- From: Mark Nottingham <mnot@mnot.net>
- Date: Fri, 25 Sep 2009 10:22:55 +1000
- To: Ian Hickson <ian@hixie.ch>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
On 24/09/2009, at 7:34 PM, Ian Hickson wrote: >> >> Nevertheless -- how do other people feel about restricting to one rel >> attribute in the Link header? Looking back at 2068, the BNF >> implicitly >> allows multiple rel values, but it isn't explicitly addressed in the >> prose, so Ian does have a point -- you could see it either way. > > I'm not talking about one rel value, I'm talking about one > attribute, of > any of the attributes. One "hreflang", one "media", one "type", etc. and I said "attribute." See subsequent proposals. >>>>> Why should HTML5 define how rel=stylesheet of a CSS file applies >>>>> to an XML document? That doesn't sound right at all. >>>> >>>> My understanding was that HTML5 is not only defining the HTML >>>> syntax, but also the model for what a "web browser" is and does; if >>>> that's the case, it's one place to put it. >>> >>> That is not the case. HTML5 defines HTML, and how all classes of >>> HTML >>> processors, whether search engines, editors, or anything else, are >>> to >>> process HTML. >>> >>> It does not define how an XML+CSS processor is to handle an HTTP >>> header. >> >> OK. The point is that some XML+CSS spec needs to define this >> behaviour. > > I don't see why an XML spec or a CSS spec or even an XML+CSS spec > would > define the behaviour of an HTTP header. Surely the spec for the HTTP > header would be the one to define the behaviour of the HTTP header. It's not defining the relation of an HTTP header, Ian; it's defining the semantics of a link relation when used with XML and CSS. >>>>> Regardless of who manages the registry, I would like to request >>>>> that the registration mechanism be made significantly simpler than >>>>> the one described in the spec. >>>> >>>> Do you have concrete suggestions for the IANA process to be used? >>> >>> I would suggest that the IANA host a wiki that anyone can edit. >> >> The point of having a registry is to act as a gateway, to assure >> appropriate review and coordination. Allowing anyone to edit the >> contents removes these benefits; people wanting to mint new relations >> without coordination or even review can do so by using extension >> relations. > > People will and do mint keywords without coordinating with us or > asking > for our review. > > Our choice is just whether we want them to register these keywords > first, > or whether we want them to not register them first. > > Whether they register them will depend on whether we make it easy or > not. > > I'm not making any judgements about whether this behaviour is > desireable, > good, bad, or the right way to do things. It's just how things are. > Ignoring it is just going to make the registry irrelevant in practice. Of course they will do this; the draft already takes the stance that unrecognised (i.e., not in the registry, or not implemented by the app) relation types have purely localised meaning; i.e., they may mean something in a particular context, but all bets are off beyond that. Allowing people to register up-front without any review or coordination allows people to register without forethought, leading to very fuzzy semantics and interoperability problems -- ultimately causing more problems than it solves. We're already seeing this with the Atom relations registry. Early experience with reviewing relations (e.g., "hub") is also promising; developers have expressed a willingness to work with the community to do the right thing, and we've been able to find ways to meet their requirements while still assuring that the relations are well-defined and fit into the link framework. > Also, it's worth noting that the HTML5 RelExtensions registry today > is a > wiki. That registry allows people to register arbitrary keywords. If > we > want that registry to be a subset of the registry you are defining, > then > it needs to be as easy (or easier) to register things in the > registry you > are defining as in the RelExtensions wiki. Otherwise, people will > register > keywords for HTML's rel="" attribute, since doing so is trivial, but > will > not bother to register them in the "higher level" registry, because > doing > so will be more work than they want to do. > > If this happens, then either the goal of preventing clashes between > HTML > and Atom won't have been met (at least, not by the registry with the > more > onerous registration requirements). Yes, but that seems like a problem completely of your own creation, Ian. > On Mon, 21 Sep 2009, Mark Nottingham wrote: >> >> I've just added: >> >> The "rel" parameter MUST NOT appear more than once in a given >> link-value; occurrences after the first MUST be ignored by parsers. >> >> and adjusted the examples to suit. Does that address your concern? > > I couldn't find the updated I-D on tools.ietf.org; is this the version > with this fix?: > > http://tools.ietf.org/html/draft-nottingham-http-link-header-06 No, I haven't updated the I-D yet, since it's in last call. See: http://www.mnot.net/drafts/draft-nottingham-http-link-header-07.txt with diff at: http://www.mnot.net/drafts/draft-nottingham-http-link-header-07-from-6.diff.html > In general, if the attributes can each only be listed once, and the > spec > says how to handle (e.g. ignore) duplicates, then my concern is > addressed. OK. > I've just changed the 'title'-related text to: >> >> The "title" parameter, when present, is used to label the >> destination of >> a link such that it can be used as a human-readable identifier >> (e.g. a >> menu entry). The "title" parameter MUST NOT appear more than once >> in a >> given link-value; occurrences after the first MUST be ignored by >> parsers. >> >> The "title*" parameter MAY be used encode this label in a different >> character set, and/or contain language information as per <xref >> target="RFC2231"/>. When using the enc2231-string syntax, producers >> MUST >> NOT use a charset value other than 'ISO-8859-1' or 'UTF-8'. The >> "title*" >> parameter MAY appear more than once in a given link-value, but each >> occurrence MUST indicate a different language; occurrences after the >> first for a given language MUST be ignored by parsers. >> >> When presenting links to users, agents SHOULD use the most >> appropriate >> "title*" value, according to user preferences. If an appropriate >> "title*" value cannot be found, the "title" parameter's value, if >> available, can be used. >> >> Does this work? > > Seems reasonable, though I am still skeptical as to the use of the > title* > feature in practice. It seems better to me to just have one title > attribute, in one language, and to upgrade HTTP to support UTF-8 in > headers. That's already been discussed extensively, and that's not the direction things are going in (certainly for pre-existing headers like Link). Cheers, -- Mark Nottingham http://www.mnot.net/
Received on Friday, 25 September 2009 00:23:48 UTC