Re: reviewing draft-weber-iri-guidelines-00

On 7/6/2011 2:58 AM, Mykyta Yevstifeyev wrote:
> However, as per RFC 3986, it isn't valid to identify the "user:pass"
> part in URIs (and IRIs) for all schemes, as well as the only user name,
> if, as you assume, no ":' is present. It is only possible when handling
> an IRI in scheme-specific manner, eg. 'ftp' URIs/IRIs. Some schemes may
> also define authentication information part, such as 'pop' URIs/IRIs
> (RFC 2384), which would be assumed to be a username under your algorithm.
>

Fixed.

> There are a number of occurrences of "relative reference" whereas it
> says nothing about processing relative IRIs. If rules of RFC 3986 are
> used, this should be mentioned.
>

Defined.

> Section 6.4 is going to specify the scheme-specific processing of 'file'
> URIs, which are not properly specified. I recall some discussions on
> file URIs in the end of 2010 on URI@w3c.org, which is the most current.
> There had been a number of such discussions before. A number of
> complexities were identified, which almost make impossible specifying
> the scheme. Considering this, I recommend to skip this section.
>

I see.  It's been brought up here before that we should consider the 
file scheme for specific handling rules. 
<http://lists.w3.org/Archives/Public/public-iri/2011Jun/0138.html> 
Though maybe doing so would be arbitrary, or based on lots of testing, 
reverse engineering, and observation...

> Section 6.5 is almost in the same situation. I'm currently working on
> 'ftp' URI scheme specification
> (https://datatracker.ietf.org/doc/draft-yevstifeyev-ftp-uri-scheme/). So
> there will probably be a need to align these two drafts; however,
> currently the ftp URI draft has no provisions regarding ftp IRIs,
> allowance of UCS chars in ftp *RIs. This may probably be addressed in
> the further versions of the draft; but until the ftp URI scheme isn't
> properly specified by RFC I don't see sense in making up the
> scheme-specific IRI parsing for such *RIs.

Removed.

>
>  From Section 7.1: I find confusing the following sequence: (1)
> precent-encode -> (2) UTF-8 encode -> (3) percent-encode {fpr the 2nd
> time!}. I suppose everything percent-encoded is already allowed in URIs,
> so 1st "percent-encode" should be skipped and the following sequence
> should be formed: (1) UTF-8 encode -> (2) percent-encode chars which are
> not allowed in particular URI part within such part.

Good point!  Fixed.

>
> Several minor/editorial/non-substantial comments. (1) All ABNF
> production should be enclosed in "<" and ">", as recommended by RFC
> 5234. (2) Should your draft update RFC 3987 (or RFC 3987bis)? (3)
> References to IDNA and punycode specifications are missing in Section
> 5.2.2. (4) I suppose RFC 3987bis should be normative reference in the
> draft. (5a) There is no explanation of U+HHHH notation used in your
> document. Even though it's considered that the reader is familiar with
> it, clarifying won't be extra. (5b) Moreover, RFC 5137, BCP 137 did
> officially recommend to use \u'HHHH'. (6) The references are not in the
> common format (even though we may leave this issue to RFC Editor).
>
> I hope my comments were useful.
>
> Thanks,
> Mykyta Yevstifeyev
>>

Very helpful thanks much.

-Chris

Received on Monday, 11 July 2011 23:03:55 UTC