Re: Fallback flow for /site-meta for top level domains

Considering that one of your core use cases for this is security- 
related, I'm surprised that you're effectively arguing that HTTP and  
HTTPS URLs with the same authority be collapsed into one name space.

Many standards and common practices currently sandbox policy and  
metadata to a single URL scheme + authority by default, including  
robots.txt, p3p.xml, cookie scoping, automated redirection processing  
in HTTP, cache invalidation, OPTIONS metadata, cross-site scripting  
and I'm sure quite a few more. This is the de facto standard for what  
a "Web site" is, and while there are many other colloquial meanings of  
that phrase, this is current technical practice.

Trying to establish a standard for site-wide metadata that doesn't  
follow this practice is IMO doomed to sow yet more confusion about an  
already muddled area, and potentially open up security as well as  
usability and technical problems.

That said, there's nothing to stop a particular application -- e.g.,  
OpenID -- saying that for a particular purpose, site-meta should be  
checked on a HTTP URL even though the URL presented is mailto: (for  
example), or even that www.example.com should be tried if example.com  
isn't available (although I still don't think it's necessary).

What I'm not willing to do is enshrine these things in standards that  
are supposed to help extend the Web architecture, not dilute it. The  
fact that a few $2 Web hosts don't provide adequate control to their  
customers in 2008 should not affect something so fundamental as the  
definition of what a Web site is for the next 30 years (if this  
succeeds, of course).

Cheers,


On 03/12/2008, at 6:32 PM, Eran Hammer-Lahav wrote:

>> On 02/12/2008, at 4:24 PM, Mark Nottingham wrote:
>>
>> /site-meta on http://foobar.com/ doesn't (and can't, on its own) make
>> any authoritative assertions about mailto:dirk@foobar.com; even  
>> though
>> the authority is the same, the URI scheme is different.
>>
>> I know this particular issue is an important one to the OpenID folks,
>> but there needs to be a very careful and broad discussion of allowing
>> policy and metadata from HTTP to be considered *automatically*
>> authoritative for other protocols.
>
> I do not considered /site-meta to be about HTTP resources. It is  
> metadata about the domain authority and uses HTTP as the protocol to  
> deliver that document. It can equally link to HTTP URIs as to other  
> URIs (i.e. point to its robots.txt available at an ftp:// URI). I  
> think it is safe to assume that whoever controls the domain controls  
> any URI scheme within that domain. Companies can split control  
> between departments but you go high enough there is one entity which  
> owns everything under that authority.
>
> HTTP clearly allows: 'GET mailto:eran@example.com', but what is  
> actually served is up to the server. In theory, that can serve a 303  
> with Link header to the XRD describing the identifier. The problem,  
> of course, is that most web servers will fail on such request, or at  
> least most platforms will not allow the developer easy access to  
> control the response to such requests. But the point is, the HTTP  
> protocol is nowhere restricted to provide information about HTTP  
> URIs alone. The fact that user-agents will use HTTP when the URI  
> scheme is HTTP and use FTP when the URI scheme is FTP is more of a  
> practical convention than a strict requirement.
>
> The issue of what constitute authoritative metadata with regard to  
> the domain authority is not something we can resolve beyond the  
> reasonable expectation that the entity that control the domain has  
> sufficient authority. Can the profile.yahoo.com admin be considered  
> the authority for my profile page? In the context of discovery, I  
> believe the answer is yes. Philosophically, I can argue that only  
> the profile owner has the authority to control that page, but such  
> control in today's infrastructure, is eventually enforced by the  
> domain admin anyway.
>
> EHL


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

Received on Wednesday, 3 December 2008 10:39:19 UTC