Subject: Re: [apps-discuss] Review of: draft-ietf-appsawg-uri-get-off-my-lawn-00

From: Mark Nottingham <[email-masked]>
Date: Thu, 30 Jan 2014 14:41:46 +1100

Hi Dave,

Thanks for the review. Some responses below. Latest source with updates is at:
  https://raw.github.com/mnot/I-D/master/uri-get-off-my-lawn/draft.md

On 1 Jan 2014, at 2:52 am, Dave Crocker <[email-masked]> wrote:
> 
> Summary:
> 
>     URIs are the core citation and client transaction (request) form on the Internet.  Anything used that widely and in such variable circumstances is likely to get ad hoc tailoring for use with particular applications and/or particular implementations and/or particular servers.  The "and/or" combinations highlight the potential for chaotic tailoring which, therefore, creates ambiguities and conflicts.   The current draft seeks to impose better global discipline on the use of URIs.
> 
>    For a construct as important as a URI, the importance of moving towards clean and unconflicted use can't be overstated.  However the requirements that prompt the ad hoc tailoring typically are legitimate, even if the method of dealing with it is problematic.  So the challenges here are in clarity and precision about what should /not/ be done, sufficiency in the available alternatives, and clarity in the way all this is explained.  Any specification needs to worry that it is adequately understandable to a reader new to the topic, but in the case of a document attempting to repair existing confusion and misbehavior, it is especially important:  the document needs an added degree of tight and coherent organization, with very pedantic logical sequences to what is said, and very careful wording that says it.
> 
> Unfortunately, at the highest level, I'm not sure how this document can be used, for those most needing to use it.  It's not a question of whether the document isn't chock full of specific advice.  And the issue is separate from agreeing or disagreeing with any of the points made in the document.  It's a question of how it is organized for long-term use.  The current form of the document doesn't seem tightly-enough organized for that use, but I'm not sure what to suggest.  In addition, it varies between portions that appear to be protocol specification, versus portions that appear to be best current practices.
> 
> Also I found myself periodically confused about the exact meaning of text in the document.  Some of this might merely need somewhat more careful wording.  Some of the confusion might be due to deeper issues with the document.  I'm not sure.  Obviously some of the confusion could be my own limitations, but I spent some time trying to track things down and was still left confused, as noted below.

Upon some reflection, I feel some sympathy, in that I feel the same way about the comments above, I think. :)

What would you like to see -- can you give me something actionable?

> The title of the document asserts that it is /creating/ structure for URI's, but I believe it is, instead, mostly clarifying /existing/ structure.  Beyond that I believe that it is at most making -- or, at least, intending to make -- modest tweaks.  (I see that as a Good Thing, for something like this.  Anything more ambitious would probably disrupt current, legitimate uses of URIs...)

I've changed the title.

> Detailed Comments:
> 
>> Abstract
>> 
>>   Sometimes, it is attractive to add features to protocols or
>>   applications by specifying a particular structure for URIs (or parts
>>   thereof).  This document cautions against this practice in standards
>>   (sometimes called "URI Squatting").
> 
> This implies that URIs must not have any 'features' or 'structure'. I think that what is meant is more limited than that.  So what is needed is a statement to balance, that indicates what is normal and acceptable.  Maybe that's just a pointer to Section 3, but I suspect there's more needed than that.
> 
> Note, for example, that the URI spec (RFC 3986) allocates the role of providing "generative grammar for URIs; that task is performed by the individual specifications of each URI scheme."  A grammar is, by definition, a structure.  So some sorts of structures are acceptable, in some sorts of specifications.  What is ok and what isn't ok needs to be clarified.
> 
> That leaves a basic question for the current draft:  when/where is acceptable for specifying functions and structures in a URI and when/where isn't?
> 
> In addition, the use of sub-structure in URI's is integral to many, established web practices.  Again:  this document needs to distinguish between those and whatever others that are /not/ acceptable.

The document is very clear that it applies to standards, not people deploying their own servers as they choose. 

>> 1.  Introduction
>> 
>>   URIs [RFC3986] very often include structured application data.  This
> 
> In spite of the examples provided in the next sentence, it isn't obvious to me what "structured application data" means.  Yet it's the key construct for the document.

There are examples below, but I do agree they're somewhat abstract. Will try to make them more concrete.

>>   might include artifacts from filesystems (often occurring in the path
>>   component), and user information (often in the query component).  In
>>   some cases, there can even be application-specific data in the
>>   authority component (e.g., some applications are spread across
>>   several hostnames to enable a form of partitioning or dispatch).
>> 
>>   Furthermore, constraints upon the structure of URIs can be imposed by
>>   an implementation; for example, many Web servers use the filename
>>   extension of the last path segment to determine the media type of the
>>   response.  Likewise, pre-packaged applications often have highly
>>   structured URIs that can only be changed in limited ways (often, just
>>   the hostname and port they are deployed upon).
>> 
>>   Because the owner of the URI is choosing to use the server or the
>>   software, this can be seen as reasonable delegation of authority.
>>   When such conventions are mandated by standards, however, it can have
>>   several potentially detrimental effects:
>> 
>>   o  Collisions - As more conventions for URI structure become
>>      standardised, it becomes more likely that there will be collisions
> 
> If indeed they are being standardized, then the real issue is to have coordination of the standards documents, through a registry or the like.

I think you're missing one of the central points of the document here; standardising such structure (e.g., through creation of a registry) where it isn't appropriate shouldn't be done. The task of this draft is to point out where it is and isn't appropriate.

In other words, URIs provide many possible affordances for extension, but some -- indeed, many -- are reserved for the use of their authority, not a random third party (including IETF WGs).

> I suspect the word "standardize" is being used ambiguously in this document, to mean both "formal" standards and "common practice" (de fact).

No, it's not.  While it would be nice to encourage other third parties (e.g., open source projects) not to "bake" assumptions into the format of their URIs, that's out of scope for this document.

>                This can lead to interoperability
>>      problems; for example, if a specification documents that the "sig"
>>      URI query parameter indicates that its payload is a cryptographic
>>      signature for the URI, it can lead to false positives.
> 
> The example seems to presume that the attribute associated with 'sig' will incorrectly validate as a signature.  What are the odds of that, if the sig is using competent modern cryptography?  False negatives seem more likely.

The interesting scenario is where a client assumes that "sig" indicates a signature and acts upon that (most likely, failing in some way because the sig doesn't validate). "false positive" refers to falsely assuming that "sig" means what the client thinks it means, but I see how that can be confusing; will modify.

>>   While it is not ideal when a server or a deployed application
>>   constrains URI structure (indeed, this is not recommended practice,
>>   but that discussion is out of scope for this document), publishing
>>   standards that mandate URI structure is inappropriate because the
>>   structure of a URI needs to be firmly under the control of its owner,
> 
> See comment above, in Abstract:  the URI spec assigns exactly that role to exactly such documents.  But perhaps I've misunderstood that doc or this one?

There are some defined ways that URI structure can be specified / constrained, and they're covered in the sections below. Read in isolation, I can see how this text could be confusion; will update.

>>   and the IETF (as well as other organisations) should not usurp this
>>   ownership; see [webarch] Section 2.2.2.1.
> 
> Huh?
> 

Errr...

>>   This document explains best current practices for establishing URI
>>   structures, conventions and formats in standards.  It also offers
>>   strategies for specifications to avoid violating these guidelines in
>>   Section 3.
>> 
>> 1.1.  Who This Document Is For
>> 
>>   These guidelines are IETF Best Current Practice, and are therefore
>>   binding upon IETF standards-track documents, as well as submissions
>>   to the RFC Editor on the Independent and IRTF streams.  See [RFC2026]
>>   and [RFC4844] for more information.
> 
> Having a document like this make such a broad and absolute assertion seems inappropriate.
> 
>>   Other Open Standards organisations (in the sense of [RFC2026]) are
>>   encouraged to adopt them.  Questions as to their applicability ought
>>   to be handled through the liaison relationship, if present.
>> 
>>   Ad hoc efforts are also encouraged to adopt them, as this RFC
>>   reflects Best Current Practice.
> 
> Instead of making the above statements of "authority" over other documents, it would be more useful for the text to describe the nature of its utility and, therefore, /when/ it should apply.  I think the draft text that follows this probably suffices for that.

OK, I'm removing those paragraphs; I agree that they're a bit clunky, but liked being direct / unambiguous (I know that's unfashionable in the IETF).

>>   types of specifications:
>> 
>>   o  URI Scheme Definitions ("scheme definitions") - specifications
>>      that define and register URI schemes, as per [RFC4395].
>>   o  Protocol Extensions ("extensions") - specifications that offer new
>>      capabilities to potentially any identifier, or a large subset;
>>      e.g., a new signature mechanism for 'http' URIs, or metadata for
>>      any URI.
> 
> How are these formally/notationally distinguished?  For example, must they be issued as updates to existing definitions?

Protocol extensions aren't; really, URIs shouldn't be considered a valid way to extend the protocol at all (on their own), but people keep trying...

>>   o  Applications Using URIs ("applications") - specifications that use
>>      URIs to meet specific needs; e.g., a HTTP interface to particular
>>      information on a host.
>> 
>>   Requirements that target the generic class "Specifications" apply to
>>   all specifications, including both those enumerated above above and
>>   others.
> 
> This document makes requirements on all other specifications ever written?

Well, yes. We do that all the time, really, don't we?

>>   Note that this specification ought not be interpreted as preventing
>>   the allocation of control of URIs by parties that legitimately own
>>   them, or have delegated that ownership; for example, a specification
>>   might legitimately specify the semantics of a URI on the IANA.ORG Web
>>   site as part of the establishment of a registry.
> 
> How is that meaningfully different from the specifications done by the IETF, or others, that are /not/ legitimate?

Because IANA is the authority for URIs under iana.org, but not mnot.net (for example).

>> 1.2.  Notational Conventions
>> 
>>   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>>   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>>   document are to be interpreted as described in [RFC2119].
>> 
>> 
>> 2.  Best Current Practices for Standardising Structured URIs
>> 
>>   Different components of a URI have differing practices recommended.
>> 
>> 2.1.  URI Schemes
>> 
>>   Applications and extensions MAY require use of specific URI
>>   scheme(s); for example, it is perfectly acceptable to require that an
>>   application support 'http' and 'https' URIs.  However, applications
>>   SHOULD NOT preclude the use of other URI schemes in the future, to
>>   promote reuse, unless they are clearly specific to the nominated
>>   schemes.
> 
> What does it mean, in practical, technical terms, to not preclude use of other schemes?  (A desire to avoid limiting future specification choices is always nice, but knowing what will and won't limit things isn't always obvious.)

It means that the specification SHOULD NOT say something like "you can never use a different scheme with this."

> For example, how is it reasonable for a file transfer application to be required to permit use of a mailto: or sip: scheme?  zThe current wording seems to imply such flexibility.

That's not what it's saying. SHOULD NOT preclude != require to permit.

> Also, "reuse"?  What does that mean?

I'll drop that clause.

>>   Applications SHOULD NOT directly specify the syntax of queries, as
>>   this can cause operational difficulties for deployments that do not
>>   support a particular form of a query.
> 
> The implication of this is that all applications that accept any queries must accept all queries.  But that doesn't make sense.  The nature of an application constrains what types of queries it can process usefully.

>>   Extensions MUST NOT specify the format or semantics of queries.  In
>>   particular, extensions MUST NOT assume that all HTTP(S) resources are
>>   capable of accepting queries in the format defined by [HTML4],
>>   Section 17.13.4.
> 
> The first sentence seems to mean that a "protocol extension" is not allowed to extend a protocol to support queries.  But the second sentence clearly means otherwise.  I'm obviously misunderstanding what this means or how it is to be applied.

Rewritten, thanks.

>>   Given the issues above, the most successful strategy for applications
>>   and extensions that wish to use URIs is to use them in the fashion
>>   they were designed; as run-time artifacts that are exchanged as part
>>   of the protocol, rather than statically specified syntax.
>> 
>>   For example, if a specific URI needs to be known to interact with an
> 
> I'm not sure what it means for a URI to be "known to interact" with an application.  A URI isn't a protocol; it's a format.  And so I don't think of it as "interacting".
> 
> Do you mean that an application accepts a particular URI or that the application uses the URI?

This section has been rewritten.

>>   application, its "shape" can be determined by interacting with the
> 
> I've searched a number of the documents cited in the references and none of them uses the word 'shape'.  What does it mean here?

I've modified the language.

>>   application's more general interface (in Web terms, its "home page")
>>   to learn about that URI.
> 
> How?  This seems a hugely important point but it contains no technical detail.

Working on it in other draft(s) that I don't want to depend upon.

> In general, this document would be greatly aided by many more examples, including examples that show the wrong way something is often done and then the right way it should be done.

Agreed.

>> 4.  Security Considerations
>> 
>>   This document does not introduce new protocol artifacts with security
>>   considerations.
> 
> Hmmm.  This draft touches on ambiguity and false positives/negatives.  I would think that these have some potential security implications.

Will work on some.

Thanks again,

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