Subject: Re: [art] Fwd: New Version Notification for draft-nottingham-rfc7320bis-01.txt

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Fri, 6 Sep 2019 16:45:53 -0700

This is great. Thanks for taking the time to make the revisions. I 
particularly appreciate the choice to do away with the word choice of 
"usurp" in favor of more prosaic language. :-)

I had some feedback, preserved below in case you want to read it, but 
realized that I was missing a key distinction from early in the document 
- "applications" and "extensions" are different use cases and have 
different requirements placed on them. I had been reading them as 
interchangeable. Given that they have such specific meanings, what do 
you think of making them defined terms and capitalizing them to make 
that clear?

--- incorrect feedback preserved below ---
 > 2.3 URL Paths
 > ...
 >    Note that this does not apply to applications defining a structure of
 >   URIs paths "under" a resource under control of the server.  Because
 >   the prefix is under control of the party deploying the application,
 >   collisions and rigidity are avoided, and the risk of erroneous client
 >   assumptions is reduced.

The connection between the first and second sentence isn't completely 
clear, and "under" isn't really defined. I'd suggest:

   ...defining a structure of URIs that all share a prefix chosen by the 
domain owner. Because the prefix is under control ...

 >   Extensions MUST NOT define a structure within individual URI
 >   components (e.g., a prefix or suffix), again to avoid collisions and
 >   erroneous client assumptions.

This seems to contradict the text above, unless I'm misunderstanding it. 
I think the concept here is that extensions shouldn't say "all paths 
ending in X, or beginning in Y, or with Z in the middle, are expected to 
do Q." Is that right?

Also, talking about "URI components" here is probably over-broad since 
this is the section about paths. I'd suggest combining this with an 
earlier paragraph:

    To avoid collisions, rigidity, and erroneous client assumptions,
    specifications MUST NOT define a fixed prefix for their URI paths;
    for example, "/myapp", unless allowed by the scheme definition.
    Similarly, specifications MUST NOT define suffixes or infixes for
    URI paths, with the exceptions below.

 > 2.4.  URI Queries
 > ...
 > Applications can specify the syntax of queries for the resources
 >   under their control.
 > ...
 >  Extensions MUST NOT constrain the format or semantics of queries, to
 >   avoid collisions and erroneous client assumptions.

These sentences seem to contradict each other.

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 9 Sep 2019 17:05:43 +1000

Hi Jacob,

> On 7 Sep 2019, at 9:45 am, Jacob Hoffman-Andrews <[email-masked]> wrote:
> 
> This is great. Thanks for taking the time to make the revisions. I particularly appreciate the choice to do away with the word choice of "usurp" in favor of more prosaic language. :-)

Thanks for the feedback.

> I had some feedback, preserved below in case you want to read it, but realized that I was missing a key distinction from early in the document - "applications" and "extensions" are different use cases and have different requirements placed on them. I had been reading them as interchangeable. Given that they have such specific meanings, what do you think of making them defined terms and capitalizing them to make that clear?

Let's try and see how it goes. Preview here:
  https://mnot.github.io/I-D/rfc7320bis/

Cheers,

> The connection between the first and second sentence isn't completely clear, and "under" isn't really defined. I'd suggest:
> 
>  ...defining a structure of URIs that all share a prefix chosen by the domain owner. Because the prefix is under control ...
> 
> This seems to contradict the text above, unless I'm misunderstanding it. I think the concept here is that extensions shouldn't say "all paths ending in X, or beginning in Y, or with Z in the middle, are expected to do Q." Is that right?
> 
> Also, talking about "URI components" here is probably over-broad since this is the section about paths. I'd suggest combining this with an earlier paragraph:
> 

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

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Mon, 9 Sep 2019 14:12:11 -0700

>    https://mnot.github.io/I-D/rfc7320bis/
This looks good to me.