W3C home > Mailing lists > Public > www-tag@w3.org > December 2008

Re: New Version Notification for draft-nottingham-http-link-header-03

From: Mark Nottingham <mnot@mnot.net>
Date: Wed, 3 Dec 2008 13:27:03 +1100
Cc: <www-tag@w3.org>, <ietf-http-wg@w3.org>
Message-Id: <A8923E98-9911-4B4F-8804-E05D105AB346@mnot.net>
To: Drummond Reed <drummond.reed@cordance.net>

Hi Drummond,

On 02/12/2008, at 6:00 PM, Drummond Reed wrote:

> Section 2: Did you use the ABNF from RFC 2616 just for compatability  
> with
> that spec? RFC 3986, from which you also cite rules, uses RFC 2234,  
> which
> has since been updated to RFC 4234.

Yes. The main reason for this is the # rule, which is 2616-specific  
(although the HTTPbis editors are working hard to factor it out, that  
isn't ready yet).

> Section 3:
> 	A link can be viewed as a statement of the form "(subject) has a
> 	(relation type) at (object)"
> It struck me that the preposition "at" can be awkward when using this
> algorithm to describe some types of relations. Examples from some of  
> the
> link relations defined in 6.2:
> 	(subject) has a related at (object)
> 	(subject) has a payment at (object)
> An alternative would be:
> 	A link can be viewed as a statement of the form "the relationship
> 	between (subject) and (object) is (relation type)"
> In the case of the two examples above, this would yield:
> 	The relationship between (subject) and (object) is related.
> 	The relationship between (subject) and (object) is payment.

That doesn't imply direction very strongly. How about

A link can be viewed as a statement of the form "(subject) has a  
(relation type) resource at (object)."

> Also, have you considered mentioning that this is essentially an RDF
> subject/predicate/object triple?

How people interpret and process links is up to them.

> Section 5:
>   Each link-value MUST have at least one "rel" or "rev" parameter  
> whose
>   value indicates the relation type.  If the "rel" parameter is used,
>   it indicates that the link's direction for that relation type is
>   outbound; if the "rev" parameter is used, the given relation type's
>   direction is inbound.
> Is there any reason this requirement isn't reflected in the ABNF  
> itself,
> i.e.:
> 	Link           = "Link" ":" #link-value
> 	link-value     = "<" URI-Reference ">" ( rel / rev )
> 				*( ";" link-param ) )
> 	rel            = "rel" "=" relation-type
> 	rev            = "rev" "=" relation-type
> 	...

More than one of each is allowed; it gets kind of tortured if you try  
to reflect all of the constraints (although if you can come up with an  
elegant way to express them, I'm more than receptive).

> Also in section 5:
>   The context of links conveyed in the Link header field is the
>   representation that the header is part of.
> If the resource for which the Link header field is being returned is
> abstract, then it has no representation (only descriptions). Thus it  
> seems
> that it would be more inclusive to say:
>   The context of links conveyed in the Link header field is the
>   resource that the header is describing.

See the response I just sent to Eran.

> At the end of section 5:
>   Here, the link "http://example.org/" has outbound links of the types
>   "http://www.iana.org/assignments/relation/index",
>   "http://www.iana.org/assignments/relation/start", and
>   "http://example.net/relation/other", as well as an inbound link of
>   type "http://www.iana.org/assignments/relation/copyright".
> It was confusing to read "the link"..."has outbound links...". Per  
> your
> earlier wording, it seems it would be more precise to say:
>   Here, the link "http://example.org/" has outbound relation types
>   "http://www.iana.org/assignments/relation/index",
>   "http://www.iana.org/assignments/relation/start", and
>   "http://example.net/relation/other", as well as an inbound relation
>   type "http://www.iana.org/assignments/relation/copyright".

Looks good, thanks!

> In section 6.2:
> 	sgml-name      = ALPHA *( ALPHA | DIGIT | "." | "-" )
> Even if the SGML folks allowed it, I've generally understood it to  
> be bad
> practice for a token name to end in a symbol character. I know it  
> means
> mucking with their rule, but you could prevent that with:
> 	sgml-name      = ALPHA *( [ "." | "-" ] ALPHA | DIGIT | )

Hmm. I lifted this text from the original Link header in 2068; it's  
largely hear to assure some amount of backwards-compatibility. The BNF  
you propose introduces other constraints besides the one you're  

> Hope this helps,

Very much so, thanks again.

Mark Nottingham     http://www.mnot.net/
Received on Wednesday, 3 December 2008 02:27:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:25 UTC