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

Taken Larry's message into account, I'll enter these issues in the issue 
tracker right now.  Mykyta

01.08.2011 10: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.  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 Sunday, 14 August 2011 09:09:30 UTC