Re: ISSUE-27: rel-ownership - Chairs Solicit Proposals

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

> 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:

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

Best regards, Julian

Received on Wednesday, 17 February 2010 12:55:51 UTC