- From: Maciej Stachowiak <mjs@apple.com>
- Date: Wed, 17 Feb 2010 05:04:46 -0800
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Mark Nottingham <mnot@mnot.net>, Ian Hickson <ian@hixie.ch>, Paul Cotton <Paul.Cotton@microsoft.com>, "public-html@w3.org" <public-html@w3.org>
On Feb 17, 2010, at 4:55 AM, Julian Reschke wrote: > On 17.02.2010 12:56, Maciej Stachowiak wrote: >> ... >> The plan to test the new procedures was discussed on #html-wg, and I >> noticed that there is no allowance in your draft for provisional >> registration; all registrations are full registrations and require a >> specification. >> >> By comparison: >> >> - Header Fields have a mechanism for provisional registration per >> http://www.ietf.org/rfc/rfc3864.txt >> - URI schemes have a mechanism for provisional registration per >> http://www.ietf.org/rfc/rfc4395.txt >> - MIME types have vendor, personal and experimental trees that >> serve a >> similar role to provisional registration per >> http://www.ietf.org/rfc/rfc4288.txt > > My 2 cents: > > - I've been following the discussions (as document shepherd), and I > don't believe the question ever came up before > > - One of the reasons it may not have been raised is that link > relation types do not *need* to be registered; you can always use a > URI you control (that would address the vendor namespace, for > instance). That would address vendor namespaces, but not registration of rel values you find arleady in active use by third parties. > >> This is not an objection, because I must admit I have no strong >> feelings >> on this issue. But I wonder if this is intentional or an oversight? >> >> It seems like many other IANA-maintained registries of values that >> are >> relevant to Web content have some sort of form of lesser registration >> that bypasses the firm "Specification Required" mandate, allowing >> values >> that are in actual use to be registered provisionally even if no >> one has >> written a proper spec yet. It seems to me like this would be useful >> for >> rel values as well. >> ... > > That's not entirely true, for instance the requirements for > provisional URI schemes are: > > 3. Guidelines for Provisional URI Scheme Registration > > > While the guidelines in Section 2 are REQUIRED for permanent > registration, they are RECOMMENDED for provisional registration. > For > a provisional registration, the following are REQUIRED: RECOMMENDED is a lower level of requirement than REQUIRED (a SHOULD, not a MUST). I have no problem with a universal SHOULD-level requirement. It's just not clear to me that when you can't meet it, the rel value should remain completely unregistered. > > o The scheme name meets the syntactic requirements of Section 2.8. > o There is not already an entry with the same URI scheme name. (In > the unfortunate case that there are multiple, different uses of > the same scheme name, the IESG may approve a request to modify an > existing entry to note the separate use.) > o Contact information identifying the person supplying the > registration is included. Previously unregistered URI schemes > discovered in use may be registered by third parties on behalf of > those who created the URI scheme; in this case, both the > registering party and the scheme creator SHOULD be identified. This bullet is exactly the kind of thing I think ought to be allowed, but effectively is not (unless you are able to reverse engineer a spec for the rel value). > o If no permanent, citable specification for the URI scheme > definition is included, credible reasons for not providing it > should be given. > o A valid Security Considerations section, as required by Section 6 > of [3]. > o If the scheme definition does not meet the guidelines laid out in > Section 2, the differences and reasons SHOULD be noted. > > (<http://tools.ietf.org/html/rfc4395#section-3>) > > Note in particular: > > o If no permanent, citable specification for the URI scheme > definition is included, credible reasons for not providing it > should be given. x
Received on Wednesday, 17 February 2010 13:05:20 UTC