|
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----- 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 |
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
