From brian.e.carpenter@gmail.com Mon Aug 31 19:32: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 B789C3A6B00 for ; Mon, 31 Aug 2009 19:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.458 X-Spam-Level: X-Spam-Status: No, score=-2.458 tagged_above=-999 required=5 tests=[AWL=0.141, 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 RW8BzD8qNZCm for ; Mon, 31 Aug 2009 19:32:29 -0700 (PDT) Received: from mail-pz0-f200.google.com (mail-pz0-f200.google.com [209.85.222.200]) by core3.amsl.com (Postfix) with ESMTP id 311423A6C46 for ; Mon, 31 Aug 2009 19:32:13 -0700 (PDT) Received: by pzk38 with SMTP id 38so4462930pzk.5 for ; Mon, 31 Aug 2009 19:32:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=O0a5vu/CJQIoIfsJpWz6v5YPL162juqSiaTjmqqRoi0=; b=P/f3u8N74KECfh61HmBOkAdOeGvKEOghL7nlUH0v4CY2Qiu5yI5U+0c3A0OqPIjDgu zO4oGa7XbBRwq192knBpElhwavbu9N5IamJnlRwmU4FFnWyVymDohDmjc5yEDkdhm0cY nfPoMHSMgoMD7NhaYF2HHT1gRTteZRePNKPUA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; b=V5O4InRy4JG6/Vz9ooiGqZFxBM+8Bnofqn8R5c+Ji5Tt0yBQKoJ7XMa+wmuOC7srsY SCTQWy9Azhqdpw1QduT2926DWskqZufcSdkgoV8xXyVSY4gft687EX6BKdqR5Lx62Iky rlelkiOJYApFzJR5dOQ6Ho4Qisy/NQCZf3ugA= Received: by 10.114.9.3 with SMTP id 3mr3682534wai.1.1251772340276; Mon, 31 Aug 2009 19:32:20 -0700 (PDT) Received: from ?130.216.38.124? (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id k14sm720942waf.39.2009.08.31.19.32.18 (version=SSLv3 cipher=RC4-MD5); Mon, 31 Aug 2009 19:32:19 -0700 (PDT) Message-ID: <4A9C87B1.90608@gmail.com> Date: Tue, 01 Sep 2009 14:32:17 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: apps-discuss@ietf.org Subject: Referrals - discussion and possible BOF Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 02 Sep 2009 08:02:49 -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: Tue, 01 Sep 2009 02:32:29 -0000 Hi, Following the short discussion in the Stockholm BEHAVE meeting, there is a proposed (not yet approved) BOF for Hiroshima on the topic of a generic referral object. Please see http://www.cs.auckland.ac.nz/~brian/GROBJ-BOF.txt and if you want to discuss the topic, join the grobj@ietf.org mailing list. We want to attract Applications Area discussion. Brian Carpenter (not subscribed to apps-discuss) From lear@cisco.com Thu Sep 3 13:08:38 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 41ECF3A67DB for ; Thu, 3 Sep 2009 13:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.275 X-Spam-Level: X-Spam-Status: No, score=-10.275 tagged_above=-999 required=5 tests=[AWL=0.324, 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 oiOGVtFs8KJy for ; Thu, 3 Sep 2009 13:08:36 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 9DBE23A6862 for ; Thu, 3 Sep 2009 13:08:35 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An8AAEu+n0qQ/uCKe2dsb2JhbACBU5lrAQEWJAamfohBAZApBYQb X-IronPort-AV: E=Sophos;i="4.44,326,1249257600"; d="scan'208";a="48590881" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 03 Sep 2009 20:04:05 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n83K45dH010942 for ; Thu, 3 Sep 2009 22:04:05 +0200 Received: from adsl-247-4-fixip.tiscali.ch (dhcp-10-61-109-103.cisco.com [10.61.109.103]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n83K44oo028188 for ; Thu, 3 Sep 2009 20:04:05 GMT Message-ID: <4AA02132.8030207@cisco.com> Date: Thu, 03 Sep 2009 22:04:02 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 MIME-Version: 1.0 To: "apps-discuss@ietf.org" Subject: anyone with deep mysql knowledge? X-Enigmail-Version: 0.97a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=195; t=1252008245; x=1252872245; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20anyone=20with=20deep=20mysql=20knowledge? |Sender:=20; bh=dBEeSGBKboHQBhDuvw9l5dSUuGl7gajOhhUv5pCr9AM=; b=NdaOdiJvOWgN4uHUuDoHpu8a5qjgooYaz+FvblEYd3kGAtFeGZg9XjX6r1 oICHBD5LOmyqSZvzRsBccvDIAz1LrqiY6WRwF1wEDw8QYDknWhAMb44wIMeG C58zPsXECJ; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); 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, 03 Sep 2009 20:08:38 -0000 Dear all, Does anyone know if there is an extension mechanism in MYSQL and whether those extensions are detectable? This has to do with an IANA port request. Thanks in advance, Eliot From sm@resistor.net Thu Sep 3 13:21: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 907EB3A67F4 for ; Thu, 3 Sep 2009 13:21:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 3vIDgzDYVJFN for ; Thu, 3 Sep 2009 13:21:31 -0700 (PDT) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id 1B74E3A67AD for ; Thu, 3 Sep 2009 13:21:28 -0700 (PDT) Received: from subman.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.4.Beta0/8.14.4.Beta0) with ESMTP id n83KJ8LW000178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Sep 2009 13:19:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1252009156; x=1252095556; bh=DBeJMZHIFMxCskpgO5KuMmd3o8I3aY6/ufvzYF/KEhk=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=gyj1TVrheuO8+pTECboJYzzMVDLODaQ8wonR9D8QU7HV/eX4TTLfcwZv5WKYYoa3t zSVT6mSVWoZnn9spNt9DtD6v3kemwca6jvtKEAxQG35FPVQuIxO4nfUjbtDLeJZVZB 4g9hY/HmoPMJR7DgRZ2B0XfNLU1n0dmhKzOBgjRE= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=fIYz/0uyOXMy/f0MNEagm1n1uGCL8zd5BtS1MxLFvhiJjPSghKm/fHgXw7OETcOH5 9phrJiOMd5DkBKW9agCABpoxaz/lSxAmsVxbilPV87Eo84VLIhDH1GoclzEzXYFaaFe DF0mwG1xyLyVMe+MDxq9o2J57u/FBb+BX8BUoXs= Message-Id: <6.2.5.6.2.20090903131157.02e0ad20@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 03 Sep 2009 13:18:56 -0700 To: Eliot Lear From: SM Subject: Re: anyone with deep mysql knowledge? In-Reply-To: <4AA02132.8030207@cisco.com> References: <4AA02132.8030207@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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, 03 Sep 2009 20:21:32 -0000 Hi Eliot, At 13:04 03-09-2009, Eliot Lear wrote: >Does anyone know if there is an extension mechanism in MYSQL and whether >those extensions are detectable? This has to do with an IANA port request. If you mean protocol extensions, the answer is no. Could you elaborate on what you mean by "extension" in relation to MySQL? Regards, -sm From lear@cisco.com Thu Sep 3 22:46: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 413A53A6885 for ; Thu, 3 Sep 2009 22:46:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RI5bVDrDW7vi for ; Thu, 3 Sep 2009 22:46:50 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 51D3C3A6879 for ; Thu, 3 Sep 2009 22:46:50 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFADtGoEqrR7MV/2dsb2JhbACBU78fiEEBkCcFhBs X-IronPort-AV: E=Sophos;i="4.44,330,1249257600"; d="scan'208";a="201812053" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 04 Sep 2009 05:44:28 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n845iRbu017806; Thu, 3 Sep 2009 22:44:27 -0700 Received: from adsl-247-4-fixip.tiscali.ch (dhcp-10-61-108-223.cisco.com [10.61.108.223]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n845iQu7011159; Fri, 4 Sep 2009 05:44:27 GMT Message-ID: <4AA0A93A.5070603@cisco.com> Date: Fri, 04 Sep 2009 07:44:26 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 MIME-Version: 1.0 To: SM Subject: Re: anyone with deep mysql knowledge? References: <4AA02132.8030207@cisco.com> <6.2.5.6.2.20090903131157.02e0ad20@resistor.net> In-Reply-To: <6.2.5.6.2.20090903131157.02e0ad20@resistor.net> X-Enigmail-Version: 0.97a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=442; t=1252043067; x=1252907067; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20anyone=20with=20deep=20mysql=20knowledg e? |Sender:=20; bh=X5/q2WfovqSwT5orE2DWns4VPf6+blnuQYyUHmj3YDQ=; b=n3orCmj2+Leu89aONO12vjseeSXTz67UCkfZKAug3uaYJ6vOV/UTXXftf0 iBk6FuVTgrRC9YYJR0WYuqV291bql/aLcTr/2W1gWZoz372A75C2KFxB8uJL zteChkAjJf4+XWb9v2BjAwhrwX4EScpdjVjL9SOi8uJh04srxlBuU=; Authentication-Results: sj-dkim-1; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); 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, 04 Sep 2009 05:46:51 -0000 On 9/3/09 10:18 PM, SM wrote: > Hi Eliot, > At 13:04 03-09-2009, Eliot Lear wrote: >> Does anyone know if there is an extension mechanism in MYSQL and whether >> those extensions are detectable? This has to do with an IANA port >> request. > > If you mean protocol extensions, the answer is no. Could you > elaborate on what you mean by "extension" in relation to MySQL? Just that. Protocol extensions. Thanks, SM. ELiot From anthonybryan@gmail.com Mon Sep 7 18:44: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 B77DB3A688D for ; Mon, 7 Sep 2009 18:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.783 X-Spam-Level: X-Spam-Status: No, score=-5.783 tagged_above=-999 required=5 tests=[AWL=-3.184, 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 K343zifrJ7al for ; Mon, 7 Sep 2009 18:44:06 -0700 (PDT) Received: from mail-yw0-f173.google.com (mail-yw0-f173.google.com [209.85.211.173]) by core3.amsl.com (Postfix) with ESMTP id D481A3A6814 for ; Mon, 7 Sep 2009 18:44:05 -0700 (PDT) Received: by ywh3 with SMTP id 3so4357736ywh.22 for ; Mon, 07 Sep 2009 18:44: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:content-type; bh=X1ch+kGAx1mXd3czEjiSTF0eRpmZgs3dH4DKITK/MYE=; b=xdCsOVLV6nqGakrJOkJ7oKfcjdGRN6OOLnxyB5F7uRY70Tg2P11iRznfRQhOVdkh85 8QIr1XftViVm3dZC5ooD04OIpWh8hXLsFKZXReyV1oa0AMzZ4Jsky3OvvzH14ytl8usB 4pUR7V99gxVz31WG+pvZ3Ar62NchO/rwZoBZ0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=pQxb+XVgpQcYl6rOfbDKKAXfihnYiacoG4xELxbrc0fX1LlBtY2m9y7hNuV+QxKtFH KmZ1NV2MJO3f26i4ymTpwBhSSo7cwandSJrDeaDN0aDNMQpOcTqkdx4xRqHyUUDuXfcr j++z17NowkMw1nFBfkd3AoUUG+LnaSqxCWpAU= MIME-Version: 1.0 Received: by 10.151.4.19 with SMTP id g19mr24942306ybi.185.1252374271002; Mon, 07 Sep 2009 18:44:31 -0700 (PDT) Date: Mon, 7 Sep 2009 21:44:30 -0400 Message-ID: Subject: Request for review of Metalink (XML for downloads) Internet Draft From: Anthony Bryan To: general discussion of application-layer protocols Content-Type: text/plain; charset=ISO-8859-1 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, 08 Sep 2009 01:44:06 -0000 We are seeking review of our Internet Draft. http://tools.ietf.org/html/draft-bryan-metalink Abstract This document specifies Metalink, an XML-based download description format. Metalink describes alternate download locations (mirrors), checksums, and other information. Clients can transparently use this information to reliably transfer files. -- (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] )) Easier, More Reliable, Self Healing Downloads From yaojk@cnnic.cn Tue Sep 8 18:35: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 5BB3E3A6B19 for ; Tue, 8 Sep 2009 18:35:58 -0700 (PDT) X-Quarantine-ID: <12KGczCp8Nxa> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: 0.762 X-Spam-Level: X-Spam-Status: No, score=0.762 tagged_above=-999 required=5 tests=[AWL=0.805, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803] 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 12KGczCp8Nxa for ; Tue, 8 Sep 2009 18:35:57 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by core3.amsl.com (Postfix) with SMTP id 0F4983A67F0 for ; Tue, 8 Sep 2009 18:35:56 -0700 (PDT) Received: (eyou send program); Wed, 09 Sep 2009 09:36:28 +0800 Message-ID: <452460188.03592@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO whatisfuture) (127.0.0.1) by 127.0.0.1 with SMTP; Wed, 09 Sep 2009 09:36:28 +0800 Message-ID: <07ce01ca30ed$f2ad5a70$236ff1da@whatisfuture> From: "YAO Jiankang" To: Subject: Fw: I-D Action:draft-yao-ccn-ddds-00.txt Date: Wed, 9 Sep 2009 09:36:26 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_07CC_01CA3131.0081DE30" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3598 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 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, 09 Sep 2009 01:35:58 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_07CC_01CA3131.0081DE30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 DQoNCiBEZWFyIGFsbCwNCiANCiAgICAgVGhpcyBpcyBhIGRyYWZ0IGFib3V0IENoaW5lc2UgQ29t bW9uIE5hbWUgTWFwcGluZyB0byBVUkkgKHNlcnZpY2VzKSBiYXNlZCBvbiBERERTLiBJdCBpcyBz aW1pbGFyIHRvIEVOVU0gd2hpY2ggbWFwIEUuMTY0IG51bWJlciB0byBVUkkgKHNlcnZpY2VzKSBi YXNlZCBvbiBERERTLiBUaGlzIGlkZWEgaGFzIGJlZW4gZGlzY3Vzc2VkIGluIHRoaXMgbGlzdCBh IGZldyBtb250aHMgYWdvLiBJdCBzZWVtcyBpbXBvc3NpYmxlIHRvIGJ1aWxkIGEgZ2xvYmFsIENv bW1vbiBOYW1lIG1hcHBpbmcgZm9yIGFsbCBsYW5ndWFnZXMuDQogd2UgaG9wZSB0byBzZWVrIHRv IHB1Ymxpc2ggdGhpcyBkcmFmdCBhcyBpbmZvcm1hdGlvbmFsIFJGQyBvciBCQ1AgUkZDIHRocm91 Z2ggaW5kaXZpZHVhbCBzdWJtaXNzaW9uLiBJbiBDaGluYSwgdGhlcmUgYXJlIHJ1bm5pbmcgYSBL ZXl3b3JkIHN5c3RlbSBzaW1pbGFyIHRvIHRoaXMuIElmIHRoZXJlIGhhcyBhIFJGQyBpbiBJRVRG IGFib3V0ICB0aGlzIGlzc3VlLCBpdCB3aWxsIGhlbHAgdGhlIGRlcGxveW1lbnQgb2YgQ2hpbmVz ZSBDb21tb24gTmFtZS4NCiANCiBhbnkgY29tbWVudHMgYXJlIHdlbGNvbWUuDQogDQogdGhhbmtz Lg0KIA0KIA0KIFlhbyBKaWFua2FuZw0KIENOTklDIA0KIA0KIA0KDQo+IC0tLS0tIE9yaWdpbmFs IE1lc3NhZ2UgLS0tLS0gDQo+IEZyb206IDxJbnRlcm5ldC1EcmFmdHNAaWV0Zi5vcmc+DQo+IFRv OiA8aS1kLWFubm91bmNlQGlldGYub3JnPg0KPiBTZW50OiBUdWVzZGF5LCBTZXB0ZW1iZXIgMDgs IDIwMDkgMTA6MzAgUE0NCj4gU3ViamVjdDogSS1EIEFjdGlvbjpkcmFmdC15YW8tY2NuLWRkZHMt MDAudHh0IA0KPiANCj4gDQo+PkEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9t IHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NCj4+IA0KPj4gVGl0bGUg ICAgICAgICAgIDogQ2hpbmVzZSBDb21tb24gTmFtZSB0byBVbmlmb3JtIFJlc291cmNlIElkZW50 aWZpZXIoVVJJKSBEeW5hbWljIERlbGVnYXRpb24gRGlzY292ZXJ5IFN5c3RlbShERERTKSBBcHBs aWNhdGlvbihDQ04pDQo+PiBBdXRob3IocykgICAgICAgOiBKLiBZYW8sIFguIExlZQ0KPj4gRmls ZW5hbWUgICAgICAgIDogZHJhZnQteWFvLWNjbi1kZGRzLTAwLnR4dA0KPj4gUGFnZXMgICAgICAg ICAgIDogMTANCj4+IERhdGUgICAgICAgICAgICA6IDIwMDktMDktMDgNCj4+IA0KPj4gVGhpcyBk b2N1bWVudCBkaXNjdXNzZXMgdGhlIHVzZSBvZiB0aGUgRG9tYWluIE5hbWUgU3lzdGVtKEROUykg Zm9yDQo+PiBzdG9yYWdlIG9mIENoaW5lc2UgQ29tbW9uIE5hbWUgdG8gVVJJIG1hcHBpbmcuICBN b3JlIHNwZWNpZmljYWxseSwNCj4+IGhvdyBETlMgY2FuIGJlIHVzZWQgZm9yIGlkZW50aWZ5aW5n IFVSSXMgb3Igc2VydmljZXMgYXNzb2NpYXRlZCB3aXRoDQo+PiB0aGUgQ2hpbmVzZSBDb21tb24g TmFtZXMuICBUaGUgbWV0aG9kIHVzZWQgdG8gZGlzY292ZXIgdGhlIG1hcHBpbmcgaXMNCj4+IHRo ZSBEeW5hbWljIERlbGVnYXRpb24gRGlzY292ZXJ5IFN5c3RlbSwgd2hpY2ggY2FuIGJlIGZvdW5k IGluIGENCj4+IHNlcmllcyBvZiBkb2N1bWVudHMgc3BlY2lmaWVkIGluIFJGQyAzNDAxLiAgVW5k ZXJzdGFuZGluZyBvZiBSRkMgMzQwMQ0KPj4gaXMgbmVjZXNzYXJ5IGZvciB1bmRlcnN0YW5kaW5n IHRoaXMgZG9jdW1lbnQuDQo+PiANCj4+IEEgVVJMIGZvciB0aGlzIEludGVybmV0LURyYWZ0IGlz Og0KPj4gaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQteWFvLWNjbi1k ZGRzLTAwLnR4dA0KPj4gDQo+PiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5 IGFub255bW91cyBGVFAgYXQ6DQo+PiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz Lw0KPj4gDQo+PiBCZWxvdyBpcyB0aGUgZGF0YSB3aGljaCB3aWxsIGVuYWJsZSBhIE1JTUUgY29t cGxpYW50IG1haWwgcmVhZGVyDQo+PiBpbXBsZW1lbnRhdGlvbiB0byBhdXRvbWF0aWNhbGx5IHJl dHJpZXZlIHRoZSBBU0NJSSB2ZXJzaW9uIG9mIHRoZQ0KPj4gSW50ZXJuZXQtRHJhZnQuDQo+Pg0K PiANCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiANCj4+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBJLUQtQW5ub3VuY2UgbWFp bGluZyBsaXN0DQo+PiBJLUQtQW5ub3VuY2VAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQo+PiBJbnRlcm5ldC1EcmFmdCBkaXJl Y3RvcmllczogaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbA0KPj4gb3IgZnRwOi8vZnRw LmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQNCj4+ ------=_NextPart_000_07CC_01CA3131.0081DE30 Content-Type: text/plain; name="draft-yao-ccn-ddds-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-yao-ccn-ddds-00.txt" Content-Type: text/plain Content-ID: <2009-09-08072901.I-D@ietf.org> ------=_NextPart_000_07CC_01CA3131.0081DE30-- From yaojk@cnnic.cn Tue Sep 8 18: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 BFC833A6899 for ; Tue, 8 Sep 2009 18:26:55 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: 0.805 X-Spam-Level: X-Spam-Status: No, score=0.805 tagged_above=-999 required=5 tests=[AWL=0.848, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803] 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 xxweWU0mk7yp for ; Tue, 8 Sep 2009 18:26:54 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by core3.amsl.com (Postfix) with SMTP id 3C4CD3A6A7B for ; Tue, 8 Sep 2009 18:26:53 -0700 (PDT) Received: (eyou send program); Wed, 09 Sep 2009 09:27:25 +0800 Message-ID: <452459645.11143@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO whatisfuture) (127.0.0.1) by 127.0.0.1 with SMTP; Wed, 09 Sep 2009 09:27:25 +0800 Message-ID: <07b701ca30ec$aecf3270$236ff1da@whatisfuture> From: "YAO Jiankang" To: Subject: Fw: I-D Action:draft-yao-ccn-ddds-00.txt Date: Wed, 9 Sep 2009 09:27:23 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_07B5_01CA312F.BC958560" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3598 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailman-Approved-At: Thu, 10 Sep 2009 08:04:22 -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, 09 Sep 2009 01:26:55 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_07B5_01CA312F.BC958560 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 RGVhciBhbGwsDQoNCiAgICAgVGhpcyBpcyBhIGRyYWZ0IGFib3V0IENoaW5lc2UgQ29tbW9uIE5h bWUgTWFwcGluZyB0byBVUkkgKHNlcnZpY2VzKSBiYXNlZCBvbiBERERTLiBJdCBpcyBzaW1pbGFy IHRvIEVOVU0gd2hpY2ggbWFwIEUuMTY0IG51bWJlciB0byBVUkkgKHNlcnZpY2VzKSBiYXNlZCBv biBERERTLiBUaGlzIGlkZWEgaGFzIGJlZW4gZGlzY3Vzc2VkIGluIHRoaXMgbGlzdCBhIGZldyBt b250aHMgYWdvLiBJdCBzZWVtcyBpbXBvc3NpYmxlIHRvIGJ1aWxkIGEgZ2xvYmFsIENvbW1vbiBO YW1lIG1hcHBpbmcgZm9yIGFsbCBsYW5ndWFnZXMuDQp3ZSBob3BlIHRvIHNlZWsgdG8gcHVibGlz aCB0aGlzIGRyYWZ0IGFzIGluZm9ybWF0aW9uYWwgUkZDIG9yIEJDUCBSRkMgdGhyb3VnaCBpbmRp dmlkdWFsIHN1Ym1pc3Npb24uIEluIENoaW5hLCB0aGVyZSBhcmUgcnVubmluZyBhIEtleXdvcmQg c3lzdGVtIHNpbWlsYXIgdG8gdGhpcy4gSWYgdGhlcmUgaGFzIGEgUkZDIGluIElFVEYgYWJvdXQg IHRoaXMgaXNzdWUsIGl0IHdpbGwgaGVscCB0aGUgZGVwbG95bWVudCBvZiBDaGluZXNlIENvbW1v biBOYW1lLg0KDQphbnkgY29tbWVudHMgYXJlIHdlbGNvbWUuDQoNCnRoYW5rcy4NCg0KDQpZYW8g SmlhbmthbmcNCkNOTklDIA0KDQoNCllhbyBKaWFua2FuZw0KLS0tLS0gT3JpZ2luYWwgTWVzc2Fn ZSAtLS0tLSANCkZyb206IDxJbnRlcm5ldC1EcmFmdHNAaWV0Zi5vcmc+DQpUbzogPGktZC1hbm5v dW5jZUBpZXRmLm9yZz4NClNlbnQ6IFR1ZXNkYXksIFNlcHRlbWJlciAwOCwgMjAwOSAxMDozMCBQ TQ0KU3ViamVjdDogSS1EIEFjdGlvbjpkcmFmdC15YW8tY2NuLWRkZHMtMDAudHh0IA0KDQoNCj5B IE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5l dC1EcmFmdHMgZGlyZWN0b3JpZXMuDQo+IA0KPiBUaXRsZSAgICAgICAgICAgOiBDaGluZXNlIENv bW1vbiBOYW1lIHRvIFVuaWZvcm0gUmVzb3VyY2UgSWRlbnRpZmllcihVUkkpIER5bmFtaWMgRGVs ZWdhdGlvbiBEaXNjb3ZlcnkgU3lzdGVtKERERFMpIEFwcGxpY2F0aW9uKENDTikNCj4gQXV0aG9y KHMpICAgICAgIDogSi4gWWFvLCBYLiBMZWUNCj4gRmlsZW5hbWUgICAgICAgIDogZHJhZnQteWFv LWNjbi1kZGRzLTAwLnR4dA0KPiBQYWdlcyAgICAgICAgICAgOiAxMA0KPiBEYXRlICAgICAgICAg ICAgOiAyMDA5LTA5LTA4DQo+IA0KPiBUaGlzIGRvY3VtZW50IGRpc2N1c3NlcyB0aGUgdXNlIG9m IHRoZSBEb21haW4gTmFtZSBTeXN0ZW0oRE5TKSBmb3INCj4gc3RvcmFnZSBvZiBDaGluZXNlIENv bW1vbiBOYW1lIHRvIFVSSSBtYXBwaW5nLiAgTW9yZSBzcGVjaWZpY2FsbHksDQo+IGhvdyBETlMg Y2FuIGJlIHVzZWQgZm9yIGlkZW50aWZ5aW5nIFVSSXMgb3Igc2VydmljZXMgYXNzb2NpYXRlZCB3 aXRoDQo+IHRoZSBDaGluZXNlIENvbW1vbiBOYW1lcy4gIFRoZSBtZXRob2QgdXNlZCB0byBkaXNj b3ZlciB0aGUgbWFwcGluZyBpcw0KPiB0aGUgRHluYW1pYyBEZWxlZ2F0aW9uIERpc2NvdmVyeSBT eXN0ZW0sIHdoaWNoIGNhbiBiZSBmb3VuZCBpbiBhDQo+IHNlcmllcyBvZiBkb2N1bWVudHMgc3Bl Y2lmaWVkIGluIFJGQyAzNDAxLiAgVW5kZXJzdGFuZGluZyBvZiBSRkMgMzQwMQ0KPiBpcyBuZWNl c3NhcnkgZm9yIHVuZGVyc3RhbmRpbmcgdGhpcyBkb2N1bWVudC4NCj4gDQo+IEEgVVJMIGZvciB0 aGlzIEludGVybmV0LURyYWZ0IGlzOg0KPiBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRy YWZ0cy9kcmFmdC15YW8tY2NuLWRkZHMtMDAudHh0DQo+IA0KPiBJbnRlcm5ldC1EcmFmdHMgYXJl IGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+IGZ0cDovL2Z0cC5pZXRmLm9y Zy9pbnRlcm5ldC1kcmFmdHMvDQo+IA0KPiBCZWxvdyBpcyB0aGUgZGF0YSB3aGljaCB3aWxsIGVu YWJsZSBhIE1JTUUgY29tcGxpYW50IG1haWwgcmVhZGVyDQo+IGltcGxlbWVudGF0aW9uIHRvIGF1 dG9tYXRpY2FsbHkgcmV0cmlldmUgdGhlIEFTQ0lJIHZlcnNpb24gb2YgdGhlDQo+IEludGVybmV0 LURyYWZ0Lg0KPg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0KPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBJLUQtQW5ub3VuY2UgbWFp bGluZyBsaXN0DQo+IEktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2ktZC1hbm5vdW5jZQ0KPiBJbnRlcm5ldC1EcmFmdCBkaXJlY3Rv cmllczogaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbA0KPiBvciBmdHA6Ly9mdHAuaWV0 Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0KPg== ------=_NextPart_000_07B5_01CA312F.BC958560 Content-Type: text/plain; name="draft-yao-ccn-ddds-00.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-yao-ccn-ddds-00.txt" Content-Type: text/plain Content-ID: <2009-09-08072901.I-D@ietf.org> ------=_NextPart_000_07B5_01CA312F.BC958560-- From stpeter@stpeter.im Thu Sep 10 11:47: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 60F6C3A6A04 for ; Thu, 10 Sep 2009 11:47:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.637 X-Spam-Level: X-Spam-Status: No, score=-2.637 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 7HSewY9IraQc for ; Thu, 10 Sep 2009 11:47:29 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 6A9D63A6A0D for ; Thu, 10 Sep 2009 11:47:29 -0700 (PDT) Received: from dhcp-64-101-72-247.cisco.com (dhcp-64-101-72-247.cisco.com [64.101.72.247]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id BD67740D09 for ; Thu, 10 Sep 2009 12:48:04 -0600 (MDT) Message-ID: <4AA949E3.8060306@stpeter.im> Date: Thu, 10 Sep 2009 12:48:03 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "apps-discuss@ietf.org" Subject: f* wildcards (was: [Fwd: Re: [VCARDDAV] AD review of draft-ietf-vcarddav-carddav-07.txt]) X-Enigmail-Version: 0.96.0 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: Thu, 10 Sep 2009 18:47:31 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I just noticed this aspect of a message that Alexey sent to the vCard list a few weeks ago. I tend to agree with what Alexey reports from a recent IESG telechat, but I wonder if it will be codified somehow; perhaps in the server identity checking I-D we've discussed here? - -------- Original Message -------- Subject: Re: [VCARDDAV] AD review of draft-ietf-vcarddav-carddav-07.txt Date: Mon, 17 Aug 2009 00:02:08 +0100 From: Alexey Melnikov To: Cyrus Daboo CC: CardDAV References: <4A888C37.50400@isode.com> 3. Requirements Overview o MUST support secure transport as defined in [RFC2818] using TLS [RFC5246]; This recently came up in review of draft-ietf-geopriv-http-location-delivery-15.txt: RFC 2818, Section 3.1 says: Matching is performed using the matching rules specified by [RFC2459]. If more than one identity of a given type is present in the certificate (e.g., more than one dNSName name, a match in any one of the set is considered acceptable.) Names may contain the wildcard character * which is considered to match any single domain name component or component fragment. E.g., *.a.com matches foo.a.com but not bar.foo.a.com. f*.com matches foo.com but not bar.com. Based on the discussion during an IESG telechat several ADs agreed that f* wildcards shouldn't be allowed anymore. So, the document should say that it complies with RFC 2818, except for f* type wildcards are not allowed. (wildcards in the leftmost label are still allowed). This is consistent with the advice from RFC 5280. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqpSeMACgkQNL8k5A2w/vxcrwCgqCve36pf/7PDq+xrX0cUMxLP fAsAnip9zPs8fa7x0xHdv84zQSo3AyYY =8wyw -----END PGP SIGNATURE----- From alexey.melnikov@isode.com Thu Sep 10 13:46:56 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 6EC1B28C1BB for ; Thu, 10 Sep 2009 13:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[AWL=-0.286, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] 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 LdlZbzA8CTW2 for ; Thu, 10 Sep 2009 13:46:55 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 3F0683A6A61 for ; Thu, 10 Sep 2009 13:46:55 -0700 (PDT) Received: from [92.40.152.171] (92.40.152.171.sub.mbb.three.co.uk [92.40.152.171]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 10 Sep 2009 21:47:25 +0100 Message-ID: <4AA965D7.7090706@isode.com> Date: Thu, 10 Sep 2009 21:47:19 +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: Peter Saint-Andre Subject: Re: f* wildcards (was: [Fwd: Re: [VCARDDAV] AD review of draft-ietf-vcarddav-carddav-07.txt]) References: <4AA949E3.8060306@stpeter.im> In-Reply-To: <4AA949E3.8060306@stpeter.im> 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: Thu, 10 Sep 2009 20:46:56 -0000 Peter Saint-Andre wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >I just noticed this aspect of a message that Alexey sent to the vCard >list a few weeks ago. I tend to agree with what Alexey reports from a >recent IESG telechat, but I wonder if it will be codified somehow; >perhaps in the server identity checking I-D we've discussed here? > > Yes. >- -------- Original Message -------- >Subject: Re: [VCARDDAV] AD review of draft-ietf-vcarddav-carddav-07.txt >Date: Mon, 17 Aug 2009 00:02:08 +0100 >From: Alexey Melnikov >To: Cyrus Daboo >CC: CardDAV >References: <4A888C37.50400@isode.com> > > > >3. Requirements Overview > > o MUST support secure transport as defined in [RFC2818] using TLS > [RFC5246]; > >This recently came up in review of >draft-ietf-geopriv-http-location-delivery-15.txt: > >RFC 2818, Section 3.1 says: > > Matching is performed using the matching rules specified by > [RFC2459]. If more than one identity of a given type is present in > the certificate (e.g., more than one dNSName name, a match in any one > of the set is considered acceptable.) Names may contain the wildcard > character * which is considered to match any single domain name > component or component fragment. E.g., *.a.com matches foo.a.com but > not bar.foo.a.com. f*.com matches foo.com but not bar.com. > >Based on the discussion during an IESG telechat several ADs agreed that >f* wildcards shouldn't be allowed anymore. So, the document should say >that it complies with RFC 2818, except for f* type wildcards are not >allowed. (wildcards in the leftmost label are still allowed). This is >consistent with the advice from RFC 5280. > > From stpeter@stpeter.im Thu Sep 10 14:39: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 C982C3A6A70 for ; Thu, 10 Sep 2009 14:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.635 X-Spam-Level: X-Spam-Status: No, score=-2.635 tagged_above=-999 required=5 tests=[AWL=-0.036, 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 HH7n7f9tcDMf for ; Thu, 10 Sep 2009 14:39:13 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 16BFA3A68AF for ; Thu, 10 Sep 2009 14:39:13 -0700 (PDT) Received: from dhcp-64-101-72-247.cisco.com (dhcp-64-101-72-247.cisco.com [64.101.72.247]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8495440D09; Thu, 10 Sep 2009 15:39:48 -0600 (MDT) Message-ID: <4AA97223.5060902@stpeter.im> Date: Thu, 10 Sep 2009 15:39:47 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Alexey Melnikov Subject: Re: f* wildcards References: <4AA949E3.8060306@stpeter.im> <4AA965D7.7090706@isode.com> In-Reply-To: <4AA965D7.7090706@isode.com> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 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: Thu, 10 Sep 2009 21:39:13 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/10/09 2:47 PM, Alexey Melnikov wrote: > Peter Saint-Andre wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> I just noticed this aspect of a message that Alexey sent to the vCard >> list a few weeks ago. I tend to agree with what Alexey reports from a >> recent IESG telechat, but I wonder if it will be codified somehow; >> perhaps in the server identity checking I-D we've discussed here? >> >> > Yes. Works for me. This will be in version -02 of draft-saintandre-tls-server-id-check. 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/ iEYEARECAAYFAkqpciMACgkQNL8k5A2w/vwl/gCfYwX5nzSDkiiaLvbcja1U7g9I 3SkAn2Ww9PeL8IBt+Ya4PaD1ciXs20Qp =6lbf -----END PGP SIGNATURE----- From lisa.dusseault@gmail.com Thu Sep 10 22:14: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 59D6D3A6A66 for ; Thu, 10 Sep 2009 22:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.723 X-Spam-Level: X-Spam-Status: No, score=-2.723 tagged_above=-999 required=5 tests=[AWL=-0.125, 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 6uyqiut3HTk2 for ; Thu, 10 Sep 2009 22:14:20 -0700 (PDT) Received: from mail-vw0-f201.google.com (mail-vw0-f201.google.com [209.85.212.201]) by core3.amsl.com (Postfix) with ESMTP id DC9C53A67F8 for ; Thu, 10 Sep 2009 22:14:19 -0700 (PDT) Received: by vws39 with SMTP id 39so537987vws.29 for ; Thu, 10 Sep 2009 22:14:01 -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; bh=t9tRms7Wv+PCLAImC6McICYzyypXjTmMj42ySe9Zg6M=; b=Kn5tjYLxQpBmG1ubXLAM7W70xVJ6vNehLyuwr+Fz5pqX+cbczACE/RSESheLD3M4J6 NWGSz6nM573OZrLZyRhXdRtSmWP/Rf/GAmotCZr5gS5jMs1FrtOmrGv4xx2TPEIqaV9D lT2vc6qrIOPCHw7U0UQrBTj+o1qylCKq/BTlQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=GTJRZd6lX9Q6e2OlBhkPPG8UGPd9thndXdKUNWGmeorDHm89ubXbZUeaBjFxthzLsN NC7CJI2Ylooetn3/OQDFIGrSAA3OpdV8hEcef9v1UgFkOKgBMZUNfy0ls/kwfjWgMMSU 6T5Pfl7w1EIqoQYAn3GH6kA05G7//+opVQ97E= MIME-Version: 1.0 Received: by 10.220.108.41 with SMTP id d41mr2865148vcp.28.1252646040829; Thu, 10 Sep 2009 22:14:00 -0700 (PDT) Date: Thu, 10 Sep 2009 22:14:00 -0700 Message-ID: Subject: Lisa's Apps Area Activity Report for August 2009 From: Lisa Dusseault To: discuss@ietf.org, lisa-dusseault-chairs@tools.ietf.org Content-Type: multipart/alternative; boundary=00c09f8c25244b010b0473466266 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, 11 Sep 2009 05:14:22 -0000 --00c09f8c25244b010b0473466266 Content-Type: text/plain; charset=ISO-8859-1 *News, Updates* IETF 76 Bar BoF planning: http://trac.tools.ietf.org/area/app/trac/wiki/BarBofs IETF 76 BOFs: see http://trac.tools.ietf.org/bof/trac/wiki -- In progress, BOF requests not approved yet *Document Status and Progress* Active documents, my action: - draft-ietf-alto-problem-statement (Info): In IESG Evaluation Active documents, waiting on other: - draft-montemurro-gsma-imei-urn (Exp): New version of draft expected - 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 - draft-ietf-calsify-2446bis (PS): In Last Call - draft-wilde-sms-uri (PS): In Last Call - draft-freed-sieve-in-xml (PS): Waiting for revision from authors & WG consensus on new format for comments - draft-nottingham-http-link-header (PS): Waiting for revision from authors Finished processing -- new in RFC Ed queue and new RFCs - none *WG Status* ALTO: Problem Statement document nearing completion; some discussion on protocol integrity and security. CALSIFY: RFC2445bis code license issues resolved; RFC2446bis in Last Call. HTTPBIS: Working through issues in the tracker IDNABIS: WGLC ended August 31; WG considering significant reviews done in LC. OAUTH: New non-WG document: draft-vrancken-oauth-redelegation-00.txt SIEVE: Some drafts going through final stages and WG review of last-minute issues (e.g. sieve-in-xml and validation of comments) --00c09f8c25244b010b0473466266 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable News, Updates
IETF 76 Bar BoF planning: http://t= rac.tools.ietf.org/area/app/trac/wiki/BarBofs
IETF 76 BOFs: see http://trac.tools.ietf.org/bof/trac/wiki -- In progress,= BOF requests not approved yet

Document Status and Progress Active documents, my action:
- draft-ietf-alto-problem-statement (Info):=A0 In IESG Evaluation

Active documents, waiting on other:
- draft-montemurro-gsma-imei-urn= (Exp): New version of draft expected
- draft-reschke-webdav-post (Exp):= Cyrus Daboo is doing shepherd review and writeup
- draft-ietf-sieve-mim= e-loop (PS): Waiting on authors to respond to GenArt review
- draft-ietf-calsify-2446bis (PS): In Last Call
- draft-wilde-sms-uri (P= S): In Last Call
- draft-freed-sieve-in-xml (PS): Waiting for revision f= rom authors & WG consensus on new format for comments
- draft-nottin= gham-http-link-header (PS): Waiting for revision from authors

Finished processing -- new in RFC Ed queue and new RFCs
=A0- none


WG Status

ALTO: Problem Statement document near= ing completion; some discussion on protocol integrity and security.
CALSIFY: RFC2445bis code license issues resolved; RFC2446bis in Last Call.<= br>HTTPBIS: Working through issues in the tracker
IDNABIS:=A0 WGLC ended= August 31; WG considering significant reviews done in LC.
OAUTH: New no= n-WG document: draft-vrancken-oauth-redeleg= ation-00.txt
SIEVE:=A0 Some drafts going through final stages and WG review of last-minu= te issues (e.g. sieve-in-xml and validation of comments)

--00c09f8c25244b010b0473466266-- From samj@samj.net Fri Sep 11 06:17: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 88ABD3A68A7 for ; Fri, 11 Sep 2009 06:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.922 X-Spam-Level: X-Spam-Status: No, score=-4.922 tagged_above=-999 required=5 tests=[AWL=-3.546, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_45=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 dvcmcJCuV5bq for ; Fri, 11 Sep 2009 06:17:11 -0700 (PDT) Received: from eu1sys200aog102.obsmtp.com (eu1sys200aog102.obsmtp.com [207.126.144.113]) by core3.amsl.com (Postfix) with SMTP id 1B9C83A685C for ; Fri, 11 Sep 2009 06:17:09 -0700 (PDT) Received: from source ([72.14.220.157]) by eu1sys200aob102.postini.com ([207.126.147.11]) with SMTP ID DSNKSqpN+kHddi5d0PrOYjLRK5qqgPI9jc4E@postini.com; Fri, 11 Sep 2009 13:17:47 UTC Received: by fg-out-1718.google.com with SMTP id e21so1715055fga.15 for ; Fri, 11 Sep 2009 06:17:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.86.18.34 with SMTP id 34mr2298168fgr.2.1252675066039; Fri, 11 Sep 2009 06:17:46 -0700 (PDT) In-Reply-To: <404dcbd20909110500j5394c43dve10264c01a7a6244@mail.gmail.com> References: <8860AD10-B0C5-4BEF-8C68-731973EF4046@mac.com> <30ac519d0909101631m14782ce8vd085629237b0e444@mail.gmail.com> <21606dcf0909110445s78ea728cueb158ff588f394a5@mail.gmail.com> <404dcbd20909110500j5394c43dve10264c01a7a6244@mail.gmail.com> Date: Fri, 11 Sep 2009 15:17:46 +0200 Message-ID: <21606dcf0909110617y40586e53x213e5e8febc4a9e8@mail.gmail.com> Subject: Re: Input on request for link relation From: Sam Johnston To: Hadrien Gardeur Content-Type: multipart/alternative; boundary=00c09ffb554454905404734d24ea Cc: apps-discuss@ietf.org, Atom-Syntax Syntax , jpanzer@acm.org, ietf-http-wg@w3.org, Jan Algermissen 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, 11 Sep 2009 13:17:12 -0000 --00c09ffb554454905404734d24ea Content-Type: text/plain; charset=ISO-8859-1 On Fri, Sep 11, 2009 at 2:00 PM, Hadrien Gardeur < hadrien.gardeur@feedbooks.com> wrote: >> In line with comments I've made in other threads I think it makes sense >> for us to limit link relation discussions to the generic relation itself >> rather than any specific implementation of it. > > Several relations would need a similar treatment. Yes, though I believe Mark's "Web Linking" draft does this already. > For example: >> >> edit: An IRI of an editable Member Entry. When appearing within an >> atom:entry, the href IRI can be used to retrieve, update and delete the >> Resource represented by that Entry. > > BTW, what would be the generic link relation to indicate an AtomPub > collection (only the service document is registered at IANA) ? I started thinking about this earlier in the week with a view to having e.g. a representation of a bookshelf referring to a collection/feed/url-list/etc. of books using rel="collection". I then started looking at parent/child/sibling relationships which are currently being discussed in a separate thread (my preference is for something like e.g. "rel=descendant level=2" for grandchildren as I subsequently realised that suggested abbreviations "asc" for ascendant and "desc" for descendant can be confused with item ordering). Do you think these "family" relations serve all the use cases for a "collection" relation? > I agree. We need a better policy for rel values. Currently, it seems that > new rel values are added to the IANA link registry whenever a new RFC is > adopted. These relationships could have a much broader scope and shouldn't > be bound to particular protocols. Great. I don't think there's much contention over this point (at least I've not yet seen any) and the draft spells out the requirements (which can be summarised as "broadly useful") reasonably well: > Commonly-used relation types with a clear meaning that are shared across applications can be registered as tokens for convenience and to promote reuse. For example, "self" and "alternate" are registered relation types, because they are broadly useful. The registry also outlines the process which involves a dedicated expert and public comment period: 6.2. Link Relation Type Registry > This specification establishes the Link Relation Type Registry, and updates Atom [RFC4287] to refer to it in place of the "Registry of Link Relations". > The requirements for registered relation types are described in Section 4.1. > Relation types are registered on the advice of a Designated Expert (appointed by the IESG or their delegate), with a Specification Required (using terminology from [RFC5226]). > Registration requests consist of the completed registration template below, typically published in an RFC or Open Standard (in the sense described by [RFC2026], Section 7). However, to allow for the allocation of values prior to publication, the Designated Expert may approve registration once they are satisfied that an RFC (or other Open Standard) will be published. > The registration template is: > o Relation Name: o Description: o Reference: o Notes: [optional] > Upon receiving a registration request (usually via IANA), the Designated Expert should request review and comment from the apps-discuss@ietf.org mailing list (or a successor designated by the APPS Area Directors). Before a period of 30 days has passed, the Designated Expert will either approve or deny the registration request, communicating this decision both to the review list and to IANA. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful. Ironically the apps-discuss list wasn't included so I am adding them now. One nitpick about the process is that it seems a request can be denied with a suggestion for another relation (for example we might prefer to use something like "push" or "notif[y|ier|ication|ications" rather than "hub" for this one) but then that would require restarting the process where it should proceed to registration immediately if the change is accepted by the applicant. I also question the relevance of the "reference" field in the registry as this links relations to implementations which I think we agree is a bad thing - the registry should capture all the necessary semantics without reliance on external references. It may be interesting to list zero or more implementations of the relation (that is, make the "reference" field optional as well and allow others to add themselves to it), however I'm not sure the maintenance load is worth the effort. Sam --00c09ffb554454905404734d24ea Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Sep 11, 2009 at 2:00 PM, Hadrien Gardeur <hadrien.gardeur@feedbooks.com> wrote:
= >> In line with comments I've made in other threads I think it ma= kes sense
>> for us to limit link relation discussions to the generic relation = itself
>> rather than any specific implementation of it.
>> Several relations would need a similar treatment.

Yes, though= I believe Mark's "Web Linking" draft does this already.
> For example:
>>
>> edit: An IRI of an editable M= ember Entry. When appearing within an
>> atom:entry, the href IRI = can be used to retrieve, update and delete the
>> Resource represe= nted by that Entry.
>
> BTW, what would be the generic link relation to indicate an At= omPub
> collection (only the service document is registered at IANA) = ?=A0

I started thinking about this earlier in the week with a view t= o having e.g. a representation of a bookshelf referring to a collection/fee= d/url-list/etc. of books using rel=3D"collection". I then started= looking at parent/child/sibling relationships which are currently being di= scussed in a separate thread (my preference is for something like e.g. &quo= t;rel=3Ddescendant level=3D2" for grandchildren as I subsequently real= ised that suggested abbreviations "asc" for ascendant and "d= esc" for descendant can be confused with item ordering). Do you think = these "family" relations serve all the use cases for a "coll= ection" relation?

> I agree. We need a better policy for rel values. Currently, it see= ms that
> new rel values are added to the IANA link registry whenever= a new RFC is
> adopted. These relationships could have a much broade= r scope and shouldn't
> be bound to particular protocols.=A0

Great. I don't think t= here's much contention over this point (at least I've not yet seen = any) and the draft spells out the requirements (which can be summarised as = "broadly useful") reasonably well:

Commonly-used relation types with a clear meaning that are shared
across applications can be registered as tokens for convenience and
to promote reuse. =A0For example, "self" and "alternate"= ; are registered
relation types, because they are broadly useful.

The registry also outlines the process which involves a dedicated exp= ert and public comment period:

6.2. =A0Link Relation Type Registry

=A0=A0 This specification establishes the Link Relation Type Registry, and<= /blockquote>
=A0=A0 updates Atom [RFC4287] to refer to it in place of the "Registry= of
=A0=A0 Link Relations".

=A0=A0 The requirements for registered relation types are described in
=A0=A0 Section 4.1.

=A0=A0 Relation types are registered on the advice of a Designated Expert
=A0=A0 (appointed by the IESG or their delegate), with a Specification
=A0=A0 Required (using terminology from [RFC5226]).

=A0=A0 Registration requests consist of the completed registration template=
=A0=A0 below, typically published in an RFC or Open Standard (in the sense<= /blockquote>
=A0=A0 described by [RFC2026], Section 7). =A0However, to allow for the
=A0=A0 allocation of values prior to publication, the Designated Expert may=
=A0=A0 approve registration once they are satisfied that an RFC (or other
=A0=A0 Open Standard) will be published.

=A0=A0 The registration template is:

=A0=A0 o =A0Relation Name:
=A0=A0 o =A0Description:
=A0=A0 o =A0Reference:
=A0=A0 o =A0Notes: [optional]

=A0=A0 Upon receiving a registration request (usually via IANA), the
=A0=A0 Designated Expert should request review and comment from the
=A0=A0 apps-discuss@ietf.org m= ailing list (or a successor designated by the
=A0=A0 APPS Area Directors). =A0Before a period of 30 days has passed, the<= /blockquote>
=A0=A0 Designated Expert will either approve or deny the registration
=A0=A0 request, communicating this decision both to the review list and to<= /blockquote>
=A0=A0 IANA. =A0Denials should include an explanation and, if applicable,
=A0=A0 suggestions as to how to make the request successful.

Ironically the apps-discuss list wasn't include= d so I am adding them now. One nitpick about the process is that it seems a= request can be denied with a suggestion for another relation (for example = we might prefer to use something like "push" or "notif[y|ier= |ication|ications" rather than "hub" for this one) but then = that would require restarting the process where it should proceed to regist= ration immediately if the change is accepted by the applicant.

I also question the relevance of the "refere= nce" field in the registry as this links relations to implementations = which I think we agree is a bad thing - the registry should capture all the= necessary semantics without reliance on external references. It may be int= eresting to list zero or more implementations of the relation (that is, mak= e the "reference" field optional as well and allow others to add = themselves to it), however I'm not sure the maintenance load is worth t= he effort.

Sam

--00c09ffb554454905404734d24ea-- From samj@samj.net Fri Sep 11 08:51: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 CF5243A6832 for ; Fri, 11 Sep 2009 08:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.362 X-Spam-Level: X-Spam-Status: No, score=-5.362 tagged_above=-999 required=5 tests=[AWL=-3.386, 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 VyyusL6YGaPK for ; Fri, 11 Sep 2009 08:51:14 -0700 (PDT) Received: from eu1sys200aog103.obsmtp.com (eu1sys200aog103.obsmtp.com [207.126.144.115]) by core3.amsl.com (Postfix) with SMTP id 29C193A67DB for ; Fri, 11 Sep 2009 08:51:13 -0700 (PDT) Received: from source ([209.85.220.216]) by eu1sys200aob103.postini.com ([207.126.147.11]) with SMTP ID DSNKSqpyF6+6A8Doe26nf3CkygDT1HuKapT4@postini.com; Fri, 11 Sep 2009 15:51:52 UTC Received: by fxm12 with SMTP id 12so1006308fxm.44 for ; Fri, 11 Sep 2009 08:51:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.86.18.34 with SMTP id 34mr2442975fgr.2.1252684310911; Fri, 11 Sep 2009 08:51:50 -0700 (PDT) Date: Fri, 11 Sep 2009 17:51:50 +0200 Message-ID: <21606dcf0909110851u67499b38s543eb3900ee04aab@mail.gmail.com> Subject: Removing references from link relations registry? From: Sam Johnston To: Mark Nottingham Content-Type: multipart/mixed; boundary=00c09ffb55445e1bbb04734f4b22 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, 11 Sep 2009 15:51:15 -0000 --00c09ffb55445e1bbb04734f4b22 Content-Type: multipart/alternative; boundary=00c09ffb55445e1baf04734f4b20 --00c09ffb55445e1baf04734f4b20 Content-Type: text/plain; charset=ISO-8859-1 Mark, There appears to be a consensus about link relations being generic and independent of implementations on the basis that the namespace (english language) is extremely sparse, there are alternative mechanisms for identifying implementations (URI relations, content types) and generally to avoid duplication of every relation for every type. That being the case the definitions should be relatively concise, generic and in plain english - ideally derived from dictionary definitions so as to avoid repurposing words. They should also not be dependent on external resources, particularly where multiple references (e.g. Atom and HTML) define the same terms. Accordingly please find attached a patch to draft-nottingham-http-link-header-06.xmlwhich removes references from the registry. In the alternative perhaps you would consider renaming the field to "Informative Reference(s)", though references to implementations "in the wild" would perhaps be better stored in a wiki like the WHAT WG RelExtensionspage. Sam --00c09ffb55445e1baf04734f4b20 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Mark,

There appears to be a consensus about link relatio= ns being generic and independent of implementations on the basis that the n= amespace (english language) is extremely sparse, there are alternative mech= anisms for identifying implementations (URI relations, content types) and g= enerally to avoid duplication of every relation for every type.

That being the case the definitions should be relativel= y concise, generic and in plain english - ideally derived from dictionary d= efinitions so as to avoid repurposing words. They should also not be depend= ent on external resources, particularly where multiple references (e.g. Ato= m and HTML) define the same terms.

Accordingly please find attached a patch to draft-nott= ingham-http-link-header-06.xml which removes references from the regist= ry. In the alternative perhaps you would consider renaming the field to &qu= ot;Informative Reference(s)", though references to implementations &qu= ot;in the wild" would perhaps be better stored in a wiki like the WHAT= WG RelExtensions= page.

Sam

--00c09ffb55445e1baf04734f4b20-- --00c09ffb55445e1bbb04734f4b22 Content-Type: application/octet-stream; name="draft-nottingham-http-link-header-06-norefs.diff" Content-Disposition: attachment; filename="draft-nottingham-http-link-header-06-norefs.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_fzh3gfm30 MzI4ZDMyNwo8ICAgICAgICAgICAgIDx0PlJlZmVyZW5jZTogPC90PgozNDdkMzQ1CjwgICAgICAg ICAgICAgPHQ+UmVmZXJlbmNlOiA8eHJlZiB0YXJnZXQ9IlczQy5SRUMtaHRtbDQwMS0xOTk5MTIy NCIgLz48L3Q+CjM1NWQzNTIKPCAgICAgICAgICAgICA8dD5SZWZlcmVuY2U6IDx4cmVmIHRhcmdl dD0iVzNDLlJFQy1odG1sNDAxLTE5OTkxMjI0IiAvPjwvdD4KMzYzZDM1OQo8ICAgICAgICAgICAg IDx0PlJlZmVyZW5jZTogPHhyZWYgdGFyZ2V0PSJXM0MuUkVDLWh0bWw0MDEtMTk5OTEyMjQiIC8+ PC90PgozNzFkMzY2CjwgICAgICAgICAgICAgPHQ+UmVmZXJlbmNlOiA8eHJlZiB0YXJnZXQ9Ilcz Qy5SRUMtaHRtbDQwMS0xOTk5MTIyNCIgLz48L3Q+CjM3OWQzNzMKPCAgICAgICAgICAgICA8dD5S ZWZlcmVuY2U6IDx4cmVmIHRhcmdldD0iVzNDLlJFQy1odG1sNDAxLTE5OTkxMjI0IiAvPjwvdD4K Mzg3ZDM4MAo8ICAgICAgICAgICAgIDx0PlJlZmVyZW5jZTogPHhyZWYgdGFyZ2V0PSJXM0MuUkVD LWh0bWw0MDEtMTk5OTEyMjQiIC8+PC90PgozOTZkMzg4CjwgICAgICAgICAgICAgPHQ+UmVmZXJl bmNlOiA8eHJlZiB0YXJnZXQ9IlJGQzUwMDUiIC8+PC90Pgo0MTJkNDAzCjwgICAgICAgICAgICAg PHQ+UmVmZXJlbmNlOiA8eHJlZiB0YXJnZXQ9IlJGQzUwMjMiIC8+PC90Pgo0MjFkNDExCjwgICAg ICAgICAgICAgPHQ+UmVmZXJlbmNlOiA8eHJlZiB0YXJnZXQ9IlJGQzUwMjMiIC8+PC90Pgo0MzBk NDE5CjwgICAgICAgICAgICAgPHQ+UmVmZXJlbmNlOiA8eHJlZiB0YXJnZXQ9IlJGQzQyODciIC8+ PC90Pgo0MzlkNDI3CjwgICAgICAgICAgICAgPHQ+UmVmZXJlbmNlOiBbdGhpcyBkb2N1bWVudF08 L3Q+CjQ0N2Q0MzQKPCAgICAgICAgICAgICA8dD5SZWZlcmVuY2U6IDx4cmVmIHRhcmdldD0iVzND LlJFQy1odG1sNDAxLTE5OTkxMjI0IiAvPjwvdD4KNDU2ZDQ0Mgo8ICAgICAgICAgICAgIDx0PlJl ZmVyZW5jZTogPHhyZWYgdGFyZ2V0PSJXM0MuUkVDLWh0bWw0MDEtMTk5OTEyMjQiIC8+PC90Pgo0 NjRkNDQ5CjwgICAgICAgICAgICAgPHQ+UmVmZXJlbmNlOiA8eHJlZiB0YXJnZXQ9IlczQy5SRUMt aHRtbDQwMS0xOTk5MTIyNCIgLz48L3Q+CjQ3M2Q0NTcKPCAgICAgICAgICAgICA8dD5SZWZlcmVu Y2U6IFt0aGlzIGRvY3VtZW50XTwvdD4KNDgxZDQ2NAo8ICAgICAgICAgICAgIDx0PlJlZmVyZW5j ZTogPHhyZWYgdGFyZ2V0PSJSRkM0OTQ2IiAvPjwvdD4KNDg5ZDQ3MQo8ICAgICAgICAgICAgIDx0 PlJlZmVyZW5jZTogPHhyZWYgdGFyZ2V0PSJXM0MuUkVDLWh0bWw0MDEtMTk5OTEyMjQiIC8+PC90 Pgo0OTdkNDc4CjwgICAgICAgICAgICAgPHQ+UmVmZXJlbmNlOiA8eHJlZiB0YXJnZXQ9IlJGQzUw MDUiIC8+PC90Pgo1MDVkNDg1CjwgICAgICAgICAgICAgPHQ+UmVmZXJlbmNlOiBbdGhpcyBkb2N1 bWVudF08L3Q+CjUxNGQ0OTMKPCAgICAgICAgICAgICA8dD5SZWZlcmVuY2U6IDx4cmVmIHRhcmdl dD0iVzNDLlJFQy1odG1sNDAxLTE5OTkxMjI0IiAvPjwvdD4KNTIzZDUwMQo8ICAgICAgICAgICAg IDx0PlJlZmVyZW5jZTogPHhyZWYgdGFyZ2V0PSJXM0MuUkVDLWh0bWw0MDEtMTk5OTEyMjQiIC8+ PC90Pgo1MzFkNTA4CjwgICAgICAgICAgICAgPHQ+UmVmZXJlbmNlOiA8eHJlZiB0YXJnZXQ9IlJG QzUwMDUiIC8+PC90Pgo1MzlkNTE1CjwgICAgICAgICAgICAgPHQ+UmVmZXJlbmNlOiA8eHJlZiB0 YXJnZXQ9IlJGQzQyODciIC8+PC90Pgo1NDdkNTIyCjwgICAgICAgICAgICAgPHQ+UmVmZXJlbmNl OiA8eHJlZiB0YXJnZXQ9IlJGQzQ2ODUiIC8+PC90Pgo1NTVkNTI5CjwgICAgICAgICAgICAgPHQ+ UmVmZXJlbmNlOiA8eHJlZiB0YXJnZXQ9IlczQy5SRUMtaHRtbDQwMS0xOTk5MTIyNCIgLz48L3Q+ CjU2M2Q1MzYKPCAgICAgICAgICAgICA8dD5SZWZlcmVuY2U6IDx4cmVmIHRhcmdldD0iUkZDNDI4 NyIgLz48L3Q+CjU3MWQ1NDMKPCAgICAgICAgICAgICA8dD5SZWZlcmVuY2U6IDx4cmVmIHRhcmdl dD0iUkZDNTAyMyIgLz48L3Q+CjU4MWQ1NTIKPCAgICAgICAgICAgICA8dD5SZWZlcmVuY2U6IDx4 cmVmIHRhcmdldD0iVzNDLlJFQy1odG1sNDAxLTE5OTkxMjI0IiAvPjwvdD4KNTg5ZDU1OQo8ICAg ICAgICAgICAgIDx0PlJlZmVyZW5jZTogPHhyZWYgdGFyZ2V0PSJXM0MuUkVDLWh0bWw0MDEtMTk5 OTEyMjQiIC8+PC90Pgo1OThkNTY3CjwgICAgICAgICAgICAgPHQ+UmVmZXJlbmNlOiA8eHJlZiB0 YXJnZXQ9IlczQy5SRUMtaHRtbDQwMS0xOTk5MTIyNCIgLz48L3Q+CjYwNmQ1NzQKPCAgICAgICAg ICAgICA8dD5SZWZlcmVuY2U6IFt0aGlzIGRvY3VtZW50XTwvdD4KNjE1ZDU4Mgo8ICAgICAgICAg ICAgIDx0PlJlZmVyZW5jZTogPHhyZWYgdGFyZ2V0PSJSRkM0Mjg3IiAvPjwvdD4K --00c09ffb55445e1bbb04734f4b22-- From hadrien.gardeur@feedbooks.com Fri Sep 11 06:41: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 C38763A693F for ; Fri, 11 Sep 2009 06:41:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.4 X-Spam-Level: X-Spam-Status: No, score=-3.4 tagged_above=-999 required=5 tests=[AWL=-1.424, 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 qMOESaeW0m80 for ; Fri, 11 Sep 2009 06:41:43 -0700 (PDT) Received: from mail-yx0-f200.google.com (mail-yx0-f200.google.com [209.85.210.200]) by core3.amsl.com (Postfix) with ESMTP id C259B3A67D8 for ; Fri, 11 Sep 2009 06:41:42 -0700 (PDT) Received: by yxe38 with SMTP id 38so1377703yxe.6 for ; Fri, 11 Sep 2009 06:42:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.45.20 with SMTP id x20mr3267933anj.26.1252676537147; Fri, 11 Sep 2009 06:42:17 -0700 (PDT) In-Reply-To: <21606dcf0909110617y40586e53x213e5e8febc4a9e8@mail.gmail.com> References: <8860AD10-B0C5-4BEF-8C68-731973EF4046@mac.com> <30ac519d0909101631m14782ce8vd085629237b0e444@mail.gmail.com> <21606dcf0909110445s78ea728cueb158ff588f394a5@mail.gmail.com> <404dcbd20909110500j5394c43dve10264c01a7a6244@mail.gmail.com> <21606dcf0909110617y40586e53x213e5e8febc4a9e8@mail.gmail.com> From: Hadrien Gardeur Date: Fri, 11 Sep 2009 15:41:57 +0200 Message-ID: <404dcbd20909110641g131d8320rcb4f9acd828735d2@mail.gmail.com> Subject: Re: Input on request for link relation To: Sam Johnston Content-Type: multipart/alternative; boundary=001636ed6e4903e2ee04734d7c9d X-Mailman-Approved-At: Fri, 11 Sep 2009 08:56:49 -0700 Cc: apps-discuss@ietf.org, Atom-Syntax Syntax , jpanzer@acm.org, ietf-http-wg@w3.org, Jan Algermissen 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, 11 Sep 2009 13:43:54 -0000 --001636ed6e4903e2ee04734d7c9d Content-Type: text/plain; charset=UTF-8 > > Yes, though I believe Mark's "Web Linking" > draft does this already. It does (Section 6.2). > I started thinking about this earlier in the week with a view to having > e.g. a representation of a bookshelf referring to a > collection/feed/url-list/etc. of books using rel="collection". I then > started looking at parent/child/sibling relationships which are currently > being discussed in a separate thread (my preference is for something like > e.g. "rel=descendant level=2" for grandchildren as I subsequently realised > that suggested abbreviations "asc" for ascendant and "desc" for descendant > can be confused with item ordering). Do you think these "family" relations > serve all the use cases for a "collection" relation? > In AtomPub, a collection is defined as: > A Resource that contains a set of Member Resources. Collections are > represented as Atom Feeds. Collections are used to indicate where you can POST a new entry in a Service document, and what you can post is defined in app:accept: > The content of an "app:accept" element value is a media range as defined in > [RFC2616]. The media range specifies a type of representation that can be > POSTed to a Collection. In the current Web Linking draft, the edit relation is redefined (Refers to a resource that can be used to edit the link's context.) but we still lack a relation type for links where we can POST things (and we shouldn't use "collection" for this purpose). Since we can't use more than a single relation type for a link, it might be complex to define something that is both a "collection" and a resource where you can "post". --001636ed6e4903e2ee04734d7c9d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes, though I be= lieve Mark's "Web Linking" draft does thi= s already.

It does (Section 6.2).
=C2=A0
I started thinking about this earli= er in the week with a view to having e.g. a representation of a bookshelf r= eferring to a collection/feed/url-list/etc. of books using rel=3D"coll= ection". I then started looking at parent/child/sibling relationships = which are currently being discussed in a separate thread (my preference is = for something like e.g. "rel=3Ddescendant level=3D2" for grandchi= ldren as I subsequently realised that suggested abbreviations "asc&quo= t; for ascendant and "desc" for descendant can be confused with i= tem ordering). Do you think these "family" relations serve all th= e use cases for a "collection" relation?

In AtomPub, a collection is defined as:=C2= =A0
A Resource that contains a set of Member Resources. Collections are represe= nted as Atom Feeds.

Collections are used to indicate where you ca= n POST a new entry in a Service document, and what you can post is defined = in app:accept:
The content of an "app:accept" element value is a media range as = defined in [RFC2616]. The media range specifies a type of representation th= at can be POSTed to a Collection.

In the cu= rrent Web Linking draft, the edit relation is redefined (Refers to a resour= ce that can be used to edit the=C2=A0link's context.) but we still lack= a relation type for links where we can POST things (and we shouldn't u= se "collection" for this purpose).
Since we can't use more than a single relation type for a link, it= might be complex to define something that is both a "collection"= and a resource where you can "post".
--001636ed6e4903e2ee04734d7c9d-- From salvatore.loreto@ericsson.com Sat Sep 12 03:49: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 1321E3A687B; Sat, 12 Sep 2009 03:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.519 X-Spam-Level: X-Spam-Status: No, score=-5.519 tagged_above=-999 required=5 tests=[AWL=0.730, 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 PsMp9+mV+sKO; Sat, 12 Sep 2009 03:49:12 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id A2FA43A6860; Sat, 12 Sep 2009 03:49:11 -0700 (PDT) X-AuditID: c1b4fb3e-b7b2cae000005a8f-73-4aab7ccd8acf Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 0A.C9.23183.DCC7BAA4; Sat, 12 Sep 2009 12:49:49 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sat, 12 Sep 2009 12:49:48 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sat, 12 Sep 2009 12:49:48 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id A14642547; Sat, 12 Sep 2009 13:49:48 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 66BEF21A17; Sat, 12 Sep 2009 13:49:48 +0300 (EEST) Received: from localhost.localdomain (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id CDB782195C; Sat, 12 Sep 2009 13:49:47 +0300 (EEST) Message-ID: <4AAB7CCB.9010805@ericsson.com> Date: Sat, 12 Sep 2009 13:49:47 +0300 From: Salvatore Loreto User-Agent: Thunderbird 2.0.0.23 (X11/20090825) MIME-Version: 1.0 To: hybi@ietf.org, apps-discuss@ietf.org, whatwg@lists.whatwg.org, whatwg@whatwg.org Subject: HyBi BOF announcement Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 12 Sep 2009 10:49:48.0762 (UTC) FILETIME=[BFB0B3A0:01CA3396] 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: Sat, 12 Sep 2009 10:49:13 -0000 Hi, Peter Saint-Andre, Joe Hildebrand and I are organizing an HyBi BOF in Hiroshima. If you would like to participate, please join the hybi@ietf.org mailing list ( https://www.ietf.org/mailman/listinfo/hybi ). There is also a wiki page that will be update to keep all the information: http://trac.tools.ietf.org/bof/trac/wiki/HyBi We are still working on the Charter Proposal and on the Agenda so all the proposal and comments are welcome! The purpose of this BoF and eventual WG is to work on "HTTP bidirectional" communication and both its improvement and evolution in new a protocol(s) Here are the topics we are thinking to include in the charter proposal: * Characterize and describe the design space for long-poll applications * list the Requirements for new browser protocol * New browser protocol. WebSockets as a possible starting point. * at the same time, while waiting for new eventual protocol to be deployed, we envision the need to continue to improve the long-poll approach: o a suggested long-poll approach o how to improve or optimize middle-box (e.g. proxy) interoperability o Protocol bindings into the long-poll approach best regards Salvatore Loreto www.sloreto.com From maxpassion@gmail.com Tue Sep 15 11:18: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 64F243A6BEA for ; Tue, 15 Sep 2009 11:18:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.17 X-Spam-Level: X-Spam-Status: No, score=-2.17 tagged_above=-999 required=5 tests=[AWL=0.429, 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 PyCa-9eVIeVI for ; Tue, 15 Sep 2009 11:17:59 -0700 (PDT) Received: from mail-pz0-f193.google.com (mail-pz0-f193.google.com [209.85.222.193]) by core3.amsl.com (Postfix) with ESMTP id 9CB4E3A6BD2 for ; Tue, 15 Sep 2009 11:17:59 -0700 (PDT) Received: by pzk31 with SMTP id 31so3637613pzk.23 for ; Tue, 15 Sep 2009 11:18:43 -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; bh=6aEbAXV+c30pf7BE8SMeb0xvCMH1acwDx0GhHLT2QdU=; b=uIOOLbn0reV0c3pKFwWy+zDB08LN0ssx4AF5ZZ+GTglpM7sPxyKATEQRfOs29WpcrY ONaBKUo1MBSg6Xdp0Ns+1J6frtpUvCqn2ubBleihZsg0gL5gcVms3L21tLRM7XOuSj7f kRxFf9pPjEA8ptPwOiz1fwNNSh3sIeEuUOb94= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=lS2ME2Yczcwoxj54CIF/TqQ05N8JILmt3qwRMXgP+iYW55+DjHA8OqVpxJsJP1ZPRN 6Ab/e1sWqq4Owcj3B05L+rqebBU+ooN6t8GdcIEc+bjv7B+zNZlvUVACp5EVuogEG2Ft u4xRwboLokpkj4NiHhfyQnEUBrV1sWbzdjJXQ= MIME-Version: 1.0 Received: by 10.142.248.42 with SMTP id v42mr605789wfh.133.1253038717217; Tue, 15 Sep 2009 11:18:37 -0700 (PDT) Date: Wed, 16 Sep 2009 02:18:37 +0800 Message-ID: <25e1aaa40909151118x195a5ffdhe38c73d0c58902fb@mail.gmail.com> Subject: FTP behavior to avoid ALG in IPv4/IPv6 translation scenario From: liu dapeng To: apps-discuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1 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, 15 Sep 2009 18:18:00 -0000 Hello everyone: We write a draft about how FTP could avoid ALG problem in the IPv4/IPv6 translation scenario, should we have to write an RFC 2428bis to carry the work forward? blow is the link of the draft for reference: http://tools.ietf.org/html/draft-liu-behave-ftp64-03 (it was posted and discussed in Behave WG firstly, but we then realize that maybe Application area is the right place to proceed the work) BR, Dapeng liu From iljitsch@muada.com Tue Sep 15 12:54: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 3B87528C10D for ; Tue, 15 Sep 2009 12:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.163 X-Spam-Level: X-Spam-Status: No, score=-4.163 tagged_above=-999 required=5 tests=[AWL=-1.564, 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 29Ue7dsW+Lpd for ; Tue, 15 Sep 2009 12:54:46 -0700 (PDT) Received: from sequoia.muada.com (unknown [IPv6:2001:1af8:2:5::2]) by core3.amsl.com (Postfix) with ESMTP id 237003A6920 for ; Tue, 15 Sep 2009 12:54:45 -0700 (PDT) Received: from [192.168.2.11] (static-167-138-7-89.ipcom.comunitel.net [89.7.138.167] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id n8FJtOYx083712 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 15 Sep 2009 21:55:25 +0200 (CEST) (envelope-from iljitsch@muada.com) Subject: Re: FTP behavior to avoid ALG in IPv4/IPv6 translation scenario Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Iljitsch van Beijnum In-Reply-To: <25e1aaa40909151118x195a5ffdhe38c73d0c58902fb@mail.gmail.com> Date: Tue, 15 Sep 2009 21:55:23 +0200 Content-Transfer-Encoding: 7bit Message-Id: <35B5A8A8-5C64-4D43-BEE0-E130A0190E0D@muada.com> References: <25e1aaa40909151118x195a5ffdhe38c73d0c58902fb@mail.gmail.com> To: liu dapeng X-Mailer: Apple Mail (2.1076) 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, 15 Sep 2009 19:54:47 -0000 On 15 Sep 2009, at 20:18 , liu dapeng wrote: > http://tools.ietf.org/html/draft-liu-behave-ftp64-03 > (it was posted and discussed in Behave WG firstly, but we then realize > that maybe Application area is the right place to proceed the work) Some background from BEHAVE: The only major point of contention between this draft and the FTP64 draft that I presented in Stockholm (draft-van-beijnum-behave- ftp64-05) is that Liu's doesn't allow for an FTP ALG for IPv6-to-IPv4 translation. There is text in mine that describes such an ALG, but doesn't mandate its implementation, in my draft. That draft was accepted as a BEHAVE wg item in Stockholm but the chairs haven't asked for this on the mailinglist yet. The reason that I feel that the ALG text needs to be in there is that at least one vendor has said they will probably implement such an ALG, and removing text that would make such ALGs behave in a predictable way even though the text is now available seems unhelpful. However, the last word hasn't been said on this issue, I welcome any opinions. Iljitsch From mnot@mnot.net Tue Sep 15 18:21: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 F342F3A67E6 for ; Tue, 15 Sep 2009 18:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.458 X-Spam-Level: X-Spam-Status: No, score=-5.458 tagged_above=-999 required=5 tests=[AWL=-2.859, 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 Tlz7N3L9CwVz for ; Tue, 15 Sep 2009 18:21:06 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by core3.amsl.com (Postfix) with ESMTP id DFC393A635F for ; Tue, 15 Sep 2009 18:21:05 -0700 (PDT) Received: from [192.168.1.6] (unknown [118.208.246.125]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id DDAFF22E257; Tue, 15 Sep 2009 21:21:45 -0400 (EDT) Subject: Re: Input on request for link relation Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Mark Nottingham In-Reply-To: <21606dcf0909110617y40586e53x213e5e8febc4a9e8@mail.gmail.com> Date: Wed, 16 Sep 2009 11:21:42 +1000 Content-Transfer-Encoding: 7bit Message-Id: <0CB59F7B-A9DD-4866-8F70-A65869A79277@mnot.net> References: <8860AD10-B0C5-4BEF-8C68-731973EF4046@mac.com> <30ac519d0909101631m14782ce8vd085629237b0e444@mail.gmail.com> <21606dcf0909110445s78ea728cueb158ff588f394a5@mail.gmail.com> <404dcbd20909110500j5394c43dve10264c01a7a6244@mail.gmail.com> <21606dcf0909110617y40586e53x213e5e8febc4a9e8@mail.gmail.com> To: Sam Johnston X-Mailer: Apple Mail (2.1076) Cc: atom-syntax Syntax , Hadrien Gardeur , HTTP Working Group , 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, 16 Sep 2009 01:21:07 -0000 On 11/09/2009, at 11:17 PM, Sam Johnston wrote: > One nitpick about the process is that it seems a request can be > denied with a suggestion for another relation (for example we might > prefer to use something like "push" or "notif[y|ier|ication| > ications" rather than "hub" for this one) but then that would > require restarting the process where it should proceed to > registration immediately if the change is accepted by the applicant. Yes, but is the overhead really that onerous? > I also question the relevance of the "reference" field in the > registry as this links relations to implementations which I think we > agree is a bad thing - the registry should capture all the necessary > semantics without reliance on external references. It may be > interesting to list zero or more implementations of the relation > (that is, make the "reference" field optional as well and allow > others to add themselves to it), however I'm not sure the > maintenance load is worth the effort. Not to implementations, to the source documents for the registrations (which IANA likes to see in registries, AIUI, for paper trail etc). It's true that the pre-populated entries have a lot of references to formats, but that's an artefact of history, not the direction we'll move in going forward. -- Mark Nottingham http://www.mnot.net/ From samj@samj.net Wed Sep 16 02:46: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 47E2E3A69D5 for ; Wed, 16 Sep 2009 02:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.151 X-Spam-Level: X-Spam-Status: No, score=-5.151 tagged_above=-999 required=5 tests=[AWL=-3.175, 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 LS16bEx8BmoS for ; Wed, 16 Sep 2009 02:46:02 -0700 (PDT) Received: from eu1sys200aog115.obsmtp.com (eu1sys200aog115.obsmtp.com [207.126.144.139]) by core3.amsl.com (Postfix) with SMTP id ADE2D28C108 for ; Wed, 16 Sep 2009 02:46:00 -0700 (PDT) Received: from source ([209.85.220.221]) by eu1sys200aob115.postini.com ([207.126.147.11]) with SMTP ID DSNKSrC0CAacvcLHecTUZYW/e71tP1pcKmS7@postini.com; Wed, 16 Sep 2009 09:46:50 UTC Received: by fxm21 with SMTP id 21so3336203fxm.9 for ; Wed, 16 Sep 2009 02:46:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.239.182.168 with SMTP id q40mr756924hbg.139.1253094408537; Wed, 16 Sep 2009 02:46:48 -0700 (PDT) In-Reply-To: <0CB59F7B-A9DD-4866-8F70-A65869A79277@mnot.net> References: <8860AD10-B0C5-4BEF-8C68-731973EF4046@mac.com> <30ac519d0909101631m14782ce8vd085629237b0e444@mail.gmail.com> <21606dcf0909110445s78ea728cueb158ff588f394a5@mail.gmail.com> <404dcbd20909110500j5394c43dve10264c01a7a6244@mail.gmail.com> <21606dcf0909110617y40586e53x213e5e8febc4a9e8@mail.gmail.com> <0CB59F7B-A9DD-4866-8F70-A65869A79277@mnot.net> Date: Wed, 16 Sep 2009 11:46:47 +0200 Message-ID: <21606dcf0909160246i56c1dc55l43631423a542c41a@mail.gmail.com> Subject: Re: Input on request for link relation From: Sam Johnston To: Mark Nottingham Content-Type: multipart/alternative; boundary=001485f6c44e1748da0473aec7bd Cc: atom-syntax Syntax , Hadrien Gardeur , HTTP Working Group , 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, 16 Sep 2009 09:46:03 -0000 --001485f6c44e1748da0473aec7bd Content-Type: text/plain; charset=ISO-8859-1 On Wed, Sep 16, 2009 at 3:21 AM, Mark Nottingham wrote: > > On 11/09/2009, at 11:17 PM, Sam Johnston wrote: > > One nitpick about the process is that it seems a request can be denied >> with a suggestion for another relation (for example we might prefer to use >> something like "push" or "notif[y|ier|ication|ications" rather than "hub" >> for this one) but then that would require restarting the process where it >> should proceed to registration immediately if the change is accepted by the >> applicant. >> > > Yes, but is the overhead really that onerous? Perhaps not, and there could well be some delay in acceptance if committees are involved. My worry is that if we don't streamline our processes as much as possible (see Ian's suggestion about IANA maintaining a RelExtensionsstyle wiki) then people will do as they please anyway - see rel="hub", rev="canonical", etc. > I also question the relevance of the "reference" field in the registry as >> this links relations to implementations which I think we agree is a bad >> thing - the registry should capture all the necessary semantics without >> reliance on external references. It may be interesting to list zero or more >> implementations of the relation (that is, make the "reference" field >> optional as well and allow others to add themselves to it), however I'm not >> sure the maintenance load is worth the effort. >> > > Not to implementations, to the source documents for the registrations > (which IANA likes to see in registries, AIUI, for paper trail etc). > Would it be possible then to support multiple references so that people can see at a glance that a given relation is implemented as described in multiple formats (rather than just the first format that happened to register it)? May well not be worth the maintenance effort. > It's true that the pre-populated entries have a lot of references to > formats, but that's an artefact of history, not the direction we'll move in > going forward. That being the case would it be worth proactively populating the registry with common/obvious relations with a view to avoiding e.g. this "monitor" vs "hub" duplication (which is presumably burnt into various implementations on both sides)? I'm specifically thinking here about a thread from a few months ago in which we discussed different types of references to resources, with a view to getting relations like 'canonical', 'latest', 'permalink' and 'shortlink' into the registry. Perhaps a separate I-D is the best way to achieve this, Sam --001485f6c44e1748da0473aec7bd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Sep 16, 2009 at 3:21 AM, Mark Nottingham <mnot@mnot.net> wrote:

On 11/09/2009, at 11:17 PM, Sam Johnston wrote:

One nitpick about the process is that it seems a request can be denied with= a suggestion for another relation (for example we might prefer to use some= thing like "push" or "notif[y|ier|ication|ications" rat= her than "hub" for this one) but then that would require restarti= ng the process where it should proceed to registration immediately if the c= hange is accepted by the applicant.

Yes, but is the overhead really that onerous?

Perhaps not, and there could well be some delay in acceptance if committ= ees are involved. My worry is that if we don't streamline our processes= as much as possible (see Ian's suggestion about IANA maintaining a RelExtensions style = wiki) then people will do as they please anyway - see rel=3D"hub"= , rev=3D"canonical", etc.
=A0
I also question the relevance of the "reference" field in the reg= istry as this links relations to implementations which I think we agree is = a bad thing - the registry should capture all the necessary semantics witho= ut reliance on external references. It may be interesting to list zero or m= ore implementations of the relation (that is, make the "reference"= ; field optional as well and allow others to add themselves to it), however= I'm not sure the maintenance load is worth the effort.

Not to implementations, to the source documents for the registrations (whic= h IANA likes to see in registries, AIUI, for paper trail etc).

Would it be possible then to support multiple refer= ences so that people can see at a glance that a given relation is implement= ed as described in multiple formats (rather than just the first format that= happened to register it)? May well not be worth the maintenance effort.
=A0
It's true that the pre-populated entries have a lot of references to fo= rmats, but that's an artefact of history, not the direction we'll m= ove in going forward.

That being the case w= ould it be worth proactively populating the registry with common/obvious re= lations with a view to avoiding e.g. this "monitor" vs "hub&= quot; duplication (which is presumably burnt into various implementations o= n both sides)?

I'm specifically thinking here about a thread from = a few months ago in which we discussed different types of references to res= ources, with a view to getting relations like 'canonical', 'lat= est', 'permalink' and 'shortlink' into the registry. Pe= rhaps a separate I-D is the best way to achieve this,

Sam

--001485f6c44e1748da0473aec7bd-- From al@akc.com Wed Sep 16 06:12: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 EC6F53A6A1A for ; Wed, 16 Sep 2009 06:12:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=0.434, 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 SvOxOtb6-HUM for ; Wed, 16 Sep 2009 06:12:11 -0700 (PDT) Received: from imail.akc.com (imail.akc.com [192.188.192.3]) by core3.amsl.com (Postfix) with ESMTP id D37FF3A6A14 for ; Wed, 16 Sep 2009 06:12:10 -0700 (PDT) Received: from upstairs (upstairs.akc.com [64.253.39.242]) by imail.akc.com with SMTP; Wed, 16 Sep 2009 09:12:49 -0400 Message-ID: <002b01ca36d7$b6b2f350$3c01a8c0@upstairs> From: "Al Costanzo" To: "Iljitsch van Beijnum" References: <25e1aaa40909151118x195a5ffdhe38c73d0c58902fb@mail.gmail.com> <35B5A8A8-5C64-4D43-BEE0-E130A0190E0D@muada.com> Subject: Re: FTP behavior to avoid ALG in IPv4/IPv6 translation scenario Date: Wed, 16 Sep 2009 09:12:21 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3598 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Al Costanzo List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2009 13:12:12 -0000 My two cents Iljitsch, >From previous discussions with Jon Postel ("the" RFC editor) years ago when I was working on RFC1505. he discussed the fact that if a vendor is interested in something, it is the IETF role to write the documentation even if there is a standards track document that does the same thing using a different methodology. I have never forgotten this and 1505 was introduced as an experimential RFC even though MIME had its foothold as standards track documents at the time. I state this because I personally feel that IMHO, it is better to state something then to leave it to vendor interpretation. Because of vendor interpretation we are still stuck to this date with the useless line: "MIME-Version: 1.0" in every email. Lets try to not repeat from mistakes from the past, mandate: "FTP ALG for IPv6-to-IPv4" don't leave it to the decision of the vendor, the IETF always should provide guidance. and remember that if you decide to place a version number in the coversion don't force it to stay "1.0" because of something you forgot to state in the RFC. Take this lesson from MIME's error. Regards, Al Costanzo > translation ----- Original Message ----- From: "Iljitsch van Beijnum" To: "liu dapeng" Cc: Sent: Tuesday, September 15, 2009 2:55 PM Subject: Re: FTP behavior to avoid ALG in IPv4/IPv6 translation scenario > On 15 Sep 2009, at 20:18 , liu dapeng wrote: > >> http://tools.ietf.org/html/draft-liu-behave-ftp64-03 > >> (it was posted and discussed in Behave WG firstly, but we then realize >> that maybe Application area is the right place to proceed the work) > > Some background from BEHAVE: > > The only major point of contention between this draft and the FTP64 draft > that I presented in Stockholm (draft-van-beijnum-behave- ftp64-05) is that > Liu's doesn't allow for an FTP ALG for IPv6-to-IPv4 translation. There is > text in mine that describes such an ALG, but doesn't mandate its > implementation, in my draft. That draft was accepted as a BEHAVE wg item > in Stockholm but the chairs haven't asked for this on the mailinglist > yet. > > The reason that I feel that the ALG text needs to be in there is that at > least one vendor has said they will probably implement such an ALG, and > removing text that would make such ALGs behave in a predictable way even > though the text is now available seems unhelpful. > > However, the last word hasn't been said on this issue, I welcome any > opinions. > > Iljitsch > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From eran@hueniverse.com Wed Sep 16 19:18: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 506F23A6B10 for ; Wed, 16 Sep 2009 19:18:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.48 X-Spam-Level: X-Spam-Status: No, score=-4.48 tagged_above=-999 required=5 tests=[AWL=-1.881, 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 ZqyGcpUaERQ4 for ; Wed, 16 Sep 2009 19:18:28 -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 7F6AD3A6B05 for ; Wed, 16 Sep 2009 19:18:28 -0700 (PDT) Received: (qmail 3483 invoked from network); 17 Sep 2009 02:19:17 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 17 Sep 2009 02:19:17 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Wed, 16 Sep 2009 19:17:08 -0700 From: Eran Hammer-Lahav To: Sam Johnston Date: Wed, 16 Sep 2009 19:19:29 -0700 Subject: RE: Input on request for link relation Thread-Topic: Input on request for link relation Thread-Index: Aco2sq5alXTGPt/UQIW8qn7kn8l9bwAigGDw Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343784D57E6A@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <8860AD10-B0C5-4BEF-8C68-731973EF4046@mac.com> <30ac519d0909101631m14782ce8vd085629237b0e444@mail.gmail.com> <21606dcf0909110445s78ea728cueb158ff588f394a5@mail.gmail.com> <404dcbd20909110500j5394c43dve10264c01a7a6244@mail.gmail.com> <21606dcf0909110617y40586e53x213e5e8febc4a9e8@mail.gmail.com> <0CB59F7B-A9DD-4866-8F70-A65869A79277@mnot.net> <21606dcf0909160246i56c1dc55l43631423a542c41a@mail.gmail.com> In-Reply-To: <21606dcf0909160246i56c1dc55l43631423a542c41a@mail.gmail.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: atom-syntax Syntax , HTTP Working Group , "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, 17 Sep 2009 02:18:29 -0000 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > bounces@ietf.org] On Behalf Of Sam Johnston > Sent: Wednesday, September 16, 2009 2:47 AM > To: Mark Nottingham > Cc: atom-syntax Syntax; Hadrien Gardeur; HTTP Working Group; apps- > discuss@ietf.org > Subject: Re: Input on request for link relation >=20 > On Wed, Sep 16, 2009 at 3:21 AM, Mark Nottingham wrote: >=20 > On 11/09/2009, at 11:17 PM, Sam Johnston wrote: > One nitpick about the process is that it seems a request can be denied > with a suggestion for another relation (for example we might prefer to > use something like "push" or "notif[y|ier|ication|ications" rather than > "hub" for this one) but then that would require restarting the process > where it should proceed to registration immediately if the change is > accepted by the applicant. >=20 > Yes, but is the overhead really that onerous? >=20 > Perhaps not, and there could well be some delay in acceptance if > committees are involved. My worry is that if we don't streamline our > processes as much as possible (see Ian's suggestion about IANA > maintaining a RelExtensions style wiki) then people will do as they > please anyway - see rel=3D"hub", rev=3D"canonical", etc. I am sure there will be those that even something as "simple" as wiki will = be deemed too much effort. The delay is usually not with the registry but w= ith getting consensus. The longer it take to build consensus is usually an = indication of issues with the request to take a common term and assign it t= o a particular use case. EHL From mnot@mnot.net Wed Sep 16 23:25: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 6D47D3A6B4E for ; Wed, 16 Sep 2009 23:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.511 X-Spam-Level: X-Spam-Status: No, score=-5.511 tagged_above=-999 required=5 tests=[AWL=-2.912, 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 VedGWafojTwB for ; Wed, 16 Sep 2009 23:25:32 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by core3.amsl.com (Postfix) with ESMTP id 3946C3A6B10 for ; Wed, 16 Sep 2009 23:25:32 -0700 (PDT) Received: from [192.168.1.6] (unknown [118.208.246.125]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 6FF3522E1F3; Thu, 17 Sep 2009 02:26:15 -0400 (EDT) Subject: Re: Input on request for link relation Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Mark Nottingham In-Reply-To: <21606dcf0909160246i56c1dc55l43631423a542c41a@mail.gmail.com> Date: Thu, 17 Sep 2009 16:26:11 +1000 Content-Transfer-Encoding: 7bit Message-Id: <2B6D770A-58C5-48D6-AF52-7341812C9BFA@mnot.net> References: <8860AD10-B0C5-4BEF-8C68-731973EF4046@mac.com> <30ac519d0909101631m14782ce8vd085629237b0e444@mail.gmail.com> <21606dcf0909110445s78ea728cueb158ff588f394a5@mail.gmail.com> <404dcbd20909110500j5394c43dve10264c01a7a6244@mail.gmail.com> <21606dcf0909110617y40586e53x213e5e8febc4a9e8@mail.gmail.com> <0CB59F7B-A9DD-4866-8F70-A65869A79277@mnot.net> <21606dcf0909160246i56c1dc55l43631423a542c41a@mail.gmail.com> To: Sam Johnston X-Mailer: Apple Mail (2.1076) Cc: Atom-Syntax Syntax , Hadrien Gardeur , Ian Hickson , HTTP Working Group , 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, 17 Sep 2009 06:25:33 -0000 On 16/09/2009, at 7:46 PM, Sam Johnston wrote: > On Wed, Sep 16, 2009 at 3:21 AM, Mark Nottingham > wrote: > > On 11/09/2009, at 11:17 PM, Sam Johnston wrote: > > One nitpick about the process is that it seems a request can be > denied with a suggestion for another relation (for example we might > prefer to use something like "push" or "notif[y|ier|ication| > ications" rather than "hub" for this one) but then that would > require restarting the process where it should proceed to > registration immediately if the change is accepted by the applicant. > > Yes, but is the overhead really that onerous? > > Perhaps not, and there could well be some delay in acceptance if > committees are involved. My worry is that if we don't streamline our > processes as much as possible (see Ian's suggestion about IANA > maintaining a RelExtensions style wiki) then people will do as they > please anyway - see rel="hub", rev="canonical", etc. Interesting examples; the "hub" people are actively engaging (finally), and I've already talked to some of the "canonical" folks about doing an I-D once the Link draft is an RFC. > Would it be possible then to support multiple references so that > people can see at a glance that a given relation is implemented as > described in multiple formats (rather than just the first format > that happened to register it)? May well not be worth the maintenance > effort. How about adding a new field for references to more information about how a relation is used in a particular context (scoped by context media type)? E.g., References regarding use in specific contexts: text/html: [HTML5] application/atom+xml: [RFC4287] One concern here is that there are going to be questions about authority; while it's fine for the HTML5 crowd to dictate what happens when you see a particular relation in an HTML context, what happens when someone comes along and defines a spec for a media type they don't own? We'd need some additional guidance about amending registrations, I think, which is doable, but it'll make things more complex. What do people think about this generally? Ian, would this help you at all? We'd still need a generic 'reference' field for the defining document of the relation itself, but in some cases the current references would change to be context references; e.g., Relation Name: chapter Description: Refers to a chapter in a collection of resources. Reference: [this specification] References regarding use in specific contexts: text/html: [W3C.REC-html401-19991224] -- Mark Nottingham http://www.mnot.net/ From mnot@mnot.net Wed Sep 16 23:59: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 95A2B28C181 for ; Wed, 16 Sep 2009 23:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.448 X-Spam-Level: X-Spam-Status: No, score=-5.448 tagged_above=-999 required=5 tests=[AWL=-2.849, 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 PRAETcziiv0J for ; Wed, 16 Sep 2009 23:58:59 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by core3.amsl.com (Postfix) with ESMTP id A4DBB28C1A6 for ; Wed, 16 Sep 2009 23:58:44 -0700 (PDT) Received: from [192.168.1.6] (unknown [118.208.246.125]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 4196422E257; Thu, 17 Sep 2009 02:59:28 -0400 (EDT) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Mime-Version: 1.0 (Apple Message framework v1076) Subject: Fwd: New Version Notification for draft-nottingham-site-meta-03 From: Mark Nottingham Date: Thu, 17 Sep 2009 16:59:26 +1000 Content-Transfer-Encoding: 7bit Message-Id: <0745006F-CE26-4E8F-A67D-32BED74D7E15@mnot.net> References: <20090917065629.BBC103A682A@core3.amsl.com> To: Apps Discuss X-Mailer: Apple Mail (2.1076) Cc: "www-tag@w3.org WG" 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, 17 Sep 2009 06:59:00 -0000 See: http://www.ietf.org/id/draft-nottingham-site-meta-03.txt and diff at: http://bit.ly/2WpmJI Begin forwarded message: > From: IETF I-D Submission Tool > Date: 17 September 2009 4:56:29 PM AEST > To: mnot@mnot.net > Cc: eran@hueniverse.com > Subject: New Version Notification for draft-nottingham-site-meta-03 > > > A new version of I-D, draft-nottingham-site-meta-03.txt has been > successfuly submitted by Mark Nottingham and posted to the IETF > repository. > > Filename: draft-nottingham-site-meta > Revision: 03 > Title: Defining Well-Known URIs > Creation_date: 2009-09-17 > WG ID: Independent Submission > Number_of_pages: 8 > > Abstract: > This memo defines a path prefix for "well-known locations" in URIs. > > > > The IETF Secretariat. > > -- Mark Nottingham http://www.mnot.net/ From bil@corry.biz Thu Sep 17 05:25: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 017593A6AD2 for ; Thu, 17 Sep 2009 05:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[AWL=-1.183, BAYES_40=-0.185, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] 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 gJMAd3a0Cuuq for ; Thu, 17 Sep 2009 05:25:00 -0700 (PDT) Received: from mail.mindio.com (app1.bc.anu.net [193.189.141.126]) by core3.amsl.com (Postfix) with ESMTP id 3CA113A69F3 for ; Thu, 17 Sep 2009 05:24:59 -0700 (PDT) Received: from [127.0.0.1] (unknown [98.212.72.151]) by mail.mindio.com (Postfix) with ESMTP id 710F3FCF38; Thu, 17 Sep 2009 07:25:49 -0500 (CDT) Message-ID: <4AB22AC7.5050704@corry.biz> Date: Thu, 17 Sep 2009 07:25:43 -0500 From: Bil Corry User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Mark Nottingham Subject: Re: Fwd: New Version Notification for draft-nottingham-site-meta-03 References: <20090917065629.BBC103A682A@core3.amsl.com> <0745006F-CE26-4E8F-A67D-32BED74D7E15@mnot.net> In-Reply-To: <0745006F-CE26-4E8F-A67D-32BED74D7E15@mnot.net> X-Enigmail-Version: 0.96.0 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: Thu, 17 Sep 2009 12:25:01 -0000 Mark Nottingham wrote on 9/17/2009 1:59 AM: > See: > http://www.ietf.org/id/draft-nottingham-site-meta-03.txt >From the above: ---8<--- A well-known URI is a URI [RFC3986] whose path component begins with the characters "/.well-known/". --->8--- I know for my own server, any file or directory within the path component that begins with a period or underscore returns 403. That's to prevent serving .htaccess, .svn, .project, ._.DS_Store, __MACOSX, and other configuration-type files and directories -- leading periods and underscores seem to be popular for them. I can add an exception for "/.well-known/", but wanted to mention it in case there were other alternatives being considered for the path component. - Bil From julian.reschke@gmx.de Thu Sep 17 05:33: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 69FE03A68B7 for ; Thu, 17 Sep 2009 05:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.594 X-Spam-Level: X-Spam-Status: No, score=-4.594 tagged_above=-999 required=5 tests=[AWL=-1.995, 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 AFVlYB2yISDa for ; Thu, 17 Sep 2009 05:33:47 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 3FEEC3A6925 for ; Thu, 17 Sep 2009 05:33:46 -0700 (PDT) Received: (qmail invoked by alias); 17 Sep 2009 12:34:37 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.117]) [217.91.35.233] by mail.gmx.net (mp027) with SMTP; 17 Sep 2009 14:34:37 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/ZH293ICzZt9biQ4JlvBL9HLqkFiMY4RybAQGmQZ dJMV1AzDsrZ0XJ Message-ID: <4AB22CC7.10607@gmx.de> Date: Thu, 17 Sep 2009 14:34:15 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Bil Corry Subject: Re: Fwd: New Version Notification for draft-nottingham-site-meta-03 References: <20090917065629.BBC103A682A@core3.amsl.com> <0745006F-CE26-4E8F-A67D-32BED74D7E15@mnot.net> <4AB22AC7.5050704@corry.biz> In-Reply-To: <4AB22AC7.5050704@corry.biz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.6 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: Thu, 17 Sep 2009 12:33:48 -0000 Bil Corry wrote: > Mark Nottingham wrote on 9/17/2009 1:59 AM: >> See: >> http://www.ietf.org/id/draft-nottingham-site-meta-03.txt > >> >From the above: > > ---8<--- > A well-known URI is a URI [RFC3986] whose path component begins with > the characters "/.well-known/". > --->8--- > > I know for my own server, any file or directory within the path component that begins with a period or underscore returns 403. That's to prevent serving .htaccess, .svn, .project, ._.DS_Store, __MACOSX, and other configuration-type files and directories -- leading periods and underscores seem to be popular for them. I can add an exception for "/.well-known/", but wanted to mention it in case there were other alternatives being considered for the path component. > ... I think that's actually a strong point *in favor* of using a leading dot (less chance for overlap with real-world URIs). BR, Julian From eran@hueniverse.com Thu Sep 17 08:59: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 F375B3A696E for ; Thu, 17 Sep 2009 08:59:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.58 X-Spam-Level: X-Spam-Status: No, score=-4.58 tagged_above=-999 required=5 tests=[AWL=-1.981, 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 wzl-wjj+a0Az for ; Thu, 17 Sep 2009 08:59:16 -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 575683A6A9C for ; Thu, 17 Sep 2009 08:59:01 -0700 (PDT) Received: (qmail 24437 invoked from network); 17 Sep 2009 15:59:53 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 17 Sep 2009 15:59:53 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 17 Sep 2009 08:56:54 -0700 From: Eran Hammer-Lahav To: Julian Reschke , Bil Corry Date: Thu, 17 Sep 2009 08:57:30 -0700 Subject: RE: Fwd: New Version Notification for draft-nottingham-site-meta-03 Thread-Topic: Fwd: New Version Notification for draft-nottingham-site-meta-03 Thread-Index: Aco3kz82Lh1tjFGpT0afcTxm+4oiWQAG/OyA Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343784D57F09@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <20090917065629.BBC103A682A@core3.amsl.com> <0745006F-CE26-4E8F-A67D-32BED74D7E15@mnot.net> <4AB22AC7.5050704@corry.biz> <4AB22CC7.10607@gmx.de> In-Reply-To: <4AB22CC7.10607@gmx.de> 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 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, 17 Sep 2009 15:59:18 -0000 Exactly. The fact that it takes more steps to enable /.well-known/ is in line with o= ur goal of using a non-obvious path that is usually not permitted as part o= f usernames in social networks and other sites. But thanks for pointing this out as it will help us get more adoption by le= tting people know to check for such restrictions. EHL > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > bounces@ietf.org] On Behalf Of Julian Reschke > Sent: Thursday, September 17, 2009 5:34 AM > To: Bil Corry > Cc: Apps Discuss > Subject: Re: Fwd: New Version Notification for draft-nottingham-site- > meta-03 >=20 > Bil Corry wrote: > > Mark Nottingham wrote on 9/17/2009 1:59 AM: > >> See: > >> http://www.ietf.org/id/draft-nottingham-site-meta-03.txt > > > >> >From the above: > > > > ---8<--- > > A well-known URI is a URI [RFC3986] whose path component begins with > > the characters "/.well-known/". > > --->8--- > > > > I know for my own server, any file or directory within the path > component that begins with a period or underscore returns 403. That's > to prevent serving .htaccess, .svn, .project, ._.DS_Store, __MACOSX, > and other configuration-type files and directories -- leading periods > and underscores seem to be popular for them. I can add an exception > for "/.well-known/", but wanted to mention it in case there were other > alternatives being considered for the path component. > > ... >=20 > I think that's actually a strong point *in favor* of using a leading > dot > (less chance for overlap with real-world URIs). >=20 > BR, Julian > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From lear@cisco.com Fri Sep 18 08:37: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 4CE6B28C18E for ; Fri, 18 Sep 2009 08:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.272 X-Spam-Level: X-Spam-Status: No, score=-10.272 tagged_above=-999 required=5 tests=[AWL=0.327, 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 NLCT4JGkFc7E for ; Fri, 18 Sep 2009 08:37:50 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id BE3D53A67E4 for ; Fri, 18 Sep 2009 08:37:49 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlsAAABGs0qQ/uCKe2dsb2JhbACBUplRAQEWJAabDIhQAZAdBYQcgV2CdA X-IronPort-AV: E=Sophos;i="4.44,410,1249257600"; d="scan'208";a="49724365" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 18 Sep 2009 15:37:41 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n8IFbfrI028672; Fri, 18 Sep 2009 17:37:41 +0200 Received: from elear-mac.local (dhcp-10-61-110-163.cisco.com [10.61.110.163]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n8IFbfcw004775; Fri, 18 Sep 2009 15:37:41 GMT Message-ID: <4AB3A945.4060000@cisco.com> Date: Fri, 18 Sep 2009 17:37:41 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 MIME-Version: 1.0 To: Julian Reschke Subject: Re: [ietf-calsify] Call for feedback on HTML5 spec on "predefined vocabularies" References: <4A8010B3.1050100@gmx.de> In-Reply-To: <4A8010B3.1050100@gmx.de> X-Enigmail-Version: 0.97a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2833; t=1253288261; x=1254152261; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[ietf-calsify]=20Call=20for=20feedback= 20on=20HTML5=20spec=20on=20=22predefined=0A=20vocabularies=2 2 |Sender:=20; bh=/vBOqLUtbvvqxbxgef2gS6g1EZxfWjwZ0uXlc/O6F6A=; b=JJuicorrViNw83S2VoasBfBrGnDi4r70dHAyhRG4s2aY1aGF14ML+iOV46 BthyQ13bje7X4NtfjPucP2LatJlaCZ482mtN6s3/FhEqaXUOxM/RZoZbjEUC +6max4MgmH; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: Apps Discuss , Calsify , CardDAV 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, 18 Sep 2009 15:37:50 -0000 Dear all, I recently had a thread with Julian in which he feels pretty strongly about the below message regarding HTML5, and the vocabulary for calendaring that is proposed. I suggest that people who are interested review the proposed specification below and comment either on one of these lists or to Julian directly. Eliot On 8/10/09 2:21 PM, Julian Reschke wrote: > Hi, > > (cross-posted to IETF apps-discuss, plus vcarddav and calsify mailing lists) > > the W3C HTML Working Group is currently preparing a new Working Draft > for HTML5. This will be based on the current Editor's Draft at > ). > > A significant change since the last Working Draft is the introduction of > "microdata", a way to augment the markup with semantics, similar to and > competing with RDFa and microformats in general (see > ). > > As part of introducing microdata, the spec also defines several > "predefined vocabularies". Some of them are based on IETF formats (and > this is why I'm writing this particular email). > > One of these vocabularies is "vcard" (see > ). As far as I can > tell, the HTML spec more or less duplicates information from RFC 2426, > and while doing so also introduces specific compliance criteria. It does > *not* refer to > , so, as far > as I can tell, it would hardwire the vocabulary to a soon-to-be-outdated > version of the spec, and also removes the inherent extensibility model. > > Another predefined vocabulary is "vevent" (see > ), to which similar > observations apply. > > I have talked to this to many W3C and IETF people, and as far as I can > tell, almost all of them consider this to be a Bad Idea. In particular, > it seems that the author has not even tried to co-ordinate with the two > applicable IETF Working Groups (I just checked the mailing list > archives, and couldn't find anything, but maybe I'm missing something). > > I'm not sure whether the two working groups have considered this issue > yet. I encourage to look at the spec now > (), or as soon as a new > Working Draft is published. > > In case the Calsify and/or Vcarddav Working Groups want to comment on > this, I encourage the chairs to send feedback directly to the W3C HTML > WG, so that the feedback gets the proper attention. > > Best regards, Julian > > _______________________________________________ > ietf-calsify mailing list > ietf-calsify@osafoundation.org > http://lists.osafoundation.org/mailman/listinfo/ietf-calsify > > From msk@cloudmark.com Mon Sep 21 10:19: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 4AF5928C1CD for ; Mon, 21 Sep 2009 10:19:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.885 X-Spam-Level: X-Spam-Status: No, score=-0.885 tagged_above=-999 required=5 tests=[AWL=-0.984, BAYES_00=-2.599, FRT_POSSIBLE=2.697, 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 mSL7MqNxIb5g for ; Mon, 21 Sep 2009 10:19:00 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by core3.amsl.com (Postfix) with ESMTP id 3E6B53A68F6 for ; Mon, 21 Sep 2009 10:19:00 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.1.71]) with mapi; Mon, 21 Sep 2009 10:20:01 -0700 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Date: Mon, 21 Sep 2009 10:20:01 -0700 Subject: Proposed (updated) ARF WG charter Thread-Topic: Proposed (updated) ARF WG charter Thread-Index: Aco634T7S5F8TEkaRa2V/+NKKj0EwQAADQ2Q Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_004_BB012BD379D7B046ABE1472D8093C61C01AFA26F6AEXCHC2corpclo_" 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: Mon, 21 Sep 2009 17:19:01 -0000 --_004_BB012BD379D7B046ABE1472D8093C61C01AFA26F6AEXCHC2corpclo_ Content-Type: multipart/alternative; boundary="_000_BB012BD379D7B046ABE1472D8093C61C01AFA26F6AEXCHC2corpclo_" --_000_BB012BD379D7B046ABE1472D8093C61C01AFA26F6AEXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ARF, or Abuse Report Format, is an email message format similar to DSNs dev= eloped by ESPs and ISPs outside of the IETF. It is intended to be used by = service providers to automate the reporting of various kinds of messaging a= buse. Interested parties are seeking to create an IETF working group to su= bject the current proposal to the review and other rigorous processes the I= ETF brings to bear to promote interoperability and adoption. The current draft charter is attached. If you would be interested in parti= cipating in such a working group or have comments on the charter, please re= spond here or (preferably) on the current ARF mailing list, available via h= ttp://mipassoc.org/mailman/listinfo/abuse-feedback-report. -MSK --_000_BB012BD379D7B046ABE1472D8093C61C01AFA26F6AEXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

ARF, or Abuse Report Format, is an email message forma= t similar to DSNs developed by ESPs and ISPs outside of the IETF.  It is intended to be used by service providers to automate the reporting of vario= us kinds of messaging abuse.  Interested parties are seeking to create an IETF working group to subject the current proposal to the review and other rigorous processes the IETF brings to bear to promote interoperability and adoption.

 

The current draft charter is attached.  If you wo= uld be interested in participating in such a working group or have comments on the charter, please respond here or (preferably) on the current ARF mailing lis= t, available via http://= mipassoc.org/mailman/listinfo/abuse-feedback-report.

 

-MSK

 

--_000_BB012BD379D7B046ABE1472D8093C61C01AFA26F6AEXCHC2corpclo_-- --_004_BB012BD379D7B046ABE1472D8093C61C01AFA26F6AEXCHC2corpclo_ Content-Type: text/plain; name="arf-charter v05.txt" Content-Description: arf-charter v05.txt Content-Disposition: attachment; filename="arf-charter v05.txt"; size=5597; creation-date="Fri, 18 Sep 2009 09:50:14 GMT"; modification-date="Fri, 18 Sep 2009 12:17:33 GMT" Content-Transfer-Encoding: base64 ICAgV29ya2luZyBHcm91cCBOYW1lOg0KICAgICAgICBBYnVzZSBSZXBvcnRpbmcgRm9ybWF0IChB UkYpDQoNCiAgIElFVEYgQXJlYToNCiAgICAgICAgQXBwbGljYXRpb25zIEFyZWENCg0KICAgQ2hh aXIocyk6DQogICAgICAgIFRCRA0KDQogICBBcHBsaWNhdGlvbnMgQXJlYSBEaXJlY3RvcihzKToN CiAgICAgICAgTGlzYSBEdXNzZWF1bHQgPExpc2EuRHVzc2VhdWx0QG1lc3NhZ2luZ2FyY2hpdGVj dHMuY29tPg0KICAgICAgICBBbGV4ZXkgTWVsbmlrb3YgPGFsZXhleS5tZWxuaWtvdkBpc29kZS5j b20+DQoNCiAgIFJlc3BvbnNpYmxlIEFyZWEgRGlyZWN0b3I6DQogICAgICAgIFRCRA0KDQogICBN YWlsaW5nIExpc3RzOg0KICAgICAgICBHZW5lcmFsIERpc2N1c3Npb246IGFidXNlLWZlZWRiYWNr LXJlcG9ydEBtaXBhc3NvYy5vcmcNCiAgICAgICAgVG8gU3Vic2NyaWJlOiBodHRwOi8vbWlwYXNz b2Mub3JnL21haWxtYW4vbGlzdGluZm8vYWJ1c2UtZmVlZGJhY2stcmVwb3J0DQogICAgICAgIEFy Y2hpdmU6IGh0dHA6Ly9taXBhc3NvYy5vcmcvbWFpbG1hbi9saXN0aW5mby9hYnVzZS1mZWVkYmFj ay1yZXBvcnQNCg0KICAgRGVzY3JpcHRpb24gb2YgV29ya2luZyBHcm91cDoNCglNZXNzYWdpbmcg YW50aS1hYnVzZSBvcGVyYXRpb25zIGJldHdlZW4gaW5kZXBlbmRlbnQgc2VydmljZXMgb2Z0ZW4g cmVxdWlyZXMNCglzZW5kaW5nIHJlcG9ydHMgb24gb2JzZXJ2ZWQgZnJhdWQsIHNwYW0gdmlydXMg b3Igb3RoZXIgYWJ1c2UgYWN0aXZpdHkuICBBDQoJc3RhbmRhcmRpemVkIHJlcG9ydCBmb3JtYXQg ZW5hYmxlcyBhdXRvbWF0ZWQgcHJvY2Vzc2luZy4gIFRoZSBBYnVzZSBSZXBvcnRpbmcNCglGb3Jt YXQgKEFSRikgc3BlY2lmaWNhdGlvbiBoYXMgZ2FpbmVkIHN1ZmZpY2llbnQgcG9wdWxhcml0eSB0 byB3YXJyYW50IGZvcm1hbA0KCWNvZGlmaWNhdGlvbiwgdG8gZW5zdXJlIGFuZCBlbmNvdXJhZ2Ug ZnV0dXJlIGludGVyb3BlcmFiaWxpdHkgd2l0aCBuZXcNCglpbXBsZW1lbnRhdGlvbnMuICBUaGUg cHJpbWFyeSBmdW5jdGlvbiBvZiB0aGlzIHdvcmtpbmcgZ3JvdXAgd2lsbCBiZSB0byBzb2xpY2l0 DQoJcmV2aWV3IGFuZCByZWZpbmVtZW50IG9mIHRoZSBleGlzdGluZyBzcGVjaWZpY2F0aW9uLg0K DQoJQVJGIHdhcyBkZXZlbG9wZWQgYnkgYSBtZXNzYWdpbmcgdHJhZGUgb3JnYW5pemF0aW9uIGlu ZGVwZW5kZW50IG9mIHRoZSBJRVRGLA0KCWFuZCB1c2VzIGEgZm9ybWF0IHNpbWlsYXIgdG8gYSBE ZWxpdmVyeSBTdGF0dXMgTm90aWZpY2F0aW9uIChEU04sIFJGQzM0NjQpDQoJdG8gcmVwb3J0IGZy YXVkLCBzcGFtLCB2aXJ1c2VzIG9yIG90aGVyIGFidXNpdmUgYWN0aXZpdHkgaW4gdGhlIGVtYWls IHN5c3RlbS4NCglUaGUgYmFzaWMgZm9ybWF0IGlzIGFtZW5hYmxlIHRvIHByb2Nlc3NpbmcgYnkg aHVtYW5zIG9yIHNvZnR3YXJlLCB3aXRoIHRoZQ0KCWxhdHRlciByZXF1aXJpbmcgdGhlIGZvcm1h dCB0byBiZSBzdGFuZGFyZGl6ZWQsIHRvIHBlcm1pdCBpbnRlcm9wZXJhYmlsaXR5DQoJYmV0d2Vl biBhdXRvbWF0ZWQgc2VydmljZXMsIHBhcnRpY3VsYXJseSB3aXRob3V0IHByaW9yIGFycmFuZ2Vt ZW50Lg0KDQoJQVJGIGFzIGluaXRpYWxseSBkZWZpbmVkIGlzIGFscmVhZHkgaW4gd2lkZXNwcmVh ZCB1c2UgYXQgbGFyZ2UgSVNQcywgc28NCglpbnRlcm9wZXJhYmlsaXR5IGNhbiBiZSBkZW1vbnN0 cmF0ZWQuICBTb21lIHRvb2xzIGFscmVhZHkgZXhpc3QNCglmb3IgcHJvY2Vzc2luZyBBUkYgbWVz c2FnZXMsIGEgZmV3IG9mIHdoaWNoIGFyZSBvcGVuIHNvdXJjZS4gIEluIG9yZGVyIHRvDQoJcHJl c2VydmUgdGhlIGluc3RhbGxlZCBiYXNlLCB0aGUgd29ya2luZyBncm91cCB3aWxsIG1ha2UgdGhl IG1pbmltdW0gY2hhbmdlcw0KCW5lY2Vzc2FyeSB0byB0aGUgZXhpc3Rpbmcgc3BlY2lmaWNhdGlv biBhbmQgd2lsbCBzZWVrIHRvIGhhdmUgYmFja3dhcmQNCgljb21wYXRpYmlsaXR5LiAgRnVydGhl cm1vcmUsIHNvbWUgZXh0ZW5zaW9ucyB0byB0aGUgY3VycmVudCBwcm9wb3NhbCBhcmUNCglvZiBp bnRlcmVzdCB0byB0aGUgY29tbXVuaXR5LCBzdWNoIGFzIHRoZSBtZWFucyBmb3IgYW4gb3BlcmF0 b3IgdG8gYWR2ZXJ0aXNlDQoJYW4gZW1haWwgYWRkcmVzcyB0byB3aGljaCBhYnVzZSByZXBvcnRz IHVzaW5nIEFSRiBzaG91bGQgYmUgc2VudC4gIFRoZQ0KCXdvcmtpbmcgZ3JvdXAgd2lsbCB0YWtl IG9uIHRoZSB0YXNrIG9mIGNvbnNpZGVyaW5nIGFuZCBzcGVjaWZ5aW5nIHN1Y2ggYSBtZWNoYW5p c20uDQoNCglUaGUgaW5pdGlhbCBwcm9wb3NhbCBpcyBwdWJsaXNoZWQgYXMgZHJhZnQtc2hhZnJh bm92aWNoLWZlZWRiYWNrLXJlcG9ydCwNCglhbmQgdGhpcyB3aWxsIHByb3ZpZGUgdGhlIHdvcmtp bmcgZ3JvdXAncyBzdGFydGluZyBwb2ludC4NCg0KCVRoZSB3b3JraW5nIGdyb3VwIHNob3VsZCBj b25zaWRlciBzdWNoIGZhY3RvcnMgYXM6DQoJKiBpbXBsZW1lbnRlciBleHBlcmllbmNlDQoJKiBp bnRlcm5hdGlvbmFsaXphdGlvbg0KCSogZXhpc3RpbmcgdXNlcyBvZiBBUkYNCgkqIGFiaWxpdHkg dG8gYWNoaWV2ZSBicm9hZCBpbXBsZW1lbnRhdGlvbiBhbmQgaW50ZXJvcGVyYWJpbGl0eQ0KCSog YWJpbGl0eSB0byBhZGRyZXNzIGJyb2FkZXIgdXNlIGNhc2VzIHRoYW4gbWF5IGhhdmUgYmUgY29u dGVtcGxhdGVkIGJ5IHRoZSBvcmlnaW5hbA0KCSAgYXV0aG9ycw0KCSogb3ZlcmxhcCB3aXRoIHRo ZSBJTkNIIHdvcmtpbmcgZ3JvdXAncyB3b3JrIChlLmcuIFJGQzUwNzApOyBpdCBpcyB1bmNsZWFy IHdoZXRoZXINCgkgIHN1Y2ggb3ZlcmxhcCBpcyBhcHByb3ByaWF0ZSBvciBzaG91bGQgYmUgYXZv aWRlZA0KDQogICAgICAgIFRodXMsIHRoZSB3b3JraW5nIGdyb3VwJ3Mgc3BlY2lmaWMgdGFza3Mg YXJlIGFzIGZvbGxvd3M6DQoNCgkxKSBUaGUgZm9sbG93aW5nIHBvc3NpbGJsZSByZXBvcnRpbmcg ZXh0ZW5zaW9ucyBoYXZlIGJlZW4gcHJvcG9zZWQgYW5kIHdpbGwgYmUgY29uc2lkZXJlZA0KCSAg IHBvc3NpYmxlIGZvciBhZGRpdGlvbiB0byB0aGUgZXhpc3Rpbmcgc3BlY2lmaWNhdGlvbjoNCg0K CSAgIGEpIGRyb3AgYm94ZXMgKGRldGVjdGlvbiBvZiBhIG1haWxib3ggdXNlZCB0byByZWNlaXZl IHRoaW5ncyBsaWtlIHN0b2xlbg0KCSAgICAgIGNyZWRpdCBjYXJkcykNCgkgICBiKSBib3RuZXQg ZGV0ZWN0aW9uIChpLmUuIHJlcG9ydGluZyBvZiB0cmFmZmljIHRoYXQgYXBwZWFycyB0byBoYXZl IGNvbWUNCgkgICAgICBmcm9tIGEgYm90LCByZWdhcmRsZXNzIG9mIGNvbnRlbnQpDQoJICAgYykg U1NIIGF0dGFja3MNCgkgICBkKSBGVFAgYXR0YWNrcw0KCSAgIGUpIFdlYiBzZXJ2ZXIgYXR0YWNr cw0KCSAgIGYpIG1haWwgc2VudCB0byBhIGhvbmV5cG90IG9yIHNwYW0gdHJhcA0KCSAgIGcpIG1h bHdhcmUgY29ubmVjdGlvbnMgdG8gc2lua2hvbGVzDQoJICAgaCkgRERvUyByZXBvcnRzDQogICAg ICAgICAgIGkpIG90aGVycyB0aGF0IG1heSBiZSBwcm9wb3NlZCB3aXRoaW4gdGhlIGFsbG90dGVk IHRpbWVmcmFtZQ0KDQoJMikgVGhlIGdyb3VwIHdpbGwgdGhlbiBwcm9kdWNlIGEgUHJvcG9zZWQg U3RhbmRhcmQgdHJhY2sgc3BlY2lmaWNhdGlvbiBvZiBBUkYuDQoJICAgVGhpcyB3aWxsIGluY2x1 ZGUgbm90IG9ubHkgdGhlIGZvcm1hdCBvZiBhbiBBUkYgbWVzc2FnZSBhZGFwdGVkIGFzIG5lZWRl ZA0KCSAgIGZvciB0aGUgaXNzdWVzIGVudW1lcmF0ZWQgYWJvdmUsIGJ1dCBtdXN0IGFsc28gaW5j bHVkZSBhcHByb3ByaWF0ZQ0KCSAgIGRvY3VtZW50YXRpb24gb2Ygc2VjdXJpdHkgY29uc2lkZXJh dGlvbnMgYW5kIGNyZWF0aW9uIG9mIElBTkEgcmVnaXN0cmllcw0KCSAgIGZvciBlbGVtZW50cyBv ZiBBUkYgdG8gc3VwcG9ydCBmdXR1cmUgZXh0ZW5zaW9ucy4NCg0KCTMpIFRoZSBncm91cCB3aWxs IHNwZWNpZnkgdGhlIGludGVncmF0aW9uIG9mIEFSRiBpbnRvIERLSU0gRE5TIGtleSByZWNvcmRz LCB3aXRoDQoJICAgZHJhZnQta3VjaGVyYXd5LWRraW0tcmVwb3J0aW5nIGFzIGl0cyBpbnB1dC4g IEl0IGNvbnRhaW5zIGV4dGVuc2lvbnMNCgkgICB0byBES0lNIHRoYXQgYXJlIHJlbGF0ZWQgdG8g QVJGIGFzIGEgbWVhbnMgb2YgcmVwb3J0aW5nIERLSU0tcmVsYXRlZCBmYWlsdXJlcw0KCSAgIHdo aWNoIGluY2x1ZGUgcGhpc2hpbmcgKCJmcmF1ZCIpIGFuZCBhcyBzdWNoIGFyZSByZWxldmFudCB0 byB0aGUgQVJGIGVmZm9ydC4NCgkgICBUaGUgZ3JvdXAgd2lsbCBwcm9kdWNlIFByb3Bvc2VkIFN0 YW5kYXJkIHRyYWNrIHNwZWNpZmljYXRpb24gZm9yIHRoZXNlDQoJICAgQVJGIGFuZCBES0lNIGV4 dGVuc2lvbnMuDQoNCgk0KSBUaGUgZ3JvdXAgd2lsbCBmaW5hbGx5IGNvbnNpZGVyIGEgbWVhbnMg Zm9yIHB1Ymxpc2hpbmcgdGhlIGFkZHJlc3MNCgkgICB0byB3aGljaCBBUkYgcmVwb3J0cyBzaG91 bGQgYmUgc2VudC4gIE5vdCBhbGwgQVJGIHBhcnRpY2lwYW50cyB3aXNoIHRvIHVzZQ0KCSAgIGFi dXNlQChkb21haW4pLCB3aGljaCBpcyB0aGUgY3VycmVudCBzdGFuZGFyZCAoUkZDMjE0MikgLCBh cyB0aGUgcGxhY2UgdG8gc2VuZA0KCSAgIGF1dG9tYXRlZCBBUkYtZm9ybWF0dGVkIHJlcG9ydHMu ICBUaGUgZ3JvdXAgd2lsbCBlaXRoZXIgY29uY2x1ZGUgdGhhdCB0aGUgaW5kdXN0cnkNCgkgICBz aG91bGQgY29udGludWUgdG8gdXNlIHRoaXMgZGUgZmFjdG8gc3RhbmRhcmQgKGFuZCB0aHVzIG5v IHNwZWNpZmljYXRpb24gaXMgYXBwcm9wcmlhdGUpLA0KCSAgIG9yIHdpbGwgcHJvZHVjZSBhIFBy b3Bvc2VkIFN0YW5kYXJkIHRyYWNrIGRvY3VtZW50IGlkZW50aWZ5aW5nIHRoZSBtZWFucyBieSB3 aGljaA0KCSAgIHRoYXQgYWRkcmVzcyBzaG91bGQgYmUgYWR2ZXJ0aXNlZC4NCg0KCVRoZSBncm91 cCBtYXkgY29uc2lkZXIgcmUtY2hhcnRlcmluZyB0byBjb3ZlciByZWxhdGVkIHdvcmssIHN1Y2gg YXMgZnVydGhlciBleHRlbnNpb25zLA0KCW9uY2UgdGhlc2UgZGVsaXZlcmFibGVzIGhhdmUgYmVl biBhY2hpZXZlZC4NCg0KICAgR29hbHMgYW5kIE1pbGVzdG9uZXM6DQoJSmFuIDEwCUlzc3VlIGZp cnN0IFdHLWJhc2VkIEludGVybmV0LURyYWZ0IGRlZmluaW5nIEFSRg0KCU1hciAxMAlBY2hpZXZl IGNvbnNlbnN1cyBvbiBhbnkgV0ctYmFzZWQgY2hhbmdlcyB0byBBUkYNCglBcHIgMTAJU3VibWl0 IEFSRiBJRCB0byBJRVNHIGZvciBwdWJsaWNhdGlvbg0KCUp1bCAxMAlJc3N1ZSBmaXJzdCBXRy1i YXNlZCBJRCBhYm91dCBES0lNIHJlcG9ydGluZyBleHRlbnNpb25zDQoJU2VwIDEwCUFjaGlldmUg Y29uc2Vuc3VzIG9uIERLSU0gcmVwb3J0aW5nIGV4dGVuc2lvbnMgZHJhZnQNCglPY3QgMTAJU3Vi bWl0IERLSU0gcmVwb3J0aW5nIElEIHRvIElFU0cgZm9yIHB1YmxpY2F0aW9uDQoJSmFuIDExCUlz c3VlIGZpcnN0IFdHLWJhc2VkIElEIGZvciBhZHZlcnRpc2luZyB0aGUgQVJGIGFkZHJlc3MNCglB cHIgMTEJQWNoaWV2ZSBjb25zZW5zdXMgb24gQVJGIGFkZHJlc3MgYWR2ZXJ0aXNpbmcgZHJhZnQN CglNYXkgMTEJU3VibWl0IEFSRiBhZGRyZXNzIGFkdmVydGlzaW5nIElEIHRvIElFU0cgZm9yIHB1 YmxpY2F0aW9uDQo= --_004_BB012BD379D7B046ABE1472D8093C61C01AFA26F6AEXCHC2corpclo_-- From masinter@adobe.com Wed Sep 16 08:44: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 A62193A68ED; Wed, 16 Sep 2009 08:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X9yODnwygZSh; Wed, 16 Sep 2009 08:44:34 -0700 (PDT) Received: from psmtp.com (exprod6ob117.obsmtp.com [64.18.1.38]) by core3.amsl.com (Postfix) with ESMTP id E9C553A6987; Wed, 16 Sep 2009 08:42:47 -0700 (PDT) Received: from source ([192.150.11.134]) by exprod6ob117.postini.com ([64.18.5.12]) with SMTP ID DSNKSrEHpFHLKZ+O2qr8amn/BhC2uYn0dTqa@postini.com; Wed, 16 Sep 2009 08:44:52 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n8GFacao002888; Wed, 16 Sep 2009 08:36:39 -0700 (PDT) Received: from nahub01.corp.adobe.com (nahub01.corp.adobe.com [10.8.189.97]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n8GFhJiq015339; Wed, 16 Sep 2009 08:43:19 -0700 (PDT) Received: from excas03.corp.adobe.com (10.8.189.123) by nahub01.corp.adobe.com (10.8.189.97) with Microsoft SMTP Server (TLS) id 8.1.375.2; Wed, 16 Sep 2009 08:43:19 -0700 Received: from nambx04.corp.adobe.com ([10.8.127.98]) by excas03.corp.adobe.com ([10.8.189.123]) with mapi; Wed, 16 Sep 2009 08:43:19 -0700 From: Larry Masinter To: "PUBLIC-IRI@W3.ORG" Date: Wed, 16 Sep 2009 08:43:17 -0700 Subject: IDNA, IRI, HTML5 coordination Thread-Topic: IDNA, IRI, HTML5 coordination Thread-Index: Aco18Wfr0CuHNytoSpuP9YKGT8AcWwAJDx3g Message-ID: <8B62A039C620904E92F1233570534C9B0118DBB46FA0@nambx04.corp.adobe.com> References: <0F9C0B65969D644EA7B34DF381465F66F451C8@RY02MAIL.citc.gov.sa> <4AAE260B.7080806@it.aoyama.ac.jp> <017C69CB-CD3E-4692-82AE-6514B3D20DBA@google.com> <0F9C0B65969D644EA7B34DF381465F66F45238@RY02MAIL.citc.gov.sa> <92EF5D61-AB67-4A67-9DF5-AB208A2B5795@google.com> In-Reply-To: <92EF5D61-AB67-4A67-9DF5-AB208A2B5795@google.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 24 Sep 2009 09:02:22 -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, 16 Sep 2009 15:44:36 -0000 R29hbDogYnJpbmcgdG9nZXRoZXIgYW5kIGNvb3JkaW5hdGUgdGhlIGRlZmluaXRpb25zDQpvZiB3 aGF0IGlzIHVzZWQgZm9yIHJlc291cmNlIGlkZW50aWZpY2F0aW9uIGluIHRoZSB3ZWIgYW5kIGVs c2V3aGVyZQ0KKElSSXMgYXMgdGhlIGV2b2x1dGlvbiBvZiBVUkwsIFVSSSwgSVJJLCBIUkVGLCBX ZWIgQWRkcmVzcywgZXRjLikNCndpdGhpbiBXM0MsIElFVEYgYW5kIHRoZWlyIHNwZWNpZmljYXRp b25zLiBTZWUgImRlc2lnbiBnb2FscyIgYmVsb3cuDQoNCkdvYWwgb2YgdGhpcyBtZXNzYWdlOiBs YXkgb3V0IHRoZSBjb25jZXJuZWQgZ3JvdXBzLCBzdGFydCBkaXNjdXNzaW9uDQpvZiBwcm9jZXNz IGZvciBjb29yZGluYXRpb24uDQoNCkkndmUgYmNjJ2QgZXZlcnlvbmUgZXhjZXB0IHRoZSBwdWJs aWMtaXJpQHczLm9yZyBtYWlsaW5nIGxpc3QsDQphcmNoaXZlIGh0dHA6Ly9saXN0cy53My5vcmcv QXJjaGl2ZXMvUHVibGljL3B1YmxpYy1pcmkvIGFzIHRoZQ0KbGlzdCBwcm9wb3NlZCBmb3IgZGlz Y3Vzc2lvbjoNCg0KDQpNeSBzdWdnZXN0aW9uIGZvciBob3cgdG8gZ2V0IGFsbCBvZiB0aGVzZSBn cm91cHMgdG8gY29vcmRpbmF0ZQ0KaXMgdG8gc3RhcnQgYW4gSUVURiB3b3JraW5nIGdyb3VwIHdp dGggYSBjaGFydGVyIHRvIGJyaW5nIHRoZXNlDQpzcGVjaWZpY2F0aW9ucyBpbnRvIGFsaWdubWVu dC4gSSBjYW4ndCB0aGluayBvZiBhbnkgb3RoZXIgcHJvY2Vzcw0Kd2hpY2ggY2FuIGFjY29tcGxp c2ggdGhlIGdvYWwuDQoNClBMRUFTRSwgUExFQVNFOiBpZiB5b3UncmUgZ29pbmcgdG8gcG9zdCBh biBvcGluaW9uLCBwbGVhc2UgYXQgbGVhc3QNCmNjIHB1YmxpYy1pcmlAdzMub3JnIGFuZCB0cnkg dG8ga2VlcCBkaXNjdXNzaW9uIHRoZXJlLg0KDQpQTEVBU0U6IFNlcGFyYXRlICdwcm9jZXNzJyBp c3N1ZXMgKHNob3VsZCB0aGVyZSBiZSBhIHdvcmtpbmcgZ3JvdXA/DQpXaG8gZWxzZSBuZWVkcyB0 byBiZSBpbnZvbHZlZD8gV2hhdCdzIHRoZSB0aW1pbmcgYW5kIHdoZW4/KSBmcm9tDQp0ZWNobmlj YWwgaXNzdWVzLg0KDQpUaGFua3MsDQoNCkxhcnJ5DQoNCj09PT09PT09PT09PT09PT09DQooSW5j b21wbGV0ZSkgbGlzdCBvZiBzcGVjaWZpY2F0aW9ucywgZ3JvdXBzLCBjaGFpcnMsIGVkaXRvcnM6 IA0KDQpIVFRQOg0KDQpbSFRUUEJJUy1VUkldIEhUVFAgVVJJIHNjaGVtZSBkZWYgaW4gSFRUUEJJ UyBkcmFmdDoNCiAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtaHR0 cGJpcy1wMS1tZXNzYWdpbmctMDcjc2VjdGlvbi05LjINCltIVFRQLVJGQ10gY3VycmVudCBIVFRQ IFVSSSBzY2hlbWUgZGVmaW5pdGlvbg0KICAgICAgaW4gUkZDIDI2MTYgaHR0cDovL3Rvb2xzLmll dGYub3JnL2h0bWwvcmZjMjYxNiNzZWN0aW9uLTMuMi4yDQpbSFRUUEJJUy1XR10gSUVURiBIVFRQ QklTIHdvcmtpbmcgZ3JvdXANCiAgICBjaGFydGVyOiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvd2cv aHR0cGJpcy9jaGFydGVycw0KICAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvZHluL3dn L2NoYXJ0ZXIvaHR0cGJpcy1jaGFydGVyLmh0bWwNCiAgICBtYWlsaW5nIGxpc3Q6IGlldGYtaHR0 cC13Z0B3My5vcmcsDQogICAgICAgICAgYXJjaGl2ZXMgaHR0cDovL2xpc3RzLnczLm9yZy9BcmNo aXZlcy9QdWJsaWMvaWV0Zi1odHRwLXdnLyANCiAgICBjaGFpcjogICBNYXJrIE5vdHRpbmdoYW0g PG1ub3RAbW5vdC5uZXQ+DQogICAgZWRpdG9yczogUm95IEZpZWxkaW5nIDxmaWVsZGluZ0BnYml2 LmNvbT4sDQogICAgICAgICAgICAgSnVsaWFuIFJlc2Noa2UgPGp1bGlhbi5yZXNjaGtlQGdyZWVu Ynl0ZXMuZGU+LCAob3RoZXJzKQ0KICAgICANCklETkE6DQpbSUROQUJJUy0qXSBkZWZpbml0aW9u cywgcG9saWNpZXMsIHN0YW5kYXJkcyBmb3IgaG93IEludGVybmF0aW9uYWxpemVkIA0KICAgICAg RG9tYWluIE5hbWVzIHNob3VsZCBiZSBoYW5kbGVkIGluIEludGVybmV0IGFwcGxpY2F0aW9ucw0K ICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1pZG5hYmlzLWRlZnMv IA0KW0lETkFCSVMtV0ddICBJRVRGIElETkFCSVMgd29ya2luZyBncm91cA0KICAgICAgY2hhcnRl cjogaHR0cDovL3d3dy5pZXRmLm9yZy9keW4vd2cvY2hhcnRlci9pZG5hYmlzLWNoYXJ0ZXIuaHRt bA0KICAgICAgY2hhaXI6IFZpbnQgQ2VyZiA8dmludEBnb29nbGUuY29tPg0KICAgICAgZWRpdG9y OiBKb2huIEMgS2xlbnNpbiA8a2xlbnNpbkBqY2suY29tPg0KDQpJUkk6DQpbSVJJQklTLTZdIFJl dmlzaW9uIHVuZGVyIHByZXBhcmF0aW9uOg0KICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtZHVlcnN0LWlyaS1iaXMtMDYNCltJUklCSVMtTE1NXSAoIkV4cGVyaW1lbnRhbCIg ZHJhZnQgYXR0ZW1wdGluZyB0byBzYXRpc2Z5IElETkFCSVMgYW5kIEhUTUwgcmVxdWlyZW1lbnRz KQ0KICAgICAgaHR0cDovL2xhcnJ5Lm1hc2ludGVyLm5ldC9pcmliaXMtaGFjay5odG1sDQogICAg ICAoaHR0cDovL3Rvb2xzLmlldGYub3JnL3JmY2RpZmY/dXJsMT1kcmFmdC1kdWVyc3QtaXJpLWJp cy50eHQmdXJsMj1odHRwOi8vbGFycnkubWFzaW50ZXIubmV0L2lyaWJpcy1oYWNrLnR4dCkNCiAg ICAgZGlzY3Vzc2lvbiBvbjogcHVibGljLWlyaUB3My5vcmcgKGFtb25nIG90aGVycykNCiAgICAg KG90aGVyKWVkaXRvcnM6IE1hcnRpbiBEw7xyc3QgPGR1ZXJzdEBpdC5hb3lhbWEuYWMuanA+DQog ICAgICAgICAgICAgICAgICAgICBNaWNoZWwgU1VJR05BUkQgPE1pY2hlbEBzdWlnbmFyZC5jb20+ DQoNCk1haWx0byBVUkk6DQoNCltNQUlMVE8tUkZDXSBNYWlsdG86IFVSSSBzY2hlbWUNCiAgICAg IEN1cnJlbnQ6IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzIzNjgNCltNQUlMVE8tQklT XSBJbiBwcmVwYXJhdGlvbg0KICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1k dWVyc3QtbWFpbHRvLWJpcy0wNg0KICAgKG90aGVyKSBlZGl0b3JzIChpbmNsdWRpbmcpIE1hcnRp biBEw7xyc3QgKGR1ZXJzdEBpdC5hb3lhbWEuYWMuanApDQogICBkaXNjdXNzaW9uIG9uOiB1cmlA dzMub3JnDQoNClVSSToNCg0KW1VSSS1SRkNdIFVSSSBzcGVjDQogICAgICBodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9yZmMzOTg2DQogICBtYWlsaW5nIGxpc3Q6IHVyaUB3My5vcmcgDQogICAo b3RoZXIpIGVkaXRvcnM6IFJveSBGaWVsZGluZyA8ZmllbGRpbmdAZ2Jpdi5jb20+LCBUaW0gQmVy bmVycy1MZWUgPHRpbWJsQHczLm9yZz4NCltVUklSRUctUkZDXSANCiAgICAgIFVSSSBndWlkZWxp bmVzOiBwb2xpY2llcyBhbmQgcHJvY2VkdXJlcyBmb3IgcmVnaXN0ZXJpbmcgbmV3IFVSSSBzY2hl bWVzIA0KICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNDM5NQ0KICAgICBlZGl0 b3JzOiBUb255IEhhbnNlbiA8dG9ueUBhdHQuY29tPg0KICAgICBtYWlsaW5nIGxpc3QgZm9yIFVS SSByZXZpZXc6IHVyaS1yZXZpZXdAaWV0Zi5vcmcgDQoNCkhUTUw1Og0KW0hUTUw1LUNVUlJFTlRd ICAgSFRNTDUgZGVmaW5pdGlvbiBvZiAiVVJMcyINCiAgICAgaHR0cDovL2Rldi53My5vcmcvaHRt bDUvc3BlYy9PdmVydmlldy5odG1sI3VybHMNCltXRUJBRERSRVNTXSBBdHRlbXB0IHRvIHNwbGl0 IG91dCAiV2ViIEFkZHJlc3MiIGNvbXBvbmVudDoNCiAgICAgaHR0cDovL3d3dy53My5vcmcvaHRt bC93Zy9ocmVmL2RyYWZ0DQpbSFRNTC1XR10gVzNDIFdvcmtpbmcgR3JvdXANCiAgICAgY2hhcnRl cjogaHR0cDovL3d3dy53My5vcmcvaHRtbC93Zy8NCiAgICAgVVJML0lSSSBpc3N1ZTogaHR0cDov L3d3dy53My5vcmcvaHRtbC93Zy90cmFja2VyL2lzc3Vlcy81Ng0KICAgICBjaGFpcnM6IFBhdWwg Q290dG9uIDxwYXVsLmNvdHRvbkBtaWNyb3NvZnQuY29tPg0KICAgICAgICAgICAgIE1hY2llaiBT dGFjaG93aWFrIDxtanNAYXBwbGUuY29tPg0KICAgICAgICAgICAgIFNhbSBSdWJ5IDxydWJ5c0Bp bnRlcnR3aW5nbHkubmV0Pg0KICAgICBlZGl0b3I6IElhbiBIaWNrc29uIDxpYW5AaGl4aWUuY2g+ DQoNCg0KT3RoZXIgaW50ZXJlc3RlZCBncm91cHM6DQoNCklFVEYgQXBwbGljYXRpb25zIGFyZWEN CiAgICAgIG1haWxpbmcgbGlzdDogYXBwcy1kaXNjdXNzQGlldGYub3JnDQogICAgICBhcmVhIGRp cmVjdG9yczogTGlzYSBEdXNzZWF1bHQgPGxpc2EuZHVzc2VhdWx0QGdtYWlsLmNvbT47IA0KICAg ICAgICAgIEFsZXhleSBNZWxuaWtvdiA8YWxleGV5Lm1lbG5pa292QGlzb2RlLmNvbT4NCg0KVzND IFRBRyAoYXJjaGl0ZWN0dXJhbCBpc3N1ZSBhcm91bmQgVVJJcyBpbiBXM0Mgc3BlY3MpDQogICAg IG1haWxpbmcgbGlzdDogd3d3LXRhZ0B3My5vcmcNCiAgICAgYXJjaGl2ZSBodHRwOi8vbGlzdHMu dzMub3JnL0FyY2hpdmVzL1B1YmxpYy93d3ctdGFnLw0KICAgICBpc3N1ZTogaHR0cDovL3d3dy53 My5vcmcvMjAwMS90YWcvZ3JvdXAvdHJhY2svaXNzdWVzLzI3DQogICAgIGNoYWlyOiBOb2FoIE1l bmRlbHNvaG4gPG5vYWhfbWVuZGVsc29obkB1cy5pYm0uY29tPg0KDQpbV0hBVFdHXSAgaHR0cDov L3d3dy53aGF0d2cub3JnLw0KDQoNCihIYXZlIEkgbWlzc2VkIGFueSBncm91cHMsIHNwZWNzPyBJ J2xsIHVwZGF0ZSB0aGlzIGxpc3QNCmFuZCBzZXQgaXQgdXAgc29tZXdoZXJlKQ0KDQo9PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpTb21lIGRlc2lnbiBnb2Fs czoNCg0KSeKAmXZlIHRyaWVkIHRvIHdyaXRlIGRvd24gc29tZSBvZiB0aGUgZGVzaWduIGdvYWxz IHdoaWNoIEkgdGhpbmsgYXJlIGltcG9ydGFudDsgdGhlc2UgbWF5IGJlIGluIGNvbmZsaWN0LCBi dXQgSSd2ZSB0cmllZCB0byBwcm9wb3NlIHByaW9yaXRpZXMgd2hpY2ggbWFrZSBzZW5zZSB0byBt ZS4gRG9lcyBhbnlvbmUgZGlzYWdyZWUgd2l0aCBhbnkgb2YgdGhlc2U/IFRoaW5rIHNvbWUgYXJl IG1pc3Npbmc/DQoNCg0KQ29uc2lzdGVudCBUZXJtaW5vbG9neTogTXVsdGlwbGUgZGVmaW5pdGlv bnMgb2YgdGhlIHNhbWUgdGVybXMgaW4gZGlmZmVyZW50IGRvY3VtZW50cyBhcmUgdG8gYmUgYXZv aWRlZDsgZXZlbiBjb25zaXN0ZW50IGRlZmluaXRpb25zIGFyZSBwcm9ibGVtYXRpYy4gV2hlcmUg cG9zc2libGUsIG5ld2VyIGRvY3VtZW50cyBzaG91bGQgcmVmZXJlbmNlIG9sZGVyIHNwZWNzLg0K DQpTZWN1cml0eTogQXZvaWRpbmcgc2VjdXJpdHkgcHJvYmxlbXMgKGUuZy4sIGRpZmZpY3VsdGll cyBkdWUgdG8gc3Bvb2ZpbmcsIHJlbmFtaW5nLCBtaXN1c2Ugb2YgRE5TKSBpcyBhIGhpZ2ggcHJp b3JpdHk7IGF2b2lkaW5nIHNlY3VyaXR5IHByb2JsZW1zIGlzIGEgaGlnaGVyIHByaW9yaXR5IHRo YW4gYmVpbmcgY29uc2lzdGVudCB3aXRoIGV4aXN0aW5nIGFwcGxpY2F0aW9ucy4NCg0KVW5pZm9y bSBiZWhhdmlvcjogT3B0aW9uYWwgaW50ZXJwcmV0YXRpb24gcnVsZXMgZm9yIHJlc291cmNlIGlk ZW50aWZpZXJzIHdoaWNoIGdpdmUgZGlmZmVyZW50IHJlc3VsdHMgZGVwZW5kaW5nIG9uIHRoZSBw cm9jZXNzaW5nIG1vZGVsIGNob3NlbiBhcmUgdG8gYmUgYXZvaWRlZC4NCg0KQ29uc2lzdGVuY3kg b2Ygd2ViIGFuZCBvdGhlciBJbnRlcm5ldCBhcHBsaWNhdGlvbnM6ICBJbnRlcm9wZXJhYmlsaXR5 IGJldHdlZW4gd2ViIGFwcGxpY2F0aW9ucyAoYnJvd3NlcnMsIHByb3hpZXMsIHNwaWRlcnMsIGV0 Yy4pIGFuZCBvdGhlciBJbnRlcm5ldCBhcHBsaWNhdGlvbnMgd2hpY2ggdXNlIHJlc291cmNlIGlk ZW50aWZpZXJzIChlbWFpbCwgZGlyZWN0b3J5IHNlcnZpY2VzKSBpcyBpbXBvcnRhbnQsIGFuZCBz aG91bGQgYmUgZ2l2ZW4gZXF1YWwgKG9yIG5lYXJseSBlcXVhbCkgcHJpb3JpdHkgYXMgaW50ZXJv cGVyYWJpbGl0eSBiZXR3ZWVuIHdlYiBicm93c2Vycy4gUmVjb21tZW5kZWQgcHJhY3RpY2UgZm9y IHdlYiBhcHBsaWNhdGlvbnMgYW5kIG90aGVyIEludGVybmV0IGFwcGxpY2F0aW9ucyBzaG91bGQg YmUgdGhlIHNhbWUg4oCTIHRob3NlIGNyZWF0aW5nIHdlYiBjb250ZW50IHNob3VsZCBub3QgYmUg ZW5jb3VyYWdlZCB0byBjcmVhdGUgUmVzb3VyY2UgSWRlbnRpZmllcnMgKHdoZXRoZXIgY2FsbGVk IFVSTHMsIFVSSXMsIElSSXMsIFdlYiBBZGRyZXNzZXMpIHdoaWNoIHdvdWxkIG5vdCBmdW5jdGlv biBpbiBvdGhlciBhcHBsaWNhdGlvbnMuDQoNCkNvbnNpc3RlbmN5IG9mIHNwZWNpZmljYXRpb25z IHdpdGggaW1wbGVtZW50YXRpb25zOiAgV2hlbiBleGlzdGluZyBzcGVjaWZpY2F0aW9ucyBkbyBu b3QgbWF0Y2ggdGhlIGNvbW1vbiBwcmFjdGljZSBvZiBleGlzdGluZyBhcHBsaWNhdGlvbnMsIGl0 IGlzIGFwcHJvcHJpYXRlIHRvIHVwZGF0ZSB0aGUgZXhpc3Rpbmcgc3BlY2lmaWNhdGlvbiwgZXZl biBpZiBsb25nIHN0YW5kaW5nLg0KDQpJbXByb3ZlIGludGVyb3BlcmFiaWxpdHk6IFdoZW4gZXhp c3RpbmcgaW1wbGVtZW50YXRpb25zIGRpc2FncmVlLCBkb2N1bWVudCBleGlzdGluZyBwcmFjdGlj ZSwgYnV0IHJlY29tbWVuZCAobm9ybWF0aXZlbHkpIHRoZSBiZWhhdmlvciB0aGF0IHdpbGwgYmVz dCBsZWFkIHRvIGltcHJvdmVkIGludGVyb3BlcmFiaWxpdHkuDQoNClNlcGFyYXRlIOKAnHNwZWNp ZmljYXRpb24gb2Ygd2hhdCBhIGNvbnNlcnZhdGl2ZSBwcm9kdWNlciBzaG91bGQgc2VuZOKAnSBm cm9tIOKAnGFkdmljZSBmb3Igd2hhdCBhIGxpYmVyYWwgY29uc3VtZXIgc2hvdWxkIGFjY2VwdOKA nTogZm9yIHJvYnVzdG5lc3MsIHRoZSBzcGVjaWZpY2F0aW9uIG9mIGEg4oCcY29uZm9ybWluZ+KA nSByZXNvdXJjZSBpZGVudGlmaWVyIHNob3VsZCBwcm9kdWNlIGNhbiBiZSAoaWYgbmVjZXNzYXJ5 KSBtb3JlIHJlc3RyaWN0aXZlIHRoYW4gdGhlIHNwZWNpZmljYXRpb24gb2Ygd2hhdCBzb21lIGNv bW1vbiBhcHBsaWNhdGlvbnMgYWNjZXB0Lg0KDQpNaW5pbWl6ZSBvcHRpb25zIGFuZCBzcGVjaWZp Y2F0aW9uczogVGhlIHNwbGl0IGJldHdlZW4gVVJJIGFuZCBJUkkgYXMgc2VwYXJhdGUgcHJvdG9j b2wgZWxlbWVudHMgd2FzIHVuZm9ydHVuYXRlIOKAkyB0byBoYXZlIHR3byBzZXBhcmF0ZSBub3Jt YXRpdmUgdGVybXMsIOKAnFVSSeKAnSBhbmQg4oCcSVJJ4oCdIHRvIGRlc2NyaWJlIHR3byB2YXJp YXRpb25zIG9mIOKAnHJlc291cmNlIGlkZW50aWZpZXJz4oCdLCBidXQgaGF2aW5nIHVubmVjZXNz YXJ5IG11bHRpcGxlIG5vbi10ZXJtaW5hbHMgYW5kIHRlcm1zIGlzIGhhcm1mdWwuIEFkZGluZyBh ZGRpdGlvbmFsIHRlcm1zIHN1Y2ggYXMg4oCcTEVJUknigJ0gYW5kIOKAnFdlYiBBZGRyZXNz4oCd IG9yIEhSRUYgc2hvdWxkIGJlIGF2b2lkZWQsIGlmIGF0IGFsbCBwb3NzaWJsZS4uIChJbiBzb21l IHdheXMsIOKAnFVSSeKAnSB3YXMgdGhlIHRlcm0gdXNlZCB0byB1bmlmeSDigJxVUkzigJ0gYW5k IOKAnFVSTuKAnSkuDQoNClVubGVzcyBuZWNlc3NhcnkgZm9yIG90aGVyIHJlYXNvbnMgYWJvdmUs IGF2b2lkIG1ha2luZyBleGlzdGluZywgY29uZm9ybWluZywgYW5kIHdpZGVseSBpbXBsZW1lbnRl ZCBiZWhhdmlvciBub24tY29uZm9ybWluZzogQXBwbGljYXRpb25zIHdoaWNoIGFjY2VwdCBVUklz IGJ1dCBub3QgSVJJcyBzaG91bGQgbm90IGJlIG1hZGUg4oCcbm9uLWNvbmZvcm1pbmfigJ0gYnkg YSByZWRlZmluaXRpb24gb2YgdGVybXMuDQoNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT0N Cg0KU29tZSBpc3N1ZXMgKEknbSBzdXJlIHRoZXJlIGFyZSBtYW55IG1vcmUpDQoNCuKAoglDYW4g SVJJIC0+IFVSSSB0cmFuc2Zvcm1hdGlvbiBiZSBzY2hlbWUgaW5kZXBlbmRlbnQ/ICgob3B0aW9u YWwgcHJvY2Vzc2luZyB3b3VsZCBhbGxvdw0KICAgICAgbm9uLXVuaWZvcm0gYmVoYXZpb3IsIG5v dCBtZWV0IElETkEgcmVxdWlyZW1lbnRzKSkNCuKAoglVc2Ugb2YgdGVybSDigJxVUkzigJ0gICgo YW1iaWd1b3VzIHRlcm1zKSkNCuKAogloYW5kbGluZyBvZiBleHRyYSBwcm9jZXNzaW5nIHJ1bGVz IGZvciBYTUwgdnMgSFRNTDUgdnMuIElSSSBkb2N1bWVudA0K4oCiCVdoZXRoZXIgSFRNTDUgcmVm ZXJlbmNlcyBhbnl0aGluZyBvdGhlciB0aGFuIElSSWJpcw0K4oCiCVVwZGF0aW5nIHRoZSBVUkkg c2NoZW1lIHJlZ2lzdHJ5IHRvIGJlIGNsZWFyIHRoYXQgIlVSSSBzY2hlbWVzIiBhcmUgdGhlIHNh bWUgYXMg4oCcVVJMIHNjaGVtZXPigJ0gDQogICAgICBhbmQg4oCcSVJJIHNjaGVtZXPigJ0NCuKA oglDYW4gZGlmZmVyZW50IFVSSSBzY2hlbWVzIGFsbG93IGRpZmZlcmVudCBJMThOIHByb2Nlc3Np bmcgcnVsZXM/DQoNCg0KDQoNCg== From masinter@adobe.com Wed Sep 23 05:59: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 3FA773A6881; Wed, 23 Sep 2009 05:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.199 X-Spam-Level: X-Spam-Status: No, score=-8.199 tagged_above=-999 required=5 tests=[AWL=-1.600, 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 5NAY8i5sqo5O; Wed, 23 Sep 2009 05:59:34 -0700 (PDT) Received: from exprod6og101.obsmtp.com (exprod6og101.obsmtp.com [64.18.1.181]) by core3.amsl.com (Postfix) with ESMTP id 745E13A6830; Wed, 23 Sep 2009 05:59:11 -0700 (PDT) Received: from source ([192.150.8.22]) by exprod6ob101.postini.com ([64.18.5.12]) with SMTP ID DSNKSroblnz5T3AIiQb0P4xxmDPq2ZVxRv1K@postini.com; Wed, 23 Sep 2009 06:00:40 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n8NCwpX3017591; Wed, 23 Sep 2009 05:58:52 -0700 (PDT) Received: from nacas02.corp.adobe.com (nacas02.corp.adobe.com [10.8.189.100]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id n8NCwhY2004981; Wed, 23 Sep 2009 05:58:43 -0700 (PDT) Received: from nacas03.corp.adobe.com (10.8.189.121) by nacas02.corp.adobe.com (10.8.189.100) with Microsoft SMTP Server (TLS) id 8.1.375.2; Wed, 23 Sep 2009 05:58:42 -0700 Received: from nambx04.corp.adobe.com ([10.8.127.98]) by nacas03.corp.adobe.com ([10.8.189.121]) with mapi; Wed, 23 Sep 2009 05:58:42 -0700 From: Larry Masinter To: Lisa Dusseault , Alexey Melnikov Date: Wed, 23 Sep 2009 05:58:40 -0700 Subject: draft agenda for IRI working group BOF, and draft charter for IRI Thread-Topic: draft agenda for IRI working group BOF, and draft charter for IRI Thread-Index: Aco8TZKDJkQOna83QfqMaBd7qh0hWA== Message-ID: <8B62A039C620904E92F1233570534C9B0118DBB47B02@nambx04.corp.adobe.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-Mailman-Approved-At: Thu, 24 Sep 2009 09:02:22 -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, 23 Sep 2009 12:59:35 -0000 (bcc www-tag, public-html, apps-discuss, w3c/ietf policy, idna-update, http= -wg & various individuals) http://lists.w3.org/Archives/Public/public-iri/2009Sep/0076.html sent (and further discussion) =3D> public-iri@w3.org "While I am still hoping a working group isn't necessary, the=20 fallback is to start an IETF working group. This message proposes an agenda for a meeting to form the working group ("BOF" at IETF 76) and a draft charter...." Larry -- http://larry.masinter.net From A.Hoenes@TR-Sys.de Thu Sep 24 05:31: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 E12373A6942 for ; Thu, 24 Sep 2009 05:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.041 X-Spam-Level: ** X-Spam-Status: No, score=2.041 tagged_above=-999 required=5 tests=[AWL=0.790, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=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 yEJpG-0cZfl7 for ; Thu, 24 Sep 2009 05:31:16 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id E2F1F3A69DD for ; Thu, 24 Sep 2009 05:31:14 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA112595504; Thu, 24 Sep 2009 14:31:44 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id OAA07812; Thu, 24 Sep 2009 14:31:42 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200909241231.OAA07812@TR-Sys.de> Subject: draft-klensin-ftp-registry-01 To: john+ietf@jck.com, apps-discuss@ietf.org Date: Thu, 24 Sep 2009 14:31:42 +0200 (MESZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Thu, 24 Sep 2009 09:02:22 -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: Thu, 24 Sep 2009 12:31:17 -0000 Folks, I'd like to submit a few remarks on draft-klensin-ftp-registry-01. First of all: I appreciate this effort. There indeed are a couple of specifications in the IETF pipeline essentially awaiting the implementation of such registry, and the welth of published and upcoming specifications deserves such repository. (1) Registry content John already has consented that the draft should better distinguish between FTP _features_ and FTP _commands_. It needs to be worked out whether the prospective "FTP Parameters" registry (as I would denote it) should contain a) - a sub-registry of all defined feature names listing the defining document(s), and - a sub-registry of *all* commands listing the related feature(s) (if any, else ) and the defining document(s). or b) - a combined, hierarchical registry of feature names and related commands (compare the RSVP message objects registry). Opinions? (2) Provisional registrations? Another 'political' question is related to the practicability of registrations-on-RFC-publication. IANA reportedly now has implemented procedures (and recommending them) to allow 'provisional registrations' under a timeout regime (to be deleted after a specified interval unless the registration document [if needed] has been approved for publication), to further rapid interoperable experimental implementations and avoid procedural blocks. Should this registry make use of this possibility? (3) Consistency The text in the newly added section 2.3 does not match the IANA considerations, which still require "RFC required". Notwithstanding the '[[anchor8]]' there, it would be useful to have congruent text in the draft. (4) Section 2.4 << John: I promise to spend cycles for harvesting RFCs, ASAP. >> Kind regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From bil@corry.biz Thu Sep 24 21:57:40 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 B28203A69B4 for ; Thu, 24 Sep 2009 21:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.991 X-Spam-Level: X-Spam-Status: No, score=-0.991 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] 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 ZHiZzsiyVGOz for ; Thu, 24 Sep 2009 21:57:39 -0700 (PDT) Received: from mail.mindio.com (app1.bc.anu.net [193.189.141.126]) by core3.amsl.com (Postfix) with ESMTP id 8248F3A680F for ; Thu, 24 Sep 2009 21:57:38 -0700 (PDT) Received: from [127.0.0.1] (bcorry.anu.net [193.189.141.233]) by mail.mindio.com (Postfix) with ESMTP id 0A1BEFC521; Thu, 24 Sep 2009 23:58:45 -0500 (CDT) Message-ID: <4ABC4D8A.30506@corry.biz> Date: Thu, 24 Sep 2009 23:56:42 -0500 From: Bil Corry User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Eran Hammer-Lahav Subject: Re: Fwd: New Version Notification for draft-nottingham-site-meta-03 References: <20090917065629.BBC103A682A@core3.amsl.com> <0745006F-CE26-4E8F-A67D-32BED74D7E15@mnot.net> <4AB22AC7.5050704@corry.biz> <4AB22CC7.10607@gmx.de> <90C41DD21FB7C64BB94121FBBC2E72343784D57F09@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343784D57F09@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-Enigmail-Version: 0.96.0 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: Fri, 25 Sep 2009 04:57:40 -0000 Hmm, apparently blocking on a leading dot isn't as widespread as I would have thought: http://www.techcrunch.com/2009/09/23/basic-flaw-reveals-source-code-to-3300-popular-websites/ FWIW, this is the Apache mod_rewrite rule I'm using to block requests that have path components that begin with a dot or underscore, yet it allows /.well-known/ requests: RewriteCond %{REQUEST_URI} !^/.well-known/.*$ RewriteRule (^|/)(_|\.).*$ - [L,NS,F] - Bil Eran Hammer-Lahav wrote on 9/17/2009 10:57 AM: > Exactly. > > The fact that it takes more steps to enable /.well-known/ is in line with our goal of using a non-obvious path that is usually not permitted as part of usernames in social networks and other sites. > > But thanks for pointing this out as it will help us get more adoption by letting people know to check for such restrictions. > > EHL > >> -----Original Message----- >> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- >> bounces@ietf.org] On Behalf Of Julian Reschke >> Sent: Thursday, September 17, 2009 5:34 AM >> To: Bil Corry >> Cc: Apps Discuss >> Subject: Re: Fwd: New Version Notification for draft-nottingham-site- >> meta-03 >> >> Bil Corry wrote: >>> Mark Nottingham wrote on 9/17/2009 1:59 AM: >>>> See: >>>> http://www.ietf.org/id/draft-nottingham-site-meta-03.txt >>>> >From the above: >>> ---8<--- >>> A well-known URI is a URI [RFC3986] whose path component begins with >>> the characters "/.well-known/". >>> --->8--- >>> >>> I know for my own server, any file or directory within the path >> component that begins with a period or underscore returns 403. That's >> to prevent serving .htaccess, .svn, .project, ._.DS_Store, __MACOSX, >> and other configuration-type files and directories -- leading periods >> and underscores seem to be popular for them. I can add an exception >> for "/.well-known/", but wanted to mention it in case there were other >> alternatives being considered for the path component. >>> ... >> I think that's actually a strong point *in favor* of using a leading >> dot >> (less chance for overlap with real-world URIs). >> >> BR, Julian From samj@samj.net Fri Sep 25 04:31: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 BA46F3A6A21 for ; Fri, 25 Sep 2009 04:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.02 X-Spam-Level: X-Spam-Status: No, score=-4.02 tagged_above=-999 required=5 tests=[AWL=-3.929, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_BACKHAIR_57=1, NORMAL_HTTP_TO_IP=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3I6YcBf36Pbi for ; Fri, 25 Sep 2009 04:31:17 -0700 (PDT) Received: from eu1sys200aog117.obsmtp.com (eu1sys200aog117.obsmtp.com [207.126.144.143]) by core3.amsl.com (Postfix) with SMTP id BF94B3A67D9 for ; Fri, 25 Sep 2009 04:31:16 -0700 (PDT) Received: from source ([209.85.218.217]) by eu1sys200aob117.postini.com ([207.126.147.11]) with SMTP ID DSNKSryqSslYRxzeiazSpAfEk2zctOmT2okA@postini.com; Fri, 25 Sep 2009 11:32:28 UTC Received: by bwz17 with SMTP id 17so1933653bwz.21 for ; Fri, 25 Sep 2009 04:32:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.239.142.155 with SMTP id g27mr3296hba.62.1253878345777; Fri, 25 Sep 2009 04:32:25 -0700 (PDT) Date: Fri, 25 Sep 2009 12:32:25 +0100 Message-ID: <21606dcf0909250432q7026616du456ed594aeb0aafa@mail.gmail.com> Subject: HTTP 2.0 (was Re: Last Call: draft-nottingham-http-link-header (Web Linking) to Proposed Standard) From: Sam Johnston To: Julian Reschke Content-Type: multipart/alternative; boundary=001485f2774e64430a0474654d2f Cc: Ian Hickson , HTTP Working Group , IETF 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, 25 Sep 2009 11:31:19 -0000 --001485f2774e64430a0474654d2f Content-Type: text/plain; charset=ISO-8859-1 On Thu, Sep 24, 2009 at 10:52 AM, Julian Reschke wrote: > > These are orthogonal issues. You *could* define that there must be only one > title. Also, HTTP can not easily be upgraded to change the header encoding; > this has been discussed a lot over here in the last years, and my > understanding is that we would need to change the major version number. > I'm increasingly often running into problems that could be relatively easily fixed by upgrading the HTTP spec - after all we've been talking about HTTP 2.0 for 15 yearsalready :P The link header could already make a huge difference to the way the web works (I've already started on this with draft-johnston-addressing-link-relations), but we're lacking the LINK and UNLINK verbs that HTTP originally defined for managing them. Similarly, people often run into problems using PUT/POST for requests that should have been handled by PATCH (which was also [poorly] specified and then abandoned). Encodings are yet another issue I'm increasingly coming up against for non-ASCII characters. "HTTP as a meta-model" would also benefit from categories (which I have already transplanted from Atom in draft-johnston-http-category-header). Oh and let's not forget about pulling in the MOVE and COPY verbs from WebDAV so we can instruct servers to migrate resources (e.g. push a VM from one cloud to another). I'd also like to have the ability to set persistent server-side "Cookies" (or "Attributes" for a more appropriate term) using a similar process to Set-Cookie, so much so that I'm considering writing an I-D specifying this. The use case I have in mind is RESTful web services, specifically exposing "attributes" of a virtual machine such as the number of cores, core speed, memory size, etc. You can see an example below, where the OCCI-* headers would be replaced by something like "Attribute: compute-cores=2" (which you could update with an empty POST specifying Set-Attribute header(s) and remove by including 'discard' ala Set-Cookie). Another significant pain point for me (and apparently others) is collections. URLs should be able to return multiple resources headers and all, without having to resort to add-ons like multipart MIME. That way I could ask for, say, all of the contacts in my mail account and have them rendered as vCard but with metadata like author and security information, web linking to other contacts (eg FOAF), web categories, etc. Presumably this would be relatively easy to do by tweaking the spec (e.g. using CRLF separators between resources) but today I'm having to use hacks like text/uri-list which have O(n+1) rather than O(1) performance, or resorting to formats like Atom for this special case. There are of course plenty of other use cases, but the idea is to avoid "wrapper" formats like Atom (which can add significant overhead in the form of base64 encoding and/or O(n+1) requests, while neutering many HTTP features such as range GETs and caching). The only other alternative for metadata with opaque/non-hypertext resources is to create a distinct content-type and/or resource which is clearly a hack when there is a perfectly good existing out-of-band communication channel. All in all I think that if we don't start to look at upgrading HTTP to better cater for machine interfaces, advanced (semantic) clients and the like then we're going to be bolting things like SOAP, Atom, RDF, etc. onto it forever. It's looking increasingly like the OCCI Core Protocolwe're working on at OGF is basically a semantic version of HTTP and some of these ideas could well be a starting point for HTTP 2.0 (in which case I've been working in the wrong forum for this component of OCCI!). Sam Retrieving a virtual machine using OCCI: GET /myapp.ovf;web01 HTTP/1.1 Host: cloud.example.com > HTTP 200 OK Content-type: application/ovf Content-length: 12345 OCCI-Hostname: myvm.cloud.example.com OCCI-Compute-Cores: 2 OCCI-Compute-Speed: 3000 OCCI-Memory-Size: 2048 Link: ; rel="related"; type="application/pdf"; title="Build > Documentation" Link: ; rel="alternative"; type="application/xen"; title="Xen > Image" Link: ; rel="http://purl.org/occi/actions#stop"; > title="Stop" Link: ; rel="http://purl.org/occi/actions#restart"; > title="Restart" Link: ; rel="http://purl.org/occi/relations/console#screenshot"; > title="Console Screenshot" Link: ; rel=" > http://purl.org/occi/relations/console#rdp"; title="Remote Desktop > Connection" Link: ; rel=" > http://purl.org/occi/relations/console#ssh"; title="Secure SHell (SSH)" Link: ; rel="http://purl.org/occi/relations/network#interface"; > title="DMZ Interface"; address: 192.168.0.10/24; local="eth0"; > policy="allow tcp/80" Link: ; rel="http://purl.org/occi/relations/storage#device"; > title="Root Device"; local="sda" Category: windows; scheme="http://purl.org/occi/categories#operating-system"; > label="Windows" Category: q123456; scheme="http://purl.org/occi/categories#microsoft-patches"; > label="Q123456 - Evil Bug" Category: us-east; scheme="http://cloud.example.com/locations"; label="US > East" Category: staging; scheme="http://cloud.example.com/user-tags/"; > label="Staging" > --001485f2774e64430a0474654d2f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Sep 24, 2009 at 10:52 AM, Julian Reschke <julian.reschke@gmx.de> w= rote:

These are orthogonal issues. You *could* define that there must be only one= title. Also, HTTP can not easily be upgraded to change the header encoding= ; this has been discussed a lot over here in the last years, and my underst= anding is that we would need to change the major version number.

I'm increasingly often running into pr= oblems that could be relatively easily fixed by upgrading the HTTP spec - a= fter all we've been talking about HTTP 2.0 for 15 y= ears already :P

The link header could already make a huge difference to= the way the web works (I've already started on this with draft-jo= hnston-addressing-link-relations), but we're lacking the LINK and U= NLINK verbs that HTTP originally defined for managing them. Similarly, peop= le often run into problems using PUT/POST for requests that should have bee= n handled by PATCH (which was also [poorly] specified and then abandoned). = Encodings are yet another issue I'm increasingly coming up against for = non-ASCII characters. "HTTP as a meta-model" would also benefit f= rom categories (which I have already transplanted from Atom in draft-johnst= on-http-category-header). Oh and let's not forget about pulling in = the MOVE and COPY verbs from WebDAV so we can instruct servers to migrate r= esources (e.g. push a VM from one cloud to another).

I'd also like to have the ability to set persistent= server-side "Cookies" (or "Attributes" for a more appr= opriate term) using a similar process to Set-Cookie, so much so that I'= m considering writing an I-D specifying this. The use case I have in mind i= s RESTful web services, specifically exposing "attributes" of a v= irtual machine such as the number of cores, core speed, memory size, etc. Y= ou can see an example below, where the OCCI-* headers would be replaced by = something like "Attribute: compute-cores=3D2" (which you could up= date with an empty POST specifying Set-Attribute header(s) and remove by in= cluding 'discard' ala Set-Cookie).

Another significant pain point for me (and apparently o= thers) is collections. URLs should be able to return multiple resources hea= ders and all, without having to resort to add-ons like multipart MIME. That= way I could ask for, say, all of the contacts in my mail account and have = them rendered as vCard but with metadata like author and security informati= on, web linking to other contacts (eg FOAF), web categories, etc. Presumabl= y this would be relatively easy to do by tweaking the spec (e.g. using CRLF= separators between resources) but today I'm having to use hacks like t= ext/uri-list which have O(n+1) rather than O(1) performance, or resorting t= o formats like Atom for this special case.

There are of course plenty of other use cases, but the = idea is to avoid "wrapper" formats like Atom (which can add signi= ficant overhead in the form of base64 encoding and/or O(n+1) requests, whil= e neutering many HTTP features such as range GETs and caching). The only ot= her alternative for metadata with opaque/non-hypertext resources is to crea= te a distinct content-type and/or resource which is clearly a hack when the= re is a perfectly good existing out-of-band communication channel.

All in all I think that if we don't start to look a= t upgrading HTTP to better cater for machine interfaces, advanced (semantic= ) clients and the like then we're going to be bolting things like SOAP,= Atom, RDF, etc. onto it forever. It's looking increasingly like the OCCI Core Proto= col we're working on at OGF= is basically a semantic version of HTTP and some of these ideas could well= be a starting point for HTTP 2.0 (in which case I've been working in t= he wrong forum for this component of OCCI!).

Sam

Retrieving a virtual = machine using OCCI:

= GET /myapp.ovf;web01 HTTP/1.1
= Host: cloud.example.com
=
= HTTP 200 OK
= Content-type: application/ovf
= Content-length: 12345
= OCCI-Hostname: myvm.cloud.example= .com
= OCCI-Compute-Cores: 2
= OCCI-Compute-Speed: 3000
= OCCI-Memory-Size: 2048
= Link: </myvm.pdf>; rel=3D"related"; type=3D"applicatio= n/pdf"; title=3D"Build Documentation"
= Link: </myvm.xen>; rel=3D"alternative"; type=3D"applic= ation/xen"; title=3D"Xen Image"
= Link: </myvm.ovf;action=3Dstop>; rel=3D"http://purl.org/occi/actions#stop"; title=3D= "Stop"
= Link: </myvm.ovf;action=3Drestart>; rel=3D"http://purl.org/occi/actions#restart";= title=3D"Restart"
= Link: </myvm.png>; rel=3D"http://purl.org/occi/relations/console#screenshot"; title=3D"Console Screenshot"
= Link: <rdp://myvm.cloud.exampl= e.com>; rel=3D"http://purl.org/occi/relations/console#rdp"; title=3D"= Remote Desktop Connection"
= Link: <ssh://myvm.cloud.exampl= e.com>; rel=3D"http://purl.org/occi/relations/console#ssh"; title=3D"= Secure SHell (SSH)"
= Link: </networks/dmz>; rel=3D"http://purl.org/occi/relations/network#interface= "; title=3D"DMZ Interface"; address: 192.168.0.10/24; local=3D"eth0"; policy=3D&qu= ot;allow tcp/80"
= Link: </san/myvm>; rel=3D"http://purl.org/occi/relations/storage#device"= ; title=3D"Root Device"; local=3D"sda"
= Category: windows; scheme=3D"http://purl.org/occi/categories#operating-system&qu= ot;; label=3D"Windows"
= Category: q123456; scheme=3D"http://purl.org/occi/categories#microsoft-patches&= quot;; label=3D"Q123456 - Evil Bug"
= Category: us-east; scheme=3D"http://cloud.example.com/locations"; label=3D"US East&q= uot;
= Category: staging; scheme=3D"http://cloud.example.com/user-tags/"; label=3D"Staging= "
=
= <?xml version=3D"1.0" encoding=3D"UTF-8" ?>
= <!-- Open Virtualisation Format (OVF) -->
--001485f2774e64430a0474654d2f-- From julian.reschke@gmx.de Fri Sep 25 04:40: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 F05623A688F for ; Fri, 25 Sep 2009 04:40:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.572 X-Spam-Level: X-Spam-Status: No, score=-4.572 tagged_above=-999 required=5 tests=[AWL=-1.973, 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 SRpdoCcEbwGK for ; Fri, 25 Sep 2009 04:40:13 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id A52673A686E for ; Fri, 25 Sep 2009 04:40:12 -0700 (PDT) Received: (qmail invoked by alias); 25 Sep 2009 11:41:17 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.117]) [217.91.35.233] by mail.gmx.net (mp071) with SMTP; 25 Sep 2009 13:41:17 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19nIn88oFFntj1Vk1RPBgbbJ4JrUChQM56a4lMBv/ L8NCIb+4P2IjFI Message-ID: <4ABCAC52.9040909@gmx.de> Date: Fri, 25 Sep 2009 13:41:06 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Sam Johnston Subject: Re: HTTP 2.0 (was Re: Last Call: draft-nottingham-http-link-header (Web Linking) to Proposed Standard) References: <21606dcf0909250432q7026616du456ed594aeb0aafa@mail.gmail.com> In-Reply-To: <21606dcf0909250432q7026616du456ed594aeb0aafa@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.5600000000000001 Cc: Ian Hickson , HTTP Working Group , IETF 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, 25 Sep 2009 11:40:14 -0000 Sam Johnston wrote: > ... > The link header could already make a huge difference to the way the web > works (I've already started on this with > draft-johnston-addressing-link-relations > ), > but we're lacking the LINK and UNLINK verbs that HTTP originally defined > for managing them. Similarly, people often run into problems using > PUT/POST for requests that should have been handled by PATCH (which was > also [poorly] specified and then abandoned). Encodings are yet another > issue I'm increasingly coming up against for non-ASCII characters. "HTTP > ... We don't need HTTP 2.0 to define LINK, UNLINK or PATCH (the latter being defined in draft-dusseault-http-patch-14 which is progressing REALLY slowly). > as a meta-model" would also benefit from categories (which I have > already transplanted from Atom in draft-johnston-http-category-header > ). Oh > and let's not forget about pulling in the MOVE and COPY verbs from > WebDAV so we can instruct servers to migrate resources (e.g. push a VM > from one cloud to another). What stops you from doing this right now? > ... > Another significant pain point for me (and apparently others) is > collections. URLs should be able to return multiple resources headers > and all, without having to resort to add-ons like multipart MIME. That > way I could ask for, say, all of the contacts in my mail account and > have them rendered as vCard but with metadata like author and security > information, web linking to other contacts (eg FOAF), web categories, > etc. Presumably this would be relatively easy to do by tweaking the spec > (e.g. using CRLF separators between resources) but today I'm having to > use hacks like text/uri-list which have O(n+1) rather than O(1) > performance, or resorting to formats like Atom for this special case. > ... WebDAV (RFC4918) defines collections, and ways to get information about multiple resources at once. > ... BR, Julian From breno@google.com Fri Sep 25 08:57: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 1CB3F3A695D for ; Fri, 25 Sep 2009 08:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.977 X-Spam-Level: X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 wk78QJV+TXHP for ; Fri, 25 Sep 2009 08:57:56 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id CDB383A6948 for ; Fri, 25 Sep 2009 08:57:55 -0700 (PDT) Received: from zps18.corp.google.com (zps18.corp.google.com [172.25.146.18]) by smtp-out.google.com with ESMTP id n8PFx4Ku030224 for ; Fri, 25 Sep 2009 16:59:05 +0100 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1253894345; bh=aEsUI/DE7taQo1ITQOtQqapYeyo=; h=DomainKey-Signature:MIME-Version:In-Reply-To:References:Date: Message-ID:Subject:From:To:Cc:Content-Type: Content-Transfer-Encoding:X-System-Of-Record; b=r+urk2ea7LlsOHifzQ f2JkxHRgCmVK1VlrGHWegZPOZ8LPMXNouVpe7GZ2ZVDv1CCsWSNcSYQsWalz4FFCtjO Q== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=bT3LOM3IH8dGOHUrQGx9+UyOBycAAuf0gFA/x28JeAVsGRiN6GHATObL50LAvZ62B WAwVj9sOCBWy81DhmRJkA== Received: from qyk37 (qyk37.prod.google.com [10.241.83.165]) by zps18.corp.google.com with ESMTP id n8PFwTtc031178 for ; Fri, 25 Sep 2009 08:59:02 -0700 Received: by qyk37 with SMTP id 37so2131122qyk.11 for ; Fri, 25 Sep 2009 08:59:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.9.130 with SMTP id l2mr282469qcl.41.1253894341527; Fri, 25 Sep 2009 08:59:01 -0700 (PDT) In-Reply-To: <4ABC4D8A.30506@corry.biz> References: <20090917065629.BBC103A682A@core3.amsl.com> <0745006F-CE26-4E8F-A67D-32BED74D7E15@mnot.net> <4AB22AC7.5050704@corry.biz> <4AB22CC7.10607@gmx.de> <90C41DD21FB7C64BB94121FBBC2E72343784D57F09@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4ABC4D8A.30506@corry.biz> Date: Fri, 25 Sep 2009 08:59:01 -0700 Message-ID: <29fb00360909250859j7dba65d5wec081cf2f2c42c27@mail.gmail.com> Subject: Re: Fwd: New Version Notification for draft-nottingham-site-meta-03 From: Breno de Medeiros To: Bil Corry Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true 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, 25 Sep 2009 15:57:57 -0000 Insecure sites are, well, insecure. Adding the '.' prevents against attacks on sites that have taken some measures to secure themselves. On Thu, Sep 24, 2009 at 9:56 PM, Bil Corry wrote: > Hmm, apparently blocking on a leading dot isn't as widespread as I would = have thought: > > =A0 =A0 =A0 =A0http://www.techcrunch.com/2009/09/23/basic-flaw-reveals-so= urce-code-to-3300-popular-websites/ > > > FWIW, this is the Apache mod_rewrite rule I'm using to block requests tha= t have path components that begin with a dot or underscore, yet it allows /= .well-known/ requests: > > =A0 =A0 =A0 =A0RewriteCond %{REQUEST_URI} =A0!^/.well-known/.*$ > =A0 =A0 =A0 =A0RewriteRule (^|/)(_|\.).*$ =A0- [L,NS,F] > > > - Bil > > > Eran Hammer-Lahav wrote on 9/17/2009 10:57 AM: >> Exactly. >> >> The fact that it takes more steps to enable /.well-known/ is in line wit= h our goal of using a non-obvious path that is usually not permitted as par= t of usernames in social networks and other sites. >> >> But thanks for pointing this out as it will help us get more adoption by= letting people know to check for such restrictions. >> >> EHL >> >>> -----Original Message----- >>> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- >>> bounces@ietf.org] On Behalf Of Julian Reschke >>> Sent: Thursday, September 17, 2009 5:34 AM >>> To: Bil Corry >>> Cc: Apps Discuss >>> Subject: Re: Fwd: New Version Notification for draft-nottingham-site- >>> meta-03 >>> >>> Bil Corry wrote: >>>> Mark Nottingham wrote on 9/17/2009 1:59 AM: >>>>> See: >>>>> =A0 http://www.ietf.org/id/draft-nottingham-site-meta-03.txt >>>>> >From the above: >>>> ---8<--- >>>> A well-known URI is a URI [RFC3986] whose path component begins with >>>> the characters "/.well-known/". >>>> --->8--- >>>> >>>> I know for my own server, any file or directory within the path >>> component that begins with a period or underscore returns 403. =A0That'= s >>> to prevent serving .htaccess, .svn, .project, ._.DS_Store, __MACOSX, >>> and other configuration-type files and directories -- leading periods >>> and underscores seem to be popular for them. =A0I can add an exception >>> for "/.well-known/", but wanted to mention it in case there were other >>> alternatives being considered for the path component. >>>> ... >>> I think that's actually a strong point *in favor* of using a leading >>> dot >>> (less chance for overlap with real-world URIs). >>> >>> BR, Julian > > > > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --=20 --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7) From A.Hoenes@TR-Sys.de Fri Sep 25 10:00: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 C0F243A68D2 for ; Fri, 25 Sep 2009 10:00:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.452 X-Spam-Level: **** X-Spam-Status: No, score=4.452 tagged_above=-999 required=5 tests=[AWL=-1.629, BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, J_CHICKENPOX_32=0.6, MIME_8BIT_HEADER=0.3, SARE_PROLOSTOCK_SYM3=1.63] 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 leH3cPoQbbQM for ; Fri, 25 Sep 2009 10:00:12 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 104643A68DD for ; Fri, 25 Sep 2009 10:00:10 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA120778034; Fri, 25 Sep 2009 19:00:34 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id TAA11690; Fri, 25 Sep 2009 19:00:32 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200909251700.TAA11690@TR-Sys.de> Subject: fodder for the proposed FTP feature/cmd registry To: john+ietf@jck.com Date: Fri, 25 Sep 2009 19:00:32 +0200 (MESZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=ELM1253898032-11670-0_ Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 25 Sep 2009 13:36:21 -0700 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, 25 Sep 2009 17:00:13 -0000 --ELM1253898032-11670-0_ Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit John, as promised recently, I have performed some harvesting of RFCs and I-Ds to collect material for the initial content of the IANA registry proposed in your I-D, draft-klensin-ftp-registry. Enclosed is a (still rough) tabulation of my results, listing all FTP commands and FTP Features I found specified in RFCs (since roughly RFC 600, but excluding gravestone dead FTP Mail stuff) and recent I-Ds. Kind regards, Alfred. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ --ELM1253898032-11670-0_ Content-Type: text/plain Content-Disposition: attachment; filename=ftp_cmds.lst Content-Description: ftp_cmds.lst Content-Transfer-Encoding: 7bit FTP Commands and Feature Names ============================== A) FTP RFCs cmd description FEAT type M/O RFC(s) Notes ------------------------------------------------------------------------ ABOR - Abort base s m 765,959 ACCT - Account base a m 765,959 ADAT - Authent./Security Data secu a o 2228,2773,4317 ALLO - Allocate base s m 765,959 APPE - Apend (with create) base s m 765,959 AUTH - Authent./Security Mechanism AUTH a o 2228,2773,4217 [2] #1 AUTH - Authent./Security Mechanism secu a o 2228 CCC - Clear Command Channel secu a o 2228 CDUP - Change to Parent Directory base a o 959 CONF - Confident. Protected Command secu a o 2228 CWD - Change Working Directory base a m 697,765,959 DELE - Delete File base s m 765,959 ENC - Privacy Protected Command secu a o 2228,2773,4217 EPRT - Extended Port nat6 p m 2428 EPSV - Extended Passive Mode nat6 p m 2428 FEAT - Feature Negotiation feat a m 2389 HELP - Help base s m 765,959 LANG - (Server Messages) Language UTF8 p o 2640 LIST - List base s m 765,959,1123 LPRT - Data Port {FOOBAR} ipng p o 1545,1639 {obsolete} LPSV - Passive Mode {FOOBAR} ipng p m 1545,1639 {obsolete} MDTM - File Modification Time MDTM s o 3659 MIC - Integrity Protected Command secu a o 2228,2773,4217 MKD - Make Directory base s o 959 MLSD - List Directory (for machine) MLST s o 3659 MLST - List Single Object MLST s o 3659 MODE - Transfer Mode base p m 765,959 NLST - Name List base s m 765,959,1123 NOOP - No-Op base s m 765,959 OPTS - Options feat p m 2389 PASS - Password base a m 765,959 PASV - Passive Mode base p m 765,959,1123 PBSZ - Protection Buffer Size PBSZ p o 2228,4217 PBSZ - Protection Buffer Size secu p o 2228 PORT - Data Port base p m 765,959 PROT - Data Channel Prot. Level PROT p o 2228,4217 PROT - Data Channel Prot. Level secu p o 2228 PWD - Print Directory base s o 959 QUIT - Logout base a m 765,959 REIN - reinitialize base a m 765,959 REST - Restart base s/p m 765,959,1123 REST - Restart (for STREAM mode) REST s/p m 3659 [1] RETR - Retrieve base s m 765,959 RMD - Remove Directory base s o 959 RNFR - Rename from base s/p m 765,959 RNTO - Rename To base s m 765,959 SITE - Site Parameters base s m 765,959,1123 SIZE - File Size SIZE s o 3659 SMNT - Structure Mount base a o 959 STAT - Status base s m 765,959 STOR - Store base s m 765,959 STOU - Store Unique base a o 949,959,1123 STRU - File Structure base p m 765,959 SYST - System base s o 959 TYPE - Representation Type base p m 765,959 USER - User Name base a m 765,959 XCUP - {exp. precursor for CDUP} hist s o 775,1123 XCWD - {exp. precursor for CWD} hist s o 775,1123 XMKD - {exp. precursor for MKD} hist s o 775,1123 XPWD - {exp. precursor for PWD} hist s o 775,1123 XRMD - {exp. precursor for RMD} hist s o 775,1123 tvfs - Trivial Virtual File Store TVFS p o 3659 B) Recent FTP Extension Proposals published in Internet-Drafts cmd description FEAT type M/O I-D Notes ------------------------------------------------------------------------ AVBL - Available Octets (Quota) AVBL s o I-D.peterson CSID - Client/Server Identification CSID s o I-D.peterson DSIZ - Directory Size DSIZ s o I-D.peterson HOST - Change {virtual} Host HOST s o I-D.peterson HOST - Change {virtual} Host HOST s o I-D.hethmon MFCT - Modify Fact: Creation Time MFCT s o I-D.somers MFF - Modify Fact: {named} Facts MFF s o I-D.somers MFMT - Modify Fact: Modific. Time MFMT s o I-D.somers RMDA - Remove Directory All RMDA s o I-D.peterson SPDT - Single-Port Data .... s o I-D.rosenau SPSV - Single-Port Passive Mode .... p o I-D.rosenau THMB - Retrieve File Thumbnail THMB s o I-D.peterson i18n - Internationalized Text TYPE p o I-D.klensin [3] Legend: ------ o cmd: uppercase: FTP command name lowercase: pseudo-command (FTP feature without a new command) o FEAT: lowercase: pseudo-feature name for RFCs roughly predating RFC 2389: hist - Historic (RFC 775) experimental; standard version is in RFC 959; however, "MAY" per RFC 1123 ! base - Basic RFC Standard (RFC 959) secu - FTP Security Extensions (RFC 2228) base - FTP Feature Negotiation (RFC 2389) ipng - FTP Ext'ns for IPng (RFC 1545, RFC 1639) experimental, obsoleted by by: nat6 - FTP Ext'ns for NAT/IPv6 (RFC 2428) uppercase: name of enabling feature, full feature strings are: [1] REST STREAM (RFC 3659) [2] AUTH TLS (RFC 4217) It is suggested that, in the spirit of RFC 4217, for the Experimental RFC 2773 the following FEAT string be used: AUTH KEA-SKIPJACK (RFC 2773) [3] TYPE {semicolon-separated list of supported types} o command types (per RFC 959): a - access control p - transfer parameter setting s - service invocation s/p - classified as service invocation in RFC 959, but actually some kind of parameter setting o Mandatory/Optional: m - mandatory command (for , , commands only) o - optional command Notes: #1 Although not explicit in RFC 2389, RFC 4217 specifies that support of these commands is needed using their opcodes as FEAT responses (expanded for AUTH). References (to be filled in): ---------- RFC 697 RFC 765 RFC 775 RFC 949 RFC 959 RFC 1123 RFC 2280 RFC 2389 RFC 2428 RFC 3659 RFC 4217 I-D.rosenau : draft-rosenau-ftp-single-port-04 I-D.peterson : draft-peterson-streamlined-ftp-command-extensions-05 I-D.somers : draft-somers-ftp-mfxx-04 I-D.klensin : draft-klensin-ftp-typeu-00 I-D.hethmon : draft-hethmon-murray-ftp-hosts-00 --ELM1253898032-11670-0_-- From john@jck.com Fri Sep 25 17:24: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 E1A7F3A68E1 for ; Fri, 25 Sep 2009 17:24:54 -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 QH-HZ-2dxS1X for ; Fri, 25 Sep 2009 17:24:54 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 13A723A68AD for ; Fri, 25 Sep 2009 17:24:54 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1MrL6v-00095A-5l; Fri, 25 Sep 2009 20:26:01 -0400 Date: Fri, 25 Sep 2009 20:26:00 -0400 From: John C Klensin To: "Alfred H?nes" Subject: Re: fodder for the proposed FTP feature/cmd registry Message-ID: In-Reply-To: <200909251700.TAA11690@TR-Sys.de> References: <200909251700.TAA11690@TR-Sys.de> 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: Sat, 26 Sep 2009 00:24:55 -0000 --On Friday, September 25, 2009 19:00 +0200 "Alfred H?nes" wrote: > John, > as promised recently, I have performed some harvesting of RFCs > and I-Ds to collect material for the initial content of the > IANA registry proposed in your I-D, draft-klensin-ftp-registry. > > Enclosed is a (still rough) tabulation of my results, listing > all FTP commands and FTP Features I found specified in RFCs > (since roughly RFC 600, but excluding gravestone dead FTP Mail > stuff) and recent I-Ds. Many thanks. I'm going to try to do the merge and get that document out this weekend or the first part of next week. Since the registry contents list is the hardest part of the job, you just got promoted to co-author unless you object for some reason. best, john From mnot@mnot.net Sat Sep 26 17:17: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 943C13A68CE for ; Sat, 26 Sep 2009 17:17:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.109 X-Spam-Level: X-Spam-Status: No, score=-5.109 tagged_above=-999 required=5 tests=[AWL=-2.510, 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 ABB8TqQ3tly8 for ; Sat, 26 Sep 2009 17:17:58 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id A63683A67D7 for ; Sat, 26 Sep 2009 17:17:58 -0700 (PDT) Received: from [10.204.4.150] (unknown [120.152.4.144]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 309E3509B3; Sat, 26 Sep 2009 20:19:03 -0400 (EDT) Subject: Re: Input on request for link relation Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Mark Nottingham In-Reply-To: Date: Sun, 27 Sep 2009 10:18:52 +1000 Content-Transfer-Encoding: 7bit Message-Id: <05DF2FC9-1DB6-48A6-91B1-500BC4FDA79B@mnot.net> References: <8860AD10-B0C5-4BEF-8C68-731973EF4046@mac.com> <30ac519d0909101631m14782ce8vd085629237b0e444@mail.gmail.com> <21606dcf0909110445s78ea728cueb158ff588f394a5@mail.gmail.com> <404dcbd20909110500j5394c43dve10264c01a7a6244@mail.gmail.com> <21606dcf0909110617y40586e53x213e5e8febc4a9e8@mail.gmail.com> <0CB59F7B-A9DD-4866-8F70-A65869A79277@mnot.net> <21606dcf0909160246i56c1dc55l43631423a542c41a@mail.gmail.com> <2B6D770A-58C5-48D6-AF52-7341812C9BFA@mnot.net> To: Ian Hickson X-Mailer: Apple Mail (2.1076) Cc: Atom-Syntax Syntax , Hadrien Gardeur , HTTP Working Group , 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, 27 Sep 2009 00:17:59 -0000 On 24/09/2009, at 7:37 PM, Ian Hickson wrote: > > It would certainly be an improvement, though I'm still unconvinced > that we > want different definitions for the same link type for different MIME > types. Difference conformance classes, sure, but that's another issue. Yes, that's the tricky part; there would be a tendency to define different meanings for different mime types, no matter how clearly it's stated that the additional information was restricted to the interpretation/implementation of the relations. -- Mark Nottingham http://www.mnot.net/ From lisa.dusseault@gmail.com Mon Sep 28 11:13: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 B52C43A69FF for ; Mon, 28 Sep 2009 11:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.777 X-Spam-Level: X-Spam-Status: No, score=-2.777 tagged_above=-999 required=5 tests=[AWL=-0.178, 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 klagACzUshhi for ; Mon, 28 Sep 2009 11:13:18 -0700 (PDT) Received: from mail-vw0-f196.google.com (mail-vw0-f196.google.com [209.85.212.196]) by core3.amsl.com (Postfix) with ESMTP id C43523A69DC for ; Mon, 28 Sep 2009 11:13:17 -0700 (PDT) Received: by vws34 with SMTP id 34so3231301vws.32 for ; Mon, 28 Sep 2009 11:14:33 -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; bh=Ua3ZEVUUjiFqj1fqkqY+ZI/XcMFPbJREiJwNwruGqlY=; b=r1Q7gMWC6sDukJBxpKDA84NE19w+298henGJlkPxJlZkxNWPCoCskuoAcYuhFiBT7O SqwBzaki0xn/k0RgFg6N3nPNubxK8ajAmAD3C4z0DGwD6/J2Si1/wQc2mf6iBjJskifs EwQD9GR78sWEONlcnTa6xlxExe/ni+tYFmpT4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=IgC4T8mKTso9cw4J8dwy/la3mAaEE/bzDVYDCnZWUvRukNm7jNk+mbO664WZxxcdrR tQXRFSaJSnZ2XNyp95aPee8X7nRM/MAEJ3FFgQqqLyrRZ/l+0clpBnJoDpbKSzK/P4ru 5Wd98IEc3k76HGYuZV0VLrj0EFPDhRxKRTizk= MIME-Version: 1.0 Received: by 10.220.114.142 with SMTP id e14mr6173541vcq.83.1254161672976; Mon, 28 Sep 2009 11:14:32 -0700 (PDT) Date: Mon, 28 Sep 2009 11:14:32 -0700 Message-ID: Subject: New affiliation -- Linden Lab From: Lisa Dusseault To: apps-discuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1 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, 28 Sep 2009 18:13:18 -0000 Hi, As of today, I am working for Linden Lab (and continue as Area Director with their support). I will continue to use this email address a lot of the time, but I can now be reached as rue@lindenlab.com as well. Thanks, Lisa Dusseault From A.Hoenes@TR-Sys.de Tue Sep 29 07:10: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 A911F3A6ADB; Tue, 29 Sep 2009 07:10:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.431 X-Spam-Level: *** X-Spam-Status: No, score=3.431 tagged_above=-999 required=5 tests=[AWL=-0.420, BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=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 WrYYIb67IsNT; Tue, 29 Sep 2009 07:10:00 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 09A0E3A6AD6; Tue, 29 Sep 2009 07:09:57 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA143003418; Tue, 29 Sep 2009 16:10:18 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id QAA19651; Tue, 29 Sep 2009 16:10:08 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200909291410.QAA19651@TR-Sys.de> Subject: draft-ietf-tsvwg-iana-ports-02 To: draft-ietf-tsvwg-iana-ports@cabernet.tools.IETF.ORG, tsvwg@ietf.org Date: Tue, 29 Sep 2009 16:10:07 +0200 (MESZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 29 Sep 2009 20:33:44 -0700 Cc: cheshire@apple.com, 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, 29 Sep 2009 14:10:02 -0000 Hello, I have followed up and studied the revised Port Number registry draft, draft-ietf-tsvwg-iana-ports-02. Lars has solicited on the TSVWG list reviews of that draft, and I have quite a couple of comments. Because of the extended scope of the topic, this note is also circulated to APPS-DISCUSS. The bulk of items below is divided into part (A) discussing substantial general issues and part (B) dedicated to (more or less) editorial issues found in the draft. Readers only interested in the points perhaps needing discussion can safely stop reading after the first part. (A) General issues (A.1) Intended expansion of the Port# registry to Service Names The -02 draft revision has proposed to expand the Port Number registry to also cover "Service Names" -- independent of the assignment of port numbers to applications/services. There are lots of reasons to not do that in the proposed form. After discussions with driving forces from the Applications Area, draft-gudmundsson-dns-srv-iana-registry-03.txt has reinforced and reconciled the proposal for a dedicated Service Prefix registry. Please refer to that draft for distinguishing details. For terminological clarity, the sketch of arguments below uses the terminology established in the context of DNS and the SRV RR specification (RFC 2782), as used in that draft: o Service label - the 1st label in the owner name of a SRV RR (up to 63 characters, optionally including a leading underscore character), o Protocol label - the 2nd label in the owner name of a SRV RR (including a leading underscore character), o Service Prefix - the combination of the above (used with SRV RRs), whereas the term "Service Name" is used as in the iana-ports draft for the existing designation of a service in the port number registry (not including a leading underscore character). Here are the primary aspects that come to mind regarding the nature and implementation of registration services for Port Numbers and Service Prefixes: (a) Since there is an established and IETF-documented practice for the use of "overlay" / "substrate" SRV Protocol labels, Service Labels making use of these should be registered in a similar manner as others containing proper "transport" Protocols, under the same procedural rules. The database proposed in draft-tsvwg-iana-ports-02 is neither prepared to, nor suitable for, also accepting the registration of such Service Prefixes not related to IETF transport protocols. Reclaiming the registration authority for 'pure' transport protocol labels (currently: _tcp, _udp, _dccp, and _sctp) by the Port Numbers registry would unnecessarily and confusingly split the SRV service label and prefix namespaces into two parts, one covered by the Port Numbers registry, one by another registry; that would make service label registration and namespace management ugly and confusing. (b) Most legacy applications with registered port numbers are not prepared to use SRV RRs (yet); it does not make sense to proactively register myriads of labels without having any documentation on the use of service discovery for that service, and without consent and knowledge of the original applicants for port number assignment. For fulfilling its purpose, a Service Prefix registry should only contain entries for applications and services indeed intended and prepared to make use of service discovery. (c) For compatibility with existing databases and APIs, draft-tsvwg-iana-ports-02 essentially maintains the 'classical' size restrictions for Service Names. APIs for (dynamic) service discovery will easily admit the use of the common 63-character size for DNS labels (as established by RFCs 1034/1035), for SRV Service labels as well. Applications making use of (dynamic) service discovery based on DNS SRV have to be written to use such API, and if existing applications previously bound to an assigned port number are being upgraded to use service discovery, they need to be modified to use such API anyway. Therefore, it makes sense to leave existing databases and APIs for Service-Name-to-Port-Number lookup unchanged. (d) The imminent exhaustion of the port number space is recognized as a reason to encourage the migration to service discovery for new applications; draft-tsvwg-iana-ports-02 also acknowledges that. However, we believe that the procedures envisioned in that draft are much too heavy-weight -- and too burdensome for IANA as well -- for exerting a strong momentum towards service labels. The compound database needed for draft-tsvwg-iana-ports-02 and the Expert Review process inadequately address the needs -- of both the prospective applicants and the registry maintainers. (e) The Port Numbers registry and the SRV Service Prefix registry serve very different purposes: i) registration of and lookup of assigned port numbers ii) registration of Service Prefixes actually defined for service discovery. Due to the vastly different sice of the available namespace, both registries need different assignment/registration policies. For the Service Prefixes (with the exception of the establishment of new Protocol Labels), an extremely lightweight procedure is needed where the role of the IANA is confined to checking uniqueness (avoiding registry-internal collisions and collisions of new Service Labels with Service Names already registered in the Port Numbers registry for other services, as specified in detail in draft-gudmundsson-dns-srv-iana-registry-03) and ensuring precedence (by first-come-first-served principle). Basically: No *assignment* function is needed in this registry, only *registration*. The Service Label registry is expected to grow rapidly. The Port Number registry is heavily constrained by the 16-bit namespace available, with the additional pressure resulting from the security critical need for client port randomization to only assign as few as possible additional port numbers. It is the basic nature of such restricted namespace that the IANA registry for it needs to be under *assignment* paradigm. The port number registry should be regarded as "almost closed" (reserved for cases where service discovery is impossible), and it needs rigid and tight management and strict IANA policy. Merging such different registries appears as a nightmare for IANA and prospective applicants, and all 'consumers' of the registry. The complicated amalgamated specification needed for the IANA procedures for such registry is contrary to the principles of clarity and simplicity. (f) The management of a narrow/scarce namespace (port numbers) should not be conflated with the management of an ample namespace; hence the need to have two independent registries, with existing service names in the Port Numbers registry implicitly reserved for use as Service Labels as well (for all Protocols) for the same application. (g) New applications/services initially registering a SRV Service Prefix but not applying for the assignment of a dedicated port number are very unlikely to do that later. For sanity, the Port Numbers registry should not accept any Service Name equivalent to a Service Label already registered for a different application/service in the SRV Service Prefix registry. (A.2) Section 1, 2nd para -- transport session identifiers The draft says: [...], and the combination of source and destination port numbers together with the IP addresses of the communicating end systems uniquely identifies a session of a given transport protocol. Just a few weeks ago, the CALIPSO RFC has been published (RFC 5570), which contains an updating correction for RFC 793 with regard to the full identification tuple for transport sessions. Although that RFC has restricted scope, it might be worth noting that the transport session identifier generally has an additional component, in order to allow compartmented MLS systems to conform with preexisting security standards. (A.3) Terminological precision: "namespace" vs. "registry" The draft repeatedly confuses "namespace" and "registry". The scarce resource is the (16-bit) port number space, not the Registry (cycles of the IANA or filespace in their data bases). Some related details and suggested corrections are included in part (B) below. (A.4) Roles of port numbers: confusion and lack of precision The draft does not make the proper distinction between the various categories of ports: a) per connection: client (ephemeral) vs. server / service port (exception: peer-to-peer applications using the same port number on both ends of a transport session) b) per packet: source port vs. destination port Since the draft addresses the registry of ports assigned to services, it is inappropriate and confusing to use a term from category b) in defining the scope of the draft. Hence, the 3rd para of Section 1 needs to be adjusted: Hosts running services, hosts accessing services on other hosts, and intermediate devices (such as firewalls and NATs) that restrict services need to agree on which service corresponds to a particular | destination port. [...] ---^^^^^^^^^^^ Hosts running services, hosts accessing services on other hosts, and intermediate devices (such as firewalls and NATs) that restrict services need to agree on which service corresponds to a particular | server port. [...] ^^^^^^ Similarly, in the 5th para the designation of the mentioned port numbers as a service port is a necessary clarification, needed to avoid inappropriately streching the applicability of the draft to client ports as well: Designers of applications and application-level protocols may apply to IANA for an assigned port number and service name for a specific application, and may - after successful registration - assume that no | other application will use that port number and service name for its communication sessions. [...] --- Designers of applications and application-level protocols may apply to IANA for an assigned port number and service name for a specific application, and may - after successful registration - assume that no | other application will use that server port number and service name ^^^^^^^^ for its communication sessions. [...] A similar clarification is needed in Section 4, 1st para, and in other places; for examples please see (B.4) and (B.7) below! (A.5) Reminder on ambiguity of port numbers observed in the wild Deliberate abuse of the simplified related to the statement in Section 1 quoted in (A.2) by policy setting entities is a common source of trouble for clients that do not provide a particular service with an assigned unique port number and hence should be free to use that port number as an ephemeral (client) port number for any application. Only stateful filtering of connection oriented transport sessions (e.g. TCP) or perhaps -- with restricted probability of success -- deep inspection of connectionless (e.g. UDP) packets is able to determine the actual role of the communicating peers and hence the significance of port numbers occurring in packets subject to filtering decisions, for the purpose of identifying applications / services. I strongly recommend that this issue be discussed in the Security considerations as well. (A.6) Registration template in Section 6.1 It does not make much sense to define differing policies for the two port number ranges and _not_ providing the applicant with a possibility to request a port number from the particular range desired. I strongly suggest to make the (still missing) range designation and the kind of the application (new / update) the initial items in the registration template specified in Section 6.1. Alternatively, the 'wildcard' "ANY" mentioned in the 4th bullet of Section 6.1 should be re-specified to be either "ANY WELL KNOWN" or "ANAY REGISTERED" (or similar). Further, the bullets in 6.1 are inconsistent regarding the admittance of an application for multiple ports. Most bullets talk about "port" in singular (only), but the 4th bullet ( labelled "Port Number:" (!) ) out of the blue talks about "port number(s)" and "port numbers". Most likely, singular "port number" should be used uniformly. (B) (Mostly) Editorials (B.1) Abstract Please use the common spelling of RFC designations within prose text, with a space character between "RFC" and the RFC number. In the 2nd para of the Abstract: s/RFC2780/RFC 2780/ s/RFC4340/RFC 4340/ (B.2) Section 1, 4th para -- singular/plural mismatch, clarification Please correct: Applications either use numeric port numbers directly, look up port numbers based on service names via system calls such as getservbyname() on UNIX, or - more recently - use service names to | look up a service resource records (SRV RRs) [RFC2782] via the Domain ^ ^? Name System (DNS) [RFC1034] in a variety of ways [RFC1078] [I-D.cheshire-dnsext-dns-sd][I-D.cheshire-dnsext-multicastdns] to | obtain the port number of a given service. --- ^ Applications either use numeric port numbers directly, look up port numbers based on service names via system calls such as getservbyname() on UNIX, or - more recently - use service names to | look up service resource records (SRV RRs) [RFC2782] via the Domain Name System (DNS) [RFC1034] in a variety of ways [RFC1078] [I-D.cheshire-dnsext-dns-sd] [I-D.cheshire-dnsext-multicastdns] to | obtain the port number of a given service instance. ^^^^^^^^^ The distinction between a "service" and a "service instance" (or "instance of a service", if you prefer) is important: the service discovery and lookup via SRV allows to host multiple logical instances of the same service on a particular system, using different server port numbers. Note: Wouldn't it be appropriate to at least mention (beyond the cited I-Ds) the DDDS already standardized in the IETF, of which various flavors are in widespread use (e.g., ENUM) ? (B.3) Section 3, last para -- missing article Please adjust: [...]. These include procedures to de-register a port number that is no longer in use, to re-use a port number allocated for one application that is no longer in use for another application, | and procedure by which IANA can unilaterally revoke a prior port ^ number registration. Section 6 discusses the specifics of these procedures. --- [...]. These include procedures to de-register a port number that is no longer in use, to re-use a port number allocated for one application that is no longer in use for another application, | and a procedure by which IANA can unilaterally revoke a prior port ^^^ number registration. Section 6 discusses the specifics of these procedures. (B.4) Section 4, 1st para The draft inappropriately talks about "namespaces for ... registries" and once more omits the important confinement on _server_ ports. Please adjust: TCP, UDP (and UDP-Lite), SCTP and DCCP use 16-bit namespaces for | their port number registries. The port registries for all these ^^^^^^^^^^^^ ^^^^ transport protocols are subdivided into three ranges of numbers, and Section 5.2 describes the IANA procedures for each range in detail: --- TCP, UDP (and UDP-Lite), SCTP and DCCP use 16-bit namespaces for their port numbers. The server port registries for all these ^ ^^^^^^^^^^^^ transport protocols are subdivided into three ranges of numbers, and Section 5.2 describes the IANA procedures for each range in detail: (B.5) Section 5 -- punctuation The bullets in Section 5 are all built of fulll sentences. Hence, please supply trailing periods (5 instances). (B.6) Section 5.1, 4th text para -- word omission In the 4th text paragraph (below the first group of bullets), the word "by" should be inserted for clarity (this kind of modification has frequently been performed by the RFC Editor in the recent past): [...] Applications and protocols are also expected to be able to efficiently use a single allocated port for multiple sessions, either | by demultiplexing multiple streams within one port, or using the allocated port to coordinate using dynamic ports for subsequent exchanges (e.g., in the spirit of FTP [RFC0959]). --- Applications and protocols are also expected to be able to efficiently use a single allocated port for multiple sessions, either | by demultiplexing multiple streams within one port, or by using the ^^^^ allocated port to coordinate using dynamic ports for subsequent exchanges (e.g., in the spirit of FTP [RFC0959]). (B.7) Section 5.2, 2nd bullet -- clarifications Here again, (A.2) and (A.3) apply. Please correct: o Ports in the Registered Ports range (1024-49151) are available for registration through IANA, and MAY be used as service identifiers | upon successful registration. Because registering a port number for a specific application consumes a fraction of the shared | resource that is the port number registry, IANA will require the ^^^^^^^^ requester to document the intended use of the port number. [...] --- o Ports in the Registered Ports range (1024-49151) are available for registration through IANA, and MAY be used as service identifiers | upon successful registration. Because registering a server port ^^^^^^^^ number for a specific application consumes a fraction of the | shared resource that is the port number space, IANA will require ^^^^^ the requester to document the intended use of the port number. [...] (B.8) Section 5.3 -- multiple issues As in (B.5) above, please supply trailing periods for the bullets (3 instances). In the last sentence of the 2nd text paragraph, the draft says: [...]. An | application MUST NOT assume that it can use a port number assigned to it for use with one transport protocol with another transport | protocol without asking IANA to convert the reservation into an ^^^^^^ assignment. Apparently, only "asking IANA" is not sufficient; the request MUST have been accepted and applied to the registry before the usage can be extended! Furthermore, the "use" to be allowed is only the use as a server port. So please rephrase, for instance: [...]. An | application MUST NOT assume that it can use a server port number ^^^^^^^ assigned to it for use with one transport protocol with another | transport protocol without having caused IANA to convert the ^^^^^^^^^^^^^ reservation into an assignment. (B.9) Section 6.1, 6th bullet -- singular/plural mismatch Please correct: o Service Code: A desired unique service code for the service associated with the registration request. Service codes are specific to the DCCP protocol [I-D.ietf-dccp-serv-codes]; the request MUST include a desired service code when the registration | requests includes DCCP as a transport protocol, and MUST NOT ^ include one otherwise. --- o Service Code: A desired unique service code for the service associated with the registration request. Service codes are specific to the DCCP protocol [I-D.ietf-dccp-serv-codes]; the request MUST include a desired service code when the registration | request includes DCCP as a transport protocol, and MUST NOT include one otherwise. (B.10) Section 8.1, 2nd para The draft says: Unfortunately, the current port number registry [REGISTRY] contains a few assigned service names that do not conform to the new naming rules. In all cases, this is because they contain illegal characters | such as asterisks, dots, plusses, slashes, or underscores. (All ^^^^^^^^^^^ current service names conform to the length requirement of 15 characters or less.) However, the table at the end of the section does not contain evidence that asterisks have been used in the past; there is no instance of a service name containing an asterisk in the table. Therefore, I suggest to drop "asterisks," from the text: Unfortunately, the current port number registry [REGISTRY] contains a few assigned service names that do not conform to the new naming rules. In all cases, this is because they contain illegal characters | such as dots, plusses, slashes, or underscores. (All current service names conform to the length requirement of 15 characters or less.) (B.11) Section 8.2, 1st para -- word omission Please insert another "for" (or perhaps better: "with") in the 1st sentence: Two Well Known ports, 1021 and 1022, have been reserved for | experimentation UDP and TCP [RFC4727]. [...] --- ^ Two Well Known ports, 1021 and 1022, have been reserved for | experimentation with UDP and TCP [RFC4727]. [...] ^^^^^^ Kind regards, Alfred. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From dwing@cisco.com Wed Sep 30 09:31:38 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 F030E3A677D; Wed, 30 Sep 2009 09:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.377 X-Spam-Level: X-Spam-Status: No, score=-6.377 tagged_above=-999 required=5 tests=[AWL=0.222, 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 qfdpDBg5wTAb; Wed, 30 Sep 2009 09:31:37 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id C8C433A659B; Wed, 30 Sep 2009 09:31:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1221; q=dns/txt; s=sjiport03001; t=1254328381; x=1255537981; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Dan=20Wing"=20|Reply-To:=20|Subject:=20Application=20referrals=20-=20GR OBJ|Date:=20Wed,=2030=20Sep=202009=2009:32:49=20-0700 |Message-ID:=20<07ab01ca41eb$a65db700$c2f0200a@cisco.com> |To:=20,=20,=20,=0D=0A=20=20=20=20=20=20=20=20,=20"'IETF=20Discussion=20Mailing=20List'"=20,=0D=0A=20=20=20=20=20=20=20=20 |Cc:=20"'Sheng=20Jiang'"=20 |MIME-Version:=201.0|Content-Transfer-Encoding:=207bit; bh=krMTXUiqIu4kT3phUnETqZrYpuXSOlFV2BcFdqSXaqI=; b=PcIuFQHlHUA1LxD0VrqKWFQ4nG0rXjaBpRjSnBCYTjjTsBZ+OnqEVUcc zTTvbcYokMvaN2TKUuTXkNXm+xjSsvaIM/A8Ye4owRannDb6MIIdSfphL daZcB+Sv9gnwEinBGFYO7z4CR+QA1oSd91VbSFAvi7UakmJ3Qi0wl+2yQ Q=; Authentication-Results: sj-iport-3.cisco.com; dkim=pass (signature verified [TEST]) header.i=dwing@cisco.com X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAN4kw0qrR7MV/2dsb2JhbACKcbYgiFsBkAgGhCeBUQ X-IronPort-AV: E=Sophos;i="4.44,481,1249257600"; d="scan'208";a="193379031" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 30 Sep 2009 16:32:53 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n8UGWooY021145; Wed, 30 Sep 2009 09:32:50 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n8UGWojD000355; Wed, 30 Sep 2009 16:32:50 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Sep 2009 09:32:50 -0700 Received: from dwingwxp01 ([10.32.240.194]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Sep 2009 09:32:49 -0700 From: "Dan Wing" To: , , , , "'IETF Discussion Mailing List'" , Subject: Application referrals - GROBJ Date: Wed, 30 Sep 2009 09:32:49 -0700 Message-ID: <07ab01ca41eb$a65db700$c2f0200a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcpB66XyIThkGbtVQJiZNN/LMtPkEQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-OriginalArrivalTime: 30 Sep 2009 16:32:49.0916 (UTC) FILETIME=[A67313C0:01CA41EB] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1221; t=1254328370; x=1255192370; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20Application=20referrals=20-=20GROBJ |Sender:=20; bh=krMTXUiqIu4kT3phUnETqZrYpuXSOlFV2BcFdqSXaqI=; b=M9zn8IEelPCptMasbWN5a6LS0CnuWnG9lx3yN9v1JD3iN9r8xDauoL/AZk FNqkP3TLG9mLJp0RI/EYz51gm/K/NgnaJDk9vpChCV44tFR3edvVoPIjejIf ysGbeFeCPNrmMfq7Sa415FdfgmHCpjrS1An1f993Jnnv0NjFzJ8UM=; Cc: 'Sheng Jiang' X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: grobj@ietf.org List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2009 16:31:39 -0000 (Please send replies to grobj@ietf.org) Today's applications usually exchange an IP address and a TCP (or UDP) port for referrals. While this works in a wide variety of situations, it has been shown insufficient with more complex networks that consist of different address realms (due to IPv4 NATs and IPv6 ULAs), different address families (IPv4 and IPv6) and new transport protocols (such as SCTP). Some applications have pursued their own mechanisms to extend their referral mechanism (e.g., draft-ietf-mmusic-ice). It is important to provide guidance to applications and network devices so that referrals can work between two applications. Such guidance is important today, and will be more important as networks become more complex with common deployments of host and network multi-homing, tunnels, VPNs, and address family translators. The mailing list GROBJ has been created to discuss Generic Referral Objects (GRO) for application referrals. Interested parties can join the mailing list at https://www.ietf.org/mailman/listinfo/grobj Draft: http://tools.ietf.org/html/draft-carpenter-behave-referral-object BoF proposal: http://www.cs.auckland.ac.nz/~brian/GROBJ-BOF.txt -d From lunohod.baikonur@googlemail.com Wed Sep 30 16:20: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 B2CB63A67EA for ; Wed, 30 Sep 2009 16:20:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.859 X-Spam-Level: X-Spam-Status: No, score=-1.859 tagged_above=-999 required=5 tests=[AWL=0.118, 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 wD-0P9V+PgrD for ; Wed, 30 Sep 2009 16:20:19 -0700 (PDT) Received: from mail-qy0-f195.google.com (mail-qy0-f195.google.com [209.85.221.195]) by core3.amsl.com (Postfix) with ESMTP id 834A93A69ED for ; Wed, 30 Sep 2009 16:20:19 -0700 (PDT) Received: by qyk33 with SMTP id 33so6520572qyk.29 for ; Wed, 30 Sep 2009 16:21:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=S+seXks5s/46wi91XevE8sPfqea42waNeZQpQ2ZHWKE=; b=ePitMM5In2P/0fJnwWsQLvK7+kJXXuzWjlRP1LEnZDHnyn+akD0WWucUzz4iEuCbNP bI1J3xzag7BM7KHSBaHi+xo27tGAvxtPmMjF5IDLLTqS1BM4TkNnTqyWCyvOJ1HgBq6W 649bzD3jdvxLKfsP4ue8Z8Rb+lXg/AUokd8Nw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=LGUspT85PgtA6zxo7TlVlVVReH14r8lHAvkgXpodukwS/zX2p+PZ+4xDMIQ72n+fBk D+RJF/cRYGeL63n9J0D9FZpoDu7QCJe2cHY+Imt48LZuaaYc8eddaqs4MrWzAvn8Ut4R nX6o4o1RLYFGk8D/49r1PGxByHPlS1EXFVrq8= MIME-Version: 1.0 Sender: lunohod.baikonur@googlemail.com Received: by 10.229.50.136 with SMTP id z8mr283537qcf.78.1254352900672; Wed, 30 Sep 2009 16:21:40 -0700 (PDT) Date: Thu, 1 Oct 2009 00:21:40 +0100 X-Google-Sender-Auth: e4d13634f98a9607 Message-ID: <29d3c4cb0909301621t9ba2035xa0269e52413e0b49@mail.gmail.com> Subject: Alexey's Apps Area Activity Report for September 2009 From: Alexey Melnikov To: Apps Discuss , alexey-melnikov-chairs@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 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, 30 Sep 2009 23:20:20 -0000 Document Status and Progress: Active documents, my action: - draft-ietf-tsvwg-iana-ports (BCP) - need to do AD-style review - draft-gudmundsson-dns-srv-iana-registry - need to discuss with authors how this relates to draft-ietf-tsvwg-iana-ports - draft-hethmon-mcmurray-ftp-hosts (Proposed Standard) - deciding if I will sponsor this document. - draft-desruisseaux-caldav-sched (Proposed Standard) - need to do AD review - draft-ietf-webdav-bind (Experimental) - need to address 2 DISCUSSes (Cullen, Robert), in particular about the document "updating the base WebDAV spec". Active documents in IETF LC or IESG review: - draft-ietf-eai-downgraded-display (Experimental) - In IESG review - RFC 3839 to Historic - In IETF LC till October 14th (despite ID tracker saying otherwise) - draft-reschke-rfc2731bis (Informational) - In IETF LC In RFC Editor's queue: - draft-ietf-vcarddav-webdav-mkcol (Proposed Standard) - in AUTH48 Published as RFCs: - draft-hollenbeck-rfc493*bis (Full Standard) - RFC 5730-5734 - draft-ietf-lemonade-streaming (Informational) - RFC 5616 - draft-ietf-ltru-4645bis (Informational) - RFC 5645 - draft-ietf-ltru-4646bis (BCP) - RFC 5646 Active documents, waiting on others: - draft-dusseault-http-patch (Unknown) - waiting for shepherding write-up and updated version before requesting IETF LC (more than 2 months) - draft-duerst-mailto-bis - performed AD-style review, waiting for revised document before deciding how to progress it - draft-ietf-eai-pop (Experimental) - new revision needed to address my AD review - draft-klensin-ftp-registry (Proposed Standard) - waiting for new revision after my AD review. - draft-cridland-acap-vendor-registry (Proposed Standard) - New revision needed. - draft-ietf-sieve-mime-loop (Proposed Standard) [as document shepherd] - waiting for the Sieve WG to come to consensus on the last remaining change to address Tim Polk's DISCUSS. - draft-daboo-srv-email (Proposed Standard) - new revision needed to address IETF LC issues - draft-ietf-eai-imap-utf8 (Experimental) - Waiting for the author to update the document as per EAI WG consensus about how multiple IMAP capabilities relate to each other. - draft-ietf-vcarddav-carddav (Proposed Standard) - waiting for the author to respond to GenArt review and also waiting for the shepherding write-up List of DISCUSSes I am currently holding: Really Old (over 2 months): draft-ietf-bfd-base-09.txt draft-ietf-ntp-ntpv4-proto-11.txt draft-mraihi-inch-thraud-08.txt draft-ietf-mmusic-sdp-capability-negotiation-10.txt draft-ietf-avt-rtcpssm-18.txt draft-ietf-dime-diameter-qos-11.txt Old (3 weeks - 2 months): draft-ietf-netconf-partial-lock-09.txt draft-ietf-ipfix-export-per-sctp-stream-03.txt draft-ietf-ntp-dhcpv6-ntp-opt-04.txt draft-wilde-sms-uri-19.txt draft-ietf-ospf-manet-or-02.txt New or recently updated (last 3 weeks): draft-housley-tls-authz-extns-08.txt [updated] draft-ietf-nea-pa-tnc-05.txt [updated] draft-ietf-nea-pb-tnc-05.txt [updated] draft-drage-sipping-service-identification-03.txt draft-ietf-calsify-2446bis-09.txt draft-peterson-rai-rfc3427bis-03.txt draft-ietf-mip4-generic-notification-message-12.txt draft-ietf-pkix-ta-format-03.txt Cleared DISCUSSes: draft-ietf-ltans-dssc draft-rosenberg-sip-app-media-tag draft-ietf-geopriv-http-location-delivery draft-ietf-ospf-hmac-sha draft-ietf-ipfix-file draft-ietf-ipfix-exporting-type Other activities/actions: Done: - VWRAP (formely OGPX) WG got charted - application/xslt+xml MIME type registration was reviewed for IESG Ongoing: - Discussing BOFs for Hiroshima (Generic Referral Objects (GROBJ), IRI, DECADE) - Acting as a document shepherd (not as the responsible AD) for SASL GS2 My action: - Finalize LTRU Language Tag Reviewer selection - draft-ietf-sasl-scram (my own document) is past IETF LC, need to update to address IETF LC/GenArt comments - Need to finalize registration of application/3gpp-ims+xml MIME type - Need to review 3 more MIME type registrations from W3C - Need to revise iMIP draft (my own document) - Need to finish IMAP Keyword registry document (Lisa agreed to sponsor the document) - 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 - draft-ietf-sieve-external-lists (my own document) - needs updating Waiting for others: - Suggestion to move LMTP to Standard Track (Ned Freed agreed to update the document, then responded that John Myers is interested to do this himself. 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 - active discussion about whether the WG should get away from special EAI email address syntax. Some discussion about dependendencies between IMAP capabilities specified in the EAI IMAP document. Downgraded display document in IESG review. 2) Lemonade [In shutting down state] - one remaining document will move to the Sieve WG 3) LTRU [In shutting down state] - all documents published as RFC. Finalizing decision about Language Tag Expert Reviewers. 4) MORG - updated SORTDISPLAY document got posted 5) VCARDDAV - Some discussion on the mailing list about whether vCardDAV should require support for vCard 4.0 (consensus that it should). 6) YAM - discussion about IESG review template for 8BITMIME document. Discussion about RFC 5321 errata.