Subject: [link-relations] Looking for some general guidance....

From: mike amundsen <[email-masked]>
Date: Thu, 7 Jul 2011 10:47:24 -0400

PREAMBLE
This is a general request for guidance on authoring, documenting, and
registering link relations. My goal here is to get a handle on what is
going on & what is possible, not try to make judgement on or influence
the process of link relation registration, etc.

To this end, I have some questions regarding identifying the 'registry
of record' (or multiple registries?) to which media-type designers
should adhere as well as some scenarios to use a 'test cases' in order
to learn some details about the process. I am looking for any
comments/correction/feedback I can get as I try to learn as much as I
can about the Link Relations registries and processes.

I offer my apologies up front for the long-ish post. Hopefully it will
result in some clarity for others pondering similar questions. FWIW,
I'd be happy to write up the results of this thread in a declarative
document and post it for public access and/or work w/ others here to
create a more formal/stable document for future reference.

REGISTRIES
I know of the following places that seem to be registries for link relations:
- IANA Link Relations [1]
- Microformats Existing Rel Values [2]
- Paramsr.us - Registering Link Relation Types [3]
- Expressing Dublin Core metadata using HTML/XHTML meta and link elements [4]

Is this a complete list? Are all these places actual link registries?
For example, is the Paramsr.us site actually a processing place for
ultimately shepherding values into the IANA or the Microformats
registries?

PROCESSES
IANA :
I understand that the process for registering link relations for the
IANA is detailed in RFC5988 sec 6.2[5]

Microformats:
I am no clear on the registration process for the Microformats
registry. I _do_ have an account there and have edit rights on that
page [2]. Is that all that is needed? There is a reference on that
page to a "process"[6] but that seems to be aimed at full-on
microformat values (e.g. @class, not @rel).  Am I missing some
documents/descriptions?

Paramsr.us:
It looks like the registration process at Paramsr.us is RFC5988. Is
that right? and discussions of new registrations happen on this list,
correct? It also looks like there has not been much activity here of
late [7] (except for jreschke's entry for "canonical" two weeks ago).

Am I right to assume Paramsr.us is a "clearing house" for adding
values to the IANA Link Relations registry and _not_ a stand-alone
registry itself? If yes, is the Paramsr.us site the _preferred_ place
to use for adding to the IANA registry?

Dublin Core:
I'll leave off discussing DC here as they seem to have their own
separate world<g>.

SCENARIOS
I have two scenarios here that I wanted to put forward to make sure I
understand the way things could go for anyone designing a media type
solution. I am hoping for feedback here on how these cases should be
handled (assuming there may not be wide agreement from all quarters).

Creating a New Media Type
Assume I have created (and registered) a brand new media type. This
media type uses one or more link relations. The media type
documentation identifies a set of link relation values that servers
and clients should be expected to handle.
- Since these link relation values are identified and defined within
the registered media type document, SHOULD/MUST these values also be
registered with IANA or Microformat?
- If these values are not registered w/ IANA/mf, SHOULD/MUST the
values always be expressed as absolute URIs (per RFC5988) even when
they are identified and defined in the media type documentation?
- If one or more of the link relation values is already registered w/
the IANA/mf, SHOULD/MUST the media type doc refer to these registered
values and, if so, is there a standardized format for doing so?

Creating a Metadata Profile for an Existing Media Type
Assume I have created a profile[8] for an existing media type (e.g.
HTML, XML, JSON, etc.). For example, a profile for HTML could identify
values for key attributes (@id, @name, @class, & @rel) in order to add
"semantic meaning" to the representations. In the case of the values
used for the A and LINK elements (@rel attributes).
- SHOULD/MUST these values also be registered with IANA or Microformat?
- If these values are not registered w/ IANA/mf, SHOULD/MUST the
values always be expressed as absolute URIs (per RFC5988) even when
they are identified and defined in the profile documentation?
- If one or more of the link relation values is already registered w/
the IANA/mf, SHOULD/MUST the profile doc refer to these registered
values and, if so, is there a standardized format for doing so?

Again, thanks in advance to all who can provide feedback, correction,
guidance on these items.

Mike Amundsen

[1] http://www.iana.org/assignments/link-relations/link-relations.xml
[2] http://microformats.org/wiki/existing-rel-values
[3] http://paramsr.us/link-relation-types/
[4] http://dublincore.org/documents/dc-html/
[5] http://tools.ietf.org/html/rfc5988#section-6.2
[6] http://microformats.org/wiki/process
[7] http://paramsr.us/tracker/
[8] http://www.w3.org/TR/html4/struct/global.html#h-7.4.4.3

mca
http://amundsen.com/blog/
http://twitter.com@mamund
http://mamund.com/foaf.rdf#me

#RESTFest 2011 - Aug 18-20
http://restfest.org

---

From: Julian Reschke <[email-masked]>
Date: Thu, 07 Jul 2011 17:18:36 +0200

On 2011-07-07 16:47, mike amundsen wrote:
> going on&  what is possible, not try to make judgement on or influence

+1 -- the current situation is kind of unfortunate, and having a neutral 
summary will be very helpful.

> - Expressing Dublin Core metadata using HTML/XHTML meta and link elements [4]

I *think* that RDFa also uses <link>, and that in RDFa 1.1 there's a way 
to register vocabularies. (IMHO one level of indirection too much...)

> ultimately shepherding values into the IANA or the Microformats

It's the tracker the DEs (Designated Experts) use to coordinate 
processing of link relation registrations. As it is used, it happens to 
also to be a registry for things that are "in process". It's for the 
IANA registry only.

> IANA is detailed in RFC5988 sec 6.2[5]

Yes.

> microformat values (e.g. @class, not @rel).  Am I missing some

If you find out, please report back :-) See related thread starting at 
<http://lists.w3.org/Archives/Public/public-html/2011Jun/0314.html>.

> that right? and discussions of new registrations happen on this list,

Yes & Yes.

> late [7] (except for jreschke's entry for "canonical" two weeks ago).

Activity depends on registrations actually coming in :-)

> to use for adding to the IANA registry?

It's for use by the Designated Experts only; people can use it to track 
the status of their registrations, but it's not there to *make* 
registrations.

> registered with IANA or Microformat?

I can't speak for Microformats. For IANA, the answer is that if you want 
your relations to mean the same thing inside your document type, inside 
the Link: header and inside other formats that participate, then yes, 
you should register them.

> they are identified and defined in the media type documentation?

If they weren't, you'd risk name collisions. Dunno whether that 
translates to SHOULD or MUST.

> values and, if so, is there a standardized format for doing so?

I think it would be good to refer to them.

If by "refer to" you mean "use a specific URI for the type" then I fear 
the answer is that IANA hasn't reached that level yet :-)

> values for key attributes (@id, @name, @class,&  @rel) in order to add

[8] refers to an HTML feature that was dropped in HTML5. I believe that 
using profile to wire relation type semantics isn't going to work well, 
as recipients aren't going to look at those, and it also only works when 
there's one profile in use per document (and here's I'm not referring to 
the old permathread about the @profile syntax but the fact that there's 
no disambiguation mechanism).

> they are identified and defined in the profile documentation?

In that case the profile wouldn't be needed (at least not for this use 
case), right?

> ...

Hope this helps somewhat :-)

Best regards, Julian

---

From: mike amundsen <[email-masked]>
Date: Thu, 7 Jul 2011 11:56:47 -0400

> summary will be very helpful.

I'll host a document to start
(http://amundsen.com/media-types/linkrelations/) and, if we like, we
can copy/move it at some future point.

> I *think* that RDFa also uses <link>, and that in RDFa 1.1 there's a way to
> register vocabularies. (IMHO one level of indirection too much...)

Good catch. I'll check into that, too.

> It's the tracker the DEs (Designated Experts) use to coordinate processing
> of link relation registrations. As it is used, it happens to also to be a
> registry for things that are "in process". It's for the IANA registry only.
>
>> PROCESSES
>> IANA :
Check

> <http://lists.w3.org/Archives/Public/public-html/2011Jun/0314.html>.
Yep, been watching that thread. I actually started a convo in the mf
IRC channel and will add my results to the doc.

>> that right? and discussions of new registrations happen on this list,
Double-Check

> Activity depends on registrations actually coming in :-)
Understood

> It's for use by the Designated Experts only; people can use it to track the
> status of their registrations, but it's not there to *make* registrations.
Make sense.

> your relations to mean the same thing inside your document type, inside the
> Link: header and inside other formats that participate, then yes, you should
> register them.
Sounds like a SHOULD, then.

> If they weren't, you'd risk name collisions. Dunno whether that translates
> to SHOULD or MUST.
Yeah, I'd say SHOULD, w/ a warning.

> If by "refer to" you mean "use a specific URI for the type" then I fear the
> answer is that IANA hasn't reached that level yet :-)
Understood. I was hoping that the spec 5988 might indicate each def
should be 'awarded' a URI. I can see that is not the case right now.

> using profile to wire relation type semantics isn't going to work well, as
> recipients aren't going to look at those, and it also only works when
> there's one profile in use per document (and here's I'm not referring to the
> old permathread about the @profile syntax but the fact that there's no
> disambiguation mechanism).
Yep, I understand the HTML5 status. In my case, I am adopting a
@profile pattern in some media type designs even though HTML5 has
dropped it (call me stubborn?). My meaning here was not to advocate
for that particular pattern, but instead to bring up the case where
new, unregistered @rel values are added to an existing media type. My
example went a bit too far afield :<

> In that case the profile wouldn't be needed (at least not for this use
Again, the profile is not the point I want to discuss here, just the
use of new rels in an existing media type vs. the first scenario of
new rels in a new media type;  my bad for throwing that into the mix
here.

I think I am hearing (from you) that, regardless of whether a new @rel
value is defined in a media type (my first scenario) or just "applied"
to an existing type (my second scenario), it SHOULD be registered.

> Hope this helps somewhat :-)
Yep, very good start. thanks!

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 8 Jul 2011 21:05:20 +0200

On 7 July 2011 16:47, mike amundsen wrote:

> My goal here is to get a handle on what is going on & what
> is possible, not try to make judgement on or influence

Well, I tested the procedure here, because the HTML5 folks
claimed that it does not work and/or is too much work.  The
result was okay, but required an understanding of what
constitutes an "appeal" (= bothering an Area Director in an
email to enforce any kind of decision).  Hopefully this was
an exception, and the experts dare write NAK in the future
if they really do not want to write ACK.

I didn't test the Wiki, but looked into it:  It contains an
years old draft claiming that this will be transformed into
a better spec. very soon.  From these examples I concluded
that I'll stick to IETF/IANA and ignore HTML5/wiki wrt link
relation registrations -- this does not affect WhatWG HTML
by definition, I'd follow their odd "moving target" concept.

Maybe this is like the alpha (canary, aurora, prerelease) -
beta (developer, RC) - stable classification; the relations
in the IANA registry are at the "stable" end (from my POV).

-Frank

---

From: mike amundsen <[email-masked]>
Date: Fri, 8 Jul 2011 18:34:39 -0400

<snip>
> in the IANA registry are at the "stable" end (from my POV).
</snip>
Yeah, i kinda see that as a possible "strategy" or "path" for registration:
- post it the Microformats (work out any conflicts, questions, etc.)
- once things are settled in MIcroformats begin the IANA link rel process

mca

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 9 Jul 2011 01:40:59 +0200

On 9 July 2011 00:34, mike amundsen <[email-masked]> wrote:

> a possible "strategy" or "path" for registration:

If it's a new + proposed relation without some kind of proper
specification a Wiki page for a collaboration sounds good.
However, you would need lots of contributors, or you somehow
have to "convene" interested folks to work on the Wiki page.

The traditional IETF way would be a mailing list - that's not
this list used for review, but not for drafting new relations.
The IETF APPS list could be a starting point.

If you pick the Internet Drafts => RFC approach it would take
*much* more time, but any RFC almost guarantees some kind of
reputation, even if it ends up as "experimental" with folks
in the IESG hating you (or v.v., fondly remembering 4408 :-)

Thanks for the <URL:http://paramsr.us> link, I didn't know
that there is an issue tracker for pending relation requests.

-Frank

---

From: mike amundsen <[email-masked]>
Date: Fri, 8 Jul 2011 19:54:59 -0400

> have to "convene" interested folks to work on the Wiki page.
i think the wiki thing is pretty "loose" right now. i plan on posting
some stuff in the non-HTML section there to see how it plays out. i'll
keep notes on my public page:
http://amundsen.com/media-types/linkrelations

> The IETF APPS list could be a starting point.
I get the impression that, when you get to the point of haveing a
completed "template", you can use the paramsr.us site to kick off the
process right from that site [1]

> that there is an issue tracker for pending relation requests.

[1] http://paramsr.us/tracker/issue?@template=item

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 30 Jul 2011 08:49:50 -0700

> that there is an issue tracker for pending relation requests.

I'm hoping that we can eventually get rid of paramsr.us, but clarifying and simplifying the RFC (yes, there's already been discussion of bis) and making some corresponding changes in both the registration procedure and the interface at IANA.

More info soo, but input (as always) welcome.

Cheers,

--
Mark Nottingham   http://www.mnot.net/