RE: Reference for UTF8 in SSH UTF8 terminal mode

[Daniel Migault <[e-mail]>]

Hi,

Apology for the confusion. So my understanding of the problem is that using RFC3629 as a reference for the UTF-8 is not convenient as its two normative references need to be updated. The two references in question are: ISO/IEC 10646:2014 and Unicode. However from this thread, I am hearing that the major concern is about providing a updated reference for Unicode, not so much ISO/IEC 10646. As a result,

I propose to have the following references:

RFC3629 as normative

[UNICODE]  The Unicode Consortium. The Unicode Standard.

              <http://www.unicode.org/versions/latest/> as informational.



A more recent version of ISO/IEC 10646 will be done by refreshing RFC3629.



Am I correct ?

Yours,
Daniel

From: Ron Frederick [mailto:[e-mail]]
Sent: Monday, December 12, 2016 8:28 PM
To: Daniel Migault <[e-mail]>
Cc: [e-mail]
Subject: 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<http://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.

Also, in your text below you switched from RFC 3629 to RFC 3929. The correct reference is the former (RFC 3629).

On Dec 12, 2016, at 11:17 AM, Daniel Migault <[e-mail]<mailto:[e-mail]>> 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: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of Mouse
Sent: Saturday, December 10, 2016 1:59 PM
To: [e-mail]<mailto:[e-mail]>
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                   [e-mail]<mailto:[e-mail]>
/ \ Email!             7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
--
Ron Frederick
[e-mail]<mailto:[e-mail]>