Skip to main content

URI Design and Ownership
RFC 8820

Revision differences

Document history

Date Rev. By Action
2020-06-30
03 (System)
Received changes through RFC Editor sync (created alias RFC 8820, changed abstract to 'Section 1.1.1 of RFC 3986 defines URI syntax as "a federated …
Received changes through RFC Editor sync (created alias RFC 8820, changed abstract to '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.

This document obsoletes RFC 7320 and updates RFC 3986.', changed pages to 8, changed standardization level to Best Current Practice, changed state to RFC, added RFC published event at 2020-06-30, changed IESG state to RFC Published, created obsoletes relation between draft-nottingham-rfc7320bis and RFC 7320, created updates relation between draft-nottingham-rfc7320bis and RFC 3986)
2020-06-30
03 (System) RFC published
2020-06-29
03 (System) RFC Editor state changed to <a href="http://www.rfc-editor.org/auth48/rfc8820">AUTH48-DONE</a> from AUTH48
2020-06-11
03 (System) RFC Editor state changed to <a href="http://www.rfc-editor.org/auth48/rfc8820">AUTH48</a> from RFC-EDITOR
2020-06-02
03 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2020-05-08
03 (System) RFC Editor state changed to EDIT from IESG
2020-03-10
03 Cindy Morgan
As an unintended side effect of recovering information lost in the 2020-02-27 server transition, the IESG state on this document reverted from "RFC Editor Queue" …
As an unintended side effect of recovering information lost in the 2020-02-27 server transition, the IESG state on this document reverted from "RFC Editor Queue" to "Approved-announcement to be sent." The state has been changed back to "RFC Editor Queue" manually. The RFC Editor state is "IESG" because there is an appeal pending.
2020-03-10
03 Cindy Morgan IESG state changed to RFC Ed Queue from Approved-announcement to be sent
2020-03-09
03 (System) RFC Editor state changed to IESG
2020-02-05
03 (System) RFC Editor state changed to IESG from EDIT
2020-01-29
03 (System) IANA Action state changed to No IANA Actions from In Progress
2020-01-28
03 (System) RFC Editor state changed to EDIT
2020-01-28
03 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2020-01-28
03 (System) Announcement was received by RFC Editor
2020-01-28
03 (System) IANA Action state changed to In Progress
2020-01-28
03 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2020-01-28
03 Cindy Morgan IESG has approved the document
2020-01-28
03 Cindy Morgan Closed "Approve" ballot
2020-01-28
03 Cindy Morgan Ballot approval text was generated
2020-01-23
03 Cindy Morgan IESG state changed to Approved-announcement to be sent from IESG Evaluation
2020-01-23
03 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2020-01-23
03 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund
2020-01-22
03 Benjamin Kaduk
[Ballot comment]
Thanks for the well-written document!  A few minor comments:

Section 2.1

  Applications and Extensions can require use of specific URI
  scheme(s); …
[Ballot comment]
Thanks for the well-written document!  A few minor comments:

Section 2.1

  Applications and Extensions can 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
  ought not preclude the use of other URI schemes in the future, unless
  they are clearly only usable with the nominated schemes.

I'm having a little trouble squaring "can require specific schemes" with
"ought not preclude the use of other schemes".  How accurate would it be
to try to summarize this guidance as "specify what properties you need
the scheme to have, not the scheme itself"?

Section 2.4

side note: the discussion we give here about the flaws in assumptions
about query parameters named "sig" is more complete than the earlier
such discussion in Section 1; the earlier treatment is slightly
confusing without the additional context present here.  It's not really
clear that a forward reference would be appropriate, though, hence this
is just a side note.

Section 3

  Specifying more elaborate structures in an attempt to avoid
  collisions is not an acceptable solution, and does not address the
  issues in Section 1.  For example, prefixing query parameters with
  "myapp_" does not help, because the prefix itself is subject to the
  risk of collision (since it is not "reserved").

nit: I'm not sure what purpose the scare-quotes on "reserved" serve.
nit^2: the previous paragraph uses single-quotes around 'reserved'.
2020-01-22
03 Benjamin Kaduk [Ballot Position Update] New position, Yes, has been recorded for Benjamin Kaduk
2020-01-22
03 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2020-01-22
03 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2020-01-22
03 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2020-01-21
03 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2020-01-21
03 Adam Roach
Shepherd writeup for draft-nottingham-rfc7320bis
Intended status: BCP
Shepherd: Martin Thomson
Source: Individual Draft (AD Sponsored)

This revision to RFC 7320 exists to make a single …
Shepherd writeup for draft-nottingham-rfc7320bis
Intended status: BCP
Shepherd: Martin Thomson
Source: Individual Draft (AD Sponsored)

This revision to RFC 7320 exists to make a single change.  The original document
had a prohibition on specifications defining structure or semantics to the
suffix of a URI (that is, the tail of the hierarchical path).  This applies to
both trailing path elements and query parameters.

This might be good theory on the basis that it allows greater latitude in how
implementation of protocols are structured, but - once aware of this BCP - the
IETF community at large violently rejected any suggestion that their power be so
curtailed.  Thus, this revision exists to document that view and remove the
restriction.

The IETF community believes that once within the confines of an "Application" or
"Extension", constraints on how semantics are carried are overly restrictive.
For instance, while recommendations to use further indirection through directory
resources or link relations, prearranged semantics in URI structure allows for
easy construction of destination URLs without the overhead of finding those
resources.  This is a very common practice.

In short, the argument says that if a random API on a website gets to do these
things, why not the IETF?

There are numerous editorial tweaks in line with this change, such as expanding
the rationale for prohibitions on attaching semantics to protocol elements with
semantics defined by the URI scheme itself.

Of particular note, the author removed an Oxford comma in the Acknowledgments.

This revision also replaces a reference to RFC 6838 with a reference to RFC
3986
for specifying fragment identifier syntax and semantics. This was done
because the original reference was misleading: RFC 6838 doesn't make such a
requirement a SHOULD. The focus of this update was to reduce the number
of unnecessary requirements.

These changes have been debated extensively, sometimes bitterly, making this
shepherd confident that this document now represents IETF consensus.  The
strictures that remain are far more firmly grounded.  Not in the doctrine of
REST, which was never a single theory anyway, but in stronger principles.  For
instance, the IETF cannot dictate what domain names people can have.  This
includes whether they are allowed to use emoji, apparently.
2020-01-21
03 Warren Kumari
[Ballot comment]
As asked by Eric, and the OpsDir review (Qin Wu - "I am curious why this bis document is not published through WG …
[Ballot comment]
As asked by Eric, and the OpsDir review (Qin Wu - "I am curious why this bis document is not published through WG process but through individual stream process. If this document is published through individual steam process with AD sponsored, should this document be classified as informational? Where was this document initially discussed to build IETF consensus?") I'm also wondering why this wasn't a WG document -- anyway, I'm assuming the AD has a good reason, so, LGTM :-)
2020-01-21
03 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2020-01-21
03 Alissa Cooper [Ballot Position Update] New position, Yes, has been recorded for Alissa Cooper
2020-01-21
03 Éric Vyncke
[Ballot comment]
Thank you for the work put into this document.  I have really appreciated the justifications and explanations. Just wondering why it is not …
[Ballot comment]
Thank you for the work put into this document.  I have really appreciated the justifications and explanations. Just wondering why it is not a WG document.

-éric
2020-01-21
03 Éric Vyncke Ballot comment text updated for Éric Vyncke
2020-01-20
03 Éric Vyncke
[Ballot comment]
Thank you for the work put into this document.  I have really appreciated the justifications and explanations. Just wondering why it is an …
[Ballot comment]
Thank you for the work put into this document.  I have really appreciated the justifications and explanations. Just wondering why it is an individual submission.

-éric
2020-01-20
03 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2020-01-20
03 Mirja Kühlewind
[Ballot comment]
Please note the TSV-ART review (Thanks Joe!) and the issue raised regarding an outstaying errata on RFC7320 that may impact the change in …
[Ballot comment]
Please note the TSV-ART review (Thanks Joe!) and the issue raised regarding an outstaying errata on RFC7320 that may impact the change in this doc.
2020-01-20
03 Mirja Kühlewind Ballot comment text updated for Mirja Kühlewind
2020-01-20
03 Mirja Kühlewind [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind
2020-01-09
03 Alexey Melnikov [Ballot Position Update] New position, Yes, has been recorded for Alexey Melnikov
2020-01-07
03 (System) IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2020-01-06
03 Barry Leiba [Ballot Position Update] New position, Yes, has been recorded for Barry Leiba
2020-01-06
03 Cindy Morgan Placed on agenda for telechat - 2020-01-23
2020-01-06
03 Adam Roach IESG state changed to IESG Evaluation from Waiting for Writeup::AD Followup
2020-01-06
03 Adam Roach Ballot has been issued
2020-01-06
03 Adam Roach [Ballot Position Update] New position, Yes, has been recorded for Adam Roach
2020-01-06
03 Adam Roach Created "Approve" ballot
2020-01-06
03 Adam Roach Ballot writeup was changed
2020-01-05
03 (System) Sub state has been changed to AD Followup from Revised ID Needed
2020-01-05
03 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2020-01-05
03 Mark Nottingham New version available: draft-nottingham-rfc7320bis-03.txt
2020-01-05
03 (System) New version accepted (logged-in submitter: Mark Nottingham)
2020-01-05
03 Mark Nottingham Uploaded new revision
2019-12-24
02 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Donald Eastlake. Submission of review completed at an earlier date.
2019-12-19
02 Adam Roach Waiting for new version based on edits already present in github.
2019-12-19
02 Adam Roach IESG state changed to Waiting for Writeup::Revised I-D Needed from Waiting for Writeup
2019-12-16
02 (System) IESG state changed to Waiting for Writeup from In Last Call
2019-12-14
02 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Donald Eastlake.
2019-12-02
02 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2019-12-02
02 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-nottingham-rfc7320bis-02, which is currently in Last Call, and has the following comments:

We …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-nottingham-rfc7320bis-02, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2019-12-02
02 Joseph Touch Request for Last Call review by TSVART Completed: Ready with Issues. Reviewer: Joseph Touch. Sent review to list.
2019-11-28
02 Qin Wu Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Qin Wu. Sent review to list.
2019-11-27
02 Wesley Eddy Request for Last Call review by TSVART is assigned to Joseph Touch
2019-11-27
02 Wesley Eddy Request for Last Call review by TSVART is assigned to Joseph Touch
2019-11-26
02 Robert Sparks Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Robert Sparks. Sent review to list.
2019-11-20
02 Tero Kivinen Request for Last Call review by SECDIR is assigned to Donald Eastlake
2019-11-20
02 Tero Kivinen Request for Last Call review by SECDIR is assigned to Donald Eastlake
2019-11-20
02 Jean Mahoney Request for Last Call review by GENART is assigned to Robert Sparks
2019-11-20
02 Jean Mahoney Request for Last Call review by GENART is assigned to Robert Sparks
2019-11-20
02 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Qin Wu
2019-11-20
02 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Qin Wu
2019-11-18
02 Amy Vezza IANA Review state changed to IANA - Review Needed
2019-11-18
02 Amy Vezza
The following Last Call announcement was sent out (ends 2019-12-16):<br><br>From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: art@ietf.org, draft-nottingham-rfc7320bis@ietf.org, …
The following Last Call announcement was sent out (ends 2019-12-16):<br><br>From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: art@ietf.org, draft-nottingham-rfc7320bis@ietf.org, adam@nostrum.com, mt@lowentropy.net, mt@mozilla.com
Reply-To: last-call@ietf.org
Sender: <iesg-secretary@ietf.org>
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@ietf.org mailing lists by 2019-12-16. Exceptionally, comments may
be sent to iesg@ietf.org 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.




2019-11-18
02 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2019-11-18
02 Adam Roach Last call was requested
2019-11-18
02 Adam Roach Last call announcement was generated
2019-11-18
02 Adam Roach Ballot approval text was generated
2019-11-18
02 Adam Roach Ballot writeup was generated
2019-11-18
02 Adam Roach IESG state changed to Last Call Requested from AD Evaluation
2019-11-18
02 Adam Roach IESG state changed to AD Evaluation from Publication Requested
2019-11-18
02 Adam Roach Notification list changed to mt@mozilla.com, art@ietf.org
2019-11-18
02 Adam Roach IESG process started in state Publication Requested
2019-11-15
02 Martin Thomson
Shepherd writeup for draft-nottingham-rfc7320bis
Intended status: BCP
Shepherd: Martin Thomson
Source: Individual Draft (AD Sponsored)

This revision to RFC 7320 exists to make a single …
Shepherd writeup for draft-nottingham-rfc7320bis
Intended status: BCP
Shepherd: Martin Thomson
Source: Individual Draft (AD Sponsored)

This revision to RFC 7320 exists to make a single change.  The original document
had a prohibition on specifications defining structure or semantics to the
suffix of a URI (that is, the tail of the hierarchical path).  This applies to
both trailing path elements and query parameters.

This might be good theory on the basis that it allows greater latitude in how
implementation of protocols are structured, but - once aware of this BCP - the
IETF community at large violently rejected any suggestion that their power be so
curtailed.  Thus, this revision exists to document that view and remove the
restriction.

The IETF community believes that once within the confines of an "Application" or
"Extension", constraints on how semantics are carried are overly restrictive.
For instance, while recommendations to use further indirection through directory
resources or link relations, prearranged semantics in URI structure allows for
easy construction of destination URLs without the overhead of finding those
resources.  This is a very common practice.

In short, the argument says that if a random API on a website gets to do these
things, why not the IETF?

There are numerous editorial tweaks in line with this change, such as expanding
the rationale for prohibitions on attaching semantics to protocol elements with
semantics defined by the URI scheme itself.

Of particular note, the author removed an Oxford comma in the Acknowledgments.

These changes have been debated extensively, sometimes bitterly, making this
shepherd confident that this document now represents IETF consensus.  The
strictures that remain are far more firmly grounded.  Not in the doctrine of
REST, which was never a single theory anyway, but in stronger principles.  For
instance, the IETF cannot dictate what domain names people can have.  This
includes whether they are allowed to use emoji, apparently.
2019-10-14
02 Adam Roach Notification list changed to Martin Thomson <mt@lowentropy.net>
2019-10-14
02 Adam Roach Document shepherd changed to Martin Thomson
2019-10-06
02 Mark Nottingham New version available: draft-nottingham-rfc7320bis-02.txt
2019-10-06
02 (System) New version approved
2019-10-06
02 (System) Request for posting confirmation emailed to previous authors: Mark Nottingham <mnot@mnot.net>
2019-10-06
02 Mark Nottingham Uploaded new revision
2019-10-01
01 Adam Roach Changed consensus to Yes from Unknown
2019-10-01
01 Adam Roach Intended Status changed to Best Current Practice from None
2019-10-01
01 Adam Roach Stream changed to IETF from None
2019-10-01
01 Adam Roach Shepherding AD changed to Adam Roach
2019-08-26
01 Mark Nottingham New version available: draft-nottingham-rfc7320bis-01.txt
2019-08-26
01 (System) New version approved
2019-08-26
01 (System) Request for posting confirmation emailed to previous authors: Mark Nottingham <mnot@mnot.net>
2019-08-26
01 Mark Nottingham Uploaded new revision
2019-08-20
00 Mark Nottingham New version available: draft-nottingham-rfc7320bis-00.txt
2019-08-20
00 (System) New version approved
2019-08-20
00 Mark Nottingham Request for posting confirmation emailed  to submitter and authors: Mark Nottingham <mnot@mnot.net>
2019-08-20
00 Mark Nottingham Uploaded new revision