RE: LINK & UNLINK Methods

Actually Jim, URIs are tokens and thus do not have spaces. As the HTTP
spec requires spaces between all tokens (please see section 2.1 of RFC
2068), your quotes are unnecessary.

For example, link: < http://blah > ; destination = http://;;;;;;;;;;;;;
; type = http://blah , < http://foo > ; destination = http:/;;;;; ; type
= http://dervenersnitzel

Also if the Link header is going to be dumped from the HTTP spec then
there is no backwards compatibility to be worried about and we can
format the header properly, which should be:
Link = "Link" ":" Source Destination Type *(";" link-param)

Also, if the link header is going away then we can forget all the
non-dav parameters. After all, no need to define the relationship with
non-existent parameters. If it isn't in the HTTP 1.1 spec, it isn't our
problem.

		Yaron

> -----Original Message-----
> From:	Jim Whitehead [SMTP:ejw@ics.uci.edu]
> Sent:	Wednesday, March 26, 1997 7:10 PM
> To:	w3c-dist-auth@w3.org
> Cc:	fielding@ics.uci.edu
> Subject:	Re: LINK & UNLINK Methods
> 
> Yaron Goland writes:
> >1.2     Link Header
> >
> >Link = "Link" ":" #("<" URI ">" *(";" DAV-link-param)
> >DAV-link-param = (Source | Destination | Type | link-param)
> >Source = "Source" "=" URI
> >Destination = "Destination" "=" URI
> >Type = "Type" "=" Token
> >
> >This definition is adapted from section 19.6.2.4 of RFC 2068.
> Link-param
> >is defined in that section. Please note that the above is not a
> >redefinition of the link header. The syntax specified above is 100%
> in
> >compliance with the link header given in RFC 2068. Rather the above
> >simply specifies the fields and extensions of particular interest to
> >DAV.
> 
> I like this proposal.  There are, however, a few issues with it that
> need
> to be ironed out before it can be finalized.
> 
> 1. Flawed BNF.  Well Yaron, it looks like you've been writing BNF at
> midnight (again :-), since there are two flaws with your BNF:
>   - There is no way to distinguish between another DAV-link-param and
> a ";"
> in a URI -- for example, a ";" parameter in a URL.  This is why we
> always
> escaped URIs at the design team meetings, and why they're escaped
> (with
> quotes) in the HTTP spec's definition of the Link header.
>   - You repeat the HTTP spec's error of omitting the trailing ), so
> the
> scope of the # operator is ambiguous.
> 
> 
> My proposal for the BNF for a DAV Link header is given below.
> 
> The BNF from the Link specification in Section 19.6.2.4 of the HTTP
> specification is as follows:
> 
>  Link           = "Link" ":" #("<" URI ">" *( ";" link-param )
> 
>           link-param     = ( ( "rel" "=" relationship )
>                              | ( "rev" "=" relationship )
>                              | ( "title" "=" quoted-string )
>                              | ( "anchor" "=" <"> URI <"> )
>                              | ( link-extension ) )
> 
>           link-extension = token [ "=" ( token | quoted-string ) ]
> 
>           relationship   = sgml-name
>                          | ( <"> sgml-name *( SP sgml-name) <"> )
> 
>           sgml-name      = ALPHA *( ALPHA | DIGIT | "." | "-" )
> 
> 
> I propose that the syntax for the DAV Link header be defined as
> follows:
> 
>  Link           = "Link" ":" #("<" URI ">" *( ";" dav-link-param ) )
> dav-link-param = ( source | destination | type | link-param )
> source = "source" "=" <"> URI <">
> destination = "destination" "=" <"> URI <">
> type = "type" "=" token
> 
> link-param, relationship, link-extension are as defined in Section
> 19.6.2.4
> of the HTTP specification.  However, since this Appendix may be
> deleted
> from a future (next) revision of the HTTP/1.1 RFC, they need to be
> restated
> in the DAV specification:
> 
>           link-param     = ( ( "rel" "=" relationship )
>                              | ( "rev" "=" relationship )
>                              | ( "title" "=" quoted-string )
>                              | ( "anchor" "=" <"> URI <"> )
>                              | ( link-extension ) )
> 
>           link-extension = token [ "=" ( token | quoted-string ) ]
> 
>           relationship   = sgml-name
>                          | ( <"> sgml-name *( SP sgml-name) <"> )
> 
>           sgml-name      = ALPHA *( ALPHA | DIGIT | "." | "-" )
> 
> This also raises the issue of how much we need to support the existing
> LINK
> method, if it is slated to be phased out.  Roy?
> 
> 2. Interactions between existing link parameters and DAV link
> parameters.
> 
>   - If a DAV TYPE parameter is defined, should REL be allowed?  Or
> should
> DAV simply use the existing REL parameter as its type?  Or are are REL
> and
> TYPE two names for the same concept?
> 
>   - an ANCHOR parameter can be used to indicate a source other than
> the URI
> on which the Link header is stored.  If a SOURCE parameter is present,
> does
> it override an ANCHOR parameter?
> 
>   - should a DAV Type be a "relationship" rather than a "token"?
> There are
> fairly minor differences between them, the largest one being that a
> token
> can start with a number.  This would allow us to write:
> 
> type = ("type" | "rel") "=" relationship
> 
> >A link header must contain exactly one Source or Destination
> attribute.
> >The URI included at the beginning of the header then takes upon
> itself
> >the unspecified value.
> 
> Or should the unspecified URI always be the destination, like it is in
> the
> HTTP spec.?
> 
> >A DAV server is only required to record Source, Destination, and
> Type.
> >It may drop all other attributes if it so chooses. In addition a DAV
> >server may not record two links which have the same source,
> destination,
> >and type but differ on other attributes. A link is uniquely
> identified
> >by the source/destination/type triple.
> 
> I agree with this.
> 
> - Jim
>

Received on Thursday, 27 March 1997 00:54:08 UTC