Subject: Reference for UTF8 in SSH UTF8 terminal mode

From: Daniel Migault <[email-masked]>
Date: Sat, 10 Dec 2016 02:53:10 +0000

Hi Mark,

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

[1] 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 ?

Yours,
Daniel

[1] https://www.ietf.org/mail-archive/web/secsh/current/msg01242.html

[Ericsson]<http://www.ericsson.com/>

DANIEL MIGAULT
Researcher
Research

Ericsson
8500 Boulevard Decarie
H4P 2N2 Montreal, Canada
Phone +1 514 345 7900 46628
Mobile +1 514 452 2160
[email-masked]
www.ericsson.com

[http://www.ericsson.com/current_campaign]<http://www.ericsson.com/current_campaign>

Legal entity: Ericsson Canada Inc., registered office in Montreal. This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer<http://www.ericsson.com/email_disclaimer>

---

From: "Mark D. Baushke" <[email-masked]>
Date: Sat, 10 Dec 2016 08:09:49 -0800

Hi Daniel,

> We are looking at which reference to UTF8 we should mention into the

Okay.

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

Section 5 of RFC 3629 does a pretty good job of pointing out that the
standards are alive. I have not seen large disruption in the definition.
I do think that the new line breaking algorithm in [UNICODE9.0.0] UAX#14
are relevant to the SSH work.

UTS#39, Unicode Security Mechanisms, may also be relevant to SSH.

RFC 3629 has a normative reference of

   [UNICODE]   The Unicode Consortium, "The Unicode Standard -- Version
               4.0",  defined by The Unicode Standard, Version 4.0
               (Boston, MA, Addison-Wesley, 2003.  ISBN 0-321-18578-1),
               April 2003, <http://www.unicode.org/unicode/standard/
               versions/enumeratedversions.html#Unicode_4_0_0>.

and what I am suggesting is that an informative reference to the living
standard may be desirable:

   [UNICODE]  The Unicode Consortium. The Unicode Standard.
              <http://www.unicode.org/versions/latest/>

I guess an alternative would be to add an informative referene to

   [UNICODE9.0] The Unicode Consortium. The Unicode Standard, Version
                9.0.0, (Mountain View, CA: The Unicode Consortium, 2016.
                ISBN 978-1-936213-13-9
                <http://www.unicode.org/versions/Unicode9.0.0/>

which is a bit newer than the UNICODE 4.0.0 URL used in RFC 3629.

> 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 ?

It does sound reasonable, but it may also imply that implmentors need to
find [UNICODE] resources on their own and may more likely point to older
and more obsolete stanards than is desirable.

> [1] https://www.ietf.org/mail-archive/web/secsh/current/msg01242.html

This is just my personal opinion. I have no strong objections to the
current draft as written.

	-- Mark

---

From: Mouse <[email-masked]>
Date: Sat, 10 Dec 2016 07:59:28 -0500 (EST)

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

> 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-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: Ron Frederick <[email-masked]>
Date: Sat, 10 Dec 2016 07:06:00 -0800

> 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 th…

According to RFC 3629:

   NOTE -- The authoritative definition of UTF-8 is in [UNICODE].  This
   grammar is believed to describe the same thing Unicode describes, but
   does not claim to be authoritative.  Implementors are urged to rely
   on the authoritative source, rather than on this ABNF.

The actual link in the RFC for [UNICODE] is somewhat out of date as you said, but wouldn’t the best reference here be to http://www.unicode.org/versions/latest/ <http://www.unicode.org/versions/latest/> listed on the page that the RFC links to? According to that page:
The documentation for the latest version of the Unicode Standard is always found at the stable link: http://www.unicode.org/versions/latest/ <http://www.unicode.org/versions/latest/>
This reference also has an excellent appendix which describes the relationship between the Unicode standard and ISO/IEC 10646 at:

http://www.unicode.org/versions/Unicode9.0.0/appC.pdf <http://www.unicode.org/versions/Unicode9.0.0/appC.pdf>

The definition of UTF-8 can be found in section 3.9 of the Unicode specification, and the appendix states:
The ISO/IEC 10646 definition of UTF-8 is identical to UTF-8 as described under Definition D92 in Section 3.9, Unicode Encoding Forms. 

-- 
Ron Frederick
[email-masked]

---

From: Daniel Migault <[email-masked]>
Date: Mon, 12 Dec 2016 19:17:05 +0000

Hi, 

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: [email-masked] [mailto:[email-masked]] On Behalf Of Mouse
Sent: Saturday, December 10, 2016 1:59 PM
To: [email-masked]
Subject: Re: Reference for UTF8 in SSH UTF8 terminal mode

> 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

---

From: Ron Frederick <[email-masked]>
Date: Mon, 12 Dec 2016 11:28:29 -0800

What’s the motivation for not directly referencing http://www.unicode.org/versions/latest/ <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).

-- 
Ron Frederick
[email-masked]

---

From: Daniel Migault <[email-masked]>
Date: Mon, 12 Dec 2016 19:58:40 +0000

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

              <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:[email-masked]]
Sent: Monday, December 12, 2016 8:28 PM
To: Daniel Migault <[email-masked]>
Cc: [email-masked]
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.

On Dec 12, 2016, at 11:17 AM, Daniel Migault <[email-masked]<mailto:[email-masked]>> wrote:

Yours,

Daniel
-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Mouse
Sent: Saturday, December 10, 2016 1:59 PM
To: [email-masked]<mailto:[email-masked]>
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.

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

/~\ The ASCII                                     Mouse
\ / Ribbon Campaign
X  Against HTML                   [email-masked]<mailto:[email-masked]>
/ \ Email!             7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
--
Ron Frederick
[email-masked]<mailto:[email-masked]>

---

From: Mark Baushke <[email-masked]>
Date: Tue, 13 Dec 2016 06:24:57 +0000

> On Dec 12, 2016, at 11:58 AM, Daniel Migault <[email-masked]> wrote:
> 
> Hi,
>  

I like it.

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

Yes.

> Am I correct ?

It seems like a good plan to me.

-- 
Mark D Baushke
[email-masked]
Security, from Chip to Cloud

---

From: Ron Frederick <[email-masked]>
Date: Tue, 13 Dec 2016 07:18:32 -0800

> It seems like a good plan to me.

Sounds good here as well. Thanks!
-- 
Ron Frederick
[email-masked]

---

From: Daniel Migault <[email-masked]>
Date: Tue, 13 Dec 2016 18:30:04 +0100

Hi,

Thanks for the feed backs, I believe we are now ready for a (last) version
before moving the draft forward.

Yours,
Daniel

On Tue, Dec 13, 2016 at 4:18 PM, Ron Frederick <[email-masked]> wrote:

> >> 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,
> >>