Hi Mike, Thanks for the review. Comments below. > On 4 Dec 2019, at 3:30 am, Mike Bishop <mbishop@xxxxxxxxxxxx> 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, > 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 <ietf-announce-bounces@xxxxxxxx> On Behalf Of The IESG > Sent: Monday, November 18, 2019 5:24 AM > To: IETF-Announce <ietf-announce@xxxxxxxx> > Cc: art@xxxxxxxx; draft-nottingham-rfc7320bis@xxxxxxxx; adam@xxxxxxxxxxx; mt@xxxxxxxxxxxxxx; mt@xxxxxxxxxxx > 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 last-call@xxxxxxxx mailing lists by 2019-12-16. Exceptionally, comments may be sent to iesg@xxxxxxxx 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 > IETF-Announce@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf-announce > -- > last-call mailing list > last-call@xxxxxxxx > https://www.ietf.org/mailman/listinfo/last-call -- Mark Nottingham https://www.mnot.net/ -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
