Re: [urn] Alissa Cooper's Discuss on draft-ietf-urnbis-rfc2141bis-urn-21: (with DISCUSS and COMMENT)

[Alissa Cooper <[e-mail]>]

> On Mar 1, 2017, at 8:21 PM, Peter Saint-Andre <[e-mail]> wrote:
> 
> Hi Alissa, thanks for your input.
> 
> On 3/1/17 8:11 AM, Alissa Cooper wrote:
>> Alissa Cooper has entered the following ballot position for
>> draft-ietf-urnbis-rfc2141bis-urn-21: Discuss
>> 
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>> 
>> 
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>> 
>> 
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-urnbis-rfc2141bis-urn/
>> 
>> 
>> 
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>> 
>> What is the motivation behind specifying the r-component syntax at this
>> point and then recommending against its use until further standardization
>> is complete? Why not specify the syntax when those future standards get
>> written? The current approach just seems like an invitation for people to
>> start including r-components in URNs without independent implementations
>> understanding their semantics.
> 
> My perspective is that we don't have the right people involved at the
> IETF (esp. many more members of the information sciences community) to
> undertake work on URN resolution, so it will happen elsewhere (perhaps
> ISO TC 46). However, this was probably our one and only chance to update
> the URN syntax so that others can work on URN resolution, which is why
> we defined the r-component syntax now. Naturally this is less than
> ideal, but we play the hand we're dealt.

Ok. This also seems to be part of the argument John made in his mail, and I get it.

Given the expectations that you state, however, I’m wondering if the expression of the normative requirements might be more prudent if it were phrased more along these lines:

---

OLD
Thus r-components SHOULD NOT be used for actual
   URNs until additional development and standardization work is
   complete, including specification of any necessary registration
   mechanisms.

NEW
Thus r-components SHOULD NOT be used for URNs before their semantics have been standardized.

---

Since the expectation is that the future standardization efforts will take place elsewhere, it doesn’t seem justified to try to constrain those efforts by normatively recommending registry mechanisms or imposing an undefined notion of what it means for future standards to be “complete.” Better to be clear that all this document is doing is specifying syntax and therefore cannot constrain how people decide to use r-components in the future. I also was not sure what an “actual” URN is. 

Thanks,
Alissa

> 
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>> 
>> = General =
>> 
>> I agree with Stephen that this spec seems unnecessarily long.
> 
> I see a few areas where the main portion of this specification (~11500
> words) is significantly longer than the combination of RFC 2141 and RFC
> 3406 (~7100 words):
> 
> 1. Design tradeoffs; this could be moved to an appendix.
> 
> 2. Terminology; given the wrangling over concepts, this was important.
> 
> 3. URI syntax; more precision was needed and r-components were added.
> (Yes, there is some repeated text here, but it was extremely confusing
> to read when an earlier version tried to combine sections.)
> 
> 4. URN equivalence; this now includes more examples and associated
> explanations, which seem helpful.
> 
> 5. URI conformance; this was necessary because RFC 3986 was published
> since RFC 2141.
> 
> 6. URN namespace registration; this was expanded because registrants
> often found the old text confusing.
> 
> IMHO the new specification is *unnecessarily* long.
> 
>> There are a
>> bunch of instances of repeated text in different sections that reference
>> each other. I realize this doc was a negotiated outcome but if doing a
>> streamlining pass is a possibility, it wouldn't hurt IMO.
> 
> Specific suggestions are welcome, and we'll take another look as well.
> 
>> = Section 4.4 =
>> 
>> "Further, all URN-aware applications MUST
>>   offer the option of displaying URNs in this canonical form to allow
>>   for direct transcription (for example by copy-and-paste
>> techniques)."
>> 
>> I know this was in 2141, but it seems needlessly constraining on
>> applications and I would be surprised if every application that is aware
>> of URNs actually does this. 
>> 
>> In general I think it would be preferable to avoid specifying normative
>> requirements about what applications are to display, including the other
>> requirements added to this section that were not in 2141.
> 
> I have no objections to softening that language.
> 
>> = Section 8 =
>> 
>> Agree with Stephen's comment here.
> 
> I'll reply separately to Stephen on this point.
> 
>> = Appendix C =
>> 
>> "Truly experimental usages MAY, of course, employ
>>       the 'example' namespace [RFC6963]."
>> 
>> It seems inappropriate to have normative language in this appendix.
> 
> I suggest changing MAY to can.
> 
> Peter
>