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.
