- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Fri, 17 Apr 2009 12:34:27 +0200
- To: "Sean B. Palmer" <sean@miscoranda.com>
- CC: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>, www-archive <www-archive@w3.org>
Sean B. Palmer wrote:
> § 4.2.
>
> “Applications that don't merit a registered relation type may use an
> extension relation type, which is a URI [RFC3986] that uniquely
> identifies the relation type.”
>
> Why not use reversed domain names? For example:
>
> Link: <http://example.org/>; rel=index;
> rel="start net.example.rel.other"
>
> The advantage is brevity. Since the specification also says that
> clients SHOULD NOT dereference the URIs identifying the relation
> types, it doesn't seem to matter that the extension type be a URI,
> except for consistency with the URI forms of the registered relation
> types.
> ...
The disadvantages are:
- potential ambiguity when domain ownership changes (which, when using
URIs, can be worked around by choosing a different scheme),
- the requirement to actually have a domain name available for that use, and
- incompatibility with RDF properties and Atom link relations.
> § 5.
>
> “[...] It is semantically equivalent to the
> <LINK> element in HTML, as well as the atom:link feed-level element
> in Atom [RFC4287].”
>
> Doesn't this mean that HTML user agents will have to support the following?
>
> <meta http-equiv="Link" value='<style.css>;
> rel="stylesheet"; type="text/css"'>
I don't think it means that, at least not according to the HTML
specification.
> Why burden HTML user agents in this way? Could you specify that Link
> has no meaning when used in conjunction with meta/@http-equiv in HTML?
It seems that clarifying the use of meta/@http-equiv is something the
HTML WG should do.
> “Here, the second link has a title encoded in UTF-8, uses the German
> language ("de"), and contains the Unicode code point \u'00E4' ("LATIN
> SMALL LETTER A WITH DIAERESIS").”
>
> \u'00E4' is a character, not a code point. A code point in Unicode is
> simply a number, so the code point here is 0xE4, or 228 in decimal.
> The convention for representing a character, moreover, is U+HHHH; in
> this case, you would use U+00E4. I would suggest changing this passage
> to something like:
>
> Here, the second link has a title encoded in UTF-8, uses the German
> language ("de"), and contains the Unicode character U+00E4 ("LATIN
> SMALL LETTER A WITH DIAERESIS").
Correct. That text was suggested by me; Mark, please take out the \u
notation.
> ...
BR, Julian
Received on Friday, 17 April 2009 10:35:14 UTC