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

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.  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.

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".

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.

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.

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.

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).

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)?

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.

I hope my comments were useful.

Mykyta Yevstifeyev

31.07.2011 9:01, Julian Reschke wrote:
> On 2011-07-31 06:27, Mykyta Yevstifeyev wrote:
>> Hello,
>>
>> I am not opposed to publication of the document, but I still think the
>> approach I proposed
>> (http://lists.w3.org/Archives/Public/public-iri/2011Jun/0097.html) is
>> better. Don't you think so?
>> ...
>
> I don't think so. It's the way how specs should be revised.
>

Received on Monday, 1 August 2011 07:14:53 UTC