From janssen@parc.com Wed May 27 09:26:49 2009 Return-Path: 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 1C9383A6883 for ; Wed, 27 May 2009 09:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.746 X-Spam-Level: X-Spam-Status: No, score=-5.746 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.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 l+8cm7J5B6iC for ; Wed, 27 May 2009 09:26:47 -0700 (PDT) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by core3.amsl.com (Postfix) with ESMTP id 380A728C252 for ; Wed, 27 May 2009 09:26:23 -0700 (PDT) Received: from parc.com ([13.1.100.121]) by alpha.xerox.com with SMTP id <514807(1)>; Wed, 27 May 2009 09:27:25 PDT To: Patrik =?iso-8859-1?B?RuRsdHN0cvZt?= , apps-discuss@ietf.org Subject: Re: Structured data over TCP? In-reply-to: <20090527154952.GW29258@Sun.COM> References: <20090527154952.GW29258@Sun.COM> Comments: In-reply-to Nicolas Williams message dated "Wed, 27 May 2009 08:49:52 -0700." X-Mailer: MH-E 8.1; nmh 1.3; GNU Emacs 23.0.60 Date: Wed, 27 May 2009 09:27:25 PDT Message-ID: <73408.1243441645@parc.com> From: Bill Janssen X-Mailman-Approved-At: Mon, 01 Jun 2009 08:19:40 -0700 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: , X-List-Received-Date: Wed, 27 May 2009 16:26:49 -0000 I'd second Nicholas' suggestion of using XDR, or perhaps, MIME "multipart/form-data" (RFC 2388), which turns out to be remarkably flexible, and for which toolkits exist everywhere. Bill From Joachim@Strombergson.com Thu May 28 13:30:33 2009 Return-Path: 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 BCE783A6E0D for ; Thu, 28 May 2009 13:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-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 rklX5SIf6Cli for ; Thu, 28 May 2009 13:30:31 -0700 (PDT) Received: from alastor.oderland.com (alastor.oderland.com [213.115.211.137]) by core3.amsl.com (Postfix) with ESMTP id D0DE53A6D93 for ; Thu, 28 May 2009 13:30:30 -0700 (PDT) Received: from 2.67.227.87.static.g-sn.siw.siwnet.net ([87.227.67.2] helo=stajlis.springfield.se) by alastor.oderland.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1M9mGo-00043d-1d; Thu, 28 May 2009 22:32:10 +0200 Message-ID: <4A1EF4C9.1010902@Strombergson.com> Date: Thu, 28 May 2009 22:32:09 +0200 From: =?ISO-8859-15?Q?Joachim_Str=F6mbergson?= Organization: Kryptologik User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Tony Finch Subject: Re: Structured data over TCP? References: <589AB1AC-28C1-4557-ACFB-679705154987@frobbit.se> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - alastor.oderland.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - Strombergson.com X-Mailman-Approved-At: Mon, 01 Jun 2009 08:19:40 -0700 Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Joachim@Strombergson.com List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2009 20:54:18 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Aloha! Tony Finch wrote: > On Wed, 27 May 2009, Patrik Fältström wrote: >> counting bytes is sometimes pretty simple... > > Implementations of byte-count protocols have a history of security > vulnerabilities associated with framing errors. It's evidently more > difficult than it seems. Interestingly though the motivation by Daniel J Bernstein for Netatrings is to aid in reducing security problems: 4. Security considerations The famous Finger security hole may be blamed on Finger's use of the CRLF encoding. In that encoding, each string is simply terminated by CRLF. This encoding has several problems. Most importantly, it does not declare the string size in advance. This means that a correct CRLF parser must be prepared to ask for more and more memory as it is reading the string. In the case of Finger, a lazy implementor found this to be too much trouble; instead he simply declared a fixed-size buffer and used C's gets() function. The rest is history. In contrast, as the above sample code shows, it is very easy to handle netstrings without risking buffer overflow. Thus widespread use of netstrings may improve network security. Netstrings is a design-by-contract thingy and if the string size differs from the stated length the receiver can easily (easier - in some sense of the word) detect such problem and discard excessive data. - -- Med vänlig hälsning, Yours Joachim Strömbergson - Alltid i harmonisk svängning. ======================================================================== Kryptoblog - IT-säkerhet på svenska http://www.strombergson.com/kryptoblog ======================================================================== -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoe9MkACgkQZoPr8HT30QEXpwCg3u/s8AY5dy6lrRwZGjy1jTV+ 2ycAnig282Sz6Rc83WnRYRGA5WUtePm0 =IXRV -----END PGP SIGNATURE----- From alexey.melnikov@isode.com Tue Jun 2 02:12:19 2009 Return-Path: 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 455E03A6D00 for ; Tue, 2 Jun 2009 02:12:19 -0700 (PDT) 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 T9Ve1U7R1F9o for ; Tue, 2 Jun 2009 02:12:18 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 1B6223A69B7 for ; Tue, 2 Jun 2009 02:12:18 -0700 (PDT) Received: from [92.40.94.170] (92.40.94.170.sub.mbb.three.co.uk [92.40.94.170]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 2 Jun 2009 10:12:17 +0100 Message-ID: <4A24ECD0.8050706@isode.com> Date: Tue, 02 Jun 2009 10:11:44 +0100 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 Subject: Re: TLS server identity verification References: <49E58EA2.6050200@isode.com> In-Reply-To: <49E58EA2.6050200@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: =JeffH 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: , X-List-Received-Date: Tue, 02 Jun 2009 09:12:19 -0000 Alexey Melnikov wrote: > Folks, > The issue of a document describing recommended text/template for > server identity verification procedure came up again while talking > about advancing EPP. > > As an AD, I would really like for draft-hodges-server-ident-check to > be published as an RFC. And I know that Chris was keen on this as well. > Jeff/Bob, do you have any cycles to work on this? As I've heard no response from the authors and lots of support from the community to work on this, I've asked Kurt Zeilenga and Peter Saint-Andre to take over editing of the document. From Jeff.Hodges@KingsMountain.com Tue Jun 2 08:31:10 2009 Return-Path: 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 A03B53A69DB for ; Tue, 2 Jun 2009 08:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 EwnpECTG9Df6 for ; Tue, 2 Jun 2009 08:31:08 -0700 (PDT) Received: from outbound-mail-35.bluehost.com (outbound-mail-35.bluehost.com [69.89.18.155]) by core3.amsl.com (Postfix) with SMTP id 94C963A680D for ; Tue, 2 Jun 2009 08:31:08 -0700 (PDT) Received: (qmail 18615 invoked by uid 0); 2 Jun 2009 15:31:06 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by outboundproxy2.bluehost.com with SMTP; 2 Jun 2009 15:31:06 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=KN91+hiDyIFlSa9K6oySwl9y+HUK88kSF0wRBCSA8dw9Hj/p8K0lUK3YbKYwC+aCnAwtIVm3Fze0FhhRIM6PbTWRM2V9DGNyFXg9vSSVreizJMP+mLtdtYGN9v30/VJj; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.48.78]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1MBVxC-0007lo-9a for discuss@apps.ietf.org; Tue, 02 Jun 2009 09:31:06 -0600 Message-ID: <4A2545C2.2050005@KingsMountain.com> Date: Tue, 02 Jun 2009 08:31:14 -0700 From: =JeffH User-Agent: Thunderbird 1.5.0.14ubu (X11/20080306) MIME-Version: 1.0 To: Apps Discuss Subject: Re: TLS server identity verification Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} 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: , X-List-Received-Date: Tue, 02 Jun 2009 15:31:10 -0000 > As I've heard no response from the authors and lots of support from the > community to work on this, I've asked Kurt Zeilenga and Peter > Saint-Andre to take over editing of the document. That's fine, those are good hands to place it into. Apologies for not responding sooner, I've been buried with other topics of late due to my new position. I'll try to contribute to this draft as I can as it moves forward. thanks, =JeffH From cfinss@dial.pipex.com Wed Jun 3 01:34:18 2009 Return-Path: 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 141373A6EA6 for ; Wed, 3 Jun 2009 01:34:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.346 X-Spam-Level: X-Spam-Status: No, score=-1.346 tagged_above=-999 required=5 tests=[AWL=1.254, 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 EJFqM+hHIoP3 for ; Wed, 3 Jun 2009 01:34:17 -0700 (PDT) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by core3.amsl.com (Postfix) with ESMTP id 443A63A6D74 for ; Wed, 3 Jun 2009 01:34:13 -0700 (PDT) X-Trace: 253947813/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.84/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.84 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuUEAM/SJUo+vGRU/2dsb2JhbACDKTsXiybAUAiCNYFOBQ X-IronPort-AV: E=Sophos;i="4.41,297,1241391600"; d="scan'208";a="253947813" X-IP-Direction: IN Received: from 1cust84.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.84]) by smtp.pipex.tiscali.co.uk with SMTP; 03 Jun 2009 09:34:08 +0100 Message-ID: <000901c9e41d$898eee40$0601a8c0@allison> From: "tom.petch" To: "Alexey Melnikov" , "Apps Discuss" References: <49E58EA2.6050200@isode.com> <4A24ECD0.8050706@isode.com> Subject: Re: TLS server identity verification Date: Wed, 3 Jun 2009 09:30:20 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 08:34:18 -0000 ----- Original Message ----- From: "Alexey Melnikov" To: "Apps Discuss" Cc: "=JeffH" Sent: Tuesday, June 02, 2009 11:11 AM Subject: Re: TLS server identity verification > Alexey Melnikov wrote: > > > Folks, > > The issue of a document describing recommended text/template for > > server identity verification procedure came up again while talking > > about advancing EPP. > > > > As an AD, I would really like for draft-hodges-server-ident-check to > > be published as an RFC. And I know that Chris was keen on this as well. > > Jeff/Bob, do you have any cycles to work on this? > > As I've heard no response from the authors and lots of support from the > community to work on this, I've asked Kurt Zeilenga and Peter > Saint-Andre to take over editing of the document. What comes next? Will they re-issue it? Will it be put up for adoption as an ietf document? Or do you want to go straight into comments on the I-D as is? Tom Petch > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From stpeter@stpeter.im Wed Jun 3 12:36:18 2009 Return-Path: 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 7D4A33A7063 for ; Wed, 3 Jun 2009 12:36:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.277 X-Spam-Level: X-Spam-Status: No, score=-2.277 tagged_above=-999 required=5 tests=[AWL=-0.322, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, J_CHICKENPOX_35=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 qCtrsjvON+RJ for ; Wed, 3 Jun 2009 12:36:17 -0700 (PDT) Received: from mailhost.dizzyd.com (dizzyd.com [207.210.219.225]) by core3.amsl.com (Postfix) with ESMTP id 8F1F53A7057 for ; Wed, 3 Jun 2009 12:36:17 -0700 (PDT) Received: from dhcp-64-101-72-227.cisco.com (dhcp-64-101-72-227.cisco.com [64.101.72.227]) (Authenticated sender: stpeter) by mailhost.dizzyd.com (Postfix) with ESMTPSA id CA9E240C7C; Wed, 3 Jun 2009 13:36:13 -0600 (MDT) Message-ID: <4A268C18.2010204@stpeter.im> Date: Wed, 03 Jun 2009 08:43:36 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: "tom.petch" Subject: Re: TLS server identity verification References: <49E58EA2.6050200@isode.com> <4A24ECD0.8050706@isode.com> <000901c9e41d$898eee40$0601a8c0@allison> In-Reply-To: <000901c9e41d$898eee40$0601a8c0@allison> X-Enigmail-Version: 0.95.7 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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: , X-List-Received-Date: Wed, 03 Jun 2009 19:36:18 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 6/3/09 1:30 AM, tom.petch wrote: > ----- Original Message ----- > From: "Alexey Melnikov" > To: "Apps Discuss" > Cc: "=JeffH" > Sent: Tuesday, June 02, 2009 11:11 AM > Subject: Re: TLS server identity verification > > >> Alexey Melnikov wrote: >> >>> Folks, >>> The issue of a document describing recommended text/template for >>> server identity verification procedure came up again while talking >>> about advancing EPP. >>> >>> As an AD, I would really like for draft-hodges-server-ident-check to >>> be published as an RFC. And I know that Chris was keen on this as well. >>> Jeff/Bob, do you have any cycles to work on this? >> As I've heard no response from the authors and lots of support from the >> community to work on this, I've asked Kurt Zeilenga and Peter >> Saint-Andre to take over editing of the document. > > What comes next? > > Will they re-issue it? Will it be put up for adoption as an ietf document? > Or do you want to go straight into comments on the I-D as is? Kurt and I will work to produce an updated I-D soon, incorporating the ideas discussed on this list and taking into account text about this topic from other RFCs and I-Ds (XMPP, SIP, etc.). Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkomjBgACgkQNL8k5A2w/vzFgwCglq1eEba9jvEh1EDh2O/uCbeY bkQAoJ4zg+8uPc/S8x/9pmzzgN/YqIuV =oX1X -----END PGP SIGNATURE----- From alexey.melnikov@isode.com Wed Jun 3 12:39:58 2009 Return-Path: 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 0468D3A6976 for ; Wed, 3 Jun 2009 12:39:58 -0700 (PDT) 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 vaVZy0tIEnRk for ; Wed, 3 Jun 2009 12:39:56 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 5C6D13A6D0E for ; Wed, 3 Jun 2009 12:39:56 -0700 (PDT) Received: from [92.40.39.250] (92.40.39.250.sub.mbb.three.co.uk [92.40.39.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 3 Jun 2009 20:39:52 +0100 Message-ID: <4A26D160.5020409@isode.com> Date: Wed, 03 Jun 2009 20:39:13 +0100 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: "tom.petch" Subject: Re: TLS server identity verification References: <49E58EA2.6050200@isode.com> <4A24ECD0.8050706@isode.com> <000901c9e41d$898eee40$0601a8c0@allison> In-Reply-To: <000901c9e41d$898eee40$0601a8c0@allison> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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: , X-List-Received-Date: Wed, 03 Jun 2009 19:39:58 -0000 tom.petch wrote: >----- Original Message ----- >From: "Alexey Melnikov" >To: "Apps Discuss" >Cc: "=JeffH" >Sent: Tuesday, June 02, 2009 11:11 AM >Subject: Re: TLS server identity verification > > >>Alexey Melnikov wrote: >> >> >>>Folks, >>>The issue of a document describing recommended text/template for >>>server identity verification procedure came up again while talking >>>about advancing EPP. >>> >>>As an AD, I would really like for draft-hodges-server-ident-check to >>>be published as an RFC. And I know that Chris was keen on this as well. >>>Jeff/Bob, do you have any cycles to work on this? >>> >>> >>As I've heard no response from the authors and lots of support from the >>community to work on this, I've asked Kurt Zeilenga and Peter >>Saint-Andre to take over editing of the document. >> >> >What comes next? > >Will they re-issue it? Will it be put up for adoption as an ietf document? > > New editors told me that the first version is just going to be a refresh. Then they will work on updating it based on comments. >Or do you want to go straight into comments on the I-D as is? > > Feel free to post your comments here. (Unless this topic generates lots of traffic, I think it is Ok to discuss it on this mailing list.) From stpeter@stpeter.im Wed Jun 3 12:53:24 2009 Return-Path: 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 0AE4628C1CA for ; Wed, 3 Jun 2009 12:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, 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 BgbAMrKGKsPR for ; Wed, 3 Jun 2009 12:53:23 -0700 (PDT) Received: from mailhost.dizzyd.com (dizzyd.com [207.210.219.225]) by core3.amsl.com (Postfix) with ESMTP id 2C4ED28C189 for ; Wed, 3 Jun 2009 12:53:23 -0700 (PDT) Received: from dhcp-64-101-72-227.cisco.com (dhcp-64-101-72-227.cisco.com [64.101.72.227]) (Authenticated sender: stpeter) by mailhost.dizzyd.com (Postfix) with ESMTPSA id E023D40C7C; Wed, 3 Jun 2009 13:53:24 -0600 (MDT) Message-ID: <4A26D4B4.4080205@stpeter.im> Date: Wed, 03 Jun 2009 13:53:24 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Alexey Melnikov Subject: Re: TLS server identity verification References: <49E58EA2.6050200@isode.com> <4A24ECD0.8050706@isode.com> <000901c9e41d$898eee40$0601a8c0@allison> <4A26D160.5020409@isode.com> In-Reply-To: <4A26D160.5020409@isode.com> X-Enigmail-Version: 0.95.7 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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: , X-List-Received-Date: Wed, 03 Jun 2009 19:53:24 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 6/3/09 1:39 PM, Alexey Melnikov wrote: >> What comes next? >> >> Will they re-issue it? Will it be put up for adoption as an ietf >> document? >> >> > New editors told me that the first version is just going to be a > refresh. Then they will work on updating it based on comments. Correct. Kurt and I will work to post a refreshed version this week. Since it's only a refresh it won't take much time. :) Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkom1LMACgkQNL8k5A2w/vyR0gCdHOiBeMCvClfVjYkHczvyRmTM T9kAoKc53xCa3qQYHul8K0srYet3Os2I =MskV -----END PGP SIGNATURE----- From stpeter@stpeter.im Wed Jun 3 15:34:22 2009 Return-Path: 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 E6C9E3A6E3D for ; Wed, 3 Jun 2009 15:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.545 X-Spam-Level: X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.054, 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 w1lanHc1IM2M for ; Wed, 3 Jun 2009 15:34:22 -0700 (PDT) Received: from mailhost.dizzyd.com (dizzyd.com [207.210.219.225]) by core3.amsl.com (Postfix) with ESMTP id 1D7A43A6817 for ; Wed, 3 Jun 2009 15:34:22 -0700 (PDT) Received: from dhcp-64-101-72-227.cisco.com (dhcp-64-101-72-227.cisco.com [64.101.72.227]) (Authenticated sender: stpeter) by mailhost.dizzyd.com (Postfix) with ESMTPSA id B4D8B40C81 for ; Wed, 3 Jun 2009 16:34:19 -0600 (MDT) Message-ID: <4A26FA6A.2060902@stpeter.im> Date: Wed, 03 Jun 2009 16:34:18 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: "apps-discuss@ietf.org" Subject: [Fwd: I-D Action:draft-saintandre-tls-server-id-check-00.txt] X-Enigmail-Version: 0.95.7 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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: , X-List-Received-Date: Wed, 03 Jun 2009 22:34:23 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 FYI. All I did was update the references, change the title slightly, and update the authors. Feedback is welcome before we publish a version with more significant modifications. Peter - -------- Original Message -------- Subject: I-D Action:draft-saintandre-tls-server-id-check-00.txt Date: Wed, 3 Jun 2009 15:30:02 -0700 (PDT) From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Best Practices for Checking of Server Identities in the Context of Transport Layer Security (TLS) Author(s) : P. Saint-Andre, et al. Filename : draft-saintandre-tls-server-id-check-00.txt Pages : 7 Date : 2009-06-03 This document specifies the how an entity establishing a TLS connection, or other PKI-based interaction, with a server should verify the server identity. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-saintandre-tls-server-id-check-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkom+moACgkQNL8k5A2w/vwswwCg7/aYZjuMPLTJvzVo3ffUrHMs wX0AoOGD7WqEMgsULxDcyjnrYjxxRTn6 =dlZG -----END PGP SIGNATURE----- From simon@josefsson.org Thu Jun 4 01:29:31 2009 Return-Path: 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 612223A6A49 for ; Thu, 4 Jun 2009 01:29:31 -0700 (PDT) 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 22PFFTAm+hKR for ; Thu, 4 Jun 2009 01:29:30 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id CDBED3A69C4 for ; Thu, 4 Jun 2009 01:29:27 -0700 (PDT) Received: from mocca.josefsson.org (c80-216-29-127.bredband.comhem.se [80.216.29.127]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n548TIP9021940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 4 Jun 2009 10:29:24 +0200 From: Simon Josefsson To: Peter Saint-Andre Subject: Re: [Fwd: I-D Action:draft-saintandre-tls-server-id-check-00.txt] References: <4A26FA6A.2060902@stpeter.im> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:090604:stpeter@stpeter.im::jaJUppDpzhROiu3E:JqVv X-Hashcash: 1:22:090604:apps-discuss@ietf.org::q73lVQLDJjwN+Yes:Ekno Date: Thu, 04 Jun 2009 10:29:17 +0200 In-Reply-To: <4A26FA6A.2060902@stpeter.im> (Peter Saint-Andre's message of "Wed, 03 Jun 2009 16:34:18 -0600") Message-ID: <87ljo8s8pu.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.94 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "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: , X-List-Received-Date: Thu, 04 Jun 2009 08:29:31 -0000 Peter Saint-Andre writes: > FYI. All I did was update the references, change the title slightly, and > update the authors. Feedback is welcome before we publish a version with > more significant modifications. Generally, I agree a document like this is needed. Some suggestions: 1) Define all terminology in section 2. The term "reference identity" is defined in section 3 but used in other sections too. 2) Re 3.1, should the reference identity be considered a stored string wrt IDNA? As I understand what reference identity refers to, it seems like a query string to me. Thanks, /Simon From phoffman@imc.org Thu Jun 4 07:24:35 2009 Return-Path: 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 7122D28C100 for ; Thu, 4 Jun 2009 07:24:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=0.930, 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 XXFmULOOYZh3 for ; Thu, 4 Jun 2009 07:24:34 -0700 (PDT) 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 2DACF28C204 for ; Thu, 4 Jun 2009 07:24:22 -0700 (PDT) Received: from [10.1.3.183] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n54EOMHo052859 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 4 Jun 2009 07:24:23 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4A26FA6A.2060902@stpeter.im> References: <4A26FA6A.2060902@stpeter.im> Date: Thu, 4 Jun 2009 07:24:21 -0700 To: From: Paul Hoffman Subject: Deprecating DNS names in the subjectName in draft-saintandre-tls-server-id-check Content-Type: text/plain; charset="us-ascii" 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: , X-List-Received-Date: Thu, 04 Jun 2009 14:24:35 -0000 Greetings again. I would like to argue that, from a security perspective, we should not allow looking up DNS names in the subjecName in PKIX certificates in this document. Section 3.1 says: The server's identity may also be verified by comparing the reference identity to the Common Name (CN) [LDAP-SCHEMA] value in the leaf Relative Distinguished Name (RDN) of the subjectName field of the server's certificate. This comparison is performed using the rules for comparison of DNS names in Section 3.1.3.1, below, with the exception that no wildcard matching is allowed. Although the use of the Common Name value is existing practice, it is deprecated, and Certification Authorities are encouraged to provide subjectAltName values instead. Note that the TLS implementation may represent DNs in certificates according to X.500 or other conventions. For example, some X.500 implementations order the RDNs in a DN using a left-to-right (most significant to least significant) convention instead of LDAP's right-to-left convention. That ambiguity leads to a fairly trivial identity attack. There is no good reason for a CA to issue certificates with domain names in the subjectName, and lots of reasons for it not to. This document should prohibit checking domain names in the subjectName, and should say why. From cfinss@dial.pipex.com Fri Jun 5 07:31:52 2009 Return-Path: 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 6DF903A6C36 for ; Fri, 5 Jun 2009 07:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.412 X-Spam-Level: X-Spam-Status: No, score=-1.412 tagged_above=-999 required=5 tests=[AWL=-0.346, BAYES_05=-1.11, DATE_IN_PAST_03_06=0.044] 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 br-H8DeG+SoE for ; Fri, 5 Jun 2009 07:31:51 -0700 (PDT) Received: from mk-outboundfilter-2.mail.uk.tiscali.com (mk-outboundfilter-2.mail.uk.tiscali.com [212.74.114.38]) by core3.amsl.com (Postfix) with ESMTP id 341983A6C28 for ; Fri, 5 Jun 2009 07:31:51 -0700 (PDT) X-Trace: 220489532/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.22/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.22 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar0FAHzJKEo+vGkW/2dsb2JhbABEgmVSizXCPAiCNYFNBQ X-IronPort-AV: E=Sophos;i="4.41,312,1241391600"; d="scan'208";a="220489532" X-IP-Direction: IN Received: from 1cust22.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.22]) by smtp.pipex.tiscali.co.uk with SMTP; 05 Jun 2009 15:31:51 +0100 Message-ID: <00a101c9e5e1$d57840c0$0601a8c0@allison> From: "tom.petch" To: "Alexey Melnikov" , References: <49E58EA2.6050200@isode.com> <4A24ECD0.8050706@isode.com> <000901c9e41d$898eee40$0601a8c0@allison> <4A26D160.5020409@isode.com> Subject: Re: TLS server identity verification Date: Fri, 5 Jun 2009 12:26:45 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 14:31:52 -0000 ----- Original Message ----- From: "Alexey Melnikov" To: "tom.petch" Cc: "Apps Discuss" Sent: Wednesday, June 03, 2009 9:39 PM Subject: Re: TLS server identity verification > > > Feel free to post your comments here. > > (Unless this topic generates lots of traffic, I think it is Ok to > discuss it on this mailing list.) Scope; what should it be? The title is about identity checking in TLS; but that is not what it is about. The body is about PKI-based interactions. TLS has several methods for authenticating a server, of which certificates may be the commonest but is not the only one. On the other hand, PKI has uses outside TLS. So I don't like the title and I don't like the body:-) I would like the scope to be (server identity checking based on) - certificates and PKI - certificates without PKI - public keys with a title to match. This view is based on requirements arising from recent work on - syslog over TLS - netconf over TLS - snmp over SSH - syslog over DTLS. From Kurt.Zeilenga@Isode.com Fri Jun 5 08:14:13 2009 Return-Path: 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 9A0383A6965 for ; Fri, 5 Jun 2009 08:14:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.623 X-Spam-Level: X-Spam-Status: No, score=-1.623 tagged_above=-999 required=5 tests=[AWL=0.376, BAYES_00=-2.599, J_CHICKENPOX_35=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 xo9dmpcJ59pm for ; Fri, 5 Jun 2009 08:14:13 -0700 (PDT) Received: from boole.openldap.org (boole.openldap.org [IPv6:2001:4f8:3:ba:219:21ff:fe2f:68d5]) by core3.amsl.com (Postfix) with ESMTP id CFF9C3A68E5 for ; Fri, 5 Jun 2009 08:14:12 -0700 (PDT) Received: from [192.168.1.101] (75-141-233-128.dhcp.nv.charter.com [75.141.233.128] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.14.3/8.14.3) with ESMTP id n55FEANP016954 for ; Fri, 5 Jun 2009 15:14:12 GMT (envelope-from Kurt.Zeilenga@Isode.com) Message-Id: <927AA151-048C-40AD-A83B-F9C7FD5C9755@Isode.com> From: Kurt Zeilenga To: Apps Discuss In-Reply-To: <00a101c9e5e1$d57840c0$0601a8c0@allison> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: TLS server identity verification X-Priority: 3 Date: Fri, 5 Jun 2009 08:14:10 -0700 References: <49E58EA2.6050200@isode.com> <4A24ECD0.8050706@isode.com> <000901c9e41d$898eee40$0601a8c0@allison> <4A26D160.5020409@isode.com> <00a101c9e5e1$d57840c0$0601a8c0@allison> X-Mailer: Apple Mail (2.935.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: , X-List-Received-Date: Fri, 05 Jun 2009 15:14:13 -0000 On Jun 5, 2009, at 3:26 AM, tom.petch wrote: > Scope; what should it be? Very good question. My personal opinion is that the document should provide a "cookbook" that can be used in creating procedures for TLS server identity verification in application protocol technical specifications. Currently, each application protocol technical specification which provides for TLS is to include procedures for TLS server identity verification. It is desirable to have some commonality between the methods. However, as not every way to verify the TLS server identity is applicable to every application protocol which uses TLS, I do not think it feasible to develop a "generic" procedure (as the previous title suggested). I suggest instead the title "TLS Server Identity Verification in Application Protocols", for the document to discuss various ways for TLS server identity verification to be done and be organized such that application protocol specifications can easily "profile" this document in order to specify the application protocol specific procedure. I think the document should be targeted for the Standard Track. I also think it would be useful to have a document indicating which ways are "best current practice", but thinking this might be better placed in a separate document. I do think the document should be narrowly focus on TLS server identity verification with X.509 certificates. I don't mind having a title which indicates this narrow focus, but am also fine with a title which leaves the "with X.509 certificates" aspect implicit. -- Kurt From alexey.melnikov@isode.com Fri Jun 5 08:24:41 2009 Return-Path: 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 A68823A6808 for ; Fri, 5 Jun 2009 08:24:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.655 X-Spam-Level: X-Spam-Status: No, score=-2.655 tagged_above=-999 required=5 tests=[AWL=-0.056, 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 agnwWKgcEL+B for ; Fri, 5 Jun 2009 08:24:41 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id DEC923A67F8 for ; Fri, 5 Jun 2009 08:24:40 -0700 (PDT) Received: from [172.16.2.167] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 5 Jun 2009 16:24:42 +0100 Message-ID: <4A293895.1050409@isode.com> Date: Fri, 05 Jun 2009 16:24:05 +0100 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: "tom.petch" Subject: Re: TLS server identity verification References: <49E58EA2.6050200@isode.com> <4A24ECD0.8050706@isode.com> <000901c9e41d$898eee40$0601a8c0@allison> <4A26D160.5020409@isode.com> <00a101c9e5e1$d57840c0$0601a8c0@allison> In-Reply-To: <00a101c9e5e1$d57840c0$0601a8c0@allison> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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: , X-List-Received-Date: Fri, 05 Jun 2009 15:24:41 -0000 Hi Tom, tom.petch wrote: >I would like the scope to be (server identity checking based on) >- certificates and PKI >- certificates without PKI >- public keys >with a title to match. > >This view is based on requirements arising from recent work on >- syslog over TLS >- netconf over TLS >- snmp over SSH >- syslog over DTLS. > > With my individual contributor hat on, I would rather concentrate on TLS (and maybe DTLS) server identity verification. If am ambivalent about non X.509 TLS certificates. From cfinss@dial.pipex.com Fri Jun 5 10:36:17 2009 Return-Path: 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 5527E3A69E3 for ; Fri, 5 Jun 2009 10:36:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, J_CHICKENPOX_35=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 vGDPl9HbRSAF for ; Fri, 5 Jun 2009 10:36:16 -0700 (PDT) Received: from mk-outboundfilter-6.mail.uk.tiscali.com (mk-outboundfilter-6.mail.uk.tiscali.com [212.74.114.14]) by core3.amsl.com (Postfix) with ESMTP id 61C013A68D2 for ; Fri, 5 Jun 2009 10:36:16 -0700 (PDT) X-Trace: 110362904/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.202/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.202 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuIEANf0KEo+vGTK/2dsb2JhbACDKVKLNcITCII1gU0F X-IronPort-AV: E=Sophos;i="4.41,312,1241391600"; d="scan'208";a="110362904" X-IP-Direction: IN Received: from 1cust202.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.202]) by smtp.pipex.tiscali.co.uk with SMTP; 05 Jun 2009 18:36:03 +0100 Message-ID: <003001c9e5fb$90e134c0$0601a8c0@allison> From: "tom.petch" To: "Alexey Melnikov" References: <49E58EA2.6050200@isode.com> <4A24ECD0.8050706@isode.com> <000901c9e41d$898eee40$0601a8c0@allison> <4A26D160.5020409@isode.com> <00a101c9e5e1$d57840c0$0601a8c0@allison> <4A293895.1050409@isode.com> Subject: Re: TLS server identity verification Date: Fri, 5 Jun 2009 18:34:50 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 17:36:17 -0000 ----- Original Message ----- From: "Alexey Melnikov" To: "tom.petch" Cc: "Apps Discuss" Sent: Friday, June 05, 2009 5:24 PM > Hi Tom, > > tom.petch wrote: > > >I would like the scope to be (server identity checking based on) > >- certificates and PKI > >- certificates without PKI > >- public keys > >with a title to match. > > > >This view is based on requirements arising from recent work on > >- syslog over TLS > >- netconf over TLS > >- snmp over SSH > >- syslog over DTLS. > > > > > With my individual contributor hat on, I would rather concentrate on TLS > (and maybe DTLS) server identity verification. If am ambivalent about > non X.509 TLS certificates. I had hoped that DTLS would be taken as read, since I see little or no difference in the identity checking. I would like to include X.509 certificates without PKI, as in eg RFC 5425 TLS Transport Mapping for Syslog. I think that the costs or hassle of PKI that inhibit deployment. Tom Petch > From phoffman@imc.org Fri Jun 5 11:51:07 2009 Return-Path: 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 3BE4E3A6B67 for ; Fri, 5 Jun 2009 11:51:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.834 X-Spam-Level: X-Spam-Status: No, score=-1.834 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, J_CHICKENPOX_35=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 lSNCR89XQeWt for ; Fri, 5 Jun 2009 11:51:06 -0700 (PDT) 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 13C4D3A6A50 for ; Fri, 5 Jun 2009 11:51:05 -0700 (PDT) Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n55Ip6Ih048091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 5 Jun 2009 11:51:07 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <00a101c9e5e1$d57840c0$0601a8c0@allison> References: <49E58EA2.6050200@isode.com> <4A24ECD0.8050706@isode.com> <000901c9e41d$898eee40$0601a8c0@allison> <4A26D160.5020409@isode.com> <00a101c9e5e1$d57840c0$0601a8c0@allison> Date: Fri, 5 Jun 2009 11:51:05 -0700 To: Apps Discuss From: Paul Hoffman Subject: Re: TLS server identity verification Content-Type: text/plain; charset="us-ascii" 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: , X-List-Received-Date: Fri, 05 Jun 2009 18:51:07 -0000 At 12:26 PM +0200 6/5/09, tom.petch wrote: >I would like the scope to be (server identity checking based on) >- certificates and PKI >- certificates without PKI >- public keys >with a title to match. I would prefer the scope to be "certificates with PKIX certificates" with TLS as an example that runs through the document. The discussion should *not* try to span to other protocols; in specific, IPsec has its own document on how to use PKIX certificates with IKE (which is tortured and burdened with dark history). Also, there are only two IETF certificates other than PKIX: SPKI has seen essentially no implementation, and OpenPGP is a certificate format but no PKI to support it. I suggest that neither of these need to have a document such as this for them. From Nicolas.Williams@sun.com Fri Jun 5 13:26:17 2009 Return-Path: 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 821FD3A6CC0 for ; Fri, 5 Jun 2009 13:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.746 X-Spam-Level: X-Spam-Status: No, score=-5.746 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_35=0.6, 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 ot73RM71PpaM for ; Fri, 5 Jun 2009 13:26:16 -0700 (PDT) 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 DCB7C3A6C6A for ; Fri, 5 Jun 2009 13:26:15 -0700 (PDT) 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 n55KQImi025500 for ; Fri, 5 Jun 2009 20:26:19 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 n55KQIjH006255 for ; Fri, 5 Jun 2009 14:26:18 -0600 (MDT) 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 n55KGNpa003109; Fri, 5 Jun 2009 15:16:23 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n55KGI00003108; Fri, 5 Jun 2009 15:16:18 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 5 Jun 2009 15:16:17 -0500 From: Nicolas Williams To: "tom.petch" Subject: Re: TLS server identity verification Message-ID: <20090605201617.GF1049@Sun.COM> References: <49E58EA2.6050200@isode.com> <4A24ECD0.8050706@isode.com> <000901c9e41d$898eee40$0601a8c0@allison> <4A26D160.5020409@isode.com> <00a101c9e5e1$d57840c0$0601a8c0@allison> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00a101c9e5e1$d57840c0$0601a8c0@allison> User-Agent: Mutt/1.5.7i Cc: psaintan@cisco.com, 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: , X-List-Received-Date: Fri, 05 Jun 2009 20:26:17 -0000 On Fri, Jun 05, 2009 at 12:26:45PM +0200, tom.petch wrote: > Scope; what should it be? > > The title is about identity checking in TLS; but that is not what it is about. > The body is about PKI-based interactions. > > TLS has several methods for authenticating a server, of which certificates may > be the commonest but is not the only one. > > On the other hand, PKI has uses outside TLS. > > So I don't like the title and I don't like the body:-) > > I would like the scope to be (server identity checking based on) > - certificates and PKI > - certificates without PKI > - public keys > with a title to match. I think it'd be fine to have a separate document for each of the above. > This view is based on requirements arising from recent work on > - syslog over TLS > - netconf over TLS > - snmp over SSH > - syslog over DTLS. Well, ideally RFC3280 should suffice. In practice, in the HTTP world, people do things that require more text than RFC3280 has in order to verify server identities. So I'd like to see a focus on describing actual practice only, and then primarily (if not only) in the context of HTTP. If other protocols also do things outside RFC3280, then let's have separate documents for those _unless_ those documents are either going to be copies of this one, or could be made a single page addition to this one. Nico -- From alexey.melnikov@isode.com Fri Jun 5 15:42:59 2009 Return-Path: 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 8CE9E3A6930 for ; Fri, 5 Jun 2009 15:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 HBr-9JV2l+3V for ; Fri, 5 Jun 2009 15:42:58 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 6C19B3A67ED for ; Fri, 5 Jun 2009 15:42:58 -0700 (PDT) Received: from [94.197.221.233] (94.197.221.233.threembb.co.uk [94.197.221.233]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 5 Jun 2009 23:42:59 +0100 Message-ID: <4A299F4C.2000003@isode.com> Date: Fri, 05 Jun 2009 23:42:20 +0100 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: Paul Hoffman Subject: Re: Deprecating DNS names in the subjectName in draft-saintandre-tls-server-id-check References: <4A26FA6A.2060902@stpeter.im> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: 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: , X-List-Received-Date: Fri, 05 Jun 2009 22:42:59 -0000 Hi Paul, Paul Hoffman wrote: >Greetings again. I would like to argue that, from a security perspective, we should not allow looking up DNS names in the subjectName in PKIX certificates in this document. Section 3.1 says: > The server's identity may also be verified by comparing the reference > identity to the Common Name (CN) [LDAP-SCHEMA] value in the leaf > Relative Distinguished Name (RDN) of the subjectName field of the > server's certificate. This comparison is performed using the rules > for comparison of DNS names in Section 3.1.3.1, below, with the > exception that no wildcard matching is allowed. Although the use of > the Common Name value is existing practice, it is deprecated, and > Certification Authorities are encouraged to provide subjectAltName > values instead. Note that the TLS implementation may represent DNs > in certificates according to X.500 or other conventions. For > example, some X.500 implementations order the RDNs in a DN using a > left-to-right (most significant to least significant) convention > instead of LDAP's right-to-left convention. > >That ambiguity leads to a fairly trivial identity attack. > Can you elaborate on this? (A pointer to discussion elsewhere would be fine as well.) >There is no good reason for a CA to issue certificates with domain names in the subjectName, and lots of reasons for it not to. > I think the current reality is that many of CAs still do that without supporting DNS name in the subjectAltName. >This document should prohibit checking domain names in the subjectName, and should say why. > From simon@josefsson.org Sat Jun 6 03:37:59 2009 Return-Path: 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 09D143A6830 for ; Sat, 6 Jun 2009 03:37:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_35=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 lEo562kJOLn1 for ; Sat, 6 Jun 2009 03:37:53 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id CAE323A6A78 for ; Sat, 6 Jun 2009 03:37:52 -0700 (PDT) Received: from mocca.josefsson.org (m90-137-71-72.cust.tele2.se [90.137.71.72]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5) with ESMTP id n56Abi2X015894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 6 Jun 2009 12:37:51 +0200 From: Simon Josefsson To: Paul Hoffman Subject: Re: TLS server identity verification References: <49E58EA2.6050200@isode.com> <4A24ECD0.8050706@isode.com> <000901c9e41d$898eee40$0601a8c0@allison> <4A26D160.5020409@isode.com> <00a101c9e5e1$d57840c0$0601a8c0@allison> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:090606:phoffman@imc.org::N5904EyriGLBvTJu:OIQX X-Hashcash: 1:22:090606:discuss@apps.ietf.org::trhGAc7NO1yXGwby:dG1L Date: Sat, 06 Jun 2009 12:37:43 +0200 In-Reply-To: (Paul Hoffman's message of "Fri\, 5 Jun 2009 11\:51\:05 -0700") Message-ID: <87prdhk5qg.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.94 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: , X-List-Received-Date: Sat, 06 Jun 2009 10:37:59 -0000 Paul Hoffman writes: > At 12:26 PM +0200 6/5/09, tom.petch wrote: >>I would like the scope to be (server identity checking based on) >>- certificates and PKI >>- certificates without PKI >>- public keys >>with a title to match. > > I would prefer the scope to be "certificates with PKIX certificates" with TLS as an example that runs through the document. The discussion should *not* try to span to other protocols; in specific, IPsec has its own document on how to use PKIX certificates with IKE (which is tortured and burdened with dark history). > > Also, there are only two IETF certificates other than PKIX: SPKI has seen essentially no implementation, and OpenPGP is a certificate format but no PKI to support it. I suggest that neither of these need to have a document such as this for them. Actually, for OpenPGP used in TLS a document like that would be useful. RFC 5081 doesn't discuss naming or verification or names. /Simon From phoffman@imc.org Sat Jun 6 07:51:14 2009 Return-Path: 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 DB7413A6830 for ; Sat, 6 Jun 2009 07:51:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, J_CHICKENPOX_32=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 FSMIZW2uxPMV for ; Sat, 6 Jun 2009 07:51:13 -0700 (PDT) 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 6E8033A67B3 for ; Sat, 6 Jun 2009 07:51:13 -0700 (PDT) Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n56EpDa5093704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 6 Jun 2009 07:51:15 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4A299F4C.2000003@isode.com> References: <4A26FA6A.2060902@stpeter.im> <4A299F4C.2000003@isode.com> Date: Sat, 6 Jun 2009 07:51:12 -0700 To: Alexey Melnikov From: Paul Hoffman Subject: Re: Deprecating DNS names in the subjectName in draft-saintandre-tls-server-id-check Content-Type: text/plain; charset="us-ascii" Cc: 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: , X-List-Received-Date: Sat, 06 Jun 2009 14:51:14 -0000 At 11:42 PM +0100 6/5/09, Alexey Melnikov wrote: >Hi Paul, > >Paul Hoffman wrote: > >>Greetings again. I would like to argue that, from a security perspective, we should not allow looking up DNS names in the subjectName in PKIX certificates in this document. Section 3.1 says: >> The server's identity may also be verified by comparing the reference >> identity to the Common Name (CN) [LDAP-SCHEMA] value in the leaf >> Relative Distinguished Name (RDN) of the subjectName field of the >> server's certificate. This comparison is performed using the rules >> for comparison of DNS names in Section 3.1.3.1, below, with the >> exception that no wildcard matching is allowed. Although the use of >> the Common Name value is existing practice, it is deprecated, and >> Certification Authorities are encouraged to provide subjectAltName >> values instead. Note that the TLS implementation may represent DNs >> in certificates according to X.500 or other conventions. For >> example, some X.500 implementations order the RDNs in a DN using a >> left-to-right (most significant to least significant) convention >> instead of LDAP's right-to-left convention. >> >>That ambiguity leads to a fairly trivial identity attack. >> >Can you elaborate on this? (A pointer to discussion elsewhere would be fine as well.) If there is a TLD that has the same name as the SLD that you want to attack, you can get a certificate that uses the CNs. For example, if you want to attack ar.com, you could register com.ar, get a certificate for it, and use it to fool systems that follow the rule in the last sentence above. This attack will get easier as more TLDs with names that exist as current SLDs are created in the coming years. >>There is no good reason for a CA to issue certificates with domain names in the subjectName, and lots of reasons for it not to. >> >I think the current reality is that many of CAs still do that without supporting DNS name in the subjectAltName. Probably. Are you saying that the fact that they are doing this knowingly insecurely should stop us from prohibiting it in this profile? This profile is supposed to be a way to codify secure authentication practice. Saying "but there are CAs who do it wrong and you should validate their certificates anyway" seems counterproductive. From phoffman@imc.org Sat Jun 6 07:53:20 2009 Return-Path: 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 7185D3A68E0 for ; Sat, 6 Jun 2009 07:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, J_CHICKENPOX_35=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 1nPYZ4VXrjDN for ; Sat, 6 Jun 2009 07:53:19 -0700 (PDT) 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 69D4A3A6830 for ; Sat, 6 Jun 2009 07:53:19 -0700 (PDT) Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n56ErH8p093787 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 6 Jun 2009 07:53:18 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <87prdhk5qg.fsf@mocca.josefsson.org> References: <49E58EA2.6050200@isode.com> <4A24ECD0.8050706@isode.com> <000901c9e41d$898eee40$0601a8c0@allison> <4A26D160.5020409@isode.com> <00a101c9e5e1$d57840c0$0601a8c0@allison> <87prdhk5qg.fsf@mocca.josefsson.org> Date: Sat, 6 Jun 2009 07:53:15 -0700 To: Simon Josefsson From: Paul Hoffman Subject: Re: TLS server identity verification Content-Type: text/plain; charset="us-ascii" 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: , X-List-Received-Date: Sat, 06 Jun 2009 14:53:20 -0000 At 12:37 PM +0200 6/6/09, Simon Josefsson wrote: >Paul Hoffman writes: > >> At 12:26 PM +0200 6/5/09, tom.petch wrote: >>>I would like the scope to be (server identity checking based on) >>>- certificates and PKI >>>- certificates without PKI >>>- public keys >>>with a title to match. >> >> I would prefer the scope to be "certificates with PKIX certificates" with TLS as an example that runs through the document. The discussion should *not* try to span to other protocols; in specific, IPsec has its own document on how to use PKIX certificates with IKE (which is tortured and burdened with dark history). >> >> Also, there are only two IETF certificates other than PKIX: SPKI has seen essentially no implementation, and OpenPGP is a certificate format but no PKI to support it. I suggest that neither of these need to have a document such as this for them. > >Actually, for OpenPGP used in TLS a document like that would be useful. >RFC 5081 doesn't discuss naming or verification or names. That's exactly my point. There is an experimental RFC with poor semantics, and a base standard RFC with no PKI. This doesn't seem like a useful foundation for specification that is supposed to help interoperability. From lisa.dusseault@gmail.com Sat Jun 6 17:56:23 2009 Return-Path: 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 A5E863A685D for ; Sat, 6 Jun 2009 17:56:23 -0700 (PDT) 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 QJCO0I4IbOeX for ; Sat, 6 Jun 2009 17:56:22 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by core3.amsl.com (Postfix) with ESMTP id 7F0F93A6452 for ; Sat, 6 Jun 2009 17:56:22 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 3so1671959qwe.31 for ; Sat, 06 Jun 2009 17:56:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=3OhBnm1ph6ZrVJVd3DzehfROqA7TnO7uiUT29VfprHw=; b=gvVW/mBw8jig0eZ6C9gO6kq6UXdQ39A6gkuVgy1l1x+pQ8R/9e63d5PEcTv7+uLgJm sB6x/klCwcO0o3ye6nFU6DYX+sB3efqygeG+TvDmhoc3idU4sgeN61R2h+CnhwMTiKvW +iw3pBRTLFOR3129tenpKokuLEKyG8FIPcX28= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=w3UVTtJt9qZp2JsjzvcAxOF48bpxqvmuVj8wFzPZiJbJHjbC7ZDUv6mbLqMOvnn+1j Weefy7eHDTQ+US16uderytSlWOnB/tyskMP+DHr4U5ZLp92yby70X6wPAAdxYgfhuUtb A7M0mL353ekCWNZnaIeBOCtrjg1UtfZaHKFUE= MIME-Version: 1.0 Received: by 10.220.91.138 with SMTP id n10mr3022438vcm.76.1244336184523; Sat, 06 Jun 2009 17:56:24 -0700 (PDT) Date: Sat, 6 Jun 2009 17:56:24 -0700 Message-ID: Subject: Lisa's Apps Area Activity Report for Jun 2009 From: Lisa Dusseault To: discuss@ietf.org, lisa-dusseault-chairs@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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: , X-List-Received-Date: Sun, 07 Jun 2009 00:56:23 -0000 News, Updates - OAUTH approved - OGPX: Proposed BOF on virtual worlds interoperability, more specific than= MMOX - IRI revision activity: please join public-iri@w3.org Document Status and Progress Active documents, my action: - draft-ietf-calsify-2446bis (PS): checking with chair on whether the Last Call issues were dealt with - draft-montemurro-gsma-imei-urn (Exp): New version of draft that I need to review Active documents, waiting on other: - draft-reschke-webdav-post (Exp): Cyrus Daboo is doing shepherd review and writeup - draft-ietf-sieve-mime-loop (PS): Waiting on authors to respond to GenArt review =A0-draft-livingood-woundy-p4p-experiences (Info): In Last Call Finished processing -- new in RFC Ed queue and new RFCs - none WG Status ALTO: Started WG Last Call on problem statement draft. CALSIFY: Not much WG action HTTPBIS: Discussion on redirects, accept headers, other issues IDNABIS: =A0New draft on mapping: http://tools.ietf.org/html/draft-ietf-idnabis-mappings-00 OAUTH: Launching work as a Working Group - discussing document organization SIEVE: =A0SIEVE-in-XML and sieve-include discussions From alexey.melnikov@isode.com Sun Jun 7 02:48:53 2009 Return-Path: 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 5BF4A3A69C3 for ; Sun, 7 Jun 2009 02:48:53 -0700 (PDT) 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=[AWL=0.000, 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 Vmot4OJ9FcQ2 for ; Sun, 7 Jun 2009 02:48:52 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id E5ECB3A68FE for ; Sun, 7 Jun 2009 02:48:51 -0700 (PDT) Received: from [92.40.185.195] (92.40.185.195.sub.mbb.three.co.uk [92.40.185.195]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 7 Jun 2009 10:48:54 +0100 Message-ID: <4A2B8CCB.4070803@isode.com> Date: Sun, 07 Jun 2009 10:47:55 +0100 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 , alexey-melnikov-chairs@tools.ietf.org Subject: Alexey's Apps Area Activity Report for May 2009 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: quoted-printable 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: , X-List-Received-Date: Sun, 07 Jun 2009 09:48:53 -0000 Please let me know if you think the information below is not accurate. =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 Document Status and Progress Active documents, my action: - draft-duerst-mailto-bis - promised Martin D=FCrst to review this document - draft-ietf-sasl-scram (my own document) - need to update as per discussion on channel bindings this week. Active documents in IETF LC or IESG review: - draft-hollenbeck-rfc493*bis - in IETF LC - draft-ietf-webdav-bind (Experimental) - need to address 3 DISCUSSes (Adrian, Robert, Cullen), in particular about the document "updating the base WebDAV spec". Approved for publication: - draft-ncook-urlauth-accessid (Proposed Standard) - draft-thomson-beep-async (Proposed Standard): was downdgraded to Experimental - draft-crocker-email-arch (Standard Track): approved as Informational - draft-ietf-lemonade-notifications (Informational): need to add some RFC Editor notes before the approval announcement can be sent Active documents, waiting on other: - draft-ietf-ltru-4646bis (BCP) - IETF LC ended, waiting for a new revision addressing my comments raised in AD review and in Apps Review Team review - draft-ietf-ltru-4645bis (Informational): IETF LC ended, waiting for update to draft-ietf-ltru-4646bis before sending both to IESG for review - draft-ietf-lemonade-streaming (Informational): 1 DISCUSSes remaining on the document (from Cullen). Waiting for Cullen to review. - draft-dusseault-http-patch: AD review is done, waiting for the shepherding write-up before requesting IETF LC List of DISCUSSes I am currently holding: Old: draft-ietf-bfd-base-09.txt draft-ietf-ipfix-exporting-type-04.txt draft-ietf-ntp-ntpv4-proto-11.txt draft-ietf-ipfix-file-03.txt draft-mraihi-inch-thraud-08.txt New (this week): draft-ietf-mmusic-sdp-capability-negotiation-10.txt draft-ietf-avt-seed-srtp-11.txt Other activities/actions: Done: - YAM (Yet Another Mail) WG was chartered - IESG discussion on NomCom requirements - Answered a couple of questions from IANA about various IANA registries (RFC 2244, RFC 3191) - Cyrus Daboo has posted draft-daboo-srv-email-00.txt and draft-daboo-srv-caldav-00.txt (how to discover location of an email servers/CalDAV server), I've reviewed the first one. Ongoing: - Negotiating resolution with LTRU WG of various issues raised by my AD=20 review and an Apps Review Team review - Request to review 3 new MIME type registrations (some activity on the first 2): - Request for registration for 3gpp-ims+xml: ongoing private discussion with authors of the registration - Request for registration for application/mp21 from ISO/IEC 21000-9:2005/Amd.1:2008: need to followup - Request for registration for multiple MIME types () from Library of Congress: need to advise on the best way forward with this. - TLS server identity check document was posted. Some discussion on the Apps Discuss mailing list My action: - Need to review OAuth document regarding possible reuse of SCRAM - Need to post 4954bis (SMTP AUTH) in order to start moving it to Draft Standard Waiting for others: - Suggestion to move LMTP to Standard Track (Ned Freed agreed to update the document, Chris Newman agreed to shepherd it) - Suggestion to convert MIME BNF to ABNF and publish as a separate draft (Ned Freed agreed to do this) WG Status: 1) EAI - waiting for the WG to finish POP3 and IMAP drafts. Some=20 discussion about what to do next on the mailing list 2) Lemonade [In shutting down state] - Pushing dependencies for the Lemonade Profile Bis out of the door (draft-ietf-sasl-scram-01.txt, QRESYNC (draft-ietf-lemonade-5162bis-00.txt)). One informational document is approved (Lemonade Notifications). Lemonade Streaming has an outstanding DISCUSS. 3) LTRU - Lots of discussions about resolving my AD review and Apps=20 Review Team review. 4) MORG - WGLC for 1 document has ended 5) VCARDDAV - Discussion about encoding Geo related information in=20 vCards, some discussion about LDAP mapping for vCards. From john-ietf@jck.com Sun Jun 7 11:27:18 2009 Return-Path: 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 784E83A6D29 for ; Sun, 7 Jun 2009 11:27:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.059 X-Spam-Level: X-Spam-Status: No, score=-2.059 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_00=-2.599, J_CHICKENPOX_36=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 YXQfaRbX2nWx for ; Sun, 7 Jun 2009 11:27:17 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 311DD3A68DF for ; Sun, 7 Jun 2009 11:27:17 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1MDN5S-000HgG-US; Sun, 07 Jun 2009 14:27:19 -0400 Date: Sun, 07 Jun 2009 14:27:18 -0400 From: John C Klensin To: Alexey Melnikov , Paul Hoffman Subject: Re: Deprecating DNS names in the subjectName in draft-saintandre-tls-server-id-check Message-ID: <3AA87721010E19AEC7C5875E@[0.1.0.4]> In-Reply-To: <4A299F4C.2000003@isode.com> References: <4A26FA6A.2060902@stpeter.im> <4A299F4C.2000003@isode.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: 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: , X-List-Received-Date: Sun, 07 Jun 2009 18:27:18 -0000 Alexey, I'll let Paul supply the references and details (although I'd be happy to collaborate with him if needed and if neither of you are in a hurry), but, fwiw, I basically agree with his reasoning as expressed in this and other notes. We've created flexibilities that can, with the help (intentional or otherwise) of top-level and root registries, render the names ambiguous and hence subject to attack. With the apparent ICANN intention of treating the root zone strictly as a market-driven activity and to exercise little or no control over the behavior of TLD registries, the opportunity to have (to take an entirely fanciful example) com.berlin as well as berlin.com appears to be just a matter of time and revenue stream to ICANN... with no processes in place to require that they be under the same control. An alternative to Paul's proposal to simply deprecate domain names in this context would be to require that they all be explicitly root-anchored, i.e., that "com.berlin" would be invalid, but "com.berlin." would be permitted. But my suspicion is that convention would be neither honored nor effective, especially since that convention has no obvious X.500 DN equivalent. john --On Friday, June 05, 2009 23:42 +0100 Alexey Melnikov wrote: > Hi Paul, > > Paul Hoffman wrote: > >> Greetings again. I would like to argue that, from a security >> perspective, we should not allow looking up DNS names in the >> subjectName in PKIX certificates in this document. Section >> 3.1 says: The server's identity may also be verified by >> comparing the reference identity to the Common Name (CN) >> [LDAP-SCHEMA] value in the leaf Relative Distinguished Name >> (RDN) of the subjectName field of the server's certificate. >> This comparison is performed using the rules for comparison >> of DNS names in Section 3.1.3.1, below, with the exception >> that no wildcard matching is allowed. Although the use of >> the Common Name value is existing practice, it is >> deprecated, and Certification Authorities are encouraged to >> provide subjectAltName values instead. Note that the TLS >> implementation may represent DNs in certificates according >> to X.500 or other conventions. For example, some X.500 >> implementations order the RDNs in a DN using a >> left-to-right (most significant to least significant) >> convention instead of LDAP's right-to-left convention. >> >> That ambiguity leads to a fairly trivial identity attack. >> > Can you elaborate on this? (A pointer to discussion elsewhere > would be fine as well.) > >> There is no good reason for a CA to issue certificates with >> domain names in the subjectName, and lots of reasons for it >> not to. >> > I think the current reality is that many of CAs still do that > without supporting DNS name in the subjectAltName. > >> This document should prohibit checking domain names in the >> subjectName, and should say why. >> > > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From alexey.melnikov@isode.com Sun Jun 7 12:32:20 2009 Return-Path: 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 AE76E3A6D6C for ; Sun, 7 Jun 2009 12:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[AWL=-1.200, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_22=0.6, J_CHICKENPOX_23=0.6, J_CHICKENPOX_32=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 HNLjSvmU6eKC for ; Sun, 7 Jun 2009 12:32:19 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 61F043A6D6B for ; Sun, 7 Jun 2009 12:32:19 -0700 (PDT) Received: from [92.40.185.195] (92.40.185.195.sub.mbb.three.co.uk [92.40.185.195]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 7 Jun 2009 20:32:21 +0100 Message-ID: <4A2C1577.6060802@isode.com> Date: Sun, 07 Jun 2009 20:31:03 +0100 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: Paul Hoffman , "Kurt D. Zeilenga" Subject: Re: Deprecating DNS names in the subjectName in draft-saintandre-tls-server-id-check References: <4A26FA6A.2060902@stpeter.im> <4A299F4C.2000003@isode.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 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: , X-List-Received-Date: Sun, 07 Jun 2009 19:32:20 -0000 Paul Hoffman wrote: >At 11:42 PM +0100 6/5/09, Alexey Melnikov wrote: > > >>Hi Paul, >> >>Paul Hoffman wrote: >> >> >>>Greetings again. I would like to argue that, from a security perspective, we should not allow looking up DNS names in the subjectName in PKIX certificates in this document. Section 3.1 says: >>> The server's identity may also be verified by comparing the reference >>> identity to the Common Name (CN) [LDAP-SCHEMA] value in the leaf >>> Relative Distinguished Name (RDN) of the subjectName field of the >>> server's certificate. This comparison is performed using the rules >>> for comparison of DNS names in Section 3.1.3.1, below, with the >>> exception that no wildcard matching is allowed. Although the use of >>> the Common Name value is existing practice, it is deprecated, and >>> Certification Authorities are encouraged to provide subjectAltName >>> values instead. Note that the TLS implementation may represent DNs >>> in certificates according to X.500 or other conventions. For >>> example, some X.500 implementations order the RDNs in a DN using a >>> left-to-right (most significant to least significant) convention >>> instead of LDAP's right-to-left convention. >>> >>>That ambiguity leads to a fairly trivial identity attack >>> >>Can you elaborate on this? (A pointer to discussion elsewhere would be fine as well.) >> >> >If there is a TLD that has the same name as the SLD that you want to attack, you can get a certificate that uses the CNs. For example, if you want to attack ar.com, you could register com.ar, get a certificate for it, and use it to fool systems that follow the rule in the last sentence above. This attack will get easier as more TLDs with names that exist as current SLDs are created in the coming years. > Paul, I missed your point entirely. Yes, this is indeed a concern. However I believe the text is talking about something else entirely. It is talking about order of Relative DNs (RDNs). For example, a subjectName for a domain might look like: cn=www.example.com, ou=Web Services, c=GB Here c=GB is the most significant RDN. What the text is saying is that some X.500 implementations would represent it as c=GB, ou=Web Services, cn=www.example.com or something like this. Kurt can probably explain this better than I can. So there is no reordering of domains inside the CN value. [As a side note, if the document were allowing use of DC (domain components) in subjectName, the problem you've identifier would have been relevant: dc=com, dc=ar, ou=Web Services, c=GB versa dc=ar, dc=com, ou=Web Services, c=GB ] From alexey.melnikov@isode.com Sun Jun 7 12:33:55 2009 Return-Path: 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 7850E3A6D54 for ; Sun, 7 Jun 2009 12:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.228 X-Spam-Level: X-Spam-Status: No, score=-2.228 tagged_above=-999 required=5 tests=[AWL=-0.229, BAYES_00=-2.599, J_CHICKENPOX_36=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 szG8ODqA2BVg for ; Sun, 7 Jun 2009 12:33:54 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 77EA03A6D4B for ; Sun, 7 Jun 2009 12:33:54 -0700 (PDT) Received: from [92.40.185.195] (92.40.185.195.sub.mbb.three.co.uk [92.40.185.195]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 7 Jun 2009 20:33:57 +0100 Message-ID: <4A2C15E1.6070207@isode.com> Date: Sun, 07 Jun 2009 20:32:49 +0100 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: John C Klensin Subject: Re: Deprecating DNS names in the subjectName in draft-saintandre-tls-server-id-check References: <4A26FA6A.2060902@stpeter.im> <4A299F4C.2000003@isode.com> <3AA87721010E19AEC7C5875E@[0.1.0.4]> In-Reply-To: <3AA87721010E19AEC7C5875E@[0.1.0.4]> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Paul Hoffman , 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: , X-List-Received-Date: Sun, 07 Jun 2009 19:33:55 -0000 John C Klensin wrote: >Alexey, > >I'll let Paul supply the references and details (although I'd be >happy to collaborate with him if needed and if neither of you >are in a hurry), but, fwiw, I basically agree with his reasoning >as expressed in this and other notes. We've created >flexibilities that can, with the help (intentional or otherwise) >of top-level and root registries, render the names ambiguous and >hence subject to attack. With the apparent ICANN intention of >treating the root zone strictly as a market-driven activity and >to exercise little or no control over the behavior of TLD >registries, the opportunity to have (to take an entirely >fanciful example) com.berlin as well as berlin.com appears to be >just a matter of time and revenue stream to ICANN... with no >processes in place to require that they be under the same >control. > > Right. >An alternative to Paul's proposal to simply deprecate domain >names in this context would be to require that they all be >explicitly root-anchored, i.e., that "com.berlin" would be >invalid, but "com.berlin." would be permitted. But my suspicion >is that convention would be neither honored nor effective, >especially since that convention has no obvious X.500 DN >equivalent. > > Indeed. But as per my reply to Paul, I don't think this is actually an issue. From phoffman@imc.org Sun Jun 7 13:49:51 2009 Return-Path: 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 13A9E3A6B83 for ; Sun, 7 Jun 2009 13:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.333 X-Spam-Level: X-Spam-Status: No, score=-1.333 tagged_above=-999 required=5 tests=[AWL=-0.534, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_22=0.6, J_CHICKENPOX_23=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 7io03mYCnZ+u for ; Sun, 7 Jun 2009 13:49:50 -0700 (PDT) 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 1AD853A6B56 for ; Sun, 7 Jun 2009 13:49:49 -0700 (PDT) Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n57Knps8060833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 7 Jun 2009 13:49:52 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4A2C1577.6060802@isode.com> References: <4A26FA6A.2060902@stpeter.im> <4A299F4C.2000003@isode.com> <4A2C1577.6060802@isode.com> Date: Sun, 7 Jun 2009 13:35:07 -0700 To: Alexey Melnikov , "Kurt D. Zeilenga" From: Paul Hoffman Subject: Re: Deprecating DNS names in the subjectName in draft-saintandre-tls-server-id-check Content-Type: text/plain; charset="us-ascii" Cc: 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: , X-List-Received-Date: Sun, 07 Jun 2009 20:49:51 -0000 At 8:31 PM +0100 6/7/09, Alexey Melnikov wrote: >[As a side note, if the document were allowing use of DC (domain components) in subjectName, the problem you've identifier would have been relevant: >dc=com, dc=ar, ou=Web Services, c=GB >versa >dc=ar, dc=com, ou=Web Services, c=GB >] I am assuming that the problem is reordering of DC values. None of the others affect the matching discussed in this document. It is *completely* believable that some implementations string together the DC values in different orders. From alexey.melnikov@isode.com Mon Jun 8 03:09:58 2009 Return-Path: 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 830C03A6DDE for ; Mon, 8 Jun 2009 03:09:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.752 X-Spam-Level: X-Spam-Status: No, score=-1.752 tagged_above=-999 required=5 tests=[AWL=-0.953, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_22=0.6, J_CHICKENPOX_23=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 W+u8tPjoaa8X for ; Mon, 8 Jun 2009 03:09:57 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 87BC83A6DA7 for ; Mon, 8 Jun 2009 03:09:57 -0700 (PDT) Received: from [172.16.2.106] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 8 Jun 2009 11:10:01 +0100 Message-ID: <4A2CE34D.8060508@isode.com> Date: Mon, 08 Jun 2009 11:09:17 +0100 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: Paul Hoffman Subject: Re: Deprecating DNS names in the subjectName in draft-saintandre-tls-server-id-check References: <4A26FA6A.2060902@stpeter.im> <4A299F4C.2000003@isode.com> <4A2C1577.6060802@isode.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "Kurt D. Zeilenga" , 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: , X-List-Received-Date: Mon, 08 Jun 2009 10:09:58 -0000 Paul Hoffman wrote: >At 8:31 PM +0100 6/7/09, Alexey Melnikov wrote: > > >>[As a side note, if the document were allowing use of DC (domain components) in subjectName, the problem you've identifier would have been relevant: >>dc=com, dc=ar, ou=Web Services, c=GB >>versa >>dc=ar, dc=com, ou=Web Services, c=GB >>] >> >> >I am assuming that the problem is reordering of DC values. None of the others affect the matching discussed in this document. It is *completely* believable that some implementations string together the DC values in different orders. > > Right. Use of DC attributes is already disallowed by not being explicitly allowed. Of course the document needs to be clear on what it means about left-to-right RDN ordering versa right-to-left RDN ordering. So some text needs to be added to clarify, or the confusing sentence needs to be removed. From phoffman@imc.org Mon Jun 8 07:11:50 2009 Return-Path: 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 61BC73A6848 for ; Mon, 8 Jun 2009 07:11:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.144 X-Spam-Level: X-Spam-Status: No, score=-2.144 tagged_above=-999 required=5 tests=[AWL=0.455, 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 p8A9B8xWuwfU for ; Mon, 8 Jun 2009 07:11:49 -0700 (PDT) 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 58CBD3A6C21 for ; Mon, 8 Jun 2009 07:11:49 -0700 (PDT) Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58E2fK9002850 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jun 2009 07:02:42 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4A2CE34D.8060508@isode.com> References: <4A26FA6A.2060902@stpeter.im> <4A299F4C.2000003@isode.com> <4A2C1577.6060802@isode.com> <4A2CE34D.8060508@isode.com> Date: Mon, 8 Jun 2009 07:02:39 -0700 To: Alexey Melnikov From: Paul Hoffman Subject: Re: Deprecating DNS names in the subjectName in draft-saintandre-tls-server-id-check Content-Type: text/plain; charset="us-ascii" Cc: "Kurt D. Zeilenga" , 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: , X-List-Received-Date: Mon, 08 Jun 2009 14:11:50 -0000 At 11:09 AM +0100 6/8/09, Alexey Melnikov wrote: >Use of DC attributes is already disallowed by not being explicitly allowed. It would be better if it was explicit, given that many systems still use DC. >Of course the document needs to be clear on what it means about left-to-right RDN ordering versa right-to-left RDN ordering. So some text needs to be added to clarify, or the confusing sentence needs to be removed. Fully agree. Examples of where it is and is not OK to look would be helpful here. From patrik@frobbit.se Mon Jun 8 07:22:10 2009 Return-Path: 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 5076A3A6BB7 for ; Mon, 8 Jun 2009 07:22:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.577 X-Spam-Level: X-Spam-Status: No, score=-1.577 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] 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 I7h5uEGzX9sb for ; Mon, 8 Jun 2009 07:22:09 -0700 (PDT) Received: from srv01.frobbit.se (srv01.frobbit.se [85.30.129.39]) by core3.amsl.com (Postfix) with ESMTP id 64EB73A6D60 for ; Mon, 8 Jun 2009 07:22:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv01.frobbit.se (Postfix) with ESMTP id C69FF57E15D1; Mon, 8 Jun 2009 16:22:13 +0200 (CEST) X-Virus-Scanned: amavisd-new at frobbit.se Received: from srv01.frobbit.se ([127.0.0.1]) by localhost (srv01.frobbit.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wU8u+1JQje3o; Mon, 8 Jun 2009 16:22:13 +0200 (CEST) Received: from junior.frobbit.se (unknown [192.165.72.12]) by srv01.frobbit.se (Postfix) with ESMTP id 5AD6A57E15CA; Mon, 8 Jun 2009 16:22:13 +0200 (CEST) Message-Id: <2CB6A2E1-4E0D-4520-9671-B6C256CC53FF@frobbit.se> From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Paul Hoffman In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: Deprecating DNS names in the subjectName in draft-saintandre-tls-server-id-check Date: Mon, 8 Jun 2009 16:22:12 +0200 References: <4A26FA6A.2060902@stpeter.im> <4A299F4C.2000003@isode.com> <4A2C1577.6060802@isode.com> <4A2CE34D.8060508@isode.com> X-Mailer: Apple Mail (2.935.3) Cc: "Kurt D. Zeilenga" , 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: , X-List-Received-Date: Mon, 08 Jun 2009 14:22:10 -0000 On 8 jun 2009, at 16.02, Paul Hoffman wrote: > At 11:09 AM +0100 6/8/09, Alexey Melnikov wrote: >> Use of DC attributes is already disallowed by not being explicitly >> allowed. > > It would be better if it was explicit, given that many systems still > use DC. While I tend to agree with you Paul (and specifically, I do not personally like DC naming), I am also nervous over words like "many", "few", "almost everyone" etc. Do you have any knowledge of how bad the situation really is? Is there anything more to do to fix this? Do we talk about many standards, many vendors, many products, many deployed entities -- or all of the above? Patrik From alexey.melnikov@isode.com Mon Jun 8 07:58:26 2009 Return-Path: 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 1A6193A6DFF for ; Mon, 8 Jun 2009 07:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.296 X-Spam-Level: X-Spam-Status: No, score=-2.296 tagged_above=-999 required=5 tests=[AWL=-0.297, BAYES_00=-2.599, J_CHICKENPOX_27=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 2UGcJ9zSlZyY for ; Mon, 8 Jun 2009 07:58:25 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 00AF63A6ABA for ; Mon, 8 Jun 2009 07:58:25 -0700 (PDT) Received: from [172.16.2.128] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 8 Jun 2009 15:58:29 +0100 Message-ID: <4A2D26EE.2090501@isode.com> Date: Mon, 08 Jun 2009 15:57:50 +0100 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: Philip Guenther Subject: Re: Deprecating DNS names in the subjectName in draft-saintandre-tls-server-id-check References: <4A26FA6A.2060902@stpeter.im> <4A299F4C.2000003@isode.com> <4A2C1577.6060802@isode.com> <4A2CE34D.8060508@isode.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Paul Hoffman , "Kurt D. Zeilenga" , 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: , X-List-Received-Date: Mon, 08 Jun 2009 14:58:26 -0000 Philip Guenther wrote: >On Mon, 8 Jun 2009, Paul Hoffman wrote: > > >>At 11:09 AM +0100 6/8/09, Alexey Melnikov wrote: >> >> >>>Use of DC attributes is already disallowed by not being explicitly >>>allowed. >>> >>> >>It would be better if it was explicit, given that many systems still use >>DC. >> >> >My understanding is that all Alexey is saying that an implementation that >matches a cert whose subject is > dc=example,dc=com > >(expressed in LDAP-style, most-specific-leftmost) against the domain >"example.com" is not compliant because that is not a documented method. > > Yes. >Is that what you're saying many systems do, Paul? > > I can't say I am an expert, but this never came up for Isode's deployments. For example, openssl wouldn't generate certificates containing DC RDNs be default. So one has to go out of the way to do that. However I know that Microsoft uses DC attributes for naming users/servers. So subjectNames with DC might be generated for such entities. >(I don't think there's any suggestion here of deprecating the use of dc >components in DNs; they just can't be used for the SSL hostname check.) > > Exactly. From guenther@sendmail.com Mon Jun 8 07:44:58 2009 Return-Path: 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 A244D3A6A71 for ; Mon, 8 Jun 2009 07:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_27=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 hZgtH0r8vFvx for ; Mon, 8 Jun 2009 07:44:57 -0700 (PDT) Received: from ladle.sendmail.com (ladle.sendmail.com [209.246.26.53]) by core3.amsl.com (Postfix) with ESMTP id C47CC3A682B for ; Mon, 8 Jun 2009 07:44:57 -0700 (PDT) Received: from fife.sendmail.com (fife.sendmail.com [209.246.26.50]) by ladle.sendmail.com (Switch-3.3.1/Sentrion-3.0.0) with ESMTP id n58EhZNN012495 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 8 Jun 2009 07:43:35 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sendmail.com; s=ladle.dkim; t=1244472215; bh=tNNsj4JqSwhtC8uvj0qln45s5JiTQZU1+AkS 4+6NZIg=; h=Received:X-BATV:X-DKIM:DKIM-Signature:X-DKIM:Date:From: To:cc:Subject:In-Reply-To:Message-ID:References:User-Agent: MIME-Version:Content-Type; b=ky748ykOu3pWpRYVavggisV31cQRfu/9sd8KN cORlv6yV92kRNqBab3Xu5VgbxD9EiY3Th+xbkd07Rn8kCs+nAMkODUsaCiWzKZqtbMT DVbxNZOLqayatzKrv4iSSTuFh/SBPD5fP4z5BL1QGShJAqkbecbYoTd1qIKMsnZh1TA = Received: from macintosh-3.smi.sendmail.com ([10.210.202.2]) (authenticated bits=0) by fife.sendmail.com (Switch-3.4.0/Switch-3.3.2mp) with ESMTP id n58Eix4Z028417 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jun 2009 07:45:01 -0700 X-BATV: Sendmail BATV Filter v0.4.0.dev fife.sendmail.com n58Eix4Z028417 X-DKIM: Sendmail DKIM Filter v2.5.6 fife.sendmail.com n58Eix4Z028417 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sendmail.com; s=fife.dkim; t=1244472303; bh=tNNsj4JqSwhtC8uvj0qln45s5JiTQZU1+AkS4 +6NZIg=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID: References:MIME-Version:Content-Type; b=5uLJIdMZRi0p8T7k5hFcL36hVI 5A7QpLdbtT+NpX/yiiTfjucrMSAzBULSYCx72TbcSUtnOQ7lyBunsWEhrwWfn8nI8Z/ ogP7X6LSOEedYGkiopdi4/BnTB6tTSldGKg0HlttgKPXSt+7163OnmeNXRPFcS9fGsS ejYOpiqGoa4= X-DKIM: Sendmail DKIM Filter v2.5.6 fife.sendmail.com n58Eix4Z028417 Date: Mon, 8 Jun 2009 08:44:59 -0600 From: Philip Guenther To: Paul Hoffman Subject: Re: Deprecating DNS names in the subjectName in draft-saintandre-tls-server-id-check In-Reply-To: Message-ID: References: <4A26FA6A.2060902@stpeter.im> <4A299F4C.2000003@isode.com> <4A2C1577.6060802@isode.com> <4A2CE34D.8060508@isode.com> User-Agent: Alpine 2.00 (BSO 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Mon, 08 Jun 2009 08:22:34 -0700 Cc: "Kurt D. Zeilenga" , 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: , X-List-Received-Date: Mon, 08 Jun 2009 14:44:58 -0000 On Mon, 8 Jun 2009, Paul Hoffman wrote: > At 11:09 AM +0100 6/8/09, Alexey Melnikov wrote: > >Use of DC attributes is already disallowed by not being explicitly > >allowed. > > It would be better if it was explicit, given that many systems still use > DC. My understanding is that all Alexey is saying that an implementation that matches a cert whose subject is dc=example,dc=com (expressed in LDAP-style, most-specific-leftmost) against the domain "example.com" is not compliant because that is not a documented method. Is that what you're saying many systems do, Paul? (I don't think there's any suggestion here of deprecating the use of dc components in DNs; they just can't be used for the SSL hostname check.) Philip Guenther From phoffman@imc.org Mon Jun 8 09:04:28 2009 Return-Path: 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 8118B3A6ABA for ; Mon, 8 Jun 2009 09:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.209 X-Spam-Level: X-Spam-Status: No, score=-2.209 tagged_above=-999 required=5 tests=[AWL=0.390, 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 5AxNfid+j3Zr for ; Mon, 8 Jun 2009 09:04:27 -0700 (PDT) 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 7144D3A6A87 for ; Mon, 8 Jun 2009 09:04:27 -0700 (PDT) Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58G4SgK008554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jun 2009 09:04:29 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4A2D26EE.2090501@isode.com> References: <4A26FA6A.2060902@stpeter.im> <4A299F4C.2000003@isode.com> <4A2C1577.6060802@isode.com> <4A2CE34D.8060508@isode.com> <4A2D26EE.2090501@isode.com> Date: Mon, 8 Jun 2009 09:04:26 -0700 To: Alexey Melnikov , Philip Guenther From: Paul Hoffman Subject: Re: Deprecating DNS names in the subjectName in draft-saintandre-tls-server-id-check Content-Type: text/plain; charset="us-ascii" Cc: "Kurt D. Zeilenga" , 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: , X-List-Received-Date: Mon, 08 Jun 2009 16:04:28 -0000 At 3:57 PM +0100 6/8/09, Alexey Melnikov wrote: >Philip Guenther wrote: >>(I don't think there's any suggestion here of deprecating the use of dc components in DNs; they just can't be used for the SSL hostname check.) >Exactly. There was a desire to make this document useful for more than TLS if other groups want to re-use it. I would like to see this document not allow the use of DC in DNs for validating host names. That is definitely not a prohibition on CAs issuing certificates with DCs; a CA can decide whether or not they want to continue to do so in a world where parties follow this document. From cfinss@dial.pipex.com Mon Jun 8 10:36:49 2009 Return-Path: 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 CE9703A68BF for ; Mon, 8 Jun 2009 10:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.86 X-Spam-Level: X-Spam-Status: No, score=-1.86 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, J_CHICKENPOX_35=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 3BOonPAUfD3m for ; Mon, 8 Jun 2009 10:36:47 -0700 (PDT) Received: from mk-outboundfilter-6.mail.uk.tiscali.com (mk-outboundfilter-6.mail.uk.tiscali.com [212.74.114.14]) by core3.amsl.com (Postfix) with ESMTP id 80EAD3A6878 for ; Mon, 8 Jun 2009 10:36:47 -0700 (PDT) X-Trace: 110937018/mk-outboundfilter-6.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.105.65/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.105.65 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak8FAJTpLEo+vGlB/2dsb2JhbACDKVKLO753CII1DYFABYhx X-IronPort-AV: E=Sophos;i="4.41,325,1241391600"; d="scan'208";a="110937018" X-IP-Direction: IN Received: from 1cust65.tnt2.lnd9.gbr.da.uu.net (HELO allison) ([62.188.105.65]) by smtp.pipex.tiscali.co.uk with SMTP; 08 Jun 2009 18:36:49 +0100 Message-ID: <004801c9e857$29c8e400$0601a8c0@allison> From: "tom.petch" To: "Nicolas Williams" References: <49E58EA2.6050200@isode.com> <4A24ECD0.8050706@isode.com> <000901c9e41d$898eee40$0601a8c0@allison> <4A26D160.5020409@isode.com> <00a101c9e5e1$d57840c0$0601a8c0@allison> <20090605201617.GF1049@Sun.COM> Subject: Re: TLS server identity verification Date: Mon, 8 Jun 2009 18:34:06 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: psaintan@cisco.com, Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2009 17:36:49 -0000 ----- Original Message ----- From: "Nicolas Williams" To: "tom.petch" Cc: "Alexey Melnikov" ; ; "Apps Discuss" Sent: Friday, June 05, 2009 10:16 PM Subject: Re: TLS server identity verification > On Fri, Jun 05, 2009 at 12:26:45PM +0200, tom.petch wrote: > > Scope; what should it be? > > > > I would like the scope to be (server identity checking based on) > > - certificates and PKI > > - certificates without PKI > > - public keys > > with a title to match. > > I think it'd be fine to have a separate document for each of the above. > > > This view is based on requirements arising from recent work on > > - syslog over TLS > > - netconf over TLS > > - snmp over SSH > > - syslog over DTLS. > > Well, ideally RFC3280 should suffice. Unfortunately the security ADs do not agree:-( which led to the work in producing syslog over TLS and netconf over TLS. I would rather not reinvent that wheel, rather capture it now before the security ADs change and we have to start all over again:---( I was sloppy in saying certificates, I did mean X.509 and not PGP etc, but want to include the non-PKI case, eg fingerprints. PKI is a hassle which is why I see it as a great invention, technically brilliant, but one that may or may not take off, one day (IPv6, OSI, Token Ring, ....). So giving users the option of X.509 with fingerprints just may allow them to introduce security when X.509 with PKI would put them off. I am a great believer in 'better something than nothing', fearing that the IETF sets the bar at a level when users opt for nothing instead. I do see two distinct parts to this cookbook, one of how do you validate the certificate (trust anchor, fingerprint, CRL etc); and the other as to what you do with the contents, which fields, what wildcarding with a set of alternatives, perhaps of different strengths of security. This bifurcation is how the discussion (and DISCUSS) panned out with the I-Ds I have been involved with. I think it wrong to focus solely on HTTP; if that is wanted, then this is RFC2818bis. HTTP is a special case, big fat server, human sitting at workstation ready to deal with difficult cases, quite unlike the uses to which TLS is now put, such as the ones I mention above. Tom Petch > In practice, in the HTTP world, > people do things that require more text than RFC3280 has in order to > verify server identities. So I'd like to see a focus on describing > actual practice only, and then primarily (if not only) in the context of > HTTP. If other protocols also do things outside RFC3280, then let's > have separate documents for those _unless_ those documents are either > going to be copies of this one, or could be made a single page addition > to this one. > > Nico From Nicolas.Williams@sun.com Mon Jun 8 10:43:28 2009 Return-Path: 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 C42C03A6A96 for ; Mon, 8 Jun 2009 10:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.028 X-Spam-Level: X-Spam-Status: No, score=-6.028 tagged_above=-999 required=5 tests=[AWL=0.018, 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 bd6-7MEFKg2P for ; Mon, 8 Jun 2009 10:43:28 -0700 (PDT) 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 E92143A68BF for ; Mon, 8 Jun 2009 10:43:27 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n58HhXqN004604 for ; Mon, 8 Jun 2009 17:43:33 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n58HhWt0045093 for ; Mon, 8 Jun 2009 11:43:33 -0600 (MDT) 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 n58HXWOl004403; Mon, 8 Jun 2009 12:33:33 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n58HXOOM004402; Mon, 8 Jun 2009 12:33:24 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 8 Jun 2009 12:33:24 -0500 From: Nicolas Williams To: Paul Hoffman Subject: Re: Deprecating DNS names in the subjectName in draft-saintandre-tls-server-id-check Message-ID: <20090608173324.GL1049@Sun.COM> References: <4A26FA6A.2060902@stpeter.im> <4A299F4C.2000003@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Cc: 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: , X-List-Received-Date: Mon, 08 Jun 2009 17:43:28 -0000 On Sat, Jun 06, 2009 at 07:51:12AM -0700, Paul Hoffman wrote: > >>There is no good reason for a CA to issue certificates with domain > >>names in the subjectName, and lots of reasons for it not to. > >> > >I think the current reality is that many of CAs still do that without > >supporting DNS name in the subjectAltName. > > Probably. Are you saying that the fact that they are doing this > knowingly insecurely should stop us from prohibiting it in this > profile? This profile is supposed to be a way to codify secure > authentication practice. Saying "but there are CAs who do it wrong and > you should validate their certificates anyway" seems > counterproductive. Non-interop would also be counter-productive. And a knob wouldn't be much help either. A phase-out of certs with domain names in subjectName seems in order. Perhaps we should say that such certs issued after some date are prohibited. Nico -- From Nicolas.Williams@sun.com Mon Jun 8 10:56:04 2009 Return-Path: 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 A3FCC3A69D7 for ; Mon, 8 Jun 2009 10:56:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.729 X-Spam-Level: X-Spam-Status: No, score=-5.729 tagged_above=-999 required=5 tests=[AWL=-0.283, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_35=0.6, 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 ZsXTzWiv9XOS for ; Mon, 8 Jun 2009 10:56:03 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by core3.amsl.com (Postfix) with ESMTP id 6DA813A67F8 for ; Mon, 8 Jun 2009 10:56:03 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n58Hu8OV009108 for ; Mon, 8 Jun 2009 17:56:08 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n58Hu8VU055820 for ; Mon, 8 Jun 2009 11:56:08 -0600 (MDT) 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 n58HkAdl004418; Mon, 8 Jun 2009 12:46:10 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n58Hk9Le004417; Mon, 8 Jun 2009 12:46:09 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 8 Jun 2009 12:46:09 -0500 From: Nicolas Williams To: "tom.petch" Subject: Re: TLS server identity verification Message-ID: <20090608174608.GN1049@Sun.COM> References: <49E58EA2.6050200@isode.com> <4A24ECD0.8050706@isode.com> <000901c9e41d$898eee40$0601a8c0@allison> <4A26D160.5020409@isode.com> <00a101c9e5e1$d57840c0$0601a8c0@allison> <20090605201617.GF1049@Sun.COM> <004801c9e857$29c8e400$0601a8c0@allison> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <004801c9e857$29c8e400$0601a8c0@allison> User-Agent: Mutt/1.5.7i Cc: Apps Discuss , psaintan@cisco.com 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: , X-List-Received-Date: Mon, 08 Jun 2009 17:56:04 -0000 On Mon, Jun 08, 2009 at 06:34:06PM +0200, tom.petch wrote: > > > Scope; what should it be? > > > > > > > I would like the scope to be (server identity checking based on) > > > - certificates and PKI > > > - certificates without PKI > > > - public keys > > > with a title to match. > > > > I think it'd be fine to have a separate document for each of the above. > > > > > This view is based on requirements arising from recent work on > > > - syslog over TLS > > > - netconf over TLS > > > - snmp over SSH > > > - syslog over DTLS. > > > > Well, ideally RFC3280 should suffice. > > Unfortunately the security ADs do not agree:-( which led to the work in > producing syslog over TLS and netconf over TLS. I would rather not > reinvent that wheel, rather capture it now before the security ADs change > and we have to start all over again:---( The oddities in cert naming arise mostly from the world of the web. I suppose that such oddities show up in other contexts simply because the same CAs are involved. If so, then I'd sadly agree that you need this doc to apply in those non-web cases too. > I was sloppy in saying certificates, I did mean X.509 and not PGP etc, > but want to include the non-PKI case, eg fingerprints. PKI is a > hassle which is why I see it as a great invention, technically > brilliant, but one that may or may not take off, one day (IPv6, OSI, > Token Ring, ....). So giving users the option of X.509 with > fingerprints just may allow them to introduce security when X.509 with > PKI would put them off. I am a great believer in 'better something > than nothing', fearing that the IETF sets the bar at a level when > users opt for nothing instead. "X.509 with fingerprints" meaning SSH-style leap-of-faith? Fine. Of course, if you have anything better to go on you can always use channel binding to "learn" the cert (much like SSH clients using the GSS-API- based SSHv2 key exchange learn server host keys). > I think it wrong to focus solely on HTTP; if that is wanted, then this > is RFC2818bis. HTTP is a special case, big fat server, human sitting > at workstation ready to deal with difficult cases, quite unlike the > uses to which TLS is now put, such as the ones I mention above. Fair enough, but it is worth pointing out the origins of certain practices. Nico -- From phoffman@imc.org Mon Jun 8 10:59:06 2009 Return-Path: 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 3B2EC3A69D7 for ; Mon, 8 Jun 2009 10:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.258 X-Spam-Level: X-Spam-Status: No, score=-2.258 tagged_above=-999 required=5 tests=[AWL=0.341, 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 UpeWP93jjH9e for ; Mon, 8 Jun 2009 10:59:05 -0700 (PDT) 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 435013A67F8 for ; Mon, 8 Jun 2009 10:59:05 -0700 (PDT) Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n58Hx7dG013929 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jun 2009 10:59:08 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20090608173324.GL1049@Sun.COM> References: <4A26FA6A.2060902@stpeter.im> <4A299F4C.2000003@isode.com> <20090608173324.GL1049@Sun.COM> Date: Mon, 8 Jun 2009 10:59:05 -0700 To: Nicolas Williams From: Paul Hoffman Subject: Re: Deprecating DNS names in the subjectName in draft-saintandre-tls-server-id-check Content-Type: text/plain; charset="us-ascii" Cc: 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: , X-List-Received-Date: Mon, 08 Jun 2009 17:59:06 -0000 At 12:33 PM -0500 6/8/09, Nicolas Williams wrote: >A phase-out of certs with domain names in subjectName >seems in order. Not at all. It is fine to have a certificate with a subject with a CN of "www.example.com". That value follows the semantics for "common name". >Perhaps we should say that such certs issued after some >date are prohibited. The chance of this have any success is near zero. The document in question is about validating systems, not CAs. I think it is quite appropriate for us to keep that focus. From Nicolas.Williams@sun.com Mon Jun 8 11:08:43 2009 Return-Path: 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 6C5993A67FD for ; Mon, 8 Jun 2009 11:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.014 X-Spam-Level: X-Spam-Status: No, score=-6.014 tagged_above=-999 required=5 tests=[AWL=0.032, 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 Zgn6Spo6Hsz4 for ; Mon, 8 Jun 2009 11:08:42 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id 8CF463A67F8 for ; Mon, 8 Jun 2009 11:08:42 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n58I8lLr017063 for ; Mon, 8 Jun 2009 18:08:47 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 n58I8jRB044863 for ; Mon, 8 Jun 2009 12:08:45 -0600 (MDT) 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 n58Hwlrq004434; Mon, 8 Jun 2009 12:58:47 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n58HwlA3004433; Mon, 8 Jun 2009 12:58:47 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 8 Jun 2009 12:58:47 -0500 From: Nicolas Williams To: Paul Hoffman Subject: Re: Deprecating DNS names in the subjectName in draft-saintandre-tls-server-id-check Message-ID: <20090608175847.GP1049@Sun.COM> References: <4A26FA6A.2060902@stpeter.im> <4A299F4C.2000003@isode.com> <20090608173324.GL1049@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Cc: 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: , X-List-Received-Date: Mon, 08 Jun 2009 18:08:43 -0000 On Mon, Jun 08, 2009 at 10:59:05AM -0700, Paul Hoffman wrote: > At 12:33 PM -0500 6/8/09, Nicolas Williams wrote: > >A phase-out of certs with domain names in subjectName > >seems in order. > > Not at all. It is fine to have a certificate with a subject with a CN > of "www.example.com". That value follows the semantics for "common > name". I hadn't caught up with the rest of the thread, which subsequently made clear what the issue was. I retract my comment. Nico -- From ietfdbh@comcast.net Mon Jun 8 11:14:49 2009 Return-Path: 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 2043F3A6DE0 for ; Mon, 8 Jun 2009 11:14:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.972 X-Spam-Level: X-Spam-Status: No, score=-1.972 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, J_CHICKENPOX_35=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 WmBs7kn3yeks for ; Mon, 8 Jun 2009 11:14:48 -0700 (PDT) Received: from QMTA01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by core3.amsl.com (Postfix) with ESMTP id D7CE43A6DD9 for ; Mon, 8 Jun 2009 11:14:47 -0700 (PDT) Received: from OMTA11.westchester.pa.mail.comcast.net ([76.96.62.36]) by QMTA01.westchester.pa.mail.comcast.net with comcast id 1N8z1c0010mv7h051WEf30; Mon, 08 Jun 2009 18:14:39 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA11.westchester.pa.mail.comcast.net with comcast id 1WEt1c00H0UQ6dC3XWEtfz; Mon, 08 Jun 2009 18:14:54 +0000 From: "David Harrington" To: "'tom.petch'" , "'Nicolas Williams'" References: <49E58EA2.6050200@isode.com> <4A24ECD0.8050706@isode.com><000901c9e41d$898eee40$0601a8c0@allison><4A26D160.5020409@isode.com><00a101c9e5e1$d57840c0$0601a8c0@allison><20090605201617.GF1049@Sun.COM> <004801c9e857$29c8e400$0601a8c0@allison> Subject: RE: TLS server identity verification Date: Mon, 8 Jun 2009 14:14:52 -0400 Message-ID: <008b01c9e865$05011df0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 thread-index: AcnoX7ovoLvBrvB9Rqq41+Gv6MQX7AAAqBAQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <004801c9e857$29c8e400$0601a8c0@allison> Cc: 'Apps Discuss' , psaintan@cisco.com 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: , X-List-Received-Date: Mon, 08 Jun 2009 18:14:49 -0000 Hi, I think it is important to understand that syslog/tls and netconf/tls and snmp/tls have specific needs that are not necessarily present in the common HTTP use case. Network management needs to work in flaky networks. HTTP/tls normally does not need to deal with this issue; you just get a 404 error or something in response, or a browser prompts a user for "what do I do now?". IETF standard network management protocols usually require that the protocol should NOT be dependent on third party services to operate. That is, the protocols need to work even if PKI or AAA or other third-party service is not available via the network. As Tom points out, syslog and netconf have been designed to use fingerprints to deal with this situation. It would be good if this approach was written down and standardized so this solution can be reused by all IETF applications that need to meet this requirement. It is also important to understand that the nature of "Internet management" is changing. Ten years ago, we didn't have syslog or netconf or ipfix in the IETF standard management protocol stable; we had SNMP as the one-and-only be-all management protocol. To better accommodate the changing nature of the Internet, we are changing IETF requirements for operations and management, and allowing new management protocols to be designed for specific purposes. It would be a good thing for operators if we used a standardized approach for securing emerging management protocols with TLS. This is a particular use case, but one that exists for a growing number of management protocols, so a separate document describing a standard for "certificates without PKI" could be appropriate. David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com > -----Original Message----- > From: apps-discuss-bounces@ietf.org > [mailto:apps-discuss-bounces@ietf.org] On Behalf Of tom.petch > Sent: Monday, June 08, 2009 12:34 PM > To: Nicolas Williams > Cc: psaintan@cisco.com; Apps Discuss > Subject: Re: TLS server identity verification > > ----- Original Message ----- > From: "Nicolas Williams" > To: "tom.petch" > Cc: "Alexey Melnikov" ; > ; "Apps > Discuss" > Sent: Friday, June 05, 2009 10:16 PM > Subject: Re: TLS server identity verification > > > On Fri, Jun 05, 2009 at 12:26:45PM +0200, tom.petch wrote: > > > Scope; what should it be? > > > > > > > I would like the scope to be (server identity checking based on) > > > - certificates and PKI > > > - certificates without PKI > > > - public keys > > > with a title to match. > > > > I think it'd be fine to have a separate document for each > of the above. > > > > > This view is based on requirements arising from recent work on > > > - syslog over TLS > > > - netconf over TLS > > > - snmp over SSH > > > - syslog over DTLS. > > > > Well, ideally RFC3280 should suffice. > > Unfortunately the security ADs do not agree:-( which led to > the work in > producing syslog over TLS and netconf over TLS. I would rather not > reinvent that wheel, rather capture it now before the > security ADs change > and we have to start all over again:---( > > I was sloppy in saying certificates, I did mean X.509 and not > PGP etc, but > want to include the non-PKI case, eg fingerprints. PKI is a > hassle which is > why I see it as a great invention, technically brilliant, but > one that may or > may not > take off, one day (IPv6, OSI, Token Ring, ....). So giving > users the option of > X.509 with fingerprints just may allow them to introduce > security when X.509 > with PKI would put them off. I am a great believer in > 'better something than > nothing', fearing that the IETF sets the bar at a level when > users opt for > nothing instead. > > I do see two distinct parts to this cookbook, one of how do > you validate the > certificate (trust anchor, fingerprint, CRL etc); and the > other as to what > you do with the contents, which fields, what wildcarding with a set of > alternatives, perhaps of different strengths of security. > This bifurcation is > how the discussion (and DISCUSS) panned out with the I-Ds I > have been involved > with. > > I think it wrong to focus solely on HTTP; if that is wanted, > then this is > RFC2818bis. HTTP is a special case, big fat server, human > sitting at workstation > ready to deal with difficult cases, quite unlike the uses to > which TLS is now > put, such as the ones I mention above. > > Tom Petch > > > In practice, in the HTTP world, > > people do things that require more text than RFC3280 has in order to > > verify server identities. So I'd like to see a focus on describing > > actual practice only, and then primarily (if not only) in > the context of > > HTTP. If other protocols also do things outside RFC3280, then let's > > have separate documents for those _unless_ those documents > are either > > going to be copies of this one, or could be made a single > page addition > > to this one. > > > > Nico > > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From fluffy@cisco.com Mon Jun 8 11:31:24 2009 Return-Path: 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 8114D3A68D2 for ; Mon, 8 Jun 2009 11:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.282 X-Spam-Level: X-Spam-Status: No, score=-106.282 tagged_above=-999 required=5 tests=[AWL=-0.283, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_MED=-4, 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 BSnOHN4eSXW4 for ; Mon, 8 Jun 2009 11:31:23 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 9D33B3A6A00 for ; Mon, 8 Jun 2009 11:31:23 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,325,1241395200"; d="scan'208";a="319175680" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 08 Jun 2009 18:31:29 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n58IVTRJ006449; Mon, 8 Jun 2009 11:31:29 -0700 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n58IVRat019851; Mon, 8 Jun 2009 18:31:27 GMT From: Cullen Jennings To: apps-discuss@ietf.org In-Reply-To: <927AA151-048C-40AD-A83B-F9C7FD5C9755@Isode.com> Impp: xmpp:cullenfluffyjennings@jabber.org Subject: Re: TLS server identity verification X-Priority: 3 References: <49E58EA2.6050200@isode.com> <4A24ECD0.8050706@isode.com> <000901c9e41d$898eee40$0601a8c0@allison> <4A26D160.5020409@isode.com> <00a101c9e5e1$d57840c0$0601a8c0@allison> <927AA151-048C-40AD-A83B-F9C7FD5C9755@Isode.com> Message-Id: <057FBB9D-1B03-4153-A7D5-5296BAFF6C4D@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 8 Jun 2009 12:31:26 -0600 X-Mailer: Apple Mail (2.935.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2274; t=1244485889; x=1245349889; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20TLS=20server=20identity=20verification |Sender:=20; bh=dmmP9gsWCNPMjDPfoV7vUxhhzMa1U2G3VPJNM7lS8cE=; b=EGDkqkRAvCzScM1TTxSVBeTiYEHPSPEtawlgJUhPGQGc4cXNqFeWo3zj+e cdnzi4S2YWacBA9Y07v1lHNz+0WzroRlGZ0OqmzJkW/pnHHvbyl/jH9Bd7Hd kOrgzBQDig; Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: Kurt Zeilenga 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: , X-List-Received-Date: Mon, 08 Jun 2009 18:31:24 -0000 On Jun 5, 2009, at 9:14 AM, Kurt Zeilenga wrote: > > On Jun 5, 2009, at 3:26 AM, tom.petch wrote: > >> Scope; what should it be? > > Very good question. > > My personal opinion is that the document should provide a "cookbook" > that can be used in creating procedures for TLS server identity > verification in application protocol technical specifications. > > Currently, each application protocol technical specification which > provides for TLS is to include procedures for TLS server identity > verification. It is desirable to have some commonality between the > methods. However, as not every way to verify the TLS server > identity is applicable to every application protocol which uses TLS, > I do not think it feasible to develop a "generic" procedure (as the > previous title suggested). > > I suggest instead the title "TLS Server Identity Verification in > Application Protocols", for the document to discuss various ways for > TLS server identity verification to be done and be organized such > that application protocol specifications can easily "profile" this > document in order to specify the application protocol specific > procedure. I think the document should be targeted for the Standard > Track. > > I also think it would be useful to have a document indicating which > ways are "best current practice", but thinking this might be better > placed in a separate document. > > I do think the document should be narrowly focus on TLS server > identity verification with X.509 certificates. I don't mind having > a title which indicates this narrow focus, but am also fine with a > title which leaves the "with X.509 certificates" aspect implicit. > > -- Kurt I would like to +1 what Kurt said. Specifically, saying this is a BCP to which all existing protocols need to conform is just not going to fly. However, having one "cook book" Standards Track RFC that all new things can point at and say, just do it like RFC AAAA says to do it would be great. I think it might be good to consider the wildcard issue a bit deeper too. It might be good good for the cookbook to have two things specified, ones that allows wildcard and one that does not. From Jeff.Hodges@KingsMountain.com Mon Jun 8 12:39:03 2009 Return-Path: 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 53C173A6B15 for ; Mon, 8 Jun 2009 12:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 ByK7acUFGire for ; Mon, 8 Jun 2009 12:39:02 -0700 (PDT) Received: from outbound-mail-11.bluehost.com (outbound-mail-11.bluehost.com [69.89.18.111]) by core3.amsl.com (Postfix) with SMTP id 6C73C3A6A50 for ; Mon, 8 Jun 2009 12:39:02 -0700 (PDT) Received: (qmail 6741 invoked by uid 0); 8 Jun 2009 19:39:07 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by outboundproxy1.bluehost.com with SMTP; 8 Jun 2009 19:39:07 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=SmbFvnAqWA40vbpWBQyOSP5Xt1UMdWeycix8eXgtkjbPo1afhGJrM9oo+qyG+j+MvHdmIYBbtkhRpnEuZ6nMNzGhZvLdXT10I1mP0I0DlPHKltOfNJw9znSu4qc8LAq0; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.48.61]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1MDkgV-0006CU-Nq for apps-discuss@ietf.org; Mon, 08 Jun 2009 13:39:07 -0600 Message-ID: <4A2D68E6.7020008@KingsMountain.com> Date: Mon, 08 Jun 2009 12:39:18 -0700 From: =JeffH User-Agent: Thunderbird 1.5.0.14ubu (X11/20080306) MIME-Version: 1.0 To: apps-discuss@ietf.org Subject: Re: TLS server identity verification Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} 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: , X-List-Received-Date: Mon, 08 Jun 2009 19:39:03 -0000 cullen said: > > having one "cook > book" Standards Track RFC that all new things can point at and say, > just do it like RFC AAAA says to do it would be great. that's a reasonable summary of what Chris Newman overall desired when he tugged my sleeve a while back wrt concocting this I-D. Kurt had said: > > I suggest instead the title "TLS Server Identity Verification in > Application Protocols", for the document to discuss various ways for > TLS server identity verification to be done and be organized such > that application protocol specifications can easily "profile" this > document in order to specify the application protocol specific > procedure. I think the document should be targeted for the Standard > Track. That's an explicit refinement of the original goal, and could be the way to go. > I also think it would be useful to have a document indicating which > ways are "best current practice", but thinking this might be better > placed in a separate document. Hm, maybe so. But then there's the issue of yet more specs/docs and which to reference when. Could it be done in one doc? =JeffH From Jeff.Hodges@KingsMountain.com Mon Jun 8 15:34:02 2009 Return-Path: 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 04CAB3A6886 for ; Mon, 8 Jun 2009 15:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 RP6lsp3JTXmM for ; Mon, 8 Jun 2009 15:34:01 -0700 (PDT) Received: from outbound-mail-12.bluehost.com (outbound-mail-12.bluehost.com [69.89.18.112]) by core3.amsl.com (Postfix) with SMTP id 2DA523A6837 for ; Mon, 8 Jun 2009 15:34:01 -0700 (PDT) Received: (qmail 1893 invoked by uid 0); 8 Jun 2009 22:34:06 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by outboundproxy1.bluehost.com with SMTP; 8 Jun 2009 22:34:06 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=t436TR+Mva8QKc8xjzvKZGDL8oi7m7dt5hRukzYFOwKkurXM8IUaQX6LMxCFwOt7N411NbcSXDpQQ+sFKuDa0X6mkGwV/L5Oel+/gYmjI37+M2Jd9RwQmvFffUotKeaf; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.48.61]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1MDnPq-0006Qw-Hy for apps-discuss@ietf.org; Mon, 08 Jun 2009 16:34:06 -0600 Message-ID: <4A2D91E9.4050205@KingsMountain.com> Date: Mon, 08 Jun 2009 15:34:17 -0700 From: =JeffH User-Agent: Thunderbird 1.5.0.14ubu (X11/20080306) MIME-Version: 1.0 To: apps-discuss@ietf.org Subject: wrt comparison of dns names Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} 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: , X-List-Received-Date: Mon, 08 Jun 2009 22:34:02 -0000 a sub-topic of the -tls-server-id-check thread(s) is one of "comparison of dns names" (aka "comparison of domain names", "domain name comparison", "domain name match(ing)", "domain-match{es,ing}", etc.). A specfic example is Section 3.1 "Comparison of DNS Names" in draft-saintandre-tls-server-id-check-00. FWIW, I have searched pretty high and fairly low and not found a comprehensive approach to this "Comparison of DNS Names" thing, but a fair number of somewhat specific approaches, e.g. in addition to the above there's at least: in RFC52080 section 4.2.1.10. Name Constraints, RFC2109 section 2. Terminology, RFC2965 Terminology, RFC2818 section 3.1. Server Identity, to some extent section 7. Processing Rules for Internationalized Names of RFC5280. My particular application having a client that needs to extract the dns name from an incomming message, and then look it up in a client-maintained cache to see if we've "seen" it before, and also that any.subdomain.domain.tld matches an entry for domain.tld (eg a form of "wildcarding" is in effect). I can certainly write the algorithm sorta yet again for my particular case, but having one that is a shared resource at the spec level that one could reference might be a good thing too. Have I missed it, does such exist? thanks, =JeffH From vkg@alcatel-lucent.com Mon Jun 8 15:42:37 2009 Return-Path: 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 416F83A6A3B for ; Mon, 8 Jun 2009 15:42:37 -0700 (PDT) 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 L7zRRb-pgjBo for ; Mon, 8 Jun 2009 15:42:36 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 317C63A63CB for ; Mon, 8 Jun 2009 15:42:36 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id n58MgdJl006538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jun 2009 17:42:39 -0500 (CDT) Received: from [135.185.236.17] (il0015vkg1.ih.lucent.com [135.185.236.17]) by umail.lucent.com (8.13.8/TPES) with ESMTP id n58Mgd3q014966; Mon, 8 Jun 2009 17:42:39 -0500 (CDT) Message-ID: <4A2D93DF.9020801@alcatel-lucent.com> Date: Mon, 08 Jun 2009 17:42:39 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: =JeffH Subject: Re: wrt comparison of dns names References: <4A2D91E9.4050205@KingsMountain.com> In-Reply-To: <4A2D91E9.4050205@KingsMountain.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: 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: , X-List-Received-Date: Mon, 08 Jun 2009 22:42:37 -0000 =JeffH wrote: > a sub-topic of the -tls-server-id-check thread(s) is one of "comparison > of dns names" (aka "comparison of domain names", "domain name > comparison", "domain name match(ing)", "domain-match{es,ing}", etc.). > > A specfic example is Section 3.1 "Comparison of DNS Names" in > draft-saintandre-tls-server-id-check-00. > > FWIW, I have searched pretty high and fairly low and not found a > comprehensive approach to this "Comparison of DNS Names" thing, [...] > I can certainly write the algorithm sorta yet again for my particular > case, but having one that is a shared resource at the spec level that > one could reference might be a good thing too. > > Have I missed it, does such exist? Jeff: We did something similar for sip in domain-certs (see http://tools.ietf.org/html/draft-ietf-sip-domain-certs-04). Specifically, S7.1 talks about finding the value in SAN, S7.2 talks about matching the values, including wild-carding, and so on. domain-certs has been through WGLC in the SIP WG and was influenced heavily by input from the PKIX WG. It is making its way to the IESG right now. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} Web: http://ect.bell-labs.com/who/vkg/ From alexey.melnikov@isode.com Wed Jun 10 10:43:59 2009 Return-Path: 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 47A653A68B9 for ; Wed, 10 Jun 2009 10:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 Oi0xc1oGSrG6 for ; Wed, 10 Jun 2009 10:43:58 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 72CF23A6855 for ; Wed, 10 Jun 2009 10:43:58 -0700 (PDT) Received: from [172.16.2.178] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 10 Jun 2009 18:44:04 +0100 Message-ID: <4A2FF0A9.30800@isode.com> Date: Wed, 10 Jun 2009 18:43:05 +0100 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: Cullen Jennings Subject: Re: TLS server identity verification References: <49E58EA2.6050200@isode.com> <4A24ECD0.8050706@isode.com> <000901c9e41d$898eee40$0601a8c0@allison> <4A26D160.5020409@isode.com> <00a101c9e5e1$d57840c0$0601a8c0@allison> <927AA151-048C-40AD-A83B-F9C7FD5C9755@Isode.com> <057FBB9D-1B03-4153-A7D5-5296BAFF6C4D@cisco.com> In-Reply-To: <057FBB9D-1B03-4153-A7D5-5296BAFF6C4D@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 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: , X-List-Received-Date: Wed, 10 Jun 2009 17:43:59 -0000 Cullen Jennings wrote: > I think it might be good to consider the wildcard issue a bit deeper > too. It might be good good for the cookbook to have two things > specified, ones that allows wildcard and one that does not. +1. From munjo.yu@gmail.com Wed Jun 10 17:29:32 2009 Return-Path: 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 A242C3A6D4B for ; Wed, 10 Jun 2009 17:29:32 -0700 (PDT) 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=[AWL=0.000, 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 JMxbRyrmZVhS for ; Wed, 10 Jun 2009 17:29:32 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by core3.amsl.com (Postfix) with ESMTP id DB72A3A6CE0 for ; Wed, 10 Jun 2009 17:29:26 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 3so841164qwe.31 for ; Wed, 10 Jun 2009 17:29:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=Z8quoWnAxQ5HZAILxlmWRsjLulfMZwW9C90TDmHxgzo=; b=UXeAVropr5uaNSNMMSf8hZj22xFaF7tkwPvrzTZyJiHJAhfw71qD1ubsMO0by6UzxL l8q+bP8ObnWyFC614QTl1fCWY9TZy6KnY8xQk1HHA0vtMK3bzh/K3xWAllbO9iRW4mS7 PEq8/M3xdldt7FfFzA4Hpx5vS+w7m+A+Xrnjc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=MP7KVa2SiTxrHenbS+Ts2MX8PKxt/T/9gbvYyMFWmODnQeJqMKdR+nhc1PRbOhk/oE fwRGhkYKEoH1DRb5dhn6m4C1pzuAfjEinytpeuWS4kqvSMbAPxkAwHAqU5Cpsy2WXFFH O8bcHze90S/xQI2FD5NwqAzWRUdJ/lmQ07Uk0= MIME-Version: 1.0 Received: by 10.229.85.17 with SMTP id m17mr447029qcl.43.1244680171911; Wed, 10 Jun 2009 17:29:31 -0700 (PDT) Date: Wed, 10 Jun 2009 20:29:31 -0400 Message-ID: Subject: Request for review of draft-kim-abnf-codegen-00.txt From: Munjo Yu To: discuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: MSKang 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: , X-List-Received-Date: Thu, 11 Jun 2009 00:29:32 -0000 Hello, We are seeking for reviews by APPS folks. We submitted our draft, draft-kim-abnf-codegen-00.txt, as "experimental", on May 27th, 2009, and Lisa Dusseault suggested us to ask for reviews. The document's link is as follows: http://www.ietf.org/internet-drafts/draft-kim-abnf-codegen-00.txt We will greatly appreciate if a couple of people give us reviews. We are also looking for someone who is willing to shepherd our draft. Thanks in advance, -Munjo Yu, at VineGen Inc From salvatore.loreto@ericsson.com Thu Jun 11 13:38:57 2009 Return-Path: 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 4B3ED3A6B3D for ; Thu, 11 Jun 2009 13:38:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=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 t0HjQgcOJPwb for ; Thu, 11 Jun 2009 13:38:56 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 01CE33A6B14 for ; Thu, 11 Jun 2009 13:38:55 -0700 (PDT) X-AuditID: c1b4fb3e-b7bedae0000062bb-04-4a316b664afb Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id AC.31.25275.66B613A4; Thu, 11 Jun 2009 22:39:02 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Jun 2009 22:39:01 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Jun 2009 22:39:02 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 04DED244E for ; Thu, 11 Jun 2009 23:39:02 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id C1F50219FF for ; Thu, 11 Jun 2009 23:39:01 +0300 (EEST) Received: from localhost.localdomain (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 7FEB4219AA for ; Thu, 11 Jun 2009 23:39:01 +0300 (EEST) Message-ID: <4A316B65.4040601@ericsson.com> Date: Thu, 11 Jun 2009 23:39:01 +0300 From: Salvatore Loreto User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: apps-discuss@ietf.org Subject: Fwd: [hybi] draft-loreto-http-bidirectional Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 11 Jun 2009 20:39:02.0184 (UTC) FILETIME=[A78E0A80:01C9EAD4] X-Brightmail-Tracker: AAAAAA== 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: , X-List-Received-Date: Thu, 11 Jun 2009 20:38:57 -0000 -------- Original Message -------- Hi there, we have just submitted the following draft: "Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP" The draft is a first tentative to describe what does it means to use HTTP for Bidirectional communication and how to better use HTTP, as it exists today, to enable such "bidirectional HTTP" using "long polling" and "HTTP streaming" mechanisms. until it will appear on the IETF website you can find it here: http://xmpp.org/internet-drafts/draft-loreto-http-bidirectional-00.txt we are looking forward to receive your comments, suggestions and feedbacks on it we would like to remind that the preferred venue for discussion of this document is the hybi@ietf.org mailing list (visit for further information). best regards Sal -------- Original Message -------- Subject: New Version Notification for draft-loreto-http-bidirectional-00 Date: Thu, 11 Jun 2009 13:15:57 -0700 (PDT) From: IETF I-D Submission Tool To: Salvatore.Loreto@ericsson.com CC: salvatore.loreto@ericsson.com,psaintan@cisco.com,gregw@webtide.com,stefano.salsano@uniroma2.it A new version of I-D, draft-loreto-http-bidirectional-00.txt has been successfuly submitted by Salvatore Loreto and posted to the IETF repository. Filename: draft-loreto-http-bidirectional Revision: 00 Title: Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP Creation_date: 2009-06-11 WG ID: Independent Submission Number_of_pages: 16 Abstract: There is widespread interest in using the Hypertext Transfer Protocol (HTTP) to enable asynchronous or server-initiated communication from a server to a client as well as from a client to a server. This document describes how to better use HTTP, as it exists today, to enable such "bidirectional HTTP" using "long polling" and "HTTP streaming" mechanisms. The IETF Secretariat. _______________________________________________ hybi mailing list hybi@ietf.org https://www.ietf.org/mailman/listinfo/hybi From Kurt.Zeilenga@Isode.com Thu Jun 11 18:24:23 2009 Return-Path: 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 D79813A6D3A for ; Thu, 11 Jun 2009 18:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.94 X-Spam-Level: X-Spam-Status: No, score=-2.94 tagged_above=-999 required=5 tests=[AWL=-0.341, 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 Faa+SNdhfMcl for ; Thu, 11 Jun 2009 18:24:23 -0700 (PDT) Received: from boole.openldap.org (boole.openldap.org [IPv6:2001:4f8:3:ba:219:21ff:fe2f:68d5]) by core3.amsl.com (Postfix) with ESMTP id E91F33A6ABC for ; Thu, 11 Jun 2009 18:24:22 -0700 (PDT) Received: from [192.168.1.102] (75-141-233-128.dhcp.nv.charter.com [75.141.233.128] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.14.3/8.14.3) with ESMTP id n5C1OOGb017215; Fri, 12 Jun 2009 01:24:26 GMT (envelope-from Kurt.Zeilenga@Isode.com) Message-Id: <75137DAB-CDA3-4411-B8FE-BE683E9C8F7A@Isode.com> From: Kurt Zeilenga To: =JeffH In-Reply-To: <4A2D68E6.7020008@KingsMountain.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: TLS server identity verification Date: Thu, 11 Jun 2009 18:24:24 -0700 References: <4A2D68E6.7020008@KingsMountain.com> X-Mailer: Apple Mail (2.935.3) Cc: 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: , X-List-Received-Date: Fri, 12 Jun 2009 01:24:23 -0000 On Jun 8, 2009, at 12:39 PM, =JeffH wrote: > cullen said: > > > > having one "cook > > book" Standards Track RFC that all new things can point at and say, > > just do it like RFC AAAA says to do it would be great. > > that's a reasonable summary of what Chris Newman overall desired > when he tugged my sleeve a while back wrt concocting this I-D. > > Kurt had said: > > > > I suggest instead the title "TLS Server Identity Verification in > > Application Protocols", for the document to discuss various ways for > > TLS server identity verification to be done and be organized such > > that application protocol specifications can easily "profile" this > > document in order to specify the application protocol specific > > procedure. I think the document should be targeted for the Standard > > Track. > > That's an explicit refinement of the original goal, and could be the > way to go. > > > I also think it would be useful to have a document indicating which > > ways are "best current practice", but thinking this might be better > > placed in a separate document. > > Hm, maybe so. But then there's the issue of yet more specs/docs and > which to reference when. Could it be done in one doc? Yes. For instance, the document could have one part which detailed various ways one could verify the server identity and separate part which discussed the applicability (in general to application-level protocols) of each way. That is, one part "technical specification" and one part "applicability statement" or "best current practice". From mnot@mnot.net Fri Jun 12 06:12:01 2009 Return-Path: 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 75E403A6E08 for ; Fri, 12 Jun 2009 06:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.138 X-Spam-Level: X-Spam-Status: No, score=-6.138 tagged_above=-999 required=5 tests=[AWL=-2.539, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 KN+zV8c9YnOf for ; Fri, 12 Jun 2009 06:12:00 -0700 (PDT) Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178]) by core3.amsl.com (Postfix) with ESMTP id 7AE8A3A6A5F for ; Fri, 12 Jun 2009 06:12:00 -0700 (PDT) Received: from [192.168.1.6] (unknown [118.208.249.76]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 242AB23E4AE for ; Fri, 12 Jun 2009 09:11:58 -0400 (EDT) Message-Id: <23E3F46C-47E8-4FCC-9C70-C21BEC0D9CD4@mnot.net> From: Mark Nottingham To: apps-discuss@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: FYI: Apache Avro Date: Fri, 12 Jun 2009 23:11:58 +1000 X-Mailer: Apple Mail (2.935.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: , X-List-Received-Date: Fri, 12 Jun 2009 13:12:01 -0000 Yet another data representation / schema / RPC: http://people.apache.org/~cutting/avro/ -- Mark Nottingham http://www.mnot.net/ From Kurt.Zeilenga@isode.com Fri Jun 12 07:15:51 2009 Return-Path: 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 F3AA43A6A3B for ; Fri, 12 Jun 2009 07:15:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.306 X-Spam-Level: X-Spam-Status: No, score=-2.306 tagged_above=-999 required=5 tests=[AWL=-0.307, BAYES_00=-2.599, J_CHICKENPOX_26=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 qKaWDk3uv1wx for ; Fri, 12 Jun 2009 07:15:50 -0700 (PDT) Received: from boole.openldap.org (boole.openldap.org [IPv6:2001:4f8:3:ba:219:21ff:fe2f:68d5]) by core3.amsl.com (Postfix) with ESMTP id 29D9E3A6814 for ; Fri, 12 Jun 2009 07:15:49 -0700 (PDT) Received: from [192.168.1.101] (75-141-233-128.dhcp.nv.charter.com [75.141.233.128] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.14.3/8.14.3) with ESMTP id n5CEFrRv060361; Fri, 12 Jun 2009 14:15:53 GMT (envelope-from Kurt.Zeilenga@isode.com) Message-Id: <1977B30B-B8B7-4642-827D-F546EC643906@isode.com> From: Kurt Zeilenga To: Paul Hoffman In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: Deprecating DNS names in the subjectName in draft-saintandre-tls-server-id-check Date: Fri, 12 Jun 2009 07:15:53 -0700 References: <4A26FA6A.2060902@stpeter.im> <4A299F4C.2000003@isode.com> <4A2C1577.6060802@isode.com> <4A2CE34D.8060508@isode.com> X-Mailer: Apple Mail (2.935.3) Cc: 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: , X-List-Received-Date: Fri, 12 Jun 2009 14:15:51 -0000 On Jun 8, 2009, at 7:02 AM, Paul Hoffman wrote: >> >> Of course the document needs to be clear on what it means about >> left-to-right RDN ordering versa right-to-left RDN ordering. So >> some text needs to be added to clarify, or the confusing sentence >> needs to be removed. > > Fully agree. Examples of where it is and is not OK to look would be > helpful here. The document should say that when CN=domain AVA is used, this AVA ought be the only AVA in the RDN (not a multi-valued RDN), and the RDN ought to be least significant RDN of the DN. (Avoid the left-to- right/right-to-left descriptions, as these terms are based upon text representations of DNs, what matters is placement in the abstract value.) We can argue whether "ought" above translates to MUST or SHOULD in the document. However, IIRC, there are CAs which place the CN=domain AVA in a multi- valued RDN and/or place the RDN somewhere other than the least- significant RDN. Both of which are problematic, but for different reasons. -- Kurt From Kurt.Zeilenga@isode.com Fri Jun 12 07:23:42 2009 Return-Path: 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 3F21D3A6B29 for ; Fri, 12 Jun 2009 07:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, 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 sWxj1dlcou6x for ; Fri, 12 Jun 2009 07:23:41 -0700 (PDT) Received: from boole.openldap.org (boole.openldap.org [IPv6:2001:4f8:3:ba:219:21ff:fe2f:68d5]) by core3.amsl.com (Postfix) with ESMTP id 405793A6814 for ; Fri, 12 Jun 2009 07:23:41 -0700 (PDT) Received: from [192.168.1.101] (75-141-233-128.dhcp.nv.charter.com [75.141.233.128] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.14.3/8.14.3) with ESMTP id n5CENj9q060661; Fri, 12 Jun 2009 14:23:46 GMT (envelope-from Kurt.Zeilenga@isode.com) Message-Id: <2D334AFB-3D9F-4E5C-9F5E-53F6DD881C05@isode.com> From: Kurt Zeilenga To: Alexey Melnikov In-Reply-To: <4A2CE34D.8060508@isode.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: Deprecating DNS names in the subjectName in draft-saintandre-tls-server-id-check Date: Fri, 12 Jun 2009 07:23:45 -0700 References: <4A26FA6A.2060902@stpeter.im> <4A299F4C.2000003@isode.com> <4A2C1577.6060802@isode.com> <4A2CE34D.8060508@isode.com> X-Mailer: Apple Mail (2.935.3) Cc: Paul Hoffman , 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: , X-List-Received-Date: Fri, 12 Jun 2009 14:23:42 -0000 On Jun 8, 2009, at 3:09 AM, Alexey Melnikov wrote: > Use of DC attributes is already disallowed by not being explicitly > allowed. Well, as subsequently clarified, DC attributes are allowed in the subjectName DN, just not used to verify the subject. > Of course the document needs to be clear on what it means about left- > to-right RDN ordering versa right-to-left RDN ordering. So some text > needs to be added to clarify, or the confusing sentence needs to be > removed. In DC naming, the most significant domain component belongs in the most significant RDN... the second most significant component in the second most significant RDN, ..., and these RDNs ought to be singled valued. But if the document doesn't discuss verification by DC naming, it doesn't need to say anything about DC naming. -- Kurt From cfinss@dial.pipex.com Fri Jun 12 07:41:07 2009 Return-Path: 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 C9C563A691E for ; Fri, 12 Jun 2009 07:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.271 X-Spam-Level: X-Spam-Status: No, score=-1.271 tagged_above=-999 required=5 tests=[AWL=-0.531, BAYES_20=-0.74] 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 WdJdx9YAN8dI for ; Fri, 12 Jun 2009 07:41:07 -0700 (PDT) Received: from mk-outboundfilter-2.mail.uk.tiscali.com (mk-outboundfilter-2.mail.uk.tiscali.com [212.74.114.38]) by core3.amsl.com (Postfix) with ESMTP id C03673A687D for ; Fri, 12 Jun 2009 07:41:06 -0700 (PDT) X-Trace: 222483080/mk-outboundfilter-2.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.19.11/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.19.11 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsYEAJ8FMko+vBML/2dsb2JhbACDKYwawj8IgjSBTwU X-IronPort-AV: E=Sophos;i="4.42,210,1243810800"; d="scan'208";a="222483080" X-IP-Direction: IN Received: from 1cust11.tnt2.lnd3.gbr.da.uu.net (HELO allison) ([62.188.19.11]) by smtp.pipex.tiscali.co.uk with SMTP; 12 Jun 2009 15:41:06 +0100 Message-ID: <003e01c9eb63$4538a680$0601a8c0@allison> From: "tom.petch" To: "Alexey Melnikov" , "Cullen Jennings" References: <49E58EA2.6050200@isode.com> <4A24ECD0.8050706@isode.com><000901c9e41d$898eee40$0601a8c0@allison><4A26D160.5020409@isode.com><00a101c9e5e1$d57840c0$0601a8c0@allison><927AA151-048C-40AD-A83B-F9C7FD5C9755@Isode.com><057FBB9D-1B03-4153-A7D5-5296BAFF6C4D@cisco.com> <4A2FF0A9.30800@isode.com> Subject: Re: TLS server identity verification Date: Fri, 12 Jun 2009 15:35:19 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 14:41:07 -0000 ----- Original Message ----- From: "Alexey Melnikov" To: "Cullen Jennings" Cc: Sent: Wednesday, June 10, 2009 7:43 PM Subject: Re: TLS server identity verification > Cullen Jennings wrote: > > > I think it might be good to consider the wildcard issue a bit deeper > > too. It might be good good for the cookbook to have two things > > specified, ones that allows wildcard and one that does not. > > +1. The most recent treatment I have seen is in RFC5425 s5.2. Note that when wildcards are allowed, then they have two uses, one in the dNSName, the other in the reference identity. I would like to see both covered. I like the idea of a cookbook because that to me includes a variety of approaches, from which a user can select a menu appropriate to their situation, such as section 3.1A and 4.2C. Tom Petch From phoffman@imc.org Fri Jun 12 08:21:42 2009 Return-Path: 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 E2F2B3A6C7C for ; Fri, 12 Jun 2009 08:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, J_CHICKENPOX_26=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 TPAaSz-zPYe7 for ; Fri, 12 Jun 2009 08:21:42 -0700 (PDT) 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 D803F3A6918 for ; Fri, 12 Jun 2009 08:21:41 -0700 (PDT) Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5CFLkSP004773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Jun 2009 08:21:48 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <1977B30B-B8B7-4642-827D-F546EC643906@isode.com> References: <4A26FA6A.2060902@stpeter.im> <4A299F4C.2000003@isode.com> <4A2C1577.6060802@isode.com> <4A2CE34D.8060508@isode.com> <1977B30B-B8B7-4642-827D-F546EC643906@isode.com> Date: Fri, 12 Jun 2009 08:20:34 -0700 To: Kurt Zeilenga From: Paul Hoffman Subject: Re: Deprecating DNS names in the subjectName in draft-saintandre-tls-server-id-check Content-Type: text/plain; charset="us-ascii" Cc: 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: , X-List-Received-Date: Fri, 12 Jun 2009 15:21:43 -0000 At 7:15 AM -0700 6/12/09, Kurt Zeilenga wrote: >On Jun 8, 2009, at 7:02 AM, Paul Hoffman wrote: > >>> >>>Of course the document needs to be clear on what it means about left-to-right RDN ordering versa right-to-left RDN ordering. So some text needs to be added to clarify, or the confusing sentence needs to be removed. >> >>Fully agree. Examples of where it is and is not OK to look would be helpful here. > >The document should say that when CN=domain AVA is used, AVA? >this AVA ought be the only AVA in the RDN (not a multi-valued RDN), and the RDN ought to be least significant RDN of the DN. (Avoid the left-to-right/right-to-left descriptions, as these terms are based upon text representations of DNs, what matters is placement in the abstract value.) We can argue whether "ought" above translates to MUST or SHOULD in the document. That's an important discussion. I am pretty sure I have seen certs with DNs with multiple CNs with different domain names in the past. >However, IIRC, there are CAs which place the CN=domain AVA in a multi-valued RDN and/or place the RDN somewhere other than the least-significant RDN. Both of which are problematic, but for different reasons. ...and therefore we need to describe the problems. From phoffman@imc.org Fri Jun 12 08:27:00 2009 Return-Path: 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 A8A3B3A6CD3 for ; Fri, 12 Jun 2009 08:27:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.296 X-Spam-Level: X-Spam-Status: No, score=-2.296 tagged_above=-999 required=5 tests=[AWL=0.303, 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 FMbPkzTiyAch for ; Fri, 12 Jun 2009 08:27:00 -0700 (PDT) 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 974AC3A6CCD for ; Fri, 12 Jun 2009 08:26:59 -0700 (PDT) Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5CFLkSR004773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Jun 2009 08:21:48 -0700 (MST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <2D334AFB-3D9F-4E5C-9F5E-53F6DD881C05@isode.com> References: <4A26FA6A.2060902@stpeter.im> <4A299F4C.2000003@isode.com> <4A2C1577.6060802@isode.com> <4A2CE34D.8060508@isode.com> <2D334AFB-3D9F-4E5C-9F5E-53F6DD881C05@isode.com> Date: Fri, 12 Jun 2009 08:21:45 -0700 To: Kurt Zeilenga , Alexey Melnikov From: Paul Hoffman Subject: Re: Deprecating DNS names in the subjectName in draft-saintandre-tls-server-id-check Content-Type: text/plain; charset="us-ascii" Cc: 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: , X-List-Received-Date: Fri, 12 Jun 2009 15:27:00 -0000 At 7:23 AM -0700 6/12/09, Kurt Zeilenga wrote: >But if the document doesn't discuss verification by DC naming, it doesn't need to say anything about DC naming. Given that some current systems do validate on DC names, I think we *do* need to say "DC matching is not allowed in this profile". From timbray@gmail.com Fri Jun 12 09:06:29 2009 Return-Path: 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 DED433A6A01 for ; Fri, 12 Jun 2009 09:06:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 qU6JevNHB+MB for ; Fri, 12 Jun 2009 09:06:29 -0700 (PDT) Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id B99A73A68E0 for ; Fri, 12 Jun 2009 09:06:28 -0700 (PDT) Received: by ewy6 with SMTP id 6so3112175ewy.37 for ; Fri, 12 Jun 2009 09:06:32 -0700 (PDT) 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:content-transfer-encoding; bh=RAzLRoZxFGc8UrpRmlr0RpDNPMAB3YaC3j6OTjyceBY=; b=hZAs2MyI/+xdj9P+P0MekJy0loYwkA89ZyGEO5HCZ/rxsuqWBqRvm7OhWf3WMon71h iS76Y9EdCzRGHuhUuFM+KoLbKNl9pe9qrYNPSn71lnZaRZNXnc5GlyQNgelC6jnVWfn1 H3YWGIw9yZxwy0dZwRtLkreAAGfms/FYkoEIY= 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 :content-transfer-encoding; b=N4U4Siq5TAe8EdHrXJ9/bQXlLwI1v8rpbB9RzHXzUJ3VDqUHcP8nzPLfWtxQBL0f69 CEQYTmKWJ1Gr+bYfhyYfn3Goy+0Z3Bycu0Jx5VyjQW9rCn//Bz1mirr0bd/WDRA62Vpv L2QL901+GTkZd2slJ4hh3g+lZZMGADgJayXXs= MIME-Version: 1.0 Sender: timbray@gmail.com Received: by 10.210.91.17 with SMTP id o17mr4570046ebb.71.1244822792305; Fri, 12 Jun 2009 09:06:32 -0700 (PDT) In-Reply-To: <23E3F46C-47E8-4FCC-9C70-C21BEC0D9CD4@mnot.net> References: <23E3F46C-47E8-4FCC-9C70-C21BEC0D9CD4@mnot.net> Date: Fri, 12 Jun 2009 09:06:31 -0700 X-Google-Sender-Auth: e7ca7c161d72037b Message-ID: <517bf110906120906u2b00e170w600bcd00bb69324a@mail.gmail.com> Subject: Re: FYI: Apache Avro From: Tim Bray To: Mark Nottingham Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org 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: , X-List-Received-Date: Fri, 12 Jun 2009 16:06:30 -0000 On Fri, Jun 12, 2009 at 6:11 AM, Mark Nottingham wrote: > Yet another data representation / schema / RPC: > =A0http://people.apache.org/~cutting/avro/ Has a bit of an ASN.1 feel to it. But I'm sure Doug knows that unfortunate history... -Tim > > -- > Mark Nottingham =A0 =A0 http://www.mnot.net/ > > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From Kurt.Zeilenga@isode.com Fri Jun 12 09:23:21 2009 Return-Path: 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 8FF883A6B2F for ; Fri, 12 Jun 2009 09:23:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.271 X-Spam-Level: X-Spam-Status: No, score=-2.271 tagged_above=-999 required=5 tests=[AWL=-0.272, BAYES_00=-2.599, J_CHICKENPOX_26=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 GmJIyAfxTPGl for ; Fri, 12 Jun 2009 09:23:20 -0700 (PDT) Received: from boole.openldap.org (boole.openldap.org [IPv6:2001:4f8:3:ba:219:21ff:fe2f:68d5]) by core3.amsl.com (Postfix) with ESMTP id A4FAA3A6AD6 for ; Fri, 12 Jun 2009 09:23:20 -0700 (PDT) Received: from [192.168.1.101] (75-141-233-128.dhcp.nv.charter.com [75.141.233.128] (may be forged)) (authenticated bits=0) by boole.openldap.org (8.14.3/8.14.3) with ESMTP id n5CGNNP7067443; Fri, 12 Jun 2009 16:23:24 GMT (envelope-from Kurt.Zeilenga@isode.com) Message-Id: From: Kurt Zeilenga To: Paul Hoffman In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: Deprecating DNS names in the subjectName in draft-saintandre-tls-server-id-check Date: Fri, 12 Jun 2009 09:23:23 -0700 References: <4A26FA6A.2060902@stpeter.im> <4A299F4C.2000003@isode.com> <4A2C1577.6060802@isode.com> <4A2CE34D.8060508@isode.com> <1977B30B-B8B7-4642-827D-F546EC643906@isode.com> X-Mailer: Apple Mail (2.935.3) Cc: 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: , X-List-Received-Date: Fri, 12 Jun 2009 16:23:21 -0000 On Jun 12, 2009, at 8:20 AM, Paul Hoffman wrote: > At 7:15 AM -0700 6/12/09, Kurt Zeilenga wrote: >> On Jun 8, 2009, at 7:02 AM, Paul Hoffman wrote: >> >>>> >>>> Of course the document needs to be clear on what it means about >>>> left-to-right RDN ordering versa right-to-left RDN ordering. So >>>> some text needs to be added to clarify, or the confusing sentence >>>> needs to be removed. >>> >>> Fully agree. Examples of where it is and is not OK to look would >>> be helpful here. >> >> The document should say that when CN=domain AVA is used, > > AVA? Attribute Value Assertion. > >> this AVA ought be the only AVA in the RDN (not a multi-valued RDN), >> and the RDN ought to be least significant RDN of the DN. (Avoid >> the left-to-right/right-to-left descriptions, as these terms are >> based upon text representations of DNs, what matters is placement >> in the abstract value.) We can argue whether "ought" above >> translates to MUST or SHOULD in the document. > > That's an important discussion. I am pretty sure I have seen certs > with DNs with multiple CNs with different domain names in the past. > >> However, IIRC, there are CAs which place the CN=domain AVA in a >> multi-valued RDN and/or place the RDN somewhere other than the >> least-significant RDN. Both of which are problematic, but for >> different reasons. > > ...and therefore we need to describe the problems. > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From Nicolas.Williams@sun.com Fri Jun 12 12:37:30 2009 Return-Path: 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 BE7C13A6858 for ; Fri, 12 Jun 2009 12:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.758 X-Spam-Level: X-Spam-Status: No, score=-5.758 tagged_above=-999 required=5 tests=[AWL=0.288, 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 8H65dGSHT40P for ; Fri, 12 Jun 2009 12:37:30 -0700 (PDT) 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 B44C03A697D for ; Fri, 12 Jun 2009 12:37:21 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n5CJbPl2027155 for ; Fri, 12 Jun 2009 19:37:28 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n5CJbPH6020515 for ; Fri, 12 Jun 2009 13:37:25 -0600 (MDT) 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 n5CJRKo2007751; Fri, 12 Jun 2009 14:27:20 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n5CJRJRC007750; Fri, 12 Jun 2009 14:27:19 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Fri, 12 Jun 2009 14:27:19 -0500 From: Nicolas Williams To: Tim Bray Subject: Re: FYI: Apache Avro Message-ID: <20090612192719.GC1049@Sun.COM> References: <23E3F46C-47E8-4FCC-9C70-C21BEC0D9CD4@mnot.net> <517bf110906120906u2b00e170w600bcd00bb69324a@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <517bf110906120906u2b00e170w600bcd00bb69324a@mail.gmail.com> User-Agent: Mutt/1.5.7i Cc: 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: , X-List-Received-Date: Fri, 12 Jun 2009 19:37:30 -0000 On Fri, Jun 12, 2009 at 09:06:31AM -0700, Tim Bray wrote: > On Fri, Jun 12, 2009 at 6:11 AM, Mark Nottingham wrote: > > Yet another data representation / schema / RPC: > >  http://people.apache.org/~cutting/avro/ > > Has a bit of an ASN.1 feel to it. But I'm sure Doug knows that > unfortunate history... -Tim It looks like JSON-based syntax with a PER-like encoding, plus always sending the schema with the data, so that one can always decode encoded data (much as one always could do that with TLV encodings like BER/DER/ CER, only better since the schema gives you more info than the BER tags ever did). I can see why everyone wants their own syntax (ASN.1 is famously difficult to parse, and JSON is easier to deal with than XML), but if you're going to use a PER-like encoding, why not just use PER? (Or XDR, which is very much like a subset of PER with 4-octet alignment.) It's like we are condemned to re-invent the wheel. Nico -- From vesely@tana.it Sun Jun 14 07:47:16 2009 Return-Path: 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 9CF0C3A6A56 for ; Sun, 14 Jun 2009 07:47:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.048 X-Spam-Level: X-Spam-Status: No, score=0.048 tagged_above=-999 required=5 tests=[AWL=-0.316, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, URIBL_RHS_DOB=1.083] 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 GW-l8EDum48p for ; Sun, 14 Jun 2009 07:47:12 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 9510F28C0F5 for ; Sun, 14 Jun 2009 07:47:12 -0700 (PDT) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Sun, 14 Jun 2009 16:47:17 +0200 id 00000000005DC036.000000004A350D75.00005001 Message-ID: <4A350D75.3020706@tana.it> Date: Sun, 14 Jun 2009 16:47:17 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Nicolas Williams Subject: Re: FYI: Apache Avro References: <23E3F46C-47E8-4FCC-9C70-C21BEC0D9CD4@mnot.net> <517bf110906120906u2b00e170w600bcd00bb69324a@mail.gmail.com> <20090612192719.GC1049@Sun.COM> In-Reply-To: <20090612192719.GC1049@Sun.COM> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: 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: , X-List-Received-Date: Sun, 14 Jun 2009 14:47:16 -0000 Nicolas Williams wrote: >> On Fri, Jun 12, 2009 at 6:11 AM, Mark Nottingham wrote: >> > Yet another data representation / schema / RPC: >> > http://people.apache.org/~cutting/avro/ > I can see why everyone wants their own syntax (ASN.1 is famously > difficult to parse, and JSON is easier to deal with than XML), but if > you're going to use a PER-like encoding, why not just use PER? (Or XDR, > which is very much like a subset of PER with 4-octet alignment.) A similar question has been answered (for Google's protocol buffers) in http://markmail.org/message/i7vkkeh3bycmwh4l . It seems one needs new names and specifications to refine previous ideas. (And this new-vs-updated dilemma has a special flavor on a IETF list.) > It's like we are condemned to re-invent the wheel. Looks like, but isn't. Nowadays it's easy to write applications that are trivially portable to different machines and OSes. Yet, it's not obvious how to port ideas across different dynamic environments. Given that the differences between avro and, say, XDR are undistinguished, what are the analogous of a source and a compiler that would allow to obtain both objects from the same idea? Considering that we've been knowing that there is a gap between the physical word and our "metaphysical" minds since the days of Plato, one may say we haven't gone very far during the past millennia. However, computers have been invented as a proof of concept to show that thinking is a physical process, and the steps in their realization may suggest that our progress rate is growing... From samj@samj.net Sun Jun 14 20:26:55 2009 Return-Path: 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 C6FB83A6A4C for ; Sun, 14 Jun 2009 20:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 coxVpz9KrJNs for ; Sun, 14 Jun 2009 20:26:54 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by core3.amsl.com (Postfix) with ESMTP id 649E03A6805 for ; Sun, 14 Jun 2009 20:26:54 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 3so2313774qwe.31 for ; Sun, 14 Jun 2009 20:27:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.85.67 with SMTP id n3mr4324091vcl.53.1245036421131; Sun, 14 Jun 2009 20:27:01 -0700 (PDT) Date: Mon, 15 Jun 2009 05:27:01 +0200 Message-ID: <21606dcf0906142027y517d22c5i78398428126f5811@mail.gmail.com> Subject: Clarifications on Web Linking with HTTP From: Sam Johnston To: apps-discuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: , X-List-Received-Date: Mon, 15 Jun 2009 03:26:55 -0000 Morning all, The HTTP Link: header enables web linking without hypermedia - that is, arbitrary content types can be linked (with attriubtes) out-of-band rather than within the payload (e.g. HTML) itself. This enables the use of HTTP as a meta-model (at least for individual resources) without having to resort to Atom, which is potentially great news for RESTful APIs. I am currently working on a real world application of Marks' Web Linking I-D[1] (OGF's Open Cloud Computing Interface - http://www.occi-wg.org/) and require clarification on a few points (which may want to end up in the I-D). - First and foremost, in the absence of the LINK and UNLINK verbs originally defined in RFC 2068[2] but specifically omitted from RFC 2616[3], what is the preferred mechanism for manipulating these links via HTTP? It appears that this header is intended for GET requests only, but presumably specifying it in POST and PUT requests would be one option that avoids the creation of [not so] "new" verbs (bearing in mind that short of accepting Link: headers from empty POST/PUT requests, it would be necessary to GET and then PUT the entire payload to update links - twice if they were reciprocal). While there was an attempt a dozen years ago to better define the relevant HTTP verbs[4], it strikes me as more sensible to follow the example of the Set-Cookie: header for this rather than WebDAV's example of creating new verbs (even if we've seen them before) but you guys are the experts. - Another concern with an arbitrary number of links is that arbitrary string length limits may be imposed by user agents, as they are with URLs. This should not be a problem where there is one link per header, but it may be where the headers are concatenated as described in RFC 2616[5]. This is a double edged sword however as some user agents have only recently added support for multiple headers of the same type[6] and it remains a problem for some[7]. - The introduction of a link relation registry at IANA makes a lot of sense, though it would be nice if these were common for HTTP, HTML, Atom and other places links appear. Perhaps namespaces (e.g. "atom:service" or "occi.state.restart") would be useful here so as to enable significantly more future extensibility. - It seems useful to be able to (optionally) specify the type (as in content type rather than relation type) of a given link, as is the case for Atom. That said, this also seems somewhat redundant with HTTP Content Negotiation, but implementations that choose to support the "type" attribute may gain some performance and usability advantages from doing so. The matter of whether this information belongs in URIs (and if so, which side of the '?') or in HTTP headers (or both) is still not clear to me as there are pros and cons of each - perhaps the relation type is more suitable (or both?) as it's often not possible to unambigously determine the relation type from the content type (consider modeling people where both fingerprint and portrait representations may exist in image/png format). To be more specific about the requirements, the API models cloud infrastructure services (IaaS) and has three main nouns (compute, network, storage) which need to be associated with each other with attributes on the links (e.g. a compute resource having a network resource associated with a local identifier attribute of "eth0"). Using Atom as the meta-model worked fine (as evidenced by GData) but it now seems possible - at least for individual resources - with HTTP. Cheers, Sam 1. http://tools.ietf.org/html/draft-nottingham-http-link-header-05 2. http://tools.ietf.org/html/rfc2068#section-19.6.1 3. http://tools.ietf.org/html/rfc2616#section-19.6.3 4. http://ftp.ics.uci.edu/pub/ietf/http/draft-pritchard-http-links-00.txt 5. http://tools.ietf.org/html/rfc2616#section-4.2 6. http://www.mail-archive.com/bug-wget@gnu.org/msg00076.html 7. http://bugs.python.org/issue1660009 From alexey.melnikov@isode.com Mon Jun 15 14:57:16 2009 Return-Path: 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 28BC63A69FF for ; Mon, 15 Jun 2009 14:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=0.135, 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 YI4n3JaYL9uB for ; Mon, 15 Jun 2009 14:57:15 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 2E0EA28C0E5 for ; Mon, 15 Jun 2009 14:57:15 -0700 (PDT) Received: from [92.40.11.139] (92.40.11.139.sub.mbb.three.co.uk [92.40.11.139]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 15 Jun 2009 22:57:20 +0100 Message-ID: <4A36C390.7030507@isode.com> Date: Mon, 15 Jun 2009 22:56:32 +0100 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 Subject: Backup Media Type reviewer for IANA MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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: , X-List-Received-Date: Mon, 15 Jun 2009 21:57:16 -0000 Ned Freed is currently the designated Expert Reviewer for Media Types (as described in RFC 4288 and RFC 4855). IANA has asked for a backup reviewer, in case Ned is on holidays, or there are too many requests for him to handle. I am looking for candidates [which will be guaranteed my nearly eternal gratitude ;-)]. From Nicolas.Williams@sun.com Tue Jun 16 11:10:20 2009 Return-Path: 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 7E0E13A6BD7 for ; Tue, 16 Jun 2009 11:10:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.749 X-Spam-Level: X-Spam-Status: No, score=-5.749 tagged_above=-999 required=5 tests=[AWL=0.297, 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 vY1UL0gxWlPO for ; Tue, 16 Jun 2009 11:10:19 -0700 (PDT) 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 E5A143A6B80 for ; Tue, 16 Jun 2009 11:10:18 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n5GIAT1K024028 for ; Tue, 16 Jun 2009 18:10:29 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n5GIAS37022801 for ; Tue, 16 Jun 2009 12:10:28 -0600 (MDT) 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 n5GI0TSf002551; Tue, 16 Jun 2009 13:00:29 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n5GI0T0I002550; Tue, 16 Jun 2009 13:00:29 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 16 Jun 2009 13:00:29 -0500 From: Nicolas Williams To: Alessandro Vesely Subject: Re: FYI: Apache Avro Message-ID: <20090616180028.GJ1308@Sun.COM> References: <23E3F46C-47E8-4FCC-9C70-C21BEC0D9CD4@mnot.net> <517bf110906120906u2b00e170w600bcd00bb69324a@mail.gmail.com> <20090612192719.GC1049@Sun.COM> <4A350D75.3020706@tana.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A350D75.3020706@tana.it> User-Agent: Mutt/1.5.7i Cc: 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: , X-List-Received-Date: Tue, 16 Jun 2009 18:10:20 -0000 On Sun, Jun 14, 2009 at 04:47:17PM +0200, Alessandro Vesely wrote: > Nicolas Williams wrote: > >>On Fri, Jun 12, 2009 at 6:11 AM, Mark Nottingham wrote: > >>> Yet another data representation / schema / RPC: > >>> http://people.apache.org/~cutting/avro/ > > >I can see why everyone wants their own syntax (ASN.1 is famously > >difficult to parse, and JSON is easier to deal with than XML), but if > >you're going to use a PER-like encoding, why not just use PER? (Or XDR, > >which is very much like a subset of PER with 4-octet alignment.) > > A similar question has been answered (for Google's protocol buffers) > in http://markmail.org/message/i7vkkeh3bycmwh4l . It seems one needs > new names and specifications to refine previous ideas. (And this > new-vs-updated dilemma has a special flavor on a IETF list.) That post has a lousy answer to the question it purports to answer. AVRO sends the schema on the wire with every message (it could just send a URL), and that is an answer to the issue in http://markmail.org/message/i7vkkeh3bycmwh4l -- inventing a new encoding is not a requirement for solving the problem that existing encodings don't send enough information about the schema. AVRO should have used PER with a JSON-based schema (instead of plain ASN.1). Instead AVRO has a new PER-like encoding that's not actually PER (re-invention). Re-inventing some things is easier to justify than others. ASN.1's syntax is hard to parse, therefore re-inventing it based on XML (done) or JSON (now also done) makes sense (and would have done the world a real favor!). But re-inventing the encoding rules doesn't really, not when so many encoding schemes have been tried over the years... ...S-expressions, BER-like TLV, PER, XDR, NDR, XML, JSON, DataDumper, ... -- endless variations these three fundamental ones: S-expressions, TLV and packed encoding. > >It's like we are condemned to re-invent the wheel. > > Looks like, but isn't. Nowadays it's easy to write applications that > are trivially portable to different machines and OSes. Yet, it's not > obvious how to port ideas across different dynamic environments. Given I don't follow this. > that the differences between avro and, say, XDR are undistinguished, > what are the analogous of a source and a compiler that would allow to > obtain both objects from the same idea? Why do you need both? Why not re-use? Anyways, the answer to your question, in the ASN.1 world, of course, is ECN (enconding control notation). No, you don't want to use it -- it will do you no good. > Considering that we've been knowing that there is a gap between the > physical word and our "metaphysical" minds since the days of Plato, > one may say we haven't gone very far during the past millennia. A silly argument for justifying re-invention, that. The real reason we re-invent, I suspect, is time pressures [+ ignorance [+ laziness]]. You have a deadline and a problem you should suspect others have solved already. What do you do? You could solve it yourself in the time it takes to write the code and docs, you could spend a sizeable portion of that time (quite possibly more!) to find out how others have solved it [over and over again], then adapt their solutions in the remaining time (quite possibly more!). (Adapting others' solutions can take a lot of work since those will likely have impedance mismatches to your development environment -- a C API but not a JavaScript one, a code generator that imposes C struct layouts on you, and so on and on). If you're a capable programmer the obviously simpler at first!) and much faster approach is to write your own solution and to heck with re-use, even if you might later come to wish you'd used off-the-shelf tools. I think that's the explanation for re-invention. Can I tell the re-inventing programmer they're wrong? Not really, or not necessarily. Is re-invention a bad thing? Not always -- sometimes the end result is better than the predecessors. Overall though, most re-invention is probably lousy, and the inescapable conclusion, if you'll grant that premise, is that it is presumptuous to re-invent the wheel without first researching previous inventions of it. A software engineer should always do some research. > However, computers have been invented as a proof of concept to show > that thinking is a physical process, and the steps in their > realization may suggest that our progress rate is growing... Practical computers were invented to solve practical problems, not to model the world, or any philosophies. Platonic object-oriented meta- schema/schema/data models come fairly late in the development of computers (after FORTRAN and LISP). If your point is that we have the same variety of philosophies in the world of computers as outside it, I think I'll concede that point :) Nico -- From cabo@tzi.org Tue Jun 16 11:35:57 2009 Return-Path: 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 EC8723A6BF4 for ; Tue, 16 Jun 2009 11:35:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=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 q0HLCwK-5aLd for ; Tue, 16 Jun 2009 11:35:57 -0700 (PDT) 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 AD02E3A6BB6 for ; Tue, 16 Jun 2009 11:35:56 -0700 (PDT) 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.3/8.14.3) with ESMTP id n5GIZwBA006724; Tue, 16 Jun 2009 20:35:58 +0200 (CEST) Received: from [192.168.217.107] (p5489C529.dip.t-dialin.net [84.137.197.41]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id 76BF3AFD2; Tue, 16 Jun 2009 20:35:58 +0200 (CEST) From: Carsten Bormann To: Nicolas Williams In-Reply-To: <20090616180028.GJ1308@Sun.COM> Subject: Re: FYI: Apache Avro References: <23E3F46C-47E8-4FCC-9C70-C21BEC0D9CD4@mnot.net> <517bf110906120906u2b00e170w600bcd00bb69324a@mail.gmail.com> <20090612192719.GC1049@Sun.COM> <4A350D75.3020706@tana.it> <20090616180028.GJ1308@Sun.COM> Message-Id: <2DFCB76A-9719-4497-95EE-5E9C9CAAE098@tzi.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 16 Jun 2009 20:35:57 +0200 X-Mailer: Apple Mail (2.935.3) Cc: apps-discuss@ietf.org, Alessandro Vesely 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: , X-List-Received-Date: Tue, 16 Jun 2009 18:35:58 -0000 On Jun 16, 2009, at 20:00, Nicolas Williams wrote: > AVRO should have used PER What do you *like* about PER? Honest question, since I have forgotten most of what I once knew about PER. I seem to remember that the decision to adopt PER created much of the interop issues that finally killed H.323. And I remember that one particularly ugly technical issue was the way PER handles extensibility. But I'm sure willing to learn about PER's good side. Gruesse, Carsten From randy_presuhn@mindspring.com Tue Jun 16 11:53:27 2009 Return-Path: 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 803833A6BC0 for ; Tue, 16 Jun 2009 11:53:27 -0700 (PDT) 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 3YUr8+FDNMjD for ; Tue, 16 Jun 2009 11:53:26 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id C11E43A6BA4 for ; Tue, 16 Jun 2009 11:53:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=B9VdtL+rRlNoTOWad7pLirgyiYbSowFs+Z0rr9pF9Qr+zcaK91jhfFo6jq6O54Qk; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [76.254.53.210] (helo=oemcomputer) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MGdmq-0003ei-RL for apps-discuss@ietf.org; Tue, 16 Jun 2009 14:53:37 -0400 Message-ID: <009f01c9eeb3$d03ec0e0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: References: <23E3F46C-47E8-4FCC-9C70-C21BEC0D9CD4@mnot.net><517bf110906120906u2b00e170w600bcd00bb69324a@mail.gmail.com><20090612192719.GC1049@Sun.COM> <4A350D75.3020706@tana.it><20090616180028.GJ1308@Sun.COM> <2DFCB76A-9719-4497-95EE-5E9C9CAAE098@tzi.org> Subject: Re: FYI: Apache Avro Date: Tue, 16 Jun 2009 11:54:00 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf69684a94e7e1d564a0625124df1e9eadf80c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 76.254.53.210 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: , X-List-Received-Date: Tue, 16 Jun 2009 18:53:27 -0000 Hi - > From: "Carsten Bormann" > To: "Nicolas Williams" > Cc: ; "Alessandro Vesely" > Sent: Tuesday, June 16, 2009 11:35 AM > Subject: Re: FYI: Apache Avro ... > But I'm sure willing to learn about PER's good side. ... For a protocol that doesn't need lots of open-ended extension capabilities or object-identifier-like things, it offers: (1) compact encoding (2) lower processing cost (2) often comes as a surprise, because the rules can seem rather arcane. But the elimination of redundant information in the encoding means fewer error cases to check for, simplifying the code path and eliminating lots of tests, as well as simply reducing the number of bits that need to be shoveled around. For a protocol where all the fields and ranges are carved out in advance, this could be helpful. But for something like SNMP, where most of the bandwidth goes to object identifiers, it's reall no help at all. Randy From Nicolas.Williams@sun.com Tue Jun 16 11:57:19 2009 Return-Path: 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 D7F1F3A6CBD for ; Tue, 16 Jun 2009 11:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.758 X-Spam-Level: X-Spam-Status: No, score=-5.758 tagged_above=-999 required=5 tests=[AWL=0.288, 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 a+isDc+xs51c for ; Tue, 16 Jun 2009 11:57:19 -0700 (PDT) Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by core3.amsl.com (Postfix) with ESMTP id A09013A6DA6 for ; Tue, 16 Jun 2009 11:57:18 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n5GIutgp012134 for ; Tue, 16 Jun 2009 18:56:55 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n5GIutgk055029 for ; Tue, 16 Jun 2009 12:56:55 -0600 (MDT) 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 n5GIksDs002667; Tue, 16 Jun 2009 13:46:55 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n5GIkm2D002666; Tue, 16 Jun 2009 13:46:48 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 16 Jun 2009 13:46:48 -0500 From: Nicolas Williams To: Carsten Bormann Subject: Re: FYI: Apache Avro Message-ID: <20090616184648.GM1308@Sun.COM> References: <23E3F46C-47E8-4FCC-9C70-C21BEC0D9CD4@mnot.net> <517bf110906120906u2b00e170w600bcd00bb69324a@mail.gmail.com> <20090612192719.GC1049@Sun.COM> <4A350D75.3020706@tana.it> <20090616180028.GJ1308@Sun.COM> <2DFCB76A-9719-4497-95EE-5E9C9CAAE098@tzi.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2DFCB76A-9719-4497-95EE-5E9C9CAAE098@tzi.org> User-Agent: Mutt/1.5.7i Cc: apps-discuss@ietf.org, Alessandro Vesely 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: , X-List-Received-Date: Tue, 16 Jun 2009 18:57:19 -0000 On Tue, Jun 16, 2009 at 08:35:57PM +0200, Carsten Bormann wrote: > On Jun 16, 2009, at 20:00, Nicolas Williams wrote: > > >AVRO should have used PER > > What do you *like* about PER? > Honest question, since I have forgotten most of what I once knew about > PER. It's not so much that I like it, but that AVRO's encoding is so similar to it. Why stop at being similar? For example, the "zig zag" encoding of integers is sooo, odd. Why?? Why not any of the heretofore tried and true encodings of integers? > I seem to remember that the decision to adopt PER created much of the > interop issues that finally killed H.323. I've no knowledge of that. And even if something like that happened it may say nothing about the applicability of PER to AVRO -- what were the interop issues about? > And I remember that one particularly ugly technical issue was the way > PER handles extensibility. I think it handles it quite nicely, actually. Nico -- From Nicolas.Williams@sun.com Tue Jun 16 12:26:18 2009 Return-Path: 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 13CCF3A6BF0 for ; Tue, 16 Jun 2009 12:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.767 X-Spam-Level: X-Spam-Status: No, score=-5.767 tagged_above=-999 required=5 tests=[AWL=0.279, 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 5f0BGSPUWKlL for ; Tue, 16 Jun 2009 12:26:16 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by core3.amsl.com (Postfix) with ESMTP id EBD4D3A6BC0 for ; Tue, 16 Jun 2009 12:26:15 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n5GJQRPp027382 for ; Tue, 16 Jun 2009 19:26:27 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 n5GJQO6D053580 for ; Tue, 16 Jun 2009 13:26:24 -0600 (MDT) 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 n5GJGOrC002689; Tue, 16 Jun 2009 14:16:24 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n5GJGO04002688; Tue, 16 Jun 2009 14:16:24 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 16 Jun 2009 14:16:24 -0500 From: Nicolas Williams To: Carsten Bormann Subject: Re: Re: FYI: Apache Avro Message-ID: <20090616191624.GC1261@Sun.COM> References: <23E3F46C-47E8-4FCC-9C70-C21BEC0D9CD4@mnot.net> <517bf110906120906u2b00e170w600bcd00bb69324a@mail.gmail.com> <20090612192719.GC1049@Sun.COM> <4A350D75.3020706@tana.it> <20090616180028.GJ1308@Sun.COM> <2DFCB76A-9719-4497-95EE-5E9C9CAAE098@tzi.org> <20090616184648.GM1308@Sun.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090616184648.GM1308@Sun.COM> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: apps-discuss@ietf.org, Alessandro Vesely 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: , X-List-Received-Date: Tue, 16 Jun 2009 19:26:18 -0000 On Tue, Jun 16, 2009 at 01:46:48PM -0500, Nicolas Williams wrote: > On Tue, Jun 16, 2009 at 08:35:57PM +0200, Carsten Bormann wrote: > > And I remember that one particularly ugly technical issue was the way > > PER handles extensibility. > > I think it handles it quite nicely, actually. I should add, PER handles extensibility thusly (from memory): by adding a single bit to the encoding of a value that indicates whether the type was extended, and if it was there's a length field so that decoders that don't know the extension can skip it. Similarly, extensible constraints on simple types are encoded as a single bit followed by the value in constrained or unconstrained encoding according to the bit's value. Extensible constraints on SEQUENCE OF are dealt with similarly. Where BER encodes CHOICE implicitly via BER's tagging, PER indicates which CHOICE arm was taken with a small integer that counts CHOICE arms from 0 (ignores explicit and implicit tags altogether). Presence/ absence of OPTIONAL or DEFAULT fields of a SEQUENCE is encoded as a bitmask with as many bits as optional/default fields. Etcetera. All this is well documented. The ITU-T ASN.1 specs are very readable (more so even than the various books on the topic, IMO). AVRO's documentation does not match the ITU-T ASN.1 specs in completeness or readability (it didn't when I checked). I.e., PER encodes extensions, presence/absence, in as few bits as possible, as few as one bit when there's no extension/extended constraint, or one bit plus length or variable-length value encoding when there is. Pretty clever. XDR is very similar to PER, but much less compact, and without support for certain ASN.1 features, though these can typically be modelled atop XDR anyways (e.g., optional fields -> use of '*' in XDR, extensibility markers -> opaque<> field or discriminated union with a single, default void arm, ...). AVRO's encoding is similarly similar to PER. Nico -- From vesely@tana.it Wed Jun 17 01:55:31 2009 Return-Path: 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 80D2C3A682F for ; Wed, 17 Jun 2009 01:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.525 X-Spam-Level: X-Spam-Status: No, score=-0.525 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 aX3crevJZx8G for ; Wed, 17 Jun 2009 01:55:30 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 9004A3A6813 for ; Wed, 17 Jun 2009 01:55:30 -0700 (PDT) Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Wed, 17 Jun 2009 10:55:38 +0200 id 00000000005DC030.000000004A38AF8A.0000459E Message-ID: <4A38AF8A.7020407@tana.it> Date: Wed, 17 Jun 2009 10:55:38 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Nicolas Williams Subject: the wheel - was: Re: FYI: Apache Avro References: <23E3F46C-47E8-4FCC-9C70-C21BEC0D9CD4@mnot.net> <517bf110906120906u2b00e170w600bcd00bb69324a@mail.gmail.com> <20090612192719.GC1049@Sun.COM> <4A350D75.3020706@tana.it> <20090616180028.GJ1308@Sun.COM> In-Reply-To: <20090616180028.GJ1308@Sun.COM> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: 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: , X-List-Received-Date: Wed, 17 Jun 2009 08:55:31 -0000 Nicolas Williams wrote: >>> It's like we are condemned to re-invent the wheel. >> [The] differences between avro and, say, XDR are undistinguished > > Why do you need both? Why not re-use? For practical issues, e.g. backward compatibility. > Anyways, the answer to your > question, in the ASN.1 world, of course, is ECN (enconding control > notation). No, you don't want to use it -- it will do you no good. I.e. it's not quite practical or general. >> Considering that we've been knowing that there is a gap between the >> physical word and our "metaphysical" minds since the days of Plato, >> one may say we haven't gone very far during the past millennia. > > A silly argument for justifying re-invention, that. The real reason we > re-invent, I suspect, is time pressures [+ ignorance [+ laziness]]. That's correct, but is POV-specific. > If you're a capable programmer the obviously simpler at first!) and much > faster approach is to write your own solution and to heck with re-use, > even if you might later come to wish you'd used off-the-shelf tools. Agreed. > I think that's the explanation for re-invention. Can I tell the > re-inventing programmer they're wrong? Not really, or not necessarily. > Is re-invention a bad thing? Not always -- sometimes the end result is > better than the predecessors. Yeah, someone wrote the code is good only after it has been rewritten at least three times. > Overall though, most re-invention is probably lousy, and the inescapable > conclusion, if you'll grant that premise, is that it is presumptuous to > re-invent the wheel without first researching previous inventions of it. > A software engineer should always do some research. From the other POV, existing solutions are not yet so good. E.g. not general or practical enough. Possibly, not sufficiently advertised. >> However, computers have been invented as a proof of concept to show >> that thinking is a physical process > > Practical computers were invented to solve practical problems, not to > model the world, or any philosophies. Platonic object-oriented meta- > schema/schema/data models come fairly late in the development of > computers (after FORTRAN and LISP). Pascal, Babbage, Turing, and others came before that. Of course, the practical problem is what makes pressure, rises funds, and requires realistic schedules. (Babbage, for one, never actually built his analytic computer.) However, practical solutions would never have ventured into if the way hadn't been paved already. The point in realizing what steps we took at what times was just to reassure that the wheel is actually a spiral, in the sense that there is some progress on each round of the loop. Correctly guessing where progress is directed may help. From Nicolas.Williams@sun.com Wed Jun 17 09:19:05 2009 Return-Path: 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 B16BD3A6940 for ; Wed, 17 Jun 2009 09:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.69 X-Spam-Level: X-Spam-Status: No, score=-5.69 tagged_above=-999 required=5 tests=[AWL=0.356, 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 1BvtSXbHWmej for ; Wed, 17 Jun 2009 09:19:04 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by core3.amsl.com (Postfix) with ESMTP id 4B29A3A6B82 for ; Wed, 17 Jun 2009 09:19:03 -0700 (PDT) Received: from dm-central-02.central.sun.com ([129.147.62.5]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n5HGJCbU008594 for ; Wed, 17 Jun 2009 16:19:13 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 n5HGJCQY033750 for ; Wed, 17 Jun 2009 10:19:12 -0600 (MDT) 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 n5HG9CJT003144; Wed, 17 Jun 2009 11:09:12 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n5HG9Bn5003143; Wed, 17 Jun 2009 11:09:11 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 17 Jun 2009 11:09:11 -0500 From: Nicolas Williams To: Alessandro Vesely Subject: Re: the wheel - was: Re: FYI: Apache Avro Message-ID: <20090617160911.GF1308@Sun.COM> References: <23E3F46C-47E8-4FCC-9C70-C21BEC0D9CD4@mnot.net> <517bf110906120906u2b00e170w600bcd00bb69324a@mail.gmail.com> <20090612192719.GC1049@Sun.COM> <4A350D75.3020706@tana.it> <20090616180028.GJ1308@Sun.COM> <4A38AF8A.7020407@tana.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A38AF8A.7020407@tana.it> User-Agent: Mutt/1.5.7i Cc: 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: , X-List-Received-Date: Wed, 17 Jun 2009 16:19:05 -0000 On Wed, Jun 17, 2009 at 10:55:38AM +0200, Alessandro Vesely wrote: > Nicolas Williams wrote: > >>>It's like we are condemned to re-invent the wheel. > >>[The] differences between avro and, say, XDR are undistinguished > > > >Why do you need both? Why not re-use? > > For practical issues, e.g. backward compatibility. What does a new wheel have to be compatible with? > >I think that's the explanation for re-invention. Can I tell the > >re-inventing programmer they're wrong? Not really, or not necessarily. > >Is re-invention a bad thing? Not always -- sometimes the end result is > >better than the predecessors. > > Yeah, someone wrote the code is good only after it has been rewritten > at least three times. Supposing that's always true, then it should generally be better to fix existing wheels to do what you want than to invent ones, except when the existing wheels have had too many fixes and so don't work as well as new ones might. But also, consider that there are two levels of re-invention here: implementation, and encoding specification. If you can't find any tools that produce a, say, PER encoder/decoder the way you want it, then you can build a new tool to do that -- why build a new encoding specification along the way?? > >Overall though, most re-invention is probably lousy, and the inescapable > >conclusion, if you'll grant that premise, is that it is presumptuous to > >re-invent the wheel without first researching previous inventions of it. > >A software engineer should always do some research. > > From the other POV, existing solutions are not yet so good. E.g. not > general or practical enough. Possibly, not sufficiently advertised. But are you referring to implementation or specification? (see above) > >>However, computers have been invented as a proof of concept to show > >>that thinking is a physical process > > > >Practical computers were invented to solve practical problems, not to > >model the world, or any philosophies. Platonic object-oriented meta- > >schema/schema/data models come fairly late in the development of > >computers (after FORTRAN and LISP). > > Pascal, Babbage, Turing, and others came before that. Of course, the > practical problem is what makes pressure, rises funds, and requires > realistic schedules. (Babbage, for one, never actually built his > analytic computer.) However, practical solutions would never have > ventured into if the way hadn't been paved already. > > The point in realizing what steps we took at what times was just to > reassure that the wheel is actually a spiral, in the sense that there > is some progress on each round of the loop. Correctly guessing where > progress is directed may help. Not every addition is necessarily an improvement. One should not dismiss re-use on the theory that what comes next will be better than what came before. I fully expect _existing_ implementations of various things to be useless to you, but not the protocols. Consider this: something better than HTTP is certainly feasible, but would you reject out of hand any suggestion that you use HTTP? As you say, practical considerations would almost certainly drive you to embrace HTTP. The world of encoding doesn't have a clear winner, therefore it's easy to be unaware of the choices and invent new ones. Whoever wrote AVRO's encoder should think about what justifications they would have had for the choice they made, but with full knowledge of the choices they really had. It's possible that they'd conclude that PER/XDR/NDR/... were each somewhat wide of the mark, it's almost certain that they'd conclude that existing tools for those were wide of the mark. But I'm interested in the former, in why the existing encodings were all inappropriate (if nothing else, so we can learn from that). If it turns out that there are no good reasons for inventing a new encoding, oh well, it'll only be one more in the huge pile that we have already. And knowing that will not help us much because there's no way to transmit that knowledge to the next person in a position to re-invent this wheel. Nico -- From Nicolas.Williams@sun.com Wed Jun 17 09:25:24 2009 Return-Path: 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 AF4263A6B82 for ; Wed, 17 Jun 2009 09:25:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.7 X-Spam-Level: X-Spam-Status: No, score=-5.7 tagged_above=-999 required=5 tests=[AWL=0.346, 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 qRwwM8oVG3MW for ; Wed, 17 Jun 2009 09:25:23 -0700 (PDT) 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 3E9C13A6876 for ; Wed, 17 Jun 2009 09:25:23 -0700 (PDT) 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 n5HGPWH4021873 for ; Wed, 17 Jun 2009 16:25:32 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 n5HGPW1m038346 for ; Wed, 17 Jun 2009 10:25:32 -0600 (MDT) 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 n5HGFWAb003150; Wed, 17 Jun 2009 11:15:32 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n5HGFVcC003149; Wed, 17 Jun 2009 11:15:32 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Wed, 17 Jun 2009 11:15:31 -0500 From: Nicolas Williams To: Randy Presuhn Subject: Re: FYI: Apache Avro Message-ID: <20090617161531.GG1308@Sun.COM> References: <23E3F46C-47E8-4FCC-9C70-C21BEC0D9CD4@mnot.net> <517bf110906120906u2b00e170w600bcd00bb69324a@mail.gmail.com> <20090612192719.GC1049@Sun.COM> <4A350D75.3020706@tana.it> <20090616180028.GJ1308@Sun.COM> <2DFCB76A-9719-4497-95EE-5E9C9CAAE098@tzi.org> <009f01c9eeb3$d03ec0e0$6801a8c0@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <009f01c9eeb3$d03ec0e0$6801a8c0@oemcomputer> User-Agent: Mutt/1.5.7i Cc: 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: , X-List-Received-Date: Wed, 17 Jun 2009 16:25:24 -0000 On Tue, Jun 16, 2009 at 11:54:00AM -0700, Randy Presuhn wrote: > > But I'm sure willing to learn about PER's good side. > ... > > For a protocol that doesn't need lots of open-ended extension > capabilities or object-identifier-like things, it offers: > > (1) compact encoding > (2) lower processing cost > > (2) often comes as a surprise, because the rules can seem rather > arcane. But the elimination of redundant information in the > encoding means fewer error cases to check for, simplifying > the code path and eliminating lots of tests, as well as simply > reducing the number of bits that need to be shoveled around. Indeed. (2) is a surprise mostly because of the rules (which are not so much arcane as detailed). But if you look at protocols like IP, TCP, ..., ones with fixed-width fields and bags-of-options (often simple enough to be described with ASCII art, and everyone agrees that their encodings are simple to process), they are very similar in layout to the PER encoding of an ASN.1 schema description of those protocols. That's because PER was designed to produce that sort of protocol. > For a protocol where all the fields and ranges are carved out > in advance, this could be helpful. > But for something like SNMP, where most of the bandwidth > goes to object identifiers, it's reall no help at all. Perhaps. But my point isn't: retrofit PER everywhere because PER is soo cool. My point is: don't re-invent PER if that's what you need. To me it looks like AVRO's encoding has similar properties to PER and gratouitous differences from it (i.e., it looks pointless). Nico -- From alexey.melnikov@isode.com Sat Jun 20 05:29:54 2009 Return-Path: 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 C4E673A6BE1 for ; Sat, 20 Jun 2009 05:29:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.461 X-Spam-Level: X-Spam-Status: No, score=-2.461 tagged_above=-999 required=5 tests=[AWL=0.138, 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 HVEWc0KYZj3g for ; Sat, 20 Jun 2009 05:29:54 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id ECFDE3A680D for ; Sat, 20 Jun 2009 05:29:53 -0700 (PDT) Received: from [92.40.139.79] (92.40.139.79.sub.mbb.three.co.uk [92.40.139.79]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sat, 20 Jun 2009 13:30:06 +0100 Message-ID: <4A3CD61D.6060004@isode.com> Date: Sat, 20 Jun 2009 13:29:17 +0100 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 Subject: www.apps.ietf.org website MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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: , X-List-Received-Date: Sat, 20 Jun 2009 12:29:54 -0000 I have 2 questions for people: 1). Do people use it and do they think it needs to be brought up-to-date? 2). If the answer to the first question is Yes, who is willing to help out with reviewing/editing its content? Regards, Alexey From john-ietf@jck.com Sat Jun 20 06:41:53 2009 Return-Path: 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 0AF303A6CED for ; Sat, 20 Jun 2009 06:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.412 X-Spam-Level: X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[AWL=0.187, 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 R9eqEuZB6xLz for ; Sat, 20 Jun 2009 06:41:52 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 2D03D3A6CB8 for ; Sat, 20 Jun 2009 06:41:52 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1MI0pZ-00025V-4W; Sat, 20 Jun 2009 09:42:05 -0400 Date: Sat, 20 Jun 2009 09:42:04 -0400 From: John C Klensin To: Alexey Melnikov , Apps Discuss Subject: Re: www.apps.ietf.org website Message-ID: <67AD6903A573DD6FD8440762@PST.JCK.COM> In-Reply-To: <4A3CD61D.6060004@isode.com> References: <4A3CD61D.6060004@isode.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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: , X-List-Received-Date: Sat, 20 Jun 2009 13:41:53 -0000 --On Saturday, June 20, 2009 13:29 +0100 Alexey Melnikov wrote: > I have 2 questions for people: > > 1). Do people use it and do they think it needs to be brought > up-to-date? I had forgotten it was there. After taking a quick look, I think one can infer that the degree to which it appears to be out of date and unmaintained without anyone noticing and complaining may be a sign of its level of use. There is some material there that might usefully be retained, but the rest doesn't seem to justify much effort. > 2). If the answer to the first question is Yes, who is willing > to help out with reviewing/editing its content? Additional observation: this page is hard to find unless one already knows where to find it. It would probably help --with all areas-- if the link from the IETF main page (http://www.ietf.org/) was named "IETF Working Groups and Area-specific Information" (or something to that effect) rather than "IETF Working Groups". best, john From timur.shemsedinov@gmail.com Sat Jun 20 06:45:01 2009 Return-Path: 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 3BB063A69C2 for ; Sat, 20 Jun 2009 06:45:01 -0700 (PDT) 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 FvwXncfV7AbT for ; Sat, 20 Jun 2009 06:45:00 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by core3.amsl.com (Postfix) with ESMTP id 31C3B3A680D for ; Sat, 20 Jun 2009 06:45:00 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 13so326105fge.16 for ; Sat, 20 Jun 2009 06:45:10 -0700 (PDT) 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=+R6Jb8N8C7eF3kMi8s9BDLpjnHO+OIv/0Du826UoB+s=; b=dFv4kO5Z/x72UrA3I3w2gq3DfNjdlTROUqk0Ys/+J1ocTlwmQiRH4i3vERaUxxEuUk IMI1uQkbz8oj8eLOxGg57kbRp+BOqyoP+J/0tYHfb8Tbf8jdh1C60pihPHkX3gY5eITS 8nuHVfvjJvPHRRLtkzYITHFFqMYJwFDT8eg0w= 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=ALlD6g1FmVneiwF8mx4KUbLqJACkowUDA2H/FB21rk8/bGUeAmQQPZjH+LSVu2PtxZ hFfVplqPgTIjjgnShTun6qORQstZmgCmFM54E1eB2gHqlFcr9Iqmj34PbrDQ1nifZz9U rKzLYwfC/Che+AFTE4CbgDu1K61y+7EdhohOA= MIME-Version: 1.0 Received: by 10.86.1.1 with SMTP id 1mr4294267fga.0.1245505510623; Sat, 20 Jun 2009 06:45:10 -0700 (PDT) In-Reply-To: <4A3CD61D.6060004@isode.com> References: <4A3CD61D.6060004@isode.com> Date: Sat, 20 Jun 2009 16:45:10 +0300 Message-ID: <248bcd790906200645i5b301911p955c1ea9ab322642@mail.gmail.com> Subject: Re: www.apps.ietf.org website From: Timur Shemsedinov To: Alexey Melnikov Content-Type: multipart/alternative; boundary=000e0cd2548086ca8b046cc7d945 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: , X-List-Received-Date: Sat, 20 Jun 2009 13:45:01 -0000 --000e0cd2548086ca8b046cc7d945 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello, I think, everybody uses this site as index to IETF tools and resources. I do not know about any active functionality of www.apps.ietf.org except I-D, RFC and some validation tools provided by this site. Nevertheless, it is important and I belive that it shoud be up-to-date to prevent misleading of visitors. If you have any idea how to upgrade this site I would like to help ~Timur On Sat, Jun 20, 2009 at 3:29 PM, Alexey Melnikov wrote: > I have 2 questions for people: > > 1). Do people use it and do they think it needs to be brought up-to-date? > 2). If the answer to the first question is Yes, who is willing to help out > with reviewing/editing its content? > > Regards, > Alexey > > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --000e0cd2548086ca8b046cc7d945 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,

I think, everybody uses this site as index to IETF tools and = resources.=A0 I do not know about any active functionality of www.apps.ietf.org except I-D, RFC and some vali= dation tools provided by this site.=A0 Nevertheless, it is important and I = belive that it shoud be up-to-date to prevent misleading of visitors.
If you have any idea how to upgrade this site I would like to help

~= Timur

On Sat, Jun 20, 2009 at 3:29 PM, Al= exey Melnikov <alexey.melnikov@isode.com> wrote:
I have 2 question= s for people:

1). Do people use it and do they think it needs to be brought up-to-date? 2). If the answer to the first question is Yes, who is willing to help out = with reviewing/editing its content?

Regards,
Alexey

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

--000e0cd2548086ca8b046cc7d945-- From samj@samj.net Sat Jun 20 06:47:21 2009 Return-Path: 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 D408128C0DC for ; Sat, 20 Jun 2009 06:47:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[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 AweN0AfyJZPB for ; Sat, 20 Jun 2009 06:47:21 -0700 (PDT) Received: from mail-ew0-f223.google.com (mail-ew0-f223.google.com [209.85.219.223]) by core3.amsl.com (Postfix) with ESMTP id 9F85A3A680D for ; Sat, 20 Jun 2009 06:47:20 -0700 (PDT) Received: by ewy23 with SMTP id 23so314536ewy.34 for ; Sat, 20 Jun 2009 06:47:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.210.105.3 with SMTP id d3mr4610099ebc.43.1245505651672; Sat, 20 Jun 2009 06:47:31 -0700 (PDT) In-Reply-To: <248bcd790906200645i5b301911p955c1ea9ab322642@mail.gmail.com> References: <4A3CD61D.6060004@isode.com> <248bcd790906200645i5b301911p955c1ea9ab322642@mail.gmail.com> Date: Sat, 20 Jun 2009 15:47:31 +0200 Message-ID: <21606dcf0906200647l400838a7vc5812131b855d32b@mail.gmail.com> Subject: Re: www.apps.ietf.org website From: Sam Johnston To: Timur Shemsedinov Content-Type: multipart/alternative; boundary=0015174bed86ef0945046cc7e17b 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: , X-List-Received-Date: Sat, 20 Jun 2009 13:47:21 -0000 --0015174bed86ef0945046cc7e17b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit If you want something more maintainable like a CMS (Drupal) or wiki (MediaWiki) then I'll happily take care of that but I'm no subject matter expert... Sam On Sat, Jun 20, 2009 at 3:45 PM, Timur Shemsedinov < timur.shemsedinov@gmail.com> wrote: > Hello, > > I think, everybody uses this site as index to IETF tools and resources. I > do not know about any active functionality of www.apps.ietf.org except > I-D, RFC and some validation tools provided by this site. Nevertheless, it > is important and I belive that it shoud be up-to-date to prevent misleading > of visitors. > If you have any idea how to upgrade this site I would like to help > > ~Timur > > > On Sat, Jun 20, 2009 at 3:29 PM, Alexey Melnikov < > alexey.melnikov@isode.com> wrote: > >> I have 2 questions for people: >> >> 1). Do people use it and do they think it needs to be brought up-to-date? >> 2). If the answer to the first question is Yes, who is willing to help out >> with reviewing/editing its content? >> >> Regards, >> Alexey >> >> _______________________________________________ >> 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 > > --0015174bed86ef0945046cc7e17b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If you want something more maintainable like a CMS (Drupal) or wiki (MediaW= iki) then I'll happily take care of that but I'm no subject matter = expert...

Sam

On Sat, Jun 20, 2009= at 3:45 PM, Timur Shemsedinov <timur.shemsedinov@gmail.com> wrote:<= br>
Hello,

I t= hink, everybody uses this site as index to IETF tools and resources.=A0 I d= o not know about any active functionality of www.apps.ietf.org except I-D, RFC and some val= idation tools provided by this site.=A0 Nevertheless, it is important and I= belive that it shoud be up-to-date to prevent misleading of visitors.
If you have any idea how to upgrade this site I would like to help

~Timur

<= br>
On Sat, Jun 20, 2009 at 3:29 PM, Alexey Melni= kov <alexey.melnikov@isode.com> wrote:
I have 2 question= s for people:

1). Do people use it and do they think it needs to be brought up-to-date? 2). If the answer to the first question is Yes, who is willing to help out = with reviewing/editing its content?

Regards,
Alexey

_______________________________________________
Apps-Discuss mailing list
Apps-Discuss@iet= f.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


--0015174bed86ef0945046cc7e17b-- From alexey.melnikov@isode.com Sat Jun 20 10:27:07 2009 Return-Path: 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 C50303A6905 for ; Sat, 20 Jun 2009 10:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.468 X-Spam-Level: X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=0.131, 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 f8e3FF0h+SkW for ; Sat, 20 Jun 2009 10:27:07 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id DA8BB3A6B00 for ; Sat, 20 Jun 2009 10:27:06 -0700 (PDT) Received: from [92.40.139.79] (92.40.139.79.sub.mbb.three.co.uk [92.40.139.79]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sat, 20 Jun 2009 18:27:19 +0100 Message-ID: <4A3D1BBA.7070202@isode.com> Date: Sat, 20 Jun 2009 18:26:18 +0100 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: John C Klensin Subject: Re: www.apps.ietf.org website References: <4A3CD61D.6060004@isode.com> <67AD6903A573DD6FD8440762@PST.JCK.COM> In-Reply-To: <67AD6903A573DD6FD8440762@PST.JCK.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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: , X-List-Received-Date: Sat, 20 Jun 2009 17:27:07 -0000 John C Klensin wrote: >--On Saturday, June 20, 2009 13:29 +0100 Alexey Melnikov > wrote: > > >>I have 2 questions for people: >> >>1). Do people use it and do they think it needs to be brought >>up-to-date? >> >> >I had forgotten it was there. After taking a quick look, I >think one can infer that the degree to which it appears to be >out of date and unmaintained without anyone noticing and >complaining may be a sign of its level of use. There is some >material there that might usefully be retained, but the rest >doesn't seem to justify much effort. > > Right. I should have mentioned that Ned worked on updating the content of the website. He moved it to Drupal. I've asked Secretariat to update the A record for www.apps.ietf.org to point to the new one. So my second question was about maintaining the website in Drupal, if it helps. >>2). If the answer to the first question is Yes, who is willing >>to help out with reviewing/editing its content? >> >> >Additional observation: this page is hard to find unless one >already knows where to find it. It would probably help --with >all areas-- if the link from the IETF main page >(http://www.ietf.org/) was named "IETF Working Groups and >Area-specific Information" (or something to that effect) rather >than "IETF Working Groups". > > Ok, I will ask Secretariat. From randy_presuhn@mindspring.com Sun Jun 21 16:55:00 2009 Return-Path: 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 BAAE03A6D9E for ; Sun, 21 Jun 2009 16:55:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=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 DnwkkhmKXhz1 for ; Sun, 21 Jun 2009 16:55:00 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id 03A3C3A6928 for ; Sun, 21 Jun 2009 16:54:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=RpRYq5D7Wr5Yr8cehlKFbwvgKPdu5z6Tn6Sh7IPvj0Qt75vK3IzVa4dwIoYi+qzs; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [99.41.50.97] (helo=oemcomputer) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1MIWsU-0000f1-QI for discuss@apps.ietf.org; Sun, 21 Jun 2009 19:55:15 -0400 Message-ID: <005401c9f2cb$cea25dc0$6801a8c0@oemcomputer> From: "Randy Presuhn" To: "Apps Discuss" References: <4A3CD61D.6060004@isode.com> Subject: Re: www.apps.ietf.org website Date: Sun, 21 Jun 2009 16:55:50 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88884f945684cbf6968927f6db9e9e0c46420f26d7bb2c864df350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.41.50.97 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: , X-List-Received-Date: Sun, 21 Jun 2009 23:55:00 -0000 Hi - > From: "Alexey Melnikov" > To: "Apps Discuss" > Sent: Saturday, June 20, 2009 5:29 AM > Subject: www.apps.ietf.org website > > I have 2 questions for people: > > 1). Do people use it and do they think it needs to be brought up-to-date? I didn't know (or had forgotten) tht it existed, so I haven't used it. Randy From lars.eggert@nokia.com Tue Jun 23 02:12:25 2009 Return-Path: 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 C09273A6AEA for ; Tue, 23 Jun 2009 02:12:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.061, 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 uxqYRKX4UidI for ; Tue, 23 Jun 2009 02:12:25 -0700 (PDT) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id BC70E3A6A7D for ; Tue, 23 Jun 2009 02:12:24 -0700 (PDT) Received: from [192.168.0.198] (wlan.fit.nokia.com [195.148.124.254]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n5N9CYhG093298 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 23 Jun 2009 12:12:35 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: <07D7E84F-6AE2-4536-B72C-73BECA4B798F@nokia.com> From: Lars Eggert To: Alexey Melnikov In-Reply-To: <4A3D1BBA.7070202@isode.com> Content-Type: multipart/signed; boundary=Apple-Mail-16--994306463; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: www.apps.ietf.org website Date: Tue, 23 Jun 2009 12:12:29 +0300 References: <4A3CD61D.6060004@isode.com> <67AD6903A573DD6FD8440762@PST.JCK.COM> <4A3D1BBA.7070202@isode.com> X-Mailer: Apple Mail (2.935.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (mail.fit.nokia.com [195.148.124.194]); Tue, 23 Jun 2009 12:12:35 +0300 (EEST) 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: , X-List-Received-Date: Tue, 23 Jun 2009 09:12:25 -0000 --Apple-Mail-16--994306463 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On 2009-6-20, at 20:26, Alexey Melnikov wrote: > I should have mentioned that Ned worked on updating the content of the > website. He moved it to Drupal. > I've asked Secretariat to update the A record for www.apps.ietf.org to > point to the new one. > > So my second question was about maintaining the website in Drupal, > if it > helps. Also note that all areas already have a wiki on the tools pages, if you want something that is easy to maintain: http://trac.tools.ietf.org/area/app/trac/wiki Lars --Apple-Mail-16--994306463 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGQDCCAvkw ggJioAMCAQICEEi7WbMMKa2GLKFpQDaOBQEwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDgyMzE3NDMzOVoXDTA5MDgyMzE3NDMz OVowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAlwQVktJZCY89iU6jcW1XnZQN+aMgF2utCUT3H3ZKB5Jbet1SDWt0md/W 571bHjxtn9CfEJdochNL3l9f1WiJNdVbJ182557Ltx9SojqthpqtA0jKEqo2gqrf+raUj1demmo0 6ocsLqv046CrwidOp6k0RAfvkKPLhD4PD9Nk3oaZuxqBz1wY4u8Q83iWMArDeXiQxfNZnOBz5cDs VvVjTjitm3VANkbD02tNkwl5AHw7htde4yH8hIwlfzqsAtHBEah3HyOvs9b+gHg2pFz9eS+HuotY ZKycCweRs8NKXoCg+zAkVYi3zvZEH2VOuPlpMQMrB9+fLWg2UBsTeZ864wIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBMdV2U+ryV5t3nuBFH19XKflodN6Bc60GBYHHY/Z0+Cl08Q75qzTt02IILBg+/YVh/fygb 6pFrOm1sFtLN7fENBfbO2VtpFjP2lGUgbXTVT5xGM6+MtqZiBI6LqexAeY6gsd/taoUfy9fZG42d ciBA9gSGlQjjWQyG8mb5HR8L9jCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJ BgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3 DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3 MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9 fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+ uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMB Af8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgG A1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcP f6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH 2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ SLtZswwprYYsoWlANo4FATAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wOTA2MjMwOTEyMjlaMCMGCSqGSIb3DQEJBDEWBBTPzJbLeor+PV+l 2JbKPdOGRDIQGzCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEwgYcGCyqGSIb3DQEJEAILMXigdjBiMQsw CQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UE AxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEEi7WbMMKa2GLKFpQDaOBQEw DQYJKoZIhvcNAQEBBQAEggEACjrlAbYEYTDWhttgc0dlqJRrAubrLjUgHptAjDwJp8ByLZ+BlP7g vtBxKWRSdl8xMkpXbe1pha+HFc5jyYf38jrRDGUKHpvQ1Nlk9Pljd3mr9kuZr6JKSBA4Zq0Ql97A vcS8aVwb1lZDDAvhhTqh0Dnk4p4FFznK+WvQU+dsCfPsXFw9eSiYI4tCAFvS13nHywsgFhTj/JkD rLaR+xus3mYhVhQtgQDAK/S3Muwh38TScceTtKtC/bQsJJeAnAkDPVifdfa/FdvkLxlyzOaJwWm2 4cESREjZSif11R4bC18x5KvBp7JP5xulmEnIGVRIOtnNVSR2QyhDG4ucZ1YmoQAAAAAAAA== --Apple-Mail-16--994306463-- From eran@hueniverse.com Thu Jun 25 11:32:10 2009 Return-Path: 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 211933A6A78 for ; Thu, 25 Jun 2009 11:32:10 -0700 (PDT) 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=[AWL=0.000, 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 1o8naTLzN+fV for ; Thu, 25 Jun 2009 11:32:09 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id E3F613A659B for ; Thu, 25 Jun 2009 11:32:08 -0700 (PDT) Received: (qmail 20978 invoked from network); 25 Jun 2009 18:30:32 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 25 Jun 2009 18:30:31 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 25 Jun 2009 11:30:31 -0700 From: Eran Hammer-Lahav To: "apps-discuss@ietf.org" Date: Thu, 25 Jun 2009 11:30:23 -0700 Subject: LRDD Update (Resource Descriptor Discovery) and Proposed Changes Thread-Topic: LRDD Update (Resource Descriptor Discovery) and Proposed Changes Thread-Index: Acn1wwDIrfEiEY01SfuZQ7HzOXEwMg== Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234378339815C@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "www-tag@w3.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: , X-List-Received-Date: Thu, 25 Jun 2009 18:32:10 -0000 (LRDD and /host-meta were previously discussed on www-talk@w3.org. Moving f= orward, this discussion is being relocated to the IETF Application area dis= cussion list. This will be indicated in future drafts.) - A quick (re)introduction I am working on a proposal called LRDD [1] which attempts to define how a d= escriptor (metadata, information about, etc.) can be attached or associated= with a resource. LRDD, which stands for Link-based Resource Description Di= scovery (and pronounced 'lard') uses the Link Relation framework proposed b= y the Link Header draft [2]. LRDD does not define the document format of th= e descriptor itself, just how to obtain it if the URI of the resource is kn= own. Existing descriptor formats include XRDS, XRD, POWDER, Metalink, etc. As previously proposed, LRDD includes three methods for linking a resource = (identified by a URI) to another resource which describes it: 1. HTTP Link: header 2. element where supported (HTML, XTHML, ATOM) 3. Link-Pattern: records [3] in the proposed /host-meta well-known-location= document [4] The first two methods simply link to the location of the descriptor documen= t from the resource itself ( element) or via the transport protocol u= sed to retrieve it (HTTP Link: header). The third option provides a simple = mechanism to map between the resource URI to the descriptor URI using a bas= ic URI template syntax (removing the need to GET a representation of the re= source or even have one available). The obvious issue with regard to the third option is where to store the tem= plate used for mapping between resource URIs and descriptor URIs. What was = previously proposed was to create a new well-known-location resource called= /host-meta which will have a similar semantic meaning as an HTTP header fo= r the abstract 'host' entity (the combination of domain and port). A long d= iscussion of terms (host, site, origin, domain, etc.) was held on the Apps = list [5]. A discussion about placing the mapping template in a DNS record d= id not mature into a proposal but is still desired by many people. For a complete discussion of other (non link-based) methods considered see = LRDD Appendix B: Methods Suitability Analysis [6]. - Proposed changes Focusing on the third method using /host-meta, two separate discussions too= k place. The first was about the security of using a /host-meta file which = can be easily created on many social networking sites by creating an accoun= t called 'host-meta' or on URI shortners [7]. The second was about the need= in some use cases (namely OpenID) to sign the /host-meta document with som= e certificate to establish trust (this is part of a much bigger discussion = but for the purpose of this thread, we can just assume that the document ne= eds to be signed somehow). These two discussions (and the focus on current use cases that are waiting = for this to be resolved to move forward), has led to the following proposed= changes: * Introduce a new I-D called 'Well-Known' which will establish the path pre= fix /.well-known/ as a home for all future well-known-location solutions. W= e were already committing a namespace sin by curving out /host-meta as (yet= ) another well-known-location document so this will simply replace that wit= h a path prefix and a lightweight registry for documents under that path. T= he main reason for this is that people are still concerned that a list regi= stry under /host-meta will not be enough to deter future protocols from cre= ating more well-known-location documents. * Move /host-meta into this new /.well-known/ directory (http://example.com= /.well-known/host-meta) and replace its text-based document format with XRD= [8]. Since host-meta will no longer be needed as a generic link registry w= ith the introduction of a well-known directory and registry, the only use c= ase left for it is to store the URI template defined by LRDD. XRD already h= as a element under , and will support document signatur= es (which is an important requirement for some use cases). Since most use c= ases at the moment will need to speak XRD anyway, and XRD is truly a lightw= eight schema, it makes sense to use it for host-meta instead of inventing a= nother format just for that. We might drop the name host-meta altogether an= d name this XRD document under /.well-known/ something else. - Next steps * Submit a proposal for /.well-known as an I-D * Publish the first committee draft (OASIS XRI TC) of XRD * Update LRDD to use /.well-known and XRD as the third method instead of /h= ost-meta Both XRD and LRDD depend on the Link I-D to be published as RFC. Any comments, feedback, or concerns are requested. EHL [1] http://tools.ietf.org/html/draft-hammer-discovery [2] http://tools.ietf.org/html/draft-nottingham-http-link-header [3] http://tools.ietf.org/html/draft-hammer-discovery-03#section-6 [4] http://tools.ietf.org/html/draft-nottingham-site-meta [5] http://www.ietf.org/mail-archive/web/apps-discuss/current/msg00227.html [6] http://tools.ietf.org/html/draft-hammer-discovery-03#appendix-B [7] http://www.ietf.org/mail-archive/web/apps-discuss/current/msg00556.html [8] http://www.hueniverse.com/hueniverse/2009/03/xrd-document-structure.htm= l From eran@hueniverse.com Thu Jun 25 11:59:15 2009 Return-Path: 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 DB3473A69E1 for ; Thu, 25 Jun 2009 11:59:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_26=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 ycEZDzyn47vm for ; Thu, 25 Jun 2009 11:59:15 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 24C553A6FA5 for ; Thu, 25 Jun 2009 11:58:51 -0700 (PDT) Received: (qmail 26442 invoked from network); 25 Jun 2009 18:57:59 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 25 Jun 2009 18:57:58 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 25 Jun 2009 11:57:32 -0700 From: Eran Hammer-Lahav To: "apps-discuss@ietf.org" Date: Thu, 25 Jun 2009 11:57:48 -0700 Subject: URI for abstract concepts (domain, host, origin, site, etc.) Thread-Topic: URI for abstract concepts (domain, host, origin, site, etc.) Thread-Index: Acn1xtVn3VpE03KbSgOajfiMM4DE/w== Message-ID: <90C41DD21FB7C64BB94121FBBC2E7234378339816C@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: URI , "www-tag@w3.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: , X-List-Received-Date: Thu, 25 Jun 2009 18:59:15 -0000 LRDD [1] defines a way to link a descriptor (metadata, information about, e= tc.) to a resource. It keeps the document format of the descriptor out of s= cope, leaving it up to existing formats (XRDS, XRD, POWDER, Metalink, etc.)= and new format to address. Most of these descriptor formats include an element which indicates what th= e document is about - the subject of the descriptor. XRD includes the element for this purpose with xs:anyURI as its type. I believe POWDER = uses RDF's 'about' attribute in a similar way IIRC. We have some use cases in which the subject of the descriptor does not have= a URI available. LRDD uses a well-known-location document (/host-meta, soon to be replaced w= ith /.well-known/host-meta) to store information about the abstract host re= source (the combination of domain name and port number, potentially also in= cluding protocol). Over the past few years, ad-hoc protocols have been abus= ing the root resource URI to mean something beyond just the root resource o= f a domain - basically as a placeholder for information about the entire do= main or host. The lack of URI for such concepts is preventing descriptor formats from bei= ng used here because there is no valid URI available to insert into the sub= ject container. While no representation is expected for such abstract conce= pts, within the context of descriptors, being able to reference them is cri= tical. The use case at hand is using XRD as the document format for host-meta. Hos= t-meta describes attributes of the host which by itself does not currently = have a URI. We need to figure out what to put in the host-meta document's <= Subject> element which has direct impact on the trust profile and signature= (but is outside the scope of this discussion). So far I could only come up with two options: 1. Make a special case exception that when the subject is http://______/.we= ll-known/host-meta, it is treated differently than any other URI in that it= means the XRD is not about that URI (the host-meta document itself), but a= bout the abstract host resource located at ______. 2. Define a new kind of URI that can be used for abstract entities such as = "host" or "domain", but which is not an http URI because that will bring us= right back to #1. I would like to ask for feedback on the idea of proposing a new URI scheme = or a new URN namespace for this purpose, something like 'abstract'. It will look something like this (please focus on the idea, not the syntax = of the examples): urn:abstract:domain:example.com urn:abstract:host:example.com:8080 urn:abstract:origin:example.com:8080:http or abstract://example.com/domain abstract://example.com:8080/host abstract://example.com:8080:http/origin Any comments, feedback, or concerns would be greatly appreciated. EHL [1] http://tools.ietf.org/html/draft-hammer-discovery From timur.shemsedinov@gmail.com Thu Jun 25 13:48:24 2009 Return-Path: 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 E295B3A6811 for ; Thu, 25 Jun 2009 13:48:24 -0700 (PDT) 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 Zus6d--UQLLX for ; Thu, 25 Jun 2009 13:48:24 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by core3.amsl.com (Postfix) with ESMTP id A4FC43A6807 for ; Thu, 25 Jun 2009 13:48:23 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 16so209273fgg.18 for ; Thu, 25 Jun 2009 13:46:18 -0700 (PDT) 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=z0qAUe1t1JhnIPkyDXu1WFbDN8VEDe4yrTa5fIVwYwQ=; b=QjTpr+eEv+2h9xfPcvjvWGku4SckjTuOvr9n0qZfsJmNe499rKOTOZa8W7TFpzwQAn kZJQgLOnGMcetR2Dq/UQm1BNMSFGNhGpi6jz9FV5RRsxnTsG1yk6Ul8Gvk0BpPoHuHVA G5oTKy39AIex3zdHuok6wE27uT362t6JLYvEA= 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=ev/m0Jw8plhn17nYnRunrDOYNxn6wtUn9B7/Hsj+qKc72l6PumiPV3UUkYVxENSS7G j6McLfoi5+kD60hTlkxfHHVL5Wa2r7x0nmRo8RDv6L3XduKB92zGTfzm13DMjNwvd1cm 8GCz4enIVchBDO20FC9dIuOgXDZoTWiT+CuAs= MIME-Version: 1.0 Received: by 10.86.57.9 with SMTP id f9mr2981169fga.62.1245962778919; Thu, 25 Jun 2009 13:46:18 -0700 (PDT) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234378339816C@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234378339816C@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 25 Jun 2009 23:46:18 +0300 Message-ID: <248bcd790906251346j248337fy314c2344063e6422@mail.gmail.com> Subject: Re: URI for abstract concepts (domain, host, origin, site, etc.) From: Timur Shemsedinov To: Eran Hammer-Lahav Content-Type: multipart/alternative; boundary=000e0cd28bfcd742c1046d3250cd Cc: URI , "www-tag@w3.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: , X-List-Received-Date: Thu, 25 Jun 2009 20:48:25 -0000 --000e0cd28bfcd742c1046d3250cd Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello, On Thu, Jun 25, 2009 at 9:57 PM, Eran Hammer-Lahav wrote: > I would like to ask for feedback on the idea of proposing a new URI scheme > or a new URN namespace for this purpose, something like 'abstract'. > It will look something like this (please focus on the idea, not the syntax > of the examples): > > urn:abstract:domain:example.com > urn:abstract:host:example.com:8080 > urn:abstract:origin:example.com:8080:http > I think URN is not applicable for those URIs, because all those URIs includes complete information for resource location, so you should use URLs (but not http urls). > or > > abstract://example.com/domain > abstract://example.com:8080/host > abstract://example.com:8080:http/origin > > Any comments, feedback, or concerns would be greatly appreciated. "abstract" schema name is not a good idea, because level of such abstraction is unclear. "abstract" is too abstract word Better use "host" for listed purposed, like in example: If wou wont to identify/locate domain s use * host:example.com* If wou wont to identify/locate service on port use *host:example.com:8080* If wou wont to identify/locate exact http on port 8080 use * http://example.com:8080* If wou wont to identify/locate host by ip use *host:208.77.188.166 * note that you can not use "://" if URL is not designed to locate resource associated with path as in http ~Timur --000e0cd28bfcd742c1046d3250cd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,

On Thu, Jun 25, 2009 at 9:57 PM, E= ran Hammer-Lahav <eran@hueniverse.com> wrote:
=A0
I would like to ask for feedback on the idea of proposing a new URI scheme = or a new URN namespace for this purpose, something like 'abstract'.=
It will look something like this (please focus on the idea, not the syntax = of the examples):

urn:abstract:domain:exampl= e.com
urn:abstract:host:exa= mple.com:8080
urn:abstract:origin:example.com:8080:http

I think URN is not applicable for those URIs, because= all those URIs includes complete information for resource location, so you= should use URLs=A0 (but not http urls).
=A0
or

abstract://example.= com/domain
abstract://examp= le.com:8080/host
abstract://example.com:8080:http/origin

Any comments, feedback, or concerns would be greatly appreciated.

"abstract" schema name is not a good idea, because le= vel of such abstraction is unclear. "abstract" is too abstract wo= rd
Better use "host" for listed purposed, like in example:

If= wou wont to identify/locate domains use host:example.= com
If wou wont to identify/locate service on port use host:example.com:8080
If wou wont to identify/loc= ate exact http on port 8080 use http= ://example.com:8080
If wou wont to identify/locate host by ip use host:208.77.188.166

note that you can not use "://" if URL is not designed to lo= cate resource associated with path as in http

~Timur



--000e0cd28bfcd742c1046d3250cd-- From connolly@w3.org Thu Jun 25 15:00:44 2009 Return-Path: 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 AE7A73A6A22 for ; Thu, 25 Jun 2009 15:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 bgEo7OuAyJ7J for ; Thu, 25 Jun 2009 15:00:34 -0700 (PDT) Received: from homer.w3.org (ssh.w3.org [128.30.52.60]) by core3.amsl.com (Postfix) with ESMTP id C1C1D3A689D for ; Thu, 25 Jun 2009 15:00:34 -0700 (PDT) Received: from 31-34-212.wireless.csail.mit.edu (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id C49144EF35; Thu, 25 Jun 2009 18:00:32 -0400 (EDT) Message-ID: <4A43F382.5020600@w3.org> Date: Thu, 25 Jun 2009 18:00:34 -0400 From: Dan Connolly User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Eran Hammer-Lahav Subject: Re: URI for abstract concepts (domain, host, origin, site, etc.) References: <90C41DD21FB7C64BB94121FBBC2E7234378339816C@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234378339816C@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: URI , "www-tag@w3.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: , X-List-Received-Date: Thu, 25 Jun 2009 22:00:44 -0000 Eran Hammer-Lahav wrote: [...] > 1. Make a special case exception that when the subject is http://______/.well-known/host-meta, it is treated differently than any other URI in that it means the XRD is not about that URI (the host-meta document itself), but about the abstract host resource located at ______. > > 2. Define a new kind of URI that can be used for abstract entities such as "host" or "domain", but which is not an http URI because that will bring us right back to #1. > > I would like to ask for feedback on the idea of proposing a new URI scheme or a new URN namespace for this purpose, something like 'abstract'. > It will look something like this (please focus on the idea, not the syntax of the examples): > > urn:abstract:domain:example.com > urn:abstract:host:example.com:8080 > urn:abstract:origin:example.com:8080:http > > or > > abstract://example.com/domain > abstract://example.com:8080/host > abstract://example.com:8080:http/origin > > Any comments, feedback, or concerns would be greatly appreciated. For domains, there's a proposed standard. See: Domain Name System Uniform Resource Identifiers (RFC 4501) Josefsson May 2006. http://www.rfc-editor.org/rfc/rfc4501.txt According to that, the 1st would be: dns:example.com I can't find any RFCs on hosts, origins, etc. For abstract things in general, I like just using dynamic lookup via http: http://anysite.you.can.publish.on/mydescription#host-site-whatever -- Dan Connolly, W3C http://www.w3.org/People/Connolly/ From eran@hueniverse.com Thu Jun 25 16:23:32 2009 Return-Path: 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 E968A3A68F8 for ; Thu, 25 Jun 2009 16:23:32 -0700 (PDT) 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 RY9FvG99CekJ for ; Thu, 25 Jun 2009 16:23:32 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id E79E73A67A3 for ; Thu, 25 Jun 2009 16:23:31 -0700 (PDT) Received: (qmail 28466 invoked from network); 25 Jun 2009 22:56:29 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 25 Jun 2009 22:56:25 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 25 Jun 2009 15:55:59 -0700 From: Eran Hammer-Lahav To: Dan Connolly Date: Thu, 25 Jun 2009 15:56:02 -0700 Subject: RE: URI for abstract concepts (domain, host, origin, site, etc.) Thread-Topic: URI for abstract concepts (domain, host, origin, site, etc.) Thread-Index: Acn14E2dhPRvKOLrS3ysGfbXETpzswABwfOA Message-ID: <90C41DD21FB7C64BB94121FBBC2E723437833981C0@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234378339816C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4A43F382.5020600@w3.org> In-Reply-To: <4A43F382.5020600@w3.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: URI , "www-tag@w3.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: , X-List-Received-Date: Thu, 25 Jun 2009 23:23:33 -0000 > From: Dan Connolly [mailto:connolly@w3.org] > Sent: Thursday, June 25, 2009 3:01 PM > For domains, there's a proposed standard. > See: >=20 > Domain Name System Uniform Resource Identifiers (RFC 4501) Josefsson > May > 2006. > http://www.rfc-editor.org/rfc/rfc4501.txt >=20 > According to that, the 1st would be: >=20 > dns:example.com I am not sure this is useful because it has clear semantic meaning represen= ting a DNS record, not some abstract concept. I can't figure out what a des= criptor about dns:example.com actually mean because I don't know what a des= cription of a DNS record means (other than comments). > I can't find any RFCs on hosts, origins, etc. >=20 > For abstract things in general, I like just > using dynamic lookup via http: > http://anysite.you.can.publish.on/mydescription#host-site-whatever How would a client know that this URI isn't for an actual HTTP resource wit= hout creating "well-known-location" URIs (option #1 in my original email)? EHL=20 From eran@hueniverse.com Thu Jun 25 16:24:49 2009 Return-Path: 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 DC9C63A6807 for ; Thu, 25 Jun 2009 16:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.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 5widlwvuM60u for ; Thu, 25 Jun 2009 16:24:49 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 754473A68F8 for ; Thu, 25 Jun 2009 16:24:19 -0700 (PDT) Received: (qmail 32123 invoked from network); 25 Jun 2009 23:24:13 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 25 Jun 2009 23:24:13 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 25 Jun 2009 16:24:12 -0700 From: Eran Hammer-Lahav To: Xiaoshu Wang Date: Thu, 25 Jun 2009 16:24:05 -0700 Subject: RE: LRDD Update (Resource Descriptor Discovery) and Proposed Changes Thread-Topic: LRDD Update (Resource Descriptor Discovery) and Proposed Changes Thread-Index: Acn16vcmnUGjW3TTS6GJqaSlKZH2aQAADgmQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E723437833981CA@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234378339815C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4A440563.90101@musc.edu> In-Reply-To: <4A440563.90101@musc.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "www-tag@w3.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: , X-List-Received-Date: Thu, 25 Jun 2009 23:24:49 -0000 > -----Original Message----- > From: Xiaoshu Wang [mailto:wangxiao@musc.edu] > Sent: Thursday, June 25, 2009 4:17 PM > Now, given one information, you are proposing three mechanisms to > specify it. Isn't it obvious that something is *fundamentally* wrong > about the proposal? No. That's like saying an HTML document should never repeat any of the link= s provided in the HTTP header, etc. The reality is that there isn't any sin= gle solution that satisfies all the use cases we have. After over a year of= debating it, this combination of three methods is the best we have come up= with, and it works fine. Is it a beautiful solution with clean architectur= e? No. But it is the only solution we can deploy today and expect people to= use. If you read the proposal, it clearly goes through the list of available met= hods and states why this approach was chosen. EHL From eran@hueniverse.com Thu Jun 25 16:38:07 2009 Return-Path: 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 D16973A6840 for ; Thu, 25 Jun 2009 16:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 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 U+3VOowjkeGz for ; Thu, 25 Jun 2009 16:38:07 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 16EB03A67E6 for ; Thu, 25 Jun 2009 16:38:07 -0700 (PDT) Received: (qmail 2189 invoked from network); 25 Jun 2009 23:36:40 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 25 Jun 2009 23:36:40 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 25 Jun 2009 16:36:13 -0700 From: Eran Hammer-Lahav To: Xiaoshu Wang Date: Thu, 25 Jun 2009 16:36:31 -0700 Subject: RE: URI for abstract concepts (domain, host, origin, site, etc.) Thread-Topic: URI for abstract concepts (domain, host, origin, site, etc.) Thread-Index: Acn17AKrELmYTDV9Qteo++3TyzuchwAAKhWQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E723437833981CE@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234378339816C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4A440724.4040002@musc.edu> In-Reply-To: <4A440724.4040002@musc.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: URI , "www-tag@w3.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: , X-List-Received-Date: Thu, 25 Jun 2009 23:38:07 -0000 > -----Original Message----- > From: Xiaoshu Wang [mailto:wangxiao@musc.edu] > Sent: Thursday, June 25, 2009 4:24 PM > What we need is a special syntax to mean that a URI denotes for itself. > Just like in natural language, that we use quotation mark to > distinguish > between the word "New York City" and New York City. Once we have that, > then we are free to define any ontology to describe the composition of > a URI, just like anything else. Without passing judgment on your proposal, it is clearly not something that= can be accomplished within a short time frame. I have a very specific need= to indicate a document describes "a host" which is a combination of domain= , port, and potentially protocol. I just need to say it formatted as a URI.= =20 > Proposing anything else is simply an over-kill, let alone another URN. If anything, it is your proposal that is an over-kill. EHL From eran@hueniverse.com Thu Jun 25 19:14:33 2009 Return-Path: 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 D1F5A3A69EC for ; Thu, 25 Jun 2009 19:14:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 FzsbLYbk5Coz for ; Thu, 25 Jun 2009 19:14:32 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id D97033A69DE for ; Thu, 25 Jun 2009 19:14:32 -0700 (PDT) Received: (qmail 30558 invoked from network); 26 Jun 2009 02:14:15 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 26 Jun 2009 02:14:14 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Thu, 25 Jun 2009 19:14:14 -0700 From: Eran Hammer-Lahav To: John Cowan Date: Thu, 25 Jun 2009 19:14:07 -0700 Subject: RE: URI for abstract concepts (domain, host, origin, site, etc.) Thread-Topic: URI for abstract concepts (domain, host, origin, site, etc.) Thread-Index: Acn1+dy/849pqoCDTh+ZaYej2Ok3LwACdJmg Message-ID: <90C41DD21FB7C64BB94121FBBC2E723437833981DA@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234378339816C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4A440724.4040002@musc.edu> <90C41DD21FB7C64BB94121FBBC2E723437833981CE@P3PW5EX1MB01.EX1.SECURESERVER.NET> <20090626010326.GD30117@mercury.ccil.org> In-Reply-To: <20090626010326.GD30117@mercury.ccil.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: URI , "www-tag@w3.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: , X-List-Received-Date: Fri, 26 Jun 2009 02:14:33 -0000 Not sure how this is going to help. You still end up with an HTTP URI with = no clear semantic meaning other than an HTTP resource. EHL > -----Original Message----- > From: John Cowan [mailto:cowan@ccil.org] > Sent: Thursday, June 25, 2009 6:03 PM > To: Eran Hammer-Lahav > Cc: Xiaoshu Wang; apps-discuss@ietf.org; www-tag@w3.org; URI > Subject: Re: URI for abstract concepts (domain, host, origin, site, > etc.) >=20 > Eran Hammer-Lahav scripsit: >=20 > > Without passing judgment on your proposal, it is clearly not > something > > that can be accomplished within a short time frame. I have a very > > specific need to indicate a document describes "a host" which is a > > combination of domain, port, and potentially protocol. I just need to > > say it formatted as a URI. >=20 > A simple approach would be to use a data: URI (see RFC 2397) of the > form > "data:application/uri,http://www.ccil.org". I proposed this for a > related > purpose during the Great XML Namespace Debate, but it didn't get > traction. >=20 > -- > Your worships will perhaps be thinking John Cowan > that it is an easy thing to blow up a dog? > http://www.ccil.org/~cowan > [Or] to write a book? > --Don Quixote, Introduction cowan@ccil.org From connolly@w3.org Thu Jun 25 19:51:54 2009 Return-Path: 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 35BAB3A68FB for ; Thu, 25 Jun 2009 19:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 b5GUp5ssHgBh for ; Thu, 25 Jun 2009 19:51:53 -0700 (PDT) Received: from homer.w3.org (ssh.w3.org [128.30.52.60]) by core3.amsl.com (Postfix) with ESMTP id 29AC33A6849 for ; Thu, 25 Jun 2009 19:51:53 -0700 (PDT) Received: from pbjam.home (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 9DDCA4EEC6; Thu, 25 Jun 2009 22:52:10 -0400 (EDT) Message-ID: <4A4437DC.3090201@w3.org> Date: Thu, 25 Jun 2009 22:52:12 -0400 From: Dan Connolly User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Eran Hammer-Lahav Subject: Re: URI for abstract concepts (domain, host, origin, site, etc.) References: <90C41DD21FB7C64BB94121FBBC2E7234378339816C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4A43F382.5020600@w3.org> <90C41DD21FB7C64BB94121FBBC2E723437833981C0@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723437833981C0@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: URI , "www-tag@w3.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: , X-List-Received-Date: Fri, 26 Jun 2009 02:51:54 -0000 Eran Hammer-Lahav wrote: >> From: Dan Connolly [mailto:connolly@w3.org] >> Sent: Thursday, June 25, 2009 3:01 PM > >> For domains, there's a proposed standard. >> See: >> >> Domain Name System Uniform Resource Identifiers (RFC 4501) Josefsson >> May >> 2006. >> http://www.rfc-editor.org/rfc/rfc4501.txt >> >> According to that, the 1st would be: >> >> dns:example.com > > I am not sure this is useful because it has clear semantic meaning representing a DNS record, not some abstract concept. Oops; OK. I didn't notice the subtlety. > I can't figure out what a descriptor about dns:example.com actually mean because I don't know what a description of a DNS record means (other than comments). > >> I can't find any RFCs on hosts, origins, etc. >> >> For abstract things in general, I like just >> using dynamic lookup via http: >> http://anysite.you.can.publish.on/mydescription#host-site-whatever > > How would a client know that this URI isn't for an actual HTTP resource without creating "well-known-location" URIs (option #1 in my original email)? It _is_ for an actual HTTP resource; i.e. something described/discussed in a document you can get by HTTP. Since documents can describe/discuss anything, they can describe/discuss things like origins and such. RDF is particularly suited for this purpose, but I can imagine other media types might work too... text/html with RDFa is pretty hip these days. -- Dan Connolly, W3C http://www.w3.org/People/Connolly/ From eran@hueniverse.com Thu Jun 25 20:18:24 2009 Return-Path: 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 9118B3A6945 for ; Thu, 25 Jun 2009 20:18:24 -0700 (PDT) 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 MwKWboa1H5sf for ; Thu, 25 Jun 2009 20:18:23 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id BBC033A6A43 for ; Thu, 25 Jun 2009 20:18:23 -0700 (PDT) Received: (qmail 2540 invoked from network); 26 Jun 2009 03:18:20 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 26 Jun 2009 03:18:19 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 25 Jun 2009 20:17:52 -0700 From: Eran Hammer-Lahav To: Dan Connolly Date: Thu, 25 Jun 2009 20:18:12 -0700 Subject: RE: URI for abstract concepts (domain, host, origin, site, etc.) Thread-Topic: URI for abstract concepts (domain, host, origin, site, etc.) Thread-Index: Acn2CQrSp2IuF4XpQMSo8KKuZnDm0QAAoEYA Message-ID: <90C41DD21FB7C64BB94121FBBC2E723437833981DC@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234378339816C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4A43F382.5020600@w3.org> <90C41DD21FB7C64BB94121FBBC2E723437833981C0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4A4437DC.3090201@w3.org> In-Reply-To: <4A4437DC.3090201@w3.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: URI , "www-tag@w3.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: , X-List-Received-Date: Fri, 26 Jun 2009 03:18:24 -0000 > From: Dan Connolly [mailto:connolly@w3.org] > Sent: Thursday, June 25, 2009 7:52 PM > > How would a client know that this URI isn't for an actual HTTP > resource without creating "well-known-location" URIs (option #1 in my > original email)? >=20 > It _is_ for an actual HTTP resource; i.e. something > described/discussed in a document you can get by HTTP. Since > documents can describe/discuss anything, they can describe/discuss > things like origins and such. RDF is particularly suited > for this purpose, but I can imagine other media types > might work too... text/html with RDFa is pretty hip > these days. In my case, the "resource" is the concept of a host, which is the combinati= on of a domain name, port number, and protocol used on that port. I want to= be able to describe this host by saying, "this is how you transform any HT= TP URI that belongs to this host to the URI of its metadata". There are ple= nty of ways to express this statement but so far I don't have a good way to= express the subject of this statement - the host. Of course, I can come up with something like this: http://abstract.example.net/host/example.com:80:http And simply include in the protocol that the http://abstract.example.net/hos= t/ prefix is a special case exception. But while such solutions (a URI vers= ion of a well-known location) might be acceptable for HTTP servers due to t= he complexity and cost of deploying changes to the infrastructure (such as = a new HTTP method), they are less acceptable for URIs which can be easily e= xtended with nothing more than a couple pages of spec... It is almost as easy to register a new URI scheme or URN namespace as it is= for me to buy and maintain a new domain name. But I think in this case, th= e reserved domain name is a lot more offensive to web architecture than a n= ew URI scheme or some other URI-based solution. I am also happy to make this as specific as needed for my super special use= case and mint a new host: URI scheme. EHL From eran@hueniverse.com Thu Jun 25 20:19:57 2009 Return-Path: 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 DAACA3A6A43 for ; Thu, 25 Jun 2009 20:19:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 V0PYcgmLFmsA for ; Thu, 25 Jun 2009 20:19:56 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id E0E8B3A6A99 for ; Thu, 25 Jun 2009 20:19:56 -0700 (PDT) Received: (qmail 6832 invoked from network); 26 Jun 2009 03:20:02 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 26 Jun 2009 03:20:02 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 25 Jun 2009 20:20:02 -0700 From: Eran Hammer-Lahav To: John Cowan Date: Thu, 25 Jun 2009 20:19:55 -0700 Subject: RE: URI for abstract concepts (domain, host, origin, site, etc.) Thread-Topic: URI for abstract concepts (domain, host, origin, site, etc.) Thread-Index: Acn2CqYrU/YGTvsnTiuGlp2OL8TbzAAAh/LA Message-ID: <90C41DD21FB7C64BB94121FBBC2E723437833981DD@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234378339816C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4A440724.4040002@musc.edu> <90C41DD21FB7C64BB94121FBBC2E723437833981CE@P3PW5EX1MB01.EX1.SECURESERVER.NET> <20090626010326.GD30117@mercury.ccil.org> <90C41DD21FB7C64BB94121FBBC2E723437833981DA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <20090626030337.GE30117@mercury.ccil.org> In-Reply-To: <20090626030337.GE30117@mercury.ccil.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: URI , "www-tag@w3.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: , X-List-Received-Date: Fri, 26 Jun 2009 03:19:58 -0000 You are right. But this only means that a document about is simply a description of the URI itself. This st= ill does not help me relay the concept of a host. I still don't know what t= o put inside this data URI to convey this. EHL > -----Original Message----- > From: John Cowan [mailto:cowan@ccil.org] > Sent: Thursday, June 25, 2009 8:04 PM > To: Eran Hammer-Lahav > Cc: John Cowan; apps-discuss@ietf.org; www-tag@w3.org; URI > Subject: Re: URI for abstract concepts (domain, host, origin, site, > etc.) >=20 > Eran Hammer-Lahav scripsit: >=20 > > Not sure how this is going to help. You still end up with an HTTP URI > > with no clear semantic meaning other than an HTTP resource. >=20 > What do you mean by "end up with"? A data URI is not an HTTP URI. > refefers to the home page of ccil.org; > refers to the URI > . They are two different URIs with two different > referents. >=20 > -- > John Cowan http://www.ccil.org/~cowan cowan@ccil.org > "After all, would you consider a man without honor wealthy, even if his > Dinar laid end to end would reach from here to the Temple of Toplat?" > "No, I wouldn't", the beggar replied. "Why is that?" the Master asked. > "A Dinar doesn't go very far these days, Master. --Kehlog Albran > Besides, the Temple of Toplat is across the street." The Profit From duerst@it.aoyama.ac.jp Thu Jun 25 23:47:57 2009 Return-Path: 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 ADCB73A6A67 for ; Thu, 25 Jun 2009 23:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.049 X-Spam-Level: X-Spam-Status: No, score=0.049 tagged_above=-999 required=5 tests=[AWL=-0.161, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3] 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 vWqFaNStWWpZ for ; Thu, 25 Jun 2009 23:47:56 -0700 (PDT) Received: from scmailgw02.scop.aoyama.ac.jp (scmailgw02.scop.aoyama.ac.jp [133.2.251.42]) by core3.amsl.com (Postfix) with ESMTP id 906C43A690B for ; Thu, 25 Jun 2009 23:47:55 -0700 (PDT) Received: from scmse01.scbb.aoyama.ac.jp (scmse01.scbb.aoyama.ac.jp [133.2.253.158]) by scmailgw02.scop.aoyama.ac.jp (secret/secret) with SMTP id n5Q6kIGb020360 for ; Fri, 26 Jun 2009 15:46:18 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 3515_0d5ef3fa_621d_11de_a32d_001d096c566a; Fri, 26 Jun 2009 15:46:18 +0900 Received: from [IPv6:::1] ([133.2.210.1]:40157) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Fri, 26 Jun 2009 15:44:17 +0900 Message-ID: <4A446EAA.5030906@it.aoyama.ac.jp> Date: Fri, 26 Jun 2009 15:46:02 +0900 From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090108 Eudora/3.0b1pre MIME-Version: 1.0 To: Eran Hammer-Lahav Subject: Re: URI for abstract concepts (domain, host, origin, site, etc.) References: <90C41DD21FB7C64BB94121FBBC2E7234378339816C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4A43F382.5020600@w3.org> <90C41DD21FB7C64BB94121FBBC2E723437833981C0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4A4437DC.3090201@w3.org> <90C41DD21FB7C64BB94121FBBC2E723437833981DC@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723437833981DC@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: URI , Dan Connolly , "www-tag@w3.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: , X-List-Received-Date: Fri, 26 Jun 2009 06:47:57 -0000 On 2009/06/26 12:18, Eran Hammer-Lahav wrote: > In my case, the "resource" is the concept of a host, which is the combination of a domain name, port number, and protocol used on that port. I want to be able to describe this host by saying, "this is how you transform any HTTP URI that belongs to this host to the URI of its metadata". There are plenty of ways to express this statement but so far I don't have a good way to express the subject of this statement - the host. > > Of course, I can come up with something like this: > > http://abstract.example.net/host/example.com:80:http > > And simply include in the protocol that the http://abstract.example.net/host/ prefix is a special case exception. But while such solutions (a URI version of a well-known location) might be acceptable for HTTP servers due to the complexity and cost of deploying changes to the infrastructure (such as a new HTTP method), they are less acceptable for URIs which can be easily extended with nothing more than a couple pages of spec... > > It is almost as easy to register a new URI scheme or URN namespace as it is for me to buy and maintain a new domain name. But I think in this case, the reserved domain name is a lot more offensive to web architecture than a new URI scheme or some other URI-based solution. > > I am also happy to make this as specific as needed for my super special use case and mint a new host: URI scheme. This seems to indicate that 'host' is just one kind or type of thing. There are tons and tons of other such things. Apples, oranges, blueberries, just to start with. The idea that we need a new URI scheme for every kind of data or thing that we want to talk about seems highly unscalable. Also, your concept of 'host' may be slightly different from what somebody else would think a 'host' is or has to be. Again, defining a 'host:' URI scheme very much looks like a non-starter. I don't exactly understand what you think your problem is, but I think it's a mistake to assume that because you have something that you can denote with almost the same information as available in an HTTP URI (that wouldn't be true for apples and oranges), it should have a scheme. Regards, Martin. -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From ajs@shinkuro.com Fri Jun 26 07:00:36 2009 Return-Path: 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 63ED93A6B11 for ; Fri, 26 Jun 2009 07:00:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.937 X-Spam-Level: X-Spam-Status: No, score=-1.937 tagged_above=-999 required=5 tests=[AWL=0.662, 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 fpj5mYPONdRB for ; Fri, 26 Jun 2009 07:00:35 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 92B733A6956 for ; Fri, 26 Jun 2009 07:00:35 -0700 (PDT) Received: from crankycanuck.ca (76-10-166-247.dsl.teksavvy.com [76.10.166.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 458312FE9664 for ; Fri, 26 Jun 2009 14:00:53 +0000 (UTC) Date: Fri, 26 Jun 2009 10:00:51 -0400 From: Andrew Sullivan To: apps-discuss@ietf.org Subject: Re: URI for abstract concepts (domain, host, origin, site, etc.) Message-ID: <20090626140051.GD481@shinkuro.com> References: <90C41DD21FB7C64BB94121FBBC2E7234378339816C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4A43F382.5020600@w3.org> <90C41DD21FB7C64BB94121FBBC2E723437833981C0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4A4437DC.3090201@w3.org> <90C41DD21FB7C64BB94121FBBC2E723437833981DC@P3PW5EX1MB01.EX1.SECURESERVER.NET> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723437833981DC@P3PW5EX1MB01.EX1.SECURESERVER.NET> User-Agent: Mutt/1.5.18 (2008-05-17) 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: , X-List-Received-Date: Fri, 26 Jun 2009 14:00:36 -0000 On Thu, Jun 25, 2009 at 08:18:12PM -0700, Eran Hammer-Lahav wrote: > > In my case, the "resource" is the concept of a host, which is the > combination of a domain name, port number, and protocol used on that > port. Whatever that concept is, it is not what "host" means in the networks we actually have today. There is a long history to the notion of a host and its name, and it is nowise limited to whatever happens to be listening at a particular DNS name on a port. I don't really understand what the problem is you're trying to solve is. It sounds to me like you want a description of an SRV or NAPTR record, in which case you ought trivially to be able to use the approach mentioned up-thread with an SRV or NAPTR DNS record, no? A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From eran@hueniverse.com Fri Jun 26 08:32:31 2009 Return-Path: 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 9DFA63A6A02 for ; Fri, 26 Jun 2009 08:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 6RAgTZhtdNfK for ; Fri, 26 Jun 2009 08:32:30 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 2F9CB3A6922 for ; Fri, 26 Jun 2009 08:32:30 -0700 (PDT) Received: (qmail 2997 invoked from network); 26 Jun 2009 15:32:20 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 26 Jun 2009 15:32:14 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Fri, 26 Jun 2009 08:31:46 -0700 From: Eran Hammer-Lahav To: =?iso-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= Date: Fri, 26 Jun 2009 08:32:08 -0700 Subject: RE: URI for abstract concepts (domain, host, origin, site, etc.) Thread-Topic: URI for abstract concepts (domain, host, origin, site, etc.) Thread-Index: Acn2KcbMUapu3wd3REyBu8NdJ2HtzQASN/Xg Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343783398202@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234378339816C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4A43F382.5020600@w3.org> <90C41DD21FB7C64BB94121FBBC2E723437833981C0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4A4437DC.3090201@w3.org> <90C41DD21FB7C64BB94121FBBC2E723437833981DC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4A446EAA.5030906@it.aoyama.ac.jp> In-Reply-To: <4A446EAA.5030906@it.aoyama.ac.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: URI , "www-tag@w3.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: , X-List-Received-Date: Fri, 26 Jun 2009 15:32:31 -0000 My definition of host comes from RFC 2616. What I am looking for is a way to express a web concept for the purpose of = describing its attributes as a URI. It needs to be a URI because the framew= orks we use to describe things on the web are all limited to describing res= ources identified with URI. The only option I would like to rule out is to use a reserved HTTP URI for = this purpose. I am open to pretty much all other options, if they correctly= convey the idea of "host", "domain", etc. EHL > -----Original Message----- > From: "Martin J. D=FCrst" [mailto:duerst@it.aoyama.ac.jp] > Sent: Thursday, June 25, 2009 11:46 PM > To: Eran Hammer-Lahav > Cc: Dan Connolly; apps-discuss@ietf.org; www-tag@w3.org; URI > Subject: Re: URI for abstract concepts (domain, host, origin, site, > etc.) >=20 > On 2009/06/26 12:18, Eran Hammer-Lahav wrote: >=20 > > In my case, the "resource" is the concept of a host, which is the > combination of a domain name, port number, and protocol used on that > port. I want to be able to describe this host by saying, "this is how > you transform any HTTP URI that belongs to this host to the URI of its > metadata". There are plenty of ways to express this statement but so > far I don't have a good way to express the subject of this statement - > the host. > > > > Of course, I can come up with something like this: > > > > http://abstract.example.net/host/example.com:80:http > > > > And simply include in the protocol that the > http://abstract.example.net/host/ prefix is a special case exception. > But while such solutions (a URI version of a well-known location) might > be acceptable for HTTP servers due to the complexity and cost of > deploying changes to the infrastructure (such as a new HTTP method), > they are less acceptable for URIs which can be easily extended with > nothing more than a couple pages of spec... > > > > It is almost as easy to register a new URI scheme or URN namespace as > it is for me to buy and maintain a new domain name. But I think in this > case, the reserved domain name is a lot more offensive to web > architecture than a new URI scheme or some other URI-based solution. > > > > I am also happy to make this as specific as needed for my super > special use case and mint a new host: URI scheme. >=20 > This seems to indicate that 'host' is just one kind or type of thing. > There are tons and tons of other such things. Apples, oranges, > blueberries, just to start with. The idea that we need a new URI scheme > for every kind of data or thing that we want to talk about seems highly > unscalable. Also, your concept of 'host' may be slightly different from > what somebody else would think a 'host' is or has to be. Again, > defining > a 'host:' URI scheme very much looks like a non-starter. I don't > exactly > understand what you think your problem is, but I think it's a mistake > to > assume that because you have something that you can denote with almost > the same information as available in an HTTP URI (that wouldn't be true > for apples and oranges), it should have a scheme. >=20 > Regards, Martin. >=20 > -- > #-# Martin J. D=FCrst, Professor, Aoyama Gakuin University > #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From eran@hueniverse.com Fri Jun 26 09:00:25 2009 Return-Path: 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 D7F983A6A6D for ; Fri, 26 Jun 2009 09:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 okFZWiyMqfI0 for ; Fri, 26 Jun 2009 09:00:24 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id EB58B3A6922 for ; Fri, 26 Jun 2009 09:00:23 -0700 (PDT) Received: (qmail 5462 invoked from network); 26 Jun 2009 16:00:23 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 26 Jun 2009 16:00:23 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Fri, 26 Jun 2009 08:59:38 -0700 From: Eran Hammer-Lahav To: Andrew Sullivan , "apps-discuss@ietf.org" Date: Fri, 26 Jun 2009 09:00:00 -0700 Subject: RE: URI for abstract concepts (domain, host, origin, site, etc.) Thread-Topic: URI for abstract concepts (domain, host, origin, site, etc.) Thread-Index: Acn2ZniPYbO+R10WSE29bYg3tei00gAD6WMg Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343783398210@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234378339816C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4A43F382.5020600@w3.org> <90C41DD21FB7C64BB94121FBBC2E723437833981C0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4A4437DC.3090201@w3.org> <90C41DD21FB7C64BB94121FBBC2E723437833981DC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <20090626140051.GD481@shinkuro.com> In-Reply-To: <20090626140051.GD481@shinkuro.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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: , X-List-Received-Date: Fri, 26 Jun 2009 16:00:25 -0000 I define host the same way 2616 does, which is a combination of a domain an= d port. Since it is defined in the context of the HTTP protocol, it include= s an implied protocol as well. The problem I am trying to solve is very simple. I have a mechanism to desc= ribe resources using their URI as identifier. I use this mechanism to descr= ibe web pages, services, and other resources. I also want to use it to desc= ribe an entire host - I need to describe rules that apply to the entire set= of resources which are part of a given host, as defined by RFC 2616. But without having a URI (*any* URI) that means 'the host at example.com po= rt 80 using HTTP', I can't use this mechanism because it only knows how to = operate on URIs. I can pick anything I want to stick in there as long as it is a valid URI. So the question is, how to express 'the host at example.com port 80 using H= TTP' in a URI? It looks like we need to create something new (from a new UR= I scheme to a new namespace in an existing URI scheme). I'm asking for idea= s. EHL > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > bounces@ietf.org] On Behalf Of Andrew Sullivan > Sent: Friday, June 26, 2009 7:01 AM > To: apps-discuss@ietf.org > Subject: Re: URI for abstract concepts (domain, host, origin, site, > etc.) >=20 > On Thu, Jun 25, 2009 at 08:18:12PM -0700, Eran Hammer-Lahav wrote: > > > > In my case, the "resource" is the concept of a host, which is the > > combination of a domain name, port number, and protocol used on that > > port. >=20 > Whatever that concept is, it is not what "host" means in the networks > we actually have today. There is a long history to the notion of a > host and its name, and it is nowise limited to whatever happens to be > listening at a particular DNS name on a port. >=20 > I don't really understand what the problem is you're trying to solve > is. It sounds to me like you want a description of an SRV or NAPTR > record, in which case you ought trivially to be able to use the > approach mentioned up-thread with an SRV or NAPTR DNS record, no? >=20 > A > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From eran@hueniverse.com Fri Jun 26 09:03:05 2009 Return-Path: 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 DCA6F3A6BE5 for ; Fri, 26 Jun 2009 09:03:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[AWL=-0.268, BAYES_00=-2.599, J_CHICKENPOX_34=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 bIAKeFCl6oYz for ; Fri, 26 Jun 2009 09:03:04 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id C12943A6BC3 for ; Fri, 26 Jun 2009 09:03:04 -0700 (PDT) Received: (qmail 12058 invoked from network); 26 Jun 2009 16:03:15 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 26 Jun 2009 16:03:15 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Fri, 26 Jun 2009 09:02:48 -0700 From: Eran Hammer-Lahav To: Pat Hayes Date: Fri, 26 Jun 2009 09:03:11 -0700 Subject: RE: URI for abstract concepts (domain, host, origin, site, etc.) Thread-Topic: URI for abstract concepts (domain, host, origin, site, etc.) Thread-Index: Acn2dWEzar1ELfBARG+eAVHCDKW2YAAAfZtQ Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343783398212@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234378339816C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4A43F382.5020600@w3.org> <90C41DD21FB7C64BB94121FBBC2E723437833981C0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4A4437DC.3090201@w3.org> <90C41DD21FB7C64BB94121FBBC2E723437833981DC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <66FB7DD9-7D0B-4877-ACBE-1618507CBFDA@ihmc.us> In-Reply-To: <66FB7DD9-7D0B-4877-ACBE-1618507CBFDA@ihmc.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: URI , Dan Connolly , "www-tag@w3.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: , X-List-Received-Date: Fri, 26 Jun 2009 16:03:05 -0000 It still needs to fit into an element that can only accept a URI. If I end = up using a URI I own and put the actual host information in the fragment as= suggested, I end up with exactly the kind of solution I am trying to avoid= which is making exceptions and defining well-known HTTP URIs that are trea= ted differently. EHL > -----Original Message----- > From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] On Behalf > Of Pat Hayes > Sent: Friday, June 26, 2009 8:47 AM > To: Eran Hammer-Lahav > Cc: Dan Connolly; apps-discuss@ietf.org; www-tag@w3.org; URI > Subject: Re: URI for abstract concepts (domain, host, origin, site, > etc.) >=20 >=20 > On Jun 25, 2009, at 10:18 PM, Eran Hammer-Lahav wrote: >=20 > >> From: Dan Connolly [mailto:connolly@w3.org] > >> Sent: Thursday, June 25, 2009 7:52 PM > > > >>> How would a client know that this URI isn't for an actual HTTP > >> resource without creating "well-known-location" URIs (option #1 in > my > >> original email)? > >> > >> It _is_ for an actual HTTP resource; i.e. something > >> described/discussed in a document you can get by HTTP. Since > >> documents can describe/discuss anything, they can describe/discuss > >> things like origins and such. RDF is particularly suited > >> for this purpose, but I can imagine other media types > >> might work too... text/html with RDFa is pretty hip > >> these days. > > > > In my case, the "resource" is the concept of a host, which is the > > combination of a domain name, port number, and protocol used on that > > port. I want to be able to describe this host by saying, "this is > > how you transform any HTTP URI that belongs to this host to the URI > > of its metadata". There are plenty of ways to express this statement > > but so far I don't have a good way to express the subject of this > > statement - the host. >=20 > To me this sounds like a clear use case for an RDF blank node. You > want to refer to some (category of) thing that has no current naming > convention, but which you can describe in terms of its properties. > That is exactly what RDF bnodes were invented for. The relevant RDF > graph fragment would look something like this, using triples notation > for clarity: >=20 > _:x rdf:type :HostClassName . > _"x :hasDomainName ^^xsd:string . > _:x :hasPortNumber ^^xsd:number . (Or maybe you want to > keep it as a string) > _:x :usesProtocol .... (Not sure how to express this, you might have > to use a literal to encode the protocol name or some such, unless > there is an ontology of protocols out there somewhere.) >=20 > to which you then add whatever you want to say about it, with that > same _:x as subject. >=20 > If you (as many people do) dislike bnodes, than just invent a naming > convention with URI references #ed onto a suitable URI you own: the > use of # gives you freedom to use your own naming style, and bypasses > the http-range-14 referential problems arising from the use of a bare > URI. >=20 > Pat Hayes >=20 > > > > Of course, I can come up with something like this: > > > > http://abstract.example.net/host/example.com:80:http > > > > And simply include in the protocol that the > http://abstract.example.net/host/ > > prefix is a special case exception. But while such solutions (a URI > > version of a well-known location) might be acceptable for HTTP > > servers due to the complexity and cost of deploying changes to the > > infrastructure (such as a new HTTP method), they are less acceptable > > for URIs which can be easily extended with nothing more than a > > couple pages of spec... > > > > It is almost as easy to register a new URI scheme or URN namespace > > as it is for me to buy and maintain a new domain name. But I think > > in this case, the reserved domain name is a lot more offensive to > > web architecture than a new URI scheme or some other URI-based > > solution. > > > > I am also happy to make this as specific as needed for my super > > special use case and mint a new host: URI scheme. > > > > EHL > > > > > > >=20 > ------------------------------------------------------------ > IHMC (850)434 8903 or (650)494 3973 > 40 South Alcaniz St. (850)202 4416 office > Pensacola (850)202 4440 fax > FL 32502 (850)291 0667 mobile > phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes >=20 >=20 >=20 >=20 >=20 From ajs@shinkuro.com Fri Jun 26 09:05:29 2009 Return-Path: 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 AA8B93A6B38 for ; Fri, 26 Jun 2009 09:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.955 X-Spam-Level: X-Spam-Status: No, score=-1.955 tagged_above=-999 required=5 tests=[AWL=0.644, 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 fNgpnwISdqIS for ; Fri, 26 Jun 2009 09:05:29 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id E6BCD3A6B8A for ; Fri, 26 Jun 2009 09:05:28 -0700 (PDT) Received: from crankycanuck.ca (76-10-166-247.dsl.teksavvy.com [76.10.166.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 954A72FE9664 for ; Fri, 26 Jun 2009 16:05:46 +0000 (UTC) Date: Fri, 26 Jun 2009 12:05:44 -0400 From: Andrew Sullivan To: apps-discuss@ietf.org Subject: Re: URI for abstract concepts (domain, host, origin, site, etc.) Message-ID: <20090626160544.GF481@shinkuro.com> References: <90C41DD21FB7C64BB94121FBBC2E7234378339816C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4A43F382.5020600@w3.org> <90C41DD21FB7C64BB94121FBBC2E723437833981C0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4A4437DC.3090201@w3.org> <90C41DD21FB7C64BB94121FBBC2E723437833981DC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4A446EAA.5030906@it.aoyama.ac.jp> <90C41DD21FB7C64BB94121FBBC2E72343783398202@P3PW5EX1MB01.EX1.SECURESERVER.NET> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343783398202@P3PW5EX1MB01.EX1.SECURESERVER.NET> User-Agent: Mutt/1.5.18 (2008-05-17) 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: , X-List-Received-Date: Fri, 26 Jun 2009 16:05:29 -0000 On Fri, Jun 26, 2009 at 08:32:08AM -0700, Eran Hammer-Lahav wrote: > My definition of host comes from RFC 2616. RFC 2616 contains a definition of a Host request-header field. It acually includes the words "Internet host" as part of the definition, from my cursory glance just now, so I suspect you don't quite have the right definition of "the concept of a host" here. I urge you to look at RFCs 822, 907, 1122, 1123, 1221, 1349, 2181, to start. 1034 and 1035 wouldn't be a bad idea, either. There's quite enough confusion in the discussion of hosts and domain names around the IETF already without someone hauling in port numbers to the topic. > What I am looking for is a way to express a web concept for the > purpose of describing its attributes as a URI. Again, I have no idea what these "web concepts" of which you speak are. I'm not even sure that concepts have attributes, but let's solve one terminological problem at a time. > The only option I would like to rule out is to use a reserved HTTP > URI for this purpose. I am open to pretty much all other options, if > they correctly convey the idea of "host", "domain", etc. So what do you think the correct ideas of host and domain are, to start with? A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From eran@hueniverse.com Fri Jun 26 09:14:45 2009 Return-Path: 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 025393A6882 for ; Fri, 26 Jun 2009 09:14:45 -0700 (PDT) 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 A4HyRxJxSVJc for ; Fri, 26 Jun 2009 09:14:44 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 1EB303A6B38 for ; Fri, 26 Jun 2009 09:14:44 -0700 (PDT) Received: (qmail 9745 invoked from network); 26 Jun 2009 16:15:00 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 26 Jun 2009 16:15:00 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Fri, 26 Jun 2009 09:15:00 -0700 From: Eran Hammer-Lahav To: "apps-discuss@ietf.org" Date: Fri, 26 Jun 2009 09:14:55 -0700 Subject: RE: URI for abstract concepts (domain, host, origin, site, etc.) Thread-Topic: URI for abstract concepts (domain, host, origin, site, etc.) Thread-Index: Acn2d+kQG1dG5vu7TNS5iflTWqETogAAGY7g Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343783398217@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234378339816C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4A43F382.5020600@w3.org> <90C41DD21FB7C64BB94121FBBC2E723437833981C0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4A4437DC.3090201@w3.org> <90C41DD21FB7C64BB94121FBBC2E723437833981DC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4A446EAA.5030906@it.aoyama.ac.jp> <90C41DD21FB7C64BB94121FBBC2E72343783398202@P3PW5EX1MB01.EX1.SECURESERVER.NET> <20090626160544.GF481@shinkuro.com> In-Reply-To: <20090626160544.GF481@shinkuro.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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: , X-List-Received-Date: Fri, 26 Jun 2009 16:14:45 -0000 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > bounces@ietf.org] On Behalf Of Andrew Sullivan > Sent: Friday, June 26, 2009 9:06 AM > So what do you think the correct ideas of host and domain are, to > start with? Fair enough. I am using only RFC 3986 terminology here from section 3 [1]. I want to express the combination of: host, port, and scheme. I need to express it formatted as a valid URI. I don't want to express it using an http URI because that requires creating= URI exceptions. Thank! EHL [1] http://tools.ietf.org/html/rfc3986#section-3 From ajs@shinkuro.com Fri Jun 26 09:16:52 2009 Return-Path: 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 81D4B3A6AE0 for ; Fri, 26 Jun 2009 09:16:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.671 X-Spam-Level: X-Spam-Status: No, score=-1.671 tagged_above=-999 required=5 tests=[AWL=0.328, 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 P2xOL9s6T05A for ; Fri, 26 Jun 2009 09:16:51 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id C2B423A6938 for ; Fri, 26 Jun 2009 09:16:51 -0700 (PDT) Received: from crankycanuck.ca (76-10-166-247.dsl.teksavvy.com [76.10.166.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id B12D42FE9664; Fri, 26 Jun 2009 16:16:49 +0000 (UTC) Date: Fri, 26 Jun 2009 12:16:47 -0400 From: Andrew Sullivan To: Eran Hammer-Lahav Subject: Re: URI for abstract concepts (domain, host, origin, site, etc.) Message-ID: <20090626161647.GH481@shinkuro.com> References: <90C41DD21FB7C64BB94121FBBC2E7234378339816C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4A43F382.5020600@w3.org> <90C41DD21FB7C64BB94121FBBC2E723437833981C0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4A4437DC.3090201@w3.org> <90C41DD21FB7C64BB94121FBBC2E723437833981DC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <20090626140051.GD481@shinkuro.com> <90C41DD21FB7C64BB94121FBBC2E72343783398210@P3PW5EX1MB01.EX1.SECURESERVER.NET> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343783398210@P3PW5EX1MB01.EX1.SECURESERVER.NET> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: "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: , X-List-Received-Date: Fri, 26 Jun 2009 16:16:52 -0000 On Fri, Jun 26, 2009 at 09:00:00AM -0700, Eran Hammer-Lahav wrote: > I define host the same way 2616 does, which is a combination of a > domain and port. Since it is defined in the context of the HTTP > protocol, it includes an implied protocol as well. > > The problem I am trying to solve is very simple. I have a mechanism > to describe resources using their URI as identifier. I use this > mechanism to describe web pages, services, and other resources. I > also want to use it to describe an entire host - I need to describe > rules that apply to the entire set of resources which are part of a > given host, as defined by RFC 2616. I'm sorry, but you're right off the rails here. Suppose that I accept that 2616 includes a (re)definition of "host" that combines a domain (or, I suppose what you mean is a FQDN) and a port. Then the rules that apply to that entire set of resources available at that FQDN:port combination is just what the protocol allows. Alternatively, if you're saying that there are operator policies that you want to express about that FQDN:port combination, it seems to me that you could use the SRV suggestion I already made upthread. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From ajs@shinkuro.com Fri Jun 26 09:34:20 2009 Return-Path: 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 CC52E3A6BEA for ; Fri, 26 Jun 2009 09:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[AWL=0.620, 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 g1DkK6ZV0uPE for ; Fri, 26 Jun 2009 09:34:20 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id EC1493A6BE5 for ; Fri, 26 Jun 2009 09:34:14 -0700 (PDT) Received: from crankycanuck.ca (76-10-166-247.dsl.teksavvy.com [76.10.166.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 13AD82FE9664; Fri, 26 Jun 2009 16:34:29 +0000 (UTC) Date: Fri, 26 Jun 2009 12:34:27 -0400 From: Andrew Sullivan To: Eran Hammer-Lahav Subject: Re: URI for abstract concepts (domain, host, origin, site, etc.) Message-ID: <20090626163426.GI481@shinkuro.com> References: <90C41DD21FB7C64BB94121FBBC2E7234378339816C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4A43F382.5020600@w3.org> <90C41DD21FB7C64BB94121FBBC2E723437833981C0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4A4437DC.3090201@w3.org> <90C41DD21FB7C64BB94121FBBC2E723437833981DC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4A446EAA.5030906@it.aoyama.ac.jp> <90C41DD21FB7C64BB94121FBBC2E72343783398202@P3PW5EX1MB01.EX1.SECURESERVER.NET> <20090626160544.GF481@shinkuro.com> <90C41DD21FB7C64BB94121FBBC2E72343783398217@P3PW5EX1MB01.EX1.SECURESERVER.NET> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343783398217@P3PW5EX1MB01.EX1.SECURESERVER.NET> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: "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: , X-List-Received-Date: Fri, 26 Jun 2009 16:34:20 -0000 On Fri, Jun 26, 2009 at 09:14:55AM -0700, Eran Hammer-Lahav wrote: > > I am using only RFC 3986 terminology here from section 3 [1]. That section does not use host the way you have so far discussed. In particular, as you note, "host" is used separately from port, so the concept of host _does not_ include the port number, whatever else it includes. "Host" is later boiled down to IP literal in square brackets, a dotted quad, or "registered name". This is an excellent example of the long-standing confusion among even experienced IETF experts between a fully-qualified domain name and a host name. Host names are not all FQDNs, and the confusion that has been caused by this historical overloading is exactly the kind of thing that causes discussions like the one you and I are having. I urge you to go and read the RFCs I already mentioned. I'm not saying that's sufficient for teasing out the differences we're talking about (I get confused about these things all the time), but it sure is necessary. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From eran@hueniverse.com Fri Jun 26 09:37:22 2009 Return-Path: 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 502373A67F5 for ; Fri, 26 Jun 2009 09:37:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.047, 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 76vtlD6Jryzp for ; Fri, 26 Jun 2009 09:37:21 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 853C43A6A8C for ; Fri, 26 Jun 2009 09:37:21 -0700 (PDT) Received: (qmail 15600 invoked from network); 26 Jun 2009 16:37:39 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 26 Jun 2009 16:37:39 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Fri, 26 Jun 2009 09:37:39 -0700 From: Eran Hammer-Lahav To: Andrew Sullivan Date: Fri, 26 Jun 2009 09:37:34 -0700 Subject: RE: URI for abstract concepts (domain, host, origin, site, etc.) Thread-Topic: URI for abstract concepts (domain, host, origin, site, etc.) Thread-Index: Acn2e+qRzvCqYHFpSJWKyE55FzoM0gAADFyA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343783398226@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234378339816C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4A43F382.5020600@w3.org> <90C41DD21FB7C64BB94121FBBC2E723437833981C0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4A4437DC.3090201@w3.org> <90C41DD21FB7C64BB94121FBBC2E723437833981DC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4A446EAA.5030906@it.aoyama.ac.jp> <90C41DD21FB7C64BB94121FBBC2E72343783398202@P3PW5EX1MB01.EX1.SECURESERVER.NET> <20090626160544.GF481@shinkuro.com> <90C41DD21FB7C64BB94121FBBC2E72343783398217@P3PW5EX1MB01.EX1.SECURESERVER.NET> <20090626163426.GI481@shinkuro.com> In-Reply-To: <20090626163426.GI481@shinkuro.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "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: , X-List-Received-Date: Fri, 26 Jun 2009 16:37:22 -0000 You already convinced me. This is why I switched to define my problem in cl= ear terms from a single RFC (3986). So now that I redefined my problem, got= ideas? EHL > -----Original Message----- > From: Andrew Sullivan [mailto:ajs@shinkuro.com] > Sent: Friday, June 26, 2009 9:34 AM > To: Eran Hammer-Lahav > Cc: apps-discuss@ietf.org > Subject: Re: URI for abstract concepts (domain, host, origin, site, > etc.) >=20 > On Fri, Jun 26, 2009 at 09:14:55AM -0700, Eran Hammer-Lahav wrote: > > > > I am using only RFC 3986 terminology here from section 3 [1]. >=20 > That section does not use host the way you have so far discussed. In > particular, as you note, "host" is used separately from port, so the > concept of host _does not_ include the port number, whatever else it > includes. >=20 > "Host" is later boiled down to IP literal in square brackets, a dotted > quad, or "registered name". This is an excellent example of the > long-standing confusion among even experienced IETF experts between a > fully-qualified domain name and a host name. Host names are not all > FQDNs, and the confusion that has been caused by this historical > overloading is exactly the kind of thing that causes discussions like > the one you and I are having. I urge you to go and read the RFCs I > already mentioned. I'm not saying that's sufficient for teasing out > the differences we're talking about (I get confused about these things > all the time), but it sure is necessary. >=20 > A > -- > Andrew Sullivan > ajs@shinkuro.com > Shinkuro, Inc. From masinter@gmail.com Fri Jun 26 09:54:12 2009 Return-Path: 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 B477F3A6BC0 for ; Fri, 26 Jun 2009 09:54:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 gsoCTSO8zqZ3 for ; Fri, 26 Jun 2009 09:54:11 -0700 (PDT) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.178]) by core3.amsl.com (Postfix) with ESMTP id CC31A3A6BE5 for ; Fri, 26 Jun 2009 09:54:07 -0700 (PDT) Received: by wa-out-1112.google.com with SMTP id v27so411366wah.5 for ; Fri, 26 Jun 2009 09:54:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:content-language:thread-index; bh=yo/t8MO1qPPJyzuFTTz+GCwhSWo3VV5PsUoM4Ew0udY=; b=iwS8zj2u3eoxJKk/oPdsjnrnbTrXcyV6zqKW/IXYsuOSfzU8MNtuthqlzqXNXJBETW EQahGDOKvFIYkfXTQzqlNnob5aCizzHtUW6SjbaAQqZCwZsDBleCtAslcr5db6uz5R+s GHRDddEN+n3LSpHoQx6ZodTqEsMPqwMIQYlf0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :content-language:thread-index; b=FXv16KUDyNtkkHaSRpJRW9ytCaiDHyIceDJYxfgEBWuxKrYLH+GJbPAUVStE6dOaD2 o/mcKPf2ikVFy5yXMxJW6oO5Cfemt2swuVJa2HatN/1vbTEKZ2OLfqhvmeh8rev453CM nWz1RaSdwzxyLssgemL7BcSftGniqRuap1II4= Received: by 10.114.159.16 with SMTP id h16mr1948571wae.35.1246035264308; Fri, 26 Jun 2009 09:54:24 -0700 (PDT) Received: from MASINTERXP (c-76-102-104-162.hsd1.ca.comcast.net [76.102.104.162]) by mx.google.com with ESMTPS id v32sm5844509wah.13.2009.06.26.09.54.23 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 26 Jun 2009 09:54:23 -0700 (PDT) Sender: Larry Masinter From: "Larry Masinter" To: "'Pat Hayes'" , "'Eran Hammer-Lahav'" References: <90C41DD21FB7C64BB94121FBBC2E7234378339816C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4A43F382.5020600@w3.org> <90C41DD21FB7C64BB94121FBBC2E723437833981C0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4A4437DC.3090201@w3.org> <90C41DD21FB7C64BB94121FBBC2E723437833981DC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <66FB7DD9-7D0B-4877-ACBE-1618507CBFDA@ihmc.us> <90C41DD21FB7C64BB94121FBBC2E72343783398212@P3PW5EX1MB01.EX1.SECURESERVER.NET> <91A2EB7E-63BE-42EA-A7E6-B02FFF726C6A@ihmc.us> In-Reply-To: <91A2EB7E-63BE-42EA-A7E6-B02FFF726C6A@ihmc.us> Subject: RE: URI for abstract concepts (domain, host, origin, site, etc.) Date: Fri, 26 Jun 2009 09:54:22 -0700 Message-ID: <005801c9f67e$c28702f0$479508d0$@org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Content-Language: en-us thread-index: Acn2eaZm8QHOPeYdRPiQOlAKCvg3+QABMrug Cc: 'URI' , 'Dan Connolly' , www-tag@w3.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: , X-List-Received-Date: Fri, 26 Jun 2009 16:54:12 -0000 # They aren't being treated differently. The normal syntax for naming # something in RDF is a URI reference with a fragid attached. The use of # a fragID cancels any assumptions that the URIreference denotes something connected with the HTTP protocol. How does it do that? # This is how RDF manages to # refer to galaxies, chemical elements, people, etc.. Sounds like this is only in the context of RDF. Larry -- http://larry.masinter.net From duerst@it.aoyama.ac.jp Sun Jun 28 01:04:18 2009 Return-Path: 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 32FB23A6836 for ; Sun, 28 Jun 2009 01:04:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.894 X-Spam-Level: X-Spam-Status: No, score=0.894 tagged_above=-999 required=5 tests=[AWL=-0.999, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_43=0.6, MIME_8BIT_HEADER=0.3, URIBL_RHS_DOB=1.083] 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 DGfwfXPM6yHw for ; Sun, 28 Jun 2009 01:04:17 -0700 (PDT) Received: from scmailgw02.scop.aoyama.ac.jp (scmailgw02.scop.aoyama.ac.jp [133.2.251.42]) by core3.amsl.com (Postfix) with ESMTP id 10F593A67DA for ; Sun, 28 Jun 2009 01:04:16 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp (scmse02.scbb.aoyama.ac.jp [133.2.253.159]) by scmailgw02.scop.aoyama.ac.jp (secret/secret) with SMTP id n5S84OTf025592 for ; Sun, 28 Jun 2009 17:04:24 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 254b_4b2a31ec_63ba_11de_83d7_001d096c5782; Sun, 28 Jun 2009 17:04:24 +0900 Received: from [IPv6:::1] ([133.2.210.1]:39767) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Sun, 28 Jun 2009 17:02:20 +0900 Message-ID: <4A4723F4.2030807@it.aoyama.ac.jp> Date: Sun, 28 Jun 2009 17:04:04 +0900 From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090108 Eudora/3.0b1pre MIME-Version: 1.0 To: Xiaoshu Wang Subject: Re: URI for abstract concepts (domain, host, origin, site, etc.) References: <90C41DD21FB7C64BB94121FBBC2E7234378339816C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4A43F382.5020600@w3.org> <90C41DD21FB7C64BB94121FBBC2E723437833981C0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4A4437DC.3090201@w3.org> <90C41DD21FB7C64BB94121FBBC2E723437833981DC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <66FB7DD9-7D0B-4877-ACBE-1618507CBFDA@ihmc.us> <90C41DD21FB7C64BB94121FBBC2E72343783398212@P3PW5EX1MB01.EX1.SECURESERVER.NET> <91A2EB7E-63BE-42EA-A7E6-B02FFF726C6A@ihmc.us> <005801c9f67e$c28702f0$479508d0$@org> <4A4504FE.3050108@danbri.org> <4A451511.2060400@musc.edu> In-Reply-To: <4A451511.2060400@musc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: 'Pat Hayes' , "apps-discuss@ietf.org" , Larry Masinter , 'URI' , 'Dan Connolly' , Dan Brickley , "www-tag@w3.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: , X-List-Received-Date: Sun, 28 Jun 2009 08:04:18 -0000 On 2009/06/27 3:36, Xiaoshu Wang wrote: > Thus, > > "http://danbri.org/foaf.rdf#danbri" denotes a person. > "http://danbri.org/foaf.rdf#(application/rdf+xml)danbri" denotes an RDF > node. > "http://danbri.org/foaf.rdf#(application/xhtml+xml)danbri" denotes an > HTML element ided "danbri I don't understand this. Why wouldn't I just use http://danbri.org/foo.html#danbri or anything similar for HTML fragments? (I'm assuming that foaf.rdf returns an application/rdf+xml documend, and foo.html returns an application/xhtml+xml document; the extensions may be meaningless to the protocol but help to keep things apart for humans and computers.) Also, I don't see much of a need to denote an RDF node per se. I'm sure there are special applications one can come up with where reasoning about RDF nodes per se is helpful/necessary/whatever, but for such cases, there are other techniques available already. A single special property and blank nodes would do the job. Regards, Martin. > When a URI owner uses content negotiation, they should make the content > of each representation consistent. Of course, there could be > inconsistencies if a user is not careful. But it is no different from > the case when someonelse makes an inconsistent statement about > "http://danbri.org/foaf.rdf#danbri". Inconsistent resources (whether it > is caused by the same root-URI owner or not) will simply not be used > (i.e., linked) by others, hence eventually die of isolation. > This is the same old story from the httpRange-14. Once we straighten > that out, all other problems are very easy to answer. > > Xiaoshu > > > > -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From masinter@gmail.com Sun Jun 28 10:53:20 2009 Return-Path: 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 10C403A6B04 for ; Sun, 28 Jun 2009 10:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 DF880-4Vo0xh for ; Sun, 28 Jun 2009 10:53:18 -0700 (PDT) Received: from mail-px0-f178.google.com (mail-px0-f178.google.com [209.85.216.178]) by core3.amsl.com (Postfix) with ESMTP id AED2A3A6884 for ; Sun, 28 Jun 2009 10:53:18 -0700 (PDT) Received: by pxi8 with SMTP id 8so680757pxi.29 for ; Sun, 28 Jun 2009 10:53:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=oiyFwIGNdKZib+7avbOk9+v7GwoUlk2ufQcam+iPKw0=; b=ZbbQrocc+lgF1LRPaZTeaT8s0/rl2LcSCd3Mo3qUZl6oTNdIz/+50IFTIaHG4FiO1k 66icTfvyCQOcQBtzGqmcOoL6jEnWMhIn4//f0Kf5ywNw5jMtYlAJ3+TXauQA5tajcVPV LL7UHj2TWncP3WxfxaQkJihzw71uMJ0P2fIeo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=UNKdGnFIwUGAfbOJ+3QXnOQcAfE2QCccmsekljd0DnI0Qs2fsfk1Wbg8IyGAhd47qh vQolTneykUha8CC9iv7V65kmah1QnfL9nO1GeEIf8OB+nW92Egovj72FrXnblauMuA2X D2R0+Lh066hbMaf9Tki+ZDh1y867QGmFHqcjg= Received: by 10.114.92.18 with SMTP id p18mr9939987wab.45.1246211614990; Sun, 28 Jun 2009 10:53:34 -0700 (PDT) Received: from MASINTERXP (c-76-102-104-162.hsd1.ca.comcast.net [76.102.104.162]) by mx.google.com with ESMTPS id g25sm8382605wag.8.2009.06.28.10.53.33 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 28 Jun 2009 10:53:34 -0700 (PDT) Sender: Larry Masinter From: "Larry Masinter" To: "'Jonathan Rees'" , References: <90C41DD21FB7C64BB94121FBBC2E7234378339816C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4A46C264.6090700@oracle.com> <760bcb2a0906280942jcb99a26y76e99b3f0d8783be@mail.gmail.com> In-Reply-To: <760bcb2a0906280942jcb99a26y76e99b3f0d8783be@mail.gmail.com> Subject: RE: URI for abstract concepts (domain, host, origin, site, etc.) Date: Sun, 28 Jun 2009 10:53:31 -0700 Message-ID: <002101c9f819$5a60bd50$0f2237f0$@org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acn4D6yOQpOpyxTjTJuWfG/XBwh4NgACK2YA Content-Language: en-us Cc: www-tag@w3.org, 'URI' , 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: , X-List-Received-Date: Sun, 28 Jun 2009 17:53:20 -0000 I'm thinking about revising http://larry.masinter.net/duri.html to: (1) to get rid of "duri" and just stick with "tdb" (because there isn't much use for duri at all) (2) make it a URI scheme rather than a URN namespace (3) make the date optional, for cases where the time of binding resource to representation (and of interpretation of that representation to an 'abstract concept') So the simplest form would be tdb:http://larry.masinter.net which would neatly allow using descriptions of abstract concepts to identify the abstract concept. (Syntactically, the date can be left out without ambiguity.) Would this be helpful, at least for illustrative purposes? I think there are other means for distinguishing between the representation of a description and=20 the thing described, but this would at least add a well-known method that isn't tied to any particular protocol, linking method, resolution method, etc. tdb:data:,the%20host%20larry.masinter.net might be a simple inline way of talking about the 'host' named 'larry.masinter.net'. Larry --=20 http://larry.masinter.net =20 -----Original Message----- From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] On Behalf = Of Jonathan Rees Sent: Sunday, June 28, 2009 9:43 AM To: ashok.malhotra@oracle.com Cc: Eran Hammer-Lahav; apps-discuss@ietf.org; www-tag@w3.org; URI Subject: Re: URI for abstract concepts (domain, host, origin, site, = etc.) On Sat, Jun 27, 2009 at 9:07 PM, ashok malhotra wrote: > Hi Eran: > Trying to understand your proposal. > By 'abstract' do you mean URIs for which a representation cannot be > retrieved? > So, perhaps, a chair? > My assumption was that for such resources you want to retrieve the = metadata. Quibble: In the case of a chair, you can't get metadata, since a chair isn't data. http://www.google.com/search?q=3Ddefine:metadata This is why it's nice that Eran calls the description resource a "description resource" instead of a "metadata resource". LRDD is a compatible alternative to linked-data 303 nose-following, one that (like 303, as David Booth has pointed out) behaves uniformly without caring whether the resource is "data"-like or not - it means you don't have to ask or answer that question. I advocate using his terminology. Perhaps an alternative to a new URI scheme for hosts would be loop detection inside of LRDD? I think that's close to what you're saying. -Jonathan From eran@hueniverse.com Sun Jun 28 11:09:35 2009 Return-Path: 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 71A9228C0FA for ; Sun, 28 Jun 2009 11:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.713 X-Spam-Level: X-Spam-Status: No, score=-1.713 tagged_above=-999 required=5 tests=[AWL=-0.797, BAYES_00=-2.599, J_CHICKENPOX_26=0.6, URIBL_RHS_DOB=1.083] 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 v1cHc5HTWYJ6 for ; Sun, 28 Jun 2009 11:09:34 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 73E7428C0F0 for ; Sun, 28 Jun 2009 11:09:34 -0700 (PDT) Received: (qmail 32519 invoked from network); 28 Jun 2009 18:09:54 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 28 Jun 2009 18:09:53 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Sun, 28 Jun 2009 11:09:53 -0700 From: Eran Hammer-Lahav To: "ashok.malhotra@oracle.com" Date: Sun, 28 Jun 2009 11:09:53 -0700 Subject: RE: URI for abstract concepts (domain, host, origin, site, etc.) Thread-Topic: URI for abstract concepts (domain, host, origin, site, etc.) Thread-Index: Acn3jNCWZQXxc+A8S3+wMEAi3d2xVAAjNaGw Message-ID: <90C41DD21FB7C64BB94121FBBC2E723437833982F0@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234378339816C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4A46C264.6090700@oracle.com> In-Reply-To: <4A46C264.6090700@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: URI , "www-tag@w3.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: , X-List-Received-Date: Sun, 28 Jun 2009 18:09:35 -0000 Let me try explaining my use case again, this time without any overloaded t= erminology or proposed solutions. --- XRD is a document format for describing resources. It looks like this: http://example.com http://example.org/type/blog author http://example.com/author Without getting too much into XRD, this short descriptor describes the reso= urce identified by 'http://example.com'. It includes one type indicator (a = made up example meant to mean this resource is a blog), and one link to the= author's page. --- I want to use this document format to describe rules that apply to all reso= urces which belong to an HTTP host (as defined by 2616: a domain/address an= d port combination). The problem is, requires a URI and currently= there is no way to identify this set of resources (http://domain:port/*) a= s a valid URI. What I don't want to do is use an exception such as 'if the URI begins with= X, treat it as a rule and not a valid URI'... EHL > -----Original Message----- > From: ashok malhotra [mailto:ashok.malhotra@oracle.com] > Sent: Saturday, June 27, 2009 6:08 PM > To: Eran Hammer-Lahav > Cc: apps-discuss@ietf.org; www-tag@w3.org; URI > Subject: Re: URI for abstract concepts (domain, host, origin, site, > etc.) >=20 > Hi Eran: > Trying to understand your proposal. > By 'abstract' do you mean URIs for which a representation cannot be > retrieved? > So, perhaps, a chair? >=20 > My assumption was that for such resources you want to retrieve the > metadata. > To do that you do a GET which returns a 'Not Found' as well as a Link > Header. >=20 > Of course, if you know syntactically that the resource does not have a > representation > you can save one access and go directly for the metadata. >=20 > Is that where you are going? >=20 > All the best, Ashok >=20 >=20 > Eran Hammer-Lahav wrote: > > LRDD [1] defines a way to link a descriptor (metadata, information > about, etc.) to a resource. It keeps the document format of the > descriptor out of scope, leaving it up to existing formats (XRDS, XRD, > POWDER, Metalink, etc.) and new format to address. > > > > Most of these descriptor formats include an element which indicates > what the document is about - the subject of the descriptor. XRD > includes the element for this purpose with xs:anyURI as its > type. I believe POWDER uses RDF's 'about' attribute in a similar way > IIRC. > > > > We have some use cases in which the subject of the descriptor does > not have a URI available. > > > > LRDD uses a well-known-location document (/host-meta, soon to be > replaced with /.well-known/host-meta) to store information about the > abstract host resource (the combination of domain name and port number, > potentially also including protocol). Over the past few years, ad-hoc > protocols have been abusing the root resource URI to mean something > beyond just the root resource of a domain - basically as a placeholder > for information about the entire domain or host. > > > > The lack of URI for such concepts is preventing descriptor formats > from being used here because there is no valid URI available to insert > into the subject container. While no representation is expected for > such abstract concepts, within the context of descriptors, being able > to reference them is critical. > > > > The use case at hand is using XRD as the document format for host- > meta. Host-meta describes attributes of the host which by itself does > not currently have a URI. We need to figure out what to put in the > host-meta document's element which has direct impact on the > trust profile and signature (but is outside the scope of this > discussion). > > > > So far I could only come up with two options: > > > > 1. Make a special case exception that when the subject is > http://______/.well-known/host-meta, it is treated differently than any > other URI in that it means the XRD is not about that URI (the host-meta > document itself), but about the abstract host resource located at > ______. > > > > 2. Define a new kind of URI that can be used for abstract entities > such as "host" or "domain", but which is not an http URI because that > will bring us right back to #1. > > > > I would like to ask for feedback on the idea of proposing a new URI > scheme or a new URN namespace for this purpose, something like > 'abstract'. > > It will look something like this (please focus on the idea, not the > syntax of the examples): > > > > urn:abstract:domain:example.com > > urn:abstract:host:example.com:8080 > > urn:abstract:origin:example.com:8080:http > > > > or > > > > abstract://example.com/domain > > abstract://example.com:8080/host > > abstract://example.com:8080:http/origin > > > > Any comments, feedback, or concerns would be greatly appreciated. > > > > EHL > > > > [1] http://tools.ietf.org/html/draft-hammer-discovery > > > > > > > > From eran@hueniverse.com Sun Jun 28 22:24:08 2009 Return-Path: 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 555633A68EB for ; Sun, 28 Jun 2009 22:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 TyrSS9L9H+R9 for ; Sun, 28 Jun 2009 22:24:07 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id EB8F93A6B31 for ; Sun, 28 Jun 2009 22:24:06 -0700 (PDT) Received: (qmail 25584 invoked from network); 29 Jun 2009 05:24:26 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 29 Jun 2009 05:24:25 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Sun, 28 Jun 2009 22:24:25 -0700 From: Eran Hammer-Lahav To: Xiaoshu Wang Date: Sun, 28 Jun 2009 22:24:26 -0700 Subject: RE: URI for abstract concepts (domain, host, origin, site, etc.) Thread-Topic: URI for abstract concepts (domain, host, origin, site, etc.) Thread-Index: Acn4YfPE5nQdNtlrTt6Htoq4v/XEHwAFsd2g Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343783398302@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E7234378339816C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4A46C264.6090700@oracle.com> <90C41DD21FB7C64BB94121FBBC2E723437833982F0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4A482805.6020401@musc.edu> In-Reply-To: <4A482805.6020401@musc.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: URI , "www-tag@w3.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: , X-List-Received-Date: Mon, 29 Jun 2009 05:24:08 -0000 > -----Original Message----- > From: Xiaoshu Wang [mailto:wangxiao@musc.edu] > Sent: Sunday, June 28, 2009 7:34 PM > (1) You develop your XSD document format, in whatever form you think is > the most suitable. And you deploy that definition in the Web, say > http://xsd.type.com, which in essence makes it a media-type. > (2) Then, you client content-negotiate the XSD content with that URI > with the desired resource. >=20 > It is as easy as it gets. All communication problem can (and I think > should be solved in this way). I said can because, as Butler Lampson > has famously said: "All problems in computer science can be solved by > another level of indirection". Content negotiation is just a level of > "indirection". The problem is abstracted into a URI and then > negotiated > over that URI. I disagree [1], and have no interest in having this discussion with you *ag= ain* [2]. EHL [1] http://www.hueniverse.com/hueniverse/2009/03/discovery-and-content-nego= tiation.html [2] http://lists.w3.org/Archives/Public/www-tag/2009Mar/0034.html From duerst@it.aoyama.ac.jp Mon Jun 29 00:35:54 2009 Return-Path: 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 62FCF3A6D5E for ; Mon, 29 Jun 2009 00:35:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.374 X-Spam-Level: X-Spam-Status: No, score=0.374 tagged_above=-999 required=5 tests=[AWL=-0.436, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_43=0.6, MIME_8BIT_HEADER=0.3] 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 azkCiVHehhhi for ; Mon, 29 Jun 2009 00:35:53 -0700 (PDT) Received: from scmailgw01.scop.aoyama.ac.jp (scmailgw01.scop.aoyama.ac.jp [133.2.251.41]) by core3.amsl.com (Postfix) with ESMTP id 330693A690B for ; Mon, 29 Jun 2009 00:35:52 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp (scmse02.scbb.aoyama.ac.jp [133.2.253.159]) by scmailgw01.scop.aoyama.ac.jp (secret/secret) with SMTP id n5T7Zu8Y015951 for ; Mon, 29 Jun 2009 16:36:01 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 711d_7b842328_647f_11de_b369_001d096c5782; Mon, 29 Jun 2009 16:35:56 +0900 Received: from [IPv6:::1] ([133.2.210.1]:52651) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Mon, 29 Jun 2009 16:33:51 +0900 Message-ID: <4A486EC6.8080101@it.aoyama.ac.jp> Date: Mon, 29 Jun 2009 16:35:34 +0900 From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090108 Eudora/3.0b1pre MIME-Version: 1.0 To: Xiaoshu Wang Subject: Re: URI for abstract concepts (domain, host, origin, site, etc.) References: <90C41DD21FB7C64BB94121FBBC2E7234378339816C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4A43F382.5020600@w3.org> <90C41DD21FB7C64BB94121FBBC2E723437833981C0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4A4437DC.3090201@w3.org> <90C41DD21FB7C64BB94121FBBC2E723437833981DC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <66FB7DD9-7D0B-4877-ACBE-1618507CBFDA@ihmc.us> <90C41DD21FB7C64BB94121FBBC2E72343783398212@P3PW5EX1MB01.EX1.SECURESERVER.NET> <91A2EB7E-63BE-42EA-A7E6-B02FFF726C6A@ihmc.us> <005801c9f67e$c28702f0$479508d0$@org> <4A4504FE.3050108@danbri.org> <4A451511.2060400@musc.edu> <4A4723F4.2030807@it.aoyama.ac.jp> <4A47860E.2020701@musc.edu> In-Reply-To: <4A47860E.2020701@musc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: 'Pat Hayes' , "apps-discuss@ietf.org" , Larry Masinter , 'URI' , 'Dan Connolly' , Dan Brickley , "www-tag@w3.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: , X-List-Received-Date: Mon, 29 Jun 2009 07:35:54 -0000 On 2009/06/29 0:02, Xiaoshu Wang wrote: > Martin J. Dürst wrote: >> On 2009/06/27 3:36, Xiaoshu Wang wrote: >> >>> Thus, >>> >>> "http://danbri.org/foaf.rdf#danbri" denotes a person. >>> "http://danbri.org/foaf.rdf#(application/rdf+xml)danbri" denotes an RDF >>> node. >>> "http://danbri.org/foaf.rdf#(application/xhtml+xml)danbri" denotes an >>> HTML element ided "danbri >> >> I don't understand this. Why wouldn't I just use >> http://danbri.org/foo.html#danbri >> or anything similar for HTML fragments? (I'm assuming that foaf.rdf >> returns an application/rdf+xml documend, and foo.html returns an >> application/xhtml+xml document; the extensions may be meaningless to >> the protocol but help to keep things apart for humans and computers.) > Well, then it just doesn't work for extending the referential range of > URI to denote things beyond engineering entities. If you take a URI > (fragment or not) to denote document (or its sub-structure), then the > Web is not much useful to our daily use. If you take a URI to denote > other things, like a human or person, then you cannot describe a > document structure. And there is one URI, then you have to make a > decision which one it denotes, right? Yes, each URI better denotes only one thing. But that doesn't mean that all URIs (with fragment identifiers) denote subdocuments, and it doesn't mean that all URIs (with fragment identifiers) denote 'other things'. It means that each individual URI denotes either one or the other, and that you find out which one (if you need to) by getting more information about it. >> Also, I don't see much of a need to denote an RDF node per se. I'm >> sure there are special applications one can come up with where >> reasoning about RDF nodes per se is helpful/necessary/whatever, but >> for such cases, there are other techniques available already. A single >> special property and blank nodes would do the job. > Sure, we can use special property and blank nodes, but don't we need to > know a URI does first before applying a property to that right? People who 'apply properties' to URIs (which I assume you mean to add properties about an URI) will know an URI from other information or because they created the URI and decided what they want to use it for. People who see an URI for the first time have to find out what it stands for either from context or from dereferencing (or probably from both). Regards, Martin. -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From enrico.marocco@telecomitalia.it Mon Jun 29 02:14:12 2009 Return-Path: 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 81B153A69B3; Mon, 29 Jun 2009 02:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.59 X-Spam-Level: X-Spam-Status: No, score=-0.59 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 IENa+8wjK4EP; Mon, 29 Jun 2009 02:14:11 -0700 (PDT) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by core3.amsl.com (Postfix) with ESMTP id D08E03A683A; Mon, 29 Jun 2009 02:13:44 -0700 (PDT) Received: from GRFHUB701BA020.griffon.local (10.188.101.111) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.1.340.0; Mon, 29 Jun 2009 11:14:02 +0200 Received: from [10.229.8.41] (10.229.8.41) by smtp.telecomitalia.it (10.188.101.114) with Microsoft SMTP Server (TLS) id 8.1.359.3; Mon, 29 Jun 2009 11:14:02 +0200 Message-ID: <4A4885DC.3000707@telecomitalia.it> Date: Mon, 29 Jun 2009 11:14:04 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: "alto@ietf.org" Subject: [alto] IETF75 - Current status and agenda requests X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010502080200060303080006" Cc: Jon Peterson , 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: , X-List-Received-Date: Mon, 29 Jun 2009 09:14:12 -0000 --------------ms010502080200060303080006 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, the ALTO WG will meet in Stockholm in a 2-hour session currently scheduled for Tuesday July 28. As usual, we would like to make best use of meeting time in order to progress the work the group has been chartered for. At this time, the following are the high-priority documents: - problem statement (draft-ietf-alto-problem-statement): WGLC ended on June 15 and the authors are now working on a new version that should reflect all the comments received. If any of the issues raised on the list require more than trivial editorial changes, I would very much like to see them addressed during this meeting; - requirements (draft-ietf-alto-reqs): the WG agreed in San Francisco to keep the document alive for a while, on the one hand, not to commit now to something we may reconsider in the future, and, on the other hand, to reflect the consensus of the WG on relevant issues. There has recently been quite a lot of discussion regarding the kind of information to put/avoid in the ALTO protocol and this is probably an open issue deserving meeting time; - protocol proposals: in SF we started a discussion about individual proposals and, more generally, solution approaches. Any update on them will be certainly of interest to the WG; - discovery: two drafts dealing with discovery issues were presented in SF and a merge was announced. At an higher level, the topic was also addressed also during the APPAREA meeting, providing good input for the ALTO-specific work. If you wish to request a slot on the agenda, please send Jon, Vijay and me a short description of the topic and a pointer to the related drafts. -- Ciao, Enrico --------------ms010502080200060303080006 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJwTCC AzswggKkoAMCAQICEEIEYmjMZBX3Us1Th/pMjJYwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDMxNjE3NTMwMloX DTEwMDMxNjE3NTMwMlowejEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEuMCwG CSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDEnMCUGCSqGSIb3 DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAvd38YWuquonbz4lP4GKp0qij0v4MgXpK/BW87GvoqHz3iQvO1Tb6f4yEtFel vpK2drtUHWyY+ww6QQSOGJvSWEKTRVX5KsXpN2yNeY4kceezCjsXBvwNPlGHrzJifUByvwzD QSnQLocE1i89x7P2T5brcaGBBgricwQL1Cggg97zp1yGrj2VIJE03GSpEL01d+omAFUou3mx 8R/9XOnGnSlDpcOV6s2Ww3NN07+7sSBaE0vcvlYF8pr1BWDl2JJobG9qpC9DlplpDZOdmsAG u/qwsI0AsucY5ZBFKqzKizQ5PGhrh3u2PHRGNncuHUANF0cPfVs7AHjHjudH7PzU2wIDAQAB o1YwVDBEBgNVHREEPTA7gR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0gRhlbnJp Y28ubWFyb2Njb0BnbWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQB3 Mi6SymgE1cfsbmr5LWvWVdO58/a0O95kXL2puRn9kGjFN1tAzHQc/UxJs0gIyRRs3gGBR+p6 TT1gmnucO8Ji0gJBMBL+ogcfyaV30hZtUceiRevemXvZW2QOCLdYUf6KdB6ccX7r3a58SRRL l5YTZ7bIhyAEmeI60ioyMI8U5jCCAzswggKkoAMCAQICEEIEYmjMZBX3Us1Th/pMjJYwDQYJ KoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBMB4XDTA5MDMxNjE3NTMwMloXDTEwMDMxNjE3NTMwMlowejEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNv bWl0YWxpYS5pdDEnMCUGCSqGSIb3DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvd38YWuquonbz4lP4GKp0qij0v4MgXpK /BW87GvoqHz3iQvO1Tb6f4yEtFelvpK2drtUHWyY+ww6QQSOGJvSWEKTRVX5KsXpN2yNeY4k ceezCjsXBvwNPlGHrzJifUByvwzDQSnQLocE1i89x7P2T5brcaGBBgricwQL1Cggg97zp1yG rj2VIJE03GSpEL01d+omAFUou3mx8R/9XOnGnSlDpcOV6s2Ww3NN07+7sSBaE0vcvlYF8pr1 BWDl2JJobG9qpC9DlplpDZOdmsAGu/qwsI0AsucY5ZBFKqzKizQ5PGhrh3u2PHRGNncuHUAN F0cPfVs7AHjHjudH7PzU2wIDAQABo1YwVDBEBgNVHREEPTA7gR9lbnJpY28ubWFyb2Njb0B0 ZWxlY29taXRhbGlhLml0gRhlbnJpY28ubWFyb2Njb0BnbWFpbC5jb20wDAYDVR0TAQH/BAIw ADANBgkqhkiG9w0BAQUFAAOBgQB3Mi6SymgE1cfsbmr5LWvWVdO58/a0O95kXL2puRn9kGjF N1tAzHQc/UxJs0gIyRRs3gGBR+p6TT1gmnucO8Ji0gJBMBL+ogcfyaV30hZtUceiRevemXvZ W2QOCLdYUf6KdB6ccX7r3a58SRRLl5YTZ7bIhyAEmeI60ioyMI8U5jCCAz8wggKooAMCAQIC AQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENh cGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAm BgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1h aWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQD EyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B 1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79A gAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8E CDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEa MBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7M DaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUa C4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk1 3iSx0x1G/11fZU8xggNxMIIDbQIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQQIQQgRiaMxkFfdSzVOH+kyMljAJBgUrDgMCGgUAoIIB0DAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA2MjkwOTE0MDRaMCMG CSqGSIb3DQEJBDEWBBR1u3Ns5+ZQ54XKQ/QCFLOgpNCsuzBfBgkqhkiG9w0BCQ8xUjBQMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBCBGJozGQV91LNU4f6TIyWMIGH BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAhBCBGJozGQV91LNU4f6TIyWMA0GCSqGSIb3DQEBAQUABIIBAC4Qey8hOshr fRLC4wPgrkX/ZSmK12RvxcbXU8VuWdtmOuCvzYpd60PmhohvS7UT5et53QUyj7DacaWp9UKC 4/RIP76qBsT9rTip6jNADv+MyD34HAhtQd/VA35ldhaoFGkW9+O+M+BdjDvApeoxmBvGiex8 2WaWbrPKdgQqAgzvItcMjTOPdJoDFHuclefMIPs/qqB3MOgRQmgiCtbTRba5cFxvW1evPcRR N6ZnAVCI6yRp2Tx7kU7RQ0xi0xuqHOT0iSXasVO9IJhCE/QuNAKt4kuv8bEExPtsoZ3XuzEI T64Rnl2JvuxOl8rnpjzUWCryCmnKBdo4gwLFlj4JxxYAAAAAAAA= --------------ms010502080200060303080006-- From mnot@mnot.net Mon Jun 29 21:20:11 2009 Return-Path: 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 2A70028C1EF for ; Mon, 29 Jun 2009 21:20:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.198 X-Spam-Level: X-Spam-Status: No, score=-6.198 tagged_above=-999 required=5 tests=[AWL=-2.599, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 1LVOLtS8fRq6 for ; Mon, 29 Jun 2009 21:20:10 -0700 (PDT) Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178]) by core3.amsl.com (Postfix) with ESMTP id E594E3A695D for ; Mon, 29 Jun 2009 21:20:09 -0700 (PDT) Received: from [192.168.1.6] (unknown [118.208.249.76]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id BD42723E3E1; Tue, 30 Jun 2009 00:20:28 -0400 (EDT) Message-Id: <88710490-2E52-42A0-8E5E-B055AC31CF0F@mnot.net> From: Mark Nottingham To: Sam Johnston In-Reply-To: <21606dcf0906142027y517d22c5i78398428126f5811@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: Clarifications on Web Linking with HTTP Date: Tue, 30 Jun 2009 14:20:26 +1000 References: <21606dcf0906142027y517d22c5i78398428126f5811@mail.gmail.com> X-Mailer: Apple Mail (2.935.3) Cc: 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: , X-List-Received-Date: Tue, 30 Jun 2009 04:20:11 -0000 Hi Sam, On 15/06/2009, at 1:27 PM, Sam Johnston wrote: > Morning all, > > The HTTP Link: header enables web linking without hypermedia - that > is, arbitrary content types can be linked (with attriubtes) > out-of-band rather than within the payload (e.g. HTML) itself. This > enables the use of HTTP as a meta-model (at least for individual > resources) without having to resort to Atom, which is potentially > great news for RESTful APIs. > > I am currently working on a real world application of Marks' Web > Linking I-D[1] (OGF's Open Cloud Computing Interface - > http://www.occi-wg.org/) and require clarification on a few points > (which may want to end up in the I-D). > > - First and foremost, in the absence of the LINK and UNLINK verbs > originally defined in RFC 2068[2] but specifically omitted from RFC > 2616[3], what is the preferred mechanism for manipulating these links > via HTTP? It appears that this header is intended for GET requests > only, but presumably specifying it in POST and PUT requests would be > one option that avoids the creation of [not so] "new" verbs (bearing > in mind that short of accepting Link: headers from empty POST/PUT > requests, it would be necessary to GET and then PUT the entire payload > to update links - twice if they were reciprocal). While there was an > attempt a dozen years ago to better define the relevant HTTP verbs[4], > it strikes me as more sensible to follow the example of the > Set-Cookie: header for this rather than WebDAV's example of creating > new verbs (even if we've seen them before) but you guys are the > experts. Undefined, but I imagine in a PUT/POST body does indeed make the most sense. Using the Link header in a request doesn't have well-defined semantics. > - Another concern with an arbitrary number of links is that arbitrary > string length limits may be imposed by user agents, as they are with > URLs. This should not be a problem where there is one link per header, > but it may be where the headers are concatenated as described in RFC > 2616[5]. This is a double edged sword however as some user agents have > only recently added support for multiple headers of the same type[6] > and it remains a problem for some[7]. Yes, this is true for most things. Not much that can be done about it beyond writing resilient software... > - The introduction of a link relation registry at IANA makes a lot of > sense, though it would be nice if these were common for HTTP, HTML, > Atom and other places links appear. Perhaps namespaces (e.g. > "atom:service" or "occi.state.restart") would be useful here so as to > enable significantly more future extensibility. Having a common registry is the whole idea behind the draft; similarly, extensibility is explicitly provided for (using URIs)... > - It seems useful to be able to (optionally) specify the type (as in > content type rather than relation type) of a given link, as is the > case for Atom. That said, this also seems somewhat redundant with HTTP > Content Negotiation, but implementations that choose to support the > "type" attribute may gain some performance and usability advantages > from doing so. The matter of whether this information belongs in URIs > (and if so, which side of the '?') or in HTTP headers (or both) is > still not clear to me as there are pros and cons of each - perhaps the > relation type is more suitable (or both?) as it's often not possible > to unambigously determine the relation type from the content type > (consider modeling people where both fingerprint and portrait > representations may exist in image/png format). Not sure there's a question in there... Cheers, -- Mark Nottingham http://www.mnot.net/ From samj@samj.net Tue Jun 30 04:49:47 2009 Return-Path: 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 392FA3A6B97 for ; Tue, 30 Jun 2009 04:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.001, 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 PL79zus3ah2w for ; Tue, 30 Jun 2009 04:49:46 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id 0BB713A6E50 for ; Tue, 30 Jun 2009 04:49:45 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 22so19195eye.65 for ; Tue, 30 Jun 2009 04:49:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.210.127.10 with SMTP id z10mr12961ebc.33.1246362542891; Tue, 30 Jun 2009 04:49:02 -0700 (PDT) In-Reply-To: <88710490-2E52-42A0-8E5E-B055AC31CF0F@mnot.net> References: <21606dcf0906142027y517d22c5i78398428126f5811@mail.gmail.com> <88710490-2E52-42A0-8E5E-B055AC31CF0F@mnot.net> Date: Tue, 30 Jun 2009 13:49:02 +0200 Message-ID: <21606dcf0906300449y7f26e43cv729dd681e815e9cf@mail.gmail.com> Subject: Re: Clarifications on Web Linking with HTTP From: Sam Johnston To: Mark Nottingham Content-Type: multipart/alternative; boundary=0015174c13aaa164c5046d8f643d Cc: 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: , X-List-Received-Date: Tue, 30 Jun 2009 11:49:47 -0000 --0015174c13aaa164c5046d8f643d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Tue, Jun 30, 2009 at 6:20 AM, Mark Nottingham wrote: > Hi Sam, > Thanks for getting back to me about this - your input is appreciated. > On 15/06/2009, at 1:27 PM, Sam Johnston wrote: > > - First and foremost, in the absence of the LINK and UNLINK verbs >> originally defined in RFC 2068[2] but specifically omitted from RFC >> 2616[3], what is the preferred mechanism for manipulating these links >> via HTTP? >> > > Undefined, but I imagine in a PUT/POST body does indeed make the most > sense. Using the Link header in a request doesn't have well-defined > semantics. > I think it would be something that's worth defining, albeit perhaps not in your current I-D at the 11th hour and after 6 revisions. It's just not clear to me what (outside of dedicated HTTP verb(s)) makes the most sense... I'm yet to come up with a reasonable way to do it in-band. > > - It seems useful to be able to (optionally) specify the type (as in >> content type rather than relation type) of a given link, as is the >> case for Atom. >> > > Not sure there's a question in there... Basically just observing that the "type" attribute is conspicuously absent from your Link: header I-D and wondering whether that's sensible (e.g. are there times when it makes sense to specify/advertise the type ala Atom - and I think there are - for example when you're dropping the Atom wrapping for individual resources as we're trying to do with OCCI). Sam --0015174c13aaa164c5046d8f643d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Jun 30, 2009 at 6:20 AM, Mark Nottingham <mnot@mnot.net>= wrote:
Hi Sam,

Thanks for ge= tting back to me about this - your input is appreciated.
=A0
On 15/06/2009, at 1:27 PM, Sam Johnston wrote:

- First and foremost, in the absence of the LINK and UNLINK verbs
originally defined in RFC 2068[2] but specifically omitted from RFC
2616[3], what is the preferred mechanism for manipulating these links
via HTTP? <snip>

Undefined, but I imagine in a PUT/POST body does indeed make the most sense= . Using the Link header in a request doesn't have well-defined semantic= s.

I think it would be something that's= worth defining, albeit perhaps not in your current I-D at the 11th hour an= d after 6 revisions. It's just not clear to me what (outside of dedicat= ed HTTP verb(s)) makes the most sense... I'm yet to come up with a reas= onable way to do it in-band.
=A0

- It seems useful to be able to (optionally) specify the type (as in
content type rather than relation type) of a given link, as is the
case for Atom. <snip>

Not sure there's a question in there...

Basically = just observing that the "type" attribute is conspicuously absent = from your Link: header I-D and wondering whether that's sensible (e.g. = are there times when it makes sense to specify/advertise the type ala Atom = - and I think there are - for example when you're dropping the Atom wra= pping for individual resources as we're trying to do with OCCI).

Sam

--0015174c13aaa164c5046d8f643d-- From cowan@ccil.org Thu Jun 25 18:03:36 2009 Return-Path: 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 0FC233A69EF for ; Thu, 25 Jun 2009 18:03:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 5YgK8ZuhpHQE for ; Thu, 25 Jun 2009 18:03:35 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by core3.amsl.com (Postfix) with ESMTP id 0E1E33A693B for ; Thu, 25 Jun 2009 18:03:34 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1MJzqg-0007O3-Ay; Thu, 25 Jun 2009 21:03:26 -0400 Date: Thu, 25 Jun 2009 21:03:26 -0400 To: Eran Hammer-Lahav Subject: Re: URI for abstract concepts (domain, host, origin, site, etc.) Message-ID: <20090626010326.GD30117@mercury.ccil.org> References: <90C41DD21FB7C64BB94121FBBC2E7234378339816C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4A440724.4040002@musc.edu> <90C41DD21FB7C64BB94121FBBC2E723437833981CE@P3PW5EX1MB01.EX1.SECURESERVER.NET> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723437833981CE@P3PW5EX1MB01.EX1.SECURESERVER.NET> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Mailman-Approved-At: Tue, 30 Jun 2009 20:31:32 -0700 Cc: URI , "www-tag@w3.org" , "apps-discuss@ietf.org" , Xiaoshu Wang 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: , X-List-Received-Date: Fri, 26 Jun 2009 01:03:36 -0000 Eran Hammer-Lahav scripsit: > Without passing judgment on your proposal, it is clearly not something > that can be accomplished within a short time frame. I have a very > specific need to indicate a document describes "a host" which is a > combination of domain, port, and potentially protocol. I just need to > say it formatted as a URI. A simple approach would be to use a data: URI (see RFC 2397) of the form "data:application/uri,http://www.ccil.org". I proposed this for a related purpose during the Great XML Namespace Debate, but it didn't get traction. -- Your worships will perhaps be thinking John Cowan that it is an easy thing to blow up a dog? http://www.ccil.org/~cowan [Or] to write a book? --Don Quixote, Introduction cowan@ccil.org From cowan@ccil.org Thu Jun 25 20:03:26 2009 Return-Path: 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 48CD93A6900 for ; Thu, 25 Jun 2009 20:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 toK5GCYRc4f9 for ; Thu, 25 Jun 2009 20:03:25 -0700 (PDT) Received: from earth.ccil.org (earth.ccil.org [192.190.237.11]) by core3.amsl.com (Postfix) with ESMTP id 6D5113A68AD for ; Thu, 25 Jun 2009 20:03:25 -0700 (PDT) Received: from cowan by earth.ccil.org with local (Exim 4.63) (envelope-from ) id 1MK1iz-0002u6-Tb; Thu, 25 Jun 2009 23:03:37 -0400 Date: Thu, 25 Jun 2009 23:03:37 -0400 To: Eran Hammer-Lahav Subject: Re: URI for abstract concepts (domain, host, origin, site, etc.) Message-ID: <20090626030337.GE30117@mercury.ccil.org> References: <90C41DD21FB7C64BB94121FBBC2E7234378339816C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4A440724.4040002@musc.edu> <90C41DD21FB7C64BB94121FBBC2E723437833981CE@P3PW5EX1MB01.EX1.SECURESERVER.NET> <20090626010326.GD30117@mercury.ccil.org> <90C41DD21FB7C64BB94121FBBC2E723437833981DA@P3PW5EX1MB01.EX1.SECURESERVER.NET> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723437833981DA@P3PW5EX1MB01.EX1.SECURESERVER.NET> User-Agent: Mutt/1.5.13 (2006-08-11) From: John Cowan X-Mailman-Approved-At: Tue, 30 Jun 2009 20:31:32 -0700 Cc: URI , John Cowan , "www-tag@w3.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: , X-List-Received-Date: Fri, 26 Jun 2009 03:03:26 -0000 Eran Hammer-Lahav scripsit: > Not sure how this is going to help. You still end up with an HTTP URI > with no clear semantic meaning other than an HTTP resource. What do you mean by "end up with"? A data URI is not an HTTP URI. refefers to the home page of ccil.org; refers to the URI . They are two different URIs with two different referents. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org "After all, would you consider a man without honor wealthy, even if his Dinar laid end to end would reach from here to the Temple of Toplat?" "No, I wouldn't", the beggar replied. "Why is that?" the Master asked. "A Dinar doesn't go very far these days, Master. --Kehlog Albran Besides, the Temple of Toplat is across the street." The Profit From phil@philarcher.org Fri Jun 26 02:54:48 2009 Return-Path: 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 4B4A03A68ED for ; Fri, 26 Jun 2009 02:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-4.300, BAYES_00=-2.599, J_CHICKENPOX_26=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 CfyxfMEzDnVA for ; Fri, 26 Jun 2009 02:54:47 -0700 (PDT) Received: from queueout03-winn.ispmail.ntl.com (queueout03-winn.ispmail.ntl.com [81.103.221.33]) by core3.amsl.com (Postfix) with ESMTP id 9BA7C3A6784 for ; Fri, 26 Jun 2009 02:54:27 -0700 (PDT) Received: from aamtaout01-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout01-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20090626094602.ITSO6742.mtaout01-winn.ispmail.ntl.com@aamtaout01-winn.ispmail.ntl.com>; Fri, 26 Jun 2009 10:46:02 +0100 Received: from [192.168.1.2] (really [86.3.206.22]) by aamtaout01-winn.ispmail.ntl.com (InterMail vG.2.02.00.01 201-2161-120-102-20060912) with ESMTP id <20090626094602.LZPF13254.aamtaout01-winn.ispmail.ntl.com@[192.168.1.2]>; Fri, 26 Jun 2009 10:46:02 +0100 Message-ID: <4A4498D5.4080906@philarcher.org> Date: Fri, 26 Jun 2009 10:45:57 +0100 From: Phil Archer User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Eran Hammer-Lahav Subject: Re: URI for abstract concepts (domain, host, origin, site, etc.) References: <90C41DD21FB7C64BB94121FBBC2E7234378339816C@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234378339816C@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Cloudmark-Analysis: v=1.0 c=1 a=3ZAkCsyKlbEA:10 a=3j4BkbkPAAAA:8 a=w7AnJT21AAAA:8 a=A1X0JdhQAAAA:8 a=SSmOFEACAAAA:8 a=48vgC7mUAAAA:8 a=RFp60smDAAAA:8 a=5-mYX-T0UncubxAaLXQA:9 a=Yhq-GBxIiGgLJNhPHW0A:7 a=0KH5CkArwrN0RUUSPSwwyB2w2rcA:4 a=J5lV41AAaZ8A:10 a=e1i35A98MB8A:10 a=m9bv2_CO_aQA:10 a=4rq7TwIXcRUA:10 a=Y6qChIQXU1wA:10 a=JBeEfTTJ0LsWHaDo:21 a=i7c1NtTG137m6omq:21 X-Mailman-Approved-At: Tue, 30 Jun 2009 20:31:32 -0700 Cc: URI , "www-tag@w3.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: , X-List-Received-Date: Fri, 26 Jun 2009 09:54:48 -0000 Hi Eran, Comments inline below. Eran Hammer-Lahav wrote: > LRDD [1] defines a way to link a descriptor (metadata, information about, etc.) to a resource. It keeps the document format of the descriptor out of scope, leaving it up to existing formats (XRDS, XRD, POWDER, Metalink, etc.) and new format to address. > > Most of these descriptor formats include an element which indicates what the document is about - the subject of the descriptor. XRD includes the element for this purpose with xs:anyURI as its type. I believe POWDER uses RDF's 'about' attribute in a similar way IIRC. No, not really. Like XRD and its template URIs, we have a simple, XML-based syntax that encodes what is described and who is describing it. POWDER also transports the RDF properties and values so that for a given input URI, you can extract the description (as triples). That's the job of the POWDER Processor. In other words, one simple document can be processed to extract information about individuals within a collection of resources. In RDF terms, the question is "I know the subject, can you give me any predicates and objects?" > > We have some use cases in which the subject of the descriptor does not have a URI available. Sympathy. We had that too and had to find a way to handle it. > > LRDD uses a well-known-location document (/host-meta, soon to be replaced with /.well-known/host-meta) to store information about the abstract host resource (the combination of domain name and port number, potentially also including protocol). Over the past few years, ad-hoc protocols have been abusing the root resource URI to mean something beyond just the root resource of a domain - basically as a placeholder for information about the entire domain or host. As you know, this is where we diverge philosophically . Well known locations go against the architecture of the web which is about URIs that link one thing to another and IMHO are a bad solution to anything but I'll refrain from opening that one again ;-) . As well as using the two link methods, we have the idea that a POWDER Processor can be a front end for a repository of descriptions that may not be linked from anywhere. > > The lack of URI for such concepts is preventing descriptor formats from being used here because there is no valid URI available to insert into the subject container. While no representation is expected for such abstract concepts, within the context of descriptors, being able to reference them is critical. I disagree. HTTP Link (and HTML link) cover it just fine. In my experience, it's not the lack of URI concepts that's the problem, it's the concept of a root resource that is the stumbling block. What is the root resource for http://www.facebook.com/philarcher1 ? Surely not the root of facebook.com. (the same applies, of course, to all those isp.com/~username/ websites). > > The use case at hand is using XRD as the document format for host-meta. Host-meta describes attributes of the host which by itself does not currently have a URI. We need to figure out what to put in the host-meta document's element which has direct impact on the trust profile and signature (but is outside the scope of this discussion). I don't think you can put it in a string of characters - it's software that has to match up a given URI with what's in the XRD document (or POWDER or whatever). It can be lightweight software, but nevertheless, you need to have some idea of the structure of the resources/services you're describing encoded in some way and a method for reading that encoding in the context of a specific request. > > So far I could only come up with two options: > > 1. Make a special case exception that when the subject is http://______/.well-known/host-meta, it is treated differently than any other URI in that it means the XRD is not about that URI (the host-meta document itself), but about the abstract host resource located at ______. Please no. An exception to the rules on how you treat a URI? No. > > 2. Define a new kind of URI that can be used for abstract entities such as "host" or "domain", but which is not an http URI because that will bring us right back to #1. That's more doable, yes, but I still don't think it's necessary. > > I would like to ask for feedback on the idea of proposing a new URI scheme or a new URN namespace for this purpose, something like 'abstract'. > It will look something like this (please focus on the idea, not the syntax of the examples): > > urn:abstract:domain:example.com > urn:abstract:host:example.com:8080 > urn:abstract:origin:example.com:8080:http > > or > > abstract://example.com/domain > abstract://example.com:8080/host > abstract://example.com:8080:http/origin Would your putative scheme include subdomains? In other words, if I have abstract://example.com/domain does that also cover everything on www.example.com ? And how flexible can it be? How would I say 'anything on example.com that ends with .jpg' ? Or that has a path containing 'foo' and 'bar' ? The working group I'm about to refer to has moved on now but a couple of years ago it defined a method of describing domains with the use case of cross-domain access control [1] which we used wholesale in the POWDER Grouping spec [2]. In short, abstract://example.com/domain DOES include all subdomains but you can also say abstract://*.example.com/domain which is all subdomains of example.com but not example.com itself. When POWDER started we thought that the resource grouping issue would be the biggest challenge which is why we tackled it first. Actually, the Proposed Rec document is the least changed of any of the specs since it was first published. We use set theory to under pin the whole thing and we're able to show that it can express any resource group, no matter how complex [3]. [1] http://www.w3.org/TR/2007/WD-access-control-20071001/#access0 [2] http://www.w3.org/TR/2009/PR-powder-grouping-20090604/#wild [3] http://www.w3.org/TR/2009/PR-powder-grouping-20090604/#conj-disj > > Any comments, feedback, or concerns would be greatly appreciated. Dunno if this helps any. Phil. > > [1] http://tools.ietf.org/html/draft-hammer-discovery > > > -- Phil Archer http://philarcher.org/ i-sieve technologies | W3C Mobile Web Initiative Beyond Impressions | www.w3.org/Mobile From phayes@ihmc.us Fri Jun 26 08:47:53 2009 Return-Path: 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 D69383A6AC0 for ; Fri, 26 Jun 2009 08:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=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 5l0-S1xGG0co for ; Fri, 26 Jun 2009 08:47:53 -0700 (PDT) Received: from comet.ihmc.us (comet.ihmc.us [72.236.182.20]) by core3.amsl.com (Postfix) with ESMTP id A2C1A3A6B78 for ; Fri, 26 Jun 2009 08:47:52 -0700 (PDT) Received: from [10.100.0.69] ([10.100.0.69]) (authenticated user phayes@ihmc.us) by comet.ihmc.us (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Fri, 26 Jun 2009 10:46:48 -0500 Message-Id: <66FB7DD9-7D0B-4877-ACBE-1618507CBFDA@ihmc.us> From: Pat Hayes To: Eran Hammer-Lahav In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723437833981DC@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: URI for abstract concepts (domain, host, origin, site, etc.) Date: Fri, 26 Jun 2009 10:46:47 -0500 References: <90C41DD21FB7C64BB94121FBBC2E7234378339816C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4A43F382.5020600@w3.org> <90C41DD21FB7C64BB94121FBBC2E723437833981C0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4A4437DC.3090201@w3.org> <90C41DD21FB7C64BB94121FBBC2E723437833981DC@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-Mailer: Apple Mail (2.935.3) X-Mailman-Approved-At: Tue, 30 Jun 2009 20:31:33 -0700 Cc: URI , Dan Connolly , "www-tag@w3.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: , X-List-Received-Date: Fri, 26 Jun 2009 15:58:11 -0000 On Jun 25, 2009, at 10:18 PM, Eran Hammer-Lahav wrote: >> From: Dan Connolly [mailto:connolly@w3.org] >> Sent: Thursday, June 25, 2009 7:52 PM > >>> How would a client know that this URI isn't for an actual HTTP >> resource without creating "well-known-location" URIs (option #1 in my >> original email)? >> >> It _is_ for an actual HTTP resource; i.e. something >> described/discussed in a document you can get by HTTP. Since >> documents can describe/discuss anything, they can describe/discuss >> things like origins and such. RDF is particularly suited >> for this purpose, but I can imagine other media types >> might work too... text/html with RDFa is pretty hip >> these days. > > In my case, the "resource" is the concept of a host, which is the > combination of a domain name, port number, and protocol used on that > port. I want to be able to describe this host by saying, "this is > how you transform any HTTP URI that belongs to this host to the URI > of its metadata". There are plenty of ways to express this statement > but so far I don't have a good way to express the subject of this > statement - the host. To me this sounds like a clear use case for an RDF blank node. You want to refer to some (category of) thing that has no current naming convention, but which you can describe in terms of its properties. That is exactly what RDF bnodes were invented for. The relevant RDF graph fragment would look something like this, using triples notation for clarity: _:x rdf:type :HostClassName . _"x :hasDomainName ^^xsd:string . _:x :hasPortNumber ^^xsd:number . (Or maybe you want to keep it as a string) _:x :usesProtocol .... (Not sure how to express this, you might have to use a literal to encode the protocol name or some such, unless there is an ontology of protocols out there somewhere.) to which you then add whatever you want to say about it, with that same _:x as subject. If you (as many people do) dislike bnodes, than just invent a naming convention with URI references #ed onto a suitable URI you own: the use of # gives you freedom to use your own naming style, and bypasses the http-range-14 referential problems arising from the use of a bare URI. Pat Hayes > > Of course, I can come up with something like this: > > http://abstract.example.net/host/example.com:80:http > > And simply include in the protocol that the http://abstract.example.net/host/ > prefix is a special case exception. But while such solutions (a URI > version of a well-known location) might be acceptable for HTTP > servers due to the complexity and cost of deploying changes to the > infrastructure (such as a new HTTP method), they are less acceptable > for URIs which can be easily extended with nothing more than a > couple pages of spec... > > It is almost as easy to register a new URI scheme or URN namespace > as it is for me to buy and maintain a new domain name. But I think > in this case, the reserved domain name is a lot more offensive to > web architecture than a new URI scheme or some other URI-based > solution. > > I am also happy to make this as specific as needed for my super > special use case and mint a new host: URI scheme. > > EHL > > > ------------------------------------------------------------ IHMC (850)434 8903 or (650)494 3973 40 South Alcaniz St. (850)202 4416 office Pensacola (850)202 4440 fax FL 32502 (850)291 0667 mobile phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes From phayes@ihmc.us Fri Jun 26 09:17:16 2009 Return-Path: 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 8ED603A6AE0 for ; Fri, 26 Jun 2009 09:17:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.016 X-Spam-Level: X-Spam-Status: No, score=-2.016 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599, J_CHICKENPOX_34=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 NbDF7MdmvBOg for ; Fri, 26 Jun 2009 09:17:15 -0700 (PDT) Received: from comet.ihmc.us (comet.ihmc.us [72.236.182.20]) by core3.amsl.com (Postfix) with ESMTP id 22C5C3A6882 for ; Fri, 26 Jun 2009 09:17:15 -0700 (PDT) Received: from [10.100.0.69] ([10.100.0.69]) (authenticated user phayes@ihmc.us) by comet.ihmc.us (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Fri, 26 Jun 2009 11:16:42 -0500 Message-Id: <91A2EB7E-63BE-42EA-A7E6-B02FFF726C6A@ihmc.us> From: Pat Hayes To: Eran Hammer-Lahav In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343783398212@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: URI for abstract concepts (domain, host, origin, site, etc.) Date: Fri, 26 Jun 2009 11:16:42 -0500 References: <90C41DD21FB7C64BB94121FBBC2E7234378339816C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4A43F382.5020600@w3.org> <90C41DD21FB7C64BB94121FBBC2E723437833981C0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4A4437DC.3090201@w3.org> <90C41DD21FB7C64BB94121FBBC2E723437833981DC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <66FB7DD9-7D0B-4877-ACBE-1618507CBFDA@ihmc.us> <90C41DD21FB7C64BB94121FBBC2E72343783398212@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-Mailer: Apple Mail (2.935.3) X-Mailman-Approved-At: Tue, 30 Jun 2009 20:31:33 -0700 Cc: URI , Dan Connolly , "www-tag@w3.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: , X-List-Received-Date: Fri, 26 Jun 2009 16:17:16 -0000 On Jun 26, 2009, at 11:03 AM, Eran Hammer-Lahav wrote: > It still needs to fit into an element that can only accept a URI. > If I end up using a URI I own and put the actual host information in > the fragment as suggested, I end up with exactly the kind of > solution I am trying to avoid which is making exceptions and > defining well-known HTTP URIs that are treated differently. They aren't being treated differently. The normal syntax for naming something in RDF is a URI reference with a fragid attached. The use of a fragID cancels any assumptions that the URIreference denotes something connected with the HTTP protocol. This is how RDF manages to refer to galaxies, chemical elements, people, etc.. Of course the bare root URI connects to (and likely refers to) an http-located information resource, but that need not interfere with the referents of the URI references constructed from it. Pat > > EHL > >> -----Original Message----- >> From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] On >> Behalf >> Of Pat Hayes >> Sent: Friday, June 26, 2009 8:47 AM >> To: Eran Hammer-Lahav >> Cc: Dan Connolly; apps-discuss@ietf.org; www-tag@w3.org; URI >> Subject: Re: URI for abstract concepts (domain, host, origin, site, >> etc.) >> >> >> On Jun 25, 2009, at 10:18 PM, Eran Hammer-Lahav wrote: >> >>>> From: Dan Connolly [mailto:connolly@w3.org] >>>> Sent: Thursday, June 25, 2009 7:52 PM >>> >>>>> How would a client know that this URI isn't for an actual HTTP >>>> resource without creating "well-known-location" URIs (option #1 in >> my >>>> original email)? >>>> >>>> It _is_ for an actual HTTP resource; i.e. something >>>> described/discussed in a document you can get by HTTP. Since >>>> documents can describe/discuss anything, they can describe/discuss >>>> things like origins and such. RDF is particularly suited >>>> for this purpose, but I can imagine other media types >>>> might work too... text/html with RDFa is pretty hip >>>> these days. >>> >>> In my case, the "resource" is the concept of a host, which is the >>> combination of a domain name, port number, and protocol used on that >>> port. I want to be able to describe this host by saying, "this is >>> how you transform any HTTP URI that belongs to this host to the URI >>> of its metadata". There are plenty of ways to express this statement >>> but so far I don't have a good way to express the subject of this >>> statement - the host. >> >> To me this sounds like a clear use case for an RDF blank node. You >> want to refer to some (category of) thing that has no current naming >> convention, but which you can describe in terms of its properties. >> That is exactly what RDF bnodes were invented for. The relevant RDF >> graph fragment would look something like this, using triples notation >> for clarity: >> >> _:x rdf:type :HostClassName . >> _"x :hasDomainName ^^xsd:string . >> _:x :hasPortNumber ^^xsd:number . (Or maybe you want to >> keep it as a string) >> _:x :usesProtocol .... (Not sure how to express this, you might have >> to use a literal to encode the protocol name or some such, unless >> there is an ontology of protocols out there somewhere.) >> >> to which you then add whatever you want to say about it, with that >> same _:x as subject. >> >> If you (as many people do) dislike bnodes, than just invent a naming >> convention with URI references #ed onto a suitable URI you own: the >> use of # gives you freedom to use your own naming style, and bypasses >> the http-range-14 referential problems arising from the use of a bare >> URI. >> >> Pat Hayes >> >>> >>> Of course, I can come up with something like this: >>> >>> http://abstract.example.net/host/example.com:80:http >>> >>> And simply include in the protocol that the >> http://abstract.example.net/host/ >>> prefix is a special case exception. But while such solutions (a URI >>> version of a well-known location) might be acceptable for HTTP >>> servers due to the complexity and cost of deploying changes to the >>> infrastructure (such as a new HTTP method), they are less acceptable >>> for URIs which can be easily extended with nothing more than a >>> couple pages of spec... >>> >>> It is almost as easy to register a new URI scheme or URN namespace >>> as it is for me to buy and maintain a new domain name. But I think >>> in this case, the reserved domain name is a lot more offensive to >>> web architecture than a new URI scheme or some other URI-based >>> solution. >>> >>> I am also happy to make this as specific as needed for my super >>> special use case and mint a new host: URI scheme. >>> >>> EHL >>> >>> >>> >> >> ------------------------------------------------------------ >> IHMC (850)434 8903 or (650)494 >> 3973 >> 40 South Alcaniz St. (850)202 4416 office >> Pensacola (850)202 4440 fax >> FL 32502 (850)291 0667 mobile >> phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes >> >> >> >> >> > > > ------------------------------------------------------------ IHMC (850)434 8903 or (650)494 3973 40 South Alcaniz St. (850)202 4416 office Pensacola (850)202 4440 fax FL 32502 (850)291 0667 mobile phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes From danbrickley@gmail.com Fri Jun 26 10:29:14 2009 Return-Path: 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 88DD03A6A2E for ; Fri, 26 Jun 2009 10:29:14 -0700 (PDT) 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=[AWL=0.000, 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 wZaITwFgYw0X for ; Fri, 26 Jun 2009 10:29:13 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id ED18C3A6932 for ; Fri, 26 Jun 2009 10:28:53 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id d26so232919eyd.31 for ; Fri, 26 Jun 2009 10:27:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=pGZPrU8y1wpVQ00N+l71EltdUeQ37d2+p41VoGDGxnc=; b=kZAa/2timyl2l2sQM/AOxih+U6dpiH78I8c6XhcCI7GsNZQEaqx4YRZtX7NpFjYOi3 5OMgLNyCd0HL+bwnSGrBFp/yQxX0u7gUX8Q7AdXINamAiT6FsjvVflOmzuzL5WtZk6Z8 N4WyeTvd1xQrsEhKPSZuvtroIl7Ga2R3oU7xY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=NhdTiHrTojjVl/ATuJtkkvpn3IwEuhX0q45iUVFXuaCpuKKX3wAtRQQO6eP7GevGoW FkpCoJnAn1AfgsbJlfEPZ+sBk/qV08qsq9EeBdACM6Zg27YLf/RDKekvYGXofRQ/clMw 3ta5vpmIcypBly8RTIpPCfxOxRXLRRkU7EMCo= Received: by 10.210.138.7 with SMTP id l7mr653664ebd.76.1246037248642; Fri, 26 Jun 2009 10:27:28 -0700 (PDT) Received: from BlackBook.local (s5590d015.adsl.wanadoo.nl [85.144.208.21]) by mx.google.com with ESMTPS id 5sm253829eyh.10.2009.06.26.10.27.27 (version=SSLv3 cipher=RC4-MD5); Fri, 26 Jun 2009 10:27:28 -0700 (PDT) Sender: Dan Brickley Message-ID: <4A4504FE.3050108@danbri.org> Date: Fri, 26 Jun 2009 19:27:26 +0200 From: Dan Brickley User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090223 Thunderbird/3.0b2 MIME-Version: 1.0 To: Larry Masinter Subject: Re: URI for abstract concepts (domain, host, origin, site, etc.) References: <90C41DD21FB7C64BB94121FBBC2E7234378339816C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4A43F382.5020600@w3.org> <90C41DD21FB7C64BB94121FBBC2E723437833981C0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4A4437DC.3090201@w3.org> <90C41DD21FB7C64BB94121FBBC2E723437833981DC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <66FB7DD9-7D0B-4877-ACBE-1618507CBFDA@ihmc.us> <90C41DD21FB7C64BB94121FBBC2E72343783398212@P3PW5EX1MB01.EX1.SECURESERVER.NET> <91A2EB7E-63BE-42EA-A7E6-B02FFF726C6A@ihmc.us> <005801c9f67e$c28702f0$479508d0$@org> In-Reply-To: <005801c9f67e$c28702f0$479508d0$@org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 30 Jun 2009 20:31:33 -0700 Cc: 'Pat Hayes' , apps-discuss@ietf.org, 'URI' , 'Dan Connolly' , www-tag@w3.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: , X-List-Received-Date: Fri, 26 Jun 2009 17:29:14 -0000 On 26/6/09 18:54, Larry Masinter wrote: > # They aren't being treated differently. The normal syntax for naming > # something in RDF is a URI reference with a fragid attached. The use of > # a fragID cancels any assumptions that the URIreference denotes > something connected with the HTTP protocol. > > How does it do that? > > # This is how RDF manages to > # refer to galaxies, chemical elements, people, etc.. > > Sounds like this is only in the context of RDF. Yes and no. Here's the "Yes": the idea is that if content is served as application/rdf+xml then the meaning of #foo is delegated to the relevant spec (http://www.w3.org/2001/sw/RDFCore/mediatype-registration ? humm that's expired). The RDF mediatype doc says """Section 4.1 of the URI specification [6] notes that the semantics of a fragment identifier (part of a URI after a "#") is a property of the data resulting from a retrieval action, and that the format and interpretation of fragment identifiers is dependent on the media type of the retrieval result. However, in RDF, the thing identified by a URI with fragment identifier does not bear any particular relationship to the thing identified by the URI alone. This differs from some readings of the URI specification [6], so attention is recommended when creating new RDF terms which use fragment identifiers.""" Here the "No": A URI that points to an RDF document constructed in this fashion, is (according to those persuaded this story works) supposed to be a URI for whatever galaxy, chemical element, person etc. the RDF is structured to represent. In this way, http://danbri.org/foaf.rdf#danbri is a URI for me. Not just for RDF applications, but for any applications that care about the idea of URIs being URIs *for* things. The media-type registration that makes this so RDF-specific (RDF/XML-specific even) but the URI is supposed to be a URI for me, full stop, rather than "a URI for me, in RDF applications". At this point people normally bring up the possibility of clashes across content-negotiated representations served at the same URI. The usual answer offered by return is "if that hurts, don't do it". Dan From phayes@ihmc.us Fri Jun 26 14:03:23 2009 Return-Path: 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 60CCD3A6BA5 for ; Fri, 26 Jun 2009 14:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[AWL=0.288, 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 4mIrvv0Kak4N for ; Fri, 26 Jun 2009 14:03:22 -0700 (PDT) Received: from comet.ihmc.us (comet.ihmc.us [72.236.182.20]) by core3.amsl.com (Postfix) with ESMTP id 2924E3A6AAE for ; Fri, 26 Jun 2009 14:03:22 -0700 (PDT) Received: from [10.100.0.69] ([10.100.0.69]) (authenticated user phayes@ihmc.us) by comet.ihmc.us (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Fri, 26 Jun 2009 16:02:44 -0500 Message-Id: From: Pat Hayes To: "Larry Masinter" In-Reply-To: <005801c9f67e$c28702f0$479508d0$@org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: URI for abstract concepts (domain, host, origin, site, etc.) Date: Fri, 26 Jun 2009 16:02:44 -0500 References: <90C41DD21FB7C64BB94121FBBC2E7234378339816C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4A43F382.5020600@w3.org> <90C41DD21FB7C64BB94121FBBC2E723437833981C0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4A4437DC.3090201@w3.org> <90C41DD21FB7C64BB94121FBBC2E723437833981DC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <66FB7DD9-7D0B-4877-ACBE-1618507CBFDA@ihmc.us> <90C41DD21FB7C64BB94121FBBC2E72343783398212@P3PW5EX1MB01.EX1.SECURESERVER.NET> <91A2EB7E-63BE-42EA-A7E6-B02FFF726C6A@ihmc.us> <005801c9f67e$c28702f0$479508d0$@org> X-Mailer: Apple Mail (2.935.3) X-Mailman-Approved-At: Tue, 30 Jun 2009 20:31:33 -0700 Cc: www-tag@w3.org, 'URI' , 'Dan Connolly' , 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: , X-List-Received-Date: Fri, 26 Jun 2009 21:03:23 -0000 On Jun 26, 2009, at 11:54 AM, Larry Masinter wrote: > # They aren't being treated differently. The normal syntax for naming > # something in RDF is a URI reference with a fragid attached. The > use of > # a fragID cancels any assumptions that the URIreference denotes > something connected with the HTTP protocol. > > How does it do that? http-range-14, as I understand it. > > # This is how RDF manages to > # refer to galaxies, chemical elements, people, etc.. > > Sounds like this is only in the context of RDF. Well, true, fragids have a different meaning in HTML. But this rule seems to work smoothly throughout the SWeb formalisms, which are all the referential uses of URIrefs on the Web. Pat > > Larry > -- > http://larry.masinter.net > > > > > ------------------------------------------------------------ IHMC (850)434 8903 or (650)494 3973 40 South Alcaniz St. (850)202 4416 office Pensacola (850)202 4440 fax FL 32502 (850)291 0667 mobile phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes From dret@berkeley.edu Sat Jun 27 07:25:55 2009 Return-Path: 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 9CF843A6C09 for ; Sat, 27 Jun 2009 07:25:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.516 X-Spam-Level: X-Spam-Status: No, score=-5.516 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, URIBL_RHS_DOB=1.083] 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 I1xH4APA+gC9 for ; Sat, 27 Jun 2009 07:25:54 -0700 (PDT) Received: from smtp.ischool.berkeley.edu (bliss.ISchool.Berkeley.EDU [128.32.78.13]) by core3.amsl.com (Postfix) with ESMTP id 994BD3A6BFA for ; Sat, 27 Jun 2009 07:25:54 -0700 (PDT) Received: from [192.168.11.153] (18.Red-88-2-185.staticIP.rima-tde.net [88.2.185.18]) (authenticated bits=0) by smtp.ischool.berkeley.edu (8.13.1/8.13.1) with ESMTP id n5REQ2ji025427 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 27 Jun 2009 07:26:04 -0700 Message-ID: <4A462BF3.9030701@berkeley.edu> Date: Sat, 27 Jun 2009 16:25:55 +0200 From: Erik Wilde User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Xiaoshu Wang Subject: Re: URI for abstract concepts (domain, host, origin, site, etc.) References: <90C41DD21FB7C64BB94121FBBC2E7234378339816C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4A43F382.5020600@w3.org> <90C41DD21FB7C64BB94121FBBC2E723437833981C0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4A4437DC.3090201@w3.org> <90C41DD21FB7C64BB94121FBBC2E723437833981DC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <66FB7DD9-7D0B-4877-ACBE-1618507CBFDA@ihmc.us> <90C41DD21FB7C64BB94121FBBC2E72343783398212@P3PW5EX1MB01.EX1.SECURESERVER.NET> <91A2EB7E-63BE-42EA-A7E6-B02FFF726C6A@ihmc.us> <005801c9f67e$c28702f0$479508d0$@org> <4A4504FE.3050108@danbri.org> <4A451511.2060400@musc.edu> In-Reply-To: <4A451511.2060400@musc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 128.32.78.13 X-Mailman-Approved-At: Tue, 30 Jun 2009 20:31:32 -0700 Cc: 'Pat Hayes' , "apps-discuss@ietf.org" , Larry Masinter , 'URI' , 'Dan Connolly' , Dan Brickley , "www-tag@w3.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: , X-List-Received-Date: Sat, 27 Jun 2009 14:25:55 -0000 hello. Xiaoshu Wang wrote: > There should not be. I have trying this many times. A URI, fragmented > or not, denotes one thing and its returned representations another. The > former is the content of the later. The remedy is to define a URI > syntax for representation. > A syntax that I have proposed is to insert a (mime-type) after the # sign. > Thus, > "http://danbri.org/foaf.rdf#danbri" denotes a person. > "http://danbri.org/foaf.rdf#(application/rdf+xml)danbri" denotes an RDF > node. > "http://danbri.org/foaf.rdf#(application/xhtml+xml)danbri" denotes an > HTML element ided "danbri interesting. would that be specific for http-identified resources? if not, how would that be supposed to work with URI schemes that do not share HTTP's capabilities for transferring content metadata, and performing content negotiation? a simple example might be FTP, which is similar in nature to HTTP (access to hierarchically organized resources) but has no concept of media types. another thing i am wondering about: aren't fragment identifiers as they are currently defined client-side only and specific to the media type anyway? that might indicate you are talking not about extending the URI syntax, but that of HTTP URI fragment identifiers? there were other approaches of doing this (with other goals), one of the issues was how to create some framework for fragment identifiers that would be uniformly applied to all fragment identifier syntaxes. that one never got anywhere, and the window of opportunity is probably closed by now. but there the idea was that instead of labeling fragments with the media type to which they should be applied (which seems to be what you're suggesting), they should follow some base syntax, and thus could be designed to be less brittle across media types. HTTP's idea of content negotiation (and thus dynamic media type assignment at access time) and URI fragment identifiers and their media type specificity always was one of the areas where web architecture certainly could need a bit of improvment. cheers, erik wilde tel:+1-510-6432253 - fax:+1-510-6425814 dret@berkeley.edu - http://dret.net/netdret UC Berkeley - School of Information (ISchool) From dret@berkeley.edu Sat Jun 27 14:10:23 2009 Return-Path: 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 8E7A53A6ADC for ; Sat, 27 Jun 2009 14:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.058 X-Spam-Level: X-Spam-Status: No, score=-6.058 tagged_above=-999 required=5 tests=[AWL=0.542, 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 PuZonVvx15QG for ; Sat, 27 Jun 2009 14:10:22 -0700 (PDT) Received: from smtp.ischool.berkeley.edu (bliss.ISchool.Berkeley.EDU [128.32.78.13]) by core3.amsl.com (Postfix) with ESMTP id ACDD23A68CF for ; Sat, 27 Jun 2009 14:10:22 -0700 (PDT) Received: from [192.168.11.153] (18.Red-88-2-185.staticIP.rima-tde.net [88.2.185.18]) (authenticated bits=0) by smtp.ischool.berkeley.edu (8.13.1/8.13.1) with ESMTP id n5RLA69b017473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 27 Jun 2009 14:10:24 -0700 Message-ID: <4A468AA7.4050608@berkeley.edu> Date: Sat, 27 Jun 2009 23:09:59 +0200 From: Erik Wilde User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Xiaoshu Wang Subject: Re: URI for abstract concepts (domain, host, origin, site, etc.) References: <90C41DD21FB7C64BB94121FBBC2E7234378339816C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4A43F382.5020600@w3.org> <90C41DD21FB7C64BB94121FBBC2E723437833981C0@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4A4437DC.3090201@w3.org> <90C41DD21FB7C64BB94121FBBC2E723437833981DC@P3PW5EX1MB01.EX1.SECURESERVER.NET> <66FB7DD9-7D0B-4877-ACBE-1618507CBFDA@ihmc.us> <90C41DD21FB7C64BB94121FBBC2E72343783398212@P3PW5EX1MB01.EX1.SECURESERVER.NET> <91A2EB7E-63BE-42EA-A7E6-B02FFF726C6A@ihmc.us> <005801c9f67e$c28702f0$479508d0$@org> <4A4504FE.3050108@danbri.org> <4A451511.2060400@musc.edu> <4A462BF3.9030701@berkeley.edu> <4A46896A.8050107@musc.edu> In-Reply-To: <4A46896A.8050107@musc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 128.32.78.13 X-Mailman-Approved-At: Tue, 30 Jun 2009 20:31:33 -0700 Cc: 'Pat Hayes' , "apps-discuss@ietf.org" , Larry Masinter , 'URI' , 'Dan Connolly' , Dan Brickley , "www-tag@w3.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: , X-List-Received-Date: Sat, 27 Jun 2009 21:10:23 -0000 hello. > I don't think a URI scheme has to do anything with transportation > protocol. the URI scheme specifies the protocol that has to be used the resource. how can that have nothing to do with the protocol? > No matter what URI you use, after de-reference, you get a > *representation*, which is a different thing from the *resource* that > the URI denotes. And a representation must have a content type, > regardless how you retrieved it. that's HTTP and HTTPS, but probably not many other protocols. if you use mailto: or tel: or fax: or sms:, then there are other modes of interaction with the identified resource, and for those interactions there is no concept of a media type. and even for ftp:, there is no media type info; you can guess, but there is no protocol mechanism that supports it. so it really seems to me you're focusing on HTTP URIs which is fine; i just wanted to find out. cheers, erik wilde tel:+1-510-6432253 - fax:+1-510-6425814 dret@berkeley.edu - http://dret.net/netdret UC Berkeley - School of Information (ISchool) From ashok.malhotra@oracle.com Sat Jun 27 18:07:43 2009 Return-Path: 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 2794F3A6A8D for ; Sat, 27 Jun 2009 18:07:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.916 X-Spam-Level: X-Spam-Status: No, score=-4.916 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_26=0.6, RCVD_IN_DNSWL_MED=-4, URIBL_RHS_DOB=1.083] 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 Cm15WIa9jUC1 for ; Sat, 27 Jun 2009 18:07:42 -0700 (PDT) Received: from acsinet11.oracle.com (acsinet11.oracle.com [141.146.126.233]) by core3.amsl.com (Postfix) with ESMTP id 311453A6A7F for ; Sat, 27 Jun 2009 18:07:42 -0700 (PDT) Received: from rgminet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by acsinet11.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n5S197ph022096 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 28 Jun 2009 01:09:09 GMT Received: from abhmt006.oracle.com (abhmt006.oracle.com [141.146.116.15]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n5S182nI012849; Sun, 28 Jun 2009 01:08:03 GMT Received: from [192.168.1.2] (/173.68.50.142) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 27 Jun 2009 18:07:55 -0700 Message-ID: <4A46C264.6090700@oracle.com> Date: Sat, 27 Jun 2009 18:07:48 -0700 From: ashok malhotra Organization: Oracle User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Eran Hammer-Lahav Subject: Re: URI for abstract concepts (domain, host, origin, site, etc.) References: <90C41DD21FB7C64BB94121FBBC2E7234378339816C@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E7234378339816C@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: abhmt006.oracle.com [141.146.116.15] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A010209.4A46C26C.00F7:SCFSTAT5015188,ss=1,fgs=0 X-Mailman-Approved-At: Tue, 30 Jun 2009 20:31:33 -0700 Cc: URI , "www-tag@w3.org" , "apps-discuss@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ashok.malhotra@oracle.com List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 01:12:09 -0000 Hi Eran: Trying to understand your proposal. By 'abstract' do you mean URIs for which a representation cannot be retrieved? So, perhaps, a chair? My assumption was that for such resources you want to retrieve the metadata. To do that you do a GET which returns a 'Not Found' as well as a Link Header. Of course, if you know syntactically that the resource does not have a representation you can save one access and go directly for the metadata. Is that where you are going? All the best, Ashok Eran Hammer-Lahav wrote: > LRDD [1] defines a way to link a descriptor (metadata, information about, etc.) to a resource. It keeps the document format of the descriptor out of scope, leaving it up to existing formats (XRDS, XRD, POWDER, Metalink, etc.) and new format to address. > > Most of these descriptor formats include an element which indicates what the document is about - the subject of the descriptor. XRD includes the element for this purpose with xs:anyURI as its type. I believe POWDER uses RDF's 'about' attribute in a similar way IIRC. > > We have some use cases in which the subject of the descriptor does not have a URI available. > > LRDD uses a well-known-location document (/host-meta, soon to be replaced with /.well-known/host-meta) to store information about the abstract host resource (the combination of domain name and port number, potentially also including protocol). Over the past few years, ad-hoc protocols have been abusing the root resource URI to mean something beyond just the root resource of a domain - basically as a placeholder for information about the entire domain or host. > > The lack of URI for such concepts is preventing descriptor formats from being used here because there is no valid URI available to insert into the subject container. While no representation is expected for such abstract concepts, within the context of descriptors, being able to reference them is critical. > > The use case at hand is using XRD as the document format for host-meta. Host-meta describes attributes of the host which by itself does not currently have a URI. We need to figure out what to put in the host-meta document's element which has direct impact on the trust profile and signature (but is outside the scope of this discussion). > > So far I could only come up with two options: > > 1. Make a special case exception that when the subject is http://______/.well-known/host-meta, it is treated differently than any other URI in that it means the XRD is not about that URI (the host-meta document itself), but about the abstract host resource located at ______. > > 2. Define a new kind of URI that can be used for abstract entities such as "host" or "domain", but which is not an http URI because that will bring us right back to #1. > > I would like to ask for feedback on the idea of proposing a new URI scheme or a new URN namespace for this purpose, something like 'abstract'. > It will look something like this (please focus on the idea, not the syntax of the examples): > > urn:abstract:domain:example.com > urn:abstract:host:example.com:8080 > urn:abstract:origin:example.com:8080:http > > or > > abstract://example.com/domain > abstract://example.com:8080/host > abstract://example.com:8080:http/origin > > Any comments, feedback, or concerns would be greatly appreciated. > > EHL > > [1] http://tools.ietf.org/html/draft-hammer-discovery > > > > From ashok.malhotra@oracle.com Sun Jun 28 10:30:09 2009 Return-Path: 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 152563A6804 for ; Sun, 28 Jun 2009 10:30:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.623 X-Spam-Level: X-Spam-Status: No, score=-5.623 tagged_above=-999 required=5 tests=[AWL=0.976, 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 AKkVChcakPKa for ; Sun, 28 Jun 2009 10:30:08 -0700 (PDT) Received: from acsinet12.oracle.com (acsinet12.oracle.com [141.146.126.234]) by core3.amsl.com (Postfix) with ESMTP id 3827C3A6960 for ; Sun, 28 Jun 2009 10:30:08 -0700 (PDT) Received: from rgminet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by acsinet12.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n5SHUHCE000856 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 28 Jun 2009 17:30:19 GMT Received: from abhmt006.oracle.com (abhmt006.oracle.com [141.146.116.15]) by rgminet15.oracle.com (Switch-3.3.1/Switch-3.3.1) with ESMTP id n5SHUSpS028111; Sun, 28 Jun 2009 17:30:28 GMT Received: from [192.168.1.6] (/173.68.50.142) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 28 Jun 2009 10:30:20 -0700 Message-ID: <4A47A8A5.3090905@oracle.com> Date: Sun, 28 Jun 2009 10:30:13 -0700 From: ashok malhotra Organization: Oracle User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Jonathan Rees Subject: Re: URI for abstract concepts (domain, host, origin, site, etc.) References: <90C41DD21FB7C64BB94121FBBC2E7234378339816C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4A46C264.6090700@oracle.com> <760bcb2a0906280942jcb99a26y76e99b3f0d8783be@mail.gmail.com> In-Reply-To: <760bcb2a0906280942jcb99a26y76e99b3f0d8783be@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: abhmt006.oracle.com [141.146.116.15] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4A47A8AD.0184:SCFSTAT5015188,ss=1,fgs=0 X-Mailman-Approved-At: Tue, 30 Jun 2009 20:31:33 -0700 Cc: "www-tag@w3.org" , URI , "apps-discuss@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ashok.malhotra@oracle.com List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2009 17:30:09 -0000 See inline All the best, Ashok Jonathan Rees wrote: > On Sat, Jun 27, 2009 at 9:07 PM, ashok > malhotra wrote: > >> Hi Eran: >> Trying to understand your proposal. >> By 'abstract' do you mean URIs for which a representation cannot be >> retrieved? >> So, perhaps, a chair? >> My assumption was that for such resources you want to retrieve the metadata. >> > > Quibble: In the case of a chair, you can't get metadata, since a chair > isn't data. > http://www.google.com/search?q=define:metadata > [AM] Picky, picky :-) > This is why it's nice that Eran calls the description resource a > "description resource" instead of a "metadata resource". LRDD is a > compatible alternative to linked-data 303 nose-following, one that > (like 303, as David Booth has pointed out) behaves uniformly without > caring whether the resource is "data"-like or not - it means you don't > have to ask or answer that question. I advocate using his terminology. > [AM] Yes, description resource is better, > Perhaps an alternative to a new URI scheme for hosts would be loop > detection inside of LRDD? I think that's close to what you're saying. > [AM] I wrote the note mainly to make sure I understood Eran's usecase, Your suggestion has merit. Let's see what he says. > -Jonathan > > From phil@philarcher.org Mon Jun 29 01:30:11 2009 Return-Path: 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 A3D4528C18E for ; Mon, 29 Jun 2009 01:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.866 X-Spam-Level: X-Spam-Status: No, score=-4.866 tagged_above=-999 required=5 tests=[AWL=-2.867, BAYES_00=-2.599, J_CHICKENPOX_26=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 YIyEX0lsdI2P for ; Mon, 29 Jun 2009 01:30:10 -0700 (PDT) Received: from mtaout01-winn.ispmail.ntl.com (mtaout01-winn.ispmail.ntl.com [81.103.221.47]) by core3.amsl.com (Postfix) with ESMTP id 032653A69D0 for ; Mon, 29 Jun 2009 01:30:09 -0700 (PDT) Received: from aamtaout03-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout01-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20090629083024.CJPX6742.mtaout01-winn.ispmail.ntl.com@aamtaout03-winn.ispmail.ntl.com>; Mon, 29 Jun 2009 09:30:24 +0100 Received: from [192.168.1.2] (really [86.3.206.22]) by aamtaout03-winn.ispmail.ntl.com (InterMail vG.2.02.00.01 201-2161-120-102-20060912) with ESMTP id <20090629083023.LIAG2093.aamtaout03-winn.ispmail.ntl.com@[192.168.1.2]>; Mon, 29 Jun 2009 09:30:23 +0100 Message-ID: <4A487B98.2040006@philarcher.org> Date: Mon, 29 Jun 2009 09:30:16 +0100 From: Phil Archer User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Eran Hammer-Lahav Subject: Re: URI for abstract concepts (domain, host, origin, site, etc.) References: <90C41DD21FB7C64BB94121FBBC2E7234378339816C@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4A46C264.6090700@oracle.com> <90C41DD21FB7C64BB94121FBBC2E723437833982F0@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723437833982F0@P3PW5EX1MB01.EX1.SECURESERVER.NET> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Cloudmark-Analysis: v=1.0 c=1 a=3ZAkCsyKlbEA:10 a=A1X0JdhQAAAA:8 a=QIhr-27iAAAA:8 a=yPCof4ZbAAAA:8 a=48vgC7mUAAAA:8 a=SSmOFEACAAAA:8 a=RFp60smDAAAA:8 a=WgIs0K7j-UalF21SHcwA:9 a=BMDm7nbPNgTe5kSF6swA:7 a=eD-kijdEWg3Q_AitALe0jky8EmwA:4 a=e1i35A98MB8A:10 a=4rq7TwIXcRUA:10 a=Y6qChIQXU1wA:10 a=7DSvI1NPTFQA:10 a=lZB815dzVvQA:10 a=69XIa8IdTDMA:10 a=VEf-SftvEmCy9bEU:21 a=NbBdESlT3TAGIigB:21 X-Mailman-Approved-At: Tue, 30 Jun 2009 20:31:32 -0700 Cc: "ashok.malhotra@oracle.com" , URI , "www-tag@w3.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: , X-List-Received-Date: Mon, 29 Jun 2009 08:30:12 -0000 Eran Hammer-Lahav wrote: > Let me try explaining my use case again, this time without any overloaded terminology or proposed solutions. > > --- > > XRD is a document format for describing resources. It looks like this: > > > http://example.com > http://example.org/type/blog > > author > http://example.com/author > > > > Without getting too much into XRD, this short descriptor describes the resource identified by 'http://example.com'. It includes one type indicator (a made up example meant to mean this resource is a blog), and one link to the author's page. > > --- > > I want to use this document format to describe rules that apply to all resources which belong to an HTTP host (as defined by 2616: a domain/address and port combination). The problem is, requires a URI and currently there is no way to identify this set of resources (http://domain:port/*) as a valid URI. As I see it, the problem is that you require type to be a URI. Why? Why not encode your rules instead? POWDER does this in a way that could, if you so chose, be applied pretty well directly in XRD so that it would look like: http example.com http://example.org/type/blog author http://example.com/author The approach POWDER takes is to define constraints on URIs. In this case, we've constrained the host and the scheme. Any resource on any subdomain of example.com, on any port, is now in scope. You reduce the scope by adding in further constraints. You can also provide alternatives in white space separated lists so that, for example, if you wanted to allow http or https (but not other schemes) then you'd have: http https and so on. Your example shows just how similar XRD and POWDER are. They have different use cases and serve different audiences and I'm not, for a moment, suggesting that one subsumes the other, but for the record, your example could be written in POWDER as: http example.com This is a declaration by the author that s/he is the author of the blog which comprises the entirety of example.com. As you can see, it's done entirely in XML and can be processed as such. Semantic folk can also process this and extract RDF triples about individual URIs on the example.com host and if you run the transformation you can get an OWL ontology out of this too - but that's all optional. > > What I don't want to do is use an exception such as 'if the URI begins with X, treat it as a rule and not a valid URI'... Agreed, that would be awful. Cheers Phil. > >> -----Original Message----- >> From: ashok malhotra [mailto:ashok.malhotra@oracle.com] >> Sent: Saturday, June 27, 2009 6:08 PM >> To: Eran Hammer-Lahav >> Cc: apps-discuss@ietf.org; www-tag@w3.org; URI >> Subject: Re: URI for abstract concepts (domain, host, origin, site, >> etc.) >> >> Hi Eran: >> Trying to understand your proposal. >> By 'abstract' do you mean URIs for which a representation cannot be >> retrieved? >> So, perhaps, a chair? >> >> My assumption was that for such resources you want to retrieve the >> metadata. >> To do that you do a GET which returns a 'Not Found' as well as a Link >> Header. >> >> Of course, if you know syntactically that the resource does not have a >> representation >> you can save one access and go directly for the metadata. >> >> Is that where you are going? >> >> All the best, Ashok >> >> >> Eran Hammer-Lahav wrote: >>> LRDD [1] defines a way to link a descriptor (metadata, information >> about, etc.) to a resource. It keeps the document format of the >> descriptor out of scope, leaving it up to existing formats (XRDS, XRD, >> POWDER, Metalink, etc.) and new format to address. >>> Most of these descriptor formats include an element which indicates >> what the document is about - the subject of the descriptor. XRD >> includes the element for this purpose with xs:anyURI as its >> type. I believe POWDER uses RDF's 'about' attribute in a similar way >> IIRC. >>> We have some use cases in which the subject of the descriptor does >> not have a URI available. >>> LRDD uses a well-known-location document (/host-meta, soon to be >> replaced with /.well-known/host-meta) to store information about the >> abstract host resource (the combination of domain name and port number, >> potentially also including protocol). Over the past few years, ad-hoc >> protocols have been abusing the root resource URI to mean something >> beyond just the root resource of a domain - basically as a placeholder >> for information about the entire domain or host. >>> The lack of URI for such concepts is preventing descriptor formats >> from being used here because there is no valid URI available to insert >> into the subject container. While no representation is expected for >> such abstract concepts, within the context of descriptors, being able >> to reference them is critical. >>> The use case at hand is using XRD as the document format for host- >> meta. Host-meta describes attributes of the host which by itself does >> not currently have a URI. We need to figure out what to put in the >> host-meta document's element which has direct impact on the >> trust profile and signature (but is outside the scope of this >> discussion). >>> So far I could only come up with two options: >>> >>> 1. Make a special case exception that when the subject is >> http://______/.well-known/host-meta, it is treated differently than any >> other URI in that it means the XRD is not about that URI (the host-meta >> document itself), but about the abstract host resource located at >> ______. >>> 2. Define a new kind of URI that can be used for abstract entities >> such as "host" or "domain", but which is not an http URI because that >> will bring us right back to #1. >>> I would like to ask for feedback on the idea of proposing a new URI >> scheme or a new URN namespace for this purpose, something like >> 'abstract'. >>> It will look something like this (please focus on the idea, not the >> syntax of the examples): >>> urn:abstract:domain:example.com >>> urn:abstract:host:example.com:8080 >>> urn:abstract:origin:example.com:8080:http >>> >>> or >>> >>> abstract://example.com/domain >>> abstract://example.com:8080/host >>> abstract://example.com:8080:http/origin >>> >>> Any comments, feedback, or concerns would be greatly appreciated. >>> >>> EHL >>> >>> [1] http://tools.ietf.org/html/draft-hammer-discovery >>> >>> >>> >>> > > -- Phil Archer http://philarcher.org/ i-sieve technologies | W3C Mobile Web Initiative Beyond Impressions | www.w3.org/Mobile From mnot@mnot.net Tue Jun 30 21:23:42 2009 Return-Path: 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 5CB1F3A67B4 for ; Tue, 30 Jun 2009 21:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.167 X-Spam-Level: X-Spam-Status: No, score=-6.167 tagged_above=-999 required=5 tests=[AWL=-2.568, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 h1zzkGHYa-aU for ; Tue, 30 Jun 2009 21:23:41 -0700 (PDT) Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178]) by core3.amsl.com (Postfix) with ESMTP id 44A9A3A6ECC for ; Tue, 30 Jun 2009 21:23:41 -0700 (PDT) Received: from [192.168.1.6] (unknown [118.208.249.76]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id AA8AA23E4A3; Wed, 1 Jul 2009 00:23:50 -0400 (EDT) Message-Id: From: Mark Nottingham To: Sam Johnston In-Reply-To: <21606dcf0906300449y7f26e43cv729dd681e815e9cf@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Subject: Re: Clarifications on Web Linking with HTTP Date: Wed, 1 Jul 2009 14:23:47 +1000 References: <21606dcf0906142027y517d22c5i78398428126f5811@mail.gmail.com> <88710490-2E52-42A0-8E5E-B055AC31CF0F@mnot.net> <21606dcf0906300449y7f26e43cv729dd681e815e9cf@mail.gmail.com> X-Mailer: Apple Mail (2.935.3) Cc: 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: , X-List-Received-Date: Wed, 01 Jul 2009 04:23:42 -0000 type is in the BNF, just not the prose; will say something in the next draft. Thanks, On 30/06/2009, at 9:49 PM, Sam Johnston wrote: > On Tue, Jun 30, 2009 at 6:20 AM, Mark Nottingham > wrote: > Hi Sam, > > Thanks for getting back to me about this - your input is appreciated. > > On 15/06/2009, at 1:27 PM, Sam Johnston wrote: > > - First and foremost, in the absence of the LINK and UNLINK verbs > originally defined in RFC 2068[2] but specifically omitted from RFC > 2616[3], what is the preferred mechanism for manipulating these links > via HTTP? > > Undefined, but I imagine in a PUT/POST body does indeed make the > most sense. Using the Link header in a request doesn't have well- > defined semantics. > > I think it would be something that's worth defining, albeit perhaps > not in your current I-D at the 11th hour and after 6 revisions. It's > just not clear to me what (outside of dedicated HTTP verb(s)) makes > the most sense... I'm yet to come up with a reasonable way to do it > in-band. > > > - It seems useful to be able to (optionally) specify the type (as in > content type rather than relation type) of a given link, as is the > case for Atom. > > Not sure there's a question in there... > > Basically just observing that the "type" attribute is conspicuously > absent from your Link: header I-D and wondering whether that's > sensible (e.g. are there times when it makes sense to specify/ > advertise the type ala Atom - and I think there are - for example > when you're dropping the Atom wrapping for individual resources as > we're trying to do with OCCI). > > Sam > -- Mark Nottingham http://www.mnot.net/