Re: Standard defined field names in Wireshark dissectors

[Dario Lombardo <lomato () gmail com>]

I agree that scripts should not rely on such an output. However sometimes
there isn't another option or people just do it anyway. We must consider
that as well.
Talking about Tomasz proposal, I agree that we should follow the standards
as closely as possible. But if that breaks backward compatibility, I'd
suggest to keep it for wirershark 4.0.
Major version changes break backward compatibility, and that looks to be
the case.

On Sun, Jan 5, 2020 at 7:17 PM Guy Harris <guy () alum mit edu> wrote:

> On Jan 5, 2020, at 8:06 AM, Tomasz Moń <desowin () gmail com> wrote:
>
> > In case of the USB Audio descriptor dissection, I would like to change
> > the header_field_info name, leaving abbrev as is. Would that still
> > cause problems?
>
> It would cause problems for programs that parse TShark -T text (default
> text) output (or "export the packet dissections as plain text" Wireshark
> output), but programs should avoid doing that if possible - they should use
> other -T formats, in which the abbrev is used.
>
> It shouldn't cause problem for any other software; filters, for example,
> use the abbrev.  ("abbrev" should be thought of as the field name, and
> "name" should be thought of as the field *description*.)
>
> ___________________________________________________________________________
> Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
> Archives:    https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>              mailto:wireshark-dev-request () wireshark org
> ?subject=unsubscribe



-- 

Naima is online.

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe