[Guy Harris <gharris@xxxxxxxxxxxx>]

> Fair enough. I agree that information needs to be presented in a variety
> of appropriate ways, so that our brain's powerful pattern matching
> capability gets enough data to get to work on. I could not get ethereal
> to produce a line like
> 
> >        0... .... = Continuation: absent
> 
> which is what I am really after, hence my suggestion of adding something to
> ethereal.

I think that would be done by declaring "Continuation" as something such
as

	{ &hf_wap_flags_continuation,
	  { "Continuation", "wap.flags.continuation", FT_BOOLEAN, 8,
	    TFS(&flags_continuation_truth), 0x80, "" } }

in an "hf_register_info" array, and declaring "flags_continuation_truth"
as:

	static const true_false_string flags_continuation_truth = {
		"absent",
		"present"
	};

(I'm assuming here that the protocol in question is WAP; if not, replace
"wap" with the appropriate name).

> >            there is no guarantee that the mere appearance of a "c" or "C"
> >            there will necessarily mean anything to the user, so I *REALLY*
> >            want to have a full textual description of all fields, including
> >            one-bit Boolean fields, not just a concise summary like the
> >            "c...  .GTr" line;
> 
> That is a fair point, but I was assuming that the 'user' in these cases
> was an expert and that C/c was as meaningful as Z/z in the flags
> word is to an Intel assembly programmer.

Well, I wouldn't assume that somebody looking at a packet trace would
necessarily find the one-letter tag obvious in all cases; some protocols
might be large enough that some fields might be obvious to most who
would look at a packet but others might be infrequently used, in which
case a more detailed display would be useful, so somebody doesn't have
to dig up the Ethereal documentation to find out what the letter in
question means.

> I have a number of female relatives who are school teachers, and have
> known from an early age that concise means brief and accurate (or
> comprehensive) not just brief. I am putting forward a case for concision
> based on my belief that packet capture can produce a very large
> quantity of data and presenting it in a physically small or short form
> (whilst retaining completeness) could be useful or even essential
> in providing our brains with the patterns needed to diagnose problems.

...and giving a full dissection might also be useful or even essential.

I'm not saying *not* to put the summary in; I'm saying that it should
not be considered a *substitute* for the bitfield-by-bitfield
dissection, but should be considered a *complement* to it - i.e:

	If I were to submit a patch implementing a type FT_FLAGS_BYTE, would    
	this be accepted. It would be in competition with the existing
	FT_BOOLEAN type but would not supplant it.

I wouldn't treat it as being in competition with using FT_BOOLEAN for
the individual bits at all - I would see them *both* being used.

Note that, for TCP, we use a different scheme for summarizing the bits
in a the flags field:

    Flags: 0x0012 (SYN, ACK)
        ..0. .... = Urgent: Not set
        ...1 .... = Acknowledgment: Set
        .... 0... = Push: Not set
        .... .0.. = Reset: Not set
        .... ..1. = Syn: Set
        .... ...0 = Fin: Not set

(I've think I've seen one person praising Ethereal over Microsoft
Network Monitor, which, in its equivalent of the "Info" field in the
packet list display, summarizes them with single letters, e.g. 
"...A..S." - he preferred, as I remember, the "SYN, ACK" summary.)

There may be advantages to both - one might well do that as

	Flags: ...A..S. (SYN, ACK)

The parenthesized summary could also display the values of multi-bit
fields, e.g.:

	Header Flags: c... .GTr (Invoke, No reassembly)

or, as we do now for the Control field in SDLC-derived protocols:

	Control field: U, func = UI (0x03)
	   000. 00.. = Unnumbered Information
	   .... ..11 = Unnumebered frame

(although the parenthesized value there is the raw hex value).

> >         3) it has the summary line displaying letters for the one-bit
> >            Boolean bitfields, which would be OK with me *as long as it
> >            didn't replace the detailed description of those fields*.
> 
> I haven't fully thought this through. I would have the full textual description
> available as a [+] reveal more tree; (you might regard this as training 
> wheels),
> so in an ideal world it is available as and when needed, but is not a 
> distraction.

That sounds as if it might be the right way to do it, e.g.:

       Header Flags
       c... .GTr
       0... .... = Continuation: absent
       .000 1... = PDU Type: Invoke
       .... .11. = Trailer flags: Packet re-assembly not supported
       .... ...0 = Retransmission: no retransmission

as per my earlier discussion - or perhaps

       Header Flags: c... .GTr
         0... .... = Continuation: absent
         .000 1... = PDU Type: Invoke
         .... .11. = Trailer flags: Packet re-assembly not supported
         .... ...0 = Retransmission: no retransmission

> > > If I were to submit a patch implementing a type FT_FLAGS_BYTE, would
> > > this be accepted. It would be in competition with the existing FT_BOOLEAN
> > > type but would not supplant it.
> >
> >What would that type do?
> 
> Meet my needs/scratch my itch. This is OSS ...

Sorry, I perhaps didn't make myself clear - that question wasn't a
rhetorical question intended to say there's no point for the feature, it
was a technical question asking what its precise semantics were, i.e. 
what would the protocol tree code put into the tree for it, and what
would it put into the display for it?

It wasn't clear to me whether you intended to make it the type for the
entire flags field, or for individual one-bit Boolean bitfields in that
field.  It sounds now as if you intended it to be the type for the
former, rather than the latter.

> If you allow FT_FLAGS_BYTE then FT_FLAGS_HALFWORD and
> FT_FLAGS_WORD would follow.

Then perhaps they should be FT_FLAGS_UINTn, or FT_FLAGS_n, or something
such as that, along the lines of the FT_UINTn field types.