- From: Peter Saint-Andre <stpeter@stpeter.im>
- Date: Mon, 16 Apr 2012 10:07:08 -0600
- To: Ned Freed <ned.freed@mrochek.com>
- CC: Jeni Tennison <jeni@jenitennison.com>, apps-discuss@ietf.org, tony+mtsuffix@maillennium.att.com, Julian Reschke <julian.reschke@gmx.de>, Noah Mendelsohn <nrm@arcanedomain.com>, john+ietf@jck.com, "www-tag@w3.org List" <www-tag@w3.org>
On 4/13/12 11:00 PM, Ned Freed wrote: >> Perhaps that's the best way of handling it, and nothing needs to be said >> specifically about fragments identifiers for top-level types. > > This isn't an option either. This is a registration best current practices > (BCP) document that sets down rules for registering media types. Default or > intrinsic syntax and semantics of fragment identifiers associated with a > particular top-level type is a protocol specification. This isn't allowed in a > BCP - BCPs are one shot affairs and not subject to interoperability testing, > which rather obviously would apply to the specification of such semantics. > > If you want to put this stuff in an RFC, it needs to one that's on the regular > standards track. And that means it needs to be in a different document. All you > can put in this document are the registration rules for specifying a fragment > identifier. Nothing more. Ned is right: this document defines best practices for *registering* media types. We all might want to more clearly specify the syntax and semantics of fragment identifiers, but IMHO that's out of scope for the registration procedures per se. Peter -- Peter Saint-Andre https://stpeter.im/
Received on Monday, 16 April 2012 16:07:42 UTC