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

From: Mark Nottingham <[email-masked]>
Date: Thu, 16 Jul 2009 16:23:45 +1000

FYI

Begin forwarded message:

> From: The IESG <[email-masked]>
> Date: 15 July 2009 1:31:40 AM
> To: IETF-Announce <[email-masked]>
> Subject: Last Call: draft-nottingham-http-link-header (Web Linking)  
> to Proposed Standard
> Reply-To: [email-masked]
>
> The IESG has received a request from an individual submitter to  
> consider
> the following document:
>
> - 'Web Linking '
>   <draft-nottingham-http-link-header-06.txt> as a Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send substantive comments to  
> the
> [email-masked] mailing lists by 2009-08-11. Exceptionally,
> comments may be sent to [email-masked] instead. In either case, please
> retain the beginning of the Subject line to allow automated sorting.
>
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-nottingham-http-link-header-06.txt
>
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14833&rfc_flag=0
>
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce

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

---

From: Phil Archer <[email-masked]>
Date: Thu, 16 Jul 2009 12:33:57 +0100

Mark,

Very glad to see this advancing so far. Terrific.

This is a nit, not a substantive point, and I feel I'm very much at the 
risk of showing my poor understanding of ABNF, but it looks to me as if 
there's a small typo in one of the examples in section 5.1. You have:

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

Should there not be an opening " character at the start of 
UTF-8'de'n%c3%a4chstes%20Kapitel" ?

Cheers

Phil.

Mark Nottingham wrote:
>> Subject: Last Call: draft-nottingham-http-link-header (Web Linking) to 
>> Proposed Standard
>> Reply-To: [email-masked]
>>
>> The IESG has received a request from an individual submitter to consider
>> the following document:
>>
>> - 'Web Linking '
>> final comments on this action.  Please send substantive comments to the

-- 

Phil Archer
http://philarcher.org/

i-sieve technologies                   |      W3C Mobile Web Initiative
Sentiment Analysis Beyond Impressions  |      www.w3.org/Mobile

---

From: Julian Reschke <[email-masked]>
Date: Thu, 16 Jul 2009 14:17:31 +0200

> UTF-8'de'n%c3%a4chstes%20Kapitel" ?

Good catch. I may be responsible for that...

The "title*" parameter should not be quoted, thus the example needs to be

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

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Sun, 19 Jul 2009 14:39:35 +0200

Mark Nottingham wrote:
> ...

Draft 06 adds the "up" relation, for which apparently there is no spec, 
just a registration entry in the Atom Link Relations Registry 
(<http://www.iana.org/assignments/link-relations/link-relations.xhtml>). 
This is similar to "first", "last", and "payment", which aren't new in 
draft 06.

It might be a good idea to clarify that those four link relations are 
indeed (re-)defined by this specification, as the new registry procedure 
clearly says "specification required".

One way to achieve this would be to have a new chapter that takes over 
that role, and specified those 4 link relations which currently have no 
specification (maybe including the details that were present in the 
original link relation registry).

BR, Julian

---

From: Noah Slater <[email-masked]>
Date: Sun, 19 Jul 2009 16:35:44 +0100

On Sun, Jul 19, 2009 at 02:39:35PM +0200, Julian Reschke wrote:
> indeed (re-)defined by this specification

I see the following:

   o  Relation Name: up
   o  Description: Refers to a parent document in a hierarchy of
      documents.
   o  Reference: [this document]

               - http://www.ietf.org/id/draft-nottingham-http-link-header-06.txt

And this has been taken from:

  up

  A URI that refers to a parent document in a hierarchy of documents.

  Undefined; this relation can be used for background processing or to provide
  extended functionality without displaying its value.

  Automated agents should take care when this relation crosses administrative
  domains (e.g., the URI has a different authority than the current document).
  Such agents should also take care to detect circular references.

  [Noah_Slater]

  2009-01-28

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

Most of that is boilerplate (I know, because I copied it from some of the other
relations in the IANA registry) but if these link relations are being redefined
in this specification, why has so much been left out?

Indeed, why are these being redefined at all?

Why not point to the IANA link relations registry, and leave it at that?

I notice the following changelog entry:

   o  Removed specific location for the registry, since IANA seems to
      have its own ideas about that.

What does this mean?

The URI given in RFC4287 is:

  http://www.iana.org/assignments/relation/

This is now a 404.

We have the following page:

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

But this misses out a few link relations in the registry.

We have the following page:

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

Which 302 redirects to:

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

On 2009-02-07T04:13:01, I sent the following to [email-masked]:

  On Sat, Feb 07, 2009 at 03:35:02AM +0000, Amanda Baber via RT wrote:
  > The index at http://www.iana.org/protocols has been updated to point to that
  > page, rather than http://www.iana.org/assignments/link-relations. That version
  > should be coming down shortly.

  What about all the old links that exist to this page?

  I know that various places link to this document. Will you be putting in a HTTP
  redirect or are you doing this purposefully so that you can mark the old version
  as obsolete?

I still haven't received a reply.

> as the new registry procedure clearly says "specification required".

Which registry procedure?

> original link relation registry).

Why not defer to the IANA link relations registry?

Thanks,

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

---

From: Julian Reschke <[email-masked]>
Date: Sun, 19 Jul 2009 17:52:40 +0200

> Why not point to the IANA link relations registry, and leave it at that?

Because the registry is being replaced; and the new registry has a 
policy of "specification required" (IMHO).

> Which registry procedure?

<http://tools.ietf.org/html/draft-nottingham-http-link-header-06#section-6.2>.

> Why not defer to the IANA link relations registry?

Again, the Atom link relations registry is getting replaced by a new 
registry.

BR, Julian

---

From: Noah Slater <[email-masked]>
Date: Sun, 19 Jul 2009 17:22:29 +0100

> <http://tools.ietf.org/html/draft-nottingham-http-link-header-06#section-6.2>.

Am I correct in understanding:

  * This is the only document that talks about replacing the existing registry.

  * The existing IANA registry will be replaced in situ.

If, so then:

  * Why does the specification link to:

    This page doesn't exist.

    The changelog suggest that this should have been removed:

    Instead of removing the location, should IANA sort out the existing mess?

  * Why does the specification omit details available in the current registry.

    The up relation in the specification is currently missing:

      - Expected Display Characteristics

      - Security Considerations

      - Reference

      - Registration Date

    This effects almost every other relation in the specification.

  * Why does the specification add the specification requirement? The previous
    relations added without specification seem quite useful. Do we really want
    to prevent relations like that being added?

Thanks,

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 20 Jul 2009 14:03:07 +1000

>   Instead of removing the location, should IANA sort out the  

It's currently in process.

> * Why does the specification omit details available in the current  

Because many of the characteristics in the atom registry were found to  
be useless in practice; eg "display characteristics" was very often  
"none" and furthermore it encouraged format-specific (and often, use- 
case specific) relations to be defined. Many uses of Atom (let alone  
other formats) don't even have a display component.

Likewise, Security Considerations is specific to an application, not  
the relation between two resources.

Reference and registration date will be populated by IANA.

>   to prevent relations like that being added?

They were often just a few words sent to IANA without much  
explanation, coordination or forethought. Since the whole idea is for  
the registered relations to be ones with common semantics and shared  
uses, having an actual specification that has *some* level of  
community behind it makes sense.

This isn't preventing relations from being added, it's making sure  
they're unambiguous and well-thought-out. Besides, there are always  
extension relations, which I expect is where most of them --  
particularly those that are more application-specific -- will go.

Cheers,

---

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

Hmm. That section would merely be a verbatim repeat of the registry,  
since by definition there isn't any more information to add.

How about adding a note to each of them to indicate it's grandfathered  
in? E.g.,

   Notes: this relation pre-exists this specification, and did not  
indicate a reference.

Cheers,

On 19/07/2009, at 10:39 PM, Julian Reschke wrote:

> Mark Nottingham wrote:
>> FYI
>> ...
>
> Draft 06 adds the "up" relation, for which apparently there is no  
> spec, just a registration entry in the Atom Link Relations Registry  
> (<http://www.iana.org/assignments/link-relations/link- 
> relations.xhtml>). This is similar to "first", "last", and  
> "payment", which aren't new in draft 06.
>
> It might be a good idea to clarify that those four link relations  
> are indeed (re-)defined by this specification, as the new registry  
> procedure clearly says "specification required".
>
> One way to achieve this would be to have a new chapter that takes  
> over that role, and specified those 4 link relations which currently  
> have no specification (maybe including the details that were present  
> in the original link relation registry).
>
> BR, Julian
>

---

From: Julian Reschke <[email-masked]>
Date: Thu, 23 Jul 2009 09:30:06 +0200

> since by definition there isn't any more information to add.

That may be true for "up", but doesn't seem to be the case for 
"payment", for instance.

>   Notes: this relation pre-exists this specification, and did not 

That is a true statement, but by removing the old registry the 
information that *is* present over there will be lost -- so I think it 
should be preserved *somewhere*.

BR, Julian