From yusuke.doi@toshiba.co.jp Thu Mar 1 01:26:49 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 336CD21F8639 for ; Thu, 1 Mar 2012 01:26:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.089 X-Spam-Level: X-Spam-Status: No, score=-4.089 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0d+C3+ngXe8A for ; Thu, 1 Mar 2012 01:26:48 -0800 (PST) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id 5D66321F8638 for ; Thu, 1 Mar 2012 01:26:48 -0800 (PST) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id q219QkTa012187 for ; Thu, 1 Mar 2012 18:26:46 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id q219QkqB024228 for apps-discuss@ietf.org; Thu, 1 Mar 2012 18:26:46 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id UAA24227; Thu, 1 Mar 2012 18:26:46 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id q219QkpU025068 for ; Thu, 1 Mar 2012 18:26:46 +0900 (JST) Received: from spiffy21.isl.rdc.toshiba.co.jp by toshiba.co.jp id q219QWF6010717; Thu, 1 Mar 2012 18:26:32 +0900 (JST) Received: from [133.196.16.94] (ncg-dhcp94.isl.rdc.toshiba.co.jp [133.196.16.94]) by spiffy21.isl.rdc.toshiba.co.jp (Postfix) with ESMTPS id B63DE97CC2; Thu, 1 Mar 2012 18:26:45 +0900 (JST) Message-ID: <4F4F40D3.3040401@toshiba.co.jp> Date: Thu, 01 Mar 2012 18:26:43 +0900 From: Yusuke DOI User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Jari Arkko References: <4F464C15.6010006@piuha.net> In-Reply-To: <4F464C15.6010006@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , General discussion of application-layer protocols Subject: Re: [apps-discuss] SenML X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 01 Mar 2012 09:26:49 -0000 Hi, I have a question on EXI use. Is it practical to allow both strict (SHOULD) and non-strict (MAY) ? In this case, some nodes may not have non-strict grammar. So, nonstrict-capable-and-extended-sender and strict-no-extension-receiver must make some agreement to make a communication in strict mode. IMHO, I like strict schema-informed (because it can reduce or eliminate dynamic memory allocation). Regards, Yusuke (2012/02/23 23:24), Jari Arkko wrote: > Hello again, > > This is another draft that we'd like to get feedback on. It is yet another component that the authors have used in their work around small and smart devices. The goal is to define a base data format that sensors and other Internet of Things devices can easily use, preferably without having to define entirely new schemes and different structures just to measure a slightly different thing. > > http://tools.ietf.org/html/draft-jennings-senml-08 > > The abstract says: > > This specification defines media types for representing simple sensor > measurements and device parameters in the Sensor Markup Language > (SenML). Representations are defined in JavaScript Object Notation > (JSON), eXtensible Markup Language (XML) and Efficient XML > Interchange (EXI), which share the common SenML data model. A simple > sensor, such as a temperature sensor, could use this media type in > protocols such as HTTP or CoAP to transport the measurements of the > sensor or to be configured. > > Comments appreciated. Necessary? Correctly defined? Improvement suggestions? > > Jari > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From zach@sensinode.com Thu Mar 1 05:33:01 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84D8521E8215 for ; Thu, 1 Mar 2012 05:33:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pye2yysJMsAK for ; Thu, 1 Mar 2012 05:33:00 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 6BEEE21E8233 for ; Thu, 1 Mar 2012 05:33:00 -0800 (PST) Received: from [213.145.205.237] ([213.145.205.237]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q21DWq7a015476; Thu, 1 Mar 2012 15:32:53 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <4F4F40D3.3040401@toshiba.co.jp> Date: Thu, 1 Mar 2012 15:32:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2355688C-D382-48EB-A2B7-7251C57AD6F0@sensinode.com> References: <4F464C15.6010006@piuha.net> <4F4F40D3.3040401@toshiba.co.jp> To: Yusuke DOI X-Mailer: Apple Mail (2.1084) Cc: Cullen Jennings , General discussion of application-layer protocols Subject: Re: [apps-discuss] SenML X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 01 Mar 2012 13:33:01 -0000 Hi Yusuke, Our main use case for the senml+exi representation is for strict mode. = We believe the vast majority of implementations will be configured in = this mode as it makes the most sense for M2M applications as you point = out. The only reason we included a MAY for non-strict was to allow such = use. However if as you point out that might cause interoperability = problems, I would be in favor of making strict mode a MUST. Thanks! Zach On Mar 1, 2012, at 11:26 AM, Yusuke DOI wrote: > Hi, >=20 > I have a question on EXI use. >=20 > Is it practical to allow both strict (SHOULD) and non-strict (MAY) ? >=20 > In this case, some nodes may not have non-strict grammar. So, = nonstrict-capable-and-extended-sender and strict-no-extension-receiver = must make some agreement to make a communication in strict mode. >=20 > IMHO, I like strict schema-informed (because it can reduce or = eliminate dynamic memory allocation). >=20 > Regards, >=20 > Yusuke >=20 >=20 >=20 > (2012/02/23 23:24), Jari Arkko wrote: >> Hello again, >>=20 >> This is another draft that we'd like to get feedback on. It is yet = another component that the authors have used in their work around small = and smart devices. The goal is to define a base data format that sensors = and other Internet of Things devices can easily use, preferably without = having to define entirely new schemes and different structures just to = measure a slightly different thing. >>=20 >> http://tools.ietf.org/html/draft-jennings-senml-08 >>=20 >> The abstract says: >>=20 >> This specification defines media types for representing simple sensor >> measurements and device parameters in the Sensor Markup Language >> (SenML). Representations are defined in JavaScript Object Notation >> (JSON), eXtensible Markup Language (XML) and Efficient XML >> Interchange (EXI), which share the common SenML data model. A simple >> sensor, such as a temperature sensor, could use this media type in >> protocols such as HTTP or CoAP to transport the measurements of the >> sensor or to be configured. >>=20 >> Comments appreciated. Necessary? Correctly defined? Improvement = suggestions? >>=20 >> Jari >>=20 >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From zach@sensinode.com Thu Mar 1 05:45:50 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9831021F8BEC for ; Thu, 1 Mar 2012 05:45:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H1ofBCcOzXrw for ; Thu, 1 Mar 2012 05:45:49 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 8A5DE21F8BE3 for ; Thu, 1 Mar 2012 05:45:48 -0800 (PST) Received: from [213.145.205.237] ([213.145.205.237]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q21DjjFr018140; Thu, 1 Mar 2012 15:45:46 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Zach Shelby In-Reply-To: <1CE2FB42E90B614C98BC172FAB12D4C002D3FCFF8A@DEMCHP99E55MSX.ww902.siemens.net> Date: Thu, 1 Mar 2012 15:45:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <52B10DF8-11D1-44FE-8A8B-184BB0AE12F2@sensinode.com> References: <1CE2FB42E90B614C98BC172FAB12D4C002D3FCFF8A@DEMCHP99E55MSX.ww902.siemens.net> To: "Kaebisch, Sebastian" X-Mailer: Apple Mail (2.1084) Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] SenML X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 01 Mar 2012 13:45:50 -0000 Hi Sebastian, Your suggestions for optimizing the XSD for EXI use would be very = welcome. Looking forward to it!=20 Thanks, Zach=20 On Feb 29, 2012, at 6:26 PM, Kaebisch, Sebastian wrote: >=20 > Hi all,=20 >=20 > I have some improvement suggestions concerning the XSD which is used = for senML EXI coding. Right now, there are some types defined which are = not optimal for small embedded devices. E.g., attribute "t", "ut", and = "ver" are typed as "integer". I think, "int" will be enough in that = context. Furthermore, I would like to suggest to make some changes in = the XSD definitions (e.g., using enumerations) to make the EXI message = instances more compact. I will prepare an XSD proposal for the next week = for further discussions. >=20 > Best regards > Sebastian K=E4bisch >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From jari.arkko@piuha.net Thu Mar 1 05:45:51 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10DC621F8BF6 for ; Thu, 1 Mar 2012 05:45:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.241 X-Spam-Level: X-Spam-Status: No, score=-102.241 tagged_above=-999 required=5 tests=[AWL=-0.242, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oOtG6b3NBEc7 for ; Thu, 1 Mar 2012 05:45:50 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 2468121F8BFC for ; Thu, 1 Mar 2012 05:45:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 7E2572DA06; Thu, 1 Mar 2012 15:45:48 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ASqJaTSH7fWb; Thu, 1 Mar 2012 15:45:47 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 46AE52CC3C; Thu, 1 Mar 2012 15:45:47 +0200 (EET) Message-ID: <4F4F7D8B.6020604@piuha.net> Date: Thu, 01 Mar 2012 15:45:47 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Zach Shelby References: <4F464C15.6010006@piuha.net> <4F4F40D3.3040401@toshiba.co.jp> <2355688C-D382-48EB-A2B7-7251C57AD6F0@sensinode.com> In-Reply-To: <2355688C-D382-48EB-A2B7-7251C57AD6F0@sensinode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , General discussion of application-layer protocols Subject: Re: [apps-discuss] SenML X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 01 Mar 2012 13:45:51 -0000 I am in support of strict-only. IMO, you do it if you need to conserve space and code as much as possible. If you don't, pure JSON mode of SenML may actually be the right choice for you. Jari On 01.03.2012 15:32, Zach Shelby wrote: > Hi Yusuke, > > Our main use case for the senml+exi representation is for strict mode. We believe the vast majority of implementations will be configured in this mode as it makes the most sense for M2M applications as you point out. The only reason we included a MAY for non-strict was to allow such use. However if as you point out that might cause interoperability problems, I would be in favor of making strict mode a MUST. > > Thanks! > Zach > > On Mar 1, 2012, at 11:26 AM, Yusuke DOI wrote: > >> Hi, >> >> I have a question on EXI use. >> >> Is it practical to allow both strict (SHOULD) and non-strict (MAY) ? >> >> In this case, some nodes may not have non-strict grammar. So, nonstrict-capable-and-extended-sender and strict-no-extension-receiver must make some agreement to make a communication in strict mode. >> >> IMHO, I like strict schema-informed (because it can reduce or eliminate dynamic memory allocation). >> >> Regards, >> >> Yusuke >> >> >> >> (2012/02/23 23:24), Jari Arkko wrote: >>> Hello again, >>> >>> This is another draft that we'd like to get feedback on. It is yet another component that the authors have used in their work around small and smart devices. The goal is to define a base data format that sensors and other Internet of Things devices can easily use, preferably without having to define entirely new schemes and different structures just to measure a slightly different thing. >>> >>> http://tools.ietf.org/html/draft-jennings-senml-08 >>> >>> The abstract says: >>> >>> This specification defines media types for representing simple sensor >>> measurements and device parameters in the Sensor Markup Language >>> (SenML). Representations are defined in JavaScript Object Notation >>> (JSON), eXtensible Markup Language (XML) and Efficient XML >>> Interchange (EXI), which share the common SenML data model. A simple >>> sensor, such as a temperature sensor, could use this media type in >>> protocols such as HTTP or CoAP to transport the measurements of the >>> sensor or to be configured. >>> >>> Comments appreciated. Necessary? Correctly defined? Improvement suggestions? >>> >>> Jari >>> >>> _______________________________________________ >>> apps-discuss mailing list >>> apps-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/apps-discuss >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss From walter.stanish@gmail.com Thu Mar 1 07:31:20 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F26821E81E1 for ; Thu, 1 Mar 2012 07:31:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a-4p6T897DmN for ; Thu, 1 Mar 2012 07:31:19 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2F93221E8163 for ; Thu, 1 Mar 2012 07:31:19 -0800 (PST) Received: by mail-tul01m020-f172.google.com with SMTP id eh20so1036821obb.31 for ; Thu, 01 Mar 2012 07:31:19 -0800 (PST) Received-SPF: pass (google.com: domain of walter.stanish@gmail.com designates 10.182.188.36 as permitted sender) client-ip=10.182.188.36; Authentication-Results: mr.google.com; spf=pass (google.com: domain of walter.stanish@gmail.com designates 10.182.188.36 as permitted sender) smtp.mail=walter.stanish@gmail.com; dkim=pass header.i=walter.stanish@gmail.com Received: from mr.google.com ([10.182.188.36]) by 10.182.188.36 with SMTP id fx4mr2226931obc.7.1330615879108 (num_hops = 1); Thu, 01 Mar 2012 07:31:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=18Ijw13mq0xPzbZtDDNBDqtCdob50/P9KLiqO0fGauU=; b=eV21kj70wtPxV1726ZlX+35UyH3dFICGcHry5z7k6mMUSp7MtSTez45HRAaA/dMll4 OJcx8JdrsVzoYtdiJFJT5iPie1+i6b+KwZUglN5CMEyfx8DEQjEZNKQ0h5QIFyAo0lFJ PHIfhVk153e1G7TBH7AzSLpCYOeFMWisgK3LY= MIME-Version: 1.0 Received: by 10.182.188.36 with SMTP id fx4mr1929712obc.7.1330615879044; Thu, 01 Mar 2012 07:31:19 -0800 (PST) Received: by 10.60.15.232 with HTTP; Thu, 1 Mar 2012 07:31:19 -0800 (PST) Date: Thu, 1 Mar 2012 22:31:19 +0700 Message-ID: From: Walter To: apps-discuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [apps-discuss] Proposal for a Finance Area Mailing List X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 01 Mar 2012 15:32:21 -0000 Hi there. This message is posted at the request of the Application Area Managers as the culmination of email interaction dating back to December 15, 2011. We seek the establishment of a mailing list for the discussion of financial area protocols. Recently Payward Inc. authored two drafts: https://datatracker.ietf.org/doc/draft-iiban/ https://datatracker.ietf.org/doc/draft-imic/ The drafts propose means for financial endpoint identification and financial market identification. They are of wide potential interest for alternate financial networking, however they are missing a critical and complex reason to deploy them widely, which is an inter-institutional protocol for transaction quotation, negotiation, reporting and state management. A possible solution in this area will be presented in an upcoming draft, essentially seeking to provide a mechanism to replace established protocols (ISO20022, FIX) with an open, non-legacy alternative with adequate flexibility to support emerging digital financial networks. To illustrate, the problem statement for the as yet unpublished draft is as follows. ============================================================ Certain functionality required by modern financial systems is not presently available in open, legacy-free, adequately globalized protocols. This functionality includes: * Settlement and reversal / cancellation term negotiation * Exchange rate negotiation * Latency calculation / negotiation * Fee, tax and discount calculation / negotiation * Arbitrary currency / asset support * Multi-currency / asset transaction support * Quotation support * Multiple settlement path support * Optional support for in-band settlement (sometimes known as DVP) * High precision decimal value support * Arbitrary financial settlement topology support * Arbitrary communications topology support Given this situation, it makes sense to propose a legacy-free, adequately extensible protocol for internet-based financial exchange. ============================================================ In addition to our own work above, most of you are probably aware of some of the various other efforts going on in the financial world. These efforts include mobile finance, digital currencies and settlement systems, private currency markets, new transaction protocols, scalable non fiat-currency based community-centric transaction systems, and other projects. A few examples: - Bitcoin: http://bitcoin.org/ - CES: http://ces.org.za/ - Ripple: http://ripple-project.org/ - W3C Web Payments: http://www.w3.org/community/webpayments/ At this stage some discussions have already occurred in public forums with reference to the drafts that Payward Inc. has published and the potential for a greater community involvement in exploring potential solutions: http://bit.ly/v6n2tk (The Bitcoin Trader) http://bit.ly/xpMxQ3 (Bitcoin Development list) http://bit.ly/zpVHms (Ripple Users) Unfortunately, due to the project-oriented nature of each of these forums it is difficult to focus on issues that exceed individual project scope either affect or have the potential to affect the wider internet community. Therefore Iwebelieve that it would be useful to try to draw representatives of the various projects together to discuss such issues via a mailing list hosted at the IETF, with the goal to discuss and develop solutions to problems in established and emerging financial networks. The IETF specifically can provide: 1. Transparency and community examination of a proven standards development process 2. Access to IANA: an established, internationally credible third party for registry management (very useful to build trust in alternate financial systems) 3. Access to functional, supplementary services such as document distribution. We therefore request the establishment of a financial area mailing list. Feedback and statements of interest are hereby requested. Regards, Walter Stanish Payward Inc. From maxpassion@gmail.com Thu Mar 1 07:49:23 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF9721F8AD3 for ; Thu, 1 Mar 2012 07:49:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.385 X-Spam-Level: X-Spam-Status: No, score=-3.385 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 54rWfyXTrgm1 for ; Thu, 1 Mar 2012 07:49:21 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id C4C9121E8207 for ; Thu, 1 Mar 2012 07:49:21 -0800 (PST) Received: by ggmi1 with SMTP id i1so328181ggm.31 for ; Thu, 01 Mar 2012 07:49:21 -0800 (PST) Received-SPF: pass (google.com: domain of maxpassion@gmail.com designates 10.50.135.66 as permitted sender) client-ip=10.50.135.66; Authentication-Results: mr.google.com; spf=pass (google.com: domain of maxpassion@gmail.com designates 10.50.135.66 as permitted sender) smtp.mail=maxpassion@gmail.com; dkim=pass header.i=maxpassion@gmail.com Received: from mr.google.com ([10.50.135.66]) by 10.50.135.66 with SMTP id pq2mr5051006igb.32.1330616961281 (num_hops = 1); Thu, 01 Mar 2012 07:49:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4T1Oc1A993Sv25w/3LppovVx1Fbk07+XR+3DrXHmVl4=; b=gfjFrub97EGg+DjFF9youhpDxfLvdq2a/PsHxbl0gg7mTSN+oB9qywg5BUlXR+pppx e3K8ypiN7FxRdbdEKFYTceam8c4mspfiTZihu8nRuyYa/JdNLidfJ5atKyRDe6tQkOaq pMFWFt8JPG8VSD/eBuloiTHAbStbYS6YXDkT4= MIME-Version: 1.0 Received: by 10.50.135.66 with SMTP id pq2mr4158170igb.32.1330616961228; Thu, 01 Mar 2012 07:49:21 -0800 (PST) Received: by 10.42.161.74 with HTTP; Thu, 1 Mar 2012 07:49:21 -0800 (PST) In-Reply-To: <4F464C15.6010006@piuha.net> References: <4F464C15.6010006@piuha.net> Date: Thu, 1 Mar 2012 23:49:21 +0800 Message-ID: From: liu dapeng To: Jari Arkko Content-Type: text/plain; charset=ISO-8859-1 Cc: Cullen Jennings , General discussion of application-layer protocols Subject: Re: [apps-discuss] SenML X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 01 Mar 2012 15:49:23 -0000 Hi all, Seems SenML only support gathering information from the sensors. What if people want to control the sensor, e.g. send a command to and expect a response from the sensor? regards, Dapeng Liu 2012/2/23, Jari Arkko : > Hello again, > > This is another draft that we'd like to get feedback on. It is yet another > component that the authors have used in their work around small and smart > devices. The goal is to define a base data format that sensors and other > Internet of Things devices can easily use, preferably without having to > define entirely new schemes and different structures just to measure a > slightly different thing. > > http://tools.ietf.org/html/draft-jennings-senml-08 > > The abstract says: > > This specification defines media types for representing simple sensor > measurements and device parameters in the Sensor Markup Language > (SenML). Representations are defined in JavaScript Object Notation > (JSON), eXtensible Markup Language (XML) and Efficient XML > Interchange (EXI), which share the common SenML data model. A simple > sensor, such as a temperature sensor, could use this media type in > protocols such as HTTP or CoAP to transport the measurements of the > sensor or to be configured. > > Comments appreciated. Necessary? Correctly defined? Improvement suggestions? > > Jari > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > -- ------ Best Regards, Dapeng Liu From trammell@tik.ee.ethz.ch Wed Feb 29 08:37:16 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5B7521F872A; Wed, 29 Feb 2012 08:37:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.19 X-Spam-Level: X-Spam-Status: No, score=-6.19 tagged_above=-999 required=5 tests=[AWL=-0.491, BAYES_00=-2.599, J_CHICKENPOX_57=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5bA6RKz3ARdd; Wed, 29 Feb 2012 08:37:15 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id AFE9521F8724; Wed, 29 Feb 2012 08:37:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id D474AD9321; Wed, 29 Feb 2012 17:37:00 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id klTiYuATt3kL; Wed, 29 Feb 2012 17:37:00 +0100 (MET) Received: from pb-10243.ethz.ch (pb-10243.ethz.ch [82.130.102.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: briant) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 2E781D9305; Wed, 29 Feb 2012 17:37:00 +0100 (MET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Brian Trammell In-Reply-To: <4F4DFDB7.4090400@it.aoyama.ac.jp> Date: Wed, 29 Feb 2012 17:36:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9C347097-7049-4D94-9269-1019B1181956@tik.ee.ethz.ch> References: <4F4DFDB7.4090400@it.aoyama.ac.jp> To: =?iso-8859-1?Q?Martin_J=2E_D=FCrst?= X-Mailer: Apple Mail (2.1257) X-Mailman-Approved-At: Thu, 01 Mar 2012 08:33:48 -0800 Cc: "" , draft-ietf-mile-template@tools.ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-mile-template-02 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 29 Feb 2012 16:37:17 -0000 Hello, Martin, Many thanks for your (thorough!) review! Replies to these points, = inline. On Feb 29, 2012, at 11:28 AM, Martin J. D=FCrst wrote: > I have been selected as the Applications Area Directorate reviewer for = this draft (for background on appsdir, please see = http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate)= . >=20 > Please resolve these comments along with any other comments you may = receive. Please wait for direction from your document shepherd or AD = before posting a new version of the draft. >=20 > Document: draft-ietf-mile-template-02 > Title: Guidelines for Defining Extensions to IODEF > Reviewer: Martin D=FCrst > Review Date: 2012/02/29 >=20 >=20 > Summary: This document may be ready for publication as a BCP after = fixing some issues. >=20 >=20 > Mayor Issues: >=20 > This draft is extremely short (the main text is less than three = pages). I'm not at all sure if it is worth spending a BCP number on it. = Given the fact that it's a deliverable of the mile WG, for the rest of = this review, I'm assuming that this has been discussed before, and the = answer was positive. However, I'm nevertheless seriously wondering = whether it would not be better to have a bit more experience with actual = extension documents before putting best current practice in RFC form. (I = can only see two extension documents at = http://datatracker.ietf.org/wg/mile/; experience from both the IETF and = the W3C shows that it may take considerable time to get extensions = right.) The status of the draft was indeed discussed in the WG, and we were = indeed expecting a discussion on its intended status after sending it = up. The content of the template itself is essentially informational: we = have a lot of contributions from people just coming into the IETF = community, so we wanted a template to help jumpstart these authors's = efforts.=20 On the other hand, the IANA note requires a standards action. BCP was = the result, but we agree it's a little weird. > Section 6, IANA Considerations, says: > [IANA NOTE: The authors request that IANA include a note at the top > of http://www.iana.org/assignments/xml-registry/schema.html, stating > "Changes to the XML Schema registry for schema names beginning with > 'urn:ietf:params:xml:schema:iodef' are subject to an additional = IODEF > Expert Review [RFC5226]," and naming the designated expert.] > The example in the appendix = (urn:ietf:params:xml:schema:iodef-myextension-1.0) shows that "names = beginning with > 'urn:ietf:params:xml:schema:iodef" refers to a simple textual prefix = match. I'd expect that this is rather difficult to implement for IANA, = and it definitely doesn't scale well at all (e.g. if other frameworks = also add such restrictions). It would probably be better to have a = separate registry e.g. under urn:ietf:params:xml:schema:iodef: or = urn:ietf:params:xml:iodef-extension-schema: or some such. I suppose we could use a separate registry if it simplifies things (we = honestly hadn't considered the scalability issues that would result from = this being a precedent, good point), but there are already extensions in = the present registry following the "textual match" semantics: iodef-phish-1.0 urn:ietf:params:xml:schema:iodef-phish-1.0 [RFC5901] iodef-rid-1.0 urn:ietf:params:xml:schema:iodef-rid-1.0 [RFC6045] iodef-rid-2.0 urn:ietf:params:xml:schema:iodef-rid-2.0 = [RFC-ietf-mile-rfc6045-bis-11.txt] So, we'd have to split the registry.=20 It also appears that "subregistries" (e.g. = urn:ietf:params:xml:schema:pidf:*) are kept in the same registry, so I'm = not sure whether 'urn:ietf:params:xml:schema:iodef-' is harder to manage = than 'urn:ietf:params:xml:schema:iodef:'. Perhaps the right thing here is to refer this to IANA? > Minor Issues: >=20 > The text uses RFC 2119, but also uses the same keywords = non-capitalized, which will lead to confusion. Examples: >=20 > Note that in this final case, the extension will not be directly > interoperable with IODEF implementations, and must "unwrap" the = IODEF > document from its container... (Section 4) >=20 > ENUM for enumerated types; allowable values of the enumeration > must be defined in the attribute definition >=20 > In addition to schema reviews required by > IANA, these registry requests should be accompanied by a review by > IODEF experts to ensure the specified AdditionalData and/or ... > (Intro, where one usually tries to avoid normative stuff) >=20 > Lots and lots of 'should' in Appendix A, which all seem to be > intended normatively and therefor would better go into the main = text. Good points all; we'll have a look at these and make a full = 2119-language pass. Note of course that some of the non-2119 words are = not intended normatively. As for upgrading the shoulds in Appendix A and moving them up, I'm not = sure that that would make the document easier to use. These are advisory = (appendix A is essentially the Informational part of the document), and = bringing them outside the template makes them harder to refer to. = Authors are intended to follow the template by copying the document = template out of appendix A (this becomes much easier when they have the = XML source), then following the instructions to fill it in. (Indeed, I see on review here that we're missing A.7.1 normative = references and A.7.2 informative references) > The shortness of the document tends to give the impression that = writing an extension is easy. However, lots of details about extensions = are already given in RFC5070, and it should be stressed very clearly = that a good knowledge of RFC 5070 is a precondition to writing an = extension. In addition, the document should not only reference RFC 5070, = but also give more explicit pointers with section numbers in more cases. Good point; we'll do this. > Section 4 says: > The attributes which can be extended in this way are defined in = Section > 5.1 of [RFC5070], and limited to the following: [followed by long = list] > This let me think that the list is just a copy of a similar list in = RFC5070. But this is not the case. To get the list, the schema in = RFC5070 has to be searched for ext- attributes. So these attributes are = not actually defined in Section 5.1. Please clarify. We can add section references for each of these. > Also, please tweak the format so such a simple list doesn't take up = almost a whole page. Also please shortly explain the Element@attribute = syntax, which is part of XML 'slang' but not a formal part of the XML = core spec. Check. > The last paragraph of Section 4 says: > XML extensions within an AdditionalData or RecordItem element use a > dtype of "xml", and SHOULD define a schema for the root element > within the AdditionalData or RecordItem attribute. > The term "root element" is very clearly defined (and important) in = XML, and the use here is different from this established use. Please = change. Indeed. Is there a preferred terminology for the root of a subtree = within a document? > Security Section: > It is a general problem of this document that most of the meat is in = the Appendix, but the problem is most apparent here. The Security = Section should clearly *at least* mention that there is additional = security stuff in the Appendix. I'm confused here. Where's the security stuff in the appendix? > p. 9, A.4.1. IODEF Data Types: This looks like a simple repetition = from RFC 5070. A pointer should be better. Also, there are some = inaccuracies: >=20 >=20 > "ML_STRING (for strings in encodings other than that of the enclosing = document)": Here, RFC 5070 says: > STRING data that represents multi-character attributes in a language > different than the default encoding of the document is of the > ML_STRING data type. >=20 > The ML_STRING data type is implemented as an "iodef:MLStringType" in > the schema. > RFC 5070 hopelessly mixes up languages and encodings. This draft = shouldn't make things worse by claiming that XML can contain blobs of = data encoded with a different encoding that the overall entity. = (external entities can have a different encoding, but that's a separate = matter). >=20 >=20 > "DATETIME for ISO 8601:2000 [RFC3339] encoded timestamps" > RFC 5070 correctly says that RFC 3339 is a subset of ISO 8601. This = draft shouldn't give the impression that they are the same. >=20 >=20 > "TIMEZONE for timezones as encoded in section 2.9 of [RFC5070]." > "as encoded in" is confusing. ", encoded as defined in" is clearer. > Same for PORTLIST. >=20 >=20 > "URL for URLs as in [RFC3986].": This repeats an error from RFC5070. = URLs are mentioned shortly in section 1.1.3 of RFC 3986, but not what's = meant here. It at least say: "URL for URIs as in [RFC3986].". It is a = problem that IRIs aren't allowed, but that's a problem that has to be = fixed in RFC 5070, not here. I think we'd like to keep this section in the template, so we'll make = these fixes. > Nits: (will fix these too) > p. 4: involving integration with IODEF within -> > involving integration of IODEF within >=20 > p. 5: SHOULD define the use the "meaning": use or meaning? >=20 > p. 8, A.3. Applicability says: "The primary goal of this > section is to allow readers to see if an extension is indeed = intended > to solve a particular problem." > Are there extensions that are not intended to solve a particular = problem? Please reword. > ibid: "This should also ??? the scope" >=20 > p. 8, A.4. Extension Definition: "enumerating the new values with an > explanation of the meaning of the new value": Singular/plural > alignment problem >=20 > ibid: "or in another referenced MILE extension document": Why the = restriction on MILE? Shouldn't any IODEF extension be okay? Yep; fixed this elsewhere but missed this one... > p. 10, Section A.4: > ... IODEF:Address element, which supports IPv4 and > [RFC4291] IPv6 addresses, as well as MAC, ATM, and BGP autonomous > system numbers. > Why do IPv6 addresses need a reference, but the others don't? At = least, it should be "IPv6 addresses [RFC4291]". But why not just drop = it? "IPv6 addresses formatted as in [RFC4291]" was the intent here. > p. 10, Section A.5: "Guidance should focus > on ensuring the users of this extension do so in a secure fashion," > "do so": do what? Be more specific. >=20 > ibid: "represented by an extension": The paragraph has "this = extension" in the first line, so it should be "represented by this = extension" here. >=20 > p. 11: Appendix A.8: "given in the appendix" -> "given in Appendix A" Best regards, and thanks again! - Brian= From zach@sensinode.com Thu Mar 1 10:30:19 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1065C21F8AC0 for ; Thu, 1 Mar 2012 10:30:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.438 X-Spam-Level: X-Spam-Status: No, score=-3.438 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c2Cn8gkkHc1y for ; Thu, 1 Mar 2012 10:30:17 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id BA32121F884D for ; Thu, 1 Mar 2012 10:30:14 -0800 (PST) Received: from [192.168.1.101] (87-95-155-28.bb.dnainternet.fi [87.95.155.28]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q21IU5Rt025698; Thu, 1 Mar 2012 20:30:07 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: Date: Thu, 1 Mar 2012 20:30:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <226F435E-BC56-4D9E-84E7-1A223C3E9703@sensinode.com> References: <4F464C15.6010006@piuha.net> To: liu dapeng X-Mailer: Apple Mail (2.1084) Cc: Cullen Jennings , General discussion of application-layer protocols Subject: Re: [apps-discuss] SenML X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 01 Mar 2012 18:30:19 -0000 Hi, On Mar 1, 2012, at 5:49 PM, liu dapeng wrote: > Hi all, >=20 > Seems SenML only support gathering information from the sensors. What > if people want to control the sensor, e.g. send a command to and > expect a response from the sensor? In this version of SenML, we actually extended the model to handle = parameters, actuators and other resources typically found on embedded = devices (it really was just for sensor readings in previous versions). = We also improved its applicability to representations that result from = REST requests. To get a better picture of how SenML can be used with a = REST design for sensors, parameters, actuators and batch collections = take a look at this draft: http://tools.ietf.org/id/draft-shelby-core-interfaces-01.txt Zach --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From iesg-secretary@ietf.org Thu Mar 1 10:47:51 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D6F321E8252; Thu, 1 Mar 2012 10:47:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D81ow2CRQdIs; Thu, 1 Mar 2012 10:47:50 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C430F21E823D; Thu, 1 Mar 2012 10:47:50 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120301184750.21152.93044.idtracker@ietfa.amsl.com> Date: Thu, 01 Mar 2012 10:47:50 -0800 Cc: apps-discuss@ietf.org Subject: [apps-discuss] Last Call: (Deprecating Use of the "X-" Prefix in Application Protocols) to Best Current Practice X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 18:47:51 -0000 The IESG has received a request from the Applications Area Working Group WG (appsawg) to consider the following document: - 'Deprecating Use of the "X-" Prefix in Application Protocols' as a Best Current Practice The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-03-15. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Historically, designers and implementers of application protocols have often distinguished between "standard" and "non-standard" parameters by prefixing the latter with the string "X-" or similar constructions. In practice, this convention causes more problems than it solves. Therefore, this document deprecates the "X-" convention for textual parameters in application protocols. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-appsawg-xdash/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-appsawg-xdash/ballot/ No IPR declarations have been submitted directly on this I-D. From macar@cloudmark.com Thu Mar 1 12:11:30 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8788721E824C for ; Thu, 1 Mar 2012 12:11:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B4WomHJq78Ry for ; Thu, 1 Mar 2012 12:11:25 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 51DB321E8164 for ; Thu, 1 Mar 2012 12:11:24 -0800 (PST) Received: from [172.20.2.21] (172.20.2.21) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 1 Mar 2012 12:11:23 -0800 Message-ID: <4F4FD7EB.8080004@cloudmark.com> Date: Thu, 1 Mar 2012 12:11:23 -0800 From: Mike Acar User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.20.2.21] Subject: [apps-discuss] Feedback on draft-ietf-appsawg-json-patch-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 01 Mar 2012 20:11:30 -0000 (Resending, because my original submission seems to have been lost...) Hi, I've been asked to review the JSON Pointer and Patch draft RFCs. I've had some discussion about them off-list, and have been advised to bring my issues to the list. And so, I am. :) I've scanned the archived list discussion of the patch and pointer RFCs, so I don't think these issues have come up here already. Let me know if they have. My first concern with Patch is the test operation; http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-00 sec 4.5 defines test: 4.5. test The "test" operation tests that a value at the specified location in the target document is equal to a specified value. The operation object contains a "value" member, which specifies the value to test for. What constitutes equality when the values in question can be trees of objects and arrays? Can this even be usefully defined in general? My next concern is with locations. Currently, the locations point to the value to operate upon; in the case of "add", this pointer is to a value which does not yet exist. This conflicts with the definition of a JSON Pointer, which says: If a reference token is being evaluated against a concrete JSON document, the implementation MAY evaluate each token against a concrete value, and terminate evaluation with an error condition if a evaluation fails to resolve a concrete value. (section 4, http://tools.ietf.org/html/draft-ietf-appsawg-json-pointer-00) There's no mention of what to do if the implementation does not return an error, leaving the behavior essentially undefined. So to avoid depending upon undefined behavior, an implementation of Patch would have to parse the Pointer, remove the "target" value from the end, and then traverse the JSON objects to find the parent of the target. I think the Patch location should always point to the parent object or array. The operation object can then define the object name or array index to operate upon, along with any new value to be added or replaced, or location to be moved to, etc. So for example, { "hork":"gak" } The patch [ { "add":"/", "name":"foo", "value":"bar" } ] gives you { "hork":"gak", "foo":"bar" } I'm not wedded to this syntax, which is a bit more verbose. But I think the issue is significant: as they stand, Patch is specified to depend upon undefined behavior in Pointer. As a stylistic matter, I also think separating operation and location into different members would be easier for people to read and programs to parse; e.g. { "op": "add", "loc":"/", "name":"foo", "value":"bar" } Just looking at the "op" member is easier than testing each of add/remove/test/etc in turn. But that's a matter of taste, and it is slightly more verbose. There's a minor issue with move; section 4.4 says This operation is functionally identical to expressing a "remove" operation, followed immediately by an "add" operation at the new location with the value that was just removed. If the location in the "to" member references a member of an existing object in the target document, it is an error condition if a value at the specified location already exists. So what about moving an location to itself? If move is "functionally identical" to remove/add, then moving /a/b/c to /a/b/c is legal. On the other hand, an implementation might check the existence of "to" before performing the "move", and then throw an error. I'm ok with just defining moving a location to itself to be a no-op. I think those were my practical concerns. I have some feedback on Pointer as well, which I'll send in another thread. -- Mike Acar - - macar at cloudmark dot com From macar@cloudmark.com Thu Mar 1 12:15:10 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E649421E8273 for ; Thu, 1 Mar 2012 12:15:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MTRA+sYgys-8 for ; Thu, 1 Mar 2012 12:15:10 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 2758221F85BD for ; Thu, 1 Mar 2012 12:14:30 -0800 (PST) Received: from [172.20.2.21] (172.20.2.21) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 1 Mar 2012 12:14:29 -0800 Message-ID: <4F4FD8A5.6010603@cloudmark.com> Date: Thu, 1 Mar 2012 12:14:29 -0800 From: Mike Acar User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: IETF Apps Discuss Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [172.20.2.21] Subject: [apps-discuss] Feedback on draft-ietf-appsawg-json-pointer-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 01 Mar 2012 20:15:11 -0000 Hi, I've been asked to review the JSON Pointer and Patch draft RFCs. I've had some discussion about them off-list, and have been advised to bring my issues to the list. And so, I am. :) I've scanned the archived list discussion of the patch and pointer RFCs, so I don't think these issues have come up here already. Let me know if they have. The first issue is comparing Unicode strings. Section 4 of http://tools.ietf.org/html/draft-ietf-appsawg-json-pointer-00 says If the currently referenced value is a JSON object, the new referenced value is the object member with the name identified by the reference token. That is, if the reference token equals the name of some value within the object, move to that value. However, the tokens and values are Unicode strings; I'm not an expert in Unicode, but my impression is that testing Unicode strings for equality is not as simple as comparing sequences of bytes. For example, there are linguistic considerations: I believe German ö and oe are considered identical. There's also the question of JSON documents with different encodings; UTF8 is the default, but UTF-16 and -32 with both endiannesses are also supported. Presumably this question will disappear in practice, since implementations will operate on deserialized data structures, not on JSON texts. Could somebody with more expertise in this area comment? Perhaps this is all a solved problem, and the Pointer RFC simply needs to pick a normalization method and equality definition - or perhaps it's all so well-settled I'm seeing a problem where there is none. Another issue is that the evaluation scheme implies some application semantics. Again, section 4: If a reference token is being evaluated against a concrete JSON document, the implementation MAY evaluate each token against a concrete value, and terminate evaluation with an error condition if a evaluation fails to resolve a concrete value. It's easy to imagine a case where a Pointer refers to a deep hierarchy, e.g. /a/b/c/d, and the application semantics of following it are to create automatically any non-existent intermediate objects. My initial thought was that the Pointer RFC should explicitly say that specs which use it (e.g. Patch) should define semantics for ambiguous cases (non-unique or non-existent member names, array index out of bounds, etc). That can still result in a user of Pointer having to implement it himself, if there are no implementations which offer him precisely what he needs. Is it preferrable to explicitly say "You must make these decisions for your use case" instead of "Behavior in these cases is undefined"? -- Mike Acar - - macar at cloudmark dot com From msk@cloudmark.com Thu Mar 1 12:19:00 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CADF221E82E4 for ; Thu, 1 Mar 2012 12:19:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.604 X-Spam-Level: X-Spam-Status: No, score=-102.604 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZXV6O6c9JxbH for ; Thu, 1 Mar 2012 12:19:00 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 720E321E82DF for ; Thu, 1 Mar 2012 12:19:00 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by EXCH-HTCAS901.corp.cloudmark.com ([fe80::2966:6846:8d89:4681%12]) with mapi id 14.01.0355.002; Thu, 1 Mar 2012 12:18:59 -0800 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Thread-Topic: [apps-discuss] Feedback on draft-ietf-appsawg-json-patch-00 Thread-Index: AQHM9+d/ykpyZt+42kKhe+gEF12z9JZV4Qsw Date: Thu, 1 Mar 2012 20:18:59 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392806FAA0@exch-mbx901.corp.cloudmark.com> References: <4F4FD7EB.8080004@cloudmark.com> In-Reply-To: <4F4FD7EB.8080004@cloudmark.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [apps-discuss] Feedback on draft-ietf-appsawg-json-patch-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 01 Mar 2012 20:19:01 -0000 One other thing that came up in conversation is that the json-patch documen= t needs to make a reference (probably normative) to the json-pointer docume= nt. -MSK From macar@cloudmark.com Thu Mar 1 12:22:31 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F7AF21E81F9 for ; Thu, 1 Mar 2012 12:22:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JcHdY6SBJPfb for ; Thu, 1 Mar 2012 12:22:30 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id ABF0921E81BB for ; Thu, 1 Mar 2012 12:22:30 -0800 (PST) Received: from [172.20.2.21] (172.20.2.21) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 1 Mar 2012 12:22:30 -0800 Message-ID: <4F4FDA86.4040506@cloudmark.com> Date: Thu, 1 Mar 2012 12:22:30 -0800 From: Mike Acar User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: References: <4F4FD7EB.8080004@cloudmark.com> <9452079D1A51524AA5749AD23E00392806FAA0@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E00392806FAA0@exch-mbx901.corp.cloudmark.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.20.2.21] Subject: Re: [apps-discuss] Feedback on draft-ietf-appsawg-json-patch-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 01 Mar 2012 20:22:31 -0000 On 03/01/2012 12:18 PM, Murray S. Kucherawy wrote: > One other thing that came up in conversation is that the json-patch > document needs to make a reference (probably normative) to the > json-pointer document. It does; http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-00#section-9.1 : 9.1. Normative References [JSON Pointer] Bryan, P. and K. Zyp, "JSON Pointer", January 2012, . -- Mike Acar - - macar at cloudmark dot com From tbray@textuality.com Thu Mar 1 12:30:05 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8291121E8164 for ; Thu, 1 Mar 2012 12:30:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.068 X-Spam-Level: X-Spam-Status: No, score=-3.068 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTItpPl94Svj for ; Thu, 1 Mar 2012 12:30:04 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9320021E8032 for ; Thu, 1 Mar 2012 12:30:04 -0800 (PST) Received: by obbeh20 with SMTP id eh20so1382053obb.31 for ; Thu, 01 Mar 2012 12:30:04 -0800 (PST) Received-SPF: pass (google.com: domain of tbray@textuality.com designates 10.182.38.3 as permitted sender) client-ip=10.182.38.3; Authentication-Results: mr.google.com; spf=pass (google.com: domain of tbray@textuality.com designates 10.182.38.3 as permitted sender) smtp.mail=tbray@textuality.com Received: from mr.google.com ([10.182.38.3]) by 10.182.38.3 with SMTP id c3mr2490743obk.42.1330633804180 (num_hops = 1); Thu, 01 Mar 2012 12:30:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.38.3 with SMTP id c3mr2173181obk.42.1330633804095; Thu, 01 Mar 2012 12:30:04 -0800 (PST) Received: by 10.182.137.69 with HTTP; Thu, 1 Mar 2012 12:30:04 -0800 (PST) X-Originating-IP: [76.10.185.204] In-Reply-To: <4F4FD8A5.6010603@cloudmark.com> References: <4F4FD8A5.6010603@cloudmark.com> Date: Thu, 1 Mar 2012 12:30:04 -0800 Message-ID: From: Tim Bray To: Mike Acar Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmAaVD0t95ypp54GSESHidFDK26dhH9lIeT1sEx0UjZR6e2ihIanb5tNgp8dN0Zs+QXL0x5 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Feedback on draft-ietf-appsawg-json-pointer-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 01 Mar 2012 20:30:05 -0000 On Thu, Mar 1, 2012 at 12:14 PM, Mike Acar wrote: > However, the tokens and values are Unicode > strings; I'm not an expert in Unicode, but my impression is that testing > Unicode strings for equality is not as simple as comparing sequences of > bytes. For example, there are linguistic considerations... There are lots of considerations, the W3C once wrote a big huge complicated spec on normalization forms. I would say explicitly don=92t go there. I could see the spec advising implementors to watch out for this, but two strings are equal if they have the same number of Unicode characters and the codepoints are positionwise equal; otherwise not. -T From julian.reschke@gmx.de Thu Mar 1 12:30:14 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 543F121E8164 for ; Thu, 1 Mar 2012 12:30:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.091 X-Spam-Level: X-Spam-Status: No, score=-104.091 tagged_above=-999 required=5 tests=[AWL=-1.492, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dw7aToF0KxSf for ; Thu, 1 Mar 2012 12:30:13 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 66CD221E8032 for ; Thu, 1 Mar 2012 12:30:13 -0800 (PST) Received: (qmail invoked by alias); 01 Mar 2012 20:30:12 -0000 Received: from p5DCC2B62.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.43.98] by mail.gmx.net (mp036) with SMTP; 01 Mar 2012 21:30:12 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19MPa1xQ59M9RY1i78Q/TUCucNMSe4uhBUOhPwTeC BnW7F5JG1N3n6G Message-ID: <4F4FDC50.9090306@gmx.de> Date: Thu, 01 Mar 2012 21:30:08 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Mike Acar References: <4F4FD8A5.6010603@cloudmark.com> In-Reply-To: <4F4FD8A5.6010603@cloudmark.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: IETF Apps Discuss Subject: [apps-discuss] Identifier comparison in draft-ietf-appsawg-json-pointer, was: Feedback on draft-ietf-appsawg-json-pointer-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 01 Mar 2012 20:30:14 -0000 On 2012-03-01 21:14, Mike Acar wrote: > Hi, > > I've been asked to review the JSON Pointer and Patch draft RFCs. I've > had some discussion about them off-list, and have been advised to bring > my issues to the list. And so, I am. :) > > I've scanned the archived list discussion of the patch and pointer RFCs, > so I don't think these issues have come up here already. Let me know if > they have. > > The first issue is comparing Unicode strings. Section 4 of > http://tools.ietf.org/html/draft-ietf-appsawg-json-pointer-00 says > > If the currently referenced value is a JSON object, the new > referenced value is the object member with the name identified by > the reference token. > > That is, if the reference token equals the name of some value within the > object, move to that value. However, the tokens and values are Unicode > strings; I'm not an expert in Unicode, but my impression is that testing > Unicode strings for equality is not as simple as comparing sequences of > bytes. For example, there are linguistic considerations: I believe > German ö and oe are considered identical. No, they aren't. The spec could be made a bit clearer by saying "code point by code point", but I would think that's the default unless otherwise stated. > There's also the question of JSON documents with different encodings; > UTF8 is the default, but UTF-16 and -32 with both endiannesses are also > supported. Presumably this question will disappear in practice, since > implementations will operate on deserialized data structures, not on > JSON texts. Indeed. > ... Best regards, Julian From julian.reschke@gmx.de Thu Mar 1 12:32:58 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC79121E82C6 for ; Thu, 1 Mar 2012 12:32:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.072 X-Spam-Level: X-Spam-Status: No, score=-104.072 tagged_above=-999 required=5 tests=[AWL=-1.473, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W-VxtPUBwatJ for ; Thu, 1 Mar 2012 12:32:58 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id F028621E8032 for ; Thu, 1 Mar 2012 12:32:57 -0800 (PST) Received: (qmail invoked by alias); 01 Mar 2012 20:32:56 -0000 Received: from p5DCC2B62.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.43.98] by mail.gmx.net (mp004) with SMTP; 01 Mar 2012 21:32:56 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/Z6U0iN4PZRYFdergjoPyHvMVFa5LEWu8bxML6ik +ytu6oLOF3lYAT Message-ID: <4F4FDCF4.2000107@gmx.de> Date: Thu, 01 Mar 2012 21:32:52 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Mike Acar References: <4F4FD7EB.8080004@cloudmark.com> <9452079D1A51524AA5749AD23E00392806FAA0@exch-mbx901.corp.cloudmark.com> <4F4FDA86.4040506@cloudmark.com> In-Reply-To: <4F4FDA86.4040506@cloudmark.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Feedback on draft-ietf-appsawg-json-patch-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 01 Mar 2012 20:32:59 -0000 On 2012-03-01 21:22, Mike Acar wrote: > On 03/01/2012 12:18 PM, Murray S. Kucherawy wrote: >> One other thing that came up in conversation is that the json-patch >> document needs to make a reference (probably normative) to the >> json-pointer document. > > It does; > http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-00#section-9.1 : > > 9.1. Normative References > > [JSON Pointer] > Bryan, P. and K. Zyp, "JSON Pointer", January 2012, //tools.ietf.org/html/draft-ietf-appsawg-json-pointer-00>. Nit: that reference should actually use the standard ID reference format... Best regards, Julian From msk@cloudmark.com Thu Mar 1 12:43:36 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A420F21E8337 for ; Thu, 1 Mar 2012 12:43:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.604 X-Spam-Level: X-Spam-Status: No, score=-102.604 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7EoKcn8hmEOv for ; Thu, 1 Mar 2012 12:43:36 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id 34EDF21E8334 for ; Thu, 1 Mar 2012 12:43:36 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Thu, 1 Mar 2012 12:43:35 -0800 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Thread-Topic: [apps-discuss] Feedback on draft-ietf-appsawg-json-patch-00 Thread-Index: AQHM9+d/ykpyZt+42kKhe+gEF12z9JZV4QswgACHTwD//3+ZAA== Date: Thu, 1 Mar 2012 20:43:34 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392806FAF4@exch-mbx901.corp.cloudmark.com> References: <4F4FD7EB.8080004@cloudmark.com> <9452079D1A51524AA5749AD23E00392806FAA0@exch-mbx901.corp.cloudmark.com> <4F4FDA86.4040506@cloudmark.com> In-Reply-To: <4F4FDA86.4040506@cloudmark.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [apps-discuss] Feedback on draft-ietf-appsawg-json-patch-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 01 Mar 2012 20:43:36 -0000 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] On Behalf Of Mike Acar > Sent: Thursday, March 01, 2012 12:23 PM > To: apps-discuss@ietf.org > Subject: Re: [apps-discuss] Feedback on draft-ietf-appsawg-json-patch-00 >=20 > On 03/01/2012 12:18 PM, Murray S. Kucherawy wrote: > > One other thing that came up in conversation is that the json-patch > > document needs to make a reference (probably normative) to the > > json-pointer document. >=20 > It does; > http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-00#section-9.1: >=20 > 9.1. Normative References >=20 > [JSON Pointer] > Bryan, P. and K. Zyp, "JSON Pointer", January 2012, //tools.ietf.org/html/draft-ietf-appsawg-json-pointer-00>. Dunno how I missed that. Nevermind me (though Julian's right, the format n= eeds fixing). -MSK From pbryan@anode.ca Thu Mar 1 13:41:29 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED74B21E8261 for ; Thu, 1 Mar 2012 13:41:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H8Gm1dxXXWRk for ; Thu, 1 Mar 2012 13:41:29 -0800 (PST) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id EB81021E8217 for ; Thu, 1 Mar 2012 13:41:28 -0800 (PST) Received: from [10.0.2.11] (unknown [75.103.8.234]) by maple.anode.ca (Postfix) with ESMTPSA id 3EB9F6485 for ; Thu, 1 Mar 2012 21:41:28 +0000 (UTC) Message-ID: <1330638087.2531.7.camel@neutron> From: "Paul C. Bryan" To: apps-discuss@ietf.org Date: Thu, 01 Mar 2012 13:41:27 -0800 In-Reply-To: <4F4FD7EB.8080004@cloudmark.com> References: <4F4FD7EB.8080004@cloudmark.com> Content-Type: multipart/alternative; boundary="=-KzvRYI5tLPYFx6QGeM/p" X-Mailer: Evolution 3.2.2-1 Mime-Version: 1.0 Subject: Re: [apps-discuss] Feedback on draft-ietf-appsawg-json-patch-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 01 Mar 2012 21:41:30 -0000 --=-KzvRYI5tLPYFx6QGeM/p Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Thu, 2012-03-01 at 12:11 -0800, Mike Acar wrote: > (Resending, because my original submission seems to have been lost...) > > Hi, > > I've been asked to review the JSON Pointer and Patch draft RFCs. I've > had some discussion about them off-list, and have been advised to bring > my issues to the list. And so, I am. :) > > I've scanned the archived list discussion of the patch and pointer RFCs, > so I don't think these issues have come up here already. Let me know if > they have. > > My first concern with Patch is the test operation; > http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-00 sec 4.5 > defines test: > > 4.5. test > > The "test" operation tests that a value at the specified location in > the target document is equal to a specified value. The operation > object contains a "value" member, which specifies the value to test > for. > > What constitutes equality when the values in question can be trees of > objects and arrays? Can this even be usefully defined in general? The value within the JSON document should be equal to the value in the JSON Patch document; if these values contain objects or arrays, they must be equal (i.e. same order of elements, with the same values). > My next concern is with locations. Currently, the locations point to the > value to operate upon; in the case of "add", this pointer is to a value > which does not yet exist. This conflicts with the definition of a JSON > Pointer, which says: > > If a reference token is being evaluated against a concrete JSON > document, the implementation MAY evaluate each token against a > concrete value, and terminate evaluation with an error condition if a > evaluation fails to resolve a concrete value. > > (section 4, http://tools.ietf.org/html/draft-ietf-appsawg-json-pointer-00) An earlier draft of JSON Patch actually had separate parent node and child to add, as you demonstrate below, as well as calling out a specific "op" member. It received a number of objections, on the grounds of being too verbose. I changed the add operation to add the node specified in the pointer, and changed the language in JSON Pointer accordingly to allow for this (i.e. the MAY language instead of MUST/SHOULD). This language is admittedly still a bit awkward. > There's no mention of what to do if the implementation does not return > an error, leaving the behavior essentially undefined. So to avoid > depending upon undefined behavior, an implementation of Patch would have > to parse the Pointer, remove the "target" value from the end, and then > traverse the JSON objects to find the parent of the target. These specifications do very little to define how to handle errors beyond terminating processing and indicating an error condition. > > I think the Patch location should always point to the parent object or > array. The operation object can then define the object name or array > index to operate upon, along with any new value to be added or replaced, > or location to be moved to, etc. So for example, > > { "hork":"gak" } > > The patch > > [ { "add":"/", "name":"foo", "value":"bar" } ] > > gives you { "hork":"gak", "foo":"bar" } > > I'm not wedded to this syntax, which is a bit more verbose. But I think > the issue is significant: as they stand, Patch is specified to depend > upon undefined behavior in Pointer. > > As a stylistic matter, I also think separating operation and location > into different members would be easier for people to read and programs > to parse; e.g. > > { "op": "add", "loc":"/", "name":"foo", "value":"bar" } > > Just looking at the "op" member is easier than testing each of > add/remove/test/etc in turn. But that's a matter of taste, and it is > slightly more verbose. > > There's a minor issue with move; section 4.4 says > > This operation is functionally identical to expressing a "remove" > operation, followed immediately by an "add" operation at the new > location with the value that was just removed. > > If the location in the "to" member references a member of an existing > object in the target document, it is an error condition if a value at > the specified location already exists. > > So what about moving an location to itself? If move is "functionally > identical" to remove/add, then moving /a/b/c to /a/b/c is legal. On the > other hand, an implementation might check the existence of "to" before > performing the "move", and then throw an error. > > I'm ok with just defining moving a location to itself to be a no-op. Since it is functionally identical to removing then re-adding, then checking for the presence of the value before removing would not be functionally identical. If adding the no-op language makes this clearer, I'd be fine adding it. Paul --=-KzvRYI5tLPYFx6QGeM/p Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit On Thu, 2012-03-01 at 12:11 -0800, Mike Acar wrote: 
(Resending, because my original submission seems to have been lost...)

Hi,

I've been asked to review the JSON Pointer and Patch draft RFCs. I've 
had some discussion about them off-list, and have been advised to bring 
my issues to the list. And so, I am. :)

I've scanned the archived list discussion of the patch and pointer RFCs, 
so I don't think these issues have come up here already. Let me know if 
they have.

My first concern with Patch is the test operation; 
http://tools.ietf.org/html/draft-ietf-appsawg-json-patch-00 sec 4.5 
defines test:

    4.5.  test

    The "test" operation tests that a value at the specified location in
    the target document is equal to a specified value.  The operation
    object contains a "value" member, which specifies the value to test
    for.

What constitutes equality when the values in question can be trees of 
objects and arrays? Can this even be usefully defined in general?

The value within the JSON document should be equal to the value in the JSON Patch document; if these values contain objects or arrays, they must be equal (i.e. same order of elements, with the same values).

My next concern is with locations. Currently, the locations point to the 
value to operate upon; in the case of "add", this pointer is to a value 
which does not yet exist. This conflicts with the definition of a JSON 
Pointer, which says:

    If a reference token is being evaluated against a concrete JSON
    document, the implementation MAY evaluate each token against a
    concrete value, and terminate evaluation with an error condition if a
    evaluation fails to resolve a concrete value.

(section 4, http://tools.ietf.org/html/draft-ietf-appsawg-json-pointer-00)

An earlier draft of JSON Patch actually had separate parent node and child to add, as you demonstrate below, as well as calling out a specific "op" member. It received a number of objections, on the grounds of being too verbose. I changed the add operation to add the node specified in the pointer, and changed the language in JSON Pointer accordingly to allow for this (i.e. the MAY language instead of MUST/SHOULD). This language is admittedly still a bit awkward.

There's no mention of what to do if the implementation does not return 
an error, leaving the behavior essentially undefined. So to avoid 
depending upon undefined behavior, an implementation of Patch would have 
to parse the Pointer, remove the "target" value from the end, and then 
traverse the JSON objects to find the parent of the target.

These specifications do very little to define how to handle errors beyond terminating processing and indicating an error condition. 

I think the Patch location should always point to the parent object or 
array. The operation object can then define the object name or array 
index to operate upon, along with any new value to be added or replaced, 
or location to be moved to, etc. So for example,

	{ "hork":"gak" }

The patch

	[ { "add":"/", "name":"foo", "value":"bar" } ]

gives you { "hork":"gak", "foo":"bar" }

I'm not wedded to this syntax, which is a bit more verbose. But I think 
the issue is significant: as they stand, Patch is specified to depend 
upon undefined behavior in Pointer.

As a stylistic matter, I also think separating operation and location 
into different members would be easier for people to read and programs 
to parse; e.g.

{ "op": "add", "loc":"/", "name":"foo", "value":"bar" }

Just looking at the "op" member is easier than testing each of 
add/remove/test/etc in turn. But that's a matter of taste, and it is 
slightly more verbose.

There's a minor issue with move; section 4.4 says

    This operation is functionally identical to expressing a "remove"
    operation, followed immediately by an "add" operation at the new
    location with the value that was just removed.

    If the location in the "to" member references a member of an existing
    object in the target document, it is an error condition if a value at
    the specified location already exists.

So what about moving an location to itself? If move is "functionally 
identical" to remove/add, then moving /a/b/c to /a/b/c is legal. On the 
other hand, an implementation might check the existence of "to" before 
performing the "move", and then throw an error.

I'm ok with just defining moving a location to itself to be a no-op.

Since it is functionally identical to removing then re-adding, then checking for the presence of the value before removing would not be functionally identical. If adding the no-op language makes this clearer, I'd be fine adding it.

Paul --=-KzvRYI5tLPYFx6QGeM/p-- From pbryan@anode.ca Thu Mar 1 13:45:52 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5624921E8058 for ; Thu, 1 Mar 2012 13:45:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id weZWglOVh8Sj for ; Thu, 1 Mar 2012 13:45:51 -0800 (PST) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id 7022421E8036 for ; Thu, 1 Mar 2012 13:45:51 -0800 (PST) Received: from [10.0.2.11] (unknown [75.103.8.234]) by maple.anode.ca (Postfix) with ESMTPSA id 11F9E6485 for ; Thu, 1 Mar 2012 21:45:51 +0000 (UTC) Message-ID: <1330638350.2531.11.camel@neutron> From: "Paul C. Bryan" To: IETF Apps Discuss Date: Thu, 01 Mar 2012 13:45:50 -0800 In-Reply-To: <4F4FD8A5.6010603@cloudmark.com> References: <4F4FD8A5.6010603@cloudmark.com> Content-Type: multipart/alternative; boundary="=-oRaayDKcmAhBNknCo3jW" X-Mailer: Evolution 3.2.2-1 Mime-Version: 1.0 Subject: Re: [apps-discuss] Feedback on draft-ietf-appsawg-json-pointer-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 01 Mar 2012 21:45:52 -0000 --=-oRaayDKcmAhBNknCo3jW Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit On Thu, 2012-03-01 at 12:14 -0800, Mike Acar wrote: > Hi, > > I've been asked to review the JSON Pointer and Patch draft RFCs. I've > had some discussion about them off-list, and have been advised to bring > my issues to the list. And so, I am. :) > > I've scanned the archived list discussion of the patch and pointer RFCs, > so I don't think these issues have come up here already. Let me know if > they have. > > The first issue is comparing Unicode strings. Section 4 of > http://tools.ietf.org/html/draft-ietf-appsawg-json-pointer-00 says > > If the currently referenced value is a JSON object, the new > referenced value is the object member with the name identified by > the reference token. > > That is, if the reference token equals the name of some value within the > object, move to that value. However, the tokens and values are Unicode > strings; I'm not an expert in Unicode, but my impression is that testing > Unicode strings for equality is not as simple as comparing sequences of > bytes. For example, there are linguistic considerations: I believe > German ö and oe are considered identical. While we may consider ö and oe to be linguistically equivalent, I do no believe they are considered lexicographically equivalent in a Unicode string comparison. Someone please correct me if I'm wrong. Would it help to define the comparison as being lexicographical? > There's also the question of JSON documents with different encodings; > UTF8 is the default, but UTF-16 and -32 with both endiannesses are also > supported. Presumably this question will disappear in practice, since > implementations will operate on deserialized data structures, not on > JSON texts. Since they're logically the same underlying Unicode representations, I'm not sure there's any issue to consider here. > Could somebody with more expertise in this area comment? Perhaps this is > all a solved problem, and the Pointer RFC simply needs to pick a > normalization method and equality definition - or perhaps it's all so > well-settled I'm seeing a problem where there is none. > > Another issue is that the evaluation scheme implies some application > semantics. Again, section 4: > > If a reference token is being evaluated against a concrete JSON > document, the implementation MAY evaluate each token against a > concrete value, and terminate evaluation with an error condition if a > evaluation fails to resolve a concrete value. > > It's easy to imagine a case where a Pointer refers to a deep hierarchy, > e.g. /a/b/c/d, and the application semantics of following it are to > create automatically any non-existent intermediate objects. > > My initial thought was that the Pointer RFC should explicitly say that > specs which use it (e.g. Patch) should define semantics for ambiguous > cases (non-unique or non-existent member names, array index out of > bounds, etc). That can still result in a user of Pointer having to > implement it himself, if there are no implementations which offer him > precisely what he needs. > > Is it preferrable to explicitly say "You must make these decisions for > your use case" instead of "Behavior in these cases is undefined"? I'm not sure. I'm open to suggestions from the apps working group... Paul --=-oRaayDKcmAhBNknCo3jW Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit On Thu, 2012-03-01 at 12:14 -0800, Mike Acar wrote: 
Hi,

I've been asked to review the JSON Pointer and Patch draft RFCs. I've 
had some discussion about them off-list, and have been advised to bring 
my issues to the list. And so, I am. :)

I've scanned the archived list discussion of the patch and pointer RFCs, 
so I don't think these issues have come up here already. Let me know if 
they have.

The first issue is comparing Unicode strings. Section 4 of 
http://tools.ietf.org/html/draft-ietf-appsawg-json-pointer-00 says

       If the currently referenced value is a JSON object, the new
       referenced value is the object member with the name identified by
       the reference token.

That is, if the reference token equals the name of some value within the 
object, move to that value. However, the tokens and values are Unicode 
strings; I'm not an expert in Unicode, but my impression is that testing 
Unicode strings for equality is not as simple as comparing sequences of 
bytes. For example, there are linguistic considerations: I believe 
German ö and oe are considered identical.

While we may consider ö and oe to be linguistically equivalent, I do no believe they are considered lexicographically equivalent in a Unicode string comparison. Someone please correct me if I'm wrong. Would it help to define the comparison as being lexicographical?

There's also the question of JSON documents with different encodings; 
UTF8 is the default, but UTF-16 and -32 with both endiannesses are also 
supported. Presumably this question will disappear in practice, since 
implementations will operate on deserialized data structures, not on 
JSON texts.

Since they're logically the same underlying Unicode representations, I'm not sure there's any issue to consider here.

Could somebody with more expertise in this area comment? Perhaps this is 
all a solved problem, and the Pointer RFC simply needs to pick a 
normalization method and equality definition - or perhaps it's all so 
well-settled I'm seeing a problem where there is none.

Another issue is that the evaluation scheme implies some application 
semantics. Again, section 4:

    If a reference token is being evaluated against a concrete JSON
    document, the implementation MAY evaluate each token against a
    concrete value, and terminate evaluation with an error condition if a
    evaluation fails to resolve a concrete value.

It's easy to imagine a case where a Pointer refers to a deep hierarchy, 
e.g. /a/b/c/d, and the application semantics of following it are to 
create automatically any non-existent intermediate objects.

My initial thought was that the Pointer RFC should explicitly say that 
specs which use it (e.g. Patch) should define semantics for ambiguous 
cases (non-unique or non-existent member names, array index out of 
bounds, etc). That can still result in a user of Pointer having to 
implement it himself, if there are no implementations which offer him 
precisely what he needs.

Is it preferrable to explicitly say "You must make these decisions for 
your use case" instead of "Behavior in these cases is undefined"?
I'm not sure. I'm open to suggestions from the apps working group...

Paul --=-oRaayDKcmAhBNknCo3jW-- From pbryan@anode.ca Thu Mar 1 13:47:14 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05D1821E8058 for ; Thu, 1 Mar 2012 13:47:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BdAKpZX4KLQE for ; Thu, 1 Mar 2012 13:47:13 -0800 (PST) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id 9B79C21E80C8 for ; Thu, 1 Mar 2012 13:47:13 -0800 (PST) Received: from [10.0.2.11] (unknown [75.103.8.234]) by maple.anode.ca (Postfix) with ESMTPSA id 33C8E6485 for ; Thu, 1 Mar 2012 21:47:13 +0000 (UTC) Message-ID: <1330638432.2531.12.camel@neutron> From: "Paul C. Bryan" To: apps-discuss@ietf.org Date: Thu, 01 Mar 2012 13:47:12 -0800 In-Reply-To: <4F4FDCF4.2000107@gmx.de> References: <4F4FD7EB.8080004@cloudmark.com> <9452079D1A51524AA5749AD23E00392806FAA0@exch-mbx901.corp.cloudmark.com> <4F4FDA86.4040506@cloudmark.com> <4F4FDCF4.2000107@gmx.de> Content-Type: multipart/alternative; boundary="=-XczFDbWZRaR8fIMcV+zB" X-Mailer: Evolution 3.2.2-1 Mime-Version: 1.0 Subject: Re: [apps-discuss] Feedback on draft-ietf-appsawg-json-patch-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 01 Mar 2012 21:47:14 -0000 --=-XczFDbWZRaR8fIMcV+zB Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Thu, 2012-03-01 at 21:32 +0100, Julian Reschke wrote: > Nit: that reference should actually use the standard ID reference format... Is this just removing the space from the reference, or are there other considerations? Paul --=-XczFDbWZRaR8fIMcV+zB Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit On Thu, 2012-03-01 at 21:32 +0100, Julian Reschke wrote:

Nit: that reference should actually use the standard ID reference format...

Is this just removing the space from the reference, or are there other considerations?

Paul --=-XczFDbWZRaR8fIMcV+zB-- From msk@cloudmark.com Thu Mar 1 14:00:12 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D48E921E806A for ; Thu, 1 Mar 2012 14:00:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.603 X-Spam-Level: X-Spam-Status: No, score=-102.603 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id joB0m4g5IXlK for ; Thu, 1 Mar 2012 14:00:11 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id A765421E8024 for ; Thu, 1 Mar 2012 14:00:11 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Thu, 1 Mar 2012 14:00:11 -0800 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Thread-Topic: [apps-discuss] Feedback on draft-ietf-appsawg-json-patch-00 Thread-Index: AQHM9+d/ykpyZt+42kKhe+gEF12z9JZV4QswgACHTwCAAALmAIAAFMUA//99OaA= Date: Thu, 1 Mar 2012 22:00:11 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392806FDBB@exch-mbx901.corp.cloudmark.com> References: <4F4FD7EB.8080004@cloudmark.com> <9452079D1A51524AA5749AD23E00392806FAA0@exch-mbx901.corp.cloudmark.com> <4F4FDA86.4040506@cloudmark.com> <4F4FDCF4.2000107@gmx.de> <1330638432.2531.12.camel@neutron> In-Reply-To: <1330638432.2531.12.camel@neutron> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: multipart/alternative; boundary="_000_9452079D1A51524AA5749AD23E00392806FDBBexchmbx901corpclo_" MIME-Version: 1.0 Subject: Re: [apps-discuss] Feedback on draft-ietf-appsawg-json-patch-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 01 Mar 2012 22:00:13 -0000 --_000_9452079D1A51524AA5749AD23E00392806FDBBexchmbx901corpclo_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVyZeKAmXMgYW4gZXhhbXBsZToNCg0KDQogICBbSS1ELklFVEYtTUFSRi1BVVRIRkFJTFVSRS1S RVBPUlRdDQoNCiAgICAgICAgICAgICAgRm9udGFuYSwgSC4sICJBdXRoZW50aWNhdGlvbiBGYWls dXJlIFJlcG9ydGluZyB1c2luZyB0aGUNCg0KICAgICAgICAgICAgICBBYnVzZSBSZXBvcnQgRm9y bWF0IiwNCg0KICAgICAgICAgICAgICBJLUQgZHJhZnQtaWV0Zi1tYXJmLWF1dGhmYWlsdXJlLXJl cG9ydDxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1hcmYtYXV0aGZhaWx1 cmUtcmVwb3J0PiwgSmFudWFyeSAyMDEyLg0KDQoNCkZyb206IGFwcHMtZGlzY3Vzcy1ib3VuY2Vz QGlldGYub3JnIFttYWlsdG86YXBwcy1kaXNjdXNzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBQYXVsIEMuIEJyeWFuDQpTZW50OiBUaHVyc2RheSwgTWFyY2ggMDEsIDIwMTIgMTo0NyBQ TQ0KVG86IGFwcHMtZGlzY3Vzc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFthcHBzLWRpc2N1c3Nd IEZlZWRiYWNrIG9uIGRyYWZ0LWlldGYtYXBwc2F3Zy1qc29uLXBhdGNoLTAwDQoNCk9uIFRodSwg MjAxMi0wMy0wMSBhdCAyMTozMiArMDEwMCwgSnVsaWFuIFJlc2Noa2Ugd3JvdGU6DQoNCg0KDQoN Cg0KTml0OiB0aGF0IHJlZmVyZW5jZSBzaG91bGQgYWN0dWFsbHkgdXNlIHRoZSBzdGFuZGFyZCBJ RCByZWZlcmVuY2UgZm9ybWF0Li4uDQoNCklzIHRoaXMganVzdCByZW1vdmluZyB0aGUgc3BhY2Ug ZnJvbSB0aGUgcmVmZXJlbmNlLCBvciBhcmUgdGhlcmUgb3RoZXIgY29uc2lkZXJhdGlvbnM/DQoN ClBhdWwNCg== --_000_9452079D1A51524AA5749AD23E00392806FDBBexchmbx901corpclo_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBD aGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0 dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7 DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm IjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np emU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+SGVyZeKAmXMgYW4gZXhhbXBsZTo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHByZT4mbmJzcDsmbmJz cDsgWzxhIG5hbWU9InJlZi1JLUQuSUVURi1NQVJGLUFVVEhGQUlMVVJFLVJFUE9SVCIgaWQ9InJl Zi1JLUQuSUVURi1NQVJGLUFVVEhGQUlMVVJFLVJFUE9SVCI+SS1ELklFVEYtTUFSRi1BVVRIRkFJ TFVSRS1SRVBPUlQ8L2E+XTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBGb250YW5hLCBILiwgJnF1b3Q7QXV0aGVudGljYXRpb24gRmFpbHVyZSBSZXBvcnRpbmcg dXNpbmcgdGhlPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFi dXNlIFJlcG9ydCBGb3JtYXQmcXVvdDssPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IEktRCA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLW1hcmYtYXV0aGZhaWx1cmUtcmVwb3J0Ij5kcmFmdC1pZXRmLW1hcmYtYXV0aGZhaWx1 cmUtcmVwb3J0PC9hPiwgSmFudWFyeSAyMDEyLjxvOnA+PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41 cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IGFwcHMtZGlz Y3Vzcy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86YXBwcy1kaXNjdXNzLWJvdW5jZXNAaWV0Zi5v cmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlBhdWwgQy4gQnJ5YW48YnI+DQo8Yj5TZW50OjwvYj4g VGh1cnNkYXksIE1hcmNoIDAxLCAyMDEyIDE6NDcgUE08YnI+DQo8Yj5Ubzo8L2I+IGFwcHMtZGlz Y3Vzc0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW2FwcHMtZGlzY3Vzc10gRmVl ZGJhY2sgb24gZHJhZnQtaWV0Zi1hcHBzYXdnLWpzb24tcGF0Y2gtMDA8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIDIwMTItMDMtMDEgYXQgMjE6 MzIgJiM0MzswMTAwLCBKdWxpYW4gUmVzY2hrZSB3cm90ZTo8YnI+DQo8YnI+DQo8YnI+DQo8bzpw PjwvbzpwPjwvcD4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+Tml0OiB0aGF0 IHJlZmVyZW5jZSBzaG91bGQgYWN0dWFsbHkgdXNlIHRoZSBzdGFuZGFyZCBJRCByZWZlcmVuY2Ug Zm9ybWF0Li4uPG86cD48L286cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCklz IHRoaXMganVzdCByZW1vdmluZyB0aGUgc3BhY2UgZnJvbSB0aGUgcmVmZXJlbmNlLCBvciBhcmUg dGhlcmUgb3RoZXIgY29uc2lkZXJhdGlvbnM/PGJyPg0KPGJyPg0KUGF1bCA8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_9452079D1A51524AA5749AD23E00392806FDBBexchmbx901corpclo_-- From julian.reschke@gmx.de Thu Mar 1 14:00:49 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C401E21E806A for ; Thu, 1 Mar 2012 14:00:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.054 X-Spam-Level: X-Spam-Status: No, score=-104.054 tagged_above=-999 required=5 tests=[AWL=-1.455, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZxS-1J7i4iZ for ; Thu, 1 Mar 2012 14:00:47 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 2319521E82F3 for ; Thu, 1 Mar 2012 14:00:40 -0800 (PST) Received: (qmail invoked by alias); 01 Mar 2012 22:00:39 -0000 Received: from p5DCC2B62.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.43.98] by mail.gmx.net (mp032) with SMTP; 01 Mar 2012 23:00:39 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/UfrFgUhDU3uvhi4f8EfpG1SAd/vtMjjfSNkSKP0 /1h5gX84B/KA6S Message-ID: <4F4FF181.1060106@gmx.de> Date: Thu, 01 Mar 2012 23:00:33 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "Paul C. Bryan" References: <4F4FD7EB.8080004@cloudmark.com> <9452079D1A51524AA5749AD23E00392806FAA0@exch-mbx901.corp.cloudmark.com> <4F4FDA86.4040506@cloudmark.com> <4F4FDCF4.2000107@gmx.de> <1330638432.2531.12.camel@neutron> In-Reply-To: <1330638432.2531.12.camel@neutron> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Feedback on draft-ietf-appsawg-json-patch-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 01 Mar 2012 22:00:49 -0000 On 2012-03-01 22:47, Paul C. Bryan wrote: > On Thu, 2012-03-01 at 21:32 +0100, Julian Reschke wrote: > >> Nit: that reference should actually use the standard ID reference format... > > Is this just removing the space from the reference, or are there other > considerations? The name of the reference is a separate issue (names in refs do not contain whitespace). The issue I was referring to is that the draft should be cited as Internet Draft, such as Bryan, P. and K. Zyp, "JSON Pointer", Internet-Draft draft-ietf-appsawg-json-pointer-00 (work in progress), January 2012. Best regards, Julian From julian.reschke@gmx.de Thu Mar 1 14:07:54 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 901B321E82DF for ; Thu, 1 Mar 2012 14:07:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.037 X-Spam-Level: X-Spam-Status: No, score=-104.037 tagged_above=-999 required=5 tests=[AWL=-1.438, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IlebXRQ+G97y for ; Thu, 1 Mar 2012 14:07:54 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 79C5821E82BA for ; Thu, 1 Mar 2012 14:07:53 -0800 (PST) Received: (qmail invoked by alias); 01 Mar 2012 22:07:51 -0000 Received: from p5DCC2B62.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.43.98] by mail.gmx.net (mp041) with SMTP; 01 Mar 2012 23:07:51 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18CD/tKwoECs8yDU5/jNeqqSY6Cm7PSzajAySYM7a +HQTFZVpPUkZdn Message-ID: <4F4FF332.2080900@gmx.de> Date: Thu, 01 Mar 2012 23:07:46 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <4F4FD7EB.8080004@cloudmark.com> <9452079D1A51524AA5749AD23E00392806FAA0@exch-mbx901.corp.cloudmark.com> <4F4FDA86.4040506@cloudmark.com> <4F4FDCF4.2000107@gmx.de> <1330638432.2531.12.camel@neutron> <9452079D1A51524AA5749AD23E00392806FDBB@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E00392806FDBB@exch-mbx901.corp.cloudmark.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Feedback on draft-ietf-appsawg-json-patch-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 01 Mar 2012 22:07:54 -0000 On 2012-03-01 23:00, Murray S. Kucherawy wrote: > Here’s an example: > > [I-D.IETF-MARF-AUTHFAILURE-REPORT] > > Fontana, H.,"Authentication Failure Reporting using the > > Abuse Report Format", > > I-Ddraft-ietf-marf-authfailure-report , January 2012. Actually that's bad example. It doesn't use "Internet-Draft" as seriesInfo, and thus doesn't produce the "work in progress" label. (yes, I'm nitpicking here) Best regards, Julian From msk@cloudmark.com Thu Mar 1 14:09:02 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98E0821E8018 for ; Thu, 1 Mar 2012 14:09:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.604 X-Spam-Level: X-Spam-Status: No, score=-102.604 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8R3qSQGkazn2 for ; Thu, 1 Mar 2012 14:09:02 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 27EC621E82BA for ; Thu, 1 Mar 2012 14:09:02 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by EXCH-HTCAS901.corp.cloudmark.com ([fe80::2966:6846:8d89:4681%12]) with mapi id 14.01.0355.002; Thu, 1 Mar 2012 14:09:01 -0800 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Thread-Topic: [apps-discuss] Feedback on draft-ietf-appsawg-json-patch-00 Thread-Index: AQHM9+d/ykpyZt+42kKhe+gEF12z9JZV4QswgACHTwCAAALmAIAAFMUA//99OaCAAIiGAP//eg5w Date: Thu, 1 Mar 2012 22:09:00 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392806FDD8@exch-mbx901.corp.cloudmark.com> References: <4F4FD7EB.8080004@cloudmark.com> <9452079D1A51524AA5749AD23E00392806FAA0@exch-mbx901.corp.cloudmark.com> <4F4FDA86.4040506@cloudmark.com> <4F4FDCF4.2000107@gmx.de> <1330638432.2531.12.camel@neutron> <9452079D1A51524AA5749AD23E00392806FDBB@exch-mbx901.corp.cloudmark.com> <4F4FF332.2080900@gmx.de> In-Reply-To: <4F4FF332.2080900@gmx.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [apps-discuss] Feedback on draft-ietf-appsawg-json-patch-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 01 Mar 2012 22:09:02 -0000 > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Thursday, March 01, 2012 2:08 PM > To: Murray S. Kucherawy > Cc: apps-discuss@ietf.org > Subject: Re: [apps-discuss] Feedback on draft-ietf-appsawg-json-patch-00 >=20 > It doesn't use "Internet-Draft" as seriesInfo, and thus doesn't produce > the "work in progress" label. Is that seriesInfo the thing that makes "(work in progress)" appear? > (yes, I'm nitpicking here) Indeed. :-) From julian.reschke@gmx.de Thu Mar 1 14:16:38 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A51B21E836D for ; Thu, 1 Mar 2012 14:16:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.02 X-Spam-Level: X-Spam-Status: No, score=-104.02 tagged_above=-999 required=5 tests=[AWL=-1.421, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mrh5+YiSRzYn for ; Thu, 1 Mar 2012 14:16:38 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 8886621E8024 for ; Thu, 1 Mar 2012 14:16:37 -0800 (PST) Received: (qmail invoked by alias); 01 Mar 2012 22:16:35 -0000 Received: from p5DCC2B62.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.43.98] by mail.gmx.net (mp031) with SMTP; 01 Mar 2012 23:16:35 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19gXI5pPsRgtDG5s2CgVv4diaywghGWTUUDbriRMy 7FREHioRqN4cmi Message-ID: <4F4FF53D.4000503@gmx.de> Date: Thu, 01 Mar 2012 23:16:29 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <4F4FD7EB.8080004@cloudmark.com> <9452079D1A51524AA5749AD23E00392806FAA0@exch-mbx901.corp.cloudmark.com> <4F4FDA86.4040506@cloudmark.com> <4F4FDCF4.2000107@gmx.de> <1330638432.2531.12.camel@neutron> <9452079D1A51524AA5749AD23E00392806FDBB@exch-mbx901.corp.cloudmark.com> <4F4FF332.2080900@gmx.de> <9452079D1A51524AA5749AD23E00392806FDD8@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E00392806FDD8@exch-mbx901.corp.cloudmark.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Feedback on draft-ietf-appsawg-json-patch-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 01 Mar 2012 22:16:38 -0000 On 2012-03-01 23:09, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: Julian Reschke [mailto:julian.reschke@gmx.de] >> Sent: Thursday, March 01, 2012 2:08 PM >> To: Murray S. Kucherawy >> Cc: apps-discuss@ietf.org >> Subject: Re: [apps-discuss] Feedback on draft-ietf-appsawg-json-patch-00 >> >> It doesn't use "Internet-Draft" as seriesInfo, and thus doesn't produce >> the "work in progress" label. > > Is that seriesInfo the thing that makes "(work in progress)" appear? Yes. >> (yes, I'm nitpicking here) > > Indeed. :-) Sorry for that :-) From sm@elandsys.com Thu Mar 1 17:20:14 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0F8E21E8370 for ; Thu, 1 Mar 2012 17:20:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9tlAGq5BgFgA for ; Thu, 1 Mar 2012 17:20:14 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CCD321E8035 for ; Thu, 1 Mar 2012 17:20:13 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.238.73]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q221JxYr014655 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 1 Mar 2012 17:20:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1330651210; i=@elandsys.com; bh=ofv3XhHBgjTFESJ4de1LCUFvM9xrl2zwOQ+OIJB1Kew=; h=Message-Id:Date:To:From:Subject:Mime-Version:Content-Type:Cc; b=zkyvc+zxI8C1/FPvyfzLrdWPirKcSo2lfRmVS0kUgiWidqQeioKbEXP2WKfxTQs5F 2rX4IKV8XK5wwC3TfcjVBA55hd0fjPpRT6sJr9Td4VxJi5IxDGxNjV5NMgEUOiqKxh rO0iOFKrKB/OHcimUbNrdotw7hWzt5nLiIBor5Wk= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1330651210; i=@elandsys.com; bh=ofv3XhHBgjTFESJ4de1LCUFvM9xrl2zwOQ+OIJB1Kew=; h=Message-Id:Date:To:From:Subject:Mime-Version:Content-Type:Cc; b=YViDFiY05axoqv52KK6rthmEnnALrC4fxgVNeTr1bCyXIcOJ8Xz+iNFyxvO78qpay KHmqIxzl/fiQg1v0DgW8avh1TaNAszR+mKJJlVylgksgLXEFsDFxVopr1SHfjQWvu3 kAlDdnGZlyfHSNryn8qLFa5F+W7s6SVtUFYZVJqE= Message-Id: <6.2.5.6.2.20120301165335.09969be8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 01 Mar 2012 17:03:17 -0800 To: Apps-Discuss@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [apps-discuss] Apps Area Directorate Report for February 2012 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 02 Mar 2012 01:20:15 -0000 The Applications Area Directorate provides semi-formal reviews of Internet-Drafts as a way to improve the quality of IETF specifications. The directorate consists of the Working Group Chairs of the Applications Area and recognized experts in the Applications Area. The following reviews were performed in February 2012: Reviewer I-D Yoshiro Yoneya draft-harkins-ipsecme-spsk-auth-06 Enrico Marocco & draft-ietf-simple-chat-13 (joint review) Alexey Melnikov Yves Lafon draft-snell-atompub-tombstones-14 William J. Mills draft-ietf-dnsext-ecdsa-04 Tobias Gondrom draft-ietf-tsvwg-source-quench-04 Henry S. Thompson draft-ietf-oauth-v2-23 Aaron Stone draft-ietf-payload-rtp-klv-03 Vijay K. Gurbani draft-ietf-pcp-base-22 S. Moonesamy draft-ietf-behave-64-analysis-05 Julian Reschke draft-ietf-core-link-format-11 Martin Durst draft-ietf-mile-template-02 Eran Hammer draft-reschke-http-status-308-05 Joseph Yee draft-ietf-dnsext-rfc2671bis-edns0-08 Carsten Bormann draft-garcia-shim6-applicability-03 Pending reviews are listed at http://trac.tools.ietf.org/area/app/trac/report/1 Regards, S. Moonesamy On behalf of the Applications Area Directorate http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate From duerst@it.aoyama.ac.jp Thu Mar 1 19:58:05 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FB7921E8032 for ; Thu, 1 Mar 2012 19:58:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.449 X-Spam-Level: X-Spam-Status: No, score=-100.449 tagged_above=-999 required=5 tests=[AWL=-0.659, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f0M3elOnTDid for ; Thu, 1 Mar 2012 19:58:04 -0800 (PST) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 3D21A21E8014 for ; Thu, 1 Mar 2012 19:58:03 -0800 (PST) Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id q223vr29006366 for ; Fri, 2 Mar 2012 12:57:53 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 5ea7_5621_e2d0b2c8_641b_11e1_b789_001d096c566a; Fri, 02 Mar 2012 12:57:52 +0900 Received: from [IPv6:::1] ([133.2.210.1]:36594) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Fri, 2 Mar 2012 12:57:56 +0900 Message-ID: <4F50453B.5020708@it.aoyama.ac.jp> Date: Fri, 02 Mar 2012 12:57:47 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: "Paul C. Bryan" References: <4F4FD8A5.6010603@cloudmark.com> <1330638350.2531.11.camel@neutron> In-Reply-To: <1330638350.2531.11.camel@neutron> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Feedback on draft-ietf-appsawg-json-pointer-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 02 Mar 2012 03:58:05 -0000 On 2012/03/02 6:45, Paul C. Bryan wrote: > On Thu, 2012-03-01 at 12:14 -0800, Mike Acar wrote: >> That is, if the reference token equals the name of some value within the >> object, move to that value. However, the tokens and values are Unicode >> strings; I'm not an expert in Unicode, but my impression is that testing >> Unicode strings for equality is not as simple as comparing sequences of >> bytes. For example, there are linguistic considerations: I believe >> German ö and oe are considered identical. > > > While we may consider ö and oe to be linguistically equivalent, I do no > believe they are considered lexicographically equivalent in a Unicode > string comparison. Someone please correct me if I'm wrong. Would it help > to define the comparison as being lexicographical? No. Lexicographical is usually used with respect to order, not equivalence (see e.g. http://en.wikipedia.org/wiki/Lexicographical_order). >> There's also the question of JSON documents with different encodings; >> UTF8 is the default, but UTF-16 and -32 with both endiannesses are also >> supported. Presumably this question will disappear in practice, since >> implementations will operate on deserialized data structures, not on >> JSON texts. > > Since they're logically the same underlying Unicode representations, I'm > not sure there's any issue to consider here. The best way to spec this is to say that equivalence is checked codepoint-by-codepoint. That solves both issues, because codepoints are independent of UTF-8/UTF-16/UTF-32, simply the Unicode character numbers. Regards, Martin. From tbray@textuality.com Thu Mar 1 21:16:25 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2889521E8014 for ; Thu, 1 Mar 2012 21:16:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.785 X-Spam-Level: X-Spam-Status: No, score=-3.785 tagged_above=-999 required=5 tests=[AWL=-1.108, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4pkCy0yqNiMl for ; Thu, 1 Mar 2012 21:16:24 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1212121E800E for ; Thu, 1 Mar 2012 21:16:23 -0800 (PST) Received: by obbeh20 with SMTP id eh20so1892373obb.31 for ; Thu, 01 Mar 2012 21:16:23 -0800 (PST) Received-SPF: pass (google.com: domain of tbray@textuality.com designates 10.182.48.36 as permitted sender) client-ip=10.182.48.36; Authentication-Results: mr.google.com; spf=pass (google.com: domain of tbray@textuality.com designates 10.182.48.36 as permitted sender) smtp.mail=tbray@textuality.com Received: from mr.google.com ([10.182.48.36]) by 10.182.48.36 with SMTP id i4mr3076158obn.72.1330665383441 (num_hops = 1); Thu, 01 Mar 2012 21:16:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.48.36 with SMTP id i4mr2667299obn.72.1330665383332; Thu, 01 Mar 2012 21:16:23 -0800 (PST) Received: by 10.182.137.69 with HTTP; Thu, 1 Mar 2012 21:16:23 -0800 (PST) X-Originating-IP: [24.84.235.32] In-Reply-To: <4F50453B.5020708@it.aoyama.ac.jp> References: <4F4FD8A5.6010603@cloudmark.com> <1330638350.2531.11.camel@neutron> <4F50453B.5020708@it.aoyama.ac.jp> Date: Thu, 1 Mar 2012 21:16:23 -0800 Message-ID: From: Tim Bray To: =?ISO-8859-1?Q?Martin_J=2E_D=FCrst?= Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmHvKJsMl/m2QnTVGAIAIdr9SGfV1DMBXNU/ee6KK5BBe4LrcXImNCvUhKLUxRQsgKJO3fc Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Feedback on draft-ietf-appsawg-json-pointer-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 02 Mar 2012 05:16:25 -0000 This thread has convinced me that it=92s still easy after all these years for people to go down rabbit holes on this issue, and therefore the draft should be explicitly clear that key equality MUST be determined codepoint-by-codepoint as Martin suggests. -T On Thu, Mar 1, 2012 at 7:57 PM, "Martin J. D=FCrst" wrote: > On 2012/03/02 6:45, Paul C. Bryan wrote: >> >> On Thu, 2012-03-01 at 12:14 -0800, Mike Acar wrote: > > >>> That is, if the reference token equals the name of some value within th= e >>> object, move to that value. However, the tokens and values are Unicode >>> strings; I'm not an expert in Unicode, but my impression is that testin= g >>> Unicode strings for equality is not as simple as comparing sequences of >>> bytes. For example, there are linguistic considerations: I believe >>> German =F6 and oe are considered identical. >> >> >> >> While we may consider =F6 and oe to be linguistically equivalent, I do n= o >> believe they are considered lexicographically equivalent in a Unicode >> string comparison. Someone please correct me if I'm wrong. Would it help >> to define the comparison as being lexicographical? > > > No. Lexicographical is usually used with respect to order, not equivalenc= e > (see e.g. http://en.wikipedia.org/wiki/Lexicographical_order). > > >>> There's also the question of JSON documents with different encodings; >>> UTF8 is the default, but UTF-16 and -32 with both endiannesses are also >>> supported. Presumably this question will disappear in practice, since >>> implementations will operate on deserialized data structures, not on >>> JSON texts. >> >> >> Since they're logically the same underlying Unicode representations, I'm >> not sure there's any issue to consider here. > > > The best way to spec this is to say that equivalence is checked > codepoint-by-codepoint. That solves both issues, because codepoints are > independent of UTF-8/UTF-16/UTF-32, simply the Unicode character numbers. > > Regards, =A0 =A0Martin. > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From stpeter@stpeter.im Fri Mar 2 09:35:41 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5205D21E800F for ; Fri, 2 Mar 2012 09:35:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.791 X-Spam-Level: X-Spam-Status: No, score=-102.791 tagged_above=-999 required=5 tests=[AWL=-0.192, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vVU7pVCBghoT for ; Fri, 2 Mar 2012 09:35:40 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 5777121F86B0 for ; Fri, 2 Mar 2012 09:35:40 -0800 (PST) Received: from squire.local (unknown [64.101.72.114]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 444B540058; Fri, 2 Mar 2012 10:47:23 -0700 (MST) Message-ID: <4F5104E9.9000500@stpeter.im> Date: Fri, 02 Mar 2012 10:35:37 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "apps-discuss@ietf.org" References: <20110912090521.DC00198C257@rfc-editor.org> In-Reply-To: <20110912090521.DC00198C257@rfc-editor.org> X-Enigmail-Version: 1.3.5 OpenPGP: url=https://stpeter.im/stpeter.asc X-Forwarded-Message-Id: <20110912090521.DC00198C257@rfc-editor.org> Content-Type: multipart/mixed; boundary="------------050403050201050109060702" Cc: Daniel van Vugt Subject: [apps-discuss] ABNF errata X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 02 Mar 2012 17:35:41 -0000 This is a multi-part message in MIME format. --------------050403050201050109060702 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Folks, two related errata (#2968 and #3076) have been reported against the ABNF spec (RFC 5234): http://www.rfc-editor.org/errata_search.php?rfc=5234 Because there is no dedicated list for ABNF, and because application protocols are the main users of ABNF, I thought it would be appropriate to post about this on the apps-discuss list. The reporter of these errata, Daniel van Vugt (cc'd), has made available some code for testing these errata: http://sourceforge.net/projects/dapar/ Thank you for your consideration. Peter -------- Original Message -------- Subject: [Technical Errata Reported] RFC5234 (2968) Date: Mon, 12 Sep 2011 02:05:21 -0700 (PDT) From: RFC Errata System To: dcrocker@bbiw.net, paul.overell@thus.net, iesg@iesg.org CC: rfc-editor@rfc-editor.org, vanvugt@gmail.com The following errata report has been submitted for RFC5234, "Augmented BNF for Syntax Specifications: ABNF". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5234&eid=2968 -------------------------------------- Type: Technical Reported by: Daniel van Vugt Section: 4 Original Text ------------- elements = alternation *c-wsp Corrected Text -------------- elements = alternation *WSP Notes ----- The grammar in section 4 of RFC 5234 is ambiguous. This was discovered by my own parsing code when trying to parse the ABNF grammar with itself. The ambiguity can be seen in a simplified form using the following 10 characters of input: Input: X = Y \r \n ; Z \r \n Offset: 0 1 2 3 4 5 6 7 8 9 My parser finds these two (ambiguous) solutions... SOLUTION 1: rulelist @ 0 len 10 rule @ 0 len 10 rulename @ 0 len 1 "X" ALPHA @ 0 len 1 star_c_wsp @ 1 len 0 defined_as @ 1 len 1 star_c_wsp @ 2 len 0 elements @ 2 len 4 alternation @ 2 len 1 concatenation @ 2 len 1 repetition @ 2 len 1 element @ 2 len 1 rulename @ 2 len 1 "Y" ALPHA @ 2 len 1 star_c_wsp @ 3 len 3 c_wsp @ 3 len 3 c_nl @ 3 len 2 CRLF @ 3 len 2 CR @ 3 len 1 LF @ 4 len 1 WSP @ 5 len 1 SP @ 5 len 1 c_nl @ 6 len 4 comment @ 6 len 4 ";Z " WSP_or_VCHAR @ 7 len 1 VCHAR @ 7 len 1 CRLF @ 8 len 2 CR @ 8 len 1 LF @ 9 len 1 SOLUTION 2: rulelist @ 0 len 10 rule @ 0 len 5 rulename @ 0 len 1 "X" ALPHA @ 0 len 1 star_c_wsp @ 1 len 0 defined_as @ 1 len 1 star_c_wsp @ 2 len 0 elements @ 2 len 1 alternation @ 2 len 1 concatenation @ 2 len 1 repetition @ 2 len 1 element @ 2 len 1 rulename @ 2 len 1 "Y" ALPHA @ 2 len 1 star_c_wsp @ 3 len 0 c_nl @ 3 len 2 CRLF @ 3 len 2 CR @ 3 len 1 LF @ 4 len 1 star_c_wsp @ 5 len 1 c_wsp @ 5 len 1 WSP @ 5 len 1 SP @ 5 len 1 c_nl @ 6 len 4 comment @ 6 len 4 ";Z " WSP_or_VCHAR @ 7 len 1 VCHAR @ 7 len 1 CRLF @ 8 len 2 CR @ 8 len 1 LF @ 9 len 1 The solution to this ambiguity is to change: elements = alternation *c-wsp to: elements = alternation *WSP Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5234 (draft-crocker-rfc4234bis-01) -------------------------------------- Title : Augmented BNF for Syntax Specifications: ABNF Publication Date : January 2008 Author(s) : D. Crocker, Ed., P. Overell Category : STANDARD Source : IETF - NON WORKING GROUP Area : N/A Stream : IETF Verifying Party : IESG --------------050403050201050109060702 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="Attached Message Part" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Attached Message Part" --------------050403050201050109060702-- From pbryan@anode.ca Fri Mar 2 10:42:07 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4E7F21E8049 for ; Fri, 2 Mar 2012 10:42:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PjUng8dDR4cC for ; Fri, 2 Mar 2012 10:42:06 -0800 (PST) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id DF53921E8034 for ; Fri, 2 Mar 2012 10:41:46 -0800 (PST) Received: from [192.168.1.9] (S0106a021b762dbb3.vf.shawcable.net [174.1.50.247]) by maple.anode.ca (Postfix) with ESMTPSA id B5EA76485 for ; Fri, 2 Mar 2012 18:41:45 +0000 (UTC) Message-ID: <1330713704.2057.0.camel@neutron> From: "Paul C. Bryan" To: IETF Apps Discuss Date: Fri, 02 Mar 2012 10:41:44 -0800 In-Reply-To: <4F50453B.5020708@it.aoyama.ac.jp> References: <4F4FD8A5.6010603@cloudmark.com> <1330638350.2531.11.camel@neutron> <4F50453B.5020708@it.aoyama.ac.jp> Content-Type: multipart/alternative; boundary="=-rNLgEu5s0iwhRp2uOqjD" X-Mailer: Evolution 3.2.2-1 Mime-Version: 1.0 Subject: Re: [apps-discuss] Feedback on draft-ietf-appsawg-json-pointer-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 02 Mar 2012 18:42:07 -0000 --=-rNLgEu5s0iwhRp2uOqjD Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Okay, I will amend the draft accordingly. Paul On Fri, 2012-03-02 at 12:57 +0900, "Martin J. Dürst" wrote: > On 2012/03/02 6:45, Paul C. Bryan wrote: > > On Thu, 2012-03-01 at 12:14 -0800, Mike Acar wrote: > > >> That is, if the reference token equals the name of some value within the > >> object, move to that value. However, the tokens and values are Unicode > >> strings; I'm not an expert in Unicode, but my impression is that testing > >> Unicode strings for equality is not as simple as comparing sequences of > >> bytes. For example, there are linguistic considerations: I believe > >> German ö and oe are considered identical. > > > > > > While we may consider ö and oe to be linguistically equivalent, I do no > > believe they are considered lexicographically equivalent in a Unicode > > string comparison. Someone please correct me if I'm wrong. Would it help > > to define the comparison as being lexicographical? > > No. Lexicographical is usually used with respect to order, not > equivalence (see e.g. http://en.wikipedia.org/wiki/Lexicographical_order). > > >> There's also the question of JSON documents with different encodings; > >> UTF8 is the default, but UTF-16 and -32 with both endiannesses are also > >> supported. Presumably this question will disappear in practice, since > >> implementations will operate on deserialized data structures, not on > >> JSON texts. > > > > Since they're logically the same underlying Unicode representations, I'm > > not sure there's any issue to consider here. > > The best way to spec this is to say that equivalence is checked > codepoint-by-codepoint. That solves both issues, because codepoints are > independent of UTF-8/UTF-16/UTF-32, simply the Unicode character numbers. > > Regards, Martin. --=-rNLgEu5s0iwhRp2uOqjD Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit Okay, I will amend the draft accordingly.

Paul

On Fri, 2012-03-02 at 12:57 +0900, "Martin J. Dürst" wrote: 
On 2012/03/02 6:45, Paul C. Bryan wrote:
> On Thu, 2012-03-01 at 12:14 -0800, Mike Acar wrote:

>> That is, if the reference token equals the name of some value within the
>> object, move to that value. However, the tokens and values are Unicode
>> strings; I'm not an expert in Unicode, but my impression is that testing
>> Unicode strings for equality is not as simple as comparing sequences of
>> bytes. For example, there are linguistic considerations: I believe
>> German ö and oe are considered identical.
>
>
> While we may consider ö and oe to be linguistically equivalent, I do no
> believe they are considered lexicographically equivalent in a Unicode
> string comparison. Someone please correct me if I'm wrong. Would it help
> to define the comparison as being lexicographical?

No. Lexicographical is usually used with respect to order, not 
equivalence (see e.g. http://en.wikipedia.org/wiki/Lexicographical_order).

>> There's also the question of JSON documents with different encodings;
>> UTF8 is the default, but UTF-16 and -32 with both endiannesses are also
>> supported. Presumably this question will disappear in practice, since
>> implementations will operate on deserialized data structures, not on
>> JSON texts.
>
> Since they're logically the same underlying Unicode representations, I'm
> not sure there's any issue to consider here.

The best way to spec this is to say that equivalence is checked 
codepoint-by-codepoint. That solves both issues, because codepoints are 
independent of UTF-8/UTF-16/UTF-32, simply the Unicode character numbers.

Regards,    Martin.

--=-rNLgEu5s0iwhRp2uOqjD-- From msk@cloudmark.com Fri Mar 2 13:12:02 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE3421E8010 for ; Fri, 2 Mar 2012 13:12:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.604 X-Spam-Level: X-Spam-Status: No, score=-102.604 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E3r1Uh-m1qh7 for ; Fri, 2 Mar 2012 13:12:02 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id 1A8F721E8019 for ; Fri, 2 Mar 2012 13:12:02 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Fri, 2 Mar 2012 13:12:01 -0800 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Thread-Topic: [apps-discuss] Feedback on draft-ietf-appsawg-json-patch-00 Thread-Index: AQHM9+d/ykpyZt+42kKhe+gEF12z9JZWfmmAgADzOuA= Date: Fri, 2 Mar 2012 21:12:00 +0000 Message-ID: <9452079D1A51524AA5749AD23E003928076BC1@exch-mbx901.corp.cloudmark.com> References: <4F4FD7EB.8080004@cloudmark.com> <1330638087.2531.7.camel@neutron> In-Reply-To: <1330638087.2531.7.camel@neutron> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [apps-discuss] Feedback on draft-ietf-appsawg-json-patch-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 02 Mar 2012 21:12:02 -0000 Pj4gTXkgZmlyc3QgY29uY2VybiB3aXRoIFBhdGNoIGlzIHRoZSB0ZXN0IG9wZXJhdGlvbjsgDQo+ PiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWFwcHNhd2ctanNvbi1wYXRj aC0wMCBzZWMgNC41IA0KPj4gZGVmaW5lcyB0ZXN0Og0KPj4NCj4+ICAgICA0LjUuICB0ZXN0DQo+ PiANCj4+ICAgIFRoZSAidGVzdCIgb3BlcmF0aW9uIHRlc3RzIHRoYXQgYSB2YWx1ZSBhdCB0aGUg c3BlY2lmaWVkIGxvY2F0aW9uIGluDQo+PiAgICB0aGUgdGFyZ2V0IGRvY3VtZW50IGlzIGVxdWFs IHRvIGEgc3BlY2lmaWVkIHZhbHVlLiAgVGhlIG9wZXJhdGlvbg0KPj4gICAgb2JqZWN0IGNvbnRh aW5zIGEgInZhbHVlIiBtZW1iZXIsIHdoaWNoIHNwZWNpZmllcyB0aGUgdmFsdWUgdG8gdGVzdA0K Pj4gICAgZm9yLg0KPj4NCj4+IFdoYXQgY29uc3RpdHV0ZXMgZXF1YWxpdHkgd2hlbiB0aGUgdmFs dWVzIGluIHF1ZXN0aW9uIGNhbiBiZSB0cmVlcyBvZiANCj4+IG9iamVjdHMgYW5kIGFycmF5cz8g Q2FuIHRoaXMgZXZlbiBiZSB1c2VmdWxseSBkZWZpbmVkIGluIGdlbmVyYWw/DQo+IA0KPiBUaGUg dmFsdWUgd2l0aGluIHRoZSBKU09OIGRvY3VtZW50IHNob3VsZCBiZSBlcXVhbCB0byB0aGUgdmFs dWUgaW4gdGhlIEpTT04gUGF0Y2ggZG9jdW1lbnQ7IGlmIHRoZXNlIHZhbHVlcw0KPiBjb250YWlu IG9iamVjdHMgb3IgYXJyYXlzLCB0aGV5IG11c3QgYmUgZXF1YWwgKGkuZS4gc2FtZSBvcmRlciBv ZiBlbGVtZW50cywgd2l0aCB0aGUgc2FtZSB2YWx1ZXMpLg0KDQpJIHRoaW5rIHRoYXQgbmVlZHMg dG8gYmUgZXhwbGljaXQuDQoNCj4+IFRoZXJlJ3Mgbm8gbWVudGlvbiBvZiB3aGF0IHRvIGRvIGlm IHRoZSBpbXBsZW1lbnRhdGlvbiBkb2VzIG5vdCByZXR1cm4gDQo+PiBhbiBlcnJvciwgbGVhdmlu ZyB0aGUgYmVoYXZpb3IgZXNzZW50aWFsbHkgdW5kZWZpbmVkLiBTbyB0byBhdm9pZCANCj4+IGRl cGVuZGluZyB1cG9uIHVuZGVmaW5lZCBiZWhhdmlvciwgYW4gaW1wbGVtZW50YXRpb24gb2YgUGF0 Y2ggd291bGQgaGF2ZSANCj4+IHRvIHBhcnNlIHRoZSBQb2ludGVyLCByZW1vdmUgdGhlICJ0YXJn ZXQiIHZhbHVlIGZyb20gdGhlIGVuZCwgYW5kIHRoZW4gDQo+PiB0cmF2ZXJzZSB0aGUgSlNPTiBv YmplY3RzIHRvIGZpbmQgdGhlIHBhcmVudCBvZiB0aGUgdGFyZ2V0Lg0KPg0KPiBUaGVzZSBzcGVj aWZpY2F0aW9ucyBkbyB2ZXJ5IGxpdHRsZSB0byBkZWZpbmUgaG93IHRvIGhhbmRsZSBlcnJvcnMg YmV5b25kIHRlcm1pbmF0aW5nIHByb2Nlc3NpbmcgYW5kDQo+IGluZGljYXRpbmcgYW4gZXJyb3Ig Y29uZGl0aW9uLiANCg0KU2hvdWxkbid0IHRoZXk/DQoNCkFuIHVucmVsYXRlZCBwb2ludCBhYm91 dCB0aGUgc2FtZSBkcmFmdDoNCg0KSW4geW91ciBJQU5BIENvbnNpZGVyYXRpb25zLCBJIGRvbid0 IHRoaW5rIEFQUFNBV0cgc2hvdWxkIGJlIHlvdXIgY2hhbmdlIGNvbnRyb2xsZXIsIGJlY2F1c2Ug dGhlcmUncyBubyBndWFyYW50ZWUgdGhpcyB3b3JraW5nIGdyb3VwIHdpbGwgYWx3YXlzIGV4aXN0 LiAgSXQgc2hvdWxkIGJlIHRoZSBJRVNHLCB0aGUgSUVURiwgYSBEZXNpZ25hdGVkIEV4cGVydCwg b3Igc3VjaGxpa2UuICBBbHNvLCB5b3VyIFB1Ymxpc2hlZCBTcGVjaWZpY2F0aW9uIHNob3VsZCBq dXN0IGJlICJbdGhpcyBtZW1vXSI7IHRoZSBSRkMgRWRpdG9yIHdpbGwgcmVwbGFjZSBpdC4NCg0K LU1TSywgeW91ciBmcmllbmRseSBuZWlnaGJvdXJob29kIGRvY3VtZW50IHNoZXBoZXJkDQo= From sm@elandsys.com Fri Mar 2 13:44:13 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDE9C21E8065 for ; Fri, 2 Mar 2012 13:44:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CzLyUyiPN4XD for ; Fri, 2 Mar 2012 13:44:11 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id DB5FD21E8013 for ; Fri, 2 Mar 2012 13:44:11 -0800 (PST) Received: from SUBMAN.elandsys.com ([41.136.238.103]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q22LhtAf012076 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Mar 2012 13:44:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1330724649; i=@elandsys.com; bh=Qc2Dy2BbdO7r/xz5tVhsx0rfVDqVxF5ECctUbEY2omc=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Content-Transfer-Encoding; b=Xjz8qYgmiffx9EYQaOU7zh08SY5Nh2RpBTSx64R8nYm/dXejp5xGfnRyNHsIOAXPh sZ58I2wUquPaMDQOqg/oVowfR84K2KZ3+fmHIMBs5M747j2xGo3gP69ySgWlKZNogk 30yJJ/YGWd1Kmdp5kQXO8Gq9dFa2miKlYxnrHKiU= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1330724649; i=@elandsys.com; bh=Qc2Dy2BbdO7r/xz5tVhsx0rfVDqVxF5ECctUbEY2omc=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Content-Transfer-Encoding; b=hvqgdqULSg32EMrZdLgGaIVGvSP78BZRQUGzqqSso7Kce06gw66HJZ2mhVEV5kBic 5mmVK6CQPQiFVpRAmpcf/O4bpyfB0+R+hkuLVA602+NKRkAtD0bOTOYL3ZSc+qTOvl SIlQE1GacID4MgMkmeSReO/QglIuVQp7ltAMHgww= Message-Id: <6.2.5.6.2.20120302133719.099b9ae0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 02 Mar 2012 13:43:16 -0800 To: apps-discuss@ietf.org From: S Moonesamy In-Reply-To: <6.2.5.6.2.20120301165335.09969be8@elandnews.com> References: <6.2.5.6.2.20120301165335.09969be8@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [apps-discuss] Apps Area Directorate Report for February 2012 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 02 Mar 2012 21:44:13 -0000 At 17:03 01-03-2012, S Moonesamy wrote: >The following reviews were performed in February 2012: [snip] > Martin Durst draft-ietf-mile-template-02 The above should be: Martin D=FCrst draft-ietf-mile-template-02 I apologize to Martin D=FCrst for misspelling his name. Regards, S. Moonesamy=20 From macar@cloudmark.com Fri Mar 2 14:15:44 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 090E321F858E for ; Fri, 2 Mar 2012 14:15:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fdq-VjFnvBYi for ; Fri, 2 Mar 2012 14:15:43 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 6454D21F858A for ; Fri, 2 Mar 2012 14:15:43 -0800 (PST) Received: from [172.20.2.21] (172.20.2.21) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 2 Mar 2012 14:15:42 -0800 Message-ID: <4F51468E.4000006@cloudmark.com> Date: Fri, 2 Mar 2012 14:15:42 -0800 From: Mike Acar User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: References: <4F4FD7EB.8080004@cloudmark.com> <1330638087.2531.7.camel@neutron> In-Reply-To: <1330638087.2531.7.camel@neutron> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.20.2.21] Subject: Re: [apps-discuss] Feedback on draft-ietf-appsawg-json-patch-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 02 Mar 2012 22:15:44 -0000 On 03/01/2012 01:41 PM, Paul C. Bryan wrote: > On Thu, 2012-03-01 at 12:11 -0800, Mike Acar wrote: >> What constitutes equality when the values in question can be trees of >> objects and arrays? Can this even be usefully defined in general? > > The value within the JSON document should be equal to the value in the > JSON Patch document; if these values contain objects or arrays, they > must be equal (i.e. same order of elements, with the same values). "Same order" applies only to arrays, right? >> My next concern is with locations. > An earlier draft of JSON Patch actually had separate parent node and > child to add, as you demonstrate below, as well as calling out a > specific "op" member. It received a number of objections, on the grounds > of being too verbose. Heh. Sorry, I didn't see that discussion in the list archive. > I changed the add operation to add the node specified in the pointer, > and changed the language in JSON Pointer accordingly to allow for > this (i.e. the MAY language instead of MUST/SHOULD). This language is > admittedly still a bit awkward. The two definitions still yield the problem that a Patch implementation has to parse the Pointer, or implement its own Pointer traversal with a parent reference. I think that's worse than verbosity. Maybe something like { "at" : "/a/b", "add" : "c", "value" : "foo" } { "at" : "/a/b", "remove" : "c" } would be terse enough? >> There's no mention of what to do if the implementation does not return >> an error, leaving the behavior essentially undefined. Implicitly undefined, that is. >> So to avoid depending upon undefined behavior, an implementation of >> Patch would have to parse the Pointer, remove the "target" value >> from the end, and then traverse the JSON objects to find the parent >> of the target. > > These specifications do very little to define how to handle errors > beyond terminating processing and indicating an error condition. I don't think Pointer can even say this MAY be an error: that's one of the semantics an application assigns to Pointers (cf http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04411.html). For Patch, in my opinion it MUST be an error if a Pointer reference token can't be found in an object or array - but the consequence of that is that pointers have to point to parents. >> So what about moving an location to itself? >> I'm ok with just defining moving a location to itself to be a no-op. > > Since it is functionally identical to removing then re-adding, then > checking for the presence of the value before removing would not be > functionally identical. If adding the no-op language makes this > clearer, I'd be fine adding it. I think explicitly saying "checking for the presence of the value before removing would not be functionally identical" is a bit better, since it shows the special case isn't actually special. But either's fine. -- Mike Acar - - macar at cloudmark dot com From macar@cloudmark.com Fri Mar 2 14:19:23 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13FB321E8049 for ; Fri, 2 Mar 2012 14:19:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mcBbAtt0lmb4 for ; Fri, 2 Mar 2012 14:19:22 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 9EB9521E8010 for ; Fri, 2 Mar 2012 14:19:22 -0800 (PST) Received: from [172.20.2.21] (172.20.2.21) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 2 Mar 2012 14:19:22 -0800 Message-ID: <4F51476A.7080307@cloudmark.com> Date: Fri, 2 Mar 2012 14:19:22 -0800 From: Mike Acar User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: IETF Apps Discuss References: <4F4FD8A5.6010603@cloudmark.com> In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [172.20.2.21] Subject: Re: [apps-discuss] Feedback on draft-ietf-appsawg-json-pointer-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 02 Mar 2012 22:19:23 -0000 On 03/01/2012 12:30 PM, Tim Bray wrote: > On Thu, Mar 1, 2012 at 12:14 PM, Mike Acar wrote: > >> However, the tokens and values are Unicode >> strings; I'm not an expert in Unicode, but my impression is that testing >> Unicode strings for equality is not as simple as comparing sequences of >> bytes. For example, there are linguistic considerations... > > There are lots of considerations, the W3C once wrote a big huge > complicated spec on normalization forms. I feared this was the case. > I would say explicitly don’t go there. I could see the spec advising > implementors to watch out for this, but two strings are equal if they > have the same number of Unicode characters and the codepoints are > positionwise equal; otherwise not. This sounds good to me. -- Mike Acar - - macar at cloudmark dot com From macar@cloudmark.com Fri Mar 2 14:34:34 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8ECE21E8049 for ; Fri, 2 Mar 2012 14:34:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XxS+VaxYTKFO for ; Fri, 2 Mar 2012 14:34:34 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 6DDBD21E8010 for ; Fri, 2 Mar 2012 14:34:34 -0800 (PST) Received: from [172.20.2.21] (172.20.2.21) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 2 Mar 2012 14:34:33 -0800 Message-ID: <4F514AF9.5010506@cloudmark.com> Date: Fri, 2 Mar 2012 14:34:33 -0800 From: Mike Acar User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: References: <4F4FD8A5.6010603@cloudmark.com> <1330638350.2531.11.camel@neutron> In-Reply-To: <1330638350.2531.11.camel@neutron> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.20.2.21] Subject: Re: [apps-discuss] Feedback on draft-ietf-appsawg-json-pointer-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 02 Mar 2012 22:34:35 -0000 On 03/01/2012 01:45 PM, Paul C. Bryan wrote: > On Thu, 2012-03-01 at 12:14 -0800, Mike Acar wrote: >> There's also the question of JSON documents with different encodings; > Since they're logically the same underlying Unicode representations, I'm > not sure there's any issue to consider here. Probably not in practice; as you and I discussed off-list, most implementations will not actually be working on the JSON texts themselves. >> Another issue is that the evaluation scheme implies some application >> semantics. >> It's easy to imagine a case where a Pointer refers to a deep hierarchy, >> e.g. /a/b/c/d, and the application semantics of following it are to >> create automatically any non-existent intermediate objects. >> >> My initial thought was that the Pointer RFC should explicitly say that >> specs which use it (e.g. Patch) should define semantics for ambiguous >> cases (non-unique or non-existent member names, array index out of >> bounds, etc). There is another case: What to do if a non-terminal reference token names a value which is not a structured type; e.g. { "a" : "b" } How should you interpret "/a/c/d"? For Patch this should be an error, but another application might promote the value of "a" from a string to an object or array. If the Pointer RFC says this MAY be an error, it disallows those semantics. >> That can still result in a user of Pointer having to implement it >> himself, if there are no implementations which offer him precisely >> what he needs. >> >> Is it preferrable to explicitly say "You must make these decisions >> for your use case" instead of "Behavior in these cases is >> undefined"? > > I'm not sure. I'm open to suggestions from the apps working group... -- Mike Acar - - macar at cloudmark dot com From msk@cloudmark.com Fri Mar 2 14:47:57 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D347721E8065 for ; Fri, 2 Mar 2012 14:47:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.604 X-Spam-Level: X-Spam-Status: No, score=-102.604 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mc3BAc38-EFi for ; Fri, 2 Mar 2012 14:47:57 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id 4AFCD21E8010 for ; Fri, 2 Mar 2012 14:47:57 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Fri, 2 Mar 2012 14:47:48 -0800 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Thread-Topic: [apps-discuss] Feedback on draft-ietf-appsawg-json-pointer-00 Thread-Index: AQHM9+gK+yT3RkbwbUqP3rSx/ahFYpZWf6IAgAGf8YD//3zT8A== Date: Fri, 2 Mar 2012 22:47:48 +0000 Message-ID: <9452079D1A51524AA5749AD23E003928077013@exch-mbx901.corp.cloudmark.com> References: <4F4FD8A5.6010603@cloudmark.com> <1330638350.2531.11.camel@neutron> <4F514AF9.5010506@cloudmark.com> In-Reply-To: <4F514AF9.5010506@cloudmark.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [apps-discuss] Feedback on draft-ietf-appsawg-json-pointer-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 02 Mar 2012 22:47:58 -0000 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] On Behalf Of Mike Acar > Sent: Friday, March 02, 2012 2:35 PM > To: apps-discuss@ietf.org > Subject: Re: [apps-discuss] Feedback on draft-ietf-appsawg-json-pointer-0= 0 >=20 > >> It's easy to imagine a case where a Pointer refers to a deep > >> hierarchy, e.g. /a/b/c/d, and the application semantics of following > >> it are to create automatically any non-existent intermediate objects. > >> > >> My initial thought was that the Pointer RFC should explicitly say > >> that specs which use it (e.g. Patch) should define semantics for > >> ambiguous cases (non-unique or non-existent member names, array index > >> out of bounds, etc). >=20 > There is another case: What to do if a non-terminal reference token > names a value which is not a structured type; e.g. >=20 > { "a" : "b" } >=20 > How should you interpret "/a/c/d"? For Patch this should be an error, > but another application might promote the value of "a" from a string to > an object or array. If the Pointer RFC says this MAY be an error, it > disallows those semantics. I don't agree that MAY disallows anything, but I do think the current expre= ssion is too mushy. I think it's fine for the pointer document to say that the handling of such= cases is application-specific, but it should actually say that, perhaps by= using your two examples to illustrate how different applications using the= pointer specification could behave. -MSK From msk@cloudmark.com Fri Mar 2 14:50:46 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F10221F8568 for ; Fri, 2 Mar 2012 14:50:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.604 X-Spam-Level: X-Spam-Status: No, score=-102.604 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FpwglCtcrnmD for ; Fri, 2 Mar 2012 14:50:45 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id DD32D21E806D for ; Fri, 2 Mar 2012 14:50:44 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by EXCH-HTCAS901.corp.cloudmark.com ([fe80::2966:6846:8d89:4681%12]) with mapi id 14.01.0355.002; Fri, 2 Mar 2012 14:50:44 -0800 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Thread-Topic: [apps-discuss] Feedback on draft-ietf-appsawg-json-patch-00 Thread-Index: AQHM9+d/ykpyZt+42kKhe+gEF12z9JZWfmmAgAGb5wD//4MRcA== Date: Fri, 2 Mar 2012 22:50:43 +0000 Message-ID: <9452079D1A51524AA5749AD23E003928077040@exch-mbx901.corp.cloudmark.com> References: <4F4FD7EB.8080004@cloudmark.com> <1330638087.2531.7.camel@neutron> <4F51468E.4000006@cloudmark.com> In-Reply-To: <4F51468E.4000006@cloudmark.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [apps-discuss] Feedback on draft-ietf-appsawg-json-patch-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 02 Mar 2012 22:50:46 -0000 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] On Behalf Of Mike Acar > Sent: Friday, March 02, 2012 2:16 PM > To: apps-discuss@ietf.org > Subject: Re: [apps-discuss] Feedback on draft-ietf-appsawg-json-patch-00 >=20 > >> So to avoid depending upon undefined behavior, an implementation of > >> Patch would have to parse the Pointer, remove the "target" value from > >> the end, and then traverse the JSON objects to find the parent of the > >> target. > > > > These specifications do very little to define how to handle errors > > beyond terminating processing and indicating an error condition. >=20 > I don't think Pointer can even say this MAY be an error: that's one of > the semantics an application assigns to Pointers (cf > http://www.ietf.org/mail-archive/web/apps- > discuss/current/msg04411.html). >=20 > For Patch, in my opinion it MUST be an error if a Pointer reference > token can't be found in an object or array - but the consequence of > that is that pointers have to point to parents. +1. This points (hah) back to the pointer document thread: That document c= an leave handling of failed pointer resolution explicitly undefined, but th= e application has to say what semantics are to be applied in such cases. F= or the patch document, it MUST be an error. -MSK From bernie@ietf.hoeneisen.ch Sat Mar 3 05:06:45 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F18BA21F874F; Sat, 3 Mar 2012 05:06:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iqeeM6iWPkg6; Sat, 3 Mar 2012 05:06:45 -0800 (PST) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by ietfa.amsl.com (Postfix) with ESMTP id DCFA921F8749; Sat, 3 Mar 2012 05:06:44 -0800 (PST) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.71) (envelope-from ) id 1S3ofZ-0002w0-Ll; Sat, 03 Mar 2012 14:06:41 +0100 Date: Sat, 3 Mar 2012 14:06:41 +0100 (CET) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: Lawrence Conroy In-Reply-To: <2A45B5D5-FEAD-4813-96D3-55FA757ADD8C@insensate.co.uk> Message-ID: References: <2A45B5D5-FEAD-4813-96D3-55FA757ADD8C@insensate.co.uk> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false Cc: IETF ENUM list , Gonzalo Camarillo , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [Enum] Enumservice registrations X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Mar 2012 13:06:46 -0000 Hi Lawrence Thanks for sharing your view on the Enumservice registration process wrt. draft-goix-appsawg-enum-sn-service-00.txt. And thanks Rich for spotting this I/D and forwarding it to the ENUM list. It appears to me that the authors simply have not read RFC 6117 too thoroughly, and therefore don't follow the RFC-6117-process. However, I am not worried at this point in time, as the I/D is a -00 individual submission. Furthermore, before any Enumservice advances, it has to go through my hands, and I will ensure each proposal gets sufficient community review (in particular ENUM community), before any decision is made. Thus, not-follow-the-process simply results in delay, which the authors otherwise could avoid. Should I happen to meet the authors in Paris, I'll talk to them about this. I hope this addresses your concerns. cheers, Bernie, IESG Designated Expert for ENUM PS: And no, we are not intending to update RFC 6117 any time soon... ;-) -- http://ucom.ch/ Tech Consulting for Internet Technology On Sat, 3 Mar 2012, Lawrence Conroy wrote: > Hi esteemed AD, ENUMers, > As a process issue: > - Section 4.1 of RFC6117 suggests that authors of Enumservices should > look for existing work in the Enum mailing list. > - Section 6.3 of RFC6117 states that authors MUST send a mail to the > enum list with a link to the registration doc. > > In the current case, Richard forwarded the id-announce mail for > draft-goix-appsawg-enum-sn-service-00.txt to the list; the authors have > not. > > So ... > Can someone ensure at least that I-Ds for Enumservices are > ALWAYS/Automatically sent to the enum mailing list? (i.e., if it's an > Enumservice, the enum mailing list is an interested party) > > The application detail for Enumservices may well be covered in other > WGs, but there must be a link the ENUM mailing list. Otherwise 6117 > needs an update -- please, no! > > all the best, > Lawrence > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www.ietf.org/mailman/listinfo/enum > From internet-drafts@ietf.org Sat Mar 3 08:43:19 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83A2C21F8707; Sat, 3 Mar 2012 08:43:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YrJFgvJUWB1z; Sat, 3 Mar 2012 08:43:16 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9668C21F86F0; Sat, 3 Mar 2012 08:43:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120303164316.15859.26453.idtracker@ietfa.amsl.com> Date: Sat, 03 Mar 2012 08:43:16 -0800 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-about-uri-scheme-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Mar 2012 16:43:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Worki= ng Group of the IETF. Title : The "about" URI Scheme Author(s) : Lachlan Hunt Mykyta Yevstifeyev Filename : draft-ietf-appsawg-about-uri-scheme-02.txt Pages : 7 Date : 2012-03-03 This document specifies the "about" URI scheme, that is widely used by Web browsers and some other applications to designate access to their internal resources, such as settings, application information, hidden built-in functionality, and so on. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-appsawg-about-uri-scheme-02.= txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-appsawg-about-uri-scheme-02.t= xt From barryleiba.mailing.lists@gmail.com Sat Mar 3 11:50:10 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED34521F8644 for ; Sat, 3 Mar 2012 11:50:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.986 X-Spam-Level: X-Spam-Status: No, score=-102.986 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eSSj40uk153M for ; Sat, 3 Mar 2012 11:50:10 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6AE5E21F85D3 for ; Sat, 3 Mar 2012 11:50:10 -0800 (PST) Received: by yhpp34 with SMTP id p34so1380427yhp.31 for ; Sat, 03 Mar 2012 11:50:10 -0800 (PST) Received-SPF: pass (google.com: domain of barryleiba.mailing.lists@gmail.com designates 10.236.145.230 as permitted sender) client-ip=10.236.145.230; Authentication-Results: mr.google.com; spf=pass (google.com: domain of barryleiba.mailing.lists@gmail.com designates 10.236.145.230 as permitted sender) smtp.mail=barryleiba.mailing.lists@gmail.com; dkim=pass header.i=barryleiba.mailing.lists@gmail.com Received: from mr.google.com ([10.236.145.230]) by 10.236.145.230 with SMTP id p66mr20000284yhj.27.1330804210130 (num_hops = 1); Sat, 03 Mar 2012 11:50:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=SmOL6k9oVVAhVCa7rA24FwNQxeig7hK1g5FzVwLL+EQ=; b=aUpnuJKq97tVYA0GKfc3kiWUUNYxa4fcQYwC/eKvad98an98aZqQwGRzM//TXk1df+ T6PXUCLhWDFtn+uSeYSp7bQki5TSwzW4dlUMPK3ODy96Q7LF9ox+vt+rojqZ1b3CWkNz 5e8uM006krKHS86mRiOtZsRIf4s6oCUKromu+Tpq8zYvz7njozfGbxjUJ45N5hV2IIqS eU3vAzihVAJofB7gl4dnm8bTn5fkHR29oroTC20L6DwEw/tvbI36s181Wzs7MlPmVhhE iWMUNr9nIwFbNW8XPOl22RISFiyuy57XSs53GvwdxGVGMxKUAxCChrIrb6Uf4QpPaUmN zzEA== MIME-Version: 1.0 Received: by 10.236.145.230 with SMTP id p66mr15874095yhj.27.1330804209999; Sat, 03 Mar 2012 11:50:09 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.106.16 with HTTP; Sat, 3 Mar 2012 11:50:09 -0800 (PST) In-Reply-To: <20120303164316.15859.26453.idtracker@ietfa.amsl.com> References: <20120303164316.15859.26453.idtracker@ietfa.amsl.com> Date: Sat, 3 Mar 2012 14:50:09 -0500 X-Google-Sender-Auth: KMbUwTAaLtQNdjodaEkXP0uClN0 Message-ID: From: Barry Leiba To: Mykyta Yevstifeyev Content-Type: multipart/alternative; boundary=20cf3040eb3233df0104ba5c00f4 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-about-uri-scheme-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 03 Mar 2012 19:50:11 -0000 --20cf3040eb3233df0104ba5c00f4 Content-Type: text/plain; charset=ISO-8859-1 Thanks, Mykyta. Please take out the comment in the IANA Considerations section, and then we will start working-group last call on this. The policy specified there has working-group consensus, and there is no need to revisit it (except as people might comment during last call). Barry, AppsAWG chair --20cf3040eb3233df0104ba5c00f4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks, Mykyta.
Please take out the comment in the IANA Considerations s= ection, and then we will start working-group last call on this. =A0The poli= cy specified there has working-group consensus, and there is no need to rev= isit it (except as people might comment during last call).

Barry, AppsAWG chair
--20cf3040eb3233df0104ba5c00f4-- From evnikita2@gmail.com Sat Mar 3 21:06:59 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA8A921F85CC for ; Sat, 3 Mar 2012 21:06:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.396 X-Spam-Level: X-Spam-Status: No, score=-2.396 tagged_above=-999 required=5 tests=[AWL=-1.248, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6dIE5e8UYAmg for ; Sat, 3 Mar 2012 21:06:59 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1F0F721F8554 for ; Sat, 3 Mar 2012 21:06:59 -0800 (PST) Received: by obbta4 with SMTP id ta4so1163823obb.31 for ; Sat, 03 Mar 2012 21:06:58 -0800 (PST) Received-SPF: pass (google.com: domain of evnikita2@gmail.com designates 10.60.6.164 as permitted sender) client-ip=10.60.6.164; Authentication-Results: mr.google.com; spf=pass (google.com: domain of evnikita2@gmail.com designates 10.60.6.164 as permitted sender) smtp.mail=evnikita2@gmail.com; dkim=pass header.i=evnikita2@gmail.com Received: from mr.google.com ([10.60.6.164]) by 10.60.6.164 with SMTP id c4mr7275545oea.43.1330837618819 (num_hops = 1); Sat, 03 Mar 2012 21:06:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kANdeWBGtZe5px+HldkFTDYKAHJKGOkRx7CZnt3FSyw=; b=yYfYWWZBGU7VO2CJyqyExJvCliclE4Zbj4vxdVixvcRiVx2pvPr5ODsII+J6NMNM87 qkSmIqM9gfzd/ymGgfGtSDKromJwViQ5UomNQKnQdhj6U8OLraafm7bZxanqLL1w8yE7 cG9oEL2Hp07b7iVVvBBtQeN69HnCL0mKld2MBiP/Y+wRdsIxRvtL9GkUCIqPFOWC5JfZ T96dgb3kvzf4GvB+BvOTn82qH9yptUQKPYuwLqCp0Los8zYxKrsVm7d8U/YkBIhK2d8T IVQfAq8mKgcfr6OXsqEKn5uEidwb7v/5G0iLWpQvWpweNFbbeD+v5uzVMpD5y4QLBku3 19uw== MIME-Version: 1.0 Received: by 10.60.6.164 with SMTP id c4mr6198722oea.43.1330837618778; Sat, 03 Mar 2012 21:06:58 -0800 (PST) Received: by 10.182.60.1 with HTTP; Sat, 3 Mar 2012 21:06:58 -0800 (PST) In-Reply-To: References: <20120303164316.15859.26453.idtracker@ietfa.amsl.com> Date: Sun, 4 Mar 2012 07:06:58 +0200 Message-ID: From: Mykyta Yevstifeyev To: Barry Leiba Content-Type: multipart/alternative; boundary=e89a8f83ab7d8561aa04ba63c7dc Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-about-uri-scheme-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 04 Mar 2012 05:06:59 -0000 --e89a8f83ab7d8561aa04ba63c7dc Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Ok, now will upload -03 w/o that remark. Mykyta 3 =CD=C1=D2=D4=C1 2012 =C7. 21:50 =D0=CF=CC=D8=DA=CF=D7=C1=D4=C5=CC=D8 Barr= y Leiba =CE=C1=D0=C9=D3=C1=CC: > Thanks, Mykyta. > Please take out the comment in the IANA Considerations section, and then > we will start working-group last call on this. The policy specified ther= e > has working-group consensus, and there is no need to revisit it (except a= s > people might comment during last call). > > Barry, AppsAWG chair > --e89a8f83ab7d8561aa04ba63c7dc Content-Type: text/html; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Ok, now will upload -03 w/o that remark.=9A Mykyta

3 =CD=C1=D2=D4=C1 2012=9A=C7. 21:50 =D0=CF=CC=D8=DA=CF=D7=C1=D4= =C5=CC=D8 Barry Leiba <barryleiba@computer.org> =CE=C1=D0=C9=D3=C1=CC:
Thanks, Mykyta.
Please take out the comme= nt in the IANA Considerations section, and then we will start working-group= last call on this. =9AThe policy specified there has working-group consens= us, and there is no need to revisit it (except as people might comment duri= ng last call).

Barry, AppsAWG chair

--e89a8f83ab7d8561aa04ba63c7dc-- From internet-drafts@ietf.org Sat Mar 3 21:09:00 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D52F21F8624; Sat, 3 Mar 2012 21:09:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oXT8bVU7YkEs; Sat, 3 Mar 2012 21:09:00 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3139621F8554; Sat, 3 Mar 2012 21:09:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120304050900.6994.92522.idtracker@ietfa.amsl.com> Date: Sat, 03 Mar 2012 21:09:00 -0800 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-about-uri-scheme-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 04 Mar 2012 05:09:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Worki= ng Group of the IETF. Title : The "about" URI Scheme Author(s) : Lachlan Hunt Mykyta Yevstifeyev Filename : draft-ietf-appsawg-about-uri-scheme-03.txt Pages : 7 Date : 2012-03-03 This document specifies the "about" URI scheme, that is widely used by Web browsers and some other applications to designate access to their internal resources, such as settings, application information, hidden built-in functionality, and so on. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-appsawg-about-uri-scheme-03.= txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-appsawg-about-uri-scheme-03.t= xt From yaojk@cnnic.cn Sat Mar 3 22:52:04 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E589321F85A5 for ; Sat, 3 Mar 2012 22:52:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.022 X-Spam-Level: X-Spam-Status: No, score=-101.022 tagged_above=-999 required=5 tests=[AWL=1.575, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TggrsPK+wGpd for ; Sat, 3 Mar 2012 22:52:04 -0800 (PST) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id CECF421F85A3 for ; Sat, 3 Mar 2012 22:52:01 -0800 (PST) X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown127.0.0.1 (HELO computer) (127.0.0.1) by 127.0.0.1 with SMTP; Sun, 04 Mar 2012 14:51:53 +0800 Message-ID: <004c01ccf9d3$49b29dc0$cb01a8c0@computer> From: "Jiankang Yao" To: , References: <20120304050900.6994.92522.idtracker@ietfa.amsl.com> Date: Sun, 4 Mar 2012 14:51:54 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3664 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 Subject: Re: [apps-discuss] I-D Action:draft-ietf-appsawg-about-uri-scheme-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 04 Mar 2012 06:52:05 -0000 Thanks Mykyta for updating this draft. I believe that the version 03 draft has addressed all the major issues raised in WG. This draft will get WGLC soon. If you have any more comments, pls let the editors know it. The editor may update one more version before WGLC. thanks. Jiankang Yao (as a co-chair) ----- Original Message ----- From: To: Cc: Sent: Sunday, March 04, 2012 1:09 PM Subject: [apps-discuss] I-D Action:draft-ietf-appsawg-about-uri-scheme-03.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Applications Area Working > Group Working Group of the IETF. > > Title : The "about" URI Scheme > Author(s) : Lachlan Hunt > Mykyta Yevstifeyev > Filename : draft-ietf-appsawg-about-uri-scheme-03.txt > Pages : 7 > Date : 2012-03-03 > > This document specifies the "about" URI scheme, that is widely used > by Web browsers and some other applications to designate access to > their internal resources, such as settings, application information, > hidden built-in functionality, and so on. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-appsawg-about-uri-scheme-03.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-appsawg-about-uri-scheme-03.txt > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From mnot@mnot.net Sun Mar 4 19:25:51 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 497E621F86A5; Sun, 4 Mar 2012 19:25:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.816 X-Spam-Level: X-Spam-Status: No, score=-104.816 tagged_above=-999 required=5 tests=[AWL=-2.217, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qhXjmTMmgXRQ; Sun, 4 Mar 2012 19:25:50 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA0E21F8682; Sun, 4 Mar 2012 19:25:50 -0800 (PST) Received: from mnot-mini.mnot.net (unknown [118.209.12.241]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 04D9250A64; Sun, 4 Mar 2012 22:25:41 -0500 (EST) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 5 Mar 2012 14:25:37 +1100 Message-Id: <8E1AF099-0252-4032-8769-E8F794BFFAD2@mnot.net> To: "apps-discuss@ietf.org Discuss" , draft-ietf-pkix-cmp-transport-protocols.all@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Cc: "iesg@ietf.org IESG" Subject: [apps-discuss] APPSDIR review of draft-ietf-pkix-cmp-transport-protocols X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 05 Mar 2012 03:25:51 -0000 I have been selected as the Applications Area Directorate reviewer for = this draft (for background on appsdir, please see = ). Please resolve these comments along with any other Last Call comments = you may receive. Please wait for direction from your document shepherd = or AD before posting a new version of the draft. Document: draft-ietf-pkix-cmp-transport-protocols-16 Title: Internet X.509 Public Key Infrastructure -- HTTP Transport for = CMP Reviewer: Mark Nottingham Review Date: March 4, 2012 Summary: This draft is not ready for publication as a Proposed Standard = and should be revised before publication. Major Issues:=20 * This draft describes a HTTP-based protocol that exclusively uses POST; = i.e., it effectively tunnels. This is widely recognised as bad practice, and should be avoided where = possible. A good use of HTTP is one that defines resources with = particular behaviours, formats with associated semantics, and then uses = links to navigate / manipulate the state of the application. GET should = be used for retrieval (it's not even clear if it's allowed / used in = this draft). Preferably, the draft should be re-worked to use HTTP well, rather than = tunnelling.=20 Alternatively, there should be a notice inserted that explains this = draft is tunnelling over HTTP, and this practice should not be emulated. Minor Issues: * Section 3.1 "HTTP Versions" - the wording here doesn't reflect how = HTTP versioning works; see RFC2145. Suggest: "Clients MUST support = HTTP/1.0 [RFC1945], and SHOULD support HTTP/1.1 [RFC2616]." * Section 3.2 "Persistent Connections" effectively re-specifies part of = HTTP; this section should be removed. * Section 3.6 "HTTP Request-URI" -- What does "depicting a directly" = mean? HTTP and URIs say nothing about directories. * Section 3.8 "HTTP Considerations" -- Pragma: no-cache is not = meaningful in responses, and shouldn't be limited to just HTTP/1.0, as = versioning is hop-by-hop, not end-to-end. In any case, this paragraph = can be dropped, because POST isn't cacheable by default, and is never = cached in practice. * Section 3.8 "HTTP Considerations" -- The paragraphs on connection = management and content-codings are re-specifying HTTP, and should be = removed. * Section 9 "Security Considerations" #2 -- "There is no security at the = HTTP protocol level" is a gross misstatement. * Section 9 "Security Considerations" #2 -- "The client SHOULD NOT = support the "301 Moved Permanently status code" is ambiguous. Do you = mean that it should never be followed, or that it should not be stored = as a permanent redirect? A statement merely warning of the effects of a = MITM would be more useful here. -- Mark Nottingham http://www.mnot.net/ From zach@sensinode.com Mon Mar 5 01:49:44 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8D4621F85D1 for ; Mon, 5 Mar 2012 01:49:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.676 X-Spam-Level: X-Spam-Status: No, score=-3.676 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J0oXX4Te+6kB for ; Mon, 5 Mar 2012 01:49:43 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id F2A1821F85C3 for ; Mon, 5 Mar 2012 01:49:42 -0800 (PST) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q259neE3014108 for ; Mon, 5 Mar 2012 11:49:40 +0200 From: Zach Shelby Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 5 Mar 2012 11:49:40 +0200 References: <20120305094330.27895.2135.idtracker@ietfa.amsl.com> To: General discussion of application-layer protocols Message-Id: Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [apps-discuss] Fwd: New Version Notification for draft-shelby-exi-registration-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 05 Mar 2012 09:49:44 -0000 As per the discussion regarding an +exi suffix on this list, I wrote up = a short draft describing the registration for such a suffix, when it = would be applicable, and what the interoperability requirements are. I = will send this to the CoRE list and to ZigBee SE2 for comments as well. http://www.ietf.org/id/draft-shelby-exi-registration-00.txt Zach Begin forwarded message: > From: internet-drafts@ietf.org > Date: March 5, 2012 11:43:30 AM GMT+02:00 > To: zach@sensinode.com > Subject: New Version Notification for = draft-shelby-exi-registration-00.txt >=20 > A new version of I-D, draft-shelby-exi-registration-00.txt has been = successfully submitted by Zach Shelby and posted to the IETF repository. >=20 > Filename: draft-shelby-exi-registration > Revision: 00 > Title: The +exi Media Type Suffix > Creation date: 2012-03-05 > WG ID: Individual Submission > Number of pages: 5 >=20 > Abstract: > Efficient XML Interchange (EXI) is an XML representation technique > specified by the W3C to provie a binary alternative to the standard > text XML representation. This document defines a new Structure > Syntax Suffix "+exi" for use in a specific class of protocols, where > "exi" content-type encoding or the generic = "application/exi" Media > Type are not applicable. >=20 >=20 >=20 >=20 > The IETF Secretariat --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From vesely@tana.it Mon Mar 5 02:44:40 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA1921F855F for ; Mon, 5 Mar 2012 02:44:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.65 X-Spam-Level: X-Spam-Status: No, score=-4.65 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-rvwFWfQZ4Q for ; Mon, 5 Mar 2012 02:44:38 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 124E321F852A for ; Mon, 5 Mar 2012 02:44:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1330944276; bh=0fv1z78pY7x1eyqM/C8pPu7h0VJjaip93QSMkdLK25I=; l=908; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=DhYkzs5wQZRSursQd1qwx8UTp/Bv7SL/aV6qDCVSWosGQJUZGWaYE9CPr2qyTeClQ iucq5s8qRtt96Ge2qh/xAtOFVV7TggFSw8Z4Qq4ZG0ejlX4QU5/hEMNh/hGWRaY7Of fz+8X3Iyqp7oTtcLBzPX3xRLyNVq6pUrmS6uNms0= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Mon, 05 Mar 2012 11:44:36 +0100 id 00000000005DC039.000000004F549914.0000454B Message-ID: <4F549914.2020907@tana.it> Date: Mon, 05 Mar 2012 11:44:36 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <9452079D1A51524AA5749AD23E00392806D278@exch-mbx901.corp.cloudmark.com> <2183832.0qjo89hoBY@scott-latitude-e6320> In-Reply-To: <2183832.0qjo89hoBY@scott-latitude-e6320> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] Malformed mail guidance document (draft-ietf-appsawg-malformed-mail) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 05 Mar 2012 10:44:40 -0000 On 01/Mar/12 05:51, Scott Kitterman wrote: > On Wednesday, February 29, 2012 07:56:41 PM Murray S. Kucherawy wrote: >> Hi all, > ... >> When it reappears, I'd love to see some additional review comments, >> especially the submission of new cases that should be included in the first >> version. I imagine there are many. > > One thought that immediately came to mind is that it might be useful to > mention case changes in header fields in paragraph 7. "Helpful" MTAs doing > this have been responsible for more than a few hard to troubleshoot DKIM > failures. More non-malformation cases occur on MIME rewriting. It may be helpful to encourage tool developers to stick to the original choice of token / quoted-string in MIME parameters (format="flowed" vs. format=flowed see http://tools.ietf.org/html/rfc2045#section-5.1 ) as well as keeping the original boundaries, if at all possible. From ned.freed@mrochek.com Mon Mar 5 07:33:32 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D009621F87A1 for ; Mon, 5 Mar 2012 07:33:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pMZoAgUOHfG7 for ; Mon, 5 Mar 2012 07:33:32 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id EED3B21F8794 for ; Mon, 5 Mar 2012 07:33:31 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OCQYO400Q8007HAO@mauve.mrochek.com> for apps-discuss@ietf.org; Mon, 5 Mar 2012 07:33:27 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OCPMUVDUMO00ZUIL@mauve.mrochek.com>; Mon, 5 Mar 2012 07:33:23 -0800 (PST) Message-id: <01OCQYO1P7T400ZUIL@mauve.mrochek.com> Date: Mon, 05 Mar 2012 07:25:31 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Mon, 05 Mar 2012 11:44:36 +0100" <4F549914.2020907@tana.it> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <9452079D1A51524AA5749AD23E00392806D278@exch-mbx901.corp.cloudmark.com> <2183832.0qjo89hoBY@scott-latitude-e6320> <4F549914.2020907@tana.it> To: Alessandro Vesely DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1330961613; bh=mZCS8Dex8g5iBO8rJhKH9tt5aDLEyi+GNE+MQNSSrp0=; h=Cc:Message-id:Date:From:Subject:In-reply-to:MIME-version: Content-type:References:To; b=OHU0X52W8ZXJJzu7Pa6clEMB6KAU/P24Re9rM9TNTI5OM2nQip3Yxn1g+bHgah+Up vqJ46c1gpnkN2ibD0rzus+9/EanPCdWdCDLA8wfnTjCLKS9kyN4tjynAXXde5auV4C QtLnwi2DOhF/yFqH4S2aPm0oniysMmfkE6AI5tKM= Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Malformed mail guidance document (draft-ietf-appsawg-malformed-mail) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 05 Mar 2012 15:33:32 -0000 > On 01/Mar/12 05:51, Scott Kitterman wrote: > > On Wednesday, February 29, 2012 07:56:41 PM Murray S. Kucherawy wrote: > >> Hi all, > > ... > >> When it reappears, I'd love to see some additional review comments, > >> especially the submission of new cases that should be included in the first > >> version. I imagine there are many. > > > > One thought that immediately came to mind is that it might be useful to > > mention case changes in header fields in paragraph 7. "Helpful" MTAs doing > > this have been responsible for more than a few hard to troubleshoot DKIM > > failures. > More non-malformation cases occur on MIME rewriting. It's more like malformations in the original message get exposed if it's rewritten for whatever reason. You can sometimes avoid or at least defer this by avoiding unnecessary rewriting; unfortunatley people always seem to come up with more reasons for doing it. > It may be > helpful to encourage tool developers to stick to the original choice > of token / quoted-string in MIME parameters (format="flowed" vs. > format=flowed see http://tools.ietf.org/html/rfc2045#section-5.1 ) > as well as keeping the original boundaries, if at all possible. IMO both of these are really bad suggestions. The first assumes that all agents tolerate superfluous syntax and some actually require it; my experience has been exactly the reverse. The second effectively either mandates forced encoding to base64 of all parts or multi-pass processing to implement. The former often causes more problems than it solves, the latter is a both a PITA to implement as well as being more error-prone. Ned From vkg@bell-labs.com Mon Mar 5 08:31:58 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B71921F8844; Mon, 5 Mar 2012 08:31:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.899 X-Spam-Level: X-Spam-Status: No, score=-108.899 tagged_above=-999 required=5 tests=[AWL=1.700, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qp3gTnRammVF; Mon, 5 Mar 2012 08:31:57 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 67A7621F8843; Mon, 5 Mar 2012 08:31:57 -0800 (PST) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q25GVsET010848 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 5 Mar 2012 10:31:55 -0600 (CST) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q25GVsBS010461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 5 Mar 2012 10:31:54 -0600 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.235]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q25GVsm1018013; Mon, 5 Mar 2012 10:31:54 -0600 (CST) Message-ID: <4F54EB8C.60109@bell-labs.com> Date: Mon, 05 Mar 2012 10:36:28 -0600 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.1) Gecko/20120209 Thunderbird/10.0.1 MIME-Version: 1.0 To: "apps-discuss@ietf.org" , draft-ietf-mediactrl-6231-iana@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Cc: IESG IESG Subject: [apps-discuss] APPSDIR review of draft-ietf-mediactrl-6231-iana-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 05 Mar 2012 16:31:58 -0000 Document: draft-ietf-mediactrl-6231-iana-00 Title: IANA Registry for MEDIACTRL Interactive Voice Response Control Package Reviewer: Vijay K. Gurbani Review Date: Mar-05-2012 IETF Last Call Date: Mar-08-2012 IESG Telechat Date: Mar-15-2012 Summary: This draft is ready for publication as a Proposed Standard. Major issues: 0 Minor issues: 0 Major issues: 0 - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ From laurentwalter.goix@telecomitalia.it Mon Mar 5 09:13:10 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E8DF21F886E; Mon, 5 Mar 2012 09:13:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.219 X-Spam-Level: X-Spam-Status: No, score=-1.219 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h8cUqJ8LFM0i; Mon, 5 Mar 2012 09:13:09 -0800 (PST) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by ietfa.amsl.com (Postfix) with ESMTP id 198EA21F886C; Mon, 5 Mar 2012 09:13:08 -0800 (PST) Received: from GRFHUB702BA020.griffon.local (10.188.101.112) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 5 Mar 2012 18:13:06 +0100 Received: from GRFMBX704BA020.griffon.local ([10.188.101.16]) by GRFHUB702BA020.griffon.local ([10.188.101.112]) with mapi; Mon, 5 Mar 2012 18:13:06 +0100 From: Goix Laurent Walter To: Bernie Hoeneisen , Lawrence Conroy Date: Mon, 5 Mar 2012 18:13:04 +0100 Thread-Topic: [apps-discuss] [Enum] Enumservice registrations Thread-Index: Acz5PoDYAF2r5NokSzu5qkZOyao4lwBtEpGw Message-ID: References: <2A45B5D5-FEAD-4813-96D3-55FA757ADD8C@insensate.co.uk> In-Reply-To: Accept-Language: en-US, it-IT Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, it-IT x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IETF ENUM list , Gonzalo Camarillo , "apps-discuss@ietf.org" Subject: [apps-discuss] R: [Enum] Enumservice registrations X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 05 Mar 2012 17:13:10 -0000 Thank you Bernie and Lawrence for the exhaustive comments. The notification= to the enum list (and its first feedback) was faster than expected... We will produce a revision accordingly and based on other comments we recei= ve. Cheers walter -----Messaggio originale----- Da: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] Pe= r conto di Bernie Hoeneisen Inviato: sabato 3 marzo 2012 14.07 A: Lawrence Conroy Cc: IETF ENUM list; Gonzalo Camarillo; apps-discuss@ietf.org Oggetto: Re: [apps-discuss] [Enum] Enumservice registrations Hi Lawrence Thanks for sharing your view on the Enumservice registration process wrt. draft-goix-appsawg-enum-sn-service-00.txt. And thanks Rich for spotting this I/D and forwarding it to the ENUM list. It appears to me that the authors simply have not read RFC 6117 too thoroughly, and therefore don't follow the RFC-6117-process. However, I am not worried at this point in time, as the I/D is a -00 individual submission. Furthermore, before any Enumservice advances, it has to go through my hands, and I will ensure each proposal gets sufficient community review (in particular ENUM community), before any decision is made. Thus, not-follow-the-process simply results in delay, which the authors otherwise could avoid. Should I happen to meet the authors in Paris, I'll talk to them about this. I hope this addresses your concerns. cheers, Bernie, IESG Designated Expert for ENUM PS: And no, we are not intending to update RFC 6117 any time soon... ;-) -- http://ucom.ch/ Tech Consulting for Internet Technology On Sat, 3 Mar 2012, Lawrence Conroy wrote: > Hi esteemed AD, ENUMers, > As a process issue: > - Section 4.1 of RFC6117 suggests that authors of Enumservices should > look for existing work in the Enum mailing list. > - Section 6.3 of RFC6117 states that authors MUST send a mail to the > enum list with a link to the registration doc. > > In the current case, Richard forwarded the id-announce mail for > draft-goix-appsawg-enum-sn-service-00.txt to the list; the authors have > not. > > So ... > Can someone ensure at least that I-Ds for Enumservices are > ALWAYS/Automatically sent to the enum mailing list? (i.e., if it's an > Enumservice, the enum mailing list is an interested party) > > The application detail for Enumservices may well be covered in other > WGs, but there must be a link the ENUM mailing list. Otherwise 6117 > needs an update -- please, no! > > all the best, > Lawrence > > _______________________________________________ > enum mailing list > enum@ietf.org > https://www.ietf.org/mailman/listinfo/enum > _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. From vesely@tana.it Mon Mar 5 10:23:37 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8146121F88D7 for ; Mon, 5 Mar 2012 10:23:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.65 X-Spam-Level: X-Spam-Status: No, score=-4.65 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VCODw6PHx5JM for ; Mon, 5 Mar 2012 10:23:35 -0800 (PST) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 57D1A21F88D2 for ; Mon, 5 Mar 2012 10:23:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1330971812; bh=tqOHISwm2haLeO6HnYkDNPkjKXQi3mWBzanZxZWDQgM=; l=1921; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=dGgQSMmOH+XxNkxP01TXLeopQ2Yy/vpxWgZ/DQRlO0M+Xa44iHj0CE99m9Yp7gvoG B7POtzOUYlJp3+CCWnLppMLF5sVTwK3DfR2Ohtm/mKJ27qnDAb1FpNgKFa+44Pyme9 nbHAHKFtnKPm2tObgX/PZrte8A6aMfsvrJ/4sJRo= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Mon, 05 Mar 2012 19:23:32 +0100 id 00000000005DC039.000000004F5504A4.000039A2 Message-ID: <4F5504A4.6010902@tana.it> Date: Mon, 05 Mar 2012 19:23:32 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <9452079D1A51524AA5749AD23E00392806D278@exch-mbx901.corp.cloudmark.com> <2183832.0qjo89hoBY@scott-latitude-e6320> <4F549914.2020907@tana.it> <01OCQYO1P7T400ZUIL@mauve.mrochek.com> In-Reply-To: <01OCQYO1P7T400ZUIL@mauve.mrochek.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] Malformed mail guidance document (draft-ietf-appsawg-malformed-mail) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 05 Mar 2012 18:23:37 -0000 On 05/Mar/12 16:25, Ned Freed wrote: > >> More non-malformation cases occur on MIME rewriting. > > It's more like malformations in the original message get exposed if it's > rewritten for whatever reason. Hm... MIME doesn't seem to say that either is better than the other. Based on what you write below, I'd derive that token is better than quoted-string, provided that quotes are actually superfluous. Hence, the I-D could state that that's the canonical syntax, implying that DKIM signers (and verifiers) may get smoother if they convert that way before playing their magic. I recall unsuccessfully looking for such a statement. Scripts may opt for always putting quotes in order to avoid to find out whether they are actually needed. Would an informational I-D have the authority to tell them that they shouldn't do so? As a side note, quotes around HTML attributes tend to become always mandatory. > You can sometimes avoid or at least defer this by avoiding > unnecessary rewriting; unfortunately people always seem to come up > with more reasons for doing it. Yes, when they came out they looked as smart enhancements :-/ >> It may be >> helpful to encourage tool developers to stick to the original choice >> of token / quoted-string in MIME parameters (format="flowed" vs. >> format=flowed see http://tools.ietf.org/html/rfc2045#section-5.1 ) >> as well as keeping the original boundaries, if at all possible. > > IMO both of these are really bad suggestions. The first assumes that all agents > tolerate superfluous syntax and some actually require it; my experience has > been exactly the reverse. > > The second effectively either mandates forced encoding to base64 of all parts > or multi-pass processing to implement. The former often causes more problems > than it solves, the latter is a both a PITA to implement as well as being more > error-prone. > > Ned From rjsparks@nostrum.com Mon Mar 5 14:05:42 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3BEA21F8889 for ; Mon, 5 Mar 2012 14:05:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.393 X-Spam-Level: X-Spam-Status: No, score=-102.393 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nLsGFMcKvofv for ; Mon, 5 Mar 2012 14:05:42 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8F6AA21F8849 for ; Mon, 5 Mar 2012 14:05:39 -0800 (PST) Received: from dn3-177.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q25M5QQP052835 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 5 Mar 2012 16:05:27 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-ID: <4F5538AF.7010509@nostrum.com> Date: Mon, 05 Mar 2012 16:05:35 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= References: <1DE839B2-11F0-4DBF-9C3A-4CB1073B91A9@gmx.net> <4F1DE84A.9000600@nostrum.com> <4F456465.6010509@stpeter.im> <4F461734.4050306@it.aoyama.ac.jp> In-Reply-To: <4F461734.4050306@it.aoyama.ac.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: ecrit@ietf.org, "apps-discuss@ietf.org" , hgs+ecrit@cs.columbia.edu, mlinsner@cisco.com Subject: Re: [apps-discuss] review of draft-ietf-ecrit-lost-sync-12 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 05 Mar 2012 22:05:42 -0000 There's an aspect of this document that I want to make sure folks aren't missing. The things lostsync1 are adding are not things that something that speaks lost will every say. It's not an iteration of the lost vocabulary in that sense. It is something spoken by things that talk about lost speakers. This is not an extension of Lost. It is a different protocol that replicates the data used to answer Lost queries. It reuses the format that Lost uses when talking about that data. Does that make a difference in whether a new namespace is appropriate? (No is an OK answer - I don't have a strong opinion, but my instinct says that the separate namespace is likely to introduce fewer problems because of a bad assumption an implementer could make if the values were in the same namespace). RjS On 2/23/12 4:38 AM, "Martin J. Dürst" wrote: > Hello Peter, others, > > On 2012/02/23 6:55, Peter Saint-Andre wrote: >> Robert Sparks asked me to think about the namespaces issue... >> >>> -------- Original Message -------- Subject: Re: review of >>> draft-ietf-ecrit-lost-sync-12 Date: Fri, 13 Jan 2012 11:17:10 +0200 >>> From: Hannes Tschofenig To: >>> "Martin J. >>> Dürst" CC: Hannes Tschofenig >>> , Henning Schulzrinne >>> , Marc Linsner, >>> Robert Sparks, "apps-review@ietf.org" >>> , ecrit@ietf.org >>> >>> >>>> From Martin: >>> >>>> Namespaces: It is overkill to define new namespaces for each spec. >>>> It's a well-known secret in the XML community that it's easily >>>> possible to add a number of new elements to an existing namespace. >>>> This would be very appropriate in this case, because the number of >>>> reused elements and attributes is quite large, and the number of >>>> new elements is low. This would simplify most of the examples. >>> >>> I guess you refer to the namespace registration in the IANA >>> consideration section, namely urn:ietf:params:xml:ns:lostsync1 >>> >>> In the RAI area we have (to my knowledge) always created new >>> namespaces for new schemas. But I am pleased to hear that this is not >>> needed. >>> >>> Could you explain what we should be doing instead? > > Rather than define a new namespace lostsync1, just add the few > elements you defined anew to the lost1 namespace. It will make the > format simpler, and it won't hurt. > >> I don't see a problem with defining a new namespace for each iteration >> of an XML format (lostsync1, lostsync2, etc.), > > There's no 'problem' with defining a separate namespace for each > element. Correct software should still work. But it's not really > necessary, it's tedious for human users and just overkill. > >> because I don't think >> there's a general case here -- backward compatibility can depend on the >> community of interest. One community might be doing strict schema >> checking, so that any new elements or attributes would be problematic. >> By contrast, another community might be more lax in its processing >> because they specify that applications must ignore unknown elements and >> attributes, even those qualified by an existing namespace. > > Validation is largely independent of namespaces. There are some > problems with validating documents with more than one namespace, > depending on the technology (I'd have to look up the details), but > there are NO issues, with any of the validating technologies around > (DTDs, XML Schema, Relaxing, Schematron), when having only one > namespace and validating against subsets thereof. > > W3C technologies regularly do that (XHTML and SVG are the examples I > know best). Way, way back there was a heated discussion in the XML > community about whether a new namespace would make sense for a new > version of XHTML, and this was strongly and utterly rejected. The way > it was put most prominently was "a

is a

is a

". > > Validation is not only different for versions, but as you have > explained also for various other purposes. Some applications may use > validation to introduce further restrictions (e.g. for security > reasons in certain places), and so on. > > A new namespace for a new version only make sense if the old and the > new version are something completely different, with essentially no > common elements and no documents that would be acceptable in both > versions. For other cases, using separate namespaces just increases > clutter without contributing anything. > > The same is the case here. The proposed "lostsync1" namespace doesn't > contain many elements, and is only useful together with the "lost1" > namespace. That's of course unless the people in charge of the LOST > protocol and the people who came up with LOSTSYNC totally distrust > each other, but I was just assuming that's not the case :-). > > Regards, Martin. From rjsparks@nostrum.com Mon Mar 5 14:15:02 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83EB021F87D3; Mon, 5 Mar 2012 14:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.39 X-Spam-Level: X-Spam-Status: No, score=-102.39 tagged_above=-999 required=5 tests=[AWL=-0.090, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S7tmro8avpjg; Mon, 5 Mar 2012 14:15:01 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5B17721F844F; Mon, 5 Mar 2012 14:14:59 -0800 (PST) Received: from dn3-177.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q25MEppd054150 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 5 Mar 2012 16:14:52 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-ID: <4F553AE5.9060602@nostrum.com> Date: Mon, 05 Mar 2012 16:15:01 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= References: <1DE839B2-11F0-4DBF-9C3A-4CB1073B91A9@gmx.net> <4F1DE84A.9000600@nostrum.com> <4F456465.6010509@stpeter.im> <4F461734.4050306@it.aoyama.ac.jp> <4F5538AF.7010509@nostrum.com> In-Reply-To: <4F5538AF.7010509@nostrum.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: hgs+ecrit@cs.columbia.edu, ecrit@ietf.org, "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [Ecrit] review of draft-ietf-ecrit-lost-sync-12 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 05 Mar 2012 22:15:02 -0000 (One typo correction inline) On 3/5/12 4:05 PM, Robert Sparks wrote: > There's an aspect of this document that I want to make sure folks > aren't missing. > > The things lostsync1 are adding are not things that something that > speaks lost will every say. s/every/ever/ > > It's not an iteration of the lost vocabulary in that sense. > > It is something spoken by things that talk about lost speakers. > > This is not an extension of Lost. It is a different protocol that > replicates the data used to > answer Lost queries. It reuses the format that Lost uses when talking > about that data. > > Does that make a difference in whether a new namespace is appropriate? > > (No is an OK answer - I don't have a strong opinion, but my instinct > says that the separate > namespace is likely to introduce fewer problems because of a bad > assumption an implementer > could make if the values were in the same namespace). > > RjS > > > On 2/23/12 4:38 AM, "Martin J. Dürst" wrote: >> Hello Peter, others, >> >> On 2012/02/23 6:55, Peter Saint-Andre wrote: >>> Robert Sparks asked me to think about the namespaces issue... >>> >>>> -------- Original Message -------- Subject: Re: review of >>>> draft-ietf-ecrit-lost-sync-12 Date: Fri, 13 Jan 2012 11:17:10 >>>> +0200 >>>> From: Hannes Tschofenig To: >>>> "Martin J. >>>> Dürst" CC: Hannes Tschofenig >>>> , Henning Schulzrinne >>>> , Marc Linsner, >>>> Robert Sparks, "apps-review@ietf.org" >>>> , ecrit@ietf.org >>>> >>>> >>>>> From Martin: >>>> >>>>> Namespaces: It is overkill to define new namespaces for each spec. >>>>> It's a well-known secret in the XML community that it's easily >>>>> possible to add a number of new elements to an existing namespace. >>>>> This would be very appropriate in this case, because the number of >>>>> reused elements and attributes is quite large, and the number of >>>>> new elements is low. This would simplify most of the examples. >>>> >>>> I guess you refer to the namespace registration in the IANA >>>> consideration section, namely urn:ietf:params:xml:ns:lostsync1 >>>> >>>> In the RAI area we have (to my knowledge) always created new >>>> namespaces for new schemas. But I am pleased to hear that this is not >>>> needed. >>>> >>>> Could you explain what we should be doing instead? >> >> Rather than define a new namespace lostsync1, just add the few >> elements you defined anew to the lost1 namespace. It will make the >> format simpler, and it won't hurt. >> >>> I don't see a problem with defining a new namespace for each iteration >>> of an XML format (lostsync1, lostsync2, etc.), >> >> There's no 'problem' with defining a separate namespace for each >> element. Correct software should still work. But it's not really >> necessary, it's tedious for human users and just overkill. >> >>> because I don't think >>> there's a general case here -- backward compatibility can depend on the >>> community of interest. One community might be doing strict schema >>> checking, so that any new elements or attributes would be problematic. >>> By contrast, another community might be more lax in its processing >>> because they specify that applications must ignore unknown elements and >>> attributes, even those qualified by an existing namespace. >> >> Validation is largely independent of namespaces. There are some >> problems with validating documents with more than one namespace, >> depending on the technology (I'd have to look up the details), but >> there are NO issues, with any of the validating technologies around >> (DTDs, XML Schema, Relaxing, Schematron), when having only one >> namespace and validating against subsets thereof. >> >> W3C technologies regularly do that (XHTML and SVG are the examples I >> know best). Way, way back there was a heated discussion in the XML >> community about whether a new namespace would make sense for a new >> version of XHTML, and this was strongly and utterly rejected. The way >> it was put most prominently was "a

is a

is a

". >> >> Validation is not only different for versions, but as you have >> explained also for various other purposes. Some applications may use >> validation to introduce further restrictions (e.g. for security >> reasons in certain places), and so on. >> >> A new namespace for a new version only make sense if the old and the >> new version are something completely different, with essentially no >> common elements and no documents that would be acceptable in both >> versions. For other cases, using separate namespaces just increases >> clutter without contributing anything. >> >> The same is the case here. The proposed "lostsync1" namespace doesn't >> contain many elements, and is only useful together with the "lost1" >> namespace. That's of course unless the people in charge of the LOST >> protocol and the people who came up with LOSTSYNC totally distrust >> each other, but I was just assuming that's not the case :-). >> >> Regards, Martin. > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From stpeter@stpeter.im Mon Mar 5 14:23:01 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4417021E8049; Mon, 5 Mar 2012 14:23:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.776 X-Spam-Level: X-Spam-Status: No, score=-102.776 tagged_above=-999 required=5 tests=[AWL=-0.177, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SbIEgobQAmyo; Mon, 5 Mar 2012 14:23:00 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 4F58C21E803D; Mon, 5 Mar 2012 14:23:00 -0800 (PST) Received: from squire.local (unknown [64.101.72.114]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id AA2F140058; Mon, 5 Mar 2012 15:34:53 -0700 (MST) Message-ID: <4F553CC2.8090801@stpeter.im> Date: Mon, 05 Mar 2012 15:22:58 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Robert Sparks References: <1DE839B2-11F0-4DBF-9C3A-4CB1073B91A9@gmx.net> <4F1DE84A.9000600@nostrum.com> <4F456465.6010509@stpeter.im> <4F461734.4050306@it.aoyama.ac.jp> <4F5538AF.7010509@nostrum.com> In-Reply-To: <4F5538AF.7010509@nostrum.com> X-Enigmail-Version: 1.3.5 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org, "apps-discuss@ietf.org" , hgs+ecrit@cs.columbia.edu, mlinsner@cisco.com Subject: Re: [apps-discuss] review of draft-ietf-ecrit-lost-sync-12 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 05 Mar 2012 22:23:01 -0000 On 3/5/12 3:05 PM, Robert Sparks wrote: > There's an aspect of this document that I want to make sure folks aren't > missing. > > The things lostsync1 are adding are not things that something that > speaks lost will every say. > > It's not an iteration of the lost vocabulary in that sense. > > It is something spoken by things that talk about lost speakers. > > This is not an extension of Lost. It is a different protocol that > replicates the data used to > answer Lost queries. It reuses the format that Lost uses when talking > about that data. > > Does that make a difference in whether a new namespace is appropriate? My quick response is that I think it does make a difference, but I will ponder it further and let you know if my thinking changes. :) Peter -- Peter Saint-Andre https://stpeter.im/ From yaojk@cnnic.cn Mon Mar 5 17:00:54 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18DF521E8079 for ; Mon, 5 Mar 2012 17:00:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.736 X-Spam-Level: X-Spam-Status: No, score=-98.736 tagged_above=-999 required=5 tests=[AWL=-1.090, BAYES_50=0.001, J_CHICKENPOX_32=0.6, MIME_BASE64_TEXT=1.753, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RA0NgQ2P6UJm for ; Mon, 5 Mar 2012 17:00:52 -0800 (PST) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 0A2CF21E805C for ; Mon, 5 Mar 2012 17:00:51 -0800 (PST) X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Tue, 06 Mar 2012 09:00:42 +0800 Message-ID: <4A10020DB6464A0BBA535BF75D21A9D9@LENOVO47E041CF> From: "Jiankang YAO" To: References: <503575970.11554@cnnic.cn> Date: Tue, 6 Mar 2012 09:00:43 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: appsawg-chairs@tools.ietf.org Subject: [apps-discuss] WGLC: draft-ietf-appsawg-about-uri-scheme-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 06 Mar 2012 01:00:54 -0000 RGVhciBjb2xsZWFndWVzLA0KDQpUaGlzIG1lc3NhZ2Ugc3RhcnRzIGEgdHdvLXdlZWsgV0dMQyBv biB0aGUgZHJhZnQNCmRyYWZ0LWlldGYtYXBwc2F3Zy1hYm91dC11cmktc2NoZW1lLTAzLnR4dC4g DQoNClBsZWFzZSBoZWxwIHRvIHJldmlldyB0aGlzIGRyYWZ0LiAgSWYgeW91IHN1cHBvcnQgcHVi bGljYXRpb24sIHBsZWFzZSBzdGF0ZSBhcw0KbXVjaCBvbiB0aGUgbGlzdC4gIElmIHlvdSBhcmUg b3Bwb3NlZCB0byBwdWJsaWNhdGlvbiwgcGxlYXNlIHN0YXRlDQp0aGF0IG9uIHRoZSBsaXN0IGFz IHdlbGwuICBJdCBpcyBtb3JlL29ubHkgaGVscGZ1bCBpZiB5b3UgZ2l2ZSB5b3VyIHJlYXNvbnMg Zm9yDQp5b3VyIHBvc2l0aW9uIGFzIHBhcnQgb2YgeW91ciBzdGF0ZW1lbnQuICANCg0KUGxzIHNl bmQgeW91ciBjb21tZW50cyB0byBhcHBzLWRpc2N1c3NAaWV0Zi5vcmcgb3IgYXBwc2F3Zy1jaGFp cnNAdG9vbHMuaWV0Zi5vcmcgb3IgZWRpdG9ycy4gDQoNClRoZSBXR0xDIHdpbGwgZW5kIG9uIE1h cmNoIDIwLCAyMDEyIGF0IDE6MDAgVVRDLg0KDQoNCg0KQmVzdCByZWdhcmRzLA0KSmlhbmthbmcg WWFvKGFzIGEgY28tY2hhaXIgb2YgQVBQU0FXRykNCg0KDQoNCg== From likepeng@huawei.com Mon Mar 5 17:02:38 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A16B621E8065 for ; Mon, 5 Mar 2012 17:02:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.551 X-Spam-Level: X-Spam-Status: No, score=-5.551 tagged_above=-999 required=5 tests=[AWL=1.048, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ltyo-MsmOpd for ; Mon, 5 Mar 2012 17:02:38 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 066BF21E805C for ; Mon, 5 Mar 2012 17:02:38 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0F00IAAUWD2U@szxga04-in.huawei.com> for apps-discuss@ietf.org; Tue, 06 Mar 2012 09:02:37 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0F002OFUWCFD@szxga04-in.huawei.com> for apps-discuss@ietf.org; Tue, 06 Mar 2012 09:02:37 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHP39390; Tue, 06 Mar 2012 09:02:36 +0800 Received: from SZXEML440-HUB.china.huawei.com (10.72.61.75) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 06 Mar 2012 09:02:32 +0800 Received: from SZXEML525-MBX.china.huawei.com ([169.254.1.201]) by SZXEML440-HUB.china.huawei.com ([10.72.61.75]) with mapi id 14.01.0323.003; Tue, 06 Mar 2012 09:02:32 +0800 Date: Tue, 06 Mar 2012 01:02:32 +0000 From: Likepeng X-Originating-IP: [10.70.109.64] To: "apps-discuss@ietf.org" Message-id: <34966E97BE8AD64EAE9D3D6E4DEE36F20181F2A3@szxeml525-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: New Version Notification for draft-li-appsawg-virtualized-application-protocol-00.txt Thread-index: AQHM+zTPqNBdKKyju0Cwqhgz+XRkbA== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Cc: Barry Leiba Subject: [apps-discuss] New Version Notification for draft-li-appsawg-virtualized-application-protocol-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 06 Mar 2012 01:02:38 -0000 SSB1cGxvYWRlZCBvbmUgZHJhZnQgdG8gcHJvcG9zZSBhIG5ldyB3b3JrIGluIElFVEY6DQpodHRw Oi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWxpLWFwcHNhd2ctdmlydHVhbGl6ZWQtYXBwbGljYXRp b24tcHJvdG9jb2wtMDAudHh0DQoNCkkgaG9wZSB0byBnZXQgY29tbWVudHMvZmVlZGJhY2tzIGZy b20geW91Lg0KDQpBbmQgYWxzbyBJIGhvcGUgY2hhaXJzIGNhbiBhbGxvY2F0ZSBhIHRpbWUgc2xv dCB0byBtZSB0byBpbnRyb2R1Y2UgdGhhdCBpbiBQYXJpcy4NCg0KVGhhbmtzLA0KDQpLaW5kIFJl Z2FyZHMNCktlcGVuZw0KLS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0K5Y+R5Lu25Lq6OiBpbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0K5Y+R 6YCB5pe26Ze0OiAyMDEy5bm0M+aciDTml6UgMTI6MDYNCuaUtuS7tuS6ujogTGlrZXBlbmcNCuS4 u+mimDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1saS1hcHBzYXdnLXZpcnR1 YWxpemVkLWFwcGxpY2F0aW9uLXByb3RvY29sLTAwLnR4dA0KDQpBIG5ldyB2ZXJzaW9uIG9mIEkt RCwgZHJhZnQtbGktYXBwc2F3Zy12aXJ0dWFsaXplZC1hcHBsaWNhdGlvbi1wcm90b2NvbC0wMC50 eHQgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBLZXBlbmcgTGkgYW5kIHBvc3Rl ZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZToJIGRyYWZ0LWxpLWFwcHNhd2ct dmlydHVhbGl6ZWQtYXBwbGljYXRpb24tcHJvdG9jb2wNClJldmlzaW9uOgkgMDANClRpdGxlOgkJ IFZpcnR1YWxpemVkIEFwcGxpY2F0aW9uIFByb3RvY29sDQpDcmVhdGlvbiBkYXRlOgkgMjAxMi0w My0wNA0KV0cgSUQ6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDgN Cg0KQWJzdHJhY3Q6DQogICBWaXJ0dWFsaXplZCBBcHBsaWNhdGlvbiBQcm90b2NvbCBhaW1zIHRv IHByb3ZpZGUgY2FwYWJpbGl0aWVzIHRvDQogICBlbmFibGUgdGhlIHVzZXIgZGV2aWNlIHRvIHJl bW90ZWx5IGNvbnN1bWUgdmFyaW91cyBhcHBsaWNhdGlvbnMgb24NCiAgIHRoZSBuZXR3b3JrLiAg VGhpcyBpbnZvbHZlcyBoYXZpbmcgYWxsIHRoZSB2aXJ0dWFsaXplZCBhcHBsaWNhdGlvbnMNCiAg IGhvc3RlZCBpbiB0aGUgbmV0d29yayBhbmQgZnJvbSB0aGVyZSBwcm92aWRpbmcgdGhlbSB0byB0 aGUgdXNlcnMNCiAgIHVzaW5nIGNsb3VkIGNvbXB1dGluZyB0ZWNobm9sb2dpZXMgbGlrZSB2aXJ0 dWFsaXphdGlvbi4gIFRoaXMNCiAgIGRvY3VtZW50IGlzIGFuIG92ZXJ2aWV3IGRvY3VtZW50LCBp bmNsdWRpbmcgdXNlIGNhc2VzLCByZXF1aXJlbWVudHMsDQogICBhcmNoaXRlY3R1cmUgYW5kIHBv c3NpYmxlIHNvbHV0aW9ucy4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KVGhlIElFVEYgU2Vj cmV0YXJpYXQNCg== From ned.freed@mrochek.com Tue Mar 6 00:13:35 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB90E21E80AD for ; Tue, 6 Mar 2012 00:13:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IQ52pooKmKT6 for ; Tue, 6 Mar 2012 00:13:35 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id E5DA121E808C for ; Tue, 6 Mar 2012 00:13:34 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OCRXL1F4SG00409B@mauve.mrochek.com> for apps-discuss@ietf.org; Tue, 6 Mar 2012 00:13:31 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OCPMUVDUMO00ZUIL@mauve.mrochek.com>; Tue, 6 Mar 2012 00:13:26 -0800 (PST) Message-id: <01OCRXKYBLNA00ZUIL@mauve.mrochek.com> Date: Tue, 06 Mar 2012 00:04:14 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Mon, 05 Mar 2012 19:23:32 +0100" <4F5504A4.6010902@tana.it> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <9452079D1A51524AA5749AD23E00392806D278@exch-mbx901.corp.cloudmark.com> <2183832.0qjo89hoBY@scott-latitude-e6320> <4F549914.2020907@tana.it> <01OCQYO1P7T400ZUIL@mauve.mrochek.com> <4F5504A4.6010902@tana.it> To: Alessandro Vesely DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1331021618; bh=qRgsBpr6jINkGeVeFipX2xAYwb2K9cNKlPnFcMyX80E=; h=Cc:Message-id:Date:From:Subject:In-reply-to:MIME-version: Content-type:References:To; b=RL/zXgdI+jDeplbfbuORF4A3RfnpUBXJ9+yr671CpCR+K43OdSbvpkz0F4KyCBd3j LafQlphMiCD7cw60jyQQikWzTVY4GsZTeJX/X0bfKs7pN75C8kN66tBgYhRiHR76vE iE/oRIepX7/q8pLJoCcavSNyxBwZA/a6+g2NoGxA= Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Malformed mail guidance document (draft-ietf-appsawg-malformed-mail) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 06 Mar 2012 08:13:36 -0000 > On 05/Mar/12 16:25, Ned Freed wrote: > > > >> More non-malformation cases occur on MIME rewriting. > > > > It's more like malformations in the original message get exposed if it's > > rewritten for whatever reason. > Hm... MIME doesn't seem to say that either is better than the other. > Based on what you write below, I'd derive that token is better than > quoted-string, provided that quotes are actually superfluous. Hence, > the I-D could state that that's the canonical syntax, implying that > DKIM signers (and verifiers) may get smoother if they convert that way > before playing their magic. I'm unclear as to the relevance. If you're transforming MIME content in some way - and if you're not why are you bothering to mess around with the headers - the content will be altered and any DKIM signature is going to be invalidated no matter what you do to the quotes. > I recall unsuccessfully looking for such a statement. There's isn't one. MIME doesn't discuss canonical forms or what representations are "better". At the time we were much more concerned with getting a specification out the door than we were on spending what would have certainly been lots of time arguing about optimal representations. Nor, frankly, did we have operational experience on which to base such choices. It took 10 years at least to accumulate that, by which time it was far too late to even consider adding that to MIME. Remember that this was 20 years ago. PEM, the first signature scheme for email, was still under development. > Scripts may opt > for always putting quotes in order to avoid to find out whether they > are actually needed. Would an informational I-D have the authority to > tell them that they shouldn't do so? As a side note, quotes around > HTML attributes tend to become always mandatory. I don't see a problem with saying that, but a document that says that and that alone doesn't seem worth it to me. I'm also dubious that anything would change significantly because of making such a recommendation. Ned From yngve@opera.com Tue Mar 6 05:01:46 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB7521F884E for ; Tue, 6 Mar 2012 05:01:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.066 X-Spam-Level: X-Spam-Status: No, score=-7.066 tagged_above=-999 required=5 tests=[AWL=-0.467, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pzk7dV3UQgzm for ; Tue, 6 Mar 2012 05:01:45 -0800 (PST) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id 77BE021F885E for ; Tue, 6 Mar 2012 05:01:45 -0800 (PST) Received: from acorna.invalid.invalid (pat-tdc.opera.com [213.236.208.22]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q26D1eOj011560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 6 Mar 2012 13:01:43 GMT Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes References: <20120306124855.6011.1769.idtracker@ietfa.amsl.com> Date: Tue, 06 Mar 2012 14:01:50 +0100 To: "Apps Discuss" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve N. Pettersen (Developer Opera Software ASA)" Organization: Opera Software AS Message-ID: In-Reply-To: <20120306124855.6011.1769.idtracker@ietfa.amsl.com> User-Agent: Opera Mail/10.63 (Win32) Subject: [apps-discuss] Fwd: New Version Notification for draft-pettersen-subtld-structure-09.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 06 Mar 2012 13:01:46 -0000 FYI ------- Forwarded message ------- From: internet-drafts@ietf.org To: yngve@opera.com Cc: Subject: New Version Notification for draft-pettersen-subtld-structure-09.txt Date: Tue, 06 Mar 2012 13:48:55 +0100 A new version of I-D, draft-pettersen-subtld-structure-09.txt has been successfully submitted by Yngve N. Pettersen and posted to the IETF repository. Filename: draft-pettersen-subtld-structure Revision: 09 Title: The Public Suffix Structure file format and its use for Cookie domain validation Creation date: 2012-03-06 WG ID: Individual Submission Number of pages: 15 Abstract: This document defines the term "Public Suffix domain" as meaning a domain under which multiple parties that are unaffiliated with the owner of the Public Suffix domain may register subdomains. Examples of Public Suffix domains include "org", "co.uk", "k12.wa.us" and "uk.com". It also defines a file format that can be used to distribute information about such Public Suffix domains to relying parties. As an example, this information is then used to limit which domains an Internet service can set HTTP cookies for, strengthening the rules already defined by the cookie specification. This specification updates RFC 6265 [RFC6265] by defining the term "Public Suffix domain". The IETF Secretariat -- Sincerely, Yngve N. Pettersen ******************************************************************** Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 23 69 32 60 Fax: +47 23 69 24 01 ******************************************************************** From vesely@tana.it Tue Mar 6 07:12:38 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61EB321F889A for ; Tue, 6 Mar 2012 07:12:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.652 X-Spam-Level: X-Spam-Status: No, score=-4.652 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7S0M0OuPmhW4 for ; Tue, 6 Mar 2012 07:12:37 -0800 (PST) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 4E73021F87B3 for ; Tue, 6 Mar 2012 07:12:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1331046755; bh=AACCNc0fQNBJx5ioK4QGIA2qpqKCwHN2Ucyj+NsmaH8=; l=1570; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=boaLbqp99Ign7BT1GhHOkBGqRpfsV+5ARSW3tsdqM19MxgK6JxPwN5TlTnBPy8nzR z9lxGr9y3BXBEWq1/xrIARv6TIgmj3WrM6cc8A7pEoX4evgCLpK+SkIsu/Kassmxi9 0XXeg8jPfFggIosrnALAdrWir/bOugJc67lHzY6M= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Tue, 06 Mar 2012 16:12:35 +0100 id 00000000005DC045.000000004F562963.000064AB Message-ID: <4F562963.3000501@tana.it> Date: Tue, 06 Mar 2012 16:12:35 +0100 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <9452079D1A51524AA5749AD23E00392806D278@exch-mbx901.corp.cloudmark.com> <2183832.0qjo89hoBY@scott-latitude-e6320> <4F549914.2020907@tana.it> <01OCQYO1P7T400ZUIL@mauve.mrochek.com> <4F5504A4.6010902@tana.it> <01OCRXKYBLNA00ZUIL@mauve.mrochek.com> In-Reply-To: <01OCRXKYBLNA00ZUIL@mauve.mrochek.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] Malformed mail guidance document (draft-ietf-appsawg-malformed-mail) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 06 Mar 2012 15:12:38 -0000 On 06/Mar/12 09:04, Ned Freed wrote: > >> Hm... MIME doesn't seem to say that either is better than the >> other. Based on what you write below, I'd derive that token is >> better than quoted-string, provided that quotes are actually >> superfluous. Hence, the I-D could state that that's the >> canonical syntax, implying that DKIM signers (and verifiers) may >> get smoother if they convert that way before playing their >> magic. > > I'm unclear as to the relevance. If you're transforming MIME > content in some way - and if you're not why are you bothering to > mess around with the headers - the content will be altered and any > DKIM signature is going to be invalidated no matter what you do to > the quotes. Not necessarily. The message you replied to was sent to apps-discuss with Content-Type: text/plain; charset=us-ascii, but I received it from mail.ietf.org with Content-Type: text/plain; charset="us-ascii". Thus, the message was rewritten, and its signature would have been broken if the Content-Type field had been signed (which should be the behavior of choice, according to RFCs 6376-6377.) As for the relevance, I admit it's a statistically irrelevant corner case, which looks more like a DKIM shortcoming than a MIME fault. > I don't see a problem with saying that, but a document that says > that and that alone doesn't seem worth it to me. I'm also dubious > that anything would change significantly because of making such a > recommendation. Yet, the less MIME rewriting, the more DKIM deployment is possible. From ted.ietf@gmail.com Tue Mar 6 18:06:45 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5CF921E8049; Tue, 6 Mar 2012 18:06:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.378 X-Spam-Level: X-Spam-Status: No, score=-3.378 tagged_above=-999 required=5 tests=[AWL=-0.379, BAYES_00=-2.599, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aZWyUybr65Jz; Tue, 6 Mar 2012 18:06:45 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id D7C4121E8047; Tue, 6 Mar 2012 18:06:44 -0800 (PST) Received: by vbbez10 with SMTP id ez10so5790380vbb.31 for ; Tue, 06 Mar 2012 18:06:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=NUTYCcra25RRJJE+ZqwBpw3e2qTTClxtypjNg8G/wf8=; b=PW0QLjU22q5GUpcXvjH01NKVQmFRrGcS2LzBaV9Ze3z+K6Azlant5buYVNdQG+EHCV 8inyhVLfSEXl+AMbCS77TrpR+mOOqdl3L+bjDRGS2IzjCTZ2zlcWe3J+jHHoLoWIHYBZ YsdrZvHq4OE7iow7hjgNJ4pLZj44+FCjqdCsfw7uNBsumpuzWfxTjSnpCNAnjLZndPxq 8iOMYJFDL9rul0+UYppb+iT/OKH08nKmkxj2dIzaDEGv4rFz95FYWtyN6lCT6ic55hvB byBwyhJduGodPuC+WvEjZpglVSCpxJeP0VyDFKCPxk6xh5orZXD8WdJHcX0Bh7cB6q5h 1bqw== MIME-Version: 1.0 Received: by 10.52.240.161 with SMTP id wb1mr492208vdc.20.1331086004402; Tue, 06 Mar 2012 18:06:44 -0800 (PST) Received: by 10.52.115.66 with HTTP; Tue, 6 Mar 2012 18:06:44 -0800 (PST) Date: Tue, 6 Mar 2012 18:06:44 -0800 Message-ID: From: Ted Hardie To: apps-discuss@ietf.org, draft-ietf-intarea-ipv4-id-update.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: IESG Subject: [apps-discuss] APPS directorate review of ietf-intarea-ipv4-id-update X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 07 Mar 2012 02:06:45 -0000 I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-intarea-ipv4-id-update-04 Reviewer:Ted Hardie Review Date:March 6, 2012 Summary: There are some areas which would benefit from clarification, but no major issues. Major Issues: [list any major issues such as security concerns, preferably by section number] No Major issues. Minor Issues: [list any minor issues such as text that is unclear or confusing, preferably by section number] In section 6, the inclusion of the mathematical expression for which datagrams were atomic vs. non-atomic did not seem to add anything to the clarity of the surrounding text. By introducing several abbreviations and reviewing the logical operators, it seemed to complicate what appeared to be a very clear statement: Atomic datagrams are those which are not fragmented now and for which later fragmentation is inhibited; non-atomic datagrams are those that either are fragmented or which may later be fragmented. In section 6.1, the document states: Duplicate suppression was only suggested [RFC1122], and no impacts of IPv4 ID reuse have been noted. Deduplication is often listed as a feature of "wan accelerator" devices. It might be useful to include these devices in the list of middleboxes in section 9. Advice to update the behaviors of those devices to ignore IPv4 IDs on atomic datagrams seems potentially useful. In section 10, the document states: When compression assumes a changing ID as a default, having a non- changing ID can make compression less efficient (see footnote 21 of [RFC1144] or cRTP [RFC2508]). The text of footnote 21 is: Note that the test here is against one, not zero. The packet ID is typically incremented by one for each packet sent so a change of zero is very unlikely. A change of one is likely: It occurs during any period when the originating system has activity on only one connection. I was expecting the footnote to contain data that referred to compression efficiency; perhaps some additional context is needed? Nits: [list editorial issues such as typographical errors, preferably by section number] From touch@isi.edu Wed Mar 7 07:41:27 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC5F821E808A; Wed, 7 Mar 2012 07:41:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.736 X-Spam-Level: X-Spam-Status: No, score=-104.736 tagged_above=-999 required=5 tests=[AWL=1.263, BAYES_00=-2.599, J_CHICKENPOX_83=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h9UntN7YXNro; Wed, 7 Mar 2012 07:41:27 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 47DB921F8623; Wed, 7 Mar 2012 07:41:07 -0800 (PST) Received: from [192.168.1.96] (pool-71-105-89-105.lsanca.dsl-w.verizon.net [71.105.89.105]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q27FePKN028453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 7 Mar 2012 07:40:34 -0800 (PST) Message-ID: <4F578169.7040408@isi.edu> Date: Wed, 07 Mar 2012 07:40:25 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1 MIME-Version: 1.0 To: Ted Hardie References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: draft-ietf-intarea-ipv4-id-update.all@tools.ietf.org, IESG , apps-discuss@ietf.org Subject: Re: [apps-discuss] APPS directorate review of ietf-intarea-ipv4-id-update X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 07 Mar 2012 15:41:28 -0000 Hi, Ted, Thank you for your comments. Some clarifications below. Joe On 3/6/2012 6:06 PM, Ted Hardie wrote: > I have been selected as the Applications Area Directorate reviewer for > this draft (for background on appsdir, please see > http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). > > Please resolve these comments along with any other Last Call comments > you may receive. Please wait for direction from your document shepherd > or AD before posting a new version of the draft. > > Document: draft-ietf-intarea-ipv4-id-update-04 > Reviewer:Ted Hardie > Review Date:March 6, 2012 > > > Summary: > > There are some areas which would benefit from clarification, but no > major issues. > > Major Issues: [list any major issues such as security concerns, > preferably by section number] > > No Major issues. > > Minor Issues: [list any minor issues such as text that is unclear or > confusing, preferably by section number] > > In section 6, the inclusion of the mathematical expression for which > datagrams were atomic vs. non-atomic did not seem to add anything to > the clarity of the surrounding text. By introducing several > abbreviations and reviewing the logical operators, it seemed to > complicate what appeared to be a very clear statement: Atomic > datagrams are those which are not fragmented now and for which later > fragmentation is inhibited; non-atomic datagrams are those that either > are fragmented or which may later be fragmented. The equations are intended to be pseudocode, to define atomicity in terms of specific tests on IP header fields. This helps clarify the interpretation of the English definition to help coders. We can clarify that by replacing "mathematical expression" with "pseudocode". Would that clarify the utility of the expressions? Should we also explain the rationale for including them in a single sentence? > In section 6.1, the document states: > > Duplicate suppression was only suggested [RFC1122], and no impacts of IPv4 ID > reuse have been noted. > > Deduplication is often listed as a feature of "wan accelerator" > devices. It might be useful to include these > devices in the list of middleboxes in section 9. Advice to update the > behaviors of those devices to ignore > IPv4 IDs on atomic datagrams seems potentially useful. Yes, thanks for pointing that out. > In section 10, the document states: > > When compression assumes a changing ID as a default, having a non- > changing ID can make compression less efficient (see footnote 21 of > [RFC1144] or > cRTP [RFC2508]). > > The text of footnote 21 is: > > Note that the test here is against one, not zero. The packet ID is > typically incremented by one for each packet sent so a change of zero is > very unlikely. A change of one is likely: It occurs during any period > when the originating system has activity on only one connection. > > I was expecting the footnote to contain data that referred to > compression efficiency; > perhaps some additional context is needed? We could change that to "less efficient. Such non-changing IDs have been described in various RFCs (e.g., footnote 21 of [RFC1144 and cRTP [RFC2508])." Would that be more clear? > Nits: [list editorial issues such as typographical errors, preferably > by section number] From alberto@it.uc3m.es Tue Mar 6 09:06:51 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C33921F8714; Tue, 6 Mar 2012 09:06:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.107 X-Spam-Level: X-Spam-Status: No, score=-6.107 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lBllJftbPFNq; Tue, 6 Mar 2012 09:06:44 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id 7DE2821F8763; Tue, 6 Mar 2012 09:06:39 -0800 (PST) X-uc3m-safe: yes Received: from BOMBO (unknown [163.117.139.62]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 4155275ABF1; Tue, 6 Mar 2012 18:06:38 +0100 (CET) From: =?iso-8859-1?Q?Alberto_Garc=EDa?= To: "'Carsten Bormann'" , "'IETF Apps Discuss'" , , References: In-Reply-To: Date: Tue, 6 Mar 2012 18:06:38 +0100 Message-ID: <00ac01ccfbbb$7e81e580$7b85b080$@it.uc3m.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00AD_01CCFBC3.E04B0870" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQE8Z7u/F1paD1p9UUiMSbxgp70Ic5d4Qc7Q Content-Language: es X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.8.0.1017-18758.000 X-Mailman-Approved-At: Wed, 07 Mar 2012 08:12:50 -0800 Cc: 'The IESG' Subject: Re: [apps-discuss] [shim6] APPSDIR review of draft-garcia-shim6-applicability-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 06 Mar 2012 17:06:51 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00AD_01CCFBC3.E04B0870 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Carsten, Thank you very much for your review =20 | -----Mensaje original----- | De: shim6-bounces@ietf.org [mailto:shim6-bounces@ietf.org] En nombre | de Carsten Bormann | Enviado el: mi=E9rcoles, 29 de febrero de 2012 23:13 | Para: IETF Apps Discuss; draft-garcia-shim6-applicability.all@tools.ietf.org; | shim6@ietf.org | CC: The IESG | Asunto: [shim6] APPSDIR review of draft-garcia-shim6-applicability-03 | =20 | I have been selected as the Applications Area Directorate reviewer = for this | draft (for background on APPSDIR, please see | http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate= ). | =20 | Please resolve these comments along with any other Last Call comments | you may receive. Please wait for direction from your document = shepherd or | AD before posting a new version of the draft. | =20 | Gruesse, Carsten | --------------------------------- | =20 | Document: draft-garcia-shim6-applicability-03.txt | Title: Applicability Statement for the Level 3 Multihoming Shim = Protocol | (Shim6) | Reviewer: Carsten Bormann | IETF Last Call Date: 2012-02-15 | Review Date: 2012-02-29 | =20 | ** Summary: This draft is ready for publication as an Informational | RFC with small changes, but maybe requires a better title. | =20 | Note: I reviewed this with the expectation that the intended audience will | read this *before* looking at RFC5533=965535 in detail. | =20 | ** Major Issues: | =20 | General: | =20 | The document provides useful discussion of considerations around the | usage of Shim6. At the end, it leaves the reader confused: What *is* = the | applicability/area of application of Shim6? =20 =20 I assume this comment relates with the expectations created by the = title, so I comment below. =20 | Who should decide whether | Shim6 is activated for a specific connection? (There is an API in = RFC 6316, | but clearly that is meant for advanced applications.)=20 =20 This issue was partially addressed in the 'Short-Lived Communications' subsection. However, I think the text would improve by placing this in a more prominent place, and by making a clearer statement. I have appended = the following text just to the end of the '2. Deployment Scenarios' section: =20 =93To allow nodes to benefit from the capabilities provided by Shim6 (discussed in Section 5) such as fault tolerance, nodes should be configured to initiate a Shim6 session with any peer node if they have multiple locators to use. Note that this configuration can be performed transparently to the applications, in the sense that applications do not need to be aware of the Shim6 functionality provided by the node; iin particular, nodes are not forced to use the Shim6 API [RFC6316] to benefit from Shim6. The Shim6 session should be created after the two nodes have been communicating for some time, i.e. using the deferred context establishment facility provided by Shim6. Otherwise, the cost of the Shim6 4-way handshake used for establishing the session may exceed the benefits provided for short- lived communications (see Section 5.1.2). More advanced node configuration may involved configuring different delays for initiating the session for different applications, for example, based on a per-port configuration. Nodes being able to use a single locator for the communication should not initiate the creation of a Shim6 context, but should participate if other node initiates it. Note that Shim6-aware applications can overrid this behavior by means of the Shim6 API [RFC6316].=94 =20 By the way, I've also merged the 'Short-lived' and 'Long-lived' = sections, into a single '5.1.2. Short-lived and long-lived communications', which = is referred in the previous paragraph. Does this address your concern? =20 | While the document | successfully relates Shim6 to SCTP and HIP, what about other = approaches to | multi-addressing? =20 In general, all mechanisms which handle different addresses at a higher level than the network-layer may experience unwanted interactions with Shim6. This applies to MPTCP, in addition to SCTP. Although there was a generic comment regarding to this at the end of the SCTP section, I have make this more explicit for MPTCP, by changing the SCTP section to refer = to both SCTP and MPTCP. =20 =937.3. Shim6, SCTP and MPTCP =20 Both the SCTP [RFC4960] and MPTCP [RFC6182] protocols provide a reliable, stream-based communications channel between two hosts which provides a superset of the capabilities of TCP. One notable feature of these two protocols is that they allow the exchange of endpoint addresses between hosts, in order to recover from the failure of a particular endpoint pair, or to benefit from multipath communication in the MPTCP case, in a manner which is conceptually similar to locator selection in Shim6. =20 SCTP and MPTCP are transport-layer protocols, higher in the protocol stack than Shim6, and hence there is no fundamental incompatibility which would prevent a Shim6-capable host from communicating using SCTP or MPTCP. =20 However, since either SCTP or MPTCP, and Shim6 aim to exchange addressing information between hosts in order to meet the same generic goal, it is possible that their simultaneous use might result in unexpected behavior, e.g. lead to race conditions. =20 The capabilities of these transport protocols with respect to path maintenance of a reliable, connection-oriented stream protocol are more extensive than the more general layer-3 locator agility provided by Shim6. Therefore, it is recommended that Shim6 is not used for SCTP or MPTCP sessions, and that path maintenance is provided solely by SCTP or MPTCP. There are at least two ways to enforce this behavior. One option would be to make the stack, and in particular the Shim6 sublayer, aware of the use of SCTP or MPTCP and in this case refrain from creating a Shim6 context. The other option is that the upper transport layer, informs using a Shim6-capable API like the one proposed in [RFC6316] that no Shim6 context must be created for this particular communication. =20 In general, the issues described here may also arise for protocols which handle different addresses for two communicating nodes at a higher level than the network-layer to improve reliability, performance, congestion control, etc.=94 =20 =20 | When is happy-eyeballs enough? =20 Umm. In my opinion, the happy-eyeballs algorithm is not related to = Shim6. Happy-eyeballs deals with dual-stack hosts connecting to servers. As discussed in section =913.1 Protocol Version (IPv4 vs. IPv6)=92, Shim6 = is just defined for IPv6. =20 =20 | When should MPTCP | be used? =20 Now this is included in the new SCTP/MPTCP section commented before. =20 | (The introduction to 7 then goes ahead and destroys any | remaining hope that this document provides the answers -- maybe this | should be split into "Open Issues" and the solid information about = where | Shim6 is not needed.) | =20 | The document may have started out as an applicability statement half = a | decade ago, but maybe renaming it to "Considerations on the = Application of | Shim6" provides a more appropriate title now. | =20 | Again, this is meant as a comment on the expectations raised by the = title | and abstract, not as an attempt to belittle the usefulness of the document's | content. | =20 =20 I think I see your point. For me its ok to change the title to =91Considerations on the Application of the Level 3 Multihoming Shim = Protocol (Shim6)=92 I=92ve also changed the abstract to a less ambitious =93This document discusses some considerations on the applicability of = the Shim6 IPv6 protocol and associated support protocols and mechanisms to provide site multihoming capabilities in IPv6.=94 =20 Regarding to splitting section 7 into something like =91open issues=92, = and =91do not mix=92, this is not evident to me. The =91do not mix=92 is comprised = of just two subsections (=91SCTP/MPTCP=92 and =91HIP=92). Besides, the =91open = issues=92 part is very heterogeneous: there are things we are pretty confident that should work (e.g. =91SEND and Shim6=92), complex interactions (eg. NATs will = work as long as there are no changes in the locators, which leads to a = functionality which is not worse than current IPv6, although not as good as Shim6 = could provide=85), things that may work but they should be tested (MIP, NEMO, firewalls)=85 I prefer the current approach in which each =91Shim6 and other=92 = combination is considered separately, without giving further structure to the section (structure that is difficult for me to find). =20 | ** Minor Issues: | =20 | (1) | I'm not so fond of the DHCP speculation in 3.3. An applicability statement | should talk about what is, not what could be. As of today, DHCP is = not | applicable, and that should be clearly stated. (Work in progress = can, of | course, be pointed to, but it is not clear there is much more than a problem | statement.) =20 OK. I=92ve changed the section to this: =20 =933.3. Address Generation and Configuration =20 The security of the Shim6 protocol is based on the use of CGA and HBA addresses. =20 CGA and HBA generation process can use the information provided by the stateless auto-configuration mechanism defined in [RFC4862] with the additional considerations presented in [RFC3972] and [RFC5535]. =20 Stateful address auto-configuration using DHCP [RFC3315] is not currently supported, because there is no defined mechanism to convey the CGA Parameter Data Structure and other relevant information from the DHCP server to the host. An analysis of the possible interactions between DHCPv6 and Cryptographically Generated Addresses (CGAs) can be found in [I-D.ietf-csi-dhcpv6-cga-ps].=94 =20 =20 | =20 | (2) | This sentence in 3.4 is opaque, unless it is talking about the state = of | implementations (or is this another piece of DHCP speculation?): | =20 | There is no current mechanism designed to allow an administrator to | enforce the configuration of a CGA or an HBA in a host. Ok, I=92ve removed it, since the comment is implicit in the previous = section.=20 =20 | =20 | (3) | Section 3.4, 7.2: The term "hybrid" does not occur in RFC 5535. | Adapt the terminology. OK, I adhere to RFC5535 text. Now the text says: =20 =93 In the case that a Shim6-capable host is using HBAs to protect its locator sets, the host will need to generate an address which is both a valid CGA and a valid HBA, as defined in [RFC5535]=94 =20 | =20 | (4) | Section 5.2: | =20 | One such solution is being developed at the MP-TCP Working Group. | =20 | That is not the name of the WG, and referring to ephemeral IETF WGs = is not | very useful in an archival document such as an RFC. It is probably = most | appropriate to reference RFC 6182. Done =20 | =20 | More generally speaking, one would expect some more guidance when | MPTCP is appropriate and when Shim6 is appropriate. Oddly, RFC 6181 | seems to provide more information about Shim6 on this point than the | present document. Well, I think the inclusion of MPTCP along with SCTP provides much more information.=20 Regarding to the information included in RFC6181, this information has = not much to do with this =91application=92 document: RFC6181 describes the = security threats involving locator agility in MPTCP, which have some relation to those faced by Shim6 (that=92s why Shim6 is referred there). These = threats are related to the design of the protocol, but not to the application of the protocol, since once they have been successfully addressed by the = protocol itself, the managers deploying it do not need to care about anymore. So these issues are covered by the Shim6 specification [RFC5533], but do = not need to be considered here, in the applicability considerations. =20 | =20 | (5) | (On a related note, avoid discussion of the Shim6 WG's charter in = 7.5.) Sure. Changed to =93Shim6 aimed to provide a solution to =85=94 =20 | =20 | ** Nits: | =20 | [I-D.ietf-mif-problem-statement] is now RFC 6418. | =20 | The document will benefit from some micro-editing, e.g. | s/different to/different from/g | s/specific of/specific to/g | s/associated to/associated with/g | s/is developed/has been developed/ | The usage of "suffer" in several places | (in particular, should "These problems are suffered by other = solutions | supporting multihoming such as SCTP [RFC4960] or HIP | [RFC4423]." in section 4 not be "relevant to" instead?) | "Shim6 has no means to enforce neither host nor network = forwarding..." Corrected to =93When a locator has been selected by a host to be used as source address for a Shim6 session, Shim6 has no means to enforce an appropriate path for that source address neither in the host nor in the network.=94 =20 | "does not require also" | s/should be review/should be reviewed/ | "...which security features can expect applications and users of the Shim6 | protocol." | As this is typically done by the RFC editor, I'm not providing a = detailed list | here. | =20 | Section 4: s/not being used/not be used/ | =20 | Define "REAP" (I know, RFC5533 doesn't, either). | =20 | Section 6: This sentence is hard to read: | "As long as the address exchanged, IP_A is the ULID..." =20 All these nits have been corrected. =20 Thanks again, Alberto =20 | =20 | _______________________________________________ | shim6 mailing list | shim6@ietf.org | https://www.ietf.org/mailman/listinfo/shim6 ------=_NextPart_000_00AD_01CCFBC3.E04B0870 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Carsten,

Thank you very much for your = review

 

|=A0 = -----Mensaje original-----

|=A0 = De: shim6-bounces@ietf.org = [mailto:shim6-bounces@iet= f.org] En nombre

|=A0 de = Carsten Bormann

|=A0 Enviado el: = mi=E9rcoles, 29 de febrero de 2012 23:13

|=A0 Para: IETF Apps Discuss; = draft-garcia-shim6-applicability.all@tools.ietf.org;

|=A0 shim6@ietf.org

|=A0 CC: The IESG

|=A0 Asunto: [shim6] APPSDIR = review of draft-garcia-shim6-applicability-03

|=A0

|=A0 I have been selected as the = Applications Area Directorate reviewer for this

|=A0 draft (for background on = APPSDIR, please see

|=A0 http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAr= eaDirectorate).

|=A0

|=A0 Please resolve these = comments along with any other Last Call comments

|=A0 you may receive. Please = wait for direction from your document shepherd = or

|=A0 = AD before posting a new version of the draft.

|=A0

|=A0 Gruesse, = Carsten

|=A0 = ---------------------------------

|=A0

|=A0 Document: = draft-garcia-shim6-applicability-03.txt

|=A0 Title: Applicability = Statement for the Level 3 Multihoming Shim = Protocol

|=A0 (Shim6)

|=A0 Reviewer: Carsten = Bormann

|=A0 IETF Last Call Date: = 2012-02-15

|=A0 Review Date: 2012-02-29

|=A0

|=A0 ** Summary: This draft is = ready for publication as an Informational

|=A0=A0=A0=A0 RFC with small = changes, but maybe requires a better title.

|=A0

|=A0 Note: I reviewed this with = the expectation that the intended audience will

|=A0 read this *before* looking = at RFC5533–5535 in detail.

|=A0

|=A0 ** Major = Issues:

|=A0

|=A0 General:

|=A0

|=A0 The document provides = useful discussion of considerations around the

|=A0 usage of Shim6.=A0 At the = end, it leaves the reader confused: What *is* = the

|=A0 = applicability/area of application of Shim6?=A0

 

I assume this comment relates = with the expectations created by the title, so I comment = below.

 

|=A0 Who should decide whether

|=A0 Shim6 is activated for a = specific connection?=A0 (There is an API in RFC = 6316,

|=A0 but clearly that is meant for advanced applications.) =

 

This issue was partially addressed in the 'Short-Lived = Communications' subsection. However, I think the text would improve by = placing this in a more prominent place, and by making a clearer = statement. I have appended the following text just to the end of the '2. = Deployment Scenarios' section:

 

“To allow nodes to benefit = from the capabilities provided by Shim6

=A0=A0 (discussed in Section 5) = such as fault tolerance, nodes should be

=A0=A0 configured to initiate a = Shim6 session with any peer node if they

=A0=A0 have multiple locators to = use.=A0 Note that this configuration can be

=A0=A0 performed transparently = to the applications, in the sense that

=A0=A0 applications do not need = to be aware of the Shim6 functionality

=A0=A0 provided by the node; iin = particular, nodes are not forced to use the

=A0=A0 Shim6 API [RFC6316] to = benefit from Shim6.=A0 The Shim6 session should

=A0=A0 be created after the two = nodes have been communicating for some time,

=A0=A0 i.e. using the deferred = context establishment facility provided by

=A0=A0 Shim6.=A0 Otherwise, the = cost of the Shim6 4-way handshake used for

=A0=A0 establishing the session = may exceed the benefits provided for short-

=A0=A0 lived communications (see = Section 5.1.2).=A0 More advanced node

=A0=A0 configuration may = involved configuring different delays for

=A0=A0 initiating the session = for different applications, for example, based

=A0=A0 on a per-port = configuration.=A0 Nodes being able to use a = single

=A0=A0 locator for the communication should not initiate = the creation of a

=A0=A0 Shim6 context, but should participate if other node = initiates it.

=A0=A0 Note that Shim6-aware applications can overrid this = behavior by means

=A0=A0 of the Shim6 API = [RFC6316].”

 

By the way, I've also merged the 'Short-lived' and = 'Long-lived' sections, into a single '5.1.2. Short-lived and long-lived = communications', which is referred in the previous = paragraph.

Does this address your concern?

 

|=A0 While the = document

|=A0 successfully relates Shim6 to SCTP and HIP, what about = other approaches to

|=A0 multi-addressing?=A0

In general, all mechanisms which = handle different addresses at a higher level than the network-layer may = experience unwanted interactions with Shim6. This applies to MPTCP, in = addition to SCTP. Although there was a generic comment regarding to this = at the end of the SCTP section, I have make this more explicit for = MPTCP, by changing the SCTP section to refer to both SCTP and = MPTCP.

 

“7.3.=A0 Shim6, SCTP and =
MPTCP
 
=A0=A0 Both the SCTP [RFC4960] and =
MPTCP [RFC6182] protocols provide a
=A0=A0 reliable, stream-based =
communications channel between two hosts =
which
=A0=A0 provides a superset of the capabilities of =
TCP.=A0 One notable feature
=A0=A0 of these two protocols is that =
they allow the exchange of endpoint
=A0=A0 addresses between hosts, in =
order to recover from the failure of a
=A0=A0 particular endpoint pair, or =
to benefit from multipath =
communication
=A0=A0 in the MPTCP case, in a manner which is =
conceptually similar to
=A0=A0 locator selection in =
Shim6.
 
=A0=A0 SCTP and MPTCP are =
transport-layer protocols, higher in the =
protocol
=A0=A0 stack than Shim6, and hence there is no =
fundamental incompatibility
=A0=A0 which would prevent a =
Shim6-capable host from communicating =
using
=A0=A0 SCTP or =
MPTCP.
 
=A0=A0 However, since either SCTP or =
MPTCP, and Shim6 aim to exchange
=A0=A0 addressing information between =
hosts in order to meet the same
=A0=A0 generic goal, it is possible =
that their simultaneous use might =
result
=A0=A0 in unexpected behavior, e.g. lead to race =
conditions.
 
=A0=A0 The capabilities of these =
transport protocols with respect to =
path
=A0=A0 maintenance of a reliable, =
connection-oriented stream protocol =
are
=A0=A0 more extensive than the more general =
layer-3 locator agility provided
=A0=A0 by Shim6.=A0 Therefore, it is =
recommended that Shim6 is not used for
=A0=A0 SCTP or MPTCP sessions, and =
that path maintenance is provided =
solely
=A0=A0 by SCTP or MPTCP.=A0 There are at least two =
ways to enforce this
=A0=A0 behavior.=A0 One option would be to make =
the stack, and in particular
=A0=A0 the Shim6 sublayer, aware of =
the use of SCTP or MPTCP and in this
=A0=A0 case refrain from creating a =
Shim6 context.=A0 The other option is =
that
=A0=A0 the upper transport layer, informs using a =
Shim6-capable API like the
=A0=A0 one proposed in [RFC6316] that =
no Shim6 context must be created for
=A0=A0 this particular =
communication.
 
=A0=A0 In general, the issues =
described here may also arise for =
protocols
=A0=A0 which handle different addresses for two =
communicating nodes at a
=A0=A0 higher level than the network-layer to =
improve reliability,
=A0=A0 performance, congestion control, =
etc.”
 

 

|=A0 When is happy-eyeballs enough?=A0 =

Umm. In = my opinion, the happy-eyeballs algorithm is not related to Shim6. = Happy-eyeballs deals with dual-stack hosts connecting to servers. As = discussed in section ‘3.1 Protocol Version (IPv4 vs. IPv6)’, = Shim6 is just defined for IPv6.

 

 

|=A0 When should = MPTCP

|=A0 be used?=A0

Now this is included in the new = SCTP/MPTCP section commented before.

 

|=A0 (The introduction to 7 then = goes ahead and destroys any

|=A0 remaining hope that this = document provides the answers -- maybe this

|=A0 should be split into = "Open Issues" and the solid information about = where

|=A0 Shim6 is not needed.)

|=A0

|=A0 The document may have = started out as an applicability statement half a

|=A0 decade ago, but maybe = renaming it to "Considerations on the Application = of

|=A0 = Shim6" provides a more appropriate title = now.

|=A0

|=A0 Again, this is meant as a comment on the expectations = raised by the title

|=A0 and abstract, not as an attempt to belittle the = usefulness of the document's

|=A0 = content.

|=A0

 

I think I see your point. For me its ok to change the title = to ‘Considerations on the Application of the Level 3 Multihoming = Shim Protocol (Shim6)’

I’ve also changed the = abstract to a less ambitious

“This document discusses = some considerations on the applicability of the Shim6 IPv6 protocol and = associated support protocols and mechanisms to provide site multihoming = capabilities in IPv6.”

 

Regarding to splitting section 7 = into something like ‘open issues’, and ‘do not = mix’, this is not evident to me. The ‘do not mix’ is = comprised of just two subsections (‘SCTP/MPTCP’ and = ‘HIP’). Besides, the ‘open issues’ part is very = heterogeneous: there are things we are pretty confident that should work = (e.g. ‘SEND and Shim6’), complex interactions (eg. NATs will = work as long as there are no changes in the locators, which leads to a = functionality which is not worse than current IPv6, although not as good = as Shim6 could provide…), things that may work but they should be = tested (MIP, NEMO, firewalls)…

I prefer the current approach in = which each ‘Shim6 and other’ combination is considered = separately, without giving further structure to the section (structure = that is difficult for me to find).

 

|=A0 ** Minor = Issues:

|=A0

|=A0 (1)

|=A0 I'm not so fond of the DHCP speculation in 3.3.=A0 An = applicability statement

|=A0 should talk about what is, = not what could be.=A0 As of today, DHCP is not

|=A0 applicable, and that should = be clearly stated.=A0 (Work in progress can, of

|=A0 course, be pointed to, but = it is not clear there is much more than a = problem

|=A0 statement.)

 

OK. I’ve changed the = section to this:

 

“3.3.=A0 Address Generation and =
Configuration
 
=A0=A0 The security of the Shim6 =
protocol is based on the use of CGA and =
HBA
=A0=A0 =
addresses.
 
=A0=A0 CGA and HBA generation process =
can use the information provided by
=A0=A0 the stateless =
auto-configuration mechanism defined in [RFC4862] =
with
=A0=A0 the additional considerations presented in =
[RFC3972] and [RFC5535].
 
=A0=A0 Stateful address =
auto-configuration using DHCP [RFC3315] is =
not
=A0=A0 currently supported, because there is no =
defined mechanism to convey
=A0=A0 the CGA Parameter Data =
Structure and other relevant information =
from
=A0=A0 the DHCP server to the host.=A0 An analysis =
of the possible
=A0=A0 interactions between DHCPv6 and =
Cryptographically Generated Addresses
=A0=A0 (CGAs) can be found in =
[I-D.ietf-csi-dhcpv6-cga-ps].”

 

 

|=A0

|=A0 (2)

|=A0 This sentence in 3.4 is = opaque, unless it is talking about the state of

|=A0 implementations (or is this = another piece of DHCP speculation?):

|=A0

|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 There is no current = mechanism designed to allow an administrator to

|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 enforce the = configuration of a CGA or an HBA in a host.

Ok, I’ve removed it, since = the comment is implicit in the previous section. =

 

|=A0

|=A0 (3)

|=A0 Section 3.4, 7.2:=A0 The term "hybrid" does = not occur in RFC 5535.

|=A0 Adapt the = terminology.

OK, I adhere to RFC5535 text. Now the text = says:

 

“ In the case that a Shim6-capable host is using HBAs = to

=A0 = protect its locator sets, the host will need to = generate

=A0 an address which is both a valid CGA and a valid HBA, = as defined in [RFC5535]”

 

|=A0

|=A0 (4)

|=A0 Section = 5.2:

|=A0

|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 One such solution is = being developed at the MP-TCP Working Group.

|=A0

|=A0 That is not the name of the = WG, and referring to ephemeral IETF WGs is not

|=A0 very useful in an archival = document such as an RFC.=A0 It is probably most

|=A0 appropriate to reference = RFC 6182.

Done

 

|=A0

|=A0 More generally speaking, one would expect some more = guidance when

|=A0 MPTCP is appropriate and when Shim6 is appropriate.=A0 = Oddly, RFC 6181

|=A0 seems to provide more information about Shim6 on this = point than the

|=A0 present document.

Well, I think the inclusion of = MPTCP along with SCTP provides much more information. =

Regarding to the information included in RFC6181, this = information has not much to do with this ‘application’ = document: RFC6181 describes the security threats involving locator = agility in MPTCP, which have some relation to those faced by Shim6 = (that’s why Shim6 is referred there). These threats are related to = the design of the protocol, but not to the application of the protocol, = since once they have been successfully addressed by the protocol itself, = the managers deploying it do not need to care about anymore. So these = issues are covered by the Shim6 specification [RFC5533], but do not need = to be considered here, in the applicability = considerations.

 

|=A0

|=A0 (5)

|=A0 (On a related note, avoid discussion of the Shim6 WG's = charter in 7.5.)

Sure. Changed to

“Shim6 aimed to provide a = solution to …”

 

|=A0

|=A0 ** = Nits:

|=A0

|=A0 [I-D.ietf-mif-problem-statement] is now RFC = 6418.

|=A0

|=A0 The document will benefit from some micro-editing, = e.g.

|=A0 s/different to/different = from/g

|=A0 s/specific of/specific to/g

|=A0 s/associated to/associated = with/g

|=A0 s/is developed/has been = developed/

|=A0 The usage of "suffer" in several = places

|=A0 (in particular, should "These problems are = suffered by other solutions

|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 supporting = multihoming such as SCTP [RFC4960] or HIP

|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 [RFC4423]." = in section 4 not be "relevant to" = instead?)

|=A0 "Shim6 has no means to enforce neither host nor = network forwarding..."

Corrected to “When a = locator has been selected by a host to be used as source address for a = Shim6 session, Shim6 has no means to enforce an appropriate path for = that source address neither in the host nor in the = network.”

 

|=A0 "does not require = also"

|=A0 s/should be review/should be = reviewed/

|=A0 "...which security features can expect = applications and users of the Shim6

|=A0 = protocol."

|=A0 As this is typically done by the RFC editor, I'm not = providing a detailed list

|=A0 = here.

|=A0

|=A0 Section 4: s/not being used/not be = used/

|=A0

|=A0 Define "REAP" (I know, RFC5533 doesn't, = either).

|=A0

|=A0 Section 6: This sentence is hard to = read:

|=A0 "As long as the address exchanged, IP_A is the = ULID..."

 

All these nits have been corrected.

 

Thanks = again,

Alberto

 

|=A0

|=A0 = _______________________________________________

|=A0 shim6 mailing = list

|=A0 shim6@ietf.org

|=A0 https://www.ietf.org/mailman/listinfo/shim6

------=_NextPart_000_00AD_01CCFBC3.E04B0870-- From ted.ietf@gmail.com Wed Mar 7 11:26:04 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7347511E8086; Wed, 7 Mar 2012 11:26:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.669 X-Spam-Level: X-Spam-Status: No, score=-3.669 tagged_above=-999 required=5 tests=[AWL=-0.070, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YK9soBXjJ1q0; Wed, 7 Mar 2012 11:26:03 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5AC1A11E807F; Wed, 7 Mar 2012 11:26:03 -0800 (PST) Received: by vcbfk13 with SMTP id fk13so6622940vcb.31 for ; Wed, 07 Mar 2012 11:26:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=EQA2hbCK/QhUZRiUmGcdu0KTO8or802s1AvCI7bclg8=; b=tY5Fufgnih+8LWXyHJXedh1JYycG1HMXZuJZDQ0j5xpfUmR/lI+ouz4K97R1Ini3iq p37CKold00IPhqWKyfRI5OdXD5ft4sYphR8bo31v34VPhe5oYgbzFMBSqefNUb8aNu3x 8zBPooxt32Z8E55zy3vxTFjhLwOipOc1jTwOzF4NU7lO0s3ApNAh7Qzf1dpBWuTdvlO/ r30HFJOIEvWkDbfHThUYGZ0q8mEx36H0fUy2gxTTC2lq8D7LWYszP2PJM71Pn7gG2CON 6TCpZsj91p3MnPtNJJEs5FG2PeAQA0/7KncVHHtdkhb5jJr05S8AJkpQpOPiTjU2gbFK 5Hcw== MIME-Version: 1.0 Received: by 10.52.71.114 with SMTP id t18mr5105488vdu.88.1331148362789; Wed, 07 Mar 2012 11:26:02 -0800 (PST) Received: by 10.52.115.66 with HTTP; Wed, 7 Mar 2012 11:26:02 -0800 (PST) In-Reply-To: <4F578169.7040408@isi.edu> References: <4F578169.7040408@isi.edu> Date: Wed, 7 Mar 2012 11:26:02 -0800 Message-ID: From: Ted Hardie To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: draft-ietf-intarea-ipv4-id-update.all@tools.ietf.org, IESG , apps-discuss@ietf.org Subject: Re: [apps-discuss] APPS directorate review of ietf-intarea-ipv4-id-update X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 07 Mar 2012 19:26:04 -0000 Hi Joe, Thanks for your quick reply; comments in-line. On Wed, Mar 7, 2012 at 7:40 AM, Joe Touch wrote: > >> Minor Issues: [list any minor issues such as text that is unclear or >> confusing, preferably by section number] >> >> In section 6, the inclusion of the mathematical expression for which >> datagrams were atomic vs. non-atomic did not seem to add anything to >> the clarity of the surrounding text. =A0By introducing several >> abbreviations and reviewing the logical operators, it seemed to >> complicate what appeared to be a very clear statement: =A0Atomic >> datagrams are those which are not fragmented now and for which later >> fragmentation is inhibited; non-atomic datagrams are those that either >> are fragmented or which may later be fragmented. > > > The equations are intended to be pseudocode, to define atomicity in terms= of > specific tests on IP header fields. This helps clarify the interpretation= of > the English definition to help coders. We can clarify that by replacing > "mathematical expression" with "pseudocode". > > Would that clarify the utility of the expressions? Should we also explain > the rationale for including them in a single sentence? > If you will retain them, I think it should be stated more explicitly that the expressions are simply a restatement of the textual definitions. Perhaps: OLD: Atomic datagrams: datagrams not yet fragmented (MF=3D0 and fragment offset=3D0) and for which further fragmentation has been inhibited (DF=3D1), i.e., as a mathematical expression (equals is =3D=3D, logic= al 'and' is &&, logical 'or' is ||, greater than is >, logical 'not' is ~, and parenthesis function typically): (DF=3D=3D1)&&(MF=3D=3D0)&&(frag_offset=3D=3D0) o Non-atomic datagrams: datagrams which have either already been fragmented, i.e.: (MF=3D1)||(frag_offset>0) or for which fragmentation remains possible: (DF=3D=3D0) I.e., non-atomic datagrams can be expressed in two equivalent tests: (DF=3D=3D0)||(MF=3D=3D1)||(frag_offset>0) which can also be expressed as follows, using DeMorgan's Law and other identities: ~((DF=3D=3D1)&&(MF=3D=3D0)&&(frag_offset=3D=3D0)) Note that this final expression is the same as "not(atomic)". NEW: Atomic datagrams are datagrams not yet fragmented and for which further fragmentation has been inhibited. Non-atomic datagrams are datagrams which either have already been fragmented or for which fragmentation remains possible. This same definition can be expressed in pseudo code as using common logical operators (equals is =3D=3D, logical 'and' is &&, logical 'or' is ||, greater than is >, logical 'not' is ~, and parenthesis function typically) as: atomic datagrams: (DF=3D=3D1)&&(MF=3D=3D0)&&(frag_offset=3D=3D0) non-atomic datagrams: (DF=3D=3D0)||(MF=3D=3D1)||(frag_offset>0) > > >> In section 10, the document states: >> >> When compression assumes a changing ID as a default, having a non- >> =A0 =A0changing ID can make compression less efficient (see footnote 21 = of >> [RFC1144] or >> =A0 cRTP [RFC2508]). >> >> The text of footnote 21 is: >> >> =A0 =A0Note that the test here is against one, not zero. =A0The packet I= D is >> =A0 =A0typically incremented by one for each packet sent so a change of = zero >> is >> =A0 =A0very unlikely. =A0A change of one is likely: =A0It occurs during = any period >> =A0 =A0when the originating system has activity on only one connection. >> >> I was expecting the footnote to contain data that referred to >> compression efficiency; >> perhaps some additional context is needed? > > > We could change that to "less efficient. Such non-changing IDs have been > described in various RFCs (e.g., footnote 21 of [RFC1144 and cRTP > [RFC2508])." > > Would that be more clear? > Yes, that's clearer, thanks, Ted Hardie From barryleiba.mailing.lists@gmail.com Wed Mar 7 15:19:05 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A28A11E808E for ; Wed, 7 Mar 2012 15:19:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.985 X-Spam-Level: X-Spam-Status: No, score=-102.985 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pwpzc3sUY1aB for ; Wed, 7 Mar 2012 15:19:04 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4601211E8074 for ; Wed, 7 Mar 2012 15:19:04 -0800 (PST) Received: by vcbfk13 with SMTP id fk13so6843164vcb.31 for ; Wed, 07 Mar 2012 15:19:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=GDCUHhD82eUAVkN+H5ZCG54PMzlsnDJ6PaJ7f7hJlaM=; b=PS+/aRfi0JmZxEuP6UoHFip7jMRMqHR6xP67Rbkeqd7Y/SBV6VgWtY+8uEAdxpEu3Z r7Ssm9fYv2MKknxKxhheaviVf4OsRluVpZ5Evt0pGtvUfr8l3bAve98S8myT9M4NzWC0 NBFPQEfl/krnNcFc94VrCcqQOzTP8bttZxsZOz/S/TWrqoQowzBsrzk1QPcGjQ6Ex/yU DZ5lYACCx5FXZlwHT8K9ArPvgBkDs6tYOVItiUH5NHFIB0SrLkdV5gm5uyn23q4gjLmn IZhoCDRw0J7TM5IpE3rfi4aWB0qv0TCIY6Aj3bdAwrXvEPmpvBa1Q33a6/nTKnmPCmpx te7w== MIME-Version: 1.0 Received: by 10.52.178.40 with SMTP id cv8mr6432935vdc.82.1331162343826; Wed, 07 Mar 2012 15:19:03 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.52.161.37 with HTTP; Wed, 7 Mar 2012 15:19:03 -0800 (PST) In-Reply-To: References: Date: Wed, 7 Mar 2012 18:19:03 -0500 X-Google-Sender-Auth: xzT3R3Hn1C4RMF-v_6ybIMlE_vM Message-ID: From: Barry Leiba To: Walter Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Proposal for a Finance Area Mailing List X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 07 Mar 2012 23:19:05 -0000 Apps-Discuss folks: It's been about a week since Walter posted this, and no one's commented. Perhaps that means that no one's interested, but I'd like to stir the pot a bit and see whether anyone has anything to say. Nudge-nudge, stir-stir. Walter, what we're looking for here is some public discussion that results in at least some reasonable level of understanding about what would be discussed on the mailing list you propose, who might be interested in participating and, importantly, what IETF work might come out of it. I'll note that standardization doesn't only happen in the IETF; there other standards organizations with different foci, and industry consortia often form to develop special-purpose standards for limited industry subgroups. What you want here might not be a bunch of Internet gearheads who worry about SMTP, HTTP, SIP, MPLS, and BGP, but, rather, some techies involved in the finance industry who can better develop something that really meets the need you have. That's not an answer one way or the other, but a call for conversation and analysis, and some seeds to start the discussion. Barry, AppsAWG chair and incoming App AD On Thu, Mar 1, 2012 at 10:31 AM, Walter wrote: > Hi there. > > This message is posted at the request of the Application Area Managers > as the culmination of email interaction dating back to December 15, > 2011. > > We seek the establishment of a mailing list for the discussion of > financial area protocols. > > Recently Payward Inc. authored two drafts: > https://datatracker.ietf.org/doc/draft-iiban/ > https://datatracker.ietf.org/doc/draft-imic/ > > The drafts propose means for financial endpoint identification and > financial market identification. They are of wide potential interest > for alternate financial networking, however they are missing a > critical and complex reason to deploy them widely, which is an > inter-institutional protocol for transaction quotation, negotiation, > reporting and state management. > > A possible solution in this area will be presented in an upcoming > draft, essentially seeking to provide a mechanism to replace > established protocols (ISO20022, FIX) with an open, non-legacy > alternative with adequate flexibility to support emerging digital > financial networks. =A0To illustrate, the problem statement for the as > yet unpublished draft is as follows. > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =A0Certain functionality required by modern financial systems is not > =A0presently available in open, legacy-free, adequately globalized > =A0protocols. > > =A0This functionality includes: > =A0 * Settlement and reversal / cancellation term negotiation > =A0 * Exchange rate negotiation > =A0 * Latency calculation / negotiation > =A0 * Fee, tax and discount calculation / negotiation > =A0 * Arbitrary currency / asset support > =A0 * Multi-currency / asset transaction support > =A0 * Quotation support > =A0 * Multiple settlement path support > =A0 * Optional support for in-band settlement (sometimes known as DVP) > =A0 * High precision decimal value support > =A0 * Arbitrary financial settlement topology support > =A0 * Arbitrary communications topology support > > =A0Given this situation, it makes sense to propose a legacy-free, > =A0adequately extensible protocol for internet-based financial exchange. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > In addition to our own work above, most of you are probably aware of > some of the various other efforts going on in the financial world. > These efforts include mobile finance, digital currencies and > settlement systems, private currency markets, new transaction > protocols, scalable non fiat-currency based community-centric > transaction systems, and other projects. =A0A few examples: > =A0- Bitcoin: http://bitcoin.org/ > =A0- CES: http://ces.org.za/ > =A0- Ripple: http://ripple-project.org/ > =A0- W3C Web Payments: http://www.w3.org/community/webpayments/ > > At this stage some discussions have already occurred in public forums > with reference to the drafts that Payward Inc. has published and the > potential for a greater community involvement in exploring potential > solutions: > =A0http://bit.ly/v6n2tk (The Bitcoin Trader) > =A0http://bit.ly/xpMxQ3 (Bitcoin Development list) > =A0http://bit.ly/zpVHms (Ripple Users) > > Unfortunately, due to the project-oriented nature of each of these > forums it is difficult to focus on issues that exceed individual > project scope either affect or have the potential to affect the wider > internet community. Therefore Iwebelieve that it would be useful to > try to draw representatives of the various projects together to > discuss such issues via a mailing list hosted at the IETF, with the > goal to discuss and develop solutions to problems in established and > emerging financial networks. =A0The IETF specifically can provide: > > =A01. Transparency and community examination of a proven standards > development process > =A02. Access to IANA: an established, internationally credible third > party for registry management (very useful to build trust in alternate > financial systems) > =A03. Access to functional, supplementary services such as document distr= ibution. > > We therefore request the establishment of a financial area mailing list. > > Feedback and statements of interest are hereby requested. > > Regards, > Walter Stanish > Payward Inc. > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From eran@hueniverse.com Wed Mar 7 15:43:01 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3DAC21E800C; Wed, 7 Mar 2012 15:43:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fKYsx96AU1n8; Wed, 7 Mar 2012 15:43:00 -0800 (PST) Received: from p3plex2out02.prod.phx3.secureserver.net (p3plex2out02.prod.phx3.secureserver.net [184.168.131.14]) by ietfa.amsl.com (Postfix) with ESMTP id F1B9111E8072; Wed, 7 Mar 2012 15:42:59 -0800 (PST) Received: from P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) by p3plex2out02.prod.phx3.secureserver.net with bizsmtp id iniz1i0A70U5vnL01nizmv; Wed, 07 Mar 2012 16:42:59 -0700 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 7 Mar 2012 16:42:57 -0700 From: Eran Hammer To: "Henry S. Thompson" , Justin Richer Date: Wed, 7 Mar 2012 16:42:50 -0700 Thread-Topic: [OAUTH-WG] FW: Appsdir review of draft-ietf-oauth-v2-23 Thread-Index: AczrQyWuo/9gAw6OQ5yDyRn3Fjfr8gReLuwA Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453AFCD4076@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: 90C41DD21FB7C64BB94121FBBC2E723453AADDD2D4@P3PW5EX1MB01.EX1.SECURESERVER.NET, f5bfwemh7pe.fsf@calexico.inf.ed.ac.uk In-Reply-To: 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: "dr@fb.com" , "apps-discuss@ietf.org" , "barryleiba@gmail.com" , "oauth@ietf.org" , "dick.hardt@gmail.com" Subject: Re: [apps-discuss] [OAUTH-WG] FW: Appsdir review of draft-ietf-oauth-v2-23 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 07 Mar 2012 23:43:01 -0000 > -----Original Message----- > From: Henry S. Thompson [mailto:ht@inf.ed.ac.uk] > Sent: Tuesday, February 14, 2012 9:07 AM > >> 11 It seems at best old-fashioned that the designer of a new access > >> token type, parameter, endpoint response type or extension error has > >> no better tool available than Google to help him/her discover whether > >> the name they have in mind is in use already. The same is true under > >> the proposed approach for any developer trying to determine what they > >> can use or must support. Is there some reason that mandated URI > >> templates, after the fashion of >=20 > >> http://www.iana.org/assignments/media-types/text/ >=20 > >> are not mandated for the registries, e.g. >=20 > >> http://www.iana.org/assignments/access-token-types/bearer >=20 > >> ? If there is a good reason, please use it to at least explicitly > >> acknowledge and justify the basis for failing to provide a way for > >> users and developers to use the "follow your nose" strategy > >> [1]. If there is no good reason, please include the appropriate > >> language to require something along the lines suggested above. If > >> you need a model, see [2]. >=20 > > I'm confused - is this a request to use a full URI for all extension > > values? I thought the purpose of a registry was to deconflict the > > short names, and that URIs could be used for anything else. >=20 > No, I appreciate that you want to use registered short names in the proto= col, > that's just fine. My problem is that you have left users, developers etc= . with > no way to discover what shortnames have been registered short of a non- > trivial and error-prone informal search effort. >=20 > What I'm asking for is support for probe URI prefixes for each family of > shortnames. So, just as today I use "text/n3" as the media type for my > Notation3 documents, I can check that this is a registered media type by > attempting to retrieve >=20 > http://www.iana.org/assignments/media-types/text/n3 >=20 > and I can see all the registered text types by retrieving from >=20 > http://www.iana.org/assignments/media-types/text >=20 > likewise I ought to be able to check e.g. the "bearer" token type by > attempting retrieval from (something along the lines of) >=20 > http://www.iana.org/assignments/access-token-types/bearer >=20 > and I should be able to see all the registered token types by retrieving = from >=20 > http://www.iana.org/assignments/access-token-types >=20 > Hope this clarifies what I meant. >=20 Not sure I understand what you are asking for, but what would the IANA inst= ruction include to support this? EH From eran@hueniverse.com Wed Mar 7 15:49:40 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D04D211E808C; Wed, 7 Mar 2012 15:49:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NpRBdVfsbPKp; Wed, 7 Mar 2012 15:49:39 -0800 (PST) Received: from p3plex2out01.prod.phx3.secureserver.net (p3plex2out01.prod.phx3.secureserver.net [184.168.131.12]) by ietfa.amsl.com (Postfix) with ESMTP id CCC8611E8072; Wed, 7 Mar 2012 15:49:39 -0800 (PST) Received: from P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) by p3plex2out01.prod.phx3.secureserver.net with bizsmtp id inpf1i03g0U5vnL01npfT3; Wed, 07 Mar 2012 16:49:39 -0700 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Wed, 7 Mar 2012 16:49:38 -0700 From: Eran Hammer To: "Henry S. Thompson" , "apps-discuss@ietf.org" , "barryleiba@gmail.com" , "dick.hardt@gmail.com" , "dr@fb.com" , "hannes.tschofenig@gmx.net" , "stephen.farrell@cs.tcd.ie" Date: Wed, 7 Mar 2012 16:49:31 -0700 Thread-Topic: Appsdir review of draft-ietf-oauth-v2-23 Thread-Index: AczlvkX9Wm7N4OupT3CF98JH152i4AW+wv7Q Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453AFCD4077@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: In-Reply-To: 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: "iesg@ietf.org" Subject: Re: [apps-discuss] Appsdir review of draft-ietf-oauth-v2-23 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 07 Mar 2012 23:49:40 -0000 Thanks Henry. > -----Original Message----- > From: Henry S. Thompson [mailto:ht@inf.ed.ac.uk] > Sent: Tuesday, February 07, 2012 9:31 AM > To: apps-discuss@ietf.org; barryleiba@gmail.com; dick.hardt@gmail.com; > dr@fb.com; Eran Hammer; hannes.tschofenig@gmx.net; > stephen.farrell@cs.tcd.ie > Cc: iesg@ietf.org > Subject: Appsdir review of draft-ietf-oauth-v2-23 >=20 > I have been selected as the Applications Area Directorate reviewer for th= is > draft (for background on appsdir, please see > http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate= ). >=20 > Please resolve these comments along with any other Last Call comments you > may receive. Please wait for direction from your document shepherd or AD > before posting a new version of the draft. >=20 > Document: draft-ietf-oauth-v2-23 >=20 > Title: The OAuth 2.0 Authorization Protocol >=20 > Reviewer: Henry S. Thompson >=20 > Review Date: 2012-02-07 >=20 > IETF Last Call Date: 2012-01-24 >=20 > Summary: This draft is almost ready for publication as an Proposed > Standard but has a few issues that should be fixed > before publication >=20 > [Note - My expertise is in the areas of markup and architecture, with onl= y the > average geek's understanding of security and cryptographic technologies. > Any comments below on security issues are therefore of the nature of > general audience concerns, rather than technical worries.] >=20 > Major Issues: >=20 > 3.1.2.1 The failure to require TLS here is worrying. At the very least = I would > expect a requirement that clients which do _not_ require TLS MUST provide > significant user feedback calling attention to this > -- by analogy, absence of a padlock does _not_ suffice. . . Added: If TLS is not available, the authorization server SHOULD warn the end-user about the insecure endpoint prior to redirection= . > 3.1.2.5 In a somewhat parallel case, I would expect this section to at l= east > explain why the SHOULD NOT is not a MUST NOT. Since in practice the > distinction between trusted and untrusted 3rd-party scripting is difficul= t if not > impossible to draw, as written the 2nd para is effectively overriden by t= he > third. New text replacing the last two paragraphs: The client SHOULD NOT include any third-party scripts (e.g. t= hird-party analytics, social plug-ins, ad networks) in the redirection endpoint res= ponse. Instead, it SHOULD extract the credentials from the URI and redirect the = user-agent again to another endpoint without exposing the credentials (in the URI= or elsewhere). If third-party scripts are included, the client MUST NOT ensure = that its own scripts (used to extract and remove the credentials from the URI) wil= l execute first. > 11 It seems at best old-fashioned that the designer of a new access toke= n > type, parameter, endpoint response type or extension error has no better > tool available than Google to help him/her discover whether the name they > have in mind is in use already. The same is true under the proposed > approach for any developer trying to determine what they can use or must > support. Is there some reason that mandated URI templates, after the > fashion of >=20 > http://www.iana.org/assignments/media-types/text/... >=20 > are not mandated for the registries, e.g. >=20 > http://www.iana.org/assignments/access-token-types/bearer >=20 > ? If there is a good reason, please use it to at least explicitly acknow= ledge > and justify the basis for failing to provide a way for users and develope= rs to > use the "follow your nose" strategy [1]. If there is no good reason, ple= ase > include the appropriate language to require something along the lines > suggested above. If you need a model, see [2]. Not sure what to do here to make this change. See other note. > Minor Issues: >=20 > A short summary of the changes from OAuth 1.0/RFC5849 would have been > helpful, and it might still be a good idea to add one. . . Not possible. Two different protocols. > 4.1 Would it be helpful to indicate that steps D&E may occur at any time= after > C, and may be repeated subsequently? That's not always right. Some servers may choose to time limit the delay be= tween C and D. Elsewhere in the document, D is stated as allowed only once. > 11.1 It might be useful to have an 11.1.2, which repeats references to t= he > bearer and mac access token type registration drafts? Maybe. We'll see how all these progress before AUTH48. Can easily add those= then. EH From barryleiba.mailing.lists@gmail.com Wed Mar 7 15:53:38 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDB2E21F855D; Wed, 7 Mar 2012 15:53:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.985 X-Spam-Level: X-Spam-Status: No, score=-102.985 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1gbky3Du-FIU; Wed, 7 Mar 2012 15:53:38 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id EBD0621F8554; Wed, 7 Mar 2012 15:53:37 -0800 (PST) Received: by vbbez10 with SMTP id ez10so6830820vbb.31 for ; Wed, 07 Mar 2012 15:53:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=EIio68DrxkirPlUhd26SVxEX0V+hi4FE17sVf3B4fz4=; b=r3gvd7wSPRSeSHV13TC5l/zCHtfVnscP34nosJVRsAn7FOjqdY9l0qvLvY10FziqBq MBcPRJ+AlErgI7zehY/A2lxW6YnXMJ3MAGA+gb6vc8WZBe5kE1W9Jk54MHm+LsYrVKl3 TKZZ7+W9waqDmrqD+wLPe0IgTq7cevlZCbdLPxYayUZ5aOrakJpE3MWpXttiJiVxGrMw 0I0GIatE/qfCj0qtjRCXz5HL9QEGmq6AIgm2/QC6SZXBW0NNjN+5KhJXkvudHRK8Wnrl 8gyAHkJHaPy7dm9eDPxI1+D6QrI/Zfr/cF3WyPPzv/E7/GMqnK1QKUG9RXSR/rjX0jtg mcfg== MIME-Version: 1.0 Received: by 10.52.24.233 with SMTP id x9mr6390326vdf.116.1331164417515; Wed, 07 Mar 2012 15:53:37 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.52.161.37 with HTTP; Wed, 7 Mar 2012 15:53:37 -0800 (PST) In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453AFCD4076@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723453AFCD4076@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Wed, 7 Mar 2012 18:53:37 -0500 X-Google-Sender-Auth: jXIYmhkhSeuRPa1dpkqaxSJgK8Y Message-ID: From: Barry Leiba To: Eran Hammer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "apps-discuss@ietf.org" , Justin Richer , "dr@fb.com" , "oauth@ietf.org" , "dick.hardt@gmail.com" Subject: Re: [apps-discuss] [OAUTH-WG] FW: Appsdir review of draft-ietf-oauth-v2-23 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 07 Mar 2012 23:53:39 -0000 Henry says... >> No, I appreciate that you want to use registered short names in the prot= ocol, >> that's just fine. =A0My problem is that you have left users, developers = etc. with >> no way to discover what shortnames have been registered short of a non- >> trivial and error-prone informal search effort. >> >> What I'm asking for is support for probe URI prefixes for each family of >> shortnames. =A0So, just as today I use "text/n3" as the media type for m= y >> Notation3 documents, I can check that this is a registered media type by >> attempting to retrieve >> >> =A0http://www.iana.org/assignments/media-types/text/n3 >> >> and I can see all the registered text types by retrieving from >> >> =A0http://www.iana.org/assignments/media-types/text >> >> likewise I ought to be able to check e.g. the "bearer" token type by >> attempting retrieval from (something along the lines of) >> >> =A0http://www.iana.org/assignments/access-token-types/bearer >> >> and I should be able to see all the registered token types by retrieving= from >> >> =A0http://www.iana.org/assignments/access-token-types >> >> Hope this clarifies what I meant. Eran says... > Not sure I understand what you are asking for, but what would the IANA in= struction include to support this? Yeh, I'm not understanding this either. The spec establishes an access-token-type registry, and anyone will be able to look in that registry the same way they look in any other IANA registry, such as media-types. It looks like Henry is asking for this to use some sort of type/subtype mechanism, as media-types does, wherein when a new token type is registered, that registration or subsequent ones can create subtypes of that token type. But it's not clear that such a type/subtype scheme would always apply here, as it does with media types. Some token types will have no subtypes. What makes more sense is for the token types that need to create their own sub-registries to do so. And then those entries will be found from IANA as well -- no error-prone informal search effort should be needed. Or am I missing the same thing Eran is? Barry From walter.stanish@gmail.com Wed Mar 7 16:47:27 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4431221E8011 for ; Wed, 7 Mar 2012 16:47:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.229 X-Spam-Level: X-Spam-Status: No, score=-3.229 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lZ1llHJw6jSJ for ; Wed, 7 Mar 2012 16:47:26 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9FC7321E800C for ; Wed, 7 Mar 2012 16:47:26 -0800 (PST) Received: by obbta4 with SMTP id ta4so6596482obb.31 for ; Wed, 07 Mar 2012 16:47:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=qwnLbMZi9EYDnfzZxvYi8odiZkIr/N0F3KJEvy9gn7M=; b=gaA20I/V2HObXj42GY9E0LzItrkjahhMq3B5hU3iq1C9melsnEKlNPpDY/DADjdnwF Yd0Yv6yLufn6/AxaSXRldROooK5ZIPczBNhZqoP0E0jDmb6LmDgyjrGCxDACpkvAv1Wa mDgQ20RpMv3I1BXIqkBqpJLYDT41uPz73ijbNCXGKzqaTPoToxgAI2rv/2mPWTDvXMjD AKQYGCRDUMEGhpWoL0EwtzqJRoXa7aeQSlnUUOSE1bIVxnHb9sg6E2gIOgKmABILQuMc a5XZKspzG4YtDJA62f8h4uftNLJL74OT0PEWuwx1SjScy5NVUvU6ndELcp01okhtviHY bu0w== MIME-Version: 1.0 Received: by 10.182.188.36 with SMTP id fx4mr1661847obc.7.1331167646244; Wed, 07 Mar 2012 16:47:26 -0800 (PST) Received: by 10.60.149.225 with HTTP; Wed, 7 Mar 2012 16:47:26 -0800 (PST) In-Reply-To: References: Date: Thu, 8 Mar 2012 07:47:26 +0700 Message-ID: From: Walter To: Barry Leiba Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Proposal for a Finance Area Mailing List X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Mar 2012 00:47:27 -0000 > Apps-Discuss folks: It's been about a week since Walter posted this, > and no one's commented. =A0Perhaps that means that no one's =A0interested= , > but I'd like to stir the pot a bit and see whether anyone has anything > to say. =A0Nudge-nudge, stir-stir. For the record I have received a private response from a member of the Energy WG. > Walter, what we're looking for here is some public discussion that > results in at least some reasonable level of understanding about what > would be discussed on the mailing list you propose, Is it really necessary to have people already participating in this mailing list express interest in order to justify a new list on a specific subject? Whilst I can understand the tradition, this does seem like a bit of a paradox to me: surely interested parties are to be drawn to such a mailing list from related corners of the wider internet community? > who might be > interested in participating Addressed in the original email, I believe. > and, importantly, what IETF work might come out of it. Being new to IETF processes in general, I can shed no light on this. Certainly the establishment of some IANA registries. > =A0I'll note that standardization doesn't only happen in > the IETF; there other standards organizations with different foci, and > industry consortia often form to develop special-purpose standards for > limited industry subgroups. =A0What you want here might not be a bunch > of Internet gearheads who worry about SMTP, HTTP, SIP, MPLS, and BGP, > but, rather, some techies involved in the finance industry who can > better develop something that really meets the need you have. I am well aware of the protocol authoring focus. Financial industry groups are not the right forum for this development as they are top-heavy with a massive, indisputable interest in maintaining the status quo. Scope-wise: Whilst we are looking at higher level protocols (hence 'application area'), we can't simply take the de-facto choice and build on HTTP or TCP because they don't meet the multipoint requirements of many financial messaging systems. (In addition, the transaction-orientation of HTTP is too limiting for many such communities who presently use exotic mixes of custom out of band stream replay solutions to resolve intermittent loss on their high bandwidth, sequence-numbered financial information streams) There are a wide range of message queue systems that are in commercial use or open source development that may serve to elegantly resolve transport layer requirements, though mandating an exotic transport layer would be self-defeating. Therefore, the current view is toward transport neutrality. Regards, Walter Stanish Payward, Inc. From ned.freed@mrochek.com Wed Mar 7 18:40:13 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 673CD21E802B for ; Wed, 7 Mar 2012 18:40:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EtwyoAuin11k for ; Wed, 7 Mar 2012 18:40:12 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 9BC7021E8020 for ; Wed, 7 Mar 2012 18:40:12 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OCUEJDGVN4007T4G@mauve.mrochek.com> for apps-discuss@ietf.org; Wed, 7 Mar 2012 18:40:07 -0800 (PST) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OCPMUVDUMO00ZUIL@mauve.mrochek.com>; Wed, 7 Mar 2012 18:40:04 -0800 (PST) Message-id: <01OCUEJBIQMG00ZUIL@mauve.mrochek.com> Date: Wed, 07 Mar 2012 18:35:52 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Tue, 06 Mar 2012 16:12:35 +0100" <4F562963.3000501@tana.it> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <9452079D1A51524AA5749AD23E00392806D278@exch-mbx901.corp.cloudmark.com> <2183832.0qjo89hoBY@scott-latitude-e6320> <4F549914.2020907@tana.it> <01OCQYO1P7T400ZUIL@mauve.mrochek.com> <4F5504A4.6010902@tana.it> <01OCRXKYBLNA00ZUIL@mauve.mrochek.com> <4F562963.3000501@tana.it> To: Alessandro Vesely DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1331174418; bh=LfwxkmPohCo9ssLuhB92/HOyGJ3jsKjAAujstkXUCX4=; h=Cc:Message-id:Date:From:Subject:In-reply-to:MIME-version: Content-type:References:To; b=AlTDN+V2iTZNQWBL4PMNZkvPrYz9SR4fsHfHdvtp09Hprmi/giorUqJt+NjaXtDH/ zXL4bCn0p7MVaG9qUP/EOMFB+tThUDacvkXqPrUWcW3SUM3sXJsVv33NBBz2cgWPKf ox5cu6QzLx8/OGEOnf3HvQ5hSHzsC+5uN/jG7DPg= Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Malformed mail guidance document (draft-ietf-appsawg-malformed-mail) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Mar 2012 02:40:13 -0000 > On 06/Mar/12 09:04, Ned Freed wrote: > > > >> Hm... MIME doesn't seem to say that either is better than the > >> other. Based on what you write below, I'd derive that token is > >> better than quoted-string, provided that quotes are actually > >> superfluous. Hence, the I-D could state that that's the > >> canonical syntax, implying that DKIM signers (and verifiers) may > >> get smoother if they convert that way before playing their > >> magic. > > > > I'm unclear as to the relevance. If you're transforming MIME > > content in some way - and if you're not why are you bothering to > > mess around with the headers - the content will be altered and any > > DKIM signature is going to be invalidated no matter what you do to > > the quotes. > Not necessarily. The message you replied to was sent to apps-discuss > with Content-Type: text/plain; charset=us-ascii, but I received it > from mail.ietf.org with Content-Type: text/plain; charset="us-ascii". > Thus, the message was rewritten, and its signature would have been > broken if the Content-Type field had been signed (which should be the > behavior of choice, according to RFCs 6376-6377.) But that only supports my argument - the list also adds a footer to the message, invalidating any signature on the message body. Who cares about the quotes on a header field when the body was altered? > As for the relevance, I admit it's a statistically irrelevant corner > case, which looks more like a DKIM shortcoming than a MIME fault. Well, I offered to work on the MIME canonicalization problem for DKIM, which happens to be a problem I've given a lot of thought to. Nobody showed even the slightest interest, so... Ned From wmills@yahoo-inc.com Wed Mar 7 22:31:57 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76B4421F8699 for ; Wed, 7 Mar 2012 22:31:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.309 X-Spam-Level: X-Spam-Status: No, score=-16.309 tagged_above=-999 required=5 tests=[AWL=-0.569, BAYES_20=-0.74, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQMho4nM5ki4 for ; Wed, 7 Mar 2012 22:31:56 -0800 (PST) Received: from nm2.bullet.mail.sp2.yahoo.com (nm2.bullet.mail.sp2.yahoo.com [98.139.91.72]) by ietfa.amsl.com (Postfix) with SMTP id CF72621F866E for ; Wed, 7 Mar 2012 22:31:56 -0800 (PST) Received: from [98.139.91.64] by nm2.bullet.mail.sp2.yahoo.com with NNFMP; 08 Mar 2012 06:31:56 -0000 Received: from [98.139.91.1] by tm4.bullet.mail.sp2.yahoo.com with NNFMP; 08 Mar 2012 06:31:56 -0000 Received: from [127.0.0.1] by omp1001.mail.sp2.yahoo.com with NNFMP; 08 Mar 2012 06:31:56 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 321884.63304.bm@omp1001.mail.sp2.yahoo.com Received: (qmail 87424 invoked by uid 60001); 8 Mar 2012 06:31:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1331188315; bh=LTJI8R7h5dhGZg+TnZEtselgHu7jm5+dSAlOZTQgxig=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=XAEL5XyIggODAPRlyYkgDorO1fx1UNFlwxnxTHnNTVuT+ybxKdWdd9dMuUZmdaMNltya46Q/vBIm5MsmaoW20OIG/BzWmrTQpLkZILGQHkvaRWCoo42ObieFOQyZclHpQMi7jWE2KzTu7LqbodghnBwPg9QNva/KDhaoaKYbuOY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=IWPbVvD3Pn1dk8tqomEJYbZhVCTzv2w7oiw/tsX84e51lNuZ6mAj11VMPsAn+8/hZG5IsDit+7r2L36o1gtPtU0rgGeJzwB/eL38mYHhoWN0TAB6HmcM9TvPJWky5Nv9/FhSxFuLnI4/ErcOhDX4rILlzTk6Vw/xXRJQU3K4uVI=; X-YMail-OSG: sjqGd0gVM1ldbmt6EnLahki4fWTAsCjtt8hU_LcPY7dAQw3 hN.wDWi8N04hsYigaojHcO1pKMpGhcjQim_34aapRjtyruSIlKUDEV57Wygt 61qkbtI9XTrM954CvsJiatlFus7akjsPogDmp.hX6AqGDHlE5ACKXTDyLWKg kj1JATbi7bX3WKF8HRY.TCwHZr2JFrqlLLZi4KhKkxC5Az8z1yfp1SY65GPa 7nZW2JLI7QHeXh.xtSiVz59wJCER6J8tB.ioeokBiXqf4FtkCo4wL2IAvJ4c KNNHRo62Q.wU8YKDTld.T8YWqk.wZT8k.0lh1cbog.23m.M2Slth_hLAVRnR LmI3wlu41tR37otY549cF1m3oTSHbOX95OOHejqQXKggmJiklSlt7780gcp4 SoiWPxlPIvOh2QMP7Vlcwor5yyDIXvbgJ0A-- Received: from [209.131.62.115] by web31816.mail.mud.yahoo.com via HTTP; Wed, 07 Mar 2012 22:31:55 PST X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.117.340979 Message-ID: <1331188315.87259.YahooMailNeo@web31816.mail.mud.yahoo.com> Date: Wed, 7 Mar 2012 22:31:55 -0800 (PST) From: William Mills To: "apps-discuss@ietf.org" , "draft-ietf-appsawg-xdash.all@tools.ietf.org" MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: The IESG Subject: [apps-discuss] APPSDIR review of draft-ietf-appswg-xdash-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 06:31:57 -0000 =0A=0ADocument: draft-ietf-appswg-xdash-03=0ATitle: Deprecating Use of the = "X-" Prefix in Application Protocols=0AReviewer: William J. Mills=0AReview = Date: March 6th, 2012=0AIETF Last Call Date: unknown=0AIESG Telechat Date: = unknown=0A=0ASummary: This draft is generally ready for publication, there = are some small issues that might be worth adjusting.=0A=0AMajor Issues: =0A= =0A=0AMinor Issues:=A0=0A=0ASection 4.5 through 4.7:=A0 I would change '"X-= " prefix' to '"X-" or similar prefix'=0A=0ANits:=A0=0A=0AAppendix B, numera= l 1 and 3, second sentence:=A0 I would strike "However, " and start the sen= tences=A0 "In this case..."=0A=0A-=A0=A0=A0 This draft uses the "$statement= . However, $argument_against" construction a lot, and I find that somewhat = clunky.=A0 However, I doubt it's worth fixing.=0A=0A=0A-=A0=A0=A0 The refer= ences are populated primarily with things from the appendices.=A0 It would = make more sense to me if references came last, but I think that breaks the = standard format rules.=0A From carine@jay.w3.org Thu Mar 8 00:33:57 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8581121F85B5 for ; Thu, 8 Mar 2012 00:33:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d6uIqtWExPUI for ; Thu, 8 Mar 2012 00:33:56 -0800 (PST) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id AD5A021F8595 for ; Thu, 8 Mar 2012 00:33:56 -0800 (PST) Received: from carine by jay.w3.org with local (Exim 4.69) (envelope-from ) id 1S5YnK-0002Zs-B5; Thu, 08 Mar 2012 03:33:54 -0500 Date: Thu, 8 Mar 2012 03:33:54 -0500 From: Carine Bournez To: Zach Shelby Message-ID: <20120308083354.GJ23228@jay.w3.org> References: <20120305094330.27895.2135.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: General discussion of application-layer protocols Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-shelby-exi-registration-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Mar 2012 08:33:57 -0000 Hi, On Mon, Mar 05, 2012 at 11:49:40AM +0200, Zach Shelby wrote: > As per the discussion regarding an +exi suffix on this list, I wrote up a short draft describing the registration for such a suffix, when it would be applicable, and what the interoperability requirements are. I will send this to the CoRE list and to ZigBee SE2 for comments as well. > > http://www.ietf.org/id/draft-shelby-exi-registration-00.txt Quoting part of the IANA considerations section: > Interoperability considerations: The registration of a Media Type > using this suffix MUST reference the XML Schema that is used to > encode/decode a payload identified by that Media Type. If multi > versions of this Schema will evolve during the lifetime of the > protocol, the protocol MUST either register multiple Media Types > (one for each version) or use the Schema ID option of EXI to > indicate the version of the Schema. I think this is a really bad idea. The schemaID option is meant to convey the information about the schema(s) in use when the schema-informed mode is chosen. Tying the schema to the media type is very likely to produce interoperability issues as well as compatibility issues between versions of a schema. In any case, you have to agree on other options or send them in the EXI stream, so why schemaID should get special treatment here? A +exi suffix might help conveying the original media type *and* the encoding whenever the content-encoding header is not available in a protocol. However, the suffix should not try to replace some of the existing EXI mechanisms at all. -- Carine Bournez -+- W3C Europe From zach@sensinode.com Thu Mar 8 01:33:25 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E454A21F85DB for ; Thu, 8 Mar 2012 01:33:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.663 X-Spam-Level: X-Spam-Status: No, score=-3.663 tagged_above=-999 required=5 tests=[AWL=-0.064, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D-wi6SDJDxQU for ; Thu, 8 Mar 2012 01:33:25 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id AF18121F8565 for ; Thu, 8 Mar 2012 01:33:23 -0800 (PST) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q289XL8O021711; Thu, 8 Mar 2012 11:33:21 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <20120308083354.GJ23228@jay.w3.org> Date: Thu, 8 Mar 2012 11:33:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <73EF8185-649D-43DB-95FD-513210F21D1C@sensinode.com> References: <20120305094330.27895.2135.idtracker@ietfa.amsl.com> <20120308083354.GJ23228@jay.w3.org> To: Carine Bournez X-Mailer: Apple Mail (2.1084) Cc: General discussion of application-layer protocols Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-shelby-exi-registration-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Mar 2012 09:33:26 -0000 Hi Carine, On Mar 8, 2012, at 10:33 AM, Carine Bournez wrote: >=20 > Hi, >=20 > On Mon, Mar 05, 2012 at 11:49:40AM +0200, Zach Shelby wrote: >> As per the discussion regarding an +exi suffix on this list, I wrote = up a short draft describing the registration for such a suffix, when it = would be applicable, and what the interoperability requirements are. I = will send this to the CoRE list and to ZigBee SE2 for comments as well. >>=20 >> http://www.ietf.org/id/draft-shelby-exi-registration-00.txt >=20 > Quoting part of the IANA considerations section: >=20 >> Interoperability considerations: The registration of a Media Type >> using this suffix MUST reference the XML Schema that is used to >> encode/decode a payload identified by that Media Type. If multi >> versions of this Schema will evolve during the lifetime of the >> protocol, the protocol MUST either register multiple Media Types >> (one for each version) or use the Schema ID option of EXI to >> indicate the version of the Schema. >=20 > I think this is a really bad idea. The schemaID option is meant to=20 > convey the information about the schema(s) in use when the = schema-informed > mode is chosen. Tying the schema to the media type is very likely to > produce interoperability issues as well as compatibility issues=20 > between versions of a schema. In any case, you have to agree on other = options > or send them in the EXI stream, so why schemaID should get special = treatment > here?=20 I agree that the EXI header should be used to convey the EXI specific = options needed to decode the payload (I got a similar comment on the = CoRE list). The SchemaID field is not very useful on its own however, so = the goal of this text should be that the media type registration for = +exi needs to define what to place in the SchemaID field of the header. = It needs to point to a specification of the schemas, and how the value = in the SchemaID field corresponds to them. It may also e.g. define a = default schema to use if the SchemaID field is elided. This is an = important aspect to the efficiency of EXI for M2M applications, where = often our EXI payloads are only tens of bytes long. Placing a 30-50 byte = URI reference to the XSD in the header of that EXI payload would be = unacceptable, however a short integer ID or such is OK.=20 I am fine with removing the text that implies the media type alone = identifies the schema. However the media type does define the semantics = and meaning of the data carried in the payload once it is decoded = (regardless of the schema version or variation).=20 > A +exi suffix might help conveying the original media type *and* the=20= > encoding whenever the content-encoding header is not available > in a protocol. However, the suffix should not try to replace some of > the existing EXI mechanisms at all. Right, and in particular the +exi suffix is only meant to be used in = cases where content-encoding is not being performed, in other words = Schema-informed mode is used and there is no intermediate use of XML. = For other use cases this document should recommend the use of the exi = content-encoding or the generic application/exi media type. Zach >=20 >=20 > --=20 > Carine Bournez -+- W3C Europe >=20 --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From lear@cisco.com Thu Mar 8 02:40:35 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA8C121F85B6; Thu, 8 Mar 2012 02:40:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.537 X-Spam-Level: X-Spam-Status: No, score=-111.537 tagged_above=-999 required=5 tests=[AWL=1.061, BAYES_00=-2.599, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iGn7A-J9Duak; Thu, 8 Mar 2012 02:40:34 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 763C921F846A; Thu, 8 Mar 2012 02:40:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=26563; q=dns/txt; s=iport; t=1331203232; x=1332412832; h=message-id:date:from:mime-version:to:cc:subject; bh=lqaMuhoAXxeLJiqbjWzrKLHF/csXKCLZ5mEUJu7yF44=; b=WoZradw2j0IArsD0ag7J4FGkYPJyRROc4Uun5vPvMWTFPZcgqQ4dcXzt V7V80G3hQaPAYteK6yrtC5xLkTYx8uFcrShCSj7UJu2NR+vhUuRs8CWVk EXEYU1fyGlOpf9DYOAGEmMuvAmnnI056EVgIMlGMsPCIa/1glORy15OE3 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAImLWE+Q/khL/2dsb2JhbABDhTSvcoEHggoBAQEDEwEHCVUBBRQWDQwKCwILAwIBAgFLAQwBBwEBHodhBQubMAGMZ5IuiiKDHoIYgRYElUGQF4JkgVs X-IronPort-AV: E=Sophos;i="4.73,551,1325462400"; d="scan'208,217";a="67972273" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 08 Mar 2012 10:40:31 +0000 Received: from dhcp-10-55-89-64.cisco.com (dhcp-10-55-89-64.cisco.com [10.55.89.64]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q28AeTWe024267; Thu, 8 Mar 2012 10:40:29 GMT Message-ID: <4F588C9D.2090403@cisco.com> Date: Thu, 08 Mar 2012 11:40:29 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "apps-discuss@ietf.org" , draft-desruisseaux-caldav-sched.all@tools.ietf.org, Mark Nottingham X-Enigmail-Version: 1.3.5 Content-Type: multipart/alternative; boundary="------------060200040200060309080607" Cc: Peter Saint-Andre , 'IESG' Subject: [apps-discuss] Applications Directorate Review of draft-desruisseaux-caldav-sched-11 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Mar 2012 10:40:36 -0000 This is a multi-part message in MIME format. --------------060200040200060309080607 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-desruisseaux-caldav-sched-11 Title: CalDAV Scheduling Extensions to WebDAV Reviewer: Eliot Lear Review Date: 8 Mar. 2012 IESG Telechat Date: 15 Mar 2012 Summary: This is a marked improvement from the previous version, represents YET ANOTHER very valuable contribution from these two authors, and is nearly ready for publication. I would suggest one more respin. I believe this could happen, however, AFTER the IESG discussion. Major Issues: A question: can the new status codes defined in this specification leak to non-participating implementations in Reply operations? Minor Issues: In general the document suffers from a lack of conciseness. What follows are some of the more glaring examples. In Section 1, 2nd paragraph, There is no need to describe so early what functions aren't covered. The way this is traditionally handled is to have a "Future Work" section. That can be done in the intro or it can even be put after examples. I prefer the latter, especially if you mean for the text to be non-normative. If it is meant to be normative, be explicit about it. Similarly, in the 4th paragraph, same section, it is sufficient to say (above) that this mechanism works compatibly with iMIP. You're using a double negative. And this problem recurs in the same paragraph. You should consider a search on the word "not". §1, pg 6: > In iTIP-based scheduling, there is an event "Organizer" whose role is > to schedule an event between one or more "Attendees", and this is > done by sending out invitations and handling responses from each > Attendee. Often times an Organizer will do a "freebusy" lookup to > check on Attendees' availability (free-time). This document needn't and shouldn't repeat or review iTIP. Suggest remove. > Servers supporting this specification advertise their capabilities > and provides new collections for scheduling operations as described > in Section 2. This is mundane and not needed in § 1. Suggest you cut it. §1, ppg 6-7: > Scheduling works by having the client store iCalendar data with > appropriate scheduling properties included ("ORGANIZER" and > "ATTENDEE" iCalendar properties). This is called a "Scheduling > Operation" and fully described in Section 3. The server detects that > the data represents a scheduling operation (as per Section 3.1) and > identifies the operation as one initiated by the Organizer or > Attendee. Processing of the scheduling operation, then depends on > who is initiating the scheduling operation (as per Section 3.2.1 or > Section 3.2.2 respectively). In each case, one of three scheduling > operations can take place: "create", "modify" or "remove". Which > operation occurs is based on the HTTP method used for the request, as > well as a comparison between any existing iCalendar data and any new > iCalendar data in the request (as per Section 3.2.3). Let's be more clear about about the theory of operation specified in this document. Suggest reword along the following lines: In order to automate the process of scheduling, we define the term "scheduling operation" that consists of a client storing an iCal VEVENT in a CALDAV store and then the server taking specific actions in response. In each case... (and lop off "as per.."). Also add one sentence here about atomicity (or lack thereof) of the operations. §1, pg. 7: > Control over who is allowed to send scheduling messages, or from whom > scheduling messages will be received or freebusy results returned to, > is controlled via a set of access control privileges dedicated to the > various scheduling operations that can occur as per Section 6. Suggest active tense reword as follows: > Section 6 describes access authorization mechanisms for the various > scheduling operations that this memo specifies. §1.1, ppg 7-8: No need to restate definitions from other documents– unless you see a difference in the meaning of the term amongst documents. In particular, I see that you chose to reference RFC-3283 instead of RFC-5546 for Calendar User. 3283 would be a downref if you referenced it normatively. The definition should be normative. You want 5546. Also see nit on this. §1.3 pg 9: I've asked Mark Nottingham for an additional set of eyes on this section. I have one immediate comment and question: > This document inherits, and sometimes extends, DTD productions from > Section 14 of [RFC4918]. I would reword- "This document inherits and extends DTD productions..." If so, should this specification update RFC4918 in rfc-index.txt? §2.1, pg 10, and similar text in §2.2, pg 11: > The following WebDAV properties specified in CalDAV "calendar-access" > [RFC4791] MAY also be defined on scheduling... Do you mean "*Only* the following WebDAV..."? If not, why state these properties? §2.1.1, pg 11, and similar text in §2.2.1, pg 13, §2,4,1, pg 14, and similar: > PROPFIND behavior: This property SHOULD NOT be returned by a > PROPFIND allprop request (as defined in Section 14.2 of > [RFC4918]). Why SHOULD NOT and not MUST NOT? How should the client interpret the information, if returned? §3.2.1.1, pg 18: > When a scheduling object resource is created by the Organizer, the > server will inspect each "ATTENDEE" property to determine if a > scheduling message ought to be delivered to this Attendee according > to the value of the "SCHEDULE-AGENT" property parameter (see > Section 7.1) as described in the table below: Please use normative language and active tense. Suggest rewording as follows: > When the Organizer creates a scheduling object resource, the server SHALL > inspect each "ATTENDEE" property to determine whether to send a scheduling > message. Table XXX below indicates the appropriate action, based on > the value > of the "SCHEDULE-AGENT" property. §3.2.1.1 AND in §3.2.1.2 and §3.2.1.3: Why are you treating authorization differently between create & modify operations and the remove operation? Cannot the text in §3.2.1.1 and §3.2.1.2 simply be moved into the chapeau (e.g., 3.2.1)? Also see nit below on tables. §3.2.1.2, pg 19 has similar, but more involved issues to §3.2.1.1: > When a scheduling object resource is modified by the Organizer, the > server will inspect each "ATTENDEE" property in the new calendar data > to determine which ones have the "SCHEDULE-AGENT" iCalendar property > parameter. It will then need to compare this with the "ATTENDEE" > properties in the existing calendar object resource that is being > modified. > For each Attendee in the old and new calendar data on a per-instance > basis, and taking into account the addition or removal of Attendees, > the server will determine whether to deliver a scheduling message to > the Attendee. The following table determines whether the server > needs to deliver a scheduling message, and if so which iTIP > scheduling method to use. The values "SERVER", "CLIENT", and "NONE" > in the top and left titles of the table refer to the "SCHEDULE-AGENT" > parameter value of the "ATTENDEE" property, and the values "" > and "" are used to cover the cases where the "ATTENDEE" > property is not present (Old) or is being removed (New). So.. active tense again, same sort of idea: > When the Organizer modifies a scheduling object resource, the server SHALL > inspect each "ATTENDEE" property in both the original and modified > event instance > to determine whether to send a scheduling message. Table XXX below > indicates the > appropriate action, based on the value of the "SCHEDULE-AGENT" property. > The values "SERVER", "CLIENT", and "NONE" in the top and left headings > refer to the "SCHEDULE-AGENT" parameter value of the "ATTENDEE" property. > The the values "" and "" are used to cover the cases > where the > "ATTENDEE" property is not present (Old) or is being removed (New). The use of the word ATTENDEE in the upper left-hand corner of the table is confusing, and I would remove it. I might also change the headings to read "Original" (going down)" and "Modified". This allows for consistency of language. §3.2.1.3, Rinse and repeat this exercise for "Remove": > When a scheduling object resource is removed by the Organizer, the > server will inspect each "ATTENDEE" property in the scheduling object > resource being removed to determine which ones have the "SCHEDULE- > AGENT" iCalendar property parameter. > > For each Attendee the server will determine whether to attempt to > deliver a scheduling message into the Attendee's scheduling Inbox > collection, based on the table below: So... > When an Organizer removes a scheduling object resource, the server SHALL > inspect each "ATTENDEE" property in the scheduling object resource being > removed, and act based on the value of the "SCHEDULE-AGENT" property > value, > according to Table XXX below. §3.2.2.3, pg 23: > If the Attendee adds an "EXDATE" property value to effectively remove > a recurrence instance, the server MUST deliver an iTIP "REPLY" > scheduling message to the Organizer to indicate that the Attendee has > declined the instance. EXDATE isn't the only way an Attendee can decline. a specific event, right? Is this the only operation in which a server MUST act? Why call this one out? §3.2.3.2, pg 25, in the COPY table, and 3.2.3.3, pg 26, the MOVE table" : Remove (1) and replace with "Same as PUT in Table XXX" Also, move DELETE above MOVE (removes forward reference) and then remove (2) and replace with "Same as DELETE") In all of these sections change to both active tense and normative language. So for instance: Old: > When a MOVE method request is received, the server will execute New: > When the server receives a MOVE request, it SHALL execute §3.2.9, pg 32: > The 1.xx "REQUEST-STATUS" codes are new. This specification modifies > item (2) of Section 3.6 of [RFC5546] by adding the following > restriction: > Should this memo indicate that it updates RFC-5546? §3.2.10.1, §3.2.10.1, pg 34: Change "Clients can" to "Clients MAY" Nits: §1, pg. 6: > This is called a "Scheduling > Operation" and fully described in Section 3 Missing verb "is". Throughout: Calendar User is not capitalized consistently. Throughout: Tables should be numbered for reference. --------------060200040200060309080607 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see  http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).

Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft.

Document:  draft-desruisseaux-caldav-sched-11
Title: CalDAV Scheduling Extensions to WebDAV
Reviewer: Eliot Lear
Review Date: 8 Mar. 2012
IESG Telechat Date: 15 Mar 2012

Summary:

This is a marked improvement from the previous version, represents YET ANOTHER very valuable contribution from these two authors, and is nearly ready for publication.  I would suggest one more respin.  I believe this could happen, however, AFTER the IESG discussion.

Major Issues:

A question: can the new status codes defined in this specification leak to non-participating implementations in Reply operations?


Minor Issues:

In general the document suffers from a lack of conciseness.  What follows are some of the more glaring examples.

In Section 1, 2nd paragraph, There is no need to describe so early what functions aren't covered.  The way this is traditionally handled is to have a "Future Work" section.  That can be done in the intro or it can even be put after examples.  I prefer the latter, especially if you mean for the text to be non-normative.  If it is meant to be normative, be explicit about it.

Similarly, in the 4th paragraph, same section, it is sufficient to say (above) that this mechanism works compatibly with iMIP. You're using a double negative.  And this problem recurs in the same paragraph.  You should consider a search on the word "not".

§1, pg 6:
   In iTIP-based scheduling, there is an event "Organizer" whose role is
   to schedule an event between one or more "Attendees", and this is
   done by sending out invitations and handling responses from each
   Attendee.  Often times an Organizer will do a "freebusy" lookup to
   check on Attendees' availability (free-time).

This document needn't and shouldn't repeat or review iTIP.  Suggest remove.

   Servers supporting this specification advertise their capabilities
   and provides new collections for scheduling operations as described
   in Section 2.

This is mundane and not needed in § 1.  Suggest you cut it.

§1, ppg 6-7:

   Scheduling works by having the client store iCalendar data with
   appropriate scheduling properties included ("ORGANIZER" and
   "ATTENDEE" iCalendar properties).  This is called a "Scheduling
   Operation" and fully described in Section 3.  The server detects that
   the data represents a scheduling operation (as per Section 3.1) and
   identifies the operation as one initiated by the Organizer or
   Attendee.  Processing of the scheduling operation, then depends on
   who is initiating the scheduling operation (as per Section 3.2.1 or
   Section 3.2.2 respectively).  In each case, one of three scheduling
   operations can take place: "create", "modify" or "remove".  Which
   operation occurs is based on the HTTP method used for the request, as
   well as a comparison between any existing iCalendar data and any new
   iCalendar data in the request (as per Section 3.2.3).

Let's be more clear about about the theory of operation specified in this document.  Suggest reword along the following lines:

In order to automate the process of scheduling, we define the term "scheduling operation" that consists of a client storing an iCal VEVENT in a CALDAV store and then the server taking specific actions in response.  In each case... (and lop off "as per..").

Also add one sentence here about atomicity (or lack thereof) of the operations.


§1, pg. 7:
   Control over who is allowed to send scheduling messages, or from whom
   scheduling messages will be received or freebusy results returned to,
   is controlled via a set of access control privileges dedicated to the
   various scheduling operations that can occur as per Section 6.

Suggest active tense reword as follows:
Section 6 describes access authorization mechanisms for the various scheduling operations that this memo specifies.
§1.1, ppg 7-8:

No need to restate definitions from other documents– unless you see a difference in the meaning of the term amongst documents.  In particular, I see that you chose to reference RFC-3283 instead of RFC-5546 for Calendar User.  3283 would be a downref if you referenced it normatively.  The definition should be normative.  You want 5546.

Also see nit on this.

§1.3 pg 9:

I've asked Mark Nottingham for an additional set of eyes on this section.  I have one immediate comment and question:

   This document inherits, and sometimes extends, DTD productions from
   Section 14 of [RFC4918].

I would reword- "This document inherits and extends DTD productions..."

If so, should this specification update RFC4918 in rfc-index.txt?

§2.1, pg 10, and similar text in §2.2, pg 11:

   The following WebDAV properties specified in CalDAV "calendar-access"
   [RFC4791] MAY also be defined on scheduling...

Do you mean "Only the following WebDAV..."?  If not, why state these properties?

§2.1.1, pg 11, and similar text in §2.2.1, pg 13, §2,4,1, pg 14, and similar:

   PROPFIND behavior:  This property SHOULD NOT be returned by a
      PROPFIND allprop request (as defined in Section 14.2 of
      [RFC4918]).

Why SHOULD NOT and not MUST NOT?  How should the client interpret the information, if returned?

§3.2.1.1, pg 18:

   When a scheduling object resource is created by the Organizer, the
   server will inspect each "ATTENDEE" property to determine if a
   scheduling message ought to be delivered to this Attendee according
   to the value of the "SCHEDULE-AGENT" property parameter (see
   Section 7.1) as described in the table below:

Please use normative language and active tense.  Suggest rewording as follows:

When the Organizer creates a scheduling object resource, the server SHALL
inspect each "ATTENDEE" property to determine whether to send a scheduling
message.  Table XXX below indicates the appropriate action, based on the value
of the "SCHEDULE-AGENT" property.

§3.2.1.1 AND in §3.2.1.2 and §3.2.1.3:

Why are you treating authorization differently between create & modify operations and the remove operation?

Cannot the text in §3.2.1.1 and §3.2.1.2 simply be moved into the chapeau (e.g., 3.2.1)?


Also see nit below on tables.



§3.2.1.2, pg 19 has similar, but more involved issues to §3.2.1.1:

   When a scheduling object resource is modified by the Organizer, the
   server will inspect each "ATTENDEE" property in the new calendar data
   to determine which ones have the "SCHEDULE-AGENT" iCalendar property
   parameter.  It will then need to compare this with the "ATTENDEE"
   properties in the existing calendar object resource that is being
   modified.
   For each Attendee in the old and new calendar data on a per-instance
   basis, and taking into account the addition or removal of Attendees,
   the server will determine whether to deliver a scheduling message to
   the Attendee.  The following table determines whether the server
   needs to deliver a scheduling message, and if so which iTIP
   scheduling method to use.  The values "SERVER", "CLIENT", and "NONE"
   in the top and left titles of the table refer to the "SCHEDULE-AGENT"
   parameter value of the "ATTENDEE" property, and the values "<Absent>"
   and "<Removed>" are used to cover the cases where the "ATTENDEE"
   property is not present (Old) or is being removed (New).


So.. active tense again, same sort of idea:

When the Organizer modifies a scheduling object resource, the server SHALL
inspect each "ATTENDEE" property in both the original and modified event instance
to determine whether to send a scheduling message.  Table XXX below indicates the
appropriate action, based on the value of the "SCHEDULE-AGENT" property.
The values "SERVER", "CLIENT", and "NONE" in the top and left headings
refer to the "SCHEDULE-AGENT"  parameter value of the "ATTENDEE" property.
The the values "<Absent>"  and "<Removed>" are used to cover the cases where the
 "ATTENDEE" property is not present (Old) or is being removed (New).

The use of the word ATTENDEE in the upper left-hand corner of the table is confusing, and I would remove it.  I might also change the headings to read "Original" (going down)" and "Modified".  This allows for consistency of language.


§3.2.1.3, Rinse and repeat this exercise for "Remove":


   When a scheduling object resource is removed by the Organizer, the
   server will inspect each "ATTENDEE" property in the scheduling object
   resource being removed to determine which ones have the "SCHEDULE-
   AGENT" iCalendar property parameter.

   For each Attendee the server will determine whether to attempt to
   deliver a scheduling message into the Attendee's scheduling Inbox
   collection, based on the table below:

So...

When an Organizer removes a scheduling object resource, the server SHALL
inspect each "ATTENDEE" property in the scheduling object resource being
removed, and act based on the value of the "SCHEDULE-AGENT" property value,
according to Table XXX below.

§3.2.2.3, pg 23:

   If the Attendee adds an "EXDATE" property value to effectively remove
   a recurrence instance, the server MUST deliver an iTIP "REPLY"
   scheduling message to the Organizer to indicate that the Attendee has
   declined the instance.

EXDATE isn't the only way an Attendee can decline. a specific event, right?  Is this the only operation in which a server MUST act?  Why call this one out?

§3.2.3.2, pg 25, in the COPY table, and 3.2.3.3, pg 26, the MOVE table" :

Remove (1) and replace with "Same as PUT in Table XXX"

Also, move DELETE above MOVE (removes forward reference) and then remove (2) and replace with "Same as DELETE")

In all of these sections change to both active tense and normative language.  So for instance:

Old:
 When a MOVE method request is received, the server will execute
New:
When the server receives a MOVE request, it SHALL execute
§3.2.9, pg 32:

   The 1.xx "REQUEST-STATUS" codes are new.  This specification modifies
   item (2) of Section 3.6 of [RFC5546] by adding the following
   restriction:


Should this memo indicate that it updates RFC-5546?


§3.2.10.1, §3.2.10.1, pg 34:

Change "Clients can" to "Clients MAY"

Nits:

§1, pg. 6:

This is called a "Scheduling
   Operation" and fully described in Section 3
Missing verb "is".

Throughout:

Calendar User is not capitalized consistently.

Throughout:

Tables should be numbered for reference.

--------------060200040200060309080607-- From ht@inf.ed.ac.uk Thu Mar 8 03:45:36 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B21F921F8648; Thu, 8 Mar 2012 03:45:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZ2943PhRPfp; Thu, 8 Mar 2012 03:45:35 -0800 (PST) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id 9761F21F8647; Thu, 8 Mar 2012 03:45:34 -0800 (PST) Received: from nutty.inf.ed.ac.uk (nutty.inf.ed.ac.uk [129.215.33.33]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id q28BifJH019389; Thu, 8 Mar 2012 11:44:46 GMT Received: from calexico.inf.ed.ac.uk (calexico.inf.ed.ac.uk [129.215.24.15]) by nutty.inf.ed.ac.uk (8.13.8/8.13.8) with ESMTP id q28BiemO013576; Thu, 8 Mar 2012 11:44:40 GMT Received: from calexico.inf.ed.ac.uk (localhost [127.0.0.1]) by calexico.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id q28BiejW003264; Thu, 8 Mar 2012 11:44:40 GMT Received: (from ht@localhost) by calexico.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id q28BidJX003259; Thu, 8 Mar 2012 11:44:39 GMT X-Authentication-Warning: calexico.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Barry Leiba References: <90C41DD21FB7C64BB94121FBBC2E723453AFCD4076@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Thu, 08 Mar 2012 11:44:39 +0000 In-Reply-To: (Barry Leiba's message of "Wed, 7 Mar 2012 18:53:37 -0500") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.4.21 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 Cc: "apps-discuss@ietf.org" , "oauth@ietf.org" , "dr@fb.com" , Justin Richer , "dick.hardt@gmail.com" Subject: Re: [apps-discuss] [OAUTH-WG] FW: Appsdir review of draft-ietf-oauth-v2-23 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Mar 2012 11:45:36 -0000 Barry Leiba writes: > Henry says... >>> No, I appreciate that you want to use registered short names in >>> the protocol, that's just fine.  My problem is that you have left >>> users, developers etc. with no way to discover what shortnames >>> have been registered short of a non- trivial and error-prone >>> informal search effort. >>> . . . > > Eran says... >> Not sure I understand what you are asking for, but what would the >> IANA instruction include to support this? > > Yeh, I'm not understanding this either. The spec establishes an > access-token-type registry, and anyone will be able to look in that > registry the same way they look in any other IANA registry, such as > media-types. It looks like Henry is asking for this to use some sort > of type/subtype mechanism, as media-types does, wherein when a new > token type is registered, that registration or subsequent ones can > create subtypes of that token type. No, sorry, not at all about subtyping or anyting like that. Sorry this is proving difficult to communicate! Start again. Consider the situation five years from now, when OAUTH2 is a great success, and there are dozens of entries in its various registries. 1) Suppose you're a developer, setting out to implement OAUTH2. You need to know what access token types, etc. to implement; 2) Or you're a user, wondering what access token types are available, so you can decide which suit your requirements best; 3) Or you're a service provider, and you come up with a new token type and want to check if the name you have in mind is already in use. You have read the spec., and the _only_ concrete thing it tells you about the registers is the name of an email list. So you have to go to the email archives and search for . . . what exactly? Different in the three cases above, and in none of them is it obvious how to know what counts as success. So what I'm asking for is more mechanism, documented in the spec. in terms of what the registry itself will provide, which is, in each case, a URI which will not only resolve to a list of the registered shortnames, but will also support retrieval for any registered short name by appending it. So for example for the access token type registry, the spec. should tell me that retrieving  http://www.iana.org/oath2/access-token-types will give me a page listing all the registered access token types, and also  http://www.iana.org/oath2/access-token-types/bearer will return the registration details for the bearer type. This will then make all of (1)--(3) easy. Better this time? ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From julian.reschke@gmx.de Thu Mar 8 04:35:22 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E08C121F85F4 for ; Thu, 8 Mar 2012 04:35:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.435 X-Spam-Level: X-Spam-Status: No, score=-104.435 tagged_above=-999 required=5 tests=[AWL=-1.836, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gSHnuUQn4HJV for ; Thu, 8 Mar 2012 04:35:20 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 131C721F85AA for ; Thu, 8 Mar 2012 04:35:13 -0800 (PST) Received: (qmail invoked by alias); 08 Mar 2012 12:35:12 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp004) with SMTP; 08 Mar 2012 13:35:12 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1807YsMX5U0pduSz0KA4konmAZcjJzMvr1u4Ly+v0 0l1HUD1VLbOyPF Message-ID: <4F58A77A.6090706@gmx.de> Date: Thu, 08 Mar 2012 13:35:06 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Eliot Lear References: <4F588C9D.2090403@cisco.com> In-Reply-To: <4F588C9D.2090403@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: draft-desruisseaux-caldav-sched.all@tools.ietf.org, Mark Nottingham , Peter Saint-Andre , 'IESG' , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Applications Directorate Review of draft-desruisseaux-caldav-sched-11 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Mar 2012 12:35:22 -0000 On 2012-03-08 11:40, Eliot Lear wrote: > ... >> This document inherits, and sometimes extends, DTD productions from >> Section 14 of [RFC4918]. > > I would reword- "This document inherits and extends DTD productions..." > > If so, should this specification update RFC4918 in rfc-index.txt? This is similar to other specs building on WebDAV, and we haven't done that (saying "updates") before. > §2.1.1, pg 11, and similar text in §2.2.1, pg 13, §2,4,1, pg 14, and > similar: > >> PROPFIND behavior: This property SHOULD NOT be returned by a >> PROPFIND allprop request (as defined in Section 14.2 of >> [RFC4918]). > > Why SHOULD NOT and not MUST NOT? How should the client interpret the > information, if returned? SHOULD NOT is right; returning it does no harm. Also, it's consistent with other WebDAV specs. Having SHOULD NOT in one place and MUST NOT somewhere else would be awkward. > Throughout: > > Tables should be numbered for reference. If this is supposed to be a general rule, I would object to it. It's a matter of style, and thus should be discussed in the RFC style manual, if it ever gets updated. Best regards, Julian From lear@cisco.com Thu Mar 8 05:18:42 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4313621F8685; Thu, 8 Mar 2012 05:18:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.546 X-Spam-Level: X-Spam-Status: No, score=-110.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wh1j18p6UjVR; Thu, 8 Mar 2012 05:18:41 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8F621F8668; Thu, 8 Mar 2012 05:18:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=1378; q=dns/txt; s=iport; t=1331212721; x=1332422321; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=/VqbGu4/4b/5CNMfJdOYqKsguJxvtGxfLJfuaNOY3uQ=; b=YLqeUFD6qcOfh3OxEUTFVsuFu34+FIHw1wMXslQdO93xCI8fYj72eACf f/iDoyz410l+353vE1X/ETV4ynGmpxbzc42VXpO17Y0atXjqV2i8i3jMJ Z9IVVEiVDMu7jIkTNlHEDGgM5NYkjzJoZ+sU1jt+EA9QtWXnop4ZrVcZy w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoIFAPuwWE+Q/khN/2dsb2JhbABDhTWsVoMTgQeCCgEBAQMBEgEQDwFGEAsYAgIFIQICDwJGBg0BBwEBHodjBZsuAYxnkjOBL44pgRYElUWQGIJk X-IronPort-AV: E=Sophos;i="4.73,552,1325462400"; d="scan'208";a="67988869" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 08 Mar 2012 13:18:39 +0000 Received: from dhcp-10-55-89-64.cisco.com (dhcp-10-55-89-64.cisco.com [10.55.89.64]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q28DIdFe010641; Thu, 8 Mar 2012 13:18:39 GMT Message-ID: <4F58B1AF.20008@cisco.com> Date: Thu, 08 Mar 2012 14:18:39 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Julian Reschke References: <4F588C9D.2090403@cisco.com> <4F58A77A.6090706@gmx.de> In-Reply-To: <4F58A77A.6090706@gmx.de> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: draft-desruisseaux-caldav-sched.all@tools.ietf.org, Mark Nottingham , Peter Saint-Andre , 'IESG' , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Applications Directorate Review of draft-desruisseaux-caldav-sched-11 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Mar 2012 13:18:42 -0000 On 3/8/12 1:35 PM, Julian Reschke wrote: > On 2012-03-08 11:40, Eliot Lear wrote: >> ... >>> This document inherits, and sometimes extends, DTD productions from >>> Section 14 of [RFC4918]. >> >> I would reword- "This document inherits and extends DTD productions..." >> >> If so, should this specification update RFC4918 in rfc-index.txt? > > This is similar to other specs building on WebDAV, and we haven't done > that (saying "updates") before. > >> §2.1.1, pg 11, and similar text in §2.2.1, pg 13, §2,4,1, pg 14, and >> similar: >> >>> PROPFIND behavior: This property SHOULD NOT be returned by a >>> PROPFIND allprop request (as defined in Section 14.2 of >>> [RFC4918]). >> >> Why SHOULD NOT and not MUST NOT? How should the client interpret the >> information, if returned? > > SHOULD NOT is right; returning it does no harm. Also, it's consistent > with other WebDAV specs. Having SHOULD NOT in one place and MUST NOT > somewhere else would be awkward. Great. What's the client behavior if it sees it? > >> Throughout: >> >> Tables should be numbered for reference. > > If this is supposed to be a general rule, I would object to it. It's a > matter of style, and thus should be discussed in the RFC style manual, > if it ever gets updated. No it's not. It's for internal referencing. Eliot From julian.reschke@greenbytes.de Thu Mar 8 05:25:35 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDFDB21F86A4; Thu, 8 Mar 2012 05:25:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1+qrL+Lkmmul; Thu, 8 Mar 2012 05:25:35 -0800 (PST) Received: from donbot.greenbytes.de (mail.greenbytes.de [217.91.35.233]) by ietfa.amsl.com (Postfix) with ESMTP id 256D321F8691; Thu, 8 Mar 2012 05:25:34 -0800 (PST) Received: from [192.168.1.140] (unknown [217.91.35.233]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by donbot.greenbytes.de (Postfix) with ESMTPSA id 0DE55C4C0E8; Thu, 8 Mar 2012 14:25:29 +0100 (CET) Message-ID: <4F58B347.1030101@greenbytes.de> Date: Thu, 08 Mar 2012 14:25:27 +0100 From: Julian Reschke Organization: greenbytes GmbH User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Eliot Lear References: <4F588C9D.2090403@cisco.com> <4F58A77A.6090706@gmx.de> <4F58B1AF.20008@cisco.com> In-Reply-To: <4F58B1AF.20008@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "apps-discuss@ietf.org" , Julian Reschke , draft-desruisseaux-caldav-sched.all@tools.ietf.org, Peter Saint-Andre , Mark Nottingham , 'IESG' Subject: Re: [apps-discuss] Applications Directorate Review of draft-desruisseaux-caldav-sched-11 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Mar 2012 13:25:35 -0000 On 2012-03-08 14:18, Eliot Lear wrote: > > > On 3/8/12 1:35 PM, Julian Reschke wrote: >> On 2012-03-08 11:40, Eliot Lear wrote: >>> ... >>>> This document inherits, and sometimes extends, DTD productions from >>>> Section 14 of [RFC4918]. >>> >>> I would reword- "This document inherits and extends DTD productions..." >>> >>> If so, should this specification update RFC4918 in rfc-index.txt? >> >> This is similar to other specs building on WebDAV, and we haven't done >> that (saying "updates") before. >> >>> §2.1.1, pg 11, and similar text in §2.2.1, pg 13, §2,4,1, pg 14, and >>> similar: >>> >>>> PROPFIND behavior: This property SHOULD NOT be returned by a >>>> PROPFIND allprop request (as defined in Section 14.2 of >>>> [RFC4918]). >>> >>> Why SHOULD NOT and not MUST NOT? How should the client interpret the >>> information, if returned? >> >> SHOULD NOT is right; returning it does no harm. Also, it's consistent >> with other WebDAV specs. Having SHOULD NOT in one place and MUST NOT >> somewhere else would be awkward. > > Great. What's the client behavior if it sees it? Essentially, the client didn't ask for the property but the server has sent it anyway. The client can throw it away, or keep it for later use (the latter case would be an edge case, because if the client had been interested, it would have asked for the property right away). >>> Throughout: >>> >>> Tables should be numbered for reference. >> >> If this is supposed to be a general rule, I would object to it. It's a >> matter of style, and thus should be discussed in the RFC style manual, >> if it ever gets updated. > > No it's not. It's for internal referencing. I just checked the spec and couldn't see any case where the tables being numbered would have made referencing them easier. IMHO, "the table below" is more helpful as "table NN" and then having the tables being numbered. Things would be different if the references were more complex, or in a more complex presentation where tables might be moved around (which we do not do in RFCs). Best regards, Julian -- bytes GmbH, Hafenweg 16, D-48155 Münster, Germany Amtsgericht Münster: HRB5782 From lear@cisco.com Thu Mar 8 05:52:45 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4BBB21F84D6; Thu, 8 Mar 2012 05:52:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.547 X-Spam-Level: X-Spam-Status: No, score=-110.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5+2o87CMO2ur; Thu, 8 Mar 2012 05:52:45 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id AB75221F84D2; Thu, 8 Mar 2012 05:52:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=2369; q=dns/txt; s=iport; t=1331214765; x=1332424365; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=DY9xL5lVR9aeyzF5F6yXOAYtlADO8hzL8t/57nhEToE=; b=ONCEcWcjae9M02sZm/kaTv8kFBo0iK+uNLrG3O/yo1vUWH5IfdbLCauW QN/YK2W5Q3iSp0m2l1BQN7KyVA+sQxTbMfXwEb1nHlEpZbet4BnkEOX2c rxSQQWX07+GKRGO2QEUCtCDrqmEKMcAPzu0p2MemYRaC6erRvvrNmlUW5 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoMFAIu4WE+Q/khL/2dsb2JhbABDhTWsVoMTgQeCCgEBAQQSARAPAUUBEAsYAgIFFgsCAgkDAgECAUUGDQEHAQEeh2ibIwGMZ5I4gS+OKYEWBJVFkBiCZA X-IronPort-AV: E=Sophos;i="4.73,552,1325462400"; d="scan'208";a="131708279" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 08 Mar 2012 13:52:43 +0000 Received: from dhcp-10-55-89-64.cisco.com (dhcp-10-55-89-64.cisco.com [10.55.89.64]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q28DqhF5004462; Thu, 8 Mar 2012 13:52:43 GMT Message-ID: <4F58B9AA.5020902@cisco.com> Date: Thu, 08 Mar 2012 14:52:42 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Julian Reschke References: <4F588C9D.2090403@cisco.com> <4F58A77A.6090706@gmx.de> <4F58B1AF.20008@cisco.com> <4F58B347.1030101@greenbytes.de> In-Reply-To: <4F58B347.1030101@greenbytes.de> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "apps-discuss@ietf.org" , Julian Reschke , draft-desruisseaux-caldav-sched.all@tools.ietf.org, Peter Saint-Andre , Mark Nottingham , 'IESG' Subject: Re: [apps-discuss] Applications Directorate Review of draft-desruisseaux-caldav-sched-11 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Mar 2012 13:52:45 -0000 Julian, Please read my review where I suggest text that references tables. Eliot On 3/8/12 2:25 PM, Julian Reschke wrote: > On 2012-03-08 14:18, Eliot Lear wrote: >> >> >> On 3/8/12 1:35 PM, Julian Reschke wrote: >>> On 2012-03-08 11:40, Eliot Lear wrote: >>>> ... >>>>> This document inherits, and sometimes extends, DTD productions >>>>> from >>>>> Section 14 of [RFC4918]. >>>> >>>> I would reword- "This document inherits and extends DTD >>>> productions..." >>>> >>>> If so, should this specification update RFC4918 in rfc-index.txt? >>> >>> This is similar to other specs building on WebDAV, and we haven't done >>> that (saying "updates") before. >>> >>>> §2.1.1, pg 11, and similar text in §2.2.1, pg 13, §2,4,1, pg 14, and >>>> similar: >>>> >>>>> PROPFIND behavior: This property SHOULD NOT be returned by a >>>>> PROPFIND allprop request (as defined in Section 14.2 of >>>>> [RFC4918]). >>>> >>>> Why SHOULD NOT and not MUST NOT? How should the client interpret the >>>> information, if returned? >>> >>> SHOULD NOT is right; returning it does no harm. Also, it's consistent >>> with other WebDAV specs. Having SHOULD NOT in one place and MUST NOT >>> somewhere else would be awkward. >> >> Great. What's the client behavior if it sees it? > > Essentially, the client didn't ask for the property but the server has > sent it anyway. The client can throw it away, or keep it for later use > (the latter case would be an edge case, because if the client had been > interested, it would have asked for the property right away). > >>>> Throughout: >>>> >>>> Tables should be numbered for reference. >>> >>> If this is supposed to be a general rule, I would object to it. It's a >>> matter of style, and thus should be discussed in the RFC style manual, >>> if it ever gets updated. >> >> No it's not. It's for internal referencing. > > I just checked the spec and couldn't see any case where the tables > being numbered would have made referencing them easier. > > IMHO, "the table below" is more helpful as "table NN" and then having > the tables being numbered. Things would be different if the references > were more complex, or in a more complex presentation where tables > might be moved around (which we do not do in RFCs). > > Best regards, Julian > > From barryleiba.mailing.lists@gmail.com Thu Mar 8 06:50:39 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 216D521F86B2; Thu, 8 Mar 2012 06:50:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.985 X-Spam-Level: X-Spam-Status: No, score=-102.985 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wneCz8ooeztv; Thu, 8 Mar 2012 06:50:38 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4130D21F867E; Thu, 8 Mar 2012 06:50:31 -0800 (PST) Received: by yhpp34 with SMTP id p34so266218yhp.31 for ; Thu, 08 Mar 2012 06:50:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=znLGOONItsG7O0DL5MS8JS30AYedN96VpLxeVLeciGI=; b=KyUWpaWHLFprwDGeQx+bVfkoKojD7tuF/eixcT1SJDHKGoivXKUDEyH9Cj6YUAmBr6 q7VVUiFQaeUN9K1rJY2hkN/+LjKBaSkywDFk62K2VnpPZBmzjXo0Gfxv6sYx4Z3+nEIe ka5k8u1IKgyRnpIboSz1d4hp0yXwr1E7GlRpY+8KBNvLTVDh0f0Ro2iW5wvQC/eO7LZl MHfyVdZfQkHoIGGQZ0638yLja1L8qIpMhiRRv2rT0uc4DOJlXvxdbEqDD5qeKxctu9v0 LM3d15jfGx8PEiAJ+ZOGhsZc/WAhe1a/mHAZqBgsIf906/QcpX3ukXl21PFKBlaysfRF c5dw== MIME-Version: 1.0 Received: by 10.236.186.1 with SMTP id v1mr11401653yhm.4.1331218230000; Thu, 08 Mar 2012 06:50:30 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.106.16 with HTTP; Thu, 8 Mar 2012 06:50:29 -0800 (PST) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E723453AFCD4076@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 8 Mar 2012 09:50:29 -0500 X-Google-Sender-Auth: x1Ovk_RoB4LPHAPq1kor495P6no Message-ID: From: Barry Leiba To: "Henry S. Thompson" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "dr@fb.com" , "oauth@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [OAUTH-WG] FW: Appsdir review of draft-ietf-oauth-v2-23 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Mar 2012 14:50:39 -0000 > You have read the spec., and the _only_ concrete thing it tells you > about the registers is the name of an email list. =A0So you have to go > to the email archives and search for . . . what exactly? =A0Different in > the three cases above, and in none of them is it obvious how to know > what counts as success. The email list is just how you start the registration process. There will be an IANA registry for access token types. When IANA creates it, the name will be in the published RFC (I expect there'll be a section in the IANA registries page ( http://www.iana.org/protocols/ ) for "OAuth Parameters", and "Access Token Types" will be listed there; search that page for "DKIM" to see what it'll look like). The spec also says what will be *in* the registry. The RFC Editor specifically does NOT want the URL for the registry to be in the RFC (the URL might change). But the registry NAME will be there. Barry From ht@inf.ed.ac.uk Thu Mar 8 07:05:37 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10D3021F86BA; Thu, 8 Mar 2012 07:05:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kfqjwCDmnfgI; Thu, 8 Mar 2012 07:05:35 -0800 (PST) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id 059BD21F8551; Thu, 8 Mar 2012 07:05:20 -0800 (PST) Received: from nutty.inf.ed.ac.uk (nutty.inf.ed.ac.uk [129.215.33.33]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id q28F56Ie018790; Thu, 8 Mar 2012 15:05:06 GMT Received: from calexico.inf.ed.ac.uk (calexico.inf.ed.ac.uk [129.215.24.15]) by nutty.inf.ed.ac.uk (8.13.8/8.13.8) with ESMTP id q28F56vS021035; Thu, 8 Mar 2012 15:05:06 GMT Received: from calexico.inf.ed.ac.uk (localhost [127.0.0.1]) by calexico.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id q28F56Wh007733; Thu, 8 Mar 2012 15:05:06 GMT Received: (from ht@localhost) by calexico.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id q28F55sD007728; Thu, 8 Mar 2012 15:05:05 GMT X-Authentication-Warning: calexico.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Barry Leiba References: <90C41DD21FB7C64BB94121FBBC2E723453AFCD4076@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Thu, 08 Mar 2012 15:05:05 +0000 In-Reply-To: (Barry Leiba's message of "Thu, 8 Mar 2012 09:50:29 -0500") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.4.21 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 Cc: "dr@fb.com" , "oauth@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [OAUTH-WG] FW: Appsdir review of draft-ietf-oauth-v2-23 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Mar 2012 15:05:37 -0000 Barry Leiba writes: >> You have read the spec., and the _only_ concrete thing it tells you >> about the registers is the name of an email list.  So you have to go >> to the email archives and search for . . . what exactly?  Different in >> the three cases above, and in none of them is it obvious how to know >> what counts as success. > > The email list is just how you start the registration process. There > will be an IANA registry for access token types. When IANA creates > it, the name will be in the published RFC (I expect there'll be a > section in the IANA registries page ( http://www.iana.org/protocols/ ) > for "OAuth Parameters", and "Access Token Types" will be listed there; > search that page for "DKIM" to see what it'll look like). The spec > also says what will be *in* the registry. > > The RFC Editor specifically does NOT want the URL for the registry to > be in the RFC (the URL might change). But the registry NAME will be > there. OK, I now recognise a culture clash as the underlying point at issue, so this spec. is the wrong place to address it. Thanks for your patience, I hereby get out of the road on this point. I'll reply to Eran's message wrt any other outstanding points. . . ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From barryleiba@gmail.com Thu Mar 8 07:10:08 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58F8021F85DB; Thu, 8 Mar 2012 07:10:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.985 X-Spam-Level: X-Spam-Status: No, score=-102.985 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IDZpbh9ALuMR; Thu, 8 Mar 2012 07:10:07 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9ABC821F8604; Thu, 8 Mar 2012 07:10:07 -0800 (PST) Received: by obbta4 with SMTP id ta4so886264obb.31 for ; Thu, 08 Mar 2012 07:10:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=3J1Im/GiMtiATrixmUfahKNCeQbOvuvD6ILPoablnNQ=; b=f6YXAdhXddwteJ9/n9uwab9w6c4p/WheL0LcozgD1x2ZpiSfy1bQyW4hE7c8Z9DhWI zENDY6k0S1M9c+lLU4ZJ/TASC/yYAjK1S0srzt/Lpx19iCPygnzII4iSjnj1dVmAltmd l8LAk4I6whSTOeWqhRmhYXyjdw3xMEIkxtRL8jIcAzN319ysoz8jJof/x26m1j69ZVL4 UOtJwBDsD7rIOsJN53xgtaAaKIT5sQBgl1RlmAT5ne9x5DCj2XyW622WQuTOrLTR1eK5 PQ1ZRUu2Y81fFQIdukbwNeNJeP46kjo0VfMSi06dCOzw4RVTIiJqKOaSiRN++HQdZi4P DKEg== MIME-Version: 1.0 Received: by 10.182.225.69 with SMTP id ri5mr251720obc.74.1331219407266; Thu, 08 Mar 2012 07:10:07 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.60.125.37 with HTTP; Thu, 8 Mar 2012 07:10:07 -0800 (PST) In-Reply-To: References: <90C41DD21FB7C64BB94121FBBC2E723453AFCD4076@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Thu, 8 Mar 2012 10:10:07 -0500 X-Google-Sender-Auth: HngQ-PbSdvN3j6XCYJyT1tj2qH0 Message-ID: From: Barry Leiba To: "Henry S. Thompson" Content-Type: text/plain; charset=ISO-8859-1 Cc: "dr@fb.com" , "oauth@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [OAUTH-WG] FW: Appsdir review of draft-ietf-oauth-v2-23 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Mar 2012 15:10:08 -0000 > OK, I now recognise a culture clash as the underlying point at issue, > so this spec. is the wrong place to address it. Ah... so if the issue is how IANA makes registry information available, then please go to the "happiana" mailing list ( https://www.ietf.org/mailman/listinfo/happiana ) and see if you can work with Michelle and the other IANA folks on it. Barry From ht@inf.ed.ac.uk Thu Mar 8 07:13:17 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92A2A21F8763; Thu, 8 Mar 2012 07:13:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gODZmQ2QeO5W; Thu, 8 Mar 2012 07:13:17 -0800 (PST) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id A0DA521F8642; Thu, 8 Mar 2012 07:13:16 -0800 (PST) Received: from nutty.inf.ed.ac.uk (nutty.inf.ed.ac.uk [129.215.33.33]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id q28FDDKe024732; Thu, 8 Mar 2012 15:13:13 GMT Received: from calexico.inf.ed.ac.uk (calexico.inf.ed.ac.uk [129.215.24.15]) by nutty.inf.ed.ac.uk (8.13.8/8.13.8) with ESMTP id q28FDCDY021329; Thu, 8 Mar 2012 15:13:12 GMT Received: from calexico.inf.ed.ac.uk (localhost [127.0.0.1]) by calexico.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id q28FDC5G007944; Thu, 8 Mar 2012 15:13:12 GMT Received: (from ht@localhost) by calexico.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id q28FDCZX007939; Thu, 8 Mar 2012 15:13:12 GMT X-Authentication-Warning: calexico.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Barry Leiba References: <90C41DD21FB7C64BB94121FBBC2E723453AFCD4076@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Thu, 08 Mar 2012 15:13:12 +0000 In-Reply-To: (Barry Leiba's message of "Thu, 8 Mar 2012 10:10:07 -0500") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.4.21 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 Cc: "dr@fb.com" , "oauth@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [OAUTH-WG] FW: Appsdir review of draft-ietf-oauth-v2-23 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Mar 2012 15:13:17 -0000 Barry Leiba writes: >> OK, I now recognise a culture clash as the underlying point at issue, >> so this spec. is the wrong place to address it. > > Ah... so if the issue is how IANA makes registry information > available Precisely. > then please go to the "happiana" mailing list ( > https://www.ietf.org/mailman/listinfo/happiana ) and see if you can > work with Michelle and the other IANA folks on it. Indeed. I should have realised that that was the right level sooner: as I said, thanks for your patience. ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From ht@inf.ed.ac.uk Thu Mar 8 07:14:57 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C70121F876C; Thu, 8 Mar 2012 07:14:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bkbYPnjQRIun; Thu, 8 Mar 2012 07:14:56 -0800 (PST) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id 5F3B521F873D; Thu, 8 Mar 2012 07:14:56 -0800 (PST) Received: from nutty.inf.ed.ac.uk (nutty.inf.ed.ac.uk [129.215.33.33]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id q28FBYce023042; Thu, 8 Mar 2012 15:11:34 GMT Received: from calexico.inf.ed.ac.uk (calexico.inf.ed.ac.uk [129.215.24.15]) by nutty.inf.ed.ac.uk (8.13.8/8.13.8) with ESMTP id q28FBX5n021206; Thu, 8 Mar 2012 15:11:34 GMT Received: from calexico.inf.ed.ac.uk (localhost [127.0.0.1]) by calexico.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id q28FBXae007918; Thu, 8 Mar 2012 15:11:33 GMT Received: (from ht@localhost) by calexico.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id q28FBWBV007914; Thu, 8 Mar 2012 15:11:32 GMT X-Authentication-Warning: calexico.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: Eran Hammer References: <90C41DD21FB7C64BB94121FBBC2E723453AFCD4077@P3PW5EX1MB01.EX1.SECURESERVER.NET> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Thu, 08 Mar 2012 15:11:32 +0000 In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453AFCD4077@P3PW5EX1MB01.EX1.SECURESERVER.NET> (Eran Hammer's message of "Wed, 7 Mar 2012 16:49:31 -0700") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.4.21 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 Cc: "barryleiba@gmail.com" , "apps-discuss@ietf.org" , "dick.hardt@gmail.com" , "iesg@ietf.org" , "dr@fb.com" Subject: Re: [apps-discuss] Appsdir review of draft-ietf-oauth-v2-23 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Mar 2012 15:14:57 -0000 Eran Hammer writes: > HST wrote: >> 3.1.2.1 The failure to require TLS here is worrying. At the very >> least I would expect a requirement that clients which do _not_ >> require TLS MUST provide significant user feedback calling >> attention to this -- by analogy, absence of a padlock does _not_ >> suffice. . . > > Added: > > If TLS is not available, the authorization server SHOULD warn > the end-user about the insecure endpoint prior to redirection. Good, thanks. >> 3.1.2.5 In a somewhat parallel case, I would expect this section to >> at least explain why the SHOULD NOT is not a MUST NOT. Since in >> practice the distinction between trusted and untrusted 3rd-party >> scripting is difficult if not impossible to draw, as written the >> 2nd para is effectively overriden by the third. > > New text replacing the last two paragraphs: > > The client SHOULD NOT include any third-party scripts > (e.g. third-party analytics, social plug-ins, ad networks) in > the redirection endpoint response. Instead, it SHOULD extract > the credentials from the URI and redirect the user-agent again > to another endpoint without exposing the credentials (in the > URI or elsewhere). If third-party scripts are included, the > client MUST NOT ensure that its own scripts (used to extract > and remove the credentials from the URI) will execute first. Good, thanks, but surely now "MUST NOT" --> "MUST" ? >> Minor Issues: >> >> A short summary of the changes from OAuth 1.0/RFC5849 would have been >> helpful, and it might still be a good idea to add one. . . > > Not possible. Two different protocols. OK, fair enough -- but even a two sentence statement to that effect, in order to defeat naive expectations such as mine, that they _are_ related, would be helpful. >> 4.1 Would it be helpful to indicate that steps D&E may occur at any >> time after C, and may be repeated subsequently? > > That's not always right. Some servers may choose to time limit the > delay between C and D. Elsewhere in the document, D is stated as > allowed only once. Hmm, OK, not obvious to the first-time reader, which is why I thought a clarification would be helpful . . . >> 11.1 It might be useful to have an 11.1.2, which repeats references to the >> bearer and mac access token type registration drafts? > > Maybe. We'll see how all these progress before AUTH48. Can easily > add those then. Fair enough. I'm satisfied, given the above changes. ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From ted.ietf@gmail.com Thu Mar 8 07:45:06 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3C2121F85F2 for ; Thu, 8 Mar 2012 07:45:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.65 X-Spam-Level: X-Spam-Status: No, score=-3.65 tagged_above=-999 required=5 tests=[AWL=-0.051, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id unXC93iSwRil for ; Thu, 8 Mar 2012 07:45:06 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 85CC021F864E for ; Thu, 8 Mar 2012 07:45:04 -0800 (PST) Received: by vcbfk13 with SMTP id fk13so563420vcb.31 for ; Thu, 08 Mar 2012 07:45:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4H2uJ2MS1raGYTMNW0q2qzax/a8ILkSio/CK34kHg60=; b=CSbTKHlnLzINySOSN0CVPTNuZ/ifL2X+7zdOvaZFppGevWTxDkYlXer79y+m19iUx+ SzTaaimqmfro8IJtMS/6pr3NY7YIy51Yr+zb88AHlK0QOTPNMBLpFXFlPwGq+1R7YTJd gGfTsHy9lSUdN3z2L7gux2ac7QVmYj0zAJ7JhWbEyEBvEk8cp+6J/yTSZO1wlc0EmQc9 WuArogqtjJyuHCB6s28DyRoaPKQ3kpm03stuONQRdqKlnt525ps93xMTP+tlDDR6I9+A 3PgxKt9MwiZD4p9DbWtOw3151fWP4ha/klvhBDO8v5OWJx3Saj4n9+dVh1dI+muqHh1G 0kZg== MIME-Version: 1.0 Received: by 10.52.26.20 with SMTP id h20mr10704858vdg.3.1331221503828; Thu, 08 Mar 2012 07:45:03 -0800 (PST) Received: by 10.52.115.66 with HTTP; Thu, 8 Mar 2012 07:45:03 -0800 (PST) In-Reply-To: References: Date: Thu, 8 Mar 2012 07:45:03 -0800 Message-ID: From: Ted Hardie To: Walter Content-Type: text/plain; charset=ISO-8859-1 Cc: Barry Leiba , apps-discuss@ietf.org Subject: Re: [apps-discuss] Proposal for a Finance Area Mailing List X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Mar 2012 15:45:07 -0000 On Wed, Mar 7, 2012 at 4:47 PM, Walter wrote: >> Walter, what we're looking for here is some public discussion that >> results in at least some reasonable level of understanding about what >> would be discussed on the mailing list you propose, > > Is it really necessary to have people already participating in this > mailing list express interest in order to justify a new list on a > specific subject? Whilst I can understand the tradition, this does > seem like a bit of a paradox to me: surely interested parties are to > be drawn to such a mailing list from related corners of the wider > internet community? So, there may be some missing history here. Some time ago, the IETF had a working group called TRADE (archives visible here: http://lists.elistx.com/archives/ietf-trade/) that produced IOTP (RFC 2801, 2802, 2803, along with some updates, including errata published in RFC 3504). Though it had sufficient activity to produce some documents, it did not seem to get a lot of use with version 1 and version 2 languished because working group was so low (a handful of folks in the room low). It eventually got shut down because there were simply too few people engaged to call consensus on the results. For areas that are new to the IETF or for which previous engagement did not produce a lot of results, it does make sense to me to ask for a demonstration that there is a community of interest in the work. Donald Eastlake, who chaired TRADE, may have more insight. regards, Ted Hardie From cyrus@daboo.name Thu Mar 8 07:51:53 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36BF521F86F4; Thu, 8 Mar 2012 07:51:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.631 X-Spam-Level: X-Spam-Status: No, score=-102.631 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iTf-7GKcoyn7; Thu, 8 Mar 2012 07:51:52 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id 1239C21F86F8; Thu, 8 Mar 2012 07:51:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 61C0423329DB; Thu, 8 Mar 2012 10:51:49 -0500 (EST) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gWPDNAhMAXRP; Thu, 8 Mar 2012 10:51:47 -0500 (EST) Received: from [17.45.162.181] (unknown [17.45.162.181]) by daboo.name (Postfix) with ESMTPSA id A0BD823329CB; Thu, 8 Mar 2012 10:51:44 -0500 (EST) Date: Thu, 08 Mar 2012 10:51:47 -0500 From: Cyrus Daboo To: Eliot Lear , Julian Reschke Message-ID: In-Reply-To: <4F58B9AA.5020902@cisco.com> References: <4F588C9D.2090403@cisco.com> <4F58A77A.6090706@gmx.de> <4F58B1AF.20008@cisco.com> <4F58B347.1030101@greenbytes.de> <4F58B9AA.5020902@cisco.com> X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=1023 Cc: apps-discuss@ietf.org, Julian Reschke , draft-desruisseaux-caldav-sched.all@tools.ietf.org, Peter Saint-Andre , Mark Nottingham , 'IESG' Subject: Re: [apps-discuss] Applications Directorate Review of draft-desruisseaux-caldav-sched-11 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Mar 2012 15:51:53 -0000 Hi Eliot, --On March 8, 2012 2:52:42 PM +0100 Eliot Lear wrote: > Please read my review where I suggest text that references tables. Just on this one point: 1) There is only ever one table per section in the draft, so a reference to a table can be reasonably provided as "the table in Section XXX". 2) Most the the tables are defined using xml2rfc elements. However, some tables are too complex for xml2rfc's table layout, and hence are implemented as ascii-art in a
. That poses a problem when using xml2rfc's built-in references because references appear as "Table 1", whereas
references appear as "Figure 1". That would mean we had a mixture of different reference labels. Now, it is possible to change all the current elements to be ascii art instead, but given point #1 above, I would rather not have to do that. So bottom line, my preference is to use a reference of the form described in #1 above whenever needed. -- Cyrus Daboo From paul.hoffman@vpnc.org Thu Mar 8 08:01:39 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58A3421F8555 for ; Thu, 8 Mar 2012 08:01:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.701 X-Spam-Level: X-Spam-Status: No, score=-102.701 tagged_above=-999 required=5 tests=[AWL=-0.102, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ijIX9Hz8ak6N for ; Thu, 8 Mar 2012 08:01:38 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 0914021F8546 for ; Thu, 8 Mar 2012 08:01:36 -0800 (PST) Received: from [10.20.30.101] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.3) with ESMTP id q28G1Ix6066161 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 8 Mar 2012 09:01:19 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: Date: Thu, 8 Mar 2012 08:01:18 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <20776EAF-5ADB-40B8-A31E-DBA329A61CF8@vpnc.org> References: To: Ted Hardie X-Mailer: Apple Mail (2.1257) Cc: Barry Leiba , apps-discuss@ietf.org Subject: Re: [apps-discuss] Proposal for a Finance Area Mailing List X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Mar 2012 16:01:39 -0000 Similarly, there was sufficient interest in the early EDI work, which = had a similar audience to what is proposed here, but then that too fell = into a situation of too few participants to be able to determine a = meaningful consensus. --Paul Hoffman From dhc@dcrocker.net Thu Mar 8 08:10:49 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9F1821F8505 for ; Thu, 8 Mar 2012 08:10:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.606 X-Spam-Level: X-Spam-Status: No, score=-6.606 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zO9JUMzD63HB for ; Thu, 8 Mar 2012 08:10:49 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3027921F8516 for ; Thu, 8 Mar 2012 08:10:49 -0800 (PST) Received: from [192.168.1.11] (adsl-67-127-58-62.dsl.pltn13.pacbell.net [67.127.58.62]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q28GAfaj015833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Mar 2012 08:10:47 -0800 Message-ID: <4F58D9F3.2000602@dcrocker.net> Date: Thu, 08 Mar 2012 08:10:27 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Walter References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Thu, 08 Mar 2012 08:10:47 -0800 (PST) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Proposal for a Finance Area Mailing List X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 16:10:50 -0000 Walter, On 3/7/2012 4:47 PM, Walter wrote: >> and, importantly, what IETF work might come out of it. > Being new to IETF processes in general, I can shed no light on this. > Certainly the establishment of some IANA registries. While it's reasonable not to know what details will or should be produced, it's a bit challenging to come to a forum asking for its community to participate in an activity, without having a pretty solid sense of what that activity will do. Stated differently, what problems are to be solved by this activity and who will work on them? (Stating the former is meant to recruit statements of interest from the latter.) > Financial industry groups are not the right forum for this development > as they are top-heavy with a massive, indisputable interest in > maintaining the status quo. You know about IANA registries but appear not to know that statements like above are counterproductive in the IETF (and most other places.) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dhc@dcrocker.net Thu Mar 8 08:15:21 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EFB321F855B for ; Thu, 8 Mar 2012 08:15:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.606 X-Spam-Level: X-Spam-Status: No, score=-6.606 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kVEd4MepFL09 for ; Thu, 8 Mar 2012 08:15:20 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id C18CD21F8555 for ; Thu, 8 Mar 2012 08:15:20 -0800 (PST) Received: from [192.168.1.11] (adsl-67-127-58-62.dsl.pltn13.pacbell.net [67.127.58.62]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q28GFFq0016036 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 8 Mar 2012 08:15:20 -0800 Message-ID: <4F58DB05.9020901@dcrocker.net> Date: Thu, 08 Mar 2012 08:15:01 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20776EAF-5ADB-40B8-A31E-DBA329A61CF8@vpnc.org> In-Reply-To: <20776EAF-5ADB-40B8-A31E-DBA329A61CF8@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Thu, 08 Mar 2012 08:15:20 -0800 (PST) Subject: Re: [apps-discuss] Proposal for a Finance Area Mailing List X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 16:15:21 -0000 On 3/8/2012 8:01 AM, Paul Hoffman wrote: > Similarly, there was sufficient interest in the early EDI work, which had a similar audience to what is proposed here, but then that too fell into a situation of too few participants to be able to determine a meaningful consensus. The early EDI work produced a working group and a successor working group, participation and specifications: RFC6362, Multiple Attachments for Electronic Data Interchange - Internet Integration (EDIINT) K. Meadors, Ed. August 2011 ASCII INFORMATIONAL RFC6359, Datatracker Extensions to Include IANA and RFC Editor Processing Information S. Ginoza, M. Cotton, A. Morris September 2011 ASCII INFORMATIONAL RFC6017, Electronic Data Interchange - Internet Integration (EDIINT) Features Header Field RFC5402, Compressed Data within an Internet Electronic Data Interchange (EDI) Message T. Harding, E RFC1865, EDI Meets the Internet Frequently Asked Questions about Electronic Data Interchange (EDI) on the Internet W. Houser, J. Griffin, C. Hage January 1996 ASCII INFORMATIONAL RFC1767, MIME Encapsulation of EDI Objects D. Crocker -- Dave Crocker Brandenburg InternetWorking bbiw.net From stpeter@stpeter.im Thu Mar 8 09:27:24 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC75A21F866E; Thu, 8 Mar 2012 09:27:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.761 X-Spam-Level: X-Spam-Status: No, score=-102.761 tagged_above=-999 required=5 tests=[AWL=-0.162, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5iKo7jnwgt2; Thu, 8 Mar 2012 09:27:23 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E199C21F84E7; Thu, 8 Mar 2012 09:27:23 -0800 (PST) Received: from squire.local (unknown [64.101.72.114]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8D5C240058; Thu, 8 Mar 2012 10:39:26 -0700 (MST) Message-ID: <4F58EBFA.7010904@stpeter.im> Date: Thu, 08 Mar 2012 10:27:22 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: William Mills References: <1331188315.87259.YahooMailNeo@web31816.mail.mud.yahoo.com> In-Reply-To: <1331188315.87259.YahooMailNeo@web31816.mail.mud.yahoo.com> X-Enigmail-Version: 1.3.5 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "draft-ietf-appsawg-xdash.all@tools.ietf.org" , The IESG , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-appswg-xdash-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Mar 2012 17:27:24 -0000 Hi Bill, thanks for the review. A few comments inline. On 3/7/12 11:31 PM, William Mills wrote: > > > Document: draft-ietf-appswg-xdash-03 Title: Deprecating Use of the > "X-" Prefix in Application Protocols Reviewer: William J. Mills > Review Date: March 6th, 2012 IETF Last Call Date: unknown IESG > Telechat Date: unknown > > Summary: This draft is generally ready for publication, there are > some small issues that might be worth adjusting. > > Major Issues: > > > Minor Issues: > > Section 4.5 through 4.7: I would change '"X-" prefix' to '"X-" or > similar prefix' Good point. In our working copy, I have changed those instances to: the "X-" prefix or similar constructions (as we have in the Introduction) > Nits: > > Appendix B, numeral 1 and 3, second sentence: I would strike > "However, " and start the sentences "In this case..." Done in our working copy. > - This draft uses the "$statement. However, $argument_against" > construction a lot, and I find that somewhat clunky. I suppose it is a bit of beating people over the head. Nevertheless, I find it clearer to use conjunctive adverbs such as "However". > However, I > doubt it's worth fixing. ;-) > - The references are populated primarily with things from the > appendices. It would make more sense to me if references came last, > but I think that breaks the standard format rules. Yes, it does. Alternatively, we could move the appendices to informational sections before the references if we felt that would help. Peter -- Peter Saint-Andre https://stpeter.im/ From Jeff.Hodges@KingsMountain.com Thu Mar 8 09:41:14 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5609021F8585 for ; Thu, 8 Mar 2012 09:41:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.373 X-Spam-Level: X-Spam-Status: No, score=-99.373 tagged_above=-999 required=5 tests=[AWL=-0.367, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ihukuaduZo-4 for ; Thu, 8 Mar 2012 09:41:13 -0800 (PST) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [IPv6:2605:dc00:100:2::a2]) by ietfa.amsl.com (Postfix) with SMTP id C16DF21F8550 for ; Thu, 8 Mar 2012 09:41:13 -0800 (PST) Received: (qmail 12581 invoked by uid 0); 8 Mar 2012 17:41:13 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy9.bluehost.com with SMTP; 8 Mar 2012 17:41:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=PRssfvhExRzURJO9oZ5SU/Y28PGmsPLZjGkEgK4+MGo=; b=mCZU9wzpxDATyxByiSmj1uMs103UWb0my/8eCd7UYfZYE8u582AhuWffbyHYdxSrVNn0Yw9JdP4hp1jVBaos52SqPLB2ekVVbaEh5YzRBE1gby/hk1fpnVOZwFmZSckT; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.137.56]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1S5hKy-0001O1-Aa for apps-discuss@ietf.org; Thu, 08 Mar 2012 10:41:12 -0700 Message-ID: <4F58EF37.8010802@KingsMountain.com> Date: Thu, 08 Mar 2012 09:41:11 -0800 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: Apps Discuss Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: Re: [apps-discuss] Proposal for a Finance Area Mailing List X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Mar 2012 17:41:14 -0000 In addition to the previously mentioned EDI and IOTP work, there was also this back in the late 1990s.. CyberCash Credit Card Protocol Version 0.8 file:///home/hodges/doc/IETF/rfc/rfc1898.txt ECML v1: Field Names for E-Commerce file:///home/hodges/doc/IETF/rfc/rfc2706.txt ECML v1.1: Field Specifications for E-Commerce file:///home/hodges/doc/IETF/rfc/rfc3106.txt ..and then fwiw, it's not clear what happened to these expired I-Ds.. draft-eastlake-internet-payment draft-eastlake-universal-payment draft-hallam-micropayment-01 Donald Eastlake and Steve Crocker were involved in the above work (they were apparently affiliated with CyberCash at the time). They'd likely have some input into this discussion (as has been noted). A separate but related question is whether "financial-protocol" folk need different underlying protocols, for transport/transfer of this particular type of data and notifications, than what is extant (and implemented & shipping) today (e.g., HTTP, TLS/SSL, SCTP, XMPP, etc.). If not, then perhaps they might concentrate on the stuff at their "financial" layer and concoct "bindings" to the existing underlying stuff (eg, as we did in SAML & Liberty (to HTTP)) as appropriate, and they then could perhps more easily work on their "financial" layer whereever (eg, W3C, OASIS, SomeNew.org, etc). The overall key is (as has been noted in this thread) getting a critical mass of subject matter experts to show up with the cycles/commitment to accomplishing something. So one should select a venue that such folk are most likely to participate in. That may or may not be the IETF (Your Mileage May Vary..) HTH, =JeffH From dhc@dcrocker.net Thu Mar 8 09:43:48 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E051821F86C6; Thu, 8 Mar 2012 09:43:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.606 X-Spam-Level: X-Spam-Status: No, score=-6.606 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OF3yVw+vgp-8; Thu, 8 Mar 2012 09:43:48 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id F04A721F858D; Thu, 8 Mar 2012 09:43:47 -0800 (PST) Received: from [192.168.1.11] (adsl-67-127-58-62.dsl.pltn13.pacbell.net [67.127.58.62]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q28HhfUa018352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Mar 2012 09:43:46 -0800 Message-ID: <4F58EFBF.8030908@dcrocker.net> Date: Thu, 08 Mar 2012 09:43:27 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Peter Saint-Andre References: <1331188315.87259.YahooMailNeo@web31816.mail.mud.yahoo.com> <4F58EBFA.7010904@stpeter.im> In-Reply-To: <4F58EBFA.7010904@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Thu, 08 Mar 2012 09:43:47 -0800 (PST) Cc: "draft-ietf-appsawg-xdash.all@tools.ietf.org" , William Mills , The IESG , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-appswg-xdash-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 17:43:49 -0000 On 3/8/2012 9:27 AM, Peter Saint-Andre wrote: >> Section 4.5 through 4.7: I would change '"X-" prefix' to '"X-" or >> similar prefix' > > Good point. In our working copy, I have changed those instances to: > > the "X-" prefix or similar constructions I apologize for not noting this issue earlier. The document has become a set of rules about /any/ naming method that distinguishes standard from non-standard. It's no longer constrained to "X-". As such I suggest changing it's name to something like Deprecating Specialized Naming for Non-Standard Values (X- and Similar Constructs) I like to have titles help document searching and organizing. >> - The references are populated primarily with things from the >> appendices. It would make more sense to me if references came last, >> but I think that breaks the standard format rules. > > Yes, it does. Alternatively, we could move the appendices to > informational sections before the references if we felt that would help. Nah. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From barryleiba@gmail.com Thu Mar 8 09:45:01 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42CC321F8469 for ; Thu, 8 Mar 2012 09:45:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.985 X-Spam-Level: X-Spam-Status: No, score=-102.985 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kzPhOnTrGCqL for ; Thu, 8 Mar 2012 09:45:00 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4616721F85C5 for ; Thu, 8 Mar 2012 09:45:00 -0800 (PST) Received: by yhpp34 with SMTP id p34so437506yhp.31 for ; Thu, 08 Mar 2012 09:44:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=/l6vY82iCQXQF8K4SHkX1TY902gYcukvoTTXuW61co8=; b=L70sHCYTOkXreXUr+pU+hM7W1Wx88YTI2t/ezN20wg7fBWoanIh8CpNrLk33Fd2WNh 1Db5CmSpcaUg+mvnR6pi0BNAIRdzrAisNM79je1G4Tam94bXFwbj/1lcNLD60LhGmt9D xGMh/5mFtgn0+4vvN0CcshKzQcnKo+TAdnjmR9+9vPM0PQBGM1hTYm/hnXI6SLWdd81n cMsaUHe9JjmsPHHAAZ01YCR6gMwRsY9UkOsikJ97AFNJojmiuiVISRWqhq3rHET4NZ1r wfRTy7zVzxymJrLR2A4GcGON4X3wka2aHWD5NEHFiUbfJl3gMWB1gDqrv1dUHBWhyNB2 b2YA== MIME-Version: 1.0 Received: by 10.60.7.70 with SMTP id h6mr2760425oea.44.1331228699507; Thu, 08 Mar 2012 09:44:59 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.60.125.37 with HTTP; Thu, 8 Mar 2012 09:44:59 -0800 (PST) Date: Thu, 8 Mar 2012 12:44:59 -0500 X-Google-Sender-Auth: y7PneE0-HkVaRDgv1N0Z-OHRpu0 Message-ID: From: Barry Leiba To: Apps Discuss Content-Type: text/plain; charset=ISO-8859-1 Subject: [apps-discuss] Reminder: Contacting the chairs and ADs X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Mar 2012 17:45:01 -0000 Because we'll be doing a change in chairs and ADs during the Paris meeting, I'll note that if you contact the chairs or ADs by sending email to our addresses directly, you encounter two problems: (1) You leave the new chairs/ADs out. (2) You include someone who's not a chair/AD any more. This is especially the case if there's an old message hanging around that you reply to after things change. You can fix this by *always* using the tools alias when you need to contact the chairs or ADs of this or any working group: Use those instead of our individual email addresses. Replace "appsawg" with the name of another working group to contact that group's chairs or ADs. And don't forget the "tools." in there. Barry, AppsAWG chair for a couple more weeks, then App AD From carine@jay.w3.org Thu Mar 8 09:47:12 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B45A21F8486 for ; Thu, 8 Mar 2012 09:47:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z0cLxzFYpUUF for ; Thu, 8 Mar 2012 09:47:11 -0800 (PST) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 74F9B21F8469 for ; Thu, 8 Mar 2012 09:47:11 -0800 (PST) Received: from carine by jay.w3.org with local (Exim 4.69) (envelope-from ) id 1S5hQj-0001IS-US; Thu, 08 Mar 2012 12:47:09 -0500 Date: Thu, 8 Mar 2012 12:47:09 -0500 From: Carine Bournez To: Zach Shelby Message-ID: <20120308174709.GK23228@jay.w3.org> References: <20120305094330.27895.2135.idtracker@ietfa.amsl.com> <20120308083354.GJ23228@jay.w3.org> <73EF8185-649D-43DB-95FD-513210F21D1C@sensinode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <73EF8185-649D-43DB-95FD-513210F21D1C@sensinode.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: General discussion of application-layer protocols Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-shelby-exi-registration-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Mar 2012 17:47:12 -0000 Hi, On Thu, Mar 08, 2012 at 11:33:21AM +0200, Zach Shelby wrote: > > I agree that the EXI header should be used to convey the EXI specific options needed to decode the payload (I got a similar comment on the CoRE list). The SchemaID field is not very useful on its own however, so the goal of this text should be that the media type registration for +exi needs to define what to place in the SchemaID field of the header. It needs to point to a specification of the schemas, and how the value in the SchemaID field corresponds to them. It may also e.g. define a default schema to use if the SchemaID field is elided. This is an important aspect to the efficiency of EXI for M2M applications, where often our EXI payloads are only tens of bytes long. Placing a 30-50 byte URI reference to the XSD in the header of that EXI payload would be unacceptable, however a short integer ID or such is OK. > Specifying the schemaID format for a foo+exi media type is indeed an interesting idea, this is not what I understood from your draft text. In any case, a MUST requirement for that is probably too strong. > I am fine with removing the text that implies the media type alone identifies the schema. However the media type does define the semantics and meaning of the data carried in the payload once it is decoded (regardless of the schema version or variation). Changing the text to something clearer about specifying schemaID, and possibly about the use of EXI extension points (datatype representation maps), would be useful as interop consideration.. > > A +exi suffix might help conveying the original media type *and* the > > encoding whenever the content-encoding header is not available > > in a protocol. However, the suffix should not try to replace some of > > the existing EXI mechanisms at all. > > Right, and in particular the +exi suffix is only meant to be used in cases where content-encoding is not being performed, in other words Schema-informed mode is used and there is no intermediate use of XML. For other use cases this document should recommend the use of the exi content-encoding or the generic application/exi media type. "there is no intermediate use of XML" is a bit obscure to me, EXI *is* XML. If you mean no text serialization of XML, I don't see the relation with the ability or not to use the content-encoding. The content-encoding is also not reserved to schema-informed mode. -- Carine Bournez -+- W3C Europe From touch@isi.edu Thu Mar 8 09:57:18 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A124D21F86B5; Thu, 8 Mar 2012 09:57:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.943 X-Spam-Level: X-Spam-Status: No, score=-102.943 tagged_above=-999 required=5 tests=[AWL=-0.344, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dyQOVjRR+Y0D; Thu, 8 Mar 2012 09:57:18 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id A9DCA21F86B1; Thu, 8 Mar 2012 09:57:17 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id q28Hums2004384 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 8 Mar 2012 09:56:48 -0800 (PST) Message-ID: <4F58F2E1.4010401@isi.edu> Date: Thu, 08 Mar 2012 09:56:49 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Ted Hardie References: <4F578169.7040408@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: draft-ietf-intarea-ipv4-id-update.all@tools.ietf.org, IESG , apps-discuss@ietf.org Subject: Re: [apps-discuss] APPS directorate review of ietf-intarea-ipv4-id-update X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Mar 2012 17:57:18 -0000 Hi, Ted, Agreed on your suggested change - thanks! Please let me know - and I'll also check with the ADs - whether these changes require a revision before proceeding or can be handled during AUTH48. Joe On 3/7/2012 11:26 AM, Ted Hardie wrote: > Hi Joe, > > Thanks for your quick reply; comments in-line. > > On Wed, Mar 7, 2012 at 7:40 AM, Joe Touch wrote: >> >>> Minor Issues: [list any minor issues such as text that is unclear or >>> confusing, preferably by section number] >>> >>> In section 6, the inclusion of the mathematical expression for which >>> datagrams were atomic vs. non-atomic did not seem to add anything to >>> the clarity of the surrounding text. By introducing several >>> abbreviations and reviewing the logical operators, it seemed to >>> complicate what appeared to be a very clear statement: Atomic >>> datagrams are those which are not fragmented now and for which later >>> fragmentation is inhibited; non-atomic datagrams are those that either >>> are fragmented or which may later be fragmented. >> >> >> The equations are intended to be pseudocode, to define atomicity in terms of >> specific tests on IP header fields. This helps clarify the interpretation of >> the English definition to help coders. We can clarify that by replacing >> "mathematical expression" with "pseudocode". >> >> Would that clarify the utility of the expressions? Should we also explain >> the rationale for including them in a single sentence? >> > > If you will retain them, I think it should be stated more explicitly > that the expressions are simply a restatement of the textual > definitions. Perhaps: > > OLD: > > Atomic datagrams: datagrams not yet fragmented (MF=0 and fragment > offset=0) and for which further fragmentation has been inhibited > (DF=1), i.e., as a mathematical expression (equals is ==, logical > 'and' is&&, logical 'or' is ||, greater than is>, logical 'not' > is ~, and parenthesis function typically): > > (DF==1)&&(MF==0)&&(frag_offset==0) > > o Non-atomic datagrams: datagrams which have either already been > fragmented, i.e.: > > (MF=1)||(frag_offset>0) > > or for which fragmentation remains possible: > > (DF==0) > > I.e., non-atomic datagrams can be expressed in two equivalent > tests: > > (DF==0)||(MF==1)||(frag_offset>0) > > which can also be expressed as follows, using DeMorgan's Law and > other identities: > > ~((DF==1)&&(MF==0)&&(frag_offset==0)) > > Note that this final expression is the same as "not(atomic)". > > NEW: > > Atomic datagrams are datagrams not yet fragmented and for which > further fragmentation has been inhibited. > > Non-atomic datagrams are datagrams which either have already been > fragmented or for which fragmentation remains possible. > > This same definition can be expressed in pseudo code as using common > logical operators (equals is ==, logical 'and' is&&, logical 'or' is > ||, greater than is>, logical 'not' is ~, and parenthesis function > typically) as: > > atomic datagrams: (DF==1)&&(MF==0)&&(frag_offset==0) > > non-atomic datagrams: (DF==0)||(MF==1)||(frag_offset>0) > >> > That works much better - thanks! >>> In section 10, the document states: >>> >>> When compression assumes a changing ID as a default, having a non- >>> changing ID can make compression less efficient (see footnote 21 of >>> [RFC1144] or >>> cRTP [RFC2508]). >>> >>> The text of footnote 21 is: >>> >>> Note that the test here is against one, not zero. The packet ID is >>> typically incremented by one for each packet sent so a change of zero >>> is >>> very unlikely. A change of one is likely: It occurs during any period >>> when the originating system has activity on only one connection. >>> >>> I was expecting the footnote to contain data that referred to >>> compression efficiency; >>> perhaps some additional context is needed? >> >> >> We could change that to "less efficient. Such non-changing IDs have been >> described in various RFCs (e.g., footnote 21 of [RFC1144 and cRTP >> [RFC2508])." >> >> Would that be more clear? >> > > Yes, that's clearer, From stpeter@stpeter.im Thu Mar 8 09:59:56 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB3EC21F86D5; Thu, 8 Mar 2012 09:59:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.75 X-Spam-Level: X-Spam-Status: No, score=-102.75 tagged_above=-999 required=5 tests=[AWL=-0.151, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tsghWIUuGcEU; Thu, 8 Mar 2012 09:59:56 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id F15FE21F86D0; Thu, 8 Mar 2012 09:59:55 -0800 (PST) Received: from squire.local (unknown [64.101.72.114]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 89C554005B; Thu, 8 Mar 2012 11:11:58 -0700 (MST) Message-ID: <4F58F39A.9030401@stpeter.im> Date: Thu, 08 Mar 2012 10:59:54 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: dcrocker@bbiw.net References: <1331188315.87259.YahooMailNeo@web31816.mail.mud.yahoo.com> <4F58EBFA.7010904@stpeter.im> <4F58EFBF.8030908@dcrocker.net> In-Reply-To: <4F58EFBF.8030908@dcrocker.net> X-Enigmail-Version: 1.3.5 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "draft-ietf-appsawg-xdash.all@tools.ietf.org" , William Mills , The IESG , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-appswg-xdash-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Mar 2012 17:59:56 -0000 On 3/8/12 10:43 AM, Dave Crocker wrote: > > > On 3/8/2012 9:27 AM, Peter Saint-Andre wrote: >>> Section 4.5 through 4.7: I would change '"X-" prefix' to '"X-" or >>> similar prefix' >> >> Good point. In our working copy, I have changed those instances to: >> >> the "X-" prefix or similar constructions > > I apologize for not noting this issue earlier. > > The document has become a set of rules about /any/ naming method that > distinguishes standard from non-standard. It's no longer constrained to > "X-". > > As such I suggest changing it's name to something like > > Deprecating Specialized Naming for Non-Standard Values (X- and Similar > Constructs) > > I like to have titles help document searching and organizing. +1, good suggestion. Changed in our working copy. I've also done: s/constructions/constructs/g Peter -- Peter Saint-Andre https://stpeter.im/ From john-ietf@jck.com Thu Mar 8 10:01:53 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2C6621F8575; Thu, 8 Mar 2012 10:01:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.833 X-Spam-Level: X-Spam-Status: No, score=-102.833 tagged_above=-999 required=5 tests=[AWL=-0.234, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OvIf6cGQs4Jg; Thu, 8 Mar 2012 10:01:51 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id AC31021F84BD; Thu, 8 Mar 2012 10:01:51 -0800 (PST) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1S5haT-000AxZ-B0; Thu, 08 Mar 2012 12:57:13 -0500 Date: Thu, 08 Mar 2012 13:01:46 -0500 From: John C Klensin To: ietf@ietf.org Message-ID: In-Reply-To: <20120301184750.21152.93044.idtracker@ietfa.amsl.com> References: <20120301184750.21152.93044.idtracker@ietfa.amsl.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Last Call: (Deprecating Use of the "X-" Prefix in Application Protocols) to Best Current Practice X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Mar 2012 18:01:53 -0000 Hi. I realize I'm probably in the minority on this, but I think the document overstates its case a bit and, perhaps recognizing the actual complexity of the situation, even may contradict itself a bit. For example, I note that it says: (Section 1) "Therefore this document deprecates the "X-" convention for named parameters in application protocols" but (Section 4 (4)) "SHOULD identify a convention to allow local or implementation-specific extensions, and reserve delimeters for such uses as needed." presumably as long as those delimiters don't consist of "X-". While I believe that the general strategy of treating textual parameters as hierarchical (or consisting of subsets) so that private allocations can exist in a separate tree is a good one, I think we also need to recognize that "X-" is just one more way to make that division. If it not a wonderful one, and it carries around a lot of baggage, but neither justifies the amount of venom that has been directed toward it over the years nor some of the strong language of this document (which is much better than some of its earlier drafts in that respect). The reality is that, when "X-" has been used to identify purely private and/or implementation-specific parameters, it has not been a problem. It has been a problem for experimental parameters, but that is a different matter... and a distinction this document fails to make clearly enough, at least IMO. Overstating the case for something like this, e.g., by inserting MUST NOT language where there is little justification for more than "SHOULD NOT" won't be likely change the behavior of those creating or maintaining implementations. MUST NOTs that are ignored do nothing positive for the reputation or credibility of the IETF. I largely agree with Randy Gellens's reasoning about this. However, I don't think the choice of requirements language is a showstopper: I think it is a judgment call and that, unless there is a basis for strong consensus, judgment calls should generally be resolved in favor of a less-strong requirement. While Appendix A mentions the history of using "X" (without the dash) for experimental and private command names, the document does not address that issue at all. The second "primary objection" listed in Appendix B is, IMO, somewhat misstated. It would be more accurate to say, more or less, "Collisions are undesirable and it would be bad for a parameter 'foo' to designate two different sets of semantics, whether either of those sets is standard or not. The only ways to avoid that situation are for all parameters to be registered so that someone considering defining a new one can determine whether the name string is already in use _or_ for all parameters to contain a relatively-long randomly-generated substring to make the likelihood of accidental collision infinitesimal. The problem is that it is impossible to achieve universal registration despite the changes represented by more recent registration specifications, so there is some merit to being able to lexically distinguish private use (not to be accepted in interchange without out-of-band knowledge) parameter values from broader-use (and possibly standardized) ones." I note that no one has seriously proposed the "random substring" solution but, if we were serious about the problem for parameters users are unlikely to see, it is part of the logical solution space. Finally, the effect of this document is to update a rather large collection of existing specifications, not all of which are included in textual discussion or references. Those specifications are not listed in the text or in an "updates" header, much less called out in the Introduction and/or Abstract. Recommendations: (1) As suggested by several others, remove the "MUST" from Section 2, replacing it with "SHOULD". (2) Clarify whether this document is intended to deprecate giving special treatment to protocol commands starting in "X" rather than merely parameters starting in "X-" and why or why not. (3) Clarify the difference between "private-use" parameters, "implementation-specific" parameters, and "experimental" parameters. Strong language discouraging the latter is probably appropriate, but clearly-defined private uses may be reasonable (at least for some protocols), and implementation-specific parameters may fall somewhere in between. (4) Correct the explanation of the counterarguments as outlined above so that the document is not attacking straw men. (5) Either (i) explicitly identify the complete list of specifications that this one updates, doing so with all of the decorations that the IESG has required in other specifications, (ii) incorporate language into this specification and a revised Last Call that identifies the reasons why this specification is exempt, or (iii) clarify, before this document is approved, what the requirements (and "really strong suggestions") actually are in a way that makes it clear why they should not apply to documents of this type. Just my opinion. john --On Thursday, March 01, 2012 10:47 -0800 The IESG wrote: > > The IESG has received a request from the Applications Area > Working Group WG (appsawg) to consider the following document: > - 'Deprecating Use of the "X-" Prefix in Application Protocols' > as a Best Current Practice > > The IESG plans to make a decision in the next few weeks, and > solicits final comments on this action. Please send > substantive comments to the ietf@ietf.org mailing lists by > 2012-03-15. Exceptionally, comments may be sent to > iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > From cabo@tzi.org Thu Mar 8 10:07:03 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE4B321F86F1 for ; Thu, 8 Mar 2012 10:07:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.824 X-Spam-Level: X-Spam-Status: No, score=-105.824 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id akh67dbWz3r1 for ; Thu, 8 Mar 2012 10:07:02 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id BC15E21F86DE for ; Thu, 8 Mar 2012 10:06:42 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q28I6ZxE021468; Thu, 8 Mar 2012 19:06:35 +0100 (CET) Received: from eduroam-pool6-0466.wlan.uni-bremen.de (eduroam-pool6-0466.wlan.uni-bremen.de [134.102.25.210]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 334C33CD; Thu, 8 Mar 2012 19:06:35 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <20120308174709.GK23228@jay.w3.org> Date: Thu, 8 Mar 2012 19:06:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <977009AA-60F0-453F-8398-E297A7238692@tzi.org> References: <20120305094330.27895.2135.idtracker@ietfa.amsl.com> <20120308083354.GJ23228@jay.w3.org> <73EF8185-649D-43DB-95FD-513210F21D1C@sensinode.com> <20120308174709.GK23228@jay.w3.org> To: Carine Bournez X-Mailer: Apple Mail (2.1257) Cc: General discussion of application-layer protocols Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-shelby-exi-registration-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Mar 2012 18:07:04 -0000 On Mar 8, 2012, at 18:47, Carine Bournez wrote: > Specifying the schemaID format for a foo+exi media type is indeed an > interesting idea, this is not what I understood from your draft text. > In any case, a MUST requirement for that is probably too strong. Well, no. The point here is to have media types such that their instances can be = parsed by extremely constrained devices. The viability of such a format is pretty much proportional to the number = of MUSTS (well, inversely proportional to the number of choice points). *Any single* variability in the format may double the cost of decoding = it. Big-device (where a smartphone is a very big device) considerations just = don't apply for class-1 devices. Flexibility is overrated. Nail things down! Gr=FC=DFe, Carsten From lear@cisco.com Thu Mar 8 10:16:06 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79F6D21F86BB; Thu, 8 Mar 2012 10:16:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.547 X-Spam-Level: X-Spam-Status: No, score=-110.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jzHIP2SUv5Fg; Thu, 8 Mar 2012 10:16:05 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 0F36A21F86B9; Thu, 8 Mar 2012 10:16:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=1168; q=dns/txt; s=iport; t=1331230565; x=1332440165; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=MhOnzPN/cfVK5RgK1IiX88/pjp7KfjUcG1Tuwk74qTg=; b=DrwFMpUNpBlLu9NfUDVq80x/ET1JM9i/axvZtqNjrSrbM8OBSECkJmIM mYuPnHGXyXx9ltIclqIDZ26Iw+3GL7KXi6eSbM0wXk8ANjJzmsF7ZQksF aKTIoIMbS7pBgqJfqWobRQPZzdRztk+gPLqdbLEET2Ga4j7wTmzhma3SF Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAM72WE+Q/khN/2dsb2JhbABDhTWvb4EHggoBAQEDARIBEFUBEAsYAgIFFgsCAgkDAgECAUUGDQEFAgEBHodjBZs9AYxnkjOBL44pgRYElUWQGIJk X-IronPort-AV: E=Sophos;i="4.73,553,1325462400"; d="scan'208";a="131751150" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 08 Mar 2012 18:15:59 +0000 Received: from dhcp-10-55-89-64.cisco.com (dhcp-10-55-89-64.cisco.com [10.55.89.64]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q28IFwkv018154; Thu, 8 Mar 2012 18:15:59 GMT Message-ID: <4F58F75E.4060101@cisco.com> Date: Thu, 08 Mar 2012 19:15:58 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Cyrus Daboo References: <4F588C9D.2090403@cisco.com> <4F58A77A.6090706@gmx.de> <4F58B1AF.20008@cisco.com> <4F58B347.1030101@greenbytes.de> <4F58B9AA.5020902@cisco.com> In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org, Julian Reschke , Julian Reschke , draft-desruisseaux-caldav-sched.all@tools.ietf.org, Peter Saint-Andre , Mark Nottingham , 'IESG' Subject: Re: [apps-discuss] Applications Directorate Review of draft-desruisseaux-caldav-sched-11 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Mar 2012 18:16:06 -0000 Hi Cyrus, On 3/8/12 4:51 PM, Cyrus Daboo wrote: > Hi Eliot, > > --On March 8, 2012 2:52:42 PM +0100 Eliot Lear wrote: > >> Please read my review where I suggest text that references tables. > > Just on this one point: > > 1) There is only ever one table per section in the draft, so a > reference to a table can be reasonably provided as "the table in > Section XXX". > > 2) Most the the tables are defined using xml2rfc elements. > However, some tables are too complex for xml2rfc's table layout, and > hence are implemented as ascii-art in a
. That poses a problem > when using xml2rfc's built-in references because > references appear as "Table 1", whereas
references appear as > "Figure 1". That would mean we had a mixture of different reference > labels. Now, it is possible to change all the current > elements to be ascii art instead, but given point #1 above, I would > rather not have to do that. > > So bottom line, my preference is to use a reference of the form > described in #1 above whenever needed. > Ok. I feel your pain on this point. Eliot From ted.ietf@gmail.com Thu Mar 8 10:53:43 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE1521F8615; Thu, 8 Mar 2012 10:53:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.648 X-Spam-Level: X-Spam-Status: No, score=-3.648 tagged_above=-999 required=5 tests=[AWL=-0.049, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ic-LHaaVPucm; Thu, 8 Mar 2012 10:53:42 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9FEA121F8609; Thu, 8 Mar 2012 10:53:42 -0800 (PST) Received: by vbbez10 with SMTP id ez10so772625vbb.31 for ; Thu, 08 Mar 2012 10:53:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=KoJ2BEKE5vf4+wHB+IIoCCsZyHAKj77JWQuVSbgcU+U=; b=Kim+5WWpho9iQuPLRbmeXbzlGH7CWswvrtzAHUn5mhahtMuzpDKdlhZFywawD9Evpo NY7lJRgLfL3NGRvK810c409xtFUOaN3DAUQEHjqOaeVCdvR0AVmB6vAxR6Yke5wqLQTH K+u9P/qXABQASaUvWBRDAuwUktkuK5hkCdZaYIdiD06nCxmew3eCOZ18/LIBpF9lvdLq 8r1gzAlHmLT6++4I4B6OM5EBirYy6xP4ogASb4U2/wR/DLHaqkpfp/LQIKah9ndj0HOA /M8tXsR+ICKDq/ia5Ivlftzrfnc/D6cyIx+kPmM525d/1PBQGvq9sAJ1gpZn8qiGZiHQ XXyg== MIME-Version: 1.0 Received: by 10.52.71.114 with SMTP id t18mr11712109vdu.88.1331232822110; Thu, 08 Mar 2012 10:53:42 -0800 (PST) Received: by 10.52.115.66 with HTTP; Thu, 8 Mar 2012 10:53:42 -0800 (PST) In-Reply-To: <4F58F2E1.4010401@isi.edu> References: <4F578169.7040408@isi.edu> <4F58F2E1.4010401@isi.edu> Date: Thu, 8 Mar 2012 10:53:42 -0800 Message-ID: From: Ted Hardie To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: draft-ietf-intarea-ipv4-id-update.all@tools.ietf.org, IESG , apps-discuss@ietf.org Subject: Re: [apps-discuss] APPS directorate review of ietf-intarea-ipv4-id-update X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Mar 2012 18:53:43 -0000 On Thu, Mar 8, 2012 at 9:56 AM, Joe Touch wrote: > Hi, Ted, > > Agreed on your suggested change - thanks! > > Please let me know - and I'll also check with the ADs - whether these > changes require a revision before proceeding or can be handled during > AUTH48. > > Joe I personally think these changes would be fine in AUTH48. Thanks again for your quick responses to the review. regards, Ted > > > On 3/7/2012 11:26 AM, Ted Hardie wrote: >> >> Hi Joe, >> >> Thanks for your quick reply; comments in-line. >> >> On Wed, Mar 7, 2012 at 7:40 AM, Joe Touch =A0wrote: >>> >>> >>>> Minor Issues: [list any minor issues such as text that is unclear or >>>> confusing, preferably by section number] >>>> >>>> In section 6, the inclusion of the mathematical expression for which >>>> datagrams were atomic vs. non-atomic did not seem to add anything to >>>> the clarity of the surrounding text. =A0By introducing several >>>> abbreviations and reviewing the logical operators, it seemed to >>>> complicate what appeared to be a very clear statement: =A0Atomic >>>> datagrams are those which are not fragmented now and for which later >>>> fragmentation is inhibited; non-atomic datagrams are those that either >>>> are fragmented or which may later be fragmented. >>> >>> >>> >>> The equations are intended to be pseudocode, to define atomicity in ter= ms >>> of >>> specific tests on IP header fields. This helps clarify the interpretati= on >>> of >>> the English definition to help coders. We can clarify that by replacing >>> "mathematical expression" with "pseudocode". >>> >>> Would that clarify the utility of the expressions? Should we also expla= in >>> the rationale for including them in a single sentence? >>> >> >> If you will retain them, I think it should be stated more explicitly >> that the expressions are simply a restatement of the textual >> definitions. =A0Perhaps: >> >> OLD: >> >> Atomic datagrams: datagrams not yet fragmented (MF=3D0 and fragment >> =A0 =A0 =A0 offset=3D0) and for which further fragmentation has been inh= ibited >> =A0 =A0 =A0 (DF=3D1), i.e., as a mathematical expression (equals is =3D= =3D, logical >> =A0 =A0 =A0 'and' is&&, logical 'or' is ||, greater than is>, logical 'n= ot' >> >> =A0 =A0 =A0 is ~, and parenthesis function typically): >> >> =A0 =A0 =A0 =A0 =A0(DF=3D=3D1)&&(MF=3D=3D0)&&(frag_offset=3D=3D0) >> >> =A0 =A0o =A0Non-atomic datagrams: datagrams which have either already be= en >> =A0 =A0 =A0 fragmented, i.e.: >> >> =A0 =A0 =A0 =A0 =A0(MF=3D1)||(frag_offset>0) >> >> =A0 =A0 =A0 or for which fragmentation remains possible: >> >> =A0 =A0 =A0 =A0 =A0(DF=3D=3D0) >> >> =A0 =A0 =A0 I.e., non-atomic datagrams can be expressed in two equivalen= t >> =A0 =A0 =A0 tests: >> >> =A0 =A0 =A0 =A0 =A0(DF=3D=3D0)||(MF=3D=3D1)||(frag_offset>0) >> >> =A0 =A0 =A0 which can also be expressed as follows, using DeMorgan's Law= and >> =A0 =A0 =A0 other identities: >> >> =A0 =A0 =A0 =A0 =A0~((DF=3D=3D1)&&(MF=3D=3D0)&&(frag_offset=3D=3D0)) >> >> =A0 =A0 =A0 Note that this final expression is the same as "not(atomic)"= . >> >> NEW: >> >> Atomic datagrams are datagrams not yet fragmented and for which >> further fragmentation has been inhibited. >> >> Non-atomic datagrams are datagrams which either have already been >> fragmented or for which fragmentation remains possible. >> >> This same definition can be expressed in pseudo code as using common >> logical operators (equals is =3D=3D, logical 'and' is&&, logical 'or' is >> >> ||, greater than is>, logical 'not' is ~, and parenthesis function >> typically) as: >> >> atomic datagrams: =A0 (DF=3D=3D1)&&(MF=3D=3D0)&&(frag_offset=3D=3D0) >> >> non-atomic datagrams: =A0 (DF=3D=3D0)||(MF=3D=3D1)||(frag_offset>0) >> >>> >> > > > That works much better - thanks! > > >>>> In section 10, the document states: >>>> >>>> When compression assumes a changing ID as a default, having a non- >>>> =A0 =A0changing ID can make compression less efficient (see footnote 2= 1 of >>>> [RFC1144] or >>>> =A0 cRTP [RFC2508]). >>>> >>>> The text of footnote 21 is: >>>> >>>> =A0 =A0Note that the test here is against one, not zero. =A0The packet= ID is >>>> =A0 =A0typically incremented by one for each packet sent so a change o= f zero >>>> is >>>> =A0 =A0very unlikely. =A0A change of one is likely: =A0It occurs durin= g any >>>> period >>>> =A0 =A0when the originating system has activity on only one connection= . >>>> >>>> I was expecting the footnote to contain data that referred to >>>> compression efficiency; >>>> perhaps some additional context is needed? >>> >>> >>> >>> We could change that to "less efficient. Such non-changing IDs have bee= n >>> described in various RFCs (e.g., footnote 21 of [RFC1144 and cRTP >>> [RFC2508])." >>> >>> Would that be more clear? >>> >> >> Yes, that's clearer, > > From barryleiba.mailing.lists@gmail.com Thu Mar 8 11:15:28 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAE7C21F85B7 for ; Thu, 8 Mar 2012 11:15:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.985 X-Spam-Level: X-Spam-Status: No, score=-102.985 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7WTxcvEmvkx8 for ; Thu, 8 Mar 2012 11:15:27 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id B306A21F8587 for ; Thu, 8 Mar 2012 11:15:27 -0800 (PST) Received: by yenm5 with SMTP id m5so515970yen.31 for ; Thu, 08 Mar 2012 11:15:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=IovhwNMPVPqw0jqv+elaqSJ5GLUT1ygMovMYbL27478=; b=Mr8gGq4j0DnRoKuGWKGwymBmN/6aWE2MyIJHci84QUASH05p6NwbG+RHeJH4G/L0k9 4HTewfTZRlA3/E71XzQHqW6a2ZAnnq4/NgAcJjMIAAFYO+mLD0qRRvDSwvMsciIb3Wuq k19EIdDwXRYpC2ISEN2xM885qpecgcqMk5ZoC9SZrWfKQWGKZ2geFU/rB2jIbR+xXej/ nK6Hh8qID4iJWldNj525lapFmDGVpxfDl/1QGGwBTfB6wZlAWGQ38lMV0RtQBOsDABre N7hhB8oVvz+mJxxwtF9Lwqw8Q8UuB877N3ohT6W0k9olh/s7CjWMsOys2p8LWg9py+ea 8PFg== MIME-Version: 1.0 Received: by 10.236.184.129 with SMTP id s1mr12502267yhm.21.1331234127092; Thu, 08 Mar 2012 11:15:27 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.106.16 with HTTP; Thu, 8 Mar 2012 11:15:26 -0800 (PST) In-Reply-To: <4F58EF37.8010802@KingsMountain.com> References: <4F58EF37.8010802@KingsMountain.com> Date: Thu, 8 Mar 2012 14:15:26 -0500 X-Google-Sender-Auth: coHLfy-SRnHOBijVfCSDpa_BLVA Message-ID: From: Barry Leiba To: Apps Discuss Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [apps-discuss] Proposal for a Finance Area Mailing List X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Mar 2012 19:15:28 -0000 On Thu, Mar 8, 2012 at 12:41 PM, =3DJeffH w= rote: > A separate but related question is whether "financial-protocol" folk need > different underlying =A0protocols, for transport/transfer of this particu= lar > type of data and notifications, than what is extant (and implemented & > shipping) today (e.g., HTTP, TLS/SSL, SCTP, XMPP, etc.). > > If not, then perhaps they might concentrate on the stuff at their > "financial" layer and concoct "bindings" to the existing underlying stuff > (eg, as we did in SAML & Liberty (to HTTP)) as appropriate, and they then > could perhps more easily work on their "financial" layer whereever (eg, W= 3C, > OASIS, SomeNew.org, etc). > > The overall key is (as has been noted in this thread) getting a critical > mass of subject matter experts to show up with the cycles/commitment to > accomplishing something. So one should select a venue that such folk are > most likely to participate in. That may or may not be the IETF Yes... this is exactly the sort of discussion I was looking to generate *here*, before deciding whether it should be spun off to a separate mailing list. These are the sorts of questions that aren't answered in the original request -- and, of course, can't be, yet, until some discussion happens. The bar for creating a new non-WG mailing list is fairly low, so the ADs are not looking for definitive answers. We just want a sense of who will participate, where it's (roughly) likely to go, and how likely it is to wind up with work for the IETF. And it's OK if we create the mailing list and in the end the participants decide to go elsewhere. As I said, the bar is pretty low.[1] But there is a bar. Barry [1] But is it a pole-vault bar (high is harder) or a limbo bar (low is harder)? Hmmmm.... From john-ietf@jck.com Thu Mar 8 12:32:19 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0F7021F84D1; Thu, 8 Mar 2012 12:32:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.827 X-Spam-Level: X-Spam-Status: No, score=-102.827 tagged_above=-999 required=5 tests=[AWL=-0.228, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nVVrX05F-Knp; Thu, 8 Mar 2012 12:32:19 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 1413721F84C9; Thu, 8 Mar 2012 12:32:19 -0800 (PST) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1S5jvq-000B6w-9t; Thu, 08 Mar 2012 15:27:26 -0500 Date: Thu, 08 Mar 2012 15:31:58 -0500 From: John C Klensin To: Peter Saint-Andre , dcrocker@bbiw.net Message-ID: <11FF964F9FF3063DE7F98BDB@PST.JCK.COM> In-Reply-To: <4F58F39A.9030401@stpeter.im> References: <1331188315.87259.YahooMailNeo@web31816.mail.mud.yahoo.com> <4F58EBFA.7010904@stpeter.im> <4F58EFBF.8030908@dcrocker.net> <4F58F39A.9030401@stpeter.im> 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: draft-ietf-appsawg-xdash.all@tools.ietf.org, William Mills , The IESG , apps-discuss@ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-appswg-xdash-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Mar 2012 20:32:20 -0000 --On Thursday, March 08, 2012 10:59 -0700 Peter Saint-Andre wrote: >> As such I suggest changing it's name to something like >> >> Deprecating Specialized Naming for Non-Standard Values (X- >> and Similar Constructs) >> >> I like to have titles help document searching and organizing. Me too. But note that "prs.xxxxx" and even "vnd.FooCo.yyyy" are "specialized naming for non-standard values" john From stpeter@stpeter.im Thu Mar 8 12:43:26 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50C0021E8039; Thu, 8 Mar 2012 12:43:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.738 X-Spam-Level: X-Spam-Status: No, score=-102.738 tagged_above=-999 required=5 tests=[AWL=-0.139, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xaLcjd8VABae; Thu, 8 Mar 2012 12:43:25 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B2D2921E8037; Thu, 8 Mar 2012 12:43:25 -0800 (PST) Received: from squire.local (unknown [64.101.72.114]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6E45A4005B; Thu, 8 Mar 2012 13:55:28 -0700 (MST) Message-ID: <4F5919EB.1080407@stpeter.im> Date: Thu, 08 Mar 2012 13:43:23 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: John C Klensin References: <1331188315.87259.YahooMailNeo@web31816.mail.mud.yahoo.com> <4F58EBFA.7010904@stpeter.im> <4F58EFBF.8030908@dcrocker.net> <4F58F39A.9030401@stpeter.im> <11FF964F9FF3063DE7F98BDB@PST.JCK.COM> In-Reply-To: <11FF964F9FF3063DE7F98BDB@PST.JCK.COM> X-Enigmail-Version: 1.3.5 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: draft-ietf-appsawg-xdash.all@tools.ietf.org, William Mills , dcrocker@bbiw.net, apps-discuss@ietf.org, The IESG Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-appswg-xdash-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Mar 2012 20:43:26 -0000 On 3/8/12 1:31 PM, John C Klensin wrote: > > > --On Thursday, March 08, 2012 10:59 -0700 Peter Saint-Andre > wrote: > >>> As such I suggest changing it's name to something like >>> >>> Deprecating Specialized Naming for Non-Standard Values (X- >>> and Similar Constructs) >>> >>> I like to have titles help document searching and organizing. > > Me too. > > But note that "prs.xxxxx" and even "vnd.FooCo.yyyy" are > "specialized naming for non-standard values" Are they specialized naming for local or implementation-specific values, not non-standard values? Perhaps that's splitting hairs... Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Thu Mar 8 12:56:13 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4033D21F85F6; Thu, 8 Mar 2012 12:56:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.737 X-Spam-Level: X-Spam-Status: No, score=-102.737 tagged_above=-999 required=5 tests=[AWL=-0.138, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E6KXf4esklLi; Thu, 8 Mar 2012 12:56:12 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 7846F21F85EE; Thu, 8 Mar 2012 12:56:06 -0800 (PST) Received: from squire.local (unknown [64.101.72.114]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6B00B4005B; Thu, 8 Mar 2012 13:59:27 -0700 (MST) Message-ID: <4F591ADA.2020106@stpeter.im> Date: Thu, 08 Mar 2012 13:47:22 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: John C Klensin References: <1331188315.87259.YahooMailNeo@web31816.mail.mud.yahoo.com> <4F58EBFA.7010904@stpeter.im> <4F58EFBF.8030908@dcrocker.net> <4F58F39A.9030401@stpeter.im> <11FF964F9FF3063DE7F98BDB@PST.JCK.COM> <4F5919EB.1080407@stpeter.im> In-Reply-To: <4F5919EB.1080407@stpeter.im> X-Enigmail-Version: 1.3.5 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: draft-ietf-appsawg-xdash.all@tools.ietf.org, William Mills , dcrocker@bbiw.net, apps-discuss@ietf.org, The IESG Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-appswg-xdash-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Mar 2012 20:56:12 -0000 On 3/8/12 1:43 PM, Peter Saint-Andre wrote: > On 3/8/12 1:31 PM, John C Klensin wrote: >> >> >> --On Thursday, March 08, 2012 10:59 -0700 Peter Saint-Andre >> wrote: >> >>>> As such I suggest changing it's name to something like >>>> >>>> Deprecating Specialized Naming for Non-Standard Values (X- >>>> and Similar Constructs) >>>> >>>> I like to have titles help document searching and organizing. >> >> Me too. >> >> But note that "prs.xxxxx" and even "vnd.FooCo.yyyy" are >> "specialized naming for non-standard values" > > Are they specialized naming for local or implementation-specific values, > not non-standard values? Perhaps that's splitting hairs... On further reflection, I think that is splitting hairs. This might be a more accurate title: "Deprecating the X- Prefix and Similar Constructs in Application Protocols". Peter -- Peter Saint-Andre https://stpeter.im/ From john-ietf@jck.com Thu Mar 8 13:06:35 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 287B721F8691; Thu, 8 Mar 2012 13:06:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.821 X-Spam-Level: X-Spam-Status: No, score=-102.821 tagged_above=-999 required=5 tests=[AWL=-0.222, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZN9F9NOZePZc; Thu, 8 Mar 2012 13:06:34 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 9FBC021F8688; Thu, 8 Mar 2012 13:06:34 -0800 (PST) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1S5kT2-000B9z-13; Thu, 08 Mar 2012 16:01:44 -0500 Date: Thu, 08 Mar 2012 16:06:17 -0500 From: John C Klensin To: Peter Saint-Andre Message-ID: <609BED83E23A6939F0C9CEC8@PST.JCK.COM> In-Reply-To: <4F5919EB.1080407@stpeter.im> References: <1331188315.87259.YahooMailNeo@web31816.mail.mud.yahoo.com> <4F58EBFA.7010904@stpeter.im> <4F58EFBF.8030908@dcrocker.net> <4F58F39A.9030401@stpeter.im> <11FF964F9FF3063DE7F98BDB@PST.JCK.COM> <4F5919EB.1080407@stpeter.im> 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: draft-ietf-appsawg-xdash.all@tools.ietf.org, William Mills , dcrocker@bbiw.net, apps-discuss@ietf.org, The IESG Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-appswg-xdash-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Mar 2012 21:06:35 -0000 --On Thursday, March 08, 2012 13:43 -0700 Peter Saint-Andre wrote: >> But note that "prs.xxxxx" and even "vnd.FooCo.yyyy" are >> "specialized naming for non-standard values" > > Are they specialized naming for local or > implementation-specific values, not non-standard values? > Perhaps that's splitting hairs... Given that the media types document (both current and pending versions) explicitly identifies them as non-standard trees, I don't think even hair-splitting makes that title correct. You could say "specialized non-hierarchical..." or "specialized non-faceted...". That is also hair-splitting but would at least be correct. john From martin.thomson@gmail.com Thu Mar 8 13:40:04 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0D1221E802B; Thu, 8 Mar 2012 13:40:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.906 X-Spam-Level: X-Spam-Status: No, score=-4.906 tagged_above=-999 required=5 tests=[AWL=-1.307, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HpmUgLZgL59D; Thu, 8 Mar 2012 13:40:04 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0741D21E801C; Thu, 8 Mar 2012 13:40:03 -0800 (PST) Received: by bkuw5 with SMTP id w5so841747bku.31 for ; Thu, 08 Mar 2012 13:40:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=CTVFMCOxR7F/wp5Bi/eqSVH7qr+hKSJSVACB5WlTHVs=; b=HdnVdTDbz/bJ39awWdaJJrT20vl+enj08odigqO4DWT71mSRg1fsnDNBy8pEK2cx+K y57WwmMM6AAREHXpUCtSX5s7Z72+vUKvnWSpT5/KaUmG1xmwRbQiHxToYrB2GXFEvx8n 8OppCjFXLT3I4gH4Eu/v8YEuOzr9WEOohiMUXcw9ju3z6+1Qy+fZKHyDFydKMQuRtBlV w+7LjuPwPbg+0A5drSVFI5Ugit9dar4Ng3H5XB8TxVLJ+p7X7fXEG3+raeUe4YYERaLe gZZm83aXRVRV3z/iAg+aMnVrQhE2jsmke5iX7sAt6F9Upo2OBe0n232BUq7BkIc9EPBx y0dQ== MIME-Version: 1.0 Received: by 10.204.141.11 with SMTP id k11mr3586116bku.5.1331242803055; Thu, 08 Mar 2012 13:40:03 -0800 (PST) Received: by 10.204.121.208 with HTTP; Thu, 8 Mar 2012 13:40:03 -0800 (PST) In-Reply-To: <609BED83E23A6939F0C9CEC8@PST.JCK.COM> References: <1331188315.87259.YahooMailNeo@web31816.mail.mud.yahoo.com> <4F58EBFA.7010904@stpeter.im> <4F58EFBF.8030908@dcrocker.net> <4F58F39A.9030401@stpeter.im> <11FF964F9FF3063DE7F98BDB@PST.JCK.COM> <4F5919EB.1080407@stpeter.im> <609BED83E23A6939F0C9CEC8@PST.JCK.COM> Date: Thu, 8 Mar 2012 13:40:03 -0800 Message-ID: From: Martin Thomson To: John C Klensin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org, draft-ietf-appsawg-xdash.all@tools.ietf.org, William Mills , The IESG , dcrocker@bbiw.net Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-appswg-xdash-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Mar 2012 21:40:05 -0000 On 8 March 2012 13:06, John C Klensin wrote: > Given that the media types document (both current and pending > versions) explicitly identifies them as non-standard trees, I > don't think even hair-splitting makes that title correct. =C2=A0You > could say "specialized non-hierarchical..." or "specialized > non-faceted...". =C2=A0That is also hair-splitting but would at least > be correct. In my mind, the distinction was always experimental vs. non-experimental, as opposed to vendor-specific vs. standardized. I think that's where the document has gone astray. Different axis of split, methinks, even if the axes aren't entirely orthogonal. From dhc@dcrocker.net Thu Mar 8 13:48:36 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 144D321F86AA; Thu, 8 Mar 2012 13:48:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.606 X-Spam-Level: X-Spam-Status: No, score=-6.606 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Py9OJZnsp--V; Thu, 8 Mar 2012 13:48:35 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 570DC21F854E; Thu, 8 Mar 2012 13:48:35 -0800 (PST) Received: from [192.168.1.11] (adsl-67-127-58-62.dsl.pltn13.pacbell.net [67.127.58.62]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q28LmQ8I023994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Mar 2012 13:48:32 -0800 Message-ID: <4F59291C.5000008@dcrocker.net> Date: Thu, 08 Mar 2012 13:48:12 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Martin Thomson References: <1331188315.87259.YahooMailNeo@web31816.mail.mud.yahoo.com> <4F58EBFA.7010904@stpeter.im> <4F58EFBF.8030908@dcrocker.net> <4F58F39A.9030401@stpeter.im> <11FF964F9FF3063DE7F98BDB@PST.JCK.COM> <4F5919EB.1080407@stpeter.im> <609BED83E23A6939F0C9CEC8@PST.JCK.COM> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Thu, 08 Mar 2012 13:48:32 -0800 (PST) Cc: apps-discuss@ietf.org, draft-ietf-appsawg-xdash.all@tools.ietf.org, William Mills , dcrocker@bbiw.net, The IESG Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-appswg-xdash-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 21:48:36 -0000 On 3/8/2012 1:40 PM, Martin Thomson wrote: > On 8 March 2012 13:06, John C Klensin wrote: >> Given that the media types document (both current and pending >> versions) explicitly identifies them as non-standard trees, I >> don't think even hair-splitting makes that title correct. You >> could say "specialized non-hierarchical..." or "specialized >> non-faceted...". That is also hair-splitting but would at least >> be correct. > > In my mind, the distinction was always experimental vs. > non-experimental, as opposed to vendor-specific vs. standardized. I > think that's where the document has gone astray. Different axis of > split, methinks, even if the axes aren't entirely orthogonal. X- itself has a rather long and well-documented history and purpose. The current document has expanded scope a bit, to try to cover a class, not merely an instance. The class is "names that are syntactically designed to be outside of standards space" because such names have a regularly tendency to become de facto standards, which makes formally standardizing them problematic. This is true for "experimental" names, "vendor" names, and any other kind of non-standard name. The premises behind the concern are a) registration is difficult, b) the name should flag the status. What the community has learned or the thirty-or-so years of the construct is that it's better to have a single, clean name space and leave status of the name as a separate issue. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From krokodil@gmail.com Thu Mar 8 13:46:13 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C52521F86AA for ; Thu, 8 Mar 2012 13:46:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RbpoaQxoJ26E for ; Thu, 8 Mar 2012 13:46:12 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 914A421F854E for ; Thu, 8 Mar 2012 13:46:12 -0800 (PST) Received: by yenm5 with SMTP id m5so625522yen.31 for ; Thu, 08 Mar 2012 13:46:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=h9ezvzla1QDBvWiqpP/A/5b3NXk9/QAARuP3wFllGNU=; b=pgLWGZIUvvwVy3RfHX8unv4NnOdtqEB3bynJrfxAh+s50+Mw0wCa5vZ8RW54wiev7x wapMZ+ewrsT/qJCXTrGyAqY6TqLZs/PimmteoVmTwt8t8ayPoqnBY4RavXMZjaG9pHFm 29UV96dtIH8AaYXN6LXOCVeedjujGFu4q1W5QX76KWDxmoByVByqOacN2lqS+Ld+hCDt NMtX7oQ+GL3O9bG9dCi+p+faSoWGFT8t7oqnutSmeMUMAWOl2H2AhC++2hRjCMaGyRW1 ZZc9MiPt7GaIJHiEcXBf0DEum3ydsdgGp2HB/DoV/OMQvX7GlD1OIcMz4JEK+ucd4NTy TN3Q== Received: by 10.50.195.131 with SMTP id ie3mr9158362igc.52.1331243172031; Thu, 08 Mar 2012 13:46:12 -0800 (PST) Received: from [10.0.1.2] (173-8-183-154-SFBA.hfc.comcastbusiness.net. [173.8.183.154]) by mx.google.com with ESMTPS id df2sm15343776igb.10.2012.03.08.13.46.10 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 08 Mar 2012 13:46:11 -0800 (PST) From: Vadim Zaliva Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Mar 2012 13:46:08 -0800 Message-Id: <9F0A2492-AE7D-4C12-8BB0-13489FD7F6C1@gmail.com> To: apps-discuss@ietf.org Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [apps-discuss] draft-pbryan-json-patch-04 - comments X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Mar 2012 21:48:54 -0000 Hi! I was looking for JSON patch formats available and found this draft. It = looks nice - concise and to the point. I would like to share few = comments I have. 1. I am not sure if 'test' operation should be part of it. The purpose = of the patch is to modify the document. 'test' operation either succeeds = of fails, but it is unclear how this information will be communicated or = used. It almost looks like a API operation rather than patch format = instruction. I would argue that in current state it should not be = included in the format.=20 I could see a case when it could be included as a part of conditional = syntax. In this case 'test' becomes a container for other operations = which would be executed only if the test succeeds. For example: { "test": "/baz", "value": "qux", "onsuccess" : [ { "replace": "/baz", "value": "boo" }, { "add": "/baz1", "value": "qux" } ] } 2. In most examples "value" property holds simple scalar values (strings = or integers) or arrays of such. I think it should be possible to use = arbitrary complex JSON data structures as such values. I hope this was = the intention. Perhaps adding an example with more complex value (object = or array) could illustrate this very powerful capability. For example = A.1 could be modified as following; An example target JSON document: { "foo": "bar" } A JSON Patch document: [ { "add": "/baz", "value": {"a":1,"b":2} } ] The resulting JSON document: { "baz": {"a":1,"b":2}, "foo": "bar" } Sincerely, Vadim From cyrus@daboo.name Thu Mar 8 14:18:49 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58A3E21F85B1; Thu, 8 Mar 2012 14:18:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGjLua8mKFmm; Thu, 8 Mar 2012 14:18:48 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE9621F85AD; Thu, 8 Mar 2012 14:18:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 84F0823373B2; Thu, 8 Mar 2012 17:18:46 -0500 (EST) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJ0NoL-lFxCP; Thu, 8 Mar 2012 17:18:31 -0500 (EST) Received: from [17.45.162.181] (unknown [17.45.162.181]) by daboo.name (Postfix) with ESMTPSA id C8531233738B; Thu, 8 Mar 2012 17:18:27 -0500 (EST) Date: Thu, 08 Mar 2012 17:18:59 -0500 From: Cyrus Daboo To: Eliot Lear , apps-discuss@ietf.org, draft-desruisseaux-caldav-sched.all@tools.ietf.org, Mark Nottingham Message-ID: <13D85D8317A51C090F37BFDD@cyrus.local> In-Reply-To: <4F588C9D.2090403@cisco.com> References: <4F588C9D.2090403@cisco.com> X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==========55BF0D386A64FFA03922==========" Cc: Peter Saint-Andre , 'IESG' Subject: Re: [apps-discuss] Applications Directorate Review of draft-desruisseaux-caldav-sched-11 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Mar 2012 22:18:49 -0000 --==========55BF0D386A64FFA03922========== Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; size=14265 Hi Eliot, Thank your for your detailed review. --On March 8, 2012 11:40:29 AM +0100 Eliot Lear wrote: > Summary: > > This is a marked improvement from the previous version, represents YET > ANOTHER very valuable contribution from these two authors, and is nearly > ready for publication.=C2=A0 I would suggest one more respin.=C2=A0 I = believe > this could happen, however, AFTER the IESG discussion. OK, that makes sense. > > Major Issues: > > > A question: can the new status codes defined in this specification leak > to non-participating implementations in Reply operations? Strictly speaking the new 1.xx codes are only meaningful when used on the=20 SCHEDULE-STATUS parameter and that parameter is required to be removed from = any iTIP message the client or server sends (as per Section 7.3). So=20 leakage should be minimal. That said, RFC5545 does define the overal=20 meaning for the 1.xx class of codes. However, neither iCalendar nor iTIP=20 explains what clients should do if they get a specific code they do not=20 recognize. I don't believe that there is any known interoperability problem = related to that (I suspect clients either ignore unknown codes outright, or = base their behavior on the status code class). If something needs to be=20 addressed here, it really ought to be in iCalendar or iTIP, and perhaps=20 filed as an erratum against one or both of those. > Minor Issues: > In general the document suffers from a lack of conciseness.=C2=A0 What > follows are some of the more glaring examples. > > In Section 1, 2nd paragraph, There is no need to describe so early what > functions aren't covered.=C2=A0 The way this is traditionally handled is = to > have a "Future Work" section.=C2=A0 That can be done in the intro or it = can > even be put after examples.=C2=A0 I prefer the latter, especially if you = mean > for the text to be non-normative.=C2=A0 If it is meant to be normative, = be > explicit about it. One reason that is there is that the we had (early on) a lot of=20 implementors asking us about those other methods not being covered. So we=20 felt it reasonable to add some commentary that they have been deliberately=20 left out. Now I would be willing to move that into a "Potential Future Work"=20 appendix. But I could argue that the 4th paragraph of Section 1 should also = be moved there (the one about not addressing support for "external" users). = Do you think that should be moved too? > Similarly, in the 4th paragraph, same section, it is sufficient to say > (above) that this mechanism works compatibly with iMIP. You're using a > double negative.=C2=A0 And this problem recurs in the same = paragraph.=C2=A0 You > should consider a search on the word "not". How about: This specification only addresses how scheduling occurs with users on a single system (i.e., scheduling between CalDAV servers, or some other calendaring and scheduling system, is not defined). However, this specification is compatible with servers being able to send or receive scheduling messages with "external" users (e.g., using the iCalendar Message-Based Interoperability Protocol iMIP [RFC6047]). > =C2=A71, pg 6: > > > =C2=A0=C2=A0 In iTIP-based scheduling, there is an event "Organizer" = whose role is > =C2=A0=C2=A0 to schedule an event between one or more "Attendees", and = this is > =C2=A0=C2=A0 done by sending out invitations and handling responses from = each > =C2=A0=C2=A0 Attendee.=C2=A0 Often times an Organizer will do a = "freebusy" lookup to > =C2=A0=C2=A0 check on Attendees' availability (free-time). > > > This document needn't and shouldn't repeat or review iTIP.=C2=A0 Suggest > remove. OK - done. > > =C2=A0=C2=A0 Servers supporting this specification advertise their = capabilities > =C2=A0=C2=A0 and provides new collections for scheduling operations as = described > =C2=A0=C2=A0 in Section 2. > > > This is mundane and not needed in =C2=A7 1.=C2=A0 Suggest you cut it. OK - done. > =C2=A71, ppg 6-7: > Let's be more clear about about the theory of operation specified in this > document.=C2=A0 Suggest reword along the following lines: > > In order to automate the process of scheduling, we define the term > "scheduling operation" that consists of a client storing an iCal VEVENT > in a CALDAV store and then the server taking specific actions in > response.=C2=A0 In each case... (and lop off "as per.."). > > Also add one sentence here about atomicity (or lack thereof) of the > operations. See next item. > =C2=A71, pg. 7: > > Suggest active tense reword as follows: What I have done is reword and compress the four paragraphs that=20 "introduce" the key sections. Now I have: Section 3 defines the automated "Scheduling Operations", that allow a client to store iCalendar data on a CalDAV server, with the server taking specific actions in response. One of three scheduling operations can take place: "create", "modify" or "remove", based on the HTTP method used for the request, and a comparison between any existing and any new iCalendar data. Section 4 defines how the server processes scheduling messages sent as the result of a scheduling operation. Section 5 defines how freebusy requests with an immediate response is accomplished. Section 6 defines access control privileges for the scheduling operations defined in this specification. > =C2=A71.1, ppg 7-8: > > No need to restate definitions from other documents=E2=80=93 unless you = see a > difference in the meaning of the term amongst documents.=C2=A0 In = particular, > I see that you chose to reference RFC-3283 instead of RFC-5546 for > Calendar User.=C2=A0 3283 would be a downref if you referenced it > normatively.=C2=A0 The definition should be normative.=C2=A0 You want = 5546. I have removed the terminology items repeated from other specs, so now it=20 just lists the new ones being defined. As a result the 3283 reference has=20 been completely eliminated. > Also see nit on this. > > =C2=A71.3 pg 9: > > I've asked Mark Nottingham for an additional set of eyes on this > section.=C2=A0 I have one immediate comment and question: > > > =C2=A0=C2=A0 This document inherits, and sometimes extends, DTD = productions from > =C2=A0=C2=A0 Section 14 of [RFC4918]. > > > I would reword- "This document inherits and extends DTD productions..." > > If so, should this specification update RFC4918 in rfc-index.txt? The text used here is an exact copy of what was used in CardDAV (RFC6352)=20 which was based on what we used in CalDAV (RFC4791) with specific changes=20 and clarifications that Julian had requested. It reflects standard WebDAV=20 XML handling behavior. > =C2=A72.1, pg 10, and similar text in =C2=A72.2, pg 11: > > > =C2=A0=C2=A0 The following WebDAV properties specified in CalDAV = "calendar-access" > =C2=A0=C2=A0 [RFC4791] MAY also be defined on scheduling... > > > > Do you mean "Only the following WebDAV..."?=C2=A0 If not, why state these > properties? There are some other properties from CalDAV we are not specifying because=20 they have no meaning on an Outbox (e.g. calendar-timezone). And there are=20 properties on other types of CalDAV resource that are not relevant (e.g.=20 calendar-home-set). So I think the working and intent here is fine. > =C2=A72.1.1, pg 11, and similar text in =C2=A72.2.1, pg 13, =C2=A72,4,1, = pg 14, and > similar: > > > =C2=A0=C2=A0 PROPFIND behavior:=C2=A0 This property SHOULD NOT be = returned by a > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 PROPFIND allprop request (as defined in = Section 14.2 of > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 [RFC4918]). > > > Why SHOULD NOT and not MUST NOT?=C2=A0 How should the client interpret = the > information, if returned? As Julian has noted, this is common practice for the definition of WebDAV=20 properties. In some cases a server might decide that a live property is=20 trivial to compute and worthwhile to return in an allprop response. Since=20 allprop is required to return all dead properties, client have to be able=20 to handle getting back properties they don't care about. > =C2=A73.2.1.1, pg 18: > > > =C2=A0=C2=A0 When a scheduling object resource is created by the = Organizer, the > =C2=A0=C2=A0 server will inspect each "ATTENDEE" property to determine = if a > =C2=A0=C2=A0 scheduling message ought to be delivered to this Attendee = according > =C2=A0=C2=A0 to the value of the "SCHEDULE-AGENT" property parameter = (see > =C2=A0=C2=A0 Section 7.1) as described in the table below: > > > Please use normative language and active tense.=C2=A0 Suggest rewording = as > follows: > > > When the Organizer creates a scheduling object resource, the server SHALL > inspect each "ATTENDEE" property to determine whether to send a > scheduling > message.=C2=A0 Table XXX below indicates the appropriate action, based = on > the value > of the "SCHEDULE-AGENT" property. Change applied, but still uses "The table below ..." rather than a direct=20 "Table N" reference. > > =C2=A73.2.1.1 AND in =C2=A73.2.1.2 and =C2=A73.2.1.3: > > Why are you treating authorization differently between create & modify > operations and the remove operation? > > Cannot the text in =C2=A73.2.1.1 and =C2=A73.2.1.2 simply be moved into = the > chapeau (e.g., 3.2.1)? OK - done. > =C2=A73.2.1.2, pg 19 has similar, but more involved issues to = =C2=A73.2.1.1: > > > =C2=A0=C2=A0 When a scheduling object resource is modified by the = Organizer, the > =C2=A0=C2=A0 server will inspect each "ATTENDEE" property in the new = calendar > data > =C2=A0=C2=A0 to determine which ones have the "SCHEDULE-AGENT" iCalendar = property > =C2=A0=C2=A0 parameter.=C2=A0 It will then need to compare this with the = "ATTENDEE" > =C2=A0=C2=A0 properties in the existing calendar object resource that is = being > =C2=A0=C2=A0 modified. > > > > =C2=A0=C2=A0 For each Attendee in the old and new calendar data on a = per-instance > =C2=A0=C2=A0 basis, and taking into account the addition or removal of = Attendees, > =C2=A0=C2=A0 the server will determine whether to deliver a scheduling = message to > =C2=A0=C2=A0 the Attendee.=C2=A0 The following table determines whether = the server > =C2=A0=C2=A0 needs to deliver a scheduling message, and if so which iTIP > =C2=A0=C2=A0 scheduling method to use.=C2=A0 The values "SERVER", = "CLIENT", and > "NONE" > =C2=A0=C2=A0 in the top and left titles of the table refer to the > "SCHEDULE-AGENT" > =C2=A0=C2=A0 parameter value of the "ATTENDEE" property, and the values > "" > =C2=A0=C2=A0 and "" are used to cover the cases where the = "ATTENDEE" > =C2=A0=C2=A0 property is not present (Old) or is being removed (New). > > > > So.. active tense again, same sort of idea: > > > When the Organizer modifies a scheduling object resource, the server = SHALL > inspect each "ATTENDEE" property in both the original and modified event > instance > to determine whether to send a scheduling message.=C2=A0 Table XXX below > indicates the > appropriate action, based on the value of the "SCHEDULE-AGENT" property. > The values "SERVER", "CLIENT", and "NONE" in the top and left headings > refer to the "SCHEDULE-AGENT"=C2=A0 parameter value of the "ATTENDEE" > property. > The the values ""=C2=A0 and "" are used to cover the = cases > where the > =C2=A0"ATTENDEE" property is not present (Old) or is being removed = (New). > > > The use of the word ATTENDEE in the upper left-hand corner of the table > is confusing, and I would remove it.=C2=A0 I might also change the = headings > to read "Original" (going down)" and "Modified".=C2=A0 This allows for > consistency of language. OK - done. > =C2=A73.2.1.3, Rinse and repeat this exercise for "Remove": > > > > =C2=A0=C2=A0 When a scheduling object resource is removed by the = Organizer, the > =C2=A0=C2=A0 server will inspect each "ATTENDEE" property in the = scheduling > object > =C2=A0=C2=A0 resource being removed to determine which ones have the = "SCHEDULE- > =C2=A0=C2=A0 AGENT" iCalendar property parameter. > > =C2=A0=C2=A0 For each Attendee the server will determine whether to = attempt to > =C2=A0=C2=A0 deliver a scheduling message into the Attendee's scheduling = Inbox > =C2=A0=C2=A0 collection, based on the table below: > > > So... > > > When an Organizer removes a scheduling object resource, the server SHALL > inspect each "ATTENDEE" property in the scheduling object resource being > removed, and act based on the value of the "SCHEDULE-AGENT" property > value, > according to Table XXX below. OK - done. > =C2=A73.2.2.3, pg 23: > > > =C2=A0=C2=A0 If the Attendee adds an "EXDATE" property value to = effectively remove > =C2=A0=C2=A0 a recurrence instance, the server MUST deliver an iTIP = "REPLY" > =C2=A0=C2=A0 scheduling message to the Organizer to indicate that the = Attendee > has > =C2=A0=C2=A0 declined the instance. > > > EXDATE isn't the only way an Attendee can decline. a specific event, > right?=C2=A0 Is this the only operation in which a server MUST act?=C2=A0 = Why > call this one out? Normally people think that a change in participation status is governed by=20 the ATTENDEE;PARTSTAT value. It is not entirely obvious that the act of=20 adding an EXDATE to an event means that the attendee has in effect declined = the event. At least I don't believe there is anything stated to that effect = in iCalendar or iTIP. So I think it is appropriate to describe the actions=20 for both a change to PARTSTAT and EXDATE. > =C2=A73.2.3.2, pg 25, in the COPY table, and 3.2.3.3, pg 26, the MOVE = table" : > > Remove (1) and replace with "Same as PUT in Table XXX" I left the note in but reworded as a reference to the section. > Also, move DELETE above MOVE (removes forward reference) and then remove > (2) and replace with "Same as DELETE") OK - done. > In all of these sections change to both active tense and normative > language.=C2=A0 So for instance: > > Old: > > > =C2=A0When a MOVE method request is received, the server will execute > > New: > > > When the server receives a MOVE request, it SHALL execute OK - done. > =C2=A73.2.9, pg 32: > > > =C2=A0=C2=A0 The 1.xx "REQUEST-STATUS" codes are new.=C2=A0 This = specification > modifies > =C2=A0=C2=A0 item (2) of Section 3.6 of [RFC5546] by adding the = following > =C2=A0=C2=A0 restriction: > > > > Should this memo indicate that it updates RFC-5546? Yes it should. Done. > > =C2=A73.2.10.1, =C2=A73.2.10.1, pg 34: > > Change "Clients can" to "Clients MAY" OK - done. > Nits: > > > =C2=A71, pg. 6: > > > > This is called a "Scheduling > =C2=A0=C2=A0 Operation" and fully described in Section 3 > > Missing verb "is". No longer relevant as that has been re-written. > > Throughout: > > > Calendar User is not capitalized consistently. Lowercased everywhere to be consistent with 5546. > Throughout: > > > Tables should be numbered for reference. As noted in separate email, this change won't be applied. I have attached my working copy with the changes described above as well as = an HTML diff for your convenience. --=20 Cyrus Daboo --==========55BF0D386A64FFA03922========== Content-Type: text/plain; charset=us-ascii; name="draft-desruisseaux-caldav-sched-12.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-desruisseaux-caldav-sched-12.txt"; size=167356 Network Working Group C. Daboo Internet-Draft Apple Inc. Updates: 4791,5546 (if approved) B. Desruisseaux Intended status: Standards Track Oracle Expires: September 9, 2012 March 8, 2012 CalDAV Scheduling Extensions to WebDAV draft-desruisseaux-caldav-sched-12 Abstract This document defines extensions to the CalDAV "calendar-access" feature to specify a standard way of performing scheduling operations with iCalendar-based calendar components. This document defines the "calendar-auto-schedule" feature of CalDAV. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 9, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Daboo & Desruisseaux Expires September 9, 2012 [Page 1] Internet-Draft CalDAV Scheduling Extensions March 2012 This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 1.2. Notational Conventions . . . . . . . . . . . . . . . . . . 7 1.3. XML Namespaces and Processing . . . . . . . . . . . . . . 8 2. Scheduling Support . . . . . . . . . . . . . . . . . . . . . . 9 2.1. Scheduling Outbox Collection . . . . . . . . . . . . . . . 9 2.1.1. CALDAV:schedule-outbox-URL Property . . . . . . . . . 10 2.2. Scheduling Inbox Collection . . . . . . . . . . . . . . . 11 2.2.1. CALDAV:schedule-inbox-URL Property . . . . . . . . . . 12 2.3. Calendaring Reports Extensions . . . . . . . . . . . . . . 12 2.4. Additional Principal Properties . . . . . . . . . . . . . 13 2.4.1. CALDAV:calendar-user-address-set Property . . . . . . 13 2.4.2. CALDAV:calendar-user-type Property . . . . . . . . . . 14 3. Scheduling Operations . . . . . . . . . . . . . . . . . . . . 16 3.1. Identifying Scheduling Object Resources . . . . . . . . . 16 3.2. Handling Scheduling Object Resources . . . . . . . . . . . 16 3.2.1. Organizer Scheduling Object Resources . . . . . . . . 16 3.2.1.1. Create . . . . . . . . . . . . . . . . . . . . . . 17 3.2.1.2. Modify . . . . . . . . . . . . . . . . . . . . . . 18 3.2.1.3. Remove . . . . . . . . . . . . . . . . . . . . . . 19 3.2.2. Attendee Scheduling Object Resources . . . . . . . . . 19 3.2.2.1. Allowed Attendee Changes . . . . . . . . . . . . . 19 3.2.2.2. Create . . . . . . . . . . . . . . . . . . . . . . 20 3.2.2.3. Modify . . . . . . . . . . . . . . . . . . . . . . 21 3.2.2.4. Remove . . . . . . . . . . . . . . . . . . . . . . 22 3.2.3. HTTP Methods . . . . . . . . . . . . . . . . . . . . . 22 3.2.3.1. PUT . . . . . . . . . . . . . . . . . . . . . . . 23 3.2.3.2. DELETE . . . . . . . . . . . . . . . . . . . . . . 23 3.2.3.3. COPY . . . . . . . . . . . . . . . . . . . . . . . 23 3.2.3.4. MOVE . . . . . . . . . . . . . . . . . . . . . . . 24 3.2.4. Additional Method Preconditions . . . . . . . . . . . 25 3.2.4.1. CALDAV:unique-scheduling-object-resource Precondition . . . . . . . . . . . . . . . . . . . 25 3.2.4.2. CALDAV:same-organizer-in-all-components Daboo & Desruisseaux Expires September 9, 2012 [Page 2] Internet-Draft CalDAV Scheduling Extensions March 2012 Precondition . . . . . . . . . . . . . . . . . . . 25 3.2.4.3. CALDAV:allowed-organizer-scheduling-object-chan Precondition . . . . . . . . . . . . . . . . . . . 26 3.2.4.4. CALDAV:allowed-attendee-scheduling-object-chang Precondition . . . . . . . . . . . . . . . . . . . 26 3.2.5. DTSTAMP and SEQUENCE Properties . . . . . . . . . . . 27 3.2.6. Restrict Recurrence Instances Sent to Attendees . . . 27 3.2.7. Forcing the Server to Send a Scheduling Message . . . 27 3.2.8. Attendee Participation Status . . . . . . . . . . . . 28 3.2.9. Schedule Status Values . . . . . . . . . . . . . . . . 29 3.2.10. Avoiding Conflicts when Updating Scheduling Object Resources . . . . . . . . . . . . . . . . . . . . . . 32 3.2.10.1. PUT . . . . . . . . . . . . . . . . . . . . . . . 34 3.2.10.2. DELETE, COPY or MOVE . . . . . . . . . . . . . . . 34 4. Processing Incoming Scheduling Messages . . . . . . . . . . . 35 4.1. Processing Organizer Requests, Additions, and Cancellations . . . . . . . . . . . . . . . . . . . . . . 35 4.2. Processing Attendee Replies . . . . . . . . . . . . . . . 36 4.3. Default Calendar Collection . . . . . . . . . . . . . . . 36 4.3.1. Additional Method Preconditions . . . . . . . . . . . 37 4.3.1.1. CALDAV:default-calendar-needed Precondition . . . 37 4.3.1.2. CALDAV:valid-schedule-default-calendar-URL Precondition . . . . . . . . . . . . . . . . . . . 37 5. Request for Busy Time Information . . . . . . . . . . . . . . 39 5.1. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 39 5.2. Additional Method Preconditions . . . . . . . . . . . . . 40 5.2.1. CALDAV:valid-scheduling-message Precondition . . . . . 40 5.2.2. CALDAV:valid-organizer Precondition . . . . . . . . . 40 6. Scheduling Privileges . . . . . . . . . . . . . . . . . . . . 42 6.1. Privileges on Scheduling Inbox Collections . . . . . . . . 42 6.1.1. CALDAV:schedule-deliver Privilege . . . . . . . . . . 42 6.1.2. CALDAV:schedule-deliver-invite Privilege . . . . . . . 42 6.1.3. CALDAV:schedule-deliver-reply Privilege . . . . . . . 43 6.1.4. CALDAV:schedule-query-freebusy Privilege . . . . . . . 43 6.2. Privileges on Scheduling Outbox Collections . . . . . . . 43 6.2.1. CALDAV:schedule-send Privilege . . . . . . . . . . . . 43 6.2.2. CALDAV:schedule-send-invite Privilege . . . . . . . . 43 6.2.3. CALDAV:schedule-send-reply Privilege . . . . . . . . . 44 6.2.4. CALDAV:schedule-send-freebusy Privilege . . . . . . . 44 6.3. Aggregation of Scheduling Privileges . . . . . . . . . . . 44 7. Additional iCalendar Property Parameters . . . . . . . . . . . 46 7.1. Schedule Agent Parameter . . . . . . . . . . . . . . . . . 46 7.2. Schedule Force Send Parameter . . . . . . . . . . . . . . 47 7.3. Schedule Status Parameter . . . . . . . . . . . . . . . . 48 8. Additional Message Header Fields . . . . . . . . . . . . . . . 50 8.1. Schedule-Reply Request Header . . . . . . . . . . . . . . 50 8.2. Schedule-Tag Response Header . . . . . . . . . . . . . . . 50 8.3. If-Schedule-Tag-Match Request Header . . . . . . . . . . . 51 Daboo & Desruisseaux Expires September 9, 2012 [Page 3] Internet-Draft CalDAV Scheduling Extensions March 2012 9. Additional WebDAV Properties . . . . . . . . . . . . . . . . . 52 9.1. CALDAV:schedule-calendar-transp Property . . . . . . . . . 52 9.2. CALDAV:schedule-default-calendar-URL Property . . . . . . 53 9.3. CALDAV:schedule-tag Property . . . . . . . . . . . . . . . 54 10. XML Element Definitions . . . . . . . . . . . . . . . . . . . 55 10.1. CALDAV:schedule-response XML Element . . . . . . . . . . . 55 10.2. CALDAV:response XML Element . . . . . . . . . . . . . . . 55 10.3. CALDAV:recipient XML Element . . . . . . . . . . . . . . . 55 10.4. CALDAV:request-status XML Element . . . . . . . . . . . . 56 11. Security Considerations . . . . . . . . . . . . . . . . . . . 57 11.1. Preventing Denial of Service Attacks . . . . . . . . . . . 57 11.2. Verifying Scheduling Operations . . . . . . . . . . . . . 57 11.3. Verifying Busy Time Information Requests . . . . . . . . . 58 11.4. Privacy Issues . . . . . . . . . . . . . . . . . . . . . . 58 11.5. Mitigation of iTIP Threats . . . . . . . . . . . . . . . . 59 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 60 12.1. Message Header Field Registrations . . . . . . . . . . . . 60 12.1.1. Schedule-Reply . . . . . . . . . . . . . . . . . . . . 60 12.1.2. Schedule-Tag . . . . . . . . . . . . . . . . . . . . . 60 12.1.3. If-Schedule-Tag-Match . . . . . . . . . . . . . . . . 60 12.2. iCalendar Property Parameter Registrations . . . . . . . . 61 12.3. iCalendar REQUEST-STATUS Value Registrations . . . . . . . 61 12.4. Additional iCalendar Elements Registries . . . . . . . . . 61 12.4.1. Schedule Agent Values Registry . . . . . . . . . . . . 61 12.4.2. Schedule Force Send Values Registry . . . . . . . . . 62 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 63 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 64 14.1. Normative References . . . . . . . . . . . . . . . . . . . 64 14.2. Informative References . . . . . . . . . . . . . . . . . . 65 Appendix A. Scheduling Privileges Summary . . . . . . . . . . . . 66 A.1. Scheduling Inbox Privileges . . . . . . . . . . . . . . . 66 A.2. Scheduling Outbox Privileges . . . . . . . . . . . . . . . 66 Appendix B. Example Scheduling Operations . . . . . . . . . . . . 68 B.1. Example: Organizer Inviting Multiple Attendees . . . . . . 68 B.2. Example: Attendee Receiving an Invitation . . . . . . . . 70 B.3. Example: Attendee Replying to an Invitation . . . . . . . 72 B.4. Example: Organizer Receiving a Reply to an Invitation . . 75 B.5. Example: Organizer Requesting Busy Time Information . . . 77 B.6. Example: User Attempting to Invite Attendee on behalf of Organizer . . . . . . . . . . . . . . . . . . . . . . . 79 B.7. Example: Attendee Declining an Instance of a Recurring Event . . . . . . . . . . . . . . . . . . . . . . . . . . 81 B.8. Example: Attendee Removing an Instance of a Recurring Event . . . . . . . . . . . . . . . . . . . . . . . . . . 84 Appendix C. Changes (to be removed by RFC Editor prior to publication) . . . . . . . . . . . . . . . . . . . . 87 C.1. Changes in -12 . . . . . . . . . . . . . . . . . . . . . . 87 C.2. Changes in -11 . . . . . . . . . . . . . . . . . . . . . . 87 Daboo & Desruisseaux Expires September 9, 2012 [Page 4] Internet-Draft CalDAV Scheduling Extensions March 2012 C.3. Changes in -10 . . . . . . . . . . . . . . . . . . . . . . 87 C.4. Changes in -09 . . . . . . . . . . . . . . . . . . . . . . 88 C.5. Changes in -08 . . . . . . . . . . . . . . . . . . . . . . 89 C.6. Changes in -07 . . . . . . . . . . . . . . . . . . . . . . 89 C.7. Changes in -06 . . . . . . . . . . . . . . . . . . . . . . 90 C.8. Changes in -05 . . . . . . . . . . . . . . . . . . . . . . 91 Daboo & Desruisseaux Expires September 9, 2012 [Page 5] Internet-Draft CalDAV Scheduling Extensions March 2012 1. Introduction This document specifies extensions to the CalDAV "calendar-access" [RFC4791] feature to enable scheduling of iCalendar-based [RFC5545] calendar components between calendar users. This extension leverages the scheduling methods defined in the iCalendar Transport-independent Interoperability Protocol (iTIP) [RFC5546] to permit calendar users to perform scheduling operations such as schedule, reschedule, respond to scheduling request or cancel calendar components, as well as search for busy time information. However, the following iTIP [RFC5546] features are not covered: publishing, countering, delegating, refreshing and forwarding calendar components, as well as replacing the Organizer of a calendar component. It is expected that future extensions will be developed to address these. This specification defines a client/server scheduling protocol, where the server is made responsible for sending scheduling messages and processing incoming scheduling messages. The client operations of creating, modifying or deleting a calendar component in a calendar is enough to trigger the server to deliver the necessary scheduling messages to the appropriate calendar users. This approach is sometimes referred to as "implicit scheduling". This specification only addresses how scheduling occurs with users on a single system (i.e., scheduling between CalDAV servers, or some other calendaring and scheduling system, is not defined). However, this specification is compatible with servers being able to send or receive scheduling messages with "external" users (e.g., using the iCalendar Message-Based Interoperability Protocol iMIP [RFC6047]). Section 3 defines the automated "Scheduling Operations", that allow a client to store iCalendar data on a CalDAV server, with the server taking specific actions in response. One of three scheduling operations can take place: "create", "modify" or "remove", based on the HTTP method used for the request, and a comparison between any existing and any new iCalendar data. Section 4 defines how the server processes scheduling messages sent as the result of a scheduling operation. Section 5 defines how freebusy requests with an immediate response is accomplished. Section 6 defines access control privileges for the scheduling operations defined in this specification. Daboo & Desruisseaux Expires September 9, 2012 [Page 6] Internet-Draft CalDAV Scheduling Extensions March 2012 For the majority of the following discussion, scheduling of events will be discussed. However, scheduling of to-dos is also fully supported by this specification. Discussion of this Internet-Draft is taking place on the mailing lists at and . 1.1. Terminology This specification reuses much of the same terminology as iCalendar [RFC5545], iTIP [RFC5546], WebDAV [RFC4918], and CalDAV [RFC4791]. Additional terms used by this specification are: Scheduling object resource: A calendar object resource contained in a calendar collection for which the server will take care of sending scheduling messages on behalf of the owner of the calendar collection. Organizer scheduling object resource: A scheduling object resource owned by the Organizer. Attendee scheduling object resource: A scheduling object resource owned by an Attendee. Scheduling operation: Add, change or remove operations on a scheduling object resource for which the server will deliver scheduling messages to other calendar users. Scheduling message: A calendar object that describes a scheduling operation such as schedule, reschedule, reply, or cancel. Scheduling Outbox collection: A resource at which busy time information requests are targeted. Scheduling Inbox collection: A collection in which incoming scheduling messages are delivered. 1.2. Notational Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. The Augmented BNF (ABNF) syntax used by this document to specify the format definition of new iCalendar elements is defined in [RFC5234]. The Augmented BNF (ABNF) syntax used by this document to specify the Daboo & Desruisseaux Expires September 9, 2012 [Page 7] Internet-Draft CalDAV Scheduling Extensions March 2012 format definition of new message header fields to be used with the HTTP/1.1 protocol is described in Section 2.1 of [RFC2616]. Since this Augmented BNF uses the basic production rules provided in Section 2.2 of [RFC2616], these rules apply to this document as well. The term "protected" is used in the Conformance field of WebDAV property definitions as defined in Section 15 of [RFC4918]. 1.3. XML Namespaces and Processing This document uses XML DTD fragments ([W3C.REC-xml-20081126], Section 3.2) as a purely notational convention. WebDAV request and response bodies cannot be validated by a DTD due to the specific extensibility rules defined in Section 17 of [RFC4918] and due to the fact that all XML elements defined by that specification use the XML namespace name "DAV:". In particular: 1. element names use the "DAV:" namespace, 2. element ordering is irrelevant unless explicitly stated, 3. extension elements (elements not already defined as valid child elements) can be added anywhere, except when explicitly stated otherwise, 4. extension attributes (attributes not already defined as valid for this element) can be added anywhere, except when explicitly stated otherwise. The XML elements specified in this document are defined in the "urn:ietf:params:xml:ns:caldav" XML namespace registered by CalDAV [RFC4791]. When XML element types in the namespaces "DAV:" and "urn:ietf:params:xml:ns:caldav" are referenced in this document outside of the context of an XML fragment, the strings "DAV:" and "CALDAV:" will be prefixed to the element types, respectively. This document inherits, and sometimes extends, DTD productions from Section 14 of [RFC4918]. Also note that some CalDAV XML element names are identical to WebDAV XML element names, though their namespace differs. Care needs to be taken not to confuse the two sets of names. Daboo & Desruisseaux Expires September 9, 2012 [Page 8] Internet-Draft CalDAV Scheduling Extensions March 2012 2. Scheduling Support A server that supports the features described in this document MUST include "calendar-auto-schedule" as a field in the DAV response header from an OPTIONS request on any resource that supports any scheduling operations, properties, privileges or methods. To advertise support for the CalDAV "calendar-auto-schedule" feature a server is REQUIRED to support and advertise support for the CalDAV "calendar-access" [RFC4791] feature. This specification introduces new collection resource types that are used to manage scheduling object resources, and scheduling privileges (as per Section 6), as well as provide scheduling functionality. It is the server's responsibility to create these collection resources, and clients have no way to create or delete them. 2.1. Scheduling Outbox Collection A scheduling Outbox collection is used as the target for busy time information requests, and to manage privileges that apply to outgoing scheduling requests. A scheduling Outbox collection MUST report the DAV:collection and CALDAV:schedule-outbox XML elements in the value of the DAV: resourcetype property. The element type declaration for CALDAV: schedule-outbox is: Example: A scheduling Outbox collection MUST NOT be a child (at any depth) of a calendar collection resource. The following WebDAV properties specified in CalDAV "calendar-access" [RFC4791] MAY also be defined on scheduling Outbox collections and apply to scheduling messages submitted to the scheduling Outbox collection with the POST method: o CALDAV:supported-calendar-component-set Daboo & Desruisseaux Expires September 9, 2012 [Page 9] Internet-Draft CalDAV Scheduling Extensions March 2012 o CALDAV:supported-calendar-data o CALDAV:max-resource-size o CALDAV:min-date-time o CALDAV:max-date-time o CALDAV:max-attendees-per-instance The use of child resources in a scheduling Outbox collection is reserved for future revisions or extensions of this specification. The following WebDAV property is defined on principal resources and used to locate the corresponding Outbox collection for the associated principal. 2.1.1. CALDAV:schedule-outbox-URL Property Name: schedule-outbox-URL Namespace: urn:ietf:params:xml:ns:caldav Purpose: Identify the URL of the scheduling Outbox collection owned by the associated principal resource. Protected: This property MAY be protected. PROPFIND behavior: This property SHOULD NOT be returned by a PROPFIND allprop request (as defined in Section 14.2 of [RFC4918]). COPY/MOVE behavior: This property value SHOULD be preserved in COPY and MOVE operations. Description: This property is needed for a client to determine where the scheduling Outbox collection of the current user is located so that sending of scheduling messages can occur. If not present, then the associated calendar user is not enabled for the sending of scheduling messages on the server. Definition: Daboo & Desruisseaux Expires September 9, 2012 [Page 10] Internet-Draft CalDAV Scheduling Extensions March 2012 2.2. Scheduling Inbox Collection A scheduling Inbox collection contains copies of incoming scheduling messages. These can be requests sent by an Organizer, or replies sent by an Attendee in response to a request. The scheduling Inbox collection is also used to manage scheduling privileges. A scheduling Inbox collection MUST report the DAV:collection and CALDAV:schedule-inbox XML elements in the value of the DAV: resourcetype property. The element type declaration for CALDAV: schedule-inbox is: Example: Scheduling Inbox collections MUST only contain calendar object resources that obey the restrictions specified in iTIP [RFC5546]. Consequently, scheduling Inbox collections MUST NOT contain any types of collection resources. Restrictions defined in Section 4.1 of CalDAV "calendar-access" [RFC4791] on calendar object resources contained in calendar collections (e.g., "UID" uniqueness) do not apply to calendar object resources contained in a scheduling Inbox collection. Thus, multiple calendar object resources contained in a scheduling Inbox collection can have the same "UID" property value (i.e., multiple scheduling messages for the same calendar component). A scheduling Inbox collection MUST NOT be a child (at any depth) of a calendar collection resource. The following WebDAV properties specified in CalDAV "calendar-access" [RFC4791] MAY also be defined on scheduling Inbox collections and apply to scheduling messages delivered to the collection: o CALDAV:supported-calendar-component-set o CALDAV:supported-calendar-data o CALDAV:max-resource-size o CALDAV:min-date-time Daboo & Desruisseaux Expires September 9, 2012 [Page 11] Internet-Draft CalDAV Scheduling Extensions March 2012 o CALDAV:max-date-time o CALDAV:max-instances o CALDAV:max-attendees-per-instance o CALDAV:calendar-timezone The following WebDAV property is defined on principal resources and used to locate the corresponding Inbox collection for the associated principal. 2.2.1. CALDAV:schedule-inbox-URL Property Name: schedule-inbox-URL Namespace: urn:ietf:params:xml:ns:caldav Purpose: Identify the URL of the scheduling Inbox collection owned by the associated principal resource. Protected: This property MAY be protected. PROPFIND behavior: This property SHOULD NOT be returned by a PROPFIND allprop request (as defined in Section 14.2 of [RFC4918]). COPY/MOVE behavior: This property value SHOULD be preserved in COPY and MOVE operations. Description: This property allows a client to determine where the scheduling Inbox collection of the current user is located so that processing of scheduling messages can occur. If not present, then the associated calendar user is not enabled for reception of scheduling messages on the server. Definition: 2.3. Calendaring Reports Extensions This specification extends the CALDAV:calendar-query and CALDAV: calendar-multiget REPORTs to return results for calendar object resources in scheduling Inbox collections. When a CALDAV:calendar-query REPORT includes a time-range query and targets a scheduling Inbox collection, if any calendar object Daboo & Desruisseaux Expires September 9, 2012 [Page 12] Internet-Draft CalDAV Scheduling Extensions March 2012 resources contain "VEVENT" calendar components that do not include a "DTSTART" iCalendar property (as allowed by iTIP [RFC5546]) then such components MUST always match the time-range query test. Note that the CALDAV:free-busy-query REPORT is not supported on scheduling Inbox collections. 2.4. Additional Principal Properties This section defines new properties for WebDAV principal resources as defined in [RFC3744]. These properties are likely to be protected but the server MAY allow them to be written by appropriate users. 2.4.1. CALDAV:calendar-user-address-set Property Name: calendar-user-address-set Namespace: urn:ietf:params:xml:ns:caldav Purpose: Identify the calendar addresses of the associated principal resource. Protected: This property MAY be protected. PROPFIND behavior: This property SHOULD NOT be returned by a PROPFIND allprop request (as defined in Section 14.2 of [RFC4918]). COPY/MOVE behavior: This property value SHOULD be preserved in COPY and MOVE operations. Description: Support for this property is REQUIRED. This property is needed to map calendar user addresses in iCalendar data to principal resources and their associated scheduling Inbox and Outbox collections. In the event that a user has no well defined identifier for their calendar user address, the URI of their principal resource can be used. This property SHOULD be searchable using the DAV:principal-property-search REPORT. The DAV:principal-search-property-set REPORT SHOULD identify this property as such. If not present, then the associated calendar user is not enabled for scheduling on the server. Definition: Daboo & Desruisseaux Expires September 9, 2012 [Page 13] Internet-Draft CalDAV Scheduling Extensions March 2012 Example: mailto:bernard@example.com mailto:bernard.desruisseaux@example.com 2.4.2. CALDAV:calendar-user-type Property Name: calendar-user-type Namespace: urn:ietf:params:xml:ns:caldav Purpose: Identifies the calendar user type of the associated principal resource. Value: Same values allowed for the iCalendar "CUTYPE" property parameter defined in Section 3.2.3 of [RFC5545]. Protected: This property MAY be protected. PROPFIND behavior: This property SHOULD NOT be returned by a PROPFIND allprop request (as defined in Section 14.2 of [RFC4918]). COPY/MOVE behavior: This property value SHOULD be preserved in COPY and MOVE operations. Description: Clients can query principal resources in order to lookup attendees available on the server. When doing this, it is useful to know, or restrict the query to, certain types of calendar user (e.g., only search for "people", or only search for "rooms"). This property MAY be defined on principal resources to indicate the type of calendar user associated with the principal resource. Its value is the same as the iCalendar "CUTYPE" property parameter that can be used on "ATTENDEE" properties. This property SHOULD be searchable using the DAV:principal- property-search REPORT. The DAV:principal-search-property-set REPORT SHOULD identify this property as such. Definition: Daboo & Desruisseaux Expires September 9, 2012 [Page 14] Internet-Draft CalDAV Scheduling Extensions March 2012 Example: INDIVIDUAL< /C:calendar-user-type> Daboo & Desruisseaux Expires September 9, 2012 [Page 15] Internet-Draft CalDAV Scheduling Extensions March 2012 3. Scheduling Operations When a calendar object resource is created, modified or removed from a calendar collection, the server examines the calendar data and checks to see whether the data represents a scheduling object resource. If it does, the server will automatically attempt to deliver a scheduling message to the appropriate calendar users. Several types of scheduling operations can occur in this case, equivalent to iTIP "REQUEST", "REPLY", "CANCEL", and "ADD" operations. 3.1. Identifying Scheduling Object Resources Calendar object resources on which the server performs scheduling operations are referred to as scheduling object resources. There are two types of scheduling object resources: organizer scheduling object resources, and attendee scheduling object resources. A calendar object resource is considered to be a valid organizer scheduling object resource if the "ORGANIZER" iCalendar property is present and set in all the calendar components to a value that matches one of the calendar user addresses of the owner of the calendar collection. A calendar object resource is considered to be a valid attendee scheduling object resource if the "ORGANIZER" iCalendar property is present and set in all the calendar components to the same value and doesn't match one of the calendar user addresses of the owner of the calendar collection, and at least one of the "ATTENDEE" iCalendar property values matches one of the calendar user addresses of the owner of the calendar collection. The creation of attendee scheduling object resources is typically done by the server, with the resource being created in an appropriate calendar collection (see Section 4.3). 3.2. Handling Scheduling Object Resources The server's behavior when processing a scheduling object resource depends on whether it is owned by the Organizer or an Attendee specified in the calendar data. 3.2.1. Organizer Scheduling Object Resources An Organizer can create, modify or remove a scheduling object resource. These operations are each described next, and how they are invoked via HTTP requests is described in Section 3.2.3. Daboo & Desruisseaux Expires September 9, 2012 [Page 16] Internet-Draft CalDAV Scheduling Extensions March 2012 The Organizer of a calendar component can also be an Attendee of that calendar component. In such cases the server MUST NOT send a scheduling message to the Attendee that matches the Organizer. The server MUST take into account scheduling privileges as described in Section 6 when handling each type of scheduling operation. Restrictions on calendar object resources defined in Section 4.1 of [RFC4791] MUST also be enforced when handling each type of scheduling operation. The server SHOULD reject any attempt to set the "PARTSTAT" iCalendar property parameter value of the "ATTENDEE" iCalendar property of other users in the calendar object resource to a value other than "NEEDS-ACTION" if the "SCHEDULE-AGENT" property parameter value is not present or set to the value "SERVER". The server MAY reject attempts to create a scheduling object resource that specifies a "UID" property value already specified in a scheduling object resource contained in another calendar collection of the Organizer. 3.2.1.1. Create When an Organizer creates a scheduling object resource, the server MUST inspect each "ATTENDEE" property to determine whether to send a scheduling message. The table below indicates the appropriate iTIP method used by the server, taking into account any "SCHEDULE-AGENT" property parameter (see Section 7.1) specified on each "ATTENDEE" property. +------------------+-------------+ | SCHEDULE-AGENT | iTIP METHOD | +------------------+-------------+ | SERVER (default) | REQUEST | | | | | CLIENT | -- | | | | | NONE | -- | +------------------+-------------+ The server MUST add a "SCHEDULE-STATUS" iCalendar property parameter (see Section 7.3) to the "ATTENDEE" iCalendar property in the scheduling object resource being created, and set its value as described in Section 3.2.9. This will result in the created calendar object resource differing from the calendar data sent in the HTTP request. As a result clients MAY reload the calendar data from the server in order to update to the new server generated state Daboo & Desruisseaux Expires September 9, 2012 [Page 17] Internet-Draft CalDAV Scheduling Extensions March 2012 information. Servers MUST NOT set the "SCHEDULE-STATUS" property parameter on the "ATTENDEE" property of Attendees for which it did not attempt to deliver a scheduling message. The server MUST return an error with the CALDAV:allowed-organizer- scheduling-object-change precondition code (Section 3.2.4.3) when the Organizer attempts to change the iCalendar data in a manner that is forbidden. 3.2.1.2. Modify When an Organizer modifies a scheduling object resource, the server MUST inspect each "ATTENDEE" property in both the original and modified iCalendar data on a per-instance basis to determine whether to send a scheduling message. The table below indicates the appropriate iTIP method used by the server, taking into account any "SCHEDULE-AGENT" property parameter (see Section 7.1) specified on each "ATTENDEE" property. The values "SERVER", "CLIENT", and "NONE" in the top and left titles of the table refer to the "SCHEDULE-AGENT" parameter value of the "ATTENDEE" property, and the values "" and "" are used to cover the cases where the "ATTENDEE" property is not present (Original) or is being removed (Modified). +---------------+-----------------------------------------------+ | | Modified | | +-----------+-----------+-----------+-----------+ | | | SERVER | CLIENT | NONE | | | | (default) | | | +===+===========+===========+===========+===========+===========+ | | | -- | REQUEST / | -- | -- | | O | | | ADD | | | | r +-----------+-----------+-----------+-----------+-----------+ | i | SERVER | CANCEL | REQUEST | CANCEL | CANCEL | | g | (default) | | | | | | i +-----------+-----------+-----------+-----------+-----------+ | n | CLIENT | -- | REQUEST / | -- | -- | | a | | | ADD | | | | l +-----------+-----------+-----------+-----------+-----------+ | | NONE | -- | REQUEST / | -- | -- | | | | | ADD | | | +---+-----------+-----------+-----------+-----------+-----------+ The server MUST add a "SCHEDULE-STATUS" iCalendar property parameter to the "ATTENDEE" iCalendar property in the scheduling object resource being modified, and set its value as described in Section 3.2.9. This will result in the created calendar object resource differing from the calendar data sent in the HTTP request. As a result clients MAY reload the calendar data from the server in Daboo & Desruisseaux Expires September 9, 2012 [Page 18] Internet-Draft CalDAV Scheduling Extensions March 2012 order to update to the new server generated state information. The server MUST return an error with the CALDAV:allowed-organizer- scheduling-object-change precondition code (Section 3.2.4.3) when the Organizer attempts to change the iCalendar data in a manner that is forbidden. 3.2.1.3. Remove When an Organizer removes a scheduling object resource, the server MUST inspect each "ATTENDEE" property to determine whether to send a scheduling message. The table below indicates the appropriate iTIP method used by the server, taking into account any "SCHEDULE-AGENT" property parameter (see Section 7.1) specified on each "ATTENDEE" property. +------------------+-------------+ | SCHEDULE-AGENT | iTIP METHOD | +------------------+-------------+ | SERVER (default) | CANCEL | | | | | CLIENT | -- | | | | | NONE | -- | +------------------+-------------+ 3.2.2. Attendee Scheduling Object Resources An Attendee can create, modify or remove a scheduling object resource. These operations are each described next, and how they are invoked via HTTP requests is described in Section 3.2.3. 3.2.2.1. Allowed Attendee Changes Attendees are allowed to make some changes to a scheduling object resource, though key properties such as start time, end time, location, and summary are typically under the control of the Organizer. The server MUST allow Attendees to: 1. change their own "PARTSTAT" iCalendar property parameter value. 2. add, modify or remove any "TRANSP" iCalendar properties. 3. add, modify or remove any "PERCENT-COMPLETE" iCalendar properties. Daboo & Desruisseaux Expires September 9, 2012 [Page 19] Internet-Draft CalDAV Scheduling Extensions March 2012 4. add, modify or remove any "COMPLETED" iCalendar properties. 5. add, modify or remove any "VALARM" iCalendar components. 6. add, modify or remove the "CALSCALE" iCalendar property within the top-level "VCALENDAR" component. 7. modify the "PRODID" iCalendar property within the top-level "VCALENDAR" component. 8. add "EXDATE" iCalendar properties and possibly remove components for overridden recurrence instances. 9. add, modify or remove any "CREATED", "DTSTAMP" and "LAST- MODIFIED" iCalendar properties. 10. add, modify or remove "SCHEDULE-STATUS" iCalendar property parameters on "ATTENDEE" properties that have a "SCHEDULE-AGENT" parameter set to "CLIENT". 11. add new components to represent overridden recurrence instances, provided the only changes to the recurrence instance follow the rules above. The server MUST return an error with the CALDAV:allowed-attendee- scheduling-object-change precondition code (Section 3.2.4.4) when the Attendee attempts to change the iCalendar data in a manner forbidden by the server. 3.2.2.2. Create Typically an Attendee does not create scheduling object resources, as scheduling messages delivered to them on the server are automatically processed by the server and placed on one of their calendars (see Section 4). However, in some cases a scheduling message can get delivered directly to the client (e.g., via email [RFC6047]), and the Attendee might wish to store that on the server. In that case the client creates a scheduling object resource in a calendar belonging to the Attendee. It can then set the "SCHEDULE-AGENT" iCalendar property parameter on all "ORGANIZER" iCalendar properties in the resource to determine how the server treats the resource. The value of the "SCHEDULE-AGENT" iCalendar property parameter on all "ORGANIZER" iCalendar properties MUST be the same. Daboo & Desruisseaux Expires September 9, 2012 [Page 20] Internet-Draft CalDAV Scheduling Extensions March 2012 +----------------+--------------------------------------------------+ | SCHEDULE-AGENT | Action | +----------------+--------------------------------------------------+ | SERVER | The server will attempt to process changes to | | (default) | the resource using the normal rules for attendee | | | scheduling object resources. | | | | | CLIENT | The server does no special processing of the | | | resource. The client is assumed to be handling | | | Attendee replies etc. | | | | | NONE | The server does no special processing of the | | | resource. | +----------------+--------------------------------------------------+ In some cases a server might not be able to process an Attendee scheduling object resource that originated from another system (i.e., where the server is unable to deliver scheduling messages to the Organizer). In such cases the server MUST add a "SCHEDULE-STATUS" iCalendar property parameter to all "ORGANIZER" iCalendar properties in the resource with a value indicating an error. 3.2.2.3. Modify When a scheduling object resource is modified by an Attendee, the server behavior depends on the value of the "SCHEDULE-AGENT" iCalendar property parameter on the "ORGANIZER" iCalendar properties: +----------------+--------------------------------------------------+ | SCHEDULE-AGENT | Action | +----------------+--------------------------------------------------+ | SERVER | The server will attempt to process the update | | (default) | using the behavior listed below. | | | | | CLIENT | The server does no special processing of the | | | resource. The client is assumed to be handling | | | any Attendee replies etc. | | | | | NONE | The server does no special processing of the | | | resource. | +----------------+--------------------------------------------------+ The server will inspect the changes by comparing the new scheduling object resource with the existing scheduling object resource. If the Attendee changes one or more "PARTSTAT" iCalendar property values on any component, or adds an overridden component with a changed "PARTSTAT" property, then the server MUST deliver an iTIP Daboo & Desruisseaux Expires September 9, 2012 [Page 21] Internet-Draft CalDAV Scheduling Extensions March 2012 "REPLY" scheduling message to the Organizer to indicate the new participation status of the Attendee. If the Attendee adds an "EXDATE" property value to effectively remove a recurrence instance, the server MUST deliver an iTIP "REPLY" scheduling message to the Organizer to indicate that the Attendee has declined the instance. The server MUST add a "SCHEDULE-STATUS" iCalendar property parameter to the "ORGANIZER" iCalendar property in the scheduling object resource being updated, and set its value as described in Section 3.2.9. This will result in the updated calendar object resource differing from the calendar data sent in the HTTP request. As a result clients MAY reload the calendar data from the server in order to update to the new server generated state information. 3.2.2.4. Remove When a scheduling object resource is removed by an Attendee, the server behavior depends on the value of the "SCHEDULE-AGENT" iCalendar property parameter on the "ORGANIZER" iCalendar properties: +----------------+--------------------------------------------------+ | SCHEDULE-AGENT | Action | +----------------+--------------------------------------------------+ | SERVER | The server will attempt to process the removal | | (default) | taking into account any "Schedule-Reply" request | | | header as per Section 8.1. | | | | | CLIENT | The server does no special processing of the | | | resource. The client is assumed to be handling | | | any Attendee replies etc. | | | | | NONE | The server does no special processing of the | | | resource. | +----------------+--------------------------------------------------+ 3.2.3. HTTP Methods This section describes how use of various HTTP methods on a scheduling object resource will cause a create, modify or remove operation on that resource as described above. The use of these methods is subject to the restrictions in [RFC4791], in addition to what is described below. Daboo & Desruisseaux Expires September 9, 2012 [Page 22] Internet-Draft CalDAV Scheduling Extensions March 2012 3.2.3.1. PUT When the server receives a PUT method request it MUST execute the following operations, provided all appropriate preconditions are met: +------------------------+--------------------------+---------------+ | Existing Destination | Resulting Destination | Server | | Resource | Resource | Operation | +------------------------+--------------------------+---------------+ | None | Calendar object resource | None | | | | | | None | Scheduling object | Create | | | resource | | | | | | | Calendar object | Calendar object resource | None | | resource | | | | | | | | Calendar object | Scheduling object | Create | | resource | resource | | | | | | | Scheduling object | Calendar object resource | Remove | | resource | | | | | | | | Scheduling object | Scheduling object | Modify | | resource | resource | | +------------------------+--------------------------+---------------+ 3.2.3.2. DELETE When the server receives a DELETE method request targeted at a scheduling object resource it MUST execute the Remove operation. When the server receives a DELETE method request targeted at a calendar collection it MUST execute the Remove operation on all scheduling object resources contained in the calendar collection. 3.2.3.3. COPY When the server receives a COPY method request it MUST execute the following operations based on the source and destination collections in the request: Daboo & Desruisseaux Expires September 9, 2012 [Page 23] Internet-Draft CalDAV Scheduling Extensions March 2012 +-----------------------+------------------------+------------------+ | Source Collection | Destination Collection | Server Operation | +-----------------------+------------------------+------------------+ | Non-calendar | Non-calendar | None | | collection | collection | | | | | | | Non-calendar | Calendar collection | (1) | | collection | | | | | | | | Calendar collection | Non-calendar | None | | | collection | | | | | | | Calendar collection | Calendar collection | (2) | +-----------------------+------------------------+------------------+ Note 1. The rules in Section 3.2.3.1 are applied for the destination of the COPY request. Note 2. The server MAY reject this as per Section 3.2.4.1, otherwise None. The behavior of a COPY method request on a calendar collection is undefined. 3.2.3.4. MOVE When the server receives a MOVE method request it MUST execute the following operations based on the source and destination collections in the request: +-----------------------+------------------------+------------------+ | Source Collection | Destination Collection | Server Operation | +-----------------------+------------------------+------------------+ | Non-calendar | Non-calendar | None | | collection | collection | | | | | | | Non-calendar | Calendar collection | (1) | | collection | | | | | | | | Calendar collection | Non-calendar | (2) | | | collection | | | | | | | Calendar collection | Calendar collection | None | +-----------------------+------------------------+------------------+ Note 1. The rules in Section 3.2.3.1 are applied for the destination of the MOVE request. Daboo & Desruisseaux Expires September 9, 2012 [Page 24] Internet-Draft CalDAV Scheduling Extensions March 2012 Note 2. The rules in Section 3.2.3.2 are applied for the source of the MOVE request. The behavior of a MOVE method request on a calendar collection is undefined. 3.2.4. Additional Method Preconditions This specification defines method preconditions (see Section 16 of WebDAV [RFC4918]), in addition to the ones in [RFC4791], to provide machine-parseable information in error responses. 3.2.4.1. CALDAV:unique-scheduling-object-resource Precondition Name: unique-scheduling-object-resource Namespace: urn:ietf:params:xml:ns:caldav Apply to: PUT, COPY, and MOVE Use with: 403 Forbidden Purpose: (precondition) -- Servers MAY reject requests to create a scheduling object resource with an iCalendar "UID" property value already in use by another scheduling object resource owned by the same user in other calendar collections. Servers SHOULD report the URL of the scheduling object resource that is already making use of the same "UID" property value in the DAV:href element. Definition: Example: /home/bernard/calendars/personal/abc123.ics 3.2.4.2. CALDAV:same-organizer-in-all-components Precondition Name: same-organizer-in-all-components Namespace: urn:ietf:params:xml:ns:caldav Daboo & Desruisseaux Expires September 9, 2012 [Page 25] Internet-Draft CalDAV Scheduling Extensions March 2012 Apply to: PUT, COPY, and MOVE Use with: 403 Forbidden Purpose: (precondition) -- All the calendar components in a scheduling object resource MUST contain the same "ORGANIZER" property value when present. Definition: 3.2.4.3. CALDAV:allowed-organizer-scheduling-object-change Precondition Name: allowed-organizer-scheduling-object-change Namespace: urn:ietf:params:xml:ns:caldav Apply to: PUT, COPY, and MOVE Use with: 403 Forbidden Purpose: (precondition) -- Servers MAY impose restrictions on modifications allowed by an Organizer. For instance, servers MAY prevent the Organizer setting the "PARTSTAT" property parameter to a value other than "NEEDS-ACTION" if the corresponding "ATTENDEE" property has the "SCHEDULE-AGENT" property parameter set to "SERVER", or has no "SCHEDULE-AGENT" property parameter. See Section 3.2.1. Definition: 3.2.4.4. CALDAV:allowed-attendee-scheduling-object-change Precondition Name: allowed-attendee-scheduling-object-change Namespace: urn:ietf:params:xml:ns:caldav Apply to: PUT, COPY, and MOVE Use with: 403 Forbidden Purpose: (precondition) -- Servers MAY impose restrictions on modifications allowed by an Attendee. Attendee modifications that servers MUST allow are specified in Section 3.2.2.1. Daboo & Desruisseaux Expires September 9, 2012 [Page 26] Internet-Draft CalDAV Scheduling Extensions March 2012 Definition: 3.2.5. DTSTAMP and SEQUENCE Properties The server MUST ensure that a "DTSTAMP" iCalendar property is present and set the value to the UTC time that the scheduling message was generated (as required by iCalendar). The server MUST ensure that for each type of scheduling operation, the "SEQUENCE" iCalendar property value is updated as per iTIP [RFC5546]. 3.2.6. Restrict Recurrence Instances Sent to Attendees Servers MUST ensure that Attendees only get information about recurrence instances that explicitly include them as an Attendee, when delivering scheduling messages for recurring calendar components. For example, if an Attendee is invited to only a single instance of a recurring event, the organizer scheduling object resource will contain an overridden instance in the form of a separate calendar component. That separate calendar component will include the "ATTENDEE" property referencing the "one-off" Attendee. That Attendee will not be listed in any other calendar components in the scheduling object resource. Any scheduling messages delivered to the Attendee will only contain information about this overridden instance. As another example, an Attendee could be excluded from one instance of a recurring event. In that case the organizer scheduling object resource will include an overridden instance with an "ATTENDEE" list that does not include the Attendee being excluded. Any scheduling messages delivered to the Attendee will not specify the overridden instance but rather include an "EXDATE" property in the "master" component that defines the recurrence set. 3.2.7. Forcing the Server to Send a Scheduling Message The iCalendar property parameter "SCHEDULE-FORCE-SEND" defined in Section 7.2 can be used by a calendar user to force the server to send a scheduling message to an Attendee or the Organizer in a situation where the server would not normally send a scheduling message. For instance, an Organizer could use this property parameter to request an Attendee, that previously declined an invitation, to reconsider their participation status without being Daboo & Desruisseaux Expires September 9, 2012 [Page 27] Internet-Draft CalDAV Scheduling Extensions March 2012 forced to modify the event. 3.2.8. Attendee Participation Status This section specifies additional requirements on the handling of the "PARTSTAT" property parameter when the "SCHEDULE-AGENT" property parameter on the corresponding "ATTENDEE" property is set to the value "SERVER" or is not present. Servers MUST reset the "PARTSTAT" property parameter value of all "ATTENDEE" properties, except the one that corresponds to the Organizer, to "NEEDS-ACTION" when the Organizer reschedules an event. A reschedule of an event occurs when any "DTSTART", "DTEND", "DURATION", "DUE", "RRULE", "RDATE", or "EXDATE" property changes in a calendar component such that existing recurrence instances are impacted by the changes, as shown in the table below. +-----------+-------------------------------------------------------+ | Property | Server Action | +-----------+-------------------------------------------------------+ | DTSTART, | Any change to these properties MUST result in | | DTEND, | "PARTSTAT" being set to "NEEDS-ACTION" | | DURATION, | | | DUE | | | | | | | | | | | | RRULE | A change to or addition of this property that results | | | in the addition of new recurring instances or a | | | change in time for existing recurring instances MUST | | | result in "PARTSTAT" being reset to "NEEDS-ACTION" on | | | each affected component. | | | | | | | | | | | RDATE | A change to or addition of this property that results | | | in the addition of new recurring instances or a | | | change in time for existing recurring instances MUST | | | result in "PARTSTAT" being reset to "NEEDS-ACTION" on | | | each affected component. | | | | | | | | | | Daboo & Desruisseaux Expires September 9, 2012 [Page 28] Internet-Draft CalDAV Scheduling Extensions March 2012 | EXDATE | A change to or removal of this property that results | | | in the re-instatement of recurring instances MUST | | | result in "PARTSTAT" being set to "NEEDS-ACTION" on | | | each affected component. | +-----------+-------------------------------------------------------+ The server MAY allow the Organizer's client to change an Attendee's "PARTSTAT" property parameter value to "NEEDS-ACTION" at any other time (e.g., when the "LOCATION" property value changes, an Organizer might wish to re-invite Attendees who might be impacted by the change). 3.2.9. Schedule Status Values When scheduling with an Attendee there are two types of status information that can be returned during the operation. The first type of status information is a "delivery" status that indicates whether the scheduling message from the Organizer to the Attendee was delivered or not, or what the current status of delivery is. The second type of status information is a "reply" status corresponding to the Attendee's own "REQUEST-STATUS" information from the scheduling message reply that is sent back to the Organizer. Similarly, when an Attendee sends a reply back to the Organizer, there will be "delivery" status information for the scheduling message sent to the Organizer. However, there is no "REQUEST-STATUS" sent back by the Organizer, so there is no equivalent of the "reply" status as per scheduling messages to Attendees. The "delivery" status information on an "ORGANIZER" or "ATTENDEE" iCalendar property is conveyed in the "SCHEDULE-STATUS" property parameter value (Section 7.3). The status code value for "delivery" status can be one of the following: Daboo & Desruisseaux Expires September 9, 2012 [Page 29] Internet-Draft CalDAV Scheduling Extensions March 2012 +----------+--------------------------------------------------------+ | Delivery | Description | | Status | | | Code | | +----------+--------------------------------------------------------+ | 1.0 | The scheduling message is pending. i.e. the server is | | | still in the process of sending the message. The | | | status code value can be expected to change once the | | | server has completed its sending and delivery | | | attempts. | | | | | | | | | | | 1.1 | The scheduling message has been successfully sent. | | | However, the server does not have explicit information | | | about whether the scheduling message was successfully | | | delivered to the recipient. This state can occur with | | | "store and forward" style scheduling protocols such as | | | iMIP [RFC6047] (iTIP using email). | | | | | | | | | | | 1.2 | The scheduling message has been successfully | | | delivered. | | | | | | | | | | | 3.7 | The scheduling message was not delivered because the | | | server did not recognize the calendar user address as | | | a valid calendar user. Note that this code applies to | | | both Organizer and Attendee calendar user addresses. | | | | | | | | | | | 3.8 | The scheduling message was not delivered due to | | | insufficient privileges. Note that this code applies | | | to both privileges granted by both the Organizer and | | | Attendee calendar users. | | | | | | | | | | | 5.1 | The scheduling message was not delivered because the | | | server could not complete delivery of the message. | | | This is likely due to a temporary failure, and the | | | originator can try to send the message again at a | | | later time. | | | | | | | Daboo & Desruisseaux Expires September 9, 2012 [Page 30] Internet-Draft CalDAV Scheduling Extensions March 2012 | 5.2 | The scheduling message was not delivered because the | | | server was not able to find a way to deliver the | | | message. This is likely a permanent failure, and the | | | originator ought not try to send the message again, at | | | least without verifying/correcting the calendar user | | | address of the recipient. | | | | | | | | | | | 5.3 | The scheduling message was not delivered and was | | | rejected because scheduling with that recipient is not | | | allowed. This is likely a permanent failure, and the | | | originator ought not try to send the message again. | +----------+--------------------------------------------------------+ The status code for "reply" status can be any of the valid iTIP [RFC5546] "REQUEST-STATUS" values. The 1.xx "REQUEST-STATUS" codes are new. This specification modifies item (2) of Section 3.6 of [RFC5546] by adding the following restriction: For a 1.xx code, all components MUST have exactly the same code. Definition of the new 1.xx codes is as follows: 3.2.9.1. Status Code 1.0 Status Code: 1.0 Status Description: Pending. Status Exception Data: None. Description: Delivery of the iTIP message is pending. 3.2.9.2. Status Code 1.1 Status Code: 1.1 Status Description: Sent. Status Exception Data: None. Description: The iTIP message has been sent, though no information about successful delivery is known. Daboo & Desruisseaux Expires September 9, 2012 [Page 31] Internet-Draft CalDAV Scheduling Extensions March 2012 3.2.9.3. Status Code 1.2 Status Code: 1.2 Status Description: Delivered. Status Exception Data: None. Description: The iTIP message has been sent and delivered. 3.2.10. Avoiding Conflicts when Updating Scheduling Object Resources Scheduling object resources on the server might change frequently as Attendees change their participation status, triggering updates to the Organizer, and refreshes of other Attendees' copies of the scheduling object resource. This can lead to an "inconsequential" change to a calendar user's data - one that does not directly impact their own participation status. When this occurs, clients have to reload calendar data and reconcile with changes being made by calendar users. To avoid the need for this, the server can instead merge calendar data changes from a client with changes made as a the result of a scheduling operation carried out by some other calendar user. This specification introduces a new WebDAV resource property CALDAV: schedule-tag with a corresponding response header "Schedule-Tag", and a new "If-Schedule-Tag-Match" request header to allow client changes to be appropriately merged with server changes in the case where the changes on the server were the result of an "inconsequential" scheduling message update (one which simply updates the status information of Attendees due to a reply from another Attendee). Servers MUST support requests targeted at scheduling object resources using the "If-Schedule-Tag-Match" request header. Servers MUST support the "Schedule-Tag" response header and CALDAV:schedule-tag property for scheduling object resources. Servers MUST automatically resolve conflicts with "inconsequential" changes done to scheduling object resources when the "If-Schedule-Tag-Match" request header is specified. The If-Schedule-Tag-Match request header applies only to the Request- URI, and not to the Destination of a COPY or MOVE. A response to any successful GET or PUT request targeting a scheduling object resource MUST include a Schedule-Tag response header with the value set to the same value as the CALDAV:schedule- tag WebDAV property of the resource. Daboo & Desruisseaux Expires September 9, 2012 [Page 32] Internet-Draft CalDAV Scheduling Extensions March 2012 A response to any successful COPY or MOVE request that specifies a Destination request header targeting a scheduling object resource MUST include a Schedule-Tag response header with the value set to the same value as the CALDAV:schedule-tag WebDAV property of the resource identified in the Request-URI. Clients SHOULD use the If-Schedule-Tag-Match header on requests that update scheduling object resources, instead of HTTP ETag-based precondition tests (e.g., If-Match). Normal ETag-based precondition tests are used in all other cases, e.g., for synchronization. The value of the CALDAV:schedule-tag property changes according to these rules: o For an Organizer's copy of a scheduling object resource: 1. The server MUST NOT change the CALDAV:schedule-tag property value when the scheduling object resource is updated as the result of automatically processing a scheduling message reply from an Attendee. For instance, when an Attendee replies to the Organizer, the CALDAV:schedule-tag property is unchanged after the Organizer's scheduling object resource has been automatically updated by the server with the Attendee's new participation status. 2. The server MUST change CALDAV:schedule-tag property value when the scheduling object resource is changed directly via an HTTP request (e.g., PUT, COPY or MOVE). o For an Attendee's copy of a scheduling object resource: 1. The server MUST change the CALDAV:schedule-tag property value when the scheduling object resource is changed as the result of processing a scheduling message update from an Organizer that contains changes other than just the participation status of Attendees. 2. The server MUST NOT change the CALDAV:schedule-tag property value when the scheduling object resource is changed as the result of processing a scheduling message update from an Organizer that only specify changes in the participation status of Attendees. For instance, when Attendee "A" replies to Organizer "O", and Attendee "B" receives a scheduling message update from Organizer "O" with the new participation status of Attendee "A", the CALDAV:schedule-tag property of Attendee "B"s scheduling object resource would remain the same. Daboo & Desruisseaux Expires September 9, 2012 [Page 33] Internet-Draft CalDAV Scheduling Extensions March 2012 3. The server MUST change the CALDAV:schedule-tag property value when the scheduling object resource is changed directly via an HTTP request (e.g., PUT, COPY or MOVE). 3.2.10.1. PUT Clients MAY use the If-Schedule-Tag-Match request header to do a PUT request that ensures that "inconsequential" changes on the server do not result in a precondition error. The value of the request header is set to the last Schedule-Tag value received for the resource being modified. If the value of the If-Schedule-Tag-Match header matches the current value of the CALDAV:schedule-tag property the server MUST take any "ATTENDEE" property changes for all Attendees other than the owner of the scheduling object resource and apply those to the new resource being stored. Otherwise, the server MUST fail the request with a 412 Precondition Failed status code. 3.2.10.2. DELETE, COPY or MOVE Clients MAY use the If-Schedule-Tag-Match request header to do a DELETE, COPY or MOVE request that ensures that "inconsequential" changes on the server do not result in a precondition error. The value of the request header is set to the last Schedule-Tag value received for the resource being deleted. If the value of the If- Schedule-Tag-Match header matches the current value of the CALDAV: schedule-tag property the server performs the normal DELETE, COPY or MOVE request processing for the resource. Otherwise, the server MUST fail the request with a 412 Precondition Failed status code. Daboo & Desruisseaux Expires September 9, 2012 [Page 34] Internet-Draft CalDAV Scheduling Extensions March 2012 4. Processing Incoming Scheduling Messages Scheduling operations can cause the delivery of a scheduling message into an Organizer's or Attendee's scheduling Inbox collection. Servers MUST automatically process incoming scheduling messages using the rules defined by [RFC5546], by creating or updating the corresponding scheduling object resources on calendars owned by the owner of the scheduling Inbox collection. In addition, the scheduling message is stored in the scheduling Inbox collection as an indicator to the client that a scheduling operation has taken place. Scheduling messages are typically removed from the scheduling Inbox collection by the client once the calendar user has acknowledged the change. The server MUST take into account privileges on the scheduling Inbox collection when processing incoming scheduling messages, to determine whether delivery of the scheduling message is allowed. Privileges on calendars containing any matching scheduling object resource are not considered in this case (i.e., a schedule message from another user can cause modifications to resources in calendar collections that the other user would not normally have read or write access to). Additionally, servers MUST take into account any scheduling Inbox collection preconditions (see Section 2.2) when delivering the scheduling message, and it MUST take into account the similar preconditions on any calendar collection which contains, or would contain, the corresponding scheduling object resource. 4.1. Processing Organizer Requests, Additions, and Cancellations For a scheduling message sent by an Organizer, the server first tries to locate a corresponding scheduling object resource belonging to the Attendee. If no matching scheduling object resource exists, the server treats the scheduling message as a new message, otherwise it is treated as an update. In the case of a new message, the server MUST process the scheduling message and create a new scheduling object resource as per Section 4.3. In the case of an update, the server MUST process the scheduling message and update the matching scheduling object resource belonging to the Attendee to reflect the changes sent by the Organizer. In each case, the scheduling message MUST only appear in the Attendee's scheduling Inbox collection once all automatic processing has been done. Daboo & Desruisseaux Expires September 9, 2012 [Page 35] Internet-Draft CalDAV Scheduling Extensions March 2012 4.2. Processing Attendee Replies For a scheduling message reply sent by an Attendee, the server first locates the corresponding scheduling object resource belonging to the Organizer. If the corresponding scheduling object resource cannot be found, the server SHOULD ignore the scheduling message. The server MUST then update the "PARTSTAT" iCalendar property parameter value of each "ATTENDEE" iCalendar property in the scheduling object resource to match the changes indicated in the reply (taking into account the fact that an Attendee could have created a new overridden iCalendar component to indicate different participation status on one or more instances of a recurring event). The server MUST also update or add the "SCHEDULE-STATUS" property parameter on each matching "ATTENDEE" iCalendar property and set its value to that of the "REQUEST-STATUS" property in the reply, or to "2.0" if "REQUEST-STATUS" is not present (also taking into account recurrence instances). If there are multiple "REQUEST-STATUS" properties in the reply, the "SCHEDULE-STATUS" property parameter value is set to a comma-separated list of status codes, one from each "REQUEST-STATUS" property. The server SHOULD send scheduling messages to all the other Attendees indicating the change in participation status of the Attendee replying, subject to the recurrence requirements of Section 3.2.6. The scheduling message MUST only appear in the Organizer's scheduling Inbox collection once all automatic processing has been done. 4.3. Default Calendar Collection The server is REQUIRED to process scheduling messages received for an Attendee by creating a new scheduling object resource in a calendar collection belonging to the Attendee, when one does not already exist. A calendar user that is an Attendee in a scheduling operation MUST have at least one valid calendar collection available. If there is no valid calendar collection, then the server MUST reject the attempt to deliver the scheduling message to the Attendee. Servers MAY provide support for a default calendar collection, that is, the calendar collection in which new scheduling object resources will be created. The CALDAV:schedule-default-calendar-URL WebDAV property, which can be present on the scheduling Inbox collection of a calendar user, specifies if this calendar user has a default calendar collection. See Section 9.2. Servers SHOULD create new scheduling object resources in the default Daboo & Desruisseaux Expires September 9, 2012 [Page 36] Internet-Draft CalDAV Scheduling Extensions March 2012 calendar collection, if the CALDAV:schedule-default-calendar-URL WebDAV property is set. Servers MAY allow clients to change the default calendar collection by changing the value of the CALDAV:schedule-default-calendar-URL WebDAV property on the scheduling Inbox collection. However, the server MUST ensure that any new value for that property refers to a valid calendar collection belonging to the owner of the scheduling Inbox collection. Servers MUST reject any attempt to delete the default calendar collection. 4.3.1. Additional Method Preconditions This specification defines additional method preconditions (see Section 16 of WebDAV [RFC4918]) to provide machine-parseable information in error responses. 4.3.1.1. CALDAV:default-calendar-needed Precondition Name: default-calendar-needed Namespace: urn:ietf:params:xml:ns:caldav Apply to: DELETE Use with: 403 Forbidden Purpose: (precondition) -- The client attempted to delete the calendar collection currently referenced by the CALDAV:schedule- default-calendar-URL property, or attempted to remove the CALDAV: schedule-default-calendar-URL property on the scheduling Inbox collection on a server that doesn't allow such operations. Definition: 4.3.1.2. CALDAV:valid-schedule-default-calendar-URL Precondition Name: valid-schedule-default-calendar-URL Namespace: urn:ietf:params:xml:ns:caldav Daboo & Desruisseaux Expires September 9, 2012 [Page 37] Internet-Draft CalDAV Scheduling Extensions March 2012 Apply to: PROPPATCH Use with: 403 Forbidden Purpose: (precondition) -- The client attempted to set the CALDAV: schedule-default-calendar-URL property to a DAV:href element that doesn't reference a valid calendar collection. Note: Servers that do not allow clients to change the CALDAV:schedule-default- calendar-URL property would simply return the DAV:cannot-modify- protected-property precondition defined in Section 16 of WebDAV [RFC4918]. Definition: Daboo & Desruisseaux Expires September 9, 2012 [Page 38] Internet-Draft CalDAV Scheduling Extensions March 2012 5. Request for Busy Time Information Busy time information of one or more calendar users can be determined by submitting a POST request targeted at the scheduling Outbox collection of the calendar user requesting the information (the Organizer). To accomplish this, the request body MUST contain a "VFREEBUSY" calendar component with the "METHOD" iCalendar property set to the value "REQUEST" as specified in Section 3.3.2 of iTIP [RFC5546]. The resource identified by the Request-URI MUST be a resource collection of type CALDAV:schedule-outbox (Section 2.1). The "ORGANIZER" property in the "VFREEBUSY" component MUST match that of the calendar user who "owns" the Outbox collection. A response to a busy time request that indicates status for one or more calendar users MUST be an XML document with a CALDAV:schedule- response XML element as its root element. This element MUST contain one CALDAV:response element for each calendar user, with each of those containing elements that indicate which calendar user they correspond to, the scheduling status for that calendar user, any error codes and an optional description. For a successful busy time request, a CALDAV:calendar-data element is also present for each calendar user, containing the actual busy time information (i.e., an iCalendar "VFREEBUSY" component). See Section 10.1 for the detail on the child elements. See Appendix B.5 for an example busy time request and response. 5.1. Status Codes The list below summarizes the most common status codes used for this method. However, clients should be prepared to handle other 2/3/4/ 5xx series status codes as well. 200 (OK) - The command succeeded. 204 (No Content) - The command succeeded. 400 (Bad Request) - The client has provided an invalid scheduling message. 403 (Forbidden) - The client cannot submit a scheduling message to the specified Request-URI. 404 (Not Found) - The URL in the Request-URI was not present. 423 (Locked) - The specified resource is locked and the client either is not a lock owner or the lock type requires a lock token to be submitted and the client did not submit it. Daboo & Desruisseaux Expires September 9, 2012 [Page 39] Internet-Draft CalDAV Scheduling Extensions March 2012 5.2. Additional Method Preconditions The following are existing preconditions that are reused for the POST method on an Outbox collection. o DAV:need-privileges [RFC3744] o CALDAV:supported-calendar-data [RFC4791] o CALDAV:valid-calendar-data [RFC4791] o CALDAV:max-resource-size [RFC4791] The following are new method preconditions for the POST method on an Outbox collection. 5.2.1. CALDAV:valid-scheduling-message Precondition Name: valid-scheduling-message Namespace: urn:ietf:params:xml:ns:caldav Apply to: POST Use with: 400 Bad Request Purpose: (precondition) -- The resource submitted in the POST request MUST obey all restrictions specified for the POST request (e.g., the scheduling message follow the restrictions of iTIP). Definition: 5.2.2. CALDAV:valid-organizer Precondition Name: valid-organizer Namespace: urn:ietf:params:xml:ns:caldav Apply to: POST Use with: 403 Forbidden Purpose: (precondition) -- The calendar user identified by the "ORGANIZER" property in the POST request's scheduling message MUST be the calendar user (or one of the calendar users) associated with the scheduling Outbox collection being targeted by the Daboo & Desruisseaux Expires September 9, 2012 [Page 40] Internet-Draft CalDAV Scheduling Extensions March 2012 request; Definition: Daboo & Desruisseaux Expires September 9, 2012 [Page 41] Internet-Draft CalDAV Scheduling Extensions March 2012 6. Scheduling Privileges New scheduling privileges are defined in this section. All the scheduling privileges MUST be non-abstract and MUST appear in the DAV:supported-privilege-set property of scheduling Outbox and Inbox collections on which they are defined. The tables specified in Appendix A clarify which scheduling methods (e.g., "REQUEST", "REPLY", etc.) are controlled by each scheduling privilege defined in this section. 6.1. Privileges on Scheduling Inbox Collections This section defines new WebDAV ACL [RFC3744] privileges that are for use on scheduling Inbox collections. These privileges determine whether delivery of scheduling messages from a calendar user is allowed by the calendar user who "owns" the scheduling Inbox collection. This allows calendar users to choose which other calendar users can schedule with them. Note that when a scheduling message is delivered to a calendar user, in addition to a scheduling object resource being created in the calendar user's scheduling Inbox collection, a new scheduling object resource might be created or an existing one updated in a calendar belonging to the calendar user. In that case, the ability to create or update the scheduling object resource in the calendar is controlled by the privileges assigned to the scheduling Inbox collection. The privileges defined in this section are ignored if applied to a resource other than a scheduling Inbox collection. 6.1.1. CALDAV:schedule-deliver Privilege CALDAV:schedule-deliver is an aggregate privilege as per Section 6.3. 6.1.2. CALDAV:schedule-deliver-invite Privilege The CALDAV:schedule-deliver-invite privilege controls the processing and delivery of scheduling messages coming from an Organizer. Daboo & Desruisseaux Expires September 9, 2012 [Page 42] Internet-Draft CalDAV Scheduling Extensions March 2012 6.1.3. CALDAV:schedule-deliver-reply Privilege The CALDAV:schedule-deliver-reply privilege controls the processing and delivery of scheduling messages coming from an Attendee. 6.1.4. CALDAV:schedule-query-freebusy Privilege The CALDAV:schedule-query-freebusy privilege controls freebusy requests targeted at the owner of the scheduling Inbox collection. 6.2. Privileges on Scheduling Outbox Collections This section defines new WebDAV ACL [RFC3744] privileges that are defined for use on scheduling Outbox collections. These privileges determine which calendar users are allowed to send scheduling messages on behalf of the calendar user who "owns" the scheduling Outbox collection. This allows calendar users to choose other calendar users who can act on their behalf (e.g. assistants working on behalf of their boss). The privileges defined in this section are ignored if applied to a resource other than a scheduling Outbox collection. 6.2.1. CALDAV:schedule-send Privilege CALDAV:schedule-send is an aggregate privilege as per Section 6.3. 6.2.2. CALDAV:schedule-send-invite Privilege The CALDAV:schedule-send-invite privilege controls the sending of scheduling messages by Organizers. Users granted the DAV:bind privilege on a calendar collection, or DAV:write privilege on scheduling object resources, will also need the CALDAV:schedule-send-invite privilege granted on the scheduling Outbox collection of the owner of the calendar collection or scheduling object resource in order to be allowed to create, modify or delete scheduling object resources in a way that will trigger the CalDAV server to deliver scheduling messages to attendees. Daboo & Desruisseaux Expires September 9, 2012 [Page 43] Internet-Draft CalDAV Scheduling Extensions March 2012 6.2.3. CALDAV:schedule-send-reply Privilege The CALDAV:schedule-send-reply privilege controls the sending of scheduling messages by Attendees. Users granted the DAV:bind privilege on a calendar collection, or DAV:write privilege on scheduling object resources, will also need the CALDAV:schedule-send-reply privilege granted on the scheduling Outbox collection of the owner of the calendar collection or scheduling object resource in order to be allowed to create, modify or delete scheduling object resources in a way that will trigger the CalDAV server to deliver scheduling message replies to the organizer. 6.2.4. CALDAV:schedule-send-freebusy Privilege The CALDAV:schedule-send-freebusy privilege controls the use of the POST method to submit scheduling messages that specify the scheduling method "REQUEST" with a "VFREEBUSY" calendar component. 6.3. Aggregation of Scheduling Privileges Server implementations MUST aggregate the scheduling privileges as follows: DAV:all MUST contain CALDAV:schedule-send and CALDAV:schedule- deliver; CALDAV:schedule-send MUST contain CALDAV:schedule-send-invite, CALDAV:schedule-send-reply, and CALDAV:schedule-send-freebusy; CALDAV:schedule-deliver MUST contain CALDAV:schedule-deliver- invite, CALDAV:schedule-deliver-reply, and CALDAV:schedule-query- freebusy. The following diagram illustrates how scheduling privileges are aggregated according to the above requirements. Daboo & Desruisseaux Expires September 9, 2012 [Page 44] Internet-Draft CalDAV Scheduling Extensions March 2012 [DAV:all] (aggregate) | +-- [CALDAV:schedule-deliver] (aggregate) | | | +-- [CALDAV:schedule-deliver-invite] | +-- [CALDAV:schedule-deliver-reply] | +-- [CALDAV:schedule-query-freebusy] | +-- [CALDAV:schedule-send] (aggregate) | +-- [CALDAV:schedule-send-invite] +-- [CALDAV:schedule-send-reply] +-- [CALDAV:schedule-send-freebusy] Daboo & Desruisseaux Expires September 9, 2012 [Page 45] Internet-Draft CalDAV Scheduling Extensions March 2012 7. Additional iCalendar Property Parameters This specification defines additional iCalendar property parameters to support the CalDAV scheduling extensions. 7.1. Schedule Agent Parameter Parameter Name: SCHEDULE-AGENT Purpose: To specify the agent expected to deliver scheduling messages to the corresponding Organizer or Attendee. Format Definition: This property parameter is defined by the following notation: scheduleagentparam = "SCHEDULE-AGENT" "=" ("SERVER" ; The server handles scheduling / "CLIENT" ; The client handles scheduling / "NONE" ; No scheduling / x-name ; Experimental type / iana-token) ; Other IANA registered type ; ; Default is SERVER Description: This property parameter MAY be specified on "ORGANIZER" or "ATTENDEE" iCalendar properties. In the absence of this parameter, the value "SERVER" MUST be used for the default behavior. The value determines whether or not a scheduling operation on a server will cause a scheduling message to be sent to the corresponding calendar user identified by the "ORGANIZER" or "ATTENDEE" property value. When the value "SERVER" is specified, or the parameter is absent, then it is the server's responsibility to send a scheduling message as part of a scheduling operation. When the value "CLIENT" is specified, that indicates that the client is handling scheduling messages with the calendar user itself. When "NONE" is specified, no scheduling messages are being sent to the calendar user. Servers MUST NOT include this parameter in any scheduling messages sent as the result of a scheduling operation. Clients MUST NOT include this parameter in any scheduling messages that they themselves send. The parameter value MUST be the same on every "ORGANIZER" property in a scheduling object resource. Daboo & Desruisseaux Expires September 9, 2012 [Page 46] Internet-Draft CalDAV Scheduling Extensions March 2012 The parameter value MUST be the same on each "ATTENDEE" property whose values match in a scheduling object resource. Servers and clients MUST treat x-name and iana-token values they do not recognize the same way as they would the "NONE" value. Example: ORGANIZER;SCHEDULE-AGENT=SERVER:mailto:bernard@example.com ATTENDEE;SCHEDULE-AGENT=NONE:mailto:cyrus@example.com 7.2. Schedule Force Send Parameter Parameter Name: SCHEDULE-FORCE-SEND Purpose: To force a scheduling message to be sent to the calendar user specified by the property. Format Definition: This property parameter is defined by the following notation: scheduleforcesendparam = "SCHEDULE-FORCE-SEND" "=" ("REQUEST" ; Force a "REQUEST" / "REPLY" ; Force a "REPLY" / iana-token) ; IANA registered method Description: This property parameter MAY be specified on "ATTENDEE" and "ORGANIZER" properties on which the "SCHEDULE-AGENT" property parameter is set to the value "SERVER" or is not specified. This property parameter is used to force a server to send a scheduling message to a specific calendar user in situations where the server would not send a scheduling message otherwise (e.g., when no change that warrants the delivery of a new scheduling message was performed on the scheduling object resource). An Organizer MAY specify this parameter on an "ATTENDEE" property with the value "REQUEST" to force a "REQUEST" scheduling message to be sent to this Attendee. An Attendee MAY specify this parameter on the "ORGANIZER" with the value "REPLY" to force a "REPLY" scheduling message to be sent to the Organizer. Servers MUST NOT preserve this property parameter in scheduling object resources, nor include it in any scheduling messages sent as the result of a scheduling operation. Clients MUST NOT include this parameter in any scheduling messages that they themselves send. Daboo & Desruisseaux Expires September 9, 2012 [Page 47] Internet-Draft CalDAV Scheduling Extensions March 2012 Servers MUST set the "SCHEDULE-STATUS" parameter of the "ATTENDEE" or "ORGANIZER" to 2.3 (i.e., "Success, invalid property parameter ignored", see Section 3.6 of [RFC5546]) when the "SCHEDULE-FORCE- SEND" parameter is set to a x-name or iana-token value they do not recognize. Example: ORGANIZER;SCHEDULE-FORCE-SEND=REPLY:mailto:cyrus@example.com ATTENDEE;SCHEDULE-FORCE-SEND=REQUEST:mailto:bernard@example.com 7.3. Schedule Status Parameter Parameter Name: SCHEDULE-STATUS Purpose: To specify the status codes returned from processing of the most recent scheduling message sent to the corresponding Attendee, or received from the corresponding Organizer. Format Definition: This property parameter is defined by the following notation: schedulestatusparam = "SCHEDULE-STATUS" "=" ( statcode / DQUOTE statcode *("," statcode) DQUOTE) ; "statcode" is defined in Section 3.8.8.3 of [RFC5545]. Value ; is a single "statcode" or a comma-separated list of "statcode" ; values. Description: This property parameter MAY be specified on the "ATTENDEE" and "ORGANIZER" properties. Servers MUST add this property parameter to any "ATTENDEE" properties corresponding to calendar users who were sent a scheduling message via a scheduling operation. Clients SHOULD NOT change or remove this parameter if it was provided by the server. In the case where the client is handling the scheduling, the client MAY add, change or remove this parameter to indicate the last scheduling message status it received. Servers MUST add this parameter to any "ORGANIZER" properties corresponding to calendar users who were sent a scheduling message reply by an Attendee via a scheduling operation. Clients SHOULD NOT change or remove this parameter if it was provided by the server. In the case where the client is handling the scheduling, the client MAY add, change or remove this parameter to indicate the last scheduling message status it received. Daboo & Desruisseaux Expires September 9, 2012 [Page 48] Internet-Draft CalDAV Scheduling Extensions March 2012 Servers MUST NOT include this parameter in any scheduling messages sent as the result of a scheduling operation. Clients MUST NOT include this parameter in any scheduling messages that they themselves send. Values for this property parameter are described in Section 3.2.9. Example: ATTENDEE;SCHEDULE-STATUS="2.0":mailto:bernard@example.com ATTENDEE;SCHEDULE-STATUS="2.0,2.4":mailto:cyrus@example.com Daboo & Desruisseaux Expires September 9, 2012 [Page 49] Internet-Draft CalDAV Scheduling Extensions March 2012 8. Additional Message Header Fields This specification defines additional HTTP request and response headers for use with CalDAV. 8.1. Schedule-Reply Request Header Schedule-Reply = "Schedule-Reply" ":" ("T" | "F") Example: Schedule-Reply: F When an Attendee removes a scheduling object resource as per Section 3.2.2.4, and the Schedule-Reply header is not present, or present and set to the value "T" (true), the server MUST send an appropriate reply scheduling message with the Attendee's "PARTSTAT" iCalendar property parameter value set to "DECLINED" as part of its normal scheduling operation processing. When the Schedule-Reply header is set to the value "F" (false), the server MUST NOT send a scheduling message as part of its normal scheduling operation processing. The Schedule-Reply request header is used by a client to indicate to a server whether or not a scheduling operation ought to occur when an Attendee deletes a scheduling object resource. In particular it controls whether a reply scheduling message is sent to the Organizer as a result of the removal. There are situations in which unsolicited scheduling messages need to be silently removed (or ignored) for security or privacy reasons. This request header allows the scheduling object resource to be removed if such a need arises. 8.2. Schedule-Tag Response Header The Schedule-Tag response header provides the current value of the CALDAV:schedule-tag property value. The behavior of this response header is described in Section 3.2.10. All scheduling object resources MUST support the Schedule-Tag header. Schedule-Tag = "Schedule-Tag" ":" opaque-tag ; "opaque-tag" is defined in Section 3.11 of [RFC2616] Daboo & Desruisseaux Expires September 9, 2012 [Page 50] Internet-Draft CalDAV Scheduling Extensions March 2012 Example: Schedule-Tag: "12ab34-cd56ef" 8.3. If-Schedule-Tag-Match Request Header The If-Schedule-Tag-Match request header field is used with a method to make it conditional. Clients can set this header to the value returned in the Schedule-Tag response header, or the CALDAV:schedule- tag property, of a scheduling object resource previously retrieved from the server to avoid overwriting "consequential" changes to the scheduling object resource. All scheduling object resources MUST support the If-Schedule-Tag- Match header. If-Schedule-Tag-Match = "If-Schedule-Tag-Match" ":" opaque-tag ; "opaque-tag" is defined in Section 3.11 of [RFC2616] Example: If-Schedule-Tag-Match: "12ab34-cd56ef" Daboo & Desruisseaux Expires September 9, 2012 [Page 51] Internet-Draft CalDAV Scheduling Extensions March 2012 9. Additional WebDAV Properties This specification defines the following new WebDAV properties for use with CalDAV. 9.1. CALDAV:schedule-calendar-transp Property Name: schedule-calendar-transp Namespace: urn:ietf:params:xml:ns:caldav Purpose: Determines whether the calendar object resources in a calendar collection will affect the owner's freebusy. Protected: This property MAY be protected and SHOULD NOT be returned by a PROPFIND allprop request (as defined in Section 14.2 of [RFC4918]). COPY/MOVE behavior: This property value SHOULD be kept during a MOVE operation, and SHOULD be copied and preserved in a COPY. Description: This property SHOULD be defined on all calendar collections. If present, it contains one of two XML elements that indicate whether the calendar object resources in the calendar collection ought to contribute to the owner's freebusy or not. When the CALDAV:opaque element is used, all calendar object resources in the corresponding calendar collection MUST contribute to freebusy, assuming access privileges and other iCalendar properties allow it to. When the CALDAV:transparent XML element is used, the calendar object resources in the corresponding calendar collection MUST NOT contribute to freebusy. If this property is not present on a calendar collection, then the default value CALDAV:opaque MUST be assumed. Definition: Daboo & Desruisseaux Expires September 9, 2012 [Page 52] Internet-Draft CalDAV Scheduling Extensions March 2012 Example: 9.2. CALDAV:schedule-default-calendar-URL Property Name: schedule-default-calendar-URL Namespace: urn:ietf:params:xml:ns:caldav Purpose: Specifies a default calendar for an Attendee where new scheduling object resources are created. Protected: This property MAY be protected in the case where a server does not support changing the default calendar, or does not support a default calendar. COPY/MOVE behavior: This property is only defined on a scheduling Inbox collection which cannot be moved or copied. Description: This property MAY be defined on a scheduling Inbox collection. If present, it contains zero or one DAV:href XML elements. When a DAV:href element is present, its value indicates a URL to a calendar collection that is used as the default calendar. When no DAV:href element is present, it indicates that there is no default calendar. In the absence of this property there is no default calendar. When there is no default calendar the server is free to choose the calendar in which a new scheduling object resource is created. See Section 4.3. Definition: Example: /home/cyrus/calendars/work/ Daboo & Desruisseaux Expires September 9, 2012 [Page 53] Internet-Draft CalDAV Scheduling Extensions March 2012 9.3. CALDAV:schedule-tag Property Name: schedule-tag Namespace: urn:ietf:params:xml:ns:caldav Purpose: Indicates whether a scheduling object resource has had a "consequential" change made to it. Value: opaque-tag (defined in Section 3.11 of [RFC2616]) Protected: This property MUST be protected as only the server can update the value. COPY/MOVE behavior: This property is only defined on scheduling object resources. It MUST be preserved when a scheduling object resource is copied or moved and the resulting resource is also a scheduling object resource. If the source resource is not a scheduling object resource but the destination resource is, this property MUST be added to the destination resource. Description: The CALDAV:schedule-tag property MUST be defined on all scheduling object resources. This property is described in Section 3.2.10. Definition: Example: "12345-67890" Daboo & Desruisseaux Expires September 9, 2012 [Page 54] Internet-Draft CalDAV Scheduling Extensions March 2012 10. XML Element Definitions 10.1. CALDAV:schedule-response XML Element Name: schedule-response Namespace: urn:ietf:params:xml:ns:caldav Purpose: Contains the set of responses for a POST method request. Description: See Section 5. Definition: 10.2. CALDAV:response XML Element Name: response Namespace: urn:ietf:params:xml:ns:caldav Purpose: Contains a single response for a POST method request. Description: See Section 5. Definition: 10.3. CALDAV:recipient XML Element Name: recipient Namespace: urn:ietf:params:xml:ns:caldav Purpose: The calendar user address that the enclosing response for a POST method request is for. Daboo & Desruisseaux Expires September 9, 2012 [Page 55] Internet-Draft CalDAV Scheduling Extensions March 2012 Description: See Section 5. Definition: 10.4. CALDAV:request-status XML Element Name: request-status Namespace: urn:ietf:params:xml:ns:caldav Purpose: The iTIP "REQUEST-STATUS" property value for this response. Description: See Section 5. Definition: Daboo & Desruisseaux Expires September 9, 2012 [Page 56] Internet-Draft CalDAV Scheduling Extensions March 2012 11. Security Considerations The process of scheduling involves the sending and receiving of scheduling messages. As a result, the security problems related to messaging in general are relevant here. In particular the authenticity of the scheduling messages needs to be verified. Servers and clients MUST use an HTTP connection protected with TLS as defined in [RFC2818] for all scheduling operations. Clients MUST use the procedures detailed in Section 6 of [RFC6125] to verify the authenticity of the server. Servers MUST make use of HTTP authentication [RFC2617] to verify the authenticity of the calendar user for whom the client is sending requests. 11.1. Preventing Denial of Service Attacks Servers MUST ensure that clients cannot consume excessive server resources by carrying out "large" scheduling operations. In particular, servers SHOULD enforce CALDAV:max-resource-size, CALDAV: max-instances and CALDAV:max-attendees-per-instance pre-conditions as applicable for scheduling Inbox and Outbox collections. 11.2. Verifying Scheduling Operations When handling a scheduling operation: 1. Servers MUST verify that the principal associated with the DAV: owner of the calendar collection in which a scheduling object resource is being manipulated contains a CALDAV:schedule-outbox- URL property value. 2. Servers MUST verify that the currently authenticated user has the CALDAV:schedule-send privilege, or a sub-privilege aggregated under this privilege, on the scheduling Outbox collection of the DAV:owner of the calendar collection in which a scheduling object resource is being manipulated. 3. Servers MUST only deliver scheduling messages to recipients when the CALDAV:schedule-deliver privilege, or a sub-privilege aggregated under this privilege, is granted on the recipient's scheduling Inbox collection for the principal associated with the DAV:owner of the calendar collection in which a scheduling object resource is being manipulated. 4. To prevent impersonation of calendar users, the server MUST verify that the "ORGANIZER" property in an organizer scheduling object resource matches one of the calendar user addresses of the DAV:owner of the calendar collection in which the resource is stored. Daboo & Desruisseaux Expires September 9, 2012 [Page 57] Internet-Draft CalDAV Scheduling Extensions March 2012 5. To prevent spoofing of an existing scheduling object resource, servers MUST verify that the "UID" iCalendar property value in a new scheduling object resource does not match that of an existing scheduling object resource with a different "ORGANIZER" property value. 11.3. Verifying Busy Time Information Requests When handling a POST request on a scheduling Outbox collection: 1. Servers MUST verify that the principal associated with the calendar user address specified in the "ORGANIZER" property of the scheduling message data in the request contains a CALDAV: schedule-outbox-URL property value that matches the scheduling Outbox collection targeted by the request. 2. Servers MUST verify that the currently authenticated user has the CALDAV:schedule-send privilege, or a sub-privilege aggregated under this privilege, on the scheduling Outbox collection targeted by the request. 3. Servers MUST only return valid freebusy information for recipients when the CALDAV:schedule-deliver privilege, or a sub- privilege aggregated under this privilege, is granted on the recipient's scheduling Inbox collection for the principal associated with the DAV:owner of the scheduling Outbox collection targeted by the request. 11.4. Privacy Issues This specification only defines how calendar users on the same server are able to schedule with each other - unauthenticated users have no way to carry out scheduling operations. Access control privileges (as per Section 6) can control which of those users can schedule with others. Calendar users not wishing to expose their calendar information to other users can do so by denying privileges to specific users, or all users, for all scheduling operations, or perhaps only freebusy. Attendees can also use the Schedule-Reply request header (Section 8.1) with the value set to "F" to prevent notification to an Organizer that a scheduling object resource was deleted. This allows Attendees to remove unwanted scheduling messages without any response to the Organizer. Daboo & Desruisseaux Expires September 9, 2012 [Page 58] Internet-Draft CalDAV Scheduling Extensions March 2012 11.5. Mitigation of iTIP Threats Section 6.1 of iTIP [RFC5546] defines a set of potential threats in a scheduling system, and in Section 6.2 defines recommendations on how those should be addressed in protocols using iTIP. This specification addresses the iTIP threats in the following manner: Spoofing the Organizer Addressed by item 4 in Section 11.2. Spoofing the Attendee Addressed by item 2 in Section 11.2 and Section 3.2.2.1. Unauthorized Replacement of the Organizer Addressed by item 5 in Section 11.2. Eavesdropping and Data Integrity Addressed by requiring TLS. Flooding a Calendar Addressed by requirements in Section 11.1 Unauthorized REFRESH Requests This specification does not support the REFRESH method. Daboo & Desruisseaux Expires September 9, 2012 [Page 59] Internet-Draft CalDAV Scheduling Extensions March 2012 12. IANA Considerations 12.1. Message Header Field Registrations The message header fields below should be added to the Permanent Message Header Field Registry (see [RFC3864]). 12.1.1. Schedule-Reply Header field name: Schedule-Reply Applicable protocol: http Status: standard Author/Change controller: IETF Specification document(s): this specification (Section 8.1) Related information: none 12.1.2. Schedule-Tag Header field name: Schedule-Tag Applicable protocol: http Status: standard Author/Change controller: IETF Specification document(s): this specification (Section 8.2) Related information: none 12.1.3. If-Schedule-Tag-Match Header field name: If-Schedule-Tag-Match Applicable protocol: http Status: standard Author/Change controller: IETF Specification document(s): this specification (Section 8.3) Related information: none Daboo & Desruisseaux Expires September 9, 2012 [Page 60] Internet-Draft CalDAV Scheduling Extensions March 2012 12.2. iCalendar Property Parameter Registrations The following iCalendar property parameters should be added to the iCalendar Property Parameter Registry defined in Section 8.3.3 of [RFC5545]. +---------------------+---------+-----------------------+ | Parameter | Status | Reference | +---------------------+---------+-----------------------+ | SCHEDULE-AGENT | Current | RFC XXXX, Section 7.1 | | | | | | SCHEDULE-STATUS | Current | RFC XXXX, Section 7.3 | | | | | | SCHEDULE-FORCE-SEND | Current | RFC XXXX, Section 7.2 | +---------------------+---------+-----------------------+ 12.3. iCalendar REQUEST-STATUS Value Registrations The following iCalendar "REQUEST-STATUS" values should be added to the iCalendar REQUEST-STATUS Value Registry defined in Section 7.3 of [RFC5546]. +-------------+---------+---------------------------+ | Status Code | Status | Reference | +-------------+---------+---------------------------+ | 1.0 | Current | RFC XXXX, Section 3.2.9.1 | | | | | | 1.1 | Current | RFC XXXX, Section 3.2.9.2 | | | | | | 1.2 | Current | RFC XXXX, Section 3.2.9.3 | +-------------+---------+---------------------------+ 12.4. Additional iCalendar Elements Registries This specification adds two new IANA registries for iCalendar elements. Additional codes MAY be used, provided the process described in Section 8.2.1 of [RFC5545] is used to register them. 12.4.1. Schedule Agent Values Registry The following table has been used to initialize the schedule agent values registry. Daboo & Desruisseaux Expires September 9, 2012 [Page 61] Internet-Draft CalDAV Scheduling Extensions March 2012 +----------------+---------+-----------------------+ | Schedule Agent | Status | Reference | +----------------+---------+-----------------------+ | SERVER | Current | RFC XXXX, Section 7.1 | | | | | | CLIENT | Current | RFC XXXX, Section 7.1 | | | | | | NONE | Current | RFC XXXX, Section 7.1 | +----------------+---------+-----------------------+ 12.4.2. Schedule Force Send Values Registry The following table has been used to initialize the schedule send values registry. +---------------------+---------+-----------------------+ | Schedule Force Send | Status | Reference | +---------------------+---------+-----------------------+ | REQUEST | Current | RFC XXXX, Section 7.2 | | | | | | REPLY | Current | RFC XXXX, Section 7.2 | +---------------------+---------+-----------------------+ Daboo & Desruisseaux Expires September 9, 2012 [Page 62] Internet-Draft CalDAV Scheduling Extensions March 2012 13. Acknowledgements The authors would like to thank the following individuals for contributing their ideas and support for writing this specification: Mike Douglass, Lisa Dusseault, Red Dutta, Jacob Farkas, Jeffrey Harris, Helge Hess, Andrew McMillan, Alexey Melnikov, Arnaud Quillaud, Julian F. Reschke, Wilfredo Sanchez Vega, Simon Vaillancourt. The authors would also like to thank the Calendaring and Scheduling Consortium for advice with this specification, and for organizing interoperability testing events to help refine it. Daboo & Desruisseaux Expires September 9, 2012 [Page 63] Internet-Draft CalDAV Scheduling Extensions March 2012 14. References 14.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners- Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC3744] Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, "Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol", RFC 3744, May 2004. [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004. [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault, "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791, March 2007. [RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)", RFC 4918, June 2007. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. [RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", RFC 5545, September 2009. [RFC5546] Daboo, C., "iCalendar Transport-Independent Daboo & Desruisseaux Expires September 9, 2012 [Page 64] Internet-Draft CalDAV Scheduling Extensions March 2012 Interoperability Protocol (iTIP)", RFC 5546, December 2009. [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain- Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, March 2011. [W3C.REC-xml-20081126] Yergeau, F., Paoli, J., Sperberg-McQueen, C., Maler, E., and T. Bray, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", World Wide Web Consortium Recommendation REC-xml- 20081126, November 2008, . 14.2. Informative References [RFC6047] Melnikov, A., "iCalendar Message-Based Interoperability Protocol (iMIP)", RFC 6047, December 2010. Daboo & Desruisseaux Expires September 9, 2012 [Page 65] Internet-Draft CalDAV Scheduling Extensions March 2012 Appendix A. Scheduling Privileges Summary A.1. Scheduling Inbox Privileges The following tables specify which scheduling privileges grant the right to a calendar user to deliver a scheduling message to the scheduling Inbox collection of another calendar user. The appropriate behavior depends on the calendar component type as well as the scheduling "METHOD" specified in the scheduling message. +--------------------------------+ | METHOD for VEVENT and VTODO | +-----------------------------+---------+-------+-----+--------+ | Scheduling Inbox Privilege | REQUEST | REPLY | ADD | CANCEL | +-----------------------------+---------+-------+-----+--------+ | schedule-deliver | * | * | * | * | | schedule-deliver-invite | * | | * | * | | schedule-deliver-reply | | * | | | | schedule-query-freebusy | | | | | +-----------------------------+---------+-------+-----+--------+ +----------------------+ | METHOD for VFREEBUSY | +-----------------------------+----------------------+ | Scheduling Inbox Privilege | REQUEST | +-----------------------------+----------------------+ | schedule-deliver | * | | schedule-deliver-invite | | | schedule-deliver-reply | | | schedule-query-freebusy | * | +-----------------------------+----------------------+ A.2. Scheduling Outbox Privileges The following tables specify which scheduling privileges grant the right to a calendar user to perform busy time information requests and to submit scheduling messages to other calendar users as the result of a scheduling operation. The appropriate behavior depends on the calendar component type as well as the scheduling "METHOD" specified in the scheduling message. Daboo & Desruisseaux Expires September 9, 2012 [Page 66] Internet-Draft CalDAV Scheduling Extensions March 2012 +--------------------------------+ | METHOD for VEVENT and VTODO | +-----------------------------+---------+-------+-----+--------+ | Scheduling Outbox Privilege | REQUEST | REPLY | ADD | CANCEL | +-----------------------------+---------+-------+-----+--------+ | schedule-send | * | * | * | * | | schedule-send-invite | * | | * | * | | schedule-send-reply | | * | | | | schedule-send-freebusy | | | | | +-----------------------------+---------+-------+-----+--------+ +----------------------+ | METHOD for VFREEBUSY | +-----------------------------+----------------------+ | Scheduling Outbox Privilege | REQUEST | +-----------------------------+----------------------+ | schedule-send | * | | schedule-send-invite | | | schedule-send-reply | | | schedule-send-freebusy | * | +-----------------------------+----------------------+ Daboo & Desruisseaux Expires September 9, 2012 [Page 67] Internet-Draft CalDAV Scheduling Extensions March 2012 Appendix B. Example Scheduling Operations This section describes some example scheduling operations that give a general idea of how scheduling is carried out between CalDAV clients and servers from the perspective of meeting Organizers and Attendees. The server is assumed to be hosted in the "example.com" domain, and users whose email address is at the "example.com" domain are assumed to be hosted by the server. In addition, the email addresses in the "example.net" domain are also valid email addresses for calendar users hosted by the server. Calendar users with an email address at the "example.org" domain are assumed to not be hosted by the server. In the following examples the requests and responses are incomplete and are only for illustrative purposes. In particular, HTTP authentication headers and behaviors are not shown, even though they are required in normal operation. B.1. Example: Organizer Inviting Multiple Attendees In the following example, Cyrus invites Wilfredo, Bernard and Mike to a single instance event by simply creating a new scheduling object resource in one of his calendar collections by using the PUT method. Daboo & Desruisseaux Expires September 9, 2012 [Page 68] Internet-Draft CalDAV Scheduling Extensions March 2012 >> Request << PUT /home/cyrus/calendars/work/9263504FD3AD.ics HTTP/1.1 Host: cal.example.com Content-Type: text/calendar; charset="utf-8" Content-Length: xxxx If-None-Match: * BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Example Corp.//CalDAV Client//EN BEGIN:VEVENT UID:9263504FD3AD SEQUENCE:0 DTSTAMP:20090602T185254Z DTSTART:20090602T160000Z DTEND:20090602T170000Z TRANSP:OPAQUE SUMMARY:Lunch ORGANIZER;CN="Cyrus Daboo":mailto:cyrus@example.com ATTENDEE;CN="Cyrus Daboo";CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED: mailto:cyrus@example.com ATTENDEE;CN="Wilfredo Sanchez Vega";CUTYPE=INDIVIDUAL;PARTSTAT =NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:wilfredo@ example.com ATTENDEE;CN="Bernard Desruisseaux";CUTYPE=INDIVIDUAL;PARTSTAT= NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:bernard@ex ample.net ATTENDEE;CN="Mike Douglass";CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-A CTION;RSVP=TRUE:mailto:mike@example.org END:VEVENT END:VCALENDAR >> Response << HTTP/1.1 201 Created Content-Length: 0 Date: Tue, 02 Jun 2009 18:52:54 GMT Last-Modified: Tue, 02 Jun 2009 18:52:54 GMT ETag: "d85561cfe74a4e785eb4639451b434fb" Schedule-Tag: "488177c8-2ea7-4176-a6cb-fab8cfccdea2" Once the event creation has been completed, Cyrus's client will retrieve the event back from the server to get the schedule status of each Attendee, as well as record the Schedule-Tag value for future use. In this example, the server reports that a scheduling message was delivered to Wilfredo, a scheduling message is still pending for Bernard, and the server was unable to deliver a scheduling message to Daboo & Desruisseaux Expires September 9, 2012 [Page 69] Internet-Draft CalDAV Scheduling Extensions March 2012 Mike. >> Request << GET /home/cyrus/calendars/work/9263504FD3AD.ics HTTP/1.1 Host: cal.example.com >> Response << HTTP/1.1 200 OK Date: Tue, 02 Jun 2009 18:52:58 GMT Last-Modified: Tue, 02 Jun 2009 18:52:58 GMT ETag: "eb897deabc8939589da116714bc99265" Schedule-Tag: "488177c8-2ea7-4176-a6cb-fab8cfccdea2" Content-Type: text/calendar; charset="utf-8" Content-Length: xxxx BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Example Corp.//CalDAV Server//EN BEGIN:VEVENT UID:9263504FD3AD SEQUENCE:0 DTSTAMP:20090602T185300Z DTSTART:20090602T160000Z DTEND:20090602T170000Z TRANSP:OPAQUE SUMMARY:Lunch ORGANIZER;CN="Cyrus Daboo":mailto:cyrus@example.com ATTENDEE;CN="Cyrus Daboo";CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED: mailto:cyrus@example.com ATTENDEE;CN="Wilfredo Sanchez Vega";CUTYPE=INDIVIDUAL;PARTSTAT =NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE;SCHEDULE-STATUS= 1.2:mailto:wilfredo@e xample.com ATTENDEE;CN="Bernard Desruisseaux";CUTYPE=INDIVIDUAL;PARTSTAT= NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE;SCHEDULE-STATUS= 1.0:mailto:bernard@example.net ATTENDEE;CN="Mike Douglass";CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-A CTION;RSVP=TRUE;SCHEDULE-STATUS=3.7:mailto:mike@example.org END:VEVENT END:VCALENDAR B.2. Example: Attendee Receiving an Invitation In the following example, Wilfredo's client retrieves and deletes the new scheduling message that appeared in his scheduling Inbox collection after the server automatically processed it and created a Daboo & Desruisseaux Expires September 9, 2012 [Page 70] Internet-Draft CalDAV Scheduling Extensions March 2012 new scheduling object resource in his default calendar collection. >> Request << GET /home/wilfredo/calendars/inbox/27d93fc0a58c.ics HTTP/1.1 Host: cal.example.com >> Response << HTTP/1.1 200 OK Date: Tue, 02 Jun 2009 18:59:58 GMT Last-Modified: Tue, 02 Jun 2009 18:59:58 GMT ETag: "da116714bc9926c89395895eb897deab" Content-Type: text/calendar; charset="utf-8" Content-Length: xxxx BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Example Corp.//CalDAV Server//EN METHOD:REQUEST BEGIN:VEVENT UID:9263504FD3AD SEQUENCE:0 DTSTAMP:20090602T185254Z DTSTART:20090602T160000Z DTEND:20090602T170000Z TRANSP:OPAQUE SUMMARY:Lunch ORGANIZER;CN="Cyrus Daboo":mailto:cyrus@example.com ATTENDEE;CN="Cyrus Daboo";CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED: mailto:cyrus@example.com ATTENDEE;CN="Wilfredo Sanchez Vega";CUTYPE=INDIVIDUAL;PARTSTAT =NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:wilfredo@ example.com ATTENDEE;CN="Bernard Desruisseaux";CUTYPE=INDIVIDUAL;PARTSTAT= NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:bernard@ex ample.net ATTENDEE;CN="Mike Douglass";CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-A CTION;RSVP=TRUE:mailto:mike@example.org END:VEVENT END:VCALENDAR >> Request << DELETE /home/wilfredo/calendars/inbox/27d93fc0a58c.ics HTTP/1.1 Host: cal.example.com Daboo & Desruisseaux Expires September 9, 2012 [Page 71] Internet-Draft CalDAV Scheduling Extensions March 2012 >> Response << HTTP/1.1 204 No Content Date: Tue, 02 Jun 2009 20:40:36 GMT B.3. Example: Attendee Replying to an Invitation In the following example, Wilfredo accepts Cyrus's invitation and sets an alarm reminder on the event. It uses the If-Schedule-Tag- Match precondition behavior to ensure it does not overwrite any significant changes from the organizer that might have occurred after it retrieved the initial resource data. Daboo & Desruisseaux Expires September 9, 2012 [Page 72] Internet-Draft CalDAV Scheduling Extensions March 2012 >> Request << PUT /home/wilfredo/calendars/work/BB64861C2228.ics HTTP/1.1 Host: cal.example.com If-Schedule-Tag-Match: "e78f23ed-0188-4bab-938d-2aeb3324c7e8" Content-Type: text/calendar; charset="utf-8" Content-Length: xxxx BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Example Corp.//CalDAV Client//EN BEGIN:VEVENT UID:9263504FD3AD SEQUENCE:0 DTSTAMP:20090602T185254Z DTSTART:20090602T160000Z DTEND:20090602T170000Z TRANSP:OPAQUE SUMMARY:Lunch ORGANIZER;CN="Cyrus Daboo":mailto:cyrus@example.com ATTENDEE;CN="Cyrus Daboo";CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED: mailto:cyrus@example.com ATTENDEE;CN="Wilfredo Sanchez Vega";CUTYPE=INDIVIDUAL;PARTSTAT =ACCEPTED;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:wilfredo@exam ple.com ATTENDEE;CN="Bernard Desruisseaux";CUTYPE=INDIVIDUAL;PARTSTAT= NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:bernard@ex ample.net ATTENDEE;CN="Mike Douglass";CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-A CTION;RSVP=TRUE:mailto:mike@example.org BEGIN:VALARM TRIGGER:-PT15M ACTION:DISPLAY DESCRIPTION:Reminder END:VALARM END:VEVENT END:VCALENDAR >> Response << HTTP/1.1 200 OK Content-Length: 0 Date: Tue, 02 Jun 2009 18:57:54 GMT Last-Modified: Tue, 02 Jun 2009 18:57:54 GMT ETag: "eb4639451b434fbd85561cfe74a4e785" Schedule-Tag: "8893ee45-eb9d-428f-b53c-c777daf19e41" Once the event modification has been completed, Wilfredo's client Daboo & Desruisseaux Expires September 9, 2012 [Page 73] Internet-Draft CalDAV Scheduling Extensions March 2012 will retrieve the event back from the server to get the schedule status of the Organizer. >> Request << GET /home/wilfredo/calendars/work/BB64861C2228.ics HTTP/1.1 Host: cal.example.com Daboo & Desruisseaux Expires September 9, 2012 [Page 74] Internet-Draft CalDAV Scheduling Extensions March 2012 >> Response << HTTP/1.1 200 OK Date: Tue, 02 Jun 2009 19:03:03 GMT Last-Modified: Tue, 02 Jun 2009 19:02:21 GMT ETag: "5eb897deabda116714bc9926c8939589" Schedule-Tag: "8893ee45-eb9d-428f-b53c-c777daf19e41" Content-Type: text/calendar; charset="utf-8" Content-Length: xxxx BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Example Corp.//CalDAV Client//EN BEGIN:VEVENT UID:9263504FD3AD SEQUENCE:0 DTSTAMP:20090602T190221Z DTSTART:20090602T160000Z DTEND:20090602T170000Z TRANSP:OPAQUE SUMMARY:Lunch ORGANIZER;CN="Cyrus Daboo";SCHEDULE-STATUS=1.2:mailto:cyrus@ex ample.com ATTENDEE;CN="Cyrus Daboo";CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED: mailto:cyrus@example.com ATTENDEE;CN="Wilfredo Sanchez Vega";CUTYPE=INDIVIDUAL;PARTSTAT =ACCEPTED;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:wilfredo@exam ple.com ATTENDEE;CN="Bernard Desruisseaux";CUTYPE=INDIVIDUAL;PARTSTAT= NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:bernard@ex ample.net ATTENDEE;CN="Mike Douglass";CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-A CTION;RSVP=TRUE:mailto:mike@example.org BEGIN:VALARM TRIGGER:-PT15M ACTION:DISPLAY DESCRIPTION:Reminder END:VALARM END:VEVENT END:VCALENDAR B.4. Example: Organizer Receiving a Reply to an Invitation On reception of Wilfredo's reply, Cyrus's server will automatically update Cyrus's scheduling object resource, make Wilfredo's scheduling message available in Cyrus's scheduling Inbox collection, and deliver an updated scheduling message to Bernard to share Wilfredo's updated participation status. In this example, Cyrus's client retrieves and Daboo & Desruisseaux Expires September 9, 2012 [Page 75] Internet-Draft CalDAV Scheduling Extensions March 2012 deletes this scheduling message in his scheduling Inbox collection. >> Request << GET /home/cyrus/calendars/inbox/c0a58c27d93f.ics HTTP/1.1 Host: cal.example.com >> Response << HTTP/1.1 200 OK Date: Tue, 02 Jun 2009 19:05:02 GMT Last-Modified: Tue, 02 Jun 2009 19:04:20 GMT ETag: "9265eb897deabc8939589da116714bc9" Content-Type: text/calendar; charset="utf-8" Content-Length: xxxx BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Example Corp.//CalDAV Server//EN METHOD:REPLY BEGIN:VEVENT UID:9263504FD3AD SEQUENCE:0 DTSTAMP:20090602T185754Z DTSTART:20090602T160000Z DTEND:20090602T170000Z ORGANIZER;CN="Cyrus Daboo":mailto:cyrus@example.com ATTENDEE;CN="Wilfredo Sanchez Vega";PARTSTAT=ACCEPTED:mailto:w ilfredo@example.com REQUEST-STATUS:2.0;Success END:VEVENT END:VCALENDAR >> Request << DELETE /home/cyrus/calendars/inbox/c0a58c27d93f.ics HTTP/1.1 Host: cal.example.com >> Response << HTTP/1.1 204 No Content Date: Tue, 02 Jun 2009 19:05:05 GMT Cyrus's client then retrieves the event back from the server with Wilfredo's updated participation status. Daboo & Desruisseaux Expires September 9, 2012 [Page 76] Internet-Draft CalDAV Scheduling Extensions March 2012 >> Request << GET /home/cyrus/calendars/work/9263504FD3AD.ics HTTP/1.1 Host: cal.example.com >> Response << HTTP/1.1 200 OK Date: Tue, 02 Jun 2009 19:05:02 GMT Last-Modified: Tue, 02 Jun 2009 19:04:20 GMT ETag: "eb897deabc8939589da116714bc99265" Schedule-Tag: "132cab27-1fe3-67ab-de13-abd348d1dee3" Content-Type: text/calendar; charset="utf-8" Content-Length: xxxx BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Example Corp.//CalDAV Server//EN BEGIN:VEVENT UID:9263504FD3AD SEQUENCE:0 DTSTAMP:20090602T190420Z DTSTART:20090602T160000Z DTEND:20090602T170000Z TRANSP:OPAQUE SUMMARY:Lunch ORGANIZER;CN="Cyrus Daboo":mailto:cyrus@example.com ATTENDEE;CN="Cyrus Daboo";CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED: mailto:cyrus@example.com ATTENDEE;CN="Wilfredo Sanchez Vega";CUTYPE=INDIVIDUAL;PARTSTAT =ACCEPTED;ROLE=REQ-PARTICIPANT;RSVP=TRUE;SCHEDULE-STATUS=2.0: mailto:wilfredo@example.com ATTENDEE;CN="Bernard Desruisseaux";CUTYPE=INDIVIDUAL;PARTSTAT= NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE;SCHEDULE-STATUS=1 .0:mailto:bernard@example.net ATTENDEE;CN="Mike Douglass";CUTYPE=INDIVIDUAL;PARTSTAT=NEEDS-A CTION;RSVP=TRUE;SCHEDULE-STATUS=3.7:mailto:mike@example.org END:VEVENT END:VCALENDAR B.5. Example: Organizer Requesting Busy Time Information In this example, Cyrus requests the busy time information of Wilfredo, Bernard and Mike. Daboo & Desruisseaux Expires September 9, 2012 [Page 77] Internet-Draft CalDAV Scheduling Extensions March 2012 >> Request << POST /home/cyrus/calendars/outbox/ HTTP/1.1 Host: cal.example.com Content-Type: text/calendar; charset="utf-8" Content-Length: xxxx BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Example Corp.//CalDAV Client//EN METHOD:REQUEST BEGIN:VFREEBUSY UID:4FD3AD926350 DTSTAMP:20090602T190420Z DTSTART:20090602T000000Z DTEND:20090604T000000Z ORGANIZER;CN="Cyrus Daboo":mailto:cyrus@example.com ATTENDEE;CN="Wilfredo Sanchez Vega":mailto:wilfredo@example.com ATTENDEE;CN="Bernard Desruisseaux":mailto:bernard@example.net ATTENDEE;CN="Mike Douglass":mailto:mike@example.org END:VFREEBUSY END:VCALENDAR >> Response << HTTP/1.1 200 OK Date: Tue, 02 Jun 2009 20:07:34 GMT Content-Type: application/xml; charset="utf-8" Content-Length: xxxx mailto:wilfredo@example.com 2.0;Success BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Example Corp.//CalDAV Server//EN METHOD:REPLY BEGIN:VFREEBUSY UID:4FD3AD926350 DTSTAMP:20090602T200733Z DTSTART:20090602T000000Z DTEND:20090604T000000Z ORGANIZER;CN="Cyrus Daboo":mailto:cyrus@example.com Daboo & Desruisseaux Expires September 9, 2012 [Page 78] Internet-Draft CalDAV Scheduling Extensions March 2012 ATTENDEE;CN="Wilfredo Sanchez Vega":mailto:wilfredo@example.com FREEBUSY;FBTYPE=BUSY:20090602T110000Z/20090602T120000Z FREEBUSY;FBTYPE=BUSY:20090603T170000Z/20090603T180000Z END:VFREEBUSY END:VCALENDAR mailto:bernard@example.net 2.0;Success BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Example Corp.//CalDAV Server//EN METHOD:REPLY BEGIN:VFREEBUSY UID:4FD3AD926350 DTSTAMP:20090602T200733Z DTSTART:20090602T000000Z DTEND:20090604T000000Z ORGANIZER;CN="Cyrus Daboo":mailto:cyrus@example.com ATTENDEE;CN="Bernard Desruisseaux":mailto:bernard@example.net FREEBUSY;FBTYPE=BUSY:20090602T150000Z/20090602T160000Z FREEBUSY;FBTYPE=BUSY:20090603T090000Z/20090603T100000Z FREEBUSY;FBTYPE=BUSY:20090603T180000Z/20090603T190000Z END:VFREEBUSY END:VCALENDAR mailto:mike@example.org 3.7;Invalid calendar user B.6. Example: User Attempting to Invite Attendee on behalf of Organizer In the following example, Cyrus attempts to create, on behalf of Wilfredo, an event with Bernard specified as an Attendee. The request fails since Wilfredo didn't grant Cyrus the right to invite other calendar users on his behalf. Daboo & Desruisseaux Expires September 9, 2012 [Page 79] Internet-Draft CalDAV Scheduling Extensions March 2012 >> Request << PUT /home/wilfredo/calendars/work/def456.ics HTTP/1.1 Host: cal.example.com Content-Type: text/calendar; charset="utf-8" Content-Length: xxxx If-None-Match: * BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Example Corp.//CalDAV Client//EN BEGIN:VEVENT UID:3504F926D3AD SEQUENCE:0 DTSTAMP:20090602T190221Z DTSTART:20090602T230000Z DTEND:20090603T000000Z TRANSP:OPAQUE SUMMARY:Dinner ORGANIZER;CN="Wilfredo Sanchez Vega":mailto:wilfredo@example.com ATTENDEE;CN="Wilfredo Sanchez Vega";CUTYPE=INDIVIDUAL;PARTSTAT=A CCEPTED:mailto:wilfredo@example.com ATTENDEE;CN="Bernard Desruisseaux";CUTYPE=INDIVIDUAL;PARTSTAT=NE EDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:bernard@exampl e.net END:VEVENT END:VCALENDAR >> Response << HTTP/1.1 403 Forbidden Content-Type: application/xml; charset="utf-8" Content-Length: xxxx /home/wilfredo/calendars/outbox/ Daboo & Desruisseaux Expires September 9, 2012 [Page 80] Internet-Draft CalDAV Scheduling Extensions March 2012 B.7. Example: Attendee Declining an Instance of a Recurring Event In the following example, Bernard declines the second recurrence instance of a daily recurring event he's been invited to by Cyrus. >> Request << PUT /home/bernard/calendars/work/4FD3AD926350.ics HTTP/1.1 Host: cal.example.com Content-Type: text/calendar; charset="utf-8" Content-Length: xxxx If-Schedule-Tag-Match: "7775FB30-7534-489E-A79A-0EA147B933EB" BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Example Corp.//CalDAV Client//EN BEGIN:VTIMEZONE TZID:America/Montreal BEGIN:STANDARD DTSTART:20071104T020000 RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU TZNAME:EST TZOFFSETFROM:-0400 TZOFFSETTO:-0500 END:STANDARD BEGIN:DAYLIGHT DTSTART:20070311T020000 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU TZNAME:EDT TZOFFSETFROM:-0500 TZOFFSETTO:-0400 END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT UID:9263504FD3AD SEQUENCE:0 DTSTAMP:20090602T185254Z DTSTART;TZID=America/Montreal:20090601T150000 DTEND;TZID=America/Montreal:20090601T160000 RRULE:FREQ=DAILY;INTERVAL=1;COUNT=5 TRANSP:OPAQUE SUMMARY:Review Internet-Draft ORGANIZER;CN="Cyrus Daboo":mailto:cyrus@example.com ATTENDEE;CN="Cyrus Daboo";CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED: mailto:cyrus@example.com ATTENDEE;CN="Bernard Desruisseaux";CUTYPE=INDIVIDUAL;PARTSTAT= ACCEPTED;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:bernard@exampl e.net Daboo & Desruisseaux Expires September 9, 2012 [Page 81] Internet-Draft CalDAV Scheduling Extensions March 2012 END:VEVENT BEGIN:VEVENT UID:9263504FD3AD SEQUENCE:0 DTSTAMP:20090603T183823Z RECURRENCE-ID;TZID=America/Montreal:20090602T150000 DTSTART;TZID=America/Montreal:20090602T150000 DTEND;TZID=America/Montreal:20090602T160000 TRANSP:TRANSPARENT SUMMARY:Review Internet-Draft ORGANIZER;CN="Cyrus Daboo":mailto:cyrus@example.com ATTENDEE;CN="Cyrus Daboo";CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED: mailto:cyrus@example.com ATTENDEE;CN="Bernard Desruisseaux";CUTYPE=INDIVIDUAL;PARTSTAT= DECLINED;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:bernard@exampl e.net END:VEVENT END:VCALENDAR >> Response << HTTP/1.1 200 OK Content-Length: 0 Date: Tue, 02 Jun 2009 18:52:54 GMT Last-Modified: Tue, 02 Jun 2009 18:52:54 GMT ETag: "d85561cfe74a4e785eb4639451b434fb" Schedule-Tag: "488177c8-2ea7-4176-a6cb-fab8cfccdea2" Bernard's participation status update will cause his server to deliver a scheduling message to Cyrus. Cyrus's client will find the following reply message from Bernard in Cyrus's scheduling Inbox collection: >> Request << GET /home/cyrus/calendars/inbox/9263504FD3AD.ics HTTP/1.1 Host: cal.example.com Daboo & Desruisseaux Expires September 9, 2012 [Page 82] Internet-Draft CalDAV Scheduling Extensions March 2012 >> Response << HTTP/1.1 200 OK Date: Tue, 02 Jun 2009 18:52:58 GMT Last-Modified: Tue, 02 Jun 2009 18:52:58 GMT ETag: "eb897deabc8939589da116714bc99265" Content-Type: text/calendar; charset="utf-8" Content-Length: xxxx BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Example Corp.//CalDAV Client//EN METHOD:REPLY BEGIN:VTIMEZONE TZID:America/Montreal BEGIN:STANDARD DTSTART:20071104T020000 RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU TZNAME:EST TZOFFSETFROM:-0400 TZOFFSETTO:-0500 END:STANDARD BEGIN:DAYLIGHT DTSTART:20070311T020000 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU TZNAME:EDT TZOFFSETFROM:-0500 TZOFFSETTO:-0400 END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT UID:9263504FD3AD SEQUENCE:0 DTSTAMP:20090603T183823Z RECURRENCE-ID;TZID=America/Montreal:20090602T150000 DTSTART;TZID=America/Montreal:20090602T150000 DTEND;TZID=America/Montreal:20090602T160000 SUMMARY:Review Internet-Draft ORGANIZER;CN="Cyrus Daboo":mailto:cyrus@example.com ATTENDEE;CN="Bernard Desruisseaux";PARTSTAT=DECLINED: mailto:bernard@example.net REQUEST-STATUS:2.0;Success END:VEVENT END:VCALENDAR Daboo & Desruisseaux Expires September 9, 2012 [Page 83] Internet-Draft CalDAV Scheduling Extensions March 2012 B.8. Example: Attendee Removing an Instance of a Recurring Event In the following example, Bernard removes from his calendar the third recurrence instance of a daily recurring event he's been invited to by Cyrus. This is accomplished by the addition of an "EXDATE" property to the scheduling object resource stored by Bernard. >> Request << PUT /home/bernard/calendars/work/4FD3AD926350.ics HTTP/1.1 Host: cal.example.com Content-Type: text/calendar; charset="utf-8" Content-Length: xxxx If-Schedule-Tag-Match: "488177c8-2ea7-4176-a6cb-fab8cfccdea2" BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Example Corp.//CalDAV Client//EN BEGIN:VTIMEZONE TZID:America/Montreal BEGIN:STANDARD DTSTART:20071104T020000 RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU TZNAME:EST TZOFFSETFROM:-0400 TZOFFSETTO:-0500 END:STANDARD BEGIN:DAYLIGHT DTSTART:20070311T020000 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU TZNAME:EDT TZOFFSETFROM:-0500 TZOFFSETTO:-0400 END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT UID:9263504FD3AD SEQUENCE:0 DTSTAMP:20090602T185254Z DTSTART;TZID=America/Montreal:20090601T150000 DTEND;TZID=America/Montreal:20090601T160000 RRULE:FREQ=DAILY;INTERVAL=1;COUNT=5 EXDATE;TZID=America/Montreal:20090603T150000 TRANSP:OPAQUE SUMMARY:Review Internet-Draft ORGANIZER;CN="Cyrus Daboo":mailto:cyrus@example.com ATTENDEE;CN="Cyrus Daboo";CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED: mailto:cyrus@example.com Daboo & Desruisseaux Expires September 9, 2012 [Page 84] Internet-Draft CalDAV Scheduling Extensions March 2012 ATTENDEE;CN="Bernard Desruisseaux";CUTYPE=INDIVIDUAL;PARTSTAT= ACCEPTED;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:bernard@exampl e.net END:VEVENT BEGIN:VEVENT UID:9263504FD3AD SEQUENCE:0 DTSTAMP:20090603T183823Z RECURRENCE-ID;TZID=America/Montreal:20090602T150000 DTSTART;TZID=America/Montreal:20090602T150000 DTEND;TZID=America/Montreal:20090602T160000 TRANSP:TRANSPARENT SUMMARY:Review Internet-Draft ORGANIZER;CN="Cyrus Daboo":mailto:cyrus@example.com ATTENDEE;CN="Cyrus Daboo";CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED: mailto:cyrus@example.com ATTENDEE;CN="Bernard Desruisseaux";CUTYPE=INDIVIDUAL;PARTSTAT= DECLINED;ROLE=REQ-PARTICIPANT;RSVP=TRUE:mailto:bernard@exampl e.net END:VEVENT END:VCALENDAR Bernard's deletion of a recurrence instance will cause his server to deliver a scheduling message to Cyrus. Cyrus's client will find the following reply message from Bernard in Cyrus's scheduling Inbox collection: >> Request << GET /home/cyrus/calendars/inbox/6504923FD3AD.ics HTTP/1.1 Host: cal.example.com Daboo & Desruisseaux Expires September 9, 2012 [Page 85] Internet-Draft CalDAV Scheduling Extensions March 2012 >> Response << HTTP/1.1 200 OK Date: Tue, 02 Jun 2009 18:52:58 GMT Last-Modified: Tue, 02 Jun 2009 18:52:58 GMT ETag: "eb897deabc8939589da116714bc99265" Content-Type: text/calendar; charset="utf-8" Content-Length: xxxx BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Example Corp.//CalDAV Client//EN METHOD:REPLY BEGIN:VTIMEZONE TZID:America/Montreal BEGIN:STANDARD DTSTART:20071104T020000 RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU TZNAME:EST TZOFFSETFROM:-0400 TZOFFSETTO:-0500 END:STANDARD BEGIN:DAYLIGHT DTSTART:20070311T020000 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU TZNAME:EDT TZOFFSETFROM:-0500 TZOFFSETTO:-0400 END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT UID:9263504FD3AD SEQUENCE:0 DTSTAMP:20090603T183823Z RECURRENCE-ID;TZID=America/Montreal:20090603T150000 DTSTART;TZID=America/Montreal:20090603T150000 DTEND;TZID=America/Montreal:20090603T160000 SUMMARY:Review Internet-Draft ORGANIZER;CN="Cyrus Daboo":mailto:cyrus@example.com ATTENDEE;CN="Bernard Desruisseaux";PARTSTAT=DECLINED: mailto:bernard@example.net REQUEST-STATUS:2.0;Success END:VEVENT END:VCALENDAR Daboo & Desruisseaux Expires September 9, 2012 [Page 86] Internet-Draft CalDAV Scheduling Extensions March 2012 Appendix C. Changes (to be removed by RFC Editor prior to publication) C.1. Changes in -12 a. AppDir: More reworking of various sections for clarity. b. AppDir: Removed terminology items defined in other specs. c. AppDir: Now updates 5546. d. AppDir: MAY instead of can in 3.2.10.1/2. e. Fixed inconsistent whitespace in examples. C.2. Changes in -11 a. Major editorial changes to remove "cruft" that built up over time, to reduce repetitive statements, and to improve clarity. b. SecDir: Added "Preventing Denial of Service Attacks" security sub-section. c. SecDir: Added reference to RFC6125 and clarified how clients and server authenticate each other. d. SecDir: Added "Mitigation of iTIP Threats" security sub-section. e. SecDir: Added new text to privacy sub-section. f. Fixed some XML examples. C.3. Changes in -10 a. Updated to RFC 6047 reference. b. Various minor clarifications to behavior and terminology done. c. Clarified that Inbox/Outbox are the server's responsibility to create. d. Changed MAY to SHOULD for server rejecting organizer PARTSTAT changes of attendees. e. Allow COMPLETED as a valid attendee change. f. Allow SCHEDULE-STATUS as a valid attendee change on SCHEDULE- AGENT=CLIENT attendee properties. Daboo & Desruisseaux Expires September 9, 2012 [Page 87] Internet-Draft CalDAV Scheduling Extensions March 2012 g. COPY or MOVE on a calendar collection now declared to be undefined. h. Changed precondition error codes from 409 to 403. i. Clarified that rules 5546 must be used when server processes incoming scheduling messages. j. default-calendar-delete-allowed -> default-calendar-needed. k. Clarified that SCHEDULE-AGENT must be the same on all matching properties. l. Added more text justifying the need for calendar-user-type property. C.4. Changes in -09 a. Fixed some examples. b. Tweaked XML conventions. c. Removed description in SCHEDULE-STATUS example values. d. Tweaked 3.7 and 3.8 SCHEDULE-STATUS description to indicate it applies to the Organizer as well as Attendee. e. Updated to RFC 5545 reference. f. AD Review: clarified text about inbox resource deletion being acknowledgment of change. g. AD Review: clarified description of freebusy Outbox POST. h. AD Review: registered new 1.xx request-status codes and added new restriction on usage as per iTIP. i. AD Review: changes SHOULD NOT to MUST NOT for new property parameters when clients send scheduling messages. j. AD Review: CALDAV:schedule-calendar-transp now preserved during COPY. k. AD Review: changed CALDAV- to CALDAV: in acl descriptions. l. AD Review: fixed various minor typos. Daboo & Desruisseaux Expires September 9, 2012 [Page 88] Internet-Draft CalDAV Scheduling Extensions March 2012 m. AD Review: Added text to new principal properties to indicate that if they are not present, then the user is not enabled for the various scheduling operations. n. AD Review: clarified use of CALDAV:calendar-data element in CALDAV:response element. o. AD Review: made reference to 5545 IANA registry procedures for the two new element registries. p. AD Review: Fixed description of B5. example. q. Fixed SCHEDULE-AGENT/SCHEDULE-STATUS behavior for Attendee replies. C.5. Changes in -08 a. Added "Updates 4791". b. XML conventions changed to match that in CardDAV spec. c. Reworded child response behavior for Outbox. d. Reworded "octet size". e. If-Schedule-Match descriptions changed to remove implication that it is purely a conditional operation. f. Schedule-Reply header descriptions generalized to resource removal rather than just HTTP DELETE. g. Fixed various examples. C.6. Changes in -07 a. Restructured document. b. Clarified that CALDAV:schedule-calendar-transp only applies to calendar collection. c. Removed CALDAV:schedule-state property on scheduling messages in the scheduling Inbox collection. d. Added conditional requests on scheduling object resources. e. Added section on handling of PARTSTAT. Daboo & Desruisseaux Expires September 9, 2012 [Page 89] Internet-Draft CalDAV Scheduling Extensions March 2012 f. Added SCHEDULE-FORCE-SEND iCalendar property parameter. g. Added clarification on child resources in scheduling Outbox collections. h. Clarified Attendee changes that server MUST allow, and removed restrictions on changes that Attendee MUST NOT do. i. Added Example Scheduling Transactions appendix. j. Scheduling privileges are no longer required to be non-abstract. k. Removed handling of REFRESH requests. l. Removed handling of VJOURNAL components. m. Completed IANA Considerations section. n. Added references to RFC3283 and RFC5234. o. Updated references to iCalendar, iTIP and iMIP. C.7. Changes in -06 a. Removed distinction between scheduling calendar collections and basic calendar collections - now just have calendar collections. b. Clients now "MAY" reload data rather than "SHOULD" reload data. c. Fixed in examples. d. Removed CALDAV:attachments-allowed precondition on POST to Outbox as that is no longer relevant. e. Added CALDAV:default-calendar-delete-allowed precondition for DELETE. f. Relaxed MUST->MAY for Organizer setting PARTSTAT value. g. Tweaked restrictions on Create/Modify to emphasize that 4791 restrictions also apply. h. Added comment that 'opaque' is the default when the CALDAV: schedule-calendar-transp property is not present. i. Description of Schedule-Reply header changed to reflect that it is only relevant for Attendees. Daboo & Desruisseaux Expires September 9, 2012 [Page 90] Internet-Draft CalDAV Scheduling Extensions March 2012 j. Minor typos fixed. C.8. Changes in -05 This draft has changed substantially since the -04 version. The primary reason for this change was implementation experience from a number of vendors who implemented products based on the earlier drafts. Experience showed that the client/server interaction was not reliable in keeping scheduling messages synchronized between organizer and attendees. In addition the latency in updates due to clients being offline proved unacceptable to users. These issues led to the redesign of this specification to support a server-based processing model that eliminates all the problems seen previously. Whilst this adds significant complexity to the server in that it needs to be a full blown iTIP processing agent, it does remove a lot of the same complexity from clients, opening up the possibility of supporting complex scheduling behaviors even with "thin" clients. In the judgement of the authors, we consider this new specification to be a substantial improvement over the old one and believe it represents a stronger protocol that will lead to better interoperability. Daboo & Desruisseaux Expires September 9, 2012 [Page 91] Internet-Draft CalDAV Scheduling Extensions March 2012 Authors' Addresses Cyrus Daboo Apple Inc. 1 Infinite Loop Cupertino, CA 95014 USA EMail: cyrus@daboo.name URI: http://www.apple.com/ Bernard Desruisseaux Oracle Corporation 600 Blvd. de Maisonneuve West Suite 1900 Montreal, QC H3A 3J2 CANADA EMail: bernard.desruisseaux@oracle.com URI: http://www.oracle.com/ Daboo & Desruisseaux Expires September 9, 2012 [Page 92] --==========55BF0D386A64FFA03922========== Content-Type: text/html; charset=utf-8; name="diff.html" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="diff.html"; size=472141 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 Diff: draft-desruisseaux-caldav-sched-11.txt - = draft-desruisseaux-caldav-sched-12.txt=20 =20 =20 =20 =20 =20
< draft-desruisseaux-caldav-sched-11.txt  draft-desruisseaux-caldav-sched-12.txt >
Network Working Group = C. Daboo Network Working Group = C. Daboo
Internet-Draft = Apple Inc. Internet-Draft = Apple Inc.
Updates: 4791 (if approved) = B. Desruisseaux Updates: 4791,5546 (if = approved) B. Desruisseaux
Intended status: Standards Track = Oracle Intended status: Standards = Track Oracle
Expires: September 8, 2012 = March 7, 2012 Expires: September 9, 2012 = March 8, 2012
= CalDAV Scheduling Extensions to WebDAV CalDAV Scheduling Extensions to = WebDAV
= draft-desruisseaux-caldav-sched-11 = draft-desruisseaux-caldav-sched-12
Abstract Abstract
= This document defines extensions to the CalDAV "calendar-access" = This document defines extensions to the CalDAV = "calendar-access"
= feature to specify a standard way of performing scheduling = operations feature to specify a = standard way of performing scheduling operations
= with iCalendar-based calendar components. This document defines = the with iCalendar-based calendar = components. This document defines the
= "calendar-auto-schedule" feature of CalDAV. "calendar-auto-schedule" feature of CalDAV.
Status of This Memo Status = of This Memo
skipping to change at page 1, line 34 = skipping to change at = page 1, line 34
= Internet-Drafts are working documents of the Internet Engineering = Internet-Drafts are working documents of the = Internet Engineering
= Task Force (IETF). Note that other groups may also distribute = Task Force (IETF). Note that other groups may = also distribute
= working documents as Internet-Drafts. The list of current = Internet- working documents as = Internet-Drafts. The list of current Internet-
= Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at = http://datatracker.ietf.org/drafts/current/.
= Internet-Drafts are draft documents valid for a maximum of six = months Internet-Drafts are draft = documents valid for a maximum of six months
= and may be updated, replaced, or obsoleted by other documents at = any and may be updated, replaced, or = obsoleted by other documents at any
= time. It is inappropriate to use Internet-Drafts as reference = time. It is inappropriate to use = Internet-Drafts as reference
= material or to cite them other than as "work in progress." = material or to cite them other than as "work in = progress."
= This Internet-Draft will expire on September 8, 2012. This = Internet-Draft will expire on September 9, = 2012.
Copyright Notice Copyright = Notice
= Copyright (c) 2012 IETF Trust and the persons identified as the = Copyright (c) 2012 IETF Trust and the persons = identified as the
= document authors. All rights reserved. = document authors. All rights reserved.
= This document is subject to BCP 78 and the IETF Trust's Legal = This document is subject to BCP 78 and the IETF = Trust's Legal
= Provisions Relating to IETF Documents = Provisions Relating to IETF Documents
= (http://trustee.ietf.org/license-info) in effect on the date of = (http://trustee.ietf.org/license-info) in = effect on the date of
= publication of this document. Please review these documents = publication of this document. Please review = these documents
skipping to change at page 2, line 21 = skipping to change at = page 2, line 21
= the copyright in such materials, this document may not be modified = the copyright in such materials, this document = may not be modified
= outside the IETF Standards Process, and derivative works of it may = outside the IETF Standards Process, and = derivative works of it may
= not be created outside the IETF Standards Process, except to = format not be created outside the IETF = Standards Process, except to format
it = for publication as an RFC or to translate it into languages other = it for publication as an RFC or to translate it = into languages other
= than English. than English.
Table = of Contents Table of Contents
1. = Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 = 1. Introduction . . . . . . . . . . . . . . . = . . . . . . . . . . 6
= 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . = 7 1.1. Terminology . . . . . . . . = . . . . . . . . . . . . . . . 7
= 1.2. Notational Conventions . . . . . . . . . . . . . . . . . . 8 1.2. = Notational Conventions . . . . . . . . . . . . . . . . . . 7
= 1.3. XML Namespaces and Processing . . . . . . . . . . . . . . 9 1.3. XML = Namespaces and Processing . . . . . . . . . . . . . . 8
= 2. Scheduling Support . . . . . . . . . . . . . . . . . . . . . . 10 2. = Scheduling Support . . . . . . . . . . . . . . . . . . . . . . 9
= 2.1. Scheduling Outbox Collection . . . . . . . . . . . . . . . 10 2.1. = Scheduling Outbox Collection . . . . . . . . . . . . . . . 9
= 2.1.1. CALDAV:schedule-outbox-URL Property . . . . . . . . . 11 2.1.1. = CALDAV:schedule-outbox-URL Property . . . . . . . . . 10
= 2.2. Scheduling Inbox Collection . . . . . . . . . . . . . . . 12 2.2. = Scheduling Inbox Collection . . . . . . . . . . . . . . . 11
= 2.2.1. CALDAV:schedule-inbox-URL Property . . . . . . . . . . 13 2.2.1. = CALDAV:schedule-inbox-URL Property . . . . . . . . . . 12
= 2.3. Calendaring Reports Extensions . . . . . . . . . . . . . . 13 2.3. = Calendaring Reports Extensions . . . . . . . . . . . . . . 12
= 2.4. Additional Principal Properties . . . . . . . . . . . . . 14 2.4. = Additional Principal Properties . . . . . . . . . . . . . 13
= 2.4.1. CALDAV:calendar-user-address-set Property . . . . . . 14 2.4.1. = CALDAV:calendar-user-address-set Property . . . . . . 13
= 2.4.2. CALDAV:calendar-user-type Property . . . . . . . . . . 15 2.4.2. = CALDAV:calendar-user-type Property . . . . . . . . . . 14
= 3. Scheduling Operations . . . . . . . . . . . . . . . . . . . . 17 3. = Scheduling Operations . . . . . . . . . . . . . . . . . . . . 16
= 3.1. Identifying Scheduling Object Resources . . . . . . . . . 17 3.1. = Identifying Scheduling Object Resources . . . . . . . . . 16
= 3.2. Handling Scheduling Object Resources . . . . . . . . . . . 17 3.2. = Handling Scheduling Object Resources . . . . . . . . . . . 16
= 3.2.1. Organizer Scheduling Object Resources . . . . . . . . 17 3.2.1. = Organizer Scheduling Object Resources . . . . . . . . 16
= 3.2.1.1. Create . . . . . . . . . . . . . . . . . . . . . . 18 = 3.2.1.1. Create . . . . . . . . . . . . . . . . . . . . . . 17
= 3.2.1.2. Modify . . . . . . . . . . . . . . . . . . . . . . 19 = 3.2.1.2. Modify . . . . . . . . . . . . . . . . . . . . . . 18
= 3.2.1.3. Remove . . . . . . . . . . . . . . . . . . . . . . 20 = 3.2.1.3. Remove . . . . . . . . . . . . . . . . . . . . . . 19
= 3.2.2. Attendee Scheduling Object Resources . . . . . . . . . 21 3.2.2. = Attendee Scheduling Object Resources . . . . . . . . . 19
= 3.2.2.1. Allowed Attendee Changes . . . . . . . . . . . . . 21 = 3.2.2.1. Allowed Attendee Changes . . . . . . . . . . . . . 19
= 3.2.2.2. Create . . . . . . . . . . . . . . . . . . . . . . 22 = 3.2.2.2. Create . . . . . . . . . . . . . . . . . . . . . . 20
= 3.2.2.3. Modify . . . . . . . . . . . . . . . . . . . . . . 23 = 3.2.2.3. Modify . . . . . . . . . . . . . . . . . . . . . . 21
= 3.2.2.4. Remove . . . . . . . . . . . . . . . . . . . . . . 23 = 3.2.2.4. Remove . . . . . . . . . . . . . . . . . . . . . . 22
= 3.2.3. HTTP Methods . . . . . . . . . . . . . . . . . . . . . 24 3.2.3. = HTTP Methods . . . . . . . . . . . . . . . . . . . . . 22
= 3.2.3.1. PUT . . . . . . . . . . . . . . . . . . . . . . . 24 = 3.2.3.1. PUT . . . . . . . . . . . . . . . . . . . . . . . 23
= 3.2.3.2. COPY . . . . . . . . . . . . . = . . . . . . . . . . 25 3.2.3.2. DELETE . = . . . . . . . . . . . . . . . . . . . . . 23
= 3.2.3.3. MOVE . . . . . . . . . . . . . = . . . . . . . . . . 25 3.2.3.3. COPY . . = . . . . . . . . . . . . . . . . . . . . . 23
= 3.2.3.4. DELETE . . . . . . . . . . . . = . . . . . . . . . . 26 3.2.3.4. MOVE . . = . . . . . . . . . . . . . . . . . . . . . = 24
= 3.2.4. Additional Method Preconditions . . . . . . . . . . . 26 3.2.4. = Additional Method Preconditions . . . . . . . . . . . 25
= 3.2.4.1. CALDAV:unique-scheduling-object-resource 3.2.4.1. = CALDAV:unique-scheduling-object-resource
= Precondition . . . . . . . . . . . . . . . . . . . 26 = Precondition . . . . . . . . . . . . . . . . . . . 25
= 3.2.4.2. CALDAV:same-organizer-in-all-components 3.2.4.2. = CALDAV:same-organizer-in-all-components
= Precondition . . . . . . . . . . . . . . . . . . . 27 = Precondition . . . . . . . . . . . . . . . . . . . 25
= 3.2.4.3. CALDAV:allowed-organizer-scheduling-object-chan = 3.2.4.3. = CALDAV:allowed-organizer-scheduling-object-chan
= Precondition . . . . . . . . . . . . . . . . . . . 27 = Precondition . . . . . . . . . . . . . . . . . . . 26
= 3.2.4.4. CALDAV:allowed-attendee-scheduling-object-chang = 3.2.4.4. = CALDAV:allowed-attendee-scheduling-object-chang
= Precondition . . . . . . . . . . . . . . . . . . . 28 = Precondition . . . . . . . . . . . . . . . . . . . 26
= 3.2.5. DTSTAMP and SEQUENCE Properties . . . . . . . . . . . 28 3.2.5. = DTSTAMP and SEQUENCE Properties . . . . . . . . . . . 27
= 3.2.6. Restrict Recurrence Instances Sent to Attendees . . . 28 3.2.6. = Restrict Recurrence Instances Sent to Attendees . . . 27
= 3.2.7. Forcing the Server to Send a Scheduling Message . . . 29 3.2.7. = Forcing the Server to Send a Scheduling Message . . . 27
= 3.2.8. Attendee Participation Status . . . . . . . . . . . . 29 3.2.8. = Attendee Participation Status . . . . . . . . . . . . 28
= 3.2.9. Schedule Status Values . . . . . . . . . . . . . . . . 30 3.2.9. = Schedule Status Values . . . . . . . . . . . . . . . . 29
= 3.2.10. Avoiding Conflicts when Updating Scheduling Object = 3.2.10. Avoiding Conflicts when Updating = Scheduling Object
= Resources . . . . . . . . . . . . . . . . . . . . . . 33 = Resources . . . . . . . . . . . . . . . . . . . . . . 32
= 3.2.10.1. PUT . . . . . . . . . . . . . . . . . . . . . . . 35 = 3.2.10.1. PUT . . . . . . . . . . . . . . . . . . . . . . . 34
= 3.2.10.2. DELETE, COPY or MOVE . . . . . . . . . . . . . . . 35 = 3.2.10.2. DELETE, COPY or MOVE . . . . . . . . . . . . . . . 34
= 4. Processing Incoming Scheduling Messages . . . . . . . . . . . 36 4. = Processing Incoming Scheduling Messages . . . . . . . . . . . 35
= 4.1. Processing Organizer Requests, Additions, and 4.1. Processing Organizer Requests, Additions, = and
= Cancellations . . . . . . . . . . . . . . . . . . . . . . 36 = Cancellations . . . . . . . . . . . . . . . . . . . . . . 35
= 4.2. Processing Attendee Replies . . . . . . . . . . . . . . . 37 4.2. = Processing Attendee Replies . . . . . . . . . . . . . . . 36
= 4.3. Default Calendar Collection . . . . . . . . . . . . . . . 37 4.3. = Default Calendar Collection . . . . . . . . . . . . . . . 36
= 4.3.1. Additional Method Preconditions . . . . . . . . . . . 38 4.3.1. = Additional Method Preconditions . . . . . . . . . . . 37
= 4.3.1.1. CALDAV:default-calendar-needed Precondition . . . 38 = 4.3.1.1. CALDAV:default-calendar-needed Precondition . . . 37
= 4.3.1.2. CALDAV:valid-schedule-default-calendar-URL 4.3.1.2. = CALDAV:valid-schedule-default-calendar-URL
= Precondition . . . . . . . . . . . . . . . . . . . 38 = Precondition . . . . . . . . . . . . . . . . . . . 37
= 5. Request for Busy Time Information . . . . . . . . . . . . . . 40 5. = Request for Busy Time Information . . . . . . . . . . . . . . 39
= 5.1. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 40 5.1. = Status Codes . . . . . . . . . . . . . . . . . . . . . . . 39
= 5.2. Additional Method Preconditions . . . . . . . . . . . . . 41 5.2. = Additional Method Preconditions . . . . . . . . . . . . . 40
= 5.2.1. CALDAV:valid-scheduling-message Precondition . . . . . 41 5.2.1. = CALDAV:valid-scheduling-message Precondition . . . . . 40
= 5.2.2. CALDAV:valid-organizer Precondition . . . . . . . . . 41 5.2.2. = CALDAV:valid-organizer Precondition . . . . . . . . . 40
= 6. Scheduling Privileges . . . . . . . . . . . . . . . . . . . . 43 6. = Scheduling Privileges . . . . . . . . . . . . . . . . . . . . 42
= 6.1. Privileges on Scheduling Inbox Collections . . . . . . . . 43 6.1. = Privileges on Scheduling Inbox Collections . . . . . . . . 42
= 6.1.1. CALDAV:schedule-deliver Privilege . . . . . . . . . . 43 6.1.1. = CALDAV:schedule-deliver Privilege . . . . . . . . . . 42
= 6.1.2. CALDAV:schedule-deliver-invite Privilege . . . . . . . 43 6.1.2. = CALDAV:schedule-deliver-invite Privilege . . . . . . . 42
= 6.1.3. CALDAV:schedule-deliver-reply Privilege . . . . . . . 44 6.1.3. = CALDAV:schedule-deliver-reply Privilege . . . . . . . 43
= 6.1.4. CALDAV:schedule-query-freebusy Privilege . . . . . . . 44 6.1.4. = CALDAV:schedule-query-freebusy Privilege . . . . . . . 43
= 6.2. Privileges on Scheduling Outbox Collections . . . . . . . 44 6.2. = Privileges on Scheduling Outbox Collections . . . . . . . 43
= 6.2.1. CALDAV:schedule-send Privilege . . . . . . . . . . . . 44 6.2.1. = CALDAV:schedule-send Privilege . . . . . . . . . . . . 43
= 6.2.2. CALDAV:schedule-send-invite Privilege . . . . . . . . 44 6.2.2. = CALDAV:schedule-send-invite Privilege . . . . . . . . 43
= 6.2.3. CALDAV:schedule-send-reply Privilege . . . . . . . . . 45 6.2.3. = CALDAV:schedule-send-reply Privilege . . . . . . . . . 44
= 6.2.4. CALDAV:schedule-send-freebusy Privilege . . . . . . . 45 6.2.4. = CALDAV:schedule-send-freebusy Privilege . . . . . . . 44
= 6.3. Aggregation of Scheduling Privileges . . . . . . . . . . . 45 6.3. = Aggregation of Scheduling Privileges . . . . . . . . . . . 44
= 7. Additional iCalendar Property Parameters . . . . . . . . . . . 47 7. = Additional iCalendar Property Parameters . . . . . . . . . . . 46
= 7.1. Schedule Agent Parameter . . . . . . . . . . . . . . . . . 47 7.1. = Schedule Agent Parameter . . . . . . . . . . . . . . . . . 46
= 7.2. Schedule Force Send Parameter . . . . . . . . . . . . . . 48 7.2. = Schedule Force Send Parameter . . . . . . . . . . . . . . 47
= 7.3. Schedule Status Parameter . . . . . . . . . . . . . . . . 49 7.3. = Schedule Status Parameter . . . . . . . . . . . . . . . . 48
= 8. Additional Message Header Fields . . . . . . . . . . . . . . . 51 8. = Additional Message Header Fields . . . . . . . . . . . . . . . 50
= 8.1. Schedule-Reply Request Header . . . . . . . . . . . . . . 51 8.1. = Schedule-Reply Request Header . . . . . . . . . . . . . . 50
= 8.2. Schedule-Tag Response Header . . . . . . . . . . . . . . . 51 8.2. = Schedule-Tag Response Header . . . . . . . . . . . . . . . 50
= 8.3. If-Schedule-Tag-Match Request Header . . . . . . . . . . . 52 8.3. = If-Schedule-Tag-Match Request Header . . . . . . . . . . . 51
= 9. Additional WebDAV Properties . . . . . . . . . . . . . . . . . 53 9. = Additional WebDAV Properties . . . . . . . . . . . . . . . . . 52
= 9.1. CALDAV:schedule-calendar-transp Property . . . . . . . . . 53 9.1. = CALDAV:schedule-calendar-transp Property . . . . . . . . . 52
= 9.2. CALDAV:schedule-default-calendar-URL Property . . . . . . 54 9.2. = CALDAV:schedule-default-calendar-URL Property . . . . . . 53
= 9.3. CALDAV:schedule-tag Property . . . . . . . . . . . . . . . 55 9.3. = CALDAV:schedule-tag Property . . . . . . . . . . . . . . . 54
= 10. XML Element Definitions . . . . . . . . . . . . . . . . . . . 56 10. XML = Element Definitions . . . . . . . . . . . . . . . . . . . 55
= 10.1. CALDAV:schedule-response XML Element . . . . . . . . . . . 56 10.1. = CALDAV:schedule-response XML Element . . . . . . . . . . . 55
= 10.2. CALDAV:response XML Element . . . . . . . . . . . . . . . 56 10.2. = CALDAV:response XML Element . . . . . . . . . . . . . . . 55
= 10.3. CALDAV:recipient XML Element . . . . . . . . . . . . . . . 56 10.3. = CALDAV:recipient XML Element . . . . . . . . . . . . . . . 55
= 10.4. CALDAV:request-status XML Element . . . . . . . . . . . . 57 10.4. = CALDAV:request-status XML Element . . . . . . . . . . . . 56
= 11. Security Considerations . . . . . . . . . . . . . . . . . . . 58 11. = Security Considerations . . . . . . . . . . . . . . . . . . . 57
= 11.1. Preventing Denial of Service Attacks . . . . . . . . . . . 58 11.1. = Preventing Denial of Service Attacks . . . . . . . . . . . 57
= 11.2. Verifying Scheduling Operations . . . . . . . . . . . . . 58 11.2. = Verifying Scheduling Operations . . . . . . . . . . . . . 57
= 11.3. Verifying Busy Time Information Requests . . . . . . . . . 59 11.3. = Verifying Busy Time Information Requests . . . . . . . . . 58
= 11.4. Privacy Issues . . . . . . . . . . . . . . . . . . . . . . 59 11.4. = Privacy Issues . . . . . . . . . . . . . . . . . . . . . . 58
= 11.5. Mitigation of iTIP Threats . . . . . . . . . . . . . . . . 60 11.5. = Mitigation of iTIP Threats . . . . . . . . . . . . . . . . 59
= 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 61 12. IANA = Considerations . . . . . . . . . . . . . . . . . . . . . 60
= 12.1. Message Header Field Registrations . . . . . . . . . . . . 61 12.1. = Message Header Field Registrations . . . . . . . . . . . . 60
= 12.1.1. Schedule-Reply . . . . . . . . . . . . . . . . . . . . 61 = 12.1.1. Schedule-Reply . . . . . . . . . . . . . . . . . . . . 60
= 12.1.2. Schedule-Tag . . . . . . . . . . . . . . . . . . . . . 61 = 12.1.2. Schedule-Tag . . . . . . . . . . . . . . . . . . . . . 60
= 12.1.3. If-Schedule-Tag-Match . . . . . . . . . . . . . . . . 61 = 12.1.3. If-Schedule-Tag-Match . . . . . . . . . . . . . . . . 60
= 12.2. iCalendar Property Parameter Registrations . . . . . . . . 62 12.2. = iCalendar Property Parameter Registrations . . . . . . . . 61
= 12.3. iCalendar REQUEST-STATUS Value Registrations . . . . . . . 62 12.3. = iCalendar REQUEST-STATUS Value Registrations . . . . . . . 61
= 12.4. Additional iCalendar Elements Registries . . . . . . . . . 62 12.4. = Additional iCalendar Elements Registries . . . . . . . . . 61
= 12.4.1. Schedule Agent Values Registry . . . . . . . . . . . . 62 = 12.4.1. Schedule Agent Values Registry . . . . . . . . . . . . 61
= 12.4.2. Schedule Force Send Values Registry . . . . . . . . . 63 = 12.4.2. Schedule Force Send Values Registry . . . . . . . . . 62
= 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 64 13. = Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 63
= 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 65 14. = References . . . . . . . . . . . . . . . . . . . . . . . . . . 64
= 14.1. Normative References . . . . . . . . . . . . . . . . . . . 65 14.1. = Normative References . . . . . . . . . . . . . . . . . . . 64
= 14.2. Informative References . . . . . . . . . . . . . . . . . . 66 14.2. = Informative References . . . . . . . . . . . . . . . . . . 65
= Appendix A. Scheduling Privileges Summary . . . . . . . . . . . . 67 Appendix = A. Scheduling Privileges Summary . . . . . . . . . . . . 66
= A.1. Scheduling Inbox Privileges . . . . . . . . . . . . . . . 67 A.1. = Scheduling Inbox Privileges . . . . . . . . . . . . . . . 66
= A.2. Scheduling Outbox Privileges . . . . . . . . . . . . . . . 67 A.2. = Scheduling Outbox Privileges . . . . . . . . . . . . . . . 66
= Appendix B. Example Scheduling Operations . . . . . . . . . . . . 69 Appendix = B. Example Scheduling Operations . . . . . . . . . . . . 68
= B.1. Example: Organizer Inviting Multiple Attendees . . . . . . 69 B.1. = Example: Organizer Inviting Multiple Attendees . . . . . . 68
= B.2. Example: Attendee Receiving an Invitation . . . . . . . . 71 B.2. = Example: Attendee Receiving an Invitation . . . . . . . . 70
= B.3. Example: Attendee Replying to an Invitation . . . . . . . 73 B.3. = Example: Attendee Replying to an Invitation . . . . . . . 72
= B.4. Example: Organizer Receiving a Reply to an Invitation . . 76 B.4. = Example: Organizer Receiving a Reply to an Invitation . . 75
= B.5. Example: Organizer Requesting Busy Time Information . . . 78 B.5. = Example: Organizer Requesting Busy Time Information . . . 77
= B.6. Example: User Attempting to Invite Attendee on behalf = B.6. Example: User Attempting to Invite = Attendee on behalf
= of Organizer . . . . . . . . . . . . . . . . . . . . . . . 80 of = Organizer . . . . . . . . . . . . . . . . . . . . . . . 79
= B.7. Example: Attendee Declining an Instance of a Recurring = B.7. Example: Attendee Declining an Instance = of a Recurring
= Event . . . . . . . . . . . . . . . . . . . . . . . . . . 82 = Event . . . . . . . . . . . . . . . . . . . . . . . . . . 81
= B.8. Example: Attendee Removing an Instance of a Recurring = B.8. Example: Attendee Removing an Instance = of a Recurring
= Event . . . . . . . . . . . . . . . . . . . . . . . . . . 85 = Event . . . . . . . . . . . . . . . . . . . . . . . . . . 84
= Appendix C. Changes (to be removed by RFC Editor prior to = Appendix C. Changes (to be removed by RFC = Editor prior to
= publication) . . . . . . . . . . . . . . . . . . . . 88 = publication) . . . . . . . . . . . . . . . . . . . . 87
= C.1. Changes in -11 . . . . . . . . . . . . = . . . . . . . . . . 88 C.1. Changes in -12 . = . . . . . . . . . . . . . . . . . . . . . 87
= C.2. Changes in -10 . . . . . . . . . . . . = . . . . . . . . . . 88 C.2. Changes in -11 . = . . . . . . . . . . . . . . . . . . . . . 87
= C.3. Changes in -09 . . . . . . . . . . . . = . . . . . . . . . . 89 C.3. Changes in -10 . = . . . . . . . . . . . . . . . . . . . . . 87
= C.4. Changes in -08 . . . . . . . . . . . . = . . . . . . . . . . 90 C.4. Changes in -09 . = . . . . . . . . . . . . . . . . . . . . . 88
= C.5. Changes in -07 . . . . . . . . . . . . = . . . . . . . . . . 90 C.5. Changes in -08 . = . . . . . . . . . . . . . . . . . . . . . 89
= C.6. Changes in -06 . . . . . . . . . . . . = . . . . . . . . . . 91 C.6. Changes in -07 . = . . . . . . . . . . . . . . . . . . . . . 89
= C.7. Changes in -05 . . . . . . . . . . . . . . . . . . . . . . = 91 C.7. Changes in -06 . . . . . . . . . . . . . . . . . . . . . . = 90
C.8. Changes in -05 . . . . . . . . . . . . . = . . . . . . . . . 91
1. = Introduction 1. Introduction
= This document specifies extensions to the CalDAV "calendar-access" = This document specifies extensions to the = CalDAV "calendar-access"
= [RFC4791] feature to enable scheduling of iCalendar-based = [RFC5545] [RFC4791] feature to enable = scheduling of iCalendar-based [RFC5545]
= calendar components between Calendar = Users. calendar components = between calendar users.
= This extension leverages the scheduling methods defined in the = This extension leverages the scheduling methods = defined in the
= iCalendar Transport-independent Interoperability Protocol (iTIP) = iCalendar Transport-independent = Interoperability Protocol (iTIP)
= [RFC5546] to permit Calendar Users to perform = scheduling operations [RFC5546] to = permit calendar users to perform scheduling = operations
= such as schedule, reschedule, respond to scheduling request or = cancel such as schedule, reschedule, = respond to scheduling request or cancel
= calendar components, as well as search for busy time information. = calendar components, as well as search for busy = time information.
= However, the following iTIP [RFC5546] features are not covered: = However, the following iTIP [RFC5546] features = are not covered:
= publishing, countering, delegating, refreshing and forwarding = publishing, countering, delegating, refreshing = and forwarding
= calendar components, as well as replacing the Organizer of a = calendar calendar components, as well = as replacing the Organizer of a calendar
= component. It is expected that future extensions will be = developed component. It is expected = that future extensions will be developed
to = address these. to address = these.
= This specification defines a client/server scheduling protocol, = where This specification defines a = client/server scheduling protocol, where
= the server is made responsible for sending scheduling messages and = the server is made responsible for sending = scheduling messages and
= processing incoming scheduling messages. The client operations of = processing incoming scheduling messages. The = client operations of
= creating, modifying or deleting a calendar component in a calendar = is creating, modifying or deleting a = calendar component in a calendar is
= enough to trigger the server to deliver the necessary scheduling = enough to trigger the server to deliver the = necessary scheduling
= messages to the appropriate Calendar Users. = This approach is messages to the = appropriate calendar users. This approach = is
= sometimes referred to as "implicit scheduling". sometimes referred to as "implicit scheduling".
= This specification does not attempt to = address how scheduling might = This specification only = addresses how scheduling occurs with = users on
occur with users on different systems (either other CalDAV = servers, a = single system (i.e., scheduling between CalDAV servers, or = some
= or some other calendaring and scheduling system). = However, the basic other = calendaring and scheduling system, is not = defined). However,
scheduling process used here = does not prevent servers from sending this specification is compatible = with servers being able to send = or
and receiving scheduling = messages with "external" users based = on = receive scheduling messages with "external" users (e.g., using the
alternative protocols, such = as the iCalendar Message-Based = iCalendar Message-Based Interoperability Protocol iMIP [RFC6047]).
= Interoperability Protocol (iMIP) = [RFC6047].
In iTIP-based scheduling, there = is an event "Organizer" whose role is
to schedule an event between one = or more "Attendees", and this is
done by sending out invitations = and handling responses from each
Attendee. Often times an = Organizer will do a "freebusy" lookup to
check on Attendees' availability = (free-time).
Servers supporting this = specification advertise their capabilities
and provides new collections for = scheduling operations as described
in Section 2. =
= Scheduling works by having the client store = iCalendar data with Section 3 defines the = automated "Scheduling Operations", that allow = a
appropriate scheduling = properties included ("ORGANIZER" and client to store iCalendar = data on a CalDAV server, with the server
"ATTENDEE" iCalendar = properties). This is called a "Scheduling taking specific actions in = response. One of three scheduling
Operation" and fully described = in Section 3. The server detects that operations can take place: "create", "modify" or "remove", based on
the data represents a scheduling = operation (as per Section 3.1) and the HTTP method used for the request, and a comparison between any
identifies the operation as one = initiated by the Organizer or = existing and any new iCalendar data.
Attendee. Processing of the = scheduling operation, then depends on
= who is initiating the scheduling operation (as per Section 3.2.1 = or
Section 3.2.2 respectively). In = each case, one of three scheduling
= operations can take place: "create", "modify" or "remove". Which
operation occurs is based = on the HTTP method used for the request, as
well as a comparison = between any existing iCalendar data and any = new
= iCalendar data in the request (as per Section = 3.2.3).
= Scheduling operations can result in = scheduling messages being Section 4 defines how the server = processes scheduling messages sent
delivered to the Organizer = (in the case of a reply from an Attendee) as the result of a scheduling operation.
or to Attendees (requests and = updates from the Organizer). The
server is responsible for = processing incoming scheduling messages = as
per Section 4. =
= Clients wishing to check freebusy information for calendar users do Section 5 defines how = freebusy requests with an immediate response is
so using a POST request against = a special collection. An immediate accomplished.
= result is returned by = the server detailing freebusy information as
per Section 5. =
= Control over who is allowed to send scheduling = messages, or from whom Section 6 defines access control privileges for the scheduling
scheduling messages will be = received or freebusy results returned to, operations defined in this = specification.
is controlled via a set = of access control privileges dedicated = to the
= various scheduling operations that can occur as per Section 6.
= For the majority of the following discussion, scheduling of events = For the majority of the following discussion, = scheduling of events
= will be discussed. However, scheduling of to-dos is also fully = will be discussed. However, scheduling of = to-dos is also fully
= supported by this specification. = supported by this specification.
= Discussion of this Internet-Draft is taking place on the mailing = Discussion of this Internet-Draft is taking = place on the mailing
= lists at <https://www.ietf.org/mailman/listinfo/caldav> and = lists at = <https://www.ietf.org/mailman/listinfo/caldav> and
= <http://lists.osafoundation.org/pipermail/ietf-caldav>. = = <http://lists.osafoundation.org/pipermail/ietf-caldav>.
1.1. = Terminology 1.1. Terminology
= This specification uses much of the same terminology as iCalendar = This specification reuses much of the same terminology as = iCalendar
= [RFC5545], iTIP [RFC5546], WebDAV [RFC4918], and CalDAV [RFC4791]. = [RFC5545], iTIP [RFC5546], WebDAV [RFC4918], = and CalDAV [RFC4791].
= The following definitions are provided to aid the = reader in Additional terms used by this specification are:
understanding this specification.
Calendar User (CU): An entity = (often a human) that accesses calendar
information = [RFC3283].
Calendar collection: A resource = that acts as a container of
references to child calendar = object resources [RFC4791].
Calendar object resource: A = resource representing a calendar object
(event, to-do, journal entry, = or other calendar components)
[RFC4791]. =
= Scheduling object resource: A calendar object resource contained = in Scheduling object resource: A = calendar object resource contained in
= a calendar collection for which the server will take care of = a calendar collection for which the server = will take care of
= sending scheduling messages on behalf of the owner of the calendar = sending scheduling messages on behalf of the = owner of the calendar
= collection. collection.
= Organizer scheduling object resource: A scheduling object = resource Organizer scheduling object = resource: A scheduling object resource
= owned by the Organizer. owned by = the Organizer.
= Attendee scheduling object resource: A scheduling object resource = Attendee scheduling object resource: A = scheduling object resource
= owned by an Attendee. owned by an = Attendee.
= Scheduling operation: Add, change or remove operations on a = Scheduling operation: Add, change or remove = operations on a
= scheduling object resource for which the server will deliver = scheduling object resource for which the = server will deliver
= scheduling messages to other Calendar = Users. scheduling messages = to other calendar users.
= Scheduling message: A calendar object that describes a scheduling = Scheduling message: A calendar object that = describes a scheduling
= operation such as schedule, reschedule, reply, or cancel. operation such as schedule, reschedule, reply, or = cancel.
= Scheduling Outbox collection: A resource at which busy time = Scheduling Outbox collection: A resource at = which busy time
= information requests are targeted. = information requests are targeted.
= Scheduling Inbox collection: A collection in which incoming = Scheduling Inbox collection: A collection in = which incoming
= scheduling messages are delivered. = scheduling messages are delivered.
skipping to change at page 10, line 33 = skipping to change at = page 9, line 33
A = scheduling Outbox collection is used as the target for busy time = A scheduling Outbox collection is used as the = target for busy time
= information requests, and to manage privileges that apply to = outgoing information requests, and to = manage privileges that apply to outgoing
= scheduling requests. scheduling = requests.
A = scheduling Outbox collection MUST report the DAV:collection and = A scheduling Outbox collection MUST report the = DAV:collection and
= CALDAV:schedule-outbox XML elements in the value of the DAV: = CALDAV:schedule-outbox XML elements in the = value of the DAV:
= resourcetype property. The element type declaration for CALDAV: = resourcetype property. The element type = declaration for CALDAV:
= schedule-outbox is: schedule-outbox = is:
= <!ELEMENT schedule-outbox = EMPTY> <!ELEMENT = schedule-outbox EMPTY>
= Example: Example:
= <D:resourcetype xmlns:D=3D"DAV:"> <D:resourcetype xmlns:D=3D"DAV:">
= <D:collection/> = <D:collection/>
= <C:schedule-outbox = xmlns:C=3D"urn:ietf:params:xml:ns:caldav"/> <C:schedule-outbox = xmlns:C=3D"urn:ietf:params:xml:ns:caldav"/>
= </D:resourcetype> = </D:resourcetype>
A = scheduling Outbox collection MUST NOT be a child (at any depth) of = A scheduling Outbox collection MUST NOT be a = child (at any depth) of
a = calendar collection resource. a = calendar collection resource.
= The following WebDAV properties specified in CalDAV = "calendar-access" The following WebDAV = properties specified in CalDAV "calendar-access"
= [RFC4791] MAY also be defined on scheduling Outbox collections and = [RFC4791] MAY also be defined on scheduling = Outbox collections and
= apply to scheduling messages submitted to the scheduling Outbox = apply to scheduling messages submitted to the = scheduling Outbox
= collection with the POST method: = collection with the POST method:
o = CALDAV:supported-calendar-component-set = o CALDAV:supported-calendar-component-set
skipping to change at page 11, line 47 = skipping to change at = page 10, line 47
= and MOVE operations. and MOVE = operations.
= Description: This property is needed for a client to determine = where Description: This property is = needed for a client to determine where
= the scheduling Outbox collection of the current user is located so = the scheduling Outbox collection of the = current user is located so
= that sending of scheduling messages can occur. If not present, = that sending of scheduling messages can = occur. If not present,
= then the associated calendar user is not enabled for the sending = then the associated calendar user is not = enabled for the sending
= of scheduling messages on the server. = of scheduling messages on the server.
= Definition: Definition:
= <!ELEMENT schedule-outbox-URL = (DAV:href)> <!ELEMENT = schedule-outbox-URL (DAV:href)>
2.2. = Scheduling Inbox Collection 2.2. = Scheduling Inbox Collection
A = scheduling Inbox collection contains copies of incoming scheduling = A scheduling Inbox collection contains copies = of incoming scheduling
= messages. These can be requests sent by an Organizer, or replies = messages. These can be requests sent by an = Organizer, or replies
= sent by an Attendee in response to a request. The scheduling = Inbox sent by an Attendee in response = to a request. The scheduling Inbox
= collection is also used to manage scheduling privileges. collection is also used to manage scheduling = privileges.
A = scheduling Inbox collection MUST report the DAV:collection and = A scheduling Inbox collection MUST report the = DAV:collection and
= CALDAV:schedule-inbox XML elements in the value of the DAV: = CALDAV:schedule-inbox XML elements in the value = of the DAV:
= resourcetype property. The element type declaration for CALDAV: = resourcetype property. The element type = declaration for CALDAV:
= schedule-inbox is: schedule-inbox = is:
= <!ELEMENT schedule-inbox = EMPTY> <!ELEMENT = schedule-inbox EMPTY>
= Example: Example:
= <D:resourcetype xmlns:D=3D"DAV:"> <D:resourcetype xmlns:D=3D"DAV:">
= <D:collection/> = <D:collection/>
= <C:schedule-inbox = xmlns:C=3D"urn:ietf:params:xml:ns:caldav"/> <C:schedule-inbox = xmlns:C=3D"urn:ietf:params:xml:ns:caldav"/>
= </D:resourcetype> = </D:resourcetype>
= Scheduling Inbox collections MUST only contain calendar object = Scheduling Inbox collections MUST only contain = calendar object
= resources that obey the restrictions specified in iTIP [RFC5546]. = resources that obey the restrictions specified = in iTIP [RFC5546].
= Consequently, scheduling Inbox collections MUST NOT contain any = types Consequently, scheduling Inbox = collections MUST NOT contain any types
of = collection resources. Restrictions defined in Section 4.1 of = of collection resources. Restrictions defined = in Section 4.1 of
= CalDAV "calendar-access" [RFC4791] on calendar object resources = CalDAV "calendar-access" [RFC4791] on calendar = object resources
= contained in calendar collections (e.g., "UID" uniqueness) do not = contained in calendar collections (e.g., "UID" = uniqueness) do not
= apply to calendar object resources contained in a scheduling Inbox = apply to calendar object resources contained in = a scheduling Inbox
= collection. Thus, multiple calendar object resources contained in = a collection. Thus, multiple calendar = object resources contained in a
= scheduling Inbox collection can have the same "UID" property value = scheduling Inbox collection can have the same = "UID" property value
skipping to change at page 13, line 42 = skipping to change at = page 12, line 42
= and MOVE operations. and MOVE = operations.
= Description: This property allows a client to determine where the = Description: This property allows a client to = determine where the
= scheduling Inbox collection of the current user is located so that = scheduling Inbox collection of the current = user is located so that
= processing of scheduling messages can occur. If not present, then = processing of scheduling messages can occur. = If not present, then
= the associated calendar user is not enabled for reception of = the associated calendar user is not enabled = for reception of
= scheduling messages on the server. = scheduling messages on the server.
= Definition: Definition:
= <!ELEMENT schedule-inbox-URL = (DAV:href)> <!ELEMENT = schedule-inbox-URL (DAV:href)>
2.3. = Calendaring Reports Extensions 2.3. = Calendaring Reports Extensions
= This specification extends the CALDAV:calendar-query and CALDAV: = This specification extends the = CALDAV:calendar-query and CALDAV:
= calendar-multiget REPORTs to return results for calendar object = calendar-multiget REPORTs to return results for = calendar object
= resources in scheduling Inbox collections. resources in scheduling Inbox collections.
= When a CALDAV:calendar-query REPORT includes a time-range query = and When a CALDAV:calendar-query = REPORT includes a time-range query and
= targets a scheduling Inbox collection, if any calendar object = targets a scheduling Inbox collection, if any = calendar object
= resources contain "VEVENT" calendar components that do not include = a resources contain "VEVENT" calendar = components that do not include a
skipping to change at page 14, line 48 = skipping to change at = page 13, line 48
= Outbox collections. In the event that a user has no well defined = Outbox collections. In the event that a = user has no well defined
= identifier for their calendar user address, the URI of their = identifier for their calendar user address, = the URI of their
= principal resource can be used. This property SHOULD be principal resource can be used. This property SHOULD = be
= searchable using the DAV:principal-property-search REPORT. The = searchable using the = DAV:principal-property-search REPORT. The
= DAV:principal-search-property-set REPORT SHOULD identify this = DAV:principal-search-property-set REPORT = SHOULD identify this
= property as such. If not present, then the associated calendar = property as such. If not present, then the = associated calendar
= user is not enabled for scheduling on the server. user is not enabled for scheduling on the = server.
= Definition: Definition:
= <!ELEMENT calendar-user-address-set = (DAV:href*)> <!ELEMENT = calendar-user-address-set (DAV:href*)>
= Example: Example:
= <C:calendar-user-address-set xmlns:D=3D"DAV:" <C:calendar-user-address-set = xmlns:D=3D"DAV:"
= = xmlns:C=3D"urn:ietf:params:xml:ns:caldav"> = xmlns:C=3D"urn:ietf:params:xml:ns:caldav">
= <D:href>mailto:bernard@example.com</D:href> = = <D:href>mailto:bernard@example.com</D:href>
= = <D:href>mailto:bernard.desruisseaux@example.com</D:href> = <D:href>mailto:bernard.desruisseaux@example.com</D:href>
= </C:calendar-user-address-set> = </C:calendar-user-address-set>
2.4.2. CALDAV:calendar-user-type Property 2.4.2. CALDAV:calendar-user-type Property
= Name: calendar-user-type Name: = calendar-user-type
= Namespace: urn:ietf:params:xml:ns:caldav Namespace: urn:ietf:params:xml:ns:caldav
= Purpose: Identifies the calendar user type of the associated = Purpose: Identifies the calendar user type of = the associated
= principal resource. principal = resource.
skipping to change at page 15, line 48 = skipping to change at = page 14, line 48
= "rooms"). This property MAY be defined on principal resources to = "rooms"). This property MAY be defined on = principal resources to
= indicate the type of calendar user associated with the principal = indicate the type of calendar user = associated with the principal
= resource. Its value is the same as the iCalendar "CUTYPE" = resource. Its value is the same as the = iCalendar "CUTYPE"
= property parameter that can be used on "ATTENDEE" properties. = property parameter that can be used on = "ATTENDEE" properties.
= This property SHOULD be searchable using the DAV:principal- = This property SHOULD be searchable using the = DAV:principal-
= property-search REPORT. The DAV:principal-search-property-set = property-search REPORT. The = DAV:principal-search-property-set
= REPORT SHOULD identify this property as such. REPORT SHOULD identify this property as such.
= Definition: Definition:
= <!ELEMENT calendar-user-type = (#PCDATA)> <!ELEMENT = calendar-user-type (#PCDATA)>
= Example: Example:
= <C:calendar-user-type = <C:calendar-user-type
= xmlns:C=3D"urn:ietf:params:xml:ns:caldav">INDIVIDUAL< = = xmlns:C=3D"urn:ietf:params:xml:ns:caldav">INDIVIDUAL<
= /C:calendar-user-type> = /C:calendar-user-type>
3. = Scheduling Operations 3. Scheduling = Operations
= When a calendar object resource is created, modified or removed = from When a calendar object resource = is created, modified or removed from
a = calendar collection, the server examines the calendar data and = a calendar collection, the server examines the = calendar data and
= checks to see whether the data represents a scheduling object = checks to see whether the data represents a = scheduling object
= resource. If it does, the server will automatically attempt to = resource. If it does, the server will = automatically attempt to
= deliver a scheduling message to the appropriate Calendar Users. = deliver a scheduling message to the appropriate calendar users.
= Several types of scheduling operations can occur in this case, = Several types of scheduling operations can = occur in this case,
= equivalent to iTIP "REQUEST", "REPLY", "CANCEL", and "ADD" = equivalent to iTIP "REQUEST", "REPLY", = "CANCEL", and "ADD"
= operations. operations.
3.1. = Identifying Scheduling Object Resources 3.1. Identifying Scheduling Object Resources
= Calendar object resources on which the server performs scheduling = Calendar object resources on which the server = performs scheduling
= operations are referred to as scheduling object resources. There = are operations are referred to as = scheduling object resources. There are
= two types of scheduling object resources: organizer scheduling = object two types of scheduling object = resources: organizer scheduling object
= resources, and attendee scheduling object resources. resources, and attendee scheduling object = resources.
skipping to change at page 18, line 9 = skipping to change at = page 17, line 9
3.2.1. Organizer Scheduling Object Resources = 3.2.1. Organizer Scheduling Object = Resources
An = Organizer can create, modify or remove a scheduling object = An Organizer can create, modify or remove a = scheduling object
= resource. These operations are each described next, and how they = are resource. These operations are = each described next, and how they are
= invoked via HTTP requests is described in Section 3.2.3. invoked via HTTP requests is described in Section = 3.2.3.
= The Organizer of a calendar component can also be an Attendee of = that The Organizer of a calendar = component can also be an Attendee of that
= calendar component. In such cases the server MUST NOT send a = calendar component. In such cases the server = MUST NOT send a
= scheduling message to the Attendee that matches the Organizer. = scheduling message to the Attendee that matches = the Organizer.
The server MUST take into account scheduling privileges as = described
in Section 6 when handling each type of scheduling = operation.
Restrictions on calendar object resources defined in = Section 4.1 of
[RFC4791] MUST also be enforced when handling each type = of scheduling
operation.
The server SHOULD reject any attempt to set the = "PARTSTAT" iCalendar
property parameter value of the "ATTENDEE" iCalendar = property of
other users in the calendar object resource to a value = other than
"NEEDS-ACTION" if the "SCHEDULE-AGENT" property = parameter value is
not present or set to the value = "SERVER".
The server MAY reject attempts to create a scheduling = object resource
that specifies a "UID" property value already specified = in a
scheduling object resource contained in another = calendar collection
of the Organizer.
=
3.2.1.1. Create 3.2.1.1. = Create
= When a scheduling object resource is created by the = Organizer, the When an Organizer creates a scheduling object resource, the server
= server will inspect each "ATTENDEE" property = to determine if a MUST inspect each = "ATTENDEE" property to determine whether to = send a
= scheduling message ought to be delivered to this = Attendee according scheduling = message. The table below indicates the appropriate iTIP
to the value of the "SCHEDULE-AGENT" property parameter = (see method = used by the server, taking into account = any "SCHEDULE-AGENT"
= Section 7.1) as described in the table = below: property parameter (see = Section 7.1) specified on each = "ATTENDEE"
property.
= +------------------+-------------+ = +------------------+-------------+
= | SCHEDULE-AGENT | iTIP METHOD | | SCHEDULE-AGENT | iTIP METHOD = |
= +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ +------------------+-------------+
= | SERVER (default) | REQUEST | | SERVER (default) | REQUEST = |
= +------------------+-------------+ = | = | |
= | CLIENT | -- | | CLIENT | -- = |
= +------------------+-------------+ = | = | |
= | NONE | -- | | NONE | -- = |
= +------------------+-------------+ = +------------------+-------------+
= The server MUST add a "SCHEDULE-STATUS" iCalendar property = parameter The server MUST add a = "SCHEDULE-STATUS" iCalendar property parameter
= (see Section 7.3) to the "ATTENDEE" iCalendar property in the = (see Section 7.3) to the "ATTENDEE" iCalendar = property in the
= scheduling object resource being created, and set its value as = scheduling object resource being created, and = set its value as
= described in Section 3.2.9. This will result in the created = calendar described in Section 3.2.9. = This will result in the created calendar
= object resource differing from the calendar data sent in the HTTP = object resource differing from the calendar = data sent in the HTTP
= request. As a result clients MAY reload the calendar data from = the request. As a result clients MAY = reload the calendar data from the
= server in order to update to the new server generated state = server in order to update to the new server = generated state
= information. Servers MUST NOT set the "SCHEDULE-STATUS" property = information. Servers MUST NOT set the = "SCHEDULE-STATUS" property
= parameter on the "ATTENDEE" property of Attendees for which it did = parameter on the "ATTENDEE" property of = Attendees for which it did
= not attempt to deliver a scheduling message. not attempt to deliver a scheduling message.
= Restrictions:
1. The server SHOULD reject any = attempt to set the "PARTSTAT"
iCalendar property parameter = value of the "ATTENDEE" iCalendar
property of other users in = the calendar object resource to a
value other than = "NEEDS-ACTION" if the "SCHEDULE-AGENT" property
parameter value is not = present or set to the value "SERVER".
2. The server MAY reject = attempts to create a scheduling object
resource that specifies a = "UID" property value already specified
in a scheduling object = resource contained in another calendar
collection of the = Organizer.
3. The server MUST take into = account scheduling privileges as
described in Section 6 when = handling the creation of a scheduling
object = resource.
4. Restrictions on calendar = object resources defined in Section 4.1
of [RFC4791] MUST also be = enforced.
= =
= The server MUST return an error with the CALDAV:allowed-organizer- = The server MUST return an error with the = CALDAV:allowed-organizer-
= scheduling-object-change precondition code (Section 3.2.4.3) when = the scheduling-object-change = precondition code (Section 3.2.4.3) when the
= Organizer attempts to change the iCalendar data in a manner that = is Organizer attempts to change the = iCalendar data in a manner that is
= forbidden. forbidden.
3.2.1.2. Modify 3.2.1.2. = Modify
= When a scheduling object resource is modified by the = Organizer, the When an Organizer modifies a scheduling object resource, the server
= server will inspect each "ATTENDEE" property = in the new calendar data MUST inspect each = "ATTENDEE" property in both the original and
to determine which ones have the = "SCHEDULE-AGENT" iCalendar property modified iCalendar data = on a per-instance basis to determine = whether
parameter. It will then need to = compare this with the "ATTENDEE" = to send a scheduling message. The table below = indicates the
properties in the existing = calendar object resource that is being appropriate iTIP method = used by the server, taking into account = any
modified. = "SCHEDULE-AGENT" = property parameter (see Section 7.1) specified on
each "ATTENDEE" property. = The values "SERVER", "CLIENT", and "NONE"
For each Attendee in the = old and new calendar data on a = per-instance
= basis, and taking into account the addition or = removal of Attendees,
the server will determine = whether to deliver a scheduling message to
the Attendee. The following table determines = whether the server
needs to deliver a scheduling = message, and if so which iTIP
= scheduling method to = use. The values "SERVER", "CLIENT", and "NONE"
in = the top and left titles of the table refer to the "SCHEDULE-AGENT" = in the top and left titles of the table refer = to the "SCHEDULE-AGENT"
= parameter value of the "ATTENDEE" property, and the values = "<Absent>" parameter value of = the "ATTENDEE" property, and the values "<Absent>"
= and "<Removed>" are used to cover the cases where the = "ATTENDEE" and "<Removed>" are = used to cover the cases where the "ATTENDEE"
= property is not present (Old) or is being removed = (New). property is not present = (Original) or is being removed = (Modified).
= +---------------+-----------------------------------------------+ = = +---------------+-----------------------------------------------+
= | | New = | | | = Modified = |
= | ATTENDEE = +-----------+-----------+-----------+-----------+ | = +-----------+-----------+-----------+-----------+
| = | <Removed> | SERVER | CLIENT | NONE = | | | <Removed> | = SERVER | CLIENT | NONE |
| = | | (default) | | | = | | | (default) | = | |
= +=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D+ = +=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D+
| = | <Absent> | -- | REQUEST / | -- | -- = | | | <Absent> | -- | = REQUEST / | -- | -- |
= | | | | ADD | | | = | O | = | | ADD | | |
= | +-----------+-----------+-----------+-----------+-----------+ = | r = +-----------+-----------+-----------+-----------+-----------+
= | | SERVER | CANCEL | REQUEST | CANCEL | CANCEL | = | i | SERVER = | CANCEL | REQUEST | CANCEL | CANCEL |
= | O | (default) | | | = | | | g | (default) | | | | |
| i = +-----------+-----------+-----------+-----------+-----------+
| n | CLIENT | -- | REQUEST / | -- | = -- |
| a | | | ADD | = | |
| = l +-----------+-----------+-----------+-----------+-----------+ = | l = +-----------+-----------+-----------+-----------+-----------+
= | d | CLIENT | -- | REQUEST / | -- = | -- |
| | | | = ADD | | |
| = +-----------+-----------+-----------+-----------+-----------+
| = | NONE | -- | REQUEST / | -- | -- | = | | NONE | -- | REQUEST / | -- = | -- |
| = | | | ADD | | | = | | | | ADD | = | |
= +---+-----------+-----------+-----------+-----------+-----------+ = = +---+-----------+-----------+-----------+-----------+-----------+
=
= The server MUST add a "SCHEDULE-STATUS" iCalendar property = parameter The server MUST add a = "SCHEDULE-STATUS" iCalendar property parameter
to = the "ATTENDEE" iCalendar property in the scheduling object = to the "ATTENDEE" iCalendar property in the = scheduling object
= resource being modified, and set its value as described in = resource being modified, and set its value as = described in
= Section 3.2.9. This will result in the created calendar object = Section 3.2.9. This will result in the created = calendar object
= resource differing from the calendar data sent in the HTTP = request. resource differing from the = calendar data sent in the HTTP request.
As = a result clients MAY reload the calendar data from the server in = As a result clients MAY reload the calendar = data from the server in
= order to update to the new server generated state information. = order to update to the new server generated = state information.
= Restrictions:
1. The server MAY reject any = attempt to set the "PARTSTAT" iCalendar
property parameter value of = the "ATTENDEE" iCalendar property of
other users in the calendar = object resource to a value other than
"NEEDS-ACTION" if the = "SCHEDULE-AGENT" property parameter value
is not present or set to the = value "SERVER".
2. The server MUST take into = account scheduling privileges as
described in Section 6 when = handling the modification of a
scheduling object = resource.
3. Restrictions on calendar = object resources defined in Section 4.1
of [RFC4791] MUST also be = enforced.
= =
= The server MUST return an error with the CALDAV:allowed-organizer- = The server MUST return an error with the = CALDAV:allowed-organizer-
= scheduling-object-change precondition code (Section 3.2.4.3) when = the scheduling-object-change = precondition code (Section 3.2.4.3) when the
= Organizer attempts to change the iCalendar data in a manner that = is Organizer attempts to change the = iCalendar data in a manner that is
= forbidden. forbidden.
3.2.1.3. Remove 3.2.1.3. = Remove
= When a scheduling object resource is removed by the = Organizer, the When an Organizer removes a scheduling object resource, the server
= server will inspect each "ATTENDEE" property = in the scheduling object MUST inspect each = "ATTENDEE" property to determine whether to send a
resource being removed to = determine which ones have the = "SCHEDULE- scheduling message. The table below = indicates the appropriate iTIP
AGENT" iCalendar property = parameter. method used by the server, taking into account any = "SCHEDULE-AGENT"
property parameter (see Section = 7.1) specified on each "ATTENDEE"
For each Attendee the server = will determine whether to attempt = to = property.
deliver a scheduling = message into the Attendee's scheduling = Inbox
collection, based on the = table below:
= +------------------+-------------+
| SCHEDULE-AGENT = | iTIP METHOD |
= +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D+
| SERVER (default) | = CANCEL |
= +------------------+-------------+
| CLIENT | = -- |
= +------------------+-------------+
| NONE | = -- |
= +------------------+-------------+
Restrictions: =
= 1. The server MUST take into account scheduling = privileges as = +------------------+-------------+
described in Section 6 when = handling the deletion of a scheduling | = SCHEDULE-AGENT | iTIP METHOD |
object = resource. = +------------------+-------------+
| SERVER (default) | CANCEL = |
| | = |
| CLIENT | -- = |
| | = |
| NONE | -- = |
= +------------------+-------------+
3.2.2. Attendee Scheduling Object Resources = 3.2.2. Attendee Scheduling Object = Resources
An = Attendee can create, modify or remove a scheduling object An Attendee can create, modify or remove a scheduling = object
= resource. These operations are each described next, and how they = are resource. These operations are = each described next, and how they are
= invoked via HTTP requests is described in Section 3.2.3. invoked via HTTP requests is described in Section = 3.2.3.
3.2.2.1. Allowed Attendee Changes 3.2.2.1. Allowed Attendee Changes
= Attendees are allowed to make some changes to a scheduling object = Attendees are allowed to make some changes to a = scheduling object
skipping to change at page 24, line 30 = skipping to change at = page 23, line 7
3.2.3. HTTP Methods 3.2.3. HTTP Methods
= This section describes how use of various HTTP methods on a = This section describes how use of various HTTP = methods on a
= scheduling object resource will cause a create, modify or remove = scheduling object resource will cause a create, = modify or remove
= operation on that resource as described above. The use of these = operation on that resource as described above. = The use of these
= methods is subject to the restrictions in [RFC4791], in addition = to methods is subject to the = restrictions in [RFC4791], in addition to
= what is described below. what is = described below.
3.2.3.1. PUT 3.2.3.1. = PUT
= When a PUT method request is received, the server = will execute the When the server receives a PUT method request it MUST = execute the
= following operations, provided all appropriate preconditions are = met: following operations, provided = all appropriate preconditions are met:
= +------------------------+--------------------------+---------------+ = +------------------------+--------------------------+---------------+
| = Existing Destination | Resulting Destination | Server = | | Existing Destination | Resulting = Destination | Server |
| = Resource | Resource | Operation = | | Resource | Resource = | Operation |
= +------------------------+--------------------------+---------------+ = +------------------------+--------------------------+---------------+
| = None | Calendar object resource | None = | | None | Calendar = object resource | None |
| = | | | = | | = | |
| = None | Scheduling object | Create = | | None | = Scheduling object | Create |
| = | resource | | = | | resource = | |
skipping to change at page 25, line 8 = skipping to change at = page 23, line 32
| = Calendar object | Scheduling object | Create = | | Calendar object | = Scheduling object | Create |
| = resource | resource | = | | resource | resource = | |
| = | | | = | | = | |
| = Scheduling object | Calendar object resource | Remove = | | Scheduling object | Calendar = object resource | Remove |
| = resource | | = | | resource | = | |
| = | | | = | | = | |
| = Scheduling object | Scheduling object | Modify = | | Scheduling object | = Scheduling object | Modify |
| = resource | resource | = | | resource | resource = | |
= +------------------------+--------------------------+---------------+ = +------------------------+--------------------------+---------------+
3.2.3.2. COPY = 3.2.3.2. DELETE
= When a COPY method request is received, the server will execute the When the server receives = a DELETE method request targeted at a
scheduling object resource it MUST execute the Remove = operation.
When the server receives a DELETE method request = targeted at a
calendar collection it MUST execute the Remove = operation on all
scheduling object resources contained in the calendar = collection.
3.2.3.3. COPY
When the server receives = a COPY method request it MUST execute the
= following operations based on the source and destination = collections following operations based = on the source and destination collections
in = the request: in the request:
= +-----------------------+------------------------+------------------+ = +-----------------------+------------------------+------------------+
| = Source Collection | Destination Collection | Server Operation = | | Source Collection | = Destination Collection | Server Operation |
= +-----------------------+------------------------+------------------+ = +-----------------------+------------------------+------------------+
| = Non-calendar | Non-calendar | None = | | Non-calendar | = Non-calendar | None |
| = collection | collection | = | | collection | collection = | |
| = | | | = | | = | |
| = Non-calendar | Calendar collection | (1) = | | Non-calendar | Calendar = collection | (1) |
| = collection | | = | | collection | = | |
| = | | | = | | = | |
| = Calendar collection | Non-calendar | None = | | Calendar collection | = Non-calendar | None |
| = | collection | | = | | collection = | |
| = | | | = | | = | |
| = Calendar collection | Calendar collection | (2) = | | Calendar collection | Calendar = collection | (2) |
= +-----------------------+------------------------+------------------+ = +-----------------------+------------------------+------------------+
= Note 1. The same rules as used for PUT above are applied for the = Note 1. The rules in = Section 3.2.3.1 are applied for the destination
= destination of the COPY request. of = the COPY request.
= Note 2. The server MAY reject this as per Section 3.2.4.1, = otherwise Note 2. The server MAY = reject this as per Section 3.2.4.1, otherwise
= None. None.
= The behavior of a COPY method request on a calendar collection is = The behavior of a COPY method request on a = calendar collection is
= undefined. undefined.
3.2.3.3. MOVE = 3.2.3.4. = MOVE
= When a MOVE method request is received, the server = will execute the When the server receives a MOVE method request it MUST = execute the
= following operations based on the source and destination = collections following operations based = on the source and destination collections
in = the request: in the request:
= +-----------------------+------------------------+------------------+ = +-----------------------+------------------------+------------------+
| = Source Collection | Destination Collection | Server Operation = | | Source Collection | = Destination Collection | Server Operation |
= +-----------------------+------------------------+------------------+ = +-----------------------+------------------------+------------------+
| = Non-calendar | Non-calendar | None = | | Non-calendar | = Non-calendar | None |
| = collection | collection | = | | collection | collection = | |
| = | | | = | | = | |
| = Non-calendar | Calendar collection | (1) = | | Non-calendar | Calendar = collection | (1) |
| = collection | | = | | collection | = | |
| = | | | = | | = | |
| = Calendar collection | Non-calendar | (2) = | | Calendar collection | = Non-calendar | (2) |
| = | collection | | = | | collection = | |
| = | | | = | | = | |
| = Calendar collection | Calendar collection | None = | | Calendar collection | Calendar = collection | None |
= +-----------------------+------------------------+------------------+ = +-----------------------+------------------------+------------------+
= Note 1. The same rules as used for PUT above are applied for the = Note 1. The rules in = Section 3.2.3.1 are applied for the destination
= destination of the MOVE request. of = the MOVE request.
= Note 2. The same rules as used for DELETE below are applied for = the Note 2. The rules in Section 3.2.3.2 are applied for the source = of
= source of the MOVE request. the MOVE = request.
= The behavior of a MOVE method request on a calendar collection is = The behavior of a MOVE method request on a = calendar collection is
= undefined. undefined.
3.2.3.4. DELETE =
When a DELETE method is targeted = at a scheduling object resource the
server will execute the Remove = operation.
When a DELETE method is targeted = at a calendar collection the server
will execute the Remove = operation on all scheduling object resources
contained in the calendar = collection.
= =
3.2.4. Additional Method Preconditions 3.2.4. Additional Method Preconditions
= This specification defines method preconditions (see Section 16 of = This specification defines method preconditions = (see Section 16 of
= WebDAV [RFC4918]), in addition to the ones in [RFC4791], to = provide WebDAV [RFC4918]), in addition = to the ones in [RFC4791], to provide
= machine-parseable information in error responses. machine-parseable information in error = responses.
3.2.4.1. CALDAV:unique-scheduling-object-resource = Precondition 3.2.4.1. = CALDAV:unique-scheduling-object-resource Precondition
= Name: unique-scheduling-object-resource = Name: unique-scheduling-object-resource
skipping to change at page 27, line 17 = skipping to change at = page 25, line 36
= Purpose: (precondition) -- Servers MAY reject requests to create = a Purpose: (precondition) -- Servers = MAY reject requests to create a
= scheduling object resource with an iCalendar "UID" property value = scheduling object resource with an iCalendar = "UID" property value
= already in use by another scheduling object resource owned by the = already in use by another scheduling object = resource owned by the
= same user in other calendar collections. Servers SHOULD report = same user in other calendar collections. = Servers SHOULD report
= the URL of the scheduling object resource that is already making = the URL of the scheduling object resource = that is already making
= use of the same "UID" property value in the DAV:href element. = use of the same "UID" property value in the = DAV:href element.
= Definition: Definition:
= <!ELEMENT = unique-scheduling-object-resource (DAV:href?)> <!ELEMENT unique-scheduling-object-resource = (DAV:href?)>
= Example: Example:
= <C:unique-scheduling-object-resource xmlns:D=3D"DAV:" = <C:unique-scheduling-object-resource = xmlns:D=3D"DAV:"
= xmlns:C=3D"urn:ietf:params:xml:ns:caldav"> = xmlns:C=3D"urn:ietf:params:xml:ns:caldav">
= = <D:href>/home/bernard/calendars/personal/abc123.ics</D:href> = <D:href>/home/bernard/calendars/personal/abc123.ics</D:href>
= </C:unique-scheduling-object-resource> </C:unique-scheduling-object-resource>
3.2.4.2. CALDAV:same-organizer-in-all-components = Precondition 3.2.4.2. = CALDAV:same-organizer-in-all-components Precondition
= Name: same-organizer-in-all-components = Name: same-organizer-in-all-components
= Namespace: urn:ietf:params:xml:ns:caldav Namespace: urn:ietf:params:xml:ns:caldav
=
= Apply to: PUT, COPY, and MOVE Apply = to: PUT, COPY, and MOVE
= Use with: 403 Forbidden Use with: = 403 Forbidden
= Purpose: (precondition) -- All the calendar components in a = Purpose: (precondition) -- All the calendar = components in a
= scheduling object resource MUST contain the same "ORGANIZER" = scheduling object resource MUST contain the = same "ORGANIZER"
= property value when present. = property value when present.
= Definition: Definition:
skipping to change at page 27, line 42 = skipping to change at = page 26, line 14
= Apply to: PUT, COPY, and MOVE Apply = to: PUT, COPY, and MOVE
= Use with: 403 Forbidden Use with: = 403 Forbidden
= Purpose: (precondition) -- All the calendar components in a = Purpose: (precondition) -- All the calendar = components in a
= scheduling object resource MUST contain the same "ORGANIZER" = scheduling object resource MUST contain the = same "ORGANIZER"
= property value when present. = property value when present.
= Definition: Definition:
= <!ELEMENT = same-organizer-in-all-components EMPTY> <!ELEMENT same-organizer-in-all-components = EMPTY>
3.2.4.3. CALDAV:allowed-organizer-scheduling-object-change = Precondition 3.2.4.3. = CALDAV:allowed-organizer-scheduling-object-change Precondition
= Name: allowed-organizer-scheduling-object-change Name: = allowed-organizer-scheduling-object-change
= Namespace: urn:ietf:params:xml:ns:caldav Namespace: urn:ietf:params:xml:ns:caldav
=
= Apply to: PUT, COPY, and MOVE Apply = to: PUT, COPY, and MOVE
= Use with: 403 Forbidden Use with: = 403 Forbidden
= Purpose: (precondition) -- Servers MAY impose restrictions on = Purpose: (precondition) -- Servers MAY impose = restrictions on
= modifications allowed by an Organizer. For instance, servers MAY = modifications allowed by an Organizer. For = instance, servers MAY
= prevent the Organizer setting the "PARTSTAT" property parameter to = prevent the Organizer setting the "PARTSTAT" = property parameter to
= a value other than "NEEDS-ACTION" if the corresponding "ATTENDEE" = a value other than "NEEDS-ACTION" if the = corresponding "ATTENDEE"
= property has the "SCHEDULE-AGENT" property parameter set to = property has the "SCHEDULE-AGENT" property = parameter set to
= "SERVER", or has no "SCHEDULE-AGENT" property parameter. See = "SERVER", or has no "SCHEDULE-AGENT" = property parameter. See
skipping to change at page 28, line 18 = skipping to change at = page 26, line 36
= Purpose: (precondition) -- Servers MAY impose restrictions on = Purpose: (precondition) -- Servers MAY impose = restrictions on
= modifications allowed by an Organizer. For instance, servers MAY = modifications allowed by an Organizer. For = instance, servers MAY
= prevent the Organizer setting the "PARTSTAT" property parameter to = prevent the Organizer setting the "PARTSTAT" = property parameter to
= a value other than "NEEDS-ACTION" if the corresponding "ATTENDEE" = a value other than "NEEDS-ACTION" if the = corresponding "ATTENDEE"
= property has the "SCHEDULE-AGENT" property parameter set to = property has the "SCHEDULE-AGENT" property = parameter set to
= "SERVER", or has no "SCHEDULE-AGENT" property parameter. See = "SERVER", or has no "SCHEDULE-AGENT" = property parameter. See
= Section 3.2.1. Section = 3.2.1.
= Definition: Definition:
= <!ELEMENT = allowed-organizer-scheduling-object-change EMPTY> <!ELEMENT = allowed-organizer-scheduling-object-change EMPTY>
3.2.4.4. CALDAV:allowed-attendee-scheduling-object-change = Precondition 3.2.4.4. = CALDAV:allowed-attendee-scheduling-object-change Precondition
= Name: allowed-attendee-scheduling-object-change Name: allowed-attendee-scheduling-object-change
= Namespace: urn:ietf:params:xml:ns:caldav Namespace: urn:ietf:params:xml:ns:caldav
= Apply to: PUT, COPY, and MOVE Apply = to: PUT, COPY, and MOVE
= Use with: 403 Forbidden Use with: = 403 Forbidden
= Purpose: (precondition) -- Servers MAY impose restrictions on = Purpose: (precondition) -- Servers MAY impose = restrictions on
= modifications allowed by an Attendee. Attendee modifications that = modifications allowed by an Attendee. = Attendee modifications that
= servers MUST allow are specified in Section 3.2.2.1. servers MUST allow are specified in Section = 3.2.2.1.
= Definition: Definition:
= <!ELEMENT = allowed-attendee-scheduling-object-change EMPTY> <!ELEMENT = allowed-attendee-scheduling-object-change EMPTY>
3.2.5. DTSTAMP and SEQUENCE Properties 3.2.5. DTSTAMP and SEQUENCE Properties
= The server MUST ensure that a "DTSTAMP" iCalendar property is = present The server MUST ensure that a = "DTSTAMP" iCalendar property is present
= and set the value to the UTC time that the scheduling message was = and set the value to the UTC time that the = scheduling message was
= generated (as required by iCalendar). = generated (as required by iCalendar).
= The server MUST ensure that for each type of scheduling operation, = The server MUST ensure that for each type of = scheduling operation,
= the "SEQUENCE" iCalendar property value is updated as per iTIP = the "SEQUENCE" iCalendar property value is = updated as per iTIP
= [RFC5546]. [RFC5546].
skipping to change at page 29, line 28 = skipping to change at = page 27, line 47
of = a recurring event. In that case the organizer scheduling object = of a recurring event. In that case the = organizer scheduling object
= resource will include an overridden instance with an "ATTENDEE" = list resource will include an = overridden instance with an "ATTENDEE" list
= that does not include the Attendee being excluded. Any scheduling = that does not include the Attendee being = excluded. Any scheduling
= messages delivered to the Attendee will not specify the overridden = messages delivered to the Attendee will not = specify the overridden
= instance but rather include an "EXDATE" property in the "master" = instance but rather include an "EXDATE" = property in the "master"
= component that defines the recurrence set. component that defines the recurrence set.
3.2.7. Forcing the Server to Send a Scheduling = Message 3.2.7. Forcing the Server to = Send a Scheduling Message
= The iCalendar property parameter "SCHEDULE-FORCE-SEND" defined in = The iCalendar property parameter = "SCHEDULE-FORCE-SEND" defined in
= Section 7.2 can be used by a Calendar User to = force the server to Section 7.2 can = be used by a calendar user to force the = server to
= send a scheduling message to an Attendee or the Organizer in a = send a scheduling message to an Attendee or the = Organizer in a
= situation where the server would not normally send a scheduling = situation where the server would not normally = send a scheduling
= message. For instance, an Organizer could use this property = message. For instance, an Organizer could use = this property
= parameter to request an Attendee, that previously declined an = parameter to request an Attendee, that = previously declined an
= invitation, to reconsider their participation status without being = invitation, to reconsider their participation = status without being
= forced to modify the event. forced to = modify the event.
3.2.8. Attendee Participation Status 3.2.8. Attendee Participation Status
= This section specifies additional requirements on the handling of = the This section specifies additional = requirements on the handling of the
skipping to change at page 32, line 18 = skipping to change at = page 31, line 4
| = | | = | | = |
| = | | = | | = |
| = | | = | | = |
| = 5.1 | The scheduling message was not delivered because the = | | 5.1 | The scheduling message = was not delivered because the |
| = | server could not complete delivery of the message. | = | | server could not complete delivery = of the message. |
| = | This is likely due to a temporary failure, and the | = | | This is likely due to a temporary = failure, and the |
| = | originator can try to send the message again at a | = | | originator can try to send the = message again at a |
| = | later time. | = | | later time. = |
| = | | = | | = |
| = | | = | | = |
| | = |
| = 5.2 | The scheduling message was not delivered because the = | | 5.2 | The scheduling message = was not delivered because the |
| = | server was not able to find a way to deliver the | = | | server was not able to find a way = to deliver the |
| = | message. This is likely a permanent failure, and the | = | | message. This is likely a = permanent failure, and the |
| = | originator ought not try to send the message again, at | = | | originator ought not try to send = the message again, at |
| = | least without verifying/correcting the calendar user | = | | least without verifying/correcting = the calendar user |
| = | address of the recipient. | = | | address of the recipient. = |
| = | | = | | = |
| = | | = | | = |
| = | | = | | = |
| = 5.3 | The scheduling message was not delivered and was = | | 5.3 | The scheduling message = was not delivered and was |
skipping to change at page 35, line 28 = skipping to change at = page 34, line 11
= status of Attendee "A", the CALDAV:schedule-tag property of = status of Attendee "A", the = CALDAV:schedule-tag property of
= Attendee "B"s scheduling object resource would remain the = Attendee "B"s scheduling object resource = would remain the
= same. same.
= 3. The server MUST change the CALDAV:schedule-tag property value = 3. The server MUST change the = CALDAV:schedule-tag property value
= when the scheduling object resource is changed directly via an = when the scheduling object resource is = changed directly via an
= HTTP request (e.g., PUT, COPY or MOVE). HTTP request (e.g., PUT, COPY or MOVE).
3.2.10.1. PUT 3.2.10.1. = PUT
= Clients can use the If-Schedule-Tag-Match = request header to do a PUT Clients = MAY use the If-Schedule-Tag-Match request = header to do a PUT
= request that ensures that "inconsequential" changes on the server = do request that ensures that = "inconsequential" changes on the server do
= not result in a precondition error. The value of the request = header not result in a precondition = error. The value of the request header
is = set to the last Schedule-Tag value received for the resource being = is set to the last Schedule-Tag value received = for the resource being
= modified. If the value of the If-Schedule-Tag-Match header = matches modified. If the value of the = If-Schedule-Tag-Match header matches
= the current value of the CALDAV:schedule-tag property the server = MUST the current value of the = CALDAV:schedule-tag property the server MUST
= take any "ATTENDEE" property changes for all Attendees other than = the take any "ATTENDEE" property = changes for all Attendees other than the
= owner of the scheduling object resource and apply those to the new = owner of the scheduling object resource and = apply those to the new
= resource being stored. Otherwise, the server MUST fail the = request resource being stored. = Otherwise, the server MUST fail the request
= with a 412 Precondition Failed status code. with a 412 Precondition Failed status code.
3.2.10.2. DELETE, COPY or MOVE 3.2.10.2. DELETE, COPY or MOVE
= Clients can use the If-Schedule-Tag-Match = request header to do a Clients MAY use the If-Schedule-Tag-Match request header to = do a
= DELETE, COPY or MOVE request that ensures that "inconsequential" = DELETE, COPY or MOVE request that ensures that = "inconsequential"
= changes on the server do not result in a precondition error. The = changes on the server do not result in a = precondition error. The
= value of the request header is set to the last Schedule-Tag value = value of the request header is set to the last = Schedule-Tag value
= received for the resource being deleted. If the value of the If- = received for the resource being deleted. If = the value of the If-
= Schedule-Tag-Match header matches the current value of the CALDAV: = Schedule-Tag-Match header matches the current = value of the CALDAV:
= schedule-tag property the server performs the normal DELETE, COPY = or schedule-tag property the server = performs the normal DELETE, COPY or
= MOVE request processing for the resource. Otherwise, the server = MUST MOVE request processing for the = resource. Otherwise, the server MUST
= fail the request with a 412 Precondition Failed status code. = fail the request with a 412 Precondition Failed = status code.
4. = Processing Incoming Scheduling Messages 4. Processing Incoming Scheduling Messages
skipping to change at page 37, line 40 = skipping to change at = page 36, line 40
= replying, subject to the recurrence requirements of Section 3.2.6. = replying, subject to the recurrence = requirements of Section 3.2.6.
= The scheduling message MUST only appear in the Organizer's = scheduling The scheduling message MUST = only appear in the Organizer's scheduling
= Inbox collection once all automatic processing has been done. = Inbox collection once all automatic processing = has been done.
4.3. = Default Calendar Collection 4.3. Default = Calendar Collection
= The server is REQUIRED to process scheduling messages received for = an The server is REQUIRED to process = scheduling messages received for an
= Attendee by creating a new scheduling object resource in a = calendar Attendee by creating a new = scheduling object resource in a calendar
= collection belonging to the Attendee, when one does not already = collection belonging to the Attendee, when one = does not already
= exist. A Calendar User that is an Attendee = in a scheduling operation exist. A = calendar user that is an Attendee in a = scheduling operation
= MUST have at least one valid calendar collection available. If = there MUST have at least one valid = calendar collection available. If there
is = no valid calendar collection, then the server MUST reject the = is no valid calendar collection, then the = server MUST reject the
= attempt to deliver the scheduling message to the Attendee. = attempt to deliver the scheduling message to = the Attendee.
= Servers MAY provide support for a default calendar collection, = that Servers MAY provide support for a = default calendar collection, that
= is, the calendar collection in which new scheduling object = resources is, the calendar collection = in which new scheduling object resources
= will be created. The CALDAV:schedule-default-calendar-URL WebDAV = will be created. The = CALDAV:schedule-default-calendar-URL WebDAV
= property, which can be present on the scheduling Inbox collection = of property, which can be present on = the scheduling Inbox collection of
= a Calendar User, specifies if this Calendar = User has a default a calendar user, specifies if this calendar user has = a default
= calendar collection. See Section 9.2. = calendar collection. See Section 9.2.
= Servers SHOULD create new scheduling object resources in the = default Servers SHOULD create new = scheduling object resources in the default
= calendar collection, if the CALDAV:schedule-default-calendar-URL = calendar collection, if the = CALDAV:schedule-default-calendar-URL
= WebDAV property is set. WebDAV = property is set.
= Servers MAY allow clients to change the default calendar = collection Servers MAY allow clients = to change the default calendar collection
by = changing the value of the CALDAV:schedule-default-calendar-URL = by changing the value of the = CALDAV:schedule-default-calendar-URL
= WebDAV property on the scheduling Inbox collection. However, the = WebDAV property on the scheduling Inbox = collection. However, the
= server MUST ensure that any new value for that property refers to = a server MUST ensure that any new = value for that property refers to a
skipping to change at page 38, line 41 = skipping to change at = page 37, line 41
= Use with: 403 Forbidden Use with: = 403 Forbidden
= Purpose: (precondition) -- The client attempted to delete the = Purpose: (precondition) -- The client = attempted to delete the
= calendar collection currently referenced by the CALDAV:schedule- = calendar collection currently referenced by = the CALDAV:schedule-
= default-calendar-URL property, or attempted to remove the CALDAV: = default-calendar-URL property, or attempted = to remove the CALDAV:
= schedule-default-calendar-URL property on the scheduling Inbox = schedule-default-calendar-URL property on = the scheduling Inbox
= collection on a server that doesn't allow such operations. = collection on a server that doesn't allow = such operations.
= Definition: Definition:
= <!ELEMENT default-calendar-needed = EMPTY> <!ELEMENT = default-calendar-needed EMPTY>
4.3.1.2. CALDAV:valid-schedule-default-calendar-URL = Precondition 4.3.1.2. = CALDAV:valid-schedule-default-calendar-URL Precondition
= Name: valid-schedule-default-calendar-URL Name: valid-schedule-default-calendar-URL
= Namespace: urn:ietf:params:xml:ns:caldav Namespace: urn:ietf:params:xml:ns:caldav
= Apply to: PROPPATCH Apply to: = PROPPATCH
= Use with: 403 Forbidden Use with: = 403 Forbidden
= Purpose: (precondition) -- The client attempted to set the = CALDAV: Purpose: (precondition) -- = The client attempted to set the CALDAV:
= schedule-default-calendar-URL property to a DAV:href element that = schedule-default-calendar-URL property to a = DAV:href element that
= doesn't reference a valid calendar collection. Note: Servers that = doesn't reference a valid calendar = collection. Note: Servers that
= do not allow clients to change the CALDAV:schedule-default- = do not allow clients to change the = CALDAV:schedule-default-
= calendar-URL property would simply return the DAV:cannot-modify- = calendar-URL property would simply return = the DAV:cannot-modify-
= protected-property precondition defined in Section 16 of WebDAV = protected-property precondition defined in = Section 16 of WebDAV
= [RFC4918]. [RFC4918].
= Definition: Definition:
= <!ELEMENT = valid-schedule-default-calendar-URL EMPTY> <!ELEMENT valid-schedule-default-calendar-URL = EMPTY>
5. = Request for Busy Time Information 5. = Request for Busy Time Information
= Busy time information of one or more Calendar = Users can be determined Busy = time information of one or more calendar = users can be determined
by = submitting a POST request targeted at the scheduling Outbox = by submitting a POST request targeted at the = scheduling Outbox
= collection of the Calendar User requesting = the information (the collection of = the calendar user requesting the information = (the
= Organizer). To accomplish this, the request body MUST contain a = Organizer). To accomplish this, the request = body MUST contain a
= "VFREEBUSY" calendar component with the "METHOD" iCalendar = property "VFREEBUSY" calendar = component with the "METHOD" iCalendar property
= set to the value "REQUEST" as specified in Section 3.3.2 of iTIP = set to the value "REQUEST" as specified in = Section 3.3.2 of iTIP
= [RFC5546]. The resource identified by the Request-URI MUST be a = [RFC5546]. The resource identified by the = Request-URI MUST be a
= resource collection of type CALDAV:schedule-outbox (Section 2.1). = resource collection of type = CALDAV:schedule-outbox (Section 2.1).
= The "ORGANIZER" property in the "VFREEBUSY" component MUST match = that The "ORGANIZER" property in the = "VFREEBUSY" component MUST match that
= of the Calendar User who "owns" the Outbox = collection. of the calendar user who "owns" the Outbox = collection.
A = response to a busy time request that indicates status for one or = A response to a busy time request that = indicates status for one or
= more Calendar Users MUST be an XML document = with a CALDAV:schedule- more calendar users MUST be an XML document with a = CALDAV:schedule-
= response XML element as its root element. This element MUST = contain response XML element as its = root element. This element MUST contain
= one CALDAV:response element for each Calendar = User, with each of one = CALDAV:response element for each calendar = user, with each of
= those containing elements that indicate which Calendar User they those containing elements that indicate which calendar user they
= correspond to, the scheduling status for that Calendar User, any correspond to, the scheduling status for that calendar user, any
= error codes and an optional description. For a successful busy = time error codes and an optional = description. For a successful busy time
= request, a CALDAV:calendar-data element is also present for each = request, a CALDAV:calendar-data element is also = present for each
= Calendar User, containing the actual busy = time information (i.e., an calendar user, containing the actual busy time = information (i.e., an
= iCalendar "VFREEBUSY" component). See Section 10.1 for the detail = on iCalendar "VFREEBUSY" component). = See Section 10.1 for the detail on
= the child elements. See Appendix B.5 for an example busy time = the child elements. See Appendix B.5 for an = example busy time
= request and response. request and = response.
5.1. = Status Codes 5.1. Status Codes
= The list below summarizes the most common status codes used for = this The list below summarizes the = most common status codes used for this
= method. However, clients should be prepared to handle other = 2/3/4/ method. However, clients = should be prepared to handle other 2/3/4/
= 5xx series status codes as well. 5xx = series status codes as well.
skipping to change at page 41, line 37 = skipping to change at = page 40, line 37
= Apply to: POST Apply to: = POST
= Use with: 400 Bad Request Use with: = 400 Bad Request
= Purpose: (precondition) -- The resource submitted in the POST = Purpose: (precondition) -- The resource = submitted in the POST
= request MUST obey all restrictions specified for the POST request = request MUST obey all restrictions specified = for the POST request
= (e.g., the scheduling message follow the restrictions of iTIP). = (e.g., the scheduling message follow the = restrictions of iTIP).
= Definition: Definition:
= <!ELEMENT valid-scheduling-message = EMPTY> <!ELEMENT = valid-scheduling-message EMPTY>
5.2.2. CALDAV:valid-organizer Precondition = 5.2.2. CALDAV:valid-organizer = Precondition
= Name: valid-organizer Name: = valid-organizer
= Namespace: urn:ietf:params:xml:ns:caldav Namespace: urn:ietf:params:xml:ns:caldav
= Apply to: POST Apply to: = POST
= Use with: 403 Forbidden Use with: = 403 Forbidden
= Purpose: (precondition) -- The Calendar User = identified by the Purpose: = (precondition) -- The calendar user = identified by the
= "ORGANIZER" property in the POST request's scheduling message MUST = "ORGANIZER" property in the POST request's = scheduling message MUST
= be the Calendar User (or one of the Calendar = Users) associated be the = calendar user (or one of the calendar users) = associated
= with the scheduling Outbox collection being targeted by the = with the scheduling Outbox collection being = targeted by the
= request; request;
= Definition: Definition:
= <!ELEMENT valid-organizer = EMPTY> <!ELEMENT = valid-organizer EMPTY>
6. = Scheduling Privileges 6. Scheduling = Privileges
= New scheduling privileges are defined in this section. All the = New scheduling privileges are defined in this = section. All the
= scheduling privileges MUST be non-abstract and MUST appear in the = scheduling privileges MUST be non-abstract and = MUST appear in the
= DAV:supported-privilege-set property of scheduling Outbox and = Inbox DAV:supported-privilege-set = property of scheduling Outbox and Inbox
= collections on which they are defined. = collections on which they are defined.
= The tables specified in Appendix A clarify which scheduling = methods The tables specified in = Appendix A clarify which scheduling methods
= (e.g., "REQUEST", "REPLY", etc.) are controlled by each scheduling = (e.g., "REQUEST", "REPLY", etc.) are controlled = by each scheduling
skipping to change at page 43, line 41 = skipping to change at = page 42, line 41
= controlled by the privileges assigned to the scheduling Inbox = controlled by the privileges assigned to the = scheduling Inbox
= collection. collection.
= The privileges defined in this section are ignored if applied to a = The privileges defined in this section are = ignored if applied to a
= resource other than a scheduling Inbox collection. resource other than a scheduling Inbox = collection.
6.1.1. CALDAV:schedule-deliver Privilege 6.1.1. CALDAV:schedule-deliver Privilege
= CALDAV:schedule-deliver is an aggregate privilege as per Section = 6.3. CALDAV:schedule-deliver is an = aggregate privilege as per Section 6.3.
= <!ELEMENT schedule-deliver EMPTY> = <!ELEMENT schedule-deliver = EMPTY>
6.1.2. CALDAV:schedule-deliver-invite Privilege = 6.1.2. CALDAV:schedule-deliver-invite = Privilege
= The CALDAV:schedule-deliver-invite privilege controls the = processing The = CALDAV:schedule-deliver-invite privilege controls the processing
= and delivery of scheduling messages coming from an Organizer. = and delivery of scheduling messages coming from = an Organizer.
= <!ELEMENT schedule-deliver-invite EMPTY> <!ELEMENT = schedule-deliver-invite EMPTY>
6.1.3. CALDAV:schedule-deliver-reply Privilege = 6.1.3. CALDAV:schedule-deliver-reply = Privilege
= The CALDAV:schedule-deliver-reply privilege controls the = processing The = CALDAV:schedule-deliver-reply privilege controls the processing
= and delivery of scheduling messages coming from an Attendee. = and delivery of scheduling messages coming from = an Attendee.
= <!ELEMENT schedule-deliver-reply EMPTY> <!ELEMENT = schedule-deliver-reply EMPTY>
6.1.4. CALDAV:schedule-query-freebusy Privilege = 6.1.4. CALDAV:schedule-query-freebusy = Privilege
= The CALDAV:schedule-query-freebusy privilege controls freebusy = The CALDAV:schedule-query-freebusy privilege = controls freebusy
= requests targeted at the owner of the scheduling Inbox collection. = requests targeted at the owner of the = scheduling Inbox collection.
= <!ELEMENT schedule-query-freebusy EMPTY> <!ELEMENT = schedule-query-freebusy EMPTY>
6.2. = Privileges on Scheduling Outbox Collections 6.2. Privileges on Scheduling Outbox Collections
= This section defines new WebDAV ACL [RFC3744] privileges that are = This section defines new WebDAV ACL [RFC3744] = privileges that are
= defined for use on scheduling Outbox collections. These = privileges defined for use on = scheduling Outbox collections. These privileges
= determine which calendar users are allowed to send scheduling = determine which calendar users are allowed to = send scheduling
= messages on behalf of the calendar user who "owns" the scheduling = messages on behalf of the calendar user who = "owns" the scheduling
= Outbox collection. This allows calendar users to choose other = Outbox collection. This allows calendar users = to choose other
= calendar users who can act on their behalf (e.g. assistants = working calendar users who can act on = their behalf (e.g. assistants working
on = behalf of their boss). on behalf of = their boss).
= The privileges defined in this section are ignored if applied to a = The privileges defined in this section are = ignored if applied to a
= resource other than a scheduling Outbox collection. resource other than a scheduling Outbox = collection.
6.2.1. CALDAV:schedule-send Privilege 6.2.1. CALDAV:schedule-send Privilege
= CALDAV:schedule-send is an aggregate privilege as per Section 6.3. = CALDAV:schedule-send is an aggregate privilege = as per Section 6.3.
= <!ELEMENT schedule-send EMPTY> = <!ELEMENT schedule-send = EMPTY>
6.2.2. CALDAV:schedule-send-invite Privilege = 6.2.2. CALDAV:schedule-send-invite = Privilege
= The CALDAV:schedule-send-invite privilege controls the sending of = The CALDAV:schedule-send-invite privilege = controls the sending of
= scheduling messages by Organizers. = scheduling messages by Organizers.
= Users granted the DAV:bind privilege on a calendar collection, or = Users granted the DAV:bind privilege on a = calendar collection, or
= DAV:write privilege on scheduling object resources, will also need = DAV:write privilege on scheduling object = resources, will also need
= the CALDAV:schedule-send-invite privilege granted on the = scheduling the = CALDAV:schedule-send-invite privilege granted on the scheduling
= Outbox collection of the owner of the calendar collection or = Outbox collection of the owner of the calendar = collection or
= scheduling object resource in order to be allowed to create, = modify scheduling object resource in = order to be allowed to create, modify
or = delete scheduling object resources in a way that will trigger the = or delete scheduling object resources in a way = that will trigger the
= CalDAV server to deliver scheduling messages to attendees. = CalDAV server to deliver scheduling messages to = attendees.
= <!ELEMENT schedule-send-invite EMPTY> <!ELEMENT = schedule-send-invite EMPTY>
6.2.3. CALDAV:schedule-send-reply Privilege = 6.2.3. CALDAV:schedule-send-reply = Privilege
= The CALDAV:schedule-send-reply privilege controls the sending of = The CALDAV:schedule-send-reply privilege = controls the sending of
= scheduling messages by Attendees. = scheduling messages by Attendees.
= Users granted the DAV:bind privilege on a calendar collection, or = Users granted the DAV:bind privilege on a = calendar collection, or
= DAV:write privilege on scheduling object resources, will also need = DAV:write privilege on scheduling object = resources, will also need
= the CALDAV:schedule-send-reply privilege granted on the scheduling = the CALDAV:schedule-send-reply privilege = granted on the scheduling
= Outbox collection of the owner of the calendar collection or = Outbox collection of the owner of the calendar = collection or
= scheduling object resource in order to be allowed to create, = modify scheduling object resource in = order to be allowed to create, modify
or = delete scheduling object resources in a way that will trigger the = or delete scheduling object resources in a way = that will trigger the
= CalDAV server to deliver scheduling message replies to the = organizer. CalDAV server to deliver = scheduling message replies to the organizer.
= <!ELEMENT schedule-send-reply EMPTY> <!ELEMENT = schedule-send-reply EMPTY>
6.2.4. CALDAV:schedule-send-freebusy Privilege = 6.2.4. CALDAV:schedule-send-freebusy = Privilege
= The CALDAV:schedule-send-freebusy privilege controls the use of = the The CALDAV:schedule-send-freebusy = privilege controls the use of the
= POST method to submit scheduling messages that specify the = scheduling POST method to submit = scheduling messages that specify the scheduling
= method "REQUEST" with a "VFREEBUSY" calendar component. method "REQUEST" with a "VFREEBUSY" calendar = component.
= <!ELEMENT schedule-send-freebusy EMPTY> <!ELEMENT = schedule-send-freebusy EMPTY>
6.3. = Aggregation of Scheduling Privileges 6.3. = Aggregation of Scheduling Privileges
= Server implementations MUST aggregate the scheduling privileges as = Server implementations MUST aggregate the = scheduling privileges as
= follows: follows:
= DAV:all MUST contain CALDAV:schedule-send and CALDAV:schedule- = DAV:all MUST contain CALDAV:schedule-send = and CALDAV:schedule-
= deliver; deliver;
= CALDAV:schedule-send MUST contain CALDAV:schedule-send-invite, = CALDAV:schedule-send MUST contain = CALDAV:schedule-send-invite,
= CALDAV:schedule-send-reply, and CALDAV:schedule-send-freebusy; = CALDAV:schedule-send-reply, and = CALDAV:schedule-send-freebusy;
= CALDAV:schedule-deliver MUST contain CALDAV:schedule-deliver- = CALDAV:schedule-deliver MUST contain = CALDAV:schedule-deliver-
= invite, CALDAV:schedule-deliver-reply, and CALDAV:schedule-query- = invite, CALDAV:schedule-deliver-reply, and = CALDAV:schedule-query-
= freebusy. freebusy.
= The following diagram illustrates how scheduling privileges are = The following diagram illustrates how = scheduling privileges are
= aggregated according to the above requirements. aggregated according to the above requirements.
= [DAV:all] (aggregate) [DAV:all] = (aggregate)
= | |
= +-- [CALDAV:schedule-deliver] (aggregate) +-- [CALDAV:schedule-deliver] (aggregate)
= | | | = |
= | +-- [CALDAV:schedule-deliver-invite] | +-- [CALDAV:schedule-deliver-invite]
= | +-- [CALDAV:schedule-deliver-reply] | +-- [CALDAV:schedule-deliver-reply]
= | +-- [CALDAV:schedule-query-freebusy] | +-- [CALDAV:schedule-query-freebusy]
= | |
= +-- [CALDAV:schedule-send] (aggregate) +-- [CALDAV:schedule-send] (aggregate)
= | = |
= +-- [CALDAV:schedule-send-invite] +-- [CALDAV:schedule-send-invite]
= +-- [CALDAV:schedule-send-reply] +-- [CALDAV:schedule-send-reply]
= +-- [CALDAV:schedule-send-freebusy] +-- [CALDAV:schedule-send-freebusy]
7. = Additional iCalendar Property Parameters 7. Additional iCalendar Property Parameters
= This specification defines additional iCalendar property = parameters This specification defines = additional iCalendar property parameters
to = support the CalDAV scheduling extensions. to support the CalDAV scheduling extensions.
7.1. = Schedule Agent Parameter 7.1. Schedule = Agent Parameter
= Parameter Name: SCHEDULE-AGENT = Parameter Name: SCHEDULE-AGENT
= Purpose: To specify the agent expected to deliver scheduling = Purpose: To specify the agent expected to = deliver scheduling
= messages to the corresponding Organizer or Attendee. messages to the corresponding Organizer or = Attendee.
= Format Definition: This property parameter is defined by the = Format Definition: This property parameter is = defined by the
= following notation: following = notation:
= scheduleagentparam =3D "SCHEDULE-AGENT" "=3D" scheduleagentparam =3D "SCHEDULE-AGENT" "=3D"
= ("SERVER" ; The server handles scheduling = ("SERVER" ; The server = handles scheduling
= / "CLIENT" ; The client handles scheduling = / "CLIENT" ; The client = handles scheduling
= / "NONE" ; No scheduling / "NONE" ; No = scheduling
= / x-name ; Experimental type / x-name ; Experimental = type
= / iana-token) ; Other IANA registered type = / iana-token) ; Other IANA = registered type
= ; = ;
= ; Default is SERVER ; Default is = SERVER
= Description: This property parameter MAY be specified on = "ORGANIZER" Description: This = property parameter MAY be specified on "ORGANIZER"
= or "ATTENDEE" iCalendar properties. In the absence of this = or "ATTENDEE" iCalendar properties. In the = absence of this
= parameter, the value "SERVER" MUST be used for the default = parameter, the value "SERVER" MUST be used = for the default
= behavior. The value determines whether or not a scheduling = behavior. The value determines whether or = not a scheduling
= operation on a server will cause a scheduling message to be sent = operation on a server will cause a = scheduling message to be sent
= to the corresponding Calendar User = identified by the "ORGANIZER" to = the corresponding calendar user identified by = the "ORGANIZER"
= or "ATTENDEE" property value. When the value "SERVER" is or "ATTENDEE" property value. When the value = "SERVER" is
= specified, or the parameter is absent, then it is the server's = specified, or the parameter is absent, then = it is the server's
= responsibility to send a scheduling message as part of a responsibility to send a scheduling message as part = of a
= scheduling operation. When the value "CLIENT" is specified, that = scheduling operation. When the value = "CLIENT" is specified, that
= indicates that the client is handling scheduling messages with the = indicates that the client is handling = scheduling messages with the
= Calendar User itself. When "NONE" is = specified, no scheduling calendar user itself. When "NONE" is specified, no = scheduling
= messages are being sent to the Calendar = User. messages are being = sent to the calendar user.
= Servers MUST NOT include this parameter in any scheduling messages = Servers MUST NOT include this parameter in = any scheduling messages
= sent as the result of a scheduling operation. sent as the result of a scheduling operation.
= Clients MUST NOT include this parameter in any scheduling messages = Clients MUST NOT include this parameter in = any scheduling messages
= that they themselves send. that = they themselves send.
= The parameter value MUST be the same on every "ORGANIZER" property = The parameter value MUST be the same on = every "ORGANIZER" property
= in a scheduling object resource. in = a scheduling object resource.
= The parameter value MUST be the same on each "ATTENDEE" property = The parameter value MUST be the same on each = "ATTENDEE" property
= whose values match in a scheduling object resource. whose values match in a scheduling object = resource.
= Servers and clients MUST treat x-name and iana-token values they = Servers and clients MUST treat x-name and = iana-token values they
= do not recognize the same way as they would the "NONE" value. = do not recognize the same way as they would = the "NONE" value.
= Example: Example:
= ORGANIZER;SCHEDULE-AGENT=3DSERVER:mailto:bernard@example.com = = ORGANIZER;SCHEDULE-AGENT=3DSERVER:mailto:bernard@example.com
= = = ATTENDEE;SCHEDULE-AGENT=3DNONE:mailto:cyrus@example.com
= ATTENDEE;SCHEDULE-AGENT=3DNONE:mailto:cyrus@example.com
7.2. = Schedule Force Send Parameter 7.2. = Schedule Force Send Parameter
= Parameter Name: SCHEDULE-FORCE-SEND = Parameter Name: SCHEDULE-FORCE-SEND
= Purpose: To force a scheduling message to be sent to the Calendar = Purpose: To force a scheduling message to be sent to the calendar
User specified by the = property. = user specified by the property.
= Format Definition: This property parameter is defined by the = Format Definition: This property parameter is = defined by the
= following notation: following = notation:
= scheduleforcesendparam =3D "SCHEDULE-FORCE-SEND" "=3D" scheduleforcesendparam =3D "SCHEDULE-FORCE-SEND" = "=3D"
= ("REQUEST" ; Force a "REQUEST" = ("REQUEST" ; Force = a "REQUEST"
= / "REPLY" ; Force a "REPLY" / "REPLY" ; Force a = "REPLY"
= / iana-token) ; IANA registered method = / iana-token) ; IANA = registered method
= Description: This property parameter MAY be specified on = "ATTENDEE" Description: This property = parameter MAY be specified on "ATTENDEE"
= and "ORGANIZER" properties on which the "SCHEDULE-AGENT" property = and "ORGANIZER" properties on which the = "SCHEDULE-AGENT" property
= parameter is set to the value "SERVER" or is not specified. This = parameter is set to the value "SERVER" or is = not specified. This
= property parameter is used to force a server to send a scheduling = property parameter is used to force a server = to send a scheduling
= message to a specific Calendar User in = situations where the server = message to a specific calendar user in = situations where the server
= would not send a scheduling message otherwise (e.g., when no = would not send a scheduling message = otherwise (e.g., when no
= change that warrants the delivery of a new scheduling message was = change that warrants the delivery of a new = scheduling message was
= performed on the scheduling object resource). An Organizer MAY = performed on the scheduling object = resource). An Organizer MAY
= specify this parameter on an "ATTENDEE" property with the value = specify this parameter on an "ATTENDEE" = property with the value
= "REQUEST" to force a "REQUEST" scheduling message to be sent to = "REQUEST" to force a "REQUEST" scheduling = message to be sent to
= this Attendee. An Attendee MAY specify this parameter on the = this Attendee. An Attendee MAY specify this = parameter on the
= "ORGANIZER" with the value "REPLY" to force a "REPLY" scheduling = "ORGANIZER" with the value "REPLY" to force = a "REPLY" scheduling
= message to be sent to the Organizer. = message to be sent to the Organizer.
= Servers MUST NOT preserve this property parameter in scheduling = Servers MUST NOT preserve this property = parameter in scheduling
skipping to change at page 49, line 16 = skipping to change at = page 48, line 13
= that they themselves send. that = they themselves send.
= Servers MUST set the "SCHEDULE-STATUS" parameter of the "ATTENDEE" = Servers MUST set the "SCHEDULE-STATUS" = parameter of the "ATTENDEE"
= or "ORGANIZER" to 2.3 (i.e., "Success, invalid property parameter = or "ORGANIZER" to 2.3 (i.e., "Success, = invalid property parameter
= ignored", see Section 3.6 of [RFC5546]) when the "SCHEDULE-FORCE- = ignored", see Section 3.6 of [RFC5546]) when = the "SCHEDULE-FORCE-
= SEND" parameter is set to a x-name or iana-token value they do not = SEND" parameter is set to a x-name or = iana-token value they do not
= recognize. recognize.
= Example: Example:
= ATTENDEE;SCHEDULE-FORCE-SEND=3DREQUEST:mailto:bernard@examp= le.com = ORGANIZER;SCHEDULE-FORCE-SEND=3DREPLY:mailto:cyrus@example.com
= = ATTENDEE;SCHEDULE-FORCE-SEND=3DREQUEST:mailto:bernard@examp= le.com
= ORGANIZER;SCHEDULE-FORCE-SEND=3DREPLY:mailto:cyrus@example.com =
7.3. = Schedule Status Parameter 7.3. Schedule = Status Parameter
= Parameter Name: SCHEDULE-STATUS = Parameter Name: SCHEDULE-STATUS
= Purpose: To specify the status codes returned from processing of = the Purpose: To specify the status = codes returned from processing of the
= most recent scheduling message sent to the corresponding Attendee, = most recent scheduling message sent to the = corresponding Attendee,
= or received from the corresponding Organizer. or received from the corresponding Organizer.
= Format Definition: This property parameter is defined by the = Format Definition: This property parameter is = defined by the
= following notation: following = notation:
= schedulestatusparam =3D "SCHEDULE-STATUS" "=3D" schedulestatusparam =3D "SCHEDULE-STATUS" = "=3D"
= ( statcode = ( statcode
= / DQUOTE statcode *("," statcode) DQUOTE) = / DQUOTE statcode *("," = statcode) DQUOTE)
= ; "statcode" is defined in Section 3.8.8.3 of ; "statcode" is defined in Section 3.8.8.3 of = [RFC5545]. Value
= ; [RFC5545]. Value is a single = ; is a single = "statcode" or a comma-separated list of "statcode"
= ; "statcode" or a comma-separated list of = "statcode" values. ; values.
= Description: This property parameter MAY be specified on the = Description: This property parameter MAY be = specified on the
= "ATTENDEE" and "ORGANIZER" properties. = "ATTENDEE" and "ORGANIZER" properties.
= Servers MUST add this property parameter to any "ATTENDEE" = Servers MUST add this property parameter to = any "ATTENDEE"
= properties corresponding to Calendar Users = who were sent a properties = corresponding to calendar users who were sent = a
= scheduling message via a scheduling operation. Clients SHOULD NOT = scheduling message via a scheduling = operation. Clients SHOULD NOT
= change or remove this parameter if it was provided by the server. = change or remove this parameter if it was = provided by the server.
= In the case where the client is handling the scheduling, the = In the case where the client is handling the = scheduling, the
= client MAY add, change or remove this parameter to indicate the = client MAY add, change or remove this = parameter to indicate the
= last scheduling message status it received. last scheduling message status it received.
= Servers MUST add this parameter to any "ORGANIZER" properties = Servers MUST add this parameter to any = "ORGANIZER" properties
= corresponding to Calendar Users who were = sent a scheduling message = corresponding to calendar users who were sent = a scheduling message
= reply by an Attendee via a scheduling operation. Clients SHOULD = reply by an Attendee via a scheduling = operation. Clients SHOULD
= NOT change or remove this parameter if it was provided by the = NOT change or remove this parameter if it = was provided by the
= server. In the case where the client is handling the scheduling, = server. In the case where the client is = handling the scheduling,
= the client MAY add, change or remove this parameter to indicate = the client MAY add, change or remove this = parameter to indicate
= the last scheduling message status it received. the last scheduling message status it = received.
= Servers MUST NOT include this parameter in any scheduling messages = Servers MUST NOT include this parameter in = any scheduling messages
= sent as the result of a scheduling operation. sent as the result of a scheduling operation.
= Clients MUST NOT include this parameter in any scheduling messages = Clients MUST NOT include this parameter in = any scheduling messages
= that they themselves send. that = they themselves send.
= Values for this property parameter are described in Section 3.2.9. = Values for this property parameter are = described in Section 3.2.9.
= Example: Example:
= ATTENDEE;SCHEDULE-STATUS=3D"2.0":mailto:bernard@example.com = = ATTENDEE;SCHEDULE-STATUS=3D"2.0":mailto:bernard@example.com
= = = ATTENDEE;SCHEDULE-STATUS=3D"2.0,2.4":mailto:cyrus@example.com
= ATTENDEE;SCHEDULE-STATUS=3D"2.0,2.4":mailto:cyrus@example.com =
8. = Additional Message Header Fields 8. = Additional Message Header Fields
= This specification defines additional HTTP request and response = This specification defines additional HTTP = request and response
= headers for use with CalDAV. headers = for use with CalDAV.
8.1. = Schedule-Reply Request Header 8.1. = Schedule-Reply Request Header
= Schedule-Reply =3D "Schedule-Reply" ":" = ("T" | "F") Schedule-Reply =3D = "Schedule-Reply" ":" ("T" | "F")
= Example: Example:
= Schedule-Reply: F Schedule-Reply: F
= When an Attendee removes a scheduling object resource as per = When an Attendee removes a scheduling object = resource as per
= Section 3.2.2.4, and the Schedule-Reply header is not present, or = Section 3.2.2.4, and the Schedule-Reply header = is not present, or
= present and set to the value "T" (true), the server MUST send an = present and set to the value "T" (true), the = server MUST send an
= appropriate reply scheduling message with the Attendee's = "PARTSTAT" appropriate reply = scheduling message with the Attendee's "PARTSTAT"
= iCalendar property parameter value set to "DECLINED" as part of = its iCalendar property parameter value = set to "DECLINED" as part of its
= normal scheduling operation processing. = normal scheduling operation processing.
= When the Schedule-Reply header is set to the value "F" (false), = the When the Schedule-Reply header is = set to the value "F" (false), the
= server MUST NOT send a scheduling message as part of its normal = server MUST NOT send a scheduling message as = part of its normal
skipping to change at page 51, line 46 = skipping to change at = page 50, line 46
= the scheduling object resource to be removed if such a need = arises. the scheduling object resource = to be removed if such a need arises.
8.2. = Schedule-Tag Response Header 8.2. = Schedule-Tag Response Header
= The Schedule-Tag response header provides the current value of the = The Schedule-Tag response header provides the = current value of the
= CALDAV:schedule-tag property value. The behavior of this response = CALDAV:schedule-tag property value. The = behavior of this response
= header is described in Section 3.2.10. = header is described in Section 3.2.10.
= All scheduling object resources MUST support the Schedule-Tag = header. All scheduling object = resources MUST support the Schedule-Tag header.
= Schedule-Tag =3D "Schedule-Tag" ":" opaque-tag Schedule-Tag =3D "Schedule-Tag" ":" = opaque-tag
= ; "opaque-tag" is defined in Section 3.11 of [RFC2616] ; "opaque-tag" is defined in Section 3.11 of = [RFC2616]
= Example: Example:
= Schedule-Tag: "12ab34-cd56ef" = Schedule-Tag: "12ab34-cd56ef"
8.3. = If-Schedule-Tag-Match Request Header 8.3. = If-Schedule-Tag-Match Request Header
= The If-Schedule-Tag-Match request header field is used with a = method The If-Schedule-Tag-Match = request header field is used with a method
to = make it conditional. Clients can set this header to the value = to make it conditional. Clients can set this = header to the value
= returned in the Schedule-Tag response header, or the = CALDAV:schedule- returned in the = Schedule-Tag response header, or the CALDAV:schedule-
= tag property, of a scheduling object resource previously retrieved = tag property, of a scheduling object resource = previously retrieved
= from the server to avoid overwriting "consequential" changes to = the from the server to avoid = overwriting "consequential" changes to the
= scheduling object resource. scheduling = object resource.
= All scheduling object resources MUST support the If-Schedule-Tag- = All scheduling object resources MUST support = the If-Schedule-Tag-
= Match header. Match header.
= If-Schedule-Tag-Match =3D "If-Schedule-Tag-Match" ":" opaque-tag = If-Schedule-Tag-Match =3D = "If-Schedule-Tag-Match" ":" opaque-tag
= ; "opaque-tag" is defined in Section 3.11 of [RFC2616] ; "opaque-tag" is defined in Section 3.11 of = [RFC2616]
= Example: Example:
= If-Schedule-Tag-Match: = "12ab34-cd56ef" = If-Schedule-Tag-Match: "12ab34-cd56ef"
9. = Additional WebDAV Properties 9. = Additional WebDAV Properties
= This specification defines the following new WebDAV properties for = This specification defines the following new = WebDAV properties for
= use with CalDAV. use with = CalDAV.
9.1. = CALDAV:schedule-calendar-transp Property 9.1. CALDAV:schedule-calendar-transp Property
= Name: schedule-calendar-transp Name: = schedule-calendar-transp
skipping to change at page 53, line 42 = skipping to change at = page 52, line 42
= to freebusy, assuming access privileges and other iCalendar = to freebusy, assuming access privileges and = other iCalendar
= properties allow it to. When the CALDAV:transparent XML element = properties allow it to. When the = CALDAV:transparent XML element
= is used, the calendar object resources in the corresponding = is used, the calendar object resources in = the corresponding
= calendar collection MUST NOT contribute to freebusy. calendar collection MUST NOT contribute to = freebusy.
= If this property is not present on a calendar collection, then the = If this property is not present on a = calendar collection, then the
= default value CALDAV:opaque MUST be assumed. default value CALDAV:opaque MUST be assumed.
= Definition: Definition:
= <!ELEMENT schedule-calendar-transp = (opaque | transparent)> = <!ELEMENT schedule-calendar-transp (opaque | transparent)>
= <!ELEMENT opaque EMPTY> = <!ELEMENT opaque EMPTY>
= <!-- Affect busy time searches --> <!-- Affect busy time searches -->
= <!ELEMENT transparent EMPTY> = <!ELEMENT transparent EMPTY>
= <!-- Invisible to busy time searches --> <!-- Invisible to busy time searches = -->
= Example: Example:
= <C:schedule-calendar-transp = <C:schedule-calendar-transp
= xmlns:C=3D"urn:ietf:params:xml:ns:caldav"> = xmlns:C=3D"urn:ietf:params:xml:ns:caldav">
= <C:opaque/> = <C:opaque/>
= </C:schedule-calendar-transp> = </C:schedule-calendar-transp>
9.2. = CALDAV:schedule-default-calendar-URL Property 9.2. CALDAV:schedule-default-calendar-URL Property
= Name: schedule-default-calendar-URL = Name: schedule-default-calendar-URL
= Namespace: urn:ietf:params:xml:ns:caldav Namespace: urn:ietf:params:xml:ns:caldav
= Purpose: Specifies a default calendar for an Attendee where new = Purpose: Specifies a default calendar for an = Attendee where new
= scheduling object resources are created. = scheduling object resources are created.
skipping to change at page 54, line 40 = skipping to change at = page 53, line 40
= elements. When a DAV:href element is present, its value indicates = elements. When a DAV:href element is = present, its value indicates
= a URL to a calendar collection that is used as the default = a URL to a calendar collection that is used = as the default
= calendar. When no DAV:href element is present, it indicates that = calendar. When no DAV:href element is = present, it indicates that
= there is no default calendar. In the absence of this property = there is no default calendar. In the = absence of this property
= there is no default calendar. When there is no default calendar = there is no default calendar. When there is = no default calendar
= the server is free to choose the calendar in which a new the server is free to choose the calendar in which a = new
= scheduling object resource is created. See Section 4.3. scheduling object resource is created. See Section = 4.3.
= Definition: Definition:
= <!ELEMENT schedule-default-calendar-URL (DAV:href?)> = <!ELEMENT = schedule-default-calendar-URL (DAV:href?)>
= Example: Example:
= <C:schedule-default-calendar-URL xmlns:D=3D"DAV:" <C:schedule-default-calendar-URL = xmlns:D=3D"DAV:"
= xmlns:C=3D"urn:ietf:params:xml:ns:caldav"> = xmlns:C=3D"urn:ietf:params:xml:ns:caldav">
= <D:href>/home/cyrus/calendars/work/</D:href> = = <D:href>/home/cyrus/calendars/work/</D:href>
= </C:schedule-default-calendar-URL> </C:schedule-default-calendar-URL>
9.3. = CALDAV:schedule-tag Property 9.3. = CALDAV:schedule-tag Property
= Name: schedule-tag Name: = schedule-tag
= Namespace: urn:ietf:params:xml:ns:caldav Namespace: urn:ietf:params:xml:ns:caldav
= Purpose: Indicates whether a scheduling object resource has had a = Purpose: Indicates whether a scheduling object = resource has had a
= "consequential" change made to it. = "consequential" change made to it.
skipping to change at page 55, line 32 = skipping to change at = page 54, line 32
= scheduling object resource. If the source resource is not a = scheduling object resource. If the source = resource is not a
= scheduling object resource but the destination resource is, this = scheduling object resource but the = destination resource is, this
= property MUST be added to the destination resource. property MUST be added to the destination = resource.
= Description: The CALDAV:schedule-tag property MUST be defined on = all Description: The = CALDAV:schedule-tag property MUST be defined on all
= scheduling object resources. This property is described in = scheduling object resources. This property = is described in
= Section 3.2.10. Section = 3.2.10.
= Definition: Definition:
= <!ELEMENT schedule-tag = (#PCDATA)> <!ELEMENT = schedule-tag (#PCDATA)>
= Example: Example:
= <C:schedule-tag xmlns:C=3D"urn:ietf:params:xml:ns:caldav" = <C:schedule-tag = xmlns:C=3D"urn:ietf:params:xml:ns:caldav"
= >"12345-67890"</C:schedule-tag> >"12345-67890"</C:schedule-tag>
10. = XML Element Definitions 10. XML Element = Definitions
10.1. = CALDAV:schedule-response XML Element 10.1. CALDAV:schedule-response XML Element
= Name: schedule-response Name: = schedule-response
= Namespace: urn:ietf:params:xml:ns:caldav Namespace: urn:ietf:params:xml:ns:caldav
= Purpose: Contains the set of responses for a POST method request. = Purpose: Contains the set of responses for a = POST method request.
= Description: See Section 5. = Description: See Section 5.
= Definition: Definition:
= <!ELEMENT schedule-response = (response*)> <!ELEMENT = schedule-response (response*)>
10.2. = CALDAV:response XML Element 10.2. = CALDAV:response XML Element
= Name: response Name: = response
= Namespace: urn:ietf:params:xml:ns:caldav Namespace: urn:ietf:params:xml:ns:caldav
= Purpose: Contains a single response for a POST method request. = Purpose: Contains a single response for a POST = method request.
= Description: See Section 5. = Description: See Section 5.
= Definition: Definition:
= <!ELEMENT response (recipient, = <!ELEMENT response (recipient,
= request-status, = request-status,
= calendar-data?, = calendar-data?,
= DAV:error?, = DAV:error?,
= DAV:responsedescription?)> = DAV:responsedescription?)>
= <!-- CALDAV:calendar-data is defined in Section 9.6 of <!-- CALDAV:calendar-data is defined in Section = 9.6 of
= RFC 4791 and when used here uses the definition with RFC 4791 and when used here uses the definition = with
= content (#PCDATA) only --> = content (#PCDATA) only -->
10.3. = CALDAV:recipient XML Element 10.3. = CALDAV:recipient XML Element
= Name: recipient Name: = recipient
= Namespace: urn:ietf:params:xml:ns:caldav Namespace: urn:ietf:params:xml:ns:caldav
= Purpose: The calendar user address that the enclosing response for = a Purpose: The calendar user address = that the enclosing response for a
= POST method request is for. POST = method request is for.
= Description: See Section 5. = Description: See Section 5.
= Definition: Definition:
= <!ELEMENT recipient = (DAV:href)> <!ELEMENT = recipient (DAV:href)>
10.4. = CALDAV:request-status XML Element 10.4. = CALDAV:request-status XML Element
= Name: request-status Name: = request-status
= Namespace: urn:ietf:params:xml:ns:caldav Namespace: urn:ietf:params:xml:ns:caldav
= Purpose: The iTIP "REQUEST-STATUS" property value for this = response. Purpose: The iTIP = "REQUEST-STATUS" property value for this response.
= Description: See Section 5. = Description: See Section 5.
= Definition: Definition:
= <!ELEMENT request-status = (#PCDATA)> <!ELEMENT = request-status (#PCDATA)>
11. = Security Considerations 11. Security = Considerations
= The process of scheduling involves the sending and receiving of = The process of scheduling involves the sending = and receiving of
= scheduling messages. As a result, the security problems related = to scheduling messages. As a result, = the security problems related to
= messaging in general are relevant here. In particular the = messaging in general are relevant here. In = particular the
= authenticity of the scheduling messages needs to be verified. = authenticity of the scheduling messages needs = to be verified.
= Servers and clients MUST use an HTTP connection protected with TLS = as Servers and clients MUST use an = HTTP connection protected with TLS as
= defined in [RFC2818] for all scheduling operations. Clients MUST = use defined in [RFC2818] for all = scheduling operations. Clients MUST use
= the procedures detailed in Section 6 of [RFC6125] to verify the = the procedures detailed in Section 6 of = [RFC6125] to verify the
skipping to change at page 62, line 11 = skipping to change at = page 61, line 11
= Specification document(s): this specification (Section 8.3) = Specification document(s): this specification = (Section 8.3)
= Related information: none Related = information: none
12.2. = iCalendar Property Parameter Registrations 12.2. iCalendar Property Parameter Registrations
= The following iCalendar property parameters should be added to the = The following iCalendar property parameters = should be added to the
= iCalendar Property Parameter Registry defined in Section 8.3.3 of = iCalendar Property Parameter Registry defined = in Section 8.3.3 of
= [RFC5545]. [RFC5545].
= +---------------------+---------+----------------------+ +---------------------+---------+-----------------------+
= | Parameter | Status | Reference | = | Parameter | Status | = Reference |
= +---------------------+---------+----------------------+ +---------------------+---------+-----------------------+
= | SCHEDULE-AGENT | Current | RFCXXXX, Section 7.1 | | SCHEDULE-AGENT | Current | RFC XXXX, Section 7.1 |
= | | | | = | | | = |
= | SCHEDULE-STATUS | Current | RFCXXXX, Section 7.3 | | SCHEDULE-STATUS | Current | RFC XXXX, Section 7.3 |
= | | | | = | | | = |
= | SCHEDULE-FORCE-SEND | Current | RFCXXXX, Section 7.2 | | SCHEDULE-FORCE-SEND | Current | RFC XXXX, Section 7.2 |
= +---------------------+---------+----------------------+ +---------------------+---------+-----------------------+
12.3. = iCalendar REQUEST-STATUS Value Registrations 12.3. iCalendar REQUEST-STATUS Value Registrations
= The following iCalendar "REQUEST-STATUS" values should be added to = The following iCalendar "REQUEST-STATUS" values = should be added to
= the iCalendar REQUEST-STATUS Value Registry defined in Section 7.3 = of the iCalendar REQUEST-STATUS Value = Registry defined in Section 7.3 of
= [RFC5546]. [RFC5546].
= +-------------+---------+---------------------------+ = = +-------------+---------+---------------------------+
= | Status Code | Status | Reference | = | Status Code | Status | Reference = |
= +-------------+---------+---------------------------+ = = +-------------+---------+---------------------------+
skipping to change at page 66, line 24 = skipping to change at = page 65, line 24
= [W3C.REC-xml-20081126] Yergeau, F., Paoli, J., Sperberg-McQueen, = C., [W3C.REC-xml-20081126] Yergeau, = F., Paoli, J., Sperberg-McQueen, C.,
= Maler, E., and T. Bray, "Extensible Markup = Maler, E., and T. Bray, = "Extensible Markup
= Language (XML) 1.0 (Fifth Edition)", World = Language (XML) 1.0 = (Fifth Edition)", World
= Wide Web Consortium Recommendation REC-xml- = Wide Web Consortium = Recommendation REC-xml-
= 20081126, November 2008, 20081126, November 2008,
= = <http://www.w3.org/TR/2008/REC-xml-20081126>. = <http://www.w3.org/TR/2008/REC-xml-20081126>.
14.2. = Informative References 14.2. = Informative References
= [RFC3283] Mahoney, B., Babics, G., and = A. Taler, "Guide
to = Internet Calendaring", RFC 3283,
June = 2002.
= =
= [RFC6047] Melnikov, A., "iCalendar Message-Based = [RFC6047] Melnikov, A., = "iCalendar Message-Based
= Interoperability Protocol (iMIP)", RFC 6047, = Interoperability = Protocol (iMIP)", RFC 6047,
= December 2010. = December 2010.
Appendix A. Scheduling Privileges Summary Appendix A. Scheduling Privileges Summary
A.1. = Scheduling Inbox Privileges A.1. = Scheduling Inbox Privileges
= The following tables specify which scheduling privileges grant the = The following tables specify which scheduling = privileges grant the
= right to a calendar user to deliver a scheduling message to the = right to a calendar user to deliver a = scheduling message to the
= scheduling Inbox collection of another calendar user. The = scheduling Inbox collection of another calendar = user. The
= appropriate behavior depends on the calendar component type as = well appropriate behavior depends on = the calendar component type as well
as = the scheduling "METHOD" specified in the scheduling message. = as the scheduling "METHOD" specified in the = scheduling message.
= +--------------------------------+ = = +--------------------------------+
= | METHOD for VEVENT and VTODO | = | METHOD for = VEVENT and VTODO |
= +-----------------------------+---------+-------+-----+--------+ = = +-----------------------------+---------+-------+-----+--------+
= | Scheduling Inbox Privilege | REQUEST | REPLY | ADD | CANCEL | = | Scheduling Inbox Privilege | REQUEST | = REPLY | ADD | CANCEL |
= +-----------------------------+---------+-------+-----+--------+ = = +-----------------------------+---------+-------+-----+--------+
= | schedule-deliver | * | * | * | * | = | schedule-deliver | * | * = | * | * |
= | schedule-deliver-invite | * | | * | * | = | schedule-deliver-invite | * | = | * | * |
= | schedule-deliver-reply | | * | | | = | schedule-deliver-reply | | * = | | |
= | schedule-query-freebusy | | | | | = | schedule-query-freebusy | | = | | |
= +-----------------------------+---------+-------+-----+--------+ = = +-----------------------------+---------+-------+-----+--------+
= +----------------------+ = +----------------------+
= | METHOD for VFREEBUSY | | METHOD for VFREEBUSY = |
= +-----------------------------+----------------------+ = +-----------------------------+----------------------+
= | Scheduling Inbox Privilege | REQUEST | | Scheduling Inbox Privilege | REQUEST = |
= +-----------------------------+----------------------+ = +-----------------------------+----------------------+
= | schedule-deliver | * | | schedule-deliver | * = |
= | schedule-deliver-invite | | | schedule-deliver-invite | = |
= | schedule-deliver-reply | | | schedule-deliver-reply | = |
= | schedule-query-freebusy | * | | schedule-query-freebusy | * = |
= +-----------------------------+----------------------+ = +-----------------------------+----------------------+
A.2. = Scheduling Outbox Privileges A.2. = Scheduling Outbox Privileges
= The following tables specify which scheduling privileges grant the = The following tables specify which scheduling = privileges grant the
= right to a Calendar User to perform busy time = information requests right to a calendar user to perform busy time information = requests
= and to submit scheduling messages to other Calendar = Users as the and to submit = scheduling messages to other calendar users = as the
= result of a scheduling operation. The appropriate behavior = depends result of a scheduling = operation. The appropriate behavior depends
on = the calendar component type as well as the scheduling "METHOD" = on the calendar component type as well as the = scheduling "METHOD"
= specified in the scheduling message. = specified in the scheduling message.
= +--------------------------------+ = = +--------------------------------+
= | METHOD for VEVENT and VTODO | = | METHOD for = VEVENT and VTODO |
= +-----------------------------+---------+-------+-----+--------+ = = +-----------------------------+---------+-------+-----+--------+
= | Scheduling Outbox Privilege | REQUEST | REPLY | ADD | CANCEL | = | Scheduling Outbox Privilege | REQUEST | = REPLY | ADD | CANCEL |
= +-----------------------------+---------+-------+-----+--------+ = = +-----------------------------+---------+-------+-----+--------+
= | schedule-send | * | * | * | * | = | schedule-send | * | * = | * | * |
= | schedule-send-invite | * | | * | * | = | schedule-send-invite | * | = | * | * |
= | schedule-send-reply | | * | | | = | schedule-send-reply | | * = | | |
= | schedule-send-freebusy | | | | | = | schedule-send-freebusy | | = | | |
= +-----------------------------+---------+-------+-----+--------+ = = +-----------------------------+---------+-------+-----+--------+
= +----------------------+ = +----------------------+
= | METHOD for VFREEBUSY | | METHOD for VFREEBUSY = |
= +-----------------------------+----------------------+ = +-----------------------------+----------------------+
= | Scheduling Outbox Privilege | REQUEST | | Scheduling Outbox Privilege | REQUEST = |
= +-----------------------------+----------------------+ = +-----------------------------+----------------------+
= | schedule-send | * | | schedule-send | * = |
= | schedule-send-invite | | | schedule-send-invite | = |
= | schedule-send-reply | | | schedule-send-reply | = |
= | schedule-send-freebusy | * | | schedule-send-freebusy | * = |
= +-----------------------------+----------------------+ = +-----------------------------+----------------------+
Appendix B. Example Scheduling Operations Appendix B. Example Scheduling Operations
= This section describes some example scheduling operations that give = a This section describes some example = scheduling operations that give a
= general idea of how scheduling is carried out between CalDAV = clients general idea of how scheduling = is carried out between CalDAV clients
= and servers from the perspective of meeting Organizers and = Attendees. and servers from the = perspective of meeting Organizers and Attendees.
= The server is assumed to be hosted in the "example.com" domain, = and The server is assumed to be hosted = in the "example.com" domain, and
= users whose email address is at the "example.com" domain are = assumed users whose email address is = at the "example.com" domain are assumed
to = be hosted by the server. In addition, the email addresses in the = to be hosted by the server. In addition, the = email addresses in the
skipping to change at page 80, line 47 = skipping to change at = page 79, line 47
= </C:recipient> = </C:recipient>
= <C:request-status>3.7;Invalid calendar = user</C:request-status> = <C:request-status>3.7;Invalid calendar = user</C:request-status>
= </C:response> = </C:response>
= </C:schedule-response> = </C:schedule-response>
B.6. = Example: User Attempting to Invite Attendee on behalf of Organizer = B.6. Example: User Attempting to Invite Attendee = on behalf of Organizer
In = the following example, Cyrus attempts to create, on behalf of = In the following example, Cyrus attempts to = create, on behalf of
= Wilfredo, an event with Bernard specified as an Attendee. The = Wilfredo, an event with Bernard specified as an = Attendee. The
= request fails since Wilfredo didn't grant Cyrus the right to = invite request fails since Wilfredo = didn't grant Cyrus the right to invite
= other Calendar Users on his behalf. = other calendar = users on his behalf.
= >> Request << >> = Request <<
= PUT /home/wilfredo/calendars/work/def456.ics HTTP/1.1 PUT /home/wilfredo/calendars/work/def456.ics = HTTP/1.1
= Host: cal.example.com Host: = cal.example.com
= Content-Type: text/calendar; charset=3D"utf-8" Content-Type: text/calendar; charset=3D"utf-8"
= Content-Length: xxxx Content-Length: = xxxx
= If-None-Match: * If-None-Match: = *
= BEGIN:VCALENDAR = BEGIN:VCALENDAR
skipping to change at page 88, line 7 = skipping to change at = page 87, line 7
= SUMMARY:Review Internet-Draft = SUMMARY:Review Internet-Draft
= ORGANIZER;CN=3D"Cyrus Daboo":mailto:cyrus@example.com ORGANIZER;CN=3D"Cyrus = Daboo":mailto:cyrus@example.com
= ATTENDEE;CN=3D"Bernard Desruisseaux";PARTSTAT=3DDECLINED: ATTENDEE;CN=3D"Bernard = Desruisseaux";PARTSTAT=3DDECLINED:
= mailto:bernard@example.net = mailto:bernard@example.net
= REQUEST-STATUS:2.0;Success = REQUEST-STATUS:2.0;Success
= END:VEVENT END:VEVENT
= END:VCALENDAR END:VCALENDAR
Appendix C. Changes (to be removed by RFC Editor prior to = publication) Appendix C. Changes (to be = removed by RFC Editor prior to publication)
C.1. Changes in -11 C.1. Changes in -12
a. AppDir: More reworking of various sections for = clarity.
b. AppDir: Removed terminology items defined in other = specs.
c. AppDir: Now updates 5546.
d. AppDir: MAY instead of can in = 3.2.10.1/2.
e. Fixed inconsistent whitespace in = examples.
C.2. Changes in -11
a. = Major editorial changes to remove "cruft" that built up over = a. Major editorial changes to remove "cruft" = that built up over
= time, to reduce repetitive statements, and to improve clarity. = time, to reduce repetitive statements, and = to improve clarity.
b. = SecDir: Added "Preventing Denial of Service Attacks" security = b. SecDir: Added "Preventing Denial of Service = Attacks" security
= sub-section. sub-section.
c. = SecDir: Added reference to RFC6125 and clarified how clients and = c. SecDir: Added reference to RFC6125 and = clarified how clients and
= server authenticate each other. = server authenticate each other.
d. = SecDir: Added "Mitigation of iTIP Threats" security sub-section. = d. SecDir: Added "Mitigation of iTIP Threats" = security sub-section.
e. = SecDir: Added new text to privacy sub-section. e. SecDir: Added new text to privacy = sub-section.
f. = Fixed some XML examples. f. Fixed = some XML examples.
C.2. Changes in = -10 C.3. = Changes in -10
a. = Updated to RFC 6047 reference. a. = Updated to RFC 6047 reference.
b. = Various minor clarifications to behavior and terminology done. = b. Various minor clarifications to behavior = and terminology done.
c. = Clarified that Inbox/Outbox are the server's responsibility to = c. Clarified that Inbox/Outbox are the = server's responsibility to
= create. create.
d. = Changed MAY to SHOULD for server rejecting organizer PARTSTAT = d. Changed MAY to SHOULD for server rejecting = organizer PARTSTAT
= changes of attendees. changes of = attendees.
skipping to change at page 89, line 8 = skipping to change at = page 88, line 21
= incoming scheduling messages. = incoming scheduling messages.
j. = default-calendar-delete-allowed -> default-calendar-needed. = j. default-calendar-delete-allowed -> = default-calendar-needed.
k. = Clarified that SCHEDULE-AGENT must be the same on all matching = k. Clarified that SCHEDULE-AGENT must be the = same on all matching
= properties. properties.
l. = Added more text justifying the need for calendar-user-type = l. Added more text justifying the need for = calendar-user-type
= property. property.
C.3. Changes in = -09 C.4. = Changes in -09
a. = Fixed some examples. a. Fixed some = examples.
b. = Tweaked XML conventions. b. Tweaked = XML conventions.
c. = Removed description in SCHEDULE-STATUS example values. c. Removed description in SCHEDULE-STATUS example = values.
d. = Tweaked 3.7 and 3.8 SCHEDULE-STATUS description to indicate it = d. Tweaked 3.7 and 3.8 SCHEDULE-STATUS = description to indicate it
= applies to the Organizer as well as Attendee. applies to the Organizer as well as = Attendee.
skipping to change at page 90, line 5 = skipping to change at = page 89, line 20
= CALDAV:response element. = CALDAV:response element.
o. = AD Review: made reference to 5545 IANA registry procedures for = o. AD Review: made reference to 5545 IANA = registry procedures for
= the two new element registries. = the two new element registries.
p. = AD Review: Fixed description of B5. example. p. AD Review: Fixed description of B5. example.
q. = Fixed SCHEDULE-AGENT/SCHEDULE-STATUS behavior for Attendee = q. Fixed SCHEDULE-AGENT/SCHEDULE-STATUS = behavior for Attendee
= replies. replies.
C.4. Changes in = -08 C.5. = Changes in -08
a. = Added "Updates 4791". a. Added = "Updates 4791".
b. = XML conventions changed to match that in CardDAV spec. b. XML conventions changed to match that in CardDAV = spec.
c. = Reworded child response behavior for Outbox. c. Reworded child response behavior for Outbox.
d. = Reworded "octet size". d. Reworded = "octet size".
e. = If-Schedule-Match descriptions changed to remove implication that = e. If-Schedule-Match descriptions changed to = remove implication that
= it is purely a conditional operation. = it is purely a conditional operation.
f. = Schedule-Reply header descriptions generalized to resource = f. Schedule-Reply header descriptions = generalized to resource
= removal rather than just HTTP DELETE. = removal rather than just HTTP DELETE.
g. = Fixed various examples. g. Fixed = various examples.
C.5. Changes in = -07 C.6. = Changes in -07
a. = Restructured document. a. = Restructured document.
b. = Clarified that CALDAV:schedule-calendar-transp only applies to = b. Clarified that = CALDAV:schedule-calendar-transp only applies to
= calendar collection. calendar = collection.
c. = Removed CALDAV:schedule-state property on scheduling messages in = c. Removed CALDAV:schedule-state property on = scheduling messages in
= the scheduling Inbox collection. = the scheduling Inbox collection.
d. = Added conditional requests on scheduling object resources. = d. Added conditional requests on scheduling = object resources.
skipping to change at page 91, line 11 = skipping to change at = page 90, line 27
k. = Removed handling of REFRESH requests. = k. Removed handling of REFRESH requests.
l. = Removed handling of VJOURNAL components. l. Removed handling of VJOURNAL components.
m. = Completed IANA Considerations section. = m. Completed IANA Considerations section.
n. = Added references to RFC3283 and RFC5234. n. Added references to RFC3283 and RFC5234.
o. = Updated references to iCalendar, iTIP and iMIP. o. Updated references to iCalendar, iTIP and = iMIP.
C.6. Changes in = -06 C.7. = Changes in -06
a. = Removed distinction between scheduling calendar collections and = a. Removed distinction between scheduling = calendar collections and
= basic calendar collections - now just have calendar collections. = basic calendar collections - now just have = calendar collections.
b. = Clients now "MAY" reload data rather than "SHOULD" reload data. = b. Clients now "MAY" reload data rather than = "SHOULD" reload data.
c. = Fixed <C:recipient> in examples. = c. Fixed <C:recipient> in examples.
d. = Removed CALDAV:attachments-allowed precondition on POST to Outbox = d. Removed CALDAV:attachments-allowed = precondition on POST to Outbox
= as that is no longer relevant. as = that is no longer relevant.
skipping to change at page 91, line 39 = skipping to change at = page 91, line 7
= restrictions also apply. = restrictions also apply.
h. = Added comment that 'opaque' is the default when the CALDAV: = h. Added comment that 'opaque' is the default = when the CALDAV:
= schedule-calendar-transp property is not present. schedule-calendar-transp property is not = present.
i. = Description of Schedule-Reply header changed to reflect that it = i. Description of Schedule-Reply header = changed to reflect that it
= is only relevant for Attendees. = is only relevant for Attendees.
j. = Minor typos fixed. j. Minor typos = fixed.
C.7. Changes in = -05 C.8. = Changes in -05
= This draft has changed substantially since the -04 version. The = This draft has changed substantially since the = -04 version. The
= primary reason for this change was implementation experience from = a primary reason for this change was = implementation experience from a
= number of vendors who implemented products based on the earlier = number of vendors who implemented products = based on the earlier
= drafts. Experience showed that the client/server interaction was = not drafts. Experience showed that = the client/server interaction was not
= reliable in keeping scheduling messages synchronized between = reliable in keeping scheduling messages = synchronized between
= organizer and attendees. In addition the latency in updates due = to organizer and attendees. In = addition the latency in updates due to
= clients being offline proved unacceptable to users. These issues = led clients being offline proved = unacceptable to users. These issues led
to = the redesign of this specification to support a server-based = to the redesign of this specification to = support a server-based
= processing model that eliminates all the problems seen previously. = processing model that eliminates all the = problems seen previously.
 End of changes. 141 change blocks. 
508 lines changed or = deleted 448 lines changed or = added

This html = diff was produced by rfcdiff 1.39p1. The latest version is available from = http://tools.ietf.org/tools/rfcdiff/
--==========55BF0D386A64FFA03922==========-- From stpeter@stpeter.im Thu Mar 8 15:22:13 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95DBA21E8050; Thu, 8 Mar 2012 15:22:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.734 X-Spam-Level: X-Spam-Status: No, score=-102.734 tagged_above=-999 required=5 tests=[AWL=-0.135, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YNQkIjdXS-Zs; Thu, 8 Mar 2012 15:22:11 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B30F421F864E; Thu, 8 Mar 2012 15:22:09 -0800 (PST) Received: from squire.local (unknown [64.101.72.114]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A514C4005B; Thu, 8 Mar 2012 16:34:12 -0700 (MST) Message-ID: <4F593F1E.1060204@stpeter.im> Date: Thu, 08 Mar 2012 16:22:06 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: dcrocker@bbiw.net References: <1331188315.87259.YahooMailNeo@web31816.mail.mud.yahoo.com> <4F58EBFA.7010904@stpeter.im> <4F58EFBF.8030908@dcrocker.net> <4F58F39A.9030401@stpeter.im> <11FF964F9FF3063DE7F98BDB@PST.JCK.COM> <4F5919EB.1080407@stpeter.im> <609BED83E23A6939F0C9CEC8@PST.JCK.COM> <4F59291C.5000008@dcrocker.net> In-Reply-To: <4F59291C.5000008@dcrocker.net> X-Enigmail-Version: 1.3.5 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org, draft-ietf-appsawg-xdash.all@tools.ietf.org, William Mills , The IESG Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-appswg-xdash-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Mar 2012 23:22:13 -0000 On 3/8/12 2:48 PM, Dave Crocker wrote: > > On 3/8/2012 1:40 PM, Martin Thomson wrote: >> On 8 March 2012 13:06, John C Klensin wrote: >>> Given that the media types document (both current and pending >>> versions) explicitly identifies them as non-standard trees, I >>> don't think even hair-splitting makes that title correct. You >>> could say "specialized non-hierarchical..." or "specialized >>> non-faceted...". That is also hair-splitting but would at least >>> be correct. >> >> In my mind, the distinction was always experimental vs. >> non-experimental, as opposed to vendor-specific vs. standardized. I >> think that's where the document has gone astray. Different axis of >> split, methinks, even if the axes aren't entirely orthogonal. > > > X- itself has a rather long and well-documented history and purpose. > The current document has expanded scope a bit, to try to cover a class, > not merely an instance. > > The class is "names that are syntactically designed to be outside of > standards space" because such names have a regularly tendency to become > de facto standards, which makes formally standardizing them problematic. > > This is true for "experimental" names, "vendor" names, and any other > kind of non-standard name. > > The premises behind the concern are a) registration is difficult, b) the > name should flag the status. > > What the community has learned or the thirty-or-so years of the > construct is that it's better to have a single, clean name space and > leave status of the name as a separate issue. Well put. Yet the inclusion of delimiters in parameter names could be construed as just another way segregating the namespace. So I think it might be best to remove the fourth bullet point in Section 4: 4. SHOULD identify a convention to allow local or implementation- specific extensions, and reserve delimeters for such uses as needed. Peter -- Peter Saint-Andre https://stpeter.im/ From martin.thomson@gmail.com Thu Mar 8 15:40:25 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCD2A21E8058; Thu, 8 Mar 2012 15:40:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.877 X-Spam-Level: X-Spam-Status: No, score=-4.877 tagged_above=-999 required=5 tests=[AWL=-1.278, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FWc5wpGTFlIM; Thu, 8 Mar 2012 15:40:25 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id D936721E8050; Thu, 8 Mar 2012 15:40:24 -0800 (PST) Received: by bkuw5 with SMTP id w5so904073bku.31 for ; Thu, 08 Mar 2012 15:40:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=9BjNbKmwC1ZhCRyECnRxpeE5r/52Cn52mWhQZ11keHY=; b=DcmHPwQsWq7XAtnbuFzq6FRe5sy/U5XK++jeGUIpdbvhHi5gzzG1WguCBoZiL909mH /TD+zyCpRBehCX2MAv7vxEM0R4ldLH9kP5hb0o8u7zqyrlpllkjrUDccLzcdb8BmhGnI Qy3/7bJDgIfB+9letBlg5tt2w85tkoz1I2P7JeZYQfx8SnmBVUqY6ZFgZAGqic5ZwXPF U+m8lfSa9aVZRJ+QyFwRRK0FzAm8IgcfCdB3Hrq8I7tV5nAj/Vi38/8B6VK7wW3gGBb2 T6BT+6Ork/5B/ZvVbIJw7ZjS8ixhZHiHb4rGoNqchxENxCmyd5eZAjOyeMWMdzhYI/YX yHAA== MIME-Version: 1.0 Received: by 10.204.154.66 with SMTP id n2mr20156bkw.77.1331250023907; Thu, 08 Mar 2012 15:40:23 -0800 (PST) Received: by 10.204.121.208 with HTTP; Thu, 8 Mar 2012 15:40:23 -0800 (PST) In-Reply-To: <4F593F1E.1060204@stpeter.im> References: <1331188315.87259.YahooMailNeo@web31816.mail.mud.yahoo.com> <4F58EBFA.7010904@stpeter.im> <4F58EFBF.8030908@dcrocker.net> <4F58F39A.9030401@stpeter.im> <11FF964F9FF3063DE7F98BDB@PST.JCK.COM> <4F5919EB.1080407@stpeter.im> <609BED83E23A6939F0C9CEC8@PST.JCK.COM> <4F59291C.5000008@dcrocker.net> <4F593F1E.1060204@stpeter.im> Date: Thu, 8 Mar 2012 15:40:23 -0800 Message-ID: From: Martin Thomson To: Peter Saint-Andre Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org, draft-ietf-appsawg-xdash.all@tools.ietf.org, William Mills , dcrocker@bbiw.net, The IESG Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-appswg-xdash-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 08 Mar 2012 23:40:26 -0000 On 8 March 2012 15:22, Peter Saint-Andre wrote: > So I think it might be best > to remove the fourth bullet point in Section 4: > > =C2=A0 4. SHOULD identify a convention to allow local or implementation- > =C2=A0 =C2=A0 =C2=A0specific extensions, and reserve delimeters for such = uses as > =C2=A0 =C2=A0 =C2=A0needed. That's the part that confused me. SHOULD NOT also works, in line with the rest of the guidance. +1 From dhc@dcrocker.net Thu Mar 8 16:57:52 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E5B121F85C6; Thu, 8 Mar 2012 16:57:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.606 X-Spam-Level: X-Spam-Status: No, score=-6.606 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DP2nr47SPiYx; Thu, 8 Mar 2012 16:57:52 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id CC8A521F85B6; Thu, 8 Mar 2012 16:57:40 -0800 (PST) Received: from [192.168.1.11] (adsl-67-127-58-62.dsl.pltn13.pacbell.net [67.127.58.62]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q290vTvK027759 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Mar 2012 16:57:34 -0800 Message-ID: <4F59556A.8070806@dcrocker.net> Date: Thu, 08 Mar 2012 16:57:14 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Peter Saint-Andre References: <1331188315.87259.YahooMailNeo@web31816.mail.mud.yahoo.com> <4F58EBFA.7010904@stpeter.im> <4F58EFBF.8030908@dcrocker.net> <4F58F39A.9030401@stpeter.im> <11FF964F9FF3063DE7F98BDB@PST.JCK.COM> <4F5919EB.1080407@stpeter.im> <609BED83E23A6939F0C9CEC8@PST.JCK.COM> <4F59291C.5000008@dcrocker.net> <4F593F1E.1060204@stpeter.im> In-Reply-To: <4F593F1E.1060204@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Thu, 08 Mar 2012 16:57:38 -0800 (PST) Cc: apps-discuss@ietf.org, draft-ietf-appsawg-xdash.all@tools.ietf.org, William Mills , dcrocker@bbiw.net, The IESG Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-appswg-xdash-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 00:57:52 -0000 On 3/8/2012 3:22 PM, Peter Saint-Andre wrote: > On 3/8/12 2:48 PM, Dave Crocker wrote: >> What the community has learned or the thirty-or-so years of the >> construct is that it's better to have a single, clean name space and >> leave status of the name as a separate issue. > > Well put. > > Yet the inclusion of delimiters in parameter names could be construed as > just another way segregating the namespace. So I think it might be best > to remove the fourth bullet point in Section 4: > > 4. SHOULD identify a convention to allow local or implementation- > specific extensions, and reserve delimeters for such uses as > needed. I think +1 d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From walter.stanish@gmail.com Thu Mar 8 19:44:55 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF46B21E801C for ; Thu, 8 Mar 2012 19:44:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=-0.556, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_FWDLOOK=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oax6FCovVeNJ for ; Thu, 8 Mar 2012 19:44:55 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5925D21E8010 for ; Thu, 8 Mar 2012 19:44:55 -0800 (PST) Received: by obbta4 with SMTP id ta4so1748563obb.31 for ; Thu, 08 Mar 2012 19:44:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=vSg9KYmv5OVPtP4IgT57VBMYA2FAf74Cnb1D4bwpYBg=; b=pSfg/Ad6DfxyxToHME6vM8E6aPVH5/r+UZiEwCZq7KMBepKF4lBAS1RSJPZcufeOD5 5s60G1FPH5YabGxfFoQnvlMfSIT7xREPQr4ztc8wSeK6PgB1GSBW3OgeDuxw0+y7l+N4 DCuiaKfYk0aSttbgMu4nB36pQBV6YdcF5euTMHkKGdW7fX10rXQMzVKcVHtz5sxM6Bmg phhp31st++HeVZ8mUpWGM3lnsirCGwwjgIv05HKTc3t3Zr79Qua/bYJ2/4usOhSW7SWu XMFoGcZ4PXHjYy6bolhtqMIEEWHeFOevX4oqC652ukpiK1GzDcdusTNCqaSGZwSTkhEs SkVQ== MIME-Version: 1.0 Received: by 10.182.108.97 with SMTP id hj1mr282153obb.37.1331264694962; Thu, 08 Mar 2012 19:44:54 -0800 (PST) Received: by 10.60.149.225 with HTTP; Thu, 8 Mar 2012 19:44:54 -0800 (PST) In-Reply-To: <4F58D9F3.2000602@dcrocker.net> References: <4F58D9F3.2000602@dcrocker.net> Date: Fri, 9 Mar 2012 10:44:54 +0700 Message-ID: From: Walter To: dcrocker@bbiw.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Proposal for a Finance Area Mailing List X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 09 Mar 2012 03:44:56 -0000 > Stated differently, what problems are to be solved by this activity and w= ho > will work on them? =A0(Stating the former is meant to recruit statements = of > interest from the latter.) Thanks for your comments Dave, particularly the historic references your subsequent message which I will reply to shortly. I believe an approximate answer to this specific question has already been supplied - if there is any area in which you would like more detail please feel free to ask: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Certain functionality required by modern financial systems is not presently available in open, legacy-free, adequately globalized protocols. This functionality includes: * Settlement and reversal / cancellation term negotiation * Exchange rate negotiation * Latency calculation / negotiation * Fee, tax and discount calculation / negotiation * Arbitrary currency / asset support * Multi-currency / asset transaction support * Quotation support * Multiple settlement path support * Optional support for in-band settlement (sometimes known as DVP) * High precision decimal value support * Arbitrary financial settlement topology support * Arbitrary communications topology support Given this situation, it makes sense to propose a legacy-free, adequately extensible protocol for internet-based financial exchange. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> Financial industry groups are not the right forum for this development >> as they are top-heavy with a massive, indisputable interest in >> maintaining the status quo. > > You know about IANA registries but appear not to know that statements lik= e > above are counterproductive in the IETF (and most other places.) Please accept my apologies as I do not understand this comment. In requesting the support of the IETF in setting up a mailing list for the discussion and development of forward looking financial standards, the question of whether the IETF is the "best" place to do this was raised. Thus presented with the notion that established financial industry bodies (large, top-heavy, centralized organizations constrained through bureaucracy, legal concerns and multi-jurisdictional regulatory constraints as well as significant financial self-interest in the status quo) might be a better venue to discuss alternatives to the established systems used by the same, I motioned that was not the case. Would it be possible to clarify your perspective further? I believe I am missing something. To reiterate the points raised earlier, the IETF has been identified as an excellent venue for such discussion and development for the following reasons: 1. Transparency and community examination of a proven standards development process 2. Access to IANA: an established, internationally credible third party for registry management (very useful to build trust in alternate financial systems) 3. Access to supplementary services such as document distribution. Regards, Walter Stanish Payward, Inc. From johnl@iecc.com Thu Mar 8 20:32:00 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FCC521E803A for ; Thu, 8 Mar 2012 20:32:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.269 X-Spam-Level: X-Spam-Status: No, score=-110.269 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r4Eyeo3dMlBy for ; Thu, 8 Mar 2012 20:31:59 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 449EC21E801C for ; Thu, 8 Mar 2012 20:31:58 -0800 (PST) Received: (qmail 25366 invoked from network); 9 Mar 2012 04:31:57 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 9 Mar 2012 04:31:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4f5987bd.xn--yuvv84g.k1203; i=johnl@user.iecc.com; bh=WbQEW07g6yqyiwWTxvRFLUJKXT45JeuIxZDBfoWzIEY=; b=hP3kaC0Ljv4XJn5o7d9lMw2E6peSM9oopgytaOQyGbzbJKepQ8j88v/VEWUa0sx1UOolu4qjIAsmlFUlTVBtzs1ME3hgLXl9RxEh7967toX1EGJnDdKmmejZJOd+dE25qk+qX3W0vVrjTk09KhsXaYI62wSu9b+DdhWSVIiDfwU= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4f5987bd.xn--yuvv84g.k1203; olt=johnl@user.iecc.com; bh=WbQEW07g6yqyiwWTxvRFLUJKXT45JeuIxZDBfoWzIEY=; b=cM6j+CTjSaESF6LOoM9kYgRJ9lnm0ryvdy4GjgCbqakjcWk8z2rap9x1ykL44DVacw7lFcfXNFqduZDyZXcTMK7zWRCslvdIwP0iT/8kR5VCEVtW4Sc0lPbAFr1RcuK/LVX3gTP4d9PAaT0FFaETjNqUBzuEw9kz6qP9t4FTkH4= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 9 Mar 2012 04:31:35 -0000 Message-ID: <20120309043135.60337.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [apps-discuss] Proposal for a Finance Area Mailing List X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 09 Mar 2012 04:32:00 -0000 > This functionality includes: > * Settlement and reversal / cancellation term negotiation > * Exchange rate negotiation > * Latency calculation / negotiation > * Fee, tax and discount calculation / negotiation > * Arbitrary currency / asset support > * Multi-currency / asset transaction support > * Quotation support > * Multiple settlement path support > * Optional support for in-band settlement (sometimes known as DVP) > * High precision decimal value support > * Arbitrary financial settlement topology support > * Arbitrary communications topology support Sounds cool. Anyone likely to implement it? The IETF has a well known preference for running code. R's, John From john-ietf@jck.com Thu Mar 8 21:00:10 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F80E21E806F; Thu, 8 Mar 2012 21:00:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.815 X-Spam-Level: X-Spam-Status: No, score=-102.815 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G5IxeAsvJ1Iz; Thu, 8 Mar 2012 21:00:09 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 1688C21E806B; Thu, 8 Mar 2012 21:00:09 -0800 (PST) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1S5rr5-000Bch-6w; Thu, 08 Mar 2012 23:55:03 -0500 Date: Thu, 08 Mar 2012 23:59:36 -0500 From: John C Klensin To: Martin Thomson Message-ID: <8C643A1E79A861336C7025FA@PST.JCK.COM> In-Reply-To: References: <1331188315.87259.YahooMailNeo@web31816.mail.mud.yahoo.com> <4F58EBFA.7010904@stpeter.im> <4F58EFBF.8030908@dcrocker.net> <4F58F39A.9030401@stpeter.im> <11FF964F9FF3063DE7F98BDB@PST.JCK.COM> <4F5919EB.1080407@stpeter.im> <609BED83E23A6939F0C9CEC8@PST.JCK.COM> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: apps-discuss@ietf.org, draft-ietf-appsawg-xdash.all@tools.ietf.org, William Mills , The IESG , dcrocker@bbiw.net Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-appswg-xdash-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 09 Mar 2012 05:00:10 -0000 --On Thursday, March 08, 2012 13:40 -0800 Martin Thomson wrote: > On 8 March 2012 13:06, John C Klensin > wrote: >> Given that the media types document (both current and pending >> versions) explicitly identifies them as non-standard trees, I >> don't think even hair-splitting makes that title correct. >> =C2=A0You could say "specialized non-hierarchical..." or >> "specialized non-faceted...". =C2=A0That is also = hair-splitting >> but would at least be correct. >=20 > In my mind, the distinction was always experimental vs. > non-experimental, as opposed to vendor-specific vs. > standardized. I think that's where the document has gone > astray. Different axis of split, methinks, even if the axes > aren't entirely orthogonal. Yes. And that has been a problem almost since the beginning. We've talked about it as "experimental" ("extension" is, as far as I can remember, a very recent retrofit) but described how implementations are expected to respond to it very much in terms consistent with "private use", e.g., mutual agreement between consenting adults, etc. =20 We've known for a long time that the transitional issues with "experimental" make it a bad idea. That is clear from the discussion of the FTP commands starting in "X" in RFC 1123 even though 1123 didn't explicitly deprecate the idea. In that regard, this draft can be seen as saying "we've known for a really long time that using specific syntax, 'X-' or otherwise, to designate experimental features that might mature into general use and it is time to finally put a stop to it". Quibbles about SHOULDs and MUSTs notwithstanding, I think that is entirely reasonable and the right thing to do. The "private use" cases are another matter. Nothing we can do about changing registration procedures is going to get a lot of those registered. Sometimes there aren't good reasons to resist registration, but sometimes there are what appear to be good reasons and nothing that the IETF can do is going to change that. So, for the private use cases, having something that designates "unless you, the recipient, have worked out something in advance with that particular sender, you don't know what this means whether you think you recognize the string or not" may be a useful tool to keep around... more useful than hoping that someone making up a new keyword won't somehow conflict with an unregistered one that uses different semantics. john From walter.stanish@gmail.com Thu Mar 8 21:19:05 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD6F821E800F for ; Thu, 8 Mar 2012 21:19:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.823 X-Spam-Level: X-Spam-Status: No, score=-1.823 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_FWDLOOK=1.666, SARE_LWFORWARD=1.11] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zRBTnnvQbcA2 for ; Thu, 8 Mar 2012 21:19:05 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 55BBC21E800E for ; Thu, 8 Mar 2012 21:19:05 -0800 (PST) Received: by obbta4 with SMTP id ta4so1846955obb.31 for ; Thu, 08 Mar 2012 21:19:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=lS7mAsQtdbv4vHDz8wtV2Q1DF8LHwm1TsZ7ynr+xhXo=; b=mvzGe10wd32KQ+Vma4wq90IoIw97mIDU3vAE9i4D1ENK57Q6zedrymX+1hZ2W1wIxE 4WQPq9Pb1XAb8cHRpz4R6CH7kSSpuD9GqkRYSMt/+ToQP383gC0Bu6yvhOiNC+VCPYhY T5G7gGLALieqYOWGrThckyB4qiAWf9v3dEG2YuseFOsI3kNi1sTKJ8zeRq4bK5IAvGOf IBn4XHIjeTn57tJ1VzH3yRwdtfunggPpRXVIEBjp2KZ55KrzwmQQUa4vxWaxyRw2qpK4 GHIdrK68Xm8veLWhUfy7FvOnKgDq/9b4ybKGZtXECOoUiCcZBsAK5E1J0zI64e4yT7en 4Nqw== MIME-Version: 1.0 Received: by 10.60.14.36 with SMTP id m4mr353649oec.37.1331270344955; Thu, 08 Mar 2012 21:19:04 -0800 (PST) Received: by 10.60.149.225 with HTTP; Thu, 8 Mar 2012 21:19:04 -0800 (PST) In-Reply-To: <20120309043135.60337.qmail@joyce.lan> References: <20120309043135.60337.qmail@joyce.lan> Date: Fri, 9 Mar 2012 12:19:04 +0700 Message-ID: From: Walter To: John Levine Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Proposal for a Finance Area Mailing List X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 09 Mar 2012 05:19:06 -0000 >> This functionality includes: >> =A0* Settlement and reversal / cancellation term negotiation >> =A0* Exchange rate negotiation >> =A0* Latency calculation / negotiation >> =A0* Fee, tax and discount calculation / negotiation >> =A0* Arbitrary currency / asset support >> =A0* Multi-currency / asset transaction support >> =A0* Quotation support >> =A0* Multiple settlement path support >> =A0* Optional support for in-band settlement (sometimes known as DVP) >> =A0* High precision decimal value support >> =A0* Arbitrary financial settlement topology support >> =A0* Arbitrary communications topology support > > Sounds cool. Thank you for your positive comment. > =A0Anyone likely to implement it? =A0The IETF has a well known > preference for running code. (One might wonder if such conflicts with the 'come with a problem rather than a solution' philosophy of the BOFs / mailing list proposals @ http://tools.ietf.org/html/rfc5434#page-2 ? Then again, one might try to focus on avoiding bureaucratic discussion entirely...) Forward looking statements are always hard to juggle, but at present it does seem that whatever we wind up deciding upon will be implemented by Payward Inc. At least one party with worldwide presence has also expressed a significant and immediate interest - even at this very early stage - in rapid implementation. Whether we move forward independently or on a shared implementation is not yet known. Resulting code may be shared in whole or in part with the wider community as open source, depending upon commercial concerns which are not my domain and I cannot therefore comment on. Secondly, I would note that the complexity that the above feature list suggests should not be taken as a requirement for basic implementation; even integrating exhaustive specifications for all possible considerations of these features in to a document would render it a book. The philosophy to do one thing and do it well demands a minimalist approach; as per established protocols extensions for precise cases (under various legal jurisdictions, when accessing certain financial markets or networks, etc.) would presumably be described separately. Individual implementations would be free to leave out support for most or all extensions, advertise the subset that they support when handshaking, then interact appropriately. Easier said than done, but I believe an achievable goal. In closing, perhaps you could assist with teething issues faced by mere newcomers such as myself by flexing your apparent dummy series authorship credentials on a humorous RFC for April; "The IETF for Dummies"? Regards, Walter Stanish Payward, Inc. From msk@cloudmark.com Thu Mar 8 21:22:17 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 702F321E801A for ; Thu, 8 Mar 2012 21:22:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8b344ZWh82mL for ; Thu, 8 Mar 2012 21:22:17 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id C5EF821E800F for ; Thu, 8 Mar 2012 21:22:16 -0800 (PST) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by EXCH-HTCAS901.corp.cloudmark.com ([fe80::2966:6846:8d89:4681%12]) with mapi id 14.01.0355.002; Thu, 8 Mar 2012 21:22:16 -0800 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Thread-Topic: [apps-discuss] Proposal for a Finance Area Mailing List Thread-Index: AQHM98CAmwhh2dOlJU+TwDETLw5yfpZgB/mAgAAYsgCAAQHjgIAAwgcAgAANC4CAAA1EAP//eoLQ Date: Fri, 9 Mar 2012 05:22:15 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392808170D@exch-mbx901.corp.cloudmark.com> References: <20120309043135.60337.qmail@joyce.lan> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.160.203.60] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [apps-discuss] Proposal for a Finance Area Mailing List X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 09 Mar 2012 05:22:17 -0000 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] On Behalf Of Walter > Sent: Thursday, March 08, 2012 9:19 PM > To: John Levine > Cc: apps-discuss@ietf.org > Subject: Re: [apps-discuss] Proposal for a Finance Area Mailing List >=20 > In closing, perhaps you could assist with teething issues faced by mere > newcomers such as myself by flexing your apparent dummy series > authorship credentials on a humorous RFC for April; "The IETF for > Dummies"? John may have different advice, but I typically refer people to RFC4677 (ht= tp://tools.ietf.org/html/rfc4677, "The Tao of IETF"). Have fun! -MSK (not an actual dummy, but I play one at plenaries) From dhc@dcrocker.net Thu Mar 8 21:24:14 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B656521E800F; Thu, 8 Mar 2012 21:24:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.606 X-Spam-Level: X-Spam-Status: No, score=-6.606 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cqS1+raH-TcI; Thu, 8 Mar 2012 21:24:14 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 02B9221E800E; Thu, 8 Mar 2012 21:24:14 -0800 (PST) Received: from [192.168.1.11] (adsl-67-127-58-62.dsl.pltn13.pacbell.net [67.127.58.62]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q295O4Q9032255 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Mar 2012 21:24:09 -0800 Message-ID: <4F5993E5.3000108@dcrocker.net> Date: Thu, 08 Mar 2012 21:23:49 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: John C Klensin References: <1331188315.87259.YahooMailNeo@web31816.mail.mud.yahoo.com> <4F58EBFA.7010904@stpeter.im> <4F58EFBF.8030908@dcrocker.net> <4F58F39A.9030401@stpeter.im> <11FF964F9FF3063DE7F98BDB@PST.JCK.COM> <4F5919EB.1080407@stpeter.im> <609BED83E23A6939F0C9CEC8@PST.JCK.COM> <8C643A1E79A861336C7025FA@PST.JCK.COM> In-Reply-To: <8C643A1E79A861336C7025FA@PST.JCK.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Thu, 08 Mar 2012 21:24:12 -0800 (PST) Cc: apps-discuss@ietf.org, draft-ietf-appsawg-xdash.all@tools.ietf.org, William Mills , dcrocker@bbiw.net, The IESG Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-appswg-xdash-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 05:24:14 -0000 On 3/8/2012 8:59 PM, John C Klensin wrote: > We've talked about it as "experimental" ("extension" is, as far > as I can remember, a very recent retrofit) but described how The construct was introduced with RFC 822: > extension-field = > published as a formal extension to this > specification; none will have names beginning > with the string "X-"> d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From pbryan@anode.ca Thu Mar 8 21:36:28 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2C1F21E8063 for ; Thu, 8 Mar 2012 21:36:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4xVNOeDjG6zx for ; Thu, 8 Mar 2012 21:36:26 -0800 (PST) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id 391F821E8043 for ; Thu, 8 Mar 2012 21:36:26 -0800 (PST) Received: from [192.168.1.9] (S0106a021b762dbb3.vf.shawcable.net [174.1.50.247]) by maple.anode.ca (Postfix) with ESMTPSA id 671A8617D for ; Fri, 9 Mar 2012 05:36:25 +0000 (UTC) Message-ID: <1331271383.6504.1.camel@neutron> From: "Paul C. Bryan" To: apps-discuss@ietf.org Date: Thu, 08 Mar 2012 21:36:23 -0800 In-Reply-To: <9F0A2492-AE7D-4C12-8BB0-13489FD7F6C1@gmail.com> References: <9F0A2492-AE7D-4C12-8BB0-13489FD7F6C1@gmail.com> Content-Type: multipart/alternative; boundary="=-8BNeW29B3dl1uZ7gPejL" X-Mailer: Evolution 3.2.2-1 Mime-Version: 1.0 Subject: Re: [apps-discuss] draft-pbryan-json-patch-04 - comments X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 09 Mar 2012 05:36:28 -0000 --=-8BNeW29B3dl1uZ7gPejL Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Thu, 2012-03-08 at 13:46 -0800, Vadim Zaliva wrote: > Hi! > > I was looking for JSON patch formats available and found this draft. > It looks nice - concise and to the point. I would like to share few > comments I have. > > 1. I am not sure if 'test' operation should be part of it. The purpose > of the patch is to modify the document. 'test' operation either > succeeds of fails, but it is unclear how this information will be > communicated or used. It almost looks like a API operation rather than > patch format instruction. I would argue that in current state it > should not be included in the format. > > I could see a case when it could be included as a part of conditional > syntax. In this case 'test' becomes a container for other operations > which would be executed only if the test succeeds. For example: > > > { "test": "/baz", "value": "qux", > "onsuccess" : [ > { "replace": "/baz", "value": "boo" }, > { "add": "/baz1", "value": "qux" } > ] > } I'd be interested in others' views on this. > 2. In most examples "value" property holds simple scalar values > (strings or integers) or arrays of such. I think it should be possible > to use arbitrary complex JSON data structures as such values. I hope > this was the intention. Yes, this was the intention. > Perhaps adding an example with more complex value (object or array) > could illustrate this very powerful capability. For example A.1 could > be modified as following; > > An example target JSON document: > > { > "foo": "bar" > } > > A JSON Patch document: > > [ > { "add": "/baz", "value": {"a":1,"b":2} } > ] > > The resulting JSON document: > > { > "baz": {"a":1,"b":2}, > "foo": "bar" > } Thanks, I'll aim to add this to -02. (-01 should be out tomorrow.) Paul --=-8BNeW29B3dl1uZ7gPejL Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit On Thu, 2012-03-08 at 13:46 -0800, Vadim Zaliva wrote:
Hi!

I was looking for JSON patch formats available and found this draft. It looks nice - concise and to the point. I would like to share few comments I have.

1. I am not sure if 'test' operation should be part of it. The purpose of the patch is to modify the document. 'test' operation either succeeds of fails, but it is unclear how this information will be communicated or used. It almost looks like a API operation rather than patch format instruction. I would argue that in current state it should not be included in the format.

I could see a case when it could be included as a part of conditional syntax. In this case 'test' becomes a container for other operations which would be executed only if the test succeeds. For example:


{ "test": "/baz", "value": "qux",
"onsuccess" : [
{ "replace": "/baz", "value": "boo" },
{ "add": "/baz1", "value": "qux" }
]
}

I'd be interested in others' views on this.

2. In most examples "value" property holds simple scalar values (strings or integers) or arrays of such. I think it should be possible to use arbitrary complex JSON data structures as such values. I hope this was the intention.

Yes, this was the intention.

Perhaps adding an example with more complex value (object or array) could illustrate this very powerful capability. For example A.1 could be modified as following;

An example target JSON document:

{
"foo": "bar"
}

A JSON Patch document:

[
{ "add": "/baz", "value": {"a":1,"b":2} }
]

The resulting JSON document:

{
"baz": {"a":1,"b":2},
"foo": "bar"
}

Thanks, I'll aim to add this to -02. (-01 should be out tomorrow.)

Paul --=-8BNeW29B3dl1uZ7gPejL-- From lear@cisco.com Thu Mar 8 22:20:07 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 741DD21F8694; Thu, 8 Mar 2012 22:20:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.547 X-Spam-Level: X-Spam-Status: No, score=-111.547 tagged_above=-999 required=5 tests=[AWL=1.052, BAYES_00=-2.599, GB_I_INVITATION=-2, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XKYWFyZRQiss; Thu, 8 Mar 2012 22:20:06 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 4997321F864D; Thu, 8 Mar 2012 22:20:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=15113; q=dns/txt; s=iport; t=1331274005; x=1332483605; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=nZ1UsezXyU1XZ6QECneGpKhyDl2sngwuxq/hMzQq8gc=; b=DOXl/0I+jSDUuI39cdz+Vy09D3/WKzG0dYfw+wF8G9a+fyBA3KK/rnd9 63n/q1QLr1fB1LDz0jRDKjMC94KuvkB1HXxEFVdP9M9kiEpHGERwedGG/ zKusvMVm65lmoX1J52vIWjToAeP4vbW3mLFs2TNFr6yPtaeebaHVHW/1F s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFABGgWU+Q/khL/2dsb2JhbABDhTWvdYEHggoBAQEEEgEQDwFFARALGAICBQwKCwICCQMCAQIBRQYNAQUCAQEeh2ibMwGMZ5FqgS+Ic4MGghiBFgSVSJAagmSBWw X-IronPort-AV: E=Sophos;i="4.73,556,1325462400"; d="scan'208";a="68050734" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 09 Mar 2012 06:19:58 +0000 Received: from dhcp-10-55-89-64.cisco.com (dhcp-10-55-89-64.cisco.com [10.55.89.64]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q296JvFv011337; Fri, 9 Mar 2012 06:19:57 GMT Message-ID: <4F59A10D.5040605@cisco.com> Date: Fri, 09 Mar 2012 07:19:57 +0100 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Cyrus Daboo References: <4F588C9D.2090403@cisco.com> <13D85D8317A51C090F37BFDD@cyrus.local> In-Reply-To: <13D85D8317A51C090F37BFDD@cyrus.local> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: draft-desruisseaux-caldav-sched.all@tools.ietf.org, Mark Nottingham , Peter Saint-Andre , 'IESG' , apps-discuss@ietf.org Subject: Re: [apps-discuss] Applications Directorate Review of draft-desruisseaux-caldav-sched-11 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 09 Mar 2012 06:20:07 -0000 Cyrus, The changes you've incorporate address my concerns. Eliot On 3/8/12 11:18 PM, Cyrus Daboo wrote: > Hi Eliot, > Thank your for your detailed review. > > --On March 8, 2012 11:40:29 AM +0100 Eliot Lear wrote: > >> Summary: >> >> This is a marked improvement from the previous version, represents YET >> ANOTHER very valuable contribution from these two authors, and is nearly >> ready for publication. I would suggest one more respin. I believe >> this could happen, however, AFTER the IESG discussion. > > OK, that makes sense. > >> >> Major Issues: >> >> >> A question: can the new status codes defined in this specification leak >> to non-participating implementations in Reply operations? > > Strictly speaking the new 1.xx codes are only meaningful when used on > the SCHEDULE-STATUS parameter and that parameter is required to be > removed from any iTIP message the client or server sends (as per > Section 7.3). So leakage should be minimal. That said, RFC5545 does > define the overal meaning for the 1.xx class of codes. However, > neither iCalendar nor iTIP explains what clients should do if they get > a specific code they do not recognize. I don't believe that there is > any known interoperability problem related to that (I suspect clients > either ignore unknown codes outright, or base their behavior on the > status code class). If something needs to be addressed here, it really > ought to be in iCalendar or iTIP, and perhaps filed as an erratum > against one or both of those. > >> Minor Issues: >> In general the document suffers from a lack of conciseness. What >> follows are some of the more glaring examples. >> >> In Section 1, 2nd paragraph, There is no need to describe so early what >> functions aren't covered. The way this is traditionally handled is to >> have a "Future Work" section. That can be done in the intro or it can >> even be put after examples. I prefer the latter, especially if you mean >> for the text to be non-normative. If it is meant to be normative, be >> explicit about it. > > One reason that is there is that the we had (early on) a lot of > implementors asking us about those other methods not being covered. So > we felt it reasonable to add some commentary that they have been > deliberately left out. > > Now I would be willing to move that into a "Potential Future Work" > appendix. But I could argue that the 4th paragraph of Section 1 should > also be moved there (the one about not addressing support for > "external" users). Do you think that should be moved too? > >> Similarly, in the 4th paragraph, same section, it is sufficient to say >> (above) that this mechanism works compatibly with iMIP. You're using a >> double negative. And this problem recurs in the same paragraph. You >> should consider a search on the word "not". > > How about: > > This specification only addresses how scheduling occurs with users on > a single system (i.e., scheduling between CalDAV servers, or some > other calendaring and scheduling system, is not defined). However, > this specification is compatible with servers being able to send or > receive scheduling messages with "external" users (e.g., using the > iCalendar Message-Based Interoperability Protocol iMIP [RFC6047]). > > >> §1, pg 6: >> >> >> In iTIP-based scheduling, there is an event "Organizer" whose role is >> to schedule an event between one or more "Attendees", and this is >> done by sending out invitations and handling responses from each >> Attendee. Often times an Organizer will do a "freebusy" lookup to >> check on Attendees' availability (free-time). >> >> >> This document needn't and shouldn't repeat or review iTIP. Suggest >> remove. > > OK - done. > >> >> Servers supporting this specification advertise their capabilities >> and provides new collections for scheduling operations as described >> in Section 2. >> >> >> This is mundane and not needed in § 1. Suggest you cut it. > > OK - done. > >> §1, ppg 6-7: > >> Let's be more clear about about the theory of operation specified in >> this >> document. Suggest reword along the following lines: >> >> In order to automate the process of scheduling, we define the term >> "scheduling operation" that consists of a client storing an iCal VEVENT >> in a CALDAV store and then the server taking specific actions in >> response. In each case... (and lop off "as per.."). >> >> Also add one sentence here about atomicity (or lack thereof) of the >> operations. > > See next item. > >> §1, pg. 7: >> >> Suggest active tense reword as follows: > > What I have done is reword and compress the four paragraphs that > "introduce" the key sections. Now I have: > > Section 3 defines the automated "Scheduling Operations", that allow a > client to store iCalendar data on a CalDAV server, with the server > taking specific actions in response. One of three scheduling > operations can take place: "create", "modify" or "remove", based on > the HTTP method used for the request, and a comparison between any > existing and any new iCalendar data. > > Section 4 defines how the server processes scheduling messages sent > as the result of a scheduling operation. > > Section 5 defines how freebusy requests with an immediate response is > accomplished. > > Section 6 defines access control privileges for the scheduling > operations defined in this specification. > >> §1.1, ppg 7-8: >> >> No need to restate definitions from other documents– unless you see a >> difference in the meaning of the term amongst documents. In particular, >> I see that you chose to reference RFC-3283 instead of RFC-5546 for >> Calendar User. 3283 would be a downref if you referenced it >> normatively. The definition should be normative. You want 5546. > > I have removed the terminology items repeated from other specs, so now > it just lists the new ones being defined. As a result the 3283 > reference has been completely eliminated. > >> Also see nit on this. >> >> §1.3 pg 9: >> >> I've asked Mark Nottingham for an additional set of eyes on this >> section. I have one immediate comment and question: >> >> >> This document inherits, and sometimes extends, DTD productions from >> Section 14 of [RFC4918]. >> >> >> I would reword- "This document inherits and extends DTD productions..." >> >> If so, should this specification update RFC4918 in rfc-index.txt? > > The text used here is an exact copy of what was used in CardDAV > (RFC6352) which was based on what we used in CalDAV (RFC4791) with > specific changes and clarifications that Julian had requested. It > reflects standard WebDAV XML handling behavior. > >> §2.1, pg 10, and similar text in §2.2, pg 11: >> >> >> The following WebDAV properties specified in CalDAV "calendar-access" >> [RFC4791] MAY also be defined on scheduling... >> >> >> >> Do you mean "Only the following WebDAV..."? If not, why state these >> properties? > > There are some other properties from CalDAV we are not specifying > because they have no meaning on an Outbox (e.g. calendar-timezone). > And there are properties on other types of CalDAV resource that are > not relevant (e.g. calendar-home-set). So I think the working and > intent here is fine. > >> §2.1.1, pg 11, and similar text in §2.2.1, pg 13, §2,4,1, pg 14, and >> similar: >> >> >> PROPFIND behavior: This property SHOULD NOT be returned by a >> PROPFIND allprop request (as defined in Section 14.2 of >> [RFC4918]). >> >> >> Why SHOULD NOT and not MUST NOT? How should the client interpret the >> information, if returned? > > As Julian has noted, this is common practice for the definition of > WebDAV properties. In some cases a server might decide that a live > property is trivial to compute and worthwhile to return in an allprop > response. Since allprop is required to return all dead properties, > client have to be able to handle getting back properties they don't > care about. > >> §3.2.1.1, pg 18: >> >> >> When a scheduling object resource is created by the Organizer, the >> server will inspect each "ATTENDEE" property to determine if a >> scheduling message ought to be delivered to this Attendee according >> to the value of the "SCHEDULE-AGENT" property parameter (see >> Section 7.1) as described in the table below: >> >> >> Please use normative language and active tense. Suggest rewording as >> follows: >> >> >> When the Organizer creates a scheduling object resource, the server >> SHALL >> inspect each "ATTENDEE" property to determine whether to send a >> scheduling >> message. Table XXX below indicates the appropriate action, based on >> the value >> of the "SCHEDULE-AGENT" property. > > Change applied, but still uses "The table below ..." rather than a > direct "Table N" reference. > >> >> §3.2.1.1 AND in §3.2.1.2 and §3.2.1.3: >> >> Why are you treating authorization differently between create & modify >> operations and the remove operation? >> >> Cannot the text in §3.2.1.1 and §3.2.1.2 simply be moved into the >> chapeau (e.g., 3.2.1)? > > OK - done. > >> §3.2.1.2, pg 19 has similar, but more involved issues to §3.2.1.1: >> >> >> When a scheduling object resource is modified by the Organizer, the >> server will inspect each "ATTENDEE" property in the new calendar >> data >> to determine which ones have the "SCHEDULE-AGENT" iCalendar property >> parameter. It will then need to compare this with the "ATTENDEE" >> properties in the existing calendar object resource that is being >> modified. >> >> >> >> For each Attendee in the old and new calendar data on a per-instance >> basis, and taking into account the addition or removal of Attendees, >> the server will determine whether to deliver a scheduling message to >> the Attendee. The following table determines whether the server >> needs to deliver a scheduling message, and if so which iTIP >> scheduling method to use. The values "SERVER", "CLIENT", and >> "NONE" >> in the top and left titles of the table refer to the >> "SCHEDULE-AGENT" >> parameter value of the "ATTENDEE" property, and the values >> "" >> and "" are used to cover the cases where the "ATTENDEE" >> property is not present (Old) or is being removed (New). >> >> >> >> So.. active tense again, same sort of idea: >> >> >> When the Organizer modifies a scheduling object resource, the server >> SHALL >> inspect each "ATTENDEE" property in both the original and modified >> event >> instance >> to determine whether to send a scheduling message. Table XXX below >> indicates the >> appropriate action, based on the value of the "SCHEDULE-AGENT" >> property. >> The values "SERVER", "CLIENT", and "NONE" in the top and left headings >> refer to the "SCHEDULE-AGENT" parameter value of the "ATTENDEE" >> property. >> The the values "" and "" are used to cover the cases >> where the >> "ATTENDEE" property is not present (Old) or is being removed (New). >> >> >> The use of the word ATTENDEE in the upper left-hand corner of the table >> is confusing, and I would remove it. I might also change the headings >> to read "Original" (going down)" and "Modified". This allows for >> consistency of language. > > OK - done. > >> §3.2.1.3, Rinse and repeat this exercise for "Remove": >> >> >> >> When a scheduling object resource is removed by the Organizer, the >> server will inspect each "ATTENDEE" property in the scheduling >> object >> resource being removed to determine which ones have the "SCHEDULE- >> AGENT" iCalendar property parameter. >> >> For each Attendee the server will determine whether to attempt to >> deliver a scheduling message into the Attendee's scheduling Inbox >> collection, based on the table below: >> >> >> So... >> >> >> When an Organizer removes a scheduling object resource, the server SHALL >> inspect each "ATTENDEE" property in the scheduling object resource >> being >> removed, and act based on the value of the "SCHEDULE-AGENT" property >> value, >> according to Table XXX below. > > OK - done. > >> §3.2.2.3, pg 23: >> >> >> If the Attendee adds an "EXDATE" property value to effectively remove >> a recurrence instance, the server MUST deliver an iTIP "REPLY" >> scheduling message to the Organizer to indicate that the Attendee >> has >> declined the instance. >> >> >> EXDATE isn't the only way an Attendee can decline. a specific event, >> right? Is this the only operation in which a server MUST act? Why >> call this one out? > > Normally people think that a change in participation status is > governed by the ATTENDEE;PARTSTAT value. It is not entirely obvious > that the act of adding an EXDATE to an event means that the attendee > has in effect declined the event. At least I don't believe there is > anything stated to that effect in iCalendar or iTIP. So I think it is > appropriate to describe the actions for both a change to PARTSTAT and > EXDATE. > >> §3.2.3.2, pg 25, in the COPY table, and 3.2.3.3, pg 26, the MOVE >> table" : >> >> Remove (1) and replace with "Same as PUT in Table XXX" > > I left the note in but reworded as a reference to the section. > >> Also, move DELETE above MOVE (removes forward reference) and then remove >> (2) and replace with "Same as DELETE") > > OK - done. > >> In all of these sections change to both active tense and normative >> language. So for instance: >> >> Old: >> >> >> When a MOVE method request is received, the server will execute >> >> New: >> >> >> When the server receives a MOVE request, it SHALL execute > > OK - done. > >> §3.2.9, pg 32: >> >> >> The 1.xx "REQUEST-STATUS" codes are new. This specification >> modifies >> item (2) of Section 3.6 of [RFC5546] by adding the following >> restriction: >> >> >> >> Should this memo indicate that it updates RFC-5546? > > Yes it should. Done. > >> >> §3.2.10.1, §3.2.10.1, pg 34: >> >> Change "Clients can" to "Clients MAY" > > OK - done. > >> Nits: >> >> >> §1, pg. 6: >> >> >> >> This is called a "Scheduling >> Operation" and fully described in Section 3 >> >> Missing verb "is". > > No longer relevant as that has been re-written. > >> >> Throughout: >> >> >> Calendar User is not capitalized consistently. > > Lowercased everywhere to be consistent with 5546. > >> Throughout: >> >> >> Tables should be numbered for reference. > > As noted in separate email, this change won't be applied. > > I have attached my working copy with the changes described above as > well as an HTML diff for your convenience. > From walter.stanish@gmail.com Thu Mar 8 23:23:39 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEFCF21F8466 for ; Thu, 8 Mar 2012 23:23:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.281 X-Spam-Level: X-Spam-Status: No, score=-1.281 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_20=-0.74, RCVD_IN_DNSWL_LOW=-1, SARE_FWDLOOK=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id App0n0Ee4QIU for ; Thu, 8 Mar 2012 23:23:38 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 06ABC21F8657 for ; Thu, 8 Mar 2012 23:23:37 -0800 (PST) Received: by bkuw5 with SMTP id w5so1095233bku.31 for ; Thu, 08 Mar 2012 23:23:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=o8z1+8LtcdEjMvJox5GjSr+5tnfc0/KbXjFRdNMChdo=; b=gwk551XTFo4VVJAc2/HRn1PVCnPnnAzBlj8HAfnRWogPh0WflFpo9NoiCym+iqG/1+ 83JrDm9hFBvsFWZikCGLifKyhW/lwU4oDPJOac2sRK0M0USCsuhDFZnnyG2JoShP1QDT HLdFLReK1pLqmysWzgdaXFTBm/yAZlaMK4s8RAi/NpDCrUaAziQd/PkRGIom9CJd2xvh Zl/eO1FG3SIYpuZEZaWmj7VKurkF01YZJfnxjW2QMm7HOJ+kf+ndBXYypJfCgbYkN5q2 w9UNazNH+KkhjFZPorlFwLB9/BhLKU8R/hGDXCgHZUnI0BwdVI39jmgCZafxseoq/vKS EqGw== MIME-Version: 1.0 Received: by 10.204.153.28 with SMTP id i28mr454310bkw.48.1331277816980; Thu, 08 Mar 2012 23:23:36 -0800 (PST) Received: by 10.204.184.17 with HTTP; Thu, 8 Mar 2012 23:23:36 -0800 (PST) In-Reply-To: <4F58DB05.9020901@dcrocker.net> References: <20776EAF-5ADB-40B8-A31E-DBA329A61CF8@vpnc.org> <4F58DB05.9020901@dcrocker.net> Date: Fri, 9 Mar 2012 14:23:36 +0700 Message-ID: From: Walter To: dcrocker@bbiw.net, Jeff.Hodges@kingsmountain.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Proposal for a Finance Area Mailing List X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 09 Mar 2012 07:23:39 -0000 > A separate but related question is whether "financial-protocol" folk need > different underlying =A0protocols, for transport/transfer of this particu= lar > type of data and notifications, than what is extant (and implemented & > shipping) today (e.g., HTTP, TLS/SSL, SCTP, XMPP, etc.). > > If not, then perhaps they might concentrate on the stuff at their > "financial" layer and concoct "bindings" to the existing underlying stuff > (eg, as we did in SAML & Liberty (to HTTP)) as appropriate, and they then > could perhps more easily work on their "financial" layer whereever (eg, W= 3C, > OASIS, SomeNew.org, etc). I agree wholeheartedly with the suggestion of transport neutrality, which I believe I raised earlier on this thread (possibly indirectly through allusion to arbitrary topology support). Each of the transports mentioned above offers different properties in terms of at least security, topology, wire-level efficiency and latency and for this reason alone it would appear to be unwise to mandate one or more possible transports for all deployment environments (whose requirements will vary). However, I am not certain that I can agree with the apparent(?) notion presented that perhaps it then follows that the IETF is not an appropriate venue for this development. The rest of this email will address each of the previous efforts raised by Dave and Jeff (thanks for taking the time to point these out!) and summarize briefly why from my perspective they appear to differ significantly from the proposed scope. > The early EDI work produced a working group and a successor working group= , > participation and specifications: > > RFC6362, Multiple Attachments for Electronic Data Interchange - Internet > Integration (EDIINT) K. Meadors, Ed. =A0August 2011 =A0ASCII =A0INFORMATI= ONAL > > RFC6359, Datatracker Extensions to Include IANA and RFC Editor Processing > Information S. Ginoza, M. Cotton, A. Morris =A0September 2011 =A0ASCII > =A0INFORMATIONAL > > RFC6017, Electronic Data Interchange - Internet Integration (EDIINT) > Features Header Field > > RFC5402, Compressed Data within an Internet Electronic Data Interchange > (EDI) Message T. Harding, E > > RFC1865, EDI Meets the Internet Frequently Asked Questions about Electron= ic > Data Interchange (EDI) on the Internet W. Houser, J. Griffin, C. Hage > =A0January 1996 ASCII =A0INFORMATIONAL > > RFC1767, MIME Encapsulation of EDI Objects D. Crocker Scope is EDI. Without passing judgement on any one of the various EDI standards that are apparently floating about these days, my own perspective is that at its core EDI tends to differ significantly in scope from the proposed scope of financial transactions, largely because EDI's focus appears to be on "big corporate" and government business level metadata and processes (invoicing, purchase orders, etc...) that do not necessarily apply to all or even most financial transactions on the internet today, such as those involving individual consumers. As a result of this key difference, EDI systems tend to prevent or constrict the expression of possible financial settlement level concerns, and have little motivation to accomodate or consider alternative systems that may be based upon either non-currency value exchange or non ISO4217 currency exchange such as Ripple, CES, LETS, Bitcoin, etc. In short, from an EDI perspective, it would seem that (in *most* cases?) the settlement of financial transactions is essentially an external process. In addition, documents like http://tools.ietf.org/html/rfc5402 delve in to concerns such as security (authentication, integrity and encryption) that an alternative protocol designed now (from a message-oriented perspective) might well be able to delegate in whole or in part to the transport layer. The proposed scope could be seen to support EDI in that it could potentially provide higher reliability, lower cost, transparently redundant (supporting business continuity / disaster recovery goals), or otherwise more attractive settlement functionality to complement existing EDI systems. In addition, EDI information could potentially be bundled within financial transaction related messages in order to provide both information relevant to settlements and higher level metadata where appropriate. > In addition to the previously mentioned EDI and IOTP work, there was also > this back in the late 1990s.. > > CyberCash Credit Card Protocol Version 0.8 > http://tools.ietf.org/html/rfc1898 Scope is basically credit cards. It is also interesting to note that, apparently at the time of writing, their centralized registry of message types exceeded 100 (getting rather messy... maybe the approach was not high level enough to be portable to an internet sized community, re: most of these were probably necessitated by legacy system integrations and there was no mechanism for abstracting them away at the higher conceptual level of a 'financial transaction'...). > ECML v1: Field Names for E-Commerce > http://tools.ietf.org/html/rfc2706.txt > > ECML v1.1: Field Specifications for E-Commerce > http://tools.ietf.org/html/rfc3106.txt Scope is HTML (user interface) oriented; a totally different problem domain. Also limits scope further to credit cards. > ..and then fwiw, it's not clear what happened to these expired I-Ds.. > > http://tools.ietf.org/html/draft-eastlake-internet-payment-01 > http://tools.ietf.org/html/draft-eastlake-universal-payment-02 > http://tools.ietf.org/html/draft-hallam-micropayment-00 'draft-eastlake-internet-payment-01' is one of the most relevant historic efforts under review to the proposed scope. It specifies a character string syntax to (1) indicate prices and acceptable methods of payment, (2) tender payment, and (3) issue a receipt acknowledging payment or notification if payment fails. It could be considered an early attempt at the same problem space. Some issues: ISO4217 limited. Includes settlement path specification with boolean 'or' logic (no other). Encourages payment information to be sent over insecure transports. Vague (re: partial payment, what is a 'payment system', estimates, ceilings, receipt delivery mechanisms, etc.). HTML integration concept predates the tendency towards pixel-perfection in the modern 'browser as a platform'-world and would be harder to propose today. Receipt implementation appears to have skipped consideration of non-realtime settlement (ie: ACH, SWIFT, etc.). 'draft-eastlake-universal-payment-02' attempts to provide header-based negotiation of common 'payment systems' between clients and servers (merchants) to facilitate simple payments, mostly in the language of online shopping from a browser. This is potentially interesting but has issues: Confuses actual financial connectivity and payment systems (which often act as gateways to others), strong B2C + centralized settlement system (legacy) focus, examples appear to request that consumers might provide personally identifiable information prior to purchase, lack of metadata. 'draft-hallam-micropayment-00' is one of the most relevant historic efforts under review to the proposed scope. It is an unfinished proposal for a payments system based upon a customer-(single)broker-vendor model, primarily concerned with micropayments. It is relatively holistic and well considered, but appears to fail to delineate clearly between aspects of financial instruments (eg: currencies) and those of financial settlement networks (eg: party authentication, message non-repudiation) in its incomplete risk model. Its forward looking proposal to formally describe multiple settlement paths with different temporal, risk, or other characteristics is very much similar to the approach that we have had under consideration and have been developing at Payward Inc. since late 2011. However, the proposal also descends in to specific cryptographic algorithms instead of maintaining a pluggable architecture which is apparently often considered 'bad practice' in higher level protocol design today. It is also rather centralized and insecure: "requires perfect trust between servers acting as brokers. Compromise of one server compromises all others." Considering all of the above proposals, at one end we have EDI focused on business level metadata surrounding actual financial transactions, and at the other we have draft-eastlake-internet-payment-01 that attempts to strip out all metadata and simply negotiate prices and paths for external execution of settlements through a finite vocabulary of intermediary 'payment systems', conveniently ignoring the potentially complex realities of said systems. In summary - whilst interesting at points - none of the historic financial related proposals target the same problem domain. Most importantly, none can adequately describe the breadth of financial transactions occurring over the internet today. >From my perspective, what is sorely needed is instead an adequately descriptive (yet extensible/flexible) protocol based not upon a specific integration point within the existing standards infrastructure (examples in the historic documents above included HTTP headers, SMTP, etc.) but rather a transport neutral message-oriented protocol that is concise and minimalist enough to be deployed readily yet robust enough to be deployed for any conventional (interbank payments, credit card payments), specialist (high frequency trading, non-currency value exchange such as the Energy Working Group member's idea regarding possible use for energy costs and trading, 'exotic' (ie. non US / credit card centric)) or emerging (mobile, digital currencies such as bitcoin, ripple) use case. There has clearly been thought in this direction previously but nothing adequately broadly based and flexible with the potential to tie things together without excluding significant, interesting, valuable and emerging parts of the community. Perhaps it is now the right time to solve this problem? Regards, Walter Stanish Payward, Inc. From zach@sensinode.com Fri Mar 9 03:35:28 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4266721F85F3; Fri, 9 Mar 2012 03:35:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AvEC4pqMNjMc; Fri, 9 Mar 2012 03:35:26 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 2DF0821F861F; Fri, 9 Mar 2012 03:35:22 -0800 (PST) Received: from [192.168.1.103] (178-55-87-130.bb.dnainternet.fi [178.55.87.130]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q29BZFQm015298; Fri, 9 Mar 2012 13:35:16 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <4F4D2FCB.8030805@gmx.de> Date: Fri, 9 Mar 2012 13:35:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F4D2FCB.8030805@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1084) Cc: core@ietf.org, draft-ietf-core-link-format@tools.ietf.org, The IESG , IETF Apps Discuss Subject: Re: [apps-discuss] [core] APPSDIR review of draft-ietf-core-link-format-11 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 09 Mar 2012 11:35:28 -0000 Julian, Thanks for the really detailed and helpful review! =20 On Feb 28, 2012, at 9:49 PM, Julian Reschke wrote: >=20 > Major Issues: >=20 > 2.2. Link relations >=20 > Since links in the CoRE Link Format are typically used to describe > resources hosted by a server, and thus in the absence of the = relation > parameter the new relation type "hosts" is assumed (see Section = 7.2). >=20 > It took me a moment to realize that "hosts" isn't the plural of "host" = here. Maybe a different relation name would make things clearer = (although I currently have no better proposal :-). Boy was that a fun discussion on the WG list as well, and hosts is what = we ended up with... Maybe just adding some explanatory text right there = would help. > The "hosts" relation type indicates that the target URI is a = resource > hosted by the server given by the base URI, or, if present, the > anchor parameter. >=20 > So the rule for determining the context URI is different for this link = relation? I believe this needs to change. Originally it was for the whole link format, and I think with the rules = you suggest below we can make it generic again.=20 > To express other relations, links can make use of any registered > relation by including the relation parameter. To simplify the > constrained implementations, the value of a "rel" parameter in this > link format SHOULD NOT contain more than one relation type. There >=20 > That's a SHOULD NOT that doesn't help anybody. Are recipients supposed = to understand multiple relation types or not? If yes, then the = constraint isn't needed. If no, it's a MUST NOT. The only reason we left the door open for allowing multiple relation = types, was in case other Web Links were converted to this format (and = thus may have multiple relation types). Constrained devices are not = expected to understand multiple relation types. I would recommend that = we just remove the SHOULD NOT. > may be cases where multiple relation types cannot be avoided, for > example when storing a RFC5988 Link header in this link format. The > context of a relation can be defined using the anchor parameter. In > this way, relations between resources hosted on a server, or between > hosted resources and external resources can be expressed. >=20 > This seems to repeat information from earlier on... >=20 >=20 > 3. CoRE link extensions >=20 > The following CoRE specific target attributes are defined in = addition > to the ABNF rules in Section 5 of [RFC5988]. These attributes > describe information useful in accessing the target link of the > relation, and in some cases may be URIs. These URIs MUST be treated >=20 > s/may be/can use the syntactical form of a/ >=20 > as non resolvable identifiers (they are not meant to be retrieved). >=20 > Not sure about the "MUST". Maybe replace with an explanation that they = can indeed by dereferenced (for instance to obtain a description of the = link relation), but that this is not part of the protocol and MUST NOT = be done automatically on link evaluation. Good suggestion, I will make a ticket. We do need to check that this is = consistent with RFC5988, as my understanding of target attributes was = that they are not meant to be retrieved (checking again though, I can't = find text in RFC5988 that contradicts what you are suggesting). > When attributes are compared, they MUST be compared as strings. >=20 > Attribute values? >=20 > Relationships to resources that are meant to be retrieved should be > expressed as separate links using the anchor attribute and the > appropriate relation type. >=20 > It's not clear to me what this means. Could you elaborate? Basically a work-around for the MUST you suggested replacing above. This = text would be removed if that change is made.=20 > link-extension =3D > link-extension =3D/ ( "rt=3D" quoted-string ) > link-extension =3D/ ( "if=3D" quoted-string ) > link-extension =3D/ ( "sz=3D" cardinal ) > cardinal =3D "0" / %x31-39 *DIGIT >=20 > In here, you copied the ABNF style from RFC 5988. I think that style = is something we should avoid, though, because it encourages parsers to = special case certain attributes. >=20 > I would recommend to allow both token and quoted-string for all new = parameters. >=20 > (and yes, I'll raise an erratum against RFC 5988 once we have done the = base work in HTTPbis) Carsten already touched on this, and I will make a ticket.=20 >=20 > 3.1. Resource type 'rt' attribute >=20 > The resource type "rt" attribute is an opaque string used to assign = a > semantically important type to a resource. One can think of this as > a noun describing the resource. In the case of a temperature > resource this could be e.g. an application-specific semantic type > like "OutdoorTemperature", a Universal Resource Name (URN) like > "urn:temperature:outdoor" or a URI referencing a specific concept in > an ontology like >=20 > "http://sweet.jpl.nasa.gov/2.0/phys.owl#Temperature". Multiple > resource type attributes MAY appear in a link. >=20 > Please avoid that. In general, the format that you're borrowing from = doesn't allow multiple parameters with the same name. Either make it = multiple links, or allow a white-space separated list of values in the = attribute value. Right, same goes for if=3D. In theory we could allow multiple values = separated by a white-space, like in the rel=3D attribute. This makes the = attribute matching more difficult however. At the same time including = multiple links is wasteful overhead. So far when applying these in = designs only a single rt=3D or if=3D attribute has been needed, but I = could foresee multiple values in the future. =20 > The resource type attribute is not meant to used to assign a human > readable name to a resource. The "title" attribute defined in > [RFC5988] is meant for that purpose. >=20 > Did you consider using the type attribute that already is defined in = RFC 5988? type=3D refers to the Media Type, and this is already used also in this = format for that purpose.=20 > 5. Examples >=20 > A few examples of typical link descriptions in this format follows. > Multiple resource descriptions in a representation are separated by > commas. Linefeeds never occur in the actual format, but are shown = in > these examples for readability. Although the following examples use > CoAP response codes, the examples are applicable to HTTP as well = (the > corresponding response code would be 200 OK). >=20 > Actually, RFC 5988 allows CR LF between parameters as it uses the RFC = 2616 list production allowing implied LWS. >=20 > If you want to rule this out, you probably need to specify your own = ABNF. I would not mind allowing the CR LF actually, but do we really inherit = that from the RFC 2616 production as we are not inside the HTTP header = anymore?=20 > This example arranges link descriptions hierarchically, with the > entry point including a link to a sub-resource containing links = about > the sensors. >=20 > REQ: GET /.well-known/core >=20 > RES: 2.05 "Content" > ;rt=3D"index" >=20 > REQ: GET /sensors >=20 > RES: 2.05 "Content" > ;rt=3D"TemperatureC";if=3D"sensor", > ;rt=3D"LightLux";if=3D"sensor" >=20 > rt=3D"index" is mentioned for the first time here. Is this something = recipients need to understand, so is it predefined? Also, isn't this a = use case for rel=3Dindex? Yep, "index" is not a great example here. I will update this to be more = appropriate.=20 > Minor Issues: >=20 > The main function of such a discovery mechanism is to provide > Universal Resource Identifiers (URIs, called links) for the = resources >=20 > Nope. As discussed further down below, a link requires two resources, = not a single one. >=20 > 2.1. Target and context URIs >=20 > Each link conveys one target URI as a URI-reference inside angle > brackets ("<>"). The context URI of a link (also called base URI in > [RFC3986]) conveyed in the CoRE Link Format is by default built from > the scheme and authority parts of the target URI. In the absence of >=20 > OK, so >=20 > ; rel=3Dbar >=20 > represents the link >=20 > http://example.com --bar--> http://example.com/foo >=20 > ? Sounds a bit counter-intuitive to me; maybe you should explain that = in examples. It is intuitive for our main use case, which is describing the resources = hosted by that server using the rel=3Dhosts relation. But yes, I can add = more example. >=20 > this information in the target URI, the context URI is built from = the > scheme and authority that was used for referencing the resource > returning the set of links, replacing the path with an empty path. >=20 > Thus by default links can be thought of as describing a target > resource hosted by the server. Other relations can be expressed by > including an anchor parameter (which defines the context URI) along > with an explicit relation parameter. This is an important = difference > to the way the HTTP Link Header format is used, as it is included in > the header of an HTTP response for some URI (this URI is by default > the context URI). Thus the HTTP Link Header is by default relating > the target URI to the URI that was requested. In comparison, the > CoRE link format includes one or more links, each describing a > resource hosted by a server by default. Other relations can be > expressed by using the anchor parameter. See Section 5 of [RFC3986] > for a description of how URIs are constructed from URI references. >=20 > Alternative explanation: >=20 > The context URI specified by >=20 > a) the anchor parameter, when specified, or >=20 > b) protocol + authority of the target URI, when specified >=20 > c) protocol + authority of the link format document's base URI. >=20 > It would be nice if the reason why only protocol + authority are used. I like this way of explaining it, will make a ticket.=20 > (you may also want to use the term "Origin" (RFC 6454) for protocol + = authority) Richard Barnes also suggested this in his review, added a ticket = already:=20 http://trac.tools.ietf.org/wg/core/trac/ticket/191 > 2.3. Use of anchors >=20 > As per Section 5.2 of [RFC5988] a link description MAY include an > "anchor" attribute, in which case the context is the URI included in > that attribute. This is used to describe a relationship between two > resources. A consuming implementation can however choose to ignore > such links. It is not expected that all implementations will be = able > to derive useful information from explicitly anchored links. >=20 > Right. Maybe make clear that recipients MUST either process anchor = correctly, or ignore the whole link relation (not only the anchor = parameter). OK.=20 > 7.2. New 'hosts' relation type >=20 > This memo registers the new "hosts" Web Linking relation type as per > [RFC5988]. >=20 > Relation Name: hosts >=20 > Description: Refers to a resource hosted by the server indicated by > the link context. >=20 > Does that indicate more than "is one the same server"? In which case I = believe no link relation is needed. We are using this to indicate: Origin -> hosts -> Target URI e.g. coap://this.server -> hosts -> /sensor/temperature (and has these = attributes) How would we relate this following Web Linking without a relation? >=20 > Nits: >=20 > Abstract >=20 > This document defines Web Linking using a link format for use by > constrained web servers to describe hosted resources, their > attributes and other relationships between links. Based on the HTTP > Link Header format defined in RFC5988, the CoRE Link Format is >=20 > Please s/header/header field/ throughout. >=20 > Resource Discovery can be performed either unicast or multicast. > When a server's IP address is already known, either a priori or > resolved via the Domain Name System (DNS) [RFC1034][RFC1035], = unicast > discovery is performed in order to locate the entry point to the > resource of interest. This is performed using a GET to = /.well-known/ > core on the server, which returns a payload in the CoRE Link Format. > A client would then match the appropriate Resource Type, Interface > Description and possible Content-Type [RFC2045] for its application. >=20 > "Media type, as specified in the type attribute"? >=20 > CoRE Link Format > A particular serialization of typed links based the HTTP Link > Header serialization defined in Section 5 of RFC5988, but carried > as a resource representation with a MIME type. >=20 > s/MIME type/Internet Media Type/ >=20 > Attribute > Properly called "Target Attribute" in RFC5988. A set of = key/value > pairs that describe the link or its target. >=20 > One attribute is a *single* key/value pair... >=20 >=20 > 3.2. Interface description 'if' attribute >=20 > The Interface Description "if" attribute is an opaque string used to > provide a name, URI or URN indicating a specific interface = definition >=20 > URNs are a subset of URIs... >=20 > used to interact with the target resource. One can think of this as > describing verbs usable on a resource. The Interface Description > attribute is meant to describe the generic REST interface to = interact > with a resource or a set of resources. It is expected that an > Interface Description will be re-used by different resource types. > For example the resource types "OutdoorTemperature", "DewPoint" and > "RelHumidity" could all be accessible using the Interface = Description > "http://www.example.org/myapp.wadl#sensor". >=20 > The Interface Description could be for example the URI of a Web > Application Description Language (WADL) [WADL] definition of the > target resource "http://www.example.org/myapp.wadl#sensor", a URN > indicating the type of interface to the resource "urn:myapp:sensor", > or an application-specific name "Sensor". Multiple Interface > Description attributes MAY appear in a link. >=20 > (see above) >=20 > 3.3. Maximum size estimate 'sz' attribute >=20 > The maximum size estimate attribute "sz" gives an indication of the > maximum size of the resource indicated by the target URI. This >=20 > Checking: is "size of the resource" sufficiently defined in Core? In = HTTP it would need a somewhat more complex definition ("payload returned = upon GET..."). What does the WG think? > 4.1. Query Filtering >=20 > A server implementing this document MAY recognize the query part of = a > resource discovery URI as a filter on the resources to be returned. > The query part should conform to the following syntax (parmname is = as > defined in [RFC5988], pct-encoded and unreserved are defined in > [RFC3986]). Note that this only defines querying for a single > parameter at a time. >=20 > I note that hardwiring URI query parameters into the protocol is *not* = Restful. >=20 > Also, you probably need to state how to present non-ASCII parameter = characters in the parameter (UTF8-encode-then-percent-escape...) Yes, already opened up a ticket on that: http://trac.tools.ietf.org/wg/core/trac/ticket/192 >=20 > filter-query =3D resource-param "=3D" query-pattern > resource-param =3D "uri" / parmname > query-pattern =3D search-token [ "*" ] > search-token =3D *search-char > search-char =3D unreserved / pct-encoded > / ":" / "@" ; from pchar > / "/" / "?" ; from query > / "!" / "$" / "'" / "(" / ")" > / "+" / "," / ";" / "=3D" ; from sub-delims >=20 > The resource-param "uri" refers to the URI-reference between the "<" > and ">" characters of a link. Other resource-param values refer to > the link attribute they name. Filtering is performed by comparing > the query-pattern against the value of the attribute identified by > the resource-param for each link-value in the collection of = resources > identified by the URI path. >=20 > Which makes it impossible to use "uri" as link attribute. Maybe this = should be noted. Alternatively maybe use a format that doesn't require = overloading the name. Carsten touched on this, we'll look at a better way. > This example shows the use of an anchor attribute to relate the > temperature sensor resource to an external description and to an > alternative URL. >=20 > s/URL/URI/ > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core Thanks, Zach --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From dhc@dcrocker.net Fri Mar 9 05:15:00 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44AE621F85EA for ; Fri, 9 Mar 2012 05:15:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.606 X-Spam-Level: X-Spam-Status: No, score=-6.606 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b0WMovm92YFA for ; Fri, 9 Mar 2012 05:14:59 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id ED5B421F85D8 for ; Fri, 9 Mar 2012 05:14:58 -0800 (PST) Received: from [192.168.1.11] (adsl-67-127-58-62.dsl.pltn13.pacbell.net [67.127.58.62]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q29DEoZs009894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Mar 2012 05:14:56 -0800 Message-ID: <4F5A023A.5000601@dcrocker.net> Date: Fri, 09 Mar 2012 05:14:34 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Walter References: <20120309043135.60337.qmail@joyce.lan> <9452079D1A51524AA5749AD23E00392808170D@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E00392808170D@exch-mbx901.corp.cloudmark.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 09 Mar 2012 05:14:56 -0800 (PST) Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Proposal for a Finance Area Mailing List X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 13:15:00 -0000 On 3/8/2012 9:22 PM, Murray S. Kucherawy wrote: >> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Walter ... >> In closing, perhaps you could assist with teething issues faced by mere >> newcomers such as myself by flexing your apparent dummy series >> authorship credentials on a humorous RFC for April; "The IETF for >> Dummies"? > > John may have different advice, but I typically refer people to RFC4677 (http://tools.ietf.org/html/rfc4677, "The Tao of IETF"). That's a good introduction for an individual wishing to participate in the IETF. Anyone new to the IETF should read it. I think the challenge here is also giving guidance about starting an IETF activity. The closest document for that, I think, is: Considerations for Having a Successful Birds-of-a-Feather (BOF) Session http://tools.ietf.org/html/rfc5434 A pre-wg isn't a BOF, of course, but it's got quite a bit in common. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From johnl@iecc.com Fri Mar 9 06:18:23 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECBDB21F85F4 for ; Fri, 9 Mar 2012 06:18:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.277 X-Spam-Level: X-Spam-Status: No, score=-110.277 tagged_above=-999 required=5 tests=[AWL=0.922, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YhyuAZsOy081 for ; Fri, 9 Mar 2012 06:18:23 -0800 (PST) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 64FA921F865C for ; Fri, 9 Mar 2012 06:18:12 -0800 (PST) Received: (qmail 54922 invoked from network); 9 Mar 2012 14:18:09 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 9 Mar 2012 14:18:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4f5a1121.xn--yuvv84g.k1203; i=johnl@user.iecc.com; bh=iedr+kDhHt1uuAHaKI+2qF0SDx7rZ/4nt3ulP0FhGUs=; b=BxGQZUXuZdlv4P/ZWy3l34me448/nR/UdAJ7mkusbQthiSBwwKLeBhZ8P/BiPClqvCr7zF2l7/W6JBwJGtagsdu5E+kzDZPezEZxcZVohbB45OvmRy3It8yCjx9W9jSidS5mjzNpuFJQhbiKP8Jzxq7kRLhospr3yofd47TXmEk= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4f5a1121.xn--yuvv84g.k1203; olt=johnl@user.iecc.com; bh=iedr+kDhHt1uuAHaKI+2qF0SDx7rZ/4nt3ulP0FhGUs=; b=nvGVBT+/3Pc6NODPAcuSea/45cnxt0rb7t2jJOU/0nygo+a+FFJXh65X8BrJAOB/D7cu7gq8BDtfXGA6aTF1pkDEeFXW/jpRRvtdh+p5Ju9Clvn/7WhIhSQ2nn93cqdviQOtsb8AaQyNT/ADpCEJSgPfflezqPogTELLCp8moiQ= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 9 Mar 2012 14:17:47 -0000 Message-ID: <20120309141747.82205.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [apps-discuss] Proposal for a Finance Area Mailing List X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 09 Mar 2012 14:18:24 -0000 >>  Anyone likely to implement it?  The IETF has a well known >> preference for running code. > >(One might wonder if such conflicts with the 'come with a problem >rather than a solution' philosophy of the BOFs / mailing list >proposals @ http://tools.ietf.org/html/rfc5434#page-2 ? Then again, >one might try to focus on avoiding bureaucratic discussion >entirely...) I'll take that as "no". R's, John From scott@kitterman.com Fri Mar 9 06:23:40 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 854A421F84DF for ; Fri, 9 Mar 2012 06:23:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ztbtFEAMfB6 for ; Fri, 9 Mar 2012 06:23:40 -0800 (PST) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id E2BA221F84DC for ; Fri, 9 Mar 2012 06:23:39 -0800 (PST) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 5099820E40FA; Fri, 9 Mar 2012 09:23:39 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1331303019; bh=BOgcqlw6y8iIgbHjMAc1g4Gi4IOjTDrxxNQ2HyGiS+8=; h=From:To:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=lTY/vTYYcwNUU985EScWVYgn0b7c1NikM4DbO20QhM0NKIMtYqXsFITl8zmrkKpvi 0q1F44XzJT0/rUlcoxHWcQTxAwIEj3pdhtKL7Q7uH4GDQ2raw6LqF9Y/t/XFI+n406 jpbXJvD0swALjeakSQQJWtNbUUctISfnOVddD5CM= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 318A620E408E; Fri, 9 Mar 2012 09:23:39 -0500 (EST) From: Scott Kitterman To: apps-discuss@ietf.org Date: Fri, 09 Mar 2012 09:23:38 -0500 Message-ID: <3711970.F67YVxsDXC@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <20120309043135.60337.qmail@joyce.lan> References: <20120309043135.60337.qmail@joyce.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Subject: [apps-discuss] Running code ... X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 09 Mar 2012 14:23:40 -0000 On Friday, March 09, 2012 04:31:35 AM John Levine wrote: ... > > Sounds cool. Anyone likely to implement it? The IETF has a well known > preference for running code. Although DNS provisioning systems seem to be a notable exception to this rule. Scott K From barryleiba.mailing.lists@gmail.com Fri Mar 9 06:46:56 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B83021F865D for ; Fri, 9 Mar 2012 06:46:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.984 X-Spam-Level: X-Spam-Status: No, score=-102.984 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ne2hmMYXXq1U for ; Fri, 9 Mar 2012 06:46:55 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id CA9C721F864F for ; Fri, 9 Mar 2012 06:46:55 -0800 (PST) Received: by ghbg16 with SMTP id g16so969291ghb.31 for ; Fri, 09 Mar 2012 06:46:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Wgj46inUoPpqiv+CZbfhgSn+ufeD+aSjmaNZwD49/OI=; b=CZ+8qxzzRuS1L1FKZwuuj6c79DTZbg/HG4bR4VgsLGr78JnZazph8e7oCoIctSNAlQ xA5RstvSAamqcIGXb6JKy+uYAw6t/RtUZqg1w8u01qc27ycPg6IwAi4qzlcMf3p/TNVi TQSPNk4hfT7eIFkNA1Fx0g9GtOJDIbiPyzYEM3p7EI4N3UUSljDAvtH82vWeGDXDyTfe QqfeJjcRbZ6MX7uS7YeuKUnsuIMtd1cX/U7hqeVGGlODRW0kWzlSP95BpYwgFkv42GIM Iile2AUtPq62s/cJFKSHjEa6U0gLYLv2y3ndxiMURlwpBRhBdxZYdlnJfNOnaRQgCFen ioLg== MIME-Version: 1.0 Received: by 10.236.186.1 with SMTP id v1mr2703759yhm.4.1331304415496; Fri, 09 Mar 2012 06:46:55 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.106.16 with HTTP; Fri, 9 Mar 2012 06:46:55 -0800 (PST) In-Reply-To: References: <4F58D9F3.2000602@dcrocker.net> Date: Fri, 9 Mar 2012 09:46:55 -0500 X-Google-Sender-Auth: bu4rZGwatPdBsrbcxFE6QGZsPFQ Message-ID: From: Barry Leiba To: Walter Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Proposal for a Finance Area Mailing List X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 09 Mar 2012 14:46:56 -0000 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =A0Certain functionality required by modern financial systems is not > =A0presently available in open, legacy-free, adequately globalized > =A0protocols. > > =A0This functionality includes: > =A0* Settlement and reversal / cancellation term negotiation > =A0* Exchange rate negotiation > =A0* Latency calculation / negotiation > =A0* Fee, tax and discount calculation / negotiation > =A0* Arbitrary currency / asset support > =A0* Multi-currency / asset transaction support > =A0* Quotation support > =A0* Multiple settlement path support > =A0* Optional support for in-band settlement (sometimes known as DVP) > =A0* High precision decimal value support > =A0* Arbitrary financial settlement topology support > =A0* Arbitrary communications topology support > > =A0Given this situation, it makes sense to propose a legacy-free, > =A0adequately extensible protocol for internet-based financial exchange. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D But here's what worries me (and, again, remember that I'm pushing back to probe for answers, not as a way of saying "no"): You're saying that you want to define a new application-layer protocol (I have no idea what "legacy-free" means) that handles the use cases you list. That seems like a very fine thing to want to do. It strikes me, though, that the denizens of the IETF know little to nothing about the needs of those applications and use cases, and that you're likely to encounter some or all of the following problems: - There will be many nuances, corner cases, and unrecognized underlying needs that will not be considered in the protocol design because you'll have a lot of protocol designers but not enough subject-matter experts. - You (plural, not you personally) will get very frustrated by people with experience developing things like LDAP and CoAP and SIP (and, worse, MPLS and BGP) poking and prodding and telling you that you have to do this and you can't do that. Some of it will be valuable input that you ought to get, but lots of it will be relevant marginally or not at all. - Because people don't know much about your field and your use cases, you will get a lot of people telling you what the working group charter has to look like, but then very, very few people participating in the working group, to the point where it will be hard to make real progress. The IETF works best when it looks at core Internet protocols and application protocols with broad applicability (such as SIP, HTTP, and CoAP) and those that apply to Internet-related functions (LDAP, SMTP, ALTO). Looking at the other side, if the IETF can do this, what you'll get is a bunch of people who know protocol design and can help you get it right, and who know how to secure Internet transactions. You definitely need that. Barry From sebastian.kaebisch.ext@siemens.com Fri Mar 9 07:06:02 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FEFD21F865D for ; Fri, 9 Mar 2012 07:06:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6YlhJ2YyycD for ; Fri, 9 Mar 2012 07:06:01 -0800 (PST) Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF7221F8637 for ; Fri, 9 Mar 2012 07:05:55 -0800 (PST) Received: from mail2.siemens.de (localhost [127.0.0.1]) by thoth.sbs.de (8.13.6/8.13.6) with ESMTP id q29F5r2n009458; Fri, 9 Mar 2012 16:05:54 +0100 Received: from DEMCHP99ET2MSX.ww902.siemens.net (demchp99et2msx.ww902.siemens.net [139.25.131.241]) by mail2.siemens.de (8.13.6/8.13.6) with ESMTP id q29F5rSx026553 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 Mar 2012 16:05:53 +0100 Received: from DEMCHP99E55MSX.ww902.siemens.net ([169.254.2.75]) by DEMCHP99ET2MSX.ww902.siemens.net ([139.25.131.241]) with mapi; Fri, 9 Mar 2012 16:05:53 +0100 From: "Kaebisch, Sebastian" To: "apps-discuss@ietf.org" Date: Fri, 9 Mar 2012 16:05:51 +0100 Thread-Topic: [apps-discuss] SenML Thread-Index: Acz3sZ2pCXNfVFEuSEmU74JtLAYX1QGVAcIQ Message-ID: <1CE2FB42E90B614C98BC172FAB12D4C002D50989C3@DEMCHP99E55MSX.ww902.siemens.net> References: <1CE2FB42E90B614C98BC172FAB12D4C002D3FCFF8A@DEMCHP99E55MSX.ww902.siemens.net> <52B10DF8-11D1-44FE-8A8B-184BB0AE12F2@sensinode.com> In-Reply-To: <52B10DF8-11D1-44FE-8A8B-184BB0AE12F2@sensinode.com> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [apps-discuss] SenML X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 09 Mar 2012 15:06:02 -0000 Hello all, as I already announced last week I would like to provide some improvements = of the SenML XSD that would optimize the EXI usage.=20 My proposed (major) changes are: 1) change all typed based "integer" elements to "int". An "integer" in the = XSD domain is much bigger as a "long". I assume, this was not the intention= .=20 2) instead of using a "float" value, I would recommend to use the "mantissa= " and "exponend" representation. A floating value is always a challenge for= constrained devices because of its inefficent processing. 3) use restriction definitions of strings (define maxLength or list all pos= sible values as enumeration). Especially using enumerations results in a sm= aller message size and avoids string comparison.=20 4) instead of using abbreviation of the element/attribute names I would def= ine the full name which makes life easer, e.g., when it comes to debugging = of SenML messages. This is one of the strength of EXI where the names of an= element/attribute do not effect the EXI message size. Further small proposals can be seen in the XSD below.=20 I would be happy about any feedback. If you have any questions, please do n= ot hesitate to contact me. Best regards Sebastian =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 =20 > -----Original Message----- > From: Zach Shelby [mailto:zach@sensinode.com] > Sent: Thursday, March 01, 2012 2:46 PM > To: Kaebisch, Sebastian > Cc: apps-discuss@ietf.org > Subject: Re: [apps-discuss] SenML >=20 > Hi Sebastian, >=20 > Your suggestions for optimizing the XSD for EXI use would be very welcome= . > Looking forward to it! >=20 > Thanks, > Zach >=20 > On Feb 29, 2012, at 6:26 PM, Kaebisch, Sebastian wrote: >=20 > > > > Hi all, > > > > I have some improvement suggestions concerning the XSD which is used fo= r > senML EXI coding. Right now, there are some types defined which are not > optimal for small embedded devices. E.g., attribute "t", "ut", and "ver" > are typed as "integer". I think, "int" will be enough in that context. > Furthermore, I would like to suggest to make some changes in the XSD > definitions (e.g., using enumerations) to make the EXI message instances > more compact. I will prepare an XSD proposal for the next week for furthe= r > discussions. > > > > Best regards > > Sebastian K=E4bisch > > > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss >=20 > -- > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://www.sensinode.com > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 From walter.stanish@gmail.com Fri Mar 9 07:31:33 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A948E21F86C6 for ; Fri, 9 Mar 2012 07:31:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.871 X-Spam-Level: X-Spam-Status: No, score=-2.871 tagged_above=-999 required=5 tests=[AWL=0.728, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ph7nLiyjw-zK for ; Fri, 9 Mar 2012 07:31:33 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 32A4021F86A0 for ; Fri, 9 Mar 2012 07:31:32 -0800 (PST) Received: by ghbg16 with SMTP id g16so1006554ghb.31 for ; Fri, 09 Mar 2012 07:31:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=KWeXCTXpUnzNGodC9jHKI9FcwnPFU0jZ/RuPckap+tM=; b=nq+CaGdgICA2DJuhl/R5l4s+rDeRLaqEvdXjym3RVhY5go8l3jLkVfig2neo34LAov 3PMEZXRe+oNVaqtEPvGzq/A5WbBqplEQhi4pqHG03BRxk3szG9ftXHEZcm6Q+nE9vJsc C8D/+XuBFCs1LgzM9/CFgP0KsJ1h62rPV2i+TS0hauoE2PUVp4tFk6xluZFW+C6PnLRH 8XzxmEx45IsjMrhvHTFEc8HKbzeMcMqt4iPQyMdfxVFtO0ztPP8rTXfoDTfZ0iUqlgLW 0nIhdsnKKpcrUj9t21NF1XZAZo2E8q+5peG/34qVhSyq+oTD06Y5EQJ6EGQwIB3D393G vK7A== MIME-Version: 1.0 Received: by 10.60.3.34 with SMTP id 2mr1051291oez.27.1331307091375; Fri, 09 Mar 2012 07:31:31 -0800 (PST) Received: by 10.60.149.225 with HTTP; Fri, 9 Mar 2012 07:31:31 -0800 (PST) In-Reply-To: References: <4F58D9F3.2000602@dcrocker.net> Date: Fri, 9 Mar 2012 22:31:31 +0700 Message-ID: From: Walter To: Barry Leiba Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Proposal for a Finance Area Mailing List X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 09 Mar 2012 15:31:33 -0000 > But here's what worries me (and, again, remember that I'm pushing back > to probe for answers, not as a way of saying "no"): OK. Thank you for your constructive response. > You're saying that you want to define a new application-layer protocol > (I have no idea what "legacy-free" means) that handles the use cases > you list. =A0That seems like a very fine thing to want to do. Great, and a fair enough point on semantics. > It strikes me, though, that the denizens of the IETF know little to > nothing about the needs of those applications and use cases, The proposal is made more in the spirit of establishing a mailing list to invite community participation from people with parts of said knowledge (as opposed to grabbing some people on an IETF list like this one and somehow cajoling them in to being motivated to study financial industry protocols and trends.) The impression right now is that the formal establishment of any IETF working group, BOF or such at some future point is an option but not a requirement. Therefore, right now we're just asking for a mailing list to gather people and ideas in one place. > and that > you're likely to encounter some or all of the following problems: > > - There will be many nuances, corner cases, and unrecognized > underlying needs that will not be considered in the protocol design > because you'll have a lot of protocol designers but not enough > subject-matter experts. This is a risk with any system, ie. not limited to the field of protocol design. There are proven ways to avoid such problems: (a) seek input from many parties (b) avoid non-critical assumptions within the design ("do one thing and do it well") (c) provide a means of extensibility that might in future be used to resolve nuances, corner cases and unrecognized underlying needs The current proposal for a mailing list is in fact made in support of method (a). > - You (plural, not you personally) will get very frustrated by people > with experience developing things like LDAP and CoAP and SIP (and, > worse, MPLS and BGP) poking and prodding and telling you that you have > to do this and you can't do that. =A0Some of it will be valuable input > that you ought to get, but lots of it will be relevant marginally or > not at all. The assumption has been that subject matter experts and finance oriented programmers recruited from communities like Bitcoin and Ripple are expected to be larger features within the mailing list than veteran protocol authors who may be largely or wholly unfamiliar with the specific area in question and whose input will be valued at a later stage. > - Because people don't know much about your field and your use cases, > you will get a lot of people telling you what the working group > charter has to look like, but then very, very few people participating > in the working group, to the point where it will be hard to make real > progress. This all sounds very much like: "Mailing list - low overhead. Working Group - high overhead." The present proposal is for the former, and for reasons similar to this. > The IETF works best when it looks at core Internet protocols and > application protocols with broad applicability (such as SIP, HTTP, and > CoAP) and those that apply to Internet-related functions (LDAP, SMTP, > ALTO). > > Looking at the other side, if the IETF can do this, what you'll get is > a bunch of people who know protocol design and can help you get it > right, and who know how to secure Internet transactions. =A0You > definitely need that. Perhaps the formalistic side of the IETF's grizzled core expertise might be more valuable when applied to, for example: (1) the design of bindings between a message oriented application layer financial transaction protocol that comes out of the mailing list in question (either formalized through a later formed BOF or WG, or not) and various available transports (as per JeffH's suggestion). (2) the design of optional security related extensions for the same Both of these areas strike me as best approached at some later stage, for example after discussions have occurred on the proposed list. Regards, Walter Stanish Payward, Inc. From dhc@dcrocker.net Fri Mar 9 07:58:50 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D356721F8575 for ; Fri, 9 Mar 2012 07:58:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.606 X-Spam-Level: X-Spam-Status: No, score=-6.606 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jfq-Dw-xAubs for ; Fri, 9 Mar 2012 07:58:50 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2EE9421F8573 for ; Fri, 9 Mar 2012 07:58:50 -0800 (PST) Received: from [192.168.1.11] (adsl-67-127-58-62.dsl.pltn13.pacbell.net [67.127.58.62]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q29Fwigi013418 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 9 Mar 2012 07:58:49 -0800 Message-ID: <4F5A28A4.8090208@dcrocker.net> Date: Fri, 09 Mar 2012 07:58:28 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20120309141747.82205.qmail@joyce.lan> In-Reply-To: <20120309141747.82205.qmail@joyce.lan> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 09 Mar 2012 07:58:50 -0800 (PST) Subject: Re: [apps-discuss] Proposal for a Finance Area Mailing List X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 15:58:51 -0000 On 3/9/2012 6:17 AM, John Levine wrote: >>> �Anyone likely to implement it? �The IETF has a well known >>> preference for running code. >> >> (One might wonder if such conflicts with the 'come with a problem >> rather than a solution' philosophy of the BOFs / mailing list >> proposals @ http://tools.ietf.org/html/rfc5434#page-2 ? Then again, >> one might try to focus on avoiding bureaucratic discussion >> entirely...) > > I'll take that as "no". expecting code to exist even before pre-standards work has been discussed seems a tad excessive. on the other hand, having a clear problem statement and clear statement of desired output -- or in the alternative, questions intended to produce those clear statements -- is more typical for pre-standards discussion lists. absent those, there is no substantive anchor for the discussions. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From stephen.farrell@cs.tcd.ie Fri Mar 9 08:00:28 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8A4121F86AB for ; Fri, 9 Mar 2012 08:00:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zFiHFlAtVcjp for ; Fri, 9 Mar 2012 07:59:55 -0800 (PST) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id CA9D721F85B6 for ; Fri, 9 Mar 2012 07:59:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 7B2D2171CBD; Fri, 9 Mar 2012 15:59:52 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1331308792; bh=qWyNh4i1zQ0mnr D7kf7VdSFQJtdoEeIwVkvXmVcJ2Mg=; b=MOPT2c8wd1AkKZbfwLBnW+MEIL7hoi TlQU56GehsNBpfqHzuY0qGwfuORlG463vv6caGCsvJfoDWquJ8zCZV18gi6A2xEn 9CIUxwLWFTd9fAJKJiF8sZuhaKRixtB/MHSDGVViK2HtAgVr7UL3ASmiwreym8Yn GwDPjWf/PzwdywbzjAXYjbPamkT+3VBhebGwkpyozndvspQoHzGa1g10aXLlTp6C 5fmjM+/Xn+qFk+Gy5SPGMd5pABgTncfKnHdnB06n/Mh3eBFLg+9ET6I7UeJq7Imm rNtFKepOJu3xYIyNsxpJ4l/+4As7Nj+4+PiapYAoXkvr7uheu3om9w1g== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id z2QvOrIt3b2A; Fri, 9 Mar 2012 15:59:52 +0000 (GMT) Received: from [192.168.1.37] (244-184.62-81.cust.bluewin.ch [81.62.184.244]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id C5A2C171CA0; Fri, 9 Mar 2012 15:59:51 +0000 (GMT) Message-ID: <4F5A28F7.7070809@cs.tcd.ie> Date: Fri, 09 Mar 2012 15:59:51 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Walter References: <4F58D9F3.2000602@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Barry Leiba , apps-discuss@ietf.org Subject: Re: [apps-discuss] Proposal for a Finance Area Mailing List X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 09 Mar 2012 16:00:28 -0000 On 03/09/2012 03:31 PM, Walter wrote: > > Perhaps the formalistic side of the IETF's grizzled core expertise > might be more valuable when applied to, for example: > (1) the design of bindings between a message oriented application > layer financial transaction protocol that comes out of the mailing > list in question (either formalized through a later formed BOF or WG, > or not) and various available transports (as per JeffH's suggestion). > (2) the design of optional security related extensions for the same > > Both of these areas strike me as best approached at some later stage, > for example after discussions have occurred on the proposed list. IMO "optional security extensions later" for this would be a bad, and in the IETF, unlikely, plan if it came to developing a protocol like this. I've no opinion on whether this ought be done, here or anywhere, but if done here, I do have an opinion on when security needs to be tackled. S From stpeter@stpeter.im Fri Mar 9 08:14:25 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EC8F21F86F0; Fri, 9 Mar 2012 08:14:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.731 X-Spam-Level: X-Spam-Status: No, score=-102.731 tagged_above=-999 required=5 tests=[AWL=-0.132, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sa97U+Dxj3cc; Fri, 9 Mar 2012 08:14:24 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id C33B621F86DA; Fri, 9 Mar 2012 08:14:24 -0800 (PST) Received: from squire.local (unknown [64.101.72.114]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 347BA4005B; Fri, 9 Mar 2012 09:26:30 -0700 (MST) Message-ID: <4F5A2C5F.6050405@stpeter.im> Date: Fri, 09 Mar 2012 09:14:23 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: dcrocker@bbiw.net References: <1331188315.87259.YahooMailNeo@web31816.mail.mud.yahoo.com> <4F58EBFA.7010904@stpeter.im> <4F58EFBF.8030908@dcrocker.net> <4F58F39A.9030401@stpeter.im> <11FF964F9FF3063DE7F98BDB@PST.JCK.COM> <4F5919EB.1080407@stpeter.im> <609BED83E23A6939F0C9CEC8@PST.JCK.COM> <4F59291C.5000008@dcrocker.net> <4F593F1E.1060204@stpeter.im> <4F59556A.8070806@dcrocker.net> In-Reply-To: <4F59556A.8070806@dcrocker.net> X-Enigmail-Version: 1.3.5 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org, draft-ietf-appsawg-xdash.all@tools.ietf.org, William Mills , The IESG Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-appswg-xdash-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 09 Mar 2012 16:14:25 -0000 On 3/8/12 5:57 PM, Dave Crocker wrote: > > > On 3/8/2012 3:22 PM, Peter Saint-Andre wrote: >> On 3/8/12 2:48 PM, Dave Crocker wrote: >>> What the community has learned or the thirty-or-so years of the >>> construct is that it's better to have a single, clean name space and >>> leave status of the name as a separate issue. >> >> Well put. >> >> Yet the inclusion of delimiters in parameter names could be construed as >> just another way segregating the namespace. So I think it might be best >> to remove the fourth bullet point in Section 4: >> >> 4. SHOULD identify a convention to allow local or implementation- >> specific extensions, and reserve delimeters for such uses as >> needed. > > > I think +1 Removed in our working copy. Peter -- Peter Saint-Andre https://stpeter.im/ From yusuke.doi@toshiba.co.jp Fri Mar 9 09:43:42 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F96621F8621 for ; Fri, 9 Mar 2012 09:43:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.924 X-Spam-Level: X-Spam-Status: No, score=-5.924 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MDZKLRKWlx2S for ; Fri, 9 Mar 2012 09:43:41 -0800 (PST) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by ietfa.amsl.com (Postfix) with ESMTP id F2B4221F85D5 for ; Fri, 9 Mar 2012 09:43:40 -0800 (PST) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id q29HhdtJ022964 for ; Sat, 10 Mar 2012 02:43:39 +0900 (JST) Received: (from root@localhost) by arc11.toshiba.co.jp id q29Hhd03016260 for apps-discuss@ietf.org; Sat, 10 Mar 2012 02:43:39 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id CAA16259; Sat, 10 Mar 2012 02:43:39 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id q29HhdYU015429 for ; Sat, 10 Mar 2012 02:43:39 +0900 (JST) Received: by toshiba.co.jp id q29HhNjp008152; Sat, 10 Mar 2012 02:43:23 +0900 (JST) Message-Id: <201203091743.q29HhNjp008152@toshiba.co.jp> Date: Sat, 10 Mar 2012 02:43:38 +0900 From: Yusuke DOI User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "Kaebisch, Sebastian" References: <1CE2FB42E90B614C98BC172FAB12D4C002D3FCFF8A@DEMCHP99E55MSX.ww902.siemens.net> <52B10DF8-11D1-44FE-8A8B-184BB0AE12F2@sensinode.com> <1CE2FB42E90B614C98BC172FAB12D4C002D50989C3@DEMCHP99E55MSX.ww902.siemens.net> In-Reply-To: <1CE2FB42E90B614C98BC172FAB12D4C002D50989C3@DEMCHP99E55MSX.ww902.siemens.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] SenML X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 09 Mar 2012 17:43:42 -0000 Dear Kaebisch, I have several comments. (2012/03/10 0:05), Kaebisch, Sebastian wrote: > 2) instead of using a "float" value, I would recommend to use the "mantissa" and "exponend" representation. A floating value is always a challenge for constrained devices because of its inefficent processing. I think float values in EXI is already mantissa and exponend (base 10). > 3) use restriction definitions of strings (define maxLength or list all possible values as enumeration). Especially using enumerations results in a smaller message size and avoids string comparison. Enumeration is good idea but I think strict enumeration allows no addition in future without breaking backword compatibility. I recommend some 'dummy entries' to make room (and show the limit to keep the same bitwidth clearly) for future. Yusuke From barryleiba.mailing.lists@gmail.com Fri Mar 9 10:42:29 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC4D321F873E for ; Fri, 9 Mar 2012 10:42:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.984 X-Spam-Level: X-Spam-Status: No, score=-102.984 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4qS7CmUFn7Q2 for ; Fri, 9 Mar 2012 10:42:29 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 516DA21F873D for ; Fri, 9 Mar 2012 10:42:29 -0800 (PST) Received: by ghbg16 with SMTP id g16so1155655ghb.31 for ; Fri, 09 Mar 2012 10:42:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=C9lhBNVKgBwL72DNF1EtvO8c/zr1I3POhaF5VUO+ap4=; b=KywNnrmpUIZAudqL5e3fUueBNHit50lKtBkqmMJNhW3h2jQTf/LR16kWQQHVi5/WHd 6yhE2PZPSAzyUSZ/Lo16pmv/HG41CuT6LSKSU24c67SjsfmspNGnrUwcxXctIrYl1pX/ jkoQEGne0xdstlBxkjDyVE6rE6MZsAwvjxev/+DUofM85TkAqtzNlkPvJQ4a+udVWP2f g7LB3sK+gOCnN2ee132RiavQnLrM0IDqSFI0N6tVwWPDqPKneG2N3mBVt7P4QlWR75Hp 28jghRZcuT3G4K6TROic1TpCOrunFYFj6iMxqp+EMA5c9HfHt2p3hPtQQBLTjPaKf00M nBhw== MIME-Version: 1.0 Received: by 10.236.195.37 with SMTP id o25mr3653438yhn.55.1331318548941; Fri, 09 Mar 2012 10:42:28 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.106.16 with HTTP; Fri, 9 Mar 2012 10:42:28 -0800 (PST) Date: Fri, 9 Mar 2012 13:42:28 -0500 X-Google-Sender-Auth: pAQE08_Rb57m6voATCDnJtTIFfk Message-ID: From: Barry Leiba To: "apps-discuss@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [apps-discuss] Working-group last call: draft-ietf-appsawg-greylisting-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 09 Mar 2012 18:42:30 -0000 > =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Email Greylisting: An Applicabili= ty Statement for SMTP > =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Murray S. Kucherawy > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 D. Crocker > =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-appsawg-greylisting-05.t= xt > =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 16 > =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-02-22 > > =A0 =A0This memo describes the art of email greylisting, the practice of > =A0 =A0providing temporarily degraded service to unknown email clients as= an > =A0 =A0anti-abuse mechanism. http://datatracker.ietf.org/drafts/draft-ietf-appsawg-greylisting There's been no comment on this document in the two weeks since it was posted, so this seems the right time to start a working-group last call on it. Therefore, working-group last call on draft-ietf-appsawg-greylisting-05 begins today, and ends on Friday, 23 Feb. Please file and final comments no later than that date -- and earlier is better. At this point in the document process, comments will be most useful if they're accompanied by a specific suggestion of text changes. Please consider that as you make your comments. Barry, appsawg chair From barryleiba.mailing.lists@gmail.com Fri Mar 9 10:43:59 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFEF721F8673 for ; Fri, 9 Mar 2012 10:43:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.984 X-Spam-Level: X-Spam-Status: No, score=-102.984 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EUZy+oYy3Hlj for ; Fri, 9 Mar 2012 10:43:59 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 42F6F21F8668 for ; Fri, 9 Mar 2012 10:43:59 -0800 (PST) Received: by ghbg16 with SMTP id g16so1156800ghb.31 for ; Fri, 09 Mar 2012 10:43:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=tVYXBGKKv9u4D/kwT2DwMmNiM5/X0818NILEfHxgG5U=; b=obzlcwbB8EjC0iraq94e2kpiRZY0ITK2aPa5e4LTye1jAbx39XTKeApyJzsdBq9k93 BVYrqLeCZ6KV8GWSwPMvGLyEJVks/Eq4klvp6+RPi1vHMCcFyqVIy/oWZFYLI8dO4HUq 1gA4COMkynFrZCdrzxosheQbctVxi6V+HfjjLzUNiqQUz/+rmcNQ7a2YSm5p53LmuI2O Yu1hKJJElFyyLtZh05PNRj4K2iX8IunyI5lLSBCQ0enzqi6JVAeJUuu8wO05FDQJrHG9 W5rLyWyWrQMWFvO13DoHl3sgBTu+eIMDWNKtVzUF43ijK0RRr6ygab1j+7BBwUNNXHna TOpg== MIME-Version: 1.0 Received: by 10.236.186.1 with SMTP id v1mr3862003yhm.4.1331318638869; Fri, 09 Mar 2012 10:43:58 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.106.16 with HTTP; Fri, 9 Mar 2012 10:43:58 -0800 (PST) In-Reply-To: References: Date: Fri, 9 Mar 2012 13:43:58 -0500 X-Google-Sender-Auth: dKELjZKwdeQ6HCGAAJ9WBvlTxoY Message-ID: From: Barry Leiba To: "apps-discuss@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [apps-discuss] Working-group last call: draft-ietf-appsawg-greylisting-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 09 Mar 2012 18:43:59 -0000 > draft-ietf-appsawg-greylisting-05 begins today, and ends on Friday, 23 > Feb. =A0Please file and final comments no later than that date -- and > earlier is better. Earlier is better, but in the past is not necessary. 23 March. Sorry. Barry From internet-drafts@ietf.org Fri Mar 9 13:18:34 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B79321E8083; Fri, 9 Mar 2012 13:18:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yWjEj81RM0Pe; Fri, 9 Mar 2012 13:18:33 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACCB021F85EA; Fri, 9 Mar 2012 13:18:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120309211833.15339.72914.idtracker@ietfa.amsl.com> Date: Fri, 09 Mar 2012 13:18:33 -0800 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-json-pointer-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 09 Mar 2012 21:18:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Worki= ng Group of the IETF. Title : JSON Pointer Author(s) : Paul C. Bryan Kris Zyp Filename : draft-ietf-appsawg-json-pointer-01.txt Pages : 7 Date : 2012-03-09 JSON Pointer defines a string syntax for identifying a specific value within a JSON document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-appsawg-json-pointer-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-appsawg-json-pointer-01.txt From internet-drafts@ietf.org Fri Mar 9 13:22:31 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E832821F86BA; Fri, 9 Mar 2012 13:22:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.546 X-Spam-Level: X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZe9aLWx3Z7D; Fri, 9 Mar 2012 13:22:31 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8421121F8675; Fri, 9 Mar 2012 13:22:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120309212231.16366.52439.idtracker@ietfa.amsl.com> Date: Fri, 09 Mar 2012 13:22:31 -0800 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-json-patch-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 09 Mar 2012 21:22:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Worki= ng Group of the IETF. Title : JSON Patch Author(s) : Paul C. Bryan Filename : draft-ietf-appsawg-json-patch-01.txt Pages : 12 Date : 2012-03-09 JSON Patch defines the media type "application/json-patch", a JSON document structure for expressing a sequence of operations to apply to a JSON document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-appsawg-json-patch-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-appsawg-json-patch-01.txt From walter.stanish@gmail.com Fri Mar 9 15:46:40 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3777C21E8018 for ; Fri, 9 Mar 2012 15:46:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.962 X-Spam-Level: X-Spam-Status: No, score=-2.962 tagged_above=-999 required=5 tests=[AWL=0.637, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y8L68sPeaaxJ for ; Fri, 9 Mar 2012 15:46:39 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1FB7521F8568 for ; Fri, 9 Mar 2012 15:46:25 -0800 (PST) Received: by yhpp34 with SMTP id p34so1440839yhp.31 for ; Fri, 09 Mar 2012 15:46:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=uckd8NJI/ZXXh1Pr+wxPrBUkjq2rCrF0BHufFfuqTpY=; b=xCacu1SKclD3iHEdHy036KDZdDfMMbyMFt2kHdks15PkiUzvCE9eJw1OhLORQIb5Fv t1A+y3insD8EHQDSTJK939wE5MvZ7jvFhxo/ADA15N4O5WqHQq63USk5CgW1mMgUwNWM xy3aNfBh4qozy9pY4fEj6Au65DF968wTJz1nogtMteQF9mClkAj4O2OWFe9cdK5zZ+Af G33Tw7izr8oxglom/txW/H2NRYf3omzNxxy8dyy14iSKhirCWk8OGrkW+vyqmlfsDzMJ +t5ky3jwaTqT4k16Z2WBnkSM9l/skeIq2EG8RlsQGjLDRq5ORFgtzfA6EHLRdInU9+rk N7yg== MIME-Version: 1.0 Received: by 10.60.18.137 with SMTP id w9mr870835oed.7.1331336783174; Fri, 09 Mar 2012 15:46:23 -0800 (PST) Received: by 10.60.149.225 with HTTP; Fri, 9 Mar 2012 15:46:23 -0800 (PST) In-Reply-To: <4F5A28F7.7070809@cs.tcd.ie> References: <4F58D9F3.2000602@dcrocker.net> <4F5A28F7.7070809@cs.tcd.ie> Date: Sat, 10 Mar 2012 06:46:23 +0700 Message-ID: From: Walter To: Stephen Farrell Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Barry Leiba , apps-discuss@ietf.org Subject: Re: [apps-discuss] Proposal for a Finance Area Mailing List X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 09 Mar 2012 23:46:40 -0000 >> Perhaps the formalistic side of the IETF's grizzled core expertise >> might be more valuable when applied to, for example: >> =A0(1) the design of bindings between a message oriented application >> layer financial transaction protocol that comes out of the mailing >> list in question (either formalized through a later formed BOF or WG, >> or not) and various available transports (as per JeffH's suggestion). >> =A0(2) the design of optional security related extensions for the same >> >> Both of these areas strike me as best approached at some later stage, >> for example after discussions have occurred on the proposed list. > > IMO "optional security extensions later" for this would be a bad, > and in the IETF, unlikely, plan if it came to developing a protocol > like this. > > I've no opinion on whether this ought be done, here or anywhere, > but if done here, I do have an opinion on when security needs to > be tackled. Fair concern. Let me explain the source of the comment. During research thus far it has been discovered that certain financial transaction systems are stupendously latency sensitive to the point where mandatory security processing is unacceptable. Thankfully, said systems may operate between known parties (even parties internal to one organization) via trusted transport and physical layers. This is not to say that more typical internet style approaches to protocol security would be ignored; far from it, they would be the norm rather than the exception. Simply in an effort to avoid additional assumptions within the design (see strategy (b), previous email), it is considered desirable to maintain the protocol's ability to switch off, or optionally delegate authentication and integrity services to lower network layers. Regards, Walter Stanish Payward, Inc. From Jeff.Hodges@KingsMountain.com Fri Mar 9 20:51:26 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B8A111E8076 for ; Fri, 9 Mar 2012 20:51:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.384 X-Spam-Level: X-Spam-Status: No, score=-99.384 tagged_above=-999 required=5 tests=[AWL=-0.378, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8m2KHSUUP9nr for ; Fri, 9 Mar 2012 20:51:25 -0800 (PST) Received: from oproxy6-pub.bluehost.com (oproxy6.bluehost.com [IPv6:2605:dc00:100:2::a6]) by ietfa.amsl.com (Postfix) with SMTP id 9046111E8073 for ; Fri, 9 Mar 2012 20:51:25 -0800 (PST) Received: (qmail 10706 invoked by uid 0); 10 Mar 2012 04:51:24 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy3.bluehost.com with SMTP; 10 Mar 2012 04:51:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=uGswf0jpthIN6PPADfgt3xwKMP7nZfYfmKfOgvrJbHY=; b=5h4U143Iqa6U3bdPc/pSRUewsHBkhMv2NH0sx2hCxJUGjk5ZQIEQu0mWMwyn7zntE5CBZIAbRHKVj4pwQOm5NGu3bBXxC+VlzSucJhu1KiCvCY1OX0ht2iJ+LoSMFnwY; Received: from c-24-4-122-173.hsd1.ca.comcast.net ([24.4.122.173] helo=[192.168.11.11]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1S6EH5-0001Tq-SS; Fri, 09 Mar 2012 21:51:23 -0700 Message-ID: <4F5ADDCA.80303@KingsMountain.com> Date: Fri, 09 Mar 2012 20:51:22 -0800 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: Walter Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 24.4.122.173 authed with jeff.hodges+kingsmountain.com} Cc: Apps Discuss Subject: Re: [apps-discuss] Proposal for a Finance Area Mailing List X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Mar 2012 04:51:26 -0000 > ============================================================ > Certain functionality required by modern financial systems is not > presently available in open, legacy-free, adequately globalized > protocols. > > This functionality includes: > * Settlement and reversal / cancellation term negotiation > * Exchange rate negotiation > * Latency calculation / negotiation > * Fee, tax and discount calculation / negotiation > * Arbitrary currency / asset support > * Multi-currency / asset transaction support > * Quotation support > * Multiple settlement path support > * Optional support for in-band settlement (sometimes known as DVP) > * High precision decimal value support > * Arbitrary financial settlement topology support > * Arbitrary communications topology support > > Given this situation, it makes sense to propose a legacy-free, > adequately extensible protocol for internet-based financial exchange. > ============================================================ All of the above are application-specific, and can be conveyed IMHO over existing specified protocols. So it isn't clear that the above /needs/ to be specified in the IETF. It can be done "anywhere". (and I've been directly involved in efforts that were defined "elsewhere" and were layered over IETF protocols) Again, the crux is whether you can get a critical mass of subject matter experts to convene wherever you decide to attempt to address the subject matter that concerns you. You ought to go ask them if they're interested in working in the IETF context to address the above. Perhaps allocating an IETF mailing list and seeing who shows up and what occurs is one way to do that. But as far as I can tell, those folks are not at this time active participants overall in the IETF. Tho, perhaps I'm wrong, I dunno. =JeffH ps: with respect to IANA, one does /NOT/ need to be affiliated with the IETF in order to register things with IANA. I know this from personal experience in that I wrote and shepherded the registrations for "application/samlassertion+xml" and "application/samlmetadata+xml" from the context of the OASIS Security Services Technical Committee (SSTC). From walter.stanish@gmail.com Sat Mar 10 04:22:48 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 030A521F84D7 for ; Sat, 10 Mar 2012 04:22:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_FWDLOOK=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oEP6B2ZeUefs for ; Sat, 10 Mar 2012 04:22:47 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id DB04A21F844B for ; Sat, 10 Mar 2012 04:22:46 -0800 (PST) Received: by iazz13 with SMTP id z13so4085015iaz.31 for ; Sat, 10 Mar 2012 04:22:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=oY53O1Xf2q9FsdQJLY/W3Y2njVhlm3C5ASTWZFhKEqc=; b=Mb8aIX737pmUryekw9irgLf7I0SyzbE8GvIekSenozDJv6VpEvNf8TYX/IFmEWS5JY qx3K7UyR98jROk/EAEGu9jzARdQcD1vHAQS8uT+LZgIv8sIawwKqzPoLrh0r3qRJM0k2 PtUJBnMSN7wHAl5rQS0TWuWPEGO3ApF7YattFykgQr5Np1YsgMqw0B+MpINKYJCIZSlL Y3dOrMwWIbFlB/uU94tbbnFIyApaWNmXxfY+Ffb2bitV+lav8PlYBEkL8duTdi2KPlSe kibtJAIY65toXkODx+RryUDXPuCdcOt8SiTk+xJoBmU71YSrxqukwHUyxRCZenkbsQo+ j2uQ== MIME-Version: 1.0 Received: by 10.182.86.197 with SMTP id r5mr2290091obz.7.1331382166353; Sat, 10 Mar 2012 04:22:46 -0800 (PST) Received: by 10.60.149.225 with HTTP; Sat, 10 Mar 2012 04:22:46 -0800 (PST) In-Reply-To: <4F5ADDCA.80303@KingsMountain.com> References: <4F5ADDCA.80303@KingsMountain.com> Date: Sat, 10 Mar 2012 19:22:46 +0700 Message-ID: From: Walter To: "=JeffH" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Apps Discuss Subject: Re: [apps-discuss] Proposal for a Finance Area Mailing List X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Mar 2012 12:22:48 -0000 > All of the above are application-specific, and can be conveyed IMHO over > existing specified protocols. That's true. However, taking that view purely you could similarly argue that almost everything is out of IETF scope because IPv4, TCP and UDP exist. Taking a broader view, one might argue that financial transfer is already a relatively common internet use case today, and could be reasonably likened to others such as email transfer, hypertext transfer, file transfer, instant message transfer, telephony, etc. Like those cases, it has its own specific needs and opportunities in terms of the potential for the open standardization of one or more protocols. Those needs deserve a forum for discussion, just as other use cases. > So it isn't clear that the above /needs/ to be specified in the IETF. It = can > be done "anywhere". =A0(and I've been directly involved in efforts that w= ere > defined "elsewhere" and were layered over IETF protocols) That's true: one could define anything anywhere. However, the request that IETF provides a forum for discussion and the potential development of open, forward-looking financial standards for the internet community is reasonable. Compare to the IETF's mission statement (http://tools.ietf.org/html/rfc4677= ): o Identifying, and proposing solutions to, pressing operational and technical problems in the Internet o Specifying the development or usage of protocols and the near-term architecture to solve such technical problems for the Internet o Making recommendations to the Internet Engineering Steering Group (IESG) regarding the standardization of protocols and protocol usage in the Internet o Facilitating technology transfer from the Internet Research Task Force (IRTF) to the wider Internet community o *Providing a forum for the exchange of information within the Internet community between vendors, users, researchers, agency contractors, and network managers* The final point does seem rather relevant with regards to the present reque= st. > Again, the crux is whether you can get a critical mass of subject matter > experts to convene wherever you decide to attempt to address the subject > matter that concerns you. It's very hard to draw attention to a forum for discussion before a that forum exists. > You ought to go ask them if they're interested in working in the IETF > context to address the above. Perhaps allocating an IETF mailing list and > seeing who shows up and what occurs is one way to do that. Nobody knows who will show up until we have a venue and make some noise about it. We are proposing the IETF host that venue in its capacity as a shepherd for the internet community. This seems to accord both with general expectations prior to contacting the IETF, and with its formal mission statement. Regards, Walter Stanish Payward, Inc. From klensin@jck.com Sat Mar 10 10:35:32 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46E8621F854B; Sat, 10 Mar 2012 10:35:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.622 X-Spam-Level: X-Spam-Status: No, score=-2.622 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dZDYxGNbewpp; Sat, 10 Mar 2012 10:35:31 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id B362321F8531; Sat, 10 Mar 2012 10:35:31 -0800 (PST) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1S6R3i-000EwO-SR; Sat, 10 Mar 2012 13:30:26 -0500 Date: Sat, 10 Mar 2012 13:35:03 -0500 From: John C Klensin To: Peter Saint-Andre , dcrocker@bbiw.net Message-ID: <62FF481C5AD21C3F683CD2B9@PST.JCK.COM> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: apps-discuss@ietf.org, draft-ietf-appsawg-xdash.all@tools.ietf.org, William Mills , The IESG Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-appswg-xdash-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Mar 2012 18:35:32 -0000 --On Thursday, March 08, 2012 16:22 -0700 Peter Saint-Andre wrote: >... >> The class is "names that are syntactically designed to be >> outside of standards space" because such names have a >> regularly tendency to become de facto standards, which makes >> formally standardizing them problematic. Agreed. >> This is true for "experimental" names, "vendor" names, and >> any other kind of non-standard name. The leap to "any other kind of non-standard name" doesn't follow. >> The premises behind the concern are a) registration is >> difficult, b) the name should flag the status. >> >> What the community has learned or the thirty-or-so years of >> the construct is that it's better to have a single, clean >> name space and leave status of the name as a separate issue. > > Well put. > > Yet the inclusion of delimiters in parameter names could be > construed as just another way segregating the namespace. So I > think it might be best to remove the fourth bullet point in > Section 4: > > 4. SHOULD identify a convention to allow local or > implementation- specific extensions, and reserve > delimeters for such uses as needed. I admit I found that bullet point confusing. However, an interpretation of Dave's statement could extend to a prohibition, not only on faceted or hierarchical names but on the "+xml" arrangements and the like that we've used in media types. I would encourage you to go even further than simply removing that bullet point: stick to "X-" parameters and field names and to "X" commands in this document and let the other naming and registry issues get sorted out elsewhere. The cost of overreaching into very broad statements could be to create a situation in which all of those other arguments need to be sorted out twice or, perhaps worse, blocking this until all of the registration strategy arguments are settled. john p.s. Dave, apologies for forgetting that "extension" was used in 822. I obviously didn't go back and look. From dhc@dcrocker.net Sat Mar 10 10:40:15 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D09BB21F84FE; Sat, 10 Mar 2012 10:40:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.606 X-Spam-Level: X-Spam-Status: No, score=-6.606 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P+gk7DAd8EGZ; Sat, 10 Mar 2012 10:40:15 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0C77121F84FA; Sat, 10 Mar 2012 10:40:15 -0800 (PST) Received: from [192.168.1.11] (adsl-67-127-58-62.dsl.pltn13.pacbell.net [67.127.58.62]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q2AIe7km011677 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 10 Mar 2012 10:40:13 -0800 Message-ID: <4F5B9FF5.7040209@dcrocker.net> Date: Sat, 10 Mar 2012 10:39:49 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: John C Klensin References: <62FF481C5AD21C3F683CD2B9@PST.JCK.COM> In-Reply-To: <62FF481C5AD21C3F683CD2B9@PST.JCK.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sat, 10 Mar 2012 10:40:13 -0800 (PST) Cc: draft-ietf-appsawg-xdash.all@tools.ietf.org, apps-discuss@ietf.org, The IESG Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-appswg-xdash-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 18:40:15 -0000 On 3/10/2012 10:35 AM, John C Klensin wrote: > However, an > interpretation of Dave's statement could extend to a > prohibition, not only on faceted or hierarchical names but on > the "+xml" arrangements and the like that we've used in media > types. Unless I've entirely misunderstood the use of that qualifier, it indicates an encoding framework for the labeled data, not it's 'status'. As such it would seem irrelevant to the current topic. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From presnick@qualcomm.com Sat Mar 10 10:48:49 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B60121F854B; Sat, 10 Mar 2012 10:48:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.567 X-Spam-Level: X-Spam-Status: No, score=-106.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L9sZ-mOsl8JJ; Sat, 10 Mar 2012 10:48:48 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 94BF321F8531; Sat, 10 Mar 2012 10:48:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1331405328; x=1362941328; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-originating-ip; z=Message-ID:=20<4F5BA20D.30304@qualcomm.com>|Date:=20Sat, =2010=20Mar=202012=2012:48:45=20-0600|From:=20Pete=20Resn ick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20|CC:=20Dave =20Crocker=20,=20John=20C=20Klensin=20< klensin@jck.com>,=0D=0A=09,=20Martin=20Thomson=0D=0A=09,=20,=20Peter=20Saint- Andre=0D=0A=09,=20The=20IESG=20|Subject:=20Re:=20[apps-discuss]=20APPSDIR=20rev iew=20of=20draft-ietf-appswg-xdash-03|References:=20<62FF 481C5AD21C3F683CD2B9@PST.JCK.COM>=20<4F5B9FF5.7040209@dcr ocker.net>|In-Reply-To:=20<4F5B9FF5.7040209@dcrocker.net> |Content-Type:=20text/plain=3B=20charset=3D"ISO-8859-1" =3B=20format=3Dflowed|Content-Transfer-Encoding:=207bit |X-Originating-IP:=20[172.30.39.5]; bh=ynlefFmslbDnZkVYT4F23Ih5cCeKIY9LRkS+WhN6dhY=; b=baoWJtBlXLiwovnFKO7JkrKvHb5sXtuGOhSp8ZiMxCxS4TYKenEUFB/z OKjuBzW/baQrGA00vQKWrQdKMXm0UhE+Dpp2oN0qVvMX7glebsvRlab5a 1lYyeIOCin/4qZDXUzUAgZ0S22OhV6gg323FJFuP7Xkm8sZvGdnM0U49k A=; X-IronPort-AV: E=McAfee;i="5400,1158,6645"; a="171360021" Received: from ironmsg02-l.qualcomm.com ([172.30.48.16]) by wolverine01.qualcomm.com with ESMTP; 10 Mar 2012 10:48:47 -0800 X-IronPort-AV: E=Sophos;i="4.73,563,1325491200"; d="scan'208";a="119652692" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by ironmsg02-L.qualcomm.com with ESMTP/TLS/AES128-SHA; 10 Mar 2012 10:48:47 -0800 Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.1.339.1; Sat, 10 Mar 2012 10:48:47 -0800 Message-ID: <4F5BA20D.30304@qualcomm.com> Date: Sat, 10 Mar 2012 12:48:45 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: References: <62FF481C5AD21C3F683CD2B9@PST.JCK.COM> <4F5B9FF5.7040209@dcrocker.net> In-Reply-To: <4F5B9FF5.7040209@dcrocker.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] Cc: apps-discuss@ietf.org, draft-ietf-appsawg-xdash.all@tools.ietf.org, John C Klensin , The IESG Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-appswg-xdash-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 10 Mar 2012 18:48:49 -0000 On 3/10/12 12:39 PM, Dave Crocker wrote: > On 3/10/2012 10:35 AM, John C Klensin wrote: >> However, an >> interpretation of Dave's statement could extend to a >> prohibition, not only on faceted or hierarchical names but on >> the "+xml" arrangements and the like that we've used in media >> types. > > Unless I've entirely misunderstood the use of that qualifier, it > indicates an encoding framework for the labeled data, not it's 'status'. Ah! That would be a lovely distinction to make in the introduction in so many words: It's when a piece of the name is used to indicate a *status* rather than a *type* that presents the problem. That would be a great clarification. pr -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From klensin@jck.com Sat Mar 10 19:24:41 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D34221F85A0; Sat, 10 Mar 2012 19:24:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.622 X-Spam-Level: X-Spam-Status: No, score=-2.622 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vnokaOABpLSl; Sat, 10 Mar 2012 19:24:40 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id B945F21F84F1; Sat, 10 Mar 2012 19:24:14 -0800 (PST) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1S6ZJS-000FcE-TP; Sat, 10 Mar 2012 22:19:14 -0500 Date: Sat, 10 Mar 2012 22:23:51 -0500 From: John C Klensin To: Pete Resnick , dcrocker@bbiw.net Message-ID: In-Reply-To: <4F5BA20D.30304@qualcomm.com> References: <62FF481C5AD21C3F683CD2B9@PST.JCK.COM> <4F5B9FF5.7040209@dcrocker.net> <4F5BA20D.30304@qualcomm.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: apps-discuss@ietf.org, draft-ietf-appsawg-xdash.all@tools.ietf.org, The IESG Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-appswg-xdash-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 11 Mar 2012 03:24:41 -0000 --On Saturday, March 10, 2012 12:48 -0600 Pete Resnick wrote: > On 3/10/12 12:39 PM, Dave Crocker wrote: > >> On 3/10/2012 10:35 AM, John C Klensin wrote: >>> However, an >>> interpretation of Dave's statement could extend to a >>> prohibition, not only on faceted or hierarchical names but on >>> the "+xml" arrangements and the like that we've used in media >>> types. >> >> Unless I've entirely misunderstood the use of that qualifier, >> it indicates an encoding framework for the labeled data, not >> it's 'status'. > > Ah! That would be a lovely distinction to make in the > introduction in so many words: It's when a piece of the name > is used to indicate a *status* rather than a *type* that > presents the problem. That would be a great clarification. Sure. Except that, while "experimental" or "private use" are examples of "status", "extension" is a type. And that, I believe, takes us back to square one. john From dhc@dcrocker.net Sat Mar 10 19:32:56 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B322521F85AE; Sat, 10 Mar 2012 19:32:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.605 X-Spam-Level: X-Spam-Status: No, score=-6.605 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dKeJcVWZMeah; Sat, 10 Mar 2012 19:32:56 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1963821F855F; Sat, 10 Mar 2012 19:32:56 -0800 (PST) Received: from [192.168.1.11] (adsl-67-127-58-62.dsl.pltn13.pacbell.net [67.127.58.62]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q2B3WnEV019416 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 10 Mar 2012 19:32:54 -0800 Message-ID: <4F5C1CCE.6020706@dcrocker.net> Date: Sat, 10 Mar 2012 19:32:30 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: John C Klensin References: <62FF481C5AD21C3F683CD2B9@PST.JCK.COM> <4F5B9FF5.7040209@dcrocker.net> <4F5BA20D.30304@qualcomm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sat, 10 Mar 2012 19:32:55 -0800 (PST) Cc: draft-ietf-appsawg-xdash.all@tools.ietf.org, apps-discuss@ietf.org, The IESG Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-appswg-xdash-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 03:32:56 -0000 On 3/10/2012 7:23 PM, John C Klensin wrote: > Sure. Except that, while "experimental" or "private use" are > examples of "status", "extension" is a type. And that, I > believe, takes us back to square one. 1. It's not a type. 2. This isn't an exercise in semantics. The document describes what it is targeting in pretty plain language. The added clarification that Pete has suggested ought to make the language even more plain. In any event, I've no idea what concern it is that you have. Perhaps you can state, in simple terms, exactly what problem passage of this document causes or what benefit exists in retaining the convention of distinguishing X- prefixes, and the like? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From presnick@qualcomm.com Sat Mar 10 19:33:41 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0E6521F8467; Sat, 10 Mar 2012 19:33:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.567 X-Spam-Level: X-Spam-Status: No, score=-106.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OSJ7ASErtsg8; Sat, 10 Mar 2012 19:33:40 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 3038621F844A; Sat, 10 Mar 2012 19:33:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1331436820; x=1362972820; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-originating-ip; z=Message-ID:=20<4F5C1D10.8050305@qualcomm.com>|Date:=20Sa t,=2010=20Mar=202012=2021:33:36=20-0600|From:=20Pete=20Re snick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20John=20C=20Klensin=20|CC:=20,=20Dave=20Crocker=20,=0D=0A=09,=20,=20The=0D=0A=20 IESG=20,=20Peter=20Saint-Andre=20,=20Martin=20Thomson=0D=0A=09|Subject:=20Re:=20[apps-discuss]=20APPSDIR=20rev iew=20of=20draft-ietf-appswg-xdash-03|References:=20<62FF 481C5AD21C3F683CD2B9@PST.JCK.COM>=09<4F5B9FF5.7040209@dcr ocker.net>=20<4F5BA20D.30304@qualcomm.com>=20|In-Reply-To:=20|Content-Type:=20text/plain=3B=20c harset=3D"ISO-8859-1"=3B=20format=3Dflowed |Content-Transfer-Encoding:=207bit|X-Originating-IP:=20[1 72.30.48.1]; bh=5vw5hDQS6JX2mh9JJajNHBDnXU6TeQj8NvA/6cOYgHY=; b=oItPr4hPFWpJ/JJZMa3SMqBAfv7bww2E398SQyiA7qZ5Gq5LxpPlvN/I hsZIc6yTKClXHC5JIyjYaJqhGyjoBP482KXJzRsKfegwp4fI1CKYocI6n r4wUqTiY/cg/AjfwYTEhiTQUpcS+a/IhKhpJGNM7XzJPXulr8MH75nTp9 Q=; X-IronPort-AV: E=McAfee;i="5400,1158,6645"; a="169097976" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine02.qualcomm.com with ESMTP; 10 Mar 2012 19:33:39 -0800 X-IronPort-AV: E=Sophos;i="4.73,563,1325491200"; d="scan'208";a="281614491" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 10 Mar 2012 19:33:39 -0800 Received: from resnick2.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.1.339.1; Sat, 10 Mar 2012 19:33:39 -0800 Message-ID: <4F5C1D10.8050305@qualcomm.com> Date: Sat, 10 Mar 2012 21:33:36 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: John C Klensin References: <62FF481C5AD21C3F683CD2B9@PST.JCK.COM> <4F5B9FF5.7040209@dcrocker.net> <4F5BA20D.30304@qualcomm.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Cc: apps-discuss@ietf.org, draft-ietf-appsawg-xdash.all@tools.ietf.org, dcrocker@bbiw.net, The IESG Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-appswg-xdash-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 11 Mar 2012 03:33:41 -0000 On 3/10/12 9:23 PM, John C Klensin wrote: > > --On Saturday, March 10, 2012 12:48 -0600 Pete Resnick > wrote: > > >> On 3/10/12 12:39 PM, Dave Crocker wrote: >> >> >>> On 3/10/2012 10:35 AM, John C Klensin wrote: >>> >>>> However, an >>>> interpretation of Dave's statement could extend to a >>>> prohibition, not only on faceted or hierarchical names but on >>>> the "+xml" arrangements and the like that we've used in media >>>> types. >>>> >>> Unless I've entirely misunderstood the use of that qualifier, >>> it indicates an encoding framework for the labeled data, not >>> it's 'status'. >>> >> Ah! That would be a lovely distinction to make in the >> introduction in so many words: It's when a piece of the name >> is used to indicate a *status* rather than a *type* that >> presents the problem. That would be a great clarification. >> > Sure. Except that, while "experimental" or "private use" are > examples of "status", "extension" is a type. And that, I > believe, takes us back to square one. > No, you've misunderstood my distinction, which means we haven't gotten the wording quite right. When I said "type", I meant "type of *content* being named". So, "+xml" is indicating a "type" of data or content. "Extension" is a status. It's how the *name* is being used, not what the *content* is. pr -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From dhc@dcrocker.net Sat Mar 10 19:37:56 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6FB921F85AF; Sat, 10 Mar 2012 19:37:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.959 X-Spam-Level: X-Spam-Status: No, score=-5.959 tagged_above=-999 required=5 tests=[AWL=-0.652, BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1wGRDMn1Tscv; Sat, 10 Mar 2012 19:37:55 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id C0A5221F85AE; Sat, 10 Mar 2012 19:37:55 -0800 (PST) Received: from [192.168.1.11] (adsl-67-127-58-62.dsl.pltn13.pacbell.net [67.127.58.62]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q2B3bmOf019525 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 10 Mar 2012 19:37:54 -0800 Message-ID: <4F5C1DF9.2060703@dcrocker.net> Date: Sat, 10 Mar 2012 19:37:29 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 References: <62FF481C5AD21C3F683CD2B9@PST.JCK.COM> <4F5B9FF5.7040209@dcrocker.net> <4F5BA20D.30304@qualcomm.com> <4F5C1D10.8050305@qualcomm.com> In-Reply-To: <4F5C1D10.8050305@qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sat, 10 Mar 2012 19:37:54 -0800 (PST) Cc: draft-ietf-appsawg-xdash.all@tools.ietf.org, The IESG , apps-discuss@ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-appswg-xdash-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 03:37:56 -0000 On 3/10/2012 7:33 PM, Pete Resnick wrote: > No, you've misunderstood my distinction, which means we haven't gotten the > wording quite right. When I said "type", I meant "type of *content* being > named". So, "+xml" is indicating a "type" of data or content. "Extension" is a > status. It's how the *name* is being used, not what the *content* is. +1 d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From presnick@qualcomm.com Sat Mar 10 19:38:06 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8430321F85EA; Sat, 10 Mar 2012 19:38:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.567 X-Spam-Level: X-Spam-Status: No, score=-106.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id deN-CIUTRBag; Sat, 10 Mar 2012 19:38:06 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id E3BC821F85AE; Sat, 10 Mar 2012 19:38:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1331437085; x=1362973085; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-originating-ip; z=Message-ID:=20<4F5C1E10.6000909@qualcomm.com>|Date:=20Sa t,=2010=20Mar=202012=2021:37:52=20-0600|From:=20Pete=20Re snick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20|CC:=20Dave =20Crocker=20,=20John=20C=20Klensin=20< klensin@jck.com>,=0D=0A=09,=20Peter=20Saint-Andre=0D=0A=09,=20,=20The=20IESG=20|Subject:=20Re:=20[apps-discuss]=20APPSDIR=20r eview=20of=20draft-ietf-appswg-xdash-03|References:=20<62 FF481C5AD21C3F683CD2B9@PST.JCK.COM>=09<4F5B9FF5.7040209@d crocker.net>=20<4F5BA20D.30304@qualcomm.com>=09=20<4F5C1CCE.6020706@dcrocker .net>|In-Reply-To:=20<4F5C1CCE.6020706@dcrocker.net> |Content-Type:=20text/plain=3B=20charset=3D"ISO-8859-1" =3B=20format=3Dflowed|Content-Transfer-Encoding:=207bit |X-Originating-IP:=20[172.30.48.1]; bh=XDmH0IKgNwx5qwM1OSvm+TSJkGKmdbFjvyYaTNap9SQ=; b=IN3fA/oTPjqXKM4TSOguIT1kBtLra3q2ZbOIprCHqXBg4QLy5lg8wgGQ 6RkMJrmm1DcoZY2Ei6EdeJfFG5P65y1gAdr04Qt26ULOWEhc8hELtrZwE TH7AYPJWyK61vg0stnij+ROxzChW/6gekM/f/pUcaeKgzj0UoueQeouUx A=; X-IronPort-AV: E=McAfee;i="5400,1158,6645"; a="169098226" Received: from ironmsg02-r.qualcomm.com ([172.30.46.16]) by wolverine02.qualcomm.com with ESMTP; 10 Mar 2012 19:37:54 -0800 X-IronPort-AV: E=Sophos;i="4.73,565,1325491200"; d="scan'208";a="157871672" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by ironmsg02-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 10 Mar 2012 19:37:54 -0800 Received: from resnick2.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.1.339.1; Sat, 10 Mar 2012 19:37:54 -0800 Message-ID: <4F5C1E10.6000909@qualcomm.com> Date: Sat, 10 Mar 2012 21:37:52 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: References: <62FF481C5AD21C3F683CD2B9@PST.JCK.COM> <4F5B9FF5.7040209@dcrocker.net> <4F5BA20D.30304@qualcomm.com> <4F5C1CCE.6020706@dcrocker.net> In-Reply-To: <4F5C1CCE.6020706@dcrocker.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Cc: apps-discuss@ietf.org, draft-ietf-appsawg-xdash.all@tools.ietf.org, John C Klensin , The IESG Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-appswg-xdash-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 11 Mar 2012 03:38:06 -0000 On 3/10/12 9:32 PM, Dave Crocker wrote: > Perhaps you can state, in simple terms, exactly what problem passage > of this document causes or what benefit exists in retaining the > convention of distinguishing X- prefixes, and the like? Perhaps you can indentify the particular word in John's message you didn't understand. Oh, you mean....nevermind. (Sometimes the forms of queries are attacking and are therefore not useful to bringing a conversation to a good conclusion.) (*grumble*) pr -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From presnick@qualcomm.com Sat Mar 10 19:38:59 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BAF521F848B; Sat, 10 Mar 2012 19:38:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.568 X-Spam-Level: X-Spam-Status: No, score=-106.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x5hnsEd+WORs; Sat, 10 Mar 2012 19:38:59 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 108DE21F846A; Sat, 10 Mar 2012 19:38:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1331437139; x=1362973139; h=message-id:date:from:user-agent:mime-version:to:cc: subject:x-priority:references:in-reply-to:content-type: content-transfer-encoding:x-originating-ip; z=Message-ID:=20<4F5C1E4F.8010507@qualcomm.com>|Date:=20Sa t,=2010=20Mar=202012=2021:38:55=20-0600|From:=20Pete=20Re snick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20Pete=20Resnick=20|CC:=20,=20Dave=20Crocker=20 ,=20John=20C=20Klensin=0D=0A=09,=20,=20Peter=0D=0A=20Saint-Andre=20,=20 ,=20The=20IESG=0D=0A=09|Subject:=20Re:=20[apps-discuss]=20APPSDIR=20review =20of=20draft-ietf-appswg-xdash-03|X-Priority:=201=20(Hig hest)|References:=20<62FF481C5AD21C3F683CD2B9@PST.JCK.COM >=09<4F5B9FF5.7040209@dcrocker.net>=20<4F5BA20D.30304@qua lcomm.com>=09=20<4F 5C1CCE.6020706@dcrocker.net>=20<4F5C1E10.6000909@qualcomm .com>|In-Reply-To:=20<4F5C1E10.6000909@qualcomm.com> |Content-Type:=20text/plain=3B=20charset=3D"ISO-8859-1" =3B=20format=3Dflowed|Content-Transfer-Encoding:=207bit |X-Originating-IP:=20[172.30.48.1]; bh=GAvr9leylIij/j56r2lfRCtMeeQLsPHkqEbmln12JRk=; b=l4zgIGBQxiNoGVFDP7vdBtD4AfQcQe/YD2kW+iaDSZ5WvAr6x5Y4DJfC 7Xd+70N2fVqpylrInvPrEDpP0sXr73VnWostrko/nPzDNE4/rklVZHj8j VIgrRpyLJWkhzcY2VmMiT6qd9g7Kal4LRc/k7yWTXNY3/RekMjGE8zFf7 I=; X-IronPort-AV: E=McAfee;i="5400,1158,6645"; a="169098270" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine02.qualcomm.com with ESMTP; 10 Mar 2012 19:38:58 -0800 X-IronPort-AV: E=Sophos;i="4.73,563,1325491200"; d="scan'208";a="217017195" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 10 Mar 2012 19:38:58 -0800 Received: from resnick2.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.1.339.1; Sat, 10 Mar 2012 19:38:58 -0800 Message-ID: <4F5C1E4F.8010507@qualcomm.com> Date: Sat, 10 Mar 2012 21:38:55 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Pete Resnick X-Priority: 1 (Highest) References: <62FF481C5AD21C3F683CD2B9@PST.JCK.COM> <4F5B9FF5.7040209@dcrocker.net> <4F5BA20D.30304@qualcomm.com> <4F5C1CCE.6020706@dcrocker.net> <4F5C1E10.6000909@qualcomm.com> In-Reply-To: <4F5C1E10.6000909@qualcomm.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Cc: apps-discuss@ietf.org, draft-ietf-appsawg-xdash.all@tools.ietf.org, John C Klensin , dcrocker@bbiw.net, The IESG Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-appswg-xdash-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 11 Mar 2012 03:38:59 -0000 On 3/10/12 9:37 PM, Pete Resnick wrote: (Something obnoxious) I'm VERY sorry. Accidental reply all. Damn. pr -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From john-ietf@jck.com Sat Mar 10 19:40:34 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18F0321F848C; Sat, 10 Mar 2012 19:40:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.805 X-Spam-Level: X-Spam-Status: No, score=-102.805 tagged_above=-999 required=5 tests=[AWL=-0.206, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7tLrEScrbBzy; Sat, 10 Mar 2012 19:40:33 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 913EB21F848B; Sat, 10 Mar 2012 19:40:33 -0800 (PST) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1S6ZZN-000Fdl-Fq; Sat, 10 Mar 2012 22:35:41 -0500 Date: Sat, 10 Mar 2012 22:40:18 -0500 From: John C Klensin To: Pete Resnick Message-ID: In-Reply-To: <4F5C1D10.8050305@qualcomm.com> References: <62FF481C5AD21C3F683CD2B9@PST.JCK.COM> <4F5B9FF5.7040209@dcrocker.net> <4F5BA20D.30304@qualcomm.com> <4F5C1D10.8050305@qualcomm.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: apps-discuss@ietf.org, draft-ietf-appsawg-xdash.all@tools.ietf.org, dcrocker@bbiw.net, The IESG Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-appswg-xdash-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 11 Mar 2012 03:40:34 -0000 --On Saturday, March 10, 2012 21:33 -0600 Pete Resnick wrote: >> Sure. Except that, while "experimental" or "private use" are >> examples of "status", "extension" is a type. And that, I >> believe, takes us back to square one. >> > > No, you've misunderstood my distinction, which means we > haven't gotten the wording quite right. When I said "type", I > meant "type of *content* being named". So, "+xml" is > indicating a "type" of data or content. "Extension" is a > status. It's how the *name* is being used, not what the > *content* is. I can buy that, but I don't think the terminology is clear. john From dhc@dcrocker.net Sat Mar 10 19:42:15 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C27B921F85D7; Sat, 10 Mar 2012 19:42:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.596 X-Spam-Level: X-Spam-Status: No, score=-6.596 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id llvADsYJpkn0; Sat, 10 Mar 2012 19:42:15 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 410A421F84A5; Sat, 10 Mar 2012 19:42:15 -0800 (PST) Received: from [192.168.1.11] (adsl-67-127-58-62.dsl.pltn13.pacbell.net [67.127.58.62]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q2B3g94H019693 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 10 Mar 2012 19:42:14 -0800 Message-ID: <4F5C1EFE.4070301@dcrocker.net> Date: Sat, 10 Mar 2012 19:41:50 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Pete Resnick References: <62FF481C5AD21C3F683CD2B9@PST.JCK.COM> <4F5B9FF5.7040209@dcrocker.net> <4F5BA20D.30304@qualcomm.com> <4F5C1CCE.6020706@dcrocker.net> <4F5C1E10.6000909@qualcomm.com> In-Reply-To: <4F5C1E10.6000909@qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sat, 10 Mar 2012 19:42:14 -0800 (PST) Cc: apps-discuss@ietf.org, draft-ietf-appsawg-xdash.all@tools.ietf.org, John C Klensin , dcrocker@bbiw.net, The IESG Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-appswg-xdash-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 03:42:15 -0000 On 3/10/2012 7:37 PM, Pete Resnick wrote: > (Sometimes the forms of queries are attacking and are therefore not useful to > bringing a conversation to a good conclusion.) indeed sometimes they are. this wasn't one of them. for the life of me, I can't figure out what John's substantive concern is with the document being considered. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dhc@dcrocker.net Sat Mar 10 19:46:50 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB79521F85D2; Sat, 10 Mar 2012 19:46:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.596 X-Spam-Level: X-Spam-Status: No, score=-6.596 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yakKfWVWOwAh; Sat, 10 Mar 2012 19:46:49 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 851F221F85F3; Sat, 10 Mar 2012 19:46:49 -0800 (PST) Received: from [192.168.1.11] (adsl-67-127-58-62.dsl.pltn13.pacbell.net [67.127.58.62]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q2B3khs2019782 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 10 Mar 2012 19:46:48 -0800 Message-ID: <4F5C2010.7020302@dcrocker.net> Date: Sat, 10 Mar 2012 19:46:24 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Pete Resnick References: <62FF481C5AD21C3F683CD2B9@PST.JCK.COM> <4F5B9FF5.7040209@dcrocker.net> <4F5BA20D.30304@qualcomm.com> <4F5C1CCE.6020706@dcrocker.net> <4F5C1E10.6000909@qualcomm.com> <4F5C1E4F.8010507@qualcomm.com> In-Reply-To: <4F5C1E4F.8010507@qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sat, 10 Mar 2012 19:46:49 -0800 (PST) Cc: apps-discuss@ietf.org, draft-ietf-appsawg-xdash.all@tools.ietf.org, John C Klensin , dcrocker@bbiw.net, The IESG Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-appswg-xdash-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 03:46:51 -0000 On 3/10/2012 7:38 PM, Pete Resnick wrote: > On 3/10/12 9:37 PM, Pete Resnick wrote: > > (Something obnoxious) > > I'm VERY sorry. Accidental reply all. First email system I built defaulted to reply all. Head of the Army Materiel Command was one of the earliest users and provided a similar demonstration of why it's a really, really bad default. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From stpeter@stpeter.im Sat Mar 10 19:48:38 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6051A21F84CF; Sat, 10 Mar 2012 19:48:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.591 X-Spam-Level: X-Spam-Status: No, score=-102.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Eoo5RZNNxVr; Sat, 10 Mar 2012 19:48:38 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id ECFA621F85F3; Sat, 10 Mar 2012 19:48:37 -0800 (PST) Received: from squire.local (unknown [216.17.175.160]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 1666C4005B; Sat, 10 Mar 2012 21:00:48 -0700 (MST) Message-ID: <4F5C2084.5020104@stpeter.im> Date: Sat, 10 Mar 2012 20:48:20 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: dcrocker@bbiw.net References: <62FF481C5AD21C3F683CD2B9@PST.JCK.COM> <4F5B9FF5.7040209@dcrocker.net> <4F5BA20D.30304@qualcomm.com> <4F5C1CCE.6020706@dcrocker.net> <4F5C1E10.6000909@qualcomm.com> <4F5C1E4F.8010507@qualcomm.com> <4F5C2010.7020302@dcrocker.net> In-Reply-To: <4F5C2010.7020302@dcrocker.net> X-Enigmail-Version: 1.3.5 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org, draft-ietf-appsawg-xdash.all@tools.ietf.org, John C Klensin , The IESG , Pete Resnick Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-appswg-xdash-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 11 Mar 2012 03:48:38 -0000 On 3/10/12 8:46 PM, Dave Crocker wrote: > > > On 3/10/2012 7:38 PM, Pete Resnick wrote: >> On 3/10/12 9:37 PM, Pete Resnick wrote: >> >> (Something obnoxious) >> >> I'm VERY sorry. Accidental reply all. > > > First email system I built defaulted to reply all. Head of the Army > Materiel Command was one of the earliest users and provided a similar > demonstration of why it's a really, really bad default. Hey, would you guys stop sending all these messages on a Saturday night? I'm trying to write an Internet-Draft... :P From presnick@qualcomm.com Sat Mar 10 20:00:53 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A625321F8607; Sat, 10 Mar 2012 20:00:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.568 X-Spam-Level: X-Spam-Status: No, score=-106.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BOd7LF+7SwQg; Sat, 10 Mar 2012 20:00:53 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 0923B21F8604; Sat, 10 Mar 2012 20:00:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1331438453; x=1362974453; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-originating-ip; z=Message-ID:=20<4F5C236F.40003@qualcomm.com>|Date:=20Sat, =2010=20Mar=202012=2022:00:47=20-0600|From:=20Pete=20Resn ick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20|CC:=20Dave =20Crocker=20,=20John=20C=20Klensin=20< klensin@jck.com>,=0D=0A=09,=20Peter=20Saint-Andre=0D=0A=09,=20,=20The=20IESG=20|Subject:=20Re:=20[apps-discuss]=20APPSDIR=20r eview=20of=20draft-ietf-appswg-xdash-03|References:=20<62 FF481C5AD21C3F683CD2B9@PST.JCK.COM>=09<4F5B9FF5.7040209@d crocker.net>=20<4F5BA20D.30304@qualcomm.com>=09=20<4F5C1CCE.6020706@dcrocker .net>=20<4F5C1E10.6000909@qualcomm.com>=20<4F5C1EFE.40703 01@dcrocker.net>|In-Reply-To:=20<4F5C1EFE.4070301@dcrocke r.net>|Content-Type:=20text/plain=3B=20charset=3D"ISO-885 9-1"=3B=20format=3Dflowed|Content-Transfer-Encoding:=207b it|X-Originating-IP:=20[172.30.48.1]; bh=1rsws8XXu4CQUZOlwcaU0RBq0Mf1/l1ixFc7DbmQbV0=; b=hGFF4jzYt7Xid7vgWKdSvmWcqgj8b1rZL51Sn+1zDlNd5+jS1Z4cGHNS 2628meinhZlijnQ1yoWxrNjkqoWt+XJ620oPe/Wf1dLj2ZvlSKudPAPcL ew3j2WiboYgXsHGdZsnrci63FGcJd9NYeMZRLDc/KGDwToOGhOM5hhXfE 0=; X-IronPort-AV: E=McAfee;i="5400,1158,6645"; a="171413194" Received: from ironmsg02-l.qualcomm.com ([172.30.48.16]) by wolverine01.qualcomm.com with ESMTP; 10 Mar 2012 20:00:52 -0800 X-IronPort-AV: E=Sophos;i="4.73,565,1325491200"; d="scan'208";a="119654336" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by ironmsg02-L.qualcomm.com with ESMTP/TLS/AES128-SHA; 10 Mar 2012 20:00:52 -0800 Received: from resnick2.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.1.339.1; Sat, 10 Mar 2012 20:00:52 -0800 Message-ID: <4F5C236F.40003@qualcomm.com> Date: Sat, 10 Mar 2012 22:00:47 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: References: <62FF481C5AD21C3F683CD2B9@PST.JCK.COM> <4F5B9FF5.7040209@dcrocker.net> <4F5BA20D.30304@qualcomm.com> <4F5C1CCE.6020706@dcrocker.net> <4F5C1E10.6000909@qualcomm.com> <4F5C1EFE.4070301@dcrocker.net> In-Reply-To: <4F5C1EFE.4070301@dcrocker.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Cc: apps-discuss@ietf.org, draft-ietf-appsawg-xdash.all@tools.ietf.org, John C Klensin , The IESG Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-appswg-xdash-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 11 Mar 2012 04:00:53 -0000 Presenting my still purple face, and this time intentionally replying to all... On 3/10/12 9:41 PM, Dave Crocker wrote: > for the life of me, I can't figure out what John's substantive concern > is with the document being considered. As I said before, I think making the "status vs. type" distinction is worth doing, though apparently even I was unable to do it the first shot to make it clear to John, though apparently I did on the second go-round. An attempt at text: To the first paragraph of the intro: Many application protocols use parameters with textual names to identify data (media types, header fields in Internet mail messages and HTTP requests, vCard parameters and properties, etc.). Historically, designers and implementers of application protocols have often distinguished between "standard" and "non-standard" parameters by prefixing the latter with the string "X-" or similar constructions (e.g., "x."), where the "X" is commonly understood to stand for "eXperimental" or "eXtension". Add: "That is, instead of just identifying the data, the name also embedded the status of the name as "non-standard" into the name itself." Does that help? Do we need more elsewhere in the intro. pr -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From dhc@dcrocker.net Sat Mar 10 20:08:53 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66B0021F84DC; Sat, 10 Mar 2012 20:08:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.596 X-Spam-Level: X-Spam-Status: No, score=-6.596 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lCK8HXxt7F6K; Sat, 10 Mar 2012 20:08:52 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id B2A5C21F84D7; Sat, 10 Mar 2012 20:08:52 -0800 (PST) Received: from [192.168.1.11] (adsl-67-127-58-62.dsl.pltn13.pacbell.net [67.127.58.62]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q2B48ltN020399 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 10 Mar 2012 20:08:52 -0800 Message-ID: <4F5C253C.7020707@dcrocker.net> Date: Sat, 10 Mar 2012 20:08:28 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Pete Resnick References: <62FF481C5AD21C3F683CD2B9@PST.JCK.COM> <4F5B9FF5.7040209@dcrocker.net> <4F5BA20D.30304@qualcomm.com> <4F5C1CCE.6020706@dcrocker.net> <4F5C1E10.6000909@qualcomm.com> <4F5C1EFE.4070301@dcrocker.net> <4F5C236F.40003@qualcomm.com> In-Reply-To: <4F5C236F.40003@qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sat, 10 Mar 2012 20:08:52 -0800 (PST) Cc: draft-ietf-appsawg-xdash.all@tools.ietf.org, apps-discuss@ietf.org, The IESG Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-appswg-xdash-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 04:08:53 -0000 On 3/10/2012 8:00 PM, Pete Resnick wrote: > > Add: "That is, instead of just identifying the data, the name also embedded the > status of the name as "non-standard" into the name itself." wfm. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From stpeter@stpeter.im Sat Mar 10 20:23:48 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F304C21F8597; Sat, 10 Mar 2012 20:23:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.591 X-Spam-Level: X-Spam-Status: No, score=-102.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQGCzaOrlq0f; Sat, 10 Mar 2012 20:23:47 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE0321F853C; Sat, 10 Mar 2012 20:23:47 -0800 (PST) Received: from squire.local (unknown [216.17.175.160]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D58B74005B; Sat, 10 Mar 2012 21:35:57 -0700 (MST) Message-ID: <4F5C28D1.6030803@stpeter.im> Date: Sat, 10 Mar 2012 21:23:45 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: dcrocker@bbiw.net References: <62FF481C5AD21C3F683CD2B9@PST.JCK.COM> <4F5B9FF5.7040209@dcrocker.net> <4F5BA20D.30304@qualcomm.com> <4F5C1CCE.6020706@dcrocker.net> <4F5C1E10.6000909@qualcomm.com> <4F5C1EFE.4070301@dcrocker.net> <4F5C236F.40003@qualcomm.com> <4F5C253C.7020707@dcrocker.net> In-Reply-To: <4F5C253C.7020707@dcrocker.net> X-Enigmail-Version: 1.3.5 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Pete Resnick , draft-ietf-appsawg-xdash.all@tools.ietf.org, The IESG , apps-discuss@ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-appswg-xdash-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 11 Mar 2012 04:23:48 -0000 On 3/10/12 9:08 PM, Dave Crocker wrote: > > > On 3/10/2012 8:00 PM, Pete Resnick wrote: >> >> Add: "That is, instead of just identifying the data, the name also >> embedded the >> status of the name as "non-standard" into the name itself." > > > wfm. For me, too. From stpeter@stpeter.im Sat Mar 10 20:32:10 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E429021F8634; Sat, 10 Mar 2012 20:32:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.591 X-Spam-Level: X-Spam-Status: No, score=-102.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FRrgSvKLLeuI; Sat, 10 Mar 2012 20:32:10 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 65E1A21F8633; Sat, 10 Mar 2012 20:32:09 -0800 (PST) Received: from squire.local (unknown [216.17.175.160]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D43E54005B; Sat, 10 Mar 2012 21:44:19 -0700 (MST) Message-ID: <4F5C2AC7.9090208@stpeter.im> Date: Sat, 10 Mar 2012 21:32:07 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: dcrocker@bbiw.net References: <62FF481C5AD21C3F683CD2B9@PST.JCK.COM> <4F5B9FF5.7040209@dcrocker.net> <4F5BA20D.30304@qualcomm.com> <4F5C1CCE.6020706@dcrocker.net> <4F5C1E10.6000909@qualcomm.com> <4F5C1EFE.4070301@dcrocker.net> <4F5C236F.40003@qualcomm.com> <4F5C253C.7020707@dcrocker.net> <4F5C28D1.6030803@stpeter.im> In-Reply-To: <4F5C28D1.6030803@stpeter.im> X-Enigmail-Version: 1.3.5 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Pete Resnick , draft-ietf-appsawg-xdash.all@tools.ietf.org, The IESG , apps-discuss@ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-appswg-xdash-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 11 Mar 2012 04:32:11 -0000 On 3/10/12 9:23 PM, Peter Saint-Andre wrote: > On 3/10/12 9:08 PM, Dave Crocker wrote: >> >> >> On 3/10/2012 8:00 PM, Pete Resnick wrote: >>> >>> Add: "That is, instead of just identifying the data, the name also >>> embedded the >>> status of the name as "non-standard" into the name itself." >> >> >> wfm. > > For me, too. Done in our working copy and checked into SVN: http://svn.tools.ietf.org/svn/wg/appsawg/xdash/ Peter -- Peter Saint-Andre https://stpeter.im/ From krokodil@gmail.com Sat Mar 10 22:33:08 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE20C21F8652 for ; Sat, 10 Mar 2012 22:33:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b6H4OwQmhK2A for ; Sat, 10 Mar 2012 22:33:08 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4001421F864B for ; Sat, 10 Mar 2012 22:33:08 -0800 (PST) Received: by dakl33 with SMTP id l33so3803103dak.31 for ; Sat, 10 Mar 2012 22:33:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=Tc+JdOPk+MtcOli76nEEeCeoJOPHBdFbwbZ90wLQaZo=; b=zc0z74L8+tEdwdw0tMR9yC/24zqMzFJTeFkRD5ftn/PbHiBJu47j7xN6hWAcNB5mtq gEALhJ4HiXGDhKY4IbdcFoIdHtf1kPX947AyWFy4a5J2QANOL+GhwVeYf/nQgQLKi0sb n8CEgPyQJJIMR2awx6kc6J8K0J8PyaeoCSfknX+WJi4NVCiEr4XwDul2eoVMvCZsxo+W u6B1Ar7X/XdQ+qhrRdch0awpWhgr5D8IBggczNfqGhKql1oTIBn8gnAbwo+vPxGSlYAo 43YS+KPI7IbokNrfVVG/0jvEa+N1D9irz/FJSFxa/4h9s9BiV0rSBIrVJC5US3ONuVqc zhFA== Received: by 10.68.138.197 with SMTP id qs5mr12981647pbb.78.1331447588106; Sat, 10 Mar 2012 22:33:08 -0800 (PST) Received: from [10.0.81.105] (c-107-3-160-225.hsd1.ca.comcast.net. [107.3.160.225]) by mx.google.com with ESMTPS id d8sm5013808pbk.18.2012.03.10.22.33.05 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 10 Mar 2012 22:33:06 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1257) From: Vadim Zaliva In-Reply-To: <20120309212231.16366.52439.idtracker@ietfa.amsl.com> Date: Sat, 10 Mar 2012 22:33:03 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120309212231.16366.52439.idtracker@ietfa.amsl.com> To: apps-discuss@ietf.org X-Mailer: Apple Mail (2.1257) Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-json-patch-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 11 Mar 2012 06:33:09 -0000 I would like to suggest some extensions to this draft. I was trying to = use proposed syntax in one of my project and found it lacking a couple of operations. Please find below my = proposed extensions: Operation =93add-unique=94 The new value appended the array only if the it presently does not = contain an element with such value. If an element with such value = already exists, the duplicate will not be added.=20 If an element referenced by this command does not exists, it will be = created, as an array with single value. If an element referenced by this = command exists, but is not an array such situation will be treated as an = error.=20 An example target JSON document: { "foo": [ "bar", "qux", "baz" ] } A JSON Patch document: [ { "add-unique": "/foo", "value": "tic" } ] The resulting JSON document: { "foo": [ "bar", "qux", "baz", "tic" ] } Operation =93remove-all=94 This operations removes from array all elements with given value. An example target JSON document: { "foo": [ "bar", "qux", "baz", "tic" ] } A JSON Patch document: [ { "remove-all": "/foo", "value": "tic" } ] The resulting JSON document: { "foo": [ "bar", "qux", "baz" ] } Operation =93replace-all=94 This operations replaces in an array all elements with given value with = a new value. An example target JSON document: { "foo": [ "bar", "qux", "baz", "tic" ] } A JSON Patch document: [ { "replace-all": "/foo", "old-value": "qux", "new-value": "zap" } ] The resulting JSON document: { "foo": [ "bar", "zap", "baz", "tic" ] } P.S. I am not sure "add-unique" is the best name. I guess = 'array-add-if-not-present' is more appropriate bit it is a bit too long. P.P.S. I am tempted to extend semantics of proposed 'remove-all' and = 'replace-all' operations also to object properties, if they are applied = to JSON object, not an array. They would either remove or replace values = of all properties with matching value. It would make things nice and = symmetric, but I am not sure if there is enough realistic use-cases for = such use. Sincerely, Vadim From Claudio.Allocchio@garr.it Sun Mar 11 03:05:28 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6589621F866D for ; Sun, 11 Mar 2012 03:05:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.407 X-Spam-Level: X-Spam-Status: No, score=-3.407 tagged_above=-999 required=5 tests=[AWL=1.192, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MkhCe5BkZZjB for ; Sun, 11 Mar 2012 03:05:27 -0700 (PDT) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [IPv6:2001:760:0:158::29]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF9721F8667 for ; Sun, 11 Mar 2012 03:04:53 -0700 (PDT) Received: from mac-allocchio3.garrtest.units.it (mac-allocchio3.garrtest.units.it [140.105.201.3] (may be forged)) (authenticated bits=0) by cyrus.dir.garr.it (8.14.5/8.14.5) with ESMTP id q2BA4mU0078979 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 Mar 2012 11:04:49 +0100 (CET) X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 cyrus.dir.garr.it q2BA4mU0078979 DomainKey-Signature: a=rsa-sha1; s=mail; d=garr.it; c=simple; q=dns; b=iY6/492PLoOtCGZwx92o0J+pQMSaYzcS5I8Me2CBc2wvDSfpWNyWXOGtz9qdzGQKC xiM/i+G5yBl3U159z8a2twiecNITA4T8dT/clneuoteFYx5QpGIvVEW4lNbjFfcwkgq d9spFpfnYfh253S8t0nSoXOj+IMtE/AzYU6WepU= Date: Sun, 11 Mar 2012 11:04:48 +0100 (CET) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.local To: apps-discuss@ietf.org, draft-ietf-mediactrl-mrb.all@tools.ietf.org Message-ID: User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: [apps-discuss] APPSDIR review of draft-ietf-mediactrl-mrb-12 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 11 Mar 2012 10:05:28 -0000 I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-mediactrl-mrb-12 Title: Media Resource Brokering Reviewer: Claudio Allocchio, GARR Review Date: March 11th 2012 IETF Last Call Date: n/a (if there was and I miss it, then CC IESG list!) IESG Telechat Date: n/a Summary: This document is well detailed, and is almaost ready for publication as a Proposed Standard. However there are some general considerations to deal with, and some small additions before this can be done. See below for details. In general, this document is a complex collection of tutorial like (architecture description) sections, general dicussions sections, and detailed element definition and examples. For sure the letter "S" (simple) does not belong to it :-) I guess the WG already discussed about the chance of splitting at lest the tutorial and specification sections, and it pro and cons in doing this. If not, then have at least some thoughts. Major Issues: The only major issue I identified is about the use of security features while communicating between the various elements defined in the architecture: for example when in 12. Security Consideration it states "In the case of the HTTP use, any binding using the Consumer interface MUST be capable of being transacted over TLS" it only states the capability MUST be there (the same for SIP etc.) but it does not make it compulsory (ok, I agree it can be too strong) nor it gives guidance or suggestions on why the capability SHOLD be used. Given we are dealing with locating Media Contents, breaking into the communication among elements can give very precious information for looking to illegally getting media contents. At least a guidance, and description of the problem should be added and will fix my concern. Minor Issues: In section 5.2 you should maybe add a small discussion about differences using HTTP and SIP as Consumer interface (pro and cons). Having Examples as a (long) Section 9 seems to break away the Security and IANA consdierations from the rest of the document body. Have you considered moving the examples below after Security and IANA Considertations? Or as an Appendix? (maybe the above should be considered an editorial Nit!). Nits: where is NS0tecnologies located ? there is no street address. (authors' addresses). Best Regards! ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca From Hannes.Tschofenig@gmx.net Sun Mar 11 04:27:05 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B4C921F865B for ; Sun, 11 Mar 2012 04:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.385 X-Spam-Level: X-Spam-Status: No, score=-102.385 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nn7-SqGJQMx3 for ; Sun, 11 Mar 2012 04:27:04 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 6183321F8657 for ; Sun, 11 Mar 2012 04:27:04 -0700 (PDT) Received: (qmail invoked by alias); 11 Mar 2012 11:27:02 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.107]) [88.115.216.191] by mail.gmx.net (mp072) with SMTP; 11 Mar 2012 12:27:02 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX181ZVN7HZA1GcsdkHcRW1Opin0qtIcyrs/AX2xslD 7cHZ/rGmETizJc Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Hannes Tschofenig In-Reply-To: <4F461734.4050306@it.aoyama.ac.jp> Date: Sun, 11 Mar 2012 13:26:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2D2E64D9-9809-4D75-ABEC-3540F51F30CE@gmx.net> References: <1DE839B2-11F0-4DBF-9C3A-4CB1073B91A9@gmx.net> <4F1DE84A.9000600@nostrum.com> <4F456465.6010509@stpeter.im> <4F461734.4050306@it.aoyama.ac.jp> To: =?iso-8859-1?Q?Martin_J=2E_D=FCrst?= X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: ecrit@ietf.org, "apps-discuss@ietf.org" , hgs+ecrit@cs.columbia.edu, mlinsner@cisco.com Subject: Re: [apps-discuss] review of draft-ietf-ecrit-lost-sync-12 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 11 Mar 2012 11:27:05 -0000 Hi Martin,=20 I understand the desire for namespace economy. In this specific case we are defining a new protocol that incorporates = elements from * OGC - a different organization who defined the Geography Markup = Langugage. This is used for the geodetic location information. * IETF GEOPRIV working group - this includes the civic location format. * IETF ECRIT working group - this includes the prior work on LoST. We = re-use one element from the LoST protocol (namely the = element). While it is possible to avoid defining a new namespace for this protocol = I believe it will lead to confusion.=20 Of course IANA needs to define a new namespace but this is not a huge = overhead.=20 When extending the LoST Sync protocol with new elements one could think = about the approach you suggest below, namely to just define new elements = without defining a new namespace. Then, the group who defines that = extension needs to take care that they do not define attributes and = elements with colliding names (given that there is no registry defined = either). =20 Ciao Hannes =20 On Feb 23, 2012, at 12:38 PM, Martin J. D=FCrst wrote: > Hello Peter, others, >=20 > On 2012/02/23 6:55, Peter Saint-Andre wrote: >> Robert Sparks asked me to think about the namespaces issue... >>=20 >>> -------- Original Message -------- Subject: Re: review of >>> draft-ietf-ecrit-lost-sync-12 Date: Fri, 13 Jan 2012 = 11:17:10 +0200 >>> From: Hannes Tschofenig To: = "Martin J. >>> D=FCrst" CC: Hannes Tschofenig >>> , Henning Schulzrinne >>> , Marc Linsner, >>> Robert Sparks, "apps-review@ietf.org" >>> , ecrit@ietf.org >>>=20 >>>=20 >>>> =46rom Martin: >>>=20 >>>> Namespaces: It is overkill to define new namespaces for each spec. >>>> It's a well-known secret in the XML community that it's easily >>>> possible to add a number of new elements to an existing namespace. >>>> This would be very appropriate in this case, because the number of >>>> reused elements and attributes is quite large, and the number of >>>> new elements is low. This would simplify most of the examples. >>>=20 >>> I guess you refer to the namespace registration in the IANA >>> consideration section, namely urn:ietf:params:xml:ns:lostsync1 >>>=20 >>> In the RAI area we have (to my knowledge) always created new >>> namespaces for new schemas. But I am pleased to hear that this is = not >>> needed. >>>=20 >>> Could you explain what we should be doing instead? >=20 > Rather than define a new namespace lostsync1, just add the few = elements you defined anew to the lost1 namespace. It will make the = format simpler, and it won't hurt. >=20 >> I don't see a problem with defining a new namespace for each = iteration >> of an XML format (lostsync1, lostsync2, etc.), >=20 > There's no 'problem' with defining a separate namespace for each = element. Correct software should still work. But it's not really = necessary, it's tedious for human users and just overkill. >=20 >> because I don't think >> there's a general case here -- backward compatibility can depend on = the >> community of interest. One community might be doing strict schema >> checking, so that any new elements or attributes would be = problematic. >> By contrast, another community might be more lax in its processing >> because they specify that applications must ignore unknown elements = and >> attributes, even those qualified by an existing namespace. >=20 > Validation is largely independent of namespaces. There are some = problems with validating documents with more than one namespace, = depending on the technology (I'd have to look up the details), but there = are NO issues, with any of the validating technologies around (DTDs, XML = Schema, Relaxing, Schematron), when having only one namespace and = validating against subsets thereof. >=20 > W3C technologies regularly do that (XHTML and SVG are the examples I = know best). Way, way back there was a heated discussion in the XML = community about whether a new namespace would make sense for a new = version of XHTML, and this was strongly and utterly rejected. The way it = was put most prominently was "a

is a

is a

". >=20 > Validation is not only different for versions, but as you have = explained also for various other purposes. Some applications may use = validation to introduce further restrictions (e.g. for security reasons = in certain places), and so on. >=20 > A new namespace for a new version only make sense if the old and the = new version are something completely different, with essentially no = common elements and no documents that would be acceptable in both = versions. For other cases, using separate namespaces just increases = clutter without contributing anything. >=20 > The same is the case here. The proposed "lostsync1" namespace doesn't = contain many elements, and is only useful together with the "lost1" = namespace. That's of course unless the people in charge of the LOST = protocol and the people who came up with LOSTSYNC totally distrust each = other, but I was just assuming that's not the case :-). >=20 > Regards, Martin. From julian.reschke@gmx.de Sun Mar 11 05:49:39 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B548421F8673 for ; Sun, 11 Mar 2012 05:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.738 X-Spam-Level: X-Spam-Status: No, score=-102.738 tagged_above=-999 required=5 tests=[AWL=-1.339, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_35=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id utuK7mtrBLUn for ; Sun, 11 Mar 2012 05:49:38 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 1F99A21F850B for ; Sun, 11 Mar 2012 05:49:37 -0700 (PDT) Received: (qmail invoked by alias); 11 Mar 2012 12:49:36 -0000 Received: from p57A6E004.dip.t-dialin.net (EHLO [192.168.178.36]) [87.166.224.4] by mail.gmx.net (mp033) with SMTP; 11 Mar 2012 13:49:36 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19r5v1zv1ZrmnIftOMDVc5eWOJWPObcR72fpu9mJU xFby6deIfuuaYV Message-ID: <4F5C9F5D.4060302@gmx.de> Date: Sun, 11 Mar 2012 13:49:33 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Zach Shelby References: <4F4D2FCB.8030805@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: core@ietf.org, draft-ietf-core-link-format@tools.ietf.org, The IESG , IETF Apps Discuss Subject: Re: [apps-discuss] [core] APPSDIR review of draft-ietf-core-link-format-11 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 11 Mar 2012 12:49:39 -0000 On 2012-03-09 12:35, Zach Shelby wrote: > Julian, > > Thanks for the really detailed and helpful review! Well, sometimes a review request comes in where I actually can contribute (hopefully) :-) > On Feb 28, 2012, at 9:49 PM, Julian Reschke wrote: >> >> Major Issues: >> >> 2.2. Link relations >> >> Since links in the CoRE Link Format are typically used to describe >> resources hosted by a server, and thus in the absence of the relation >> parameter the new relation type "hosts" is assumed (see Section 7.2). >> >> It took me a moment to realize that "hosts" isn't the plural of "host" here. Maybe a different relation name would make things clearer (although I currently have no better proposal :-). > > Boy was that a fun discussion on the WG list as well, and hosts is what we ended up with... Maybe just adding some explanatory text right there would help. +1 >> The "hosts" relation type indicates that the target URI is a resource >> hosted by the server given by the base URI, or, if present, the >> anchor parameter. >> >> So the rule for determining the context URI is different for this link relation? I believe this needs to change. > > Originally it was for the whole link format, and I think with the rules you suggest below we can make it generic again. Sounds good. >> To express other relations, links can make use of any registered >> relation by including the relation parameter. To simplify the >> constrained implementations, the value of a "rel" parameter in this >> link format SHOULD NOT contain more than one relation type. There >> >> That's a SHOULD NOT that doesn't help anybody. Are recipients supposed to understand multiple relation types or not? If yes, then the constraint isn't needed. If no, it's a MUST NOT. > > The only reason we left the door open for allowing multiple relation types, was in case other Web Links were converted to this format (and thus may have multiple relation types). Constrained devices are not expected to understand multiple relation types. I would recommend that we just remove the SHOULD NOT. Well, you could serialized multiple relations in one link instance into multiple links. >> may be cases where multiple relation types cannot be avoided, for >> example when storing a RFC5988 Link header in this link format. The >> context of a relation can be defined using the anchor parameter. In >> this way, relations between resources hosted on a server, or between >> hosted resources and external resources can be expressed. >> >> This seems to repeat information from earlier on... >> >> >> 3. CoRE link extensions >> >> The following CoRE specific target attributes are defined in addition >> to the ABNF rules in Section 5 of [RFC5988]. These attributes >> describe information useful in accessing the target link of the >> relation, and in some cases may be URIs. These URIs MUST be treated >> >> s/may be/can use the syntactical form of a/ >> >> as non resolvable identifiers (they are not meant to be retrieved). >> >> Not sure about the "MUST". Maybe replace with an explanation that they can indeed by dereferenced (for instance to obtain a description of the link relation), but that this is not part of the protocol and MUST NOT be done automatically on link evaluation. > > Good suggestion, I will make a ticket. We do need to check that this is consistent with RFC5988, as my understanding of target attributes was that they are not meant to be retrieved (checking again though, I can't find text in RFC5988 that contradicts what you are suggesting). Consistency with 5988 is good :-) The main point here is that processing the link doesn't *need* dereferencing the link; but there may be other cases, such as looking up information, when it's useful to do so. >> When attributes are compared, they MUST be compared as strings. >> >> Attribute values? >> >> Relationships to resources that are meant to be retrieved should be >> expressed as separate links using the anchor attribute and the >> appropriate relation type. >> >> It's not clear to me what this means. Could you elaborate? > > Basically a work-around for the MUST you suggested replacing above. This text would be removed if that change is made. > >> link-extension = >> link-extension =/ ( "rt=" quoted-string ) >> link-extension =/ ( "if=" quoted-string ) >> link-extension =/ ( "sz=" cardinal ) >> cardinal = "0" / %x31-39 *DIGIT >> >> In here, you copied the ABNF style from RFC 5988. I think that style is something we should avoid, though, because it encourages parsers to special case certain attributes. >> >> I would recommend to allow both token and quoted-string for all new parameters. >> >> (and yes, I'll raise an erratum against RFC 5988 once we have done the base work in HTTPbis) > > Carsten already touched on this, and I will make a ticket. > >> >> 3.1. Resource type 'rt' attribute >> >> The resource type "rt" attribute is an opaque string used to assign a >> semantically important type to a resource. One can think of this as >> a noun describing the resource. In the case of a temperature >> resource this could be e.g. an application-specific semantic type >> like "OutdoorTemperature", a Universal Resource Name (URN) like >> "urn:temperature:outdoor" or a URI referencing a specific concept in >> an ontology like >> >> "http://sweet.jpl.nasa.gov/2.0/phys.owl#Temperature". Multiple >> resource type attributes MAY appear in a link. >> >> Please avoid that. In general, the format that you're borrowing from doesn't allow multiple parameters with the same name. Either make it multiple links, or allow a white-space separated list of values in the attribute value. > > Right, same goes for if=. In theory we could allow multiple values separated by a white-space, like in the rel= attribute. This makes the attribute matching more difficult however. At the same time including multiple links is wasteful overhead. So far when applying these in designs only a single rt= or if= attribute has been needed, but I could foresee multiple values in the future. If you require the separator to be a single SP, matching can be done by doing contains(concat(" ",value," "),concat(" ",searchfor," ") so it's no too hard. >> The resource type attribute is not meant to used to assign a human >> readable name to a resource. The "title" attribute defined in >> [RFC5988] is meant for that purpose. >> >> Did you consider using the type attribute that already is defined in RFC 5988? > > type= refers to the Media Type, and this is already used also in this format for that purpose. > >> 5. Examples >> >> A few examples of typical link descriptions in this format follows. >> Multiple resource descriptions in a representation are separated by >> commas. Linefeeds never occur in the actual format, but are shown in >> these examples for readability. Although the following examples use >> CoAP response codes, the examples are applicable to HTTP as well (the >> corresponding response code would be 200 OK). >> >> Actually, RFC 5988 allows CR LF between parameters as it uses the RFC 2616 list production allowing implied LWS. >> >> If you want to rule this out, you probably need to specify your own ABNF. > > I would not mind allowing the CR LF actually, but do we really inherit that from the RFC 2616 production as we are not inside the HTTP header anymore? It's part of the ABNF, not something specific to header fields. So yes, it does inherit that. >> This example arranges link descriptions hierarchically, with the >> entry point including a link to a sub-resource containing links about >> the sensors. >> >> REQ: GET /.well-known/core >> >> RES: 2.05 "Content" >> ;rt="index" >> >> REQ: GET /sensors >> >> RES: 2.05 "Content" >> ;rt="TemperatureC";if="sensor", >> ;rt="LightLux";if="sensor" >> >> rt="index" is mentioned for the first time here. Is this something recipients need to understand, so is it predefined? Also, isn't this a use case for rel=index? > > Yep, "index" is not a great example here. I will update this to be more appropriate. > >> Minor Issues: >> >> The main function of such a discovery mechanism is to provide >> Universal Resource Identifiers (URIs, called links) for the resources >> >> Nope. As discussed further down below, a link requires two resources, not a single one. >> >> 2.1. Target and context URIs >> >> Each link conveys one target URI as a URI-reference inside angle >> brackets ("<>"). The context URI of a link (also called base URI in >> [RFC3986]) conveyed in the CoRE Link Format is by default built from >> the scheme and authority parts of the target URI. In the absence of >> >> OK, so >> >> ; rel=bar >> >> represents the link >> >> http://example.com --bar--> http://example.com/foo >> >> ? Sounds a bit counter-intuitive to me; maybe you should explain that in examples. > > It is intuitive for our main use case, which is describing the resources hosted by that server using the rel=hosts relation. But yes, I can add more example. > >> >> this information in the target URI, the context URI is built from the >> scheme and authority that was used for referencing the resource >> returning the set of links, replacing the path with an empty path. >> >> Thus by default links can be thought of as describing a target >> resource hosted by the server. Other relations can be expressed by >> including an anchor parameter (which defines the context URI) along >> with an explicit relation parameter. This is an important difference >> to the way the HTTP Link Header format is used, as it is included in >> the header of an HTTP response for some URI (this URI is by default >> the context URI). Thus the HTTP Link Header is by default relating >> the target URI to the URI that was requested. In comparison, the >> CoRE link format includes one or more links, each describing a >> resource hosted by a server by default. Other relations can be >> expressed by using the anchor parameter. See Section 5 of [RFC3986] >> for a description of how URIs are constructed from URI references. >> >> Alternative explanation: >> >> The context URI specified by >> >> a) the anchor parameter, when specified, or >> >> b) protocol + authority of the target URI, when specified >> >> c) protocol + authority of the link format document's base URI. >> >> It would be nice if the reason why only protocol + authority are used. > > I like this way of explaining it, will make a ticket. > >> (you may also want to use the term "Origin" (RFC 6454) for protocol + authority) > > Richard Barnes also suggested this in his review, added a ticket already: > http://trac.tools.ietf.org/wg/core/trac/ticket/191 > >> 2.3. Use of anchors >> >> As per Section 5.2 of [RFC5988] a link description MAY include an >> "anchor" attribute, in which case the context is the URI included in >> that attribute. This is used to describe a relationship between two >> resources. A consuming implementation can however choose to ignore >> such links. It is not expected that all implementations will be able >> to derive useful information from explicitly anchored links. >> >> Right. Maybe make clear that recipients MUST either process anchor correctly, or ignore the whole link relation (not only the anchor parameter). > > OK. > >> 7.2. New 'hosts' relation type >> >> This memo registers the new "hosts" Web Linking relation type as per >> [RFC5988]. >> >> Relation Name: hosts >> >> Description: Refers to a resource hosted by the server indicated by >> the link context. >> >> Does that indicate more than "is one the same server"? In which case I believe no link relation is needed. > > We are using this to indicate: > > Origin -> hosts -> Target URI > > e.g. > > coap://this.server -> hosts -> /sensor/temperature (and has these attributes) > > How would we relate this following Web Linking without a relation? By specifying an untyped link... > ... Best regards, Julian From zach@sensinode.com Sun Mar 11 06:51:25 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E87E221F86AF for ; Sun, 11 Mar 2012 06:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Up9M1NSDHEq7 for ; Sun, 11 Mar 2012 06:51:21 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 73A5321F8693 for ; Sun, 11 Mar 2012 06:51:19 -0700 (PDT) Received: from [192.168.0.139] (dsl-kmibrasgw1-fe40de00-225.dhcp.inet.fi [80.222.64.225]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q2BDotJV032123; Sun, 11 Mar 2012 15:51:17 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <20120308174709.GK23228@jay.w3.org> Date: Sun, 11 Mar 2012 15:13:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5BE91077-80A0-4A34-9F76-1A133D8DC2B4@sensinode.com> References: <20120305094330.27895.2135.idtracker@ietfa.amsl.com> <20120308083354.GJ23228@jay.w3.org> <73EF8185-649D-43DB-95FD-513210F21D1C@sensinode.com> <20120308174709.GK23228@jay.w3.org> To: Carine Bournez X-Mailer: Apple Mail (2.1084) Cc: General discussion of application-layer protocols Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-shelby-exi-registration-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 11 Mar 2012 13:51:25 -0000 Carine, Based on this thread, I think I have enough input to make a new update = to the draft and try to focus on the media type registration defining = how the schemaID is to be interpreted. I will also look at the EXI = extension point issue. We should clearly point out that all EXI settings = etc. are controlled by the EXI header. I will post a link to this list = when the new version is available - latest during the IETF week... Thanks, Zach=20 On Mar 8, 2012, at 7:47 PM, Carine Bournez wrote: > Hi, > On Thu, Mar 08, 2012 at 11:33:21AM +0200, Zach Shelby wrote: >>=20 >> I agree that the EXI header should be used to convey the EXI specific = options needed to decode the payload (I got a similar comment on the = CoRE list). The SchemaID field is not very useful on its own however, so = the goal of this text should be that the media type registration for = +exi needs to define what to place in the SchemaID field of the header. = It needs to point to a specification of the schemas, and how the value = in the SchemaID field corresponds to them. It may also e.g. define a = default schema to use if the SchemaID field is elided. This is an = important aspect to the efficiency of EXI for M2M applications, where = often our EXI payloads are only tens of bytes long. Placing a 30-50 byte = URI reference to the XSD in the header of that EXI payload would be = unacceptable, however a short integer ID or such is OK.=20 >>=20 >=20 > Specifying the schemaID format for a foo+exi media type is indeed an > interesting idea, this is not what I understood from your draft text. > In any case, a MUST requirement for that is probably too strong. >=20 >> I am fine with removing the text that implies the media type alone = identifies the schema. However the media type does define the semantics = and meaning of the data carried in the payload once it is decoded = (regardless of the schema version or variation).=20 >=20 > Changing the text to something clearer about specifying schemaID, and=20= > possibly about the use of EXI extension points (datatype = representation > maps), would be useful as interop consideration.. >=20 >>> A +exi suffix might help conveying the original media type *and* the=20= >>> encoding whenever the content-encoding header is not available >>> in a protocol. However, the suffix should not try to replace some of >>> the existing EXI mechanisms at all. >>=20 >> Right, and in particular the +exi suffix is only meant to be used in = cases where content-encoding is not being performed, in other words = Schema-informed mode is used and there is no intermediate use of XML. = For other use cases this document should recommend the use of the exi = content-encoding or the generic application/exi media type. >=20 > "there is no intermediate use of XML" is a bit obscure to me, EXI *is* = XML. > If you mean no text serialization of XML, I don't see the relation = with > the ability or not to use the content-encoding. The content-encoding = is also > not reserved to schema-informed mode. >=20 >=20 > --=20 > Carine Bournez -+- W3C Europe >=20 --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From john-ietf@jck.com Sun Mar 11 11:09:54 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC75B21F8518; Sun, 11 Mar 2012 11:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.8 X-Spam-Level: X-Spam-Status: No, score=-102.8 tagged_above=-999 required=5 tests=[AWL=-0.201, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PNwyl3zW5scV; Sun, 11 Mar 2012 11:09:54 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB6F21F84E7; Sun, 11 Mar 2012 11:09:42 -0700 (PDT) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1S6n8U-000IHn-Ay; Sun, 11 Mar 2012 14:04:50 -0400 Date: Sun, 11 Mar 2012 14:09:28 -0400 From: John C Klensin To: Pete Resnick , dcrocker@bbiw.net Message-ID: <04886CA63CB9FA84DC8CA8B9@PST.JCK.COM> In-Reply-To: <4F5C236F.40003@qualcomm.com> References: <62FF481C5AD21C3F683CD2B9@PST.JCK.COM> <4F5B9FF5.7040209@dcrocker.net> <4F5BA20D.30304@qualcomm.com> <4F5C1CCE.6020706@dcrocker.net> <4F5C1E10.6000909@qualcomm.com> <4F5C1EFE.4070301@dcrocker.net> <4F5C236F.40003@qualcomm.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: draft-ietf-appsawg-xdash.all@tools.ietf.org, The IESG , apps-discuss@ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-appswg-xdash-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 11 Mar 2012 18:09:55 -0000 --On Saturday, March 10, 2012 22:00 -0600 Pete Resnick wrote: > Presenting my still purple face, and this time intentionally > replying to all... > > On 3/10/12 9:41 PM, Dave Crocker wrote: >> for the life of me, I can't figure out what John's >> substantive concern is with the document being considered. > > As I said before, I think making the "status vs. type" > distinction is worth doing, though apparently even I was > unable to do it the first shot to make it clear to John, > though apparently I did on the second go-round. An attempt at > text: > > To the first paragraph of the intro: > > Many application protocols use parameters with textual > names to > identify data (media types, header fields in Internet mail > messages > and HTTP requests, vCard parameters and properties, etc.). > Historically, designers and implementers of application > protocols > have often distinguished between "standard" and > "non-standard" > parameters by prefixing the latter with the string "X-" or > similar > constructions (e.g., "x."), where the "X" is commonly > understood to > stand for "eXperimental" or "eXtension". > > Add: "That is, instead of just identifying the data, the name > also embedded the status of the name as "non-standard" into > the name itself." > > Does that help? Do we need more elsewhere in the intro. Yes, it helps. And I like Peter's proposed new text. To answer Dave's question, I have had two specific concerns. The first is largely covered above and by the new text. I don't want to see over-broad statements in this document that could accidentally constrain approaches, such as specific prefixes or suffixes for other purposes, that we've found more useful than harmful in other contexts. The second is still outstanding. I think killing off "X-" for any use that might become widely-used or require standardization is a great idea and long overdue. On the other hand, I think there are private use cases that will never be registered or standardized no matter what we do. For them, even if they are observed in use, I'm concerned about third-party registrations, unless we want to find ourselves needing to do trademark searches and/or embroiled in the middle of trade secret disclosure problems. As a result, I think it might (please note that word) be in the Internet's best interest to continue to have a syntax convention for strictly private (and "agreement among parties") use. I think that option needs a good deal of explanation, most of which is already present in the document and other things we have written: inappropriate for experimental use (keywords for experiments should be registered so that different semantics don't use the same keyword and so that, if the experiment succeeds, we don't have multiple keyword issues), inappropriate for general-purpose extension use (extensions should be registered so they can be used with reasonable confidence that both parties are talking about the same thing), and so on. But, for true private-use cases, I don't see the harm in permitting (or even encouraging) "X-" and see some advantages in terms of putting receivers on notice. To look at that same position from another point of view, we have ample evidence that experimental, preliminary, and extension use of "X-" causes problems and that we should get rid of those uses on that basis. We have little or no evidence that the private use cases are problematic. Let's not try to discard / prohibit the latter until we have that evidence... or until someone makes a really compelling argument that the community is incapable of distinguishing "private" from "experimental". john From dhc@dcrocker.net Sun Mar 11 11:16:16 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9C2D21F870E; Sun, 11 Mar 2012 11:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.596 X-Spam-Level: X-Spam-Status: No, score=-6.596 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2L0NYGfq9V9m; Sun, 11 Mar 2012 11:16:15 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id D86E921F870B; Sun, 11 Mar 2012 11:16:15 -0700 (PDT) Received: from [192.168.1.11] (adsl-67-127-58-62.dsl.pltn13.pacbell.net [67.127.58.62]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q2BIG9jQ021275 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 Mar 2012 11:16:15 -0700 Message-ID: <4F5CEBD6.7090002@dcrocker.net> Date: Sun, 11 Mar 2012 11:15:50 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: John C Klensin References: <62FF481C5AD21C3F683CD2B9@PST.JCK.COM> <4F5B9FF5.7040209@dcrocker.net> <4F5BA20D.30304@qualcomm.com> <4F5C1CCE.6020706@dcrocker.net> <4F5C1E10.6000909@qualcomm.com> <4F5C1EFE.4070301@dcrocker.net> <4F5C236F.40003@qualcomm.com> <04886CA63CB9FA84DC8CA8B9@PST.JCK.COM> In-Reply-To: <04886CA63CB9FA84DC8CA8B9@PST.JCK.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sun, 11 Mar 2012 11:16:15 -0700 (PDT) Cc: Pete Resnick , draft-ietf-appsawg-xdash.all@tools.ietf.org, The IESG , apps-discuss@ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-appswg-xdash-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 18:16:16 -0000 On 3/11/2012 11:09 AM, John C Klensin wrote: > On the other hand, I think > there are private use cases that will never be registered or > standardized no matter what we do. 1. The experience with X- is that we can't know ahead of time which cases will qualify. You appear to believe we can. How? 2. What specific benefits accrue from providing for these cases? 3. What specific problems accrue from the provisions in the current draft? By 'specific', I'm not asking for a restatement of your concern but for the operational effects. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From john-ietf@jck.com Sun Mar 11 12:19:18 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3FF121F8592; Sun, 11 Mar 2012 12:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.796 X-Spam-Level: X-Spam-Status: No, score=-102.796 tagged_above=-999 required=5 tests=[AWL=-0.197, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oiednnncd0ro; Sun, 11 Mar 2012 12:19:17 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 20FBD21F8546; Sun, 11 Mar 2012 12:19:17 -0700 (PDT) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1S6oDt-000IMP-SI; Sun, 11 Mar 2012 15:14:29 -0400 Date: Sun, 11 Mar 2012 15:19:05 -0400 From: John C Klensin To: dcrocker@bbiw.net Message-ID: In-Reply-To: <4F5CEBD6.7090002@dcrocker.net> References: <62FF481C5AD21C3F683CD2B9@PST.JCK.COM> <4F5B9FF5.7040209@dcrocker.net> <4F5BA20D.30304@qualcomm.com> <4F5C1CCE.6020706@dcrocker.net> <4F5C1E10.6000909@qualcomm.com> <4F5C1EFE.4070301@dcrocker.net> <4F5C236F.40003@qualcomm.com> <04886CA63CB9FA84DC8CA8B9@PST.JCK.COM> <4F5CEBD6.7090002@dcrocker.net> 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: Pete Resnick , draft-ietf-appsawg-xdash.all@tools.ietf.org, The IESG , apps-discuss@ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-appswg-xdash-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 11 Mar 2012 19:19:18 -0000 Dave, I think I've explained the answer to your questions several times. I'm going to try again but, unless others are also confused, I'm going to assume that our misunderstanding is localized and stop cluttering up the list. No offense is intended by that statement: I believe that just about everyone reading this knows that we often see things from perspectives that are different enough to make misunderstandings common. --On Sunday, March 11, 2012 11:15 -0700 Dave Crocker wrote: > On 3/11/2012 11:09 AM, John C Klensin wrote: >> On the other hand, I think >> there are private use cases that will never be registered or >> standardized no matter what we do. > 1. The experience with X- is that we can't know ahead of time > which cases will qualify. You appear to believe we can. How? I believe that the true "private use" cases --e.g., "I'm going to use this field, or this parameter, to communicate within my organization or with my business partners" -- are easily distinguished from the "likely to end up in general use" and "likely to be standardization candidates" group. are easily distinguished from the problem cases. If we really think people need help, I think we can provide guidance via two questions and perhaps a third. (i) Is this really intended for use strictly within your organizational context and not for general use or later standardization? (ii) If you changed your mind and decided it was appropriate for more general use, would it need significant redesign for use out of your context? (iii) Is the meaning or interpretation of this parameter or command something that you would consider to be a trade secret or other proprietary information? If the answer to the first two questions is not "yes", then the application is probably not "private use". The third question further qualifies the situation; if the answer to all three is "yes", then the application is almost certainly private use. > 2. What specific benefits accrue from providing for these > cases? Non-conflicting use or, more specifically, a warning about possible conflicting use, of commands, parameters or fields that are clearly private and that will not be registered and/or publicly explained no matter how much we change the registration rules. Also see "standard for action" below. > 3. What specific problems accrue from the provisions in the > current draft? The current draft deprecates the use of "X" and "X-", even in those private use cases and does so without providing any practical recommendation about how to avoid conflicts. Registration is not practical, or, at least, has never been used in the past for these cases, there is no reason to believe that it will be used in the future, nor that it would be effective if we could convince people to use it. Use of a syntax convention for private-use cases provides a warning to implementations that they need to know with whom they are talking before interpreting the parameter. If we get rid of "X-" for other purposes, it makes that particular use even more attractive. And, again, we don't have a practical alternative that preserves that functionality. > By 'specific', I'm not asking for a restatement of your > concern but for the operational effects. I hope the above is responsive to your request. In case it isn't clear, I have seen examples of such private-use parameters and commands in the past, often to carry organization-specific magic cookies or classificatory information. _Standards for Action_ It is worth noting that we have a more or less philosophical question about the criteria that should used by the IETF for including or withdrawing a feature. For the latter, I believe the standard should be "this specific use causes harm" and not "some members of the set of capabilities enabled by this feature cause harm, therefore the whole feature should be banned unless people can _prove_ that all capabilities are reasonable and safe". So, to me, if it is established that experimental and normal extension uses are problematic and have very little benefit (and I believe that has been established), we should deprecate those uses. It does not follow that we should automatically depreciate all other uses, nor that anyone advocating retention of those uses until and unless there is evidence of harm should be required to prove that they are safe or even beneficial in a large number of cases. I think we should have a commitment to stability to be careful about blanket deprecation of a feature that has been around for circa 30 years and that such care should lead us to be conservative and narrow about the actions we take to restrict it. Otherwise, we can engage in exchanges that amount to "you prove it is ok" and "no, you prove it is not ok" until long after exhaustion sets in. john From McQuilWP@pobox.com Sun Mar 11 12:28:23 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 197CF21F870E for ; Sun, 11 Mar 2012 12:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xl2+nOUtX1dS for ; Sun, 11 Mar 2012 12:28:22 -0700 (PDT) Received: from smtp.pobox.com (b-pb-sasl-quonix.pobox.com [208.72.237.35]) by ietfa.amsl.com (Postfix) with ESMTP id 6E9AB21F8701 for ; Sun, 11 Mar 2012 12:28:22 -0700 (PDT) Received: from smtp.pobox.com (unknown [127.0.0.1]) by b-sasl-quonix.pobox.com (Postfix) with ESMTP id 0696C68DA; Sun, 11 Mar 2012 15:28:21 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=date:from :message-id:to:cc:subject:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=sasl; bh=XXqiDGm9sLpj qfMDqQ23VXpk7Rc=; b=Fh76BrQWmZ1q6cHiI0zNny8T6d4utw4F1Pb+xoDfR3xL 0QmmXCTbOec5FuMfc0ybSMjXSuTK2WoEjKIDmWFH3yoySx/5ksZtOlpUKk9oRLoQ u+YKQEjnLNARcwzFadTm7oR4wTBM7ex8OS19WjMj9x6djyhnzvQjgiydzwTcgvA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=date:from :message-id:to:cc:subject:in-reply-to:references:mime-version :content-type:content-transfer-encoding; q=dns; s=sasl; b=YBs2z7 4CjvhA9aa0NIYoV2ebWuII5GvH8b3M4bAHdmPJdz8FCKQHBDknQD5/2KXyzRf/WM 4REoI/TaxLGa2eOrItn5iGmdRMLc3cuFe5eYiXTUH2EXIrOxztSHF86Cc205HSpK PBJyLScpzvrxIpRBLOM2qwJMxyu3hI47Acx8U= Received: from b-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by b-sasl-quonix.pobox.com (Postfix) with ESMTP id EF76368D9; Sun, 11 Mar 2012 15:28:20 -0400 (EDT) Received: from [192.168.0.3] (unknown [68.107.110.211]) by b-sasl-quonix.pobox.com (Postfix) with ESMTPA id DEC1668D7; Sun, 11 Mar 2012 15:28:19 -0400 (EDT) Date: Sun, 11 Mar 2012 12:28:18 -0700 From: Bill McQuillan X-Priority: 3 (Normal) Message-ID: <1369189904.20120311122818@pobox.com> To: Apps-Discusssion In-Reply-To: <04886CA63CB9FA84DC8CA8B9@PST.JCK.COM> References: <62FF481C5AD21C3F683CD2B9@PST.JCK.COM> <4F5B9FF5.7040209@dcrocker.net> <4F5BA20D.30304@qualcomm.com> <4F5C1CCE.6020706@dcrocker.net> <4F5C1E10.6000909@qualcomm.com> <4F5C1EFE.4070301@dcrocker.net> <4F5C236F.40003@qualcomm.com> <04886CA63CB9FA84DC8CA8B9@PST.JCK.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 5C6BC2A8-6BB0-11E1-9F80-9DB42E706CDE-02871704!b-pb-sasl-quonix.pobox.com Cc: Pete Resnick , draft-ietf-appsawg-xdash.all@tools.ietf.org, dcrocker@bbiw.net, The IESG Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-appswg-xdash-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 11 Mar 2012 19:28:23 -0000 On Sun, 2012-03-11, John C Klensin wrote: > To look at that same position from another point of view, we > have ample evidence that experimental, preliminary, and > extension use of "X-" causes problems and that we should get rid > of those uses on that basis. We have little or no evidence > that the private use cases are problematic. Let's not try to > discard / prohibit the latter until we have that evidence... or > until someone makes a really compelling argument that the > community is incapable of distinguishing "private" from > "experimental". Very much agree. Let's not presume we know all possible ways to use this convention and pre-declare them all "bad." We have run this "experiment" (X- names) for a couple of decades and found *some* problems with them in transitioning from experimentation to standardization, but I think that with some guidance they *are* useful for true private use. -- Bill McQuillan From dhc@dcrocker.net Sun Mar 11 12:42:28 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 462AC21F8713; Sun, 11 Mar 2012 12:42:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.596 X-Spam-Level: X-Spam-Status: No, score=-6.596 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sIuHEWR61-xB; Sun, 11 Mar 2012 12:42:27 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id AE1B621F86FF; Sun, 11 Mar 2012 12:42:27 -0700 (PDT) Received: from [192.168.1.11] (adsl-67-127-58-62.dsl.pltn13.pacbell.net [67.127.58.62]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q2BJgLVr024798 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 Mar 2012 12:42:26 -0700 Message-ID: <4F5D0009.1040709@dcrocker.net> Date: Sun, 11 Mar 2012 12:42:01 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Bill McQuillan References: <62FF481C5AD21C3F683CD2B9@PST.JCK.COM> <4F5B9FF5.7040209@dcrocker.net> <4F5BA20D.30304@qualcomm.com> <4F5C1CCE.6020706@dcrocker.net> <4F5C1E10.6000909@qualcomm.com> <4F5C1EFE.4070301@dcrocker.net> <4F5C236F.40003@qualcomm.com> <04886CA63CB9FA84DC8CA8B9@PST.JCK.COM> <1369189904.20120311122818@pobox.com> In-Reply-To: <1369189904.20120311122818@pobox.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sun, 11 Mar 2012 12:42:27 -0700 (PDT) Cc: draft-ietf-appsawg-xdash.all@tools.ietf.org, Apps-Discusssion , The IESG Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-appswg-xdash-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 19:42:28 -0000 On 3/11/2012 12:28 PM, Bill McQuillan wrote: > I think that with some guidance they*are* > useful for true private use. Given two decades of experience, can you site those that have been both successful and needed an explicit, standards-level convention (like X-)? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dhc@dcrocker.net Sun Mar 11 12:54:51 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C258521F8540; Sun, 11 Mar 2012 12:54:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.596 X-Spam-Level: X-Spam-Status: No, score=-6.596 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2eRXHmVNxxZr; Sun, 11 Mar 2012 12:54:51 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3B3BF21F8510; Sun, 11 Mar 2012 12:54:51 -0700 (PDT) Received: from [192.168.1.11] (adsl-67-127-58-62.dsl.pltn13.pacbell.net [67.127.58.62]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q2BJsiin025002 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 Mar 2012 12:54:50 -0700 Message-ID: <4F5D02F1.1030208@dcrocker.net> Date: Sun, 11 Mar 2012 12:54:25 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: John C Klensin References: <62FF481C5AD21C3F683CD2B9@PST.JCK.COM> <4F5B9FF5.7040209@dcrocker.net> <4F5BA20D.30304@qualcomm.com> <4F5C1CCE.6020706@dcrocker.net> <4F5C1E10.6000909@qualcomm.com> <4F5C1EFE.4070301@dcrocker.net> <4F5C236F.40003@qualcomm.com> <04886CA63CB9FA84DC8CA8B9@PST.JCK.COM> <4F5CEBD6.7090002@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sun, 11 Mar 2012 12:54:51 -0700 (PDT) Cc: Pete Resnick , draft-ietf-appsawg-xdash.all@tools.ietf.org, The IESG , apps-discuss@ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-appswg-xdash-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 19:54:51 -0000 On 3/11/2012 12:19 PM, John C Klensin wrote: > I think I've explained the answer to your questions several > times. I'm happy to have you cut and paste from your previous notes where you explained the specifics. As I say, I didn't see them. > --On Sunday, March 11, 2012 11:15 -0700 Dave Crocker > wrote: > >> On 3/11/2012 11:09 AM, John C Klensin wrote: >>> On the other hand, I think >>> there are private use cases that will never be registered or >>> standardized no matter what we do. > >> 1. The experience with X- is that we can't know ahead of time >> which cases will qualify. You appear to believe we can. How? ... > (i) Is this really intended for use strictly within your > organizational context and not for general use or later > standardization X- was for these cases. > (ii) If you changed your mind and decided it was > appropriate for more general use, would it need > significant redesign for use out of your context? The current draft answers that question, with a yes. It is not about 'redesign' but total switching cost. The former is a rather small subset of the latter. There's this odd concept, called "installed base", which proves nettlesome for such transitions. > (iii) Is the meaning or interpretation of this parameter > or command something that you would consider to be a > trade secret or other proprietary information? And this requires a public syntax convention why? Remember this is not about private actions taken privately. This is about public conventions that 'protect' private actions. >> 2. What specific benefits accrue from providing for these >> cases? > > Non-conflicting use That was the premise for X-. It has proved more problematic than beneficial. What actual evidence -- specifics -- do you have to the contrary? What makes other similar conventions subject to different outcomes? >> 3. What specific problems accrue from the provisions in the >> current draft? > > The current draft deprecates the use of "X" and "X-", even in > those private use cases and does so without providing any > practical recommendation about how to avoid conflicts. Ahh, so you actually want to continue to have X-. It's semantics are exactly what you are lobbying for: "won't become a standards-based name"? >> By 'specific', I'm not asking for a restatement of your >> concern but for the operational effects. > > I hope the above is responsive to your request. Alas, it's not. You are only stating broad hypotheticals. > In case it > isn't clear, I have seen examples of such private-use parameters > and commands in the past, often to carry organization-specific > magic cookies or classificatory information. Excellent. Those would be specifics. What are they? > _Standards for Action_ > > It is worth noting that we have a more or less philosophical > question about the criteria that should used by the IETF for > including or withdrawing a feature. have or should have? if have, please cite where it is stated. if should have, then that's a philosophical debate that I hope is conducted separately. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From presnick@qualcomm.com Sun Mar 11 13:09:58 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B12E21F867C; Sun, 11 Mar 2012 13:09:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.568 X-Spam-Level: X-Spam-Status: No, score=-106.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aMGycpbxBuNd; Sun, 11 Mar 2012 13:09:58 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id DEEF321F863E; Sun, 11 Mar 2012 13:09:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1331496597; x=1363032597; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-originating-ip; z=Message-ID:=20<4F5D0690.5020700@qualcomm.com>|Date:=20Su n,=2011=20Mar=202012=2015:09:52=20-0500|From:=20Pete=20Re snick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20|CC:=20Dave =20Crocker=20,=20John=20C=20Klensin=20< john-ietf@jck.com>,=0D=0A=09,=20The=20IESG=20,=0D=0A =09|Subject:=20Re:=20[apps-discuss ]=20APPSDIR=20review=20of=20draft-ietf-appswg-xdash-03 |References:=20<62FF481C5AD21C3F683CD2B9@PST.JCK.COM>=09< 4F5B9FF5.7040209@dcrocker.net>=09<4F5BA20D.30304@qualcomm .com>=09=09<4F5C1CC E.6020706@dcrocker.net>=09<4F5C1E10.6000909@qualcomm.com> =09<4F5C1EFE.4070301@dcrocker.net>=09<4F5C236F.40003@qual comm.com>=09<04886CA63CB9FA84DC8CA8B9@PST.JCK.COM>=09<4F5 CEBD6.7090002@dcrocker.net>=09=20<4F5D02F1.1030208@dcrocker.net> |In-Reply-To:=20<4F5D02F1.1030208@dcrocker.net> |Content-Type:=20text/plain=3B=20charset=3D"ISO-8859-1" =3B=20format=3Dflowed|Content-Transfer-Encoding:=207bit |X-Originating-IP:=20[172.30.39.5]; bh=oWmLRjTfCzMKATZcbndd8PVw6QTb07FJwil8mIYdt9g=; b=kJZQ0EqSPL9n1s++hYZ2nwHpBfYTR2V0P9zRiA9hR8OlOj4y5HQTmYcG Y7IxGtmuQGtE7Rm7zFOtL27iZ3WWc1nx4069IWMpk60ykmdkiHXVwDjVg mnYelHqRLR499L/16PXIIr/NOT9wln4I8DmXzxnn49Iu3CcHkgVKYQeIH s=; X-IronPort-AV: E=McAfee;i="5400,1158,6646"; a="171495229" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine01.qualcomm.com with ESMTP; 11 Mar 2012 13:09:57 -0700 X-IronPort-AV: E=Sophos;i="4.73,567,1325491200"; d="scan'208";a="281926442" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 11 Mar 2012 13:09:56 -0700 Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.1.339.1; Sun, 11 Mar 2012 13:09:56 -0700 Message-ID: <4F5D0690.5020700@qualcomm.com> Date: Sun, 11 Mar 2012 15:09:52 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: References: <62FF481C5AD21C3F683CD2B9@PST.JCK.COM> <4F5B9FF5.7040209@dcrocker.net> <4F5BA20D.30304@qualcomm.com> <4F5C1CCE.6020706@dcrocker.net> <4F5C1E10.6000909@qualcomm.com> <4F5C1EFE.4070301@dcrocker.net> <4F5C236F.40003@qualcomm.com> <04886CA63CB9FA84DC8CA8B9@PST.JCK.COM> <4F5CEBD6.7090002@dcrocker.net> <4F5D02F1.1030208@dcrocker.net> In-Reply-To: <4F5D02F1.1030208@dcrocker.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] Cc: draft-ietf-appsawg-xdash.all@tools.ietf.org, The IESG , apps-discuss@ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-appswg-xdash-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 11 Mar 2012 20:09:58 -0000 On 3/11/12 2:54 PM, Dave Crocker wrote: > On 3/11/2012 12:19 PM, John C Klensin wrote: >> I think I've explained the answer to your questions several times. > > I'm happy to have you cut and paste from your previous notes where you > explained the specifics. As I say, I didn't see them. > [...] > What actual evidence -- specifics -- do you have to the contrary? > What makes other similar conventions subject to different outcomes? Sorry, process interrupt, speaking as the person who is trying to determine consensus in the Last Call: First of all, I did see in John's previous notes several specific explications of answers to Dave's questions. I find the Socratic questions sent back, and sent at alarming speed, not helpful to my assessment of consensus, but rather inviting silly tit-for-tat discussion. Indeed, the speed with which the replies are sent with these Socratic questions indicates to me a lack of consideration of the issues and a lack of well-reasoned response. I would ask that it please stop. Second, I believe it is likely the case that the concerns that John and Bill have expressed have been discussed in the WG and answered. I am endeavoring to collect together those answers to see if they do show that John and Bill are "in the rough. *If* John and Bill (or others) have concerns that were *not* answered in those discussions, which they will be able to determine by my laying out what I think are the answers from the WG, they can highlight the appropriate distinctions in their arguments so that I can figure out if they have new issues that the WG needs to address in the document. But until that time, I find continued interrogation and answers on these topics non-useful. Whether you agree or disagree with John and Bill on this particular topic, please hold your comments in abeyance unless you think you are able to consisely explain to John or Bill why their concerns are unfounded or already answered. Otherwise, please allow me (or Alexey as chair/shepherd) to collect together what the WG has said previously on this topic and see if that answers John and Bill (and perhaps simply needs some additional text in the document), or whether they actually have a new issue that needs to be addressed. pr -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From McQuilWP@pobox.com Sun Mar 11 13:11:20 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 053D521F8680 for ; Sun, 11 Mar 2012 13:11:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sgvldwDUYEsL for ; Sun, 11 Mar 2012 13:11:16 -0700 (PDT) Received: from smtp.pobox.com (b-pb-sasl-quonix.pobox.com [208.72.237.35]) by ietfa.amsl.com (Postfix) with ESMTP id 947FD21F867F for ; Sun, 11 Mar 2012 13:11:16 -0700 (PDT) Received: from smtp.pobox.com (unknown [127.0.0.1]) by b-sasl-quonix.pobox.com (Postfix) with ESMTP id D8C5170B8; Sun, 11 Mar 2012 16:11:15 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=date:from :message-id:to:cc:subject:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=sasl; bh=FeFvD9D4kHrK vD8IwkPlbHi9y/U=; b=p4u9fcpUgq+jOviEvgZLVnyVNavyCNiwJja4+qhEip8e hM4BohUgND7lDooU0W2Z03LiiswMHYbYtRl2pN/QHCEt9kEiUe8y9j6PNAHqsXWM 2JMdaQQ7nzoMqfOQDJ0YRAQ+xBKYav3WGMebw1kvF20fAFErrGV9ygvzC6ftEWM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=date:from :message-id:to:cc:subject:in-reply-to:references:mime-version :content-type:content-transfer-encoding; q=dns; s=sasl; b=SYuZMj HA3qE1ak6yxHNQOx/RyHREy9wBdFF6/V5OMzG1bRkgG79/YoZ/11pTSUUk51Phs0 mU/+QlX2x41Rp3sRQ/q3U0VqwY3ow2JmTWMFhWcIqu2B+oLw1k0FAVCU8Fqg9mRj Kv6tgqISvV2m3AXyNAM3IiTybmNbUeUJd27Ks= Received: from b-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by b-sasl-quonix.pobox.com (Postfix) with ESMTP id CEBDF70B7; Sun, 11 Mar 2012 16:11:15 -0400 (EDT) Received: from [192.168.0.3] (unknown [68.107.110.211]) by b-sasl-quonix.pobox.com (Postfix) with ESMTPA id B609170B6; Sun, 11 Mar 2012 16:11:14 -0400 (EDT) Date: Sun, 11 Mar 2012 13:11:13 -0700 From: Bill McQuillan X-Priority: 3 (Normal) Message-ID: <221887190.20120311131113@pobox.com> To: Apps-Discusssion In-Reply-To: <4F5D0009.1040709@dcrocker.net> References: <62FF481C5AD21C3F683CD2B9@PST.JCK.COM> <4F5B9FF5.7040209@dcrocker.net> <4F5BA20D.30304@qualcomm.com> <4F5C1CCE.6020706@dcrocker.net> <4F5C1E10.6000909@qualcomm.com> <4F5C1EFE.4070301@dcrocker.net> <4F5C236F.40003@qualcomm.com> <04886CA63CB9FA84DC8CA8B9@PST.JCK.COM> <1369189904.20120311122818@pobox.com> <4F5D0009.1040709@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 5B0BEC3E-6BB6-11E1-8F90-9DB42E706CDE-02871704!b-pb-sasl-quonix.pobox.com Cc: draft-ietf-appsawg-xdash.all@tools.ietf.org, The IESG Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-appswg-xdash-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 11 Mar 2012 20:11:20 -0000 On Sun, 2012-03-11, Dave Crocker wrote: > On 3/11/2012 12:28 PM, Bill McQuillan wrote: >> I think that with some guidance they*are* >> useful for true private use. > Given two decades of experience, can you site those that have been both > successful and needed an explicit, standards-level convention (like X-)? Her are the X- Header Fields from your message to this list and then to me: ------------------------------------------------------------------ X-CT-Class: Clean X-CT-Score: 0.00 X-CT-RefID: str=0001.0A020203.4F5D0046.0065:SCFSTAT16494284,ss=1,re=-4.000,fgs=0 X-CT-Spam: 0 X-Authority-Analysis: v=1.1 cv=/ZwqEBlPVGrPjyTYV1SQchNqYCp4wKr9chc4/hMuKn4= c=1 sm=1 a=311X-zf45VgA:10 a=njq9vhlBZ1cA:10 a=eOGH69Cg1f0A:10 a=6fD_dijBfH4A:10 a=wPDyFdB5xvgA:10 a=kj9zAlcOel0A:10 a=GU4rwa5YvsQnE15YQEkOQw==:17 a=k7Ga1wGzAAAA:8 a=48vgC7mUAAAA:8 a=xT979wAqctAob7kwSJkA:9 a=CjuIK1q_8ugA:10 a=x3I_HB9Tk8MA:10 a=ClmATp4dOM8A:10 a=lZB815dzVvQA:10 a=fsYzn3yOqi5YVgO2YBcNBQ==:117 X-CM-Score: 0.00 X-Pobox-Orig-Sender: X-Pobox-Delivery-ID: 68B0C71E-6BB2-11E1-B45E-81693F681118-07228702!sienna.pobox.com X-Original-To: apps-discuss@ietfa.amsl.com x-pobox-client-address: 12.22.58.30 x-pobox-client-name: mail.ietf.org X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.596 X-Spam-Level: X-Spam-Status: No, score=-6.596 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sun, 11 Mar 2012 12:42:27 -0700 (PDT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 ------------------------------------------------------------------ I see no problems with them and believe that they are all for "private use" and I would not like to see them forbidden. I especially like the "X-BeenThere: apps-discuss@ietf.org" field since I would guess that it is for anti-looping purposes, but perhaps it is for debugging or even vanity, but it doesn't matter because it clearly only has any meaning to apps-discuss@ietf.org. Now perhaps these could have been registered names, but I don't see the advantage in these cases. -- Bill McQuillan From bernie@ietf.hoeneisen.ch Sun Mar 11 13:21:36 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA9C721F86C6; Sun, 11 Mar 2012 13:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pc1DZiWQjl5Y; Sun, 11 Mar 2012 13:21:35 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by ietfa.amsl.com (Postfix) with ESMTP id EC88A21F86AD; Sun, 11 Mar 2012 13:21:34 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.71) (envelope-from ) id 1S6pGn-00024P-CT; Sun, 11 Mar 2012 21:21:33 +0100 Date: Sun, 11 Mar 2012 21:21:33 +0100 (CET) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: IETF ENUM list Message-ID: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false Cc: apps-discuss@ietf.org Subject: [apps-discuss] New Version Notification for draft-hoeneisen-rfc5333bis-01.txt (fwd) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 11 Mar 2012 20:21:37 -0000 FYI ---------- Forwarded message ---------- Date: Sun, 11 Mar 2012 21:18:32 From: internet-drafts@ietf.org To: bernie@ietf.hoeneisen.ch Subject: New Version Notification for draft-hoeneisen-rfc5333bis-01.txt A new version of I-D, draft-hoeneisen-rfc5333bis-01.txt has been successfully submitted by Bernie Hoeneisen and posted to the IETF repository. Filename: draft-hoeneisen-rfc5333bis Revision: 01 Title: IANA Registration of Enumservices for Internet Calendaring Creation date: 2012-03-11 WG ID: Individual Submission Number of pages: 20 Abstract: This document registers and obsoletes Enumservices for Internet calendaring. Specifically, this document focuses on Enumservices for iMIP (iCalendar Message-Based Interoperability Protocol), CalDAV (Calendaring Extensions to WebDAV), and iSchedule (Internet Calendar Scheduling Protocol). -- http://ucom.ch/ Tech Consulting for Internet Technology From dhc@dcrocker.net Sun Mar 11 13:43:57 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F095921F8603; Sun, 11 Mar 2012 13:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.596 X-Spam-Level: X-Spam-Status: No, score=-6.596 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NwSCfslFuhPC; Sun, 11 Mar 2012 13:43:57 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0DC8621F85F6; Sun, 11 Mar 2012 13:43:57 -0700 (PDT) Received: from [192.168.1.11] (adsl-67-127-58-62.dsl.pltn13.pacbell.net [67.127.58.62]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q2BKhn97025740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 Mar 2012 13:43:54 -0700 Message-ID: <4F5D0E71.1000605@dcrocker.net> Date: Sun, 11 Mar 2012 13:43:29 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Bill McQuillan References: <62FF481C5AD21C3F683CD2B9@PST.JCK.COM> <4F5B9FF5.7040209@dcrocker.net> <4F5BA20D.30304@qualcomm.com> <4F5C1CCE.6020706@dcrocker.net> <4F5C1E10.6000909@qualcomm.com> <4F5C1EFE.4070301@dcrocker.net> <4F5C236F.40003@qualcomm.com> <04886CA63CB9FA84DC8CA8B9@PST.JCK.COM> <1369189904.20120311122818@pobox.com> <4F5D0009.1040709@dcrocker.net> <221887190.20120311131113@pobox.com> In-Reply-To: <221887190.20120311131113@pobox.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sun, 11 Mar 2012 13:43:56 -0700 (PDT) Cc: draft-ietf-appsawg-xdash.all@tools.ietf.org, Apps-Discusssion , The IESG Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-appswg-xdash-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 20:43:58 -0000 On 3/11/2012 1:11 PM, Bill McQuillan wrote: > I see no problems with them and believe that they are all for > "private use" and I would not like to see them forbidden. Bill, You think the new draft prohibits people from having private conventions? It doesn't. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From likepeng@huawei.com Sun Mar 11 23:08:28 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DABA21F8555 for ; Sun, 11 Mar 2012 23:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.667 X-Spam-Level: X-Spam-Status: No, score=-5.667 tagged_above=-999 required=5 tests=[AWL=0.932, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kmK1OXyxNj6k for ; Sun, 11 Mar 2012 23:08:27 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 8E37121F8552 for ; Sun, 11 Mar 2012 23:08:26 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0R00B7LD1RR1@szxga04-in.huawei.com> for apps-discuss@ietf.org; Mon, 12 Mar 2012 14:08:15 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0R00M4ID1R9L@szxga04-in.huawei.com> for apps-discuss@ietf.org; Mon, 12 Mar 2012 14:08:15 +0800 (CST) Received: from szxeml210-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHT31416; Mon, 12 Mar 2012 14:08:15 +0800 Received: from SZXEML408-HUB.china.huawei.com (10.82.67.95) by szxeml210-edg.china.huawei.com (172.24.2.183) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 12 Mar 2012 14:07:37 +0800 Received: from SZXEML525-MBX.china.huawei.com ([169.254.1.71]) by szxeml408-hub.china.huawei.com ([10.82.67.95]) with mapi id 14.01.0323.003; Mon, 12 Mar 2012 14:07:11 +0800 Date: Mon, 12 Mar 2012 06:07:11 +0000 From: Likepeng X-Originating-IP: [10.70.109.64] To: "apps-discuss@ietf.org" Message-id: <34966E97BE8AD64EAE9D3D6E4DEE36F20330665F@szxeml525-mbx.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: New Version Notification for draft-li-appsawg-virtualized-application-protocol-01.txt Thread-index: AQHNABUIZ3PAIWnZuk6ylIzY0u/PR5ZmKgbQ X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Subject: [apps-discuss] Fw: New Version Notification for draft-li-appsawg-virtualized-application-protocol-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 12 Mar 2012 06:08:28 -0000 SGVsbG8gYWxsLA0KDQpJIHJldmlzZWQgdGhlIGRyYWZ0IGZvciB0aGUgVmlydHVhbGl6ZWQgQXBw bGljYXRpb24uIFRoZSBkcmFmdCBhaW1zIHRvIHByb3ZpZGUgYSBzdGFydGluZyBwb2ludCBmb3Ig ZGlzY3Vzc2lvbiwgYW5kIHRoaXMgaXMgbm90IGFuIGF0dGVtcHQgdG8gZGVmaW5lIGFueSBwcm90 b2NvbCBhdCB0aGlzIHBvaW50LCBidXQgdG8gc3RhcnQgYSBkaXNjdXNzaW9uIG9mIHRoZSBwcm9i bGVtIHN0YXRlbWVudCBJIGdpdmUuDQoNCk5vdyB0aGUgZG9jdW1lbnQgdGl0bGUgaXMgcmV2aXNl ZCBhcyAiVmlydHVhbGl6ZWQgQXBwbGljYXRpb24gLS0gUHJvYmxlbSBTdGF0ZW1lbnQiLg0KDQpJ ZiBwb3NzaWJsZSwgSSBob3BlIHRvIHByZXNlbnQgdGhhdCBicmllZmx5IGF0IHRoZSBBcHBsaWNh dGlvbnMgQXJlYSBvcGVuIG1lZXRpbmcsIGFuZCBJIGhvcGUgdG8gZ2V0IHNvbWUgZGlzY3Vzc2lv biBhYm91dCB3aGV0aGVyIGl0J3MgYSBwcm9ibGVtIHRoYXQncyBsaWtlbHkgdG8gZ2VuZXJhdGUg SUVURiB3b3JrIHRvIHNvbHZlIGl0LiANCg0KSSBub3RpY2UgdGhhdCBwcmV2aW91c2x5IHRoZXJl IHdhcyBhIFZpcnR1YWxpemVkIERlc2t0b3AgSW5mcmFzdHJ1Y3R1cmUgcHJvcG9zYWwsIGFuZCBJ IGluZGljYXRlZCBpbiB0aGUgZHJhZnQgdGhhdCBteSBwcm9wb3NhbCBpcyBkaWZmZXJlbnQgZnJv bSB0aGF0Lg0KDQpJZiB5b3UgaGF2ZSBpbnRlcmVzdCwgcGxlYXNlIGZlZWwgZnJlZSB0byBwcm92 aWRlIHlvdXIgY29tbWVudHMvc3VnZ2VzdGlvbnMvZmVlZGJhY2tzLCBJIGFtIGdsYWQgdG8gYW5z d2VyIHRoZW0uDQoNClRoYW5rcywNCktpbmQgUmVnYXJkcw0KS2VwZW5nDQotLS0tLemCruS7tuWO n+S7ti0tLS0tDQrlj5Hku7bkuro6IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQrlj5HpgIHml7bpl7Q6IDIwMTLlubQz5pyIMTLml6Ug MTM6NTcNCuaUtuS7tuS6ujogTGlrZXBlbmcNCuS4u+mimDogTmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIGZvciBkcmFmdC1saS1hcHBzYXdnLXZpcnR1YWxpemVkLWFwcGxpY2F0aW9uLXByb3RvY29s LTAxLnR4dA0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtbGktYXBwc2F3Zy12aXJ0dWFs aXplZC1hcHBsaWNhdGlvbi1wcm90b2NvbC0wMS50eHQgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1 Ym1pdHRlZCBieSBLZXBlbmcgTGkgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0K DQpGaWxlbmFtZToJIGRyYWZ0LWxpLWFwcHNhd2ctdmlydHVhbGl6ZWQtYXBwbGljYXRpb24tcHJv dG9jb2wNClJldmlzaW9uOgkgMDENClRpdGxlOgkJIFZpcnR1YWxpemVkIEFwcGxpY2F0aW9uOiBQ cm9ibGVtIFN0YXRlbWVudA0KQ3JlYXRpb24gZGF0ZToJIDIwMTItMDMtMTINCldHIElEOgkJIElu ZGl2aWR1YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiAxMA0KDQpBYnN0cmFjdDoNCiAg IFZpcnR1YWxpemVkIEFwcGxpY2F0aW9uIGFpbXMgdG8gZW5hYmxlIHRoZSB1c2VyIGRldmljZSB0 byByZW1vdGVseQ0KICAgY29uc3VtZSB2YXJpb3VzIGFwcGxpY2F0aW9ucyBvbiB0aGUgbmV0d29y ay4gIFRoaXMgaW52b2x2ZXMgaGF2aW5nDQogICBhbGwgdGhlIHZpcnR1YWxpemVkIGFwcGxpY2F0 aW9ucyBob3N0ZWQgaW4gdGhlIG5ldHdvcmsgYW5kIGZyb20gdGhlcmUNCiAgIHByb3ZpZGluZyB0 aGVtIHRvIHRoZSB1c2VycyB1c2luZyBjbG91ZCBjb21wdXRpbmcgdGVjaG5vbG9naWVzIGxpa2UN CiAgIHZpcnR1YWxpemF0aW9uLiAgVGhpcyBkb2N1bWVudCB0cmllcyB0byBleHBsYWluIHRoZSBw cm9ibGVtcyB0bw0KICAgYWNoaWV2ZSB0aGUgdmlydHVhbGl6ZWQgYXBwbGljYXRpb25zLg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIA0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0K From paulej@packetizer.com Mon Mar 12 00:25:52 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3C0721F85CD for ; Mon, 12 Mar 2012 00:25:52 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4JaNheBXf8bA for ; Mon, 12 Mar 2012 00:25:52 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id D130621F85B5 for ; Mon, 12 Mar 2012 00:25:51 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q2C7Po4x026921 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 12 Mar 2012 03:25:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1331537151; bh=Dn6FYSrNlEyfJPzU418zlHj7xqsOkiJ7ZxYTATy10hk=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=NeA3L5el599/1CqX7VPCI9kGEa/TvbxHEhM6Ffblgy8OOqZVMSf5STQgSb5CCLtWk gDo7zYDBbNdK/i2wZYOnyDVpTMxW5I4Nf71lylTtRZqZnJiMPFSQO+Lw40mCEZQ5E1 ACIcIjyV145HpU6xiuy3ZAtNTmOZm0DeGaqhN3Kg= From: "Paul E. Jones" To: References: <20120312072303.24645.20735.idtracker@ietfa.amsl.com> In-Reply-To: <20120312072303.24645.20735.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2012 03:25:53 -0400 Message-ID: <018701cd0021$5bbb6160$13322420$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHgtf6weo5Hh9+k8X/jrkg0oihfQJY+1nEA Content-Language: en-us Subject: [apps-discuss] FW: New Version Notification for draft-jones-appsawg-webfinger-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 12 Mar 2012 07:25:52 -0000 Folks, I just wanted to let everyone know that we have published a revised = version of the Webfinger draft. Your comments are encouraged. Paul > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Monday, March 12, 2012 3:23 AM > To: paulej@packetizer.com > Cc: jsmarr@google.com; gsalguei@cisco.com > Subject: New Version Notification for = draft-jones-appsawg-webfinger-01.txt >=20 > A new version of I-D, draft-jones-appsawg-webfinger-01.txt has been > successfully submitted by Paul E. Jones and posted to the IETF = repository. >=20 > Filename: draft-jones-appsawg-webfinger > Revision: 01 > Title: Webfinger > Creation date: 2012-03-12 > WG ID: Individual Submission > Number of pages: 17 >=20 > Abstract: > This specification defines the Webfinger protocol. Webfinger may = be > used to discover information about people on the Internet, such as = a > person's personal profile address, identity service, telephone > number, or preferred avatar. Webfinger may also be used to learn > information about objects on the network, such as the amount of = toner > in a printer or the physical location of a server. >=20 >=20 >=20 >=20 > The IETF Secretariat From stpeter@stpeter.im Mon Mar 12 08:32:45 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BA7921E8020 for ; Mon, 12 Mar 2012 08:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.726 X-Spam-Level: X-Spam-Status: No, score=-102.726 tagged_above=-999 required=5 tests=[AWL=-0.127, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5F0TtbkOhEn for ; Mon, 12 Mar 2012 08:32:44 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 854C321E801E for ; Mon, 12 Mar 2012 08:32:44 -0700 (PDT) Received: from dhcp-64-101-72-193.cisco.com (unknown [64.101.72.193]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A7A4A40058; Mon, 12 Mar 2012 09:44:58 -0600 (MDT) Message-ID: <4F5E1719.9090106@stpeter.im> Date: Mon, 12 Mar 2012 09:32:41 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Bill McQuillan References: <62FF481C5AD21C3F683CD2B9@PST.JCK.COM> <4F5B9FF5.7040209@dcrocker.net> <4F5BA20D.30304@qualcomm.com> <4F5C1CCE.6020706@dcrocker.net> <4F5C1E10.6000909@qualcomm.com> <4F5C1EFE.4070301@dcrocker.net> <4F5C236F.40003@qualcomm.com> <04886CA63CB9FA84DC8CA8B9@PST.JCK.COM> <1369189904.20120311122818@pobox.com> In-Reply-To: <1369189904.20120311122818@pobox.com> X-Enigmail-Version: 1.3.5 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Pete Resnick , Apps-Discusssion , draft-ietf-appsawg-xdash.all@tools.ietf.org, dcrocker@bbiw.net, The IESG Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-appswg-xdash-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 12 Mar 2012 15:32:45 -0000 On 3/11/12 1:28 PM, Bill McQuillan wrote: > > On Sun, 2012-03-11, John C Klensin wrote: > >> To look at that same position from another point of view, we >> have ample evidence that experimental, preliminary, and >> extension use of "X-" causes problems and that we should get rid >> of those uses on that basis. We have little or no evidence >> that the private use cases are problematic. Let's not try to >> discard / prohibit the latter until we have that evidence... or >> until someone makes a really compelling argument that the >> community is incapable of distinguishing "private" from >> "experimental". > > Very much agree. > > Let's not presume we know all possible ways to use this > convention and pre-declare them all "bad." We have run this > "experiment" (X- names) for a couple of decades and found *some* > problems with them in transitioning from experimentation to > standardization, but I think that with some guidance they *are* > useful for true private use. This document does not recommend against the practice of private, local, preliminary, experimental, or implementation-specific parameters, only against the use of "X-" and similar constructs in the names of such parameters. I haven't seen anyone argue for deprecating the former practice, only the latter convention. (I've provisionally added the first sentence of this paragraph to the introduction in our working copy of the document, because I think it answers what could be a common misunderstanding.) Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Mon Mar 12 10:24:27 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1E8921F88D9; Mon, 12 Mar 2012 10:24:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.719 X-Spam-Level: X-Spam-Status: No, score=-102.719 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qsNgJZd6uUhq; Mon, 12 Mar 2012 10:24:26 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 4460621F88D8; Mon, 12 Mar 2012 10:24:26 -0700 (PDT) Received: from dhcp-64-101-72-193.cisco.com (unknown [64.101.72.193]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6060040058; Mon, 12 Mar 2012 11:36:41 -0600 (MDT) Message-ID: <4F5E3148.50507@stpeter.im> Date: Mon, 12 Mar 2012 11:24:24 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: John C Klensin References: <62FF481C5AD21C3F683CD2B9@PST.JCK.COM> <4F5B9FF5.7040209@dcrocker.net> <4F5BA20D.30304@qualcomm.com> <4F5C1CCE.6020706@dcrocker.net> <4F5C1E10.6000909@qualcomm.com> <4F5C1EFE.4070301@dcrocker.net> <4F5C236F.40003@qualcomm.com> <04886CA63CB9FA84DC8CA8B9@PST.JCK.COM> <4F5CEBD6.7090002@dcrocker.net> In-Reply-To: X-Enigmail-Version: 1.3.5 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Pete Resnick , draft-ietf-appsawg-xdash.all@tools.ietf.org, dcrocker@bbiw.net, apps-discuss@ietf.org, The IESG Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-appswg-xdash-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 12 Mar 2012 17:24:28 -0000 On 3/11/12 1:19 PM, John C Klensin wrote: > Dave, > > I think I've explained the answer to your questions several > times. I'm going to try again but, unless others are also > confused, I'm going to assume that our misunderstanding is > localized and stop cluttering up the list. No offense is > intended by that statement: I believe that just about everyone > reading this knows that we often see things from perspectives > that are different enough to make misunderstandings common. > > --On Sunday, March 11, 2012 11:15 -0700 Dave Crocker > wrote: > >> On 3/11/2012 11:09 AM, John C Klensin wrote: >>> On the other hand, I think >>> there are private use cases that will never be registered or >>> standardized no matter what we do. > >> 1. The experience with X- is that we can't know ahead of time >> which cases will qualify. You appear to believe we can. How? > > I believe that the true "private use" cases --e.g., "I'm going > to use this field, or this parameter, to communicate within my > organization or with my business partners" -- are easily > distinguished from the "likely to end up in general use" and > "likely to be standardization candidates" group. are easily > distinguished from the problem cases. If we really think people > need help, I think we can provide guidance via two questions and > perhaps a third. > > (i) Is this really intended for use strictly within your > organizational context and not for general use or later > standardization? > > (ii) If you changed your mind and decided it was > appropriate for more general use, would it need > significant redesign for use out of your context? > > (iii) Is the meaning or interpretation of this parameter > or command something that you would consider to be a > trade secret or other proprietary information? > > If the answer to the first two questions is not "yes", then the > application is probably not "private use". The third question > further qualifies the situation; if the answer to all three is > "yes", then the application is almost certainly private use. John, your description helps to clarify the notion of private use, which this I-D currently uses but does not define (perhaps assuming that people know it when they see it). To apply that notion to the subject matter of this I-D, do you think that the "X-" prefix or a similar construct is needed to mark off private-use parameters? Or would you find it acceptable for folks needing private-use parameters to follow the guidelines mentioned in Appendix B? (The following text is copied from our working version, which might be slightly different from what's in -03.) ### In some situations, segregating the parameter name space used in a given application protocol can be justified: 1. When it is extremely unlikely that some parameters will ever be standardized. In this case implementation-specific and private- use parameters could at least incorporate the organization's name (e.g., "ExampleInc-foo" or, consistent with [RFC4288], "VND.ExampleInc.foo") or primary domain name (e.g., "com.example.foo" or a Uniform Resource Identifier [RFC3986] such as "http://example.com/foo"). In rare cases, truly experimental parameters could be given meaningless names such as nonsense words, the output of a hash function, or UUIDs [RFC4122]. ### >> 2. What specific benefits accrue from providing for these >> cases? > > Non-conflicting use or, more specifically, a warning about > possible conflicting use, of commands, parameters or fields that > are clearly private and that will not be registered and/or > publicly explained no matter how much we change the registration > rules. Also see "standard for action" below. > >> 3. What specific problems accrue from the provisions in the >> current draft? > > The current draft deprecates the use of "X" and "X-", even in > those private use cases and does so without providing any > practical recommendation about how to avoid conflicts. I think the text quoted above does provide several practical recommendations about how to avoid conflicts: incorporate the name or domain name of the organization that has minted the private-use parameter, or in rare cases even create a nonsense string, use the output of a hash function, or generate a UUID. > Registration is not practical, or, at least, has never been used > in the past for these cases, there is no reason to believe that > it will be used in the future, nor that it would be effective if > we could convince people to use it. Use of a syntax convention > for private-use cases provides a warning to implementations that > they need to know with whom they are talking before interpreting > the parameter. If we get rid of "X-" for other purposes, it > makes that particular use even more attractive. And, again, we > don't have a practical alternative that preserves that > functionality. I think we do. [philosophical topic elided] Peter -- Peter Saint-Andre https://stpeter.im/ From john-ietf@jck.com Mon Mar 12 11:24:12 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 285CF21F88B7; Mon, 12 Mar 2012 11:24:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.779 X-Spam-Level: X-Spam-Status: No, score=-102.779 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cidQIjYpqSVm; Mon, 12 Mar 2012 11:24:10 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id A717221F8822; Mon, 12 Mar 2012 11:24:09 -0700 (PDT) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1S79q2-000LRb-9b; Mon, 12 Mar 2012 14:19:18 -0400 Date: Mon, 12 Mar 2012 14:23:57 -0400 From: John C Klensin To: Peter Saint-Andre Message-ID: <4DE92D3E19AFC20A87DCCC2E@PST.JCK.COM> In-Reply-To: <4F5E3148.50507@stpeter.im> References: <62FF481C5AD21C3F683CD2B9@PST.JCK.COM> <4F5B9FF5.7040209@dcrocker.net> <4F5BA20D.30304@qualcomm.com> <4F5C1CCE.6020706@dcrocker.net> <4F5C1E10.6000909@qualcomm.com> <4F5C1EFE.4070301@dcrocker.net> <4F5C236F.40003@qualcomm.com> <04886CA63CB9FA84DC8CA8B9@PST.JCK.COM> <4F5CEBD6.7090002@dcrocker.net> <4F5E3148.50507@stpeter.im> 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: draft-ietf-appsawg-xdash.all@tools.ietf.org, The IESG , apps-discuss@ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-appswg-xdash-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 12 Mar 2012 18:24:12 -0000 --On Monday, March 12, 2012 11:24 -0600 Peter Saint-Andre wrote: >... >> If the answer to the first two questions is not "yes", then >> the application is probably not "private use". The third >> question further qualifies the situation; if the answer to >> all three is "yes", then the application is almost certainly >> private use. > John, your description helps to clarify the notion of private > use, which this I-D currently uses but does not define > (perhaps assuming that people know it when they see it). I had assumed the latter too, but some of the earlier correspondence led me to the conclusion that maybe I was wrong and that people could not, in practice, distinguish private use from the other cases. > To apply that notion to the subject matter of this I-D, do you > think that the "X-" prefix or a similar construct is needed to > mark off private-use parameters? Or would you find it > acceptable for folks needing private-use parameters to follow > the guidelines mentioned in Appendix B? (The following text is > copied from our working version, which might be slightly > different from what's in -03.) > >### > > In some situations, segregating the parameter name space > used in a given application protocol can be justified: > > 1. When it is extremely unlikely that some parameters will > ever be standardized. In this case > implementation-specific and private- use parameters > could at least incorporate the organization's name > (e.g., "ExampleInc-foo" or, consistent with [RFC4288], > "VND.ExampleInc.foo") or primary domain name (e.g., > "com.example.foo" or a Uniform Resource Identifier [RFC3986] > such as "http://example.com/foo"). In rare cases, > truly experimental parameters could be given > meaningless names such as nonsense words, the output of > a hash function, or UUIDs [RFC4122]. > >### At the risk of being facetious, the answers to both "is the construct needed" and to "are the Appendix B guidelines sufficient" is "yes". To answer Pete's question, I don't think the tradeoffs in this have been adequately examined in the WG and earlier discussions. I think it is more important that examination occur, and preferably be described in the document, than that there be any particular answer. I am, to some extent, trying to play devil's advocate for a position I think is relevant but that has not, IMO, been sufficiently discussed in the rush to get rid of "X-" entirely. To be specific about the range of ways in which the document could satisfy my concerns (without necessarily making me completely happy), I believe Appendix B would be a lot stronger if its introduction said something equivalent to "as long as what you are doing is really and exclusively private use, there is nothing to prevent you from using the 'X-' convention or anything else. Nonetheless, we believe you would be better off using one of the conventions outlined in this section to further reduce the odds of ambiguity". That goes a bit further than "segregating the name space", which may not mean the same thing to everyone. Indeed, the private-use folks may not see "X-" as a segregation of the name space as much as a "hands off unless you are part of a prior agreement" warning. Note that "ExampleInc-foo", "com.example.foo", and so on do not provide that warning because ExampleInc could easily and sensibly have ExampleInc-foo (private use) ExampleInc-bar (public use, described in ExampleInc's documentation, but not registered with IANA) ExampleInc-baz (registered with IANA) I believe that trying to distinguish between the latter two --by syntax or otherwise-- is hopeless and counterproductive. But the first one does seem really different to me, different enough to justify X-foo or X-ExampleInc-foo. >>> 2. What specific benefits accrue from providing for these >>> cases? >> >> Non-conflicting use or, more specifically, a warning about >> possible conflicting use, of commands, parameters or fields >> that are clearly private and that will not be registered >> and/or publicly explained no matter how much we change the >> registration rules. See above for a bit more about the "warning" distinction which, unless we can successfully require registration of all non-private uses, would seem to me to benefit from some specific syntax. Again, I don't see the absence of such syntax as a showstopper, largely because the private use folks will do whatever they want to do. At the same time, I believe making a prohibition that will be ignored is not in the IETF's collective best interest. What is and is not reasonable for private use (and ultimately whether Appendix B is realistic) involves a problem I don't think we know how to talk about. I think it would be easy to get very broad consensus agreement in the IETF for statements like "security by obscurity is bad" or "security by obscurity doesn't provide much protection". On the other hand, the number of people who could honestly say that they had never relied on obscurity as part of a security strategy, or incorporated some obscure characteristics into a protocol in the hope of strengthening or improving its performance it slightly, would be, I think _much_ smaller. Whether or not the Appendix B suggestions are likely to be followed probably depends a great deal on whether an implementer believes that disclosure of the company name increases the risk, even slightly. Of course, creating a hash or partially-nonsense string would eliminate that problem. But, in practice, if someone sees the string as truly private use, I just don't see that happening. Ever. >... >>> 3. What specific problems accrue from the provisions in the >>> current draft? >> >> The current draft deprecates the use of "X" and "X-", even in >> those private use cases and does so without providing any >> practical recommendation about how to avoid conflicts. > > I think the text quoted above does provide several practical > recommendations about how to avoid conflicts: incorporate the > name or domain name of the organization that has minted the > private-use parameter, or in rare cases even create a nonsense > string, use the output of a hash function, or generate a UUID. See above. >... best, john From ned.freed@mrochek.com Mon Mar 12 11:50:11 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E26321F89B6; Mon, 12 Mar 2012 11:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XoB8zuWO52kb; Mon, 12 Mar 2012 11:50:09 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id CCC2721F8649; Mon, 12 Mar 2012 11:50:09 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OD0ZNP8BEO007XB7@mauve.mrochek.com>; Mon, 12 Mar 2012 11:50:03 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OCPMUVDUMO00ZUIL@mauve.mrochek.com>; Mon, 12 Mar 2012 11:49:59 -0700 (PDT) Message-id: <01OD0ZNMUTC000ZUIL@mauve.mrochek.com> Date: Mon, 12 Mar 2012 11:35:47 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Mon, 12 Mar 2012 14:23:57 -0400" <4DE92D3E19AFC20A87DCCC2E@PST.JCK.COM> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <62FF481C5AD21C3F683CD2B9@PST.JCK.COM> <4F5B9FF5.7040209@dcrocker.net> <4F5BA20D.30304@qualcomm.com> <4F5C1CCE.6020706@dcrocker.net> <4F5C1E10.6000909@qualcomm.com> <4F5C1EFE.4070301@dcrocker.net> <4F5C236F.40003@qualcomm.com> <04886CA63CB9FA84DC8CA8B9@PST.JCK.COM> <4F5CEBD6.7090002@dcrocker.net> <4F5E3148.50507@stpeter.im> <4DE92D3E19AFC20A87DCCC2E@PST.JCK.COM> To: John C Klensin DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1331578204; bh=WeD+iI1wEbMMltkcVD9iVjXUwn5iDjKkut5t9c8ntKw=; h=Cc:Message-id:Date:From:Subject:In-reply-to:MIME-version: Content-type:References:To; b=Z/m5efPumoRdhubjI2l5kNc+RzrrB4Rg+cEQnkgQDBej1lmTsloGGzQyXRZ6ypSRU 341pGdFZNyBEY5b6zKIl1IhmB+Og1yT6vfJdWyzulELOy3Hz2XbNYpkWSTIJqYfuI8 y4yoPFqAPmgEiWIMHLDUdD4nAZ/MxFATrQh1odi4= Cc: draft-ietf-appsawg-xdash.all@tools.ietf.org, apps-discuss@ietf.org, The IESG Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-appswg-xdash-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 12 Mar 2012 18:50:11 -0000 > > John, your description helps to clarify the notion of private > > use, which this I-D currently uses but does not define > > (perhaps assuming that people know it when they see it). > I had assumed the latter too, but some of the earlier > correspondence led me to the conclusion that maybe I was wrong > and that people could not, in practice, distinguish private use > from the other cases. I don't think the problem has much to do with people's ability to discern the difference. I think they're well aware of that, but either: (1) They think their application meets the private use criteria, and it may even meet them at the time the choice is made, but later events conspire to falsify that conclusion, (2) They want to develop something in private and if successful transition to public identifiers, but seriously underestimate the difficulty of making that transition, (3) They would like to do the right thing, but percieve, rightly or wrongly, that the barriers to entry are too high, or (3) They're the sort who take the path of least immediate resistance, long term consequences be damned. And finally, there's the more general case of someone who is completely unaware of any of the rules and simply apes what they see someone else doing. This is actually quite different from being aware of the rules but not understanding them. We may be able to address the lack of understanding, but it's hard to get the horse to drink our koolaide when it doesn't know that the pitcher exists. (How's that for a mixed metaphor?) I think if you analyze the various subcases of spaces where we've seen flagrant abuse of x- names, including but not limited to media types and email headers, you'll find it isn't any one thing, but a combination of factors, probably including some I haven't thought to list here. And no, this doesn't answer the question of what do to to clean up existing messes. But it does suggest that in cases where names are plentiful defining a private use space naming convention may be a bad idea for reasons we have no control over. Ned From stpeter@stpeter.im Mon Mar 12 12:02:07 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16BA821E8067; Mon, 12 Mar 2012 12:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.715 X-Spam-Level: X-Spam-Status: No, score=-102.715 tagged_above=-999 required=5 tests=[AWL=-0.116, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FwKOFdMGX2ES; Mon, 12 Mar 2012 12:02:06 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id C7F0321F8A23; Mon, 12 Mar 2012 12:01:59 -0700 (PDT) Received: from squire.local (unknown [64.101.72.114]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 355DD40058; Mon, 12 Mar 2012 13:14:15 -0600 (MDT) Message-ID: <4F5E4825.6030503@stpeter.im> Date: Mon, 12 Mar 2012 13:01:57 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Ned Freed References: <62FF481C5AD21C3F683CD2B9@PST.JCK.COM> <4F5B9FF5.7040209@dcrocker.net> <4F5BA20D.30304@qualcomm.com> <4F5C1CCE.6020706@dcrocker.net> <4F5C1E10.6000909@qualcomm.com> <4F5C1EFE.4070301@dcrocker.net> <4F5C236F.40003@qualcomm.com> <04886CA63CB9FA84DC8CA8B9@PST.JCK.COM> <4F5CEBD6.7090002@dcrocker.net> <4F5E3148.50507@stpeter.im> <4DE92D3E19AFC20A87DCCC2E@PST.JCK.COM> <01OD0ZNMUTC000ZUIL@mauve.mrochek.com> In-Reply-To: <01OD0ZNMUTC000ZUIL@mauve.mrochek.com> X-Enigmail-Version: 1.3.5 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: draft-ietf-appsawg-xdash.all@tools.ietf.org, The IESG , apps-discuss@ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-appswg-xdash-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 12 Mar 2012 19:02:07 -0000 On 3/12/12 12:35 PM, Ned Freed wrote: >>> John, your description helps to clarify the notion of private >>> use, which this I-D currently uses but does not define >>> (perhaps assuming that people know it when they see it). > >> I had assumed the latter too, but some of the earlier >> correspondence led me to the conclusion that maybe I was wrong >> and that people could not, in practice, distinguish private use >> from the other cases. > > I don't think the problem has much to do with people's ability to discern the > difference. I think they're well aware of that, but either: > > (1) They think their application meets the private use criteria, and it may > even meet them at the time the choice is made, but later events > conspire to falsify that conclusion, > > (2) They want to develop something in private and if successful transition > to public identifiers, but seriously underestimate the difficulty of > making that transition, > > (3) They would like to do the right thing, but percieve, rightly or wrongly, > that the barriers to entry are too high, or > > (3) They're the sort who take the path of least immediate resistance, > long term consequences be damned. > > And finally, there's the more general case of someone who is completely unaware > of any of the rules and simply apes what they see someone else doing. This is > actually quite different from being aware of the rules but not understanding > them. We may be able to address the lack of understanding, but it's hard to get > the horse to drink our koolaide when it doesn't know that the pitcher exists. > (How's that for a mixed metaphor?) I think your more general case is the most common. Someone creates a parameter and unthinkingly slaps an "X-" on the front because that's what everyone else has done, or because they don't want to be seen as presumptuous about the status of their little extension (which often enough becomes a big extension). > I think if you analyze the various subcases of spaces where we've seen flagrant > abuse of x- names, including but not limited to media types and email headers, > you'll find it isn't any one thing, but a combination of factors, probably > including some I haven't thought to list here. > > And no, this doesn't answer the question of what do to to clean up existing > messes. This I-D decidedly does not attempt to clean out that Augean stable. > But it does suggest that in cases where names are plentiful defining a > private use space naming convention may be a bad idea for reasons we have no > control over. Agreed. Peter -- Peter Saint-Andre https://stpeter.im/ From dcrocker@bbiw.net Mon Mar 12 12:07:29 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BE7321F8A36; Mon, 12 Mar 2012 12:07:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.01 X-Spam-Level: X-Spam-Status: No, score=-6.01 tagged_above=-999 required=5 tests=[AWL=-0.412, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_BACKHAIR_27=1, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i4I-4zRKshPx; Mon, 12 Mar 2012 12:07:27 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id DDD7721F8A37; Mon, 12 Mar 2012 12:07:27 -0700 (PDT) Received: from com.flipdogsolutions (adsl-67-127-58-62.dsl.pltn13.pacbell.net [67.127.58.62]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q2CJ7Ldb027455 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 12 Mar 2012 12:07:27 -0700 Date: Mon, 12 Mar 2012 12:07:24 -0700 (PDT) From: Dave Crocker To: Peter Saint-Andre , Ned Freed Message-ID: In-Reply-To: <4F5E4825.6030503@stpeter.im> References: <62FF481C5AD21C3F683CD2B9@PST.JCK.COM> <4F5B9FF5.7040209@dcrocker.net> <4F5BA20D.30304@qualcomm.com> <4F5C1CCE.6020706@dcrocker.net> <4F5C1E10.6000909@qualcomm.com> <4F5C1EFE.4070301@dcrocker.net> <4F5C236F.40003@qualcomm.com> <04886CA63CB9FA84DC8CA8B9@PST.JCK.COM> <4F5CEBD6.7090002@dcrocker.net> <4F5E3148.50507@stpeter.im> <4DE92D3E19AFC20A87DCCC2E@PST.JCK.COM> <01OD0ZNMUTC000ZUIL@mauve.mrochek.com> <4F5E4825.6030503@stpeter.im> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_0_1089180016.1331579245471" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 12 Mar 2012 12:07:27 -0700 (PDT) Cc: draft-ietf-appsawg-xdash.all@tools.ietf.org, The IESG , apps-discuss@ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-appswg-xdash-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 12 Mar 2012 19:07:29 -0000 ------=_Part_0_1089180016.1331579245471 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Ned's note is a nice survey of 'reasons'. /d -- Dave Crocker bbiw.net -----Original Message----- From: Peter Saint-Andre To: Ned Freed Cc: John C Klensin , draft-ietf-appsawg-xdash.all@tools.ietf.org, apps-discuss@ietf.org, The IESG Sent: Mon, 12 Mar 2012 12:01 PM Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-appswg-xdash-03 On 3/12/12 12:35 PM, Ned Freed wrote: >>> John, your description helps to clarify the notion of private >>> use, which this I-D currently uses but does not define >>> (perhaps assuming that people know it when they see it). > >> I had assumed the latter too, but some of the earlier >> correspondence led me to the conclusion that maybe I was wrong >> and that people could not, in practice, distinguish private use >> from the other cases. > > I don't think the problem has much to do with people's ability to discern the > difference. I think they're well aware of that, but either: > > (1) They think their application meets the private use criteria, and it may > even meet them at the time the choice is made, but later events > conspire to falsify that conclusion, > > (2) They want to develop something in private and if successful transition > to public identifiers, but seriously underestimate the difficulty of > making that transition, > > (3) They would like to do the right thing, but percieve, rightly or wrongly, > that the barriers to entry are too high, or > > (3) They're the sort who take the path of least immediate resistance, > long term consequences be damned. > > And finally, there's the more general case of someone who is completely unaware > of any of the rules and simply apes what they see someone else doing. This is > actually quite different from being aware of the rules but not understanding > them. We may be able to address the lack of understanding, but it's hard to get > the horse to drink our koolaide when it doesn't know that the pitcher exists. > (How's that for a mixed metaphor?) I think your more general case is the most common. Someone creates a parameter and unthinkingly slaps an "X-" on the front because that's what everyone else has done, or because they don't want to be seen as presumptuous about the status of their little extension (which often enough becomes a big extension). > I think if you analyze the various subcases of spaces where we've seen flagrant > abuse of x- names, including but not limited to media types and email headers, > you'll find it isn't any one thing, but a combination of factors, probably > including some I haven't thought to list here. > > And no, this doesn't answer the question of what do to to clean up existing > messes. This I-D decidedly does not attempt to clean out that Augean stable. > But it does suggest that in cases where names are plentiful defining a > private use space naming convention may be a bad idea for reasons we have no > control over. Agreed. Peter -- Peter Saint-Andre https://stpeter.im/ ------=_Part_0_1089180016.1331579245471 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Ned's note is a nice survey of 'reasons'.


/d

--

Dave Crocker
bbiw.net



-----Original Message-----
From: Peter Saint-Andre <stpeter@stpeter.im>
To: Ned Freed <ned.freed@mrochek.com>
Cc: John C Klensin <john-ietf@jck.com>, draft-ietf-appsawg-xdash.all@tools.ietf.org, apps-discuss@ietf.org, The IESG <iesg@ietf.org>
Sent: Mon, 12 Mar 2012 12:01 PM
Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-appswg-xdash-03

On 3/12/12 12:35 PM, Ned Freed wrote:
>>> John, your description helps to clarify the notion of private
>>> use, which this I-D currently uses but does not define
>>> (perhaps assuming that people know it when they see it).
>
>> I had assumed the latter too, but some of the earlier
>> correspondence led me to the conclusion that maybe I was wrong
>> and that people could not, in practice, distinguish private use
>> from the other cases.
>
> I don't think the problem has much to do with people's ability to discern the
> difference. I think they're well aware of that, but either:
>
> (1) They think their application meets the private use criteria, and it may
>     even meet them at the time the choice is made, but later events
>     conspire to falsify that conclusion,
>
> (2) They want to develop something in private and if successful transition
>     to public identifiers, but seriously underestimate the difficulty of
>     making that transition,
>
> (3) They would like to do the right thing, but percieve, rightly or wrongly,
>     that the barriers to entry are too high, or
>
> (3) They're the sort who take the path of least immediate resistance,
>     long term consequences be damned.
>
> And finally, there's the more general case of someone who is completely unaware
> of any of the rules and simply apes what they see someone else doing. This is
> actually quite different from being aware of the rules but not understanding
> them. We may be able to address the lack of understanding, but it's hard to get
> the horse to drink our koolaide when it doesn't know that the pitcher exists.
> (How's that for a mixed metaphor?)

I think your more general case is the most common. Someone creates a
parameter and unthinkingly slaps an "X-" on the front because that's
what everyone else has done, or because they don't want to be seen as
presumptuous about the status of their little extension (which often
enough becomes a big extension).

> I think if you analyze the various subcases of spaces where we've seen flagrant
> abuse of x- names, including but not limited to media types and email headers,
> you'll find it isn't any one thing, but a combination of factors, probably
> including some I haven't thought to list here.
>
> And no, this doesn't answer the question of what do to to clean up existing
> messes.

This I-D decidedly does not attempt to clean out that Augean stable.

> But it does suggest that in cases where names are plentiful defining a
> private use space naming convention may be a bad idea for reasons we have no
> control over.

Agreed.

Peter

--
Peter Saint-Andre
https://stpeter.im/

------=_Part_0_1089180016.1331579245471-- From stpeter@stpeter.im Mon Mar 12 12:15:06 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10C7E21F8618; Mon, 12 Mar 2012 12:15:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.714 X-Spam-Level: X-Spam-Status: No, score=-102.714 tagged_above=-999 required=5 tests=[AWL=-0.115, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KSNPWCgDzfCP; Mon, 12 Mar 2012 12:15:04 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B3AF921F88FF; Mon, 12 Mar 2012 12:15:04 -0700 (PDT) Received: from squire.local (unknown [64.101.72.114]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7545840058; Mon, 12 Mar 2012 13:27:20 -0600 (MDT) Message-ID: <4F5E4B37.4030705@stpeter.im> Date: Mon, 12 Mar 2012 13:15:03 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: John C Klensin References: <62FF481C5AD21C3F683CD2B9@PST.JCK.COM> <4F5B9FF5.7040209@dcrocker.net> <4F5BA20D.30304@qualcomm.com> <4F5C1CCE.6020706@dcrocker.net> <4F5C1E10.6000909@qualcomm.com> <4F5C1EFE.4070301@dcrocker.net> <4F5C236F.40003@qualcomm.com> <04886CA63CB9FA84DC8CA8B9@PST.JCK.COM> <4F5CEBD6.7090002@dcrocker.net> <4F5E3148.50507@stpeter.im> <4DE92D3E19AFC20A87DCCC2E@PST.JCK.COM> In-Reply-To: <4DE92D3E19AFC20A87DCCC2E@PST.JCK.COM> X-Enigmail-Version: 1.3.5 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: draft-ietf-appsawg-xdash.all@tools.ietf.org, The IESG , apps-discuss@ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-appswg-xdash-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 12 Mar 2012 19:15:06 -0000 On 3/12/12 12:23 PM, John C Klensin wrote: > > > --On Monday, March 12, 2012 11:24 -0600 Peter Saint-Andre > wrote: > >> ... >>> If the answer to the first two questions is not "yes", then >>> the application is probably not "private use". The third >>> question further qualifies the situation; if the answer to >>> all three is "yes", then the application is almost certainly >>> private use. > >> John, your description helps to clarify the notion of private >> use, which this I-D currently uses but does not define >> (perhaps assuming that people know it when they see it). > > I had assumed the latter too, but some of the earlier > correspondence led me to the conclusion that maybe I was wrong > and that people could not, in practice, distinguish private use > from the other cases. > >> To apply that notion to the subject matter of this I-D, do you >> think that the "X-" prefix or a similar construct is needed to >> mark off private-use parameters? Or would you find it >> acceptable for folks needing private-use parameters to follow >> the guidelines mentioned in Appendix B? (The following text is >> copied from our working version, which might be slightly >> different from what's in -03.) >> >> ### >> >> In some situations, segregating the parameter name space >> used in a given application protocol can be justified: >> >> 1. When it is extremely unlikely that some parameters will >> ever be standardized. In this case >> implementation-specific and private- use parameters >> could at least incorporate the organization's name >> (e.g., "ExampleInc-foo" or, consistent with [RFC4288], >> "VND.ExampleInc.foo") or primary domain name (e.g., >> "com.example.foo" or a Uniform Resource Identifier [RFC3986] >> such as "http://example.com/foo"). In rare cases, >> truly experimental parameters could be given >> meaningless names such as nonsense words, the output of >> a hash function, or UUIDs [RFC4122]. >> >> ### > > At the risk of being facetious, the answers to both "is the > construct needed" and to "are the Appendix B guidelines > sufficient" is "yes". > > To answer Pete's question, I don't think the tradeoffs in this > have been adequately examined in the WG and earlier discussions. > I think it is more important that examination occur, and > preferably be described in the document, than that there be any > particular answer. I am, to some extent, trying to play devil's > advocate for a position I think is relevant but that has not, > IMO, been sufficiently discussed in the rush to get rid of "X-" > entirely. > > To be specific about the range of ways in which the document > could satisfy my concerns (without necessarily making me > completely happy), I believe Appendix B would be a lot stronger > if its introduction said something equivalent to "as long as > what you are doing is really and exclusively private use, there > is nothing to prevent you from using the 'X-' convention or > anything else. Nonetheless, we believe you would be better off > using one of the conventions outlined in this section to further > reduce the odds of ambiguity". > > That goes a bit further than "segregating the name space", which > may not mean the same thing to everyone. Indeed, the > private-use folks may not see "X-" as a segregation of the name > space as much as a "hands off unless you are part of a prior > agreement" warning. Note that "ExampleInc-foo", > "com.example.foo", and so on do not provide that warning because > ExampleInc could easily and sensibly have > > ExampleInc-foo (private use) > ExampleInc-bar (public use, described in ExampleInc's > documentation, but not registered with IANA) > ExampleInc-baz (registered with IANA) > > I believe that trying to distinguish between the latter two --by > syntax or otherwise-- is hopeless and counterproductive. But > the first one does seem really different to me, different enough > to justify X-foo or X-ExampleInc-foo. Interesting. I had not seen it that way, so thank you for the new perspective. I now need to think about it a bit more. My first reaction is that I think few people perceive "X-" as a hands-off warning (it's much more cryptic than those silly email footers about the message being intended only for the addressee), but I suppose that such a notion might be floating around in the heads of some people who have created such parameters. >>>> 2. What specific benefits accrue from providing for these >>>> cases? >>> >>> Non-conflicting use or, more specifically, a warning about >>> possible conflicting use, of commands, parameters or fields >>> that are clearly private and that will not be registered >>> and/or publicly explained no matter how much we change the >>> registration rules. > > See above for a bit more about the "warning" distinction which, > unless we can successfully require registration of all > non-private uses, would seem to me to benefit from some specific > syntax. Again, I don't see the absence of such syntax as a > showstopper, largely because the private use folks will do > whatever they want to do. At the same time, I believe making a > prohibition that will be ignored is not in the IETF's collective > best interest. > > What is and is not reasonable for private use (and ultimately > whether Appendix B is realistic) involves a problem I don't > think we know how to talk about. I think it would be easy to > get very broad consensus agreement in the IETF for statements > like "security by obscurity is bad" or "security by obscurity > doesn't provide much protection". On the other hand, the number > of people who could honestly say that they had never relied on > obscurity as part of a security strategy, or incorporated some > obscure characteristics into a protocol in the hope of > strengthening or improving its performance it slightly, would > be, I think _much_ smaller. If they're being honest, yes. :) > Whether or not the Appendix B > suggestions are likely to be followed probably depends a great > deal on whether an implementer believes that disclosure of the > company name increases the risk, even slightly. > > Of course, creating a hash or partially-nonsense string would > eliminate that problem. But, in practice, if someone sees the > string as truly private use, I just don't see that happening. > Ever. Perhaps we are, indeed, merely tilting at windmills there. Given that the I-D cutoff is less than 5 hours from now and you have raised an issue that needs further airing, I will submit -04 today (which addresses other issues that folks have raised) so that we have a clear baseline, then circle back to this private use issue again in the coming days. Peter -- Peter Saint-Andre https://stpeter.im/ From john-ietf@jck.com Mon Mar 12 12:15:21 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1E7121F8618; Mon, 12 Mar 2012 12:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.776 X-Spam-Level: X-Spam-Status: No, score=-102.776 tagged_above=-999 required=5 tests=[AWL=-0.177, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ydw3DQvSasci; Mon, 12 Mar 2012 12:15:20 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 01B8D21F85AC; Mon, 12 Mar 2012 12:15:19 -0700 (PDT) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1S7AdV-000LWJ-8h; Mon, 12 Mar 2012 15:10:25 -0400 Date: Mon, 12 Mar 2012 15:15:04 -0400 From: John C Klensin To: Peter Saint-Andre , Ned Freed Message-ID: <40626365C6934FA8A9EFFEF9@PST.JCK.COM> In-Reply-To: <4F5E4825.6030503@stpeter.im> References: <62FF481C5AD21C3F683CD2B9@PST.JCK.COM> <4F5B9FF5.7040209@dcrocker.net> <4F5BA20D.30304@qualcomm.com> <4F5C1CCE.6020706@dcrocker.net> <4F5C1E10.6000909@qualcomm.com> <4F5C1EFE.4070301@dcrocker.net> <4F5C236F.40003@qualcomm.com> <04886CA63CB9FA84DC8CA8B9@PST.JCK.COM> <4F5CEBD6.7090002@dcrocker.net> <4F5E3148.50507@stpeter.im> <4DE92D3E19AFC20A87DCCC2E@PST.JCK.COM> <01OD0ZNMUTC000ZUIL@mauve.mrochek.com> <4F5E4825.6030503@stpeter.im> 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: draft-ietf-appsawg-xdash.all@tools.ietf.org, The IESG , apps-discuss@ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-appswg-xdash-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 12 Mar 2012 19:15:21 -0000 --On Monday, March 12, 2012 13:01 -0600 Peter Saint-Andre wrote: > On 3/12/12 12:35 PM, Ned Freed wrote: >>>> John, your description helps to clarify the notion of >>>> private use, which this I-D currently uses but does not >>>> define (perhaps assuming that people know it when they see >>>> it). >> >>> I had assumed the latter too, but some of the earlier >>> correspondence led me to the conclusion that maybe I was >>> wrong and that people could not, in practice, distinguish >>> private use from the other cases. >> >> I don't think the problem has much to do with people's >> ability to discern the difference. I think they're well aware >> of that, but either: >> >> (1) They think their application meets the private use >> criteria, and it may even meet them at the time the choice is >> made, but later events conspire to falsify that >> conclusion, >> >> (2) They want to develop something in private and if >> successful transition to public identifiers, but seriously >> underestimate the difficulty of making that transition, >> >> (3) They would like to do the right thing, but percieve, >> rightly or wrongly, that the barriers to entry are too high, >> or >> >> (3) They're the sort who take the path of least immediate >> resistance, long term consequences be damned. >> >> And finally, there's the more general case of someone who is >> completely unaware of any of the rules and simply apes what >> they see someone else doing. This is actually quite different >> from being aware of the rules but not understanding them. We >> may be able to address the lack of understanding, but it's >> hard to get the horse to drink our koolaide when it doesn't >> know that the pitcher exists. (How's that for a mixed >> metaphor?) > > I think your more general case is the most common. Someone > creates a parameter and unthinkingly slaps an "X-" on the > front because that's what everyone else has done, or because > they don't want to be seen as presumptuous about the status of > their little extension (which often enough becomes a big > extension). First of all, this is exactly the discussion I wanted to see. I care much less about how it comes out than I do about being sure it occurred even though I'd prefer that it be reflected in the document. That said, if that more general case applies, there is absolutely no reason to expect that this specification will have any impact whatsoever on what those people do, so neither the text in Appendix B nor my suggested guidance about how to figure out if something is "private use" are particularly meaningful, rather than just provide more KoolAid for the unseen pitcher. I think that implies we should either do more (explain the situation even more carefully in Appendix B or elsewhere in the hope that, despite our experience, someone relevant will read it) or do less (reduce Appendix B to a simple statement that, while the document cannot apply to actual private use cases, those cases are lots less frequent than people often believe and that is it usually best to construct names on the assumption (however unlikely it may appear) that they will eventually become public enough that registration is desirable. >> I think if you analyze the various subcases of spaces where >> we've seen flagrant abuse of x- names, including but not >> limited to media types and email headers, you'll find it >> isn't any one thing, but a combination of factors, probably >> including some I haven't thought to list here. While I completely agree with that, I remain concerned about the cases that are not abuses of x- names, flagrant or otherwise. >> And no, this doesn't answer the question of what do to to >> clean up existing messes. > > This I-D decidedly does not attempt to clean out that Augean > stable. > >> But it does suggest that in cases where names are plentiful >> defining a private use space naming convention may be a bad >> idea for reasons we have no control over. > > Agreed. It also suggests that, for reasons we have no control over, trying to prohibit that usage is pretty hopeless... at least unless one can get the horse's nose into the pitcher well past the nostrils. Based on experience, if one decides to try that, one should be very sure to not be within kicking range. john From john-ietf@jck.com Mon Mar 12 12:25:58 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C82F921E803A; Mon, 12 Mar 2012 12:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.769 X-Spam-Level: X-Spam-Status: No, score=-102.769 tagged_above=-999 required=5 tests=[AWL=-0.170, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFcFOp22Cp0q; Mon, 12 Mar 2012 12:25:58 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 8B47921E8071; Mon, 12 Mar 2012 12:25:57 -0700 (PDT) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1S7Ann-000LXc-8E; Mon, 12 Mar 2012 15:21:03 -0400 Date: Mon, 12 Mar 2012 15:25:43 -0400 From: John C Klensin To: Peter Saint-Andre Message-ID: <6E2ADB086ECCDD50E1D4D4CB@PST.JCK.COM> In-Reply-To: <4F5E4B37.4030705@stpeter.im> References: <62FF481C5AD21C3F683CD2B9@PST.JCK.COM> <4F5B9FF5.7040209@dcrocker.net> <4F5BA20D.30304@qualcomm.com> <4F5C1CCE.6020706@dcrocker.net> <4F5C1E10.6000909@qualcomm.com> <4F5C1EFE.4070301@dcrocker.net> <4F5C236F.40003@qualcomm.com> <04886CA63CB9FA84DC8CA8B9@PST.JCK.COM> <4F5CEBD6.7090002@dcrocker.net> <4F5E3148.50507@stpeter.im> <4DE92D3E19AFC20A87DCCC2E@PST.JCK.COM> <4F5E4B37.4030705@stpeter.im> 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: draft-ietf-appsawg-xdash.all@tools.ietf.org, The IESG , apps-discuss@ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-appswg-xdash-03 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 12 Mar 2012 19:25:59 -0000 --On Monday, March 12, 2012 13:15 -0600 Peter Saint-Andre wrote: > Given that the I-D cutoff is less than 5 hours from now and > you have raised an issue that needs further airing, I will > submit -04 today (which addresses other issues that folks have > raised) so that we have a clear baseline, then circle back to > this private use issue again in the coming days. Wfm. Thanks. john From internet-drafts@ietf.org Mon Mar 12 12:54:53 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BC9321F8910; Mon, 12 Mar 2012 12:54:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WE0Q16BVg0Tr; Mon, 12 Mar 2012 12:54:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A140121F88A8; Mon, 12 Mar 2012 12:54:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120312195452.11143.79991.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2012 12:54:52 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-xdash-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 12 Mar 2012 19:54:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Worki= ng Group of the IETF. Title : Deprecating the X- Prefix and Similar Constructs in Appl= ication Protocols Author(s) : Peter Saint-Andre D. Crocker Mark Nottingham Filename : draft-ietf-appsawg-xdash-04.txt Pages : 12 Date : 2012-03-12 Historically, designers and implementers of application protocols have often distinguished between "standard" and "non-standard" parameters by prefixing the names of "non-standard" parameters with the string "X-" or similar constructs. In practice, that convention causes more problems than it solves. Therefore, this document deprecates the convention for the names of newly-defined textual parameters in application protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-appsawg-xdash-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-appsawg-xdash-04.txt From macar@cloudmark.com Mon Mar 12 13:53:48 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2550121F8A03 for ; Mon, 12 Mar 2012 13:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uX4iSQ86V2m6 for ; Mon, 12 Mar 2012 13:53:47 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id D494821F86F9 for ; Mon, 12 Mar 2012 13:53:42 -0700 (PDT) Received: from [172.20.2.21] (172.20.2.21) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 12 Mar 2012 13:53:42 -0700 Message-ID: <4F5E6255.9040402@cloudmark.com> Date: Mon, 12 Mar 2012 13:53:41 -0700 From: Mike Acar User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: References: <9F0A2492-AE7D-4C12-8BB0-13489FD7F6C1@gmail.com> <1331271383.6504.1.camel@neutron> In-Reply-To: <1331271383.6504.1.camel@neutron> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.20.2.21] Subject: Re: [apps-discuss] draft-pbryan-json-patch-04 - comments X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 12 Mar 2012 20:53:48 -0000 Hi, On 03/08/2012 09:36 PM, Paul C. Bryan wrote: > On Thu, 2012-03-08 at 13:46 -0800, Vadim Zaliva wrote: >> I was looking for JSON patch formats available and found this draft. >> It looks nice - concise and to the point. I would like to share few >> comments I have. >> >> 1. I am not sure if 'test' operation should be part of it. The purpose >> of the patch is to modify the document. 'test' operation either >> succeeds of fails, but it is unclear how this information will be >> communicated or used. It almost looks like a API operation rather than >> patch format instruction. I'm unsure about test as well. It seems strange to me to express "change this document if it looks like this" in a patch; if the application creating the patch doesn't know how the document looks, how can it create a patch? >> I could see a case when it could be included as a part of conditional >> syntax. In this case 'test' becomes a container for other operations >> which would be executed only if the test succeeds. I'm even more unsure about this. Could you nest them, for example? > I'd be interested in others' views on this. Paul, is there an archived discussion of the "test" operation, particularly regarding use cases? -- Mike Acar - - macar at cloudmark dot com From msk@cloudmark.com Mon Mar 12 13:55:06 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADC7421F8A0B for ; Mon, 12 Mar 2012 13:55:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.603 X-Spam-Level: X-Spam-Status: No, score=-102.603 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5-fAYxVEwRZs for ; Mon, 12 Mar 2012 13:55:05 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id D708621F8A0A for ; Mon, 12 Mar 2012 13:55:05 -0700 (PDT) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Mon, 12 Mar 2012 13:55:05 -0700 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Thread-Topic: [apps-discuss] I-D Action: draft-ietf-appsawg-json-patch-01.txt Thread-Index: AQHM/jrB8PCAcYWHKk608ngo3slf9JZlGoKAgAIMvsA= Date: Mon, 12 Mar 2012 20:55:04 +0000 Message-ID: <9452079D1A51524AA5749AD23E003928086A22@exch-mbx901.corp.cloudmark.com> References: <20120309212231.16366.52439.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-json-patch-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 12 Mar 2012 20:55:06 -0000 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] On Behalf Of Vadim Zaliva > Sent: Saturday, March 10, 2012 10:33 PM > To: apps-discuss@ietf.org > Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-json-patch-01.= txt >=20 > I would like to suggest some extensions to this draft. I was trying to > use proposed syntax in one of my project and found it lacking a couple > of operations. Please find below my proposed extensions: >=20 > Operation "add-unique" >=20 > The new value appended the array only if the it presently does not > contain an element with such value. If an element with such value > already exists, the duplicate will not be added. This feels like feature creep to me. A patch to me is a sequence of steps = for moving some content from one known state to another. This proposed cap= ability allows one to move from an uncertain state to a known state. That = might be a useful thing to do, but it's not something I think of as a "patc= h". > Operation "remove-all" >=20 > This operations removes from array all elements with given value. I have the same concern here. > Operation "replace-all" >=20 > This operations replaces in an array all elements with given value with > a new value. And here. -MSK From msk@cloudmark.com Mon Mar 12 14:13:14 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A620D21F8961 for ; Mon, 12 Mar 2012 14:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.603 X-Spam-Level: X-Spam-Status: No, score=-102.603 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vchHaZSdW57y for ; Mon, 12 Mar 2012 14:13:14 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id 236EE21F8948 for ; Mon, 12 Mar 2012 14:13:14 -0700 (PDT) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Mon, 12 Mar 2012 14:13:13 -0700 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Thread-Topic: [apps-discuss] draft-pbryan-json-patch-04 - comments Thread-Index: AQHM/XVUGAQVraAqCUe8UYuvozCrgpZnLgIw Date: Mon, 12 Mar 2012 21:13:13 +0000 Message-ID: <9452079D1A51524AA5749AD23E003928086A75@exch-mbx901.corp.cloudmark.com> References: <9F0A2492-AE7D-4C12-8BB0-13489FD7F6C1@gmail.com> In-Reply-To: <9F0A2492-AE7D-4C12-8BB0-13489FD7F6C1@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [apps-discuss] draft-pbryan-json-patch-04 - comments X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 12 Mar 2012 21:13:14 -0000 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] On Behalf Of Vadim Zaliva > Sent: Thursday, March 08, 2012 1:46 PM > To: apps-discuss@ietf.org > Subject: [apps-discuss] draft-pbryan-json-patch-04 - comments >=20 > Hi! >=20 > I was looking for JSON patch formats available and found this draft. It > looks nice - concise and to the point. I would like to share few > comments I have. >=20 > 1. I am not sure if 'test' operation should be part of it. The purpose > of the patch is to modify the document. 'test' operation either > succeeds of fails, but it is unclear how this information will be > communicated or used. It almost looks like a API operation rather than > patch format instruction. I would argue that in current state it should > not be included in the format. Maybe I'm too firmly rooted in UNIX patch/diff land, but I don't think I ag= ree. "test" is useful up-front to ensure you're about to modify what you i= ntend to modify, and give you a chance to abort otherwise. In this case, "= test" would be used to confirm you're in a context you want to modify, much= like the lines of context around a traditional UNIX patch. I would say that "test" is not useful except before any add/modify/remove i= nstructions. If it fails to establish context, the whole patch aborts. > 2. In most examples "value" property holds simple scalar values > (strings or integers) or arrays of such. I think it should be possible > to use arbitrary complex JSON data structures as such values. I hope > this was the intention. Perhaps adding an example with more complex > value (object or array) could illustrate this very powerful capability. > For example A.1 could be modified as following; >=20 > An example target JSON document: >=20 > { > "foo": "bar" > } >=20 > A JSON Patch document: >=20 > [ > { "add": "/baz", "value": {"a":1,"b":2} } > ] >=20 > The resulting JSON document: >=20 > { > "baz": {"a":1,"b":2}, > "foo": "bar" > } That seems a reasonable thing to consider. -MSK From internet-drafts@ietf.org Mon Mar 12 14:26:01 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC61811E8132; Mon, 12 Mar 2012 14:26:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BURVrR4tiWfc; Mon, 12 Mar 2012 14:26:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E05811E8116; Mon, 12 Mar 2012 14:26:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120312212601.14363.60166.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2012 14:26:01 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-media-type-regs-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 12 Mar 2012 21:26:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Worki= ng Group of the IETF. Title : Media Type Specifications and Registration Procedures Author(s) : Ned Freed John C. Klensin Tony Hansen Filename : draft-ietf-appsawg-media-type-regs-02.txt Pages : 30 Date : 2012-03-12 This document defines procedures for the specification and registration of media types for use in HTTP, MIME and other Internet protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-appsawg-media-type-regs-02.t= xt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-appsawg-media-type-regs-02.txt From macar@cloudmark.com Mon Mar 12 14:44:22 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E92321E802F for ; Mon, 12 Mar 2012 14:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0x6VSTq30yqn for ; Mon, 12 Mar 2012 14:44:22 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 8422521E804D for ; Mon, 12 Mar 2012 14:44:17 -0700 (PDT) Received: from [172.20.2.21] (172.20.2.21) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 12 Mar 2012 14:44:15 -0700 Message-ID: <4F5E6E2F.4030503@cloudmark.com> Date: Mon, 12 Mar 2012 14:44:15 -0700 From: Mike Acar User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: References: <20120309211833.15339.72914.idtracker@ietfa.amsl.com> In-Reply-To: <20120309211833.15339.72914.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.20.2.21] Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-json-pointer-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 12 Mar 2012 21:44:22 -0000 On 03/09/2012 01:18 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. Typo: In section 4, The member name is equal to the token if it has the same number of Unicode characters as token and their codepoints are positionwise equal. Need a "the" between "as" and "token". You removed one "concrete", but should probably remove the next two. Since the section begins with Evaluation of a JSON Pointer begins with a reference to the root value of a JSON text document the implication is that you're following the pointer and traversing an existing (concrete) object. Actually, I suggest rewriting the paragraph, something like: While evaluating the JSON Pointer, if the implementation does not match the reference token to a member name or array index in the currently-referenced value, then the implementation MAY terminate evaluation with an error condition. That said, I'm still concerned that this behavior interacts badly with Pointers as they're used in JSON Patch. I'll follow up in the patch thread, though. -- Mike Acar - - macar at cloudmark dot com From macar@cloudmark.com Mon Mar 12 14:55:16 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDC4821E80CA for ; Mon, 12 Mar 2012 14:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hQozFpBnd7E6 for ; Mon, 12 Mar 2012 14:55:11 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 4B00121E80C5 for ; Mon, 12 Mar 2012 14:55:11 -0700 (PDT) Received: from [172.20.2.21] (172.20.2.21) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 12 Mar 2012 14:55:10 -0700 Message-ID: <4F5E70BE.9070308@cloudmark.com> Date: Mon, 12 Mar 2012 14:55:10 -0700 From: Mike Acar User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: References: <20120309212231.16366.52439.idtracker@ietfa.amsl.com> In-Reply-To: <20120309212231.16366.52439.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.20.2.21] Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-json-patch-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 12 Mar 2012 21:55:17 -0000 On 03/09/2012 01:22 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > Title : JSON Patch > Author(s) : Paul C. Bryan > Filename : draft-ietf-appsawg-json-patch-01.txt > Pages : 12 > Date : 2012-03-09 This version of the draft doesn't address the bad interaction with the JSON Pointer spec, namely that "add" takes a JSON Pointer to a value which does not yet exist, and the Pointer spec says that in that case, an implementation MAY abort with an error. Is that going to be addressed in -02? -- Mike Acar - - macar at cloudmark dot com From internet-drafts@ietf.org Mon Mar 12 15:14:43 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3514C21F8AA9; Mon, 12 Mar 2012 15:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ripmum+Q4Idf; Mon, 12 Mar 2012 15:14:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75E1221F8930; Mon, 12 Mar 2012 15:14:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120312221442.8779.64953.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2012 15:14:42 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-media-type-regs-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 12 Mar 2012 22:14:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Worki= ng Group of the IETF. Title : Media Type Specifications and Registration Procedures Author(s) : Ned Freed John C. Klensin Tony Hansen Filename : draft-ietf-appsawg-media-type-regs-03.txt Pages : 30 Date : 2012-03-12 This document defines procedures for the specification and registration of media types for use in HTTP, MIME and other Internet protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-appsawg-media-type-regs-03.t= xt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-appsawg-media-type-regs-03.txt From jyee@afilias.info Mon Mar 12 22:16:59 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75C4C21F88B7 for ; Mon, 12 Mar 2012 22:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UHbyVqFwVJRO for ; Mon, 12 Mar 2012 22:16:58 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by ietfa.amsl.com (Postfix) with ESMTP id 42B1021F88B6 for ; Mon, 12 Mar 2012 22:16:55 -0700 (PDT) Received: from ms5.yyz2.afilias-ops.info ([10.50.129.111] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1S7K6Q-0001Gt-4d for Apps-Discuss@ietf.org; Tue, 13 Mar 2012 05:16:54 +0000 Received: from mail-yx0-f178.google.com ([209.85.213.178]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1S7K6Q-0000lb-4A for Apps-Discuss@ietf.org; Tue, 13 Mar 2012 05:16:54 +0000 Received: by yenm14 with SMTP id m14so162556yen.9 for ; Mon, 12 Mar 2012 22:16:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:content-type:content-transfer-encoding:date:subject:to :message-id:mime-version:x-mailer:x-gm-message-state; bh=MOHzRasV9ZUztzmbgUOCVW1VYsL1MRrHPLDwiVVy5Zk=; b=O7eKNgyBmZv0ZS40b8p+2UpmcIpBPoBKOYolm7IwqAF6sweW8F1KqPUjWGfar8rcBl 0AAYJoIKkZFfAaHSzt2DPQSLPwnt5Y6IleXoCDExzDL/zG0QU29o7tpNFu9MH6OLeIK3 isLss07HSZtcq4KHgia42GEp5sYNgk+S2lAjR2Rd2VgVkCyahJAhhZPw0Uqca/p/VK0+ k5/8yEFSKdJDdBbFY1o1mX2IekHGciudx4bXucN+YcV5v0gJrcC5l4wVI/6jQMcdfMyb 00aF6Oj6tqpTDr/Yne3eAATukG1XpEj5bml847wpyGx/ddLXhXLPPUhJf/jSbofEXYo8 zgSQ== Received: by 10.182.86.200 with SMTP id r8mr10482217obz.20.1331615813700; Mon, 12 Mar 2012 22:16:53 -0700 (PDT) Received: from [192.168.0.103] (206-248-164-23.dsl.teksavvy.com. [206.248.164.23]) by mx.google.com with ESMTPS id gl4sm24365367obb.23.2012.03.12.22.16.52 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 12 Mar 2012 22:16:53 -0700 (PDT) From: Joseph Yee Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 13 Mar 2012 01:16:51 -0400 To: Apps-Discuss@ietf.org, draft-moonesamy-rfc2369bis.all@tools.ietf.org Message-Id: <2AEADD20-7074-4321-A838-0034597C522B@afilias.info> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Gm-Message-State: ALoCoQnYvsMcSEk1cAX/898Jvlrp849BHqbokJeSklIL8XV5cNRwCPfLBkWkE8WO7DmHdJzUEeaR Subject: [apps-discuss] APPSDIR review of draft-moonesamy-rfc2369bis-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Mar 2012 05:16:59 -0000 I have been selected as the Applications Area Directorate reviewer for = this draft (for background on appsdir, please see = http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate)= . Please resolve these comments along with any other Last Call comments = you may receive. Please wait for direction from your document shepherd = or AD before posting a new version of the draft. Document: draft-moonesamy-rfc2369bis-04 Title: The Use of URIs as Meta-Syntax for Core Mail List Commands and = their Transport through Message Header Fields Reviewer: Joseph Yee Review Date: March 12, 2012 Summary: This draft is ready for publication as a Standard Tracks Major Issues: none Minor Issues:=20 none Nits:=20 (1) casing in Section 2 - 1st paragraph - 5th line original "being ignored. mailing list managers...." correction "being ignored. Mailing list managers..." From sm@elandsys.com Mon Mar 12 23:15:54 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AF4621F8887 for ; Mon, 12 Mar 2012 23:15:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.596 X-Spam-Level: X-Spam-Status: No, score=-102.596 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zo0MnAxJMjfL for ; Mon, 12 Mar 2012 23:15:49 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD5521F8885 for ; Mon, 12 Mar 2012 23:15:49 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.239.189]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q2D6FYkR010660 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Mar 2012 23:15:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1331619346; i=@elandsys.com; bh=OkvZwoLPkAqea8SkYTwwFDFU1M2YlTFT8Z7e78lkmwk=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=JiacBTrbO9PVE8Svv8twxWD7GEux/LwILdOPUhlGCd6DHDomWxEYKjyg30CGCK/EL QAUikh5Sq4rLvUPHXSdW5LvJZnd9W2R7oDsuAOw/iwn+24HkmAYWtDk652pOw+DjlC nifS6IJEOnA6Mo1kPdHnGFJOCF51pFZ0TlVBlrOo= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1331619346; i=@elandsys.com; bh=OkvZwoLPkAqea8SkYTwwFDFU1M2YlTFT8Z7e78lkmwk=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=HYFcyo3VPG3y88sTiv1I79orBIsTr9mWDblZPoMmhpzjMc28NOweX5VXrSIurESHN dUAKF1lf0IM6gJ3rExpQhsIqNR9O/RizqYVJ179URaqKhszF2q0vYEic4xxIDMutiu XvQW14EzEwtFEg4wsUii8O5ulOBkfyfTfvh5gXHs= Message-Id: <6.2.5.6.2.20120312225727.091804b8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 12 Mar 2012 23:08:56 -0700 To: Joseph Yee From: S Moonesamy In-Reply-To: <2AEADD20-7074-4321-A838-0034597C522B@afilias.info> References: <2AEADD20-7074-4321-A838-0034597C522B@afilias.info> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: draft-moonesamy-rfc2369bis.all@tools.ietf.org, Apps-Discuss@ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-moonesamy-rfc2369bis-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Mar 2012 06:15:54 -0000 Hi Joseph, Thanks for reviewing the draft. At 22:16 12-03-2012, Joseph Yee wrote: >Nits: > (1) casing in Section 2 - 1st paragraph - 5th line > original > "being ignored. mailing list managers...." > correction > "being ignored. Mailing list managers..." I'll fix that in the next revision. Regards, S. Moonesamy From yaojk@cnnic.cn Tue Mar 13 01:22:43 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7884C21F8882 for ; Tue, 13 Mar 2012 01:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.361 X-Spam-Level: X-Spam-Status: No, score=-100.361 tagged_above=-999 required=5 tests=[AWL=0.485, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ah8WQHKaWN+8 for ; Tue, 13 Mar 2012 01:22:42 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by ietfa.amsl.com (Postfix) with SMTP id 2C8AA21F885A for ; Tue, 13 Mar 2012 01:22:39 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown127.0.0.1 (HELO lenovo47e041cf) (127.0.0.1) by 127.0.0.1 with SMTP; Tue, 13 Mar 2012 16:22:32 +0800 Message-ID: From: "Jiankang YAO" To: , Date: Tue, 13 Mar 2012 16:22:33 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: iesg@ietf.org Subject: [apps-discuss] APPSDIR review of draft-ietf-dnsext-dnssec-registry-fixes-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Mar 2012 08:22:43 -0000 SSBoYXZlIGJlZW4gc2VsZWN0ZWQgYXMgdGhlIEFwcGxpY2F0aW9ucyBBcmVhIERpcmVjdG9yYXRl IHJldmlld2VyIA0KZm9yIHRoaXMgZHJhZnQgKGZvciBiYWNrZ3JvdW5kIG9uIGFwcHNkaXIsIHBs ZWFzZSANCnNlZSANCmh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2FyZWEvYXBwL3RyYWMvd2lr aS9BcHBsaWNhdGlvbnNBcmVhRGlyZWN0b3JhdGUgDQopLiAgDQpQbGVhc2UgcmVzb2x2ZSB0aGVz ZSBjb21tZW50cyBhbG9uZyB3aXRoIGFueSBvdGhlciBjb21tZW50cyANCnlvdSBtYXkgcmVjZWl2 ZS4gUGxlYXNlIHdhaXQgZm9yIGRpcmVjdGlvbiBmcm9tIHlvdXIgZG9jdW1lbnQgDQpzaGVwaGVy ZCBvciBBRCBiZWZvcmUgcG9zdGluZyBhIG5ldyB2ZXJzaW9uIG9mIHRoZSBkcmFmdC4NCg0KRG9j dW1lbnQ6IGRyYWZ0LWlldGYtZG5zZXh0LWRuc3NlYy1yZWdpc3RyeS1maXhlcy0wOCANClRpdGxl OiANCkFwcGxpY2FiaWxpdHkgU3RhdGVtZW50OiBETlMgU2VjdXJpdHkgKEROU1NFQykgRE5TS0VZ IEFsZ29yaXRobSBJQU5BIFJlZ2lzdHJ5DQpSZXZpZXdlcjogSmlhbmthbmcgWWFvDQpSZXZpZXcg RGF0ZTogTWFyY2ggMTMsIDIwMTINCg0KU3VtbWFyeToNCg0KVGhpcyBkcmFmdCBpcyB1c2VmdWwu IElmIGl0IGlzIHB1Ymxpc2hlZCwgdGhlIGZvbGxvd2luZyANCmlzc3VlcyBzaG91bGQgYmUgY29u c2lkZXJlZCBvciBhZGRyZXNzZWQgYmVmb3JlIHB1YmxpY2F0aW9uLg0KDQpNaW5vciBpc3N1ZToN Cg0KMSkgVGhlIGludHJvZHVjdGlvbiBzYWlkICJUaGlzIGRvY3VtZW50IHVwZGF0ZXMNCiAgIHRo ZSBmb2xsb3dpbmc6IFtSRkMyNTM2XSwgW1JGQzI1MzldLCBbUkZDMzExMF0sIFtSRkM0MDM0XSwg W1JGQzQzOThdLA0KICAgW1JGQzUxNTVdLCBbUkZDNTcwMl0sIGFuZCBbUkZDNTkzM10uDQoiDQoN Ckl0IHNob3VsZCBhZGRyZXNzIHdoYXQgaXMgdXBkYXRlZCAgaW4gdGhlc2UgUkZDcyBbUkZDMjUz Nl0sIFtSRkMyNTM5XSwgW1JGQzMxMTBdLCBbUkZDNDAzNF0sIFtSRkM0Mzk4XSwgW1JGQzUxNTVd LCBbUkZDNTcwMl0sIGFuZCBbUkZDNTkzM10uDQoNCg0KTml0czoNCg0KVGhpcyBzZW50ZW5jZSBi ZWxvdyBpbiB0aGUgSUFOQSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uIHNob3VsZCBiZSBub3RlZCB3 aXRoICJyZW1vdmVkIHdoZW4gcmZjIGlzIHB1Ymxpc2hlZCIuDQoNCiJJbiB0aGUgY29sdW1uICJD b21wbGlhbmNlIHRvIFJGQyBUQkQiLCAiUkZDIFRCRCIgc2hvdWxkIGJlY2hhbmdlZCB0byB0aGUg b2ZmaWNpYWwgUkZDIHdoZW4gcHVibGlzaGVkLg0KIg0KDQpKaWFua2FuZyBZYW8NCg== From duerst@it.aoyama.ac.jp Tue Mar 13 03:38:55 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B3D821F8674 for ; Tue, 13 Mar 2012 03:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.428 X-Spam-Level: X-Spam-Status: No, score=-100.428 tagged_above=-999 required=5 tests=[AWL=-0.638, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xwPHUpblOoTQ for ; Tue, 13 Mar 2012 03:38:54 -0700 (PDT) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id ED10021F86DD for ; Tue, 13 Mar 2012 03:38:51 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id q2DAcgA5013286 for ; Tue, 13 Mar 2012 19:38:42 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 2bc3_3c3d_b3e491ce_6cf8_11e1_b22f_001d096c5782; Tue, 13 Mar 2012 19:38:42 +0900 Received: from [IPv6:::1] ([133.2.210.1]:51686) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Tue, 13 Mar 2012 19:38:47 +0900 Message-ID: <4F5F23AE.7080404@it.aoyama.ac.jp> Date: Tue, 13 Mar 2012 19:38:38 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: "apps-discuss@ietf.org" , draft-moonesamy-rfc2919bis.all@tools.ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: [apps-discuss] APPSDIR review of draft-moonesamy-rfc2919bis-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Mar 2012 10:38:55 -0000 I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-moonesamy-rfc2919bis-04 Title: List-Id: A Structured Field and Namespace for the Identification of Mailing Lists Reviewer: Martin Dürst Review Date: March 13, 2012 Summary: This draft is close to being ready for publication on Standard Tracks, with the exception of Internationalization concerns, which seem to have been forgotten completely General comment: I'm somewhat unsure about the need for this update. But if somebody is doing the actual work, I don't mind. [After completing this review, I realize that I have probably invested too much work to let the above comment stay. But I definitely didn't want to disappoint our Team Lead.] Major Issues: Internationalization of list identifiers seem to have been completely ignored. How is a list id from an IDN domain used? One option is punycode, but this is really ugly (and would mean MUAs have to translate to readable text). Also, it might make conversion to/from EAI messages a real pain. There is a tension between "the owner of a mailing list MUST NOT generate List Identifiers in any domain name space for which they do not have authority" and "As such the mailing list administrator should avoid changing the List Identifier even when the host serving the mailing list changes.". The MUST NOT is worded more strongly, but I think we want the second part to win in case of conflict. Minor Issues: "List manager" is used throughout the document. When reading, I first associated a person with this term, which was of course confusing. I propose to change to another term or at least to explain the term on its first use. "This document obsoletes RFC 2919 [RFC2919].": I was really wondering here what changed. At least provide a pointer to Appendix B here. "and on other messages where the message clearly applies to this particular distinct mailing list.": It would be good to give a few examples here. I was thinking that this would mean bounce messages, subscription confirmations, and the like, but I wasn't sure I got that right. "This field MUST only be generated by mailing list managers, not MUAs.": What about MTAs? "The contents of the List-Id header field mostly consist of": "mostly consists of" is really confusing. It would be better to give the syntax first, and then discuss the components one-by-one. "As such the mailing list administrator *should* avoid changing the List Identifier even when the host serving the mailing list changes." (and some other instances): Please avoid lower-case normative keywords. They are confusing. (one other example I found: "the MUA *may* inform the user if the descriptive name of a mailing list changes." "On the other hand, transitioning from an informal unmanaged-list-id-namespace to a domain name space is an acceptable reason to change the List Identifier.": There seems to be some confusion between names and namespaces. In my understanding, there are only two namespaces. Did I get something wrong? Section 5 (Uniqueness): The first two paragraphs are about ".invalid", then there is a paragraph about list ids derived from existing domain names, then we are back to ".invalid". I suggest sorting this out better. "A List Identifier using the special "invalid" namespace SHOULD include the month and year (in the form MYYYY), i.e. the List Identifier is a "subdomain" of the "invalid" namespace.": Why be imprecise first and then give the details in the example? What about: ""A List Identifier using the special "invalid" namespace SHOULD include a subdomain with the month and year (in the form MMYYYY)." Why is it MMYYYY? This may be legacy, but if not, it definitely should be YYYYMM. "Such a namespace is inherently flat, unmanaged and thus non-unique.": The namespace is flat, but *names in it* are non-unique. Nits: Structuring of "1. Introduction": Add a subsection heading "Overview" close to the start of the section; merge Terminology and Syntax Notation into one subsection (e.g. Terminology and Notation). Also, consider merging some of the very small sections into bigger sections with subsections. As an example, the discussion of Persistence and Uniqueness should probably be folded into the "List Identifier" Section. This will lead to a better balance of sections and subsections. Provide a short overview (by section) of the doc at the end of the general part of the Introduction Section. "This Internet-Draft can be discussed on the apps-discuss@ietf.org mailing list. [RFC-Editor: please remove this paragraph]": "paragraph" -> "subsection" Section 2, "Where" part after "Syntax": I'd prefer to see the reference to [RFC2606] immediately after the first mention of "invalid". Then that item in the "Where" part could be removed. The explanation of "dot-atom-text" would best be moved into the syntax, as follows dot-atom-text-enc = (see also http://tools.ietf.org/html/draft-duerst-eai-mailto-02 for similar examples). "There MUST be not be more than one of List-Id header field in any given message." -> "There MUST not be more than one List-Id header field in any given message." "consist of angle-bracket ('<', '>') enclosed identifier": "consist of an identifier enclosed by angle-brackets ('<' and '>')" "Client applications SHOULD treat any such whitespace, that might be inserted by poorly behaved mailing list managers, as characters to ignore.": "that" -> "which" ("that" cannot start a nonrestrictive clause) "While it is perfectly acceptable for a List Identifier to be completely independent of the domain name of the host machine servicing the mailing list, the owner of a mailing list MUST NOT generate List Identifiers in any domain name space for which they do not have authority.": A normative sentence (MUST NOT and such) should stand on its own wherever possible (and the above sentence is longish anyway). "from an informal unmanaged-list-id-namespace to a domain name space": Please check for consistent spelling of name space/namespace. (namespace is better, because most people will parse "domain name space" as (domain name) space. "month and year (in the form MYYYY)": "MYYYY" -> "MMYYYY" "6. Operations on List Identifier*s*" "The comparison operation MUST ignore any part of the List-Id header field outside of the angle brackets, the MUA may inform the user if the descriptive name of a mailing list changes.": This looks like it wants to be two sentences to me. "however, this will only be possible when the nested mailing list is aware of the relationship between it and its "parent" mailing lists.": Please change "it and its" to "itself and its". Also, please change "aware" to a less personifying term. "If a mailing list manager encounters List-Id header fields from any unexpected source it SHOULD NOT pass them through to the mailing list. As mentioned above, mail list managers should not allow any user-originated List-Id header fields to pass through to their lists, lest they confuse the user and have the potential to create security problems.": Please eliminate repetition. "Removed List-Sequence header field as it does not fit it": What does not fit what? Regards, Martin. From barryleiba@gmail.com Tue Mar 13 06:22:08 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26AAB21F86EB; Tue, 13 Mar 2012 06:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.984 X-Spam-Level: X-Spam-Status: No, score=-102.984 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cjK0F2TclCXn; Tue, 13 Mar 2012 06:22:07 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id A8DD721F86E5; Tue, 13 Mar 2012 06:22:04 -0700 (PDT) Received: by ghbg16 with SMTP id g16so629903ghb.31 for ; Tue, 13 Mar 2012 06:22:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=UY+UokXDuxWt8HXIxzB3KEJlE9az6NQCCa3ex++J//k=; b=D99/PJd9yPzWMW2K0si6vBHCx8cNgMucDeqhFoFBNl89n4YCT/1MSihUlIUZ5qbdBZ 2S/KLUNj+IiVle6j5pM/Z8RbYZ3sP8s7abwcMoeqGb39xgDcJpkifJiByrPNqOzZLkpc +ZM1WHS00K6ta61i+UbZbd2TkquwX55rhzInn4W++M5yIMXgxUIDniBlRv7mmDYcBeLN Ly4hrglV1Wgr9wLbQMLNApltBaP9Etd+YboxFAZIqd4a8GUYOvOsWdoRDpXQtalzQylK 9GYKu2bezZEIN8h5Yb3V0up+7yI31Kjx4hpp/R8K9sUlxicL1JMwAcCvmputfQSv7dZl NsXg== MIME-Version: 1.0 Received: by 10.182.122.36 with SMTP id lp4mr9904275obb.64.1331644923200; Tue, 13 Mar 2012 06:22:03 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.60.125.37 with HTTP; Tue, 13 Mar 2012 06:22:03 -0700 (PDT) In-Reply-To: References: Date: Tue, 13 Mar 2012 09:22:03 -0400 X-Google-Sender-Auth: B02m5feT39iNJM4R6T506zo_xlw Message-ID: From: Barry Leiba To: Jiankang YAO Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: scottr.nist@gmail.com, iesg@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-dnsext-dnssec-registry-fixes-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Mar 2012 13:22:08 -0000 > 1) The introduction said "This document updates > =A0 the following: [RFC2536], [RFC2539], [RFC3110], [RFC4034], [RFC4398], > =A0 [RFC5155], [RFC5702], and [RFC5933]. > " > > It should address what is updated =A0in these RFCs [RFC2536], [RFC2539], > [RFC3110], [RFC4034], [RFC4398], [RFC5155], [RFC5702], and [RFC5933]. It should, and it does. The whole paragraph that the cited sentence is in gives that explanation. > Nits: > This sentence below in the IANA considerations section should be noted wi= th "removed when rfc is published". > > "In the column "Compliance to RFC TBD", "RFC TBD" should bechanged to the= official RFC when published. > " But then wouldn't THAT sentence itself ALSO need a notation that IT should be removed at publication? And then THAT sentence, and so on? We could wind up in quite a fix here! Seriously, the RFC Editor folks are smart; they will understand that the "fix this when published" message needs to be removed when they do the fix. Barry From williamstw@gmail.com Tue Mar 13 07:39:54 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 718AE21F88E9 for ; Tue, 13 Mar 2012 07:39:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fj8R-p+bcTDK for ; Tue, 13 Mar 2012 07:39:43 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id BB6E421F88CF for ; Tue, 13 Mar 2012 07:39:41 -0700 (PDT) Received: by yhpp34 with SMTP id p34so722313yhp.31 for ; Tue, 13 Mar 2012 07:39:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Bp7ITSqmRC0rEL0g/p3FQr2odhM2VNrqac432wgX8II=; b=E/3SDEwbKnyhkLTbCt54qnXWOCJ9JuNpYS83NpcukDBKLKjfNI2u82u+rWu7WMADPX ImDANuNGxcIjdjBK9xMk9+eqj49XOQo536l0kWCUVM9u8j/yu7xL72MIOON02igyGwdM cOWISsHabRhZ9q9/HZ5YeahmFOM7zqrCUBka8Bonr4+nmNbHkY6tZA01YAtUSJRh+8yP Mx4N3TEI3AyArv+ZWMr3cTlF/l6x9Zcgd1ywF6MrDrK8aBjLd/4vtsXtm6TrPM2htvWE ex4tVWEIctxUbSMKT3KUBT8IlsPKvo29fjjE70FWv6f9VRVLfvxVQV5nbWd3Y1+OMStO FBVg== MIME-Version: 1.0 Received: by 10.182.37.99 with SMTP id x3mr12227948obj.31.1331649581270; Tue, 13 Mar 2012 07:39:41 -0700 (PDT) Received: by 10.182.209.97 with HTTP; Tue, 13 Mar 2012 07:39:41 -0700 (PDT) Date: Tue, 13 Mar 2012 10:39:41 -0400 Message-ID: From: Tim Williams To: apps-discuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [apps-discuss] URITemplates and Atom X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Mar 2012 14:39:54 -0000 I found that using URITemplates in Atom links has been discussed on another list[1] and concluded it's not appropriate. The consensus there seems to have been that a new I-D was needed - presumably to describe applying URITemplates to Atom. That discussion was some time ago, does anyone know of any activity around that? Thanks, --tim **please feel free to point me to a more appropriate list if there is one. [1] - http://old.nabble.com/URI-Templates-in-Atom-links-td27717625.html From bobwyman@gmail.com Tue Mar 13 08:12:35 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD7A921F8913 for ; Tue, 13 Mar 2012 08:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f0+B2-52BbQk for ; Tue, 13 Mar 2012 08:12:35 -0700 (PDT) Received: from mail-fa0-f44.google.com (mail-fa0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id A3EE821F88AB for ; Tue, 13 Mar 2012 08:12:34 -0700 (PDT) Received: by faaa25 with SMTP id a25so136144faa.31 for ; Tue, 13 Mar 2012 08:12:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=5I0Ihl4Y/p5XHsgFMjF3Ud6MmZc5CI8SIQO5Ov+cQfI=; b=l31vD4SdIwKJu3TwLtuHmaRksuTbFbvHGtxf7+FwPwDH7TydXXVdNh71kQvp4J1UIQ ruVxSBbG2xMcax68hZSV+WRlw5LafdMJIk5qbPddDd7WGI6maafHgb5EV+oN9+WfzKQk VXEZawol8paVdjhl3D+avMWI5GtDQkxmgQvDmJVGD22Dweq9JYuZF191kpBKcIKFsQwE hXUqoRM3TiZo8LpI7RZsZj37eBFDC1IEOKzXnN51lGhf0EsTneNiOjHFYmPQDAsiQ6jo hx2Kx45xgxctQ9BEPrkXnw8PU8BNHfeMbq6O0iz6mPknQqIPkQggcy9NS96khBI3gZry kH4Q== MIME-Version: 1.0 Received: by 10.224.173.72 with SMTP id o8mr12934235qaz.76.1331651553153; Tue, 13 Mar 2012 08:12:33 -0700 (PDT) Sender: bobwyman@gmail.com Received: by 10.229.157.16 with HTTP; Tue, 13 Mar 2012 08:12:33 -0700 (PDT) In-Reply-To: <018701cd0021$5bbb6160$13322420$@packetizer.com> References: <20120312072303.24645.20735.idtracker@ietfa.amsl.com> <018701cd0021$5bbb6160$13322420$@packetizer.com> Date: Tue, 13 Mar 2012 11:12:33 -0400 X-Google-Sender-Auth: 1I_Hjv5XRQtpFRJuzFIuL0T5Ync Message-ID: From: Bob Wyman To: "Paul E. Jones" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: WebFinger List , apps-discuss@ietf.org Subject: Re: [apps-discuss] FW: New Version Notification for draft-jones-appsawg-webfinger-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Mar 2012 15:12:35 -0000 Examples teach as much or more than the actual text of specifications... Thus, I'd like to suggest a small modification to the examples provided: Many webfinger clients will inevitably seek to cache the host metadata returned as an XRD or JRD. However, we can anticipate that many developers will skip a detailed analysis of the actual XRD draft and will, instead, have designs driven largely by what they see in the examples. Because of the complex interaction between XRD Expire elements and HTTP Cache control I suggest that the examples in 3.1 and 3.2 be modified slightly to include an Expires element as defined in the XRD specification. Doing so in the examples might, in fact, motivate developers to seek out the documentation that explains the element. Thus, a modified example in 3.1 would be something like: HTTP/1.1 200 OK Access-Control-Allow-Origin: * Content-Type: application/xrd+xml; charset=3DUTF-8 2011-11-11T23:11:11Z acct:bob@example.com bob wyman On Mon, Mar 12, 2012 at 3:25 AM, Paul E. Jones wrot= e: > > Folks, > > I just wanted to let everyone know that we have published a revised versi= on of the Webfinger draft. =A0Your comments are encouraged. > > Paul > > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: Monday, March 12, 2012 3:23 AM > > To: paulej@packetizer.com > > Cc: jsmarr@google.com; gsalguei@cisco.com > > Subject: New Version Notification for draft-jones-appsawg-webfinger-01.= txt > > > > A new version of I-D, draft-jones-appsawg-webfinger-01.txt has been > > successfully submitted by Paul E. Jones and posted to the IETF reposito= ry. > > > > Filename: =A0 =A0 =A0draft-jones-appsawg-webfinger > > Revision: =A0 =A0 =A001 > > Title: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Webfinger > > Creation date: =A0 =A0 =A0 =A0 2012-03-12 > > WG ID: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Individual Submission > > Number of pages: 17 > > > > Abstract: > > =A0 =A0This specification defines the Webfinger protocol. =A0Webfinger = may be > > =A0 =A0used to discover information about people on the Internet, such = as a > > =A0 =A0person's personal profile address, identity service, telepho= ne > > =A0 =A0number, or preferred avatar. =A0Webfinger may also be used to le= arn > > =A0 =A0information about objects on the network, such as the amount of = toner > > =A0 =A0in a printer or the physical location of a server. > > > > > > > > > > The IETF Secretariat > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From pbryan@anode.ca Tue Mar 13 08:18:13 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD01F21F8924 for ; Tue, 13 Mar 2012 08:18:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MDzmfD2nCOXU for ; Tue, 13 Mar 2012 08:18:13 -0700 (PDT) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id 5A65321F8923 for ; Tue, 13 Mar 2012 08:18:13 -0700 (PDT) Received: from [192.168.1.119] (unknown [209.97.219.224]) by maple.anode.ca (Postfix) with ESMTPSA id 847556456 for ; Tue, 13 Mar 2012 15:18:12 +0000 (UTC) Message-ID: <1331651889.3301.5.camel@neutron> From: "Paul C. Bryan" To: apps-discuss@ietf.org Date: Tue, 13 Mar 2012 08:18:09 -0700 In-Reply-To: <4F5E6255.9040402@cloudmark.com> References: <9F0A2492-AE7D-4C12-8BB0-13489FD7F6C1@gmail.com> <1331271383.6504.1.camel@neutron> <4F5E6255.9040402@cloudmark.com> Content-Type: multipart/alternative; boundary="=-W5D12aLnkSY26b6dfo9h" X-Mailer: Evolution 3.2.2-1 Mime-Version: 1.0 Subject: Re: [apps-discuss] draft-pbryan-json-patch-04 - comments X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Mar 2012 15:18:13 -0000 --=-W5D12aLnkSY26b6dfo9h Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Mon, 2012-03-12 at 13:53 -0700, Mike Acar wrote: > I'm unsure about test as well. It seems strange to me to express "change > this document if it looks like this" in a patch; if the application > creating the patch doesn't know how the document looks, how can it > create a patch? I'm surprised that it seems so strange, as this is very much like how text-based diff/patches work. It allows assumptions about the state of the resource being modified to be a precondition to successfully modifying the resource. With HTTP, it's ideal if precondition headers be used, but this is not always feasible, nor is HTTP the only avenue for using JSON Patch. > Paul, is there an archived discussion of the "test" operation, > particularly regarding use cases? This was originally discussed on the JSON Patch Google Group discussion. Paul --=-W5D12aLnkSY26b6dfo9h Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit On Mon, 2012-03-12 at 13:53 -0700, Mike Acar wrote: 
I'm unsure about test as well. It seems strange to me to express "change 
this document if it looks like this" in a patch; if the application 
creating the patch doesn't know how the document looks, how can it 
create a patch?
I'm surprised that it seems so strange, as this is very much like how text-based diff/patches work. It allows assumptions about the state of the resource being modified to be a precondition to successfully modifying the resource. With HTTP, it's ideal if precondition headers be used, but this is not always feasible, nor is HTTP the only avenue for using JSON Patch.

Paul, is there an archived discussion of the "test" operation, 
particularly regarding use cases?

This was originally discussed on the JSON Patch Google Group discussion.

Paul --=-W5D12aLnkSY26b6dfo9h-- From pbryan@anode.ca Tue Mar 13 08:18:54 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4543E21F86F6 for ; Tue, 13 Mar 2012 08:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fgyf6eV1vhLk for ; Tue, 13 Mar 2012 08:18:53 -0700 (PDT) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id A2D2321F86EF for ; Tue, 13 Mar 2012 08:18:53 -0700 (PDT) Received: from [192.168.1.119] (unknown [209.97.219.224]) by maple.anode.ca (Postfix) with ESMTPSA id CB9526456 for ; Tue, 13 Mar 2012 15:18:52 +0000 (UTC) Message-ID: <1331651931.3301.6.camel@neutron> From: "Paul C. Bryan" To: "apps-discuss@ietf.org" Date: Tue, 13 Mar 2012 08:18:51 -0700 In-Reply-To: <9452079D1A51524AA5749AD23E003928086A22@exch-mbx901.corp.cloudmark.com> References: <20120309212231.16366.52439.idtracker@ietfa.amsl.com> <9452079D1A51524AA5749AD23E003928086A22@exch-mbx901.corp.cloudmark.com> Content-Type: multipart/alternative; boundary="=-qzvdWCsV+BY3dLkJsYYK" X-Mailer: Evolution 3.2.2-1 Mime-Version: 1.0 Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-json-patch-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Mar 2012 15:18:54 -0000 --=-qzvdWCsV+BY3dLkJsYYK Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit I agree with Murray's points. Paul On Mon, 2012-03-12 at 20:55 +0000, Murray S. Kucherawy wrote: > > -----Original Message----- > > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Vadim Zaliva > > Sent: Saturday, March 10, 2012 10:33 PM > > To: apps-discuss@ietf.org > > Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-json-patch-01.txt > > > > I would like to suggest some extensions to this draft. I was trying to > > use proposed syntax in one of my project and found it lacking a couple > > of operations. Please find below my proposed extensions: > > > > Operation "add-unique" > > > > The new value appended the array only if the it presently does not > > contain an element with such value. If an element with such value > > already exists, the duplicate will not be added. > > This feels like feature creep to me. A patch to me is a sequence of steps for moving some content from one known state to another. This proposed capability allows one to move from an uncertain state to a known state. That might be a useful thing to do, but it's not something I think of as a "patch". > > > Operation "remove-all" > > > > This operations removes from array all elements with given value. > > I have the same concern here. > > > Operation "replace-all" > > > > This operations replaces in an array all elements with given value with > > a new value. > > And here. > > -MSK > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --=-qzvdWCsV+BY3dLkJsYYK Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit I agree with Murray's points.

Paul

On Mon, 2012-03-12 at 20:55 +0000, Murray S. Kucherawy wrote: 
> -----Original Message-----
> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Vadim Zaliva
> Sent: Saturday, March 10, 2012 10:33 PM
> To: apps-discuss@ietf.org
> Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-json-patch-01.txt
> 
> I would like to suggest some extensions to this draft. I was trying to
> use proposed syntax in one of my project and found it lacking a couple
> of operations. Please find below my proposed extensions:
> 
> Operation "add-unique"
> 
> The new value appended the array only if the it presently does not
> contain an element with such value. If an element with such value
> already exists, the duplicate will not be added.

This feels like feature creep to me.  A patch to me is a sequence of steps for moving some content from one known state to another.  This proposed capability allows one to move from an uncertain state to a known state.  That might be a useful thing to do, but it's not something I think of as a "patch".

> Operation "remove-all"
> 
> This operations removes from array all elements with given value.

I have the same concern here.

> Operation "replace-all"
> 
> This operations replaces in an array all elements with given value with
> a new value.

And here.

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

--=-qzvdWCsV+BY3dLkJsYYK-- From pbryan@anode.ca Tue Mar 13 08:22:26 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06C0421F896D for ; Tue, 13 Mar 2012 08:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wqu9AOFowQUq for ; Tue, 13 Mar 2012 08:22:25 -0700 (PDT) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id 7DD6D21F896B for ; Tue, 13 Mar 2012 08:22:25 -0700 (PDT) Received: from [192.168.1.119] (unknown [209.97.219.224]) by maple.anode.ca (Postfix) with ESMTPSA id D113C6487 for ; Tue, 13 Mar 2012 15:22:24 +0000 (UTC) Message-ID: <1331652143.3301.9.camel@neutron> From: "Paul C. Bryan" To: apps-discuss@ietf.org Date: Tue, 13 Mar 2012 08:22:23 -0700 In-Reply-To: <4F5E6E2F.4030503@cloudmark.com> References: <20120309211833.15339.72914.idtracker@ietfa.amsl.com> <4F5E6E2F.4030503@cloudmark.com> Content-Type: multipart/alternative; boundary="=-5SRAR7RT2ba7ua9CeSmk" X-Mailer: Evolution 3.2.2-1 Mime-Version: 1.0 Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-json-pointer-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Mar 2012 15:22:26 -0000 --=-5SRAR7RT2ba7ua9CeSmk Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Mon, 2012-03-12 at 14:44 -0700, Mike Acar wrote: > Typo: In section 4, > > The member name is equal to the token if it has the same number of > Unicode characters as token and their codepoints are positionwise > equal. > > Need a "the" between "as" and "token". Thanks, fixed in next revision. > You removed one "concrete", but should probably remove the next two. > Since the section begins with > > Evaluation of a JSON Pointer begins with a reference to the root > value of a JSON text document > > the implication is that you're following the pointer and traversing an > existing (concrete) object. > > Actually, I suggest rewriting the paragraph, something like: > > While evaluating the JSON Pointer, if the implementation does not > match the reference token to a member name or array index in the > currently-referenced value, then the implementation MAY terminate > evaluation with an error condition. > > That said, I'm still concerned that this behavior interacts badly with > Pointers as they're used in JSON Patch. I'll follow up in the patch > thread, though. Hmm, okay, we'll need to continue discussing this. Paul --=-5SRAR7RT2ba7ua9CeSmk Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit On Mon, 2012-03-12 at 14:44 -0700, Mike Acar wrote: 
Typo: In section 4,

     The member name is equal to the token if it has the same number of
     Unicode characters as token and their codepoints are positionwise
     equal.

Need a "the" between "as" and "token".

Thanks, fixed in next revision.

You removed one "concrete", but should probably remove the next two. 
Since the section begins with

     Evaluation of a JSON Pointer begins with a reference to the root
     value of a JSON text document

the implication is that you're following the pointer and traversing an 
existing (concrete) object.

Actually, I suggest rewriting the paragraph, something like:

     While evaluating the JSON Pointer, if the implementation does not
     match the reference token to a member name or array index in the
     currently-referenced value, then the implementation MAY terminate
     evaluation with an error condition.

That said, I'm still concerned that this behavior interacts badly with 
Pointers as they're used in JSON Patch. I'll follow up in the patch 
thread, though.

Hmm, okay, we'll need to continue discussing this.

Paul --=-5SRAR7RT2ba7ua9CeSmk-- From pbryan@anode.ca Tue Mar 13 08:31:53 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70F2021F8898 for ; Tue, 13 Mar 2012 08:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q4yiZxk9KX16 for ; Tue, 13 Mar 2012 08:31:53 -0700 (PDT) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id E592621F889A for ; Tue, 13 Mar 2012 08:31:52 -0700 (PDT) Received: from [192.168.1.119] (unknown [209.97.219.224]) by maple.anode.ca (Postfix) with ESMTPSA id 30FFE6487 for ; Tue, 13 Mar 2012 15:31:52 +0000 (UTC) Message-ID: <1331652710.3301.18.camel@neutron> From: "Paul C. Bryan" To: apps-discuss@ietf.org Date: Tue, 13 Mar 2012 08:31:50 -0700 In-Reply-To: <4F5E70BE.9070308@cloudmark.com> References: <20120309212231.16366.52439.idtracker@ietfa.amsl.com> <4F5E70BE.9070308@cloudmark.com> Content-Type: multipart/alternative; boundary="=-EiJlNUdqo5qvA7TggqaX" X-Mailer: Evolution 3.2.2-1 Mime-Version: 1.0 Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-json-patch-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Mar 2012 15:31:53 -0000 --=-EiJlNUdqo5qvA7TggqaX Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Mon, 2012-03-12 at 14:55 -0700, Mike Acar wrote: > This version of the draft doesn't address the bad interaction with the > JSON Pointer spec, namely that "add" takes a JSON Pointer to a value > which does not yet exist, and the Pointer spec says that in that case, > an implementation MAY abort with an error. Is that going to be > addressed in -02? I'm of the opinion that expressing a not-yet-existing target as a JSON Pointer is the most simple and intuitive method so far. I've had no problems implementing the specs as a result of this. I agree that the language in the JSON Pointer spec is still somewhat awkward and could still stand to be improved. The suggested alternative of requiring the parent and target member to be expressed separately is more verbose and complex. Over-verbosity of JSON Patch is already an objection that has been raised more than once on this list, and I'm not inclined to exacerbate it further unless there is consensus from the members of appsawg that it should be adopted. Paul --=-EiJlNUdqo5qvA7TggqaX Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit On Mon, 2012-03-12 at 14:55 -0700, Mike Acar wrote:
This version of the draft doesn't address the bad interaction with the JSON Pointer spec, namely that "add" takes a JSON Pointer to a value which does not yet exist, and the Pointer spec says that in that case, an implementation MAY abort with an error. Is that going to be addressed in -02?

I'm of the opinion that expressing a not-yet-existing target as a JSON Pointer is the most simple and intuitive method so far. I've had no problems implementing the specs as a result of this. I agree that the language in the JSON Pointer spec is still somewhat awkward and could still stand to be improved.

The suggested alternative of requiring the parent and target member to be expressed separately is more verbose and complex. Over-verbosity of JSON Patch is already an objection that has been raised more than once on this list, and I'm not inclined to exacerbate it further unless there is consensus from the members of appsawg that it should be adopted.

Paul --=-EiJlNUdqo5qvA7TggqaX-- From rdroms.ietf@gmail.com Tue Mar 13 08:17:46 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D00A021F891E; Tue, 13 Mar 2012 08:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.451 X-Spam-Level: X-Spam-Status: No, score=-102.451 tagged_above=-999 required=5 tests=[AWL=-0.248, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8RPfZsme11l; Tue, 13 Mar 2012 08:17:45 -0700 (PDT) Received: from mail-fa0-f44.google.com (mail-fa0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2589921F88EA; Tue, 13 Mar 2012 08:17:44 -0700 (PDT) Received: by faaa25 with SMTP id a25so142497faa.31 for ; Tue, 13 Mar 2012 08:17:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:x-priority:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=YmNVyBUOHhZyQV+B8ACGiLQdQ4B7lv0Et9OC4+ZnHJU=; b=i2k03yagN7B5n1OgbQu4Eu1zIbf0ULpSw8B99PkkcSLMC193q2bQXYIzESHPPocd9k dexz9WjICXaXvW5PS0YCs8RY0dqPXx7ZZD4it4cIsjMBd3y1kSiFXOrd8zUVKhSEXdUf iFjupN90Cco51ZYHFjozoRqptFWHfxuw/cPwZh3XjjAzpTa2FuwJeiQQXHI4VnaNCEp1 AMSj+8i58LqR0p4NOdTuMMIkMCdVhvGh8JYHkI9NNsB6WTOH/UjLr5TH9eeMAI5YnXTB gcbVt3V6bqOJBiIojOfn8I8mKtlWDXvMZOmh9J3BkAVhBnSaQrsvFD/i4S6trwMudm/y vB5w== Received: by 10.224.218.195 with SMTP id hr3mr12973641qab.26.1331651863491; Tue, 13 Mar 2012 08:17:43 -0700 (PDT) Received: from [161.44.65.173] ([161.44.65.173]) by mx.google.com with ESMTPS id ef6sm3695733qab.7.2012.03.13.08.17.41 (version=SSLv3 cipher=OTHER); Tue, 13 Mar 2012 08:17:41 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Ralph Droms X-Priority: 3 In-Reply-To: <7797DB11-A6F8-437A-9A49-2671360A1A82@gmail.com> Date: Tue, 13 Mar 2012 11:17:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <46CEC102-9F51-4E83-8646-656390710269@gmail.com> References: <7797DB11-A6F8-437A-9A49-2671360A1A82@gmail.com> To: Scott Rose X-Mailer: Apple Mail (2.1251.1) X-Mailman-Approved-At: Tue, 13 Mar 2012 09:26:59 -0700 Cc: apps-discuss@ietf.org, Ralph Droms , iesg@ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-dnsext-dnssec-registry-fixes-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Mar 2012 15:17:46 -0000 On Mar 13, 2012, at 9:46 AM 3/13/12, Scott Rose wrote: > I think there might be a disconnect here. I believe that the = registry-fixes draft was not to be advanced. In response to WG and IESG = comments, the work was broken into two separate drafts that would be = worked on independently: >=20 > draft-ietf-dnsext-dnssec-registry-update: Addressing some fixes to a = set of DNSSEC algorithm registry entries > = http://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-registry-update/ >=20 > and draft-ietf-dnsext-dnssec-algo-imp-status: Algorithm implementation = status assignment. Aiming for BCP status and not Standards Track. > = http://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-algo-imp-status/ Correct. I've marked draft-ietf-dnsext-dnssec-registry-fixes dead. I = will progress draft-ietf-dnsext-dnssec-registry-update and = draft-ietf-dnsext-dnssec-algo-imp-status through IETF and IESG when they = are forwarded to me for publication. - Ralph > There has been more feedback and work on the registry-update draft as = it contains the non-controversial parts of the older registry-fixes = draft. Not sure of the exact timeline for advancing that out of the WG, = but Andrew might have a better feel. >=20 > Scott >=20 > On Mar 13, 2012, at 4:22 AM, Jiankang YAO wrote: >=20 >> I have been selected as the Applications Area Directorate reviewer=20 >> for this draft (for background on appsdir, please=20 >> see=20 >> = http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate=20= >> ). =20 >> Please resolve these comments along with any other comments=20 >> you may receive. Please wait for direction from your document=20 >> shepherd or AD before posting a new version of the draft. >>=20 >> Document: draft-ietf-dnsext-dnssec-registry-fixes-08=20 >> Title:=20 >> Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm IANA = Registry >> Reviewer: Jiankang Yao >> Review Date: March 13, 2012 >>=20 >> Summary: >>=20 >> This draft is useful. If it is published, the following=20 >> issues should be considered or addressed before publication. >>=20 >> Minor issue: >>=20 >> 1) The introduction said "This document updates >> the following: [RFC2536], [RFC2539], [RFC3110], [RFC4034], = [RFC4398], >> [RFC5155], [RFC5702], and [RFC5933]. >> " >>=20 >> It should address what is updated in these RFCs [RFC2536], = [RFC2539], [RFC3110], [RFC4034], [RFC4398], [RFC5155], [RFC5702], and = [RFC5933]. >>=20 >>=20 >> Nits: >>=20 >> This sentence below in the IANA considerations section should be = noted with "removed when rfc is published". >>=20 >> "In the column "Compliance to RFC TBD", "RFC TBD" should bechanged to = the official RFC when published. >> " >>=20 >> Jiankang Yao >=20 From scottr.nist@gmail.com Tue Mar 13 06:46:54 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9D2B21F8944; Tue, 13 Mar 2012 06:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.901 X-Spam-Level: X-Spam-Status: No, score=-5.901 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ij1R+ObnmY+6; Tue, 13 Mar 2012 06:46:54 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by ietfa.amsl.com (Postfix) with ESMTP id 10CB621F893C; Tue, 13 Mar 2012 06:46:53 -0700 (PDT) Received: from 107-140.antd.nist.gov (107-140.antd.nist.gov [129.6.140.107]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id q2DDkZH7002777; Tue, 13 Mar 2012 09:46:37 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Scott Rose X-Priority: 3 In-Reply-To: Date: Tue, 13 Mar 2012 09:46:34 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7797DB11-A6F8-437A-9A49-2671360A1A82@gmail.com> References: To: Jiankang YAO , Andrew Sullivan X-Mailer: Apple Mail (2.1084) X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: scottr.nist@gmail.com X-Mailman-Approved-At: Tue, 13 Mar 2012 09:34:35 -0700 Cc: iesg@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-dnsext-dnssec-registry-fixes-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Mar 2012 13:46:54 -0000 I think there might be a disconnect here. I believe that the = registry-fixes draft was not to be advanced. In response to WG and IESG = comments, the work was broken into two separate drafts that would be = worked on independently: draft-ietf-dnsext-dnssec-registry-update: Addressing some fixes to a set = of DNSSEC algorithm registry entries = http://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-registry-update/ and draft-ietf-dnsext-dnssec-algo-imp-status: Algorithm implementation = status assignment. Aiming for BCP status and not Standards Track. = http://datatracker.ietf.org/doc/draft-ietf-dnsext-dnssec-algo-imp-status/ There has been more feedback and work on the registry-update draft as it = contains the non-controversial parts of the older registry-fixes draft. = Not sure of the exact timeline for advancing that out of the WG, but = Andrew might have a better feel. Scott On Mar 13, 2012, at 4:22 AM, Jiankang YAO wrote: > I have been selected as the Applications Area Directorate reviewer=20 > for this draft (for background on appsdir, please=20 > see=20 > = http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate=20= > ). =20 > Please resolve these comments along with any other comments=20 > you may receive. Please wait for direction from your document=20 > shepherd or AD before posting a new version of the draft. >=20 > Document: draft-ietf-dnsext-dnssec-registry-fixes-08=20 > Title:=20 > Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm IANA = Registry > Reviewer: Jiankang Yao > Review Date: March 13, 2012 >=20 > Summary: >=20 > This draft is useful. If it is published, the following=20 > issues should be considered or addressed before publication. >=20 > Minor issue: >=20 > 1) The introduction said "This document updates > the following: [RFC2536], [RFC2539], [RFC3110], [RFC4034], = [RFC4398], > [RFC5155], [RFC5702], and [RFC5933]. > " >=20 > It should address what is updated in these RFCs [RFC2536], [RFC2539], = [RFC3110], [RFC4034], [RFC4398], [RFC5155], [RFC5702], and [RFC5933]. >=20 >=20 > Nits: >=20 > This sentence below in the IANA considerations section should be noted = with "removed when rfc is published". >=20 > "In the column "Compliance to RFC TBD", "RFC TBD" should bechanged to = the official RFC when published. > " >=20 > Jiankang Yao From paulej@packetizer.com Tue Mar 13 14:02:48 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 234CD21E8015 for ; Tue, 13 Mar 2012 14:02:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dfrZiCROOGHG for ; Tue, 13 Mar 2012 14:02:47 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE1221F85D3 for ; Tue, 13 Mar 2012 14:02:46 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q2DL2eba017887 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 13 Mar 2012 17:02:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1331672561; bh=hEC5yoI4XePLchk+qykSJGM3TO9+vJ3dDSmjNhhXmwQ=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=VV9avsNIXFoOvGtOuRhBvKW9y0GBYRkMA2kRw7ws6ZPEVvqMPEPyodS/WboFbbqIr Jvy+TTQct6/0k+zZpvqn+kqn3zbIxqB5k/RbHNcEy44Bq/E4IrwlQDijmmvjvDokr1 nau3iAFP9g01jumGXhnqmWG2hjlTumV429kQSbiI= From: "Paul E. Jones" To: "'Bob Wyman'" References: <20120312072303.24645.20735.idtracker@ietfa.amsl.com> <018701cd0021$5bbb6160$13322420$@packetizer.com> In-Reply-To: Date: Tue, 13 Mar 2012 17:02:46 -0400 Message-ID: <051701cd015c$a4a8d740$edfa85c0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHgtf6weo5Hh9+k8X/jrkg0oihfQAKE6w7zAZn4ufKWIFX/MA== Content-Language: en-us Cc: 'WebFinger List' , apps-discuss@ietf.org Subject: Re: [apps-discuss] FW: New Version Notification for draft-jones-appsawg-webfinger-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Mar 2012 21:02:48 -0000 Bob, That's a good suggestion. I've updated several examples (both host-meta = and LRDD) with Expires (both XRD and JRD). Paul > -----Original Message----- > From: bobwyman@gmail.com [mailto:bobwyman@gmail.com] On Behalf Of Bob > Wyman > Sent: Tuesday, March 13, 2012 11:13 AM > To: Paul E. Jones > Cc: apps-discuss@ietf.org; WebFinger List > Subject: Re: [apps-discuss] FW: New Version Notification for = draft-jones- > appsawg-webfinger-01.txt >=20 > Examples teach as much or more than the actual text of = specifications... > Thus, I'd like to suggest a small modification to the examples = provided: > Many webfinger clients will inevitably seek to cache the host metadata > returned as an XRD or JRD. However, we can anticipate that many = developers > will skip a detailed analysis of the actual XRD draft and will, = instead, > have designs driven largely by what they see in the examples. Because = of > the complex interaction between XRD Expire elements and HTTP Cache = control > I suggest that the examples in 3.1 and > 3.2 be modified slightly to include an Expires element as defined in = the > XRD specification. Doing so in the examples might, in fact, motivate > developers to seek out the documentation that explains the element. = Thus, > a modified example in 3.1 would be something like: >=20 > HTTP/1.1 200 OK > Access-Control-Allow-Origin: * > Content-Type: application/xrd+xml; charset=3DUTF-8 >=20 > > > 2011-11-11T23:11:11Z > acct:bob@example.com > href=3D"http://www.example.com/~bob/bob.jpg"/> > href=3D"http://www.example.com/~bob/"/> > href=3D"http://blogs.example.com/bob/"/> > >=20 > bob wyman >=20 >=20 > On Mon, Mar 12, 2012 at 3:25 AM, Paul E. Jones > wrote: > > > > Folks, > > > > I just wanted to let everyone know that we have published a revised > version of the Webfinger draft. =A0Your comments are encouraged. > > > > Paul > > > > > -----Original Message----- > > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > > Sent: Monday, March 12, 2012 3:23 AM > > > To: paulej@packetizer.com > > > Cc: jsmarr@google.com; gsalguei@cisco.com > > > Subject: New Version Notification for > > > draft-jones-appsawg-webfinger-01.txt > > > > > > A new version of I-D, draft-jones-appsawg-webfinger-01.txt has = been > > > successfully submitted by Paul E. Jones and posted to the IETF > repository. > > > > > > Filename: =A0 =A0 =A0draft-jones-appsawg-webfinger > > > Revision: =A0 =A0 =A001 > > > Title: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Webfinger > > > Creation date: =A0 =A0 =A0 =A0 2012-03-12 > > > WG ID: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Individual Submission = Number of pages: 17 > > > > > > Abstract: > > > =A0 =A0This specification defines the Webfinger protocol. = =A0Webfinger may > > > be > > > =A0 =A0used to discover information about people on the Internet, = such > > > as a > > > =A0 =A0person's personal profile address, identity service, > > > telephone > > > =A0 =A0number, or preferred avatar. =A0Webfinger may also be used = to learn > > > =A0 =A0information about objects on the network, such as the = amount of > > > toner > > > =A0 =A0in a printer or the physical location of a server. > > > > > > > > > > > > > > > The IETF Secretariat > > > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss From sm@elandsys.com Tue Mar 13 16:00:36 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9469321E8053 for ; Tue, 13 Mar 2012 16:00:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.446 X-Spam-Level: X-Spam-Status: No, score=-102.446 tagged_above=-999 required=5 tests=[AWL=-0.147, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U08jKYOVDF3i for ; Tue, 13 Mar 2012 16:00:32 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id BCB1A21E8033 for ; Tue, 13 Mar 2012 16:00:32 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.234.218]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q2DN0BjN029710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Mar 2012 16:00:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1331679630; i=@elandsys.com; bh=A5hbcvLKEQVXiGCJY3nEfr0ZKyEdYpLpTrXzMqiJWcA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=vYGWV0UPPI6Z5ffQ+d85TSE8BRSE5/FoOtPGOj9EwRa7OpTtu3MFshdbEJh2w/Vn1 rk2w9k3orofuVf0VFd8XVV+JYuUEPd7CUUXMQjmOHMHlRObu3zeEuNv5Zj5gCoAEaq QidOSaM9616VTt76zuqnQyF5O6A5J18cVuOW/Xqg= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1331679630; i=@elandsys.com; bh=A5hbcvLKEQVXiGCJY3nEfr0ZKyEdYpLpTrXzMqiJWcA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=PuWPzvzCoF9Z+LoUPqmqDLMzMTWbpUENms4MRBvKPg1esYz9UQJUwPadwuTvIYV8c DH4MnFOm+4ZrhJwz8hAtABdbpfuv6l3P+NCAg+3os2xnq0TRDQxy53qQ6XfOxHbJNe IGLULAG1k9OZsoUBvfewj+bipGesZ/syLUPH+t9A= Message-Id: <6.2.5.6.2.20120313101329.091f9df8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 13 Mar 2012 15:42:56 -0700 To: =?iso-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= From: S Moonesamy In-Reply-To: <4F5F23AE.7080404@it.aoyama.ac.jp> References: <4F5F23AE.7080404@it.aoyama.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: draft-moonesamy-rfc2919bis.all@tools.ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-moonesamy-rfc2919bis-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Mar 2012 23:00:36 -0000 Hi Martin, At 03:38 13-03-2012, Martin J. D=FCrst wrote: >Summary: This draft is close to being ready for=20 >publication on Standard Tracks, with the=20 >exception of Internationalization concerns,=20 >which seem to have been forgotten completely > > >General comment: I'm somewhat unsure about the=20 >need for this update. But if somebody is doing the actual work, I don't= mind. >[After completing this review, I realize that I=20 >have probably invested too much work to let the=20 >above comment stay. But I definitely didn't want to disappoint our Team= Lead.] I don't think that the Team Lead would be=20 disappointed as the reviews are exceeding expectations. :-) I'll label my response as an individual comment=20 as I still have to discuss with my co-authors about the review. The updated started as a clean-up of RFC 2919=20 while I was working on an implementation. It is=20 also to facilitate the internationalization=20 aspect and IETF work on its mailing lists. >Major Issues: > >Internationalization of list identifiers seem to=20 >have been completely ignored. How is a list id=20 >from an IDN domain used? One option is punycode,=20 >but this is really ugly (and would mean MUAs=20 >have to translate to readable text). Also, it=20 >might make conversion to/from EAI messages a real pain. I am glad that you raised this question as it=20 should be given some thought. Although the draft=20 does not discuss about internationalization or=20 IDNs, I went through the text to see whether=20 there were any possible issues which would affect=20 future work. Internationalization would be more=20 than referencing the IDNA documents; the header=20 field would have to be RFC 6532 compliant instead=20 of RFC 5322 compliant. That opens a new set of=20 issues to be considered and it is better to do that through the EAI WG. The internationalization alternative is to see=20 whether the MTA performing final delivery is=20 SMTPUTF8-aware. It might be better to avoid=20 getting into MUA "downgrades"; it's less work to=20 rely on RFC 5721 or RFC 5738 support. >There is a tension between "the owner of a=20 >mailing list MUST NOT generate List Identifiers=20 >in any domain name space for which they do not=20 >have authority" and "As such the mailing list=20 >administrator should avoid changing the List=20 >Identifier even when the host serving the=20 >mailing list changes.". The MUST NOT is worded=20 >more strongly, but I think we want the second part to win in case of= conflict. Here's the text from Section 2 of -03: "While it is perfectly acceptable for a List Identifier to be completely independent of the domain name of the host machine servicing the mailing list, it is recommended that the owner of a mailing list avoids generating List Identifiers in any domain name space for which they do not have authority." I avoided changing the requirements from RFC 2919=20 given the intended status of the draft; hence the=20 "MUST NOT generate". The reverted text (see=20 Appendix C.1) is based on advice from the Sponsoring AD. >Minor Issues: > >"List manager" is used throughout the document.=20 >When reading, I first associated a person with=20 >this term, which was of course confusing. I=20 >propose to change to another term or at least to=20 >explain the term on its first use. The term "mailing list manager" (MLM) is used=20 throughout the draft. As it's a well-known term=20 in email circles, I expect push-back if I try to=20 change it. I could modify the sentence in the Introduction Section as= follows: draft-moonesamy-rfc2369bis [ID.moonesamy-rfc2369bis] expands the functionality that the Mail User Agent (MUA) can provide by providing more information in each message sent by a software agent which is generally known as the mailing list manager (MLM) >"This document obsoletes RFC 2919 [RFC2919].": I=20 >was really wondering here what changed. At least=20 >provide a pointer to Appendix B here. That sentence is to be in line with RFC Editor=20 policy. I'll add "(see Appendix B). >"and on other messages where the message clearly=20 >applies to this particular distinct mailing=20 >list.": It would be good to give a few examples=20 >here. I was thinking that this would mean bounce=20 >messages, subscription confirmations, and the=20 >like, but I wasn't sure I got that right. List Identifiers can be added for administrative=20 messages in respect to a mailing list. By making=20 a distinction, e.g. providing examples, this may=20 be interpreted narrowly. It's better to leave it=20 to good judgement, hence the "clearly applies to=20 this particular distinct mailing list" >"This field MUST only be generated by mailing=20 >list managers, not MUAs.": What about MTAs? The mailing list manager performs mailing list=20 operations; the MTA doesn't. A MTA passes messages without modification to the message data=20 other than adding trace information. >"The contents of the List-Id header field mostly=20 >consist of": "mostly consists of" is really=20 >confusing. It would be better to give the syntax=20 >first, and then discuss the components one-by-one. Given that the text was already in RFC 2919, I=20 prefer not to change this. I'll discuss the above with my co-authors. >"As such the mailing list administrator *should*=20 >avoid changing the List Identifier even when the=20 >host serving the mailing list changes." (and=20 >some other instances): Please avoid lower-case=20 >normative keywords. They are confusing. (one=20 >other example I found: "the MUA *may* inform the=20 >user if the descriptive name of a mailing list changes." I understand your point. As it may be pointed to=20 the authors that such changes are stylistic in=20 the context of this draft (see intended status),=20 I'll defer to the Sponsoring AD. >"On the other hand, transitioning from an=20 >informal unmanaged-list-id-namespace to a domain=20 >name space is an acceptable reason to change the=20 >List Identifier.": There seems to be some=20 >confusion between names and namespaces. In my=20 >understanding, there are only two namespaces. Did I get something wrong? The domain name space is used as a basis for the=20 List Identifier=20 namespace. "unmanaged-list-id-namespace" comes=20 from the syntax. It's not "namespace". >Section 5 (Uniqueness): The first two paragraphs=20 >are about ".invalid", then there is a paragraph=20 >about list ids derived from existing domain=20 >names, then we are back to ".invalid". I suggest sorting this out better. The first two paragraphs of Section 5 are not=20 about ".invalid"; they are about=20 uniqueness. ".invalid" is first mentioned in the fourth paragraph. >"A List Identifier using the special "invalid"=20 >namespace SHOULD include the month and year (in=20 >the form MYYYY), i.e. the List Identifier is a=20 >"subdomain" of the "invalid" namespace.": Why be=20 >imprecise first and then give the details in the=20 >example? What about: ""A List Identifier using=20 >the special "invalid" namespace SHOULD include a=20 >subdomain with the month and year (in the form MMYYYY)." Please see the above comment about the first two=20 paragraphs. Section 5 is about the uniqueness of List Identifiers. >Why is it MMYYYY? This may be legacy, but if=20 >not, it definitely should be YYYYMM. BTW, there is a typo in -04, it ought to be=20 MMYYYY as in RFC 2919. This is legacy. As there=20 are four digits for the year, the month won't be confused with it. >"Such a namespace is inherently flat, unmanaged=20 >and thus non-unique.": The namespace is flat, but *names in it* are= non-unique. I'll fix that as follows: Such a namespace is inherently flat, unmanaged=20 and thus names in it are non-unique. >Nits: > >Structuring of "1. Introduction": Add a=20 >subsection heading "Overview" close to the start=20 >of the section; merge Terminology and Syntax=20 >Notation into one subsection (e.g. Terminology and Notation). I'll take this with you off-list and post a summary to apps-discuss. >Also, consider merging some of the very small=20 >sections into bigger sections with subsections.=20 >As an example, the discussion of Persistence and=20 >Uniqueness should probably be folded into the "List Identifier" Section. >This will lead to a better balance of sections and subsections. Yes, but it makes it changes the text ordering=20 when we compare the draft with RFC 2919. Let me ask my co-authors about= this. >Provide a short overview (by section) of the doc=20 >at the end of the general part of the Introduction Section. I'll discuss this with you off-list. >"This Internet-Draft can be discussed on the apps-discuss@ietf.org > mailing list. [RFC-Editor: please remove this paragraph]": >"paragraph" -> "subsection" Ok. >Section 2, "Where" part after "Syntax": I'd=20 >prefer to see the reference to [RFC2606]=20 >immediately after the first mention of=20 >"invalid". Then that item in the "Where" part=20 >could be removed. The explanation of=20 >"dot-atom-text" would best be moved into the syntax, as follows > dot-atom-text-enc =3D >(see also=20 >http://tools.ietf.org/html/draft-duerst-eai-mailto-02 for similar= examples). I'll get back to you on this. >"There MUST be not be more than one of List-Id=20 >header field in any given message." -> "There=20 >MUST not be more than one List-Id header field in any given message." Ok. >"consist of angle-bracket ('<', '>') enclosed=20 >identifier": "consist of an identifier enclosed=20 >by angle-brackets ('<' and '>')" Ok. >"Client applications SHOULD treat any such=20 >whitespace, that might be inserted by poorly=20 >behaved mailing list managers, as characters to=20 >ignore.": "that" -> "which" ("that" cannot start a nonrestrictive clause) Ok. >"While it is perfectly acceptable for a List=20 >Identifier to be completely independent of the=20 >domain name of the host machine servicing the=20 >mailing list, the owner of a mailing list MUST=20 >NOT generate List Identifiers in any domain name=20 >space for which they do not have authority.": A=20 >normative sentence (MUST NOT and such) should=20 >stand on its own wherever possible (and the above sentence is longish= anyway). I prefer to leave this one as it is or else I=20 would have to argue that it is not a change in the requirement. >"from an informal unmanaged-list-id-namespace to=20 >a domain name space": Please check for=20 >consistent spelling of name space/namespace.=20 >(namespace is better, because most people will=20 >parse "domain name space" as (domain name) space. Ok. I'll follow up on this off-list. >"month and year (in the form MYYYY)": "MYYYY" -> "MMYYYY" :-) >"6. Operations on List Identifier*s*" > >"The comparison operation MUST ignore any part=20 >of the List-Id header field outside of the angle=20 >brackets, the MUA may inform the user if the=20 >descriptive name of a mailing list changes.":=20 >This looks like it wants to be two sentences to me. Ok. >"however, this will only be possible when the=20 >nested mailing list is aware of the relationship=20 >between it and its "parent" mailing lists.": >Please change "it and its" to "itself and its".=20 >Also, please change "aware" to a less personifying term. That would be Section 7: "A list that is a sublist for another list in a nested mailing list hierarchy MUST NOT modify the List-Id header field; however, this will only be possible when the nested mailing list can determine the relationship between itself and its "parent" mailing lists. >"If a mailing list manager encounters List-Id=20 >header fields from any unexpected source it=20 >SHOULD NOT pass them through to the mailing list. > >As mentioned above, mail list managers should=20 >not allow any user-originated List-Id header=20 >fields to pass through to their lists, lest they=20 >confuse the user and have the potential to=20 >create security problems.": Please eliminate repetition. I'll give a quick OK while I ask my co-authors about this. >"Removed List-Sequence header field as it does=20 >not fit it": What does not fit what? That was a comment to track changes in the=20 draft. It was pointed out to me that the=20 List-Sequence header field is not related to the topic discussed in the= draft. Thanks for the thorough review. I appreciate the effort you put in. Regards, S. Moonesamy=20 From sm@elandsys.com Tue Mar 13 16:28:00 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8828E21E806D; Tue, 13 Mar 2012 16:28:00 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HyZV+H9BxOUs; Tue, 13 Mar 2012 16:27:59 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id C868521E805E; Tue, 13 Mar 2012 16:27:58 -0700 (PDT) Received: from SUBMAN.elandsys.com ([41.136.233.203]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q2DNRgwI007319 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Mar 2012 16:27:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1331681276; i=@gmail.com; bh=8r+MZzKEhn0mdo4vMYrM6fIj0t7S1oU4J+76EScUyJQ=; h=Date:To:From:Subject:Cc; b=AlABZ4J0OndNLPv8UDaj5wpyfojGeKRnDmd6XzDiah95L59eM1JW48ZdO2uqEYjSa m9CCDYSitqmCYfFuVRPJX3DFDvatQvQ/bYGdBlusyGNwxco0iUJ41zOoTkSszAqPzs lj+lpEMkfPG5krB8h8tQyFhiE14abzogfpHD5Uh0= Message-Id: <6.2.5.6.2.20120313162357.0a0e5350@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 13 Mar 2012 16:27:34 -0700 To: apps-discuss@ietf.org From: Lisa Dusseault (by way of S Moonesamy ) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: draft-ietf-opsawg-management-stds.all@tools.ietf.org, opsawg@ietf.org, iesg@ietf.org Subject: [apps-discuss] APPSDIR review of draft-ietf-opsawg-management-stds-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Mar 2012 23:28:00 -0000 ---------- Forwarded message ---------- From: Lisa Dusseault To: apps-review@ietf.org, draft-ietf-opsawg-management-stds.all@tools.ietf.org Cc: IESG Date: Tue, 13 Mar 2012 16:19:54 -0700 Subject: APPSDIR review of draft-ietf-opsawg-management-stds-05 I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-opsawg-management-stds-05 Title: An Overview of the IETF Network Management Standards Reviewer: Lisa Dusseault Review Date: March 13, 2012 Summary: Document is probably a useful contribution The goal of this document sounds great, and it seems there is some need for a survey or overview of network management standards. Some sections achieve the document's goals with concise, clear summaries and pointers to outside work. Other sections of the document suffer from meaningless (e.g. circular or jargon-laden) summaries and awkward explanations, but at least the pointers will still be useful. I have some concerns about whether the document is comprehensive, because a survey is most useful when it really points to all the prior and relevant work at least in brief. While I am not in a position to notice all the places where the document may have holes in its comprehensiveness, I did note that currently active work was not consistently covered. The document does not mention or refer to ARMD, BMWG or benchmarking, GROW or BGP Monitoring. I do not know which of these Ops area WGs are important or actively making progress, but to an Ops outsider they all seem relevant. It's not as if the document does not cover active work: the document goes into some detail explaining not only the purpose of energy management work going on in the IETF but also some of the challenges of that work (appendix B). Missing other active WGs' topics seems odd. Organizational: Section 3.9 describes ACAP. Either ACAP belongs in the general purpose protocols (section 2) or another section entirely (perhaps together with XCAP in a section on application-layer configuration protocols). In any case, ACAP has been largely superseded by other work, which would be useful for readers of this document to know. Section 3.10 describes XCAP. It is similar to ACAP in the general scope of its ambition. Section 3.2 doesn't seem to fit in Section 3. I understand Section 3 to be about application-focused network management protocols and mechanisms, whereas section 3.2 does not describe any specific protocols or mechanisms, but rather operational guidance. Nits (note that generally the document would be much clearer if it had a good grammatical editorial pass): Grammatical error: "As far as valuable Best Current Practice (BCP) documents are referenced." Grammatical or cut-and-paste error: - "a management protocol used to convey management information between the SNMP entities, and management information." Grammatical error: "As such following standards build up the basis of the current SNMP Management Framework" Grammatical error: " Requirements to such a monitoring on the application level include measuring signaling quality" Grammatical error: " YANG allows to express constraints on data models by means of type restrictions and XPATH 1.0 [XPATH] expressions." Confusing: "One example SDO using DIAMETER extensively is 3GPP (e.g. 3GPP 'IP Multimedia Subsystem' (IMS) uses DIAMETER based interfaces (e.g. Cx) [3GPPIMS])." -- looks like the Cx is either an error or can be cut, Cx is not referred to anywhere else in the document Grammatical or typo: " The main goal of this protocol is to configure and manage access equipments and allow them to report information" (plural 'equipments' is not used, fix also elsewhere in doc) Grammatical: " The following subsections aim to guide the reader for the fast selection of the management standard in interest" Grammatical: " due to several factors including the rising and fluctuating energy costs,", extra 'the' _______________________________________________ appsdir mailing list appsdir@ietf.org https://www.ietf.org/mailman/listinfo/appsdir From dwing@cisco.com Tue Mar 13 16:38:50 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC92B21E8013 for ; Tue, 13 Mar 2012 16:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.036 X-Spam-Level: X-Spam-Status: No, score=-109.036 tagged_above=-999 required=5 tests=[AWL=1.563, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uzuRu0XreyRH for ; Tue, 13 Mar 2012 16:38:46 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id E5C4E21F84D0 for ; Tue, 13 Mar 2012 16:38:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=3889; q=dns/txt; s=iport; t=1331681926; x=1332891526; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=veTxRjcNt/hqH/dEmtgzGds6HPKwPFf31XAvnWxEYsk=; b=aEurulcBMwUSDFFwv6mYyZ7Y1qm45ZmA7Khdy1fnuEmO6PCePZ3X162A jJlTWvXKkqX7U7hrSjQa2fvqOCQOT5fkfUpBKVBPenYBcveqojM476B4s HXztBknvxWIeYmLemlF3orF2wGsrbaQ5TffhY4fOSW/kul0/FTekUsZSv E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFADDaX0+rRDoH/2dsb2JhbABDpguPZIEHggkBAQEDAQgKARcQPwwBAwIJDwIEAQEBJwcZIwoJCAEBBBMLF4djBAycPQGecoothkkEiFWFEpgMgwWBNQc X-IronPort-AV: E=Sophos;i="4.73,580,1325462400"; d="scan'208";a="36003753" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 13 Mar 2012 23:38:46 +0000 Received: from dwingWS ([10.32.240.194]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2DNckN3013222; Tue, 13 Mar 2012 23:38:46 GMT From: "Dan Wing" To: "'Vijay K. Gurbani'" References: <4F3592E5.3080707@bell-labs.com> <0a5701cceab4$f723c070$e56b4150$@com> <4F4801EF.9020703@bell-labs.com> In-Reply-To: <4F4801EF.9020703@bell-labs.com> Date: Tue, 13 Mar 2012 16:38:46 -0700 Message-ID: <0a3301cd0172$6f67de30$4e379a90$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AczzOzLuE61KJWY8SZ+X3u7AEiiq0AONr8SA Content-Language: en-us Cc: draft-ietf-pcp-base@tools.ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] APPSDIR rdraft-ietf-pcp-base-22 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Mar 2012 23:38:50 -0000 > -----Original Message----- > From: Vijay K. Gurbani [mailto:vkg@bell-labs.com] > Sent: Friday, February 24, 2012 1:33 PM > To: Dan Wing > Cc: apps-discuss@ietf.org; draft-ietf-pcp-base@tools.ietf.org > Subject: Re: [apps-discuss] APPSDIR rdraft-ietf-pcp-base-22 > > Dan: Sorry for the delay in responding. Day job gets in the > way. > > Please see inline for residual comments. I am skipping all > those that we agreed on for brevity. Thanks for attending to > these! > > On 02/13/2012 07:07 PM, Dan Wing wrote: > >> - S7.1, second-to-last paragraph: I suspect that if more than one > >> server was specified in the server list, the client will cycle > >> through and try the next server. I also note that this document > >> only considers one server, so exact guidance is not provided on > >> what to do when a PCP client has more than one server. > > > > We are purposefully silent on multiple servers, because we expect > that > > to be described in a later document. There are a lot of nuances and > > details related to multiple servers, including a multi-homed network > > (where you purposefully want to talk to one server, or both servers, > > for different reasons). Such a network is purposefully out of scope. > > > > However, we wanted the text to allow a list of servers to be > returned, > > so that we could do something with that list in the future. > > Sure; maybe a small indented note will help the reader that you allow > a list of servers for future extensibility but in this draft you are > only considering the case where this list has a singleton element. (I > know I would have found such a note helpful as an implementer). During IESG review, there were two Comments of a similar nature. It seemed the "list" is what triggered the confusion, so I added the sentence starting with "Thus," which tries to explain what we meant by the "default router list". -24 now reads: 2. the default router list (for IPv4 and IPv6) is used as the list of PCP Server(s). Thus, if a PCP client has both an IPv4 and IPv6 address, it will have an IPv4 PCP server (its IPv4 default router) for its IPv4 mappings, and an IPv6 PCP server (its IPv6 default router) for its IPv6 mappings. > > I adjusted the sentence so it now reads: > > > > The PCP client SHOULD impose > > an upper limit on this returned value (to protect against > > absurdly large values, e.g., 5 years), and the suggested > values > > are 24 hours for success responses and 30 minutes for error > > responses. > > > > which should be clearer? > > Perfect. Thanks! > > >> - S16.2: To protect against Advanced Threat Model attacks, the > >> draft assumes a PCP security mechanism that provides channel > >> authentication and encryption. However, no further information > >> is provided for such a mechanism. Will it help to provide > >> any candidates for such a mechanism (TLS? S/MIME?) or is there > >> something entirely different in mind? > > > > The candidate at this time is draft-wasserman-pcp-authentication, > > which uses EAP. However, it is not yet a working group document > > and it seemed premature to cite it. > > ... even as an Informational Reference? We have a DISCUSS from Stephen Farrell that we don't have anything implementable in Section 16.2. As of -24, I did not add a citation to draft-wasserman-pcp-authentication. > > Thanks for your review! > > No problem; thank you for paying attention to my comments! Thanks for your review! -d > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) > Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com > Web: http://ect.bell-labs.com/who/vkg/ From glenn.parsons@ericsson.com Tue Mar 13 18:01:20 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3315F21F8592; Tue, 13 Mar 2012 18:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.661 X-Spam-Level: X-Spam-Status: No, score=-5.661 tagged_above=-999 required=5 tests=[AWL=0.682, BAYES_00=-2.599, FU_ENDS_2_WRDS=0.255, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PPlW3Cz1yqnU; Tue, 13 Mar 2012 18:01:19 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 009BA21F858F; Tue, 13 Mar 2012 18:01:18 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q2E11FAm016453 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 13 Mar 2012 20:01:16 -0500 Received: from EUSAACMS0714.eamcs.ericsson.se ([169.254.2.27]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Tue, 13 Mar 2012 21:01:13 -0400 From: Glenn Parsons To: "apps-discuss@ietf.org" , "draft-ietf-marf-spf-reporting@tools.ietf.org" Date: Tue, 13 Mar 2012 21:01:13 -0400 Thread-Topic: Review of draft-marf-spf-reporting-08 Thread-Index: AczP3Eif5ovw7p/HQ361wftFZGD5/AuoSRIg 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="_005_D9DBDA6E6E3A9F438D9F76F0AF9D7AE34879B0CBF1EUSAACMS0714e_" MIME-Version: 1.0 Cc: "iesg@ietf.org" Subject: [apps-discuss] Review of draft-marf-spf-reporting-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 14 Mar 2012 01:01:20 -0000 --_005_D9DBDA6E6E3A9F438D9F76F0AF9D7AE34879B0CBF1EUSAACMS0714e_ Content-Type: multipart/alternative; boundary="_000_D9DBDA6E6E3A9F438D9F76F0AF9D7AE34879B0CBF1EUSAACMS0714e_" --_000_D9DBDA6E6E3A9F438D9F76F0AF9D7AE34879B0CBF1EUSAACMS0714e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have been selected as the Applications Area Directorate reviewer for this= draft (for background on appsdir, please see http://trac.tools.ietf.org/ar= ea/app/trac/wiki/ApplicationsAreaDirectorate). Please resolve these comments along with any other Last Call comments you m= ay receive. Please wait for direction from your document shepherd or AD bef= ore posting a new version of the draft. Document: draft-ietf-marf-spf-reporting-08 Title: SPF Authentication Failure Reporting using the Abuse Report Format Reviewer: Glenn Parsons Review Date: March 12, 2012 Summary: This draft is not ready for publication as a Proposed Standard and should b= e revised before publication Major Issues: This is a standards track document that is updating an experimental RFC. A= nd per the IESG Note in RFC 4408 that this is updating, there was quite a c= ontroversy on this 6 years ago. As a result, I do not see how this can be = published as a standards track update to the experimental RFC 4408 without = some sort of discussion of the issues that led to the initial publication o= f the RFC 4405-4408 set. This is especially the case since a 2 year timeli= ne for deployment review was stated as part of the IESG note (and it has be= en 6 years). If it is the case that SPF is stable enough to progress on th= e standards track then I would prefer to see RFC 4408 progressed to standar= ds track before moving forward with these extensions as standards track. A= lternatively, if there has been no determination on SPF then it would be mo= re appropriate for this document to have an experimental status. 5. The modifier "exp" is not the same as "explanation" in RFC4088. If th= e intent is for this to be shorter, then a lot more explanation of that (in= cluding ABNF update) is required. Minor Issues: 3. Does the ABNF really have to be in hex? That is why not ra instead of = %x72.61 3. The "include: mechanism" is vague. Suggest adding a reference to claus= e 5.2 of [SPF] and/or using the same naming convention from RFC 4408 -- i.e= ., "include" mechanism Nits: ** Downref: Normative reference to an Experimental RFC: RFC 4408 (ref. 'SPF= ') GLENN PARSONS Standards Advisor Ericsson Canada 3500 Carling Avenue Ottawa, ON K2H 8E9, Canada Phone +1 613 667 1569 Mobile +1 613 796 9407 glenn.parsons@ericsson.com www.ericsson.com --_000_D9DBDA6E6E3A9F438D9F76F0AF9D7AE34879B0CBF1EUSAACMS0714e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I have been selected a= s the Applications Area Directorate reviewer for this draft (for background= on appsdir, please see http://trac.t= ools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate= ).
Please resolve these c= omments along with any other Last Call comments you may receive. Please wai= t for direction from your document shepherd or AD before posting a new vers= ion of the draft.
Document: draft-ietf-marf-spf-reporting-08
Title: SPF Authentication Failure Reporting using the Abuse Report F= ormat
Reviewer: Glenn Parsons
Review Date:  March 12, 2012
Summary:
This draft is not read= y for publication as a Proposed Standard and should be revised before publi= cation
Major Issues:
This is a standards track document that is updating a= n experimental RFC.  And per the IESG Note in RFC 4408 that this is up= dating, there was quite a controversy on this 6 years ago.  As a result, I do not see how this can be published as a= standards track update to the experimental RFC 4408 without some sort of d= iscussion of the issues that led to the initial publication of the RFC 4405= -4408 set.  This is especially the case since a 2 year timeline for deployment review was stated as part of the IES= G note (and it has been 6 years).  If it is the case that SPF is stabl= e enough to progress on the standards track then I would prefer to see RFC = 4408 progressed to standards track before moving forward with these extensions as standards track.  Alternativel= y, if there has been no determination on SPF then it would be more appropri= ate for this document to have an experimental status.
5.  The modifier "exp" is not the sam= e as "explanation" in RFC4088.  If the intent is for this to= be shorter, then a lot more explanation of that (including ABNF update) is required.
Minor Issues:
3. Does the ABNF really have to be in hex?  Tha= t is why not ra instead of %x72.61
3. The "include: mechanism" is vague. = ; Suggest adding a reference to clause 5.2 of [SPF] and/or using the same n= aming convention from RFC 4408 -- i.e., "include" mechanism
 
Nits: 
 
** Downref: Normative = reference to an Experimental RFC: RFC 4408 (ref. 'SPF')
 
 



GLENN PARSONS <= /b>
Standards Advis= or =

Ericsson Canada
3500 Carling Avenue
Ottawa, ON K2H 8E9, Canada
Phone +1 613 667 1569
Mobile +1 613 796 9407
glenn.parsons@ericsson.com
www.ericsson.com




 
 --_000_D9DBDA6E6E3A9F438D9F76F0AF9D7AE34879B0CBF1EUSAACMS0714e_-- --_005_D9DBDA6E6E3A9F438D9F76F0AF9D7AE34879B0CBF1EUSAACMS0714e_ Content-Type: image/jpeg; name="Picture (Device Independent Bitmap) 1.jpg" Content-Description: Picture (Device Independent Bitmap) 1.jpg Content-Disposition: inline; filename="Picture (Device Independent Bitmap) 1.jpg"; creation-date="Wed, 14 Mar 2012 01:01:12 GMT"; modification-date="Wed, 14 Mar 2012 01:01:12 GMT" Content-ID: <8abd2434-625c-455a-aaf7-c9ccd46971f9> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCAADAP8DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD0DxiM awTzyg7+1cvJRRXwWN/3yp6sxqFaSqslFFa0Tz6hVkqrJRRXp0jgqFaSqzdaKK9OkefUG0UUV30z EWloortpiCloorupiCloortpgRNUL0UVqbwIHqBqKKR2QIGqB6KKR2QIGqFutFFI7KYoqQUUVjI9 XDkgqQUUVzTPaw5ItSLRRXNI9vDki16n8FEB1XVXyciBB9445Y9unb/OaKK5Zm2Z/wC4VPl+aP/Z --_005_D9DBDA6E6E3A9F438D9F76F0AF9D7AE34879B0CBF1EUSAACMS0714e_ Content-Type: image/jpeg; name="Picture (Device Independent Bitmap) 2.jpg" Content-Description: Picture (Device Independent Bitmap) 2.jpg Content-Disposition: inline; filename="Picture (Device Independent Bitmap) 2.jpg"; creation-date="Wed, 14 Mar 2012 01:01:12 GMT"; modification-date="Wed, 14 Mar 2012 01:01:12 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCABRAfQDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDz6TVN QErj7fdfeP8Ay2b/ABpv9q6h/wA/91/3+b/Gq0v+uf8A3jTK96yPLuy5/amof8/91/3+b/Gj+1NR /wCf+6/7/N/jS6XpV9reoxafp1u091Lnai8cDqSewHrXqehfAu5k2y67qawr1MFoNzfQuePyBrOd SnT+IuEJy2PKv7V1DIH2+6yeAPObn9ac2pamjlHvLxGHVWkYEfga+kbXw74J8CWwuXisrRgP+Pi7 cNI30Lc/lXj/AMVPFWjeKdZtJNHUyLbxsklyU2+YSeAM8kDB596zp1lUlaMdO5c6XJG7epxv9qah /wA/91/3+b/Gj+1NQ/5/7r/v83+NVKK6LIxuz638LMz+EdFZmLMbCAkk5JPlrWtWR4V/5E/RP+vC D/0Wta9eHL4menHZBRRRUjCiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi iigAooooA+NJf9c/+8abTpf9c/8AvGm1755Ru+DdZ1HQfE9reaVafbLo5iFsFJMgbqBjn3z7V7as fxH8TKPMks/DNm3UIPOuCP5CvFfBXiP/AIRXxRb6obU3ShWiaJfvENx8vvXtS+JfHHiRQNB8PJpN qw/4/NVb5seqxjn864sSnzXSXqzqotctrlux+GvhvTZDqGrvLqt0vLXWqTbwPfB4FeU/Fi78NXWu 2v8Awjwti6Rst09qoEZORtHHBI56V6dF8Mv7SlW48W67fa1IOfIL+VAPoq9vyrzD4r6N4d0XW7SD QRFE5iP2m3hfcsZB+U+xPPHtUYdp1NZNv8CqqahtY4Cloor0DjPrbwr/AMifon/XhB/6LWtesjwr /wAifon/AF4Qf+i1rXrwpfEz1I7IKKKKkYUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF FFFABRRRQAUUUUAFFFFAHxpL/rX/AN402rNvatfarDZxsFe4nESs3QFmwM/nXWTfDe6j1y20dNZs ZbyeZoSqxyARlVLEkkYI+XHHrXuOcY6M8xRb2M7wHrth4b8XWup6jA0tsispKruMZIwHA74/rXp2 ufHPT4A0eh6fLdv2muP3afl94/pXnz/Dm/EsAi1Kxngnt57iOdN4BEON6lSAQeeDVa48EzWVpbfb dX0+31K6jSWHTXLGVgxwoJAwpOehrGcaNSXMzWLqRVkJrnxC8T+INyXWpyQwN/ywtf3S/jjk/ia5 eu2f4bXg15NGj1aykvQjSXCeXIvkKoBJ5HzjkD5e9VLfwT5/224Ou2EOl2jpE9/Kkiq0jdECEbsj IznpmtIzpxXukOM29TlaK7Kb4Z65BY6xcs9uzaWRvjQljKpUNuQ9xtOfwNc/r+iz+HtYl024ljll jRHLx52kMoYdfrVRqRk7JkuElqz6k8K/8ifon/XhB/6LWtesjwr/AMifon/XhB/6LWtevFl8TPSj sgoooqRhRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAfHtpdf YdZt7zZv+z3Cy7M43bWzj9K7y6+KMVxr9lqw0/UCba4afyJr/fH8yMuFXbhfvV51L/rn/wB402vc lTjLVnmRm46I7sfEmSZ7W5v7GS5vobS5s2uDMAZElPy5GOq/rVDU/FOk67BBcarosz6vFAkBuoLs okgXozLjg49K5OkpKlBaoftJPc9AuviJaXSabbmy1UQWLvIk51DN0GIwAJMfdA7HOePSk1H4jWmu G+tdX0RptMuWikWOK42yq8YxuL4w24cGuBopexh2H7WR6BJ8VLxrh7iOwWNzfRXCKsmVEKR+X5R4 5yCeffpXMeK9dXxL4judWS2+zLMqKId27aFUDr+FY1FONKMXdITnKSsz628K/wDIn6J/14Qf+i1r XrI8K/8AIn6J/wBeEH/ota168aXxM9GOyCiiipGFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF FFFABRRRQAUUUUAFFFFABRRRQB8aS/65/wDeNNp0v+tf/eNNr3zygooooAKKKKACkpaKAPrbwr/y J+if9eEH/ota16yPCv8AyJ+if9eEH/ota168KXxM9SOyCiiipGFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB8kyf61/9402iivbPMCiiigAooooAKDRRQB9R+Gf +RU0f/rxh/8AQBWrRRXiy3Z6S2CiiikMKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigD/2Q== --_005_D9DBDA6E6E3A9F438D9F76F0AF9D7AE34879B0CBF1EUSAACMS0714e_-- From scott@kitterman.com Tue Mar 13 18:33:37 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 201AC21E801B; Tue, 13 Mar 2012 18:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f-lFclL0frKo; Tue, 13 Mar 2012 18:33:36 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 2EC8511E8073; Tue, 13 Mar 2012 18:33:36 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id B14B520E40BD; Tue, 13 Mar 2012 21:33:35 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1331688815; bh=xygsrBbB8qSJA/YsfvpqWVQVVvfw5IXLurICnJYVxMI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=D/cdqy+IFaGGirU89SrEqWIjXYwVVN9Rxs7HkRiaV5tctFxfRnOtunjX43Vz52rHO wMebxzsCvvaieLaTGC6AiI5rg7fJhEzdOlpEG9iXfp8gaSmtIISbhvLtHTVoRQMl0r ciFZXPCjf/AXyfsZ2RwPzAHA6kxPwEVDVNM/bdnA= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 91DD720E4064; Tue, 13 Mar 2012 21:33:35 -0400 (EDT) From: Scott Kitterman To: apps-discuss@ietf.org, Glenn Parsons Date: Tue, 13 Mar 2012 21:33:34 -0400 Message-ID: <1344986.gzdu38iGHL@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Cc: "iesg@ietf.org" , "draft-ietf-marf-spf-reporting@tools.ietf.org" Subject: Re: [apps-discuss] Review of draft-marf-spf-reporting-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 14 Mar 2012 01:33:37 -0000 On Tuesday, March 13, 2012 09:01:13 PM Glenn Parsons wrote: > I have been selected as the Applications Area Directorate reviewer for this > draft (for background on appsdir, please see > http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). > Please resolve these comments along with any other Last Call comments you > may receive. Please wait for direction from your document shepherd or AD > before posting a new version of the draft. Document: > draft-ietf-marf-spf-reporting-08 This is not the current revision of the draft. > Title: SPF Authentication Failure Reporting using the Abuse Report Format > Reviewer: Glenn Parsons > Review Date: March 12, 2012 > > Summary: > This draft is not ready for publication as a Proposed Standard and should be > revised before publication Major Issues: > This is a standards track document that is updating an experimental RFC. > And per the IESG Note in RFC 4408 that this is updating, there was quite a > controversy on this 6 years ago. As a result, I do not see how this can be > published as a standards track update to the experimental RFC 4408 without > some sort of discussion of the issues that led to the initial publication > of the RFC 4405-4408 set. This is especially the case since a 2 year > timeline for deployment review was stated as part of the IESG note (and it > has been 6 years). If it is the case that SPF is stable enough to progress > on the standards track then I would prefer to see RFC 4408 progressed to > standards track before moving forward with these extensions as standards > track. Alternatively, if there has been no determination on SPF then it > would be more appropriate for this document to have an experimental status. There is an SPFbis working group that has been chartered to deal with these issues. The exact question of if it made sense to table this draft until SPFbis was disscussed in the working group and the conclusion was that it did not make sense to wait. > 5. The modifier "exp" is not the same as "explanation" in RFC4088. If the > intent is for this to be shorter, then a lot more explanation of that > (including ABNF update) is required. Where do you get that it's not the same? The draft says the source for exp is RFC 4408. > Minor Issues: > 3. Does the ABNF really have to be in hex? That is why not ra instead of > %x72.61 It's consistent with the related documents the working group has produced. > 3. The "include: mechanism" is vague. Suggest adding a reference > to clause 5.2 of [SPF] and/or using the same naming convention from RFC > 4408 -- i.e., "include" mechanism This seems reasonable. > > Nits: > > > ** Downref: Normative reference to an Experimental RFC: RFC 4408 (ref. > 'SPF') I think this is addressed. Scott K From barryleiba@gmail.com Tue Mar 13 18:50:29 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDA6321F8549; Tue, 13 Mar 2012 18:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.984 X-Spam-Level: X-Spam-Status: No, score=-102.984 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sFmxlM2Hmd6n; Tue, 13 Mar 2012 18:50:29 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 596A921F8548; Tue, 13 Mar 2012 18:50:29 -0700 (PDT) Received: by yenm5 with SMTP id m5so1454653yen.31 for ; Tue, 13 Mar 2012 18:50:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Frn/2H+F/qfXjIse39aR9997VcX/sGjqtdBjgVzQ4sk=; b=zRkovTLupu4knTqsYkQpEZCiqFuD2DzZnGeMH3Qct8JMkbmNxnQTZhsY5Lc7trrURv /ujAB2Gz+OztoYVZGEGqedvYlXU2mMTztDrywrCgQKWhtQG/ksgGIBquovjuQiX6p9lv /wokr2y4NmzMMnyDB0kbMqx0kFjzdjbb+NZZUaAFJvv4RO5wbk07p4Q6b49RNBsdKYVx U0MtItspOvpOEewas+ISEenr0pxsCKB3pkLRcnX+YEKb3Cj1pn3lRc+4kDD66SQEJkn6 t5kPBDJ+V0Wr2GQd31n4lMYLpyR6kT8W+vfO2I+HnSn5D84MzjbR+riqWSM60JhLjB0Z QNUA== MIME-Version: 1.0 Received: by 10.60.3.226 with SMTP id f2mr826218oef.44.1331689828872; Tue, 13 Mar 2012 18:50:28 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.60.125.37 with HTTP; Tue, 13 Mar 2012 18:50:28 -0700 (PDT) In-Reply-To: <1344986.gzdu38iGHL@scott-latitude-e6320> References: <1344986.gzdu38iGHL@scott-latitude-e6320> Date: Tue, 13 Mar 2012 21:50:28 -0400 X-Google-Sender-Auth: xwU3fLVlDC6QOWQqcMVT9HsuEz0 Message-ID: From: Barry Leiba To: Glenn Parsons Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "iesg@ietf.org" , apps-discuss@ietf.org, "draft-ietf-marf-spf-reporting@tools.ietf.org" Subject: Re: [apps-discuss] Review of draft-marf-spf-reporting-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 14 Mar 2012 01:50:30 -0000 >> =A03. Does the ABNF really have to be in hex? =A0That is why not ra inst= ead of >> %x72.61 > > It's consistent with the related documents the working group has produced= . To be a little clearer and more useful: The ABNF is done that way because literal strings in ABNF are not case-specific, so using "ra" in the ABNF also allows "RA", "Ra", and "rA". How do we make it "ra", lower-case only, other than using hex? We don't know how, and we've just used hex (it's in DKIM and other docs as well). It's icky, but there it is. Barry From duerst@it.aoyama.ac.jp Tue Mar 13 19:14:03 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E441E21E8042 for ; Tue, 13 Mar 2012 19:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.386 X-Spam-Level: X-Spam-Status: No, score=-100.386 tagged_above=-999 required=5 tests=[AWL=-0.596, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S2NVx7nmvyfv for ; Tue, 13 Mar 2012 19:14:03 -0700 (PDT) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 46F6B21E803A for ; Tue, 13 Mar 2012 19:14:02 -0700 (PDT) Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id q2E2Dsov015932 for ; Wed, 14 Mar 2012 11:13:55 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 71eb_5aa4_590e4b90_6d7b_11e1_b9ee_001d096c566a; Wed, 14 Mar 2012 11:13:53 +0900 Received: from [IPv6:::1] ([133.2.210.1]:44741) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 14 Mar 2012 11:13:58 +0900 Message-ID: <4F5FFEDE.80703@it.aoyama.ac.jp> Date: Wed, 14 Mar 2012 11:13:50 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Barry Leiba References: <1344986.gzdu38iGHL@scott-latitude-e6320> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "draft-ietf-marf-spf-reporting@tools.ietf.org" , apps-discuss@ietf.org, "iesg@ietf.org" Subject: Re: [apps-discuss] Review of draft-marf-spf-reporting-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 14 Mar 2012 02:14:04 -0000 On 2012/03/14 10:50, Barry Leiba wrote: >>> 3. Does the ABNF really have to be in hex? That is why not ra instead of >>> %x72.61 >> >> It's consistent with the related documents the working group has produced. > > To be a little clearer and more useful: > The ABNF is done that way because literal strings in ABNF are not > case-specific, so using "ra" in the ABNF also allows "RA", "Ra", and > "rA". How do we make it "ra", lower-case only, other than using hex? > We don't know how, and we've just used hex (it's in DKIM and other > docs as well). > > It's icky, but there it is. What I have done in some instance (sorry, don't remember anymore what that was) was to say that we use ABNF, but without the case-insensitivity. If all the syntax is case-sensitive, that works. If part of the syntax is case-sensitive and the rest is case-insensitive, either way of using ABNF gets rather unreadable. Regards, Martin. From dhc@dcrocker.net Tue Mar 13 19:54:53 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7A7821F8551; Tue, 13 Mar 2012 19:54:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.459 X-Spam-Level: X-Spam-Status: No, score=-6.459 tagged_above=-999 required=5 tests=[AWL=-0.160, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oLofGSJyo+MI; Tue, 13 Mar 2012 19:54:49 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 28E1721F8548; Tue, 13 Mar 2012 19:54:49 -0700 (PDT) Received: from [192.168.1.11] (adsl-67-127-58-62.dsl.pltn13.pacbell.net [67.127.58.62]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q2E2shfb011914 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Mar 2012 19:54:48 -0700 Message-ID: <4F60085B.4080101@dcrocker.net> Date: Tue, 13 Mar 2012 19:54:19 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= References: <1344986.gzdu38iGHL@scott-latitude-e6320> <4F5FFEDE.80703@it.aoyama.ac.jp> In-Reply-To: <4F5FFEDE.80703@it.aoyama.ac.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 13 Mar 2012 19:54:49 -0700 (PDT) Cc: "iesg@ietf.org" , apps-discuss@ietf.org, "draft-ietf-marf-spf-reporting@tools.ietf.org" Subject: Re: [apps-discuss] Review of draft-marf-spf-reporting-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 02:54:53 -0000 On 3/13/2012 7:13 PM, "Martin J. Dürst" wrote: > What I have done in some instance (sorry, don't remember anymore what that was) > was to say that we use ABNF, but without the case-insensitivity. If all the > syntax is case-sensitive, that works. If part of the syntax is case-sensitive > and the rest is case-insensitive, either way of using ABNF gets rather unreadable. That's a really good approach for getting mis-readings of the spec. You are calling it thing but then re-defining it. By saying 'ABNF' you invoke a set of knowledge and expectations. Although you are no doubt diligent and proper in re-defining this one characteristic, readers are going to tend to fall back on what they already know about ABNF. If it's that important to have a construct for 'case-dependent' strings, then define a new construct. ABNF is extensible. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From ned.freed@mrochek.com Tue Mar 13 20:02:19 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D51EE21F8585; Tue, 13 Mar 2012 20:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9oHsv4LD5COI; Tue, 13 Mar 2012 20:02:18 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id CB4F921F8584; Tue, 13 Mar 2012 20:02:18 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OD2V58FFK00080V7@mauve.mrochek.com>; Tue, 13 Mar 2012 20:02:14 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OCPMUVDUMO00ZUIL@mauve.mrochek.com>; Tue, 13 Mar 2012 20:02:05 -0700 (PDT) Message-id: <01OD2V534LXE00ZUIL@mauve.mrochek.com> Date: Tue, 13 Mar 2012 19:42:24 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 13 Mar 2012 21:33:34 -0400" <1344986.gzdu38iGHL@scott-latitude-e6320> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <1344986.gzdu38iGHL@scott-latitude-e6320> To: Scott Kitterman DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1331694135; bh=QjeC+AKLU5bxUytCfSa11ydEULqqTsPL11ybijxd6qI=; h=Cc:Message-id:Date:From:Subject:In-reply-to:MIME-version: Content-type:References:To; b=Ghy3JSEXyU5bdH2tTj5OyNjZ5AhA7ZdSgPu/X75SdHrjLp1YnMsVRYFmDt8tS4FJx QfhNHNxCHisGID95M7ObaNXnksJRSjKmvARBF4Uocw7j6U19yqKiTBtQ+3ZnoYSbFW nnv9h7vgwRFwTGZ991lx69VbDXYJbgR7A4ZmFm30= Cc: "draft-ietf-marf-spf-reporting@tools.ietf.org" , apps-discuss@ietf.org, "iesg@ietf.org" Subject: Re: [apps-discuss] Review of draft-marf-spf-reporting-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 14 Mar 2012 03:02:20 -0000 One small comment here: > > 3. Does the ABNF really have to be in hex? That is why not ra instead of > > %x72.61 That depends on whether or not you want it to be case-sensitive. "ra" is case insensitive, %x72.61 is explicitly in lower case. See RFC 5234 section 2.3. > It's consistent with the related documents the working group has produced. I don't find that to be the case in either SPF or MARK documents, but even if it is, I fail to see the relevance. This isn't a consistency of terminology issue - the two different ABNF terminals are not different representations of the same thing. So what matters is whether or not this particular terminal is supposed to be case-sensitive. You're defining a new SPF record modifier here. RFC 4408 clearly states in section 4.6.1 that modifier names are case-insensitive. So "ra" is correct and %x72.61 is incorrect. Ned From ned.freed@mrochek.com Tue Mar 13 20:03:15 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E75E221F8585; Tue, 13 Mar 2012 20:03:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PtizDMSIDVXl; Tue, 13 Mar 2012 20:03:15 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 7B58821F8584; Tue, 13 Mar 2012 20:03:15 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OD2V6EMAQO0080V7@mauve.mrochek.com>; Tue, 13 Mar 2012 20:03:11 -0700 (PDT) MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=iso-8859-1 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OCPMUVDUMO00ZUIL@mauve.mrochek.com>; Tue, 13 Mar 2012 20:03:06 -0700 (PDT) Message-id: <01OD2V6C91KQ00ZUIL@mauve.mrochek.com> Date: Tue, 13 Mar 2012 20:02:31 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 13 Mar 2012 21:50:28 -0400" References: <1344986.gzdu38iGHL@scott-latitude-e6320> To: Barry Leiba DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1331694192; bh=N0oK8TJLpF/GGGBKz0dqpGI+epbDfBQI28HvxSqTTJk=; h=MIME-version:Content-type:Cc:Message-id:Date:From:Subject: In-reply-to:References:To; b=awXO5hku/dC8pKMjWbJRLZ6DRBEdSEuIQLMZ4MN4wl+yPrc0r1WuQrF7GNQZnamvc HRdbn9rqWzPJpEqM0x3HNN70NMXkKZmqZf5Mg7DbeoRmd3n8XvPxFhy49spAwRIt77 JvC9HTotrNFqod6hJjd6kTZwkNDjduGelHo7q4oE= Cc: "draft-ietf-marf-spf-reporting@tools.ietf.org" , apps-discuss@ietf.org, "iesg@ietf.org" Subject: Re: [apps-discuss] Review of draft-marf-spf-reporting-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 14 Mar 2012 03:03:16 -0000 > >>  3. Does the ABNF really have to be in hex?  That is why not ra instead of > >> %x72.61 > > > > It's consistent with the related documents the working group has produced. > To be a little clearer and more useful: > The ABNF is done that way because literal strings in ABNF are not > case-specific, so using "ra" in the ABNF also allows "RA", "Ra", and > "rA". How do we make it "ra", lower-case only, other than using hex? > We don't know how, and we've just used hex (it's in DKIM and other > docs as well). > It's icky, but there it is. But this is an SPF thing, not a MARF thing. SPF semantics apply, and those semantics say these strings are supposed to be case-insensitive. Ned From scott@kitterman.com Tue Mar 13 20:05:33 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D41921E804D; Tue, 13 Mar 2012 20:05:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aF-L++FEK6pk; Tue, 13 Mar 2012 20:05:32 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB6821E800F; Tue, 13 Mar 2012 20:05:32 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 055B020E40BD; Tue, 13 Mar 2012 23:05:32 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1331694332; bh=BpZwub5zT30c7CCJ+s1lMi/hfBdeHO6CLseiNvZsbyU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=D6KPIoJ2y6X9aSqDbuOT/JGf7qVTJJPggHkj1m63+3+LH+TJGYgEVMIVM5/UupWUd cgxcaXuyS6GwhbshL+fv9IWasa+9K5Wk9l8E67W+yHUI1mtubbjgR1NW3nITiKdnOW AkcADBvRSd6hc5v8qGwF2Krvv9ynVah+MZ9CDH5g= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id DF13E20E4064; Tue, 13 Mar 2012 23:05:31 -0400 (EDT) From: Scott Kitterman To: Ned Freed Date: Tue, 13 Mar 2012 23:05:31 -0400 Message-ID: <8706442.lrbpmYfGfV@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: <01OD2V534LXE00ZUIL@mauve.mrochek.com> References: <1344986.gzdu38iGHL@scott-latitude-e6320> <01OD2V534LXE00ZUIL@mauve.mrochek.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Cc: "draft-ietf-marf-spf-reporting@tools.ietf.org" , apps-discuss@ietf.org, "iesg@ietf.org" Subject: Re: [apps-discuss] Review of draft-marf-spf-reporting-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 14 Mar 2012 03:05:33 -0000 On Tuesday, March 13, 2012 07:42:24 PM Ned Freed wrote: > One small comment here: > > > 3. Does the ABNF really have to be in hex? That is why not ra > > > instead of> > > > > %x72.61 > > That depends on whether or not you want it to be case-sensitive. "ra" is > case insensitive, %x72.61 is explicitly in lower case. See RFC 5234 section > 2.3. > > It's consistent with the related documents the working group has > > produced. > I don't find that to be the case in either SPF or MARK documents, but even > if it is, I fail to see the relevance. This isn't a consistency of > terminology issue - the two different ABNF terminals are not different > representations of the same thing. So what matters is whether or not this > particular terminal is supposed to be case-sensitive. > > You're defining a new SPF record modifier here. RFC 4408 clearly states in > section 4.6.1 that modifier names are case-insensitive. So "ra" is correct > and %x72.61 is incorrect. That's a good point. The related drafts I'd meant where the other MARF drafts, but I think I agree with you upon reflection. Scott K From glenn.parsons@ericsson.com Tue Mar 13 20:42:55 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA3321E800F; Tue, 13 Mar 2012 20:42:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.96 X-Spam-Level: X-Spam-Status: No, score=-5.96 tagged_above=-999 required=5 tests=[AWL=0.639, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y7K9rBxfVkNS; Tue, 13 Mar 2012 20:42:54 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 8C7F921F84A7; Tue, 13 Mar 2012 20:42:54 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q2E3goqa024867; Tue, 13 Mar 2012 22:42:51 -0500 Received: from EUSAACMS0714.eamcs.ericsson.se ([169.254.2.27]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Tue, 13 Mar 2012 23:42:44 -0400 From: Glenn Parsons To: "apps-discuss@ietf.org" Date: Tue, 13 Mar 2012 23:42:43 -0400 Thread-Topic: [apps-discuss] Review of draft-marf-spf-reporting-08 Thread-Index: Ac0Bgoe1oYDzTjrOQCaBqaimNv1vRgAEAMHA Message-ID: References: <1344986.gzdu38iGHL@scott-latitude-e6320> In-Reply-To: <1344986.gzdu38iGHL@scott-latitude-e6320> 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: "iesg@ietf.org" , "draft-ietf-marf-spf-reporting@tools.ietf.org" Subject: Re: [apps-discuss] Review of draft-marf-spf-reporting-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 14 Mar 2012 03:42:55 -0000 If the consensus is that you cannot wait ... my point is that given the IES= G note in RFC 4408, it is not appropriate to make this standards track with= out an indication of the fact that RFC 4408 is being revised/elevated to st= andards track. Now that note could be another IESG note... BTW, would SPFbis would then subsume this RFC ? On exp / explanation, I misread so that is not an issue. And on the ABNF, my comment would apply to "ra", "rp" and "rr" Cheers, Glenn. -----Original Message----- From: Scott Kitterman [mailto:scott@kitterman.com]=20 Sent: March-13-12 9:34 PM To: apps-discuss@ietf.org; Glenn Parsons Cc: draft-ietf-marf-spf-reporting@tools.ietf.org; iesg@ietf.org Subject: Re: [apps-discuss] Review of draft-marf-spf-reporting-08 On Tuesday, March 13, 2012 09:01:13 PM Glenn Parsons wrote: > I have been selected as the Applications Area Directorate reviewer for=20 > this draft (for background on appsdir, please see=20 > http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate= ). > Please resolve these comments along with any other Last Call comments=20 > you may receive. Please wait for direction from your document shepherd=20 > or AD before posting a new version of the draft. Document: > draft-ietf-marf-spf-reporting-08 This is not the current revision of the draft. > Title: SPF Authentication Failure Reporting using the Abuse Report=20 > Format > Reviewer: Glenn Parsons > Review Date: March 12, 2012 >=20 > Summary: > This draft is not ready for publication as a Proposed Standard and=20 > should be revised before publication Major Issues: > This is a standards track document that is updating an experimental RFC.= =20 > And per the IESG Note in RFC 4408 that this is updating, there was=20 > quite a controversy on this 6 years ago. As a result, I do not see=20 > how this can be published as a standards track update to the=20 > experimental RFC 4408 without some sort of discussion of the issues=20 > that led to the initial publication of the RFC 4405-4408 set. This is=20 > especially the case since a 2 year timeline for deployment review was=20 > stated as part of the IESG note (and it has been 6 years). If it is=20 > the case that SPF is stable enough to progress on the standards track=20 > then I would prefer to see RFC 4408 progressed to standards track=20 > before moving forward with these extensions as standards track. =20 > Alternatively, if there has been no determination on SPF then it would be= more appropriate for this document to have an experimental status. There is an SPFbis working group that has been chartered to deal with these= issues. The exact question of if it made sense to table this draft until = SPFbis was disscussed in the working group and the conclusion was that it d= id not make sense to wait. > 5. The modifier "exp" is not the same as "explanation" in RFC4088. =20 > If the intent is for this to be shorter, then a lot more explanation=20 > of that (including ABNF update) is required. Where do you get that it's not the same? The draft says the source for exp= is RFC 4408. > Minor Issues: > 3. Does the ABNF really have to be in hex? That is why not ra=20 > instead of > %x72.61 It's consistent with the related documents the working group has produced. > 3. The "include: mechanism" is vague. Suggest adding a reference to=20 > clause 5.2 of [SPF] and/or using the same naming convention from RFC > 4408 -- i.e., "include" mechanism This seems reasonable. >=20 > Nits: >=20 >=20 > ** Downref: Normative reference to an Experimental RFC: RFC 4408 (ref. > 'SPF') I think this is addressed. Scott K From scott@kitterman.com Tue Mar 13 20:56:30 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14A8121E8017; Tue, 13 Mar 2012 20:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.59 X-Spam-Level: X-Spam-Status: No, score=-3.59 tagged_above=-999 required=5 tests=[AWL=1.009, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EEIYYewTtZUD; Tue, 13 Mar 2012 20:56:29 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id DBD5B21E800F; Tue, 13 Mar 2012 20:56:28 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 44D5520E40D0; Tue, 13 Mar 2012 23:56:28 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1331697388; bh=LJmJhuM441WwKyDFlYZjjM3XxnBJgqXRnzr/FbeCtXc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Transfer-Encoding:Content-Type; b=EWGk3H+X2iLAdUHzZeZkp62Sz7v82FJqWz0B6TgSt3gOD2fuEUdWlqCsevxayMLCc ZbMzWpc/50b89weZGpN+mA6HSjrDajBJTrI8A1jTmf77V7CVaI+iFOa9yaQS3tBXPV IU+XLALQyWlQuViEtZ0Lksi7Wggu/3hBZ/SzcDys= Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 294DB20E4064; Tue, 13 Mar 2012 23:56:27 -0400 (EDT) From: Scott Kitterman To: apps-discuss@ietf.org Date: Tue, 13 Mar 2012 23:56:27 -0400 Message-ID: <3722383.WlunSX8BHo@scott-latitude-e6320> User-Agent: KMail/4.7.3 (Linux/3.0.0-16-generic-pae; KDE/4.7.4; i686; ; ) In-Reply-To: References: <1344986.gzdu38iGHL@scott-latitude-e6320> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-AV-Checked: ClamAV using ClamSMTP Cc: "draft-ietf-marf-spf-reporting@tools.ietf.org" , "iesg@ietf.org" Subject: Re: [apps-discuss] Review of draft-marf-spf-reporting-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 14 Mar 2012 03:56:30 -0000 On Tuesday, March 13, 2012 11:42:43 PM Glenn Parsons wrote: > If the consensus is that you cannot wait ... my point is that given the IESG > note in RFC 4408, it is not appropriate to make this standards track > without an indication of the fact that RFC 4408 is being revised/elevated > to standards track. Now that note could be another IESG note... The downref was discussed in the working group, there was consensus to proceed, and it was specifically noted in the last call announcement. AIUI, that's all that's required from a process perspective. On a practical basis, there is no chance that the changes proposed for SPFbis would affect the content of this draft. It would be well outside the scope of the charter. > BTW, would SPFbis would then subsume this RFC ? It would be up to the working group to determine. To fit into the existing charter, the WG would have to determine this was widely deployed. By the time we get to discussing it, it may be (or maybe a small charter adjustment). It's hard to tell. > On exp / explanation, I misread so that is not an issue. OK. Thanks. > And on the ABNF, my comment would apply to "ra", "rp" and "rr" Based on the other discussions in this thread I agree. We should make them case insensitive and use the actual letters. That's a simple enough change to make. Scott K > > Cheers, > Glenn. > > > -----Original Message----- > From: Scott Kitterman [mailto:scott@kitterman.com] > Sent: March-13-12 9:34 PM > To: apps-discuss@ietf.org; Glenn Parsons > Cc: draft-ietf-marf-spf-reporting@tools.ietf.org; iesg@ietf.org > Subject: Re: [apps-discuss] Review of draft-marf-spf-reporting-08 > > On Tuesday, March 13, 2012 09:01:13 PM Glenn Parsons wrote: > > I have been selected as the Applications Area Directorate reviewer for > > this draft (for background on appsdir, please see > > http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorat > > e). Please resolve these comments along with any other Last Call > > comments you may receive. Please wait for direction from your document > > shepherd or AD before posting a new version of the draft. Document: > > draft-ietf-marf-spf-reporting-08 > > This is not the current revision of the draft. > > > Title: SPF Authentication Failure Reporting using the Abuse Report > > Format > > Reviewer: Glenn Parsons > > Review Date: March 12, 2012 > > > > Summary: > > This draft is not ready for publication as a Proposed Standard and > > should be revised before publication Major Issues: > > This is a standards track document that is updating an experimental RFC. > > And per the IESG Note in RFC 4408 that this is updating, there was > > quite a controversy on this 6 years ago. As a result, I do not see > > how this can be published as a standards track update to the > > experimental RFC 4408 without some sort of discussion of the issues > > that led to the initial publication of the RFC 4405-4408 set. This is > > especially the case since a 2 year timeline for deployment review was > > stated as part of the IESG note (and it has been 6 years). If it is > > the case that SPF is stable enough to progress on the standards track > > then I would prefer to see RFC 4408 progressed to standards track > > before moving forward with these extensions as standards track. > > Alternatively, if there has been no determination on SPF then it would > > be more appropriate for this document to have an experimental status. > There is an SPFbis working group that has been chartered to deal with these > issues. The exact question of if it made sense to table this draft until > SPFbis was disscussed in the working group and the conclusion was that it > did not make sense to wait. > > 5. The modifier "exp" is not the same as "explanation" in RFC4088. > > If the intent is for this to be shorter, then a lot more explanation > > of that (including ABNF update) is required. > > Where do you get that it's not the same? The draft says the source for exp > is RFC 4408. > > Minor Issues: > > 3. Does the ABNF really have to be in hex? That is why not ra > > > > instead of > > %x72.61 > > It's consistent with the related documents the working group has produced. > > > 3. The "include: mechanism" is vague. Suggest adding a reference to > > clause 5.2 of [SPF] and/or using the same naming convention from RFC > > 4408 -- i.e., "include" mechanism > > This seems reasonable. > > > Nits: > > > > > > ** Downref: Normative reference to an Experimental RFC: RFC 4408 (ref. > > 'SPF') > > I think this is addressed. > > Scott K > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From ned.freed@mrochek.com Tue Mar 13 21:02:54 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17A2A21E8017; Tue, 13 Mar 2012 21:02:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XawRWmQoqnxn; Tue, 13 Mar 2012 21:02:53 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 2920821E800F; Tue, 13 Mar 2012 21:02:53 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OD2X99HE3K002N64@mauve.mrochek.com>; Tue, 13 Mar 2012 21:02:45 -0700 (PDT) MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=iso-8859-1; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OCPMUVDUMO00ZUIL@mauve.mrochek.com>; Tue, 13 Mar 2012 21:02:39 -0700 (PDT) Message-id: <01OD2X96ESFW00ZUIL@mauve.mrochek.com> Date: Tue, 13 Mar 2012 21:01:33 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 13 Mar 2012 19:54:19 -0700" <4F60085B.4080101@dcrocker.net> References: <1344986.gzdu38iGHL@scott-latitude-e6320> <4F5FFEDE.80703@it.aoyama.ac.jp> <4F60085B.4080101@dcrocker.net> To: Dave Crocker DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1331697767; bh=nhjJjQQHq6QZLbAXvUwruXpo9M5weTM9NZZ6eWFGCFQ=; h=MIME-version:Content-type:Cc:Message-id:Date:From:Subject: In-reply-to:References:To; b=pu0rRULUqExbPAojrcWKhZ1YtwhSsxvDIuXUzdmuFi/kZJN1yD2XNZfN/QXpgZOBa G51eXbBhRFFGG1OBlIFis+EyOwtciw/rAQlQCvsMFsi2tkS0G5vtsbIvaY1+4OnEtC Z0Fzuw2na21ZGhjBIrPQscvYSt7jk6q0fAF7VfWA= Cc: "iesg@ietf.org" , apps-discuss@ietf.org, "draft-ietf-marf-spf-reporting@tools.ietf.org" Subject: Re: [apps-discuss] Review of draft-marf-spf-reporting-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 14 Mar 2012 04:02:54 -0000 > On 3/13/2012 7:13 PM, "Martin J. Dürst" wrote: > > What I have done in some instance (sorry, don't remember anymore what that was) > > was to say that we use ABNF, but without the case-insensitivity. If all the > > syntax is case-sensitive, that works. If part of the syntax is case-sensitive > > and the rest is case-insensitive, either way of using ABNF gets rather unreadable. > That's a really good approach for getting mis-readings of the spec. I have to agree. If I were on the IESG I'd push back *hard* on this. > You are calling it thing but then re-defining it. By saying 'ABNF' you invoke a > set of knowledge and expectations. Although you are no doubt diligent and > proper in re-defining this one characteristic, readers are going to tend to fall > back on what they already know about ABNF. > If it's that important to have a construct for 'case-dependent' strings, then > define a new construct. > ABNF is extensible. E.g., say that single quoted strings are case sensitive. That's a much better approach IMO. Ned From walter.stanish@gmail.com Tue Mar 13 21:21:29 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 026D521E800F for ; Tue, 13 Mar 2012 21:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.36 X-Spam-Level: X-Spam-Status: No, score=-2.36 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C3UsKfu2cyKI for ; Tue, 13 Mar 2012 21:21:27 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2101321E803A for ; Tue, 13 Mar 2012 21:21:26 -0700 (PDT) Received: by yhpp34 with SMTP id p34so1559476yhp.31 for ; Tue, 13 Mar 2012 21:21:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; bh=lS2Uc2I7sDPCqFFzxh0Qjh80mgwmemNHBUDzGXD553s=; b=d5B+P4ddlkH1Z4/5xjnG1LcBPEBdaioEo6zFXQ1aqogtRE348eD092t0sKKlA7pyC3 K7zyw7jqpH9qCZW786UrOS2ZJQYWKdGyeBoYbOU6bnEzY9cACaPqQuUoqigLJjKB+pbp 5RazvKEACon2LnjQLnqZCwt6xp798R3cZ2yvDpK/f1al9afh83t4n6y6HxVWhsTTk0+y FARJ/EuaJS1EsEdu6Y1cEpGloKJJjNOTEIp3qFDr3C9YWIsWkpuPft3hg8g4PDGbV+gU BIR9+uM2qbk8STNjh/ukAFmBQGky8zosh1F5vBQjeKsn2IuDd/ByGYCpPIkf5Z91QzHL 8gPw== MIME-Version: 1.0 Received: by 10.182.86.197 with SMTP id r5mr1243190obz.7.1331698885009; Tue, 13 Mar 2012 21:21:25 -0700 (PDT) Received: by 10.60.149.225 with HTTP; Tue, 13 Mar 2012 21:21:24 -0700 (PDT) In-Reply-To: References: <4F5ADDCA.80303@KingsMountain.com> Date: Wed, 14 Mar 2012 11:21:24 +0700 Message-ID: From: Walter Cc: Apps Discuss Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [apps-discuss] Proposal for a Finance Area Mailing List X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 14 Mar 2012 04:21:30 -0000 *nudge* From duerst@it.aoyama.ac.jp Tue Mar 13 21:46:03 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2252121E8073 for ; Tue, 13 Mar 2012 21:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.348 X-Spam-Level: X-Spam-Status: No, score=-100.348 tagged_above=-999 required=5 tests=[AWL=-0.558, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vaXjRfLMMVEp for ; Tue, 13 Mar 2012 21:46:01 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id E929D21E8017 for ; Tue, 13 Mar 2012 21:45:56 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id q2E4jnk2002867 for ; Wed, 14 Mar 2012 13:45:50 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 6876_b885_9284d65e_6d90_11e1_8e33_001d096c5782; Wed, 14 Mar 2012 13:45:49 +0900 Received: from [IPv6:::1] ([133.2.210.1]:51986) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 14 Mar 2012 13:45:54 +0900 Message-ID: <4F60227C.6020200@it.aoyama.ac.jp> Date: Wed, 14 Mar 2012 13:45:48 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Ned Freed References: <1344986.gzdu38iGHL@scott-latitude-e6320> <4F5FFEDE.80703@it.aoyama.ac.jp> <4F60085B.4080101@dcrocker.net> <01OD2X96ESFW00ZUIL@mauve.mrochek.com> In-Reply-To: <01OD2X96ESFW00ZUIL@mauve.mrochek.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "iesg@ietf.org" , apps-discuss@ietf.org, "draft-ietf-marf-spf-reporting@tools.ietf.org" Subject: Re: [apps-discuss] Review of draft-marf-spf-reporting-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 14 Mar 2012 04:46:03 -0000 Hello Ned, Dave, others, On 2012/03/14 13:01, Ned Freed wrote: > > >> On 3/13/2012 7:13 PM, "Martin J. Dürst" wrote: >> > What I have done in some instance (sorry, don't remember anymore >> what that was) I found it: http://tools.ietf.org/html/rfc5147#section-3. >> > was to say that we use ABNF, but without the case-insensitivity. If >> all the >> > syntax is case-sensitive, that works. If part of the syntax is >> case-sensitive >> > and the rest is case-insensitive, either way of using ABNF gets >> rather unreadable. > > >> That's a really good approach for getting mis-readings of the spec. > > I have to agree. If I were on the IESG I'd push back *hard* on this. I half agree and half disagree. There is another case where we use ABNF with Unicode characters, not ASCII (http://tools.ietf.org/html/rfc3987#section-2.2). Although that's allowed by the ABNF spec, I'd guess most people will overread it at first. >> You are calling it thing but then re-defining it. By saying 'ABNF' you >> invoke a >> set of knowledge and expectations. Although you are no doubt diligent and >> proper in re-defining this one characteristic, readers are going to >> tend to fall >> back on what they already know about ABNF. Or what they think they already know about ABNF. >> If it's that important to have a construct for 'case-dependent' >> strings, then >> define a new construct. > >> ABNF is extensible. > > E.g., say that single quoted strings are case sensitive. That's a much > better > approach IMO. Good idea, I'll use that the next time I need it. I don't expect an update of RFC 5147 soon, nor do I have any other work around now that would need that feature, however. Regards, Martin. From nico@cryptonector.com Tue Mar 13 22:40:53 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EB5521F85F1 for ; Tue, 13 Mar 2012 22:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.194 X-Spam-Level: X-Spam-Status: No, score=-2.194 tagged_above=-999 required=5 tests=[AWL=-0.217, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HtlTSm47-SaP for ; Tue, 13 Mar 2012 22:40:52 -0700 (PDT) Received: from homiemail-a98.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 6FF1F21F85EE for ; Tue, 13 Mar 2012 22:40:52 -0700 (PDT) Received: from homiemail-a98.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a98.g.dreamhost.com (Postfix) with ESMTP id 260052C206E for ; Tue, 13 Mar 2012 22:40:52 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=PSw21A5KC5m/1/HnloF0W DPNaZsB1FcUePbrLReXIlCuuNOpkFp7VzmVNY7zriHGPqch6G4dY1oJ9E/LFuUcR mFOIGpJBQ7TIqmsDzOWNP+nUhpCKEGYYLw6x9UouzgBJFZjcJwZYH+fjeV+sHGD1 i9p1SZPQt7bdmPMHIT7g8w= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=/AL9PKu9oA7bpMx28t6N ac1SoXs=; b=ULsCV+HmTbKqmb/fJhVNZwXzzG4ISqRYwpo8kARZ+J12w7utm+3i JVoak/HKaQJpiVA7tYoO6A1GpeqNJSlqWCSRYQQYW23mWSnNVfyu33mrSnNWXSd4 vidE5+3Obyq6alnlMU/QXFaEuASlQD696mYj4BLqIH8v53FsgZtteR0= Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a98.g.dreamhost.com (Postfix) with ESMTPSA id 06B732C2058 for ; Tue, 13 Mar 2012 22:40:51 -0700 (PDT) Received: by dald2 with SMTP id d2so3010289dal.27 for ; Tue, 13 Mar 2012 22:40:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.132.40 with SMTP id or8mr1876725pbb.34.1331703651544; Tue, 13 Mar 2012 22:40:51 -0700 (PDT) Received: by 10.68.28.6 with HTTP; Tue, 13 Mar 2012 22:40:51 -0700 (PDT) In-Reply-To: References: <4F5ADDCA.80303@KingsMountain.com> Date: Wed, 14 Mar 2012 00:40:51 -0500 Message-ID: From: Nico Williams To: Walter Content-Type: text/plain; charset=UTF-8 Cc: Apps Discuss Subject: Re: [apps-discuss] Proposal for a Finance Area Mailing List X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 14 Mar 2012 05:40:53 -0000 On Sat, Mar 10, 2012 at 6:22 AM, Walter wrote: >> All of the above are application-specific, and can be conveyed IMHO over >> existing specified protocols. > > That's true. However, taking that view purely you could similarly > argue that almost everything is out of IETF scope because IPv4, TCP > and UDP exist. Indeed, XMPP, for example, and many other protocols that are application-specific are standardized here are standardized here. I think the questions regarding whether to standardize financial protocols here or not will be the same as with other application protocols (and sub-IP protocols, for that matter). Maybe someone more familiar with past debates on similar issues can give us some background. I suspect it will all come down to: how many participants are willing to work on this, how many are willing to review, whether there is any running code, whether the wider community can be of help, and so on. We should at least consider it. My fear is that there isn't enough financial clue at the IETF to help the proponents, but then, that probably could have been said about the media protocols too. Nico -- From paulej@packetizer.com Tue Mar 13 22:56:41 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65C4621F85D3 for ; Tue, 13 Mar 2012 22:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ST+fMR9NaL7N for ; Tue, 13 Mar 2012 22:56:40 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id D72DE21F85D1 for ; Tue, 13 Mar 2012 22:56:39 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q2E5ucqa026953 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 14 Mar 2012 01:56:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1331704598; bh=AVI6du+Zel6XM7nuGZbQxZ3MYwwuNQVmT3WAj1V45gs=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; b=fi6Usk+b8yn2NUvqNkyqp7Ria+yELKAbb3o75fgj2OmdJ0ZZnXSf4H88k/alngKgy 5rBAXFTYW5vjUPWEWbRwV9i+0ETrlowOKcGg6eIH5AlLok/KKi/2d9Qvk1xYiLtFUW Tj3qMFSH0elm17N5xUqlFk0V093qTpasY1WFSPC0= From: "Paul E. Jones" To: , Date: Wed, 14 Mar 2012 01:56:44 -0400 Message-ID: <05d001cd01a7$3cbb0c70$b6312550$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_05D1_01CD0185.B5A96C70" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac0BpQFPzAZiU0kpTmqy3YhO+8RyEw== Content-Language: en-us Subject: [apps-discuss] Webfinger: acct "link relation" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 14 Mar 2012 05:56:41 -0000 This is a multipart message in MIME format. ------=_NextPart_000_05D1_01CD0185.B5A96C70 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Folks, In the latest Webfinger draft, we introduced a "acct" link relation named "acct" (see Section 6). The intent with that link relation was to allow for one to inform a webfinger client that a user's account information may be retrieved elsewhere. I believe this will be important, since a user might have more than one account and this might serve as a means of associating them. Certainly, it would be a way of retrieving information from those other accounts automatically. Perhaps calling the new link relation "acct" is too restrictive, though. If one used Webfinger to query other kinds of information other than a user's account, there may still be a need/desire to refer the Webfinger client to other resources. What do you think about changing this section such that the link relation is renamed to "seealso"? This would still be useful when querying an acct URI, but would also be useful when querying any URI since it is more generic. Do note that "seealso" would be different than the "alternate" link relation. It would not refer to alternative information, but would refer to supplemental information. In practice, the supplemental information may be the more informative since the bulk of the information related to a user might be held under a different account. Your thoughts? Paul ------=_NextPart_000_05D1_01CD0185.B5A96C70 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Folks,

 

In the = latest Webfinger draft, we introduced a “acct” link relation = named “acct” (see Section 6).  The intent with that = link relation was to allow for one to inform a webfinger client that a = user’s account information may be retrieved elsewhere.  I = believe this will be important, since a user might have more than one = account and this might serve as a means of associating them.  = Certainly, it would be a way of retrieving information from those other = accounts automatically.

 

Perhaps = calling the new link relation “acct” is too restrictive, = though.  If one used Webfinger to query other kinds of information = other than a user’s account, there may still be a need/desire to = refer the Webfinger client to other resources.

 

What do you = think about changing this section such that the link relation is renamed = to “seealso”?  This would still be useful when querying = an acct URI, but would also be useful when querying any URI since = it  is more generic.

 

Do note that = “seealso” would be different than the = “alternate” link relation.  It would not refer to = alternative information, but would refer to supplemental = information.  In practice, the supplemental information may be the = more informative since the bulk of the information related to a user = might be held under a different account.

 

Your = thoughts?

 

Paul

 

 

 

------=_NextPart_000_05D1_01CD0185.B5A96C70-- From walter.stanish@gmail.com Wed Mar 14 02:21:59 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C78C21F8707 for ; Wed, 14 Mar 2012 02:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[AWL=-1.536, BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_FWDLOOK=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZAcjUmPpPAlR for ; Wed, 14 Mar 2012 02:21:58 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 37B8521F871B for ; Wed, 14 Mar 2012 02:21:57 -0700 (PDT) Received: by ggmi1 with SMTP id i1so1778571ggm.31 for ; Wed, 14 Mar 2012 02:21:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=n9sM075L5RJ4zHdZ1oKbjdzBOi5YUwVKb+xvkNQIy1Y=; b=uJjB45wrzNC1/YhtiG0c7AOSFpTt4svuUISNK5XsDiBcV6KCFts5EkVFN++NWpR1OW MOKmeoJKZ/w3i5zCqw9lmrPJ7qvzm5QKZYp0DfPNF2P5oXh9YGS2zb85S/moQ9mVi43i rN3orN8v5rK4l6sWY+dNUfEmerp/j2Qg+NvlXQOdzNccuyYE0HMiKWEl9nAutahB5IJe nQqTDw2bBi1QIiGiOqtkZ87C+l+7joXv9BNNE0IGCLTeNA9PyknMvAWNkzDQpvgVoq4T 2vvqRgkHRcNKoN2cBuu8pUn6wzCxLEX+4GzS/HPw3HuFzaWTSIp4nP5SJil2Q7LQlDc2 jq9A== MIME-Version: 1.0 Received: by 10.182.51.73 with SMTP id i9mr2227392obo.17.1331716916683; Wed, 14 Mar 2012 02:21:56 -0700 (PDT) Received: by 10.60.149.225 with HTTP; Wed, 14 Mar 2012 02:21:56 -0700 (PDT) In-Reply-To: References: <4F5ADDCA.80303@KingsMountain.com> Date: Wed, 14 Mar 2012 16:21:56 +0700 Message-ID: From: Walter To: Nico Williams Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Apps Discuss Subject: Re: [apps-discuss] Proposal for a Finance Area Mailing List X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 14 Mar 2012 09:22:00 -0000 >>> All of the above are application-specific, and can be conveyed IMHO ove= r >>> existing specified protocols. >> >> That's true. However, taking that view purely you could similarly >> argue that almost everything is out of IETF scope because IPv4, TCP >> and UDP exist. > > Indeed, XMPP, for example, and many other protocols that are > application-specific are standardized here are standardized here. Sincere thanks for taking the time to reply. In case there's an audience still out there in the distinctly echoey (echoey...) halls of this thread, I have tried to address the valid points you raised below. > I think the questions regarding whether to standardize financial > protocols here or not will be the same as with other application > protocols (and sub-IP protocols, for that matter). =A0Maybe someone more > familiar with past debates on similar issues can give us some > background. As a student and aspiring author of history myself, I do not in any way wish to dissuade valuable historic inquiry, but this does seem a tad tangential in light of the apparent existence of formalized statements regarding the IETF's role and process. (That is, unless the IETF has somehow descended in to the dark and near unnavigable realm of ... "case law".*) * Possible theme for a future roguelike? "You prize open the case law archive. Mouldy remnants of past inquiry flap woefully in the millennial breeze. The stench of legal aid skeletons and ancient coffee emanates up from what must once have been a cheaply carpeted floor." > I suspect it will all come down to: how many participants > are willing to work on this, While we really do need the forum before collecting participants, we can probably safely assume at least a smattering of mutual credit communities, plus Bitcoin and other digital currency people, possibly some financially oriented software vendors, some techier market and banking people, etc. Maybe some big name companies - 'social' and so forth - who are basically moving in to private currency accounting. Such people are actually around (we have been in touch with quite a few), it's just that many will need a neutral, focused forum to congregate on definable problems before coming out of the woodwork for procedural reasons. > how many are willing to review, Not to run before we walk ... I think gathering people to discuss the perceived needs of individual community segments and come up with some ideas for shared solutions (that do not sacrifice interoperability) is the immediate task; latter issues of formal review MAY follow. > whether > there is any running code, As above. In addition, running code has already been deemed "a tad excessive" earlier on this thread: http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04519.html > whether the wider community can be of help, Certainly there are multiple parties identified who have worked in this direction in the past (see http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04511.html) and multiple parties who are working in this direction at present, though exclusively with narrower scope: - Ripple: http://ripple-project.org/Protocol/Protocol - CES (private communication, 2012): http://ces.org.za/ - W3C Web Payments Community Group: http://www.w3.org/community/webpayment= s/ One might add to this short list the tremendous number of financial services providers (both established and innovative) who currently consistently present their customers with custom protocols or APIs (XML, REST, SOAP, JSON RPC, HTTP; often with unique complex event callback and/or state-based polling mechanisms; the same based on weird VPNs, leased lines, client certificate SSL systems for security box-ticking purposes, etc.) even for extremely well trodden settlement problems (credit cards come to mind, as do mobile operators opening their consumer billing platforms to payment integration, B2B banking portals offered by leading banks, etc.). Each of these entities, their vendors and clients would likely testify to present pains of implementation: indeed, huge numbers of libraries and software modules exist purely for specific-vendor-X API integration purposes (few of which are created - shall we say - equal, particularly in view of tax, fee, anti-fraud, accounting, auditing and other related concerns that often slip out of view during small scale/minimalist integrations). As for how many might choose to actively contribute, that would be a forward looking statement. Some will. In short, there's a huge amount of experience out there in the community to potentially focus on cost-saving, flexibility enhancing standardization. People are motivated, they get it. They've done Euro, they've done taxes, they've done regulatory change, they've done protocol upgrades, they've done vendor lock in, they're looking in to mobile, they're seeing digital currencies. People want an interface that works, and doesn't need to be thrown out and re-implemented periodically. The "wider community" in the non-IETF sense can thus be relied upon to help, though which quarters specifically will step forward we will only know in time. In the IETF-internal sense of "wider community", when any potential for formalization of output approaches in the future, I'm sure people will volunteer. But we will need a mailing list. > and so on. =A0We should at least consider it. =A0My fear is that there > isn't enough financial clue at the IETF to help the proponents, but > then, that probably could have been said about the media protocols > too. Glad to see we're not on entirely new ground here. While unfamiliar with the IETF's media protocols history, this seems rather chicken and egg to me as affiliation with the IETF seems* to be largely based on mailing list participation. Once formalization arises, surely any knowledge or assistance required of existing IETF participants (without necessitating broad finance domain expertise) could be teased out of some quarter or other... * "There is no membership in the IETF. Anyone may register for and attend any meeting. The closest thing there is to being an IETF member is being on the IETF or Working Group mailing lists". http://www.ietf.org/tao.html Thanks again for your valuable feedback. Regards, Walter Stanish Payward, Inc. From sebastian.kaebisch.ext@siemens.com Wed Mar 14 02:51:08 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE86921F8574 for ; Wed, 14 Mar 2012 02:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.166 X-Spam-Level: X-Spam-Status: No, score=-9.166 tagged_above=-999 required=5 tests=[AWL=-1.083, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s8OdsiTthGlZ for ; Wed, 14 Mar 2012 02:51:08 -0700 (PDT) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by ietfa.amsl.com (Postfix) with ESMTP id EA79A21F8566 for ; Wed, 14 Mar 2012 02:51:07 -0700 (PDT) Received: from mail3.siemens.de (localhost [127.0.0.1]) by david.siemens.de (8.13.6/8.13.6) with ESMTP id q2E9p55p009907; Wed, 14 Mar 2012 10:51:05 +0100 Received: from DEMCHP99ET1MSX.ww902.siemens.net (demchp99et1msx.ww902.siemens.net [139.25.131.180]) by mail3.siemens.de (8.13.6/8.13.6) with ESMTP id q2E9p3EF031513 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Wed, 14 Mar 2012 10:51:05 +0100 Received: from DEMCHP99E55MSX.ww902.siemens.net ([169.254.2.75]) by DEMCHP99ET1MSX.ww902.siemens.net ([139.25.131.180]) with mapi; Wed, 14 Mar 2012 10:50:58 +0100 From: "Kaebisch, Sebastian" To: Yusuke DOI Date: Wed, 14 Mar 2012 10:50:57 +0100 Thread-Topic: [apps-discuss] SenML Thread-Index: Acz+HC0RMmoGe7GERxGeL1x16rBa7gDp0Cgg Message-ID: <1CE2FB42E90B614C98BC172FAB12D4C002D5098E63@DEMCHP99E55MSX.ww902.siemens.net> References: <1CE2FB42E90B614C98BC172FAB12D4C002D3FCFF8A@DEMCHP99E55MSX.ww902.siemens.net> <52B10DF8-11D1-44FE-8A8B-184BB0AE12F2@sensinode.com> <1CE2FB42E90B614C98BC172FAB12D4C002D50989C3@DEMCHP99E55MSX.ww902.siemens.net> <201203091742.q29HglnN008664@toshiba.co.jp> In-Reply-To: <201203091742.q29HglnN008664@toshiba.co.jp> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] SenML X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 14 Mar 2012 09:51:08 -0000 Dear Yusuke, thank you for your mail. > > 2) instead of using a "float" value, I would recommend to use the > "mantissa" and "exponend" representation. A floating value is always a > challenge for constrained devices because of its inefficent processing. >=20 > I think float values in EXI is already mantissa and exponend (base 10). That's right, however, EXI has to convert the float value into the mantissa= and exponent representation (encoding) and vice versa (decoding) respectiv= ely. This processing overhead can be avoided if we working already on data = model level only with the mantissa and exponent representation. > > 3) use restriction definitions of strings (define maxLength or list all > possible values as enumeration). Especially using enumerations results in > a smaller message size and avoids string comparison. >=20 > Enumeration is good idea but I think strict enumeration allows no > addition in future without breaking backword compatibility. I recommend > some 'dummy entries' to make room (and show the limit to keep the same > bitwidth clearly) for future. >=20 If there a need of flexibility, then we should do that. In my understanding= , the unit symbol table in 10.1 will be standardized and will be fixed then= .=20 Best regards Sebastian K=E4bisch From zach@sensinode.com Wed Mar 14 02:56:46 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7742F21F8721 for ; Wed, 14 Mar 2012 02:56:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QUBSsins95tC for ; Wed, 14 Mar 2012 02:56:45 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 1EB9F21F8703 for ; Wed, 14 Mar 2012 02:56:44 -0700 (PDT) Received: from [192.168.1.101] (87-93-15-88.bb.dnainternet.fi [87.93.15.88]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q2E9ucaG021356; Wed, 14 Mar 2012 11:56:40 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <1CE2FB42E90B614C98BC172FAB12D4C002D5098E63@DEMCHP99E55MSX.ww902.siemens.net> Date: Wed, 14 Mar 2012 11:56:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1CE2FB42E90B614C98BC172FAB12D4C002D3FCFF8A@DEMCHP99E55MSX.ww902.siemens.net> <52B10DF8-11D1-44FE-8A8B-184BB0AE12F2@sensinode.com> <1CE2FB42E90B614C98BC172FAB12D4C002D50989C3@DEMCHP99E55MSX.ww902.siemens.net> <201203091742.q29HglnN008664@toshiba.co.jp> <1CE2FB42E90B614C98BC172FAB12D4C002D5098E63@DEMCHP99E55MSX.ww902.siemens.net> To: "Kaebisch, Sebastian" X-Mailer: Apple Mail (2.1084) Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] SenML X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 14 Mar 2012 09:56:46 -0000 On Mar 14, 2012, at 11:50 AM, Kaebisch, Sebastian wrote: >>>=20 >>> 3) use restriction definitions of strings (define maxLength or list = all >> possible values as enumeration). Especially using enumerations = results in >> a smaller message size and avoids string comparison. >>=20 >> Enumeration is good idea but I think strict enumeration allows no >> addition in future without breaking backword compatibility. I = recommend >> some 'dummy entries' to make room (and show the limit to keep the = same >> bitwidth clearly) for future. >>=20 >=20 > If there a need of flexibility, then we should do that. In my = understanding, the unit symbol table in 10.1 will be standardized and = will be fixed then.=20 The unit representation part of the SenML draft is the last thing that = is an open issue to fix actually. The value will need to be open-ended = as even in the current form this would need to be an IANA registry and = thus new values would be added over time. However, we are looking at a = model where external unit references can be made instead of trying to = standardize a list of units in the IETF. For now at least we should = leave this as a string. Let's look at it again when the unit model has = been updated in the draft. Zach --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From dromasca@avaya.com Wed Mar 14 03:53:10 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EAE221E8036; Wed, 14 Mar 2012 03:53:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.367 X-Spam-Level: X-Spam-Status: No, score=-103.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hfZ-Jb-ZAyYC; Wed, 14 Mar 2012 03:53:09 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 0281A21E8026; Wed, 14 Mar 2012 03:53:08 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAEJ3YE/GmAcF/2dsb2JhbABDthmBB4IJAQEBAQIBEgYYCj8FBwQCAQgNCA0GDAsBBgFFEQEBBAESCBqHYwWgAJwkkBVjBJtjihmCZw X-IronPort-AV: E=Sophos;i="4.73,583,1325480400"; d="scan'208";a="297063911" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 14 Mar 2012 06:52:58 -0400 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 14 Mar 2012 06:45:03 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 14 Mar 2012 11:52:56 +0100 Message-ID: In-Reply-To: <6.2.5.6.2.20120313162357.0a0e5350@elandnews.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [apps-discuss] APPSDIR review ofdraft-ietf-opsawg-management-stds-05 Thread-Index: Ac0BcPWBoWeyOaiCSH+zI4qt0Z5NdAAXoEkQ References: <6.2.5.6.2.20120313162357.0a0e5350@elandnews.com> From: "Romascanu, Dan (Dan)" To: "Lisa Dusseault" , Cc: draft-ietf-opsawg-management-stds.all@tools.ietf.org, opsawg@ietf.org, iesg@ietf.org Subject: Re: [apps-discuss] APPSDIR review ofdraft-ietf-opsawg-management-stds-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 14 Mar 2012 10:53:10 -0000 Hi Lisa, Thank you for your review.=20 Please allow me to respond to one of your comments.=20 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > bounces@ietf.org] On Behalf Of Lisa Dusseault > The goal of this document sounds great, and it seems there is some > need for a survey or overview of network management standards. Some > sections achieve the document's goals with concise, clear summaries > and pointers to outside work. Other sections of the document suffer > from meaningless (e.g. circular or jargon-laden) summaries and awkward > explanations, but at least the pointers will still be useful. I have > some concerns about whether the document is comprehensive, because a > survey is most useful when it really points to all the prior and > relevant work at least in brief. >=20 > While I am not in a position to notice all the places where the > document may have holes in its comprehensiveness, I did note that > currently active work was not consistently covered. The document does > not mention or refer to ARMD, BMWG or benchmarking, GROW or BGP > Monitoring. I do not know which of these Ops area WGs are important > or actively making progress, but to an Ops outsider they all seem > relevant. It's not as if the document does not cover active work: the > document goes into some detail explaining not only the purpose of > energy management work going on in the IETF but also some of the > challenges of that work (appendix B). Missing other active WGs' > topics seems odd. >=20 [[DR]] As you probably know well the OPS Area activities covers Operations and Management. The scope of this document is as you correctly point providing an overview of network management standards. The WGs you mention - ARMD, BMWG, GROW - belong all to the operational part of the area, none develops network management standards (protocols or data models). BGP monitoring is realized via a number of means, two of them are mentioned in the document (the data model in RFC 4273 in section 4.1.3 and the IPFIX IEs in section 4.2.3).=20 Regards, Dan =20 From laurentwalter.goix@telecomitalia.it Wed Mar 14 04:19:29 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ECF421F86EB for ; Wed, 14 Mar 2012 04:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.039 X-Spam-Level: X-Spam-Status: No, score=-0.039 tagged_above=-999 required=5 tests=[AWL=-1.180, BAYES_20=-0.74, EXTRA_MPART_TYPE=1, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kyAH+ehpQbph for ; Wed, 14 Mar 2012 04:19:26 -0700 (PDT) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by ietfa.amsl.com (Postfix) with ESMTP id 2D2D321F8636 for ; Wed, 14 Mar 2012 04:19:26 -0700 (PDT) Received: from grfhub704ba020.griffon.local (10.188.101.117) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 14 Mar 2012 12:19:13 +0100 Received: from GRFMBX704BA020.griffon.local ([10.188.101.16]) by grfhub704ba020.griffon.local ([10.188.101.117]) with mapi; Wed, 14 Mar 2012 12:19:12 +0100 From: Goix Laurent Walter To: "Paul E. Jones" , "apps-discuss@ietf.org" , "webfinger@googlegroups.com" Date: Wed, 14 Mar 2012 12:19:11 +0100 Thread-Topic: [apps-discuss] Webfinger: acct "link relation" Thread-Index: Ac0BpQFPzAZiU0kpTmqy3YhO+8RyEwALlNNg Message-ID: References: <05d001cd01a7$3cbb0c70$b6312550$@packetizer.com> In-Reply-To: <05d001cd01a7$3cbb0c70$b6312550$@packetizer.com> Accept-Language: en-US Content-Language: it-IT X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US x-ti-disclaimer: Disclaimer1 Content-Type: multipart/related; boundary="_004_A09A9E0A4B9C654E8672D1DC003633AE52EDA3023DGRFMBX704BA02_"; type="multipart/alternative" MIME-Version: 1.0 Subject: [apps-discuss] R: Webfinger: acct "link relation" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 14 Mar 2012 11:19:29 -0000 --_004_A09A9E0A4B9C654E8672D1DC003633AE52EDA3023DGRFMBX704BA02_ Content-Type: multipart/alternative; boundary="_000_A09A9E0A4B9C654E8672D1DC003633AE52EDA3023DGRFMBX704BA02_" --_000_A09A9E0A4B9C654E8672D1DC003633AE52EDA3023DGRFMBX704BA02_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Well, generalizing could be a more flexible approach. Especially if uri sch= emes evolve over time to identify users (could be http, tel, etc). I guess = the semantics here is o refer to yet another identity of that individual. "seealso" may fit, although it is quite vague semantically and do not speci= fically ensure that the specific resource is actually the same individual b= ut another account. The "related" relation link (defined in atom [1] ) may also fit and has mor= e or less the same meaning whilst being already formally assigned. In alternative one could borrow from xfn concepts [2] and use "me" to clear= ly state that this resource is another pointer to "myself"... Just my 2 cents to stimulate the discussion here walter [1] http://tools.ietf.org/html/rfc4287#section-4.2.7.2 [2] http://gmpg.org/xfn/11 Da: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] Pe= r conto di Paul E. Jones Inviato: mercoled=EC 14 marzo 2012 6.57 A: apps-discuss@ietf.org; webfinger@googlegroups.com Oggetto: [apps-discuss] Webfinger: acct "link relation" Folks, In the latest Webfinger draft, we introduced a "acct" link relation named "= acct" (see Section 6). The intent with that link relation was to allow for= one to inform a webfinger client that a user's account information may be = retrieved elsewhere. I believe this will be important, since a user might = have more than one account and this might serve as a means of associating t= hem. Certainly, it would be a way of retrieving information from those oth= er accounts automatically. Perhaps calling the new link relation "acct" is too restrictive, though. I= f one used Webfinger to query other kinds of information other than a user'= s account, there may still be a need/desire to refer the Webfinger client t= o other resources. What do you think about changing this section such that the link relation i= s renamed to "seealso"? This would still be useful when querying an acct U= RI, but would also be useful when querying any URI since it is more generi= c. Do note that "seealso" would be different than the "alternate" link relatio= n. It would not refer to alternative information, but would refer to suppl= emental information. In practice, the supplemental information may be the = more informative since the bulk of the information related to a user might = be held under a different account. Your thoughts? Paul Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. [cid:00000000000000000000000000000003@TI.Disclaimer]Rispetta l'ambiente. No= n stampare questa mail se non =E8 necessario. --_000_A09A9E0A4B9C654E8672D1DC003633AE52EDA3023DGRFMBX704BA02_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Well, g= eneralizing could be a more flexible approach. Especially if uri schemes ev= olve over time to identify users (could be http, tel, etc). I guess the sem= antics here is o refer to yet another identity of that individual.

&n= bsp;

“= seealso” may fit, although it is quite vague semantically and do not = specifically ensure that the specific resource is actually the same individ= ual but another account.

&n= bsp;

The = 220;related” relation link (defined in atom [1] ) may also fit and ha= s more or less the same meaning whilst being already formally assigned.

In alte= rnative one could borrow from xfn concepts [2] and use “me” to = clearly state that this resource is another pointer to “myself”= …

&n= bsp;

Just my= 2 cents to stimulate the discussion here

walter<= o:p>

&n= bsp;

[1] http://tools.ietf.org/h= tml/rfc4287#section-4.2.7.2

[2] htt= p://gmpg.org/xfn/11

Da: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounce= s@ietf.org] Per conto di Paul E. Jones
Inviato: mercoled=EC 14 marzo 2012 6.57
A: apps-discuss@ietf.org; webfinger@googlegroups.com
Oggetto: [apps-discuss] Webfinger: acct "link relation"

 

Folks,

 

In the latest Webfinger draft, = we introduced a “acct” link relation named “acct” (= see Section 6).  The intent with that link relation was to allow for o= ne to inform a webfinger client that a user’s account information may be retrieved elsewhere.  I believe this will be important, since = a user might have more than one account and this might serve as a means of = associating them.  Certainly, it would be a way of retrieving informat= ion from those other accounts automatically.

 

Perhaps calling the new link re= lation “acct” is too restrictive, though.  If one used Web= finger to query other kinds of information other than a user’s accoun= t, there may still be a need/desire to refer the Webfinger client to other resources.

 

What do you think about changin= g this section such that the link relation is renamed to “seealsoR= 21;?  This would still be useful when querying an acct URI, but would = also be useful when querying any URI since it  is more generic.

 

Do note that “seealsoR= 21; would be different than the “alternate” link relation. = ; It would not refer to alternative information, but would refer to supplem= ental information.  In practice, the supplemental information may be the more informative since the bulk of the information related to a use= r might be held under a different account.

 

Your thoughts?

 

Paul

 

 

 

= Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigoro= samente vietate. Qualora abbiate ricevuto questo documento per errore siete= cortesemente pregati di darne immediata comunicazione al mittente e di pro= vvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only.= Dissemination, copying, printing or use by anybody else is unauthorised. I= f you are not the intended recipient, please delete this message and any at= tachments and advise the sender by return e-mail, Thanks.

3D"rispettaRispetta= l'ambiente. Non stampare questa mail se non =E8 necessario.

--_000_A09A9E0A4B9C654E8672D1DC003633AE52EDA3023DGRFMBX704BA02_-- --_004_A09A9E0A4B9C654E8672D1DC003633AE52EDA3023DGRFMBX704BA02_ Content-Type: image/jpeg; name="logo Ambiente_foglia2.jpg" Content-Description: logo Ambiente_foglia2.jpg Content-Disposition: inline; filename="logo Ambiente_foglia2.jpg"; size=677; creation-date="Wed, 14 Mar 2012 12:19:12 GMT"; modification-date="Wed, 14 Mar 2012 12:19:12 GMT" Content-ID: <00000000000000000000000000000003@TI.Disclaimer> Content-Transfer-Encoding: base64 R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= --_004_A09A9E0A4B9C654E8672D1DC003633AE52EDA3023DGRFMBX704BA02_-- From stpeter@stpeter.im Wed Mar 14 06:01:06 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8A0F21F874C for ; Wed, 14 Mar 2012 06:01:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.76 X-Spam-Level: X-Spam-Status: No, score=-101.76 tagged_above=-999 required=5 tests=[AWL=-0.827, BAYES_00=-2.599, SARE_FWDLOOK=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kzFi1JODJkLe for ; Wed, 14 Mar 2012 06:01:05 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B43A021F874A for ; Wed, 14 Mar 2012 06:01:05 -0700 (PDT) Received: from squire.local (unknown [216.17.175.160]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 583EE40058; Wed, 14 Mar 2012 07:13:24 -0600 (MDT) Message-ID: <4F60968D.4020703@stpeter.im> Date: Wed, 14 Mar 2012 07:01:01 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Walter References: <4F5ADDCA.80303@KingsMountain.com> In-Reply-To: X-Enigmail-Version: 1.3.5 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Apps Discuss Subject: Re: [apps-discuss] Proposal for a Finance Area Mailing List X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 14 Mar 2012 13:01:07 -0000 On 3/14/12 3:21 AM, Walter wrote: >>>> All of the above are application-specific, and can be conveyed IMHO over >>>> existing specified protocols. >>> >>> That's true. However, taking that view purely you could similarly >>> argue that almost everything is out of IETF scope because IPv4, TCP >>> and UDP exist. >> >> Indeed, XMPP, for example, and many other protocols that are >> application-specific are standardized here are standardized here. > > Sincere thanks for taking the time to reply. In case there's an > audience still out there in the distinctly echoey (echoey...) halls of > this thread, I have tried to address the valid points you raised > below. > >> I think the questions regarding whether to standardize financial >> protocols here or not will be the same as with other application >> protocols (and sub-IP protocols, for that matter). Maybe someone more >> familiar with past debates on similar issues can give us some >> background. > > As a student and aspiring author of history myself, I do not in any > way wish to dissuade valuable historic inquiry, but this does seem a > tad tangential in light of the apparent existence of formalized > statements regarding the IETF's role and process. (That is, unless the > IETF has somehow descended in to the dark and near unnavigable realm > of ... "case law".*) > > * Possible theme for a future roguelike? "You prize open the case law > archive. Mouldy remnants of past inquiry flap woefully in the > millennial breeze. The stench of legal aid skeletons and ancient > coffee emanates up from what must once have been a cheaply carpeted > floor." > >> I suspect it will all come down to: how many participants >> are willing to work on this, > > While we really do need the forum before collecting participants, we > can probably safely assume at least a smattering of mutual credit > communities, plus Bitcoin and other digital currency people, possibly > some financially oriented software vendors, some techier market and > banking people, etc. Maybe some big name companies - 'social' and so > forth - who are basically moving in to private currency accounting. > Such people are actually around (we have been in touch with quite a > few), it's just that many will need a neutral, focused forum to > congregate on definable problems before coming out of the woodwork for > procedural reasons. > >> how many are willing to review, > > Not to run before we walk ... I think gathering people to discuss the > perceived needs of individual community segments and come up with some > ideas for shared solutions (that do not sacrifice interoperability) is > the immediate task; latter issues of formal review MAY follow. > >> whether >> there is any running code, > > As above. In addition, running code has already been deemed "a tad > excessive" earlier on this thread: > http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04519.html > >> whether the wider community can be of help, > > Certainly there are multiple parties identified who have worked in > this direction in the past (see > http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04511.html) > and multiple parties who are working in this direction at present, > though exclusively with narrower scope: > - Ripple: http://ripple-project.org/Protocol/Protocol > - CES (private communication, 2012): http://ces.org.za/ > - W3C Web Payments Community Group: http://www.w3.org/community/webpayments/ > > One might add to this short list the tremendous number of financial > services providers (both established and innovative) who currently > consistently present their customers with custom protocols or APIs > (XML, REST, SOAP, JSON RPC, HTTP; often with unique complex event > callback and/or state-based polling mechanisms; the same based on > weird VPNs, leased lines, client certificate SSL systems for security > box-ticking purposes, etc.) even for extremely well trodden settlement > problems (credit cards come to mind, as do mobile operators opening > their consumer billing platforms to payment integration, B2B banking > portals offered by leading banks, etc.). > > Each of these entities, their vendors and clients would likely testify > to present pains of implementation: indeed, huge numbers of libraries > and software modules exist purely for specific-vendor-X API > integration purposes (few of which are created - shall we say - equal, > particularly in view of tax, fee, anti-fraud, accounting, auditing and > other related concerns that often slip out of view during small > scale/minimalist integrations). > > As for how many might choose to actively contribute, that would be a > forward looking statement. Some will. > > In short, there's a huge amount of experience out there in the > community to potentially focus on cost-saving, flexibility enhancing > standardization. People are motivated, they get it. They've done > Euro, they've done taxes, they've done regulatory change, they've done > protocol upgrades, they've done vendor lock in, they're looking in to > mobile, they're seeing digital currencies. People want an interface > that works, and doesn't need to be thrown out and re-implemented > periodically. The "wider community" in the non-IETF sense can thus be > relied upon to help, though which quarters specifically will step > forward we will only know in time. In the IETF-internal sense of > "wider community", when any potential for formalization of output > approaches in the future, I'm sure people will volunteer. > > But we will need a mailing list. Actually, you don't *need* an *IETF* mailing list to discuss financial application protocols. I would like to note that I remain skeptical that there truly is a community here, that there is a tractable engineering problem to be solved, that the IETF is necessarily the right place to do work on engineering solutions even if there is a tractable problem, or that the proponent (I have yet to see more than one) has taken account of previous work in this space at the IETF and why that work has not been a wild success. Notwithstanding, as an area director for the applications area (at least for a few more weeks) and in consultation with Pete and Barry, I am willing to create a list and see if a more concrete initiative gels here. If list discussion doesn't lead anywhere, it will be easy enough to close the list. Walter, please provide the following information: 1. List name (please don't make it "finance" because people might think it is an IAOC list) 2. List administrator email address(es) 3. Purpose (a *brief* description, see http://www.ietf.org/list/nonwg.html for examples) Thanks. Peter -- Peter Saint-Andre https://stpeter.im/ From barryleiba@gmail.com Wed Mar 14 06:11:24 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 840F021F8792; Wed, 14 Mar 2012 06:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.984 X-Spam-Level: X-Spam-Status: No, score=-102.984 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ly6OHYgdTCFM; Wed, 14 Mar 2012 06:11:24 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id DC7CE21F8703; Wed, 14 Mar 2012 06:11:23 -0700 (PDT) Received: by yhpp34 with SMTP id p34so2047070yhp.31 for ; Wed, 14 Mar 2012 06:11:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=lDJSAQQDbrHtefz3FghisBH/mjqw6BuiuPXCyGI4Ym4=; b=X7j9HxExPW4Lo5aYI6iQXQvjtZtqsl9+RqOObYgN0zm174ce3Sr1PnzFYIZjQjN4p8 S/Y02itF7qwuXK6J4pzV0KHg+IKuFzqCnVbjQ6Xowoji4XOGj7vclM9sonPeyI2qDL1A sC3rvgsw2+za75O9/c/Etd6yOtYkgw4cCuM6W03HzfAduW+wHT+gOsEIWsL5sxErGIQy rBcXYI/o2+h4xweM8vc2/KDVMjqX1I0aElL3KyYVDG3+jRTFVLhnkC/xqvy4PeX1hDdo VAR90XrNpxCTaRcY+7+H1a9sQQli0+CiwLa2b+83F02VxSugHwlUt2KEKPL/tASpHvMB inJw== MIME-Version: 1.0 Received: by 10.60.18.163 with SMTP id x3mr3010287oed.64.1331730683448; Wed, 14 Mar 2012 06:11:23 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.60.125.37 with HTTP; Wed, 14 Mar 2012 06:11:23 -0700 (PDT) In-Reply-To: <3722383.WlunSX8BHo@scott-latitude-e6320> References: <1344986.gzdu38iGHL@scott-latitude-e6320> <3722383.WlunSX8BHo@scott-latitude-e6320> Date: Wed, 14 Mar 2012 09:11:23 -0400 X-Google-Sender-Auth: kGtBqgGYFEkgXfegmojEwPtJSvI Message-ID: From: Barry Leiba To: "iesg@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org, "draft-ietf-marf-spf-reporting@tools.ietf.org" Subject: Re: [apps-discuss] Review of draft-marf-spf-reporting-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 14 Mar 2012 13:11:24 -0000 >> If the consensus is that you cannot wait ... my point is that given the = IESG >> note in RFC 4408, it is not appropriate to make this standards track >> without an indication of the fact that RFC 4408 is being revised/elevate= d >> to standards track. =A0Now that note could be another IESG note... > > The downref was discussed in the working group, there was consensus to > proceed, and it was specifically noted in the last call announcement. =A0= AIUI, > that's all that's required from a process perspective. > > On a practical basis, there is no chance that the changes proposed for SP= Fbis > would affect the content of this draft. =A0It would be well outside the s= cope of > the charter. I'll note this: 1. Glenn has made his view on downgrading this doc to Experimental clear, and it is a sensible suggestion. 2. Scott has noted that the working group did discuss this point, and decided on Standards Track. 3. The IESG thus has input on the matter, and will ultimately decide whether to make it PS or Experimental. Others, whom we've not yet heard from, may certainly add their opinions and reasoning. But there's not much value to further discussing it among those who've already spoken. Barry From yusuke.doi@toshiba.co.jp Wed Mar 14 06:35:52 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A824521F8705 for ; Wed, 14 Mar 2012 06:35:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.924 X-Spam-Level: X-Spam-Status: No, score=-5.924 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w2Yr8xt0cVXG for ; Wed, 14 Mar 2012 06:35:52 -0700 (PDT) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by ietfa.amsl.com (Postfix) with ESMTP id 01CAB21F8625 for ; Wed, 14 Mar 2012 06:35:51 -0700 (PDT) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id q2EDZppt027109 for ; Wed, 14 Mar 2012 22:35:51 +0900 (JST) Received: (from root@localhost) by arc11.toshiba.co.jp id q2EDZon1002453 for apps-discuss@ietf.org; Wed, 14 Mar 2012 22:35:50 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id YAA02452; Wed, 14 Mar 2012 22:35:50 +0900 Received: from mx12.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id q2EDZonC001239 for ; Wed, 14 Mar 2012 22:35:50 +0900 (JST) Received: by toshiba.co.jp id q2EDZokH026005; Wed, 14 Mar 2012 22:35:50 +0900 (JST) Date: Wed, 14 Mar 2012 22:35:49 +0900 (JST) Message-Id: <201203141335.q2EDZokH026005@toshiba.co.jp> To: sebastian.kaebisch.ext@siemens.com From: DOI Yusuke In-Reply-To: <1CE2FB42E90B614C98BC172FAB12D4C002D5098E63@DEMCHP99E55MSX.ww902.siemens.net> References: <1CE2FB42E90B614C98BC172FAB12D4C002D50989C3@DEMCHP99E55MSX.ww902.siemens.net> <201203091742.q29HglnN008664@toshiba.co.jp> <1CE2FB42E90B614C98BC172FAB12D4C002D5098E63@DEMCHP99E55MSX.ww902.siemens.net> X-Mailer: Mew version 5.2 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] SenML X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 14 Mar 2012 13:35:52 -0000 Dear Sebastian, From: "Kaebisch, Sebastian" Subject: RE: [apps-discuss] SenML Date: Wed, 14 Mar 2012 10:50:57 +0100 > > > 2) instead of using a "float" value, I would recommend to use the > > "mantissa" and "exponend" representation. A floating value is always a > > challenge for constrained devices because of its inefficent processing. > > > > I think float values in EXI is already mantissa and exponend (base 10). > > That's right, however, EXI has to convert the float value into the mantissa and exponent representation (encoding) and vice versa (decoding) respectively. This processing overhead can be avoided if we working already on data model level only with the mantissa and exponent representation. I cannot get your point. Do you have specific API or something else in mind? I think both is possible and some library for constrianed devices may implement something like the latter. 1) encode_exi_float(EXI_STREAM *out_stream, double f); 2) encode_exi_exp(EXI_STREAM *out_stream, int mantissa, int exponent); Thanks, Yusuke From cabo@tzi.org Wed Mar 14 06:52:21 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72CBB21F87E1 for ; Wed, 14 Mar 2012 06:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.115 X-Spam-Level: X-Spam-Status: No, score=-106.115 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tqc179A6HbK1 for ; Wed, 14 Mar 2012 06:52:21 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id A44A721F87DE for ; Wed, 14 Mar 2012 06:52:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q2EDqCEP027415; Wed, 14 Mar 2012 14:52:12 +0100 (CET) Received: from [10.0.1.3] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 2B37190E; Wed, 14 Mar 2012 14:52:12 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <4F60968D.4020703@stpeter.im> Date: Wed, 14 Mar 2012 14:52:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F5ADDCA.80303@KingsMountain.com> <4F60968D.4020703@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1257) Cc: Apps Discuss Subject: Re: [apps-discuss] Proposal for a Finance Area Mailing List X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 14 Mar 2012 13:52:21 -0000 On Mar 14, 2012, at 14:01, Peter Saint-Andre wrote: > financial > application protocols. Maybe I'm still struggling with the direction of this. Is AMQP a financial application protocol? 0MQ? Gr=FC=DFe, Carsten From timon.elviejo@gmail.com Wed Mar 14 07:54:47 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 253BB21F8733 for ; Wed, 14 Mar 2012 07:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LrNeuGw2kuWq for ; Wed, 14 Mar 2012 07:54:45 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4EAED21F86C6 for ; Wed, 14 Mar 2012 07:54:45 -0700 (PDT) Received: by eeke51 with SMTP id e51so1051250eek.31 for ; Wed, 14 Mar 2012 07:54:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=AQY6pwCtbMnwc+hPmzT+LRsAVOLXmSJOeqHaTXkLpPc=; b=bdQLxAdrhUGt7cQg980ekJz2vhGmxFPAg6JUGupVauCqOG1Sp90sNcPCglsDneeUu9 knDhkwT1v2y+uelIkZIvEOj4WUHUrrvc7EgC3OoGgDqDnJybRJarAbFwzB3dqngwE8gr tUhL5x1YJx28fO/WqpCnldHNyASfcNnqGD/AcsVsVxRt36P5M568CKKW0sh2D94JP77i GC6ktgmklkWCcsNlB6fYFXWFyPM95l2sCBmUT0rATq60JcIdbOjAsvWr8hFLTje3KVMp 6y98dRBLt+x4CEX8W3MKh5fwk4QWqXae457wxZvE0ydGY9LABcg6FqaZy8w+C/Y6PTKL 2Ybw== MIME-Version: 1.0 Received: by 10.52.31.69 with SMTP id y5mr2119400vdh.37.1331736883922; Wed, 14 Mar 2012 07:54:43 -0700 (PDT) Received: by 10.220.69.76 with HTTP; Wed, 14 Mar 2012 07:54:43 -0700 (PDT) In-Reply-To: References: <4F5ADDCA.80303@KingsMountain.com> <4F60968D.4020703@stpeter.im> Date: Wed, 14 Mar 2012 15:54:43 +0100 Message-ID: From: =?ISO-8859-1?Q?Jorge_Tim=F3n?= To: Carsten Bormann Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Apps Discuss Subject: Re: [apps-discuss] Proposal for a Finance Area Mailing List X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jtimonmv@gmail.com List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 14:56:27 -0000 Hi, Walter contacted us in the ripple forum and I would be interested in collaborating with a generic protocol design. Although I've participated in the distributed Ripple protocol design, I've never designed a protocol myself. I have done a lot of research in alternative monetary systems. I'm a computer scientist and I'm involved in the bitcoin and ripple communities, although I haven't had the time to help with the coding yet. I've also discussed some things with the open transactions developers too. I've proposed freicoin (just a bitcoin fork with demurrage, is not even implemented yet, but a very similar crypto currency is about to be released) and some other alternative chains. For all of the above, I think I can be helpful designing the protocol Walter wants. ZeroMQ is not a financial protocol. I would say a networking/queuing/concurrency framework, but I've just read a little bit about it so don't take my word here. Although I think it can be very useful for implementing the financial protocol at hand, it can be used for other things that have nothing to do with finances. If we have to have a working group before getting help from IETF, we can start a thread in the Ripple forum or in bitcoin's (probably the dev mailing list is better) for that purpose. I think there's different people working on different financial protocols that aim to be more or less generic already. I can offer the freicoin forum too. On 3/14/12, Carsten Bormann wrote: > On Mar 14, 2012, at 14:01, Peter Saint-Andre wrote: > >> financial >> application protocols. > > Maybe I'm still struggling with the direction of this. > Is AMQP a financial application protocol? 0MQ? > > Gr=FC=DFe, Carsten > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --=20 Jorge Tim=F3n From stpeter@stpeter.im Wed Mar 14 07:56:31 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A437921F87CD for ; Wed, 14 Mar 2012 07:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.636 X-Spam-Level: X-Spam-Status: No, score=-102.636 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NqiGtwyVx9RC for ; Wed, 14 Mar 2012 07:56:31 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id F018F21F87C9 for ; Wed, 14 Mar 2012 07:56:30 -0700 (PDT) Received: from squire.local (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 95B4D40058; Wed, 14 Mar 2012 09:08:52 -0600 (MDT) Message-ID: <4F60B19D.3070408@stpeter.im> Date: Wed, 14 Mar 2012 08:56:29 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Carsten Bormann References: <4F5ADDCA.80303@KingsMountain.com> <4F60968D.4020703@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.3.5 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Apps Discuss Subject: Re: [apps-discuss] Proposal for a Finance Area Mailing List X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 14 Mar 2012 14:56:31 -0000 On 3/14/12 7:52 AM, Carsten Bormann wrote: > On Mar 14, 2012, at 14:01, Peter Saint-Andre wrote: > >> financial >> application protocols. > > Maybe I'm still struggling with the direction of this. > Is AMQP a financial application protocol? 0MQ? AMQP and 0MQ are used in the financial industry, but I don't think they are financial application protocols of the kind Walter seems to have in mind, such as: https://datatracker.ietf.org/doc/draft-iiban/ https://datatracker.ietf.org/doc/draft-imic/ But perhaps he can explain more clearly. Peter -- Peter Saint-Andre https://stpeter.im/ From melvincarvalho@gmail.com Wed Mar 14 03:08:05 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC6D921F8742 for ; Wed, 14 Mar 2012 03:08:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.765 X-Spam-Level: X-Spam-Status: No, score=-2.765 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ll9vaQLYsxyl for ; Wed, 14 Mar 2012 03:08:04 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 88E3321F871B for ; Wed, 14 Mar 2012 03:08:04 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so2106619vcb.31 for ; Wed, 14 Mar 2012 03:08:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0GO4p50/wgIYn0wuNTCsFM13EaRyVr2D7dY3az+8E8E=; b=bDzKuJvXGt4zl/+gx5M/RMnGE8iB623tEZiNQeIcF1eGiVvEy2UWs3S/mqUGsttvAq UtbC8vmAiFCqsMa/KdXQHN8DEBcMV/o8O/czGLY01sCugSJexqynB8K3CDcUXkzUJFLV 1avXUZC/bMaEAwBsu90vRYTBF9RrhbzgaGFJOxmjRohY49rZfZ+ORHUGxvnn8OpSV1MM +VXvwKvu7h0amBur3IRv4BqLAkstXG4FmYUY0MTqmuFjGexf5mmlSMupyorw7n8pRbD/ zYsSqiR9rOGxa+tWVWL7aJEm21Ez9/Szia5jxX6ScvFC0GIuv013Pa8xfZ3Ua6WSd5mq 3HDg== MIME-Version: 1.0 Received: by 10.52.94.146 with SMTP id dc18mr1411417vdb.19.1331719683715; Wed, 14 Mar 2012 03:08:03 -0700 (PDT) Received: by 10.52.174.70 with HTTP; Wed, 14 Mar 2012 03:08:03 -0700 (PDT) In-Reply-To: <05d001cd01a7$3cbb0c70$b6312550$@packetizer.com> References: <05d001cd01a7$3cbb0c70$b6312550$@packetizer.com> Date: Wed, 14 Mar 2012 11:08:03 +0100 Message-ID: From: Melvin Carvalho To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=bcaec501646fb031d704bb3126c9 X-Mailman-Approved-At: Wed, 14 Mar 2012 08:04:45 -0700 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Webfinger: acct "link relation" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 14 Mar 2012 10:08:05 -0000 --bcaec501646fb031d704bb3126c9 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 14 March 2012 06:56, Paul E. Jones wrote: > Folks,**** > > ** ** > > In the latest Webfinger draft, we introduced a =93acct=94 link relation n= amed > =93acct=94 (see Section 6). The intent with that link relation was to al= low > for one to inform a webfinger client that a user=92s account information = may > be retrieved elsewhere. I believe this will be important, since a user > might have more than one account and this might serve as a means of > associating them. Certainly, it would be a way of retrieving information > from those other accounts automatically.**** > > ** ** > > Perhaps calling the new link relation =93acct=94 is too restrictive, thou= gh. > If one used Webfinger to query other kinds of information other than a > user=92s account, there may still be a need/desire to refer the Webfinger > client to other resources.**** > > ** ** > > What do you think about changing this section such that the link relation > is renamed to =93seealso=94? This would still be useful when querying an= acct > URI, but would also be useful when querying any URI since it is more > generic.**** > > ** ** > > Do note that =93seealso=94 would be different than the =93alternate=94 li= nk > relation. It would not refer to alternative information, but would refer > to supplemental information. In practice, the supplemental information m= ay > be the more informative since the bulk of the information related to a us= er > might be held under a different account. > seeAlso already exists as an "extended relation type" http://www.w3.org/TR/2000/CR-rdf-schema-20000327/#s2.3.4 Seems like a good choice. In fact, timbl uses it in his profile: $ rapper -g http://www.w3.org/People/Berners-Lee/card | grep seeAlso < http://dig.csail.mit.edu/2008/webdav/timbl/foaf.rdf> . sameas is also similar . > **** > > ** ** > > Your thoughts?**** > > ** ** > > Paul**** > > ** ** > > ** ** > > ** ** > --bcaec501646fb031d704bb3126c9 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On 14 March 2012 06:56, Paul E. Jones <paulej@packeti= zer.com> wrote:

Folks,

=A0

In the latest Webfinger draft, we introduced a =93acct= =94 link relation named =93acct=94 (see Section 6).=A0 The intent with that= link relation was to allow for one to inform a webfinger client that a use= r=92s account information may be retrieved elsewhere.=A0 I believe this wil= l be important, since a user might have more than one account and this migh= t serve as a means of associating them.=A0 Certainly, it would be a way of = retrieving information from those other accounts automatically.

=A0

Perhaps = calling the new link relation =93acct=94 is too restrictive, though.=A0 If = one used Webfinger to query other kinds of information other than a user=92= s account, there may still be a need/desire to refer the Webfinger client t= o other resources.

=A0

What do = you think about changing this section such that the link relation is rename= d to =93seealso=94?=A0 This would still be useful when querying an acct URI= , but would also be useful when querying any URI since it=A0 is more generi= c.

=A0

Do note = that =93seealso=94 would be different than the =93alternate=94 link relatio= n.=A0 It would not refer to alternative information, but would refer to sup= plemental information.=A0 In practice, the supplemental information may be = the more informative since the bulk of the information related to a user mi= ght be held under a different account.

<= u>

=A0

Your tho= ughts?<= /span>

=A0

Paul

= =A0

=A0

=A0

--bcaec501646fb031d704bb3126c9-- From michiel@unhosted.org Tue Mar 13 23:56:35 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA7C21F85FB for ; Tue, 13 Mar 2012 23:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MCLJdrNU0B9d for ; Tue, 13 Mar 2012 23:56:34 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id B7D0D21F85F6 for ; Tue, 13 Mar 2012 23:56:34 -0700 (PDT) Received: by iazz13 with SMTP id z13so2206459iaz.31 for ; Tue, 13 Mar 2012 23:56:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=LjCjLlXGYX6W/MDR6UDeVglGSB/OGV95HJngUTBWI+c=; b=kcoCNIgRfGsobbd3hP1jfb3A4zegeEb9ti3YEBYyS0Jh4lmz70u5W8KI+ALZQ1VDsX Hm1sLo5/xpyT0wqJ6eEwmUkaNtVR3Xmid1iqxoxeEVzrkZVBYI/RvwHtJSBil88sP22H rY4IPCot++cSTEsCw2VgXh2XcRQqcmxHZpxsFpJ1SeVSQA5flqzWIPvecwp76t+F5qfC vfw1ejm6GYGh0bvYyNCq8NxADxb/nUyWBfoDlhLXm84VjW4vXlVw3QUabmST6y0BQdrl W/aCv7B8l3Uh1jVeHnZASjK7Z9CM/GFPc7mXfoQLiI218ktKouXvGe26uAUSt7iVtiRs Q7Qg== MIME-Version: 1.0 Received: by 10.68.233.98 with SMTP id tv2mr2065755pbc.51.1331708193822; Tue, 13 Mar 2012 23:56:33 -0700 (PDT) Received: by 10.68.14.166 with HTTP; Tue, 13 Mar 2012 23:56:33 -0700 (PDT) X-Originating-IP: [84.90.251.181] In-Reply-To: <05d001cd01a7$3cbb0c70$b6312550$@packetizer.com> References: <05d001cd01a7$3cbb0c70$b6312550$@packetizer.com> Date: Wed, 14 Mar 2012 06:56:33 +0000 Message-ID: From: Michiel de Jong To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=047d7b33d630d6561d04bb2e79bc X-Gm-Message-State: ALoCoQkRuah5gXZZ7il783Tm3j8Li1OwXI4Xo3ZYEklnp2pmY+h2EqSNyvY0yrVydOTvxJJh+el7 X-Mailman-Approved-At: Wed, 14 Mar 2012 08:04:48 -0700 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Webfinger: acct "link relation" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 14 Mar 2012 06:56:35 -0000 --047d7b33d630d6561d04bb2e79bc Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable one very nice application of that would be to facilitate implementation of user-editable webfinger. There will be resources that an identity provider wants to announce by default for all their users, but maybe some (power) users want to announce some additional machine-readable pointers related to their user address. Separating user-provided links from provider-provided :) might make a lot of sense where you don't want the provider-provided stuff to break. In case of conflict i think the 'seealso' one should always lose. That way, you can give your users the freedom to paste whatever links they want into their profile settings, without fear of that breaking your service's well-tested federation features. user-editable webfinger would be an amazing feature, and whereas in theory you could offer it already, allowing users to paste stuff into the bowels of your service's federation mechanism feels just wrong, adding a seealso link to a section on the user's profile page, where the user already has things like a bio, interests, location, etcetera, feels a lot more right. i guess it's a software architecture consideration. On Wed, Mar 14, 2012 at 5:56 AM, Paul E. Jones wrote= : > Folks,**** > > ** ** > > In the latest Webfinger draft, we introduced a =93acct=94 link relation n= amed > =93acct=94 (see Section 6). The intent with that link relation was to al= low > for one to inform a webfinger client that a user=92s account information = may > be retrieved elsewhere. I believe this will be important, since a user > might have more than one account and this might serve as a means of > associating them. Certainly, it would be a way of retrieving information > from those other accounts automatically.**** > > ** ** > > Perhaps calling the new link relation =93acct=94 is too restrictive, thou= gh. > If one used Webfinger to query other kinds of information other than a > user=92s account, there may still be a need/desire to refer the Webfinger > client to other resources.**** > > ** ** > > What do you think about changing this section such that the link relation > is renamed to =93seealso=94? This would still be useful when querying an= acct > URI, but would also be useful when querying any URI since it is more > generic.**** > > ** ** > > Do note that =93seealso=94 would be different than the =93alternate=94 li= nk > relation. It would not refer to alternative information, but would refer > to supplemental information. In practice, the supplemental information m= ay > be the more informative since the bulk of the information related to a us= er > might be held under a different account.**** > > ** ** > > Your thoughts?**** > > ** ** > > Paul**** > > ** ** > > ** ** > > ** ** > --047d7b33d630d6561d04bb2e79bc Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable one very nice application of that would be to facilitate implementation of = user-editable webfinger. There will be resources that an identity provider = wants to announce by default for all their users, but maybe some (power) us= ers want to announce some additional machine-readable pointers related to t= heir user address. Separating user-provided links from provider-provided :)= might make a lot of sense where you don't want the provider-provided s= tuff to break. In case of conflict i think the 'seealso' one should= always lose. That way, you can give your users the freedom to paste whatev= er links they want into their profile settings, without fear of that breaki= ng your service's well-tested federation features.

user-editable webfinger would be an amazing feature, and whereas in the= ory you could offer it already, allowing users to paste stuff into the bowe= ls of your service's federation mechanism feels just wrong, adding a se= ealso link to a section on the user's profile page, where the user alre= ady has things like a bio, interests, location, etcetera, feels a lot more = right. i guess it's a software architecture consideration.


On Wed, Mar 14, 2012 at 5:56 AM, Paul E.= Jones <paule= j@packetizer.com> wrote:

Folks,

=A0

In the latest Webfinger draft, we introduced a =93acct= =94 link relation named =93acct=94 (see Section 6).=A0 The intent with that= link relation was to allow for one to inform a webfinger client that a use= r=92s account information may be retrieved elsewhere.=A0 I believe this wil= l be important, since a user might have more than one account and this migh= t serve as a means of associating them.=A0 Certainly, it would be a way of = retrieving information from those other accounts automatically.

=A0

Perhaps = calling the new link relation =93acct=94 is too restrictive, though.=A0 If = one used Webfinger to query other kinds of information other than a user=92= s account, there may still be a need/desire to refer the Webfinger client t= o other resources.

=A0

What do = you think about changing this section such that the link relation is rename= d to =93seealso=94?=A0 This would still be useful when querying an acct URI= , but would also be useful when querying any URI since it=A0 is more generi= c.

=A0

Do note = that =93seealso=94 would be different than the =93alternate=94 link relatio= n.=A0 It would not refer to alternative information, but would refer to sup= plemental information.=A0 In practice, the supplemental information may be = the more informative since the bulk of the information related to a user mi= ght be held under a different account.

=A0

Your tho= ughts?<= /span>

=A0

Paul

= =A0

=A0

=A0

--047d7b33d630d6561d04bb2e79bc-- From bobwyman@gmail.com Wed Mar 14 08:25:51 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21FCA21F86F8 for ; Wed, 14 Mar 2012 08:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.634 X-Spam-Level: X-Spam-Status: No, score=-1.634 tagged_above=-999 required=5 tests=[AWL=-1.343, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HS_INDEX_PARAM=0.001, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QcDd6KWehb6e for ; Wed, 14 Mar 2012 08:25:49 -0700 (PDT) Received: from mail-fa0-f44.google.com (mail-fa0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7009821F86F3 for ; Wed, 14 Mar 2012 08:25:49 -0700 (PDT) Received: by faaa25 with SMTP id a25so414772faa.31 for ; Wed, 14 Mar 2012 08:25:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=/AxJCD+QeYjb2wREyIAvP51y8cfHuNs48Uu8A7QVsDg=; b=QoEsrl0yDk1TtcPxSjV1O5d6PIpUlW4S053H42RG16WADIiv4Hzn3SefKeXF1lVB7U 4foOhodpsl+0JzBW6WTQDUZNYqzCWz2wh7OtTMJQbAh8nlPiuMzUR0RQRXmsBxi8rGa4 pfYxkP4DgRAXqg06CBRVE6fI71wdJmk42aO4lNl49ejfMvCheuWWpplX42mcDm25dXuD zRd9Rh+em5syAzekXBnIF3YnnNf/95ORbI3/h+GPfr6RxsE3yXew12B82D0M+MmFeAmn RCuGjsSvtHYYfLD5GuEFzE9pyWlXeuc0Qj/iY+60AFRo4L01POnwg4EOqovzcP4vegbB 0njw== MIME-Version: 1.0 Received: by 10.224.222.141 with SMTP id ig13mr3452570qab.63.1331738748271; Wed, 14 Mar 2012 08:25:48 -0700 (PDT) Sender: bobwyman@gmail.com Received: by 10.229.157.16 with HTTP; Wed, 14 Mar 2012 08:25:48 -0700 (PDT) In-Reply-To: <05d001cd01a7$3cbb0c70$b6312550$@packetizer.com> References: <05d001cd01a7$3cbb0c70$b6312550$@packetizer.com> Date: Wed, 14 Mar 2012 11:25:48 -0400 X-Google-Sender-Auth: maGItz6NprNxKxX2daM_iMgbGtw Message-ID: From: Bob Wyman To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=20cf3074b372063b8d04bb35972f Cc: webfinger@googlegroups.com, apps-discuss@ietf.org Subject: Re: [apps-discuss] Webfinger: acct "link relation" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 14 Mar 2012 15:25:51 -0000 --20cf3074b372063b8d04bb35972f Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks for mentioning section 6. I have been puzzling over this for some time now. It seems to me that if Alice receives an email from " bob@example.net" then, because there is no certain equivalence of mailto:and acct: identifiers, Alice should query for "mailto: bob@example.net" in order to discover "acct:bob@example.com" rather than assuming similarity between the mailto: and acct: identifiers and first querying for "acct:bob@example.net." It must be remembered that WebFinger acct: identifiers need not be the same as or even similar to mailto: identifiers. Additionly, similar identifiers, such as "mailto:bob@example.net" and "acct:bob@example.net," need not identify the same person or entity. (although it would be really, really smart if they did...) Given that in most cases, "acct:xxx" and "mailto:xxx" will, in fact, be associated with the same entity, it would be a bit of a nuisance to require the multi-step discovery process outlined above. Especially since we know that mapping from mailto: to acct: will be a very, very common requirement. Thus, it seems reasonable to me that we would add a few new rules: 1) If the server responding to a request for mailto: information is also the authoritative server for the WebFinger acct information, it may provide that information as long as it also provides a link with rel=3Dacct element to identify the acct:. In this case, it should be understood that any information provided (other than the link that shows the relationship between the identifiers) is associated with the acct: identifier, not with the mailto: identifier. This server-side automatic mapping rule could, of course, be generalized to say that whenever the server knows the exact mapping from any URI, no matter what scheme it uses, to a corresponding acct: URI, it may perform the translation as long as it provides an appropriate link with (rel=3Dacct) in its response. 2) To enable clients to do URI translations, it would be useful for servers to be able to describe those translations which are easily performed. For instance, for servers that maintain a one-to-one relationship between mailto: and acct: URIs, it should be possible for the server to publish in its host metadata the mapping between the two identifiers. Thus, we might have an XRD like the following: ** The XRD above not only describes the general template for forming queries, it gives specific instructions re optional pre-translation for mailto:URIs. Clearly, more complex template mappings would be interesting and often useful, but perhaps too complex. bob wyman On Wed, Mar 14, 2012 at 1:56 AM, Paul E. Jones wrote: > Folks, > > > > In the latest Webfinger draft, we introduced a =93acct=94 link relation n= amed > =93acct=94 (see Section 6). The intent with that link relation was to al= low for > one to inform a webfinger client that a user=92s account information may = be > retrieved elsewhere. I believe this will be important, since a user migh= t > have more than one account and this might serve as a means of associating > them. Certainly, it would be a way of retrieving information from those > other accounts automatically. > > > > Perhaps calling the new link relation =93acct=94 is too restrictive, thou= gh. If > one used Webfinger to query other kinds of information other than a user= =92s > account, there may still be a need/desire to refer the Webfinger client t= o > other resources. > > > > What do you think about changing this section such that the link relation is > renamed to =93seealso=94? This would still be useful when querying an ac= ct URI, > but would also be useful when querying any URI since it is more generic. > > > > Do note that =93seealso=94 would be different than the =93alternate=94 li= nk > relation. It would not refer to alternative information, but would refer to > supplemental information. In practice, the supplemental information may be > the more informative since the bulk of the information related to a user > might be held under a different account. > > > > Your thoughts? > > > > Paul > > > > > > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --20cf3074b372063b8d04bb35972f Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks for mentioning section 6. I have been puzzling over this for some ti= me now. It seems to me that if Alice receives an email from "bob@example.net" then, because there i= s no certain equivalence of mailto: and acct: identifiers, Alice should que= ry for "mailto:bob@example.net&= quot; in order to discover "= acct:bob@example.com" rather than assuming similarity between the = mailto: and acct: identifiers and first querying for "acct:bob@example.net."
It must be remembered that WebFinger acct: identifiers need not be the same= as or even similar to mailto: identifiers. Additionly, similar identifiers= , such as "mailto:bob@example.net" and "acct:bob@examp= le.net," need not identify the same person or entity. (although it= would be really, really smart if they did...)

Given that in most cases, "acct:xxx" and "mailto:xxx" will, in fact, be associated with the same en= tity, it would be a bit of a nuisance to require the multi-step discovery p= rocess outlined above. Especially since we know that mapping from mailto: t= o acct: will be a very, very common requirement. Thus, it seems reasonable = to me that we would add a few new rules:
1) If the server responding to a request for mailto: information is also th= e authoritative server for the WebFinger acct information, it may provide t= hat information as long as it also provides a link with rel=3Dacct element = to identify the acct:. In this case, it should be understood that any infor= mation provided (other than the link that shows the relationship between th= e identifiers) is associated with the acct: identifier, not with the mailto= : identifier. This server-side automatic mapping rule could, of course, be = generalized to say that whenever the server knows the exact mapping from an= y URI, no matter what scheme it uses, to a corresponding acct: URI, it may = perform the translation as long as it provides an appropriate link with (re= l=3Dacct) in its response.
2) To enable clients to do URI translations, it would be useful for servers= to be able to describe those translations which are easily performed. For = instance, for servers that maintain a one-to-one relationship between mailt= o: and acct: URIs, it should be possible for the server to publish in its h= ost metadata the mapping between the two identifiers. Thus, we might have a= n XRD like the following:
    <XRD xmlns=3D"http://docs.oasis-open.org/ns/xri/xrd-1.0">
       <Link rel=3D"lrdd"
             type=3D"application/xrd+xml"
             template=3D"https://example.com/lrdd/?uri=3D{uri}"/>
=A0 =A0 =A0 =A0<Link rel=3D"mailto2acct" =
template=3D"acct:{mailto_id}"/>

     </XRD>

The XRD above not only describes the general temp= late for forming queries, it gives specific instructions re optional pre-tr= anslation for mailto: URIs. Clearly, more complex template mappings would b= e interesting and often useful, but perhaps too complex.

bob wyman

On Wed, Mar 14, 2012 at 1:56 AM, Paul E. Jones <paulej@packetizer.com> wrote:<= br>> Folks,
>
> =A0
>
> In the latest Webfinger = draft, we introduced a =93acct=94 link relation named
> =93acct=94 (see Section 6).=A0 The intent with that link relation was = to allow for
> one to inform a webfinger client that a user=92s accou= nt information may be
> retrieved elsewhere.=A0 I believe this will b= e important, since a user might
> have more than one account and this might serve as a means of associat= ing
> them.=A0 Certainly, it would be a way of retrieving information= from those
> other accounts automatically.
>
> =A0
&g= t;
> Perhaps calling the new link relation =93acct=94 is too restrictive, t= hough.=A0 If
> one used Webfinger to query other kinds of information= other than a user=92s
> account, there may still be a need/desire to= refer the Webfinger client to
> other resources.
>
> =A0
>
> What do you think= about changing this section such that the link relation is
> renamed= to =93seealso=94?=A0 This would still be useful when querying an acct URI,=
> but would also be useful when querying any URI since it=A0 is more gen= eric.
>
> =A0
>
> Do note that =93seealso=94 would = be different than the =93alternate=94 link
> relation.=A0 It would no= t refer to alternative information, but would refer to
> supplemental information.=A0 In practice, the supplemental information= may be
> the more informative since the bulk of the information rela= ted to a user
> might be held under a different account.
>
> =A0
>
> Your thoughts?
>
> =A0
>
>= Paul
>
> =A0
>
> =A0
>
> =A0
>>
> _______________________________________________
> apps= -discuss mailing list
> apps-discuss@ietf.org
= > https:/= /www.ietf.org/mailman/listinfo/apps-discuss
>
--20cf3074b372063b8d04bb35972f-- From paulej@packetizer.com Wed Mar 14 08:54:11 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF0321F85B8 for ; Wed, 14 Mar 2012 08:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bVwWqZbiDAPp for ; Wed, 14 Mar 2012 08:54:09 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id F3D8921F85F6 for ; Wed, 14 Mar 2012 08:54:07 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q2EFs6x4006963 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 14 Mar 2012 11:54:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1331740447; bh=p+Q2+wncXOOXAKvmEKzl2FfR8mpIExgi0Ik7wm0wu1s=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=VzGmBkVq9Nzs3SLVN4aRV0xyZeEPhHjZUIBQM9+l94bXzmlP5l8uBqRwjpuqEeqQ1 Kk+1OXUg6MKd8M0KbuTPEC8fuZf9VUa8HNa4EUwixf430CwoGPmZQeG1jVkHqXiaZC zKWGWFZK4Y53UcXsAzC6YNWGhHOLuiZriboiM3e0= From: "Paul E. Jones" To: References: <05d001cd01a7$3cbb0c70$b6312550$@packetizer.com> In-Reply-To: Date: Wed, 14 Mar 2012 11:54:09 -0400 Message-ID: <009f01cd01fa$b1eacfa0$15c06ee0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A0_01CD01D9.2ADAB640" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIpr5CrRpL27TKx2eu4GfpqVU03ngHiZKY7laGCtCA= Content-Language: en-us Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Webfinger: acct "link relation" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 14 Mar 2012 15:54:11 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00A0_01CD01D9.2ADAB640 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Michael, I would hope that virtually every piece of information stored in a user's profile is editable, though I can imagine some information may not be. In any case, that largely seems to be an account management user interface issue. Are you suggesting a change in the Webfinger protocol? Paul From: webfinger@googlegroups.com [mailto:webfinger@googlegroups.com] On Behalf Of Michiel de Jong Sent: Wednesday, March 14, 2012 2:57 AM To: webfinger@googlegroups.com Cc: apps-discuss@ietf.org Subject: Re: Webfinger: acct "link relation" one very nice application of that would be to facilitate implementation of user-editable webfinger. There will be resources that an identity provider wants to announce by default for all their users, but maybe some (power) users want to announce some additional machine-readable pointers related to their user address. Separating user-provided links from provider-provided :) might make a lot of sense where you don't want the provider-provided stuff to break. In case of conflict i think the 'seealso' one should always lose. That way, you can give your users the freedom to paste whatever links they want into their profile settings, without fear of that breaking your service's well-tested federation features. user-editable webfinger would be an amazing feature, and whereas in theory you could offer it already, allowing users to paste stuff into the bowels of your service's federation mechanism feels just wrong, adding a seealso link to a section on the user's profile page, where the user already has things like a bio, interests, location, etcetera, feels a lot more right. i guess it's a software architecture consideration. On Wed, Mar 14, 2012 at 5:56 AM, Paul E. Jones wrote: Folks, In the latest Webfinger draft, we introduced a "acct" link relation named "acct" (see Section 6). The intent with that link relation was to allow for one to inform a webfinger client that a user's account information may be retrieved elsewhere. I believe this will be important, since a user might have more than one account and this might serve as a means of associating them. Certainly, it would be a way of retrieving information from those other accounts automatically. Perhaps calling the new link relation "acct" is too restrictive, though. If one used Webfinger to query other kinds of information other than a user's account, there may still be a need/desire to refer the Webfinger client to other resources. What do you think about changing this section such that the link relation is renamed to "seealso"? This would still be useful when querying an acct URI, but would also be useful when querying any URI since it is more generic. Do note that "seealso" would be different than the "alternate" link relation. It would not refer to alternative information, but would refer to supplemental information. In practice, the supplemental information may be the more informative since the bulk of the information related to a user might be held under a different account. Your thoughts? Paul ------=_NextPart_000_00A0_01CD01D9.2ADAB640 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Michael,

 

I would hope that virtually every piece of information stored in a = user’s profile is editable, though I can imagine some information = may not be.  In any case, that largely seems to be an account = management user interface issue.  Are you suggesting a change in = the Webfinger protocol?

 

Paul

 

From:= = webfinger@googlegroups.com [mailto:webfinger@googlegroups.com] On = Behalf Of Michiel de Jong
Sent: Wednesday, March 14, 2012 = 2:57 AM
To: webfinger@googlegroups.com
Cc: = apps-discuss@ietf.org
Subject: Re: Webfinger: acct "link = relation"

 

one very nice application of that would = be to facilitate implementation of user-editable webfinger. There will = be resources that an identity provider wants to announce by default for = all their users, but maybe some (power) users want to announce some = additional machine-readable pointers related to their user address. = Separating user-provided links from provider-provided :) might make a = lot of sense where you don't want the provider-provided stuff to break. = In case of conflict i think the 'seealso' one should always lose. That = way, you can give your users the freedom to paste whatever links they = want into their profile settings, without fear of that breaking your = service's well-tested federation features.

user-editable = webfinger would be an amazing feature, and whereas in theory you could = offer it already, allowing users to paste stuff into the bowels of your = service's federation mechanism feels just wrong, adding a seealso link = to a section on the user's profile page, where the user already has = things like a bio, interests, location, etcetera, feels a lot more = right. i guess it's a software architecture = consideration.

On Wed, = Mar 14, 2012 at 5:56 AM, Paul E. Jones <paulej@packetizer.com> = wrote:

Folks,<= /o:p>

 <= /o:p>

In the = latest Webfinger draft, we introduced a “acct” link relation = named “acct” (see Section 6).  The intent with that = link relation was to allow for one to inform a webfinger client that a = user’s account information may be retrieved elsewhere.  I = believe this will be important, since a user might have more than one = account and this might serve as a means of associating them.  = Certainly, it would be a way of retrieving information from those other = accounts automatically.

 <= /o:p>

Perhaps = calling the new link relation “acct” is too restrictive, = though.  If one used Webfinger to query other kinds of information = other than a user’s account, there may still be a need/desire to = refer the Webfinger client to other resources.

 <= /o:p>

What do you = think about changing this section such that the link relation is renamed = to “seealso”?  This would still be useful when querying = an acct URI, but would also be useful when querying any URI since = it  is more generic.

 <= /o:p>

Do note = that “seealso” would be different than the = “alternate” link relation.  It would not refer to = alternative information, but would refer to supplemental = information.  In practice, the supplemental information may be the = more informative since the bulk of the information related to a user = might be held under a different account.

 <= /o:p>

Your = thoughts?

 

Paul

 

 

 

 

------=_NextPart_000_00A0_01CD01D9.2ADAB640-- From paulej@packetizer.com Wed Mar 14 08:59:22 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7573721F86E4 for ; Wed, 14 Mar 2012 08:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zgqhHLhWYQD0 for ; Wed, 14 Mar 2012 08:59:20 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA9321F86E3 for ; Wed, 14 Mar 2012 08:59:20 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q2EFxIL4007066 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 14 Mar 2012 11:59:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1331740759; bh=e9uhN0GjL7DA4No+Vp61YPdM1h1iTg724EbgNCQjskk=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=JLMmhYWl22AxY1m63tHEwLbvaeryesKUTfAI161IhFJpQ/hE0+UxWQtFF3qrwWVkz 7YN1PeNe0mQyRu7PBpTf++PddPG7RM6W815wrZH+waHC7W+tKJxRwMNLcjxm2NVdhj dO4j0K7O6mqh0LT+wT5E3+N7AnSGPYICZkbtAxtM= From: "Paul E. Jones" To: References: <05d001cd01a7$3cbb0c70$b6312550$@packetizer.com> In-Reply-To: Date: Wed, 14 Mar 2012 11:59:22 -0400 Message-ID: <00ac01cd01fb$6c30f7e0$4492e7a0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00AD_01CD01D9.E5206950" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIpr5CrRpL27TKx2eu4GfpqVU03ngF54BtklaTHSmA= Content-Language: en-us Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Webfinger: acct "link relation" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 14 Mar 2012 15:59:22 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00AD_01CD01D9.E5206950 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Melvin, I, too, like the idea of introducing "seealo" that would have wider applicability. For example, consider this page: http://www.techabulary.com/h/h323/ The bottom of this page refers the reader to several other resources for additional information. I think having "seealso" generally available as a web link relation would allow a web site to suggest related reading material and the browser could offer up that list via a consistent user interface for the user. Now, should we document "seealso" in the Webfinger draft or should that be in its own draft? Paul From: webfinger@googlegroups.com [mailto:webfinger@googlegroups.com] On Behalf Of Melvin Carvalho Sent: Wednesday, March 14, 2012 6:08 AM To: webfinger@googlegroups.com Cc: apps-discuss@ietf.org Subject: Re: Webfinger: acct "link relation" On 14 March 2012 06:56, Paul E. Jones wrote: Folks, In the latest Webfinger draft, we introduced a "acct" link relation named "acct" (see Section 6). The intent with that link relation was to allow for one to inform a webfinger client that a user's account information may be retrieved elsewhere. I believe this will be important, since a user might have more than one account and this might serve as a means of associating them. Certainly, it would be a way of retrieving information from those other accounts automatically. Perhaps calling the new link relation "acct" is too restrictive, though. If one used Webfinger to query other kinds of information other than a user's account, there may still be a need/desire to refer the Webfinger client to other resources. What do you think about changing this section such that the link relation is renamed to "seealso"? This would still be useful when querying an acct URI, but would also be useful when querying any URI since it is more generic. Do note that "seealso" would be different than the "alternate" link relation. It would not refer to alternative information, but would refer to supplemental information. In practice, the supplemental information may be the more informative since the bulk of the information related to a user might be held under a different account. seeAlso already exists as an "extended relation type" http://www.w3.org/TR/2000/CR-rdf-schema-20000327/#s2.3.4 Seems like a good choice. In fact, timbl uses it in his profile: $ rapper -g http://www.w3.org/People/Berners-Lee/card | grep seeAlso . sameas is also similar . Your thoughts? Paul ------=_NextPart_000_00AD_01CD01D9.E5206950 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Melvin,

 

I, too, like the idea of introducing “seealo” that would = have wider applicability.  For example, consider this = page:

http://www.techabulary.com/h/= h323/

 

The bottom of this page refers the reader to several other resources = for additional information.  I think having “seealso” = generally available as a web link relation would allow a web site to = suggest related reading material and the browser could offer up that = list via a consistent user interface for the = user.

 

Now, should we document “seealso” in the Webfinger draft = or should that be in its own draft?

 

Paul

 

From:= = webfinger@googlegroups.com [mailto:webfinger@googlegroups.com] On = Behalf Of Melvin Carvalho
Sent: Wednesday, March 14, 2012 = 6:08 AM
To: webfinger@googlegroups.com
Cc: = apps-discuss@ietf.org
Subject: Re: Webfinger: acct "link = relation"

 

 

On 14 March 2012 06:56, Paul E. Jones <paulej@packetizer.com> = wrote:

Folks,<= /o:p>

 <= /o:p>

In the = latest Webfinger draft, we introduced a “acct” link relation = named “acct” (see Section 6).  The intent with that = link relation was to allow for one to inform a webfinger client that a = user’s account information may be retrieved elsewhere.  I = believe this will be important, since a user might have more than one = account and this might serve as a means of associating them.  = Certainly, it would be a way of retrieving information from those other = accounts automatically.

 <= /o:p>

Perhaps = calling the new link relation “acct” is too restrictive, = though.  If one used Webfinger to query other kinds of information = other than a user’s account, there may still be a need/desire to = refer the Webfinger client to other resources.

 <= /o:p>

What do you = think about changing this section such that the link relation is renamed = to “seealso”?  This would still be useful when querying = an acct URI, but would also be useful when querying any URI since = it  is more generic.

 <= /o:p>

Do note = that “seealso” would be different than the = “alternate” link relation.  It would not refer to = alternative information, but would refer to supplemental = information.  In practice, the supplemental information may be the = more informative since the bulk of the information related to a user = might be held under a different = account.

 <= /o:p>

Your = thoughts?

 

Paul

 

 

 

 

------=_NextPart_000_00AD_01CD01D9.E5206950-- From paulej@packetizer.com Wed Mar 14 09:04:05 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3C3321F86DC for ; Wed, 14 Mar 2012 09:04:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ihz9ycCEbrMs for ; Wed, 14 Mar 2012 09:04:03 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 922B421F86AD for ; Wed, 14 Mar 2012 09:04:03 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q2EG41WZ007205 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 14 Mar 2012 12:04:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1331741042; bh=vAp25BFbLcf72qIfkhIWs1qNUKh0RliN+pA5VTcCA00=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=cgN00QKd4Kn3zC5DxipwNJvTo5E3gZhkkcGxg/rYaXRvKkpTeTOfel1y+RS9roOzM 6SCLfkkipgfhQ7P0/0SSHmPA0Iv7ACnhFoE/zd9YpI5+rGcOan0V0RITDsoxjR4AQ+ aTaLh92OFhgBDuYH2LA6K4xaKACQJ4GxzsSVEfUY= From: "Paul E. Jones" To: References: <05d001cd01a7$3cbb0c70$b6312550$@packetizer.com> <4F60AD42.2080208@openlinksw.com> In-Reply-To: <4F60AD42.2080208@openlinksw.com> Date: Wed, 14 Mar 2012 12:04:05 -0400 Message-ID: <00bf01cd01fc$1502bde0$3f0839a0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C0_01CD01DA.8DF2A480" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIpr5CrRpL27TKx2eu4GfpqVU03ngH8fdNDlaC0jJA= Content-Language: en-us Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Webfinger: acct "link relation" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 14 Mar 2012 16:04:05 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00C0_01CD01DA.8DF2A480 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Kingsley, Oh, I was not aware of the "related" scheme. So, if "related" and "seealso" have the same semantics, then I would not want to introduce a new one. Are there different semantics? Would we prefer to use "seealso" or "related" or "acct" to refer webfinger to go look at a different account URI? Paul From: webfinger@googlegroups.com [mailto:webfinger@googlegroups.com] On Behalf Of Kingsley Idehen Sent: Wednesday, March 14, 2012 10:38 AM To: webfinger@googlegroups.com Subject: Re: Webfinger: acct "link relation" On 3/14/12 1:56 AM, Paul E. Jones wrote: Folks, In the latest Webfinger draft, we introduced a "acct" link relation named "acct" (see Section 6). The intent with that link relation was to allow for one to inform a webfinger client that a user's account information may be retrieved elsewhere. I believe this will be important, since a user might have more than one account and this might serve as a means of associating them. Certainly, it would be a way of retrieving information from those other accounts automatically. Perhaps calling the new link relation "acct" is too restrictive, though. If one used Webfinger to query other kinds of information other than a user's account, there may still be a need/desire to refer the Webfinger client to other resources. What do you think about changing this section such that the link relation is renamed to "seealso"? This would still be useful when querying an acct URI, but would also be useful when querying any URI since it is more generic. Do note that "seealso" would be different than the "alternate" link relation. It would not refer to alternative information, but would refer to supplemental information. In practice, the supplemental information may be the more informative since the bulk of the information related to a user might be held under a different account. Your thoughts? Paul +1 for "seeAlso" . But, this is analogous to "related" which already exists i.e., :-) -- Regards, Kingsley Idehen Founder & CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca handle: @kidehen Google+ Profile: https://plus.google.com/112399767740508618350/about LinkedIn Profile: http://www.linkedin.com/in/kidehen ------=_NextPart_000_00C0_01CD01DA.8DF2A480 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Kingsley,

 

Oh, I was not aware of = the “related” scheme.  So, if “related” and = “seealso” have the same semantics, then I would not want to = introduce a new one.

 

Are there different = semantics?

 

Would we prefer to  = use “seealso” or “related” or “acct” = to refer webfinger to go look at a different account = URI?

 

Paul

 

From: webfinger@googlegroups.com [mailto:webfinger@googlegroups.com] = On Behalf Of Kingsley Idehen
Sent: Wednesday, March 14, = 2012 10:38 AM
To: = webfinger@googlegroups.com
Subject: Re: Webfinger: acct = "link relation"

 

On 3/14/12 = 1:56 AM, Paul E. Jones wrote:

Folks,

 

In the = latest Webfinger draft, we introduced a “acct” link relation = named “acct” (see Section 6).  The intent with that = link relation was to allow for one to inform a webfinger client that a = user’s account information may be retrieved elsewhere.  I = believe this will be important, since a user might have more than one = account and this might serve as a means of associating them.  = Certainly, it would be a way of retrieving information from those other = accounts automatically.

 

Perhaps = calling the new link relation “acct” is too restrictive, = though.  If one used Webfinger to query other kinds of information = other than a user’s account, there may still be a need/desire to = refer the Webfinger client to other resources.

 

What do you = think about changing this section such that the link relation is renamed = to “seealso”?  This would still be useful when querying = an acct URI, but would also be useful when querying any URI since = it  is more generic.

 

Do note that = “seealso” would be different than the = “alternate” link relation.  It would not refer to = alternative information, but would refer to supplemental = information.  In practice, the supplemental information may be the = more informative since the bulk of the information related to a user = might be held under a different account.

 

Your = thoughts?

 

Paul

 

 

 

+1 for = "seeAlso" . But, this is analogous to "related" = which already exists i.e., <link rel=3D"related" .../> = :-)


-- =

 
Regards,
 
Kingsley =
Idehen       =
      
Founder & CEO =

OpenLink Software     =

Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.co=
m/blog/~kidehen
Twitter/Identi.ca handle: =
@kidehen
Google+ Profile: https://plus=
.google.com/112399767740508618350/about
LinkedIn=
 Profile: http://www.linkedin.com/in/ki=
dehen
 
 
 
 
------=_NextPart_000_00C0_01CD01DA.8DF2A480-- From paulej@packetizer.com Wed Mar 14 12:38:21 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D40C21F84F3 for ; Wed, 14 Mar 2012 12:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.235 X-Spam-Level: X-Spam-Status: No, score=-2.235 tagged_above=-999 required=5 tests=[AWL=-0.238, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id igGG4Bp3mt1m for ; Wed, 14 Mar 2012 12:38:17 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id F304321F85BE for ; Wed, 14 Mar 2012 12:38:16 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q2EJcEOM011933 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 14 Mar 2012 15:38:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1331753895; bh=Hc8OpOBKzA96JO5MggWMVDUPL5OXUHcjupAQDXOGhF4=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=gBolh8+5urYDpjVOu9RMCjyt34GRHUwmaq2WAN0fkeXaTjz7nf2fiemqWhzNlG5dV p01wurCfNE+1ygR55WT9zAAjiDVBHFUcTm0Qr69B4Z6F81dtevnWOYRItHOhIRIX51 3dlVfA0uw8xnUmHxOuQBAHtMkG4gruC9UNwirCnA= From: "Paul E. Jones" To: "'Bob Wyman'" References: <05d001cd01a7$3cbb0c70$b6312550$@packetizer.com> In-Reply-To: Date: Wed, 14 Mar 2012 15:38:18 -0400 Message-ID: <017201cd021a$02320450$06960cf0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0173_01CD01F8.7B21C3E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIpr5CrRpL27TKx2eu4GfpqVU03ngIPbM1elaBXCAA= Content-Language: en-us Cc: webfinger@googlegroups.com, apps-discuss@ietf.org Subject: Re: [apps-discuss] Webfinger: acct "link relation" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 14 Mar 2012 19:38:21 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0173_01CD01F8.7B21C3E0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Bob, I want to improve the language in the introduction of that section, but I do think it is reasonable to assume that a user with a given email address may have an account with the same name on the server. There are instances where that would not be the case, but a 404 would be returned in that instance. It has been suggested that perhaps making this assumption would lead to returning information for the wrong person. That's possible, but I believe Webfinger might help to encourage domain owners from putting themselves in that situation. If user@example.com is a non-email account at that domain, there should not be a real user account with the same name, but belonging to a different person. It's simply poor practice. It confuses humans. We could get this straight in protocol, but it would never address the confusion in the human mind. In any case, I want the "acct" link relation to refer to other accounts, not necessarily the "right" account. The wording was not clear on that. Here's the proposed wording changes for the first 3 paragraphs (now reduced to two): Users of some services might have an acct URI that looks significantly different from their email address, perhaps using entirely different domain names. It is also possible that a user has multiple accounts that a Webfinger client may want to query. As such, it is useful to allow one user account to refer to one or more other account identifiers. To make a reference to other user accounts, one uses the "acct" link relation. Consider the following example. I welcome any textual changes to make this clearer. Paul From: bobwyman@gmail.com [mailto:bobwyman@gmail.com] On Behalf Of Bob Wyman Sent: Wednesday, March 14, 2012 11:26 AM To: Paul E. Jones Cc: apps-discuss@ietf.org; webfinger@googlegroups.com Subject: Re: [apps-discuss] Webfinger: acct "link relation" Thanks for mentioning section 6. I have been puzzling over this for some time now. It seems to me that if Alice receives an email from "bob@example.net" then, because there is no certain equivalence of mailto: and acct: identifiers, Alice should query for "mailto:bob@example.net" in order to discover "acct:bob@example.com " rather than assuming similarity between the mailto: and acct: identifiers and first querying for "acct:bob@example.net ." It must be remembered that WebFinger acct: identifiers need not be the same as or even similar to mailto: identifiers. Additionly, similar identifiers, such as "mailto:bob@example.net" and "acct:bob@example.net ," need not identify the same person or entity. (although it would be really, really smart if they did...) Given that in most cases, "acct:xxx" and "mailto:xxx" will, in fact, be associated with the same entity, it would be a bit of a nuisance to require the multi-step discovery process outlined above. Especially since we know that mapping from mailto: to acct: will be a very, very common requirement. Thus, it seems reasonable to me that we would add a few new rules: 1) If the server responding to a request for mailto: information is also the authoritative server for the WebFinger acct information, it may provide that information as long as it also provides a link with rel=acct element to identify the acct:. In this case, it should be understood that any information provided (other than the link that shows the relationship between the identifiers) is associated with the acct: identifier, not with the mailto: identifier. This server-side automatic mapping rule could, of course, be generalized to say that whenever the server knows the exact mapping from any URI, no matter what scheme it uses, to a corresponding acct: URI, it may perform the translation as long as it provides an appropriate link with (rel=acct) in its response. 2) To enable clients to do URI translations, it would be useful for servers to be able to describe those translations which are easily performed. For instance, for servers that maintain a one-to-one relationship between mailto: and acct: URIs, it should be possible for the server to publish in its host metadata the mapping between the two identifiers. Thus, we might have an XRD like the following: The XRD above not only describes the general template for forming queries, it gives specific instructions re optional pre-translation for mailto: URIs. Clearly, more complex template mappings would be interesting and often useful, but perhaps too complex. bob wyman On Wed, Mar 14, 2012 at 1:56 AM, Paul E. Jones wrote: > Folks, > > > > In the latest Webfinger draft, we introduced a "acct" link relation named > "acct" (see Section 6). The intent with that link relation was to allow for > one to inform a webfinger client that a user's account information may be > retrieved elsewhere. I believe this will be important, since a user might > have more than one account and this might serve as a means of associating > them. Certainly, it would be a way of retrieving information from those > other accounts automatically. > > > > Perhaps calling the new link relation "acct" is too restrictive, though. If > one used Webfinger to query other kinds of information other than a user's > account, there may still be a need/desire to refer the Webfinger client to > other resources. > > > > What do you think about changing this section such that the link relation is > renamed to "seealso"? This would still be useful when querying an acct URI, > but would also be useful when querying any URI since it is more generic. > > > > Do note that "seealso" would be different than the "alternate" link > relation. It would not refer to alternative information, but would refer to > supplemental information. In practice, the supplemental information may be > the more informative since the bulk of the information related to a user > might be held under a different account. > > > > Your thoughts? > > > > Paul > > > > > > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > ------=_NextPart_000_0173_01CD01F8.7B21C3E0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Bob,

 

I want to improve the language in the introduction of that section, = but I do think it is reasonable to assume that a user with a given email = address may have an account with the same name on the = server.  There are instances where that would not be the case, but = a 404 would be returned in that instance.  It has been suggested = that perhaps making this assumption would lead to returning information = for the wrong person.  That’s possible, but I believe = Webfinger might help to encourage domain owners from putting themselves = in that situation.  If user@example.com is a non-email account at = that domain, there should not be a real user account with the same name, = but belonging to a different person.  It’s simply poor = practice.  It confuses humans.  We could get this straight in = protocol, but it would never address the confusion in the human = mind.

 

In any case, I want the “acct” link relation to refer to = other accounts, not necessarily the “right” account.  = The wording was not clear on that.  Here’s the proposed = wording changes for the first 3 paragraphs (now reduced to = two):

 

Users of some services might have an acct URI that looks = significantly different from their email address, perhaps using entirely = different domain names.  It is also possible that a user has = multiple accounts that a Webfinger client may want to query.  As = such, it is useful to allow one user account to refer to one or more = other account identifiers.

 

To make a reference to other user accounts, one uses the = “acct” link relation.  Consider the following = example.

 

I welcome any textual changes to make this = clearer.

 

Paul

 

From:= = bobwyman@gmail.com [mailto:bobwyman@gmail.com] On Behalf Of Bob = Wyman
Sent: Wednesday, March 14, 2012 11:26 AM
To: = Paul E. Jones
Cc: apps-discuss@ietf.org; = webfinger@googlegroups.com
Subject: Re: [apps-discuss] = Webfinger: acct "link = relation"

 

Thanks for = mentioning section 6. I have been puzzling over this for some time now. = It seems to me that if Alice receives an email from "bob@example.net" then, because = there is no certain equivalence of mailto: and acct: identifiers, Alice = should query for "mailto:bob@example.net" in order to = discover "acct:bob@example.com" = rather than assuming similarity between the mailto: and acct: = identifiers and first querying for "acct:bob@example.net." =
It must be remembered that WebFinger acct: identifiers need not be = the same as or even similar to mailto: identifiers. Additionly, similar = identifiers, such as "mailto:bob@example.net" and "acct:bob@example.net," = need not identify the same person or entity. (although it would be = really, really smart if they did...)

Given that in most cases, = "acct:xxx" and "mailto:xxx" will, in fact, be associated with the = same entity, it would be a bit of a nuisance to require the multi-step = discovery process outlined above. Especially since we know that mapping = from mailto: to acct: will be a very, very common requirement. Thus, it = seems reasonable to me that we would add a few new rules:
1) If the = server responding to a request for mailto: information is also the = authoritative server for the WebFinger acct information, it may provide = that information as long as it also provides a link with rel=3Dacct = element to identify the acct:. In this case, it should be understood = that any information provided (other than the link that shows the = relationship between the identifiers) is associated with the acct: = identifier, not with the mailto: identifier. This server-side automatic = mapping rule could, of course, be generalized to say that whenever the = server knows the exact mapping from any URI, no matter what scheme it = uses, to a corresponding acct: URI, it may perform the translation as = long as it provides an appropriate link with (rel=3Dacct) in its = response.
2) To enable clients to do URI translations, it would be = useful for servers to be able to describe those translations which are = easily performed. For instance, for servers that maintain a one-to-one = relationship between mailto: and acct: URIs, it should be possible for = the server to publish in its host metadata the mapping between the two = identifiers. Thus, we might have an XRD like the = following:

    <XRD xmlns=3D"http://docs.oasis-open=
.org/ns/xri/xrd-1.0">
       <Link =
rel=3D"lrdd"
       &nbs=
p;     =
type=3D"application/xrd+xml"
       &nbs=
p;     template=3D"https://example.com/lr=
dd/?uri=3D{uri}"/>
       <Link =
rel=3D"mailto2acct" =
template=3D"acct:{mailto_id}"/>

     =
</XRD>

 

The XRD above not only describes the general template = for forming queries, it gives specific instructions re optional = pre-translation for mailto: URIs. Clearly, more complex template = mappings would be interesting and often useful, but perhaps too = complex.

bob wyman

On Wed, Mar 14, 2012 at 1:56 AM, Paul = E. Jones <paulej@packetizer.com> = wrote:
> Folks,
>
>  
>
> In the = latest Webfinger draft, we introduced a “acct” link relation = named
> “acct” (see Section 6).  The intent with = that link relation was to allow for
> one to inform a webfinger = client that a user’s account information may be
> retrieved = elsewhere.  I believe this will be important, since a user = might
> have more than one account and this might serve as a means = of associating
> them.  Certainly, it would be a way of = retrieving information from those
> other accounts = automatically.
>
>  
>
> Perhaps calling = the new link relation “acct” is too restrictive, = though.  If
> one used Webfinger to query other kinds of = information other than a user’s
> account, there may still = be a need/desire to refer the Webfinger client to
> other = resources.
>
>  
>
> What do you think = about changing this section such that the link relation is
> = renamed to “seealso”?  This would still be useful when = querying an acct URI,
> but would also be useful when querying any = URI since it  is more generic.
>
> =  
>
> Do note that “seealso” would be = different than the “alternate” link
> relation.  = It would not refer to alternative information, but would refer = to
> supplemental information.  In practice, the supplemental = information may be
> the more informative since the bulk of the = information related to a user
> might be held under a different = account.
>
>  
>
> Your = thoughts?
>
>  
>
> Paul
>
> =  
>
>  
>
> =  
>
>
> = _______________________________________________
> apps-discuss = mailing list
> apps-discuss@ietf.org
> = https://www.i= etf.org/mailman/listinfo/apps-discuss
>

------=_NextPart_000_0173_01CD01F8.7B21C3E0-- From msk@cloudmark.com Wed Mar 14 12:49:06 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1951721F8629 for ; Wed, 14 Mar 2012 12:49:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.603 X-Spam-Level: X-Spam-Status: No, score=-102.603 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FI9r1kwqfGKw for ; Wed, 14 Mar 2012 12:49:05 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 66FA221F8617 for ; Wed, 14 Mar 2012 12:48:59 -0700 (PDT) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by EXCH-HTCAS901.corp.cloudmark.com ([fe80::2966:6846:8d89:4681%12]) with mapi id 14.01.0355.002; Wed, 14 Mar 2012 12:48:58 -0700 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Thread-Topic: [apps-discuss] Malformed mail guidance document (draft-ietf-appsawg-malformed-mail) Thread-Index: AQHM92cFazIv3ot2y0mMzxumQABBTpZqR4nQ Date: Wed, 14 Mar 2012 19:48:58 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392808B2E2@exch-mbx901.corp.cloudmark.com> References: <9452079D1A51524AA5749AD23E00392806D278@exch-mbx901.corp.cloudmark.com> <2183832.0qjo89hoBY@scott-latitude-e6320> In-Reply-To: <2183832.0qjo89hoBY@scott-latitude-e6320> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [apps-discuss] Malformed mail guidance document (draft-ietf-appsawg-malformed-mail) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 14 Mar 2012 19:49:06 -0000 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] On Behalf Of Scott Kitterman > Sent: Wednesday, February 29, 2012 8:52 PM > To: apps-discuss@ietf.org > Subject: Re: [apps-discuss] Malformed mail guidance document (draft-ietf-= appsawg-malformed-mail) >=20 > On Wednesday, February 29, 2012 07:56:41 PM Murray S. Kucherawy wrote: > > Hi all, > ... > > When it reappears, I'd love to see some additional review comments, > > especially the submission of new cases that should be included in the > > first version. I imagine there are many. >=20 > One thought that immediately came to mind is that it might be useful to > mention case changes in header fields in paragraph 7. "Helpful" MTAs > doing this have been responsible for more than a few hard to > troubleshoot DKIM failures. That's certainly a concern but I'm not sure it's on topic for this draft. = Altering header field name cases is not strictly a malformation, it's a que= stionable handling choice that doesn't really alter the semantics or interp= retation of the message in a meaningful way. And DKIM does have a way (rel= axed header canonicalization mode) to deal with it. A separate document that lists annoying MTA habits which don't actually res= ult in non-compliant messages would quite possibly be a lot larger than thi= s one. :-) -MSK From msk@cloudmark.com Wed Mar 14 12:50:49 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 651B321F862F for ; Wed, 14 Mar 2012 12:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.603 X-Spam-Level: X-Spam-Status: No, score=-102.603 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S7pwLY9wT-OR for ; Wed, 14 Mar 2012 12:50:49 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 062D521F84E6 for ; Wed, 14 Mar 2012 12:50:49 -0700 (PDT) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by EXCH-HTCAS901.corp.cloudmark.com ([fe80::2966:6846:8d89:4681%12]) with mapi id 14.01.0355.002; Wed, 14 Mar 2012 12:50:48 -0700 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Thread-Topic: I-D Action: draft-ietf-appsawg-greylisting-05.txt Thread-Index: AQHM8ZI/NfjHLgzFXkyZMIHKh9XCxJZKvjfggB+V/gA= Date: Wed, 14 Mar 2012 19:50:47 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392808B2F9@exch-mbx901.corp.cloudmark.com> References: <20120222184536.6635.42117.idtracker@ietfa.amsl.com> <9452079D1A51524AA5749AD23E003928042C26@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E003928042C26@exch-mbx901.corp.cloudmark.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-greylisting-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 14 Mar 2012 19:50:49 -0000 Some offlist feedback suggests adding this to the end of the list in Sectio= n 5: 7. An ADMD's own submission service (see [SUBMISSION]) SHOULD NOT apply greylisting checks. Alternately, an ADMD could simply exempt internal IP addresses from being greylisted, as described in the previous point. Seems reasonable to me. Others? -MSK From bobwyman@gmail.com Wed Mar 14 13:00:44 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 502F721F87F7 for ; Wed, 14 Mar 2012 13:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.405 X-Spam-Level: X-Spam-Status: No, score=-1.405 tagged_above=-999 required=5 tests=[AWL=-0.229, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x3B+m-6H75Ct for ; Wed, 14 Mar 2012 13:00:43 -0700 (PDT) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by ietfa.amsl.com (Postfix) with ESMTP id BE3FD21F87F3 for ; Wed, 14 Mar 2012 13:00:42 -0700 (PDT) Received: by yhgm50 with SMTP id m50so3348425yhg.27 for ; Wed, 14 Mar 2012 13:00:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=4sAc71wIFzGZ7UkONK3c92Ka2hM1RN3YQ1KJlRApYjc=; b=04oOVgcTaxPeonAHj4IG0ZeQyVdKyK5Wa3Z3sLqGxdKaPX+LrbjEsigLDBxaDMQ/F2 zkECY/G4CyooQ9hi/n6gJvhQLzshMkzDwkfeCcfzgHv8RsnGfZmgt75jR+9kNmWifqfg 0ihCU0sC7SIBCJqQCZqWuJ+I8x9AKrPlIfUtKNECJkGOjgylFk9lf/Qh4SxdWg91nRhX ZT1JNKHCWzxn0aw6PCk/nE2f7Em/2t6BE8YdMuXHZ2Jz8HCk3VPfBfKInopqvIhLrcsz eHCGFL6hLCQ7htkxp3CuR6JbVGP7dE+SrImb2X88gpa5MjtgQAGoK5oLNA4G9vL9/DDi 5NqA== MIME-Version: 1.0 Received: by 10.224.220.16 with SMTP id hw16mr4548135qab.89.1331755242298; Wed, 14 Mar 2012 13:00:42 -0700 (PDT) Sender: bobwyman@gmail.com Received: by 10.229.157.16 with HTTP; Wed, 14 Mar 2012 13:00:42 -0700 (PDT) In-Reply-To: <017201cd021a$02320450$06960cf0$@packetizer.com> References: <05d001cd01a7$3cbb0c70$b6312550$@packetizer.com> <017201cd021a$02320450$06960cf0$@packetizer.com> Date: Wed, 14 Mar 2012 16:00:42 -0400 X-Google-Sender-Auth: ygqDxzWXuvEZLh2voOhmNsw79F4 Message-ID: From: Bob Wyman To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=20cf3074b518251b6e04bb396efe Cc: webfinger@googlegroups.com, apps-discuss@ietf.org Subject: Re: [apps-discuss] Webfinger: acct "link relation" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 14 Mar 2012 20:00:44 -0000 --20cf3074b518251b6e04bb396efe Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Paul, If one may assume that mailto:user@example.com and acct:user@example.comare associated with the same user, shouldn't it be stated in the RFC that clients MAY assume this and that servers MUST NOT allow for the assumption to be invalid? Certainly, allowing the two identifiers to be associated with different people will cause never-ending confusion, however, if we want to prevent the confusion, then we should explicitly state that this situation should not arise. Note: I support your efforts to clarify the situation where a mailto:corresponds to a dissimilar acct:. Also, allowing user editing of WebFinger data, will drastically increase the utility of the protocol. bob wyman On Wed, Mar 14, 2012 at 3:38 PM, Paul E. Jones wrote= : > Bob,**** > > ** ** > > I want to improve the language in the introduction of that section, but I > do think it is reasonable to assume that a user with a given email addres= s > *may* have an account with the same name on the server. There are > instances where that would not be the case, but a 404 would be returned i= n > that instance. It has been suggested that perhaps making this assumption > would lead to returning information for the wrong person. That=92s possi= ble, > but I believe Webfinger might help to encourage domain owners from puttin= g > themselves in that situation. If user@example.com is a non-email account > at that domain, there should not be a real user account with the same nam= e, > but belonging to a different person. It=92s simply poor practice. It > confuses humans. We could get this straight in protocol, but it would > never address the confusion in the human mind.**** > > ** ** > > In any case, I want the =93acct=94 link relation to refer to other accoun= ts, > not necessarily the =93right=94 account. The wording was not clear on th= at. > Here=92s the proposed wording changes for the first 3 paragraphs (now red= uced > to two):**** > > ** ** > > Users of some services might have an acct URI that looks significantly > different from their email address, perhaps using entirely different doma= in > names. It is also possible that a user has multiple accounts that a > Webfinger client may want to query. As such, it is useful to allow one > user account to refer to one or more other account identifiers.**** > > ** ** > > To make a reference to other user accounts, one uses the =93acct=94 link > relation. Consider the following example.**** > > ** ** > > I welcome any textual changes to make this clearer.**** > > ** ** > > Paul**** > > ** ** > > *From:* bobwyman@gmail.com [mailto:bobwyman@gmail.com] *On Behalf Of *Bob > Wyman > *Sent:* Wednesday, March 14, 2012 11:26 AM > *To:* Paul E. Jones > *Cc:* apps-discuss@ietf.org; webfinger@googlegroups.com > *Subject:* Re: [apps-discuss] Webfinger: acct "link relation"**** > > ** ** > > Thanks for mentioning section 6. I have been puzzling over this for some > time now. It seems to me that if Alice receives an email from " > bob@example.net" then, because there is no certain equivalence of mailto:= and acct: identifiers, Alice should query for "mailto: > bob@example.net" in order to discover "acct:bob@example.com" rather than > assuming similarity between the mailto: and acct: identifiers and first > querying for "acct:bob@example.net." > It must be remembered that WebFinger acct: identifiers need not be the > same as or even similar to mailto: identifiers. Additionly, similar > identifiers, such as "mailto:bob@example.net" and "acct:bob@example.net," > need not identify the same person or entity. (although it would be really= , > really smart if they did...) > > Given that in most cases, "acct:xxx" and "mailto:xxx" will, in fact, be > associated with the same entity, it would be a bit of a nuisance to requi= re > the multi-step discovery process outlined above. Especially since we know > that mapping from mailto: to acct: will be a very, very common > requirement. Thus, it seems reasonable to me that we would add a few new > rules: > 1) If the server responding to a request for mailto: information is also > the authoritative server for the WebFinger acct information, it may provi= de > that information as long as it also provides a link with rel=3Dacct eleme= nt > to identify the acct:. In this case, it should be understood that any > information provided (other than the link that shows the relationship > between the identifiers) is associated with the acct: identifier, not wit= h > the mailto: identifier. This server-side automatic mapping rule could, of > course, be generalized to say that whenever the server knows the exact > mapping from any URI, no matter what scheme it uses, to a corresponding > acct: URI, it may perform the translation as long as it provides an > appropriate link with (rel=3Dacct) in its response. > 2) To enable clients to do URI translations, it would be useful for > servers to be able to describe those translations which are easily > performed. For instance, for servers that maintain a one-to-one > relationship between mailto: and acct: URIs, it should be possible for > the server to publish in its host metadata the mapping between the two > identifiers. Thus, we might have an XRD like the following:**** > > **** > > > type=3D"application/xrd+xml"**** > > template=3D"https://example.com/lrdd/?uri=3D{uri}"/>**** > > ** > > **** > > **** > > ** ** > > The XRD above not only describes the general template for forming queries= , > it gives specific instructions re optional pre-translation for mailto:URI= s. Clearly, more complex template mappings would be interesting and > often useful, but perhaps too complex. > > bob wyman > > On Wed, Mar 14, 2012 at 1:56 AM, Paul E. Jones > wrote: > > Folks, > > > > > > > > In the latest Webfinger draft, we introduced a =93acct=94 link relation= named > > =93acct=94 (see Section 6). The intent with that link relation was to = allow > for > > one to inform a webfinger client that a user=92s account information ma= y be > > retrieved elsewhere. I believe this will be important, since a user > might > > have more than one account and this might serve as a means of associati= ng > > them. Certainly, it would be a way of retrieving information from thos= e > > other accounts automatically. > > > > > > > > Perhaps calling the new link relation =93acct=94 is too restrictive, > though. If > > one used Webfinger to query other kinds of information other than a > user=92s > > account, there may still be a need/desire to refer the Webfinger client > to > > other resources. > > > > > > > > What do you think about changing this section such that the link > relation is > > renamed to =93seealso=94? This would still be useful when querying an = acct > URI, > > but would also be useful when querying any URI since it is more generi= c. > > > > > > > > Do note that =93seealso=94 would be different than the =93alternate=94 = link > > relation. It would not refer to alternative information, but would > refer to > > supplemental information. In practice, the supplemental information ma= y > be > > the more informative since the bulk of the information related to a use= r > > might be held under a different account. > > > > > > > > Your thoughts? > > > > > > > > Paul > > > > > > > > > > > > > > > > > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss > >**** > --20cf3074b518251b6e04bb396efe Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Paul,
If one may assume that mailto:user@example.com and acct:u= ser@example.com are associated with the same user, shouldn't it be = stated in the RFC that clients MAY assume this and that servers MUST NOT al= low for the assumption to be invalid? Certainly, allowing the two identifie= rs to be associated with different people will cause never-ending confusion= , however, if we want to prevent the confusion, then we should explicitly s= tate that this situation should not arise.

Note: I support your efforts to clarify the situation w= here a mailto: corresponds to a dissimilar acct:. Also, allowing user editi= ng of WebFinger data, will drastically increase the utility of the protocol= .

bob wyman

On Wed, Mar= 14, 2012 at 3:38 PM, Paul E. Jones <paulej@packetizer.com> wrote:

Bob,

=A0

I want to improve the language in the introdu= ction of that section, but I do think it is reasonable to assume that a use= r with a given email address may have an account with the same name = on the server.=A0 There are instances where that would not be the case, but= a 404 would be returned in that instance.=A0 It has been suggested that pe= rhaps making this assumption would lead to returning information for the wr= ong person.=A0 That=92s possible, but I believe Webfinger might help to enc= ourage domain owners from putting themselves in that situation.=A0 If user@example.com is a = non-email account at that domain, there should not be a real user account w= ith the same name, but belonging to a different person.=A0 It=92s simply po= or practice.=A0 It confuses humans.=A0 We could get this straight in protoc= ol, but it would never address the confusion in the human mind.

=A0<= /p>

In any case, I want th= e =93acct=94 link relation to refer to other accounts, not necessarily the = =93right=94 account.=A0 The wording was not clear on that.=A0 Here=92s the = proposed wording changes for the first 3 paragraphs (now reduced to two):

=A0<= /p>

Users of some services might have an acct URI that looks significantly= different from their email address, perhaps using entirely different domai= n names.=A0 It is also possible that a user has multiple accounts that a We= bfinger client may want to query.=A0 As such, it is useful to allow one use= r account to refer to one or more other account identifiers.<= /span>

To make a reference to other user accounts,= one uses the =93acct=94 link relation.=A0 Consider the following example.<= u>

=A0<= /p>

I welcome any textual = changes to make this clearer.

=A0<= /p>

Paul

=A0<= /p>

From: bobwyman@gmai= l.com [mailto:b= obwyman@gmail.com] On Behalf Of Bob Wyman
Sent: Wednesday, March 14, 2012 11:26 AM
To: Paul E. Jones=
Cc: a= pps-discuss@ietf.org; webfinger@googlegroups.com
Subject: Re: [apps-discuss] Webfinger: acct "link relation"= ;

=A0

Thanks for mentioning = section 6. I have been puzzling over this for some time now. It seems to me= that if Alice receives an email from "bob@example.net" then, because there is no c= ertain equivalence of mailto: and acct: identifiers, Alice should query for= "mailto:bob@exam= ple.net" in order to discover "acct:bob@example.com" rather than as= suming similarity between the mailto: and acct: identifiers and first query= ing for "a= cct:bob@example.net."
It must be remembered that WebFinger acct: identifiers need not be the same= as or even similar to mailto: identifiers. Additionly, similar identifiers= , such as "mailto:bob@example.net" and "acct:bob@example.net," need not identify the= same person or entity. (although it would be really, really smart if they = did...)

Given that in most cases, "acct:xxx" and "mailto:xxx" will, in fact, be associate= d with the same entity, it would be a bit of a nuisance to require the mult= i-step discovery process outlined above. Especially since we know that mapp= ing from mailto: to acct: will be a very, very common requirement. Thus, it= seems reasonable to me that we would add a few new rules:
1) If the server responding to a request for mailto: information is also th= e authoritative server for the WebFinger acct information, it may provide t= hat information as long as it also provides a link with rel=3Dacct element = to identify the acct:. In this case, it should be understood that any infor= mation provided (other than the link that shows the relationship between th= e identifiers) is associated with the acct: identifier, not with the mailto= : identifier. This server-side automatic mapping rule could, of course, be = generalized to say that whenever the server knows the exact mapping from an= y URI, no matter what scheme it uses, to a corresponding acct: URI, it may = perform the translation as long as it provides an appropriate link with (re= l=3Dacct) in its response.
2) To enable clients to do URI translations, it would be useful for servers= to be able to describe those translations which are easily performed. For = instance, for servers that maintain a one-to-one relationship between mailt= o: and acct: URIs, it should be possible for the server to publish in its h= ost metadata the mapping between the two identifiers. Thus, we might have a= n XRD like the following:

=A0=A0=A0 <XRD xmlns=3D"=
htt=
p://docs.oasis-open.org/ns/xri/xrd-1.0">
=A0=A0=A0=A0=A0=A0 <Link rel=
=3D"lrdd"


=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
type=3D"application/xrd+xml"
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 template=
=3D"https://example.com/lrdd/?uri=3D{uri}"/>


=A0 =A0 =A0 =A0<Link rel=3D&quo=
t;mailto2acct" template=3D"acct:{mailto_id}"/>=



=A0=A0=A0=A0 </XRD>

=A0

The XRD above not only describes the general template for forming queries, = it gives specific instructions re optional pre-translation for mailto: URIs= . Clearly, more complex template mappings would be interesting and often us= eful, but perhaps too complex.

bob wyman

On Wed, Mar 14, 2012 at 1:56 AM, Paul E. Jones <paulej@packetizer.c= om> wrote:
> Folks,
>
> =A0
>
> In the= latest Webfinger draft, we introduced a =93acct=94 link relation named
> =93acct=94 (see Section 6).=A0 The intent with that link relation was = to allow for
> one to inform a webfinger client that a user=92s accou= nt information may be
> retrieved elsewhere.=A0 I believe this will b= e important, since a user might
> have more than one account and this might serve as a means of associat= ing
> them.=A0 Certainly, it would be a way of retrieving information= from those
> other accounts automatically.
>
> =A0
&g= t;
> Perhaps calling the new link relation =93acct=94 is too restrictive, t= hough.=A0 If
> one used Webfinger to query other kinds of information= other than a user=92s
> account, there may still be a need/desire to= refer the Webfinger client to
> other resources.
>
> =A0
>
> What do you think= about changing this section such that the link relation is
> renamed= to =93seealso=94?=A0 This would still be useful when querying an acct URI,=
> but would also be useful when querying any URI since it=A0 is more gen= eric.
>
> =A0
>
> Do note that =93seealso=94 would = be different than the =93alternate=94 link
> relation.=A0 It would no= t refer to alternative information, but would refer to
> supplemental information.=A0 In practice, the supplemental information= may be
> the more informative since the bulk of the information rela= ted to a user
> might be held under a different account.
>
> =A0
>
> Your thoughts?
>
> =A0
>
>= Paul
>
> =A0
>
> =A0
>
> =A0
>>
> _______________________________________________
> apps= -discuss mailing list
> apps-discus= s@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-dis= cuss
>


--20cf3074b518251b6e04bb396efe-- From dhc@dcrocker.net Wed Mar 14 13:11:01 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DAA421E8010 for ; Wed, 14 Mar 2012 13:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.607 X-Spam-Level: X-Spam-Status: No, score=-6.607 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5bkGcNxj63ow for ; Wed, 14 Mar 2012 13:10:56 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0A59C21E800E for ; Wed, 14 Mar 2012 13:10:56 -0700 (PDT) Received: from [192.168.1.11] (adsl-67-127-58-62.dsl.pltn13.pacbell.net [67.127.58.62]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q2EKAn8N004724 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Mar 2012 13:10:55 -0700 Message-ID: <4F60FB31.80209@dcrocker.net> Date: Wed, 14 Mar 2012 13:10:25 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <20120222184536.6635.42117.idtracker@ietfa.amsl.com> <9452079D1A51524AA5749AD23E003928042C26@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E00392808B2F9@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E00392808B2F9@exch-mbx901.corp.cloudmark.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Wed, 14 Mar 2012 13:10:55 -0700 (PDT) Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-greylisting-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 20:11:01 -0000 On 3/14/2012 12:50 PM, Murray S. Kucherawy wrote: > 7. An ADMD's own submission service (see [SUBMISSION]) SHOULD NOT > apply greylisting checks. Alternately, an ADMD could simply > exempt internal IP addresses from being greylisted, as described > in the previous point. > > Seems reasonable to me. Others? I think the general form of this is: 7. Greylisting SHOULD NOT be applied by an ADMD's submission service (see [SUBMISSION]) for authenticated client hosts. Authentication can include whatever mechanisms are deemed appropriate for the ADMD, such as known internal IP addresses, SASL or the like. The "alternately" is confusing to me. Is it meant to apply to non-submission services? If so, then this rule needs something broader, such as: 7. Greylisting SHOULD NOT be applied to client hosts internal to the ADMD or otherwise part of the ADMD's operation, such as having membership on a list of exempt IP Addresses. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From msk@cloudmark.com Wed Mar 14 13:12:48 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB33D21E8024 for ; Wed, 14 Mar 2012 13:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.603 X-Spam-Level: X-Spam-Status: No, score=-102.603 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9b+xRtfHrv6r for ; Wed, 14 Mar 2012 13:12:48 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id 45EA421E800E for ; Wed, 14 Mar 2012 13:12:48 -0700 (PDT) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Wed, 14 Mar 2012 13:12:47 -0700 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Thread-Topic: [apps-discuss] I-D Action: draft-ietf-appsawg-greylisting-05.txt Thread-Index: AQHM8ZI/NfjHLgzFXkyZMIHKh9XCxJZKvjfggB+V/gCAAHr7gP//iy+g Date: Wed, 14 Mar 2012 20:12:47 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392808B3A5@exch-mbx901.corp.cloudmark.com> References: <20120222184536.6635.42117.idtracker@ietfa.amsl.com> <9452079D1A51524AA5749AD23E003928042C26@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E00392808B2F9@exch-mbx901.corp.cloudmark.com> <4F60FB31.80209@dcrocker.net> In-Reply-To: <4F60FB31.80209@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-greylisting-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 14 Mar 2012 20:12:48 -0000 > -----Original Message----- > From: Dave Crocker [mailto:dhc@dcrocker.net] > Sent: Wednesday, March 14, 2012 1:10 PM > To: Murray S. Kucherawy > Cc: apps-discuss@ietf.org > Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-greylisting-05= .txt >=20 > I think the general form of this is: >=20 > 7. Greylisting SHOULD NOT be applied by an ADMD's submission > service (see > [SUBMISSION]) for authenticated client hosts. Authentication can > include whatever mechanisms are deemed appropriate for the ADMD, such > as known internal IP addresses, SASL or the like. >=20 > The "alternately" is confusing to me. Is it meant to apply to non- > submission services? If so, then this rule needs something broader, > such as: >=20 > 7. Greylisting SHOULD NOT be applied to client hosts internal to > the ADMD or otherwise part of the ADMD's operation, such as having > membership on a list of exempt IP Addresses. I think your first restatement is more what I had in mind. -MSK From barryleiba.mailing.lists@gmail.com Wed Mar 14 13:13:50 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 958B221F84F6 for ; Wed, 14 Mar 2012 13:13:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.984 X-Spam-Level: X-Spam-Status: No, score=-102.984 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JkdweOVxJDAG for ; Wed, 14 Mar 2012 13:13:49 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9506821F84A6 for ; Wed, 14 Mar 2012 13:13:49 -0700 (PDT) Received: by yenm5 with SMTP id m5so2559810yen.31 for ; Wed, 14 Mar 2012 13:13:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=qh1VbpwANrF8X4QAG5DBVEtvy1+dK8FvwSbuTafxtq4=; b=PKLqpWPeiY8g7IBxabYotsBfrSkhoS5ts1K9HaSDjnTi/OO6IAesM8KtAo+fUiceuF InVTbhH99kGRUUdrCXOHy0iZs7SUIrVtmY7jcLUy4vLsQjtceL0I/plrlKCsEWIKeqbw U669FyO/9G9aXiMr7zqwmlQPWRN15B2cOMy5o6hIZkmC5CheJaEHGOW0PPbYxWml4grY yK9W833AOit9BtMfTe3sH3oQYK9oV8wkByE1syUUYttnH0KEaB9lt0XVelkQcQwLYyFP pQPfF1m6f/JTIIE1C5cRjSvtKwqXM05lJ4gDouabX7l3yLQ3X7fNUNtUmHEaOx9QxEed eq8g== MIME-Version: 1.0 Received: by 10.236.184.129 with SMTP id s1mr4808322yhm.21.1331756021719; Wed, 14 Mar 2012 13:13:41 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.106.16 with HTTP; Wed, 14 Mar 2012 13:13:41 -0700 (PDT) In-Reply-To: <4F60FB31.80209@dcrocker.net> References: <20120222184536.6635.42117.idtracker@ietfa.amsl.com> <9452079D1A51524AA5749AD23E003928042C26@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E00392808B2F9@exch-mbx901.corp.cloudmark.com> <4F60FB31.80209@dcrocker.net> Date: Wed, 14 Mar 2012 16:13:41 -0400 X-Google-Sender-Auth: sX5dF5I2OD8_0rpdpExqUO5iLNU Message-ID: From: Barry Leiba To: dcrocker@bbiw.net Content-Type: text/plain; charset=ISO-8859-1 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-greylisting-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 14 Mar 2012 20:13:50 -0000 > The "alternately" is confusing to me. Maybe because it should be "alternatively"; they're not the same thing. I have this image of applying greylisting to odd-numbered submissions, but not to even-numbered ones. Barry, as pedant From dhc@dcrocker.net Wed Mar 14 13:18:45 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A61B21F85F8 for ; Wed, 14 Mar 2012 13:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.607 X-Spam-Level: X-Spam-Status: No, score=-6.607 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WMRHGkirQST4 for ; Wed, 14 Mar 2012 13:18:45 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6B5EA21F8462 for ; Wed, 14 Mar 2012 13:18:43 -0700 (PDT) Received: from [192.168.1.11] (adsl-67-127-58-62.dsl.pltn13.pacbell.net [67.127.58.62]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q2EKIZf1005013 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Mar 2012 13:18:40 -0700 Message-ID: <4F60FD03.2070407@dcrocker.net> Date: Wed, 14 Mar 2012 13:18:11 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Barry Leiba References: <20120222184536.6635.42117.idtracker@ietfa.amsl.com> <9452079D1A51524AA5749AD23E003928042C26@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E00392808B2F9@exch-mbx901.corp.cloudmark.com> <4F60FB31.80209@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Wed, 14 Mar 2012 13:18:40 -0700 (PDT) Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-greylisting-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 20:18:45 -0000 On 3/14/2012 1:13 PM, Barry Leiba wrote: >> The "alternately" is confusing to me. > > Maybe because it should be "alternatively"; they're not the same thing. > > I have this image of applying greylisting to odd-numbered submissions, > but not to even-numbered ones. doesn't help. I don't really understand what is being alternated or sequenced or whatever. That is, I'm not clear what the overriding scope/principal of the rule is. There seem to be multiple possibilities, as I indicated. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dhc@dcrocker.net Wed Mar 14 13:23:46 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A883621F8629 for ; Wed, 14 Mar 2012 13:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.606 X-Spam-Level: X-Spam-Status: No, score=-6.606 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wmHCjHUfUf6b for ; Wed, 14 Mar 2012 13:23:46 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 25D7F21F8622 for ; Wed, 14 Mar 2012 13:23:46 -0700 (PDT) Received: from [192.168.1.11] (adsl-67-127-58-62.dsl.pltn13.pacbell.net [67.127.58.62]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q2EKNe0d005136 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 14 Mar 2012 13:23:45 -0700 Message-ID: <4F60FE34.90807@dcrocker.net> Date: Wed, 14 Mar 2012 13:23:16 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20120222184536.6635.42117.idtracker@ietfa.amsl.com> <9452079D1A51524AA5749AD23E003928042C26@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E00392808B2F9@exch-mbx901.corp.cloudmark.com> <4F60FB31.80209@dcrocker.net> <9452079D1A51524AA5749AD23E00392808B3A5@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E00392808B3A5@exch-mbx901.corp.cloudmark.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Wed, 14 Mar 2012 13:23:46 -0700 (PDT) Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-greylisting-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 20:23:46 -0000 On 3/14/2012 1:12 PM, Murray S. Kucherawy wrote: > I think your first restatement is more what I had in mind. goodie. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From ned.freed@mrochek.com Wed Mar 14 15:52:43 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21B2011E8089 for ; Wed, 14 Mar 2012 15:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z5OGhitU8CtU for ; Wed, 14 Mar 2012 15:52:42 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 1AD8411E8081 for ; Wed, 14 Mar 2012 15:52:42 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OD40Q1Y3QO00PK4E@mauve.mrochek.com> for apps-discuss@ietf.org; Wed, 14 Mar 2012 15:52:35 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OCPMUVDUMO00ZUIL@mauve.mrochek.com>; Wed, 14 Mar 2012 15:52:28 -0700 (PDT) Message-id: <01OD40PXSWDK00ZUIL@mauve.mrochek.com> Date: Wed, 14 Mar 2012 15:36:06 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Wed, 14 Mar 2012 19:48:58 +0000" <9452079D1A51524AA5749AD23E00392808B2E2@exch-mbx901.corp.cloudmark.com> MIME-version: 1.0 Content-type: TEXT/PLAIN References: <9452079D1A51524AA5749AD23E00392806D278@exch-mbx901.corp.cloudmark.com> <2183832.0qjo89hoBY@scott-latitude-e6320> <9452079D1A51524AA5749AD23E00392808B2E2@exch-mbx901.corp.cloudmark.com> To: "Murray S. Kucherawy" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1331765559; bh=GJeUhgKy4MySwP+//oChUc1PuJXLCiIqYlCQyFkn6Dc=; h=Cc:Message-id:Date:From:Subject:In-reply-to:MIME-version: Content-type:References:To; b=haAIV/J7rsHahkp04D35ZpRBwTDQRrJCeqjJ1W+EavsWarl7A3NTU94t1o9Drc2Ef fPFfXxcq7f0WEosDHjXE5TieQEIMbyIFdloAnB9DKH5kCKwWC/Wywyi5pQDN3clEgL EYju3cowqJ4VV+o7MFOI7f62X8Gml9CK0ulvwwk0= Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Malformed mail guidance document (draft-ietf-appsawg-malformed-mail) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 14 Mar 2012 22:52:43 -0000 > > -----Original Message----- > > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Scott Kitterman > > Sent: Wednesday, February 29, 2012 8:52 PM > > To: apps-discuss@ietf.org > > Subject: Re: [apps-discuss] Malformed mail guidance document (draft-ietf-appsawg-malformed-mail) > > > > On Wednesday, February 29, 2012 07:56:41 PM Murray S. Kucherawy wrote: > > > Hi all, > > ... > > > When it reappears, I'd love to see some additional review comments, > > > especially the submission of new cases that should be included in the > > > first version. I imagine there are many. > > > > One thought that immediately came to mind is that it might be useful to > > mention case changes in header fields in paragraph 7. "Helpful" MTAs > > doing this have been responsible for more than a few hard to > > troubleshoot DKIM failures. > That's certainly a concern but I'm not sure it's on topic for this draft. Altering header field name cases is not strictly a malformation, it's a questionable handling choice that doesn't really alter the semantics or interpretation of the message in a meaningful way. And DKIM does have a way (relaxed header canonicalization mode) to deal with it. > A separate document that lists annoying MTA habits which don't actually result in non-compliant messages would quite possibly be a lot larger than this one. :-) Completely agree. This needs to focus on malformations that actually change RFC5322/MIME message semantics and which cause problems for end users. There's plenty of graund to cover here. If you want a header rewriting one that *does* affect end users, the one that immediately comes to mind isn't, or rather shouldn't, be a malformation per se, but some clients treat it as such: Some clients get all pissy unless headers appear in a certain order. I don't think mentioning specific clients is any help here (especially since it would involve some industry heavyweights who really should have known better), but a specific example of headers that have had ordering dependencies would be Content-Type: and Content-Transfer-Encoding. Most clients put CT before CTE, but not all MIME downgraders do, resulting in ... interesting behavior. Now, you can argue that this behavior malforms the MIME headers because MIME says header ordering must be preserved. OTOH, it doesn't really talk about the downgrading case, so it isn't clear this applies when downgrading. Another interesting example of header ordering issues shows up when Received: fields are stripped from messages. (This is unfortunately pretty common to have happen, especially at final delivery.) The obvious problem with this is good luck on tracing the message or figuring out where it was delayed, but a less obvious one shows up when some clients attempt to process Resent-* fields. It seems some of them depend on there being Received: fields in between the sets of Resent-* fields. Blow away the Received: fields and ... oops. Ned From walter.stanish@gmail.com Wed Mar 14 16:12:51 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD94A21F87C9 for ; Wed, 14 Mar 2012 16:12:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.874 X-Spam-Level: X-Spam-Status: No, score=-2.874 tagged_above=-999 required=5 tests=[AWL=0.725, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a+qu53NCnBFd for ; Wed, 14 Mar 2012 16:12:51 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1B6D721F87B0 for ; Wed, 14 Mar 2012 16:12:51 -0700 (PDT) Received: by yenm5 with SMTP id m5so2753288yen.31 for ; Wed, 14 Mar 2012 16:12:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=f0/Y1RQ1bUPU59h5RA5SqGOeiVyRK4XMA+jL5pvRBDI=; b=PNsgYD4HZkAUGUdkOTxfhrcrZXie1e0e0pFBXQwniU8JqTonPv5FzvKE//w4Zxq4wI vghSllB3eYAIO4s3KXLFk0RwSltyJ0D3s2v7iCzE0jPhsUD12GcZXHMjq+HSxhUBdPpp mVZaby2kWmAXIGWd045ixYg0KlyAItWK6utO3JFoN8NIYOPe5jzBqEMbJ3AbS5D/UTFp wHY/Xg1EBX7edgQN8NZJlUzssFXCreTK4fzxgCtx0gSTsT79MSGbCiwyZPI+4F8RIl5q xKfB5Tu/ursuWxxlXb6dXNuSy9FTa6hoXUqUdcMYZRO84uhObf/9el9p/WZr3/zGguET kLTw== MIME-Version: 1.0 Received: by 10.182.86.197 with SMTP id r5mr5544236obz.7.1331766770086; Wed, 14 Mar 2012 16:12:50 -0700 (PDT) Received: by 10.60.149.225 with HTTP; Wed, 14 Mar 2012 16:12:50 -0700 (PDT) In-Reply-To: <4F60B19D.3070408@stpeter.im> References: <4F5ADDCA.80303@KingsMountain.com> <4F60968D.4020703@stpeter.im> <4F60B19D.3070408@stpeter.im> Date: Thu, 15 Mar 2012 06:12:50 +0700 Message-ID: From: Walter To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Apps Discuss Subject: Re: [apps-discuss] Proposal for a Finance Area Mailing List X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 14 Mar 2012 23:12:51 -0000 >>> financial >>> application protocols. >> >> Maybe I'm still struggling with the direction of this. >> Is AMQP a financial application protocol? =A00MQ? > > AMQP and 0MQ are used in the financial industry, but I don't think they > are financial application protocols of the kind Walter seems to have in > mind, such as: > > https://datatracker.ietf.org/doc/draft-iiban/ > https://datatracker.ietf.org/doc/draft-imic/ > > But perhaps he can explain more clearly. AMQP and 0MQ are Message Queues. Roughly (I'm no authority) MQ's are associated with finance for a few reaso= ns: 1. Message orientation 2. Often good for building high availability systems on cheap hardware (n:n topology support) 3. Can be very low latency and bandwidth efficient 4. (probably) 'Enterprise' cultural overhead Code-wise, you can typically use the sockets interface to connect to them but they have all sorts of their own options to expose their flexibility. Often reliability is optional - in part, it's this ability to switch off the service guarantees provided by a standard transport that lend these layers their power, the other side being topology flexibility. In any case, message queues definitely appear to be a (the?) primary potential transport option for non "vendor locked-in" financial systems today. Hope that clarifies. Regards, Walter Stanish Payward, Inc. From walter.stanish@gmail.com Wed Mar 14 16:27:54 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73EA121F888D for ; Wed, 14 Mar 2012 16:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.929 X-Spam-Level: X-Spam-Status: No, score=-2.929 tagged_above=-999 required=5 tests=[AWL=0.670, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VHPdDv1JXals for ; Wed, 14 Mar 2012 16:27:54 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id DCB4621F888B for ; Wed, 14 Mar 2012 16:27:53 -0700 (PDT) Received: by ggmi1 with SMTP id i1so2766833ggm.31 for ; Wed, 14 Mar 2012 16:27:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cTPp+sWtK0m1zQG6TWPRhWzjCjas0PXwnMW3sIANmO8=; b=fAnHILHxp8Q/u73PPIEk7EgwtR1+rOSWITrL7PSL7pvxjnjVzoNVhjooNB95nHubWh O4xEXAK0N370N5IXjtsPDNrYGQEqDf5IrapeqlocuEO46eW6UYCq3gjHKT/CCpOASsH/ hlNiz0j6SN8HWXWPo2JWCizlEZvQupFcXqH6FUrNpmpAbA/Vfh5uw+8j33uKppDFMiQP Vwz4sHPGB7cBL89BlmACL0CXp9Cgg2EtEqfSWsCnSh0tUEsLdvgpVcAtYFDVxLJbn9TX 2npHzvs0AJ11g+dlG6pFpsh3RA0qIPjEq357uYHQ7CbatO5fsyXBcFpBsoay63zhbQHq jvow== MIME-Version: 1.0 Received: by 10.60.18.137 with SMTP id w9mr5794721oed.7.1331767673026; Wed, 14 Mar 2012 16:27:53 -0700 (PDT) Received: by 10.60.149.225 with HTTP; Wed, 14 Mar 2012 16:27:52 -0700 (PDT) In-Reply-To: <4F60968D.4020703@stpeter.im> References: <4F5ADDCA.80303@KingsMountain.com> <4F60968D.4020703@stpeter.im> Date: Thu, 15 Mar 2012 06:27:52 +0700 Message-ID: From: Walter To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Cc: Apps Discuss Subject: Re: [apps-discuss] Proposal for a Finance Area Mailing List X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 14 Mar 2012 23:27:54 -0000 > Walter, please provide the following information: > > 1. List name (please don't make it "finance" because people might think > it is an IAOC list) ifex (Internet Financial EXchange) > 2. List administrator email address(es) walter@stani.sh; others can be added as participation grows > 3. Purpose (a *brief* description, see > http://www.ietf.org/list/nonwg.html for examples) Discussion of future financial services protocols for the internet community. Regards, Walter Stanish Payward, Inc. From walter.stanish@gmail.com Wed Mar 14 17:17:11 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C63721F8470 for ; Wed, 14 Mar 2012 17:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.144 X-Spam-Level: X-Spam-Status: No, score=-2.144 tagged_above=-999 required=5 tests=[AWL=-0.211, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_FWDLOOK=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F10x1WifWeXK for ; Wed, 14 Mar 2012 17:17:11 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2985121F846B for ; Wed, 14 Mar 2012 17:17:11 -0700 (PDT) Received: by ggmi1 with SMTP id i1so2805236ggm.31 for ; Wed, 14 Mar 2012 17:17:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DpLjJFeW2HJ1gwnnpkMzH76no6YhndMMMSxtCx7nt3w=; b=fld0/C9Hs5tQIRpNzBhlPfJu//ERGNnjXyyxAOnZUuGyWqVecKtJnbEQxAiwPIByK0 MtZahEWLqjYWALafOTTk6FHgeFbmFzZ/KIDrattwyJxr0NcpNyOpiSjuBGhgrIFf8BA2 gsgeMLlyeD28LCNdy/u58+BZO2/NICqtRgXlXcFkrqx2IWjNGtVZueHOyqC7gB0qRPDi 3S6UDt++AL620NKACobMlfs+1tb1sJla/6RjKWe4PUCOL0C5EDv70FSoYFazxweVMBGq UMYvngnmGZ1xg+bUjg3/1RMZ66C5JEUN/S/2g/x92NGKLR6R7EQNhUySRQaNNsqcV8E9 ZvSw== MIME-Version: 1.0 Received: by 10.60.14.36 with SMTP id m4mr5791114oec.37.1331770630611; Wed, 14 Mar 2012 17:17:10 -0700 (PDT) Received: by 10.60.149.225 with HTTP; Wed, 14 Mar 2012 17:17:10 -0700 (PDT) In-Reply-To: References: <4F5ADDCA.80303@KingsMountain.com> <4F60968D.4020703@stpeter.im> Date: Thu, 15 Mar 2012 07:17:10 +0700 Message-ID: From: Walter To: jtimonmv@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Proposal for a Finance Area Mailing List X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 15 Mar 2012 00:17:11 -0000 Thanks for your support Jorge, and welcome to the effort :) With regards to forum location, I think the main difficulty with using an established forum is that most people come from a certain community with interest and experience that is generally more focused on certain aspects of internet based financial exchange. For example, it would be unreasonable to expect people involved in mobile operator billing to be familiar with mutual credit systems, just as it would be unreasonable to expect people involved with high frequency trading on stock exchanges to be familiar with credit card settlement anti-fraud rule weightings. The establishment of a unique forum under the IETF provides the capacity for different groups to come together - without being under the banner of any particular one - to look at issues of interoperability and leverage the skills, insight and experience of other parties. It also means that there's an established and proven procedure for getting things done (eventually formalized), resolving questions of consensus fairly, etc. Anyway, Ripple brings a very unique and relevant perspective to forward looking internet finance and I am really glad that you are joining in. Looking forward to working together on the new list! Regards, Walter Stanish Payward, Inc. From paulej@packetizer.com Wed Mar 14 18:49:19 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D98721F84E0 for ; Wed, 14 Mar 2012 18:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.226 X-Spam-Level: X-Spam-Status: No, score=-2.226 tagged_above=-999 required=5 tests=[AWL=-0.229, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9jprdbwTXqaD for ; Wed, 14 Mar 2012 18:49:14 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 1BBA621F844F for ; Wed, 14 Mar 2012 18:49:12 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q2F1n99s018431 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 14 Mar 2012 21:49:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1331776151; bh=GAYUlNS4pgWmq//vZx/H6unag56lAQsbJO6Swv5ePeU=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=pdE2mWMiC2Ri5tbllH8kMaPhpCfIzKRL6kSxmx3mVHlwJlLbUUdZf3QSesmGMYzne y86fv7fQyJ6IBPJ1PSa2bshuZXWUC3cjhrdLK2VVlPtJwx1HTHgRecx70PmLUAhbzL 4OeAUo0MWDMPCx6i+v7SZFV9Bf8vCpSkkkLSXT/w= From: "Paul E. Jones" To: "'Bob Wyman'" References: <05d001cd01a7$3cbb0c70$b6312550$@packetizer.com> <017201cd021a$02320450$06960cf0$@packetizer.com> In-Reply-To: Date: Wed, 14 Mar 2012 21:49:12 -0400 Message-ID: <000001cd024d$d2eb5d70$78c21850$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01CD022C.4BDC0760" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIpr5CrRpL27TKx2eu4GfpqVU03ngIPbM1eAcMbrxwBYFZBKJWHnBMA Content-Language: en-us Cc: webfinger@googlegroups.com, apps-discuss@ietf.org Subject: Re: [apps-discuss] Webfinger: acct "link relation" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 15 Mar 2012 01:49:19 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0001_01CD022C.4BDC0760 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Bob, I used an example wherein the client makes an assumption. However, I feel a little nervous about putting in normative statements that declare that this is the way it must work. My email client also makes the assumption when I type an address that looks like an email address that it is one. Such client-side "intelligent" assumptions are reasonable to make life easier for users, but I think it is best to leave that as non-normative. What I want to do is split section 6 into 6.1 and 6.2. In 6.1, I'll introduce the purpose for the "acct" URI, void of any example usage. In 6.2, I'll have a non-normative example (one like what is there presently.) Paul From: bobwyman@gmail.com [mailto:bobwyman@gmail.com] On Behalf Of Bob Wyman Sent: Wednesday, March 14, 2012 4:01 PM To: Paul E. Jones Cc: apps-discuss@ietf.org; webfinger@googlegroups.com Subject: Re: [apps-discuss] Webfinger: acct "link relation" Paul, If one may assume that mailto:user@example.com and acct:user@example.com are associated with the same user, shouldn't it be stated in the RFC that clients MAY assume this and that servers MUST NOT allow for the assumption to be invalid? Certainly, allowing the two identifiers to be associated with different people will cause never-ending confusion, however, if we want to prevent the confusion, then we should explicitly state that this situation should not arise. Note: I support your efforts to clarify the situation where a mailto: corresponds to a dissimilar acct:. Also, allowing user editing of WebFinger data, will drastically increase the utility of the protocol. bob wyman On Wed, Mar 14, 2012 at 3:38 PM, Paul E. Jones wrote: Bob, I want to improve the language in the introduction of that section, but I do think it is reasonable to assume that a user with a given email address may have an account with the same name on the server. There are instances where that would not be the case, but a 404 would be returned in that instance. It has been suggested that perhaps making this assumption would lead to returning information for the wrong person. That's possible, but I believe Webfinger might help to encourage domain owners from putting themselves in that situation. If user@example.com is a non-email account at that domain, there should not be a real user account with the same name, but belonging to a different person. It's simply poor practice. It confuses humans. We could get this straight in protocol, but it would never address the confusion in the human mind. In any case, I want the "acct" link relation to refer to other accounts, not necessarily the "right" account. The wording was not clear on that. Here's the proposed wording changes for the first 3 paragraphs (now reduced to two): Users of some services might have an acct URI that looks significantly different from their email address, perhaps using entirely different domain names. It is also possible that a user has multiple accounts that a Webfinger client may want to query. As such, it is useful to allow one user account to refer to one or more other account identifiers. To make a reference to other user accounts, one uses the "acct" link relation. Consider the following example. I welcome any textual changes to make this clearer. Paul From: bobwyman@gmail.com [mailto:bobwyman@gmail.com] On Behalf Of Bob Wyman Sent: Wednesday, March 14, 2012 11:26 AM To: Paul E. Jones Cc: apps-discuss@ietf.org; webfinger@googlegroups.com Subject: Re: [apps-discuss] Webfinger: acct "link relation" Thanks for mentioning section 6. I have been puzzling over this for some time now. It seems to me that if Alice receives an email from "bob@example.net" then, because there is no certain equivalence of mailto: and acct: identifiers, Alice should query for "mailto:bob@example.net" in order to discover "acct:bob@example.com " rather than assuming similarity between the mailto: and acct: identifiers and first querying for "acct:bob@example.net ." It must be remembered that WebFinger acct: identifiers need not be the same as or even similar to mailto: identifiers. Additionly, similar identifiers, such as "mailto:bob@example.net" and "acct:bob@example.net ," need not identify the same person or entity. (although it would be really, really smart if they did...) Given that in most cases, "acct:xxx" and "mailto:xxx" will, in fact, be associated with the same entity, it would be a bit of a nuisance to require the multi-step discovery process outlined above. Especially since we know that mapping from mailto: to acct: will be a very, very common requirement. Thus, it seems reasonable to me that we would add a few new rules: 1) If the server responding to a request for mailto: information is also the authoritative server for the WebFinger acct information, it may provide that information as long as it also provides a link with rel=acct element to identify the acct:. In this case, it should be understood that any information provided (other than the link that shows the relationship between the identifiers) is associated with the acct: identifier, not with the mailto: identifier. This server-side automatic mapping rule could, of course, be generalized to say that whenever the server knows the exact mapping from any URI, no matter what scheme it uses, to a corresponding acct: URI, it may perform the translation as long as it provides an appropriate link with (rel=acct) in its response. 2) To enable clients to do URI translations, it would be useful for servers to be able to describe those translations which are easily performed. For instance, for servers that maintain a one-to-one relationship between mailto: and acct: URIs, it should be possible for the server to publish in its host metadata the mapping between the two identifiers. Thus, we might have an XRD like the following: The XRD above not only describes the general template for forming queries, it gives specific instructions re optional pre-translation for mailto: URIs. Clearly, more complex template mappings would be interesting and often useful, but perhaps too complex. bob wyman On Wed, Mar 14, 2012 at 1:56 AM, Paul E. Jones wrote: > Folks, > > > > In the latest Webfinger draft, we introduced a "acct" link relation named > "acct" (see Section 6). The intent with that link relation was to allow for > one to inform a webfinger client that a user's account information may be > retrieved elsewhere. I believe this will be important, since a user might > have more than one account and this might serve as a means of associating > them. Certainly, it would be a way of retrieving information from those > other accounts automatically. > > > > Perhaps calling the new link relation "acct" is too restrictive, though. If > one used Webfinger to query other kinds of information other than a user's > account, there may still be a need/desire to refer the Webfinger client to > other resources. > > > > What do you think about changing this section such that the link relation is > renamed to "seealso"? This would still be useful when querying an acct URI, > but would also be useful when querying any URI since it is more generic. > > > > Do note that "seealso" would be different than the "alternate" link > relation. It would not refer to alternative information, but would refer to > supplemental information. In practice, the supplemental information may be > the more informative since the bulk of the information related to a user > might be held under a different account. > > > > Your thoughts? > > > > Paul > > > > > > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > ------=_NextPart_000_0001_01CD022C.4BDC0760 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Bob,

 

I used an example wherein the client makes an assumption.  = However, I feel a little nervous about putting in normative statements = that declare that this is the way it must work.  My email client = also makes the assumption when I type an address that looks like an = email address that it is one.  Such client-side = “intelligent” assumptions are reasonable to make life easier = for users, but I think it is best to leave that as = non-normative.

 

What I want to do is split section 6 into 6.1 and 6.2.  In 6.1, = I’ll introduce the purpose for the “acct” URI, void of = any example usage.  In 6.2, I’ll have a non-normative example = (one like what is there presently.)

 

Paul

 

From:= = bobwyman@gmail.com [mailto:bobwyman@gmail.com] On Behalf Of Bob = Wyman
Sent: Wednesday, March 14, 2012 4:01 PM
To: = Paul E. Jones
Cc: apps-discuss@ietf.org; = webfinger@googlegroups.com
Subject: Re: [apps-discuss] = Webfinger: acct "link = relation"

 

Paul,

If one = may assume that mailto:user@example.com and acct:user@example.com are = associated with the same user, shouldn't it be stated in the RFC that = clients MAY assume this and that servers MUST NOT allow for the = assumption to be invalid? Certainly, allowing the two identifiers to be = associated with different people will cause never-ending confusion, = however, if we want to prevent the confusion, then we should explicitly = state that this situation should not arise.

 

Note: I support your efforts to clarify the situation = where a mailto: corresponds to a dissimilar acct:. Also, allowing user = editing of WebFinger data, will drastically increase the utility of the = protocol.

 

bob wyman

On Wed, Mar 14, 2012 at 3:38 PM, Paul E. Jones <paulej@packetizer.com> = wrote:

Bob,

 

I want to improve the language in the introduction of that section, = but I do think it is reasonable to assume that a user with a given email = address may have an account with the same name on the = server.  There are instances where that would not be the case, but = a 404 would be returned in that instance.  It has been suggested = that perhaps making this assumption would lead to returning information = for the wrong person.  That’s possible, but I believe = Webfinger might help to encourage domain owners from putting themselves = in that situation.  If user@example.com is a non-email account at that = domain, there should not be a real user account with the same name, but = belonging to a different person.  It’s simply poor = practice.  It confuses humans.  We could get this straight in = protocol, but it would never address the confusion in the human = mind.

 

In any case, I want the “acct” link relation to refer to = other accounts, not necessarily the “right” account.  = The wording was not clear on that.  Here’s the proposed = wording changes for the first 3 paragraphs (now reduced to = two):

 

Users of some services might have an acct URI that looks = significantly different from their email address, perhaps using entirely = different domain names.  It is also possible that a user has = multiple accounts that a Webfinger client may want to query.  As = such, it is useful to allow one user account to refer to one or more = other account identifiers.

 

To make a reference to other user accounts, one uses the = “acct” link relation.  Consider the following = example.

 

I welcome any textual changes to make this = clearer.

 

Paul

 

From:= = bobwyman@gmail.com [mailto:bobwyman@gmail.com] On Behalf Of Bob = Wyman
Sent: Wednesday, March 14, 2012 11:26 AM
To: = Paul E. Jones
Cc: apps-discuss@ietf.org; webfinger@googlegroups.com
Subject: Re: = [apps-discuss] Webfinger: acct "link = relation"

 <= /o:p>

Thanks for = mentioning section 6. I have been puzzling over this for some time now. = It seems to me that if Alice receives an email from "bob@example.net" then, because there is no = certain equivalence of mailto: and acct: identifiers, Alice should query = for "mailto:bob@example.net" in order to discover = "acct:bob@example.com" rather than assuming = similarity between the mailto: and acct: identifiers and first querying = for "acct:bob@example.net."
It must be = remembered that WebFinger acct: identifiers need not be the same as or = even similar to mailto: identifiers. Additionly, similar identifiers, = such as "mailto:bob@example.net" and "acct:bob@example.net," need not identify the = same person or entity. (although it would be really, really smart if = they did...)

Given that in most cases, "acct:xxx" and = "mailto:xxx" = will, in fact, be associated with the same entity, it would be a bit of = a nuisance to require the multi-step discovery process outlined above. = Especially since we know that mapping from mailto: to acct: will be a = very, very common requirement. Thus, it seems reasonable to me that we = would add a few new rules:
1) If the server responding to a request = for mailto: information is also the authoritative server for the = WebFinger acct information, it may provide that information as long as = it also provides a link with rel=3Dacct element to identify the acct:. = In this case, it should be understood that any information provided = (other than the link that shows the relationship between the = identifiers) is associated with the acct: identifier, not with the = mailto: identifier. This server-side automatic mapping rule could, of = course, be generalized to say that whenever the server knows the exact = mapping from any URI, no matter what scheme it uses, to a corresponding = acct: URI, it may perform the translation as long as it provides an = appropriate link with (rel=3Dacct) in its response.
2) To enable = clients to do URI translations, it would be useful for servers to be = able to describe those translations which are easily performed. For = instance, for servers that maintain a one-to-one relationship between = mailto: and acct: URIs, it should be possible for the server to publish = in its host metadata the mapping between the two identifiers. Thus, we = might have an XRD like the following:

    <XRD xmlns=3D"http://docs.oasis-open.org/ns/xri/xrd-1.0">=

       <Link =
rel=3D"lrdd"
       &nbs=
p;     =
type=3D"application/xrd+xml"
       &nbs=
p;     template=3D"https://example.com/lrdd/?uri=3D{uri}"/>
    =
   <Link rel=3D"mailto2acct" =
template=3D"acct:{mailto_id}"/>

=

 
     =
</XRD>

 <= /o:p>

The XRD = above not only describes the general template for forming queries, it = gives specific instructions re optional pre-translation for mailto: = URIs. Clearly, more complex template mappings would be interesting and = often useful, but perhaps too complex.

bob wyman

On Wed, = Mar 14, 2012 at 1:56 AM, Paul E. Jones <paulej@packetizer.com> wrote:
> = Folks,
>
>  
>
> In the latest Webfinger = draft, we introduced a “acct” link relation named
> = “acct” (see Section 6).  The intent with that link = relation was to allow for
> one to inform a webfinger client that = a user’s account information may be
> retrieved = elsewhere.  I believe this will be important, since a user = might
> have more than one account and this might serve as a means = of associating
> them.  Certainly, it would be a way of = retrieving information from those
> other accounts = automatically.
>
>  
>
> Perhaps calling = the new link relation “acct” is too restrictive, = though.  If
> one used Webfinger to query other kinds of = information other than a user’s
> account, there may still = be a need/desire to refer the Webfinger client to
> other = resources.
>
>  
>
> What do you think = about changing this section such that the link relation is
> = renamed to “seealso”?  This would still be useful when = querying an acct URI,
> but would also be useful when querying any = URI since it  is more generic.
>
> =  
>
> Do note that “seealso” would be = different than the “alternate” link
> relation.  = It would not refer to alternative information, but would refer = to
> supplemental information.  In practice, the supplemental = information may be
> the more informative since the bulk of the = information related to a user
> might be held under a different = account.
>
>  
>
> Your = thoughts?
>
>  
>
> Paul
>
> =  
>
>  
>
> =  
>
>
> = _______________________________________________
> apps-discuss = mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss<= br>>

 

------=_NextPart_000_0001_01CD022C.4BDC0760-- From timon.elviejo@gmail.com Thu Mar 15 04:10:07 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3664421F864E for ; Thu, 15 Mar 2012 04:10:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.633 X-Spam-Level: X-Spam-Status: No, score=-1.633 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_FWDLOOK=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mLVGz2-5Ixpk for ; Thu, 15 Mar 2012 04:10:06 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9476721F8649 for ; Thu, 15 Mar 2012 04:10:06 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so3690896vcb.31 for ; Thu, 15 Mar 2012 04:10:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=0lIoauJBCsUJWawn2F6y+tjHuJXaDeWuJglFN04QE3A=; b=Qv87xljzSF9ydZ2CHg4jx5CmduM6XMyzBeHfGdrdJ9GPxCnS7QNgE30gXpTjlhc24f w3qMofxW7HO3WKjIhCCYq/Br2jgO5sTJ18+k2h3I+MtGuiPsqYJlO3tZ7Do9qwFmSVpn E6LPj7236YmoiLx0fNuloefPd6mcrONRwmw/ULq/6IhtZWJ2fFpM7kfFP8dyjwA+BQ50 Bm1TvRWQKi/HH9777T8rYxcnFbsSPsX/rchpZSuDwbENcfhvhevLXe2zIGZ0aLTNaf++ 8MBTSJakdE/s9F9MziykNwrQLaQWfYayN9b4wshkqYez5dShYEkSUhAiCCMVcQUgjAVS 153g== MIME-Version: 1.0 Received: by 10.52.93.77 with SMTP id cs13mr4352122vdb.71.1331809806079; Thu, 15 Mar 2012 04:10:06 -0700 (PDT) Sender: timon.elviejo@gmail.com Received: by 10.220.69.76 with HTTP; Thu, 15 Mar 2012 04:10:05 -0700 (PDT) In-Reply-To: References: <4F5ADDCA.80303@KingsMountain.com> <4F60968D.4020703@stpeter.im> Date: Thu, 15 Mar 2012 12:10:05 +0100 X-Google-Sender-Auth: f7Z1_661GKiT4QHyWfQE_YgN2VA Message-ID: From: =?ISO-8859-1?Q?Jorge_Tim=F3n?= To: Walter Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Proposal for a Finance Area Mailing List X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 15 Mar 2012 11:10:07 -0000 Probably Ryan will be interested in participate too. I agree that the discussion would be better in a "neutral" forum, I was just suggesting forums to "join the people together" if it is necessary to start the new mailing list. If you want, I can start a thread in the bitcoin-dev mailing list to get more people interested in the protocol. On 3/15/12, Walter wrote: > Thanks for your support Jorge, and welcome to the effort :) > > With regards to forum location, I think the main difficulty with using > an established forum is that most people come from a certain community > with interest and experience that is generally more focused on certain > aspects of internet based financial exchange. > > For example, it would be unreasonable to expect people involved in > mobile operator billing to be familiar with mutual credit systems, > just as it would be unreasonable to expect people involved with high > frequency trading on stock exchanges to be familiar with credit card > settlement anti-fraud rule weightings. > > The establishment of a unique forum under the IETF provides the > capacity for different groups to come together - without being under > the banner of any particular one - to look at issues of > interoperability and leverage the skills, insight and experience of > other parties. It also means that there's an established and proven > procedure for getting things done (eventually formalized), resolving > questions of consensus fairly, etc. > > Anyway, Ripple brings a very unique and relevant perspective to > forward looking internet finance and I am really glad that you are > joining in. Looking forward to working together on the new list! > > Regards, > Walter Stanish > Payward, Inc. > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --=20 Jorge Tim=F3n From michiel@unhosted.org Wed Mar 14 12:13:22 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3536021E8010 for ; Wed, 14 Mar 2012 12:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jGb0p1Zf9Pnn for ; Wed, 14 Mar 2012 12:13:20 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id BABEE21F86D4 for ; Wed, 14 Mar 2012 12:13:20 -0700 (PDT) Received: by dald2 with SMTP id d2so4481999dal.27 for ; Wed, 14 Mar 2012 12:13:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=i6hh1W9W6tWYqreONaZznIPLgQ3c022TAn6Y6WlEksY=; b=l2HoyQCw4QR7asU6JPwLvGXIogb+S550XwqSkj5KBZpBhqhrTjIsev+roV33FpxNmp rJHKnRpJYJCINQ5S1dLQmKFjtapA/er1fnlZXufpskvhQAGNozEDCXalB1SXJFzbkbP3 8hqoP61fJVJyQqBQUmn5NOKEEDolCIecXYfcqU1RC5EosIm/JD2sUfqcQvrm+BL5XplN chmHAL/b7SyaSccilA1jkHEIVbizuQcx9C659EGnn2PvSdNx1Yx+VOCGLPB4hngE3kRV 16BiT/HrQK1+8t0vhRODIYi9z38g09SugoFQHd754V0+demBbpJ2GtGA5/D4MF7LkwjD zBjA== MIME-Version: 1.0 Received: by 10.68.136.99 with SMTP id pz3mr4215135pbb.114.1331752400263; Wed, 14 Mar 2012 12:13:20 -0700 (PDT) Received: by 10.68.14.166 with HTTP; Wed, 14 Mar 2012 12:13:20 -0700 (PDT) X-Originating-IP: [84.90.251.181] In-Reply-To: <009f01cd01fa$b1eacfa0$15c06ee0$@packetizer.com> References: <05d001cd01a7$3cbb0c70$b6312550$@packetizer.com> <009f01cd01fa$b1eacfa0$15c06ee0$@packetizer.com> Date: Wed, 14 Mar 2012 19:13:20 +0000 Message-ID: From: Michiel de Jong To: webfinger@googlegroups.com Content-Type: multipart/alternative; boundary=047d7b10c943bf187204bb38c479 X-Gm-Message-State: ALoCoQnMwUqf+mSUw9n2IySOl12mkfeqRJsLIoInCMhI7D1xj83yLidS9xOPXVOH6zYmSihhDNjC X-Mailman-Approved-At: Thu, 15 Mar 2012 08:03:09 -0700 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Webfinger: acct "link relation" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 14 Mar 2012 19:13:22 -0000 --047d7b10c943bf187204bb38c479 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Now that i think some more about it, you're right, it's unrelated. But I do think there is a psychological problem, in that people don't use the template=3D'...{uri}...' syntax to its full potential. what you see happening a lot is something like: http://www.mysite.com/webfinger?q=3D{uri} On the statics server probably, in an MVC controller that has no access to the user profile database, probably. In the 'federation stuff' part of the site, and not in the 'human-viewable' part of the website. That's the wrong approach to the software architecture of a webfinger-capable website, i just realised. If you are already publishing human-readable "public profile" page on, say, https://profiles.mysite.com/username then you should use a lrdd template something a lot more like: https://profile.mysite.com/{uri}?format=3Djrd that way one controller can fetch a user's bio, interests, full name, and birthday and your MVC can spit out that same information in either html or xrd or jrd, depending on who is asking (a human or a machine). but you're right, it was purely a problem in software architecture, and the correct solution for it is to use on the one hand your MVC framework, and on the other the already existing indirection in the host-meta's lrdd template, to make them both do what they were designed for. Cheers! Michiel On Wed, Mar 14, 2012 at 3:54 PM, Paul E. Jones wrote= : > Michael,**** > > ** ** > > I would hope that virtually every piece of information stored in a user= =92s > profile is editable, though I can imagine some information may not be. I= n > any case, that largely seems to be an account management user interface > issue. Are you suggesting a change in the Webfinger protocol?**** > > ** ** > > Paul**** > > ** ** > > *From:* webfinger@googlegroups.com [mailto:webfinger@googlegroups.com] *O= n > Behalf Of *Michiel de Jong > *Sent:* Wednesday, March 14, 2012 2:57 AM > *To:* webfinger@googlegroups.com > *Cc:* apps-discuss@ietf.org > *Subject:* Re: Webfinger: acct "link relation"**** > > ** ** > > one very nice application of that would be to facilitate implementation o= f > user-editable webfinger. There will be resources that an identity provide= r > wants to announce by default for all their users, but maybe some (power) > users want to announce some additional machine-readable pointers related = to > their user address. Separating user-provided links from provider-provided > :) might make a lot of sense where you don't want the provider-provided > stuff to break. In case of conflict i think the 'seealso' one should alwa= ys > lose. That way, you can give your users the freedom to paste whatever lin= ks > they want into their profile settings, without fear of that breaking your > service's well-tested federation features. > > user-editable webfinger would be an amazing feature, and whereas in theor= y > you could offer it already, allowing users to paste stuff into the bowels > of your service's federation mechanism feels just wrong, adding a seealso > link to a section on the user's profile page, where the user already has > things like a bio, interests, location, etcetera, feels a lot more right.= i > guess it's a software architecture consideration. > > **** > > On Wed, Mar 14, 2012 at 5:56 AM, Paul E. Jones > wrote:**** > > Folks,**** > > **** > > In the latest Webfinger draft, we introduced a =93acct=94 link relation n= amed > =93acct=94 (see Section 6). The intent with that link relation was to al= low > for one to inform a webfinger client that a user=92s account information = may > be retrieved elsewhere. I believe this will be important, since a user > might have more than one account and this might serve as a means of > associating them. Certainly, it would be a way of retrieving information > from those other accounts automatically.**** > > **** > > Perhaps calling the new link relation =93acct=94 is too restrictive, thou= gh. > If one used Webfinger to query other kinds of information other than a > user=92s account, there may still be a need/desire to refer the Webfinger > client to other resources.**** > > **** > > What do you think about changing this section such that the link relation > is renamed to =93seealso=94? This would still be useful when querying an= acct > URI, but would also be useful when querying any URI since it is more > generic.**** > > **** > > Do note that =93seealso=94 would be different than the =93alternate=94 li= nk > relation. It would not refer to alternative information, but would refer > to supplemental information. In practice, the supplemental information m= ay > be the more informative since the bulk of the information related to a us= er > might be held under a different account.**** > > **** > > Your thoughts?**** > > **** > > Paul**** > > **** > > **** > > **** > > ** ** > --047d7b10c943bf187204bb38c479 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Now that i think some more about it, you're right, it's unrelated.<= br>
But I do think there is a psychological problem, in that people don&= #39;t use the template=3D'...{uri}...' syntax to its full potential= . what you see happening a lot is something like:

http://www.mysite= .com/webfinger?q=3D{uri}

On the statics server probably, in an M= VC controller that has no access to the user profile database, probably. In= the 'federation stuff' part of the site, and not in the 'human= -viewable' part of the website. That's the wrong approach to the so= ftware architecture of a webfinger-capable website, i just realised. If you= are already publishing human-readable "public profile" page on, = say,

https://profiles.mysit= e.com/username

then you should use a lrdd template something a l= ot more like:

https://profile.mysite.com/{uri}?format=3Djrd

that way one controller can fetch a user's bio, interests, full nam= e, and birthday and your MVC can spit out that same information in either h= tml or xrd or jrd, depending on who is asking (a human or a machine).

but you're right, it was purely a problem in software architecture,= and the correct solution for it is to use on the one hand your MVC framewo= rk, and on the other the already existing indirection in the host-meta'= s lrdd template, to make them both do what they were designed for.


Cheers!
Michiel

On Wed, Mar 14= , 2012 at 3:54 PM, Paul E. Jones <paulej@packetizer.com> wrote:

Michael,

=A0

I would hope that virtually every piece of in= formation stored in a user=92s profile is editable, though I can imagine so= me information may not be.=A0 In any case, that largely seems to be an acco= unt management user interface issue.=A0 Are you suggesting a change in the = Webfinger protocol?

=A0<= /p>

Paul

=A0<= /p>

From: webfi= nger@googlegroups.com [mailto:webfinger@googlegroups.com] On Behalf Of = Michiel de Jong
Sent: Wednesday, March 14, 2012 2:57 AM
To: webfinger@googlegroups.co= m
Cc: apps-discuss@ietf.org
Subject: Re: Webfinger: acct "link relation"=

=A0

one ve= ry nice application of that would be to facilitate implementation of user-e= ditable webfinger. There will be resources that an identity provider wants = to announce by default for all their users, but maybe some (power) users wa= nt to announce some additional machine-readable pointers related to their u= ser address. Separating user-provided links from provider-provided :) might= make a lot of sense where you don't want the provider-provided stuff t= o break. In case of conflict i think the 'seealso' one should alway= s lose. That way, you can give your users the freedom to paste whatever lin= ks they want into their profile settings, without fear of that breaking you= r service's well-tested federation features.

user-editable webfinger would be an amazing feature, and whereas in the= ory you could offer it already, allowing users to paste stuff into the bowe= ls of your service's federation mechanism feels just wrong, adding a se= ealso link to a section on the user's profile page, where the user alre= ady has things like a bio, interests, location, etcetera, feels a lot more = right. i guess it's a software architecture consideration.

On Wed, Mar 14, 2012 at 5= :56 AM, Paul E. Jones <paulej@packetizer.com> wrote:

Folks,

=A0

In the latest Webfinger draft, we introduced a =93acct=94 l= ink relation named =93acct=94 (see Section 6).=A0 The intent with that link= relation was to allow for one to inform a webfinger client that a user=92s= account information may be retrieved elsewhere.=A0 I believe this will be = important, since a user might have more than one account and this might ser= ve as a means of associating them.=A0 Certainly, it would be a way of retri= eving information from those other accounts automatically.

=A0

Perhaps = calling the new link relation =93acct=94 is too restrictive, though.=A0 If = one used Webfinger to query other kinds of information other than a user=92= s account, there may still be a need/desire to refer the Webfinger client t= o other resources.

=A0

What do = you think about changing this section such that the link relation is rename= d to =93seealso=94?=A0 This would still be useful when querying an acct URI= , but would also be useful when querying any URI since it=A0 is more generi= c.

=A0

Do note = that =93seealso=94 would be different than the =93alternate=94 link relatio= n.=A0 It would not refer to alternative information, but would refer to sup= plemental information.=A0 In practice, the supplemental information may be = the more informative since the bulk of the information related to a user mi= ght be held under a different account.

=A0

Your tho= ughts?

=A0

Paul

=A0

=A0

=A0=

=A0

<= /div>

--047d7b10c943bf187204bb38c479-- From sebastian.kaebisch.ext@siemens.com Thu Mar 15 11:01:41 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0469E21F8787 for ; Thu, 15 Mar 2012 11:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.805 X-Spam-Level: X-Spam-Status: No, score=-8.805 tagged_above=-999 required=5 tests=[AWL=-0.722, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sk4oVlSJxpuu for ; Thu, 15 Mar 2012 11:01:40 -0700 (PDT) Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by ietfa.amsl.com (Postfix) with ESMTP id B13EA21F8770 for ; Thu, 15 Mar 2012 11:01:37 -0700 (PDT) Received: from mail3.siemens.de (localhost [127.0.0.1]) by david.siemens.de (8.13.6/8.13.6) with ESMTP id q2FI1Z1L019718; Thu, 15 Mar 2012 19:01:35 +0100 Received: from DEMCHP99ET3MSX.ww902.siemens.net (demchp99et3msx.ww902.siemens.net [139.25.131.243]) by mail3.siemens.de (8.13.6/8.13.6) with ESMTP id q2FI1YBC009881 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 15 Mar 2012 19:01:34 +0100 Received: from DEMCHP99E55MSX.ww902.siemens.net ([169.254.2.75]) by DEMCHP99ET3MSX.ww902.siemens.net ([139.25.131.243]) with mapi; Thu, 15 Mar 2012 19:01:33 +0100 From: "Kaebisch, Sebastian" To: DOI Yusuke Date: Thu, 15 Mar 2012 19:01:32 +0100 Thread-Topic: [apps-discuss] SenML Thread-Index: Ac0B52L9xTzd/tS3QmCvOLd86f+BRQAAHj3Q Message-ID: <1CE2FB42E90B614C98BC172FAB12D4C002D5099178@DEMCHP99E55MSX.ww902.siemens.net> References: <1CE2FB42E90B614C98BC172FAB12D4C002D50989C3@DEMCHP99E55MSX.ww902.siemens.net> <201203091742.q29HglnN008664@toshiba.co.jp> <1CE2FB42E90B614C98BC172FAB12D4C002D5098E63@DEMCHP99E55MSX.ww902.siemens.net> <201203141335.q2EDZoJ2026006@toshiba.co.jp> In-Reply-To: <201203141335.q2EDZoJ2026006@toshiba.co.jp> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] SenML X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 15 Mar 2012 18:01:41 -0000 Dear Yusuke, > > That's right, however, EXI has to convert the float value into the > mantissa and exponent representation (encoding) and vice versa (decoding) > respectively. This processing overhead can be avoided if we working > already on data model level only with the mantissa and exponent > representation. >=20 > I cannot get your point. Do you have specific API or something else in > mind? >=20 > I think both is possible and some library for constrianed devices may > implement something like the latter. >=20 > 1) encode_exi_float(EXI_STREAM *out_stream, double f); > 2) encode_exi_exp(EXI_STREAM *out_stream, int mantissa, int exponent); You are absolutely right, both implementations are possible. My intention w= as only to point to the processing overhead in "encode_exi_float" (bringing= float to mantissa-exponent representation) which can be avoided if we are = only working with the mantissa-exponent representation all the time and sta= te this in the senML XSD as well. I have only the very restricted microcont= rollers in mind. Best regards Sebastian From ietfc@btconnect.com Fri Mar 16 03:43:48 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A671621F857F; Fri, 16 Mar 2012 03:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.113 X-Spam-Level: X-Spam-Status: No, score=-2.113 tagged_above=-999 required=5 tests=[AWL=0.486, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ml0YsfPxwOCr; Fri, 16 Mar 2012 03:43:47 -0700 (PDT) Received: from mail.btconnect.com (c2bthomr10.btconnect.com [213.123.20.128]) by ietfa.amsl.com (Postfix) with ESMTP id 2406621F8581; Fri, 16 Mar 2012 03:43:46 -0700 (PDT) Received: from host86-151-41-215.range86-151.btcentralplus.com (HELO pc6) ([86.151.41.215]) by c2bthomr10.btconnect.com with SMTP id GTO68142; Fri, 16 Mar 2012 10:43:21 +0000 (GMT) Message-ID: <01be01cd0359$19b557e0$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Romascanu, Dan \(Dan\)" , "Lisa Dusseault" , References: <6.2.5.6.2.20120313162357.0a0e5350@elandnews.com> Date: Fri, 16 Mar 2012 10:42:23 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0303.4F631948.00A0, actions=tag X-Junkmail-Premium-Raw: score=8/50, refid=2.7.2:2012.3.16.101221:17:8.317, ip=86.151.41.215, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __MULTIPLE_RCPTS_CC_X2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __FRAUD_BODY_WEBMAIL, __URI_NO_PATH, BODY_SIZE_3000_3999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, HTML_00_01, HTML_00_10, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, MULTIPLE_RCPTS, RDNS_SUSP, __FRAUD_WEBMAIL, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2bthomr10.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0205.4F631949.00C0,ss=1,re=0.000,fgs=0, ip=0.0.0.0, so=2011-07-25 19:15:43, dmn=2011-05-27 18:58:46, mode=multiengine X-Junkmail-IWF: false Cc: draft-ietf-opsawg-management-stds.all@tools.ietf.org, opsawg@ietf.org Subject: Re: [apps-discuss] [OPSAWG] APPSDIR reviewofdraft-ietf-opsawg-management-stds-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 16 Mar 2012 10:43:48 -0000 Lisa I think that the other subtext implicit in this I-D is the recent change of meaning of OAM, to exclude Management. That is, when you nowadays see a reference to Management, as in the title of this I-D, you have to add, sotto voce, 'and excluding anything that might be considered part of OAM'. Sigh:-( Tom Petch ----- Original Message ----- From: "Romascanu, Dan (Dan)" To: "Lisa Dusseault" ; Cc: ; ; Sent: Wednesday, March 14, 2012 11:52 AM Subject: Re: [OPSAWG] [apps-discuss] APPSDIR reviewofdraft-ietf-opsawg-management-stds-05 > Hi Lisa, > > Thank you for your review. > > Please allow me to respond to one of your comments. > > > > > > > -----Original Message----- > > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > > bounces@ietf.org] On Behalf Of Lisa Dusseault > > > > The goal of this document sounds great, and it seems there is some > > need for a survey or overview of network management standards. Some > > sections achieve the document's goals with concise, clear summaries > > and pointers to outside work. Other sections of the document suffer > > from meaningless (e.g. circular or jargon-laden) summaries and awkward > > explanations, but at least the pointers will still be useful. I have > > some concerns about whether the document is comprehensive, because a > > survey is most useful when it really points to all the prior and > > relevant work at least in brief. > > > > While I am not in a position to notice all the places where the > > document may have holes in its comprehensiveness, I did note that > > currently active work was not consistently covered. The document does > > not mention or refer to ARMD, BMWG or benchmarking, GROW or BGP > > Monitoring. I do not know which of these Ops area WGs are important > > or actively making progress, but to an Ops outsider they all seem > > relevant. It's not as if the document does not cover active work: the > > document goes into some detail explaining not only the purpose of > > energy management work going on in the IETF but also some of the > > challenges of that work (appendix B). Missing other active WGs' > > topics seems odd. > > > > [[DR]] As you probably know well the OPS Area activities covers > Operations and Management. The scope of this document is as you > correctly point providing an overview of network management standards. > The WGs you mention - ARMD, BMWG, GROW - belong all to the operational > part of the area, none develops network management standards (protocols > or data models). BGP monitoring is realized via a number of means, two > of them are mentioned in the document (the data model in RFC 4273 in > section 4.1.3 and the IPFIX IEs in section 4.2.3). > > Regards, > > Dan > > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > > From aaron@serendipity.cx Fri Mar 16 04:11:49 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 022D021F8606; Fri, 16 Mar 2012 04:11:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.405 X-Spam-Level: X-Spam-Status: No, score=-101.405 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aSOPL1cQ1so9; Fri, 16 Mar 2012 04:11:47 -0700 (PDT) Received: from slice.serendipity.cx (slice.serendipity.cx [67.23.2.90]) by ietfa.amsl.com (Postfix) with ESMTP id 0426D21F856C; Fri, 16 Mar 2012 04:11:46 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by slice.serendipity.cx (Postfix) with ESMTPSA id 3C0A0110064; Fri, 16 Mar 2012 04:10:41 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so5049924vcb.31 for ; Fri, 16 Mar 2012 04:11:37 -0700 (PDT) Received: by 10.52.240.177 with SMTP id wb17mr1361135vdc.63.1331896297762; Fri, 16 Mar 2012 04:11:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.172.9 with HTTP; Fri, 16 Mar 2012 04:11:17 -0700 (PDT) From: Aaron Stone Date: Fri, 16 Mar 2012 04:11:17 -0700 Message-ID: To: apps-discuss@ietf.org, draft-ietf-marf-dkim-reporting.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: The IESG Subject: [apps-discuss] APPSDIR review of draft-ietf-marf-dkim-reporting-15 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 16 Mar 2012 11:11:49 -0000 Document: draft-ietf-marf-dkim-reporting-15 Title: Extensions to DKIM for Failure Reporting Reviewer: Aaron Stone Review Date: 3/15/2012 IESG Telechat Date: 3/15/2012 Summary: This draft is generally in good shape; the major issues here should be easy to resolve. I hope the minor issues notes are helpful and not too pedantic. === Major Issues: Should the well-known domain components "_report._domainkey" be registered with IANA? (Hmm, I don't see any such registry. In that case, there is an edit below suggesting text to more clearly state a MUST around this domain record name.) Please add a note about DKIM selectors. The name "_report._domainkey" is in the same namespace as RFC 6376, Section 3.1 Selectors, which take the form, "yourselector._domainkey". This effectively states that a domain implementing both strategies MUST NOT use "_report" as a selector, because of this requirement of the algorithm described in Section 3.3: 3. If the DNS query returns anything other than RCODE 0 (NOERROR), or if multiple TXT records are returned, terminate. === Minor Issues: Introduction: UPDATED DomainKeys Identified Mail [DKIM] introduced a mechanism for message signing and authentication. It uses digital signing to associate a domain name with a message in a reliable manner. The verified domain name can then be evaluated before the message is delivered, e.g., checking advertised sender policy, comparing to a known-good sender list, submitting to a reputation service, and so on. A message sender employing [DKIM] may want to know when and why messages received by others fail verification. This applies equally to verification failures in a message containing DKIM headers, as well as published signing practices (e.g., Author Domain Signing Practices, [ADSP]) in an Administrative Management Domain (ADMD; see [EMAIL-ARCH]). This document extends [DKIM] and [ADSP] to add an optional reporting address and some reporting parameters. Reports are generated using the format defined in [I-D.IETF-MARF-AUTHFAILURE-REPORT]. Sections 2.2 and 2.3 - switch the order, so that it goes: Keywords, Notation, Imported Definitions, Other Definitions. Section 2.4 - report generator has an awkward use of "also". Remove the world "also": OLD ... also designed to ... NEW ... designed to ... Section 3: OLD A domain name owner employing [DKIM] for email signing and authentication might want to know when signatures in use by that ought to be verifiable with specific public keys are not successfully verifying. Currently there is no such mechanism defined. This document adds optional "tags" (as defined in [DKIM]) to the DKIM-Signature header field and the DKIM key record in the DNS, using the formats defined in that specification. NEW A domain name owner employing [DKIM] for email signing and authentication might want to know when message recipients are unable to verify a message due to problems in the keys published for a domain. Currently there is no such mechanism defined. This section adds optional tags to the DKIM-Signature header field and the DKIM key record in the DNS, using the formats defined in [DKIM]. Section 3.1: mismatch between prose and ABNF. Prose says "upper or lower case", ABNF is lower-case only. Edit the prose to match the ABNF: OLD At present, the only legal value is the single character "y" (in either upper or lower case). NEW At present, the only legal value is the single character "y". Section 3.2: I'm confused by the following paragraph, and took a while to understand which DNS record would be used. I suggest this edit: OLD When a Signer wishes to advertise that it wants to receive failed verification reports, it also places in the DNS a TXT resource record (RR). The RR is made up of a sequence of tag-value objects (much like DKIM key records, as defined in Section 3.6.1 of [DKIM]), but it is entirely independent of those key records and is found at a different name. In the case of a record advertising the desire for authentication failure reports, the tags and values comprise the parameters to be used when generating the reports. A report generator will request the content of this record when it sees an "r=" tag in a DKIM-Signature header field. NEW When a Signer wants to receive reports of failed DKIM verifications, it adds a TXT resource record (RR) in the DNS, advertising how to notify the Signer of such failures. The RR contains a sequence of tag-value objects in a similar format as DKIM key records, specifying parameters to be used when generating failure reports. The TXT record containing failure reporting information MUST be "_report._domainkey" within the relevant DNS domains. A report generator will request the contents of this record when it sees an "r=" tag in a DKIM-Signature header field. Section 3.2: Confusing use of "tags" and "tokens". Edited to use "tokens". HOWEVER - maybe the word "values" would be better? OLD rr= Requested Reports (plain-text; OPTIONAL; default is "all"). The value MUST be a colon-separated list of tokens representing those conditions under which a report is desired. See Section 5.1 for a list of valid tags. NEW rr= Requested Reports (plain-text; OPTIONAL; default is "all"). The value MUST be a colon-separated list of tokens representing those conditions under which a report is desired. See Section 5.1 for a list of valid tokens. Section 3.2: Use of dkim-quoted-printable in prose, but qp-section in ABNF. Please edit this as apprpriate. ERR rs= Requested SMTP Error String (text; OPTIONAL; no default). The value is a dkim-quoted-printable string that the publishing ADMD ^^^^^^^^^^^^^^^^^^^^^ requests be included in [SMTP] error strings if messages are rejected during the delivery SMTP session. ABNF: rep-rs-tag = %x72.73 *WSP "=" qp-section ^^^^^^^^^^ ; "rs=..." (lower-case only for the tag name) Section 4: Confusing language, similar edits as intro to Section 3: OLD There also exist cases in which a domain name owner employing [ADSP] for announcing signing practises with DKIM may want to know when messages are received without valid author domain signatures. Currently there is no such mechanism defined. This document adds the following optional "tags" (as defined in [ADSP]) to the DKIM ADSP records, using the form defined in that specification: NEW A domain name owner employing Author Domain Signing Practices [ADSP] may also want to know when message recipients are unable to verify a message due to errors in the ADSP records. Currently there is no such mechanism defined. This section adds optional tags to the DKIM ADSP records, using the formats defined in [ADSP]. (and [DKIM] ?) Section 4: Run-on sentence, and dkim-quoted-printable vs. qp-section again. OLD ra= Reporting Address (plain-text; OPTIONAL; no default). The value MUST be a dkim-quoted-printable string containing the local-part ^^^^^^^^^^^^^^^^^^^^^ of an email address to which a report SHOULD be sent when mail claiming to be from this domain failed the verification algorithm described in [ADSP], in particular because a message arrived without a signature that validates, which contradicts what the ADSP record claims. NEW ra= Reporting Address (plain-text; OPTIONAL; no default). The value MUST be a dkim-quoted-printable string containing the local-part ^^^^^^^^^^^^^^^^^^^^^ of an email address to which a report SHOULD be sent when mail claiming to be from this domain failed the verification algorithm described in [ADSP]. ERR adsp-ra-tag = %x72.61 *WSP "=" qp-section ^^^^^^^^^^ ; "ra=..." (lower-case only for the tag name) Section 4: remove this sentence, it's not particularly useful? ... An exception to this might be some out-of-band arrangement between two parties to override it with some mutually agreed value. ... Section 4: tokens vs. tags again. "value" might still be a better word? OLD rr= Requested Reports (plain-text; OPTIONAL; default is "all"). The value MUST be a colon-separated list of tokens representing those conditions under which a report is desired. See Section 5.2 for a list of valid tags. ABNF: NEW rr= Requested Reports (plain-text; OPTIONAL; default is "all"). The value MUST be a colon-separated list of tokens representing those conditions under which a report is desired. See Section 5.2 for a list of valid tokens. ABNF: Section 5: remove extra sentence OLD This memo also includes, as the "ro" "rr" tags defined above, the means by which the signer can request reports for specific circumstances of interest. Verifiers MUST NOT generate reports for incidents that do not match a requested report, and MUST ignore requests for reports not included in this list. NEW The "ro" and "rr" tags allow a Signer to specify the types of errors it is interested in receiving reports about. This section defines the error types and corresponding token values. Verifiers MUST NOT generate reports for incidents that do not match a requested report, and MUST ignore requests for reports not included in this list. Section 8.3: missing context clues OLD Some threats caused by deliberate misuse of this mechanism are discussed in Section 3.3, but they warrant further discussion here. NEW Some threats caused by deliberate misuse of this error reporting mechanism are discussed in Section 3.3, but they warrant further discussion here. Paragraph out of order; this paragraph: Negative caching offers some protection against this pattern of abuse, although it will work only as long as the negative time-to- live on the relevant SOA record in the DNS. Please move it to just above the paragraph about positive caching, as well as making some small changes below: OLD Implementers are therefore strongly advised not to advertise that DNS record except when reports desired, including the risk of receiving this kind of attack. Positive caching of this DNS reply also means turning off the flow of reports by removing the record is not likely to have immediate effect. A low time-to-live on the record needs to be considered. NEW Domain owners are therefore strongly advised not to advertise the DNS records specified in this document except when failure reports are desired. Domain owners ought to be prepared to receive unexpected traffic and attacks. Negative caching offers some protection against this pattern of abuse, although it will work only as long as the negative time-to- live on the relevant SOA record in the DNS. Positive caching of DNS records also means turning off the flow of reports by removing the record is not likely to have immediate effect. A low time-to-live on the record needs to be considered. === Nits: [list editorial issues such as typographical errors, preferably by section number] Section 3.2: typo at the very last sentence: OLD See Section 8.4 for some considerations regardin limitations of this mechanism. NEW See Section 8.4 for some considerations regarding limitations of this mechanism. Remove the quotes around "tags" -- tags appears as a bare word in [DKIM], so it's safe to use here, too. Choose either "document" or "memo" to refer to this document / memo throughout. END From dhc@dcrocker.net Fri Mar 16 07:27:23 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D24521F8649; Fri, 16 Mar 2012 07:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.606 X-Spam-Level: X-Spam-Status: No, score=-6.606 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z6TTAyIzXiII; Fri, 16 Mar 2012 07:27:22 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6356321F85DD; Fri, 16 Mar 2012 07:27:22 -0700 (PDT) Received: from [192.168.1.11] (adsl-67-127-58-62.dsl.pltn13.pacbell.net [67.127.58.62]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q2GERGsb003154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Mar 2012 07:27:21 -0700 Message-ID: <4F634DA6.1050203@dcrocker.net> Date: Fri, 16 Mar 2012 07:26:46 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Aaron Stone References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 16 Mar 2012 07:27:22 -0700 (PDT) Cc: The IESG , apps-discuss@ietf.org, draft-ietf-marf-dkim-reporting.all@tools.ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-marf-dkim-reporting-15 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 14:27:23 -0000 On 3/16/2012 4:11 AM, Aaron Stone wrote: > === Major Issues: > > Should the well-known domain components "_report._domainkey" be > registered with IANA? > (Hmm, I don't see any such registry. In that case, there is an edit > below suggesting text to more clearly state a MUST around this domain > record name.) Currently, every new use of a reserved, underscore-based domain name is creating its own registry for the name(s). So far, there are roughly 20. I've twice proposed creating a single, consolidated registry for this. The first proposal, in 2006, was incomplete. The recent version seems complete to me, but the dnsop working group produced no responses when I queried it for feedback repeatedly: http://tools.ietf.org/html/draft-crocker-dns-attrleaf-06 We still need the registry, as you note. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From msk@cloudmark.com Fri Mar 16 10:42:43 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1358A21E804E; Fri, 16 Mar 2012 10:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.603 X-Spam-Level: X-Spam-Status: No, score=-102.603 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HTlx3FomZJ2x; Fri, 16 Mar 2012 10:42:41 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id 0747D21E8012; Fri, 16 Mar 2012 10:42:35 -0700 (PDT) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Fri, 16 Mar 2012 10:42:34 -0700 From: "Murray S. Kucherawy" To: Aaron Stone , "apps-discuss@ietf.org" , "draft-ietf-marf-dkim-reporting.all@tools.ietf.org" Thread-Topic: APPSDIR review of draft-ietf-marf-dkim-reporting-15 Thread-Index: AQHNA2WdqbNeMSp5F0Wf4Tcqt6bT3ZZtJAmA Date: Fri, 16 Mar 2012 17:42:33 +0000 Message-ID: <9452079D1A51524AA5749AD23E00392808EF6E@exch-mbx901.corp.cloudmark.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: The IESG Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-marf-dkim-reporting-15 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 16 Mar 2012 17:42:43 -0000 > -----Original Message----- > From: Aaron Stone [mailto:aaron@serendipity.cx] > Sent: Friday, March 16, 2012 4:11 AM > To: apps-discuss@ietf.org; draft-ietf-marf-dkim-reporting.all@tools.ietf.= org > Cc: The IESG > Subject: APPSDIR review of draft-ietf-marf-dkim-reporting-15 >=20 > Document: draft-ietf-marf-dkim-reporting-15 > Title: Extensions to DKIM for Failure Reporting > Reviewer: Aaron Stone > Review Date: 3/15/2012 > IESG Telechat Date: 3/15/2012 >=20 > Summary: This draft is generally in good shape; the major issues here > should be easy to resolve. > I hope the minor issues notes are helpful and not too pedantic. Hi Aaron, This arrived after the telechat completed. I'll talk to our AD about how t= o handle your comments, modulo my replies below. > =3D=3D=3D Major Issues: >=20 > Should the well-known domain components "_report._domainkey" be > registered with IANA? > (Hmm, I don't see any such registry. In that case, there is an edit > below suggesting text to more clearly state a MUST around this domain > record name.) The registry doesn't exist. Another document proposes it, but it hasn't ga= ined much momentum so far (unfortunately). See Dave's reply. > Please add a note about DKIM selectors. The name "_report._domainkey" > is in the same namespace as RFC 6376, Section 3.1 Selectors, which take > the form, "yourselector._domainkey". This effectively states that a > domain implementing both strategies MUST NOT use "_report" as a > selector, because of this requirement of the algorithm described in > Section 3.3: >=20 > 3. If the DNS query returns anything other than RCODE 0 (NOERROR), > or if multiple TXT records are returned, terminate. A selector, per RFC6376 Section 3.1, is a set of "sub-domain"s concatenated= by periods. A "sub-domain" is defined in Section 4.1.2 of RFC5321 in a wa= y that disallows underscores. There's therefore no overlap. > =3D=3D=3D Minor Issues: >=20 > Introduction: >=20 > UPDATED > [...] OK. > Sections 2.2 and 2.3 - switch the order, so that it goes: Keywords, > Notation, Imported Definitions, Other Definitions. OK. > Section 2.4 - report generator has an awkward use of "also". Remove the > world "also": >=20 > OLD > ... also designed to ... > NEW > ... designed to ... Actually the intent there is to indicate this is a slightly atypical Verifi= er in the DKIM sense; it's a DKIM Verifier that also has a report generatio= n capability. I'll say that explicitly. > Section 3: >=20 > OLD > A domain name owner employing [DKIM] for email signing and > authentication might want to know when signatures in use by that ought= to be > verifiable with specific public keys are not successfully verifying. > Currently there is no such mechanism defined. >=20 > This document adds optional "tags" (as defined in [DKIM]) to the > DKIM-Signature header field and the DKIM key record in the DNS, using > the formats defined in that specification. > NEW > A domain name owner employing [DKIM] for email signing and > authentication might want to know when message recipients are unable > to verify a message due to problems in the keys published for a domain= . > Currently there is no such mechanism defined. This isn't quite right, because there could be no problem with the keys, bu= t rather message alteration in transit that the signer wants to know about. > This section adds optional tags to the DKIM-Signature header field > and the DKIM key record in the DNS, using the formats defined in [DKIM= ]. OK. > Section 3.1: mismatch between prose and ABNF. Prose says "upper or > lower case", ABNF is lower-case only. Edit the prose to match the > ABNF: >=20 > OLD > At present, the only legal value is the single character "y" > (in either upper or lower case). >=20 > NEW > At present, the only legal value is the single character "y". Removed; a note was already added in the ABNF to indicate that only the low= ercase form is allowed. > Section 3.2: I'm confused by the following paragraph, and took a while > to understand which DNS record would be used. I suggest this edit: >=20 > OLD > When a Signer wishes to advertise that it wants to receive failed > verification reports, it also places in the DNS a TXT resource record > (RR). The RR is made up of a sequence of tag-value objects (much > like DKIM key records, as defined in Section 3.6.1 of [DKIM]), but it > is entirely independent of those key records and is found at a > different name. In the case of a record advertising the desire for > authentication failure reports, the tags and values comprise the > parameters to be used when generating the reports. A report > generator will request the content of this record when it sees an > "r=3D" tag in a DKIM-Signature header field. > NEW > When a Signer wants to receive reports of failed DKIM verifications, > it adds a TXT resource record (RR) in the DNS, advertising how to > notify the Signer of such failures. The RR contains a sequence of > tag-value objects in a similar format as DKIM key records, specifying > parameters to be used when generating failure reports. >=20 > The TXT record containing failure reporting information MUST be > "_report._domainkey" within the relevant DNS domains. A report > generator will request the contents of this record when it sees an > "r=3D" tag in a DKIM-Signature header field. OK. > Section 3.2: Confusing use of "tags" and "tokens". Edited to use "tokens"= . > HOWEVER - maybe the word "values" would be better? I used "tags" in this context to refer to the left half of "a=3Db" objects;= "tokens" are the elements in a list of values. > OLD > rr=3D Requested Reports (plain-text; OPTIONAL; default is "all"). The > value MUST be a colon-separated list of tokens representing those > conditions under which a report is desired. See Section 5.1 for a > list of valid tags. > NEW > rr=3D Requested Reports (plain-text; OPTIONAL; default is "all"). The > value MUST be a colon-separated list of tokens representing those > conditions under which a report is desired. See Section 5.1 for a > list of valid tokens. Right, fixed. > Section 3.2: Use of dkim-quoted-printable in prose, but qp-section in ABN= F. > Please edit this as apprpriate. >=20 > ERR > rs=3D Requested SMTP Error String (text; OPTIONAL; no default). The > value is a dkim-quoted-printable string that the publishing ADMD > ^^^^^^^^^^^^^^^^^^^^^ > requests be included in [SMTP] error strings if messages are > rejected during the delivery SMTP session. ABNF: >=20 > rep-rs-tag =3D %x72.73 *WSP "=3D" qp-section > ^^^^^^^^^^ > ; "rs=3D..." (lower-case only for the tag name) Fixed, and a reference added in the Imported Definitions section. > Section 4: Confusing language, similar edits as intro to Section 3: >=20 > OLD > There also exist cases in which a domain name owner employing [ADSP] > for announcing signing practises with DKIM may want to know when > messages are received without valid author domain signatures. > Currently there is no such mechanism defined. >=20 > This document adds the following optional "tags" (as defined in > [ADSP]) to the DKIM ADSP records, using the form defined in that > specification: > NEW > A domain name owner employing Author Domain Signing Practices [ADSP] > may also want to know when message recipients are unable to verify > a message due to errors in the ADSP records. > Currently there is no such mechanism defined. This is also not quite right. The intent is to allow reporting of messages= that fail ADSP checks even when there aren't errors in ADSP records. > This section adds optional tags to the DKIM ADSP records, > using the formats defined in [ADSP]. > (and [DKIM] ?) ADSP refers to DKIM to get the tag format, so I think this is good enough. > Section 4: Run-on sentence, and dkim-quoted-printable vs. qp-section > again. >=20 > OLD > ra=3D Reporting Address (plain-text; OPTIONAL; no default). The valu= e > MUST be a dkim-quoted-printable string containing the local-part > ^^^^^^^^^^^^^^^^^^^^^ > of an email address to which a report SHOULD be sent when mail > claiming to be from this domain failed the verification algorithm > described in [ADSP], in particular because a message arrived > without a signature that validates, which contradicts what the > ADSP record claims. > NEW > ra=3D Reporting Address (plain-text; OPTIONAL; no default). The valu= e > MUST be a dkim-quoted-printable string containing the local-part > ^^^^^^^^^^^^^^^^^^^^^ > of an email address to which a report SHOULD be sent when mail > claiming to be from this domain failed the verification algorithm > described in [ADSP]. Fixed. > ERR > adsp-ra-tag =3D %x72.61 *WSP "=3D" qp-section > ^^^^^^^^^^ > ; "ra=3D..." (lower-case only for the tag name) Fixed. > Section 4: remove this sentence, it's not particularly useful? >=20 > ... An exception to this > might be some out-of-band arrangement between two parties to > override it with some mutually agreed value. ... The IESG lately likes to see example cases where one might go against the a= dmonition of a SHOULD NOT, so I think it's reasonable to leave in. > Section 4: tokens vs. tags again. "value" might still be a better word? > > OLD > rr=3D Requested Reports (plain-text; OPTIONAL; default is "all"). The > value MUST be a colon-separated list of tokens representing those > conditions under which a report is desired. See Section 5.2 for a > list of valid tags. ABNF: > NEW > rr=3D Requested Reports (plain-text; OPTIONAL; default is "all"). The > value MUST be a colon-separated list of tokens representing those > conditions under which a report is desired. See Section 5.2 for a > list of valid tokens. ABNF: Fixed. > Section 5: remove extra sentence >=20 > OLD > This memo also includes, as the "ro" "rr" tags defined above, the mean= s by > which the signer can request reports for specific circumstances of > interest. Verifiers MUST NOT generate reports for incidents that do > not match a requested report, and MUST ignore requests for reports > not included in this list. > NEW > The "ro" and "rr" tags allow a Signer to specify the types of errors i= t > is interested in receiving reports about. This section defines > the error types and corresponding token values. >=20 > Verifiers MUST NOT generate reports for incidents that do > not match a requested report, and MUST ignore requests for reports > not included in this list. OK. > Section 8.3: missing context clues >=20 > OLD > Some threats caused by deliberate misuse of this mechanism are > discussed in Section 3.3, but they warrant further discussion here. > NEW > Some threats caused by deliberate misuse of this error reporting > mechanism are discussed in Section 3.3, but they warrant further > discussion here. OK. > Paragraph out of order; this paragraph: > Negative caching offers some protection against this pattern of > abuse, although it will work only as long as the negative time-to- > live on the relevant SOA record in the DNS. >=20 > Please move it to just above the paragraph about positive caching, OK. > as well as making some small changes below: >=20 > OLD > Implementers are therefore strongly advised not to advertise that DNS > record except when reports desired, including the risk of receiving > this kind of attack. >=20 > Positive caching of this DNS reply also means turning off the flow of > reports by removing the record is not likely to have immediate > effect. A low time-to-live on the record needs to be considered. > NEW > Domain owners are therefore strongly advised not to advertise the DNS > records specified in this document except when failure reports are des= ired. > Domain owners ought to be prepared to receive unexpected traffic and a= ttacks. >=20 > Negative caching offers some protection against this pattern of > abuse, although it will work only as long as the negative time-to- > live on the relevant SOA record in the DNS. >=20 > Positive caching of DNS records also means turning off the flow of > reports by removing the record is not likely to have immediate > effect. A low time-to-live on the record needs to be considered. >=20 >=20 > =3D=3D=3D Nits: [list editorial issues such as typographical errors, > preferably by section number] >=20 > Section 3.2: typo at the very last sentence: > OLD > See Section 8.4 for some considerations regardin limitations of this > mechanism. > NEW > See Section 8.4 for some considerations regarding limitations of > this mechanism. Fixed. > Remove the quotes around "tags" -- tags appears as a bare word in > [DKIM], so it's safe to use here, too. I prefer it with the quotes at least on first use. I agreed with almost ev= erything else, so I'll make my stand here. :-) > Choose either "document" or "memo" to refer to this document / memo > throughout. OK. Thanks for the review! -MSK From presnick@qualcomm.com Fri Mar 16 11:18:51 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96BAA21F858B; Fri, 16 Mar 2012 11:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.572 X-Spam-Level: X-Spam-Status: No, score=-106.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1yWhEzoE7f8z; Fri, 16 Mar 2012 11:18:49 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id D872D21F857A; Fri, 16 Mar 2012 11:18:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1331921925; x=1363457925; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-originating-ip; z=Message-ID:=20<4F638401.1030007@qualcomm.com>|Date:=20Fr i,=2016=20Mar=202012=2013:18:41=20-0500|From:=20Pete=20Re snick=20|User-Agent:=20Mozilla/5.0 =20(Macintosh=3B=20U=3B=20Intel=20Mac=20OS=20X=2010.6=3B =20en-US=3B=20rv:1.9.1.9)=20Gecko/20100630=20Eudora/3.0.4 |MIME-Version:=201.0|To:=20Aaron=20Stone=20|CC:=20,=0D=0A=09,=20The=20IESG =20|Subject:=20Re:=20APPSDIR=20review=20of =20draft-ietf-marf-dkim-reporting-15|References:=20|In-Reply-To:=20|Content-Type:=20text /plain=3B=20charset=3D"ISO-8859-1"=3B=20format=3Dflowed |Content-Transfer-Encoding:=207bit|X-Originating-IP:=20[1 72.30.39.5]; bh=WvW5zzBM0yPhEhj+T187clLy/Tr49xF8m8/V74QrEGY=; b=pqGDVaotLlqodIMYzJPkiE3EeJvF2Y3VLw6EumIKMhnrwaCVjopgGXRd 7MWfjQNP/p0Pn2LRtUZYsZmR1YQlBG0D9hEBae/h2VGwYc8YIoY1AdvhJ y4Jz+s2jyZLrHjS2QfApty+3GBVXIoqjQTwb6PeVpHoIWmy0L4SJ3kK1S w=; X-IronPort-AV: E=McAfee;i="5400,1158,6650"; a="173194290" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine01.qualcomm.com with ESMTP; 16 Mar 2012 11:18:45 -0700 X-IronPort-AV: E=Sophos;i="4.73,598,1325491200"; d="scan'208";a="191776502" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/AES128-SHA; 16 Mar 2012 11:18:45 -0700 Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.1.339.1; Fri, 16 Mar 2012 11:18:44 -0700 Message-ID: <4F638401.1030007@qualcomm.com> Date: Fri, 16 Mar 2012 13:18:41 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Aaron Stone References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] Cc: The IESG , apps-discuss@ietf.org, draft-ietf-marf-dkim-reporting.all@tools.ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-marf-dkim-reporting-15 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 16 Mar 2012 18:18:51 -0000 Hi Aaron, Thanks for the review. Murray has addressed many of the issues, but I had a few questions: > === Minor Issues: > > Introduction: > > UPDATED > DomainKeys Identified Mail [DKIM] introduced a mechanism for message > signing and authentication. It uses digital signing to associate a > domain name with a message in a reliable manner. > The verified domain name can then be evaluated before > the message is delivered, e.g., checking advertised sender > policy, comparing to a known-good sender list, submitting to a reputation > service, and so on. > > A message sender employing [DKIM] may want to know when and why > messages received by others fail verification. This applies equally to > verification failures in a message containing DKIM headers, as well as > published signing practices (e.g., Author Domain Signing > Practices, [ADSP]) in an Administrative Management Domain > (ADMD; see [EMAIL-ARCH]). > > This document extends [DKIM] and [ADSP] to add an optional reporting > address and some reporting parameters. Reports are generated using > the format defined in [I-D.IETF-MARF-AUTHFAILURE-REPORT]. > That's an awful lot of rewrite and, even though it's in the intro, I am worried about introducing something that the WG would not agree with. What about the current text are you trying to clarify? Is there something wrong with the current text, or is this just a stylistic change? Similary below: > OLD > When a Signer wishes to advertise that it wants to receive failed > verification reports, it also places in the DNS a TXT resource record > (RR). The RR is made up of a sequence of tag-value objects (much > like DKIM key records, as defined in Section 3.6.1 of [DKIM]), but it > is entirely independent of those key records and is found at a > different name. In the case of a record advertising the desire for > authentication failure reports, the tags and values comprise the > parameters to be used when generating the reports. A report > generator will request the content of this record when it sees an > "r=" tag in a DKIM-Signature header field. > NEW > When a Signer wants to receive reports of failed DKIM verifications, > it adds a TXT resource record (RR) in the DNS, advertising how to > notify the Signer of such failures. The RR contains a sequence of > tag-value objects in a similar format as DKIM key records, specifying > parameters to be used when generating failure reports. > > The TXT record containing failure reporting information MUST be > "_report._domainkey" within the relevant DNS domains. A report > generator will request the contents of this record when it sees an > "r=" tag in a DKIM-Signature header field. > Same issue (but moreso) as in the introduction. What is the clarification you are making or the issue that you are trying to fix? > Section 5: remove extra sentence > > OLD > This memo also includes, as the "ro" "rr" tags defined above, the means by > which the signer can request reports for specific circumstances of > interest. Verifiers MUST NOT generate reports for incidents that do > not match a requested report, and MUST ignore requests for reports > not included in this list. > NEW > The "ro" and "rr" tags allow a Signer to specify the types of errors it > is interested in receiving reports about. This section defines > the error types and corresponding token values. > > Verifiers MUST NOT generate reports for incidents that do > not match a requested report, and MUST ignore requests for reports > not included in this list. > > Again, why? > OLD > Implementers are therefore strongly advised not to advertise that DNS > record except when reports desired, including the risk of receiving > this kind of attack. > > Positive caching of this DNS reply also means turning off the flow of > reports by removing the record is not likely to have immediate > effect. A low time-to-live on the record needs to be considered. > NEW > Domain owners are therefore strongly advised not to advertise the DNS > records specified in this document except when failure reports are desired. > Domain owners ought to be prepared to receive unexpected traffic and attacks. > > Negative caching offers some protection against this pattern of > abuse, although it will work only as long as the negative time-to- > live on the relevant SOA record in the DNS. > > Positive caching of DNS records also means turning off the flow of > reports by removing the record is not likely to have immediate > effect. A low time-to-live on the record needs to be considered. > And this one too. Please explain. Nits I've got no concerns about, and some of the re-ordering and the like is just nits. But since you put these in the "Minor issues" section, I'd like to understand the issues. Thanks again for your thorough review. pr -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From julian.reschke@gmx.de Sat Mar 17 05:50:33 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6EF221F8698 for ; Sat, 17 Mar 2012 05:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.264 X-Spam-Level: X-Spam-Status: No, score=-103.264 tagged_above=-999 required=5 tests=[AWL=-0.665, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0i4JV4YckbCz for ; Sat, 17 Mar 2012 05:50:32 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 6B72121F8697 for ; Sat, 17 Mar 2012 05:50:32 -0700 (PDT) Received: (qmail invoked by alias); 17 Mar 2012 12:50:30 -0000 Received: from p57A6EBC7.dip.t-dialin.net (EHLO [192.168.178.36]) [87.166.235.199] by mail.gmx.net (mp002) with SMTP; 17 Mar 2012 13:50:30 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+kugQX7eGkThRWFXjw2I6BU0bjSfclZyZYHACQuX +jxxfG4A69+CAV Message-ID: <4F648879.4000909@gmx.de> Date: Sat, 17 Mar 2012 13:50:01 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: ietf@ietf.org References: <20120217144555.26744.99147.idtracker@ietfa.amsl.com> <4F3E7816.4070709@gmx.de> In-Reply-To: <4F3E7816.4070709@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: HTTP Working Group , IETF Apps Discuss Subject: Re: [apps-discuss] Last Call: (The Hypertext Transfer Protocol (HTTP) Status Code 308 (Permanent Redirect)) to Experimental RFC X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 17 Mar 2012 12:50:33 -0000 Hi there, the IESG has approved the draft for publication as experimental, but a few details need some tuning. I plan to post a revised draft next Monday (when publication restarts), and have my current version available over here: Diffs relative to the WGLC draft can be found here: The main changes so far are updates to references, an addition of an informal ref to the HTML spec (because of the example using HTML), a warning against attempting to do UA sniffing, plus the inclusion of a note that makes the definition more consistent with what HTTPbis says about status code 307. Feedback appreciated, Julian On 2012-02-17 16:53, Julian Reschke wrote: > (FYI) > > Also, an HTML version with feedback links is available at > . > > Best regards, Julian > > On 2012-02-17 15:45, The IESG wrote: >> >> The IESG has received a request from an individual submitter to consider >> the following document: >> - 'The Hypertext Transfer Protocol (HTTP) Status Code 308 (Permanent >> Redirect)' >> as an Experimental RFC >> >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send substantive comments to the >> ietf@ietf.org mailing lists by 2012-03-16. Exceptionally, comments may be >> sent to iesg@ietf.org instead. In either case, please retain the >> beginning of the Subject line to allow automated sorting. >> >> Abstract >> >> >> This document specifies the additional HyperText Transfer Protocol >> (HTTP) Status Code 308 (Permanent Redirect). >> >> >> >> >> The file can be obtained via >> http://datatracker.ietf.org/doc/draft-reschke-http-status-308/ >> >> IESG discussion can be tracked via >> http://datatracker.ietf.org/doc/draft-reschke-http-status-308/ >> >> >> No IPR declarations have been submitted directly on this I-D. >> >> >> _______________________________________________ >> IETF-Announce mailing list >> IETF-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-announce >> > > > From julian.reschke@gmx.de Sat Mar 17 06:40:38 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E06CA21F867A for ; Sat, 17 Mar 2012 06:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.405 X-Spam-Level: X-Spam-Status: No, score=-103.405 tagged_above=-999 required=5 tests=[AWL=-0.806, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ku7o+7kEdTL for ; Sat, 17 Mar 2012 06:40:37 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 44DEE21F8617 for ; Sat, 17 Mar 2012 06:40:37 -0700 (PDT) Received: (qmail invoked by alias); 17 Mar 2012 13:40:36 -0000 Received: from p57A6EBC7.dip.t-dialin.net (EHLO [192.168.178.36]) [87.166.235.199] by mail.gmx.net (mp037) with SMTP; 17 Mar 2012 14:40:36 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18S/8l/Q7cSEzD8DLgOBSNMQQIJiBWvm6ZTr/TAYN zZThd/v6qBMPVC Message-ID: <4F649435.6000807@gmx.de> Date: Sat, 17 Mar 2012 14:40:05 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: ietf@ietf.org References: <20120217144555.26744.99147.idtracker@ietfa.amsl.com> <4F3E7816.4070709@gmx.de> <4F648879.4000909@gmx.de> In-Reply-To: <4F648879.4000909@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: HTTP Working Group , IETF Apps Discuss Subject: Re: [apps-discuss] Last Call: (The Hypertext Transfer Protocol (HTTP) Status Code 308 (Permanent Redirect)) to Experimental RFC X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 17 Mar 2012 13:40:39 -0000 On 2012-03-17 13:50, Julian Reschke wrote: > Hi there, > > the IESG has approved the draft for publication as experimental, but a > few details need some tuning. > > I plan to post a revised draft next Monday (when publication restarts), > ... Monday, March 26, actually... From aaron@serendipity.cx Mon Mar 19 11:29:45 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA3121F88A3; Mon, 19 Mar 2012 11:29:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.42 X-Spam-Level: X-Spam-Status: No, score=-101.42 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9oDjNU1bWz7u; Mon, 19 Mar 2012 11:29:44 -0700 (PDT) Received: from slice.serendipity.cx (slice.serendipity.cx [67.23.2.90]) by ietfa.amsl.com (Postfix) with ESMTP id A9D0821F8894; Mon, 19 Mar 2012 11:29:44 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by slice.serendipity.cx (Postfix) with ESMTPSA id 89BD5110062; Mon, 19 Mar 2012 11:28:38 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so7988397vcb.31 for ; Mon, 19 Mar 2012 11:29:39 -0700 (PDT) Received: by 10.52.67.19 with SMTP id j19mr4923630vdt.46.1332181778988; Mon, 19 Mar 2012 11:29:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.172.9 with HTTP; Mon, 19 Mar 2012 11:29:18 -0700 (PDT) In-Reply-To: <9452079D1A51524AA5749AD23E00392808EF6E@exch-mbx901.corp.cloudmark.com> References: <9452079D1A51524AA5749AD23E00392808EF6E@exch-mbx901.corp.cloudmark.com> From: Aaron Stone Date: Mon, 19 Mar 2012 11:29:18 -0700 Message-ID: To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: The IESG , "apps-discuss@ietf.org" , "draft-ietf-marf-dkim-reporting.all@tools.ietf.org" Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-marf-dkim-reporting-15 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Mar 2012 18:29:45 -0000 [Text clipped to replied-to sections only] On Fri, Mar 16, 2012 at 10:42 AM, Murray S. Kucherawy w= rote: >> -----Original Message----- >> From: Aaron Stone [mailto:aaron@serendipity.cx] >> Sent: Friday, March 16, 2012 4:11 AM >> To: apps-discuss@ietf.org; draft-ietf-marf-dkim-reporting.all@tools.ietf= .org >> Cc: The IESG >> Subject: APPSDIR review of draft-ietf-marf-dkim-reporting-15 >> >> Document: draft-ietf-marf-dkim-reporting-15 >> Title: Extensions to DKIM for Failure Reporting >> Reviewer: Aaron Stone >> Review Date: 3/15/2012 >> IESG Telechat Date: 3/15/2012 -- >> Please add a note about DKIM selectors. The name "_report._domainkey" >> is in the same namespace as RFC 6376, Section 3.1 Selectors, which take >> the form, "yourselector._domainkey". This effectively states that a >> domain implementing both strategies MUST NOT use "_report" as a >> selector, because of this requirement of the algorithm described in >> Section 3.3: >> >> =A0 =A03. =A0 If the DNS query returns anything other than RCODE 0 (NOER= ROR), >> =A0 =A0 =A0 =A0 or if multiple TXT records are returned, terminate. > > A selector, per RFC6376 Section 3.1, is a set of "sub-domain"s concatenat= ed by periods. =A0A "sub-domain" is defined in Section 4.1.2 of RFC5321 in = a way that disallows underscores. =A0There's therefore no overlap. Of course! I've been using service records so much lately that I lapsed on the whole point of using "_". -- >> Section 2.4 - report generator has an awkward use of "also". Remove the >> world "also": >> >> OLD >> =A0 =A0 ... also designed to ... >> NEW >> =A0 =A0... designed to ... > > Actually the intent there is to indicate this is a slightly atypical Veri= fier in the DKIM sense; it's a DKIM Verifier that also has a report generat= ion capability. =A0I'll say that explicitly. Sounds good. > >> Section 3: >> >> OLD >> =A0 =A0A domain name owner employing [DKIM] for email signing and >> =A0 =A0authentication might want to know when signatures in use by that = ought to be >> =A0 =A0verifiable with specific public keys are not successfully verifyi= ng. >> =A0 =A0Currently there is no such mechanism defined. >> >> =A0 =A0This document adds optional "tags" (as defined in [DKIM]) to the >> =A0 =A0DKIM-Signature header field and the DKIM key record in the DNS, u= sing >> =A0 =A0the formats defined in that specification. >> NEW >> =A0 =A0A domain name owner employing [DKIM] for email signing and >> =A0 =A0authentication might want to know when message recipients are una= ble >> =A0 =A0to verify a message due to problems in the keys published for a d= omain. >> =A0 =A0Currently there is no such mechanism defined. > > This isn't quite right, because there could be no problem with the keys, = but rather message alteration in transit that the signer wants to know abou= t. I had a hard time understanding what "signatures that ought to be verifiable with specific public keys are not successfully verifying" refers to. It's not bad, just a little confusing at first. I don't object to your original text. -- >> Section 3.2: Confusing use of "tags" and "tokens". Edited to use "tokens= ". >> HOWEVER - maybe the word "values" would be better? > > I used "tags" in this context to refer to the left half of "a=3Db" object= s; "tokens" are the elements in a list of values. Sounds good. -- >> Section 4: Confusing language, similar edits as intro to Section 3: >> >> OLD >> =A0 =A0There also exist cases in which a domain name owner employing [AD= SP] >> =A0 =A0for announcing signing practises with DKIM may want to know when >> =A0 =A0messages are received without valid author domain signatures. >> =A0 =A0Currently there is no such mechanism defined. >> >> =A0 =A0This document adds the following optional "tags" (as defined in >> =A0 =A0[ADSP]) to the DKIM ADSP records, using the form defined in that >> =A0 =A0specification: >> NEW >> =A0 =A0A domain name owner employing Author Domain Signing Practices [AD= SP] >> =A0 =A0may also want to know when message recipients are unable to verif= y >> =A0 =A0a message due to errors in the ADSP records. >> =A0 =A0Currently there is no such mechanism defined. > > This is also not quite right. =A0The intent is to allow reporting of mess= ages that fail ADSP checks even when there aren't errors in ADSP records. Ok, my misunderstanding. Original text should remain, though "There also exist cases in which" could be removed :) -- >> Section 4: remove this sentence, it's not particularly useful? >> >> =A0 =A0 =A0 ... An exception to this >> =A0 =A0 =A0 might be some out-of-band arrangement between two parties to >> =A0 =A0 =A0 override it with some mutually agreed value. ... > > The IESG lately likes to see example cases where one might go against the= admonition of a SHOULD NOT, so I think it's reasonable to leave in. Ok. -- > Thanks for the review! Most welcome! Per Pete's note, I apologize for mixing minor technical comments with wordsmithing nits. Aaron From aaron@serendipity.cx Mon Mar 19 11:57:53 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C96F021E8012; Mon, 19 Mar 2012 11:57:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.433 X-Spam-Level: X-Spam-Status: No, score=-101.433 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HMgiqCJ3y8gv; Mon, 19 Mar 2012 11:57:53 -0700 (PDT) Received: from slice.serendipity.cx (slice.serendipity.cx [67.23.2.90]) by ietfa.amsl.com (Postfix) with ESMTP id 1888121F88D6; Mon, 19 Mar 2012 11:57:53 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by slice.serendipity.cx (Postfix) with ESMTPSA id CEB8D110065; Mon, 19 Mar 2012 11:56:47 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so8020275vcb.31 for ; Mon, 19 Mar 2012 11:57:47 -0700 (PDT) Received: by 10.220.142.82 with SMTP id p18mr5261384vcu.5.1332183467924; Mon, 19 Mar 2012 11:57:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.172.9 with HTTP; Mon, 19 Mar 2012 11:57:26 -0700 (PDT) In-Reply-To: <4F638401.1030007@qualcomm.com> References: <4F638401.1030007@qualcomm.com> From: Aaron Stone Date: Mon, 19 Mar 2012 11:57:26 -0700 Message-ID: To: Pete Resnick Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: The IESG , apps-discuss@ietf.org, draft-ietf-marf-dkim-reporting.all@tools.ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-marf-dkim-reporting-15 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 19 Mar 2012 18:57:53 -0000 On Fri, Mar 16, 2012 at 11:18 AM, Pete Resnick wrot= e: > Hi Aaron, > > Thanks for the review. Murray has addressed many of the issues, but I had= a > few questions: I realized that I mixed together some wordsmithing nits with minor issues. Sorry about that, and thank you for calling it out. > >> =3D=3D=3D Minor Issues: >> >> Introduction: >> >> UPDATED >> =A0 =A0DomainKeys Identified Mail [DKIM] introduced a mechanism for mess= age >> =A0 =A0signing and authentication. =A0It uses digital signing to associa= te a >> =A0 =A0domain name with a message in a reliable manner. >> =A0 =A0The verified domain name can then be evaluated before >> =A0 =A0the message is delivered, e.g., checking advertised sender >> =A0 =A0policy, comparing to a known-good sender list, submitting to a >> reputation >> =A0 =A0service, and so on. -- > That's an awful lot of rewrite and, even though it's in the intro, I am > worried about introducing something that the WG would not agree with. Wha= t > about the current text are you trying to clarify? Is there something wron= g > with the current text, or is this just a stylistic change? Similary below= : Mostly style, a little bit of understanding. In this case, I tried to unwind the sentence so that it reads straight through. I withdraw the proposed changes to the intro except as to remove the parentheses. Severity reduced to nit. >> OLD >> =A0 =A0When a Signer wishes to advertise that it wants to receive failed >> =A0 =A0verification reports, it also places in the DNS a TXT resource re= cord >> =A0 =A0(RR). =A0The RR is made up of a sequence of tag-value objects (mu= ch >> =A0 =A0like DKIM key records, as defined in Section 3.6.1 of [DKIM]), bu= t it >> =A0 =A0is entirely independent of those key records and is found at a >> =A0 =A0different name. =A0In the case of a record advertising the desire= for >> =A0 =A0authentication failure reports, the tags and values comprise the >> =A0 =A0parameters to be used when generating the reports. =A0A report >> =A0 =A0generator will request the content of this record when it sees an >> =A0 =A0"r=3D" tag in a DKIM-Signature header field. >> NEW >> =A0 =A0When a Signer wants to receive reports of failed DKIM verificatio= ns, >> =A0 =A0it adds a TXT resource record (RR) in the DNS, advertising how to >> =A0 =A0notify the Signer of such failures. =A0The RR contains a sequence= of >> =A0 =A0tag-value objects in a similar format as DKIM key records, specif= ying >> =A0 =A0parameters to be used when generating failure reports. >> >> =A0 =A0The TXT record containing failure reporting information MUST be >> =A0 =A0"_report._domainkey" within the relevant DNS domains. =A0A report >> =A0 =A0generator will request the contents of this record when it sees a= n >> =A0 =A0"r=3D" tag in a DKIM-Signature header field. >> > > > Same issue (but moreso) as in the introduction. What is the clarification > you are making or the issue that you are trying to fix? Severity reduced to nit. This is totally wordsmithing. Here's what I thought was important: The RR is made up of a sequence of tag-value objects (much like DKIM key records, as defined in Section 3.6.1 of [DKIM]), but it =A0 is entirely independent of those key records and is found at a different name. =A0In the case of a record advertising the desire for =A0authentication failure reports, the tags and values comprise the =A0parameters to be used when generating the reports. These two sentences had low signal to noise, so I combined them into one shorter sentence that got straight to the point. >> Section 5: remove extra sentence >> >> OLD >> =A0 =A0This memo also includes, as the "ro" "rr" tags defined above, the= means >> by >> =A0 =A0which the signer can request reports for specific circumstances o= f >> =A0 =A0interest. =A0Verifiers MUST NOT generate reports for incidents th= at do >> =A0 =A0not match a requested report, and MUST ignore requests for report= s >> =A0 =A0not included in this list. >> NEW >> =A0 =A0The "ro" and "rr" tags allow a Signer to specify the types of err= ors it >> =A0 =A0is interested in receiving reports about. This section defines >> =A0 =A0the error types and corresponding token values. >> >> =A0 =A0Verifiers MUST NOT generate reports for incidents that do >> =A0 =A0not match a requested report, and MUST ignore requests for report= s >> =A0 =A0not included in this list. >> > > Again, why? Nit. Removed the comma splice in the first sentence. Separated the sentences because one introduces the section, and the other states normative requirements. >> OLD >> =A0 =A0Implementers are therefore strongly advised not to advertise that= DNS >> =A0 =A0record except when reports desired, including the risk of receivi= ng >> =A0 =A0this kind of attack. >> >> =A0 =A0Positive caching of this DNS reply also means turning off the flo= w of >> =A0 =A0reports by removing the record is not likely to have immediate >> =A0 =A0effect. =A0A low time-to-live on the record needs to be considere= d. >> NEW >> =A0 =A0Domain owners are therefore strongly advised not to advertise the= DNS >> =A0 =A0records specified in this document except when failure reports ar= e >> desired. >> =A0 =A0Domain owners ought to be prepared to receive unexpected traffic = and >> attacks. >> >> =A0 =A0Negative caching offers some protection against this pattern of >> =A0 =A0abuse, although it will work only as long as the negative time-to= - >> =A0 =A0live on the relevant SOA record in the DNS. >> >> =A0 =A0Positive caching of DNS records also means turning off the flow o= f >> =A0 =A0reports by removing the record is not likely to have immediate >> =A0 =A0effect. =A0A low time-to-live on the record needs to be considere= d. >> > > And this one too. Please explain. The reordered paragraph was a problem, because the negative caching had no context until a few paragraphs later when I got that the topic was DNS caching. Tightening up the sentences was a clarity nit. > Nits I've got no concerns about, and some of the re-ordering and the like= is > just nits. But since you put these in the "Minor issues" section, I'd lik= e > to understand the issues. > > Thanks again for your thorough review. Thanks for your review review! :) Aaron From barryleiba@gmail.com Mon Mar 19 18:42:48 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A73321F876D for ; Mon, 19 Mar 2012 18:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.991 X-Spam-Level: X-Spam-Status: No, score=-102.991 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id irZfAKFaYqQR for ; Mon, 19 Mar 2012 18:42:47 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id A93F621F876F for ; Mon, 19 Mar 2012 18:42:43 -0700 (PDT) Received: by qadc14 with SMTP id c14so995438qad.10 for ; Mon, 19 Mar 2012 18:42:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding; bh=amkzb0yPDGy5LbH4W8t8VCV3eUs7CVPNWC8OYowkzAs=; b=LEs6UmgsZRid7SLDOt7dGRo2IHnFIPBoW/H4SpDqH5VnhDHoHC683yK7g478ZxjYVR QKxHuroeprfeL5jE/RcjESNcrStlSLKuOE4UpcwDaw+a44kbCeEioVLo1GyuUHBVPZEz 2EeEZkBMWLxjqvqJCHXsp61E80cYqNtQQSzLbsk7Bo4MAtvWsZUO540HiiaJzaBqJEZa z/9lLDPMSYnD0BXyq2RZIjed4NdssQBitoVLL1NHwokcMDRcLvYvzB9jGIElGk3i0U61 7s3kq8pTvqdjw6bgL54VhMIKhgWmRi9I7cPzfHtdVX2wbIKGur2Ml4ulGGdh9L6JFZ9R vCkg== MIME-Version: 1.0 Received: by 10.224.58.205 with SMTP id i13mr11065877qah.97.1332207763199; Mon, 19 Mar 2012 18:42:43 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.229.157.210 with HTTP; Mon, 19 Mar 2012 18:42:43 -0700 (PDT) Date: Mon, 19 Mar 2012 21:42:43 -0400 X-Google-Sender-Auth: 7e6HnIxjH0IUNrbjmLYYuHXxvq4 Message-ID: From: Barry Leiba To: Apps Discuss Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: [apps-discuss] CFP: IEEE Internet Computing special issue on Virtualization X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 Mar 2012 01:42:48 -0000 There are a bunch of people here who may be interested in writing papers for the issue below. Please also pass this along to others who you think might be interested. Barry ---------- Forwarded message ---------- IEEE Internet Computing is soliciting papers for a special issue on Virtualization. Final submissions due: 1 July 2012 Publication date: March/April 2013 Please email the guest editors a brief description of the article you plan to submit by 15 June 2012. One of the most famous adages in computer science is that =93any problem in computer science can be solved by an extra level of indirection.=94 Increasingly, that level of indirection takes the form of virtualization, where a resource=92s consumers are provided with a virtual rather than physical version of that resource. This layer of indirection has helped address a multitude of problems, including efficiency, security, high availability, elasticity, fault containment, mobility, and scalability. In the past several years virtualization has gone mainstream, and more and more resources are virtualizable. Although virtual machines are the most obvious example, others include desktop sharing (VNC), virtual networks, virtual storage, and many more. All these have an enormous impact on Internet computing. A key recent use of virtualization is to enable infrastructure-as-a-service clouds. Virtualization lets producers efficiently support many tenants while strongly isolating them from each other, and consumers to be isolated from the specifics of providers=92 physical capacity, allowing, for example, virtual machines to move between different computers and even clouds. This special issue seeks articles from both industry and academia that discuss the application and development of virtualization in the Internet computing space. Topics include - cloud computing; - virtual networks; - storage-area networks; - remote desktops; - security; - performance (in a network context); and - migration of virtual environments. Editors' note: We encourage submissions from both academic and industrial practitioners, especially as they pertain to open source tools or products, but content must have technical merit, not be an advertisement. Questions? Contact Guest Editors Fred Douglis and Orran Krieger (ic2-2013@computer.org= ) All submissions must be original manuscripts of fewer than 5,000 words, focused on Internet technologies and implementations. All manuscripts are subject to peer review on both technical merit and relevance to IC=92s international readership=97primarily system and software design engineers. We do not accept white papers, and we discourage strictly theoretical or mathematical papers. To submit a manuscript, please log on to ScholarOne (https://mc.manuscriptcentral.com:443/ic-cs) to create or access an account, which you can use to log on to IC=92s Author Center and upload your submission. ---------- From ietfc@btconnect.com Tue Mar 20 03:42:54 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D041A21F8658 for ; Tue, 20 Mar 2012 03:42:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_32=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZE7GDfSAb5b for ; Tue, 20 Mar 2012 03:42:54 -0700 (PDT) Received: from mail.btconnect.com (c2bthomr13.btconnect.com [213.123.20.131]) by ietfa.amsl.com (Postfix) with ESMTP id B416A21F8655 for ; Tue, 20 Mar 2012 03:42:53 -0700 (PDT) Received: from host86-162-135-195.range86-162.btcentralplus.com (HELO pc6) ([86.162.135.195]) by c2bthomr13.btconnect.com with SMTP id GTK16895; Tue, 20 Mar 2012 10:42:34 +0000 (GMT) Message-ID: <02f601cd067d$a49ddc20$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Jiankang YAO" , References: <503575970.11554@cnnic.cn> <4A10020DB6464A0BBA535BF75D21A9D9@LENOVO47E041CF> Date: Tue, 20 Mar 2012 10:41:27 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0303.4F685F18.00DB, actions=tag X-Junkmail-Premium-Raw: score=9/50, refid=2.7.2:2012.3.20.101515:17:9.975, ip=86.162.135.195, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, CN_TLD, __URI_NO_PATH, BODY_SIZE_1700_1799, BODYTEXTP_SIZE_3000_LESS, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, HTML_00_01, HTML_00_10, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_2000_LESS, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2bthomr13.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0209.4F685F21.013C,ss=1,re=0.000,fgs=0, ip=0.0.0.0, so=2011-07-25 19:15:43, dmn=2011-05-27 18:58:46, mode=multiengine X-Junkmail-IWF: false Cc: appsawg-chairs@tools.ietf.org Subject: Re: [apps-discuss] WGLC: draft-ietf-appsawg-about-uri-scheme-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 Mar 2012 10:42:55 -0000 The I-D points out the impossibility of specifying how to handle the many different tokens that a browser may encounte and then goes on to tell us what Opera does. I am uncomfortable with a Standards Track document telling us about the behaviour of one and only one product, with, the text being in the body of the I-D, an implication that this text has Normative status (earlier versions of this I-D also included Mozilla Firefox). Nothing wrong with the web browser mentioned but I think that having just the one example is inappropriate; other examples should be mentioned (and they all could be in an Informative appendix). I note too that this has been 'quiet long-lasting'; an interesting combination. Tom Petch ----- Original Message ----- From: "Jiankang YAO" To: Cc: Sent: Tuesday, March 06, 2012 2:00 AM Subject: [apps-discuss] WGLC: draft-ietf-appsawg-about-uri-scheme-03.txt > Dear colleagues, > > This message starts a two-week WGLC on the draft > draft-ietf-appsawg-about-uri-scheme-03.txt. > > Please help to review this draft. If you support publication, please state as > much on the list. If you are opposed to publication, please state > that on the list as well. It is more/only helpful if you give your reasons for > your position as part of your statement. > > Pls send your comments to apps-discuss@ietf.org or appsawg-chairs@tools.ietf.org or editors. > > The WGLC will end on March 20, 2012 at 1:00 UTC. > > > > Best regards, > Jiankang Yao(as a co-chair of APPSAWG) > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > From julian.reschke@gmx.de Tue Mar 20 07:37:30 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79C9521F84A0 for ; Tue, 20 Mar 2012 07:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.419 X-Spam-Level: X-Spam-Status: No, score=-104.419 tagged_above=-999 required=5 tests=[AWL=-1.820, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fvsFxkdMfdGO for ; Tue, 20 Mar 2012 07:37:30 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 77C5921F849C for ; Tue, 20 Mar 2012 07:37:29 -0700 (PDT) Received: (qmail invoked by alias); 20 Mar 2012 14:37:27 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp038) with SMTP; 20 Mar 2012 15:37:27 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19FDytncvVFa736zhcRgOREhBY/6VH49DvAYHcPLm zAD4nUESso3Nms Message-ID: <4F689626.9070500@gmx.de> Date: Tue, 20 Mar 2012 15:37:26 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20120309212231.16366.52439.idtracker@ietfa.amsl.com> In-Reply-To: <20120309212231.16366.52439.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Subject: [apps-discuss] feedback on draft-ietf-appsawg-json-patch-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 Mar 2012 14:37:30 -0000 On 2012-03-09 22:22, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. > ... I'd like to repeat my concern I posted on the -00 version: > On 2012-01-05 02:42, "Martin J. Dürst" wrote: > > ... > > Appendix A: > > The semantics of fragment identifiers depends on the media type. You > need to be clear whether you're trying to define the fragid semantics > for application/json (which as far as I recall doesn't define any), or > something else. > > Yes. I'd propose that you just say you do, and then add a line at the > top saying that your RFC-to-be will update the JSON definition. You'll > also have to note that in an IANA section. > >> ... > > I have to say that I'm getting nervous about this. > > > 1) When this WG adopted this as a work item, was it clear that JSON pointer isn't "a pointer syntax" but "*the* pointer syntax"? > > 2) Also, declaring this the one and only fragment identifier syntax for application/json means that we're closing the door for any future syntax that offers more expressiveness. > > In XML, people tried to handle this problem with a whole framework (XPointer), which doesn't seem to work too well. > > Maybe in this case the solution would be to reserve more delimiter characters that we'll likely need in the future (such as "[", "]", "(", ")", double quotes, single quotes etc). > > Best regards, Julian (see ) Best regards, Julian From julian.reschke@gmx.de Tue Mar 20 09:12:41 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEAEA21F860B for ; Tue, 20 Mar 2012 09:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.386 X-Spam-Level: X-Spam-Status: No, score=-104.386 tagged_above=-999 required=5 tests=[AWL=-1.787, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hyXypou8wOD9 for ; Tue, 20 Mar 2012 09:12:41 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id BAFDC21F85F3 for ; Tue, 20 Mar 2012 09:12:40 -0700 (PDT) Received: (qmail invoked by alias); 20 Mar 2012 16:12:39 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp037) with SMTP; 20 Mar 2012 17:12:39 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/IYHtyAnzIYE8Se4hH4Xj1HgZW3nu67iSnyJ2oMU xVDycJqabpzUmX Message-ID: <4F68AC76.40904@gmx.de> Date: Tue, 20 Mar 2012 17:12:38 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "Paul C. Bryan" References: <4ED64A26.5030003@gmx.de> <4ED77513.3070506@gmx.de> <6E443D75-D1AC-451F-9B17-115C9A6C7696@mnot.net> <4ED7F8C2.9030804@gmx.de> <37E09A53-E9F4-45D2-BB8F-79655BECDBB2@mnot.net> <1322779521.1958.1.camel@neutron> <4EFC8A08.7000105@gmx.de> <1325222688.18477.25.camel@neutron> In-Reply-To: <1325222688.18477.25.camel@neutron> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] more feature requests, was: JSON patch: "test" operation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 Mar 2012 16:12:41 -0000 On 2011-12-30 06:24, Paul C. Bryan wrote: > On Thu, 2011-12-29 at 16:40 +0100, Julian Reschke wrote: >> Hi there, >> >> in discussions in Apache Jackrabbit space, two more features have been >> mentioned as potentially useful: >> >> 1) The ability to send additional data along with the actual patch; such >> as a plain text string describing the change (think "commit" message), >> or user information. > > I've had a few thoughts here. > > First, I think commit messages should probably be out of scope for JSON > Patch specifically. That said, we should allow the ability to build on > the specified format, allowing for extensions, including additional > (more domain-specific) operations. > > I'm generally against the idea of using out-of-band metadata such as > header fields in an HTTP request, mostly because it ties metadata to the > transfer protocol rather (what I believe rightly should be tied to the > document). > > I'm interested in feedback on the possibility that I add text stating > that if an operation cannot be determined for a given patch object, then > an implementation should ignore it. Thoughts? > ... That's exactly the question we need to answer; is the extensibility model "must understand" or is it "must ignore"? In the latter case, people can define their own operators, such as "commit-message". But of course it would make it harder to define new operators later on. If JSON had a comment syntax there would be a simple, although a bit hacky way to extend the format. But it does not... Best regards, Julian From pbryan@anode.ca Tue Mar 20 09:32:29 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1AF521F86A8 for ; Tue, 20 Mar 2012 09:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ErnTGi1Uh9Wp for ; Tue, 20 Mar 2012 09:32:28 -0700 (PDT) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id E3FD921F8557 for ; Tue, 20 Mar 2012 09:32:27 -0700 (PDT) Received: from [192.168.11.246] (unknown [209.52.95.5]) by maple.anode.ca (Postfix) with ESMTPSA id D21DA6456 for ; Tue, 20 Mar 2012 16:32:26 +0000 (UTC) Message-ID: <1332261146.2171.7.camel@neutron> From: "Paul C. Bryan" To: apps-discuss@ietf.org Date: Tue, 20 Mar 2012 09:32:26 -0700 In-Reply-To: <4F689626.9070500@gmx.de> References: <20120309212231.16366.52439.idtracker@ietfa.amsl.com> <4F689626.9070500@gmx.de> Content-Type: multipart/alternative; boundary="=-zztBN4mdbcmwFIG5AOpR" X-Mailer: Evolution 3.2.2-1 Mime-Version: 1.0 Subject: Re: [apps-discuss] feedback on draft-ietf-appsawg-json-patch-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 Mar 2012 16:32:29 -0000 --=-zztBN4mdbcmwFIG5AOpR Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit I happen to think JSON Pointer should be the pointer syntax for fragment identifiers used by JSON Patch, not application/json per se. I don't currently see why one would need to amend the JSON specification to support this; any JSON Patch implementation should be fully capable of resolving fragment identifiers itself. Paul On Tue, 2012-03-20 at 15:37 +0100, Julian Reschke wrote: > On 2012-03-09 22:22, internet-drafts@ietf.org wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. > > ... > > I'd like to repeat my concern I posted on the -00 version: > > > On 2012-01-05 02:42, "Martin J. Dürst" wrote: > > > > ... > > > > Appendix A: > > > > The semantics of fragment identifiers depends on the media type. You > > need to be clear whether you're trying to define the fragid semantics > > for application/json (which as far as I recall doesn't define any), or > > something else. > > > > Yes. I'd propose that you just say you do, and then add a line at the > > top saying that your RFC-to-be will update the JSON definition. You'll > > also have to note that in an IANA section. > > > >> ... > > > > I have to say that I'm getting nervous about this. > > > > > > 1) When this WG adopted this as a work item, was it clear that JSON pointer isn't "a pointer syntax" but "*the* pointer syntax"? > > > > 2) Also, declaring this the one and only fragment identifier syntax for application/json means that we're closing the door for any future syntax that offers more expressiveness. > > > > In XML, people tried to handle this problem with a whole framework (XPointer), which doesn't seem to work too well. > > > > Maybe in this case the solution would be to reserve more delimiter characters that we'll likely need in the future (such as "[", "]", "(", ")", double quotes, single quotes etc). > > > > Best regards, Julian > > (see > ) > > Best regards, Julian > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --=-zztBN4mdbcmwFIG5AOpR Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit I happen to think JSON Pointer should be the pointer syntax for fragment identifiers used by JSON Patch, not application/json per se. I don't currently see why one would need to amend the JSON specification to support this; any JSON Patch implementation should be fully capable of resolving fragment identifiers itself.

Paul

On Tue, 2012-03-20 at 15:37 +0100, Julian Reschke wrote: 
On 2012-03-09 22:22, internet-drafts@ietf.org wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF.
> ...

I'd like to repeat my concern I posted on the -00 version:

> On 2012-01-05 02:42, "Martin J. Dürst" wrote:
>
>     ...
>
>         Appendix A:
>
>         The semantics of fragment identifiers depends on the media type. You
>         need to be clear whether you're trying to define the fragid semantics
>         for application/json (which as far as I recall doesn't define any), or
>         something else.
>
>     Yes. I'd propose that you just say you do, and then add a line at the
>     top saying that your RFC-to-be will update the JSON definition. You'll
>     also have to note that in an IANA section.
>
>> ...
>
> I have to say that I'm getting nervous about this.
>
>
> 1) When this WG adopted this as a work item, was it clear that JSON pointer isn't "a pointer syntax" but "*the* pointer syntax"?
>
> 2) Also, declaring this the one and only fragment identifier syntax for application/json means that we're closing the door for any future syntax that offers more expressiveness.
>
> In XML, people tried to handle this problem with a whole framework (XPointer), which doesn't seem to work too well.
>
> Maybe in this case the solution would be to reserve more delimiter characters that we'll likely need in the future (such as "[", "]", "(", ")", double quotes, single quotes etc).
>
> Best regards, Julian

(see 
<http://www.ietf.org/mail-archive/web/apps-discuss/current/msg04035.html>)

Best regards, Julian
_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--=-zztBN4mdbcmwFIG5AOpR-- From pbryan@anode.ca Tue Mar 20 09:34:05 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5155E21F8637 for ; Tue, 20 Mar 2012 09:34:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m+jXV0PifhHz for ; Tue, 20 Mar 2012 09:34:04 -0700 (PDT) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id 9BDB021F8634 for ; Tue, 20 Mar 2012 09:34:04 -0700 (PDT) Received: from [192.168.11.246] (unknown [209.52.95.5]) by maple.anode.ca (Postfix) with ESMTPSA id 3DDB86456 for ; Tue, 20 Mar 2012 16:34:04 +0000 (UTC) Message-ID: <1332261243.2171.8.camel@neutron> From: "Paul C. Bryan" To: IETF Apps Discuss Date: Tue, 20 Mar 2012 09:34:03 -0700 In-Reply-To: <4F68AC76.40904@gmx.de> References: <4ED64A26.5030003@gmx.de> <4ED77513.3070506@gmx.de> <6E443D75-D1AC-451F-9B17-115C9A6C7696@mnot.net> <4ED7F8C2.9030804@gmx.de> <37E09A53-E9F4-45D2-BB8F-79655BECDBB2@mnot.net> <1322779521.1958.1.camel@neutron> <4EFC8A08.7000105@gmx.de> <1325222688.18477.25.camel@neutron> <4F68AC76.40904@gmx.de> Content-Type: multipart/alternative; boundary="=-ZBjPDt3KbGBro4S80ChY" X-Mailer: Evolution 3.2.2-1 Mime-Version: 1.0 Subject: Re: [apps-discuss] more feature requests, was: JSON patch: "test" operation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 Mar 2012 16:34:05 -0000 --=-ZBjPDt3KbGBro4S80ChY Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit This was discussed previously, and the consensus at the time was for must-understand. Paul On Tue, 2012-03-20 at 17:12 +0100, Julian Reschke wrote: > On 2011-12-30 06:24, Paul C. Bryan wrote: > > On Thu, 2011-12-29 at 16:40 +0100, Julian Reschke wrote: > >> Hi there, > >> > >> in discussions in Apache Jackrabbit space, two more features have been > >> mentioned as potentially useful: > >> > >> 1) The ability to send additional data along with the actual patch; such > >> as a plain text string describing the change (think "commit" message), > >> or user information. > > > > I've had a few thoughts here. > > > > First, I think commit messages should probably be out of scope for JSON > > Patch specifically. That said, we should allow the ability to build on > > the specified format, allowing for extensions, including additional > > (more domain-specific) operations. > > > > I'm generally against the idea of using out-of-band metadata such as > > header fields in an HTTP request, mostly because it ties metadata to the > > transfer protocol rather (what I believe rightly should be tied to the > > document). > > > > I'm interested in feedback on the possibility that I add text stating > > that if an operation cannot be determined for a given patch object, then > > an implementation should ignore it. Thoughts? > > ... > > That's exactly the question we need to answer; is the extensibility > model "must understand" or is it "must ignore"? In the latter case, > people can define their own operators, such as "commit-message". But of > course it would make it harder to define new operators later on. > > If JSON had a comment syntax there would be a simple, although a bit > hacky way to extend the format. But it does not... > > Best regards, Julian > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --=-ZBjPDt3KbGBro4S80ChY Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit This was discussed previously, and the consensus at the time was for must-understand.

Paul

On Tue, 2012-03-20 at 17:12 +0100, Julian Reschke wrote: 
On 2011-12-30 06:24, Paul C. Bryan wrote:
> On Thu, 2011-12-29 at 16:40 +0100, Julian Reschke wrote:
>> Hi there,
>>
>> in discussions in Apache Jackrabbit space, two more features have been
>> mentioned as potentially useful:
>>
>> 1) The ability to send additional data along with the actual patch; such
>> as a plain text string describing the change (think "commit" message),
>> or user information.
>
> I've had a few thoughts here.
>
> First, I think commit messages should probably be out of scope for JSON
> Patch specifically. That said, we should allow the ability to build on
> the specified format, allowing for extensions, including additional
> (more domain-specific) operations.
>
> I'm generally against the idea of using out-of-band metadata such as
> header fields in an HTTP request, mostly because it ties metadata to the
> transfer protocol rather (what I believe rightly should be tied to the
> document).
>
> I'm interested in feedback on the possibility that I add text stating
> that if an operation cannot be determined for a given patch object, then
> an implementation should ignore it. Thoughts?
> ...

That's exactly the question we need to answer; is the extensibility 
model "must understand" or is it "must ignore"? In the latter case, 
people can define their own operators, such as "commit-message". But of 
course it would make it harder to define new operators later on.

If JSON had a comment syntax there would be a simple, although a bit 
hacky way to extend the format. But it does not...

Best regards, Julian
_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--=-ZBjPDt3KbGBro4S80ChY-- From julian.reschke@gmx.de Tue Mar 20 09:42:42 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86D1621F8712 for ; Tue, 20 Mar 2012 09:42:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.37 X-Spam-Level: X-Spam-Status: No, score=-104.37 tagged_above=-999 required=5 tests=[AWL=-1.771, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7UGBFV6aRTWR for ; Tue, 20 Mar 2012 09:42:42 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 94F3321F8709 for ; Tue, 20 Mar 2012 09:42:41 -0700 (PDT) Received: (qmail invoked by alias); 20 Mar 2012 16:42:39 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp028) with SMTP; 20 Mar 2012 17:42:39 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/fmPgXqlTf1H60aY+E/TcrGfNrIhkVNGw9kbntpP LAZE/pLOBessvM Message-ID: <4F68B37E.9060608@gmx.de> Date: Tue, 20 Mar 2012 17:42:38 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "Paul C. Bryan" References: <20120309212231.16366.52439.idtracker@ietfa.amsl.com> <4F689626.9070500@gmx.de> <1332261146.2171.7.camel@neutron> In-Reply-To: <1332261146.2171.7.camel@neutron> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] feedback on draft-ietf-appsawg-json-patch-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 Mar 2012 16:42:42 -0000 On 2012-03-20 17:32, Paul C. Bryan wrote: > I happen to think JSON Pointer should be the pointer syntax for fragment > identifiers used by JSON Patch, not application/json per se. I don't > currently see why one would need to amend the JSON specification to > support this; any JSON Patch implementation should be fully capable of > resolving fragment identifiers itself. > ... +1 on that, but in that case Section 6 and the examples in appendix A (using pointers in fragment identifiers) should be removed. We can't say that we aren't defining the fragment syntax for application/json, but then have examples doing the opposite. Best regards, Julian From julian.reschke@gmx.de Tue Mar 20 09:46:56 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD13621F86A4 for ; Tue, 20 Mar 2012 09:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.355 X-Spam-Level: X-Spam-Status: No, score=-104.355 tagged_above=-999 required=5 tests=[AWL=-1.756, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pR12Th9wFphp for ; Tue, 20 Mar 2012 09:46:56 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id EA19721F867C for ; Tue, 20 Mar 2012 09:46:55 -0700 (PDT) Received: (qmail invoked by alias); 20 Mar 2012 16:46:54 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp020) with SMTP; 20 Mar 2012 17:46:54 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18ednhg9Uwe0m5fSjwXP/H8xhTPEvC8eHRmd+ydOV Rw2osIAGBGDd1Z Message-ID: <4F68B47E.3010406@gmx.de> Date: Tue, 20 Mar 2012 17:46:54 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "Paul C. Bryan" References: <4ED64A26.5030003@gmx.de> <4ED77513.3070506@gmx.de> <6E443D75-D1AC-451F-9B17-115C9A6C7696@mnot.net> <4ED7F8C2.9030804@gmx.de> <37E09A53-E9F4-45D2-BB8F-79655BECDBB2@mnot.net> <1322779521.1958.1.camel@neutron> <4EFC8A08.7000105@gmx.de> <1325222688.18477.25.camel@neutron> <4F68AC76.40904@gmx.de> <1332261243.2171.8.camel@neutron> In-Reply-To: <1332261243.2171.8.camel@neutron> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] more feature requests, was: JSON patch: "test" operation X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 Mar 2012 16:46:57 -0000 On 2012-03-20 17:34, Paul C. Bryan wrote: > This was discussed previously, and the consensus at the time was for > must-understand. > ... OK; in which case should state this as an error condition. It currently says: The operation to perform is expressed in a member of the operation object. The name of the operation member is one of: "add", "remove", "replace", "move", "copy" or "test". The member value is a string containing a [JSON-Pointer] value, which references the location within the target document to perform the operation. It is an error condition if an operation object contains no recognized operation member or more than one operation member. So { "test": "/a/b/c", "value": "foo", "julians-extension" : "bar" } would be legal (so you could augment each operation with additional information, but not the patch document itself). Best regards, Julian From pbryan@anode.ca Tue Mar 20 09:54:44 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5400821F85D6 for ; Tue, 20 Mar 2012 09:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MlH10DD-oYrm for ; Tue, 20 Mar 2012 09:54:43 -0700 (PDT) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id D409521F85A1 for ; Tue, 20 Mar 2012 09:54:43 -0700 (PDT) Received: from [192.168.11.246] (unknown [209.52.95.5]) by maple.anode.ca (Postfix) with ESMTPSA id 5EDDB616A for ; Tue, 20 Mar 2012 16:54:43 +0000 (UTC) Message-ID: <1332262482.2171.11.camel@neutron> From: "Paul C. Bryan" To: apps-discuss@ietf.org Date: Tue, 20 Mar 2012 09:54:42 -0700 In-Reply-To: <4F68B37E.9060608@gmx.de> References: <20120309212231.16366.52439.idtracker@ietfa.amsl.com> <4F689626.9070500@gmx.de> <1332261146.2171.7.camel@neutron> <4F68B37E.9060608@gmx.de> Content-Type: multipart/alternative; boundary="=-8Abxb8lr8mRfiongMZu/" X-Mailer: Evolution 3.2.2-1 Mime-Version: 1.0 Subject: Re: [apps-discuss] feedback on draft-ietf-appsawg-json-patch-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 Mar 2012 16:54:44 -0000 --=-8Abxb8lr8mRfiongMZu/ Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Why remove Section 6? Where are fragment identifiers being used in Appendix A? Paul On Tue, 2012-03-20 at 17:42 +0100, Julian Reschke wrote: > On 2012-03-20 17:32, Paul C. Bryan wrote: > > I happen to think JSON Pointer should be the pointer syntax for fragment > > identifiers used by JSON Patch, not application/json per se. I don't > > currently see why one would need to amend the JSON specification to > > support this; any JSON Patch implementation should be fully capable of > > resolving fragment identifiers itself. > > ... > > +1 on that, but in that case Section 6 and the examples in appendix A > (using pointers in fragment identifiers) should be removed. > > We can't say that we aren't defining the fragment syntax for > application/json, but then have examples doing the opposite. > > Best regards, Julian --=-8Abxb8lr8mRfiongMZu/ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit Why remove Section 6? Where are fragment identifiers being used in Appendix A?

Paul

On Tue, 2012-03-20 at 17:42 +0100, Julian Reschke wrote: 
On 2012-03-20 17:32, Paul C. Bryan wrote:
> I happen to think JSON Pointer should be the pointer syntax for fragment
> identifiers used by JSON Patch, not application/json per se. I don't
> currently see why one would need to amend the JSON specification to
> support this; any JSON Patch implementation should be fully capable of
> resolving fragment identifiers itself.
> ...

+1 on that, but in that case Section 6 and the examples in appendix A 
(using pointers in fragment identifiers) should be removed.

We can't say that we aren't defining the fragment syntax for 
application/json, but then have examples doing the opposite.

Best regards, Julian

--=-8Abxb8lr8mRfiongMZu/-- From julian.reschke@gmx.de Tue Mar 20 10:26:18 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 028A121F86E2 for ; Tue, 20 Mar 2012 10:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.34 X-Spam-Level: X-Spam-Status: No, score=-104.34 tagged_above=-999 required=5 tests=[AWL=-1.741, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G8HsejBlKHQb for ; Tue, 20 Mar 2012 10:26:17 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 0F44121F8684 for ; Tue, 20 Mar 2012 10:26:16 -0700 (PDT) Received: (qmail invoked by alias); 20 Mar 2012 17:26:16 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp033) with SMTP; 20 Mar 2012 18:26:16 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX189inlb92o9WoNSRoRdJX+Iap2a2K1k2AetLUksGg wRDwXI1+JHs00j Message-ID: <4F68BDB7.7030808@gmx.de> Date: Tue, 20 Mar 2012 18:26:15 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "Paul C. Bryan" References: <20120309212231.16366.52439.idtracker@ietfa.amsl.com> <4F689626.9070500@gmx.de> <1332261146.2171.7.camel@neutron> <4F68B37E.9060608@gmx.de> <1332262482.2171.11.camel@neutron> In-Reply-To: <1332262482.2171.11.camel@neutron> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] feedback on draft-ietf-appsawg-json-patch-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 Mar 2012 17:26:18 -0000 On 2012-03-20 17:54, Paul C. Bryan wrote: > Why remove Section 6? Where are fragment identifiers being used in > Appendix A? Section 6 says: 6. URI Fragment Identifier Representation A JSON Pointer MAY be represented in a URI fragment identifier. The JSON pointer MUST be UTF-8 [RFC3629] encoded as octets; octets not in the URI "unreserved" set SHOULD be percent-encoded, per [RFC3986], section 2.5. What's the point of making this statement? What media type is this about? Appendix A contains: http://example.com/example.json#/foo/inner%20object Resolves to the object value of the "inner object" member in the "foo" object value in the root object. http://example.com/example.json#/foo/inner%20object/baz Resolves to the string value "qux", which is the value of the "baz" member in the "inner object" member in the "foo" member in the root object. http://example.com/example.json#/foo/bar/0 Resolves to the string value "element0", which is the first value in the "bar" array in the "foo" member in the root object. ...which to me reads like using JSON pointers as fragment identifiers for payloads of type application/json. If that's not the case, it should be clarified somehow. Going back two mails you said: > I happen to think JSON Pointer should be the pointer syntax for fragment identifiers used by JSON Patch, not application/json per se. In that case however the JSON Patch specification should state in the media type registration what the fragment syntax is (see fourth item), and the JSON Pointer spec should clarify that both Section 6 and the examples in the appendix are about media types that have chosen to use JSON pointer as fragment identifier, which is not the case for application/json. Right now it's way too easy for people to jump to the conclusion that JSON Pointer *is* the fragment identifier syntax for application/json. Best regards, Julian From pbryan@anode.ca Tue Mar 20 11:44:37 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65FAA21F8557 for ; Tue, 20 Mar 2012 11:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yD6OB6P4CqLS for ; Tue, 20 Mar 2012 11:44:36 -0700 (PDT) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id 8196821F854A for ; Tue, 20 Mar 2012 11:44:36 -0700 (PDT) Received: from [192.168.11.246] (unknown [209.52.95.5]) by maple.anode.ca (Postfix) with ESMTPSA id CB3A36456 for ; Tue, 20 Mar 2012 18:44:35 +0000 (UTC) Message-ID: <1332269074.2171.21.camel@neutron> From: "Paul C. Bryan" To: apps-discuss@ietf.org Date: Tue, 20 Mar 2012 11:44:34 -0700 In-Reply-To: <4F68BDB7.7030808@gmx.de> References: <20120309212231.16366.52439.idtracker@ietfa.amsl.com> <4F689626.9070500@gmx.de> <1332261146.2171.7.camel@neutron> <4F68B37E.9060608@gmx.de> <1332262482.2171.11.camel@neutron> <4F68BDB7.7030808@gmx.de> Content-Type: multipart/alternative; boundary="=-+wYDg3vU/Z12trYopwJ0" X-Mailer: Evolution 3.2.2-1 Mime-Version: 1.0 Subject: Re: [apps-discuss] feedback on draft-ietf-appsawg-json-patch-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 Mar 2012 18:44:37 -0000 --=-+wYDg3vU/Z12trYopwJ0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Tue, 2012-03-20 at 18:26 +0100, Julian Reschke wrote: > On 2012-03-20 17:54, Paul C. Bryan wrote: > > Why remove Section 6? Where are fragment identifiers being used in > > Appendix A? > > Section 6 says: > > 6. URI Fragment Identifier Representation > > A JSON Pointer MAY be represented in a URI fragment identifier. > The > JSON pointer MUST be UTF-8 [RFC3629] encoded as octets; octets not > in > the URI "unreserved" set SHOULD be percent-encoded, per [RFC3986], > section 2.5. > > What's the point of making this statement? What media type is this > about? Okay, sorry, didn't know you were referring to the JSON Pointer spec when referencing these sections. The intent of JSON Pointer is to be expressed in a URI fragment identifier for resources that have JSON representations. To that end, it makes sense to establish the rules for encoding pointers in URIs. > Appendix A contains: > > http://example.com/example.json#/foo/inner%20object > Resolves to the object value of the "inner object" member in > the > "foo" object value in the root object. > > http://example.com/example.json#/foo/inner%20object/baz > Resolves to the string value "qux", which is the value of the > "baz" member in the "inner object" member in the "foo" member > in > the root object. > > http://example.com/example.json#/foo/bar/0 > Resolves to the string value "element0", which is the first > value > in the "bar" array in the "foo" member in the root object. > > ...which to me reads like using JSON pointers as fragment identifiers > for payloads of type application/json. If that's not the case, it > should > be clarified somehow. > > Going back two mails you said: > > > I happen to think JSON Pointer should be the pointer syntax for > fragment identifiers used by JSON Patch, not application/json per se. I'll now retract this statement. I don't think fragments should have anything to do with JSON Patch, and there's nothing in the JSON Patch spec where fragments are in use. > In that case however the JSON Patch specification should state in the > media type registration what the fragment syntax is (see > > fourth item), and the JSON Pointer spec should clarify that both > Section > 6 and the examples in the appendix are about media types that have > chosen to use JSON pointer as fragment identifier, which is not the > case > for application/json. I don't think it makes a lot of sense for JSON Pointer spec to reference every spec that happens to reference it. > Right now it's way too easy for people to jump to the conclusion that > JSON Pointer *is* the fragment identifier syntax for application/json. Simply based on the JSON Pointer spec text itself? Paul --=-+wYDg3vU/Z12trYopwJ0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit On Tue, 2012-03-20 at 18:26 +0100, Julian Reschke wrote:
On 2012-03-20 17:54, Paul C. Bryan wrote:
> Why remove Section 6? Where are fragment identifiers being used in
> Appendix A?

Section 6 says:

6. URI Fragment Identifier Representation

A JSON Pointer MAY be represented in a URI fragment identifier. The
JSON pointer MUST be UTF-8 [RFC3629] encoded as octets; octets not in
the URI "unreserved" set SHOULD be percent-encoded, per [RFC3986],
section 2.5.

What's the point of making this statement? What media type is this about?

Okay, sorry, didn't know you were referring to the JSON Pointer spec when referencing these sections.

The intent of JSON Pointer is to be expressed in a URI fragment identifier for resources that have JSON representations. To that end, it makes sense to establish the rules for encoding pointers in URIs.

Appendix A contains:

http://example.com/example.json#/foo/inner%20object
Resolves to the object value of the "inner object" member in the
"foo" object value in the root object.

http://example.com/example.json#/foo/inner%20object/baz
Resolves to the string value "qux", which is the value of the
"baz" member in the "inner object" member in the "foo" member in
the root object.

http://example.com/example.json#/foo/bar/0
Resolves to the string value "element0", which is the first value
in the "bar" array in the "foo" member in the root object.

...which to me reads like using JSON pointers as fragment identifiers
for payloads of type application/json. If that's not the case, it should
be clarified somehow.

Going back two mails you said:

> I happen to think JSON Pointer should be the pointer syntax for fragment identifiers used by JSON Patch, not application/json per se.

I'll now retract this statement. I don't think fragments should have anything to do with JSON Patch, and there's nothing in the JSON Patch spec where fragments are in use.

In that case however the JSON Patch specification should state in the
media type registration what the fragment syntax is (see
<http://trac.tools.ietf.org/html/draft-ietf-appsawg-media-type-regs-03#appendix-C>
fourth item), and the JSON Pointer spec should clarify that both Section
6 and the examples in the appendix are about media types that have
chosen to use JSON pointer as fragment identifier, which is not the case
for application/json.

I don't think it makes a lot of sense for JSON Pointer spec to reference every spec that happens to reference it.

Right now it's way too easy for people to jump to the conclusion that JSON Pointer *is* the fragment identifier syntax for application/json.

Simply based on the JSON Pointer spec text itself?

Paul --=-+wYDg3vU/Z12trYopwJ0-- From julian.reschke@gmx.de Tue Mar 20 11:55:22 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F1D921F8537 for ; Tue, 20 Mar 2012 11:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.439 X-Spam-Level: X-Spam-Status: No, score=-103.439 tagged_above=-999 required=5 tests=[AWL=-0.840, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YKxxFgHZBj7Y for ; Tue, 20 Mar 2012 11:55:21 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 2BDD021F8513 for ; Tue, 20 Mar 2012 11:55:20 -0700 (PDT) Received: (qmail invoked by alias); 20 Mar 2012 18:55:19 -0000 Received: from p57A6E8EB.dip.t-dialin.net (EHLO [192.168.178.36]) [87.166.232.235] by mail.gmx.net (mp038) with SMTP; 20 Mar 2012 19:55:19 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+CXlh5ovCCGs1aYBbZGecCOGTDUXerfl09ccAG4G ogI+q6sqKGP40Q Message-ID: <4F68D295.2040401@gmx.de> Date: Tue, 20 Mar 2012 19:55:17 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "Paul C. Bryan" References: <20120309212231.16366.52439.idtracker@ietfa.amsl.com> <4F689626.9070500@gmx.de> <1332261146.2171.7.camel@neutron> <4F68B37E.9060608@gmx.de> <1332262482.2171.11.camel@neutron> <4F68BDB7.7030808@gmx.de> <1332269074.2171.21.camel@neutron> In-Reply-To: <1332269074.2171.21.camel@neutron> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] feedback on draft-ietf-appsawg-json-patch-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 Mar 2012 18:55:22 -0000 On 2012-03-20 19:44, Paul C. Bryan wrote: > ... > The intent of JSON Pointer is to be expressed in a URI fragment > identifier for resources that have JSON representations. To that end, it > makes sense to establish the rules for encoding pointers in URIs. > ... So is the intent to define the fragment identifier syntax for application/json or not? If it is, we need to normatively update the JSON RFC, and need to make sure there's really consensus on this. If it is not, the way the Pointer spec currently is written is very confusing. > ... > I don't think it makes a lot of sense for JSON Pointer spec to reference > every spec that happens to reference it. > ... What needs to be clear is to what media types the fragment syntax applies. All JSON-shaped? application/json? Future json-types, on an opt-in basis? >> Right now it's way too easy for people to jump to the conclusion that >> JSON Pointer *is* the fragment identifier syntax for application/json. > > Simply based on the JSON Pointer spec text itself? Yes. Best regards, Julian From pbryan@anode.ca Tue Mar 20 14:01:37 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBAF321F85D9 for ; Tue, 20 Mar 2012 14:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7kddBYYykuN6 for ; Tue, 20 Mar 2012 14:01:36 -0700 (PDT) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id 646D421F8624 for ; Tue, 20 Mar 2012 14:01:36 -0700 (PDT) Received: from [192.168.11.246] (unknown [209.52.95.5]) by maple.anode.ca (Postfix) with ESMTPSA id A2FF8616A for ; Tue, 20 Mar 2012 21:01:35 +0000 (UTC) Message-ID: <1332277294.2171.25.camel@neutron> From: "Paul C. Bryan" To: apps-discuss@ietf.org Date: Tue, 20 Mar 2012 14:01:34 -0700 In-Reply-To: <4F68D295.2040401@gmx.de> References: <20120309212231.16366.52439.idtracker@ietfa.amsl.com> <4F689626.9070500@gmx.de> <1332261146.2171.7.camel@neutron> <4F68B37E.9060608@gmx.de> <1332262482.2171.11.camel@neutron> <4F68BDB7.7030808@gmx.de> <1332269074.2171.21.camel@neutron> <4F68D295.2040401@gmx.de> Content-Type: multipart/alternative; boundary="=-b9yZg7DKhNpijgbagVsa" X-Mailer: Evolution 3.2.2-1 Mime-Version: 1.0 Subject: Re: [apps-discuss] feedback on draft-ietf-appsawg-json-patch-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 Mar 2012 21:01:37 -0000 --=-b9yZg7DKhNpijgbagVsa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Tue, 2012-03-20 at 19:55 +0100, Julian Reschke wrote: > So is the intent to define the fragment identifier syntax for > application/json or not? It wasn't my intent originally, though your concerns have me think that perhaps we should consider it. It was to define a fragment identifier syntax, which other specifications (e.g. JSON Schema, JSON Reference) can reference. > If it is, we need to normatively update the JSON RFC, and need to make > sure there's really consensus on this. Question: Do you think it should? > If it is not, the way the Pointer spec currently is written is very > confusing. Any text suggestions to resolve this? Paul --=-b9yZg7DKhNpijgbagVsa Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit On Tue, 2012-03-20 at 19:55 +0100, Julian Reschke wrote:

So is the intent to define the fragment identifier syntax for 
application/json or not?

It wasn't my intent originally, though your concerns have me think that perhaps we should consider it. It was to define a fragment identifier syntax, which other specifications (e.g. JSON Schema, JSON Reference) can reference.

If it is, we need to normatively update the JSON RFC, and need to make 
sure there's really consensus on this.

Question: Do you think it should?

If it is not, the way the Pointer spec currently is written is very 
confusing.

Any text suggestions to resolve this?

Paul --=-b9yZg7DKhNpijgbagVsa-- From julian.reschke@gmx.de Tue Mar 20 14:13:33 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 827CE21F866A for ; Tue, 20 Mar 2012 14:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.649 X-Spam-Level: X-Spam-Status: No, score=-103.649 tagged_above=-999 required=5 tests=[AWL=-1.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sZR467URduYp for ; Tue, 20 Mar 2012 14:13:32 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 31AAD21F8679 for ; Tue, 20 Mar 2012 14:13:31 -0700 (PDT) Received: (qmail invoked by alias); 20 Mar 2012 21:13:30 -0000 Received: from p57A6E8EB.dip.t-dialin.net (EHLO [192.168.178.36]) [87.166.232.235] by mail.gmx.net (mp001) with SMTP; 20 Mar 2012 22:13:30 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+5GjkRoYq5gmrg2+H3RJku5CO6z9FMLbt/OS4OOw 76Ss3idLVyj4m+ Message-ID: <4F68F2F8.7000207@gmx.de> Date: Tue, 20 Mar 2012 22:13:28 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "Paul C. Bryan" References: <20120309212231.16366.52439.idtracker@ietfa.amsl.com> <4F689626.9070500@gmx.de> <1332261146.2171.7.camel@neutron> <4F68B37E.9060608@gmx.de> <1332262482.2171.11.camel@neutron> <4F68BDB7.7030808@gmx.de> <1332269074.2171.21.camel@neutron> <4F68D295.2040401@gmx.de> <1332277294.2171.25.camel@neutron> In-Reply-To: <1332277294.2171.25.camel@neutron> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] feedback on draft-ietf-appsawg-json-patch-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 Mar 2012 21:13:33 -0000 On 2012-03-20 22:01, Paul C. Bryan wrote: > On Tue, 2012-03-20 at 19:55 +0100, Julian Reschke wrote: > >> So is the intent to define the fragment identifier syntax for >> application/json or not? > > It wasn't my intent originally, though your concerns have me think that > perhaps we should consider it. It was to define a fragment identifier > syntax, which other specifications (e.g. JSON Schema, JSON Reference) > can reference. > >> If it is, we need to normatively update the JSON RFC, and need to make >> sure there's really consensus on this. > > Question: Do you think it should? I'm not sure. >> If it is not, the way the Pointer spec currently is written is very >> confusing. > > Any text suggestions to resolve this? Section 6 should clarify that the fragment identifier syntax applies to Internet Media Types that explicitly choose it, and that application/json hasn't (yet). The examples in the appendix should get an explanation that they apply to a JSON-shaped example media type that indeed has choosen the fragid syntax... Best regards, Julian From macar@cloudmark.com Tue Mar 20 14:15:29 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95DE721F8664 for ; Tue, 20 Mar 2012 14:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GtEsdoZJWVuv for ; Tue, 20 Mar 2012 14:15:29 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 4490B21F865A for ; Tue, 20 Mar 2012 14:15:29 -0700 (PDT) Received: from [172.20.2.21] (172.20.2.21) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 20 Mar 2012 14:15:28 -0700 Message-ID: <4F68F370.7040506@cloudmark.com> Date: Tue, 20 Mar 2012 14:15:28 -0700 From: Mike Acar User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: References: <20120309212231.16366.52439.idtracker@ietfa.amsl.com> <4F689626.9070500@gmx.de> <1332261146.2171.7.camel@neutron> In-Reply-To: <1332261146.2171.7.camel@neutron> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.20.2.21] Subject: Re: [apps-discuss] feedback on draft-ietf-appsawg-json-patch-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 Mar 2012 21:15:29 -0000 On 03/20/2012 09:32 AM, Paul C. Bryan wrote: > any JSON Patch implementation should be fully capable of resolving > fragment identifiers itself. And it will have to, given that the Patch spec depends on undefined behavior in Pointer. No. I haven't given that issue up yet :) I'll respond to the other thread a bit later today. -- Mike Acar - - macar at cloudmark dot com From msk@cloudmark.com Tue Mar 20 14:40:14 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 796C821E8017 for ; Tue, 20 Mar 2012 14:40:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.601 X-Spam-Level: X-Spam-Status: No, score=-102.601 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rv0+unpMibBV for ; Tue, 20 Mar 2012 14:40:14 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 1242B21E800F for ; Tue, 20 Mar 2012 14:40:14 -0700 (PDT) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by EXCH-HTCAS901.corp.cloudmark.com ([fe80::2966:6846:8d89:4681%12]) with mapi id 14.01.0355.002; Tue, 20 Mar 2012 14:40:13 -0700 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Thread-Topic: [apps-discuss] feedback on draft-ietf-appsawg-json-patch-01.txt Thread-Index: AQHNBqb8fJun3tO+20eyseC5qutf45Zz1hwAgAAC2QCAAANgAIAACNCAgAAV4gCAAAL+gIAAI0kAgAADUwD//5GnMA== Date: Tue, 20 Mar 2012 21:40:13 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280949C7@exch-mbx901.corp.cloudmark.com> References: <20120309212231.16366.52439.idtracker@ietfa.amsl.com> <4F689626.9070500@gmx.de> <1332261146.2171.7.camel@neutron> <4F68B37E.9060608@gmx.de> <1332262482.2171.11.camel@neutron> <4F68BDB7.7030808@gmx.de> <1332269074.2171.21.camel@neutron> <4F68D295.2040401@gmx.de> <1332277294.2171.25.camel@neutron> <4F68F2F8.7000207@gmx.de> In-Reply-To: <4F68F2F8.7000207@gmx.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [apps-discuss] feedback on draft-ietf-appsawg-json-patch-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 Mar 2012 21:40:14 -0000 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] On Behalf Of Julian Reschke > Sent: Tuesday, March 20, 2012 2:13 PM > To: Paul C. Bryan > Cc: apps-discuss@ietf.org > Subject: Re: [apps-discuss] feedback on draft-ietf-appsawg-json-patch-01.= txt >=20 > > It wasn't my intent originally, though your concerns have me think > > that perhaps we should consider it. It was to define a fragment > > identifier syntax, which other specifications (e.g. JSON Schema, JSON > > Reference) can reference. > > > >> If it is, we need to normatively update the JSON RFC, and need to > >> make sure there's really consensus on this. > > > > Question: Do you think it should? >=20 > I'm not sure. Does there need to be one-and-only-one? Or I guess more accurately, do we = need to say this is the one and only way to do this? Seems like that close= s the door to someone coming up with a better idea. It seems to me that you can just say that this is a way to do pointers to o= bjects, and that patch is built on top of it, and stop there. From julian.reschke@gmx.de Tue Mar 20 15:02:59 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A523921F85FD for ; Tue, 20 Mar 2012 15:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.31 X-Spam-Level: X-Spam-Status: No, score=-103.31 tagged_above=-999 required=5 tests=[AWL=-1.311, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iYMSGAyg1UoJ for ; Tue, 20 Mar 2012 15:02:59 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id D1B6421F858F for ; Tue, 20 Mar 2012 15:02:58 -0700 (PDT) Received: (qmail invoked by alias); 20 Mar 2012 22:02:56 -0000 Received: from p57A6E8EB.dip.t-dialin.net (EHLO [192.168.178.36]) [87.166.232.235] by mail.gmx.net (mp019) with SMTP; 20 Mar 2012 23:02:56 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+Bv0gKr+OBMwg/eVsJLCNKCOcvYy7yKbwBWAzMBv WL87/vpbRuqsp+ Message-ID: <4F68FE8E.7030100@gmx.de> Date: Tue, 20 Mar 2012 23:02:54 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <20120309212231.16366.52439.idtracker@ietfa.amsl.com> <4F689626.9070500@gmx.de> <1332261146.2171.7.camel@neutron> <4F68B37E.9060608@gmx.de> <1332262482.2171.11.camel@neutron> <4F68BDB7.7030808@gmx.de> <1332269074.2171.21.camel@neutron> <4F68D295.2040401@gmx.de> <1332277294.2171.25.camel@neutron> <4F68F2F8.7000207@gmx.de> <9452079D1A51524AA5749AD23E0039280949C7@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E0039280949C7@exch-mbx901.corp.cloudmark.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] feedback on draft-ietf-appsawg-json-patch-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 Mar 2012 22:02:59 -0000 On 2012-03-20 22:40, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Julian Reschke >> Sent: Tuesday, March 20, 2012 2:13 PM >> To: Paul C. Bryan >> Cc: apps-discuss@ietf.org >> Subject: Re: [apps-discuss] feedback on draft-ietf-appsawg-json-patch-01.txt >> >>> It wasn't my intent originally, though your concerns have me think >>> that perhaps we should consider it. It was to define a fragment >>> identifier syntax, which other specifications (e.g. JSON Schema, JSON >>> Reference) can reference. >>> >>>> If it is, we need to normatively update the JSON RFC, and need to >>>> make sure there's really consensus on this. >>> >>> Question: Do you think it should? >> >> I'm not sure. > > Does there need to be one-and-only-one? Or I guess more accurately, do we need to say this is the one and only way to do this? Seems like that closes the door to someone coming up with a better idea. There could be multiple fragment identifier schemes, but then you'd need a way to disambiguate (for instance, xml:id doesn't allow things like "()", so there's an extension point to hook XMLPointer to). > It seems to me that you can just say that this is a way to do pointers to objects, and that patch is built on top of it, and stop there. Well, the patch format doesn't need fragment identifiers to start with... From macar@cloudmark.com Tue Mar 20 16:19:30 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 266CF21E8036 for ; Tue, 20 Mar 2012 16:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S1d388A+F5dd for ; Tue, 20 Mar 2012 16:19:29 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 8000D21E8032 for ; Tue, 20 Mar 2012 16:19:29 -0700 (PDT) Received: from [172.20.2.21] (172.20.2.21) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 20 Mar 2012 16:19:29 -0700 Message-ID: <4F691080.7020606@cloudmark.com> Date: Tue, 20 Mar 2012 16:19:28 -0700 From: Mike Acar User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: References: <20120309212231.16366.52439.idtracker@ietfa.amsl.com> <4F5E70BE.9070308@cloudmark.com> <1331652710.3301.18.camel@neutron> In-Reply-To: <1331652710.3301.18.camel@neutron> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.20.2.21] Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-json-patch-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 Mar 2012 23:19:30 -0000 On 03/13/2012 08:31 AM, Paul C. Bryan wrote: > On Mon, 2012-03-12 at 14:55 -0700, Mike Acar wrote: > >> This version of the draft doesn't address the bad interaction with the >> JSON Pointer spec, namely that "add" takes a JSON Pointer to a value >> which does not yet exist, and the Pointer spec says that in that case, >> an implementation MAY abort with an error. Is that going to be >> addressed in -02? > > > I'm of the opinion that expressing a not-yet-existing target as a JSON > Pointer is the most simple and intuitive method so far. If the pointer is to the parent, and there is a "name" element, the code will look something like (perlish syntax ahead): # We already figured out we're adding an element my $new_name = $patch->[0]->{name}; my $new_val = $patch->[0]->{value}; # Resolve the pointer. my $parent = follow_pointer($patch->[0]->{add}); # "Add" logic: if (exists($parent->{$new_name}) { die "$new_name already exists in $parent!"; } $parent->{$new_name} = $new_val; Get a reference to the parent and manipulate it. Nice and simple. Compare if the location is to the new name to be added: # We already figured out we're adding an element my $new_val = $patch->[0]->{val}; my $pointer = $patch->[0]->{add}; # Resolve the pointer. my @pointer_elements = split_pointer($pointer); my $new_name = pop(@pointer_elements); my $parent_pointer = join_pointer(@pointer_elements) my $parent = follow_pointer($parent_pointer); # "Add" logic: if (exists($parent->{$new_name}) { die "$new_name already exists in $parent!"; } $parent->{$new_name} = $new_val; The first looks simpler to me. > I've had no problems implementing the specs as a result of this. > I agree that the > language in the JSON Pointer spec is still somewhat awkward and could > still stand to be improved. I think that no matter how it's expressed, this is a flaw in the relationship between these specs. The goal of specification is to improve interoperability. As these drafts stand, you can write a conforming Pointer implementation that is useless for Patch. > The suggested alternative of requiring the parent and target member to > be expressed separately is more verbose It is, but I think the extra verbosity can be made very very small (a few bytes at most). Balancing that against conforming but not-interoperable implementations.... I think verbosity is better. > and complex. I disagree here, too. I think pointer-to-parent/name-to-add is simpler to specify, to understand, and to use in implementation. > Over-verbosity of JSON Patch is already an objection that has been > raised more than once on this list, and I'm not inclined to > exacerbate it further unless there is consensus from the members of > appsawg that it should be adopted. Even very early design discussions noted this problem; see Dean Landolt's comments from Apr 27 2011: I'm wondering if it makes more sense to use a path for add similar to remove -- the last path portion would be the "element". One drawback is that the actual submitted pointer path wouldn't point to a valid node until after the patch is applied (which, I assume, is why you used the "element" approach). http://groups.google.com/group/json-patch/browse_thread/thread/6e1cc65501eda324# Your original design was 3. You're right, the reason I kept "element" was so that the pointer always resolves to a node. This idea is getting pushback by those who want ultra-tight syntax; any further feedback on this point would be appreciated. Consider this (belated) feedback in favor of pointers always referring to existing nodes :) Dean went on to write Given well-defined path semantics this shouldn't be as important -- we should be able to count on an implementation correctly splitting a path into parent and element targets. I'm not sure why that assumption would be true; somebody reading just the Pointer spec wouldn't realize this need, which Patch imposes. -- Mike Acar - - macar at cloudmark dot com From macar@cloudmark.com Tue Mar 20 16:38:00 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CC3921F854B for ; Tue, 20 Mar 2012 16:38:00 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yw5ivf7+wmBQ for ; Tue, 20 Mar 2012 16:38:00 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 1131021F8546 for ; Tue, 20 Mar 2012 16:38:00 -0700 (PDT) Received: from [172.20.2.21] (172.20.2.21) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 20 Mar 2012 16:37:59 -0700 Message-ID: <4F6914D7.5050505@cloudmark.com> Date: Tue, 20 Mar 2012 16:37:59 -0700 From: Mike Acar User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: References: <9F0A2492-AE7D-4C12-8BB0-13489FD7F6C1@gmail.com> <1331271383.6504.1.camel@neutron> <4F5E6255.9040402@cloudmark.com> <1331651889.3301.5.camel@neutron> In-Reply-To: <1331651889.3301.5.camel@neutron> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.20.2.21] Subject: Re: [apps-discuss] draft-pbryan-json-patch-04 - comments X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 Mar 2012 23:38:00 -0000 On 03/13/2012 08:18 AM, Paul C. Bryan wrote: > On Mon, 2012-03-12 at 13:53 -0700, Mike Acar wrote: > >> I'm unsure about test as well. It seems strange to me to express "change >> this document if it looks like this" in a patch; if the application >> creating the patch doesn't know how the document looks, how can it >> create a patch? > > I'm surprised that it seems so strange, as this is very much like how > text-based diff/patches work. But in diff, the "test" is not optional. The diff (AFAIK anyway) always expresses "replace this with that". Patch doesn't. So I guess I should say it's the optionality that makes it a bit weird to me - mixing tested and not-tested operations. When would that make sense? I'm not yet convinced it's a problem, but I wonder about the desired semantics and if this is sufficient to get them. For example, I can see that test combined with Patch's atomicity could be useful, but it seems like it can't protect you from race conditions. Maybe it's sufficient for some use cases, though. > It allows assumptions about the state of the resource being modified > to be a precondition to successfully modifying the resource. With > HTTP, it's ideal if precondition headers be used, but this is not > always feasible, nor is HTTP the only avenue for using JSON Patch. Mhm. >> Paul, is there an archived discussion of the "test" operation, >> particularly regarding use cases? > > This was originally discussed on the JSON Patch Google Group discussion. I've read some of the archives, but not all, so I'll have another look through them for this discussion. -- Mike Acar - - macar at cloudmark dot com From msk@cloudmark.com Tue Mar 20 16:59:00 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 301AE21F84B3 for ; Tue, 20 Mar 2012 16:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4-cwejRlwxJL for ; Tue, 20 Mar 2012 16:58:59 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 3C8BC21F8453 for ; Tue, 20 Mar 2012 16:58:59 -0700 (PDT) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by EXCH-HTCAS901.corp.cloudmark.com ([fe80::2966:6846:8d89:4681%12]) with mapi id 14.01.0355.002; Tue, 20 Mar 2012 16:58:58 -0700 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Thread-Topic: [apps-discuss] WGLC: draft-ietf-appsawg-about-uri-scheme-03.txt Thread-Index: AQHM+zSl3R1Ur6zXPEClJ5AyVkiELpZz6yzQ Date: Tue, 20 Mar 2012 23:58:57 +0000 Message-ID: <9452079D1A51524AA5749AD23E003928094CEB@exch-mbx901.corp.cloudmark.com> References: <503575970.11554@cnnic.cn> <4A10020DB6464A0BBA535BF75D21A9D9@LENOVO47E041CF> In-Reply-To: <4A10020DB6464A0BBA535BF75D21A9D9@LENOVO47E041CF> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.20.2.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [apps-discuss] WGLC: draft-ietf-appsawg-about-uri-scheme-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 20 Mar 2012 23:59:00 -0000 > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] On Behalf Of Jiankang YAO > Sent: Monday, March 05, 2012 5:01 PM > To: apps-discuss@ietf.org > Cc: appsawg-chairs@tools.ietf.org > Subject: [apps-discuss] WGLC: draft-ietf-appsawg-about-uri-scheme-03.txt >=20 > Dear colleagues, >=20 > This message starts a two-week WGLC on the draft draft-ietf-appsawg- > about-uri-scheme-03.txt. >=20 > Please help to review this draft. If you support publication, please > state as much on the list. If you are opposed to publication, please > state that on the list as well. It is more/only helpful if you give > your reasons for your position as part of your statement. >=20 > Pls send your comments to apps-discuss@ietf.org or appsawg- > chairs@tools.ietf.org or editors. >=20 > The WGLC will end on March 20, 2012 at 1:00 UTC. This is coming in a bit late, and apologies for that (and shame on me for c= omplaining about other people who come in late on my drafts!), but the poin= ts should be easily resolved. [Relatively] Major Issues: In Section 4.2, you talk about the Intended Usage field of the registration= being "what they must be resolved to, if resolvable." Why would you allow= registration of something that can't resolve to something? Section 4.2 also talks about referencing a document that allows one to crea= te an "interoperable" implementation of the "about" URI being registered. = I know we talked about this in the WG, but a new reader might well ask "int= eroperable with what?" You might want to answer that question before the I= ESG asks it. :-) [Relatively] Minor Issues: I'm not so sure about use of RFC2119 language in the IANA Considerations se= ction. You're not really describing interoperability requirements with IAN= A. [Absolutely] Nits: All of these are either reductions of overly-wordy text or fixes to minor g= rammar nits, or both. Section 1: OLD scheme, that is currently widely used by Web browsers and some other NEW scheme, which is currently widely used by Web browsers and some other Also, I'm not sure that "Web" is a proper noun, so it should probably be "w= eb". OLD The concept of "about" URIs has been formed at the times when the applications did not have the "friendly" user interface, in order to provide an access to the aforementioned resources via typing the URIs in the address bar. Even though the user interface of current Internet-targeted software effectively rescinds the issue, and "about" URIs can be thought to be a rudimentary phenomenon, they are still supported by a variety of Web browsers and are not going to cease to exist. As use of "about" URIs has been quiet long-lasting, and the URIs have been used without any proper registration and absent any proper specification, the necessity for the latter two actions arises. The purpose of this document is to provide a stable specification for "about" URI scheme and correspondingly register it in the IANA registry. Along, several provisions for handling the "about" URIs Are set. NEW The concept of "about" URIs formed when applications did not have a "friendly" user interface, to enable access to the aforementioned resources by typing URIs into an address bar or similar feature. They have however become commonplace in modern user applications. Given their current ubiquity, their absence from the URI scheme registry and lack of a defining document is conspicuous. Therefore, this document provides a stable specification for the "about" URI scheme and registers it with IANA. Section 2.2: OLD Generally speaking, the resource a particular "about" URI resolves to is denoted by part of the URI, and specifies additional information concerning its handling and/or the information that should be returned in the resource a URI is resolved to. However, it is impossible to specify binding between all the possible tokens and the semantics of "about" URIs that would contain such tokens, which this document does not attempt to do. Therefore, any application resolving an "about" URI MAY choose the resource it is resolved to at its own discretion, with the exception of those defined below as 'special-purpose "about" URIs'. They MAY use internal redirection to accomplish this (for instance, Opera redirects all "about" URIs except "about:blank" to its internal "opera" URIs). NEW Generally speaking, the resource to which a particular "about" URI resolv= es is denoted by part of the URI, and specifies additional information concerning its handling and/or the information that should be returned in the resource to which the URI resolves. However, it is impossible to specify a binding between all the possible tokens and the semantics of "about" URIs that would contain such tokens. Therefore, the resource referenced by the URI is application-specific, except for those listed below as 'special-purpose "about" URIs'. Applications MAY use internal redirection to accomplish this (for instance, the Opera web browser redirects all "about" URIs exce= pt "about:blank" to its internal "opera" URIs). Section 2.2.1: OLD A small, though expandable, range of s are reserved for special purposes ("special-purpose tokens"). NEW A small, though extensible, range of s is reserved for Special purposes ("special-purpose tokens"). OLD Additional special-purpose tokens can be defined by registering an registry created in Section 4.2. Special-purpose "about" URIs are intended to be uncommon, and new ones should be defined only when there is a need to strongly connect a particular with a particular function in all applications. NEW Additional special-purpose tokens can be defined by updating the registry created in Section 4.2. Special-purpose "about" URIs are intended to be uncommon, and new ones only need to be defined when there is a need to strongly connect a particular with a particular function in all applications. Section 3: OLD Generic security considerations for URIs are discussed in Section 7 of RFC 3986 [RFC3986]. However, many of those provisions hardly apply to "about" URI scheme, as they are mainly scoped to schemes used in the Internet, not internally. "about" URIs may sometimes refer to a sensitive information, such as user passwords stored in a cache, or parameter that, if changed, may affect user's data. The application should therefore ensure that user's data is in the safety, and no threats are imposed by "about" URIs. NEW Generic security considerations for URIs are discussed in Section 7 of RFC 3986 [RFC3986]. However, few of those provisions apply to the "about" URI scheme, as they are mainly scoped to schemes used in the Internet, not internally. "about" URIs can sometimes refer to a sensitive information, such as user passwords stored in a cache, or parameters that, if changed, could affect user's data. The application therefore needs to ensure that the user's data is secured, and no threats are imposed by "about" URIs. Section 4.2: OLD o Intended usage: A short description of how "about" URIs with the registered token must be handled; especially, what they must be resolved to, if resolvable. o Handling query component: It should be mentioned whether there are some provisions on handling query components in the "about" URIs with the registered token. o Contact/Change controller: An individual or an organization which (1) should be contacted for more details, and (2) is authorized to change the registration. o Specification. This provides documentation at a level that could be used to create a compliant, interoperable implementation of the registered "about" URI. The reference to a full specification MUST be provided here, and there should be a reasonable expectation that the documentation will remain available. IANA will consult with the IESG or its specified delegate if there is doubt about whether the specification is adequate for the purpose. The following is a template for "blank" token: NEW o Intended usage: A short description of how "about" URIs with the registered token must be handled; especially, to what resource they are to resolve. o Handling query component: Describe any requirements for handling query components in "about" URIs that contain the registered token. o Contact/Change controller: An individual or an organization that (1) should be contacted for more details, and (2) is authorized to change the registration. o Specification. A permanent reference to a specification that can be used to create a compliant, interoperable implementation of the registered "about" URI. IANA will consult with the IESG or its specified delegate if there is doubt about whether the specification is adequate for this purpose. The following is a template for the "blank" token: -MSK From barryleiba.mailing.lists@gmail.com Tue Mar 20 19:34:58 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A6B821E801A for ; Tue, 20 Mar 2012 19:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.99 X-Spam-Level: X-Spam-Status: No, score=-102.99 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ysnl8iJvxlCO for ; Tue, 20 Mar 2012 19:34:57 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8C17121F8628 for ; Tue, 20 Mar 2012 19:34:57 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so783702vcb.31 for ; Tue, 20 Mar 2012 19:34:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=qMLjRKj92c99i5qn2yOqL6FgALl57HC/fjw5PEtogWk=; b=wTm9uN7dxA7VBVASIwz4NstaRX+In26cBT1FJSiAakpPY/IlHMqLkw/DLBEwSoMaMF bWz+nHs9iM1cgOt6EizDp5lQzi+NL555I5f1sQt7RtQvMFQx1bzdZBKiS9CgAjorhm49 WPG6w907I2MtqqOGKPjEdMgIEx/9PWSd5xHjNRhUKQQoLMNFSEysRltZVDTpAks6wgWp 1VwsxgZxS1cpoho+ADI2QDYuiaLPJnumrUsZOSS/etMhuhfSQvE4WDgpExeYPC0uOo1Q aSGs30pu9CO/2iiqoajRXwUo2RPw5mnBGrYckRS7TKCCQEE3M9TXG+A/623fNQcTtdl7 IOIA== MIME-Version: 1.0 Received: by 10.220.153.139 with SMTP id k11mr1075488vcw.27.1332297297102; Tue, 20 Mar 2012 19:34:57 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.52.161.37 with HTTP; Tue, 20 Mar 2012 19:34:57 -0700 (PDT) In-Reply-To: <9452079D1A51524AA5749AD23E003928094CEB@exch-mbx901.corp.cloudmark.com> References: <503575970.11554@cnnic.cn> <4A10020DB6464A0BBA535BF75D21A9D9@LENOVO47E041CF> <9452079D1A51524AA5749AD23E003928094CEB@exch-mbx901.corp.cloudmark.com> Date: Tue, 20 Mar 2012 22:34:57 -0400 X-Google-Sender-Auth: XQCwDEIpX4_sTZh0AwMBLcHJv_Q Message-ID: From: Barry Leiba To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] WGLC: draft-ietf-appsawg-about-uri-scheme-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 21 Mar 2012 02:34:58 -0000 > [Relatively] Minor Issues: > I'm not so sure about use of RFC2119 language in the IANA Considerations > section. =A0You're not really describing interoperability requirements wi= th IANA. I'm sure. And it's my text -- this is one that Mykyta doesn't like. The three MUSTs in there are not directed at IANA, but at people writing new registrations. They tell those people what their registrations have to look like, and I wanted to use MUST to stress that even though this is an FCFS policy, there are requirements nonetheless. > [Absolutely] Nits: > All of these are either reductions of overly-wordy text or fixes to minor= grammar nits, or both. ... > =A0 =A0 =A0 =A0OLD > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0The concept of "about" URIs has been forme= d at the times when the > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0applications did not have the "friendly" u= ser interface, in order to > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0provide an access to the aforementioned re= sources via typing the URIs ... > =A0 =A0 =A0 =A0NEW > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0The concept of "about" URIs formed when ap= plications did not have a > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"friendly" user interface, to enable acces= s to the aforementioned > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0resources by typing URIs into an address b= ar or similar feature. ... Yeah, good luck with that. I tried to convince Mykyta to tone the rhetoric down in there, and he declined... and I didn't see it as important enough to fight about. Barry From pbryan@anode.ca Tue Mar 20 22:35:25 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7682321F863E for ; Tue, 20 Mar 2012 22:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ny8Y2KO+WU5R for ; Tue, 20 Mar 2012 22:35:24 -0700 (PDT) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id 4A64921F863C for ; Tue, 20 Mar 2012 22:35:19 -0700 (PDT) Received: from [192.168.1.9] (S0106a021b762dbb3.vf.shawcable.net [174.1.50.247]) by maple.anode.ca (Postfix) with ESMTPSA id 250706456 for ; Wed, 21 Mar 2012 05:35:18 +0000 (UTC) Message-ID: <1332308116.2171.30.camel@neutron> From: "Paul C. Bryan" To: apps-discuss@ietf.org Date: Tue, 20 Mar 2012 22:35:16 -0700 In-Reply-To: <4F691080.7020606@cloudmark.com> References: <20120309212231.16366.52439.idtracker@ietfa.amsl.com> <4F5E70BE.9070308@cloudmark.com> <1331652710.3301.18.camel@neutron> <4F691080.7020606@cloudmark.com> Content-Type: multipart/alternative; boundary="=-EogamfOK8ekKsSS7PefX" X-Mailer: Evolution 3.2.2-1 Mime-Version: 1.0 Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-json-patch-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 21 Mar 2012 05:35:25 -0000 --=-EogamfOK8ekKsSS7PefX Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit As I stated previously, if there's consensus on a more verbose patch operation object format, I will defer. Any opinions from other members of the working group? Paul On Tue, 2012-03-20 at 16:19 -0700, Mike Acar wrote: > On 03/13/2012 08:31 AM, Paul C. Bryan wrote: > > On Mon, 2012-03-12 at 14:55 -0700, Mike Acar wrote: > > > >> This version of the draft doesn't address the bad interaction with the > >> JSON Pointer spec, namely that "add" takes a JSON Pointer to a value > >> which does not yet exist, and the Pointer spec says that in that case, > >> an implementation MAY abort with an error. Is that going to be > >> addressed in -02? > > > > > > I'm of the opinion that expressing a not-yet-existing target as a JSON > > Pointer is the most simple and intuitive method so far. > > If the pointer is to the parent, and there is a "name" element, the code > will look something like (perlish syntax ahead): > > # We already figured out we're adding an element > my $new_name = $patch->[0]->{name}; > my $new_val = $patch->[0]->{value}; > > # Resolve the pointer. > my $parent = follow_pointer($patch->[0]->{add}); > > # "Add" logic: > if (exists($parent->{$new_name}) { > die "$new_name already exists in $parent!"; > } > $parent->{$new_name} = $new_val; > > Get a reference to the parent and manipulate it. Nice and simple. > > Compare if the location is to the new name to be added: > > # We already figured out we're adding an element > my $new_val = $patch->[0]->{val}; > my $pointer = $patch->[0]->{add}; > > # Resolve the pointer. > my @pointer_elements = split_pointer($pointer); > my $new_name = pop(@pointer_elements); > my $parent_pointer = join_pointer(@pointer_elements) > my $parent = follow_pointer($parent_pointer); > > # "Add" logic: > if (exists($parent->{$new_name}) { > die "$new_name already exists in $parent!"; > } > $parent->{$new_name} = $new_val; > > The first looks simpler to me. > > > I've had no problems implementing the specs as a result of this. > > > I agree that the > > language in the JSON Pointer spec is still somewhat awkward and could > > still stand to be improved. > > I think that no matter how it's expressed, this is a flaw in the > relationship between these specs. > > The goal of specification is to improve interoperability. As these > drafts stand, you can write a conforming Pointer implementation that is > useless for Patch. > > > The suggested alternative of requiring the parent and target member to > > be expressed separately is more verbose > > It is, but I think the extra verbosity can be made very very small (a > few bytes at most). Balancing that against conforming but > not-interoperable implementations.... I think verbosity is better. > > > and complex. > > I disagree here, too. I think pointer-to-parent/name-to-add is simpler > to specify, to understand, and to use in implementation. > > > Over-verbosity of JSON Patch is already an objection that has been > > raised more than once on this list, and I'm not inclined to > > exacerbate it further unless there is consensus from the members of > > appsawg that it should be adopted. > > Even very early design discussions noted this problem; see Dean > Landolt's comments from Apr 27 2011: > > I'm wondering if it makes more sense to use a path for add similar > to remove -- the last path portion would be the "element". One > drawback is that the actual submitted pointer path wouldn't point to > a valid node until after the patch is applied (which, I assume, is > why you used the "element" approach). > > http://groups.google.com/group/json-patch/browse_thread/thread/6e1cc65501eda324# > > Your original design was > > 3. You're right, the reason I kept "element" was so that the pointer > always resolves to a node. This idea is getting pushback by those > who want ultra-tight syntax; any further feedback on this point > would be appreciated. > > Consider this (belated) feedback in favor of pointers always referring > to existing nodes :) > > Dean went on to write > > Given well-defined path semantics this shouldn't be as important -- > we should be able to count on an implementation correctly splitting > a path into parent and element targets. > > I'm not sure why that assumption would be true; somebody reading just > the Pointer spec wouldn't realize this need, which Patch imposes. > --=-EogamfOK8ekKsSS7PefX Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit As I stated previously, if there's consensus on a more verbose patch operation object format, I will defer. Any opinions from other members of the working group?

Paul

On Tue, 2012-03-20 at 16:19 -0700, Mike Acar wrote: 
On 03/13/2012 08:31 AM, Paul C. Bryan wrote:
> On Mon, 2012-03-12 at 14:55 -0700, Mike Acar wrote:
>
>> This version of the draft doesn't address the bad interaction with the
>> JSON Pointer spec, namely that "add" takes a JSON Pointer to a value
>> which does not yet exist, and the Pointer spec says that in that case,
>> an implementation MAY abort with an error. Is that going to be
>> addressed in -02?
>
>
> I'm of the opinion that expressing a not-yet-existing target as a JSON
> Pointer is the most simple and intuitive method so far.

If the pointer is to the parent, and there is a "name" element, the code 
will look something like (perlish syntax ahead):

# We already figured out we're adding an element
my $new_name = $patch->[0]->{name};
my $new_val = $patch->[0]->{value};

# Resolve the pointer.
my $parent = follow_pointer($patch->[0]->{add});

# "Add" logic:
if (exists($parent->{$new_name}) {
	die "$new_name already exists in $parent!";
}
$parent->{$new_name} = $new_val;

Get a reference to the parent and manipulate it. Nice and simple.

Compare if the location is to the new name to be added:

# We already figured out we're adding an element
my $new_val = $patch->[0]->{val};
my $pointer = $patch->[0]->{add};

# Resolve the pointer.
my @pointer_elements = split_pointer($pointer);
my $new_name = pop(@pointer_elements);
my $parent_pointer = join_pointer(@pointer_elements)
my $parent = follow_pointer($parent_pointer);

# "Add" logic:
if (exists($parent->{$new_name}) {
	die "$new_name already exists in $parent!";
}
$parent->{$new_name} = $new_val;

The first looks simpler to me.

> I've had no problems implementing the specs as a result of this.

 > I agree that the
> language in the JSON Pointer spec is still somewhat awkward and could
> still stand to be improved.

I think that no matter how it's expressed, this is a flaw in the 
relationship between these specs.

The goal of specification is to improve interoperability. As these 
drafts stand, you can write a conforming Pointer implementation that is 
useless for Patch.

> The suggested alternative of requiring the parent and target member to
> be expressed separately is more verbose

It is, but I think the extra verbosity can be made very very small (a 
few bytes at most). Balancing that against conforming but 
not-interoperable implementations.... I think verbosity is better.

> and complex.

I disagree here, too. I think pointer-to-parent/name-to-add is simpler 
to specify, to understand, and to use in implementation.

> Over-verbosity of JSON Patch is already an objection that has been
> raised more than once on this list, and I'm not inclined to
> exacerbate it further unless there is consensus from the members of
> appsawg that it should be adopted.

Even very early design discussions noted this problem; see Dean 
Landolt's comments from Apr 27 2011:

     I'm wondering if it makes more sense to use a path for add similar
     to remove -- the last path portion would be the "element". One
     drawback is that the actual submitted pointer path wouldn't point to
     a valid node until after the patch is applied (which, I assume, is
     why you used the "element" approach).

http://groups.google.com/group/json-patch/browse_thread/thread/6e1cc65501eda324#

Your original design was

     3. You're right, the reason I kept "element" was so that the pointer
     always resolves to a node. This idea is getting pushback by those
     who want ultra-tight syntax; any further feedback on this point
     would be appreciated.

Consider this (belated) feedback in favor of pointers always referring 
to existing nodes :)

Dean went on to write

     Given well-defined path semantics this shouldn't be as important --
     we should be able to count on an implementation correctly splitting
     a path into parent and element targets.

I'm not sure why that assumption would be true; somebody reading just 
the Pointer spec wouldn't realize this need, which Patch imposes.

--=-EogamfOK8ekKsSS7PefX-- From msk@cloudmark.com Tue Mar 20 23:07:54 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3930021E8012 for ; Tue, 20 Mar 2012 23:07:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VZWtUXMOcY0l for ; Tue, 20 Mar 2012 23:07:53 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id 176CE21F85D9 for ; Tue, 20 Mar 2012 23:07:53 -0700 (PDT) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Tue, 20 Mar 2012 23:07:52 -0700 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Thread-Topic: [apps-discuss] I-D Action: draft-ietf-appsawg-json-patch-01.txt Thread-Index: AQHM/jrB8PCAcYWHKk608ngo3slf9JZnrnkAgAEnOwCAC4L6AIAAaP8A//+TgEA= Date: Wed, 21 Mar 2012 06:07:50 +0000 Message-ID: <9452079D1A51524AA5749AD23E003928094FF3@exch-mbx901.corp.cloudmark.com> References: <20120309212231.16366.52439.idtracker@ietfa.amsl.com> <4F5E70BE.9070308@cloudmark.com> <1331652710.3301.18.camel@neutron> <4F691080.7020606@cloudmark.com> <1332308116.2171.30.camel@neutron> In-Reply-To: <1332308116.2171.30.camel@neutron> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.160.203.60] Content-Type: multipart/alternative; boundary="_000_9452079D1A51524AA5749AD23E003928094FF3exchmbx901corpclo_" MIME-Version: 1.0 Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-json-patch-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 21 Mar 2012 06:07:54 -0000 --_000_9452079D1A51524AA5749AD23E003928094FF3exchmbx901corpclo_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmW0gaW5jbGluZWQgdG8gYWdyZWUgdGhhdCBzb21ldGhpbmcgdGhhdOKAmXMgbW9yZSBsaWtl bHkgdG8gcHJvZHVjZSBpbnRlcm9wZXJhYmxlIGltcGxlbWVudGF0aW9ucyBhdCB0aGUgY29zdCBv ZiBzbGlnaHRseSBtb3JlIGJ5dGVzIG9uIHRoZSB3aXJlIGlzIGEgZGVzaXJhYmxlIHRyYWRlb2Zm Lg0KDQotTVNLDQoNCkZyb206IGFwcHMtZGlzY3Vzcy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86 YXBwcy1kaXNjdXNzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBQYXVsIEMuIEJyeWFu DQpTZW50OiBUdWVzZGF5LCBNYXJjaCAyMCwgMjAxMiAxMDozNSBQTQ0KVG86IGFwcHMtZGlzY3Vz c0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFthcHBzLWRpc2N1c3NdIEktRCBBY3Rpb246IGRyYWZ0 LWlldGYtYXBwc2F3Zy1qc29uLXBhdGNoLTAxLnR4dA0KDQpBcyBJIHN0YXRlZCBwcmV2aW91c2x5 LCBpZiB0aGVyZSdzIGNvbnNlbnN1cyBvbiBhIG1vcmUgdmVyYm9zZSBwYXRjaCBvcGVyYXRpb24g b2JqZWN0IGZvcm1hdCwgSSB3aWxsIGRlZmVyLiBBbnkgb3BpbmlvbnMgZnJvbSBvdGhlciBtZW1i ZXJzIG9mIHRoZSB3b3JraW5nIGdyb3VwPw0KDQpQYXVsDQoNCk9uIFR1ZSwgMjAxMi0wMy0yMCBh dCAxNjoxOSAtMDcwMCwgTWlrZSBBY2FyIHdyb3RlOg0KDQoNCg0KT24gMDMvMTMvMjAxMiAwODoz MSBBTSwgUGF1bCBDLiBCcnlhbiB3cm90ZToNCg0KPiBPbiBNb24sIDIwMTItMDMtMTIgYXQgMTQ6 NTUgLTA3MDAsIE1pa2UgQWNhciB3cm90ZToNCg0KPg0KDQo+PiBUaGlzIHZlcnNpb24gb2YgdGhl IGRyYWZ0IGRvZXNuJ3QgYWRkcmVzcyB0aGUgYmFkIGludGVyYWN0aW9uIHdpdGggdGhlDQoNCj4+ IEpTT04gUG9pbnRlciBzcGVjLCBuYW1lbHkgdGhhdCAiYWRkIiB0YWtlcyBhIEpTT04gUG9pbnRl ciB0byBhIHZhbHVlDQoNCj4+IHdoaWNoIGRvZXMgbm90IHlldCBleGlzdCwgYW5kIHRoZSBQb2lu dGVyIHNwZWMgc2F5cyB0aGF0IGluIHRoYXQgY2FzZSwNCg0KPj4gYW4gaW1wbGVtZW50YXRpb24g TUFZIGFib3J0IHdpdGggYW4gZXJyb3IuIElzIHRoYXQgZ29pbmcgdG8gYmUNCg0KPj4gYWRkcmVz c2VkIGluIC0wMj8NCg0KPg0KDQo+DQoNCj4gSSdtIG9mIHRoZSBvcGluaW9uIHRoYXQgZXhwcmVz c2luZyBhIG5vdC15ZXQtZXhpc3RpbmcgdGFyZ2V0IGFzIGEgSlNPTg0KDQo+IFBvaW50ZXIgaXMg dGhlIG1vc3Qgc2ltcGxlIGFuZCBpbnR1aXRpdmUgbWV0aG9kIHNvIGZhci4NCg0KDQoNCklmIHRo ZSBwb2ludGVyIGlzIHRvIHRoZSBwYXJlbnQsIGFuZCB0aGVyZSBpcyBhICJuYW1lIiBlbGVtZW50 LCB0aGUgY29kZQ0KDQp3aWxsIGxvb2sgc29tZXRoaW5nIGxpa2UgKHBlcmxpc2ggc3ludGF4IGFo ZWFkKToNCg0KDQoNCiMgV2UgYWxyZWFkeSBmaWd1cmVkIG91dCB3ZSdyZSBhZGRpbmcgYW4gZWxl bWVudA0KDQpteSAkbmV3X25hbWUgPSAkcGF0Y2gtPlswXS0+e25hbWV9Ow0KDQpteSAkbmV3X3Zh bCA9ICRwYXRjaC0+WzBdLT57dmFsdWV9Ow0KDQoNCg0KIyBSZXNvbHZlIHRoZSBwb2ludGVyLg0K DQpteSAkcGFyZW50ID0gZm9sbG93X3BvaW50ZXIoJHBhdGNoLT5bMF0tPnthZGR9KTsNCg0KDQoN CiMgIkFkZCIgbG9naWM6DQoNCmlmIChleGlzdHMoJHBhcmVudC0+eyRuZXdfbmFtZX0pIHsNCg0K ICAgICAgIGRpZSAiJG5ld19uYW1lIGFscmVhZHkgZXhpc3RzIGluICRwYXJlbnQhIjsNCg0KfQ0K DQokcGFyZW50LT57JG5ld19uYW1lfSA9ICRuZXdfdmFsOw0KDQoNCg0KR2V0IGEgcmVmZXJlbmNl IHRvIHRoZSBwYXJlbnQgYW5kIG1hbmlwdWxhdGUgaXQuIE5pY2UgYW5kIHNpbXBsZS4NCg0KDQoN CkNvbXBhcmUgaWYgdGhlIGxvY2F0aW9uIGlzIHRvIHRoZSBuZXcgbmFtZSB0byBiZSBhZGRlZDoN Cg0KDQoNCiMgV2UgYWxyZWFkeSBmaWd1cmVkIG91dCB3ZSdyZSBhZGRpbmcgYW4gZWxlbWVudA0K DQpteSAkbmV3X3ZhbCA9ICRwYXRjaC0+WzBdLT57dmFsfTsNCg0KbXkgJHBvaW50ZXIgPSAkcGF0 Y2gtPlswXS0+e2FkZH07DQoNCg0KDQojIFJlc29sdmUgdGhlIHBvaW50ZXIuDQoNCm15IEBwb2lu dGVyX2VsZW1lbnRzID0gc3BsaXRfcG9pbnRlcigkcG9pbnRlcik7DQoNCm15ICRuZXdfbmFtZSA9 IHBvcChAcG9pbnRlcl9lbGVtZW50cyk7DQoNCm15ICRwYXJlbnRfcG9pbnRlciA9IGpvaW5fcG9p bnRlcihAcG9pbnRlcl9lbGVtZW50cykNCg0KbXkgJHBhcmVudCA9IGZvbGxvd19wb2ludGVyKCRw YXJlbnRfcG9pbnRlcik7DQoNCg0KDQojICJBZGQiIGxvZ2ljOg0KDQppZiAoZXhpc3RzKCRwYXJl bnQtPnskbmV3X25hbWV9KSB7DQoNCiAgICAgICBkaWUgIiRuZXdfbmFtZSBhbHJlYWR5IGV4aXN0 cyBpbiAkcGFyZW50ISI7DQoNCn0NCg0KJHBhcmVudC0+eyRuZXdfbmFtZX0gPSAkbmV3X3ZhbDsN Cg0KDQoNClRoZSBmaXJzdCBsb29rcyBzaW1wbGVyIHRvIG1lLg0KDQoNCg0KPiBJJ3ZlIGhhZCBu byBwcm9ibGVtcyBpbXBsZW1lbnRpbmcgdGhlIHNwZWNzIGFzIGEgcmVzdWx0IG9mIHRoaXMuDQoN Cg0KDQogPiBJIGFncmVlIHRoYXQgdGhlDQoNCj4gbGFuZ3VhZ2UgaW4gdGhlIEpTT04gUG9pbnRl ciBzcGVjIGlzIHN0aWxsIHNvbWV3aGF0IGF3a3dhcmQgYW5kIGNvdWxkDQoNCj4gc3RpbGwgc3Rh bmQgdG8gYmUgaW1wcm92ZWQuDQoNCg0KDQpJIHRoaW5rIHRoYXQgbm8gbWF0dGVyIGhvdyBpdCdz IGV4cHJlc3NlZCwgdGhpcyBpcyBhIGZsYXcgaW4gdGhlDQoNCnJlbGF0aW9uc2hpcCBiZXR3ZWVu IHRoZXNlIHNwZWNzLg0KDQoNCg0KVGhlIGdvYWwgb2Ygc3BlY2lmaWNhdGlvbiBpcyB0byBpbXBy b3ZlIGludGVyb3BlcmFiaWxpdHkuIEFzIHRoZXNlDQoNCmRyYWZ0cyBzdGFuZCwgeW91IGNhbiB3 cml0ZSBhIGNvbmZvcm1pbmcgUG9pbnRlciBpbXBsZW1lbnRhdGlvbiB0aGF0IGlzDQoNCnVzZWxl c3MgZm9yIFBhdGNoLg0KDQoNCg0KPiBUaGUgc3VnZ2VzdGVkIGFsdGVybmF0aXZlIG9mIHJlcXVp cmluZyB0aGUgcGFyZW50IGFuZCB0YXJnZXQgbWVtYmVyIHRvDQoNCj4gYmUgZXhwcmVzc2VkIHNl cGFyYXRlbHkgaXMgbW9yZSB2ZXJib3NlDQoNCg0KDQpJdCBpcywgYnV0IEkgdGhpbmsgdGhlIGV4 dHJhIHZlcmJvc2l0eSBjYW4gYmUgbWFkZSB2ZXJ5IHZlcnkgc21hbGwgKGENCg0KZmV3IGJ5dGVz IGF0IG1vc3QpLiBCYWxhbmNpbmcgdGhhdCBhZ2FpbnN0IGNvbmZvcm1pbmcgYnV0DQoNCm5vdC1p bnRlcm9wZXJhYmxlIGltcGxlbWVudGF0aW9ucy4uLi4gSSB0aGluayB2ZXJib3NpdHkgaXMgYmV0 dGVyLg0KDQoNCg0KPiBhbmQgY29tcGxleC4NCg0KDQoNCkkgZGlzYWdyZWUgaGVyZSwgdG9vLiBJ IHRoaW5rIHBvaW50ZXItdG8tcGFyZW50L25hbWUtdG8tYWRkIGlzIHNpbXBsZXINCg0KdG8gc3Bl Y2lmeSwgdG8gdW5kZXJzdGFuZCwgYW5kIHRvIHVzZSBpbiBpbXBsZW1lbnRhdGlvbi4NCg0KDQoN Cj4gT3Zlci12ZXJib3NpdHkgb2YgSlNPTiBQYXRjaCBpcyBhbHJlYWR5IGFuIG9iamVjdGlvbiB0 aGF0IGhhcyBiZWVuDQoNCj4gcmFpc2VkIG1vcmUgdGhhbiBvbmNlIG9uIHRoaXMgbGlzdCwgYW5k IEknbSBub3QgaW5jbGluZWQgdG8NCg0KPiBleGFjZXJiYXRlIGl0IGZ1cnRoZXIgdW5sZXNzIHRo ZXJlIGlzIGNvbnNlbnN1cyBmcm9tIHRoZSBtZW1iZXJzIG9mDQoNCj4gYXBwc2F3ZyB0aGF0IGl0 IHNob3VsZCBiZSBhZG9wdGVkLg0KDQoNCg0KRXZlbiB2ZXJ5IGVhcmx5IGRlc2lnbiBkaXNjdXNz aW9ucyBub3RlZCB0aGlzIHByb2JsZW07IHNlZSBEZWFuDQoNCkxhbmRvbHQncyBjb21tZW50cyBm cm9tIEFwciAyNyAyMDExOg0KDQoNCg0KICAgICBJJ20gd29uZGVyaW5nIGlmIGl0IG1ha2VzIG1v cmUgc2Vuc2UgdG8gdXNlIGEgcGF0aCBmb3IgYWRkIHNpbWlsYXINCg0KICAgICB0byByZW1vdmUg LS0gdGhlIGxhc3QgcGF0aCBwb3J0aW9uIHdvdWxkIGJlIHRoZSAiZWxlbWVudCIuIE9uZQ0KDQog ICAgIGRyYXdiYWNrIGlzIHRoYXQgdGhlIGFjdHVhbCBzdWJtaXR0ZWQgcG9pbnRlciBwYXRoIHdv dWxkbid0IHBvaW50IHRvDQoNCiAgICAgYSB2YWxpZCBub2RlIHVudGlsIGFmdGVyIHRoZSBwYXRj aCBpcyBhcHBsaWVkICh3aGljaCwgSSBhc3N1bWUsIGlzDQoNCiAgICAgd2h5IHlvdSB1c2VkIHRo ZSAiZWxlbWVudCIgYXBwcm9hY2gpLg0KDQoNCg0KaHR0cDovL2dyb3Vwcy5nb29nbGUuY29tL2dy b3VwL2pzb24tcGF0Y2gvYnJvd3NlX3RocmVhZC90aHJlYWQvNmUxY2M2NTUwMWVkYTMyNCM8aHR0 cDovL2dyb3Vwcy5nb29nbGUuY29tL2dyb3VwL2pzb24tcGF0Y2gvYnJvd3NlX3RocmVhZC90aHJl YWQvNmUxY2M2NTUwMWVkYTMyND4NCg0KDQoNCllvdXIgb3JpZ2luYWwgZGVzaWduIHdhcw0KDQoN Cg0KICAgICAzLiBZb3UncmUgcmlnaHQsIHRoZSByZWFzb24gSSBrZXB0ICJlbGVtZW50IiB3YXMg c28gdGhhdCB0aGUgcG9pbnRlcg0KDQogICAgIGFsd2F5cyByZXNvbHZlcyB0byBhIG5vZGUuIFRo aXMgaWRlYSBpcyBnZXR0aW5nIHB1c2hiYWNrIGJ5IHRob3NlDQoNCiAgICAgd2hvIHdhbnQgdWx0 cmEtdGlnaHQgc3ludGF4OyBhbnkgZnVydGhlciBmZWVkYmFjayBvbiB0aGlzIHBvaW50DQoNCiAg ICAgd291bGQgYmUgYXBwcmVjaWF0ZWQuDQoNCg0KDQpDb25zaWRlciB0aGlzIChiZWxhdGVkKSBm ZWVkYmFjayBpbiBmYXZvciBvZiBwb2ludGVycyBhbHdheXMgcmVmZXJyaW5nDQoNCnRvIGV4aXN0 aW5nIG5vZGVzIDopDQoNCg0KDQpEZWFuIHdlbnQgb24gdG8gd3JpdGUNCg0KDQoNCiAgICAgR2l2 ZW4gd2VsbC1kZWZpbmVkIHBhdGggc2VtYW50aWNzIHRoaXMgc2hvdWxkbid0IGJlIGFzIGltcG9y dGFudCAtLQ0KDQogICAgIHdlIHNob3VsZCBiZSBhYmxlIHRvIGNvdW50IG9uIGFuIGltcGxlbWVu dGF0aW9uIGNvcnJlY3RseSBzcGxpdHRpbmcNCg0KICAgICBhIHBhdGggaW50byBwYXJlbnQgYW5k IGVsZW1lbnQgdGFyZ2V0cy4NCg0KDQoNCkknbSBub3Qgc3VyZSB3aHkgdGhhdCBhc3N1bXB0aW9u IHdvdWxkIGJlIHRydWU7IHNvbWVib2R5IHJlYWRpbmcganVzdA0KDQp0aGUgUG9pbnRlciBzcGVj IHdvdWxkbid0IHJlYWxpemUgdGhpcyBuZWVkLCB3aGljaCBQYXRjaCBpbXBvc2VzLg0KDQoNCg0K --_000_9452079D1A51524AA5749AD23E003928094FF3exchmbx901corpclo_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglw YW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N CnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9y bWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi SFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRW1haWxT dHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPknigJltIGluY2xpbmVkIHRvIGFn cmVlIHRoYXQgc29tZXRoaW5nIHRoYXTigJlzIG1vcmUgbGlrZWx5IHRvIHByb2R1Y2UgaW50ZXJv cGVyYWJsZSBpbXBsZW1lbnRhdGlvbnMgYXQgdGhlIGNvc3Qgb2Ygc2xpZ2h0bHkgbW9yZSBieXRl cyBvbiB0aGUgd2lyZSBpcyBhIGRlc2lyYWJsZQ0KIHRyYWRlb2ZmLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LU1TSzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBhcHBzLWRpc2N1c3Mt Ym91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmFwcHMtZGlzY3Vzcy1ib3VuY2VzQGlldGYub3JnXQ0K PGI+T24gQmVoYWxmIE9mIDwvYj5QYXVsIEMuIEJyeWFuPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNk YXksIE1hcmNoIDIwLCAyMDEyIDEwOjM1IFBNPGJyPg0KPGI+VG86PC9iPiBhcHBzLWRpc2N1c3NA aWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFthcHBzLWRpc2N1c3NdIEktRCBBY3Rp b246IGRyYWZ0LWlldGYtYXBwc2F3Zy1qc29uLXBhdGNoLTAxLnR4dDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFzIEkgc3RhdGVkIHByZXZpb3VzbHksIGlm IHRoZXJlJ3MgY29uc2Vuc3VzIG9uIGEgbW9yZSB2ZXJib3NlIHBhdGNoIG9wZXJhdGlvbiBvYmpl Y3QgZm9ybWF0LCBJIHdpbGwgZGVmZXIuIEFueSBvcGluaW9ucyBmcm9tIG90aGVyIG1lbWJlcnMg b2YgdGhlIHdvcmtpbmcgZ3JvdXA/PGJyPg0KPGJyPg0KUGF1bDxicj4NCjxicj4NCk9uIFR1ZSwg MjAxMi0wMy0yMCBhdCAxNjoxOSAtMDcwMCwgTWlrZSBBY2FyIHdyb3RlOiA8bzpwPjwvbzpwPjwv cD4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+T24gMDMvMTMvMjAxMiAwODoz MSBBTSwgUGF1bCBDLiBCcnlhbiB3cm90ZTo8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mZ3Q7IE9u IE1vbiwgMjAxMi0wMy0xMiBhdCAxNDo1NSAtMDcwMCwgTWlrZSBBY2FyIHdyb3RlOjxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4mZ3Q7Jmd0 OyBUaGlzIHZlcnNpb24gb2YgdGhlIGRyYWZ0IGRvZXNuJ3QgYWRkcmVzcyB0aGUgYmFkIGludGVy YWN0aW9uIHdpdGggdGhlPG86cD48L286cD48L3ByZT4NCjxwcmU+Jmd0OyZndDsgSlNPTiBQb2lu dGVyIHNwZWMsIG5hbWVseSB0aGF0ICZxdW90O2FkZCZxdW90OyB0YWtlcyBhIEpTT04gUG9pbnRl ciB0byBhIHZhbHVlPG86cD48L286cD48L3ByZT4NCjxwcmU+Jmd0OyZndDsgd2hpY2ggZG9lcyBu b3QgeWV0IGV4aXN0LCBhbmQgdGhlIFBvaW50ZXIgc3BlYyBzYXlzIHRoYXQgaW4gdGhhdCBjYXNl LDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZndDsmZ3Q7IGFuIGltcGxlbWVudGF0aW9uIE1BWSBh Ym9ydCB3aXRoIGFuIGVycm9yLiBJcyB0aGF0IGdvaW5nIHRvIGJlPG86cD48L286cD48L3ByZT4N CjxwcmU+Jmd0OyZndDsgYWRkcmVzc2VkIGluIC0wMj88bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4m Z3Q7PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9w cmU+DQo8cHJlPiZndDsgSSdtIG9mIHRoZSBvcGluaW9uIHRoYXQgZXhwcmVzc2luZyBhIG5vdC15 ZXQtZXhpc3RpbmcgdGFyZ2V0IGFzIGEgSlNPTjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZndDsg UG9pbnRlciBpcyB0aGUgbW9zdCBzaW1wbGUgYW5kIGludHVpdGl2ZSBtZXRob2Qgc28gZmFyLjxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPklmIHRo ZSBwb2ludGVyIGlzIHRvIHRoZSBwYXJlbnQsIGFuZCB0aGVyZSBpcyBhICZxdW90O25hbWUmcXVv dDsgZWxlbWVudCwgdGhlIGNvZGUgPG86cD48L286cD48L3ByZT4NCjxwcmU+d2lsbCBsb29rIHNv bWV0aGluZyBsaWtlIChwZXJsaXNoIHN5bnRheCBhaGVhZCk6PG86cD48L286cD48L3ByZT4NCjxw cmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+IyBXZSBhbHJlYWR5IGZpZ3VyZWQgb3V0 IHdlJ3JlIGFkZGluZyBhbiBlbGVtZW50PG86cD48L286cD48L3ByZT4NCjxwcmU+bXkgJG5ld19u YW1lID0gJHBhdGNoLSZndDtbMF0tJmd0O3tuYW1lfTs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5t eSAkbmV3X3ZhbCA9ICRwYXRjaC0mZ3Q7WzBdLSZndDt7dmFsdWV9OzxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPiMgUmVzb2x2ZSB0aGUgcG9pbnRl ci48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5teSAkcGFyZW50ID0gZm9sbG93X3BvaW50ZXIoJHBh dGNoLSZndDtbMF0tJmd0O3thZGR9KTs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNw OzwvbzpwPjwvcHJlPg0KPHByZT4jICZxdW90O0FkZCZxdW90OyBsb2dpYzo8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT5pZiAoZXhpc3RzKCRwYXJlbnQtJmd0O3skbmV3X25hbWV9KSB7PG86cD48L286 cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRpZSAm cXVvdDskbmV3X25hbWUgYWxyZWFkeSBleGlzdHMgaW4gJHBhcmVudCEmcXVvdDs7PG86cD48L286 cD48L3ByZT4NCjxwcmU+fTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiRwYXJlbnQtJmd0O3skbmV3 X25hbWV9ID0gJG5ld192YWw7PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286 cD48L3ByZT4NCjxwcmU+R2V0IGEgcmVmZXJlbmNlIHRvIHRoZSBwYXJlbnQgYW5kIG1hbmlwdWxh dGUgaXQuIE5pY2UgYW5kIHNpbXBsZS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNw OzwvbzpwPjwvcHJlPg0KPHByZT5Db21wYXJlIGlmIHRoZSBsb2NhdGlvbiBpcyB0byB0aGUgbmV3 IG5hbWUgdG8gYmUgYWRkZWQ6PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286 cD48L3ByZT4NCjxwcmU+IyBXZSBhbHJlYWR5IGZpZ3VyZWQgb3V0IHdlJ3JlIGFkZGluZyBhbiBl bGVtZW50PG86cD48L286cD48L3ByZT4NCjxwcmU+bXkgJG5ld192YWwgPSAkcGF0Y2gtJmd0O1sw XS0mZ3Q7e3ZhbH07PG86cD48L286cD48L3ByZT4NCjxwcmU+bXkgJHBvaW50ZXIgPSAkcGF0Y2gt Jmd0O1swXS0mZ3Q7e2FkZH07PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286 cD48L3ByZT4NCjxwcmU+IyBSZXNvbHZlIHRoZSBwb2ludGVyLjxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPm15IEBwb2ludGVyX2VsZW1lbnRzID0gc3BsaXRfcG9pbnRlcigkcG9pbnRlcik7PG86cD48 L286cD48L3ByZT4NCjxwcmU+bXkgJG5ld19uYW1lID0gcG9wKEBwb2ludGVyX2VsZW1lbnRzKTs8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5teSAkcGFyZW50X3BvaW50ZXIgPSBqb2luX3BvaW50ZXIo QHBvaW50ZXJfZWxlbWVudHMpPG86cD48L286cD48L3ByZT4NCjxwcmU+bXkgJHBhcmVudCA9IGZv bGxvd19wb2ludGVyKCRwYXJlbnRfcG9pbnRlcik7PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86 cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+IyAmcXVvdDtBZGQmcXVvdDsgbG9naWM6PG86cD48 L286cD48L3ByZT4NCjxwcmU+aWYgKGV4aXN0cygkcGFyZW50LSZndDt7JG5ld19uYW1lfSkgezxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBkaWUgJnF1b3Q7JG5ld19uYW1lIGFscmVhZHkgZXhpc3RzIGluICRwYXJlbnQhJnF1b3Q7Ozxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPn08bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4kcGFyZW50LSZn dDt7JG5ld19uYW1lfSA9ICRuZXdfdmFsOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5i c3A7PC9vOnA+PC9wcmU+DQo8cHJlPlRoZSBmaXJzdCBsb29rcyBzaW1wbGVyIHRvIG1lLjxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPiZndDsgSSd2 ZSBoYWQgbm8gcHJvYmxlbXMgaW1wbGVtZW50aW5nIHRoZSBzcGVjcyBhcyBhIHJlc3VsdCBvZiB0 aGlzLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJl PiAmZ3Q7IEkgYWdyZWUgdGhhdCB0aGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mZ3Q7IGxhbmd1 YWdlIGluIHRoZSBKU09OIFBvaW50ZXIgc3BlYyBpcyBzdGlsbCBzb21ld2hhdCBhd2t3YXJkIGFu ZCBjb3VsZDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZndDsgc3RpbGwgc3RhbmQgdG8gYmUgaW1w cm92ZWQuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxw cmU+SSB0aGluayB0aGF0IG5vIG1hdHRlciBob3cgaXQncyBleHByZXNzZWQsIHRoaXMgaXMgYSBm bGF3IGluIHRoZSA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5yZWxhdGlvbnNoaXAgYmV0d2VlbiB0 aGVzZSBzcGVjcy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJl Pg0KPHByZT5UaGUgZ29hbCBvZiBzcGVjaWZpY2F0aW9uIGlzIHRvIGltcHJvdmUgaW50ZXJvcGVy YWJpbGl0eS4gQXMgdGhlc2UgPG86cD48L286cD48L3ByZT4NCjxwcmU+ZHJhZnRzIHN0YW5kLCB5 b3UgY2FuIHdyaXRlIGEgY29uZm9ybWluZyBQb2ludGVyIGltcGxlbWVudGF0aW9uIHRoYXQgaXMg PG86cD48L286cD48L3ByZT4NCjxwcmU+dXNlbGVzcyBmb3IgUGF0Y2guPG86cD48L286cD48L3By ZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+Jmd0OyBUaGUgc3VnZ2VzdGVk IGFsdGVybmF0aXZlIG9mIHJlcXVpcmluZyB0aGUgcGFyZW50IGFuZCB0YXJnZXQgbWVtYmVyIHRv PG86cD48L286cD48L3ByZT4NCjxwcmU+Jmd0OyBiZSBleHByZXNzZWQgc2VwYXJhdGVseSBpcyBt b3JlIHZlcmJvc2U8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJl Pg0KPHByZT5JdCBpcywgYnV0IEkgdGhpbmsgdGhlIGV4dHJhIHZlcmJvc2l0eSBjYW4gYmUgbWFk ZSB2ZXJ5IHZlcnkgc21hbGwgKGEgPG86cD48L286cD48L3ByZT4NCjxwcmU+ZmV3IGJ5dGVzIGF0 IG1vc3QpLiBCYWxhbmNpbmcgdGhhdCBhZ2FpbnN0IGNvbmZvcm1pbmcgYnV0IDxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPm5vdC1pbnRlcm9wZXJhYmxlIGltcGxlbWVudGF0aW9ucy4uLi4gSSB0aGlu ayB2ZXJib3NpdHkgaXMgYmV0dGVyLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wcmU+DQo8cHJlPiZndDsgYW5kIGNvbXBsZXguPG86cD48L286cD48L3ByZT4NCjxw cmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+SSBkaXNhZ3JlZSBoZXJlLCB0b28uIEkg dGhpbmsgcG9pbnRlci10by1wYXJlbnQvbmFtZS10by1hZGQgaXMgc2ltcGxlciA8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT50byBzcGVjaWZ5LCB0byB1bmRlcnN0YW5kLCBhbmQgdG8gdXNlIGluIGlt cGxlbWVudGF0aW9uLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9w cmU+DQo8cHJlPiZndDsgT3Zlci12ZXJib3NpdHkgb2YgSlNPTiBQYXRjaCBpcyBhbHJlYWR5IGFu IG9iamVjdGlvbiB0aGF0IGhhcyBiZWVuPG86cD48L286cD48L3ByZT4NCjxwcmU+Jmd0OyByYWlz ZWQgbW9yZSB0aGFuIG9uY2Ugb24gdGhpcyBsaXN0LCBhbmQgSSdtIG5vdCBpbmNsaW5lZCB0bzxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZndDsgZXhhY2VyYmF0ZSBpdCBmdXJ0aGVyIHVubGVzcyB0 aGVyZSBpcyBjb25zZW5zdXMgZnJvbSB0aGUgbWVtYmVycyBvZjxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPiZndDsgYXBwc2F3ZyB0aGF0IGl0IHNob3VsZCBiZSBhZG9wdGVkLjxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPkV2ZW4gdmVyeSBlYXJseSBk ZXNpZ24gZGlzY3Vzc2lvbnMgbm90ZWQgdGhpcyBwcm9ibGVtOyBzZWUgRGVhbiA8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT5MYW5kb2x0J3MgY29tbWVudHMgZnJvbSBBcHIgMjcgMjAxMTo8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgSSdtIHdvbmRlcmluZyBpZiBpdCBtYWtlcyBtb3JlIHNlbnNlIHRvIHVz ZSBhIHBhdGggZm9yIGFkZCBzaW1pbGFyPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHRvIHJlbW92ZSAtLSB0aGUgbGFzdCBwYXRoIHBvcnRpb24gd291bGQg YmUgdGhlICZxdW90O2VsZW1lbnQmcXVvdDsuIE9uZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBkcmF3YmFjayBpcyB0aGF0IHRoZSBhY3R1YWwgc3VibWl0 dGVkIHBvaW50ZXIgcGF0aCB3b3VsZG4ndCBwb2ludCB0bzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhIHZhbGlkIG5vZGUgdW50aWwgYWZ0ZXIgdGhlIHBh dGNoIGlzIGFwcGxpZWQgKHdoaWNoLCBJIGFzc3VtZSwgaXM8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgd2h5IHlvdSB1c2VkIHRoZSAmcXVvdDtlbGVtZW50 JnF1b3Q7IGFwcHJvYWNoKS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpw PjwvcHJlPg0KPHByZT48YSBocmVmPSJodHRwOi8vZ3JvdXBzLmdvb2dsZS5jb20vZ3JvdXAvanNv bi1wYXRjaC9icm93c2VfdGhyZWFkL3RocmVhZC82ZTFjYzY1NTAxZWRhMzI0Ij5odHRwOi8vZ3Jv dXBzLmdvb2dsZS5jb20vZ3JvdXAvanNvbi1wYXRjaC9icm93c2VfdGhyZWFkL3RocmVhZC82ZTFj YzY1NTAxZWRhMzI0IzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpw PjwvcHJlPg0KPHByZT5Zb3VyIG9yaWdpbmFsIGRlc2lnbiB3YXM8bzpwPjwvbzpwPjwvcHJlPg0K PHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgMy4gWW91J3JlIHJpZ2h0LCB0aGUgcmVhc29uIEkga2VwdCAmcXVvdDtlbGVtZW50JnF1b3Q7 IHdhcyBzbyB0aGF0IHRoZSBwb2ludGVyPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IGFsd2F5cyByZXNvbHZlcyB0byBhIG5vZGUuIFRoaXMgaWRlYSBpcyBn ZXR0aW5nIHB1c2hiYWNrIGJ5IHRob3NlPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHdobyB3YW50IHVsdHJhLXRpZ2h0IHN5bnRheDsgYW55IGZ1cnRoZXIg ZmVlZGJhY2sgb24gdGhpcyBwb2ludDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyB3b3VsZCBiZSBhcHByZWNpYXRlZC48bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5Db25zaWRlciB0aGlzIChiZWxhdGVkKSBm ZWVkYmFjayBpbiBmYXZvciBvZiBwb2ludGVycyBhbHdheXMgcmVmZXJyaW5nIDxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPnRvIGV4aXN0aW5nIG5vZGVzIDopPG86cD48L286cD48L3ByZT4NCjxwcmU+ PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+RGVhbiB3ZW50IG9uIHRvIHdyaXRlPG86cD48 L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IEdpdmVuIHdlbGwtZGVmaW5lZCBwYXRoIHNlbWFudGljcyB0aGlzIHNo b3VsZG4ndCBiZSBhcyBpbXBvcnRhbnQgLS08bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgd2Ugc2hvdWxkIGJlIGFibGUgdG8gY291bnQgb24gYW4gaW1wbGVt ZW50YXRpb24gY29ycmVjdGx5IHNwbGl0dGluZzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBhIHBhdGggaW50byBwYXJlbnQgYW5kIGVsZW1lbnQgdGFyZ2V0 cy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5J J20gbm90IHN1cmUgd2h5IHRoYXQgYXNzdW1wdGlvbiB3b3VsZCBiZSB0cnVlOyBzb21lYm9keSBy ZWFkaW5nIGp1c3QgPG86cD48L286cD48L3ByZT4NCjxwcmU+dGhlIFBvaW50ZXIgc3BlYyB3b3Vs ZG4ndCByZWFsaXplIHRoaXMgbmVlZCwgd2hpY2ggUGF0Y2ggaW1wb3Nlcy48bzpwPjwvbzpwPjwv cHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_9452079D1A51524AA5749AD23E003928094FF3exchmbx901corpclo_-- From julian.reschke@gmx.de Tue Mar 20 23:42:57 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5C5421E8018 for ; Tue, 20 Mar 2012 23:42:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.564 X-Spam-Level: X-Spam-Status: No, score=-103.564 tagged_above=-999 required=5 tests=[AWL=-0.965, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SIfP096Iur4E for ; Tue, 20 Mar 2012 23:42:55 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id B473421E8040 for ; Tue, 20 Mar 2012 23:42:54 -0700 (PDT) Received: (qmail invoked by alias); 21 Mar 2012 06:42:52 -0000 Received: from p57A6E8EB.dip.t-dialin.net (EHLO [192.168.178.36]) [87.166.232.235] by mail.gmx.net (mp038) with SMTP; 21 Mar 2012 07:42:52 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/BnRMiO5zBDbC6VZ3eKTpiFiboiwc7XZLMmjom2O yeOLIihWiPugXU Message-ID: <4F697867.2050500@gmx.de> Date: Wed, 21 Mar 2012 07:42:47 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Mike Acar References: <9F0A2492-AE7D-4C12-8BB0-13489FD7F6C1@gmail.com> <1331271383.6504.1.camel@neutron> <4F5E6255.9040402@cloudmark.com> <1331651889.3301.5.camel@neutron> <4F6914D7.5050505@cloudmark.com> In-Reply-To: <4F6914D7.5050505@cloudmark.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-pbryan-json-patch-04 - comments X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 21 Mar 2012 06:42:57 -0000 On 2012-03-21 00:37, Mike Acar wrote: > On 03/13/2012 08:18 AM, Paul C. Bryan wrote: >> On Mon, 2012-03-12 at 13:53 -0700, Mike Acar wrote: >> >>> I'm unsure about test as well. It seems strange to me to express "change >>> this document if it looks like this" in a patch; if the application >>> creating the patch doesn't know how the document looks, how can it >>> create a patch? >> >> I'm surprised that it seems so strange, as this is very much like how >> text-based diff/patches work. > > But in diff, the "test" is not optional. The diff (AFAIK anyway) always > expresses "replace this with that". Patch doesn't. > > So I guess I should say it's the optionality that makes it a bit weird > to me - mixing tested and not-tested operations. When would that make > sense? > ... What makes you think it's optional? Best regards, Julian From julian.reschke@gmx.de Tue Mar 20 23:44:50 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8653221F857F for ; Tue, 20 Mar 2012 23:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.53 X-Spam-Level: X-Spam-Status: No, score=-103.53 tagged_above=-999 required=5 tests=[AWL=-0.931, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CUHdVMmI9QXW for ; Tue, 20 Mar 2012 23:44:50 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 914B621F8484 for ; Tue, 20 Mar 2012 23:44:49 -0700 (PDT) Received: (qmail invoked by alias); 21 Mar 2012 06:44:48 -0000 Received: from p57A6E8EB.dip.t-dialin.net (EHLO [192.168.178.36]) [87.166.232.235] by mail.gmx.net (mp031) with SMTP; 21 Mar 2012 07:44:48 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+7Vsp/Px67Rsc2FQwbfbwPUFtd0ydns8rcDxpj0Z NQ2kDzEXuS/+vT Message-ID: <4F6978D8.10605@gmx.de> Date: Wed, 21 Mar 2012 07:44:40 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Barry Leiba References: <503575970.11554@cnnic.cn> <4A10020DB6464A0BBA535BF75D21A9D9@LENOVO47E041CF> <9452079D1A51524AA5749AD23E003928094CEB@exch-mbx901.corp.cloudmark.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "apps-discuss@ietf.org" Subject: [apps-discuss] Use of RFC 2119, Re: WGLC: draft-ietf-appsawg-about-uri-scheme-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 21 Mar 2012 06:44:50 -0000 On 2012-03-21 03:34, Barry Leiba wrote: >> [Relatively] Minor Issues: >> I'm not so sure about use of RFC2119 language in the IANA Considerations >> section. You're not really describing interoperability requirements with IANA. > > I'm sure. And it's my text -- this is one that Mykyta doesn't like. > The three MUSTs in there are not directed at IANA, but at people > writing new registrations. They tell those people what their > registrations have to look like, and I wanted to use MUST to stress > that even though this is an FCFS policy, there are requirements > nonetheless. > ... I'm with Murray here. This is something RFC 2119 keywords are not for. Best regards, Julian From julian.reschke@gmx.de Tue Mar 20 23:45:47 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F93821F8582 for ; Tue, 20 Mar 2012 23:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.499 X-Spam-Level: X-Spam-Status: No, score=-103.499 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EMOoGUzpQ+2O for ; Tue, 20 Mar 2012 23:45:46 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 1EC3821F8581 for ; Tue, 20 Mar 2012 23:45:45 -0700 (PDT) Received: (qmail invoked by alias); 21 Mar 2012 06:45:45 -0000 Received: from p57A6E8EB.dip.t-dialin.net (EHLO [192.168.178.36]) [87.166.232.235] by mail.gmx.net (mp004) with SMTP; 21 Mar 2012 07:45:45 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+6JkNSjCK64iJY18zYCRgJnswAgduQifUFJGAhOw fUiMMhE8nvLWiU Message-ID: <4F697917.3090105@gmx.de> Date: Wed, 21 Mar 2012 07:45:43 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "Paul C. Bryan" References: <20120309212231.16366.52439.idtracker@ietfa.amsl.com> <4F5E70BE.9070308@cloudmark.com> <1331652710.3301.18.camel@neutron> <4F691080.7020606@cloudmark.com> <1332308116.2171.30.camel@neutron> In-Reply-To: <1332308116.2171.30.camel@neutron> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-json-patch-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 21 Mar 2012 06:45:47 -0000 On 2012-03-21 06:35, Paul C. Bryan wrote: > As I stated previously, if there's consensus on a more verbose patch > operation object format, I will defer. Any opinions from other members > of the working group? > ... Please leave it the way it is. Best regards, Julian From duerst@it.aoyama.ac.jp Tue Mar 20 23:55:11 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90D4B21F84DD for ; Tue, 20 Mar 2012 23:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.25 X-Spam-Level: X-Spam-Status: No, score=-100.25 tagged_above=-999 required=5 tests=[AWL=-0.460, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PhnAgXTTq7wD for ; Tue, 20 Mar 2012 23:55:11 -0700 (PDT) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id A118B21F84D8 for ; Tue, 20 Mar 2012 23:55:10 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id q2L6t9Jb008089 for ; Wed, 21 Mar 2012 15:55:09 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 5172_a483_ccb36808_7322_11e1_9bce_001d096c5782; Wed, 21 Mar 2012 15:55:09 +0900 Received: from [IPv6:::1] ([133.2.210.1]:38867) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 21 Mar 2012 15:55:14 +0900 Message-ID: <4F697B48.1050305@it.aoyama.ac.jp> Date: Wed, 21 Mar 2012 15:55:04 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <20120309212231.16366.52439.idtracker@ietfa.amsl.com> <4F689626.9070500@gmx.de> <1332261146.2171.7.camel@neutron> <4F68B37E.9060608@gmx.de> <1332262482.2171.11.camel@neutron> <4F68BDB7.7030808@gmx.de> <1332269074.2171.21.camel@neutron> <4F68D295.2040401@gmx.de> <1332277294.2171.25.camel@neutron> <4F68F2F8.7000207@gmx.de> <9452079D1A51524AA5749AD23E0039280949C7@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E0039280949C7@exch-mbx901.corp.cloudmark.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] feedback on draft-ietf-appsawg-json-patch-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 21 Mar 2012 06:55:11 -0000 On 2012/03/21 6:40, Murray S. Kucherawy wrote: > Does there need to be one-and-only-one? In theory, not necessarily. In practice, not having a lot of variation usually helps. > Or I guess more accurately, do we need to say this is the one and only way to do this? Seems like that closes the door to someone coming up with a better idea. Fragment pointers into datastructures such as JSON isn't exactly a brand new field with lots of new possibilities. And XPointer has shown that making it too complicated cuts out most implementations. My proposal would be to somehow include an extensibility hatch, but then say this is the one and only one. Regards, Martin. From msk@cloudmark.com Wed Mar 21 00:45:18 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 868B721F8603 for ; Wed, 21 Mar 2012 00:45:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rvqW+9nYXv3s for ; Wed, 21 Mar 2012 00:45:17 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id DAADD21F8601 for ; Wed, 21 Mar 2012 00:45:17 -0700 (PDT) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Wed, 21 Mar 2012 00:45:17 -0700 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Thread-Topic: [apps-discuss] WGLC: draft-ietf-appsawg-about-uri-scheme-03.txt Thread-Index: AQHM+zSl3R1Ur6zXPEClJ5AyVkiELpZz6yzQgACqLID//959oA== Date: Wed, 21 Mar 2012 07:45:16 +0000 Message-ID: <9452079D1A51524AA5749AD23E003928095184@exch-mbx901.corp.cloudmark.com> References: <503575970.11554@cnnic.cn> <4A10020DB6464A0BBA535BF75D21A9D9@LENOVO47E041CF> <9452079D1A51524AA5749AD23E003928094CEB@exch-mbx901.corp.cloudmark.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [67.160.203.60] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [apps-discuss] WGLC: draft-ietf-appsawg-about-uri-scheme-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 21 Mar 2012 07:45:18 -0000 > -----Original Message----- > From: barryleiba.mailing.lists@gmail.com [mailto:barryleiba.mailing.lists= @gmail.com] On Behalf Of Barry Leiba > Sent: Tuesday, March 20, 2012 7:35 PM > To: Murray S. Kucherawy > Cc: apps-discuss@ietf.org > Subject: Re: [apps-discuss] WGLC: draft-ietf-appsawg-about-uri-scheme-03.= txt >=20 > > [Relatively] Minor Issues: > > I'm not so sure about use of RFC2119 language in the IANA > > Considerations section. =A0You're not really describing > > interoperability requirements with IANA. >=20 > I'm sure. And it's my text -- this is one that Mykyta doesn't like. > The three MUSTs in there are not directed at IANA, but at people > writing new registrations. They tell those people what their > registrations have to look like, and I wanted to use MUST to stress > that even though this is an FCFS policy, there are requirements > nonetheless. I think my point is that the IANA Considerations section spells out the rul= es for a new registry when the registry is created, especially when conform= ant with RFC5226. Everything in such a section is essentially a MUST, beca= use you're either filling out or defining a template and the registry's ini= tial entries. I can't imagine a "This field SHOULD/MAY contain..." anywher= e in an IANA Considerations section, except maybe optional fields, but they= 're typically labeled as such in the first place. In the case of this draft, the second MUST in particular seems unnecessary.= If the first one were changed to "has to" or similar, I have some doubts = that IANA would start slipping in invalid tokens. And for the third one, t= hey're already pretty good at preferring (or even requiring?) permanent doc= ument links without this document having to say so. I don't feel particularly strongly about this. It just seems unnecessary. > > [Absolutely] Nits: > > All of these are either reductions of overly-wordy text or fixes to > minor grammar nits, or both. > ... > > =A0 =A0 =A0 =A0OLD > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0The concept of "about" URIs has been for= med at the > > times when the > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0applications did not have the "friendly"= user > > interface, in order to > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0provide an access to the aforementioned = resources via > > typing the URIs > ... > > =A0 =A0 =A0 =A0NEW > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0The concept of "about" URIs formed when = applications > > did not have a > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"friendly" user interface, to enable acc= ess to the > > aforementioned > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0resources by typing URIs into an address= bar or > similar feature. > ... >=20 > Yeah, good luck with that. I tried to convince Mykyta to tone the > rhetoric down in there, and he declined... and I didn't see it as > important enough to fight about. Well, parts of it are grammatically incorrect and the RFC Editor will have = to fix them anyway, but a lot of my nits attempted to simplify needlessly w= ordy or overly formal paragraphs. I hope the authors will give them a seco= nd look. -MSK From julian.reschke@gmx.de Wed Mar 21 02:11:45 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABC2521F8677 for ; Wed, 21 Mar 2012 02:11:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.175 X-Spam-Level: X-Spam-Status: No, score=-104.175 tagged_above=-999 required=5 tests=[AWL=-1.876, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9SDDMO8OpuZC for ; Wed, 21 Mar 2012 02:11:45 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id CE8E921F864F for ; Wed, 21 Mar 2012 02:11:43 -0700 (PDT) Received: (qmail invoked by alias); 21 Mar 2012 09:11:42 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp033) with SMTP; 21 Mar 2012 10:11:42 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/S19MZBT7SLx/ujoRcekSzEhLCjFuHRNp1Ot7T6r jBOYqEHC2Xxu1a Message-ID: <4F699B49.1010108@gmx.de> Date: Wed, 21 Mar 2012 10:11:37 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= References: <20120309212231.16366.52439.idtracker@ietfa.amsl.com> <4F689626.9070500@gmx.de> <1332261146.2171.7.camel@neutron> <4F68B37E.9060608@gmx.de> <1332262482.2171.11.camel@neutron> <4F68BDB7.7030808@gmx.de> <1332269074.2171.21.camel@neutron> <4F68D295.2040401@gmx.de> <1332277294.2171.25.camel@neutron> <4F68F2F8.7000207@gmx.de> <9452079D1A51524AA5749AD23E0039280949C7@exch-mbx901.corp.cloudmark.com> <4F697B48.1050305@it.aoyama.ac.jp> In-Reply-To: <4F697B48.1050305@it.aoyama.ac.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] feedback on draft-ietf-appsawg-json-patch-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 21 Mar 2012 09:11:45 -0000 On 2012-03-21 07:55, "Martin J. Dürst" wrote: > On 2012/03/21 6:40, Murray S. Kucherawy wrote: > >> Does there need to be one-and-only-one? > > In theory, not necessarily. In practice, not having a lot of variation > usually helps. > >> Or I guess more accurately, do we need to say this is the one and only >> way to do this? Seems like that closes the door to someone coming up >> with a better idea. > > Fragment pointers into datastructures such as JSON isn't exactly a brand > new field with lots of new possibilities. And XPointer has shown that > making it too complicated cuts out most implementations. My proposal > would be to somehow include an extensibility hatch, but then say this is > the one and only one. In XML, as far as I understand, the escape hatch is that identifiers do not allow brackets, and thus these are free for defining new addressing schemes. So in JSON Pointer, we'd need to escape a few more characters when using in fragment identifiers. Also, it seems this needs to be coordinated with a potential spec defining a "+json" media type suffix... Best regards, Julian From julian.reschke@gmx.de Wed Mar 21 06:00:24 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0498321F84FC for ; Wed, 21 Mar 2012 06:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.309 X-Spam-Level: X-Spam-Status: No, score=-104.309 tagged_above=-999 required=5 tests=[AWL=-1.710, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TXvhPFu3n24Z for ; Wed, 21 Mar 2012 06:00:23 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 1463021F84D9 for ; Wed, 21 Mar 2012 06:00:22 -0700 (PDT) Received: (qmail invoked by alias); 21 Mar 2012 13:00:21 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp040) with SMTP; 21 Mar 2012 14:00:21 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18OWhM9yAUOArOx96H1X4XsbOyu4N5HjqVQO+D8zv FCEOjiV4fFqxul Message-ID: <4F69D0CD.2090608@gmx.de> Date: Wed, 21 Mar 2012 13:59:57 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "Paul C. Bryan" References: <20120309212231.16366.52439.idtracker@ietfa.amsl.com> <4F5E70BE.9070308@cloudmark.com> <1331652710.3301.18.camel@neutron> <4F691080.7020606@cloudmark.com> <1332308116.2171.30.camel@neutron> <4F697917.3090105@gmx.de> In-Reply-To: <4F697917.3090105@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-json-patch-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 21 Mar 2012 13:00:24 -0000 On 2012-03-21 07:45, Julian Reschke wrote: > On 2012-03-21 06:35, Paul C. Bryan wrote: >> As I stated previously, if there's consensus on a more verbose patch >> operation object format, I will defer. Any opinions from other members >> of the working group? >> ... > > Please leave it the way it is. ...by which I mean the syntax. I *do* agree that we need to tune the language so it defines what needs to happen when the pointer identifies a non-existing piece of the referenced document (but we can do this by tuning the language in the Patch spec). Best regards, Julian From evnikita2@gmail.com Wed Mar 21 06:22:57 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E70F621F860D for ; Wed, 21 Mar 2012 06:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.358 X-Spam-Level: X-Spam-Status: No, score=-2.358 tagged_above=-999 required=5 tests=[AWL=-1.210, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ucFL4rsITLAo for ; Wed, 21 Mar 2012 06:22:56 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1310921F8601 for ; Wed, 21 Mar 2012 06:22:56 -0700 (PDT) Received: by yhkk25 with SMTP id k25so978953yhk.31 for ; Wed, 21 Mar 2012 06:22:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TG6YS7q0DHuxn6yanpQF8ph9/L53K0iaJdYm9aIW6Uc=; b=KC6/3oDjNEkkuPYGF9VSjEWapHntQZVBk/HWepLDLAn1udCfIRkRvaQnhD4dU12YFa DPrI/0td4hBSJ34HgrW6AvuzPLQz4Hhn/egIKgL6uK1/nK8yNevOpeaXR4rKXPlutLRY LBHkTgilVSIRgOKINEnz7GOb2VcvWbuqI7JytWURICxqEy9twpoXtjTzsRb1jiY2Bjpc 7c4jcDgDHJCGTxhZf2I+gvOD8hVrgur1hegWUFrT1nYvLcDl1n75KanKhIO0LABePJcb inmDT1W6oGJt7oVbbteg0KI6pkR+bBU1s2XS0FQbVh1RTiisgcYIskPbPqtzFw+VWXN2 u6Ag== MIME-Version: 1.0 Received: by 10.182.136.10 with SMTP id pw10mr4436222obb.73.1332336175601; Wed, 21 Mar 2012 06:22:55 -0700 (PDT) Received: by 10.182.60.1 with HTTP; Wed, 21 Mar 2012 06:22:55 -0700 (PDT) In-Reply-To: <9452079D1A51524AA5749AD23E003928094CEB@exch-mbx901.corp.cloudmark.com> References: <503575970.11554@cnnic.cn> <4A10020DB6464A0BBA535BF75D21A9D9@LENOVO47E041CF> <9452079D1A51524AA5749AD23E003928094CEB@exch-mbx901.corp.cloudmark.com> Date: Wed, 21 Mar 2012 15:22:55 +0200 Message-ID: From: Mykyta Yevstifeyev To: "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=e89a8f64697f77d8c004bbc0b002 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] WGLC: draft-ietf-appsawg-about-uri-scheme-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 21 Mar 2012 13:22:58 -0000 --e89a8f64697f77d8c004bbc0b002 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable 21 =CD=C1=D2=D4=C1 2012 =C7. 1:58 =D0=CF=CC=D8=DA=CF=D7=C1=D4=C5=CC=D8 Murr= ay S. Kucherawy =CE=C1=D0=C9=D3=C1=CC: > > -----Original Message----- > > From: apps-discuss-bounces@ietf.org [mailto: > apps-discuss-bounces@ietf.org] On Behalf Of Jiankang YAO > > Sent: Monday, March 05, 2012 5:01 PM > > To: apps-discuss@ietf.org > > Cc: appsawg-chairs@tools.ietf.org > > Subject: [apps-discuss] WGLC: draft-ietf-appsawg-about-uri-scheme-03.tx= t > > > > Dear colleagues, > > > > This message starts a two-week WGLC on the draft draft-ietf-appsawg- > > about-uri-scheme-03.txt. > > > > Please help to review this draft. If you support publication, please > > state as much on the list. If you are opposed to publication, please > > state that on the list as well. It is more/only helpful if you give > > your reasons for your position as part of your statement. > > > > Pls send your comments to apps-discuss@ietf.org or appsawg- > > chairs@tools.ietf.org or editors. > > > > The WGLC will end on March 20, 2012 at 1:00 UTC. > > This is coming in a bit late, and apologies for that (and shame on me for > complaining about other people who come in late on my drafts!), but the > points should be easily resolved. > > [Relatively] Major Issues: > > In Section 4.2, you talk about the Intended Usage field of the > registration being "what they must be resolved to, if resolvable." Why > would you allow registration of something that can't resolve to something= ? > This is what we had from the previous version of the document when we had resolvable/unresolvable distinction. We've dropped it, so I think I'll drop these words as well. (Actually, this document was originally written "for" HTML5 'about' URIs, which are unresolvable, but later we reached an agreement on not introducing this in the document.) > > Section 4.2 also talks about referencing a document that allows one to > create an "interoperable" implementation of the "about" URI being > registered. I know we talked about this in the WG, but a new reader migh= t > well ask "interoperable with what?" You might want to answer that questi= on > before the IESG asks it. :-) > I believe this isn't an important matter. "interoperable" is quite usual term, and I don't think we need to detalize this. > > [Relatively] Minor Issues: > I'm not so sure about use of RFC2119 language in the IANA Considerations > section. You're not really describing interoperability requirements with > IANA. > I'll reply to a later message. > > [Absolutely] Nits: > All of these are either reductions of overly-wordy text or fixes to minor > grammar nits, or both. > > Section 1: > > OLD > scheme, that is currently widely used by Web browsers and > some other > > NEW > scheme, which is currently widely used by Web browsers and > some other > > Also, I'm not sure that "Web" is a proper noun, so it should probably be > "web". > Fixed. > > OLD > The concept of "about" URIs has been formed at the times > when the > applications did not have the "friendly" user interface, i= n > order to > provide an access to the aforementioned resources via > typing the URIs > in the address bar. Even though the user interface of > current > Internet-targeted software effectively rescinds the issue, > and > "about" URIs can be thought to be a rudimentary phenomenon= , > they are > still supported by a variety of Web browsers and are not > going to cease > to exist. > > As use of "about" URIs has been quiet long-lasting, and th= e > URIs have > been used without any proper registration and absent any > proper > specification, the necessity for the latter two actions > arises. > The purpose of this document is to provide a stable > specification for > "about" URI scheme and correspondingly register it in the > IANA > registry. Along, several provisions for handling the > "about" URIs > Are set. > > NEW > The concept of "about" URIs formed when applications did > not have a > "friendly" user interface, to enable access to the > aforementioned > resources by typing URIs into an address bar or similar > feature. > They have however become commonplace in modern user > applications. > > Given their current ubiquity, their absence from the URI > scheme > registry and lack of a defining document is conspicuous. > Therefore, > this document provides a stable specification for the > "about" > URI scheme and registers it with IANA. > Quite agree with this text. > > Section 2.2: > > OLD > > Generally speaking, the resource a particular "about" URI > resolves to > is denoted by part of the URI, and > > specifies additional information concerning its handling > and/or the > information that should be returned in the resource a URI > is resolved > to. > > However, it is impossible to specify binding between all > the possible > tokens and the semantics of "about" URIs that would contai= n > such > tokens, which this document does not attempt to do. > Therefore, any > application resolving an "about" URI MAY choose the > resource it is > resolved to at its own discretion, with the exception of > those > defined below as 'special-purpose "about" URIs'. They MAY > use > internal redirection to accomplish this (for instance, Ope= ra > redirects all "about" URIs except "about:blank" to its > internal > "opera" URIs). > > NEW > > Generally speaking, the resource to which a particular > "about" URI resolves > is denoted by part of the URI, and > > specifies additional information concerning its handling > and/or the > information that should be returned in the resource to > which the URI > resolves. > > However, it is impossible to specify a binding between all > the possible > tokens and the semantics of "about" URIs that would contai= n > such > tokens. Therefore, the resource referenced by the URI is > application-specific, except for those listed below as > 'special-purpose > "about" URIs'. Applications MAY use internal redirection > to accomplish > this (for instance, the Opera web browser redirects all > "about" URIs except > "about:blank" to its internal "opera" URIs). > Changed. > > Section 2.2.1: > > OLD > > A small, though expandable, range of s are > reserved for > special purposes ("special-purpose tokens"). > > NEW > > A small, though extensible, range of s is > reserved for > Special purposes ("special-purpose tokens"). > > OLD > > Additional special-purpose tokens can be defined by > registering an > registry created in Section 4.2. Special-purpose "about" > URIs are > intended to be uncommon, and new ones should be defined > only when > there is a need to strongly connect a particular > with a > particular function in all applications. > > NEW > > Additional special-purpose tokens can be defined by > updating the > registry created in Section 4.2. Special-purpose "about" > URIs are > intended to be uncommon, and new ones only need to be > defined when > there is a need to strongly connect a particular > with a > particular function in all applications. > Taken into account. > > Section 3: > > OLD > > Generic security considerations for URIs are discussed in > Section 7 > of RFC 3986 [RFC3986]. However, many of those provisions > hardly > apply to "about" URI scheme, as they are mainly scoped to > schemes > used in the Internet, not internally. > > "about" URIs may sometimes refer to a sensitive > information, such as > user passwords stored in a cache, or parameter that, if > changed, may > affect user's data. The application should therefore > ensure that > user's data is in the safety, and no threats are imposed b= y > "about" > URIs. > > NEW > > Generic security considerations for URIs are discussed in > Section 7 > of RFC 3986 [RFC3986]. However, few of those provisions > apply to the "about" URI scheme, as they are mainly scoped > to schemes > used in the Internet, not internally. > > "about" URIs can sometimes refer to a sensitive > information, such as > user passwords stored in a cache, or parameters that, if > changed, could > affect user's data. The application therefore needs to > ensure that > the user's data is secured, and no threats are imposed by > "about" > URIs. > > Section 4.2: > > OLD > > o Intended usage: A short description of how "about" URIs > with the > registered token must be handled; especially, what they > must be > resolved to, if resolvable. > > o Handling query component: It should be mentioned whethe= r > there are > some provisions on handling query components in the > "about" URIs > with the registered token. > > o Contact/Change controller: An individual or an > organization which > (1) should be contacted for more details, and (2) is > authorized to > change the registration. > > o Specification. This provides documentation at a level > that could > be used to create a compliant, interoperable > implementation of the > registered "about" URI. The reference to a full > specification MUST > be provided here, and there should be a reasonable > expectation that > the documentation will remain available. IANA will > consult with > the IESG or its specified delegate if there is doubt > about whether > the specification is adequate for the purpose. > > The following is a template for "blank" token: > > NEW > o Intended usage: A short description of how "about" URIs > with the > registered token must be handled; especially, to what > resource > they are to resolve. > > o Handling query component: Describe any requirements for > handling > query components in "about" URIs that contain the register= ed > token. > > o Contact/Change controller: An individual or an > organization that > (1) should be contacted for more details, and (2) is > authorized to > change the registration. > > o Specification. A permanent reference to a specification > that can > be used to create a compliant, interoperable > implementation of the > registered "about" URI. IANA will consult with > the IESG or its specified delegate if there is doubt > about whether > the specification is adequate for this purpose. > > The following is a template for the "blank" token: > Accepted. Thanks you for your assistance. Mykyta Yevstifeyev > > -MSK > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --e89a8f64697f77d8c004bbc0b002 Content-Type: text/html; charset=KOI8-R Content-Transfer-Encoding: quoted-printable
21 =CD=C1=D2=D4=C1 2012=9A=C7. 1:58 =D0=CF=CC=D8= =DA=CF=D7=C1=D4=C5=CC=D8 Murray S. Kucherawy <msk@cloudmark.com> =CE=C1=D0=C9=D3=C1=CC:
> -----Original Message-----
> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On = Behalf Of Jiankang YAO
> Sent: Monday, March 05, 2012 5:01 PM
> To: apps-di= scuss@ietf.org
> Cc: appsawg-chairs@tools.ietf.org
> Subject: [apps-discuss] WGLC: draft-ietf-appsawg-about-uri-scheme-03.t= xt
>
> Dear colleagues,
>
> This message starts a two-week WGLC on the draft draft-ietf-appsawg- > about-uri-scheme-03.txt.
>
> Please help to review this draft. =9AIf you support publication, pleas= e
> state as much on the list. =9AIf you are opposed to publication, pleas= e
> state that on the list as well. =9AIt is more/only helpful if you give=
> your reasons for your position as part of your statement.
>
> Pls send your comments to apps-discuss@ietf.org or appsawg-
> chairs@tool= s.ietf.org or editors.
>
> The WGLC will end on March 20, 2012 at 1:00 UTC.

This is coming in a bit late, and apologies for that (and shame on me for c= omplaining about other people who come in late on my drafts!), but the poin= ts should be easily resolved.

[Relatively] Major Issues:

In Section 4.2, you talk about the Intended Usage field of the registration= being "what they must be resolved to, if resolvable." =9AWhy wou= ld you allow registration of something that can't resolve to something?=

This is what we had from the previous version of the = document when we had resolvable/unresolvable distinction.=9A We've drop= ped it, so I think I'll drop these words as well.=9A (Actually, this do= cument was originally written "for" HTML5 'about' URIs, w= hich are unresolvable, but later we reached an agreement on not introducing= this in the document.)
=9A

Section 4.2 also talks about referencing a document that allows one to crea= te an "interoperable" implementation of the "about" URI= being registered. =9AI know we talked about this in the WG, but a new read= er might well ask "interoperable with what?" =9AYou might want to= answer that question before the IESG asks it. =9A:-)

I believe this isn't an important matter.=9A &quo= t;interoperable" is quite usual term, and I don't think we need to= detalize this.
=9A

[Relatively] Minor Issues:
I'm not so sure about use of RFC2119 language in the IANA Consideration= s section. =9AYou're not really describing interoperability requirement= s with IANA.

I'll reply to a later message. =9A

[Absolutely] Nits:
All of these are either reductions of overly-wordy text or fixes to minor g= rammar nits, or both.

Section 1:

=9A =9A =9A =9AOLD
=9A =9A =9A =9A =9A =9A =9A =9Ascheme, that is currently widely used by We= b browsers and some other

=9A =9A =9A =9ANEW
=9A =9A =9A =9A =9A =9A =9A =9Ascheme, which is currently widely used by W= eb browsers and some other

Also, I'm not sure that "Web" is a proper noun, so it should = probably be "web".

Fixed.
=9A

=9A =9A =9A =9AOLD
=9A =9A =9A =9A =9A =9A =9A =9AThe concept of "about" URIs has b= een formed at the times when the
=9A =9A =9A =9A =9A =9A =9A =9Aapplications did not have the "friendl= y" user interface, in order to
=9A =9A =9A =9A =9A =9A =9A =9Aprovide an access to the aforementioned res= ources via typing the URIs
=9A =9A =9A =9A =9A =9A =9A =9Ain the address bar. =9AEven though the user= interface of current
=9A =9A =9A =9A =9A =9A =9A =9AInternet-targeted software effectively resc= inds the issue, and
=9A =9A =9A =9A =9A =9A =9A =9A"about" URIs can be thought to be= a rudimentary phenomenon, they are
=9A =9A =9A =9A =9A =9A =9A =9Astill supported by a variety of Web browser= s and are not going to cease
=9A =9A =9A =9A =9A =9A =9A =9Ato exist.

=9A =9A =9A =9A =9A =9A =9A =9AAs use of "about" URIs has been q= uiet long-lasting, and the URIs have
=9A =9A =9A =9A =9A =9A =9A =9Abeen used without any proper registration a= nd absent any proper
=9A =9A =9A =9A =9A =9A =9A =9Aspecification, the necessity for the latter= two actions arises.
=9A =9A =9A =9A =9A =9A =9A =9AThe purpose of this document is to provide = a stable specification for
=9A =9A =9A =9A =9A =9A =9A =9A"about" URI scheme and correspond= ingly register it in the IANA
=9A =9A =9A =9A =9A =9A =9A =9Aregistry. =9AAlong, several provisions for = handling the "about" URIs
=9A =9A =9A =9A =9A =9A =9A =9AAre set.

=9A =9A =9A =9ANEW
=9A =9A =9A =9A =9A =9A =9A =9AThe concept of "about" URIs forme= d when applications did not have a
=9A =9A =9A =9A =9A =9A =9A =9A"friendly" user interface, to ena= ble access to the aforementioned
=9A =9A =9A =9A =9A =9A =9A =9Aresources by typing URIs into an address ba= r or similar feature.
=9A =9A =9A =9A =9A =9A =9A =9AThey have however become commonplace in mod= ern user applications.

=9A =9A =9A =9A =9A =9A =9A =9AGiven their current ubiquity, their absence= from the URI scheme
=9A =9A =9A =9A =9A =9A =9A =9Aregistry and lack of a defining document is= conspicuous. =9ATherefore,
=9A =9A =9A =9A =9A =9A =9A =9Athis document provides a stable specificati= on for the "about"
=9A =9A =9A =9A =9A =9A =9A =9AURI scheme and registers it with IANA.
<= /blockquote>

Quite agree with this text.
=9A

Section 2.2:

=9A =9A =9A =9AOLD

=9A =9A =9A =9A =9A =9A =9A =9AGenerally speaking, the resource a particul= ar "about" URI resolves to
=9A =9A =9A =9A =9A =9A =9A =9Ais denoted by <about-token> part of t= he URI, and <about-query>
=9A =9A =9A =9A =9A =9A =9A =9Aspecifies additional information concerning= its handling and/or the
=9A =9A =9A =9A =9A =9A =9A =9Ainformation that should be returned in the = resource a URI is resolved
=9A =9A =9A =9A =9A =9A =9A =9Ato.

=9A =9A =9A =9A =9A =9A =9A =9AHowever, it is impossible to specify bindin= g between all the possible
=9A =9A =9A =9A =9A =9A =9A =9Atokens and the semantics of "about&quo= t; URIs that would contain such
=9A =9A =9A =9A =9A =9A =9A =9Atokens, which this document does not attemp= t to do. =9ATherefore, any
=9A =9A =9A =9A =9A =9A =9A =9Aapplication resolving an "about" = URI MAY choose the resource it is
=9A =9A =9A =9A =9A =9A =9A =9Aresolved to at its own discretion, with the= exception of those
=9A =9A =9A =9A =9A =9A =9A =9Adefined below as 'special-purpose "= ;about" URIs'. =9AThey MAY use
=9A =9A =9A =9A =9A =9A =9A =9Ainternal redirection to accomplish this (fo= r instance, Opera
=9A =9A =9A =9A =9A =9A =9A =9Aredirects all "about" URIs except= "about:blank" to its internal
=9A =9A =9A =9A =9A =9A =9A =9A"opera" URIs).

=9A =9A =9A =9ANEW

=9A =9A =9A =9A =9A =9A =9A =9AGenerally speaking, the resource to which a= particular "about" URI resolves
=9A =9A =9A =9A =9A =9A =9A =9Ais denoted by <about-token> part of t= he URI, and <about-query>
=9A =9A =9A =9A =9A =9A =9A =9Aspecifies additional information concerning= its handling and/or the
=9A =9A =9A =9A =9A =9A =9A =9Ainformation that should be returned in the = resource to which the URI
=9A =9A =9A =9A =9A =9A =9A =9Aresolves.

=9A =9A =9A =9A =9A =9A =9A =9AHowever, it is impossible to specify a bind= ing between all the possible
=9A =9A =9A =9A =9A =9A =9A =9Atokens and the semantics of "about&quo= t; URIs that would contain such
=9A =9A =9A =9A =9A =9A =9A =9Atokens. =9ATherefore, the resource referenc= ed by the URI is
=9A =9A =9A =9A =9A =9A =9A =9Aapplication-specific, except for those list= ed below as 'special-purpose
=9A =9A =9A =9A =9A =9A =9A =9A"about" URIs'. =9AApplication= s MAY use internal redirection to accomplish
=9A =9A =9A =9A =9A =9A =9A =9Athis (for instance, the Opera web browser r= edirects all "about" URIs except
=9A =9A =9A =9A =9A =9A =9A =9A"about:blank" to its internal &qu= ot;opera" URIs).

Changed.
=9A

Section 2.2.1:

=9A =9A =9A =9AOLD

=9A =9A =9A =9A =9A =9A =9A =9AA small, though expandable, range of <ab= out-token>s are reserved for
=9A =9A =9A =9A =9A =9A =9A =9Aspecial purposes ("special-purpose tok= ens").

=9A =9A =9A =9ANEW

=9A =9A =9A =9A =9A =9A =9A =9AA small, though extensible, range of <ab= out-token>s is reserved for
=9A =9A =9A =9A =9A =9A =9A =9ASpecial purposes ("special-purpose tok= ens").

=9A =9A =9A =9AOLD

=9A =9A =9A =9A =9A =9A =9A =9AAdditional special-purpose tokens can be de= fined by registering an
=9A =9A =9A =9A =9A =9A =9A =9Aregistry created in Section 4.2. Special-pu= rpose "about" URIs are
=9A =9A =9A =9A =9A =9A =9A =9Aintended to be uncommon, and new ones shoul= d be defined only when
=9A =9A =9A =9A =9A =9A =9A =9Athere is a need to strongly connect a parti= cular <about-token> with a
=9A =9A =9A =9A =9A =9A =9A =9Aparticular function in all applications.
=9A =9A =9A =9ANEW

=9A =9A =9A =9A =9A =9A =9A =9AAdditional special-purpose tokens can be de= fined by updating the
=9A =9A =9A =9A =9A =9A =9A =9Aregistry created in Section 4.2. Special-pu= rpose "about" URIs are
=9A =9A =9A =9A =9A =9A =9A =9Aintended to be uncommon, and new ones only = need to be defined when
=9A =9A =9A =9A =9A =9A =9A =9Athere is a need to strongly connect a parti= cular <about-token> with a
=9A =9A =9A =9A =9A =9A =9A =9Aparticular function in all applications.

Taken into account.
=9A

Section 3:

=9A =9A =9A =9AOLD

=9A =9A =9A =9A =9A =9A =9A =9AGeneric security considerations for URIs ar= e discussed in Section 7
=9A =9A =9A =9A =9A =9A =9A =9Aof RFC 3986 [RFC3986]. =9AHowever, many of = those provisions hardly
=9A =9A =9A =9A =9A =9A =9A =9Aapply to "about" URI scheme, as t= hey are mainly scoped to schemes
=9A =9A =9A =9A =9A =9A =9A =9Aused in the Internet, not internally.

=9A =9A =9A =9A =9A =9A =9A =9A"about" URIs may sometimes refer = to a sensitive information, such as
=9A =9A =9A =9A =9A =9A =9A =9Auser passwords stored in a cache, or parame= ter that, if changed, may
=9A =9A =9A =9A =9A =9A =9A =9Aaffect user's data. =9AThe application = should therefore ensure that
=9A =9A =9A =9A =9A =9A =9A =9Auser's data is in the safety, and no th= reats are imposed by "about"
=9A =9A =9A =9A =9A =9A =9A =9AURIs.

=9A =9A =9A =9ANEW

=9A =9A =9A =9A =9A =9A =9A =9AGeneric security considerations for URIs ar= e discussed in Section 7
=9A =9A =9A =9A =9A =9A =9A =9Aof RFC 3986 [RFC3986]. =9AHowever, few of t= hose provisions
=9A =9A =9A =9A =9A =9A =9A =9Aapply to the "about" URI scheme, = as they are mainly scoped to schemes
=9A =9A =9A =9A =9A =9A =9A =9Aused in the Internet, not internally.

=9A =9A =9A =9A =9A =9A =9A =9A"about" URIs can sometimes refer = to a sensitive information, such as
=9A =9A =9A =9A =9A =9A =9A =9Auser passwords stored in a cache, or parame= ters that, if changed, could
=9A =9A =9A =9A =9A =9A =9A =9Aaffect user's data. =9AThe application = therefore needs to ensure that
=9A =9A =9A =9A =9A =9A =9A =9Athe user's data is secured, and no thre= ats are imposed by "about"
=9A =9A =9A =9A =9A =9A =9A =9AURIs.

Section 4.2:

=9A =9A =9A =9AOLD

=9A =9A =9A =9A =9A =9A =9A =9Ao Intended usage: =9AA short description of= how "about" URIs with the
=9A =9A =9A =9A =9A =9A =9A =9A =9Aregistered token must be handled; espec= ially, what they must be
=9A =9A =9A =9A =9A =9A =9A =9A =9Aresolved to, if resolvable.

=9A =9A =9A =9A =9A =9A =9A =9Ao Handling query component: =9AIt should be= mentioned whether there are
=9A =9A =9A =9A =9A =9A =9A =9A =9Asome provisions on handling query compo= nents in the "about" URIs
=9A =9A =9A =9A =9A =9A =9A =9A =9Awith the registered token.

=9A =9A =9A =9A =9A =9A =9A =9Ao Contact/Change controller: =9AAn individu= al or an organization which
=9A =9A =9A =9A =9A =9A =9A =9A =9A(1) should be contacted for more detail= s, and (2) is authorized to
=9A =9A =9A =9A =9A =9A =9A =9A =9Achange the registration.

=9A =9A =9A =9A =9A =9A =9A =9Ao Specification. =9AThis provides documenta= tion at a level that could
=9A =9A =9A =9A =9A =9A =9A =9A =9Abe used to create a compliant, interope= rable implementation of the
=9A =9A =9A =9A =9A =9A =9A =9A =9Aregistered "about" URI. =9ATh= e reference to a full specification MUST
=9A =9A =9A =9A =9A =9A =9A =9A =9Abe provided here, and there should be a= reasonable expectation that
=9A =9A =9A =9A =9A =9A =9A =9A =9Athe documentation will remain available= . =9AIANA will consult with
=9A =9A =9A =9A =9A =9A =9A =9A =9Athe IESG or its specified delegate if t= here is doubt about whether
=9A =9A =9A =9A =9A =9A =9A =9A =9Athe specification is adequate for the p= urpose.

=9A =9A =9A =9A =9A =9A =9A =9AThe following is a template for "blank= " token:

=9A =9A =9A =9ANEW
=9A =9A =9A =9A =9A =9A =9A =9Ao Intended usage: =9AA short description of= how "about" URIs with the
=9A =9A =9A =9A =9A =9A =9A =9A =9Aregistered token must be handled; espec= ially, to what resource
=9A =9A =9A =9A =9A =9A =9A =9A =9Athey are to resolve.

=9A =9A =9A =9A =9A =9A =9A =9Ao Handling query component: =9ADescribe any= requirements for handling
=9A =9A =9A =9A =9A =9A =9A =9Aquery components in "about" URIs = that contain the registered
=9A =9A =9A =9A =9A =9A =9A =9A =9Atoken.

=9A =9A =9A =9A =9A =9A =9A =9Ao Contact/Change controller: =9AAn individu= al or an organization that
=9A =9A =9A =9A =9A =9A =9A =9A =9A(1) should be contacted for more detail= s, and (2) is authorized to
=9A =9A =9A =9A =9A =9A =9A =9A =9Achange the registration.

=9A =9A =9A =9A =9A =9A =9A =9Ao Specification. =9AA permanent reference t= o a specification that can
=9A =9A =9A =9A =9A =9A =9A =9A =9Abe used to create a compliant, interope= rable implementation of the
=9A =9A =9A =9A =9A =9A =9A =9A =9Aregistered "about" URI. =9AIA= NA will consult with
=9A =9A =9A =9A =9A =9A =9A =9A =9Athe IESG or its specified delegate if t= here is doubt about whether
=9A =9A =9A =9A =9A =9A =9A =9A =9Athe specification is adequate for this = purpose.

=9A =9A =9A =9A =9A =9A =9A =9AThe following is a template for the "b= lank" token:

Accepted.

Thanks you for = your assistance.

Mykyta Yevstifeyev
=9A

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

--e89a8f64697f77d8c004bbc0b002-- From evnikita2@gmail.com Wed Mar 21 06:26:18 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E12AC21F85B5 for ; Wed, 21 Mar 2012 06:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.323 X-Spam-Level: X-Spam-Status: No, score=-2.323 tagged_above=-999 required=5 tests=[AWL=-1.175, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D8LG5hdD+aBv for ; Wed, 21 Mar 2012 06:26:18 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id EF96321F85A3 for ; Wed, 21 Mar 2012 06:26:17 -0700 (PDT) Received: by yhkk25 with SMTP id k25so982870yhk.31 for ; Wed, 21 Mar 2012 06:26:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=q9fpuCCnGEUY8DgRmvj9PaBmrTcCuSxABtRbiOpHI4g=; b=eYrc/oURx4WNVh4qJWSvzda13wXKCmprq/AmCqowg84CX2VNXJ5zefgjV0x+WY+3EZ TwLesKKiLVfNcioO3vmjgJKht+BUCwN7M4o9+dRO/3hjQ/h26tCEdBpvPp1TLnTMmZkf 96ViskJksT8lazZYnRW21r8EY/6HXxgSEHLzAILpnUnkyD0gMyecXAClmYyqKROjz1us egNQTxPlUWGOR5ZaOu5dAI6eotuP6jzPqauFyxAbthKgmNrabzVQ5Q1VVNkaddlYUpYH i6rqRciYdTTxMwzNlCUgNUnkxHoVr8GdN2DT+dHX6nxYC7seCDLh3f6UkdLDRXCSqytr rdEw== MIME-Version: 1.0 Received: by 10.182.227.37 with SMTP id rx5mr4600864obc.53.1332336377455; Wed, 21 Mar 2012 06:26:17 -0700 (PDT) Received: by 10.182.60.1 with HTTP; Wed, 21 Mar 2012 06:26:17 -0700 (PDT) In-Reply-To: <9452079D1A51524AA5749AD23E003928095184@exch-mbx901.corp.cloudmark.com> References: <503575970.11554@cnnic.cn> <4A10020DB6464A0BBA535BF75D21A9D9@LENOVO47E041CF> <9452079D1A51524AA5749AD23E003928094CEB@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E003928095184@exch-mbx901.corp.cloudmark.com> Date: Wed, 21 Mar 2012 15:26:17 +0200 Message-ID: From: Mykyta Yevstifeyev To: "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=f46d0444737d7fe28d04bbc0bc90 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] WGLC: draft-ietf-appsawg-about-uri-scheme-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 21 Mar 2012 13:26:19 -0000 --f46d0444737d7fe28d04bbc0bc90 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable 21 =CD=C1=D2=D4=C1 2012 =C7. 9:45 =D0=CF=CC=D8=DA=CF=D7=C1=D4=C5=CC=D8 Murr= ay S. Kucherawy =CE=C1=D0=C9=D3=C1=CC: > > -----Original Message----- > > From: barryleiba.mailing.lists@gmail.com [mailto: > barryleiba.mailing.lists@gmail.com] On Behalf Of Barry Leiba > > Sent: Tuesday, March 20, 2012 7:35 PM > > To: Murray S. Kucherawy > > Cc: apps-discuss@ietf.org > > Subject: Re: [apps-discuss] WGLC: > draft-ietf-appsawg-about-uri-scheme-03.txt > > > > > [Relatively] Minor Issues: > > > I'm not so sure about use of RFC2119 language in the IANA > > > Considerations section. You're not really describing > > > interoperability requirements with IANA. > > > > I'm sure. And it's my text -- this is one that Mykyta doesn't like. > > The three MUSTs in there are not directed at IANA, but at people > > writing new registrations. They tell those people what their > > registrations have to look like, and I wanted to use MUST to stress > > that even though this is an FCFS policy, there are requirements > > nonetheless. > > I think my point is that the IANA Considerations section spells out the > rules for a new registry when the registry is created, especially when > conformant with RFC5226. Everything in such a section is essentially a > MUST, because you're either filling out or defining a template and the > registry's initial entries. I can't imagine a "This field SHOULD/MAY > contain..." anywhere in an IANA Considerations section, except maybe > optional fields, but they're typically labeled as such in the first place= . > > In the case of this draft, the second MUST in particular seems > unnecessary. If the first one were changed to "has to" or similar, I hav= e > some doubts that IANA would start slipping in invalid tokens. And for th= e > third one, they're already pretty good at preferring (or even requiring?) > permanent document links without this document having to say so. > > I don't feel particularly strongly about this. It just seems unnecessary= . > I see we've agreed on dropping 2119 language here. I'll change this to non-normaitve equivalents. > > > > [Absolutely] Nits: > > > All of these are either reductions of overly-wordy text or fixes to > > minor grammar nits, or both. > > ... > > > OLD > > > The concept of "about" URIs has been formed at the > > > times when the > > > applications did not have the "friendly" user > > > interface, in order to > > > provide an access to the aforementioned resources via > > > typing the URIs > > ... > > > NEW > > > The concept of "about" URIs formed when applications > > > did not have a > > > "friendly" user interface, to enable access to the > > > aforementioned > > > resources by typing URIs into an address bar or > > similar feature. > > ... > > > > Yeah, good luck with that. I tried to convince Mykyta to tone the > > rhetoric down in there, and he declined... and I didn't see it as > > important enough to fight about. > > Well, parts of it are grammatically incorrect and the RFC Editor will hav= e > to fix them anyway, but a lot of my nits attempted to simplify needlessly > wordy or overly formal paragraphs. I hope the authors will give them a > second look. > Again thanks to Murray for these nits. Mykyta Yevstifeyev > > -MSK > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --f46d0444737d7fe28d04bbc0bc90 Content-Type: text/html; charset=KOI8-R Content-Transfer-Encoding: quoted-printable
21 =CD=C1=D2=D4=C1 2012=9A=C7. 9:45 =D0=CF=CC=D8= =DA=CF=D7=C1=D4=C5=CC=D8 Murray S. Kucherawy <msk@cloudmark.com> =CE=C1=D0=C9= =D3=C1=CC:
> -----Original Message-----
> From: barryleiba= .mailing.lists@gmail.com [mailto:barryleiba.mailing.lists@gmail.com] On Behalf Of Barry = Leiba
> Sent: Tuesday, March 20, 2012 7:35 PM
> To: Murray S. Kucherawy
> Cc: apps-discuss@ietf.org=
> Subject: Re: [apps-discuss] WGLC: draft-ietf-appsawg-about-uri-scheme-= 03.txt
>
> > [Relatively] Minor Issues:
> > I'm not so sure about use of RFC2119 language in the IANA
> > Considerations section. =9AYou're not really describing
> > interoperability requirements with IANA.
>
> I'm sure. =9AAnd it's my text -- this is one that Mykyta doesn= 't like.
> The three MUSTs in there are not directed at IANA, but at people
> writing new registrations. =9AThey tell those people what their
> registrations have to look like, and I wanted to use MUST to stress > that even though this is an FCFS policy, there are requirements
> nonetheless.

I think my point is that the IANA Considerations section spells out the rul= es for a new registry when the registry is created, especially when conform= ant with RFC5226. =9AEverything in such a section is essentially a MUST, be= cause you're either filling out or defining a template and the registry= 's initial entries. =9AI can't imagine a "This field SHOULD/MA= Y contain..." anywhere in an IANA Considerations section, except maybe= optional fields, but they're typically labeled as such in the first pl= ace.

In the case of this draft, the second MUST in particular seems unnecessary.= =9AIf the first one were changed to "has to" or similar, I have = some doubts that IANA would start slipping in invalid tokens. =9AAnd for th= e third one, they're already pretty good at preferring (or even requiri= ng?) permanent document links without this document having to say so.

I don't feel particularly strongly about this. =9AIt just seems unneces= sary.

I see we've agreed on dropping 2119 lang= uage here.=9A I'll change this to non-normaitve equivalents.
=9A

> > [Absolutely] Nits:
> > All of these are either reductions of overly-wordy text or fixes = to
> minor grammar nits, or both.
> ...
> > =9A =9A =9A =9AOLD
> > =9A =9A =9A =9A =9A =9A =9A =9AThe concept of "about" U= RIs has been formed at the
> > times when the
> > =9A =9A =9A =9A =9A =9A =9A =9Aapplications did not have the &quo= t;friendly" user
> > interface, in order to
> > =9A =9A =9A =9A =9A =9A =9A =9Aprovide an access to the aforement= ioned resources via
> > typing the URIs
> ...
> > =9A =9A =9A =9ANEW
> > =9A =9A =9A =9A =9A =9A =9A =9AThe concept of "about" U= RIs formed when applications
> > did not have a
> > =9A =9A =9A =9A =9A =9A =9A =9A"friendly" user interfac= e, to enable access to the
> > aforementioned
> > =9A =9A =9A =9A =9A =9A =9A =9Aresources by typing URIs into an a= ddress bar or
> similar feature.
> ...
>
> Yeah, good luck with that. =9AI tried to convince Mykyta to tone the > rhetoric down in there, and he declined... and I didn't see it as<= br> > important enough to fight about.

Well, parts of it are grammatically incorrect and the RFC Editor will have = to fix them anyway, but a lot of my nits attempted to simplify needlessly w= ordy or overly formal paragraphs. =9AI hope the authors will give them a se= cond look.

Again thanks to Murray for these nits.

Mykyta = Yevstifeyev
=9A

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

--f46d0444737d7fe28d04bbc0bc90-- From barryleiba.mailing.lists@gmail.com Wed Mar 21 07:19:34 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9CCC21F8705 for ; Wed, 21 Mar 2012 07:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.99 X-Spam-Level: X-Spam-Status: No, score=-102.99 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3HwSptPtnpwS for ; Wed, 21 Mar 2012 07:19:34 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1FDB321F8704 for ; Wed, 21 Mar 2012 07:19:34 -0700 (PDT) Received: by yhkk25 with SMTP id k25so1048629yhk.31 for ; Wed, 21 Mar 2012 07:19:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=fsddbWHkeHh/cSdsNkmDQBSEMkrZtQRTMbKXnoVD16I=; b=pKK9H/VpJGpPDfVB94DaCq0muASsIw7FmzB1znQ/9WTQzAgCuL3ChP7YNewJxXJNHB Ng+qSTAeB0GSDRbk8cqZ/DTqc8zEPtJzUJTJyELAeqlVgSxhTk8JCSBTEOWEEa7TyqRg F8KoxH7At1/pF0lURf0UVskTuHuDQLg9zEOWKvHabLQpE/yr0v1ENbL/SgdZ+oDbsEt8 +C+LQgg+7JdF1TPj9LxOp2CXFgq6s6ZD92cSuaeRj0VkipRtzhyETHf47r0S7teq8wxW 6QFsY0z1mTw1j7v2zx3ylcfc0srdQxmeudCRc7+Gytfdm6FTI/qrqmAc1zKpaYyjoN0d ddPA== MIME-Version: 1.0 Received: by 10.101.179.28 with SMTP id g28mr1215782anp.61.1332339573721; Wed, 21 Mar 2012 07:19:33 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.146.230.1 with HTTP; Wed, 21 Mar 2012 07:19:33 -0700 (PDT) In-Reply-To: <4F6978D8.10605@gmx.de> References: <503575970.11554@cnnic.cn> <4A10020DB6464A0BBA535BF75D21A9D9@LENOVO47E041CF> <9452079D1A51524AA5749AD23E003928094CEB@exch-mbx901.corp.cloudmark.com> <4F6978D8.10605@gmx.de> Date: Wed, 21 Mar 2012 10:19:33 -0400 X-Google-Sender-Auth: ZJbgSa2Fp6lH3uj70Kr10ifs5Pk Message-ID: From: Barry Leiba To: Mykyta Yevstifeyev Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Use of RFC 2119, Re: WGLC: draft-ietf-appsawg-about-uri-scheme-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 21 Mar 2012 14:19:34 -0000 I said... >> I'm sure. =A0And it's my text -- this is one that Mykyta doesn't like. >> The three MUSTs in there are not directed at IANA, but at people >> writing new registrations. =A0They tell those people what their >> registrations have to look like, and I wanted to use MUST to stress >> that even though this is an FCFS policy, there are requirements >> nonetheless. Julian says... > I'm with Murray here. This is something RFC 2119 keywords are not for. OK... and given the conversations that Pete and I have had recently (we're both in favour of less unnecessary all-caps 2119 stuff), I think a change is appropriate. Let's lower-case (or remove) those three "MUST"s (and there are three others that are already in lower case, which is fine). Section 4.2: OLD The registry entries consist of 3 fields: Special-Purpose Token, Description and Reference. The Special-Purpose Token field MUST conform to production defined in Section 2.1. NEW The registry entries consist of 3 fields: Special-Purpose Token, Description and Reference. The Special-Purpose Token field conforms to the production defined in Section 2.1. OLD The registration procedures for this registry are "First Come First Served", described in RFC 5226 [RFC5226], with supporting documentation meeting the requirements below. The registrant of the token MUST provide the following registration template, which will be made available on IANA web site: NEW The registration procedures for this registry are "First Come First Served", described in RFC 5226 [RFC5226], with supporting documentation meeting the requirements below. The registrant of the token must provide the following registration template, which will be made available on IANA web site: OLD o Specification. This provides documentation at a level that could be used to create a compliant, interoperable implementation of the registered "about" URI. The reference to a full specification MUST be provided here, and there should be a reasonable expectation that the documentation will remain available. NEW o Specification. This provides documentation at a level that could be used to create a compliant, interoperable implementation of the registered "about" URI. The reference to a full specification must be provided here, and there should be a reasonable expectation that the documentation will remain available. Mykyta, please note those changes, address Murray's other comments, and push out a new rev of the draft (email TXT and XML to internet-drafts@ietf.org and CC appsawg-ads@tools.ietf.org to get permission). Barry From julian.reschke@gmx.de Wed Mar 21 07:26:00 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B39E21F8576 for ; Wed, 21 Mar 2012 07:26:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.294 X-Spam-Level: X-Spam-Status: No, score=-104.294 tagged_above=-999 required=5 tests=[AWL=-1.695, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qRnPIB7y+l-2 for ; Wed, 21 Mar 2012 07:25:59 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 6066821F858F for ; Wed, 21 Mar 2012 07:25:59 -0700 (PDT) Received: (qmail invoked by alias); 21 Mar 2012 14:25:58 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp037) with SMTP; 21 Mar 2012 15:25:58 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18lydYBzbElXQRF7nwy8Be2FnAGm7h/teWp4NnD+q plH0Q27aeRHjQC Message-ID: <4F69E4E5.2060504@gmx.de> Date: Wed, 21 Mar 2012 15:25:41 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Barry Leiba References: <503575970.11554@cnnic.cn> <4A10020DB6464A0BBA535BF75D21A9D9@LENOVO47E041CF> <9452079D1A51524AA5749AD23E003928094CEB@exch-mbx901.corp.cloudmark.com> <4F6978D8.10605@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Use of RFC 2119, Re: WGLC: draft-ietf-appsawg-about-uri-scheme-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 21 Mar 2012 14:26:00 -0000 On 2012-03-21 15:19, Barry Leiba wrote: > I said... >>> I'm sure. And it's my text -- this is one that Mykyta doesn't like. >>> The three MUSTs in there are not directed at IANA, but at people >>> writing new registrations. They tell those people what their >>> registrations have to look like, and I wanted to use MUST to stress >>> that even though this is an FCFS policy, there are requirements >>> nonetheless. > > Julian says... >> I'm with Murray here. This is something RFC 2119 keywords are not for. > > OK... and given the conversations that Pete and I have had recently > (we're both in favour of less unnecessary all-caps 2119 stuff), I > think a change is appropriate. Let's lower-case (or remove) those > three "MUST"s (and there are three others that are already in lower > case, which is fine). > ... +1, except that I would replace "must" by "needs to" (otherwise somebody else will point out that RFC2119 doesn't require the keywords to be in uppercase). Best regards, Julian From macar@cloudmark.com Wed Mar 21 10:01:58 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B69621F85AF for ; Wed, 21 Mar 2012 10:01:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id be54hihRef1T for ; Wed, 21 Mar 2012 10:01:57 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id D847121F856C for ; Wed, 21 Mar 2012 10:01:57 -0700 (PDT) Received: from [172.20.2.21] (172.20.2.21) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 21 Mar 2012 10:01:56 -0700 Message-ID: <4F6A0985.8030208@cloudmark.com> Date: Wed, 21 Mar 2012 10:01:57 -0700 From: Mike Acar User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Julian Reschke References: <9F0A2492-AE7D-4C12-8BB0-13489FD7F6C1@gmail.com> <1331271383.6504.1.camel@neutron> <4F5E6255.9040402@cloudmark.com> <1331651889.3301.5.camel@neutron> <4F6914D7.5050505@cloudmark.com> <4F697867.2050500@gmx.de> In-Reply-To: <4F697867.2050500@gmx.de> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.20.2.21] Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-pbryan-json-patch-04 - comments X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 21 Mar 2012 17:01:58 -0000 On 03/20/2012 11:42 PM, Julian Reschke wrote: > What makes you think it's optional? I don't see anything in the spec that requires a test operation in a patch. So this conforms: [ { "add": "/a/b/c", "value": [ "foo", "bar" ] }, { "remove": "/foo/bar/baz" } ] Similarly, this conforms: [ { "add": "/a/b/c", "value": [ "foo", "bar" ] }, { "test": "/a/b/c", "value": [ "foo", "bar" ] } ] Whether those patch docs make any sense is a question of a particular use case. -- Mike Acar - - macar at cloudmark dot com From spencer@wonderhamster.org Wed Mar 21 10:05:22 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3BF121F85A4; Wed, 21 Mar 2012 10:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.932 X-Spam-Level: X-Spam-Status: No, score=-102.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzd0-eBg2F1n; Wed, 21 Mar 2012 10:05:22 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 1285A21F84F7; Wed, 21 Mar 2012 10:05:22 -0700 (PDT) Received: from [192.168.2.9] (cpe-76-182-255-76.tx.res.rr.com [76.182.255.76]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0MGis5-1S6KVm1sxN-00EE8B; Wed, 21 Mar 2012 13:05:21 -0400 Message-ID: <4F6A0A41.3050006@wonderhamster.org> Date: Wed, 21 Mar 2012 12:05:05 -0500 From: Spencer Dawkins User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: apps-discuss@ietf.org, opsawg@ietf.org, tsvwg@ietf.org, cdni@ietf.org, dc@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:37kwmDyh1PGtEv1+GuK5JGGumWHU/GEI1BmdmoUug8c hWnMw72RwkhAxsiU6NG7N79qlJQ2XV6Z5awI9Cd48xzXeg5xFU 776j0JR0CGgz/Me5v58EWM1FwIxl3WeJpt1rC5lVJTGIRDApNj Y5EGXhxNayCTqYWx4P27UPyH5xJ2sNZ6axI84XY2/21DUaEibd X2jyXDdNbpDdekwqfzSMsiWaa0wMb7Wy87HIiScZG9r+c85VYG tfT5MBRwtPWjQlRfl1m4rnht0aaWMtrR59lQpOw2/QpT5+wlQu epn5Vg7T+8MSL4TRS9TDCWCg16mEyA/Z8zH6ksI23CL/SnqZNv P5TKeqNw8EBjZjP2pah70i10iOL6ag912CaluRy5Y Subject: [apps-discuss] Announcing the i2aex BoF X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 21 Mar 2012 17:05:23 -0000 Hi all, David Harrington asked me to act as BoF Shepherd for the Infrastructure-to-application Information Exposure (i2aex) BoF, and I wanted to make sure that a broad community of interest was aware of this BoF, especially since the BoF is scheduled for Monday, Afternoon Session 1, at 1300 PM. Preliminary discussion has been going on for some time now on the altoext@ietf.org mailing list, mainly among people in some way involved in the standardization the ALTO protocol. In order to have a conversation that's as productive as possible in Paris, we would really like to invite people who are involved on different sides of the same problem to bring their perspective as well. Here's a short description, with the usual pointers. Follow-ups to altoext@ietf.org, please. The goal of the (non-WG-forming) BoF is to investigate infrastructure- to-application information exposure and communications requirements in fully controlled (e.g., data centers) or partially controlled environments (e.g. CDN). Existing mechanisms such as SNMP, IGP, BGP and other protocols that monitor and manage infrastructure may reveal much if not all of the possibly required information, but are typically only accessible to the operators of the network infrastructure. CDNs and data center applications have some requirements to operate over the Internet, possibly between administrative domains. On the other hand, the ALTO protocol was initially designed to address peer-to-peer application requirements, but was designed to be extensible and could be quite easily adapted to export the pieces of information that CDN and data center applications would benefit from. The BoF will thus primarily seek an answer to the following questions: + do CDN and data center applications require (or benefit in a significant way from) accessing to information that cannot be made available through existing mechanisms in a practical way? + is an extension to the ALTO protocol (or to any other protocol) a viable way to address such requirements? Additional information about the topic is available on the BoF wiki entry: http://trac.tools.ietf.org/bof/trac/#Transport The provisional agenda for the meeting is online at: http://www.ietf.org/proceedings/83/agenda/agenda-83-i2aex.txt From julian.reschke@gmx.de Wed Mar 21 10:06:52 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C48421F85EA for ; Wed, 21 Mar 2012 10:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.47 X-Spam-Level: X-Spam-Status: No, score=-103.47 tagged_above=-999 required=5 tests=[AWL=-0.871, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fAb+ksIwN5Om for ; Wed, 21 Mar 2012 10:06:51 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 4505B21F85E5 for ; Wed, 21 Mar 2012 10:06:51 -0700 (PDT) Received: (qmail invoked by alias); 21 Mar 2012 17:06:50 -0000 Received: from p57A6E199.dip.t-dialin.net (EHLO [192.168.178.36]) [87.166.225.153] by mail.gmx.net (mp032) with SMTP; 21 Mar 2012 18:06:50 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/UYSEOEYrU4Ybt8O7s01xlz5hgQ6xKBcXDGqw3tb dcNKVp2uvoNFb4 Message-ID: <4F6A0AA8.70106@gmx.de> Date: Wed, 21 Mar 2012 18:06:48 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Mike Acar References: <9F0A2492-AE7D-4C12-8BB0-13489FD7F6C1@gmail.com> <1331271383.6504.1.camel@neutron> <4F5E6255.9040402@cloudmark.com> <1331651889.3301.5.camel@neutron> <4F6914D7.5050505@cloudmark.com> <4F697867.2050500@gmx.de> <4F6A0985.8030208@cloudmark.com> In-Reply-To: <4F6A0985.8030208@cloudmark.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-pbryan-json-patch-04 - comments X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 21 Mar 2012 17:06:52 -0000 On 2012-03-21 18:01, Mike Acar wrote: > On 03/20/2012 11:42 PM, Julian Reschke wrote: > >> What makes you think it's optional? > > I don't see anything in the spec that requires a test operation in a > patch. So this conforms: > > [ > { "add": "/a/b/c", "value": [ "foo", "bar" ] }, > { "remove": "/foo/bar/baz" } > ] > > Similarly, this conforms: > > [ > { "add": "/a/b/c", "value": [ "foo", "bar" ] }, > { "test": "/a/b/c", "value": [ "foo", "bar" ] } > ] > > Whether those patch docs make any sense is a question of a particular > use case. 4.6. test The "test" operation tests that a value at the specified location in the target document is equal to a specified value. The operation object contains a "value" member, which specifies the value to test for. If values are or contain objects or arrays, they must be identical (i.e. same order of elements, with the same values). Example: { "test": "/a/b/c", "value": "foo" } It is an error condition if the value at the specified location is not equal to the specified value. Note the last paragraph. Best regards, Julian From macar@cloudmark.com Wed Mar 21 10:43:41 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22AB621E8040 for ; Wed, 21 Mar 2012 10:43:41 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T6w9I9TrXjIl for ; Wed, 21 Mar 2012 10:43:40 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id BC46021E8026 for ; Wed, 21 Mar 2012 10:43:40 -0700 (PDT) Received: from [172.20.2.21] (172.20.2.21) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 21 Mar 2012 10:43:40 -0700 Message-ID: <4F6A134C.5060906@cloudmark.com> Date: Wed, 21 Mar 2012 10:43:40 -0700 From: Mike Acar User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Julian Reschke References: <9F0A2492-AE7D-4C12-8BB0-13489FD7F6C1@gmail.com> <1331271383.6504.1.camel@neutron> <4F5E6255.9040402@cloudmark.com> <1331651889.3301.5.camel@neutron> <4F6914D7.5050505@cloudmark.com> <4F697867.2050500@gmx.de> <4F6A0985.8030208@cloudmark.com> <4F6A0AA8.70106@gmx.de> In-Reply-To: <4F6A0AA8.70106@gmx.de> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.20.2.21] Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-pbryan-json-patch-04 - comments X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 21 Mar 2012 17:43:41 -0000 On 03/21/2012 10:06 AM, Julian Reschke wrote: > On 2012-03-21 18:01, Mike Acar wrote: >> On 03/20/2012 11:42 PM, Julian Reschke wrote: >> >>> What makes you think it's optional? >> >> I don't see anything in the spec that requires a test operation in a >> patch. > 4.6. test > It is an error condition if the value at the specified location is > not equal to the specified value. > > Note the last paragraph. No, I don't mean that whether a test passes is optional, I mean that a document isn't required to have any "test" operations. This is not like how text-based diff/patches work; in Patch syntax, those would look like [ { "test":"/a/b/c", "value":"oldval" }, { "replace":"/a/b/c", "value":"newval" }, { "test":"/foo/bar/baz", "value":"quux" }, { "replace":"/foo/bar/baz", "value":"xyzzy" }, ... ] Anyway, let me read the rest of the archived Google Groups discussion before I comment further. -- Mike Acar - - macar at cloudmark dot com From vumip1@gmail.com Wed Mar 21 10:50:32 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C90421E808C; Wed, 21 Mar 2012 10:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.492 X-Spam-Level: X-Spam-Status: No, score=-2.492 tagged_above=-999 required=5 tests=[AWL=-0.560, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wd0wZ7JN4zPv; Wed, 21 Mar 2012 10:50:31 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 381DB21E8040; Wed, 21 Mar 2012 10:50:31 -0700 (PDT) Received: by yenm5 with SMTP id m5so1308124yen.31 for ; Wed, 21 Mar 2012 10:50:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zC0cm5QYiRjo5405z/iXCy1JqbVw+rHCtRUW70A0pPs=; b=NP27W+seIGqA/JW8UnZjgNF7vOZqgqPG14AV1VMOkwJNGyLAd/ZqB+4FqhiGkRyY4s aOIeEkHFf1l2GZq6iOhKxR1r8yAoLez+rpVVtfDSZU2D+uICDGnDRah5AlIwRx25Rjkd qwjgTH5llq7Ck5jbhHKg4xlNRpXG2yNAaWMdRnvj3vI5r5ESAZCqBxN5Ks6/VMmTo1yG 36BoxmMVlnNOeK/7oAgGV6uauoWZyYA/gfbTTq2u9lR6Uyizye0S1RLbZVedXLo+T+9G jRTYP8qX1ROLmY/r1jpHpIMkOi07DC0n3DvoRSvqoaYQhows1SrKqq/wY+0Jds0HQs1U JBhw== MIME-Version: 1.0 Received: by 10.182.54.114 with SMTP id i18mr5776882obp.49.1332352230691; Wed, 21 Mar 2012 10:50:30 -0700 (PDT) Received: by 10.182.12.234 with HTTP; Wed, 21 Mar 2012 10:50:30 -0700 (PDT) In-Reply-To: <4F6A0A41.3050006@wonderhamster.org> References: <4F6A0A41.3050006@wonderhamster.org> Date: Wed, 21 Mar 2012 13:50:30 -0400 Message-ID: From: Bhumip Khasnabish To: Spencer Dawkins Content-Type: multipart/alternative; boundary=14dae93a122f6d130b04bbc46d8a Cc: dc@ietf.org, opsawg@ietf.org, cdni@ietf.org, tsvwg@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] [dc] Announcing the i2aex BoF X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 21 Mar 2012 17:50:32 -0000 --14dae93a122f6d130b04bbc46d8a Content-Type: text/plain; charset=ISO-8859-1 Hi Spencer, Is this similar to Cloud Infrastructure Management Interface (CIMI) Model and REST Interface over HTTP An Interface for Managing Cloud Infrastructure( http://dmtf.org/standards/cloud)? What is the trigger for this?! Thanks for clarifying. Best. Bhumip On Wed, Mar 21, 2012 at 1:05 PM, Spencer Dawkins wrote: > Hi all, > > David Harrington asked me to act as BoF Shepherd for the > Infrastructure-to-application Information Exposure (i2aex) BoF, and I > wanted to make sure that a broad community of interest was aware of this > BoF, especially since the BoF is scheduled for Monday, Afternoon Session 1, > at 1300 PM. > > Preliminary discussion has been going on for some time now on the > altoext@ietf.org mailing list, mainly among people in some way involved > in the standardization the ALTO protocol. In order to have a conversation > that's as productive as possible in Paris, we would really like to invite > people who are involved on different sides of the same problem to bring > their perspective as well. > > Here's a short description, with the usual pointers. Follow-ups to > altoext@ietf.org, please. > > The goal of the (non-WG-forming) BoF is to investigate infrastructure- > to-application information exposure and communications requirements in > fully controlled (e.g., data centers) or partially controlled > environments (e.g. CDN). Existing mechanisms such as SNMP, IGP, BGP and > other protocols that monitor and manage infrastructure may reveal much > if not all of the possibly required information, but are typically only > accessible to the operators of the network infrastructure. CDNs and data > center applications have some requirements to operate over the Internet, > possibly between administrative domains. On the other hand, the ALTO > protocol was initially designed to address peer-to-peer application > requirements, but was designed to be extensible and could be quite > easily adapted to export the pieces of information that CDN and data > center applications would benefit from. > > The BoF will thus primarily seek an answer to the following questions: > > + do CDN and data center applications require (or benefit in a > significant way from) accessing to information that cannot be made > available through existing mechanisms in a practical way? > > + is an extension to the ALTO protocol (or to any other protocol) a > viable way to address such requirements? > > Additional information about the topic is available on the BoF wiki > entry: http://trac.tools.ietf.org/**bof/trac/#Transport > > The provisional agenda for the meeting is online at: > http://www.ietf.org/**proceedings/83/agenda/agenda-**83-i2aex.txt > ______________________________**_________________ > dc mailing list > dc@ietf.org > https://www.ietf.org/mailman/**listinfo/dc > --14dae93a122f6d130b04bbc46d8a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Spencer,
=A0
Is this similar to Cloud Infrastructure Management Interface (CIMI) Model and REST Interface= over HTTP An Interface for Managing Cloud In= frastructure (http://dmtf.org/standards/cloud)?
=A0
What is the trigger for this?!
=A0
Thanks for clarifying.
=A0
Best.
=A0
Bhumip
=A0

=A0



On Wed, Mar 21, 2012 at 1:05 PM, Spencer Dawkins= <spencer= @wonderhamster.org> wrote:
Hi all,

David Harrington asked= me to act as BoF Shepherd for the Infrastructure-to-application Informatio= n Exposure (i2aex) BoF, and I wanted to make sure that a broad community of= interest was aware of this BoF, especially since the BoF is scheduled for = Monday, Afternoon Session 1, at 1300 PM.

Preliminary discussion has been going on for some time now on the altoext@ietf.org maili= ng list, mainly among people in some way involved in the standardization th= e ALTO protocol. In order to have a conversation that's as productive a= s possible in Paris, we would really like to invite people who are involved= on different sides of the same problem to bring their perspective as well.=

Here's a short description, with the usual pointers. Follow-ups to = altoext@ietf.org,= please.

The goal of the (non-WG-forming) BoF is to investigate infr= astructure-
to-application information exposure and communications requirements in
f= ully controlled (e.g., data centers) or partially controlled
environment= s (e.g. CDN). Existing mechanisms such as SNMP, IGP, BGP and
other proto= cols that monitor and manage infrastructure may reveal much
if not all of the possibly required information, but are typically only
= accessible to the operators of the network infrastructure. CDNs and datacenter applications have some requirements to operate over the Internet, possibly between administrative domains. On the other hand, the ALTO
pro= tocol was initially designed to address peer-to-peer application
require= ments, but was designed to be extensible and could be quite
easily adapt= ed to export the pieces of information that CDN and data
center applications would benefit from.

The BoF will thus primarily = seek an answer to the following questions:

=A0+ do CDN and data cent= er applications require (or benefit in a
=A0 =A0significant way from) ac= cessing to information that cannot be made
=A0 =A0available through existing mechanisms in a practical way?

=A0= + is an extension to the ALTO protocol (or to any other protocol) a
=A0 = =A0viable way to address such requirements?

Additional information a= bout the topic is available on the BoF wiki
entry: http://trac.tools.ietf.org/bof/trac/#Transport

T= he provisional agenda for the meeting is online at:
htt= p://www.ietf.org/proceedings/83/agenda/agenda-83-i2aex.txt
_______________________________________________
dc mailing listdc@ietf.org
https://w= ww.ietf.org/mailman/listinfo/dc


=A0 --14dae93a122f6d130b04bbc46d8a-- From mduerig@apache.org Wed Mar 21 11:25:01 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A65A721F852D for ; Wed, 21 Mar 2012 11:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PYOAXkraZK+6 for ; Wed, 21 Mar 2012 11:25:01 -0700 (PDT) Received: from exprod6og112.obsmtp.com (exprod6og112.obsmtp.com [64.18.1.29]) by ietfa.amsl.com (Postfix) with ESMTP id 68AD321F847A for ; Wed, 21 Mar 2012 11:24:59 -0700 (PDT) Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob112.postini.com ([64.18.5.12]) with SMTP ID DSNKT2oc+2cxJ3UU3MyHivp2MuTc8qysy9A1@postini.com; Wed, 21 Mar 2012 11:25:00 PDT Received: from inner-relay-1.corp.adobe.com (ms-exchange.macromedia.com [153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id q2LIOvvq013810 for ; Wed, 21 Mar 2012 11:24:58 -0700 (PDT) Received: from nacas02.corp.adobe.com (nacas02.corp.adobe.com [10.8.189.100]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id q2LIOuMM000267 for ; Wed, 21 Mar 2012 11:24:56 -0700 (PDT) Received: from eurhub01.eur.adobe.com (10.128.4.30) by nacas02.corp.adobe.com (10.8.189.100) with Microsoft SMTP Server (TLS) id 8.3.192.1; Wed, 21 Mar 2012 11:24:56 -0700 Received: from susi.local (10.136.131.233) by eurhub01.eur.adobe.com (10.128.4.111) with Microsoft SMTP Server id 8.3.192.1; Wed, 21 Mar 2012 18:24:55 +0000 Message-ID: <4F6A1CF6.6060608@apache.org> Date: Wed, 21 Mar 2012 18:24:54 +0000 From: =?ISO-8859-1?Q?Michael_D=FCrig?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: References: <9F0A2492-AE7D-4C12-8BB0-13489FD7F6C1@gmail.com> <1331271383.6504.1.camel@neutron> <4F5E6255.9040402@cloudmark.com> <1331651889.3301.5.camel@neutron> <4F6914D7.5050505@cloudmark.com> <4F697867.2050500@gmx.de> <4F6A0985.8030208@cloudmark.com> <4F6A0AA8.70106@gmx.de> <4F6A134C.5060906@cloudmark.com> In-Reply-To: <4F6A134C.5060906@cloudmark.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] draft-pbryan-json-patch-04 - comments X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 21 Mar 2012 18:25:01 -0000 AFAIR the original intention for test wasn't to introduce conditional operations but rather to prevent some specific race conditions. Much like a "test and set" operation. Michael On 21.3.12 17:43, Mike Acar wrote: > On 03/21/2012 10:06 AM, Julian Reschke wrote: >> On 2012-03-21 18:01, Mike Acar wrote: >>> On 03/20/2012 11:42 PM, Julian Reschke wrote: >>> >>>> What makes you think it's optional? >>> >>> I don't see anything in the spec that requires a test operation in a >>> patch. > >> 4.6. test > >> It is an error condition if the value at the specified location is >> not equal to the specified value. >> >> Note the last paragraph. > > No, I don't mean that whether a test passes is optional, I mean that a > document isn't required to have any "test" operations. This is not like > how text-based diff/patches work; in Patch syntax, those would look like > > [ > { "test":"/a/b/c", "value":"oldval" }, > { "replace":"/a/b/c", "value":"newval" }, > { "test":"/foo/bar/baz", "value":"quux" }, > { "replace":"/foo/bar/baz", "value":"xyzzy" }, > ... > ] > > Anyway, let me read the rest of the archived Google Groups discussion > before I comment further. > From pbryan@anode.ca Wed Mar 21 11:30:57 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B932C21F84FF for ; Wed, 21 Mar 2012 11:30:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QfDVWQz9YLVy for ; Wed, 21 Mar 2012 11:30:57 -0700 (PDT) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id 1ECC121F85D6 for ; Wed, 21 Mar 2012 11:30:57 -0700 (PDT) Received: from [192.168.11.246] (unknown [209.52.95.5]) by maple.anode.ca (Postfix) with ESMTPSA id 818526456 for ; Wed, 21 Mar 2012 18:30:56 +0000 (UTC) Message-ID: <1332354655.2175.3.camel@neutron> From: "Paul C. Bryan" To: apps-discuss@ietf.org Date: Wed, 21 Mar 2012 11:30:55 -0700 In-Reply-To: <4F6A1CF6.6060608@apache.org> References: <9F0A2492-AE7D-4C12-8BB0-13489FD7F6C1@gmail.com> <1331271383.6504.1.camel@neutron> <4F5E6255.9040402@cloudmark.com> <1331651889.3301.5.camel@neutron> <4F6914D7.5050505@cloudmark.com> <4F697867.2050500@gmx.de> <4F6A0985.8030208@cloudmark.com> <4F6A0AA8.70106@gmx.de> <4F6A134C.5060906@cloudmark.com> <4F6A1CF6.6060608@apache.org> Content-Type: multipart/alternative; boundary="=-O5n0nkIyyk/LjherdMyr" X-Mailer: Evolution 3.2.2-1 Mime-Version: 1.0 Subject: Re: [apps-discuss] draft-pbryan-json-patch-04 - comments X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 21 Mar 2012 18:30:57 -0000 --=-O5n0nkIyyk/LjherdMyr Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit The intent of "test" was to ensure the partial state of a JSON resource before applying modification(s) to it. Essentially, it's a recognition that ETag (or equivalent entire-resource version) will be too coarse-grained in some use cases. So in that sense, it makes the entire patch document conditional on the tests being successfully applied; it's definitely not intended to have some operations in a patch document be applied and others not. Paul On Wed, 2012-03-21 at 18:24 +0000, Michael Dürig wrote: > AFAIR the original intention for test wasn't to introduce conditional > operations but rather to prevent some specific race conditions. Much > like a "test and set" operation. > > Michael > > On 21.3.12 17:43, Mike Acar wrote: > > On 03/21/2012 10:06 AM, Julian Reschke wrote: > >> On 2012-03-21 18:01, Mike Acar wrote: > >>> On 03/20/2012 11:42 PM, Julian Reschke wrote: > >>> > >>>> What makes you think it's optional? > >>> > >>> I don't see anything in the spec that requires a test operation in a > >>> patch. > > > >> 4.6. test > > > >> It is an error condition if the value at the specified location is > >> not equal to the specified value. > >> > >> Note the last paragraph. > > > > No, I don't mean that whether a test passes is optional, I mean that a > > document isn't required to have any "test" operations. This is not like > > how text-based diff/patches work; in Patch syntax, those would look like > > > > [ > > { "test":"/a/b/c", "value":"oldval" }, > > { "replace":"/a/b/c", "value":"newval" }, > > { "test":"/foo/bar/baz", "value":"quux" }, > > { "replace":"/foo/bar/baz", "value":"xyzzy" }, > > ... > > ] > > > > Anyway, let me read the rest of the archived Google Groups discussion > > before I comment further. > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --=-O5n0nkIyyk/LjherdMyr Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit The intent of "test" was to ensure the partial state of a JSON resource before applying modification(s) to it. Essentially, it's a recognition that ETag (or equivalent entire-resource version) will be too coarse-grained in some use cases. So in that sense, it makes the entire patch document conditional on the tests being successfully applied; it's definitely not intended to have some operations in a patch document be applied and others not.

Paul

On Wed, 2012-03-21 at 18:24 +0000, Michael Dürig wrote: 
AFAIR the original intention for test wasn't to introduce conditional 
operations but rather to prevent some specific race conditions. Much 
like a "test and set" operation.

Michael

On 21.3.12 17:43, Mike Acar wrote:
> On 03/21/2012 10:06 AM, Julian Reschke wrote:
>> On 2012-03-21 18:01, Mike Acar wrote:
>>> On 03/20/2012 11:42 PM, Julian Reschke wrote:
>>>
>>>> What makes you think it's optional?
>>>
>>> I don't see anything in the spec that requires a test operation in a
>>> patch.
>
>> 4.6. test
>
>> It is an error condition if the value at the specified location is
>> not equal to the specified value.
>>
>> Note the last paragraph.
>
> No, I don't mean that whether a test passes is optional, I mean that a
> document isn't required to have any "test" operations. This is not like
> how text-based diff/patches work; in Patch syntax, those would look like
>
> [
> { "test":"/a/b/c", "value":"oldval" },
> { "replace":"/a/b/c", "value":"newval" },
> { "test":"/foo/bar/baz", "value":"quux" },
> { "replace":"/foo/bar/baz", "value":"xyzzy" },
> ...
> ]
>
> Anyway, let me read the rest of the archived Google Groups discussion
> before I comment further.
>
_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--=-O5n0nkIyyk/LjherdMyr-- From timon.elviejo@gmail.com Wed Mar 21 11:33:57 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 629A221F8453 for ; Wed, 21 Mar 2012 11:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.704 X-Spam-Level: X-Spam-Status: No, score=-0.704 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_FWDLOOK=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PuI1nCZX-FZi for ; Wed, 21 Mar 2012 11:33:56 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id BAE8821F8446 for ; Wed, 21 Mar 2012 11:33:56 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so1575487vcb.31 for ; Wed, 21 Mar 2012 11:33:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=EkORviNPbw0doIe+GHxDYkVBsGRGmSwKruYgIpH+I5g=; b=eL5EeZdWhqpRkxtfSQbRetCJI/i0GfCiXJDyP23qXD3pc4+cVtfb7fWNH1aFbDBpZq 2MOD2nxq7aWZUqMJjdqf3ZF6M/eGg+DmdIRbwNAOHiRok94mrZ23XRoXsh+22q3DhzGT glHktdp2njYQoPnN+zdYUOJA38anKcdANaJmgoQGHBci3FupQVHemZ+tMfSOzyq7LfVv Dngn72yLASuFKgTz468ivfKGYe9eyqkj853+UXORmxxq9me9q6fETQ5vKIJK+PJxkzkj w88/qLDyjYtjt2PJ1rlHL7jZzpn01nKRGCcGHcClPl16Z+X0Sgmc3dg6Ht/4QxFd27I6 s1Cw== MIME-Version: 1.0 Received: by 10.52.155.173 with SMTP id vx13mr1949280vdb.88.1332354836222; Wed, 21 Mar 2012 11:33:56 -0700 (PDT) Sender: timon.elviejo@gmail.com Received: by 10.220.154.131 with HTTP; Wed, 21 Mar 2012 11:33:56 -0700 (PDT) In-Reply-To: References: <4F5ADDCA.80303@KingsMountain.com> <4F60968D.4020703@stpeter.im> Date: Wed, 21 Mar 2012 19:33:56 +0100 X-Google-Sender-Auth: JNqv67IFezHxo-4DImUuZ_eMnFk Message-ID: From: =?ISO-8859-1?Q?Jorge_Tim=F3n?= To: Walter Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Proposal for a Finance Area Mailing List X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 21 Mar 2012 18:33:57 -0000 Please, let me know if there's any news. I'm going to unsubscribe from this list for now. On 3/15/12, Jorge Tim=F3n wrote: > Probably Ryan will be interested in participate too. > I agree that the discussion would be better in a "neutral" forum, I > was just suggesting forums to "join the people together" if it is > necessary to start the new mailing list. > If you want, I can start a thread in the bitcoin-dev mailing list to > get more people interested in the protocol. > > > On 3/15/12, Walter wrote: >> Thanks for your support Jorge, and welcome to the effort :) >> >> With regards to forum location, I think the main difficulty with using >> an established forum is that most people come from a certain community >> with interest and experience that is generally more focused on certain >> aspects of internet based financial exchange. >> >> For example, it would be unreasonable to expect people involved in >> mobile operator billing to be familiar with mutual credit systems, >> just as it would be unreasonable to expect people involved with high >> frequency trading on stock exchanges to be familiar with credit card >> settlement anti-fraud rule weightings. >> >> The establishment of a unique forum under the IETF provides the >> capacity for different groups to come together - without being under >> the banner of any particular one - to look at issues of >> interoperability and leverage the skills, insight and experience of >> other parties. It also means that there's an established and proven >> procedure for getting things done (eventually formalized), resolving >> questions of consensus fairly, etc. >> >> Anyway, Ripple brings a very unique and relevant perspective to >> forward looking internet finance and I am really glad that you are >> joining in. Looking forward to working together on the new list! >> >> Regards, >> Walter Stanish >> Payward, Inc. >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >> > > > -- > Jorge Tim=F3n > --=20 Jorge Tim=F3n From macar@cloudmark.com Wed Mar 21 12:04:12 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACEAD21F85CF for ; Wed, 21 Mar 2012 12:04:12 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aAgA9wad0K97 for ; Wed, 21 Mar 2012 12:04:12 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 2EB7D21F85D8 for ; Wed, 21 Mar 2012 12:04:12 -0700 (PDT) Received: from [172.20.2.21] (172.20.2.21) by exch-htcas901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 21 Mar 2012 12:04:11 -0700 Message-ID: <4F6A262B.7090703@cloudmark.com> Date: Wed, 21 Mar 2012 12:04:11 -0700 From: Mike Acar User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: References: <9F0A2492-AE7D-4C12-8BB0-13489FD7F6C1@gmail.com> <1331271383.6504.1.camel@neutron> <4F5E6255.9040402@cloudmark.com> <1331651889.3301.5.camel@neutron> <4F6914D7.5050505@cloudmark.com> <4F697867.2050500@gmx.de> <4F6A0985.8030208@cloudmark.com> <4F6A0AA8.70106@gmx.de> <4F6A134C.5060906@cloudmark.com> <4F6A1CF6.6060608@apache.org> <1332354655.2175.3.camel@neutron> In-Reply-To: <1332354655.2175.3.camel@neutron> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.20.2.21] Subject: Re: [apps-discuss] draft-pbryan-json-patch-04 - comments X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 21 Mar 2012 19:04:12 -0000 On 03/21/2012 11:30 AM, Paul C. Bryan wrote: > The intent of "test" was to ensure the partial state of a JSON resource > before applying modification(s) to it. Essentially, it's a recognition > that ETag (or equivalent entire-resource version) will be too > coarse-grained in some use cases. So in that sense, it makes the entire > patch document conditional on the tests being successfully applied; it's > definitely not intended to have some operations in a patch document be > applied and others not. Right, I understand that the patch is atomic. My concern has been that "test" alone doesn't save you from race conditions; you still need to lock whatever you're going to update, and in that case, you might as well lock, read, patch. I wondered how useful "test" would be without protocol support that might make it redundant. But I wasn't thinking about optimistic concurrency control, which "test" does indeed let you implement (like ETags). And if you have an application which requires a pessimistic locking strategy, then "test" operations in the patches would be redundant - the draft shouldn't require them. So I've come to agree that "test" makes sense as it is. -- Mike Acar - - macar at cloudmark dot com From julian.reschke@gmx.de Wed Mar 21 13:37:50 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01F0421E8136 for ; Wed, 21 Mar 2012 13:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.443 X-Spam-Level: X-Spam-Status: No, score=-103.443 tagged_above=-999 required=5 tests=[AWL=-0.844, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EjiUNOcN+ks4 for ; Wed, 21 Mar 2012 13:37:49 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 4C5B121E812D for ; Wed, 21 Mar 2012 13:37:48 -0700 (PDT) Received: (qmail invoked by alias); 21 Mar 2012 20:37:46 -0000 Received: from p57A6E199.dip.t-dialin.net (EHLO [192.168.178.36]) [87.166.225.153] by mail.gmx.net (mp020) with SMTP; 21 Mar 2012 21:37:46 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/1KXxKQb71KZMzCSymNlfyUUreMDxz5FmsMVGAYf w6sicloGT51Id+ Message-ID: <4F6A3C18.6000603@gmx.de> Date: Wed, 21 Mar 2012 21:37:44 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Mike Acar References: <9F0A2492-AE7D-4C12-8BB0-13489FD7F6C1@gmail.com> <1331271383.6504.1.camel@neutron> <4F5E6255.9040402@cloudmark.com> <1331651889.3301.5.camel@neutron> <4F6914D7.5050505@cloudmark.com> <4F697867.2050500@gmx.de> <4F6A0985.8030208@cloudmark.com> <4F6A0AA8.70106@gmx.de> <4F6A134C.5060906@cloudmark.com> <4F6A1CF6.6060608@apache.org> <1332354655.2175.3.camel@neutron> <4F6A262B.7090703@cloudmark.com> In-Reply-To: <4F6A262B.7090703@cloudmark.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-pbryan-json-patch-04 - comments X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 21 Mar 2012 20:37:50 -0000 On 2012-03-21 20:04, Mike Acar wrote: > On 03/21/2012 11:30 AM, Paul C. Bryan wrote: >> The intent of "test" was to ensure the partial state of a JSON resource >> before applying modification(s) to it. Essentially, it's a recognition >> that ETag (or equivalent entire-resource version) will be too >> coarse-grained in some use cases. So in that sense, it makes the entire >> patch document conditional on the tests being successfully applied; it's >> definitely not intended to have some operations in a patch document be >> applied and others not. > > Right, I understand that the patch is atomic. > > My concern has been that "test" alone doesn't save you from race > conditions; you still need to lock whatever you're going to update, and > in that case, you might as well lock, read, patch. I wondered how useful You can't do that interoperably in HTTP, unless you include WebDAV locking into the picture. > "test" would be without protocol support that might make it redundant. > > But I wasn't thinking about optimistic concurrency control, which "test" > does indeed let you implement (like ETags). > > And if you have an application which requires a pessimistic locking > strategy, then "test" operations in the patches would be redundant - the > draft shouldn't require them. On the other hand, they seem to be inexpensive to implement, but very expensive to emulate. > So I've come to agree that "test" makes sense as it is. +1 :-) Best regards, Julian From ray.polk@oracle.com Wed Mar 21 14:30:25 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA7421F8514 for ; Wed, 21 Mar 2012 14:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZTW1iJtR3SJ for ; Wed, 21 Mar 2012 14:30:25 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id 0D84321F8513 for ; Wed, 21 Mar 2012 14:30:24 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q2LLUMga019661 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Mar 2012 21:30:23 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q2LLUMKO012459 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Mar 2012 21:30:22 GMT Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q2LLULFr006960; Wed, 21 Mar 2012 16:30:21 -0500 MIME-Version: 1.0 Message-ID: Date: Wed, 21 Mar 2012 14:30:21 -0700 (PDT) From: Ray Polk To: X-Mailer: Zimbra on Oracle Beehive Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A020205.4F6A486F.009A,ss=1,re=0.000,fgs=0 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-pbryan-json-patch-04 - comments X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 21 Mar 2012 21:30:25 -0000 ----- msk@cloudmark.com wrote: | > 1. I am not sure if 'test' operation should be part of it. The purpose | > of the patch is to modify the document. 'test' operation either | > succeeds of fails, but it is unclear how this information will be | > communicated or used. It almost looks like a API operation rather than | > patch format instruction. I would argue that in current state it should | > not be included in the format. |=20 | Maybe I'm too firmly rooted in UNIX patch/diff land, but I don't think | I agree. "test" is useful up-front to ensure you're about to modify | what you intend to modify, and give you a chance to abort otherwise.=20 | In this case, "test" would be used to confirm you're in a context you | want to modify, much like the lines of context around a traditional | UNIX patch. |=20 | I would say that "test" is not useful except before any | add/modify/remove instructions. If it fails to establish context, the | whole patch aborts. Much like If-Match? Would a strong tag or hash be better than a content co= mparison? From pbryan@anode.ca Wed Mar 21 14:48:30 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 154A321E8083 for ; Wed, 21 Mar 2012 14:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eB709720xX99 for ; Wed, 21 Mar 2012 14:48:29 -0700 (PDT) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id 748D521E8032 for ; Wed, 21 Mar 2012 14:48:29 -0700 (PDT) Received: from [10.125.20.76] (unknown [209.52.95.1]) by maple.anode.ca (Postfix) with ESMTPSA id C5843647C for ; Wed, 21 Mar 2012 21:48:28 +0000 (UTC) Message-ID: <1332366507.2909.2.camel@neutron> From: "Paul C. Bryan" To: apps-discuss@ietf.org Date: Wed, 21 Mar 2012 14:48:27 -0700 In-Reply-To: References: Content-Type: multipart/alternative; boundary="=-rg/ox0QG41AYBiQNxDHW" X-Mailer: Evolution 3.2.2-1 Mime-Version: 1.0 Subject: Re: [apps-discuss] draft-pbryan-json-patch-04 - comments X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 21 Mar 2012 21:48:30 -0000 --=-rg/ox0QG41AYBiQNxDHW Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Hashing would be a good idea (because currently test requires the entire value to be expressed) but seemed like it could also add significant complexity, in large part due to the need to perform some level of transformation/normalization to establish a stable value to hash. Paul On Wed, 2012-03-21 at 14:30 -0700, Ray Polk wrote: > ----- msk@cloudmark.com wrote: > > | > 1. I am not sure if 'test' operation should be part of it. The purpose > | > of the patch is to modify the document. 'test' operation either > | > succeeds of fails, but it is unclear how this information will be > | > communicated or used. It almost looks like a API operation rather than > | > patch format instruction. I would argue that in current state it should > | > not be included in the format. > | > | Maybe I'm too firmly rooted in UNIX patch/diff land, but I don't think > | I agree. "test" is useful up-front to ensure you're about to modify > | what you intend to modify, and give you a chance to abort otherwise. > | In this case, "test" would be used to confirm you're in a context you > | want to modify, much like the lines of context around a traditional > | UNIX patch. > | > | I would say that "test" is not useful except before any > | add/modify/remove instructions. If it fails to establish context, the > | whole patch aborts. > > Much like If-Match? Would a strong tag or hash be better than a content comparison? > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --=-rg/ox0QG41AYBiQNxDHW Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit Hashing would be a good idea (because currently test requires the entire value to be expressed) but seemed like it could also add significant complexity, in large part due to the need to perform some level of transformation/normalization to establish a stable value to hash.

Paul

On Wed, 2012-03-21 at 14:30 -0700, Ray Polk wrote: 
----- msk@cloudmark.com wrote:

| > 1. I am not sure if 'test' operation should be part of it. The purpose
| > of the patch is to modify the document. 'test' operation either
| > succeeds of fails, but it is unclear how this information will be
| > communicated or used. It almost looks like a API operation rather than
| > patch format instruction. I would argue that in current state it should
| > not be included in the format.
| 
| Maybe I'm too firmly rooted in UNIX patch/diff land, but I don't think
| I agree.  "test" is useful up-front to ensure you're about to modify
| what you intend to modify, and give you a chance to abort otherwise. 
| In this case, "test" would be used to confirm you're in a context you
| want to modify, much like the lines of context around a traditional
| UNIX patch.
| 
| I would say that "test" is not useful except before any
| add/modify/remove instructions.  If it fails to establish context, the
| whole patch aborts.

Much like If-Match?  Would a strong tag or hash be better than a content comparison?
_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--=-rg/ox0QG41AYBiQNxDHW-- From mnot@mnot.net Wed Mar 21 17:37:58 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A93B21F8634 for ; Wed, 21 Mar 2012 17:37:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.194 X-Spam-Level: X-Spam-Status: No, score=-104.194 tagged_above=-999 required=5 tests=[AWL=-3.084, BAYES_05=-1.11, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uXLUHberXv3s for ; Wed, 21 Mar 2012 17:37:57 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 6446F21F8631 for ; Wed, 21 Mar 2012 17:37:57 -0700 (PDT) Received: from mnot-mini.mnot.net (unknown [118.209.134.89]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 808B450A64 for ; Wed, 21 Mar 2012 20:37:50 -0400 (EDT) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Mar 2012 11:37:47 +1100 Message-Id: <8717B335-A14C-4DFE-B78C-AD2B0F2014B1@mnot.net> To: Apps Discuss Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Subject: [apps-discuss] Free Universal Construction Kit X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 22 Mar 2012 00:37:58 -0000 I think there's a lesson for us in this; not sure what it is, though. = Maybe something about the relationship between Open Source and = standards? Anyway. See especially: = -- Mark Nottingham http://www.mnot.net/ From hannes.tschofenig@nsn.com Wed Mar 21 23:03:48 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF10621F84FF for ; Wed, 21 Mar 2012 23:03:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.43 X-Spam-Level: X-Spam-Status: No, score=-106.43 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C3xV0eIAnnsz for ; Wed, 21 Mar 2012 23:03:47 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 52A1821F84F3 for ; Wed, 21 Mar 2012 23:03:47 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q2M63hTn011859 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 22 Mar 2012 07:03:45 +0100 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q2M63eFT014818; Thu, 22 Mar 2012 07:03:40 +0100 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Mar 2012 07:03:33 +0100 Received: from 10.159.32.93 ([10.159.32.93]) by FIESEXC035.nsn-intra.net ([10.159.0.182]) with Microsoft Exchange Server HTTP-DAV ; Thu, 22 Mar 2012 06:03:32 +0000 MIME-Version: 1.0 Message-ID: <6c7801cd07f1$826a04da$5d209f0a@nsnintra.net> From: "Tschofenig, Hannes (NSN - FI/Espoo)" Thread-Topic: [apps-discuss] Free Universal Construction Kit Thread-Index: Ac0H8YJpV13VPbqkRUiKOYlz4Zt2UQ== Date: Thu, 22 Mar 2012 08:03:39 +0200 To: "ext Mark Nottingham" , "Apps Discuss" Content-Type: multipart/alternative; boundary="_891E1BAA-9241-599D-5EA1-2C8A090D00C5_"; charset="iso-8859-1" X-OriginalArrivalTime: 22 Mar 2012 06:03:33.0262 (UTC) FILETIME=[8328E2E0:01CD07F1] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 4786 X-purgate-ID: 151667::1332396226-00007415-499D86E3/0-0/0-0 Subject: Re: [apps-discuss] Free Universal Construction Kit X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 22 Mar 2012 06:03:48 -0000 --_891E1BAA-9241-599D-5EA1-2C8A090D00C5_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" Hi Mark, Nice stuff in two ways: 1) as a toy useful, and 2) interesting when compared with IETF technologies. I believe we are, however, already deeply into this 'adaptor/gatewaying' bu= siness. As an example think about the asynchronous real-time protocol work = (lacking a better word). Folks are looking into the interaction between XMP= P and SIP, between SIP and RTCWEB and various sub-components within these a= reas, such as emergency services. Another example is all the work on IPv4/IPv6 transition. btw, while the comparison between Lego blocks and IETF protocols had been u= sed before I believe it is not a perfect match since we often have one or = multiple architectures in mind when we design the building blocks. Conseque= ntly, the building blocks work fine in a range of architectures but not eve= rywhere. They are not as nicely interchangeable as Lego blocks. Just a few thoughts early in the morning in response to your mail. Ciao Hannes Sent from my Windows Phone -----Original Message----- From: ext Mark Nottingham Sent: 3/22/2012 2:38 AM To: Apps Discuss Subject: [apps-discuss] Free Universal Construction Kit I think there's a lesson for us in this; not sure what it is, though. Maybe= something about the relationship between Open Source and standards? Anyway= . See especially: -- Mark Nottingham http://www.mnot.net/ _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss --_891E1BAA-9241-599D-5EA1-2C8A090D00C5_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii"
Hi Mark,

Nice stuff in two ways:
1) as a toy= useful, and
2) interesting when compared with IETF technologies.
I believe we are, however, already deeply into this 'adaptor/gatewaying' b= usiness. As an example think about the asynchronous real-time protocol work= (lacking a better word). Folks are looking into the interaction between XM= PP and SIP, between SIP and RTCWEB and various sub-components within these = areas, such as emergency services.

Another example is all the work o= n IPv4/IPv6 transition.


btw, while the comparison between Lego b= locks and IETF protocols had been used  before I believe it is not a p= erfect match since we often have one or multiple architectures in mind when= we design the building blocks. Consequently, the building blocks work fine= in a range of architectures but not everywhere. They are not as nicely int= erchangeable as Lego blocks.

Just a few thoughts early in the mornin= g in response to your mail.

Ciao
Hannes

Sent from my Windo= ws Phone
From: ext Mark Nottingham
Sent: 3/22/2012 2:38 AM
To: Apps Discuss
[apps-discuss] Free Universal Construction Kit

<ht= tp://fffff.at/free-universal-construction-kit/>

I think there's a= lesson for us in this; not sure what it is, though. Maybe something about = the relationship between Open Source and standards? Anyway.

See espe= cially:

<http://media.fffff.at/free-universal-construction-kit/im= ages/free-universal-construction-kit-poster.pdf>


--
Mark N= ottingham   http://www.mnot.net/



_________________= ______________________________
apps-discuss mailing list
apps-discuss= @ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss
<= /html>= --_891E1BAA-9241-599D-5EA1-2C8A090D00C5_-- From dcrocker@bbiw.net Thu Mar 22 03:48:31 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9242421F8681; Thu, 22 Mar 2012 03:48:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.703 X-Spam-Level: X-Spam-Status: No, score=-2.703 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DATE_IN_PAST_06_12=1.069, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zOeAIviMk9o5; Thu, 22 Mar 2012 03:48:27 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8D98D21F8675; Thu, 22 Mar 2012 03:48:27 -0700 (PDT) Received: from [192.168.8.65] (ter75-1-81-57-68-77.fbx.proxad.net [81.57.68.77]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q2MAm6GM004968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Mar 2012 03:48:13 -0700 Message-ID: <4F6A966A.6000102@bbiw.net> Date: Thu, 22 Mar 2012 04:03:06 +0100 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: apps-discuss@ietf.org, draft-ietf-decade-problem-statement.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Thu, 22 Mar 2012 03:48:27 -0700 (PDT) Cc: iesg Subject: [apps-discuss] Review of: draft-ietf-decade-reqs-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 22 Mar 2012 10:48:31 -0000 I have been selected as the Applications Area Directorate reviewer for this draft: (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). Document: draft-ietf-decade-reqs-05 Title: DECADE Requirements Reviewer: D. Crocker Review Date: 22 March 2012 Summary: The document specifies requirements for a DECADE service that caches content topologically near "swarms" of consumer clients. I believe the documents needs substantial work. The motivation for DECADE is stated a bit differently in the -problem draft than in this -reqs draft. In the -problem draft, the task is to place content "near" consumers. In the current draft, the task is for any sort of separate storage service that can be controlled by "P2P applications". As with the -reqs draft, a number of core terms are not defined. In some cases, they seemed to be used with different or ambiguous meaning. Possibly, different terms are used for the same meaning; I can't be sure. More fundamentally, the considerable range of requirements appears to be predicated on one or more functional models -- a storage service overlay -- that is unstated, except by intuiting it -- if not completely -- from various of the requirements. The requirements desperately need a functional model/architecture specification upon which to build their references and meanings. It would chart out the functional components and their relationships, greatly aiding in discussion of actors and actors. The requirements are riddled with assumed characteristics of the model. That is, the model seems clearly to be in the minds of the authors, but the reader is left guessing. This needs to be remedied. By now, those active in the DECADE working group are likely thinking that I should have read the -arch document. First, it wasn't in the set delivered for review. I assume that it is not yet ready? Second, neither the -problem nor -reqs documents are consistent with the -arch document. My suggestion is to complete the -arch document /before/ doing further work on the -reqs document. Then when working on -reqs, diligently cite terms and discussion in the -arch document to explain the terms and provide the motivation for the requirements. (For reference, I've used some possible terms in this review, since they are commonly used elsewhere. While I do suggest re-using established terms that have the correct meaning, I don't care which ones are chosen. As with the -problem document, normative language is used but there is not reference that defines them. I suspect that some of the requirements -- notably the one concerning credentials -- entails a security capability that has never been deployed widely in the open Internet. That is, not having required support by large numbers of independent administrations. In general, I suspect that the assertions of security requirements are too rigid and will incur unnecessary expense for many environments. The last security-related concern I have is that the model is entirely channel-based, permitting no object-based security, such as with S/Mime, OpenPGP or even DKIM. For some uses, the advantage of object-based security is that it does not matter what the security properties of the server are! Organizationally, the document seems to have related requirements that are redundant and/or widely separated. It also makes forward references, a number times, which suggestions that re-organization would develop a better foundation of requirements. Detailed Comments: > DECADE Y. Gu > Internet-Draft Huawei > Intended status: Informational D. Bryan > Expires: May 3, 2012 Polycom, Inc. > Y. Yang > Yale University > R. Alimi > Google > October 31, 2011 > > > DECADE Requirements > draft-ietf-decade-reqs-05 > > Abstract > > The target of DECoupled Application Data Enroute (DECADE) is to > provide an open and standard in-network storage system for > applications, primarily P2P (peer-to-peer) applications, to store, Concerns about terminology that were stated for the "problem" document also apply to this document. In general, all of the major concerns expressed in the review of the -problem document should also be imported into this review. > 1. Introduction > > The object of DECoupled Application Data Enroute (DECADE) is to > provide an open and standard in-network storage system for content What does "in network" mean? It seems likely that it does not mean a collection of routers, but the paper doesn't define it; yet it uses the term heavily. As with the -problem document, I believe that what is being postulated is a storage server infrastructure, to operate between content producers and content consumers. How these servers are insinuated in the path from producer to consumer is not discussed. I can't tell how important a lack that is. > distribution applications, where data is typically broken into one or By some measures, all applications deliver content. This paper needs to define the content distribution (storage service) that is meant here, in distinct technical terms that distinguish the service from other services that are not content distribution, that is, which do not qualify as an example of a DECADE service. > more chunks and then distributed. This may already include many > types of applications including P2P applications, IPTV (Internet What is P2P? In technical terms that distinguish it. > Protocol Television), and VoD (Video on Demand). (For a precise > definition of the applications targeted in DECADE, see the definition > for Target Application in Section 2.) Instead of always transferring > data directly from a source/owner client to a requesting client, the From a producer to a consumer. > source/owner client can write to and manage its content on its in- > network storage. The requesting client can get the address of the > in-network storage pertaining to the source/owner client and read > data from the storage. > > This draft enumerates and explains the rationale behind SPECIFIC Having Rationale segments is extremely useful. > requirements on the protocol design and on any data store > implementation that may be used to implement DECADE servers that > should be considered during the design and implementation of a DECADE > system. As such, it DOES NOT include general guiding principles. > General design considerations, explanation of the problem being > addressed, and enumeration of the types of applications to which > DECADE may be suited is not considered in this document. For general > information, please see the problem statement > [I-D.ietf-decade-problem-statement] and architecture > [I-D.ietf-decade-arch] drafts. > > This document enumerates the requirements to enable target > applications to utilize in-network storage. In this context, using > storage resources includes not only basic capabilities such as > writing, reading, and managing data, but also controlling access for > particular remote clients with which it is sharing data. > Additionally, we also consider controlling the resources used by > remote clients when they access data as an integral part of utilizing > the network storage. "remote client" -> consumer (?) > This document discusses requirements pertaining to DECADE > protocol(s). In certain deployments, several logical in-network > storage systems could be deployed (e.g., within the same > administrative domain). These in-network storage systems can > communicate and transfer data through internal or non-standard > communication messages that are outside of the scope of these > requirements, but they SHOULD use DECADE protocol(s) when > communicating with other DECADE-capable in-network storage systems. What does it mean to have multiple storage systems? How do they differ? How are they similar? > > > Gu, et al. Expires May 3, 2012 [Page 5] > > Internet-Draft DECADE Requirements October 2011 > > > 2. Terminology and Concepts > > This document uses terms defined in > [I-D.ietf-decade-problem-statement]. > > This document also defines additional terminology: > > Target Application: An application (typically installed at end-hosts) 1. What, exactly, is an 'end-host' for this discussion? 2. In a distributed environment, at the application layer, applications typically (always?) are distributed. That is, The folks consuming content presumably are also running part of the application. Hence, the definition here for "target application" sounds an awful lot like a server function or a content producer or some other established term for that specific role. Note that it does not cover the consumer side of the equation. That is, it does not appear to cover all of the components of the application, such as the users of the application. > with the ability to explicitly control usage of network and/or > storage resources to deliver content to a large number of users. > This includes scenarios where multiple applications or entities > cooperate, such as with P2P, CDN, and hybrid P2P/CDN architectures. > Such applications distribute large amounts of content (e.g., a large > file, or video stream) by dividing the content into smaller blocks > for more flexible distribution (e.g., over multiple application-level > paths). The distributed content is typically immutable (though it > may be deleted). We use the term Target Application to refer to the > type of applications that are explicitly (but not exclusively) > supported by DECADE. P2P is used throughout but never defined. What are the technical characteristics that make it distinct from basic, client/server models or the web or email or the DNS? What is the difference between "network resources" and "storage resources" and what does it mean to control each? I suspect that the current work is /not/ targeted at controlling network resources, yet it appears to imply that such control is possible. Elaborate on the mean of 'flexible distribution' and its technical import for DECADE. From the above definition, a target application is one that is given some controls. It has a large number of users. Given the term P2P, are the users the first P or the second? (Yes, I mean the question seriously.) By 'immutable' does this mean it's static content, that does not change from one retrieval to the next? However what about the case that qualify as targeted applications but are not 'typical'? > > 3. Requirements Structure Good section. Helpful template. > The DECADE protocol is intended to sit between Target Applications > and a back-end storage system. DECADE does not intend to develop yet "back-end"? what does that mean. Note that much of this is likely to be made clearer with some diagrams showing components and their relationships. > another storage system, but rather to create a protocol that enables > Target Applications to make use of storage within the network, Actually, by defining an access and control interface to a storage system, this work is, in effect, defining the system. That is, it /is/ defining a storage system. It's not defining the internals to the system, but it is defining its public face. > leaving specific storage system considerations to the implementation > of the DECADE servers as much as possible. For this reason, we have > divided the requirements into two primary categories: > > o Protocol Requirements: Protocol requirements for Target > Applications to make use of in-network storage within their own > data dissemination schemes. Development of these requirements is > guided by a study of data access, search and management > capabilities used by Target Applications. These requirements may > be met by a combination of existing protocols and new protocols. This covers the producer side of storage access and control, but says nothing about the consumer side. How do consumers access the storage? > > o Storage Requirements: Functional requirements necessary for the > back-end storage system employed by the DECADE server. Is there a "front-end" storage system? Again, what is meant by "back-end"? How does that term add to the meaning here? > Development of these requirements is guided by a study of the data > access patterns used by Target Applications. These requirements While the behaviors of the data producer are of course important, I would think that the behaviors of the data consumers would be more so. Yet that appears to be missed in the text. > should be met by the underlying data transport used by DECADE. In > this document, we use "data transport" to refer to a protocol used > to read and write data from DECADE in-network storage. > > Note that a third category also enumerates requirements on the > protocol used to discover DECADE Servers. > > > > Gu, et al. Expires May 3, 2012 [Page 6] > > Internet-Draft DECADE Requirements October 2011 > > > It should also be made clear that the approach is to make DECADE a > simple protocol, while still enabling its usage within many Target > Applications. For this reason, and to further reinforce the > distinction between DECADE and a storage system, in some cases we > also highlight the non-requirements of the protocol. These non- > requirements are intended to capture behaviors that will NOT be > assumed to be needed by DECADE's Target Applications and hence not > present in the DECADE protocol. > > Finally, some implementation considerations are provided, which while > not strictly requirements, are intended to provide guidance and > highlight potential points that need to be considered by the protocol > developers, and later by implementors. > > > 4. Protocol Requirements > > This section details the requirements of DECADE protocol(s). > > 4.1. Overall Protocol Requirements > > 4.1.1. Connectivity Concerns > > 4.1.1.1. NATs and Firewalls > > REQUIREMENT(S): DECADE client to server protocols SHOULD be usable > across firewalls and NAT (Network Address Translation) devices > without requiring additional network support (e.g., Application- > level Gateways). How is that possible? Given the degree to which NATs and firewalls get in the way, this would seem a difficult requirement to satisfy. And this raises an issue which 'requirements'. While it is quite good to add the rationale, there is also a question of feasibility. > RATIONALE: Firewalls and NATs are widely used in the Internet today, > both in ISP (Internet Service Provider) and Enterprise networks > and by consumers. Deployment of DECADE must not require > modifications to such devices (beyond, perhaps, reconfiguration). > Note that this requirement applies to both any new protocol > developed by the DECADE Working Group and any data transport used > with DECADE. > > 4.1.1.2. Connections to Clients > > REQUIREMENT(S): DECADE SHOULD require that network connections be > made from DECADE clients to DECADE servers (i.e., not from the > server to the DECADE client). This document uses the term 'servers', which the Problem document did not. It is not clear what the term refers to, exactly, in this document. Perhaps the distinction that is meant is producer and consumer? > RATIONALE: Many household networks and operating systems have > firewalls and NATs configured by default to block incoming > connections. To ease deployment by avoiding configuration > changes and help mitigate security risks, DECADE should not > > > > Gu, et al. Expires May 3, 2012 [Page 7] > > Internet-Draft DECADE Requirements October 2011 > > > require clients to listen for any incoming network connections > (beyond what is required by any other already-deployed > application). For many (all?) p2p -- such at BitTorrent -- any consumer can become a producer. That seems to be entirely at odds with this requirement. > > 4.1.2. Security > > 4.1.2.1. Secure Transport > > REQUIREMENT(S): DECADE MUST contain a mode in which all > communication between a DECADE client and server is over a secure > transport that provides confidentiality, integrity, and > authentication. This suggests a transitive trust model of security that is entirely channel-based. It precludes object-based security such as authentication, data integrity and confidentiality. Also, transitive trust, absent quite a bit of end2end administrative structure, has a very problematic history when taken to Internet scale -- specifically when there is a large number of independent administrative domains. It also means that special environments within an adequately operated administrative domain are required to incur overhead they don't need. That is, a group operating with this mechanism, in an environment that permits adequate trust without satisfying this requirement, nonetheless will be required to incur the cost of this requirement. > RATIONALE: Target Applications may wish to write sensitive data. To > satisfy this use case, DECADE must provide a mode in which all > communication between a DECADE client and server occurs over a > secure transport protocol (e.g., SSL/TLS). Note the "may". The applications also might not want to write sensitive data. And by the way, is the 'may' here normative? Probably not. > 4.1.3. Error and Failure Conditions > > 4.1.3.1. Overload Condition > > REQUIREMENT(S): In-network storage, which is operating close to its > capacity limit (e.g., too busy servicing other requests), MUST be > permitted to reject requests and not be required to generate > responses to additional requests. In-network storage MUST also > be permitted to redirect requests (see Section 4.1.3.5) as a > load-shedding technique. "rejection" is usually an active process that includes generating a response. I assume the actual requirement here is to permit /ignoring/ or /dropping/ requests that cannot be serviced. Also, this model optimizes convenience for the storage component, at the expense of the user-side components (content producers and consumers.) So the "customers" have to wait for timeouts. If the overall system is to have any sort of reliability, that means that these users of the storage system will do retransmissions, since they won't know whether their request got lost or the storage server dropped it. At a minimum, this requirement therefore imposes some sort of exponential backoff on retransmission by the users of the system. The requirements need to attend to effects on the IP network, as much as to the DECADE storage servers. In other words, while the design is likely to require some amount of retransmission, no matter what the other requirements are, it is likely that this requirement makes the mechanism needed more and overall is likely to /reduce/ aggregate system performance. And for reference, rejection notices tend to be cheap. I suspect a more reasonable requirement -- if decent user/storage interaction is a goal -- is to have the storage server provide differential behavior, to optimize for activities that have priority -- for whatever priority model makes sense -- and give worse performance for 'lower' priority requests. At the least, performance effects of this requirement need to be analyzed and documented better. The rationale that is provided, below, is an entirely localized point and ignores larger end2end systems implications. > RATIONALE: Forcing the in-network storage to respond to requests > when operating close to its capacity can impair its ability to > service existing requests, and thus is permitted to avoid > generating responses to additional requests. > 4.1.3.2. Insufficient Resources > > REQUIREMENT(S): DECADE MUST support an error condition indicating to > a DECADE client that resources (e.g., storage space) were not > available to service a request (e.g., storage quota exceeded when > attempting to write data). As stated here, this requirement is directly at odds with the above 4.1.3.1. "Lack of capacity" is an example of resources not being available. > > RATIONALE: The currently-used resource levels within the in-network > storage are not locally-discoverable, since the resources (disk, > network interfaces, etc) are not directly attached. In order to > allocate resources appropriately amongst remote clients, a client > must be able to determine when resource limits have been reached. > The client can then respond by explicitly freeing necessary > resources or waiting for such resources to be freed. > > > > Gu, et al. Expires May 3, 2012 [Page 8] > > Internet-Draft DECADE Requirements October 2011 > > > 4.1.3.3. Unavailable and Deleted Data > > REQUIREMENT(S): DECADE MUST support error conditions indicating that > (1) data was rejected from being written, (2) deleted, or (3) > marked unavailable by a storage provider. 4.1.3.1-4 ought to be written as a single requirement, with a single sentence that dictates the conditions that are covered. The current micro-granularity just makes the document large and actually less informative (since it encourages the reader to get lost in the details...) > > RATIONALE: Storage providers may require the ability to (1) avoid > storing, (2) delete, or (3) quarantine certain data that has been > identified as illegal (or otherwise prohibited). DECADE does not > indicate how such data is identified, but applications using > DECADE should not break if a storage provider is obligated to > enforce such policies. Appropriate error conditions should be > indicated to applications. > > 4.1.3.4. Insufficient Permissions > > REQUIREMENT(S): DECADE MUST support error conditions indicating that > the requesting client does not have sufficient permissions to > access requested data objects. > > RATIONALE: DECADE clients may request objects to which they do not > have sufficent access permissions, and DECADE servers must be > able to signal that this has occurred. Note that access > permissions may be insufficient due to a combination of the > credentials presented by a client as well as additional policies > defined by the storage provider. > > 4.1.3.5. Redirection Redirection is not an error condition, per se. It probably should be handled in a section dealing with discovery and routing, to get to the correct server. > REQUIREMENT(S): DECADE SHOULD support the ability for a DECADE > server to redirect requests to another DECADE server. This may > either be in response to an error, failure, or overload > condition, or to support capabilities such as load balancing. It might also cover cases in which the data have been moved. ("it used to be here, but now it is stored over there") > RATIONALE: A DECADE server may opt to redirect requests to another > server to support capabilities such as load balancing, or if the > implementation decides that another DECADE server is in a better > position to handle the request due to either its location in the > network, server status, or other consideration. This implies a rather sophisticated knowledge by servers about other servers. > 4.2. Transfer and Latency Requirements > > 4.2.1. Low-Latency Access > > > > > > > > > Gu, et al. Expires May 3, 2012 [Page 9] > > Internet-Draft DECADE Requirements October 2011 > > > REQUIREMENT(S): DECADE SHOULD provide "low-latency" access for > application clients. DECADE MUST allow clients to specify at > least two classes of services: lowest possible latency and > latency non-critical. Absent a definition of low-latency, there is no way to tell whether the performance requirement is being met. There also needs to be a much more technical definition of low-latency in terms of the overall system. What pieces of end2end work need to be done differently? > RATIONALE: Some applications may have requirements on delivery time > (e.g., live streaming [PPLive]). The user experience may be > unsatisfactory if the use of in-network storage results in lower > performance than connecting directly to remote clients over a > low-speed, possibly congested uplink. Additionally, the overhead > required for control-plane operations in DECADE must not cause > the latency to be higher than for a low-speed, possibly congested > uplink. While it is impossible to make a guarantee that a system > using in-network storage will always outperform a system that > does not for every transfer, the overall performance of the > system should be improved compared with direct low-speed uplink > connections, even considering control overhead. > > 4.2.2. Data Object Size > > REQUIREMENT(S): DECADE MUST allow for efficient data transfer of > small objects (e.g., 16KB) between a DECADE client and in-network > storage with minimal additional latency imposed by the protocol. This needs to provide a technical definition of "efficient" as meant here. Otherwise there is no basis for telling whether the requirement is being met. Also, does this apply to /all/ transfers? Might there be alternate modes, for example, with one for small objects and another for large. > RATIONALE: Though Target Applications are frequently used to share > large amounts of data (e.g., continuous streams or large files), > the data itself is typically subdivided into smaller chunks that > are transferred between clients. Additionally, the small chunks Frankly, the first sentence doesn't make any sense to me. Or rather, it asserts a fact that doesn't make obvious sense. This needs more explanation. > may have requirements on delivery time (e.g., in a live-streaming Small data segments can produce lower latencies for individual segments but also can dramatically lower overall throughput, since there is higher aggregate segment-handling costs. Worse, when the segments come in rapid streams, the collision/congestion issues get worse exponentially. > application). DECADE must enable data to be efficiently > transferred amongst clients at this granularity. It is important > to note that DECADE may be used to store and retrieve larger > objects, but protocol(s) should not be designed such that usage > with smaller data objects cannot meet the requirements of Target > Applications. I believe these are typically competing design requirements. A protocol good for one is typically not very good for the other, unless there's been an advance in design that I missed (which is entirely possible.) > > 4.2.3. Communication among DECADE Servers > > REQUIREMENT(S): DECADE SHOULD support the ability for two in-network > storage elements in different administrative domains to write > and/or read data directly between each other (if authorized as > described in Section 4.7). If such a capability is supported, > this MAY be the same (or a subset or extension of) as the DECADE > protocol(s) used by clients to access data. There has been no previous discussion of administrative domains or permissions. The probably meaning of an ADMD is good, but it needs to be defined. There is also no concept of 'direct' versus 'indirect' reading or writing. Requirements should be careful to cover all relevant cases. For example, what about data exchange among servers within the /same/ administrative domain? Also, there needs to be a technical meaning to "direct", here. From the rationale, it appears that the assumed model is to have mediation by some other devices? > > > > > > > Gu, et al. Expires May 3, 2012 [Page 10] > > Internet-Draft DECADE Requirements October 2011 > > > RATIONALE: Allowing server-to-server communication can reduce > latency in some common scenarios. Consider a scenario when a > DECADE client is downloading data into its own storage from Which kind of client? Also, does downloading mean "retrieving"? (upload and download can be ambiguous.) > another client's in-network storage. One possibility is for the "client's in-network storage"? clients do not "have" or "own" storage. Is the upload/download being done "through" the client? If not, then how is this other client relevant? I suspect this requirement comes from a model that assumes servers do not talk to each other and that, therefore, all data between servers goes through their clients? Yet requirement 4.2.3 goes contrary to this. At a minimum, this further suggests the need for there to be a statement of the model, the assumptions, and the like, before laying down requirements based on them. By the way, I thought BitTorrent was a user2user direct transfer mechanism, yet it was one of only 2 example scenarios in the -problem document. That is, it has no supporting infrastructure, such as storage servers. > client to first download the data itself, and then upload it to > its own storage. However, this uploading causes unnecessary > latency and network traffic. Allowing the data to be downloaded > from the remote in-network storage into the client's own in- > network storage can alleviate both. > > 4.3. Data Access Requirements > > 4.3.1. Reading/Writing Own Storage > > REQUIREMENT(S): DECADE MUST support the ability for a DECADE client > to read data from and write data to its own in-network storage. > > RATIONALE: Two basic capabilities for any storage system are reading > and writing data. A DECADE client can read data from and write > data to in-network storage space that it owns. The organization of the requirements in the documents seems odd, if this is where such a basic requirement is finally appearing. > > 4.3.2. Access by Other Users > > REQUIREMENT(S): DECADE MUST support the ability for a user to apply > access control policies to users other than itself for its This implies that particular users "own" particular instances of data. The model for this needs to be stated. For example, can there be more than one owner of a given instance? Can different instances of the same data have different owners and different access control settings; if so, why? Besides lacking a model, these requirements lack any sense of the scenarios that need to be supported. This would provide much better motivation for many of the requirements than do individual rationales. > storage. The users with whom access is being shared can be under > a different administrative domain than the user who owns the in- > network storage. The authorized users may read from or write to > the user's storage. > > RATIONALE: Endpoints in Target Applications may be located across What is an endpoint? Is it the same as a client or a specific kind of client? > multiple ISPs under multiple administrative domains. Thus, to be Target applications constitute an application overlay on the Internet. The relevance of routers and connections to them is that it defines a topology, determining which components of the application are "near" and which are not. However it is not immediately clear how the administrative organization of the routers is relevant. This requirement appears to conflate administrative domains between IP routing service providers with administrative domains of target application producers and consumers. Here, again, we need a description of the model that makes this relevant. > useful by Target Applications, DECADE allows a user to implement > access control policies for users that may or may not be known to > the user's storage provider. Ahh. It appears that the assumption is that storage is operated by an "ISP"? However servers can be operated by many different types of organizations. I suspect the model will be more useful to simply assert that storage servers can be operated by different organizations than those operating clients, and that different storage servers can be in different administrative domains -- that is, under different administrative author. > > 4.3.3. Negotiable Data Transport Protocol > > REQUIREMENT(S): DECADE MUST support the ability for a DECADE client > to negotiate with its in-network storage about which protocol it > can use to read data from and write data to its In-network > storage. DECADE MUST specify at least one mandatory protocol to > be supported by implementations; usage of a different protocol > may be selected via negotiation. > > > > > > > Gu, et al. Expires May 3, 2012 [Page 11] > > Internet-Draft DECADE Requirements October 2011 > > > RATIONALE: Since typical data transport protocols (e.g., NFS and > WebDAV) already provide read and write operations for network > storage, it may not be necessary for DECADE to define such > operations in a new protocol. However, because of the particular > application requirements and deployment considerations, different > applications may support different protocols. Thus, a DECADE > client must be able to select an appropriate protocol also The rationale is helpful. However it implies some storage-related entity with which negotiation can be done. What is it? How is it operated? > supported by the in-network storage. This requirement also > follows as a result of the requirement of Separation of Control > and Data Operations (Section 4.3.4). On the average, it's better to have backward references rather than forward references. Organizing things to support this tends to produce documents that establish a foundation before building upon it. > > 4.3.4. Separation of Data and Control Policies > > REQUIREMENT(S): DECADE Protocol(s) MUST only provide a minimal set > of core operations to support diverse policies implemented and > desired by Target Applications. I have no idea what this means. There is no basis for knowing what satisfies it. Also, applications don't have desires. For generic requirements about this kind of basic design philosophy it is often most helpful to cast a requirement in terms of tradeoffs. > > RATIONALE: Target Applications support many complex behaviors and > diverse policies to control and distribute data, such as (e.g., > search, index, setting permissions/passing authorization tokens). > Thus, to support such Target Applications, these behaviors must > be logically separated from the data transfer operations (e.g., > read, write). Some minimal overlap (for example obtaining > credentials needed to encrypt or authorize data transfer using > control operations) may be required to be directly specified by > DECADE. > > 4.4. Data Management Requirements > > 4.4.1. Agnostic of reliability > > REQUIREMENT(S): DECADE SHOULD remain agnostic of reliability/ > fault-tolerance level offered by storage provider. Latency is a form of service. So latency matters but reliability and fault-tolerance do not? Why? > > RATIONALE: Providers of a DECADE service may wish to offer varying > levels of service for different applications/users. However, a > single compliant DECADE client should be able to use multiple > DECADE services with differing levels of service. > > 4.4.2. Data Object Attributes > > REQUIREMENT(S): DECADE MUST support the ability to associate > attributes with data objects with a scope local to a DECADE > server, and for DECADE clients to query these attributes. DECADE > protocol(s) MUST transmit any attributes using an operating > system-independent and architecture-independent standard format. What does it mean to be "architecture-independent"? > DECADE protocol(s) MUST be designed such that new attributes can > be added by later protocol revisions or extensions. > > > > Gu, et al. Expires May 3, 2012 [Page 12] > > Internet-Draft DECADE Requirements October 2011 > > > RATIONALE: DECADE supports associating attributes (e.g., a time-to- > live, creation timestamp, or object size) with a data object. Where is the full set of required/permitted attributes specified? Otherwise, the Rationale is quit helpful. > These attributes are local to a data object stored by a > particular DECADE server, and are thus not applied to any DECADE > server or client to which the data object is copied. These > attributes may be used as hints to the storage system, internal > optimizations, or as additional information queryable by DECADE > clients. > > 4.4.3. Time-to-live for Written Data Objects > > REQUIREMENT(S): DECADE MUST support the ability for a DECADE client > to indicate a time-to-live value (or expiration time) indicating > a length of time until particular data can be deleted by the in- > network storage element. > > RATIONALE: Some data objects written by a DECADE client may be > usable only within a certain window of time, such as in live- > streaming P2P applications. Providing a time-to-live value for > data objects (e.g., at the time they are written) can reduce > management overhead by avoiding many 'delete' commands sent to > in-network storage. The in-network storage may still keep the > data in cache for bandwidth optimization. But this is guided by > the privacy policy of the DECADE provider. It isn't just the "effort" of the commands themselves. To be able to do the commands requires knowing where they are needed. This means a detailed knowledge of every server caching a copy. > > 4.4.4. Offline Usage > > REQUIREMENT(S): DECADE MAY support the ability for a user to provide > authorized access to its in-network storage even if the user has > no DECADE applications actively running or connected to the > network. What does it mean for "a user to provide authorized access"? This again invokes an architecture and security model that hasn't been specified. > > RATIONALE: If an application desires, it can authorize remote > clients to access its storage even after the application exits or > network connectivity is lost. An example use case is mobile > scenarios, where a client can lose and regain network > connectivity very often. "Data owners can assert persistent data access authorization for other users"? 1. Data owners can assign access to other users. 2. The assignment can persist even when the owner is absent. 3. Users can be "remote" (which presumably means in an other admin domain?) These are three separate requirements. It's ok to state them together but each needs to be explained in terms of need. The Rationale provided here really is the 'what' not the 'why'. That is, it provides basic meaning, not an explanation of why the requirement is needed. But again, this all gets clearer with an integrated description of the model and architecture, rather than these piecemeal requirements. > > 4.5. Data Naming Requirements > > 4.5.1. Unique Names > > REQUIREMENT(S): DECADE MUST support a naming scheme that ensures a > high probability of uniqueness and supports the operation of > DECADE servers under diverse administrative domains with no > coordination. DECADE SHOULD provide a mechanism (minimally > rejection) to handle the improbable case of a collision. > "uniqueness" can have variable attributes. Not just statistical, but scope and persistence. What are the requirements for these and why? The collision-handling requirement presumes that collision will be detected... > > > Gu, et al. Expires May 3, 2012 [Page 13] > > Internet-Draft DECADE Requirements October 2011 > > > RATIONALE: When writing a data object, a DECADE Client should be > able to write it without being concerned over whether an object > of the same name already exists, unless the existing object > contains the exact same data. Frankly, this rationale is bizarre. I don't think I've ever seen a scenario that supports this and scales. > Note that it may be reasonable for > DECADE to satisfy this requirement probabilistically (e.g., using > a hashing mechanism). As a result, it is wise to provide a > collision handling mechanism, even if the probability of > collisions is extremely low. Again, how can collisions be detected? > 4.6. Resource Control > > 4.6.1. Multiple Applications > > REQUIREMENT(S): DECADE SHOULD support the ability for users to > define resource sharing policies for multiple applications > (DECADE clients) being run/managed by the user. What does this mean? The text in a Rationale should not be required in order to understand what a requirement means. > > RATIONALE: A user may own in-network storage and share the in- > network storage resources amongst multiple applications. For > example, the user may run one or more video-on-demand > application(s) and a live-streaming application(s) which both > make use of the user's in-network storage. The applications may > be running on different machines and may not directly > communicate. Thus, DECADE should enable the user to determine > resource sharing policies between the applications. "resource sharing policies between applications" does not have an obvious meaning for me, especially given the preceding statement that the apps don't communicate with each other. > > One possibility is for a user to indicate the particular resource > sharing policies between applications out-of-band (not using a > standard protocol), but this requirement may manifest itself in > passing values within DECADE protocol(s) to identify individual > applications. Such identifiers can be either user-generated or > server-generated and do not need to be registered by IANA. > > 4.6.2. Per-Remote-Client, Per-Data Control > > REQUIREMENT(S): A DECADE client MUST be able to assign resource > policies (bandwidth share, storage quota, and network connection > quota) to individual remote clients for reading from and writing > particular data to its in-network storage within a particular > range of time. The DECADE server MUST enforce these constraints. It's unlikely the data owner can specify network performance characteristics. As stated, this requirement has more to do with the network behavior than the server behavior and is unlikely to be met, except in very constrained environments. Perhaps only server performance characteristics is meant? This raises a question of resolving competing policies amongst servers shared by multiple owners. > > RATIONALE: Target Applications can rely on control of resources on a > per-remote-client or per-data basis. For example, application > policy may indicate that certain remote clients have a higher > bandwidth share for receiving data [LLSB08]. Additionally, > certain data (e.g., chunks) may be distributed with a higher > priority. As another example, when allowing a remote client to > write data to a user's in-network storage, the remote client may > > > > Gu, et al. Expires May 3, 2012 [Page 14] > > Internet-Draft DECADE Requirements October 2011 > > > be restricted to write only a certain amount of data. Since the > client may need to manage multiple clients accessing its data, it > should be able to indicate the time over which the granted > resources are usable. For example, an expiration time for the > access could be indicated to the server after which no resources > are granted (e.g., indicate error as access denied). > > 4.6.3. Server Involvement > > REQUIREMENT(S): A DECADE client SHOULD be able to indicate to a > DECADE server, without itself contacting the server, resource > control policies for remote clients' requests. This appears to require some sort of unstated infrastructure, which is likely to reduce to having the client contact the server "indirectly". In any event, it is not obvious what this requirement really does mean, in technical terms. > > RATIONALE: One important consideration for in-network storage > elements is scalability, since a single storage element may be > used to support many users. Many Target Applications use small > chunk sizes and frequent data exchanges. If such an application > employed resource control and contacted the in-network storage > element for each data exchange, this could present a scalability > challenge for the server as well as additional latency for > clients. > > Our preferred alternative is to let requesting users obtain > signed resource control policies (in the form of a token) from signed -> assigned (?) > the owning user, and then users can then present the policy to > the storage directly. This can result in reduced messaging > handled by the in-network storage. So the architectural point is that a data owner mediates interactions between other consumers and the storage server? However the stated requirement and the given rational appear to cover conflicting scenarios. Perhaps I'm confusing which actors are doing what. A diagram might help. > > 4.7. Authorization > > 4.7.1. Per-Remote-Client, Per-Data Read Access > > REQUIREMENT(S): A DECADE Client MUST be able to control which > individual remote clients are authorized to read particular data > from its in-network storage. How is this different from 4.6.2? Why are they in different sections? > > RATIONALE: A Target Application can control certain application- > level policies by sending particular data (e.g., chunks) to > certain remote clients. It is important that remote clients not > be able to circumvent such decisions by arbitrarily reading any > data in in-network storage. > > 4.7.2. Per-User Write Access When requirements are only tiny variants of each other, listing them separately inflates the document unnecessarily. Instead, make a single requirement that cover the variants together. > > > > > > > > Gu, et al. Expires May 3, 2012 [Page 15] > > Internet-Draft DECADE Requirements October 2011 > > > REQUIREMENT(S): A DECADE Client MUST be able to control which > individual remote clients are authorized to write data into its > in-network storage. > > RATIONALE: The space managed by a user in in-network storage can be > a limited resource. At the same time, it can be useful to allow > remote clients to write data directly to a user's in-network > storage. Thus, a DECADE client should be able to grant only > certain remote clients this privilege. > > 4.7.3. Default Access Permissions > > REQUIREMENT(S): Unless read or write access is granted by a DECADE > Client to a remote client, the default access MUST be no access. This seems to mean that it is not possible to declare some data as fully public like a web page, so that it is available to whatever client attempts to consume it? > > RATIONALE: The current leading proposal for an access control model > in DECADE is via token passing, resulting in a system with little > state on the server side. > > 4.7.4. Authorization Checks > > REQUIREMENT(S): In-network storage MUST check the authorization of a > client before it executes a supplied request. The in-network > storage MAY use optimizations to avoid such authorization checks > as long as the enforced permissions are the same. In formal terms, I suspect that optimizations are, themselves, a form of authorization check. That is, I suspect this Requirement isn't quite stating the actual requirement. > RATIONALE: Authorization granted by a DECADE client are meaningless are -> is (?) > unless unauthorized requests are denied access. Thus, the in- > network storage element must verify the authorization of a > particular request before it is executed. > > 4.7.5. Cryptographic Credentials > > REQUIREMENT(S): Access MUST be able to be granted using > cryptographic credentials. This appears to be universally mandating a very heavyweight security model that has little-to-no large-scale deployment over the open Internet... Perhaps 'cryptographic credentials' means something other than a PKI? > RATIONALE: DECADE clients may be operating on hosts without constant > network connectivity or without a permanent attachment address > (e.g., mobile devices). To support access control with such > hosts, DECADE servers must support access control policies that > use cryptographic credentials, not simply by tying access to IP > addresses. Hmmm. I think the requirement that is intended here is that requests must contain their own authorization? In addition the requirement is that the authorization be based on cryptography? Why this latter requirement? Aren't there any scenarios that can be satisfied with something simpler? Also, the concern for a history of a scalable mechanism that satisfies this seems to be problematic. > 4.7.6. Server Involvement > > > > > > > > Gu, et al. Expires May 3, 2012 [Page 16] > > Internet-Draft DECADE Requirements October 2011 > > > REQUIREMENT(S): A DECADE client SHOULD be able to indicate, without > contacting the server itself, access control policies for remote > clients' requests. > > RATIONALE: See discussion in Section 4.6.3. Exactly. So how is this different and why is it in a separate section? > 4.7.7. Protocol Reuse > > REQUIREMENT(S): If possible, DECADE SHOULD reuse existing protocol > and mechanisms for Authentication, Access, and Authorization > (AAA). Isn't this requirement more universal than for AAA? Doesn't it cover all DECADE protocols? > RATIONALE: If possible, reusing an existing AAA protocol/mechanism > will minimize the development required by applications, and will > maximize interoperability of the DECADE protocol with existing > infrastructure. > > 4.8. Non-Requirements > > 4.8.1. Application-defined Properties and Metadata > > REQUIREMENT(S): DECADE MUST NOT provide a mechanism for associating > Application-defined properties (metadata) with data objects > beyond what is provided by Section 4.4.2. > > RATIONALE: Associating key-value pairs that are defined by Target > Applications with data objects introduces substantial complexity > to the DECADE protocol. If Target Applications wish to associate > additional metadata with a data object, possible alternatives > include (1) managing such metadata within the Target Application > itself, (2) storing metadata inside of the data object, or (3) > storing metadata in a different data object at the DECADE server. While the suggested alternatives do seem the better approach, it's not clear to me that the prohibited feature is all that onerous. Given the requirement of 4.4.2, why isn't it reasonably straightforward to expand the capability to cover application metadata? An example of possible benefit for this would be a common way for applications to associate operational metadata that the handling system could use, without the handling system having to know anything about the nature of the application... > > 5. Storage Requirements > > This section details the requirements of the underlying storage used > to support the DECADE protocol(s). > > 5.1. Immutable Data > > REQUIREMENT(S): DECADE MUST only store and manage data objects that > are immutable once they are written to storage. No javascript in the data? No web pages that include external data? Perhaps "immutable " needs to be defined precisely? > > RATIONALE: Immutable data objects are an important simplification in > DECADE. Reasonable consistency models for updating existing > objects would significantly complicate implementation (especially > if implementation chooses to replicate data across multiple > > > > Gu, et al. Expires May 3, 2012 [Page 17] > > Internet-Draft DECADE Requirements October 2011 > > > servers). If a user needs to update a resource, it can write a > new resource and then distribute the new resource instead of the > old one. > > 5.2. Explicit Deletion of Data > > REQUIREMENT(S): DECADE MUST support the ability for a DECADE client > to explicitly delete data from its own in-network storage. > > RATIONALE: A DECADE client may continually be writing data to its > in-network storage. Since there may be a limit (e.g., imposed by > the storage provider) to how much total storage can be used, some > data may need to be removed to make room for additional data. A > DECADE client should be able to explicitly remove particular > data. This may be implemented using existing protocols. > > 5.3. Multiple writing > > REQUIREMENT(S): DECADE MUST NOT allow multiple simultaneous writers > for the same object. Implementations MUST raise an error to one > of the writers. 1. This implies a locking mechanism? 2. This implies that writes are not atomic? What is the implied model that permits multiple writers? Different ones are possible. > > RATIONALE: This avoids data corruption in a simple way while > remaining efficient. Alternately, the DECADE server would need > to either manage locking, handle write collisions, or merge data, > all of which reduce efficiency and increase complexity. > > 5.4. Multiple reading > > REQUIREMENT(S): DECADE MUST allow for multiple simultaneous readers > for an object. > > RATIONALE: One characteristic of Target Applications is the ability > to upload an object to multiple clients. Thus, it is natural for > DECADE to allow multiple readers to read the content > concurrently. > > 5.5. Reading before completely written > > REQUIREMENT(S): DECADE MAY allow readers to read from objects before > they have been completely written. Like playing a show on a DVR before the show has finished broadcast?... > RATIONALE: Some Target Applications (in particular, P2P streaming) > can be sensitive to latency. A technique to reduce latency is to > remove store-and-forward delays for data objects (e.g., make the > object available before it is completely written). Appropriate > handling for error conditions (e.g., a disappearing writer) needs > to be specified. > > > > Gu, et al. Expires May 3, 2012 [Page 18] > > Internet-Draft DECADE Requirements October 2011 > > > 5.6. Hints concerning usage of written data > > REQUIREMENT(S): DECADE MAY allow writers of new objects to indicate > specific hints concerning how the objects are expected to be used > (e.g., access frequency or time-to-live). Isn't this the same as 4.4.2 or one of the other requirements that refers to TTL? Also, what is the set of 'hints'? Where are/will they be defined? It's difficult to think of TTL as a 'hint'. > RATIONALE: Different Target Applications may have different usage > patterns for objects written to in-network storage. For example, > a P2P live streaming application may indicate to a DECADE server > that the objects are expected to have a short time-to-live, but > read frequently. The DECADE server may then opt to persist the > objects in memory instead of in disk. > > 5.7. Writing model > > REQUIREMENT(S): DECADE storage MUST provide at least a writing model > (while writing an object) that appends data to data already > written. provide at least a writing model...that appends -> provide a writing model... that at least appends (?) > > RATIONALE: Depending on the object size (e.g., chunk size) used by a > Target Application, the application may need to send data to the > DECADE server in multiple packets. To keep implementation > simple, the DECADE must at least support the ability to write the > data sequentially in the order received. Implementations MAY > allow application to write data in an object out-of-order (but > MUST NOT overwrite ranges of the object that have already been > written). > > 5.8. Storage Status > > REQUIREMENT(S): A DECADE client MUST be able to read current > resource usage (including list of written data objects), resource > quotas, and access permissions for its in-network storage. The > returned information MUST include resource usage resulting from > the client's own usage and usage by other clients that have been > authorized to read/write objects or open connections to that > client's storage. DECADE protocol(s) MUST support the ability > for a DECADE client to read aggregated resource usage information > (across all other clients to which it has authorized access), and > MAY support the ability to request this information for each > other authorized client. > > RATIONALE: The resources used by a client are not directly-attached > (e.g., disk, network interface, etc). Thus, the client cannot > locally determine how such resources are being used. Before > storing and retrieving data, a client should be able to determine > which data is available (e.g., after an application restart). > Additionally, a client should be able to determine resource > > > > Gu, et al. Expires May 3, 2012 [Page 19] > > Internet-Draft DECADE Requirements October 2011 > > > availability to better allocate them to remote clients. Due to > scalability issues, it is not required that DECADE support > returning usage information broken down by each remote client > which has been authorized access, but this feature may be useful > in certain deployment scenarios. > > > 6. Discovery Requirements > > 6.1. Requirements > > 6.1.1. Locating DECADE Servers > > REQUIREMENT(S): The DECADE Discovery mechanism MUST allow a DECADE > Client to identify one or more DECADE Servers to which it is > authorized to read/write data and to which it may authorize other > DECADE Clients to read/write data, or fail if no such DECADE > Servers are available. Every consumer must be able to redistribute the information or otherwise act as an administrator for access to the information? That seems an onerous requirement to have as a MUST. > > RATIONALE: A basic goal of DECADE is to allow DECADE Clients to > read/write data for access by other DECADE Clients or itself. > Executing the Discovery process should result in a DECADE Client > finding a DECADE Server that it can use for these purposes. It > is possible that no such DECADE Servers are available. Note that > even if a DECADE Client may not successfully locate a DECADE > Server that fits these criteria, it may still read/write data > from/to a DECADE Server if authorized by another DECADE Client. > > 6.1.2. Support for Clients Behind NATs and Firewalls > > REQUIREMENT(S): The Discovery mechanism MUST support DECADE Clients > operating behind NATs and Firewalls without requiring additional > network support (e.g., Application-level Gateways). > > RATIONALE: NATs and Firewalls are prevalent in network deployments, > and it is common for Target Applications that include a DECADE > Client to be deployed behind these devices. How is this different from 4.1.1.1? Why is it separated from that requirement? > 6.1.3. Prefer Existing Protocols > > REQUIREMENT(S): The DECADE Server discovery mechanism SHOULD > leverage existing mechanisms and protocols wherever possible. > > RATIONALE: Existing protocols such as DNS and DHCP are widespread. > Using existing protocols, or combinations of the protocols that > have been specified in other contexts, is strictly preferred over > developing a new discovery protocol for DECADE. > > > > > Gu, et al. Expires May 3, 2012 [Page 20] > > Internet-Draft DECADE Requirements October 2011 > > > 7. Future Considerations > > This section enumerates considerations that should be taken into > account during the DECADE design and implementation. They have been In other words, these are /current/ design considerations... > intentionally omitted as requirements since they are either out of > scope or implementation-dependent. Nevertheless, enumerating them > may help to guide future application of the requirements included in > this document. > > 7.1. Fairness > > To provide fairness among users, the in-network storage provider > should assign resource (e.g., storage, bandwidth, connections) quota > for users. This can prevent a small number of clients from occupying > large amounts of resources on the in-network storage, while others > starve. There are many approaches to fairness. A quota system is only one. What is the basis for choosing this? > 7.2. Removal of Duplicate Data Objects > > There are actually two possible scenarios. The first is the case of > removing duplicates within one particular DECADE server (or logical > server). While not a requirement, as it does not impact the > protocol, a DECADE server may implement internal mechanisms to > monitor for duplicate objects and use internal mechanisms to prevent > duplication in internal storage. > > The second scenario is removing duplicates across a distributed set > of DECADE servers. DECADE does not explicitly design for this, but > does offer a redirection mechanism (Section 4.1.3.5) that is one > primitive that may be used to support this feature in certain > deployment scenarios. > > 7.3. Gaming of the Resource Control Mechanism > > The particular resource control policy communicated by a DECADE > protocol and enforced by the scheduling system of a DECADE > implementation may be open to certain gaming by clients. for example > by specifying many small peers to increase total throughput or > inciting overload conditions at a DECADE server. Identifying and > protecting against all such opportunities for gaming is outside the > scope of this document, but DECADE protocol(s) and implementations > SHOULD be aware that opportunities to game the system may be > attempted. > > > 8. Security Considerations > > The security model is an important component of DECADE. It is > > > > Gu, et al. Expires May 3, 2012 [Page 21] > > Internet-Draft DECADE Requirements October 2011 > > > crucial for users to be able to manage and limit distribution of > content to only authorized parties, and the mechanism needs to work > on the general Internet which spans multiple administrative and > security domains. Previous sections have enumerated detailed > requirements, but this section discusses the overall approach and > other considerations that do not merit requirements. > > 8.1. Authentication and Authorization > > DECADE only uses authentication when allowing a particular client to > access its own storage at a server. DECADE servers themselves do not > authenticate other clients which are reading/writing a client's own > storage. Instead, DECADE relies on clients to authenticate others to > access its storage, and then communicate the result of that > authentication to the DECADE server so that the DECADE server may > implement the necessary authorization checks. Decade apparently also will not authenticate the data producer? or the data author? > 8.2. Encrypted Data > > DECADE Servers provide the ability to write raw data objects (subject > to any policies instituted by the owner/administrator of the DECADE > server, which are outside of the scope of this document). Thus, > DECADE clients may opt to encrypt data before it is written to the > DECADE Server. However, DECADE itself does not provide encryption of > data objects other than is provided by Section 4.1.2.1. I believe the correct security term for this is "Confidentiality", parallel to "Authentication". Encryption is merely a technique for performing confidentiality. Also, this assumes that client and server use the same confidentiality schemes. As a rule, these need to be specified as part of the service definition. -- Dave Crocker Brandenburg InternetWorking bbiw.net From dcrocker@bbiw.net Thu Mar 22 03:48:38 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAB6521F86AA; Thu, 22 Mar 2012 03:48:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.117 X-Spam-Level: X-Spam-Status: No, score=-4.117 tagged_above=-999 required=5 tests=[AWL=1.414, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uikEXN51rdgO; Thu, 22 Mar 2012 03:48:37 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6A38B21F86A7; Thu, 22 Mar 2012 03:48:37 -0700 (PDT) Received: from [192.168.8.65] (ter75-1-81-57-68-77.fbx.proxad.net [81.57.68.77]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id q2MAmSYW004974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Mar 2012 03:48:35 -0700 Message-ID: <4F6A96A5.3070608@bbiw.net> Date: Thu, 22 Mar 2012 04:04:05 +0100 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: apps-discuss@ietf.org, draft-ietf-decade-problem-statement.all@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Thu, 22 Mar 2012 03:48:37 -0700 (PDT) Cc: iesg Subject: [apps-discuss] Review of: draft-ietf-decade-problem-statement-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 22 Mar 2012 10:48:38 -0000 I have been selected as the Applications Area Directorate reviewer for this draft: (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). Document: draft-ietf-decade-problem-statement-05 Title: DECoupled Application Data Enroute (DECADE) Problem Statement Reviewer: D. Crocker Review Date: 22 March 2012 Summary: This draft needs substantial work, due to ambiguous terminology and a lack of technical detail. The document serves as an initial statement of the problem(s) that a DECADE protocol will solve. If I understand that problem correctly, it concerns creation of a standardized caching protocol, in order to gain performance and network efficiencies when a collection of content consumers are topologically near. Proprietary caching already exists, but the current effort is to develop an open specification. Major Issues: The document suffers a number of significant problems. Caches are useful. It seems obvious that they would be useful for the types of configurations that the working group intends to cover. It also seems that stating that basic pint as a 'problem' requires no more than a few sentences, or at most a few paragraphs. The interesting parts of the problem are the technical details and constraints that are specific to the current effort. The document is deficient with respect to its assumptions and its details. The issue is not whether caching can be useful. It's that the engineering issues about this particular environment are not stated or explored. The document assumes that the reader already know the meanings and implications of a number of terms of art, since they are used heavily but not really explained. (I also suspect that some of the terms do not have the kind of widespread, rigorous technical definitions that one would like.) The document needs to define these terms and the definitions need to be sufficient to help the reader understand what possible cases are excluded, not just those that are included. In addition, the document could benefit from using some different terms, such as producer (or provider) and consumer, rather than 'peer'. For a given type of activity or role, the terminology should clearly distinguish one actor from another and the terminology should be terse. And roles change. For example for BitTorrent, a machine that is initially a consumer, when receiving the document, then becomes a provider as other machines consume copies from it. I also was sometimes confused about the relationships between the cache and producers or consumers. It is unclear which actor needs what control over which caches. More seriously, the problem statement only has superficial technical content, as summarized above. It states things redundantly, but does not elaborate. It needs much great technical depth in order to guide requirements and protocol choices. For example, what sorts of usage scenarios are to be covered? The included examples of BitTorrent and Content Distribution are offered more as functional tags than as networking technical scenarios. What sort of related scenarios will not be covered and why? I'll include my usual suggestion that diagrams for this sort of thing could help quite a bit. Detailed comments: > 2. Terminology and Concepts > > The following terms have special meaning in the definition of the in- > network storage system. > > in-network storage: A service inside a network that provides > storage and bandwidth to network applications. In-network storage > may reduce upload/transit/backbone traffic and improve network > application performance. The problem with this definition is that the most obvious meaning of 'in network' is wrong and the correct meaning is not provided. For example, I suspect it has nothing to do with routers. And certainly nothing with the contents or code of routers. In reality, the model being espoused sounds quite a bit like what we are used to for the DNS and possibly similar to common Web arrangements. I strongly urge discussion of these two explicitly, though probably in the requirements documents, since that moves more towards solution than problem statement. I suspect that "in network" merely means 'in the query/response handling sequence between consumer and provider.' > P2P cache (Peer to Peer cache): A kind of in-network storage that > understands the signaling and transport of specific P2P > application protocols. It caches the content for those specific > P2P applications in order to serve peers and reduce traffic on > certain links. The problem with this definition is that P2P is not defined. It needs to be, since the term is at the core of the stated problem-space. Use technical terms that distinguish it from other kinds of applications. How is P2P different from email, web, DNS or anything else? The definition should be sufficient to tell what qualifies as P2P and what doesn't. > 3. The Problems > > The emergence of peer-to-peer (P2P) as a major network application > (especially P2P file sharing and streaming) has led to substantial > opportunities. The P2P paradigm can be utilized to design highly > scalable and robust applications at low cost, compared to the > traditional client-server paradigm. For example, CNN reported that > P2P streaming by Octoshape played a major role in its distribution of > the historic inauguration address of President Obama[Octoshape]. > PPLive, one of the largest P2P streaming vendors, is able to > distribute large-scale, live streaming programs to more than 2 > million users with only a handful of servers [PPLive]. > > However, P2P applications also face substantial design challenges. A > particular problem facing P2P applications is the additional stress > that they place on the network infrastructure. Furthermore, lack of > infrastructure support can lead to unstable P2P application > performance during peer churns and flash crowds, when a large group > of users begin to retrieve the content during a short period of time. > These problems are now discussed in further detail. > > 3.1. P2P infrastructural stress and inefficiency > > A particular problem of the P2P paradigm is the stress that P2P > application traffic places on the infrastructure of Internet service > providers (ISPs). Multiple measurements (e.g., [Internet Study 2008/ > 2009][Internet_Study_2008-2009]) have shown that P2P traffic has > become a major type of traffic on some networks. Furthermore, the > inefficiency of network-agnostic peering (at the P2P transmission > level) leads to unnecessary traversal across network domains or > spanning the backbone of a network [RFC5693]. > > > > Song, et al. Expires August 11, 2012 [Page 4] > > Internet-Draft DECADE Problem Statement February 2012 > > > Using network information alone to construct more efficient P2P > swarms is not sufficient to reduce P2P traffic in access networks, as "swarms"? this probably needs a technical definition, since it points towards the implied technical solution that is being proposed. Again, there is an implied underlying architecture here that is not stated, yet is fundamental to the assumptions and proposals of the work. > the total access upload traffic is equal to the total access download > traffic in a traditional P2P system. On the other hand, it is > reported that P2P traffic is becoming the dominant traffic on the > access networks of some networks, reaching as high as 50-60% on the > downlinks and 60-90% on the uplinks ([DCIA], [ICNP], > [ipoque.P2P_survey.], [P2P_file_sharing]). Consequently, it becomes > increasingly important to reduce upload access traffic, in addition > to cross-domain and backbone traffic. > > The inefficiency is also represented when traffic is sent upstream as I have no idea what 'upstream' or 'downstream' mean in this context. Does it mean from provider to consumer? Or perhaps it's a query, going from consumer to provider? > many times as there are remote peers interested in getting the > corresponding information. For example, the P2P application transfer > completion times remain affected by potentially (relatively) slow > upstream transmission. Similarly, the performance of real-time P2P > applications may be affected by potentially (relatively) higher > upstream latencies. transit latencies. up-vs-down is irrelevant. I'm also not 100% convinced that 'latency' is the precisely correct technical concern. From a practical standpoint, although caching is an obvious and generally helpful method of improving the performance concerns being raised here, not that congestion is often worst at leaf portions of a network and caching doesn't fix that. > 3.2. P2P cache: a complex in-network storage > An effective technique to reduce P2P infrastructural stress and > inefficiency is to introduce in-network storage. > > In the current Internet, in-network storage is introduced as P2P > caches, either transparently or explicitly as a P2P peer. To provide > service to a specific P2P application, the P2P cache server must > support the specific signaling and transport protocols of the > specific P2P application. This can lead to substantial complexity > for the P2P Cache vendor. > > First, there are many P2P applications on the Internet (e.g., > BitTorrent, eMule, Flashget, and Thunder for file sharing; Abacast, > Kontiki, Octoshape, PPLive, PPStream, and UUSee for P2P streaming). > Consequently, a P2P cache vendor faces the challenge of supporting a > large number of P2P application protocols, leading to product > complexity and increased development cost. > > Furthermore, a specific P2P application protocol may evolve > continuously, to add new features or fix bugs. This forces a P2P > cache vendor to continuously update to track the changes of the P2P > application, leading to product complexity and increased costs. While I can imagine that this is true, I am pretty sure that it is not automatically true. Does the creation of a new DNS RR type automatically requirement enhancement of DNS caches? I suspect it does only for overly knowledgeable caches. > Third, many P2P applications use proprietary protocols or support > end-to-end encryption. This can render P2P caches ineffective. > > Finally, a P2P cache is likely to be much better connected to end > hosts than to remote peers. Without the ability to manage bandwidth "end hosts"? "remote peers"? this statement is probably important and therefore should assume less. it needs to explain itself /much/ better. > 4.1. BitTorrent > > When a BitTorrent client A uploads a block to multiple peers, the > block traverses the last-mile uplink once for each peer. And after > that, the peer B who just received the block from A also needs to > upload through its own last-mile uplink to others when sharing this > block. This is not an efficient use of the last-mile uplink. With > in-network storage server however, the BitTorrent client may upload > the block to its in-network storage. Peers may retrieve the block > from the in-network storage, reducing the amount of data on the last- "its"? any given producer of content (the one doing the 'uploading') is supposed to know about all of the caches near "swarms" of consumers? Note that this also means knowing about the swarms. And all these producers are supposed to have administrative rights for 'controlling' those caches? > > Song, et al. Expires August 11, 2012 [Page 6] > > Internet-Draft DECADE Problem Statement February 2012 > > > mile uplink. If supported by the in-network storage, a peer can also > save the block in its own in-network storage while it is being > retrieved; the block can then be uploaded from the in-network storage > to other peers. It occurs to me that having infrastructure support, such as a cache, would seem to be at odds with the basic philosophy of BitTorrent, which is entirely about having ad hoc, consumer machines used for the functionality. Rather than defining an infrastructure caching service, I'd expect the Bit Torrent protocols to support similar functionality in the consumer machines... > As previously discussed, BitTorrent or other P2P applications > currently cannot explicitly manage which content is placed in the > existing P2P caches, nor can they manage access and resource control > polices. Applications need to retain flexibility to control the > content distribution policies and topology among peers. > > 4.2. Content Publisher > > Content publishers may also utilize in-network storage. For example, > consider a P2P live streaming application. A Content Publisher > typically maintains a small number of sources, each of which > distributes blocks in the current play buffer to a set of the P2P > peers. > > Some content publishers use another hybrid content distribution > approach incorporating both P2P and CDN modes. As an example, Modes? What does this mean? > Internet TV may be implemented as a hybrid CDN/P2P application by > distributing content from central servers via a CDN, and also > incorporating a P2P mode amongst endhosts and set-top boxes. In- > network storage may be beneficial to hybrid CDN/P2P applications as > well to support P2P distribution and to enable content publisher > standard interfaces and controls. > > However, there is no standard interface for different content > publishers to access in-network storage. One streaming content > publisher may need the existing in-network storage to support > streaming signaling or such capability, such as transcoding > capability, bitmap information, intelligent retransmission, etc, > while a different content publisher may only need the in-network > storage to distribute files. However it is reasonable that the > application services are only supported by content publisher's > original servers and clients, and intelligent data plane transport > for those content publishers are supported by in-network storage. > > A content publisher also benefits from a standard interface to access > in-network storage servers provided by different providers. The > standard interface must allow the content publisher to retain control > over content placed in their own in-network storage, and grant access > and resources only to the desired endhosts and peers. > > In the hybrid CDN/P2P scenario, if only the endhosts can store I don't know what this 'hybrid' scenario is? There needs to be a statement of the actual technical and/or operational details that make it a hybrid. There should be a discussion of the differences between BitTorrent and Content Provider models, to highlight what problems are shared between them and what problems are specific to them. > content in the in-network storage server, the content must be > downloaded and then uploaded over the last-mile access link before > > > > Song, et al. Expires August 11, 2012 [Page 7] > > Internet-Draft DECADE Problem Statement February 2012 > > > another peer may retrieve it from a in-network storage server. Thus, > in this deployment scenario, it may be advantageous for a content > publisher or CDN provider to store content in in-network storage > servers. > > > 5. Security Considerations Good discussion. There is probably an accidental security risk from scaling possibilities. I'm imagining that having every BitTorrent content host dictating the policies of a cache is likely to have serious scaling problems that wind up constituting a de facto DOS attack. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From evnikita2@gmail.com Thu Mar 22 11:51:54 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D226B21F8584 for ; Thu, 22 Mar 2012 11:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.291 X-Spam-Level: X-Spam-Status: No, score=-2.291 tagged_above=-999 required=5 tests=[AWL=-1.143, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ulQVVkVVL7G2 for ; Thu, 22 Mar 2012 11:51:54 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id DC3CE21F857D for ; Thu, 22 Mar 2012 11:51:53 -0700 (PDT) Received: by ghbg16 with SMTP id g16so2312204ghb.31 for ; Thu, 22 Mar 2012 11:51:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ijFECUGgTMzwQRfmWxSc2mO5PCMmNsAFw3fOsAwuDxA=; b=yIQMZbtU6SfmNCn9bufb8JymNoaDDHBIJi4hzdz+uFEg1Bm/deaXwqiJjyAwacvweL I6V2I9Ag9ZY2puza74RCrLCuX95uhZi1oOeTOPrxO0Y67DtqU0GTYn0ns10MtKDgWvLb BeYBmQxGoLApfYgku6uR2bMxR/fupLXSBfQa4nnvJzJOGIQFGJyIBSGeyzjpnVm+w2eN clRvWpPMWz6Mb4JyiidWdzTAM4AO0P0vUlj9hCEYQpf2tfWyRqUrSZcDSUmAS1o03RCA 4IhuqO/vFVWG9aBfQYZBwg9CddbElc7jxfjp3qWuKjO8ZQ8L4E1c/go2ao53W3FFdHY/ A53g== MIME-Version: 1.0 Received: by 10.182.11.100 with SMTP id p4mr11259016obb.63.1332442313271; Thu, 22 Mar 2012 11:51:53 -0700 (PDT) Received: by 10.182.60.1 with HTTP; Thu, 22 Mar 2012 11:51:53 -0700 (PDT) In-Reply-To: References: <503575970.11554@cnnic.cn> <4A10020DB6464A0BBA535BF75D21A9D9@LENOVO47E041CF> <9452079D1A51524AA5749AD23E003928094CEB@exch-mbx901.corp.cloudmark.com> <4F6978D8.10605@gmx.de> Date: Thu, 22 Mar 2012 20:51:53 +0200 Message-ID: From: Mykyta Yevstifeyev To: Barry Leiba Content-Type: multipart/alternative; boundary=f46d04462eccc42b6704bbd96603 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Use of RFC 2119, Re: WGLC: draft-ietf-appsawg-about-uri-scheme-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 22 Mar 2012 18:51:54 -0000 --f46d04462eccc42b6704bbd96603 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable So all, I've emailed the new version with issues raised in WGLC considered to internet-drafts@ietf.org, Secretariat and cc'ed Pete as sponsoring AD. I'm waiting for some reaction from the Secretariat. Mykyta Yevstifeyev 21 =CD=C1=D2=D4=C1 2012 =C7. 16:19 =D0=CF=CC=D8=DA=CF=D7=C1=D4=C5=CC=D8 Bar= ry Leiba =CE=C1=D0=C9=D3=C1=CC: > I said... > >> I'm sure. And it's my text -- this is one that Mykyta doesn't like. > >> The three MUSTs in there are not directed at IANA, but at people > >> writing new registrations. They tell those people what their > >> registrations have to look like, and I wanted to use MUST to stress > >> that even though this is an FCFS policy, there are requirements > >> nonetheless. > > Julian says... > > I'm with Murray here. This is something RFC 2119 keywords are not for. > > OK... and given the conversations that Pete and I have had recently > (we're both in favour of less unnecessary all-caps 2119 stuff), I > think a change is appropriate. Let's lower-case (or remove) those > three "MUST"s (and there are three others that are already in lower > case, which is fine). > > Section 4.2: > OLD > The registry entries consist of 3 fields: Special-Purpose Token, > Description and Reference. The Special-Purpose Token field MUST > conform to production defined in Section 2.1. > NEW > The registry entries consist of 3 fields: Special-Purpose Token, > Description and Reference. The Special-Purpose Token field > conforms to the production defined in Section 2.1. > > OLD > The registration procedures for this registry are "First Come First > Served", described in RFC 5226 [RFC5226], with supporting > documentation meeting the requirements below. The registrant of the > token MUST provide the following registration template, which will be > made available on IANA web site: > NEW > The registration procedures for this registry are "First Come First > Served", described in RFC 5226 [RFC5226], with supporting > documentation meeting the requirements below. The registrant of the > token must provide the following registration template, which will be > made available on IANA web site: > > OLD > o Specification. This provides documentation at a level that could > be used to create a compliant, interoperable implementation of the > registered "about" URI. The reference to a full specification MUST > be provided here, and there should be a reasonable expectation that > the documentation will remain available. > NEW > o Specification. This provides documentation at a level that could > be used to create a compliant, interoperable implementation of the > registered "about" URI. The reference to a full specification must > be provided here, and there should be a reasonable expectation that > the documentation will remain available. > > Mykyta, please note those changes, address Murray's other comments, > and push out a new rev of the draft (email TXT and XML to > internet-drafts@ietf.org and CC appsawg-ads@tools.ietf.org to get > permission). > > Barry > --f46d04462eccc42b6704bbd96603 Content-Type: text/html; charset=KOI8-R Content-Transfer-Encoding: quoted-printable So all,

I've emailed the new version with issues raised in WGLC = considered to internet-drafts@i= etf.org, Secretariat and cc'ed Pete as sponsoring AD.=9A I'm wa= iting for some reaction from the Secretariat.

Mykyta Yevstifeyev

21 =CD=C1=D2=D4=C1= 2012=9A=C7. 16:19 =D0=CF=CC=D8=DA=CF=D7=C1=D4=C5=CC=D8 Barry Leiba <barryleiba@comput= er.org> =CE=C1=D0=C9=D3=C1=CC:
I said...
>> I'm sure. =9AAnd it's my text -- this is one that Mykyta d= oesn't like.
>> The three MUSTs in there are not directed at IANA, but at people >> writing new registrations. =9AThey tell those people what their >> registrations have to look like, and I wanted to use MUST to stres= s
>> that even though this is an FCFS policy, there are requirements >> nonetheless.

Julian says...
> I'm with Murray here. This is something RFC 2119 keywords are not = for.

OK... and given the conversations that Pete and I have had recently
(we're both in favour of less unnecessary all-caps 2119 stuff), I
think a change is appropriate. =9ALet's lower-case (or remove) those three "MUST"s (and there are three others that are already in low= er
case, which is fine).

Section 4.2:
OLD
=9A The registry entries consist of 3 fields: Special-Purpose Token,
=9A Description and Reference. =9AThe Special-Purpose Token field MUST
=9A conform to <about-token> production defined in Section 2.1.
NEW
=9A The registry entries consist of 3 fields: Special-Purpose Token,
=9A Description and Reference. =9AThe Special-Purpose Token field
=9A conforms to the <about-token> production defined in Section 2.1.=

OLD
=9A The registration procedures for this registry are "First Come Fir= st
=9A Served", described in RFC 5226 [RFC5226], with supporting
=9A documentation meeting the requirements below. =9AThe registrant of the=
=9A token MUST provide the following registration template, which will be<= br> =9A made available on IANA web site:
NEW
=9A The registration procedures for this registry are "First Come Fir= st
=9A Served", described in RFC 5226 [RFC5226], with supporting
=9A documentation meeting the requirements below. =9AThe registrant of the=
=9A token must provide the following registration template, which will be<= br> =9A made available on IANA web site:

OLD
=9A o Specification. =9AThis provides documentation at a level that could<= br> =9A =9A be used to create a compliant, interoperable implementation of the=
=9A =9A registered "about" URI. =9AThe reference to a full speci= fication MUST
=9A =9A be provided here, and there should be a reasonable expectation tha= t
=9A =9A the documentation will remain available.
NEW
=9A o Specification. =9AThis provides documentation at a level that could<= br> =9A =9A be used to create a compliant, interoperable implementation of the=
=9A =9A registered "about" URI. =9AThe reference to a full speci= fication must
=9A =9A be provided here, and there should be a reasonable expectation tha= t
=9A =9A the documentation will remain available.

Mykyta, please note those changes, address Murray's other comments,
and push out a new rev of the draft (email TXT and XML to
internet-drafts@ietf.org an= d CC appsawg-ads@tools.ietf.o= rg to get
permission).

Barry

--f46d04462eccc42b6704bbd96603-- From walter.stanish@gmail.com Thu Mar 22 19:49:16 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 293AF21F8466 for ; Thu, 22 Mar 2012 19:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.813 X-Spam-Level: X-Spam-Status: No, score=-2.813 tagged_above=-999 required=5 tests=[AWL=0.486, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DAoUiXFUBx4P for ; Thu, 22 Mar 2012 19:49:15 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3F11C21F8464 for ; Thu, 22 Mar 2012 19:49:15 -0700 (PDT) Received: by ggmi1 with SMTP id i1so2683818ggm.31 for ; Thu, 22 Mar 2012 19:49:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=B8mOzw48j5YP92e/JT5q6oFJUA7o9S5zzOQgDrR+DBk=; b=BdJ7ibNLbJApNsuEkMUCrb/pAiKggd1fcliZE8CmTekTu1zBm6XnPl2gsJVZBugeHR INeK83/NAYuoQC15ebDpevEikQqs/nXEnAv320OVuRjL2AQX23Fk389+oTJ+vuNmZjS6 T3jTX7lvdlHJ31yNDutPsdJ7s7UZpDpRDxPQ4C5V3VyWWJCQ8ZGNg7vIBRJZEhNgqQDZ yIvW/LFDgD0G5dYLj6nQ+stfH+2c2WvgCcTT7c4Eom6Nux1Qv0XEA2U+pw3mPF+NFiXk 3bh5cVzQDqeKVrI1npZvGeRVJAcqro8h89lDN8VUg/3bgMWptNKIO8uFPLc+7ywrac9C ESGw== MIME-Version: 1.0 Received: by 10.60.20.6 with SMTP id j6mr12603987oee.17.1332470954799; Thu, 22 Mar 2012 19:49:14 -0700 (PDT) Received: by 10.60.9.8 with HTTP; Thu, 22 Mar 2012 19:49:14 -0700 (PDT) In-Reply-To: References: <4F5ADDCA.80303@KingsMountain.com> <4F60968D.4020703@stpeter.im> Date: Fri, 23 Mar 2012 09:49:14 +0700 Message-ID: From: Walter To: =?ISO-8859-1?Q?Jorge_Tim=F3n?= Content-Type: text/plain; charset=ISO-8859-1 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Proposal for a Finance Area Mailing List X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 23 Mar 2012 02:49:16 -0000 > Please, let me know if there's any news. I'm going to unsubscribe from > this list for now. Is there any news from Area Managers regarding the status of the creation of the proposed list as previously advised? I have sent two requests for status updates privately but have not had any response. *nudge* Regards, Walter Stanish Payward, Inc. From stpeter@stpeter.im Thu Mar 22 19:56:25 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 667BA21E8042 for ; Thu, 22 Mar 2012 19:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.637 X-Spam-Level: X-Spam-Status: No, score=-102.637 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aXz7rtpdZGFN for ; Thu, 22 Mar 2012 19:56:24 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 64D7221E8032 for ; Thu, 22 Mar 2012 19:56:24 -0700 (PDT) Received: from squire.local (unknown [216.17.175.160]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E36AF40075; Thu, 22 Mar 2012 21:09:12 -0600 (MDT) Message-ID: <4F6BE647.5010704@stpeter.im> Date: Thu, 22 Mar 2012 20:56:07 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Walter References: <4F5ADDCA.80303@KingsMountain.com> <4F60968D.4020703@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= , apps-discuss@ietf.org Subject: Re: [apps-discuss] Proposal for a Finance Area Mailing List X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 23 Mar 2012 02:56:25 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 3/22/12 8:49 PM, Walter wrote: >> Please, let me know if there's any news. I'm going to unsubscribe >> from this list for now. > > Is there any news from Area Managers regarding the status of the > creation of the proposed list as previously advised? > > I have sent two requests for status updates privately but have not > had any response. > > *nudge* Email to your domain is being delayed: : conversation with mail.stani.sh[206.123.115.203] timed out while receiving the initial server greeting This happened to both me and Barry. 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/ iEYEARECAAYFAk9r5kcACgkQNL8k5A2w/vzyyQCglY+GfzIvMu5emz1hnxpRtyBk lioAnAm5Ctrj8nWV+xkOklfcVPRRs/ef =QqzP -----END PGP SIGNATURE----- From walter.stanish@gmail.com Thu Mar 22 21:13:09 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2FF321F848C for ; Thu, 22 Mar 2012 21:13:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.994 X-Spam-Level: X-Spam-Status: No, score=-2.994 tagged_above=-999 required=5 tests=[AWL=0.606, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5uygdXOV+K4r for ; Thu, 22 Mar 2012 21:13:09 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB2B21F848B for ; Thu, 22 Mar 2012 21:13:08 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so2381690obb.31 for ; Thu, 22 Mar 2012 21:13:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xegsgVwyTLCWje3p7l938sxMMnF6XXqypRLDoyVZtRA=; b=ULCuL2on+fFpR2j4V/BLi7M55R98SnWP6AaYXHaAiJydida+BFDhslyZrJl8ESQwZe dtMSVlbbCwt7nsVebfplgoZMAXEU7WNICOaUaX8VkAbG3PwTMaILElbuuJsSA4THi0C9 bE7L+vcXlj4d2dp/WOR+obGOpk6GD/BKv9ea/im47AXgHauu5ilybZ66NBeliNlttI/0 iGyAU9ncOghl+Z1dFmv+4eA3xtGfjMdbQtBqKuGwr0xAHdPjsfeWOWZASSt6JuzYYjjY lek3oXs18g+Iz+VxR1Z96OZx4HvwKP15ZQojH6gvvIg9nenraVjnCrfrPURA2jzcA3NV YE0w== MIME-Version: 1.0 Received: by 10.60.20.6 with SMTP id j6mr12757087oee.17.1332475988564; Thu, 22 Mar 2012 21:13:08 -0700 (PDT) Received: by 10.60.9.8 with HTTP; Thu, 22 Mar 2012 21:13:08 -0700 (PDT) In-Reply-To: <4F6BE647.5010704@stpeter.im> References: <4F5ADDCA.80303@KingsMountain.com> <4F60968D.4020703@stpeter.im> <4F6BE647.5010704@stpeter.im> Date: Fri, 23 Mar 2012 11:13:08 +0700 Message-ID: From: Walter To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Cc: =?ISO-8859-1?Q?Jorge_Tim=F3n?= , apps-discuss@ietf.org Subject: Re: [apps-discuss] Proposal for a Finance Area Mailing List X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 23 Mar 2012 04:13:09 -0000 > Email to your domain is being delayed: Resolved? - Walter From ietfdbh@comcast.net Thu Mar 22 09:51:07 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D65E21F866E for ; Thu, 22 Mar 2012 09:51:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.019 X-Spam-Level: X-Spam-Status: No, score=-102.019 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599, J_CHICKENPOX_62=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tH-VmUsiuiDj for ; Thu, 22 Mar 2012 09:51:07 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by ietfa.amsl.com (Postfix) with ESMTP id 5516021F8679 for ; Thu, 22 Mar 2012 09:50:55 -0700 (PDT) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta01.westchester.pa.mail.comcast.net with comcast id ogow1i0091HzFnQ51gqvXb; Thu, 22 Mar 2012 16:50:55 +0000 Received: from [192.168.1.33] ([71.233.85.150]) by omta14.westchester.pa.mail.comcast.net with comcast id ogqd1i0073Ecudz3agqlo1; Thu, 22 Mar 2012 16:50:55 +0000 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Thu, 22 Mar 2012 12:50:34 -0400 From: David Harrington To: Bhumip Khasnabish , Spencer Dawkins Message-ID: Thread-Topic: [dc] Announcing the i2aex BoF In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Mailman-Approved-At: Fri, 23 Mar 2012 08:09:23 -0700 Cc: apps-discuss@ietf.org, opsawg@ietf.org, cdni@ietf.org, Tsvwg , dc@ietf.org Subject: Re: [apps-discuss] [dc] Announcing the i2aex BoF X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 22 Mar 2012 16:51:07 -0000 Hi Bhumip, Your input would be more helpful if you did the research to answer the question your self and prepared a detailed analysis for the community to review (I.e., write a draft). Is this similar to dmtf's CIMI? I suggest you read the documents on the agenda and read the CIMI spec and compare them to see if they are or are not similar. My experience has been that DMTF works top-down - they tend to develop and abstract architecture first and then encourage implementers to develop detailed specs that fit within the architecture. That sometimes leads to abstract systems that implementers choose not to implement, because the architecture is too all-inclusive, or implementers cherry-pick the features, with the result that different implementations choose different feature sets and then do not interoperate. The IETF uses a bottom-up model; we prefer detailed proposals based on actual experience in the field, and developing highly focused specifications with a small number of mandatory-to-implement features, to ensure cross-vendor interoperation. The result can be messy as compared to a nice top-down architecture, but the IETF has been very successful using this approach, and the Internet community seems to want to keep using this approach. Is the REST interface similar to interfaces being proposed in i2aex? Have you done a feature comparison between the i2aex proposals and the DMTF proposals? I have a concern that the DMTF REST interface might be based on a DMTF abstract architectural model that may or may not actually be used by operators in real-world deployments. A major part of this BOF is to get feedback from real-world operators about what bottom=up technologies they actually use in real-world deployments to mitigate the problems of CDN and DC optimization, and whether operators would benefit from IETF standardization of these bottom-up optimization approaches. Ultimately, the i2aex BOF is about understanding whether IETF should develop extensions to Internet protocols to meet CDN and DC optimization needs when running over the Internet. It is not about developing an abstract all-encompassing architecture for managing clouds. So I have doubts about how much actual overlap exists between the DMTF proposals and the i2aex proposals. I do encourage people involved in this effort to consider whether there is overlap, but they should avoid being sidetracked into some mission that is not an IETF or i2aex BOF mission. My $.04 as Responsible AD for this BOF. -- David Harrington Director, Transport Area Internet Engineering Task Force (IETF) Ietfdbh@comcast.net +1-603-828-1401 On 3/21/12 1:50 PM, "Bhumip Khasnabish" wrote: >Hi Spencer, > >Is this similar to Cloud Infrastructure Management Interface (CIMI) Model >and REST Interface over HTTP An Interface for Managing Cloud >Infrastructure (http://dmtf.org/standards/cloud)? > >What is the trigger for this?! > >Thanks for clarifying. > >Best. > >Bhumip > > > > >On Wed, Mar 21, 2012 at 1:05 PM, Spencer Dawkins > wrote: > >Hi all, > >David Harrington asked me to act as BoF Shepherd for the >Infrastructure-to-application Information Exposure (i2aex) BoF, and I >wanted to make sure that a broad community of interest was aware of this >BoF, especially since the BoF is scheduled for Monday, Afternoon Session >1, at 1300 PM. > >Preliminary discussion has been going on for some time now on the >altoext@ietf.org mailing list, mainly among people in some way involved >in the standardization the ALTO protocol. In order to have a conversation >that's as productive as possible in Paris, we would really like to invite >people who are involved on different sides of the same problem to bring >their perspective as well. > >Here's a short description, with the usual pointers. Follow-ups to >altoext@ietf.org, please. > >The goal of the (non-WG-forming) BoF is to investigate infrastructure- >to-application information exposure and communications requirements in >fully controlled (e.g., data centers) or partially controlled >environments (e.g. CDN). Existing mechanisms such as SNMP, IGP, BGP and >other protocols that monitor and manage infrastructure may reveal much >if not all of the possibly required information, but are typically only >accessible to the operators of the network infrastructure. CDNs and data >center applications have some requirements to operate over the Internet, >possibly between administrative domains. On the other hand, the ALTO >protocol was initially designed to address peer-to-peer application >requirements, but was designed to be extensible and could be quite >easily adapted to export the pieces of information that CDN and data >center applications would benefit from. > >The BoF will thus primarily seek an answer to the following questions: > > + do CDN and data center applications require (or benefit in a > significant way from) accessing to information that cannot be made > available through existing mechanisms in a practical way? > > + is an extension to the ALTO protocol (or to any other protocol) a > viable way to address such requirements? > >Additional information about the topic is available on the BoF wiki >entry: http://trac.tools.ietf.org/bof/trac/#Transport > >The provisional agenda for the meeting is online at: >http://www.ietf.org/proceedings/83/agenda/agenda-83-i2aex.txt >_______________________________________________ >dc mailing list >dc@ietf.org >https://www.ietf.org/mailman/listinfo/dc > > > > > > From linda.dunbar@huawei.com Thu Mar 22 12:43:09 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5638621E8028; Thu, 22 Mar 2012 12:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pM24XEoCbLuy; Thu, 22 Mar 2012 12:43:08 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id EBA3121F85D6; Thu, 22 Mar 2012 12:43:07 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEP68367; Thu, 22 Mar 2012 15:43:06 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 22 Mar 2012 12:41:57 -0700 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0323.003; Thu, 22 Mar 2012 12:42:00 -0700 From: Linda Dunbar To: Spencer Dawkins , "apps-discuss@ietf.org" , "opsawg@ietf.org" , "tsvwg@ietf.org" , "cdni@ietf.org" , "dc@ietf.org" Thread-Topic: [dc] Announcing the i2aex BoF Thread-Index: AQHNB4Tsxr8YheQTEUmLhaS9a9PrIpZ2th0g Date: Thu, 22 Mar 2012 19:42:00 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F632E4F713@dfweml505-mbx> References: <4F6A0A41.3050006@wonderhamster.org> In-Reply-To: <4F6A0A41.3050006@wonderhamster.org> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.144.61] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mailman-Approved-At: Fri, 23 Mar 2012 08:09:23 -0700 Subject: Re: [apps-discuss] [dc] Announcing the i2aex BoF X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 22 Mar 2012 19:43:09 -0000 Are there specific applications in mind for the Intra-structure to expose t= o?=20 Linda > -----Original Message----- > From: dc-bounces@ietf.org [mailto:dc-bounces@ietf.org] On Behalf Of > Spencer Dawkins > Sent: Wednesday, March 21, 2012 12:05 PM > To: apps-discuss@ietf.org; opsawg@ietf.org; tsvwg@ietf.org; > cdni@ietf.org; dc@ietf.org > Subject: [dc] Announcing the i2aex BoF >=20 > Hi all, >=20 > David Harrington asked me to act as BoF Shepherd for the > Infrastructure-to-application Information Exposure (i2aex) BoF, and I > wanted to make sure that a broad community of interest was aware of > this > BoF, especially since the BoF is scheduled for Monday, Afternoon > Session > 1, at 1300 PM. >=20 > Preliminary discussion has been going on for some time now on the > altoext@ietf.org mailing list, mainly among people in some way involved > in the standardization the ALTO protocol. In order to have a > conversation that's as productive as possible in Paris, we would really > like to invite people who are involved on different sides of the same > problem to bring their perspective as well. >=20 > Here's a short description, with the usual pointers. Follow-ups to > altoext@ietf.org, please. >=20 > The goal of the (non-WG-forming) BoF is to investigate infrastructure- > to-application information exposure and communications requirements in > fully controlled (e.g., data centers) or partially controlled > environments (e.g. CDN). Existing mechanisms such as SNMP, IGP, BGP and > other protocols that monitor and manage infrastructure may reveal much > if not all of the possibly required information, but are typically only > accessible to the operators of the network infrastructure. CDNs and > data > center applications have some requirements to operate over the Internet, > possibly between administrative domains. On the other hand, the ALTO > protocol was initially designed to address peer-to-peer application > requirements, but was designed to be extensible and could be quite > easily adapted to export the pieces of information that CDN and data > center applications would benefit from. >=20 > The BoF will thus primarily seek an answer to the following questions: >=20 > + do CDN and data center applications require (or benefit in a > significant way from) accessing to information that cannot be made > available through existing mechanisms in a practical way? >=20 > + is an extension to the ALTO protocol (or to any other protocol) a > viable way to address such requirements? >=20 > Additional information about the topic is available on the BoF wiki > entry: http://trac.tools.ietf.org/bof/trac/#Transport >=20 > The provisional agenda for the meeting is online at: > http://www.ietf.org/proceedings/83/agenda/agenda-83-i2aex.txt > _______________________________________________ > dc mailing list > dc@ietf.org > https://www.ietf.org/mailman/listinfo/dc From vkg@bell-labs.com Fri Mar 23 08:35:00 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E86D221F851A; Fri, 23 Mar 2012 08:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.988 X-Spam-Level: X-Spam-Status: No, score=-106.988 tagged_above=-999 required=5 tests=[AWL=-0.389, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ogNqsSmsbBGd; Fri, 23 Mar 2012 08:34:55 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 7324321F8518; Fri, 23 Mar 2012 08:34:55 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q2NFXhLm011780 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 23 Mar 2012 10:33:43 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q2NFXgUK024564 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 23 Mar 2012 10:33:43 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.235]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q2NFXg6h019406; Fri, 23 Mar 2012 10:33:42 -0500 (CDT) Message-ID: <4F6C98F6.5020302@bell-labs.com> Date: Fri, 23 Mar 2012 10:38:30 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.1) Gecko/20120209 Thunderbird/10.0.1 MIME-Version: 1.0 To: Linda Dunbar References: <4F6A0A41.3050006@wonderhamster.org> <4A95BA014132FF49AE685FAB4B9F17F632E4F713@dfweml505-mbx> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F632E4F713@dfweml505-mbx> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Cc: "apps-discuss@ietf.org" , "dc@ietf.org" , "opsawg@ietf.org" , "cdni@ietf.org" , "tsvwg@ietf.org" Subject: Re: [apps-discuss] [dc] Announcing the i2aex BoF X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 23 Mar 2012 15:35:00 -0000 On 03/22/2012 02:42 PM, Linda Dunbar wrote: > Are there specific applications in mind for the Intra-structure to > expose to? Yes; there are what we call 3 high-level use cases ("applications" in your terminology above). These are: CDN, data centers, and large bandwidth. Please see http://www.ietf.org/proceedings/83/agenda/agenda-83-i2aex.txt for an agenda and a reading list. Thanks! - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ From alexey.melnikov@isode.com Sat Mar 24 05:29:40 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC5621F8711 for ; Sat, 24 Mar 2012 05:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Tb3y+dLzYQe for ; Sat, 24 Mar 2012 05:29:39 -0700 (PDT) Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 950A221F870F for ; Sat, 24 Mar 2012 05:29:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1332592178; d=isode.com; s=selector; i=@isode.com; bh=03Loo7RdSXbTwmMljND6KYmu4RdBdn+C01EF68pf3Sc=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=mF3jxNsbALRlxVph/o/9Hdlx/SId9vMl7E/Bp6JMdShqv3UoVdd//yBAH1VpxmA/Y0cHIP v053SRK+usTepeLbMqZBPwEQ+ZOyA3PVluej0fyKfOMpkbAf+3QQgniy56X9VmCUuLEh74 /HABQSioWhHDNL5Z4rmuOFoCiupoJvc=; Received: from [130.129.18.66] (dhcp-1242.meeting.ietf.org [130.129.18.66]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Sat, 24 Mar 2012 12:29:38 +0000 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <4F6DBE37.5080403@isode.com> Date: Sat, 24 Mar 2012 13:29:43 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: Jiankang YAO , =?UTF-8?B?Ik15a3l0YSBZZXZzdGlmZXlldiAo?= =?UTF-8?B?0JwuINCE0LLRgdGC0ZbRhNC10ZTQsiki?= References: <503575970.11554@cnnic.cn> <4A10020DB6464A0BBA535BF75D21A9D9@LENOVO47E041CF> In-Reply-To: <4A10020DB6464A0BBA535BF75D21A9D9@LENOVO47E041CF> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] WGLC: draft-ietf-appsawg-about-uri-scheme-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 24 Mar 2012 12:29:40 -0000 On 06/03/2012 01:00, Jiankang YAO wrote: > Dear colleagues, > > This message starts a two-week WGLC on the draft > draft-ietf-appsawg-about-uri-scheme-03.txt. > > Please help to review this draft. If you support publication, please state as > much on the list. If you are opposed to publication, please state > that on the list as well. It is more/only helpful if you give your reasons for > your position as part of your statement. > > Pls send your comments toapps-discuss@ietf.org orappsawg-chairs@tools.ietf.org or editors. > > The WGLC will end on March 20, 2012 at 1:00 UTC. Hi, Sorry, I've missed the WGLC. A couple of nits: 1. Introduction As use of "about" URIs has been quiet long-lasting, and the URIs have s/quiet/quite been used without any proper registration and absent any proper specification, the necessity for the the latter two actions arises. The purpose of this document is to provide a stable specification for "about" URI scheme and correspondingly register it in the IANA registry. Along, several provisions for handling the "about" URIs are set. 4.2. A Registry for Registered Tokens IANA is asked to set up a new registry entitled "'about' URI Special Purpose Tokens" following the guidelines below. The registry entries consist of 3 fields: Special-Purpose Token, Description and Reference. Below you also have "Contact/Change Controller", so 4 or 5 fields, depending how you count. From msk@cloudmark.com Sun Mar 25 03:36:47 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EEDF21F849C for ; Sun, 25 Mar 2012 03:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YozLUO6SPnCF for ; Sun, 25 Mar 2012 03:36:46 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 9183A21F8474 for ; Sun, 25 Mar 2012 03:36:46 -0700 (PDT) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by EXCH-HTCAS901.corp.cloudmark.com ([fe80::2966:6846:8d89:4681%12]) with mapi id 14.01.0355.002; Sun, 25 Mar 2012 03:36:45 -0700 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Thread-Topic: Slides for Monday Thread-Index: Ac0Kcy4gtqSymtU+QASZ5MoWg/b5DQ== Date: Sun, 25 Mar 2012 10:36:45 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280B8074@exch-mbx901.corp.cloudmark.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.129.66.96] Content-Type: multipart/alternative; boundary="_000_9452079D1A51524AA5749AD23E0039280B8074exchmbx901corpclo_" MIME-Version: 1.0 Subject: [apps-discuss] Slides for Monday X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 25 Mar 2012 10:36:47 -0000 --_000_9452079D1A51524AA5749AD23E0039280B8074exchmbx901corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Channeling the current WG chairs (Alexey is sitting next to me): Anybody who has slides for presentations at APPSAWG, please submit them to = appsawg-chairs@tools.ietf.org today. = If you're late, or if you show up to the meeting with your slides on a USB= stick, we reserve the right to move your agenda slot to the end or put it = under Any Other Business, and there may not be time. We already have slides from Paul about webfinger and Luca about certified e= mail; thanks for getting those in early. -MSK (for Alexey, Barry and Jiankang) --_000_9452079D1A51524AA5749AD23E0039280B8074exchmbx901corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Channeling the current WG chairs (Alexey is sitting = next to me):

 

Anybody who has slides for presentations at APPSAWG,= please submit them to appsawg-chairs@tools.ietf.= org today.  If you’re late, or if you show up to the meeting= with your slides on a USB stick, we reserve the right to move your agenda = slot to the end or put it under Any Other Business, and there may not be time.

 

We already have slides from Paul about webfinger and= Luca about certified email; thanks for getting those in early.<= /p>

 

-MSK (for Alexey, Barry and Jiankang)

--_000_9452079D1A51524AA5749AD23E0039280B8074exchmbx901corpclo_-- From lunohod.baikonur@gmail.com Sun Mar 25 13:10:05 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D288321E8013 for ; Sun, 25 Mar 2012 13:10:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.751 X-Spam-Level: X-Spam-Status: No, score=-102.751 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NHkrRAhmf96U for ; Sun, 25 Mar 2012 13:10:05 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3F38D21E800C for ; Sun, 25 Mar 2012 13:10:05 -0700 (PDT) Received: by iazz13 with SMTP id z13so8502095iaz.31 for ; Sun, 25 Mar 2012 13:10:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=9XR4fiw5dWq+xQlXYh7vIjevMAmRGOERLBtKkeU6kWs=; b=jf/31tyZNOfxreJZdDZ37/VVPXquHwraeqbT6KvBddTII3ZQLr2STe07J2Zm/QWaJf 0pl9a8fx0NNg+qp+nosVbzEt/0SWV5KDk9o+NkP3gOQhNIwif76fYZuguDsADFENfIAE gGt087LVLxrohru2Mxeg8gkRLE8jrLg2Bw6vepC4VCyvxFyHejcMkYslqqHPB4/FxtXS C8Wx533YJX98hJzGfYPlQBWZlcW/b8qIhB9YimZ1PtWRVOZ3MTBXvOQLhxQ/Sg/iyeCr H4X0yeV5dqkl4xzagOo37S8dQzJUhJNBE6eE/pa5LxUAFxVXNs4ptAzSsrDUKlCTGJaE QiXg== MIME-Version: 1.0 Received: by 10.50.76.163 with SMTP id l3mr4667213igw.10.1332706204832; Sun, 25 Mar 2012 13:10:04 -0700 (PDT) Sender: lunohod.baikonur@gmail.com Received: by 10.42.3.1 with HTTP; Sun, 25 Mar 2012 13:10:04 -0700 (PDT) In-Reply-To: <4F45D452.9010702@it.aoyama.ac.jp> References: <4F45D452.9010702@it.aoyama.ac.jp> Date: Sun, 25 Mar 2012 22:10:04 +0200 X-Google-Sender-Auth: gEY2f78vzbQyZiM0x-Wn5dh1Fkg Message-ID: From: Alexey Melnikov To: =?ISO-8859-1?Q?Martin_J=2E_D=FCrst?= Content-Type: multipart/alternative; boundary=e89a8f23533dedd40404bc16d7b6 Cc: Anne van Kesteren , apps-discuss@ietf.org Subject: Re: [apps-discuss] Feedback about "Update to MIME regarding Charset Parameter Handling in Textual Media Types" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 25 Mar 2012 20:14:40 -0000 --e89a8f23533dedd40404bc16d7b6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Martin, Catching up with this thread. On Thu, Feb 23, 2012 at 6:53 AM, "Martin J. D=FCrst" wrote: > > On 2012/02/22 22:25, Henri Sivonen wrote: > >> >> > > In order to improve interoperability with deployed agents, "text/*" medi= a >>> type definitions SHOULD either a) specify that the "charset" parameter = is >>> not used for the defined subtype, because the charset information is >>> transported inside the payload (as in "text/xml") >>> >> >> This seems wrong. If the charset parameter is present, it has an >> effect for text/xml. >> > Yes indeed. > > > Please describe this behavior. (As Julian pointed out, this might be just a bad example here. This document is not changing defaults for any existing text/* media type.) --e89a8f23533dedd40404bc16d7b6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Martin,
Catching up with this thread.
On Thu, Feb 23, 2012 at 6:53 AM, "Martin J. D=FCrst&q= uot; <duerst= @it.aoyama.ac.jp> wrote:

On 2012/02/22 22:25, Henri Sivonen w= rote:

=A0
In order to improve interoperability with deployed agents, "text/*&quo= t; media type definitions SHOULD either a) specify that the "charset&q= uot; parameter is not used for the defined subtype, because the charset inf= ormation is transported inside the payload (as in "text/xml")

This seems wrong. If the charset parameter is present, it has an
effect for text/xml.

Yes indeed.

=A0

Please describe this be= havior. (As Julian=A0pointed out, this=A0might be just a bad example here. = This document is not changing defaults for any existing text/*=A0media type= .)=A0

--e89a8f23533dedd40404bc16d7b6-- From internet-drafts@ietf.org Sun Mar 25 20:30:31 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB14621E8089; Sun, 25 Mar 2012 20:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jhy0fzEruusc; Sun, 25 Mar 2012 20:30:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4900D21F842B; Sun, 25 Mar 2012 20:30:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120326033031.13943.60219.idtracker@ietfa.amsl.com> Date: Sun, 25 Mar 2012 20:30:31 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-greylisting-06.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 26 Mar 2012 03:30:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Worki= ng Group of the IETF. Title : Email Greylisting: An Applicability Statement for SMTP Author(s) : Murray S. Kucherawy D. Crocker Filename : draft-ietf-appsawg-greylisting-06.txt Pages : 16 Date : 2012-03-25 This memo describes the art of email greylisting, the practice of providing temporarily degraded service to unknown email clients as an anti-abuse mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-appsawg-greylisting-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-appsawg-greylisting-06.txt From msk@cloudmark.com Sun Mar 25 20:32:10 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66D4021F8437 for ; Sun, 25 Mar 2012 20:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3tlAprua63hJ for ; Sun, 25 Mar 2012 20:32:09 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id CE7D321F8433 for ; Sun, 25 Mar 2012 20:32:06 -0700 (PDT) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by EXCH-HTCAS901.corp.cloudmark.com ([fe80::2966:6846:8d89:4681%12]) with mapi id 14.01.0355.002; Sun, 25 Mar 2012 20:32:06 -0700 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Thread-Topic: I-D Action: draft-ietf-appsawg-greylisting-06.txt Thread-Index: AQHNCwDR/tmhY4doeEWSf0LGtxWwTJZ769Qg Date: Mon, 26 Mar 2012 03:32:06 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280B88C2@exch-mbx901.corp.cloudmark.com> References: <20120326033031.13943.60219.idtracker@ietfa.amsl.com> In-Reply-To: <20120326033031.13943.60219.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.22.1.156] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-greylisting-06.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 26 Mar 2012 03:32:10 -0000 > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org= ] On Behalf Of internet-drafts@ietf.org > Sent: Sunday, March 25, 2012 8:31 PM > To: i-d-announce@ietf.org > Cc: apps-discuss@ietf.org > Subject: I-D Action: draft-ietf-appsawg-greylisting-06.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Applications Area Working > Group Working Group of the IETF. >=20 > Title : Email Greylisting: An Applicability Statement for SMTP > Author(s) : Murray S. Kucherawy > D. Crocker > Filename : draft-ietf-appsawg-greylisting-06.txt > Pages : 16 > Date : 2012-03-25 >=20 > This memo describes the art of email greylisting, the practice of > providing temporarily degraded service to unknown email clients as an > anti-abuse mechanism. Incorporates some minor post-WGLC feedback. -MSK From Internet-Drafts@ietf.org Mon Mar 26 00:26:56 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5BE921E809C; Mon, 26 Mar 2012 00:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.387 X-Spam-Level: X-Spam-Status: No, score=-102.387 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kPp5oT9do2V0; Mon, 26 Mar 2012 00:26:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7882D21E8098; Mon, 26 Mar 2012 00:26:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120326072653.12451.23432.idtracker@ietfa.amsl.com> Date: Mon, 26 Mar 2012 00:26:53 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D ACTION:draft-ietf-appsawg-about-uri-scheme-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 26 Mar 2012 07:26:56 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. Title : The "about" URI Scheme Author(s) : L. Hunt, et al Filename : draft-ietf-appsawg-about-uri-scheme Pages : 7 Date : March 26, 2012 This document specifies the "about" URI scheme, which is widely used by web browsers and some other applications to designate access to their internal resources, such as settings, application information, hidden built-in functionality, and so on. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-appsawg-about-uri-scheme-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-appsawg-about-uri-scheme"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2012-03-26002652.I-D@ietf.org> --NextPart-- From barryleiba@gmail.com Mon Mar 26 04:27:08 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E39D21F848B for ; Mon, 26 Mar 2012 04:27:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.005 X-Spam-Level: X-Spam-Status: No, score=-103.005 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LxCQQXZt+PZi for ; Mon, 26 Mar 2012 04:27:08 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id D997421F84F8 for ; Mon, 26 Mar 2012 04:27:07 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so6015135obb.31 for ; Mon, 26 Mar 2012 04:27:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=B9y8CughNmUixzliymixZWA2YTpqop8kIq6Cb6DunMU=; b=AQslZM5uMuDr5tYA+KvzQAcKLBzO6XV827+62mmcASAHsSigmiOFUFy/Nt+34du0Q7 qa77VMNmkMb/REyqfob/ewkpoms2hykH1ZNES5Cb2CEQ8x/lbTZBYgHLMsBBiGgv46Me VVsWIfxf8o1nGjN34szCOQj44BJ1BZjENyfJepx2sHex2z6roLaTQDS/gLdca3nnHSNZ KY0C5OXnjqSXT8oOUIs0xFr1diLf/iYMW+J7sd8p4R36LjsxEDYDSaioYtpecq5dPHdR jGqlEoSA0wu7TDm8A+4OgwVx/HGzsfo3ZnQShpBR6zgssWI6X+2mawOcieV7c1TJfN7L Rcog== MIME-Version: 1.0 Received: by 10.60.23.138 with SMTP id m10mr26482020oef.12.1332761227510; Mon, 26 Mar 2012 04:27:07 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.60.10.68 with HTTP; Mon, 26 Mar 2012 04:27:07 -0700 (PDT) Date: Mon, 26 Mar 2012 07:27:07 -0400 X-Google-Sender-Auth: lhEwgfuIgbfdAffJXgRkQBSqHM4 Message-ID: From: Barry Leiba To: Apps Discuss Content-Type: multipart/alternative; boundary=e89a8fb1ff2a89436d04bc23a79c Subject: [apps-discuss] AppsAWG chair changes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 26 Mar 2012 11:27:08 -0000 --e89a8fb1ff2a89436d04bc23a79c Content-Type: text/plain; charset=ISO-8859-1 As we announced in this morning's appsawg session, the App ADs have wantd to rotate the appsawg chairs, and give others opportunities for greater exposure within the App area. With Barry's leaving chairdom to be an AD, we have the following changes: 1. Peter St Andre is leaving the IESG, and Barry Leiba is a new Applications Area Director. 2. Barry will become the responsible AD for appsawg, transferred from Pete Resnick. 3. Barry and Jiankang Yao will step down as appsawg chairs now. 4. Alexey Melnikov will remain as transitional chair, to provide continuity. 5. Murray Kucherawy (chair of MARF and liaison to OMA) will step in as new appsawg chair. 6. Pete and Barry will look for a new appsawg chair, to replace Alexey (probably in Vancouver). Barry and Pete, Applications ADs --e89a8fb1ff2a89436d04bc23a79c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable As we announced in this morning's appsawg session, the App ADs have wan= td to rotate the appsawg chairs, and give others opportunities for greater = exposure within the App area. =A0With Barry's leaving chairdom to be an= AD, we have the following changes:

1. Peter St Andre is leaving the IESG, and Barry Leiba is a new Applica= tions Area Director.
2. Barry will become the responsible AD for appsawg= , transferred from Pete Resnick.
3. Barry and Jiankang Yao will step dow= n as appsawg chairs now.
4. Alexey Melnikov will remain as transitional chair, to provide continuity= .
5. Murray Kucherawy (chair of MARF and liaison to OMA) will step in as= new appsawg chair.
6. Pete and Barry will look for a new appsawg chair,= to replace Alexey (probably in Vancouver).

Barry and Pete, Applications ADs --e89a8fb1ff2a89436d04bc23a79c-- From paulej@packetizer.com Mon Mar 26 07:35:56 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB4A21E809C for ; Mon, 26 Mar 2012 07:35:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R-lIF-Ex34ZW for ; Mon, 26 Mar 2012 07:35:55 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id EE26021E80B3 for ; Mon, 26 Mar 2012 07:35:52 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q2QEZpM4017520 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 26 Mar 2012 10:35:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1332772552; bh=EKpXO5wdq0DKHSCtzzGrgS/L73y2G/EcVJV7AIs7d88=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type: Content-Transfer-Encoding; b=M1y5aGnf4FH0udJZuanGPhYcj5UebV2f20a84Z/OATsRVFAdL/RHHPyAzA/pORHfX MWcXUcEynnqEo5catpbJPodjXoRi7U40q5Sm1ZYVZjxty6fltTiuH6DFP84ikejGBk 0ec2rK4FfFJlMprfeiqG9v+kZTqu7gLpU84oSeRU= From: "Paul E. Jones" To: Date: Mon, 26 Mar 2012 10:35:54 -0400 Message-ID: <053201cd0b5d$c08c80f0$41a582d0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac0LWmibUdNYkiEqSDOmM+1w+wpGVQ== Content-Language: en-us Subject: [apps-discuss] Webfinger discussion X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 26 Mar 2012 14:35:56 -0000 Folks, I saw the notes regarding the Webfinger discussion today. Unfortunately, I could not be there, so please indulge me while I ask questions related to the notes: > Thomas Roessler: CORS is in last call This is good to know. So, was the group in favor of leaving it in as mandatory? ?: Good idea. Work going on in other orgs that reference this. > Hannes Tschofenig: People like the whole idea, but is bizarre to mandate CORS Yeah, we have a choice to make. If we mandate it, then (in theory) it should be possible to query a Webfinger server via a JavaScript application in the browser. Without it, we would not be able to get beyond the single-origin rules. > Paul Hoffman: needs to have consensus calls, so should be in APPSAWG Not sure what this meant. Are you suggesting we make the document a WG item? For sure, I'd like to progress the document. > Leif Johannsen: people don't have their own email servers anymore This is true, which is one reason people have favored using "acct". Now, people have identifiers on social networks, but the user@domain notation is convenient and understood. > Andrew Sullivan: when I was a kid, they told us to turn off finger, so I'm > concerned about security That was due to the fact the finger protocol implementations had security holes. It was also possible to do things like "ln /etc/password .plan" and that was a bad thing :-) > Dave Crocker: email is the same as it's always been. Email is good as > identifier, even if there's no mailbox. Nice service to have, but needs > lots of input to get correct. Might need more work than APPSAWG. Might > need its own WG. I would hope it does not go so far as to needing its own WG. Much of the "Webfinger" functionality is really formally describing it as such and using existing RFCs. The "new" bits are the "acct" URI scheme, link relation, requirement to use CORS, and requirement to implement JRD. The "acct" URI scheme is already used "in the wild" and is needed because some social networks provide user accounts, but not email addresses. To somebody else's point, some do not run their own email servers anymore and certainly many social networks are not going to provide email services, as there is little to no value in doing so. Yet, a "Webfinger" service has value. > Mike Jones: (speaking as openid/oauth contributer) we don't use this; > it doesn't have the right properties Webfinger is not intended to be used by OpenID directly. Actually, how I stumbled into this area, though, was through OpenID. As I implemented my OpenID server, I wanted to find a way to get rid of forcing people to have OpenID identifiers that had to enter on sites like https://openid.packetizer.com/paulej. People pointed me to the work on Webfinger. Webfinger does not replace the OpenID identifier, but merely provides makes it easily discoverable. So, when I visit a web site, I can enter paulej@packetizer.com. This would result in a Webfinger query for acct:paulej@packetizer.com. What would be returned is several pieces of information one of which is https://openid.packetizer.com/paulej using the link relation http://specs.openid.net/auth/2.0/provider. (I'm not too favorable to that particular link relation, since it's not a pointer to the provider, but a pointer to my identifier. But, that seems to be the predominant value used.) The service I'm trying to log into now has my identifier in hand and would go through the same login procedures. Security should not be compromised, because the Webfinger account information should have been provided securely and the login process within the OpenID provider should either be automatic (because the provider already recognizes your browser) or would prompt for credentials. Nothing about OpenID has been weakened in the process, as nothing about OpenID changed. Further, there is never a requirement to use Webfinger -- it's an option for OpenID. > John Bradley: (speaking as author of XRD) JRD is doc'd in blog post, > concerned about security/privacy, needs more work before could be used > in OpenID/Connect. JRD is documented now in standards-track RFC 6415. It defines a direct mapping from XRD to JRD. I will not disagree that thought may need to be considered in for use in OpenID or OpenID Connect, but that is not an issue for Webfinger itself. Webfinger merely provides pointers to information or other identifiers. I understand how this would work in OpenID and I don't see risk there. I'm not familiar with how OpenID Connect is supposed to work. I had seen some proposals, but nothing recent. Those proposals I had seen suggested that I enter my credentials for my identify provider on the site that I was visiting. Hopefully, that's now how it works now, because there's no way I would do that :-) So, what was the opinion of the group? It's important to note that RFC 6415 essentially defines all of the mechanisms already, so it's out there and people can use it. The Webfinger draft is there to formalize the name and to introduce the needed "acct" URI and link relation values. Paul From ajs@anvilwalrusden.com Mon Mar 26 08:05:56 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C57021E80DB for ; Mon, 26 Mar 2012 08:05:56 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HCXNg5nf7XLb for ; Mon, 26 Mar 2012 08:05:56 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id CA71121E80DA for ; Mon, 26 Mar 2012 08:05:55 -0700 (PDT) Received: from mail.yitter.info (dhcp-21ac.meeting.ietf.org [130.129.33.172]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id AEFE91ECB420 for ; Mon, 26 Mar 2012 15:05:54 +0000 (UTC) Date: Mon, 26 Mar 2012 11:05:57 -0400 From: Andrew Sullivan To: apps-discuss@ietf.org Message-ID: <20120326150556.GC3557@mail.yitter.info> References: <053201cd0b5d$c08c80f0$41a582d0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <053201cd0b5d$c08c80f0$41a582d0$@packetizer.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [apps-discuss] Webfinger discussion X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 26 Mar 2012 15:05:56 -0000 On Mon, Mar 26, 2012 at 10:35:54AM -0400, Paul E. Jones wrote: > > Andrew Sullivan: when I was a kid, they told us to turn off finger, so I'm > > concerned about security > > That was due to the fact the finger protocol implementations had security > holes. It was also possible to do things like "ln /etc/password .plan" and > that was a bad thing :-) That wasn't the only reason they told us this. One of the things that people used to worry about was that finger leaked information. In particular, it was an excellent way to identify targets for account takeover: people who never logged in, and people who were in for endless days and therefore whose account was probably often unmonitored. Now, I never knew whether I believed this sort of complaint, but it was one, and the draft as it stands only just hints at the sort of analysis that ought to be done. It seems like this requires a much expanded security considerations section, and that was the point I wanted to make. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From internet-drafts@ietf.org Mon Mar 26 08:10:36 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46CE021E80C9; Mon, 26 Mar 2012 08:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQLxNGstZWFA; Mon, 26 Mar 2012 08:10:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8825421F8608; Mon, 26 Mar 2012 08:10:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120326151030.7902.33251.idtracker@ietfa.amsl.com> Date: Mon, 26 Mar 2012 08:10:30 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-http-forwarded-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 26 Mar 2012 15:10:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Worki= ng Group of the IETF. Title : Forwarded HTTP Extension Author(s) : Andreas Petersson Martin Nilsson Filename : draft-ietf-appsawg-http-forwarded-01.txt Pages : 12 Date : 2012-03-26 This document standardizes an HTTP extension header field that allows proxy components to disclose information lost in the proxying process, e.g., the originating IP address of a request or IP number of the proxy on the user-agent facing interface. Given a trusted path of proxying components, this makes it possible to arrange so that each subsequent component will have access to e.g., all IP addresses used in the chain of proxied HTTP requests. This document also specifies guidelines for a proxy administrator to anonymize the origin of a request. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-appsawg-http-forwarded-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-appsawg-http-forwarded-01.txt From andreas@sbin.se Mon Mar 26 08:34:22 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 860B521E80CF for ; Mon, 26 Mar 2012 08:34:22 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FIOLNPOTn3fF for ; Mon, 26 Mar 2012 08:34:21 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id 5590521E80C2 for ; Mon, 26 Mar 2012 08:34:20 -0700 (PDT) Received: from hetzer (oslo.jvpn.opera.com [213.236.208.46]) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q2QFYIaA011669 for ; Mon, 26 Mar 2012 15:34:18 GMT Date: Mon, 26 Mar 2012 17:34:17 +0200 From: Andreas Petersson To: apps-discuss@ietf.org Message-ID: <20120326173417.6058d1f6@hetzer> In-Reply-To: <20120326151030.7902.33251.idtracker@ietfa.amsl.com> References: <20120326151030.7902.33251.idtracker@ietfa.amsl.com> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.6; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-http-forwarded-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 26 Mar 2012 15:34:22 -0000 On Mon, 26 Mar 2012 08:10:30 -0700 internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF. I believe there is not much left to fix in this draft. My biggest concern right now is this: extension = 1*( ALPHA | DIGIT | "-" ) ext-value = Is that too liberal? Should recommendations be done in this draft on what character encoding should be used? If the value is an URL, should the document recommend IDNA? Should the draft say anything about case sensitivity? Of course all this depends on what people will use it for. /Andreas Petersson From paulej@packetizer.com Mon Mar 26 11:15:38 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0C7521E80F7 for ; Mon, 26 Mar 2012 11:15:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Q15Nx7ZRqMG for ; Mon, 26 Mar 2012 11:15:38 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id AAF2221E80CE for ; Mon, 26 Mar 2012 11:15:37 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q2QIFRXW022619 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 26 Mar 2012 14:15:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1332785729; bh=o8EtaC7Sb5TlTJGccXmDjBVy1no7HbEyD/onCmi2qi4=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=InbdfA6syRVJgSiKy8Nu/2aN40b7FJjvyNoTZ8PVE6mNQab2Nhzo0zanhP768tEKP MWS4cZ+2wIwvLM90LUAMxN2t5YnyMalDm59YKh+4ENUqZMfRZ0sMed1zizRTN3hb6C r+ArUchYDLSU/hm2ofhGBGHqz34mom7ebCrE72h0= From: "Paul E. Jones" To: "'Andrew Sullivan'" , References: <053201cd0b5d$c08c80f0$41a582d0$@packetizer.com> <20120326150556.GC3557@mail.yitter.info> In-Reply-To: <20120326150556.GC3557@mail.yitter.info> Date: Mon, 26 Mar 2012 14:15:31 -0400 Message-ID: <057101cd0b7c$6ec95170$4c5bf450$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEg174HJISLlkWDD0VVkXSpmVuZQwKMareXl8DkonA= Content-Language: en-us Subject: Re: [apps-discuss] Webfinger discussion X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 26 Mar 2012 18:15:38 -0000 Andrew, > > > Andrew Sullivan: when I was a kid, they told us to turn off finger, > > > so I'm concerned about security > > > > That was due to the fact the finger protocol implementations had > > security holes. It was also possible to do things like "ln > > /etc/password .plan" and that was a bad thing :-) > > That wasn't the only reason they told us this. One of the things that > people used to worry about was that finger leaked information. In > particular, it was an excellent way to identify targets for account > takeover: people who never logged in, and people who were in for endless > days and therefore whose account was probably often unmonitored. > > Now, I never knew whether I believed this sort of complaint, but it was > one, and the draft as it stands only just hints at the sort of analysis > that ought to be done. It seems like this requires a much expanded > security considerations section, and that was the point I wanted to make. I can see those argument against the traditional finger protocol. At the very least, one could determine which accounts have not changed passwords since the last attack attempt. For Webfinger, though, those same security issues do not exist. It borrows the concept of learning information about somebody (or something), but it's certainly not exposing the same risks. Further, whatever risks exist for Webfinger exist with RFC 6415, largely. The acct URI, acct link relation, and use of CORS are two new considerations, but everything else already exists. So for the security considerations, we need to focus on those items. I'm happy to add whatever folks feel we should add. Paul From bobwyman@gmail.com Mon Mar 26 11:31:31 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8E2B21F85C4 for ; Mon, 26 Mar 2012 11:31:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.229 X-Spam-Level: X-Spam-Status: No, score=-2.229 tagged_above=-999 required=5 tests=[AWL=0.748, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8APJdTpDLU5 for ; Mon, 26 Mar 2012 11:31:31 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id C5A0A21F85BD for ; Mon, 26 Mar 2012 11:31:30 -0700 (PDT) Received: by qcsq13 with SMTP id q13so4056261qcs.31 for ; Mon, 26 Mar 2012 11:31:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=QscMxMqvAvzXewHNFyN0ddG2tgn5s6sNla/3tLGMTDc=; b=XVaa/KV3w4HszlXCavrIvfmh8qZPRDF2jHNcra7TcDq80HoMYj8rCJNc5uy2wskg5s XyX53mPmznMAbdfWvuI5cDmgz6tpdyvpIpxeMJKBS1mi0tiGTuK+db+U32EObhCKHtlm AsQUpY1n/h40RY1mcpLHnhdycT9SPUJ6ge/syKTrU5W2aJAXbao1tQsPDblEUa9yILYX SjKpGntUJF0xgoAatUeO+c4njdVIo6HT610/WBlz7eibzfHQ2k9GQOtxUFY/VbwwG40p PueyZOV7k1hJp2kg9Z2Qv4haRiAuE4SYRH8H1BTcAQ8mXF/6V5/x2gT1+Zlhg35Wd9Sy weVg== MIME-Version: 1.0 Received: by 10.224.116.19 with SMTP id k19mr29109955qaq.59.1332786690219; Mon, 26 Mar 2012 11:31:30 -0700 (PDT) Sender: bobwyman@gmail.com Received: by 10.229.157.16 with HTTP; Mon, 26 Mar 2012 11:31:30 -0700 (PDT) In-Reply-To: <20120326150556.GC3557@mail.yitter.info> References: <053201cd0b5d$c08c80f0$41a582d0$@packetizer.com> <20120326150556.GC3557@mail.yitter.info> Date: Mon, 26 Mar 2012 14:31:30 -0400 X-Google-Sender-Auth: _-BK5LmDu0CjFiwhUfbu0pFnYjE Message-ID: From: Bob Wyman To: Andrew Sullivan Content-Type: multipart/alternative; boundary=20cf3074d9343b5c8c04bc29951a Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Webfinger discussion X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 26 Mar 2012 18:31:31 -0000 --20cf3074d9343b5c8c04bc29951a Content-Type: text/plain; charset=ISO-8859-1 On Mon, Mar 26, 2012 at 11:05 AM, Andrew Sullivan wrote: > On Mon, Mar 26, 2012 at 10:35:54AM -0400, Paul E. Jones wrote: > > > > Andrew Sullivan: when I was a kid, they told us to turn off finger, so > I'm > > > concerned about security > > > > That was due to the fact the finger protocol implementations had security > > holes. It was also possible to do things like "ln /etc/password .plan" > and > > that was a bad thing :-) > > That wasn't the only reason they told us this. One of the things that > people used to worry about was that finger leaked information. In > particular, it was an excellent way to identify targets for account > takeover: people who never logged in, and people who were in for > endless days and therefore whose account was probably often > unmonitored. > WebFinger has primarily been used for providing access to relatively static data rather than for the kind of dynamic "presence" information that finger was often used for. Thus, when folk are thinking about WebFinger, they are usually considering use cases like "locating a user's blog," or "finding a user's public key." However, there isn't anything in WebFinger that would prevent providing dynamic data such as "current location (lat/long)," "logged in state," or even "last command issued to bash..." (highly un-recommended!). If people did, in fact, use WebFinger to record such stuff, the concerns you mentioned would be relevant. Thus, it might make sense for the Security Considerations section to suggest that one should think carefully before using WebFinger to provide such dynamic information. > > Now, I never knew whether I believed this sort of complaint, but it > was one, and the draft as it stands only just hints at the sort of > analysis that ought to be done. It seems like this requires a much > expanded security considerations section, and that was the point I > wanted to make. > > Best, > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --20cf3074d9343b5c8c04bc29951a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Mar 26, 2012 at 11:05 AM, Andrew= Sullivan <a= js@anvilwalrusden.com> wrote:
On Mon, Mar 26, 2012 at 10:35:54AM -0400, Paul E. Jones w= rote:

> > Andrew Sullivan: when I was a kid, they told us to turn off finge= r, so I'm
> > concerned about security
>
> That was due to the fact the finger protocol implementations had secur= ity
> holes. =A0It was also possible to do things like "ln /etc/passwor= d .plan" and
> that was a bad thing :-)

That wasn't the only reason they told us this. =A0One of the thin= gs that
people used to worry about was that finger leaked information. =A0In
particular, it was an excellent way to identify targets for account
takeover: people who never logged in, and people who were in for
endless days and therefore whose account was probably often
unmonitored.
WebFinger has primarily been used for pro= viding access to relatively static data rather than for the kind of dynamic= "presence" information that finger was often used for. Thus, whe= n folk are thinking about WebFinger, they are usually considering use cases= like "locating a user's blog," or "finding a user's= public key." However, there isn't anything in WebFinger that woul= d prevent providing dynamic data such as "current location (lat/long),= " "logged in state," or even "last command issued to ba= sh..." (highly un-recommended!). If people did, in fact, use WebFinger= to record such stuff, the concerns you mentioned would be relevant. Thus, = it might make sense for the Security Considerations section to suggest that= one should think carefully before using WebFinger to provide such dynamic = information.
=A0

Now, I never knew whether I believed this sort of complaint, but it
was one, and the draft as it stands only just hints at the sort of
analysis that ought to be done. =A0It seems like this requires a much
expanded security considerations section, and that was the point I
wanted to make.

Best,

A

--
Andrew Sullivan
ajs@anvilwalrusden.com
_____________________= __________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--20cf3074d9343b5c8c04bc29951a-- From stpeter@stpeter.im Mon Mar 26 15:30:43 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44F5121E801F for ; Mon, 26 Mar 2012 15:30:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7S8JOrVNirRk for ; Mon, 26 Mar 2012 15:30:42 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 94C3A21E8012 for ; Mon, 26 Mar 2012 15:30:42 -0700 (PDT) Received: from squire.lan (unknown [82.66.240.205]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 00F3A40058; Mon, 26 Mar 2012 16:43:42 -0600 (MDT) Message-ID: <4F70EE0F.8090706@stpeter.im> Date: Tue, 27 Mar 2012 00:30:39 +0200 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: Bob Wyman References: <053201cd0b5d$c08c80f0$41a582d0$@packetizer.com> <20120326150556.GC3557@mail.yitter.info> In-Reply-To: X-Enigmail-Version: 1.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Webfinger discussion X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 26 Mar 2012 22:30:43 -0000 On 3/26/12 8:31 PM, Bob Wyman wrote: > > > On Mon, Mar 26, 2012 at 11:05 AM, Andrew Sullivan > > wrote: > > On Mon, Mar 26, 2012 at 10:35:54AM -0400, Paul E. Jones wrote: > > > > Andrew Sullivan: when I was a kid, they told us to turn off > finger, so I'm > > > concerned about security > > > > That was due to the fact the finger protocol implementations had > security > > holes. It was also possible to do things like "ln /etc/password > .plan" and > > that was a bad thing :-) > > That wasn't the only reason they told us this. One of the things that > people used to worry about was that finger leaked information. In > particular, it was an excellent way to identify targets for account > takeover: people who never logged in, and people who were in for > endless days and therefore whose account was probably often > unmonitored. > > WebFinger has primarily been used for providing access to relatively > static data rather than for the kind of dynamic "presence" information > that finger was often used for. Thus, when folk are thinking about > WebFinger, they are usually considering use cases like "locating a > user's blog," or "finding a user's public key." However, there isn't > anything in WebFinger that would prevent providing dynamic data such as > "current location (lat/long)," "logged in state," or even "last command > issued to bash..." (highly un-recommended!). If people did, in fact, use > WebFinger to record such stuff, the concerns you mentioned would be > relevant. Thus, it might make sense for the Security Considerations > section to suggest that one should think carefully before using > WebFinger to provide such dynamic information. We already have protocols for such dynamic publish/subscribe features (and those protocols include ways to authorize who can see what). Webfinger might provide pointers to locations where one could subscribe to dynamic data, but AFAIK it would not be used to pull the data. Peter -- Peter Saint-Andre https://stpeter.im/ From chi880466@gmail.com Mon Mar 26 22:22:06 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9CDB21F841D for ; Mon, 26 Mar 2012 22:22:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.271 X-Spam-Level: X-Spam-Status: No, score=0.271 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lun7rQEEkwWH for ; Mon, 26 Mar 2012 22:22:06 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 296FC21F8766 for ; Mon, 26 Mar 2012 22:22:06 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so3618906vbb.31 for ; Mon, 26 Mar 2012 22:22:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=dmad7JDwJov0k4hz62qCqyshZYgeMCdjzP9yTXobqb0=; b=ESh2hlpZU0ljx+trwl8Arkkoy6NipYZC3pVYtqJkGfrJJlhhjURNPTwrZWQbVsGBNg X53dTsrzBJCtXuItE7FaKG3v/ofh3W6JTBu4aursRa87qH9y0lvVrhL7PIrN47lXIP9x LUxGKDSnWB+OCdj23fvP75SS6eHJMAjBRIYI8Kssy8Sgexqcxqah0il1r+d3BgbYZNQ6 ly8+a0DRCT8eWVE1nmj0Au2BeEmP50UBP4vT5jtKadEvKHLHCrqZCc3Mp7DwaX5awFLm NH4PoRjuiEH/V8NC8FjxGsPIvODd+wxZwYt/iOp4VSV+75I41J6etCpIs/kDjuF+jeph XXVQ== MIME-Version: 1.0 Received: by 10.52.88.9 with SMTP id bc9mr9457175vdb.74.1332825725643; Mon, 26 Mar 2012 22:22:05 -0700 (PDT) Received: by 10.220.1.4 with HTTP; Mon, 26 Mar 2012 22:22:05 -0700 (PDT) Date: Tue, 27 Mar 2012 14:22:05 +0900 Message-ID: From: =?EUC-KR?B?wfa827/4IEphbWVzIFNvbmd3b24gQ2hp?= To: apps-discuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [apps-discuss] Confusing JSON Pointer X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 27 Mar 2012 05:22:06 -0000 After reading JSON Pointer (draft-ietf-appsawg-json-pointer-01), I am confused with encoding or escape scheme. For me, it is an ambiguous scheme. For example, a reference token "ref/1" can be expressed following ways: 1) If it is a URI fragment identifier and a JSON Pointer Step 1. apply URI encoding: ref%5C1 Step 2. apply JSON Pointer encoding: ref%5C1 Final result: ref%5C1 2) If it is a JSON Pointer and a URI fragment identifier Step 1. apply JSON Pointer encoding: ref^/1 Step 2. apply URI encoding: ref^%5C1 Final result: ref^%5C1 I expected the same results. And if my interpretation is wrong, to prevent the similar question, there should be some examples for this kind. James From martin.thomson@gmail.com Tue Mar 27 00:41:02 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D5C721F87AE for ; Tue, 27 Mar 2012 00:41:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.684 X-Spam-Level: X-Spam-Status: No, score=-4.684 tagged_above=-999 required=5 tests=[AWL=-1.085, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gg-IF8IkizQR for ; Tue, 27 Mar 2012 00:41:01 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4000521F8790 for ; Tue, 27 Mar 2012 00:41:01 -0700 (PDT) Received: by bkuw5 with SMTP id w5so5350482bku.31 for ; Tue, 27 Mar 2012 00:41:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=xC0kHctjAcQFFN0TGevt0k2jWt9Q1jADuvEGUckXWdM=; b=GGc1N6/7vW6T5xkdC7BxU7MDqNbaSqHz3LZGazOH5HW4PSRFU1mtEmVbY5w4I8oWNk hkGa2ecN3DN44B1t3ICNe/s4aNHTF+ZAjfZYVO6/7kKFMgWXmKSaTjgjBpspn19YNy0Y H2K/5BUng/LvwWtyzKYxr7DJDo+OlO1A6Bmdq0lJ2AmWCliTfoWEN2sU21RRvp+hAPIK 3CTI8gC5+KTiPKFPe1tkRy5MLL8uEGjZjU1EubPaDFm7UlbYQYC2icZWn1eORJvYry47 6OqKMmZcl89zeanx3rGmFIryHZi6aM12gtYPXl2l755cTd66fev2oqqMUG+SXhIeG/g8 8tYA== MIME-Version: 1.0 Received: by 10.204.153.215 with SMTP id l23mr9652283bkw.11.1332834060238; Tue, 27 Mar 2012 00:41:00 -0700 (PDT) Received: by 10.205.38.73 with HTTP; Tue, 27 Mar 2012 00:41:00 -0700 (PDT) In-Reply-To: <20120326173417.6058d1f6@hetzer> References: <20120326151030.7902.33251.idtracker@ietfa.amsl.com> <20120326173417.6058d1f6@hetzer> Date: Tue, 27 Mar 2012 09:41:00 +0200 Message-ID: From: Martin Thomson To: Andreas Petersson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-http-forwarded-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 27 Mar 2012 07:41:02 -0000 On 26 March 2012 17:34, Andreas Petersson wrote: > I believe there is not much left to fix in this draft. > My biggest concern right now is this: > > =C2=A0 =C2=A0extension =3D 1*( ALPHA | DIGIT | "-" ) > =C2=A0 =C2=A0ext-value =3D =C2=A0 =C2=A0 =C2=A0but including SP> > > Is that too liberal? Should recommendations be done in this draft on > what character encoding should be used? Why not use the normal token / quoted-string constructs? From julian.reschke@gmx.de Tue Mar 27 00:54:09 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B662021F87D0 for ; Tue, 27 Mar 2012 00:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.163 X-Spam-Level: X-Spam-Status: No, score=-104.163 tagged_above=-999 required=5 tests=[AWL=-1.564, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E78RKHL6SZRE for ; Tue, 27 Mar 2012 00:54:09 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 6927A21F87B0 for ; Tue, 27 Mar 2012 00:54:08 -0700 (PDT) Received: (qmail invoked by alias); 27 Mar 2012 07:54:07 -0000 Received: from mail.greenbytes.de (EHLO [IPv6:::1]) [217.91.35.233] by mail.gmx.net (mp012) with SMTP; 27 Mar 2012 09:54:07 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18ro9ZwypsrW+AD8wDFQ/RqE644vRI1DMjNHSTte9 Yuw6QIvZuutx++ Message-ID: <4F71721A.7010301@gmx.de> Date: Tue, 27 Mar 2012 09:54:02 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Martin Thomson References: <20120326151030.7902.33251.idtracker@ietfa.amsl.com> <20120326173417.6058d1f6@hetzer> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-http-forwarded-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 27 Mar 2012 07:54:10 -0000 On 2012-03-27 09:41, Martin Thomson wrote: > On 26 March 2012 17:34, Andreas Petersson wrote: >> I believe there is not much left to fix in this draft. >> My biggest concern right now is this: >> >> extension = 1*( ALPHA | DIGIT | "-" ) >> ext-value => but including SP> >> >> Is that too liberal? Should recommendations be done in this draft on >> what character encoding should be used? > > Why not use the normal token / quoted-string constructs? Yes, please. Also, it's no entirely clear why the spec depends on RFC 2616, not HTTPbis (although it copies some of its style). Finally, as noted in other WGs: please do not special case the syntax of certain parameters. Just define *all* of them to be token / quoted-string and then define additional constrains separately (see epic discussions in OAuth and WebSec). Best regards, Julian From julian.reschke@gmx.de Tue Mar 27 00:57:57 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FE3C21F87F9 for ; Tue, 27 Mar 2012 00:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.002 X-Spam-Level: X-Spam-Status: No, score=-104.002 tagged_above=-999 required=5 tests=[AWL=-1.703, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NlfPCY5KfD4I for ; Tue, 27 Mar 2012 00:57:56 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 27A0521F87F8 for ; Tue, 27 Mar 2012 00:57:55 -0700 (PDT) Received: (qmail invoked by alias); 27 Mar 2012 07:57:54 -0000 Received: from mail.greenbytes.de (EHLO [IPv6:::1]) [217.91.35.233] by mail.gmx.net (mp017) with SMTP; 27 Mar 2012 09:57:54 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+pXk8eSfCpSiUdYN2ZDtq6Y6xsm8F8CnWcaduhZF X9f1IQCAWoNk46 Message-ID: <4F7172FE.6060207@gmx.de> Date: Tue, 27 Mar 2012 09:57:50 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: =?UTF-8?B?7KeA7Iah7JuQIEphbWVzIFNvbmd3b24gQ2hp?= References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Confusing JSON Pointer X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 27 Mar 2012 07:57:57 -0000 On 2012-03-27 07:22, ì§€ì†¡ì› James Songwon Chi wrote: > After reading JSON Pointer (draft-ietf-appsawg-json-pointer-01), I am > confused with encoding or escape scheme. > For me, it is an ambiguous scheme. For example, a reference token > "ref/1" can be expressed following ways: > > 1) If it is a URI fragment identifier and a JSON Pointer > Step 1. apply URI encoding: ref%5C1 > Step 2. apply JSON Pointer encoding: ref%5C1 > Final result: ref%5C1 > > 2) If it is a JSON Pointer and a URI fragment identifier > Step 1. apply JSON Pointer encoding: ref^/1 > Step 2. apply URI encoding: ref^%5C1 > Final result: ref^%5C1 > > I expected the same results. > > And if my interpretation is wrong, to prevent the similar question, > there should be some examples for this kind. > ... I don't understand the question. The spec states how to put JSON Pointers (^-escaping) into fragment identifiers (%-escaping). As far as I can tell the outcome then is what you have under 2), no? Best regards, Julian From ajs@anvilwalrusden.com Tue Mar 27 01:47:15 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A64421F8802 for ; Tue, 27 Mar 2012 01:47:15 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aNLho2cI5t0B for ; Tue, 27 Mar 2012 01:47:14 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id B49E821F87FA for ; Tue, 27 Mar 2012 01:47:14 -0700 (PDT) Received: from mail.yitter.info (dhcp-1108.meeting.ietf.org [130.129.17.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 9528A1ECB420 for ; Tue, 27 Mar 2012 08:47:13 +0000 (UTC) Date: Tue, 27 Mar 2012 04:47:10 -0400 From: Andrew Sullivan To: apps-discuss@ietf.org Message-ID: <20120327084709.GB11491@mail.yitter.info> References: <053201cd0b5d$c08c80f0$41a582d0$@packetizer.com> <20120326150556.GC3557@mail.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [apps-discuss] Webfinger discussion X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 27 Mar 2012 08:47:15 -0000 On Mon, Mar 26, 2012 at 02:31:30PM -0400, Bob Wyman wrote: > un-recommended!). If people did, in fact, use WebFinger to record such > stuff, the concerns you mentioned would be relevant. Thus, it might make > sense for the Security Considerations section to suggest that one should > think carefully before using WebFinger to provide such dynamic information. Right, that's most of what I was trying to say. I do have a concern that collecting a bunch of different information about a given person and linking it together in a single, easy to access repository has some potential security side effects (not just privacy ones, but those too, of course) that are not clearly highlighted in the security considerations. I suppose one could argue that facebook's (or pick your poison) user population shows nobody cares about that, but I think it would still be good to have some observations about those effects. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From john-ietf@jck.com Tue Mar 27 03:52:49 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1148221F88C1 for ; Tue, 27 Mar 2012 03:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.694 X-Spam-Level: X-Spam-Status: No, score=-102.694 tagged_above=-999 required=5 tests=[AWL=-0.095, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9KEdoe2tT-j for ; Tue, 27 Mar 2012 03:52:47 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id D7ECC21F88C0 for ; Tue, 27 Mar 2012 03:52:42 -0700 (PDT) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1SCTwH-0006QQ-7e; Tue, 27 Mar 2012 06:47:45 -0400 Date: Tue, 27 Mar 2012 06:52:31 -0400 From: John C Klensin To: Andrew Sullivan , apps-discuss@ietf.org Message-ID: <8D0CAE073DF47CFA986CE5F5@PST.JCK.COM> In-Reply-To: <20120327084709.GB11491@mail.yitter.info> References: <053201cd0b5d$c08c80f0$41a582d0$@packetizer.com> <20120326150556.GC3557@mail.yitter.info> <20120327084709.GB11491@mail.yitter.info> 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 Subject: Re: [apps-discuss] Webfinger discussion X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 27 Mar 2012 10:52:49 -0000 --On Tuesday, March 27, 2012 04:47 -0400 Andrew Sullivan wrote: > I suppose one could argue that facebook's (or pick > your poison) user population shows nobody cares about that, > but I think it would still be good to have some observations > about those effects. While Facebook (and others who think that Facebook-style social networks are taking over the world, or that the world is turning into them) are fond of making that inference, I think we need to keep in mind that the total number of active Facebook users remains a very small fraction of the number of people who are using the Internet and who could, in principle, join Facebook. Statistically, we know just nothing about that larger population and what they do and do not care about. We don't even know what fraction of them are not on Facebook because of those concerns. john From chi880466@gmail.com Tue Mar 27 06:49:14 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D71C821E81D1 for ; Tue, 27 Mar 2012 06:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.403 X-Spam-Level: * X-Spam-Status: No, score=1.403 tagged_above=-999 required=5 tests=[AWL=-0.948, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9VNsC9sctRvF for ; Tue, 27 Mar 2012 06:49:13 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id BA0EE21E81D9 for ; Tue, 27 Mar 2012 06:49:13 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so3907936vbb.31 for ; Tue, 27 Mar 2012 06:49:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=q0owiNEmUC2HNUB3+oMrlwKZteeyJ9BtWRYb4oIKZD8=; b=h+TvNzveFpwOKUHlkX/Z1k2aktElfISA4wSsOWgsXH0UqNBVnnw9xLJ+H2Zh3WR67h W0ssMpMTg9ReINIZtlt5l7TcXyuSqAdufhB0+GtyL0t2WJ5PBTks9YSWFBFfwaKSj1Zp BiDKuqpxVF0Pt7xQ+MxTdOfvdaODiW7pqmhhaobiwEsFGKQLhGSGmmV8Y7SlCt9ciFE+ Jh79l1NcvWEUgzyl5L0fpCiGko933CfDVRrdZoHF4q7/MIIrJUfoVB578syzmxxFh65n yfSfAtq0xVUocXZZrSd7PWU4zTkNEgANk4I7R67BseFkonBMRJZ+crL/FldYjG4SEa6u SknA== MIME-Version: 1.0 Received: by 10.52.19.196 with SMTP id h4mr9997576vde.91.1332856152983; Tue, 27 Mar 2012 06:49:12 -0700 (PDT) Received: by 10.220.1.4 with HTTP; Tue, 27 Mar 2012 06:49:12 -0700 (PDT) In-Reply-To: <4F7172FE.6060207@gmx.de> References: <4F7172FE.6060207@gmx.de> Date: Tue, 27 Mar 2012 22:49:12 +0900 Message-ID: From: =?EUC-KR?B?wfa827/4IEphbWVzIFNvbmd3b24gQ2hp?= To: Julian Reschke Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Confusing JSON Pointer X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 27 Mar 2012 13:49:15 -0000 2012=B3=E2 3=BF=F9 27=C0=CF =BF=C0=C8=C4 4:57, Julian Reschke =B4=D4=C0=C7 =B8=BB: > On 2012-03-27 07:22, =C1=F6=BC=DB=BF=F8 James Songwon Chi wrote: >> >> After reading JSON Pointer (draft-ietf-appsawg-json-pointer-01), I am >> confused with encoding or escape scheme. >> For me, it is an ambiguous scheme. For example, a reference token >> "ref/1" can be expressed following ways: >> >> 1) If it is a URI fragment identifier and a JSON Pointer >> Step 1. apply URI encoding: ref%5C1 >> Step 2. apply JSON Pointer encoding: ref%5C1 >> Final result: ref%5C1 >> >> 2) If it is a JSON Pointer and a URI fragment identifier >> Step 1. apply JSON Pointer encoding: ref^/1 >> Step 2. apply URI encoding: ref^%5C1 >> Final result: ref^%5C1 >> >> I expected the same results. >> >> And if my interpretation is wrong, to prevent the similar question, >> there should be some examples for this kind. >> ... > > > I don't understand the question. > > The spec states how to put JSON Pointers (^-escaping) into fragment > identifiers (%-escaping). > > As far as I can tell the outcome then is what you have under 2), no? > > Best regards, Julian Thank you Julian for the reply. Yes. Answer is 2) for above question. Well, but I gave a wrong question and a wrong example (And solidus is 0x2F, not 0x5C.) This is corrected one: If I want a JSON Pointer to be represented as both a JSON String and a URI fragment identifier, I should apply three encoding scheme. There are two sequences with example: 1) step 1. JSON Pointer escape: ref^/1 step 2. JSON String escape: ref^\/1 step 3. URI encoding: ref^\%2F1 2) step 1. JSON Pointer escape: ref^/1 step 2. URI encoding: ref^%2F1 step 3. JSON String escape: ref^%2F1 The results are same except only when there is a solidus and it is encoded as '\/' during JSON String encoding. As in the example, ref^/1 becomes either ref^\%2F1 or ref^%2F1 ( differs = '\'). Note that JSON String allows multiple encodings for a character. For a soldus(/) there are four possible encodings - '/', '\/', '\u002F', and '\u002f'. Also URI encoding allows multiple encodings in case of percentage encoding - %2F and %2f. Any comment? James From andreas@sbin.se Tue Mar 27 07:03:50 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D56621E81F8 for ; Tue, 27 Mar 2012 07:03:50 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ERdmk+hCBXDx for ; Tue, 27 Mar 2012 07:03:49 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id C552E21E81F7 for ; Tue, 27 Mar 2012 07:03:48 -0700 (PDT) Received: from hetzer (oslo.jvpn.opera.com [213.236.208.46]) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q2RE3jhH011874; Tue, 27 Mar 2012 14:03:45 GMT Date: Tue, 27 Mar 2012 16:03:43 +0200 From: Andreas Petersson To: Julian Reschke Message-ID: <20120327160343.45e7e832@hetzer> In-Reply-To: <4F71721A.7010301@gmx.de> References: <20120326151030.7902.33251.idtracker@ietfa.amsl.com> <20120326173417.6058d1f6@hetzer> <4F71721A.7010301@gmx.de> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.24.6; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-http-forwarded-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 27 Mar 2012 14:03:50 -0000 On Tue, 27 Mar 2012 09:54:02 +0200 Julian Reschke wrote: > On 2012-03-27 09:41, Martin Thomson wrote: > > On 26 March 2012 17:34, Andreas Petersson wrote: > >> I believe there is not much left to fix in this draft. > >> My biggest concern right now is this: > >> > >> extension = 1*( ALPHA | DIGIT | "-" ) > >> ext-value = >> but including SP> > >> > >> Is that too liberal? Should recommendations be done in this draft on > >> what character encoding should be used? > > > > Why not use the normal token / quoted-string constructs? > > Yes, please. > For ext-value I assume you mean? > Also, it's no entirely clear why the spec depends on RFC 2616, not > HTTPbis (although it copies some of its style). > Because HTTPbis is not an RFC yet. When we started working on this draft it was unclear both when this draft will be finished and when HTTPbis will be finished. If HTTPbis becomes an RFC before this one, I intend to make adjustments to this one to refer to HTTPbis and also use ABNF as used in HTTPbis instead of RFC2616-style BNF. > Finally, as noted in other WGs: please do not special case the syntax of > certain parameters. Just define *all* of them to be > > token / quoted-string > > and then define additional constrains separately (see epic discussions > in OAuth and WebSec). I don't see the point in this. If you can't motivate it in one e-mail I doubt there is a good one. :-) /Andreas Petersson From julian.reschke@gmx.de Tue Mar 27 07:23:07 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A80A721F88EB for ; Tue, 27 Mar 2012 07:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.755 X-Spam-Level: X-Spam-Status: No, score=-102.755 tagged_above=-999 required=5 tests=[AWL=-2.906, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l7UkKK0X4IVC for ; Tue, 27 Mar 2012 07:23:07 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 8E26C21F889B for ; Tue, 27 Mar 2012 07:23:06 -0700 (PDT) Received: (qmail invoked by alias); 27 Mar 2012 14:23:05 -0000 Received: from mail.greenbytes.de (EHLO [IPv6:::1]) [217.91.35.233] by mail.gmx.net (mp038) with SMTP; 27 Mar 2012 16:23:05 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/g5WR3fOjgIcOhSNquVwWzYN5oeoUT8RzXhttgQD OQOnIBRJgqHGac Message-ID: <4F71CD46.5070603@gmx.de> Date: Tue, 27 Mar 2012 16:23:02 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: =?EUC-KR?B?wfa827/4IEphbWVzIFNvbmd3b24gQ2hp?= References: <4F7172FE.6060207@gmx.de> In-Reply-To: Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Confusing JSON Pointer X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 27 Mar 2012 14:23:08 -0000 On 2012-03-27 15:49, Áö¼Û¿ø James Songwon Chi wrote: > 2012³â 3¿ù 27ÀÏ ¿ÀÈÄ 4:57, Julian Reschke´ÔÀÇ ¸»: >> On 2012-03-27 07:22, Áö¼Û¿ø James Songwon Chi wrote: >>> >>> After reading JSON Pointer (draft-ietf-appsawg-json-pointer-01), I am >>> confused with encoding or escape scheme. >>> For me, it is an ambiguous scheme. For example, a reference token >>> "ref/1" can be expressed following ways: >>> >>> 1) If it is a URI fragment identifier and a JSON Pointer >>> Step 1. apply URI encoding: ref%5C1 >>> Step 2. apply JSON Pointer encoding: ref%5C1 >>> Final result: ref%5C1 >>> >>> 2) If it is a JSON Pointer and a URI fragment identifier >>> Step 1. apply JSON Pointer encoding: ref^/1 >>> Step 2. apply URI encoding: ref^%5C1 >>> Final result: ref^%5C1 >>> >>> I expected the same results. >>> >>> And if my interpretation is wrong, to prevent the similar question, >>> there should be some examples for this kind. >>> ... >> >> >> I don't understand the question. >> >> The spec states how to put JSON Pointers (^-escaping) into fragment >> identifiers (%-escaping). >> >> As far as I can tell the outcome then is what you have under 2), no? >> >> Best regards, Julian > > Thank you Julian for the reply. > Yes. Answer is 2) for above question. Well, but I gave a wrong > question and a wrong example (And solidus is 0x2F, not 0x5C.) > > This is corrected one: > > If I want a JSON Pointer to be represented as both a JSON String and a > URI fragment identifier, I should apply three encoding scheme. > There are two sequences with example: > ... You convert *either* to a string *or* to a URI fragment. Never both. > ... Best regards, Julian From julian.reschke@gmx.de Tue Mar 27 07:29:53 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0877C21F8939 for ; Tue, 27 Mar 2012 07:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.111 X-Spam-Level: X-Spam-Status: No, score=-104.111 tagged_above=-999 required=5 tests=[AWL=-1.512, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wYVCXvjT-bG5 for ; Tue, 27 Mar 2012 07:29:52 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id E8A1621F8935 for ; Tue, 27 Mar 2012 07:29:51 -0700 (PDT) Received: (qmail invoked by alias); 27 Mar 2012 14:29:50 -0000 Received: from mail.greenbytes.de (EHLO [IPv6:::1]) [217.91.35.233] by mail.gmx.net (mp038) with SMTP; 27 Mar 2012 16:29:50 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/M3AFj1XLMaOc57ElHF6WLCgChsuogdNb1KmpwT8 UteuuZEB1AHITT Message-ID: <4F71CEDA.50502@gmx.de> Date: Tue, 27 Mar 2012 16:29:46 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Andreas Petersson References: <20120326151030.7902.33251.idtracker@ietfa.amsl.com> <20120326173417.6058d1f6@hetzer> <4F71721A.7010301@gmx.de> <20120327160343.45e7e832@hetzer> In-Reply-To: <20120327160343.45e7e832@hetzer> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-http-forwarded-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 27 Mar 2012 14:29:53 -0000 On 2012-03-27 16:03, Andreas Petersson wrote: > ... >>> Why not use the normal token / quoted-string constructs? >> >> Yes, please. >> > > For ext-value I assume you mean? Yes. >> Also, it's no entirely clear why the spec depends on RFC 2616, not >> HTTPbis (although it copies some of its style). >> > > Because HTTPbis is not an RFC yet. When we started working on this draft > it was unclear both when this draft will be finished and when HTTPbis > will be finished. If HTTPbis becomes an RFC before this one, I intend to > make adjustments to this one to refer to HTTPbis and also use ABNF as > used in HTTPbis instead of RFC2616-style BNF. Ack. Note that we now have the first spec in the RFC Editor queue with a normative reference to HTTPbis. >> Finally, as noted in other WGs: please do not special case the syntax of >> certain parameters. Just define *all* of them to be >> >> token / quoted-string >> >> and then define additional constrains separately (see epic discussions >> in OAuth and WebSec). > > I don't see the point in this. If you can't motivate it in one e-mail I > doubt there is a good one. :-) The reason is that if you special-case the value syntax based on the parameter name, you'll end up - writing a custom parser (and most custom parsers I've seen a incredibly broken), or - using a generic parser (and accept values that the ABNF says are invalid, causing interop problems with other implementations). The simplest possible approach is to allow the same syntax for all parameters. Best regards, Julian PS: I think we need a downfall clip about this; maybe Jari can help me with that () From paulej@packetizer.com Tue Mar 27 09:15:23 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D7A621F89AF for ; Tue, 27 Mar 2012 09:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KojubcqskyNR for ; Tue, 27 Mar 2012 09:15:22 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id D620C21F8972 for ; Tue, 27 Mar 2012 09:15:20 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q2RGFIbd011441 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 27 Mar 2012 12:15:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1332864919; bh=nmXI1JdiPGkzh+DozpDzeA6akfC2ez192EGbelRBK88=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=d/nnTjqE9UE28dudRJ1+8GT9r8MkfIZ61yGWVjCGvRNDRPbVqbXu4rwrwlee2smXY Zsy3b8Fb9QrpdMirYKH/qT12FMvTaxm47pFEYAFE8HmIffcrZChzE0seukkdXNv6JQ //zbdSTZQx5TmXK3oeV2ULCjecHoHjsjvGVq1+Ns= From: "Paul E. Jones" To: "'Andrew Sullivan'" , References: <053201cd0b5d$c08c80f0$41a582d0$@packetizer.com> <20120326150556.GC3557@mail.yitter.info> <20120327084709.GB11491@mail.yitter.info> In-Reply-To: <20120327084709.GB11491@mail.yitter.info> Date: Tue, 27 Mar 2012 12:15:21 -0400 Message-ID: <00ac01cd0c34$cfc96f10$6f5c4d30$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEg174HJISLlkWDD0VVkXSpmVuZQwKMareXAWwgTx8BwaaRJZeo6B0A Content-Language: en-us Subject: Re: [apps-discuss] Webfinger discussion X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 27 Mar 2012 16:15:23 -0000 I agree it would be useful to add text about sharing information that might be dynamic in nature (e.g., current user location). We'll add text along those lines to the next draft. Any other security considerations we should note? Paul > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] > On Behalf Of Andrew Sullivan > Sent: Tuesday, March 27, 2012 4:47 AM > To: apps-discuss@ietf.org > Subject: Re: [apps-discuss] Webfinger discussion > > On Mon, Mar 26, 2012 at 02:31:30PM -0400, Bob Wyman wrote: > > > un-recommended!). If people did, in fact, use WebFinger to record such > > stuff, the concerns you mentioned would be relevant. Thus, it might > > make sense for the Security Considerations section to suggest that one > > should think carefully before using WebFinger to provide such dynamic > information. > > Right, that's most of what I was trying to say. I do have a concern that > collecting a bunch of different information about a given person and > linking it together in a single, easy to access repository has some > potential security side effects (not just privacy ones, but those too, of > course) that are not clearly highlighted in the security considerations. > I suppose one could argue that facebook's (or pick your poison) user > population shows nobody cares about that, but I think it would still be > good to have some observations about those effects. > > Best, > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From jasnell@gmail.com Tue Mar 27 09:39:57 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF9AD21E80F4 for ; Tue, 27 Mar 2012 09:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.099 X-Spam-Level: X-Spam-Status: No, score=-7.099 tagged_above=-999 required=5 tests=[AWL=-3.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6XaNnhQqyp6L for ; Tue, 27 Mar 2012 09:39:55 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id 871B221E80ED for ; Tue, 27 Mar 2012 09:39:46 -0700 (PDT) Received: by wibhr17 with SMTP id hr17so4896235wib.1 for ; Tue, 27 Mar 2012 09:39:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=KePBJG03YLHMIvMNRh1rWNn7GE5tPHC/SWIzI3u1UM4=; b=pl+fHj8hW6KmwMOTwLjebxwaj1EZAonvRpcmJUyXmusMktQqK/D6vQX1RCiaIr834F 1wSa1LaPSCBvwSdxY1mwu6l32aUri1n/nvNzvnPVtjFCu15LAvDHHdCrqIxIl6N2usqB 3ejCy8DXWMcP2ckOmtQEIxZpp5kdmrXlcZBWwLJio02Yn+42ju/+o4+ZSEEQy+iLK0af Nf02jkq8wP/tdj4qLf69YIQasSbsJ1awxTN/2QH7c4/b0FVXCIcJf7vo8w7DtaoAyNgt 0Basp5yNggffopq20zc/KL91V7DA3j8w4M0S/62SJiK3s7vH+R/iQOsHNQFGM+oo/UGA bHCQ== Received: by 10.216.132.151 with SMTP id o23mr14845265wei.120.1332866385559; Tue, 27 Mar 2012 09:39:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.89.138 with HTTP; Tue, 27 Mar 2012 09:39:25 -0700 (PDT) In-Reply-To: <00ac01cd0c34$cfc96f10$6f5c4d30$@packetizer.com> References: <053201cd0b5d$c08c80f0$41a582d0$@packetizer.com> <20120326150556.GC3557@mail.yitter.info> <20120327084709.GB11491@mail.yitter.info> <00ac01cd0c34$cfc96f10$6f5c4d30$@packetizer.com> From: James M Snell Date: Tue, 27 Mar 2012 09:39:25 -0700 Message-ID: To: "Paul E. Jones" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Webfinger discussion X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 27 Mar 2012 16:39:58 -0000 To be fair, there are ways of dealing with the potential for security leaks of this nature with WebFinger that did not really exist with the original Finger protocol. OAuth 2, for instance. A WebFinger endpoint could choose to serve up only the most basic static information to unauthenticated requesters, but then provide a means for a requester to authenticate and request permission from the target user or provider to acquire additional information as part of the response. On a side note to Paul: I did have some additional general comments on the WebFinger spec itself, I wanted to ask where such comments would be best directed for discussion. - James On Tue, Mar 27, 2012 at 9:15 AM, Paul E. Jones wrot= e: > I agree it would be useful to add text about sharing information that mig= ht > be dynamic in nature (e.g., current user location). > > We'll add text along those lines to the next draft. =C2=A0Any other secur= ity > considerations we should note? > > Paul > >> -----Original Message----- >> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.or= g] >> On Behalf Of Andrew Sullivan >> Sent: Tuesday, March 27, 2012 4:47 AM >> To: apps-discuss@ietf.org >> Subject: Re: [apps-discuss] Webfinger discussion >> >> On Mon, Mar 26, 2012 at 02:31:30PM -0400, Bob Wyman wrote: >> >> > un-recommended!). If people did, in fact, use WebFinger to record such >> > stuff, the concerns you mentioned would be relevant. Thus, it might >> > make sense for the Security Considerations section to suggest that one >> > should think carefully before using WebFinger to provide such dynamic >> information. >> >> Right, that's most of what I was trying to say. =C2=A0I do have a concer= n that >> collecting a bunch of different information about a given person and >> linking it together in a single, easy to access repository has some >> potential security side effects (not just privacy ones, but those too, o= f >> course) that are not clearly highlighted in the security considerations. >> I suppose one could argue that facebook's (or pick your poison) user >> population shows nobody cares about that, but I think it would still be >> good to have some observations about those effects. >> >> Best, >> >> A >> >> -- >> Andrew Sullivan >> ajs@anvilwalrusden.com >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From paulej@packetizer.com Tue Mar 27 09:57:31 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDADC21E8222 for ; Tue, 27 Mar 2012 09:57:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.481 X-Spam-Level: X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bGCBm7kCSHGJ for ; Tue, 27 Mar 2012 09:57:31 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 1E1F221E80D0 for ; Tue, 27 Mar 2012 09:57:31 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q2RGvSn8012362 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 27 Mar 2012 12:57:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1332867449; bh=7q2ca26y+fe6cNccSJtBAOFJUPA5BPKBE2/YyidVq9E=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=pTiLp4XoN9pPPFPPGBAt6VDa17hIes7A11aIWovWmLcGiVZI0JtVHiOeecMGGbCbr rfKKkVI+eJKhTTeJMO3jK2dKabkAM7sBdcsUSL/oh4kH0QLH6qBw01E0+IIC4geth0 UX62tDqUgiW+9dGF23jKGua4ODy+BbsgKYekICek= From: "Paul E. Jones" To: "'James M Snell'" References: <053201cd0b5d$c08c80f0$41a582d0$@packetizer.com> <20120326150556.GC3557@mail.yitter.info> <20120327084709.GB11491@mail.yitter.info> <00ac01cd0c34$cfc96f10$6f5c4d30$@packetizer.com> In-Reply-To: Date: Tue, 27 Mar 2012 12:57:31 -0400 Message-ID: <00d201cd0c3a$b3672410$1a356c30$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEg174HJISLlkWDD0VVkXSpmVuZQwKMareXAWwgTx8BwaaRJQGG5wouAU3B5AaXkk7QgA== Content-Language: en-us Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Webfinger discussion X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 27 Mar 2012 16:57:32 -0000 James, If the other items are editorial, perhaps just direct them to me. If = they are items that others might want to weigh in on, then this list is = the appropriate venue. Paul > -----Original Message----- > From: James M Snell [mailto:jasnell@gmail.com] > Sent: Tuesday, March 27, 2012 12:39 PM > To: Paul E. Jones > Cc: Andrew Sullivan; apps-discuss@ietf.org > Subject: Re: [apps-discuss] Webfinger discussion >=20 > To be fair, there are ways of dealing with the potential for security > leaks of this nature with WebFinger that did not really exist with the > original Finger protocol. OAuth 2, for instance. A WebFinger endpoint > could choose to serve up only the most basic static information to > unauthenticated requesters, but then provide a means for a requester = to > authenticate and request permission from the target user or provider = to > acquire additional information as part of the response. >=20 > On a side note to Paul: I did have some additional general comments on = the > WebFinger spec itself, I wanted to ask where such comments would be = best > directed for discussion. >=20 > - James >=20 > On Tue, Mar 27, 2012 at 9:15 AM, Paul E. Jones > wrote: > > I agree it would be useful to add text about sharing information = that > > might be dynamic in nature (e.g., current user location). > > > > We'll add text along those lines to the next draft. Any other > > security considerations we should note? > > > > Paul > > > >> -----Original Message----- > >> From: apps-discuss-bounces@ietf.org > >> [mailto:apps-discuss-bounces@ietf.org] > >> On Behalf Of Andrew Sullivan > >> Sent: Tuesday, March 27, 2012 4:47 AM > >> To: apps-discuss@ietf.org > >> Subject: Re: [apps-discuss] Webfinger discussion > >> > >> On Mon, Mar 26, 2012 at 02:31:30PM -0400, Bob Wyman wrote: > >> > >> > un-recommended!). If people did, in fact, use WebFinger to record > >> > such stuff, the concerns you mentioned would be relevant. Thus, = it > >> > might make sense for the Security Considerations section to = suggest > >> > that one should think carefully before using WebFinger to provide > >> > such dynamic > >> information. > >> > >> Right, that's most of what I was trying to say. I do have a = concern > >> that collecting a bunch of different information about a given = person > >> and linking it together in a single, easy to access repository has > >> some potential security side effects (not just privacy ones, but > >> those too, of > >> course) that are not clearly highlighted in the security > considerations. > >> I suppose one could argue that facebook's (or pick your poison) = user > >> population shows nobody cares about that, but I think it would = still > >> be good to have some observations about those effects. > >> > >> Best, > >> > >> A > >> > >> -- > >> Andrew Sullivan > >> ajs@anvilwalrusden.com > >> _______________________________________________ > >> apps-discuss mailing list > >> apps-discuss@ietf.org > >> https://www.ietf.org/mailman/listinfo/apps-discuss > > > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss From bobwyman@gmail.com Tue Mar 27 10:00:30 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED2EE21E8048 for ; Tue, 27 Mar 2012 10:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.115 X-Spam-Level: X-Spam-Status: No, score=-2.115 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9dgPUiZPwq7 for ; Tue, 27 Mar 2012 10:00:29 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 8E91A21E80A5 for ; Tue, 27 Mar 2012 10:00:29 -0700 (PDT) Received: by qaea16 with SMTP id a16so273916qae.10 for ; Tue, 27 Mar 2012 10:00:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=mCCDk+CnVzxbDv2pukC+oi01h0iB9ppl/5lGcg4TlgY=; b=Zt7J+wbFQ+Kx35UhPmEnqrprnHmP3LaSf8cu3QdPZ6unmTCWHUvH8T376xHuAvrOmW mFZRUQsEDfFddbrOOOlScEqg85/j2jHmX3HVJnpzNyUngNJoOlM4vkIHuqi991oQo/Xb rEAYep/kYtNhke1FmanmvF0t9k/NA4TO4zMxLQCVLcsJtf0VmoD/sElnkFEdSnLHt32H F7baggfKBSPXHgkBgI3c5SxrwS8AL/FYB/a4uz/N0OUgxTgbWJCGTMLQqnNvQAglfFZ7 Tt1DjuiUnZn+ij3jxVU5RN/9BRX5k4uqwTWf+vu4/miiVwnX4pse41JKnScw+6/m79ei DrFw== MIME-Version: 1.0 Received: by 10.224.73.12 with SMTP id o12mr33295730qaj.98.1332867626187; Tue, 27 Mar 2012 10:00:26 -0700 (PDT) Sender: bobwyman@gmail.com Received: by 10.229.157.16 with HTTP; Tue, 27 Mar 2012 10:00:26 -0700 (PDT) In-Reply-To: <4F70EE0F.8090706@stpeter.im> References: <053201cd0b5d$c08c80f0$41a582d0$@packetizer.com> <20120326150556.GC3557@mail.yitter.info> <4F70EE0F.8090706@stpeter.im> Date: Tue, 27 Mar 2012 13:00:26 -0400 X-Google-Sender-Auth: WfuCI1MIlUdPiSy4HOBYWyxAkdA Message-ID: From: Bob Wyman To: Peter Saint-Andre Content-Type: multipart/alternative; boundary=20cf3074b5a2643b0e04bc3c6d56 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Webfinger discussion X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 27 Mar 2012 17:00:31 -0000 --20cf3074b5a2643b0e04bc3c6d56 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Mar 26, 2012 at 6:30 PM, Peter Saint-Andre wrote: > On 3/26/12 8:31 PM, Bob Wyman wrote: > > > > > > On Mon, Mar 26, 2012 at 11:05 AM, Andrew Sullivan > > > wrote: > > > > On Mon, Mar 26, 2012 at 10:35:54AM -0400, Paul E. Jones wrote: > > > > > > Andrew Sullivan: when I was a kid, they told us to turn off > > finger, so I'm > > > > concerned about security > > > > > > That was due to the fact the finger protocol implementations had > > security > > > holes. It was also possible to do things like "ln /etc/password > > .plan" and > > > that was a bad thing :-) > > > > That wasn't the only reason they told us this. One of the things > that > > people used to worry about was that finger leaked information. In > > particular, it was an excellent way to identify targets for account > > takeover: people who never logged in, and people who were in for > > endless days and therefore whose account was probably often > > unmonitored. > > > > WebFinger has primarily been used for providing access to relatively > > static data rather than for the kind of dynamic "presence" information > > that finger was often used for. Thus, when folk are thinking about > > WebFinger, they are usually considering use cases like "locating a > > user's blog," or "finding a user's public key." However, there isn't > > anything in WebFinger that would prevent providing dynamic data such as > > "current location (lat/long)," "logged in state," or even "last command > > issued to bash..." (highly un-recommended!). If people did, in fact, use > > WebFinger to record such stuff, the concerns you mentioned would be > > relevant. Thus, it might make sense for the Security Considerations > > section to suggest that one should think carefully before using > > WebFinger to provide such dynamic information. > > We already have protocols for such dynamic publish/subscribe features > (and those protocols include ways to authorize who can see what). > Certainly there are other protocols that are much better suited for the sharing of dynamic information than is WebFinger. However, it is generally the case that if a protocol *can* be used to address some need, it* will*be used to address that need. Thus, I think we need to anticipate that some folk will, in fact, share dynamic information with WebFinger even if it is not the optimal protocol for that purpose. Folk will do this for no other reason than that they will wish to minimize the complexity of their implementations by doing as much as they can with one mechanism. Others will do it because they don't know of the alternatives. I support the inclusion of pointers in the WebFinger spec to other protocols that are better suited for the sharing of dynamic, rapidly changing information. > Webfinger might provide pointers to locations where one could subscribe > to dynamic data, but AFAIK it would not be used to pull the data. > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > > > --20cf3074b5a2643b0e04bc3c6d56 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Mar 26, 2012 at 6:30 PM, Peter S= aint-Andre <stpe= ter@stpeter.im> wrote:
On 3/26/12 8:31 PM, Bob Wyman wrote:
>
>
> On Mon, Mar 26, 2012 at 11:05 AM, Andrew Sullivan
> <ajs@anvilwalrusden.com <mailto:ajs@anvilwalrusden.com>> wrote:
>
> =A0 =A0 On Mon, Mar 26, 2012 at 10:35:54AM -0400, Paul E. Jones wrote:=
>
> =A0 =A0 > > Andrew Sullivan: when I was a kid, they told us to t= urn off
> =A0 =A0 finger, so I'm
> =A0 =A0 > > concerned about security
> =A0 =A0 >
> =A0 =A0 > That was due to the fact the finger protocol implementati= ons had
> =A0 =A0 security
> =A0 =A0 > holes. =A0It was also possible to do things like "ln= /etc/password
> =A0 =A0 .plan" and
> =A0 =A0 > that was a bad thing :-)
>
> =A0 =A0 That wasn't the only reason they told us this. =A0One of t= he things that
> =A0 =A0 people used to worry about was that finger leaked information.= =A0In
> =A0 =A0 particular, it was an excellent way to identify targets for ac= count
> =A0 =A0 takeover: people who never logged in, and people who were in f= or
> =A0 =A0 endless days and therefore whose account was probably often > =A0 =A0 unmonitored.
>
> WebFinger has primarily been used for providing access to relatively > static data rather than for the kind of dynamic "presence" i= nformation
> that finger was often used for. Thus, when folk are thinking about
> WebFinger, they are usually considering use cases like "locating = a
> user's blog," or "finding a user's public key."= However, there isn't
> anything in WebFinger that would prevent providing dynamic data such a= s
> "current location (lat/long)," "logged in state," = or even "last command
> issued to bash..." (highly un-recommended!). If people did, in fa= ct, use
> WebFinger to record such stuff, the concerns you mentioned would be > relevant. Thus, it might make sense for the Security Considerations > section to suggest that one should think carefully before using
> WebFinger to provide such dynamic information.

We already have protocols for such dynamic publish/subscribe fe= atures
(and those protocols include ways to authorize who can see what).
Certainly there are other protocols that are much better suited= for the sharing of dynamic information than is WebFinger. However, it is g= enerally the case that if a protocol can be used to address some nee= d, it will be used to address that need. Thus, I think we need to an= ticipate that some folk will, in fact, share dynamic information with WebFi= nger even if it is not the optimal protocol for that purpose. Folk will do = this for no other reason than that they will wish to minimize the complexit= y of their implementations by doing as much as they can with one mechanism.= Others will do it because they don't know of the alternatives.

I support the inclusion of pointers in the WebFinger sp= ec to other protocols that are better suited for the sharing of dynamic, ra= pidly changing information.=A0
=A0
Webfinger might provide pointers to locations where one could subscribe
to dynamic data, but AFAIK it would not be used to pull the data.

Peter

--
Peter Saint-Andre
https://stpeter.im/


--20cf3074b5a2643b0e04bc3c6d56-- From bobwyman@gmail.com Tue Mar 27 10:18:12 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B28521F8855 for ; Tue, 27 Mar 2012 10:18:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.468 X-Spam-Level: X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=0.508, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kM4ooeKWItTk for ; Tue, 27 Mar 2012 10:18:11 -0700 (PDT) Received: from mail-qa0-f43.google.com (mail-qa0-f43.google.com [209.85.216.43]) by ietfa.amsl.com (Postfix) with ESMTP id DA58421F8842 for ; Tue, 27 Mar 2012 10:18:10 -0700 (PDT) Received: by qadb15 with SMTP id b15so4060887qad.16 for ; Tue, 27 Mar 2012 10:18:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=1kJMAvTIvg5IjfrQhKCAAlUphK8bz9VZpTKjTDXpa9w=; b=XO5myRZetl1jkScWtG3hgnz9+bgLpi4KKshaNX8AXLP4rD925kCCeEDtFiuwjTZQts dREEeEdtk0QXmZaUYo1JEGJaazLSIUw+qrZQDV4W/tnjue4n3elBpsWJl/7CpyKQkjRi 4+hifAicIboZIsZeo5gJKWj2CWyofYeA/4QCaFr8pTCd9ObnBmyUPcXxNQgC9x3/+sbl Zi4dJPx61W5cmphk7aqET4TMkQTspGWWwoNx3s7SUuQiJJ092xVbHLm5wEtJzHcbVxpI bAtDwfyZqo73WH0/ARfe/A1bgDElj3oztduxrEGqt0XOHURZAJyVVPAjLyOSBKRTkY+f IZQg== MIME-Version: 1.0 Received: by 10.224.210.129 with SMTP id gk1mr33679760qab.85.1332868689011; Tue, 27 Mar 2012 10:18:09 -0700 (PDT) Sender: bobwyman@gmail.com Received: by 10.229.157.16 with HTTP; Tue, 27 Mar 2012 10:18:08 -0700 (PDT) In-Reply-To: <00d201cd0c3a$b3672410$1a356c30$@packetizer.com> References: <053201cd0b5d$c08c80f0$41a582d0$@packetizer.com> <20120326150556.GC3557@mail.yitter.info> <20120327084709.GB11491@mail.yitter.info> <00ac01cd0c34$cfc96f10$6f5c4d30$@packetizer.com> <00d201cd0c3a$b3672410$1a356c30$@packetizer.com> Date: Tue, 27 Mar 2012 13:18:08 -0400 X-Google-Sender-Auth: UkRHihUDTKn_YM6eFMi0apl7fIg Message-ID: From: Bob Wyman To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=20cf300faca1bda4ba04bc3cac00 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Webfinger discussion X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 27 Mar 2012 17:18:12 -0000 --20cf300faca1bda4ba04bc3cac00 Content-Type: text/plain; charset=ISO-8859-1 Paul, Examples are very powerful means of setting expectations for usage of standards... So, perhaps it would be useful to include in the examples a pointer to a user's "pres:" URI, defined by RFC3859 "Common Profile for Presence", as the endpoint that should be used to obtain "presence" information. bob wyman On Tue, Mar 27, 2012 at 12:57 PM, Paul E. Jones wrote: > James, > > If the other items are editorial, perhaps just direct them to me. If they > are items that others might want to weigh in on, then this list is the > appropriate venue. > > Paul > > > -----Original Message----- > > From: James M Snell [mailto:jasnell@gmail.com] > > Sent: Tuesday, March 27, 2012 12:39 PM > > To: Paul E. Jones > > Cc: Andrew Sullivan; apps-discuss@ietf.org > > Subject: Re: [apps-discuss] Webfinger discussion > > > > To be fair, there are ways of dealing with the potential for security > > leaks of this nature with WebFinger that did not really exist with the > > original Finger protocol. OAuth 2, for instance. A WebFinger endpoint > > could choose to serve up only the most basic static information to > > unauthenticated requesters, but then provide a means for a requester to > > authenticate and request permission from the target user or provider to > > acquire additional information as part of the response. > > > > On a side note to Paul: I did have some additional general comments on > the > > WebFinger spec itself, I wanted to ask where such comments would be best > > directed for discussion. > > > > - James > > > > On Tue, Mar 27, 2012 at 9:15 AM, Paul E. Jones > > wrote: > > > I agree it would be useful to add text about sharing information that > > > might be dynamic in nature (e.g., current user location). > > > > > > We'll add text along those lines to the next draft. Any other > > > security considerations we should note? > > > > > > Paul > > > > > >> -----Original Message----- > > >> From: apps-discuss-bounces@ietf.org > > >> [mailto:apps-discuss-bounces@ietf.org] > > >> On Behalf Of Andrew Sullivan > > >> Sent: Tuesday, March 27, 2012 4:47 AM > > >> To: apps-discuss@ietf.org > > >> Subject: Re: [apps-discuss] Webfinger discussion > > >> > > >> On Mon, Mar 26, 2012 at 02:31:30PM -0400, Bob Wyman wrote: > > >> > > >> > un-recommended!). If people did, in fact, use WebFinger to record > > >> > such stuff, the concerns you mentioned would be relevant. Thus, it > > >> > might make sense for the Security Considerations section to suggest > > >> > that one should think carefully before using WebFinger to provide > > >> > such dynamic > > >> information. > > >> > > >> Right, that's most of what I was trying to say. I do have a concern > > >> that collecting a bunch of different information about a given person > > >> and linking it together in a single, easy to access repository has > > >> some potential security side effects (not just privacy ones, but > > >> those too, of > > >> course) that are not clearly highlighted in the security > > considerations. > > >> I suppose one could argue that facebook's (or pick your poison) user > > >> population shows nobody cares about that, but I think it would still > > >> be good to have some observations about those effects. > > >> > > >> Best, > > >> > > >> A > > >> > > >> -- > > >> Andrew Sullivan > > >> ajs@anvilwalrusden.com > > >> _______________________________________________ > > >> apps-discuss mailing list > > >> apps-discuss@ietf.org > > >> https://www.ietf.org/mailman/listinfo/apps-discuss > > > > > > _______________________________________________ > > > apps-discuss mailing list > > > apps-discuss@ietf.org > > > https://www.ietf.org/mailman/listinfo/apps-discuss > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --20cf300faca1bda4ba04bc3cac00 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Paul,
Examples are very powerful means of setting expectations for usag= e of standards... So, perhaps it would be useful to include in the examples= a pointer to a user's "pres:" URI, defined by RFC3859 "= Common Profile for Presence", as the endpoint that should be used to o= btain "presence" information.=A0

bob wyman

On Tu= e, Mar 27, 2012 at 12:57 PM, Paul E. Jones <paulej@packetizer.com> wrote:<= br>
James,

If the other items are editorial, perhaps just direct them to me. =A0If the= y are items that others might want to weigh in on, then this list is the ap= propriate venue.

Paul

> -----Original Message-----
> From: James M Snell [mailto:jasne= ll@gmail.com]
> Sent: Tuesday, March 27, 2012 12:39 PM
> To: Paul E. Jones
> Cc: Andrew Sullivan; apps-dis= cuss@ietf.org
> Subject: Re: [apps-discuss] Webfinger discussion
>
> To be fair, there are ways of dealing with the potential for security<= br> > leaks of this nature with WebFinger that did not really exist with the=
> original Finger protocol. OAuth 2, for instance. A WebFinger endpoint<= br> > could choose to serve up only the most basic static information to
> unauthenticated requesters, but then provide a means for a requester t= o
> authenticate and request permission from the target user or provider t= o
> acquire additional information as part of the response.
>
> On a side note to Paul: I did have some additional general comments on= the
> WebFinger spec itself, I wanted to ask where such comments would be be= st
> directed for discussion.
>
> - James
>
> On Tue, Mar 27, 2012 at 9:15 AM, Paul E. Jones <paulej@packetizer.com>
> wrote:
> > I agree it would be useful to add text about sharing information = that
> > might be dynamic in nature (e.g., current user location).
> >
> > We'll add text along those lines to the next draft. =A0Any ot= her
> > security considerations we should note?
> >
> > Paul
> >
> >> -----Original Message-----
> >> From: apps-d= iscuss-bounces@ietf.org
> >> [mailto:apps= -discuss-bounces@ietf.org]
> >> On Behalf Of Andrew Sullivan
> >> Sent: Tuesday, March 27, 2012 4:47 AM
> >> To: apps-discuss@iet= f.org
> >> Subject: Re: [apps-discuss] Webfinger discussion
> >>
> >> On Mon, Mar 26, 2012 at 02:31:30PM -0400, Bob Wyman wrote: > >>
> >> > un-recommended!). If people did, in fact, use WebFinger = to record
> >> > such stuff, the concerns you mentioned would be relevant= . Thus, it
> >> > might make sense for the Security Considerations section= to suggest
> >> > that one should think carefully before using WebFinger t= o provide
> >> > such dynamic
> >> information.
> >>
> >> Right, that's most of what I was trying to say. =A0I do h= ave a concern
> >> that collecting a bunch of different information about a give= n person
> >> and linking it together in a single, easy to access repositor= y has
> >> some potential security side effects (not just privacy ones, = but
> >> those too, of
> >> course) that are not clearly highlighted in the security
> considerations.
> >> I suppose one could argue that facebook's (or pick your p= oison) user
> >> population shows nobody cares about that, but I think it woul= d still
> >> be good to have some observations about those effects.
> >>
> >> Best,
> >>
> >> A
> >>
> >> --
> >> Andrew Sullivan
> >> ajs@anvilwalrusden.= com
> >> _______________________________________________
> >> apps-discuss mailing list
> >> apps-discuss@ietf.or= g
> >> https://www.ietf.org/mailman/listinfo/apps-discuss<= br> > >
> > _______________________________________________
> > apps-discuss mailing list
> > apps-discuss@ietf.org
> > https://www.ietf.org/mailman/listinfo/apps-discuss

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

--20cf300faca1bda4ba04bc3cac00-- From paulej@packetizer.com Tue Mar 27 11:06:12 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1789E21E80F0 for ; Tue, 27 Mar 2012 11:06:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.483 X-Spam-Level: X-Spam-Status: No, score=-2.483 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7FZEZsxeQeUa for ; Tue, 27 Mar 2012 11:06:09 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 0E18F21E80EC for ; Tue, 27 Mar 2012 11:06:05 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q2RI64WG014318 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 27 Mar 2012 14:06:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1332871565; bh=TDPdUNUOj52VF2FoCvkg01QqF87JLK+i4L8ME41+c4w=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=aMklbE4Dr3YQBj/Gqxaq0CjaBsCxAuDNz2V+NdxbqnoLyHFZc28GoMAawKXvQbNfT TSIdwkU5zNa8GJfVRb9VcJRBSLjbElE/SoP08vXw7YYaMjOAYXPyTSAIX8sF/dwJlg bIyERl80YZKWcjxofT+0oWfs/1ovxLVmBGT8Stw8= From: "Paul E. Jones" To: "'Bob Wyman'" References: <053201cd0b5d$c08c80f0$41a582d0$@packetizer.com> <20120326150556.GC3557@mail.yitter.info> <20120327084709.GB11491@mail.yitter.info> <00ac01cd0c34$cfc96f10$6f5c4d30$@packetizer.com> <00d201cd0c3a$b3672410$1a356c30$@packetizer.com> In-Reply-To: Date: Tue, 27 Mar 2012 14:06:07 -0400 Message-ID: <00f701cd0c44$48cb87e0$da6297a0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F8_01CD0C22.C1BB2060" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEg174HJISLlkWDD0VVkXSpmVuZQwKMareXAWwgTx8BwaaRJQGG5wouAU3B5AYBuFTkWgH4n5esl3TaDnA= Content-Language: en-us Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Webfinger discussion X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 27 Mar 2012 18:06:12 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00F8_01CD0C22.C1BB2060 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Bob, Is "pres:" being used in practice? Does it refer to SIP or XMPP or other presence protocol? I'll note that adding this one might incite additional concerns for privacy. I assume that whatever protocol to which pres: refers (which is unclear to me) would handle the authorization aspects. But, I'm left wondering. if one knows a person's SIP or XMPP URI, why would one need pres:? Paul From: bobwyman@gmail.com [mailto:bobwyman@gmail.com] On Behalf Of Bob Wyman Sent: Tuesday, March 27, 2012 1:18 PM To: Paul E. Jones Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Webfinger discussion Paul, Examples are very powerful means of setting expectations for usage of standards... So, perhaps it would be useful to include in the examples a pointer to a user's "pres:" URI, defined by RFC3859 "Common Profile for Presence", as the endpoint that should be used to obtain "presence" information. bob wyman On Tue, Mar 27, 2012 at 12:57 PM, Paul E. Jones wrote: James, If the other items are editorial, perhaps just direct them to me. If they are items that others might want to weigh in on, then this list is the appropriate venue. Paul > -----Original Message----- > From: James M Snell [mailto:jasnell@gmail.com] > Sent: Tuesday, March 27, 2012 12:39 PM > To: Paul E. Jones > Cc: Andrew Sullivan; apps-discuss@ietf.org > Subject: Re: [apps-discuss] Webfinger discussion > > To be fair, there are ways of dealing with the potential for security > leaks of this nature with WebFinger that did not really exist with the > original Finger protocol. OAuth 2, for instance. A WebFinger endpoint > could choose to serve up only the most basic static information to > unauthenticated requesters, but then provide a means for a requester to > authenticate and request permission from the target user or provider to > acquire additional information as part of the response. > > On a side note to Paul: I did have some additional general comments on the > WebFinger spec itself, I wanted to ask where such comments would be best > directed for discussion. > > - James > > On Tue, Mar 27, 2012 at 9:15 AM, Paul E. Jones > wrote: > > I agree it would be useful to add text about sharing information that > > might be dynamic in nature (e.g., current user location). > > > > We'll add text along those lines to the next draft. Any other > > security considerations we should note? > > > > Paul > > > >> -----Original Message----- > >> From: apps-discuss-bounces@ietf.org > >> [mailto:apps-discuss-bounces@ietf.org] > >> On Behalf Of Andrew Sullivan > >> Sent: Tuesday, March 27, 2012 4:47 AM > >> To: apps-discuss@ietf.org > >> Subject: Re: [apps-discuss] Webfinger discussion > >> > >> On Mon, Mar 26, 2012 at 02:31:30PM -0400, Bob Wyman wrote: > >> > >> > un-recommended!). If people did, in fact, use WebFinger to record > >> > such stuff, the concerns you mentioned would be relevant. Thus, it > >> > might make sense for the Security Considerations section to suggest > >> > that one should think carefully before using WebFinger to provide > >> > such dynamic > >> information. > >> > >> Right, that's most of what I was trying to say. I do have a concern > >> that collecting a bunch of different information about a given person > >> and linking it together in a single, easy to access repository has > >> some potential security side effects (not just privacy ones, but > >> those too, of > >> course) that are not clearly highlighted in the security > considerations. > >> I suppose one could argue that facebook's (or pick your poison) user > >> population shows nobody cares about that, but I think it would still > >> be good to have some observations about those effects. > >> > >> Best, > >> > >> A > >> > >> -- > >> Andrew Sullivan > >> ajs@anvilwalrusden.com > >> _______________________________________________ > >> apps-discuss mailing list > >> apps-discuss@ietf.org > >> https://www.ietf.org/mailman/listinfo/apps-discuss > > > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss ------=_NextPart_000_00F8_01CD0C22.C1BB2060 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Bob,

 

Is “pres:” being used in practice?  Does it refer to = SIP or XMPP or other presence protocol?

 

I’ll note that adding this one might incite additional concerns = for privacy.  I assume that whatever protocol to which pres: refers = (which is unclear to me) would handle the authorization aspects.  = But, I’m left wondering… if one knows a person’s SIP = or XMPP URI, why would one need pres:?

 

Paul

 

From:= = bobwyman@gmail.com [mailto:bobwyman@gmail.com] On Behalf Of Bob = Wyman
Sent: Tuesday, March 27, 2012 1:18 PM
To: Paul = E. Jones
Cc: apps-discuss@ietf.org
Subject: Re: = [apps-discuss] Webfinger discussion

 

Paul,

Examples = are very powerful means of setting expectations for usage of = standards... So, perhaps it would be useful to include in the examples a = pointer to a user's "pres:" URI, defined by RFC3859 = "Common Profile for Presence", as the endpoint that should be = used to obtain "presence" = information. 

 

bob wyman

 

On Tue, = Mar 27, 2012 at 12:57 PM, Paul E. Jones <paulej@packetizer.com> = wrote:

James,

If the other = items are editorial, perhaps just direct them to me.  If they are = items that others might want to weigh in on, then this list is the = appropriate venue.

Paul


> -----Original Message-----
> From: = James M Snell [mailto:jasnell@gmail.com]
> Sent: = Tuesday, March 27, 2012 12:39 PM
> To: Paul E. Jones
> Cc: = Andrew Sullivan; apps-discuss@ietf.org
> = Subject: Re: [apps-discuss] Webfinger discussion
>
> To be = fair, there are ways of dealing with the potential for security
> = leaks of this nature with WebFinger that did not really exist with = the
> original Finger protocol. OAuth 2, for instance. A WebFinger = endpoint
> could choose to serve up only the most basic static = information to
> unauthenticated requesters, but then provide a = means for a requester to
> authenticate and request permission = from the target user or provider to
> acquire additional = information as part of the response.
>
> On a side note to = Paul: I did have some additional general comments on the
> = WebFinger spec itself, I wanted to ask where such comments would be = best
> directed for discussion.
>
> - = James
>
> On Tue, Mar 27, 2012 at 9:15 AM, Paul E. Jones = <paulej@packetizer.com>
&g= t; wrote:
> > I agree it would be useful to add text about = sharing information that
> > might be dynamic in nature (e.g., = current user location).
> >
> > We'll add text along = those lines to the next draft.  Any other
> > security = considerations we should note?
> >
> > Paul
> = >
> >> -----Original Message-----
> >> From: = apps-discuss-bounces@ietf.o= rg
> >> [mailto:apps-discuss-bounces@ietf.o= rg]
> >> On Behalf Of Andrew Sullivan
> >> = Sent: Tuesday, March 27, 2012 4:47 AM
> >> To: apps-discuss@ietf.org
> = >> Subject: Re: [apps-discuss] Webfinger discussion
> = >>
> >> On Mon, Mar 26, 2012 at 02:31:30PM -0400, Bob = Wyman wrote:
> >>
> >> > un-recommended!). If = people did, in fact, use WebFinger to record
> >> > such = stuff, the concerns you mentioned would be relevant. Thus, it
> = >> > might make sense for the Security Considerations section = to suggest
> >> > that one should think carefully before = using WebFinger to provide
> >> > such dynamic
> = >> information.
> >>
> >> Right, that's = most of what I was trying to say.  I do have a concern
> = >> that collecting a bunch of different information about a given = person
> >> and linking it together in a single, easy to = access repository has
> >> some potential security side = effects (not just privacy ones, but
> >> those too, = of
> >> course) that are not clearly highlighted in the = security
> considerations.
> >> I suppose one could = argue that facebook's (or pick your poison) user
> >> = population shows nobody cares about that, but I think it would = still
> >> be good to have some observations about those = effects.
> >>
> >> Best,
> = >>
> >> A
> >>
> >> --
> = >> Andrew Sullivan
> >> ajs@anvilwalrusden.com
>= >> _______________________________________________
> = >> apps-discuss mailing list
> >> apps-discuss@ietf.org
> = >> https://www.ietf.org/mailman/listinfo/apps-discuss<= br>> >
> > = _______________________________________________
> > = apps-discuss mailing list
> > apps-discuss@ietf.org
> = > https://www.ietf.org/mailman/listinfo/apps-discuss<= br>
_______________________________________________
apps-discuss = mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss<= o:p>

 

------=_NextPart_000_00F8_01CD0C22.C1BB2060-- From bobwyman@gmail.com Tue Mar 27 11:13:15 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D575A21F87D7 for ; Tue, 27 Mar 2012 11:13:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.424, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rDtcA0+9jpHM for ; Tue, 27 Mar 2012 11:13:14 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id A9F8421F87D6 for ; Tue, 27 Mar 2012 11:13:14 -0700 (PDT) Received: by qaea16 with SMTP id a16so320157qae.10 for ; Tue, 27 Mar 2012 11:13:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=VEDHtSy5caLf8IdTNVtdEhZTpEVdrBkWNVnc5OCB92A=; b=itpi6q8gsYVBfkIHEBu6ERs/fRlou+S0PxTY1IiYZ7MmU+ybaMjNOmNvp3cc3txRQr Dme1PbDnJVvkSilz8CqmZwF+vE2C+uhOkIfIErLnkVfHnq3DKdLIT0PFQcCtPJoc/jvR 8pPbnU/3QPap7uSuGBfrCXV3QaBhruFsrkB9mdiFAQhGzBt5VgveFV9uX+KobBIPUpd8 Otv4HAltwr1LQo74Q4340wKk31BnsR/Gwn7gcCMp9Bis+XHHdNp/pY+/u82Hp2HmAVA8 K9P/mLq7Rm+M224yUb2EpdyLb/HPA+fyN2n/Zy08P9WJ4bfP5uT13iExUQnTnA/GqYMG Tjrg== MIME-Version: 1.0 Received: by 10.224.73.12 with SMTP id o12mr33681949qaj.98.1332871992067; Tue, 27 Mar 2012 11:13:12 -0700 (PDT) Sender: bobwyman@gmail.com Received: by 10.229.157.16 with HTTP; Tue, 27 Mar 2012 11:13:12 -0700 (PDT) In-Reply-To: <00f701cd0c44$48cb87e0$da6297a0$@packetizer.com> References: <053201cd0b5d$c08c80f0$41a582d0$@packetizer.com> <20120326150556.GC3557@mail.yitter.info> <20120327084709.GB11491@mail.yitter.info> <00ac01cd0c34$cfc96f10$6f5c4d30$@packetizer.com> <00d201cd0c3a$b3672410$1a356c30$@packetizer.com> <00f701cd0c44$48cb87e0$da6297a0$@packetizer.com> Date: Tue, 27 Mar 2012 14:13:12 -0400 X-Google-Sender-Auth: YxuNvWctKXp-11bVr6aHQSiArMk Message-ID: From: Bob Wyman To: "Paul E. Jones" Content-Type: multipart/alternative; boundary=20cf3074b5a29e461704bc3d712a Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Webfinger discussion X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 27 Mar 2012 18:13:16 -0000 --20cf3074b5a29e461704bc3d712a Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable im: and pres: were defined as protocol independent URI's in order to make things simpler than having to work with XMPP, SIP, and potentially even APEX, etc. as alternative presence or messaging protocols. But, yeah... nobody seems to use the stuff. The fact remains that messaging and presence are still distinct services. So, perhaps an xmpp: URI tagged as both "instant-messaging" and "presence" would make more sense. bob wyman On Tue, Mar 27, 2012 at 2:06 PM, Paul E. Jones wrote= : > Bob,**** > > ** ** > > Is =93pres:=94 being used in practice? Does it refer to SIP or XMPP or o= ther > presence protocol?**** > > ** ** > > I=92ll note that adding this one might incite additional concerns for > privacy. I assume that whatever protocol to which pres: refers (which is > unclear to me) would handle the authorization aspects. But, I=92m left > wondering=85 if one knows a person=92s SIP or XMPP URI, why would one nee= d > pres:?**** > > ** ** > > Paul**** > > ** ** > > *From:* bobwyman@gmail.com [mailto:bobwyman@gmail.com] *On Behalf Of *Bob > Wyman > *Sent:* Tuesday, March 27, 2012 1:18 PM > *To:* Paul E. Jones > *Cc:* apps-discuss@ietf.org > > *Subject:* Re: [apps-discuss] Webfinger discussion**** > > ** ** > > Paul,**** > > Examples are very powerful means of setting expectations for usage of > standards... So, perhaps it would be useful to include in the examples a > pointer to a user's "pres:" URI, defined by RFC3859 "Common Profile for > Presence", as the endpoint that should be used to obtain "presence" > information. **** > > ** ** > > bob wyman**** > > ** ** > > On Tue, Mar 27, 2012 at 12:57 PM, Paul E. Jones > wrote:**** > > James, > > If the other items are editorial, perhaps just direct them to me. If the= y > are items that others might want to weigh in on, then this list is the > appropriate venue. > > Paul**** > > > > -----Original Message----- > > From: James M Snell [mailto:jasnell@gmail.com] > > Sent: Tuesday, March 27, 2012 12:39 PM > > To: Paul E. Jones > > Cc: Andrew Sullivan; apps-discuss@ietf.org > > Subject: Re: [apps-discuss] Webfinger discussion > > > > To be fair, there are ways of dealing with the potential for security > > leaks of this nature with WebFinger that did not really exist with the > > original Finger protocol. OAuth 2, for instance. A WebFinger endpoint > > could choose to serve up only the most basic static information to > > unauthenticated requesters, but then provide a means for a requester to > > authenticate and request permission from the target user or provider to > > acquire additional information as part of the response. > > > > On a side note to Paul: I did have some additional general comments on > the > > WebFinger spec itself, I wanted to ask where such comments would be bes= t > > directed for discussion. > > > > - James > > > > On Tue, Mar 27, 2012 at 9:15 AM, Paul E. Jones > > wrote: > > > I agree it would be useful to add text about sharing information that > > > might be dynamic in nature (e.g., current user location). > > > > > > We'll add text along those lines to the next draft. Any other > > > security considerations we should note? > > > > > > Paul > > > > > >> -----Original Message----- > > >> From: apps-discuss-bounces@ietf.org > > >> [mailto:apps-discuss-bounces@ietf.org] > > >> On Behalf Of Andrew Sullivan > > >> Sent: Tuesday, March 27, 2012 4:47 AM > > >> To: apps-discuss@ietf.org > > >> Subject: Re: [apps-discuss] Webfinger discussion > > >> > > >> On Mon, Mar 26, 2012 at 02:31:30PM -0400, Bob Wyman wrote: > > >> > > >> > un-recommended!). If people did, in fact, use WebFinger to record > > >> > such stuff, the concerns you mentioned would be relevant. Thus, it > > >> > might make sense for the Security Considerations section to sugges= t > > >> > that one should think carefully before using WebFinger to provide > > >> > such dynamic > > >> information. > > >> > > >> Right, that's most of what I was trying to say. I do have a concern > > >> that collecting a bunch of different information about a given perso= n > > >> and linking it together in a single, easy to access repository has > > >> some potential security side effects (not just privacy ones, but > > >> those too, of > > >> course) that are not clearly highlighted in the security > > considerations. > > >> I suppose one could argue that facebook's (or pick your poison) user > > >> population shows nobody cares about that, but I think it would still > > >> be good to have some observations about those effects. > > >> > > >> Best, > > >> > > >> A > > >> > > >> -- > > >> Andrew Sullivan > > >> ajs@anvilwalrusden.com > > >> _______________________________________________ > > >> apps-discuss mailing list > > >> apps-discuss@ietf.org > > >> https://www.ietf.org/mailman/listinfo/apps-discuss > > > > > > _______________________________________________ > > > apps-discuss mailing list > > > apps-discuss@ietf.org > > > https://www.ietf.org/mailman/listinfo/apps-discuss > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss**** > > ** ** > --20cf3074b5a29e461704bc3d712a Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable im: and pres: were defined as protocol independent URI's in order to ma= ke things simpler than having to work with XMPP, SIP, and potentially even = APEX, etc. as alternative presence or messaging protocols. But, yeah... nob= ody seems to use the stuff. The fact remains that messaging and presence ar= e still distinct services. So, perhaps an xmpp: URI tagged as both "in= stant-messaging" and "presence" would make more sense.

bob wyman

On Tue, Mar 27, = 2012 at 2:06 PM, Paul E. Jones <paulej@packetizer.com> wrote:

Bob,

=A0

Is =93pres:=94 being used in practice?=A0 Doe= s it refer to SIP or XMPP or other presence protocol?<= /p>

=A0<= /p>

I=92ll note that addin= g this one might incite additional concerns for privacy.=A0 I assume that w= hatever protocol to which pres: refers (which is unclear to me) would handl= e the authorization aspects.=A0 But, I=92m left wondering=85 if one knows a= person=92s SIP or XMPP URI, why would one need pres:?=

=A0<= /p>

Paul

=A0<= /p>

From: bobwyman@gmai= l.com [mailto:b= obwyman@gmail.com] On Behalf Of Bob Wyman
Sent: Tuesday, March 27, 2012 1:18 PM
To: Paul E. JonesCc: apps= -discuss@ietf.org


Subject: = Re: [apps-discuss] Webfinger discussion

<= /u>=A0

Paul,

Examples are very powerful means of setting expectations fo= r usage of standards... So, perhaps it would be useful to include in the ex= amples a pointer to a user's "pres:" URI, defined by RFC3859 = "Common Profile for Presence", as the endpoint that should be use= d to obtain "presence" information.=A0

=A0

bob wyman

<= /u>=A0

On Tue, Mar 27, 2012 at 12:57 = PM, Paul E. Jones <paulej@packetizer.com> wrote:

James,

If the other items are editorial, perh= aps just direct them to me. =A0If they are items that others might want to = weigh in on, then this list is the appropriate venue.

Paul

=
> -----Original Message-----
> From: James M Snell [mailto:jasnell@gmail.com]<= br> > Sent: Tuesday, March 27, 2012 12:39 PM
> To: Paul E. Jones
&g= t; Cc: Andrew Sullivan; apps-discuss@ietf.org
> Subject: Re: [apps-discuss] Webfi= nger discussion
>
> To be fair, there are ways of dealing with the potential for s= ecurity
> leaks of this nature with WebFinger that did not really exi= st with the
> original Finger protocol. OAuth 2, for instance. A WebF= inger endpoint
> could choose to serve up only the most basic static information to
= > unauthenticated requesters, but then provide a means for a requester t= o
> authenticate and request permission from the target user or provi= der to
> acquire additional information as part of the response.
>
>= ; On a side note to Paul: I did have some additional general comments on th= e
> WebFinger spec itself, I wanted to ask where such comments would = be best
> directed for discussion.
>
> - James
>
> On Tu= e, Mar 27, 2012 at 9:15 AM, Paul E. Jones <paulej@packetizer.com>
> wrote:<= br> > > I agree it would be useful to add text about sharing information = that
> > might be dynamic in nature (e.g., current user location).=
> >
> > We'll add text along those lines to the next= draft. =A0Any other
> > security considerations we should note?
> >
> >= Paul
> >
> >> -----Original Message-----
> >= > From: apps-discuss-bounces@ietf.org
> >> [mailto:apps-discuss-bounces@ietf.org]
> >> On Behalf= Of Andrew Sullivan
> >> Sent: Tuesday, March 27, 2012 4:47 AM<= br> > >> To: apps-discuss@ietf.org
> >> Subject: Re: [apps-discuss] We= bfinger discussion
> >>
> >> On Mon, Mar 26, 2012 a= t 02:31:30PM -0400, Bob Wyman wrote:
> >>
> >> > un-recommended!). If people did, in fac= t, use WebFinger to record
> >> > such stuff, the concerns y= ou mentioned would be relevant. Thus, it
> >> > might make s= ense for the Security Considerations section to suggest
> >> > that one should think carefully before using WebFinger t= o provide
> >> > such dynamic
> >> information.<= br>> >>
> >> Right, that's most of what I was tryi= ng to say. =A0I do have a concern
> >> that collecting a bunch of different information about a give= n person
> >> and linking it together in a single, easy to acce= ss repository has
> >> some potential security side effects (no= t just privacy ones, but
> >> those too, of
> >> course) that are not clearly h= ighlighted in the security
> considerations.
> >> I suppo= se one could argue that facebook's (or pick your poison) user
> &= gt;> population shows nobody cares about that, but I think it would stil= l
> >> be good to have some observations about those effects.
>= ; >>
> >> Best,
> >>
> >> A
&g= t; >>
> >> --
> >> Andrew Sullivan
> &g= t;> ajs@anvi= lwalrusden.com
> >> _______________________________________________
> >&= gt; apps-discuss mailing list
> >> apps-discuss@ietf.org
> >> <= a href=3D"https://www.ietf.org/mailman/listinfo/apps-discuss" target=3D"_bl= ank">https://www.ietf.org/mailman/listinfo/apps-discuss
> >
> > _______________________________________________
&= gt; > apps-discuss mailing list
> > apps-discuss@ietf.org
> > https://www.ietf.org/mailman/listinfo/apps-discuss

_______________________________________________
apps-discuss mailing= list
apps-di= scuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-disc= uss

=A0

<= /div>

--20cf3074b5a29e461704bc3d712a-- From jasnell@gmail.com Tue Mar 27 11:19:42 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A028021E80B3 for ; Tue, 27 Mar 2012 11:19:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.099 X-Spam-Level: X-Spam-Status: No, score=-7.099 tagged_above=-999 required=5 tests=[AWL=-3.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kzU4FrI1vHFB for ; Tue, 27 Mar 2012 11:19:41 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id D30D921E808D for ; Tue, 27 Mar 2012 11:19:39 -0700 (PDT) Received: by werb10 with SMTP id b10so144411wer.31 for ; Tue, 27 Mar 2012 11:19:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=8zqo8tDuzir5hBY19Q7Bg8NjcfTShFaOJNZugL9E0J4=; b=kpaBvl/wsSgfRJV1oKMrkqYHBHPE41b76pQHdLH0gfqCI+lONMiyD84ctPT0FVYBC0 beBDMrx4P6VfeLF4rSaqustZMtCvSRq6LIkDdbIyaKcWpTcFS30nGjLxzTDWHOXn2msq Eq4G/SQNAhaan5Bm4Q4AE5eaN4CN55BESW0QNhpEjFRSUqeXS4Vz9uRARuabeXVeRtZi AmvTBYQS9YrrRnpiF9Crx411wZGX6DNtRh3EZiOlJiS3YMdnVqp4Dc0p+wsBw3R0mdmJ rO9eXWPx4vZtp8f+MNOK5fcD3rB3wfzbN/gQ2xqoD1PGiPuFoK3ugijk1H5NtoT2YPfJ Cxlg== Received: by 10.216.132.151 with SMTP id o23mr15022940wei.120.1332872343688; Tue, 27 Mar 2012 11:19:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.89.138 with HTTP; Tue, 27 Mar 2012 11:18:43 -0700 (PDT) In-Reply-To: <00d201cd0c3a$b3672410$1a356c30$@packetizer.com> References: <053201cd0b5d$c08c80f0$41a582d0$@packetizer.com> <20120326150556.GC3557@mail.yitter.info> <20120327084709.GB11491@mail.yitter.info> <00ac01cd0c34$cfc96f10$6f5c4d30$@packetizer.com> <00d201cd0c3a$b3672410$1a356c30$@packetizer.com> From: James M Snell Date: Tue, 27 Mar 2012 11:18:43 -0700 Message-ID: To: "Paul E. Jones" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Webfinger discussion X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 27 Mar 2012 18:19:42 -0000 They are rather technical in nature and speak to the overall operation of the protocol. I've written up a detailed version of my feedback here [1] [1] http://chmod777self.blogspot.com/2012/03/thoughts-on-webfinger.html The summary version is this: I believe we can make this even simpler without sacrificing basic operation by saying simply: If I want to know about user "bob@example.org", send a GET request to: http://example.org/.well-known/finger/{md5(acct:bob@example.org)} and see what I get back. The requirement to use XRD/JRD and first look up information about the LRDD service in host-meta is quite unnecessary. Also note that the ID is hashed in the request URI for privacy/security purposes... We can expand on that basic idea further to say: If I want to know if "bob@example.org" has a "blog" and where it is locat= ed, I could simply send a request to: http://example.org/.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/bl= og and the server can respond with a redirect to the proper location: HTTP/1.1 302 Found Location: http://blogs.example.org/bob The "/blog" portion of the request URI specifies a Link rel... if I want to discover some other type of service... say, the users profile or avatar, I simply link the different rel attribute value there.. e.g. http://example.org/.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/av= atar http://example.org/.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/pr= ofile If there are multiple links for a particular rel, the server can respond with a 300 Multiple Options response. The point is that requiring XRD/JRD isn't actually necessary, and requiring the initial host metadata step isn't required also. Requiring CORS is also isn't necessary. Anyway, that's the basic rundown. - James On Tue, Mar 27, 2012 at 9:57 AM, Paul E. Jones wrot= e: > James, > > If the other items are editorial, perhaps just direct them to me. =C2=A0I= f they are items that others might want to weigh in on, then this list is t= he appropriate venue. > > Paul > >> -----Original Message----- >> From: James M Snell [mailto:jasnell@gmail.com] >> Sent: Tuesday, March 27, 2012 12:39 PM >> To: Paul E. Jones >> Cc: Andrew Sullivan; apps-discuss@ietf.org >> Subject: Re: [apps-discuss] Webfinger discussion >> >> To be fair, there are ways of dealing with the potential for security >> leaks of this nature with WebFinger that did not really exist with the >> original Finger protocol. OAuth 2, for instance. A WebFinger endpoint >> could choose to serve up only the most basic static information to >> unauthenticated requesters, but then provide a means for a requester to >> authenticate and request permission from the target user or provider to >> acquire additional information as part of the response. >> >> On a side note to Paul: I did have some additional general comments on t= he >> WebFinger spec itself, I wanted to ask where such comments would be best >> directed for discussion. >> >> - James >> >> On Tue, Mar 27, 2012 at 9:15 AM, Paul E. Jones >> wrote: >> > I agree it would be useful to add text about sharing information that >> > might be dynamic in nature (e.g., current user location). >> > >> > We'll add text along those lines to the next draft. =C2=A0Any other >> > security considerations we should note? >> > >> > Paul >> > >> >> -----Original Message----- >> >> From: apps-discuss-bounces@ietf.org >> >> [mailto:apps-discuss-bounces@ietf.org] >> >> On Behalf Of Andrew Sullivan >> >> Sent: Tuesday, March 27, 2012 4:47 AM >> >> To: apps-discuss@ietf.org >> >> Subject: Re: [apps-discuss] Webfinger discussion >> >> >> >> On Mon, Mar 26, 2012 at 02:31:30PM -0400, Bob Wyman wrote: >> >> >> >> > un-recommended!). If people did, in fact, use WebFinger to record >> >> > such stuff, the concerns you mentioned would be relevant. Thus, it >> >> > might make sense for the Security Considerations section to suggest >> >> > that one should think carefully before using WebFinger to provide >> >> > such dynamic >> >> information. >> >> >> >> Right, that's most of what I was trying to say. =C2=A0I do have a con= cern >> >> that collecting a bunch of different information about a given person >> >> and linking it together in a single, easy to access repository has >> >> some potential security side effects (not just privacy ones, but >> >> those too, of >> >> course) that are not clearly highlighted in the security >> considerations. >> >> I suppose one could argue that facebook's (or pick your poison) user >> >> population shows nobody cares about that, but I think it would still >> >> be good to have some observations about those effects. >> >> >> >> Best, >> >> >> >> A >> >> >> >> -- >> >> Andrew Sullivan >> >> ajs@anvilwalrusden.com >> >> _______________________________________________ >> >> apps-discuss mailing list >> >> apps-discuss@ietf.org >> >> https://www.ietf.org/mailman/listinfo/apps-discuss >> > >> > _______________________________________________ >> > apps-discuss mailing list >> > apps-discuss@ietf.org >> > https://www.ietf.org/mailman/listinfo/apps-discuss > From ajs@anvilwalrusden.com Tue Mar 27 12:33:06 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85D4321E80EB for ; Tue, 27 Mar 2012 12:33:06 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AYqRWSdQHtol for ; Tue, 27 Mar 2012 12:33:05 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 95A2C21E80EC for ; Tue, 27 Mar 2012 12:33:05 -0700 (PDT) Received: from mail.yitter.info (unknown [83.145.64.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id B587F1ECB420 for ; Tue, 27 Mar 2012 19:33:04 +0000 (UTC) Date: Tue, 27 Mar 2012 15:32:54 -0400 From: 'Andrew Sullivan' To: apps-discuss@ietf.org Message-ID: <20120327193247.GA12201@mail.yitter.info> References: <053201cd0b5d$c08c80f0$41a582d0$@packetizer.com> <20120326150556.GC3557@mail.yitter.info> <20120327084709.GB11491@mail.yitter.info> <00ac01cd0c34$cfc96f10$6f5c4d30$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00ac01cd0c34$cfc96f10$6f5c4d30$@packetizer.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [apps-discuss] Webfinger discussion X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 27 Mar 2012 19:33:06 -0000 On Tue, Mar 27, 2012 at 12:15:21PM -0400, Paul E. Jones wrote: > We'll add text along those lines to the next draft. Any other security > considerations we should note? I wish I had something more intelligent to say than, "Is anyone [else] worried about the aggregation of this information amd what it does to the security profile of the aggregated things?" Note this isn't exactly the privacy issue, though there's that. As nearly as I can tell, one natural use case (or anyway, something people said) was that you can aggregate information across services so that, for instance, it would be easy to tell about the relationships among me@service1, me@service2, and me@service3. If I'm misunderstanding (this happens a lot, note, so don't be afraid to point and laugh), please correct me. If I understood correctly, it seems to me that disclosing something about the relationship of these three accounts is in effect a new disclosure, and that it offers potential for analysis (and therefore attacks) that might not have been available given the individual accounts alone. But beyond that hand-wavy unease, I haven't the tools to say anything really sensible. Maybe there's some sort of secdir guidance for this sort of thing? (Note that I'm not a security guy, and I don't play one on TV either. This is just the sort of thing they warned me about when I was a kid, and I think that's why I have the heebie-jeebies about this. Maybe I'm just superstitious.) Thanks for putting up with the hand-waving (which will stop now), A -- Andrew Sullivan ajs@anvilwalrusden.com From bobwyman@gmail.com Tue Mar 27 13:16:48 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3C2121F8688 for ; Tue, 27 Mar 2012 13:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.613 X-Spam-Level: X-Spam-Status: No, score=-2.613 tagged_above=-999 required=5 tests=[AWL=0.363, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t5yWAzXz6FPs for ; Tue, 27 Mar 2012 13:16:47 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 6AE3B21F8686 for ; Tue, 27 Mar 2012 13:16:46 -0700 (PDT) Received: by qaea16 with SMTP id a16so395642qae.10 for ; Tue, 27 Mar 2012 13:16:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=rPnTTXaI9YFlTcUqURNVROj0mMWbb09WSY2Xxf/Fe78=; b=PTLEQ05VEPflnlcnL/OQ1C9D2JyfpOUnDduVKZ+XzRqzSkMKWQnxcaxH65nmzYTqxt YjUGiVziNo1z9K4p4SAZXv1vYTJ7PqvKy7333btie4Q8oSv9mhWq0KAbC6SDKqcUriOE H65EeNZwUHB4YRiaLMkpXAiTOY4KC+9SXj5ZbKZb6mATCO9u3ZAQVyrgDVHcfZaWW9yz vHq+Al7Nm9XIYQ67Tast67ePCiCYikTP8IMKZ/8IfnbFb5CnbIVnEGH/Dcb6hdsFYUxi j3P1m0x7cU/fzFxgewRUhg57j7W5Zs1d4A367B+e7UH+UXCky14D07R36lN2O70YAOvk 6BEw== MIME-Version: 1.0 Received: by 10.224.116.19 with SMTP id k19mr34723941qaq.59.1332879405895; Tue, 27 Mar 2012 13:16:45 -0700 (PDT) Sender: bobwyman@gmail.com Received: by 10.229.157.16 with HTTP; Tue, 27 Mar 2012 13:16:45 -0700 (PDT) In-Reply-To: References: <053201cd0b5d$c08c80f0$41a582d0$@packetizer.com> <20120326150556.GC3557@mail.yitter.info> <20120327084709.GB11491@mail.yitter.info> <00ac01cd0c34$cfc96f10$6f5c4d30$@packetizer.com> <00d201cd0c3a$b3672410$1a356c30$@packetizer.com> Date: Tue, 27 Mar 2012 16:16:45 -0400 X-Google-Sender-Auth: DwXV0vDofeBnyBtr1SGLv1Xkocs Message-ID: From: Bob Wyman To: James M Snell Content-Type: multipart/alternative; boundary=20cf3074d934844e8e04bc3f2bb1 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Webfinger discussion X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 27 Mar 2012 20:16:49 -0000 --20cf3074d934844e8e04bc3f2bb1 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Mar 27, 2012 at 2:18 PM, James M Snell wrote: > They are rather technical in nature and speak to the overall operation > of the protocol. I've written up a detailed version of my feedback > here [1] > > [1] http://chmod777self.blogspot.com/2012/03/thoughts-on-webfinger.html > > The summary version is this: I believe we can make this even simpler > without sacrificing basic operation by saying simply: > > If I want to know about user "bob@example.org", send a GET request to: > http://example.org/.well-known/finger/{md5(acct:bob@example.org)} and > see what I get back. > > The requirement to use XRD/JRD and first look up information about the > LRDD service in host-meta is quite unnecessary. Also note that the ID > is hashed in the request URI for privacy/security purposes... > Given WebFinger as currently defined, you are probably correct in saying that the LRDD lookup is unnecessary. The reason for this is WebFinger only defines a single variable for use in Templates. Thus, the easiest thing to do is to simply define a standard URI for doing WebFinger lookups. The Template mechanism provides more generality than is useful for WebFinger as defined. Things could have been different -- and I think that was part of folk's original thinking here. For instance, WebFinger might have defined a few more Template variables or provided for a registry of template variables. In that case, we might have seen: "Full_Name", "telephone number," "Student_ID_Number" and many other variables Then, there would have been a question as to how to construct the WebFinger query URI -- (Which variables are supported by the current server? How should the URI be composed?). It would, I think, simplify matters if, as you suggest, we define a fixed URI for WebFinger. If anyone really wants a service that can be used to map from attributes to WebFinger acct: URIs, then they can do so in a different specification. (i.e. This new "WebFinger Acct Lookup Service" would do lookups from stuff like "full_name"="bob wyman" to acct:bob@example.com) One other advantage that comes from using the two-step, template-driven approach is that it is easier to handle re-directions in some environments. Given the current spec, I can ask example.com/... for an LRDD that might tell me that I really should be asking webfinger.example.com for WebFinger information instead. Certainly, the same can be handled using HTTP redirects, however, HTTP redirects may be managed by someone other than the person who manages the LRDDs. (i.e. Given the way host-meta works, even if I'm running a web site on a fairly strictly controlled shared service, I can accomplish much by simply putting a file named ".well-known/host-meta" on my site. But, it might be much harder for me to get those who run the shared service to define a redirect for me.) I like the idea of passing acct: URIs as hash values. Clearly, such simple obfuscation is relatively transparent (subject to dictionary attack), nonetheless, it would raise the cost of interception by a reasonably useful amount. Nonetheless, I suspect that this is the sort of thing that might best be a SHOULD for clients while a MUST for servers. bob wyman > > We can expand on that basic idea further to say: > > If I want to know if "bob@example.org" has a "blog" and where it is > located, > I could simply send a request to: > > http://example.org/.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/blog > > and the server can respond with a redirect to the proper location: > > HTTP/1.1 302 Found > Location: http://blogs.example.org/bob > > The "/blog" portion of the request URI specifies a Link rel... if I > want to discover some other type of service... say, the users profile > or avatar, I simply link the different rel attribute value there.. > e.g. > > > http://example.org/.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/avatar > > http://example.org/.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/profile > > If there are multiple links for a particular rel, the server can > respond with a 300 Multiple Options response. > > The point is that requiring XRD/JRD isn't actually necessary, and > requiring the initial host metadata step isn't required also. > > Requiring CORS is also isn't necessary. > > Anyway, that's the basic rundown. > > - James > > On Tue, Mar 27, 2012 at 9:57 AM, Paul E. Jones > wrote: > > James, > > > > If the other items are editorial, perhaps just direct them to me. If > they are items that others might want to weigh in on, then this list is the > appropriate venue. > > > > Paul > > > >> -----Original Message----- > >> From: James M Snell [mailto:jasnell@gmail.com] > >> Sent: Tuesday, March 27, 2012 12:39 PM > >> To: Paul E. Jones > >> Cc: Andrew Sullivan; apps-discuss@ietf.org > >> Subject: Re: [apps-discuss] Webfinger discussion > >> > >> To be fair, there are ways of dealing with the potential for security > >> leaks of this nature with WebFinger that did not really exist with the > >> original Finger protocol. OAuth 2, for instance. A WebFinger endpoint > >> could choose to serve up only the most basic static information to > >> unauthenticated requesters, but then provide a means for a requester to > >> authenticate and request permission from the target user or provider to > >> acquire additional information as part of the response. > >> > >> On a side note to Paul: I did have some additional general comments on > the > >> WebFinger spec itself, I wanted to ask where such comments would be best > >> directed for discussion. > >> > >> - James > >> > >> On Tue, Mar 27, 2012 at 9:15 AM, Paul E. Jones > >> wrote: > >> > I agree it would be useful to add text about sharing information that > >> > might be dynamic in nature (e.g., current user location). > >> > > >> > We'll add text along those lines to the next draft. Any other > >> > security considerations we should note? > >> > > >> > Paul > >> > > >> >> -----Original Message----- > >> >> From: apps-discuss-bounces@ietf.org > >> >> [mailto:apps-discuss-bounces@ietf.org] > >> >> On Behalf Of Andrew Sullivan > >> >> Sent: Tuesday, March 27, 2012 4:47 AM > >> >> To: apps-discuss@ietf.org > >> >> Subject: Re: [apps-discuss] Webfinger discussion > >> >> > >> >> On Mon, Mar 26, 2012 at 02:31:30PM -0400, Bob Wyman wrote: > >> >> > >> >> > un-recommended!). If people did, in fact, use WebFinger to record > >> >> > such stuff, the concerns you mentioned would be relevant. Thus, it > >> >> > might make sense for the Security Considerations section to suggest > >> >> > that one should think carefully before using WebFinger to provide > >> >> > such dynamic > >> >> information. > >> >> > >> >> Right, that's most of what I was trying to say. I do have a concern > >> >> that collecting a bunch of different information about a given person > >> >> and linking it together in a single, easy to access repository has > >> >> some potential security side effects (not just privacy ones, but > >> >> those too, of > >> >> course) that are not clearly highlighted in the security > >> considerations. > >> >> I suppose one could argue that facebook's (or pick your poison) user > >> >> population shows nobody cares about that, but I think it would still > >> >> be good to have some observations about those effects. > >> >> > >> >> Best, > >> >> > >> >> A > >> >> > >> >> -- > >> >> Andrew Sullivan > >> >> ajs@anvilwalrusden.com > >> >> _______________________________________________ > >> >> apps-discuss mailing list > >> >> apps-discuss@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/apps-discuss > >> > > >> > _______________________________________________ > >> > apps-discuss mailing list > >> > apps-discuss@ietf.org > >> > https://www.ietf.org/mailman/listinfo/apps-discuss > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --20cf3074d934844e8e04bc3f2bb1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Mar 27, 2012 at 2:18 PM, James M= Snell <jasnell@g= mail.com> wrote:
They are rather technical in nature and speak to the overall operation
of the protocol. I've written up a detailed version of my feedback
here [1]

[1] http://chmod777self.blogspot.com/2012/03/thought= s-on-webfinger.html

The summary version is this: I believe we can make this even simpler
without sacrificing basic operation by saying simply:

=A0If I want to know about user "b= ob@example.org", send a GET request to:
=A0http://example.org/.well-known/finger/{md5(acct:bo= b@example.org)} and
=A0see what I get back.

The requirement to use XRD/JRD and first look up information about the
LRDD service in host-meta is quite unnecessary. Also note that the ID
is hashed in the request URI for privacy/security purposes...
Given WebFinger as currently defined, you are probably correct in s= aying that the LRDD lookup is unnecessary. The reason for this is WebFinger= only defines a single variable for use in Templates. Thus, the easiest thi= ng to do is to simply define a standard URI for doing WebFinger lookups. Th= e Template mechanism provides more generality than is useful for WebFinger = as defined.=A0

Things could have been different -- and I think that wa= s part of folk's original thinking here. For instance, WebFinger might = have defined a few more Template variables or provided for a registry of te= mplate variables. In that case, we might have seen: "Full_Name", = "telephone number," "Student_ID_Number" and many other = variables Then, there would have been a question as to how to construct the= WebFinger query URI -- =A0(Which variables are supported by the current se= rver? =A0How should the URI be composed?).

It would, I think, simplify matters if, as you suggest,= we define a fixed URI for WebFinger. If anyone really wants a service that= can be used to map from attributes to WebFinger acct: URIs, then they can = do so in a different specification. (i.e. This new "WebFinger Acct Loo= kup Service" would do lookups from stuff like "full_name"=3D= "bob wyman" to acct:bob= @example.com)

One other advantage that comes from using the two-step,= template-driven approach is that it is easier to handle re-directions in s= ome environments. Given the current spec, I can ask example.com/... for an LRDD that might tell me that I really = should be asking webfinger.example= .com for WebFinger information instead. Certainly, the same can be hand= led using HTTP redirects, however, HTTP redirects may be managed by someone= other than the person who manages the LRDDs. (i.e. Given the way host-meta= works, even if I'm running a web site on a fairly strictly controlled = shared service, I can accomplish much by simply putting=A0a file named ".well-known/host-meta&q= uot; on my site. But, it might be much harder for me to get those who run t= he shared service to define a redirect for me.)

I like the idea of passing acct: URIs as hash values. C= learly, such simple obfuscation is relatively transparent (subject to dicti= onary attack), nonetheless, it would raise the cost of interception by a re= asonably useful amount. Nonetheless, I suspect that this is the sort of thi= ng that might best be a SHOULD for clients while a MUST for servers.

bob wyman
=A0

We can expand on that basic idea further to say:

=A0If I want to know if "bob@examp= le.org" has a "blog" and where it is located,
=A0I could simply send a request to:
=A0http://example.org/.well-known/finger/f4= 9c533fa0f0bc7ee9cc8c88902302ba/blog

=A0and the server can respond with a redirect to the proper location:

=A0HTTP/1.1 302 Found
=A0Location: ht= tp://blogs.example.org/bob

The "/blog" portion of the request URI specifies a Link rel... if= I
want to discover some other type of service... say, the users profile
or avatar, I simply link the different rel attribute value there..
e.g.

=A0http://example.org/.well-known/finger/= f49c533fa0f0bc7ee9cc8c88902302ba/avatar
=A0http://example.org/.well-known/finger= /f49c533fa0f0bc7ee9cc8c88902302ba/profile

If there are multiple links for a particular rel, the server can
respond with a 300 Multiple Options response.

The point is that requiring XRD/JRD isn't actually necessary, and
requiring the initial host metadata step isn't required also.

Requiring CORS is also isn't necessary.

Anyway, that's the basic rundown.

- James

On Tue, Mar 27, 2012 at 9:57 AM, Paul E. Jones <paulej@packetizer.com> wrote:
> James,
>
> If the other items are editorial, perhaps just direct them to me. =A0I= f they are items that others might want to weigh in on, then this list is t= he appropriate venue.
>
> Paul
>
>> -----Original Message-----
>> From: James M Snell [mailto:j= asnell@gmail.com]
>> Sent: Tuesday, March 27, 2012 12:39 PM
>> To: Paul E. Jones
>> Cc: Andrew Sullivan; apps= -discuss@ietf.org
>> Subject: Re: [apps-discuss] Webfinger discussion
>>
>> To be fair, there are ways of dealing with the potential for secur= ity
>> leaks of this nature with WebFinger that did not really exist with= the
>> original Finger protocol. OAuth 2, for instance. A WebFinger endpo= int
>> could choose to serve up only the most basic static information to=
>> unauthenticated requesters, but then provide a means for a request= er to
>> authenticate and request permission from the target user or provid= er to
>> acquire additional information as part of the response.
>>
>> On a side note to Paul: I did have some additional general comment= s on the
>> WebFinger spec itself, I wanted to ask where such comments would b= e best
>> directed for discussion.
>>
>> - James
>>
>> On Tue, Mar 27, 2012 at 9:15 AM, Paul E. Jones <paulej@packetizer.com>
>> wrote:
>> > I agree it would be useful to add text about sharing informat= ion that
>> > might be dynamic in nature (e.g., current user location).
>> >
>> > We'll add text along those lines to the next draft. =A0An= y other
>> > security considerations we should note?
>> >
>> > Paul
>> >
>> >> -----Original Message-----
>> >> From: ap= ps-discuss-bounces@ietf.org
>> >> [mailto:= apps-discuss-bounces@ietf.org]
>> >> On Behalf Of Andrew Sullivan
>> >> Sent: Tuesday, March 27, 2012 4:47 AM
>> >> To: apps-discuss= @ietf.org
>> >> Subject: Re: [apps-discuss] Webfinger discussion
>> >>
>> >> On Mon, Mar 26, 2012 at 02:31:30PM -0400, Bob Wyman wrote= :
>> >>
>> >> > un-recommended!). If people did, in fact, use WebFin= ger to record
>> >> > such stuff, the concerns you mentioned would be rele= vant. Thus, it
>> >> > might make sense for the Security Considerations sec= tion to suggest
>> >> > that one should think carefully before using WebFing= er to provide
>> >> > such dynamic
>> >> information.
>> >>
>> >> Right, that's most of what I was trying to say. =A0I = do have a concern
>> >> that collecting a bunch of different information about a = given person
>> >> and linking it together in a single, easy to access repos= itory has
>> >> some potential security side effects (not just privacy on= es, but
>> >> those too, of
>> >> course) that are not clearly highlighted in the security<= br> >> considerations.
>> >> I suppose one could argue that facebook's (or pick yo= ur poison) user
>> >> population shows nobody cares about that, but I think it = would still
>> >> be good to have some observations about those effects. >> >>
>> >> Best,
>> >>
>> >> A
>> >>
>> >> --
>> >> Andrew Sullivan
>> >> ajs@anvilwalrus= den.com
>> >> _______________________________________________
>> >> apps-discuss mailing list
>> >> apps-discuss@iet= f.org
>> >> https://www.ietf.org/mailman/listinfo/apps-discuss<= /a>
>> >
>> > _______________________________________________
>> > apps-discuss mailing list
>> > apps-discuss@ietf.or= g
>> > https://www.ietf.org/mailman/listinfo/apps-discuss<= br> >
_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--20cf3074d934844e8e04bc3f2bb1-- From sm@resistor.net Tue Mar 27 15:22:04 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF7AA21E80D3 for ; Tue, 27 Mar 2012 15:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.624 X-Spam-Level: X-Spam-Status: No, score=-102.624 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GA3DeqqbN-6s for ; Tue, 27 Mar 2012 15:22:02 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C0DC21E8011 for ; Tue, 27 Mar 2012 15:22:02 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q2RMLpDd013000; Tue, 27 Mar 2012 15:21:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1332886916; i=@resistor.net; bh=0ISVKaMbM/7AEMwIEoav7Wltv6RTyVGD1zjfiLKuCj0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=BkBqs62MYZ0c3C0e8ARbC+F5LTKuK7B1r276mTaTuw5ctJlzv0xFtYmuhJP/Xq2kY TNvLTmxXqpwWM7ZZH0w18sY8WH08rL5rKmjWLLGiPJ9+4l4+dSvieBZRtnTmKbq9AM HF7xGcrezsg0+086yPzJF6njmcg//m2q6OZ7JmmY= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1332886916; i=@resistor.net; bh=0ISVKaMbM/7AEMwIEoav7Wltv6RTyVGD1zjfiLKuCj0=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=tPiI/DMrEvZRAVHxvWG+aK2QO1iKRHDRo7FJIr1XTEAiJb7bhsU+uS/53RadpxWI+ zmLNZhMZ8wWlcXiBcXiB3WMf6gUeGIGhHzSSgnF365GygHzyEIW2MYAHjbXfHeCVGT SRAQuOyDIKq9kbHiGso1YZpnPdEngrVzAsBhcsh8= Message-Id: <6.2.5.6.2.20120327150610.0c73eec8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 27 Mar 2012 15:13:52 -0700 To: apps-discuss@ietf.org From: SM In-Reply-To: <20120327193247.GA12201@mail.yitter.info> References: <053201cd0b5d$c08c80f0$41a582d0$@packetizer.com> <20120326150556.GC3557@mail.yitter.info> <20120327084709.GB11491@mail.yitter.info> <00ac01cd0c34$cfc96f10$6f5c4d30$@packetizer.com> <20120327193247.GA12201@mail.yitter.info> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [apps-discuss] Webfinger discussion X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 27 Mar 2012 22:22:04 -0000 At 12:32 27-03-2012, 'Andrew Sullivan' wrote: >I wish I had something more intelligent to say than, "Is anyone [else] >worried about the aggregation of this information amd what it does to >the security profile of the aggregated things?" Note this isn't I'll label it as a concern. >If I understood correctly, it seems to me that disclosing something >about the relationship of these three accounts is in effect a new >disclosure, and that it offers potential for analysis (and therefore >attacks) that might not have been available given the individual >accounts alone. But beyond that hand-wavy unease, I haven't the tools Yes. >to say anything really sensible. Maybe there's some sort of secdir >guidance for this sort of thing? (Note that I'm not a security guy, That might be summed up as: "If one does not wish to share certain information with the world, do not allow that information to be accessible through Webfinger." I suggest that the authors take a look at draft-iab-privacy-considerations-02. Regards, -sm From chi880466@gmail.com Tue Mar 27 16:47:43 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4644C21F8763 for ; Tue, 27 Mar 2012 16:47:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.593 X-Spam-Level: * X-Spam-Status: No, score=1.593 tagged_above=-999 required=5 tests=[AWL=-0.758, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mR0ip4blopuk for ; Tue, 27 Mar 2012 16:47:42 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8A10D21F8762 for ; Tue, 27 Mar 2012 16:47:42 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so365439vbb.31 for ; Tue, 27 Mar 2012 16:47:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=+Ekm1CoWR6KI5obmHfXHDvmEXQjS/+KMWY/rkirEwM8=; b=yk6n0zQaeB6itx4gqo2BWHjggHviR8bBvMehYEdy0zeyluwHw7y8jSFP918YRzDknm iISBgfpLiQhRh0Niqdk/+usyZJxBWrCQHu4g07fAogBkSpVRMvRcZ9RQRI8sw8lL27S2 pIjMatbGuhlk4NkWaKw2+VddV06Glv3rUYD2EELJ7MQl5CR4pkQRCxnF0H0g6iHLSaUR rKPRtSJ+gGo36vCU2W9Cdlr6qP0f5DWH9mvMSBNP+OtIjuDRwXJJxCacyF+0VvKgWJSK 8WC5oC2Cb88ZE/WFGMdUaeu8Ck/DUtXwAb9swseDwBNyM80ZM/ZIARwcUgm1Fw1CYRie RsjA== MIME-Version: 1.0 Received: by 10.52.19.196 with SMTP id h4mr10773238vde.91.1332892061906; Tue, 27 Mar 2012 16:47:41 -0700 (PDT) Received: by 10.220.1.4 with HTTP; Tue, 27 Mar 2012 16:47:41 -0700 (PDT) In-Reply-To: <4F71CD46.5070603@gmx.de> References: <4F7172FE.6060207@gmx.de> <4F71CD46.5070603@gmx.de> Date: Wed, 28 Mar 2012 08:47:41 +0900 Message-ID: From: =?EUC-KR?B?wfa827/4IEphbWVzIFNvbmd3b24gQ2hp?= To: Julian Reschke Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Confusing JSON Pointer X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 27 Mar 2012 23:47:43 -0000 2012=B3=E2 3=BF=F9 27=C0=CF =BF=C0=C8=C4 11:23, Julian Reschke =B4=D4=C0=C7 =B8=BB: > On 2012-03-27 15:49, =C1=F6=BC=DB=BF=F8 James Songwon Chi wrote: >> 2012=B3=E2 3=BF=F9 27=C0=CF =BF=C0=C8=C4 4:57, Julian Reschke=B4=D4=C0=C7 =B8=BB: >>> On 2012-03-27 07:22, =C1=F6=BC=DB=BF=F8 James Songwon Chi wrote: >>>> >>>> After reading JSON Pointer (draft-ietf-appsawg-json-pointer-01), I am >>>> confused with encoding or escape scheme. >>>> For me, it is an ambiguous scheme. For example, a reference token >>>> "ref/1" can be expressed following ways: >>>> >>>> 1) If it is a URI fragment identifier and a JSON Pointer >>>> Step 1. apply URI encoding: ref%5C1 >>>> Step 2. apply JSON Pointer encoding: ref%5C1 >>>> Final result: ref%5C1 >>>> >>>> 2) If it is a JSON Pointer and a URI fragment identifier >>>> Step 1. apply JSON Pointer encoding: ref^/1 >>>> Step 2. apply URI encoding: ref^%5C1 >>>> Final result: ref^%5C1 >>>> >>>> I expected the same results. >>>> >>>> And if my interpretation is wrong, to prevent the similar question, >>>> there should be some examples for this kind. >>>> ... >>> >>> >>> I don't understand the question. >>> >>> The spec states how to put JSON Pointers (^-escaping) into fragment >>> identifiers (%-escaping). >>> >>> As far as I can tell the outcome then is what you have under 2), no? >>> >>> Best regards, Julian >> >> Thank you Julian for the reply. >> Yes. Answer is 2) for above question. Well, but I gave a wrong >> question and a wrong example (And solidus is 0x2F, not 0x5C.) >> >> This is corrected one: >> >> If I want a JSON Pointer to be represented as both a JSON String and a >> URI fragment identifier, I should apply three encoding scheme. >> There are two sequences with example: >> ... > > You convert *either* to a string *or* to a URI fragment. Never both. I don't agree with you. First, there is no such words. Second, if it is used in a JSON Schema as a "$ref" value, it should be both JSON String and URI. By the way, do we really *need another escape* even there are two encodings already? > >> ... > > Best regards, Julian From pbryan@anode.ca Tue Mar 27 18:36:31 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 269D321F8600 for ; Tue, 27 Mar 2012 18:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H+GVdEieWbvw for ; Tue, 27 Mar 2012 18:36:29 -0700 (PDT) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id 1632221F8602 for ; Tue, 27 Mar 2012 18:36:29 -0700 (PDT) Received: from [10.0.49.41] (unknown [204.14.239.221]) by maple.anode.ca (Postfix) with ESMTPSA id 7D06B6483 for ; Wed, 28 Mar 2012 01:36:28 +0000 (UTC) Message-ID: <1332898587.10875.5.camel@neutron> From: "Paul C. Bryan" To: apps-discuss@ietf.org Date: Tue, 27 Mar 2012 18:36:27 -0700 In-Reply-To: References: <4F7172FE.6060207@gmx.de> <4F71CD46.5070603@gmx.de> Content-Type: multipart/alternative; boundary="=-NFRj3PzDHMV+6G+6XajQ" X-Mailer: Evolution 3.2.2-1 Mime-Version: 1.0 Subject: Re: [apps-discuss] Confusing JSON Pointer X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 28 Mar 2012 01:36:31 -0000 --=-NFRj3PzDHMV+6G+6XajQ Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit On Wed, 2012-03-28 at 08:47 +0900, ì§€ì†¡ì› James Songwon Chi wrote: > 2012ë…„ 3ì›” 27ì¼ ì˜¤í›„ 11:23, Julian Reschke ë‹˜ì˜ ë§: > > On 2012-03-27 15:49, ì§€ì†¡ì› James Songwon Chi wrote: > >> 2012ë…„ 3ì›” 27ì¼ ì˜¤í›„ 4:57, Julian Reschkeë‹˜ì˜ ë§: > >>> On 2012-03-27 07:22, ì§€ì†¡ì› James Songwon Chi wrote: > >>>> > >>>> After reading JSON Pointer (draft-ietf-appsawg-json-pointer-01), I am > >>>> confused with encoding or escape scheme. > >>>> For me, it is an ambiguous scheme. For example, a reference token > >>>> "ref/1" can be expressed following ways: > >>>> > >>>> 1) If it is a URI fragment identifier and a JSON Pointer > >>>> Step 1. apply URI encoding: ref%5C1 > >>>> Step 2. apply JSON Pointer encoding: ref%5C1 > >>>> Final result: ref%5C1 > >>>> > >>>> 2) If it is a JSON Pointer and a URI fragment identifier > >>>> Step 1. apply JSON Pointer encoding: ref^/1 > >>>> Step 2. apply URI encoding: ref^%5C1 > >>>> Final result: ref^%5C1 > >>>> > >>>> I expected the same results. > >>>> > >>>> And if my interpretation is wrong, to prevent the similar question, > >>>> there should be some examples for this kind. > >>>> ... > >>> > >>> > >>> I don't understand the question. > >>> > >>> The spec states how to put JSON Pointers (^-escaping) into fragment > >>> identifiers (%-escaping). > >>> > >>> As far as I can tell the outcome then is what you have under 2), no? > >>> > >>> Best regards, Julian > >> > >> Thank you Julian for the reply. > >> Yes. Answer is 2) for above question. Well, but I gave a wrong > >> question and a wrong example (And solidus is 0x2F, not 0x5C.) > >> > >> This is corrected one: > >> > >> If I want a JSON Pointer to be represented as both a JSON String and a > >> URI fragment identifier, I should apply three encoding scheme. > >> There are two sequences with example: > >> ... > > > > You convert *either* to a string *or* to a URI fragment. Never both. > I don't agree with you. First, there is no such words. > Second, if it is used in a JSON Schema as a "$ref" value, it should be > both JSON String and URI. The intent of the draft is to establish rules for encoding in a JSON string or in a URI. Of course, I agree that a URI can in turn be expressed in a JSON string, but in this case, URI encoding applies; you do not mix-and-match encodings. > By the way, do we really *need another escape* even there are two > encodings already? I'm not sure what you mean here. If you encode as URI, presumably all valid URI characters are representable without any further escaping in a JSON string. Paul --=-NFRj3PzDHMV+6G+6XajQ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit On Wed, 2012-03-28 at 08:47 +0900, 지송원 James Songwon Chi wrote: 
2012년 3월 27일 오후 11:23, Julian Reschke <julian.reschke@gmx.de>님의 말:
> On 2012-03-27 15:49, 지송원 James Songwon Chi wrote:
>> 2012년 3월 27일 오후 4:57, Julian Reschke<julian.reschke@gmx.de>님의 말:
>>> On 2012-03-27 07:22, 지송원 James Songwon Chi wrote:
>>>>
>>>> After reading JSON Pointer (draft-ietf-appsawg-json-pointer-01), I am
>>>> confused with encoding or escape scheme.
>>>> For me, it is an ambiguous scheme. For example, a reference token
>>>> "ref/1" can be expressed following ways:
>>>>
>>>> 1) If it is a URI fragment identifier and a JSON Pointer
>>>>       Step 1. apply URI encoding: ref%5C1
>>>>       Step 2. apply JSON Pointer encoding:  ref%5C1
>>>>       Final result: ref%5C1
>>>>
>>>> 2) If it is a JSON Pointer and a URI fragment identifier
>>>>       Step 1. apply JSON Pointer encoding: ref^/1
>>>>       Step 2. apply URI encoding:  ref^%5C1
>>>>       Final result: ref^%5C1
>>>>
>>>> I expected the same results.
>>>>
>>>> And if my interpretation is wrong, to prevent the similar question,
>>>> there should be some examples for this kind.
>>>> ...
>>>
>>>
>>> I don't understand the question.
>>>
>>> The spec states how to put JSON Pointers (^-escaping) into fragment
>>> identifiers (%-escaping).
>>>
>>> As far as I can tell the outcome then is what you have under 2), no?
>>>
>>> Best regards, Julian
>>
>> Thank you Julian for the reply.
>> Yes. Answer is 2) for above question. Well, but I gave a wrong
>> question and a wrong example (And solidus is 0x2F, not 0x5C.)
>>
>> This is corrected one:
>>
>> If I want a JSON Pointer to be represented as both a JSON String and a
>> URI fragment identifier, I should apply three encoding scheme.
>> There are two sequences with example:
>> ...
>
> You convert *either* to a string *or* to a URI fragment. Never both.
I don't agree with you. First, there is no such words.
Second, if it is used in a JSON Schema as a "$ref" value, it should be
both JSON String and URI.

The intent of the draft is to establish rules for encoding in a JSON string or in a URI. Of course, I agree that a URI can in turn be expressed in a JSON string, but in this case, URI encoding applies; you do not mix-and-match encodings.

By the way, do we really *need another escape* even there are two
encodings already?

I'm not sure what you mean here. If you encode as URI, presumably all valid URI characters are representable without any further escaping in a JSON string.

Paul --=-NFRj3PzDHMV+6G+6XajQ-- From chi880466@gmail.com Tue Mar 27 19:04:55 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B6EC21E8063 for ; Tue, 27 Mar 2012 19:04:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.719 X-Spam-Level: * X-Spam-Status: No, score=1.719 tagged_above=-999 required=5 tests=[AWL=-0.632, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i6LsO78K2Trb for ; Tue, 27 Mar 2012 19:04:54 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 72FEB21E804A for ; Tue, 27 Mar 2012 19:04:54 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so427427vbb.31 for ; Tue, 27 Mar 2012 19:04:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ZurAnRSueIcB51DaUQSQ0r3w3wvFdlu09pbY18lt2dg=; b=H6eltdS2a8OsnijCut+uXZPiqqPl4U3QdgoY4AOs5C+axSueYMCzTsHwY5rz37uYy8 E/+vsOch0tL3mH24UWv6Y/tirBNRSyAFcgJATwWi184+t634JSSoQkF3IbRtIUJwuDhu NBE/YQmwKZyz8w5UndV949cp0kfJ+fcaOsjU3rASqgKshQDXbmqcl8NRQP88I0oq7y1E XwOZPLKd2YRdEyKnHcqCilShe0eqWaQ7H7Vx6Z9Tt0kCoupftEZC/jWqNsK0ccfpdaQx OCCWeatw1krJqe+g0zBMXb49owNTYZRhosFaxaCkLoq8UUnnN3aulJ5MB7BKvECkUgR7 Emig== MIME-Version: 1.0 Received: by 10.52.88.9 with SMTP id bc9mr10908260vdb.74.1332900293600; Tue, 27 Mar 2012 19:04:53 -0700 (PDT) Received: by 10.220.1.4 with HTTP; Tue, 27 Mar 2012 19:04:53 -0700 (PDT) In-Reply-To: <1332898587.10875.5.camel@neutron> References: <4F7172FE.6060207@gmx.de> <4F71CD46.5070603@gmx.de> <1332898587.10875.5.camel@neutron> Date: Wed, 28 Mar 2012 11:04:53 +0900 Message-ID: From: =?EUC-KR?B?wfa827/4IEphbWVzIFNvbmd3b24gQ2hp?= To: "Paul C. Bryan" Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Confusing JSON Pointer X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 28 Mar 2012 02:04:55 -0000 2012=B3=E2 3=BF=F9 28=C0=CF =BF=C0=C0=FC 10:36, Paul C. Bryan =B4=D4=C0=C7 =B8=BB: > On Wed, 2012-03-28 at 08:47 +0900, =C1=F6=BC=DB=BF=F8 James Songwon Chi w= rote: > > 2012=B3=E2 3=BF=F9 27=C0=CF =BF=C0=C8=C4 11:23, Julian Reschke =B4=D4=C0=C7 =B8=BB: >> On 2012-03-27 15:49, =C1=F6=BC=DB=BF=F8 James Songwon Chi wrote: >>> 2012=B3=E2 3=BF=F9 27=C0=CF =BF=C0=C8=C4 4:57, Julian Reschke=B4=D4=C0=C7 =B8=BB: >>>> On 2012-03-27 07:22, =C1=F6=BC=DB=BF=F8 James Songwon Chi wrote: >>>>> >>>>> After reading JSON Pointer (draft-ietf-appsawg-json-pointer-01), I am >>>>> confused with encoding or escape scheme. >>>>> For me, it is an ambiguous scheme. For example, a reference token >>>>> "ref/1" can be expressed following ways: >>>>> >>>>> 1) If it is a URI fragment identifier and a JSON Pointer >>>>> Step 1. apply URI encoding: ref%5C1 >>>>> Step 2. apply JSON Pointer encoding: ref%5C1 >>>>> Final result: ref%5C1 >>>>> >>>>> 2) If it is a JSON Pointer and a URI fragment identifier >>>>> Step 1. apply JSON Pointer encoding: ref^/1 >>>>> Step 2. apply URI encoding: ref^%5C1 >>>>> Final result: ref^%5C1 >>>>> >>>>> I expected the same results. >>>>> >>>>> And if my interpretation is wrong, to prevent the similar question, >>>>> there should be some examples for this kind. >>>>> ... >>>> >>>> >>>> I don't understand the question. >>>> >>>> The spec states how to put JSON Pointers (^-escaping) into fragment >>>> identifiers (%-escaping). >>>> >>>> As far as I can tell the outcome then is what you have under 2), no? >>>> >>>> Best regards, Julian >>> >>> Thank you Julian for the reply. >>> Yes. Answer is 2) for above question. Well, but I gave a wrong >>> question and a wrong example (And solidus is 0x2F, not 0x5C.) >>> >>> This is corrected one: >>> >>> If I want a JSON Pointer to be represented as both a JSON String and a >>> URI fragment identifier, I should apply three encoding scheme. >>> There are two sequences with example: >>> ... >> >> You convert *either* to a string *or* to a URI fragment. Never both. > I don't agree with you. First, there is no such words. > Second, if it is used in a JSON Schema as a "$ref" value, it should be > both JSON String and URI. > > > The intent of the draft is to establish rules for encoding in a JSON stri= ng > or in a URI. Of course, I agree that a URI can in turn be expressed in a > JSON string, but in this case, URI encoding applies; you do not > mix-and-match encodings. > > > By the way, do we really *need another escape* even there are two > encodings already? > > > I'm not sure what you mean here. If you encode as URI, presumably all val= id > URI characters are representable without any further escaping in a JSON > string. We have URI encoding and JSON String encoding. Why do we need another escape or encoding for JSON Pointer? > > Paul > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --=20 -- James Chi From pbryan@anode.ca Tue Mar 27 19:46:25 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C50521F86AB for ; Tue, 27 Mar 2012 19:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UEww0wyOfI5p for ; Tue, 27 Mar 2012 19:46:24 -0700 (PDT) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id C994A21F86A0 for ; Tue, 27 Mar 2012 19:46:24 -0700 (PDT) Received: from [10.71.9.110] (adsl-75-55-201-218.dsl.pltn13.sbcglobal.net [75.55.201.218]) by maple.anode.ca (Postfix) with ESMTPSA id 460ED6456 for ; Wed, 28 Mar 2012 02:46:23 +0000 (UTC) Message-ID: <1332902780.2403.3.camel@neutron> From: "Paul C. Bryan" To: apps-discuss@ietf.org Date: Tue, 27 Mar 2012 19:46:20 -0700 In-Reply-To: References: <4F7172FE.6060207@gmx.de> <4F71CD46.5070603@gmx.de> <1332898587.10875.5.camel@neutron> Content-Type: multipart/alternative; boundary="=-qHStMg/hjpDtJBr2Kn7v" X-Mailer: Evolution 3.2.2-1 Mime-Version: 1.0 Subject: Re: [apps-discuss] Confusing JSON Pointer X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 28 Mar 2012 02:46:25 -0000 --=-qHStMg/hjpDtJBr2Kn7v Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit On Wed, 2012-03-28 at 11:04 +0900, ì§€ì†¡ì› James Songwon Chi wrote: > We have URI encoding and JSON String encoding. Why do we need another > escape or encoding for JSON Pointer? JSON Pointer needs a separator character to separate reference tokens. The slash '/' character has proven to be the most intuitive separator to date. If this character appears in a token, however, it needs to be escaped so as not to be interpreted as a separator. Paul --=-qHStMg/hjpDtJBr2Kn7v Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit On Wed, 2012-03-28 at 11:04 +0900, 지송원 James Songwon Chi wrote:

We have URI encoding and JSON String encoding. Why do we need another escape or encoding for JSON Pointer?

JSON Pointer needs a separator character to separate reference tokens. The slash '/' character has proven to be the most intuitive separator to date. If this character appears in a token, however, it needs to be escaped so as not to be interpreted as a separator.

Paul --=-qHStMg/hjpDtJBr2Kn7v-- From chi880466@gmail.com Tue Mar 27 20:33:12 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8945E21E80CB for ; Tue, 27 Mar 2012 20:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.81 X-Spam-Level: * X-Spam-Status: No, score=1.81 tagged_above=-999 required=5 tests=[AWL=-0.541, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YtB1rCs+6vkf for ; Tue, 27 Mar 2012 20:33:12 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id F027121E801A for ; Tue, 27 Mar 2012 20:33:11 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so497925vcb.31 for ; Tue, 27 Mar 2012 20:33:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=8nH2vW+E4PA3+bH+bNksZSj9vwF4HYzrafpbaPl/0jo=; b=Zuilh8eIgEd0+V08QR/SD4ZYeVpewZdDwLpZTS3Nwe4h8nNtuAh7ijAAyLTUQPF3f1 +d9SAxk890SykXoVYDUwqrjmpztlqP90CQSWztuNggHeTJtShi3y6+hp/WHCK12MYpAQ DCOf7tNEt8iyX3EWIp6gznWNmpEJ3R7bbyVyZoSFx39LhCN0e5JezSDzS2VRmkSdznqr 4LpssLRD2uZMuaqhvP6xM/JbsdWrSNTb+R+JOzoryeBCcVtW+wsTukBrCyn79+BcQkcb 0EOPCDnrYFd199ZELJW6G7VD/+GD5QkaNpdZVQ8OSxPc/E3sqhZ7OSlMDds1hBGffaHk 6dXw== MIME-Version: 1.0 Received: by 10.52.19.196 with SMTP id h4mr10998422vde.91.1332905591216; Tue, 27 Mar 2012 20:33:11 -0700 (PDT) Received: by 10.220.1.4 with HTTP; Tue, 27 Mar 2012 20:33:11 -0700 (PDT) In-Reply-To: <1332902780.2403.3.camel@neutron> References: <4F7172FE.6060207@gmx.de> <4F71CD46.5070603@gmx.de> <1332898587.10875.5.camel@neutron> <1332902780.2403.3.camel@neutron> Date: Wed, 28 Mar 2012 12:33:11 +0900 Message-ID: From: =?EUC-KR?B?wfa827/4IEphbWVzIFNvbmd3b24gQ2hp?= To: "Paul C. Bryan" Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Confusing JSON Pointer X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 28 Mar 2012 03:33:12 -0000 2012=B3=E2 3=BF=F9 28=C0=CF =BF=C0=C0=FC 11:46, Paul C. Bryan =B4=D4=C0=C7 =B8=BB: > On Wed, 2012-03-28 at 11:04 +0900, =C1=F6=BC=DB=BF=F8 James Songwon Chi w= rote: > > We have URI encoding and JSON String encoding. Why do we need another esc= ape > or encoding for JSON Pointer? > > > JSON Pointer needs a separator character to separate reference tokens. Th= e > slash '/' character has proven to be the most intuitive separator to date= . > If this character appears in a token, however, it needs to be escaped so = as > not to be interpreted as a separator. I prefer '/' as a reference-token separator. What I don't like is using a caret(^) as a escape character. In the draft 00, the escape character was a reverse solidus(\) but it is changed to caret(^) in draft 01. Is there something that I missed? > > Paul > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > -- James Chi From duerst@it.aoyama.ac.jp Tue Mar 27 23:40:17 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4AE821E804B for ; Tue, 27 Mar 2012 23:40:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.033 X-Spam-Level: X-Spam-Status: No, score=-100.033 tagged_above=-999 required=5 tests=[AWL=-0.243, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13+y8SRDluWS for ; Tue, 27 Mar 2012 23:40:17 -0700 (PDT) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 1DDA521E8050 for ; Tue, 27 Mar 2012 23:40:16 -0700 (PDT) Received: from scmse01.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id q2S6e5Z6024137 for ; Wed, 28 Mar 2012 15:40:05 +0900 Received: from (unknown [133.2.206.133]) by scmse01.scbb.aoyama.ac.jp with smtp id 41c4_8551_da55b136_78a0_11e1_b401_001d096c566a; Wed, 28 Mar 2012 15:40:04 +0900 Received: from [IPv6:::1] ([133.2.210.1]:33148) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 28 Mar 2012 15:40:09 +0900 Message-ID: <4F72B241.60101@it.aoyama.ac.jp> Date: Wed, 28 Mar 2012 15:40:01 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: "Paul C. Bryan" References: <4F7172FE.6060207@gmx.de> <4F71CD46.5070603@gmx.de> <1332898587.10875.5.camel@neutron> In-Reply-To: <1332898587.10875.5.camel@neutron> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Confusing JSON Pointer X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 28 Mar 2012 06:40:18 -0000 Hello Paul, others, On 2012/03/28 10:36, Paul C. Bryan wrote: > On Wed, 2012-03-28 at 08:47 +0900, ì§€ì†¡ì› James Songwon Chi wrote: > >> 2012ë…„ 3ì›” 27ì¼ ì˜¤í›„ 11:23, Julian Reschkeë‹˜ì˜ ë§: >>> On 2012-03-27 15:49, ì§€ì†¡ì› James Songwon Chi wrote: >>>> 2012ë…„ 3ì›” 27ì¼ ì˜¤í›„ 4:57, Julian Reschkeë‹˜ì˜ ë§: >>>>> On 2012-03-27 07:22, ì§€ì†¡ì› James Songwon Chi wrote: >>>>>> And if my interpretation is wrong, to prevent the similar question, >>>>>> there should be some examples for this kind. >>>>>> ... Can we please make sure that we add some example(s) and clarify the spec so that such questions can be avoided in the future? > The intent of the draft is to establish rules for encoding in a JSON > string or in a URI. Of course, I agree that a URI can in turn be > expressed in a JSON string, but in this case, URI encoding applies; you > do not mix-and-match encodings. > > >> By the way, do we really *need another escape* even there are two >> encodings already? > > > I'm not sure what you mean here. If you encode as URI, presumably all > valid URI characters are representable without any further escaping in a > JSON string. Can we please make sure this is as clear as possible in the spec? Regards, Martin. From laurentwalter.goix@telecomitalia.it Tue Mar 27 23:55:54 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B511421E8150 for ; Tue, 27 Mar 2012 23:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.087 X-Spam-Level: X-Spam-Status: No, score=-1.087 tagged_above=-999 required=5 tests=[AWL=0.632, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4qIqy-uG6WJc for ; Tue, 27 Mar 2012 23:55:53 -0700 (PDT) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA7521E8147 for ; Tue, 27 Mar 2012 23:55:53 -0700 (PDT) Received: from GRFHUB702BA020.griffon.local (10.188.101.112) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 28 Mar 2012 08:55:48 +0200 Received: from GRFMBX704BA020.griffon.local ([10.188.101.16]) by GRFHUB702BA020.griffon.local ([10.188.101.112]) with mapi; Wed, 28 Mar 2012 08:55:47 +0200 From: Goix Laurent Walter To: James M Snell , "Paul E. Jones" Date: Wed, 28 Mar 2012 08:55:31 +0200 Thread-Topic: [apps-discuss] Webfinger discussion Thread-Index: Ac0MRjJKu93SeVC1RESMGUYVDM+lcwAZb1wA Message-ID: References: <053201cd0b5d$c08c80f0$41a582d0$@packetizer.com> <20120326150556.GC3557@mail.yitter.info> <20120327084709.GB11491@mail.yitter.info> <00ac01cd0c34$cfc96f10$6f5c4d30$@packetizer.com> <00d201cd0c3a$b3672410$1a356c30$@packetizer.com> In-Reply-To: Accept-Language: en-US, it-IT Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: Catu JeH1 NwEc N/PB Rc+L R2oU UGEF WXDj WpAl Xxfa Yb5d ZLek ZqmE cIYc eTuA en5p; 3; YQBwAHAAcwAtAGQAaQBzAGMAdQBzAHMAQABpAGUAdABmAC4AbwByAGcAOwBqAGEAcwBuAGUAbABsAEAAZwBtAGEAaQBsAC4AYwBvAG0AOwBwAGEAdQBsAGUAagBAAHAAYQBjAGsAZQB0AGkAegBlAHIALgBjAG8AbQA=; Sosha1_v1; 7; {505E3304-E0BC-4F1D-A264-F5A86425B47B}; bABhAHUAcgBlAG4AdAB3AGEAbAB0AGUAcgAuAGcAbwBpAHgAQAB0AGUAbABlAGMAbwBtAGkAdABhAGwAaQBhAC4AaQB0AA==; Wed, 28 Mar 2012 06:55:31 GMT; UgA6ACAAWwBhAHAAcABzAC0AZABpAHMAYwB1AHMAcwBdACAAVwBlAGIAZgBpAG4AZwBlAHIAIABkAGkAcwBjAHUAcwBzAGkAbwBuAA== x-cr-puzzleid: {505E3304-E0BC-4F1D-A264-F5A86425B47B} acceptlanguage: en-US, it-IT x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" Subject: [apps-discuss] R: Webfinger discussion X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 28 Mar 2012 06:55:54 -0000 SGVsbG8gamFtZXMsIGFsbCwNCg0KSSBjb3VsZCBzZWUgbWFueSBzb3J0IG9mIHRocmVhZHMgZ29p bmcgaW4gcGFyYWxsZWwgaW4gdGhpcyBkaXNjdXNzaW9uIGFkZHJlc3NpbmcgZGlmZmVyZW50IHR5 cGVzIG9mIGNvbmNlcm5zLiBJIGRvbid0IHdhbnQgdG8gZW50ZXIgdGhlICJzZWN1cml0eSIgZGlz Y3Vzc2lvbiBoZXJlIGJ1dCByYXRoZXIgY29tbWVudCBvbiBzb21lIHNwZWNpZmljIHRlY2huaWNh bCBwb2ludHMgcmVsYXRlZCB0byB0aGUgInByb3RvY29sIjoNCg0KLSB0aGUgImZpbmdlciIgKG9y IGxyZGQpIHdlbGwta25vd24gZW5kcG9pbnQgY291bGQgYmUgYSBzaG9ydGN1dCB0byBjb25zaWRl ciB0byBkaXJlY3RseSBpbnZva2UgdGhlIHdlYmZpbmdlciBlbmRwb2ludCB3aXRob3V0IHRoZSBu ZWVkIGZvciB0aGUgaG9zdC1tZXRhLiBUaGlzIHNraXBzIG9uZSBodHRwIHRyYW5zYWN0aW9uLCBh bHRob3VnaCBJIHdvdWxkIGltYWdpbmUgaW4gbW9zdCBjYXNlcyB0aGF0IHRoZSBob3N0LW1ldGEg eHJkIDEpIGNhbiBiZSBjYWNoZWQgYnkgdGhlIGludm9raW5nIGNsaWVudCwgMikgY2FuIGNvbnRh aW4gYWRkaXRpb25hbCB1c2VmdWwgaW5mbyAoZWcgT0V4Y2hhbmdlIGVuZHBvaW50IGxpbmspLg0K DQotIEkgYW0gbm90IHN1cmUgYWJvdXQgdGhlIGV4YWN0IHZhbHVlIGJyb3VnaHQgYnkgdGhlIG1k NSBoYXNoLCBhbHNvIGNvbnNpZGVyaW5nIHRoYXQgQVBJcyBhbHJlYWR5IGV4aXN0IChlLmcuIE9w ZW5Tb2NpYWwpIHRoYXQgdXNlIHBsYWluIGlkZW50aWZpZXJzIGFzIHBhcnQgb2YgdGhlIHBhdGgu IEkgY2Fubm90IHNlZSBtdWNoIGRpZmZlcmVuY2UgaGVyZSB3cnQgc2VjdXJpdHkgdGhhdCBqdXN0 aWZpZXMgdGhpcyBuZWVkIGZvciB3ZWJmaW5nZXIuIEluIGFueSBjYXNlIHN1cHBvcnQgZm9yIG1k NSBoYXNoIHdvdWxkIHByb2JhYmx5IG5lZWQgdG8gYmUgZGVjbGFyZWQgYnkgdGhlIHNlcnZlciwg ZWcgdXNpbmcge21kNXVyaX0gaW5zdGVhZCBvZiB7dXJpfSBpbiB0aGUgbHJkZCB0ZW1wbGF0ZS4N Cg0KLSByZWdhcmRpbmcgdGhlIHNob3J0Y3V0cyB0byBsaW5rIHJlbCB0eXBlcyB0aGlzIGlzIGJl Y29taW5nIG1vcmUgYSBwcm90b2NvbCBmb3IgYWNjZXNzaW5nIHVzZXIgaW5mbyByYXRoZXIgdGhh biBkaXNjb3ZlcnkuIGkgY2FuIHNlZSB0aGlzIGFzIGEgZGlyZWN0L3N0YW5kYXJkIEFQSS9VUkwg dG8gYWNjZXNzIHVzZXIgaW5mb3JtYXRpb24gKGUuZy4gYXZhdGFyLCBwcm9maWxlLXBhZ2UpLiBU aGlzIG1pc3NlcyB0aGUgInR5cGUiIChjb250ZW50LXR5cGUpIHdoaWNoIG1heSB2YXJ5IHdpdGhp biBhIHNpbmdsZSByZWwgKGFsdGhvdWdoIHRoaXMgY291bGQgYmUgYWRkcmVzc2VkIGJ5IEFjY2Vw dDogaGVhZGVycykgYW5kIGlzIHNpZ25pZmljYW50bHkgZGlmZmVyZW50IGZyb20gdGhlIG9yaWdp bmFsIHNjb3BlIG9mIHdlYmZpbmdlciBmb3IgZGlzY292ZXJ5IG9ubHkgKEkgY291bGQgaW1hZ2lu ZSB5b3UgY291bGQgZnVydGhlciBleHRlbmQgeW91ciBwcm9wb3NhbCB0byBwZXJmb3JtIENSVUQg b3BlcmF0aW9ucyBvbiB0aGUgc2luZ2xlIHJlbHMsIHdoaWNoIHRlbmRzIHRvIGJlY29tZSBjbG9z ZSB0byBvcGVuc29jaWFsIGFwaXMpLg0KVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGUg eHJkL2pyZCBjYW4gaW4gZmFjdCBlYXNpbHkgYmUgY2FjaGVkIGFsdG9nZXRoZXIgZm9yIHN1YnNl cXVlbnQgdXNlIGFuZCBub3QgZm9yIGltbWVkaWF0ZSBjb25zdW1wdGlvbiBvZiBhbGwgcmVsIHR5 cGVzLiBJIHdvdWxkIGFzc3VtZSB0aGlzIGlzIG5vdCBtb3JlIGNvbXBsZXggdGhhbiBwYXJzaW5n IHRoZSB2YXJpb3VzIExpbms6IGhlYWRlcnMgaW4gdGhlIHJlc3BvbnNlcy4NCkJ1dCBpIGNhbiB1 bmRlcnN0YW5kIHRoZXJlIG1heSBiZSBzb21lIG5ldyB1c2UgY2FzZSB3aGVyZSBhIHVzZXIgaXMg b25seSBpbnRlcmVzdGVkIGluIDEtMiByZWxzIGZvciBpbnN0YW50IGNvbnN1bXB0aW9uLCBhbmQg c29tZSBzb2x1dGlvbiBtYXkgYmUgaW52ZXN0aWdhdGVkIGZvciB0aGlzLg0KDQotIHJlZ2FyZGlu ZyBPQXV0aCBpdCBjYW4gYmUgdmFsdWFibGUgaW4gY2FzZSB3ZWJmaW5nZXIgaXMgcXVlcmllZCBk aXJlY3RseSBieSBhcHBsaWNhdGlvbnMuIEhvd2V2ZXIgaW4gbW9zdCBjdXJyZW50IHVzYWdlcyAo b3N0YXR1cywgZGlhc3BvcmEsIGV0YykgdGhlIHdlYmZpbmdlciBkaXNjb3ZlcnkgcHJvY2VzcyBp cyBwZXJmb3JtZWQgYnkgYSBzZXJ2ZXIgb2YgYW5vdGhlciBkb21haW4sIHRodXMgbGltaXRpbmcg dGhlIHBvc3NpYmxlIHVzYWdlIG9mIG9hdXRoIGluIHRoYXQgY2FzZS4NCg0Kd2FsdGVyDQoNCi0t LS0tTWVzc2FnZ2lvIG9yaWdpbmFsZS0tLS0tDQpEYTogYXBwcy1kaXNjdXNzLWJvdW5jZXNAaWV0 Zi5vcmcgW21haWx0bzphcHBzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9yZ10gUGVyIGNvbnRvIGRp IEphbWVzIE0gU25lbGwNCkludmlhdG86IG1hcnRlZMOsIDI3IG1hcnpvIDIwMTIgMjAuMTkNCkE6 IFBhdWwgRS4gSm9uZXMNCkNjOiBhcHBzLWRpc2N1c3NAaWV0Zi5vcmcNCk9nZ2V0dG86IFJlOiBb YXBwcy1kaXNjdXNzXSBXZWJmaW5nZXIgZGlzY3Vzc2lvbg0KDQpUaGV5IGFyZSByYXRoZXIgdGVj aG5pY2FsIGluIG5hdHVyZSBhbmQgc3BlYWsgdG8gdGhlIG92ZXJhbGwgb3BlcmF0aW9uDQpvZiB0 aGUgcHJvdG9jb2wuIEkndmUgd3JpdHRlbiB1cCBhIGRldGFpbGVkIHZlcnNpb24gb2YgbXkgZmVl ZGJhY2sNCmhlcmUgWzFdDQoNClsxXSBodHRwOi8vY2htb2Q3NzdzZWxmLmJsb2dzcG90LmNvbS8y MDEyLzAzL3Rob3VnaHRzLW9uLXdlYmZpbmdlci5odG1sDQoNClRoZSBzdW1tYXJ5IHZlcnNpb24g aXMgdGhpczogSSBiZWxpZXZlIHdlIGNhbiBtYWtlIHRoaXMgZXZlbiBzaW1wbGVyDQp3aXRob3V0 IHNhY3JpZmljaW5nIGJhc2ljIG9wZXJhdGlvbiBieSBzYXlpbmcgc2ltcGx5Og0KDQogIElmIEkg d2FudCB0byBrbm93IGFib3V0IHVzZXIgImJvYkBleGFtcGxlLm9yZyIsIHNlbmQgYSBHRVQgcmVx dWVzdCB0bzoNCiAgaHR0cDovL2V4YW1wbGUub3JnLy53ZWxsLWtub3duL2Zpbmdlci97bWQ1KGFj Y3Q6Ym9iQGV4YW1wbGUub3JnKX0gYW5kDQogIHNlZSB3aGF0IEkgZ2V0IGJhY2suDQoNClRoZSBy ZXF1aXJlbWVudCB0byB1c2UgWFJEL0pSRCBhbmQgZmlyc3QgbG9vayB1cCBpbmZvcm1hdGlvbiBh Ym91dCB0aGUNCkxSREQgc2VydmljZSBpbiBob3N0LW1ldGEgaXMgcXVpdGUgdW5uZWNlc3Nhcnku IEFsc28gbm90ZSB0aGF0IHRoZSBJRA0KaXMgaGFzaGVkIGluIHRoZSByZXF1ZXN0IFVSSSBmb3Ig cHJpdmFjeS9zZWN1cml0eSBwdXJwb3Nlcy4uLg0KDQpXZSBjYW4gZXhwYW5kIG9uIHRoYXQgYmFz aWMgaWRlYSBmdXJ0aGVyIHRvIHNheToNCg0KICBJZiBJIHdhbnQgdG8ga25vdyBpZiAiYm9iQGV4 YW1wbGUub3JnIiBoYXMgYSAiYmxvZyIgYW5kIHdoZXJlIGl0IGlzIGxvY2F0ZWQsDQogIEkgY291 bGQgc2ltcGx5IHNlbmQgYSByZXF1ZXN0IHRvOg0KICBodHRwOi8vZXhhbXBsZS5vcmcvLndlbGwt a25vd24vZmluZ2VyL2Y0OWM1MzNmYTBmMGJjN2VlOWNjOGM4ODkwMjMwMmJhL2Jsb2cNCg0KICBh bmQgdGhlIHNlcnZlciBjYW4gcmVzcG9uZCB3aXRoIGEgcmVkaXJlY3QgdG8gdGhlIHByb3BlciBs b2NhdGlvbjoNCg0KICBIVFRQLzEuMSAzMDIgRm91bmQNCiAgTG9jYXRpb246IGh0dHA6Ly9ibG9n cy5leGFtcGxlLm9yZy9ib2INCg0KVGhlICIvYmxvZyIgcG9ydGlvbiBvZiB0aGUgcmVxdWVzdCBV Ukkgc3BlY2lmaWVzIGEgTGluayByZWwuLi4gaWYgSQ0Kd2FudCB0byBkaXNjb3ZlciBzb21lIG90 aGVyIHR5cGUgb2Ygc2VydmljZS4uLiBzYXksIHRoZSB1c2VycyBwcm9maWxlDQpvciBhdmF0YXIs IEkgc2ltcGx5IGxpbmsgdGhlIGRpZmZlcmVudCByZWwgYXR0cmlidXRlIHZhbHVlIHRoZXJlLi4N CmUuZy4NCg0KICBodHRwOi8vZXhhbXBsZS5vcmcvLndlbGwta25vd24vZmluZ2VyL2Y0OWM1MzNm YTBmMGJjN2VlOWNjOGM4ODkwMjMwMmJhL2F2YXRhcg0KICBodHRwOi8vZXhhbXBsZS5vcmcvLndl bGwta25vd24vZmluZ2VyL2Y0OWM1MzNmYTBmMGJjN2VlOWNjOGM4ODkwMjMwMmJhL3Byb2ZpbGUN Cg0KSWYgdGhlcmUgYXJlIG11bHRpcGxlIGxpbmtzIGZvciBhIHBhcnRpY3VsYXIgcmVsLCB0aGUg c2VydmVyIGNhbg0KcmVzcG9uZCB3aXRoIGEgMzAwIE11bHRpcGxlIE9wdGlvbnMgcmVzcG9uc2Uu DQoNClRoZSBwb2ludCBpcyB0aGF0IHJlcXVpcmluZyBYUkQvSlJEIGlzbid0IGFjdHVhbGx5IG5l Y2Vzc2FyeSwgYW5kDQpyZXF1aXJpbmcgdGhlIGluaXRpYWwgaG9zdCBtZXRhZGF0YSBzdGVwIGlz bid0IHJlcXVpcmVkIGFsc28uDQoNClJlcXVpcmluZyBDT1JTIGlzIGFsc28gaXNuJ3QgbmVjZXNz YXJ5Lg0KDQpBbnl3YXksIHRoYXQncyB0aGUgYmFzaWMgcnVuZG93bi4NCg0KLSBKYW1lcw0KDQpP biBUdWUsIE1hciAyNywgMjAxMiBhdCA5OjU3IEFNLCBQYXVsIEUuIEpvbmVzIDxwYXVsZWpAcGFj a2V0aXplci5jb20+IHdyb3RlOg0KPiBKYW1lcywNCj4NCj4gSWYgdGhlIG90aGVyIGl0ZW1zIGFy ZSBlZGl0b3JpYWwsIHBlcmhhcHMganVzdCBkaXJlY3QgdGhlbSB0byBtZS4gIElmIHRoZXkgYXJl IGl0ZW1zIHRoYXQgb3RoZXJzIG1pZ2h0IHdhbnQgdG8gd2VpZ2ggaW4gb24sIHRoZW4gdGhpcyBs aXN0IGlzIHRoZSBhcHByb3ByaWF0ZSB2ZW51ZS4NCj4NCj4gUGF1bA0KPg0KPj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IEphbWVzIE0gU25lbGwgW21haWx0bzpqYXNuZWxs QGdtYWlsLmNvbV0NCj4+IFNlbnQ6IFR1ZXNkYXksIE1hcmNoIDI3LCAyMDEyIDEyOjM5IFBNDQo+ PiBUbzogUGF1bCBFLiBKb25lcw0KPj4gQ2M6IEFuZHJldyBTdWxsaXZhbjsgYXBwcy1kaXNjdXNz QGlldGYub3JnDQo+PiBTdWJqZWN0OiBSZTogW2FwcHMtZGlzY3Vzc10gV2ViZmluZ2VyIGRpc2N1 c3Npb24NCj4+DQo+PiBUbyBiZSBmYWlyLCB0aGVyZSBhcmUgd2F5cyBvZiBkZWFsaW5nIHdpdGgg dGhlIHBvdGVudGlhbCBmb3Igc2VjdXJpdHkNCj4+IGxlYWtzIG9mIHRoaXMgbmF0dXJlIHdpdGgg V2ViRmluZ2VyIHRoYXQgZGlkIG5vdCByZWFsbHkgZXhpc3Qgd2l0aCB0aGUNCj4+IG9yaWdpbmFs IEZpbmdlciBwcm90b2NvbC4gT0F1dGggMiwgZm9yIGluc3RhbmNlLiBBIFdlYkZpbmdlciBlbmRw b2ludA0KPj4gY291bGQgY2hvb3NlIHRvIHNlcnZlIHVwIG9ubHkgdGhlIG1vc3QgYmFzaWMgc3Rh dGljIGluZm9ybWF0aW9uIHRvDQo+PiB1bmF1dGhlbnRpY2F0ZWQgcmVxdWVzdGVycywgYnV0IHRo ZW4gcHJvdmlkZSBhIG1lYW5zIGZvciBhIHJlcXVlc3RlciB0bw0KPj4gYXV0aGVudGljYXRlIGFu ZCByZXF1ZXN0IHBlcm1pc3Npb24gZnJvbSB0aGUgdGFyZ2V0IHVzZXIgb3IgcHJvdmlkZXIgdG8N Cj4+IGFjcXVpcmUgYWRkaXRpb25hbCBpbmZvcm1hdGlvbiBhcyBwYXJ0IG9mIHRoZSByZXNwb25z ZS4NCj4+DQo+PiBPbiBhIHNpZGUgbm90ZSB0byBQYXVsOiBJIGRpZCBoYXZlIHNvbWUgYWRkaXRp b25hbCBnZW5lcmFsIGNvbW1lbnRzIG9uIHRoZQ0KPj4gV2ViRmluZ2VyIHNwZWMgaXRzZWxmLCBJ IHdhbnRlZCB0byBhc2sgd2hlcmUgc3VjaCBjb21tZW50cyB3b3VsZCBiZSBiZXN0DQo+PiBkaXJl Y3RlZCBmb3IgZGlzY3Vzc2lvbi4NCj4+DQo+PiAtIEphbWVzDQo+Pg0KPj4gT24gVHVlLCBNYXIg MjcsIDIwMTIgYXQgOToxNSBBTSwgUGF1bCBFLiBKb25lcyA8cGF1bGVqQHBhY2tldGl6ZXIuY29t Pg0KPj4gd3JvdGU6DQo+PiA+IEkgYWdyZWUgaXQgd291bGQgYmUgdXNlZnVsIHRvIGFkZCB0ZXh0 IGFib3V0IHNoYXJpbmcgaW5mb3JtYXRpb24gdGhhdA0KPj4gPiBtaWdodCBiZSBkeW5hbWljIGlu IG5hdHVyZSAoZS5nLiwgY3VycmVudCB1c2VyIGxvY2F0aW9uKS4NCj4+ID4NCj4+ID4gV2UnbGwg YWRkIHRleHQgYWxvbmcgdGhvc2UgbGluZXMgdG8gdGhlIG5leHQgZHJhZnQuICBBbnkgb3RoZXIN Cj4+ID4gc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgd2Ugc2hvdWxkIG5vdGU/DQo+PiA+DQo+PiA+ IFBhdWwNCj4+ID4NCj4+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiA+PiBGcm9t OiBhcHBzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9yZw0KPj4gPj4gW21haWx0bzphcHBzLWRpc2N1 c3MtYm91bmNlc0BpZXRmLm9yZ10NCj4+ID4+IE9uIEJlaGFsZiBPZiBBbmRyZXcgU3VsbGl2YW4N Cj4+ID4+IFNlbnQ6IFR1ZXNkYXksIE1hcmNoIDI3LCAyMDEyIDQ6NDcgQU0NCj4+ID4+IFRvOiBh cHBzLWRpc2N1c3NAaWV0Zi5vcmcNCj4+ID4+IFN1YmplY3Q6IFJlOiBbYXBwcy1kaXNjdXNzXSBX ZWJmaW5nZXIgZGlzY3Vzc2lvbg0KPj4gPj4NCj4+ID4+IE9uIE1vbiwgTWFyIDI2LCAyMDEyIGF0 IDAyOjMxOjMwUE0gLTA0MDAsIEJvYiBXeW1hbiB3cm90ZToNCj4+ID4+DQo+PiA+PiA+IHVuLXJl Y29tbWVuZGVkISkuIElmIHBlb3BsZSBkaWQsIGluIGZhY3QsIHVzZSBXZWJGaW5nZXIgdG8gcmVj b3JkDQo+PiA+PiA+IHN1Y2ggc3R1ZmYsIHRoZSBjb25jZXJucyB5b3UgbWVudGlvbmVkIHdvdWxk IGJlIHJlbGV2YW50LiBUaHVzLCBpdA0KPj4gPj4gPiBtaWdodCBtYWtlIHNlbnNlIGZvciB0aGUg U2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgc2VjdGlvbiB0byBzdWdnZXN0DQo+PiA+PiA+IHRoYXQg b25lIHNob3VsZCB0aGluayBjYXJlZnVsbHkgYmVmb3JlIHVzaW5nIFdlYkZpbmdlciB0byBwcm92 aWRlDQo+PiA+PiA+IHN1Y2ggZHluYW1pYw0KPj4gPj4gaW5mb3JtYXRpb24uDQo+PiA+Pg0KPj4g Pj4gUmlnaHQsIHRoYXQncyBtb3N0IG9mIHdoYXQgSSB3YXMgdHJ5aW5nIHRvIHNheS4gIEkgZG8g aGF2ZSBhIGNvbmNlcm4NCj4+ID4+IHRoYXQgY29sbGVjdGluZyBhIGJ1bmNoIG9mIGRpZmZlcmVu dCBpbmZvcm1hdGlvbiBhYm91dCBhIGdpdmVuIHBlcnNvbg0KPj4gPj4gYW5kIGxpbmtpbmcgaXQg dG9nZXRoZXIgaW4gYSBzaW5nbGUsIGVhc3kgdG8gYWNjZXNzIHJlcG9zaXRvcnkgaGFzDQo+PiA+ PiBzb21lIHBvdGVudGlhbCBzZWN1cml0eSBzaWRlIGVmZmVjdHMgKG5vdCBqdXN0IHByaXZhY3kg b25lcywgYnV0DQo+PiA+PiB0aG9zZSB0b28sIG9mDQo+PiA+PiBjb3Vyc2UpIHRoYXQgYXJlIG5v dCBjbGVhcmx5IGhpZ2hsaWdodGVkIGluIHRoZSBzZWN1cml0eQ0KPj4gY29uc2lkZXJhdGlvbnMu DQo+PiA+PiBJIHN1cHBvc2Ugb25lIGNvdWxkIGFyZ3VlIHRoYXQgZmFjZWJvb2sncyAob3IgcGlj ayB5b3VyIHBvaXNvbikgdXNlcg0KPj4gPj4gcG9wdWxhdGlvbiBzaG93cyBub2JvZHkgY2FyZXMg YWJvdXQgdGhhdCwgYnV0IEkgdGhpbmsgaXQgd291bGQgc3RpbGwNCj4+ID4+IGJlIGdvb2QgdG8g aGF2ZSBzb21lIG9ic2VydmF0aW9ucyBhYm91dCB0aG9zZSBlZmZlY3RzLg0KPj4gPj4NCj4+ID4+ IEJlc3QsDQo+PiA+Pg0KPj4gPj4gQQ0KPj4gPj4NCj4+ID4+IC0tDQo+PiA+PiBBbmRyZXcgU3Vs bGl2YW4NCj4+ID4+IGFqc0BhbnZpbHdhbHJ1c2Rlbi5jb20NCj4+ID4+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+PiBhcHBzLWRpc2N1c3MgbWFp bGluZyBsaXN0DQo+PiA+PiBhcHBzLWRpc2N1c3NAaWV0Zi5vcmcNCj4+ID4+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXBwcy1kaXNjdXNzDQo+PiA+DQo+PiA+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+IGFwcHMtZGlz Y3VzcyBtYWlsaW5nIGxpc3QNCj4+ID4gYXBwcy1kaXNjdXNzQGlldGYub3JnDQo+PiA+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXBwcy1kaXNjdXNzDQo+DQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KYXBwcy1kaXNjdXNzIG1h aWxpbmcgbGlzdA0KYXBwcy1kaXNjdXNzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2FwcHMtZGlzY3Vzcw0KDQpRdWVzdG8gbWVzc2FnZ2lvIGUgaSBzdW9p IGFsbGVnYXRpIHNvbm8gaW5kaXJpenphdGkgZXNjbHVzaXZhbWVudGUgYWxsZSBwZXJzb25lIGlu ZGljYXRlLiBMYSBkaWZmdXNpb25lLCBjb3BpYSBvIHF1YWxzaWFzaSBhbHRyYSBhemlvbmUgZGVy aXZhbnRlIGRhbGxhIGNvbm9zY2VuemEgZGkgcXVlc3RlIGluZm9ybWF6aW9uaSBzb25vIHJpZ29y b3NhbWVudGUgdmlldGF0ZS4gUXVhbG9yYSBhYmJpYXRlIHJpY2V2dXRvIHF1ZXN0byBkb2N1bWVu dG8gcGVyIGVycm9yZSBzaWV0ZSBjb3J0ZXNlbWVudGUgcHJlZ2F0aSBkaSBkYXJuZSBpbW1lZGlh dGEgY29tdW5pY2F6aW9uZSBhbCBtaXR0ZW50ZSBlIGRpIHByb3Z2ZWRlcmUgYWxsYSBzdWEgZGlz dHJ1emlvbmUsIEdyYXppZS4NCg0KVGhpcyBlLW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBpcyBj b25maWRlbnRpYWwgYW5kIG1heSBjb250YWluIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gaW50ZW5k ZWQgZm9yIHRoZSBhZGRyZXNzZWUocykgb25seS4gRGlzc2VtaW5hdGlvbiwgY29weWluZywgcHJp bnRpbmcgb3IgdXNlIGJ5IGFueWJvZHkgZWxzZSBpcyB1bmF1dGhvcmlzZWQuIElmIHlvdSBhcmUg bm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBkZWxldGUgdGhpcyBtZXNzYWdlIGFu ZCBhbnkgYXR0YWNobWVudHMgYW5kIGFkdmlzZSB0aGUgc2VuZGVyIGJ5IHJldHVybiBlLW1haWws IFRoYW5rcy4NCg0K From masinter@adobe.com Wed Mar 28 01:42:28 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D848121F8779 for ; Wed, 28 Mar 2012 01:42:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.628 X-Spam-Level: X-Spam-Status: No, score=-106.628 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eJYAvmUiLtmC for ; Wed, 28 Mar 2012 01:42:28 -0700 (PDT) Received: from exprod6og108.obsmtp.com (exprod6og108.obsmtp.com [64.18.1.21]) by ietfa.amsl.com (Postfix) with ESMTP id B835921F876A for ; Wed, 28 Mar 2012 01:42:27 -0700 (PDT) Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob108.postini.com ([64.18.5.12]) with SMTP ID DSNKT3LO7zCiZRggTILKEO6FXa6J1kvLORC8@postini.com; Wed, 28 Mar 2012 01:42:27 PDT Received: from inner-relay-1.corp.adobe.com (inner-relay-1.corp.adobe.com [153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id q2S8gMvq020124; Wed, 28 Mar 2012 01:42:22 -0700 (PDT) Received: from nahub02.corp.adobe.com (nahub02.corp.adobe.com [10.8.189.98]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id q2S8gLMM007928; Wed, 28 Mar 2012 01:42:21 -0700 (PDT) Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nahub02.corp.adobe.com ([10.8.189.98]) with mapi; Wed, 28 Mar 2012 01:42:21 -0700 From: Larry Masinter To: "julian.reschke@gmx.de" , Barry Leiba Date: Wed, 28 Mar 2012 01:42:19 -0700 Thread-Topic: [apps-discuss] Use of RFC 2119, Re: WGLC: draft-ietf-appsawg-about-uri-scheme-03.txt Thread-Index: Ac0HLiDU8Ev7DMOBSIK0OILPgCaxTQFj8uRA Message-ID: References: <503575970.11554@cnnic.cn> <4A10020DB6464A0BBA535BF75D21A9D9@LENOVO47E041CF> <9452079D1A51524AA5749AD23E003928094CEB@exch-mbx901.corp.cloudmark.com> <4F6978D8.10605@gmx.de> In-Reply-To: <4F6978D8.10605@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@ietf.org" Subject: Re: [apps-discuss] Use of RFC 2119, Re: WGLC: draft-ietf-appsawg-about-uri-scheme-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 28 Mar 2012 08:42:29 -0000 rfc4395 and http://tools.ietf.org/html/draft-ietf-iri-4395bis-irireg-04 bot= h use 2119 keywords in the same way: Within this document, the key words MUST, MAY, SHOULD, REQUIRED, RECOMMENDED, and so forth are used within the general meanings established in [RFC2119], within the context that they are requirements on future registration specifications. i.e., just in the sense that "about:" is establishing a second-level regist= ration. Is a FCFS policy by itself consistent with having MUST and SHOULD requireme= nts on the registration?=20 >> [Relatively] Minor Issues: >> I'm not so sure about use of RFC2119 language in the IANA Considerations >> section. You're not really describing interoperability requirements wit= h IANA. > > I'm sure. And it's my text -- this is one that Mykyta doesn't like. > The three MUSTs in there are not directed at IANA, but at people > writing new registrations. They tell those people what their > registrations have to look like, and I wanted to use MUST to stress > that even though this is an FCFS policy, there are requirements > nonetheless. > ... I'm with Murray here. This is something RFC 2119 keywords are not for. Best regards, Julian _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From barryleiba@gmail.com Wed Mar 28 01:54:26 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9CDF21F895F for ; Wed, 28 Mar 2012 01:54:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.776 X-Spam-Level: X-Spam-Status: No, score=-101.776 tagged_above=-999 required=5 tests=[AWL=-1.255, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SdBeW-W-GUzf for ; Wed, 28 Mar 2012 01:54:26 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 22A9421F895E for ; Wed, 28 Mar 2012 01:54:26 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so1235417obb.31 for ; Wed, 28 Mar 2012 01:54:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=KaJEWzSzhhEAnDAy7DKiBTlOxDH1y9SK+VHK9hP6shw=; b=QGyOlZCWEwTh5bUTanj8en/zig4OyphXHigcmAz0+hfz04w56sqs0JLCOvoxicRA1W aTkrwZ35dWz5oAzxtIAX7Vz2N40PsIxGCt+iAjicIGU+xcBT6k5Cb52Adt+KwWiDBmVu eG6HH+46caXPGgMHEr4ZetPFheMIyxRPwgyCofUuadcV8lF8orweEvhwx91eK/ubJ4q3 xKNMzkAgvtrEQcYxLkhXy4pL1EuE5f3CZyqQlBkAMbq8OfHXg3uBMoSjC4ydBjbUTStk YKhSp+GwNSgpDMQK6fpqZ5IbjgqKPK8wW85draJzppyptVaDj+eL+kCK3y6jXWh6zDS8 WOUA== MIME-Version: 1.0 Received: by 10.182.154.7 with SMTP id vk7mr3078125obb.22.1332924865628; Wed, 28 Mar 2012 01:54:25 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.60.10.68 with HTTP; Wed, 28 Mar 2012 01:54:25 -0700 (PDT) In-Reply-To: References: <503575970.11554@cnnic.cn> <4A10020DB6464A0BBA535BF75D21A9D9@LENOVO47E041CF> <9452079D1A51524AA5749AD23E003928094CEB@exch-mbx901.corp.cloudmark.com> <4F6978D8.10605@gmx.de> Date: Wed, 28 Mar 2012 04:54:25 -0400 X-Google-Sender-Auth: yeY4TOOxPCXKxyFkCFjj5TgRWGU Message-ID: From: Barry Leiba To: Larry Masinter Content-Type: multipart/alternative; boundary=f46d04479fdd20c8b904bc49c1b1 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Use of RFC 2119, Re: WGLC: draft-ietf-appsawg-about-uri-scheme-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 28 Mar 2012 08:54:27 -0000 --f46d04479fdd20c8b904bc49c1b1 Content-Type: text/plain; charset=ISO-8859-1 On Wednesday, March 28, 2012, Larry Masinter wrote: > rfc4395 and http://tools.ietf.org/html/draft-ietf-iri-4395bis-irireg-04both use 2119 > keywords in the same way: Nevertheless, we've come to the decision to change it to lower-case words here. > Is a FCFS policy by itself consistent with having MUST and SHOULD requirements > on the registration? Sure; we're starting with FCFS (as in BCP 26), and then adding requirements. Perfectly fine. Barry --f46d04479fdd20c8b904bc49c1b1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wednesday, March 28, 2012, Larry Masinter <masinter@adobe.com> wrote:
> rfc4395 and http://too= ls.ietf.org/html/draft-ietf-iri-4395bis-irireg-04 both use 2119
> keywords in the same way:

Nevertheless, we've come to the d= ecision to change it to lower-case words here.

> Is a FCFS policy= by itself consistent with having MUST and SHOULD requirements
> on t= he registration?

Sure; we're starting with FCFS (as in BCP 26), and then adding requ= irements. =A0Perfectly fine.

Barry
--f46d04479fdd20c8b904bc49c1b1-- From alexey.melnikov@isode.com Wed Mar 28 01:58:36 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C45AC21F899D for ; Wed, 28 Mar 2012 01:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.352 X-Spam-Level: X-Spam-Status: No, score=-101.352 tagged_above=-999 required=5 tests=[AWL=-1.209, BAYES_00=-2.599, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GjVdNNBFrQ5I for ; Wed, 28 Mar 2012 01:58:36 -0700 (PDT) Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id D020121F899B for ; Wed, 28 Mar 2012 01:58:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1332925115; d=isode.com; s=selector; i=@isode.com; bh=wTwiU8Ji8ryQys40AfsJtB50zjZkKjoHGSXq/Pbpt84=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=gyzIsn25MhZIKDkMhWL6c16DXuegm9XA+y2EGYYcdp3cXsq1lhnpDHfJvaSflIsz+zXxgZ fKe2FQNFJsqx8BZxa9TNKxKDBZgMs0soqrOJIo9RMxP7X3d+Sle9RgusN/q4pubCSl8xaL qfjPV8zS6me+3dnV86JUH2+/TCqG+zo=; Received: from [130.129.23.230] (dhcp-17e6.meeting.ietf.org [130.129.23.230]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 28 Mar 2012 09:58:34 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <4F72D2C0.2040604@isode.com> Date: Wed, 28 Mar 2012 10:58:40 +0200 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: Barry Leiba References: <503575970.11554@cnnic.cn> <4A10020DB6464A0BBA535BF75D21A9D9@LENOVO47E041CF> <9452079D1A51524AA5749AD23E003928094CEB@exch-mbx901.corp.cloudmark.com> <4F6978D8.10605@gmx.de> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------070005080904070700040809" Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Use of RFC 2119, Re: WGLC: draft-ietf-appsawg-about-uri-scheme-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 28 Mar 2012 08:58:37 -0000 This is a multi-part message in MIME format. --------------070005080904070700040809 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 28/03/2012 10:54, Barry Leiba wrote: > On Wednesday, March 28, 2012, Larry Masinter > wrote: [...] > > Is a FCFS policy by itself consistent with having MUST and SHOULD > requirements > > on the registration? > > Sure; we're starting with FCFS (as in BCP 26), and then adding > requirements. Perfectly fine. I think the question is who is going to enforce RFC 2119 language. --------------070005080904070700040809 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 28/03/2012 10:54, Barry Leiba wrote:
On Wednesday, March 28, 2012, Larry Masinter <masinter@adobe.com> wrote:
 [...]
> Is a FCFS policy by itself consistent with having MUST and SHOULD requirements
> on the registration?

Sure; we're starting with FCFS (as in BCP 26), and then adding requirements.  Perfectly fine.
I think the question is who is going to enforce RFC 2119 language.

--------------070005080904070700040809-- From barryleiba@gmail.com Wed Mar 28 02:04:30 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEEB021F89C8 for ; Wed, 28 Mar 2012 02:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.998 X-Spam-Level: X-Spam-Status: No, score=-102.998 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G7ut-KbDxrgn for ; Wed, 28 Mar 2012 02:04:30 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4350C21F8902 for ; Wed, 28 Mar 2012 02:04:30 -0700 (PDT) Received: by obbtb4 with SMTP id tb4so1249534obb.31 for ; Wed, 28 Mar 2012 02:04:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=EHABw5A54KaO2kklqJIQXoQqhF2A/9Qr0/NLRyW6vPo=; b=YljH5nTPN1Ba995s/YRLuhRbEhcHtzjONL0rgl3sJTxqsNanoeGqois8c0RB+f8ONv RPawrLoShTb/iOsz9sNE7YNBJR/ZlKCHlJDG88U9PxdypfJxcWgkzDSWYqV66McnKP1z jl+bshtQdCwk9ypAbFFyDfIJpKYr51Rfyuh1lAP1EG1JSsUK4nC1PtCtMWHZ1xhulOKU bPaKHyGJKVaFNiCnkMQ97jh3EJkblaWdUgOMyMZ7VoKQfkAoEL8RV1xDJyTyKaqRvVoi 67lI0kcTQCrUxLx5ZKD5Q8qOu/ik3eNtg6BzoY0XSQbXWF9vK+HTG3r3xd03Seo9JvSL sZlQ== MIME-Version: 1.0 Received: by 10.182.154.7 with SMTP id vk7mr3116371obb.22.1332925469842; Wed, 28 Mar 2012 02:04:29 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.60.10.68 with HTTP; Wed, 28 Mar 2012 02:04:29 -0700 (PDT) In-Reply-To: <4F72D2C0.2040604@isode.com> References: <503575970.11554@cnnic.cn> <4A10020DB6464A0BBA535BF75D21A9D9@LENOVO47E041CF> <9452079D1A51524AA5749AD23E003928094CEB@exch-mbx901.corp.cloudmark.com> <4F6978D8.10605@gmx.de> <4F72D2C0.2040604@isode.com> Date: Wed, 28 Mar 2012 05:04:29 -0400 X-Google-Sender-Auth: ey-qiIkQ3H5616F9lA6uY6xMHu4 Message-ID: From: Barry Leiba To: Alexey Melnikov Content-Type: multipart/alternative; boundary=f46d04479fdd245ee704bc49e5b3 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Use of RFC 2119, Re: WGLC: draft-ietf-appsawg-about-uri-scheme-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 28 Mar 2012 09:04:30 -0000 --f46d04479fdd245ee704bc49e5b3 Content-Type: text/plain; charset=ISO-8859-1 >> Sure; we're starting with FCFS (as in BCP 26), and then adding requirements. Perfectly fine. > > I think the question is who is going to enforce RFC 2119 language. Well, IANA's going to make sure the registration request contains the required information. And that's all we have there. b --f46d04479fdd245ee704bc49e5b3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >> Sure; we're starting with FCFS (as in BCP 26), and then adding= requirements. =A0Perfectly fine.
>
> I think the question is w= ho is going to enforce RFC 2119 language.

Well, IANA's going to = make sure the registration request contains the required information. =A0An= d that's all we have there.

b
--f46d04479fdd245ee704bc49e5b3-- From john-ietf@jck.com Wed Mar 28 02:42:40 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9502321F8928 for ; Wed, 28 Mar 2012 02:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.687 X-Spam-Level: X-Spam-Status: No, score=-102.687 tagged_above=-999 required=5 tests=[AWL=-0.088, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TvJp5fBFvNQT for ; Wed, 28 Mar 2012 02:42:40 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 03ACC21F8921 for ; Wed, 28 Mar 2012 02:42:39 -0700 (PDT) Received: from [198.252.137.7] (helo=PST.JCK.COM) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1SCpK5-0008I9-Ab; Wed, 28 Mar 2012 05:37:45 -0400 Date: Wed, 28 Mar 2012 05:42:33 -0400 From: John C Klensin To: 'Andrew Sullivan' , apps-discuss@ietf.org Message-ID: <924455E32E44385207331B9D@PST.JCK.COM> In-Reply-To: <20120327193247.GA12201@mail.yitter.info> References: <053201cd0b5d$c08c80f0$41a582d0$@packetizer.com> <20120326150556.GC3557@mail.yitter.info> <20120327084709.GB11491@mail.yitter.info> <00ac01cd0c34$cfc96f10$6f5c4d30$@packetizer.com> <20120327193247.GA12201@mail.yitter.info> 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 Subject: Re: [apps-discuss] Webfinger discussion X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 28 Mar 2012 09:42:40 -0000 --On Tuesday, March 27, 2012 15:32 -0400 'Andrew Sullivan' wrote: > On Tue, Mar 27, 2012 at 12:15:21PM -0400, Paul E. Jones wrote: >> We'll add text along those lines to the next draft. Any >> other security considerations we should note? > > I wish I had something more intelligent to say than, "Is > anyone [else] worried about the aggregation of this > information amd what it does to the security profile of the > aggregated things?" Note this isn't exactly the privacy > issue, though there's that. Short answer: yes. Slightly longer answer: While most of today's privacy discussions correctly focus on such questions as "why do you need to know that", "why should I tell you", and "if I do tell you, what control do I have over your telling others", many of the really hard questions lie in the observation that the more dimensions of information I know about you (or about your membership in various groups and categories) the more I identify you and predict your behavior in statistically-interesting ways. Now combining information associated with me@service1, me@service2, and me@service3 doesn't inherently create any extra risk unless you have (deliberately or accidentally) associated different information with those identities s.t. the information content in their union is significantly larger than the information content in their intersection. If that relationship holds, you are exposed to a new family of unintended disclosures, some of it based on statistical models of the behavior of populations that share a large enough number of attribute categories with you. I have no idea how we go about sorting it out, but I agree that we need to be clear about the possibility and risks. john From julian.reschke@gmx.de Wed Mar 28 03:57:46 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6182921F8A42 for ; Wed, 28 Mar 2012 03:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.913 X-Spam-Level: X-Spam-Status: No, score=-103.913 tagged_above=-999 required=5 tests=[AWL=-1.614, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lcpNQ6LZwA3w for ; Wed, 28 Mar 2012 03:57:45 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 207A921F8A3E for ; Wed, 28 Mar 2012 03:57:44 -0700 (PDT) Received: (qmail invoked by alias); 28 Mar 2012 10:57:43 -0000 Received: from mail.greenbytes.de (EHLO [IPv6:::1]) [217.91.35.233] by mail.gmx.net (mp035) with SMTP; 28 Mar 2012 12:57:43 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18U+gRN8ocUQs/CGakN2Y7RI6I3mzMv73oT0zhSOs VMwk9XRTuwfDJa Message-ID: <4F72EEA4.1060308@gmx.de> Date: Wed, 28 Mar 2012 12:57:40 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: =?UTF-8?B?7KeA7Iah7JuQIEphbWVzIFNvbmd3b24gQ2hp?= References: <4F7172FE.6060207@gmx.de> <4F71CD46.5070603@gmx.de> <1332898587.10875.5.camel@neutron> <1332902780.2403.3.camel@neutron> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Confusing JSON Pointer X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 28 Mar 2012 10:57:46 -0000 On 2012-03-28 05:33, ì§€ì†¡ì› James Songwon Chi wrote: > 2012ë…„ 3ì›” 28ì¼ ì˜¤ì „ 11:46, Paul C. Bryanë‹˜ì˜ ë§: >> On Wed, 2012-03-28 at 11:04 +0900, ì§€ì†¡ì› James Songwon Chi wrote: >> >> We have URI encoding and JSON String encoding. Why do we need another escape >> or encoding for JSON Pointer? >> >> >> JSON Pointer needs a separator character to separate reference tokens. The >> slash '/' character has proven to be the most intuitive separator to date. >> If this character appears in a token, however, it needs to be escaped so as >> not to be interpreted as a separator. > > I prefer '/' as a reference-token separator. What I don't like is > using a caret(^) as a escape character. > In the draft 00, the escape character was a reverse solidus(\) but it > is changed to caret(^) in draft 01. > Is there something that I missed? Using "\" would be awkward, because it would appear as "\\" in a JSON string. Best regards, Julian From vesely@tana.it Wed Mar 28 04:28:13 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B7AD21F889F for ; Wed, 28 Mar 2012 04:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rGYCMnVfp3ia for ; Wed, 28 Mar 2012 04:28:12 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 88A7621F889A for ; Wed, 28 Mar 2012 04:28:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1332934091; bh=rPEaATDRAwLjJzEi82Xj3NVLbrbjklfBFFKx+m1XU3U=; l=1293; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=cHwIAtv58w6d20+D7bsXhUrQUQC6/pZkDh8beytOaZP4gz1Mi9FafWnKy2+L4I3Wh QHW34U8ywGHY4av/RbP0RryE55HHPVMlBS1XTmEdMk+AEwPc/Vz79g6eNrlfTHSXk7 OBGPZNcmPbqP0kGtMLoieiB5EoGNSp4dWFedfrF0= Received: from [10.216.6.120] ([93.158.42.127]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Wed, 28 Mar 2012 13:28:08 +0200 id 00000000005DC039.000000004F72F5C9.00005C3A Message-ID: <4F72F5C0.70106@tana.it> Date: Wed, 28 Mar 2012 13:28:00 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <053201cd0b5d$c08c80f0$41a582d0$@packetizer.com> <20120326150556.GC3557@mail.yitter.info> <20120327084709.GB11491@mail.yitter.info> <00ac01cd0c34$cfc96f10$6f5c4d30$@packetizer.com> <00d201cd0c3a$b3672410$1a356c30$@packetizer.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [apps-discuss] What auth server supplies email addresses? Was webfinger discussion X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 28 Mar 2012 11:28:13 -0000 I reproach myself for having missed the Internet Society Panel on OpenID and OAuth yesterday morning. I'll try and find the recording. Meanwhile, does someone know if there is a way to get an email address from an id? On Wed 28/Mar/2012 12:40:20 +0200 James M Snell wrote: > > If I want to know about user "bob@example.org", send a GET request to: > http://example.org/.well-known/finger/{md5(acct:bob@example.org)} and > see what I get back. That implies the address is known. Couldn't one use just http://example.org/.well-known/finger/{opaque-token} and, possibly, http://example.org/.well-known/finger/{opaque-token}/email-addr? The idea is that the relevant user, well, Bob in this case, can be logged in more or less at the same time as he triggered an automatic query of that url. For example, he might be buying a DVD at Amazon's. Bob's server might let him choose whether to supply his plain email address or any variant thereof, possibly offering to update Sieve scripts while it's at it. Is perhaps SCIM, or whatever other framework, nearer to such kind of use cases? It could be used as a better double-opt-in... (Yes, I'm the one who asked what's the difference between Webfinger and SCIM on Monday, and I'm apparently still unclear on that.) From bobwyman@gmail.com Wed Mar 28 08:00:43 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E498721E82A0 for ; Wed, 28 Mar 2012 08:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.658 X-Spam-Level: X-Spam-Status: No, score=-2.658 tagged_above=-999 required=5 tests=[AWL=0.318, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0YNHky3u1fCK for ; Wed, 28 Mar 2012 08:00:39 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 86FE621E8296 for ; Wed, 28 Mar 2012 08:00:38 -0700 (PDT) Received: by qcsq13 with SMTP id q13so829466qcs.31 for ; Wed, 28 Mar 2012 08:00:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=By61DNv0C33L3zbhTixgu/hQFVbcfgiFTBpFyy/igOE=; b=pCfMWTdlzX21RzF4gmrwjWXNnVqdSNkiteTqbH7MWFi9BqudC2stCWGtndj9//Eiio EwyF+2HJ7BDWjpKUC8cl/0Pg7cwh9s83M653krxIB+tDhQWVyOfWwUMNDaHqlANFYw3H x+3+BQsZlFiKMazE6z8kC3TlXLH4I7uXLpn2xIcAJY1ubdEUDtbNRXFIaMh5A9j6A0ab BO3r+/WRaKqSZZelKFdmgLq8DoY4GOr3b1UclGkrkQgmyZ4MqxOwPHOFaVoFyWxvncGw yqLlxOqFSg3jIIjw2Utzdp4sSLFF/NFgPl8ijhyde+b2QUU6orOgDtgsBws8iviHrVpm 8CSA== MIME-Version: 1.0 Received: by 10.224.31.203 with SMTP id z11mr38943543qac.72.1332946829688; Wed, 28 Mar 2012 08:00:29 -0700 (PDT) Sender: bobwyman@gmail.com Received: by 10.229.157.16 with HTTP; Wed, 28 Mar 2012 08:00:29 -0700 (PDT) In-Reply-To: References: <053201cd0b5d$c08c80f0$41a582d0$@packetizer.com> <20120326150556.GC3557@mail.yitter.info> <20120327084709.GB11491@mail.yitter.info> <00ac01cd0c34$cfc96f10$6f5c4d30$@packetizer.com> <00d201cd0c3a$b3672410$1a356c30$@packetizer.com> Date: Wed, 28 Mar 2012 11:00:29 -0400 X-Google-Sender-Auth: zvn1-T4wS3EpXouyoVEkItJwuMM Message-ID: From: Bob Wyman To: Goix Laurent Walter Content-Type: multipart/alternative; boundary=20cf3074afc249c04f04bc4ede23 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] R: Webfinger discussion X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 28 Mar 2012 15:00:43 -0000 --20cf3074afc249c04f04bc4ede23 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Mar 28, 2012 at 2:55 AM, Goix Laurent Walter < laurentwalter.goix@telecomitalia.it> wrote: > more a protocol for accessing user info rather than discovery Forgive me if I'm being dense, but could you expand a bit on the difference between "accessing user info" and "discovery?" > - regarding OAuth it can be valuable in case webfinger is queried directly by applications. Certainly, OAuth would be useful when combined with WebFinger. I would like to be able to have the equivalent of ACLs that would be used to vary the WebFinger responses based on who authenticates. For instance, in mapping from acct: URI to mailto:, I might want one group of people to receive one mailto: and another group to see a different value or no value. I think we need to also consider that there are alternatives to existing practice of providing "values" directly in the WebFinger XRD/JRDs. An alternative would be to provide pointers to other services that can provide the desired answers. (i.e. Adding yet another level of indirection...) in other words, rather than providing the mailto: address that corresponds to a particular acct: URI, the XRD/JRD could point to a service which uses OAuth and that can be queried to provide whichever of several mailto: addresses that are appropriate -- depending on the results of authentication. bob wyman On Wed, Mar 28, 2012 at 2:55 AM, Goix Laurent Walter < laurentwalter.goix@telecomitalia.it> wrote: > Hello james, all, > > I could see many sort of threads going in parallel in this discussion > addressing different types of concerns. I don't want to enter the > "security" discussion here but rather comment on some specific technical > points related to the "protocol": > > - the "finger" (or lrdd) well-known endpoint could be a shortcut to > consider to directly invoke the webfinger endpoint without the need for t= he > host-meta. This skips one http transaction, although I would imagine in > most cases that the host-meta xrd 1) can be cached by the invoking client= , > 2) can contain additional useful info (eg OExchange endpoint link). > > - I am not sure about the exact value brought by the md5 hash, also > considering that APIs already exist (e.g. OpenSocial) that use plain > identifiers as part of the path. I cannot see much difference here wrt > security that justifies this need for webfinger. In any case support for > md5 hash would probably need to be declared by the server, eg using > {md5uri} instead of {uri} in the lrdd template. > > - regarding the shortcuts to link rel types this is becoming more a > protocol for accessing user info rather than discovery. i can see this as= a > direct/standard API/URL to access user information (e.g. avatar, > profile-page). This misses the "type" (content-type) which may vary withi= n > a single rel (although this could be addressed by Accept: headers) and is > significantly different from the original scope of webfinger for discover= y > only (I could imagine you could further extend your proposal to perform > CRUD operations on the single rels, which tends to become close to > opensocial apis). > The information contained in the xrd/jrd can in fact easily be cached > altogether for subsequent use and not for immediate consumption of all re= l > types. I would assume this is not more complex than parsing the various > Link: headers in the responses. > But i can understand there may be some new use case where a user is only > interested in 1-2 rels for instant consumption, and some solution may be > investigated for this. > > - regarding OAuth it can be valuable in case webfinger is queried directl= y > by applications. However in most current usages (ostatus, diaspora, etc) > the webfinger discovery process is performed by a server of another domai= n, > thus limiting the possible usage of oauth in that case. > > walter > > -----Messaggio originale----- > Da: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] > Per conto di James M Snell > Inviato: marted=EC 27 marzo 2012 20.19 > A: Paul E. Jones > Cc: apps-discuss@ietf.org > Oggetto: Re: [apps-discuss] Webfinger discussion > > They are rather technical in nature and speak to the overall operation > of the protocol. I've written up a detailed version of my feedback > here [1] > > [1] http://chmod777self.blogspot.com/2012/03/thoughts-on-webfinger.html > > The summary version is this: I believe we can make this even simpler > without sacrificing basic operation by saying simply: > > If I want to know about user "bob@example.org", send a GET request to: > http://example.org/.well-known/finger/{md5(acct:bob@example.org)} and > see what I get back. > > The requirement to use XRD/JRD and first look up information about the > LRDD service in host-meta is quite unnecessary. Also note that the ID > is hashed in the request URI for privacy/security purposes... > > We can expand on that basic idea further to say: > > If I want to know if "bob@example.org" has a "blog" and where it is > located, > I could simply send a request to: > > http://example.org/.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/bl= og > > and the server can respond with a redirect to the proper location: > > HTTP/1.1 302 Found > Location: http://blogs.example.org/bob > > The "/blog" portion of the request URI specifies a Link rel... if I > want to discover some other type of service... say, the users profile > or avatar, I simply link the different rel attribute value there.. > e.g. > > > http://example.org/.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/av= atar > > http://example.org/.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/pr= ofile > > If there are multiple links for a particular rel, the server can > respond with a 300 Multiple Options response. > > The point is that requiring XRD/JRD isn't actually necessary, and > requiring the initial host metadata step isn't required also. > > Requiring CORS is also isn't necessary. > > Anyway, that's the basic rundown. > > - James > > On Tue, Mar 27, 2012 at 9:57 AM, Paul E. Jones > wrote: > > James, > > > > If the other items are editorial, perhaps just direct them to me. If > they are items that others might want to weigh in on, then this list is t= he > appropriate venue. > > > > Paul > > > >> -----Original Message----- > >> From: James M Snell [mailto:jasnell@gmail.com] > >> Sent: Tuesday, March 27, 2012 12:39 PM > >> To: Paul E. Jones > >> Cc: Andrew Sullivan; apps-discuss@ietf.org > >> Subject: Re: [apps-discuss] Webfinger discussion > >> > >> To be fair, there are ways of dealing with the potential for security > >> leaks of this nature with WebFinger that did not really exist with the > >> original Finger protocol. OAuth 2, for instance. A WebFinger endpoint > >> could choose to serve up only the most basic static information to > >> unauthenticated requesters, but then provide a means for a requester t= o > >> authenticate and request permission from the target user or provider t= o > >> acquire additional information as part of the response. > >> > >> On a side note to Paul: I did have some additional general comments on > the > >> WebFinger spec itself, I wanted to ask where such comments would be be= st > >> directed for discussion. > >> > >> - James > >> > >> On Tue, Mar 27, 2012 at 9:15 AM, Paul E. Jones > >> wrote: > >> > I agree it would be useful to add text about sharing information tha= t > >> > might be dynamic in nature (e.g., current user location). > >> > > >> > We'll add text along those lines to the next draft. Any other > >> > security considerations we should note? > >> > > >> > Paul > >> > > >> >> -----Original Message----- > >> >> From: apps-discuss-bounces@ietf.org > >> >> [mailto:apps-discuss-bounces@ietf.org] > >> >> On Behalf Of Andrew Sullivan > >> >> Sent: Tuesday, March 27, 2012 4:47 AM > >> >> To: apps-discuss@ietf.org > >> >> Subject: Re: [apps-discuss] Webfinger discussion > >> >> > >> >> On Mon, Mar 26, 2012 at 02:31:30PM -0400, Bob Wyman wrote: > >> >> > >> >> > un-recommended!). If people did, in fact, use WebFinger to record > >> >> > such stuff, the concerns you mentioned would be relevant. Thus, i= t > >> >> > might make sense for the Security Considerations section to sugge= st > >> >> > that one should think carefully before using WebFinger to provide > >> >> > such dynamic > >> >> information. > >> >> > >> >> Right, that's most of what I was trying to say. I do have a concer= n > >> >> that collecting a bunch of different information about a given pers= on > >> >> and linking it together in a single, easy to access repository has > >> >> some potential security side effects (not just privacy ones, but > >> >> those too, of > >> >> course) that are not clearly highlighted in the security > >> considerations. > >> >> I suppose one could argue that facebook's (or pick your poison) use= r > >> >> population shows nobody cares about that, but I think it would stil= l > >> >> be good to have some observations about those effects. > >> >> > >> >> Best, > >> >> > >> >> A > >> >> > >> >> -- > >> >> Andrew Sullivan > >> >> ajs@anvilwalrusden.com > >> >> _______________________________________________ > >> >> apps-discuss mailing list > >> >> apps-discuss@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/apps-discuss > >> > > >> > _______________________________________________ > >> > apps-discuss mailing list > >> > apps-discuss@ietf.org > >> > https://www.ietf.org/mailman/listinfo/apps-discuss > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle > persone indicate. La diffusione, copia o qualsiasi altra azione derivante > dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualo= ra > abbiate ricevuto questo documento per errore siete cortesemente pregati d= i > darne immediata comunicazione al mittente e di provvedere alla sua > distruzione, Grazie. > > This e-mail and any attachments is confidential and may contain privilege= d > information intended for the addressee(s) only. Dissemination, copying, > printing or use by anybody else is unauthorised. If you are not the > intended recipient, please delete this message and any attachments and > advise the sender by return e-mail, Thanks. > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --20cf3074afc249c04f04bc4ede23 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Mar 28, 2012 at 2:55 AM, Goix Laurent Walter=A0&l= t;laurentwalter.goix= @telecomitalia.it>=A0wrote:
>=A0more a prot= ocol for accessing user info rather than discovery
Forgive me if I'm being dense, but could you expand a bit on the differ= ence between "accessing user info" and "discovery?"
>=A0- regarding OAuth it can be valuable in case webfing= er is queried directly by applications.
Certainly, OAuth would be useful when combined with WebFinger. I would= like to be able to have the equivalent of ACLs that would be used to vary = the WebFinger responses based on who authenticates. For instance, in mappin= g from acct: URI to mailto:, I might want one group of people to receive on= e mailto: and another group to see a different value or no value.

I think we need to also consider that there are alterna= tives to existing practice of providing "values" directly in the = WebFinger XRD/JRDs. An alternative would be to provide =A0pointers to other= services that can provide the desired answers. (i.e. Adding yet another le= vel of indirection...) in other words, rather than providing the mailto: ad= dress that corresponds to a particular acct: URI, the XRD/JRD could point t= o a service which uses OAuth and that can be queried to provide whichever o= f several mailto: addresses that are appropriate -- depending on the result= s of authentication.

bob wyman

On Wed, Mar= 28, 2012 at 2:55 AM, Goix Laurent Walter <laurentwalter.goix@telecomitali= a.it> wrote:
Hello james, all,

I could see many sort of threads going in parallel in this discussion addre= ssing different types of concerns. I don't want to enter the "secu= rity" discussion here but rather comment on some specific technical po= ints related to the "protocol":

- the "finger" (or lrdd) well-known endpoint could be a shortcut = to consider to directly invoke the webfinger endpoint without the need for = the host-meta. This skips one http transaction, although I would imagine in= most cases that the host-meta xrd 1) can be cached by the invoking client,= 2) can contain additional useful info (eg OExchange endpoint link).

- I am not sure about the exact value brought by the md5 hash, also conside= ring that APIs already exist (e.g. OpenSocial) that use plain identifiers a= s part of the path. I cannot see much difference here wrt security that jus= tifies this need for webfinger. In any case support for md5 hash would prob= ably need to be declared by the server, eg using {md5uri} instead of {uri} = in the lrdd template.

- regarding the shortcuts to link rel types this is becoming more a protoco= l for accessing user info rather than discovery. i can see this as a direct= /standard API/URL to access user information (e.g. avatar, profile-page). T= his misses the "type" (content-type) which may vary within a sing= le rel (although this could be addressed by Accept: headers) and is signifi= cantly different from the original scope of webfinger for discovery only (I= could imagine you could further extend your proposal to perform CRUD opera= tions on the single rels, which tends to become close to opensocial apis).<= br> The information contained in the xrd/jrd can in fact easily be cached altog= ether for subsequent use and not for immediate consumption of all rel types= . I would assume this is not more complex than parsing the various Link: he= aders in the responses.
But i can understand there may be some new use case where a user is only in= terested in 1-2 rels for instant consumption, and some solution may be inve= stigated for this.

- regarding OAuth it can be valuable in case webfinger is queried directly = by applications. However in most current usages (ostatus, diaspora, etc) th= e webfinger discovery process is performed by a server of another domain, t= hus limiting the possible usage of oauth in that case.

walter

-----Messaggio originale-----
Da: apps-discuss-bounces@i= etf.org [mailto:apps-d= iscuss-bounces@ietf.org] Per conto di James M Snell
Inviato: marted=EC 27 marzo 2012 20.19
A: Paul E. Jones
Cc: apps-discuss@ietf.org
Oggetto: Re: [apps-discuss] Webfinger discussion

They are rather technical in nature and speak to the overall operation
of the protocol. I've written up a detailed version of my feedback
here [1]

[1] http://chmod777self.blogspot.com/2012/03/thought= s-on-webfinger.html

The summary version is this: I believe we can make this even simpler
without sacrificing basic operation by saying simply:

=A0If I want to know about user "b= ob@example.org", send a GET request to:
=A0http://example.org/.well-known/finger/{md5(acct:bo= b@example.org)} and
=A0see what I get back.

The requirement to use XRD/JRD and first look up information about the
LRDD service in host-meta is quite unnecessary. Also note that the ID
is hashed in the request URI for privacy/security purposes...

We can expand on that basic idea further to say:

=A0If I want to know if "bob@examp= le.org" has a "blog" and where it is located,
=A0I could simply send a request to:
=A0http://example.org/.well-known/finger/f4= 9c533fa0f0bc7ee9cc8c88902302ba/blog

=A0and the server can respond with a redirect to the proper location:

=A0HTTP/1.1 302 Found
=A0Location: ht= tp://blogs.example.org/bob

The "/blog" portion of the request URI specifies a Link rel... if= I
want to discover some other type of service... say, the users profile
or avatar, I simply link the different rel attribute value there..
e.g.

=A0http://example.org/.well-known/finger/= f49c533fa0f0bc7ee9cc8c88902302ba/avatar
=A0http://example.org/.well-known/finger= /f49c533fa0f0bc7ee9cc8c88902302ba/profile

If there are multiple links for a particular rel, the server can
respond with a 300 Multiple Options response.

The point is that requiring XRD/JRD isn't actually necessary, and
requiring the initial host metadata step isn't required also.

Requiring CORS is also isn't necessary.

Anyway, that's the basic rundown.

- James

On Tue, Mar 27, 2012 at 9:57 AM, Paul E. Jones <paulej@packetizer.com> wrote:
> James,
>
> If the other items are editorial, perhaps just direct them to me. =A0I= f they are items that others might want to weigh in on, then this list is t= he appropriate venue.
>
> Paul
>
>> -----Original Message-----
>> From: James M Snell [mailto:j= asnell@gmail.com]
>> Sent: Tuesday, March 27, 2012 12:39 PM
>> To: Paul E. Jones
>> Cc: Andrew Sullivan; apps= -discuss@ietf.org
>> Subject: Re: [apps-discuss] Webfinger discussion
>>
>> To be fair, there are ways of dealing with the potential for secur= ity
>> leaks of this nature with WebFinger that did not really exist with= the
>> original Finger protocol. OAuth 2, for instance. A WebFinger endpo= int
>> could choose to serve up only the most basic static information to=
>> unauthenticated requesters, but then provide a means for a request= er to
>> authenticate and request permission from the target user or provid= er to
>> acquire additional information as part of the response.
>>
>> On a side note to Paul: I did have some additional general comment= s on the
>> WebFinger spec itself, I wanted to ask where such comments would b= e best
>> directed for discussion.
>>
>> - James
>>
>> On Tue, Mar 27, 2012 at 9:15 AM, Paul E. Jones <paulej@packetizer.com>
>> wrote:
>> > I agree it would be useful to add text about sharing informat= ion that
>> > might be dynamic in nature (e.g., current user location).
>> >
>> > We'll add text along those lines to the next draft. =A0An= y other
>> > security considerations we should note?
>> >
>> > Paul
>> >
>> >> -----Original Message-----
>> >> From: ap= ps-discuss-bounces@ietf.org
>> >> [mailto:= apps-discuss-bounces@ietf.org]
>> >> On Behalf Of Andrew Sullivan
>> >> Sent: Tuesday, March 27, 2012 4:47 AM
>> >> To: apps-discuss= @ietf.org
>> >> Subject: Re: [apps-discuss] Webfinger discussion
>> >>
>> >> On Mon, Mar 26, 2012 at 02:31:30PM -0400, Bob Wyman wrote= :
>> >>
>> >> > un-recommended!). If people did, in fact, use WebFin= ger to record
>> >> > such stuff, the concerns you mentioned would be rele= vant. Thus, it
>> >> > might make sense for the Security Considerations sec= tion to suggest
>> >> > that one should think carefully before using WebFing= er to provide
>> >> > such dynamic
>> >> information.
>> >>
>> >> Right, that's most of what I was trying to say. =A0I = do have a concern
>> >> that collecting a bunch of different information about a = given person
>> >> and linking it together in a single, easy to access repos= itory has
>> >> some potential security side effects (not just privacy on= es, but
>> >> those too, of
>> >> course) that are not clearly highlighted in the security<= br> >> considerations.
>> >> I suppose one could argue that facebook's (or pick yo= ur poison) user
>> >> population shows nobody cares about that, but I think it = would still
>> >> be good to have some observations about those effects. >> >>
>> >> Best,
>> >>
>> >> A
>> >>
>> >> --
>> >> Andrew Sullivan
>> >> ajs@anvilwalrus= den.com
>> >> _______________________________________________
>> >> apps-discuss mailing list
>> >> apps-discuss@iet= f.org
>> >> https://www.ietf.org/mailman/listinfo/apps-discuss<= /a>
>> >
>> > _______________________________________________
>> > apps-discuss mailing list
>> > apps-discuss@ietf.or= g
>> > https://www.ietf.org/mailman/listinfo/apps-discuss<= br> >
_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

Questo messaggio e i suoi allegati sono indirizzati esclusivame= nte alle persone indicate. La diffusione, copia o qualsiasi altra azione de= rivante dalla conoscenza di queste informazioni sono rigorosamente vietate.= Qualora abbiate ricevuto questo documento per errore siete cortesemente pr= egati di darne immediata comunicazione al mittente e di provvedere alla sua= distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks.

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

--20cf3074afc249c04f04bc4ede23-- From Claudio.Allocchio@garr.it Wed Mar 28 08:12:34 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D158321E82A5; Wed, 28 Mar 2012 08:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EJSSDPqcTbn5; Wed, 28 Mar 2012 08:12:32 -0700 (PDT) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [IPv6:2001:760:0:158::29]) by ietfa.amsl.com (Postfix) with ESMTP id 7450521E8265; Wed, 28 Mar 2012 08:12:31 -0700 (PDT) Received: from mac-allocchio3.elettra.trieste.it (mac-allocchio3.elettra.trieste.it [140.105.2.18]) (authenticated bits=0) by cyrus.dir.garr.it (8.14.5/8.14.5) with ESMTP id q2SFCP31019389 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Mar 2012 17:12:25 +0200 (CEST) X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 cyrus.dir.garr.it q2SFCP31019389 DomainKey-Signature: a=rsa-sha1; s=mail; d=garr.it; c=simple; q=dns; b=c2TS9VWxwzrp3fC7KizpscX1QxYm/a8MVluUicaOS0tYYBGAfrLwVQQjC/rWM8aQw Ieq6YzhbIQBN3/bmlrf2QCWCVeO4VdS3XXinBwdRNi46J0UUO+6nBbdaYYXQ9kkrrLJ +yrqYOtXtSa8/i+WYyXb5afDynPYCjdXOf+jv+c= Date: Wed, 28 Mar 2012 17:12:25 +0200 (CEST) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.elettra.trieste.it To: apps-discuss@ietf.org, draft-melnikov-smtp-priority.all@tools.ietf.org Message-ID: User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: iesg@ietf.org Subject: [apps-discuss] APPSDIR review of draft-melnikov-smtp-priority-09 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 28 Mar 2012 15:12:34 -0000 I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-melnikov-smtp-priority-09 Title: Simple Mail Transfer Protocol extension for Message Transfer Priorities Reviewer: Claudio Allocchio, GARR Review Date: March 28th 2012 IETF Last Call Date: 2012-03-28 IESG Telechat Date: n/a Summary: In its declared scope, this document provides a mechamism (and implementation suggestions) in order to enble a "real" priority delivery service into the global e-mail handling scenario. However, it also introduces a concept idea on how to "tunnel" new SMTP parameters requests via MTAs which do not support and ignore them, embedding them into e-mail Heders fields. In doing this it breaks the ideal separation between Envelope (SMTP) and Content (Headers and bodyparts) in a different a new way than it was done before, because is causes Headers to be able to modify Envelope parameters. There is no negative consideration in this, but this feature should also be stated more explicitly in the introduction. In general the document is well specified, and no major technical issues are present. However I suggest yet another turn of consideraion for the state iself of the specification: the WG and many others propose to go into Standards Track, but in order to do this there are at least some more exlicit considerations to clarify into the text itself. Also, it is not easy to guess what will be the adoption level of this mechanism, and the risk introduced by possible inaccurate implementations shall also be evaluated before going Proposed Standard. Major Issues: The first major issue is non-technical. The e-mail service via SMTP (and gateways and other related transport protocols) is best-effort, often first-in/first-out based. And by itself, e-mail is a non real-time service, like a chat, or text broadcast services: it is delivered into a mailbox where the recipient will read it at his/her will. Although many mail clients now uses a push-like model, delivering messages on "always on" devices, the proposed new service extension aims to provide differentiated service among messages. As correctly stated into the document iself, there is a parallel between this and network transport level services, where packets are prioritised. But also in this case, the proposed mechanism will start to produce benefits only when congestion in some parts of the mail transport system exists. When congestion does not exist, the mechanisms will not result in better service. This is not a drawback, but it should be stated more explicitly in the document. Maybe expanding it into the 5.4 section, where comparison with RFC2474 and RFC2205 are done. The other major issue to consider is the global trust model which is needed to implement the mechanisms. There are suggestions in the specification on how to enhance security when tunnelling across non supprting MTAs, for example, but in the document there are also other suggestions which consider the extension applicable easily only within restricted trusted communities. This apparently contradictory point shall be explained better. If this specification is going Proposed Standard, it shall be crystal clear about these scenarios, because implementers who did not take part in the original discussion will implement it, and thus all pre-assupmtions made during the discussion process of the specification discussion will not be available for them. Minor Issues: There is no discussion (explicit) about how this specification interacts/interferes with anti-spam techniques like graylisting / whitelisting. Section 5.1 suggests that shorter retry times shall be used for higher priority messages, but it does not mention at all graylisting, for example. This should be explicitly mentioned, and some guidance / suggestion given, to ensure a coherent behaviour. The sentence in section 2 "The most important reason for emails to be delayed is a transient error response from the next MTA to which the email must be transferred." should also explicitly refer to the graylisting case (which also causes often a "reply" message to be delivered before the original message is). Section 4.2: why allowing an X-something like X-Priority to be used? I understand why not "Importance" and why yes "Priority"... but... Maybe this specification should "update" or even attempt to Obsolete partially RFC2156? Section 4.5: the text say that in case of mailing lists and aliases the Header parameters tunnelling this specification extension SHOULD retain the original priority. What about the many implementations where headers are completely re-written and many parameters just disappear? Some sentence should be given aout this case, too. Section 4.6... not all "non e-mail" environment allow addition of an "header field"... how do we handle this? Section 9: given the current architecture, I'm very worried this will ALWAYS happen (different behaviours because different support at various MX-pointed servers). I'd make the consideration more explicit and suggest a stronger guidance. Appendix A, B, C are very environment specific. Appendix A and C, however, seem very specific environment related (the NATO messaging military convetions for "A" and the USA Civil Protecion service for "C"). While "B" is really global, beacause it maps OSI X.400 service, the other two appendix seems too environment specific for an international standard RFC specification. I would suggest handling at least "A' and "C" not as appendixes of this document, but as separate short "mapping specification", also to enable further similar documents to be published/registered more easily for other environments. Nits: none. Best Regards! ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca From laurentwalter.goix@telecomitalia.it Wed Mar 28 08:17:33 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF52321F86B7 for ; Wed, 28 Mar 2012 08:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.692 X-Spam-Level: X-Spam-Status: No, score=-0.692 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id skN8X8c19I33 for ; Wed, 28 Mar 2012 08:17:27 -0700 (PDT) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by ietfa.amsl.com (Postfix) with ESMTP id 6B04421F8679 for ; Wed, 28 Mar 2012 08:17:22 -0700 (PDT) Received: from GRFHUB702BA020.griffon.local (10.188.101.112) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 28 Mar 2012 17:17:11 +0200 Received: from GRFMBX704BA020.griffon.local ([10.188.101.16]) by GRFHUB702BA020.griffon.local ([10.188.101.112]) with mapi; Wed, 28 Mar 2012 17:17:11 +0200 From: Goix Laurent Walter To: Bob Wyman Date: Wed, 28 Mar 2012 17:17:08 +0200 Thread-Topic: [apps-discuss] R: Webfinger discussion Thread-Index: Ac0M85f7MflCRbJJQF+bokCdiPsR9AAAImCw Message-ID: References: <053201cd0b5d$c08c80f0$41a582d0$@packetizer.com> <20120326150556.GC3557@mail.yitter.info> <20120327084709.GB11491@mail.yitter.info> <00ac01cd0c34$cfc96f10$6f5c4d30$@packetizer.com> <00d201cd0c3a$b3672410$1a356c30$@packetizer.com> In-Reply-To: Accept-Language: en-US, it-IT Content-Language: it-IT X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US, it-IT x-ti-disclaimer: Disclaimer1 Content-Type: multipart/related; boundary="_004_A09A9E0A4B9C654E8672D1DC003633AE52EDC5253EGRFMBX704BA02_"; type="multipart/alternative" MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" Subject: [apps-discuss] R: R: Webfinger discussion X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 28 Mar 2012 15:17:33 -0000 --_004_A09A9E0A4B9C654E8672D1DC003633AE52EDC5253EGRFMBX704BA02_ Content-Type: multipart/alternative; boundary="_000_A09A9E0A4B9C654E8672D1DC003633AE52EDC5253EGRFMBX704BA02_" --_000_A09A9E0A4B9C654E8672D1DC003633AE52EDC5253EGRFMBX704BA02_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Wed, Mar 28, 2012 at 2:55 AM, Goix Laurent Walter > wrote: > more a protocol for accessing user info rather than discovery Forgive me if I'm being dense, but could you expand a bit on the difference= between "accessing user info" and "discovery?" [walter] by "accessing user info" I mean directly accessing actual informat= ion about a user (my profile details, activity stream, etc). what I mean by= "discovery" is to retrieve a pointer to a specific information. Webfinger = is aimed at becoming a discovery protocol. There are plenty of other protoc= ol/apis/interfaces for accessing information that could be "discovered" thr= ough webfinger and then use very different/specific communications means. I= hope I clarified my point here. > - regarding OAuth it can be valuable in case webfinger is queried directl= y by applications. Certainly, OAuth would be useful when combined with WebFinger. I would like= to be able to have the equivalent of ACLs that would be used to vary the W= ebFinger responses based on who authenticates. For instance, in mapping fro= m acct: URI to mailto:, I might want one group of people to receive one mai= lto: and another group to see a different value or no value. I think we need to also consider that there are alternatives to existing pr= actice of providing "values" directly in the WebFinger XRD/JRDs. An alterna= tive would be to provide pointers to other services that can provide the d= esired answers. (i.e. Adding yet another level of indirection...) in other = words, rather than providing the mailto: address that corresponds to a part= icular acct: URI, the XRD/JRD could point to a service which uses OAuth and= that can be queried to provide whichever of several mailto: addresses that= are appropriate -- depending on the results of authentication. [walter] i have not seen webfinger usages where "values" are directly provi= ded and would be very careful with it (I would be glad to see if there are = already such usages deployed). Imho the entire purpose of webfinger is to d= iscover "pointers" to information, not the information itself. This allows = any security mechanism to be applied on those specific endpoints (+ on webf= inger endpoint itself) to control access to the actual information (profile= , activities, etc). Again, oauth could work for users/invocations within a single social networ= k/domain, but I could hardly imagine it working for server-to-server transa= ctions (eg a user from one SN acts on his server's webpage to follow a user= on another SN). Or do you have other scenarios in mind with oauth? The only direct information I could easily imagine in a xrd is another "acc= t" uri in case of portability. Other personal uris (eg im:, mailto:, etc) s= hould be handled with care and imo not included in the xrd but rather in a = profile description (hcard, foaf, etc), whose link is provided in the xrd (= so that a more precise acl can be applied when someone wants to access it) walter bob wyman On Wed, Mar 28, 2012 at 2:55 AM, Goix Laurent Walter > wrote: Hello james, all, I could see many sort of threads going in parallel in this discussion addre= ssing different types of concerns. I don't want to enter the "security" dis= cussion here but rather comment on some specific technical points related t= o the "protocol": - the "finger" (or lrdd) well-known endpoint could be a shortcut to conside= r to directly invoke the webfinger endpoint without the need for the host-m= eta. This skips one http transaction, although I would imagine in most case= s that the host-meta xrd 1) can be cached by the invoking client, 2) can co= ntain additional useful info (eg OExchange endpoint link). - I am not sure about the exact value brought by the md5 hash, also conside= ring that APIs already exist (e.g. OpenSocial) that use plain identifiers a= s part of the path. I cannot see much difference here wrt security that jus= tifies this need for webfinger. In any case support for md5 hash would prob= ably need to be declared by the server, eg using {md5uri} instead of {uri} = in the lrdd template. - regarding the shortcuts to link rel types this is becoming more a protoco= l for accessing user info rather than discovery. i can see this as a direct= /standard API/URL to access user information (e.g. avatar, profile-page). T= his misses the "type" (content-type) which may vary within a single rel (al= though this could be addressed by Accept: headers) and is significantly dif= ferent from the original scope of webfinger for discovery only (I could ima= gine you could further extend your proposal to perform CRUD operations on t= he single rels, which tends to become close to opensocial apis). The information contained in the xrd/jrd can in fact easily be cached altog= ether for subsequent use and not for immediate consumption of all rel types= . I would assume this is not more complex than parsing the various Link: he= aders in the responses. But i can understand there may be some new use case where a user is only in= terested in 1-2 rels for instant consumption, and some solution may be inve= stigated for this. - regarding OAuth it can be valuable in case webfinger is queried directly = by applications. However in most current usages (ostatus, diaspora, etc) th= e webfinger discovery process is performed by a server of another domain, t= hus limiting the possible usage of oauth in that case. walter -----Messaggio originale----- Da: apps-discuss-bounces@ietf.org [ma= ilto:apps-discuss-bounces@ietf.org] P= er conto di James M Snell Inviato: marted=EC 27 marzo 2012 20.19 A: Paul E. Jones Cc: apps-discuss@ietf.org Oggetto: Re: [apps-discuss] Webfinger discussion They are rather technical in nature and speak to the overall operation of the protocol. I've written up a detailed version of my feedback here [1] [1] http://chmod777self.blogspot.com/2012/03/thoughts-on-webfinger.html The summary version is this: I believe we can make this even simpler without sacrificing basic operation by saying simply: If I want to know about user "bob@example.org", se= nd a GET request to: http://example.org/.well-known/finger/{md5(acct:bob@example.org)} and see what I get back. The requirement to use XRD/JRD and first look up information about the LRDD service in host-meta is quite unnecessary. Also note that the ID is hashed in the request URI for privacy/security purposes... We can expand on that basic idea further to say: If I want to know if "bob@example.org" has a "blog= " and where it is located, I could simply send a request to: http://example.org/.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/blo= g and the server can respond with a redirect to the proper location: HTTP/1.1 302 Found Location: http://blogs.example.org/bob The "/blog" portion of the request URI specifies a Link rel... if I want to discover some other type of service... say, the users profile or avatar, I simply link the different rel attribute value there.. e.g. http://example.org/.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/ava= tar http://example.org/.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/pro= file If there are multiple links for a particular rel, the server can respond with a 300 Multiple Options response. The point is that requiring XRD/JRD isn't actually necessary, and requiring the initial host metadata step isn't required also. Requiring CORS is also isn't necessary. Anyway, that's the basic rundown. - James On Tue, Mar 27, 2012 at 9:57 AM, Paul E. Jones > wrote: > James, > > If the other items are editorial, perhaps just direct them to me. If the= y are items that others might want to weigh in on, then this list is the ap= propriate venue. > > Paul > >> -----Original Message----- >> From: James M Snell [mailto:jasnell@gmail.com] >> Sent: Tuesday, March 27, 2012 12:39 PM >> To: Paul E. Jones >> Cc: Andrew Sullivan; apps-discuss@ietf.org >> Subject: Re: [apps-discuss] Webfinger discussion >> >> To be fair, there are ways of dealing with the potential for security >> leaks of this nature with WebFinger that did not really exist with the >> original Finger protocol. OAuth 2, for instance. A WebFinger endpoint >> could choose to serve up only the most basic static information to >> unauthenticated requesters, but then provide a means for a requester to >> authenticate and request permission from the target user or provider to >> acquire additional information as part of the response. >> >> On a side note to Paul: I did have some additional general comments on t= he >> WebFinger spec itself, I wanted to ask where such comments would be best >> directed for discussion. >> >> - James >> >> On Tue, Mar 27, 2012 at 9:15 AM, Paul E. Jones > >> wrote: >> > I agree it would be useful to add text about sharing information that >> > might be dynamic in nature (e.g., current user location). >> > >> > We'll add text along those lines to the next draft. Any other >> > security considerations we should note? >> > >> > Paul >> > >> >> -----Original Message----- >> >> From: apps-discuss-bounces@ietf.org >> >> [mailto:apps-discuss-bounces@ietf.org] >> >> On Behalf Of Andrew Sullivan >> >> Sent: Tuesday, March 27, 2012 4:47 AM >> >> To: apps-discuss@ietf.org >> >> Subject: Re: [apps-discuss] Webfinger discussion >> >> >> >> On Mon, Mar 26, 2012 at 02:31:30PM -0400, Bob Wyman wrote: >> >> >> >> > un-recommended!). If people did, in fact, use WebFinger to record >> >> > such stuff, the concerns you mentioned would be relevant. Thus, it >> >> > might make sense for the Security Considerations section to suggest >> >> > that one should think carefully before using WebFinger to provide >> >> > such dynamic >> >> information. >> >> >> >> Right, that's most of what I was trying to say. I do have a concern >> >> that collecting a bunch of different information about a given person >> >> and linking it together in a single, easy to access repository has >> >> some potential security side effects (not just privacy ones, but >> >> those too, of >> >> course) that are not clearly highlighted in the security >> considerations. >> >> I suppose one could argue that facebook's (or pick your poison) user >> >> population shows nobody cares about that, but I think it would still >> >> be good to have some observations about those effects. >> >> >> >> Best, >> >> >> >> A >> >> >> >> -- >> >> Andrew Sullivan >> >> ajs@anvilwalrusden.com >> >> _______________________________________________ >> >> apps-discuss mailing list >> >> apps-discuss@ietf.org >> >> https://www.ietf.org/mailman/listinfo/apps-discuss >> > >> > _______________________________________________ >> > apps-discuss mailing list >> > apps-discuss@ietf.org >> > https://www.ietf.org/mailman/listinfo/apps-discuss > _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. [cid:00000000000000000000000000000003@TI.Disclaimer]Rispetta l'ambiente. No= n stampare questa mail se non =E8 necessario. --_000_A09A9E0A4B9C654E8672D1DC003633AE52EDC5253EGRFMBX704BA02_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

On Wed, Mar 28, 2012 at 2:55 AM= , Goix Laurent Walter <laurentwalter.goix@telecomitalia.it<= /span>> wrote:
> more a protocol for accessing user info rather than discovery
Forgive me if I'm being dense, but could you expand a bit on the difference= between "accessing user info" and "discovery?"

 

[walter] by "accessing user info” I mean directly= accessing actual information about a user (my profile details, activity st= ream, etc). what I mean by “discovery” is to retrieve a pointer to a specific i= nformation. Webfinger is aimed at becoming a discovery protocol. There are = plenty of other protocol/apis/interfaces for accessing information that cou= ld be “discovered” through webfinger and then use very different/specific communications means. I hope I clarified my po= int here.

 

> - regarding OAuth it can be valuable in ca= se webfinger is queried directly by applications.

Certainly, OAuth would be useful when combined with = WebFinger. I would like to be able to have the equivalent of ACLs that woul= d be used to vary the WebFinger responses based on who authenticates. For i= nstance, in mapping from acct: URI to mailto:, I might want one group of people to receive one mailto: and an= other group to see a different value or no value.

 

I think we need to also consider that there are alte= rnatives to existing practice of providing "values" directly in t= he WebFinger XRD/JRDs. An alternative would be to provide  pointers to= other services that can provide the desired answers. (i.e. Adding yet another level of indirection...) in other words, rather t= han providing the mailto: address that corresponds to a particular acct: UR= I, the XRD/JRD could point to a service which uses OAuth and that can be qu= eried to provide whichever of several mailto: addresses that are appropriate -- depending on the results of auth= entication.

 

[walter] i have not seen webfinger usages where “value= s” are directly provided and would be very careful with it (I would b= e glad to see if there are already such usages deployed). Imho the entire purpose of webfinger is= to discover “pointers” to information, not the information its= elf. This allows any security mechanism to be applied on those specific end= points (+ on webfinger endpoint itself) to control access to the actual information (profile, activities, etc).

Again, oauth could work for users/invocations within a singl= e social network/domain, but I could hardly imagine it working for server-t= o-server transactions (eg a user from one SN acts on his server’s webpage to = follow a user on another SN). Or do you have other scenarios in mind with o= auth?

The only direct information I could easily imagine in a xrd = is another “acct” uri in case of portability. Other personal ur= is (eg im:, mailto:, etc) should be handled with care and imo not included in the xrd but rathe= r in a profile description (hcard, foaf, etc), whose link is provided in th= e xrd (so that a more precise acl can be applied when someone wants to acce= ss it)

 

walter

 

bob wyman<= /p>

On Wed, Mar 28, 2012 at 2:55 AM, Goix Laurent Walter= <laurentwalter.g= oix@telecomitalia.it> wrote:

Hello james, all,

I could see many sort of threads going in parallel in this discussion addre= ssing different types of concerns. I don't want to enter the "security= " discussion here but rather comment on some specific technical points= related to the "protocol":

- the "finger" (or lrdd) well-known endpoint could be a shortcut = to consider to directly invoke the webfinger endpoint without the need for = the host-meta. This skips one http transaction, although I would imagine in= most cases that the host-meta xrd 1) can be cached by the invoking client, 2) can contain additional useful info (e= g OExchange endpoint link).

- I am not sure about the exact value brought by the md5 hash, also conside= ring that APIs already exist (e.g. OpenSocial) that use plain identifiers a= s part of the path. I cannot see much difference here wrt security that jus= tifies this need for webfinger. In any case support for md5 hash would probably need to be declared by the= server, eg using {md5uri} instead of {uri} in the lrdd template.

- regarding the shortcuts to link rel types this is becoming more a protoco= l for accessing user info rather than discovery. i can see this as a direct= /standard API/URL to access user information (e.g. avatar, profile-page). T= his misses the "type" (content-type) which may vary within a single rel (although this could be addressed by Ac= cept: headers) and is significantly different from the original scope of we= bfinger for discovery only (I could imagine you could further extend your p= roposal to perform CRUD operations on the single rels, which tends to become close to opensocial apis).
The information contained in the xrd/jrd can in fact easily be cached altog= ether for subsequent use and not for immediate consumption of all rel types= . I would assume this is not more complex than parsing the various Link: he= aders in the responses.
But i can understand there may be some new use case where a user is only in= terested in 1-2 rels for instant consumption, and some solution may be inve= stigated for this.

- regarding OAuth it can be valuable in case webfinger is queried directly = by applications. However in most current usages (ostatus, diaspora, etc) th= e webfinger discovery process is performed by a server of another domain, t= hus limiting the possible usage of oauth in that case.

walter

-----Messaggio originale-----
Da: apps-discuss-bounces@i= etf.org [mailto:apps-d= iscuss-bounces@ietf.org] Per conto di James M Snell
Inviato: marted=EC 27 marzo 2012 20.19

A: Paul E. Jones
Cc: apps-discuss@ietf.org=

Oggetto: Re: [apps-discuss] Webfinger discussion


They are rather technical in nature and speak to the overall operation
of the protocol. I've written up a detailed version of my feedback
here [1]

[1] http://chmod777self.blogspot.com/2012/03/thoughts-on-webfinger.html

The summary version is this: I believe we can make this even simpler
without sacrificing basic operation by saying simply:

 If I want to know about user "bob@example.org", send a GET request to:
 http://example.org/.well-known/finger/{md5(a= cct:bob@example.org)} and
 see what I get back.

The requirement to use XRD/JRD and first look up information about the
LRDD service in host-meta is quite unnecessary. Also note that the ID
is hashed in the request URI for privacy/security purposes...

We can expand on that basic idea further to say:

 If I want to know if "bob@exa= mple.org" has a "blog" and where it is located,
 I could simply send a request to:
 http://example.org/.well-known/finger/= f49c533fa0f0bc7ee9cc8c88902302ba/blog

 and the server can respond with a redirect to the proper location:
 HTTP/1.1 302 Found
 Location: = http://blogs.example.org/bob

The "/blog" portion of the request URI specifies a Link rel... if= I
want to discover some other type of service... say, the users profile
or avatar, I simply link the different rel attribute value there..
e.g.

 http://example.org/.well-known/finge= r/f49c533fa0f0bc7ee9cc8c88902302ba/avatar
 http://example.org/.well-known/fing= er/f49c533fa0f0bc7ee9cc8c88902302ba/profile

If there are multiple links for a particular rel, the server can
respond with a 300 Multiple Options response.

The point is that requiring XRD/JRD isn't actually necessary, and
requiring the initial host metadata step isn't required also.

Requiring CORS is also isn't necessary.

Anyway, that's the basic rundown.

- James

On Tue, Mar 27, 2012 at 9:57 AM, Paul E. Jones <paulej@packetizer.com> wrote:
> James,
>
> If the other items are editorial, perhaps just direct them to me. &nbs= p;If they are items that others might want to weigh in on, then this list i= s the appropriate venue.
>
> Paul
>
>> -----Original Message-----
>> From: James M Snell [mailto:j= asnell@gmail.com]
>> Sent: Tuesday, March 27, 2012 12:39 PM
>> To: Paul E. Jones
>> Cc: Andrew Sullivan; apps= -discuss@ietf.org
>> Subject: Re: [apps-discuss] Webfinger discussion
>>
>> To be fair, there are ways of dealing with the potential for secur= ity
>> leaks of this nature with WebFinger that did not really exist with= the
>> original Finger protocol. OAuth 2, for instance. A WebFinger endpo= int
>> could choose to serve up only the most basic static information to=
>> unauthenticated requesters, but then provide a means for a request= er to
>> authenticate and request permission from the target user or provid= er to
>> acquire additional information as part of the response.
>>
>> On a side note to Paul: I did have some additional general comment= s on the
>> WebFinger spec itself, I wanted to ask where such comments would b= e best
>> directed for discussion.
>>
>> - James
>>
>> On Tue, Mar 27, 2012 at 9:15 AM, Paul E. Jones <paulej@packetizer.com>
>> wrote:
>> > I agree it would be useful to add text about sharing informat= ion that
>> > might be dynamic in nature (e.g., current user location).
>> >
>> > We'll add text along those lines to the next draft.  Any= other
>> > security considerations we should note?
>> >
>> > Paul
>> >
>> >> -----Original Message-----
>> >> From: ap= ps-discuss-bounces@ietf.org
>> >> [mailto:= apps-discuss-bounces@ietf.org]
>> >> On Behalf Of Andrew Sullivan
>> >> Sent: Tuesday, March 27, 2012 4:47 AM
>> >> To: apps-discuss= @ietf.org
>> >> Subject: Re: [apps-discuss] Webfinger discussion
>> >>
>> >> On Mon, Mar 26, 2012 at 02:31:30PM -0400, Bob Wyman wrote= :
>> >>
>> >> > un-recommended!). If people did, in fact, use WebFin= ger to record
>> >> > such stuff, the concerns you mentioned would be rele= vant. Thus, it
>> >> > might make sense for the Security Considerations sec= tion to suggest
>> >> > that one should think carefully before using WebFing= er to provide
>> >> > such dynamic
>> >> information.
>> >>
>> >> Right, that's most of what I was trying to say.  I d= o have a concern
>> >> that collecting a bunch of different information about a = given person
>> >> and linking it together in a single, easy to access repos= itory has
>> >> some potential security side effects (not just privacy on= es, but
>> >> those too, of
>> >> course) that are not clearly highlighted in the security<= br> >> considerations.
>> >> I suppose one could argue that facebook's (or pick your p= oison) user
>> >> population shows nobody cares about that, but I think it = would still
>> >> be good to have some observations about those effects. >> >>
>> >> Best,
>> >>
>> >> A
>> >>
>> >> --
>> >> Andrew Sullivan
>> >> ajs@anvilwalrus= den.com
>> >> _______________________________________________
>> >> apps-discuss mailing list
>> >> apps-discuss@iet= f.org
>> >> https://www.ietf.org/mailman/listinfo/apps-discuss
>> >
>> > _______________________________________________
>> > apps-discuss mailing list
>> > apps-discuss@ietf.or= g
>> > https://www.ietf.org/mailman/listinfo/apps-discuss
>
_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

Questo messaggio e i suoi allegati sono indirizzati = esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altr= a azione derivante dalla conoscenza di queste informazioni sono rigorosamen= te vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata = comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.


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

 

= Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigoro= samente vietate. Qualora abbiate ricevuto questo documento per errore siete= cortesemente pregati di darne immediata comunicazione al mittente e di pro= vvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only.= Dissemination, copying, printing or use by anybody else is unauthorised. I= f you are not the intended recipient, please delete this message and any at= tachments and advise the sender by return e-mail, Thanks.

3D"rispettaRispetta= l'ambiente. Non stampare questa mail se non =E8 necessario.

--_000_A09A9E0A4B9C654E8672D1DC003633AE52EDC5253EGRFMBX704BA02_-- --_004_A09A9E0A4B9C654E8672D1DC003633AE52EDC5253EGRFMBX704BA02_ Content-Type: image/jpeg; name="logo Ambiente_foglia2.jpg" Content-Description: logo Ambiente_foglia2.jpg Content-Disposition: inline; filename="logo Ambiente_foglia2.jpg"; size=677; creation-date="Wed, 28 Mar 2012 17:17:11 GMT"; modification-date="Wed, 28 Mar 2012 17:17:11 GMT" Content-ID: <00000000000000000000000000000003@TI.Disclaimer> Content-Transfer-Encoding: base64 R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= --_004_A09A9E0A4B9C654E8672D1DC003633AE52EDC5253EGRFMBX704BA02_-- From bobwyman@gmail.com Wed Mar 28 11:06:37 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D68A521E819B for ; Wed, 28 Mar 2012 11:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.694 X-Spam-Level: X-Spam-Status: No, score=-2.694 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5K10wNf42vH for ; Wed, 28 Mar 2012 11:06:35 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 644E021E81C2 for ; Wed, 28 Mar 2012 11:06:35 -0700 (PDT) Received: by qaea16 with SMTP id a16so991157qae.10 for ; Wed, 28 Mar 2012 11:06:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=hNyAp3qWrZbXiTRYWsGd/UZdDeseCtFwMiSxV2r4LLY=; b=q/YY4Ld8RqeKR3Wut7gzQGdtDZlTSIF9M/YhbvyfpI+EQW+IKvRonUby1vZqsZgiGT r1AQJ4rFTohCGF8zt5ejIBobrsxiMkyogQc5lyvE2LLUV1fkjC0Rvud8jqEfxXw2nZqG 9XcYeeJLkAIbtpUDplBCfgOIhrUk2HN/8NN3jdIn2NH34TBsrae/HPnXcGCOWiat4ffN VVuJ/nfya4xYCfqNUE6J8s1TOFF/ZSfZzVmYANqj5RcNktBV9YsXJCMBanWZytwXbg8L R2ZJLlX2c8dNhx6L6miINVi0beeHdOmoOCd6smW2KodH4CNXQ7YsxZh9T4rVvzzQndXF sLcA== MIME-Version: 1.0 Received: by 10.224.210.129 with SMTP id gk1mr39187486qab.85.1332957994659; Wed, 28 Mar 2012 11:06:34 -0700 (PDT) Sender: bobwyman@gmail.com Received: by 10.229.157.16 with HTTP; Wed, 28 Mar 2012 11:06:34 -0700 (PDT) In-Reply-To: References: <053201cd0b5d$c08c80f0$41a582d0$@packetizer.com> <20120326150556.GC3557@mail.yitter.info> <20120327084709.GB11491@mail.yitter.info> <00ac01cd0c34$cfc96f10$6f5c4d30$@packetizer.com> <00d201cd0c3a$b3672410$1a356c30$@packetizer.com> Date: Wed, 28 Mar 2012 14:06:34 -0400 X-Google-Sender-Auth: cbhADbm3H3VYLH2Lc5nXeuglBtE Message-ID: From: Bob Wyman To: Goix Laurent Walter Content-Type: multipart/related; boundary=20cf300faca1c5af2304bc517712 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] R: Webfinger discussion X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 28 Mar 2012 18:06:38 -0000 --20cf300faca1c5af2304bc517712 Content-Type: multipart/alternative; boundary=20cf300faca1c5af2104bc517711 --20cf300faca1c5af2104bc517711 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Wed, Mar 28, 2012 at 11:17 AM, Goix Laurent Walter < laurentwalter.goix@telecomitalia.it> wrote: > > i have not seen webfinger usages where =93values=94 are directly provid= ed What is a "pointer" for you may be a "value" for me. Consider the case where the URL of my blog is identified. Is that a pointer, a value or both at the same time? It seems to me that in these cases, the distinction between "pointer" and "value" is not inherent to the data provided but rather is found in how the data is used. bob wyman On Wed, Mar 28, 2012 at 11:17 AM, Goix Laurent Walter < laurentwalter.goix@telecomitalia.it> wrote: > On Wed, Mar 28, 2012 at 2:55 AM, Goix Laurent Walter < > laurentwalter.goix@telecomitalia.it> wrote: > > more a protocol for accessing user info rather than discovery > Forgive me if I'm being dense, but could you expand a bit on the > difference between "accessing user info" and "discovery?"**** > > ** ** > > [walter] by "accessing user info=94 I mean directly accessing actual > information about a user (my profile details, activity stream, etc). what= I > mean by =93discovery=94 is to retrieve a pointer to a specific informatio= n. > Webfinger is aimed at becoming a discovery protocol. There are plenty of > other protocol/apis/interfaces for accessing information that could be > =93discovered=94 through webfinger and then use very different/specific > communications means. I hope I clarified my point here.**** > > ** ** > > > - regarding OAuth it can be valuable in case webfinger is queried > directly by applications.**** > > Certainly, OAuth would be useful when combined with WebFinger. I would > like to be able to have the equivalent of ACLs that would be used to vary > the WebFinger responses based on who authenticates. For instance, in > mapping from acct: URI to mailto:, I might want one group of people to > receive one mailto: and another group to see a different value or no > value.**** > > ** ** > > I think we need to also consider that there are alternatives to existing > practice of providing "values" directly in the WebFinger XRD/JRDs. An > alternative would be to provide pointers to other services that can > provide the desired answers. (i.e. Adding yet another level of > indirection...) in other words, rather than providing the mailto: address > that corresponds to a particular acct: URI, the XRD/JRD could point to a > service which uses OAuth and that can be queried to provide whichever of > several mailto: addresses that are appropriate -- depending on the > results of authentication.**** > > ** ** > > [walter] i have not seen webfinger usages where =93values=94 are directly > provided and would be very careful with it (I would be glad to see if the= re > are already such usages deployed). Imho the entire purpose of webfinger i= s > to discover =93pointers=94 to information, not the information itself. Th= is > allows any security mechanism to be applied on those specific endpoints (= + > on webfinger endpoint itself) to control access to the actual information > (profile, activities, etc). **** > > Again, oauth could work for users/invocations within a single social > network/domain, but I could hardly imagine it working for server-to-serve= r > transactions (eg a user from one SN acts on his server=92s webpage to fol= low > a user on another SN). Or do you have other scenarios in mind with oauth?= * > *** > > The only direct information I could easily imagine in a xrd is another > =93acct=94 uri in case of portability. Other personal uris (eg im:, mailt= o:, > etc) should be handled with care and imo not included in the xrd but rath= er > in a profile description (hcard, foaf, etc), whose link is provided in th= e > xrd (so that a more precise acl can be applied when someone wants to acce= ss > it)**** > > ** ** > > walter**** > > ** ** > > bob wyman**** > > On Wed, Mar 28, 2012 at 2:55 AM, Goix Laurent Walter < > laurentwalter.goix@telecomitalia.it> wrote:**** > > Hello james, all, > > I could see many sort of threads going in parallel in this discussion > addressing different types of concerns. I don't want to enter the > "security" discussion here but rather comment on some specific technical > points related to the "protocol": > > - the "finger" (or lrdd) well-known endpoint could be a shortcut to > consider to directly invoke the webfinger endpoint without the need for t= he > host-meta. This skips one http transaction, although I would imagine in > most cases that the host-meta xrd 1) can be cached by the invoking client= , > 2) can contain additional useful info (eg OExchange endpoint link). > > - I am not sure about the exact value brought by the md5 hash, also > considering that APIs already exist (e.g. OpenSocial) that use plain > identifiers as part of the path. I cannot see much difference here wrt > security that justifies this need for webfinger. In any case support for > md5 hash would probably need to be declared by the server, eg using > {md5uri} instead of {uri} in the lrdd template. > > - regarding the shortcuts to link rel types this is becoming more a > protocol for accessing user info rather than discovery. i can see this as= a > direct/standard API/URL to access user information (e.g. avatar, > profile-page). This misses the "type" (content-type) which may vary withi= n > a single rel (although this could be addressed by Accept: headers) and is > significantly different from the original scope of webfinger for discover= y > only (I could imagine you could further extend your proposal to perform > CRUD operations on the single rels, which tends to become close to > opensocial apis). > The information contained in the xrd/jrd can in fact easily be cached > altogether for subsequent use and not for immediate consumption of all re= l > types. I would assume this is not more complex than parsing the various > Link: headers in the responses. > But i can understand there may be some new use case where a user is only > interested in 1-2 rels for instant consumption, and some solution may be > investigated for this. > > - regarding OAuth it can be valuable in case webfinger is queried directl= y > by applications. However in most current usages (ostatus, diaspora, etc) > the webfinger discovery process is performed by a server of another domai= n, > thus limiting the possible usage of oauth in that case. > > walter > > -----Messaggio originale----- > Da: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] > Per conto di James M Snell > Inviato: marted=EC 27 marzo 2012 20.19**** > > A: Paul E. Jones > Cc: apps-discuss@ietf.org**** > > Oggetto: Re: [apps-discuss] Webfinger discussion**** > > > They are rather technical in nature and speak to the overall operation > of the protocol. I've written up a detailed version of my feedback > here [1] > > [1] http://chmod777self.blogspot.com/2012/03/thoughts-on-webfinger.html > > The summary version is this: I believe we can make this even simpler > without sacrificing basic operation by saying simply: > > If I want to know about user "bob@example.org", send a GET request to: > http://example.org/.well-known/finger/{md5(acct:bob@example.org)} and > see what I get back. > > The requirement to use XRD/JRD and first look up information about the > LRDD service in host-meta is quite unnecessary. Also note that the ID > is hashed in the request URI for privacy/security purposes... > > We can expand on that basic idea further to say: > > If I want to know if "bob@example.org" has a "blog" and where it is > located, > I could simply send a request to: > > http://example.org/.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/bl= og > > and the server can respond with a redirect to the proper location: > > HTTP/1.1 302 Found > Location: http://blogs.example.org/bob > > The "/blog" portion of the request URI specifies a Link rel... if I > want to discover some other type of service... say, the users profile > or avatar, I simply link the different rel attribute value there.. > e.g. > > > http://example.org/.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/av= atar > > http://example.org/.well-known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/pr= ofile > > If there are multiple links for a particular rel, the server can > respond with a 300 Multiple Options response. > > The point is that requiring XRD/JRD isn't actually necessary, and > requiring the initial host metadata step isn't required also. > > Requiring CORS is also isn't necessary. > > Anyway, that's the basic rundown. > > - James > > On Tue, Mar 27, 2012 at 9:57 AM, Paul E. Jones > wrote: > > James, > > > > If the other items are editorial, perhaps just direct them to me. If > they are items that others might want to weigh in on, then this list is t= he > appropriate venue. > > > > Paul > > > >> -----Original Message----- > >> From: James M Snell [mailto:jasnell@gmail.com] > >> Sent: Tuesday, March 27, 2012 12:39 PM > >> To: Paul E. Jones > >> Cc: Andrew Sullivan; apps-discuss@ietf.org > >> Subject: Re: [apps-discuss] Webfinger discussion > >> > >> To be fair, there are ways of dealing with the potential for security > >> leaks of this nature with WebFinger that did not really exist with the > >> original Finger protocol. OAuth 2, for instance. A WebFinger endpoint > >> could choose to serve up only the most basic static information to > >> unauthenticated requesters, but then provide a means for a requester t= o > >> authenticate and request permission from the target user or provider t= o > >> acquire additional information as part of the response. > >> > >> On a side note to Paul: I did have some additional general comments on > the > >> WebFinger spec itself, I wanted to ask where such comments would be be= st > >> directed for discussion. > >> > >> - James > >> > >> On Tue, Mar 27, 2012 at 9:15 AM, Paul E. Jones > >> wrote: > >> > I agree it would be useful to add text about sharing information tha= t > >> > might be dynamic in nature (e.g., current user location). > >> > > >> > We'll add text along those lines to the next draft. Any other > >> > security considerations we should note? > >> > > >> > Paul > >> > > >> >> -----Original Message----- > >> >> From: apps-discuss-bounces@ietf.org > >> >> [mailto:apps-discuss-bounces@ietf.org] > >> >> On Behalf Of Andrew Sullivan > >> >> Sent: Tuesday, March 27, 2012 4:47 AM > >> >> To: apps-discuss@ietf.org > >> >> Subject: Re: [apps-discuss] Webfinger discussion > >> >> > >> >> On Mon, Mar 26, 2012 at 02:31:30PM -0400, Bob Wyman wrote: > >> >> > >> >> > un-recommended!). If people did, in fact, use WebFinger to record > >> >> > such stuff, the concerns you mentioned would be relevant. Thus, i= t > >> >> > might make sense for the Security Considerations section to sugge= st > >> >> > that one should think carefully before using WebFinger to provide > >> >> > such dynamic > >> >> information. > >> >> > >> >> Right, that's most of what I was trying to say. I do have a concer= n > >> >> that collecting a bunch of different information about a given pers= on > >> >> and linking it together in a single, easy to access repository has > >> >> some potential security side effects (not just privacy ones, but > >> >> those too, of > >> >> course) that are not clearly highlighted in the security > >> considerations. > >> >> I suppose one could argue that facebook's (or pick your poison) use= r > >> >> population shows nobody cares about that, but I think it would stil= l > >> >> be good to have some observations about those effects. > >> >> > >> >> Best, > >> >> > >> >> A > >> >> > >> >> -- > >> >> Andrew Sullivan > >> >> ajs@anvilwalrusden.com > >> >> _______________________________________________ > >> >> apps-discuss mailing list > >> >> apps-discuss@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/apps-discuss > >> > > >> > _______________________________________________ > >> > apps-discuss mailing list > >> > apps-discuss@ietf.org > >> > https://www.ietf.org/mailman/listinfo/apps-discuss > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss**** > > Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle > persone indicate. La diffusione, copia o qualsiasi altra azione derivante > dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualo= ra > abbiate ricevuto questo documento per errore siete cortesemente pregati d= i > darne immediata comunicazione al mittente e di provvedere alla sua > distruzione, Grazie. > > This e-mail and any attachments is confidential and may contain privilege= d > information intended for the addressee(s) only. Dissemination, copying, > printing or use by anybody else is unauthorised. If you are not the > intended recipient, please delete this message and any attachments and > advise the sender by return e-mail, Thanks.**** > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss**** > > ** ** > Questo messaggio e i suoi allegati sono indirizzati esclusivamente > alle persone indicate. La diffusione, copia o qualsiasi altra azione > derivante dalla conoscenza di queste informazioni sono rigorosamente > vietate. Qualora abbiate ricevuto questo documento per errore siete > cortesemente pregati di darne immediata comunicazione al mittente e di > provvedere alla sua distruzione, Grazie. > > *This e-mail and any attachments** is **confidential and may contain > privileged information intended for the addressee(s) only. Dissemination, > copying, printing or use by anybody else is unauthorised. If you are not > the intended recipient, please delete this message and any attachments an= d > advise the sender by return e-mail, Thanks.* > *[image: rispetta l'ambiente]Rispetta l'ambiente. Non stampare questa > mail se non =E8 necessario.* > > --20cf300faca1c5af2104bc517711 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Wed, Mar 28, 2012 at 11:17 AM, Goix Laurent Walter=A0<laurentwalte= r.goix@telecomitalia.it>=A0wrote:
>=A0i have not seen webfinger usages = where =93values=94 are directly provided=A0
What is a "pointer" for you may be a "value" for me. Co= nsider the case where the URL of my blog is identified. Is that a pointer, = a value or both at the same time? It seems to me that in these cases, the d= istinction between "pointer" and "value" is not inheren= t to the data provided but rather is found in how the data is used.

bob wyman

On Wed, Mar 28, 2012 at 11= :17 AM, Goix Laurent Walter <laurentwalter.goix@telecomitalia.it> wrote:

On Wed, Mar 28, 2012 at 2:55 AM= , Goix Laurent Walter=A0<laurentwalter.goix@te= lecomitalia.it>=A0wrote:
>=A0more a protocol for accessing user info rather than discovery
Forgive me if I'm being dense, but could you expand a bit on the differ= ence between "accessing user info" and "discovery?"<= /u>

=A0=

[wal= ter] by "accessing user info=94 I mean directly accessing actual infor= mation about a user (my profile details, activity stream, etc). what I mean by =93discovery=94 is to retrieve a pointer to a specific informati= on. Webfinger is aimed at becoming a discovery protocol. There are plenty o= f other protocol/apis/interfaces for accessing information that could be = =93discovered=94 through webfinger and then use very different/specific communications means. I hope I clarified my po= int here.

=A0

>=A0- regarding OAuth it can be valuable in case = webfinger is queried directly by applications.

Certainly, OAuth would be useful when combined with = WebFinger. I would like to be able to have the equivalent of ACLs that woul= d be used to vary the WebFinger responses based on who authenticates. For i= nstance, in mapping from acct: URI to mailto:, I might want one group of people to receive one mailto: and an= other group to see a different value or no value.

=A0

I think we need to also consider that there are alte= rnatives to existing practice of providing "values" directly in t= he WebFinger XRD/JRDs. An alternative would be to provide =A0pointers to ot= her services that can provide the desired answers. (i.e. Adding yet another level of indirection...) in other words, rather t= han providing the mailto: address that corresponds to a particular acct: UR= I, the XRD/JRD could point to a service which uses OAuth and that can be qu= eried to provide whichever of several mailto: addresses that are appropriate -- depending on the results of auth= entication.

=A0<= /p>

[wal= ter] i have not seen webfinger usages where =93values=94 are directly provi= ded and would be very careful with it (I would be glad to see if there are already such usages deployed). Imho the entire purpose of webfinger is= to discover =93pointers=94 to information, not the information itself. Thi= s allows any security mechanism to be applied on those specific endpoints (= + on webfinger endpoint itself) to control access to the actual information (profile, activities, etc).

Again, oau= th could work for users/invocations within a single social network/domain, = but I could hardly imagine it working for server-to-server transactions (eg a user from one SN acts on his server=92s webpage to foll= ow a user on another SN). Or do you have other scenarios in mind with oauth= ?

The only d= irect information I could easily imagine in a xrd is another =93acct=94 uri= in case of portability. Other personal uris (eg im:, mailto:, etc) should be handled with care and imo not included in the xrd but rathe= r in a profile description (hcard, foaf, etc), whose link is provided in th= e xrd (so that a more precise acl can be applied when someone wants to acce= ss it)

=A0=

walter<= /u>

=A0

bob wyman

On Wed, Mar 28, 2012 at 2:55 AM, Goix Laurent Walter= <laurentwalter.goix@telecomitalia.it> wrote:

Hello james, all,

I could see many sort of threads going in parallel in this discussion addre= ssing different types of concerns. I don't want to enter the "secu= rity" discussion here but rather comment on some specific technical po= ints related to the "protocol":

- the "finger" (or lrdd) well-known endpoint could be a shortcut = to consider to directly invoke the webfinger endpoint without the need for = the host-meta. This skips one http transaction, although I would imagine in= most cases that the host-meta xrd 1) can be cached by the invoking client, 2) can contain additional useful info (e= g OExchange endpoint link).

- I am not sure about the exact value brought by the md5 hash, also conside= ring that APIs already exist (e.g. OpenSocial) that use plain identifiers a= s part of the path. I cannot see much difference here wrt security that jus= tifies this need for webfinger. In any case support for md5 hash would probably need to be declared by the= server, eg using {md5uri} instead of {uri} in the lrdd template.

- regarding the shortcuts to link rel types this is becoming more a protoco= l for accessing user info rather than discovery. i can see this as a direct= /standard API/URL to access user information (e.g. avatar, profile-page). T= his misses the "type" (content-type) which may vary within a single rel (although this could be addressed by Ac= cept: headers) and is significantly different from the original scope of we= bfinger for discovery only (I could imagine you could further extend your p= roposal to perform CRUD operations on the single rels, which tends to become close to opensocial apis).
The information contained in the xrd/jrd can in fact easily be cached altog= ether for subsequent use and not for immediate consumption of all rel types= . I would assume this is not more complex than parsing the various Link: he= aders in the responses.
But i can understand there may be some new use case where a user is only in= terested in 1-2 rels for instant consumption, and some solution may be inve= stigated for this.

- regarding OAuth it can be valuable in case webfinger is queried directly = by applications. However in most current usages (ostatus, diaspora, etc) th= e webfinger discovery process is performed by a server of another domain, t= hus limiting the possible usage of oauth in that case.

walter

-----Messaggio originale-----
Da: apps= -discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] Per conto = di James M Snell
Inviato: marted=EC 27 marzo 2012 20.19

A: Paul E. Jones
Cc: apps-discuss= @ietf.org

Oggetto: Re: [apps-discuss] Webfinger discussion<= /u>


They are rather technical in nature and speak to the overall operation
of the protocol. I've written up a detailed version of my feedback
here [1]

[1] http://chmod777self.blogspot.com/2012/03/thoughts-on-webfinger.html

The summary version is this: I believe we can make this even simpler
without sacrificing basic operation by saying simply:

=A0If I want to know about user "bob@example.org", send a GET request to:
=A0http://example.org/.well-known/finger/{md5(acct= :bob@example.org)} and
=A0see what I get back.

The requirement to use XRD/JRD and first look up information about the
LRDD service in host-meta is quite unnecessary. Also note that the ID
is hashed in the request URI for privacy/security purposes...

We can expand on that basic idea further to say:

=A0If I want to know if "bob@example.org" has a "blog" and where it is lo= cated,
=A0I could simply send a request to:
=A0http://example.org/.well-known/finger/f49= c533fa0f0bc7ee9cc8c88902302ba/blog

=A0and the server can respond with a redirect to the proper location:

=A0HTTP/1.1 302 Found
=A0Location: htt= p://blogs.example.org/bob

The "/blog" portion of the request URI specifies a Link rel... if= I
want to discover some other type of service... say, the users profile
or avatar, I simply link the different rel attribute value there..
e.g.

=A0http://example.org/.well-known/finger/f= 49c533fa0f0bc7ee9cc8c88902302ba/avatar
=A0http://example.org/.well-known/finger/= f49c533fa0f0bc7ee9cc8c88902302ba/profile

If there are multiple links for a particular rel, the server can
respond with a 300 Multiple Options response.

The point is that requiring XRD/JRD isn't actually necessary, and
requiring the initial host metadata step isn't required also.

Requiring CORS is also isn't necessary.

Anyway, that's the basic rundown.

- James

On Tue, Mar 27, 2012 at 9:57 AM, Paul E. Jones <paulej@packetizer.com> wrote:
> James,
>
> If the other items are editorial, perhaps just direct them to me. =A0I= f they are items that others might want to weigh in on, then this list is t= he appropriate venue.
>
> Paul
>
>> -----Original Message-----
>> From: James M Snell [mailto:jasnell@gmail.com]
>> Sent: Tuesday, March 27, 2012 12:39 PM
>> To: Paul E. Jones
>> Cc: Andrew Sullivan; apps-discuss@ietf.org
>> Subject: Re: [apps-discuss] Webfinger discussion
>>
>> To be fair, there are ways of dealing with the potential for secur= ity
>> leaks of this nature with WebFinger that did not really exist with= the
>> original Finger protocol. OAuth 2, for instance. A WebFinger endpo= int
>> could choose to serve up only the most basic static information to=
>> unauthenticated requesters, but then provide a means for a request= er to
>> authenticate and request permission from the target user or provid= er to
>> acquire additional information as part of the response.
>>
>> On a side note to Paul: I did have some additional general comment= s on the
>> WebFinger spec itself, I wanted to ask where such comments would b= e best
>> directed for discussion.
>>
>> - James
>>
>> On Tue, Mar 27, 2012 at 9:15 AM, Paul E. Jones <paulej@packetizer.com> >> wrote:
>> > I agree it would be useful to add text about sharing informat= ion that
>> > might be dynamic in nature (e.g., current user location).
>> >
>> > We'll add text along those lines to the next draft. =A0An= y other
>> > security considerations we should note?
>> >
>> > Paul
>> >
>> >> -----Original Message-----
>> >> From: apps-discuss-bounces@ietf.org
>> >> [mailto:apps-discuss-bounces@ietf.org]
>> >> On Behalf Of Andrew Sullivan
>> >> Sent: Tuesday, March 27, 2012 4:47 AM
>> >> To: apps-discuss@ietf.org
>> >> Subject: Re: [apps-discuss] Webfinger discussion
>> >>
>> >> On Mon, Mar 26, 2012 at 02:31:30PM -0400, Bob Wyman wrote= :
>> >>
>> >> > un-recommended!). If people did, in fact, use WebFin= ger to record
>> >> > such stuff, the concerns you mentioned would be rele= vant. Thus, it
>> >> > might make sense for the Security Considerations sec= tion to suggest
>> >> > that one should think carefully before using WebFing= er to provide
>> >> > such dynamic
>> >> information.
>> >>
>> >> Right, that's most of what I was trying to say. =A0I = do have a concern
>> >> that collecting a bunch of different information about a = given person
>> >> and linking it together in a single, easy to access repos= itory has
>> >> some potential security side effects (not just privacy on= es, but
>> >> those too, of
>> >> course) that are not clearly highlighted in the security<= br> >> considerations.
>> >> I suppose one could argue that facebook's (or pick yo= ur poison) user
>> >> population shows nobody cares about that, but I think it = would still
>> >> be good to have some observations about those effects. >> >>
>> >> Best,
>> >>
>> >> A
>> >>
>> >> --
>> >> Andrew Sullivan
>> >> ajs@anvilwalrusden.com
>> >> _______________________________________________
>> >> apps-discuss mailing list
>> >> apps-discuss@ietf.org
>> >> https://www.ietf.org/mailman/listinfo/apps-discuss
>> >
>> > _______________________________________________
>> > apps-discuss mailing list
>> > ap= ps-discuss@ietf.org
>> > https://www.ietf.org/mailman/listinfo/apps-discuss
>
_______________________________________________
apps-discuss mailing list
apps-discuss@iet= f.org
https://www.ietf.org/mailman/listinfo/apps-discuss<= /p>

Questo messaggio e i suoi allegati sono indirizzati = esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altr= a azione derivante dalla conoscenza di queste informazioni sono rigorosamen= te vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata = comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.=


_______________________________________________
apps-discuss mailing list
apps-discuss@iet= f.org
https://www.ietf.org/mailman/listinfo/apps-discuss<= /p>

=A0

Q= uesto messaggio e i suoi allegati sono indirizzati esclusivamente alle pers= one indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigoro= samente vietate. Qualora abbiate ricevuto questo documento per errore siete= cortesemente pregati di darne immediata comunicazione al mittente e di pro= vvedere alla sua distruzione, Grazie.

This e-mail and any attachments=A0is=A0confidential and may contain privileged information intended for the addressee(s) only.= Dissemination, copying, printing or use by anybody else is unauthorised. I= f you are not the intended recipient, please delete this message and any at= tachments and advise the sender by return e-mail, Thanks.

3D"rispettaRispetta l'ambiente. Non stampa= re questa mail se non =E8 necessario.


--20cf300faca1c5af2104bc517711-- --20cf300faca1c5af2304bc517712 Content-Type: image/jpeg; name="logo Ambiente_foglia2.jpg" Content-Transfer-Encoding: base64 Content-ID: <00000000000000000000000000000003@TI.Disclaimer> X-Attachment-Id: dcc9f1527df0e316_0.1 R0lGODlhGgAoANU5AEiFNnikNyRvNcvYOafCOEOEW3DO3jB2NqjGs9ny9o+zOIOrN+L1+G+ggbzo 8GCUN1SNNv///zx+NrPJOL/ROYPV44zY5YuzmrfQwCZxQlKNaMXZzOfy8NTi2TV6TuLs5vX8/ez5 +4yzmtTj2cXr8mCXdKni62ycN5/f6aDf6X2qjrPl7rLl7Zu6OJbb53nS4PH188bs8sXZzfH18pq9 p0SDWxhnNWbL3NfgOf///wAAAAAAAAAAAAAAAAAAAAAAACH5BAEAADkALAAAAAAaACgAAAb/wJxw SBQ6WMWkMmm6kZbQ5OvmjFoT1JuBYYWmsrcXqJvEgm8WctFypnI66pyjfXMhCmqGgR4r2S5dIBV0 FjI2h3BRX20VHAUCEjZ4UHNtFo42BA+HCEskbQYOIwU2CjgBNgAZM0kMbSYcIjYCBDg4LTYLf0V6 YCghNBk2DwO2OASZqkS9VBYMCB6pE8bGucidOYJUoaOptdQTFDg2ATgHGkIs2wyyAqbUtgICCwfl uh8ge1sNNhDF8LYiHYKAg4INBJUS8FsAEF6AA6lsHWjg4gYKDDZONGwIAIAtCAX2hPAgYSNHj6ds 3KiA8V3DAQGm2epoS4HKFQ0EmMRhc97Mwge2kN1IoIGgyQECD5wQUO6YygTkdtpCdSgqDl0VoDaV OmDBpm+oTCQoABQgBZfGbIrDAUBDAgcNDnDs98/WA504Buxa0RKgzVkB/h0oi+pDjgQhHtU1RgDi oY6l8gpAJyTBCBsSFtuC6XjWTBuJhIRAgFkmwAmoAkM4mCQCBmEB1sIDIKAFRGytYfDrt4CAuAkn qnrYYCXCBxGkqlYtgbtLhOcbMNSw0SBOEmg2VFj/sGHDhRLCNBC3fqFqARWhowQBADs= --20cf300faca1c5af2304bc517712-- From paulej@packetizer.com Wed Mar 28 14:07:23 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4AB021F8543 for ; Wed, 28 Mar 2012 14:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Nynqw4VdD+G for ; Wed, 28 Mar 2012 14:07:21 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id D1D6A21F8537 for ; Wed, 28 Mar 2012 14:07:20 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q2SL7Jv5028494 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 28 Mar 2012 17:07:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1332968840; bh=YIuumMXznq0+ZwNwYjgOZic1PyS2QvybhVDafDE4Ces=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=cWVRa1BvJr1H7SdeOy5u+ljgO7SUfK0QyEuF1cxMoLcdBrQoVp4viJiN4PSNhiSSa SjvZW/CFc/2T8AjPBbiVcc/UnAQN2PFPKIPxs7m9wdzVwT5pExNt4ul64BTdJuD9IN WaH6Zi+N8cheQdQsDAU3nu4OzXmrWvw+uHlAEMf8= From: "Paul E. Jones" To: "'Bob Wyman'" References: <053201cd0b5d$c08c80f0$41a582d0$@packetizer.com> <20120326150556.GC3557@mail.yitter.info> <20120327084709.GB11491@mail.yitter.info> <00ac01cd0c34$cfc96f10$6f5c4d30$@packetizer.com> <00d201cd0c3a$b3672410$1a356c30$@packetizer.com> <00f701cd0c44$48cb87e0$da6297a0$@packetizer.com> In-Reply-To: Date: Wed, 28 Mar 2012 17:07:24 -0400 Message-ID: <021301cd0d26$c6b0db50$541291f0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0214_01CD0D05.3FA0C1F0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEg174HJISLlkWDD0VVkXSpmVuZQwKMareXAWwgTx8BwaaRJQGG5wouAU3B5AYBuFTkWgH4n5esAoBkcbkB4jKGpJdTg6EA Content-Language: en-us Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Webfinger discussion X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 28 Mar 2012 21:07:23 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0214_01CD0D05.3FA0C1F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Bob, Given I'm not sure how to really use these off-hand, I'd prefer we did not put them into examples. It would be reasonable to define an "im" link relation, though. Then the href can refer to something concrete like xmpp:paulej@packetizer.com. Paul From: bobwyman@gmail.com [mailto:bobwyman@gmail.com] On Behalf Of Bob Wyman Sent: Tuesday, March 27, 2012 2:13 PM To: Paul E. Jones Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Webfinger discussion im: and pres: were defined as protocol independent URI's in order to make things simpler than having to work with XMPP, SIP, and potentially even APEX, etc. as alternative presence or messaging protocols. But, yeah... nobody seems to use the stuff. The fact remains that messaging and presence are still distinct services. So, perhaps an xmpp: URI tagged as both "instant-messaging" and "presence" would make more sense. bob wyman On Tue, Mar 27, 2012 at 2:06 PM, Paul E. Jones wrote: Bob, Is "pres:" being used in practice? Does it refer to SIP or XMPP or other presence protocol? I'll note that adding this one might incite additional concerns for privacy. I assume that whatever protocol to which pres: refers (which is unclear to me) would handle the authorization aspects. But, I'm left wondering. if one knows a person's SIP or XMPP URI, why would one need pres:? Paul From: bobwyman@gmail.com [mailto:bobwyman@gmail.com] On Behalf Of Bob Wyman Sent: Tuesday, March 27, 2012 1:18 PM To: Paul E. Jones Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Webfinger discussion Paul, Examples are very powerful means of setting expectations for usage of standards... So, perhaps it would be useful to include in the examples a pointer to a user's "pres:" URI, defined by RFC3859 "Common Profile for Presence", as the endpoint that should be used to obtain "presence" information. bob wyman On Tue, Mar 27, 2012 at 12:57 PM, Paul E. Jones wrote: James, If the other items are editorial, perhaps just direct them to me. If they are items that others might want to weigh in on, then this list is the appropriate venue. Paul > -----Original Message----- > From: James M Snell [mailto:jasnell@gmail.com] > Sent: Tuesday, March 27, 2012 12:39 PM > To: Paul E. Jones > Cc: Andrew Sullivan; apps-discuss@ietf.org > Subject: Re: [apps-discuss] Webfinger discussion > > To be fair, there are ways of dealing with the potential for security > leaks of this nature with WebFinger that did not really exist with the > original Finger protocol. OAuth 2, for instance. A WebFinger endpoint > could choose to serve up only the most basic static information to > unauthenticated requesters, but then provide a means for a requester to > authenticate and request permission from the target user or provider to > acquire additional information as part of the response. > > On a side note to Paul: I did have some additional general comments on the > WebFinger spec itself, I wanted to ask where such comments would be best > directed for discussion. > > - James > > On Tue, Mar 27, 2012 at 9:15 AM, Paul E. Jones > wrote: > > I agree it would be useful to add text about sharing information that > > might be dynamic in nature (e.g., current user location). > > > > We'll add text along those lines to the next draft. Any other > > security considerations we should note? > > > > Paul > > > >> -----Original Message----- > >> From: apps-discuss-bounces@ietf.org > >> [mailto:apps-discuss-bounces@ietf.org] > >> On Behalf Of Andrew Sullivan > >> Sent: Tuesday, March 27, 2012 4:47 AM > >> To: apps-discuss@ietf.org > >> Subject: Re: [apps-discuss] Webfinger discussion > >> > >> On Mon, Mar 26, 2012 at 02:31:30PM -0400, Bob Wyman wrote: > >> > >> > un-recommended!). If people did, in fact, use WebFinger to record > >> > such stuff, the concerns you mentioned would be relevant. Thus, it > >> > might make sense for the Security Considerations section to suggest > >> > that one should think carefully before using WebFinger to provide > >> > such dynamic > >> information. > >> > >> Right, that's most of what I was trying to say. I do have a concern > >> that collecting a bunch of different information about a given person > >> and linking it together in a single, easy to access repository has > >> some potential security side effects (not just privacy ones, but > >> those too, of > >> course) that are not clearly highlighted in the security > considerations. > >> I suppose one could argue that facebook's (or pick your poison) user > >> population shows nobody cares about that, but I think it would still > >> be good to have some observations about those effects. > >> > >> Best, > >> > >> A > >> > >> -- > >> Andrew Sullivan > >> ajs@anvilwalrusden.com > >> _______________________________________________ > >> apps-discuss mailing list > >> apps-discuss@ietf.org > >> https://www.ietf.org/mailman/listinfo/apps-discuss > > > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss ------=_NextPart_000_0214_01CD0D05.3FA0C1F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Bob,

 

Given I’m not sure how to really use these off-hand, I’d = prefer we did not put them into examples.  It would be reasonable = to define an “im” link relation, though.  Then the href = can refer to something concrete like = xmpp:paulej@packetizer.com.

Paul

 

From:= = bobwyman@gmail.com [mailto:bobwyman@gmail.com] On Behalf Of Bob = Wyman
Sent: Tuesday, March 27, 2012 2:13 PM
To: Paul = E. Jones
Cc: apps-discuss@ietf.org
Subject: Re: = [apps-discuss] Webfinger discussion

 

im: and = pres: were defined as protocol independent URI's in order to make things = simpler than having to work with XMPP, SIP, and potentially even APEX, = etc. as alternative presence or messaging protocols. But, yeah... nobody = seems to use the stuff. The fact remains that messaging and presence are = still distinct services. So, perhaps an xmpp: URI tagged as both = "instant-messaging" and "presence" would make more = sense.

 

bob wyman

On Tue, Mar 27, 2012 at 2:06 PM, Paul E. Jones <paulej@packetizer.com> = wrote:

Bob,

 

Is “pres:” being used in practice?  Does it refer to = SIP or XMPP or other presence protocol?

 

I’ll note that adding this one might incite additional concerns = for privacy.  I assume that whatever protocol to which pres: refers = (which is unclear to me) would handle the authorization aspects.  = But, I’m left wondering… if one knows a person’s SIP = or XMPP URI, why would one need pres:?

 

Paul

 

From:= = bobwyman@gmail.com [mailto:bobwyman@gmail.com] On Behalf Of Bob = Wyman
Sent: Tuesday, March 27, 2012 1:18 PM
To: Paul = E. Jones
Cc: apps-discuss@ietf.org


Subject: Re: [apps-discuss] Webfinger = discussion

 <= /o:p>

Paul,

Examples = are very powerful means of setting expectations for usage of = standards... So, perhaps it would be useful to include in the examples a = pointer to a user's "pres:" URI, defined by RFC3859 = "Common Profile for Presence", as the endpoint that should be = used to obtain "presence" = information. 

 <= /o:p>

bob = wyman

 <= /o:p>

On Tue, Mar = 27, 2012 at 12:57 PM, Paul E. Jones <paulej@packetizer.com> wrote:

James,
If the other items are editorial, perhaps just direct them to me. =  If they are items that others might want to weigh in on, then this = list is the appropriate venue.

Paul


> = -----Original Message-----
> From: James M Snell [mailto:jasnell@gmail.com]
> Sent: Tuesday, March = 27, 2012 12:39 PM
> To: Paul E. Jones
> Cc: Andrew Sullivan; = apps-discuss@ietf.org
> Subject: Re: = [apps-discuss] Webfinger discussion
>
> To be fair, there = are ways of dealing with the potential for security
> leaks of = this nature with WebFinger that did not really exist with the
> = original Finger protocol. OAuth 2, for instance. A WebFinger = endpoint
> could choose to serve up only the most basic static = information to
> unauthenticated requesters, but then provide a = means for a requester to
> authenticate and request permission = from the target user or provider to
> acquire additional = information as part of the response.
>
> On a side note to = Paul: I did have some additional general comments on the
> = WebFinger spec itself, I wanted to ask where such comments would be = best
> directed for discussion.
>
> - = James
>
> On Tue, Mar 27, 2012 at 9:15 AM, Paul E. Jones = <paulej@packetizer.com>
> wrote:
> = > I agree it would be useful to add text about sharing information = that
> > might be dynamic in nature (e.g., current user = location).
> >
> > We'll add text along those lines to = the next draft.  Any other
> > security considerations we = should note?
> >
> > Paul
> >
> = >> -----Original Message-----
> >> From: apps-discuss-bounces@ietf.org
> >> = [mailto:apps-discuss-bounces@ietf.org]
> >> On = Behalf Of Andrew Sullivan
> >> Sent: Tuesday, March 27, 2012 = 4:47 AM
> >> To: apps-discuss@ietf.org
> >> Subject: = Re: [apps-discuss] Webfinger discussion
> >>
> = >> On Mon, Mar 26, 2012 at 02:31:30PM -0400, Bob Wyman = wrote:
> >>
> >> > un-recommended!). If = people did, in fact, use WebFinger to record
> >> > such = stuff, the concerns you mentioned would be relevant. Thus, it
> = >> > might make sense for the Security Considerations section = to suggest
> >> > that one should think carefully before = using WebFinger to provide
> >> > such dynamic
> = >> information.
> >>
> >> Right, that's = most of what I was trying to say.  I do have a concern
> = >> that collecting a bunch of different information about a given = person
> >> and linking it together in a single, easy to = access repository has
> >> some potential security side = effects (not just privacy ones, but
> >> those too, = of
> >> course) that are not clearly highlighted in the = security
> considerations.
> >> I suppose one could = argue that facebook's (or pick your poison) user
> >> = population shows nobody cares about that, but I think it would = still
> >> be good to have some observations about those = effects.
> >>
> >> Best,
> = >>
> >> A
> >>
> >> --
> = >> Andrew Sullivan
> >> ajs@anvilwalrusden.com
> >> = _______________________________________________
> >> = apps-discuss mailing list
> >> apps-discuss@ietf.org
> >> https://www.ietf.org/mailman/listinfo/apps-discuss<= br>> >
> > = _______________________________________________
> > = apps-discuss mailing list
> > apps-discuss@ietf.org
> > https://www.ietf.org/mailman/listinfo/apps-discuss<= br>
_______________________________________________
apps-discuss = mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss<= o:p>

 <= /o:p>

 

------=_NextPart_000_0214_01CD0D05.3FA0C1F0-- From paulej@packetizer.com Wed Mar 28 14:09:43 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 873D521E80A2 for ; Wed, 28 Mar 2012 14:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dEKNWYrGTXSp for ; Wed, 28 Mar 2012 14:09:40 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id A4B0B21E80BB for ; Wed, 28 Mar 2012 14:09:40 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q2SL9d4W028533 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 28 Mar 2012 17:09:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1332968980; bh=hDCJ+A3oRPWKTWPC6hu87fc0qMf/ia6jwCVJ+Uvu3Ls=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=htrUrqMeZgcdABiXLdhKx7L9NgA5DxT9H9NcMEnkgrYLre/nP+PqO1c1X98JajgN0 J7bRUHQJsp2+9sMwdCn10CY1QASkRH8XNK4nrGy7S1ToNlEjmgr/MSiGskazo8UDXg AZfxXXjJWAfBfKHl/6xv+6cggFfkj1hk8n32DJ90= From: "Paul E. Jones" To: "'Bob Wyman'" References: <053201cd0b5d$c08c80f0$41a582d0$@packetizer.com> <20120326150556.GC3557@mail.yitter.info> <20120327084709.GB11491@mail.yitter.info> <00ac01cd0c34$cfc96f10$6f5c4d30$@packetizer.com> <00d201cd0c3a$b3672410$1a356c30$@packetizer.com> <00f701cd0c44$48cb87e0$da6297a0$@packetizer.com> In-Reply-To: Date: Wed, 28 Mar 2012 17:09:44 -0400 Message-ID: <022001cd0d27$1a06c7b0$4e145710$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0221_01CD0D05.92F6D560" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEg174HJISLlkWDD0VVkXSpmVuZQwKMareXAWwgTx8BwaaRJQGG5wouAU3B5AYBuFTkWgH4n5esAoBkcbkB4jKGpAIrItt5l0IyRGA= Content-Language: en-us Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Webfinger discussion X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 28 Mar 2012 21:09:43 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0221_01CD0D05.92F6D560 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit That said. vcard defines addresses like IM. We ought not duplicate information, but I'm not sure where to draw the line. Paul From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: Wednesday, March 28, 2012 5:07 PM To: 'Bob Wyman' Cc: 'apps-discuss@ietf.org' Subject: RE: [apps-discuss] Webfinger discussion Bob, Given I'm not sure how to really use these off-hand, I'd prefer we did not put them into examples. It would be reasonable to define an "im" link relation, though. Then the href can refer to something concrete like xmpp:paulej@packetizer.com. Paul From: bobwyman@gmail.com [mailto:bobwyman@gmail.com] On Behalf Of Bob Wyman Sent: Tuesday, March 27, 2012 2:13 PM To: Paul E. Jones Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Webfinger discussion im: and pres: were defined as protocol independent URI's in order to make things simpler than having to work with XMPP, SIP, and potentially even APEX, etc. as alternative presence or messaging protocols. But, yeah... nobody seems to use the stuff. The fact remains that messaging and presence are still distinct services. So, perhaps an xmpp: URI tagged as both "instant-messaging" and "presence" would make more sense. bob wyman On Tue, Mar 27, 2012 at 2:06 PM, Paul E. Jones wrote: Bob, Is "pres:" being used in practice? Does it refer to SIP or XMPP or other presence protocol? I'll note that adding this one might incite additional concerns for privacy. I assume that whatever protocol to which pres: refers (which is unclear to me) would handle the authorization aspects. But, I'm left wondering. if one knows a person's SIP or XMPP URI, why would one need pres:? Paul From: bobwyman@gmail.com [mailto:bobwyman@gmail.com] On Behalf Of Bob Wyman Sent: Tuesday, March 27, 2012 1:18 PM To: Paul E. Jones Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Webfinger discussion Paul, Examples are very powerful means of setting expectations for usage of standards... So, perhaps it would be useful to include in the examples a pointer to a user's "pres:" URI, defined by RFC3859 "Common Profile for Presence", as the endpoint that should be used to obtain "presence" information. bob wyman On Tue, Mar 27, 2012 at 12:57 PM, Paul E. Jones wrote: James, If the other items are editorial, perhaps just direct them to me. If they are items that others might want to weigh in on, then this list is the appropriate venue. Paul > -----Original Message----- > From: James M Snell [mailto:jasnell@gmail.com] > Sent: Tuesday, March 27, 2012 12:39 PM > To: Paul E. Jones > Cc: Andrew Sullivan; apps-discuss@ietf.org > Subject: Re: [apps-discuss] Webfinger discussion > > To be fair, there are ways of dealing with the potential for security > leaks of this nature with WebFinger that did not really exist with the > original Finger protocol. OAuth 2, for instance. A WebFinger endpoint > could choose to serve up only the most basic static information to > unauthenticated requesters, but then provide a means for a requester to > authenticate and request permission from the target user or provider to > acquire additional information as part of the response. > > On a side note to Paul: I did have some additional general comments on the > WebFinger spec itself, I wanted to ask where such comments would be best > directed for discussion. > > - James > > On Tue, Mar 27, 2012 at 9:15 AM, Paul E. Jones > wrote: > > I agree it would be useful to add text about sharing information that > > might be dynamic in nature (e.g., current user location). > > > > We'll add text along those lines to the next draft. Any other > > security considerations we should note? > > > > Paul > > > >> -----Original Message----- > >> From: apps-discuss-bounces@ietf.org > >> [mailto:apps-discuss-bounces@ietf.org] > >> On Behalf Of Andrew Sullivan > >> Sent: Tuesday, March 27, 2012 4:47 AM > >> To: apps-discuss@ietf.org > >> Subject: Re: [apps-discuss] Webfinger discussion > >> > >> On Mon, Mar 26, 2012 at 02:31:30PM -0400, Bob Wyman wrote: > >> > >> > un-recommended!). If people did, in fact, use WebFinger to record > >> > such stuff, the concerns you mentioned would be relevant. Thus, it > >> > might make sense for the Security Considerations section to suggest > >> > that one should think carefully before using WebFinger to provide > >> > such dynamic > >> information. > >> > >> Right, that's most of what I was trying to say. I do have a concern > >> that collecting a bunch of different information about a given person > >> and linking it together in a single, easy to access repository has > >> some potential security side effects (not just privacy ones, but > >> those too, of > >> course) that are not clearly highlighted in the security > considerations. > >> I suppose one could argue that facebook's (or pick your poison) user > >> population shows nobody cares about that, but I think it would still > >> be good to have some observations about those effects. > >> > >> Best, > >> > >> A > >> > >> -- > >> Andrew Sullivan > >> ajs@anvilwalrusden.com > >> _______________________________________________ > >> apps-discuss mailing list > >> apps-discuss@ietf.org > >> https://www.ietf.org/mailman/listinfo/apps-discuss > > > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss ------=_NextPart_000_0221_01CD0D05.92F6D560 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

That said… vcard defines addresses like IM.  We ought not = duplicate information, but I’m not sure where to draw the = line.

 

Paul

 

From:= = Paul E. Jones [mailto:paulej@packetizer.com]
Sent: Wednesday, = March 28, 2012 5:07 PM
To: 'Bob Wyman'
Cc: = 'apps-discuss@ietf.org'
Subject: RE: [apps-discuss] Webfinger = discussion

 

Bob,

 

Given I’m not sure how to really use these off-hand, I’d = prefer we did not put them into examples.  It would be reasonable = to define an “im” link relation, though.  Then the href = can refer to something concrete like = xmpp:paulej@packetizer.com.

 

Paul

 

 

im: and = pres: were defined as protocol independent URI's in order to make things = simpler than having to work with XMPP, SIP, and potentially even APEX, = etc. as alternative presence or messaging protocols. But, yeah... nobody = seems to use the stuff. The fact remains that messaging and presence are = still distinct services. So, perhaps an xmpp: URI tagged as both = "instant-messaging" and "presence" would make more = sense.

 

bob wyman

On Tue, Mar 27, 2012 at 2:06 PM, Paul E. Jones <paulej@packetizer.com> = wrote:

Bob,

 

Is “pres:” being used in practice?  Does it refer to = SIP or XMPP or other presence protocol?

 

I’ll note that adding this one might incite additional concerns = for privacy.  I assume that whatever protocol to which pres: refers = (which is unclear to me) would handle the authorization aspects.  = But, I’m left wondering… if one knows a person’s SIP = or XMPP URI, why would one need pres:?

 

Paul

 

From:= = bobwyman@gmail.com [mailto:bobwyman@gmail.com] On Behalf Of Bob = Wyman
Sent: Tuesday, March 27, 2012 1:18 PM
To: Paul = E. Jones
Cc: apps-discuss@ietf.org


Subject: Re: [apps-discuss] Webfinger = discussion

 <= /o:p>

Paul,

Examples = are very powerful means of setting expectations for usage of = standards... So, perhaps it would be useful to include in the examples a = pointer to a user's "pres:" URI, defined by RFC3859 = "Common Profile for Presence", as the endpoint that should be = used to obtain "presence" = information. 

 <= /o:p>

bob = wyman

 <= /o:p>

On Tue, Mar = 27, 2012 at 12:57 PM, Paul E. Jones <paulej@packetizer.com> wrote:

James,
If the other items are editorial, perhaps just direct them to me. =  If they are items that others might want to weigh in on, then this = list is the appropriate venue.

Paul


> = -----Original Message-----
> From: James M Snell [mailto:jasnell@gmail.com]
> Sent: Tuesday, March = 27, 2012 12:39 PM
> To: Paul E. Jones
> Cc: Andrew Sullivan; = apps-discuss@ietf.org
> Subject: Re: = [apps-discuss] Webfinger discussion
>
> To be fair, there = are ways of dealing with the potential for security
> leaks of = this nature with WebFinger that did not really exist with the
> = original Finger protocol. OAuth 2, for instance. A WebFinger = endpoint
> could choose to serve up only the most basic static = information to
> unauthenticated requesters, but then provide a = means for a requester to
> authenticate and request permission = from the target user or provider to
> acquire additional = information as part of the response.
>
> On a side note to = Paul: I did have some additional general comments on the
> = WebFinger spec itself, I wanted to ask where such comments would be = best
> directed for discussion.
>
> - = James
>
> On Tue, Mar 27, 2012 at 9:15 AM, Paul E. Jones = <paulej@packetizer.com>
> wrote:
> = > I agree it would be useful to add text about sharing information = that
> > might be dynamic in nature (e.g., current user = location).
> >
> > We'll add text along those lines to = the next draft.  Any other
> > security considerations we = should note?
> >
> > Paul
> >
> = >> -----Original Message-----
> >> From: apps-discuss-bounces@ietf.org
> >> = [mailto:apps-discuss-bounces@ietf.org]
> >> On = Behalf Of Andrew Sullivan
> >> Sent: Tuesday, March 27, 2012 = 4:47 AM
> >> To: apps-discuss@ietf.org
> >> Subject: = Re: [apps-discuss] Webfinger discussion
> >>
> = >> On Mon, Mar 26, 2012 at 02:31:30PM -0400, Bob Wyman = wrote:
> >>
> >> > un-recommended!). If = people did, in fact, use WebFinger to record
> >> > such = stuff, the concerns you mentioned would be relevant. Thus, it
> = >> > might make sense for the Security Considerations section = to suggest
> >> > that one should think carefully before = using WebFinger to provide
> >> > such dynamic
> = >> information.
> >>
> >> Right, that's = most of what I was trying to say.  I do have a concern
> = >> that collecting a bunch of different information about a given = person
> >> and linking it together in a single, easy to = access repository has
> >> some potential security side = effects (not just privacy ones, but
> >> those too, = of
> >> course) that are not clearly highlighted in the = security
> considerations.
> >> I suppose one could = argue that facebook's (or pick your poison) user
> >> = population shows nobody cares about that, but I think it would = still
> >> be good to have some observations about those = effects.
> >>
> >> Best,
> = >>
> >> A
> >>
> >> --
> = >> Andrew Sullivan
> >> ajs@anvilwalrusden.com
> >> = _______________________________________________
> >> = apps-discuss mailing list
> >> apps-discuss@ietf.org
> >> https://www.ietf.org/mailman/listinfo/apps-discuss<= br>> >
> > = _______________________________________________
> > = apps-discuss mailing list
> > apps-discuss@ietf.org
> > https://www.ietf.org/mailman/listinfo/apps-discuss<= br>
_______________________________________________
apps-discuss = mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss<= o:p>

 <= /o:p>

 

------=_NextPart_000_0221_01CD0D05.92F6D560-- From paulej@packetizer.com Wed Mar 28 14:49:33 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8750621E8097 for ; Wed, 28 Mar 2012 14:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.492 X-Spam-Level: X-Spam-Status: No, score=-2.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZDiHToMubs9 for ; Wed, 28 Mar 2012 14:49:32 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 8051B21E801E for ; Wed, 28 Mar 2012 14:49:32 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q2SLnSg6029133 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 28 Mar 2012 17:49:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1332971369; bh=0TlalVdtAu7aBdUkkc/amxw0T+TwlvIRrGCk4+Vbgac=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=tV7RAqtFN/4jKeEoaQDm9F8y+9Wc4k9OsJq8o/vgFhKb9prdXTKta9lJrKlEmbogi H2amD5V20lAyc38DDsYp0caccpqftissE7/1jr/cVlx/n2p57SNCN9BvIS9KBwUNxB fyLD0oD6eWrUIDUA9OcvbFFHRtqNLfO6SsyGYL1o= From: "Paul E. Jones" To: "'James M Snell'" References: <053201cd0b5d$c08c80f0$41a582d0$@packetizer.com> <20120326150556.GC3557@mail.yitter.info> <20120327084709.GB11491@mail.yitter.info> <00ac01cd0c34$cfc96f10$6f5c4d30$@packetizer.com> <00d201cd0c3a$b3672410$1a356c30$@packetizer.com> In-Reply-To: Date: Wed, 28 Mar 2012 17:49:34 -0400 Message-ID: <023901cd0d2c$aa665e10$ff331a30$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEg174HJISLlkWDD0VVkXSpmVuZQwKMareXAWwgTx8BwaaRJQGG5wouAU3B5AYBuFTkWgIDrH2Cl3ZNHSA= Content-Language: en-us Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Webfinger discussion X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 28 Mar 2012 21:49:33 -0000 James, I really like this idea. It makes an attempt to short-cut some of the = procedures, very much in line with what the "resource" parameter does in = Section 4.2 of the Webfinger draft. I don't have a particular love for = the using MD5, preferring something like this: GET = /.well-known/webfinger?resource=3Dacct%3Abob%40example.com&rel=3Dblog = HTTP/1.1 Since any reply might have multiple links, then the 204 reply including = links would likely be necessary. Using 302 would not be right, since = that has a different meaning: the client would go to Location trying to = resolve the original request. A 204 with any number of Link headers = would be good. Using the resource parameter means we make a query and get a JRD or XRD = document. What we cannot do is query for one specific type of content. Changing Webfinger so drastically is a challenge since Webfinger builds = on RFC 6415. But, I do like the idea of querying for a very specific = value like this: GET = /.well-known/host-meta.json?resource=3Dacct%3Abob%40example.com&rel=3Dblo= g HTTP/1.1 Perhaps this might return a reply like this: HTTP/1.1 204 No Content Link: ; rel=3D"blog" A challenge with this, though, is that it means the application has to = deal with two different formats. Either JRD/XRD or an HTTP header with = Links. We could introduce this and make it mandatory if the resource parameter = is supported. However, would it make the client-side code simpler? = Support for the "resource" parameter is already optional. (We could = make it mandatory, but I did get pushback on that.) Paul > -----Original Message----- > From: James M Snell [mailto:jasnell@gmail.com] > Sent: Tuesday, March 27, 2012 2:19 PM > To: Paul E. Jones > Cc: Andrew Sullivan; apps-discuss@ietf.org > Subject: Re: [apps-discuss] Webfinger discussion >=20 > They are rather technical in nature and speak to the overall operation = of > the protocol. I've written up a detailed version of my feedback here = [1] >=20 > [1] = http://chmod777self.blogspot.com/2012/03/thoughts-on-webfinger.html >=20 > The summary version is this: I believe we can make this even simpler > without sacrificing basic operation by saying simply: >=20 > If I want to know about user "bob@example.org", send a GET request = to: > http://example.org/.well-known/finger/{md5(acct:bob@example.org)} = and > see what I get back. >=20 > The requirement to use XRD/JRD and first look up information about the > LRDD service in host-meta is quite unnecessary. Also note that the ID = is > hashed in the request URI for privacy/security purposes... >=20 > We can expand on that basic idea further to say: >=20 > If I want to know if "bob@example.org" has a "blog" and where it is > located, > I could simply send a request to: > http://example.org/.well- > known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/blog >=20 > and the server can respond with a redirect to the proper location: >=20 > HTTP/1.1 302 Found > Location: http://blogs.example.org/bob >=20 > The "/blog" portion of the request URI specifies a Link rel... if I = want > to discover some other type of service... say, the users profile or > avatar, I simply link the different rel attribute value there.. > e.g. >=20 > http://example.org/.well- > known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/avatar > http://example.org/.well- > known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/profile >=20 > If there are multiple links for a particular rel, the server can = respond > with a 300 Multiple Options response. >=20 > The point is that requiring XRD/JRD isn't actually necessary, and > requiring the initial host metadata step isn't required also. >=20 > Requiring CORS is also isn't necessary. >=20 > Anyway, that's the basic rundown. >=20 > - James >=20 > On Tue, Mar 27, 2012 at 9:57 AM, Paul E. Jones > wrote: > > James, > > > > If the other items are editorial, perhaps just direct them to me. = If > they are items that others might want to weigh in on, then this list = is > the appropriate venue. > > > > Paul > > > >> -----Original Message----- > >> From: James M Snell [mailto:jasnell@gmail.com] > >> Sent: Tuesday, March 27, 2012 12:39 PM > >> To: Paul E. Jones > >> Cc: Andrew Sullivan; apps-discuss@ietf.org > >> Subject: Re: [apps-discuss] Webfinger discussion > >> > >> To be fair, there are ways of dealing with the potential for = security > >> leaks of this nature with WebFinger that did not really exist with > >> the original Finger protocol. OAuth 2, for instance. A WebFinger > >> endpoint could choose to serve up only the most basic static > >> information to unauthenticated requesters, but then provide a means > >> for a requester to authenticate and request permission from the > >> target user or provider to acquire additional information as part = of > the response. > >> > >> On a side note to Paul: I did have some additional general comments > >> on the WebFinger spec itself, I wanted to ask where such comments > >> would be best directed for discussion. > >> > >> - James > >> > >> On Tue, Mar 27, 2012 at 9:15 AM, Paul E. Jones > >> > >> wrote: > >> > I agree it would be useful to add text about sharing information > >> > that might be dynamic in nature (e.g., current user location). > >> > > >> > We'll add text along those lines to the next draft. Any other > >> > security considerations we should note? > >> > > >> > Paul > >> > > >> >> -----Original Message----- > >> >> From: apps-discuss-bounces@ietf.org > >> >> [mailto:apps-discuss-bounces@ietf.org] > >> >> On Behalf Of Andrew Sullivan > >> >> Sent: Tuesday, March 27, 2012 4:47 AM > >> >> To: apps-discuss@ietf.org > >> >> Subject: Re: [apps-discuss] Webfinger discussion > >> >> > >> >> On Mon, Mar 26, 2012 at 02:31:30PM -0400, Bob Wyman wrote: > >> >> > >> >> > un-recommended!). If people did, in fact, use WebFinger to > >> >> > record such stuff, the concerns you mentioned would be = relevant. > >> >> > Thus, it might make sense for the Security Considerations > >> >> > section to suggest that one should think carefully before = using > >> >> > WebFinger to provide such dynamic > >> >> information. > >> >> > >> >> Right, that's most of what I was trying to say. I do have a > >> >> concern that collecting a bunch of different information about a > >> >> given person and linking it together in a single, easy to access > >> >> repository has some potential security side effects (not just > >> >> privacy ones, but those too, of > >> >> course) that are not clearly highlighted in the security > >> considerations. > >> >> I suppose one could argue that facebook's (or pick your poison) > >> >> user population shows nobody cares about that, but I think it > >> >> would still be good to have some observations about those = effects. > >> >> > >> >> Best, > >> >> > >> >> A > >> >> > >> >> -- > >> >> Andrew Sullivan > >> >> ajs@anvilwalrusden.com > >> >> _______________________________________________ > >> >> apps-discuss mailing list > >> >> apps-discuss@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/apps-discuss > >> > > >> > _______________________________________________ > >> > apps-discuss mailing list > >> > apps-discuss@ietf.org > >> > https://www.ietf.org/mailman/listinfo/apps-discuss > > From paulej@packetizer.com Wed Mar 28 15:13:34 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAEA221E8101 for ; Wed, 28 Mar 2012 15:13:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k5N5fGmnJjny for ; Wed, 28 Mar 2012 15:13:34 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id F2B0D21E80FB for ; Wed, 28 Mar 2012 15:13:33 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q2SMDVbn029512 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 28 Mar 2012 18:13:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1332972813; bh=SGZgQ6kYIlORcpQt7kidallyq0B+DCIL2bpEIggDHyI=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=i2k0LjigPwQqolshHagmPZQkY0QSW6Vh7p+58EO/YnyaSnhT6kwQFk9tr+hRpUH9Z wb46VtRsSrImHp3zeqrG7RvQebxc1OsxROHvRUe404T+riHPPSjTrliBh6cgb/PJvv JZ/CXOYtQgvPinPiAttA38FZxm1IkHd2AVQa5RWU= From: "Paul E. Jones" To: "'Alessandro Vesely'" , References: <053201cd0b5d$c08c80f0$41a582d0$@packetizer.com> <20120326150556.GC3557@mail.yitter.info> <20120327084709.GB11491@mail.yitter.info> <00ac01cd0c34$cfc96f10$6f5c4d30$@packetizer.com> <00d201cd0c3a$b3672410$1a356c30$@packetizer.com> <4F72F5C0.70106@tana.it> In-Reply-To: <4F72F5C0.70106@tana.it> Date: Wed, 28 Mar 2012 18:13:37 -0400 Message-ID: <024101cd0d30$06d70ac0$14852040$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEg174HJISLlkWDD0VVkXSpmVuZQwKMareXAWwgTx8BwaaRJQGG5wouAU3B5AYBuFTkWgIDrH2CAm7QUeSXYuMTgA== Content-Language: en-us Subject: Re: [apps-discuss] What auth server supplies email addresses? Was webfinger discussion X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 28 Mar 2012 22:13:34 -0000 Get an email address from what ID? A Webfinger "acct" URI? Paul > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] > On Behalf Of Alessandro Vesely > Sent: Wednesday, March 28, 2012 7:28 AM > To: apps-discuss@ietf.org > Subject: [apps-discuss] What auth server supplies email addresses? Was > webfinger discussion > > I reproach myself for having missed the Internet Society Panel on OpenID > and OAuth yesterday morning. I'll try and find the recording. Meanwhile, > does someone know if there is a way to get an email address from an id? > > On Wed 28/Mar/2012 12:40:20 +0200 James M Snell wrote: > > > > If I want to know about user "bob@example.org", send a GET request to: > > http://example.org/.well-known/finger/{md5(acct:bob@example.org)} and > > see what I get back. > > That implies the address is known. Couldn't one use just > > http://example.org/.well-known/finger/{opaque-token} > > and, possibly, > > http://example.org/.well-known/finger/{opaque-token}/email-addr? > > The idea is that the relevant user, well, Bob in this case, can be logged > in more or less at the same time as he triggered an automatic query of > that url. > For example, he might be buying a DVD at Amazon's. Bob's server might let > him choose whether to supply his plain email address or any variant > thereof, possibly offering to update Sieve scripts while it's at it. > > Is perhaps SCIM, or whatever other framework, nearer to such kind of use > cases? It could be used as a better double-opt-in... (Yes, I'm the one > who asked what's the difference between Webfinger and SCIM on Monday, and > I'm apparently still unclear on that.) > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From ned.freed@mrochek.com Wed Mar 28 16:31:05 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDBF821F85F1 for ; Wed, 28 Mar 2012 16:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tb+awCNAAXvV for ; Wed, 28 Mar 2012 16:31:05 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 2C69A21F85F0 for ; Wed, 28 Mar 2012 16:31:05 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01ODNM5K4I9S00VWRY@mauve.mrochek.com> for apps-discuss@ietf.org; Wed, 28 Mar 2012 16:31:02 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01ODMFECALKG00ZUIL@mauve.mrochek.com>; Wed, 28 Mar 2012 16:30:58 -0700 (PDT) Message-id: <01ODNM5I5WBU00ZUIL@mauve.mrochek.com> Date: Wed, 28 Mar 2012 16:01:06 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Wed, 21 Mar 2012 07:44:40 +0100" <4F6978D8.10605@gmx.de> MIME-version: 1.0 Content-type: TEXT/PLAIN; Format=flowed References: <503575970.11554@cnnic.cn> <4A10020DB6464A0BBA535BF75D21A9D9@LENOVO47E041CF> <9452079D1A51524AA5749AD23E003928094CEB@exch-mbx901.corp.cloudmark.com> <4F6978D8.10605@gmx.de> To: Julian Reschke DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=mauve; t=1332977485; bh=Ugt0doN/Abp4vfRetV2KVLBXHKPXK+2fJBihBnqtQ3E=; h=Cc:Message-id:Date:From:Subject:In-reply-to:MIME-version: Content-type:References:To; b=ROc6pMRL4zAXzQ+XiQc5lFKHf+Q7w+yyO5KhDgfDMGrth3uxt0U+FNUk1GHoiZym7 JUgT3xKRz91uK2Z1NpHIfHYpPOabQTJzsDQgosxKz4nOhrE7wZ+Dabdo0LS4D5OHRI RtVHGyOK1ua1IutzrrrwNj+OLQIUsmoB+b4IQcq0= Cc: Barry Leiba , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Use of RFC 2119, Re: WGLC: draft-ietf-appsawg-about-uri-scheme-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 28 Mar 2012 23:31:06 -0000 > On 2012-03-21 03:34, Barry Leiba wrote: > >> [Relatively] Minor Issues: > >> I'm not so sure about use of RFC2119 language in the IANA Considerations > >> section. You're not really describing interoperability requirements with IANA. > > > > I'm sure. And it's my text -- this is one that Mykyta doesn't like. > > The three MUSTs in there are not directed at IANA, but at people > > writing new registrations. They tell those people what their > > registrations have to look like, and I wanted to use MUST to stress > > that even though this is an FCFS policy, there are requirements > > nonetheless. > > ... > I'm with Murray here. This is something RFC 2119 keywords are not for. The about: URI registration procedure can do whatever it wants to - the usage of RFC 2119 compliance language there is pretty limited and I don't think it will make a significant difference either way. That said ... The notion that this usage was inappropriate is overly pedantic nonsense. Nothing more and nothing less. Both RFC 1123 and RFC 2119 agree: Compliance keywords are used in the context of compliance with a specification. There doesn't have to be a protocol, format, or anything else involved. Now, RFC 2119 does go further and talk about when compliance language needs to be used in order to insure interoperability. But nowhere does it say, or even imply, that interoperability considerations are the sole justification for using these terms. And even if it did, so what? Are you seriously going to try and argue that failure to follow these or any other registration mandates can under no circumstances cause interoperability problems? No, I didn't think so. Besides, we've been using compliance language in registration procedures for a long time. The media types registration procedure is one example; other messages have pointed out various other ones. And as for Alexey's question about who enforces these rules, in the case of registration procedures that would be the registration process itself. The media types registration form won't accept invalid values for many fields. And I refuse to accept violations of the MUSTs and push back on violations of the SHOULDs in media type registrations on a regular basis. And even if this weren't true, I again have to ask: So what? I haven't noticed the Internet Protocol Police arresting any of the MIME scoff-MUSTs out there. In fact I'd have to say that in the case of a registraton process, these keywords are actually carry more weight than they do in protocol specifications. Fail to meet a MUST in a registration document, your registration is rejected. Whereas in protocol implementations often as not they are seen as, well, suggestions. And finally, I thought making registrations processes easier for people to use was something of an overarching goal here. To that end, don't you think highlighting the actual requirements in these document so they stand out at least a little might be somewhat helpful to the casual reader? Ned From paulej@packetizer.com Wed Mar 28 18:49:35 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9663921E80B9 for ; Wed, 28 Mar 2012 18:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.473 X-Spam-Level: X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZjAIdjEPpj5n for ; Wed, 28 Mar 2012 18:49:34 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 9306521E800F for ; Wed, 28 Mar 2012 18:49:34 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q2T1nWMq032500 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 28 Mar 2012 21:49:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1332985774; bh=oiZ4JI/nor5vdcGd4y7dP2DzXgwAM4POobvjL/xmvP0=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; b=UcvVoo5a7EpoG5T095PZjeWzkwbXEM06+40qJZqlbWTlFEKylEql/r7Rp60A+T2Oe pNtZ6teK1erFCvZJuaws6YmbVWCebehOjuMOIAlM28OdAFU1D5zmHSBeAgQATpQGHB lhf3fgq8Grr67J2/W3/cYbsrPndPdBidIlpmoNBE= From: "Paul E. Jones" To: Date: Wed, 28 Mar 2012 21:49:38 -0400 Message-ID: <027801cd0d4e$343dfbe0$9cb9f3a0$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0279_01CD0D2C.AD2CAA00" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac0NTjN3PPuV9i7nTOWIJZJHpX6j7A== Content-Language: en-us Subject: [apps-discuss] Revised webfinger draft (-02) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 29 Mar 2012 01:49:35 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0279_01CD0D2C.AD2CAA00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Folks, I published a revised version of the Webfinger specification based on feedback I've received so far that seems to have general agreement. As requested, I added a change log at the end of the document that I hope will help. The draft is here: http://tools.ietf.org/html/draft-jones-appsawg-webfinger-02 The "diff" tool on that page allows you to quickly see exactly what changed. Paul ------=_NextPart_000_0279_01CD0D2C.AD2CAA00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

I published = a revised version of the Webfinger specification based on feedback = I’ve received so far that seems to  have general = agreement.  As requested, I added a change log at the end of the = document that I hope will help.  The draft is = here:

http= ://tools.ietf.org/html/draft-jones-appsawg-webfinger-02

 

The = “diff” tool on that page allows you to quickly see exactly = what changed.

 

Paul

 

------=_NextPart_000_0279_01CD0D2C.AD2CAA00-- From pbryan@anode.ca Wed Mar 28 22:06:56 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DFBA21F87CF for ; Wed, 28 Mar 2012 22:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43ASCK5Wa15t for ; Wed, 28 Mar 2012 22:06:52 -0700 (PDT) Received: from maple.anode.ca (maple.anode.ca [72.14.183.184]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA5B21F87CC for ; Wed, 28 Mar 2012 22:06:51 -0700 (PDT) Received: from [10.71.9.110] (adsl-75-55-201-218.dsl.pltn13.sbcglobal.net [75.55.201.218]) by maple.anode.ca (Postfix) with ESMTPSA id 746CD647C for ; Thu, 29 Mar 2012 05:06:50 +0000 (UTC) Message-ID: <1332997609.2955.1.camel@neutron> From: "Paul C. Bryan" To: apps-discuss@ietf.org Date: Wed, 28 Mar 2012 22:06:49 -0700 In-Reply-To: <4F72B241.60101@it.aoyama.ac.jp> References: <4F7172FE.6060207@gmx.de> <4F71CD46.5070603@gmx.de> <1332898587.10875.5.camel@neutron> <4F72B241.60101@it.aoyama.ac.jp> Content-Type: multipart/alternative; boundary="=-zf1BvAuwkAmaJxPfBAgB" X-Mailer: Evolution 3.2.2-1 Mime-Version: 1.0 Subject: Re: [apps-discuss] Confusing JSON Pointer X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 29 Mar 2012 05:06:56 -0000 --=-zf1BvAuwkAmaJxPfBAgB Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit On Wed, 2012-03-28 at 15:40 +0900, "Martin J. Dürst" wrote: > Hello Paul, others, > > On 2012/03/28 10:36, Paul C. Bryan wrote: > > On Wed, 2012-03-28 at 08:47 +0900, ì§€ì†¡ì› James Songwon Chi wrote: > > > >> 2012ë…„ 3ì›” 27ì¼ ì˜¤í›„ 11:23, Julian Reschkeë‹˜ì˜ ë§: > >>> On 2012-03-27 15:49, ì§€ì†¡ì› James Songwon Chi wrote: > >>>> 2012ë…„ 3ì›” 27ì¼ ì˜¤í›„ 4:57, Julian Reschkeë‹˜ì˜ ë§: > >>>>> On 2012-03-27 07:22, ì§€ì†¡ì› James Songwon Chi wrote: > > >>>>>> And if my interpretation is wrong, to prevent the similar question, > >>>>>> there should be some examples for this kind. > >>>>>> ... > > Can we please make sure that we add some example(s) and clarify the spec > so that such questions can be avoided in the future? Yes, for sure. > > The intent of the draft is to establish rules for encoding in a JSON > > string or in a URI. Of course, I agree that a URI can in turn be > > expressed in a JSON string, but in this case, URI encoding applies; you > > do not mix-and-match encodings. > > > > > >> By the way, do we really *need another escape* even there are two > >> encodings already? > > > > > > I'm not sure what you mean here. If you encode as URI, presumably all > > valid URI characters are representable without any further escaping in a > > JSON string. > > Can we please make sure this is as clear as possible in the spec? Sure, but I'd appreciate suggestions. Would it be best to outright state what I did above? Paul --=-zf1BvAuwkAmaJxPfBAgB Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit On Wed, 2012-03-28 at 15:40 +0900, "Martin J. Dürst" wrote: 
Hello Paul, others,

On 2012/03/28 10:36, Paul C. Bryan wrote:
> On Wed, 2012-03-28 at 08:47 +0900, 지송원 James Songwon Chi wrote:
>
>> 2012년 3월 27일 오후 11:23, Julian Reschke<julian.reschke@gmx.de>님의 말:
>>> On 2012-03-27 15:49, 지송원 James Songwon Chi wrote:
>>>> 2012년 3월 27일 오후 4:57, Julian Reschke<julian.reschke@gmx.de>님의 말:
>>>>> On 2012-03-27 07:22, 지송원 James Songwon Chi wrote:

>>>>>> And if my interpretation is wrong, to prevent the similar question,
>>>>>> there should be some examples for this kind.
>>>>>> ...

Can we please make sure that we add some example(s) and clarify the spec 
so that such questions can be avoided in the future?

Yes, for sure.

> The intent of the draft is to establish rules for encoding in a JSON
> string or in a URI. Of course, I agree that a URI can in turn be
> expressed in a JSON string, but in this case, URI encoding applies; you
> do not mix-and-match encodings.
>
>
>> By the way, do we really *need another escape* even there are two
>> encodings already?
>
>
> I'm not sure what you mean here. If you encode as URI, presumably all
> valid URI characters are representable without any further escaping in a
> JSON string.

Can we please make sure this is as clear as possible in the spec?

Sure, but I'd appreciate suggestions. Would it be best to outright state what I did above?

Paul --=-zf1BvAuwkAmaJxPfBAgB-- From msk@cloudmark.com Thu Mar 29 04:35:16 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 572FC21F89B8 for ; Thu, 29 Mar 2012 04:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.593 X-Spam-Level: X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-ZzEMCb7o50 for ; Thu, 29 Mar 2012 04:35:14 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 725D021F89AB for ; Thu, 29 Mar 2012 04:35:14 -0700 (PDT) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Thu, 29 Mar 2012 04:35:14 -0700 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Thread-Topic: [apps-discuss] Revised webfinger draft (-02) Thread-Index: Ac0NTjN3PPuV9i7nTOWIJZJHpX6j7AAUZkqg Date: Thu, 29 Mar 2012 11:35:14 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280C0BFA@exch-mbx901.corp.cloudmark.com> References: <027801cd0d4e$343dfbe0$9cb9f3a0$@packetizer.com> In-Reply-To: <027801cd0d4e$343dfbe0$9cb9f3a0$@packetizer.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.129.23.154] Content-Type: multipart/alternative; boundary="_000_9452079D1A51524AA5749AD23E0039280C0BFAexchmbx901corpclo_" MIME-Version: 1.0 Subject: Re: [apps-discuss] Revised webfinger draft (-02) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 29 Mar 2012 11:35:16 -0000 --_000_9452079D1A51524AA5749AD23E0039280C0BFAexchmbx901corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable To the working group, This has been hovering outside APPSAWG for two meetings now. Is APPSAWG th= e right place to process it? That is, should we bring it in as a working g= roup document? Or would it be better done through the ISE, or perhaps in s= ome other working group? -MSK From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = On Behalf Of Paul E. Jones Sent: Wednesday, March 28, 2012 6:50 PM To: apps-discuss@ietf.org Subject: [apps-discuss] Revised webfinger draft (-02) Folks, I published a revised version of the Webfinger specification based on feedb= ack I've received so far that seems to have general agreement. As request= ed, I added a change log at the end of the document that I hope will help. = The draft is here: http://tools.ietf.org/html/draft-jones-appsawg-webfinger-02 The "diff" tool on that page allows you to quickly see exactly what changed= . Paul --_000_9452079D1A51524AA5749AD23E0039280C0BFAexchmbx901corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

To the working group,<= o:p>

 

This has been hovering= outside APPSAWG for two meetings now.  Is APPSAWG the right place to = process it?  That is, should we bring it in as a working group documen= t?  Or would it be better done through the ISE, or perhaps in some other working group?

 

-MSK=

 

From: apps-dis= cuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Paul E. Jones
Sent: Wednesday, March 28, 2012 6:50 PM
To: apps-discuss@ietf.org
Subject: [apps-discuss] Revised webfinger draft (-02)

 

Folks,

 

I published a revised version of the Webfinger speci= fication based on feedback I’ve received so far that seems to  h= ave general agreement.  As requested, I added a change log at the end = of the document that I hope will help.  The draft is here:

http://tools.ietf.org/html/draft-jones-appsawg-webfinge= r-02

 

The “diff” tool on that page allows you = to quickly see exactly what changed.

 

Paul

 

--_000_9452079D1A51524AA5749AD23E0039280C0BFAexchmbx901corpclo_-- From vesely@tana.it Thu Mar 29 04:58:48 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E79D221F89F6 for ; Thu, 29 Mar 2012 04:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mu4+haxHa9VB for ; Thu, 29 Mar 2012 04:58:47 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE1A21F89F0 for ; Thu, 29 Mar 2012 04:58:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1333022302; bh=RFOdkENSn6zPpFrk034yLmr4Yf9CeLZ/YJnPt7kbuKw=; l=417; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=ejGaBY9BGV8P4FmTLcVnXJx41KwM6cc+7eAPcCZBN+xJTZdybBw7UA5lgwWyTbj3N T6sORUgGipQcHTVOm2iBqkKj9zgXV75c6kToEtHjJpEOM5vlT4Z9ZR52D2egPwSZ1U aP4yOcNqWcqCtyLKQ0ZFYqZ1gYZujaZpYSFBrCn0= Received: from [130.129.20.64] (dhcp-1440.meeting.ietf.org [130.129.20.64]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Thu, 29 Mar 2012 13:58:02 +0200 id 00000000005DC045.000000004F744E52.00003474 Message-ID: <4F744E1D.6080101@tana.it> Date: Thu, 29 Mar 2012 13:57:17 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <053201cd0b5d$c08c80f0$41a582d0$@packetizer.com> <20120326150556.GC3557@mail.yitter.info> <20120327084709.GB11491@mail.yitter.info> <00ac01cd0c34$cfc96f10$6f5c4d30$@packetizer.com> <00d201cd0c3a$b3672410$1a356c30$@packetizer.com> <4F72F5C0.70106@tana.it> <024101cd0d30$06d70ac0$14852040$@packetizer.com> In-Reply-To: <024101cd0d30$06d70ac0$14852040$@packetizer.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] What auth server supplies email addresses? Was webfinger discussion X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 29 Mar 2012 11:58:49 -0000 On Thu 29/Mar/2012 13:55:12 +0200 Paul E. Jones wrote: > > Get an email address from what ID? A Webfinger "acct" URI? In general, the opaque token would be kind-of-claim @ claim-provider >> >> That implies the address is known. Couldn't one use just >> >> http://example.org/.well-known/finger/{opaque-token} >> >> and, possibly, >> >> http://example.org/.well-known/finger/{opaque-token}/email-addr? From msk@cloudmark.com Thu Mar 29 06:56:56 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A922F21F8973 for ; Thu, 29 Mar 2012 06:56:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.594 X-Spam-Level: X-Spam-Status: No, score=-102.594 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nug1yaRbcChy for ; Thu, 29 Mar 2012 06:56:55 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id 2D3D621F8BA5 for ; Thu, 29 Mar 2012 06:56:55 -0700 (PDT) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Thu, 29 Mar 2012 06:56:54 -0700 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Thread-Topic: [apps-discuss] Revised webfinger draft (-02) Thread-Index: Ac0NTjN3PPuV9i7nTOWIJZJHpX6j7AAUZkqgAAT2Q5A= Date: Thu, 29 Mar 2012 13:56:53 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280C0FE9@exch-mbx901.corp.cloudmark.com> References: <027801cd0d4e$343dfbe0$9cb9f3a0$@packetizer.com> <9452079D1A51524AA5749AD23E0039280C0BFA@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E0039280C0BFA@exch-mbx901.corp.cloudmark.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.129.64.89] Content-Type: multipart/alternative; boundary="_000_9452079D1A51524AA5749AD23E0039280C0FE9exchmbx901corpclo_" MIME-Version: 1.0 Subject: Re: [apps-discuss] Revised webfinger draft (-02) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 29 Mar 2012 13:56:56 -0000 --_000_9452079D1A51524AA5749AD23E0039280C0FE9exchmbx901corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Having talked with Barry now, an amended question: Would this work better fit in another working group like OAuth (which has i= ts own interest and concerns in webfinger), or perhaps in its own working g= roup? It may well be that it's too big to fit in APPSAWG's charter for sma= ller work items. -MSK From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = On Behalf Of Murray S. Kucherawy Sent: Thursday, March 29, 2012 4:35 AM To: apps-discuss@ietf.org Subject: Re: [apps-discuss] Revised webfinger draft (-02) To the working group, This has been hovering outside APPSAWG for two meetings now. Is APPSAWG th= e right place to process it? That is, should we bring it in as a working g= roup document? Or would it be better done through the ISE, or perhaps in s= ome other working group? -MSK From: apps-discuss-bounces@ietf.org [= mailto:apps-discuss-bounces@ietf.org] On Behalf Of Paul E. Jones Sent: Wednesday, March 28, 2012 6:50 PM To: apps-discuss@ietf.org Subject: [apps-discuss] Revised webfinger draft (-02) Folks, I published a revised version of the Webfinger specification based on feedb= ack I've received so far that seems to have general agreement. As request= ed, I added a change log at the end of the document that I hope will help. = The draft is here: http://tools.ietf.org/html/draft-jones-appsawg-webfinger-02 The "diff" tool on that page allows you to quickly see exactly what changed= . Paul --_000_9452079D1A51524AA5749AD23E0039280C0FE9exchmbx901corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Having talked with Bar= ry now, an amended question:

Would this work better fit in another working group like OAuth (which has i= ts own interest and concerns in webfinger), or perhaps in its own working g= roup?  It may well be that it’s too big to fit in APPSAWG’= s charter for smaller work items.

 

-MSK=

 

From: apps-dis= cuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Murray S. Kucherawy
Sent: Thursday, March 29, 2012 4:35 AM
To: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Revised webfinger draft (-02)=

 

To the working group,<= o:p>

 

This has been hovering= outside APPSAWG for two meetings now.  Is APPSAWG the right place to = process it?  That is, should we bring it in as a working group documen= t?  Or would it be better done through the ISE, or perhaps in some other working group?

 

-MSK=

 

--_000_9452079D1A51524AA5749AD23E0039280C0FE9exchmbx901corpclo_-- From lear@cisco.com Thu Mar 29 07:11:55 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F26321E80AE for ; Thu, 29 Mar 2012 07:11:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.537 X-Spam-Level: X-Spam-Status: No, score=-110.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZxxaTg-zuaYO for ; Thu, 29 Mar 2012 07:11:55 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id A087121E8131 for ; Thu, 29 Mar 2012 07:11:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=204; q=dns/txt; s=iport; t=1333030313; x=1334239913; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=TMejWHZVte4ixmSgEwUj4oQzwGoi0slpWhDXlZsmFFI=; b=DEoHMPwZF8ilZUPg3+VOojTyEDdHkPb431pPSXsv9LcHEWzm1erkXH/6 BnUN5cIctq1v8J9eoYfgzd0hLJeXCeMzmL+iFsobPMrktIi4yMAHzGR5J ARmtxV5Am0fqzhyhUQwV9gSsfoEyieB9FIKoHNLyvJ7V9VIH/Mfe3vy3x 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuIKAKdsdE+Q/khM/2dsb2JhbABEhUOyOQEDAQOBDYEHggsBBQEBDwEQSwo2AgUWCwILAwIBAgEVKgwNCAEBHodoC5pJgSeNCJIVBIEvjliBGASVYY5GgWiCaQ X-IronPort-AV: E=Sophos;i="4.73,668,1325462400"; d="scan'208";a="69659927" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 29 Mar 2012 14:11:51 +0000 Received: from ams3-vpn-dhcp4459.cisco.com (ams3-vpn-dhcp4459.cisco.com [10.61.81.106]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2TEBpnp030652 for ; Thu, 29 Mar 2012 14:11:51 GMT Message-ID: <4F746DA9.7020706@cisco.com> Date: Thu, 29 Mar 2012 16:11:53 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "apps-discuss@ietf.org" X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [apps-discuss] scim mailing list X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 29 Mar 2012 14:11:55 -0000 It was pointed out that the slides for the scim BoF did not have a mailing list link, and that this would be useful to have. Here is the link: https://www.ietf.org/mailman/listinfo/scim Eliot From eran@hueniverse.com Thu Mar 29 09:06:19 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60BBD21E81AB for ; Thu, 29 Mar 2012 09:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NYqX-M8rWg2B for ; Thu, 29 Mar 2012 09:06:17 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id 9960921E816B for ; Thu, 29 Mar 2012 09:06:10 -0700 (PDT) Received: (qmail 15633 invoked from network); 29 Mar 2012 16:06:10 -0000 Received: from unknown (HELO p3plex2out02.prod.phx3.secureserver.net) (184.168.131.14) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 29 Mar 2012 16:06:10 -0000 Received: from P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) by p3plex2out02.prod.phx3.secureserver.net with bizsmtp id rU621i0050SoFT401U6A15; Thu, 29 Mar 2012 09:06:10 -0700 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 29 Mar 2012 09:03:33 -0700 From: Eran Hammer To: "Murray S. Kucherawy" , "apps-discuss@ietf.org" Date: Thu, 29 Mar 2012 09:03:24 -0700 Thread-Topic: [apps-discuss] Revised webfinger draft (-02) Thread-Index: Ac0NTjN3PPuV9i7nTOWIJZJHpX6j7AAUZkqgAAT2Q5AABFAtMA== Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453B42BB4F4@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <027801cd0d4e$343dfbe0$9cb9f3a0$@packetizer.com> <9452079D1A51524AA5749AD23E0039280C0BFA@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280C0FE9@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E0039280C0FE9@exch-mbx901.corp.cloudmark.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723453B42BB4F4P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [apps-discuss] Revised webfinger draft (-02) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 29 Mar 2012 16:06:19 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723453B42BB4F4P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This clearly does not belong in the Security area or the OAuth working grou= p. I would strongly warn that moving this effort into any WG requires very car= eful work on the charter as historically there has been very little consens= us and success in agreeing on what problems we are trying to solve. RFC 641= 5 was the end of a 5+ years process across multiple standard bodies includi= ng the IETF, W3C, OASIS, and the OpenID Foundation. This has proved a reall= y hard problem to *define*. EH From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = On Behalf Of Murray S. Kucherawy Sent: Thursday, March 29, 2012 6:57 AM To: apps-discuss@ietf.org Subject: Re: [apps-discuss] Revised webfinger draft (-02) Having talked with Barry now, an amended question: Would this work better fit in another working group like OAuth (which has i= ts own interest and concerns in webfinger), or perhaps in its own working g= roup? It may well be that it's too big to fit in APPSAWG's charter for sma= ller work items. -MSK From: apps-discuss-bounces@ietf.org [= mailto:apps-discuss-bounces@ietf.org] On Behalf Of Murray S. Kucherawy Sent: Thursday, March 29, 2012 4:35 AM To: apps-discuss@ietf.org Subject: Re: [apps-discuss] Revised webfinger draft (-02) To the working group, This has been hovering outside APPSAWG for two meetings now. Is APPSAWG th= e right place to process it? That is, should we bring it in as a working g= roup document? Or would it be better done through the ISE, or perhaps in s= ome other working group? -MSK From: apps-discuss-bounces@ietf.org [= mailto:apps-discuss-bounces@ietf.org] On Behalf Of Paul E. Jones Sent: Wednesday, March 28, 2012 6:50 PM To: apps-discuss@ietf.org Subject: [apps-discuss] Revised webfinger draft (-02) Folks, I published a revised version of the Webfinger specification based on feedb= ack I've received so far that seems to have general agreement. As request= ed, I added a change log at the end of the document that I hope will help. = The draft is here: http://tools.ietf.org/html/draft-jones-appsawg-webfinger-02 The "diff" tool on that page allows you to quickly see exactly what changed= . Paul --_000_90C41DD21FB7C64BB94121FBBC2E723453B42BB4F4P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This clearly does not belong in the Security area or the OAut= h working group.

 

I would strongly warn that moving this effort into any W= G requires very careful work on the charter as historically there has been = very little consensus and success in agreeing on what problems we are tryin= g to solve. RFC 6415 was the end of a 5+ years process across multiple stan= dard bodies including the IETF, W3C, OASIS, and the OpenID Foundation. This= has proved a really hard problem to *define*.

=

 =

EH=

 

From: apps-discuss-bounces@= ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Murray = S. Kucherawy
Sent: Thursday, March 29, 2012 6:57 AM
To:= apps-discuss@ietf.org
Subject: Re: [apps-discuss] Revised webfin= ger draft (-02)

=  

Having t= alked with Barry now, an amended question:

Would this work better fi= t in another working group like OAuth (which has its own interest and conce= rns in webfinger), or perhaps in its own working group?  It may well b= e that it’s too big to fit in APPSAWG’s charter for smaller wor= k items.

 

-MSK

 

From: apps-discuss-bo= unces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Murray S. = Kucherawy
Sent: Thursday, March 29, 2012 4:35 AM
To: apps-discuss@ietf.org
Subj= ect: Re: [apps-discuss] Revised webfinger draft (-02)=

 

To the working group,

 

This has been hove= ring outside APPSAWG for two meetings now.  Is APPSAWG the right place= to process it?  That is, should we bring it in as a working group doc= ument?  Or would it be better done through the ISE, or perhaps in some= other working group?

 

-MSK

 

<= p class=3DMsoNormal>From: ap= ps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Paul E= . Jones
Sent: Wednesday, March 28, 2012 6:50 PM
To: apps-discuss@ietf.org
Subje= ct: [apps-discuss] Revised webfinger draft (-02)

<= /div>

 

F= olks,

 

I published a revised version of the Webfinger specification based = on feedback I’ve received so far that seems to  have general agr= eement.  As requested, I added a change log at the end of the document= that I hope will help.  The draft is here:

http://tools.ietf.org/html/draft-jones-appsawg-webfinger-02<= /o:p>

 

The= “diff” tool on that page allows you to quickly see exactly wha= t changed.

 

Paul

 

<= /div>
= --_000_90C41DD21FB7C64BB94121FBBC2E723453B42BB4F4P3PW5EX1MB01E_-- From eran@hueniverse.com Thu Mar 29 09:12:43 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BA3B21F8718 for ; Thu, 29 Mar 2012 09:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.231 X-Spam-Level: X-Spam-Status: No, score=-2.231 tagged_above=-999 required=5 tests=[AWL=-0.232, BAYES_00=-2.599, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M7jb0ZTIlGdp for ; Thu, 29 Mar 2012 09:12:42 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id B6FC921F872F for ; Thu, 29 Mar 2012 09:12:41 -0700 (PDT) Received: (qmail 323 invoked from network); 29 Mar 2012 16:12:41 -0000 Received: from unknown (HELO p3plex2out02.prod.phx3.secureserver.net) (184.168.131.14) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 29 Mar 2012 16:12:41 -0000 Received: from P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) by p3plex2out02.prod.phx3.secureserver.net with bizsmtp id rUCd1i0030U5vnL01UCh9R; Thu, 29 Mar 2012 09:12:41 -0700 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Thu, 29 Mar 2012 09:12:19 -0700 From: Eran Hammer To: "Paul E. Jones" , 'James M Snell' Date: Thu, 29 Mar 2012 09:12:11 -0700 Thread-Topic: [apps-discuss] Webfinger discussion Thread-Index: AQEg174HJISLlkWDD0VVkXSpmVuZQwKMareXAWwgTx8BwaaRJQGG5wouAU3B5AYBuFTkWgIDrH2Cl3ZNHSCAATd/IA== Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453B42BB4F8@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <053201cd0b5d$c08c80f0$41a582d0$@packetizer.com> <20120326150556.GC3557@mail.yitter.info> <20120327084709.GB11491@mail.yitter.info> <00ac01cd0c34$cfc96f10$6f5c4d30$@packetizer.com> <00d201cd0c3a$b3672410$1a356c30$@packetizer.com> <023901cd0d2c$aa665e10$ff331a30$@packetizer.com> In-Reply-To: <023901cd0d2c$aa665e10$ff331a30$@packetizer.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Webfinger discussion X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 29 Mar 2012 16:12:43 -0000 RFC 6415 (host-meta) was the end of a long evolution of discovery ideas. I = would strongly caution against throwing it away and starting from scratch g= iven the amount of experience and balance that was put into it. There are e= asy things we can do to make it easier to use and more efficient, without l= osing its main architectural benefits (caching, simplicity, ease of deploym= ent, efficiency in templates, security, flexible schema, etc.). In the past I've proposed adding query parameters to the endpoint to allow = for direct retrieval of information without having to parse the document. I= have also suggested moving away from XRD to JRD as the primary format. BTW= , XRD has nothing to do with XRI and all to do with HTTP Link relations - s= o people should get over their bias and hate for XRI and give this work the= benefit of the doubt. The key to this work has always been adoption. These protocols are useless = without large companies (primarily email providers as currently proposed) s= upporting it, which was a significant driving force in shaping the protocol= based on what these companies were able and willing to deploy. For example, Yahoo was a strong supporter of the template mechanism because= it enable them to deploy a single static file that provided information ab= out all their users for the purpose of address book discovery. EH > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss- > bounces@ietf.org] On Behalf Of Paul E. Jones > Sent: Wednesday, March 28, 2012 2:50 PM > To: 'James M Snell' > Cc: apps-discuss@ietf.org > Subject: Re: [apps-discuss] Webfinger discussion >=20 > James, >=20 > I really like this idea. It makes an attempt to short-cut some of the > procedures, very much in line with what the "resource" parameter does in > Section 4.2 of the Webfinger draft. I don't have a particular love for t= he using > MD5, preferring something like this: >=20 > GET /.well- > known/webfinger?resource=3Dacct%3Abob%40example.com&rel=3Dblog > HTTP/1.1 >=20 > Since any reply might have multiple links, then the 204 reply including l= inks > would likely be necessary. Using 302 would not be right, since that has = a > different meaning: the client would go to Location trying to resolve the > original request. A 204 with any number of Link headers would be good. >=20 > Using the resource parameter means we make a query and get a JRD or XRD > document. What we cannot do is query for one specific type of content. >=20 > Changing Webfinger so drastically is a challenge since Webfinger builds o= n > RFC 6415. But, I do like the idea of querying for a very specific value l= ike this: >=20 > GET /.well-known/host- > meta.json?resource=3Dacct%3Abob%40example.com&rel=3Dblog HTTP/1.1 >=20 > Perhaps this might return a reply like this: >=20 > HTTP/1.1 204 No Content > Link: ; rel=3D"blog" >=20 > A challenge with this, though, is that it means the application has to de= al with > two different formats. Either JRD/XRD or an HTTP header with Links. >=20 > We could introduce this and make it mandatory if the resource parameter i= s > supported. However, would it make the client-side code simpler? Support > for the "resource" parameter is already optional. (We could make it > mandatory, but I did get pushback on that.) >=20 > Paul >=20 > > -----Original Message----- > > From: James M Snell [mailto:jasnell@gmail.com] > > Sent: Tuesday, March 27, 2012 2:19 PM > > To: Paul E. Jones > > Cc: Andrew Sullivan; apps-discuss@ietf.org > > Subject: Re: [apps-discuss] Webfinger discussion > > > > They are rather technical in nature and speak to the overall operation > > of the protocol. I've written up a detailed version of my feedback > > here [1] > > > > [1] > > http://chmod777self.blogspot.com/2012/03/thoughts-on-webfinger.html > > > > The summary version is this: I believe we can make this even simpler > > without sacrificing basic operation by saying simply: > > > > If I want to know about user "bob@example.org", send a GET request to= : > > http://example.org/.well-known/finger/{md5(acct:bob@example.org)} > and > > see what I get back. > > > > The requirement to use XRD/JRD and first look up information about the > > LRDD service in host-meta is quite unnecessary. Also note that the ID > > is hashed in the request URI for privacy/security purposes... > > > > We can expand on that basic idea further to say: > > > > If I want to know if "bob@example.org" has a "blog" and where it is > > located, > > I could simply send a request to: > > http://example.org/.well- > > known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/blog > > > > and the server can respond with a redirect to the proper location: > > > > HTTP/1.1 302 Found > > Location: http://blogs.example.org/bob > > > > The "/blog" portion of the request URI specifies a Link rel... if I > > want to discover some other type of service... say, the users profile > > or avatar, I simply link the different rel attribute value there.. > > e.g. > > > > http://example.org/.well- > > known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/avatar > > http://example.org/.well- > > known/finger/f49c533fa0f0bc7ee9cc8c88902302ba/profile > > > > If there are multiple links for a particular rel, the server can > > respond with a 300 Multiple Options response. > > > > The point is that requiring XRD/JRD isn't actually necessary, and > > requiring the initial host metadata step isn't required also. > > > > Requiring CORS is also isn't necessary. > > > > Anyway, that's the basic rundown. > > > > - James > > > > On Tue, Mar 27, 2012 at 9:57 AM, Paul E. Jones > > wrote: > > > James, > > > > > > If the other items are editorial, perhaps just direct them to me. > > > If > > they are items that others might want to weigh in on, then this list > > is the appropriate venue. > > > > > > Paul > > > > > >> -----Original Message----- > > >> From: James M Snell [mailto:jasnell@gmail.com] > > >> Sent: Tuesday, March 27, 2012 12:39 PM > > >> To: Paul E. Jones > > >> Cc: Andrew Sullivan; apps-discuss@ietf.org > > >> Subject: Re: [apps-discuss] Webfinger discussion > > >> > > >> To be fair, there are ways of dealing with the potential for > > >> security leaks of this nature with WebFinger that did not really > > >> exist with the original Finger protocol. OAuth 2, for instance. A > > >> WebFinger endpoint could choose to serve up only the most basic > > >> static information to unauthenticated requesters, but then provide > > >> a means for a requester to authenticate and request permission from > > >> the target user or provider to acquire additional information as > > >> part of > > the response. > > >> > > >> On a side note to Paul: I did have some additional general comments > > >> on the WebFinger spec itself, I wanted to ask where such comments > > >> would be best directed for discussion. > > >> > > >> - James > > >> > > >> On Tue, Mar 27, 2012 at 9:15 AM, Paul E. Jones > > >> > > >> wrote: > > >> > I agree it would be useful to add text about sharing information > > >> > that might be dynamic in nature (e.g., current user location). > > >> > > > >> > We'll add text along those lines to the next draft. Any other > > >> > security considerations we should note? > > >> > > > >> > Paul > > >> > > > >> >> -----Original Message----- > > >> >> From: apps-discuss-bounces@ietf.org > > >> >> [mailto:apps-discuss-bounces@ietf.org] > > >> >> On Behalf Of Andrew Sullivan > > >> >> Sent: Tuesday, March 27, 2012 4:47 AM > > >> >> To: apps-discuss@ietf.org > > >> >> Subject: Re: [apps-discuss] Webfinger discussion > > >> >> > > >> >> On Mon, Mar 26, 2012 at 02:31:30PM -0400, Bob Wyman wrote: > > >> >> > > >> >> > un-recommended!). If people did, in fact, use WebFinger to > > >> >> > record such stuff, the concerns you mentioned would be relevant= . > > >> >> > Thus, it might make sense for the Security Considerations > > >> >> > section to suggest that one should think carefully before > > >> >> > using WebFinger to provide such dynamic > > >> >> information. > > >> >> > > >> >> Right, that's most of what I was trying to say. I do have a > > >> >> concern that collecting a bunch of different information about a > > >> >> given person and linking it together in a single, easy to access > > >> >> repository has some potential security side effects (not just > > >> >> privacy ones, but those too, of > > >> >> course) that are not clearly highlighted in the security > > >> considerations. > > >> >> I suppose one could argue that facebook's (or pick your poison) > > >> >> user population shows nobody cares about that, but I think it > > >> >> would still be good to have some observations about those effects= . > > >> >> > > >> >> Best, > > >> >> > > >> >> A > > >> >> > > >> >> -- > > >> >> Andrew Sullivan > > >> >> ajs@anvilwalrusden.com > > >> >> _______________________________________________ > > >> >> apps-discuss mailing list > > >> >> apps-discuss@ietf.org > > >> >> https://www.ietf.org/mailman/listinfo/apps-discuss > > >> > > > >> > _______________________________________________ > > >> > apps-discuss mailing list > > >> > apps-discuss@ietf.org > > >> > https://www.ietf.org/mailman/listinfo/apps-discuss > > > >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From msk@cloudmark.com Thu Mar 29 09:18:16 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E2F821E81B7 for ; Thu, 29 Mar 2012 09:18:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.595 X-Spam-Level: X-Spam-Status: No, score=-102.595 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZeiIrxpB1HX for ; Thu, 29 Mar 2012 09:18:12 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id CDEDD21F8899 for ; Thu, 29 Mar 2012 09:18:12 -0700 (PDT) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Thu, 29 Mar 2012 09:18:12 -0700 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Thread-Topic: [apps-discuss] Revised webfinger draft (-02) Thread-Index: Ac0NTjN3PPuV9i7nTOWIJZJHpX6j7AAUZkqgAAT2Q5AABFAtMAAAmxdw Date: Thu, 29 Mar 2012 16:18:11 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280C132B@exch-mbx901.corp.cloudmark.com> References: <027801cd0d4e$343dfbe0$9cb9f3a0$@packetizer.com> <9452079D1A51524AA5749AD23E0039280C0BFA@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280C0FE9@exch-mbx901.corp.cloudmark.com> <90C41DD21FB7C64BB94121FBBC2E723453B42BB4F4@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453B42BB4F4@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.129.23.154] Content-Type: multipart/alternative; boundary="_000_9452079D1A51524AA5749AD23E0039280C132Bexchmbx901corpclo_" MIME-Version: 1.0 Subject: Re: [apps-discuss] Revised webfinger draft (-02) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 29 Mar 2012 16:18:16 -0000 --_000_9452079D1A51524AA5749AD23E0039280C132Bexchmbx901corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable That sounds like a mighty strong statement that, in any case, it's not appr= opriate for APPSAWG. Perhaps the proponents should request a non-WG list to talk about it for a = while to let the problem definition congeal for a while, and then request a= working group when a charter falls out of that. -MSK From: Eran Hammer [mailto:eran@hueniverse.com] Sent: Thursday, March 29, 2012 9:03 AM To: Murray S. Kucherawy; apps-discuss@ietf.org Subject: RE: [apps-discuss] Revised webfinger draft (-02) This clearly does not belong in the Security area or the OAuth working grou= p. I would strongly warn that moving this effort into any WG requires very car= eful work on the charter as historically there has been very little consens= us and success in agreeing on what problems we are trying to solve. RFC 641= 5 was the end of a 5+ years process across multiple standard bodies includi= ng the IETF, W3C, OASIS, and the OpenID Foundation. This has proved a reall= y hard problem to *define*. EH From: apps-discuss-bounces@ietf.org [= mailto:apps-discuss-bounces@ietf.org] On Behalf Of Murray S. Kucherawy Sent: Thursday, March 29, 2012 6:57 AM To: apps-discuss@ietf.org Subject: Re: [apps-discuss] Revised webfinger draft (-02) Having talked with Barry now, an amended question: Would this work better fit in another working group like OAuth (which has i= ts own interest and concerns in webfinger), or perhaps in its own working g= roup? It may well be that it's too big to fit in APPSAWG's charter for sma= ller work items. -MSK From: apps-discuss-bounces@ietf.org [= mailto:apps-discuss-bounces@ietf.org] On Behalf Of Murray S. Kucherawy Sent: Thursday, March 29, 2012 4:35 AM To: apps-discuss@ietf.org Subject: Re: [apps-discuss] Revised webfinger draft (-02) To the working group, This has been hovering outside APPSAWG for two meetings now. Is APPSAWG th= e right place to process it? That is, should we bring it in as a working g= roup document? Or would it be better done through the ISE, or perhaps in s= ome other working group? -MSK From: apps-discuss-bounces@ietf.org [= mailto:apps-discuss-bounces@ietf.org] On Behalf Of Paul E. Jones Sent: Wednesday, March 28, 2012 6:50 PM To: apps-discuss@ietf.org Subject: [apps-discuss] Revised webfinger draft (-02) Folks, I published a revised version of the Webfinger specification based on feedb= ack I've received so far that seems to have general agreement. As request= ed, I added a change log at the end of the document that I hope will help. = The draft is here: http://tools.ietf.org/html/draft-jones-appsawg-webfinger-02 The "diff" tool on that page allows you to quickly see exactly what changed= . Paul --_000_9452079D1A51524AA5749AD23E0039280C132Bexchmbx901corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

That sounds like a mig= hty strong statement that, in any case, it’s not appropriate for APPS= AWG.

 

Perhaps the proponents= should request a non-WG list to talk about it for a while to let the probl= em definition congeal for a while, and then request a working group when a = charter falls out of that.

 

-MSK=

 

From: Eran Ham= mer [mailto:eran@hueniverse.com]
Sent: Thursday, March 29, 2012 9:03 AM
To: Murray S. Kucherawy; apps-discuss@ietf.org
Subject: RE: [apps-discuss] Revised webfinger draft (-02)=

 

This clearly does not = belong in the Security area or the OAuth working group.

 

I would strongly warn = that moving this effort into any WG requires very careful work on the chart= er as historically there has been very little consensus and success in agre= eing on what problems we are trying to solve. RFC 6415 was the end of a 5+ years process across multiple s= tandard bodies including the IETF, W3C, OASIS, and the OpenID Foundation. T= his has proved a really hard problem to *define*.<= /p>

 

EH

 

 

Having talked with Bar= ry now, an amended question:

Would this work better fit in another working group like OAuth (which has i= ts own interest and concerns in webfinger), or perhaps in its own working g= roup?  It may well be that it’s too big to fit in APPSAWG’= s charter for smaller work items.

 

-MSK=

 

 

To the working group,<= o:p>

 

This has been hovering= outside APPSAWG for two meetings now.  Is APPSAWG the right place to = process it?  That is, should we bring it in as a working group documen= t?  Or would it be better done through the ISE, or perhaps in some other working group?

 

-MSK=

 
--_000_9452079D1A51524AA5749AD23E0039280C132Bexchmbx901corpclo_-- From eran@hueniverse.com Thu Mar 29 09:47:51 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 723D121F895E for ; Thu, 29 Mar 2012 09:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZumB7nj1uT8 for ; Thu, 29 Mar 2012 09:47:46 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 6290921F895A for ; Thu, 29 Mar 2012 09:47:46 -0700 (PDT) Received: (qmail 23349 invoked from network); 29 Mar 2012 16:47:41 -0000 Received: from unknown (HELO p3plex2out01.prod.phx3.secureserver.net) (184.168.131.12) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 29 Mar 2012 16:47:41 -0000 Received: from P3PW5EX1HT004.EX1.SECURESERVER.NET ([72.167.180.46]) by p3plex2out01.prod.phx3.secureserver.net with bizsmtp id rUnh1i00310TkE001UnhvF; Thu, 29 Mar 2012 09:47:41 -0700 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT004.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Thu, 29 Mar 2012 09:47:05 -0700 From: Eran Hammer To: "Murray S. Kucherawy" , "apps-discuss@ietf.org" Date: Thu, 29 Mar 2012 09:46:57 -0700 Thread-Topic: [apps-discuss] Revised webfinger draft (-02) Thread-Index: Ac0NTjN3PPuV9i7nTOWIJZJHpX6j7AAUZkqgAAT2Q5AABFAtMAAAmxdwAACqzvA= Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453B42BB50B@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <027801cd0d4e$343dfbe0$9cb9f3a0$@packetizer.com> <9452079D1A51524AA5749AD23E0039280C0BFA@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280C0FE9@exch-mbx901.corp.cloudmark.com> <90C41DD21FB7C64BB94121FBBC2E723453B42BB4F4@P3PW5EX1MB01.EX1.SECURESERVER.NET> <9452079D1A51524AA5749AD23E0039280C132B@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E0039280C132B@exch-mbx901.corp.cloudmark.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723453B42BB50BP3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [apps-discuss] Revised webfinger draft (-02) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 29 Mar 2012 16:47:51 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723453B42BB50BP3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It would be appropriate for APPSAWG if the scope is narrowly defined as add= ing a few enhancements to RFC 6415 (which *is* what the current draft attem= pts to do, even though its prose might sounds grander). But in the context = of the recent OAuth WG meeting discussing a competing foundation (SWD), a n= ew WG seems to be in order. My concern is that we are reaching a point (or maybe pass it) where progres= sing a work to standards track RFC status no longer translate into requirin= g new work to explain why it cannot build on top of the published standard.= If this body throws away work as recent as October 2011 just because it's = more convenient for some to start from scratch, I don't see why anyone woul= d bother go through the significant cost and effort of getting it published= here in the first place. EH From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = On Behalf Of Murray S. Kucherawy Sent: Thursday, March 29, 2012 9:18 AM To: apps-discuss@ietf.org Subject: Re: [apps-discuss] Revised webfinger draft (-02) That sounds like a mighty strong statement that, in any case, it's not appr= opriate for APPSAWG. Perhaps the proponents should request a non-WG list to talk about it for a = while to let the problem definition congeal for a while, and then request a= working group when a charter falls out of that. -MSK From: Eran Hammer [mailto:eran@hueniverse.com] Sent: Thursday, March 29, 2012 9:03 AM To: Murray S. Kucherawy; apps-discuss@ietf.org Subject: RE: [apps-discuss] Revised webfinger draft (-02) This clearly does not belong in the Security area or the OAuth working grou= p. I would strongly warn that moving this effort into any WG requires very car= eful work on the charter as historically there has been very little consens= us and success in agreeing on what problems we are trying to solve. RFC 641= 5 was the end of a 5+ years process across multiple standard bodies includi= ng the IETF, W3C, OASIS, and the OpenID Foundation. This has proved a reall= y hard problem to *define*. EH From: apps-discuss-bounces@ietf.org [= mailto:apps-discuss-bounces@ietf.org] On Behalf Of Murray S. Kucherawy Sent: Thursday, March 29, 2012 6:57 AM To: apps-discuss@ietf.org Subject: Re: [apps-discuss] Revised webfinger draft (-02) Having talked with Barry now, an amended question: Would this work better fit in another working group like OAuth (which has i= ts own interest and concerns in webfinger), or perhaps in its own working g= roup? It may well be that it's too big to fit in APPSAWG's charter for sma= ller work items. -MSK From: apps-discuss-bounces@ietf.org [= mailto:apps-discuss-bounces@ietf.org] On Behalf Of Murray S. Kucherawy Sent: Thursday, March 29, 2012 4:35 AM To: apps-discuss@ietf.org Subject: Re: [apps-discuss] Revised webfinger draft (-02) To the working group, This has been hovering outside APPSAWG for two meetings now. Is APPSAWG th= e right place to process it? That is, should we bring it in as a working g= roup document? Or would it be better done through the ISE, or perhaps in s= ome other working group? -MSK From: apps-discuss-bounces@ietf.org [= mailto:apps-discuss-bounces@ietf.org] On Behalf Of Paul E. Jones Sent: Wednesday, March 28, 2012 6:50 PM To: apps-discuss@ietf.org Subject: [apps-discuss] Revised webfinger draft (-02) Folks, I published a revised version of the Webfinger specification based on feedb= ack I've received so far that seems to have general agreement. As request= ed, I added a change log at the end of the document that I hope will help. = The draft is here: http://tools.ietf.org/html/draft-jones-appsawg-webfinger-02 The "diff" tool on that page allows you to quickly see exactly what changed= . Paul --_000_90C41DD21FB7C64BB94121FBBC2E723453B42BB50BP3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

It would be appropriate for APPSAWG if the scope is narrowly defined as adding a few enhancements t= o RFC 6415 (which *is* what the current draft attempts to do, even t= hough its prose might sounds grander). But in the context of the recent OAu= th WG meeting discussing a competing foundation (SWD), a new WG seems to be= in order.

 

My concern is that we are reaching a point (or maybe pass it) w= here progressing a work to standards track RFC status no longer translate i= nto requiring new work to explain why it cannot build on top of the publish= ed standard. If this body throws away work as recent as October 2011 just b= ecause it’s more convenient for some to start from scratch, I donR= 17;t see why anyone would bother go through the significant cost and effort= of getting it published here in the first place.

 

=

EH

=

 =

 

 

 <= /o:p>

From: apps-discuss-= bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Murray S. Kucherawy
Sent: Thursday, March 29, 2012 9:18 AM
To: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Revise= d webfinger draft (-02)

 

= That sounds like a mighty strong statement that, in any case, it’s no= t appropriate for APPSAWG.

 

Perhaps the proponents should request a non-WG = list to talk about it for a while to let the problem definition congeal for= a while, and then request a working group when a charter falls out of that= .

<= o:p> 

-MSK

 

= From:= Eran Hammer [mailto:era= n@hueniverse.com]
Sent: Thursday, March 29, 2012 9:03 AM
= To: Murray S. Kucherawy; ap= ps-discuss@ietf.org
Subject: RE: [apps-discuss] Revised webfi= nger draft (-02)

 

This cl= early does not belong in the Security area or the OAuth working group.=

&n= bsp;

I w= ould strongly warn that moving this effort into any WG requires very carefu= l work on the charter as historically there has been very little consensus = and success in agreeing on what problems we are trying to solve. RFC 6415 w= as the end of a 5+ years process across multiple standard bodies including = the IETF, W3C, OASIS, and the OpenID Foundation. This has proved a really h= ard problem to *define*.

<= span style=3D'color:#1F497D'> 

EH

 

 

Having talked with Barry now,= an amended question:

Would this work better fit in another working = group like OAuth (which has its own interest and concerns in webfinger), or= perhaps in its own working group?  It may well be that it’s too= big to fit in APPSAWG’s charter for smaller work items.

 

-MSK

&nbs= p;

From: apps-discuss-bounces@ietf.org [mailto:apps-discus= s-bounces@ietf.org] On Behalf Of Murray S. Kucherawy
Sent:= Thursday, March 29, 2012 4:35 AM
To: apps-discuss@ietf.org
Subject: Re: [apps-di= scuss] Revised webfinger draft (-02)

 

To the working group,

 

This has been hovering outside APPSAWG = for two meetings now.  Is APPSAWG the right place to process it? = That is, should we bring it in as a working group document?  Or would= it be better done through the ISE, or perhaps in some other working group?=

 

-MSK

 

<= b>From:<= /span> apps-discuss-bounces@ie= tf.org [mailto:apps-di= scuss-bounces@ietf.org] On Behalf Of Paul E. Jones
Sent: Wednesday, March 28, 2012 6:50 PM
To: apps-discuss@ietf.org
Subject: [apps-discuss= ] Revised webfinger draft (-02)

 

Folks,

 

I published= a revised version of the Webfinger specification based on feedback I’= ;ve received so far that seems to  have general agreement.  As re= quested, I added a change log at the end of the document that I hope will h= elp.  The draft is here:

http://tools.= ietf.org/html/draft-jones-appsawg-webfinger-02

 

The “diff̶= 1; tool on that page allows you to quickly see exactly what changed.

 

Paul=

 

=
= --_000_90C41DD21FB7C64BB94121FBBC2E723453B42BB50BP3PW5EX1MB01E_-- From msk@cloudmark.com Thu Mar 29 10:12:14 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54EB021F86D1 for ; Thu, 29 Mar 2012 10:12:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.595 X-Spam-Level: X-Spam-Status: No, score=-102.595 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7XK6MqqwEtyZ for ; Thu, 29 Mar 2012 10:12:10 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.26]) by ietfa.amsl.com (Postfix) with ESMTP id 8CF6421F8444 for ; Thu, 29 Mar 2012 10:12:10 -0700 (PDT) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas902.corp.cloudmark.com ([fe80::e82a:4f80:7f44:eaf7%12]) with mapi id 14.01.0355.002; Thu, 29 Mar 2012 10:12:07 -0700 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Thread-Topic: [apps-discuss] Revised webfinger draft (-02) Thread-Index: Ac0NTjN3PPuV9i7nTOWIJZJHpX6j7AAUZkqgAAT2Q5AABFAtMAAAmxdwAACqzvAAASE20A== Date: Thu, 29 Mar 2012 17:12:06 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280C142E@exch-mbx901.corp.cloudmark.com> References: <027801cd0d4e$343dfbe0$9cb9f3a0$@packetizer.com> <9452079D1A51524AA5749AD23E0039280C0BFA@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280C0FE9@exch-mbx901.corp.cloudmark.com> <90C41DD21FB7C64BB94121FBBC2E723453B42BB4F4@P3PW5EX1MB01.EX1.SECURESERVER.NET> <9452079D1A51524AA5749AD23E0039280C132B@exch-mbx901.corp.cloudmark.com> <90C41DD21FB7C64BB94121FBBC2E723453B42BB50B@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453B42BB50B@P3PW5EX1MB01.EX1.SECURESERVER.NET> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.129.23.154] Content-Type: multipart/alternative; boundary="_000_9452079D1A51524AA5749AD23E0039280C142Eexchmbx901corpclo_" MIME-Version: 1.0 Subject: Re: [apps-discuss] Revised webfinger draft (-02) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 29 Mar 2012 17:12:14 -0000 --_000_9452079D1A51524AA5749AD23E0039280C142Eexchmbx901corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm not advocating throwing anything away. I'm proposing figuring out what= path would be most appropriate, regardless of whether it's a new innovatio= n or a derivative innovation. Our charter constrains us to small tasks. If webfinger can legitimately be= characterized as a small task, then we can do a call for adoption. If not= , which seems to be the case, then this isn't the right place for it, and w= e have other procedures for advancing such work. That's the question I'm p= osing here. -MSK From: Eran Hammer [mailto:eran@hueniverse.com] Sent: Thursday, March 29, 2012 9:47 AM To: Murray S. Kucherawy; apps-discuss@ietf.org Subject: RE: [apps-discuss] Revised webfinger draft (-02) It would be appropriate for APPSAWG if the scope is narrowly defined as add= ing a few enhancements to RFC 6415 (which *is* what the current draft attem= pts to do, even though its prose might sounds grander). But in the context = of the recent OAuth WG meeting discussing a competing foundation (SWD), a n= ew WG seems to be in order. My concern is that we are reaching a point (or maybe pass it) where progres= sing a work to standards track RFC status no longer translate into requirin= g new work to explain why it cannot build on top of the published standard.= If this body throws away work as recent as October 2011 just because it's = more convenient for some to start from scratch, I don't see why anyone woul= d bother go through the significant cost and effort of getting it published= here in the first place. EH From: apps-discuss-bounces@ietf.org [= mailto:apps-discuss-bounces@ietf.org] On Behalf Of Murray S. Kucherawy Sent: Thursday, March 29, 2012 9:18 AM To: apps-discuss@ietf.org Subject: Re: [apps-discuss] Revised webfinger draft (-02) That sounds like a mighty strong statement that, in any case, it's not appr= opriate for APPSAWG. Perhaps the proponents should request a non-WG list to talk about it for a = while to let the problem definition congeal for a while, and then request a= working group when a charter falls out of that. -MSK From: Eran Hammer [mailto:eran@hueniverse.com] Sent: Thursday, March 29, 2012 9:03 AM To: Murray S. Kucherawy; apps-discuss@ietf.org Subject: RE: [apps-discuss] Revised webfinger draft (-02) This clearly does not belong in the Security area or the OAuth working grou= p. I would strongly warn that moving this effort into any WG requires very car= eful work on the charter as historically there has been very little consens= us and success in agreeing on what problems we are trying to solve. RFC 641= 5 was the end of a 5+ years process across multiple standard bodies includi= ng the IETF, W3C, OASIS, and the OpenID Foundation. This has proved a reall= y hard problem to *define*. EH From: apps-discuss-bounces@ietf.org [= mailto:apps-discuss-bounces@ietf.org] On Behalf Of Murray S. Kucherawy Sent: Thursday, March 29, 2012 6:57 AM To: apps-discuss@ietf.org Subject: Re: [apps-discuss] Revised webfinger draft (-02) Having talked with Barry now, an amended question: Would this work better fit in another working group like OAuth (which has i= ts own interest and concerns in webfinger), or perhaps in its own working g= roup? It may well be that it's too big to fit in APPSAWG's charter for sma= ller work items. -MSK From: apps-discuss-bounces@ietf.org [= mailto:apps-discuss-bounces@ietf.org] On Behalf Of Murray S. Kucherawy Sent: Thursday, March 29, 2012 4:35 AM To: apps-discuss@ietf.org Subject: Re: [apps-discuss] Revised webfinger draft (-02) To the working group, This has been hovering outside APPSAWG for two meetings now. Is APPSAWG th= e right place to process it? That is, should we bring it in as a working g= roup document? Or would it be better done through the ISE, or perhaps in s= ome other working group? -MSK From: apps-discuss-bounces@ietf.org [= mailto:apps-discuss-bounces@ietf.org] On Behalf Of Paul E. Jones Sent: Wednesday, March 28, 2012 6:50 PM To: apps-discuss@ietf.org Subject: [apps-discuss] Revised webfinger draft (-02) Folks, I published a revised version of the Webfinger specification based on feedb= ack I've received so far that seems to have general agreement. As request= ed, I added a change log at the end of the document that I hope will help. = The draft is here: http://tools.ietf.org/html/draft-jones-appsawg-webfinger-02 The "diff" tool on that page allows you to quickly see exactly what changed= . Paul --_000_9452079D1A51524AA5749AD23E0039280C142Eexchmbx901corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m not advocati= ng throwing anything away.  I’m proposing figuring out what path= would be most appropriate, regardless of whether it’s a new innovati= on or a derivative innovation.

 

Our charter constrains= us to small tasks.  If webfinger can legitimately be characterized as= a small task, then we can do a call for adoption.  If not, which seem= s to be the case, then this isn’t the right place for it, and we have other procedures for advancing such work.  That&#= 8217;s the question I’m posing here.

 

-MSK=

 

From: Eran Ham= mer [mailto:eran@hueniverse.com]
Sent: Thursday, March 29, 2012 9:47 AM
To: Murray S. Kucherawy; apps-discuss@ietf.org
Subject: RE: [apps-discuss] Revised webfinger draft (-02)=

 

It would be appropriat= e for APPSAWG if the scope is narrowly defined as adding a few enhancements= to RFC 6415 (which *is* what the current draft attempts to do, even= though its prose might sounds grander). But in the context of the recent OAuth WG meeting discussing a competing f= oundation (SWD), a new WG seems to be in order.

 

My concern is that we = are reaching a point (or maybe pass it) where progressing a work to standar= ds track RFC status no longer translate into requiring new work to explain = why it cannot build on top of the published standard. If this body throws away work as recent as October 2011 just bec= ause it’s more convenient for some to start from scratch, I don’= ;t see why anyone would bother go through the significant cost and effort o= f getting it published here in the first place.

 

EH

 

 

 

 

 

That sounds like a mig= hty strong statement that, in any case, it’s not appropriate for APPS= AWG.

 

Perhaps the proponents= should request a non-WG list to talk about it for a while to let the probl= em definition congeal for a while, and then request a working group when a = charter falls out of that.

 

-MSK=

 

From: Eran Ham= mer [mailto:eran@hueniverse.com= ]
Sent: Thursday, March 29, 2012 9:03 AM
To: Murray S. Kucherawy; ap= ps-discuss@ietf.org
Subject: RE: [apps-discuss] Revised webfinger draft (-02)=

 

This clearly does not = belong in the Security area or the OAuth working group.

 

I would strongly warn = that moving this effort into any WG requires very careful work on the chart= er as historically there has been very little consensus and success in agre= eing on what problems we are trying to solve. RFC 6415 was the end of a 5+ years process across multiple s= tandard bodies including the IETF, W3C, OASIS, and the OpenID Foundation. T= his has proved a really hard problem to *define*.<= /p>

 

EH

 

 

Having talked with Bar= ry now, an amended question:

Would this work better fit in another working group like OAuth (which has i= ts own interest and concerns in webfinger), or perhaps in its own working g= roup?  It may well be that it’s too big to fit in APPSAWG’= s charter for smaller work items.

 

-MSK=

 

 

To the working group,<= o:p>

 

This has been hovering= outside APPSAWG for two meetings now.  Is APPSAWG the right place to = process it?  That is, should we bring it in as a working group documen= t?  Or would it be better done through the ISE, or perhaps in some other working group?

 

-MSK=

 
--_000_9452079D1A51524AA5749AD23E0039280C142Eexchmbx901corpclo_-- From zach@sensinode.com Thu Mar 29 13:52:16 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3809321F8548 for ; Thu, 29 Mar 2012 13:52:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Pm+7WyLnqXy for ; Thu, 29 Mar 2012 13:52:14 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 5739521F8542 for ; Thu, 29 Mar 2012 13:52:14 -0700 (PDT) Received: from dhcp-4377.meeting.ietf.org (dhcp-4377.meeting.ietf.org [130.129.67.119]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q2TKq7E8027251 for ; Thu, 29 Mar 2012 23:52:08 +0300 From: Zach Shelby Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 29 Mar 2012 22:52:06 +0200 References: <20120329204732.13711.266.idtracker@ietfa.amsl.com> To: "apps-discuss@ietf.org application-layer protocols" Message-Id: <5580A282-E191-4962-9410-6CF9FB14EDFC@sensinode.com> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [apps-discuss] Fwd: New Version Notification for draft-shelby-exi-registration-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 29 Mar 2012 20:52:16 -0000 I have posted a new version of the +exi registration draft. This version = improves the Interoperability considerations of the registration = requirements and further clarifies when this suffix may be used, as per = the feedback on the list from Carine and others. http://www.ietf.org/id/draft-shelby-exi-registration-01.txt Regards, Zach Begin forwarded message: > From: internet-drafts@ietf.org > Date: March 29, 2012 10:47:32 PM GMT+02:00 > To: zach@sensinode.com > Subject: New Version Notification for = draft-shelby-exi-registration-01.txt >=20 > A new version of I-D, draft-shelby-exi-registration-01.txt has been = successfully submitted by Zach Shelby and posted to the IETF repository. >=20 > Filename: draft-shelby-exi-registration > Revision: 01 > Title: The +exi Media Type Suffix > Creation date: 2012-03-29 > WG ID: Individual Submission > Number of pages: 5 >=20 > Abstract: > Efficient XML Interchange (EXI) is an XML representation technique > specified by the W3C to provie a binary alternative to the standard > text XML representation. This document defines a new Structure > Syntax Suffix "+exi" for use in a specific class of = protocols, where > "exi" content-type encoding or the generic = "application/exi" Media > Type are not applicable. >=20 >=20 >=20 >=20 > The IETF Secretariat --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From eran@hueniverse.com Thu Mar 29 19:27:02 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D840F21E8043 for ; Thu, 29 Mar 2012 19:27:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LiOT8lluR2Z4 for ; Thu, 29 Mar 2012 19:26:59 -0700 (PDT) Received: from p3plex2out01.prod.phx3.secureserver.net (p3plex2out01.prod.phx3.secureserver.net [184.168.131.12]) by ietfa.amsl.com (Postfix) with ESMTP id 477F521E801C for ; Thu, 29 Mar 2012 19:26:59 -0700 (PDT) Received: from P3PW5EX1HT004.EX1.SECURESERVER.NET ([72.167.180.46]) by p3plex2out01.prod.phx3.secureserver.net with bizsmtp id reSz1i00110TkE001eSz0C; Thu, 29 Mar 2012 19:26:59 -0700 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT004.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Thu, 29 Mar 2012 19:26:59 -0700 From: Eran Hammer To: "Murray S. Kucherawy" , "apps-discuss@ietf.org" Date: Thu, 29 Mar 2012 19:26:50 -0700 Thread-Topic: [apps-discuss] Revised webfinger draft (-02) Thread-Index: Ac0NTjN3PPuV9i7nTOWIJZJHpX6j7AAUZkqgAAT2Q5AABFAtMAAAmxdwAACqzvAAASE20AATfYUA Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453B42BB5C6@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <027801cd0d4e$343dfbe0$9cb9f3a0$@packetizer.com> <9452079D1A51524AA5749AD23E0039280C0BFA@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280C0FE9@exch-mbx901.corp.cloudmark.com> <90C41DD21FB7C64BB94121FBBC2E723453B42BB4F4@P3PW5EX1MB01.EX1.SECURESERVER.NET> <9452079D1A51524AA5749AD23E0039280C132B@exch-mbx901.corp.cloudmark.com> <90C41DD21FB7C64BB94121FBBC2E723453B42BB50B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <9452079D1A51524AA5749AD23E0039280C142E@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E0039280C142E@exch-mbx901.corp.cloudmark.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723453B42BB5C6P3PW5EX1MB01E_" MIME-Version: 1.0 Subject: Re: [apps-discuss] Revised webfinger draft (-02) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 30 Mar 2012 02:27:03 -0000 --_000_90C41DD21FB7C64BB94121FBBC2E723453B42BB5C6P3PW5EX1MB01E_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable And my answer is that right now it is a small task, but the responses indic= ated that some people might want it to be bigger. EH From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = On Behalf Of Murray S. Kucherawy Sent: Thursday, March 29, 2012 10:12 AM To: apps-discuss@ietf.org Subject: Re: [apps-discuss] Revised webfinger draft (-02) I'm not advocating throwing anything away. I'm proposing figuring out what= path would be most appropriate, regardless of whether it's a new innovatio= n or a derivative innovation. Our charter constrains us to small tasks. If webfinger can legitimately be= characterized as a small task, then we can do a call for adoption. If not= , which seems to be the case, then this isn't the right place for it, and w= e have other procedures for advancing such work. That's the question I'm p= osing here. -MSK From: Eran Hammer [mailto:eran@hueniverse.com] Sent: Thursday, March 29, 2012 9:47 AM To: Murray S. Kucherawy; apps-discuss@ietf.org Subject: RE: [apps-discuss] Revised webfinger draft (-02) It would be appropriate for APPSAWG if the scope is narrowly defined as add= ing a few enhancements to RFC 6415 (which *is* what the current draft attem= pts to do, even though its prose might sounds grander). But in the context = of the recent OAuth WG meeting discussing a competing foundation (SWD), a n= ew WG seems to be in order. My concern is that we are reaching a point (or maybe pass it) where progres= sing a work to standards track RFC status no longer translate into requirin= g new work to explain why it cannot build on top of the published standard.= If this body throws away work as recent as October 2011 just because it's = more convenient for some to start from scratch, I don't see why anyone woul= d bother go through the significant cost and effort of getting it published= here in the first place. EH From: apps-discuss-bounces@ietf.org [= mailto:apps-discuss-bounces@ietf.org] On Behalf Of Murray S. Kucherawy Sent: Thursday, March 29, 2012 9:18 AM To: apps-discuss@ietf.org Subject: Re: [apps-discuss] Revised webfinger draft (-02) That sounds like a mighty strong statement that, in any case, it's not appr= opriate for APPSAWG. Perhaps the proponents should request a non-WG list to talk about it for a = while to let the problem definition congeal for a while, and then request a= working group when a charter falls out of that. -MSK From: Eran Hammer [mailto:eran@hueniverse.com] Sent: Thursday, March 29, 2012 9:03 AM To: Murray S. Kucherawy; apps-discuss@ietf.org Subject: RE: [apps-discuss] Revised webfinger draft (-02) This clearly does not belong in the Security area or the OAuth working grou= p. I would strongly warn that moving this effort into any WG requires very car= eful work on the charter as historically there has been very little consens= us and success in agreeing on what problems we are trying to solve. RFC 641= 5 was the end of a 5+ years process across multiple standard bodies includi= ng the IETF, W3C, OASIS, and the OpenID Foundation. This has proved a reall= y hard problem to *define*. EH From: apps-discuss-bounces@ietf.org [= mailto:apps-discuss-bounces@ietf.org] On Behalf Of Murray S. Kucherawy Sent: Thursday, March 29, 2012 6:57 AM To: apps-discuss@ietf.org Subject: Re: [apps-discuss] Revised webfinger draft (-02) Having talked with Barry now, an amended question: Would this work better fit in another working group like OAuth (which has i= ts own interest and concerns in webfinger), or perhaps in its own working g= roup? It may well be that it's too big to fit in APPSAWG's charter for sma= ller work items. -MSK From: apps-discuss-bounces@ietf.org [= mailto:apps-discuss-bounces@ietf.org] On Behalf Of Murray S. Kucherawy Sent: Thursday, March 29, 2012 4:35 AM To: apps-discuss@ietf.org Subject: Re: [apps-discuss] Revised webfinger draft (-02) To the working group, This has been hovering outside APPSAWG for two meetings now. Is APPSAWG th= e right place to process it? That is, should we bring it in as a working g= roup document? Or would it be better done through the ISE, or perhaps in s= ome other working group? -MSK From: apps-discuss-bounces@ietf.org [= mailto:apps-discuss-bounces@ietf.org] On Behalf Of Paul E. Jones Sent: Wednesday, March 28, 2012 6:50 PM To: apps-discuss@ietf.org Subject: [apps-discuss] Revised webfinger draft (-02) Folks, I published a revised version of the Webfinger specification based on feedb= ack I've received so far that seems to have general agreement. As request= ed, I added a change log at the end of the document that I hope will help. = The draft is here: http://tools.ietf.org/html/draft-jones-appsawg-webfinger-02 The "diff" tool on that page allows you to quickly see exactly what changed= . Paul --_000_90C41DD21FB7C64BB94121FBBC2E723453B42BB5C6P3PW5EX1MB01E_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

And my answer is that right now it is a small task, but the r= esponses indicated that some people might want it to be bigger.<= /span>

 

EH

 = ;

From: apps-discu= ss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of = Murray S. Kucherawy
Sent: Thursday, March 29, 2012 10:12 AMTo: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Re= vised webfinger draft (-02)

 

I’m not advocating throwing anything away.  I’m propos= ing figuring out what path would be most appropriate, regardless of whether= it’s a new innovation or a derivative innovation.<= /p>

 

Our charter const= rains us to small tasks.  If webfinger can legitimately be characteriz= ed as a small task, then we can do a call for adoption.  If not, which= seems to be the case, then this isn’t the right place for it, and we= have other procedures for advancing such work.  That’s the ques= tion I’m posing here.

 

<= span style=3D'color:#1F497D'>-MSK

 

From: Eran Hammer [mailto:eran@hueniverse.com]
Sent: Thursday, = March 29, 2012 9:47 AM
To: Murray S. Kucherawy; apps-discuss@ietf.org
Subject: RE: [a= pps-discuss] Revised webfinger draft (-02)

 

It would be appropriate for APPSAWG if the scope is narr= owly defined as adding a few enhancements to RFC 6415 (which *is* wh= at the current draft attempts to do, even though its prose might sounds gra= nder). But in the context of the recent OAuth WG meeting discussing a compe= ting foundation (SWD), a new WG seems to be in order.

=

 =

My concern is that w= e are reaching a point (or maybe pass it) where progressing a work to stand= ards track RFC status no longer translate into requiring new work to explai= n why it cannot build on top of the published standard. If this body throws= away work as recent as October 2011 just because it’s more convenien= t for some to start from scratch, I don’t see why anyone would bother= go through the significant cost and effort of getting it published here in= the first place.

 

EH

 

 

 

 

From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of = Murray S. Kucherawy
Sent: Thursday, March 29, 2012 9:18 AM
= To: apps-discuss@ietf.org<= br>Subject: Re: [apps-discuss] Revised webfinger draft (-02)

 

That sounds like a mighty stron= g statement that, in any case, it’s not appropriate for APPSAWG.=

&n= bsp;

Per= haps the proponents should request a non-WG list to talk about it for a whi= le to let the problem definition congeal for a while, and then request a wo= rking group when a charter falls out of that.

 

-MSK

 

From: Eran Hammer [mailto:eran@hueniverse.com]
Se= nt: Thursday, March 29, 2012 9:03 AM
To: Murray S. Kucherawy;= apps-discuss@ietf.org
S= ubject: RE: [apps-discuss] Revised webfinger draft (-02)

 

This clearly does not belong in the Se= curity area or the OAuth working group.

 

I would strongly warn that movin= g this effort into any WG requires very careful work on the charter as hist= orically there has been very little consensus and success in agreeing on wh= at problems we are trying to solve. RFC 6415 was the end of a 5+ years proc= ess across multiple standard bodies including the IETF, W3C, OASIS, and the= OpenID Foundation. This has proved a really hard problem to *define= *.

=  

EH

 

<= b>From:<= /span> apps-discuss-bounces@ie= tf.org [mailto:apps-di= scuss-bounces@ietf.org] On Behalf Of Murray S. Kucherawy
S= ent: Thursday, March 29, 2012 6:57 AM
To: apps-discuss@ietf.org
Subject: Re: [app= s-discuss] Revised webfinger draft (-02)

<= p class=3DMsoNormal> 

Having talked with Barry now, an amended question:
Would this work better fit in another working group like OAuth (which has= its own interest and concerns in webfinger), or perhaps in its own working= group?  It may well be that it’s too big to fit in APPSAWG̵= 7;s charter for smaller work items.

 

-MSK

 

<= div>

From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = On Behalf Of Murray S. Kucherawy
Sent: Thursday, March 29, 20= 12 4:35 AM
To: apps-disc= uss@ietf.org
Subject: Re: [apps-discuss] Revised webfinger dr= aft (-02)

 =

To the working= group,

 

This has been hovering outside APPSAWG for two meetings now. = Is APPSAWG the right place to process it?  That is, should we bring i= t in as a working group document?  Or would it be better done through = the ISE, or perhaps in some other working group?

 

<= p class=3DMsoNormal>-MSK

 

From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org]= On Behalf Of Paul E. Jones
Sent: Wednesday, March 28, 201= 2 6:50 PM
To: apps-discu= ss@ietf.org
Subject: [apps-discuss] Revised webfinger draft (= -02)

 

Folks,

&n= bsp;

I published a revised version of the Web= finger specification based on feedback I’ve received so far that seem= s to  have general agreement.  As requested, I added a change log= at the end of the document that I hope will help.  The draft is here:=

http://tools.ietf.org/html/draft-jones-app= sawg-webfinger-02

 <= /p>

The “diff” tool on that page allows you= to quickly see exactly what changed.

 

Paul

 

<= /body>= --_000_90C41DD21FB7C64BB94121FBBC2E723453B42BB5C6P3PW5EX1MB01E_-- From paulej@packetizer.com Thu Mar 29 23:09:49 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DECBD21F86D5 for ; Thu, 29 Mar 2012 23:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2NbuZNkJBL62 for ; Thu, 29 Mar 2012 23:09:48 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 1DFFC21F8631 for ; Thu, 29 Mar 2012 23:09:48 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q2U69NOk001722 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 30 Mar 2012 02:09:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1333087764; bh=cuXe0hL2U2Q7l1VeQPiiCT8EIX5o+w3WaRXJF+D1ciU=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=fm+V7EHdyjalB8kyvD2MVqF98bzOWD2dGs+F6KmZtI5CVhukgUC6n1FnLMgdjRYLy ADj1+EIXVA+5sIUOJrHOF334OPLc3JSELBn8jmiEzNabLx7821SdiYadsQBsyjcbq7 s79AFGEP71H5rU5aRuVHke8HPFnNDOIpumj8AVxw= From: "Paul E. Jones" To: "'Murray S. Kucherawy'" , References: <027801cd0d4e$343dfbe0$9cb9f3a0$@packetizer.com> <9452079D1A51524AA5749AD23E0039280C0BFA@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280C0FE9@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E0039280C0FE9@exch-mbx901.corp.cloudmark.com> Date: Fri, 30 Mar 2012 02:09:31 -0400 Message-ID: <041f01cd0e3b$aca55c70$05f01550$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0420_01CD0E1A.2593BC70" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIu9uTQOHonqm8rGpkT+zjk6FKq9wFMvbOwAZNX8mmVp4iUEA== Content-Language: en-us Subject: Re: [apps-discuss] Revised webfinger draft (-02) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 30 Mar 2012 06:09:50 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0420_01CD0E1A.2593BC70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Given that it is building on the existing RFCs (6415, in particular), with very little addition, I do not think an entire WG is necessary. From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Murray S. Kucherawy Sent: Thursday, March 29, 2012 9:57 AM To: apps-discuss@ietf.org Subject: Re: [apps-discuss] Revised webfinger draft (-02) Having talked with Barry now, an amended question: Would this work better fit in another working group like OAuth (which has its own interest and concerns in webfinger), or perhaps in its own working group? It may well be that it's too big to fit in APPSAWG's charter for smaller work items. -MSK From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Murray S. Kucherawy Sent: Thursday, March 29, 2012 4:35 AM To: apps-discuss@ietf.org Subject: Re: [apps-discuss] Revised webfinger draft (-02) To the working group, This has been hovering outside APPSAWG for two meetings now. Is APPSAWG the right place to process it? That is, should we bring it in as a working group document? Or would it be better done through the ISE, or perhaps in some other working group? -MSK From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Paul E. Jones Sent: Wednesday, March 28, 2012 6:50 PM To: apps-discuss@ietf.org Subject: [apps-discuss] Revised webfinger draft (-02) Folks, I published a revised version of the Webfinger specification based on feedback I've received so far that seems to have general agreement. As requested, I added a change log at the end of the document that I hope will help. The draft is here: http://tools.ietf.org/html/draft-jones-appsawg-webfinger-02 The "diff" tool on that page allows you to quickly see exactly what changed. Paul ------=_NextPart_000_0420_01CD0E1A.2593BC70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Given that it is building on the existing RFCs = (6415, in particular), with very little addition, I do not think an = entire WG is necessary.

 

From:= = apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = On Behalf Of Murray S. Kucherawy
Sent: Thursday, March = 29, 2012 9:57 AM
To: apps-discuss@ietf.org
Subject: = Re: [apps-discuss] Revised webfinger draft = (-02)

 

Having talked with Barry now, an amended = question:

Would this work better fit in another working group = like OAuth (which has its own interest and concerns in webfinger), or = perhaps in its own working group?  It may well be that it’s = too big to fit in APPSAWG’s charter for smaller work = items.

 

-MSK

 

From:= = apps-discuss-bounces@ietf.o= rg [mailto:apps-discu= ss-bounces@ietf.org] On Behalf Of Murray S. = Kucherawy
Sent: Thursday, March 29, 2012 4:35 AM
To: = apps-discuss@ietf.org
Sub= ject: Re: [apps-discuss] Revised webfinger draft = (-02)

 

To the working group,

 

This has been hovering = outside APPSAWG for two meetings now.  Is APPSAWG the right place = to process it?  That is, should we bring it in as a working group = document?  Or would it be better done through the ISE, or perhaps = in some other working group?

 

-MSK

 

From:= = apps-discuss-bounces@ietf.o= rg [mailto:apps-discuss-bounces= @ietf.org] On Behalf Of Paul E. Jones
Sent: = Wednesday, March 28, 2012 6:50 PM
To: apps-discuss@ietf.org
Sub= ject: [apps-discuss] Revised webfinger draft = (-02)

 

Folks,

 

I published = a revised version of the Webfinger specification based on feedback = I’ve received so far that seems to  have general = agreement.  As requested, I added a change log at the end of the = document that I hope will help.  The draft is = here:

http= ://tools.ietf.org/html/draft-jones-appsawg-webfinger-02

 

The = “diff” tool on that page allows you to quickly see exactly = what changed.

 

Paul

 

------=_NextPart_000_0420_01CD0E1A.2593BC70-- From paulej@packetizer.com Thu Mar 29 23:14:16 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A13421F87BD for ; Thu, 29 Mar 2012 23:14:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.481 X-Spam-Level: X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1sYCWx7T2Xs for ; Thu, 29 Mar 2012 23:14:12 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 1B4C621F8794 for ; Thu, 29 Mar 2012 23:14:12 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q2U6DlDg001830 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 30 Mar 2012 02:13:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1333088029; bh=kVG0djIKBlSUooreH3q9+j3x+OQqaC1boJtiELLBqOs=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=ED1fgE81cmaUY5nSK+HJEJqAArIEGragoxux/GCP0z+y/QGzNgoOHysII5YQDXoQk oOAs57tYv9cA9Kv5ugtEM9D1jtkQeBtJRs0JblETSd7I8rOHI8WcvxiiaOKv1ij80C 1GnUq63XrCzlKHOKB8eeKQwfHQj9uyvYF0QoZf78= From: "Paul E. Jones" To: "'Murray S. Kucherawy'" , References: <027801cd0d4e$343dfbe0$9cb9f3a0$@packetizer.com> <9452079D1A51524AA5749AD23E0039280C0BFA@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280C0FE9@exch-mbx901.corp.cloudmark.com> <90C41DD21FB7C64BB94121FBBC2E723453B42BB4F4@P3PW5EX1MB01.EX1.SECURESERVER.NET> <9452079D1A51524AA5749AD23E0039280C132B@exch-mbx901.corp.cloudmark.com> <90C41DD21FB7C64BB94121FBBC2E723453B42BB50B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <9452079D1A51524AA5749AD23E0039280C142E@exch-mbx901.corp.cloudmark.com> In-Reply-To: <9452079D1A51524AA5749AD23E0039280C142E@exch-mbx901.corp.cloudmark.com> Date: Fri, 30 Mar 2012 02:13:56 -0400 Message-ID: <042c01cd0e3c$4a5c9320$df15b960$@packetizer.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_042D_01CD0E1A.C34D6420" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIu9uTQOHonqm8rGpkT+zjk6FKq9wFMvbOwAZNX8mkBehjPOwIT3OQgAaXbFDQDlfxh15VhOwnQ Content-Language: en-us Subject: Re: [apps-discuss] Revised webfinger draft (-02) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 30 Mar 2012 06:14:16 -0000 This is a multipart message in MIME format. ------=_NextPart_000_042D_01CD0E1A.C34D6420 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I do classify this as a small task. The Webfinger draft does the following: . Introduces the acct URI scheme for use with RFC 6415 . Introduces the acct link relation for the same . Mandates use of JRD (defined in RFC 6415) . Introduces a "resource" parameter to be used with RFC 6415 I think that's a complete list. As Eran said, it may be perceived as something bigger than it is. RFC 6415 is a framework and Webfinger builds on that, with a particular emphasis on user account URIs and stuff to support those. Paul From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Murray S. Kucherawy Sent: Thursday, March 29, 2012 1:12 PM To: apps-discuss@ietf.org Subject: Re: [apps-discuss] Revised webfinger draft (-02) I'm not advocating throwing anything away. I'm proposing figuring out what path would be most appropriate, regardless of whether it's a new innovation or a derivative innovation. Our charter constrains us to small tasks. If webfinger can legitimately be characterized as a small task, then we can do a call for adoption. If not, which seems to be the case, then this isn't the right place for it, and we have other procedures for advancing such work. That's the question I'm posing here. -MSK From: Eran Hammer [mailto:eran@hueniverse.com] Sent: Thursday, March 29, 2012 9:47 AM To: Murray S. Kucherawy; apps-discuss@ietf.org Subject: RE: [apps-discuss] Revised webfinger draft (-02) It would be appropriate for APPSAWG if the scope is narrowly defined as adding a few enhancements to RFC 6415 (which *is* what the current draft attempts to do, even though its prose might sounds grander). But in the context of the recent OAuth WG meeting discussing a competing foundation (SWD), a new WG seems to be in order. My concern is that we are reaching a point (or maybe pass it) where progressing a work to standards track RFC status no longer translate into requiring new work to explain why it cannot build on top of the published standard. If this body throws away work as recent as October 2011 just because it's more convenient for some to start from scratch, I don't see why anyone would bother go through the significant cost and effort of getting it published here in the first place. EH From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Murray S. Kucherawy Sent: Thursday, March 29, 2012 9:18 AM To: apps-discuss@ietf.org Subject: Re: [apps-discuss] Revised webfinger draft (-02) That sounds like a mighty strong statement that, in any case, it's not appropriate for APPSAWG. Perhaps the proponents should request a non-WG list to talk about it for a while to let the problem definition congeal for a while, and then request a working group when a charter falls out of that. -MSK From: Eran Hammer [mailto:eran@hueniverse.com] Sent: Thursday, March 29, 2012 9:03 AM To: Murray S. Kucherawy; apps-discuss@ietf.org Subject: RE: [apps-discuss] Revised webfinger draft (-02) This clearly does not belong in the Security area or the OAuth working group. I would strongly warn that moving this effort into any WG requires very careful work on the charter as historically there has been very little consensus and success in agreeing on what problems we are trying to solve. RFC 6415 was the end of a 5+ years process across multiple standard bodies including the IETF, W3C, OASIS, and the OpenID Foundation. This has proved a really hard problem to *define*. EH From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Murray S. Kucherawy Sent: Thursday, March 29, 2012 6:57 AM To: apps-discuss@ietf.org Subject: Re: [apps-discuss] Revised webfinger draft (-02) Having talked with Barry now, an amended question: Would this work better fit in another working group like OAuth (which has its own interest and concerns in webfinger), or perhaps in its own working group? It may well be that it's too big to fit in APPSAWG's charter for smaller work items. -MSK From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Murray S. Kucherawy Sent: Thursday, March 29, 2012 4:35 AM To: apps-discuss@ietf.org Subject: Re: [apps-discuss] Revised webfinger draft (-02) To the working group, This has been hovering outside APPSAWG for two meetings now. Is APPSAWG the right place to process it? That is, should we bring it in as a working group document? Or would it be better done through the ISE, or perhaps in some other working group? -MSK From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Paul E. Jones Sent: Wednesday, March 28, 2012 6:50 PM To: apps-discuss@ietf.org Subject: [apps-discuss] Revised webfinger draft (-02) Folks, I published a revised version of the Webfinger specification based on feedback I've received so far that seems to have general agreement. As requested, I added a change log at the end of the document that I hope will help. The draft is here: http://tools.ietf.org/html/draft-jones-appsawg-webfinger-02 The "diff" tool on that page allows you to quickly see exactly what changed. Paul ------=_NextPart_000_042D_01CD0E1A.C34D6420 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I do classify this as a small task.  The = Webfinger draft does the following:

·         = Introduces = the acct URI scheme for use with RFC 6415

·         = Introduces = the acct link relation for the same

·         = Mandates = use of JRD (defined in RFC 6415)

·         = Introduces = a “resource” parameter to be used with RFC = 6415

 

I think that’s a = complete list.  As Eran said, it may be perceived as something = bigger than it is.  RFC 6415 is a framework and Webfinger builds on = that, with a particular emphasis on user account URIs and stuff to = support those.

 

Paul =

 

From:= = apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = On Behalf Of Murray S. Kucherawy
Sent: Thursday, March = 29, 2012 1:12 PM
To: apps-discuss@ietf.org
Subject: = Re: [apps-discuss] Revised webfinger draft = (-02)

 

I’m not advocating throwing anything = away.  I’m proposing figuring out what path would be most = appropriate, regardless of whether it’s a new innovation or a = derivative innovation.

 

Our charter constrains = us to small tasks.  If webfinger can legitimately be characterized = as a small task, then we can do a call for adoption.  If not, which = seems to be the case, then this isn’t the right place for it, and = we have other procedures for advancing such work.  That’s the = question I’m posing here.

 

-MSK

 

From:= = Eran Hammer [mailto:eran@hueniverse.com]=
Sent: Thursday, March 29, 2012 9:47 AM
To: = Murray S. Kucherawy; apps-discuss@ietf.org
Sub= ject: RE: [apps-discuss] Revised webfinger draft = (-02)

 

It would be appropriate for APPSAWG if the scope = is narrowly defined as adding a few enhancements to RFC 6415 (which = *is* what the current draft attempts to do, even though its prose = might sounds grander). But in the context of the recent OAuth WG meeting = discussing a competing foundation (SWD), a new WG seems to be in = order.

 

My concern is that we = are reaching a point (or maybe pass it) where progressing a work to = standards track RFC status no longer translate into requiring new work = to explain why it cannot build on top of the published standard. If this = body throws away work as recent as October 2011 just because it’s = more convenient for some to start from scratch, I don’t see why = anyone would bother go through the significant cost and effort of = getting it published here in the first place.

 

EH

 

 

 

 

From:= = apps-discuss-bounces@ietf.o= rg [mailto:apps-discuss-bounces= @ietf.org] On Behalf Of Murray S. Kucherawy
Sent: = Thursday, March 29, 2012 9:18 AM
To: apps-discuss@ietf.org
Sub= ject: Re: [apps-discuss] Revised webfinger draft = (-02)

 

That sounds like a mighty strong statement that, = in any case, it’s not appropriate for = APPSAWG.

 

Perhaps the proponents = should request a non-WG list to talk about it for a while to let the = problem definition congeal for a while, and then request a working group = when a charter falls out of that.

 

-MSK

 

From:= = Eran Hammer [mailto:eran@hueniverse.com]=
Sent: Thursday, March 29, 2012 9:03 AM
To: = Murray S. Kucherawy; apps-discuss@ietf.org
Sub= ject: RE: [apps-discuss] Revised webfinger draft = (-02)

 

This clearly does not belong in the Security = area or the OAuth working group.

 

I would strongly warn = that moving this effort into any WG requires very careful work on the = charter as historically there has been very little consensus and success = in agreeing on what problems we are trying to solve. RFC 6415 was the = end of a 5+ years process across multiple standard bodies including the = IETF, W3C, OASIS, and the OpenID Foundation. This has proved a really = hard problem to *define*.

 

EH

 

From:= = apps-discuss-bounces@ietf.o= rg [mailto:apps-discuss-bounces= @ietf.org] On Behalf Of Murray S. Kucherawy
Sent: = Thursday, March 29, 2012 6:57 AM
To: apps-discuss@ietf.org
Sub= ject: Re: [apps-discuss] Revised webfinger draft = (-02)

 

Having talked with Barry now, an amended = question:

Would this work better fit in another working group = like OAuth (which has its own interest and concerns in webfinger), or = perhaps in its own working group?  It may well be that it’s = too big to fit in APPSAWG’s charter for smaller work = items.

 

-MSK

 

From:= = apps-discuss-bounces@ietf.o= rg [mailto:apps-discu= ss-bounces@ietf.org] On Behalf Of Murray S. = Kucherawy
Sent: Thursday, March 29, 2012 4:35 AM
To: = apps-discuss@ietf.org
Sub= ject: Re: [apps-discuss] Revised webfinger draft = (-02)

 

To the working group,

 

This has been hovering = outside APPSAWG for two meetings now.  Is APPSAWG the right place = to process it?  That is, should we bring it in as a working group = document?  Or would it be better done through the ISE, or perhaps = in some other working group?

 

-MSK

 

From:= = apps-discuss-bounces@ietf.o= rg [mailto:apps-discuss-bounces= @ietf.org] On Behalf Of Paul E. Jones
Sent: = Wednesday, March 28, 2012 6:50 PM
To: apps-discuss@ietf.org
Sub= ject: [apps-discuss] Revised webfinger draft = (-02)

 

Folks,

 

I published = a revised version of the Webfinger specification based on feedback = I’ve received so far that seems to  have general = agreement.  As requested, I added a change log at the end of the = document that I hope will help.  The draft is = here:

http= ://tools.ietf.org/html/draft-jones-appsawg-webfinger-02

 

The = “diff” tool on that page allows you to quickly see exactly = what changed.

 

Paul

 

------=_NextPart_000_042D_01CD0E1A.C34D6420-- From stpeter@stpeter.im Fri Mar 30 01:45:25 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A339A21F88CE for ; Fri, 30 Mar 2012 01:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.727 X-Spam-Level: X-Spam-Status: No, score=-102.727 tagged_above=-999 required=5 tests=[AWL=-0.128, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T0kFVIrLqlQ7 for ; Fri, 30 Mar 2012 01:45:25 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id EB22A21F8867 for ; Fri, 30 Mar 2012 01:45:24 -0700 (PDT) Received: from dhcp-153f.meeting.ietf.org (unknown [64.103.25.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A3FAC4005B; Fri, 30 Mar 2012 02:58:33 -0600 (MDT) Message-ID: <4F75729F.50903@stpeter.im> Date: Fri, 30 Mar 2012 10:45:19 +0200 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: Eran Hammer References: <027801cd0d4e$343dfbe0$9cb9f3a0$@packetizer.com> <9452079D1A51524AA5749AD23E0039280C0BFA@exch-mbx901.corp.cloudmark.com> <9452079D1A51524AA5749AD23E0039280C0FE9@exch-mbx901.corp.cloudmark.com> <90C41DD21FB7C64BB94121FBBC2E723453B42BB4F4@P3PW5EX1MB01.EX1.SECURESERVER.NET> <9452079D1A51524AA5749AD23E0039280C132B@exch-mbx901.corp.cloudmark.com> <90C41DD21FB7C64BB94121FBBC2E723453B42BB50B@P3PW5EX1MB01.EX1.SECURESERVER.NET> <9452079D1A51524AA5749AD23E0039280C142E@exch-mbx901.corp.cloudmark.com> <90C41DD21FB7C64BB94121FBBC2E723453B42BB5C6@P3PW5EX1MB01.EX1.SECURESERVER.NET> In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723453B42BB5C6@P3PW5EX1MB01.EX1.SECURESERVER.NET> X-Enigmail-Version: 1.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Revised webfinger draft (-02) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 30 Mar 2012 08:45:25 -0000 On 3/30/12 4:26 AM, Eran Hammer wrote: > And my answer is that right now it is a small task, but the responses > indicated that some people might want it to be bigger. I also think it's a small task. If some people construe it as larger, then perhaps we need to clarify the scope in the document. Peter -- Peter Saint-Andre https://stpeter.im/ From vesely@tana.it Fri Mar 30 02:30:57 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B2ED21F8644 for ; Fri, 30 Mar 2012 02:30:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V1qbywKPj5U5 for ; Fri, 30 Mar 2012 02:30:56 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 85C0821F88CE for ; Fri, 30 Mar 2012 02:30:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1333099854; bh=yfgJmADKS3cbhPCy01raexzvRnNUmhHsC7dJBBGYhqQ=; l=1766; h=Message-ID:Date:From:MIME-Version:To:CC:References:In-Reply-To: Content-Transfer-Encoding; b=Yek8FknrDBQTLXuao1PrQj4bpDnIAZJl3Y9dC+HPX8pgetIPAJMw/o9lF7FhWKz19 T0wtOqjFqRLP3KjB/LZ4LPnpVv93dMsfbSoaqQdP5Qb09nOTuPvliJAfIEnt/4vLFM tftk2zvsiGJGtC2FGKYDeV7ul0x6Lw0UWAN4p1ow= Received: from [130.129.20.64] (dhcp-1440.meeting.ietf.org [130.129.20.64]) (AUTH: PLAIN 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Fri, 30 Mar 2012 11:30:54 +0200 id 00000000005DC035.000000004F757D4E.0000684A Message-ID: <4F757D47.8060704@tana.it> Date: Fri, 30 Mar 2012 11:30:47 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: "Paul E. Jones" References: <053201cd0b5d$c08c80f0$41a582d0$@packetizer.com> <20120326150556.GC3557@mail.yitter.info> <20120327084709.GB11491@mail.yitter.info> <00ac01cd0c34$cfc96f10$6f5c4d30$@packetizer.com> <00d201cd0c3a$b3672410$1a356c30$@packetizer.com> <4F72F5C0.70106@tana.it> <024101cd0d30$06d70ac0$14852040$@packetizer.com> <4F744E1D.6080101@tana.it> <041d01cd0e3b$7d9d1bc0$78d75340$@packetizer.com> In-Reply-To: <041d01cd0e3b$7d9d1bc0$78d75340$@packetizer.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] What auth server supplies email addresses? Was webfinger discussion X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 30 Mar 2012 09:30:57 -0000 On Fri 30/Mar/2012 08:51:12 +0200 Paul E. Jones wrote: > I still do not understand :-( > > Can you elaborate for me a bit more? I may be conflating webfinger, openid, browserid, webid, and some other protocols of that sort. At any rate, it was said that a functionality relevant to some of those is to certify a generic claim, for example whether someone is legally allowed to drive a lorry in France. The user would indicate the kind-of-claim (driving license) and a trusted certifier (the French motoring authority) without revealing his/her identity. The relaying party would then let the user login at the certifier's site in order to eventually obtain the certificate. By the same logic, given that example.com should be universally trusted for email addresses that end with "@example.com", its server would be able to provide a certified, anonymous email address (opaque@example.com) to a shop, on behalf of a customer who wishes to protect his/her main address. >> -----Original Message----- >> From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] >> On Behalf Of Alessandro Vesely >> Sent: Thursday, March 29, 2012 7:57 AM >> To: apps-discuss@ietf.org >> Subject: Re: [apps-discuss] What auth server supplies email addresses? Was >> webfinger discussion >> >> On Thu 29/Mar/2012 13:55:12 +0200 Paul E. Jones wrote: >>> >>> Get an email address from what ID? A Webfinger "acct" URI? >> >> In general, the opaque token would be kind-of-claim @ claim-provider >> >>>> >>>> That implies the address is known. Couldn't one use just >>>> >>>> http://example.org/.well-known/finger/{opaque-token} >>>> >>>> and, possibly, >>>> >>>> http://example.org/.well-known/finger/{opaque-token}/email-addr? From julian.reschke@gmx.de Fri Mar 30 03:01:36 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94B0621F8965 for ; Fri, 30 Mar 2012 03:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.079 X-Spam-Level: X-Spam-Status: No, score=-104.079 tagged_above=-999 required=5 tests=[AWL=-1.480, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WN6CU3UshXel for ; Fri, 30 Mar 2012 03:01:35 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 7176E21F8971 for ; Fri, 30 Mar 2012 03:01:35 -0700 (PDT) Received: (qmail invoked by alias); 30 Mar 2012 10:01:29 -0000 Received: from mail.greenbytes.de (EHLO [IPv6:::1]) [217.91.35.233] by mail.gmx.net (mp004) with SMTP; 30 Mar 2012 12:01:29 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX194Sc0fbK14UaTlkM2m7kMrAnVhHTV043x3rFaKOf 6sdfq0Vjf1r/SK Message-ID: <4F758476.4020003@gmx.de> Date: Fri, 30 Mar 2012 12:01:26 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Andreas Petersson References: <20120326151030.7902.33251.idtracker@ietfa.amsl.com> <20120326173417.6058d1f6@hetzer> <4F71721A.7010301@gmx.de> <20120327160343.45e7e832@hetzer> <4F71CEDA.50502@gmx.de> In-Reply-To: <4F71CEDA.50502@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-http-forwarded-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 30 Mar 2012 10:01:36 -0000 On 2012-03-27 16:29, Julian Reschke wrote: > ... OK, details...: > Forwarded = "Forwarded" ":" LWS Forwarded-v > Forwarded-v = 1#forwarded-element If you use RFC2616ABNF, the LWS isn't needed here. (If you did switch to base this on HTTPbis, I would recommend just to define the *value* ABNF). > forwarded-element = > OWS forwarded-value *( OWS ";" OWS forwarded-value ) OWS I would recommend to allow leading and trailing ";"; if you don't you will end up with some recipients allowing them (because it's the simplest way to parse it) and some not doing so. Thus: forwarded-element = [ forwarded-value ] *( ";" [ forwarded-value ] ) Also OWS isn't needed here if you use RFC2616ABNF. (see similar discussion in websec) > forwarded-value = for-kv | by-kv | proto-kv | host-kv | ext-kv > > for-kv = "for=" node > by-kv = "by=" node > proto-kv = "proto=" proto-name > host-kv = "host=" host > ext-kv = extension "=" ext-value > proto-name = ALPHA *( ALPHA | DIGIT | "+" | "-" | "." ) I would change this to forwarded-element = token "=" value value = token / quoted-string And then define the various values independently of the base ABNF. Example: The syntax of a "for" value, after potential quoted-string unescaping, MUST conform to the "node" ABNF. (Also, it's kind of weird to use the name "value" for something that is not the right-hand side of a name/value pair; would be good to make "forwarded-value" something else) Finally: > extension = 1*( ALPHA | DIGIT | "-" ) > ext-value = but including SP> This should be extension = token ext-value = token | quoted-string for consistency with all the other values. Best regards, Julian From ht@inf.ed.ac.uk Fri Mar 30 03:20:34 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC3021F896D; Fri, 30 Mar 2012 03:20:34 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CsZCpMaJClHA; Fri, 30 Mar 2012 03:20:33 -0700 (PDT) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id 4E38321F8951; Fri, 30 Mar 2012 03:20:31 -0700 (PDT) Received: from nutty.inf.ed.ac.uk (nutty.inf.ed.ac.uk [129.215.33.33]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id q2UAKARL002994; Fri, 30 Mar 2012 11:20:15 +0100 (BST) Received: from calexico.inf.ed.ac.uk (calexico.inf.ed.ac.uk [129.215.24.15]) by nutty.inf.ed.ac.uk (8.13.8/8.13.8) with ESMTP id q2UAK45e019158; Fri, 30 Mar 2012 11:20:10 +0100 Received: from calexico.inf.ed.ac.uk (localhost [127.0.0.1]) by calexico.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id q2UAK34L021374; Fri, 30 Mar 2012 11:20:03 +0100 Received: (from ht@localhost) by calexico.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id q2UAK0Me021367; Fri, 30 Mar 2012 11:20:00 +0100 X-Authentication-Warning: calexico.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: apps-discuss@ietf.org, draft-ietf-appsawg-xdash.all@tools.ietf.org From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Fri, 30 Mar 2012 11:20:00 +0100 Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.4.21 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 Cc: iesg@ietf.org Subject: [apps-discuss] Review of draft-ietf-appsawg-xdash-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 30 Mar 2012 10:20:34 -0000 I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-appsawg-xdash Title: Deprecating the X- Prefix and Similar Constructs in Application Protocols Reviewer: Henry S. Thompson Review Date: 2012-03-30 IETF Last Call Date: 2012-03-15 Summary: This draft is almost ready for publication as an Proposed Standard but has a few issues that should be fixed before publication Major Issues: Abstract and Introduction [This started out as a nit about the use of scare-quotes in the Abstract, but now that I see how much depends on it throughout the document, I have promoted it] I have an allergy to scare-quotes, I guess, but putting quotes around "standard" here seems . . . odd. If what you mean is more along the lines of "distinguished between the names of parameters defined in the relevant standards and those without such definitions", then words along those lines might serve better. . . If you make such a change, then "newly-defined parameters" could become something such as "parameters getting their names outside the standards process". More importantly, the distinction between "parameters named in, or by means licensed by, the relevant standard" and "parameters named elsewhere" deserves more careful definition than that implied just by contrasting, in quotes, "standard" and "non-standard", given the weight the distinction has to bear later on. Section 2. Maybe not major? Depends on the answer. What does "discriminate between 'standard' and 'non-standard' parameters" actually _mean_? Either a parameter is defined in the relevant standard, or via a standards-licensed route, or it isn't. This section seems to imply there is some kind of generic processing reserved to parameters named in or licensed by the relevant standard (or, perhaps, to parameters _not_ so named), but this reader at least is not clear what such generic processing might be. It seems that the authors of this RFC know, or suspect, that some application implementers are lazy, and deploy such processing without actually using a list derived from the relevant specs and registries---if so, give an example? If not, what is this section for, exactly? Minor Issues: 3 Maybe, if you think there are relevant cases, add something along the lines of "MUST follow any naming guidelines set out in the relevant standard(s)". ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From julian.reschke@gmx.de Fri Mar 30 05:24:06 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D713321F865E for ; Fri, 30 Mar 2012 05:24:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.07 X-Spam-Level: X-Spam-Status: No, score=-104.07 tagged_above=-999 required=5 tests=[AWL=-1.471, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hLqLBBqxrg7z for ; Fri, 30 Mar 2012 05:24:05 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 4D5FB21F865D for ; Fri, 30 Mar 2012 05:24:05 -0700 (PDT) Received: (qmail invoked by alias); 30 Mar 2012 12:24:03 -0000 Received: from mail.greenbytes.de (EHLO [IPv6:::1]) [217.91.35.233] by mail.gmx.net (mp035) with SMTP; 30 Mar 2012 14:24:03 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/cNkJjXiXcupgZl136awr3sJvtByzva/o9ZNywiV WQL3Cg2AlbuVHK Message-ID: <4F75A5E0.4020908@gmx.de> Date: Fri, 30 Mar 2012 14:24:00 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Ned Freed References: <01OCB41ZCJES00ZUIL@mauve.mrochek.com> In-Reply-To: <01OCB41ZCJES00ZUIL@mauve.mrochek.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: Anne van Kesteren , apps-discuss@ietf.org Subject: Re: [apps-discuss] Feedback about "Update to MIME regarding Charset Parameter Handling in Textual Media Types" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 30 Mar 2012 12:24:06 -0000 On 2012-02-23 04:59, Ned Freed wrote: > ... >> For backwards compatibility, pretty much every existing text/* type >> > will have to violate this "SHOULD NOT". > Yep. That's the main reason why it needs to be a SHOULD. > ... Alexey and myself just discussed this, and we do agree that the SHOULD will need to be violated for updates of text/xml and text/html, but we believe this is ok (the authors of the new registrations will understand what the SHOULD is about and how to deal with it). Best regards, Julian From internet-drafts@ietf.org Fri Mar 30 05:52:29 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EDAC21F846A; Fri, 30 Mar 2012 05:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.49 X-Spam-Level: X-Spam-Status: No, score=-101.49 tagged_above=-999 required=5 tests=[AWL=1.110, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oKQycUoqHFqI; Fri, 30 Mar 2012 05:52:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E8C421F847B; Fri, 30 Mar 2012 05:52:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120330125228.15497.35035.idtracker@ietfa.amsl.com> Date: Fri, 30 Mar 2012 05:52:28 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-mime-default-charset-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 30 Mar 2012 12:52:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Worki= ng Group of the IETF. Title : Update to MIME regarding Charset Parameter Handling in T= extual Media Types Author(s) : Alexey Melnikov Julian F. Reschke Filename : draft-ietf-appsawg-mime-default-charset-01.txt Pages : 6 Date : 2012-03-30 This document changes RFC 2046 rules regarding default charset parameter values for text/* media types to better align with common usage by existing clients and servers. Editorial Note (To be removed by RFC Editor) Discussion of this draft should take place on the Apps Area Working Group mailing list (apps-discuss@ietf.org), which is archived at . A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-appsawg-mime-default-charset= -01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-appsawg-mime-default-charset-= 01.txt From paulej@packetizer.com Fri Mar 30 11:03:18 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 201DB21F85F3 for ; Fri, 30 Mar 2012 11:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.484 X-Spam-Level: X-Spam-Status: No, score=-2.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bi-PiNQfMZyR for ; Fri, 30 Mar 2012 11:03:17 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 2A9BE21F85EC for ; Fri, 30 Mar 2012 11:03:17 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q2UI3EPS016088 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 30 Mar 2012 14:03:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1333130596; bh=jC8DglZl5C19tlyDXUqcPfWVT/2nuX+cdZAJ9TVU2/8=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=D8Co5r8j40JLv3E2QZnyJHnT3SnZ/kciSIO47qsHOLjEdvfWFcWwDh53hD2oPw5Am t9I5iKeZGitY32pk/cGwOiwkOXisODVHlFruS6+XRKWSn9Gqoy4op+Zyokyp33kzAf TO4LKkRl2/WPQiK4pQYZ8BFF32kylCz0E4vMczFo= From: "Paul E. Jones" To: "'Alessandro Vesely'" References: <053201cd0b5d$c08c80f0$41a582d0$@packetizer.com> <20120326150556.GC3557@mail.yitter.info> <20120327084709.GB11491@mail.yitter.info> <00ac01cd0c34$cfc96f10$6f5c4d30$@packetizer.com> <00d201cd0c3a$b3672410$1a356c30$@packetizer.com> <4F72F5C0.70106@tana.it> <024101cd0d30$06d70ac0$14852040$@packetizer.com> <4F744E1D.6080101@tana.it> <041d01cd0e3b$7d9d1bc0$78d75340$@packetizer.com> <4F757D47.8060704@tana.it> In-Reply-To: <4F757D47.8060704@tana.it> Date: Fri, 30 Mar 2012 14:03:24 -0400 Message-ID: <04f101cd0e9f$67616f00$36244d00$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEg174HJISLlkWDD0VVkXSpmVuZQwKMareXAWwgTx8BwaaRJQGG5wouAU3B5AYBuFTkWgIDrH2CAm7QUeQCPbK1PwHttm20Akw553QBo30rsZck6EJQ Content-Language: en-us Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] What auth server supplies email addresses? Was webfinger discussion X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 30 Mar 2012 18:03:18 -0000 What you describe sounds a bit like JWT: http://openid.net/specs/draft-jones-json-web-token-07.html Or, it might be OpenID Connect, which uses JWT. (What you describe is not in OpenID 2.0.) Paul > -----Original Message----- > From: Alessandro Vesely [mailto:vesely@tana.it] > Sent: Friday, March 30, 2012 5:31 AM > To: Paul E. Jones > Cc: apps-discuss@ietf.org > Subject: Re: [apps-discuss] What auth server supplies email addresses? Was > webfinger discussion > > On Fri 30/Mar/2012 08:51:12 +0200 Paul E. Jones wrote: > > > I still do not understand :-( > > > > Can you elaborate for me a bit more? > > I may be conflating webfinger, openid, browserid, webid, and some other > protocols of that sort. At any rate, it was said that a functionality > relevant to some of those is to certify a generic claim, for example > whether someone is legally allowed to drive a lorry in France. The user > would indicate the kind-of-claim (driving license) and a trusted certifier > (the French motoring authority) without revealing his/her identity. The > relaying party would then let the user login at the certifier's site in > order to eventually obtain the certificate. > > By the same logic, given that example.com should be universally trusted > for email addresses that end with "@example.com", its server would be able > to provide a certified, anonymous email address (opaque@example.com) to a > shop, on behalf of a customer who wishes to protect his/her main address. > > >> -----Original Message----- > >> From: apps-discuss-bounces@ietf.org > >> [mailto:apps-discuss-bounces@ietf.org] > >> On Behalf Of Alessandro Vesely > >> Sent: Thursday, March 29, 2012 7:57 AM > >> To: apps-discuss@ietf.org > >> Subject: Re: [apps-discuss] What auth server supplies email > >> addresses? Was webfinger discussion > >> > >> On Thu 29/Mar/2012 13:55:12 +0200 Paul E. Jones wrote: > >>> > >>> Get an email address from what ID? A Webfinger "acct" URI? > >> > >> In general, the opaque token would be kind-of-claim @ claim-provider > >> > >>>> > >>>> That implies the address is known. Couldn't one use just > >>>> > >>>> http://example.org/.well-known/finger/{opaque-token} > >>>> > >>>> and, possibly, > >>>> > >>>> http://example.org/.well-known/finger/{opaque-token}/email-addr? From ned.freed@mrochek.com Fri Mar 30 11:16:09 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4935021F8656 for ; Fri, 30 Mar 2012 11:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qxBi7v2lSDsW for ; Fri, 30 Mar 2012 11:16:08 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 6F65D21F8646 for ; Fri, 30 Mar 2012 11:16:05 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01ODQ3PM20C0017PSW@mauve.mrochek.com> for apps-discuss@ietf.org; Fri, 30 Mar 2012 11:15:57 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01ODNXKOYL8000ZUIL@mauve.mrochek.com>; Fri, 30 Mar 2012 11:15:48 -0700 (PDT) Message-id: <01ODQ3PGNAFW00ZUIL@mauve.mrochek.com> Date: Fri, 30 Mar 2012 11:15:22 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Fri, 30 Mar 2012 14:24:00 +0200" <4F75A5E0.4020908@gmx.de> MIME-version: 1.0 Content-type: TEXT/PLAIN; Format=flowed References: <01OCB41ZCJES00ZUIL@mauve.mrochek.com> <4F75A5E0.4020908@gmx.de> To: Julian Reschke Cc: Anne van Kesteren , Ned Freed , apps-discuss@ietf.org Subject: Re: [apps-discuss] Feedback about "Update to MIME regarding Charset Parameter Handling in Textual Media Types" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 30 Mar 2012 18:16:09 -0000 > On 2012-02-23 04:59, Ned Freed wrote: > > ... > >> For backwards compatibility, pretty much every existing text/* type > >> > will have to violate this "SHOULD NOT". > > Yep. That's the main reason why it needs to be a SHOULD. > > ... > Alexey and myself just discussed this, and we do agree that the SHOULD > will need to be violated for updates of text/xml and text/html, but we > believe this is ok (the authors of the new registrations will understand > what the SHOULD is about and how to deal with it). Sounds like we're all in agreement then. Ned From McQuilWP@pobox.com Fri Mar 30 14:19:57 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4EB721F8674 for ; Fri, 30 Mar 2012 14:19:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LY84Xu5tV6P5 for ; Fri, 30 Mar 2012 14:19:56 -0700 (PDT) Received: from smtp.pobox.com (b-pb-sasl-quonix.pobox.com [208.72.237.35]) by ietfa.amsl.com (Postfix) with ESMTP id B2C2A21F85EC for ; Fri, 30 Mar 2012 14:19:54 -0700 (PDT) Received: from smtp.pobox.com (unknown [127.0.0.1]) by b-sasl-quonix.pobox.com (Postfix) with ESMTP id F3DAE4955; Fri, 30 Mar 2012 17:19:51 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=date:from :message-id:to:subject:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=sasl; bh=ui++/iH21ep5 bl1x8jmEzsxTWzU=; b=DycX/bLL31FOD6/rf+O+nFFTVS1pjCKOIMrw7KOcQdhJ 54RaZVd1ocHWgKytJSNPjp6lEgzlxvRh4bwMzspXKxPVqkb3dRpXBgTL8x91xJIt O7KulFTb/GieVMj5b+tcisUxKz/pTZUdsGku+bPQhsY2zFRTgWZQlEpHEJnVaMk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=date:from :message-id:to:subject:in-reply-to:references:mime-version :content-type:content-transfer-encoding; q=dns; s=sasl; b=B7TURG s/7ntSdsg2R9fwmKD8fCFXzoBtQcWwM+NGFpbmdkBuKWcdJrTvwIkwIcS0NUtHMs fFv+6kQJ/+wff10r78ZH0bKUK8c0hoKeI7ptfVB8/p68m95Gg8+aO+NG9suwDqgq sqklft4uX0yRG6MtmQE1rc5T3W0R6F/Zp6dPg= Received: from b-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by b-sasl-quonix.pobox.com (Postfix) with ESMTP id EB7DE4954; Fri, 30 Mar 2012 17:19:51 -0400 (EDT) Received: from BQ07NB (unknown [68.107.110.211]) by b-sasl-quonix.pobox.com (Postfix) with ESMTPA id 5314E4953; Fri, 30 Mar 2012 17:19:51 -0400 (EDT) Date: Fri, 30 Mar 2012 14:19:48 -0700 From: Bill McQuillan X-Priority: 3 (Normal) Message-ID: <1271382236.20120330141948@pobox.com> To: Apps-Discusssion In-Reply-To: <20120330125228.15497.35035.idtracker@ietfa.amsl.com> References: <20120330125228.15497.35035.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: 165C8F7E-7AAE-11E1-8EAD-9DB42E706CDE-02871704!b-pb-sasl-quonix.pobox.com Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-mime-default-charset-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 30 Mar 2012 21:19:57 -0000 In section 3: ---------- In order to improve interoperability with deployed agents, "text/*" media type registrations SHOULD either a. specify that the "charset" parameter is not used for the defined subtype, because the charset information is transported inside the payload (such as in "text/xml"), or b. require explicit unconditional inclusion of the "charset" parameter eliminating the need for a default value. In accordance with option (a), above, registrations for "text/*" media types that can transport charset information inside the corresponding payloads (such as "text/html" and "text/xml") SHOULD NOT specify the use of a "charset" parameter, nor any default value, in order to avoid conflicting interpretations should the charset parameter value and the value specified in the payload disagree. ---------- Doesn't option (a) actually mean that a new default charset is now defined, perhaps called "embedded-ascii", in which all octets with values less than 128 must have the same meaning as the correspondding ASCII values and that all octet values greater than 127 may be ignored? This would allow naively processing a newly specified text/* type by displaying the content first using the "embedded-ascii" charset (ignoring non-ascii octets) and, hopefully, finding, by eye, the actual charset specified within and then re-displaying the content using that discovered charset. For instance how would a newly specified type similar to text/html with a document using the internal charset of "ebcdic" be handled? The current specification would deal with this merely by ensuring that a "charset=ebcdic" appeared in the Content-Type Mime field and also within the document itself. -- Bill McQuillan From masinter@adobe.com Fri Mar 30 15:53:09 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4BB621F85D1 for ; Fri, 30 Mar 2012 15:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.538 X-Spam-Level: X-Spam-Status: No, score=-106.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJd0slJNJOkc for ; Fri, 30 Mar 2012 15:53:09 -0700 (PDT) Received: from exprod6og106.obsmtp.com (exprod6og106.obsmtp.com [64.18.1.191]) by ietfa.amsl.com (Postfix) with ESMTP id 9423C21F84A0 for ; Fri, 30 Mar 2012 15:53:06 -0700 (PDT) Received: from outbound-smtp-1.corp.adobe.com ([192.150.11.134]) by exprod6ob106.postini.com ([64.18.5.12]) with SMTP ID DSNKT3Y5UYwSHuOgZv7WFPL3Ik3FPkLSf1rL@postini.com; Fri, 30 Mar 2012 15:53:06 PDT Received: from inner-relay-4.eur.adobe.com (inner-relay-4.adobe.com [193.104.215.14]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id q2UMoxJ0021404; Fri, 30 Mar 2012 15:50:59 -0700 (PDT) Received: from nacas03.corp.adobe.com (nacas03.corp.adobe.com [10.8.189.121]) by inner-relay-4.eur.adobe.com (8.12.10/8.12.9) with ESMTP id q2UMr2HF007034; Fri, 30 Mar 2012 15:53:02 -0700 (PDT) Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nacas03.corp.adobe.com ([10.8.189.121]) with mapi; Fri, 30 Mar 2012 15:53:01 -0700 From: Larry Masinter To: Bill McQuillan , Apps-Discusssion Date: Fri, 30 Mar 2012 15:52:57 -0700 Thread-Topic: [apps-discuss] I-D Action: draft-ietf-appsawg-mime-default-charset-01.txt Thread-Index: Ac0OuuNl/dfMmNZsRa21yxIQPGKBMQADLZxg Message-ID: References: <20120330125228.15497.35035.idtracker@ietfa.amsl.com> <1271382236.20120330141948@pobox.com> In-Reply-To: <1271382236.20120330141948@pobox.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 Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-mime-default-charset-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 30 Mar 2012 22:53:09 -0000 RFC 2397 defaults media type of "data:" URIs to text/plain;charset=3DUS-ASC= II.=20 Should this be updated to default to utf8? From alexey.melnikov@isode.com Fri Mar 30 16:08:03 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A465521F8601 for ; Fri, 30 Mar 2012 16:08:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.932 X-Spam-Level: X-Spam-Status: No, score=-103.932 tagged_above=-999 required=5 tests=[AWL=-1.333, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oQJKah5e0M5F for ; Fri, 30 Mar 2012 16:08:03 -0700 (PDT) Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id A4B9D21F85FC for ; Fri, 30 Mar 2012 16:08:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1333148876; d=isode.com; s=selector; i=@isode.com; bh=kFHBI9Og3LJ60F1kLfba6Zxpja0WEdcVN5Lt/EZ2Q7M=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=uAo6AuUd32Z3H6XIw56lMueKGgRL2CGGFo03PAzl4pwLeB59c+IZIWyRiGKmQFSLA//MP4 cbZWcxGRZBTVWh+oSeL5VXfBnJhSQLGZdWPnBGzCFGmdEgawd1tWHB8EhfsPH8KJUVuNo/ rxR/USMedey6h9TPsNiv3aRaaVOYqN0=; Received: from [192.168.1.85] (191.49.12.93.rev.sfr.net [93.12.49.191]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Sat, 31 Mar 2012 00:07:55 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <4F763CCC.7020301@isode.com> Date: Sat, 31 Mar 2012 01:07:56 +0200 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: Larry Masinter References: <20120330125228.15497.35035.idtracker@ietfa.amsl.com> <1271382236.20120330141948@pobox.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Apps-Discusssion , Bill McQuillan Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-mime-default-charset-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 30 Mar 2012 23:08:03 -0000 On 31/03/2012 00:52, Larry Masinter wrote: > RFC 2397 defaults media type of "data:" URIs to text/plain;charset=US-ASCII. > > Should this be updated to default to utf8? I don't think so, unless there is WG consensus to change the default for text/plain in general. And so far I haven't seen one. From iesg-secretary@ietf.org Fri Mar 30 23:41:20 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6FF021F8601; Fri, 30 Mar 2012 23:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oIFkuCsCMfs0; Fri, 30 Mar 2012 23:41:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3978F21F85FD; Fri, 30 Mar 2012 23:41:19 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120331064119.28459.49304.idtracker@ietfa.amsl.com> Date: Fri, 30 Mar 2012 23:41:19 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] Last Call: (Email Greylisting: An Applicability Statement for SMTP) to Proposed Standard X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 06:41:20 -0000 The IESG has received a request from the Applications Area Working Group WG (appsawg) to consider the following document: - 'Email Greylisting: An Applicability Statement for SMTP' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-04-13. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This memo describes the art of email greylisting, the practice of providing temporarily degraded service to unknown email clients as an anti-abuse mechanism. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-appsawg-greylisting/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-appsawg-greylisting/ballot/ No IPR declarations have been submitted directly on this I-D. From mnot@mnot.net Sat Mar 31 03:55:58 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCB7D21F871A for ; Sat, 31 Mar 2012 03:55:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-4.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oLZvLVwJmdXH for ; Sat, 31 Mar 2012 03:55:58 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 2DF9121F871E for ; Sat, 31 Mar 2012 03:55:58 -0700 (PDT) Received: from mnot-air.lan (unknown [83.202.201.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id C7168509EB; Sat, 31 Mar 2012 06:55:48 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Mark Nottingham In-Reply-To: <5580A282-E191-4962-9410-6CF9FB14EDFC@sensinode.com> Date: Sat, 31 Mar 2012 12:55:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0885CE0D-11A3-4396-9443-37B4FF8D36C9@mnot.net> References: <20120329204732.13711.266.idtracker@ietfa.amsl.com> <5580A282-E191-4962-9410-6CF9FB14EDFC@sensinode.com> To: Zach Shelby X-Mailer: Apple Mail (2.1257) Cc: "apps-discuss@ietf.org application-layer protocols" Subject: Re: [apps-discuss] New Version Notification for draft-shelby-exi-registration-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 31 Mar 2012 10:55:59 -0000 What's the use case here? Content negotiation, or something else? Regards, On 29/03/2012, at 10:52 PM, Zach Shelby wrote: > I have posted a new version of the +exi registration draft. This = version improves the Interoperability considerations of the registration = requirements and further clarifies when this suffix may be used, as per = the feedback on the list from Carine and others. >=20 > http://www.ietf.org/id/draft-shelby-exi-registration-01.txt >=20 > Regards, > Zach >=20 > Begin forwarded message: >=20 >> From: internet-drafts@ietf.org >> Date: March 29, 2012 10:47:32 PM GMT+02:00 >> To: zach@sensinode.com >> Subject: New Version Notification for = draft-shelby-exi-registration-01.txt >>=20 >> A new version of I-D, draft-shelby-exi-registration-01.txt has been = successfully submitted by Zach Shelby and posted to the IETF repository. >>=20 >> Filename: draft-shelby-exi-registration >> Revision: 01 >> Title: The +exi Media Type Suffix >> Creation date: 2012-03-29 >> WG ID: Individual Submission >> Number of pages: 5 >>=20 >> Abstract: >> Efficient XML Interchange (EXI) is an XML representation technique >> specified by the W3C to provie a binary alternative to the standard >> text XML representation. This document defines a new Structure >> Syntax Suffix "+exi" for use in a specific class of = protocols, where >> "exi" content-type encoding or the generic = "application/exi" Media >> Type are not applicable. >>=20 >>=20 >>=20 >>=20 >> The IETF Secretariat >=20 > --=20 > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://www.sensinode.com > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Mark Nottingham http://www.mnot.net/ From msk@cloudmark.com Sat Mar 31 13:40:04 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB19E21F8741 for ; Sat, 31 Mar 2012 13:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.05 X-Spam-Level: X-Spam-Status: No, score=-101.05 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_20=-0.74, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R-P7QL1WnNYe for ; Sat, 31 Mar 2012 13:39:59 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 281C121F871E for ; Sat, 31 Mar 2012 13:39:58 -0700 (PDT) Received: from EXCH-MBX901.corp.cloudmark.com ([fe80::addf:849a:f71c:4a82]) by exch-htcas901.corp.cloudmark.com ([fe80::2524:76b6:a865:539c%10]) with mapi id 14.01.0355.002; Sat, 31 Mar 2012 13:39:58 -0700 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" , "draft-ietf-dane-protocol.all@tools.ietf.org" Thread-Topic: AppsDir review of draft-ietf-dane-protocol-18 Thread-Index: Ac0PZos4Ee9Go2DpTUOKvm1U+AQEwg== Date: Sat, 31 Mar 2012 20:39:56 +0000 Message-ID: <9452079D1A51524AA5749AD23E0039280C3D5E@exch-mbx901.corp.cloudmark.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [69.38.252.84] Content-Type: multipart/alternative; boundary="_000_9452079D1A51524AA5749AD23E0039280C3D5Eexchmbx901corpclo_" MIME-Version: 1.0 Subject: [apps-discuss] AppsDir review of draft-ietf-dane-protocol-18 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 31 Mar 2012 20:40:04 -0000 --_000_9452079D1A51524AA5749AD23E0039280C3D5Eexchmbx901corpclo_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have been selected as the Applications Area Directorate reviewer for this= draft (for background on appsdir, please see http://trac.tools.ietf.org/a= rea/app/trac/wiki/ApplicationsAreaDirectorate). This review is being undertaken early, during AD Evaluation but before IETF= Last Call. Please resolve these comments along with any other pre-Last Ca= ll comments you may receive. Please wait for direction from your document s= hepherd or AD before posting a new version of the draft. Document: draft-ietf-dane-protocol Title: The DNS-Based Authentication of Named Entities (DANE) Protocol for T= ransport Layer Security (TLS) Reviewer: Murray S. Kucherawy Review Date: March 31, 2012 IETF Last Call Date: not started IESG Telechat Date: not scheduled Review Summary: This draft is almost ready for publication as an Standards= Track RFC but has a few issues that should be fixed before publication. Document Summary: The draft proposes a mechanism by which an association be= tween a TLS certificate and an ADMD (a domain owner or similar) can be infe= rred from data found in the DNS. That is, one could confirm "This key real= ly does belong to example.com" by checking for some corresponding new data = in example.com's DNS. The goal appears to be to eliminate the current requ= irement for third-party certificate validation. The document is well-forme= d and clearly a lot of good work has gone into it. The IANA and Security s= ections are present and well-formed. Truly, a captivating read; I was part= icularly moved by the authors' use of "30820454308202BC020900AB58D24E77AD2A= F6300D06092A86" in Appendix C. Major Issues (things I think the WG needs to think about, clarify, reconsid= er, overhaul, describe better, fret about, talk me out of, etc.): Section 2.1.3: I don't know understand why this is a SHOULD. Doesn't it ha= ve to match exactly? What's an example of a situation where one could/shou= ld/would legitimately deviate from what this field says with a meaningful r= esult? The pseudocode in Appendix B leaves no room for SHOULD-style evalua= tion, so maybe this really ought to be a MUST. Section 10: RFC1034 and RFC1035 should be normative references, probably dr= agged in very early in this document. The examples in Section 2.3 rely on = zone file syntax defined there, and Appendix A.2 includes quite a bit of ma= terial that requires DNS familiarity. A reference for DNAME (I don't have = it handy) would probably also be a good idea, though that one could be info= rmative. Minor Issues (things I believe can be improved without too much effort or a= dditional thought): Section 1.3: The lone MUST here seems out of place given that Section 1 is = "Introduction". I suspect it might belong in or near Section 4. It's also= unclear to me whether you're repeating a requirement of DNSSEC or declarin= g one imposed by the protocol this document presents. Section 1.3: The sentence at the end of the first paragraph should probably= be on its own, at the start of this section. It should be followed by the= "This document defines a secure method..." paragraph, which also has a ver= y context-setting feel to it. Section 2: The "TBD" here might be better replaced by a forward reference t= o Section 7 where that number will presumably be assigned, so that there's = no need to update the same value in two places once the assignment occurs. = More on that later when I get to section 7. Section 2.1.1: Suggest the lowercase "must" in the 0 definition be changed = to "MUST". Section 2.1.1: Suggest the lowercase "may" be changed to "can" in the 1 def= inition. Section 2.2: Suggest stating that the unsigned decimal integers are eight-b= it unsigned decimal integers. (I realize this is redundant to the block di= agram earlier, but since you're being so precise here, you may as well be c= omplete.) Section 2.3: Suggest adding an example that uses matching type 0 and select= or 1. Section 2.3: The TLSA syntax in the example has me wondering of RFC103[45] = defined the space-separated integers in the zone file to do what you're obv= iously trying to do here. Since I'm airborne I don't have access to confir= m, but I suspect you've done your homework and this is fine. It's just a n= ote to me to check it when I'm back on the ground. Section 3: Don't use active voice. Generally, instead of "you would use", = say "is used" or "would be used". Section 4: The third paragraph is juicy insofar as I can think of other cur= rent IETF work that might be useful to reference here. For example, might = the domain name with which an association is established be useful input to= the Same Origin work being done in WEBSEC? Have they talked about this? = It might be an interesting use case to call out here or in an appendix or s= ome such. Section 4: The fourth paragraph needs a MUST in there somewhere, either cov= ering the full set of steps or one for each of them. Section 4: The third item in the bulleted list is less assertive than the o= ther two and seems to leave things dangling a bit. Suggest saying explicit= ly that the TLS session can continue but no positive assertion of an associ= ation can be made, or something like that. Section 4, second last paragraph: In the preceding paragraph, you direct th= e client to consider the TLSA data unusable. In this one, you direct the c= lient to mark it unusable. Is there a reason for the distinction between "= considering" and "marking"? I don't know what I would do differently here. Section 4, last paragraph: Is this referring to a TLSA query that returns m= ultiple answers? I think it is; just confirming. (You actually do answer = this in the next section, I believe.) Section 4: The last paragraph also leaves me hanging a bit. It should prob= ably say something about exactly what the meaning of a successful match is,= since you were so clear about the meanings of the failure cases. Section 6: Do we need version numbering in the protocol anywhere, since you= 're already anticipating a revision? The answer might be "no", just want t= o make sure it got consideration. Section 7.1: Why do the TBD thing instead of making the RRtype assignment r= equest now? Section 7.2: Would it be appropriate to make a DANE registry group for the = work you're doing in 7.2, 7.3 and 7.4? IANA might do that automatically, I= suppose, but I thought I'd ask anyway. Section 8, second last paragraph: A caveat about long TTLs meaning terminat= ion of a TLSA record can take a long time to take effect might be useful he= re. (This came up in a recent SecDir review for a draft I authored in anot= her working group.) Section 8.1: I'm not a fan of normative language in Security Considerations= . Suggest this section be moved up to a new subsection of Section 4, or re= ndered non-normative. Section A.1.2.1: Where would a na=EFve implementer find a guide to which al= gorithms are considered weak? Section A.1.2.2: Avoid use of non-normative "should". Appendix B: "This section is non-normative" can be removed. There's no suc= h thing as a normative appendix. You didn't say it in Appendix A, so you d= on't need to say it here. (One is also left wondering if Appendix A is nor= mative with this here and not there.) Nits (these are presentation improvements only and mostly are driven by per= sonal preference; if you do none of these, it's fine with me, but it might = save the RFC Editor some work): Section 1.1: s/the service that the key is used by/the service that uses t= he key/ Section 1.3: "DNSSEC, which is defined in RFCs 4033, 4034, and 4035 ([RFC40= 33], [RFC4034], and [RFC4035])" could just become "DNSSEC, which is defined= in [RFC4033], [RFC4034], and [RFC4035]", as you did in Section 1.4. Section 1.3: s/This document only relates to securely getting the DNS infor= mation for the certificate association using DNSSEC;/This document only rel= ates to getting the DNS information for the certificate association securel= y using DNSSEC;/ Section 2.1.1: s/specifying/specifies/, otherwise the surrounding text isn'= t a sentence. The fragment would be fine if this were a bulleted list or s= uchlike, but it reads awkwardly in this case. Section 2.1.1: In the definition of usage type 2, there's a comma splice. = The "for example" clause should be its own sentence, e.g., "For example, a = domain name administrator would use this to indicate that the domain issues= its own..." Section 2.1.2: s/specifying/specifies/, otherwise the surrounding text isn'= t a sentence. Section 2.1.2: "SubjectPublicKeyInfo" isn't defined before this point. I s= uspect this is likely fine; I'm doing this review on a plane without access= to some of the referenced RFCs, so I just want to confirm that this isn't = a dangling reference. Section 2.1.3: s/specifying/specifies/, otherwise the surrounding text isn'= t a sentence. Section 5: s/appendixes/appendices/ Section 5: s/to use TLSA records that are only shown to be validated/to use= only those TLSA records that are shown to be validated/ Section 6: s/selectors type/selector types/ Section A.1: Add a comma before "care must be taken". Section A.1.1: s/may/can/ (or "could" or "might") Section A.1.1: Starting with the "CAs frequently reissue" paragraph, the se= ction contains numerous grammatical errors. Section A.1.2: s/for certificate/for a certificate/ Section A.1.2.1: s/best course...are/best course...is/, and make the bullet= ed list into a numbered list. Section A.1.2.1: Should MD2 and MD5 be informative references? Section A.1.2.2: s/not sharing key of/not sharing the key of/ Section A.2.1.3: ...or the same certificate is used for all services on a h= ost. (Correct?) Section A.3: s/to securely find this out/to determine this securely/ -MSK --_000_9452079D1A51524AA5749AD23E0039280C3D5Eexchmbx901corpclo_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I have been selected as the Applications Area Direct= orate reviewer for this draft (for background on appsdir, please see  http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).

 

This review is being undertaken early, during AD Eva= luation but before IETF Last Call.  Please resolve these comments alon= g with any other pre-Last Call comments you may receive. Please wait for di= rection from your document shepherd or AD before posting a new version of the draft.

 

Document: draft-ietf-dane-protocol

Title: The DNS-Based Authentication of Named Entitie= s (DANE) Protocol for Transport Layer Security (TLS)

Reviewer: Murray S. Kucherawy

Review Date: March 31, 2012

IETF Last Call Date: not started

IESG Telechat Date: not scheduled

 

Review Summary:  This draft is almost ready for= publication as an Standards Track RFC but has a few issues that should be = fixed before publication.

 

Document Summary: The draft proposes a mechanism by = which an association between a TLS certificate and an ADMD (a domain owner = or similar) can be inferred from data found in the DNS.  That is, one = could confirm “This key really does belong to example.com” by checking for some corresponding new data in examp= le.com’s DNS.  The goal appears to be to eliminate the current r= equirement for third-party certificate validation.  The document is we= ll-formed and clearly a lot of good work has gone into it.  The IANA and Security sections are present and well-formed. = ; Truly, a captivating read; I was particularly moved by the authors’= use of “30820454308202BC020900AB58D24E77AD2AF6300D06092A86” in= Appendix C.

 

Major Issues (things I think the WG needs to think a= bout, clarify, reconsider, overhaul, describe better, fret about, talk me o= ut of, etc.):

 

Section 2.1.3: I don’t know understand why thi= s is a SHOULD.  Doesn’t it have to match exactly?  WhatR= 17;s an example of a situation where one could/should/would legitimately de= viate from what this field says with a meaningful result?  The pseudocode in Appendix B leaves no room for SHOULD-style evaluation, so ma= ybe this really ought to be a MUST.

 

Section 10: RFC1034 and RFC1035 should be normative = references, probably dragged in very early in this document.  The exam= ples in Section 2.3 rely on zone file syntax defined there, and Appendix A.= 2 includes quite a bit of material that requires DNS familiarity.  A reference for DNAME (I don’t have = it handy) would probably also be a good idea, though that one could be info= rmative.

 

Minor Issues (things I believe can be improved witho= ut too much effort or additional thought):

 

Section 1.3: The lone MUST here seems out of place g= iven that Section 1 is “Introduction”.  I suspect it might= belong in or near Section 4.  It’s also unclear to me whether y= ou’re repeating a requirement of DNSSEC or declaring one imposed by the protocol this document presents.

 

Section 1.3: The sentence at the end of the first pa= ragraph should probably be on its own, at the start of this section.  = It should be followed by the “This document defines a secure method&#= 8230;” paragraph, which also has a very context-setting feel to it.

 

Section 2: The “TBD” here might be bette= r replaced by a forward reference to Section 7 where that number will presu= mably be assigned, so that there’s no need to update the same value i= n two places once the assignment occurs.  More on that later when I get to section 7.

 

Section 2.1.1: Suggest the lowercase “mustR= 21; in the 0 definition be changed to “MUST”.

 

Section 2.1.1: Suggest the lowercase “may̶= 1; be changed to “can” in the 1 definition.

 

Section 2.2: Suggest stating that the unsigned decim= al integers are eight-bit unsigned decimal integers.  (I realize this = is redundant to the block diagram earlier, but since you’re being so = precise here, you may as well be complete.)

 

Section 2.3: Suggest adding an example that uses mat= ching type 0 and selector 1.


Section 2.3: The TLSA syntax in the example has me wondering of RFC103[45] = defined the space-separated integers in the zone file to do what you’= re obviously trying to do here.  Since I’m airborne I don’= t have access to confirm, but I suspect you’ve done your homework and this is fine.  It’s just a note to me to check it = when I’m back on the ground.

 

Section 3: Don’t use active voice.  Gener= ally, instead of “you would use”, say “is used” or = “would be used”.

 

Section 4: The third paragraph is juicy insofar as I= can think of other current IETF work that might be useful to reference her= e.  For example, might the domain name with which an association is es= tablished be useful input to the Same Origin work being done in WEBSEC?  Have they talked about this?  It mig= ht be an interesting use case to call out here or in an appendix or some su= ch.

 

Section 4: The fourth paragraph needs a MUST in ther= e somewhere, either covering the full set of steps or one for each of them.=

 

Section 4: The third item in the bulleted list is le= ss assertive than the other two and seems to leave things dangling a bit.&n= bsp; Suggest saying explicitly that the TLS session can continue but no pos= itive assertion of an association can be made, or something like that.

 

Section 4, second last paragraph: In the preceding p= aragraph, you direct the client to consider the TLSA data unusable.  I= n this one, you direct the client to mark it unusable.  Is there a rea= son for the distinction between “considering” and “marking”?  I don’t know what I would do differ= ently here.

 

Section 4, last paragraph: Is this referring to a TL= SA query that returns multiple answers?  I think it is; just confirmin= g.  (You actually do answer this in the next section, I believe.)=


Section 4: The last paragraph also leaves me hanging a bit.  It should= probably say something about exactly what the meaning of a successful matc= h is, since you were so clear about the meanings of the failure cases.=

 

Section 6: Do we need version numbering in the proto= col anywhere, since you’re already anticipating a revision?  The= answer might be “no”, just want to make sure it got considerat= ion.


Section 7.1: Why do the TBD thing instead of making the RRtype assignment r= equest now?

 

Section 7.2: Would it be appropriate to make a DANE = registry group for the work you’re doing in 7.2, 7.3 and 7.4?  I= ANA might do that automatically, I suppose, but I thought I’d ask any= way.

 

Section 8, second last paragraph: A caveat about lon= g TTLs meaning termination of a TLSA record can take a long time to take ef= fect might be useful here.  (This came up in a recent SecDir review fo= r a draft I authored in another working group.)

 

Section 8.1: I’m not a fan of normative langua= ge in Security Considerations.  Suggest this section be moved up to a = new subsection of Section 4, or rendered non-normative.

 

Section A.1.2.1: Where would a na=EFve implementer f= ind a guide to which algorithms are considered weak?

 

Section A.1.2.2: Avoid use of non-normative “s= hould”.

 

Appendix B: “This section is non-normativeR= 21; can be removed.  There’s no such thing as a normative append= ix.  You didn’t say it in Appendix A, so you don’t need to= say it here.  (One is also left wondering if Appendix A is normative = with this here and not there.)

 

Nits (these are presentation improvements only and m= ostly are driven by personal preference; if you do none of these, it’= s fine with me, but it might save the RFC Editor some work):

 

Section 1.1:  s/the service that the key is use= d by/the service that uses the key/


Section 1.3: “DNSSEC, which is defined in RFCs 4033, 4034, and 4035 (= [RFC4033], [RFC4034], and [RFC4035])” could just become “DNSSEC= , which is defined in [RFC4033], [RFC4034], and [RFC4035]”, as you di= d in Section 1.4.

 

Section 1.3: s/This document only relates to securel= y getting the DNS information for the certificate association using DNSSEC;= /This document only relates to getting the DNS information for the certific= ate association securely using DNSSEC;/

 

Section 2.1.1: s/specifying/specifies/, otherwise th= e surrounding text isn’t a sentence.  The fragment would be fine= if this were a bulleted list or suchlike, but it reads awkwardly in this c= ase.

 

Section 2.1.1: In the definition of usage type 2, th= ere’s a comma splice.  The “for example” clause shou= ld be its own sentence, e.g., “For example, a domain name administrat= or would use this to indicate that the domain issues its own…”<= o:p>

Section 2.1.2: s/specifying/specifies/, otherwise th= e surrounding text isn’t a sentence.

 

Section 2.1.2: “SubjectPublicKeyInfo” is= n’t defined before this point.  I suspect this is likely fine; I= ’m doing this review on a plane without access to some of the referen= ced RFCs, so I just want to confirm that this isn’t a dangling reference.

 

Section 2.1.3: s/specifying/specifies/, otherwise th= e surrounding text isn’t a sentence.

 

Section 5: s/appendixes/appendices/


Section 5: s/to use TLSA records that are only shown to be validated/to use= only those TLSA records that are shown to be validated/

 

Section 6: s/selectors type/selector types/

 

Section A.1: Add a comma before “care must be = taken”.

 

Section A.1.1: s/may/can/ (or “could” or= “might”)

 

Section A.1.1: Starting with the “CAs frequent= ly reissue” paragraph, the section contains numerous grammatical erro= rs.

 

Section A.1.2: s/for certificate/for a certificate/<= o:p>

 

Section A.1.2.1: s/best course…are/best course= …is/, and make the bulleted list into a numbered list.

 

Section A.1.2.1: Should MD2 and MD5 be informative r= eferences?

 

Section A.1.2.2: s/not sharing key of/not sharing th= e key of/

 

Section A.2.1.3: …or the same certificate is u= sed for all services on a host.  (Correct?)

 

Section A.3: s/to securely find this out/to determin= e this securely/

 

-MSK

--_000_9452079D1A51524AA5749AD23E0039280C3D5Eexchmbx901corpclo_-- From ned.freed@mrochek.com Sat Mar 31 21:45:06 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D58921F8677 for ; Sat, 31 Mar 2012 21:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SVlHSx5FTYmn for ; Sat, 31 Mar 2012 21:45:05 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id C0D6621F867A for ; Sat, 31 Mar 2012 21:45:05 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01ODS3YW9B2O009ACW@mauve.mrochek.com> for discuss@apps.ietf.org; Sat, 31 Mar 2012 21:45:00 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01ODNXKOYL8000ZUIL@mauve.mrochek.com>; Sat, 31 Mar 2012 21:44:56 -0700 (PDT) Message-id: <01ODS3YTKX1400ZUIL@mauve.mrochek.com> Date: Sat, 31 Mar 2012 21:44:06 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Fri, 30 Mar 2012 15:52:57 -0700" MIME-version: 1.0 Content-type: TEXT/PLAIN References: <20120330125228.15497.35035.idtracker@ietfa.amsl.com> <1271382236.20120330141948@pobox.com> To: Larry Masinter Cc: Apps-Discusssion , Bill McQuillan Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-mime-default-charset-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 01 Apr 2012 04:45:06 -0000 > RFC 2397 defaults media type of "data:" URIs to text/plain;charset=US-ASCII. > Should this be updated to default to utf8? I'm not entirely sure of all the ramifications, but they are minimal this sound like a really good idea to me. Ned From ned.freed@mrochek.com Sat Mar 31 21:46:46 2012 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C509921F8575 for ; Sat, 31 Mar 2012 21:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XtkdQ+7Vwa9U for ; Sat, 31 Mar 2012 21:46:46 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id E30D821F845F for ; Sat, 31 Mar 2012 21:46:45 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01ODS41X3GDS009ACW@mauve.mrochek.com> for discuss@apps.ietf.org; Sat, 31 Mar 2012 21:46:40 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01ODNXKOYL8000ZUIL@mauve.mrochek.com>; Sat, 31 Mar 2012 21:46:33 -0700 (PDT) Message-id: <01ODS41SVIQA00ZUIL@mauve.mrochek.com> Date: Sat, 31 Mar 2012 21:45:28 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Sat, 31 Mar 2012 01:07:56 +0200" <4F763CCC.7020301@isode.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; Format=flowed References: <20120330125228.15497.35035.idtracker@ietfa.amsl.com> <1271382236.20120330141948@pobox.com> <4F763CCC.7020301@isode.com> To: Alexey Melnikov Cc: Apps-Discusssion , Bill McQuillan Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-mime-default-charset-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 01 Apr 2012 04:46:46 -0000 > On 31/03/2012 00:52, Larry Masinter wrote: > > RFC 2397 defaults media type of "data:" URIs to text/plain;charset=US-ASCII. > > > > Should this be updated to default to utf8? > I don't think so, unless there is WG consensus to change the default for > text/plain in general. And so far I haven't seen one. How does this relate to the default for text/plain? I presume this default would only apply if no content-type was specified. Ned