Subject: [apps-discuss] comments on draft-ietf-appsawg-uri-get-off-my-lawn-01

From: Andrew Newton <[email-masked]>
Date: Thu, 20 Feb 2014 14:20:57 -0500

Having just read the URI Design and Ownership draft, I have the
following comments:

1) This document provides guidelines on URIs in general, yet some of
the reasoning and advice seems very specific to HTTP URIs. And some of
it seems counter to other URI types. Specifically regarding URNs, this
draft runs counter to how URN namespaces are created. Section 2.3
states that specifications MUST NOT constrain or define structure in
any path segment, yet according to RFC 3986 every part of a URN
following the scheme name is the path of a URN. Given that every URN
namespace specifically identifies its namespace identifier and that
identifier IS part of the URI path of the URN, this advice is
incompatible.

2) As I read this draft, it appears to be aimed at specifications
re-using HTTP (though it is generalized) and therefore providing
guidance on specifications re-using HTTP. Given that BCP 56 is broadly
interpreted as 'use a different port for HTTP', this seems to be
encouraging behavior that is shunned by BCP 56. Therefore, shouldn't
this draft update BCP 56?

3) This draft updates RFC 3986, yet 3986 is a standards track document
whereas this is a BCP document. Is that allowed? This is especially
relevant given the update to 3986 changes URNs (see #1).

4) Section 1.1 exempts IANA. Why? And if the IANA registry is to be
exempted, wouldn't this mean other types of registries could be
exempted? This goes directly to the challenge against the WEIRDS
output. WEIRDS is targeting IP address and domain name registries.

5) Appendix B states that URI templates are one solution to avoiding
the problems given in this draft. Yet URI templates seem to run
counter to the WEBARCH reference used by this draft, specifically
Section 3.5.1 which was called out by this draft. URI templates are a
method for allowing applications to conform to changing URI
paths/queries, yet the advice of Section 3.5.1 is specifically about
the importance of URI persistence.

6) In addition to the above, WEBARCH Section 3.5.0 states
"Dereferencing a URI has a (potentially significant) cost in computing
and bandwidth resources, may have security implications, and may
impose significant latency on the dereferencing application.
Dereferencing URIs should be avoided except when necessary." URI
Templates as a solution cause an additional dereference and therefore
are counter to this advice. While such dereferencing is an engineering
tradeoff, this draft strikes a rigid tone in its advice (and the
application so far on this mailing list amplifies this). If this draft
is to reference an architecture document for the reasons to which its
advice should be adhered, it should not also offer solutions which
violate the architecture document. Or, alternatively, this draft and
its application should be less rigid.

7) Paragraph 2 of Section 1 justifies this draft with the defense of
practices which are not generally held as being good. Use of file type
suffixes for content negotiation is specifically called out in the
WEBARCH reference as something to be avoided. Additionally, there
seems to be a disconnect between excusing packaged software vendors
for the rigidity of their software yet holding specifications
accountable.

8) This draft also makes the suggestion that some servers cannot
adequately comply with the protocols upon which they operate, and
therefore specifications should comply with the practices of this
draft to route around these shortcomings. I do not think it is right
for the IETF to encumber its specifications to alleviate the pain of
shoddy server implementations. And if enough server implementations
have issues with compliance, that really should be a driver to fixing
the base protocol vs adjusting the things built upon it. In other
words, if a significant number of HTTP servers cannot comply with
portions of the HTTP protocol, we should fix HTTP which is the root
cause of the problem.

Overall I think much of the advice in this draft is very useful. I do
think most of the MUST/MUST NOTs are too rigid. In fact, the 2119
language should probably be dropped in most of the places in favor of
providing guidelines, not specific requirements, to future
specification authors. Too much rigidity will cause thrashing during
the IETF processes and will likely not accommodate future scenarios
now unseen.

-andy

---

From: Martin Thomson <[email-masked]>
Date: Thu, 20 Feb 2014 11:32:13 -0800

I think that the idea that this is too HTTP specific may be a fair
call, this being the big ticket item I think:

> identifier IS part of the URI path of the URN, this advice is

I don't think that this is the problem you think it is.  The advice is
that standard X should not override the sovereignty of the owner of a
particular part of URI space.  In the case of URNs, the ownership
arrangement might be such that owners naturally cede some degree of
ownership.

---

From: Andrew Newton <[email-masked]>
Date: Thu, 20 Feb 2014 15:12:47 -0500

> arrangement might be such that owners naturally cede some degree of

That maybe, but not as currently written. And if so, why are URNs the
exception? Can we not allow for other exceptions? Again, this draft
about URI rigidity is too rigid. :)

And can't such an arrangement be said for every protocol? If you wish
to use it, you cede some degree of ownership regarding how the bits
flow across the wire. This draft offers some very good advice to spec
authors especially with regards to being forward looking and being
compatible within shared environments. That being said, it is not
applicable to every situation and spec authors should have some wiggle
room.

-andy

---

From: Martin Thomson <[email-masked]>
Date: Thu, 20 Feb 2014 13:55:15 -0800

> about URI rigidity is too rigid. :)

I didn't mean to imply that URNs are special.  Just that sometimes
"ownership" isn't always as simple as what (I think) you implied
above.

---

From: Andrew Newton <[email-masked]>
Date: Thu, 20 Feb 2014 18:11:19 -0500

On Thu, Feb 20, 2014 at 2:32 PM, Martin Thomson
<[email-masked]> wrote:
> call

Which got me to thinking about RFC 4516. Does section 2.3 of this
draft mean that new attribute types in LDAP may not show up in LDAP
URLs? And more interestingly, does Section 2.4 completely void the
extension mechanism in Section 2 of 4516?

-andy