Subject: Re: Review Comments for draft-nottingham-http-link-header-05

From: Julian Reschke <[email-masked]>
Date: Fri, 17 Apr 2009 12:34:27 +0200

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='&lt;style.css&gt;;
>          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

---

From: "Anne van Kesteren" <[email-masked]>
Date: Fri, 17 Apr 2009 12:34:43 +0200

On Fri, 17 Apr 2009 11:47:39 +0200, Sean B. Palmer <[email-masked]>  
wrote:
> § 4.1.
>
>    “[...] However, the URI form
>    of a registered relation type SHOULD NOT be serialised when an
>    application specifies the use of a relation type, because a consuming
>    implementation may not recognise it.”
>
> Why not MUST NOT? You say that applications can identify the tokens
> *internally* using URIs, but not that they may do so externally. So
> logically, you can't serialise a token using its URI, because there is
> nothing at all to say that there is an external equivalence between
> tokens and their URIs.
>
> I suggest adding, to make this clear, that registered relation types
> MUST be compared character for character, as well as in a
> case-insensitive fashion.

I agree with this comment. I'm not that interested in dealing with bug  
reports that we need to handle

   <link rel=http://www.iana.org/assignments/relation/stylesheet href=...>

and such.

> except for consistency with the URI forms of the registered relation

I agree with this comment as well. Using URIs as identifiers leads to  
consumers trying to retrieve the URI. (See Netscape RSS DTD, W3C systeam.)

> has no meaning when used in conjunction with meta/@http-equiv in HTML?

FWIW, HTML5 makes it clear that http-equiv does not work this way. (And in  
HTML4 it was actually a processing instruction for servers that was never  
implemented IIRC.)

-- 
Anne van Kesteren
http://annevankesteren.nl/

---

From: Julian Reschke <[email-masked]>
Date: Fri, 17 Apr 2009 13:28:39 +0200

> consumers trying to retrieve the URI. (See Netscape RSS DTD, W3C systeam.)

I think that's a misleading example, as the DTD URI is *supposed* to be 
dereferenced.

BR, Julian

---

From: "Sean B. Palmer" <[email-masked]>
Date: Fri, 17 Apr 2009 09:48:38 +0000

§ 4.

   “There are two kinds of relation types; registered and extension.”

Change “types;” to “types:”.

§ 4.1.

§ 4.2.

   “Note that while extension relation types are required to be URIs, but
   a serialisation of links MAY specify that they are expressed in
   another form, as long as they can be converted to URIs.”

Delete either “while” or “but”.

§ 5.

§ 6.2.

   “The Link Relation Type registry's initial contents are:”

This table doesn't contain all of the values from the Atom registry:

http://www.iana.org/assignments/link-relations/link-relations.xhtml

Update it to include “service” and “up”.

§ 7.

This Security Considerations section makes no mention of the authority
risks associated with the rev relation, as expounded by you in an
excellent recent essay. Though rev is said to be included for legacy
purposes, there is no “SHOULD NOT” about its usage. Should § 5 be
updated to say that rev SHOULD NOT be used?

Kindest regards,

-- 
Sean B. Palmer, http://inamidst.com/sbp/

---

From: "Sean B. Palmer" <[email-masked]>
Date: Fri, 17 Apr 2009 11:30:23 +0000

On Fri, Apr 17, 2009 at 11:34 AM, Julian Reschke wrote:

> The disadvantages are: [...]
>
> - incompatibility with RDF properties

If you want compatibility with RDF properties, the specification will
have to state that all URI extension relations MUST return a 303 See
Other response when dereferenced, as a consequence of this finding:

http://lists.w3.org/Archives/Public/www-tag/2005Jun/0039

Otherwise, you will have the situation where there can be valid URI
extension relations which aren't compatible with RDF, and that the
only way to test will be to dereference and place burden on the
server.

> and Atom link relations.

Atom link relations are IRIs, whereas the Link header extension
relations only cover URIs. So there's a similar incompatibility case
here, though at least this doesn't require a server dereference to
test.

Overall I see the case that you're making for URIs, but it would be
great if this could be tempered with some prose that mitigates against
the inherent disadvantage of using URIs which Anne van K. has pointed
out.

> It seems that clarifying the use of meta/@http-equiv is something
> the HTML WG should do.

The basic problem here is what happens when an HTML 2 to 4.01 document
is accessed on the filesystem. The behaviour of user agents peeking at
http-equiv is, as Anne van K. points out, not allowed by the HTML 4.01
specification (and none others back to HTML 2; I've checked). But it's
certainly the case that, for example, browsers will try to sniff the
encoding from an http-equiv value for Content-Type when the HTML file
is on the filesystem.

So this is a de facto thing. I'm not sure whether this user agent
behaviour is limited to sniffing an encoding or whether there are
other things that get deployed. Refresh, potentially, though again
this is something that HTML 4.01 explicitly tells people not to do and
yet is still, as far as I know, widely supported.

Kindest regards,

---

From: Julian Reschke <[email-masked]>
Date: Fri, 17 Apr 2009 13:45:34 +0200

> http://lists.w3.org/Archives/Public/www-tag/2005Jun/0039

Why can an XML namespace be an information resource, and a link relation 
can not? (Noting that the www.w3.org serves namespace documents with a 
status of 200).

I'd rather have this specification not go near this whole discussion 
(and yes, previously discussed in 
<http://lists.w3.org/Archives/Public/ietf-http-wg/2009JanMar/0226.html>).

> only way to test will be to dereference and place burden on the

Can you cite a document that states that an RDF property is not an 
Information Resource?

> the inherent disadvantage of using URIs which Anne van K. has pointed

I happen to agree with that, see Point 2 in 
<http://lists.w3.org/Archives/Public/ietf-http-wg/2009JanMar/0223.html>.

BR, Julian

---

From: Noah Slater <[email-masked]>
Date: Fri, 17 Apr 2009 13:27:20 +0100

>    identifies the relation type.”

On an unrelated tangent, this section caused me some initial confusion.

The single example given is:

   Note that link-values may convey multiple links between the same
   target and context IRIs; for example:

       Link: <http://example.org/>; rel=index;
             rel="start http://example.net/relation/other"

I think it would be better to split this into multiple examples to show IRIs
being used as relation types, and another showing IRIs mixed with registered
values. As it stands, it could be mistaken that this forms a single value:

  start http://example.net/relation/other

Perhaps the first use of an IRI in this document should be:

       Link: <http://example.org/>; rel=index;
             rel="http://example.net/relation/other"

Best,

-- 
Noah Slater, http://tumbolia.org/nslater

---

From: Julian Reschke <[email-masked]>
Date: Fri, 17 Apr 2009 14:28:03 +0200

Sean B. Palmer wrote:
> On Fri, Apr 17, 2009 at 12:45 PM, Julian Reschke wrote:
> 
>> Why can an XML namespace be an information resource
> 
> Because Webarch explicitly says so.

I see.

However, allowing an XML namespace to be an Information Resource, but 
disallowing that for a RDF property still looks very arbitrary to me.

>> and a link relation can not?
> 
> Well it can't be if you also want to use it as an RDF property. The
> @xmlns use of a URI is different from the use of a URI when you put it
> in your browser or when you use it in RDF. Similarly, yes, the Link
> header specification could do something like what @xmlns is doing.
> 
> But in that case, it won't be compatible with RDF.
> 
> (You'd have to choose, one or the other.)

Not convinced yet.

Where exactly is the incompatibility?

> That'd be fine by me, and I'd be happy with reversed domain names
> which are anyway incompatible with RDF. But you raised RDF
> compatibility in response, and I'm just pointing out that if this is
> to be so then such compatibility should be done carefully and
> thoroughly.
> 
> There may be other ways to avoid the hornets' nests, of course. But
> the specification should at least be clear about whatever it allows.
> 
> Sure: Webarch, § 2.2.

Section 2.2 does not mention RDF at all. Could you please be more specific?

BR, Julian

---

From: "Sean B. Palmer" <[email-masked]>
Date: Fri, 17 Apr 2009 12:24:22 +0000

Sure: Webarch, § 2.2.

Kindest regards,

---

From: "Sean B. Palmer" <[email-masked]>
Date: Fri, 17 Apr 2009 13:45:48 +0000

On Fri, Apr 17, 2009 at 1:28 PM, Julian Reschke wrote:

> However, allowing an XML namespace to be an Information Resource,
> but disallowing that for a RDF property still looks very arbitrary to me.

Well the idea is that XML namespaces are in a sense apart from the
web. You can see this in the fact that an XML namespace URI doesn't
have to resolve to anything. It can return a 404 over HTTP for
example, and yet you can still use it as an XML namespace.

When RDF wanted to use URIs to identify all sorts of things, an
attempt was made to integrate it properly with the web and not keep it
in some sense separate like XML namespaces. This is what the TAG
ruling that I cited is all about.

> Where exactly is the incompatibility?

Well what I was proposing is that the specification for Link header
extension relations could be done by analogy to XML namespaces. That
would mean that extension relations could:

1. Resolve to nothing, 404ing.
2. Resolve to an information resource, 200ing.

And quite possibly, but not certainly:

3. Resolve to an arbitrary resource, 303ing.

That would be a grey area. In my previous email I thought that it
wouldn't be allowed, that XML namespaces had to be either undefined or
information resources, but I now find this not to be supported by
Webarch.

In this scenario, you're getting a situation where people can create
extension relations which aren't web friendly (1.), and which aren't
RDF compatible (1. and 2.). That's if you take the route of using XML
namespaces as an analogy for how extension relations work in Link.

On the other hand, you could spell it out. You could say, extension
relations must return a 200 or a 303. This would stop people from
getting angry like they did at the XML Special Interest Group's
decision, and prevent the creation of a link-uri list like the old
xml-uri list :-)

But this would also mean that extension relations could be
incompatible with RDF. And in that case, to test whether an extension
relation is compatible you'd have to dereference it. This is arguably,
therefore, not a good solution.

Or you could say, extension relations must return a 303. Then it would
be web friendly and RDF compatible, but it would make extension
relations harder to implement. So this too has a problem.

If the IANA want their registered relation type URIs to be compatible
with RDF, they'll have to make them return 303s too.

If you just have the specification be silent about the issue of what
extension relations identify on the web, then people will ask the
question. It is a slippery area, but you can't avoid it if you're
using URIs in this way.

> Section 2.2 does not mention RDF at all. Could you please be

§ 2.2 defines an information resource, and if you compare that with
the definition of property in the RDF Concept, Schema, and Semantics
recommendations, you'll find them to be incompatible.

Note that § 2.2's definition of “information” is quite strict, as can
be seen from the fact that it doesn't even consider a printed document
to be information that has high fidelity to a message.

Avoiding this altogether may be a good idea, as you suggest. But can
you suggest a way to avoid it that doesn't ditch the use of URIs as
extension relations altogether? Otherwise, these difficulties will
have to be addressed.

I'd prefer reversed domain names, but it's just a suggestion.

Kindest regards,

---

From: Julian Reschke <[email-masked]>
Date: Fri, 17 Apr 2009 17:36:09 +0200

> <http://lists.w3.org/Archives/Public/ietf-http-wg/2009JanMar/0223.html>.

Turns out this was indeed addressed in this draft:

"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. Although the URI MAY point to a resource 
that contains a definition of the semantics of the relation type, 
clients SHOULD NOT access that resource to avoid overburdening its 
server." -- 
<http://greenbytes.de/tech/webdav/draft-nottingham-http-link-header-05.html#rfc.section.4.2.p.1>

BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 17 Apr 2009 18:21:22 +0200

> example, and yet you can still use it as an XML namespace.

How is this different for a RDF *property*? (Not a subject or object!)

> ruling that I cited is all about.

I understand that the "303 hack" is useful for the things RDF makes 
statements *about* -- but that's different from the RDF properties, 
isn't it?

OK, let's test.

As example, got the latest tr.rdf from 
<http://www.w3.org/2002/01/tr-automation/tr.rdf>, and tried Dublin 
Core's dc:date as example.

The prefix dc is mapped to "http://purl.org/dc/elements/1.1/".

Retrieving "http://purl.org/dc/elements/1.1/date" yields a 302 redirect.

So is Dublin Core violating WebArch, and breaking RDF?

> ..

Still not convinced that there *is* an incompatibility.

BTW, the TAG tried to convince IANA of this several months ago, and 
apparently didn't succeed.

I'm not saying that the TAG is right and IANA is wrong, but this shows 
that the whole concept does not yet work in practice.

BR, Julian

---

From: "Sean B. Palmer" <[email-masked]>
Date: Fri, 17 Apr 2009 15:53:45 +0000

On Fri, Apr 17, 2009 at 4:36 PM, Julian Reschke wrote:

> “[...] Although the URI MAY point to a resource that contains a
> definition of the semantics of the relation type, clients SHOULD
> NOT access that resource to avoid overburdening its server."

Does that mean that RDF users would routinely be able to check whether
a 303 is returned, or does it not? If the former, then the SHOULD NOT
injunction doesn't serve its purpose. If not, then there is a
compatibility problem with RDF.

Kindest regards,

---

From: Julian Reschke <[email-masked]>
Date: Fri, 17 Apr 2009 19:29:10 +0200

Sean B. Palmer wrote:
> On Fri, Apr 17, 2009 at 5:21 PM, Julian Reschke wrote:
> 
> Properties can used in the subject or object position, so I'm not sure
> what your question means. If you meant to say predicate, I'm even more
> unsure of what you mean.

I meant predicates (I keep saying "properties" because of my WebDAV 
background :-).

> Yes, and that's dealt with here:
> 
> “As PURL servers use a 302 response code and there is currently no way
> to configure them to use 303 response codes, existing vocabularies
> with http://purl.org slash namespaces servers do not strictly conform
> to the current TAG recommendations.”
> — http://www.w3.org/TR/swbp-vocab-pub/#purls

But DC is not using PURL, so this is just a similar problem.

That being said: if something as widely used as DC (it is, isn't it) 
violates the principle, what *effect* does it have? In practice?

>> I'm not saying that the TAG is right and IANA is wrong, but this
>> shows that the whole concept does not yet work in practice.
> 
> That is partly why I advise to use reversed domain names.

I think URIs as identifiers work just fine. What seems to be problematic 
os the "Information Resource" distinction.

> Do you have a reference to the TAG and IANA discussion, by the way? It
> might be useful not just for me but for others following the current
> thread, if there be such people.

See around <http://lists.w3.org/Archives/Public/www-tag/2009Jan/0114.html>.

BR, Julian

---

From: "Sean B. Palmer" <[email-masked]>
Date: Fri, 17 Apr 2009 16:42:50 +0000

Kindest regards,

---

From: Julian Reschke <[email-masked]>
Date: Fri, 17 Apr 2009 20:43:20 +0200

Sean B. Palmer wrote:
> On Fri, Apr 17, 2009 at 6:29 PM, Julian Reschke wrote:
> 
> But DC *is* using PURL. You even said so in your email:
> 
>   ‘Retrieving "http://purl.org/dc/elements/1.1/date" yields a 302 redirect.
>   So is Dublin Core violating WebArch, and breaking RDF?’
> 
> The purl.org domain is the PURL server.

Oops. Sorry.

> I don't know, it's not my responsibility to defend TAG resolutions and
> RDF specifications. I don't even agree with their design decisions.
> But just ignoring them is going to create new problems.

Understood.

But the fact that the distinction (or the lack of implementation of it) 
doesn't seem to have any effect in practice makes me very skeptical 
about future adoption.

> And anyway, we're reviewing something which is supposed to become an
> RFC. It would be a little strange for us to pick and choose which
> standards we follow and which we don't!

A TAG finding is not a standard. And even if it was, not stating 
anything about retrieval wouldn't conflict with it.

>> What seems to be problematic [i]s the "Information Resource"
> 
> Yes, but as soon as you start to use a URI for something in this way,
> you will get this problem. And Link is so obviously close to the RDF
> model that people are bound to say, “we can harvest RDF from this.”

Indeed.

> What I'm saying is, you cannot avoid this problem by ignoring it.

But people are, and it doesn't seem to cause problems (I'm honestly 
trying to understand the implications!).

> As soon as I saw this URI extension relations mechanism in the draft,
> I realised that it would cause trouble, so I suggested an alternative
> which wouldn't.
> 
> Another alternative would be to remove the extension relations
> entirely. This would be fine by me, and I think that extensibility in
> this area tends to be overrated. Consider, for example, the URN nid

Extensibility is already there for Atom relations, and as far as I 
recall, the TAG likes URI-based extensibility. I wouldn't want to 
sacrifice it because of the 303 debate.

> mechanism. Or even the TAG's current issue about URIs for media types:
> 
> http://www.w3.org/2001/tag/issues.html#uriMediaType-9
> 
> uriMediaType-9 is a strange issue because media types are so seldom
> registered, and so seldom is there a good reason to create a new one,
> that it's worth having a registry for them. You don't need URIs to
> solve this.
> 
> On the other hand, the situation with @rel is a hot topic because of
> the way that the HTML WG have tried to solve the extensibility
> situation, by having a link types registry wiki. Some people object to

...including me....

> this, and Sam Ruby commented recently on the matter:
> 
> “If transparency and approachability are the solutions, then we need
> something radically more transparent and approachable than a wiki
> page.  Now that’s a sobering thought.”
> — http://intertwingly.net/blog/2009/04/14/
> 
> Reversed domain names would solve the social problem without getting
> into architectural permathreads about information resources. But

Reversed domain names would be a new approach to do distributed 
extensibility. If this would be used, people will build bridges between 
the new system and URI based extensibility anyway. So, in essence, it 
would just introduce a new level of indirection, and the original issue 
wouldn't go away.

> whatever the solution, as long as the issues are dealt with properly
> then the specification will have integrity that it ought to have as an
> RFC.

I like the idea of the semantic web. I want things to be compatible with 
RDF. I believe that distributed extensibility based on URIs is good. I 
use it myself.

However: I'm unconvinced that the 303 solution is a good one, and that 
the semantic web will stop working when it gets ignored. If the semantic 
web community is so convinced about it, why isn't there a W3C 
Recommendation which clearly states how to deal with RDF predicates that 
happen to be identified by an HTTP URI? (or is there?)

BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 17 Apr 2009 22:26:20 +0200

Sean B. Palmer wrote:
> On Fri, Apr 17, 2009 at 7:43 PM, Julian Reschke wrote:
> 
>> A TAG finding is not a standard.
> 
> Well, who decides how much standing a TAG finding, or a W3C
> recommendation, or an IETF RFC, or an ISO standard has?

Dunno.

What I was trying to say is that if the W3C wants to make a normative 
statement, it should do so by issuing a Recommendation, because that's 
the closest thing in the W3C Publication System to a Standard.

> But even socially speaking, there is some obvious substance here: the
> TAG finding was announced by Roy Fielding, an author of the HTTP RFC.
> And the TAG chair is another author of the HTTP RFC.

I happen to be aware of that, as I've been spending some time editing 
the latter lately :-).

Anyway, before you cite Roy as authority sanctioning the httprange 
finding, you may want to search the TAG mailing list archive for more of 
his emails around this topic 
(<http://lists.w3.org/Archives/Public/www-tag/2008Feb/0086.html> is an 
example).

> This isn't just somebody's opinion on a mailing list, it's a W3C
> resolution of something that had been causing intense argument for
> years and years.

And continues to do so.

>> And even if it was, not stating anything about retrieval
>> wouldn't conflict with it.
> 
> Well it makes the Web Linking specification inconsistent. If you can
> use extension relations as RDF properties, then the only way you can
> tell whether they're valid is to dereference them. And Web Linking
> says you SHOULD NOT dereference them... so why force people to do it?

Could you elaborate why you need to dereference the URI of an RDF 
predicate to validate it?

> You can be compatible with RDF, or you can be incompatible. But at the
> moment it's being quasi-compatible, which isn't good.
> 
>> (I'm honestly trying to understand the implications!).
> 
> The most concise way that I can put it is this:
> 
> If Link is supposed to be compatible with RDF, then you have to
> explain why you're not mandating 303 responses for extension
> relations. If Link is not supposed to be compatible with RDF, then you
> have to let RDF people know so that they won't be misled.

Again, please cite a normative document that states that the URI used to 
identify an RDF predicate needs to be a non-information resource.

>> Extensibility is already there for Atom relations
> 
> It'd be interesting to survey how often Atom IRI relations are used in
> proportion to Atom registered relations.

Dunno.

>> the new system and URI based extensibility anyway.
> 
> Possibly, but possibly not? The HTML WG link types registry makes it
> look like people care about extensibility. But, to be cynical, perhaps
> they really care about politics and transparency and so on?

What registry do you mean? The one proposed by the WHATWG? The one 
proposed by the XHTML2 WG?

As far as I can tell, HTML4 didn't have a registry, which is part of the 
problem we need to solve.

> Those are good things to care about, but it's not Web Linking's place
> to try to fix that. The point should be to judge how often people are
> really going to want to implement extensions. How can we gauge how
> popular it will be?

We have evidence that people make up new relation names. Whether a 
single central registry is sufficient to deal with that is another 
question. History shows that people try to avoid registration 
procedures, thus having another way to avoid naming conflicts seems to 
be good.

>> I believe that distributed extensibility based on URIs is good.
> 
> Where do you use it, incidentally?

Myself? In WebDAV (properties, protocol extensions such as condition 
names or report names). In JCR (Java Content Repository), identifying 
property and node types. When extending other people's XML vocabularies. 
All the time, really.

>> If the semantic web community is so convinced about it, why isn't
>> there a W3C Recommendation which clearly states how to deal with
>> RDF predicates that happen to be identified by an HTTP URI?
> 
> I'd guess because the RDF Core WG was disbanded before the TAG
> resolution was made, and because it tends to be covered in notes such
> as the following:
> 
> http://www.w3.org/TR/swbp-vocab-pub/
> Best Practice Recipes for Publishing RDF Vocabularies
> 
> http://www.w3.org/TR/cooluris/
> Cool URIs for the Semantic Web
> 
> Again I'm not defending this design, and my proposal is to eschew the
> thing entirely. But if you're going to encourage compatibility with
> RDF, it's got to be done right if Web Linking to be a decent
> specification.

I think it would be helpful if you could point out how having link 
relation URIs resolve to 200 actually is in conflict with an RDF related 
spec, and also how it would have an effect in practice (given the fact 
that DC URIs today do not resolve to 303s either).

BR, Julian

---

From: "Sean B. Palmer" <[email-masked]>
Date: Fri, 17 Apr 2009 19:18:13 +0000

> and as far as I recall, the TAG likes URI-based extensibility

But they haven't resolved uriMediaType-9 yet... :-)