Ballot for draft-nottingham-rfc5785bis
Yes
No Objection
Note: This ballot was opened for revision 08 and is now closed.
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)
Alissa and Spencer already captured all of my comments :-)
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 :-) ...
= 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.
Thank you for resolving my Discuss point (per https://github.com/mnot/I-D/commit/548d575f9046d1a693fe33e8c278993ff679cb94#diff-f887343399d11cba948cc192d3c78362)!