Re: Uniform access to descriptions

Xiaoshu,

I think you need to look at section 19.6.2.4 of RFC2068 which describes the
Link header. This conversation is not about the LINK method.

Ian

On Thu, Apr 10, 2008 at 11:19 PM, Xiaoshu Wang <wangxiao@musc.edu> wrote:

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