Re: Reference for UTF8 in SSH UTF8 terminal mode

["Mark D. Baushke" <mdb%juniper.net@localhost>]

Hi Daniel,

Daniel Migault <daniel.migault%ericsson.com@localhost> writes:


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

Okay.

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

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.

> Yours,
> Daniel
>
> [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