URIs, domains and authority

[Mark Nottingham <mnot at mnot.net>]

The site-meta draft <http://tools.ietf.org/id/draft-nottingham-site-meta-00.txt 
> defines an "Über well-known location" for Web sites, in an attempt  
to allow discovery of metadata about a site without defining an  
application-specific URL (which is generally held to be bad practice).

In discussions about it, there's been some misunderstanding and  
disagreement about its scope of applicability. My original conception  
was that, for example,

  http://www.example.org/site-meta

would contain metadata specific and limited to the (HTTP, www.example.com 
, 80) triple; that is, it is scoped by the combination of protocol,  
host and port.

However, some potential users of this mechanism would like its scope  
to be broader. In particular, they'd like it to be cross-protocol;  
e.g., the metadata sourced from the URI above would also be  
potentially applicable to the following URIs:

  mailto:user at example.org
  xmpp:user at example.org

Note that here, both the protocol used, the port used, and even the  
hostname used (because www is dropped) are different. I.e., the  
metadata is not confined to the authority, but potentially applicable  
across an entire domain, for all protocols and ports.

AIUI, these use cases involve things like discovering security policy,  
configuration negotiation, etc. E.g., some want to discover XMPP- 
related policy by making a HTTP request to a pre-determined URI in the  
same domain.

My concern here is that there's a large difference between saying that  
a special file on a Web server defines metadata for that server (and  
only that server) and saying that it does so for -- potentially --  
everything to do with that domain. As such, I'd very much like to hear  
what the rest of the IETF community thinks of this issue (positive or  
negative).

There is some background discussion on the XRI TC mailing list <http://lists.oasis-open.org/archives/xri/ 
>, which is one of the groups with this kind of use case.

I'll also mention that DNS is an obvious answer for this type of  
information, but AIUI the folks who are interested in this are wary of  
relying upon it, because of deployment concerns; i.e., some domain  
owners may not have the technical ability, knowledge or tools to  
modify their DNS to add records.

Regards,

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

_______________________________________________
Apps-Discuss mailing list
Apps-Discuss at ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss