Subject: Fwd: New Version Notification - draft-nottingham-http-link-header-07.txt

From: Mark Nottingham <[email-masked]>
Date: Tue, 19 Jan 2010 16:31:22 +1100

Begin forwarded message:

> From: [email-masked]
> Date: 19 January 2010 4:30:02 PM AEDT
> To: [email-masked], [email-masked],[email-masked]
> Subject: New Version Notification - draft-nottingham-http-link-header-07.txt 
> 
> New version (-07) has been submitted for draft-nottingham-http-link-header-07.txt.
> http://www.ietf.org/internet-drafts/draft-nottingham-http-link-header-07.txt
> Sub state has been changed to AD Follow up from New Id Needed
> 
> Diff from previous version:
> http://tools.ietf.org/rfcdiff?url2=draft-nottingham-http-link-header-07
> 
> IETF Secretariat.

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

---

From: Mike Burrows <[email-masked]>
Date: Tue, 19 Jan 2010 22:06:04 +0100

Thanks, and nice timing - I've just ported my link header rubygem to Python
- see http://pypi.python.org/pypi/LinkHeader/0.1 or
http://bitbucket.org/asplake/link_header/.

The Python version is rather smarter about when to quote attribute values (I
should port this back to Ruby), but they are otherwise similar in
functionality - parsing, formatting and conversion to/from json-friendly
structures.

Caveat: I've made no serious attempt (in either language) to parse title*
attributes ("title*" "=" enc2231-string) but if anyone has need of them (or
has any other feedback for that matter) please get in touch privately and I
will see what I can do.

Regards,
Mike
[email-masked]
http://positiveincline.com
http://twitter.com/asplake

2010/1/19 Mark Nottingham <[email-masked]>

> > New version (-07) has been submitted for
> draft-nottingham-http-link-header-07.txt.
> >

---

From: Julian Reschke <[email-masked]>
Date: Wed, 20 Jan 2010 12:01:17 +0100

Thanks, Mark.

I'd like to make sure that everybody is aware that these are past-LC 
changes, and they *are* significant; see 
<http://tools.ietf.org/html/draft-nottingham-http-link-header-07#appendix-E>:

    o  Allowed multiple spaces between relation types.
    o  Relaxed requirements for registered relations.
    o  Removed Defining New Link Serialisations appendix.
    o  Added Field registry.
    o  Added registry XML format.
    o  Changed registration procedure to use mailing list(s), giving the
       Designated Experts more responsibility for the smooth running of
       the registry.
    o  Loosened prohibition against media-specific relation types to
       SHOULD NOT.
    o  Disallowed registration of media-specific relation types (can
       still be used as extension types).
    o  Clarified that parsers are responsible for resolving relative
       URIs.
    o  Fixed ABNF for extended-initial-value.
    o  Fixed title* parameter quoting in example.
    o  Added notes for registered relations that lack a reference.
    o  Added hreflang parameter.
    o  Clarified status of 'rev'.
    o  Removed advice to use @profile in HTML4.
    o  Clarified what multiple *title and hreflang attributes mean.
    o  Disallowed multiple type, rel and title attributes.
    o  Removed text about absolute URI form of registered relations.
    o  Required registered relations to conform to sgml-name (now just
       rel-relation-type).
    o  Required registered relations to be lowercase.
    o  Made comparison of extension relations case insensitive.
    o  Clarified requirements on registered relation types regarding
       media types, etc.
    o  Allowed applications to ignore links with anchor parameters if
       they're concerned.
    o  Made 'rev' text a bit less confusing.
    o  Extension relation URIs SHOULD be all-lowercase.
    o  Added media parameter.
    o  Required applications to specifically call out use of anchor
       parameter.

Thus everybody who's interested in this specification should review 
these changes as soon as possible.

Best regards, Julian

Mark Nottingham wrote:
> _______________________________________________
> Apps-Discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: Subbu Allamaraju <[email-masked]>
Date: Wed, 20 Jan 2010 13:38:47 -0800

The usage of fields is not clear. Sec. 6.3 says that "entries in the Link Relation Type Registry can be extended with application-specific data". But the BNF in Sec. 5 does not specify fields. Could you clarify the intent of fields?

Subbu

---

From: Jan Algermissen <[email-masked]>
Date: Thu, 21 Jan 2010 08:37:30 +0100

On Jan 20, 2010, at 10:38 PM, Subbu Allamaraju wrote:

> The usage of fields is not clear. Sec. 6.3 says that "entries in the  
> Link Relation Type Registry can be extended with application- 
> specific data". But the BNF in Sec. 5 does not specify fields. Could  
> you clarify the intent of fields?

I understand fields to be meant as link relation specific parameters.

Jan

>>> To: [email-masked], draft-nottingham-http-link- 
>>> [email-masked],[email-masked]

-----------------------------------
  Jan Algermissen, Consultant

  Mail: [email-masked]
  Blog: http://www.nordsc.com/blog/
  Work: http://www.nordsc.com/
-----------------------------------

---

From: Julian Reschke <[email-masked]>
Date: Thu, 21 Jan 2010 13:53:26 +0100

Hi,

this is the first of several LC comments on 
draft-nottingham-http-link-header-07. Except for the purely editorial 
ones I'll be sending them in separate emails so that it's easier to 
track them.

This is about the anchor parameter.

The changes 
(<http://tools.ietf.org/html/draft-nottingham-http-link-header-07#appendix-E>) 
say:

The actual text changed from 
(<http://tools.ietf.org/html/draft-nottingham-http-link-header-06#section-5>)

    By default, the context of a link conveyed in the Link header field
    is the IRI of the requested resource.  When present, the anchor
    parameter overrides this with another URI, such as a fragment of this
    resource, or a third resource (i.e., when the anchor value is an
    absolute URI).  If the anchor parameter's value is a relative URI, it
    MUST be resolved as per [RFC3986], Section 5.  Note that any base URI
    from the body's content is not applied.

to 
(<http://tools.ietf.org/html/draft-nottingham-http-link-header-07#section-5.2>)

    When present and explicitly specified by use by an application, the
    anchor parameter overrides this with another URI, such as a fragment
    of this resource, or a third resource (i.e., when the anchor value is
    an absolute URI).  If the anchor parameter's value is a relative URI,
    parsers MUST resolve it as per [RFC3986], Section 5.  Note that any
    base URI from the body's content is not applied.

So it appears that this change does not "allow applications to ignore", 
but "requires applications to specify how to process", so it's an "opt 
in", not an "opt out".

That being said: what is an "application" in this context? What needs to 
be done to specify this? An example would be useful; for instance, it 
would be interesting what 
<http://tools.ietf.org/html/draft-brown-versioning-link-relations-06#appendix-A.1> 
would need to say to specify the required processing of anchor.

In general I think that making this somehow optional will be an interop 
disaster. Link header processing should be uniform and not depend on 
some out-of-band information.

If the reason this was changed was because of missing support in those 
UAs that currently handle the "Link" header: let's file bugs.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 21 Jan 2010 14:31:55 +0100

Hi,

<http://tools.ietf.org/html/draft-nottingham-http-link-header-07#appendix-E> 
says:

and also

I think it's still confusing...

So the grammar in 
<http://tools.ietf.org/html/draft-nottingham-http-link-header-07#section-5> 
lists it as regular link parameter:

    link-param        = ( ( "rel" "=" relation-types )
                      | ( "anchor" "=" <"> URI-Reference <"> )
                      | ( "rev" "=" relation-types )
                      | ( "hreflang" "=" Language-Tag )
                      | ( "media" "=" ( MediaDesc | <"> MediaDesc <"> ) )
                      | ( "title" "=" quoted-string )
                      | ( "title*" "=" enc2231-string )
                      | ( "type" "=" type-name "/" subtype-name )
                      | ( link-extension ) )

On the other hand, 
<http://tools.ietf.org/html/draft-nottingham-http-link-header-07#section-5.3> 
states:

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

So the ABNF defines it as parameter, but the prose claims it's not 
specified, and could be specified later on as extension. Speaking of 
which, how do I define an extension? Standards Track RFC updating this 
one, as there is no registry?

Later on, in the section about HTML4 we find 
(<http://tools.ietf.org/html/draft-nottingham-http-link-header-07#appendix-B>):

    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 (briefly, some hold that rev reverses
    the direction of the link, while others that it reverses the
    semantics of the relation itself).

I have to admit that I'm still not sure what *in practice* the 
difference between reversing the link direction and reversing the link 
semantics actually is. (Example?)

RFC 2068 delegates the definition to RFC 1866 (HTML 2) which says 
(<http://tools.ietf.org/html/rfc1866#section-5.7.3>):

     REV
             same as the REL attribute, but the semantics of the
             relationship are in the reverse direction. A link from A
             to B with REL="X" expresses the same relationship as a
             link from B to A with REV="X". An anchor may have both
             REL and REV attributes.

This does not seem to contradict the latest HTML spec, which has in 
<http://www.w3.org/TR/html4/struct/links.html#rev-link>:

    The rel and rev attributes play complementary roles -- the rel
    attribute specifies a forward link and the rev attribute specifies a
    reverse link.

    Consider two documents A and B.

    Document A:       <LINK href="docB" rel="foo">

    Has exactly the same meaning as:

    Document B:       <LINK href="docA" rev="foo">

    Both attributes may be specified simultaneously.

So my preference would be to actually define the rev parameter 
consistently with this, and then to discourage it's use due to the other 
good reasons we heard about that (such as HTML authors typing "rev" 
instead of "rel").

Related to that: if processing the anchor attribute was mandatory then 
any use of "rev" (under the definition above) could be rewritten with 
rel and anchor. Given a context IRI of A:

   Link: <B>; rev=foo

should be equivalent to

   Link: <A>; rel=foo; anchor=<B>

right?

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 21 Jan 2010 14:47:50 +0100

Hi,

a few comments regarding quoting of link parameters:

<http://tools.ietf.org/html/draft-nottingham-http-link-header-07#section-5> 
defines the new parameters:

"hreflang" and "media", so quoting is allowed for media, but it's not 
for hreflang. I think it's correct that valid language tags never 
require quoting, but I'm not sure that disallowing quoting is the right 
thing to do here.

Which made have a closer look at existing parameters (sorry for not 
bringing this up earlier):

I believe this *definitively* needs quoting, as "/" is a separator 
character in HTTP and thus can not appear in a token.

Also, as this spec uses the RFC 2616 ABNF, we probably need to duplicate 
the statement from 
<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.3.7>:

"...Linear white space (LWS) MUST NOT be used between the type and 
subtype, ..."

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 21 Jan 2010 15:04:47 +0100

Hi,

below are some comments of editorial nature:

Section 1., paragraph 3:
OLD:

    Furthermore, an HTTP header-field for conveying typed links was
    defined in [RFC2068], but removed from [RFC2616], due to a lack of
    implementation experience.  Since then, it has been implemented in
    some User-Agents (e.g., for stylesheets), and several additional use
    cases have surfaced.

NEW:

    Furthermore, an HTTP header-field for conveying typed links was
    defined in Section 19.6.2.4 of [RFC2068], but removed from [RFC2616],
    due to a lack of implementation experience.  Since then, it has been
    implemented in some User-Agents (e.g., for stylesheets), and several
    additional use cases have surfaced.

(be nice to the reader and a bit more specific in the RFC 2068 reference)

Section 2., paragraph 0:
OLD:

    [[ Feedback is welcome on the [email-masked] mailing list,
    although this is NOT a work item of the HTTPBIS WG. ]]

Please either move into a front page note, or clearly mark this as
something to be removed before publication.

Section 2., paragraph 3:
OLD:

    Additionally, the following rules are included from [RFC3986]: URI
    and URI-Reference; from [RFC4288]: type-name and subtype-name; from
    [W3C.REC-html401-19991224]: MediaDesc, and from [RFC4646]: Language-
    Tag.

NEW:

    Additionally, the following rules are included from [RFC3986]: URI
    and URI-Reference; from [RFC4288]: type-name and subtype-name; from
    [W3C.REC-html401-19991224]: MediaDesc, and from [RFC5646]: Language-
    Tag.

RFC 4646 was updated by RFC 5646.

Section 4.1., paragraph 3:
OLD:

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

Does "methods" refer to HTTP here? maybe clarify this.

Section 4.1., paragraph 4:
OLD:

    Additionally, specific applications of linking may have additional
    per-relation type attributes which are advantageous to register.  For
    example, some link relations might not be appropriate to use in
    particular contexts, or might have common behaviour such as whether
    their content should be archived with the page.  To accommodate this,
    new per-entry fields MAY be added to the registry, by registering
    them in the Link Relation Field Registry Section 6.3.

NEW:

    Additionally, specific applications of linking may have additional
    per-relation type attributes which are advantageous to register.  For
    example, some link relations might not be appropriate to use in
    particular contexts, or might have common behaviour such as whether
    their content should be archived with the page.  To accommodate this,
    new per-entry fields MAY be added to the registry, by registering
    them in the Link Relation Field Registry (Section 6.3).

(Missing brackets at the paragraph end)

Section 5.4., paragraph 3:
OLD:

    The "media" parameter, when present, is used to indicate intended
    destination medium or media for style information (see
    [W3C.REC-html401-19991224], Section 6.13.  Note that this may be
    updated by [W3C.CR-css3-mediaqueries-20090915]).  Its value MUST be
    quoted if it contains a semicolon (";") or comma (","), and there
    MUST NOT be more than one media parameter in a link-value.

NEW:

    The "media" parameter, when present, is used to indicate intended
    destination medium or media for style information (see
    [W3C.REC-html401-19991224], Section 6.13).  Note that this may be
    updated by [W3C.CR-css3-mediaqueries-20090915]).  Its value MUST be
    quoted if it contains a semicolon (";") or comma (","), and there
    MUST NOT be more than one media parameter in a link-value.

Missing closing bracket in HTML4 reference.

Section 5.4., paragraph 5:
OLD:

    The "title*" parameter MAY be used encode this label in a different
    character set, and/or contain language information as per [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.

NEW:

    The "title*" parameter MAY be used to encode this label in a
    different character set, and/or contain language information as per
    [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.

...may be used *to* encode...

Section 9.1., paragraph 9:
OLD:

    [RFC4646]  Phillips, A. and M. Davis, "Tags for Identifying
               Languages", RFC 4646, September 2006.

NEW:

    [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
               IANA Considerations Section in RFCs", BCP 26, RFC 5226,
               May 2008.

Section 9.2., paragraph 7:
OLD:

    [W3C.CR-css3-mediaqueries-20090915]
               Glazman, D., Celik, T., Lie, H., and A. Kesteren, "Media
               Queries", World Wide Web Consortium CR CR-css3-
               mediaqueries-20090915, September 2009,
               <http://www.w3.org/TR/2009/CR-css3-mediaqueries-20090915>.

    [W3C.REC-html401-19991224]
               Jacobs, I., Raggett, D., and A. Hors, "HTML 4.01
               Specification", World Wide Web Consortium
               Recommendation REC-html401-19991224, December 1999,
               <http://www.w3.org/TR/1999/REC-html401-19991224>.

    [W3C.REC-rdfa-syntax-20081014]
               Adida, B., Pemberton, S., McCarron, S., and M. Birbeck,
               "RDFa in XHTML: Syntax and Processing", World Wide Web
               Consortium Recommendation REC-rdfa-syntax-20081014,
               October 2008,
               <http://www.w3.org/TR/2008/REC-rdfa-syntax-20081014>.

    [W3C.REC-xhtml-basic-20080729]
               Wugofski, T., Matsui, S., Baker, M., Yamakami, T.,
               Ishikawa, M., and P. Stark, "XHTML[TM] Basic 1.1", World
               Wide Web Consortium Recommendation REC-xhtml-basic-
               20080729, July 2008,
               <http://www.w3.org/TR/2008/REC-xhtml-basic-20080729>.

NEW:

    [W3C.CR-css3-mediaqueries-20090915]
               Glazman, D., Celik, T., Lie, H., and A. Kesteren, "Media
               Queries", W3C Candidate Recommendation CR-css3-
               mediaqueries-20090915, September 2009,
               <http://www.w3.org/TR/2009/
               CR-css3-mediaqueries-20090915/>.

    [W3C.REC-html401-19991224]
               Jacobs, I., Raggett, D., and A. Hors, "HTML 4.01
               Specification", W3C Recommendation REC-html401-19991224,
               December 1999,
               <http://www.w3.org/TR/1999/REC-html401-19991224/>.

    [W3C.REC-rdfa-syntax-20081014]
               Adida, B., Pemberton, S., McCarron, S., and M. Birbeck,
               "RDFa in XHTML: Syntax and Processing", W3C
               Recommendation REC-rdfa-syntax-20081014, October 2008,
               <http://www.w3.org/TR/2008/REC-rdfa-syntax-20081014/>.

    [W3C.REC-xhtml-basic-20080729]
               Wugofski, T., Matsui, S., Baker, M., Yamakami, T.,
               Ishikawa, M., and P. Stark, "XHTML Basic 1.1", W3C
               Recommendation REC-xhtml-basic-20080729, July 2008,
               <http://www.w3.org/TR/2008/REC-xhtml-basic-20080729/>.

Please make the W3C references consistent: W3C instead of "Word Wide Web
Consortium", and make sure the URIs use the current format (trailing slash).

Optimally, also reduce the length of the anchor names (I'll be happy to
supply diffs).

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 21 Jan 2010 15:23:05 +0100

Hi,

finally a security related comment.

During IETF LC for draft-brown-versioning-link-relations we got a 
comment from Eric Rescorla:

"In general this mechanism seems sound but I'm not sure that the 
security considerations are entirely adequate. This mechanism lets you 
learn information about other versions of a resource even if you 
potentially don't have permission to view them directly. Consider a 
limiting case where each version of the resource had a name that 
contained the change set for that resource. E.g.,

http://example.com/versions/filename/_@line_50_+_FOO;@line_60_+_BAR/;

In this case, seeing other parts of the version tree leaks information 
about those versions. I don't think that this is a problem for the 
draft, but it might be useful to mention that this feature has 
implications for name construction."

I assume this is a concern that applies to the Link header in general.

Best regards, Julian

---

From: Mike Burrows <[email-masked]>
Date: Thu, 21 Jan 2010 16:01:25 +0100

Hi Julian (and all),

Which made have a closer look at existing parameters (sorry for not bringing
> this up earlier):

But is 'type-name "/" subtype-name' a token?  I didn't interpret as such -
in fact I assumed (perhaps erroneously) that it was in fact two tokens
separated by "/".

Regards,
Mike

2010/1/21 Julian Reschke <[email-masked]>

> "hreflang" and "media", so quoting is allowed for media, but it's not for
> hreflang. I think it's correct that valid language tags never require
> quoting, but I'm not sure that disallowing quoting is the right thing to do
> here.
>
> the statement from <
> http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.3.7>:
>
> "...Linear white space (LWS) MUST NOT be used between the type and subtype,
> ..."
>
> Best regards, Julian
>
>
>
>
>
>
>
>

---

From: Julian Reschke <[email-masked]>
Date: Thu, 21 Jan 2010 16:08:32 +0100

Mike Burrows wrote:
> But is 'type-name "/" subtype-name' a token?  I didn't interpret as such 
> - in fact I assumed (perhaps erroneously) that it was in fact two tokens 
> separated by "/".
> 
> Regards,
> Mike
> ...

You are right, it's not. But, in general, parameter values either take 
tokens or quoted-strings, so a generic parser of HTTP parameters would 
fail to parse this correctly.

Maybe that's not a big issue in practice, because people use custom 
parser per header field, but it would be good if we could avoid that.

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 22 Jan 2010 11:43:18 +1100

On 21/01/2010, at 11:53 PM, Julian Reschke wrote:

> So it appears that this change does not "allow applications to ignore", but "requires applications to specify how to process", so it's an "opt in", not an "opt out".

Yes, sorry; forgot to (re-)update the changelog on that one.

> That being said: what is an "application" in this context? What needs to be done to specify this? An example would be useful; for instance, it would be interesting what <http://tools.ietf.org/html/draft-brown-versioning-link-relations-06#appendix-A.1> would need to say to specify the required processing of anchor.

Yes, it would. "Application" is intentionally a bit fuzzy, because while some link relations are defined by their application, others have been purposefully separated; e.g., "alternate" is used for a variety of purposes.

> In general I think that making this somehow optional will be an interop disaster. Link header processing should be uniform and not depend on some out-of-band information.
> 
> If the reason this was changed was because of missing support in those UAs that currently handle the "Link" header: let's file bugs.

It wasn't, and the link header parsing is the same; it's just the interpretation that changes, depending on whether the application expects the anchor parameter to be used. This was done because in many (or even most) instances, it's very surprising to have a link from A to B to be able to assert things about C, and have their semantics automatically applied. 

Cheers,

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 22 Jan 2010 11:53:37 +1100

I agree in principle, but practically, it's almost a foregone conclusion that people will produce these unquoted, and implementations will consume them happily. I'd rather align with what is done in practice, even if it does preclude using a generic parser...

On 22/01/2010, at 2:08 AM, Julian Reschke wrote:

>> But is 'type-name "/" subtype-name' a token?  I didn't interpret as such - in fact I assumed (perhaps erroneously) that it was in fact two tokens separated by "/".
>> Regards,
>> Mike
>> ...
> 
> You are right, it's not. But, in general, parameter values either take tokens or quoted-strings, so a generic parser of HTTP parameters would fail to parse this correctly.
> 
> Maybe that's not a big issue in practice, because people use custom parser per header field, but it would be good if we could avoid that.
> 
> Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 22 Jan 2010 12:02:42 +1100

On 22/01/2010, at 12:31 AM, Julian Reschke wrote:
> 
> So the grammar in <http://tools.ietf.org/html/draft-nottingham-http-link-header-07#section-5> lists it as regular link parameter:
> 
> On the other hand, <http://tools.ietf.org/html/draft-nottingham-http-link-header-07#section-5.3> states:
> 
> So the ABNF defines it as parameter, but the prose claims it's not specified, and could be specified later on as extension.

I'm happy to remove it from the BNF if that doesn't disturb the very delicate consensus we have on this topic. Comments from others?

> Speaking of which, how do I define an extension? Standards Track RFC updating this one, as there is no registry?

If you like. Practically speaking, I think many extensions will be used without such registration, as they'll be specific to the format and/or application in use -- which I think is just fine.

> Later on, in the section about HTML4 we find (<http://tools.ietf.org/html/draft-nottingham-http-link-header-07#appendix-B>):
> 
> I have to admit that I'm still not sure what *in practice* the difference between reversing the link direction and reversing the link semantics actually is. (Example?)

I can add a brief example for the latter.

> So my preference would be to actually define the rev parameter consistently with this, and then to discourage it's use due to the other good reasons we heard about that (such as HTML authors typing "rev" instead of "rel").

As previous discussed (quite a bit), HTML2 defines REV as having reversed *semantics*, while HTML4 talks about it creating a "reverse link" -- which are very different things. This feels like a rat hole to me (thus my attempts to navigate around it).

Cheers,

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 22 Jan 2010 12:05:17 +1100

Thanks! One note - 

> Optimally, also reduce the length of the anchor names (I'll be happy to

These refs are straight from xml.resource.org; probably the most efficient way to solve this problem would be to work with them?

Cheers,

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 22 Jan 2010 14:46:23 +1100

Thanks, Mike; looks interesting. 

I have a less functional implementation at <http://gist.github.com/210535>; it would be interesting to compare notes.

Cheers,

On 20/01/2010, at 8:06 AM, Mike Burrows wrote:

> 
> Thanks, and nice timing - I've just ported my link header rubygem to Python - see http://pypi.python.org/pypi/LinkHeader/0.1 or http://bitbucket.org/asplake/link_header/.
> 
> The Python version is rather smarter about when to quote attribute values (I should port this back to Ruby), but they are otherwise similar in functionality - parsing, formatting and conversion to/from json-friendly structures.
> 
> Caveat: I've made no serious attempt (in either language) to parse title* attributes ("title*" "=" enc2231-string) but if anyone has need of them (or has any other feedback for that matter) please get in touch privately and I will see what I can do.
> 
> Regards,
> Mike
> [email-masked]

---

From: Julian Reschke <[email-masked]>
Date: Fri, 22 Jan 2010 09:39:44 +0100

> Yes, it would. "Application" is intentionally a bit fuzzy, because while some link relations are defined by their application, others have been purposefully separated; e.g., "alternate" is used for…

OK, what needs to be done to specify this?

> It wasn't, and the link header parsing is the same; it's just the interpretation that changes, depending on whether the application expects the anchor parameter to be used. This was done because in…

Both *parsing* and *processing* should be uniform.

I'm ok with allowing recipients to *reject* (*) link headers that 
include the anchor parameter. On the other hand *ignoring* it needs to 
be a bug.

Best regards, Julian

(*) treat it as invalid

---

From: Julian Reschke <[email-masked]>
Date: Fri, 22 Jan 2010 10:02:04 +0100

> I agree in principle, but practically, it's almost a foregone conclusion that people will produce these unquoted, and implementations will consume them happily. I'd rather align with what is done i…

I just did some testing with the two UAs I have that actually do 
something the the Link header; Firefox and Opera.

Both process the type parameter both quoted and unquoted. So minimally 
the ABNF should allow both.

That being said, given the little amount of deployment, I'd *much* 
prefer to make the ABNF consistent with generic parameter parsing, and 
potentially just add a statement that unquoted type parameters may occur 
in the wild (*) and may have to be accepted as well.

Best regards, Julian

(*) do they, outside of test cases?

---

From: Julian Reschke <[email-masked]>
Date: Fri, 22 Jan 2010 10:09:04 +0100

> I'm happy to remove it from the BNF if that doesn't disturb the very delicate consensus we have on this topic. Comments from others?

Optimally, it gets defined. Otherwise it should be clear through which 
path somebody else can define it.

> I can add a brief example for the latter.

Please.

> As previous discussed (quite a bit), HTML2 defines REV as having reversed *semantics*, while HTML4 talks about it creating a "reverse link" -- which are very different things. This feels like a rat…

Again, HTML 2 defines it as:

     REV

(<http://tools.ietf.org/html/rfc1866#section-5.7.3>)

That totally sounds like "reverse link" to me. So, I really really think 
there's less confusion than some people claim.

Best regards, Julian

---

From: Subbu Allamaraju <[email-masked]>
Date: Fri, 22 Jan 2010 10:19:32 -0800

You mean "link-extension" params?

Subbu

---

From: Jan Algermissen <[email-masked]>
Date: Fri, 22 Jan 2010 22:53:08 +0100

> You mean "link-extension" params?

Hmm, no I am getting confused :-)

I;d say link-extension == field.

Mark?

Jan

>>> The usage of fields is not clear. Sec. 6.3 says that "entries in  
>>> the Link Relation Type Registry can be extended with application- 
>>> specific data". But the BNF in Sec. 5 does not specify fields.  
>>> Could you clarify the intent of fields?
>>

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 29 Jan 2010 15:23:37 +1100

> OK, what needs to be done to specify this?

Probably just a sentence or two to tease this out at the top. I've been trying to come up with prose for this for a while, but it's difficult to do it without messing it up. Will try again.

> I'm ok with allowing recipients to *reject* (*) link headers that include the anchor parameter. On the other hand *ignoring* it needs to be a bug.
> 
> Best regards, Julian
> 
> (*) treat it as invalid

If that's the case, you're saying that whether the anchor is allowed is really a property of the relation type, not the application, aren't you?

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 29 Jan 2010 15:25:34 +1100

No, the extension fields are in the registry itself; e.g., by adding a "foo" field to it, you add a "foo" field to every registered link relation type, in the registry (NOT on the wire).

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 29 Jan 2010 15:30:51 +1100

I sincerely don't believe that adding any such text to the Link draft (or the URI specification, which is where this really belongs) will make the world any more secure of a place. 

However, I'll be happy to have that discussion with Eric *if* he brings it up.

Cheers,

On 22/01/2010, at 1:23 AM, Julian Reschke wrote:

> During IETF LC for draft-brown-versioning-link-relations we got a comment from Eric Rescorla:
> 
> "In general this mechanism seems sound but I'm not sure that the security considerations are entirely adequate. This mechanism lets you learn information about other versions of a resource even if you potentially don't have permission to view them directly. Consider a limiting case where each version of the resource had a name that contained the change set for that resource. E.g.,
> 
> In this case, seeing other parts of the version tree leaks information about those versions. I don't think that this is a problem for the draft, but it might be useful to mention that this feature has implications for name construction."
>

---

From: Subbu Allamaraju <[email-masked]>
Date: Thu, 28 Jan 2010 22:23:07 -0800

Could you elaborate on the purpose of such fields when they have no bearing on rels on the wire? The last para of 4.1 does include an example, but it seems vague. It also seems that any information that can be expressed via fields can equally be described in prose as part of the description.

Subbu

---

From: Julian Reschke <[email-masked]>
Date: Fri, 29 Jan 2010 13:45:41 +0100

> If that's the case, you're saying that whether the anchor is allowed is really a property of the relation type, not the application, aren't you? 

First of all, I'd prefer to distinguish between (A) "must be processed" 
and (B) "may be processed, otherwise link must be rejected altogether".

I see two purposes for the anchor parameter:

1) Making a statement about a subset of the context resource, by 
specifying a fragment identifier

2) Making a statement about a different resource than the context 
resource, such as

2a) because the context is anonymous (such as the response body for a 
204, see 
<http://greenbytes.de/tech/webdav/draft-brown-versioning-link-relations-07.html#rfc.section.A.1>), 
or

2b) because a reverse link is exposed (anchor as workaround for missing 
rev parameter)

I'm still not sure why we would ever make special cases here, except for 
the known bugs in current implementations of the Link header where 
anchor is ignored (so mainly Mozilla/Opera for stylesheet links). 
Optimally, we just work with the vendors to get the bugs fixed.

If that's not possible, allowing an opt-out per relation type might 
work, as long as behavior (B) would still be allowed. Is there any 
relation != "stylesheet" for which this would be relevant?

Best regards, Julian