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

From: [email-masked]
Date: Tue, 22 Apr 2014 21:33:27 -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-04.txt
	Pages           : 8
	Date            : 2014-04-22

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

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

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: Andrew Newton <[email-masked]>
Date: Wed, 23 Apr 2014 08:28:15 -0400

I have read this draft and am generally supportive of it. Many of the
issues have been resolved.

I do have one question. Section 2.3 constrains applications (in the
all other specifications category) from constraining paths with MUST
NOT. Section 2.4 constrains query components with applications with
SHOULD NOT. Why the difference since the harm from doing both is the
same? In my opinion, Section 2.3 should place applications at the
SHOULD NOT compliance level.

-andy

On Wed, Apr 23, 2014 at 12:33 AM,  <[email-masked]> wrote:
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: "John Levine" <[email-masked]>
Date: 26 Apr 2014 17:02:23 -0000

>SHOULD NOT compliance level.

I completely agree.  There are all sorts of applications, with all sorts
of reasons to design them in various ways.

Also, although I know I've lost this argument, I want to put it on the
record again: slavish adherence to this rule will lead to situations
where the protocol documented in the RFC is not the one that people
actually implement.  In WEIRDS, where we've had lengthy arguments
about it, it's quite clear that everyone will use the same URL
structures.  The big players already do, the small players will use
the free server software that ICANN has commissioned.  So in practice,
if you set up a server with different URL structures, it won't work
because a lot of clients will skip the template lookups and will
expect that the URLs that work with everyone else will work with you.

One option is to rail against how stupid the client implementers are.
The other is to document what you have to do to interoperate.

R's,
John