Re: Reference for UTF8 in SSH UTF8 terminal mode

> We are looking at which reference to UTF8 we should mention into the
> SSH UTF8 terminal mode.

> [some Web URL] mentions that RFC3629 is slightly out of date and that
> a reference to ISO/IEC 10646:2014 may also be useful.

> Is anyone aware of any deficiencies in RFC3629 fixed in ISO/IEC
> 10646:2014 ?

> The question is whether we should have one reference or both in the
> draft.  Unless RFC 3629 has some deficiencies fixed in ISO/IEC
> 10646:2014, I am incline to have only RFC3629. Is that something that
> sounds reasonable to everyone ?

My opinion - probably worth about what you paid for it - is that the
RFC is a much better reference.  This is for entirely non-technical
reasons.

The ISO believes pay-to-play is reasonable for standards, and, while
10646:2014 seems to be one they make an exception for, (a) getting it
requires a _lot_ more hoop-jumping than an RFCs, (b) getting it
requires agreeing to what for most of the world is foreign legal
jurisdiction, (c) they say what you'd get is a "single-user,
non-revisable Adobe Acrobat® PDF file", which means either it's DRMed
or they're stupid enough to think no other PDF-handling software than
Adobe's exists (I don't know which; between the jurisdictional issue,
the difficulty of jumping through their hoops, and my lack of any real
need for it, I haven't fetched it), and (d) their copyright terms are
ridiculously onerous for something supposedly "freely available" - for
example, you are prohibited from storing it on a filesystem that gets
backed up, and you are permitted only one printed copy.

> This Communication is Confidential.

Then you might want to avoid sending it to a public, publicly archived,
mailing list.

/~\ 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