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
browser.
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.
