Date: Tue, 22 Nov 2016 22:58:05 -0500
From: John C Klensin <john-ietf@jck.com>
To: Matthew Kerwin <matthew@kerwin.net.au>, Dave Crocker <dcrocker@bbiw.net>
Message-ID: <88A3D1C42786D208F18ED079@JcK-HP8200>
In-Reply-To: <CACweHNAHJBGOrpE=G-ZU9vOVe3eti_9JPQ0mCOM1Yhfoc2E0rw@mail.gmail.com>
References: <2ed4e7c7-6876-6bd1-8ff8-abbd94139336@isode.com>
 <CACweHNCu+-mN1+Ry15Xdakt+DFS2Bzx5gQ1mAa5_DMiuDzhiwg@mail.gmail.com>
 <dc452593-3e84-04b0-a5b5-53f07453ff98@dcrocker.net>
 <CACweHNDdDi_8vd7gG=eZTwBbJ0Lkn+O=j4XdqRDh88-=EQXssA@mail.gmail.com>
 <6e9ffa5e-47b6-95aa-5807-c8f7a7cd6c24@dcrocker.net>
 <CACweHNAHJBGOrpE=G-ZU9vOVe3eti_9JPQ0mCOM1Yhfoc2E0rw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/art/WP96TvkED6klsR2rHvdEF5n4A6g>
Cc: Alexey Melnikov <alexey.melnikov@isode.com>,
 Dave Thaler <dthaler@microsoft.com>,
 "General Area Review Team \(gen-art@ietf.org\)" <art@ietf.org>
Subject: Re: [art] AD review of draft-ietf-appsawg-file-scheme-13.txt
Precedence: list



--On Wednesday, November 23, 2016 13:05 +1000 Matthew Kerwin
<matthew@kerwin.net.au> wrote:

> On 23 November 2016 at 12:03, Dave Crocker =
<dcrocker@gmail.com>
> 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.

>...
> =E2=80=8BActually 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.
>=20
> 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 "=E2=84=A2" (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. =20

> but it could matter for windows-1252
> (which is.) It's a question of whether "
> %C3%83" means "
> =C3=83" or "=C3=83=C6=92=E2=80=8B
> "

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