Skip to main content

Shepherd writeup
draft-nottingham-rfc7320bis

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.
Back