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

Mark,

I'm not on the IETF HTTP WG list so if this bounces there, please feel free
to forward to them.

I like the focus of the new spec on link relations and their semantics, with
different "bindings" for how they are represented in specific cases.

The following is mostly editorial feedback:

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

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

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

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

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

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

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


********
Hope this helps,

=Drummond 
http://xri.net/=drummond.reed 


> -----Original Message-----
> From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] On Behalf Of
> Mark Nottingham
> Sent: Sunday, November 30, 2008 5:12 PM
> To: ietf-http-wg@w3.org Group; Atom Syntax
> Cc: www-tag@w3.org; HTML WG
> Subject: Fwd: New Version Notification for draft-nottingham-http-link-
> header-03
> 
> 
> This is a fairly substantial rewrite of the spec, based upon the
> observation that the link header really isn't the central concept
> here; it's link relations themselves.
> 
> Changelog:
> 
> o  Inverted focus from Link headers to link relations.
> o  Specified was a link relation type is.
> o  Based on discussion, re-added 'rev'.
> o  Changed IESG Approval to IETF Consensus for relation registrations
>     (i.e., require a document).
> o  Updated RFC2434 reference to RFC5226.
> o  Registered relations SHOULD conform to sgml-name.
> o  Cautioned against confusing relation types with media types.
> 
> I'm particularly interested in feedback regarding registration
> requirements, as I think that's the biggest remaining sticking point.
> Note that it was previously "IESG Approval"; I've changed it to "IETF
> Review" (nee "IETF Consensus") so that a document is required. Also, I
> believe this still accommodates other standards orgs (like the W3C)
> using their processes to publish documents that register entries, just
> as with media types.
> 
> Assuming this is acceptable and no serious shortcomings are found in
> this draft, I think this document is ready to progress; i.e., I
> believe (speaking as an individual) there is consensus within the Atom
> community to make the registry modifications, and the feedback I've
> heard from the HTML community is that it's not necessary to have a
> tight integration with HTML4 or HTML5.
> 
> Regards,
> 
> 
> Begin forwarded message:
> 
> > From: IETF I-D Submission Tool <idsubmission@ietf.org>
> > Date: 1 December 2008 12:03:54 PM
> > To: mnot@mnot.net
> > Subject: New Version Notification for  draft-nottingham-http-link-
> > header-03
> >
> >
> > A new version of I-D, draft-nottingham-http-link-header-03.txt has
> > been successfuly submitted by Mark Nottingham and posted to the IETF
> > repository.
> >
> > Filename:	 draft-nottingham-http-link-header
> > Revision:	 03
> > Title:		 Link Relations and HTTP Header Linking
> > Creation_date:	 2008-12-01
> > WG ID:		 Independent Submission
> > Number_of_pages: 15
> >
> > Abstract:
> > This document specifies relation types for Web links, and defines a
> > registry for them.  It also defines how to send such links in HTTP
> > headers with the Link header-field.
> >
> >
> >
> > The IETF Secretariat.
> >
> >
> 
> 
> --
> Mark Nottingham     http://www.mnot.net/
>

Received on Tuesday, 2 December 2008 07:01:33 UTC