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

Hi Mark,

> -----Original Message-----
> From: Mark Nottingham [mailto:mnot@mnot.net]
> Sent: Tuesday, December 02, 2008 6:27 PM
> To: Drummond Reed
> Cc: www-tag@w3.org; ietf-http-wg@w3.org
> Subject: Re: New Version Notification for draft-nottingham-http-link-
> header-03
> 
> 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).

Got it.

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

Yes, much clearer.

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

Actually, what I meant by the elipses in the ABNF above was that it
continued with the rest of your ABNF, which includes all the relation-types
(including rel and rev) so that you can have more than one. So the only
thing the above adds is the MUST for having at least one "rel" or "rev". 

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

Okay.

> > 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!

NP.

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

Sure, just wanted to mention it.

> > Hope this helps,
> 
> Very much so, thanks again.

And thanks for driving this. We really need it!

=Drummond

Received on Wednesday, 3 December 2008 06:31:50 UTC