Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-uri-get-off-my-lawn-02.txt

From: [email-masked]
Date: Wed, 02 Apr 2014 21:20:55 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Applications Area Working Group Working Group of the IETF.

        Title           : URI Design and Ownership
        Author          : Mark Nottingham
	Filename        : draft-ietf-appsawg-uri-get-off-my-lawn-02.txt
	Pages           : 8
	Date            : 2014-04-02

Abstract:
   RFC3986 Section 3.1 defines URI syntax as "a federated and extensible
   naming system my 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
   standards that mandate particular forms of URI substructure is
   inappropriate, because the effectively usurps ownership.

   This document is intended to prevent this practice (sometimes called
   "URI Squatting") in standards, but updating RFC3986 to indicate where
   it is acceptable.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-appsawg-uri-get-off-my-lawn/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-appsawg-uri-get-off-my-lawn-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-uri-get-off-my-lawn-02

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Graham Klyne <[email-masked]>
Date: Thu, 03 Apr 2014 10:19:45 +0100

Hi,

The abstract quote appears to be garbled.

Section 2.2

"all other specifications MUST NOT constrain, define structure or semantics for 
URI authorities" appears to be at odds with section 1.,1 final para.  This 
appears to prohibit a specification that assigns a part of, say, iana.org space 
form use as a registry, something allowed at 1.1.

Maybe just add something like "except as allowed by section 1.1" or "except to 
the extent that a specification allocates elements of a URI space owned by the 
specification owner or publisher"?

Hmmm... reading ahead, I see this might be a recurring issue.  It's the "all 
other specifications" that tweaked by antennae here.

The term "Applications" used in section 1.1 is one I find I can read in two 
different ways:
- a specification for a general type of application, which is what I think you 
mean (e.g. webfinger).
- a specification for a particular instance or limited deployment of some 
application, such as was previously specified for the use of HTTP in WEIRDS. 
(That in particular seems to be a boundary case whose status would usefully be 
clear in this proposal.)

#g
--

On 03/04/2014 05:20, [email-masked] wrote:
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 7 Apr 2014 16:23:54 +1000

On 3 Apr 2014, at 8:19 pm, Graham Klyne <[email-masked]> wrote:

> Section 2.2
> 
> "all other specifications MUST NOT constrain, define structure or semantics for URI authorities" appears to be at odds with section 1.,1 final para.  This appears to prohibit a specification that assigns a part of, say, iana.org space form use as a registry, something allowed at 1.1.

Yes. The IANA loophole is a very small one; IANA effectively delegates control of portions of its URI space to IETF specifications. That is not common, obviously (and may be unique?).

> Maybe just add something like "except as allowed by section 1.1" or "except to the extent that a specification allocates elements of a URI space owned by the specification owner or publisher"?

I think that will cause more confusion than it resolves; the second proposal in particular could be misunderstood.

> Hmmm... reading ahead, I see this might be a recurring issue.  It's the "all other specifications" that tweaked by antennae here.
> 
> The term "Applications" used in section 1.1 is one I find I can read in two different ways:
> - a specification for a general type of application, which is what I think you mean (e.g. webfinger).
> - a specification for a particular instance or limited deployment of some application, such as was previously specified for the use of HTTP in WEIRDS. (That in particular seems to be a boundary case whose status would usefully be clear in this proposal.)

Both are in-scope here.

Cheers,

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