W3C home > Mailing lists > Public > www-talk@w3.org > January to February 2009

Re: Origin vs Authority; use of HTTPS (draft-nottingham-site-meta-01)

From: Thomas Roessler <tlr@w3.org>
Date: Wed, 11 Feb 2009 00:48:43 +0000
To: www-talk@w3.org
Message-Id: <745649D1-365B-4D1D-A009-C2FB944A3A42@w3.org>
Cc: Eran Hammer-Lahav <blade@yahoo-inc.com>, ietf-http-wg@w3.org, discuss@apps.ietf.org, Adam Barth <abarth@cs.stanford.edu>, Collin Jackson <collinj@cs.stanford.edu>, Mark Nottingham <mnot@yahoo-inc.com>

On 11 Feb 2009, at 01:31, Mark Nottingham wrote:

> Gentle reminder; the draft asks for discussion on www-talk. Sending  
> followups there (I should have mentioned this in the announcement,  
> sorry)...

(and I should read instructions.... apologies)

>> The obvious solution to that part of the puzzle is to let the  
>> mechanism default to the same URI scheme, unless there is a  
>> specific convention to the contrary.  That should cover any URI  
>> schemes for which a safe retrieval operation is defined (HTTP,  
>> HTTPS, FTP come to mind).
> I'm happy to clarify this by either adding scheme/protocol to the  
> (host, port) tuple (although we'll probably have to come up with a  
> different term than "authority"; PLEASE don't say "endpoint" ;),  
> which will affect both the default scoping of application as well as  
> the discovery mechanism, or just limiting it to discovery.

I'd use the (scheme, host, port) triple to identify the endpoints that  
we're dealing with here, both for scope and discovery. Adam Barth's  
draft-abarth-origin gives a canonicalization procedure for these  
tuples.  That will be useful when the tuples derived from different  
URIs need to be compared, to determine whether one is in the same site  
metadata scope as the other.

Calling that kind of triple "an origin" seems fine, and is consistent  
with the usage of that word in draft-abarth-origin and elsewhere.

The benefit of using the triple for both discovery and scope is that  
you don't acquire yet another possible cross-origin channel in the  

>> For other URI schemes, one could either punt on this issue  
>> completely, define a default fall-back to HTTP (or HTTPS, depending  
>> on which of the two better matches the security properties of the  
>> protocol in question), or actually say explicitly what's the  
>> correct scheme.
> I'm inclined to punt on it. Default fall-back to HTTP makes too many  
> assumptions.

Same inclination here, actually.
Received on Wednesday, 11 February 2009 01:12:13 UTC

This archive was generated by hypermail 2.4.0 : Monday, 20 January 2020 16:08:30 UTC