Please note that the Transport Area is in the process to update the Port Numbers IANA registry -- see: <http://tools.ietf.org/html/draft-ietf-tsvwg-iana-ports-04>
In pursuit of long-standing IESG recommendations, the new unified Service Names and Port Numbers registry will no longer allow multiple port numbers to be registered for a single conceptual service (and different service names for variants of a service), and it intends to start applying the new policy on legacy registry content during the planned (annual?) "garbage collection" phases that IANA will conduct in the future. So unless a specific use case can be shown to be supported by a very strong momentum, the registry garbage collection phases will perhaps some day start challenging the service name registrations and default port assignments for 'imaps' and similar "services over TLS" that do not use in-band security negotiation on the same port number as the basic service and hence do not conform to the new registry rules for service names and default port number assignment. That draft says in the description of the new rules (Section 7.2): The process and protocol identifier use suggests that anything a single process can demultiplex, or that can be encoded into a single protocol, should be. The firewall filtering use suggests that some uses that could be multiplexed or encoded must be separated to allow | for firewall management. Note that this latter use is much less | sound, because port numbers have meaning only for the two endpoints | involved in a connection, and drawing conclusions about the service | that generated a given flow based on observed port numbers is not | always reliable. Further, previous separation of protocol variants | based on security capabilities (e.g., HTTP on port 80 vs. HTTPS on | port 443) is not recommended for new protocols, because all should be | security-capable and capable of negotiating the use of security in- | band. Please read draft-ietf-tsvwg-iana-ports-04 and comment on the TSVWG list, if you want. Releated discussion also happend on the apps-discuss at ietf dot org mailing list. Conclusion: It might be worth adding a strong note to your draft that again discourages further use of email-related "<someservice->s" service names and related default port numbers. Kind regards, Alfred Hönes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: [email protected] | +------------------------+--------------------------------------------+ _______________________________________________ yam mailing list [email protected] https://www.ietf.org/mailman/listinfo/yam
