Subject: Re: [Last-Call] Last Call: <draft-nottingham-rfc7320bis-02.txt> (URI Design and Ownership) to Best Current Practice

From: Mike Bishop <[email-masked]>
Date: Tue, 3 Dec 2019 16:30:20 +0000

Overall, this looks good.  Two minor points in 2.3:  The example of defining paths under `.well-known` counts as a path delegation permitted by the scheme because it updates the scheme definition to add it.  That's not totally clear on first reading, and I'm concerned that it might encourage a bad practice of lots of documents wanting to update scheme definitions to reserve their preferred prefixes.

Perhaps a better way to frame this is that it's okay to grab a fixed path if the set of paths is managed by a registry, and well-known URIs are an example of that.  The scheme definition update in RFC8615 is to establish such a registry, and that is the pattern to emulate.

Second, another argument against fixed paths for applications is that you might want to run multiple instances/versions of the application on the same server at the same time.  The deployment-controlled prefix permits this, but a static path (even registered) does not.

-----Original Message-----
From: IETF-Announce <[email-masked]> On Behalf Of The IESG
Sent: Monday, November 18, 2019 5:24 AM
To: IETF-Announce <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Last Call: <draft-nottingham-rfc7320bis-02.txt> (URI Design and Ownership) to Best Current Practice

The IESG has received a request from an individual submitter to consider the following document: - 'URI Design and Ownership'

  <draft-nottingham-rfc7320bis-02.txt> as Best Current Practice

The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the [email-masked]<mailto:[email-masked]> mailing lists by 2019-12-16. Exceptionally, comments may be sent to [email-masked]<mailto:[email-masked]> instead. In either case, please retain the beginning of the Subject line to allow automated sorting.

Abstract

   Section 1.1.1 of RFC 3986 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 substructure in URIs is often

   problematic.

   This document provides guidance on the specification of URI

   substructure in standards.

The file can be obtained via

https://datatracker.ietf.org/doc/draft-nottingham-rfc7320bis/

IESG discussion can be tracked via

https://datatracker.ietf.org/doc/draft-nottingham-rfc7320bis/ballot/

No IPR declarations have been submitted directly on this I-D.

_______________________________________________

IETF-Announce mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/ietf-announce

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 11 Dec 2019 13:02:13 +1100

Hi Mike,

Thanks for the review. Comments below.

> On 4 Dec 2019, at 3:30 am, Mike Bishop <[email-masked]> wrote:
> 
> Overall, this looks good.  Two minor points in 2.3:  The example of defining paths under `.well-known` counts as a path delegation permitted by the scheme because it updates the scheme definition to add it.  That’s not totally clear on first reading, and I’m concerned that it might encourage a bad practice of lots of documents wanting to update scheme definitions to reserve their preferred prefixes.
>  
> Perhaps a better way to frame this is that it’s okay to grab a fixed path if the set of paths is managed by a registry, and well-known URIs are an example of that.  The scheme definition update in RFC8615 is to establish such a registry, and that is the pattern to emulate.
 
This text has been updated in the editors' copy based upon Fluffy's feedback; it might also address this. I don't want specifically recommend a registry, as it might be different from scheme to scheme. Please take a look:
  https://mnot.github.io/I-D/rfc7320bis/#uri-paths

Cheers,

> The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the [email-masked] mailing lists by 2019-12-16. Exceptionally, comments may be sent to [email-masked] instead. In either case, please retain the beginning of the Subject line to allow automated sorting.
>  
> Abstract
>  
>  
> [email-masked]
> -- 
> last-call mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/last-call

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