Do we really need port preferences for dissectors?

[Michael Mann <mmann78 () netscape net>]

I've ran across a bunch of dissectors lately that don't have an IANA registered port, so they add a port preference.  
This is done is one of two ways:
1. Assigning their "randomly picked" port number to the preference, possibly requiring a user to change (set to 0) if 
it interferes with their traffic.  Since these are usually niche protocols, I can understand someone being annoyed by 
the "interference".
2. Defaulting port preference to 0, then making sure it's non-zero when registering with the (TCP/UDP) dissector table. 
 If not careful, sometimes the dissector isn't registered at all, so Decode As can't be used.

Since Decode As can also be persistent, wouldn't that be a better way to (force users to) go?  To me it has similar 
logic/justification as when I removed the "subdissector preferences" in favor of Decode As.  While it would be nice to 
have users go to a single place to decide a "heuristic hierarchy" (a subject that is touched on from time to time), 
having port preferences seems to spread it out more than necessary.

I'm hesitant because of the number of backwards compatibility issues it could introduce, but if we converted the 
preferences into the Decode As structure (if found), wouldn't that alleviate a lot of it? 

I'm more okay with keeping "range" preferences for protocols (at least for now) as that seems a more tedious task to do 
with Decode As.

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