Re: [apps-discuss] Fwd: FW: New Version Notification for draft-kerwin-file-scheme-13.txt

[Sam Ruby <[e-mail]>]

On 01/10/2015 06:13 PM, Sean Leonard wrote:
> On 1/10/2015 1:05 PM, Sam Ruby wrote:
>>
>> Permit me to introduce myself.  I'm one of the co-chairs of the W3C
>> HTML Working group.  I am indeed aware of this work.
>
> Pleased to meet you!

Likewise!

> [various other text]
>
> I believe that the relevant prompting text is:
> ---
> I'm working on a specification how strings that can found in the href
> attribute of HTML elements like <link>, <base>, and <a>.  Some of
> those strings may start with "file:".
>
> I think it would be a good idea for us to explore whether there is a
> relationship between those strings and RFC 3986.  I'll go further and
> state that it is in nobody's best interest for there to be overlapping
> and conflicting standards in this area.
> ---
>
> Let us agree that RFC 3986 === "URI". A URI is supposed to be made up of
> characters *entirely within* the repertoire I previously posted (taken
> from RFC 3986).

Let's not.  I believe that there needs to be a RFC 3986bis created, and 
therefore a Working Group chartered.

As a concrete example, I believe that the repertoire of characters 
available for fragment identifiers should be expanded.

And related to the original discussion, domains containing Unicode 
characters do now exist, and IDNA specifies the mapping of those 
characters to the set of characters that RFC 3986 allows.  RFC 3986 
needs to be updated to cover this.

> The issue at hand is that a lot of software uses Unicode, and in
> particular, there are protocol slots and data entry fields that are
> labeled "URI" or "URL" in some fashion, but do not limit themselves to
> the RFC 3986 repertoire. I.e., in <a href=""> etc. you can have Unicode
> characters, so the question is, what should you do with them?
>
> That is a very interesting question and one that I do not particularly
> care to wade into. So, I guess I am sidestepping the prompt. :)
>
> But the subject of this thread is about registering the file: URI scheme
> under the current rules in force, which are RFC 3986 and RFC 4395. (And,
> I suppose, RFC 3987.)
>
> So it seems to me that the first and "most important" part of
> draft-kerwin-file-scheme should clearly state how file: URIs work,
> according to the character repertoire permitted by RFC 3986.

This very question changes when the possibility of a RFC 3986bis enters 
the discussion.

> Then if the author wants to get into the other issues, i.e., dealing
> with the presence of non-URI characters (including Unicode characters
> that keep the string following IRI), that can be done in a subsequent
> section. (Which can be a "normative" section of the main text, if we can
> get agreement on all of that.)
>
> Note that RFC 4395 says:
>
>       2.6 <http://tools.ietf.org/html/rfc4395#section-2.6>.
>       Internationalization and Character Encoding
>
>     When describing URI schemes in which (some of) the elements of the
>     URI are actually representations of human-readable text, care should
>     be taken not to introduce unnecessary variety in the ways in which
>     characters are encoded into octets and then into URI characters; see
>     RFC 3987  <http://tools.ietf.org/html/rfc3987>  [6
> <http://tools.ietf.org/html/rfc4395#ref-6>] andSection 2.5 of RFC 3986
> <http://tools.ietf.org/html/rfc3986#section-2.5>  [5
> <http://tools.ietf.org/html/rfc4395#ref-5>] for guidelines.  If URIs
>     of a scheme contain any text fields, the scheme definition MUST
>     describe the ways in which characters are encoded, and any
>     compatibility issues with IRIs of the scheme.
>
> ******
>
> The text says not to introduce "unnecessary variety", but in the file:
> case, maybe some variety is natural and therefore necessary.

I actually would argue that the advice RFC 4395 provides be followed. 
And that's precisely why IDNA is relevant here.

> Sean

- Sam Ruby