From GK-lists@ninebynine.org Sun Feb 28 10:24:43 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FCFA28C170 for ; Sun, 28 Feb 2010 10:24:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.93 X-Spam-Level: X-Spam-Status: No, score=-2.93 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DATE_IN_PAST_06_12=1.069, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 059wt8PFgyS8 for ; Sun, 28 Feb 2010 10:24:41 -0800 (PST) Received: from relay6.mail.ox.ac.uk (relay6.mail.ox.ac.uk [163.1.2.167]) by core3.amsl.com (Postfix) with ESMTP id CA2F428C16B for ; Sun, 28 Feb 2010 10:24:41 -0800 (PST) Received: from smtp0.mail.ox.ac.uk ([129.67.1.205]) by relay6.mail.ox.ac.uk with esmtp (Exim 4.71) (envelope-from ) id 1Nlnom-00061g-M5; Sun, 28 Feb 2010 18:24:40 +0000 Received: from gklyne.plus.com ([80.229.154.156] helo=Eskarina.local) by smtp0.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Nlnom-0003xP-1l; Sun, 28 Feb 2010 18:24:40 +0000 Message-ID: <4B8A5AF1.6010202@ninebynine.org> Date: Sun, 28 Feb 2010 12:00:49 +0000 From: Graham Klyne User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Aaron Stone Subject: Re: LDAP outcome entry References: <4B82AF43.1090304@dcrocker.net> <4B838DBB.4060804@ninebynine.org> <1629dc8c1002231108s49c3ce70lda09b38eeb6f6a20@mail.gmail.com> In-Reply-To: <1629dc8c1002231108s49c3ce70lda09b38eeb6f6a20@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 X-Mailman-Approved-At: Mon, 01 Mar 2010 08:16:19 -0800 Cc: discuss@apps.ietf.org, dcrocker@bbiw.net X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Feb 2010 18:24:43 -0000 Aaron Stone wrote: >> It also appears to be a popular >> authorization framework for use with Samba. > > I wish it were easier to deploy small setups for home and small > business users, though :\ Me too! We're trying to create a kind of ready-to-go environment for this, but it's a struggle: http://imageweb.zoo.ox.ac.uk/wiki/index.php/ADMIRAL_LSDS_setup http://imageweb.zoo.ox.ac.uk/wiki/index.php/Zakynthos_Configuration #g From dougb@dougbarton.us Sun Feb 28 18:45:20 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55EAC3A88C0 for ; Sun, 28 Feb 2010 18:45:20 -0800 (PST) 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_50=0.001, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GbKpNYvB6Uqv for ; Sun, 28 Feb 2010 18:45:20 -0800 (PST) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by core3.amsl.com (Postfix) with ESMTP id C7BD33A862F for ; Sun, 28 Feb 2010 18:45:19 -0800 (PST) Received: (qmail 32682 invoked by uid 399); 1 Mar 2010 02:38:31 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 1 Mar 2010 02:38:31 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4B8B2894.40702@dougbarton.us> Date: Sun, 28 Feb 2010 18:38:12 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.7) Gecko/20100218 Thunderbird/3.0.1 MIME-Version: 1.0 To: Michelle Cotton Subject: Re: [DNSOP] New version of document for review References: In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: id=D5B2F0FB Content-Type: multipart/mixed; boundary="------------030700080506000703090203" X-Mailman-Approved-At: Mon, 01 Mar 2010 08:16:19 -0800 Cc: "dnsop@ietf.org" , "tsvwg@ietf.org" , "apps-discuss@ietf.org" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Mar 2010 02:45:20 -0000 This is a multi-part message in MIME format. --------------030700080506000703090203 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 On 01/15/10 08:16, Michelle Cotton wrote: > Attn: TSVWG Working Group, DNSOPS Working Group and APPS AREA Working Group > > There is a new version of the Internet Assigned Numbers Authority (IANA) > Procedures for the Management > of the Transport Protocol Port Number and Service Name Registry document: > > draft-ietf-tsvwg-iana-ports-04.txt > > Please review and send comments. Your feedback is much appreciated. I'm writing to provide both review and support of this draft. Before I do however it's probably useful for me to make some explicit statements, some of the "should go without saying" variety and some to provide context for my comments. I was the General Manager of the IANA from late 2003 through mid 2005. In that capacity I was proud to manage Michelle as one of my employees. One of my responsibilities was to oversee the port number allocation process, including occasionally making the final decisions on these assignments myself. Other than her public messages regarding these drafts I have had no communication from Michelle or anyone else from ICANN regarding this topic. Other than this message today I've not communicated with them about it. (IOW, ETINC.) I also have experience with port numbers from the operating system implementer's perspective as part of a large group of people who have "commit privileges" to the FreeBSD code base. With all that out of the way, I would like to commend Michelle and the other authors on this much needed piece of work. It is clear, well written, and covers the topic very well. I know that I would very much like to have had such a clear set of guidelines to operate under while I was making these decisions. I do have some feedback, none of which I consider to be show-stopper issues. If the draft were to progress in its current condition I would be supportive. I also think it is important to move this draft forward sooner rather than later since it will allow us to start using, and encouraging the use of SRV in a much more meaningful way. I've attached a diff with some mostly minor edits. Most of them are simple English language nits such as: 1. Comma reduction (a topic which I'm very sensitive to since it's one of my major faults when writing) 2. Capitalizing the first letter of bullet points I've also included some textual changes which I hope improve and/or clarify the text. In all cases the authors are free to adopt or deny my suggestions as they see fit. More substantive issues, in more or less increasing order of importance. * In Section 3 I think the readability would improve by switching the first and second paragraphs. * In Section 7.2, paragraph 7, I think the change to "IANA converting the reservation" makes the desired outcome (that designers not use the port without IANA authorizing the change) more clear. * In Section 8.1 (and/or perhaps elsewhere?) I think it would be useful to suggest (perhaps at the SHOULD level?) that when appropriate the administrative contact e-mail address should be a role account, and the problem this is designed to mitigate (individuals sometimes leave the company/organization that is responsible for the assignment resulting in a dead e-mail address). * In Section 6 (and elsewhere) there does not appear to be a normative reference for the division of port numbers into the Well Known, Registered, and Dynamic categories. * Section 7.2 mentions several suggestions to designers for reducing the number of port numbers that they need for an application. I think it would be useful to add 2 explicit suggestions to that list, one is the idea of a "master" application with one Registered port number that can coordinate communications between the various components of more complicated applications without requiring each element of the application to have its own assigned port number. The other suggestion I think should be made explicitly in the document is the use of multicast DNS to avoid port number assignments altogether. My final area of concern is the idea people have that without an assigned port number from IANA that no firewall administrators will allow their traffic. You mention this issue briefly in 7.2, and in Section 9 (Security Considerations) you include the text that I wrote in number 2 of "PLEASE NOTE THE FOLLOWING" on the http://www.iana.org/assignments/port-numbers page, both of which I think are good things to include. However I believe that it would be useful to have the whole concept described in more detail in 7.2. In my communication with port number applicants this issue came up over and over again, and was either the primary or sole consideration in filing the application in the first place; resulting in more than one otherwise-spurious application. I won't quibble if my opinion on the importance of this topic isn't shared by others, but I felt it was important to mention it. I hope that these comments are helpful, and I apologize for not offering them sooner. Best regards, Doug - -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEAREDAAYFAkuLKJQACgkQyIakK9Wy8PtcaACg5lEBJw12OwUGCn6i98VDlkHQ oI0AoLfNB0fMMGJ42dPV6d38V+i3pPr0 =giEw -----END PGP SIGNATURE----- --------------030700080506000703090203 Content-Type: text/plain; name="draft-ietf-tsvwg-iana-ports-04.txt-diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-ietf-tsvwg-iana-ports-04.txt-diff" --- draft-ietf-tsvwg-iana-ports-04.txt-orig 2010-02-28 13:22:59.000000000 -0800 +++ draft-ietf-tsvwg-iana-ports-04.txt 2010-02-28 17:44:08.000000000 -0800 @@ -209,7 +209,7 @@ This document updates IANA's procedures for UDP and TCP port numbers by obsoleting Sections 8 and 9.1 of the IANA allocation guidelines [RFC2780]. (Note that different sections of the IANA allocation - guidelines, relating to the protocol field values in IPv4 header, + guidelines, relating to the protocol field values in IPv4 headers, were also updated in February 2008 [RFC5237].) This document also updates the IANA allocation procedures for DCCP [RFC4340] and SCTP [RFC4960]. @@ -225,11 +225,11 @@ uses the same set of port number values assigned by the IANA for use - by UDP". Thus the update of UDP procedures result in an update also - of the UDP-Lite procedures. + by UDP". Thus the update of UDP procedures also results in a + corresponding update of the UDP-Lite procedures. - This document also clarify what a service name is and how it is - registered. This will impact the DNS SRV specification, because that + This document also clarifies what a service name is and how it is + registered. This will impact the DNS SRV specification because that specification merely makes a brief mention that the symbolic names of services are defined in "Assigned Numbers" [RFC1700], without stating to which section of that 230-page document it refers. The DNS SRV @@ -254,7 +254,7 @@ Similarly, the procedures surrounding service names have been historically unclear. Service names were originally created as - mnemonic identifiers for port numbers without a well-defined syntax, + mnemonic identifiers for port numbers without a well-defined syntax beyond the 14-character limit mentioned on the IANA website [SYSFORM] [USRFORM]. Even that length limit has not been consistently applied, and some assigned service names are 15 characters long. When service @@ -268,8 +268,8 @@ for both port numbers and service names. It gives more detailed guidance to prospective requesters of ports and service names than the existing documentation, and it streamlines the IANA procedures - for the management of the registry, so that management requests can - complete in a timely manner. + for the management of the registry so that management requests can + be completed in a timely manner. This document defines rules for registration of service names without @@ -292,7 +292,7 @@ that guide the IETF and IANA in their role as the long-term joint stewards of the port number registry. TCP and UDP have been a remarkable success over the last decades. Thousands of applications - and application-level protocols have registered ports and service + and application-level protocols have registered port numbers and service names for their use, and there is every reason to believe that this trend will continue into the future. It is hence extremely important that management of the registry follow principles that ensure its @@ -321,7 +321,7 @@ application and service identification on the Internet. Ports are 16-bit numbers, and the combination of source and destination port numbers together with the IP addresses of the communicating end - systems uniquely identifies a session of a given transport protocol. + systems uniquely identify a session of a given transport protocol. Port numbers are also known by their corresponding service names such as "telnet" for port number 23 and "http" (and the "www" alias) for port number 80. @@ -366,11 +366,12 @@ to IANA for an assigned port number and service name for a specific application, and may - after successful registration - assume that no other application will use that port number or service name for its - communication sessions. Alternatively, application designers may - also ask for only an assigned service name, if their application does - not require a fixed port number. The latter alternative is - encouraged when possible, in order to conserve the more limited port - number space. This includes, for example, applications that use DNS + communication sessions. Application designers also have the option + of requesting an assigned service name without a corresponding fixed + port number if their application does not require one. Because the + number of fixed port numbers is finite (and therefore conservation + is an important goal) the latter alternative is encouraged whenever possible. + This includes, for example, applications that use DNS SRV records to look up port numbers at runtime. @@ -394,12 +395,12 @@ registry. This unique symbolic name for a service may also be used for other purposes, such as in DNS SRV records [RFC2782]. Within the - registry, this unique key ensures that different services can be + registry this unique key ensures that different services can be unambiguously distinguished, thus preventing name collisions and avoiding confusion about who is the administrative contact for a particular entry. - For each service name, there may exist zero or more associated port + For each service name there may exist zero or more associated port number assignments. A port number assignment associated with a service name contains the transport protocol, port number and possibly additional data, such as a DCCP service code. @@ -407,7 +408,7 @@ There may be more than one service name associated with a particular transport protocol and port. This SHOULD only occur when all such service names are aliases for the same service, such as with "http" - and "www". In such cases, one of the service names MUST be + and "www". In such cases one of the service names MUST be designated primary, for use with mechanisms such as DNS SRV Records [RFC2782], and the others MUST be designated as aliases of the primary service name. This is necessary so that all clients and @@ -485,7 +486,7 @@ The details of how applications make use of DNS SRV should be specified in the documentation set of the application/service. In - the absense of such specification, prospective clients of a given + the absence of such specification, prospective clients of a given service should not assume the existence of SRV RRs for this service or, if they have indications that this will be the case (e.g., by configuration), must assume the unextended naming scheme from @@ -507,17 +508,17 @@ 6. Port Number Ranges TCP, UDP, UDP-Lite, SCTP and DCCP use 16-bit namespaces for their - port number registries. The port registries for all these transport + port number registries. The port registries for all of these transport protocols are subdivided into three ranges of numbers, and Section 7.3 describes the IANA procedures for each range in detail: - o the Well Known Ports, also known as the System Ports, from 0-1023 + o The Well Known Ports, also known as the System Ports, from 0-1023 (assigned by IANA) - o the Registered Ports, also known as the User Ports, from 1024- + o The Registered Ports, also known as the User Ports, from 1024- 49151 (assigned by IANA) - o the Dynamic Ports, also known as the Private Ports, from 49152- + o The Dynamic Ports, also known as the Private or Ephemeral Ports, from 49152- 65535 (never assigned) Of the assignable port ranges (Well Known and Registered, i.e., port @@ -537,7 +538,7 @@ e.g., 0, 1023, 1024, etc., which may be used to extend these ranges or the overall port number space in the future. - In order to keep the size of the registry manageable, IANA typically + In order to keep the size of the registry manageable IANA typically only records the Assigned and Reserved port numbers and service names in the registry. Unassigned values are typically not explicitly listed. @@ -571,7 +572,7 @@ for experimentation with new application-layer protocols over SCTP and DCCP in Section 10.2. - Unfortunately, it can be difficult to limit access to these ports. + Unfortunately it can be difficult to limit access to these ports. Users SHOULD take measures to ensure that experimental ports are connecting to the intended process. For example, users of these experimental ports might include a 64-bit nonce, once on each segment @@ -589,22 +590,22 @@ well as coordination of information about existing allocations. The latter includes maintaining contact and description information about assignments, revoking abandoned assignments, and redefining - assignments when needed. Of these procedures, port number allocation - is most critical, in order to continue to conserve the remaining port + assignments when needed. Of these procedures port number allocation + is the most critical in order to continue to conserve the remaining port numbers. - As noted earlier, only ~9% of the Registered Port space is currently + As noted earlier only ~9% of the Registered Port space is currently assigned. The current rate of assignment is approximately 400 ports/ year, and has remained linear for the past 8 years. At that rate, if similar conservation continues, this resource will sustain another 85 years of assignment - without the need to resort to reassignment of released values or revocation. Note that the namespace available for service names is even larger, which allows for a simpler management - procedures. + procedure. 7.1. Past Principles - Before the publication of this document, the principles of port + Before the publication of this document the principles of port number and service name management followed a few mostly-undocumented guidelines. They are recorded here for historical purposes, and this document updates them in Section 7.2. These principles were: @@ -639,20 +640,21 @@ 7.2. Updated Principles - This section summarizes the basic principles by which IANA handles + This section summarizes the basic principles by which IANA both handles the Port and Service Name registry, and attempts to conserve the port number space. This description is intended to inform applicants - requesting service names and port numbers. IANA decisions are not - required to be bound to these principles, however; other factors may - come into play, and exceptions may occur where deemed in the best - interest of the Internet. + requesting service names and port numbers. + However other factors may + come into play, and exceptions may occur when deemed in the best + interest of the Internet. Thus applicants should be aware that + IANA decisions are not required to be bound to these principles, IANA will begin assigning service names that do not request a corresponding port number allocation under a simple "First Come, First Served" policy [RFC5226]. IANA MAY, at its discretion, refer service name requests to "Expert Review" in cases of mass registrations or other situations where IANA believes expert review - is advisable. + is advisable [RFC5226]. The basic principle of port number registry management is to conserve use of the port space where possible. Extensions to support larger @@ -694,8 +696,8 @@ de-registration, revocation, and transfer A given service is expected to further demultiplex messages where - possible. For example, applications and protocols are expected to - include in-band version information, so that future versions of the + possible. For example applications and protocols are expected to + include in-band version information so that future versions of the application or protocol can share the same allocated port. Applications and protocols are also expected to be able to efficiently use a single allocated port for multiple sessions, either @@ -705,11 +707,11 @@ Ports are used in various ways, notably: - o as endpoint process identifiers + o As endpoint process identifiers - o as application protocol identifiers + o As application protocol identifiers - o for firewall filtering purposes + o For firewall filtering purposes The process and protocol identifier use suggests that anything a single process can demultiplex, or that can be encoded into a single @@ -736,26 +738,27 @@ IANA will begin assigning protocol numbers for only those transport protocols explicitly included in a registration request. This ends the long-standing practice of automatically assigning a port number - to an application for both TCP and a UDP, even if the request is for + to an application for both TCP and UDP, even if the request is for only one of these transport protocols. The new allocation procedure conserves resources by allocating a port number to an application for only those transport protocols (TCP, UDP, SCTP and/or DCCP) it - actually uses. The port number will be marked as Reserved - instead - of Assigned - in the port number registries of the other transport - protocols. When applications start supporting the use of some of - those additional transport protocols, their implementors MUST request + actually uses. In the port number registries of the other transport + protocols the port number will be marked as Reserved instead + of Assigned. + When applications start supporting the use of some of + those additional transport protocols, their implementers MUST request IANA to convert the reservation into an assignment. An application MUST NOT assume that it can use a port number assigned to it for use with one transport protocol with another transport protocol without - asking IANA to convert the reservation into an assignment. + IANA converting the reservation into an assignment. - When the available pool of unassigned address has run out in a port - range, it will be necessary for IANA to consider the Reserved ports - for assignment. This is part of the motivation to not automatically - assigning ports for other transport protocols than the requested - ones. This will allow more ports to be available for assignment at - that point. It also shows the importance to register the transport - protocols that are in fact used. + When the available pool of unassigned numbers has run out in a port + range it will be necessary for IANA to consider the Reserved ports + for assignment. This is part of the motivation for not automatically + assigning ports for transport protocols other than the requested + one(s). This will allow more ports to be available for assignment at + that point. It also shows the importance of registering only the transport + protocols that are actually used. Conservation of port numbers is improved by procedures that allow previously allocated port numbers to become Unassigned, either @@ -764,7 +767,7 @@ number to a new application. Section 8 describes these procedures, which so far were undocumented. Port number conservation is also improved by recommending that applications that do not require an - allocated port chose this option and register only a service name. + allocated port choose this option and register only a service name. 7.3. Variances for Specific Port Number Ranges @@ -842,7 +845,7 @@ name is appropriate for this action. - When a registration for one or more transport protocols is approved, + When a registration for one or more transport protocols is approved the port number for any non-requested transport protocol(s) will be marked as Reserved. IANA SHOULD NOT assign that port number to any other application or service until no other port numbers remain @@ -903,9 +906,9 @@ one or more technical contact persons SHALL be provided. o Service Name: A desired unique service name for the service - associated with the registration request MUST be provided, for use - in various service selection and discovery mechanisms (including, - but not limited to, DNS SRV records [RFC2782]). The name MUST be + associated with the registration request MUST be provided. This name will be used + in various service selection and discovery mechanisms including, + but not limited to, DNS SRV records [RFC2782]. The name MUST be compliant with the syntax defined in Section 5.1. In order to be unique, they MUST NOT be identical to any currently registered service names in the IANA registry [PORTREG]. Service names are --------------030700080506000703090203-- From julian.reschke@gmx.de Mon Mar 1 08:39:31 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDEAA28C2EC for ; Mon, 1 Mar 2010 08:39: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=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pzBU44FG1FYv for ; Mon, 1 Mar 2010 08:39:31 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 841A03A879D for ; Mon, 1 Mar 2010 08:39:30 -0800 (PST) Received: (qmail invoked by alias); 01 Mar 2010 16:39:26 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.119]) [217.91.35.233] by mail.gmx.net (mp050) with SMTP; 01 Mar 2010 17:39:26 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19QAY4/NcdQ6ZZMlm5DRcMPQD87lp0RRndsDtx98Q WP64FKJ9Lk8lrw Message-ID: <4B8BEDBB.9050807@gmx.de> Date: Mon, 01 Mar 2010 17:39:23 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Thomas Roessler Subject: Re: draft-reschke-rfc2231-in-http: section 4.2, Error Handling References: <4c80fa21002241136y629dda22l1d7617eb25250af8@mail.gmail.com> <4B87F0FB.6090605@gmx.de> <4c80fa21002260942g3aacf02ak20510ca9d9c0659@mail.gmail.com> In-Reply-To: <4c80fa21002260942g3aacf02ak20510ca9d9c0659@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.64000000000000001 Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Mar 2010 16:39:31 -0000 On 26.02.2010 18:42, Thomas Roessler wrote: > On Fri, Feb 26, 2010 at 5:04 PM, Julian Reschke wrote: > >>> Leaving the choice of precedence to the header specification implies >>> that parsers need to special-case. It would seem reasonable to make a >>> choice in this specification that for properties which can only occur >>> once, the traditional syntax takes precedence. >> >> That would rule out the use case where the traditional syntax is used as a >> fallback for clients that do not support the new syntax, as discussed in >> that section: >> >> "Header specifications that include parameters should also specify whether >> same-named parameters can occur multiple times. If repetitions are not >> allowed (and this is believed to be the common case), the specification >> should state whether regular or the extended syntax takes precedence. In the >> latter case, this could be used by producers to use both formats without >> breaking recipients that do not understand the syntax. > > That's a compelling argument for choosing "new style takes precedence" > in the spec; I don't know of good arguments the other way. > > My main point is that I think we should make a choice (and either of > the possible choices sounds reasonable), not which of the specific > choices it should be. Ok, let's make that choice, this would result in: Header specifications that include parameters should also specify whether same-named parameters can occur multiple times. If repetitions are not allowed (and this is believed to be the common case), the specification should state that the extended syntax takes precedence. This could be used by producers to use both formats without breaking recipients that do not understand the syntax. However, that would still only be a recommendation -- so if a header definition deviated from that, a generic processor wouldn't be usable (or return the wrong choice). Would that be ok, or are we prepared to mandate a choice here? Best regards, Julian From mnot@mnot.net Mon Mar 1 15:40:25 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36F503A8BE0 for ; Mon, 1 Mar 2010 15:40:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.421 X-Spam-Level: X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[AWL=-2.040, BAYES_00=-2.599, TVD_SPACE_RATIO=2.219] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d5-4se8z4ggG for ; Mon, 1 Mar 2010 15:40:23 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id 9AC2B3A8BEC for ; Mon, 1 Mar 2010 15:40:11 -0800 (PST) Received: from chancetrain-lm.mnot.net (unknown [118.209.189.113]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 7B4C8509DE for ; Mon, 1 Mar 2010 18:40:05 -0500 (EST) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Fwd: New Version Notification - draft-nottingham-http-link-header-08.txt Date: Tue, 2 Mar 2010 10:40:00 +1100 References: <20100301130001.D418D3A876E@core3.amsl.com> To: Apps Discuss Message-Id: <0E11EDE7-0AB7-4195-9BD1-D43D6B41F3F6@mnot.net> Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Mar 2010 23:40:25 -0000 Begin forwarded message: > From: Internet-Draft@ietf.org > Date: 2 March 2010 12:00:01 AM AEDT > To: mnot@pobox.com, = draft-nottingham-http-link-header@tools.ietf.org,lisa.dusseault@gmail.com > Subject: New Version Notification - = draft-nottingham-http-link-header-08.txt >=20 > New version (-08) has been submitted for = draft-nottingham-http-link-header-08.txt. > = http://www.ietf.org/internet-drafts/draft-nottingham-http-link-header-08.t= xt >=20 >=20 > Diff from previous version: > = http://tools.ietf.org/rfcdiff?url2=3Ddraft-nottingham-http-link-header-08 >=20 > IETF Secretariat. -- Mark Nottingham http://www.mnot.net/ From lisa.dusseault@gmail.com Mon Mar 1 19:06:18 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B08E03A88BC for ; Mon, 1 Mar 2010 19:06:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wW09Esmh-xNR for ; Mon, 1 Mar 2010 19:06:17 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id B4C2A3A88B7 for ; Mon, 1 Mar 2010 19:06:17 -0800 (PST) Received: by vws20 with SMTP id 20so1395117vws.31 for ; Mon, 01 Mar 2010 19:06:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=tho0Hfq/TbNdx3ANgcEK6m7luIvXYp5HrBGTqX3YaMc=; b=HgPGsXGGU49Z/NGL7Wnht6q2mO/OOImWZrMKbbCUYbGmA989OeII0ubtMZWkW7j4pz NQdMdkWWhP2/oNuIyfxCD4izTpkkwYUWFvqW93tCMk/dZyJ4/O7oQEkY7aJqM0B41gOC oTm5X86oCCJGeY4u9a/hhryFIqm9n8lfXOpzg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=VEitdi4ZUb8u4g27scM4qTs1Au210gaq8VYFsK8ilbXgYE/Hbwyy4ROPIIc9wMl3dj vXOzKGTmk9AI2T4wMdJ7OX8fjXbnyTftLVsqE8IaN+XhmJlf+ub2ZYN9iovaQ9sN6nCR r8qZlPZHFge/uY8Enniu3sD0wJ2IkUwvtHtXA= MIME-Version: 1.0 Received: by 10.220.108.27 with SMTP id d27mr3738756vcp.124.1267499174843; Mon, 01 Mar 2010 19:06:14 -0800 (PST) Date: Mon, 1 Mar 2010 19:06:14 -0800 Message-ID: Subject: Lisa's Apps Area Activity Report for Feb 2010 From: Lisa Dusseault To: lisa-dusseault-chairs@tools.ietf.org, discuss@ietf.org Content-Type: multipart/alternative; boundary=00c09f8de4f011d5350480c8a679 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 03:06:18 -0000 --00c09f8de4f011d5350480c8a679 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable *News, Updates* CORE, formerly known as 6LOWAPP, is now in the charter-approval process. This is my last report before handing over to Peter St. Andr=E9 and Alexey Melnikov. Most of the WGs I advised are now in Peter's hands but Alexey ha= s taken on a couple. *Document Status and Progress* *Active documents, my action:* - draft-ietf-idnabis-mappings (Info): Working with chair on how to determin= e WG consensus for status of this doc - draft-nottingham-http-link-header (PS): AD Review of latest changes *Active documents, waiting on other:* - draft-giralt-schac-ns (Info): Revised ID needed - draft-larmouth-oid-uri (PS): Revised ID Needed (response to expert review & my own questions) - draft-reschke-webdav-post (Exp): Cyrus Daboo is doing shepherd review and writeup *Finished processing -- new in RFC Ed queue and new RFCs* - draft-bryan-metalink (PS): Approved - draft-ietf-idnabis-bidi (PS): Approved - draft-hammer-oauth (Info): Approved - draft-bryan-http-digest-algorithm-values-update (Info): approved *WG Status* ALTO: Now using an issue tracker; meeting at IETF 77 CALSIFY: No WG activity in Feb, no meeting at IETF 77. HTTPBIS: Planning to meet at IETF77. HTTPSTATE: Resolving issues in Adam's draft. HYBI: Much debate on requirements. IDNABIS: AD & authors & chair are still discussing idnabis-mappings. OAUTH: Discussion of WRAP requirements & authentication requirements SIEVE: renewed activity over adopting a couple more docs --00c09f8de4f011d5350480c8a679 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable News, Updates
CORE, formerly known as=A0 6LOWAPP, is now in the c= harter-approval process.
This is my last report before handing over to = Peter St. Andr=E9 and Alexey Melnikov.=A0 Most of the WGs I advised are now= in Peter's hands but Alexey has taken on a couple.

Document Status and Progress

Active documents, my action:
- dr= aft-ietf-idnabis-mappings=20 (Info): Working with chair on how to determine WG consensus for status=20 of this doc
- draft-nottingham-http-link-header (PS): AD Review of latest changes

Active documents, waiting on other:
- draft-giralt-schac-ns= =20 (Info): Revised ID needed
- draft-larmouth-oid-uri (PS): Revised=20 ID Needed (response to expert review & my own questions)
-=20 draft-reschke-webdav-post (Exp): Cyrus Daboo is doing shepherd review=20 and writeup

Finished processing -- new in RFC Ed queue and n= ew=20 RFCs
- draft-bryan-metalink (PS): Approved
- draft-ietf-idnabis-bidi (PS): App= roved
- draft-hammer-oauth (Info): Approved
-=20 draft-bryan-http-digest-algorithm-values-update (Info): approved

WG Status

ALTO: Now using an issue tracker; meeting at IE= TF 77
CALSIFY: No WG activity in Feb, no meeting at IETF 77.
HTTPBIS= : Planning to meet at IETF77.
HTTPSTATE: Resolving issues in Adam's draft.
HYBI: Much debate on requirements.
IDNABIS: AD & authors & chair are = still discussing idnabis-mappings.
OAUTH: Discussion of WRAP requirements & authentication requirements
SIEVE: renewed activity over adopting a couple more docs
--00c09f8de4f011d5350480c8a679-- From skissane@gmail.com Mon Mar 1 21:47:28 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D7D028C64D for ; Mon, 1 Mar 2010 21:47:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QVl6k0B9gtox for ; Mon, 1 Mar 2010 21:47:27 -0800 (PST) Received: from mail-pz0-f176.google.com (mail-pz0-f176.google.com [209.85.222.176]) by core3.amsl.com (Postfix) with ESMTP id 9A88D28C54F for ; Mon, 1 Mar 2010 21:47:27 -0800 (PST) Received: by pzk6 with SMTP id 6so694921pzk.10 for ; Mon, 01 Mar 2010 21:47:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=OZ4/SMtrMUvmV7E95oD9JhsDe4Ot4OLm0bY7rtitZaw=; b=Aw2dp31WJmg+53Vdt6kclaC1EbuD8fBwEYXlPkSgOcRGMppl23BatKz0za9fueI0cd xNH14i49/Yv73+mlu8+9x8MK/rxQekOmbxhVW1BqQJtL4fipmTrYyXgN4jEjScykFUZg XPAwh/HbxVMbaYnAXap3CV+QZZ5BmNCEQp0PE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=OSJq5bwJz6tuyLpOtkBR9AH3Tfi35BIjti5h19Cr/TfO8++gerJ+pgC6t7IpOgNMsL 8vyhrr0hGkwhBxgKBaEUT9HS6E3/qhL4PrYoNqrjTZYgB8MPtTWQ4x4C5N4Stl+uw6xD h023+3DUzF5SYmB9ckJ5Q4Dtsw7BFMmW8YieY= MIME-Version: 1.0 Received: by 10.115.84.18 with SMTP id m18mr3193952wal.70.1267508781639; Mon, 01 Mar 2010 21:46:21 -0800 (PST) In-Reply-To: <4B845A18.5010603@dcrocker.net> References: <4B82AF43.1090304@dcrocker.net> <4B838DBB.4060804@ninebynine.org> <1629dc8c1002231108s49c3ce70lda09b38eeb6f6a20@mail.gmail.com> <4B845A18.5010603@dcrocker.net> Date: Tue, 2 Mar 2010 16:46:21 +1100 Message-ID: <82fa66381003012146k50b5c38cy5ce5c3a4724e034b@mail.gmail.com> Subject: Re: LDAP outcome entry From: SJ Kissane To: dcrocker@bbiw.net Content-Type: multipart/alternative; boundary=0016e64ccddcade8e90480cae244 Cc: discuss@apps.ietf.org, Graham Klyne X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 05:47:28 -0000 --0016e64ccddcade8e90480cae244 Content-Type: text/plain; charset=ISO-8859-1 On 24 February 2010 09:43, Dave CROCKER wrote: > 2. LDAP is not (widely) deployed or used across the open Internet, for use > between random pairs. > I'm not sure it ever will. From a policy/legal viewpoint, sharing user identity data between independent organizations has major privacy and security concerns, and LDAP doesn't tend to be a good fit for managing that in practice. In particular it doesn't support ideas like end user opt-in, or letting users know who knows what about them. Newer federation technologies like SAML, Liberty, WS-Federation, etc., tend to be a better fit for that space. > I am not sure whether there are restrictions that should be applied, about > the /type/ of Enterprise that is popular for LDAP use. I'd guess > medium-to-large Enterprises, more than small, but could imagine otherwise. > It's probably not essential to get agreement on this, but the agreement > might solidify agreement about whether LDAP is essential. > I would agree its mainly medium-to-large enterprises - to my knowledge, all major enterprise ERP packages (e.g. Peoplesoft, SAP) support LDAP, all the major enterprise collaboration suites (e.g. Notes/Domino, Exchange, GroupWise, etc.) are based on LDAP, all major operating systems support LDAP for user authentication, etc. But given products like Microsoft Small Business Server, there's likely even many small business running an LDAP without even realising it. cheers Simon Kissane --0016e64ccddcade8e90480cae244 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On 24 February 2010 09:43, Dave CROCKER <dhc@dcrocker.net><= /span> wrote:
2. LDAP is not (widely) deployed or used across the open Internet, for use = between random pairs.
I'm not sure it ever will. F= rom a policy/legal viewpoint, sharing user identity data between independen= t organizations has major privacy and security concerns, and LDAP doesn'= ;t tend to be a good fit for managing that in practice. In particular it do= esn't support ideas like end user opt-in, or letting users know who kno= ws what about them. Newer federation technologies like SAML, Liberty, WS-Fe= deration, etc., tend to be a better fit for that space.
=A0
I am not sure whether there are restrictions that should be applied, about = the /type/ of Enterprise that is popular for LDAP use. =A0I'd guess med= ium-to-large Enterprises, more than small, but could imagine otherwise. =A0= It's probably not essential to get agreement on this, but the agreement= might solidify agreement about whether LDAP is essential.
I would agree its mainly medium-to-large enterprises - to= my knowledge, all major enterprise ERP packages (e.g. Peoplesoft, SAP) sup= port LDAP, all the major enterprise collaboration suites (e.g. Notes/Domino= , Exchange, GroupWise, etc.) are based on LDAP, all major operating systems= support LDAP for user authentication, etc. But given products like Microso= ft Small Business Server, there's likely even many small business runni= ng an LDAP without even realising it.

cheers
Simon Kissane
--0016e64ccddcade8e90480cae244-- From julian.reschke@gmx.de Tue Mar 2 10:25:52 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F25653A680B for ; Tue, 2 Mar 2010 10:25:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.173 X-Spam-Level: X-Spam-Status: No, score=-3.173 tagged_above=-999 required=5 tests=[AWL=-0.574, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VpRlNNwp-uz4 for ; Tue, 2 Mar 2010 10:25:50 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 6BE0A28C170 for ; Tue, 2 Mar 2010 10:25:50 -0800 (PST) Received: (qmail invoked by alias); 02 Mar 2010 18:25:40 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.105]) [217.91.35.233] by mail.gmx.net (mp012) with SMTP; 02 Mar 2010 19:25:40 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19BiBo+U+lB6N2UodRwkjB3khuouVnKrtvlsSwryL F+UEI0hU9uQZvf Message-ID: <4B8D581F.7070905@gmx.de> Date: Tue, 02 Mar 2010 19:25:35 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Mark Nottingham Subject: Re: allowable characters in token as used in parameter ABNF References: <4B6C3BDC.8090709@gmx.de> <4B71645A.3070502@gmx.de> In-Reply-To: <4B71645A.3070502@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.5 Cc: Benjamin Carlyle , HTTP Working Group , IETF Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 18:25:52 -0000 Hi, adding apps-discuss to get more review... -- comments in-line. On 09.02.2010 14:34, Julian Reschke wrote: > Mark Nottingham wrote: >> Speaking personally -- >> >> I'm torn here. On one hand, I'd very much like to see best practice >> promoted here, because the wild-west situation of HTTP header parsing >> is one of the things I really dislike, and suspect causes a lot of >> problems. >> >> OTOH, we don't have any implementers stepping up and saying that >> they're eager, and in this situation it may be too easy to specify the >> wrong thing. >> >> AIUI the most liberal form of xtoken would be 1*VCHAR without DQUOTE, >> "," or ";". Correct? > > That will make it: > > "!" / "#" / "$" / "%" / "&" / "'" / "(" / ")" / "*" / "+" / "-" / "." / > "/" / DIGIT / ":" / "<" / "=" / ">" / "?" / "@" / ALPHA / "[" / "\" / > "]" / "^" / "_" / "`" / "{" / "|" / "}" / "~" > > which includes the following non-token characters: > > "(" / ")" / "/" / ":" / "<" / "=" / ">" / "?" / "@" / "[" / "\" / "]" / > "{" / "}" > > "(" and ")" *might* become a problem in headers that allow comments. > > "\" might be confused with the escape character in quoted strings and > comments. > > Other than that, I don't see a problem. In the meantime, Mark has added this as "ptoken" to the ABNF for the HTTP Link Header, see : ptoken = "!" | "#" | "$" | "%" | "&" | "'" | "(" | ")" | "*" | "+" | "-" | "." | "/" | DIGIT | ":" | "<" | "=" | ">" | "?" | "@" | ALPHA | "[" | "\" | "]" | "^" | "_" | "`" | "{" | "|" | "}" | "~" Are people ok with relaxing this, compared to RFC 2616 token characters? Assuming this is ok for parameters in the Link header, should I add a similar construct to draft-reschke-rfc2231-in-http, to promote re-use in new header definitions? > ... Best regards, Julian From alexey.melnikov@isode.com Tue Mar 2 14:14:15 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A94D28C28E for ; Tue, 2 Mar 2010 14:14:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lU+8yGayHRHk for ; Tue, 2 Mar 2010 14:14:12 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 9243528C27D for ; Tue, 2 Mar 2010 14:14:05 -0800 (PST) Received: from [172.16.2.121] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 2 Mar 2010 22:14:06 +0000 Message-ID: <4B8D8D74.8010502@isode.com> Date: Tue, 02 Mar 2010 22:13:08 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: apps-discuss@ietf.org Subject: Responsible ADs for various Apps Area WGs MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 22:14:15 -0000 Lisa already mentioned that after Anaheim I will be taking over some of her WGs, so I think it is a good idea to let people know how Peter and I are planning to split WGs: Peter: alto Application-Layer Traffic Optimization calsify Calendaring and Scheduling Standards Simplification iri Internationalized Resource Identifiers httpstate HTTP State Management Mechanism oauth Open Authentication Protocol vwrap Virtual World Region Agent Protocol vcarddav vCard and CardDAV 6lowapp - when chartered Alexey: eai Email Address Internationalization httpbis Hypertext Transfer Protocol Bis hybi BiDirectional or Server-Initiated HTTP idnabis Internationalized Domain Names in Applications, Revised marf Messaging Abuse Reporting Format morg Message Organization sieve Sieve Mail Filtering Language yam Yet Another Mail decade - if/when chartered From duerst@it.aoyama.ac.jp Thu Mar 4 03:05:38 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A47EB3A8913 for ; Thu, 4 Mar 2010 03:05:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.21 X-Spam-Level: X-Spam-Status: No, score=0.21 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wrY95tAt1ZaW for ; Thu, 4 Mar 2010 03:05:36 -0800 (PST) Received: from scmailgw01.scop.aoyama.ac.jp (scmailgw01.scop.aoyama.ac.jp [133.2.251.41]) by core3.amsl.com (Postfix) with ESMTP id 75EE03A890F for ; Thu, 4 Mar 2010 03:05:36 -0800 (PST) Received: from scmse02.scbb.aoyama.ac.jp (scmse02.scbb.aoyama.ac.jp [133.2.253.159]) by scmailgw01.scop.aoyama.ac.jp (secret/secret) with SMTP id o24B5R7v009173 for ; Thu, 4 Mar 2010 20:05:27 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 5285_2b3a_d6b1d2ba_277d_11df_8e4f_001d096c5782; Thu, 04 Mar 2010 20:05:27 +0900 Received: from [IPv6:::1] ([133.2.210.1]:51918) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Thu, 4 Mar 2010 20:05:26 +0900 Message-ID: <4B8F93EA.3020807@it.aoyama.ac.jp> Date: Thu, 04 Mar 2010 20:05:14 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.1) Gecko/20090902 Eudora/3.0b3 MIME-Version: 1.0 To: Alexey Melnikov Subject: Re: Additional comments on draft-duerst-mailto-bis-07.txt References: <4B1139D1.5060000@isode.com> In-Reply-To: <4B1139D1.5060000@isode.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 11:05:38 -0000 Hello Alex, On 2009/11/28 23:55, Alexey Melnikov wrote: > Hi Martin/Larry, > I've requested IETF LC for this document. The following extra comments > can be considered as a part of IETF LC. > > >> 2. Syntax of a 'mailto' URI >> >> The syntax of a 'mailto' URI is described using the ABNF of [STD68], >> non-terminal definitions from [RFC5322] (dot-atom, quoted-string) and >> non-terminal definitions from [STD66] (unreserved, pct-encoded): >> >> mailtoURI = "mailto:" [ to ] [ hfields ] >> to = [ addr-spec *("%2C" addr-spec ) ] >> hfields = "?" hfield *( "&" hfield ) >> hfield = hfname "=" hfvalue >> hfname = *qchar >> hfvalue = *qchar >> addr-spec = local-part "@" domain >> local-part = dot-atom / quoted-string >> domain = dot-atom > > I think you should be using "dot-atom-text" instead: > > atext = ALPHA / DIGIT / ; Printable US-ASCII > "!" / "#" / ; characters not including > "$" / "%" / ; specials. Used for atoms. > "&" / "'" / > "*" / "+" / > "-" / "/" / > "=" / "?" / > "^" / "_" / > "`" / "{" / > "|" / "}" / > "~" > > atom = [CFWS] 1*atext [CFWS] > > dot-atom-text = 1*atext *("." 1*atext) > > dot-atom = [CFWS] dot-atom-text [CFWS] > > > I.e. I don't think we want CFWS. Done (in my internal copy that will go out before the deadline next Monday). >> qchar = unreserved / pct-encoded / some-delims >> some-delims = "!" / "$" / "'" / "(" / ")" / "*" >> / "+" / "," / ";" / ":" / "@" > > [...] > >> Implementations SHOULD NOT produce two "To:" header fields in a >> message; the "To:" header field may occur at most once in a message >> ([RFC5322], Section 3.6). Also, creators of 'mailto' URIs SHOULD NOT >> include other message header fields multiple times if these header >> fields can only be used once in a message. >> >> > Any reasons why these SHOULD NOTs are not MUST NOTs? Done. >> From ID-nits: >> >> Miscellaneous warnings: >> ---------------------------------------------------------------------------- >> >> >> == The document seems to lack the recommended RFC 2119 boilerplate, >> even if >> it appears to use RFC 2119 keywords -- however, there's a paragraph with >> a matching beginning. Boilerplate error? >> >> (The document does seem to have the reference to RFC 2119 which the >> >> ID-Checklist requires). >> >> > I think this can be fixed by the RFC Editor, but if you have to do a new > revision, you might as well fix that. Done. Regards, Martin. -- #-# Martin J. Dürst, Professor, Aoyama Gakuin University #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp From stpeter@stpeter.im Tue Mar 9 10:44:54 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B139A3A6A0F; Tue, 9 Mar 2010 10:44:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sdn3IE0d4FZh; Tue, 9 Mar 2010 10:44:53 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 9BEB23A69FD; Tue, 9 Mar 2010 10:44:53 -0800 (PST) Received: from dhcp-64-101-72-245.cisco.com (dhcp-64-101-72-245.cisco.com [64.101.72.245]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id ADA9D40E14; Tue, 9 Mar 2010 11:44:57 -0700 (MST) Message-ID: <4B969728.3090907@stpeter.im> Date: Tue, 09 Mar 2010 11:44:56 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: "apps-discuss@ietf.org" , saag@ietf.org, "tls@ietf.org" , pkix@ietf.org Subject: representation and verification of identity in certificates X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050001070505060602060700" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2010 18:44:54 -0000 This is a cryptographically signed message in MIME format. --------------ms050001070505060602060700 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable A small, informal design team has been working on an I-D that attempts to define recommended procedures for representing and verifying server identities in X.509 certificates intended for use in applications that employ TLS. We have just published version -03 of that I-D: http://tools.ietf.org/html/draft-saintandre-tls-server-id-check-03 Because this work touches on security in a wide variety of application protocols (HTTP, IMAP, LDAP, SMTP, XMPP, NNTP, NETCONF, SysLog, SIP, etc.) through the re-use of both TLS and the PKI, there is no one list where we can hold a focused discussion. Therefore we have created a new list, certid@ietf.org, to which you can subscribe here: https://www.ietf.org/mailman/listinfo/certid Please join the discussion there if you have an interest in this topic. Thanks! Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms050001070505060602060700 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDMwOTE4NDQ1NlowIwYJKoZIhvcNAQkEMRYEFGpKbBS+nmGTxzjQuWo5 tEpAz7CiMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAfOcREdMu7C6XXMkbbeROprnTPbcjgLyds5Juph26 JqcqQUORSoebtuWHliLZ0HBs/KlaW4yZin9n+9wM3K5X9ZDQ+S/+W3YwwQ0s3RHKkxi0P4vb HnkI/a9g4gwganOKGO53amNM7rf70Sm1S0V78NvMD8lMExaHUYdG8Dg/hM4bZr67V9ssnPQb Bj6EojT8o/5LzFaDanmHlA+CdnHbPEb8ESBj/HGHhYMglxNJUt/4bgIogsT6ZrfGdaSmE4Ug Z4walaFPI4x3e55zakXyYNur95p2sz8602vVJeN9wwgp2u8U3suq2kkH//9shNoJ/7g8oiFc QC3E9hoba6ItmAAAAAAAAA== --------------ms050001070505060602060700-- From dromasca@avaya.com Thu Mar 11 05:14:17 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B6293A69FF for ; Thu, 11 Mar 2010 05:14:17 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u14jm84HyJJl for ; Thu, 11 Mar 2010 05:14:15 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 34F6C3A67C0 for ; Thu, 11 Mar 2010 05:13:48 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,620,1262581200"; d="scan'208";a="179886452" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 11 Mar 2010 08:13:52 -0500 X-IronPort-AV: E=Sophos;i="4.49,620,1262581200"; d="scan'208";a="454466350" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by co300216-co-erhwest-out.avaya.com with ESMTP; 11 Mar 2010 08:13:51 -0500 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 Subject: FW: Last Call: draft-ietf-netmod-yang (YANG - A data modeling languagefor NETCONF) to Proposed Standard Date: Thu, 11 Mar 2010 14:13:51 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last Call: draft-ietf-netmod-yang (YANG - A data modeling languagefor NETCONF) to Proposed Standard Thread-Index: AcrAiMvc4u8HXTRcR46w6H+oAm+yGgAk2vzw From: "Romascanu, Dan (Dan)" To: , X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2010 13:14:17 -0000 XML and APPS Experts, I would like to draw you attention on the IETF Last Call for the YANG data modeling language for NETCONF that started yesterday and will last for about one month.=20 Your comments and reviews will be appreciated.=20 Thanks and Regards, Dan -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of The IESG Sent: Wednesday, March 10, 2010 9:35 PM To: IETF-Announce Cc: netmod@ietf.org Subject: Last Call: draft-ietf-netmod-yang (YANG - A data modeling languagefor NETCONF) to Proposed Standard The IESG has received a request from the NETCONF Data Modeling Language WG (netmod) to consider the following document: - 'YANG - A data modeling language for NETCONF ' 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 2010-04-09. 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. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-netmod-yang-11.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTag= =3D 17247&rfc_flag=3D0 _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From dromasca@avaya.com Thu Mar 11 05:35:31 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3DC73A6813; Thu, 11 Mar 2010 05:35:31 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q9S66LINEJvr; Thu, 11 Mar 2010 05:35:30 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id CE79D3A672E; Thu, 11 Mar 2010 05:35:29 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,620,1262581200"; d="scan'208";a="179889571" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 11 Mar 2010 08:35:33 -0500 X-IronPort-AV: E=Sophos;i="4.49,620,1262581200"; d="scan'208";a="440833320" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.15]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 11 Mar 2010 08:35:32 -0500 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 Subject: RE: FW: Last Call: draft-ietf-netmod-yang (YANG - A data modeling languagefor NETCONF) to Proposed Standard Date: Thu, 11 Mar 2010 14:35:33 +0100 Message-ID: In-Reply-To: <4B98F119.5070101@gmx.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FW: Last Call: draft-ietf-netmod-yang (YANG - A data modeling languagefor NETCONF) to Proposed Standard Thread-Index: AcrBH21NA8oiGk5wRiOpPjrs9+n1cQAABbVQ References: <4B98F119.5070101@gmx.de> From: "Romascanu, Dan (Dan)" To: "Julian Reschke" Cc: apps-discuss@ietf.org, xml-dir@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2010 13:35:31 -0000 Hi Julian, Thank you for looking at the document.=20 As this document is in IETF Last Call would it be possible to send these comments to ietf.org?=20 Thanks and Regards, Dan =20 > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de]=20 > Sent: Thursday, March 11, 2010 3:33 PM > To: Romascanu, Dan (Dan) > Cc: xml-dir@ietf.org; apps-discuss@ietf.org > Subject: Re: FW: Last Call: draft-ietf-netmod-yang (YANG - A=20 > data modeling languagefor NETCONF) to Proposed Standard >=20 > On 11.03.2010 14:13, Romascanu, Dan (Dan) wrote: > > XML and APPS Experts, > > > > I would like to draw you attention on the IETF Last Call=20 > for the YANG=20 > > data modeling language for NETCONF that started yesterday and will=20 > > last for about one month. > > > > Your comments and reviews will be appreciated. > > > > Thanks and Regards, > > > > Dan > > ... >=20 > Isolated comment: >=20 > > 5.3. XML Namespaces > > > > All YANG definitions are specified within a module that=20 > is bound to a > > particular XML Namespace [XML-NAMES], which is a=20 > globally unique URI > > [RFC3986]. A NETCONF client or server uses the=20 > namespace during XML > > encoding of data. > > > > Namespaces for modules published in RFC streams [RFC4844] MUST be > > assigned by IANA, see Section 14. >=20 > I don't see why this is a requirement. The whole point of=20 > using URIs as XML namespace identifiers is that you don't=20 > *need* a central authority for assignment. >=20 > > Namespaces for private modules are assigned by the organization > > owning the module without a central registry. Namespace=20 > URIs MUST be > > chosen so they cannot collide with standard or other enterprise > > namespaces, for example by using the enterprise or=20 > organization name > > in the namespace. >=20 > That's true, but IMHO just repeats best XML practice. >=20 > > The "namespace" statement is covered in Section 7.1.3. >=20 > Best regards, Julian >=20 From julian.reschke@gmx.de Thu Mar 11 05:39:57 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB6EE3A67D2 for ; Thu, 11 Mar 2010 05:39:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.333 X-Spam-Level: X-Spam-Status: No, score=-5.333 tagged_above=-999 required=5 tests=[AWL=-2.734, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4+2-Qrnh1pko for ; Thu, 11 Mar 2010 05:39:57 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 305083A67AE for ; Thu, 11 Mar 2010 05:39:57 -0800 (PST) Received: (qmail invoked by alias); 11 Mar 2010 13:33:22 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.105]) [217.91.35.233] by mail.gmx.net (mp072) with SMTP; 11 Mar 2010 14:33:22 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/VpDg+6ZzVKKeiZwk4+y4h8sCJL4LPQb0M4swi1D WtK29bVo0Y6ni0 Message-ID: <4B98F119.5070101@gmx.de> Date: Thu, 11 Mar 2010 14:33:13 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" Subject: Re: FW: Last Call: draft-ietf-netmod-yang (YANG - A data modeling languagefor NETCONF) to Proposed Standard References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.56999999999999995 Cc: apps-discuss@ietf.org, xml-dir@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2010 13:39:57 -0000 On 11.03.2010 14:13, Romascanu, Dan (Dan) wrote: > XML and APPS Experts, > > I would like to draw you attention on the IETF Last Call for the YANG > data modeling language for NETCONF that started yesterday and will last > for about one month. > > Your comments and reviews will be appreciated. > > Thanks and Regards, > > Dan > ... Isolated comment: > 5.3. XML Namespaces > > All YANG definitions are specified within a module that is bound to a > particular XML Namespace [XML-NAMES], which is a globally unique URI > [RFC3986]. A NETCONF client or server uses the namespace during XML > encoding of data. > > Namespaces for modules published in RFC streams [RFC4844] MUST be > assigned by IANA, see Section 14. I don't see why this is a requirement. The whole point of using URIs as XML namespace identifiers is that you don't *need* a central authority for assignment. > Namespaces for private modules are assigned by the organization > owning the module without a central registry. Namespace URIs MUST be > chosen so they cannot collide with standard or other enterprise > namespaces, for example by using the enterprise or organization name > in the namespace. That's true, but IMHO just repeats best XML practice. > The "namespace" statement is covered in Section 7.1.3. Best regards, Julian From alexey.melnikov@isode.com Thu Mar 11 15:45:39 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C3AE3A6833 for ; Thu, 11 Mar 2010 15:45:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uaPfF+j7WMaM for ; Thu, 11 Mar 2010 15:45:38 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id ACBA43A6802 for ; Thu, 11 Mar 2010 15:45:35 -0800 (PST) Received: from [172.16.2.187] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 11 Mar 2010 23:45:40 +0000 Message-ID: <4B998082.9030104@isode.com> Date: Thu, 11 Mar 2010 23:45:06 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Apps-Discuss@ietf.org Subject: Call for Apps Area meeting discussion topics MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2010 23:45:39 -0000 So far Lisa/Peter/myself heard of the following requests: Short introduction of Apps Area BOFs: IRDE, NewPrep (5-10 minutes each) Sean Leonard: A Uniform Resource Name (URN) Namespace for Transaction Identifiers (draft-seantek-tid-urn-01) - 15 mins Eliot Lear: OpenID and SAML Simple Authentication Security Layer (SASL) mechanisms - 20 mins [this will be the last presentation] Other topics to discuss? From GK@ninebynine.org Thu Mar 11 15:46:57 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BF7D3A6835; Thu, 11 Mar 2010 15:46: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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TV5M5vmGK5d6; Thu, 11 Mar 2010 15:46:56 -0800 (PST) Received: from relay9.mail.ox.ac.uk (relay9.mail.ox.ac.uk [163.1.2.169]) by core3.amsl.com (Postfix) with ESMTP id 3A0C43A6833; Thu, 11 Mar 2010 15:46:56 -0800 (PST) Received: from smtp1.mail.ox.ac.uk ([129.67.1.207]) by relay9.mail.ox.ac.uk with esmtp (Exim 4.71) (envelope-from ) id 1Nps5k-0001ru-Vt; Thu, 11 Mar 2010 23:47:00 +0000 Received: from gklyne.plus.com ([80.229.154.156] helo=Eskarina.local) by smtp1.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Nps5k-0005HS-4j; Thu, 11 Mar 2010 23:47:00 +0000 Message-ID: <4B9980F3.90502@ninebynine.org> Date: Thu, 11 Mar 2010 23:46:59 +0000 From: Graham Klyne User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" Subject: Re: FW: Last Call: draft-ietf-netmod-yang (YANG - A data modeling languagefor NETCONF) to Proposed Standard References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Cc: xml-dir@iet.org, ietf@ietf.org, apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2010 23:46:57 -0000 Hi, At 180-ish pages, it's a pretty daunting spec. At a cursory glance, it mostly seems to be yet another schema language for XML - I didn't see anything in the introduction to suggest otherwise: This document describes the syntax and semantics of the YANG language, how the data model defined in a YANG module is represented in XML, and how NETCONF operations are used to manipulate the data. Sounds to me like a schema language with a little bit of operational semantics attached for manipulation. What is it that this specification provides that cannot be expressed with XML Schema or RelaxNG? And if it's not very much, wouldn't it make more sense to frame this as a modest extension of an existing schema language? Maybe I'm missing something fundamental here: if so, it would help if the introduction could explain what that might be. #g -- Romascanu, Dan (Dan) wrote: > XML and APPS Experts, > > I would like to draw you attention on the IETF Last Call for the YANG > data modeling language for NETCONF that started yesterday and will last > for about one month. > > Your comments and reviews will be appreciated. > > Thanks and Regards, > > Dan > > > -----Original Message----- > From: ietf-announce-bounces@ietf.org > [mailto:ietf-announce-bounces@ietf.org] On Behalf Of The IESG > Sent: Wednesday, March 10, 2010 9:35 PM > To: IETF-Announce > Cc: netmod@ietf.org > Subject: Last Call: draft-ietf-netmod-yang (YANG - A data modeling > languagefor NETCONF) to Proposed Standard > > The IESG has received a request from the NETCONF Data Modeling Language > WG (netmod) to consider the following document: > > - 'YANG - A data modeling language for NETCONF ' > 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 2010-04-09. 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. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-netmod-yang-11.txt > > > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag= > 17247&rfc_flag=0 > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > _______________________________________________ > Apps-Discuss mailing list > Apps-Discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From alexey.melnikov@isode.com Fri Mar 12 03:32:05 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A25813A6768 for ; Fri, 12 Mar 2010 03:32:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JpFt6AW3N+u6 for ; Fri, 12 Mar 2010 03:32:05 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id B21FE3A6842 for ; Fri, 12 Mar 2010 03:32:04 -0800 (PST) Received: from [192.168.1.124] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 12 Mar 2010 11:32:10 +0000 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4B9A262B.6080206@isode.com> Date: Fri, 12 Mar 2010 11:31:55 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Apps-Discuss@ietf.org Subject: Re: Call for Apps Area meeting discussion topics References: <4B998082.9030104@isode.com> In-Reply-To: <4B998082.9030104@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Mar 2010 11:32:05 -0000 Alexey Melnikov wrote: > So far Lisa/Peter/myself heard of the following requests: > > Short introduction of Apps Area BOFs: IRDE, NewPrep (5-10 minutes each) I got reminded that I forgot something: Eran Hammer-Lahav (15 mins): WebFinger 'acct' URIs host-meta LRDD / XRD / Discovery > Sean Leonard: A Uniform Resource Name (URN) Namespace for Transaction > Identifiers (draft-seantek-tid-urn-01) - 15 mins > Eliot Lear: OpenID and SAML Simple Authentication Security Layer > (SASL) mechanisms - 20 mins [this will be the last presentation] > > Other topics to discuss? From stpeter@stpeter.im Fri Mar 12 05:05:53 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A6BE3A67B4 for ; Fri, 12 Mar 2010 05:05:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZzR0hnIX827 for ; Fri, 12 Mar 2010 05:05:52 -0800 (PST) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 3D1043A67B2 for ; Fri, 12 Mar 2010 05:05:52 -0800 (PST) Received: from squire.local (dsl-179-231.dynamic-dsl.frii.net [216.17.179.231]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 54D4740E14 for ; Fri, 12 Mar 2010 06:05:57 -0700 (MST) Message-ID: <4B9A3C33.4060208@stpeter.im> Date: Fri, 12 Mar 2010 06:05:55 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: apps-discuss@ietf.org Subject: Re: Call for Apps Area meeting discussion topics References: <4B998082.9030104@isode.com> <4B9A262B.6080206@isode.com> In-Reply-To: <4B9A262B.6080206@isode.com> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040506000202000309020509" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Mar 2010 13:05:53 -0000 This is a cryptographically signed message in MIME format. --------------ms040506000202000309020509 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 3/12/10 4:31 AM, Alexey Melnikov wrote: > Alexey Melnikov wrote: >=20 >> So far Lisa/Peter/myself heard of the following requests: >> >> Short introduction of Apps Area BOFs: IRDE, NewPrep (5-10 minutes each= ) >=20 > I got reminded that I forgot something: >=20 > Eran Hammer-Lahav (15 mins): >=20 > WebFinger > 'acct' URIs > host-meta > LRDD / XRD / Discovery Oh yes, true. I'm looking forward to that one. :) Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms040506000202000309020509 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDMxMjEzMDU1NVowIwYJKoZIhvcNAQkEMRYEFIGbHCr7YA53pp2nNaE3 yqIaaFXgMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAhHsy3UEWX5nmvvNQhpzIJQ5p5VDktT+97xNA2q2f ApC55gedpjq0umGq0Al8GlkFpWANWBU0ahgAYPNkwCpVbc3lWTLs6o50S1RkBJ335jgu78RB qOKSLvnj+QN6rQPOixvqz6xutpkRnaFlr1s1/MPInPL/SyvdfA37OqSXz1Ezyz5y8WEIf986 3VzGGbNMUqvteyxcLT4pCDlJmB0ktdVF9ZPY12bMswVL/uNGXWeeHYdpUBtdn4vaQq1ohCTq g0PSlhn0r9UaaQS2ojrT2unUUq70JaX8QULKd3IBcmNwGpVerrOYdn8JXZ4d5JkfLda+1NJj KTZ58VbS7FKF7AAAAAAAAA== --------------ms040506000202000309020509-- From lunohod.baikonur@googlemail.com Fri Mar 19 10:57:50 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 680A23A6909 for ; Fri, 19 Mar 2010 10:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.312 X-Spam-Level: X-Spam-Status: No, score=0.312 tagged_above=-999 required=5 tests=[AWL=-1.441, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S6Z4-7iJt5S9 for ; Fri, 19 Mar 2010 10:57:49 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id B41A93A68E6 for ; Fri, 19 Mar 2010 10:57:45 -0700 (PDT) Received: by wwg30 with SMTP id 30so953280wwg.31 for ; Fri, 19 Mar 2010 10:57:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type; bh=gxO53ofjGMlZxqlBJh2QpS6Zk6H0Nb+g/UPhdzAFwzo=; b=HQkhlzG1XQWGUjBM4CS+I7Xcs0v+s9IHBqbZ7X/OB9uJSPUHAxilG15iJ73+Cwbpc9 2m7o+TSwIPVB3D2kW1uwOMcCNZdeUp1BHrn6gQmm9oqQj6eg8PaNB4pZV23XKyYDs/2x DU6+WTmpm4YYggE+GprZioeiUxQHZJG7QRJyg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=SwkkKMUFDgjN2oZtfKSlnYakNmyL6fFeUzdjMU6S7OqG8kbI1x9lUslzU1d2sfKfnz s5TNhqtWJyPFbLbq+8nzFfTct5UU0SD55g1N/hi28yJHJMJG8QJY3V6fg0RCILSjQuyU FTufsA60s/mCVK8tCd8tlNmotnFOOhyjJY4B4= MIME-Version: 1.0 Sender: lunohod.baikonur@googlemail.com Received: by 10.216.89.139 with SMTP id c11mr1691768wef.198.1269021474494; Fri, 19 Mar 2010 10:57:54 -0700 (PDT) In-Reply-To: <4B9A262B.6080206@isode.com> References: <4B998082.9030104@isode.com> <4B9A262B.6080206@isode.com> Date: Fri, 19 Mar 2010 17:57:50 +0000 X-Google-Sender-Auth: 833f8cec3963ef38 Message-ID: <29d3c4cb1003191057x72dd88ebjcc7d7f5d4602caf8@mail.gmail.com> Subject: Re: Call for Apps Area meeting discussion topics From: Alexey Melnikov To: Apps-Discuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2010 17:57:50 -0000 Updated agenda (the order of topics is random at this point and my change. Please email me if you have preferences): 1) Short introduction of Apps Area BOFs: IRDE, NewPrep (5-10 minutes each) 2) Eran Hammer-Lahav (15 mins): WebFinger 'acct' URIs host-meta LRDD / XRD / Discovery 3) Murray S. Kucherawy: Message Header Field for Indicating Message Authentication Status (RFC5451bis) - 5 mins 4) Sean Leonard: A Uniform Resource Name (URN) Namespace for Transaction Identifiers (draft-seantek-tid-urn-01) - 15 mins 5) Andrew Sullivan: "DNS name equivalence" - short presentation and moderated discussion, 15 mins 6) Eliot Lear: OpenID and SAML Simple Authentication Security Layer (SASL) mechanisms - 20 mins [this will be the last presentation] From A.Hoenes@TR-Sys.de Mon Mar 22 06:33:43 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6720628C163; Mon, 22 Mar 2010 06:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.893 X-Spam-Level: *** X-Spam-Status: No, score=3.893 tagged_above=-999 required=5 tests=[AWL=-1.088, BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A+pwVydk+j4Q; Mon, 22 Mar 2010 06:33:42 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id CC54D3A6B69; Mon, 22 Mar 2010 06:27:30 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA043384434; Mon, 22 Mar 2010 14:27:14 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id OAA02242; Mon, 22 Mar 2010 14:27:13 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201003221327.OAA02242@TR-Sys.de> Subject: New Version Notification for draft-hakala-rfc3187bis-isbn-urn-00 (fwd) To: urn-nid@ietf.org, apps-discuss@ietf.org Date: Mon, 22 Mar 2010 14:27:13 +0100 (MEZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 13:33:43 -0000 Folks, we have posted a RFC 3187-bis initial draft (see below). This work is part of the PersID project to establish an international network of stable resolution services for Persistent Identifiers (URNs), in particular for Bibliographic identifiers. To give this work a more solid ground, updates to the basic URN-related documents (RFC 2141 and RFC 3406) and URN namespace-specific RFCs are planned, and brought to the IETF, in order to bring these documents in alignment with current IETF Full Standards and IANA procedures. The ultimate goal is to establish a dedicated 'urnbis' WG in the IETF, hopefully by this summer, with an ambitious schedule to bring revised documents initially targetting PS / BCP status to the IESG, with the goal of fast progression of RFC 2141-bis on the Standards Track. Kind regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ ----- Forwarded message from IETF I-D Submission Tool ----- > Message-Id: <20100322130444.4400D28C0F6@core3.amsl.com> > Date: Mon, 22 Mar 2010 06:04:44 -0700 (PDT) > Subject: New Version Notification for draft-hakala-rfc3187bis-isbn-urn-00 A new version of I-D, draft-hakala-rfc3187bis-isbn-urn-00.txt has been successfully submitted by Alfred Hoenes and posted to the IETF repository. Filename: draft-hakala-rfc3187bis-isbn-urn Revision: 00 Title: Using International Standard Book Numbers as Uniform Resource Names Creation_date: 2010-03-22 WG ID: Independent Submission Number_of_pages: 17 Abstract: The International Standard Book Number, ISBN, is a widely used identifier for monographic publications. Since 2001, there has been a URN (Uniform Resource Names) namespace for ISBNs. The namespace registration was performed in RFC 3187 and applies to the ISBN as specified in the original ISO Standard 2108-1992. To allow for further growth in use, the successor ISO Standard, ISO 2108-2005, has defined an expanded format for the ISBN, known as "ISBN-13". This document replaces RFC 3187 and defines how both the old and new ISBN standard can be supported within the URN framework and the syntax for URNs defined in RFC 2141. An updated namespace registration is included, which describes how both the old and the new ISBN format can share the same namespace. Discussion This draft version is the outcome of work started in 2008 and brought to the IETF as a contribution to a much larger effort to revise the basic URN RFCs, in order to bring them in alignment with the current URI Standard (STD 63, RFC 3986), ABNF, and IANA guidelines, and to establish a modern URN resolution system for bibliographic identifiers. Until a more specific mailing list is established, comments are welcome on the urn-nid@ietf.org mailing list (or sent to the authors). The IETF Secretariat. ----- End of forwarded message from IETF I-D Submission Tool ----- From msk@cloudmark.com Wed Mar 24 09:10:04 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90BCE3A6A74 for ; Wed, 24 Mar 2010 09:10:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.732 X-Spam-Level: * X-Spam-Status: No, score=1.732 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 413iN+nkIdrv for ; Wed, 24 Mar 2010 09:09:57 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by core3.amsl.com (Postfix) with ESMTP id 70A5F3A6A48 for ; Wed, 24 Mar 2010 09:09:53 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.1.71]) with mapi; Wed, 24 Mar 2010 09:10:14 -0700 From: "Murray S. Kucherawy" To: "apps-discuss@ietf.org" Date: Wed, 24 Mar 2010 09:10:12 -0700 Subject: Authentication-Results: changes Thread-Topic: Authentication-Results: changes Thread-Index: AcrLbHve3cXcdkEgS8uyC1xnghc9pw== Message-ID: 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_BB012BD379D7B046ABE1472D8093C61C01CF000075EXCHC2corpclo_" MIME-Version: 1.0 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 16:10:05 -0000 --_000_BB012BD379D7B046ABE1472D8093C61C01CF000075EXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Monday in the APPAREA meeting, I mentioned some upcoming work regarding = the Authentication-Results: header field. I've split the two changes I'm s= eeking to make into separate drafts because one is fairly trivial and only = requires an IANA registration action to complete while the other touches a = potentially complicated security issue, involves a format change, and thus = probably involves a full spec revision. So rather than hold up the simple = one waiting for the complex one, I've split them. One thing that was brought up way back in the early DKIM years, but dropped= then as unimportant, was the idea that Authentication-Results needs a way = to specify which signature a DKIM result is conveying. Since more than one= signature might be on a message from the same domain, we can't rely on "he= ader.d" and "header.i" to be able to make this distinction. For example: A message comes to you with two signatures, both from the sign= er. The only distinction is that one signature has an "l=3D" tag and one do= es not. The message was altered by a mailing list. Therefore, the signatu= re with "l=3D" passes when you try it, and the other one fails. You create= a compliant Authentication-Results: header field to add to the message. W= ith the current specification, the best you can do is say "dkim=3Dpass head= er.d=3Dexample.com; dkim=3Dfail header.d=3Dexample.com" and perhaps rely on= signature order to match them up. I propose that we need a new tag, "header.b", which will contain the first = several characters of the actual digital signature, which is pretty much gu= aranteed to be unique among signatures present. This will allow unambiguou= s matching of signatures with results. I have this now in a draft that I plan to move through the Applications are= a of the IETF as an individual submission since it's fairly minor: http://datatracker.ietf.org/doc/draft-kucherawy-authres-header-b/ Comments welcome. -MSK --_000_BB012BD379D7B046ABE1472D8093C61C01CF000075EXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

On Monday in the APPAREA meeting, I mentioned some upc= oming work regarding the Authentication-Results: header field.  I’ve s= plit the two changes I’m seeking to make into separate drafts because one = is fairly trivial and only requires an IANA registration action to complete wh= ile the other touches a potentially complicated security issue, involves a form= at change, and thus probably involves a full spec revision.  So rather th= an hold up the simple one waiting for the complex one, I’ve split them.<= o:p>

 

One thing that was brought up way back in the early DK= IM years, but dropped then as unimportant, was the idea that Authentication-Results needs a way to specify which signature a DKIM result= is conveying.  Since more than one signature might be on a message from t= he same domain, we can’t rely on “header.d” and “header.i&#= 8221; to be able to make this distinction.

 

For example: A message comes to you with two signature= s, both from the signer. The only distinction is that one signature has an = 220;l=3D” tag and one does not.  The message was altered by a mailing list. = ; Therefore, the signature with “l=3D” passes when you try it, an= d the other one fails.  You create a compliant Authentication-Results: heade= r field to add to the message.  With the current specification, the best= you can do is say “dkim=3Dpass header.d=3Dexample.com; dkim=3Dfail header.d=3Dexample.com” and perhaps rely on signature order to match = them up.

 

I propose that we need a new tag, “header.b̶= 1;, which will contain the first several characters of the actual digital signature, which is pretty much guaranteed to be unique among signatures present.  This will allow unambiguous matching of signatures with resu= lts.

 

I have this now in a draft that I plan to move through= the Applications area of the IETF as an individual submission since it’s fairly minor:

 

= http://datatracker.ietf.org/doc/draft-kucherawy-authres-header-b/<= /o:p>

 

Comments welcome.

 

-MSK

 

--_000_BB012BD379D7B046ABE1472D8093C61C01CF000075EXCHC2corpclo_-- From jpanzer@google.com Wed Mar 24 09:32:12 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9753E3A6B91 for ; Wed, 24 Mar 2010 09:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.246 X-Spam-Level: X-Spam-Status: No, score=-102.246 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gNuSoI1mAo4i for ; Wed, 24 Mar 2010 09:32:11 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 3C1FD3A6C13 for ; Wed, 24 Mar 2010 09:32:09 -0700 (PDT) Received: from hpaq2.eem.corp.google.com (hpaq2.eem.corp.google.com [10.3.21.2]) by smtp-out.google.com with ESMTP id o2OGWQKl002140 for ; Wed, 24 Mar 2010 09:32:27 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1269448347; bh=qZ50PJD+QtT9QcMVjvtm30BlNxs=; h=MIME-Version:From:Date:Message-ID:Subject:To:Cc:Content-Type; b=Azr4o1rWm252jGHG+SnKbgVg/kICH8aNjKodQMvGpSOixcdYMZX2GbxHU8kCDodeI o9pm+pxRvM3/XKvXiITLQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:from:date:message-id:subject:to:cc: content-type:x-system-of-record; b=psYUSNxYZezNtOvBPncuFmggg9q8VzF4/XL9IzioKMRX9y8uhCu4vsAIKrc+Cpxxn ns7LtyRSxZJb0wnTjfm3A== Received: from pxi7 (pxi7.prod.google.com [10.243.27.7]) by hpaq2.eem.corp.google.com with ESMTP id o2OGWJGi027987 for ; Wed, 24 Mar 2010 17:32:25 +0100 Received: by pxi7 with SMTP id 7so3433935pxi.5 for ; Wed, 24 Mar 2010 09:32:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.152.37 with SMTP id z37mr1651669wfd.84.1269448343381; Wed, 24 Mar 2010 09:32:23 -0700 (PDT) From: John Panzer Date: Wed, 24 Mar 2010 09:25:20 -0700 Message-ID: Subject: Notes on draft-hammer-discovery-04 To: apps-discuss@ietf.org Content-Type: multipart/alternative; boundary=000e0cd2e28691669404828e79af X-System-Of-Record: true Cc: webfinger@googlegroups.com, "salmon-protocol@googlegroups.com" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 16:32:12 -0000 --000e0cd2e28691669404828e79af Content-Type: text/plain; charset=ISO-8859-1 Some comments and questions about section 3, Discovery Process: The section lists two use cases, one in which a client is looking for "a link" and another in which a client is looking for "metadata ... other than a link to another resource". (1) It would be good to have an example of the latter. (2) What if a client simply wants to retrieve all of the available metadata -- including links -- for a given resource, honoring the host-priority, but doing a full transitive closure retrieval of everything of interest? This is an extremely natural thing to do, especially for a caching client, and should be possible if the specification is logically consistent. But there's no mention of this use case. I am particularly interested in #2 as I'm about to dive in to write-or-update code to do this. (3) The following section leaves me with additional questions: > If the information being sought is a link: find a link matching the desired criteria by processing the links in order. If a qualified link is found, the process ends successfully. Typically one is searching for links with a given rel value, and in the general case this results in a collection of links. The wording above seems to be aimed at the (simple) case where you are looking for a link with cardinality 0 or 1. But it doesn't address the general case. If you are looking for a set of links, the spec could either say that all links with a given rel value MUST be co-located in the same document. Or, it could say that clients MUST keep searching all documents (honoring host-priority) until they exhaust the possible set of documents looking for rel values. Are there any other choices? -- John Panzer / Google jpanzer@google.com / abstractioneer.org/ @jpanzer --000e0cd2e28691669404828e79af Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Some comments and questions about section 3, Discovery Process:
<= div>
The section lists two use cases, one in which a client i= s looking for "a link" and another in which a client is looking f= or "metadata ... other than a link to another resource". =A0

(1) It would be good to have an example of the latter.<= /div>
(2) What if a client simply wants to retrieve all of the availabl= e metadata -- including links -- for a given resource, honoring the host-pr= iority, but doing a full transitive closure retrieval of everything of inte= rest? =A0This is an extremely natural thing to do, especially for a caching= client, and should be possible if the specification is logically consisten= t. =A0But there's no mention of this use case.

I am particularly interested in #2 as I'm about to = dive in to write-or-update code to do this.

(3) Th= e following section leaves me with additional questions:
= 




If the information being sought is a link: find a link matching the desired=
 criteria by processing the links in order.  If a qualified link is found, =
the process ends successfully.
Typically one is searching for links with a given rel value, and in the gen= eral case this results in a collection of links. The wording above seems to= be aimed at the (simple) case where you are looking for a link with cardin= ality 0 or 1. =A0But it doesn't address the general case.

If you are looking for a set of= links, the spec could either say that all links with a given rel value MUS= T be co-located in the same document. =A0Or, it could say that clients MUST= keep searching all documents (honoring host-priority) until they exhaust t= he possible set of documents looking for rel values. =A0Are there any other= choices?


--John Panzer / Google
jpanzer@= google.com / abstractioneer.org / @jpanzer

--000e0cd2e28691669404828e79af-- From anthonybryan@gmail.com Wed Mar 24 14:30:07 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 524573A6B4C for ; Wed, 24 Mar 2010 14:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.431 X-Spam-Level: * X-Spam-Status: No, score=1.431 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rlr7sHA84NWJ for ; Wed, 24 Mar 2010 14:30:06 -0700 (PDT) Received: from mail-iw0-f189.google.com (mail-iw0-f189.google.com [209.85.223.189]) by core3.amsl.com (Postfix) with ESMTP id 6CF823A69ED for ; Wed, 24 Mar 2010 14:29:54 -0700 (PDT) Received: by iwn27 with SMTP id 27so3960704iwn.5 for ; Wed, 24 Mar 2010 14:30:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=+0lAKLpJHrCbNWdgM/RyLSOpTh6RScjDndP+dCMXfKE=; b=ZJkrnnuYk4aGnUSJseQ0At1AGgJlAraYCD/+RIcpYOMR1qLzq5mNDaO4ztcDMyZJNi vRjG4hSsAmokMItgxbr1vPPkG5ANQ/YOVOIDbsW81DOrDNCJwuFr/1NlcNuApBJD8stY y53tRYrXWVuNdTyZpWJ/aml/u5TaVVROr7L90= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=skPmW2n8ep20niWU83Cj3ZOXixIbW8eOwFlle1SkXFOh2s4wCkYSGfhzFu2FzcsGKx MjQRNETjmBoNdAZCXZN8/A5SElCjl8Iv7PE+7obdGGFrtF+bkBEnAL049YXYIB7Y4xrL MHp/f8Qupc5/2ELo7GOBNCJZhhHgsdL7yEMv8= MIME-Version: 1.0 Received: by 10.231.154.207 with SMTP id p15mr828718ibw.91.1269466212767; Wed, 24 Mar 2010 14:30:12 -0700 (PDT) Date: Wed, 24 Mar 2010 17:30:12 -0400 Message-ID: Subject: FTP Extensions for Cryptographic Hashes (draft-bryan-ftp-hash) From: Anthony Bryan To: apps-discuss@ietf.org, Tim Kosse , =?ISO-8859-1?Q?Alfred_H=CEnes?= , john+ietf@jck.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 21:30:07 -0000 Hi, This ID proposes a feature where FTP clients can request the hash of a file. A number of FTP clients and servers have implemented multiple commands (XMD5, XSHA1, SITE SHOHASH, etc) that are not formally specified, leading to non-interoperability and confusion. We have talked to FTP application authors that are interested in this feature. Others have previously resisted implementing this feature because it isn't formally specified. We already have some issues from Alfred Hoenes and John Klensin to address. If you are interested, please review & reply. thanks, --=20 (( Anthony Bryan ... Metalink [ http://www.metalinker.org ] )) Easier, More Reliable, Self Healing Downloads A new version of I-D, draft-bryan-ftp-hash-00.txt has been successfully submitted by Anthony Bryan and posted to the IETF repository. Filename: =A0 =A0 =A0 =A0draft-bryan-ftp-hash Revision: =A0 =A0 =A0 =A000 Title: =A0 =A0 =A0 =A0 =A0 FTP Extensions for Cryptographic Hashes Creation_date: =A0 2010-03-23 WG ID: =A0 =A0 =A0 =A0 =A0 Independent Submission Number_of_pages: 7 Abstract: The specification for the File Transfer Protocol does not include methods to obtain cryptographic hashes of files. =A0Cryptographic hashes can be used to identify files and verify integrity. Unfortunately, because of the desire for this feature, multiple commands that are not formally specified have been implemented in FTP applications leading to non-interoperability and confusion. =A0This specification documents an optional command where FTP clients can request the cryptographic hash of a file from a FTP server. From daniel@haxx.se Wed Mar 24 14:59:48 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DC4B3A6C7B for ; Wed, 24 Mar 2010 14:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.74 X-Spam-Level: X-Spam-Status: No, score=0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YPJwc54Af85x for ; Wed, 24 Mar 2010 14:59:47 -0700 (PDT) Received: from giant.haxx.se (giant.haxx.se [83.168.254.42]) by core3.amsl.com (Postfix) with ESMTP id 5615D3A6C2C for ; Wed, 24 Mar 2010 14:59:47 -0700 (PDT) Received: from giant.haxx.se (giant.haxx.se [83.168.254.42]) by giant.haxx.se (8.14.3/8.14.3/Debian-9) with ESMTP id o2OLxpLX014343; Wed, 24 Mar 2010 22:59:51 +0100 Date: Wed, 24 Mar 2010 22:59:51 +0100 (CET) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: Anthony Bryan Subject: Re: FTP Extensions for Cryptographic Hashes (draft-bryan-ftp-hash) In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) X-fromdanielhimself: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Tim Kosse , =?ISO-8859-15?Q?Alfred_H=CEnes?= , john+ietf@jck.com, apps-discuss@ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 21:59:48 -0000 On Wed, 24 Mar 2010, Anthony Bryan wrote: > This ID proposes a feature where FTP clients can request the hash of a file. > A number of FTP clients and servers have implemented multiple commands > (XMD5, XSHA1, SITE SHOHASH, etc) that are not formally specified, leading to > non-interoperability and confusion. Nice draft! Here's one remark: You use 550 as response code when the user isn't allowed to use the HASH command, but I find that 550 is otherwise often used for file-not-found in both SIZE, RETR and other responses. Wouldn't it make sense to have a "file not found" response for when you try to HASH a non-existing file? Wouldn't it make sense to re-use the same error code (550) for that as other command use? Maybe the "HASH not allowed" case can use 552 or 553? -- / daniel.haxx.se From jpanzer@google.com Thu Mar 25 16:41:36 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B8FF3A6B46 for ; Thu, 25 Mar 2010 16:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.295 X-Spam-Level: X-Spam-Status: No, score=-97.295 tagged_above=-999 required=5 tests=[AWL=-0.849, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_44=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E+sa039nlQlN for ; Thu, 25 Mar 2010 16:41:34 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.35]) by core3.amsl.com (Postfix) with ESMTP id D56C03A69BF for ; Thu, 25 Mar 2010 16:41:33 -0700 (PDT) Received: from hpaq5.eem.corp.google.com (hpaq5.eem.corp.google.com [10.3.21.5]) by smtp-out.google.com with ESMTP id o2PNfthP032310 for ; Fri, 26 Mar 2010 00:41:55 +0100 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1269560515; bh=unXi/hFGdd7roSAGpq7ktqDHL88=; h=MIME-Version:From:Date:Message-ID:Subject:To:Cc:Content-Type; b=M2J94rQetuNJGYdOksQQo826Bmp1c7gI4Vms1rm8WZE4zY83Y5UHRnTf/7bkwszCM yHHaMI+Zef8t2pB2wCyxA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:from:date:message-id:subject:to:cc: content-type:x-system-of-record; b=lVJRkdHzYKs+KJzS+aQGf5d+8+R1aJjcffvkGjdw8ca79QM8kRsbtAY0kSVObtnWf 5ugZF48eddvQZzEsbPJRA== Received: from pzk11 (pzk11.prod.google.com [10.243.19.139]) by hpaq5.eem.corp.google.com with ESMTP id o2PNfqc6015048 for ; Fri, 26 Mar 2010 00:41:53 +0100 Received: by pzk11 with SMTP id 11so2467pzk.17 for ; Thu, 25 Mar 2010 16:41:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.187.11 with SMTP id k11mr1600471waf.153.1269560509413; Thu, 25 Mar 2010 16:41:49 -0700 (PDT) From: John Panzer Date: Thu, 25 Mar 2010 16:41:29 -0700 Message-ID: Subject: Query on discovery algoritm for LRDD (draft-hammer-discovery-04) To: apps-discuss@ietf.org Content-Type: multipart/alternative; boundary=0016e64cca7e2f3a770482a89792 X-System-Of-Record: true Cc: webfinger@googlegroups.com, "salmon-protocol@googlegroups.com" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2010 23:41:36 -0000 --0016e64cca7e2f3a770482a89792 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable All, This is my attempt to translate * http://tools.ietf.org/html/draft-hammer-discovery-04* into an actionable algorithm, as a first step in attempting to write a truly general resource discovery library that matches the latest spec. It is written under the assumption that a client may wish to query for sets of links with a given relvalue, and is not going to wish to retrieve and re-parse host-meta files any more often than necessary. Feedback welcomed! *Definitions* - *startURI*: Starting point for discovery; input into the discovery process. Discovery produces metadata for *startURI.* - *meta data:*A collection of links and properties for the resource. - *link*: An abstract edge between the*startURI*resource and another resource identified by a field *href. *Has a*rel*field indicating the relationship from *startURI *to *href.* Has a *lrdd_pri *field indicatin= g ordering within the *rel *value. Has a *secure *boolean field indicatin= g whether it was retrieved securely. Can be annotated with arbitrary * properties*. - *property*: A piece of metadata about a resource less structured than a *link.* Only present for XRD-derived data. Has a *secure *boolean field indicating whether it was retrieved securely. *Algorithm* 1. Determine priority order (Host-priority or Resource-priority): 1. lookup HostMetaLRDD(startURI) 2. if above lookup fails because Host(startURI) is not available, priority =3D Resource (goto step 2) 3. Else, does result contain XRD/Property@type=3D http://lrdd.net/priority/resource? 4. If yes, then priority =3D Resource (goto step 2) 5. Otherwise, priority =3D Host (goto step 2) 2. If priority =3D Host: *// priority order is host-meta, HTTP Link, elements* 1. metadata =3D lookup HostMetaLRDD(startURI, 1) 2. augment metadata with result of lookup HeaderLinks(startURI, 2) 3. augment metadata with lookup ResourceLinks(startURI, 3) 3. If priority =3D Resource:*// priority order is elements, HTTP Link, host-meta* 1. metadata =3D lookup ResourceLinks(startURI, 1) 2. augment metadata with result of lookup HeaderLinks(startURI, 2) 3. augment metadata with lookup HostMetaLRDD(startURI, 3) *where* HostMetaLRDD(uri, pri) is: 1. Revalidate local XRD data cache for hostof(*uri* )/.well-known/host-meta. 2. Find*the first link*with rel=3D=94lrdd=94 in host-meta document (call= the href value *lrdd_url*) 3. Revalidate local XRD data cache for *lrdd_url,*annotating each link with *lrdd_pri*=3Dpri 4. Return metadata (non-lrdd links and properties) for *lrdd_uri* HeaderLinks(uri, pri) is: 1. If uri is not dereferenceable (e.g., acct:) return empty set 2. Revalidate local resource link cache for *uri* 3. Retrieve Link: headers for resource from cache, annotating each link with *lrdd_pri*=3Dpri 4. Return links to caller ResourceLinks(uri, pri) is: 1. If uri is not dereferenceable (e.g., acct:) return empty set 2. Revalidate local resource link cache for *uri*, annotating each link with *lrddsrc =3D*resource 3. Retrieve MIME-type-specific set of links known for resource, annotating each link with *lrdd_pri=3D*pri 4. Return links to caller augment X with Y with priority pri is: 1. For each set of links y in Y sharing link relation r: 1. if r=3D=3D=94lrdd=94, and X does not already contain a link with rel=3D=94lrdd=94:, augment X with results of: 1. Revalidate local XRD data cache for first *href *for rel=3D=94l= rdd=94, annotating each link with *lrdd_pri*=3D pri 2. Augment X with resulting metadata from *href* 2. else, add list of links y to X. 2. Add all properties in Y to X. NB: Some link types can contain space-separated rel values, which are interpreted as a series of links with each of the space-separated rel value names in the above algorithm. NB: Ordering of links and properties from each source with the same rel/typ= e values is retained throughout, with the caveat that HTTP headers do not hav= e a guaranteed stable order. Security is not shown here, but is based on either TLS used throughout the retrievals or (for XRD) the XRD signature specification. Content type specific security may also be used to verify links within content (e.g., Magic Signatures over link elements). When set, the *secure *boolean indicates that a specific link or property was retrieved securely; when not set, it indicates that the retrieval path contained one or more insecure steps. The algorithm will also reject data that is red-flagged (e.g., if a CRL check shows that a certificate has been revoked as opposed to merely expiring). (?) *Result*: An ordered collection of metadata, consisting of links and properties, each of which is annotated with its*lrddsrc*provenance. There is at most one rel=3D=94lrdd=94 link in the collection which identifies the specific LRDD document used, if any. A client which wishes to coalesce links and properties found in all three places within a given rel or type value can just query the collection for the desired rel or type and retrieve collections of links or properties. Once retrieved, the set of metadata can be queried. An important/useful query is to retrieve the list of links with a given rel value: get_links(metadata, rel) # Get sequence of links with given rel value, or empty list if not found. Sometimes you may require that only the first set of links found count: get_top_priority_links(metadata, rel) # Get sequence of links with given rel value, ignoring all but the first set found ...and of course you can do a similar query for properties. --0016e64cca7e2f3a770482a89792 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
All,

This is my attempt to translate=A0= http://tools.ietf.org/html/draft-hammer-discovery-04= =A0into an actiona= ble algorithm, as a first step in attempting to write a truly general resou= rce discovery library that matches the latest spec. =A0It is written under = the assumption that a client may wish to query for sets of links with a giv= en relvalue, and is not going to wish to retrieve and re-parse host-meta fi= les any more often than necessary. =A0Feedback welcomed!

Definitions
  • startURI: Starting point for di= scovery; input into the discovery process. =A0Discovery produces metadata f= or=A0<= i>startURI.
  • meta data:A collection of links and properties for the resource.
  • link: = An abstract edge between thestartU= RIresource an= d another resource identified by a field=A0href. =A0Has arel<= /font><= font class=3D"Apple-style-span" size=3D"3">field indicating the relationshi= p from=A0startURI=A0to=A0<= /span>href.=A0Has a=A0lrdd_pri=A0<= /font>field indicati= ng ordering within the=A0rel=A0value. =A0Has a= =A0= secure=A0boolean field indicating whether it= was retrieved securely. =A0Can be annotated with arbitrary=A0properties.
  • property: A piece of metadata about a resource less structured than a=A0link.=A0Only present for XRD-derived data. =A0Has a=A0= secure=A0= boolean field indicating whether it wa= s retrieved securely.


<= b>Algorithm
  1. Determine priority order (Host-priority or Resource-p= riority):
    1. lookup HostMetaLRDD(startURI)
    2. if above lookup fails beca= use Host(startURI) is not available, priority =3D Resource (goto step 2)
    3. Else, does result contain = XRD/Property@type=3Dhttp://lr= dd.net/priority/resource?
    4. If yes, then priority =3D = Resource (goto step 2)
    5. Otherwise, priority =3D Ho= st (goto step 2)
  2. If priority =3D Host: =A0= // priority order is host-meta, HT= TP Link, <Link> elements
    1. metadata =3D lookup HostMetaLRDD(startURI, 1)
    2. augment metadata with resu= lt of lookup HeaderLinks(startURI, 2)
    3. augment metadata with look= up ResourceLinks(startURI, 3)
  3. If priority =3D Resource:= // priority order is <Link> = elements, HTTP Link, host-meta
    1. metadata =3D lookup ResourceLinks(startURI, 1)
    2. augment metadata with resu= lt of lookup HeaderLinks(startURI, 2)
    3. augment metadata with look= up HostMetaLRDD(startURI, 3)

where

HostMetaLRDD(uri, pri) is:
  1. Revalidate local XRD data cache for hostof(uri)/.well-known/host-meta.
  2. Findthe first linkwith rel=3D=94lrdd=94 in host-meta document (call the href = value=A0lrdd_url)<= /li>
  3. Revalidate local XRD data cache for=A0lrdd_url,annotating each link with=A0<= /span>lrdd_pri=3Dpri
  4. Return metadata (non-lrdd links and properties) fo= r=A0lrdd_uri


<= font class=3D"Apple-style-span" size=3D"3">HeaderLinks(uri, pri) is:=
  1. If uri is not dereferenceable = (e.g., acct:) return empty set
  2. Revalidate local resource link= cache for=A0uri=
  3. Retrieve Link: headers for res= ource from cache, annotating each link with=A0<= span class=3D"Apple-style-span" style=3D"vertical-align: baseline; font-siz= e: 9.02778px; ">lrdd_pri=3Dpri
  4. Return links to caller<= /font>


<= font class=3D"Apple-style-span" size=3D"3">ResourceLinks(uri, pri) is:
  1. If uri is not dereferenceable = (e.g., acct:) return empty set
  2. Revalidate local resource link= cache for=A0uri= = , annotating each link with=A0<= /font>lrddsrc =3Dresource<= /li>
  3. Retrieve MIME-type-specific se= t of links known for resource, annotating each link with=A0lrdd_pri=3Dpri
  4. Return links to caller<= /font>


<= font class=3D"Apple-style-span" size=3D"3">augment X with Y with priority p= ri is:
  1. For each set of links y in Y s= haring link relation r:
    1. if r=3D=3D=94lrdd=94, and X does not already cont= ain a link with rel=3D=94lrdd=94:, augment X with results of:=
      1. Revalidate local XRD data cache for first=A0href=A0= for rel=3D=94lrdd=94, annotating each link= with=A0lrdd_pri=3D pri
      2. Augment X with resulting m= etadata from=A0href
    2. else, add list of lin= ks y to X.
  2. Add all properties in Y t= o X.


<= font class=3D"Apple-style-span" size=3D"3">NB: Some link types can contain = space-separated rel values, which are interpreted as a series of links with= each of the space-separated rel value names in the above algorithm.=

NB: Ordering of links and properties from= each source with the same rel/type values is retained throughout, with the= caveat that HTTP headers do not have a guaranteed stable order.

Security is not shown here, but is based = on either TLS used throughout the retrievals or (for XRD) the XRD signature= specification. =A0Content type specific security may also be used to verif= y links within content (e.g., Magic Signatures over link elements). =A0When= set, the=A0secure=A0boolean indicates that a s= pecific link or property was retrieved securely; when not set, it indicates= that the retrieval path contained one or more insecure steps. =A0The algor= ithm will also reject data that is red-flagged (e.g., if a CRL check shows = that a certificate has been revoked as opposed to merely expiring). =A0(?)<= /font>

Result= :

An ordered collection of metadata, consis= ting of links and properties, each of which is annotated with itslrddsrcprovenance. =A0There is at most one rel=3D=94lrd= d=94 link in the collection which identifies the specific LRDD document use= d, if any. =A0

A client which wishes to coalesce links a= nd properties found in all three places within a given rel or type value ca= n just query the collection for the desired rel or type and retrieve collec= tions of links or properties.

Once retrieved, the set of metadata can b= e queried. =A0An important/useful query is to retrieve the list of links wi= th a given rel value:

get_links(metadata, rel) =A0# Get sequenc= e of links with given rel value, or empty list if not found.<= /font>

Sometimes you may require that only the f= irst set of links found count:

get_top_priority_links(metadata, rel) =A0= # Get sequence of links with given rel value, ignoring all but the first se= t found

...and of course you can do a similar que= ry for properties. --0016e64cca7e2f3a770482a89792-- From eran@hueniverse.com Thu Mar 25 18:02:26 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C2513A6924 for ; Thu, 25 Mar 2010 18:02:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.54 X-Spam-Level: X-Spam-Status: No, score=-0.54 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d+qQ7HF6V00H for ; Thu, 25 Mar 2010 18:02:24 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id C91C23A68F8 for ; Thu, 25 Mar 2010 18:02:24 -0700 (PDT) Received: (qmail 17709 invoked from network); 26 Mar 2010 01:02:47 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.20) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 26 Mar 2010 01:02:46 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT002.EX1.SECURESERVER.NET ([72.167.180.20]) with mapi; Thu, 25 Mar 2010 18:02:46 -0700 From: Eran Hammer-Lahav To: John Panzer , "apps-discuss@ietf.org" Date: Thu, 25 Mar 2010 18:03:01 -0700 Subject: RE: Notes on draft-hammer-discovery-04 Thread-Topic: Notes on draft-hammer-discovery-04 Thread-Index: AcrLb5h3LJcGdiKkTF6IIJ+umwXsrwBD035Q Message-ID: <90C41DD21FB7C64BB94121FBBC2E723438E20DA9D3@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "webfinger@googlegroups.com" , "salmon-protocol@googlegroups.com" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2010 01:02:26 -0000 Thanks John. > -----Original Message----- > From: John Panzer [mailto:jpanzer@google.com] > Sent: Wednesday, March 24, 2010 9:25 AM > Some comments and questions about section 3, Discovery Process: >=20 > The section lists two use cases, one in which a client is looking for "a = link" and > another in which a client is looking for "metadata ... other than a link = to > another resource". >=20 > (1) It would be good to have an example of the latter. For example, looking for a resource property such as: http://example.com/post?id=3D1 > (2) What if a client simply wants to retrieve all of the available metada= ta -- > including links -- for a given resource, honoring the host-priority, but = doing a > full transitive closure retrieval of everything of interest? =A0This is a= n extremely > natural thing to do, especially for a caching client, and should be possi= ble if > the specification is logically consistent. =A0But there's no mention of t= his use > case. I think this is implied. If you are looking for more than one qualified lin= k, just keep going. The workflow is focused on getting the first qualified = link. If that fails, you get the next qualified link. But if you feel this = is important to address directly, I can tweak the language to address that. > (3) The following section leaves me with additional questions: >=20 > > If the information being sought is a link: find a link matching the des= ired > > criteria by processing the links in order. > > If a qualified link is found, the process ends successfully. >=20 > Typically one is searching for links with a given rel value, and in the g= eneral > case this results in a collection of links. The wording above seems to be= aimed > at the (simple) case where you are looking for a link with cardinality 0 = or > 1. =A0But it doesn't address the general case. The link cardinality doesn't matter. You grab the first one you find. If yo= u want all links you just go ahead and continue (instead of returning a lin= k, you add it to a list and continue). However, rel=3D'lrdd' links are treated differently, where you only use the= first link, ignoring all other rel=3D'lrdd' links in the same source. This= was done to make client simpler and remove the ability to link to a list o= f LRDD documents. I am not a client developer so removing this restriction = is not going to bother me much. Any thoughts? > If you are looking for a set of links, the spec could either say that all= links with > a given rel value MUST be co-located in the same document. =A0Or, it coul= d say > that clients MUST keep searching all documents (honoring host-priority) u= ntil > they exhaust the possible set of documents looking for rel values. =A0Are= there > any other choices? This is what I didn't want to do. I don't want to require full processing o= f all links. I think most applications will be satisfied using the first qu= alified link they find. EHL From jpanzer@google.com Fri Mar 26 10:07:59 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6A2E3A6807 for ; Fri, 26 Mar 2010 10:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.246 X-Spam-Level: X-Spam-Status: No, score=-102.246 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1YXUFWCsd6lO for ; Fri, 26 Mar 2010 10:07:58 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 263853A6B87 for ; Fri, 26 Mar 2010 10:07:57 -0700 (PDT) Received: from hpaq2.eem.corp.google.com (hpaq2.eem.corp.google.com [10.3.21.2]) by smtp-out.google.com with ESMTP id o2QH8J1Q030992 for ; Fri, 26 Mar 2010 10:08:20 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1269623300; bh=HjzKoYDTr2qwch48i84IPjeLaC8=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=QZV66sZkw+ab2+GnvFnEZDDP2aGQ123FP/vQHBil2BI8X2PJDAjgZG6xhKiNBAXO2 yy2+j8eVJ9YHHPZAB1jYw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding:x-system-of-record; b=YsiHv2T+N0gX0LSA3gSwBXt3PAYGvdSai6w8RV4GyvR5gf9AmBFC0ec062ejvSUoH bz+DOBKeC9RTMO+8Db9UA== Received: from pxi15 (pxi15.prod.google.com [10.243.27.15]) by hpaq2.eem.corp.google.com with ESMTP id o2QH8Fa7011316 for ; Fri, 26 Mar 2010 18:08:18 +0100 Received: by pxi15 with SMTP id 15so4358621pxi.12 for ; Fri, 26 Mar 2010 10:08:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.194.87 with HTTP; Fri, 26 Mar 2010 10:07:54 -0700 (PDT) In-Reply-To: References: From: John Panzer Date: Fri, 26 Mar 2010 10:07:54 -0700 Received: by 10.115.28.8 with SMTP id f8mr1411279waj.65.1269623294387; Fri, 26 Mar 2010 10:08:14 -0700 (PDT) Message-ID: Subject: Re: Query on discovery algoritm for LRDD (draft-hammer-discovery-04) To: apps-discuss@ietf.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: webfinger@googlegroups.com, "salmon-protocol@googlegroups.com" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2010 17:07:59 -0000 Note: By popular demand, I've attempted to convert this into a readable plain text form (below). This is my attempt to translate http://tools.ietf.org/html/draft-hammer-discovery-04 into an actionable algorithm, as a first step in attempting to write a truly general resource discovery library that matches the latest spec. It is written under the assumption that a client may wish to query for sets of links with a given relvalue, and is not going to wish to retrieve and re-parse host-meta files any more often than necessary. Feedback welcomed! Definitions startURI: Starting point for discovery; input into the discovery process. Discovery produces metadata for startURI. metadata: A collection of links and properties for the resource. link: An abstract edge between the startURI resource and another resource identified by a field href. Has a rel field indicating the relationship from startURI to href. Has a lrdd_pri field indicating ordering within the rel value. Has a secure boolean field indicating whether it was retrieved securely. Can be annotated with arbitrary properties. property: A piece of metadata about a resource less structured than a link. Only present for XRD-derived data. Has a secure boolean field indicating whether it was retrieved securely. Algorithm Determine priority order (Host-priority or Resource-priority): lookup HostMetaLRDD(startURI) if above lookup fails because Host(startURI) is not available, priority =3D Resource Else, does result contain XRD/Property@type=3Dhttp://lrdd.net/priority/resource? If yes, then priority =3D Resource. Otherwise, priority =3D Host If priority =3D Host: // priority order is host-meta, HTTP Link, elements metadata =3D lookup HostMetaLRDD(startURI, 1) augment metadata with result of lookup HeaderLinks(startURI, 2) augment metadata with lookup ResourceLinks(startURI, 3) If priority =3D Resource: // priority order is elements, HTTP Link, host-meta metadata =3D lookup ResourceLinks(startURI, 1) augment metadata with result of lookup HeaderLinks(startURI, 2) augment metadata with lookup HostMetaLRDD(startURI, 3) where HostMetaLRDD(uri, pri) is: Revalidate local XRD data cache for hostof(uri)/.well-known/host-meta. Findthe first linkwith rel=3D=94lrdd=94 in host-meta document (call the href value lrdd_url) Revalidate local XRD data cache for lrdd_url,annotating each link with lrdd_pri=3Dpri Return metadata (non-lrdd links and properties) for lrdd_uri HeaderLinks(uri, pri) is: If uri is not dereferenceable (e.g., acct:) return empty set Revalidate local resource link cache for uri Retrieve Link: headers for resource from cache, annotating each link with lrdd_pri=3Dpri Return links to caller ResourceLinks(uri, pri) is: If uri is not dereferenceable (e.g., acct:) return empty set Revalidate local resource link cache for uri Retrieve MIME-type-specific set of links known for resource, annotating e= ach link with lrdd_pri=3Dpri Return links to caller augment X with Y with priority pri is: For each set of links y in Y sharing link relation r: if r=3D=3D=94lrdd=94, and X does not already contain a link with rel=3D=94lrdd=94: augment X with results of: Revalidate local XRD data cache for first href for rel=3D=94lrdd=94= , annotating each link with lrdd_pri=3Dpri Augment X with resulting metadata from href else, add list of links y to X. Add all properties in Y to X. NB: Some link types can contain space-separated rel values, which are interpreted as a series of links with each of the space-separated rel value names in the above algorithm. NB: Ordering of links and properties from each source with the same rel/type values is retained throughout, with the caveat that HTTP headers do not have a guaranteed stable order. Security is not shown here, but is based on either TLS used throughout the retrievals or (for XRD) the XRD signature specification. Content type specific security may also be used to verify links within content (e.g., Magic Signatures over link elements). When set, the secure boolean indicates that a specific link or property was retrieved securely; when not set, it indicates that the retrieval path contained one or more insecure steps. The algorithm will also reject data that is red-flagged (e.g., if a CRL check shows that a certificate has been revoked as opposed to merely expiring). (?) Result: An ordered collection of metadata, consisting of links and properties, each of which is annotated with its lrdd_pri in case it matters. There is = at most one rel=3D=94lrdd=94 link in the collection which identifies the specific LRDD document used, if any, and any metadata from that lrdd document is transcluded into the metadata collection. A client which wishes to coalesce links and properties found in all three places within a given rel or type value can just query the collection for the desired rel or type and retrieve collections of links or properties. Once retrieved, the set of metadata can be queried. An important/useful query is to retrieve the list of links with a given rel value: get_links(metadata, rel) # Get sequence of links with given rel value, or empty list if not found. Sometimes you may require that only the first set of links found count: get_top_priority_links(metadata, rel) # Get sequence of links with given rel value, ignoring all but the first set found ...and of course you can do a similar query for properties. From eran@hueniverse.com Sat Mar 27 14:41:00 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EED63A6802 for ; Sat, 27 Mar 2010 14:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.481 X-Spam-Level: X-Spam-Status: No, score=0.481 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y7dFVrqyIH+6 for ; Sat, 27 Mar 2010 14:40:58 -0700 (PDT) Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by core3.amsl.com (Postfix) with SMTP id 368833A6403 for ; Sat, 27 Mar 2010 14:40:57 -0700 (PDT) Received: (qmail 8656 invoked from network); 27 Mar 2010 21:41:22 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 27 Mar 2010 21:41:20 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Sat, 27 Mar 2010 14:41:19 -0700 From: Eran Hammer-Lahav To: John Panzer , "apps-discuss@ietf.org" Date: Sat, 27 Mar 2010 14:41:40 -0700 Subject: RE: Query on discovery algoritm for LRDD (draft-hammer-discovery-04) Thread-Topic: Query on discovery algoritm for LRDD (draft-hammer-discovery-04) Thread-Index: AcrNBvA+97iTpvdqTnaR2P73j9JLzgAvliCg Message-ID: <90C41DD21FB7C64BB94121FBBC2E723438E20DAD23@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: "webfinger@googlegroups.com" , "salmon-protocol@googlegroups.com" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Mar 2010 21:41:00 -0000 > -----Original Message----- > From: John Panzer [mailto:jpanzer@google.com] > Sent: Friday, March 26, 2010 10:08 AM > This is my attempt to translate > http://tools.ietf.org/html/draft-hammer-discovery-04 into an actionable > algorithm, as a first step in attempting to write a truly general resourc= e > discovery library that matches the latest spec. > It is written under the assumption that a client may wish to query for se= ts of > links with a given relvalue, and is not going to wish to retrieve and re-= parse > host-meta files any more often than necessary. Feedback welcomed! >=20 > Definitions >=20 > startURI: Starting point for discovery; input into the discovery process. > Discovery produces metadata for startURI. >=20 > metadata: A collection of links and properties for the resource. >=20 > link: An abstract edge between the startURI resource and another resource > identified by a field href. Has a rel field indicating the relationship = from > startURI to href. Has a lrdd_pri field indicating ordering within the rel= value. > Has a secure boolean field indicating whether it was retrieved securely. = Can > be annotated with arbitrary properties. >=20 > property: A piece of metadata about a resource less structured than a lin= k. > Only present for XRD-derived data. Has a secure boolean field indicating > whether it was retrieved securely. Link headers and elements can include extension parameters that are either = rel-specific or document specific. These will be in the form of key/value p= airs but in which the key is a short name, not a URI (like XRD t= ype). In markup the can have a namespace. I generally prefer people used the XRD facility instead of exten= ding the link schema (for header format). > Algorithm >=20 > Determine priority order (Host-priority or Resource-priority): >=20 > lookup HostMetaLRDD(startURI) What does this do in this context? Your Function below is aimed for getting= metadata, not just raw host-meta. > if above lookup fails because Host(startURI) is not available, priority = =3D > Resource Else, does result contain > XRD/Property@type=3Dhttp://lrdd.net/priority/resource? If yes, then prio= rity > =3D Resource. Otherwise, priority =3D Host >=20 > If priority =3D Host: > // priority order is host-meta, HTTP Link, elements > metadata =3D lookup HostMetaLRDD(startURI, 1) > augment metadata with result of lookup HeaderLinks(startURI, 2) > augment metadata with lookup ResourceLinks(startURI, 3) >=20 > If priority =3D Resource: > // priority order is elements, HTTP Link, host-meta > metadata =3D lookup ResourceLinks(startURI, 1) > augment metadata with result of lookup HeaderLinks(startURI, 2) > augment metadata with lookup HostMetaLRDD(startURI, 3) >=20 > where >=20 > HostMetaLRDD(uri, pri) is: > Revalidate local XRD data cache for hostof(uri)/.well-known/host-meta. How do you handle http vs https? Follow redirections. Validate host-meta is valid for the desired host. > Find the first link with rel=3D"lrdd" in host-meta document (call > the href value lrdd_url) Apply template... > Revalidate local XRD data cache for lrdd_url,annotating each link > with lrdd_pri=3Dpri > Return metadata (non-lrdd links and properties) for lrdd_uri >=20 >=20 > HeaderLinks(uri, pri) is: > If uri is not dereferenceable (e.g., acct:) return empty set If you URI is not http/https, or if a GET/HEAD returns a response that does= not contains a representation for the requested resource. See: http://tool= s.ietf.org/html/draft-ietf-httpbis-p2-semantics-09#section-6.1 > Revalidate local resource link cache for uri > Retrieve Link: headers for resource from cache, annotating > each link with lrdd_pri=3Dpri > Return links to caller >=20 > ResourceLinks(uri, pri) is: > If uri is not dereferenceable (e.g., acct:) return empty set > Revalidate local resource link cache for uri > Retrieve MIME-type-specific set of links known for resource, annotating > each > link with lrdd_pri=3Dpri > Return links to caller >=20 >=20 > augment X with Y with priority pri is: > For each set of links y in Y sharing link relation r: > if r=3D=3D"lrdd", and X does not already > contain a link with rel=3D"lrdd": > augment X with results of: > Revalidate local XRD data cache for first href for rel=3D"lrdd", > annotating each link with lrdd_pri=3Dpri > Augment X with resulting metadata from href > else, > add list of links y to X. > Add all properties in Y to X. >=20 >=20 > NB: Some link types can contain space-separated rel values, which are > interpreted as a series of links with each of the space-separated rel val= ue > names in the above algorithm. >=20 > NB: Ordering of links and properties from each source with the same rel/t= ype > values is retained throughout, with the caveat that HTTP headers do not > have a guaranteed stable order. >=20 > Security is not shown here, but is based on either TLS used throughout th= e > retrievals or (for XRD) the XRD signature specification. Content type sp= ecific > security may also be used to verify links within content (e.g., Magic > Signatures over link elements). When set, the secure boolean indicates t= hat > a specific link or property was retrieved securely; when not set, it indi= cates > that the retrieval path contained one or more insecure steps. The algori= thm > will also reject data that is red-flagged (e.g., if a CRL check shows tha= t a > certificate has been revoked as opposed to merely expiring). (?) >=20 > Result: >=20 > An ordered collection of metadata, consisting of links and properties, ea= ch of > which is annotated with its lrdd_pri in case it matters. There is at mos= t one > rel=3D"lrdd" link in the collection which identifies the specific LRDD do= cument > used, if any, and any metadata from that lrdd document is transcluded int= o > the metadata collection. There can be more than one LRDD document, but only one is used from each so= urce. There should not be any rel=3D'lrdd' in the collection because it is = either expanded or dropped (not first). > A client which wishes to coalesce links and properties found in all three > places within a given rel or type value can just query the collection for= the > desired rel or type and retrieve collections of links or properties. >=20 > Once retrieved, the set of metadata can be queried. An important/useful > query is to retrieve the list of links with a given rel value: >=20 > get_links(metadata, rel) # Get sequence of links with given rel value, o= r > empty list if not found. >=20 > Sometimes you may require that only the first set of links found > count: >=20 > get_top_priority_links(metadata, rel) # Get sequence of links with given= rel > value, ignoring all but the first set found >=20 > ...and of course you can do a similar query for properties. EHL From eran@hueniverse.com Sat Mar 27 16:02:24 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACE5D3A67E2 for ; Sat, 27 Mar 2010 16:02:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.862 X-Spam-Level: X-Spam-Status: No, score=0.862 tagged_above=-999 required=5 tests=[AWL=-0.869, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HNYG18KWhUbH for ; Sat, 27 Mar 2010 16:02:20 -0700 (PDT) Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id 34DC13A67A3 for ; Sat, 27 Mar 2010 16:02:20 -0700 (PDT) Received: (qmail 17778 invoked from network); 27 Mar 2010 23:02:45 -0000 Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 27 Mar 2010 23:02:44 -0000 Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Sat, 27 Mar 2010 16:02:45 -0700 From: Eran Hammer-Lahav To: "webfinger@googlegroups.com" , "apps-discuss@ietf.org" Date: Sat, 27 Mar 2010 16:03:04 -0700 Subject: RE: Query on discovery algoritm for LRDD (draft-hammer-discovery-04) Thread-Topic: Query on discovery algoritm for LRDD (draft-hammer-discovery-04) Thread-Index: AcrOAHDwurYu9tK4RH2cT+/dtvePpAAANuDg Message-ID: <90C41DD21FB7C64BB94121FBBC2E723438E20DAD25@P3PW5EX1MB01.EX1.SECURESERVER.NET> References: <90C41DD21FB7C64BB94121FBBC2E723438E20DAD23@P3PW5EX1MB01.EX1.SECURESERVER.NET> <560F0BCB-30E4-4CBA-811D-2A6057A3D0CF@josephholsten.com> In-Reply-To: <560F0BCB-30E4-4CBA-811D-2A6057A3D0CF@josephholsten.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: "salmon-protocol@googlegroups.com" X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Mar 2010 23:02:24 -0000 > -----Original Message----- > From: webfinger@googlegroups.com > [mailto:webfinger@googlegroups.com] On Behalf Of Joseph Holsten > Sent: Saturday, March 27, 2010 3:54 PM > To: apps-discuss@ietf.org > Cc: webfinger@googlegroups.com; salmon-protocol@googlegroups.com > Subject: Re: Query on discovery algoritm for LRDD (draft-hammer-discovery= - > 04) >=20 > On Mar 27, 2010, at 4:41 PM, Eran Hammer-Lahav wrote: > >> HeaderLinks(uri, pri) is: > >> If uri is not dereferenceable (e.g., acct:) return empty set > > > > If you URI is not http/https, or if a GET/HEAD returns a response that = does > not contains a representation for the requested resource. See: > http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-09#section-6.1 >=20 > That reminds me, is there a good Accept header for the initial URI reques= t? > The draft mentions ways to get links from application/xrd+xml, > application/atom+xml, application/xhtml+xml, text/html. Are there any > other situations that can usually work? Should a client claim support for > application/xml and text/xml, since they could include a atom:link? Are t= here > other link formats that clients should be supporting? XLink is used in SV= G, if I > remember correctly. >=20 > I'm thinking the Accept has to have */*, due to all the */*+xml types, so= the > only purpose of the Accept will be to express preference for xhtml over > html, &c. At this point HTML, XHTML, and ATOM support typed links with compatible sem= antics. If you have other formats its up to you to decide if you want your = client to use links found there. > I notice draft-hammer-discovery-04 uses an explicit Accept: text/html on > page 3. Is that really intended? Should I read anything into that? The client is asking for HTML because that's one of the markup formats it u= nderstands. There is no requirement for clients to speak ATOM if they don't= deal with ATOM documents as part of the resources they care about. EHL > http://josephholsten.com >=20 > To unsubscribe from this group, send email to > webfinger+unsubscribegooglegroups.com or reply to this email with the > words "REMOVE ME" as the subject. From alexey.melnikov@isode.com Sun Mar 28 17:01:22 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89B4F3A6403 for ; Sun, 28 Mar 2010 17:01:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.86 X-Spam-Level: * X-Spam-Status: No, score=1.86 tagged_above=-999 required=5 tests=[AWL=0.729, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00+KwjsM2V92 for ; Sun, 28 Mar 2010 17:01:21 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 0AAC13A63EC for ; Sun, 28 Mar 2010 17:01:21 -0700 (PDT) Received: from [92.40.219.107] (92.40.219.107.sub.mbb.three.co.uk [92.40.219.107]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Mon, 29 Mar 2010 00:32:57 +0100 Message-ID: <4BAFE72A.8070503@isode.com> Date: Mon, 29 Mar 2010 00:32:58 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.21) Gecko/20090303 SeaMonkey/1.1.15 To: Apps Discuss Subject: Alexey's Apps Area Activity Report for March 2010 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: alexey-melnikov-chairs@tools.ietf.org X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 00:01:22 -0000 BOFs in Anaheim: - DECADE - charter approved for external review before the BOF itself. - NewPrep (updates to StringPrep and its profiles) - successful BOF. Peter Saint-Andre is likely to be the responsible AD for this. - IRDE (Internet Registration Escrow) - interest to work on this, but some confusion on scope. [Update on WG status would be sent out separately.] Document Status and Progress: Active documents, my action: - draft-daboo-srv-email (Proposed Standard) - need to add the document to IESG telechat - draft-reschke-webdav-post (Experimental) - need to do AD review - draft-altman-tls-channel-bindings (Proposed Standard) - took over the document from Pasi. Need to do AD review and redo IETF LC, due to massive changes. - draft-ietf-tsvwg-iana-ports (BCP) - re-reviewed, waiting for another revision and then TSVWG WGLC - draft-gudmundsson-dns-srv-iana-registry - need to re-review Active documents in IETF LC or IESG review: - draft-ietf-eai-mailinglist (Experimental) - in IETF LC - draft-freed-sieve-notary (Proposed Standard) - in IETF LC - draft-denenberg-mods-etc-media-types (Proposed Standard) - in IETF LC - draft-ietf-morg-sortdisplay (Proposed Standard) - in IESG review - draft-reschke-rfc2231-in-http (Proposed Standard) - in IESG review. Waiting for a small update. - draft-nottingham-http-link-header (Proposed Standard) - in IESG review. Waiting for a small update. In RFC Editor's queue: - draft-gould-rfc4310bis (Proposed Standard) - need to check a minor error reported after approval - draft-ietf-vcarddav-carddav (Proposed Standard) - draft-ietf-yam-rfc1652bis (Standard) - draft-allbery-afs-srv-records (Proposed Standard) - draft-ietf-eai-downgraded-display (Experimental) - in AUTH48 - draft-ietf-webdav-bind (Experimental) - draft-reschke-rfc2731bis (Informational) - draft-roach-sip-http-subscribe (Proposed Standard) Published as RFCs: draft-klensin-ftp-registry (Proposed Standard) - RFC 5797 draft-dusseault-http-patch (Proposed Standard) - RFC 5789 draft-ietf-eai-imap-utf8 (Experimental) - RFC 5738 draft-ietf-eai-pop (Experimental) - RFC 5721 Active documents, waiting on others: - draft-saintandre-tls-server-id-check (Proposed Standard) - a new revision needed based on recent comments - draft-duerst-mailto-bis - IETF LC ended, need a new revision to address Ned Freed's comments - draft-hethmon-mcmurray-ftp-hosts (Proposed Standard) - performed AD review, new revision needed - draft-giralt-schac-ns (Informational) - took over the document from Lisa, new revision needed. - draft-rosen-urn-nena (Informational) - took over the document from Lisa, waiting for additional information from Lisa - draft-larmouth-oid-iri (Proposed Standard) - took over the document from Lisa, new revision needed - draft-cridland-acap-vendor-registry (Proposed Standard) - New revision needed. - draft-desruisseaux-caldav-sched (Proposed Standard) - performed AD review, new revision needed draft-zeilenga-ldap-dontusecopy (Proposed Standard) - performed AD review, new revision needed - draft-dawkins-ldapext-subnot - performed informal review - draft-burnett-pronunciation-alphabet-registry (None) - waiting for authors to address comments from a Language Tag expert reviewer (Doug Ewell) List of DISCUSSes I am currently holding: Old: draft-moriarty-post-inch-rid-10.txt draft-ietf-pkix-new-asn1-07.txt draft-drage-sipping-service-identification-03.txt draft-mraihi-inch-thraud-09.txt draft-ietf-dhc-dhcpv4-vendor-message-01.txt draft-ietf-dhc-dhcpv6-vendor-message-01.txt New or recently updated (last 3 weeks): draft-gennai-smime-cnipa-pec-05.txt draft-ietf-geopriv-geo-uri-04.txt Cleared DISCUSSes: draft-bryan-metalink-28.txt draft-josefsson-kerberos5-starttls-08.txt draft-ietf-geopriv-lis-discovery-13.txt draft-ietf-sip-certs-09.txt draft-ietf-dime-diameter-qos-13.txt draft-ietf-mmusic-connectivity-precon-06.txt draft-ietf-sipping-rtcp-summary-08.txt Other activities/actions: Done: - draft-ietf-sasl-scram (my own document) in AUTH48 - draft-melnikov-sasl-scram-ldap (my own document) in AUTH48 - draft-melnikov-imap-keywords (my own document) - published - SASL GS2 (acting as a document shepherd, not as the responsible AD) - in AUTH48 Ongoing: - Need to finish iMIP draft [ietf-calsify-rfc2447bis] (my own document) My action: - Need to review OAuth document regarding possible reuse of SCRAM - Need to post 4954bis (SMTP AUTH) in order to start moving it to Draft Standard - draft-ietf-sieve-external-lists (my own document) - needs updating. Thanks to Barry Leiba for picking this up. - SIP Sieve notify (my own document) - needs refreshing Waiting for others: - Suggestion to move LMTP to Standard Track (Ned Freed agreed to update the document, then responded that John Myers is interested to do this himself. Chris Newman agreed to shepherd it) - Suggestion to convert MIME BNF to ABNF and publish as a separate draft (Ned Freed agreed to do this) From julian.reschke@gmx.de Mon Mar 29 05:57:10 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68D5D3A6A43 for ; Mon, 29 Mar 2010 05:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m6Cjh78xmxIH for ; Mon, 29 Mar 2010 05:57:09 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 44F523A6A1A for ; Mon, 29 Mar 2010 05:57:08 -0700 (PDT) Received: (qmail invoked by alias); 29 Mar 2010 12:57:35 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.119]) [217.91.35.233] by mail.gmx.net (mp006) with SMTP; 29 Mar 2010 14:57:35 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19ru0oN6jFrVwolTnddUHrl6j8OWa964F31G5jTYr 3h+fpFj1pTEuOO Message-ID: <4BB0A3BF.1030608@gmx.de> Date: Mon, 29 Mar 2010 14:57:35 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: IETF Apps Discuss , HTTP Working Group Subject: Re: FYI: IETF LC for draft-reschke-rfc2231-in-http References: <20100222140422.2EFC728C125@core3.amsl.com> <4B829C3C.3070901@gmx.de> In-Reply-To: <4B829C3C.3070901@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.54000000000000004 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 12:57:10 -0000 On 22.02.2010 16:01, Julian Reschke wrote: > ... > Hi there, > > this spec is now in Last Call, ending March, 22. > > A few issues are open, and those are summarized in Appendix D. I'm > particularly looking for feedback on: > > - parameter-abnf > > In Section 3.2: > > Type: change > > julian.reschke@greenbytes.de (2010-02-20): The ABNF for reg-parameter > and ext-parameter is ambiguous, as "*" is a valid token character; > furthermore, RFC 2616's "attribute" production allows "*" while RFC > 2231's does not. (reported by Alexey Melnikov). > > julian.reschke@greenbytes.de (2010-02-21): Proposal: restrict the > allowable character set in parameter names to exclude "*" (and maybe > even more non-name characters?). Also, consider extending the set of > value characters (for the right hand side) to allow more characters > that can be unambiguously parsed outside quoted strings, such as "/". > > and This will be fixed as proposed in the next draft. > - iso8859 > > In Section 3.2: > > Type: change > > julian.reschke@greenbytes.de (2010-02-20): The protocol could be > further simplified by mandating UTF-8 only (reported by Alexey > Melnikov). On the other hand and not surprisingly, testing shows > that ISO-8859-1 support is widely implemented. The author is looking > for community feedback on this choice. > > Feedback on these specific issues would be appreciated, > ... There was no feedback at all on this one; as the existing implementations *do* support ISO-8859-1 I'm leaning towards leaving things as they are. Best regards, Julian From josephholsten@gmail.com Sat Mar 27 15:53:55 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 931B73A686C for ; Sat, 27 Mar 2010 15:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.62 X-Spam-Level: X-Spam-Status: No, score=0.62 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yrsiDnZf4RJF for ; Sat, 27 Mar 2010 15:53:54 -0700 (PDT) Received: from mail-iw0-f191.google.com (mail-iw0-f191.google.com [209.85.223.191]) by core3.amsl.com (Postfix) with ESMTP id 5AF123A67A3 for ; Sat, 27 Mar 2010 15:53:54 -0700 (PDT) Received: by iwn29 with SMTP id 29so5590977iwn.17 for ; Sat, 27 Mar 2010 15:54:16 -0700 (PDT) Received: by 10.231.168.85 with SMTP id t21mr1484057iby.0.1269730456401; Sat, 27 Mar 2010 15:54:16 -0700 (PDT) Received: from [192.168.1.101] (ip70-189-108-199.ok.ok.cox.net [70.189.108.199]) by mx.google.com with ESMTPS id d2sm2188527ibr.15.2010.03.27.15.54.14 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 27 Mar 2010 15:54:15 -0700 (PDT) Subject: Re: Query on discovery algoritm for LRDD (draft-hammer-discovery-04) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Joseph Holsten In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E723438E20DAD23@P3PW5EX1MB01.EX1.SECURESERVER.NET> Date: Sat, 27 Mar 2010 17:54:11 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <560F0BCB-30E4-4CBA-811D-2A6057A3D0CF@josephholsten.com> References: <90C41DD21FB7C64BB94121FBBC2E723438E20DAD23@P3PW5EX1MB01.EX1.SECURESERVER.NET> To: apps-discuss@ietf.org X-Mailer: Apple Mail (2.1077) X-Mailman-Approved-At: Mon, 29 Mar 2010 08:07:40 -0700 Cc: webfinger@googlegroups.com, salmon-protocol@googlegroups.com X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Mar 2010 22:53:55 -0000 On Mar 27, 2010, at 4:41 PM, Eran Hammer-Lahav wrote: >> HeaderLinks(uri, pri) is: >> If uri is not dereferenceable (e.g., acct:) return empty set >=20 > If you URI is not http/https, or if a GET/HEAD returns a response that = does not contains a representation for the requested resource. See: = http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-09#section-6.1 That reminds me, is there a good Accept header for the initial URI = request? The draft mentions ways to get links from application/xrd+xml, = application/atom+xml, application/xhtml+xml, text/html. Are there any = other situations that can usually work? Should a client claim support = for application/xml and text/xml, since they could include a atom:link? = Are there other link formats that clients should be supporting? XLink is = used in SVG, if I remember correctly. I'm thinking the Accept has to have */*, due to all the */*+xml types, = so the only purpose of the Accept will be to express preference for = xhtml over html, &c.=20 I notice draft-hammer-discovery-04 uses an explicit Accept: text/html on = page 3. Is that really intended? Should I read anything into that? -- http://josephholsten.com= From julian.reschke@gmx.de Mon Mar 29 08:23:51 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29D3B3A6A90 for ; Mon, 29 Mar 2010 08:23:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.147 X-Spam-Level: X-Spam-Status: No, score=-1.147 tagged_above=-999 required=5 tests=[AWL=-2.278, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b20yBNh27C7N for ; Mon, 29 Mar 2010 08:23:50 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 288F23A6A89 for ; Mon, 29 Mar 2010 08:22:34 -0700 (PDT) Received: (qmail invoked by alias); 29 Mar 2010 15:23:01 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.119]) [217.91.35.233] by mail.gmx.net (mp022) with SMTP; 29 Mar 2010 17:23:01 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19JpZRkeHNJFbBiYpvJ6msW/pNcLnD75FlIN66R8P gLYE2jzo0MKo7g Message-ID: <4BB0C5D4.2060604@gmx.de> Date: Mon, 29 Mar 2010 17:23:00 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Chris Newman Subject: Re: Comment on draft-reschke-rfc2231-in-http-10 section 4.3 References: <43E5645840A7C8169A56AAE2@446E7922C82D299DB29D899F> In-Reply-To: <43E5645840A7C8169A56AAE2@446E7922C82D299DB29D899F> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.52000000000000002 Cc: Ned Freed , ietf-http-wg@w3.org, IETF Apps Discuss , julian.reschke@greenbytes.de X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 15:23:51 -0000 On 23.03.2010 00:32, Chris Newman wrote: > RFC 2231 did not allow two parameters with the same name but different > languages, at least in the context of continuations that was impossible. > Absent continuations, RFC 2231 was otherwise silent on that topic. > > So section 4.3 adds a new feature over and above what RFC 2231 did. It's > a feature that will make implementations significantly more complex and > is likely to cause interoperability problems. > > Much of the experience with deployment of both language tagging and > language variants in the IETF seems to result in unnecessary complexity. > While there are good abstract arguments for language tagging in theory, > it seems more often than not that the parties in the exchange are unable > to put anything useful in the field in which case it falls into the > realm of unnecessary complexity. In addition, we have experience where > we attempted to allow language variants (multipart/alternative) and not > only did that usage not deploy, it is actively broken despite being an > explicit example in RFC 1766. > > The one place where I've seen language variants mostly work is when the > language tag is actually included in the attribute name (LDAP does this) > and the "search" mechanism allows wildcarding of languages. But having > two attributes with the same name seems dangerous. > > My recommendation is to remove this feature as I believe it will not be > used in practice and will add unnecessary complexity that is likely to > create interoperability problems. > > - Chris Yes, this is indeed a problem. Proposal: - state the issue - rephrase 4.2 accordingly - remove 4.3 This would change Section 4 to: -- snip -- 4. Guidelines for Usage in HTTP Header Field Definitions Specifications of HTTP header fields that use the extensions defined in Section 3.2 should clearly state that. A simple way to achieve this is to normatively reference this specification, and to include the ext-value production into the ABNF for that header field. For instance: foo-header = "foo" LWSP ":" LWSP token ";" LWSP title-param title-param = "title" LWSP "=" LWSP value / "title*" LWSP "=" LWSP ext-value ext-value = [[rfcno: Note to RFC Editor: in the figure above, please replace "xxxx" by the RFC number assigned to this specification.]] Note: The Parameter Value Continuation feature defined in Section 3 of [RFC2231] makes it impossible to have multiple instances of extended parameters with identical parmname components, as the processing of continuations would become ambiguous. Thus, specifications using this extension are RECOMMENDED to disallow this case for compatibility with RFC 2231. 4.1. When to Use the Extension Section 4.2 of [RFC2277] requires that protocol elements containing text are able to carry language information. Thus, the ext-value production should always be used when the parameter value is of textual nature and its language is known. Furthermore, the extension should also be used whenever the parameter value needs to carry characters not present in the US-ASCII ([USASCII]) character set (note that it would be unacceptable to define a new parameter that would be restricted to a subset of the Unicode character set). 4.2. Error Handling Header field specifications need to define whether multiple instances of parameters with identical parmname components are allowed, and how they should processed. It is recommended that a parameter using the extended syntax takes precedence. This could be used by producers to use both formats without breaking recipients that do not understand the extended syntax yet. Example: foo: bar; title="EURO exchange rates"; title*=utf-8''%e2%82%ac%20exchange%20rates In this case, the sender provides an ASCII version of the title for legacy recipients, but also includes an internationalized version for recipients understanding this specification -- the latter obviously should prefer the new syntax over the old one. Note: at the time of this writing, many implementations failed to ignore the form they do not understand, or prioritize the ASCII form although the extended syntax was present. -- snip -- Best regards, Julian From A.Hoenes@TR-Sys.de Mon Mar 29 13:44:46 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 943B83A687B; Mon, 29 Mar 2010 13:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.072 X-Spam-Level: X-Spam-Status: No, score=-94.072 tagged_above=-999 required=5 tests=[AWL=0.947, BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z5aseuAiUoHB; Mon, 29 Mar 2010 13:44:45 -0700 (PDT) Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 0BA3D3A65A6; Mon, 29 Mar 2010 13:44:43 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA088025482; Mon, 29 Mar 2010 22:44:42 +0200 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id WAA18251; Mon, 29 Mar 2010 22:44:41 +0200 (MESZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <201003292044.WAA18251@TR-Sys.de> Subject: New Version Notification for draft-ah-rfc2141bis-urn-00 (fwd) (resent) To: apps-discuss@ietf.org, uri-review@ietf.org, urn-nid@ietf.org Date: Mon, 29 Mar 2010 22:44:41 +0200 (MESZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 20:44:46 -0000 [[ Resending because of trouble with spam filtering (now resolved) ]] > From: Alfred HÎnes > To: apps-discuss@ietf.org, uri-review@ietf.org, urn-nid@ietf.org > Message-Id: <201003251139.MAA09048@TR-Sys.de> > Date: Thu, 25 Mar 2010 12:39:06 +0100 (MEZ) > Subject: New Version Notification for draft-ah-rfc2141bis-urn-00 (fwd) Folks, I have posted an initial draft version for a RFC 2141 bis, to give the 'urn' URI scheme a 'modern' definition document in line with STD 66 (RFC 3986) and BCP 35 (RFC 4395). My apologies for cross-posting. Please send follow-up messages to uri-review (provisional dispositon -- see below). This work is triggered by the PersID project that aims to establish an international network of stable resolution services for Persistent Identifiers (URNs), in particular for Bibliographic identifiers. To give that work a more solid ground, updates to the basic URN-related documents (RFC 2141 and RFC 3406) and URN namespace-specific RFCs are planned, and brought to the IETF, in order to bring these documents in alignment with current IETF Full Standards and IANA procedures. The ultimate goal is to establish a dedicated 'urnbis' WG in the IETF, hopefully by this summer, with an ambitious schedule to bring revised documents initially targetting PS / BCP status to the IESG, with the goal of fast progression of RFC 2141-bis on the Standards Track. During the work on this draft, ambiguities in RFC 2141 syntax and prose have been uncovered. Also, there seems to be an opportunity to better align the general URN ABNF with RFC 3986 general URI syntax. At this stage, I'm particularly interested in early discussion of the syntax questions raised by NOTEs and DISCUSS comments in Section 2[.*] . I envision that particular URN namespace definitions in the future could be allowed to admit (per namespace) standard and components as specified in RFC 3986 -- this question was explicitly deferred by RFC 2141 -- and to simplify the syntax of the Namespace Specific String (NSS) to simply be a . Kind regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ ----- Forwarded message from IETF I-D Submission Tool ----- > From: IETF I-D Submission Tool > Message-Id: <20100325111510.604AC3A6A7B@core3.amsl.com> > Date: Thu, 25 Mar 2010 04:15:10 -0700 (PDT) > Subject: New Version Notification for draft-ah-rfc2141bis-urn-00 A new version of I-D, draft-ah-rfc2141bis-urn-00.txt has been successfully submitted by Alfred Hoenes and posted to the IETF repository. Filename: draft-ah-rfc2141bis-urn Revision: 00 Title: Uniform Resource Name (URN) Syntax Creation_date: 2010-03-24 WG ID: Independent Submission Number_of_pages: 18 Abstract: Uniform Resource Names (URNs) are intended to serve as persistent, location-independent, resource identifiers. This document serves as the foundation of the 'urn' URI Scheme according to RFC 3986 and sets forward the canonical syntax for URNs, which subdivides URNs into "namespaces". A discussion of both existing legacy and new namespaces and requirements for URN presentation and transmission are presented. Finally, there is a discussion of URN equivalence and how to determine it. This document supersedes RFC 2141. The requirements and procedures for URN Namespace registration documents are currently set forth in RFC 3406, which is also expected to be updated by an independent, revised specification soon. Discussion This draft version has been obtained by importing the text from RFC 2141 into modern tools and making a first round of updating steps. It is intended to serve as one of the starting points for an effort to bring URN RFCs in alignment with STD 63, STD 68, BCP 26, and the requirements from emerging distributed national and international URN resolution systems, and advance them on the IETF Standards Track. Until a more specific mailing list is established, comments are welcome on the uri-review@ietf.org mailing list (or sent to the document editor). The IETF Secretariat. ----- End of forwarded message from IETF I-D Submission Tool ----- From julian.reschke@gmx.de Tue Mar 30 08:54:08 2010 Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 125143A6C57 for ; Tue, 30 Mar 2010 08:54:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.805 X-Spam-Level: X-Spam-Status: No, score=-2.805 tagged_above=-999 required=5 tests=[AWL=-1.336, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IBrvwMX8WF0F for ; Tue, 30 Mar 2010 08:54:07 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id DF1AC3A6839 for ; Tue, 30 Mar 2010 08:54:06 -0700 (PDT) Received: (qmail invoked by alias); 30 Mar 2010 15:54:33 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.119]) [217.91.35.233] by mail.gmx.net (mp037) with SMTP; 30 Mar 2010 17:54:33 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/Y3pVErLzYesjIKr5ULkQp8ch1t0mOKhOIldMm6m gJZKFvvhn1/1hL Message-ID: <4BB21EB2.5060404@gmx.de> Date: Tue, 30 Mar 2010 17:54:26 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.4) Gecko/20060516 Thunderbird/1.5.0.4 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: HTTP Working Group Subject: Re: I-D Action:draft-reschke-rfc2231-in-http-11.txt References: <20100330154502.706A73A6BFC@core3.amsl.com> In-Reply-To: <20100330154502.706A73A6BFC@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.54000000000000004 Cc: IETF Apps Discuss X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 15:54:08 -0000 Hi, FYI: this draft (hopefully) resolves all issues reported during IETF Last Call (which ended 8 days ago). See diff at . Best regards, Julian On 30.03.2010 17:45, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Application of RFC 2231 Encoding to Hypertext Transfer Protocol (HTTP) Header Fields > Author(s) : J. Reschke > Filename : draft-reschke-rfc2231-in-http-11.txt > Pages : 18 > Date : 2010-03-30 > > By default, message header field parameters in Hypertext Transfer > Protocol (HTTP) messages can not carry characters outside the ISO- > 8859-1 character set. RFC 2231 defines an escaping mechanism for use > in Multipurpose Internet Mail Extensions (MIME) headers. This > document specifies a profile of that encoding suitable for use in > HTTP header fields. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-reschke-rfc2231-in-http-11.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. > > > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt