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

On Feb 18, 2010, at 6:07 PM, Mark Nottingham wrote:

> I'm adding:
>> Note that relation types MAY be registered by third parties, if the  
>> Designated Expert determines that the relation type is widely  
>> deployed, and the party or parties responsible for introducing or  
>> implementing the relation type have failed to register it in a  
>> timely manner.
> Workable?

Sounds like an improvement, thanks.

Though it makes me wonder why there is *any* bias towards the inventor  
or initial implementor of a relation type being the one to register  
it. Apple invented and was the first to implement <canvas>, but Ian  
was the first to define it in a spec. That doesn't seem like a  
problem. As far as I recall, he didn't ask our permission either, nor  
did he wait to see if we would spec it first.

Likewise, it seems like anyone should be register a relation, so long  
as the spec for it is consistent with existing public use. What's the  
reason to have a bias in favor of the originator of a relation type?

My other issue is that this still requires a spec, but if even a very  
rough spec would be accepted, that seems ok.

(I note also that none of this should be taken an objection, it's just  
my opinion, and I do not feel strongly about the details.)


> On 18/02/2010, at 12:24 AM, Maciej Stachowiak wrote:
>> On Feb 17, 2010, at 5:15 AM, Julian Reschke wrote:
>>> On 17.02.2010 14:04, Maciej Stachowiak wrote:
>>>> That would address vendor namespaces, but not registration of rel  
>>>> values
>>>> you find arleady in active use by third parties.
>>> Yes, that's what I just said :-).
>> The latter is more what I am concerned about, since people make up  
>> rel values all the time without asking anyone's permission.
>>>>> 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.
>>> I'm aware of that. I was just trying to point out that  
>>> "provisional" doesn't mean "anything goes".
>> No one said it did.
>>>>> 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).
>>> I don't see how this is disallowed for "rel". Write a spec, and  
>>> request registration. What you can't do is specify somebody else  
>>> as relation creator without their agreement.
>> I don't think it's a good idea to leave values in common use  
>> completely undocumented in the registry. It means that a good  
>> samaritan who finds someone else's unregistered header cannot  
>> ensure that it is documented without writing a full specification  
>> that will survive formal review.
>> Like I said, I'm not going to object on this basis, I was just  
>> curious to hear from Mark why there is not any form of provisional  
>> or experimental registration.
>> Regards,
>> Maciej
> --
> Mark Nottingham

Received on Friday, 19 February 2010 02:48:57 UTC