Re: Uniform access to descriptions

Roy T. Fielding wrote:
> On Apr 8, 2008, at 4:33 PM, Xiaoshu Wang wrote:
>> "Honestly, after I read the Nottingham's draft, I dislike it even 
>> more.   The LINK header is essentially a "cute" way to move some of 
>> the RDF assertions into the HTTP headers. If you exam the proposed 
>> Link header more closely, they are more or less the Dublin Core.  
>> What it will lead to is what you described as "transclude" all URIs 
>> into the headers.  It is very dangerous and very bad.  Consider the 
>> copyright LINK. If the content carries a copyright statement, which 
>> is different from the LINK's copyright?  Which one is the right one?".
>
> FTR, that is complete nonsense.  Link was defined in 1992.  It is 
> already an
> HTTP header field.  It's purpose is to define typed links from one 
> resource
> to another resource, particularly when the representation is not 
> hypertext.
> It is one of the key components of the Web architecture that was left 
> out of
> RFC 2616 because the editor was in a rush to move to Draft Standard 
> status,
> not because we had any intention to remove the field from HTTP.
Roy,

I am not proposing that. 

Here is an excerpt from 
http://tools.ietf.org/html/draft-nottingham-http-link-header-01.
which I believe is what Jonathan referred to new HTTP LINK proposal.

   o  Relation Name: copyright
   o  Description: Refers to a copyright statement.
   o  Reference: [W3C.REC-html401-19991224 <http://tools.ietf.org/html/draft-nottingham-http-link-header-01#ref-W3C.REC-html401-19991224>]

I found the 1997's HTTP draft (RFC 2068).  
http://www.ietf.org/rfc/rfc2068.txt, which section 19.6.1.2, describing 
the LINK.

   The LINK method establishes one or more Link relationships between
   the existing resource identified by the Request-URI and other
   existing resources. The difference between LINK and other methods
   allowing links to be established between resources is that the LINK
   method does not allow any message-body to be sent in the request and
   does not directly result in the creation of new resources.

   If the request passes through a cache and the Request-URI identifies
   a currently cached entity, that entity MUST be removed from the
   cache.  Responses to this method are not cachable.

   Caches that implement LINK should invalidate cached responses as
   defined in section 13.10 for PUT.

I don't what kind of "typed" link should be modeled in LINK, but the 
requirement for LINK to make sense is that message must be *empty* 
because there is no other way to tell the reason of *empty* message, 
such as due to copy right restriction etc..  

But the reason for UA2D approach is not based on the assumption of the 
message is *empty* but *not empty* because by then they can avoid 303 
with  LINK+200.  You tell me where is the rational. 

Xiaoshu

Received on Thursday, 10 April 2008 22:20:44 UTC