Re: [yam] draft-daboo-srv-email: POP3S/IMAPS?

[Ned Freed <[e-mail]>]

> 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.

Sigh. We've attemped this sort of purity policing many times in the past. The
results can be summarized quite simply:

    IT DOES NOT WORK

I just don't understand why IETFers have such a grossly inflated belief in the
power of registries to influence developer behavior. In reality it's
astonishlngly difficult to get people to register stuff and/or to use
registered stuff even when the advantages of doing so are extremely clear and
obvious.

And that's when there are clear advantages to registration. When the registry
attempts to police out what they view as bad behavior, what invariably happens
is people simply ignore the rules and do whatever they feel they nave to do.

It is only through literally years of hard work that we've managed to mostly
overcome the effects of our deeply misguided attempt at purity policing when
the media types registry was first set up.

And while the situation with the charsets registry is a little more complex, a
nonnegligable part of its failure to *ever* recover relates to ongoing purity
policing efforts.

> 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 ignorance in that statement is simply astonishing. Heck, this could be seen
sas saying that we should be ddoing everything with HTTP on port 80.

>    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.

I'm sorry to have to say it, but if this represents where they are in terms of
their thinking they are so far off in the weeds there's no point in bothering.

> 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.

While I agree with the sentiment, I'll repeat for at least the third time that
this draft isn't the place to make the point. We're dealing (or at least
attempting to deal) with service discovery for a very limited set of existing
protocols. Even if someone was planning to define managesieves:, the chances of
them looming to this document for advice are for all intents and purposes zero.

				Ned