Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Htn5F-0006df-9P; Thu, 31 May 2007 12:01:05 -0400 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1HtRAH-00013V-Jj for apps-review-confirm+ok@megatron.ietf.org; Wed, 30 May 2007 12:36:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtRAE-00012y-5P; Wed, 30 May 2007 12:36:46 -0400 Received: from mail.cs.utexas.edu ([128.83.139.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtRAC-0007YU-SW; Wed, 30 May 2007 12:36:46 -0400 Received: from [192.168.0.14] (rrcs-71-42-113-213.sw.biz.rr.com [71.42.113.213]) (authenticated bits=0) by mail.cs.utexas.edu (8.14.1/8.14.1) with ESMTP id l4UGaUtm023671 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 May 2007 11:36:43 -0500 (CDT) Message-ID: <465DA809.9020306@informed-control.com> Date: Wed, 30 May 2007 11:36:25 -0500 From: Mark Wahl User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.2) Gecko/20070222 SeaMonkey/1.1.1 MIME-Version: 1.0 To: Kurt Zeilenga References: <4B4F28FA-F4FE-4B63-BD59-4966B83BE478@Isode.com> In-Reply-To: <4B4F28FA-F4FE-4B63-BD59-4966B83BE478@Isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-Mailman-Approved-At: Thu, 31 May 2007 12:01:04 -0400 Cc: Ldapext , Mark Wahl , Chris Newman , ldap-dir@ietf.org, apps-review@ietf.org Subject: [APPS-REVIEW] Re: Review of draft-wahl-ldap-adminaddr X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Applications Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: apps-review-bounces@ietf.org Kurt Zeilenga wrote: > I reviewed this draft on behalf of the Apps Area Review team and the > LDAP Directorate. Thanks for your comments on these drafts! I'll be reviewing your emails and will respond shortly with more details. > I do find the uses of SHOULD in the Security Consideration section kind > of odd. Use > of RFC 2119 keywords should be limited to specification of > implementation requirements. If so, then RFC 2119 should be revised to incorporate that limitation, as I don't see that stated in 2119, and I observe in recently published proposed standard RFCs the use of RFC 2119 terminology in the security considerations sections to make statements beyond implementation requirements, e.g., RFC 4875 "Specifications of applications within the IETF MUST specify this mechanism" or RFC 4872 "RSVP signaling MUST be able to provide authentication and integrity". Mark Wahl Informed Control Inc. _______________________________________________ APPS-REVIEW mailing list APPS-REVIEW@ietf.org https://www1.ietf.org/mailman/listinfo/apps-review Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtU1L-0004d1-Ao; Wed, 30 May 2007 15:39:47 -0400 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1HtU1K-0004cj-9t for apps-review-confirm+ok@megatron.ietf.org; Wed, 30 May 2007 15:39:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HtU1K-0004ca-0F; Wed, 30 May 2007 15:39:46 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HtU1I-0003z4-Iy; Wed, 30 May 2007 15:39:45 -0400 Received: from [192.168.1.200] ((unknown) [24.182.55.218]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 30 May 2007 20:39:43 +0100 X-SMTP-Protocol-Errors: NORDNS In-Reply-To: <465DA809.9020306@informed-control.com> References: <4B4F28FA-F4FE-4B63-BD59-4966B83BE478@Isode.com> <465DA809.9020306@informed-control.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1E9A40B4-C10B-44C7-B64E-5710CB71F4B0@Isode.com> Content-Transfer-Encoding: 7bit From: Kurt Zeilenga Date: Wed, 30 May 2007 12:39:37 -0700 To: Mark Wahl X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: Chris Newman , Ldapext , ldap-dir@ietf.org, apps-review@ietf.org Subject: [APPS-REVIEW] Re: [ldapext] Re: Review of draft-wahl-ldap-adminaddr X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Applications Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: apps-review-bounces@ietf.org On May 30, 2007, at 9:36 AM, Mark Wahl wrote: > Kurt Zeilenga wrote: >> I reviewed this draft on behalf of the Apps Area Review team and >> the LDAP Directorate. > > Thanks for your comments on these drafts! I'll be reviewing your > emails and will respond shortly with more details. > >> I do find the uses of SHOULD in the Security Consideration section >> kind of odd. Use >> of RFC 2119 keywords should be limited to specification of >> implementation requirements. > > If so, then RFC 2119 should be revised to incorporate that limitation, > as I don't see that stated in 2119, and I observe in recently > published > proposed standard RFCs the use of RFC 2119 terminology in the security > considerations sections to make statements beyond implementation > requirements, e.g., RFC 4875 "Specifications of applications within > the > IETF MUST specify this mechanism" or RFC 4872 "RSVP signaling MUST be > able to provide authentication and integrity". There are plenty of examples of RFC 2119 keywords being oddly used... (including RFC 2119 itself). As I wasn't intending to start a debate on use of RFC 2119 keywords, I suggest you can take my RFC 2119 comments as indicating a concern that the document may not be clear as whom its requirements are placed upon. For instance, "The server's access control policy SHOULD allow this information to be visible to a suitable administrator in the same organization. can be taken to mean: The server SHOULD restricted allowable access control policies to those which cause this information to be visible to suitable administrators in the same organization. Which, if implemented in a server, would be quite bad. To avoid such confusion, I recommend you only use RFC 2119 keywords to impart requirements upon implementations of the specification and to word recommendations to server administrators as guidance. -- Kurt _______________________________________________ APPS-REVIEW mailing list APPS-REVIEW@ietf.org https://www1.ietf.org/mailman/listinfo/apps-review Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HsQC4-00054r-Tu; Sun, 27 May 2007 17:22:28 -0400 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1HrbHr-0005sy-2f for apps-review-confirm+ok@megatron.ietf.org; Fri, 25 May 2007 11:01:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrbHq-0005sc-Es; Fri, 25 May 2007 11:01:02 -0400 Received: from smtp1.su.se ([130.237.162.112]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HrbHp-0001Bt-5c; Fri, 25 May 2007 11:01:02 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp1.su.se (Postfix) with ESMTP id D1A4674353; Fri, 25 May 2007 17:00:59 +0200 (CEST) Received: from smtp1.su.se ([127.0.0.1]) by localhost (smtp1.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 27745-01-24; Fri, 25 May 2007 17:00:59 +0200 (CEST) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp1.su.se (Postfix) with ESMTP id 6333974279; Fri, 25 May 2007 17:00:56 +0200 (CEST) Message-ID: <4656FA33.6000608@it.su.se> Date: Fri, 25 May 2007 17:01:07 +0200 From: Leif Johansson User-Agent: Thunderbird 1.5.0.10 (X11/20070403) MIME-Version: 1.0 To: Kurt Zeilenga References: In-Reply-To: X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-2.312 tagged_above=-99 required=7 tests=[BAYES_00=-2.312] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-Mailman-Approved-At: Sun, 27 May 2007 17:22:27 -0400 Cc: Ldapext , Mark Wahl , Chris Newman , ldap-dir@ietf.org, apps-review@ietf.org Subject: [APPS-REVIEW] Re: [ldapext] Review of draft-wahl-ldap-subtree-source X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Applications Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: apps-review-bounces@ietf.org Kurt Zeilenga wrote: > I reviewed this draft on behalf of the Apps Area Review team and the > LDAP Directorate. > Such reviews have no special weight in the IETF. That is, this > message should be > treated simply as comments from an IETF participant. > > Summary: This document specifies an directory attribute to publish the > "source" of > directory entries. > > Directory entries often do derive from other sources. An entry could > easily derive > from multiple sources. Having a standard attribute that holds > reliable source > information seems to useful. However, I wonder if it appropriate to > have an > attribute which has "subtree" scope. I would think an attribute with > "entry" > scope would be better. > In practice I'd say entries are typically derived from multiple sources. Attribute or even value scope would be ideal imo but that may be impractical. I definitely agree that subree scope is too blunt a tool. Cheers Leif _______________________________________________ APPS-REVIEW mailing list APPS-REVIEW@ietf.org https://www1.ietf.org/mailman/listinfo/apps-review Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hraic-0000Z4-9c; Fri, 25 May 2007 10:24:38 -0400 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1Hraib-0000Yh-4e for apps-review-confirm+ok@megatron.ietf.org; Fri, 25 May 2007 10:24:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hraia-0000YY-R6; Fri, 25 May 2007 10:24:36 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HraiY-0000wB-BR; Fri, 25 May 2007 10:24:36 -0400 Received: from [192.168.1.200] ((unknown) [24.182.55.218]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 25 May 2007 15:24:33 +0100 X-SMTP-Protocol-Errors: NORDNS Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7039DF2B-2C9A-46DC-8D0E-16971083F942@Isode.com> Content-Transfer-Encoding: 7bit From: Kurt Zeilenga Date: Fri, 25 May 2007 07:24:27 -0700 To: Mark Wahl , Chris Newman X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: Ldapext , ldap-dir@ietf.org, apps-review@ietf.org Subject: [APPS-REVIEW] Review of draft-wahl-ldap-p3p X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Applications Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: apps-review-bounces@ietf.org I reviewed this draft on behalf of the Apps Area Review team and the LDAP Directorate. Such reviews have no special weight in the IETF. Summary: This I-D specifies LDAP schema for holding URIs for privacy policy documents. Though it seems a good idea for a directory service to publish its privacy policy information, I rather see the information stored in the directory so that directory clients need not use another access protocol. Aside from avoiding complexity in client implementations, there may be some security considerations specific to the use of a second protocol, and second connection to retrieve the policy information. The key issues here center around trust. Another issue with the expectation that an LDAP client can talk HTTP, is that LDAP clients often use authentication and data services which are not supported in HTTP. For instance, LDAP supports SASL, and HTTP doesn't. I dislike "subtree scoped" attributes as they make it more difficult than necessary for clients to obtain the information. The last paragraph of page 7 says "Clients MUST NOT assume the absence of this class in an entry's objectClass implies that the subtreeP3PrivacyPolicy attribute is not present in the entry...." This implies, however, that a client can assume the absence of the subtreeP3PrivacyPolicy in results requesting its return implies absence in the entry. A client, of course, cannot assume this. Unfortunately, because of the apparent absence, the client will likely go looking for this attribute in superior entries. If it finds one, or one in the Root DSE, the client will get the wrong privacy policy. I think it would be far better to define privacy policy in terms of the LDAP/X.500 administrative model. I note the community discussed use of subtree policy attributes v. use of subentries on multiple occasions, and seems to favor use of subentries (as evident by both ACI and password policy proposals, initially submitted using subtree scoped attributes, to being re-engineered to use subentries). That said, these discussions may not completely apply here. More discussion is needed. Lastly, a few minor things: The serverP3PrivacyPolicy attribute likely should have usage dSAOperation as it's DSA-specific (as are all root DSE attributes). The last paragraph on page 7 says "... this attribute might ... be provided through collective attributes". However, as the attribute is not defined as being COLLECTIVE, it simply cannot be provided as a collective attribute (as defined in [RFC 3671]). You likely meant something else. I suggest you say "provided by other means". For instance, the attribute could be specifically allowed by the controlling DIT content rule. Should note that caseExactMatch is not designed for matching of URIs and will return False for URIs which are equivalent, like http:// www.example.com v. HTTP://WWW.EXAMPLE.COM. Given serverP3PrivacyPolicy attribute is single valued, use of caseIgnoreMatch might be more appropriate (as it will return TRUE in cases such as the above). Of course, caseIgnoreMatch will ignore differences in URIs that are similar, like http://www.example.com/x and http://www.example.com/X. In either case, the inadequency of the matching rule chosen should be discussed in the I-D (and possibly the security considerations section. Also note that the LDAP data preservation requirements is also problematic, especially for the subtreeP3PrivacyPolicy (as its a user applications attribute). LDAP only requirements only require the server to return a value which is equivalent per the matching rule. To ensure the value is actually preserved, it might be best to use octetString and octetStringMatch to hold the URI. The document likely should include a statement of how a client is to treat a value which is not a valid URI. The attribute type and object class definitions were line-wrapped for readability. A note stating this is required (per Section 5 of BCP 118). Should include a references for UTF-8, XML, and LDAP URL. HTTP cite should be on first mention. Acronyms should be spelled out on first use in title, in Abstract, and in body. _______________________________________________ APPS-REVIEW mailing list APPS-REVIEW@ietf.org https://www1.ietf.org/mailman/listinfo/apps-review Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HraiV-0000TO-PD; Fri, 25 May 2007 10:24:31 -0400 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1HraiT-0000Q2-CU for apps-review-confirm+ok@megatron.ietf.org; Fri, 25 May 2007 10:24:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HraiT-0000Pt-2E; Fri, 25 May 2007 10:24:29 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HraiR-0000vw-Nf; Fri, 25 May 2007 10:24:29 -0400 Received: from [192.168.1.200] ((unknown) [24.182.55.218]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 25 May 2007 15:24:25 +0100 X-SMTP-Protocol-Errors: NORDNS Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Kurt Zeilenga Date: Fri, 25 May 2007 07:24:19 -0700 To: Mark Wahl , Chris Newman X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: Ldapext , ldap-dir@ietf.org, apps-review@ietf.org Subject: [APPS-REVIEW] Review of draft-wahl-ldap-subtree-source X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Applications Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: apps-review-bounces@ietf.org I reviewed this draft on behalf of the Apps Area Review team and the LDAP Directorate. Such reviews have no special weight in the IETF. That is, this message should be treated simply as comments from an IETF participant. Summary: This document specifies an directory attribute to publish the "source" of directory entries. Directory entries often do derive from other sources. An entry could easily derive from multiple sources. Having a standard attribute that holds reliable source information seems to useful. However, I wonder if it appropriate to have an attribute which has "subtree" scope. I would think an attribute with "entry" scope would be better. The main problem with use of a "subtree" scope attribute here is that it can be quite difficult, if not impossible, for the client to determine how entries in the subtree relate to objects at the source URI. For instance, say I have a subtree of each entries, each representing a page from a website. How can the client relate an entry of the subtree to a page from a website? It should be assumed that the relationship between the derived entry and its specific source element at the source (provided by the source URI) is non-obvious. Under this assumption, the source URI only provides information about the source of the subtree as a collection of entries, not information about the particular source object of any particular entry in the collection. I don't see how automated tools could make use of non-specific subtree source information. Say I have a subtree of entries derived from a website. How is Beyond this, I think RFC 2119 keywords are misused in the document, especially within the Security Considerations section. RFC 2119 keywords should only be used to detail requirements up implementations. While certainly server implementations SHOULD be capable of restricting access to this attribute (by whatever means they provide) (SHOULD be protectABLE), access policy is a local matter (should/should not be protectED). I see no reason why the document should recommend access be restricted to "administrative tools". _______________________________________________ APPS-REVIEW mailing list APPS-REVIEW@ietf.org https://www1.ietf.org/mailman/listinfo/apps-review Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HraiN-0000Ns-FE; Fri, 25 May 2007 10:24:23 -0400 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1HraiM-0000Na-M9 for apps-review-confirm+ok@megatron.ietf.org; Fri, 25 May 2007 10:24:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HraiJ-0000NO-M4; Fri, 25 May 2007 10:24:19 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HraiI-0000uT-6r; Fri, 25 May 2007 10:24:19 -0400 Received: from [192.168.1.200] ((unknown) [24.182.55.218]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 25 May 2007 15:24:14 +0100 X-SMTP-Protocol-Errors: NORDNS Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4B4F28FA-F4FE-4B63-BD59-4966B83BE478@Isode.com> Content-Transfer-Encoding: 7bit From: Kurt Zeilenga Date: Fri, 25 May 2007 07:24:06 -0700 To: Mark Wahl , Chris Newman X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: Ldapext , ldap-dir@ietf.org, apps-review@ietf.org Subject: [APPS-REVIEW] Review of draft-wahl-ldap-adminaddr X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Applications Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: apps-review-bounces@ietf.org I reviewed this draft on behalf of the Apps Area Review team and the LDAP Directorate. Such reviews have no special weight in the IETF. Summary: This I-D specifies the administratorsAddress attribute type for use in LDAP directory services to hold contact information about an "administrator". This document has a few minor issues. Once addressed, I see no problem with publication of this document. The attribute type was described in an ASID WG draft as having dSAOperation usage, which is generally appropriate for attributes providing information specific to the DSA (server). In this I-D it has directoryOperation usage. I assume the change was due to allowing the attribute not only to appear in the Root DSE, but in entries at the context prefix. I don't have any problem with this change, but it likely should be noted. Might be good to expand its applicability to other subentries. For instance, when placed in a collective attribute subentry, the attribute would contain the address of the party responsible for the content of that subentry. Expansion beyond this would likely be problematic. Should likely have an equality matching rule as well, but no ordering or substrings rule. As the syntax, IA5String, is not constrained to URIs, the I-D should say something about what clients should do when the value isn't a valid URI. (Treat it like an non-resolvable URI.) I do find the uses of SHOULD in the Security Consideration section kind of odd. Use of RFC 2119 keywords should be limited to specification of implementation requirements. It would be appropriate to say that access to this attribute SHOULD be controlled by the server's authorization mechanisms, any guidance to the server administrator as to what access policy for this attribute should be stated as guidance. Since one use of this attribute is to find who is responsible if the server is not making authentication decisions properly, a directory server configuration SHOULD cause the attribute in the root DSE, if present, to be able to be returned in a search response to all users who are permitted to access the directory server. If the user cannot authenticate, he's anonymous to the server, so by the above, I assume you mean: Since one use of this attribute is to find who is responsible if the server is not making authentication decisions properly, it may be appropriate to allow anonymous access this information (with or without other administrative restrictions). (your wording could be taken a number of odd ways) I suggest stating that servers SHOULD allow the administrator to control access to this attribute (via whatever access control mechanisms it offers). And where they don't allow the administrator to control access, they MUST allow the administrator to elect not to publish contact information. _______________________________________________ APPS-REVIEW mailing list APPS-REVIEW@ietf.org https://www1.ietf.org/mailman/listinfo/apps-review Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrEgn-0006mG-I9; Thu, 24 May 2007 10:53:17 -0400 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1HqyDl-0000Da-Hz for apps-review-confirm+ok@megatron.ietf.org; Wed, 23 May 2007 17:18:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqyDl-0000DS-7q for apps-review@ietf.org; Wed, 23 May 2007 17:18:13 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqyDi-0005vJ-9z for apps-review@ietf.org; Wed, 23 May 2007 17:18:13 -0400 Received: from [192.168.0.4] (adsl-68-122-125-236.dsl.pltn13.pacbell.net [68.122.125.236]) (authenticated bits=0) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l4NLHvS0025497 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 23 May 2007 14:17:58 -0700 Message-ID: <4654AF53.4090204@dcrocker.net> Date: Wed, 23 May 2007 14:17:07 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: apps-review@ietf.org References: In-Reply-To: Content-Type: multipart/mixed; boundary="------------040401080208090103010304" X-SongbirdInformation: support@songbird.com for more information X-Songbird: Clean X-Songbird-From: dhc@dcrocker.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fbfbe0dcb613b3d3aacd60d0efd6ab2 X-Mailman-Approved-At: Thu, 24 May 2007 10:53:16 -0400 Subject: [APPS-REVIEW] Review of: draft-ietf-simple-xml-patch-ops-02 X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Applications Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: apps-review-bounces@ietf.org This is a multi-part message in MIME format. --------------040401080208090103010304 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Review of: draft-ietf-simple-xml-patch-ops-02 By: D. Crocker Date: 23 May 2007 This document defines a means of specifying discrete changes to an existing XML document. It is intended as an alternative to sending an entire copy of the revised document, thereby saving bandwidth, but also having the benefit of permitting development of a change history. The document has a narrow focus on a problem that is intuitively real and significant. The solution offered in the document is also intuitively narrow and useful. It is explicit about its limitations, as well as providing for later extension. The document appears to be intended as -- and useful as -- a generic mechanism for modifying XML documents. (In fact, I'm surprised something like this has not been specified much sooner!) However as such, some of its more general references to SIP, and the like, are probably not necessary and might even be distracting. Those references no doubt come from the fact that it is the SIP community that is generating this specification, but I do not see anything that ties the specification to that specific environment, so it need not be cited. The specification style is rather more narrative than I think advisable for an Internet specification. It is not so much an issue of having text that is not useful but that it seems to lack enough formal/syntactic/structural content that would give the bits of local narrative more context, as well as making the document potentially better for reference. Although Section 9, XML Schema provides the complete 'syntax' for xml-patch, the body of the specification could greatly benefit from having in-line portions of that syntax or, at least, cross references to the relevant portions of Section 9. In some cases, it would be worth reviewing the text, to make sure it has the best logical flow when defining something. That is, sometimes I suspect that although the relevant pieces of specification are present for each thing, they are provided in a sequence that could be improved. Again, this is a comment about the 'local' portions, rather than overall document flow. The overall document flow seems fine. Detailed comments are attached. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net --------------040401080208090103010304 Content-Type: text/plain; name="draft-ietf-simple-xml-patch-ops-02-00dc.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; filename="draft-ietf-simple-xml-patch-ops-02-00dc.txt" SIMPLE WG J. Urpalainen Internet-Draft Nokia Research Center Expires: September 7, 2006 March 6, 2006 An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors draft-ietf-simple-xml-patch-ops-02 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 7, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract Extensible Markup Language (XML) documents are widely used as containers for the exchange and storage of arbitrary data in today's systems. Updates to this data require transporting of the entire XML document between hosts, unless there's a mechanism that allows exchanging only the updates of XML documents. This document describes an XML patch framework utilizing XML Path language (XPath) selectors. These selector values and updated new data content constitute the basis of patch operations described in this document. =20 << DHC: Updates to this data require transporting of the entire XML document between hosts, unless there's a mechanism that allows exchanging only the updates of XML documents. =20 --> =20 In order to send changes to an XML document, an entire copy of the new= version must be sent, unless there is a means of indicating only the por= tions that have changed (patches). =20 >> =20 =20 Urpalainen Expires September 7, 2006 [Page 1] =0C Internet-Draft Patch Operations March 2006 In addition to them, with basic , and directives a set of patches can then be applied to update an existing XML document. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Basic Features and Requirements . . . . . . . . . . . . . . . 4 4. Patch Operations . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Locating the Target for a Patch . . . . . . . . . . . . . 6 4.2. Namespace Mangling . . . . . . . . . . . . . . . . . . . . 6 4.3. Element . . . . . . . . . . . . . . . . . . . . . . 8 4.4. Element . . . . . . . . . . . . . . . . . . . . 11 4.5. Element . . . . . . . . . . . . . . . . . . . . . 12 5. Error Handling . . . . . . . . . . . . . . . . . . . . . . . . 14 6. Usage of Patch Operations . . . . . . . . . . . . . . . . . . 14 7. Usage of Selector Values . . . . . . . . . . . . . . . . . . . 14 8. Full Example . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 16 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 10.1. XML Schema Registration . . . . . . . . . . . . . . . . . 18 11. Security Considerations . . . . . . . . . . . . . . . . . . . 18 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 13.1. Normative References . . . . . . . . . . . . . . . . . . . 19 13.2. Informative References . . . . . . . . . . . . . . . . . . 20 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21 Intellectual Property and Copyright Statements . . . . . . . . . . 22 Urpalainen Expires September 7, 2006 [Page 2] =0C Internet-Draft Patch Operations March 2006 1. Introduction Extensible Markup Language (XML) [2] documents are widely used as containers for the exchange and storage of arbitrary data in today's systems. An example of such a system is the Common Presence Profile (CPP) [16] compatible presence system, in which presence data is represented using the XML based Presence Information Data Format (PIDF) [17]. Updates to this data require transporting of the entire XML document between hosts, unless there's a mechanism that allows exchanging only the updates of an XML document. =20 << 1. DHC: =20 Referring to CPP and PIDF both winds up confusing me. If I understan= d things correctly, the example utility is for specifying changes to a PI= DF document. I suggest simply saying that. The larger context for PIDF = is provided by the PIDF document, isn't it? =20 My point is that citing SIP, CPP, or any of the larger context winds = up making this document appear to be specific to those services, when it = appears to me that this is a very basic mechanism with wide utility for *= any* XML document modification. =20 =20 /d =20 >> =20 =20 << 2. DHC: =20 transporting of -> transporting =20 >> This document describes an XML patch framework which utilizes XML Path language (XPath) [3] selectors. An XPath selector is used to pinpoint the target for a change. These selector values and updated =20 << DHC: the target for the change =20 --> =20 the specific portion of the XML that is the target for the change. =20 >> =20 =20 new data content constitute the basis of patch operations described in this document. In addition to them, with basic , and directives a set of patches can be applied to update an existing initial XML document. With these patch operations, a simple semantics for data oriented XML documents [7] is achieved, that is, modifications like additions, removals or substitutions of elements and attributes can easily be performed. This document does not describe a full XML diff format, only basic patch operation elements which can be embedded within a full format. =20 << DHC: =20 What does the last sentence mean? =20 Perhaps: =20 This document only defines a means of specifiying discrete, individ= ual changes to an existing XML document. It does not provide a means of = representing an entire document that highlights changes (diffs). (But now I'm confused, because isn't that what a "XML diff document" i= s? d/) =20 >> As an example, in the Session Initiation Protocol (SIP) [18] based presence system a partial PIDF XML document format [13] consists of the existing PIDF document format combined with the patch operations elements described in this document. In general, patch operations can be used in any application that exchanges XML documents, for example within the SIP Events framework [12]. Another example is XCAP-diff [14] which uses this framework for sending partial updates of changes to XCAP [15] resources. << DHC: See above discussion about limiting the reference to be PIDF, rather t= han SIP, etc. =20 >> =20 =20 2. Conventions In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119, BCP 14 [1] and indicate requirement levels for compliant implementations. The following terms are used in this document: Initial XML document: An initial XML document that is going to be updated with a set of patches. Urpalainen Expires September 7, 2006 [Page 3] =0C Internet-Draft Patch Operations March 2006 XML diff document: A frame XML document that contains patch operation elements, namespace declarations and all the document content changes that are needed in order to transform an initial XML document into a new patched XML document. =20 << DHC: I'm not finding a definition for "frame XML document". =20 >> =20 Patched XML document: An XML document that results after applying one or more patch operations defined in the XML diff document to the initial XML document. Patch operation: A single change, i.e. a patch that is being applied to update an initial XML document. Patch operation element: An XML element that represents a single patch operation. Type definition for an element: A W3C Schema type definition for an element that describes a patch operation content. In-scope namespace declaration: A list of all in-scope namespace declarations within a context node. The QName expansion of a context node is based on mapping a prefix with one of these declarations. For an element, one namespace binding may have an empty prefix. Positional constraint: A number enclosed with square brackets. It can be used as a location step predicate. Located target node: A node which was found from the initial XML document with the aid of an XPath selector value. White space text node: A text node which contains only white space. 3. Basic Features and Requirements In this framework, XPath selector values and new data content are embedded within XML elements, the names of which imply the type of a modification: , or . These elements, or synonymously patch operations as used in this document, are described by defining their schema types with the W3C Schema language [6]. << DHC: =20 --> =20 the names of which specify the modification to be performed , or . These elements (patch operations) are defined in sch= ema types with the W3C Schema language [6]. =20 >> =20 =20 by defining their schema types with the W3C Schema language [6]. XPath selectors pinpoint the target for a change and they are expressed as attributes of these elements. The child node(s) of patch operation elements contain the new data content. In general when applicable, the new content SHOULD be moved unaltered to the patched XML document. =20 << DHC: Given that the edit operations are the entire essence of this specific= ation, what is the basis for this being a SHOULD rather than MUST? /d =20 >> =20 =20 The specifications utilizing these element types MUST define the full XML diff format with an appropriate MIME type [11] and a character =20 << DHC: Again, I thought the document said that it doesn't do a full diff form= at? In any event, how are they to define one, and what is the appropriat= e MIME type? d/ =20 >> =20 Urpalainen Expires September 7, 2006 [Page 4] =0C Internet-Draft Patch Operations March 2006 set, e.g. UTF-8 [9]. The partial PIDF format [13] includes this schema and describes additional definitions to produce a complete XML diff format for partial presence information updates. =20 << DHC: If the current document is intended for broader use, then I assume tha= t the PIDF reference, here, is meant as an example. The text should say = that. If I am understanding this correctly, the text should then say tha= t use of the current spec -- and I suggest you formulate an acronym, such= as XML-POF, so it is easy to refer to -- requires a similar schema defin= ition for each type of document to which it can be applied. =20 If indeed it does require this additional specification, then the curr= ent document is not usable on its own. As such, its progress through sta= ndards track should be coupled with at least one other specification, so = that the combination produces a useful whole. Perhaps the "partial PIDF = format" accomplishes this already. If it does, then I suggest an Appendi= x that specifies this formally, in order to provide the reader of the cur= rent document with a template for creating a similar package for other XM= L document types. =20 /d =20 >> =20 As the schema defined in this document does not declare any target namespace, the type definitions inherit the target namespace of the including schema. Therefore, additional namespace declarations within the XML diff documents can be avoided. It is anticipated that applications using these types will define , and elements based on the corresponding type definitions in this schema. In addition, an application may =20 << DHC: Huh? The current document defines add, replace, remove, right? So wh= at does it mean to have some other document define the elements "based on= the corresponding type definitions"? Add, replace, remove are generic o= perations on XML nodes, right? It does not matter what the context-specif= ic meaning of the node is, does it? d/ =20 >> =20 =20 reference only a subset of these type definitions. A future extension can introduce other operations, e.g. with document oriented models [7] a operation and a text node patching algorithm combined with would undoubtedly produce smaller XML diff documents. The instance document elements based on these schema type definitions MUST be well formed and SHOULD be valid. The following XPath 1.0 data model node types can be added, replaced or removed with this framework: elements, attributes, namespaces, comments, texts and processing instructions. The full XML prolog including e.g. XML entities [2] and the root node of an XML document cannot be patched according to this framework. However, patching of comments and processing instructions of the root node is allowed. Naturally the removal or addition of a document root element is not allowed as any valid XML document MUST always contain a single root element. Also note that support for external entities is beyond the scope of this framework. Note: Implementations must thus be based on XML parsers and XPath =20 << DHC: Assuming that the 'must' is normative, then a) capitalize it, please, = and b) this is more than a Note. d/ =20 >> =20 =20 interpreters that support all XPath 1.0 data model node types except the root node of an XML document. In addition to the location capability of these nodes, some application programming interfaces are needed for their manipulation in practice. XML documents which are equivalent for the purposes of many applications MAY differ in their physical representation. The aim of this document is to describe a deterministic framework where the canonical form with comments [4] of an XML document determines logical equivalence. For example, white space text nodes MUST be processed properly in order to fulfil this requirement as white space is by default significant [4]. Urpalainen Expires September 7, 2006 [Page 5] =0C Internet-Draft Patch Operations March 2006 4. Patch Operations An XML diff document contains a collection of patch operation elements, including one or more , and elements. These patch operations will be applied sequentially in the document order. After the first patch has been applied to update an initial XML document, the patched XML document becomes a new initial XML document. This procedure repeats until all patches have =20 << DHC: "initial"?? I don't recall that as an XML term of art. Unless it is = one, I suggest "independent" or the like. d/ =20 >> =20 =20 successfully been processed. In other words, this framework does not allow "apply all occurrences" in one pass. =20 << DHC: This seems less like an "in other words" and more like an additional, = basic constraint: the framework does not provide for repetition operator= s. d/ =20 >> =20 =20 4.1. Locating the Target for a Patch << DHC: for -> of =20 >> =20 =20 Each patch operation element contains a 'sel' attribute. The value of this attribute is an XPath selector with a restricted subset of the full XPath 1.0 recommendation. The 'sel' value is used to locate a single unique target node from the initial XML document. This located node pinpoints the target for a change and usually it is an element, which is e.g. either updated itself or some child node(s) are added into it. It may also be for instance a comment node, after =20 << DHC: =20 may -> MAY =20 >> =20 =20 which some other sibling node(s) are inserted. In any case, it is an error condition if multiple nodes are found during the evaluation of this selector value. The XPath selections of the 'sel' attribute always start from the =20 << DHC: =20 start -> starts =20 >> =20 =20 root node of a document. Thus relative location paths SHOULD be used so that the starting root node selection "/" can be omitted. When locating elements in a document tree, a node test can either be a "*" character or a QName. A "*" character selects all element children of the context node. Right after the node test, a location step can contain one or more predicates in any order. An attribute value comparison is one of the most typical predicates. The string value of the current context node or a child element may alternatively be used to identify elements in the tree. The character ".", which denotes a current context node selection, is an abbreviated form of "self::node()". Lastly, positional constraints like "[2]" can also be used as an additional predicate. An XPath 1.0 "id()" node-set function MAY also be used to identify unique elements from the document tree. The schema that describes the content model of the document MUST then use an attribute with the type ID [7] or with non-validating XML parsers, an "xml:id" [8] attribute MUST have been used within an instance document. 4.2. Namespace Mangling While the XPath recommendation specifies that prefixes can be used in location steps, it does not specify how associated namespace URIs are Urpalainen Expires September 7, 2006 [Page 6] =0C Internet-Draft Patch Operations March 2006 discovered during these evaluations. In the patch operation framework QName [5] expansion within a location step is evaluated according to the namespace declarations of the XML diff document. Thus the namespace URIs for these prefixes are found from the in- scope namespaces of the patch operation element. In other words, the XML diff document contains all needed information for QName expansions in order to perform XPath searches from the initial XML document. Note: It should be emphasized that prefixes within the XPath selectors MAY be different than those of the initial XML document because the matching of nodes is based on expanded names, i.e. a prefix maps to a namespace URI and these URIs and local names MUST be identical. For example, with a selector "p:foo", "p" maps to a namespace URI and "foo" is the local name. In this framework, when a node test is "foo" and the patch operation element has an in-scope default namespace declaration, a qualified element from the initial XML document is being searched. That is, the namespace URI of the expanded name of the located element MUST then be identical compared to this default namespace declaration. If there's not an in-scope default namespace declaration within the evaluation context, an unqualified element is located. Note: By contrast, in XPath 1.0 a "foo" selector always locates an unqualified element but in XPath 2.0 [10] also a qualified one which is attached with the default namespace declaration. Note: The XPath 1.0 recommendation specifies "namespace-uri()" and "local-name()" node-set functions which can be used within predicates. These functions may be utilized during XPath evaluations if there are no other means to "register" prefixes with associated namespace URIs. They can also be used when handling selections where default namespaces are attached to elements. However, the schema type definitions for these patch operation elements do not allow the usage of these functions. Also elements within the changed data content are usually namespace qualified. For example, when adding a new namespace qualified element to the initial XML document, the namespace declaration reference of this new element belongs first to the XML diff document. Naturally after copying or moving this element, the attached namespace MUST refer to a declaration within the patched XML document. If this namespace is declared in the patch operation element or within its ascendants, these references MUST thus be changed. Like in XPath, the mapping of these references is based on identical namespace URIs, not prefixes. The namespace with an Urpalainen Expires September 7, 2006 [Page 7] =0C Internet-Draft Patch Operations March 2006 identical URI from the in-scope namespaces of a context node of the initial XML document MUST be chosen. However, if overlapping in- scope namespaces exist, i.e., there are several in-scope namespaces with an identical namespace URI, then the namespace with the same prefix MUST be chosen. If an equivalent prefix is not then found, an error occurs. For instance, this kind of overlapping can happen when a namespace qualified attribute is added while elements are attached with an identical default namespace declaration. When the new added or updated elements contain namespace declarations, the namespace nodes move unaltered from the XML diff document to the patched XML document. Default namespace declarations can only be added by this way but prefixed namespace declarations MAY be added or removed with XPath namespace axis semantics shown later in this document. Note: In practice, this namespace mangling means that an XML diff document MUST only know the namespace URIs of qualified nodes, the prefixes of the initial XML document are not significant unless there are those overlapping namespace declarations. In other words, regardless whether the prefixes of qualified elements of the initial XML document are empty (default namespace attached) or not, the XML diff document may remain the same. 4.3. Element The element represents the addition of some new content to the initial XML document: e.g. a new element can be appended into an existing element. =20 << DHC: Given the tree-structured nature of XML structure, how is it possible = to add an element without "appending" it to an existing one? I am probab= ly not understanding what is being said here that is distinctive. /d =20 >> =20 The new data content exists as the child node(s) of the element. When adding attributes and namespaces the child node of the element MUST be a single text node. Otherwise, the element can contain any mixture of element, text, comment or =20 << DHC: can -> MAY =20 >> =20 =20 processing instruction nodes in any order. All children of the element are then copied into an initial XML document. The described =20 << DHC: an initial XML document=20 =20 ->=20 =20 into the XML document that will be the new version of the document bei= ng patched. =20 >> =20 =20 namespace mangling procedure applies to added elements, which include all of their attribute, namespace and descendant nodes. The element type has three attributes: 'sel', 'type' and 'pos'. =20 << DHC: hmmm. the patching "syntax" seems to be provided piecemeal. I sugges= t that there be a formal, discrete representation of each operation, comp= lete with attributes, parameters, or whatever, either as each operator is= defined, or as an aggregate set in an appendix. The current document is= more purely narrative than seems wise for specification. /d =20 >> =20 =20 The value of the optional 'type' attribute is only used when adding attributes and namespaces. Then the located target node MUST be an element into which new attributes and namespace declarations are inserted. When the value of this 'type' attribute equals "@attr" the purpose is to add a new attribute node with the name 'attr'. The value of this new 'attr' attribute is the text node content of the element. The less frequently used, prefixed, i.e. namespace Urpalainen Expires September 7, 2006 [Page 8] =0C Internet-Draft Patch Operations March 2006 qualified attributes can also be added. If the value of the 'type' attribute equals "namespace::pref" the aim is to add a new "pref" prefixed namespace declaration and the text node content of the element contains the corresponding namespace URI. Note: The 'type' attribute is thus also an XPath selector, but it only locates attributes and namespaces. Attribute axis "attribute" has an abbreviated form "@" unlike the "namespace" axis which doesn't have an abbreviated form. Double colons "::" are used as an axis separator in XPath. The value of the optional 'pos' attribute indicates the positioning of new data content. It is not used when adding attributes or namespaces. When neither 'type' nor 'pos' attribute exist, the children of the element are then appended as the last child node(s) of the located target element. When the value of 'pos' attribute is "prepend" the new node(s) are added as the first child node(s) of the located target element. With the value of "before" the added new node(s) MUST be the immediate preceding sibling node(s) and with "after" the immediate following sibling node(s) of the located target node. Some examples follow where nodes are not namespace qualified and prefixes are therefore not used. The whole XML diff content is not shown in these examples, only patch operation elements because of simplicity reasons: This is a new child =20 << DHC: This examples appears to be intended to demonstrate simplicity. Standi= ng on its own, I don't think it accomplishes this, because there is nothi= ng to compare it to. For example, what would be the alternative, less-si= mple means of specifying the change? d/ =20 >> =20 =20 Once the element has been found from the initial XML document, a new element is appended as the last child node of the element. The located target node: the element is naturally the root element of the initial XML document. The new element contains an 'id' attribute and a child text node. An example for an addition of an attribute: Bob =20 << DHC: Although more verbose, it also would help to show before-and-after sna= pshots of the document being modified. In other words, along with showin= g the modification operator specification, show its effect. d/ =20 >> =20 This operation adds a new 'user' attribute to the element which was located by using an 'id' attribute value predicate. The value of this new 'user' attribute is "Bob". A similar patched XML document is achieved when using a validating XML parser, if the 'sel' selector value had been 'id("ert4773")' and if the data type of the 'id' attribute is "ID" [7]. Urpalainen Expires September 7, 2006 [Page 9] =0C Internet-Draft Patch Operations March 2006 Note: As the 'sel' selector value MAY contain quotation marks, =20 << DHC: It can? How were we supposed to know that? d/ =20 >> =20 =20 escaped forms: """ or "'" can be used within attribute =20 << DHC: can -> MAY =20 >> =20 =20 values. However, it is often more appropriate to use the apostrophe (') character as shown in these examples. An alternative is also to interchange the apostrophes and quotation marks. An example for an addition of a prefixed namespace declaration: urn:ns:xxx This operation adds a new namespace declaration to the element. The prefix of this new namespace node is thus "pref" and the namespace URI is "urn:ns:xxx". An example for an addition of a comment node: <= /add> This operation adds a new comment node just before the element as an immediate preceding sibling node. This is also an example how a 'pos' attribute directive can be used. Some complexity arises when so called white space text nodes exist within an initial XML document. The XPath 1.0 data model requires that a text node MUST not have another text node as an immediate sibling node. For instance, if an add operation is like this: This is a new child The element has then two child nodes: a white space text node (a linefeed and two spaces) and a element. If the existing last child of the element is a text node, its content and the white space text node content MUST then be combined together. Otherwise (white space) text nodes can be added just like elements and thus, the canonical form of the patched XML document easily remains deterministic. As several sibling nodes can be inserted with a single operation, a "pretty printing" style can easily be maintained. Still another example about the handling of text nodes. Consider this example: newelem The second text node child of the element is first located. The added new content contains two text nodes and an element. As Urpalainen Expires September 7, 2006 [Page 10] =0C Internet-Draft Patch Operations March 2006 there can not be immediate sibling text nodes, the located target text node content and the first new text node content MUST be combined together. In essence, if the 'pos' value had been "before", the second new text node content would effectively have been prepended to the located target text node. Note: It is still worth noting that text nodes MAY contain CDATA sections, the latter of which are not treated as separate nodes. Once these CDATA sections exist within the new text nodes, they SHOULD be moved unaltered to the patched XML document. While XML entities [2] cannot be patched with this framework, the references to other than predefined internal entities can exist within text nodes or attributes when the XML prolog contains those declarations. These references may then be preserved if both the XML diff and the initial XML document have identical declarations within their prologs. Otherwise, references may be replaced with identical text as long as the "canonically equivalent" rule is obeyed. 4.4. Element The element represents a replacement operation: e.g. an existing element is updated with a new element or an attribute value is replaced with a new value. This operation always updates a single node or node content at a time. The element type has only a 'sel' attribute. If the located target node is an element, a comment or a processing instruction, then the child of the element MUST also be of the same type. Otherwise the element MUST have text content or it MAY be empty when replacing an attribute value or a text node content. Examples for replace operations, first a replacement of an element: This will update the element which has an 'a' attribute with value "1". The located target element is replaced with the element. So all descendant nodes, namespace declarations and attributes of the replaced element, if any existed, are thus removed. An example for a replacement of an attribute value: new value This will replace the 'a' attribute content of the element with Urpalainen Expires September 7, 2006 [Page 11] =0C Internet-Draft Patch Operations March 2006 the value "new value". If the element is empty, the 'a' attribute MUST then remain in the patched XML document appearing like . An example for a replacement of a namespace URI: urn:new:xxx This will replace the URI value of 'pref' prefixed namespace node with "urn:new:xxx". The parent node of the namespace declaration MUST be the element, otherwise an error occurs. An example for a replacement of a comment node: This will replace a comment node. The located target node is the first comment node child of the element. An example for a replacement of a processing instruction node: This will replace the processing instruction node "test" whose parent is the element. An example for a replacement of a text node: This is the new text content This will replace the first text node child of the element. The positional constraint "[1]" is not usually needed as the element content is rarely of mixed type [6] where several text node siblings typically exist. If a text node is updated and the element is empty, the text node MUST thus be removed as a text node MUST always have at least one character of data. 4.5. Element The element represents a removal operation of e.g. an existing element or an attribute. The element type has two attributes: 'sel' and 'ws'. The Urpalainen Expires September 7, 2006 [Page 12] =0C Internet-Draft Patch Operations March 2006 value of the optional 'ws' attribute is used to remove the possible white space text nodes that exist either as immediate following or preceding sibling nodes of the located target node. The usage of 'ws' attribute is only allowed when removing other types than text, attribute and namespace nodes. If the value of 'ws' is "before", the purpose is to remove the immediate preceding sibling node which MUST be a white space text node and if the value is "after", the corresponding following node. If the 'ws' value is "both", both the preceding and following white space text nodes MUST be removed. Examples for remove operations, first a removal of an element including all of its descendant, attribute and namespace nodes: This will remove the element as well as the immediate following sibling white space text node of the element. If the immediate following sibling node is not a white space text node, an error occurs. An example for a removal of an attribute node: This will remove the 'a' attribute node from the element. An example for a removal of a namespace node: This will remove the 'pref' prefixed namespace node from the element. Naturally this prefix MUST not be associated with any node prior to the removal of this namespace node. Also the parent node of this namespace declaration MUST be the element. An example for a removal of a comment node: This will remove the first comment node child of the element. An example for a removal of a processing instruction node: This will remove the "test" processing instruction node child of the element. Urpalainen Expires September 7, 2006 [Page 13] =0C Internet-Draft Patch Operations March 2006 An example for a removal of a text node: This will remove the first text node child of the element. When removing an element, a comment or a processing instruction node which has immediate preceding and following sibling text nodes without the 'ws' directive, the content of these two text nodes MUST be combined together. The latter text node thus disappears from the document. 5. Error Handling It is an error condition if any of the patch operations can not be unambiguously fulfilled. In other words, once a particular patch operation fails, it is an error condition and processing of further patch operations is hardly sensible. Also it is beyond the scope of this document to describe a generic error response. 6. Usage of Patch Operations An XML diff document SHOULD contain only the nodes which have been modified. However, when there's a large collection of changes it MAY =20 << DHC: "have been" or "will be"?? I suspect this question points to my havin= g some deeper confusion about what is being said here. That might be due= to my not being clear about what a "diff document" really is. d/ =20 >> =20 =20 be desirable to exchange the full document content instead. How this will be done in practice is beyond the scope of this document. =20 << DHC: I believe the "MAY" here is in fact not normative. The text is a sugg= estion for what to do, rather than a specification for what to do. If so= , I suggest say "could" or "might". =20 >> =20 7. Usage of Selector Values It is up to the application to decide the verbosity model for =20 << DHC: "verbosity model"??? what does this mean? It sounds like a formal te= rm. /d =20 >> =20 =20 selector values. Positional element selectors like "*/*[3]/*[2]" provide the shortest selectors, but care must to taken when using them. When there are several removals of sibling elements, the positional element indexes change after each update. Likewise these indexes change when new elements are inserted into the tree. Using names with possible attribute predicates like "doc[@sel=3D'foo']" is usually easier for an application, be it e.g. an auto diff tool but it leads to larger diff documents. 8. Full Example << DHC: OK. So this provides an original document, a set of patches, and the = result of applying the patches. This is good to have. Still, I suggest = that the earlier specifications for individual operators or particular us= es of operators, contain more narrow before/after examples, so that the r= eader can see what each thing does. d/ =20 >> =20 =20 An example initial XML document where namespace qualified elements exist: Urpalainen Expires September 7, 2006 [Page 14] =0C Internet-Draft Patch Operations March 2006 This is a sample document An imaginary XML diff document where prefix "p" corresponds the targetNamespace of this imaginary schema: Patched doc new attr One possible form of the result XML document after applying the patches: Urpalainen Expires September 7, 2006 [Page 15] =0C Internet-Draft Patch Operations March 2006 Patched doc The and removed element prefixes within the XML diff document are different than what are the "identical" namespace declarations in the initial XML document. If the initial XML document had used a prefixed namespace declaration instead of the default one, the XML diff document could still have been the same. The added new qualified elements would just have inherited that prefix. 9. XML Schema The schema types for the patch operation elements. ]> Urpalainen Expires September 7, 2006 [Page 16] =0C Internet-Draft Patch Operations March 2006 Urpalainen Expires September 7, 2006 [Page 17] =0C Internet-Draft Patch Operations March 2006 10. IANA Considerations 10.1. XML Schema Registration This section registers a new XML Schema. URI: urn:ietf:params:xml:schema:xml-patch-ops Registrant Contact: IETF, SIMPLE working group, Jari Urpalainen, 11. Security Considerations Information exchanged within these patch operations can be highly sensitive. Thus systems need to protect the integrity and Urpalainen Expires September 7, 2006 [Page 18] =0C Internet-Draft Patch Operations March 2006 confidentiality of this data. Especially, the transport protocol once it is used SHOULD have capabilities to protect from possible threats. For example, a malicious man-in-the-middle attack could easily give misinformation. However, all the security considerations depend very much on the application which utilizes this framework. 12. Acknowledgments The author would like to thank Eva Leppanen, Mikko Lonnfors, Aki Niemi, Jonathan Rosenberg, Miguel A. Garcia, Anat Angel and Stephane Bortzmeyer for their valuable comments and Ted Hardie for his input and support. 13. References 13.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] "Extensible Markup Language (XML) 1.0 (Third Edition)", W3C Recommendation REC-xml-20040204 , February 2004. [3] "XML Path Language (XPath) Version 1.0", W3C Recommendation REC- xpath-19991116 , November 1999. [4] "Canonical XML 1.0", W3C Recommendation REC-xml-c14n-20010315 , March 2001. [5] "Namespaces in XML", W3C Recommendation REC-xml-names-19990114 , January 1999. [6] "XML Schema Part 1: Structures Second Edition", W3C Recommendation REC-xmlschema-1-20041028 , October 2004. [7] "XML Schema Part 2: Datatypes Second Edition", W3C Recommendation PER-xmlschema-2-20040318 , October 2004. [8] "xml:id Version 1.0 W3C Recommendation 9 September 2005", W3C Recommendation PR-xml-id-20050712 , September 2005. [9] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998. Urpalainen Expires September 7, 2006 [Page 19] =0C Internet-Draft Patch Operations March 2006 13.2. Informative References [10] "XML Path Language (XPath) Version 2.0", W3C Candidate Recommendation 3 20051103 , November 2005. [11] Murata, M., "XML media types", RFC 3023, January 2001. [12] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [13] Lonnfors, M., Leppanen, E., Khartabil, H., and J. Urpalainen, "Presence Information Data format (PIDF) Extension for Partial Presence", draft-ietf-simple-partial-pidf-format-06 (work in progress), March 2006. [14] Rosenberg, J., "An Extensible Markup Language (XML) Document Format For Indicating Changes in XML Configuration Access Protocol (XCAP) Resources", draft-ietf-simple-xcap-diff-0x (work in progress), ? 2006. [15] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", draft-ietf-simple-xcap-08, October 2005. [16] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859, August 2004. [17] Sugano, H., "CPIM presence information data format", RFC 3863, May 2003. [18] Niemi, A., "Session Initiation Protocol (SIP) Extension for Event State Publication", RFC 3903, October 2004. Urpalainen Expires September 7, 2006 [Page 20] =0C Internet-Draft Patch Operations March 2006 Author's Address Jari Urpalainen Nokia Research Center Itamerenkatu 11-13 Helsinki 00180 Finland Phone: +358 7180 37686 Email: jari.urpalainen@nokia.com Urpalainen Expires September 7, 2006 [Page 21] =0C Internet-Draft Patch Operations March 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Urpalainen Expires September 7, 2006 [Page 22] =0C --------------040401080208090103010304 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ APPS-REVIEW mailing list APPS-REVIEW@ietf.org https://www1.ietf.org/mailman/listinfo/apps-review --------------040401080208090103010304-- Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HppX0-0002Pg-76; Sun, 20 May 2007 13:49:22 -0400 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1HppWx-0002Ko-GJ for apps-review-confirm+ok@megatron.ietf.org; Sun, 20 May 2007 13:49:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HppWu-0002AS-29 for apps-review@ietf.org; Sun, 20 May 2007 13:49:16 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HppWs-0006XA-Px for apps-review@ietf.org; Sun, 20 May 2007 13:49:16 -0400 Received: from [172.16.1.99] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 20 May 2007 18:49:13 +0100 Message-ID: <465089D2.3020107@isode.com> Date: Sun, 20 May 2007 18:48:02 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Lisa Dusseault Subject: Re: [APPS-REVIEW] Apps Review of individual submissions in the Area References: <65D1BC4F-E930-46D0-8417-97E4DD0F4D88@Isode.com> <65C2B987-7782-4F07-AAE7-D8FF35A50A60@osafoundation.org> In-Reply-To: <65C2B987-7782-4F07-AAE7-D8FF35A50A60@osafoundation.org> MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1"; format="flowed" Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: Kurt Zeilenga , apps-review@ietf.org X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Applications Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: apps-review-bounces@ietf.org Lisa Dusseault wrote: > I am currently doing AD review on draft-crispin-collation-unicasemap > and draft-hartman-webauth-phishing (Informational) as individual > submissions and would love to get input on those. I volunteer Kurt to review draft-crispin-collation-unicasemap ;-). _______________________________________________ APPS-REVIEW mailing list APPS-REVIEW@ietf.org https://www1.ietf.org/mailman/listinfo/apps-review Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp8lA-0001Af-HQ; Fri, 18 May 2007 16:09:08 -0400 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1Hp8l8-0001AU-Ev for apps-review-confirm+ok@megatron.ietf.org; Fri, 18 May 2007 16:09:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp8l8-0001AM-5D for apps-review@ietf.org; Fri, 18 May 2007 16:09:06 -0400 Received: from laweleka.osafoundation.org ([204.152.186.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hp8l6-0003pO-RO for apps-review@ietf.org; Fri, 18 May 2007 16:09:06 -0400 Received: from localhost (laweleka.osafoundation.org [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 7C369142204; Fri, 18 May 2007 13:09:04 -0700 (PDT) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7JKM3BMLVbqY; Fri, 18 May 2007 13:09:03 -0700 (PDT) Received: from [192.168.1.101] (unknown [74.95.2.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 977AF1421FB; Fri, 18 May 2007 13:09:02 -0700 (PDT) In-Reply-To: <65D1BC4F-E930-46D0-8417-97E4DD0F4D88@Isode.com> References: <65D1BC4F-E930-46D0-8417-97E4DD0F4D88@Isode.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <65C2B987-7782-4F07-AAE7-D8FF35A50A60@osafoundation.org> Content-Transfer-Encoding: 7bit From: Lisa Dusseault Subject: Re: [APPS-REVIEW] Apps Review of individual submissions in the Area Date: Fri, 18 May 2007 13:08:58 -0700 To: Kurt Zeilenga X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: apps-review@ietf.org X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Applications Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: apps-review-bounces@ietf.org I think that would be terrific. Actually I've gotten some pushback about the number of individual drafts I've sponsored -- there are a number of arguments against overusing that practice ( gives additional advantage to "insider" authors, may be harder to really determine consensus, doesn't engage as broad a community that may be implementors later...) However as long as we do sponsor individual submissions, having good reviews is always a bonus. I am currently doing AD review on draft-crispin-collation-unicasemap and draft-hartman-webauth-phishing (Informational) as individual submissions and would love to get input on those. thx, Lisa On May 18, 2007, at 11:40 AM, Kurt Zeilenga wrote: > I think it would be wise to not only do reviews "by request" of WGs/ > authors, but provide > unsolicited reviews to other documents. As we don't have enough > reviewers to review > every document under IESG consideration, we could try to cover a > useful subset. > > One useful subset, which I think we have enough reviewers to > adequately cover, would > be all Apps Area individual submissions. > > Comments? > > -- Kurt > > > _______________________________________________ > APPS-REVIEW mailing list > APPS-REVIEW@ietf.org > https://www1.ietf.org/mailman/listinfo/apps-review _______________________________________________ APPS-REVIEW mailing list APPS-REVIEW@ietf.org https://www1.ietf.org/mailman/listinfo/apps-review Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp7N7-00036g-GT; Fri, 18 May 2007 14:40:13 -0400 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1Hp7N6-00036M-NJ for apps-review-confirm+ok@megatron.ietf.org; Fri, 18 May 2007 14:40:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hp7N3-00035x-Fn for apps-review@ietf.org; Fri, 18 May 2007 14:40:09 -0400 Received: from rufus.isode.com ([62.3.217.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hp7N2-0007Cd-74 for apps-review@ietf.org; Fri, 18 May 2007 14:40:09 -0400 Received: from [192.168.1.200] ((unknown) [24.182.55.218]) by rufus.isode.com (submission channel) via TCP with ESMTPA id for ; Fri, 18 May 2007 19:40:07 +0100 X-SMTP-Protocol-Errors: NORDNS Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <65D1BC4F-E930-46D0-8417-97E4DD0F4D88@Isode.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: apps-review@ietf.org From: Kurt Zeilenga Date: Fri, 18 May 2007 11:40:03 -0700 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [APPS-REVIEW] Apps Review of individual submissions in the Area X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Applications Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: apps-review-bounces@ietf.org I think it would be wise to not only do reviews "by request" of WGs/ authors, but provide unsolicited reviews to other documents. As we don't have enough reviewers to review every document under IESG consideration, we could try to cover a useful subset. One useful subset, which I think we have enough reviewers to adequately cover, would be all Apps Area individual submissions. Comments? -- Kurt _______________________________________________ APPS-REVIEW mailing list APPS-REVIEW@ietf.org https://www1.ietf.org/mailman/listinfo/apps-review Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmUiq-0004Lb-By; Fri, 11 May 2007 08:59:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmUip-0004LR-3y for apps-review@ietf.org; Fri, 11 May 2007 08:59:47 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmUin-0006Do-MY for apps-review@ietf.org; Fri, 11 May 2007 08:59:47 -0400 Received: from repmmr02.bea.com (repmmr02.bea.com [10.160.30.72]) by repmmg02.bea.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4BCxiPu017907 for ; Fri, 11 May 2007 05:59:44 -0700 Received: from rcpbex01.amer.bea.com (repbex01.bea.com [10.168.26.17] (may be forged)) by repmmr02.bea.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4BCxg7g024777 for ; Fri, 11 May 2007 05:59:43 -0700 Received: from 10.43.242.154 ([10.43.242.154]) by rcpbex01.amer.bea.com ([10.168.26.17]) with Microsoft Exchange Server HTTP-DAV ; Fri, 11 May 2007 13:00:31 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Fri, 11 May 2007 08:59:38 -0400 Subject: Re: [APPS-REVIEW] Updated Web Site From: Eric Burger To: Message-ID: Thread-Topic: [APPS-REVIEW] Updated Web Site Thread-Index: AceTyJXX1ESBkv+7EdusdgAWy4mm/wAA6Vom In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Applications Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: apps-review-bounces@ietf.org One correction - I attributed one too many reviews to Julian, so we need to assign more to him :) Again, thanks to Claudio, John, Alexey, Mark, Julian, and Thomas for their reviews. On 5/11/07 8:33 AM, "Eric Burger" wrote: > I've updated the web site with what I think has been reviewed. Thomas gets > the prize for doing the fastest review, and Julian gets the prize for doing > the most reviews. > > I renamed the Applications Review web page to make it manual-browser-address > friendly. It is now at: > http://www.standardstrack.com/ietf/apps-review/ > > If you can update me with your areas of interest / expertise, that would be > great. However, that is no guarantee that I still won't randomly assign a > draft to you. > > Thanks. > > -- > Eric, your AARD (looking for some acronym for VARK) > > > Notice: This email message, together with any attachments, may contain > information of BEA Systems, Inc., its subsidiaries and affiliated > entities, that may be confidential, proprietary, copyrighted and/or > legally privileged, and is intended solely for the use of the individual or > entity named in this message. If you are not the intended recipient, and have > received this message in error, please immediately return this by email and > then delete it. > > _______________________________________________ > APPS-REVIEW mailing list > APPS-REVIEW@ietf.org > https://www1.ietf.org/mailman/listinfo/apps-review > Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ APPS-REVIEW mailing list APPS-REVIEW@ietf.org https://www1.ietf.org/mailman/listinfo/apps-review Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmUJe-0003ez-5h; Fri, 11 May 2007 08:33:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmUJb-0003eA-NQ for apps-review@ietf.org; Fri, 11 May 2007 08:33:44 -0400 Received: from repmmg02.bea.com ([66.248.192.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmUJa-00035M-A1 for apps-review@ietf.org; Fri, 11 May 2007 08:33:43 -0400 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4BCXeaf023414 for ; Fri, 11 May 2007 05:33:40 -0700 Received: from rcpbex01.amer.bea.com (rcpbex01.bea.com [10.168.26.17]) by repmmr01.bea.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l4BCXa6D030214 for ; Fri, 11 May 2007 05:33:36 -0700 Received: from 10.43.242.154 ([10.43.242.154]) by rcpbex01.amer.bea.com ([10.168.26.17]) with Microsoft Exchange Server HTTP-DAV ; Fri, 11 May 2007 12:34:25 +0000 User-Agent: Microsoft-Entourage/11.3.3.061214 Date: Fri, 11 May 2007 08:33:32 -0400 From: Eric Burger To: Message-ID: Thread-Topic: Updated Web Site Thread-Index: AceTyJXX1ESBkv+7EdusdgAWy4mm/w== Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [APPS-REVIEW] Updated Web Site X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Applications Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: apps-review-bounces@ietf.org I've updated the web site with what I think has been reviewed. Thomas gets the prize for doing the fastest review, and Julian gets the prize for doing the most reviews. I renamed the Applications Review web page to make it manual-browser-address friendly. It is now at: http://www.standardstrack.com/ietf/apps-review/ If you can update me with your areas of interest / expertise, that would be great. However, that is no guarantee that I still won't randomly assign a draft to you. Thanks. -- Eric, your AARD (looking for some acronym for VARK) Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ APPS-REVIEW mailing list APPS-REVIEW@ietf.org https://www1.ietf.org/mailman/listinfo/apps-review