Subject: Re: Last Call: draft-nottingham-http-link-header (Web Linking) to Proposed Standard

From: Julian Reschke <[email-masked]>
Date: Thu, 16 Jul 2009 22:58:20 +0200

Nicolás Alvarez wrote:
> ...
> In the ABNF in section 5, enc2231-string refers to extended-value in section 7 
> of RFC2231. However, "extended-value" isn't explicitly defined anywhere in 
> RFC. The strange thing is that it's *used* in other ABNF constructions of 
> RFC2231, like extended-parameter; but I don't see it in the left hand side of 
> any ":="
> ...

Indeed, that needs to say "extended-initial-value". Note the related RFC 
2231 erratum: <http://www.rfc-editor.org/errata_search.php?eid=477>.

BR, Julian

---

From: Nicolás Alvarez <[email-masked]>
Date: Thu, 16 Jul 2009 19:46:12 +0000

I'm reading draft-nottingham-http-link-header-06 and I have a few comments, or 
at least things I am confused about.

Section 4 says: "As such, relation types are not format-specific, and MUST NOT 
specify a particular format or media type that they are to be used with."

Does this refer to the format or media type of the context or the target?
I think there are reasonable use cases for a relation type to specify what the 
target format is supposed to be. For example, an application-specific 
extension relation type to link http://example.com to an API endpoint 
(whatever that means) could say the target must be (or should be) 
application/x-example-format+xml. Or a relation type could say the target 
must be a subtype of the image/ mime type.

Below the ABNF in section 5, it says:
"If the URI-Reference is relative, it MUST be resolved as per [RFC3986], 
Section 5."

Does this mean that if a client parsing a Link header finds a relative URI 
reference, it MUST resolve it to an absolute URI; or does it mean a server 
MUST resolve relative URIs to absolute URIs before sending the Link header to 
a client?

I think it should be clarified what side (client or server) that MUST applies 
to.

Same for "If the anchor parameter's value is a relative URI[...]" in the 
paragraph that follows.

Editorial issue: the last line of page 5 (second paragraph after ABNF in 
section 5) should be moved to the beginning of page 6 for better readability. 
(this is known as an "orphan line")

Apologies in advance if any of these issues were raised already (I'm not on 
the mailing list myself), or if I'm posting to the wrong list for this topic.

Since I'm not subscribed to the list (and I'm having technical problems to 
access gmane.org), I'd appreciate if you Cc: me in any replies.

-- 
Nicolas

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 17 Jul 2009 10:15:29 +1000

Hi Nicolás,

Thanks for reviewing; responses inline.

> must be a subtype of the image/ mime type.

That's an interesting question; although that requirement has been  
discussed extensively, this aspect has not yet come up.

The intent was that it apply to the target, the reason being that the  
relation type and media type are orthoganal (if the type of the  
relation needs to be contrained for a particular application, it can  
be done by that application, not in the definition of the relation  
type itself).

I think it's equally applicable to the context (and this is already  
alluded to in separate text about not specifying the context in the  
relation type, although it doesn't mention the context's type  
specifically).

All of that said, it's pretty clear that despite good practice and  
separation of concerns, people are going to want to do this whether we  
like it or not. Therefore, I'm inclined to loosen this requirement to  
SHOULD NOT (or even degrade it to a non-normative recommendation  
against) making extension (NOT registered) relation types format- 
specific.

The benefit here is that doing this encourages application-specific  
relation types to be defined as extensions, which is their nominated  
purpose.

> RFC2231, like extended-parameter; but I don't see it in the left  

Ack.

> Same for "If the anchor parameter's value is a relative URI[...]" in  

They're both parsing requirements; the syntax is unambiguous about  
what's allowed when produced. However, I'll try to tweak the text to  
make this more obvious.

> (this is known as an "orphan line")

Ack.

> access gmane.org), I'd appreciate if you Cc: me in any replies.

Thank very much for the feedback!

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

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 23 Jul 2009 14:32:18 +1000

FYI:

I'm tracking proposed changes to -06 as a result of Last Call at:
   http://www.mnot.net/drafts/draft-nottingham-http-link-header-07.txt

with a diff at:
   http://www.mnot.net/drafts/draft-nottingham-http-link-header-07-from-6.diff.html

Cheers,

---

From: Noah Slater <[email-masked]>
Date: Thu, 23 Jul 2009 22:08:07 +0100

Hey Mark,

>   http://www.mnot.net/drafts/draft-nottingham-http-link-header-07.txt

I'm not sure how this process works, so please just say so if I'm getting the
wrong end of the stick. I've sent a number of emails to the list about adding
two language related link parameters.

My original email was:

  http://lists.w3.org/Archives/Public/ietf-http-wg/2009AprJun/0196.html

My next email was:

  http://lists.w3.org/Archives/Public/ietf-http-wg/2009JulSep/0100.html

And I added some clarification here:

  http://lists.w3.org/Archives/Public/ietf-http-wg/2009JulSep/0112.html

I'm worried that your most recent email means that my suggestions wont make it
into the specification. If that's the case, I was hoping for some comentary so
that I understand why that isn't going to be possible.

Thanks,

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

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 24 Jul 2009 11:02:36 +1000

Hi Noah,

Sorry, that slipped through the cracks.

lang doesn't make any sense in this context; in HTML it applies to the  
link text, but there is none here.

Regarding hreflang - looking through the history, it's been discussed  
in a fairly positive light a few times, but never made it in. I think  
it does make some sense, since it's both in Atom and HTML. I'm a bit  
concerned about what the appropriate reference is for the value space;  
ATM I'm thinking BCP47 directly, rather than to a specific RFC, to  
allow it to evolve*.

Anyone see an issue with adding hreflang with a value space of BCP47?

Cheers,

* Often, a reference to an RFC is preferable, so that software can be  
reliably written to a specific set of identifiers. My initial feeling  
is that here that's not appropriate to do that, because language tags  
are labels, not something that you're going to hardcode into  
infrastructure software. Feedback appreciated, especially from the  
i18n community.

---

From: Noah Slater <[email-masked]>
Date: Fri, 24 Jul 2009 02:11:42 +0100

> Sorry, that slipped through the cracks.

No problem!

I didn't want to be a pain, bringing it up so often.

>From the exmaple I gave in one of my previous emails:

  Link: <essay.en>; rel="alternate"; hreflang="en"; lang="en"; title="Essay"
  Link: <essay.fr>; rel="alternate"; hreflang="fr"; lang="fr"; title="Essais"
  Link: <essay.de>; rel="alternate"; hreflang="de"; lang="de"; title="Aufsatz"

The lang parameter pertains to the content of the link title parameter:

  Essay, Essais, or Aufsatz

Which is directly analogous to the HTML version:

  <link rel="alternate" href="essay.en" hreflang="en" lang="en" title="Essay">
  <link rel="alternate" href="essay.fr" hreflang="fr" lang="fr" title="Essais">
  <link rel="alternate" href="essay.de" hreflang="de" lang="de" title="Aufsatz">

A friend of mine points out that it should be Essai, but oh well.

Thank you for considering my feedback!

Best,

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 24 Jul 2009 11:19:08 +1000

The *title parameter already allows for a language to be associated  
with the title. See RFC2231 and the examples in the link draft.

Cheers,

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 24 Jul 2009 11:19:53 +1000

Oops, title*...

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 24 Jul 2009 12:40:37 +1000

Strike that; looking more closely, RFC4646 makes sense ATM (although  
LTRU will change that).

On 24/07/2009, at 11:02 AM, Mark Nottingham wrote:

> lang doesn't make any sense in this context; in HTML it applies to  
> the link text, but there is none here.
>
> Regarding hreflang - looking through the history, it's been  
> discussed in a fairly positive light a few times, but never made it  
> in. I think it does make some sense, since it's both in Atom and  
> HTML. I'm a bit concerned about what the appropriate reference is  
> for the value space; ATM I'm thinking BCP47 directly, rather than to  
> a specific RFC, to allow it to evolve*.
>
> * Often, a reference to an RFC is preferable, so that software can  
> be reliably written to a specific set of identifiers. My initial  
> feeling is that here that's not appropriate to do that, because  
> language tags are labels, not something that you're going to  
> hardcode into infrastructure software. Feedback appreciated,  
> especially from the i18n community.
>
>
>
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: Noah Slater <[email-masked]>
Date: Fri, 24 Jul 2009 03:47:11 +0100

On Fri, Jul 24, 2009 at 11:19:08AM +1000, Mark Nottingham wrote:
> The *title parameter already allows for a language to be associated with
> the title. See RFC2231 and the examples in the link draft.

Of course, I should have spotted this.

I have two questions:

  * Would it be harmful to mirror HTML and specify a redundant lang parameter
    anyway, even though this can also be functionally acheived using RFC 2231
    syntax. It may be easier for some people to understand this.

  * Is there a default encoding for parameter values, or in fact any other part
    of this header. I could not find anything in the draft which would indicate
    there is a default. Could this cause problems?

Thanks,

---

From: Noah Slater <[email-masked]>
Date: Fri, 24 Jul 2009 04:28:42 +0100

On Fri, Jul 24, 2009 at 12:55:03PM +1000, Mark Nottingham wrote:
> My understanding of HTML4 is that @lang identifies the language of the
> link text itself, not the title (although that may be a side effect),
> since it already has @hreflang. Do I have that wrong?

  This attribute specifies the base language of an element's attribute
  values and text content. The default value of this attribute is unknown.

                        - http://www.w3.org/TR/html401/struct/dirlang.html#h-8.1

> If they're a token (i.e., unquoted), they're restricted to ASCII in the
> BNF ( token = *CHAR = octets 0-127).

Ah, I had overlooked this.

Thanks,

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 24 Jul 2009 12:55:03 +1000

On 24/07/2009, at 12:47 PM, Noah Slater wrote:

>> with

>    there is a default. Could this cause problems?

If they're a token (i.e., unquoted), they're restricted to ASCII in  
the BNF ( token = *CHAR = octets 0-127).

If it's a quoted-string, it's restricted to ISO-8859-1 unless encoded  
as per 2047 (like title*) (see RFC2616 section 2.2). However, HTTPbis  
looks like it will be further restricting this to ASCII (with defined  
encodings into ASCII as needed).

Cheers,

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 24 Jul 2009 16:12:22 +1000

>                        - http://www.w3.org/TR/html401/struct/dirlang.html#h-8.1

OK.

I'm wary of duplicating this in the header, because it would then  
create two ways to do the same thing in the same header, and  
inevitably people would be forced to do both to communicate properly...

Cheers,

---

From: Julian Reschke <[email-masked]>
Date: Fri, 24 Jul 2009 07:49:00 +0200

>     there is a default. Could this cause problems?

The encoding is restricted by HTTP, thus, depending how you read 
RFC2616, to ASCII or ISO-88591-1 at best.

That's why an extension mechanism is needed anyway; the draft uses 
RFC2231-based encoding.

BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 24 Jul 2009 07:33:53 +0200

Mark Nottingham wrote:
> If it's a quoted-string, it's restricted to ISO-8859-1 unless encoded as 
> per 2047 (like title*) (see RFC2616 section 2.2). However, HTTPbis looks 
 > ...

Almost. RFC 2047 does not work in parameter values, thus RFC 2231 
encoding is needed...

BR, Julian