Subject: Re: [apps-discuss] [IANA #812412] Expert Review - draft-ietf-appsawg-uri-scheme-reg-04

From: Dave Thaler <[email-masked]>
Date: Thu, 2 Apr 2015 19:01:50 +0000

Thanks for the review.  Below is what the co-authors did in response in -05:

> -----Original Message-----
> From: Pearl Liang via RT [mailto:[email-masked]]
> Sent: Monday, March 16, 2015 10:59 AM
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: [IANA #812412] Expert Review - draft-ietf-appsawg-uri-scheme-reg-04
> 
> Dear Authors,
> 
> Upon review, Graham Klyne has approved the requested new URI scheme and
> raised some comments and question:
> 
> ...
> 
> I'm also taking this opportunity to review the current version and make some
> final comments. These are pretty much all editorial, and I'm assuming they
> could be addressed (or not) in any AUTH48 period without requiring further
> public review.
> 
> 
> Section 3.
> 
> "For IETF Standards-Track documents, Permanent registration status is
> REQUIRED."
> Reading this now, I find the drafting here is potentially confusing. Suggest:
> 
> "For URI schemes defined or normatively referenced by IETF Standards-Track
> documents, Permanent registration status is REQUIRED."

This was the subject of the rest of this thread, with comments from the AD,
the doc shepherd, co-authors, and other WG participants.

We thought the concensus was to accept this and so made the change.
(I see this discussion continues regarding -05...)

> Section 3.3
> 
> "Schemes that are not intended to be used as locators SHOULD describe how
> the
> resource identified can be determined or accessed by software that obtains a
> URI
> of that scheme."
> 
> This doesn't seem quite right to me. Schemes that are not intended to be
> used
> as locators aren't generally expected to be accessed by software (though they
> may be in particular circumstances).
> 
> I think then point that needs to be made here is that there should be some
> defined structure of naming authority for the scheme, which is not necessarily
> interpretable by software. E.g., something like:
> 
> "Schemes that are not intended to be used as locators SHOULD describe how
> the
> resource identified can be determined or accessed by an agent that obtains a
> URI
> of that scheme."

The term "agent" is undefined and as co-authors we think the statement was
more correct as is.  In any case, the language here is unchanged from RFC 4395,
and so was kept as it appeared in RFC 4395, lacking consensus to change.

> Section 7.2:
> 
> " 8. Once Expert Review approves registration for a given status, IANA
> adds the registration to the registry."
> 
> I note that the scheme has already been added to the registry at prior step 3.
> 
> Suggest:
> 
> " 8. Once Expert Review approves registration for a given status, IANA
> updates the registration (per step 3) to indicate the approved status. "

Done.
 
> Section 8:
> 
> I was somewhat thrown by the heading of section 8.1.
> 
> "8.1. "Example" Scheme Registration Request"
> 
> I think the intent would be clearer if the section title were given as:
> 
> "8.1. "Example" Scheme Registration Template"

Not done.  The term "template" is defined in section 2 as being the
(unfilled) form.   The term "registration request" is defined in the doc
as being the completed form that gets submitted.  Tweaked wording
of section 2 to make this even more clear.

> - Regarding the Pending Review Status:
> 
> Section 7.2, a step 3 said:
> 
> 3. Otherwise, IANA enters the registration request in the IANA
> registry, with status marked as "Pending Review" and the
> remainder of this section applies.
> 
> Question: Shall IANA remove the "Pending Review" URI scheme from the
> registry
> if a new 'requested' permanent URI scheme is not being accepted after DE
> reviewed (step 4/5)?  Or it is okay to keep the Pending Review entry in the
> such status
> as long as it is under "additional review or discussion"?
> 
> The scheme may not be approved for its requested status. If not accepted, I
> imagine would would revert to "provisional" status (which does not require
> approval if it meets the minimal criteria set out). But I agree that this
> should probably be clarified.

The intent was that if it is rejected, then it no longer appears in the registry
(same as if a rejection happened with RFC 4395, no change intended).  
Updated point 8 of the process to explicitly state this.

Dave

---

From: Dave Thaler <[email-masked]>
Date: Thu, 2 Apr 2015 19:01:50 +0000

Done.

Dave

---

From: "Pearl Liang via RT" <[email-masked]>
Date: Thu, 02 Apr 2015 20:39:32 +0000

Dave,

I've forwarded Graham's comments for version -05 in the Evaluation ticket
under an IANA ticket #815901.  Did you receive that message?

Thanks,
~pl