Last Call: draft-nottingham-site-meta (Defining Well-Known URIs) / ISSUE-36 siteData-36

[Dan Connolly]

The TAG has had an issue on well-known URIs for years now...

ISSUE-36 siteData-36 Web site metadata improving on robots.txt, w3c/p3p
and favicon etc.
http://www.w3.org/2001/tag/group/track/issues/36

The site-meta design seems to address it, essentially, as follows:

[[
To address this, this memo defines a path prefix for these "well-
   known locations", "/.well-known/".  Future specifications that need
   to define a resource for such site-wide metadata can register their
   use to avoid collisions and minimise impingement upon sites' URI
   space.
]]

This design is in "speak now or forever hold your peace" mode, aka Last
Call, in the IETF:

"Please send substantive comments to the ietf@... mailing lists by
2009-11-06."
and
"Please discuss this draft on the apps-discuss@... [1] mailing
   list.
[1]  <https://www.ietf.org/mailman/listinfo/apps-discuss> "


I sent a procedural and an editorial comment, but as to the technical
content... I'm pretty much OK with it. Some thinking out loud:

I prefer that people would use Link: ... i.e. rather
than the client making an unsolicited request for /favicon.ico ,
it would just fetch the page it's after and look for
  Link: rel="icon" href="/company-logo.ico"
Maybe I should send a comment asking that the spec note that
alternative. Meanwhile, there are cases (e.g. P3P) where the
resource at the well-known location is something you need
*before* you make other requests, so the Link: technique doesn't
always suffice (even if I could go back in time and
get clients to stop making unsolicited requests for /favicon.ico).

Given that, I'm somewhat inclined to propose that this
design addresses TAG issue siteData-36... perhaps this draft
along with the Link: draft... maybe a short finding that
also mentions the sitemap.xml stuff is in order. Hmm.

FYI, the comments I did send are:

 * draft-nottingham-site-meta: put key bit (/.well-known/) in the
abstract Dan Connolly (Thursday, 22 October)
http://lists.w3.org/Archives/Public/www-archive/2009Oct/0030.html
  * draft-nottingham-site-meta: registration too slow, opaque Dan
    Connolly (Thursday, 22 October)
http://lists.w3.org/Archives/Public/www-archive/2009Oct/0029.html


--
Dan Connolly, W3C http://www.w3.org/People/Connolly/
gpg D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E

FYI on the W3C side.

Begin forwarded message:

> From: The IESG <iesg-secretary@...>
> Date: 10 October 2009 12:38:41 AM AEDT
> To: IETF-Announce <ietf-announce@...>
> Subject: Last Call: draft-nottingham-site-meta (Defining Well-Known  
> URIs) to Proposed Standard
> Reply-To: ietf@...
>
> The IESG has received a request from an individual submitter to  
> consider
> the following document:
>
> - 'Defining Well-Known URIs '
>   <draft-nottingham-site-meta-03.txt> as a Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send substantive comments to  
> the
> ietf@... mailing lists by 2009-11-06. Exceptionally,
> comments may be sent to iesg@... instead. In either case, please
> retain the beginning of the Subject line to allow automated sorting.
>
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-nottingham-site-meta-03.txt
>
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17778&rfc_flag=0
>
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce@...
> https://www.ietf.org/mailman/listinfo/ietf-announce

--
Mark Nottingham     http://www.mnot.net/

[Roy T. Fielding]

On Oct 22, 2009, at 9:56 AM, Dan Connolly wrote:

> The TAG has had an issue on well-known URIs for years now...
>
> ISSUE-36 siteData-36 Web site metadata improving on robots.txt, w3c/
> p3p
> and favicon etc.
> http://www.w3.org/2001/tag/group/track/issues/36
>
> The site-meta design seems to address it, essentially, as follows:
>
> [[
> To address this, this memo defines a path prefix for these "well-
>   known locations", "/.well-known/".  Future specifications that need
>   to define a resource for such site-wide metadata can register their
>   use to avoid collisions and minimise impingement upon sites' URI
>   space.
> ]]
>
> This design is in "speak now or forever hold your peace" mode, aka  
> Last
> Call, in the IETF:
>
> "Please send substantive comments to the ietf@... mailing lists  
> by
> 2009-11-06."
> and
> "Please discuss this draft on the apps-discuss@... [1] mailing
>   list.
> [1]  <https://www.ietf.org/mailman/listinfo/apps-discuss> "
>
>
> I sent a procedural and an editorial comment, but as to the technical
> content... I'm pretty much OK with it. Some thinking out loud:
>
> I prefer that people would use Link: ... i.e. rather
> than the client making an unsolicited request for /favicon.ico ,
> it would just fetch the page it's after and look for
>  Link: rel="icon" href="/company-logo.ico"

I would prefer that as well.  In fact, I'd say that these
"well-known" addresses should be limited to stuff that must be
known before a regular resource access, such as robots and P3P,
or are an efficiency replacement for regular access, like sitemap.

....Roy

[Eran Hammer-Lahav]

> -----Original Message-----
> From: www-tag-request@... [mailto:www-tag-request@...] On Behalf
> Of Roy T. Fielding
> Sent: Thursday, October 22, 2009 1:18 PM
 
> I would prefer that as well.  In fact, I'd say that these
> "well-known" addresses should be limited to stuff that must be
> known before a regular resource access, such as robots and P3P,
> or are an efficiency replacement for regular access, like sitemap.

If we are going to give guidelines on when well-known are appropriate, we should also include cases when there is no specific resource to associate metadata with, such as site policy of location of site-wide services. The use of the root resource for these cases is abusive.

EHL

[Roy T. Fielding]

On Oct 22, 2009, at 2:08 PM, Eran Hammer-Lahav wrote:

>> -----Original Message-----
>> From: www-tag-request@... [mailto:www-tag-request@...] On  
>> Behalf
>> Of Roy T. Fielding
>> Sent: Thursday, October 22, 2009 1:18 PM
>
>> I would prefer that as well.  In fact, I'd say that these
>> "well-known" addresses should be limited to stuff that must be
>> known before a regular resource access, such as robots and P3P,
>> or are an efficiency replacement for regular access, like sitemap.
>
> If we are going to give guidelines on when well-known are  
> appropriate, we should also include cases when there is no specific  
> resource to associate metadata with, such as site policy of location  
> of site-wide services. The use of the root resource for these cases  
> is abusive.

Agreed, though I don't understand why any of that is needed.
OPTIONS was designed for this purpose.

....Roy

[Eran Hammer-Lahav]

When I did my survey last year for possible solutions, the issues raised about OPTIONS were lack of support/understanding in many web environments and hosting services, no caching, and the need to define a syntax for the OPTIONS response in addition to that of the metadata document. Of all these, the difficulty in deployment on both the server and client side (unfortunately) prevents OPTIONS from being used in most web protocols.

EHL

> -----Original Message-----
> From: Roy T. Fielding [mailto:fielding@...]
> Sent: Thursday, October 22, 2009 3:33 PM
> To: Eran Hammer-Lahav
> Cc: Dan Connolly; www-tag@...
> Subject: Re: Last Call: draft-nottingham-site-meta (Defining Well-Known
> URIs) / ISSUE-36 siteData-36
>
> On Oct 22, 2009, at 2:08 PM, Eran Hammer-Lahav wrote:
> >> -----Original Message-----
> >> From: www-tag-request@... [mailto:www-tag-request@...] On
> >> Behalf
> >> Of Roy T. Fielding
> >> Sent: Thursday, October 22, 2009 1:18 PM
> >
> >> I would prefer that as well.  In fact, I'd say that these
> >> "well-known" addresses should be limited to stuff that must be
> >> known before a regular resource access, such as robots and P3P,
> >> or are an efficiency replacement for regular access, like sitemap.
> >
> > If we are going to give guidelines on when well-known are
> > appropriate, we should also include cases when there is no specific
> > resource to associate metadata with, such as site policy of location
> > of site-wide services. The use of the root resource for these cases
> > is abusive.
>
> Agreed, though I don't understand why any of that is needed.
> OPTIONS was designed for this purpose.
>
> ....Roy

[Roy T. Fielding]

On Oct 22, 2009, at 3:48 PM, Eran Hammer-Lahav wrote:

> When I did my survey last year for possible solutions, the issues  
> raised about OPTIONS were lack of support/understanding in many web  
> environments and hosting services, no caching, and the need to  
> define a syntax for the OPTIONS response in addition to that of the  
> metadata document. Of all these, the difficulty in deployment on  
> both the server and client side (unfortunately) prevents OPTIONS  
> from being used in most web protocols.

Ugh.  If I had an example of what needs doing, I could make
sure it works on Apache.  Most things can be configured like

    SetEnvIf Request_Method OPTIONS do_options_stuff=y
    Header add Link '</favicon.ico>;rel="icon"' env=do_options_stuff

but I'd have to check if OPTIONS has a default handler.

Of course, mod_rewrite can do most anything.

    RewriteCond %{REQUEST_METHOD} ^OPTIONS
    RewriteRule  ^/  /.well-known/  [L]

as just a guess.

....Roy

[Joseph A Holsten]

Roy T. Fielding supposedly wrote:

> On Oct 22, 2009, at 3:48 PM, Eran Hammer-Lahav wrote:
>
>> When I did my survey last year for possible solutions, the issues  
>> raised about OPTIONS were lack of support/understanding in many web  
>> environments and hosting services, no caching, and the need to  
>> define a syntax for the OPTIONS response in addition to that of the  
>> metadata document. Of all these, the difficulty in deployment on  
>> both the server and client side (unfortunately) prevents OPTIONS  
>> from being used in most web protocols.
>
> Ugh.  If I had an example of what needs doing, I could make
> sure it works on Apache.  Most things can be configured like
>
>   SetEnvIf Request_Method OPTIONS do_options_stuff=y
>   Header add Link '</favicon.ico>;rel="icon"' env=do_options_stuff

Which is lovely for us, but most of the world still chooses to suffer  
with shared hosting. And plenty access the web through broken proxies.  
And yahoo cries itself to sleep when things can't be cached. So, the  
justification was for an idiot-proof alternative to OPTIONS, with  
caching.

Short of paying for everyone's hosting, teaching them apache configs,  
replacing their other broken software, and paying for every OPTIONS  
request that yahoo wishes could be cached, I don't know how to fix it.  
Well-known seems to be the worst solution to this problem, except for  
everything else.

BTW, mnot has been trying to make OPTIONS work for a while: http://www.mnot.net/blog/2005/04/03/options

--
Joseph Holsten
http://josephholsten.com

[Anne van Kesteren-2]

On Fri, 23 Oct 2009 11:30:07 +0200, Joseph A Holsten  
<joseph@...> wrote:
> Which is lovely for us, but most of the world still chooses to suffer  
> with shared hosting.

Also on shared hosting accounts, e.g. with DreamHost, the ability to use  
OPTIONS is there. We did some research into this when we switched from GET  
to OPTIONS for http://www.w3.org/TR/cors/ Most shared hosting accounts  
give the ability to use .htaccess or run PHP/Perl/Python or something and  
with each of those it is not very hard to get things to work.


--
Anne van Kesteren
http://annevankesteren.nl/

[Eran Hammer-Lahav]

Are there any adoption numbers available for this work? It would be valuable information.

EHL

> -----Original Message-----
> From: Anne van Kesteren [mailto:annevk@...]
> Sent: Friday, October 23, 2009 4:23 AM
> To: Joseph A Holsten; Roy T. Fielding
> Cc: Eran Hammer-Lahav; Dan Connolly; www-tag@...
> Subject: Re: Last Call: draft-nottingham-site-meta (Defining Well-Known
> URIs) / ISSUE-36 siteData-36
>
> On Fri, 23 Oct 2009 11:30:07 +0200, Joseph A Holsten
> <joseph@...> wrote:
> > Which is lovely for us, but most of the world still chooses to suffer
> > with shared hosting.
>
> Also on shared hosting accounts, e.g. with DreamHost, the ability to
> use
> OPTIONS is there. We did some research into this when we switched from
> GET
> to OPTIONS for http://www.w3.org/TR/cors/ Most shared hosting accounts
> give the ability to use .htaccess or run PHP/Perl/Python or something
> and
> with each of those it is not very hard to get things to work.
>
>
> --
> Anne van Kesteren
> http://annevankesteren.nl/

[Karl Dubost-3]

Le 22 oct. 2009 à 18:48, Eran Hammer-Lahav a écrit :
> the issues raised about OPTIONS were lack of support/understanding  
> in many web environments and hosting services,

Is there a document summarizing this (interoperability tests)?

--
Karl Dubost
Montréal, QC, Canada
http://www.la-grange.net/karl/

[Joseph A Holsten]

On Oct 25, 2009, at 6:32 AM, Karl Dubost wrote:
> Le 22 oct. 2009 à 18:48, Eran Hammer-Lahav a écrit :
>> the issues raised about OPTIONS were lack of support/understanding  
>> in many web environments and hosting services,
>
> Is there a document summarizing this (interoperability tests)?

Eran Hammer-Lahav wrote <http://hueniverse.com/2008/09/discovery-and-http/ 
 > to document the need for well-known and LRDD (draft-hammer-
discovery). It didn't have interop tests. I just took mnot's word for  
it <http://www.mnot.net/blog/2005/04/03/options>.

--
Joseph Holsten
http://josephholsten.com

[Anne van Kesteren-2]

On Fri, 23 Oct 2009 17:13:34 +0200, Eran Hammer-Lahav  
<eran@...> wrote:
> Are there any adoption numbers available for this work? It would be  
> valuable information.

It's still a bit too early for that I think.


--
Anne van Kesteren
http://annevankesteren.nl/