[Guy Harris <guy@xxxxxxxxxxxx>]

On Oct 16, 2008, at 1:11 AM, Bryant Eastham wrote:

> I suppose the idea would be that selecting the field and some option  
> (menu, shortcut, context menu) would open a browser to a URL  
> associated with the field by the dissector. It could be a static  
> part of the field definition (most likely) or even dynamic based on  
> the particular context.
>
> I see that there are links to the wiki for protocols, but not for  
> fields. Further, the wiki is not the only resource available (or,  
> horrors, the best). As someone mentioned a while ago, the wiki is  
> more for how Wireshark works with the protocol, not (I think) to act  
> as the authoritative reference of the protocol itself.

It's definitely not *the* authoritative reference for the protocol;  
the authoritative reference for Ethernet, for example, is at

	http://standards.ieee.org/getieee802/download/802.3-2005_section1.pdf

through

	http://standards.ieee.org/getieee802/download/802.3-2005_section5.pdf

not

	http://wiki.wireshark.org/Ethernet

I'm not sure I'd say it's *solely* for how Wireshark works with the  
protocol, however; the Ethernet page in the wiki, for example, has  
some tutorial information about Ethernet, as well as information about  
display and capture filters for Ethernet in Wireshark.

> What I propose would be a link to the authoritative reference (RFC,  
> internal spec, whatever).

For protocols in the standard Wireshark release, one could add  
authoritative references to the Wiki page itself.  Those pages  
arguably *should* have pointers to the protocol specification if it's  
available on-line.

For private protocols in plugins, that obviously doesn't suffice.  The  
ability to add an official-specification URL to a protocol might be  
useful here; a menu item to go to the official specification would  
show up in, for example, the context item for a protocol item.  That  
could also be used for standard protocols as well.

Whether the URL should be in the source code, or in, for example, a  
file mapping protocol filter names to protocol specification URLs is  
another matter.  I might be inclined to go for the latter, as it'd let  
users, for example, deal with moved URLs without having to change the  
source code and recompile.  It would also handle the "private  
protocols" case.

Also, what if there isn't *A* protocol specification?  There is an RFC  
for BOOTP, and another RFC for DHCP, and a whole pile of RFCs for  
various DHCP options, for example.  That's one case where links from a  
Wiki page would work better.

Perhaps, instead, there should be a file giving URLs for protocols  
and, if a protocol has an entry in the file, it'd be presumed that  
there isn't a Wireshark Wiki page for the protocol, and the context  
menu for the protocol would have, instead of the link to the Wiki, a  
link to the specified URL.  That page could give tutorial information  
as well as one or more links to protocol specifications.

For fields, it's a bit more complicated.  The official reference for,  
for example, eth.dst and eth.src is, I guess, section 3.2.3 of 802.3,  
but there's not really a way to point to that.