Re: Reference for UTF8 in SSH UTF8 terminal mode

What’s the motivation for not directly referencing http://www.unicode.org/versions/latest/ here, or is that the link you had in mind to use in conjunction with the RFC? I understand and agree with the objection raised about not wanting to deal with the hassles of pay-to-play specifications and custom watermarked PDFs that would apply to some of the ISO/IEC docs, but that does not apply to the documents present on www.unicode.org. While I have no objection to linking to the RFC, it does reference quite an old version of the standard at this point.

On Dec 12, 2016, at 11:17 AM, Daniel Migault <daniel.migault%ericsson.com@localhost> wrote:

Thank you all for the comments and feed backs.

As far as I understand, adding the two references ISO/IEC 10646:2014 with URL and RFC3629 in the current document reaches a consensus. ISO will be informative while RFC3929 will be normative.

I also noted that for the future, there is a demand that RFC3929 be refreshed with at least new references for Unicode. But I do not think we should wait for that now.

If that is fine with everyone, I believe the draft can be moved forward.

Yours,

Daniel
-----Original Message-----
From: ietf-ssh-owner%NetBSD.org@localhost [mailto:ietf-ssh-owner%NetBSD.org@localhost] On Behalf Of Mouse
Sent: Saturday, December 10, 2016 1:59 PM
To: ietf-ssh%NetBSD.org@localhost
Subject: 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(r) 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 mouse%rodents-montreal.org@localhost
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B