Subject: draft-nottingham-http-link-relation-07 progress

From: Mark Nottingham <[email-masked]>
Date: Wed, 2 Dec 2009 17:00:44 +1100

Based on Last Call feedback, as well as discussions with members of the HTML5 WG, I've taken another pass at this spec.

There's a complete change listing at the end of the spec, as well as a diff, but the biggest change is in the registry itself; it now allows extension "fields" to be registered by third parties, to aid in deploying applications that want to leverage the registry.

See:
  http://www.mnot.net/drafts/draft-nottingham-http-link-header-07.txt
and
  http://www.mnot.net/drafts/draft-nottingham-http-link-header-07-from-6.diff.html

Cheers,

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

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 2 Dec 2009 00:30:42 -0700

Overall I like the use of 'well-defined' as qualifier instead of 'Commonly-used', and the fact a registered relation type can be protocol specific. But the changes take away from the usefulness of the registry by making it a suggestion, not a requirement for using short relation types.

> Section 4

> Link relation types can also be used to indicate that the target	
> resource has particular attributes, or exhibits particular	
> behaviours; for example, a "service" link implies that the identified	
> resource is part of a defined protocol (in this case, a service	
> description).

I would rather make it clear that this is a subjective description in the same way the 'type' attribute is used. Relation types are not the proper way to provide metadata for *another* resource.

> Section 4.1
>
>   Well-defined relation types SHOULD be registered as tokens for
>   convenience and to promote reuse.  This specification establishes an
>   IANA registry of such relation types; see Section 6.2.

...

> 4.2.  Extension Relation Types
>
>   Applications that don't wish to register a relation type may use an
>   extension relation type, which is a URI [RFC3986] that uniquely
>   identifies the relation type.

This suggests that the entire registry is optional, even for non-URI (extension) relation types. That registration is just a better way of going about it, but in no way required. The only stick we have to motivate people to register is to say they violate a standard (the carrot is a record in the registry for future fame and glory). With this language, I am not sure why anyone would bother.

Then in section 5:

>   Note that extension relation types are REQUIRED to be absolute URIs
>   in Link headers, and MUST be quoted if they contain a semicolon (";")
>   or comma (",").

This suggests that in HTTP Link header, you MUST register short-name relation types which contradicts the above SHOULD.

Back to 4.2:

>   Registered relation types MUST NOT constrain the media type of the
>   context IRI, and MUST NOT constrain the available representation
>   media types of the target IRI.  However, they MAY specify the
>   behaviours and properties of the target resource (e.g., allowable
>   methods, request and response media types which must be supported).

I am not sure what you mean by "MUST NOT constrain the available representation media types of the target IRI". A registered relation type should be able to mandate a specific target media type, which is how most protocols use links. Does this mean a protocol is allowed to limit its use of links with specific 'type' attributes, but not to limit the registration of the relation type to such media types?

EHL

> -----Original Message-----
> From: [email-masked] [mailto:apps-discuss-
> [email-masked]] On Behalf Of Mark Nottingham
> Sent: Tuesday, December 01, 2009 10:01 PM
> To: Apps Discuss
> Subject: draft-nottingham-http-link-relation-07 progress
> 
> Based on Last Call feedback, as well as discussions with members of the
> HTML5 WG, I've taken another pass at this spec.
> 
> There's a complete change listing at the end of the spec, as well as a diff, but
> the biggest change is in the registry itself; it now allows extension "fields" to
> be registered by third parties, to aid in deploying applications that want to
> leverage the registry.
> 
> See:
> _______________________________________________
> Apps-Discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: John Panzer <[email-masked]>
Date: Tue, 1 Dec 2009 23:33:47 -0800

Why the change to case-insensitive comparisons for URIs used as link
relations?  ("When extension relation types are compared, they MUST be
compared as URIs in a case-insensitive fashion, character-by-character.")

--
John Panzer / Google
[email-masked] / abstractioneer.org / @jpanzer

On Tue, Dec 1, 2009 at 10:00 PM, Mark Nottingham <[email-masked]> wrote:

> There's a complete change listing at the end of the spec, as well as a
> diff, but the biggest change is in the registry itself; it now allows
> extension "fields" to be registered by third parties, to aid in deploying
> applications that want to leverage the registry.
>
> See:

---

From: Jan Algermissen <[email-masked]>
Date: Wed, 02 Dec 2009 10:03:40 +0100

On Dec 2, 2009, at 8:33 AM, John Panzer wrote:

> relations?  ("When extension relation types are compared, they MUST  
> be compared as URIs in a case-insensitive fashion, character-by- 
> character.")

Additional comment: isn't there a spec that can be referenced that  
specifies URI equality rules?

"When extension relation types are compared, they MUST be compared  
according to the equality rules defined by X"

Jan

> Based on Last Call feedback, as well as discussions with members of  
> the HTML5 WG, I've taken another pass at this spec.
>
> There's a complete change listing at the end of the spec, as well as  
> a diff, but the biggest change is in the registry itself; it now  
> allows extension "fields" to be registered by third parties, to aid  
> in deploying applications that want to leverage the registry.
>
> See:

--------------------------------------
Jan Algermissen

Mail: [email-masked]
Blog: http://algermissen.blogspot.com/
Home: http://www.jalgermissen.com
--------------------------------------

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 2 Dec 2009 09:30:30 -0700

Unfortunately no. There is no standard way (I'm aware of) to canonicalize a URI in a consistent way. This is why specs like OAuth have to spell out how to perform percent encoding and other transformations to ensure a consistent string.

EHL

> [email-masked]] On Behalf Of Jan Algermissen
> Sent: Wednesday, December 02, 2009 1:04 AM
> To: John Panzer
> Cc: Apps Discuss
> Subject: Re: draft-nottingham-http-link-relation-07 progress
> 
> 
> Additional comment: isn't there a spec that can be referenced that specifies
> URI equality rules?
> 
> > extension "fields" to be registered by third parties, to aid in
> > deploying applications that want to leverage the registry.
> >
> > See:
> > http://www.mnot.net/drafts/draft-nottingham-http-link-header-07-from-
> 6
> > .diff.html
> >
> > Cheers,
> >
> > --

---

From: Julian Reschke <[email-masked]>
Date: Wed, 02 Dec 2009 17:43:26 +0100

> Unfortunately no. There is no standard way (I'm aware of) to canonicalize a URI in a consistent way. This is why specs like OAuth have to spell out how to perform percent encoding and other transfo…

<http://greenbytes.de/tech/webdav/rfc3986.html#rfc.section.6.2.2.2>?

BR, Julian

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 2 Dec 2009 11:03:45 -0700

It's a good start but not enough. The text itself points out the various problems with normalization but does not address all of them with normative language. Normalization must be nothing but a long list of MUSTs and MUST NOTs.

When we first pointed developers to 3986 for OAuth normalization needs, nothing worked...

EHL

> From: Julian Reschke [mailto:[email-masked]]
> Sent: Wednesday, December 02, 2009 8:43 AM
> To: Eran Hammer-Lahav
> Cc: Jan Algermissen; John Panzer; Apps Discuss
> > Unfortunately no. There is no standard way (I'm aware of) to canonicalize a
> URI in a consistent way. This is why specs like OAuth have to spell out how to
> perform percent encoding and other transformations to ensure a consistent
> string.
> > ...
>

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 3 Dec 2009 12:14:03 +1100

I think the text is pretty clear; if you don't want to register a relation type, you need to use an extension relation type, whose syntax is constrained to that of a URI.

I actually am considering getting rid of extension relation types altogether; we haven't seen them in the wild, and the barriers to registration are considerably lower. Combine this with the carrot of machine-readable registry information (with application-specific fields), and I think there's quite a strong motivation to register.

Cheers,

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 3 Dec 2009 12:15:08 +1100

This was requested by the HTML5 folks, since rel values historically are case-insensitive.

I agree that it feels a bit weird, but it doesn't seem harmful, and is necessary for backwards compatibility.

Cheers,

On 02/12/2009, at 6:33 PM, John Panzer wrote:

> Why the change to case-insensitive comparisons for URIs used as link relations?  ("When extension relation types are compared, they MUST be compared as URIs in a case-insensitive fashion, character-by-character.") 
> 
> 
> --
> John Panzer / Google

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 3 Dec 2009 12:16:06 +1100

Huh? I don't see how you get that out of that text.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 3 Dec 2009 12:17:00 +1100

It must not constrain them; i.e., it can't say "you can only have these media types there." This doesn't preclude it from mandating that a particular type is available.

Cheers,

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 2 Dec 2009 19:01:28 -0700

It was late and I was not paying attention...

I read it as 'Non-extension relation...'.

EHL

> From: Mark Nottingham [mailto:[email-masked]]
> Sent: Wednesday, December 02, 2009 5:16 PM
> To: Eran Hammer-Lahav
> Cc: [email-masked]
> > This suggests that in HTTP Link header, you MUST register short-name
> relation types which contradicts the above SHOULD.
> 
> 
> --

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 2 Dec 2009 19:05:41 -0700

I disagree.

You define two classes of relations types and explain their syntax. But you then make the registration part a SHOULD. It is not clear if the SHOULD is about the need to register short names, or a guidance on when to consider not using an extension and registering instead.

As for removing the extension type, there are still plenty of cases when a relation type is so specific, it should not be registered.

EHL

> Sent: Wednesday, December 02, 2009 5:14 PM
> To: Eran Hammer-Lahav
> I think the text is pretty clear; if you don't want to register a relation type,
> you need to use an extension relation type, whose syntax is constrained to
> that of a URI.
> 
> I actually am considering getting rid of extension relation types altogether;
> we haven't seen them in the wild, and the barriers to registration are
> considerably lower. Combine this with the carrot of machine-readable
> registry information (with application-specific fields), and I think there's quite
> a strong motivation to register.
> 
> Cheers,
> 
> > This suggests that the entire registry is optional, even for non-URI
> (extension) relation types. That registration is just a better way of going
> about it, but in no way required. The only stick we have to motivate people
> to register is to say they violate a standard (the carrot is a record in the
> registry for future fame and glory). With this language, I am not sure why
> anyone would bother.
> 
> 
> --

---

From: Peter Keane <[email-masked]>
Date: Wed, 2 Dec 2009 23:52:54 -0600

On Wed, Dec 2, 2009 at 8:05 PM, Eran Hammer-Lahav <[email-masked]>wrote:

> I disagree.
>
> You define two classes of relations types and explain their syntax. But you
> then make the registration part a SHOULD. It is not clear if the SHOULD is
> about the need to register short names, or a guidance on when to consider
> not using an extension and registering instead.
>
> As for removing the extension type, there are still plenty of cases when a
> relation type is so specific, it should not be registered.
>
>
+1 (re: v. specific rel types that ought not be registered)

--peter keane

---

From: Julian Reschke <[email-masked]>
Date: Thu, 03 Dec 2009 13:20:33 +0100

Peter Keane wrote:
> 
> On Wed, Dec 2, 2009 at 8:05 PM, Eran Hammer-Lahav <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     I disagree.
> 
>     You define two classes of relations types and explain their syntax.
>     But you then make the registration part a SHOULD. It is not clear if
>     the SHOULD is about the need to register short names, or a guidance
>     on when to consider not using an extension and registering instead.
> 
>     As for removing the extension type, there are still plenty of cases
>     when a relation type is so specific, it should not be registered.
> 
> 

Absolutely.

BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Sun, 06 Dec 2009 19:33:30 +0100

> There's a complete change listing at the end of the spec, as well as a diff, but the biggest change is in the registry itself; it now allows extension "fields" to be registered by third parties, to…

Thanks, Mark.

Comments below:

3.  Links

    This specification does not place restrictions on the cardinality of
    links; there can be multiple links from and to a particular IRI, and
    multiple links of different types between two given IRIs.  Likewise,
    the relative ordering of links in any particular serialisation, or
    between serialisations (e.g., the Link header and in-content links)
    is not specified or significant in this specification; applications
    that wish to consider ordering significant MAY do so.

s/MAX/can/

That being said, see TimBL's comment in
<http://lists.w3.org/Archives/Public/www-tag/2009Dec/0038.html>.

4.1.  Registered Relation Types

Compared to earlier drafts, this seems to suggest that any well-defined
relation should be registered. Previously we had

    "Commonly-used relation types with a clear meaning that are shared
    across applications can be registered as tokens for convenience and
    to promote reuse." (draft 06)

Is this really a change we want to make? If yes, what would be the feedback
for the relations defined by CMIS (currently using extension types), such
as "http://docs.oasis-open.org/ns/cmis/link/200908/typedescendants" (see
<http://docs.oasis-open.org/cmis/CMIS/v1.0/cd04/cmis-spec-v1.0.html#_Toc243712631>)?

    Applications that don't wish to register a 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 automatically access that resource to avoid
    overburdening its server.

s/MAY/can/

    When extension relation types are compared, they MUST be compared as
    URIs in a case-insensitive fashion, character-by-character.

Should we add guidance about how to mint the URIs then, such as "prefer
all-lowercase"?

5.  The Link Header Field

    Each link-value conveys one target IRI as a URI-Reference (after
    conversion to one, if necessary; see [RFC3987], Section 3.1) inside
    angle brackets ("<>").  If the URI-Reference is relative, parsers
    MUST resolve it as per [RFC3986], Section 5.  Note that any base IRI
    from the body's content is not applied.

(maybe clarify "body" here)

    The relation type of a link is conveyed in the "rel" parameter's
    value.  The "rev" parameter has also been used for this purpose
    historically by some formats, and MAY be accommodated as a link-
    extension, but its use is neither encouraged nor defined by this
    specification.

Jonathan Rees points out in 
<http://lists.w3.org/Archives/Public/www-tag/2009Dec/0052.html>
that this makes it sound as if rev and rel are synonymous.

5.1.  Examples

    NOTE: Non-ASCII characters used in prose for examples are encoded
    using the format "Backslash-U with Delimiters", defined in Section
    5.1 of [RFC5137].

I think this note needs to be removed; it's not true anymore.

    The example below shows an instance of the Link header encoding
    multiple links, and also the use of RFC 2231 encoding to encode both
    non-ASCII characters and language information.

    Link: </TheBook/chapter2>;
          rel="previous"; title*=UTF-8'de'letztes%20Kapitel,
          </TheBook/chapter4>;
          rel="next"; title*=UTF-8'de'n%c3%a4chstes%20Kapitel

    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").

"Here, both links have titles encoded in UTF-8, use the German language
("d"), and the second one contains the Unicode code point..."

6.2.  Link Relation Type Registry

    [[ Note to RFC Editor: Entries in the Atom registry that are not
    listed below at the time that IANA implements this change (i.e.,
    those that are registered before this document comes into effect)
    should be referred to the Designated Expert. ]]

Not sure that the RFC Editor is the right audience here; shouldn't it be 
the IESG?

6.2.1.  Registering new Link Relation Types

    Within at most 14 days of the request, the Designated Expert will
    either approve or deny the registration request, communicating this

(I think 14 days is really short; if the designated expert lived in 
Germany, for instance, being on vacation for two weeks in a row wouldn't 
be THAT exceptional).

    decision to the review list.  Denials should include an explanation
    and, if applicable, suggestions as to how to make the request
    successful.  Registration requests that are undetermined for a period
    longer than 21 days MAY be brought to the IESG's attention (using the
    [email-masked] mailing list) for resolution.

s/MAY/can/

7.  Security Considerations

    Applications that take advantage of typed links should consider the
    attack vectors opened by automatically following, trusting, or
    otherwise using links gathered from HTTP headers.  In particular,
    Link headers that use the "anchor" parameter to associate a link's
    context with another resource should be treated with due caution.

(maybe the case where anchor is needed on a non-GET response without
Content-Location response should be mentioned as a case where anchor
actually is needed; maybe this belongs somewhere else though).

Appendix B.  Notes on Using the Link Header with HTML4

    HTML4 also has a "rev" parameter for links that allows a link's
    relation to be reversed.  The Link header does not define a
    corresponding "rev" parameter to allow the expression of these links
    in HTTP headers, due to the confusion this mechanism causes as well
    as conflicting interpretations among HTML versions.

I think the part about the "conflicting interpretations" should be
explained somewhere for future reference (I'm still not sure I 
understand it).

    Individual applications of linking will therefore need to define
    their extension links should be serialised into HTML4.

s/define their/define how their/?

That being said, shouldn't we state a default?

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 14 Dec 2009 14:28:51 +1100

Thanks, Julian. Most changes made (see links as before), some responses inline:

On 07/12/2009, at 5:33 AM, Julian Reschke wrote:
> Is this really a change we want to make?

Thinking about this, I've come to a point where I have a hard time justifying segregating the different types of relations. Much of the demand for typed links seems to be for very specific relations, and indeed a "good" relation is very tightly defined. As such, it's difficult to say -- even for the Designated Expert, much less a prospective relation author -- whether something is going to be commonly used. Arbitrarily relegating application-specific relations to extensions (with all of the negative connotations that brings -- justified or not) doesn't seem to solve as many problems as it potentially causes.

> If yes, what would be the feedback

They need to be well-defined; some of them look like they are (at a glance), and some do not (e.g., the 'changes' one seems quite muddy, on the face of it). Beyond that, if I were DE, I'd probably ask for some of them to be prefixed by 'cmis' to assure that they're not grabbing potentially more generic semantics.

Thoughts?

> (I think 14 days is really short; if the designated expert lived in Germany, for instance, being on vacation for two weeks in a row wouldn't be THAT exceptional).

This is why "Designated Expert(s)" is specified; the intent being that there are at least two, mostly to assure that the deadline is met.

Cheers,

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 14 Dec 2009 00:05:40 -0700

> Sent: Sunday, December 13, 2009 7:29 PM
> To: Julian Reschke
> Cc: Apps Discuss
> > Compared to earlier drafts, this seems to suggest that any
> > well-defined relation should be registered. Previously we had
> >
> Thinking about this, I've come to a point where I have a hard time justifying
> segregating the different types of relations. Much of the demand for typed
> links seems to be for very specific relations, and indeed a "good" relation is
> very tightly defined. As such, it's difficult to say -- even for the Designated
> Expert, much less a prospective relation author -- whether something is
> going to be commonly used. Arbitrarily relegating application-specific
> relations to extensions (with all of the negative connotations that brings --
> justified or not) doesn't seem to solve as many problems as it potentially
> causes.

I would justify the two types of relations by their different review "cost". If someone doesn't want to bother with the registration process, and is satisfied with using a URI, let them. There are many cases in which a registration would be an overkill or inappropriate (intranet applications, experimental, short-lived, undocumented or semi-private, etc.). 

On the other hand, by providing a path to a registered short-name we encourage better definition, documentation, and seeking community review. Even if the relation type isn't commonly used, it provides a public documentation of the use case. I also agree that it is hard to prove something is going to be widely useful.

> > for the relations defined by CMIS (currently using extension types),
> > such as
> > "http://docs.oasis-open.org/ns/cmis/link/200908/typedescendants" (see
> They need to be well-defined; some of them look like they are (at a glance),
> and some do not (e.g., the 'changes' one seems quite muddy, on the face of
> it). Beyond that, if I were DE, I'd probably ask for some of them to be
> prefixed by 'cmis' to assure that they're not grabbing potentially more
> generic semantics.
> 
> Thoughts?

Maybe some recommendation in the spec about naming conventions? Something along the lines of non-novel names should not be used for very narrow cases.

As long as the extension type is still available, I am supportive of this new well-defined approach. But we might need to give the DE a bit more to work with.

EHL

---

From: Julian Reschke <[email-masked]>
Date: Mon, 14 Dec 2009 15:47:49 +0100

> Thinking about this, I've come to a point where I have a hard time justifying segregating the different types of relations. Much of the demand for typed links seems to be for very specific relation…

Two thoughts:

- If we move from "must be of general use" to "almost anything goes", 
then I'm expecting many more attempts of registering short names. Are 
the DEs willing to handle that load?

- Furthermore, this appears to be a rather big change compared to what 
earlier drafts said, so I think we'd need to go back to IETF LC.

> They need to be well-defined; some of them look like they are (at a glance), and some do not (e.g., the 'changes' one seems quite muddy, on the face of it). Beyond that, if I were DE, I'd probably…

It's a bit ironic in that's exactly how CMIS started something like one 
year ago, until we told them that they should either use extension 
relations, or make the relations more generic :-).

Best regards, Julian

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 15 Dec 2009 14:11:20 +0900

I agree that RFC 3986 (and RFC 3987) are not of direct use for defining 
anything like a normalization of URIs (or IRIs). The main reason for 
this is that there are different contexts in which you may have 
different knowledge (e.g. of scheme specific default ports) and may 
prefer aggressive or cautionary normalization. The safe side of the 
normalization range is on different ends depending on what you are doing.

As we are working on an update to RFC 3987, what I'm wondering is 
whether it may be possible to improve the text in RFC 3987 (which is 
mostly a copy of the one in RFC 3986, with some additions due to the 
bigger character repertoire) so that it becomes easier for an 
application such as OAuth to define what they need just with a few 
pointers (e.g. "from Section X of the IRI spec, use foo, baz, and frof 
normalizations but not bar") rather than defining everything ab initio.

Would that help? Or does nobody care?

Regards,   Martin.

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:[email-masked]

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 15 Dec 2009 16:51:34 +1100

On 15/12/2009, at 1:47 AM, Julian Reschke wrote:
> 
> Two thoughts:
> 
> - If we move from "must be of general use" to "almost anything goes", then I'm expecting many more attempts of registering short names. Are the DEs willing to handle that load?

Since they're not selected yet, it's hard to say. However, "almost anything goes" isn't a good characterisation; it's still specification required...

> - Furthermore, this appears to be a rather big change compared to what earlier drafts said, so I think we'd need to go back to IETF LC.

We've had enough changes that I think that's going to be necessary anyway.

> It's a bit ironic in that's exactly how CMIS started something like one year ago, until we told them that they should either use extension relations, or make the relations more generic :-).

Perhaps, but I'd rather get it right.

Cheers,

---

From: Ted Hardie <[email-masked]>
Date: Tue, 15 Dec 2009 09:55:17 -0800

On Mon, Dec 14, 2009 at 9:11 PM, "Martin J. Dürst"
<[email-masked]> wrote:
> anything like a normalization of URIs (or IRIs). The main reason for this is
> that there are different contexts in which you may have different knowledge
> (e.g. of scheme specific default ports) and may prefer aggressive or
> cautionary normalization. The safe side of the normalization range is on
> different ends depending on what you are doing.
>
> As we are working on an update to RFC 3987, what I'm wondering is whether it
> may be possible to improve the text in RFC 3987 (which is mostly a copy of
> the one in RFC 3986, with some additions due to the bigger character
> repertoire) so that it becomes easier for an application such as OAuth to
> define what they need just with a few pointers (e.g. "from Section X of the
> IRI spec, use foo, baz, and frof normalizations but not bar") rather than
> defining everything ab initio.
>

I think it would be very useful, partly because it would allow
descriptions of comparison techniques to say "The FOO comparison
starts with the application of the BAR normalization
then applies the following steps".  This simplifies the necessary
description of the comparison methods, and it seems likely to improve
the selection among comparison methods by protocol designers as
well.

Just my two cents,

Ted

>> It's a good start but not enough. The text itself points out the various
>> problems with normalization but does not address all of them with normative
>> language. Normalization must be nothing but a long list of MUSTs and MUST
>> NOTs.
>>

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 30 Dec 2009 10:26:06 +1100

> Maybe some recommendation in the spec about naming conventions? Something along the lines of non-novel names should not be used for very narrow cases.

How about (after the other requirements on relation names):
 
They SHOULD be appropriate to the specificity of the relation; i.e., if the semantics are highly specific to a particular application, the name should reflect that, so that more general names are available for less specific use.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 29 Dec 2009 23:43:35 -0700

I like this. This is where I think we are:

-- Use a URI relation type when:

* Don't want or cannot engage the community for the purpose of registering a relation type
* Using an internal or experimental relation type (similar to the original purpose of the X- HTTP headers)
* Defining a short-lived relation type (e.g. something for an event) 
* Do not want to involve IANA / IETF in the process or politics of your standard
* You like URIs better

-- Use a "trademark-quality" registered short relation type for (i.e. a relation type that is unique, not a trivial word, and unlikely to mean something else):

* A narrowly defined relation type
* Protocol specific
* Restricted in the media type of the linked resource
* Restricted in link cardinality in the same place or multiple places (HTTP Header, HTML element, etc.)
* Use for other purposes will break something

-- Use a generic term registered short relation type:

* Generally applicable across context, protocols
* Meaning is aligned with common expectations of technical people
* Can have specialized processing rules of meaning in some cases without breaking something

Are these examples right? I don't think we need to have them in the spec, but it would be great if we can offer the DE's something to work with (as well as the wider community to better understand how they should use this process).

EHL

> Sent: Tuesday, December 29, 2009 3:26 PM
> To: Eran Hammer-Lahav
> Cc: Julian Reschke; Apps Discuss
> > Maybe some recommendation in the spec about naming conventions?
> Something along the lines of non-novel names should not be used for very
> narrow cases.
> 
> 
> They SHOULD be appropriate to the specificity of the relation; i.e., if the
> semantics are highly specific to a particular application, the name should
> reflect that, so that more general names are available for less specific use.
> 
> 
> --