Re: Feedback for draft-nottingham-http-link-header-03
Eran Hammer-Lahav <eran-GmYI2sWRrjEj5TC/[email protected]> Tue, 2 Dec 2008 18:36:40 -0700
| Newsgroups | gmane.ietf.http-wg,gmane.comp.web.general |
|---|---|
| Message-ID | <C55B22A8.F4A4%[email protected]> |
--_000_C55B22A8F4A4eranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable (adding www-talk for /site-meta comments) A separate header is easily workable, but will require a different approach= to the proposed simplified /site-meta text format. It cannot be a list of = Link headers without the "Link: " prefix and still support this kind of ext= ension. EHL On 12/2/08 5:31 PM, "Mark Nottingham" <[email protected]> wrote: A separate header is by far the best way to do this. On 02/12/2008, at 7:35 PM, Eran Hammer-Lahav wrote: > >> Well, right now there's no extension point; the target does not allow >> templating, and a parameter can't override it (recipients will ignore >> extension parameters they don't understand). >> >> One potential solution would be to state that if a link target that >> is >> not a syntactically valid URI-reference is reserved for future >> extensions (so clients ignore it for now). > > This looks like the more promising option. > >> Another one would be to use a different header, such as Link- >> Template, >> defined in version 00 of the draft >> (<http://tools.ietf.org/html/draft-nottingham-http-link-header- >> 00#section-5>). > > The problem with that is the lack of equal treatment this whole > draft is trying to establish for Link header/element. This will also > stand in the way of the new suggestion to simplify /site-meta to > switch to a simple text document with Link header records (with the > "Link: " stripped). > >> Personally, I'd like to see this move ahead without any dependency on >> URI templates. > > I agree. There is urgent need in getting this spec finalized and the > templates discussion is far from conclusion. But there are enough > compelling reasons to bake into this spec support for such future > extensions. I think the suggestion to ignore non-compliant URIs is > the best option, and I would prefer to see it indicated in the ABNF, > but if not, a simple clarification would suffice. > > EHL > -- Mark Nottingham http://www.mnot.net/ --_000_C55B22A8F4A4eranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <HTML> <HEAD> <TITLE>Re: Feedback for draft-nottingham-http-link-header-03</TITLE> </HEAD> <BODY> <FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:= 11pt'>(adding www-talk for /site-meta comments)<BR> <BR> A separate header is easily workable, but will require a different approach= to the proposed simplified /site-meta text format. It cannot be a list of = Link headers without the “Link: “ prefix and still support this= kind of extension.<BR> <BR> EHL<BR> <BR> <BR> On 12/2/08 5:31 PM, "Mark Nottingham" <<a href=3D"[email protected]= t">[email protected]</a>> wrote:<BR> <BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"= ><SPAN STYLE=3D'font-size:11pt'>A separate header is by far the best way to= do this.<BR> <BR> <BR> On 02/12/2008, at 7:35 PM, Eran Hammer-Lahav wrote:<BR> <BR> ><BR> >> Well, right now there's no extension point; the target does not al= low<BR> >> templating, and a parameter can't override it (recipients will ign= ore<BR> >> extension parameters they don't understand).<BR> >><BR> >> One potential solution would be to state that if a link target tha= t<BR> >> is<BR> >> not a syntactically valid URI-reference is reserved for future<BR> >> extensions (so clients ignore it for now).<BR> ><BR> > This looks like the more promising option.<BR> ><BR> >> Another one would be to use a different header, such as Link-<BR> >> Template,<BR> >> defined in version 00 of the draft<BR> >> (<<a href=3D"http://tools.ietf.org/html/draft-nottingham-http-l= ink-header-">http://tools.ietf.org/html/draft-nottingham-http-link-header-<= /a><BR> >> 00#section-5>).<BR> ><BR> > The problem with that is the lack of equal treatment this whole<BR> > draft is trying to establish for Link header/element. This will also<B= R> > stand in the way of the new suggestion to simplify /site-meta to<BR> > switch to a simple text document with Link header records (with the<BR= > > "Link: " stripped).<BR> ><BR> >> Personally, I'd like to see this move ahead without any dependency= on<BR> >> URI templates.<BR> ><BR> > I agree. There is urgent need in getting this spec finalized and the<B= R> > templates discussion is far from conclusion. But there are enough<BR> > compelling reasons to bake into this spec support for such future<BR> > extensions. I think the suggestion to ignore non-compliant URIs is<BR> > the best option, and I would prefer to see it indicated in the ABNF,<B= R> > but if not, a simple clarification would suffice.<BR> ><BR> > EHL<BR> ><BR> <BR> <BR> --<BR> Mark Nottingham <a href=3D"http://www.mnot.net/">ht= tp://www.mnot.net/</a><BR> <BR> <BR> </SPAN></FONT></BLOCKQUOTE> </BODY> </HTML> --_000_C55B22A8F4A4eranhueniversecom_--