["ronnie sahlberg" <ronniesahlberg@xxxxxxxxx>]

many protocols are implemented because they are in use in the wild
regardless of their standard status.

in fact, many of the most important protocols that wireshark supports
have never and will likely never be officially documented.
this includes virtually all cifs based file sharing and service
protocols. we are surely not going to remove them just because an rfc
does not exist.
other examples can be that wireshark does exist special non-rfc
versions of kerberos that are widely deplyed such as packetcable
kerberos.   this support should not be removed just because they use a
pre-1510 version of the packet formats that is not
compatible/identical to 1510 or later.





As long as the protocols exist in the wild and are useful for users it
is useful for wireshark to have them built in.

If however protocols evolve and they are not updated in wireshark it
probably means that the existing support is good enough or that not
enough interest exist to update them.


users are encouraged though to enhance dissectors and implement later
versions of the protocols.


i dont think we should remove old obsoleted versions of protocols as
long as they are used in the wild.



On 8/9/06, David Sips <DSips@xxxxxxxx> wrote:
> Hello all,
>
>
>
> I am new to development w.r.t. Wireshark though I have been a user for
> years. The question is, what are the rules/guidelines regarding protocol
> support from a standards perspective? Must a protocol meet a certain
> threshold before it can be included as part of "official" Wireshark? I
> browsed the documentation, Wiki and mailing list archive a bit and could
> find no good guidance on when a protocol should be included in the
> distribution and what the rules are for protocol that becomes obsolete.
>
>
>
> A little color and an example. I am working on a toolset that builds on
> top of a neat little tool called Scapy
> (http://www.secdev.org/projects/scapy/). As part of that toolset, I am
> developing additional classes to extend Scapy for select protocols.
> Naturally, after I construct my packets I want to inspect them on the
> wire and Wireshark provides that capability. While extending Scapy, I
> investigate a particular protocol and write my packet class based on the
> latest definition of a said protocol. I have discovered that sometimes
> Ethereal, er, I mean Wireshark, cannot decode or incorrectly decodes a
> particular protocol. For those it cannot decode I have found enough info
> so as to be able to write a new dissector. For those that are not
> correct, I have been able to identify flaws in both my Scapy packet
> classes and/or particular dissectors.
>
>
>
> As an example, the IGMP dissector (packet-igmp.c) has a few associated
> dissectors (MRDisc, MSNIP, IGAP). The dissector for Multicast Discovery
> protocol is based on draft 6 (draft-ietf-idmr-igmp-mrdisc-06.txt) of a
> proposal while the protocol has advanced to RFC status (RFC 4286). I
> would like to update the MRD dissector and submit it back but what
> should I do with the old (and now obsolete) frame definitions? I think
> removal is appropriate but I would appreciate guidance on the subject.
> Also, what about those drafts that just die (MSNIP and IGAP). I think it
> is appropriate to remove those. What does the community think? Should
> there be a set of guidelines to define the lifetime of a dissector?
>
>
>
> My apologies if this has been addressed previously.
>
>
>
> David Sips
> LVL7 Systems, Inc.
> Software Engineer
>
>
>
>
>
> The information contained in this e-mail is LVL7 confidential. Any use
> except that authorized by LVL7 is prohibited. If you get this in error,
> please notify the sender and delete this e-mail.