Subject: [art] AD review of draft-ietf-appsawg-file-scheme-13.txt

From: Alexey Melnikov <[email-masked]>
Date: Tue, 22 Nov 2016 11:44:36 +0000

Hi,

I think the document is generally in a good state, but I have a couple 
of minor things to discuss:

1) In Section 4:

   When a file URI is produced, characters not allowed by the syntax in 
Section 2 SHOULD be percent-encoded as characters using UTF-8 encoding, 
as per [RFC3986], Section 2.5.

This text is confusing. Are you trying to say that first Unicode 
characters are encoded in UTF-8 and then that encoding is percent encoded?

2) Section 6 doesn't include all IANA registration template fields 
specified in RFC 7595, Section 7.4.

I would like these to be fixed before the document reaches IESG, but I 
don't think this needs to cause delay before starting IETF Last Call.

Best Regards,

Alexey

---

From: Matthew Kerwin <[email-masked]>
Date: Wed, 23 Nov 2016 11:18:19 +1000

Hi Alexey,

On 22 November 2016 at 21:44, Alexey Melnikov <[email-masked]>
wrote:

> Hi,
>
> I think the document is generally in a good state, but I have a couple of
> minor things to discuss:
>
>
> 1) In Section 4:
>
> Section 2 SHOULD be percent-encoded as characters using UTF-8 encoding, as
> per [RFC3986], Section 2.5.
>
​Yeah, pretty much.  @mnot originally proposed it, and I never really
improved on his first suggestion.

It speaks to RFC 3986:

   "When a new URI scheme defines a component that represents textual
   data consisting of characters from the Universal Character Set [UCS],
   the data should first be encoded as octets according to the UTF-8
   character encoding [STD63]; then only those octets that do not
   correspond to characters in the unreserved set should be percent-
   encoded."

Would you prefer I switched it from descriptive to imperative, like this?:

"When a file URI is produced, characters not allowed by the syntax in
Section 2 SHOULD be encoded using UTF-8 and percent-encoded, as per
[RFC3986], Section 2.5."​

> specified in RFC 7595, Section 7.4.
​It's just the 'References' that's missing, correct? In my working draft
I've added it with:

"See Section 8 of this document."

I think that covers it.  Turns out I last substantially updated that
section just before RFC 7595 was published.​

> don't think this needs to cause delay before starting IETF Last Call.
​I can publish -14 pretty quickly once we resolve the working in Section 4,
if that's what you want.  (Assuming we don't mind the XML upload being
broken.)

Cheers
-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/

---

From: Dave Crocker <[email-masked]>
Date: Tue, 22 Nov 2016 17:23:25 -0800

> [RFC3986], Section 2.5."​

The oddity in the language is that the phrasing implies that the 
characters that /are/ allowed won't be in UTF-8.

I would have thought that the entire string is always UTF-8, but the 
non-allowed characters need to be percent-encoded.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Matthew Kerwin <[email-masked]>
Date: Wed, 23 Nov 2016 11:47:41 +1000

> non-allowed characters need to be percent-encoded.
​Oh, yeah, I think I overlooked UTF-16 and EBCDIC, which contain characters
that are allowed by the syntax but don't encode to US-ASCII-compatible
octets.  How about this?:

"
When a file URI is produced, characters SHOULD be encoded using UTF-8, and
any characters not allowed by the syntax in Section 2 MUST be
percent-encoded.
"

I think that recaptures the original intent better as well, now I look at
it.

Cheers

---

From: Dave Crocker <[email-masked]>
Date: Tue, 22 Nov 2016 18:03:47 -0800

On 11/22/2016 5:47 PM, Matthew Kerwin wrote:
> ​ Oh, yeah, I think I overlooked UTF-16 and EBCDIC, which contain
> characters that are allowed by the syntax but don't encode to
> US-ASCII-compatible octets.  How about this?:

Overlooking UTF-16 and EBCDIC has always seemed like simple good hygiene 
to me...  But I assume you really mean that those might be the 'native' 
form and the issue is mapping to the canonical form in the standard...

> When a file URI is produced, characters SHOULD be encoded using UTF-8,
> and any characters not allowed by the syntax in Section 2 MUST be
> percent-encoded.

That sounds much more like what I'd expect to see.  (My comment is 
waffling only because I try to be careful not to sound as if think I 
know anything about UTF-*...)

> I think that recaptures the original intent better as well, now I look
> at it.

dandy.

d/

-- 

   Dave Crocker

---

From: John C Klensin <[email-masked]>
Date: Tue, 22 Nov 2016 22:01:24 -0500

--On Tuesday, November 22, 2016 17:23 -0800 Dave Crocker
<[email-masked]> wrote:

>> "When a file URI is produced, characters not allowed by the
>> syntax in Section 2 SHOULD be encoded using UTF-8 and
>> percent-encoded, as per [RFC3986], Section 2.5."​
> 
> The oddity in the language is that the phrasing implies that
> the characters that /are/ allowed won't be in UTF-8.

Dave, I don't read the statement that way although it is
certainly confusing and easy to interpret the way you read it.
I agree that it should probably be improved.  The minimum
change, which I don't think is good enough for the reasons
below, would be to insert "then" after "using UTF-8 and".

Matthew, IMO the problem is that the productions/ definitions
you are co-opting from 3986 prohibit two types of characters:
assorted ASCII "specials" and everything non-ASCII.   Both are
required to be percent-encoded, but, while Unicode characters
outside the ASCII repertoire require encoding into UTF-8 first,
ASCII characters do not -- they are precisely one octet each and
one just applies the percent-encoding algorithm as it was
originally defined to each octet in turn.  

What makes your statement technically correct if the missing
word is assumed is that, because the ASCII repertoire is a
strict subset of Unicode and the only encoding for ASCII that
has, AFAIK, _ever_ been used on the Internet is a strict subset
of Unicode in UTF-8 with a one-one mapping, "encoding ASCII into
UTF-8" is a trivial identity operation, so encoding the relevant
ASCII characters into UTF-8 and then percent-encoding will
actually work just fine.   However, that formulation will also
create a lot of confusion, not only the way in which Dave was
confused but because, if one is being precise, "UTF-8" is just
an encoding method that is not specific to a particular coded
character set or character repertoire.  There is no reason why
one could not encode an ISO 8859-1 string in UTF-8.   So, while
you can say "ASCII" (a character repertoire, a coded character
set (i.e., a mapping from each characters in the repertoire to a
code point), and an encoding (on the Internet, one octet per
character with the 7bit ASCII right aligned in an octet with a
leading zero bit per RFC 20)), you should be saying "Unicode
encoded in UTF-8", not just "UTF-8".

> I would have thought that the entire string is always UTF-8,
> but the non-allowed characters need to be percent-encoded.

See above.  Certainly one hopes that the entire string is in
Unicode encoded in UTF-8 and making a statement that can imply
UTF-8 is an alternative to percent-encoding would just be wrong. 

<rant>
That, however, gets me to the issue that has always bothered me
about efforts to completely nail down the "file:" scheme.   The
examples in Appendix D are not comprehensive (and should, by the
way, be identified as examples).  One can imagine (and some of
us have encountered and used) file systems that are far more
different from those four than any of them are from each other
_and_ that do not use ASCII (at least as the IETF and everyone
else these days encodes it) or Unicode for files names or paths.
In doing file operations on those systems, one would really
prefer that a file URL track the conventions of the local
system, if only because the transcoding processes may require
additional information that there is no obvious place to put or,
without that information, may be ambiguous.  If one goes down
that path, either UTF-8 may not be appropriate or specifying
"Unicode in UTF-8" or "whatever you have in UTF-8" may be an
important distinction.  One may also need to understand the path
elements and file system well enough to talk in terms of access
methods, not just "file".

FWIW, we dealt with most of those issues in a file retrieval
protocol more than forty years ago -- a careful reading of the
evolution of the ARPANET/ Internet File Transfer Protocol specs
will provide insight into a lot of them in the context of a much
more diverse collection of file system models than we typically
encounter today.

I don't think the document needs to reflect those issues in any
significant way -- if we reach a point at which the model it
(and 3986) use is obsolete or even significantly challenged, we
are going to have enough other problems to make the issues with
this spec fairly minor.  However, I do believe the spec would be
improved by being a little more sensitive to the possibilities.
Making sure that Appendix D is clear that those are examples
rather than a comprehensive list of operating systems in which
"file:" can be used would be an example of such sensitivity.
</rant>

best,
    john

---

From: Matthew Kerwin <[email-masked]>
Date: Wed, 23 Nov 2016 13:05:22 +1000

On 23 November 2016 at 12:03, Dave Crocker <[email-masked]> wrote:

> waffling only because I try to be careful not to sound as if think I know
> anything about UTF-*...)
>
>
​Actually on reflection I think this butts up against one of the earliest
contentions the draft had.  This comment was from Dave Thaler, a couple of
years ago:

> As draft-montenegro-httpbis-uri-encoding summarizes:
>
>> The URI RFC [RFC3986] talks about the generic syntax for URI
>> components:
>>
>> * Legacy URI components (before 2005) tend to use UTF-8 "or some
>>   other superset of the US-ASCII character encoding"
>>
>> * New schemes (after 2005) use UTF-8 with percent encoding for
>>   reserved characters.
>
> The file URI is a legacy (pre-2005) scheme for which the encoding is
> not deterministic, and indeed varies across implementation. And this
> is unlikely to ever change. Unlike HTTP, file has no protocol. For
> HTTP, the problem is “fixable” in the protocol, as
> draft-montenegro-httpbis-uri-encoding proposes.
>
> A generic URI parser can never assume percent-encoded octets are
> UTF-8 (for file, http, https, or any scheme for which it has no
> scheme-specific knowledge).

By changing this paragraph to say that all characters should be UTF-8,
we're adding a new restriction to the scheme which is likely incompatible
with a bunch of current stuff (especially in Microsoft world), and not
strictly necessary to bring the scheme in line with RFC 3986.

It's not so much an issue for UTF-16, since that's not a superset of
US-ASCII, but it could matter for windows-1252 (which is.) It's a question
of whether "
%C3%83" means "
Ã" or "Ãƒ
​​
"

In this case I'd want to confirm that that's how people were already
interpreting the paragraph, before changing it to make it more explicit.  I
don't want to rewrite any consensus here.

Cheers

---

From: John C Klensin <[email-masked]>
Date: Tue, 22 Nov 2016 22:35:55 -0500

--On Wednesday, November 23, 2016 11:47 +1000 Matthew Kerwin
<[email-masked]> wrote:

> ​Oh, yeah, I think I overlooked UTF-16 and EBCDIC, which
> contain characters that are allowed by the syntax but don't
> encode to US-ASCII-compatible octets. 

You are confusing "encoding" with "coded character set".  The
_characters_ available in Unicode encoded in UTF-16 are, by
definition, exactly the same as the _characters_ available in
Unicode encoded in UTF-8.  EBCDIC is another matter.  The
character repertoire and code point assignments depend on
selection of code pages; some have exact and unambiguous
mappings to Unicode but I wouldn't count on that being true for
all of them.

I also don't know what a "US-ASCII-compatible octet" is.  Unless
one turns that high bit on, bits are bits.

> How about this?:
 
> "
> When a file URI is produced, characters SHOULD be encoded
> using UTF-8, and any characters not allowed by the syntax in
> Section 2 MUST be percent-encoded.
> "
 
> I think that recaptures the original intent better as well,
> now I look at it.

See my previous note.   First of all, percent-encoding really
encodes octets, not characters.  That may have been a mistake
(see RFC 5137) but it is far too late to consider changing that
now.  Outside the ASCII range (and _only_ outside the ASCII
range), the thing that makes [Unicode in] UTF-8 important is
that percent-encoding of, e.g., "Ω" (U+03A9) yields "%CE%A9"
and not, e.g., %0e%A9 which is what one would get if one encoded
the UTF-16 octets instead.   Again, RFC 3986 (and hence Section
2) disallow "/" (U+002F) but it is a (by definition
single-octet) ASCII character and its percent-encoding is %2F
for reasons that have everything to do with the original
definition of percent-encoding and just about nothing to do with
the ASCII<->UTF-8 relationship.

There actually is a protocol issue here and, if you are going to
say "SHOULD" rather than "MUST", perhaps we should make you
address it.   If I have a file system whose file names and paths
are natively expressed in Unicode encoded in UTF-16, then it
actually is a big deal whether you expect that, at least outside
the ASCII repertoire and maybe including it) to be transcoded to
UTF-8 and then percent-encoded or whether, since 3986 doesn't
make specific allowances for other character sets or encodings,
you want to treat _all_ file names and paths expressed in the
native form of that file system as "not allowed by the syntax"
end percent-encode the native octets.   If you want to allow the
latter, you need to explain it.  If you intend the former, then
non-ASCII character MUST be in (or converted to) Unicode and
encoded in UTF-8 because anything else will result in ambiguity
and nasty interoperability problems.

    john

---

From: Dave Crocker <[email-masked]>
Date: Tue, 22 Nov 2016 19:53:03 -0800

On 11/22/2016 7:05 PM, Matthew Kerwin wrote:
> know anything about UTF

So, I'm quoting the same text I did last time, but this time I'm 
responding to some of the more recent concerns:

      To the extent the above simplifies the range of supported data to 
be a single, common standard (utf-8) where the history has been 
multiple, competing ones, I'd class that as an enormous and fundamental 
improvement.

The simplification is well worth it.

d/
-- 

   Dave Crocker

---

From: John C Klensin <[email-masked]>
Date: Tue, 22 Nov 2016 22:58:05 -0500

--On Wednesday, November 23, 2016 13:05 +1000 Matthew Kerwin
<[email-masked]> wrote:

>...
>> That sounds much more like what I'd expect to see.  (My
>> comment is waffling only because I try to be careful not to
>> sound as if think I know anything about UTF-*...)

I'm trying to fill that little gap in... see earlier notes in
this thread and the discussion in RFC 5198.

>...
> ​Actually on reflection I think this butts up against one of
> the earliest contentions the draft had.  This comment was from
> Dave Thaler, a couple of years ago:
>...
>> A generic URI parser can never assume percent-encoded octets
>> are UTF-8 (for file, http, https, or any scheme for which it
>> has no scheme-specific knowledge).

See previous comment about percent-encoding encoding octets,
not, e.g., Unicode code points or any particular encoding.

> By changing this paragraph to say that all characters should
> be UTF-8, we're adding a new restriction to the scheme which
> is likely incompatible with a bunch of current stuff
> (especially in Microsoft world), and not strictly necessary to
> bring the scheme in line with RFC 3986.
> 
> It's not so much an issue for UTF-16, since that's not a
> superset of US-ASCII,

On an octet by octet basis, sure it is, at least for selected
sets of code points.   Consider "™" (U+2122).  It isn't a
valid character in the syntax, so needs to be percent-encoded.
Its UTF-16 encoding consists of two octets which, in a slightly
different notation to reduce confusion, would be x'21' x'22'.
But, if you percent-encode that directly and don't have external
knowledge, it looks like %21%22 or ASCII '!"' -- two perfectly
good ASCII characters that happen to require percent-encoding in
at least some 3986 contexts.  

> but it could matter for windows-1252
> (which is.) It's a question of whether "
> %C3%83" means "
> Ã" or "Ãƒ​
> "

Yep.

> In this case I'd want to confirm that that's how people were
> already interpreting the paragraph, before changing it to make
> it more explicit.  I don't want to rewrite any consensus here.

Whatever you decide, you need to be sure that, at least outside
the ASCII range, you are very precise about exactly what
percent-encoding is applied to.  If that is a local option, say
so and move on.

    best,
     john

---

From: John C Klensin <[email-masked]>
Date: Tue, 22 Nov 2016 23:06:32 -0500

--On Tuesday, November 22, 2016 19:53 -0800 Dave Crocker
<[email-masked]> wrote:

>>     using UTF-8, and any characters not allowed by the syntax
>>     in Section 2 MUST be percent-encoded.
>> 
>> 
>> sound as if think I know anything about UTF
> 
> So, I'm quoting the same text I did last time, but this time
> I'm responding to some of the more recent concerns:
> 
>       To the extent the above simplifies the range of
> supported data to be a single, common standard (utf-8) where
> the history has been multiple, competing ones, I'd class that
> as an enormous and fundamental improvement.
> 

Agreed.  More generally, if we could get rid of everything in
protocols and on the wire other than Unicode in UTF-8, we'd be
better off for all sorts of reasons.

However, making that simplification involves invalidating some,
probably a lot of, existing uses.  To some degree, it shifts the
document from describing current and historical practice to
describing a new scheme with properties similar to, but much
more clear, precise, and consistent than, the historical "file:"
one.   Normally that would call for creating a new scheme
("file1:", "filebis:" ?) and then discouraging use of the old
one.   Do we want to do that?  If not, does an "it is always
Unicode in UTF-8 except when the URL, reference, or usage are
old" situation create, e.g., any security problems?

    best,
      john

---

From: Matthew Kerwin <[email-masked]>
Date: Wed, 23 Nov 2016 14:12:19 +1000

> originally defined to each octet in turn.

​Actually RFC 3986, Section 2 explicitly doesn't forbid
non-US-ASCII-encoded octets in URIs, only characters that don't have an
equivalent in US-ASCII. It's goes to lengths to clarify how to map between
US-ASCII ABNF terminals and not-necessarily-ASCII URI characters.

I think we're now suffering from the same thing those authors did in 2005
-- we have to live with crappy implementations that don't play nice.

> actually work just fine.

> However, that formulation will also
> one could not encode an ISO 8859-1 string in UTF-8.

​Not so, UTF-8 covers both encoding and charset. RFC 3629 explicitly says
it's for encoding ISO/IEC 10646-1 UCS / Unicode characters.

"UTF-8 encodes UCS characters as a varying number of octets, where the
   number of octets, and the value of each, depend on the integer value
   assigned to the character in ISO/IEC 10646..." [RFC 3986]

"UTF-8 is a Unicode encoding form that assigns each Unicode scalar value to
an unsigned byte sequence..." <
http://www.unicode.org/versions/Unicode6.0.0/ch03.pdf>, D92.

Etc.

I'm pretty sure it's widely recognised that UTF-8 always only encodes UCS
codepoints.  (Not to mention the fact that "UTF-8" is in IANA's Character
Set registry.)​

>    So, while

​I don't understand what you're saying here. I don't think anyone ever said
UTF-8 (even just the encoding part of it) could be an alternative to
percent-encoding.​

> way, be identified as examples).

​"...highlights some observed behaviours..." isn't enough? Sure, I can
fluff it out.

I'll stop responding here because there are half a dozen new messages in
the thread which I'll read first.

Cheers

---

From: Matthew Kerwin <[email-masked]>
Date: Wed, 23 Nov 2016 15:08:30 +1000

Here's the point I can jump back in after my last (abridged) response.

> at least some 3986 contexts.

Sorry, I've been imprecise in my words. I meant to say that UTF-16 does not
have the property that, for any given sequence of US-ASCII characters
(repertoire, charset, and encoding), the same sequence of characters
encoded in UCS-2 (repertoire) using UTF-16 (charset and encoding) results
in the same sequence of octets.

Windows-1252 does have that property, and doesn't come under the "Unicode"
umbrella, which is what made it seem dangerous to me.  Although I agree
that U+2122/%21%22/!" is interestingly ambiguous, and just as (or even
more) dangerous in a different way.​

[then]:

> More generally, if we could get rid of everything in

Which begs the question, what does "on the wire" mean for this URI scheme?
Most of the uses I, personally, am familiar with are: locally-minted,
locally-used.

> old" situation create, e.g., any security problems?

I just want to write down what happens now, and try to realign the scheme
with RFC 3986. (Originally I just wanted to disassociate the "obsolete"
flag from the scheme, so it could be used with Ruby's OpenURI library.)
 Whatever gets us to that place is good with me, especially if it avoids
stalling in the same encoding quagmire that killed the last attempt (a
decade ago.)

I'm not aware of any specific security issues. There is a mention in
Security Considerations:

  "​Care MUST be taken to avoid issues resulting from possibly unexpected
aliasing from [...] mismatched encodings or Unicode equivalences [UTR15]
(see Section 4)."

Cheers

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 23 Nov 2016 07:30:58 +0000

> On 23 Nov 2016, at 01:18, Matthew Kerwin <[email-masked]> wrote:
> 
> Hi Alexey,
> 
>> On 22 November 2016 at 21:44, Alexey Melnikov <[email-masked]> wrote:
>> Hi,
>> 
>> I think the document is generally in a good state, but I have a couple of minor things to discuss:
>> 
>> 
>> 1) In Section 4:
>> 
>>   When a file URI is produced, characters not allowed by the syntax in Section 2 SHOULD be percent-encoded as characters using UTF-8 encoding, as per [RFC3986], Section 2.5.
>> 
>> This text is confusing. Are you trying to say that first Unicode characters are encoded in UTF-8 and then that encoding is percent encoded?
> 
> ​Yeah, pretty much.  @mnot originally proposed it, and I never really improved on his first suggestion.
> 
> It speaks to RFC 3986:
> 
> "When a file URI is produced, characters not allowed by the syntax in Section 2 SHOULD be encoded using UTF-8 and percent-encoded, as per [RFC3986], Section 2.5."​

This is better. Thank you.

---

From: John C Klensin <[email-masked]>
Date: Wed, 23 Nov 2016 03:19:26 -0500

Matthew,

I'm going to drop back out of this .. other things to do, but...

--On Wednesday, November 23, 2016 14:12 +1000 Matthew Kerwin
<[email-masked]> wrote:

> ​Not so, UTF-8 covers both encoding and charset. RFC 3629
> explicitly says it's for encoding ISO/IEC 10646-1 UCS /
> Unicode characters.
> 
> "UTF-8 encodes UCS characters as a varying number of octets,
> where the    number of octets, and the value of each, depend
> on the integer value assigned to the character in ISO/IEC
> 10646..." [RFC 3986]

Then make it clear --much more clear than I think the simple
citation in your Section 4 implies -- that you are using a
specific definition.  There are others, equally authoritative.
Note too that the statement in 3986 says "encodes UCS
characters", not that the coding system cannot encode anything
else.

FWIW, I'd need to go back and check exactly what they say and
how they say it, but, after years of insisting on references to
ISO 10646 rather than Unicode, the IETF is now normally using
Unicode references.  That is, in part, because 10646 changes
more slowly but, more important, because "Unicode" normatively
includes properties and definitions that have become important
to us, which the ISO / IEC Standard does not.  IIR, many
versions of ISO/IEC 10646 did not even define/standardize the
collection of Unicode encoding forms.  Similarly, the term UCS-2
(from your later note) is obsolescent and has probably (again,
I'd have to check and am not going to do it at this hour) been
formally depreciated.  If you must refer to the first 65535 code
points in Unicode / 10646 (a restriction that RFC 3986 does not
make), the preferred terminology is "Basic Multilingual Plane
(BMP)" because there is no separate Standard or Part of a
Standard for that subset of the Unicode / 10646 repertoire and,
btw, it has always been a little ambiguous as to whether the
surrogate-introducing code points were part of UCS-2 or not
since they are invalid (create nonsense) if mechanically encoded
into UTF-8 or UTF-32.

But that was the point of my first note in this thread.  The
original form of your statement was, I believe, correct (if it
was what you intended to say).  It was also confusing to people
with at least a moderate amount of knowledge (e.g., had seen the
term "UTF-8" before, who might start thinking in terms of
Windows code pages, or who remembered when character coding for
the web was defined in terms of ISO/IEC 8859-1 or 8859-9) who
were reading quickly through the text rather that looking up and
checking every reference, a group that included myself and
presumably Dave.  I decided to step in because it looked to me
as if you and Dave were heading in a direction of confusing each
other further as the later discussion of whether it was
appropriate to require [Unicode and] UTF-8 seemed to illustrate.
The terminology around these character coding and i18n issues
can confuse people very easily; I think it is worth putting in a
bit of extra effort to be super-clear and precise if you are
going to use that vocabulary in a context in which it makes a
difference, as it does, or at least appears to do, here.

  best,
    john

    john

---

From: Matthew Kerwin <[email-masked]>
Date: Wed, 23 Nov 2016 19:19:29 +1000

For those playing along, if any still are:

> > on the integer value assigned to the character in ISO/IEC

​Sorry, typo, I meant RFC 3629 (i.e. STD 63, our UTF-8 standard.)
​

> specific definition.  There are others, equally authoritative.
​I realise that I should probably make STD 63 a normative reference, since
it's at the pointy end of a 'SHOULD' requirement.  That doesn't address the
request for more words, though.  I'll try to think of a way to make it
clear that my "UTF-8" also means Unicode.​

> formally depreciated.

​Yeah, that was another typo, I meant UCS (the repertoire), not UCS-2 (the
encoding.)  I call it "UCS" rather than "the Unicode character repertoire"
because it's shorter, and because that's what STD 63 uses.  If the
differences are important enough, I'll try to use "Unicode" more from now
on.​

> was what you intended to say).

​Well, that was the real question: how did everyone who didn't object to
the text interpret it?

Cheers

---

From: t.petch <[email-masked]>
Date: Thu, 24 Nov 2016 10:47:56 +0000

----- Original Message -----
From: "Matthew Kerwin" <[email-masked]>
To: "John C Klensin" <[email-masked]>
Cc: "Alexey Melnikov" <[email-masked]>; "Dave Crocker"
<[email-masked]>; <[email-masked]>
Sent: Wednesday, November 23, 2016 9:19 AM

<snip>

<tp>
Since we have been here a hundred times before, I assumed that it was
the same as those hundred times, such as

               In
       particular, non-ASCII characters MUST first be encoded according
       to UTF-8 [STD63], and then each octet of the corresponding UTF-8
       sequence MUST be percent-encoded to be represented as URI
       characters.
[RFC6068]

Tom Petch

Cheers

------------------------------------------------------------------------
--------

> _______________________________________________
> art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/art
>