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

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