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

01.08.2011 12:49, "Martin J. Dürst" wrote:
>> 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".

I agree here.  I suppose the editors will find the appropriate 
formulation to reflect this.

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

But we have never seen any evidence of 'urn' IRIs; I suppose this issue 
will be under consideration of URNBIS WG.

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

Well, but RFC 2119 language isn't appropriate here; and "should" will be 
OK to reflect what you've said.

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

This was present in RFC 4395.  However, the recommendation was never put 
into action.  Eg., Microsoft submitted a request to register 3 schemes 
for use with MS .NET Message Framing Protocol 
(http://www.ietf.org/mail-archive/web/uri-review/current/msg01310.html), 
and these URIs made use of names "net.msmq", "net.tcp" and "net.pipe" 
instead of "com-microsoft-net.msmq" etc.

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

I'm not opposed strongly to inclusion of this regulation, though.

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

Well, but at least I personally can't stand such notation :-)  I 
suppose, to be RFC 3986-compliant, such regulation should be added.

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

Let's leave this to the editors to decide.

Mykyta

>
> Regards,   Martin.
>

Received on Monday, 1 August 2011 16:30:51 UTC