URIs, domains and authority

Mark Nottingham <mnot@mnot.net> Fri, 16 January 2009 06:11 UTC

Return-Path: <apps-discuss-bounces@ietf.org>
X-Original-To: apps-discuss-archive@ietf.org
Delivered-To: ietfarch-apps-discuss-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D3173A6803; Thu, 15 Jan 2009 22:11:37 -0800 (PST)
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F9273A6803 for <apps-discuss@core3.amsl.com>; Thu, 15 Jan 2009 22:11:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.331
X-Spam-Level:
X-Spam-Status: No, score=-5.331 tagged_above=-999 required=5 tests=[AWL=-2.732, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3J0cW+JNjoWi for <apps-discuss@core3.amsl.com>; Thu, 15 Jan 2009 22:11:34 -0800 (PST)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id 41FB53A67AA for <discuss@apps.ietf.org>; Thu, 15 Jan 2009 22:11:34 -0800 (PST)
Received: from [192.168.1.4] (unknown [209.131.62.115]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 63E06D059E for <discuss@apps.ietf.org>; Fri, 16 Jan 2009 01:11:15 -0500 (EST)
Message-Id: <319C1C80-F0E8-41ED-8422-3FB303CBCA6F@mnot.net>
From: Mark Nottingham <mnot@mnot.net>
To: Apps Discuss <discuss@apps.ietf.org>
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: URIs, domains and authority
Date: Fri, 16 Jan 2009 17:11:15 +1100
X-Mailer: Apple Mail (2.930.3)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"; DelSp="yes"
Sender: apps-discuss-bounces@ietf.org
Errors-To: apps-discuss-bounces@ietf.org

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@example.org
   xmpp:user@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@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss