From apps-discuss-bounces@ietf.org Mon Jan 5 09:41:59 2009 Return-Path: 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 951763A6940; Mon, 5 Jan 2009 09:41:59 -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 1E05E3A6940 for ; Mon, 5 Jan 2009 09:41:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.088 X-Spam-Level: X-Spam-Status: No, score=-3.088 tagged_above=-999 required=5 tests=[AWL=-0.490, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 PsO8Ro9i9WIW for ; Mon, 5 Jan 2009 09:41:57 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.237]) by core3.amsl.com (Postfix) with ESMTP id 1BCCB3A693E for ; Mon, 5 Jan 2009 09:41:57 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id b25so6750826rvf.49 for ; Mon, 05 Jan 2009 09:41:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type; bh=uG0zSW+KuTl4xq7DNcG3SM+3uTltSHwvMznMjTPPfaM=; b=ZqFP9vWTNEIa2lAipemeUcx4OMhMCpX+RLHquNroRlSto6LRkiYk1UJ30vVJikjjwW kZrS1cQtyzFfqTDfDDp1I3gaJ52ejTUXWENM+K9tcf0CHVUZQoAWXFqpOapgXLt6naS2 Tt9aSE5t5nMirfH9g2roCxnZsp9GKTAUan/bU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=t5dtGUROKtHYca9UC6QrYApK4dZred/gUa06hMb6Q7Br4CXvnHK3vfeRYSDZRnbTqx crC0rhTdQwsFtDyp0gFphguK+/XyiKWmoiINJ6grapxj4pjjb+WNp6anFZtTWhXBXi9+ fQrzro4o0pgYZ5fyeB52ZW1zhoo+9Ojtn0VC4= Received: by 10.140.204.7 with SMTP id b7mr10481998rvg.117.1231177303873; Mon, 05 Jan 2009 09:41:43 -0800 (PST) Received: by 10.140.140.21 with HTTP; Mon, 5 Jan 2009 09:41:43 -0800 (PST) Message-ID: Date: Mon, 5 Jan 2009 09:41:43 -0800 From: "Lisa Dusseault" To: lisa-dusseault-chairs@tools.ietf.org, aschiffman@commerce.net, discuss@ietf.org, sayrer@gmail.com, pbossut@osafoundation.org Subject: Lisa's Apps Area Activity Report for Dec 2009 MIME-Version: 1.0 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0664025609==" Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org --===============0664025609== Content-Type: multipart/alternative; boundary="----=_Part_169980_10723127.1231177303858" ------=_Part_169980_10723127.1231177303858 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline *News, updates * Registration and WG meeting scheduling open for IETF 74 in San Francisco, 22-27 March 2009. Jan 19: deadline for BOF proposals to ADs and WG meeting requests. *Document Status and Progress * Active Documents: my action - draft-ietf-sieve-mime-loop (PS): IETF Last Call ended, investigating next steps on feedback Stalled, in review, waiting on other: - draft-ietf-sieve-managesieve (PS): In IESG Evaluation Jan 15. - draft-melnikov-sieve-imapext-metadata (PS): AD Evaluation done, in IETF Last Call - draft-ietf-calsify-rfc2445bis (PS): Authors working on IESG Evaluation issues - draft-kucherawy-sender-auth-header (PS): IESG Evaluation issues. - draft-montemurro-gsma-imei-urn (Info): waiting for author changes or response - draft-freed-sieve-ihave (PS): Waiting for IESG DISCUSS position to be reviewed - draft-ietf-calsify-rfc2446bis (PS): Waiting for issues from another review to be addressed. I requested IETF Last Call prematurely. - draft-snell-atompub-bidi (PS): A couple changes needed after IESG Evaluation. - draft-ietf-usefor-usepro (PS): Finished IETF Last Call. Authors and chairs need to decide whether/what changes to make. - draft-wilde-sms-uri (PS): IESG Evaluation found a number of issues. Author needs to revise or respond. Finished Processing -- new in RFC Ed queue and new RFCs - draft-irtf-asrg-dnsbl (Info): IESG agreed that this IRTF document does not conflict with IESG work --> approved - draft-ietf-sieve-notify-mailto (PS): Approved, in RFC Ed queue. - RFC 5397: WebDAV Current Principal Extension *WG Status *ALTO: Mostly quiet in December. CALSIFY: Mostly quiet in December HTTPBIS: Plugging away on issues. Some discussion of related but non WG drafts like draft-nottingham-http-link-header, draft-dusseault-http-patch and draft-broyer-http-cookie-auth. IDNABIS: New versions of several documents posted and under discussion. SIEVE: Finishing up several docs. USEFOR: No action since last report. ------=_Part_169980_10723127.1231177303858 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
News, updates

Registration and WG meeting scheduling open for IETF 74 in San Francisco, 22-27 March 2009. 
Jan 19: deadline for BOF proposals to ADs and WG meeting requests.

Document Status and Progress

Active Documents: my action
 - draft-ietf-sieve-mime-loop (PS): IETF Last Call ended, investigating next steps on feedback

Stalled, in review, waiting on other:
 - draft-ietf-sieve-managesieve (PS): In IESG Evaluation Jan 15.
 - draft-melnikov-sieve-imapext-metadata (PS): AD Evaluation done, in IETF Last Call
 - draft-ietf-calsify-rfc2445bis (PS):  Authors working on IESG Evaluation issues
 - draft-kucherawy-sender-auth-header (PS): IESG Evaluation issues.
 - draft-montemurro-gsma-imei-urn (Info): waiting for author changes or response
 - draft-freed-sieve-ihave (PS): Waiting for IESG DISCUSS position to be reviewed
 - draft-ietf-calsify-rfc2446bis (PS): Waiting for issues from another review to be addressed.  I requested IETF Last Call prematurely.
 - draft-snell-atompub-bidi (PS): A couple changes needed after IESG Evaluation.
 - draft-ietf-usefor-usepro (PS): Finished IETF Last Call.  Authors and chairs need to decide whether/what changes to make.
 - draft-wilde-sms-uri (PS): IESG Evaluation found a number of issues. Author needs to revise or respond.

Finished Processing -- new in RFC Ed queue and new RFCs
 - draft-irtf-asrg-dnsbl (Info): IESG agreed that this IRTF document does not conflict with IESG work --> approved
 - draft-ietf-sieve-notify-mailto (PS):  Approved, in RFC Ed queue.
 - RFC 5397: WebDAV Current Principal Extension



WG Status
ALTO: Mostly quiet in December.
CALSIFY: Mostly quiet in December
HTTPBIS:   Plugging away on issues. Some discussion of related but non WG drafts like draft-nottingham-http-link-header, draft-dusseault-http-patch and draft-broyer-http-cookie-auth.
IDNABIS:  New versions of several documents posted and under discussion.
SIEVE: Finishing up several docs. 
USEFOR:  No action since last report.

------=_Part_169980_10723127.1231177303858-- --===============0664025609== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss --===============0664025609==-- From apps-discuss-bounces@ietf.org Tue Jan 6 18:26:56 2009 Return-Path: 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 E9E2C3A6872; Tue, 6 Jan 2009 18:26:56 -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 651793A6800 for ; Tue, 6 Jan 2009 18:26:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 kBmezbqCqT79 for ; Tue, 6 Jan 2009 18:26:54 -0800 (PST) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.175]) by core3.amsl.com (Postfix) with ESMTP id 6C4B33A6872 for ; Tue, 6 Jan 2009 18:26:54 -0800 (PST) Received: by wf-out-1314.google.com with SMTP id 25so8614911wfc.22 for ; Tue, 06 Jan 2009 18:26:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=7P+pBRb+LXdLuqwDpWiZFa4D06o2W8yGMXyScaZFd24=; b=sahcm2oAwMYudwB+x8LB257MVGD+ZSUo/AO3E0t/cSJqEynVNR7xRST5cznRVHnwYZ eN91bw4yqLbTfO9zt6FPPbTlfJ1h0PMAd0zGTCROFdDFPhSxIpKzQXoEOfOow19HB/70 zVFbYC2E+EEtXevJ6L6Cu6QJ23r4CAAk+bCIY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=vZ5KMhN9VLY4YUmH478WSPzRiDI9HT65OqeAmYFZfwKmR0kxonGgGvEZVX3XDMvbbI 4B2DIpeU4OUipgmq0jFMv109LSEw9TXOSp8h3BjE11NRPIp/HSNPWooUU4Snipq2I57x ENwuJ8ZMmlAB8wtcsUIkXSKsaAJYj9ytLcxVs= Received: by 10.142.177.7 with SMTP id z7mr9445203wfe.59.1231295200577; Tue, 06 Jan 2009 18:26:40 -0800 (PST) Received: by 10.142.179.4 with HTTP; Tue, 6 Jan 2009 18:26:40 -0800 (PST) Message-ID: Date: Tue, 6 Jan 2009 21:26:40 -0500 From: "Anthony Bryan" To: discuss@apps.ietf.org, apps-review@ietf.org, xml-dev@lists.xml.org, ietf-http-wg@w3.org Subject: Re: Metalink XML Download Description Format (draft-bryan-metalink-01) In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org On Mon, Sep 1, 2008 at 12:44 AM, Anthony Bryan wrote: > Greetings, > > Here is the Internet Draft for Metalink, available at > http://tools.ietf.org/html/draft-bryan-metalink-01 > with interim revisions at > http://metalinks.svn.sourceforge.net/viewvc/metalinks/internetdraft/ . > We're looking for review and public comments. > > Metalink is currently supported by some 35 applications and used by > projects such as OpenOffice.org, openSUSE, Ubuntu, cURL, and others. > > Metalink is an XML-based document format that describes a file or > lists of files to be added to a download queue. Lists are composed > of a number of files, each with an extensible set of attached > metadata. For example, each file can have a description, checksum, > and list of URIs that it is available from. > > The primary use case that Metalink addresses is the description of > downloadable content in a format so download agents can act > intelligently and recover from common errors with little or no user > interaction necessary. These errors can include multiple servers > going down and data corrupted in transmission. A new version of this draft is available at http://tools.ietf.org/html/draft-bryan-metalink-04 It contains clarifications including a simpler "Securing Metalink Documents" section. As always, we welcome comments and suggestions. We could also use help with - Inclusion of digital signatures (other than PGP) of a file listed in a metalink. For instance, files are frequently signed with PGP (section 4.2.14), and these can be included in a metalink so signature verification can be automated: -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkkcJgEACgkQeOEcayedXJFf6QCgy9pkyqqTtRZiZlz4GSLr1D13 avAAoMrPU7nomJysDbqo3uTDYcdbpz2T =GBjI -----END PGP SIGNATURE----- We don't describe other ways to sign a file and include it in the metalink. If you are familiar with other ways, please help us add these to the draft. Thanks! -- (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] )) Easier, More Reliable, Self Healing Downloads _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Thu Jan 8 09:27:46 2009 Return-Path: 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 3AB033A6853; Thu, 8 Jan 2009 09:27:46 -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 12E7A3A6853 for ; Thu, 8 Jan 2009 09:27:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.865 X-Spam-Level: X-Spam-Status: No, score=-5.865 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] 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 r0X1Wosc02Tt for ; Thu, 8 Jan 2009 09:27:44 -0800 (PST) Received: from sca-es-mail-1.sun.com (sca-es-mail-1.Sun.COM [192.18.43.132]) by core3.amsl.com (Postfix) with ESMTP id 50CB13A63D3 for ; Thu, 8 Jan 2009 09:27:44 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n08HRG6n027250 for ; Thu, 8 Jan 2009 09:27:21 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KD500B01X9PXT00@fe-sfbay-09.sun.com> (original mail from Chris.Newman@Sun.COM) for apps-discuss@ietf.org; Thu, 08 Jan 2009 09:27:16 -0800 (PST) Received: from [10.1.110.5] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KD500BQJXTEIC40@fe-sfbay-09.sun.com>; Thu, 08 Jan 2009 09:27:16 -0800 (PST) Date: Thu, 08 Jan 2009 09:27:14 -0800 From: Chris Newman Subject: Algorithm for comparing two email addresses (draft-ietf-smime-3850bis)? To: apps-discuss@ietf.org Message-id: <810049B5575CF7A8A716C7BC@446E7922C82D299DB29D899F> MIME-version: 1.0 X-Mailer: Mulberry/4.0.8 (Mac OS X) Content-disposition: inline Cc: Tim Polk , smime-chairs@tools.ietf.org, draft-ietf-smime-3850bis@tools.ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org When I was reviewing draft-ietf-smime-3850bis, I noticed it mandates comparison of email addresses but did not specify the algorithm for doing so. My DISCUSS comment is here: Is anyone aware of a stable reference for the algorithm to compare two email addresses (one from a header), so we can avoid embedding an outline of the algorithm in this specification to get it done promptly? The closest I could find is the "relaxed" Header Canonicalization Algorithm in RFC 4871 section 3.4.2. But it has unnecessary steps and additional steps would be needed to remove the non-significant WSP from the addr-spec prior to comparison. I don't think that's a good reference. Can anyone think of a better reference? I really don't want to be obstructionist about this, but I do think getting the algorithm specified will improve interoperability (since I've personally experienced S/MIME interoperability problems due to this issue). As always, feel free to let me know if you feel my discuss position is not reasonable. Getting the balance between quality and approval speed right is difficult and I do get it wrong sometimes, so feedback is welcome. Thanks, - Chris _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Thu Jan 8 10:10:56 2009 Return-Path: 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 AFC513A6990; Thu, 8 Jan 2009 10:10:56 -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 A2ED93A69A2 for ; Thu, 8 Jan 2009 10:10:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 s8vl8GIX4Wom for ; Thu, 8 Jan 2009 10:10:54 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id DAC253A6990 for ; Thu, 8 Jan 2009 10:10:53 -0800 (PST) Received: from [10.20.30.158] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n08IAbYg063910 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Jan 2009 11:10:38 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <810049B5575CF7A8A716C7BC@446E7922C82D299DB29D899F> References: <810049B5575CF7A8A716C7BC@446E7922C82D299DB29D899F> Date: Thu, 8 Jan 2009 10:10:35 -0800 To: Chris Newman , apps-discuss@ietf.org From: Paul Hoffman Subject: Re: Algorithm for comparing two email addresses (draft-ietf-smime-3850bis)? Cc: Tim Polk , smime-chairs@tools.ietf.org, draft-ietf-smime-3850bis@tools.ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org At 9:27 AM -0800 1/8/09, Chris Newman wrote: >Can anyone think of a better reference? I really don't want to be obstructionist about this, but I do think getting the algorithm specified will improve interoperability (since I've personally experienced S/MIME interoperability problems due to this issue). It would be better if this algorithm came from the Apps community than expecting the security folks to come up with it. >As always, feel free to let me know if you feel my discuss position is not reasonable. Getting the balance between quality and approval speed right is difficult and I do get it wrong sometimes, so feedback is welcome. Given that this same wording is in RFC 3850 and even its predecessor (RFC 2632), it seems a bit onerous to require this now. I agree that there could be a BCP on address matching, but stopping a bis (or, reall, ter) document on it seems over the top. _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Thu Jan 8 11:11:57 2009 Return-Path: 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 ADA5328C0FA; Thu, 8 Jan 2009 11:11:57 -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 DBB1428C0FA for ; Thu, 8 Jan 2009 11:11:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 wUAtT6RP6oj6 for ; Thu, 8 Jan 2009 11:11:56 -0800 (PST) Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) by core3.amsl.com (Postfix) with ESMTP id 0AE2728C0F5 for ; Thu, 8 Jan 2009 11:11:55 -0800 (PST) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n08JAORh005975 for ; Thu, 8 Jan 2009 14:10:24 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id n08JBf0v157772 for ; Thu, 8 Jan 2009 14:11:41 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n08JAsFD027419 for ; Thu, 8 Jan 2009 14:10:54 -0500 Received: from poplar (poplar.watson.ibm.com [9.2.24.140]) by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n08JAssV027183; Thu, 8 Jan 2009 14:10:54 -0500 Received: from Uranus-009002042072.watson.ibm.com ([9.2.42.72]) by poplar.watson.ibm.com (IMF.2005.07.16.1050.haw) with SMTP ID IMFd1231441917.2661; Thu, 08 Jan 2009 14:11:57 -0400 Date: Thu, 08 Jan 2009 14:11:36 -0500 From: Barry Leiba To: Chris Newman , apps-discuss@ietf.org Subject: Re: Algorithm for comparing two email addresses (draft-ietf-smime-3850bis)? Message-ID: In-Reply-To: <200901081728.n08HSrUJ009613@igw3.watson.ibm.com> References: <200901081728.n08HSrUJ009613@igw3.watson.ibm.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline Cc: Tim Polk , smime-chairs@tools.ietf.org, draft-ietf-smime-3850bis@tools.ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org I'm with Paul on the DISCUSS question. The proper method for comparing addresses has to be specified somewhere (I'm not sure your algorithm is even complete; what about RFC 2047 encodings; what about Unicode issues when we go to EAI?), but it's not here, and this shouldn't be held up for it. At the most, I'd ask that they put in a notation that the right side SHOULD be treated as ASCII-case-insensitive. As to where such a document belongs, I suggest EAI: since it's changing the rules, it should probably document them. [For what it's worth, I think this is related to the issue of mail loops in sieve-notify-mailto, and sieve-vacation, along with other instances in other places. There may be a need for a BCP about certain aspects of dealing with email, and it needs to be tackled. But we can't just pick some unfortunate victim that happens to mention the problem and say, basically, "You touched it; you fix it."] Barry _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Thu Jan 8 11:21:40 2009 Return-Path: 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 271263A68B2; Thu, 8 Jan 2009 11:21:40 -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 A04173A67B6 for ; Thu, 8 Jan 2009 11:21:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.433 X-Spam-Level: X-Spam-Status: No, score=-0.433 tagged_above=-999 required=5 tests=[AWL=0.615, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] 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 CrtUmnJdYi90 for ; Thu, 8 Jan 2009 11:21:32 -0800 (PST) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 5E0153A680C for ; Thu, 8 Jan 2009 11:21:32 -0800 (PST) Received: by jazz.viagenie.ca (Postfix, from userid 8) id C810A29E154D; Thu, 8 Jan 2009 14:21:18 -0500 (EST) Received: from Macintosh-7.local (unknown [206.167.141.86]) by jazz.viagenie.ca (Postfix) with ESMTP id 6992D29E1520; Thu, 8 Jan 2009 14:21:18 -0500 (EST) Message-ID: <4966522D.10206@viagenie.ca> Date: Thu, 08 Jan 2009 14:21:17 -0500 From: Marc Blanchet User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Chris Newman Subject: Re: Algorithm for comparing two email addresses (draft-ietf-smime-3850bis)? References: <810049B5575CF7A8A716C7BC@446E7922C82D299DB29D899F> In-Reply-To: <810049B5575CF7A8A716C7BC@446E7922C82D299DB29D899F> X-Enigmail-Version: 0.95.7 Cc: Tim Polk , smime-chairs@tools.ietf.org, draft-ietf-smime-3850bis@tools.ietf.org, apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org - I guess one has to take into account EAI too... - therefore, a possible draft which takes into account EAI would be a good doc. Marc. Chris Newman a =E9crit : > When I was reviewing draft-ietf-smime-3850bis, I noticed it mandates > comparison of email addresses but did not specify the algorithm for > doing so. > = > My DISCUSS comment is here: > > = > Is anyone aware of a stable reference for the algorithm to compare two > email addresses (one from a header), so we can avoid embedding an > outline of the algorithm in this specification to get it done promptly? > = > The closest I could find is the "relaxed" Header Canonicalization > Algorithm in RFC 4871 section 3.4.2. But it has unnecessary steps and > additional steps would be needed to remove the non-significant WSP from > the addr-spec prior to comparison. I don't think that's a good reference. > = > Can anyone think of a better reference? I really don't want to be > obstructionist about this, but I do think getting the algorithm > specified will improve interoperability (since I've personally > experienced S/MIME interoperability problems due to this issue). > = > As always, feel free to let me know if you feel my discuss position is > not reasonable. Getting the balance between quality and approval speed > right is difficult and I do get it wrong sometimes, so feedback is welcom= e. > = > Thanks, > - Chris > = > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- = =3D=3D=3D=3D=3D=3D=3D=3D=3D IPv6 book: Migrating to IPv6, Wiley, 2006. http://www.ipv6book.ca Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Fri Jan 9 01:52:21 2009 Return-Path: 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 C77043A68CB; Fri, 9 Jan 2009 01:52:21 -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 687CB3A68CB for ; Fri, 9 Jan 2009 01:52:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 KrIdi13D2fRO for ; Fri, 9 Jan 2009 01:52:19 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 8DAB33A68BD for ; Fri, 9 Jan 2009 01:52:19 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n099pc0c019500; Fri, 9 Jan 2009 03:52:03 -0600 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Jan 2009 11:52:00 +0200 Received: from vaebe107.NOE.Nokia.com ([10.160.244.68]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Jan 2009 11:52:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Algorithm for comparing two email addresses (draft-ietf-smime-3850bis)? Date: Fri, 9 Jan 2009 11:51:58 +0200 Message-ID: <7AB1DD29D9B2CE44A0A50010FF099467016C4038@vaebe107.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Algorithm for comparing two email addresses (draft-ietf-smime-3850bis)? thread-index: AclxxPwW277fSlxATzym8qW4QHMtmAAetHYQ References: <200901081728.n08HSrUJ009613@igw3.watson.ibm.com> From: To: , , X-OriginalArrivalTime: 09 Jan 2009 09:52:00.0204 (UTC) FILETIME=[EAA640C0:01C9723F] X-Nokia-AV: Clean Cc: tim.polk@nist.gov, smime-chairs@tools.ietf.org, draft-ietf-smime-3850bis@tools.ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org Hi all, I agree with the previous speakers on EAI. But, I feel that IDNA should be taken into account, too. = Best regards: Zolt=E1n =D6rd=F6gh E-mail: zoltan dot ordogh at nokia dot com Phone: +358 50 386 0566 -----Original Message----- From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = On Behalf Of ext Barry Leiba Sent: 08 January, 2009 21:12 To: Chris Newman; apps-discuss@ietf.org Cc: Tim Polk; smime-chairs@tools.ietf.org; draft-ietf-smime-3850bis@tools.i= etf.org Subject: Re: Algorithm for comparing two email addresses (draft-ietf-smime-= 3850bis)? I'm with Paul on the DISCUSS question. The proper method for comparing add= resses has to be specified somewhere (I'm not sure your algorithm is even c= omplete; what about RFC 2047 encodings; what about Unicode issues when we g= o to EAI?), but it's not here, and this shouldn't be held up for it. At th= e most, I'd ask that they put in a notation that the right side SHOULD be t= reated as ASCII-case-insensitive. As to where such a document belongs, I suggest EAI: since it's changing the= rules, it should probably document them. [For what it's worth, I think this is related to the issue of mail loops in= sieve-notify-mailto, and sieve-vacation, along with other instances in oth= er places. There may be a need for a BCP about certain aspects of dealing = with email, and it needs to be tackled. But we can't just pick some unfort= unate victim that happens to mention the problem and say, basically, "You t= ouched it; you fix it."] Barry _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Fri Jan 9 11:24:10 2009 Return-Path: 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 B75483A6784; Fri, 9 Jan 2009 11:24:10 -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 D960A3A6783 for ; Fri, 9 Jan 2009 11:24:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.04 X-Spam-Level: X-Spam-Status: No, score=-3.04 tagged_above=-999 required=5 tests=[AWL=-0.443, BAYES_00=-2.599, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001] 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 Xm6fVUCg7cRM for ; Fri, 9 Jan 2009 11:24:08 -0800 (PST) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.237]) by core3.amsl.com (Postfix) with ESMTP id 6B2523A6405 for ; Fri, 9 Jan 2009 11:24:08 -0800 (PST) Received: by rv-out-0506.google.com with SMTP id f9so350948rvb.5 for ; Fri, 09 Jan 2009 11:23:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type:references; bh=Kj77zSKMnwTFFOG3vvPYZH24Ta12sSTjw6XP1nVkJeM=; b=jEoP8Whw/qR9xayiOyta2oAyHbLu43lT0yvoKR+c59obRDXRPvY+RDMCiv/zu3m52V sWDdyhzR3TpkX0s7hhSmdvOHq61b0uwszCxYBSJ5tmgRgNJRTKppXr0bY9RQfPC5F7lh wp0/RiPFXR63VQOcjGPtA6v0uaD7CbKh8+mh8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:references; b=Nqw1VhqwoMQF0CvDx+v5X0KvxbSsT4vkn3LRd6d+T8MeFyqs4QlbMb+pX+MG+M1Drm vSybba/h3GtGckAko7eLZ+J+OYbCKKCTDtaqQM0gN50nWXJ+wpWlf97g9M3WQQY37DyB sNwkKp/E/JEwmg8oAT6e2X1ogAxwBhNIsUrPQ= Received: by 10.140.174.11 with SMTP id w11mr12904139rve.83.1231529034103; Fri, 09 Jan 2009 11:23:54 -0800 (PST) Received: by 10.140.140.21 with HTTP; Fri, 9 Jan 2009 11:23:54 -0800 (PST) Message-ID: Date: Fri, 9 Jan 2009 11:23:54 -0800 From: "Lisa Dusseault" To: apps-discuss@ietf.org Subject: Fwd: RFC Errata Update for Working Group Chairs In-Reply-To: <20090108203120.GC29175@isi.edu> MIME-Version: 1.0 References: <20090108203120.GC29175@isi.edu> X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0847029488==" Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org --===============0847029488== Content-Type: multipart/alternative; boundary="----=_Part_236424_4691431.1231529034097" ------=_Part_236424_4691431.1231529034097 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline FYI not just for chairs -- Apps has errata in a wide variety of areas, and what to do about the errata is not always obvious. Lisa ---------- Forwarded message ---------- From: RFC Editor Date: Thu, Jan 8, 2009 at 12:31 PM Subject: RFC Errata Update for Working Group Chairs To: wgchairs@ietf.org Cc: RFC Editor WG chairs, We have made some updates to the RFC errata system and would like to inform you of the new features and explain how these features may impact your working group. 1) We'd like to bring your attention to the improved search for RFC errata on http://www.rfc-editor.org/errata.php. You can search by WG acronym and other information. Please contact your Area Director if you find errata reports that need correction. For example, the Type (Editorial/Technical) may be incorrect. Area Directors can log in to verify errata in RFCs produced by the IETF stream, so if you want to to recommend that a report be Verified/Rejected/Held, then please let the relevant AD know. (For the meanings of Status and Type for RFC errata, please see http://www.rfc-editor.org/status_type_desc.html.) 2) Previously, the initial report message was sent to the authors of the RFC and the relevant WG chairs and ADs when the RFC was a product of a WG. The IESG has suggested that the WG mailing list be CC'ed on these messages, and we have implemented this feature. For example, grow@ietf.org would now be CC'ed on the message below. The idea is to notify the WG of the new report and potentially initiate a discussion of the validity of the report among those who are familiar with the content. This will allow the verifier to update the erratum so that its Status and Notes capture the conclusion of any discussion. Please distribute this information to your working groups as you see fit, and let us know if you have any comments or concerns. Thank you. RFC Editor >From: RFC Errata System >Date: October 23, 2008 6:05:46 PM PDT >To: vaf@cisco.com, tli@tropos.com, dromasca@avaya.com, >rbonica@juniper.net, pds@lugs.com, christopher.morrow@gmail.com >Cc: tony.li@tony.li, rfc-editor@rfc-editor.org >Subject: [Technical Errata Reported] RFC4632 (1577) > > >The following errata report has been submitted for RFC4632, >"Classless Inter-domain Routing (CIDR): The Internet Address >Assignment and Aggregation Plan". > >-------------------------------------- >You may review the report below and at: >http://www.rfc-editor.org/errata_search.php?rfc=4632&eid=1577 > >-------------------------------------- >Type: Technical >Reported by: Tony Li > >Section: 3.1 > >Original Text >------------- > For example, the legacy "Class B" network 172.16.0.0, with an >implied > network mask of 255.255.0.0, is defined as the prefix >172.16.0.0/16, > the "/16" indicating that the mask to extract the network >portion of > the prefix is a 32-bit value where the most significant 16 bits are > ones and the least significant 16 bits are zeros. Similarly, the > legacy "Class C" network number 192.168.99.0 is defined as the >prefix > 192.168.99.0/24; the most significant 24 bits are ones and the >least > significant 8 bits are zeros. > > > >Corrected Text >-------------- > For example, the legacy "Class B" network 172.16.0.0, with an >implied > network mask of 255.255.0.0, is defined as the prefix >172.16.0.0/16, > the "/16" indicating that the mask to extract the network >portion of > the prefix is a 32-bit value where the most significant 16 bits are > ones and the least significant 16 bits are zeros. Similarly, the > legacy "Class C" network number 192.168.99.0 is defined as the >prefix > 192.168.99.0/24; the most significant 24 bits are ones and the >least > significant 8 bits are zeros. > > In cases where a prefix has 1, 2, or 3 trailing insignificant > octets, it is permissible to elide the insignificant octets and > trailing '.' separators. Thus, 172.16.0.0/16 may also be >represented > as 172.16/16, and 192.168.99.0/24 is equivalent to 192.168.99/24. > > > > >Notes >----- >This adds some clarifying text and documents a common convention >for displaying prefixes. It was never the intention of the authors >to exclude the alternative notation and it has since come into >vogue. It should be explicitly documented as being acceptable. > >Instructions: >------------- >This errata is currently posted as "Reported". If necessary, please >use "Reply All" to discuss whether it should be verified or >rejected. When a decision is reached, the verifying party (IESG) >can log in to change the status and edit the report, if necessary. > >-------------------------------------- >RFC4632 (draft-ietf-grow-rfc1519bis-04) >-------------------------------------- >Title : Classless Inter-domain Routing (CIDR): The >Internet Address Assignment and Aggregation Plan >Publication Date : August 2006 >Author(s) : V. Fuller, T. Li >Category : BEST CURRENT PRACTICE >Source : Global Routing Operations >Area : Operations and Management >Stream : IETF >Verifying Party : IESG > ------=_Part_236424_4691431.1231529034097 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline FYI not just for chairs -- Apps has errata in a wide variety of areas, and what to do about the errata is not always obvious.

Lisa

---------- Forwarded message ----------
From: RFC Editor <rfc-editor@rfc-editor.org>
Date: Thu, Jan 8, 2009 at 12:31 PM
Subject: RFC Errata Update for Working Group Chairs
To: wgchairs@ietf.org
Cc: RFC Editor <rfc-editor@rfc-editor.org>


WG chairs,

We have made some updates to the RFC errata system and would like to
inform you of the new features and explain how these features may
impact your working group.

1) We'd like to bring your attention to the improved search for RFC
errata on http://www.rfc-editor.org/errata.php. You can search by WG
acronym and other information.

Please contact your Area Director if you find errata reports that need
correction.  For example, the Type (Editorial/Technical) may be
incorrect.  Area Directors can log in to verify errata in RFCs
produced by the IETF stream, so if you want to to recommend that a
report be Verified/Rejected/Held, then please let the relevant AD
know. (For the meanings of Status and Type for RFC errata, please see
http://www.rfc-editor.org/status_type_desc.html.)

2) Previously, the initial report message was sent to the authors of
the RFC and the relevant WG chairs and ADs when the RFC was a product
of a WG.  The IESG has suggested that the WG mailing list be CC'ed on
these messages, and we have implemented this feature.  For example,
grow@ietf.org would now be CC'ed on the message below.  The idea is to
notify the WG of the new report and potentially initiate a discussion
of the validity of the report among those who are familiar with the
content.  This will allow the verifier to update the erratum so that
its Status and Notes capture the conclusion of any discussion.

Please distribute this information to your working groups as you see
fit, and let us know if you have any comments or concerns.

Thank you.

RFC Editor

>From: RFC Errata System <rfc-editor@rfc-editor.org>
>Date: October 23, 2008 6:05:46 PM PDT
>To: vaf@cisco.com, tli@tropos.com, dromasca@avaya.com,
>rbonica@juniper.net, pds@lugs.com, christopher.morrow@gmail.com
>Cc: tony.li@tony.li, rfc-editor@rfc-editor.org
>Subject: [Technical Errata Reported] RFC4632 (1577)
>
>
>The following errata report has been submitted for RFC4632,
>"Classless Inter-domain Routing (CIDR): The Internet Address
>Assignment and Aggregation Plan".
>
>--------------------------------------
>You may review the report below and at:
>http://www.rfc-editor.org/errata_search.php?rfc=4632&eid=1577
>
>--------------------------------------
>Type: Technical
>Reported by: Tony Li <tony.li@tony.li>
>
>Section: 3.1
>
>Original Text
>-------------
>   For example, the legacy "Class B" network 172.16.0.0, with an
>implied
>   network mask of 255.255.0.0, is defined as the prefix
>172.16.0.0/16,
>   the "/16" indicating that the mask to extract the network
>portion of
>   the prefix is a 32-bit value where the most significant 16 bits
are
>   ones and the least significant 16 bits are zeros.  Similarly, the
>   legacy "Class C" network number 192.168.99.0 is defined as the
>prefix
>   192.168.99.0/24; the most significant 24 bits are ones and the
>least
>   significant 8 bits are zeros.
>
>
>
>Corrected Text
>--------------
>   For example, the legacy "Class B" network 172.16.0.0, with an
>implied
>   network mask of 255.255.0.0, is defined as the prefix
>172.16.0.0/16,
>   the "/16" indicating that the mask to extract the network
>portion of
>   the prefix is a 32-bit value where the most significant 16 bits
are
>   ones and the least significant 16 bits are zeros.  Similarly, the
>   legacy "Class C" network number 192.168.99.0 is defined as the
>prefix
>   192.168.99.0/24; the most significant 24 bits are ones and the
>least
>   significant 8 bits are zeros.
>
>   In cases where a prefix has 1, 2, or 3 trailing insignificant
>   octets, it is permissible to elide the insignificant octets and
>   trailing '.' separators. Thus, 172.16.0.0/16 may also be
>represented
>   as 172.16/16, and 192.168.99.0/24 is equivalent to 192.168.99/24.
>
>
>
>
>Notes
>-----
>This adds some clarifying text and documents a common convention
>for displaying prefixes.  It was never the intention of the authors
>to exclude the alternative notation and it has since come into
>vogue.  It should be explicitly documented as being acceptable.
>
>Instructions:
>-------------
>This errata is currently posted as "Reported". If necessary, please
>use "Reply All" to discuss whether it should be verified or
>rejected. When a decision is reached, the verifying party (IESG)
>can log in to change the status and edit the report, if necessary.
>
>--------------------------------------
>RFC4632 (draft-ietf-grow-rfc1519bis-04)
>--------------------------------------
>Title               : Classless Inter-domain Routing (CIDR): The
>Internet Address Assignment and Aggregation Plan
>Publication Date    : August 2006
>Author(s)           : V. Fuller, T. Li
>Category            : BEST CURRENT PRACTICE
>Source              : Global Routing Operations
>Area                : Operations and Management
>Stream              : IETF
>Verifying Party     : IESG
>


------=_Part_236424_4691431.1231529034097-- --===============0847029488== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss --===============0847029488==-- From apps-discuss-bounces@ietf.org Mon Jan 12 22:00:39 2009 Return-Path: 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 985A23A683E; Mon, 12 Jan 2009 22:00:39 -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 0241D3A67EA for ; Mon, 12 Jan 2009 22:00:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.392 X-Spam-Level: X-Spam-Status: No, score=-5.392 tagged_above=-999 required=5 tests=[AWL=-5.207, BAYES_40=-0.185] 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 OgZhDM-hrQSd for ; Mon, 12 Jan 2009 22:00:30 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id E8E803A6816 for ; Mon, 12 Jan 2009 22:00:29 -0800 (PST) Received: from [192.168.1.4] (unknown [121.44.206.3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 25D52D0BA7 for ; Tue, 13 Jan 2009 01:00:08 -0500 (EST) Message-Id: From: Mark Nottingham To: Apps Discuss Mime-Version: 1.0 (Apple Message framework v929.2) Subject: DNS prefetching Date: Tue, 13 Jan 2009 17:00:05 +1100 X-Mailer: Apple Mail (2.929.2) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org seems to be catching on: https://addons.mozilla.org/en-US/firefox/addon/8923 and this http://plasmasturm.org/log/528/ implies that Google's new Chrome browser does it. I'm curious to know what the IETF community thinks of this. The Web caching community experimented with HTTP prefetching for a while (and I believe that some browsers also dabble with it), but we were burnt by unintended side effects (e.g., taking sites down with the extra traffic, burning up costly bandwidth in non-US locations). Also, are there any security implications here, considering that DNS- based attacks often rely upon timing? Cheers, -- Mark Nottingham http://www.mnot.net/ _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Mon Jan 12 22:07:03 2009 Return-Path: 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 8E8CD3A67EA; Mon, 12 Jan 2009 22:07:03 -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 D778A3A67EA for ; Mon, 12 Jan 2009 22:07:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 Ya8GPTQpxEDS for ; Mon, 12 Jan 2009 22:07:00 -0800 (PST) Received: from rv-out-0708.google.com (rv-out-0708.google.com [209.85.198.250]) by core3.amsl.com (Postfix) with ESMTP id B84723A67D1 for ; Mon, 12 Jan 2009 22:07:00 -0800 (PST) Received: by rv-out-0708.google.com with SMTP id c5so12589917rvf.34 for ; Mon, 12 Jan 2009 22:06:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=6ZP5Ni2SLm1FClasdgDC0xC5Iqu1n0QNB+jU0qDlTyA=; b=Zc5weezLP/Mfd1LJxOXWnjPaiE2paeDroH6zkUo9SrrMdigYKtyNLoRjTMa8pCe8pB QTEu/AxWX70X1Htih2ghCr9A1QsysP6iTgkxxYxF0SzbBJyZr0iUHnL7WPikYBkVelvx TDNFwINWQmQzJkSPJ1HMtn5aJKXfx+R1Lswbg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=U8/0E/5uqnTfmbvd2LkdLRgvm4bq1cggh+MK4W3p4SSvceqSdX6M7MvA5ETvnBNdDV ujvmph8Lgz5EgCQK/MVyKiWPpDvAd10WyK1YvmleFUDQEJK/mhCqYH/c4dWZpd+VUrAG DqUKXBx82oKaCOcjoLaHZThLxXM58H76nJgwQ= MIME-Version: 1.0 Received: by 10.141.196.19 with SMTP id y19mr15109886rvp.173.1231826804448; Mon, 12 Jan 2009 22:06:44 -0800 (PST) In-Reply-To: References: Date: Tue, 13 Jan 2009 17:06:44 +1100 Message-ID: <82fa66380901122206n1a5d55a3nf5cb465918b25268@mail.gmail.com> Subject: Re: DNS prefetching From: SJ Kissane To: Mark Nottingham Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0323179521==" Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org --===============0323179521== Content-Type: multipart/alternative; boundary=000e0cd14c2a1aa04404605707a1 --000e0cd14c2a1aa04404605707a1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi I think DNS prefetching should be less of a concern than HTTP prefetching, given DNS caching. If your ISP's/network's DNS server is caching, and the link is to a site with a sensible TTL, then the extra network impact of DNS prefetching should be marginal, especially for popular pages. Also, the size of the data being transferred with DNS is smaller, and the efficiency is better. Now, one security concern, is if a web page has a huge number of links, all to different host names. It might be sensible to set a limit, e.g. on any web page, I will prefetch the first 20 hostnames I see, but stop there. Otherwise, I could insert into a HTML page hidden links to h1.example.com, h2.example.com, .... up to h1000000.example.com, and then have your web browser blindly issue 1,000,000 DNS queries. Another security requirement would be to have a sensible pause between each lookup, or else I could use that nasty HTML page to flood your DNS server. Cheers Simon 2009/1/13 Mark Nottingham > seems to be catching on: > https://addons.mozilla.org/en-US/firefox/addon/8923 > and this > http://plasmasturm.org/log/528/ > implies that Google's new Chrome browser does it. > > I'm curious to know what the IETF community thinks of this. The Web caching > community experimented with HTTP prefetching for a while (and I believe that > some browsers also dabble with it), but we were burnt by unintended side > effects (e.g., taking sites down with the extra traffic, burning up costly > bandwidth in non-US locations). > > Also, are there any security implications here, considering that DNS-based > attacks often rely upon timing? > > Cheers, > > -- > Mark Nottingham http://www.mnot.net/ > > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --000e0cd14c2a1aa04404605707a1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi

I think DNS prefetching should be less of a concern than HTTP pre= fetching, given DNS caching.
If your ISP's/network's DNS server = is caching, and the link is to a site with a sensible TTL, then
the extr= a network impact of DNS prefetching should be marginal, especially for popu= lar pages.
Also, the size of the data being transferred with DNS is smaller, and the e= fficiency is better.

Now, one security concern, is if a web page has= a huge number of links, all to different host names.
It might be sensib= le to set a limit, e.g. on any web page, I will prefetch the first 20 hostn= ames
I see, but stop there. Otherwise, I could insert into a HTML page hidden li= nks to h1.example.com,
h2.example.com, .... up to h1000000.example.com, and then have your web browser= blindly issue
1,000,000 DNS queries. Another security requirement would be to have a sens= ible pause between
each lookup, or else I could use that nasty HTML page= to flood your DNS server.

Cheers
Simon

2009/1/13 Mark Nottingham <mnot@mnot.net>
seems to be catching on:
 https://addons.mozilla.org/en-US/firefox/addon/8923
and this
 http:/= /plasmasturm.org/log/528/
implies that Google's new Chrome browser does it.

I'm curious to know what the IETF community thinks of this. The Web cac= hing community experimented with HTTP prefetching for a while (and I believ= e that some browsers also dabble with it), but we were burnt by unintended = side effects (e.g., taking sites down with the extra traffic, burning up co= stly bandwidth in non-US locations).

Also, are there any security implications here, considering that DNS-based = attacks often rely upon timing?

Cheers,

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

_______________________________________________
Apps-Discuss mailing list
Apps-Discuss@iet= f.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--000e0cd14c2a1aa04404605707a1-- --===============0323179521== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss --===============0323179521==-- From apps-discuss-bounces@ietf.org Tue Jan 13 03:17:05 2009 Return-Path: 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 07C693A68B3; Tue, 13 Jan 2009 03:17:05 -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 DF29D3A67FD for ; Tue, 13 Jan 2009 03:17:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 NunLhslf+plp for ; Tue, 13 Jan 2009 03:17:02 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by core3.amsl.com (Postfix) with ESMTP id 31FB83A69D2 for ; Tue, 13 Jan 2009 03:17:01 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.2/8.14.2) with ESMTP id n0DBGiqn003407; Tue, 13 Jan 2009 12:16:44 +0100 (CET) Received: from [10.0.1.200] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id F0F8C1704DA; Tue, 13 Jan 2009 12:16:43 +0100 (CET) Message-Id: From: Carsten Bormann To: SJ Kissane In-Reply-To: <82fa66380901122206n1a5d55a3nf5cb465918b25268@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: DNS prefetching Date: Tue, 13 Jan 2009 12:16:47 +0100 References: <82fa66380901122206n1a5d55a3nf5cb465918b25268@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org On Jan 13, 2009, at 07:06, SJ Kissane wrote: > security concern Another line for the security considerations section: DNS prefetching might give away domain names that the user of a page did not intend to actually use. (Probably most relevant with HTTPS.) Gruesse, Carsten _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Tue Jan 13 04:44:11 2009 Return-Path: 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 5E8033A6A5F; Tue, 13 Jan 2009 04:44:11 -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 9EF6C3A6A5F for ; Tue, 13 Jan 2009 04:44:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 f7pdPH7MlQaT for ; Tue, 13 Jan 2009 04:44:09 -0800 (PST) Received: from e38.co.us.ibm.com (e38.co.us.ibm.com [32.97.110.159]) by core3.amsl.com (Postfix) with ESMTP id D356C3A67EE for ; Tue, 13 Jan 2009 04:44:08 -0800 (PST) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e38.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id n0DCgPg9018517 for ; Tue, 13 Jan 2009 05:42:25 -0700 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id n0DChpO0227640 for ; Tue, 13 Jan 2009 05:43:53 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n0DChpQG013500 for ; Tue, 13 Jan 2009 05:43:51 -0700 Received: from poplar (poplar.watson.ibm.com [9.2.24.140]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n0DChpMU013490 for ; Tue, 13 Jan 2009 05:43:51 -0700 Received: from Uranus-009002042072.watson.ibm.com ([9.2.42.72]) by poplar.watson.ibm.com (IMF.2005.07.16.1050.haw) with SMTP ID IMFd1231850653.3308; Tue, 13 Jan 2009 07:44:13 -0400 Date: Tue, 13 Jan 2009 07:43:49 -0500 From: Barry Leiba To: Apps Discuss Subject: Re: DNS prefetching Message-ID: <41FA4EA6E19BE520781E08B1@Uranus-009002042072.watson.ibm.com> In-Reply-To: References: <82fa66380901122206n1a5d55a3nf5cb465918b25268@mail.gmail.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org Carsten says... > Another line for the security considerations section: > DNS prefetching might give away domain names that the user of a page did not > intend to actually use. But it only "gives them away" to your own DNS server. That's worth noting, but it's a minor issue. Barry -- Barry Leiba, Senior Technical Staff (leiba@watson.ibm.com) Internet Messaging Technology, IBM Research http://www.research.ibm.com/people/l/leiba http://www.research.ibm.com/spam _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Tue Jan 13 10:20:06 2009 Return-Path: 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 AFB743A6A78; Tue, 13 Jan 2009 10:20:06 -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 6023F3A6A78 for ; Tue, 13 Jan 2009 10:20:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.23 X-Spam-Level: X-Spam-Status: No, score=-5.23 tagged_above=-999 required=5 tests=[AWL=-2.631, 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 dUtUmfITETiV for ; Tue, 13 Jan 2009 10:20:04 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 82E693A691E for ; Tue, 13 Jan 2009 10:20:04 -0800 (PST) Received: (qmail 24564 invoked from network); 13 Jan 2009 18:19:49 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 13 Jan 2009 18:19:29 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Tue, 13 Jan 2009 11:19:28 -0700 From: Eran Hammer-Lahav To: "ietf-http-wg@w3.org" , "apps-discuss@ietf.org" , "www-tag@w3.org" Date: Tue, 13 Jan 2009 11:18:51 -0700 Subject: Request for feedback: HTTP-based Resource Descriptor Discovery Thread-Topic: Request for feedback: HTTP-based Resource Descriptor Discovery Thread-Index: Acl1q2Le73nwX51+QhWDWgT0I52KMQ== Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234127C86A082@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org http://tools.ietf.org/html/draft-hammer-discovery-00 I have recently published a draft for obtaining resource descriptors via HTTP using Link headers, Link elements (HTML, Atom), and Site-Meta [1]. The draft goal is to provide a unified view on how to use the three methods for obtaining information about resources (discovery). The draft invents very little (an extension to Site-Meta allowing it to describe individual resources and not just the overall site). Any feedback would be greatly appreciated and can be sent directly to me or discussed on the www-talk@w3.org mailing list. Thanks, EHL [1] http://tools.ietf.org/html/draft-nottingham-site-meta-00 _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Thu Jan 15 22:11:37 2009 Return-Path: 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 ; 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 ; 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 ; 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 ; Fri, 16 Jan 2009 01:11:15 -0500 (EST) Message-Id: <319C1C80-F0E8-41ED-8422-3FB303CBCA6F@mnot.net> From: Mark Nottingham To: Apps Discuss 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 defines an "=DCber 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 , 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 From apps-discuss-bounces@ietf.org Thu Jan 15 23:29:32 2009 Return-Path: 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 7D5183A68D0; Thu, 15 Jan 2009 23:29:32 -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 6ECD93A68CF for ; Thu, 15 Jan 2009 23:29:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.175 X-Spam-Level: X-Spam-Status: No, score=-5.175 tagged_above=-999 required=5 tests=[AWL=-2.576, 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 2OrrSmmC7fkj for ; Thu, 15 Jan 2009 23:29:30 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id DCC2F3A6829 for ; Thu, 15 Jan 2009 23:29:29 -0800 (PST) Received: (qmail 3760 invoked from network); 16 Jan 2009 07:29:14 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 16 Jan 2009 07:28:53 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Fri, 16 Jan 2009 00:28:53 -0700 From: Eran Hammer-Lahav To: Mark Nottingham , Apps Discuss Date: Fri, 16 Jan 2009 00:28:48 -0700 Subject: RE: URIs, domains and authority Thread-Topic: URIs, domains and authority Thread-Index: Acl3oUIUmbRd8i+SRsa7yQPC3LugFgABDW1A Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234127C86A159@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <319C1C80-F0E8-41ED-8422-3FB303CBCA6F@mnot.net> In-Reply-To: <319C1C80-F0E8-41ED-8422-3FB303CBCA6F@mnot.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org Thanks Mark. The specific context and use case in which this issue came up is described = in my recent I-D: HTTP-based Resource Descriptor Discovery [1]. The idea is= to define a method for obtaining resource descriptors (metadata) for URIs = (such as POWDER, XRD, or Metalink). While the significant majority of use c= ases are HTTP-centric, there is at least one use case in which obtaining me= tadata for a mailto URI is needed. It is not likely that SMTP would be exte= nded to offer XRD documents per email address... The authority issue is explicitly raised in the discovery draft [2]: 8.3.4. Descriptor Authority for Non-HTTP(S) URIs Site-Meta uses the HTTP protocol for providing metadata about the abstract 'web site' entity. This raises the issue whether an HTTP server can speak authoritatively for a non-HTTP resource, namely, a resource identified by a URI with a scheme other than 'http' or 'https'. From a deployment perspective, many organizations separate the administration responsibilities of their HTTP resources from other resources such as email (SMTP) or instant messaging (XMPP). It would be an unexpected behavior in such organizations if the HTTP server provides authoritative information about identifiers belonging to other departments. The process defined in this memo was design with ease of deployment as one of its top priorities. Since it is unlikely that protocols such as SMTP will introduce their own discovery extensions (which will realize any significant deployment in the foreseeable future), Site-Meta must be able to provide authoritative information regarding the descriptor location of non-HTTP(S) resources. The question whether Site-Meta can be considered authoritative for schemes other than 'http' and 'https' is application specific and is directly linked to their semantic and security considerations. If the application requires an explicit grant of authority, other methods SHOULD be defined. An outline for a simple DNS-based solution was proposed in the initial revi= sion [3]: To obtain such authority, the owner of the domain (as represented by the administrator of its DNS records) MUST declare that Site-Meta is indeed allowed to provide such information. To do so, the domain DNS records MUST include, for each domain or sub-domain for which the HTTP server has such authority, a TXT record with the exact value of '/site-meta non-http delegation enabled'. [[The DNS record type and value are included in this draft only as a straw man proposal and are likely to change based on feedback received from the DNS community. Proposals for such record are requested.]] Resource-consumers MUST verify the existence of such DNS record before obtaining and utilizing the Site-Meta document for the discovery of non-HTTP(S) resources. If no such record is found, the method fails. but has been since removed. The idea was that if an application attempts to= use Site-Meta for URI schemes other than 'http' or 'https', it should go t= o the DNS records for that authority and look for some indication that the = domain owner has explicitly allowed it. The reason why this was dropped in = the second revision was because I came to the conclusion that while the aut= hority question is generic, the solution to it will most likely have to be = application-specific. The current use case for this is allowing OpenID [4] to accept email identi= fiers (mailto) alongside HTTP URIs to improve usability. However, since Ope= nID has other security requirements, it was not at all clear if the OpenID = community will find the DNS solution sufficient. Solving the authority issu= e in a generic spec for a use cases that might not even be able to use it a= nd without any implementation experience seems counterproductive. So instea= d, the current draft contains a discussion of the authority issue (included= above) without offering any technical solutions. --- However, the question Mark raised is very much still open and must be addre= ssed by the discovery spec [1] in one of 4 ways: 1. The spec should explicitly limit discovery using Site-Meta to HTTP resou= rces as defined by Mark (i.e. scoped by the combination of protocol, host a= nd port). 2. The spec should ignore the authority question and focus on discovery for= HTTP resources, leaving the applicability to non-HTTP resource up to other= specs and applications to resolve. 3. The spec should raise the authority issue with regard to discovery using= Site-Meta but leave it up to the application to resolve when used in such = manner (current draft). 4. The spec should offer a technical solution (DNS-based or other) for usin= g Site-Meta to discovery metadata about non-HTTP resources. DNS has certainly been identified as the easiest place to "grant" such auth= ority and as mentioned above, has been suggested as a solution. While techn= ical accessibility is an important factor in this work (which is an unusual= consideration at the IETF but critical in many communities this work emerg= ed from such as OpenID and OAuth), it is not the primary concern but comple= xity for the common use cases. Since most use cases (if not all) are HTTP b= ased, I do not want to complicate them in any way to accommodate some theor= etical use cases for other protocols. So while DNS is a great approach, if = used, I would rather it applied only to non-HTTP resources where there is s= uch authority issue. EHL [1] http://tools.ietf.org/html/draft-hammer-discovery-01 [2] http://tools.ietf.org/html/draft-hammer-discovery-01#section-8.3.4 [3] http://tools.ietf.org/html/draft-hammer-discovery-00#section-8.3.3 [4] http://openid.net/specs/openid-authentication-2_0.txt > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > bounces@ietf.org] On Behalf Of Mark Nottingham > Sent: Thursday, January 15, 2009 10:11 PM > To: Apps Discuss > Subject: URIs, domains and authority > > The site-meta draft meta-00.txt > > defines an "=DCber 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 > >, 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 _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Fri Jan 16 04:40:01 2009 Return-Path: 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 F19073A6A99; Fri, 16 Jan 2009 04:40:00 -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 0F5293A6A99 for ; Fri, 16 Jan 2009 04:40:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=-0.250, 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 0FK+SKBMzQ6I for ; Fri, 16 Jan 2009 04:39:59 -0800 (PST) Received: from turner.dave.cridland.net (turner.dave.cridland.net [217.155.137.60]) by core3.amsl.com (Postfix) with ESMTP id CF5633A6A58 for ; Fri, 16 Jan 2009 04:39:58 -0800 (PST) Received: from peirce.dave.cridland.net ([217.155.137.61]) by turner.dave.cridland.net (submission) via TCP with ESMTPA id for ; Fri, 16 Jan 2009 10:49:13 +0000 Subject: Re: URIs, domains and authority References: <319C1C80-F0E8-41ED-8422-3FB303CBCA6F@mnot.net> In-Reply-To: <319C1C80-F0E8-41ED-8422-3FB303CBCA6F@mnot.net> MIME-Version: 1.0 Message-Id: <12062.1232102952.601422@peirce.dave.cridland.net> Date: Fri, 16 Jan 2009 10:49:12 +0000 From: Dave Cridland To: General discussion of application-layer protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org On Fri Jan 16 06:11:15 2009, Mark Nottingham wrote: > 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. Who, and what policy? I've not seen any mention of this on the relevant XSF lists, nor here, so it'd be useful to get some background, this is far beyond my knowledge. Otherwise I'm inclined to strongly question why discovery of XMPP policy cannot be done solely by XMPP - there's a number of obvious proposals that spring to mind, but really, involving the XMPP expertise at the XSF would be an obvious first step. I mean, the threads on this on the XRI list appear to be talking about entity capabilities, which is, franky, a well and truly solved problem in the XMPP world - look at XEP-0030 and XEP-0115. I don't see how either xmpp or mailto scheme URIs can be generically processed to extract a URI anyway. (That is, by RFC 3986 rules, both xmpp:user@example.org and mailto:user@example.org have *no* authority, only a path of "user@example.org"). Given that one understands the URI scheme, one can quite easily have different processing rules for both - indeed, technically, one has to to an extent. I know that SMTP is likely to be different, but I'll have a better idea of potential solutions if I can understand the nature of the problem a bit better. (Specifically, SMTP admins do already put considerable operational data in the DNS, and adding a metadata URI might be fine). Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Fri Jan 16 07:26:29 2009 Return-Path: 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 5E67D3A680F; Fri, 16 Jan 2009 07:26:29 -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 D13253A680F for ; Fri, 16 Jan 2009 07:26:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 g3NOBLBSBhgx for ; Fri, 16 Jan 2009 07:26:27 -0800 (PST) Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.150]) by core3.amsl.com (Postfix) with ESMTP id CD89E3A67B1 for ; Fri, 16 Jan 2009 07:26:27 -0800 (PST) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e32.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id n0GFOH6Y030928 for ; Fri, 16 Jan 2009 08:24:17 -0700 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id n0GFQA13225148 for ; Fri, 16 Jan 2009 08:26:10 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n0GFQAOH017104 for ; Fri, 16 Jan 2009 08:26:10 -0700 Received: from poplar (poplar.watson.ibm.com [9.2.24.140]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n0GFQ9H0017087; Fri, 16 Jan 2009 08:26:09 -0700 Received: from Uranus-009002042072.watson.ibm.com ([9.2.42.72]) by poplar.watson.ibm.com (IMF.2005.07.16.1050.haw) with SMTP ID IMFd1232119567.25; Fri, 16 Jan 2009 10:26:07 -0400 Date: Fri, 16 Jan 2009 10:26:07 -0500 From: Barry Leiba To: Mark Nottingham , Apps Discuss Subject: Re: URIs, domains and authority Message-ID: <540995862DE0CE1A17A90228@dyn9002042072.watson.ibm.com> In-Reply-To: <319C1C80-F0E8-41ED-8422-3FB303CBCA6F@mnot.net> References: <319C1C80-F0E8-41ED-8422-3FB303CBCA6F@mnot.net> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org > 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. The issue goes beyond dropping the "www". IBM, for example, does not send mail from "ibm.com". We use our country-code subdomains, and some others. So, where should one go to find metadata for the mailto protocol for us.ibm.com? What about fr.ibm.com and jp.ibm.com, which each might have different rules? And what about watson.ibm.com (which I use), which is under entirely different administration? If this were to be done at all, I'd suggest extending the "site-meta" concept in a way such as "site-meta-xmpp" and "site-meta-mailto" (in other words, "site-meta-"). And I'd make it be specific to the domain specified. So, to get the information in Mark's examples: http://www.example.org/site-meta http://example.org/site-meta-mailto http://example.org/site-meta-xmpp Or perhaps we'd use parameters instead: http://www.example.org/site-meta (for http on port 80) http://www.example.org/site-meta?port=8080 http://example.org/site-meta?protocol=mailto Note that "user@" isn't there for mailto or xmpp. It's "site" meta, after all. If we want to include user-specific metadata, maybe do it with a parameter: http://example.org/site-meta-mailto?user=mnot or http://example.org/site-meta?protocol=mailto&user=mnot But I'm not sure it needs to go that far. For my examples, we might have these: http://us.ibm.com/site-meta-mailto http://fr.ibm.com/site-meta-mailto http://jp.ibm.com/site-meta-mailto http://watson.ibm.com/site-meta-mailto And note that I'd expect these two: http://www.ibm.com/site-meta http://ibm.com/site-meta ...to actually be different, though for most sites they would return the same metadata. I agree with the concerns about doing this in DNS. In many large organizations, DNS management is completely separate from management of the web servers, and having web-server metadata stored in DNS would add an unnecessary layer of organizational difficulty. Barry -- Barry Leiba, Senior Technical Staff (leiba@watson.ibm.com) Internet Messaging Technology, IBM Research http://www.research.ibm.com/people/l/leiba http://www.research.ibm.com/spam _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Fri Jan 16 08:59:29 2009 Return-Path: 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 132083A68BF; Fri, 16 Jan 2009 08:59:29 -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 A483C3A68BF for ; Fri, 16 Jan 2009 08:59:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.068 X-Spam-Level: X-Spam-Status: No, score=-5.068 tagged_above=-999 required=5 tests=[AWL=-2.469, 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 7slFhQGxmYxL for ; Fri, 16 Jan 2009 08:59:27 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id E3C903A68B0 for ; Fri, 16 Jan 2009 08:59:26 -0800 (PST) Received: (qmail 28227 invoked from network); 16 Jan 2009 16:59:11 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 16 Jan 2009 16:59:11 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Fri, 16 Jan 2009 09:59:11 -0700 From: Eran Hammer-Lahav To: Dave Cridland , General discussion of application-layer protocols Date: Fri, 16 Jan 2009 09:59:06 -0700 Subject: RE: URIs, domains and authority Thread-Topic: URIs, domains and authority Thread-Index: Acl314P/Y3QW30oBTtuHuOPnFrsWtgAJDYyg Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234127C86A190@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <319C1C80-F0E8-41ED-8422-3FB303CBCA6F@mnot.net> <12062.1232102952.601422@peirce.dave.cridland.net> In-Reply-To: <12062.1232102952.601422@peirce.dave.cridland.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > bounces@ietf.org] On Behalf Of Dave Cridland > Sent: Friday, January 16, 2009 2:49 AM > To: General discussion of application-layer protocols > Subject: Re: URIs, domains and authority > > On Fri Jan 16 06:11:15 2009, Mark Nottingham wrote: > > 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. > > Who, and what policy? I've not seen any mention of this on the > relevant XSF lists, nor here, so it'd be useful to get some > background, this is far beyond my knowledge. There are not suggested use case for XMPP URIs. They were mentioned as an example of a URI that *might* be used but there are no existing use cases or requirements. There is one use case for email identifiers which implies mailto (using email as identity identifiers in sign-on and registration). > I don't see how either xmpp or mailto scheme URIs can be generically > processed to extract a URI anyway. (That is, by RFC 3986 rules, both > xmpp:user@example.org and mailto:user@example.org have *no* > authority, only a path of "user@example.org"). True, but they can both produce an addressable authority by understanding their structure. I agree though that referencing RFC 3986 would not be enough to extract their authority. Hmm. For some reason I was under the impression that they email address was the authority part but the lack of // make this assumption wrong. For the sake of discussion, let's change the example to FTP. Can Site-Meta point to FTP related metadata? EHL _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Fri Jan 16 09:07:09 2009 Return-Path: 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 7FB9728C0FC; Fri, 16 Jan 2009 09:07:09 -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 2C54F3A69B4 for ; Fri, 16 Jan 2009 09:07:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.969 X-Spam-Level: X-Spam-Status: No, score=-4.969 tagged_above=-999 required=5 tests=[AWL=-2.370, 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 7Ml+op94raS5 for ; Fri, 16 Jan 2009 09:07:07 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 2AF493A63D3 for ; Fri, 16 Jan 2009 09:07:07 -0800 (PST) Received: (qmail 29594 invoked from network); 16 Jan 2009 17:06:52 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 16 Jan 2009 17:06:50 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Fri, 16 Jan 2009 10:06:50 -0700 From: Eran Hammer-Lahav To: Barry Leiba , Mark Nottingham , Apps Discuss Date: Fri, 16 Jan 2009 10:06:44 -0700 Subject: RE: URIs, domains and authority Thread-Topic: URIs, domains and authority Thread-Index: Acl37sVt56oVixaWR3KqABK2quXcsQADgdrw Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234127C86A195@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <319C1C80-F0E8-41ED-8422-3FB303CBCA6F@mnot.net> <540995862DE0CE1A17A90228@dyn9002042072.watson.ibm.com> In-Reply-To: <540995862DE0CE1A17A90228@dyn9002042072.watson.ibm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org This just adds complexity and doesn't solve the problem. Using the protocol name in the Site-Meta resource doesn't give HTTP any more authority to describe such protocols. Also, this whole business of dropping the 'www' (or adding it) is really not part of this discussion. http://www.example.com/site-meta doesn't speak on behalf of example.com, us.example.com, etc. This doesn't mean a specific application can't come up with their own rules (though it should be properly done using DNS CNAMEs). EHL > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > bounces@ietf.org] On Behalf Of Barry Leiba > Sent: Friday, January 16, 2009 7:26 AM > To: Mark Nottingham; Apps Discuss > Subject: Re: URIs, domains and authority > > > 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. > > The issue goes beyond dropping the "www". IBM, for example, does not > send mail > from "ibm.com". We use our country-code subdomains, and some others. > So, where > should one go to find metadata for the mailto protocol for us.ibm.com? > What > about fr.ibm.com and jp.ibm.com, which each might have different rules? > And what > about watson.ibm.com (which I use), which is under entirely different > administration? > > If this were to be done at all, I'd suggest extending the "site-meta" > concept in > a way such as "site-meta-xmpp" and "site-meta-mailto" (in other words, > "site-meta-"). And I'd make it be specific to the domain > specified. > So, to get the information in Mark's examples: > > http://www.example.org/site-meta > http://example.org/site-meta-mailto > http://example.org/site-meta-xmpp > > Or perhaps we'd use parameters instead: > > http://www.example.org/site-meta (for http on port 80) > http://www.example.org/site-meta?port=8080 > http://example.org/site-meta?protocol=mailto > > Note that "user@" isn't there for mailto or xmpp. It's "site" meta, > after all. > If we want to include user-specific metadata, maybe do it with a > parameter: > > http://example.org/site-meta-mailto?user=mnot > or > http://example.org/site-meta?protocol=mailto&user=mnot > > But I'm not sure it needs to go that far. > > For my examples, we might have these: > > http://us.ibm.com/site-meta-mailto > http://fr.ibm.com/site-meta-mailto > http://jp.ibm.com/site-meta-mailto > http://watson.ibm.com/site-meta-mailto > > And note that I'd expect these two: > > http://www.ibm.com/site-meta > http://ibm.com/site-meta > > ...to actually be different, though for most sites they would return > the same > metadata. > > > I agree with the concerns about doing this in DNS. In many large > organizations, > DNS management is completely separate from management of the web > servers, and > having web-server metadata stored in DNS would add an unnecessary layer > of > organizational difficulty. > > Barry > > -- > Barry Leiba, Senior Technical Staff (leiba@watson.ibm.com) > Internet Messaging Technology, IBM Research > http://www.research.ibm.com/people/l/leiba > http://www.research.ibm.com/spam > > > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Fri Jan 16 09:29:44 2009 Return-Path: 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 BAAC928C290; Fri, 16 Jan 2009 09:29:44 -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 A725C28C290 for ; Fri, 16 Jan 2009 09:29:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 fWrcKm-QeNys for ; Fri, 16 Jan 2009 09:29:41 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 73BAD28C246 for ; Fri, 16 Jan 2009 09:29:41 -0800 (PST) Received: from [10.20.30.158] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0GHTN3h032997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Jan 2009 10:29:24 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <319C1C80-F0E8-41ED-8422-3FB303CBCA6F@mnot.net> References: <319C1C80-F0E8-41ED-8422-3FB303CBCA6F@mnot.net> Date: Fri, 16 Jan 2009 09:28:51 -0800 To: Mark Nottingham , Apps Discuss From: Paul Hoffman Subject: Re: URIs, domains and authority X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org Two comments: scope and technology At 5:11 PM +1100 1/16/09, Mark Nottingham wrote: >Note that here, both the protocol used, the port used, and even the hostname used (because www is dropped) are different. Doing so means that the administrator of sub.domain.morelabels gets to declare the metadata and policy for domain.morelabels. That seems like a policy disaster waiting to happen. To make the case as gently as possible: should a web server at http://ietf.org get to define metadata and policy for .org? If you forward with this, the semantics must be completely clear that the metadata and policy are for the exact domain name and subordinate domain names only. I do not have a problem with a web server (HTTP on 80) declaring metadata and policy for hosts running other protocols and/or on other ports of the same domain or of subordinate domains, but others might be more sensitive to this than I. >I'll also mention that DNS is an obvious answer for this type of information, Yes > 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. Tough. If the metadata and policy is about the domain in the domain name, it should be in the DNS. A tool to put something structured in the DNS are no harder to write than a tool to put it on a web page: most of the work will be in getting the structure correct, not in putting the file in the right place on the servers. Having said that, you will find people arguing forever about whether the policy is really about the domain in the domain name or the servers that are running on addresses that are pointed to by records for that domain name. This level of IETF ontology never results in better protocols for users. _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Fri Jan 16 09:50:26 2009 Return-Path: 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 EDDA528C2A9; Fri, 16 Jan 2009 09:50:25 -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 CA34828C2A8 for ; Fri, 16 Jan 2009 09:50:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.878 X-Spam-Level: X-Spam-Status: No, score=-4.878 tagged_above=-999 required=5 tests=[AWL=-2.279, 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 LWX+bLzvDVkS for ; Fri, 16 Jan 2009 09:50:24 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 1728528C2A9 for ; Fri, 16 Jan 2009 09:50:24 -0800 (PST) Received: (qmail 24554 invoked from network); 16 Jan 2009 17:50:08 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 16 Jan 2009 17:50:08 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Fri, 16 Jan 2009 10:50:08 -0700 From: Eran Hammer-Lahav To: Paul Hoffman , Mark Nottingham , Apps Discuss Date: Fri, 16 Jan 2009 10:50:02 -0700 Subject: RE: URIs, domains and authority Thread-Topic: URIs, domains and authority Thread-Index: Acl3//0Z0lm7SIR8QHKoj8b6oePnAwAAjY1w Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234127C86A19F@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <319C1C80-F0E8-41ED-8422-3FB303CBCA6F@mnot.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > bounces@ietf.org] On Behalf Of Paul Hoffman > > > 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. > > Tough. If the metadata and policy is about the domain in the domain > name, it should be in the DNS. A tool to put something structured in > the DNS are no harder to write than a tool to put it on a web page: > most of the work will be in getting the structure correct, not in > putting the file in the right place on the servers. This is simply not true. There are many platforms and environments where developers simply don't have access to such layers (but have the ability to perform simple HTTP GET requests) such as web gadgets (iGoogle, MyYahoo, OpenSocial, etc.). EHL _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Fri Jan 16 10:07:55 2009 Return-Path: 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 34B513A69B4; Fri, 16 Jan 2009 10:07:55 -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 A7B7C28C2AD for ; Fri, 16 Jan 2009 10:07:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 x-HHSyMJfQxl for ; Fri, 16 Jan 2009 10:07:52 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 8269F28C299 for ; Fri, 16 Jan 2009 10:07:51 -0800 (PST) Received: from [10.20.30.158] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0GI7Wv1034369 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Jan 2009 11:07:33 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234127C86A19F@P3PW5EX1MB01.EX1.SECURESERVER. NET> References: <319C1C80-F0E8-41ED-8422-3FB303CBCA6F@mnot.net> <90C41DD21FB7C64BB94121FBBC2E7234127C86A19F@P3PW5EX1MB01.EX1.SECURESERVER. NET> Date: Fri, 16 Jan 2009 10:07:31 -0800 To: Eran Hammer-Lahav , Mark Nottingham , Apps Discuss From: Paul Hoffman Subject: RE: URIs, domains and authority X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org At 10:50 AM -0700 1/16/09, Eran Hammer-Lahav wrote: > > -----Original Message----- >> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- >> bounces@ietf.org] On Behalf Of Paul Hoffman >> >> > 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. >> >> Tough. If the metadata and policy is about the domain in the domain >> name, it should be in the DNS. A tool to put something structured in >> the DNS are no harder to write than a tool to put it on a web page: >> most of the work will be in getting the structure correct, not in >> putting the file in the right place on the servers. > >This is simply not true. There are many platforms and environments where developers simply don't have access to such layers (but have the ability to perform simple HTTP GET requests) such as web gadgets (iGoogle, MyYahoo, OpenSocial, etc.). Are you talking about publishing or getting published results? For publishing, if someone has the authority to tell the policy and metadata for a domain, they need to have access to the location to do it. For asking, everyone has access to the DNS. _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Fri Jan 16 10:10:56 2009 Return-Path: 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 B1CAB28C2B2; Fri, 16 Jan 2009 10:10:56 -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 C1B3328C2B8 for ; Fri, 16 Jan 2009 10:10:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.976 X-Spam-Level: X-Spam-Status: No, score=-101.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 V+Cuqj6+D8dM for ; Fri, 16 Jan 2009 10:10:53 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id B44B828C2B2 for ; Fri, 16 Jan 2009 10:10:52 -0800 (PST) Received: from zps76.corp.google.com (zps76.corp.google.com [172.25.146.76]) by smtp-out.google.com with ESMTP id n0GIAYRQ022326 for ; Fri, 16 Jan 2009 18:10:36 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1232129436; bh=k3ft5rmXkmCwEbIVR6E2WTprsd0=; h=DomainKey-Signature:MIME-Version:In-Reply-To:References:Date: Message-ID:Subject:From:To:Cc:Content-Type:X-GMailtapped-By: X-GMailtapped; b=VRouaiWqImtMo29VKq9JZ4uaS8iPFwgrGLHT0h6ceoHzDAAhX zP79rgxW872nNjgl/cUJo8W2XtnyjaDWcZ9JA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-gmailtapped-by:x-gmailtapped; b=qFw+T1lzExPCpqGkGdDGbNjAXteaq4rm1XXAg3bFi18jJEN3/HMO/oi8uuUa2EYLb nnwA1Wa1cDLkje2Mgk0RQ== Received: from ewy14 (ewy14.prod.google.com [10.241.103.14]) by zps76.corp.google.com with ESMTP id n0GIAUHV028198 for ; Fri, 16 Jan 2009 10:10:31 -0800 Received: by ewy14 with SMTP id 14so2199373ewy.2 for ; Fri, 16 Jan 2009 10:10:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.210.67.4 with SMTP id p4mr3469236eba.193.1232129430358; Fri, 16 Jan 2009 10:10:30 -0800 (PST) In-Reply-To: References: <319C1C80-F0E8-41ED-8422-3FB303CBCA6F@mnot.net> Date: Fri, 16 Jan 2009 10:10:30 -0800 Message-ID: <29fb00360901161010o4ff94b2cia4b1b7f1f74b4ff2@mail.gmail.com> Subject: Re: URIs, domains and authority From: Breno de Medeiros To: Paul Hoffman X-GMailtapped-By: 172.25.146.76 X-GMailtapped: breno Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0746581456==" Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org --===============0746581456== Content-Type: multipart/alternative; boundary=0015174c3f4c038c2604609d7d52 --0015174c3f4c038c2604609d7d52 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Fri, Jan 16, 2009 at 10:07 AM, Paul Hoffman wrote: > At 10:50 AM -0700 1/16/09, Eran Hammer-Lahav wrote: > > > -----Original Message----- > >> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > >> bounces@ietf.org] On Behalf Of Paul Hoffman > >> > >> > 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. > >> > >> Tough. If the metadata and policy is about the domain in the domain > >> name, it should be in the DNS. A tool to put something structured in > >> the DNS are no harder to write than a tool to put it on a web page: > >> most of the work will be in getting the structure correct, not in > >> putting the file in the right place on the servers. > > > >This is simply not true. There are many platforms and environments where > developers simply don't have access to such layers (but have the ability to > perform simple HTTP GET requests) such as web gadgets (iGoogle, MyYahoo, > OpenSocial, etc.). > > Are you talking about publishing or getting published results? For > publishing, if someone has the authority to tell the policy and metadata for > a domain, they need to have access to the location to do it. For asking, > everyone has access to the DNS. For asking, a lot of people do not have access to DNS, because the API abstracts it away. See the list of examples above. You could add to that any number of web APIs that export only HTTP interface (not a full network stack). > > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7) --0015174c3f4c038c2604609d7d52 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Jan 16, 2009 at 10:07 AM, Paul H= offman <phoffman@i= mc.org> wrote:
At 10:50 AM -0700 1/16/09, Eran Hammer-Lahav wrote: > > -----Original Message-----
>> From: apps-discus= s-bounces@ietf.org [mailto:apps-discus= s-
>> bounces@ietf.org] On Behal= f Of Paul Hoffman
>>
>> > but AIUI the folks who are intere= sted 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.
>>
>> Tough. If the metadata and policy is about the domain in the domai= n
>> name, it should be in the DNS. A tool to put something structured = in
>> the DNS are no harder to write than a tool to put it on a web page= :
>> most of the work will be in getting the structure correct, not in<= br> >> putting the file in the right place on the servers.
>
>This is simply not true. There are many pla= tforms and environments where developers simply don't have access to su= ch layers (but have the ability to perform simple HTTP GET requests) such a= s web gadgets (iGoogle, MyYahoo, OpenSocial, etc.).

Are you talking about publishing or getting published results? For pu= blishing, if someone has the authority to tell the policy and metadata for = a domain, they need to have access  to the location to do it. For aski= ng, everyone has access to the DNS.

For asking, a lot of people do not have access to DNS, because the= API abstracts it away. See the list of examples above. You could add to th= at any number of web APIs that export only HTTP interface (not a full netwo= rk stack).
 

_____________________________________= __________
Apps-Discuss mailing list
Apps-Discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss



--
--Breno
=
+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3= : 383-A
PST (GMT-8) / PDT(GMT-7)
--0015174c3f4c038c2604609d7d52-- --===============0746581456== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss --===============0746581456==-- From apps-discuss-bounces@ietf.org Fri Jan 16 10:19:02 2009 Return-Path: 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 9A13128C2B3; Fri, 16 Jan 2009 10:19:02 -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 E386328C2B3 for ; Fri, 16 Jan 2009 10:19:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 Dzr9vvYm7oKI for ; Fri, 16 Jan 2009 10:19:01 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id C62A728C2B2 for ; Fri, 16 Jan 2009 10:19:00 -0800 (PST) Received: from [10.20.30.158] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0GIIgoT035071 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Jan 2009 11:18:43 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <29fb00360901161010o4ff94b2cia4b1b7f1f74b4ff2@mail.gmail.com> References: <319C1C80-F0E8-41ED-8422-3FB303CBCA6F@mnot.net> <29fb00360901161010o4ff94b2cia4b1b7f1f74b4ff2@mail.gmail.com> Date: Fri, 16 Jan 2009 10:18:41 -0800 To: Breno de Medeiros From: Paul Hoffman Subject: Re: URIs, domains and authority Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org At 10:10 AM -0800 1/16/09, Breno de Medeiros wrote: >For asking, a lot of people do not have access to DNS, because the API abstracts it away. See the list of examples above. You could add to that any number of web APIs that export only HTTP interface (not a full network stack). I thought Mark was talking about applications having access to the data, not people, but I could have been mistaken. If it is applications, they do not need to go through an API that might abstract away things like a DNS RRtype. _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Fri Jan 16 10:22:36 2009 Return-Path: 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 6E49C3A680C; Fri, 16 Jan 2009 10:22:36 -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 4BE2E3A6806 for ; Fri, 16 Jan 2009 10:22:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.976 X-Spam-Level: X-Spam-Status: No, score=-101.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 Q1aCH4V7rENL for ; Fri, 16 Jan 2009 10:22:34 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id 8271D28C2AF for ; Fri, 16 Jan 2009 10:22:34 -0800 (PST) Received: from zps37.corp.google.com (zps37.corp.google.com [172.25.146.37]) by smtp-out.google.com with ESMTP id n0GIMJA5004118 for ; Fri, 16 Jan 2009 10:22:19 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1232130139; bh=AgvKm7ir24VGOoxoUAStut1EjtY=; h=DomainKey-Signature:MIME-Version:In-Reply-To:References:Date: Message-ID:Subject:From:To:Cc:Content-Type:X-GMailtapped-By: X-GMailtapped; b=StXAuSUXr/jMha0inFkkGtisGE3Hu38SsQ0zCufX2pC3aqpbu xMUzps6/259RUpGoiBLD4AduSOOfrJrv/DXQQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-gmailtapped-by:x-gmailtapped; b=H38NtYPnfZYtkmcr5BnKpngcS/nYqAYo7MzHaJmymaGae+uIE8M5Ys6YBhOcoBjRM XdAHsjWHOZUd8cy9ElFkg== Received: from nf-out-0910.google.com (nfcd3.prod.google.com [10.48.105.3]) by zps37.corp.google.com with ESMTP id n0GIMF4r016428 for ; Fri, 16 Jan 2009 10:22:15 -0800 Received: by nf-out-0910.google.com with SMTP id d3so270230nfc.36 for ; Fri, 16 Jan 2009 10:22:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.210.35.17 with SMTP id i17mr3542956ebi.70.1232130134706; Fri, 16 Jan 2009 10:22:14 -0800 (PST) In-Reply-To: References: <319C1C80-F0E8-41ED-8422-3FB303CBCA6F@mnot.net> <29fb00360901161010o4ff94b2cia4b1b7f1f74b4ff2@mail.gmail.com> Date: Fri, 16 Jan 2009 10:22:14 -0800 Message-ID: <29fb00360901161022i1999e0e2u5a459a36c0bcaa4@mail.gmail.com> Subject: Re: URIs, domains and authority From: Breno de Medeiros To: Paul Hoffman X-GMailtapped-By: 172.25.146.37 X-GMailtapped: breno Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1201554514==" Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org --===============1201554514== Content-Type: multipart/alternative; boundary=0015174c17a8ff09b304609da617 --0015174c17a8ff09b304609da617 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Fri, Jan 16, 2009 at 10:18 AM, Paul Hoffman wrote: > At 10:10 AM -0800 1/16/09, Breno de Medeiros wrote: > >For asking, a lot of people do not have access to DNS, because the API > abstracts it away. See the list of examples above. You could add to that any > number of web APIs that export only HTTP interface (not a full network > stack). > > I thought Mark was talking about applications having access to the data, > not people, but I could have been mistaken. If it is applications, they do > not need to go through an API that might abstract away things like a DNS > RRtype. Applications that are to be deployed in environments where _there_is_no_API_ to get to the DNS layer (see examples above, there are many, many others) _have_to_do_without_DNS_ -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7) --0015174c17a8ff09b304609da617 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Jan 16, 2009 at 10:18 AM, Paul H= offman <phoffman@i= mc.org> wrote:
At 10:10 AM -0800 1/16/09, Breno de Medeiros wrote: >For asking, a lot of people do not have access to DNS, because the API = abstracts it away. See the list of examples above. You could add to that an= y number of web APIs that export only HTTP interface (not a full network st= ack).

I thought Mark was talking about applications having access to the da= ta, not people, but I could have been mistaken. If it is applications, they= do not need to go through an API that might abstract away things like a DN= S RRtype.

Applications that are to be deployed in environments where _there_= is_no_API_ to get to the DNS layer (see examples above, there are many, man= y others) _have_to_do_without_DNS_



--
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Gran= d Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)
--0015174c17a8ff09b304609da617-- --===============1201554514== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss --===============1201554514==-- From apps-discuss-bounces@ietf.org Fri Jan 16 10:31:47 2009 Return-Path: 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 3CB193A6A7F; Fri, 16 Jan 2009 10:31:47 -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 936C93A6A64 for ; Fri, 16 Jan 2009 10:31:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 DzPtk55iAzps for ; Fri, 16 Jan 2009 10:31:45 -0800 (PST) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.144]) by core3.amsl.com (Postfix) with ESMTP id 6394B3A6A98 for ; Fri, 16 Jan 2009 10:31:07 -0800 (PST) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e4.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n0GITO7U016415 for ; Fri, 16 Jan 2009 13:29:24 -0500 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id n0GIUpaL196780 for ; Fri, 16 Jan 2009 13:30:51 -0500 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n0GIU0gV024236 for ; Fri, 16 Jan 2009 13:30:00 -0500 Received: from poplar (poplar.watson.ibm.com [9.2.24.140]) by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n0GIU08H024228; Fri, 16 Jan 2009 13:30:00 -0500 Received: from Uranus-009002042072.watson.ibm.com ([9.2.42.72]) by poplar.watson.ibm.com (IMF.2005.07.16.1050.haw) with SMTP ID IMFd1232130649.54; Fri, 16 Jan 2009 13:30:49 -0400 Date: Fri, 16 Jan 2009 13:30:49 -0500 From: Barry Leiba To: Paul Hoffman Subject: Re: URIs, domains and authority Message-ID: In-Reply-To: References: <319C1C80-F0E8-41ED-8422-3FB303CBCA6F@mnot.net> <29fb00360901161010o4ff94b2cia4b1b7f1f74b4ff2@mail.gmail.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org > I thought Mark was talking about applications having access to the data, not > people, but I could have been mistaken. If it is applications, they do not need > to go through an API that might abstract away things like a DNS RRtype. Paul, I think the issue here is where applications are limited in which APIs they use. You and I, perhaps, can say, "Damn, I can't do what I want here; I'll go write this bit in C." Not everyone has that option, and not every development platform exposes what it thinks to be lower-level network interfaces. And, as I said in my other note, even on the publishing side there are real barriers to putting this stuff in DNS. It's often far, far easier (and less error prone) for a group that does web stuff to update a file on a web server than it is for that group to get someone else to make a change to the DNS info. Barry _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Fri Jan 16 11:18:18 2009 Return-Path: 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 8B9A33A69E3; Fri, 16 Jan 2009 11:18:18 -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 C90643A6903 for ; Fri, 16 Jan 2009 11:18:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 pVYM9TOYvC8r for ; Fri, 16 Jan 2009 11:18:17 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 8914A28C1AB for ; Fri, 16 Jan 2009 11:18:16 -0800 (PST) Received: from [10.20.30.158] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0GJHwAH038052 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Jan 2009 12:17:59 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <319C1C80-F0E8-41ED-8422-3FB303CBCA6F@mnot.net> <29fb00360901161010o4ff94b2cia4b1b7f1f74b4ff2@mail.gmail.com> Date: Fri, 16 Jan 2009 11:17:57 -0800 To: Barry Leiba From: Paul Hoffman Subject: Re: URIs, domains and authority Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org At 1:30 PM -0500 1/16/09, Barry Leiba wrote: >>I thought Mark was talking about applications having access to the data, not >>people, but I could have been mistaken. If it is applications, they do not need >>to go through an API that might abstract away things like a DNS RRtype. > >Paul, I think the issue here is where applications are limited in which APIs they use. You and I, perhaps, can say, "Damn, I can't do what I want here; I'll go write this bit in C." Not everyone has that option, and not every development platform exposes what it thinks to be lower-level network interfaces. OK. If an IAB member says "it's OK to push everything through port 80", I'll accept that. :-) >And, as I said in my other note, even on the publishing side there are real barriers to putting this stuff in DNS. It's often far, far easier (and less error prone) for a group that does web stuff to update a file on a web server than it is for that group to get someone else to make a change to the DNS info. Let me turn that around, however. If this is metadata and policy about a domain (not just about the web server), maybe the DNS group will have a hard time finding someone in the web server group to reliably put the data on a stable web page. Mark's question that started this tread was about expanding the content of the current draft beyond being about the web server serving the data. _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Fri Jan 16 11:26:28 2009 Return-Path: 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 402EA3A6874; Fri, 16 Jan 2009 11:26:28 -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 789203A6852 for ; Fri, 16 Jan 2009 11:26:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 ACaDUw5-4fdV for ; Fri, 16 Jan 2009 11:26:22 -0800 (PST) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.144]) by core3.amsl.com (Postfix) with ESMTP id 6CB363A67D1 for ; Fri, 16 Jan 2009 11:26:22 -0800 (PST) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e4.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n0GJOd2Z017850 for ; Fri, 16 Jan 2009 14:24:39 -0500 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id n0GJQ6cb185800 for ; Fri, 16 Jan 2009 14:26:06 -0500 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n0GJQ5A3019341 for ; Fri, 16 Jan 2009 14:26:05 -0500 Received: from poplar (poplar.watson.ibm.com [9.2.24.140]) by d01av04.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n0GJQ5oo019338; Fri, 16 Jan 2009 14:26:05 -0500 Received: from Uranus-009002042072.watson.ibm.com ([9.2.42.72]) by poplar.watson.ibm.com (IMF.2005.07.16.1050.haw) with SMTP ID IMFd1232133964.71; Fri, 16 Jan 2009 14:26:04 -0400 Date: Fri, 16 Jan 2009 14:26:04 -0500 From: Barry Leiba To: Paul Hoffman Subject: Re: URIs, domains and authority Message-ID: In-Reply-To: References: <319C1C80-F0E8-41ED-8422-3FB303CBCA6F@mnot.net> <29fb00360901161010o4ff94b2cia4b1b7f1f74b4ff2@mail.gmail.com> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org > OK. If an IAB member says "it's OK to push everything through port 80", > I'll accept that. :-) He-he-he. Well, I *am* up for renewal, and we never know what the NomCom will do. Seriously: No, I don't think everything should go through HTTP. But I do think it's reasonable to put possibly extensive policy and configuration information there... ...especially when it's related to web services. That said, I get your other point: as the concept is expanded beyond web services, it's more questionable. I still contend that in some environments -- at least in the company with which I'm most familiar -- putting information about policies for email, XMPP, FTP, and the like behind an HTTP server would be much easier, administratively, than putting it in DNS. It might well be quite the opposite elsewhere. But the other things I said in my first message apply: the subdomain scope MUST be clean, and the information for the different protocols MUST be kept separate. Else it will be a True Mess. Barry -- Barry Leiba, Senior Technical Staff (leiba@watson.ibm.com) Internet Messaging Technology, IBM Research http://www.research.ibm.com/people/l/leiba http://www.research.ibm.com/spam _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Fri Jan 16 15:06:40 2009 Return-Path: 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 A7E0B3A689D; Fri, 16 Jan 2009 15:06:40 -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 3345E3A6888 for ; Fri, 16 Jan 2009 15:06:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.996 X-Spam-Level: X-Spam-Status: No, score=-3.996 tagged_above=-999 required=5 tests=[AWL=-1.397, 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 IBvX4Ex6NRK0 for ; Fri, 16 Jan 2009 15:06:38 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id EAF923A6768 for ; Fri, 16 Jan 2009 15:06:37 -0800 (PST) Received: from [192.168.1.4] (unknown [121.44.206.3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id C3A34D05B1; Fri, 16 Jan 2009 18:06:19 -0500 (EST) Message-Id: <4ACC3625-3B92-466C-B56D-EF2EC25DF3BD@mnot.net> From: Mark Nottingham To: Breno de Medeiros In-Reply-To: <29fb00360901161022i1999e0e2u5a459a36c0bcaa4@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v930.3) Subject: hacking and standards [was: URIs, domains and authority] Date: Sat, 17 Jan 2009 10:06:16 +1100 References: <319C1C80-F0E8-41ED-8422-3FB303CBCA6F@mnot.net> <29fb00360901161010o4ff94b2cia4b1b7f1f74b4ff2@mail.gmail.com> <29fb00360901161022i1999e0e2u5a459a36c0bcaa4@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org And I think this is perhaps the crux of this and many other arguments ^H^H^H^H^H^H^H^H^H^Hdisagreements^H^H^H^H^H^H^H^H^H^H^H^H^Hdiscussions that are happening in the Web world now. A number of innovators (often with the "Web 2.0" label) have been hacking (in the "good" sense) on the Web and have got to the point where they need to mint some standards. Since they've been hacking, they've by necessity worked within the sometimes quite narrow limits of deployed Web software -- browsers, servers, hosting facilities, etc. I.e., they have and need "running code." So, it's not too surprising that they want to standardise things that work within those limits. Personally, I have a few reservations with doing so: 1) It effectively dumbs down the Web to preclude anything that can't be done with a free University account with FTP access. Yes, I have seen this argument made (not in this discussion yet). This is a sad, constricted and very worrisome vision of the future of the Web. 2) It rewards those vendors who choose not to implement full specifications, and to service providers who provide feature- restricted services. Again, not a good road to be on. 3) The solutions that this leads to are often very convoluted and specific to the state of the implementations when it was conceived, creating more complex standards that are harder to factor, implement, secure, use, and evolve. Evolving a product or service is relatively easy, compared to changing a standard. 4) It fails to recognise that, by pushing the limits in carefully managed ways, we can encourage broader, more standards-compliant implementations and deployments to be made. In particular, it seems very odd to me to hear this kind of argument, when looking at the list of names behind efforts like OAuth (not to pick on them particularly); by defining a specification that requires a particular feature and adopting it, THEY CHANGE THE MARKET and encourage implementation of that feature. Again personally, I think the right thing to do here is to find compromises between "working right now" and "sensible in the long term". site-meta (as I conceived it) was one such compromise; yes, a well-known URI isn't a particularly good thing, but it works, is easy to use, and they're already out there; if done well, site-meta can be the last one of those. However, making it authoritative for more than the site it's on crosses the line, to me. I'd suggest the line is that it makes sense to accommodate the realities of widespread implementation, but it don't make sense to try to assure that a particular standard can be used with every last, arbitrarily constructed hosting system in the world. Then, of course, someone will say "but what about [huge deployed hosted service X]?" What I find interesting here is that the same people are often representing the company that owns [huge deployed hosted service X]... Cheers, On 17/01/2009, at 5:22 AM, Breno de Medeiros wrote: > > > On Fri, Jan 16, 2009 at 10:18 AM, Paul Hoffman > wrote: > At 10:10 AM -0800 1/16/09, Breno de Medeiros wrote: > >For asking, a lot of people do not have access to DNS, because the > API abstracts it away. See the list of examples above. You could add > to that any number of web APIs that export only HTTP interface (not > a full network stack). > > I thought Mark was talking about applications having access to the > data, not people, but I could have been mistaken. If it is > applications, they do not need to go through an API that might > abstract away things like a DNS RRtype. > > Applications that are to be deployed in environments where > _there_is_no_API_ to get to the DNS layer (see examples above, there > are many, many others) _have_to_do_without_DNS_ > > > > -- > --Breno > > +1 (650) 214-1007 desk > +1 (408) 212-0135 (Grand Central) > MTV-41-3 : 383-A > PST (GMT-8) / PDT(GMT-7) -- Mark Nottingham http://www.mnot.net/ _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Fri Jan 16 15:29:23 2009 Return-Path: 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 898323A689D; Fri, 16 Jan 2009 15:29:23 -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 28F6A3A6768 for ; Fri, 16 Jan 2009 15:29:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.976 X-Spam-Level: X-Spam-Status: No, score=-101.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 BYSY1ij2t1dX for ; Fri, 16 Jan 2009 15:29:20 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 948E93A689D for ; Fri, 16 Jan 2009 15:29:19 -0800 (PST) Received: from wpaz17.hot.corp.google.com (wpaz17.hot.corp.google.com [172.24.198.81]) by smtp-out.google.com with ESMTP id n0GNT1Kn001168 for ; Fri, 16 Jan 2009 23:29:02 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1232148543; bh=koZnP7QEnmyKp6HFjYWsKHEXq00=; h=DomainKey-Signature:MIME-Version:In-Reply-To:References:Date: Message-ID:Subject:From:To:Cc:Content-Type:X-GMailtapped-By: X-GMailtapped; b=mwtprozI9G4O7yYK+hhTLeCBiA9hiWavV8BAf48AffiXXUfb/ leCBEIJFPlEpMufJBkwqil9g3mcXYVbQR3vHQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-gmailtapped-by:x-gmailtapped; b=TctM2XQiXujSwS0PHZZELKY4Khsb0Mfc8mV/1y7rj3bKcvjxk/K5GAbUyy8cpAyPs Z+246D+HjvprUfOmHaN5w== Received: from ewy9 (ewy9.prod.google.com [10.241.103.9]) by wpaz17.hot.corp.google.com with ESMTP id n0GNSvqj027138 for ; Fri, 16 Jan 2009 15:28:59 -0800 Received: by ewy9 with SMTP id 9so159691ewy.17 for ; Fri, 16 Jan 2009 15:28:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.210.117.1 with SMTP id p1mr3848867ebc.180.1232148536911; Fri, 16 Jan 2009 15:28:56 -0800 (PST) In-Reply-To: <4ACC3625-3B92-466C-B56D-EF2EC25DF3BD@mnot.net> References: <319C1C80-F0E8-41ED-8422-3FB303CBCA6F@mnot.net> <29fb00360901161010o4ff94b2cia4b1b7f1f74b4ff2@mail.gmail.com> <29fb00360901161022i1999e0e2u5a459a36c0bcaa4@mail.gmail.com> <4ACC3625-3B92-466C-B56D-EF2EC25DF3BD@mnot.net> Date: Fri, 16 Jan 2009 15:28:56 -0800 Message-ID: <29fb00360901161528l7a27f277g3d450171cf613f05@mail.gmail.com> Subject: Re: hacking and standards [was: URIs, domains and authority] From: Breno de Medeiros To: Mark Nottingham X-GMailtapped-By: 172.24.198.81 X-GMailtapped: breno Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1129581375==" Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org --===============1129581375== Content-Type: multipart/alternative; boundary=0015174bdfecda69600460a1efaa --0015174bdfecda69600460a1efaa Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Fri, Jan 16, 2009 at 3:06 PM, Mark Nottingham wrote: > And I think this is perhaps the crux of this and many other > arguments^H^H^H^H^H^H^H^H^H^Hdisagreements^H^H^H^H^H^H^H^H^H^H^H^H^Hdiscussions > that are happening in the Web world now. > > A number of innovators (often with the "Web 2.0" label) have been hacking > (in the "good" sense) on the Web and have got to the point where they need > to mint some standards. Since they've been hacking, they've by necessity > worked within the sometimes quite narrow limits of deployed Web software -- > browsers, servers, hosting facilities, etc. I.e., they have and need > "running code." > > So, it's not too surprising that they want to standardise things that work > within those limits. > > Personally, I have a few reservations with doing so: > > 1) It effectively dumbs down the Web to preclude anything that can't be > done with a free University account with FTP access. Yes, I have seen this > argument made (not in this discussion yet). This is a sad, constricted and > very worrisome vision of the future of the Web. > > 2) It rewards those vendors who choose not to implement full > specifications, and to service providers who provide feature-restricted > services. Again, not a good road to be on. > > 3) The solutions that this leads to are often very convoluted and specific > to the state of the implementations when it was conceived, creating more > complex standards that are harder to factor, implement, secure, use, and > evolve. Evolving a product or service is relatively easy, compared to > changing a standard. > > 4) It fails to recognise that, by pushing the limits in carefully managed > ways, we can encourage broader, more standards-compliant implementations and > deployments to be made. In particular, it seems very odd to me to hear this > kind of argument, when looking at the list of names behind efforts like > OAuth (not to pick on them particularly); by defining a specification that > requires a particular feature and adopting it, THEY CHANGE THE MARKET and > encourage implementation of that feature. > > Again personally, I think the right thing to do here is to find compromises > between "working right now" and "sensible in the long term". site-meta (as I > conceived it) was one such compromise; yes, a well-known URI isn't a > particularly good thing, but it works, is easy to use, and they're already > out there; if done well, site-meta can be the last one of those. However, > making it authoritative for more than the site it's on crosses the line, to > me. Nobody here is suggesting that this standard make it authoritative, just delegating the decision to applications. This is a sensible thing to do from a modularity standpoint, and it is bad when standards try to push decisions lower in the network layer than they have to be. For illustrative purposes, consider the SSL and IPSEC standards. The IPSEC standard provides much more comprehensive security properties, because it is defined at the network layer. However, its deployment is limited to VPN and other systems where there is a comprehensive managing authority for the network. It does not provide sufficient granularity and flexibility for deployment in open networks. On the other hand, SSL pushes security to the transport/application layers and is much more flexible, addressing many use cases which would be difficult or simply unwieldy to address using IPSEC. SSL is not better or worse than IPSEC. It has a different set of operational and deployment requirements in terms of security/flexibility. It is my view (and from what I have heard, of several others in the XRI committee) that the application environment where HRDD is going to be applied is much more akin to the SSL setting than the IPSEC setting, and that the flexibility to allow for applications that use this standard to make end-to-end decisions on trust/authority issues is essential *due to the nature of such applications* and not because of any current contingencies on existing APIs. On the contrary, such web APIs are what they are because they capture well the environment of the applications they need to support. > > I'd suggest the line is that it makes sense to accommodate the realities of > widespread implementation, but it don't make sense to try to assure that a > particular standard can be used with every last, arbitrarily constructed > hosting system in the world. > > Then, of course, someone will say "but what about [huge deployed hosted > service X]?" What I find interesting here is that the same people are often > representing the company that owns [huge deployed hosted service X]... Interesting that such hosting systems from fiercely competitive companies have converged on the same solution. Maybe it is because they believe in clean, useful APIs that capture the architecture of the application domain, instead of trying to solve problems that are out of scope (and should remain out of scope). > > > Cheers, > > > On 17/01/2009, at 5:22 AM, Breno de Medeiros wrote: > > >> >> On Fri, Jan 16, 2009 at 10:18 AM, Paul Hoffman wrote: >> At 10:10 AM -0800 1/16/09, Breno de Medeiros wrote: >> >For asking, a lot of people do not have access to DNS, because the API >> abstracts it away. See the list of examples above. You could add to that any >> number of web APIs that export only HTTP interface (not a full network >> stack). >> >> I thought Mark was talking about applications having access to the data, >> not people, but I could have been mistaken. If it is applications, they do >> not need to go through an API that might abstract away things like a DNS >> RRtype. >> >> Applications that are to be deployed in environments where >> _there_is_no_API_ to get to the DNS layer (see examples above, there are >> many, many others) _have_to_do_without_DNS_ >> >> >> >> -- >> --Breno >> >> +1 (650) 214-1007 desk >> +1 (408) 212-0135 (Grand Central) >> MTV-41-3 : 383-A >> PST (GMT-8) / PDT(GMT-7) >> > > > -- > Mark Nottingham http://www.mnot.net/ > > -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7) --0015174bdfecda69600460a1efaa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Jan 16, 2009 at 3:06 PM, Mark No= ttingham <mnot@mnot.n= et> wrote:
And I think this is perhaps the crux of this and many other arguments^H^H^H= ^H^H^H^H^H^H^Hdisagreements^H^H^H^H^H^H^H^H^H^H^H^H^Hdiscussions that are h= appening in the Web world now.

A number of innovators (often with the "Web 2.0" label) have been= hacking (in the "good" sense) on the Web and have got to the poi= nt where they need to mint some standards. Since they've been hacking, = they've by necessity worked within the sometimes quite narrow limits of= deployed Web software -- browsers, servers, hosting facilities, etc. I.e.,= they have and need "running code."

So, it's not too surprising that they want to standardise things that w= ork within those limits.

Personally, I have a few reservations with doing so:

1) It effectively dumbs down the Web to preclude anything that can't be= done with a free University account with FTP access. Yes, I have seen this= argument made (not in this discussion yet). This is a sad, constricted and= very worrisome vision of the future of the Web.

2) It rewards those vendors who choose not to implement full specifications= , and to service providers who provide feature-restricted services. Again, = not a good road to be on.

3) The solutions that this leads to are often very convoluted and specific = to the state of the implementations when it was conceived, creating more co= mplex standards that are harder to factor, implement, secure, use, and evol= ve. Evolving a product or service is relatively easy, compared to changing = a standard.

4) It fails to recognise that, by pushing the limits in carefully managed w= ays, we can encourage broader, more standards-compliant implementations and= deployments to be made. In particular, it seems very odd to me to hear thi= s kind of argument, when looking at the list of names behind efforts like O= Auth (not to pick on them particularly); by defining a specification that r= equires a particular feature and adopting it, THEY CHANGE THE MARKET and en= courage implementation of that feature.

Again personally, I think the right thing to do here is to find compromises= between "working right now" and "sensible in the long term&= quot;. site-meta (as I conceived it) was one such compromise; yes, a well-k= nown URI isn't a particularly good thing, but it works, is easy to use,= and they're already out there; if done well, site-meta can be the last= one of those. However, making it authoritative for more than the site it&#= 39;s on crosses the line, to me.


Nobody here is suggesting that this standard make it authorita= tive, just delegating the decision to applications. This is a sensible thin= g to do from a modularity standpoint, and it is bad when standards try to p= ush decisions lower in the network layer than they have to be.

For illustrative purposes, consider the SSL and IPSEC standards. The IP= SEC standard provides much more comprehensive security properties, because = it is defined at the network layer. However, its deployment is limited to V= PN and other systems where there is a comprehensive managing authority for = the network. It does not provide sufficient granularity and flexibility for= deployment in open networks. On the other hand, SSL pushes security to the= transport/application layers and is much more flexible, addressing many us= e cases which would be difficult or simply unwieldy to address using IPSEC.=

SSL is not better or worse than IPSEC. It has a different set of operat= ional and deployment requirements in terms of security/flexibility.
It is my view (and from what I have heard, of several others in the XRI co= mmittee) that the application environment where HRDD is going to be applied= is much more akin to the SSL setting than the IPSEC setting, and that the = flexibility to allow for applications that use this standard to make end-to= -end decisions on trust/authority issues is essential *due to the nature of= such applications* and not because of any current contingencies on existin= g APIs. On the contrary, such web APIs are what they are because they captu= re well the environment of the applications they need to support.



I'd suggest the line is that it makes sense to accommodate the realitie= s of widespread implementation, but it don't make sense to try to assur= e that a particular standard can be used with every last, arbitrarily const= ructed hosting system in the world.

Then, of course, someone will say "but what about [huge deployed hoste= d service X]?" What I find interesting here is that the same people ar= e often representing the company that owns [huge deployed hosted service X]= ...

Interesting that such hosting systems from fiercely competitive co= mpanies have converged on the same solution. Maybe it is because they belie= ve in clean, useful APIs that capture the architecture of the application d= omain, instead of trying to solve problems that are out of scope (and shoul= d remain out of scope).

 
<= br>
Cheers,


On 17/01/2009, at 5:22 AM, Breno de Medeiros wrote:



On Fri, Jan 16, 2009 at 10:18 AM, Paul Hoffman <phoffman@imc.org> wrote:
At 10:10 AM -0800 1/16/09, Breno de Medeiros wrote:
>For asking, a lot of people do not have access to DNS, because the API = abstracts it away. See the list of examples above. You could add to that an= y number of web APIs that export only HTTP interface (not a full network st= ack).

I thought Mark was talking about applications having access to the data, no= t people, but I could have been mistaken. If it is applications, they do no= t need to go through an API that might abstract away things like a DNS RRty= pe.

Applications that are to be deployed in environments where _there_is_no_API= _ to get to the DNS layer (see examples above, there are many, many others)= _have_to_do_without_DNS_



--
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)


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




--
--Breno

+1 (650)= 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7)
--0015174bdfecda69600460a1efaa-- --===============1129581375== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss --===============1129581375==-- From apps-discuss-bounces@ietf.org Fri Jan 16 15:39:10 2009 Return-Path: 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 08F953A694F; Fri, 16 Jan 2009 15:39:10 -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 323B43A694F for ; Fri, 16 Jan 2009 15:39:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.794 X-Spam-Level: X-Spam-Status: No, score=-4.794 tagged_above=-999 required=5 tests=[AWL=-2.195, 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 7emKYuoblmwM for ; Fri, 16 Jan 2009 15:39:08 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 467EA3A689D for ; Fri, 16 Jan 2009 15:39:08 -0800 (PST) Received: (qmail 1674 invoked from network); 16 Jan 2009 23:38:52 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 16 Jan 2009 23:38:52 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Fri, 16 Jan 2009 16:38:51 -0700 From: Eran Hammer-Lahav To: Mark Nottingham , Breno de Medeiros Date: Fri, 16 Jan 2009 16:38:51 -0700 Subject: Re: hacking and standards [was: URIs, domains and authority] Thread-Topic: hacking and standards [was: URIs, domains and authority] Thread-Index: Acl4Lwz8tJ26TQM9TBqW9LXzM+UOOQABIjkg Message-ID: In-Reply-To: <4ACC3625-3B92-466C-B56D-EF2EC25DF3BD@mnot.net> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org This is an interesting discussion but does not really help answering the scope question of Site-Meta. The spec must answer the question of what is the subject of the relationships described by the meta elements. It can also be defined in contrast to Link header by asking, how is a link in Site-Meta different from a Link header in the HTTP response to a GET request of the root resource (GET / HTTP/1.1). Site-Meta provides links between some "abstract web site" entity and metadata documents. This discussion is finding out an acceptable definition to this "abstract web site", and how it is different from what today the HTTP root resource of a domain is used for (i.e. http://yahoo.com/). The more detailed that definition is, the more restrictive the use of Site-Meta becomes. The problem with the way this discussion has been framed initially, is that it asks about authority across protocols. An HTTP application that collects information about people and their email addresses, should surely be allowed to use Site-Meta to publish their findings, and provide a way to map between the email address to the HTTP descriptor it produced? I think the key here isn't defining the "abstract web site" directly, but trying to define how it is different from the root resource and when each should be used. My use case is simple: I want Site-Meta to provide information about URIs, regardless of their scheme, via HTTP. What you do with this information should be out of scope. EHL On 1/16/09 3:06 PM, "Mark Nottingham" wrote: > And I think this is perhaps the crux of this and many other > arguments > ^H^H^H^H^H^H^H^H^H^Hdisagreements^H^H^H^H^H^H^H^H^H^H^H^H^Hdiscussions > that are happening in the Web world now. > > A number of innovators (often with the "Web 2.0" label) have been > hacking (in the "good" sense) on the Web and have got to the point > where they need to mint some standards. Since they've been hacking, > they've by necessity worked within the sometimes quite narrow limits > of deployed Web software -- browsers, servers, hosting facilities, > etc. I.e., they have and need "running code." > > So, it's not too surprising that they want to standardise things that > work within those limits. > This is less about the hacking part and more about trying to deploy a grand vision in a world that is not yet ready or accommodating it. This debate goes far beyond the technical details of standardizing limited environment. There is a significant culture clash between communities like the IETF and communities like OAuth. But this is completely off topic for the technical question I would like to see resolved here. > 4) It fails to recognise that, by pushing the limits in carefully > managed ways, we can encourage broader, more standards-compliant > implementations and deployments to be made. In particular, it seems > very odd to me to hear this kind of argument, when looking at the list > of names behind efforts like OAuth (not to pick on them particularly); > by defining a specification that requires a particular feature and > adopting it, THEY CHANGE THE MARKET and encourage implementation of > that feature. The "names" behind OAuth, if you look at actual leadership, contribution, and influence are all individuals with practically zero influence on web deployment and market structure. Yes, big companies join towards the end, but the core of the work, and the 'soul' of the project very completely anchored with the philosophy of maximizing accessibility and making sure it is compatible with as many limited framework as possible. And that was the most significant reason for its adoption. In fact, many people argue that it didn't go far enough in simplicity and that is still hurting adoption. EHL _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Fri Jan 16 15:41:30 2009 Return-Path: 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 2BFB03A696D; Fri, 16 Jan 2009 15:41:30 -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 7C6793A69C3 for ; Fri, 16 Jan 2009 15:41:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.715 X-Spam-Level: X-Spam-Status: No, score=-4.715 tagged_above=-999 required=5 tests=[AWL=-2.117, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 iX5kPL40dIn3 for ; Fri, 16 Jan 2009 15:41:27 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id EDDA83A696D for ; Fri, 16 Jan 2009 15:41:26 -0800 (PST) Received: (qmail 14922 invoked from network); 16 Jan 2009 23:41:10 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 16 Jan 2009 23:41:10 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Fri, 16 Jan 2009 16:41:10 -0700 From: Eran Hammer-Lahav To: Eran Hammer-Lahav , Mark Nottingham , Breno de Medeiros Date: Fri, 16 Jan 2009 16:41:08 -0700 Subject: Re: hacking and standards [was: URIs, domains and authority] Thread-Topic: hacking and standards [was: URIs, domains and authority] Thread-Index: Acl4Lwz8tJ26TQM9TBqW9LXzM+UOOQABIjkgAAAUalU= Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1050882197==" Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org --===============1050882197== Content-Language: en Content-Type: multipart/alternative; boundary="_000_C5965B1411017eranhueniversecom_" --_000_C5965B1411017eranhueniversecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I included both a reply at the top and inline... Sorry for the confusion. EHL On 1/16/09 3:38 PM, "Eran Hammer-Lahav" wrote: This is an interesting discussion but does not really help answering the scope question of Site-Meta. The spec must answer the question of what is the subject of the relationships described by the meta elements. It can als= o be defined in contrast to Link header by asking, how is a link in Site-Meta different from a Link header in the HTTP response to a GET request of the root resource (GET / HTTP/1.1). Site-Meta provides links between some "abstract web site" entity and metadata documents. This discussion is finding out an acceptable definition to this "abstract web site", and how it is different from what today the HTTP root resource of a domain is used for (i.e. http://yahoo.com/). The more detailed that definition is, the more restrictive the use of Site-Meta becomes. The problem with the way this discussion has been framed initially, is that it asks about authority across protocols. An HTTP application that collects information about people and their email addresses, should surely be allowed to use Site-Meta to publish their findings, and provide a way to map between the email address to the HTTP descriptor it produced? I think the key here isn't defining the "abstract web site" directly, but trying to define how it is different from the root resource and when each should be used. My use case is simple: I want Site-Meta to provide information about URIs, regardless of their scheme, via HTTP. What you do with this information should be out of scope. EHL On 1/16/09 3:06 PM, "Mark Nottingham" wrote: > And I think this is perhaps the crux of this and many other > arguments > ^H^H^H^H^H^H^H^H^H^Hdisagreements^H^H^H^H^H^H^H^H^H^H^H^H^Hdiscussions > that are happening in the Web world now. > > A number of innovators (often with the "Web 2.0" label) have been > hacking (in the "good" sense) on the Web and have got to the point > where they need to mint some standards. Since they've been hacking, > they've by necessity worked within the sometimes quite narrow limits > of deployed Web software -- browsers, servers, hosting facilities, > etc. I.e., they have and need "running code." > > So, it's not too surprising that they want to standardise things that > work within those limits. > This is less about the hacking part and more about trying to deploy a grand vision in a world that is not yet ready or accommodating it. This debate goes far beyond the technical details of standardizing limited environment. There is a significant culture clash between communities like the IETF and communities like OAuth. But this is completely off topic for the technical question I would like to see resolved here. > 4) It fails to recognise that, by pushing the limits in carefully > managed ways, we can encourage broader, more standards-compliant > implementations and deployments to be made. In particular, it seems > very odd to me to hear this kind of argument, when looking at the list > of names behind efforts like OAuth (not to pick on them particularly); > by defining a specification that requires a particular feature and > adopting it, THEY CHANGE THE MARKET and encourage implementation of > that feature. The "names" behind OAuth, if you look at actual leadership, contribution, and influence are all individuals with practically zero influence on web deployment and market structure. Yes, big companies join towards the end, but the core of the work, and the 'soul' of the project very completely anchored with the philosophy of maximizing accessibility and making sure it is compatible with as many limited framework as possible. And that was the most significant reason for its adoption. In fact, many people argue that it didn't go far enough in simplicity and that is still hurting adoption. EHL _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss --_000_C5965B1411017eranhueniversecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: hacking and standards [was: URIs, domains and authority] I included both a reply at the top and inline... Sorry for the confus= ion.

EHL


On 1/16/09 3:38 PM, "Eran Hammer-Lahav" <eran@hueniverse.com> wrote:

This is an interesting discussion but does = not really help answering the
scope question of Site-Meta. The spec must answer the question of what is the subject of the relationships described by the meta elements. It can als= o
be defined in contrast to Link header by asking, how is a link in Site-Meta=
different from a Link header in the HTTP response to a GET request of the root resource (GET / HTTP/1.1).

Site-Meta provides links between some "abstract web site" entity = and
metadata documents. This discussion is finding out an acceptable definition=
to this "abstract web site", and how it is different from what to= day the
HTTP root resource of a domain is used for (i.e. http://yahoo.com/).

The more detailed that definition is, the more restrictive the use of
Site-Meta becomes. The problem with the way this discussion has been framed=
initially, is that it asks about authority across protocols. An HTTP
application that collects information about people and their email
addresses, should surely be allowed to use Site-Meta to publish their
findings, and provide a way to map between the email address to the HTTP descriptor it produced?

I think the key here isn't defining the "abstract web site" direc= tly, but
trying to define how it is different from the root resource and when each should be used.

My use case is simple: I want Site-Meta to provide information about URIs,<= BR> regardless of their scheme, via HTTP. What you do with this information
should be out of scope.

EHL


On 1/16/09 3:06 PM, "Mark Nottingham" <mnot@mnot.net> wrote:

> And I think this is perhaps the crux of this and many other
> arguments
> ^H^H^H^H^H^H^H^H^H^Hdisagreements^H^H^H^H^H^H^H^H^H^H^H^H^Hdiscussions=
> that are happening in the Web world now.
>
> A number of innovators (often with the "Web 2.0" label) have= been
> hacking (in the "good" sense) on the Web and have got to the= point
> where they need to mint some standards. Since they've been hacking, > they've by necessity worked within the sometimes quite narrow limits > of deployed Web software -- browsers, servers, hosting facilities,
> etc. I.e., they have and need "running code."
>
> So, it's not too surprising that they want to standardise things that<= BR> > work within those limits.
>

This is less about the hacking part and more about trying to deploy a grand=
vision in a world that is not yet ready or accommodating it. This debate goes far beyond the technical details of standardizing limited environment.=
There is a significant culture clash between communities like the IETF and<= BR> communities like OAuth. But this is completely off topic for the technical<= BR> question I would like to see resolved here.

> 4) It fails to recognise that, by pushing the limits in carefully
> managed ways, we can encourage broader, more standards-compliant
> implementations and deployments to be made. In particular, it seems > very odd to me to hear this kind of argument, when looking at the list=
> of names behind efforts like OAuth (not to pick on them particularly);=
> by defining a specification that requires a particular feature and
> adopting it, THEY CHANGE THE MARKET and encourage implementation of > that feature.

The "names" behind OAuth, if you look at actual leadership, contr= ibution,
and influence are all individuals with practically zero influence on web deployment and market structure. Yes, big companies join towards the end, but the core of the work, and the 'soul' of the project very completely
anchored with the philosophy of maximizing accessibility and making sure it=
is compatible with as many limited framework as possible.

And that was the most significant reason for its adoption. In fact, many people argue that it didn't go far enough in simplicity and that is still hurting adoption.

EHL

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

--_000_C5965B1411017eranhueniversecom_-- --===============1050882197== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss --===============1050882197==-- From apps-discuss-bounces@ietf.org Fri Jan 16 15:52:53 2009 Return-Path: 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 0A94B3A694F; Fri, 16 Jan 2009 15:52:53 -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 1C81D3A694F for ; Fri, 16 Jan 2009 15:52:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.53 X-Spam-Level: X-Spam-Status: No, score=-3.53 tagged_above=-999 required=5 tests=[AWL=-0.931, 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 TAKt-J2DO0Vv for ; Fri, 16 Jan 2009 15:52:51 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id E84673A6768 for ; Fri, 16 Jan 2009 15:52:50 -0800 (PST) Received: from [192.168.1.4] (unknown [121.44.206.3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 26DA6D05A2; Fri, 16 Jan 2009 18:52:30 -0500 (EST) Message-Id: <7E9077DA-0BB8-43E9-925D-B890F5BCD052@mnot.net> From: Mark Nottingham To: Breno de Medeiros In-Reply-To: <29fb00360901161528l7a27f277g3d450171cf613f05@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: hacking and standards [was: URIs, domains and authority] Date: Sat, 17 Jan 2009 10:52:28 +1100 References: <319C1C80-F0E8-41ED-8422-3FB303CBCA6F@mnot.net> <29fb00360901161010o4ff94b2cia4b1b7f1f74b4ff2@mail.gmail.com> <29fb00360901161022i1999e0e2u5a459a36c0bcaa4@mail.gmail.com> <4ACC3625-3B92-466C-B56D-EF2EC25DF3BD@mnot.net> <29fb00360901161528l7a27f277g3d450171cf613f05@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 On 17/01/2009, at 10:28 AM, Breno de Medeiros wrote: > Nobody here is suggesting that this standard make it authoritative, = > just delegating the decision to applications. This is a sensible = > thing to do from a modularity standpoint, and it is bad when = > standards try to push decisions lower in the network layer than they = > have to be. Possibly. I'd be OK with defining the scope of site-meta to be the = site it's on by default, whilst leaving the door open for others to = use it beyond that scope on a per-application basis (with appropriate = warnings). Does that work for you, and does it work for others? > Then, of course, someone will say "but what about [huge deployed = > hosted service X]?" What I find interesting here is that the same = > people are often representing the company that owns [huge deployed = > hosted service X]... > > Interesting that such hosting systems from fiercely competitive = > companies have converged on the same solution. Maybe it is because = > they believe in clean, useful APIs that capture the architecture of = > the application domain, instead of trying to solve problems that are = > out of scope (and should remain out of scope). Touch=E9 :) However, often they're less than "clean, useful APIs that capture the = architecture of the application domain" and more like whatever can get = out the door fastest. That's not a criticism of any one company, BTW, = but more of a comment on the state of innovation in Silicon Valley. = It's fast and furious and about capturing mind-share, but a lot of it = is throwing things at the wall and seeing what sticks. It's not about = building infrastructure that's going to stand the test of time and be = a good internet citizen. Cheers, -- Mark Nottingham http://www.mnot.net/ _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Fri Jan 16 15:57:35 2009 Return-Path: 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 CF34828C0DC; Fri, 16 Jan 2009 15:57:35 -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 A05CA3A6A22 for ; Fri, 16 Jan 2009 15:57:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.976 X-Spam-Level: X-Spam-Status: No, score=-101.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 MfHpN2VDCPMs for ; Fri, 16 Jan 2009 15:57:33 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 705703A6768 for ; Fri, 16 Jan 2009 15:57:33 -0800 (PST) Received: from zps75.corp.google.com (zps75.corp.google.com [172.25.146.75]) by smtp-out.google.com with ESMTP id n0GNvFR3017966 for ; Fri, 16 Jan 2009 23:57:15 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1232150236; bh=ToBs24vVwJ1zFg1b/9vryjBFoQk=; h=DomainKey-Signature:MIME-Version:In-Reply-To:References:Date: Message-ID:Subject:From:To:Cc:Content-Type:X-GMailtapped-By: X-GMailtapped; b=DXZR2IB/oaUEFF1CuQQGWi+6DgWtfYo8OnC1vqEdX1w/+hfIR G/Im9eWs1cPTkI5be9lQnwWEbYWIFtXHXiGRw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-gmailtapped-by:x-gmailtapped; b=M7OnbMG1XuuHdTJeSy9yRLzKR7pxlxb5Km23Zp453oeyyPQ2gT77Atm+UmRFlN+H/ 2jpnSwLN34VpfcR2NRHpQ== Received: from fg-out-1718.google.com (fgg19.prod.google.com [10.86.7.19]) by zps75.corp.google.com with ESMTP id n0GNvBa8015115 for ; Fri, 16 Jan 2009 15:57:12 -0800 Received: by fg-out-1718.google.com with SMTP id 19so1084090fgg.16 for ; Fri, 16 Jan 2009 15:57:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.178.17 with SMTP id f17mr1484274mup.45.1232150231626; Fri, 16 Jan 2009 15:57:11 -0800 (PST) In-Reply-To: <7E9077DA-0BB8-43E9-925D-B890F5BCD052@mnot.net> References: <319C1C80-F0E8-41ED-8422-3FB303CBCA6F@mnot.net> <29fb00360901161010o4ff94b2cia4b1b7f1f74b4ff2@mail.gmail.com> <29fb00360901161022i1999e0e2u5a459a36c0bcaa4@mail.gmail.com> <4ACC3625-3B92-466C-B56D-EF2EC25DF3BD@mnot.net> <29fb00360901161528l7a27f277g3d450171cf613f05@mail.gmail.com> <7E9077DA-0BB8-43E9-925D-B890F5BCD052@mnot.net> Date: Fri, 16 Jan 2009 15:57:11 -0800 Message-ID: <29fb00360901161557q5dd9d837ycbb82d2e4ac181dc@mail.gmail.com> Subject: Re: hacking and standards [was: URIs, domains and authority] From: Breno de Medeiros To: Mark Nottingham X-GMailtapped-By: 172.25.146.75 X-GMailtapped: breno Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1098715632==" Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org --===============1098715632== Content-Type: multipart/alternative; boundary=001636426515ddb6a50460a254dc --001636426515ddb6a50460a254dc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Fri, Jan 16, 2009 at 3:52 PM, Mark Nottingham wrote: > > On 17/01/2009, at 10:28 AM, Breno de Medeiros wrote: > >> Nobody here is suggesting that this standard make it authoritative, just >> delegating the decision to applications. This is a sensible thing to do from >> a modularity standpoint, and it is bad when standards try to push decisions >> lower in the network layer than they have to be. >> > > Possibly. I'd be OK with defining the scope of site-meta to be the site > it's on by default, whilst leaving the door open for others to use it beyond > that scope on a per-application basis (with appropriate warnings). Does that > work for you, and does it work for others? > I understand that is what the spec currently does, i.e., delegates authority question to the applications. Does it not? > > > Cheers, > > > -- > Mark Nottingham http://www.mnot.net/ > > -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7) --001636426515ddb6a50460a254dc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Jan 16, 2009 at 3:52 PM, Mark No= ttingham <mnot@mnot.n= et> wrote:

On 17/01/2009, at 10:28 AM, Breno de Medeiros wrote:
Nobody here is suggesting that this standard make it authoritative, just de= legating the decision to applications. This is a sensible thing to do from = a modularity standpoint, and it is bad when standards try to push decisions= lower in the network layer than they have to be.

Possibly. I'd be OK with defining the scope of site-meta to be the site= it's on by default, whilst leaving the door open for others to use it = beyond that scope on a per-application basis (with appropriate warnings). D= oes that work for you, and does it work for others?

I understand that is what the spec currently do= es, i.e., delegates authority question to the applications. Does it not? 


Cheers,


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




--
--Breno
=
+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3= : 383-A
PST (GMT-8) / PDT(GMT-7)
--001636426515ddb6a50460a254dc-- --===============1098715632== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss --===============1098715632==-- From apps-discuss-bounces@ietf.org Fri Jan 16 16:05:42 2009 Return-Path: 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 429F43A696D; Fri, 16 Jan 2009 16:05:42 -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 52CC13A6768 for ; Fri, 16 Jan 2009 16:05:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.297 X-Spam-Level: X-Spam-Status: No, score=-3.297 tagged_above=-999 required=5 tests=[AWL=-0.698, 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 jefgScMuH58p for ; Fri, 16 Jan 2009 16:05:40 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id 85BF13A696D for ; Fri, 16 Jan 2009 16:05:40 -0800 (PST) Received: from [192.168.1.4] (unknown [121.44.206.3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id E9453D05BA; Fri, 16 Jan 2009 19:05:22 -0500 (EST) Message-Id: From: Mark Nottingham To: Breno de Medeiros In-Reply-To: <29fb00360901161557q5dd9d837ycbb82d2e4ac181dc@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: hacking and standards [was: URIs, domains and authority] Date: Sat, 17 Jan 2009 11:05:19 +1100 References: <319C1C80-F0E8-41ED-8422-3FB303CBCA6F@mnot.net> <29fb00360901161010o4ff94b2cia4b1b7f1f74b4ff2@mail.gmail.com> <29fb00360901161022i1999e0e2u5a459a36c0bcaa4@mail.gmail.com> <4ACC3625-3B92-466C-B56D-EF2EC25DF3BD@mnot.net> <29fb00360901161528l7a27f277g3d450171cf613f05@mail.gmail.com> <7E9077DA-0BB8-43E9-925D-B890F5BCD052@mnot.net> <29fb00360901161557q5dd9d837ycbb82d2e4ac181dc@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org The scope isn't well-defined in the current spec. On 17/01/2009, at 10:57 AM, Breno de Medeiros wrote: > > > On Fri, Jan 16, 2009 at 3:52 PM, Mark Nottingham > wrote: > > On 17/01/2009, at 10:28 AM, Breno de Medeiros wrote: > Nobody here is suggesting that this standard make it authoritative, > just delegating the decision to applications. This is a sensible > thing to do from a modularity standpoint, and it is bad when > standards try to push decisions lower in the network layer than they > have to be. > > Possibly. I'd be OK with defining the scope of site-meta to be the > site it's on by default, whilst leaving the door open for others to > use it beyond that scope on a per-application basis (with > appropriate warnings). Does that work for you, and does it work for > others? > > I understand that is what the spec currently does, i.e., delegates > authority question to the applications. Does it not? > > > > Cheers, > > > -- > Mark Nottingham http://www.mnot.net/ > > > > > -- > --Breno > > +1 (650) 214-1007 desk > +1 (408) 212-0135 (Grand Central) > MTV-41-3 : 383-A > PST (GMT-8) / PDT(GMT-7) -- Mark Nottingham http://www.mnot.net/ _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Fri Jan 16 16:07:17 2009 Return-Path: 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 690823A696D; Fri, 16 Jan 2009 16:07:17 -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 2E2EC3A696D for ; Fri, 16 Jan 2009 16:07:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.976 X-Spam-Level: X-Spam-Status: No, score=-101.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 k1o3eplRlqI3 for ; Fri, 16 Jan 2009 16:07:15 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id C8FF83A6768 for ; Fri, 16 Jan 2009 16:07:14 -0800 (PST) Received: from spaceape8.eur.corp.google.com (spaceape8.eur.corp.google.com [172.28.16.142]) by smtp-out.google.com with ESMTP id n0H06wpC019779 for ; Sat, 17 Jan 2009 00:06:58 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1232150818; bh=MdObEQ/4X8aYYxL4kIYNdyXN1+k=; h=DomainKey-Signature:MIME-Version:In-Reply-To:References:Date: Message-ID:Subject:From:To:Cc:Content-Type:X-GMailtapped-By: X-GMailtapped; b=JpRDqcgFVX0mzsb+Xp6JoqWyZ9ZTGfEJa6paS0BLsxTKOc+ci Cy1KesP9K2XqEFXoW2HJOwmIVGV69BL50Vovg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-gmailtapped-by:x-gmailtapped; b=uLjjhgVGOLEnz63ClYdJU0P55aevEiqFP+cSpM9ipTwuPn6IdoX0q6mKmvav/wn7f bVX2CCowT4YfcpnMHCwhQ== Received: from fg-out-1718.google.com (fge13.prod.google.com [10.86.5.13]) by spaceape8.eur.corp.google.com with ESMTP id n0H06swX025626 for ; Fri, 16 Jan 2009 16:06:55 -0800 Received: by fg-out-1718.google.com with SMTP id 13so885485fge.41 for ; Fri, 16 Jan 2009 16:06:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.92.10 with SMTP id u10mr1486940mul.22.1232150814453; Fri, 16 Jan 2009 16:06:54 -0800 (PST) In-Reply-To: References: <319C1C80-F0E8-41ED-8422-3FB303CBCA6F@mnot.net> <29fb00360901161010o4ff94b2cia4b1b7f1f74b4ff2@mail.gmail.com> <29fb00360901161022i1999e0e2u5a459a36c0bcaa4@mail.gmail.com> <4ACC3625-3B92-466C-B56D-EF2EC25DF3BD@mnot.net> <29fb00360901161528l7a27f277g3d450171cf613f05@mail.gmail.com> <7E9077DA-0BB8-43E9-925D-B890F5BCD052@mnot.net> <29fb00360901161557q5dd9d837ycbb82d2e4ac181dc@mail.gmail.com> Date: Fri, 16 Jan 2009 16:06:54 -0800 Message-ID: <29fb00360901161606h913c947lf169f06cc5eed46f@mail.gmail.com> Subject: Re: hacking and standards [was: URIs, domains and authority] From: Breno de Medeiros To: Mark Nottingham X-GMailtapped-By: 172.28.16.142 X-GMailtapped: breno Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2068654008==" Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org --===============2068654008== Content-Type: multipart/alternative; boundary=0016e6dd966f9af2c20460a27749 --0016e6dd966f9af2c20460a27749 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Eran's earlier response clarifies what it is the intended scope for the spec. On Fri, Jan 16, 2009 at 4:05 PM, Mark Nottingham wrote: > The scope isn't well-defined in the current spec. > > > > On 17/01/2009, at 10:57 AM, Breno de Medeiros wrote: > > >> >> On Fri, Jan 16, 2009 at 3:52 PM, Mark Nottingham wrote: >> >> On 17/01/2009, at 10:28 AM, Breno de Medeiros wrote: >> Nobody here is suggesting that this standard make it authoritative, just >> delegating the decision to applications. This is a sensible thing to do from >> a modularity standpoint, and it is bad when standards try to push decisions >> lower in the network layer than they have to be. >> >> Possibly. I'd be OK with defining the scope of site-meta to be the site >> it's on by default, whilst leaving the door open for others to use it beyond >> that scope on a per-application basis (with appropriate warnings). Does that >> work for you, and does it work for others? >> >> I understand that is what the spec currently does, i.e., delegates >> authority question to the applications. Does it not? >> >> >> >> Cheers, >> >> >> -- >> Mark Nottingham http://www.mnot.net/ >> >> >> >> >> -- >> --Breno >> >> +1 (650) 214-1007 desk >> +1 (408) 212-0135 (Grand Central) >> MTV-41-3 : 383-A >> PST (GMT-8) / PDT(GMT-7) >> > > > -- > Mark Nottingham http://www.mnot.net/ > > -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7) --0016e6dd966f9af2c20460a27749 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Eran's earlier response clarifies what it is the intended scope for the= spec.

On Fri, Jan 16, 2009 at 4:05 PM, M= ark Nottingham <mnot@= mnot.net> wrote:
The scope isn'= ;t well-defined in the current spec.
<= br>

On 17/01/2009, at 10:57 AM, Breno de Medeiros wrote:



On Fri, Jan 16, 2009 at 3:52 PM, Mark Nottingham <mnot@mnot.net> wrote:

On 17/01/2009, at 10:28 AM, Breno de Medeiros wrote:
Nobody here is suggesting that this standard make it authoritative, just de= legating the decision to applications. This is a sensible thing to do from = a modularity standpoint, and it is bad when standards try to push decisions= lower in the network layer than they have to be.

Possibly. I'd be OK with defining the scope of site-meta to be the site= it's on by default, whilst leaving the door open for others to use it = beyond that scope on a per-application basis (with appropriate warnings). D= oes that work for you, and does it work for others?

I understand that is what the spec currently does, i.e., delegates authorit= y question to the applications. Does it not?



Cheers,


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




--
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)


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




--
--Breno
=
+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3= : 383-A
PST (GMT-8) / PDT(GMT-7)
--0016e6dd966f9af2c20460a27749-- --===============2068654008== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss --===============2068654008==-- From apps-discuss-bounces@ietf.org Fri Jan 16 16:08:40 2009 Return-Path: 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 8F8993A6A24; Fri, 16 Jan 2009 16:08:40 -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 B461D3A696D for ; Fri, 16 Jan 2009 16:08:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.976 X-Spam-Level: X-Spam-Status: No, score=-101.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 FmXtX3RgP2Iq for ; Fri, 16 Jan 2009 16:08:38 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 6DAEC3A6768 for ; Fri, 16 Jan 2009 16:08:38 -0800 (PST) Received: from wpaz9.hot.corp.google.com (wpaz9.hot.corp.google.com [172.24.198.73]) by smtp-out.google.com with ESMTP id n0H08LbI023270 for ; Sat, 17 Jan 2009 00:08:21 GMT DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1232150901; bh=vJSi48a3dgVBLSVz8DzeLyOteA0=; h=DomainKey-Signature:MIME-Version:In-Reply-To:References:Date: Message-ID:Subject:From:To:Cc:Content-Type:X-GMailtapped-By: X-GMailtapped; b=NqjLltVQlNbCZfIgCFU1/s8VvnSE+uvAXqmnenwpksuY4z6Va 7yvOcPGX0AKDlVhsZV54HGYS19pM/PD0Q3XRg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-gmailtapped-by:x-gmailtapped; b=VqDmNxPlODRAIWHIXEfgTNhUdVdK/nG9pqXyjxjCLiwWL18qioKsG9EgTvsxuWQAF I3IAy47wMpGsO9ieQY7hA== Received: from bwz13 (bwz13.prod.google.com [10.188.26.13]) by wpaz9.hot.corp.google.com with ESMTP id n0H08HQB013105 for ; Fri, 16 Jan 2009 16:08:18 -0800 Received: by bwz13 with SMTP id 13so6458331bwz.19 for ; Fri, 16 Jan 2009 16:08:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.102.17 with SMTP id e17mr1465679mum.119.1232150897256; Fri, 16 Jan 2009 16:08:17 -0800 (PST) In-Reply-To: <29fb00360901161606h913c947lf169f06cc5eed46f@mail.gmail.com> References: <319C1C80-F0E8-41ED-8422-3FB303CBCA6F@mnot.net> <29fb00360901161010o4ff94b2cia4b1b7f1f74b4ff2@mail.gmail.com> <29fb00360901161022i1999e0e2u5a459a36c0bcaa4@mail.gmail.com> <4ACC3625-3B92-466C-B56D-EF2EC25DF3BD@mnot.net> <29fb00360901161528l7a27f277g3d450171cf613f05@mail.gmail.com> <7E9077DA-0BB8-43E9-925D-B890F5BCD052@mnot.net> <29fb00360901161557q5dd9d837ycbb82d2e4ac181dc@mail.gmail.com> <29fb00360901161606h913c947lf169f06cc5eed46f@mail.gmail.com> Date: Fri, 16 Jan 2009 16:08:17 -0800 Message-ID: <29fb00360901161608w2f3f9fe4qacfe576ef1586c23@mail.gmail.com> Subject: Re: hacking and standards [was: URIs, domains and authority] From: Breno de Medeiros To: Mark Nottingham X-GMailtapped-By: 172.24.198.73 X-GMailtapped: breno Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2057692312==" Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org --===============2057692312== Content-Type: multipart/alternative; boundary=0016363ba6608a68090460a27c7f --0016363ba6608a68090460a27c7f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I should have added the sense. Therefore if that intended scope gets expressed in the spec with potentially more clear language, then are your concerns addressed? On Fri, Jan 16, 2009 at 4:06 PM, Breno de Medeiros wrote: > Eran's earlier response clarifies what it is the intended scope for the > spec. > > > On Fri, Jan 16, 2009 at 4:05 PM, Mark Nottingham wrote: > >> The scope isn't well-defined in the current spec. >> >> >> >> On 17/01/2009, at 10:57 AM, Breno de Medeiros wrote: >> >> >>> >>> On Fri, Jan 16, 2009 at 3:52 PM, Mark Nottingham wrote: >>> >>> On 17/01/2009, at 10:28 AM, Breno de Medeiros wrote: >>> Nobody here is suggesting that this standard make it authoritative, just >>> delegating the decision to applications. This is a sensible thing to do from >>> a modularity standpoint, and it is bad when standards try to push decisions >>> lower in the network layer than they have to be. >>> >>> Possibly. I'd be OK with defining the scope of site-meta to be the site >>> it's on by default, whilst leaving the door open for others to use it beyond >>> that scope on a per-application basis (with appropriate warnings). Does that >>> work for you, and does it work for others? >>> >>> I understand that is what the spec currently does, i.e., delegates >>> authority question to the applications. Does it not? >>> >>> >>> >>> Cheers, >>> >>> >>> -- >>> Mark Nottingham http://www.mnot.net/ >>> >>> >>> >>> >>> -- >>> --Breno >>> >>> +1 (650) 214-1007 desk >>> +1 (408) 212-0135 (Grand Central) >>> MTV-41-3 : 383-A >>> PST (GMT-8) / PDT(GMT-7) >>> >> >> >> -- >> Mark Nottingham http://www.mnot.net/ >> >> > > > -- > --Breno > > +1 (650) 214-1007 desk > +1 (408) 212-0135 (Grand Central) > MTV-41-3 : 383-A > PST (GMT-8) / PDT(GMT-7) > -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7) --0016363ba6608a68090460a27c7f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I should have added the sense. Therefore if that intended scope gets expres= sed in the spec with potentially more clear language, then are your concern= s addressed?

On Fri, Jan 16, 2009 at 4:06= PM, Breno de Medeiros <breno@google.com> wrote:
Eran's earlie= r response clarifies what it is the intended scope for the spec.
<= /div>


On Fri, Jan 16, 20= 09 at 4:05 PM, Mark Nottingham <mnot@mnot.net> wrote:
The scope isn'= ;t well-defined in the current spec.



On 17/01/2009, at 10:57 AM, Breno de Medeiros wrote:



On Fri, Jan 16, 2009 at 3:52 PM, Mark Nottingham <mnot@mnot.net> wrote:

On 17/01/2009, at 10:28 AM, Breno de Medeiros wrote:
Nobody here is suggesting that this standard make it authoritative, just de= legating the decision to applications. This is a sensible thing to do from = a modularity standpoint, and it is bad when standards try to push decisions= lower in the network layer than they have to be.

Possibly. I'd be OK with defining the scope of site-meta to be the site= it's on by default, whilst leaving the door open for others to use it = beyond that scope on a per-application basis (with appropriate warnings). D= oes that work for you, and does it work for others?

I understand that is what the spec currently does, i.e., delegates authorit= y question to the applications. Does it not?



Cheers,


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




--
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)


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




--
--Breno
=
+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3= : 383-A
PST (GMT-8) / PDT(GMT-7)



--
--Breno
=
+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3= : 383-A
PST (GMT-8) / PDT(GMT-7)
--0016363ba6608a68090460a27c7f-- --===============2057692312== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss --===============2057692312==-- From apps-discuss-bounces@ietf.org Fri Jan 16 16:24:46 2009 Return-Path: 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 6B99E3A6A55; Fri, 16 Jan 2009 16:24:46 -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 421903A6A55 for ; Fri, 16 Jan 2009 16:24:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.158 X-Spam-Level: X-Spam-Status: No, score=-3.158 tagged_above=-999 required=5 tests=[AWL=-0.559, 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 tz+uyFROZ+sr for ; Fri, 16 Jan 2009 16:24:45 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id 53E823A6A41 for ; Fri, 16 Jan 2009 16:24:45 -0800 (PST) Received: from [192.168.1.4] (unknown [121.44.206.3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id AE64DD0A2D; Fri, 16 Jan 2009 19:24:27 -0500 (EST) Message-Id: <61A407D0-29E5-4778-B292-8BBD5EB8286B@mnot.net> From: Mark Nottingham To: Breno de Medeiros In-Reply-To: <29fb00360901161608w2f3f9fe4qacfe576ef1586c23@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: hacking and standards [was: URIs, domains and authority] Date: Sat, 17 Jan 2009 11:24:24 +1100 References: <319C1C80-F0E8-41ED-8422-3FB303CBCA6F@mnot.net> <29fb00360901161010o4ff94b2cia4b1b7f1f74b4ff2@mail.gmail.com> <29fb00360901161022i1999e0e2u5a459a36c0bcaa4@mail.gmail.com> <4ACC3625-3B92-466C-B56D-EF2EC25DF3BD@mnot.net> <29fb00360901161528l7a27f277g3d450171cf613f05@mail.gmail.com> <7E9077DA-0BB8-43E9-925D-B890F5BCD052@mnot.net> <29fb00360901161557q5dd9d837ycbb82d2e4ac181dc@mail.gmail.com> <29fb00360901161606h913c947lf169f06cc5eed46f@mail.gmail.com> <29fb00360901161608w2f3f9fe4qacfe576ef1586c23@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org Clarification: when I say "the spec" I mean site-meta, not Eran's other spec. As I said, I'm OK with it. The reason we're having the discussion here is as a sanity check to see what others think... Cheers, On 17/01/2009, at 11:08 AM, Breno de Medeiros wrote: > I should have added the sense. Therefore if that intended scope gets > expressed in the spec with potentially more clear language, then are > your concerns addressed? > > On Fri, Jan 16, 2009 at 4:06 PM, Breno de Medeiros > wrote: > Eran's earlier response clarifies what it is the intended scope for > the spec. > > > On Fri, Jan 16, 2009 at 4:05 PM, Mark Nottingham > wrote: > The scope isn't well-defined in the current spec. > > > > On 17/01/2009, at 10:57 AM, Breno de Medeiros wrote: > > > > On Fri, Jan 16, 2009 at 3:52 PM, Mark Nottingham > wrote: > > On 17/01/2009, at 10:28 AM, Breno de Medeiros wrote: > Nobody here is suggesting that this standard make it authoritative, > just delegating the decision to applications. This is a sensible > thing to do from a modularity standpoint, and it is bad when > standards try to push decisions lower in the network layer than they > have to be. > > Possibly. I'd be OK with defining the scope of site-meta to be the > site it's on by default, whilst leaving the door open for others to > use it beyond that scope on a per-application basis (with > appropriate warnings). Does that work for you, and does it work for > others? > > I understand that is what the spec currently does, i.e., delegates > authority question to the applications. Does it not? > > > > Cheers, > > > -- > Mark Nottingham http://www.mnot.net/ > > > > > -- > --Breno > > +1 (650) 214-1007 desk > +1 (408) 212-0135 (Grand Central) > MTV-41-3 : 383-A > PST (GMT-8) / PDT(GMT-7) > > > -- > Mark Nottingham http://www.mnot.net/ > > > > > -- > --Breno > > +1 (650) 214-1007 desk > +1 (408) 212-0135 (Grand Central) > MTV-41-3 : 383-A > PST (GMT-8) / PDT(GMT-7) > > > > -- > --Breno > > +1 (650) 214-1007 desk > +1 (408) 212-0135 (Grand Central) > MTV-41-3 : 383-A > PST (GMT-8) / PDT(GMT-7) -- Mark Nottingham http://www.mnot.net/ _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Fri Jan 16 17:49:54 2009 Return-Path: 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 482A23A69DD; Fri, 16 Jan 2009 17:49:54 -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 6695D28C10E for ; Fri, 16 Jan 2009 17:49:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.396 X-Spam-Level: X-Spam-Status: No, score=-4.396 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] 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 3EQzHW06SM+E for ; Fri, 16 Jan 2009 17:49:52 -0800 (PST) Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.146]) by core3.amsl.com (Postfix) with ESMTP id 687383A698E for ; Fri, 16 Jan 2009 17:49:52 -0800 (PST) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e6.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n0H1norA002620 for ; Fri, 16 Jan 2009 20:49:50 -0500 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id n0H1naTw164018 for ; Fri, 16 Jan 2009 20:49:36 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n0H1narS028978 for ; Fri, 16 Jan 2009 20:49:36 -0500 Received: from poplar (poplar.watson.ibm.com [9.2.24.140]) by d01av01.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n0H1nZc4028975; Fri, 16 Jan 2009 20:49:35 -0500 Received: from 9.12.243.198:56585 ([9.12.243.198]) by poplar.watson.ibm.com (IMF.2005.07.16.1050.haw) with SMTP ID IMFd1232156974.139; Fri, 16 Jan 2009 20:49:34 -0400 Date: Fri, 16 Jan 2009 20:49:29 -0500 From: Barry Leiba To: Mark Nottingham , Breno de Medeiros Subject: Re: hacking and standards [was: URIs, domains and authority] Message-ID: <75394988F1859307167DF898@Uranus.local> In-Reply-To: <7E9077DA-0BB8-43E9-925D-B890F5BCD052@mnot.net> References: <319C1C80-F0E8-41ED-8422-3FB303CBCA6F@mnot.net> <29fb00360901161010o4ff94b2cia4b1b7f1f74b4ff2@mail.gmail.com> <29fb00360901161022i1999e0e2u5a459a36c0bcaa4@mail.gmail.com> <4ACC3625-3B92-466C-B56D-EF2EC25DF3BD@mnot.net> <29fb00360901161528l7a27f277g3d450171cf613f05@mail.gmail.com> <7E9077DA-0BB8-43E9-925D-B890F5BCD052@mnot.net> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org > Possibly. I'd be OK with defining the scope of site-meta to be the site it's on > by default, whilst leaving the door open for others to use it beyond that scope > on a per-application basis (with appropriate warnings). Does that work for you, > and does it work for others? I would object very strongly to the idea that site-specific metadata found at http://x.y.z/site-meta might automatically be considered applicable (much less "authoritative") to any domain other than x.y.z. I can point out all sorts of cases where that's a truly bad idea. And I think it's a *terrible* idea to think that "www" is somehow special -- are you *sure* that every domain that doles out subdomains will forbid "www" as a separately managed subdomain? I'm not. DKIM had issues related to this, and they were a very contentious part of the protocol. Ultimately, we managed to have things apply to subdomains in some cases because we limited the situations, and the protocol always has the subdomain checked first (so the parent domain's data only applies as a default). I highly recommend not trying to go there, though I realize it limits the utility of things -- for instance, having metadata at blogspot.com apply to all blogs hosted there would be useful; perhaps this sort of thing can be handled in the definition of the specific metadata involved, rather than be a general rule for how site metadata works. Barry -- Barry Leiba, Senior Technical Staff (leiba@watson.ibm.com) Internet Messaging Technology, IBM Research http://www.research.ibm.com/people/l/leiba http://www.research.ibm.com/spam _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Fri Jan 16 18:21:05 2009 Return-Path: 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 08D2B3A6A75; Fri, 16 Jan 2009 18:21:05 -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 9179A3A6A75 for ; Fri, 16 Jan 2009 18:21:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.642 X-Spam-Level: X-Spam-Status: No, score=-4.642 tagged_above=-999 required=5 tests=[AWL=-2.043, 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 CBhFyOO46kRM for ; Fri, 16 Jan 2009 18:21:02 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id B24173A6A2F for ; Fri, 16 Jan 2009 18:21:02 -0800 (PST) Received: (qmail 13203 invoked from network); 17 Jan 2009 02:20:46 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 17 Jan 2009 02:20:46 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Fri, 16 Jan 2009 19:20:46 -0700 From: Eran Hammer-Lahav To: Mark Nottingham , Breno de Medeiros Date: Fri, 16 Jan 2009 19:20:36 -0700 Subject: RE: hacking and standards [was: URIs, domains and authority] Thread-Topic: hacking and standards [was: URIs, domains and authority] Thread-Index: Acl4OfcCYulHwarSTQCO1YikR+KrmAAECDXA Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234127C86A1D7@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <319C1C80-F0E8-41ED-8422-3FB303CBCA6F@mnot.net> <29fb00360901161010o4ff94b2cia4b1b7f1f74b4ff2@mail.gmail.com> <29fb00360901161022i1999e0e2u5a459a36c0bcaa4@mail.gmail.com> <4ACC3625-3B92-466C-B56D-EF2EC25DF3BD@mnot.net> <29fb00360901161528l7a27f277g3d450171cf613f05@mail.gmail.com> <7E9077DA-0BB8-43E9-925D-B890F5BCD052@mnot.net> <29fb00360901161557q5dd9d837ycbb82d2e4ac181dc@mail.gmail.com> <29fb00360901161606h913c947lf169f06cc5eed46f@mail.gmail.com> <29fb00360901161608w2f3f9fe4qacfe576ef1586c23@mail.gmail.com> <61A407D0-29E5-4778-B292-8BBD5EB8286B@mnot.net> In-Reply-To: <61A407D0-29E5-4778-B292-8BBD5EB8286B@mnot.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org This entire discussion is about the Site-Meta spec alone. My previous statement still applies: Site-Meta provides links between some "abstract web site" entity and metadata documents. This discussion is finding out an acceptable definition to this "abstract web site", and how it is different from what today the HTTP root resource of a domain is used for (i.e. http://yahoo.com/). EHL > -----Original Message----- > From: Mark Nottingham [mailto:mnot@mnot.net] > Sent: Friday, January 16, 2009 4:24 PM > To: Breno de Medeiros > Cc: Paul Hoffman; Eran Hammer-Lahav; Apps Discuss > Subject: Re: hacking and standards [was: URIs, domains and authority] > > Clarification: when I say "the spec" I mean site-meta, not Eran's > other spec. > > As I said, I'm OK with it. The reason we're having the discussion here > is as a sanity check to see what others think... > > Cheers, > > > On 17/01/2009, at 11:08 AM, Breno de Medeiros wrote: > > > I should have added the sense. Therefore if that intended scope gets > > expressed in the spec with potentially more clear language, then are > > your concerns addressed? > > > > On Fri, Jan 16, 2009 at 4:06 PM, Breno de Medeiros > > wrote: > > Eran's earlier response clarifies what it is the intended scope for > > the spec. > > > > > > On Fri, Jan 16, 2009 at 4:05 PM, Mark Nottingham > > wrote: > > The scope isn't well-defined in the current spec. > > > > > > > > On 17/01/2009, at 10:57 AM, Breno de Medeiros wrote: > > > > > > > > On Fri, Jan 16, 2009 at 3:52 PM, Mark Nottingham > > wrote: > > > > On 17/01/2009, at 10:28 AM, Breno de Medeiros wrote: > > Nobody here is suggesting that this standard make it authoritative, > > just delegating the decision to applications. This is a sensible > > thing to do from a modularity standpoint, and it is bad when > > standards try to push decisions lower in the network layer than they > > have to be. > > > > Possibly. I'd be OK with defining the scope of site-meta to be the > > site it's on by default, whilst leaving the door open for others to > > use it beyond that scope on a per-application basis (with > > appropriate warnings). Does that work for you, and does it work for > > others? > > > > I understand that is what the spec currently does, i.e., delegates > > authority question to the applications. Does it not? > > > > > > > > Cheers, > > > > > > -- > > Mark Nottingham http://www.mnot.net/ > > > > > > > > > > -- > > --Breno > > > > +1 (650) 214-1007 desk > > +1 (408) 212-0135 (Grand Central) > > MTV-41-3 : 383-A > > PST (GMT-8) / PDT(GMT-7) > > > > > > -- > > Mark Nottingham http://www.mnot.net/ > > > > > > > > > > -- > > --Breno > > > > +1 (650) 214-1007 desk > > +1 (408) 212-0135 (Grand Central) > > MTV-41-3 : 383-A > > PST (GMT-8) / PDT(GMT-7) > > > > > > > > -- > > --Breno > > > > +1 (650) 214-1007 desk > > +1 (408) 212-0135 (Grand Central) > > MTV-41-3 : 383-A > > PST (GMT-8) / PDT(GMT-7) > > > -- > Mark Nottingham http://www.mnot.net/ _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Fri Jan 16 18:56:02 2009 Return-Path: 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 AFC433A68FE; Fri, 16 Jan 2009 18:56:02 -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 F15F13A68FE for ; Fri, 16 Jan 2009 18:56:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.064 X-Spam-Level: X-Spam-Status: No, score=-3.064 tagged_above=-999 required=5 tests=[AWL=-0.465, 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 A5POn0UVdlw2 for ; Fri, 16 Jan 2009 18:56:01 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id 05EB63A689F for ; Fri, 16 Jan 2009 18:56:00 -0800 (PST) Received: from [192.168.1.4] (unknown [121.44.206.3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id D00FDD05A2; Fri, 16 Jan 2009 21:55:39 -0500 (EST) Message-Id: From: Mark Nottingham To: Barry Leiba In-Reply-To: <75394988F1859307167DF898@Uranus.local> Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: hacking and standards [was: URIs, domains and authority] Date: Sat, 17 Jan 2009 13:55:36 +1100 References: <319C1C80-F0E8-41ED-8422-3FB303CBCA6F@mnot.net> <29fb00360901161010o4ff94b2cia4b1b7f1f74b4ff2@mail.gmail.com> <29fb00360901161022i1999e0e2u5a459a36c0bcaa4@mail.gmail.com> <4ACC3625-3B92-466C-B56D-EF2EC25DF3BD@mnot.net> <29fb00360901161528l7a27f277g3d450171cf613f05@mail.gmail.com> <7E9077DA-0BB8-43E9-925D-B890F5BCD052@mnot.net> <75394988F1859307167DF898@Uranus.local> X-Mailer: Apple Mail (2.930.3) Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org Hi Barry, Your last statement >> I highly recommend not trying to go there, though I realize it >> limits the utility of things -- for instance, having metadata at >> blogspot.com apply to all blogs hosted there would be useful; >> perhaps this sort of thing can be handled in the definition of the >> specific metadata involved, rather than be a general rule for how >> site metadata works. is what I think is on the table; >> Possibly. I'd be OK with defining the scope of site-meta to be the >> site it's on >> by default, whilst leaving the door open for others to use it >> beyond that scope >> on a per-application basis (with appropriate warnings). Where "site it's on" is (protocol, hostname, port). Do you read that as roughly equivalent, or are you thinking of something different? Cheers, -- Mark Nottingham http://www.mnot.net/ _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Fri Jan 16 20:06:01 2009 Return-Path: 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 9243B3A69C3; Fri, 16 Jan 2009 20:06:01 -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 2B8503A69C3 for ; Fri, 16 Jan 2009 20:06:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.401 X-Spam-Level: X-Spam-Status: No, score=-4.401 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] 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 de9AkHvumvE3 for ; Fri, 16 Jan 2009 20:06:00 -0800 (PST) Received: from e36.co.us.ibm.com (e36.co.us.ibm.com [32.97.110.154]) by core3.amsl.com (Postfix) with ESMTP id 7AE123A689D for ; Fri, 16 Jan 2009 20:06:00 -0800 (PST) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e36.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id n0H44j1J003296 for ; Fri, 16 Jan 2009 21:04:45 -0700 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id n0H45hN3207228 for ; Fri, 16 Jan 2009 21:05:44 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n0H45htx016796 for ; Fri, 16 Jan 2009 21:05:43 -0700 Received: from poplar (poplar.watson.ibm.com [9.2.24.140]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n0H45gWr016754; Fri, 16 Jan 2009 21:05:43 -0700 Received: from 9.12.239.111:56986 ([9.12.239.111]) by poplar.watson.ibm.com (IMF.2005.07.16.1050.haw) with SMTP ID IMFd1232165141.146; Fri, 16 Jan 2009 23:05:41 -0400 Date: Fri, 16 Jan 2009 23:05:35 -0500 From: Barry Leiba To: Mark Nottingham Subject: Re: hacking and standards [was: URIs, domains and authority] Message-ID: <00AD45209C5E88F6FE89BD04@Uranus.local> In-Reply-To: References: <319C1C80-F0E8-41ED-8422-3FB303CBCA6F@mnot.net> <29fb00360901161010o4ff94b2cia4b1b7f1f74b4ff2@mail.gmail.com> <29fb00360901161022i1999e0e2u5a459a36c0bcaa4@mail.gmail.com> <4ACC3625-3B92-466C-B56D-EF2EC25DF3BD@mnot.net> <29fb00360901161528l7a27f277g3d450171cf613f05@mail.gmail.com> <7E9077DA-0BB8-43E9-925D-B890F5BCD052@mnot.net> <75394988F1859307167DF898@Uranus.local> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Disposition: inline Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org > Where "site it's on" is (protocol, hostname, port). > > Do you read that as roughly equivalent, or are you thinking of something > different? Mm... OK; I think I read that differently before. Yes, it sounds like you and I agree here. Barry _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Sat Jan 17 14:01:02 2009 Return-Path: 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 CE4973A6A9E; Sat, 17 Jan 2009 14:01:02 -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 758EC3A6851 for ; Sat, 17 Jan 2009 14:01:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.232 X-Spam-Level: X-Spam-Status: No, score=-1.232 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 ktXHldpIdnvO for ; Sat, 17 Jan 2009 14:01:00 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.177]) by core3.amsl.com (Postfix) with ESMTP id 506A83A6B37 for ; Sat, 17 Jan 2009 14:01:00 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id v33so1212770wah.2 for ; Sat, 17 Jan 2009 14:00:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:reply-to:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=UG2bSxo+2oiDym4MF+VhnmstVA4BakwZ9Tu8yOvNaQs=; b=NnjEDZxBldQqoG6OoQrO1yEl4zH/3iqN4Eojy32A+toxcpsDt3yJKnW4YJOj8ZuDlX P/QY+Pc3BlLCXLFAJACB6d+Qhup4A0p80TQ6dIgHshWSD145bCh4zab7kd8plVNuW+dX gdwZaNEIzBOKUHpjh0O1iJs07vWXE0g9rzxec= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:reply-to:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=Ed1kj6J03FpIUPGxfJ1DCkHzzX1b8JW3gCezgNRBB0cbXSmbiQI25PNImCi8TSh77Z 75y8AFjWicFnowzeBTD9QkdZnRh0mD0JxjDBLmXKuykagFf+OlJRjIMNeGJWLGtUFwvi SK1vNjQlO/fyp6JqGd6loRAE7rFByMolY0oxs= MIME-Version: 1.0 Received: by 10.115.23.19 with SMTP id a19mr2875582waj.63.1232229644259; Sat, 17 Jan 2009 14:00:44 -0800 (PST) In-Reply-To: <319C1C80-F0E8-41ED-8422-3FB303CBCA6F@mnot.net> References: <319C1C80-F0E8-41ED-8422-3FB303CBCA6F@mnot.net> Date: Sat, 17 Jan 2009 14:00:44 -0800 X-Google-Sender-Auth: 102ebac04e35c210 Message-ID: <517bf110901171400k3c7383a9n1558810a3ca38c49@mail.gmail.com> Subject: Re: URIs, domains and authority From: Tim Bray To: Mark Nottingham Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tbray@textuality.com List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1202681990==" Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org --===============1202681990== Content-Type: multipart/alternative; boundary=001485f33a183a53b80460b4d254 --001485f33a183a53b80460b4d254 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Jan 15, 2009 at 10:11 PM, Mark Nottingham wrote: > The site-meta draft < > http://tools.ietf.org/id/draft-nottingham-site-meta-00.txt> defines an > "=DCber well-known location" for Web sites, in an attempt to allow discov= ery > of metadata about a site without defining an application-specific URL (wh= ich > is generally held to be bad practice). I assume it's well-known that this has been a long-time discussion over at the W3C TAG, called Sitedata-36: http://www.w3.org/2001/tag/group/track/issues/36 The discussion has been going on since 2003. I think the notion that a "site" maps to the root of a host's URI space is demonstrably wrong, and that carving out pieces of namespace is harmful. M= y opinion, stated in Feb. 2003, hasn't changed. It's short enough to copy in= : =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I took an action item last TAG telecon to raise a strawman proposal. TBL launched this with his proposal at http://lists.w3.org/Archives/Public/www-tag/2003Feb/0093.html. He outlines the problem and proposes a new HTTP header (the note says "HTTP tag" but that's a typo), but isn't quite explicit enough in acknowledging that we're inventing a new architectural thing, the notion of a "site". Here's how I'd come at it. Right now the web architecture doesn't have any formal notion of a "site", and software that tries to pretend it does by and large doesn't do a very good job (as the author of two large-scale web spiders I have bitter first-hand knowledge). Things like /robots.txt that try to pretend that a host is a site have problems because, well, a host isn't always a site. So let's introduce a formal notion of a "Web Site", which is a collection of Resources, each identified by URI. A resource can be in more than one site - not an obvious choice, but it seems it would be hard to enforce a rule to the contrary. Since a Web Site is an interesting and important thing, it ought to be a resource and ought to have a URI. There is no point trying to write any rules about whether all the resources on a site ought to be on the same host or whether the site's URI should look like those of the resources. Then you introduce a new HTTP header as TBL suggested. I'd call it "Web-site" or just "Site". Any server could, but need not, include this header in a response to a GET or HEAD request. You could easily include this in the of HTML documents along the lines of Perhaps would be better, or perhaps the HTML people might want to define new markup for the purpose. Of course, this leads inevitably to the question of what is a useful representation for a site. The kinds of stuff that could go there could include robots info, language info, favicon.ico equivalent, RSS info, p3p info, etc etc etc. Unlike the RDDL issues we've been discussing, I see little requirement for human readability, so this feels like a natural for a small (but extensible) RDF vocabulary, who cares if it's ugly. The RDF assertions would mostly have as their subject the URI "", which works well in this case. -Tim --001485f33a183a53b80460b4d254 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Jan 15, 2009 at 10:11 PM, Mark Nottingha= m <mnot@mnot.net&= gt; wrote:
The site-meta draft <http://tools.ietf.org/id/draft-nottin= gham-site-meta-00.txt> defines an "=DCber well-known location&q= uot; for Web sites, in an attempt to allow discovery of metadata about a si= te without defining an application-specific URL (which is generally held to= be bad practice).

I assume it's well-known that this has been a long-= time discussion over at the W3C TAG, called Sitedata-36: http://www.w3.org/2001/tag/= group/track/issues/36

The discussion has been going on since 2003.  

I think the notion that a "site" maps to th= e root of a host's URI space is demonstrably wrong, and that carving ou= t pieces of namespace is harmful.  My opinion, stated in Feb. 2003, ha= sn't changed.  It's short enough to copy in:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

TBL la= unched this with his proposal at 

http://= lists.w3.org/Archives/Public/www-tag/2003Feb/0093.html.  He <= /p>

outlin= es the problem and proposes a new HTTP header (the note says "HTTP&nbs= p;

tag&qu= ot; but that's a typo), but isn't quite explicit enough in 

acknow= ledging that we're inventing a new architectural thing, the notion = ;

of a &= quot;site".


Here&#= 39;s how I'd come at it.  Right now the web architecture doesn'= ;t have 

any fo= rmal notion of a "site", and software that tries to pretend it&nb= sp;

does b= y and large doesn't do a very good job (as the author of two 

large-= scale web spiders I have bitter first-hand knowledge).  Things 

like /= robots.txt that try to pretend that a host is a site have problems 

becaus= e, well, a host isn't always a site.


So let= 's introduce a formal notion of a "Web Site", which is a = ;

collec= tion of Resources, each identified by URI.  A resource can be in =

more t= han one site - not an obvious choice, but it seems it would be 

hard t= o enforce a rule to the contrary.


Since = a Web Site is an interesting and important thing, it ought to be a 

resour= ce and ought to have a URI.  There is no point trying to write any&nbs= p;

rules = about whether all the resources on a site ought to be on the same 

host o= r whether the site's URI should look like those of the resources.


Then y= ou introduce a new HTTP header as TBL suggested.  I'd call it = ;

"= Web-site" or just "Site".  Any server could, but need n= ot, include this 

header= in a response to a GET or HEAD request.


You co= uld easily include this in the <head> of HTML documents along the&nbs= p;

lines = of


 = <meta http-equiv=3D"Web-site" content=3D"http://example.com/site" />


Perhap= s <link> would be better, or perhaps the HTML people might want to&nb= sp;

define= new markup for the purpose.


Of cou= rse, this leads inevitably to the question of what is a useful 

repres= entation for a site.  The kinds of stuff that could go there could&nbs= p;

includ= e robots info, language info, favicon.ico equivalent, RSS info, 

p3p in= fo, etc etc etc.  Unlike the RDDL issues we've been discussing, I&= nbsp;

see li= ttle requirement for human readability, so this feels like a 

natura= l for a small (but extensible) RDF vocabulary, who cares if it's <= /p>

ugly.&= nbsp; The RDF assertions would mostly have as their subject the URI "&= quot;, 

which = works well in this case.  -Tim


--001485f33a183a53b80460b4d254-- --===============1202681990== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss --===============1202681990==-- From apps-discuss-bounces@ietf.org Sat Jan 17 14:15:59 2009 Return-Path: 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 88E153A6A96; Sat, 17 Jan 2009 14:15:59 -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 668D43A6822 for ; Sat, 17 Jan 2009 14:15:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[AWL=-0.399, 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 UCOVAj4sOGT7 for ; Sat, 17 Jan 2009 14:15:56 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id A1E0C3A6A96 for ; Sat, 17 Jan 2009 14:15:56 -0800 (PST) Received: from [192.168.1.4] (unknown [121.44.206.3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id BAA04D059E; Sat, 17 Jan 2009 17:15:35 -0500 (EST) Message-Id: <6B3EA97F-FF53-4F6A-B2B8-50243C6F68E0@mnot.net> From: Mark Nottingham To: tbray@textuality.com In-Reply-To: <517bf110901171400k3c7383a9n1558810a3ca38c49@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: URIs, domains and authority Date: Sun, 18 Jan 2009 09:15:32 +1100 References: <319C1C80-F0E8-41ED-8422-3FB303CBCA6F@mnot.net> <517bf110901171400k3c7383a9n1558810a3ca38c49@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 Yes. Unfortunately, the TAG never made much progress on this. As the introduction of site-meta tries to make clear, site-meta is = *not* a generic metadata solution; it's only intended for the subset = it's necessary to discover metadata *before* (or even without) = accessing a resource. E.g., P3P needs this because people need to know the privacy policy of = a site before they send a request (thereby revealing Personally = Identifying Information). Other uses need to find metadata for very = large numbers of resources at the same time, and cannot spider them = all to do so to discover the site's "shape." I would readily agree that the use of the term "site" here is not the = best choice, but "authority-data" is frankly a bit painful. There have been a fair number of other proposals in this space = (including some by yours truly, e.g., ), but none have caught on. I suspect this is because many of = them were too complex, and many of the requirements are quite diverse. = Thus the extreme simplicity and generality of site-meta (the next = version should be even more so). Cheers, On 18/01/2009, at 9:00 AM, Tim Bray wrote: > On Thu, Jan 15, 2009 at 10:11 PM, Mark Nottingham = > wrote: > The site-meta draft > defines an "=DCber 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). > > I assume it's well-known that this has been a long-time discussion = > over at the W3C TAG, called Sitedata-36: http://www.w3.org/2001/tag/group= /track/issues/36 > > The discussion has been going on since 2003. > > I think the notion that a "site" maps to the root of a host's URI = > space is demonstrably wrong, and that carving out pieces of = > namespace is harmful. My opinion, stated in Feb. 2003, hasn't = > changed. It's short enough to copy in: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > I took an action item last TAG telecon to raise a strawman proposal. > TBL launched this with his proposal at > http://lists.w3.org/Archives/Public/www-tag/2003Feb/0093.html. He > outlines the problem and proposes a new HTTP header (the note says = > "HTTP > tag" but that's a typo), but isn't quite explicit enough in > acknowledging that we're inventing a new architectural thing, the = > notion > of a "site". > > Here's how I'd come at it. Right now the web architecture doesn't = > have > any formal notion of a "site", and software that tries to pretend it > does by and large doesn't do a very good job (as the author of two > large-scale web spiders I have bitter first-hand knowledge). Things > like /robots.txt that try to pretend that a host is a site have = > problems > because, well, a host isn't always a site. > > So let's introduce a formal notion of a "Web Site", which is a > collection of Resources, each identified by URI. A resource can be in > more than one site - not an obvious choice, but it seems it would be > hard to enforce a rule to the contrary. > > Since a Web Site is an interesting and important thing, it ought to = > be a > resource and ought to have a URI. There is no point trying to write = > any > rules about whether all the resources on a site ought to be on the = > same > host or whether the site's URI should look like those of the = > resources. > > Then you introduce a new HTTP header as TBL suggested. I'd call it > "Web-site" or just "Site". Any server could, but need not, include = > this > header in a response to a GET or HEAD request. > > You could easily include this in the of HTML documents along = > the > lines of > > > > Perhaps would be better, or perhaps the HTML people might = > want to > define new markup for the purpose. > > Of course, this leads inevitably to the question of what is a useful > representation for a site. The kinds of stuff that could go there = > could > include robots info, language info, favicon.ico equivalent, RSS info, > p3p info, etc etc etc. Unlike the RDDL issues we've been = > discussing, I > see little requirement for human readability, so this feels like a > natural for a small (but extensible) RDF vocabulary, who cares if it's > ugly. The RDF assertions would mostly have as their subject the URI = > "", > which works well in this case. -Tim > -- Mark Nottingham http://www.mnot.net/ _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Sat Jan 17 14:32:10 2009 Return-Path: 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 5BDB63A6A9E; Sat, 17 Jan 2009 14:32:10 -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 113673A6957 for ; Sat, 17 Jan 2009 14:32:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.984 X-Spam-Level: X-Spam-Status: No, score=-0.984 tagged_above=-999 required=5 tests=[AWL=-0.497, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 azj8Jdu7Ixuh for ; Sat, 17 Jan 2009 14:32:08 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.183]) by core3.amsl.com (Postfix) with ESMTP id 647663A6851 for ; Sat, 17 Jan 2009 14:32:08 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id v33so1217280wah.2 for ; Sat, 17 Jan 2009 14:31:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:reply-to:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=6CqTJ+hV/gZdDlqPzsIamsmAPiIl+mNKFHEHV6gfPog=; b=W5B3aD3GJtA64cwh4rOLkzGkSUrcCL+FoV0UXhKeg+zQ03CFcZ2bGWoA/rnfBU2MP5 wxaMntbF8yHLzDmFFop5uKC/EcKIY5oH7c51bZTQRogHu1s0Cza8csNP/oakdF7zhF+/ bp1WamItJKKIZtU0u/m17m1hZSZOqbfTFlOks= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:reply-to:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=aA2sY6bmuCqS60oEHP0KhP+E/ITc1WhgSAxIrdb5oauvCB4wj1vmL+/JtuZLiYzYQb pzV5lQBtLx+O1HmujJw6IUxXU55RuIsdGNE0+dxf9maL3I+pv69nCPZZlWnsSqJnunqm z1D9ecl1JnlXUTUj5MraG8gfk8StrDoWoNcv4= MIME-Version: 1.0 Received: by 10.114.56.1 with SMTP id e1mr1521849waa.150.1232231511952; Sat, 17 Jan 2009 14:31:51 -0800 (PST) In-Reply-To: <6B3EA97F-FF53-4F6A-B2B8-50243C6F68E0@mnot.net> References: <319C1C80-F0E8-41ED-8422-3FB303CBCA6F@mnot.net> <517bf110901171400k3c7383a9n1558810a3ca38c49@mail.gmail.com> <6B3EA97F-FF53-4F6A-B2B8-50243C6F68E0@mnot.net> Date: Sat, 17 Jan 2009 14:31:51 -0800 X-Google-Sender-Auth: 220da761936d7bbf Message-ID: <517bf110901171431p6edd082fhff44cb25c9897e67@mail.gmail.com> Subject: Re: URIs, domains and authority From: Tim Bray To: Mark Nottingham Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tbray@textuality.com List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1937462835==" Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org --===============1937462835== Content-Type: multipart/alternative; boundary=0016364585c28d0e170460b54185 --0016364585c28d0e170460b54185 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit > > I would readily agree that the use of the term "site" here is not the best > choice, but "authority-data" is frankly a bit painful. Your proposal is for the use of a location hardwired to a particular host. Thus, by definition it is host metadata. If you changed the name it would be more accurate and might avoid collisions with others working in the same space. I would be strongly opposed to progressing this document as long as it claims to be about Web sites, because it's not. I think that the host-metadata mechanism, as presented, might turn out to be very useful, assuming it's relabeled. -Tim --0016364585c28d0e170460b54185 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I would readily a= gree that the use of the term "site" here is not the best choice,= but "authority-data" is frankly a bit painful.

Your proposal is for the use of a location hardwired to= a particular host.  Thus, by definition it is host metadata. If you c= hanged the name it would be more accurate and might avoid collisions with o= thers working in the same space.

I would be strongly opposed to progressing this documen= t as long as it claims to be about Web sites, because it's not.  <= /div>

I think that the host-metadata mechanism, as prese= nted, might turn out to be very useful, assuming it's relabeled.
 -Tim
--0016364585c28d0e170460b54185-- --===============1937462835== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss --===============1937462835==-- From apps-discuss-bounces@ietf.org Sat Jan 17 14:56:10 2009 Return-Path: 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 6A7043A6870; Sat, 17 Jan 2009 14:56:10 -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 77A7B3A6A08 for ; Sat, 17 Jan 2009 14:56:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.948 X-Spam-Level: X-Spam-Status: No, score=-2.948 tagged_above=-999 required=5 tests=[AWL=-0.349, 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 xROF3XsxvigR for ; Sat, 17 Jan 2009 14:56:07 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id 8155E3A66B4 for ; Sat, 17 Jan 2009 14:56:07 -0800 (PST) Received: from [192.168.1.4] (unknown [121.44.206.3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id B05E2D0B93; Sat, 17 Jan 2009 17:55:48 -0500 (EST) Message-Id: <6516B799-D4F7-4CF2-B072-6B2FBF790B66@mnot.net> From: Mark Nottingham To: tbray@textuality.com In-Reply-To: <517bf110901171431p6edd082fhff44cb25c9897e67@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: URIs, domains and authority Date: Sun, 18 Jan 2009 09:55:45 +1100 References: <319C1C80-F0E8-41ED-8422-3FB303CBCA6F@mnot.net> <517bf110901171400k3c7383a9n1558810a3ca38c49@mail.gmail.com> <6B3EA97F-FF53-4F6A-B2B8-50243C6F68E0@mnot.net> <517bf110901171431p6edd082fhff44cb25c9897e67@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org Well, it's host-port-protocol; i.e., a host (in the internet sense) can have more than one, potentially many more. 'authority' (in the URI sense, which is probably the right sense, given that this is rooted in URIs) doesn't even really cover it, because it doesn't include scheme. Naming things is hard... On 18/01/2009, at 9:31 AM, Tim Bray wrote: > I would readily agree that the use of the term "site" here is not > the best choice, but "authority-data" is frankly a bit painful. > > Your proposal is for the use of a location hardwired to a particular > host. Thus, by definition it is host metadata. If you changed the > name it would be more accurate and might avoid collisions with > others working in the same space. > > I would be strongly opposed to progressing this document as long as > it claims to be about Web sites, because it's not. > > I think that the host-metadata mechanism, as presented, might turn > out to be very useful, assuming it's relabeled. > -Tim -- Mark Nottingham http://www.mnot.net/ _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Sat Jan 17 15:27:59 2009 Return-Path: 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 121BF3A68AD; Sat, 17 Jan 2009 15:27:59 -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 5AA563A68AD for ; Sat, 17 Jan 2009 15:27:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[AWL=-0.610, BAYES_00=-2.599, J_CHICKENPOX_44=0.6] 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 cWu6Xo+Q7NvK for ; Sat, 17 Jan 2009 15:27:57 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id 61B7A3A66B4 for ; Sat, 17 Jan 2009 15:27:57 -0800 (PST) Received: from [192.168.1.4] (unknown [121.44.206.3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id C3B06D05A7; Sat, 17 Jan 2009 18:27:39 -0500 (EST) Message-Id: <201A9829-6DC9-4539-B2FF-7307B95973FF@mnot.net> From: Mark Nottingham To: Tim Bray In-Reply-To: <6516B799-D4F7-4CF2-B072-6B2FBF790B66@mnot.net> Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: URIs, domains and authority Date: Sun, 18 Jan 2009 10:27:36 +1100 References: <319C1C80-F0E8-41ED-8422-3FB303CBCA6F@mnot.net> <517bf110901171400k3c7383a9n1558810a3ca38c49@mail.gmail.com> <6B3EA97F-FF53-4F6A-B2B8-50243C6F68E0@mnot.net> <517bf110901171431p6edd082fhff44cb25c9897e67@mail.gmail.com> <6516B799-D4F7-4CF2-B072-6B2FBF790B66@mnot.net> X-Mailer: Apple Mail (2.930.3) Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org ..although host,port does uniquely identify, at least; so "authority" is probably the best fit. That would make it /authority-data with the upside of being more precise (and several people have noted the 'but a site is different' issue), with two (minor) downsides; a few more characters, and a more esoteric term. I'm neutral on this; if I read Tim correctly, he's nearly or at lying down in the road against the current name (is this better?). Others? On 18/01/2009, at 9:55 AM, Mark Nottingham wrote: > Well, it's host-port-protocol; i.e., a host (in the internet sense) > can have more than one, potentially many more. > > 'authority' (in the URI sense, which is probably the right sense, > given that this is rooted in URIs) doesn't even really cover it, > because it doesn't include scheme. > > Naming things is hard... > > > On 18/01/2009, at 9:31 AM, Tim Bray wrote: > >> I would readily agree that the use of the term "site" here is not >> the best choice, but "authority-data" is frankly a bit painful. >> >> Your proposal is for the use of a location hardwired to a >> particular host. Thus, by definition it is host metadata. If you >> changed the name it would be more accurate and might avoid >> collisions with others working in the same space. >> >> I would be strongly opposed to progressing this document as long as >> it claims to be about Web sites, because it's not. >> >> I think that the host-metadata mechanism, as presented, might turn >> out to be very useful, assuming it's relabeled. >> -Tim > > > -- > Mark Nottingham http://www.mnot.net/ > > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Mark Nottingham http://www.mnot.net/ _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Sat Jan 17 15:30:42 2009 Return-Path: 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 4A49E28C123; Sat, 17 Jan 2009 15:30:42 -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 8545E3A6A08 for ; Sat, 17 Jan 2009 15:30:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.278 X-Spam-Level: X-Spam-Status: No, score=-2.278 tagged_above=-999 required=5 tests=[AWL=-0.279, BAYES_00=-2.599, J_CHICKENPOX_44=0.6] 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 PO1lZHFTAG7c for ; Sat, 17 Jan 2009 15:30:40 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 7731D28C107 for ; Sat, 17 Jan 2009 15:30:40 -0800 (PST) Received: from [10.20.30.158] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n0HNULVk007157 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 17 Jan 2009 16:30:22 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <201A9829-6DC9-4539-B2FF-7307B95973FF@mnot.net> References: <319C1C80-F0E8-41ED-8422-3FB303CBCA6F@mnot.net> <517bf110901171400k3c7383a9n1558810a3ca38c49@mail.gmail.com> <6B3EA97F-FF53-4F6A-B2B8-50243C6F68E0@mnot.net> <517bf110901171431p6edd082fhff44cb25c9897e67@mail.gmail.com> <6516B799-D4F7-4CF2-B072-6B2FBF790B66@mnot.net> <201A9829-6DC9-4539-B2FF-7307B95973FF@mnot.net> Date: Sat, 17 Jan 2009 15:30:19 -0800 To: Apps Discuss From: Paul Hoffman Subject: Re: URIs, domains and authority X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org At 10:27 AM +1100 1/18/09, Mark Nottingham wrote: >..although host,port does uniquely identify, at least; so "authority" is probably the best fit. > >That would make it > /authority-data > >with the upside of being more precise (and several people have noted the 'but a site is different' issue), with two (minor) downsides; a few more characters, and a more esoteric term. > >I'm neutral on this; if I read Tim correctly, he's nearly or at lying down in the road against the current name (is this better?). Others? I lay with Tim. "site" is way too loaded of a word. I also like "-data" instead of "-meta" because you can put things in there that someone would not call metadata. _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Sat Jan 17 17:14:26 2009 Return-Path: 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 BEFA03A69C1; Sat, 17 Jan 2009 17:14:26 -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 0D5233A69C1 for ; Sat, 17 Jan 2009 17:14:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.274 X-Spam-Level: X-Spam-Status: No, score=-4.274 tagged_above=-999 required=5 tests=[AWL=-2.275, BAYES_00=-2.599, J_CHICKENPOX_44=0.6] 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 6XQgTWlvK1cA for ; Sat, 17 Jan 2009 17:14:25 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 16AAF3A68D6 for ; Sat, 17 Jan 2009 17:14:24 -0800 (PST) Received: (qmail 3767 invoked from network); 18 Jan 2009 01:14:09 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 18 Jan 2009 01:14:08 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Sat, 17 Jan 2009 18:14:08 -0700 From: Eran Hammer-Lahav To: Mark Nottingham , Tim Bray Date: Sat, 17 Jan 2009 18:14:00 -0700 Subject: RE: URIs, domains and authority Thread-Topic: URIs, domains and authority Thread-Index: Acl4+zOAofmhhSE1Q/q2uyA9/Vq5QAADou7Q Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234127C86A1E0@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <319C1C80-F0E8-41ED-8422-3FB303CBCA6F@mnot.net> <517bf110901171400k3c7383a9n1558810a3ca38c49@mail.gmail.com> <6B3EA97F-FF53-4F6A-B2B8-50243C6F68E0@mnot.net> <517bf110901171431p6edd082fhff44cb25c9897e67@mail.gmail.com> <6516B799-D4F7-4CF2-B072-6B2FBF790B66@mnot.net> <201A9829-6DC9-4539-B2FF-7307B95973FF@mnot.net> In-Reply-To: <201A9829-6DC9-4539-B2FF-7307B95973FF@mnot.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org I would like to hear from Tim how he would adjust the proposal to accommodate the term 'site'. I understand the objection but before giving up on calling this site-meta, would like to know if there are ideas on how to accomplish that. EHL > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > bounces@ietf.org] On Behalf Of Mark Nottingham > Sent: Saturday, January 17, 2009 3:28 PM > To: Tim Bray > Cc: Apps Discuss > Subject: Re: URIs, domains and authority > > ..although host,port does uniquely identify, at least; so "authority" > is probably the best fit. > > That would make it > /authority-data > > with the upside of being more precise (and several people have noted > the 'but a site is different' issue), with two (minor) downsides; a > few more characters, and a more esoteric term. > > I'm neutral on this; if I read Tim correctly, he's nearly or at lying > down in the road against the current name (is this better?). Others? > > > On 18/01/2009, at 9:55 AM, Mark Nottingham wrote: > > > Well, it's host-port-protocol; i.e., a host (in the internet sense) > > can have more than one, potentially many more. > > > > 'authority' (in the URI sense, which is probably the right sense, > > given that this is rooted in URIs) doesn't even really cover it, > > because it doesn't include scheme. > > > > Naming things is hard... > > > > > > On 18/01/2009, at 9:31 AM, Tim Bray wrote: > > > >> I would readily agree that the use of the term "site" here is not > >> the best choice, but "authority-data" is frankly a bit painful. > >> > >> Your proposal is for the use of a location hardwired to a > >> particular host. Thus, by definition it is host metadata. If you > >> changed the name it would be more accurate and might avoid > >> collisions with others working in the same space. > >> > >> I would be strongly opposed to progressing this document as long as > >> it claims to be about Web sites, because it's not. > >> > >> I think that the host-metadata mechanism, as presented, might turn > >> out to be very useful, assuming it's relabeled. > >> -Tim > > > > > > -- > > Mark Nottingham http://www.mnot.net/ > > > > _______________________________________________ > > Apps-Discuss mailing list > > Apps-Discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss > > > -- > Mark Nottingham http://www.mnot.net/ > > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Sat Jan 17 17:25:55 2009 Return-Path: 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 090E13A6A2C; Sat, 17 Jan 2009 17:25:55 -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 362383A6A2C for ; Sat, 17 Jan 2009 17:25:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[AWL=-2.202, BAYES_00=-2.599, J_CHICKENPOX_44=0.6] 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 BtzYYeWXSaEQ for ; Sat, 17 Jan 2009 17:25:53 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 6E8123A69CC for ; Sat, 17 Jan 2009 17:25:53 -0800 (PST) Received: (qmail 26163 invoked from network); 18 Jan 2009 01:25:36 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 18 Jan 2009 01:25:34 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Sat, 17 Jan 2009 18:25:34 -0700 From: Eran Hammer-Lahav To: Paul Hoffman , Apps Discuss Date: Sat, 17 Jan 2009 18:25:26 -0700 Subject: RE: URIs, domains and authority Thread-Topic: URIs, domains and authority Thread-Index: Acl4+5RZvokc6xstRP+CF2zpjoalbQADoehA Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234127C86A1E1@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <319C1C80-F0E8-41ED-8422-3FB303CBCA6F@mnot.net> <517bf110901171400k3c7383a9n1558810a3ca38c49@mail.gmail.com> <6B3EA97F-FF53-4F6A-B2B8-50243C6F68E0@mnot.net> <517bf110901171431p6edd082fhff44cb25c9897e67@mail.gmail.com> <6516B799-D4F7-4CF2-B072-6B2FBF790B66@mnot.net> <201A9829-6DC9-4539-B2FF-7307B95973FF@mnot.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org This really isn't meta or data. For the current use cases, it is all links. For future use cases, and semantically, it is really the HTTP header of the "web site". The reason we need this file is because we have no better place (DNS aside) to declare typed-relationships between the site/authority/domain/whatever and other resources. Today, people usually put those on the root resource which is wrong. /authority-header is more accurate but might sounds a bit weird. EHL > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > bounces@ietf.org] On Behalf Of Paul Hoffman > Sent: Saturday, January 17, 2009 3:30 PM > To: Apps Discuss > Subject: Re: URIs, domains and authority > > At 10:27 AM +1100 1/18/09, Mark Nottingham wrote: > >..although host,port does uniquely identify, at least; so "authority" > is probably the best fit. > > > >That would make it > > /authority-data > > > >with the upside of being more precise (and several people have noted > the 'but a site is different' issue), with two (minor) downsides; a few > more characters, and a more esoteric term. > > > >I'm neutral on this; if I read Tim correctly, he's nearly or at lying > down in the road against the current name (is this better?). Others? > > I lay with Tim. "site" is way too loaded of a word. I also like "-data" > instead of "-meta" because you can put things in there that someone > would not call metadata. > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Sat Jan 17 17:45:09 2009 Return-Path: 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 3B4313A68D6; Sat, 17 Jan 2009 17:45:09 -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 2FC2F3A68D6 for ; Sat, 17 Jan 2009 17:45:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.304 X-Spam-Level: X-Spam-Status: No, score=-1.304 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6] 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 mSMggnI6rB76 for ; Sat, 17 Jan 2009 17:45:07 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.176]) by core3.amsl.com (Postfix) with ESMTP id 5DBED3A682C for ; Sat, 17 Jan 2009 17:45:07 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id v33so1244176wah.2 for ; Sat, 17 Jan 2009 17:44:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:reply-to:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=cpejJ01CV4QZV8frjVzVF6zA0b1JFAoi6lUy/ERcc8E=; b=bkVAd7R6VRMfskQx1OubGB6JjxuII3P9mMcqR0W0AcCT50LH2dQ4ypCFoZwjLfaxTu 9iuSsL5qHRi4ZYOsyfpD/YubsbIDR51coyt5z7tIfT6IRp7E/GfTlD6l+Sq0Na/8A5AF IzoQsHTixIQIMY2F+H+miauvrTpuU4NMjHG7s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:reply-to:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=XyQ8lOxIPY1CoFqZJLTEyGNH82qUEO9qdV871O6ivWv0ImdwatXwpscHZDe7hy+MwB IDVKQv2EVEb14keR1KDsyg65HQMa8ePjIcb5ubRzjDDWhsFn2T2vzBPszF/CSfD0rXrC +LafTadJ59R+M+VxhLDioazTdwY5VxdF/P9/A= MIME-Version: 1.0 Received: by 10.114.205.1 with SMTP id c1mr2973090wag.128.1232243091349; Sat, 17 Jan 2009 17:44:51 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234127C86A1E0@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <319C1C80-F0E8-41ED-8422-3FB303CBCA6F@mnot.net> <517bf110901171400k3c7383a9n1558810a3ca38c49@mail.gmail.com> <6B3EA97F-FF53-4F6A-B2B8-50243C6F68E0@mnot.net> <517bf110901171431p6edd082fhff44cb25c9897e67@mail.gmail.com> <6516B799-D4F7-4CF2-B072-6B2FBF790B66@mnot.net> <201A9829-6DC9-4539-B2FF-7307B95973FF@mnot.net> <90C41DD21FB7C64BB94121FBBC2E7234127C86A1E0@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Sat, 17 Jan 2009 17:44:51 -0800 X-Google-Sender-Auth: fddb0d21ef90af98 Message-ID: <517bf110901171744l6c5bfa41t1cf8afb3a64a8069@mail.gmail.com> Subject: Re: URIs, domains and authority From: Tim Bray To: Eran Hammer-Lahav Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tbray@textuality.com List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0143124547==" Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org --===============0143124547== Content-Type: multipart/alternative; boundary=0016e64aee3ebca2560460b7f3e2 --0016e64aee3ebca2560460b7f3e2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Sat, Jan 17, 2009 at 5:14 PM, Eran Hammer-Lahav wrote: > I would like to hear from Tim how he would adjust the proposal to > accommodate the term 'site'. I understand the objection but before giving up > on calling this site-meta, would like to know if there are ideas on how to > accomplish that. Well, as I noted, the TAG's been wrestling with this for years, and I lost touch with that debate in 2004. I'm not sure why it's hard, from the Web's point-of-view it'd be easy enough to assert that a Site is something that other web resources can claim to be part of with a labeled link as in in HTML, and perhaps some teeny XML namespace for more generic use, which doesn't conflate hosts with sites, nor does it steal any of the URI namespace. It leaves only the problem of what to put there. I'd originally suggested RDF, but Mark's draft vocabulary looks perfectly sensible to me as far as it goes. But I'll shut up at this point because I haven't been following closely and haven't been thinking about the use cases around host+port metadata, which is the current proposal. It's just that claiming that this thing is about sites would be actively harmful, so fix that and I'll shut up. -T --0016e64aee3ebca2560460b7f3e2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sat, Jan 17, 2009 at= 5:14 PM, Eran Hammer-Lahav <era= n@hueniverse.com> wrote:
I would like to hear from Tim how he would adjust the proposal to accommoda= te the term 'site'. I understand the objection but before giving up= on calling this site-meta, would like to know if there are ideas on how to= accomplish that.

Well, as I noted, the TAG's been wrestling wi= th this for years, and I lost touch with that debate in 2004.  I'm= not sure why it's hard, from the Web's point-of-view it'd be e= asy enough to assert that a Site is something that other web resources can = claim to be part of with a labeled link as in 

<link rel=3D"site"> in HTML, and perhap= s some teeny XML namespace for more generic use, which doesn't con= flate hosts with sites, nor does it steal any of the URI namespace.  I= t leaves only the problem of what to put there.   I'd or= iginally suggested RDF, but Mark's draft vocabulary looks perfectly sen= sible to me as far as it goes.  

But I'll shut up at this point because I haven'= t been following closely and haven't been thinking about the use cases = around host+port metadata, which is the current proposal.

It's just that claiming that this thing is about sites would= be actively harmful, so fix that and I'll shut up.

-T

--0016e64aee3ebca2560460b7f3e2-- --===============0143124547== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss --===============0143124547==-- From apps-discuss-bounces@ietf.org Sat Jan 17 18:08:15 2009 Return-Path: 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 5C0E928C149; Sat, 17 Jan 2009 18:08:15 -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 1BB0B28C149 for ; Sat, 17 Jan 2009 18:08:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.131 X-Spam-Level: X-Spam-Status: No, score=-4.131 tagged_above=-999 required=5 tests=[AWL=-2.133, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6] 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 q7n+L6sXZux3 for ; Sat, 17 Jan 2009 18:08:13 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 32BE728C0CF for ; Sat, 17 Jan 2009 18:08:13 -0800 (PST) Received: (qmail 1532 invoked from network); 18 Jan 2009 02:07:57 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 18 Jan 2009 02:07:57 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Sat, 17 Jan 2009 19:07:57 -0700 From: Eran Hammer-Lahav To: "tbray@textuality.com" Date: Sat, 17 Jan 2009 19:07:49 -0700 Subject: RE: URIs, domains and authority Thread-Topic: URIs, domains and authority Thread-Index: Acl5DlsWaIEndln2SIiPUAA88ht0JQAAG/OA Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234127C86A1E3@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <319C1C80-F0E8-41ED-8422-3FB303CBCA6F@mnot.net> <517bf110901171400k3c7383a9n1558810a3ca38c49@mail.gmail.com> <6B3EA97F-FF53-4F6A-B2B8-50243C6F68E0@mnot.net> <517bf110901171431p6edd082fhff44cb25c9897e67@mail.gmail.com> <6516B799-D4F7-4CF2-B072-6B2FBF790B66@mnot.net> <201A9829-6DC9-4539-B2FF-7307B95973FF@mnot.net> <90C41DD21FB7C64BB94121FBBC2E7234127C86A1E0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <517bf110901171744l6c5bfa41t1cf8afb3a64a8069@mail.gmail.com> In-Reply-To: <517bf110901171744l6c5bfa41t1cf8afb3a64a8069@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0341309767==" Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org --===============0341309767== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E7234127C86A1E3P3PW5EX1MB01E_" --_000_90C41DD21FB7C64BB94121FBBC2E7234127C86A1E3P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm trying to understand your thinking on this. So in your view a 'site' is= something web resources associate themselves with (via links), and which c= an then be described. Because you use an association, you can assign a URI = to this 'site' which can carry its own links and metadata. The problem, of course, is that you have to check with each resource which = site they are associated with. I disagree that this can be the only valid definition of a site (self selec= ted association with some site-URI), but am open to using a different name = than site for Site-Meta if changing the name accomplishes consensus (or at = least removes objections). EHL From: timbray@gmail.com [mailto:timbray@gmail.com] On Behalf Of Tim Bray Sent: Saturday, January 17, 2009 5:45 PM To: Eran Hammer-Lahav Cc: Mark Nottingham; Apps Discuss Subject: Re: URIs, domains and authority On Sat, Jan 17, 2009 at 5:14 PM, Eran Hammer-Lahav > wrote: I would like to hear from Tim how he would adjust the proposal to accommoda= te the term 'site'. I understand the objection but before giving up on call= ing this site-meta, would like to know if there are ideas on how to accompl= ish that. Well, as I noted, the TAG's been wrestling with this for years, and I lost = touch with that debate in 2004. I'm not sure why it's hard, from the Web's= point-of-view it'd be easy enough to assert that a Site is something that = other web resources can claim to be part of with a labeled link as in in HTML, and perhaps some teeny XML namespace for more = generic use, which doesn't conflate hosts with sites, nor does it steal any= of the URI namespace. It leaves only the problem of what to put there. = I'd originally suggested RDF, but Mark's draft vocabulary looks perfectly s= ensible to me as far as it goes. But I'll shut up at this point because I haven't been following closely and= haven't been thinking about the use cases around host+port metadata, which= is the current proposal. It's just that claiming that this thing is about sites would be actively ha= rmful, so fix that and I'll shut up. -T --_000_90C41DD21FB7C64BB94121FBBC2E7234127C86A1E3P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I'm try= ing to understand your thinking on this. So in your view a 'site' is something web resources associate themselves with (via links), and which can then be described. Because you use an association, you can assign a URI to this 'si= te' which can carry its own links and metadata.

&n= bsp;

The pro= blem, of course, is that you have to check with each resource which site they are associated with.

&n= bsp;

I disag= ree that this can be the only valid definition of a site (self selected association = with some site-URI), but am open to using a different name than site for Site-Me= ta if changing the name accomplishes consensus (or at least removes objections= ).

&n= bsp;

EHL

 

From: timbray@gmail= .com [mailto:timbray@gmail.com] On Behalf Of Tim Bray
Sent: Saturday, January 17, 2009 5:45 PM
To: Eran Hammer-Lahav
Cc: Mark Nottingham; Apps Discuss
Subject: Re: URIs, domains and authority

 

On Sat, Jan 17, 2009 at = 5:14 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:=

I would like to hear fro= m Tim how he would adjust the proposal to accommodate the term 'site'. I understa= nd the objection but before giving up on calling this site-meta, would like to know if there are ideas on how to accomplish that.

 =

Well, as I noted, the TAG's been wrestling with this f= or years, and I lost touch with that debate in 2004.  I'm not sure why it's hard= , from the Web's point-of-view it'd be easy enough to assert that a Site is something that other web resources can claim to be part of with a labeled l= ink as in 

 

<link rel=3D"site"> in HTML, and perha= ps some teeny XML namespace for more generic use, which doesn't conflate hosts with sites, nor does it steal any of the URI namespace.  It leave= s only the problem of what to put there.   I'd originally suggested RDF, but Mark's draft vocabulary looks perfectly sensible to me as far as i= t goes.  

 

But I'll shut up at this point because I haven't been following closely and haven't been thinking about the use cases around host+port metadata, which is the current proposal.

 

It's just that claiming that this thing is about sites= would be actively harmful, so fix that and I'll shut up.

 

-T

 

--_000_90C41DD21FB7C64BB94121FBBC2E7234127C86A1E3P3PW5EX1MB01E_-- --===============0341309767== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss --===============0341309767==-- From apps-discuss-bounces@ietf.org Sat Jan 17 18:34:00 2009 Return-Path: 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 F05663A6B40; Sat, 17 Jan 2009 18:33:59 -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 BF4683A6AD0 for ; Sat, 17 Jan 2009 18:33:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.62 X-Spam-Level: X-Spam-Status: No, score=-5.62 tagged_above=-999 required=5 tests=[AWL=0.426, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] 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 gjHALkwnl9pD for ; Sat, 17 Jan 2009 18:33:57 -0800 (PST) Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by core3.amsl.com (Postfix) with ESMTP id D9B6B3A6AC5 for ; Sat, 17 Jan 2009 18:33:57 -0800 (PST) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n0I2Xg3x013187 for ; Sun, 18 Jan 2009 02:33:42 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n0I2XfSX063952 for ; Sat, 17 Jan 2009 19:33:42 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n0I2P3iU023072; Sat, 17 Jan 2009 20:25:03 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n0I2Om4N023071; Sat, 17 Jan 2009 20:24:48 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Sat, 17 Jan 2009 20:24:48 -0600 From: Nicolas Williams To: Eran Hammer-Lahav Subject: Re: URIs, domains and authority Message-ID: <20090118022447.GJ884@Sun.COM> References: <319C1C80-F0E8-41ED-8422-3FB303CBCA6F@mnot.net> <517bf110901171400k3c7383a9n1558810a3ca38c49@mail.gmail.com> <6B3EA97F-FF53-4F6A-B2B8-50243C6F68E0@mnot.net> <517bf110901171431p6edd082fhff44cb25c9897e67@mail.gmail.com> <6516B799-D4F7-4CF2-B072-6B2FBF790B66@mnot.net> <201A9829-6DC9-4539-B2FF-7307B95973FF@mnot.net> <90C41DD21FB7C64BB94121FBBC2E7234127C86A1E0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <517bf110901171744l6c5bfa41t1cf8afb3a64a8069@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E7234127C86A1E3@P3PW5EX1MB01.EX1.SECURESERVER.NET> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234127C86A1E3@P3PW5EX1MB01.EX1.SECURESERVER.NET> User-Agent: Mutt/1.5.7i Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org On Sat, Jan 17, 2009 at 07:07:49PM -0700, Eran Hammer-Lahav wrote: > I'm trying to understand your thinking on this. So in your view a > 'site' is something web resources associate themselves with (via > links), and which can then be described. Because you use an > association, you can assign a URI to this 'site' which can carry its > own links and metadata. > > The problem, of course, is that you have to check with each resource > which site they are associated with. > > I disagree that this can be the only valid definition of a site (self > selected association with some site-URI), but am open to using a > different name than site for Site-Meta if changing the name > accomplishes consensus (or at least removes objections). Well, listing all the things that make up a site can be, er, difficult. So what alternative is there but to let things tell you what site(s) they are in? Also, just because some resource exists in some location where many/most/all other resources are associated with a "site" does not mean that one resource is too. Perhaps this could be useful for dealing with XSS... Nico -- _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Sat Jan 17 20:04:49 2009 Return-Path: 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 7893E3A6824; Sat, 17 Jan 2009 20:04:49 -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 A12A53A6824 for ; Sat, 17 Jan 2009 20:04:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.367 X-Spam-Level: X-Spam-Status: No, score=-4.367 tagged_above=-999 required=5 tests=[AWL=-1.768, 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 vm7d8iGSkvJ5 for ; Sat, 17 Jan 2009 20:04:47 -0800 (PST) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id D5A373A677D for ; Sat, 17 Jan 2009 20:04:47 -0800 (PST) Received: (qmail 26362 invoked from network); 18 Jan 2009 04:04:30 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 18 Jan 2009 04:04:30 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Sat, 17 Jan 2009 21:04:30 -0700 From: Eran Hammer-Lahav To: Nicolas Williams Date: Sat, 17 Jan 2009 21:04:22 -0700 Subject: RE: URIs, domains and authority Thread-Topic: URIs, domains and authority Thread-Index: Acl5Fjvar8mXTawlQROgRmwInRC5GAAC48RA Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234127C86A1E4@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <319C1C80-F0E8-41ED-8422-3FB303CBCA6F@mnot.net> <517bf110901171400k3c7383a9n1558810a3ca38c49@mail.gmail.com> <6B3EA97F-FF53-4F6A-B2B8-50243C6F68E0@mnot.net> <517bf110901171431p6edd082fhff44cb25c9897e67@mail.gmail.com> <6516B799-D4F7-4CF2-B072-6B2FBF790B66@mnot.net> <201A9829-6DC9-4539-B2FF-7307B95973FF@mnot.net> <90C41DD21FB7C64BB94121FBBC2E7234127C86A1E0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <517bf110901171744l6c5bfa41t1cf8afb3a64a8069@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E7234127C86A1E3@P3PW5EX1MB01.EX1.SECURESERVER.NET> <20090118022447.GJ884@Sun.COM> In-Reply-To: <20090118022447.GJ884@Sun.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org Yes, everyone has their own definition of what a 'site' means... EHL > -----Original Message----- > From: Nicolas Williams [mailto:Nicolas.Williams@sun.com] > Sent: Saturday, January 17, 2009 6:25 PM > To: Eran Hammer-Lahav > Cc: tbray@textuality.com; Apps Discuss > Subject: Re: URIs, domains and authority > > On Sat, Jan 17, 2009 at 07:07:49PM -0700, Eran Hammer-Lahav wrote: > > I'm trying to understand your thinking on this. So in your view a > > 'site' is something web resources associate themselves with (via > > links), and which can then be described. Because you use an > > association, you can assign a URI to this 'site' which can carry its > > own links and metadata. > > > > The problem, of course, is that you have to check with each resource > > which site they are associated with. > > > > I disagree that this can be the only valid definition of a site (self > > selected association with some site-URI), but am open to using a > > different name than site for Site-Meta if changing the name > > accomplishes consensus (or at least removes objections). > > Well, listing all the things that make up a site can be, er, difficult. > So what alternative is there but to let things tell you what site(s) > they are in? > > Also, just because some resource exists in some location where > many/most/all other resources are associated with a "site" does not > mean > that one resource is too. > > Perhaps this could be useful for dealing with XSS... > > Nico > -- _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Sat Jan 17 22:43:50 2009 Return-Path: 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 8E4363A6A90; Sat, 17 Jan 2009 22:43:50 -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 836043A6A90 for ; Sat, 17 Jan 2009 22:43:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.618 X-Spam-Level: X-Spam-Status: No, score=-1.618 tagged_above=-999 required=5 tests=[AWL=0.358, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 ymrGG0itWiVf for ; Sat, 17 Jan 2009 22:43:48 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.179]) by core3.amsl.com (Postfix) with ESMTP id AB2A53A6810 for ; Sat, 17 Jan 2009 22:43:48 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id v33so1282483wah.2 for ; Sat, 17 Jan 2009 22:43:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:reply-to:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=m99IIV91NaILRLcsbbmWG3HAb3t/PlsWdlDMFXgGkcc=; b=FfUHfKGFS4dDguUvD//ATJi0GYYmKl+OnMLRnCEyaE4sBLxuyfVRPxTOUspaPg4xU/ GhbrGN731AjHEv8bdtXc/G6cgAEMpOhmWYHtt4tq2MFQLG/u29Ty0pysqBlaZRHxX6w8 tkoy8JR2cfJayza4+H8nBZS7LoXPrnOZNLI1Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:reply-to:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=q//VbzmKQR9ux1agMexD4T+rOIcYBoJ4f7CzI0DpbUSfI5PgGO2fr36x5HwHPr4yYK tNlyC8p2JhX+CnlC/MJL1FpNr/x6JN6E/Ax/+XCFbtFWO78FxJVVzhEQCBEWjVR2plzY ICq2gKhBqxzg2s6160pQCF1zAtnvwqNz1PWDI= MIME-Version: 1.0 Received: by 10.115.92.2 with SMTP id u2mr3093127wal.137.1232261012019; Sat, 17 Jan 2009 22:43:32 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234127C86A1E3@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <319C1C80-F0E8-41ED-8422-3FB303CBCA6F@mnot.net> <517bf110901171400k3c7383a9n1558810a3ca38c49@mail.gmail.com> <6B3EA97F-FF53-4F6A-B2B8-50243C6F68E0@mnot.net> <517bf110901171431p6edd082fhff44cb25c9897e67@mail.gmail.com> <6516B799-D4F7-4CF2-B072-6B2FBF790B66@mnot.net> <201A9829-6DC9-4539-B2FF-7307B95973FF@mnot.net> <90C41DD21FB7C64BB94121FBBC2E7234127C86A1E0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <517bf110901171744l6c5bfa41t1cf8afb3a64a8069@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E7234127C86A1E3@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Sat, 17 Jan 2009 22:43:31 -0800 X-Google-Sender-Auth: 349d10da388668a4 Message-ID: <517bf110901172243j9703b3at97c1739c69a86b5c@mail.gmail.com> Subject: Re: URIs, domains and authority From: Tim Bray To: Eran Hammer-Lahav Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tbray@textuality.com List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1681318942==" Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org --===============1681318942== Content-Type: multipart/alternative; boundary=00163646c5a4e4598d0460bc1fc3 --00163646c5a4e4598d0460bc1fc3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Sat, Jan 17, 2009 at 6:07 PM, Eran Hammer-Lahav wrote: > I'm trying to understand your thinking on this. So in your view a 'site' > is something web resources associate themselves with (via links), and which > can then be described. Because you use an association, you can assign a URI > to this 'site' which can carry its own links and metadata. > People who use, the web, and people who build the web, believe that there's something called a "site" and that the notion is important; it's typically what people get paid for building and is a common topic of conversation among users. The underlying software and protocols include no such notion. Some people see this as an irritant or shortcoming. There is not a 1-1 mapping between hosts and sites; big sites sprawl across dozens of hosts, and many small sites share hosts. Thus things like /robots.txt are irritating both in theory and in practice. The Web tends to think that anything that matters should be a "resource", i.e. have a URI. Thus, the proposal is to formalize the notion of a "site" by agreeing - that it is a resource and has a URI - on ways to find that URI, e.g. in HTTP headers or HTML elements or whatever - what you should expect to find when you dereference the site's URI. That's all. -Tim --00163646c5a4e4598d0460bc1fc3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, Jan 17, 2009 at 6:07 PM, Eran Hammer-Lah= av <eran@hueniv= erse.com> wrote:

I'm trying to understand your thinking on this. So in your view a 'site' is somet= hing web resources associate themselves with (via links), and which can then be described. Because you use an association, you can assign a URI to this = 9;site' which can carry its own links and metadata.

People who use, the web, and people who build the web, belie= ve that there's something called a "site" and that the notion= is important; it's typically what people get paid for building and is = a common topic of conversation among users.  

The underlying software and protocols include no such n= otion.  Some people see this as an irritant or shortcoming.   The= re is not a 1-1 mapping between hosts and sites; big sites sprawl across do= zens of hosts, and many small sites share hosts.  Thus things like /ro= bots.txt are irritating both in theory and in practice.

The Web tends to think that anything that matters shoul= d be a "resource", i.e. have a URI.  Thus, the proposal is t= o formalize the notion of a "site" by agreeing 
- that it is a resource and has a URI
- on ways to find that= URI, e.g. in HTTP headers or HTML <link> elements or whatever
<= div>- what you should expect to find when you dereference the site's UR= I.

That's all.  -Tim
--00163646c5a4e4598d0460bc1fc3-- --===============1681318942== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss --===============1681318942==-- From apps-discuss-bounces@ietf.org Sun Jan 18 00:46:40 2009 Return-Path: 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 AA5F43A67F0; Sun, 18 Jan 2009 00:46:40 -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 381C33A67F0 for ; Sun, 18 Jan 2009 00:46:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.848 X-Spam-Level: X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[AWL=-0.249, 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 v2SEU1437sY2 for ; Sun, 18 Jan 2009 00:46:38 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id B26C13A67A3 for ; Sun, 18 Jan 2009 00:46:35 -0800 (PST) Received: from [192.168.1.4] (unknown [121.44.206.3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id ECA3CD05A2; Sun, 18 Jan 2009 03:46:15 -0500 (EST) Message-Id: <7F296296-49FF-4659-9AC3-32E1C95A0F15@mnot.net> From: Mark Nottingham To: tbray@textuality.com In-Reply-To: <517bf110901171744l6c5bfa41t1cf8afb3a64a8069@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: URIs, domains and authority Date: Sun, 18 Jan 2009 19:46:13 +1100 References: <319C1C80-F0E8-41ED-8422-3FB303CBCA6F@mnot.net> <517bf110901171400k3c7383a9n1558810a3ca38c49@mail.gmail.com> <6B3EA97F-FF53-4F6A-B2B8-50243C6F68E0@mnot.net> <517bf110901171431p6edd082fhff44cb25c9897e67@mail.gmail.com> <6516B799-D4F7-4CF2-B072-6B2FBF790B66@mnot.net> <201A9829-6DC9-4539-B2FF-7307B95973FF@mnot.net> <90C41DD21FB7C64BB94121FBBC2E7234127C86A1E0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <517bf110901171744l6c5bfa41t1cf8afb3a64a8069@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org It's very hard. If evil.net asserts that it's part of the site citibank.com and is unquestioningly believed, all sorts of nasty things can happen. Furthermore, spidering every possible resource to determine the shape of a site is unworkable for most use cases, so some sort of site map is required. If there isn't any grounding for that map (e.g., being limited to an authority), then two maps can assert that a single resource is part of both sites; now you have to deal with conflict resolution. robots.txt, p3p.xml, favicon.ico, and the like are unfortunate hacks, yes, but they work, because they're grounded in a crisply defined scope -- a single and whole authority. I think the use of the term 'authority' in the URI spec is very appropriate. "Site" is a term that people use when referring to portions of the Web; this mechanism is for machines, and doesn't *necessarily* have to align with the concept of "site." BTW -- there was a substantial amount of feedback that XML was too complex and error-prone for this purpose, so the next draft is likely to be a header-like text format. Cheers, On 18/01/2009, at 12:44 PM, Tim Bray wrote: > On Sat, Jan 17, 2009 at 5:14 PM, Eran Hammer-Lahav > wrote: > I would like to hear from Tim how he would adjust the proposal to > accommodate the term 'site'. I understand the objection but before > giving up on calling this site-meta, would like to know if there are > ideas on how to accomplish that. > > Well, as I noted, the TAG's been wrestling with this for years, and > I lost touch with that debate in 2004. I'm not sure why it's hard, > from the Web's point-of-view it'd be easy enough to assert that a > Site is something that other web resources can claim to be part of > with a labeled link as in > > in HTML, and perhaps some teeny XML namespace for > more generic use, which doesn't conflate hosts with sites, nor does > it steal any of the URI namespace. It leaves only the problem of > what to put there. I'd originally suggested RDF, but Mark's draft > vocabulary looks perfectly sensible to me as far as it goes. > > But I'll shut up at this point because I haven't been following > closely and haven't been thinking about the use cases around host > +port metadata, which is the current proposal. > > It's just that claiming that this thing is about sites would be > actively harmful, so fix that and I'll shut up. > > -T > -- Mark Nottingham http://www.mnot.net/ _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Sun Jan 18 11:31:10 2009 Return-Path: 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 9520828C0FA; Sun, 18 Jan 2009 11:31:10 -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 848DE28C0E4 for ; Sun, 18 Jan 2009 11:31:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.63 X-Spam-Level: X-Spam-Status: No, score=-5.63 tagged_above=-999 required=5 tests=[AWL=0.416, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] 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 eOFuTZRWYb3C for ; Sun, 18 Jan 2009 11:31:08 -0800 (PST) Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by core3.amsl.com (Postfix) with ESMTP id C7F9728C0FA for ; Sun, 18 Jan 2009 11:31:00 -0800 (PST) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n0IJUarR026605 for ; Sun, 18 Jan 2009 19:30:45 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n0IJUaCf018837 for ; Sun, 18 Jan 2009 12:30:36 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n0IJLqA2023335; Sun, 18 Jan 2009 13:21:57 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n0IJLZFY023334; Sun, 18 Jan 2009 13:21:35 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Sun, 18 Jan 2009 13:21:35 -0600 From: Nicolas Williams To: Eran Hammer-Lahav Subject: Re: URIs, domains and authority Message-ID: <20090118192135.GK884@Sun.COM> References: <517bf110901171400k3c7383a9n1558810a3ca38c49@mail.gmail.com> <6B3EA97F-FF53-4F6A-B2B8-50243C6F68E0@mnot.net> <517bf110901171431p6edd082fhff44cb25c9897e67@mail.gmail.com> <6516B799-D4F7-4CF2-B072-6B2FBF790B66@mnot.net> <201A9829-6DC9-4539-B2FF-7307B95973FF@mnot.net> <90C41DD21FB7C64BB94121FBBC2E7234127C86A1E0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <517bf110901171744l6c5bfa41t1cf8afb3a64a8069@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E7234127C86A1E3@P3PW5EX1MB01.EX1.SECURESERVER.NET> <20090118022447.GJ884@Sun.COM> <90C41DD21FB7C64BB94121FBBC2E7234127C86A1E4@P3PW5EX1MB01.EX1.SECURESERVER.NET> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234127C86A1E4@P3PW5EX1MB01.EX1.SECURESERVER.NET> User-Agent: Mutt/1.5.7i Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org On Sat, Jan 17, 2009 at 09:04:22PM -0700, Eran Hammer-Lahav wrote: > Yes, everyone has their own definition of what a 'site' means... Except I didn't touch on that topic. I merely pointed out that listing all the resources that make up a "site," whatever your definition of that might be, is not realistic. Yes, I did then mention XSS attacks, which does assume a notion of "site," and a fairly weak one at that (is user-submitted content part of a larger "site" built by others?). That's the crux of XSS, isn't it? Identifying the "source" ("authority") of content that is at what users think of as "sites" may well help address XSS. Nico -- _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Sun Jan 18 11:42:24 2009 Return-Path: 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 ECCC728C0E4; Sun, 18 Jan 2009 11:42:24 -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 AC6C53A695F for ; Sun, 18 Jan 2009 11:42:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.639 X-Spam-Level: X-Spam-Status: No, score=-5.639 tagged_above=-999 required=5 tests=[AWL=0.407, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] 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 5d-0gu60ymvE for ; Sun, 18 Jan 2009 11:42:22 -0800 (PST) Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by core3.amsl.com (Postfix) with ESMTP id E78EB3A6881 for ; Sun, 18 Jan 2009 11:42:22 -0800 (PST) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n0IJg75U028108 for ; Sun, 18 Jan 2009 19:42:07 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n0IJg6Mb024599 for ; Sun, 18 Jan 2009 12:42:06 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n0IJXRo4023343; Sun, 18 Jan 2009 13:33:27 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n0IJXRGV023342; Sun, 18 Jan 2009 13:33:27 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Sun, 18 Jan 2009 13:33:27 -0600 From: Nicolas Williams To: Tim Bray Subject: Re: URIs, domains and authority Message-ID: <20090118193327.GL884@Sun.COM> References: <319C1C80-F0E8-41ED-8422-3FB303CBCA6F@mnot.net> <517bf110901171400k3c7383a9n1558810a3ca38c49@mail.gmail.com> <6B3EA97F-FF53-4F6A-B2B8-50243C6F68E0@mnot.net> <517bf110901171431p6edd082fhff44cb25c9897e67@mail.gmail.com> <6516B799-D4F7-4CF2-B072-6B2FBF790B66@mnot.net> <201A9829-6DC9-4539-B2FF-7307B95973FF@mnot.net> <90C41DD21FB7C64BB94121FBBC2E7234127C86A1E0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <517bf110901171744l6c5bfa41t1cf8afb3a64a8069@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E7234127C86A1E3@P3PW5EX1MB01.EX1.SECURESERVER.NET> <517bf110901172243j9703b3at97c1739c69a86b5c@mail.gmail.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <517bf110901172243j9703b3at97c1739c69a86b5c@mail.gmail.com> User-Agent: Mutt/1.5.7i Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org On Sat, Jan 17, 2009 at 10:43:31PM -0800, Tim Bray wrote: > People who use, the web, and people who build the web, believe that there's > something called a "site" and that the notion is important; it's typically > what people get paid for building and is a common topic of conversation > among users. Any notion of "site" other than what users and developers already expect is likely to fail to gain currency. > The underlying software and protocols include no such notion. Some people > see this as an irritant or shortcoming. There is not a 1-1 mapping between > hosts and sites; big sites sprawl across dozens of hosts, and many small > sites share hosts. Thus things like /robots.txt are irritating both in > theory and in practice. For small sites sharing hosts virtualization comes to the rescue (or could/should). Yes, yes, if only HTTP/1.0 were no longer in use... But anyways, the underlying hosts that make up a site aren't remotely a part of the notion of "site" that _users_ have. From a user's point of view all that matters is the host/domain name part of the URL -- that makes up a site. And from an XSS point of view what matters is the source of any one resource. Users, of course, may not be aware of the fact that many individual resources make up a "site" or that some such resources are not really part of the same "site." > The Web tends to think that anything that matters should be a "resource", > i.e. have a URI. Thus, the proposal is to formalize the notion of a "site" > by agreeing > > - that it is a resource and has a URI > - on ways to find that URI, e.g. in HTTP headers or HTML elements or > whatever > - what you should expect to find when you dereference the site's URI. Thus the crucial feature of a formalized notion of site is the second one on your list, because it could actually be helpful. The third item might not be needed at all, since one could argue that without a way to dereference a "site URI" one could simply conclude that it refers to the owners of the DNS domain name of the site, for example (though I'm not saying that the thirdd item is useless, in fact, I think it'd be useful). I would also add that it may be possible for a resource to be in multiple sites, or that the site the resource appears to be in may depend on the URI used to find the resource. A single link to a containing "site" may be insufficient. > That's all. -Tim Agreed. Nico -- _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Sun Jan 18 12:01:07 2009 Return-Path: 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 8E9DB28C10D; Sun, 18 Jan 2009 12:01:07 -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 4D88F28C10D for ; Sun, 18 Jan 2009 12:01:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.315 X-Spam-Level: X-Spam-Status: No, score=-4.315 tagged_above=-999 required=5 tests=[AWL=-1.716, 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 5oMcAwPelNPc for ; Sun, 18 Jan 2009 12:01:05 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 727A23A695F for ; Sun, 18 Jan 2009 12:01:05 -0800 (PST) Received: (qmail 29847 invoked from network); 18 Jan 2009 20:00:49 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 18 Jan 2009 20:00:49 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Sun, 18 Jan 2009 13:00:49 -0700 From: Eran Hammer-Lahav To: Nicolas Williams , Tim Bray Date: Sun, 18 Jan 2009 13:00:41 -0700 Subject: RE: URIs, domains and authority Thread-Topic: URIs, domains and authority Thread-Index: Acl5peUwT0faUlxURGuHs4y7mP59eQAARLaA Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234127C86A1EF@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <319C1C80-F0E8-41ED-8422-3FB303CBCA6F@mnot.net> <517bf110901171400k3c7383a9n1558810a3ca38c49@mail.gmail.com> <6B3EA97F-FF53-4F6A-B2B8-50243C6F68E0@mnot.net> <517bf110901171431p6edd082fhff44cb25c9897e67@mail.gmail.com> <6516B799-D4F7-4CF2-B072-6B2FBF790B66@mnot.net> <201A9829-6DC9-4539-B2FF-7307B95973FF@mnot.net> <90C41DD21FB7C64BB94121FBBC2E7234127C86A1E0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <517bf110901171744l6c5bfa41t1cf8afb3a64a8069@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E7234127C86A1E3@P3PW5EX1MB01.EX1.SECURESERVER.NET> <517bf110901172243j9703b3at97c1739c69a86b5c@mail.gmail.com> <20090118193327.GL884@Sun.COM> In-Reply-To: <20090118193327.GL884@Sun.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org All of which seems to imply that the term 'site' is, well, useless. That leaves us with other well defined terms: - host - domain - authority And with the following descriptions of the document: - meta - data - header - links Any preferences? EHL > -----Original Message----- > From: Nicolas Williams [mailto:Nicolas.Williams@sun.com] > Sent: Sunday, January 18, 2009 11:33 AM > To: Tim Bray > Cc: Eran Hammer-Lahav; Apps Discuss > Subject: Re: URIs, domains and authority > > On Sat, Jan 17, 2009 at 10:43:31PM -0800, Tim Bray wrote: > > People who use, the web, and people who build the web, believe that > there's > > something called a "site" and that the notion is important; it's > typically > > what people get paid for building and is a common topic of > conversation > > among users. > > Any notion of "site" other than what users and developers already > expect > is likely to fail to gain currency. > > > The underlying software and protocols include no such notion. Some > people > > see this as an irritant or shortcoming. There is not a 1-1 mapping > between > > hosts and sites; big sites sprawl across dozens of hosts, and many > small > > sites share hosts. Thus things like /robots.txt are irritating both > in > > theory and in practice. > > For small sites sharing hosts virtualization comes to the rescue (or > could/should). Yes, yes, if only HTTP/1.0 were no longer in use... > > But anyways, the underlying hosts that make up a site aren't remotely a > part of the notion of "site" that _users_ have. From a user's point of > view all that matters is the host/domain name part of the URL -- that > makes up a site. And from an XSS point of view what matters is the > source of any one resource. Users, of course, may not be aware of the > fact that many individual resources make up a "site" or that some such > resources are not really part of the same "site." > > > The Web tends to think that anything that matters should be a > "resource", > > i.e. have a URI. Thus, the proposal is to formalize the notion of a > "site" > > by agreeing > > > > - that it is a resource and has a URI > > - on ways to find that URI, e.g. in HTTP headers or HTML > elements or > > whatever > > - what you should expect to find when you dereference the site's URI. > > Thus the crucial feature of a formalized notion of site is the second > one on your list, because it could actually be helpful. The third item > might not be needed at all, since one could argue that without a way to > dereference a "site URI" one could simply conclude that it refers to > the > owners of the DNS domain name of the site, for example (though I'm not > saying that the thirdd item is useless, in fact, I think it'd be > useful). > > I would also add that it may be possible for a resource to be in > multiple sites, or that the site the resource appears to be in may > depend on the URI used to find the resource. A single link to a > containing "site" may be insufficient. > > > That's all. -Tim > > Agreed. > > Nico > -- _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Sun Jan 18 13:07:59 2009 Return-Path: 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 9AEDB3A6A10; Sun, 18 Jan 2009 13:07:59 -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 A1C553A6A10 for ; Sun, 18 Jan 2009 13:07:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[AWL=0.298, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 62s+6OBNKj2Y for ; Sun, 18 Jan 2009 13:07:57 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.177]) by core3.amsl.com (Postfix) with ESMTP id C51403A68E3 for ; Sun, 18 Jan 2009 13:07:57 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id m16so112957waf.2 for ; Sun, 18 Jan 2009 13:07:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:reply-to:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=qdizLnOIkAdN5L4pyXwUN1KO6dwluGRs9tpgc/y3VfU=; b=YVO/LInPNZ0Ob0hQ2yJ7/vLr4aX6HLxbcKIkmCvAM+PBPE8yO3Mmh1Mz+opjMrstOp bZ/KS42rsme36MZjMLnHKiB5Qb+djKAJPCtAGQCkj4V6RvKBrDav0T6c0KrniJ9KZMI4 hAhEqaD66if34E4qaJyL3CLAVpn4nchuazT1w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:reply-to:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=QxhhFQvrioaWpIFYfpBWIG1xvBRztpoBi+6CTt6o68QlvnjY3NGSyqQ1TE3+inNOCT paeoOdPsCfpt+XePYTEakoaWiQdzoaT3A4UjtuRJzVciC5f7hu3AToSwawNwOXd9jtwP yqlFJ2VxDflxTItlvf4EYGZE2hQSe8W+1kEeY= MIME-Version: 1.0 Received: by 10.114.122.9 with SMTP id u9mr3531802wac.129.1232312860967; Sun, 18 Jan 2009 13:07:40 -0800 (PST) In-Reply-To: <6B3EA97F-FF53-4F6A-B2B8-50243C6F68E0@mnot.net> References: <319C1C80-F0E8-41ED-8422-3FB303CBCA6F@mnot.net> <517bf110901171400k3c7383a9n1558810a3ca38c49@mail.gmail.com> <6B3EA97F-FF53-4F6A-B2B8-50243C6F68E0@mnot.net> Date: Sun, 18 Jan 2009 13:07:40 -0800 X-Google-Sender-Auth: 405b7c7d869f0a7f Message-ID: <517bf110901181307w3aca734eq456fdb36d79023fb@mail.gmail.com> Subject: Re: URIs, domains and authority From: Tim Bray To: Mark Nottingham Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tbray@textuality.com List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1852835093==" Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org --===============1852835093== Content-Type: multipart/alternative; boundary=00163646ba225483fb0460c832cd --00163646ba225483fb0460c832cd Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit > > I would readily agree that the use of the term "site" here is not the best > choice, but "authority-data" is frankly a bit painful. I agree with both halves of that sentence. Why not just say "host metadata"? Anyone remotely net-literate knows that foo.com and foo.com:8080are effectively different hosts. So simply assert that "host metadata" is short for "host-port-combination metadata". -Tim --00163646ba225483fb0460c832cd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I would readily = agree that the use of the term "site" here is not the best choice= , but "authority-data" is frankly a bit painful.

I agree with both halves of that sentence.  Why no= t just say "host metadata"?  Anyone remotely net-literate kn= ows that foo.com and foo.com:8080 are effectively different hosts. So simply assert= that "host metadata" is short for "host-port-combination me= tadata".

 -Tim
--00163646ba225483fb0460c832cd-- --===============1852835093== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss --===============1852835093==-- From apps-discuss-bounces@ietf.org Sun Jan 18 14:06:23 2009 Return-Path: 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 63A2A3A67EF; Sun, 18 Jan 2009 14:06:23 -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 F34573A67EF for ; Sun, 18 Jan 2009 14:06:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.082 X-Spam-Level: X-Spam-Status: No, score=-6.082 tagged_above=-999 required=5 tests=[AWL=0.517, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 UM4eYsDnwGf6 for ; Sun, 18 Jan 2009 14:06:21 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id DA5603A67BD for ; Sun, 18 Jan 2009 14:06:20 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 436AE33C28; Sun, 18 Jan 2009 17:06:03 -0500 (EST) Date: Sun, 18 Jan 2009 17:06:03 -0500 From: John Leslie To: Eran Hammer-Lahav Subject: Re: URIs, domains and authority Message-ID: <20090118220603.GF24908@verdi> References: <6B3EA97F-FF53-4F6A-B2B8-50243C6F68E0@mnot.net> <517bf110901171431p6edd082fhff44cb25c9897e67@mail.gmail.com> <6516B799-D4F7-4CF2-B072-6B2FBF790B66@mnot.net> <201A9829-6DC9-4539-B2FF-7307B95973FF@mnot.net> <90C41DD21FB7C64BB94121FBBC2E7234127C86A1E0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <517bf110901171744l6c5bfa41t1cf8afb3a64a8069@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E7234127C86A1E3@P3PW5EX1MB01.EX1.SECURESERVER.NET> <517bf110901172243j9703b3at97c1739c69a86b5c@mail.gmail.com> <20090118193327.GL884@Sun.COM> <90C41DD21FB7C64BB94121FBBC2E7234127C86A1EF@P3PW5EX1MB01.EX1.SECURESERVER.NET> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234127C86A1EF@P3PW5EX1MB01.EX1.SECURESERVER.NET> User-Agent: Mutt/1.4.1i Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org Eran Hammer-Lahav wrote: > > All of which seems to imply that the term 'site' is, well, useless. Alas, yes: we can't map to "site" from anything we have. > That leaves us with other well defined terms: > > - host > - domain > - authority > > And with the following descriptions of the document: > > - meta > - data > - header > - links > > Any preferences? I strongly recommend "domain" if you're going to retrieve it with htpp://example.com/site-meta (well, of course, I don't recommend "site-meta", but you get the picture. And I have no problem with "meta"... though YMMV. Many folks may think of the name following "http://" as a "site", but it's really a domain -- and the better the term fits the facts, the happier we'll be in the long term. I also recommend (strongly) that the metadata exactly match the domain -- no parent domains and no subdomains -- at least in the initial version. It's far better for the webserver to serve multiple copies of the same metadata for different domains, if that is really how the "site" is organized. -- John Leslie _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Sun Jan 18 14:21:31 2009 Return-Path: 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 22CB828C101; Sun, 18 Jan 2009 14:21:31 -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 EACF228C101 for ; Sun, 18 Jan 2009 14:21:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.259 X-Spam-Level: X-Spam-Status: No, score=-5.259 tagged_above=-999 required=5 tests=[AWL=-2.661, BAYES_00=-2.599, WEIRD_PORT=0.001] 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 qf2ZkhjsXgvZ for ; Sun, 18 Jan 2009 14:21:28 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id CF54328C0E4 for ; Sun, 18 Jan 2009 14:21:28 -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 B673FD05BA; Sun, 18 Jan 2009 17:21:08 -0500 (EST) Message-Id: <4D4147BF-6919-41A5-8292-7595B5F85BFD@mnot.net> From: Mark Nottingham To: John Leslie In-Reply-To: <20090118220603.GF24908@verdi> Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: URIs, domains and authority Date: Mon, 19 Jan 2009 09:21:04 +1100 References: <6B3EA97F-FF53-4F6A-B2B8-50243C6F68E0@mnot.net> <517bf110901171431p6edd082fhff44cb25c9897e67@mail.gmail.com> <6516B799-D4F7-4CF2-B072-6B2FBF790B66@mnot.net> <201A9829-6DC9-4539-B2FF-7307B95973FF@mnot.net> <90C41DD21FB7C64BB94121FBBC2E7234127C86A1E0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <517bf110901171744l6c5bfa41t1cf8afb3a64a8069@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E7234127C86A1E3@P3PW5EX1MB01.EX1.SECURESERVER.NET> <517bf110901172243j9703b3at97c1739c69a86b5c@mail.gmail.com> <20090118193327.GL884@Sun.COM> <90C41DD21FB7C64BB94121FBBC2E7234127C86A1EF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <20090118220603.GF24908@verdi> X-Mailer: Apple Mail (2.930.3) Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org No, a domain is 'example.com', not 'www.example.com', 'us.example.com', 'foo.bar.example.com' or the myriad of other possibilities. Likewise, a 'host' is 'foo.example.com', not 'foo.example.com:8000'. If we rule out 'site' as a confusing colloquial name, it doesn't make sense to move to misusing an already defined term. On 19/01/2009, at 9:06 AM, John Leslie wrote: > Eran Hammer-Lahav wrote: >> >> All of which seems to imply that the term 'site' is, well, useless. > > Alas, yes: we can't map to "site" from anything we have. > >> That leaves us with other well defined terms: >> >> - host >> - domain >> - authority >> >> And with the following descriptions of the document: >> >> - meta >> - data >> - header >> - links >> >> Any preferences? > > I strongly recommend "domain" if you're going to retrieve it with > > htpp://example.com/site-meta > > (well, of course, I don't recommend "site-meta", but you get the > picture. > > And I have no problem with "meta"... though YMMV. > > Many folks may think of the name following "http://" as a "site", > but it's really a domain -- and the better the term fits the facts, > the happier we'll be in the long term. > > I also recommend (strongly) that the metadata exactly match the > domain -- no parent domains and no subdomains -- at least in the > initial > version. It's far better for the webserver to serve multiple copies of > the same metadata for different domains, if that is really how the > "site" > is organized. > > -- > John Leslie > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Mark Nottingham http://www.mnot.net/ _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Sun Jan 18 14:45:08 2009 Return-Path: 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 1BC4C28C173; Sun, 18 Jan 2009 14:45:08 -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 CFF4828C173 for ; Sun, 18 Jan 2009 14:45:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.097 X-Spam-Level: X-Spam-Status: No, score=-6.097 tagged_above=-999 required=5 tests=[AWL=0.502, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 tqKYILtF5nQs for ; Sun, 18 Jan 2009 14:45:06 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id 1FE6A28C16E for ; Sun, 18 Jan 2009 14:45:06 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 1FDFA33C29; Sun, 18 Jan 2009 17:44:51 -0500 (EST) Date: Sun, 18 Jan 2009 17:44:51 -0500 From: John Leslie To: Mark Nottingham Subject: Re: URIs, domains and authority Message-ID: <20090118224451.GG24908@verdi> References: <6516B799-D4F7-4CF2-B072-6B2FBF790B66@mnot.net> <201A9829-6DC9-4539-B2FF-7307B95973FF@mnot.net> <90C41DD21FB7C64BB94121FBBC2E7234127C86A1E0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <517bf110901171744l6c5bfa41t1cf8afb3a64a8069@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E7234127C86A1E3@P3PW5EX1MB01.EX1.SECURESERVER.NET> <517bf110901172243j9703b3at97c1739c69a86b5c@mail.gmail.com> <20090118193327.GL884@Sun.COM> <90C41DD21FB7C64BB94121FBBC2E7234127C86A1EF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <20090118220603.GF24908@verdi> <4D4147BF-6919-41A5-8292-7595B5F85BFD@mnot.net> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <4D4147BF-6919-41A5-8292-7595B5F85BFD@mnot.net> User-Agent: Mutt/1.4.1i Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org Mark Nottingham wrote: > > No, a domain is 'example.com', not 'www.example.com', > 'us.example.com', 'foo.bar.example.com' or the myriad of other > possibilities. Please explain. (RFC 1034 leads me to believe all of those are "domains".) -- John Leslie _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Sun Jan 18 15:27:11 2009 Return-Path: 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 AB0CC28C173; Sun, 18 Jan 2009 15:27:11 -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 0E4F928C173 for ; Sun, 18 Jan 2009 15:27:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.266 X-Spam-Level: X-Spam-Status: No, score=-4.266 tagged_above=-999 required=5 tests=[AWL=-1.668, BAYES_00=-2.599, WEIRD_PORT=0.001] 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 E8J481oMcd0X for ; Sun, 18 Jan 2009 15:27:10 -0800 (PST) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 3EE8828C170 for ; Sun, 18 Jan 2009 15:27:10 -0800 (PST) Received: (qmail 3539 invoked from network); 18 Jan 2009 23:26:54 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 18 Jan 2009 23:26:53 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Sun, 18 Jan 2009 16:26:53 -0700 From: Eran Hammer-Lahav To: Mark Nottingham , John Leslie Date: Sun, 18 Jan 2009 16:26:45 -0700 Subject: RE: URIs, domains and authority Thread-Topic: URIs, domains and authority Thread-Index: Acl5uxF69UwdEsCMTFOMrHP3e0oyFwACRZGQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234127C86A1F2@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <6B3EA97F-FF53-4F6A-B2B8-50243C6F68E0@mnot.net> <517bf110901171431p6edd082fhff44cb25c9897e67@mail.gmail.com> <6516B799-D4F7-4CF2-B072-6B2FBF790B66@mnot.net> <201A9829-6DC9-4539-B2FF-7307B95973FF@mnot.net> <90C41DD21FB7C64BB94121FBBC2E7234127C86A1E0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <517bf110901171744l6c5bfa41t1cf8afb3a64a8069@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E7234127C86A1E3@P3PW5EX1MB01.EX1.SECURESERVER.NET> <517bf110901172243j9703b3at97c1739c69a86b5c@mail.gmail.com> <20090118193327.GL884@Sun.COM> <90C41DD21FB7C64BB94121FBBC2E7234127C86A1EF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <20090118220603.GF24908@verdi> <4D4147BF-6919-41A5-8292-7595B5F85BFD@mnot.net> In-Reply-To: <4D4147BF-6919-41A5-8292-7595B5F85BFD@mnot.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org HTTP Host header seems to accomplish what you want. It includes both the domain and port. EHL > -----Original Message----- > From: Mark Nottingham [mailto:mnot@mnot.net] > Sent: Sunday, January 18, 2009 2:21 PM > To: John Leslie > Cc: Eran Hammer-Lahav; Apps Discuss > Subject: Re: URIs, domains and authority > > No, a domain is 'example.com', not 'www.example.com', > 'us.example.com', 'foo.bar.example.com' or the myriad of other > possibilities. > > Likewise, a 'host' is 'foo.example.com', not 'foo.example.com:8000'. > > If we rule out 'site' as a confusing colloquial name, it doesn't make > sense to move to misusing an already defined term. > > > On 19/01/2009, at 9:06 AM, John Leslie wrote: > > > Eran Hammer-Lahav wrote: > >> > >> All of which seems to imply that the term 'site' is, well, useless. > > > > Alas, yes: we can't map to "site" from anything we have. > > > >> That leaves us with other well defined terms: > >> > >> - host > >> - domain > >> - authority > >> > >> And with the following descriptions of the document: > >> > >> - meta > >> - data > >> - header > >> - links > >> > >> Any preferences? > > > > I strongly recommend "domain" if you're going to retrieve it with > > > > htpp://example.com/site-meta > > > > (well, of course, I don't recommend "site-meta", but you get the > > picture. > > > > And I have no problem with "meta"... though YMMV. > > > > Many folks may think of the name following "http://" as a "site", > > but it's really a domain -- and the better the term fits the facts, > > the happier we'll be in the long term. > > > > I also recommend (strongly) that the metadata exactly match the > > domain -- no parent domains and no subdomains -- at least in the > > initial > > version. It's far better for the webserver to serve multiple copies > of > > the same metadata for different domains, if that is really how the > > "site" > > is organized. > > > > -- > > John Leslie > > _______________________________________________ > > Apps-Discuss mailing list > > Apps-Discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss > > > -- > Mark Nottingham http://www.mnot.net/ _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Sun Jan 18 16:24:59 2009 Return-Path: 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 652FB28C171; Sun, 18 Jan 2009 16:24:59 -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 AFF8428C171 for ; Sun, 18 Jan 2009 16:24:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.976 X-Spam-Level: X-Spam-Status: No, score=-0.976 tagged_above=-999 required=5 tests=[AWL=-0.490, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, WEIRD_PORT=0.001] 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 aypekOVwFxDD for ; Sun, 18 Jan 2009 16:24:56 -0800 (PST) Received: from rv-out-0708.google.com (rv-out-0708.google.com [209.85.198.244]) by core3.amsl.com (Postfix) with ESMTP id B08EE28C169 for ; Sun, 18 Jan 2009 16:24:56 -0800 (PST) Received: by rv-out-0708.google.com with SMTP id c5so2902727rvf.34 for ; Sun, 18 Jan 2009 16:24:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:reply-to:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=D6lZn/kAc2WunhvVSYiKwtJkEzoN4W9gTIAJEzeRI2M=; b=Z6yApXVYJtN/2zKR4jEyUh6zvmqEggrSl6odx5d664O1hhcj0NWbA+CCse/WkeE5I8 tKVKu9Dnanbd2QT6vYyr/9xWmJg9XeyS9UWDpvXc0ipvbzwd/TqDwhsQhDyrTF0cj90D L2WJYSa0ZVyf5pgMciKDMIP2SE1yP2irzc3+8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:reply-to:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=M32US8rmELgYqTnXfs9mhBVsUkmMbIPWx2gYtz998HWX3NvewGp93WVzur435yAsiE f3VXXQWBg3z8KsKdenYXs8aZ61UJsfNAEZU4TWH+vp0+oFUSMfTqPLkEVkH9hxChEOle iI5mODHA1OXDMFqSrYztUCyQ9bxI1ueq5zo/o= MIME-Version: 1.0 Received: by 10.114.147.1 with SMTP id u1mr3194426wad.115.1232324679621; Sun, 18 Jan 2009 16:24:39 -0800 (PST) In-Reply-To: <4D4147BF-6919-41A5-8292-7595B5F85BFD@mnot.net> References: <6B3EA97F-FF53-4F6A-B2B8-50243C6F68E0@mnot.net> <201A9829-6DC9-4539-B2FF-7307B95973FF@mnot.net> <90C41DD21FB7C64BB94121FBBC2E7234127C86A1E0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <517bf110901171744l6c5bfa41t1cf8afb3a64a8069@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E7234127C86A1E3@P3PW5EX1MB01.EX1.SECURESERVER.NET> <517bf110901172243j9703b3at97c1739c69a86b5c@mail.gmail.com> <20090118193327.GL884@Sun.COM> <90C41DD21FB7C64BB94121FBBC2E7234127C86A1EF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <20090118220603.GF24908@verdi> <4D4147BF-6919-41A5-8292-7595B5F85BFD@mnot.net> Date: Sun, 18 Jan 2009 16:24:38 -0800 X-Google-Sender-Auth: 9fd0811a485f88bf Message-ID: <517bf110901181624m36ccf2ge81f6d91a742c034@mail.gmail.com> Subject: Re: URIs, domains and authority From: Tim Bray To: Mark Nottingham Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tbray@textuality.com List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0704895867==" Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org --===============0704895867== Content-Type: multipart/alternative; boundary=0016364c5bafc6deee0460caf2cf --0016364c5bafc6deee0460caf2cf Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Sun, Jan 18, 2009 at 2:21 PM, Mark Nottingham wrote: > Likewise, a 'host' is 'foo.example.com', not 'foo.example.com:8000'. > > If we rule out 'site' as a confusing colloquial name, it doesn't make sense > to move to misusing an already defined term. You're right, but "authority-metadata" has three extra syllables, and while I yield to nobody in the height of my pedantry, it feels awkward. Anyhow, I'm merely suggesting we use "host-meadata" as a an *abbreviation* for host-port-pair-metadata. -T --0016364c5bafc6deee0460caf2cf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sun, Jan 18, 2009 at 2:21 PM, Mark Nottingham= <mnot@mnot.net&g= t; wrote:
 
Likewise, a 'host' is 'foo.example.com', not 'foo.example.com:8000'.

If we rule out 'site' as a confusing colloquial name, it doesn'= t make sense to move to misusing an already defined term.
=
You're right, but "authority-metadata" has thr= ee extra syllables, and while I yield to nobody in the height of my pedantr= y, it feels awkward.  Anyhow, I'm merely suggesting we use "h= ost-meadata" as a an *abbreviation* for host-port-pair-metadata.  = ;-T
--0016364c5bafc6deee0460caf2cf-- --===============0704895867== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss --===============0704895867==-- From apps-discuss-bounces@ietf.org Sun Jan 18 16:34:18 2009 Return-Path: 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 B4D5828C0EB; Sun, 18 Jan 2009 16:34:18 -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 B2E1128C106 for ; Sun, 18 Jan 2009 16:34:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.191 X-Spam-Level: X-Spam-Status: No, score=-5.191 tagged_above=-999 required=5 tests=[AWL=-2.592, 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 c3EKhvcNRvc3 for ; Sun, 18 Jan 2009 16:34:15 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id 5E45E3A6830 for ; Sun, 18 Jan 2009 16:34:15 -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 74567D0A2C; Sun, 18 Jan 2009 19:33:57 -0500 (EST) Message-Id: <598F4E02-AAC2-4CA1-8543-8D7FA9C33CDA@mnot.net> From: Mark Nottingham To: John Leslie In-Reply-To: <20090118224451.GG24908@verdi> Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: URIs, domains and authority Date: Mon, 19 Jan 2009 11:33:52 +1100 References: <6516B799-D4F7-4CF2-B072-6B2FBF790B66@mnot.net> <201A9829-6DC9-4539-B2FF-7307B95973FF@mnot.net> <90C41DD21FB7C64BB94121FBBC2E7234127C86A1E0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <517bf110901171744l6c5bfa41t1cf8afb3a64a8069@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E7234127C86A1E3@P3PW5EX1MB01.EX1.SECURESERVER.NET> <517bf110901172243j9703b3at97c1739c69a86b5c@mail.gmail.com> <20090118193327.GL884@Sun.COM> <90C41DD21FB7C64BB94121FBBC2E7234127C86A1EF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <20090118220603.GF24908@verdi> <4D4147BF-6919-41A5-8292-7595B5F85BFD@mnot.net> <20090118224451.GG24908@verdi> X-Mailer: Apple Mail (2.930.3) Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org My examples were chosen poorly. Although "www.example.com" is a domain, the use of "example.com" includes that host, as per > A domain is identified by a domain name, and consists of that part > of the domain name space that is at or below the domain name which > specifies the domain. A domain is a subdomain of another domain if > it is contained within that domain. This relationship can be tested > by seeing if the subdomain's name ends with the containing domain's > name. For example, A.B.C.D is a subdomain of B.C.D, C.D, D, and " ". in that RFC, which is not desirable here. Moreover, in common use there's almost as much confusion about "domain" as there is about "site"; people use domain to indicate something obtained from a registrar, not a hostname or subdomain. Cheers, On 19/01/2009, at 9:44 AM, John Leslie wrote: > Mark Nottingham wrote: >> >> No, a domain is 'example.com', not 'www.example.com', >> 'us.example.com', 'foo.bar.example.com' or the myriad of other >> possibilities. > > Please explain. > > (RFC 1034 leads me to believe all of those are "domains".) > > -- > John Leslie -- Mark Nottingham http://www.mnot.net/ _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Sun Jan 18 16:40:19 2009 Return-Path: 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 285DB3A6B68; Sun, 18 Jan 2009 16:40:19 -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 9C5A13A6B68 for ; Sun, 18 Jan 2009 16:40:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.126 X-Spam-Level: X-Spam-Status: No, score=-5.126 tagged_above=-999 required=5 tests=[AWL=-2.528, BAYES_00=-2.599, WEIRD_PORT=0.001] 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 x2cGkIuhJ+C2 for ; Sun, 18 Jan 2009 16:40:15 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id 5CAB63A6B67 for ; Sun, 18 Jan 2009 16:40:15 -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 74F3BD05AE; Sun, 18 Jan 2009 19:39:56 -0500 (EST) Message-Id: From: Mark Nottingham To: tbray@textuality.com In-Reply-To: <517bf110901181624m36ccf2ge81f6d91a742c034@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: URIs, domains and authority Date: Mon, 19 Jan 2009 11:39:52 +1100 References: <6B3EA97F-FF53-4F6A-B2B8-50243C6F68E0@mnot.net> <201A9829-6DC9-4539-B2FF-7307B95973FF@mnot.net> <90C41DD21FB7C64BB94121FBBC2E7234127C86A1E0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <517bf110901171744l6c5bfa41t1cf8afb3a64a8069@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E7234127C86A1E3@P3PW5EX1MB01.EX1.SECURESERVER.NET> <517bf110901172243j9703b3at97c1739c69a86b5c@mail.gmail.com> <20090118193327.GL884@Sun.COM> <90C41DD21FB7C64BB94121FBBC2E7234127C86A1EF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <20090118220603.GF24908@verdi> <4D4147BF-6919-41A5-8292-7595B5F85BFD@mnot.net> <517bf110901181624m36ccf2ge81f6d91a742c034@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org On 19/01/2009, at 11:24 AM, Tim Bray wrote: > On Sun, Jan 18, 2009 at 2:21 PM, Mark Nottingham > wrote: > > Likewise, a 'host' is 'foo.example.com', not 'foo.example.com:8000'. > > If we rule out 'site' as a confusing colloquial name, it doesn't > make sense to move to misusing an already defined term. > > You're right, but "authority-metadata" has three extra syllables, > and while I yield to nobody in the height of my pedantry, it feels > awkward. Yeah, that's exactly how I got to "site" -- but I'd have avoided it if I knew it would cause this much kerfuffle. > Anyhow, I'm merely suggesting we use "host-meadata" as a an > *abbreviation* for host-port-pair-metadata. -T Not "host-meta"? I'm not against "host-metadata", but since we're chopping syllables... Or, going in a completely different direction: http://www.example.com/my-meta Cheers, -- Mark Nottingham http://www.mnot.net/ _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Tue Jan 20 11:59:38 2009 Return-Path: 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 9E0113A6781; Tue, 20 Jan 2009 11:59:38 -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 E624B3A6781 for ; Tue, 20 Jan 2009 11:59:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.625 X-Spam-Level: X-Spam-Status: No, score=-2.625 tagged_above=-999 required=5 tests=[AWL=-0.026, 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 rHt8WXAEuy6B for ; Tue, 20 Jan 2009 11:59:37 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 00CC83A6359 for ; Tue, 20 Jan 2009 11:59:33 -0800 (PST) Received: from [172.16.2.158] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 20 Jan 2009 19:59:17 +0000 Message-ID: <49761502.7090500@isode.com> Date: Tue, 20 Jan 2009 18:16:34 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Apps-Discuss@ietf.org Subject: Proposed XMPP BOF in San Francisco MIME-Version: 1.0 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org Hi, Peter Saint-Andre, Pete Resnick and I are organizing an XMPP BOF in San Francisco. If you would like to participare, please join the xmppwg@xmpp.org mailing list (you can subscribe by sending email to xmppwg-request@xmpp.org). I've posted a proposed agenda, which can be seen in the xmppwg mailing list archive: _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Fri Jan 23 03:29:52 2009 Return-Path: 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 4D0A23A6A6D; Fri, 23 Jan 2009 03:29:52 -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 168033A6A6D for ; Fri, 23 Jan 2009 03:29:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 7rm4-+vgJhmc for ; Fri, 23 Jan 2009 03:29:50 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [134.102.201.18]) by core3.amsl.com (Postfix) with ESMTP id 2D18C3A698D for ; Fri, 23 Jan 2009 03:29:49 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from [127.0.0.1] (maildrop [134.102.201.19]) by informatik.uni-bremen.de (8.14.2/8.14.2) with ESMTP id n0NBT5J7005253; Fri, 23 Jan 2009 12:29:08 +0100 (CET) Message-Id: From: Carsten Bormann To: Barry Leiba In-Reply-To: <41FA4EA6E19BE520781E08B1@Uranus-009002042072.watson.ibm.com> Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: DNS prefetching Date: Fri, 23 Jan 2009 12:29:04 +0100 References: <82fa66380901122206n1a5d55a3nf5cb465918b25268@mail.gmail.com> <41FA4EA6E19BE520781E08B1@Uranus-009002042072.watson.ibm.com> X-Mailer: Apple Mail (2.930.3) Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org On Jan 13 2009, at 13:43, Barry Leiba wrote: > But it only "gives them away" to your own DNS server. That is only true if the RR is in the cache of that server. (Also, "your own" DNS server may not be in your trust domain at all.) A minor issue in most cases indeed, but still worth noting. Gruesse, Carsten _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Fri Jan 23 06:50:36 2009 Return-Path: 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 5912E28C13B; Fri, 23 Jan 2009 06:50:36 -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 42FF63A6AB3 for ; Fri, 23 Jan 2009 06:50:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.123 X-Spam-Level: X-Spam-Status: No, score=-5.123 tagged_above=-999 required=5 tests=[AWL=1.126, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] 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 a2aI3aTQz8z3 for ; Fri, 23 Jan 2009 06:50:28 -0800 (PST) Received: from mx2.nic.fr (mx2.nic.fr [192.134.4.11]) by core3.amsl.com (Postfix) with ESMTP id 5FAC73A6AAB for ; Fri, 23 Jan 2009 06:50:28 -0800 (PST) Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 30F831C019A; Fri, 23 Jan 2009 15:45:08 +0100 (CET) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx2.nic.fr (Postfix) with ESMTP id 2B7F91C0181; Fri, 23 Jan 2009 15:45:08 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay1.nic.fr (Postfix) with ESMTP id 27D42A1D95C; Fri, 23 Jan 2009 15:45:08 +0100 (CET) Date: Fri, 23 Jan 2009 15:45:07 +0100 From: Stephane Bortzmeyer To: Nicolas Williams Subject: Re: URIs, domains and authority Message-ID: <20090123144507.GA14336@nic.fr> References: <517bf110901171400k3c7383a9n1558810a3ca38c49@mail.gmail.com> <6B3EA97F-FF53-4F6A-B2B8-50243C6F68E0@mnot.net> <517bf110901171431p6edd082fhff44cb25c9897e67@mail.gmail.com> <6516B799-D4F7-4CF2-B072-6B2FBF790B66@mnot.net> <201A9829-6DC9-4539-B2FF-7307B95973FF@mnot.net> <90C41DD21FB7C64BB94121FBBC2E7234127C86A1E0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <517bf110901171744l6c5bfa41t1cf8afb3a64a8069@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E7234127C86A1E3@P3PW5EX1MB01.EX1.SECURESERVER.NET> <517bf110901172243j9703b3at97c1739c69a86b5c@mail.gmail.com> <20090118193327.GL884@Sun.COM> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20090118193327.GL884@Sun.COM> X-Operating-System: Debian GNU/Linux 5.0 X-Kernel: Linux 2.6.26-1-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org On Sun, Jan 18, 2009 at 01:33:27PM -0600, Nicolas Williams wrote a message of 58 lines which said: > Any notion of "site" other than what users and developers already > expect is likely to fail to gain currency. Yes, but: > From a user's point of view all that matters is the host/domain name > part of the URL -- that makes up a site. I disagree. Part of the problem with the user's point of view is that it is not rigourously defined. But I've often hear users use "site" for "group of Web resources managed together" and so http://www.myuniversity.edu/maths and http://www.myuniversity.edu/history are two different sites... _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Fri Jan 23 09:26:41 2009 Return-Path: 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 F03DD3A6A61; Fri, 23 Jan 2009 09:26:40 -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 5979C3A6A61 for ; Fri, 23 Jan 2009 09:26:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.659 X-Spam-Level: X-Spam-Status: No, score=-1.659 tagged_above=-999 required=5 tests=[AWL=0.317, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 dbwRaRqyPHXB for ; Fri, 23 Jan 2009 09:26:39 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.183]) by core3.amsl.com (Postfix) with ESMTP id AD28C3A67F2 for ; Fri, 23 Jan 2009 09:26:39 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id j4so1649wah.2 for ; Fri, 23 Jan 2009 09:26:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:reply-to:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=4TdyqlJ4em1gzoPi+uQ5wUFOtDUC/iBlDauNPYoV6qY=; b=Hx74pMHXq+OJAiF7fkz3A9UbhEM9OCm9WR28hz40EKq6UPtoJQa8uO9NFWkYFJiiyr nftERUUxi+3epdveMSHHFLcISEYHZvcxQuDem8C+IE5ugUTLntf5UlfCFO4ALYc04mul 0wirwb8XNFvL/KXHE5TnzBL2ZoVkRj+8cq4s8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:reply-to:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=hBiF4qe6kN92/1CfKKqI4T/Iohicz1goNmbbWEx5ssJeYhz4T427KgCVId0t3qUWAE /0arweUIcJtF9T5q0O9e/rJEHW+3WI+Sd/5sKdq8ev/p1RfjnjvprdKI45LkZzMEUPLx 3TsFZjj5m6oFeAys0isbCjpA2zSoBZmhTWJmY= MIME-Version: 1.0 Received: by 10.114.145.1 with SMTP id s1mr598200wad.223.1232731581601; Fri, 23 Jan 2009 09:26:21 -0800 (PST) In-Reply-To: References: <6B3EA97F-FF53-4F6A-B2B8-50243C6F68E0@mnot.net> <517bf110901171744l6c5bfa41t1cf8afb3a64a8069@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E7234127C86A1E3@P3PW5EX1MB01.EX1.SECURESERVER.NET> <517bf110901172243j9703b3at97c1739c69a86b5c@mail.gmail.com> <20090118193327.GL884@Sun.COM> <90C41DD21FB7C64BB94121FBBC2E7234127C86A1EF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <20090118220603.GF24908@verdi> <4D4147BF-6919-41A5-8292-7595B5F85BFD@mnot.net> <517bf110901181624m36ccf2ge81f6d91a742c034@mail.gmail.com> Date: Fri, 23 Jan 2009 09:26:21 -0800 X-Google-Sender-Auth: 771aa97454da97ea Message-ID: <517bf110901230926p371a8ce0q5fb427cb35d8b632@mail.gmail.com> Subject: Re: URIs, domains and authority From: Tim Bray To: Mark Nottingham Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tbray@textuality.com List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0165128313==" Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org --===============0165128313== Content-Type: multipart/alternative; boundary=001636417c9d0659f7046129b0b5 --001636417c9d0659f7046129b0b5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit > > Anyhow, I'm merely suggesting we use "host-meadata" as a an *abbreviation* >> for host-port-pair-metadata. -T >> > > > Not "host-meta"? I'm not against "host-metadata", but since we're chopping > syllables... host-meta works for me. -T --001636417c9d0659f7046129b0b5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
 Anyhow, I'm merely suggesting we use "host-meadata" as a an *abbreviation* for host-port-pair-metadata.  -T


Not "host-meta"? I'm not against "host-metadata", but since we're chopping syllables...

host-meta works for me.  -T
--001636417c9d0659f7046129b0b5-- --===============0165128313== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss --===============0165128313==-- From apps-discuss-bounces@ietf.org Fri Jan 23 09:39:48 2009 Return-Path: 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 EF7EE28C223; Fri, 23 Jan 2009 09:39:47 -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 D4F2328C223 for ; Fri, 23 Jan 2009 09:39:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100] 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 5jzMB5BfVS4C for ; Fri, 23 Jan 2009 09:39:46 -0800 (PST) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.13]) by core3.amsl.com (Postfix) with ESMTP id F1FD128C20D for ; Fri, 23 Jan 2009 09:39:45 -0800 (PST) Received: from wpaz9.hot.corp.google.com (wpaz9.hot.corp.google.com [172.24.198.73]) by smtp-out.google.com with ESMTP id n0NHdSuM021653 for ; Fri, 23 Jan 2009 09:39:29 -0800 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1232732369; bh=R38aNN8zeWe5nqrm4hXbt7DASFs=; h=DomainKey-Signature:MIME-Version:In-Reply-To:References:Date: Message-ID:Subject:From:To:Cc:Content-Type: Content-Transfer-Encoding:X-GMailtapped-By:X-GMailtapped; b=Z8vvf4 Xi3WH+uCFk8pARFjr+qsMsfxNQqHTVlB84PHyBPdl3gkyheYH/vpH/nWw0y1mPnHiF1 qNCRMJ2duva8A== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding: x-gmailtapped-by:x-gmailtapped; b=NhYEqiY21RkYGdbEIEfC6E0HAhuMmOmg5VHZgk2DWP9a/VC4WyboNocnGdVwIb8Me b8sYb2pDzKGdEFDBXAP/g== Received: from ey-out-2122.google.com (eydd26.prod.google.com [10.208.30.26]) by wpaz9.hot.corp.google.com with ESMTP id n0NHdO75018720 for ; Fri, 23 Jan 2009 09:39:25 -0800 Received: by ey-out-2122.google.com with SMTP id d26so598822eyd.61 for ; Fri, 23 Jan 2009 09:39:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.210.43.11 with SMTP id q11mr33972ebq.163.1232732364715; Fri, 23 Jan 2009 09:39:24 -0800 (PST) In-Reply-To: <517bf110901230926p371a8ce0q5fb427cb35d8b632@mail.gmail.com> References: <6B3EA97F-FF53-4F6A-B2B8-50243C6F68E0@mnot.net> <90C41DD21FB7C64BB94121FBBC2E7234127C86A1E3@P3PW5EX1MB01.EX1.SECURESERVER.NET> <517bf110901172243j9703b3at97c1739c69a86b5c@mail.gmail.com> <20090118193327.GL884@Sun.COM> <90C41DD21FB7C64BB94121FBBC2E7234127C86A1EF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <20090118220603.GF24908@verdi> <4D4147BF-6919-41A5-8292-7595B5F85BFD@mnot.net> <517bf110901181624m36ccf2ge81f6d91a742c034@mail.gmail.com> <517bf110901230926p371a8ce0q5fb427cb35d8b632@mail.gmail.com> Date: Fri, 23 Jan 2009 09:39:24 -0800 Message-ID: <29fb00360901230939v7713c675uc1e73d755d759481@mail.gmail.com> Subject: Re: URIs, domains and authority From: Breno de Medeiros To: tbray@textuality.com X-GMailtapped-By: 172.24.198.73 X-GMailtapped: breno Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org >From what I heard in this thread, all commonly used terms such as 'site', 'domain', 'host', even 'authority' ... have multiple definitions/understandings and could lead to confusion. So the burden is on the spec to define what scope '/site-meta' has. The benefit of using one or another of more or less ambiguous terms is a discussion with diminishing returns. 'site-meta' can have a non-ambiguous meaning even if 'site' does not. On Fri, Jan 23, 2009 at 9:26 AM, Tim Bray wrote: >>> Anyhow, I'm merely suggesting we use "host-meadata" as a an >>> *abbreviation* for host-port-pair-metadata. -T >> >> >> Not "host-meta"? I'm not against "host-metadata", but since we're chopping >> syllables... > > host-meta works for me. -T > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7) _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Fri Jan 23 09:46:50 2009 Return-Path: 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 3C26728C1F3; Fri, 23 Jan 2009 09:46:50 -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 182E13A6B02 for ; Fri, 23 Jan 2009 09:46:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.497 X-Spam-Level: X-Spam-Status: No, score=-4.497 tagged_above=-999 required=5 tests=[AWL=-0.751, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, MANGLED_NAIL=2.3, RCVD_IN_DNSWL_MED=-4] 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 2Nbf5qADVnpk for ; Fri, 23 Jan 2009 09:46:43 -0800 (PST) Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by core3.amsl.com (Postfix) with ESMTP id 222773A6AFC for ; Fri, 23 Jan 2009 09:46:37 -0800 (PST) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n0NHkKgV009916 for ; Fri, 23 Jan 2009 17:46:20 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n0NHkJgX028562 for ; Fri, 23 Jan 2009 10:46:19 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n0NHbciO001718; Fri, 23 Jan 2009 11:37:38 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n0NHbXYb001717; Fri, 23 Jan 2009 11:37:33 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 23 Jan 2009 11:37:33 -0600 From: Nicolas Williams To: Stephane Bortzmeyer Subject: Re: URIs, domains and authority Message-ID: <20090123173733.GN1044@Sun.COM> References: <6B3EA97F-FF53-4F6A-B2B8-50243C6F68E0@mnot.net> <517bf110901171431p6edd082fhff44cb25c9897e67@mail.gmail.com> <6516B799-D4F7-4CF2-B072-6B2FBF790B66@mnot.net> <201A9829-6DC9-4539-B2FF-7307B95973FF@mnot.net> <90C41DD21FB7C64BB94121FBBC2E7234127C86A1E0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <517bf110901171744l6c5bfa41t1cf8afb3a64a8069@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E7234127C86A1E3@P3PW5EX1MB01.EX1.SECURESERVER.NET> <517bf110901172243j9703b3at97c1739c69a86b5c@mail.gmail.com> <20090118193327.GL884@Sun.COM> <20090123144507.GA14336@nic.fr> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <20090123144507.GA14336@nic.fr> User-Agent: Mutt/1.5.7i Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org On Fri, Jan 23, 2009 at 03:45:07PM +0100, Stephane Bortzmeyer wrote: > On Sun, Jan 18, 2009 at 01:33:27PM -0600, > Nicolas Williams wrote > a message of 58 lines which said: > > > Any notion of "site" other than what users and developers already > > expect is likely to fail to gain currency. > > Yes, but: > > > From a user's point of view all that matters is the host/domain name > > part of the URL -- that makes up a site. > > I disagree. Part of the problem with the user's point of view is that > it is not rigourously defined. But I've often hear users use "site" > for "group of Web resources managed together" and so > http://www.myuniversity.edu/maths and > http://www.myuniversity.edu/history are two different sites... True, the notion of site that users have is a bit slippery, and you might not even get all users to agree as to what whether a particular set of URIs makes up one site on N. All the more reason, I guess, to avoid the word 'site' altogether. _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Fri Jan 23 09:53:06 2009 Return-Path: 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 870CB3A6B11; Fri, 23 Jan 2009 09:53:06 -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 7255E3A6B0C for ; Fri, 23 Jan 2009 09:53:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.632 X-Spam-Level: X-Spam-Status: No, score=-5.632 tagged_above=-999 required=5 tests=[AWL=0.414, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] 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 QQJJmQz+5ZqP for ; Fri, 23 Jan 2009 09:53:00 -0800 (PST) Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by core3.amsl.com (Postfix) with ESMTP id BFF9B3A6B0B for ; Fri, 23 Jan 2009 09:52:59 -0800 (PST) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n0NHqhUm019237 for ; Fri, 23 Jan 2009 17:52:43 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-02.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n0NHqg8m034464 for ; Fri, 23 Jan 2009 10:52:42 -0700 (MST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n0NHi1Aj001732; Fri, 23 Jan 2009 11:44:01 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n0NHi1AK001731; Fri, 23 Jan 2009 11:44:01 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 23 Jan 2009 11:44:01 -0600 From: Nicolas Williams To: Breno de Medeiros Subject: Re: URIs, domains and authority Message-ID: <20090123174400.GP1044@Sun.COM> References: <90C41DD21FB7C64BB94121FBBC2E7234127C86A1E3@P3PW5EX1MB01.EX1.SECURESERVER.NET> <517bf110901172243j9703b3at97c1739c69a86b5c@mail.gmail.com> <20090118193327.GL884@Sun.COM> <90C41DD21FB7C64BB94121FBBC2E7234127C86A1EF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <20090118220603.GF24908@verdi> <4D4147BF-6919-41A5-8292-7595B5F85BFD@mnot.net> <517bf110901181624m36ccf2ge81f6d91a742c034@mail.gmail.com> <517bf110901230926p371a8ce0q5fb427cb35d8b632@mail.gmail.com> <29fb00360901230939v7713c675uc1e73d755d759481@mail.gmail.com> Mime-Version: 1.0 Content-Disposition: inline In-Reply-To: <29fb00360901230939v7713c675uc1e73d755d759481@mail.gmail.com> User-Agent: Mutt/1.5.7i Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org On Fri, Jan 23, 2009 at 09:39:24AM -0800, Breno de Medeiros wrote: > From what I heard in this thread, all commonly used terms such as > 'site', 'domain', 'host', even 'authority' ... have multiple > definitions/understandings and could lead to confusion. So the burden > is on the spec to define what scope '/site-meta' has. The benefit of > using one or another of more or less ambiguous terms is a discussion > with diminishing returns. 'site-meta' can have a non-ambiguous meaning > even if 'site' does not. 'site-meta' is probably less ambiguous too than 'host-meta' (is the latter information about the host, such as what OS it's running? Or is is information about the resources hosted on it? And what about related resources hosted on a different host but, from a user's p.o.v., still part of the same 'site'?). So I agree. _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From apps-discuss-bounces@ietf.org Fri Jan 23 10:08:21 2009 Return-Path: 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 5AEB23A6B07; Fri, 23 Jan 2009 10:08:21 -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 1A9C63A6B01 for ; Fri, 23 Jan 2009 10:08:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.695 X-Spam-Level: X-Spam-Status: No, score=-1.695 tagged_above=-999 required=5 tests=[AWL=0.281, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 MVeMfs4zaN8f for ; Fri, 23 Jan 2009 10:08:19 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.178]) by core3.amsl.com (Postfix) with ESMTP id 4F75E3A691A for ; Fri, 23 Jan 2009 10:08:19 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id j4so10625wah.2 for ; Fri, 23 Jan 2009 10:08:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:reply-to:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=fjx/0SjnMLoD+77vzaUSNHKx1BSD2v0mp/XBcLaW1iQ=; b=X5CCo3Q7xCb0/LdLVcDION3rC/QjM2mpu1rLJp2VVdl7/w04TxtfOICjuwMJgrdfKk jjdTXI4x5dGM51YHpTZu31WxXojduo3eh+nvynMPf3/bwqPqqZxkcjlhslkmNbqQ/PpD Dnp2myuiuMGvwOX6vlcOi+y7rYRBlkk/QmkEE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:reply-to:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=EY2xGd9gN1AKOvDGeQu/q5+2HMsi/jQLCaZXEmtyFZYtgh9lVF+3iLDACcSHP3k1LK yPJxbCnFKLlJu8Boine4h68yJU5PzDKAl5XoSqSTs7F4D618ntsGdshf02HeW2nXG8XO 4ib4aG7xmwbEChJ2n0SAix6D/3QLky5OKG3tk= MIME-Version: 1.0 Received: by 10.115.107.1 with SMTP id j1mr978744wam.121.1232734081842; Fri, 23 Jan 2009 10:08:01 -0800 (PST) In-Reply-To: <29fb00360901230939v7713c675uc1e73d755d759481@mail.gmail.com> References: <6B3EA97F-FF53-4F6A-B2B8-50243C6F68E0@mnot.net> <517bf110901172243j9703b3at97c1739c69a86b5c@mail.gmail.com> <20090118193327.GL884@Sun.COM> <90C41DD21FB7C64BB94121FBBC2E7234127C86A1EF@P3PW5EX1MB01.EX1.SECURESERVER.NET> <20090118220603.GF24908@verdi> <4D4147BF-6919-41A5-8292-7595B5F85BFD@mnot.net> <517bf110901181624m36ccf2ge81f6d91a742c034@mail.gmail.com> <517bf110901230926p371a8ce0q5fb427cb35d8b632@mail.gmail.com> <29fb00360901230939v7713c675uc1e73d755d759481@mail.gmail.com> Date: Fri, 23 Jan 2009 10:08:01 -0800 X-Google-Sender-Auth: 6d85ada2134a667e Message-ID: <517bf110901231008y19b71467k58d8f104837d684@mail.gmail.com> Subject: Re: URIs, domains and authority From: Tim Bray To: Breno de Medeiros Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tbray@textuality.com List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1211182417==" Sender: apps-discuss-bounces@ietf.org Errors-To: apps-discuss-bounces@ietf.org --===============1211182417== Content-Type: multipart/alternative; boundary=00163646c41c0cfcd304612a458e --00163646c41c0cfcd304612a458e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit > > From what I heard in this thread, all commonly used terms such as > 'site', 'domain', 'host', even 'authority' ... have multiple > definitions/understandings and could lead to confusion. So the burden > is on the spec to define what scope '/site-meta' has. The benefit of > using one or another of more or less ambiguous terms is a discussion > with diminishing returns. 'site-meta' can have a non-ambiguous meaning > even if 'site' does not. I'd really prefer to avoid claiming to solve the "site" problem, because I think it's a real problem that could be solved, and I haven't given up on the W3C TAG making progress. -T --00163646c41c0cfcd304612a458e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
From what I hear= d in this thread, all commonly used terms such as
'site', 'domain', 'host', even 'authority' = ... have multiple
definitions/understandings and could lead to confusion. So the burden
is on the spec to define what scope '/site-meta' has. The benefit o= f
using one or another of more or less ambiguous terms is a discussion
with diminishing returns. 'site-meta' can have a non-ambiguous mean= ing
even if 'site' does not.

I'd re= ally prefer to avoid claiming to solve the "site" problem, becaus= e I think it's a real problem that could be solved, and I haven't g= iven up on the W3C TAG making progress.  -T
--00163646c41c0cfcd304612a458e-- --===============1211182417== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Apps-Discuss mailing list Apps-Discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss --===============1211182417==--