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

[Nicolas Williams <Nicolas.Williams%sun.com@localhost>]

On Tue, Jun 08, 2004 at 04:26:39PM +1000, Damien Miller wrote:
> 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.

I agree.

The '@' sign here is used to reserve part of the namespace of named
SSHv2 protocol elements for private allocation (the extensions that this
enables are typically not proprietary, though they may be).

More importantly, these names are not visible to users and so users
won't try to interpret them -- these names are internal to SSHv2.

This feature has been used in production deployments for several
extensions to SSHv2, so it cannot be removed, even if the removal made
sense -- which it does not.

Nico
--