Wireshark · Wireshark-dev: Re: [Wireshark-dev] Related Information (again)

["Graeme Lunt" <graeme.lunt@xxxxxxxxx>]

Ulf,

Thanks for the comments.

> > It adds a new menu item "Related Information" and provides a generic
> > mechanism to register related information for:
> > * a specific hf_index - register_related_hfid_callback()
> > * a range of hf_indexes (e.g. "owned" by a given dissector) -
> > register_related_range_callback() 
> > and 
> > * a type e.g. FT_OID - register_related_type_callback();
> >   
> Will this be called for all appearances of a specific type 
> regardless of  the dissector / protocol?
> 
> In this case it's probably rather useless for most types, so 
> using the hf_index based registration might work better.

I agree there are not many types that could currently be used (eg
FT_PROTOCOL as discussed last time to provide further information e.g. link
RFC, ) - but there may be others in the future. It is useful for FT_OID type
and is part of a generic solution.

> > In addition, a new FI_URL flag has been defined to mark a 
> > field as a URL, together associated macros - e.g. PROTO_ITEM_SET_URL().
> >   
> I guess this will present the field in the protocol details tree as a 
> link (similar to "go to frame" fields) to open it in a browser? Sounds 
> reasonable.

It doesn't do this at the moment - but it easily could.

> > URL:
> > The logotypeURI_item has been marked as FI_URL and can be 
> > opened in a browser (e.g. showing the logo)
> > The uniformResourceIdentifier in a GeneralName has been 
> > marked as a FI_URL (e.g. can be used to download the CRL from the CRLDP)
> >   
> Please give a more general example, I (and probably a lot of other 
> developers) don't know CRL and CRLDP :-)

Sorry - 
CRL - certificateRevocationList
CRLDP - certificateRevocationList Distribution Point.

I'd hoped an SSL capture was fairly general (certainly more general than
X.400 and X.500!). 
Maybe you could suggest a more general protocol (which is likely to contain
URLs) and I'll find 
a further example.

> > OID:
> > All fields of type FT_OID can bring up the Harald Alvestrand web page
(e.g.
> > certificatePolicies 2.5.29.32).
> > The actual template URL can be configured on the BER preferences page
(may
> > be moved later). It is a text field (rather than option menu) for those
with
> > no Internet connection, or prefer the elibel site.
> >   
> Will this be the right way to go for *every* FT_OID field for *every* 
> protocol using it? 

Yes - that is absolutely correct.

> I have serious doubts here.

Why? Could you explain your serious doubts?

> And showing a "Harald Alvestrand page" for completely 
> unrelated topics  would be very confusing.

An OID is an OID - regardless of the protocol - why would a page detailing
the definition and usage of an OID but useful for one topic, but not for
another?

> > At the moment, only a single related page can be brought 
> > up, but I have played with a dialog for if/when there are multiple hits.
> >   
> This might be added on demand later. IMHO having a dialog 
> might not be very user friendly.

Yes - my thought too. And as there is currently only (at most) one hit per
field, it isn't yet an issue.

> > If you send patch files, be sure to:
> - diff from the latest SVN version

It was 19303 - must have missed a couple of updates while making/testing the
patch.

> - (manually) remove unrelated changes, e.g. config.nmake

Apologies - always getting hit by this. 
Question: should I be making local changes in a different file (that is not
under version control)?

> Conclusion:
> This sounds like a much more generic way to display relevant 
> information and I appreciate your work on this.
> 
> However: there is a serious usability drawback in this solution.
> This works perfectly for the developer of this solution and a user 
> working with the protocol on a day to day basis.
> Problem: How does an unexperienced user will know at which 
> field related information is available???

There is currently no way to tell as you point out. But that is not to say
that someone (with better GTK skills than me) can't contribute a solution to
this issue. 

> "Unexperienced user" scenario:
> 1. select a field in the tree
> 2. right click to look if relevant information is available
> 3. start with 1 until no more fields available
> ... as you cannot remember thousands of different fields!

There is another usage case where an inexperienced user comes across a field
he hasn't seen before and just wants to see if Wireshark can provide any
further information on that particular field. The information is context
specific. If he wants general information on the protocol, that is another
menu item.

> As you (hopefully :-) see this isn't really the way to go.

Sadly not Ufl - that is why I spent my time and effort developing and
submitting a patch.

Whilst not 100% perfect, I think it adds useful features that can be
enhanced over time. 
An indication in the display that there is further information would be a
very useful addition, but not essential for adding this functionality to
Wireshark.

> Wouldn't it be a better user experience to simply add the related 
> information as additional generated fields to the packet 
> details tree? 

It is interesting and something I looked at.

> Would this add too much new fields?

For me it would approximately double the number of fields displayed, as I
would have at least a reference to the type definition for each field.

Thanks,

Graeme