Re: [psg.com #441] IESG - Architecture - atsign - additional IESG Response

[Damien Miller <djm%mindrot.org@localhost>]

rt+secsh%rt.psg.com@localhost wrote:

>>I don't understand the comment.
>>Names of the form "user@host" are used in a number of places (email, login
>>names in ftp://user@host/ URLs, NAIs for roaming, IM identifiers and more).
>>
>>I *think* the purpose of the paragraph
>>
>>     Names with the at-sign ('@') in them are allocated by the owner of
>>     DNS name after the at-sign (hierarchical allocation in [RFC-
>>     2343]), otherwise the same restrictions as above.
>>
>>is to give local extensibility to protocol parameter identifiers; there
>>are a number of variants that are commonly suggested for this, and DNS
>>based naming is one of them. (It's not a particularly good one, though -
>>DNS names change hands too often to be considered "completely stable", and
>>we do tend to want stability in parameter naming..... it also gives all
>>the problems of "X-" headers in enabling wide deployment of
>>non-interoperable extensions; if this isn't currently in use, and we need
>>to push back on the document for other reasons, it might be worth asking
>>the authors whether losing this would cause them heartburn.

OpenSSH uses this feature now and I plan to use it in the future
for new extentions (ciphers and auth methods). Banning this will render
widely deployed software non-compliant.

The use of user@domain in the secsh protocol is completely orthogonal to
its use in URIs or email. These names are used as internal protocol
identifiers, not in addressing. IMO this is much more elegant a
namespace than X-whatever.

The "stability" issue seems irrelevant too - there are no catastrophic
consequences if the domain name goes away. Remember that these are,
by definition, vendor or site-local extensions.

-d