UMPA protocol objects field names

[ignotus]

I talked to Bartosz about using shorter names for the field names of protocols. My suggestion is to use something based on libpcap filter syntax [0] to get something near to Wireshark display filter (e.g. for TCP see [1]).

[0] http://www.cs.ucr.edu/~marios/ethereal-tcpdump.pdf [1] http://www.wireshark.org/docs/dfref/t/tcp.html

[nopper]

I would to discuss with you this, because interest me also.

PacketManipulator could use 2 backends: scapy and UMPA, but they have different protocol names and relative field nomenclature.

I mean in scapy IP packet has tos field while in UMPA for the same field we have a different name: IP.type_of_service.

Would be nice to unify this or simply create a reasonable general and common nomenclature, and then use a dynamic translator for getattr() or something like that, to be sure that the a unique nomenclature will work with both backends.

[getxsick]

As I said to Joao on IRC.. Currently name convention is based on names from RFC documents...kind of official, isn't it?

Anyway, I would like to have shorter names because using ip.source_address is of course more boring than ip.saddr or something.

But, if we gonna change it please remember that new convention has to be in some way official as well. I would like to have common reference to documents which describes it. I don't know which convention scapy uses but if it's only scapy's convention - this is no point to use the same. Users who may use UMPA propably don't know scapy or other blabla. libpcap filter convention is something really common and it's better case than scapy. Users cannot be confused and names have to be obvious for anyone.

Please notice that this change vary all API. It's OK to do it now but propably we can't change it in the future again to avoid API conflicts. So, we have to decide for upcoming milestone and this decision is important.

[getxsick]

What if I would allow to keep both type of names? Lets say as aliases? Maybe we could handle it as a dictionary or something in umpa.config or $HOME/.umpa so, users could use also any other fancy names?

[nopper]

IMHO it's useless and confusing letting the user choose alias or different names to refer to the same thing. The "standard" way should be better.

[nopper]

Well probably I've been misunderstood. I like the initiative proposed by ignotus. But to be much clear as possible what I've in mind is:

• Support pcap filter in sniffing functions provided in the API.
• Use the wireshark display filter to name the various fields of protocols implemented. In this sense wireshark offer the support for a great range of protocols trough his dissectors. So should be nice easy and common the using of his names for the various fields.

With this we should avoid headaches for developers and enduser.

[getxsick]

Replying to nopper:

- Support pcap filter in sniffing functions provided in the API.

current state of UMPA does support it.

- Use the wireshark display filter to name the various fields of protocols implemented. In this sense wireshark offer the support for a great range of protocols trough his dissectors. So should be nice easy and common the using of his names for the various fields.

OK. It's OK for me. But I've been trying to change names and seems like not all fields are described by wireshark. Example for TCP: Padding, Data Offset, Reserved Of course I know that these fields are not common and I understand why wireshard doesn't provide naming/filtering for it. But UMPA has to deal with it and what should we do in this case? Use official names from RFC? Then it would look like half of fields have name from wireshark and have from RFC. In my opinion, this way makes more confusion for endusers. But maybe I'm wrong. What do you propose?

I'm open on yours opinion, I wanted to change naming to wireshark but got stuck in those cases.

[ignotus]

I think you can do both, using RFC's as base for long names, and, when short names are not defined in wireshark, you can define it, if applicable. I think this way is near standardization, even when the short names are not already defined.

[luis]

Well, I'm seeing with Bartosz and in some causes there are some fields like tcp windows size, that have longer names compared with Standard (pcap - "windows_size", rfc - "window")

Why complicate it? Standards is very important and it was done to be respected. And RFC in this case is kind of standard.

And there are another situation: not all fields are contemplated by pcap.

---

Two API will be confuse the users, so I'm discarding it.

The last approach of João seems like to have 2 APIs too. Or is it like have a alias to some fields?

---

[getxsick]

OK. r4999 is about this ticket. i changed API to wireshark filtering convention where it's possible and for rest i left old good RFC naming.