Re: Fwd: I-D Action: draft-ietf-iri-4395bis-irireg-03.txt

(comments are more to the authors (and everybody) than specifically to 
Mykyta)

On 2011/08/01 16:14, Mykyta Yevstifeyev wrote:
> Hello,
>
> I understand there is no support for my proposition, so I don't insist
> any more. As I've already mentioned, I'm not opposed to its publication,
> and I'd like to comment it, then.
>
> Section 1:
>
>> [RFC3987] introduced IRIs by defining a mapping
>> between URIs and IRIs; [RFC3987bis] updates that definition, allowing
>> an IRI to be interpreted directly without translating into a URI.
>
> I actually don't see RFC 3987 requiring an IRI to be translated to URI
> under any circumstances. Current implementations of IRIs, under RFC
> 3987, work perfectly without mapping any IRI to URI.

Yes indeed.

> So I think this
> statement should be changed to:
>
>> [RFC3987] introduced IRIs by extending the characetr range allowed
>> for URIs from ASCII to Universal Characetr Set (UCS); [RFC3987bis]
>> updates that definition to suit IRIs' current usage.

On top of this change, I think this should be rewritten so as not to 
depend on RFC3987bis. It should just mention RFC3987, and the RFC editor 
will update this to the newest spec depending on which spec gets done by 
what date.

This goes back to Marc's question:
- is this document really normative to draft-...3987bis which is not yet 
finished and may change?
(which I think should actually read "is 3987bis really normative to this 
draft")
I haven't checked carefully enough yet, but I think if the IETF works 
under the theory that references to 'obsoleted by' documents 
automatically get tweaked to actually reference the obsoleting document, 
then we can just reference RFC3987 and should be able to move ahead. If 
it's not clear under what theory the IETF works, then we probably have 
to say "RFC 3987 or its successor".


> Ibid:
>
>> reserving the
>> term "URN" explicitly for those URIs/IRIs using the "urn" scheme name
>> ([RFC2141]).
>
> RFC 2141 doesn't allow 'urn' IRIs, not they exist at all. I propose the
> following correction: OLD: "URIs/IRIs", NEW: "URIs".

RFC 2141 indeed doesn't currently allow 'urn:' IRIs. But likewise, the 
HTTP spec doesn't currently allow 'http:' IRIs. Nevertheless, they get 
used. Actually, the situation is better for urn: IRIs, because RFC 2141 
is very clear that non-ASCII characters in urn: URIs have to be 
percent-encoded using UTF-8, whereas HTTP leaves this open. So in this 
sense, an urn: IRI is not a problem at all.


> Section 3.1:
>
>> New URI/IRI schemes SHOULD
>> have clear utility to the broad Internet community, beyond that
>
> I don't understand use of "SHOULD" here. From RFC 2119:
>
>> 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
>> may exist valid reasons in particular circumstances to ignore a
>> particular item, but the full implications must be understood and
>> carefully weighed before choosing a different course.
>
> What are such "valid reasons"? I suppose you should use here "MUST" or
> "must", but not "SHOULD". This is a requirement, not a recommendation.

I think there has been a strong argument that making the requirements 
too strict will result in the registry not reflecting reality. It may be 
perfectly okay to register an URI/IRI scheme that has utility only to a 
limited part of the Internet community.

> Section 3.2:
>
>> <absolute-URI> grammar described in [RFC3987bis].
>
> Maybe <absolute-IRI>? Ibid:
>
>> Schemes that do not
>> contain a conformant hierarchical structure in their<scheme-
>> specific-part> SHOULD NOT use double slashes following the
>> "<scheme>:" string.
>
> I don't recall the <scheme-specific-part> production either in RFC 3986,
> RFC 3987 or RFC 3987bis. Maybe you meant <hier-part>/<ihier-part>?
>
> Section 3.8:
>
>> Organizations that desire a private name space for URI scheme names
>> are encouraged to use a prefix based on their domain name, expressed
>> in reverse order. For example, a URI scheme name of com-example-info
>> might be registered by the vendor that owns the example.com domain
>> name.
>
> Do we actually need this? I have never even heard of any attempts to
> register such scheme.

Is this new or old? Anyway, if it doesn't cause problem, I guess we can 
keep it, just in case.

> Section 4:
>
>> (In the
>> unfortunate case that there are multiple, different uses of the
>> same scheme name, the IESG may approve a request to modify an
>> existing entry to note the separate use.)
>
> I don't really think this may be necessary (probably for the sake of
> robustness, but...). Maybe I'm wrong, but I don't know whether there are
> some schemes which have different usage.

There is at least one case where there was a collision. I seem to 
remember the scheme name started with an 'm' and had three letters. I 
guess Ted Hardie should remember.

> Section 5:
>
>> Any scheme that is no longer in common use MAY be designated as
>> historical
>
> I suppose "SHOULD" is more appropriate here. But RFC 2119 might also be
> inappropriate to be used here as well, and "should" may be OK as well.
>
> Section 6.2, bullet 2:
>> The
>> template may also be submitted in some other form (as part of
>> another document or as a stand-alone document), but the contents
>> will be treated as an "IETF Contribution" under the guidelines of
>> [RFC3978].
>
> RFC 3978 was obsoleted by RFC 5378.
>
> Section 6.3:
>
>> In cases where the original
>> definition of the scheme is contained in an IESG-approved document,
>> update of the specification also requires IESG approval.
>
> I suppose you should have clearly mentioned that the Standards Track
> document MUST have IESG as the change controller
>
> Section 6.4:
>
>> Author/Change controller:
>> Person (including contact information) authorized to change this,
>> if a provisional registration.
>
> I's like you dropped "if a provisional registration", as the
> registration may also be changed if it is a permanent one.
>
> Section 11.1. Why do you reference RFC 3987 normatively? At the time the
> document is published RFC 3987bis will also have been published. I don't
> see the reason for making RFC 2141 normative reference as well.
>
> Some general comments. Where you point to specific URI schemes, it may
> be useful to refer to corresponding documents. I recall there are 'mid',
> 'ftp' and 'telnet' schemes mentioned there.
>
> The document should be clear regarding what the "scheme" means. I mean
> (sorry for pun) that the "scheme" may refer to the URI/IRI's part; it
> may also refer to the "model" of a particular URI, eg. its specification
> - syntax and semantics.
>
> The proposal to Section 3.8, "Scheme Name Considerations". I think the
> document should prescribe that the ":" character should not occur in URI
> scheme name, as eg. in RFC 6196. This is incorrect; the justification
> may be found in Erratum report #2756
> (http://www.rfc-editor.org/errata_search.php?eid=2756).

I think this is a minor detail. In spec text, it may help to use the 
trailing colon instead of quotes or so. I don't think there is any 
chance for people confusing thigs (e.g. ending up with two consecutive 
colons or some such).


> Regarding Section 6.4, registration template. Won't this be useful to ad
> a new field "registration information" with the contents as for URN
> namespaces (http://tools.ietf.org/html/rfc3406#appendix-A)?

This has:
    Registration Information:

       This is information to identify the particular version of
       registration information:

       -  registration version number: starting with 1, incrementing by 1
          with each new version
       -  registration date: date submitted to the IANA, using the format
          outlined in [ISO8601]:

             YYYY-MM-DD

I think this is overkill. The URN people are much more formalistic. The 
IANA should have all the necessary info on file if it's ever needed.

> The document should be clear that its recommendations don't have
> retroactivity; those RI schemes which weren't suited to IRIs, as being
> registered before it, shouldn't be used with IRIs.

The details of this are discussed in RFC 3987, so I'm not sure how much 
we need here. Essentially, for a scheme that doesn't allow %-encoding, 
or allows %-encoding, but not based on UTF-8, IRIs will look exactly the 
same as URIs, so it's not possible to say that such schemes should not 
be used with IRIs.

Regards,   Martin.

Received on Monday, 1 August 2011 09:50:30 UTC