- From: Maciej Stachowiak <mjs@apple.com>
- Date: Thu, 18 Feb 2010 18:48:20 -0800
- To: Mark Nottingham <mnot@mnot.net>
- Cc: Julian Reschke <julian.reschke@gmx.de>, Ian Hickson <ian@hixie.ch>, Paul Cotton <Paul.Cotton@microsoft.com>, "public-html@w3.org" <public-html@w3.org>
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.) Regards, Maciej > > > 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 http://www.mnot.net/ >
Received on Friday, 19 February 2010 02:48:57 UTC