Re: [Curdle] Time to Review IANA SSH Registries Policies?

>> identifiers without going through the registry (specifically,
>> identifiers of the form name@domain are permitted, as assigned by
>> the owner of that domain).

Which, actually, brings up a point.  What if the domain in question
disappears or changes "owner"s?

> It is possible to mark [email protected] as private/experimental and not
> require review.

Indeed, I think that's exactly what they are: private to the person or
organization controlling dom.ain.  (But the part before the @ is not
necessarily any kind of "user"; see 4250 4.6.1, third paragraph.)

> The only issue would be if such identifiers are needed for interop
> and the table has to be in IANA.  Is that the case?

In practice, it is not.  There are numerous examples of such names in
live use, some of which interoperate (and, except for some that are
undocumented, the ones that don't don't because implementors haven't
bothered, not because there's anything preventing it), without any sort
of IANA interaction required.

However, I have seen an ssh server (embedded in a commercial turnkey
product - a switch, I think it was) that would crash upon, as far as I
could tell, receiving any instance of the [email protected] extension
mechanism.  I had to add an option to moussh to suppress sending any
such in order for it to interoperate with that device.  (Not that this
is more than a side note; if we don't do things because buggy
implementations may mishandle them, we'll never do anything.  That was
something like a decade ago, but there are recent issues too; I just
recently ran into an ssh server that didn't offer either of the kex
methods required by 4253 6.5.)

Of course, there is nothing technical preventing anyone from
implementing something that looks like that extension mechanism
_without_ the approval of the holder of the dom.ain in question.  But
doing that, like any other spec violation, is just _asking_ for
interoperability problems.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email protected]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B