Well-Known Uniform Resource Identifiers (URIs)
draft-nottingham-rfc5785bis-11

[Ballot discuss]
Thanks for this long-overdue update, and well-written document.

I do think that we should discuss a bit the current text in Section 3.1
that allows Experts to change provisional registrations to permanent
without consulting the community in the way that they would need to for
an initial permanent registration.  Is it really expected that the level
of community review will be identical for provisional and permanent
registrations such that one can suffice for the other?

[Ballot comment]
It would be nice to have seen an I-D version with the updates from the
secdir review.  For example, where do we stand on having draft text
of the registration instructions to be placed in the registry (whether
in the document or elsewhere)?

Section 3

  It MAY also contain additional information, such as the syntax of
  additional path components, query strings and/or fragment identifiers
  to be appended to the well-known URI, or protocol-specific details
  (e.g., HTTP [RFC7231] method handling).

"It" is the registration here, not the applications, right?

Section 4

A reference to RFC 3552 is probably in order here.

I see that Section 4.3 advises applications about the risk of
poorly-administered servers that treat /.well-known/ in a risky fashion,
but shouldn't we also give some guidance to *all* administrators of
servers using protocols that use well-known URIs about protecting
/.well-known/* ?

Section 4.1

Is it also advisable to limit the content under the well-known URI to a
discovery document, and move writable resources to a different origin?

[Ballot comment]
= Abstract =

Please briefly describe why/how this document obsoletes and updates other documents.

= Section 2 =

Please use the RFC 8174 boilerplate.

= Section 3.1 =

I agree with Adam regarding postal address, unless there is some compelling reason why postal address would be needed for this registry.

[Ballot comment]
Thanks for doing this document. I have comments.

The document says this:

  Applications that wish to mint new well-known URIs MUST register
  them, following the procedures in Section 5.1.

  For example, if an application registers the name 'example', the
  corresponding well-known URI on 'http://www.example.com/' would be
  'http://www.example.com/.well-known/example'.

but almost immediately says this:

  Registered names for a specific application SHOULD be correspondingly
  precise; "squatting" on generic terms is not encouraged.  For
  example, if the Example application wants a well-known location for
  metadata, an appropriate registered name might be "example-metadata"
  or even "example.com-metadata", not "metadata".

ISTM that this isn't a BCP14 SHOULD - it's not required for interworking, and I have no idea what "correspondingly precise" would mean as a normative requirement, but more to the point, if you moved the example below this paragraph, and used one of the correspondingly precise versions as your example, that would likely help people assimilate this excellent advice.

And, now that I'm looking at this more closely, ISTM that the beginning of Section 3 is intended for requesters, most of Section 3 is intended for expert reviewers, and Section 3.1 is intended for requesters. Perhaps putting all the information intended for requesters in one place and clearly labeling the audiences would be helpful?

I'm looking at this text in Section 3.1,

  Standards-defined values have a status of "permanent".  Other values
  can also be registered as permanent, if the Experts find that they
  are in use, in consultation with the community.  Other values should
  be registered as "provisional".

  Provisional entries can be removed by the Experts if - in
  consultation with the community - the Experts find that they are not
  in use.  The Experts can change a provisional entry's status to
  permanent at any time.

  Note that well-known URIs can be registered by third parties
  (including the expert(s)), if the expert(s) determines that an
  unregistered well-known URI is widely deployed and not likely to be
  registered in a timely manner otherwise.  Such registrations still
  are subject to the requirements defined, including the need to
  reference a specification.

and, call me cynical, but this seems to be begging people to squat, because if they achieve wide deployment, their well-known URI will likely be be eventually registered (and, unless I'm missing something, may be registered as "permanent") with no interaction with expert reviewers, and if they don't achieve wide deployment, squatting didn't matter.

What we're doing with https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml ia tracking "unauthorized use reported". If the experts can chase down a specification for an unregistered use and process it with themselves as requesters, that's great, but if they can't always do that, you might consider adding "unauthorized" or "reported unregistered use", or something like that, as a third Status value.

But do the right thing, of course :-) ...

[Ballot comment]
Thanks for taking the time to update RFC 5785 to match the needs of modern
HTTP-using protocols. This will make my job much easier. :)

---------------------------------------------------------------------------

§3.1:

>  Change controller:  For Standards-Track RFCs, state "IETF".  For
>    others, give the name of the responsible party.  Other details
>    (e.g., postal address, e-mail address, home page URI) may also be
>    included.

The IANA recently went through an exercise for the ITAD registry in which it
decided to no longer collect postal addresses for registrants, and to purge
those addresses it had already collected. I believe that the interpretation of
GDPR they have arrived at is that, absent a clearly stated reason to possess it,
they no longer wish to receive such information at all. I would suggest removing
it from the list of details that change controllers may optionally submit.

---------------------------------------------------------------------------

§3.1:

>  General requirements for registered relation types are described in
>  Section 3.

I don't think you mean "relation types" here.

---------------------------------------------------------------------------

§4.1:

>  o  Using an application-specific media type in the Content-Type
>    header, and requiring clients to fail if it is not used

Nit: "...header field..." (I know, but this is where we are today)

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

The IANA Functions Operator has completed its review of draft-nottingham-rfc5785bis-08. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

We understand that this document, is an update of the Well-Known URI Registry located at:

https://www.iana.org/assignments/well-known-uris/

IANA notes that the previous registration procedure was Expert Review as defined in RFC8126. We understand that this document, upon approval, changes the registration procedure to Specification Required and [ RFC-to-be ] provides consideration for the Experts required in the Specification.

We have three questions/notes:

1) RFC 5988 has been obsoleted by RFC 8288
2) There are no references to RFC 5988 or RFC 8288 in Well-Known URIs. There are references to RFC 8288 in https://www.iana.org/assignments/link-relations and https://www.iana.org/assignments/message-headers
3) There's nowhere in Well-Known URIs to mark a registration "permanent."

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2019-02-05):

From: The IESG
To: IETF-Announce
CC: Martin Thomson , alexey.melnikov@isode.com, martin.thomson@gmail.com, draft-nottingham-rfc5785bis@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Well-Known Uniform Resource Identifiers (URIs)) to Proposed Standard


The IESG has received a request from an individual submitter to consider the
following document: - 'Well-Known Uniform Resource Identifiers (URIs)'
  as Proposed Standard

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
ietf@ietf.org mailing lists by 2019-02-05. 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


  This memo defines a path prefix for "well-known locations", "/.well-
  known/", in selected Uniform Resource Identifier (URI) schemes.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-nottingham-rfc5785bis/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-nottingham-rfc5785bis/ballot/


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

1. Summary

Shepherd: Martin Thomson
Responsible AD: Alexey Melnikov

This document updates two RFCs defining the /.well-known/ path for URLs in HTTP
(5785) and thewebsocketprotocol (8307).  The only meaningful change is to relax
some of the constraints on registrations to allow for a broader set of uses.
For instance, service discovery is now expressly permitted.

There are also a number of editorial improvements and an expansion of the
security considerations.

2. Review and Consensus

The main change in this document is the result of some contention about the
intent of the mechanism and some lengthy discussions in plenary (e.g.,
).
A mailing list for discussing this was established after that most recent
discussion: .

3. Intellectual Property

The author confirmed that IPR has been disclosed.

4. Other Points

The checklist is clean.