Subject: [apps-discuss] Last Call: <draft-ietf-appsawg-uri-get-off-my-lawn-04.txt> (URI Design and Ownership) to Best Current Practice

From: The IESG <[email-masked]>
Date: Wed, 23 Apr 2014 05:44:20 -0700

The IESG has received a request from the Applications Area Working Group
WG (appsawg) to consider the following document:
- 'URI Design and Ownership'
  <draft-ietf-appsawg-uri-get-off-my-lawn-04.txt> as Best Current
Practice

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2014-05-07. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   RFC3986 Section 1.1.1 defines URI syntax as "a federated and
   extensible naming system wherein each scheme's specification may
   further restrict the syntax and semantics of identifiers using that
   scheme."  In other words, the structure of a URI is defined by its
   scheme.  While it is common for schemes to further delegate their
   substructure to the URI's owner, publishing independent standards
   that mandate particular forms of URI substructure is inappropriate,
   because that essentially usurps ownership.  This document further
   describes this problematic practice and provides some acceptable
   alternatives for use in standards.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-appsawg-uri-get-off-my-lawn/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-appsawg-uri-get-off-my-lawn/ballot/

No IPR declarations have been submitted directly on this I-D.

---

From: S Moonesamy <[email-masked]>
Date: Fri, 25 Apr 2014 17:15:39 -0700

Hi Mark,
>[email-masked] mailing lists by 2014-05-07. Exceptionally, comments may be

In Section 2:

   "This section updates [RFC3986] by setting limitations on how other
    specifications may define structure and semantics within URIs."

I gather that this means that the updates apply to Sections 3.2, 3.3 
and 3.4 of RFC 3986.  I could not tell whether 3.1 of RFC 3985 is 
also included in the update.

In Section 2.1:

   "However, applications SHOULD NOT preclude the use of other URI
    schemes in the future, unless they are clearly specific to the
    nominated schemes."

Could you please explain the "SHOULD NOT"?

   "A specification that defines substructure within a URI scheme MUST do
    so in the defining document for that URI scheme, or by modifying
    [RFC4395]."

RFC 4395 is about guidelines and registration procedures.  Why is 
there a requirement to modify that BCP when defining substructures 
within a URI scheme?

Regards,
S. Moonesamy

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 28 Apr 2014 17:10:08 +1000

On 26 Apr 2014, at 10:15 am, S Moonesamy <[email-masked]> wrote:

> I gather that this means that the updates apply to Sections 3.2, 3.3 and 3.4 of RFC 3986.  I could not tell whether 3.1 of RFC 3985 is also included in the update.

It updates 3986 in the sense that it explains appropriate use of the structures defined therein. What practical affect does the section-by-section applicability have?

> Could you please explain the "SHOULD NOT”?

I define the standard for Foo, which allows widgets to be orchestrated by giving them URIs. I might define how to do so over HTTP using HTTP URIs, but I shouldn’t say “You MUST NOT use any other URI scheme than HTTP."

> RFC 4395 is about guidelines and registration procedures.  Why is there a requirement to modify that BCP when defining substructures within a URI scheme?

Because when you define substructure in the URI scheme (a la “foo+”, as currently being discussed), the registration procedure needs to know about it.

Cheers,

--
Mark Nottingham   http://www.mnot.net/

---

From: Larry Masinter <[email-masked]>
Date: Mon, 28 Apr 2014 07:28:55 +0000

> > RFC 4395 is about guidelines and registration procedures.  Why is there a
> requirement to modify that BCP when defining substructures within a URI
> scheme?
> 
> Because when you define substructure in the URI scheme (a la "foo+", as
> currently being discussed), the registration procedure needs to know about it.

Reference [BCP115] rather than [RFC4395].   This working group has
 http://tools.ietf.org/html/draft-ietf-appsawg-uri-scheme-reg-00
scheduled for Dec 2014. You can't 'modify' RFC 4395 anway.

Larry
--
http://larry.masinter.net

---

From: S Moonesamy <[email-masked]>
Date: Mon, 28 Apr 2014 01:03:43 -0700

Hi Mark,
At 00:10 28-04-2014, Mark Nottingham wrote:
>It updates 3986 in the sense that it explains appropriate use of the 
>structures defined therein. What practical affect does the 
>section-by-section applicability have?

I am not asking for a section-by-section update.  It is about the 
reader understanding what has been changed in RFC 3986.

There is STD 66, which may include RFC 6874 if the IETF ever gets the 
documents together.  In some near future the IETF might publish BCP 
XXX (this document).  This is where one could ask "why is this a BCP?".

>I define the standard for Foo, which allows widgets to be 
>orchestrated by giving them URIs. I might define how to do so over 
>HTTP using HTTP URIs, but I shouldn't say "You MUST NOT use any 
>other URI scheme than HTTP."

I was not arguing for "MUST NOT". :-)  The above is good enough for 
me to understand the meaning of that text.

>Because when you define substructure in the URI scheme (a la "foo+", 
>as currently being discussed), the registration procedure needs to 
>know about it.

Larry commented about the above.  I'll look at this as a working 
group question.  The working group has this draft and is also working 
on draft-ietf-appsawg-uri-scheme-reg-00.   I am okay with not 
delaying your work as waiting until next year to get that done is not 
encouraging.  I would ask how does all this fit.

Regards,
S. Moonesamy

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 28 Apr 2014 20:48:00 +1000

On 28 Apr 2014, at 6:03 pm, S Moonesamy <[email-masked]> wrote:

> I am not asking for a section-by-section update.  It is about the reader understanding what has been changed in RFC 3986.
> 
> There is STD 66, which may include RFC 6874 if the IETF ever gets the documents together.  In some near future the IETF might publish BCP XXX (this document).  This is where one could ask "why is this a BCP?”.

I’m having trouble parsing this… what are you suggesting?

>> I define the standard for Foo, which allows widgets to be orchestrated by giving them URIs. I might define how to do so over HTTP using HTTP URIs, but I shouldn't say "You MUST NOT use any other URI scheme than HTTP."
> 
> I was not arguing for "MUST NOT". :-)  The above is good enough for me to understand the meaning of that text.
> 
>> Because when you define substructure in the URI scheme (a la "foo+", as currently being discussed), the registration procedure needs to know about it.
> 
> Larry commented about the above.  I'll look at this as a working group question.  The working group has this draft and is also working on draft-ietf-appsawg-uri-scheme-reg-00.   I am okay with not delaying your work as waiting until next year to get that done is not encouraging.  I would ask how does all this fit.

I’ll respond to Larry.

Cheers,

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 28 Apr 2014 20:48:30 +1000

On 28 Apr 2014, at 5:28 pm, Larry Masinter <[email-masked]> wrote:

> scheduled for Dec 2014. You can't 'modify' RFC 4395 anyway.

Makes sense to me.

Thanks,

---

From: S Moonesamy <[email-masked]>
Date: Mon, 28 Apr 2014 05:40:56 -0700

Hi Mark,
>I’m having trouble parsing this… what are you suggesting?

I am suggesting finding out why the draft is 
intended as a BCP and then seeing whether the "Updates:" is needed.

Regards,
S. Moonesamy