From nobody Wed Apr 1 04:11:04 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 302CA1A0387; Wed, 1 Apr 2015 04:11:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7RtQV8Z4tbbB; Wed, 1 Apr 2015 04:10:57 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 793161A040B; Wed, 1 Apr 2015 04:10:57 -0700 (PDT) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YdGXr-0007Rw-0F; Wed, 01 Apr 2015 07:10:51 -0400 Date: Wed, 01 Apr 2015 07:10:45 -0400 From: John C Klensin To: Alexey Melnikov , Graham Klyne , draft-ietf-appsawg-uri-scheme-reg.all@ietf.org Message-ID: <266EAB2393341CF1F491F327@JcK-HP8200.jck.com> In-Reply-To: <306B3AB5-02E3-4958-9D05-4E4FF82AD114@isode.com> References: <551AE31E.1070009@ninebynine.org> <306B3AB5-02E3-4958-9D05-4E4FF82AD114@isode.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: Barry Leiba , iesg@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] FW: New Version Notification - draft-ietf-appsawg-uri-scheme-reg-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 11:11:00 -0000 --On Wednesday, April 01, 2015 02:40 +0100 Alexey Melnikov wrote: >> Under the circumstances that a WG has achieved consensus to >> use a particular scheme, I think there's sufficient grounds >> to upgrade its registration to permanent. I think a request >> to do so should come from the WG concerned (I think that's >> doable within the current and new spec), and preferably as >> part of the IANA considerations for the spec that uses it. >> That would bring the issue to DE's attention with appropriate >> context. >> >> I don't think think this gives the DE any greater power of >> veto than they already have with respect to a WG consensus >> request to register a new permanent scheme. > > I would think slightly more comfortable if the document has a > paragraph discussing the above (pretty much using what you > said). > > But if others don't think this is an issue, I will let it go. I have read the above several times and am not sure what it means, so some clarification within the document is definitely in order. More important, I think _any_ situation in which a designated expert or other individual, especially one who is not Nomcom-designated, can override a consensus decision in a WG or equivalent is a fundamental violation of our principles and pushes at the boundaries of "openness and fairness". We shouldn't even be discussing such situations in term of how much "power of veto" the DE has. I believe the more appropriate model is to structure things so that, as soon as a WG or other recognized consensus-development process takes up something that would normatively define a scheme, the expert review becomes important advisory input to that process but nothing more. FWIW, one attempt at defining such a relationship and tying it to standardization appears in the current version of draft-ietf-urnbis-rfc2141bis-urn, Section 7.2. I continue to believe that some similar discussion and model should make it into draft-leiba-cotton-iana-5226bis, but that spec seems to have gotten stalled. john From nobody Wed Apr 1 04:11:05 2015 Return-Path: X-Original-To: expand-draft-ietf-appsawg-uri-scheme-reg.all@virtual.ietf.org Delivered-To: apps-discuss@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 5184D1A044D; Wed, 1 Apr 2015 04:11:00 -0700 (PDT) X-Original-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 302CA1A0387; Wed, 1 Apr 2015 04:11:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7RtQV8Z4tbbB; Wed, 1 Apr 2015 04:10:57 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 793161A040B; Wed, 1 Apr 2015 04:10:57 -0700 (PDT) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YdGXr-0007Rw-0F; Wed, 01 Apr 2015 07:10:51 -0400 Date: Wed, 01 Apr 2015 07:10:45 -0400 From: John C Klensin To: Alexey Melnikov , Graham Klyne , draft-ietf-appsawg-uri-scheme-reg.all@ietf.org Message-ID: <266EAB2393341CF1F491F327@JcK-HP8200.jck.com> In-Reply-To: <306B3AB5-02E3-4958-9D05-4E4FF82AD114@isode.com> References: <551AE31E.1070009@ninebynine.org> <306B3AB5-02E3-4958-9D05-4E4FF82AD114@isode.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Cc: Barry Leiba , iesg@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] FW: New Version Notification - draft-ietf-appsawg-uri-scheme-reg-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 11:11:00 -0000 --On Wednesday, April 01, 2015 02:40 +0100 Alexey Melnikov wrote: >> Under the circumstances that a WG has achieved consensus to >> use a particular scheme, I think there's sufficient grounds >> to upgrade its registration to permanent. I think a request >> to do so should come from the WG concerned (I think that's >> doable within the current and new spec), and preferably as >> part of the IANA considerations for the spec that uses it. >> That would bring the issue to DE's attention with appropriate >> context. >> >> I don't think think this gives the DE any greater power of >> veto than they already have with respect to a WG consensus >> request to register a new permanent scheme. > > I would think slightly more comfortable if the document has a > paragraph discussing the above (pretty much using what you > said). > > But if others don't think this is an issue, I will let it go. I have read the above several times and am not sure what it means, so some clarification within the document is definitely in order. More important, I think _any_ situation in which a designated expert or other individual, especially one who is not Nomcom-designated, can override a consensus decision in a WG or equivalent is a fundamental violation of our principles and pushes at the boundaries of "openness and fairness". We shouldn't even be discussing such situations in term of how much "power of veto" the DE has. I believe the more appropriate model is to structure things so that, as soon as a WG or other recognized consensus-development process takes up something that would normatively define a scheme, the expert review becomes important advisory input to that process but nothing more. FWIW, one attempt at defining such a relationship and tying it to standardization appears in the current version of draft-ietf-urnbis-rfc2141bis-urn, Section 7.2. I continue to believe that some similar discussion and model should make it into draft-leiba-cotton-iana-5226bis, but that spec seems to have gotten stalled. john From nobody Wed Apr 1 12:33:39 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0071A1A7C; Wed, 1 Apr 2015 12:33:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wTGmCz2H4nTD; Wed, 1 Apr 2015 12:33:25 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C45C91A8876; Wed, 1 Apr 2015 12:33:24 -0700 (PDT) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YdOOB-000Bz8-SO; Wed, 01 Apr 2015 15:33:23 -0400 Date: Wed, 01 Apr 2015 15:33:18 -0400 From: John C Klensin To: draft-ietf-appsawg-uri-scheme-reg.all@ietf.org, iesg@ietf.org, apps-discuss@ietf.org Message-ID: <2E49FA112B054FFAED69D8A1@JcK-HP8200.jck.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: [apps-discuss] Retroactive application of draft-ietf-appsawg-uri-scheme-reg - comprehensive review X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 19:33:31 -0000 Hi. I've been thinking more about Larry's claim [1] that draft-ietf-appsawg-uri-scheme-reg (referred to as "4395bis" below) constrains work going on in the URNBIS WG and, in particular, draft-ietf-urnbis-rfc2141bis-urn and have been studying both documents. This is not a late review in the usual sense. Under normal circumstances, I would consider a WG document to update a registration model to be routine and in good hands and reached precisely that conclusion about this specification after glancing through an early version. What has changed is the assertion that this document constrains the work of the URNBIS WG and actually invalidates decisions already made there. If true, that raises significant issues of a variety that, had they arisen after IESG approval, would properly have resulted in appeals. I think we should consider it fortunate that the issue has arisen before things reached IESG balloting. Some of Larry's comments involve substantive issues about URNs or decisions made in, or under consideration by, the URNBIS WG. I assume that they will be taken up in an ordinary way on that WG's list (a response from me to some of them can be expected soon although it seemed important to get these notes out first). However, the interactions between 4395bis and the URN work raise some fundamental questions about 4395bis that I hope can be resolved without either holding it up significantly or dropping it into a procedural quagmire. We have a situation in which two WGs (notably two WGs that are responsible to the same AD) are aware of each other's work and claims are made that the work conflicts or that one effort dominates the other. Certainly both the principles of openness and fairness that are called out repeatedly in RFC 2026 and our long-term practices suggest that the relevant documents should be considered at the same time and, as appropriate, be reviewed and achieve at least rough consensus in both WGs unless the conflicts can be eliminated in other ways. In particular, neither WG (or document authors) should be able to establish their document as controlling the other by creating a race condition. In this case, the following specific issues seem relevant to resolving, eliminating, or clarifying the claimed conflict about controlling text. (1) I note that there has been a title change between RFC 4395 ("Guidelines and Registration Procedures for New URI Schemes") and 4395bis ("Guidelines and Registration Procedures for URI Schemes") that the authors of the latter did not consider significant enough to note in their discussion of changes in Appendix A. The third paragraph of Section 1 begins "This document provides updated guidelines for the definition of new schemes..." and "new" is repeated at the beginning of Section 3 and at several other points in the document. I infer from that, as well as the above, that the change of title is not intended to be substantive and that, in particular, the procedures established or updated by this document do not alter or constrain any of (i) Procedures for updating established registrations (ii) The ability for a new registration to specify appropriate updating procedures for that scheme definition (iii) The ability for the authoritative entity for a particular already-registered scheme to change the rules for updating that scheme. When that scheme definition is part of an IETF standards-track document, the usual rules for updating standards-track documents apply. and that, (iv) As (probably) pointed out at the end of the second paragraph of the introduction, URN namespaces are not part of the scope of this document. As I read 4395bis, all of those statements seem clear to me. However, if Larry, especially in his capacity as a listed co-author of 4395bis, reads it in a different way, I think some clarification is probably necessary (and that, if there is no agreement that these are really clarifications, that the document should be returned to the WG): Clarification #1: Either restore "new" to the title and add it to the Abstract or insert an explicit statement in the Introduction that reflects the above, ideally all three. Clarification #2: Either clarify very precisely what "explicitly" means in the sentence 'URN "namespaces" ([RFC3406]) are specific to the "urn" scheme and are not covered explicitly by this specification.' (a sentence 4395bis appears to have incorporated without change from 4395) or drop "explicitly" from that sentence. (2) Section 3 of 4395bis cites the "overall syntax for URIs" from RFC 3986 and then says "A scheme definition cannot override the overall syntax for URIs. For example, this means that fragment identifiers cannot be re-used outside the generic syntax restrictions, and fragment identifiers are not scheme-specific." If we can agree that this is not applicable to existing registered scheme definitions or updates to them and that future URN-like schemes are unlikely, then that is a non-issue. If we cannot, the AppsAWG and IESG should be formally aware (the former has certainly been told about this in various area meetings) that the current consensus within URNBIS is to separate URNs from the semantic requirements of 3986 [2]. That position was the result of a difficult compromise in which the main alternative was to separate URNs entirely from what the WG believes are the many assumptions (most derived from locators) and some of the confusing language in 3986. The paragraph quoted above appears to be new to 4395bis, does not appear to be noted in the appendix that lists changes, and I wonder why it was felt to be necessary. Whether it is applicable to the "urn" scheme or not, the statement is factually false. The only constraint the "overall syntax for URIs" imposes on what 3986 calls a "fragment" is that it be preceded by "#", that it extend to the end of the URI, and that it obey the usual rules about permitted characters and character escaping. Statements about fragment identifiers being scheme-specific are _semantic_ restrictions and, absent a good deal of semantics, I can't even figure out what "fragment identifiers cannot be re-used outside the generic syntax restrictions" might mean. Clarification #3: Either explicitly exempt URNs (either by name or by "not applicable to existing registrations") or fix that paragraph to clarify the difference between syntax and semantic restrictions. In the interest of correctness and technical accuracy, a fix seems preferable to an exemption. The thing I think we should avoid (even though it would be easy from a textual standpoint) is having to put text in the URNBIS documents that updates 4395bis to remove this particular apparent requirement. If we have to have a battle over the applicability of that text, it seems to me that the time to do it is while both documents are still under consideration, i.e., now. (3) I observe that 4395bis appears to considerably increase and tighten the binding to 3986 relative to 4395, with the above being just one example. Those who have been watching developments closely are aware that there are multiple efforts in progress in different organizations that have the intent to revise or even supercede 3986. The IETF has not taken a strong position about those other efforts and there have apparently been AD-level discussions about ceding generic URI work to other bodies. Given that state of uncertainty and the IETF's presumed desire to avoid having changes in the status of 3986 drag this 4395bis specification into obsolescence, it would seem desirable to make this document and procedure less, rather than more, dependent on specific text and wording in 3986. Alternately, if the intent of those additional dependencies is to try to defend against internal or external alterations to 3986, I believe that should be handled up front rather than trying to use this registration specification as a back door. Clarification #4/ Recommendation: The authors or others should make a careful pass through this document, eliminating specific dependencies on 3986 where possible and clarifying the intent of what remains sufficiently to preserve the effectiveness of this specification should 3986 be superceded. If that is not feasible, the IANA Considerations section of this document should be clear about the status of the registration procedure (and the registry that it specifies) should the references on which the spec is normatively dependent be superceded (that would probably be a good idea for all registration specifications that are not self-contained, but it is important in this case because there appears to be a real possibility that documents that supercede 3986 will not be under IETF change control). (4) The second sentence of the first paragraph of Section 3.3 ("Well-defined") says: "Schemes that are not intended to be used as locators SHOULD describe how the resource identified can be determined or accessed by software that obtains a URI of that scheme." If this is intended to be applicable to URN or URN-like schemes that are used as what URNBIS has been calling "indicators", it is not clear what the requirement statement means. Requirement statements without clean meaning vis-a-vis all of the cases to which they might apply are undesirable and are indeed "technical deficiencies". Clarification #5: Either clarify the excluded cases implied by the "SHOULD" or explicitly exempt URNs and any similar schemes that might be developed or registered in the future. (5) The last paragraph of Section 3.3, much of it copied intact from RFC 4395, suggests a requirement that all "legal protocol interactions" of another protocol must be capable of being mapped into the URI and calls out "ftp" as an example. One significant change from 4395 (not noted in the Appendix that lists changes) is the transformation from an informal "must" suggestion about the mapping model to a normative "MUST". That "MUST" actually contradicts the final sentence of the paragraph which begins "If not all legal values or protocol interactions of the base standard can be represented..." This raises two issues. First, if 4395bis (especially its normative requirements) is to be applied retroactively to existing registrations, then the registration of the ftp scheme is now invalid (whether that last sentence is considered as a path to an exception or not). First, the discussion in RFC 1738, which is referenced as the definition of the scheme from the IANA registry, is not complete relative to the functionality of the FTP protocol as of the time RFC 1738 was written and does not explain the exceptions. It even says that it is incomplete with the rather magical sentence (in Section 3.2.2 of RFC 1738) that reads "The mechanism for doing so is not spelled out here." The IETF has also chosen to standardize a number of extensions to FTP (including, in these IPv6 and security-conscious days, RFCs 2428 and 4217) that have not been reflected in either the registration or in an update to RFC 1738. Second, even for new registrations, changing informal guidance that happens to use the word "must" to a normative absolute requirement (with "MUST") should require much more careful review and evaluation by the community than this change appears to have gotten (especially given the apparent contradiction it introduces). FWIW, I haven't done a careful review, but it is not clear to me that even the "http:" scheme, as reflected in the IANA registry, would be considered valid by the criteria in 4395bis given functionality changes introduced by HTTP2 and other relatively recent changes and extensions. I note, also FWIW, that Section 3.4 is much more balanced and reasoned and that it uses "SHOULD" consistently and not "MUST". Retroactive application of Section 3.7 ("Clear Security Considerations") would also invalidate a number of existing registrations. Clarification #6: This example, which has nothing to do with URNs or, unless the long-expired draft-hoffman-ftp-uri is considered, any other active URI-defining work in the IETF, points out another reason why it is important that this 4395bis document explicitly disclaim applicability to any already-registered scheme or updates to it except as the most general guidance and recommendations of issues to be considered. Clarification #7: The MUST in the cited paragraph should be, at most, a "SHOULD" or the paragraph should be reworded to correctly reflect realistic intent. Clarification #8/Recommendation: The list of Changes in Appendix A should be expanded to reflect all changes from general guidance (expressed in, e.g., "must" or "should") to normative requirements. Treating such changes as editorial corrections is appropriate only when the context clearly indicates normative intent and the changes do not introduce contradictions either within the text or to established practices. (6) URN work has made it clear that defining the scope of applicability of a URI scheme is, at best, a shared responsibility between whatever documentation defines the scheme and the documentation that defines the referencing context. Attempts to shift all of that responsibility to the scheme definition, as Section 3.5 can be interpreted to do, is unrealistic if only because the scheme definition cannot predict referencing contexts that might be defined or redefined in the future. Given that the current text uses a "SHOULD", it is probably ok, but a clarification that contexts that incorporate URI references also bear some responsibility for describing the schemes that are valid and meaningful (preferably on an inclusion basis) would be helpful to avoid outrageous claims in the future. Anyone contemplating a 4395ter might consider whether adding an "applicable application, protocol, or context" field to the IANA registry would be useful. Clarification #9: Add a sentence to Section 3.5 to clarify that its provisions do not eliminate the requirement for the applications and/or protocols from which URIs are used to discuss the schemes that are (or are not) relevant and appropriate for use in those contexts. (7) In my capacity as someone who is supposed to know a bit about i18n issues, I think I understand the intent that motivated the inclusion of the last paragraph of Section 3.6. However, after reading that paragraph several times, I am not sure what it actually means. If the term "variant" (which I would encourage authors to avoid) is interpreted in its ICANN usage or even as defined in Section 7.2 of RFC 6365, I am _sure_ I don't know what the paragraph means. Clarification #10: That paragraph needs to be rewritten and carefully checked by i18n experts. Encouraging the registration to make a clear statement about normalization and/or other comparison-related issues would probably be desirable. (8) Section 7.3 is not explicit that an updated registration can change the mechanism for future updates, nor that registrations, especially those associated with IETF documents, can specify update/change mechanisms different from those specified in this document. Had I been asked a month ago, I would have said that both were obvious and that further explanation was not required. Since recent discussions have called both into question, I think some clarification is needed. Clarification #11: Add text to Section 7.3 to make it explicit that scheme registrations MAY specify updating procedures that are more specific than those outlined in 4395bis, including identifying other approval mechanisms or responsible parties, and that scheme registration updates may modify the updating mechanism as well as other aspects of the registration. Clarification #12: In the template shown in Section 7.4, add to the "Change controller:" entry a statement equivalent to "Any special considerations about updating or updating procedures should also appear as part of this item." (9) Further evidence that this document is confused about existing registrations, retroactive application, and its own requirements appears in Section 8. The "example" URI scheme registration that is specified in that section does not appear to conform to the "fields that MUST be supplied" requirements of Section 7.4: there is no contact given and the "Change controller" field is identified as "Author/Change controller". If that flexibility was intended by Section 7.4, the document should say so. thanks, john [1] http://www.ietf.org/mail-archive/web/urn/current/msg02873.html [2] https://datatracker.ietf.org/doc/draft-ietf-urnbis-semantics-clarif/ From nobody Wed Apr 1 12:33:40 2015 Return-Path: X-Original-To: expand-draft-ietf-appsawg-uri-scheme-reg.all@virtual.ietf.org Delivered-To: apps-discuss@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 84AB01A8876; Wed, 1 Apr 2015 12:33:31 -0700 (PDT) X-Original-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0071A1A7C; Wed, 1 Apr 2015 12:33:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wTGmCz2H4nTD; Wed, 1 Apr 2015 12:33:25 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C45C91A8876; Wed, 1 Apr 2015 12:33:24 -0700 (PDT) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YdOOB-000Bz8-SO; Wed, 01 Apr 2015 15:33:23 -0400 Date: Wed, 01 Apr 2015 15:33:18 -0400 From: John C Klensin To: draft-ietf-appsawg-uri-scheme-reg.all@ietf.org, iesg@ietf.org, apps-discuss@ietf.org Message-ID: <2E49FA112B054FFAED69D8A1@JcK-HP8200.jck.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: [apps-discuss] Retroactive application of draft-ietf-appsawg-uri-scheme-reg - comprehensive review X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 19:33:31 -0000 Hi. I've been thinking more about Larry's claim [1] that draft-ietf-appsawg-uri-scheme-reg (referred to as "4395bis" below) constrains work going on in the URNBIS WG and, in particular, draft-ietf-urnbis-rfc2141bis-urn and have been studying both documents. This is not a late review in the usual sense. Under normal circumstances, I would consider a WG document to update a registration model to be routine and in good hands and reached precisely that conclusion about this specification after glancing through an early version. What has changed is the assertion that this document constrains the work of the URNBIS WG and actually invalidates decisions already made there. If true, that raises significant issues of a variety that, had they arisen after IESG approval, would properly have resulted in appeals. I think we should consider it fortunate that the issue has arisen before things reached IESG balloting. Some of Larry's comments involve substantive issues about URNs or decisions made in, or under consideration by, the URNBIS WG. I assume that they will be taken up in an ordinary way on that WG's list (a response from me to some of them can be expected soon although it seemed important to get these notes out first). However, the interactions between 4395bis and the URN work raise some fundamental questions about 4395bis that I hope can be resolved without either holding it up significantly or dropping it into a procedural quagmire. We have a situation in which two WGs (notably two WGs that are responsible to the same AD) are aware of each other's work and claims are made that the work conflicts or that one effort dominates the other. Certainly both the principles of openness and fairness that are called out repeatedly in RFC 2026 and our long-term practices suggest that the relevant documents should be considered at the same time and, as appropriate, be reviewed and achieve at least rough consensus in both WGs unless the conflicts can be eliminated in other ways. In particular, neither WG (or document authors) should be able to establish their document as controlling the other by creating a race condition. In this case, the following specific issues seem relevant to resolving, eliminating, or clarifying the claimed conflict about controlling text. (1) I note that there has been a title change between RFC 4395 ("Guidelines and Registration Procedures for New URI Schemes") and 4395bis ("Guidelines and Registration Procedures for URI Schemes") that the authors of the latter did not consider significant enough to note in their discussion of changes in Appendix A. The third paragraph of Section 1 begins "This document provides updated guidelines for the definition of new schemes..." and "new" is repeated at the beginning of Section 3 and at several other points in the document. I infer from that, as well as the above, that the change of title is not intended to be substantive and that, in particular, the procedures established or updated by this document do not alter or constrain any of (i) Procedures for updating established registrations (ii) The ability for a new registration to specify appropriate updating procedures for that scheme definition (iii) The ability for the authoritative entity for a particular already-registered scheme to change the rules for updating that scheme. When that scheme definition is part of an IETF standards-track document, the usual rules for updating standards-track documents apply. and that, (iv) As (probably) pointed out at the end of the second paragraph of the introduction, URN namespaces are not part of the scope of this document. As I read 4395bis, all of those statements seem clear to me. However, if Larry, especially in his capacity as a listed co-author of 4395bis, reads it in a different way, I think some clarification is probably necessary (and that, if there is no agreement that these are really clarifications, that the document should be returned to the WG): Clarification #1: Either restore "new" to the title and add it to the Abstract or insert an explicit statement in the Introduction that reflects the above, ideally all three. Clarification #2: Either clarify very precisely what "explicitly" means in the sentence 'URN "namespaces" ([RFC3406]) are specific to the "urn" scheme and are not covered explicitly by this specification.' (a sentence 4395bis appears to have incorporated without change from 4395) or drop "explicitly" from that sentence. (2) Section 3 of 4395bis cites the "overall syntax for URIs" from RFC 3986 and then says "A scheme definition cannot override the overall syntax for URIs. For example, this means that fragment identifiers cannot be re-used outside the generic syntax restrictions, and fragment identifiers are not scheme-specific." If we can agree that this is not applicable to existing registered scheme definitions or updates to them and that future URN-like schemes are unlikely, then that is a non-issue. If we cannot, the AppsAWG and IESG should be formally aware (the former has certainly been told about this in various area meetings) that the current consensus within URNBIS is to separate URNs from the semantic requirements of 3986 [2]. That position was the result of a difficult compromise in which the main alternative was to separate URNs entirely from what the WG believes are the many assumptions (most derived from locators) and some of the confusing language in 3986. The paragraph quoted above appears to be new to 4395bis, does not appear to be noted in the appendix that lists changes, and I wonder why it was felt to be necessary. Whether it is applicable to the "urn" scheme or not, the statement is factually false. The only constraint the "overall syntax for URIs" imposes on what 3986 calls a "fragment" is that it be preceded by "#", that it extend to the end of the URI, and that it obey the usual rules about permitted characters and character escaping. Statements about fragment identifiers being scheme-specific are _semantic_ restrictions and, absent a good deal of semantics, I can't even figure out what "fragment identifiers cannot be re-used outside the generic syntax restrictions" might mean. Clarification #3: Either explicitly exempt URNs (either by name or by "not applicable to existing registrations") or fix that paragraph to clarify the difference between syntax and semantic restrictions. In the interest of correctness and technical accuracy, a fix seems preferable to an exemption. The thing I think we should avoid (even though it would be easy from a textual standpoint) is having to put text in the URNBIS documents that updates 4395bis to remove this particular apparent requirement. If we have to have a battle over the applicability of that text, it seems to me that the time to do it is while both documents are still under consideration, i.e., now. (3) I observe that 4395bis appears to considerably increase and tighten the binding to 3986 relative to 4395, with the above being just one example. Those who have been watching developments closely are aware that there are multiple efforts in progress in different organizations that have the intent to revise or even supercede 3986. The IETF has not taken a strong position about those other efforts and there have apparently been AD-level discussions about ceding generic URI work to other bodies. Given that state of uncertainty and the IETF's presumed desire to avoid having changes in the status of 3986 drag this 4395bis specification into obsolescence, it would seem desirable to make this document and procedure less, rather than more, dependent on specific text and wording in 3986. Alternately, if the intent of those additional dependencies is to try to defend against internal or external alterations to 3986, I believe that should be handled up front rather than trying to use this registration specification as a back door. Clarification #4/ Recommendation: The authors or others should make a careful pass through this document, eliminating specific dependencies on 3986 where possible and clarifying the intent of what remains sufficiently to preserve the effectiveness of this specification should 3986 be superceded. If that is not feasible, the IANA Considerations section of this document should be clear about the status of the registration procedure (and the registry that it specifies) should the references on which the spec is normatively dependent be superceded (that would probably be a good idea for all registration specifications that are not self-contained, but it is important in this case because there appears to be a real possibility that documents that supercede 3986 will not be under IETF change control). (4) The second sentence of the first paragraph of Section 3.3 ("Well-defined") says: "Schemes that are not intended to be used as locators SHOULD describe how the resource identified can be determined or accessed by software that obtains a URI of that scheme." If this is intended to be applicable to URN or URN-like schemes that are used as what URNBIS has been calling "indicators", it is not clear what the requirement statement means. Requirement statements without clean meaning vis-a-vis all of the cases to which they might apply are undesirable and are indeed "technical deficiencies". Clarification #5: Either clarify the excluded cases implied by the "SHOULD" or explicitly exempt URNs and any similar schemes that might be developed or registered in the future. (5) The last paragraph of Section 3.3, much of it copied intact from RFC 4395, suggests a requirement that all "legal protocol interactions" of another protocol must be capable of being mapped into the URI and calls out "ftp" as an example. One significant change from 4395 (not noted in the Appendix that lists changes) is the transformation from an informal "must" suggestion about the mapping model to a normative "MUST". That "MUST" actually contradicts the final sentence of the paragraph which begins "If not all legal values or protocol interactions of the base standard can be represented..." This raises two issues. First, if 4395bis (especially its normative requirements) is to be applied retroactively to existing registrations, then the registration of the ftp scheme is now invalid (whether that last sentence is considered as a path to an exception or not). First, the discussion in RFC 1738, which is referenced as the definition of the scheme from the IANA registry, is not complete relative to the functionality of the FTP protocol as of the time RFC 1738 was written and does not explain the exceptions. It even says that it is incomplete with the rather magical sentence (in Section 3.2.2 of RFC 1738) that reads "The mechanism for doing so is not spelled out here." The IETF has also chosen to standardize a number of extensions to FTP (including, in these IPv6 and security-conscious days, RFCs 2428 and 4217) that have not been reflected in either the registration or in an update to RFC 1738. Second, even for new registrations, changing informal guidance that happens to use the word "must" to a normative absolute requirement (with "MUST") should require much more careful review and evaluation by the community than this change appears to have gotten (especially given the apparent contradiction it introduces). FWIW, I haven't done a careful review, but it is not clear to me that even the "http:" scheme, as reflected in the IANA registry, would be considered valid by the criteria in 4395bis given functionality changes introduced by HTTP2 and other relatively recent changes and extensions. I note, also FWIW, that Section 3.4 is much more balanced and reasoned and that it uses "SHOULD" consistently and not "MUST". Retroactive application of Section 3.7 ("Clear Security Considerations") would also invalidate a number of existing registrations. Clarification #6: This example, which has nothing to do with URNs or, unless the long-expired draft-hoffman-ftp-uri is considered, any other active URI-defining work in the IETF, points out another reason why it is important that this 4395bis document explicitly disclaim applicability to any already-registered scheme or updates to it except as the most general guidance and recommendations of issues to be considered. Clarification #7: The MUST in the cited paragraph should be, at most, a "SHOULD" or the paragraph should be reworded to correctly reflect realistic intent. Clarification #8/Recommendation: The list of Changes in Appendix A should be expanded to reflect all changes from general guidance (expressed in, e.g., "must" or "should") to normative requirements. Treating such changes as editorial corrections is appropriate only when the context clearly indicates normative intent and the changes do not introduce contradictions either within the text or to established practices. (6) URN work has made it clear that defining the scope of applicability of a URI scheme is, at best, a shared responsibility between whatever documentation defines the scheme and the documentation that defines the referencing context. Attempts to shift all of that responsibility to the scheme definition, as Section 3.5 can be interpreted to do, is unrealistic if only because the scheme definition cannot predict referencing contexts that might be defined or redefined in the future. Given that the current text uses a "SHOULD", it is probably ok, but a clarification that contexts that incorporate URI references also bear some responsibility for describing the schemes that are valid and meaningful (preferably on an inclusion basis) would be helpful to avoid outrageous claims in the future. Anyone contemplating a 4395ter might consider whether adding an "applicable application, protocol, or context" field to the IANA registry would be useful. Clarification #9: Add a sentence to Section 3.5 to clarify that its provisions do not eliminate the requirement for the applications and/or protocols from which URIs are used to discuss the schemes that are (or are not) relevant and appropriate for use in those contexts. (7) In my capacity as someone who is supposed to know a bit about i18n issues, I think I understand the intent that motivated the inclusion of the last paragraph of Section 3.6. However, after reading that paragraph several times, I am not sure what it actually means. If the term "variant" (which I would encourage authors to avoid) is interpreted in its ICANN usage or even as defined in Section 7.2 of RFC 6365, I am _sure_ I don't know what the paragraph means. Clarification #10: That paragraph needs to be rewritten and carefully checked by i18n experts. Encouraging the registration to make a clear statement about normalization and/or other comparison-related issues would probably be desirable. (8) Section 7.3 is not explicit that an updated registration can change the mechanism for future updates, nor that registrations, especially those associated with IETF documents, can specify update/change mechanisms different from those specified in this document. Had I been asked a month ago, I would have said that both were obvious and that further explanation was not required. Since recent discussions have called both into question, I think some clarification is needed. Clarification #11: Add text to Section 7.3 to make it explicit that scheme registrations MAY specify updating procedures that are more specific than those outlined in 4395bis, including identifying other approval mechanisms or responsible parties, and that scheme registration updates may modify the updating mechanism as well as other aspects of the registration. Clarification #12: In the template shown in Section 7.4, add to the "Change controller:" entry a statement equivalent to "Any special considerations about updating or updating procedures should also appear as part of this item." (9) Further evidence that this document is confused about existing registrations, retroactive application, and its own requirements appears in Section 8. The "example" URI scheme registration that is specified in that section does not appear to conform to the "fields that MUST be supplied" requirements of Section 7.4: there is no contact given and the "Change controller" field is identified as "Author/Change controller". If that flexibility was intended by Section 7.4, the document should say so. thanks, john [1] http://www.ietf.org/mail-archive/web/urn/current/msg02873.html [2] https://datatracker.ietf.org/doc/draft-ietf-urnbis-semantics-clarif/ From nobody Thu Apr 2 02:30:56 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9BDB1B2C20; Thu, 2 Apr 2015 02:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DCsde7yucg-D; Thu, 2 Apr 2015 02:30:49 -0700 (PDT) Received: from relay11.mail.ox.ac.uk (relay11.mail.ox.ac.uk [129.67.1.162]) by ietfa.amsl.com (Postfix) with ESMTP id 6EF2A1B2C23; Thu, 2 Apr 2015 02:30:49 -0700 (PDT) Received: from smtp5.mail.ox.ac.uk ([163.1.2.207]) by relay11.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1YdbSX-0005s1-bo; Thu, 02 Apr 2015 10:30:45 +0100 Received: from host109-152-232-46.range109-152.btcentralplus.com ([109.152.232.46] helo=cheery.atuin.ninebynine.org) by smtp5.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YdbSX-00064q-Hu; Thu, 02 Apr 2015 10:30:45 +0100 Message-ID: <551D0C47.5090603@ninebynine.org> Date: Thu, 02 Apr 2015 10:30:47 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: John C Klensin , Alexey Melnikov , draft-ietf-appsawg-uri-scheme-reg.all@ietf.org References: <551AE31E.1070009@ninebynine.org> <306B3AB5-02E3-4958-9D05-4E4FF82AD114@isode.com> <266EAB2393341CF1F491F327@JcK-HP8200.jck.com> In-Reply-To: <266EAB2393341CF1F491F327@JcK-HP8200.jck.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: Cc: Barry Leiba , Graham Klyne , iesg@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] FW: New Version Notification - draft-ietf-appsawg-uri-scheme-reg-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 02 Apr 2015 09:30:52 -0000 On 01/04/2015 12:10, John C Klensin wrote: >>> Under the circumstances that a WG has achieved consensus to >>> use a particular scheme, I think there's sufficient grounds >>> to upgrade its registration to permanent. I think a request >>> to do so should come from the WG concerned (I think that's >>> doable within the current and new spec), and preferably as >>> part of the IANA considerations for the spec that uses it. >>> That would bring the issue to DE's attention with appropriate >>> context. >>> >>> I don't think think this gives the DE any greater power of >>> veto than they already have with respect to a WG consensus >>> request to register a new permanent scheme. >> >> I would think slightly more comfortable if the document has a >> paragraph discussing the above (pretty much using what you >> said). >> >> But if others don't think this is an issue, I will let it go. > > I have read the above several times and am not sure what it > means, so some clarification within the document is definitely > in order. > > More important, I think _any_ situation in which a designated > expert or other individual, especially one who is not > Nomcom-designated, can override a consensus decision in a WG or > equivalent is a fundamental violation of our principles and > pushes at the boundaries of "openness and fairness". I agree, and my use of the phrase "power of veto" may have been ill-judged; I was trying to say that I don't think such exists ;) From memory, the revised procedure (and maybe the current) already have it that a DE decision can be overruled by the IESG, who (I would judge) are ultimately the guardians of the IETF consensus process. So I think the DE cannot override the consensus process. But I would be happy for this to be clarified. For example, in section 7.1 (http://tools.ietf.org/html/draft-ietf-appsawg-uri-scheme-reg-05#section-7.1), maybe add something like this: "The role of the designated expert in the procedure for permanent registrations described here is to ensure that normal IETF open review process has been properly followed, and to raise possible concerns about wider implications of proposals for the use and deployment of URIs. Nothing in the procedure empowers the Designated Expert to override properly arrived-at IETF or working group consensus." > ... We > shouldn't even be discussing such situations in term of how much > "power of veto" the DE has. I believe the more appropriate > model is to structure things so that, as soon as a WG or other > recognized consensus-development process takes up something that > would normatively define a scheme, the expert review becomes > important advisory input to that process but nothing more. In practice, my comments tend to be early input to the last-call process, and I think it would be fine in principle for that to be made explicit. But there are also circumstances where the role of the DE to approve permanent registration of something that has NOT been through the IETF consensus process - I think we'd need to be careful not to disrupt that aspect of the process. > > FWIW, one attempt at defining such a relationship and tying it > to standardization appears in the current version of > draft-ietf-urnbis-rfc2141bis-urn, Section 7.2. I continue to > believe that some similar discussion and model should make it > into draft-leiba-cotton-iana-5226bis, but that spec seems to > have gotten stalled. You mean https://tools.ietf.org/html/draft-ietf-urnbis-rfc2141bis-urn-11#section-7.2 ? I'm seeing: "For namespaces or their definitions that are intended to become standards or normative components of standards, the output of the Expert Review process is intended to be a report, rather than instructions to IANA to take action (see below)." and "If standardization is anticipated, the designated experts will prepare a report and forward it to the appropriate standards approval body (the IESG in the case of the IETF) and IANA will register the requested NID only after receiving directions from that body and a copy of the expert review report." I'm OK with this in principle but have a couple of possible concerns: 1. "prepare a report" starts to sound a bit heavyweight. If we can be clear that a "report" may be a short email at the level of "this is fine" or "I have concerns with and " then it's OK. But if you envisage something more formal then that could (from my perspective) seriously impair my ability to perform the DE role. 2. I am not sure that it is appropriate for the IETF to have a procedure that requires us to become formally involved in the machinations of external standards bodies. We already have and recommend submissions to the URI-review list, and the registration procedures already operate to promote dialog with external bodies (or individuals) who wish to make permanent registrations, so I'm unconvinced that greater formality is needed vis-a-vis interaction with external standards bodies. What I might do is suggest that external standards bodies make initial registration requests early/ier in their process so that they can receive and respond to feedback while there is still scope to do so within the constraints of their process. For example, to submit a permanent registration request early on the understanding that it may initially be accepted provisionally, and upgraded to permanent as and when any concerns raised are resolved (including progression to the appropriate status by the requesting organization). #g -- From nobody Thu Apr 2 02:30:57 2015 Return-Path: X-Original-To: expand-draft-ietf-appsawg-uri-scheme-reg.all@virtual.ietf.org Delivered-To: apps-discuss@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 058611B2C24; Thu, 2 Apr 2015 02:30:51 -0700 (PDT) X-Original-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9BDB1B2C20; Thu, 2 Apr 2015 02:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DCsde7yucg-D; Thu, 2 Apr 2015 02:30:49 -0700 (PDT) Received: from relay11.mail.ox.ac.uk (relay11.mail.ox.ac.uk [129.67.1.162]) by ietfa.amsl.com (Postfix) with ESMTP id 6EF2A1B2C23; Thu, 2 Apr 2015 02:30:49 -0700 (PDT) Received: from smtp5.mail.ox.ac.uk ([163.1.2.207]) by relay11.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1YdbSX-0005s1-bo; Thu, 02 Apr 2015 10:30:45 +0100 Received: from host109-152-232-46.range109-152.btcentralplus.com ([109.152.232.46] helo=cheery.atuin.ninebynine.org) by smtp5.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YdbSX-00064q-Hu; Thu, 02 Apr 2015 10:30:45 +0100 Message-ID: <551D0C47.5090603@ninebynine.org> Date: Thu, 02 Apr 2015 10:30:47 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: John C Klensin , Alexey Melnikov , draft-ietf-appsawg-uri-scheme-reg.all@ietf.org References: <551AE31E.1070009@ninebynine.org> <306B3AB5-02E3-4958-9D05-4E4FF82AD114@isode.com> <266EAB2393341CF1F491F327@JcK-HP8200.jck.com> In-Reply-To: <266EAB2393341CF1F491F327@JcK-HP8200.jck.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: Cc: Barry Leiba , Graham Klyne , iesg@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] FW: New Version Notification - draft-ietf-appsawg-uri-scheme-reg-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 02 Apr 2015 09:30:52 -0000 On 01/04/2015 12:10, John C Klensin wrote: >>> Under the circumstances that a WG has achieved consensus to >>> use a particular scheme, I think there's sufficient grounds >>> to upgrade its registration to permanent. I think a request >>> to do so should come from the WG concerned (I think that's >>> doable within the current and new spec), and preferably as >>> part of the IANA considerations for the spec that uses it. >>> That would bring the issue to DE's attention with appropriate >>> context. >>> >>> I don't think think this gives the DE any greater power of >>> veto than they already have with respect to a WG consensus >>> request to register a new permanent scheme. >> >> I would think slightly more comfortable if the document has a >> paragraph discussing the above (pretty much using what you >> said). >> >> But if others don't think this is an issue, I will let it go. > > I have read the above several times and am not sure what it > means, so some clarification within the document is definitely > in order. > > More important, I think _any_ situation in which a designated > expert or other individual, especially one who is not > Nomcom-designated, can override a consensus decision in a WG or > equivalent is a fundamental violation of our principles and > pushes at the boundaries of "openness and fairness". I agree, and my use of the phrase "power of veto" may have been ill-judged; I was trying to say that I don't think such exists ;) From memory, the revised procedure (and maybe the current) already have it that a DE decision can be overruled by the IESG, who (I would judge) are ultimately the guardians of the IETF consensus process. So I think the DE cannot override the consensus process. But I would be happy for this to be clarified. For example, in section 7.1 (http://tools.ietf.org/html/draft-ietf-appsawg-uri-scheme-reg-05#section-7.1), maybe add something like this: "The role of the designated expert in the procedure for permanent registrations described here is to ensure that normal IETF open review process has been properly followed, and to raise possible concerns about wider implications of proposals for the use and deployment of URIs. Nothing in the procedure empowers the Designated Expert to override properly arrived-at IETF or working group consensus." > ... We > shouldn't even be discussing such situations in term of how much > "power of veto" the DE has. I believe the more appropriate > model is to structure things so that, as soon as a WG or other > recognized consensus-development process takes up something that > would normatively define a scheme, the expert review becomes > important advisory input to that process but nothing more. In practice, my comments tend to be early input to the last-call process, and I think it would be fine in principle for that to be made explicit. But there are also circumstances where the role of the DE to approve permanent registration of something that has NOT been through the IETF consensus process - I think we'd need to be careful not to disrupt that aspect of the process. > > FWIW, one attempt at defining such a relationship and tying it > to standardization appears in the current version of > draft-ietf-urnbis-rfc2141bis-urn, Section 7.2. I continue to > believe that some similar discussion and model should make it > into draft-leiba-cotton-iana-5226bis, but that spec seems to > have gotten stalled. You mean https://tools.ietf.org/html/draft-ietf-urnbis-rfc2141bis-urn-11#section-7.2 ? I'm seeing: "For namespaces or their definitions that are intended to become standards or normative components of standards, the output of the Expert Review process is intended to be a report, rather than instructions to IANA to take action (see below)." and "If standardization is anticipated, the designated experts will prepare a report and forward it to the appropriate standards approval body (the IESG in the case of the IETF) and IANA will register the requested NID only after receiving directions from that body and a copy of the expert review report." I'm OK with this in principle but have a couple of possible concerns: 1. "prepare a report" starts to sound a bit heavyweight. If we can be clear that a "report" may be a short email at the level of "this is fine" or "I have concerns with and " then it's OK. But if you envisage something more formal then that could (from my perspective) seriously impair my ability to perform the DE role. 2. I am not sure that it is appropriate for the IETF to have a procedure that requires us to become formally involved in the machinations of external standards bodies. We already have and recommend submissions to the URI-review list, and the registration procedures already operate to promote dialog with external bodies (or individuals) who wish to make permanent registrations, so I'm unconvinced that greater formality is needed vis-a-vis interaction with external standards bodies. What I might do is suggest that external standards bodies make initial registration requests early/ier in their process so that they can receive and respond to feedback while there is still scope to do so within the constraints of their process. For example, to submit a permanent registration request early on the understanding that it may initially be accepted provisionally, and upgraded to permanent as and when any concerns raised are resolved (including progression to the appropriate status by the requesting organization). #g -- From nobody Thu Apr 2 02:43:10 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE91B1A8BB7; Thu, 2 Apr 2015 02:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pv7qZzLA-UtO; Thu, 2 Apr 2015 02:43:04 -0700 (PDT) Received: from relay16.mail.ox.ac.uk (relay16.mail.ox.ac.uk [163.1.2.166]) by ietfa.amsl.com (Postfix) with ESMTP id 2B2211A0338; Thu, 2 Apr 2015 02:43:04 -0700 (PDT) Received: from smtp4.mail.ox.ac.uk ([129.67.1.207]) by relay16.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1YdbeO-0002dT-px; Thu, 02 Apr 2015 10:43:00 +0100 Received: from host109-152-232-46.range109-152.btcentralplus.com ([109.152.232.46] helo=cheery.atuin.ninebynine.org) by smtp4.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YdbeN-0005oS-G4; Thu, 02 Apr 2015 10:43:00 +0100 Message-ID: <551D0F27.9030201@ninebynine.org> Date: Thu, 02 Apr 2015 10:43:03 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: John C Klensin , draft-ietf-appsawg-uri-scheme-reg.all@ietf.org, iesg@ietf.org, apps-discuss@ietf.org References: <2E49FA112B054FFAED69D8A1@JcK-HP8200.jck.com> In-Reply-To: <2E49FA112B054FFAED69D8A1@JcK-HP8200.jck.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: Cc: Graham Klyne Subject: Re: [apps-discuss] Retroactive application of draft-ietf-appsawg-uri-scheme-reg - comprehensive review X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 02 Apr 2015 09:43:06 -0000 On 01/04/2015 20:33, John C Klensin wrote: > (2) Section 3 of 4395bis cites the "overall syntax for URIs" > from RFC 3986 and then says > > "A scheme definition cannot override the overall syntax > for URIs. For example, this means that fragment > identifiers cannot be re-used outside the generic syntax > restrictions, and fragment identifiers are not > scheme-specific." > > If we can agree that this is not applicable to existing > registered scheme definitions or updates to them and that future > URN-like schemes are unlikely, then that is a non-issue. If we > cannot, the AppsAWG and IESG should be formally aware (the > former has certainly been told about this in various area > meetings) that the current consensus within URNBIS is to > separate URNs from the semantic requirements of 3986 [2]. That > position was the result of a difficult compromise in which the > main alternative was to separate URNs entirely from what the WG > believes are the many assumptions (most derived from locators) > and some of the confusing language in 3986. Procedural matters aside, I think this is an important clarification, and that urn: URIs SHOULD be constrained by this. This is not about existing and new URI schemes, but about what is required to be a a valid URI. My reason is that there is software out there that is written to accept *anything* that is a valid URI, and legitimately expect such strings to confirm to RFC3986 syntax (not withstanding Sam Ruby's efforts to document variations between systems about what they accept as a valid URI). If URNs are to be usable as URIs in such circumstances, I think it's important that they follow the rules, including those concerning the role of fragment identifiers. Procedurally, the URN working group might decide that URNs are not URIs, and hence be released from adhering to URI constraints, but that would be most unfortunate in that a possibly-important class of identifiers would be excluded from use by an important class of applications. #g -- > > The paragraph quoted above appears to be new to 4395bis, does > not appear to be noted in the appendix that lists changes, and I > wonder why it was felt to be necessary. Whether it is > applicable to the "urn" scheme or not, the statement is > factually false. The only constraint the "overall syntax for > URIs" imposes on what 3986 calls a "fragment" is that it be > preceded by "#", that it extend to the end of the URI, and that > it obey the usual rules about permitted characters and character > escaping. Statements about fragment identifiers being > scheme-specific are_semantic_ restrictions and, absent a good > deal of semantics, I can't even figure out what "fragment > identifiers cannot be re-used outside the generic syntax > restrictions" might mean. From nobody Thu Apr 2 02:43:11 2015 Return-Path: X-Original-To: expand-draft-ietf-appsawg-uri-scheme-reg.all@virtual.ietf.org Delivered-To: apps-discuss@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 193A51B2C29; Thu, 2 Apr 2015 02:43:06 -0700 (PDT) X-Original-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE91B1A8BB7; Thu, 2 Apr 2015 02:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pv7qZzLA-UtO; Thu, 2 Apr 2015 02:43:04 -0700 (PDT) Received: from relay16.mail.ox.ac.uk (relay16.mail.ox.ac.uk [163.1.2.166]) by ietfa.amsl.com (Postfix) with ESMTP id 2B2211A0338; Thu, 2 Apr 2015 02:43:04 -0700 (PDT) Received: from smtp4.mail.ox.ac.uk ([129.67.1.207]) by relay16.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1YdbeO-0002dT-px; Thu, 02 Apr 2015 10:43:00 +0100 Received: from host109-152-232-46.range109-152.btcentralplus.com ([109.152.232.46] helo=cheery.atuin.ninebynine.org) by smtp4.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YdbeN-0005oS-G4; Thu, 02 Apr 2015 10:43:00 +0100 Message-ID: <551D0F27.9030201@ninebynine.org> Date: Thu, 02 Apr 2015 10:43:03 +0100 From: Graham Klyne User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: John C Klensin , draft-ietf-appsawg-uri-scheme-reg.all@ietf.org, iesg@ietf.org, apps-discuss@ietf.org References: <2E49FA112B054FFAED69D8A1@JcK-HP8200.jck.com> In-Reply-To: <2E49FA112B054FFAED69D8A1@JcK-HP8200.jck.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: Cc: Graham Klyne Subject: Re: [apps-discuss] Retroactive application of draft-ietf-appsawg-uri-scheme-reg - comprehensive review X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 02 Apr 2015 09:43:06 -0000 On 01/04/2015 20:33, John C Klensin wrote: > (2) Section 3 of 4395bis cites the "overall syntax for URIs" > from RFC 3986 and then says > > "A scheme definition cannot override the overall syntax > for URIs. For example, this means that fragment > identifiers cannot be re-used outside the generic syntax > restrictions, and fragment identifiers are not > scheme-specific." > > If we can agree that this is not applicable to existing > registered scheme definitions or updates to them and that future > URN-like schemes are unlikely, then that is a non-issue. If we > cannot, the AppsAWG and IESG should be formally aware (the > former has certainly been told about this in various area > meetings) that the current consensus within URNBIS is to > separate URNs from the semantic requirements of 3986 [2]. That > position was the result of a difficult compromise in which the > main alternative was to separate URNs entirely from what the WG > believes are the many assumptions (most derived from locators) > and some of the confusing language in 3986. Procedural matters aside, I think this is an important clarification, and that urn: URIs SHOULD be constrained by this. This is not about existing and new URI schemes, but about what is required to be a a valid URI. My reason is that there is software out there that is written to accept *anything* that is a valid URI, and legitimately expect such strings to confirm to RFC3986 syntax (not withstanding Sam Ruby's efforts to document variations between systems about what they accept as a valid URI). If URNs are to be usable as URIs in such circumstances, I think it's important that they follow the rules, including those concerning the role of fragment identifiers. Procedurally, the URN working group might decide that URNs are not URIs, and hence be released from adhering to URI constraints, but that would be most unfortunate in that a possibly-important class of identifiers would be excluded from use by an important class of applications. #g -- > > The paragraph quoted above appears to be new to 4395bis, does > not appear to be noted in the appendix that lists changes, and I > wonder why it was felt to be necessary. Whether it is > applicable to the "urn" scheme or not, the statement is > factually false. The only constraint the "overall syntax for > URIs" imposes on what 3986 calls a "fragment" is that it be > preceded by "#", that it extend to the end of the URI, and that > it obey the usual rules about permitted characters and character > escaping. Statements about fragment identifiers being > scheme-specific are_semantic_ restrictions and, absent a good > deal of semantics, I can't even figure out what "fragment > identifiers cannot be re-used outside the generic syntax > restrictions" might mean. From nobody Thu Apr 2 06:09:25 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C88981A8A66; Thu, 2 Apr 2015 06:09:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OPhvfBuPM0pw; Thu, 2 Apr 2015 06:09:21 -0700 (PDT) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82E661A8025; Thu, 2 Apr 2015 06:08:28 -0700 (PDT) Received: by ignm3 with SMTP id m3so49025092ign.0; Thu, 02 Apr 2015 06:08:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=9dNs8p+j34iVL436DAduc+2/XOtG4I7Xl5TdhD3MHsw=; b=m4XRd0sPOsGcGOJOmJ0EtZUwyc6oYGgnwcebYBvSR2j5r9K7ykKZZDa7IOeaWrz9y0 3RoVVAa5EUx+7Am1fjGvk3jRr2VCyoNsG/Ob4DOouyQq4bkJhFct0CJnJZ1zNVOPWsaL R3R7CsSj0TVl9mG9jrp234OWyiid1KPZFH703pAN1EmdawSKWtEBrHUfIfdSsRIizkOR lKlRiyr2E1t1FxP/7+0khmgtVxpESgPb7Q+QjW59tnonisA7Cc+Yyr3urVRh77NKosb6 le7RXf9KDlNv1y7e9wgC1zmxnJjYWy6I36kvV5pvaC+xpebgA2d+pmcWpdf4TrjCI/x1 AbtA== MIME-Version: 1.0 X-Received: by 10.42.119.202 with SMTP id c10mr80293603icr.4.1427980108062; Thu, 02 Apr 2015 06:08:28 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.107.7.130 with HTTP; Thu, 2 Apr 2015 06:08:28 -0700 (PDT) In-Reply-To: <551D0F27.9030201@ninebynine.org> References: <2E49FA112B054FFAED69D8A1@JcK-HP8200.jck.com> <551D0F27.9030201@ninebynine.org> Date: Thu, 2 Apr 2015 09:08:28 -0400 X-Google-Sender-Auth: v92JZZ_9gye1H3cibNeIF-Y3loc Message-ID: From: Barry Leiba To: Graham Klyne Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Cc: "draft-ietf-appsawg-uri-scheme-reg.all@ietf.org" , IESG , Apps Discuss Subject: Re: [apps-discuss] Retroactive application of draft-ietf-appsawg-uri-scheme-reg - comprehensive review X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 02 Apr 2015 13:09:22 -0000 Just to one point: > My reason is that there is software out there that is written to accept > *anything* that is a valid URI, and legitimately expect such strings to > confirm to RFC3986 syntax (not withstanding Sam Ruby's efforts to document > variations between systems about what they accept as a valid URI). Absolutely. And the URNbis document maintains that, but keeping URNs syntactically URIs. > If URNs > are to be usable as URIs in such circumstances, I think it's important that > they follow the rules, including those concerning the role of fragment > identifiers. Here's where I don't agree. If URN fragments (f-components, or friggle-fraggles... the bit after the "#") are semantically somewhat different to what 3986 says about fragments in locators, because that's what semantically makes sense for URNs, why does that stop anyone from continuing to use them in places where URIs are syntactically required? Barry From nobody Thu Apr 2 06:09:27 2015 Return-Path: X-Original-To: expand-draft-ietf-appsawg-uri-scheme-reg.all@virtual.ietf.org Delivered-To: apps-discuss@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id E827B1ABC75; Thu, 2 Apr 2015 06:09:21 -0700 (PDT) X-Original-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C88981A8A66; Thu, 2 Apr 2015 06:09:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OPhvfBuPM0pw; Thu, 2 Apr 2015 06:09:21 -0700 (PDT) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82E661A8025; Thu, 2 Apr 2015 06:08:28 -0700 (PDT) Received: by ignm3 with SMTP id m3so49025092ign.0; Thu, 02 Apr 2015 06:08:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=9dNs8p+j34iVL436DAduc+2/XOtG4I7Xl5TdhD3MHsw=; b=m4XRd0sPOsGcGOJOmJ0EtZUwyc6oYGgnwcebYBvSR2j5r9K7ykKZZDa7IOeaWrz9y0 3RoVVAa5EUx+7Am1fjGvk3jRr2VCyoNsG/Ob4DOouyQq4bkJhFct0CJnJZ1zNVOPWsaL R3R7CsSj0TVl9mG9jrp234OWyiid1KPZFH703pAN1EmdawSKWtEBrHUfIfdSsRIizkOR lKlRiyr2E1t1FxP/7+0khmgtVxpESgPb7Q+QjW59tnonisA7Cc+Yyr3urVRh77NKosb6 le7RXf9KDlNv1y7e9wgC1zmxnJjYWy6I36kvV5pvaC+xpebgA2d+pmcWpdf4TrjCI/x1 AbtA== MIME-Version: 1.0 X-Received: by 10.42.119.202 with SMTP id c10mr80293603icr.4.1427980108062; Thu, 02 Apr 2015 06:08:28 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.107.7.130 with HTTP; Thu, 2 Apr 2015 06:08:28 -0700 (PDT) In-Reply-To: <551D0F27.9030201@ninebynine.org> References: <2E49FA112B054FFAED69D8A1@JcK-HP8200.jck.com> <551D0F27.9030201@ninebynine.org> Date: Thu, 2 Apr 2015 09:08:28 -0400 X-Google-Sender-Auth: v92JZZ_9gye1H3cibNeIF-Y3loc Message-ID: From: Barry Leiba To: Graham Klyne Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Cc: "draft-ietf-appsawg-uri-scheme-reg.all@ietf.org" , IESG , Apps Discuss Subject: Re: [apps-discuss] Retroactive application of draft-ietf-appsawg-uri-scheme-reg - comprehensive review X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 02 Apr 2015 13:09:22 -0000 Just to one point: > My reason is that there is software out there that is written to accept > *anything* that is a valid URI, and legitimately expect such strings to > confirm to RFC3986 syntax (not withstanding Sam Ruby's efforts to document > variations between systems about what they accept as a valid URI). Absolutely. And the URNbis document maintains that, but keeping URNs syntactically URIs. > If URNs > are to be usable as URIs in such circumstances, I think it's important that > they follow the rules, including those concerning the role of fragment > identifiers. Here's where I don't agree. If URN fragments (f-components, or friggle-fraggles... the bit after the "#") are semantically somewhat different to what 3986 says about fragments in locators, because that's what semantically makes sense for URNs, why does that stop anyone from continuing to use them in places where URIs are syntactically required? Barry From nobody Thu Apr 2 07:19:14 2015 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6876E1A90F2; Thu, 2 Apr 2015 07:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pV9CbyI_EVtc; Thu, 2 Apr 2015 07:19:11 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17B5F1AD338; Thu, 2 Apr 2015 07:19:10 -0700 (PDT) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Ydfxb-000I8Q-SF; Thu, 02 Apr 2015 10:19:07 -0400 Date: Thu, 02 Apr 2015 10:19:02 -0400 From: John C Klensin To: Graham Klyne , draft-ietf-appsawg-uri-scheme-reg.all@ietf.org, iesg@ietf.org, apps-discuss@ietf.org Message-ID: <1AFEBE03F8FCCEB215C30DEC@JcK-HP8200.jck.com> In-Reply-To: <551D0F27.9030201@ninebynine.org> References: <2E49FA112B054FFAED69D8A1@JcK-HP8200.jck.com> <551D0F27.9030201@ninebynine.org> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [apps-discuss] Retroactive application of draft-ietf-appsawg-uri-scheme-reg - comprehensive review X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 02 Apr 2015 14:19:13 -0000 Barry has commented on the more important part of this, but an observation on the other part... --On Thursday, April 02, 2015 10:43 +0100 Graham Klyne wrote: >> If we can agree that this is not applicable to existing >> registered scheme definitions or updates to them and that >> future URN-like schemes are unlikely, then that is a >> non-issue. If we cannot, the AppsAWG and IESG should be >> formally aware (the former has certainly been told about this >> in various area meetings) that the current consensus within >> URNBIS is to separate URNs from the semantic requirements of >> 3986 [2]. That position was the result of a difficult >> compromise in which the main alternative was to separate URNs >> entirely from what the WG believes are the many assumptions >> (most derived from locators) and some of the confusing >> language in 3986. > > Procedural matters aside, I think this is an important > clarification, and that urn: URIs SHOULD be constrained by > this. This is not about existing and new URI schemes, but > about what is required to be a a valid URI. Procedural issues very much not aside, I would like to see if we can navigate the very large collection of URI issues (including those being discussed outside IETF) in a way that doesn't make everything so dependent on everything else that we cannot move any document (including this one) forward without moving everything else forward at the same time. If, as you suggest, language in draft-ietf-appsawg-uri-scheme-reg-05 "clarifies" what is required to be a valid URI, especially in a way that affects both existing and future ones, then it necessarily updates 3986. If it does that, then it is missing the required "Updates" indication (trivial) and the required explanation of what parts or provisions of 3986 are being updated and how. So, if you believe the above, you have just made a significant procedural objection to processing the draft in its current form. While that might be a minor issue for some documents, easily corrected by an RFC Editor note, I believe there is ample reason to believe that a description of what is being updated and why would turn out to be controversial and difficult in terms of achieving consensus. At least from my perspective, the problem goes beyond that and into issues I have identified earlier. If draft-ietf-appsawg-uri-scheme-reg modifies what it is possible to do in ongoing URN work beyond whatever is clearly specified in 3986, then any of the active participants in URNBIS (or those concerned about its output, whether actively participating or not) are entitled to raise the issue of whether openness and fairness allows draft-ietf-appsawg-uri-scheme-reg to be processed independently of the URN documents that it claims to restrict. Equally frighteningly, if draft-ietf-appsawg-uri-scheme-reg changes the fundamental validity criteria for URIs as specified (or claimed to be specified) in 3986, it presumably [re]opens all of the issues about what 3986 actually requires rather than recommending or discussing and probably requires reaching consensus on and documenting such topics as those raised in the rather extensive threads about 3986 validity and scope that showed up in January and not moving _any_ of these documents forward until 3986bis (the right place to apply such clarifications) is ready for IETF Last Call. Another complication is that if there is disagreement in the community about the scope of draft-ietf-appsawg-uri-scheme-reg before it is even approved, you are a partisan for one position in that matter and that combination might cause reasonable people to be concerned about perceptions of possible interactions between those issues and your role as Designated Expert. I hope we can avoid going into a place where all of these issues become procedurally interlocked but when some of the authors and a subset of the (I believe few) people who carefully reviewed draft-ietf-appsawg-uri-scheme-reg disagree on its scope and applicability, we are not in good shape for avoiding that outcome. john From nobody Thu Apr 2 07:19:18 2015 Return-Path: X-Original-To: expand-draft-ietf-appsawg-uri-scheme-reg.all@virtual.ietf.org Delivered-To: apps-discuss@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 9078C1B2A83; Thu, 2 Apr 2015 07:19:13 -0700 (PDT) X-Original-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6876E1A90F2; Thu, 2 Apr 2015 07:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pV9CbyI_EVtc; Thu, 2 Apr 2015 07:19:11 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17B5F1AD338; Thu, 2 Apr 2015 07:19:10 -0700 (PDT) Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Ydfxb-000I8Q-SF; Thu, 02 Apr 2015 10:19:07 -0400 Date: Thu, 02 Apr 2015 10:19:02 -0400 From: John C Klensin To: Graham Klyne , draft-ietf-appsawg-uri-scheme-reg.all@ietf.org, iesg@ietf.org, apps-discuss@ietf.org Message-ID: <1AFEBE03F8FCCEB215C30DEC@JcK-HP8200.jck.com> In-Reply-To: <551D0F27.9030201@ninebynine.org> References: <2E49FA112B054FFAED69D8A1@JcK-HP8200.jck.com> <551D0F27.9030201@ninebynine.org> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.35 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [apps-discuss] Retroactive application of draft-ietf-appsawg-uri-scheme-reg - comprehensive review X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 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, 02 Apr 2015 14:19:13 -0000 Barry has commented on the more important part of this, but an observation on the other part... --On Thursday, April 02, 2015 10:43 +0100 Graham Klyne wrote: >> If we can agree that this is not applicable to existing >> registered scheme definitions or updates to them and that >> future URN-like schemes are unlikely, then that is a >> non-issue. If we cannot, the AppsAWG and IESG should be >> formally aware (the former has certainly been told about this >> in various area meetings) that the current consensus within >> URNBIS is to separate URNs from the semantic requirements of >> 3986 [2]. That position was the result of a difficult >> compromise in which the main alternative was to separate URNs >> entirely from what the WG believes are the many assumptions >> (most derived from locators) and some of the confusing >> language in 3986. > > Procedural matters aside, I think this is an important > clarification, and that urn: URIs SHOULD be constrained by > this. This is not about existing and new URI schemes, but > about what is required to be a a valid URI. Procedural issues very much not aside, I would like to see if we can navigate the very large collection of URI issues (including those being discussed outside IETF) in a way that doesn't make everything so dependent on everything else that we cannot move any document (including this one) forward without moving everything else forward at the same time. If, as you suggest, language in draft-ietf-appsawg-uri-scheme-reg-05 "clarifies" what is required to be a valid URI, especially in a way that affects both existing and future ones, then it necessarily updates 3986. If it does that, then it is missing the required "Updates" indication (trivial) and the required explanation of what parts or provisions of 3986 are being updated and how. So, if you believe the above, you have just made a significant procedural objection to processing the draft in its current form. While that might be a minor issue for some documents, easily corrected by an RFC Editor note, I believe there is ample reason to believe that a description of what is being updated and why would turn out to be controversial and difficult in terms of achieving consensus. At least from my perspective, the problem goes beyond that and into issues I have identified earlier. If draft-ietf-appsawg-uri-scheme-reg modifies what it is possible to do in ongoing URN work beyond whatever is clearly specified in 3986, then any of the active participants in URNBIS (or those concerned about its output, whether actively participating or not) are entitled to raise the issue of whether openness and fairness allows draft-ietf-appsawg-uri-scheme-reg to be processed independently of the URN documents that it claims to restrict. Equally frighteningly, if draft-ietf-appsawg-uri-scheme-reg changes the fundamental validity criteria for URIs as specified (or claimed to be specified) in 3986, it presumably [re]opens all of the issues about what 3986 actually requires rather than recommending or discussing and probably requires reaching consensus on and documenting such topics as those raised in the rather extensive threads about 3986 validity and scope that showed up in January and not moving _any_ of these documents forward until 3986bis (the right place to apply such clarifications) is ready for IETF Last Call. Another complication is that if there is disagreement in the community about the scope of draft-ietf-appsawg-uri-scheme-reg before it is even approved, you are a partisan for one position in that matter and that combination might cause reasonable people to be concerned about perceptions of possible interactions between those issues and your role as Designated Expert. I hope we can avoid going into a place where all of these issues become procedurally interlocked but when some of the authors and a subset of the (I believe few) people who carefully reviewed draft-ietf-appsawg-uri-scheme-reg disagree on its scope and applicability, we are not in good shape for avoiding that outcome. john From nobody Thu Apr 2 10:54:17 2015 Return-Path: X-Original-To: expand-draft-ietf-appsawg-multipart-form-data.all@virtual.ietf.org Delivered-To: apps-discuss@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 761F41A0092; Wed, 1 Apr 2015 10:15:12 -0700 (PDT) X-Original-To: xfilter-draft-ietf-appsawg-multipart-form-data.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-appsawg-multipart-form-data.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45AB01A0084 for ; Wed, 1 Apr 2015 10:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.333 X-Spam-Level: X-Spam-Status: No, score=-1.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y7G1gYBiczjw for ; Wed, 1 Apr 2015 10:15:07 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D84F11A0092 for ; Wed, 1 Apr 2015 10:15:07 -0700 (PDT) Received: from mail-pa0-x233.google.com ([2607:f8b0:400e:c03::233]:35960) by zinfandel.tools.ietf.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YdMEM-0002C3-Ga for draft-ietf-appsawg-multipart-form-data.all@tools.ietf.org; Wed, 01 Apr 2015 10:15:07 -0700 Received: by padcy3 with SMTP id cy3so57763895pad.3 for ; Wed, 01 Apr 2015 10:14:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type; bh=vzBps80pwypn9vfYBMFed/6bWXTRGC/sdPp2MRF2SM4=; b=JFFLPKLWqLF1rP48gA+BH2rMbSH2xQqUCyMhf99bTz2ufoEYnm8QdL+bQPleA15GsN U6RfxHKIBa5+KMIV4DjMH6HbT5kMReGP7rCjP5iPtFQKmSITjP3YAZsIr414eByvaQhe D9b5hXN8qDMblNs3hhU2E7yOZylF+bIi7EWVbsTMx2tVCCUjkMVv+1XcGJBT7CGryocs bXsiycfbn4vCvBDpXrWwJPgm3dPEvWYpz0zwGsiFLs0UPwwWfdp5J1emvXNLHyx3JFVR /cPX0HH3igTkP9uw0VzEqsNEn+yr8zsgrPmO6wi2DJpmXNKgr1sQU0ob28a9Y+7PVq1d Bi8A== X-Received: by 10.68.78.65 with SMTP id z1mr79796720pbw.112.1427908499705; Wed, 01 Apr 2015 10:14:59 -0700 (PDT) Received: from [192.168.1.76] (172-3-137-150.lightspeed.sntcca.sbcglobal.net. [172.3.137.150]) by mx.google.com with ESMTPSA id je11sm2669502pbd.65.2015.04.01.10.14.58 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Apr 2015 10:14:59 -0700 (PDT) Message-ID: <551C2791.7090206@gmail.com> Date: Wed, 01 Apr 2015 10:14:57 -0700 From: Chris Lonvick User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "iesg@ietf.org" , "secdir@ietf.org" , draft-ietf-appsawg-multipart-form-data.all@tools.ietf.org Content-Type: multipart/alternative; boundary="------------040602060508070505010801" X-SA-Exim-Connect-IP: 2607:f8b0:400e:c03::233 X-SA-Exim-Rcpt-To: draft-ietf-appsawg-multipart-form-data.all@tools.ietf.org X-SA-Exim-Mail-From: lonvick.ietf@gmail.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-appsawg-multipart-form-data.all@ietf.org Resent-Message-Id: <20150401171507.D84F11A0092@ietfa.amsl.com> Resent-Date: Wed, 1 Apr 2015 10:15:07 -0700 (PDT) Resent-From: lonvick.ietf@gmail.com Archived-At: Archived-At: X-Mailman-Approved-At: Thu, 02 Apr 2015 10:54:16 -0700 Subject: [apps-discuss] SECDIR review of draft-ietf-appsawg-multipart-form-data-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 17:15:12 -0000 This is a multi-part message in MIME format. --------------040602060508070505010801 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. I only got a chance to skim through the document but the Security Considerations section looks to be consistent with RFC 2388, which it intends to replace. I would suggest placing the last paragraph of the Security Considerations section at the top of the section. That paragraph seems to be the most comprehensive in these considerations, and the other paragraphs seem to augment and give specific details. It just seems to me that it would provide a better flow to reading that section. Also, I'm just not sure that I'm following the second paragraph of Appendix B: More problematic is the ambiguity introduced because implementations did not follow [RFC2388 ] because it used "may" instead of "MUST" when specifying encoding of field names, and for other unknown reasons, so now, parsers need to be more complex for fuzzy matching against the possible outputs of various encoding methods. Please correct me if I'm off base here, but it sounds like the ambiguity set in because implementations WERE following RFC 2388 by making choices on their own (due to the "may"s) rather than being directed to make uniform choices which would have been mandated if that RFC had used "MUST"s. Finally, I usually advocate giving directions to implementers about what to do if they find implementations using the older, outdated spec. As an example, what should a receiver do if it gets a ContentType that does not have a "boundary" parameter? However, as I'm not really familiar with this technology, and as the document says there are many ways to do all of this, then I'm not sure that could or should be discussed. If it is something that would better define behavior then I would suggest providing some guidance here. Best regards, Chris --------------040602060508070505010801 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit 
Hi,
I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

I only got a chance to skim through the document but the Security 
Considerations section looks to be consistent with RFC 2388, which it 
intends to replace.

I would suggest placing the last paragraph of the Security Considerations
section at the top of the section.  That paragraph seems to be the most
comprehensive in these considerations, and the other paragraphs seem to
augment and give specific details.  It just seems to me that it would
provide a better flow to reading that section.

Also, I'm just not sure that I'm following the second paragraph of
Appendix B:
   More problematic is the ambiguity introduced because implementations
   did not follow [RFC2388] because it used "may" instead of "MUST" when
   specifying encoding of field names, and for other unknown reasons, so
   now, parsers need to be more complex for fuzzy matching against the
   possible outputs of various encoding methods.
Please correct me if I'm off base here, but it sounds like the ambiguity
set in because implementations WERE following RFC 2388 by making
choices on their own (due to the "may"s) rather than being directed to
make uniform choices which would have been mandated if that RFC had used
"MUST"s.

Finally, I usually advocate giving directions to implementers about what
to do if they find implementations using the older, outdated spec.  As
an example, what should a receiver do if it gets a ContentType that does
not have a "boundary" parameter?  However, as I'm not really familiar 
with this technology, and as the document says there are many ways to
do all of this, then I'm not sure that could or should be discussed.  If
it is something that would better define behavior then I would suggest
providing some guidance here.

Best regards,
Chris


  


--------------040602060508070505010801--


From nobody Thu Apr  2 10:54:19 2015
Return-Path: 
X-Original-To: expand-draft-ietf-appsawg-uri-scheme-reg.all@virtual.ietf.org
Delivered-To: apps-discuss@ietfa.amsl.com
Received: by ietfa.amsl.com (Postfix, from userid 65534) id B85FF1A8A9D; Wed,  1 Apr 2015 12:41:04 -0700 (PDT)
X-Original-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com
Delivered-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD481A8A5E; Wed,  1 Apr 2015 12:41:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level: 
X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7Xm71dAPxr8; Wed,  1 Apr 2015 12:41:02 -0700 (PDT)
Received: from waldorf.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id E96D11A8F4C; Wed,  1 Apr 2015 12:40:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1427917252; d=isode.com; s=selector; i=@isode.com; bh=c6JicUJcFzNOnf7Bu29d2X/8j3YGfnEGWudPDMjEhUk=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=D7Cth7xydbTqAw8y9K3JM+z5G/5nMT9YFepgeakJlHtjiSsKcMfyWSPbXh4132ftXjtBGH 6jp7Fi3LGhu2cYpdsWymRi9TbWT/Kjx6/hufqGYNWk+Sc/wrhPvzN9pbiOdR5iQx1cxm8V damz0VOqF7JJ4fu8qZmR/S1+ZySDdIA=;
Received: from [192.168.0.5] (cpc5-nmal20-2-0-cust24.19-2.cable.virginm.net [92.234.84.25])  by waldorf.isode.com (submission channel) via TCP with ESMTPSA  id ; Wed, 1 Apr 2015 20:40:48 +0100
X-SMTP-Protocol-Errors: PIPELINING
Message-ID: <551C49BC.6010705@isode.com>
Date: Wed, 01 Apr 2015 20:40:44 +0100
From: Alexey Melnikov 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
To: John C Klensin 
References: <20150327163331.20999.30881.idtracker@ietfa.amsl.com>   <551806AD.2010409@isode.com> <4F34805800F3B75F9752C8A5@JcK-HP8200.jck.com>
In-Reply-To: <4F34805800F3B75F9752C8A5@JcK-HP8200.jck.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-transfer-encoding: quoted-printable
Archived-At: 
X-Mailman-Approved-At: Thu, 02 Apr 2015 10:54:16 -0700
Cc: Barry Leiba , iesg@ietf.org, draft-ietf-appsawg-uri-scheme-reg.all@ietf.org
Subject: Re: [apps-discuss] FW: New Version Notification - draft-ietf-appsawg-uri-scheme-reg-05.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 01 Apr 2015 19:41:04 -0000

On 29/03/2015 20:59, John C Klensin wrote:
> --On Sunday, March 29, 2015 15:05 +0100 Alexey Melnikov
>  wrote:
>
>> On 27/03/2015 19:29, Barry Leiba wrote:
>>>> I will send email responses to the feedback received with
>>>> what we did. I may not get those out today though. But I
>>>> think the doc should be ready for the IESG telechat.
>>> Thanks.  I've issued the ballot; I'll wait to change the
>>> state until I hear that your co-authors & shepherd are OK
>>> with it.
>> This is almost perfect :-).
>>
>> A couple of comments:
>> ...
>> Here is a real world example of a problem with this text. SIDR
>> WG decided to use rsync protocol, they needed to use rsync
>> URIs. rsync URIs are currently provisional, defined in an
>> Informational RFC.  So this text is basically saying that
>> under the new rule the registration have to be upgraded to
>> Permanent, allowing the expert reviewer (no disrespect to
>> Graham or his future replacement) to be a person that blocks
>> consensus of a WG to use a particular technology. I find this
>> to be problematic.
>>
>> Do people agree that this is problematic?
> Yes.
>
> At the risk of tossing a spanner toward the works, one more
> issue that seems to me very significant:
>
> Larry Masinter has raised several issues in the URNBIS WG in
> which he claims that draft-ietf-appsawg-uri-scheme-reg
> constrains what that WG is proposing to do with URNs [1].  I
> also believe that some of his comments mix up registration of
> schemes (e.g., "urn:") with registrations of URN namespaces and
> NIDs  I think those issues need to be considered in that WG.
> However, procedurally, it seems to me that either:
John, from looking at the list of changes since RFC 4395 in=20
draft-ietf-appsawg-uri-scheme-reg, I don't see anything obvious that=20
would break URNs.

But reading [1], here is my personal opinion:

1. Use of =93/=93 - I agree with Larry that this should be fixed in the=20
draft-ietf-urnbis-rfc2141bis-urn. URNs are either hierarchical or they=20
are not. They can't be "sort of hierarchical".
2. Use of =93#=94 - I think this needs to be discussed. I agree that there=
=20
is an issue, but I am not sure about solutions yet.
3. Update of formal namespaces with =91Expert Review=92 - I agree with you=
=20
that what draft-ietf-appsawg-uri-scheme-reg says has no impact on URN=20
namespaces. However, I agree with Larry that a similar solution should=20
(SHOULD ;-)) be used for URNs.

The issue #1 is not really new to draft-ietf-appsawg-uri-scheme-reg. I=20
am not sure about #2. If it is, it also need to be listed in the=20
"changes since" section.

[snip]
> [1]
> http://www.ietf.org/mail-archive/web/urn/current/msg02873.html
>
>


From nobody Thu Apr  2 10:54:20 2015
Return-Path: 
X-Original-To: expand-draft-ietf-appsawg-uri-scheme-reg.all@virtual.ietf.org
Delivered-To: apps-discuss@ietfa.amsl.com
Received: by ietfa.amsl.com (Postfix, from userid 65534) id 7CFB01ACF6C; Wed,  1 Apr 2015 17:26:55 -0700 (PDT)
X-Original-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com
Delivered-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61CE61ACF24; Wed,  1 Apr 2015 17:26:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZcYHRpElIBFq; Wed,  1 Apr 2015 17:26:52 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0644.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:644]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 719771ACF1D; Wed,  1 Apr 2015 17:26:50 -0700 (PDT)
Received: from DM2PR02MB1322.namprd02.prod.outlook.com (25.161.142.21) by DM2PR02MB1324.namprd02.prod.outlook.com (25.161.142.23) with Microsoft SMTP Server (TLS) id 15.1.118.21; Thu, 2 Apr 2015 00:26:31 +0000
Received: from DM2PR02MB1322.namprd02.prod.outlook.com ([25.161.142.21]) by DM2PR02MB1322.namprd02.prod.outlook.com ([25.161.142.21]) with mapi id 15.01.0118.022; Thu, 2 Apr 2015 00:26:31 +0000
From: Larry Masinter 
To: Alexey Melnikov , John C Klensin 
Thread-Topic: applicability of draft-ietf-appsawg-uri-scheme-reg-05.txt to URN namespaces and fragments
Thread-Index: AQHQbNuq5S+da65y3UG4w2uhpEyPiQ==
Date: Thu, 2 Apr 2015 00:26:31 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/15.8.0.150303
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [64.250.248.171]
authentication-results: spf=none (sender IP is ) smtp.mailfrom=masinter@adobe.com; 
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR02MB1324;
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10009020)(979002)(6009001)(122556002)(230783001)(54356999)(83716003)(229853001)(102836002)(92566002)(2900100001)(87936001)(40100003)(83506001)(99286002)(46102003)(86362001)(62966003)(33656002)(50986999)(15975445007)(106116001)(66066001)(2656002)(36756003)(77156002)(82746002)(19580395003)(104396002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR02MB1324; H:DM2PR02MB1322.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:DM2PR02MB1324; BCL:0; PCL:0; RULEID:;  SRVR:DM2PR02MB1324; 
x-forefront-prvs: 0534947130
received-spf: None (protection.outlook.com: adobe.com does not designate permitted sender hosts)
Content-Type: text/plain; charset="utf-8"
Content-ID: <4496E23CF762CA49B232B5CD3806DD46@namprd02.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: adobe.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Apr 2015 00:26:31.3199 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR02MB1324
Archived-At: 
X-Mailman-Approved-At: Thu, 02 Apr 2015 10:54:16 -0700
Cc: Barry Leiba , "iesg@ietf.org" , "draft-ietf-appsawg-uri-scheme-reg.all@ietf.org" 
Subject: [apps-discuss] applicability of draft-ietf-appsawg-uri-scheme-reg-05.txt to URN namespaces and fragments
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 02 Apr 2015 00:26:55 -0000

PiAzLiBVcGRhdGUgb2YgZm9ybWFsIG5hbWVzcGFjZXMgd2l0aCDigJhFeHBlcnQgUmV2aWV34oCZ
IC0gSSBhZ3JlZSB3aXRoIHlvdQ0KDQo+IHRoYXQgd2hhdCBkcmFmdC1pZXRmLWFwcHNhd2ctdXJp
LXNjaGVtZS1yZWcgc2F5cyBoYXMgbm8gaW1wYWN0IG9uIFVSTg0KPiBuYW1lc3BhY2VzLiBIb3dl
dmVyLCBJIGFncmVlIHdpdGggTGFycnkgdGhhdCBhIHNpbWlsYXIgc29sdXRpb24gc2hvdWxkDQo+
IChTSE9VTEQgOy0pKSBiZSB1c2VkIGZvciBVUk5zDQoNClRoZXJlIGlzIHRoZSBiYXNpYyDigJxz
aG91bGQgZ28gd2l0aG91dCBzYXlpbmciIGNvbnN0cmFpbnQ6DQogeW91IGNhbuKAmXQgZGVsZWdh
dGUgcmlnaHRzIHlvdSBkb27igJl0IGhhdmUgeW91cnNlbGYuDQoNClRoYXTigJlzIHRvIGJlIHJl
dmlld2VkIHRoZSBFeHBlcnQgUmV2aWV3ZXIgb3Igd2hvZXZlcg0KaXMgYXV0aG9yaXplZCB0byBh
cHByb3ZlIHRoZSBwYXJlbnQgcmVnaXN0cmF0aW9uLg0KDQoNCk5vdGUsIEkgZG9u4oCZdCB0aGlu
ayAyMTQxIGRpc2FsbG93cyBmcmFnbWVudHMsIG9yIHRoYXQgMjE0MWJpcyBzaG91bGQuDQoNCklu
IGZhY3QsIGlmIGZyYWdtZW50cyBhcmVu4oCZdCBkZWZpbmVkIGJ5IHRoZSBzY2hlbWUsIHRoZXkg
c2hvdWxkbuKAmXQNCmJlIGRpc2FsbG93ZWQgZWl0aGVyLiBJdOKAmXMganVzdCB0aGF0IGlmIHlv
dSB1c2UgYSBmcmFnbWVudCB3aXRoDQrigJhtYWlsdG864oCZIGl04oCZcyB1bmxpa2VseSB0byB3
b3JrLg0KDQogDQpNeSBwcm9ibGVtIHdpdGggMjE0MWJpcyBpcyBub3QgdGhhdCBpdCBhbGxvd3Mg
ZnJhZ21lbnRzLCBidXQgcmF0aGVyDQppdCBzZWVtcyB0byB3YW50IHRvIGRlbGVnYXRlIHRvIHVy
biBuYW1lc3BhY2VzIHRoZQ0KYWJpbGl0eSB0byBzcGVjaWZ5IHRoZSBpbnRlcnByZXRhdGlvbiBv
ZiBmcmFnbWVudHMuDQoNClNjaGVtZXMgZG9u4oCZdCBkZWZpbmUgZnJhZ21lbnQgc3ludGF4IE9S
IHNlbWFudGljcywgc28gdGhleQ0Kc2hvdWxkbuKAmXQgYmUgYWxsb3dlZCB0byBkZWxlZ2F0ZSBp
dC4NCg0KQXMgZmFyIGFzIHVyaS1zY2hlbWUtcmVnIGlzIGNvbmNlcm5lZCwgd2UgbWlnaHQgc2F5
IHNvbWV0aGluZw0KYWJvdXQgZGVsZWdhdGlvbi4gV2Ugc2hvdWxkIHJlbW92ZSDigJxOZXfigJ0g
ZnJvbSB0aGUgdGl0bGUsIGFzDQp0aGUgc2ltcGxlc3QgZWRpdCB0byBjbGFyaWZ5IGFwcGxpY2Fi
aWxpdHkgdG8gdXBkYXRlcy4NCg0KSSBkb27igJl0IHRoaW5rIHdlIG5lZWQgYSDigJhncmFuZGZh
dGhlcuKAmSBjbGF1c2U6IGEgZ29vZCByZWFzb24NCmZvciBicmVha2luZyBCQ1AzNSBndWlkZWxp
bmVzIHdvdWxkIGJlIOKAnGV4aXN0aW5nIGRlcGxveW1lbnTigJ0uDQpTbyBwcmV2aW91c2x5IHJl
Z2lzdGVyZWQgc2NoZW1lcyAobGlrZSBVUk4pIGRvbuKAmXQgaGF2ZSB0bw0KZm9sbG93IGEgQkNQ
MzUgcnVsZSBpZiB0aGV5IGRpZG7igJl0IGJlZm9yZSwgb3IgaWYgdGhlcmUgYXJlDQp3aWRlbHkg
ZGVwbG95ZWQgaW1wbGVtZW50YXRpb25zIHRoYXQgZG9u4oCZdC4NCg0KTGFycnkNCuKAlA0KaHR0
cDovL2xhcnJ5Lm1hc2ludGVyLm5ldA0KDQoNCg0K


From nobody Thu Apr  2 10:54:22 2015
Return-Path: 
X-Original-To: expand-draft-ietf-appsawg-uri-scheme-reg.all@virtual.ietf.org
Delivered-To: apps-discuss@ietfa.amsl.com
Received: by ietfa.amsl.com (Postfix, from userid 65534) id AD5761B2B99; Thu,  2 Apr 2015 00:30:05 -0700 (PDT)
X-Original-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com
Delivered-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86F301B2B97; Thu,  2 Apr 2015 00:30:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.155
X-Spam-Level: 
X-Spam-Status: No, score=-0.155 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OpyaMXCdKj5j; Thu,  2 Apr 2015 00:30:04 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 417C71B2B89; Thu,  2 Apr 2015 00:30:04 -0700 (PDT)
Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YdZZb-000ERu-Ec; Thu, 02 Apr 2015 03:29:55 -0400
Date: Thu, 02 Apr 2015 03:29:50 -0400
From: John C Klensin 
To: Larry Masinter , Alexey Melnikov 
Message-ID: 
In-Reply-To: 
References: 
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.35
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: 
X-Mailman-Approved-At: Thu, 02 Apr 2015 10:54:16 -0700
Cc: Barry Leiba , iesg@ietf.org, draft-ietf-appsawg-uri-scheme-reg.all@ietf.org
Subject: Re: [apps-discuss] applicability of draft-ietf-appsawg-uri-scheme-reg-05.txt to URN namespaces and fragments
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 02 Apr 2015 07:30:05 -0000

--On Thursday, April 02, 2015 00:26 +0000 Larry Masinter
 wrote:

>> 3. Update of formal namespaces with 'Expert Review' - I
>> agree with you
> 
>> that what draft-ietf-appsawg-uri-scheme-reg says has no
>> impact on URN namespaces. However, I agree with Larry that a
>> similar solution should (SHOULD ;-)) be used for URNs
> 
> There is the basic "should go without saying" constraint:
>  you can't delegate rights you don't have yourself.
> 
> That's to be reviewed the Expert Reviewer or whoever
> is authorized to approve the parent registration.

I have lost track of what you are talking about and can't parse
the above non-sentence.  Sorry.

> Note, I don't think 2141 disallows fragments, or that
> 2141bis should.
> 
> In fact, if fragments aren't defined by the scheme, they
> shouldn't be disallowed either. It's just that if you use
> a fragment with 'mailto:' it's unlikely to work.

> My problem with 2141bis is not that it allows fragments, but
> rather it seems to want to delegate to urn namespaces the
> ability to specify the interpretation of fragments.

>From the perspective of 2141bis (and the WG consensus decision
about using 3986's syntax but not its semantics), there is no
such thing as a fragment to allow or disallow.  There is only a
piece of 3986-conformant syntax that is introduced by a "#" and
and 2141bis calls, for convenience, an "f-component".    Perhaps
it should have been called, e.g., a "frigglefraggle" instead
because "f-component" reminds you of "fragment" too much, but
the whole point of using a different name for that piece of
syntax (relative to what 3986 uses) for an identical piece of
syntax was to reinforce the point that, the moment you start
talking about "fragments" and how they behave, are defined, or
how they interact with other things, you are outside the scope
and frame of reference of 2141bis.

If that doesn't work for you, your problem isn't really with
2141bis.  It is with the "syntax only" decision, a decision on
which Andy, as WG Chair at the time, made a consensus call and
told us to move on.

> Schemes don't define fragment syntax OR semantics, so they
> shouldn't be allowed to delegate it.

And that is an assertion that depends on 3986 semantics about
pieces of syntax.  See above.
 
> As far as uri-scheme-reg is concerned, we might say something
> about delegation. We should remove "New" from the title, as
> the simplest edit to clarify applicability to updates.

"New" has already been removed from the title.  It has not been
removed from many places it appears in the text so, if you think
its removal is important, you are co-author of a wildly
inconsistent document.
 
> I don't think we need a 'grandfather' clause: a good
> reason for breaking BCP35 guidelines would be "existing
> deployment". So previously registered schemes (like URN)
> don't have to follow a BCP35 rule if they didn't before,
> or if there are widely deployed implementations that don't.

That makes sense to me, but the document doesn't say "you can
break these guidelines if you have a good reason".  It says some
very specific things and we have had many incidents of people
turning protocol lawyers to block an outcome that they don't
like for altogether unrelated reasons.

     john


From nobody Thu Apr  2 11:06:24 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 722331B2D64; Thu,  2 Apr 2015 11:06:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level: 
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WbvPoamHV32E; Thu,  2 Apr 2015 11:06:19 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 953EB1B2D8A; Thu,  2 Apr 2015 11:06:19 -0700 (PDT)
Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YdjVN-000Ib7-G8; Thu, 02 Apr 2015 14:06:13 -0400
Date: Thu, 02 Apr 2015 14:06:08 -0400
From: John C Klensin 
To: Graham Klyne , Alexey Melnikov , draft-ietf-appsawg-uri-scheme-reg.all@ietf.org
Message-ID: 
In-Reply-To: <551D0C47.5090603@ninebynine.org>
References:  <551AE31E.1070009@ninebynine.org> <306B3AB5-02E3-4958-9D05-4E4FF82AD114@isode.com> <266EAB2393341CF1F491F327@JcK-HP8200.jck.com> <551D0C47.5090603@ninebynine.org>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.35
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: 
Cc: Barry Leiba , iesg@ietf.org, apps-discuss@ietf.org
Subject: Re: [apps-discuss] FW: New Version Notification - draft-ietf-appsawg-uri-scheme-reg-05.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 02 Apr 2015 18:06:22 -0000

--On Thursday, April 02, 2015 10:30 +0100 Graham Klyne
 wrote:

>...
>> More important, I think _any_ situation in which a designated
>> expert or other individual, especially one who is not
>> Nomcom-designated, can override a consensus decision in a WG
>> or equivalent is a fundamental violation of our principles and
>> pushes at the boundaries of "openness and fairness".
> 
> I agree, and my use of the phrase "power of veto" may have
> been ill-judged;  I was trying to say that I don't think such
> exists ;)
>...
 
> But I would be happy for this to be clarified.  For example,
> in section 7.1
> (http://tools.ietf.org/html/draft-ietf-appsawg-uri-scheme-reg-
> 05#section-7.1), maybe add something like this:
> 
> "The role of the designated expert in the procedure for
> permanent registrations described here is to ensure that
> normal IETF open review process has been properly followed,
> and to raise possible concerns about wider implications of
> proposals for the use and deployment of URIs.  Nothing in the
> procedure empowers the Designated Expert to override properly
> arrived-at IETF or working group consensus."

That would work for me and, IMO, considerably improve the
document.

>> ...   We
>> shouldn't even be discussing such situations in term of how
>> much "power of veto" the DE has.  I believe the more
>> appropriate model is to structure things so that, as soon as
>> a WG or other recognized consensus-development process takes
>> up something that would normatively define a scheme, the
>> expert review becomes important advisory input to that
>> process but nothing more.
> 
> In practice, my comments tend to be early input to the
> last-call process, and I think it would be fine in principle
> for that to be made explicit.  But there are also
> circumstances where the role of the DE to approve permanent
> registration of something that has NOT been through the IETF
> consensus process - I think we'd need to be careful not to
> disrupt that aspect of the process.

Agreed.  

>> FWIW, one attempt at defining such a relationship and tying it
>> to standardization appears in the current version of
>> draft-ietf-urnbis-rfc2141bis-urn, Section 7.2.   I continue to
>> believe that some similar discussion and model should make it
>> into draft-leiba-cotton-iana-5226bis, but that spec seems to
>> have gotten stalled.
> 
> You mean
> https://tools.ietf.org/html/draft-ietf-urnbis-rfc2141bis-urn-1
> 1#section-7.2 ?

Yes.

> I'm seeing:
> 
> "For namespaces or their definitions that are intended to
> become standards
>     or normative components of standards, the output of the
> Expert Review
>     process is intended to be a report, rather than
> instructions to IANA
>     to take action (see below)."
> 
> and
> 
> "If standardization is anticipated, the designated
>         experts will prepare a report and forward it to the
> appropriate
>         standards approval body (the IESG in the case of the
> IETF) and
>         IANA will register the requested NID only after
> receiving
>         directions from that body and a copy of the expert
> review report."
> 
> I'm OK with this in principle but have a couple of possible
> concerns:
> 
> 1. "prepare a report" starts to sound a bit heavyweight.

I didn't like it either, but it was the best I could come up
with when I was writing that.  Better wording would be welcome.
However, unlike the URI registration case in which the
presumption is that any formal standards process would be within
the IETF, the URN namespace registration text anticipates
handing off final review and approval to what the media type
registration procedure calls "recognized standards bodies" when
the namespaces themselves are under the control of those bodies.
In some of those cases, especially if the DE concludes that the
registration proposal is a hopeless mess, a "report" is going to
be precisely what is needed.  My hope is that we can avoid any
tendencies to overspecify that but the motivation is the same as
it was with media types: if a namespace registration shows up
that involves highly technical matters that are under the
control of, or standardized by, some competent and recognized
standards body or scientific group, having the IETF demonstrate
community ignorance by debating the issues is not helpful to
anyone.

>   If
> we can be clear that a "report" may be a short email at the
> level of "this is fine" or "I have concerns with  and
> " then it's OK.  But if you envisage something more
> formal then that could (from my perspective) seriously impair
> my ability to perform the DE role.

See above.  I would hope that whatever reporting would occur
would be appropriate to the circumstances.  Certainly, under the
obvious circumstances (and remembering that the issue of
delegation to other standards bodies is presumably not an issue
for URI scheme registrations), "this is fine", "I don't see any
issues", etc., would be perfectly reasonable "reports".

Again, text suggestions for the URN namespace version of this
would be very welcome.

> 2. I am not sure that it is appropriate for the IETF to have a
> procedure that requires us to become formally involved in the
> machinations of external standards bodies.  We already have
> and recommend submissions to the URI-review list, and the
> registration procedures already operate to promote dialog with
> external bodies (or individuals) who wish to make permanent
> registrations, so I'm unconvinced that greater formality is
> needed vis-a-vis interaction with external standards bodies.

First, what was anticipated was closer to a delegation and
handoff rather than "involved with the machinations".  Second,
we've had provisions equivalent to this for many years (see,
e.g., the discussion in Section 2.1.5 of RFC 2048).  The
thinking that drove that model ran something like this: Suppose
the IAU decided it need a media type for subplanetary objects or
IUPAC decided it needed one for chemical synthesis of some
flavor.  Noting that examples like that are actually far more
likely for URN namespaces than for media types, while an Expert
Review (and, if appropriate, advice) about whether the template
was adequate and whether suggestions about format or syntax were
in order, IETF debates about what objects or processes were to
be included in the namespace or how they were to be named would
not be helpful and might turn into a public embarrassment.
Consider ISBNs as an example: I would hope that a Designated
Expert would offer advice about the tradeoffs between allowing
NSS strings both with and without hyphens, including those
involving the two not being equal when comparisons were made
using generic URI rules with no scheme-specific information or
generic URN rules with no namespace-specific information.  It
seems to me that neither of those is a showstopper that should
block NID registration, but there should be an informed choice
made and that the International ISBN Agency should make it, not
the IETF (or the Designated Expert).

Again, I am _not_ suggesting this is the right model for URI
schemes even though, if things continue in the directions they
seem to be going in lately, I can image some sort of deal being
worked out between the IETF and W3C.

> What I might do is suggest that external standards bodies make
> initial registration requests early/ier in their process so
> that they can receive and respond to feedback while there is
> still scope to do so within the constraints of their process.
> For example, to submit a permanent registration request early
> on the understanding that it may initially be accepted
> provisionally, and upgraded to permanent as and when any
> concerns raised are resolved (including progression to the
> appropriate status by the requesting organization).

For URI schemes, I'm going to continue to try to not have an
opinion.  For a variety of other registration activities,
including DNS RRTYPEs and media types and I believe URN
namespaces, I suggest that "provisional" or similar vocabulary
has not worked out well because things get registered and
deployed and then, when the time comes to standardize or make
them permanent, the claim is made that they cannot be altered
without causing serious disruption.  I am reminded that similar
behavior sequences were part of what caused RFC 6648.

best,
    john


From nobody Thu Apr  2 11:06:29 2015
Return-Path: 
X-Original-To: expand-draft-ietf-appsawg-uri-scheme-reg.all@virtual.ietf.org
Delivered-To: apps-discuss@ietfa.amsl.com
Received: by ietfa.amsl.com (Postfix, from userid 65534) id 9F8081B2D8A; Thu,  2 Apr 2015 11:06:22 -0700 (PDT)
X-Original-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com
Delivered-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 722331B2D64; Thu,  2 Apr 2015 11:06:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level: 
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WbvPoamHV32E; Thu,  2 Apr 2015 11:06:19 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 953EB1B2D8A; Thu,  2 Apr 2015 11:06:19 -0700 (PDT)
Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YdjVN-000Ib7-G8; Thu, 02 Apr 2015 14:06:13 -0400
Date: Thu, 02 Apr 2015 14:06:08 -0400
From: John C Klensin 
To: Graham Klyne , Alexey Melnikov , draft-ietf-appsawg-uri-scheme-reg.all@ietf.org
Message-ID: 
In-Reply-To: <551D0C47.5090603@ninebynine.org>
References:  <551AE31E.1070009@ninebynine.org> <306B3AB5-02E3-4958-9D05-4E4FF82AD114@isode.com> <266EAB2393341CF1F491F327@JcK-HP8200.jck.com> <551D0C47.5090603@ninebynine.org>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.35
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: 
Cc: Barry Leiba , iesg@ietf.org, apps-discuss@ietf.org
Subject: Re: [apps-discuss] FW: New Version Notification - draft-ietf-appsawg-uri-scheme-reg-05.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 02 Apr 2015 18:06:22 -0000

--On Thursday, April 02, 2015 10:30 +0100 Graham Klyne
 wrote:

>...
>> More important, I think _any_ situation in which a designated
>> expert or other individual, especially one who is not
>> Nomcom-designated, can override a consensus decision in a WG
>> or equivalent is a fundamental violation of our principles and
>> pushes at the boundaries of "openness and fairness".
> 
> I agree, and my use of the phrase "power of veto" may have
> been ill-judged;  I was trying to say that I don't think such
> exists ;)
>...
 
> But I would be happy for this to be clarified.  For example,
> in section 7.1
> (http://tools.ietf.org/html/draft-ietf-appsawg-uri-scheme-reg-
> 05#section-7.1), maybe add something like this:
> 
> "The role of the designated expert in the procedure for
> permanent registrations described here is to ensure that
> normal IETF open review process has been properly followed,
> and to raise possible concerns about wider implications of
> proposals for the use and deployment of URIs.  Nothing in the
> procedure empowers the Designated Expert to override properly
> arrived-at IETF or working group consensus."

That would work for me and, IMO, considerably improve the
document.

>> ...   We
>> shouldn't even be discussing such situations in term of how
>> much "power of veto" the DE has.  I believe the more
>> appropriate model is to structure things so that, as soon as
>> a WG or other recognized consensus-development process takes
>> up something that would normatively define a scheme, the
>> expert review becomes important advisory input to that
>> process but nothing more.
> 
> In practice, my comments tend to be early input to the
> last-call process, and I think it would be fine in principle
> for that to be made explicit.  But there are also
> circumstances where the role of the DE to approve permanent
> registration of something that has NOT been through the IETF
> consensus process - I think we'd need to be careful not to
> disrupt that aspect of the process.

Agreed.  

>> FWIW, one attempt at defining such a relationship and tying it
>> to standardization appears in the current version of
>> draft-ietf-urnbis-rfc2141bis-urn, Section 7.2.   I continue to
>> believe that some similar discussion and model should make it
>> into draft-leiba-cotton-iana-5226bis, but that spec seems to
>> have gotten stalled.
> 
> You mean
> https://tools.ietf.org/html/draft-ietf-urnbis-rfc2141bis-urn-1
> 1#section-7.2 ?

Yes.

> I'm seeing:
> 
> "For namespaces or their definitions that are intended to
> become standards
>     or normative components of standards, the output of the
> Expert Review
>     process is intended to be a report, rather than
> instructions to IANA
>     to take action (see below)."
> 
> and
> 
> "If standardization is anticipated, the designated
>         experts will prepare a report and forward it to the
> appropriate
>         standards approval body (the IESG in the case of the
> IETF) and
>         IANA will register the requested NID only after
> receiving
>         directions from that body and a copy of the expert
> review report."
> 
> I'm OK with this in principle but have a couple of possible
> concerns:
> 
> 1. "prepare a report" starts to sound a bit heavyweight.

I didn't like it either, but it was the best I could come up
with when I was writing that.  Better wording would be welcome.
However, unlike the URI registration case in which the
presumption is that any formal standards process would be within
the IETF, the URN namespace registration text anticipates
handing off final review and approval to what the media type
registration procedure calls "recognized standards bodies" when
the namespaces themselves are under the control of those bodies.
In some of those cases, especially if the DE concludes that the
registration proposal is a hopeless mess, a "report" is going to
be precisely what is needed.  My hope is that we can avoid any
tendencies to overspecify that but the motivation is the same as
it was with media types: if a namespace registration shows up
that involves highly technical matters that are under the
control of, or standardized by, some competent and recognized
standards body or scientific group, having the IETF demonstrate
community ignorance by debating the issues is not helpful to
anyone.

>   If
> we can be clear that a "report" may be a short email at the
> level of "this is fine" or "I have concerns with  and
> " then it's OK.  But if you envisage something more
> formal then that could (from my perspective) seriously impair
> my ability to perform the DE role.

See above.  I would hope that whatever reporting would occur
would be appropriate to the circumstances.  Certainly, under the
obvious circumstances (and remembering that the issue of
delegation to other standards bodies is presumably not an issue
for URI scheme registrations), "this is fine", "I don't see any
issues", etc., would be perfectly reasonable "reports".

Again, text suggestions for the URN namespace version of this
would be very welcome.

> 2. I am not sure that it is appropriate for the IETF to have a
> procedure that requires us to become formally involved in the
> machinations of external standards bodies.  We already have
> and recommend submissions to the URI-review list, and the
> registration procedures already operate to promote dialog with
> external bodies (or individuals) who wish to make permanent
> registrations, so I'm unconvinced that greater formality is
> needed vis-a-vis interaction with external standards bodies.

First, what was anticipated was closer to a delegation and
handoff rather than "involved with the machinations".  Second,
we've had provisions equivalent to this for many years (see,
e.g., the discussion in Section 2.1.5 of RFC 2048).  The
thinking that drove that model ran something like this: Suppose
the IAU decided it need a media type for subplanetary objects or
IUPAC decided it needed one for chemical synthesis of some
flavor.  Noting that examples like that are actually far more
likely for URN namespaces than for media types, while an Expert
Review (and, if appropriate, advice) about whether the template
was adequate and whether suggestions about format or syntax were
in order, IETF debates about what objects or processes were to
be included in the namespace or how they were to be named would
not be helpful and might turn into a public embarrassment.
Consider ISBNs as an example: I would hope that a Designated
Expert would offer advice about the tradeoffs between allowing
NSS strings both with and without hyphens, including those
involving the two not being equal when comparisons were made
using generic URI rules with no scheme-specific information or
generic URN rules with no namespace-specific information.  It
seems to me that neither of those is a showstopper that should
block NID registration, but there should be an informed choice
made and that the International ISBN Agency should make it, not
the IETF (or the Designated Expert).

Again, I am _not_ suggesting this is the right model for URI
schemes even though, if things continue in the directions they
seem to be going in lately, I can image some sort of deal being
worked out between the IETF and W3C.

> What I might do is suggest that external standards bodies make
> initial registration requests early/ier in their process so
> that they can receive and respond to feedback while there is
> still scope to do so within the constraints of their process.
> For example, to submit a permanent registration request early
> on the understanding that it may initially be accepted
> provisionally, and upgraded to permanent as and when any
> concerns raised are resolved (including progression to the
> appropriate status by the requesting organization).

For URI schemes, I'm going to continue to try to not have an
opinion.  For a variety of other registration activities,
including DNS RRTYPEs and media types and I believe URN
namespaces, I suggest that "provisional" or similar vocabulary
has not worked out well because things get registered and
deployed and then, when the time comes to standardize or make
them permanent, the claim is made that they cannot be altered
without causing serious disruption.  I am reminded that similar
behavior sequences were part of what caused RFC 6648.

best,
    john


From nobody Thu Apr  2 12:02:33 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B4D01A1A70; Thu,  2 Apr 2015 12:02:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.902
X-Spam-Level: 
X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nduYbUfl6CeQ; Thu,  2 Apr 2015 12:02:27 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0751.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:751]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB98A1A1B5D; Thu,  2 Apr 2015 12:02:05 -0700 (PDT)
Received: from BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) by BY2PR03MB411.namprd03.prod.outlook.com (10.141.141.22) with Microsoft SMTP Server (TLS) id 15.1.130.12; Thu, 2 Apr 2015 19:01:50 +0000
Received: from BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) by BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) with mapi id 15.01.0130.020; Thu, 2 Apr 2015 19:01:50 +0000
From: Dave Thaler 
To: "drafts-expert-review@iana.org" 
Thread-Topic: [IANA #812412] Expert Review - draft-ietf-appsawg-uri-scheme-reg-04
Thread-Index: AQHQYBLgskoDp2Jf6ky4uqKxp9O/2506LLCg
Date: Thu, 2 Apr 2015 19:01:50 +0000
Message-ID: 
References:   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:4898:80e0:ee43::5]
authentication-results: iana.org; dkim=none (message not signed) header.d=none;
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB411;
x-microsoft-antispam-prvs: 
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(13464003)(51704005)(51914003)(377454003)(77096005)(46102003)(77156002)(122556002)(74316001)(19580395003)(106116001)(110136001)(2351001)(62966003)(76576001)(102836002)(19580405001)(54356999)(2501003)(87936001)(50986999)(2656002)(86362001)(33656002)(99286002)(230783001)(76176999)(2950100001)(92566002)(2900100001)(86612001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB411; H:BY2PR03MB412.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:BY2PR03MB411; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB411; 
x-forefront-prvs: 0534947130
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.onmicrosoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Apr 2015 19:01:50.6092 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB411
Archived-At: 
Cc: "appsawg-chairs@ietf.org" , "draft-ietf-appsawg-uri-scheme-reg.all@ietf.org" , "iesg@ietf.org" , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] [IANA #812412] Expert Review - draft-ietf-appsawg-uri-scheme-reg-04
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 02 Apr 2015 19:02:29 -0000

VGhhbmtzIGZvciB0aGUgcmV2aWV3LiAgQmVsb3cgaXMgd2hhdCB0aGUgY28tYXV0aG9ycyBkaWQg
aW4gcmVzcG9uc2UgaW4gLTA1Og0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZy
b206IFBlYXJsIExpYW5nIHZpYSBSVCBbbWFpbHRvOmRyYWZ0cy1leHBlcnQtcmV2aWV3QGlhbmEu
b3JnXQ0KPiBTZW50OiBNb25kYXksIE1hcmNoIDE2LCAyMDE1IDEwOjU5IEFNDQo+IENjOiBkcmFm
dC1pZXRmLWFwcHNhd2ctdXJpLXNjaGVtZS1yZWcuYWxsQGlldGYub3JnOyBhcHBzYXdnLWNoYWly
c0BpZXRmLm9yZzsNCj4gYXBwcy1kaXNjdXNzQGlldGYub3JnOyBpZXNnQGlldGYub3JnDQo+IFN1
YmplY3Q6IFtJQU5BICM4MTI0MTJdIEV4cGVydCBSZXZpZXcgLSBkcmFmdC1pZXRmLWFwcHNhd2ct
dXJpLXNjaGVtZS1yZWctMDQNCj4gDQo+IERlYXIgQXV0aG9ycywNCj4gDQo+IFVwb24gcmV2aWV3
LCBHcmFoYW0gS2x5bmUgaGFzIGFwcHJvdmVkIHRoZSByZXF1ZXN0ZWQgbmV3IFVSSSBzY2hlbWUg
YW5kDQo+IHJhaXNlZCBzb21lIGNvbW1lbnRzIGFuZCBxdWVzdGlvbjoNCj4gDQo+IC4uLg0KPiAN
Cj4gSSdtIGFsc28gdGFraW5nIHRoaXMgb3Bwb3J0dW5pdHkgdG8gcmV2aWV3IHRoZSBjdXJyZW50
IHZlcnNpb24gYW5kIG1ha2Ugc29tZQ0KPiBmaW5hbCBjb21tZW50cy4gVGhlc2UgYXJlIHByZXR0
eSBtdWNoIGFsbCBlZGl0b3JpYWwsIGFuZCBJJ20gYXNzdW1pbmcgdGhleQ0KPiBjb3VsZCBiZSBh
ZGRyZXNzZWQgKG9yIG5vdCkgaW4gYW55IEFVVEg0OCBwZXJpb2Qgd2l0aG91dCByZXF1aXJpbmcg
ZnVydGhlcg0KPiBwdWJsaWMgcmV2aWV3Lg0KPiANCj4gDQo+IFNlY3Rpb24gMy4NCj4gDQo+ICJG
b3IgSUVURiBTdGFuZGFyZHMtVHJhY2sgZG9jdW1lbnRzLCBQZXJtYW5lbnQgcmVnaXN0cmF0aW9u
IHN0YXR1cyBpcw0KPiBSRVFVSVJFRC4iDQo+IFJlYWRpbmcgdGhpcyBub3csIEkgZmluZCB0aGUg
ZHJhZnRpbmcgaGVyZSBpcyBwb3RlbnRpYWxseSBjb25mdXNpbmcuIFN1Z2dlc3Q6DQo+IA0KPiAi
Rm9yIFVSSSBzY2hlbWVzIGRlZmluZWQgb3Igbm9ybWF0aXZlbHkgcmVmZXJlbmNlZCBieSBJRVRG
IFN0YW5kYXJkcy1UcmFjaw0KPiBkb2N1bWVudHMsIFBlcm1hbmVudCByZWdpc3RyYXRpb24gc3Rh
dHVzIGlzIFJFUVVJUkVELiINCg0KVGhpcyB3YXMgdGhlIHN1YmplY3Qgb2YgdGhlIHJlc3Qgb2Yg
dGhpcyB0aHJlYWQsIHdpdGggY29tbWVudHMgZnJvbSB0aGUgQUQsDQp0aGUgZG9jIHNoZXBoZXJk
LCBjby1hdXRob3JzLCBhbmQgb3RoZXIgV0cgcGFydGljaXBhbnRzLg0KDQpXZSB0aG91Z2h0IHRo
ZSBjb25jZW5zdXMgd2FzIHRvIGFjY2VwdCB0aGlzIGFuZCBzbyBtYWRlIHRoZSBjaGFuZ2UuDQoo
SSBzZWUgdGhpcyBkaXNjdXNzaW9uIGNvbnRpbnVlcyByZWdhcmRpbmcgLTA1Li4uKQ0KDQo+IFNl
Y3Rpb24gMy4zDQo+IA0KPiAiU2NoZW1lcyB0aGF0IGFyZSBub3QgaW50ZW5kZWQgdG8gYmUgdXNl
ZCBhcyBsb2NhdG9ycyBTSE9VTEQgZGVzY3JpYmUgaG93DQo+IHRoZQ0KPiByZXNvdXJjZSBpZGVu
dGlmaWVkIGNhbiBiZSBkZXRlcm1pbmVkIG9yIGFjY2Vzc2VkIGJ5IHNvZnR3YXJlIHRoYXQgb2J0
YWlucyBhDQo+IFVSSQ0KPiBvZiB0aGF0IHNjaGVtZS4iDQo+IA0KPiBUaGlzIGRvZXNuJ3Qgc2Vl
bSBxdWl0ZSByaWdodCB0byBtZS4gU2NoZW1lcyB0aGF0IGFyZSBub3QgaW50ZW5kZWQgdG8gYmUN
Cj4gdXNlZA0KPiBhcyBsb2NhdG9ycyBhcmVuJ3QgZ2VuZXJhbGx5IGV4cGVjdGVkIHRvIGJlIGFj
Y2Vzc2VkIGJ5IHNvZnR3YXJlICh0aG91Z2ggdGhleQ0KPiBtYXkgYmUgaW4gcGFydGljdWxhciBj
aXJjdW1zdGFuY2VzKS4NCj4gDQo+IEkgdGhpbmsgdGhlbiBwb2ludCB0aGF0IG5lZWRzIHRvIGJl
IG1hZGUgaGVyZSBpcyB0aGF0IHRoZXJlIHNob3VsZCBiZSBzb21lDQo+IGRlZmluZWQgc3RydWN0
dXJlIG9mIG5hbWluZyBhdXRob3JpdHkgZm9yIHRoZSBzY2hlbWUsIHdoaWNoIGlzIG5vdCBuZWNl
c3NhcmlseQ0KPiBpbnRlcnByZXRhYmxlIGJ5IHNvZnR3YXJlLiBFLmcuLCBzb21ldGhpbmcgbGlr
ZToNCj4gDQo+ICJTY2hlbWVzIHRoYXQgYXJlIG5vdCBpbnRlbmRlZCB0byBiZSB1c2VkIGFzIGxv
Y2F0b3JzIFNIT1VMRCBkZXNjcmliZSBob3cNCj4gdGhlDQo+IHJlc291cmNlIGlkZW50aWZpZWQg
Y2FuIGJlIGRldGVybWluZWQgb3IgYWNjZXNzZWQgYnkgYW4gYWdlbnQgdGhhdCBvYnRhaW5zIGEN
Cj4gVVJJDQo+IG9mIHRoYXQgc2NoZW1lLiINCg0KVGhlIHRlcm0gImFnZW50IiBpcyB1bmRlZmlu
ZWQgYW5kIGFzIGNvLWF1dGhvcnMgd2UgdGhpbmsgdGhlIHN0YXRlbWVudCB3YXMNCm1vcmUgY29y
cmVjdCBhcyBpcy4gIEluIGFueSBjYXNlLCB0aGUgbGFuZ3VhZ2UgaGVyZSBpcyB1bmNoYW5nZWQg
ZnJvbSBSRkMgNDM5NSwNCmFuZCBzbyB3YXMga2VwdCBhcyBpdCBhcHBlYXJlZCBpbiBSRkMgNDM5
NSwgbGFja2luZyBjb25zZW5zdXMgdG8gY2hhbmdlLg0KDQo+IFNlY3Rpb24gNy4yOg0KPiANCj4g
IiA4LiBPbmNlIEV4cGVydCBSZXZpZXcgYXBwcm92ZXMgcmVnaXN0cmF0aW9uIGZvciBhIGdpdmVu
IHN0YXR1cywgSUFOQQ0KPiBhZGRzIHRoZSByZWdpc3RyYXRpb24gdG8gdGhlIHJlZ2lzdHJ5LiIN
Cj4gDQo+IEkgbm90ZSB0aGF0IHRoZSBzY2hlbWUgaGFzIGFscmVhZHkgYmVlbiBhZGRlZCB0byB0
aGUgcmVnaXN0cnkgYXQgcHJpb3Igc3RlcCAzLg0KPiANCj4gU3VnZ2VzdDoNCj4gDQo+ICIgOC4g
T25jZSBFeHBlcnQgUmV2aWV3IGFwcHJvdmVzIHJlZ2lzdHJhdGlvbiBmb3IgYSBnaXZlbiBzdGF0
dXMsIElBTkENCj4gdXBkYXRlcyB0aGUgcmVnaXN0cmF0aW9uIChwZXIgc3RlcCAzKSB0byBpbmRp
Y2F0ZSB0aGUgYXBwcm92ZWQgc3RhdHVzLiAiDQoNCkRvbmUuDQogDQo+IFNlY3Rpb24gODoNCj4g
DQo+IEkgd2FzIHNvbWV3aGF0IHRocm93biBieSB0aGUgaGVhZGluZyBvZiBzZWN0aW9uIDguMS4N
Cj4gDQo+ICI4LjEuICJFeGFtcGxlIiBTY2hlbWUgUmVnaXN0cmF0aW9uIFJlcXVlc3QiDQo+IA0K
PiBJIHRoaW5rIHRoZSBpbnRlbnQgd291bGQgYmUgY2xlYXJlciBpZiB0aGUgc2VjdGlvbiB0aXRs
ZSB3ZXJlIGdpdmVuIGFzOg0KPiANCj4gIjguMS4gIkV4YW1wbGUiIFNjaGVtZSBSZWdpc3RyYXRp
b24gVGVtcGxhdGUiDQoNCk5vdCBkb25lLiAgVGhlIHRlcm0gInRlbXBsYXRlIiBpcyBkZWZpbmVk
IGluIHNlY3Rpb24gMiBhcyBiZWluZyB0aGUNCih1bmZpbGxlZCkgZm9ybS4gICBUaGUgdGVybSAi
cmVnaXN0cmF0aW9uIHJlcXVlc3QiIGlzIGRlZmluZWQgaW4gdGhlIGRvYw0KYXMgYmVpbmcgdGhl
IGNvbXBsZXRlZCBmb3JtIHRoYXQgZ2V0cyBzdWJtaXR0ZWQuICBUd2Vha2VkIHdvcmRpbmcNCm9m
IHNlY3Rpb24gMiB0byBtYWtlIHRoaXMgZXZlbiBtb3JlIGNsZWFyLg0KDQo+IC0gUmVnYXJkaW5n
IHRoZSBQZW5kaW5nIFJldmlldyBTdGF0dXM6DQo+IA0KPiBTZWN0aW9uIDcuMiwgYSBzdGVwIDMg
c2FpZDoNCj4gDQo+IDMuIE90aGVyd2lzZSwgSUFOQSBlbnRlcnMgdGhlIHJlZ2lzdHJhdGlvbiBy
ZXF1ZXN0IGluIHRoZSBJQU5BDQo+IHJlZ2lzdHJ5LCB3aXRoIHN0YXR1cyBtYXJrZWQgYXMgIlBl
bmRpbmcgUmV2aWV3IiBhbmQgdGhlDQo+IHJlbWFpbmRlciBvZiB0aGlzIHNlY3Rpb24gYXBwbGll
cy4NCj4gDQo+IFF1ZXN0aW9uOiBTaGFsbCBJQU5BIHJlbW92ZSB0aGUgIlBlbmRpbmcgUmV2aWV3
IiBVUkkgc2NoZW1lIGZyb20gdGhlDQo+IHJlZ2lzdHJ5DQo+IGlmIGEgbmV3ICdyZXF1ZXN0ZWQn
IHBlcm1hbmVudCBVUkkgc2NoZW1lIGlzIG5vdCBiZWluZyBhY2NlcHRlZCBhZnRlciBERQ0KPiBy
ZXZpZXdlZCAoc3RlcCA0LzUpPyAgT3IgaXQgaXMgb2theSB0byBrZWVwIHRoZSBQZW5kaW5nIFJl
dmlldyBlbnRyeSBpbiB0aGUNCj4gc3VjaCBzdGF0dXMNCj4gYXMgbG9uZyBhcyBpdCBpcyB1bmRl
ciAiYWRkaXRpb25hbCByZXZpZXcgb3IgZGlzY3Vzc2lvbiI/DQo+IA0KPiBUaGUgc2NoZW1lIG1h
eSBub3QgYmUgYXBwcm92ZWQgZm9yIGl0cyByZXF1ZXN0ZWQgc3RhdHVzLiBJZiBub3QgYWNjZXB0
ZWQsIEkNCj4gaW1hZ2luZSB3b3VsZCB3b3VsZCByZXZlcnQgdG8gInByb3Zpc2lvbmFsIiBzdGF0
dXMgKHdoaWNoIGRvZXMgbm90IHJlcXVpcmUNCj4gYXBwcm92YWwgaWYgaXQgbWVldHMgdGhlIG1p
bmltYWwgY3JpdGVyaWEgc2V0IG91dCkuIEJ1dCBJIGFncmVlIHRoYXQgdGhpcw0KPiBzaG91bGQg
cHJvYmFibHkgYmUgY2xhcmlmaWVkLg0KDQpUaGUgaW50ZW50IHdhcyB0aGF0IGlmIGl0IGlzIHJl
amVjdGVkLCB0aGVuIGl0IG5vIGxvbmdlciBhcHBlYXJzIGluIHRoZSByZWdpc3RyeQ0KKHNhbWUg
YXMgaWYgYSByZWplY3Rpb24gaGFwcGVuZWQgd2l0aCBSRkMgNDM5NSwgbm8gY2hhbmdlIGludGVu
ZGVkKS4gIA0KVXBkYXRlZCBwb2ludCA4IG9mIHRoZSBwcm9jZXNzIHRvIGV4cGxpY2l0bHkgc3Rh
dGUgdGhpcy4NCg0KRGF2ZQ0K


From nobody Thu Apr  2 12:02:34 2015
Return-Path: 
X-Original-To: expand-draft-ietf-appsawg-uri-scheme-reg.all@virtual.ietf.org
Delivered-To: apps-discuss@ietfa.amsl.com
Received: by ietfa.amsl.com (Postfix, from userid 65534) id 4E41B1A1B5D; Thu,  2 Apr 2015 12:02:29 -0700 (PDT)
X-Original-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com
Delivered-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B4D01A1A70; Thu,  2 Apr 2015 12:02:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.902
X-Spam-Level: 
X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nduYbUfl6CeQ; Thu,  2 Apr 2015 12:02:27 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0751.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:751]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB98A1A1B5D; Thu,  2 Apr 2015 12:02:05 -0700 (PDT)
Received: from BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) by BY2PR03MB411.namprd03.prod.outlook.com (10.141.141.22) with Microsoft SMTP Server (TLS) id 15.1.130.12; Thu, 2 Apr 2015 19:01:50 +0000
Received: from BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) by BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) with mapi id 15.01.0130.020; Thu, 2 Apr 2015 19:01:50 +0000
From: Dave Thaler 
To: "drafts-expert-review@iana.org" 
Thread-Topic: [IANA #812412] Expert Review - draft-ietf-appsawg-uri-scheme-reg-04
Thread-Index: AQHQYBLgskoDp2Jf6ky4uqKxp9O/2506LLCg
Date: Thu, 2 Apr 2015 19:01:50 +0000
Message-ID: 
References:   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:4898:80e0:ee43::5]
authentication-results: iana.org; dkim=none (message not signed) header.d=none;
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB411;
x-microsoft-antispam-prvs: 
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(13464003)(51704005)(51914003)(377454003)(77096005)(46102003)(77156002)(122556002)(74316001)(19580395003)(106116001)(110136001)(2351001)(62966003)(76576001)(102836002)(19580405001)(54356999)(2501003)(87936001)(50986999)(2656002)(86362001)(33656002)(99286002)(230783001)(76176999)(2950100001)(92566002)(2900100001)(86612001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB411; H:BY2PR03MB412.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:BY2PR03MB411; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB411; 
x-forefront-prvs: 0534947130
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.onmicrosoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Apr 2015 19:01:50.6092 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB411
Archived-At: 
Cc: "appsawg-chairs@ietf.org" , "draft-ietf-appsawg-uri-scheme-reg.all@ietf.org" , "iesg@ietf.org" , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] [IANA #812412] Expert Review - draft-ietf-appsawg-uri-scheme-reg-04
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 02 Apr 2015 19:02:29 -0000

VGhhbmtzIGZvciB0aGUgcmV2aWV3LiAgQmVsb3cgaXMgd2hhdCB0aGUgY28tYXV0aG9ycyBkaWQg
aW4gcmVzcG9uc2UgaW4gLTA1Og0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZy
b206IFBlYXJsIExpYW5nIHZpYSBSVCBbbWFpbHRvOmRyYWZ0cy1leHBlcnQtcmV2aWV3QGlhbmEu
b3JnXQ0KPiBTZW50OiBNb25kYXksIE1hcmNoIDE2LCAyMDE1IDEwOjU5IEFNDQo+IENjOiBkcmFm
dC1pZXRmLWFwcHNhd2ctdXJpLXNjaGVtZS1yZWcuYWxsQGlldGYub3JnOyBhcHBzYXdnLWNoYWly
c0BpZXRmLm9yZzsNCj4gYXBwcy1kaXNjdXNzQGlldGYub3JnOyBpZXNnQGlldGYub3JnDQo+IFN1
YmplY3Q6IFtJQU5BICM4MTI0MTJdIEV4cGVydCBSZXZpZXcgLSBkcmFmdC1pZXRmLWFwcHNhd2ct
dXJpLXNjaGVtZS1yZWctMDQNCj4gDQo+IERlYXIgQXV0aG9ycywNCj4gDQo+IFVwb24gcmV2aWV3
LCBHcmFoYW0gS2x5bmUgaGFzIGFwcHJvdmVkIHRoZSByZXF1ZXN0ZWQgbmV3IFVSSSBzY2hlbWUg
YW5kDQo+IHJhaXNlZCBzb21lIGNvbW1lbnRzIGFuZCBxdWVzdGlvbjoNCj4gDQo+IC4uLg0KPiAN
Cj4gSSdtIGFsc28gdGFraW5nIHRoaXMgb3Bwb3J0dW5pdHkgdG8gcmV2aWV3IHRoZSBjdXJyZW50
IHZlcnNpb24gYW5kIG1ha2Ugc29tZQ0KPiBmaW5hbCBjb21tZW50cy4gVGhlc2UgYXJlIHByZXR0
eSBtdWNoIGFsbCBlZGl0b3JpYWwsIGFuZCBJJ20gYXNzdW1pbmcgdGhleQ0KPiBjb3VsZCBiZSBh
ZGRyZXNzZWQgKG9yIG5vdCkgaW4gYW55IEFVVEg0OCBwZXJpb2Qgd2l0aG91dCByZXF1aXJpbmcg
ZnVydGhlcg0KPiBwdWJsaWMgcmV2aWV3Lg0KPiANCj4gDQo+IFNlY3Rpb24gMy4NCj4gDQo+ICJG
b3IgSUVURiBTdGFuZGFyZHMtVHJhY2sgZG9jdW1lbnRzLCBQZXJtYW5lbnQgcmVnaXN0cmF0aW9u
IHN0YXR1cyBpcw0KPiBSRVFVSVJFRC4iDQo+IFJlYWRpbmcgdGhpcyBub3csIEkgZmluZCB0aGUg
ZHJhZnRpbmcgaGVyZSBpcyBwb3RlbnRpYWxseSBjb25mdXNpbmcuIFN1Z2dlc3Q6DQo+IA0KPiAi
Rm9yIFVSSSBzY2hlbWVzIGRlZmluZWQgb3Igbm9ybWF0aXZlbHkgcmVmZXJlbmNlZCBieSBJRVRG
IFN0YW5kYXJkcy1UcmFjaw0KPiBkb2N1bWVudHMsIFBlcm1hbmVudCByZWdpc3RyYXRpb24gc3Rh
dHVzIGlzIFJFUVVJUkVELiINCg0KVGhpcyB3YXMgdGhlIHN1YmplY3Qgb2YgdGhlIHJlc3Qgb2Yg
dGhpcyB0aHJlYWQsIHdpdGggY29tbWVudHMgZnJvbSB0aGUgQUQsDQp0aGUgZG9jIHNoZXBoZXJk
LCBjby1hdXRob3JzLCBhbmQgb3RoZXIgV0cgcGFydGljaXBhbnRzLg0KDQpXZSB0aG91Z2h0IHRo
ZSBjb25jZW5zdXMgd2FzIHRvIGFjY2VwdCB0aGlzIGFuZCBzbyBtYWRlIHRoZSBjaGFuZ2UuDQoo
SSBzZWUgdGhpcyBkaXNjdXNzaW9uIGNvbnRpbnVlcyByZWdhcmRpbmcgLTA1Li4uKQ0KDQo+IFNl
Y3Rpb24gMy4zDQo+IA0KPiAiU2NoZW1lcyB0aGF0IGFyZSBub3QgaW50ZW5kZWQgdG8gYmUgdXNl
ZCBhcyBsb2NhdG9ycyBTSE9VTEQgZGVzY3JpYmUgaG93DQo+IHRoZQ0KPiByZXNvdXJjZSBpZGVu
dGlmaWVkIGNhbiBiZSBkZXRlcm1pbmVkIG9yIGFjY2Vzc2VkIGJ5IHNvZnR3YXJlIHRoYXQgb2J0
YWlucyBhDQo+IFVSSQ0KPiBvZiB0aGF0IHNjaGVtZS4iDQo+IA0KPiBUaGlzIGRvZXNuJ3Qgc2Vl
bSBxdWl0ZSByaWdodCB0byBtZS4gU2NoZW1lcyB0aGF0IGFyZSBub3QgaW50ZW5kZWQgdG8gYmUN
Cj4gdXNlZA0KPiBhcyBsb2NhdG9ycyBhcmVuJ3QgZ2VuZXJhbGx5IGV4cGVjdGVkIHRvIGJlIGFj
Y2Vzc2VkIGJ5IHNvZnR3YXJlICh0aG91Z2ggdGhleQ0KPiBtYXkgYmUgaW4gcGFydGljdWxhciBj
aXJjdW1zdGFuY2VzKS4NCj4gDQo+IEkgdGhpbmsgdGhlbiBwb2ludCB0aGF0IG5lZWRzIHRvIGJl
IG1hZGUgaGVyZSBpcyB0aGF0IHRoZXJlIHNob3VsZCBiZSBzb21lDQo+IGRlZmluZWQgc3RydWN0
dXJlIG9mIG5hbWluZyBhdXRob3JpdHkgZm9yIHRoZSBzY2hlbWUsIHdoaWNoIGlzIG5vdCBuZWNl
c3NhcmlseQ0KPiBpbnRlcnByZXRhYmxlIGJ5IHNvZnR3YXJlLiBFLmcuLCBzb21ldGhpbmcgbGlr
ZToNCj4gDQo+ICJTY2hlbWVzIHRoYXQgYXJlIG5vdCBpbnRlbmRlZCB0byBiZSB1c2VkIGFzIGxv
Y2F0b3JzIFNIT1VMRCBkZXNjcmliZSBob3cNCj4gdGhlDQo+IHJlc291cmNlIGlkZW50aWZpZWQg
Y2FuIGJlIGRldGVybWluZWQgb3IgYWNjZXNzZWQgYnkgYW4gYWdlbnQgdGhhdCBvYnRhaW5zIGEN
Cj4gVVJJDQo+IG9mIHRoYXQgc2NoZW1lLiINCg0KVGhlIHRlcm0gImFnZW50IiBpcyB1bmRlZmlu
ZWQgYW5kIGFzIGNvLWF1dGhvcnMgd2UgdGhpbmsgdGhlIHN0YXRlbWVudCB3YXMNCm1vcmUgY29y
cmVjdCBhcyBpcy4gIEluIGFueSBjYXNlLCB0aGUgbGFuZ3VhZ2UgaGVyZSBpcyB1bmNoYW5nZWQg
ZnJvbSBSRkMgNDM5NSwNCmFuZCBzbyB3YXMga2VwdCBhcyBpdCBhcHBlYXJlZCBpbiBSRkMgNDM5
NSwgbGFja2luZyBjb25zZW5zdXMgdG8gY2hhbmdlLg0KDQo+IFNlY3Rpb24gNy4yOg0KPiANCj4g
IiA4LiBPbmNlIEV4cGVydCBSZXZpZXcgYXBwcm92ZXMgcmVnaXN0cmF0aW9uIGZvciBhIGdpdmVu
IHN0YXR1cywgSUFOQQ0KPiBhZGRzIHRoZSByZWdpc3RyYXRpb24gdG8gdGhlIHJlZ2lzdHJ5LiIN
Cj4gDQo+IEkgbm90ZSB0aGF0IHRoZSBzY2hlbWUgaGFzIGFscmVhZHkgYmVlbiBhZGRlZCB0byB0
aGUgcmVnaXN0cnkgYXQgcHJpb3Igc3RlcCAzLg0KPiANCj4gU3VnZ2VzdDoNCj4gDQo+ICIgOC4g
T25jZSBFeHBlcnQgUmV2aWV3IGFwcHJvdmVzIHJlZ2lzdHJhdGlvbiBmb3IgYSBnaXZlbiBzdGF0
dXMsIElBTkENCj4gdXBkYXRlcyB0aGUgcmVnaXN0cmF0aW9uIChwZXIgc3RlcCAzKSB0byBpbmRp
Y2F0ZSB0aGUgYXBwcm92ZWQgc3RhdHVzLiAiDQoNCkRvbmUuDQogDQo+IFNlY3Rpb24gODoNCj4g
DQo+IEkgd2FzIHNvbWV3aGF0IHRocm93biBieSB0aGUgaGVhZGluZyBvZiBzZWN0aW9uIDguMS4N
Cj4gDQo+ICI4LjEuICJFeGFtcGxlIiBTY2hlbWUgUmVnaXN0cmF0aW9uIFJlcXVlc3QiDQo+IA0K
PiBJIHRoaW5rIHRoZSBpbnRlbnQgd291bGQgYmUgY2xlYXJlciBpZiB0aGUgc2VjdGlvbiB0aXRs
ZSB3ZXJlIGdpdmVuIGFzOg0KPiANCj4gIjguMS4gIkV4YW1wbGUiIFNjaGVtZSBSZWdpc3RyYXRp
b24gVGVtcGxhdGUiDQoNCk5vdCBkb25lLiAgVGhlIHRlcm0gInRlbXBsYXRlIiBpcyBkZWZpbmVk
IGluIHNlY3Rpb24gMiBhcyBiZWluZyB0aGUNCih1bmZpbGxlZCkgZm9ybS4gICBUaGUgdGVybSAi
cmVnaXN0cmF0aW9uIHJlcXVlc3QiIGlzIGRlZmluZWQgaW4gdGhlIGRvYw0KYXMgYmVpbmcgdGhl
IGNvbXBsZXRlZCBmb3JtIHRoYXQgZ2V0cyBzdWJtaXR0ZWQuICBUd2Vha2VkIHdvcmRpbmcNCm9m
IHNlY3Rpb24gMiB0byBtYWtlIHRoaXMgZXZlbiBtb3JlIGNsZWFyLg0KDQo+IC0gUmVnYXJkaW5n
IHRoZSBQZW5kaW5nIFJldmlldyBTdGF0dXM6DQo+IA0KPiBTZWN0aW9uIDcuMiwgYSBzdGVwIDMg
c2FpZDoNCj4gDQo+IDMuIE90aGVyd2lzZSwgSUFOQSBlbnRlcnMgdGhlIHJlZ2lzdHJhdGlvbiBy
ZXF1ZXN0IGluIHRoZSBJQU5BDQo+IHJlZ2lzdHJ5LCB3aXRoIHN0YXR1cyBtYXJrZWQgYXMgIlBl
bmRpbmcgUmV2aWV3IiBhbmQgdGhlDQo+IHJlbWFpbmRlciBvZiB0aGlzIHNlY3Rpb24gYXBwbGll
cy4NCj4gDQo+IFF1ZXN0aW9uOiBTaGFsbCBJQU5BIHJlbW92ZSB0aGUgIlBlbmRpbmcgUmV2aWV3
IiBVUkkgc2NoZW1lIGZyb20gdGhlDQo+IHJlZ2lzdHJ5DQo+IGlmIGEgbmV3ICdyZXF1ZXN0ZWQn
IHBlcm1hbmVudCBVUkkgc2NoZW1lIGlzIG5vdCBiZWluZyBhY2NlcHRlZCBhZnRlciBERQ0KPiBy
ZXZpZXdlZCAoc3RlcCA0LzUpPyAgT3IgaXQgaXMgb2theSB0byBrZWVwIHRoZSBQZW5kaW5nIFJl
dmlldyBlbnRyeSBpbiB0aGUNCj4gc3VjaCBzdGF0dXMNCj4gYXMgbG9uZyBhcyBpdCBpcyB1bmRl
ciAiYWRkaXRpb25hbCByZXZpZXcgb3IgZGlzY3Vzc2lvbiI/DQo+IA0KPiBUaGUgc2NoZW1lIG1h
eSBub3QgYmUgYXBwcm92ZWQgZm9yIGl0cyByZXF1ZXN0ZWQgc3RhdHVzLiBJZiBub3QgYWNjZXB0
ZWQsIEkNCj4gaW1hZ2luZSB3b3VsZCB3b3VsZCByZXZlcnQgdG8gInByb3Zpc2lvbmFsIiBzdGF0
dXMgKHdoaWNoIGRvZXMgbm90IHJlcXVpcmUNCj4gYXBwcm92YWwgaWYgaXQgbWVldHMgdGhlIG1p
bmltYWwgY3JpdGVyaWEgc2V0IG91dCkuIEJ1dCBJIGFncmVlIHRoYXQgdGhpcw0KPiBzaG91bGQg
cHJvYmFibHkgYmUgY2xhcmlmaWVkLg0KDQpUaGUgaW50ZW50IHdhcyB0aGF0IGlmIGl0IGlzIHJl
amVjdGVkLCB0aGVuIGl0IG5vIGxvbmdlciBhcHBlYXJzIGluIHRoZSByZWdpc3RyeQ0KKHNhbWUg
YXMgaWYgYSByZWplY3Rpb24gaGFwcGVuZWQgd2l0aCBSRkMgNDM5NSwgbm8gY2hhbmdlIGludGVu
ZGVkKS4gIA0KVXBkYXRlZCBwb2ludCA4IG9mIHRoZSBwcm9jZXNzIHRvIGV4cGxpY2l0bHkgc3Rh
dGUgdGhpcy4NCg0KRGF2ZQ0K


From nobody Thu Apr  2 12:05:33 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D0C01A1B5D; Thu,  2 Apr 2015 12:05:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qeUiXPrwjGAP; Thu,  2 Apr 2015 12:05:30 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BD6651A1BAF; Thu,  2 Apr 2015 12:05:28 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
To: , , 
X-Test-IDTracker: no
X-IETF-IDTracker: 5.13.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150402190528.13751.85531.idtracker@ietfa.amsl.com>
Date: Thu, 02 Apr 2015 12:05:28 -0700
From: IETF Secretariat 
Archived-At: 
Subject: [apps-discuss] ID Tracker State Update Notice: 
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 02 Apr 2015 19:05:31 -0000

IANA review state changed to IANA OK - Actions Needed
ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-uri-scheme-reg/


From nobody Thu Apr  2 12:27:32 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 644F81A000B for ; Thu,  2 Apr 2015 12:27:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.602
X-Spam-Level: 
X-Spam-Status: No, score=-103.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, MIME_8BIT_HEADER=0.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5nlXTTcEGRT2 for ; Thu,  2 Apr 2015 12:27:23 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0764.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:764]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4DDB1A0004 for ; Thu,  2 Apr 2015 12:27:22 -0700 (PDT)
Received: from BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) by BY2PR03MB409.namprd03.prod.outlook.com (10.141.141.11) with Microsoft SMTP Server (TLS) id 15.1.130.12; Thu, 2 Apr 2015 19:27:04 +0000
Received: from BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) by BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) with mapi id 15.01.0130.020; Thu, 2 Apr 2015 19:27:04 +0000
From: Dave Thaler 
To: =?utf-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= , "apps-discuss@ietf.org" , Larry Masinter , Ted Hardie , Tony Hansen 
Thread-Topic: Last Call:  (Guidelines and Registration Procedures for URI Schemes) to Best Current Practice
Thread-Index: AQHQXKwMVJ1nESp+pkCQTGWdSKvW5506NdCQ
Date: Thu, 2 Apr 2015 19:27:04 +0000
Message-ID: 
References: <550164DD.6020509@it.aoyama.ac.jp>
In-Reply-To: <550164DD.6020509@it.aoyama.ac.jp>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:4898:80e0:ee43::5]
authentication-results: it.aoyama.ac.jp; dkim=none (message not signed) header.d=none;
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB409;
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(52314003)(51704005)(24454002)(51914003)(99286002)(15975445007)(77096005)(77156002)(2950100001)(2656002)(230783001)(122556002)(92566002)(76576001)(2900100001)(102836002)(62966003)(33656002)(2501003)(87936001)(106116001)(76176999)(50986999)(54356999)(74316001)(46102003)(86612001)(107886001)(19580395003)(86362001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB409; H:BY2PR03MB412.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:BY2PR03MB409; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB409; 
x-forefront-prvs: 0534947130
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.onmicrosoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Apr 2015 19:27:04.2151 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB409
Archived-At: 
Subject: Re: [apps-discuss] Last Call:  (Guidelines and Registration Procedures for URI Schemes) to Best Current Practice
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 02 Apr 2015 19:27:30 -0000

VGhhbmtzIGZvciB0aGUgdGhvcm91Z2ggcmV2aWV3LiAgVGhlIGNvLWF1dGhvcnMgYW5kIGRvYyBz
aGVwaGVyZCBtZXQgaW4NCkRhbGxhcyBhbmQgd2VudCBvdmVyIHRoZXNlLiAgQmVsb3cgaXMgd2hh
dCB3ZSBkaWQgaW4gcmVzcG9uc2UgaW4gZHJhZnQtMDU6DQoNCk1hcnRpbiBKLiBEw7xyc3QiIHdy
b3RlOg0KPiBNeSBvdmVyYWxsIGltcHJlc3Npb24gaXMgdGhhdCB0aGUgb3ZlcmFsbCBkaXJlY3Rp
b24gb2YgdGhlIGRyYWZ0IGlzIGp1c3QgZmluZSwgYnV0DQo+IHRoYXQgcHJlc2VudGF0aW9uIGFu
ZCB3b3JkaW5nIGFyZSBxdWl0ZSByb3VnaCBpbiBtYW55IHBsYWNlcyBhbmQgd291bGQNCj4gdHJl
bWVuZG91c2x5IGJlbmVmaXQgZnJvbSBtb3JlIGNhcmVmdWwgd29yZGluZy4NCj4gDQo+IA0KPiBJ
bnRyb2R1Y3Rpb246IE92ZXJhbGwsIHRoaXMgZmVsdCB0b28gbG9uZywgYW5kIGl0IHdvdWxkIGJl
bmVmaXQgZnJvbSBiZXR0ZXINCj4gc3RydWN0dXJpbmcsIGFuZC9vciBtb3Zpbmcgc29tZSBvZiB0
aGUgcG9pbnRzIG91dCB0byB0aGVpciBvd24NCj4gc2VjdGlvbnMvc3Vic2VjdGlvbnMuIEZvciBl
eGFtcGxlLCBhZGRpbmcgc3Vic2VjdGlvbiB0aXRsZXMgc3VjaCBhcyAiVVJJcyBhbmQNCj4gSVJJ
cyIgYW5kICJHZW5lcmljIFN5bnRheCBhbmQgU2NoZW1lIFNwZWNpZmljIFN5bnRheCIgb3Igc29t
ZSBzdWNoIHdvdWxkDQo+IGhlbHAgcXVpdGUgYSBsb3QuDQoNCkFkZGVkIHN1YnNlY3Rpb24gdGl0
bGVzLg0KDQo+ICIgIG8gIHByb3ZpZGUgYSBjZW50cmFsIHBvaW50IG9mIGRpc2NvdmVyeSBmb3Ig
ZXN0YWJsaXNoZWQgVVJJIHNjaGVtZQ0KPiAgICAgICAgbmFtZXMsIGFuZCBlYXN5IGxvY2F0aW9u
IG9mIGRlZmluaW5nIGRvY3VtZW50cyBmb3Igc3RhbmRhcmQNCj4gICAgICAgIHNjaGVtZXM7Ig0K
PiBUaGUgdXNlIG9mIHRoZSB3b3JkICJzdGFuZGFyZCIgaW4gInN0YW5kYXJkIHNjaGVtZSIgaXMg
dW5jbGVhci4gVGhpcyB1c2UNCj4gZG9lc24ndCBhcHBlYXIgYW55d2hlcmUgaW4gdGhlIGRvY3Vt
ZW50LiBEbyB5b3UgbWVhbiBwZXJtYW5lbnRseQ0KPiByZWdpc3RlcmVkIHNjaGVtZXM/IElmIHRo
ZXJlJ3Mgc29tZSBzcGVjaWZpYyBwb2ludCB0byBiZSBtYWRlLCBwbGVhc2UgbWFrZSBpdA0KPiBt
b3JlIGNsZWFybHkuIE90aGVyd2lzZSwgSSBzdWdnZXN0IHRvIGp1c3QgZHJvcCB0aGUgd29yZCAi
c3RhbmRhcmQiLg0KDQpBZ3JlZWQsIGRyb3BwZWQgdGhlIHdvcmQgInN0YW5kYXJkIi4NCg0KPiAi
byAgZGlzY291cmFnZSBtdWx0aXBsZSBzZXBhcmF0ZSB1c2VzIG9mIHRoZSBzYW1lIHNjaGVtZSBu
YW1lOyINCj4gSSdkIHBlcnNvbmFsbHkgYmUgaGFwcGllciBpZiB0aGlzIHNhaWQgInN0cm9uZ2x5
IGRpc2NvdXJhZ2UiLCBiZWNhdXNlIEkgaG9wZSB3ZQ0KPiBhbGwgYWdyZWUgdGhhdCBpdCdzIHJl
YWxseSBub3QgYSBnb29kIGlkZWEuIElmIHRoZSBjb25zZW5zdXMgaXMgdGhhdCBpdCdzIG9idmlv
dXMNCj4gYW55d2F5IHRoYXQgaXQncyByZWFsbHkgbm90IGEgZ29vZCBpZGVhLCBhbmQgd2UgZG9u
J3QgbmVlZCB0byBiZSBvdmVybHkgY2xlYXINCj4gYWJvdXQgdGhhdCwgdGhlbiBJJ2xsIGtlZXAg
cXVpZXQuDQoNCldlIGJlbGlldmUgaXQncyBvYnZpb3VzIGFueXdheSBmcm9tIHRoZSBjdXJyZW50
IHRleHQuDQogDQo+ICJvICBlbmNvdXJhZ2UgcmVnaXN0cmF0aW9uIGJ5IHNldHRpbmcgYSBsb3cg
YmFycmllciBmb3IgcmVnaXN0cmF0aW9uLiINCj4gV2hhdCBhYm91dCBtYWtpbmcgdGhpcyAiZW5j
b3VyYWdlIGVhcmx5IHJlZ2lzdHJhdGlvbiI/DQoNCk5vLCB0aGF0IHdvdWxkIGhhdmUgYSBkaWZm
ZXJlbnQgbWVhbmluZy4gIFRoZSBtYWluIHByb2JsZW0gd2l0aCBwcm92aXNpb25hbA0KdG9kYXkg
aXMgbGFjayBvZiByZWdpc3RyYXRpb24gKmF0IGFsbCouICAgVGhlIGdvYWwgaXMgdG8gbG93ZXIg
dGhlIGJhciBzbyB0aGF0DQp3ZSBhY3R1YWxseSBnZXQgbW9yZSBvZiB0aGVtIHJhdGhlciB0aGFu
IHNxdWF0dGluZywgdGhlIGNvbW1vbiBjYXNlIHRvZGF5Lg0KIA0KPiAiQSBVUkkgc2NoZW1lIG5h
bWUgaXMgdGhlIHNhbWUgYXMgdGhlIGNvcnJlc3BvbmRpbmcgSVJJIHNjaGVtZSBuYW1lLiINCj4g
QXQgdGhlIG1pbmltdW0sIEknZCB0dXJuIHRoaXMgYXJvdW5kIGFuZCBzYXkgIkFuIElSSSBzY2hl
bWUgbmFtZSBpcyB0aGUNCj4gc2FtZSBhcyB0aGUgY29ycmVzcG9uZGluZyBVUkkgc2NoZW1lIG5h
bWUuIiBCdXQgYmVjYXVzZSB0aGUgdGhlcmUgaXNuJ3QNCj4gcmVhbGx5IGFueXRoaW5nIGxpa2Ug
YW4gIklSSSBzY2hlbWUgbmFtZSIsIEknZCBhY3R1YWxseSBwcmVmZXIgaWYgdGhpcyBzYWlkICJJ
UklzDQo+IHVzZSB0aGUgc2FtZSBzY2hlbWUgbmFtZXMgYXMgVVJJcy4iIG9yIHNvbWV0aGluZyBz
aW1pbGFyLg0KDQpEb25lLg0KIA0KPiAiRm9yIGV4YW1wbGUsIHRoaXMgbWVhbnMgdGhhdCBmcmFn
bWVudCBpZGVudGlmaWVycyAoIykgY2Fubm90IGJlIHJlLXVzZWQNCj4gb3V0c2lkZSB0aGUgZ2Vu
ZXJpYyBzeW50YXggcmVzdHJpY3Rpb25zLiINCj4gTXkgJ2Jlc3QtZ3Vlc3MnIGludGVycHJldGF0
aW9uIG9mIHRoaXMgc2VudGVuY2UgaXMgdGhhdCB0aGlzIGludGVuZGVkIHRvIHNheQ0KPiB0aGF0
IGEgc2NoZW1lIGRlZmluaXRpb24gY2Fubm90IGRlZmluZSBmcmFnbWVudHMgdGhhdCBjb250YWlu
IGNoYXJhY3RlcnMgKGUuZy4NCj4gIykgdGhhdCBSRkMgMzk4NiBkb2Vzbid0IGFsbG93Lg0KDQpD
b3JyZWN0Lg0KIA0KPiBCdXQgdGhpcyBpcyBiYWQgYWR2aWNlLCBiZWNhdXNlIHNjaGVtZSBkZWZp
bml0aW9ucyBjYW5ub3Qgc2F5IGFueXRoaW5nIGFib3V0DQo+IGZyYWdtZW50cyBhdCBhbGwuIFRo
aXMgaXNuJ3Qgc3ludGF4LCBidXQgc2VtYW50aWNzOyB0aGUgc2VtYW50aWNzIG9mIGEgZnJhZ21l
bnQNCj4gYXJlIGRlZmluZWQgYnkgdGhlIG1lZGlhIHR5cGUsIG5vdCB0aGUgc2NoZW1lLiBJIGhh
dmVuJ3QgZm91bmQgYW55IHBsYWNlDQo+IGFueXdoZXJlIGluIHRoaXMgZG9jIHRoYXQgc2F5cyB0
aGlzLCBpdCBjbGVhcmx5IHNob3VsZCBiZSBhZGRlZC4NCj4NCj4gSWYgeW91IHdhbnQgdG8gbWFr
ZSBhbiBleGFtcGxlIHJlLiBzeW50YXgsIEknZCBzdWdnZXN0IHRvIHNheSBzb21ldGhpbmcgbGlr
ZQ0KPiAiRm9yIGV4YW1wbGUsIHRoZSBxdWVyeSBwYXJ0IGNhbm5vdCBjb250YWluIGxpdGVyYWwg
JyMnIGNoYXJhY3RlcnMgYmVjYXVzZSB0aGV5DQo+IGFuZCBhbnl0aGluZyBhZnRlciB0aGVtIHdv
dWxkIGJlIGludGVycHJldGVkIGFzIHBhcnQgb2YgdGhlIGZyYWdtZW50IGFuZA0KPiBub3QgdGhl
IHF1ZXJ5LiIgb3Igc29tZSBzdWNoLg0KPiANCj4gQWxzbywgdGhlICIoIykiIGluIHRoZSB0ZXh0
IGlzIGNvbXBsZXRlbHkgc3VwZXJmbHVvdXM7IHRoZSAnIycgaXRzZWxmIGlzbid0IHRoZQ0KPiBm
cmFnbWVudCwgYW5kIGEgcmVhZGVyIHNob3VsZCBiZSBhYmxlIHRvIGNvcnJlbGF0ZSB0aGUgd29y
ZCBpbiB0aGUgdGV4dCBhbmQNCj4gdGhlIHNhbWUgd29yZCBpbiB0aGUgQUJORi4NCg0KVXBkYXRl
ZCB0byByZWFkOg0KIiBGb3IgZXhhbXBsZSwgdGhpcyBtZWFucyB0aGF0IGZyYWdtZW50IGlkZW50
aWZpZXJzIGNhbm5vdCBiZSByZS11c2VkDQogICBvdXRzaWRlIHRoZSBnZW5lcmljIHN5bnRheCBy
ZXN0cmljdGlvbnMsIGFuZCBmcmFnbWVudCBpZGVudGlmaWVycyBhcmUNCiAgIG5vdCBzY2hlbWUt
c3BlY2lmaWMuIg0KDQo+ICJBIHNjaGVtZSBkZWZpbml0aW9uIG11c3Qgc3BlY2lmeSB0aGUgc2No
ZW1lIG5hbWUgYW5kIHRoZSBzeW50YXggb2YgdGhlDQo+IHNjaGVtZS1zcGVjaWZpYyBwYXJ0LCB3
aGljaCBpcyBjbGFyaWZpZWQgYXMgZm9sbG93czoiDQo+IFNheWluZyAiY2xhcmlmaWVkIGFzIGZv
bGxvd3MiIGFuZCB0aGVuIGp1c3QgZ2l2aW5nIHNvbWUgQUJORiBtYXkgYmUgZGlmZmljdWx0DQo+
IHRvIGdyb2sgZm9yIHNvbWUgcGVvcGxlLiBJIHByb3Bvc2UgdG8gY2hhbmdlIHRoZSBzZW50ZW5j
ZSB0byAiQSBzY2hlbWUNCj4gZGVmaW5pdGlvbiBtdXN0IHNwZWNpZnkgdGhlIHNjaGVtZSBuYW1l
IGFuZCB0aGUgc3ludGF4IG9mIHRoZSBzY2hlbWUtDQo+IHNwZWNpZmljIHBhcnQsIHdoaWNoIGNv
cnJlc3BvbmRzIHRvIHRoZSAnaGllci1wYXJ0JyBhbmQgdGhlIG9wdGlvbmFsIHF1ZXJ5IGluDQo+
IHRoZSBhYm92ZSBkZWZpbml0aW9uLiBUaGlzIGNhbiBiZSBjbGFyaWZpZWQgYnkgcmV3cml0aW5n
IHRoZSBkZWZpbml0aW9uIGFzDQo+IGZvbGxvd3M6Ig0KDQpXZSB0aG91Z2h0IGl0J3MgYWxyZWFk
eSBvYnZpb3VzIGVub3VnaCBhbmQgc3VjaCBhIGNoYW5nZSBtaWdodCBtYWtlIGl0DQpoYXJkZXIg
dG8gcmVhZC4gIFNpbmNlIHlvdSBzYWlkIGl0ICJtYXkiIGJlIGRpZmZpY3VsdCB0byBncm9rLCB3
ZSBkaWRuJ3QgdGFrZSB0aGlzDQphcyBhIG11c3QtY2hhbmdlLg0KIA0KPiAyLiBUZXJtaW5vbG9n
eToNCj4gDQo+ICAgICBXaXRoaW4gdGhpcyBkb2N1bWVudCwgdGhlIGtleSB3b3JkcyBNVVNULCBN
QVksIFNIT1VMRCwgUkVRVUlSRUQsDQo+ICAgICBSRUNPTU1FTkRFRCwgYW5kIHNvIGZvcnRoIGFy
ZSB1c2VkIHdpdGhpbiB0aGUgZ2VuZXJhbCBtZWFuaW5ncw0KPiAgICAgZXN0YWJsaXNoZWQgaW4g
W1JGQzIxMTldLCB3aXRoaW4gdGhlIGNvbnRleHQgdGhhdCB0aGV5IGFyZQ0KPiAgICAgcmVxdWly
ZW1lbnRzIG9uIGZ1dHVyZSByZWdpc3RyYXRpb25zLg0KPiBUaGUgZG91YmxlICd3aXRoaW4nIGlz
IGNvbmZ1c2luZy4gSSBwcm9wb3NlIHRvIHJlcGxhY2UgIndpdGhpbiB0aGUgY29udGV4dCB0aGF0
DQo+IHRoZXkgYXJlIHJlcXVpcmVtZW50cyBvbiBmdXR1cmUgcmVnaXN0cmF0aW9ucyIgd2l0aCAi
YXMgcmVxdWlyZW1lbnRzIG9uDQo+IGZ1dHVyZSByZWdpc3RyYXRpb25zIg0KDQpEb25lLg0KIA0K
PiAzLiAgUmVxdWlyZW1lbnRzIGZvciBQZXJtYW5lbnQgU2NoZW1lIERlZmluaXRpb25zDQo+IA0K
PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgRm9yDQo+ICAgICBJRVRGIFN0YW5kYXJkcy1UcmFjayBkb2N1bWVudHMs
IFBlcm1hbmVudCByZWdpc3RyYXRpb24gc3RhdHVzIGlzDQo+ICAgICBSRVFVSVJFRC4NCj4gUGxl
YXNlIGNoYW5nZSB0aGlzIHRvOiAiRm9yIFVSSSBTY2hlbWUgZGVmaW5pdGlvbnMgaW4gSUVURiBT
dGFuZGFyZHMtVHJhY2sNCj4gZG9jdW1lbnRzLCBQZXJtYW5lbnQgcmVnaXN0cmF0aW9uIHN0YXR1
cyBpcyBSRVFVSVJFRC4iDQoNCkRvbmUuDQoNCj4gMy4yLiBTeW50YWN0aWMgQ29tcGF0aWJpbGl0
eQ0KPiANCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBDYXJl
IG11c3QgYmUgdGFrZW4gdG8gZW5zdXJlDQo+ICAgICB0aGF0IGFsbCBzdHJpbmdzIG1hdGNoaW5n
IHRoZWlyIHNjaGVtZS1zcGVjaWZpYyBzeW50YXggd2lsbCBhbHNvDQo+ICAgICBtYXRjaCB0aGUg
PGFic29sdXRlLVVSST4gZ3JhbW1hciBkZXNjcmliZWQgaW4gW1JGQzM5ODZdLg0KPiANCj4gUHJv
bm91bnMgbGlrZSAidGhlaXIiIGRvbid0IHVzdWFsbHkgd29yayB3ZWxsIGluIHN0YW5kYXJkIGxh
bmd1YWdlLiBJDQo+IHN1Z2dlc3QgY2hhbmdpbmcgInRoZWlyIHNjaGVtZS1zcGVjaWZpYyBzeW50
YXgiIHRvICJ0aGUgc3ludGFjdGljDQo+IHJlc3RyaWN0aW9ucyBvZiB0aGUgc2NoZW1lIGRlZmlu
aXRpb24iIG9yIHNvbWUgc3VjaC4NCg0KVGhpcyB0ZXh0IGlzIHVuY2hhbmdlZCBmcm9tIFJGQyA0
Mzk1LiAgSG93ZXZlciwgd2UgYmVsaWV2ZSB0aGUgUkZDIGVkaXRvcg0KaGFzIHNwZWNpZmljIHN0
eWxpc3QgcHJlZmVyZW5jZXMgaW4gdGhpcyBhcmVhIHRoYXQgdGhleSBvZnRlbiBjaGFuZ2UgYW55
d2F5LA0KYW5kIHNvIHdlIGRlZmVyIHRvIHRoZSBSRkMgZWRpdGluZyBwYXNzIHRvIGhhbmRsZSBk
dXJpbmcgQVVUSDQ4Lg0KDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBJZiB0aGVyZSBpcyBhIHN0cm9uZw0KPiAgICAgcmVhc29uIGZvciBhIHNj
aGVtZSBub3QgdG8gdXNlIHRoZSBoaWVyYXJjaGljYWwgc3ludGF4LCB0aGVuIHRoZSBuZXcNCj4g
ICAgIHNjaGVtZSBkZWZpbml0aW9uIFNIT1VMRCBmb2xsb3cgdGhlIHN5bnRheCBvZiBwcmV2aW91
c2x5IHJlZ2lzdGVyZWQNCj4gICAgIHNjaGVtZXMuDQo+IA0KPiBQbGVhc2UgY2hhbmdlICJ0aGUg
c3ludGF4IG9mIHByZXZpb3VzbHkgcmVnaXN0ZXJlZCBzY2hlbWVzIiB0byAidGhlDQo+IHN5bnRh
eCBvZiBwcmV2aW91c2x5IHJlZ2lzdGVyZWQgc2NoZW1lcyB3aXRoIHNpbWlsYXIgY29tcG9uZW50
cyBvcg0KPiBzaW1pbGFyIHN5bnRhY3RpYyBuZWVkcy4iIG9yIHNvbWUgc3VjaCwgdG8gbWFrZSBp
dCBjbGVhciB0aGF0IGl0J3Mgbm90DQo+IHN1ZmZpY2llbnQgdG8ganVzdCBjb3B5IHNvbWUgc3lu
dGF4IGlmIGl0J3MgdG90YWxseSB1bnJlbGF0ZWQuDQoNCkFkZGVkICJzaW1pbGFyIi4NCg0KPiAg
ICAgU2NoZW1lcyB0aGF0IGFyZSBub3QgaW50ZW5kZWQgZm9yIHVzZSB3aXRoIHJlbGF0aXZlIFVS
SXMgU0hPVUxEIGF2b2lkDQo+ICAgICB1c2Ugb2YgdGhlIGZvcndhcmQgc2xhc2ggIi8iIGNoYXJh
Y3Rlciwgd2hpY2ggaXMgdXNlZCBmb3INCj4gICAgIGhpZXJhcmNoaWNhbCBkZWxpbWl0ZXJzLCBh
bmQgdGhlIGNvbXBsZXRlIHBhdGggc2VnbWVudHMgIi4iIGFuZCAiLi4iDQo+ICAgICAoZG90LXNl
Z21lbnRzKS4NCj4gSXQgd291bGQgYmUgZ29vZCBpZiB0aGUgdGV4dCBnYXZlIHRoZSByZWFzb25z
IGZvciB0aGUgU0hPVUxEICh3aGljaCBJDQo+IGZ1bGx5IGFncmVlIHdpdGg7IG1heWJlIGV2ZW4g
YSBNVVNUKS4NCg0KUmV3b3JkZWQgYXMgDQoiLi4uIG9yZGVyIHRvIGF2b2lkIHVuaW50ZW5kZWQg
cHJvY2Vzc2luZyBzdWNoIGFzIHJlc29sdXRpb24gb2YgIi4iIGFuZCAiLi4iIChkb3Qtc2VnbWVu
dHMpLiINCg0KPiBQbGVhc2UgYWRkIGEobiBpbmZvcm1hdGlvbmFsKSByZWZlcmVuY2UgdG8gR2V0
dHlzLCBKLiwgIlVSSSBNb2RlbA0KPiBDb25zZXF1ZW5jZXMiLCA8aHR0cDovL3d3dy53My5vcmcv
RGVzaWduSXNzdWVzL01vZGVsQ29uc2VxdWVuY2VzPiBpbg0KPiB0aGlzIHNlY3Rpb24uIEl0IGlz
IGEgZ3JlYXQgdGV4dCBoZWxwaW5nIGRlc2lnbmVycyBvZiBVUkkgc2NoZW1lIHN5bnRheA0KPiB0
byB1bmRlcnN0YW5kIHRoZSBpZGVhcyByZWdhcmRpbmcgdGhlIGRpZmZlcmVudCBzeW50YXggY29t
cG9uZW50cy4NCg0KVGhhdCByZWZlcmVuY2UgaXMgbm90IHBvc2l0aW9uZWQgYXMgYSBjb25zZW5z
dXMgc3RhdGVtZW50IGFuZCBhY3R1YWxseQ0KbWFrZXMgd2Vha2VyIHJlY29tbWVuZGF0aW9ucyB0
aGFuIGluIHRoaXMgZG9jdW1lbnQuICAgQXMgc3VjaCwgd2UgdGhvdWdodA0KaXQgbWlnaHQgYWRk
IGNvbmZ1c2lvbiBpZiBpdCB3ZXJlIHJlZmVyZW5jZWQuICAgV2hpbGUgaXQgbWF5IGJlIGEgZ29v
ZCByZWZlcmVuY2UNCmZvciBzb21lIHB1cnBvc2VzLCB3ZSBkZWNpZGVkIHRoYXQgY2l0aW5nIGl0
IHdhcyBub3QgbmVjZXNzYXJ5Lg0KIA0KPiAgICAgTmV3IHNjaGVtZXMgU0hPVUxEIGNsZWFybHkg
ZGVmaW5lIHRoZSByb2xlIG9mIFtSRkMzOTg2XSByZXNlcnZlZA0KPiAgICAgY2hhcmFjdGVycyBp
biBVUklzIG9mIHRoZSBzY2hlbWUgYmVpbmcgZGVmaW5lZC4NCj4gVGhlIGxvY2F0aW9uIG9mIFtS
RkMzOTg2XSBpcyBhIGJpdCBzdHJhbmdlLiBJdCBtaWdodCB3b3JrIGlmICJbUkZDMzk4Nl0NCj4g
cmVzZXJ2ZWQgY2hhcmFjdGVycyIgaXMgdGFrZW4gYXMgYSBwaHJhc2UsIGJ1dCBpdCdzIGRpZmZp
Y3VsdCBmb3IgdGhlDQo+IHJlYWRlciB0byBzZWUgdGhhdC4gQWxzbywgdGhlIHNwZWNpZmljIHRv
cGljIGlzIGRpc2N1c3NlZCBpbiBTZWN0aW9uIDIuMg0KPiBvZiBbUkZDMzk4Nl0sIHNvIGNoYW5n
ZSB0aGUgYWJvdmUgdG86DQo+ICAgICBOZXcgc2NoZW1lcyBTSE9VTEQgY2xlYXJseSBkZWZpbmUg
dGhlIHJvbGUgb2YgcmVzZXJ2ZWQgY2hhcmFjdGVycw0KPiAgICAgKHNlZSBbUkZDMzk4Nl0sIFNl
Y3Rpb24gMi4yKSBpbiBVUklzIG9mIHRoZSBzY2hlbWUgYmVpbmcgZGVmaW5lZC4NCg0KRG9uZS4N
CiANCj4gMy4zLiBXZWxsLURlZmluZWQNCj4gDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGFuZCBob3cgbGVnYWwNCj4gICAgIHZhbHVl
cyBpbiB0aGUgYmFzZSBuYW1lc3BhY2UsIG9yIGxlZ2FsIHByb3RvY29sIGludGVyYWN0aW9ucywg
bWlnaHQNCj4gICAgIGJlIHJlcHJlc2VudGVkIGluIGEgdmFsaWQgVVJJLg0KPiAibWlnaHQgYmUg
cmVwcmVzZW50ZWQiIC0+ICJhcmUgcmVwcmVzZW50ZWQiDQoNCkRvbmUuDQoNCj4gICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgU2VlIFNlY3Rpb24gMy42IGZvciBndWlkZWxpbmVz
IGZvcg0KPiAgICAgZW5jb2RpbmcgYmluYXJ5IG9yIGNoYXJhY3RlciBzdHJpbmdzIHdpdGhpbiB2
YWxpZCBjaGFyYWN0ZXIgc2VxdWVuY2VzDQo+ICAgICBpbiBhIFVSSSAuDQo+ICJiaW5hcnkgb3Ig
Y2hhcmFjdGVyIHN0cmluZ3MiIC0+ICJzZXF1ZW5jZXMgb2YgYnl0ZXMgb3IgY2hhcmFjdGVycyIg
KGluDQo+IG1vc3QgY29udGV4dHMgKHByb2dyYW1taW5nIGxhbmd1YWdlcywuLi4pLCAiY2hhcmFj
dGVyIHN0cmluZyIgaXMNCj4gZXF1aXZhbGVudCB0byAic3RyaW5nIiwgd2hpbGUgImJpbmFyeSBz
dHJpbmciIGlzIHVuZGVmaW5lZC4pDQoNCkNoYW5nZWQgdG8gInN0cmluZ3Mgb3Igc2VxdWVuY2Vz
IG9mIGJ5dGVzIi4NCg0KPiBTdXBlcmZsdW91cyBzcGFjZSBiZWZvcmUgcGVyaW9kLg0KDQpEb25l
Lg0KDQo+IA0KPiAgICAgICAgICAgICAgICAgSWYgbm90IGFsbCBsZWdhbCB2YWx1ZXMgb3IgcHJv
dG9jb2wgaW50ZXJhY3Rpb25zIG9mIHRoZQ0KPiAgICAgYmFzZSBzdGFuZGFyZCBjYW4gYmUgcmVw
cmVzZW50ZWQgdXNpbmcgdGhlIHNjaGVtZSwgdGhlIGRlZmluaXRpb24NCj4gICAgIFNIT1VMRCBi
ZSBjbGVhciBhYm91dCB3aGljaCBzdWJzZXQgYXJlIGFsbG93ZWQsIGFuZCB3aHkuDQo+ICJXaGlj
aCBzdWJzZXQgYXJlIiAtPiAid2hpY2ggc3Vic2V0IGlzIiAob3IgIndoaWNoIHN1YnNldHMgYXJl
IikNCj4gDQo+IA0KPiAzLjUuIENvbnRleHQgb2YgVXNlDQo+IA0KPiAgICAgICAgICAgICAgICAg
ICAgTW9zdCBjb21tb25seSwgVVJJcyBhcmUgdXNlZCBhcyByZWZlcmVuY2VzIHRvDQo+ICAgICBy
ZXNvdXJjZXMgd2l0aGluIGRpcmVjdG9yaWVzIG9yIGh5cGVydGV4dCBkb2N1bWVudHMsIGFzIGh5
cGVybGlua3MgdG8NCj4gICAgIG90aGVyIHJlc291cmNlcy4NCj4gDQo+IFRoaXMgc2VudGVuY2Ug
aXMgdG90YWxseSB1bmNsZWFyLiBXaHkgZG8gZGlyZWN0b3JpZXMgdHVybiB1cCBoZXJlPyBJcw0K
PiAicmVzb3VyY2VzIHdpdGhpbiBkaXJlY3RvcmllcyIgYW5kICJvdGhlciByZXNvdXJjZXMiIHBh
cmFsbGVscz8gQXJlDQo+ICJyZWZlcmVuY2VzIiBhbmQgImh5cGVybGlua3MiIGludGVuZGVkIHRv
IGJlIHBhcmFsbGVscz8gSXMgInJlZmVyZW5jZXMNCj4gdG8gcmVzb3VyY2VzIHdpdGhpbiAuLi4i
IGludGVuZGVkIHRvIG1lYW4gInJlZmVyZW5jZXMgdG8gcmVzb3VyY2VzIGZyb20NCj4gd2l0aGlu
IC4uLiIgb3IgInJlZmVyZW5jZXMgdG8gKHJlc291cmNlcyB3aXRoaW4gLi4uKSI/LiBQbGVhc2Ug
Y2xhcmlmeS4NCg0KQWdyZWUsIGFuZCBSRkMgNDM5NSBhbmQgdGhlIGRyYWZ0cyB0aGF0IHByZWNl
ZGVkIGl0IHdlcmUgZXF1YWxseSB1bmNsZWFyLg0KTGFycnkgKHdobyB3YXMgcGFydCBvZiB0aGUg
b3JpZ2luYWwgZGlzY3Vzc2lvbikgcmV3cm90ZSB0aGlzIG5vdyBhczoNCiJGb3IgZXhhbXBsZSwg
VVJJcyBhcmUgY29tbW9ubHkgdXNlZCB3aXRoaW4gaHlwZXJ0ZXh0IGRvY3VtZW50cyBhcw0KcmVm
ZXJlbmNlcyB0byBvdGhlciByZXNvdXJjZXMuIg0KDQo+IDMuNi4gSW50ZXJuYXRpb25hbGl6YXRp
b24gYW5kIENoYXJhY3RlciBFbmNvZGluZw0KPiANCj4gICAgIFdoZW4gZGVzY3JpYmluZyBzY2hl
bWVzIGluIHdoaWNoIChzb21lIG9mKSB0aGUgZWxlbWVudHMgb2YgdGhlIFVSSQ0KPiAgICAgYXJl
IGFjdHVhbGx5IHJlcHJlc2VudGF0aW9ucyBvZiBodW1hbi1yZWFkYWJsZSB0ZXh0LCBjYXJlIHNo
b3VsZCBiZQ0KPiAgICAgdGFrZW4gbm90IHRvIGludHJvZHVjZSB1bm5lY2Vzc2FyeSB2YXJpZXR5
IGluIHRoZSB3YXlzIGluIHdoaWNoDQo+ICAgICBjaGFyYWN0ZXJzIGFyZSBlbmNvZGVkIGludG8g
b2N0ZXRzIGFuZCB0aGVuIGludG8gVVJJIGNoYXJhY3RlcnM7IHNlZQ0KPiAgICAgW1JGQzM5ODdd
IGFuZCBTZWN0aW9uIDIuNSBvZiBbUkZDMzk4Nl0gZm9yIGd1aWRlbGluZXMuICBJZiBVUklzIG9m
IGENCj4gICAgIHNjaGVtZSBjb250YWluIGFueSB0ZXh0IGZpZWxkcywgdGhlIHNjaGVtZSBkZWZp
bml0aW9uIE1VU1QgZGVzY3JpYmUNCj4gICAgIHRoZSB3YXlzIGluIHdoaWNoIGNoYXJhY3RlcnMg
YXJlIGVuY29kZWQgYW5kIGFueSBjb21wYXRpYmlsaXR5IGlzc3Vlcw0KPiAgICAgd2l0aCBJUklz
IG9mIHRoZSBzY2hlbWUuDQo+IA0KPiBJIHRoaW5rIGl0IHdvdWxkIGJlIGV4dHJlbWVseSBoZWxw
ZnVsIHRvIHRoZSBhdmVyYWdlIFVSSSBzY2hlbWUNCj4gZGVzaWduZXIvZGVzY3JpYmVyIGlmIHRo
aXMgc2VjdGlvbiBtZW50aW9uZWQgdGhlIHVzZSBvZiBVVEYtOC4gVGhlDQo+IHJlZmVyZW5jZSB0
byBTZWN0aW9uIDIuNSBvZiBSRkMgMzk4NiBpcyBnb29kLCBidXQgdGhlIHByb2JsZW0gd2l0aCB0
aGF0DQo+IHNlY3Rpb24gaXMgdGhhdCBpdCBzdGFydHMgb3V0IHdpdGggdmVyeSBnZW5lcmFsIGFu
ZCBhYnN0cmFjdCBsYW5ndWFnZSwNCj4gYW5kIG9uZSBoYXMgdG8gcmVhZCB0aHJvdWdoIHRoZSB3
aG9sZSBzZWN0aW9uIHRvIGZpbmQgdGhlIHJlbGV2YW50IChhbmQNCj4gZXh0cmVtZWx5IGNsZWFy
IGFuZCBhcHByb3ByaWF0ZSkgYWR2aWNlIGluIHRoZSBsYXN0IHBhcmFncmFwaC4NCj4gDQo+IEF0
IGEgbWluaW11bSwgcGxlYXNlIHBvaW50IHRoZSByZWFkZXIgdG8gdGhlIGxhc3QgcGFyYWdyYXBo
IG9mIFNlY3Rpb24NCj4gMi41LiBNdWNoIGJldHRlciB3b3VsZCBiZSB0byBpbmNsdWRlIHRoYXQg
cGFyYWdyYXBoIHZlcmJhdGltIChhbmQgc2F5aW5nDQo+IHNvIGV4cGxpY2l0bHkpOg0KDQpEb25l
LiAgRGlkIG5vdCBpbmNsdWRlIHRoZSBsYXJnZSB2ZXJiYXRpbSBxdW90ZSBidXQgY2l0ZWQgaXQg
ZXhwbGljaXRseS4NCg0KPiANCj4gPj4+Pg0KPiAgICAgV2hlbiBhIG5ldyBVUkkgc2NoZW1lIGRl
ZmluZXMgYSBjb21wb25lbnQgdGhhdCByZXByZXNlbnRzIHRleHR1YWwNCj4gICAgIGRhdGEgY29u
c2lzdGluZyBvZiBjaGFyYWN0ZXJzIGZyb20gdGhlIFVuaXZlcnNhbCBDaGFyYWN0ZXIgU2V0IFtV
Q1NdLA0KPiAgICAgdGhlIGRhdGEgc2hvdWxkIGZpcnN0IGJlIGVuY29kZWQgYXMgb2N0ZXRzIGFj
Y29yZGluZyB0byB0aGUgVVRGLTgNCj4gICAgIGNoYXJhY3RlciBlbmNvZGluZyBbU1RENjNdOyB0
aGVuIG9ubHkgdGhvc2Ugb2N0ZXRzIHRoYXQgZG8gbm90DQo+ICAgICBjb3JyZXNwb25kIHRvIGNo
YXJhY3RlcnMgaW4gdGhlIHVucmVzZXJ2ZWQgc2V0IHNob3VsZCBiZSBwZXJjZW50LQ0KPiAgICAg
ZW5jb2RlZC4gIEZvciBleGFtcGxlLCB0aGUgY2hhcmFjdGVyIEEgd291bGQgYmUgcmVwcmVzZW50
ZWQgYXMgIkEiLA0KPiAgICAgdGhlIGNoYXJhY3RlciBMQVRJTiBDQVBJVEFMIExFVFRFUiBBIFdJ
VEggR1JBVkUgd291bGQgYmUgcmVwcmVzZW50ZWQNCj4gICAgIGFzICIlQzMlODAiLCBhbmQgdGhl
IGNoYXJhY3RlciBLQVRBS0FOQSBMRVRURVIgQSB3b3VsZCBiZSByZXByZXNlbnRlZA0KPiAgICAg
YXMgIiVFMyU4MiVBMiIuDQo+ID4+Pj4NCj4gDQo+ICAgICBUaGUgc2NoZW1lIHNwZWNpZmljYXRp
b24gU0hPVUxEIGJlIGFzIHJlc3RyaWN0aXZlIGFzIHBvc3NpYmxlDQo+ICAgICByZWdhcmRpbmcg
d2hhdCBjaGFyYWN0ZXJzIGFyZSBhbGxvd2VkIGluIHRoZSBVUkksIGJlY2F1c2Ugc29tZQ0KPiAg
ICAgY2hhcmFjdGVycyBjYW4gY3JlYXRlIHNldmVyYWwgZGlmZmVyZW50IHNlY3VyaXR5IGNvbnNp
ZGVyYXRpb25zIChzZWUsDQo+ICAgICBmb3IgZXhhbXBsZSBbUkZDNDY5MF0pLg0KPiBJJ20gYWZy
YWlkIHRoYXQgbWFueSBwZW9wbGUgd2lsbCByZWFkICJhcyByZXN0cmljdGl2ZSBhcyBwb3NzaWJs
ZSIgYXMNCj4gIndlbGwsIGxldCdzIGp1c3QgZG8gQVNDSUkgb25seSIgb3Igc29tZSBzdWNoLiBJ
IGJlbGlldmUgYW5kIGhvcGUgdGhhdA0KPiB0aGlzIHdhc24ndCB0aGUgaW50ZW50LCBidXQgSSBk
b24ndCB0aGluayB0aGlzIGNvbWVzIGFjcm9zcy4gT25lIGtpbmQgb2YNCj4gaW1wcm92ZW1lbnQg
d291bGQgYmUgdG8gY2hhbmdlICJhcyByZXN0cmljdGl2ZSBhcyBwb3NzaWJsZSIgdG8ganVzdA0K
PiAicmVzdHJpY3RpdmUiLiBBbm90aGVyIGlzIHRvIGNoYW5nZSAiYXMgcmVzdHJpY3RpdmUgYXMg
cG9zc2libGUiIHRvICJhcw0KPiByZXN0cmljdGl2ZSBhcyBwb3NzaWJsZSB3aXRob3V0IGV4Y2x1
ZGluZyBjaGFyYWN0ZXJzIG91dHNpZGUgVVMtQVNDSUkiLg0KDQpXZSAoaW5jbHVkaW5nIHRoZSBk
b2Mgc2hlcGhlcmQpIGRpc2N1c3NlZCB0aGlzIGFuZCBiZWxpZXZlIGl0IGFscmVhZHkgaGFkDQp0
aGUgaW50ZW5kZWQgbWVhbmluZywgZXNwZWNpYWxseSB3aXRoIHRoZSBwYXJhZ3JhcGggdGhhdCBp
bW1lZGlhdGVseQ0KZm9sbG93cyB0aGUgcXVvdGVkIHRleHQgKGFuZCB3aGljaCB5b3UgcXVvdGUg
bGF0ZXIgaW4gdGhpcyBlbWFpbCkNCmFuZCByZWZsZWN0cyBXRyBjb25zZW5zdXMuICAgSG93ZXZl
ciwgd2UgYWRkZWQgYWRkaXRpb25hbCB0ZXh0IHRvIHRoZQ0Kc3Vic2VxdWVudCBwYXJhZ3JhcGgg
Zm9yIHlvdXIgbGFzdCBwb2ludCBiZWxvdywgd2hpY2ggd2UgYmVsaWV2ZSBpcyBzDQp1ZmZpY2ll
bnQgdG8gYWxzbyBjbGFyaWZ5IHRoZSBpbnRlbnQgb2YgdGhlIHRleHQgYWJvdmUuDQoNCj4gDQo+
ICJjYW4gY3JlYXRlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIiBzb3VuZHMgd2VpcmQuIFRoZSBj
aGFyYWN0ZXJzIG1heQ0KPiBjcmVhdGUgc2VjdXJpdHkgaXNzdWVzIG9yIHNlY3VyaXR5IHByb2Js
ZW1zIG9yIHNvbWUgc3VjaCwgd2hpY2ggbWF5IG5lZWQNCj4gdG8gYmUgZGVzY3JpYmVkIGluIGEg
c2VjdXJpdHkgY29uc2lkZXJhdGlvbiBzZWN0aW9uLg0KDQpDaGFuZ2VkICJjb25zaWRlcmF0aW9u
cyIgdG8gImlzc3VlcyIuDQoNCj4gICAgIEFsbCBwZXJjZW50LWVuY29kZWQgdmFyaWFudHMgYXJl
IGF1dG9tYXRpY2FsbHkgaW5jbHVkZWQgYnkgZGVmaW5pdGlvbg0KPiAgICAgZm9yIGFueSBjaGFy
YWN0ZXIgZ2l2ZW4gaW4gYW4gSVJJIHByb2R1Y3Rpb24uICBUaGlzIG1lYW5zIHRoYXQgaWYgeW91
DQo+ICAgICB3YW50IHRvIHJlc3RyaWN0IHRoZSBVUkkgcGVyY2VudC1lbmNvZGVkIGZvcm1zIGlu
IHNvbWUgd2F5LCB5b3UgbXVzdA0KPiAgICAgcmVzdHJpY3QgdGhlIFVuaWNvZGUgZm9ybXMgdGhh
dCB3b3VsZCBsZWFkIHRvIHRoZW0uDQo+IA0KPiBJIGtub3cgd2hhdCB5b3Ugd2FudCB0byBzYXkg
aGVyZSAoSSB0aGluayBpdCdzIHRoZSBwb2ludCBvcmlnaW5hbGx5DQo+IGJyb3VnaHQgdXAgYnkg
QmrDtnJuIEjDtmhybWFubiBpbiB0aGUgSVJJIFdHKS4gQnV0IEkgdGhpbmsgaXQncyB0b28NCj4g
cmVzdHJpY3RpdmUgYW5kIGNhbiBiZSB3b3JkZWQgYmV0dGVyOg0KPiANCj4gICAgIFVSSSBzY2hl
bWVzIHRoYXQgaW5jbHVkZSB0ZXh0dWFsIGRhdGEgZnJvbSBVbmljb2RlIGhhdmUgdG8gYmUgYXdh
cmUNCj4gICAgIHRoYXQgdGhleSBoYXZlIHRvIGRlZmluZSBib3RoIHRoZSBhY3R1YWwgY2hhcmFj
dGVycyBhbGxvd2VkIChmb3INCj4gICAgIElSSXMpIGFuZCB0aGUgY29ycmVzcG9uZGluZyBwZXJj
ZW50LWVuY29kZWQgZm9ybXMgKGZvciBVUklzIGFuZA0KPiAgICAgSVJJcykuIFRoaXMgY2FuIGJl
IGRvbmUgaW4gdmFyaW91cyB3YXlzLCBidXQgaW4gbW9zdCBjYXNlcywgaXQgaXMNCj4gICAgIGFk
dmlzYWJsZSB0byBkZWZpbmUgdGhlIGFjdHVhbCBjaGFyYWN0ZXJzIGFsbG93ZWQgaW4gYW4gSVJJ
DQo+ICAgICBwcm9kdWN0aW9uLCB0byBhbGxvdyB0aGUgJ3BjdC1lbmNvZGVkJyBkZWZpbml0aW9u
IGZyb20gU2VjdGlvbiAyLjENCj4gICAgIG9mIFtSRkMgMzk4Nl0gYXQgdGhlIHNhbWUgcGxhY2Vz
LCBhbmQgdG8gYWRkIHByb3NlIHRoYXQgbGltaXRzDQo+ICAgICBwZXJjZW50LWVzY2FwZXMgdG8g
dGhvc2UgdGhhdCBjYW4gYmUgY3JlYXRlZCBieSBjb252ZXJ0aW5nIHZhbGlkDQo+ICAgICBjaGFy
YWN0ZXIgc2VxdWVuY2VzIHRvIHBlcmNlbnQtZW5jb2RpbmcgdmlhIFVURi04Lg0KDQpBZGRlZCB0
aGlzIHZhcmlhdGlvbiBvZiB5b3VyIHN1Z2dlc3Rpb24sIGFmdGVyIHRoZSBleGlzdGluZyB0ZXh0
IGFib3V0IElSSXM6DQogICBJbiBtb3N0IGNhc2VzLA0KICAgaXQgaXMgYWR2aXNhYmxlIHRvIGRl
ZmluZSB0aGUgYWN0dWFsIGNoYXJhY3RlcnMgYWxsb3dlZCBpbiBhbiBJUkkNCiAgIHByb2R1Y3Rp
b24sIHRvIGFsbG93IHRoZSAncGN0LWVuY29kZWQnIGRlZmluaXRpb24gZnJvbSBTZWN0aW9uIDIu
MSBvZg0KICAgW1JGQzM5ODZdIGF0IHRoZSBzYW1lIHBsYWNlcywgYW5kIHRvIGFkZCBwcm9zZSB0
aGF0IGxpbWl0cyBwZXJjZW50LQ0KICAgZXNjYXBlcyB0byB0aG9zZSB0aGF0IGNhbiBiZSBjcmVh
dGVkIGJ5IGNvbnZlcnRpbmcgdmFsaWQgY2hhcmFjdGVyDQogICBzZXF1ZW5jZXMgdG8gcGVyY2Vu
dC1lbmNvZGluZyB2aWEgVVRGLTguDQoNCkRhdmUNCg==


From nobody Thu Apr  2 12:57:21 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78A8B1A035F for ; Thu,  2 Apr 2015 12:57:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.31
X-Spam-Level: 
X-Spam-Status: No, score=-0.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_MEN=2.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7VwQccRsA4UG for ; Thu,  2 Apr 2015 12:57:19 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88EED1A033B for ; Thu,  2 Apr 2015 12:57:19 -0700 (PDT)
Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YdlEl-000IqN-Sn; Thu, 02 Apr 2015 15:57:11 -0400
Date: Thu, 02 Apr 2015 15:57:06 -0400
From: John C Klensin 
To: Dave Thaler 
Message-ID: <080D2D237EF9714533B15BDB@JcK-HP8200.jck.com>
In-Reply-To: 
References: <550164DD.6020509@it.aoyama.ac.jp> 
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.35
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: 
Cc: apps-discuss@ietf.org, Larry Masinter 
Subject: Re: [apps-discuss] Last Call:  (Guidelines and Registration Procedures for URI Schemes) to Best Current Practice
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 02 Apr 2015 19:57:20 -0000

--On Thursday, April 02, 2015 19:27 +0000 Dave Thaler
 wrote:

>...
>> "For example, this means that fragment identifiers (#) cannot
>> be re-used outside the generic syntax restrictions."
>> My 'best-guess' interpretation of this sentence is that this
>> intended to say that a scheme definition cannot define
>> fragments that contain characters (e.g.
>> # ) that RFC 3986 doesn't allow.
> 
> Correct.

Hi.

Just because this may be an illustration of how much 3986 (with
or without this I-D) is confusing everyone, my reading of the
syntax in 3986 is that 
   somescheme://domain/foobar#sss#yyy 
is perfectly valid.  The actual fragment is "foo#yyy" and there
is no requirement that the embedded "#" be %-encoded.

So Martin's "best guess" sentence above, which you identified as
correct, actually is not.

>> But this is bad advice, because scheme definitions cannot say
>> anything about fragments at all. This isn't syntax, but
>> semantics; the semantics of a fragment are defined by the
>> media type, not the scheme. I haven't found any place
>> anywhere in this doc that says this, it clearly should be
>> added.
>> 
>> If you want to make an example re. syntax, I'd suggest to say
>> something like "For example, the query part cannot contain
>> literal '#' characters because they and anything after them
>> would be interpreted as part of the fragment and not the
>> query." or some such.

Now _that_ is strictly correct.  I also note the "isn't syntax,
but semantics" comment above, which is critical to the
syntax-eemantics distinction being drawn in URNBIS -- thanks
Martin.

>...

> Updated to read:
> " For example, this means that fragment identifiers cannot be
> re-used    outside the generic syntax restrictions, and
> fragment identifiers are    not scheme-specific."

This is not correct and has already triggered controversy
because, as Martin points out, the binding between "fragment"
and media type is a matter of semantics, not syntax.  Indeed,
assigning any meaning at all to the string consisting of the
characters "f", "r", "a", "g", "m", "e", "n", and "t" is about
semantics: as far as the generic syntax is concerned, that term
refers to a substring that is preceded by "#" and extends to the
end of the string in in which some characters, if they appear,
are required to be %-encoded (but "#" is not one of those
characters, nor is "?").

>...

I have discussed some issues related to other comments in this
note in other postings and won't repeat myself, but the above
seemed critical.

best,
    john


From nobody Thu Apr  2 14:30:16 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3F121A6EF4 for ; Thu,  2 Apr 2015 14:30:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.602
X-Spam-Level: 
X-Spam-Status: No, score=-101.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PvOTjY6kmBQK for ; Thu,  2 Apr 2015 14:30:12 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0127.outbound.protection.outlook.com [65.55.169.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 495DB1A6EDC for ; Thu,  2 Apr 2015 14:30:12 -0700 (PDT)
Received: from BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) by BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) with Microsoft SMTP Server (TLS) id 15.1.130.12; Thu, 2 Apr 2015 21:30:10 +0000
Received: from BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) by BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) with mapi id 15.01.0130.020; Thu, 2 Apr 2015 21:30:10 +0000
From: Dave Thaler 
To: =?utf-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= , "apps-discuss@ietf.org" , Larry Masinter , Ted Hardie , Tony Hansen 
Thread-Topic: [apps-discuss] Last Call:  (Guidelines and Registration Procedures for URI Schemes) to Best Current Practice
Thread-Index: AQHQXKwMVJ1nESp+pkCQTGWdSKvW550aJtMAgCAWCzA=
Date: Thu, 2 Apr 2015 21:30:09 +0000
Message-ID: 
References: <550164DD.6020509@it.aoyama.ac.jp> <5502ADC6.3030108@it.aoyama.ac.jp>
In-Reply-To: <5502ADC6.3030108@it.aoyama.ac.jp>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:4898:80e0:ee43::2]
authentication-results: it.aoyama.ac.jp; dkim=none (message not signed) header.d=none;
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB412;
x-microsoft-antispam-prvs: 
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(51704005)(24454002)(55885003)(2656002)(77096005)(102836002)(15975445007)(99286002)(46102003)(76576001)(87936001)(230783001)(106116001)(33656002)(54356999)(19580395003)(19580405001)(40100003)(74316001)(92566002)(62966003)(50986999)(2501003)(86362001)(77156002)(2900100001)(107886001)(76176999)(2950100001)(3826002)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB412; H:BY2PR03MB412.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:BY2PR03MB412; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB412; 
x-forefront-prvs: 0534947130
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.onmicrosoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Apr 2015 21:30:10.1007 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB412
Archived-At: 
Subject: Re: [apps-discuss] Last Call:  (Guidelines and Registration Procedures for URI Schemes) to Best Current Practice
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 02 Apr 2015 21:30:15 -0000

QW5kIGJlbG93IGlzIHdoYXQgd2UgKGNvLWF1dGhvcnMsIHdpdGggaW5wdXQgZnJvbSBkb2Mgc2hl
cGhlcmQpIA0KZGlkIGluIHJlc3BvbnNlIGluIGRyYWZ0LTA1LCByZWdhcmRpbmcgdGhlIGxhc3Qg
c2V0IG9mIElFVEYgTGFzdCBDYWxsIGNvbW1lbnRzOg0KDQpNYXJ0aW4gSi4gRMO8cnN0IHdyb3Rl
OiANCj4gMy44LiBTY2hlbWUgTmFtZSBDb25zaWRlcmF0aW9ucw0KPiANCj4gICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgTmV3IHJlZ2lzdGVyZWQgc2NoZW1lcw0KPiAgICAg
cmVnaXN0cmF0aW9ucyBNVVNUIGZvbGxvdyB0aGlzIHN5bnRheCwgd2hpY2ggb25seSBhbGxvd3Mg
YSBsaW1pdGVkDQo+ICAgICByZXBlcnRvaXJlIG9mIGNoYXJhY3RlcnMgKHRha2VuIGZyb20gVVMt
QVNDSUkpLg0KPiAic2NoZW1lcyByZWdpc3RyYXRpb25zIiAtPiAic2NoZW1lIHJlZ2lzdHJhdGlv
bnMiDQoNCkRvbmUNCg0KPiAgICAgQSBzY2hlbWUgbmFtZSBpcyBub3QgYSAicHJvdG9jb2wiIGFs
dGhvdWdoLCBsaWtlIGEgc2VydmljZSBuYW1lIGFzDQo+ICAgICBkZWZpbmVkIGluIHNlY3Rpb24g
NSBvZiBbUkZDNjMzNV0sIGl0IG9mdGVuIGlkZW50aWZpZXMgYSBwYXJ0aWN1bGFyDQo+ICAgICBw
cm90b2NvbCBvciBhcHBsaWNhdGlvbi4NCj4gJyJwcm90b2NvbCIgYWx0aG91Z2gnIGRvZXNuJ3Qg
d29yay4gSSBzdWdnZXN0IHRvIHJld29yZCBhczoNCj4gICAgIEEgc2NoZW1lIG5hbWUgaXMgbm90
IGEgInByb3RvY29sIi4gSG93ZXZlciwgbGlrZSBhIHNlcnZpY2UgbmFtZSBhcw0KPiAgICAgZGVm
aW5lZCBpbiBzZWN0aW9uIDUgb2YgW1JGQzYzMzVdLCBpdCBvZnRlbiBpZGVudGlmaWVzIGEgcGFy
dGljdWxhcg0KPiAgICAgcHJvdG9jb2wgb3IgYXBwbGljYXRpb24uDQoNCkRvbmUNCg0KPiBJIHdv
bmRlciB3aGV0aGVyIGl0IG1ha2VzIHNlbnNlIHRvIHNheSBzb21ldGhpbmcgYWJvdXQgYWJicmV2
aWF0aW9ucywgc3VjaA0KPiBhcyAiSWYgdGhlcmUgaXMgYSB3ZWxsLWtub3duIGFiYnJldmlhdGlv
biBmb3IgdGhlIHByb3RvY29sIG9yIHNlcnZpY2UsIHRoZW4gaXQncw0KPiBwcmVmZXJhYmxlIHRv
IHVzZSBpdCBhcyBhIHNjaGVtZSBuYW1lIChlLmcuIGh0dHA6DQo+IHJhdGhlciB0aGFuIGh5cGVy
dGV4dC10cmFuc2Zlci1wcm90b2NvbDopLiINCg0KV2UgYmVsaWV2ZSBpdCdzIGFscmVhZHkgb2J2
aW91cyBmcm9tIHRoZSBleGlzdGluZyB0ZXh0IGluIHNlY3Rpb24gMy44IHRoYXQgc3RhdGVzDQog
ICBTY2hlbWUgbmFtZXMgU0hPVUxEIGJlIHNob3J0LCBidXQgYWxzbyBzdWZmaWNpZW50bHkgZGVz
Y3JpcHRpdmUgYW5kDQogICBkaXN0aW5ndWlzaGVkIHRvIGF2b2lkIHByb2JsZW1zLg0KDQo+ICAg
ICBTb21lIG9yZ2FuaXphdGlvbnMgZGVzaXJlIHRoZWlyIG93biBuYW1lc3BhY2UgZm9yIFVSSSBz
Y2hlbWUgbmFtZXMNCj4gICAgIGZvciBwcml2YXRlIHVzZSAoc2VlIFNlY3Rpb24gNikuICBJbiBk
b2luZyBzbywgaXQgaXMgaW1wb3J0YW50IHRvDQo+ICAgICBwcmV2ZW50IGNvbGxpc2lvbnMsIGFu
ZCB0byBtYWtlIGl0IHBvc3NpYmxlIHRvIGlkZW50aWZ5IHRoZSBvd25lciBvZg0KPiAgICAgYSBw
cml2YXRlIHVzZSBzY2hlbWUuICBUbyBhY2NvbXBsaXNoIHRoZXNlIHR3byBnb2Fscywgc3VjaA0K
PiAgICAgb3JnYW5pemF0aW9ucyBTSE9VTEQgdXNlIGEgcHJlZml4IGJhc2VkIG9uIHRoZWlyIGRv
bWFpbiBuYW1lLA0KPiAgICAgZXhwcmVzc2VkIGluIHJldmVyc2Ugb3JkZXIuICBGb3IgZXhhbXBs
ZSwgYSBVUkkgc2NoZW1lIG5hbWUgb2YNCj4gICAgIGNvbS5leGFtcGxlLmluZm8gbWlnaHQgYmUg
dXNlZCBieSB0aGUgb3JnYW5pemF0aW9uIHRoYXQgb3ducyB0aGUNCj4gICAgIGV4YW1wbGUuY29t
IGRvbWFpbiBuYW1lLiAgQ2FyZSBtdXN0IGJlIHRha2VuLCBob3dldmVyLCBpZiB0aGUNCj4gICAg
IG9yZ2FuaXphdGlvbiBsYXRlciBsb3NlcyB0aGUgZG9tYWluIG5hbWUgZW1iZWRkZWQgaW4gdGhl
aXIgc2NoZW1lDQo+ICAgICBuYW1lcywgc2luY2UgZG9tYWluIG5hbWUgcmVnaXN0cmF0aW9ucyBh
cmUgbm90IHBlcm1hbmVudC4gIFRoZSBVUkkNCj4gICAgIHNjaGVtZSBuYW1lIHJlZ2lzdHJhdGlv
biBwcm9jZWR1cmUgY2FuIGJlIHVzZWQgaW4gc3VjaCBhbiBldmVudC4NCj4gVGhlIHRoZSBsYXN0
IHNlbnRlbmNlIGlzIHVuY2xlYXIuIEkgc3VnZ2VzdCB0byByZXdyaXRlIHRoZSBsYXN0IHNlbnRl
bmNlIHRvDQo+IHNvbWV0aGluZyBsaWtlICJJbiBvcmRlciB0byBwZXJtYW5lbnRseSBhc3NvY2lh
dGUgdGhlIHByaXZhdGUgdXNlIHNjaGVtZQ0KPiBuYW1lIHdpdGggdGhlIG9yaWdpbmFsIGRvbWFp
biBuYW1lIG93bmVyLCB0aGUgcHJpdmF0ZSB1c2Ugc2NoZW1lIGNhbiBiZQ0KPiByZWdpc3RlcmVk
IHVzaW5nIHRoZSByZWdpc3RyYXRpb24gcHJvY2VkdXJlIGluIFNlY3Rpb24gWFlaLiIuDQoNCkRv
bmUuDQogDQo+IEVpdGhlciBhdCB0aGUgZW5kIG9mIHNlY3Rpb24gMSBvciBpbiBhIHN1YnNlY3Rp
b24gb2Ygc2VjdGlvbiAzLCBpdCBzaG91bGQgYmUNCj4gbWFkZSAqZXh0cmVtZWx5KiBjbGVhciB0
aGF0IHNjaGVtZSByZWdpc3RyYXRpb25zIG5laXRoZXIgY2FuIG5vciBzaG91bGQNCj4gZGVmaW5l
IGFueXRoaW5nIHJlbGF0ZWQgdG8gZnJhZ21lbnRzLCBpLmUuIHRoYXQgZnJhZ21lbnRzIGFyZSBt
b3N0bHkgaWYgbm90DQo+IGNvbXBsZXRlbHkgb3J0aG9nb25hbCB0byBzY2hlbWVzLCBhbmQgdGhl
aXIgaW50ZXJwcmV0YXRpb24gaXMgZGVmaW5lZCBieSB0aGUNCj4gTUlNRSBtZWRpYSB0eXBlIG9m
IHRoZSByZXR1cm5lZCByZXByZXNlbnRhdGlvbiB3aGVuIGRlcmVmZXJlbmNpbmcuDQoNCkRvbmUg
YXMgc3RhdGVkIGluIG15IHJlc3BvbnNlIHRvIHlvdXIgcHJldmlvdXMgY29tbWVudHMgd2hpY2gg
YWxzbyBjYWxsZWQgdGhpcyBvdXQuDQoNCj4gNC4gR3VpZGVsaW5lcyBmb3IgUHJvdmlzaW9uYWwg
VVJJIFNjaGVtZSBSZWdpc3RyYXRpb24NCj4gDQo+IFRoZXJlIGlzIGEgcG9pbnQgYWJvdXQgcHJv
dmlzaW9uYWwgcmVnaXN0cmF0aW9ucyBtZWV0aW5nIHRoZSBzeW50YXgNCj4gcmVzdHJpY3Rpb25z
IGZvciBzY2hlbWUgbmFtZXMsIGJ1dCBub3RoaW5nIGFib3V0IHN5bnRheCByZXN0cmljdGlvbnMg
Zm9yIHRoZQ0KPiByZXN0IG9mIHRoZSBVUklzLiBJIHRoaW5rIGl0IHNob3VsZCBiZSBtYWRlIHZl
cnkgY2xlYXIgdGhhdCB3aGlsZSB3ZSBoYXZlIG1hZGUNCj4gcHJvdmlzaW9uYWwgcmVnaXN0cmF0
aW9uIHZlcnkgZWFzeSBvbiBwdXJwb3NlLCBpZiBhIHNjaGVtZSBkb2Vzbid0IG1lZXQgdGhlDQo+
IGdlbmVyYWwgc3ludGF4IHJlc3RyaWN0aW9ucywgaXQgbWF5IG5vdCB3b3JrIGluIHNvbWUgb3Ig
YWxsIFVSSSBzb2Z0d2FyZSwgYW5kIGl0DQo+IGRvZXNuJ3QgaGF2ZSBhIGNoYW5jZSB0byBtb3Zl
IHRvIHBlcm1hbmVudCByZWdpc3RyYXRpb24uDQoNCk15IGNvLWF1dGhvcnMgZmVsdCB0aGF0IHRo
ZSBkb2N1bWVudCB3YXMgYWxyZWFkeSBjbGVhciBlbm91Z2ggYWJvdXQgdGhvc2UgcG9pbnRzLA0K
YW5kIHRoZSBkYW5nZXIgb2YgcHV0dGluZyBpbiBtb3JlIHRleHQgYWJvdXQgcHJvdmlzaW9uYWwg
cmVnaXN0cmF0aW9uIGlzIHRoYXQgdGhlDQptb3JlIGNvbXBsaWNhdGVkIHRoZSBkaXNjdXNzaW9u
IGlzLCB0aGUgbW9yZSBsaWtlbHkgc29tZW9uZSB3aWxsIGdpdmUgdXAgYW5kDQpzaW1wbHkgc3F1
YXQgb24gYSBzY2hlbWUgbmFtZSByYXRoZXIgdGhhbiByZWdpc3RlcmluZyBhcyBwcm92aXNpb25h
bC4gIEhlbmNlDQp3ZSB3YW50IHRvIGtlZXAgdGhlIHByb3Zpc2lvbmFsIGRpc2N1c3Npb24gYXMg
c2ltcGxlIGFzIHBvc3NpYmxlIChidXQgbm8gc2ltcGxlciA6KQ0KDQo+IG8gIFRoZSBzY2hlbWUg
ZGVmaW5pdGlvbiBTSE9VTEQgaW5jbHVkZSBhIGNsZWFyIFNlY3VyaXR5DQo+ICAgICBDb25zaWRl
cmF0aW9ucyAoU2VjdGlvbiAzLjcpDQo+IA0KPiAiYSBjbGVhciBTZWN1cml0eSBDb25zaWRlcmF0
aW9ucyIgLT4gImEgY2xlYXIgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgc2VjdGlvbiINCj4gb3Ig
ImNsZWFyIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIg0KPiBBbHNvOiAiKFNlY3Rpb24gMy43KSIg
LT4gIihzZWUgU2VjdGlvbiAzLjcpIg0KDQpEb25lDQoNCj4gNS4gR3VpZGVsaW5lcyBmb3IgSGlz
dG9yaWNhbCBVUkkgU2NoZW1lIFJlZ2lzdHJhdGlvbg0KPiANCj4gICAgIEluIHNvbWUgY2lyY3Vt
c3RhbmNlcywgaXQgaXMgYXBwcm9wcmlhdGUgdG8gbm90ZSBhIHNjaGVtZSB0aGF0IHdhcw0KPiAg
ICAgb25jZSBpbiB1c2Ugb3IgcmVnaXN0ZXJlZCBidXQgZm9yIHdoYXRldmVyIHJlYXNvbiBpcyBu
byBsb25nZXIgaW4NCj4gICAgIGNvbW1vbiB1c2Ugb3IgdGhlIHVzZSBpcyBub3QgcmVjb21tZW5k
ZWQuDQo+IENoYW5nZSB0aGUgbGFzdCBiaXQgKCJvciB0aGUgdXNlIGlzIG5vdCByZWNvbW1lbmRl
ZCIpIHRvICJvciBpcyBubw0KPiBsb25nZXIgcmVjb21tZW5kZWQgZm9yIHVzZSIgdG8gYXZvaWQg
YSBjaGFuZ2Ugb2Ygc3ViamVjdCBpbiBtaWQtc2VudGVuY2UuDQoNCkNoYW5nZWQgdG8gIm9yIHdo
b3NlIHVzZSBpcyBub3QgcmVjb21tZW5kZWQiIHRvIGZpeCBncmFtbWFyLg0KDQo+ICAgICAgICAg
ICAgICAgICAgICBBbnkgc2NoZW1lIHRoYXQgaXMgbm8gbG9uZ2VyIGluIGNvbW1vbiB1c2UgTUFZ
IGJlDQo+ICAgICBkZXNpZ25hdGVkIGFzIGhpc3RvcmljYWw7IHRoZSByZWdpc3RyYXRpb24gU0hP
VUxEIGNvbnRhaW4gc29tZQ0KPiAgICAgaW5kaWNhdGlvbiB0byB3aGVyZSB0aGUgc2NoZW1lIHdh
cyBwcmV2aW91c2x5IGRlZmluZWQgb3IgZG9jdW1lbnRlZC4NCj4gImluZGljYXRpb24gdG8iIC0+
ICJpbmRpY2F0aW9uIGFib3V0Ig0KDQpDaGFuZ2VkIHRvICJpbmRpY2F0aW9uIGFzIHRvIiB0byBm
aXggZ3JhbW1hcg0KDQo+IDYuIEd1aWRlbGluZXMgZm9yIFByaXZhdGUgVVJJIFNjaGVtZSBVc2UN
Cj4gDQo+ICAgICAgICAgICAgIEFzIHN1Y2gsIGEgdW5pcXVlIG5hbWVzcGFjZSAoc2VlIFNlY3Rp
b24gMy44KSBNVVNUIGJlIHVzZWQsDQo+ICAgICBhbmQgaXQgaXMgc3Ryb25nbHkgZW5jb3VyYWdl
ZCB0byBkbyBhIFByb3Zpc2lvbmFsIHJlZ2lzdHJhdGlvbiB1bmxlc3MNCj4gICAgIHRoZSBzY2hl
bWUgbmFtZSBpcyBjb25zdHJ1Y3RlZCBmcm9tIGEgZG9tYWluIG5hbWUuDQo+IFBsZWFzZSBhZGQg
YSBwb2ludGVyIHRvIHRoZSBleGFtcGxlIGF0IHRoZSBlbmQgb2Ygc2VjdGlvbiAzLjguDQoNCkRv
bmUNCiANCj4gNy4gVVJJIFNjaGVtZSBSZWdpc3RyYXRpb24gUHJvY2VkdXJlDQo+IA0KPiA3LjEu
IEdlbmVyYWwNCj4gDQo+ICAgICBUaGUgSUFOQSBwb2xpY3kgKHVzaW5nIHRlcm1zIGRlZmluZWQg
aW4gW1JGQzUyMjZdKSBmb3IgUHJvdmlzaW9uYWwNCj4gICAgIHJlZ2lzdHJhdGlvbiB3YXMgZm9y
bWVybHkgRXhwZXJ0IFJldmlldyBhbmQgaXMgbm93IGNoYW5nZWQgdG8gc2ltcGx5DQo+ICAgICB1
c2UgYSBGaXJzdCBDb21lIEZpcnN0IFNlcnZlZCBwb2xpY3kuDQo+ICJpcyBub3cgY2hhbmdlZCIg
d2lsbCByZWFkIGJhZGx5IGEgZmV3IHllYXJzIGRvd24gdGhlIGxpbmUuIFBsZWFzZQ0KPiByZXdv
cmQuIA0KDQpSZXdvcmRlZC4NCg0KPiBBbHNvLCBpdCBtYXkgYmUgd29ydGggcG9pbnRpbmcgb3V0
IHRoYXQgc29tZWJvZHkgd2hvIHdhbnRzIHRvDQo+IHJlZ2lzdGVyIHNvbWV0aGluZyBhcyBwcm92
aXNpb25hbCBzdGlsbCBjYW4gYXNrIGZvciByZXZpZXcuIFdoaWxlIHRoZXJlDQo+IGFyZSBwZW9w
bGUgd2hvIGtub3cgdGhhdCB0aGV5IGFyZSBleGFjdGx5IHJpZ2h0IChldmVuIGlmIHRoZXkgbWF5
IGJlDQo+IHdyb25nKSwgdGhlcmUgYXJlIGFsc28gb3RoZXIgcGVvcGxlIHdobyBtaWdodCB3YW50
IHRvIGdldCBhIChmZXcpDQo+IHBhaXIocykgb2YgZXllcyBtb3JlIG9uIHdoYXQgdGhleSBhcmUg
ZG9pbmcuDQoNCkFkZGVkIHBhcmVudGhldGljYWwgY2xhdXNlIHRvIHRoZSBpbnRybyB0ZXh0IGFi
b3V0IGFza2luZyBmb3IgcmV2aWV3Og0KICAgMy4gIElmIHRoZSByZWdpc3RyYXRpb24gcmVxdWVz
dCBpcyBmb3IgYSBQZXJtYW5lbnQgcmVnaXN0cmF0aW9uOiByZWdpc3RyYXRpb24gKG9yLA0KICAg
ICAgIG9wdGlvbmFsbHksIGZvciBhbnkgb3RoZXIgcmVnaXN0cmF0aW9uIGlmIGRlc2lyZWQpOg0K
DQo+IDcuMi4gUmVnaXN0cmF0aW9uIFByb2NlZHVyZXMNCj4gDQo+ICAgICBTb21lb25lIHdpc2hp
bmcgdG8gcmVnaXN0ZXIgYSBuZXcgc2NoZW1lIE1VU1Q6DQo+IA0KPiAgICAgMS4gIENoZWNrIHRo
ZSBJQU5BIFVSSSBTY2hlbWVzIHJlZ2lzdHJ5IHRvIHNlZSB3aGV0aGVyIHRoZXJlIGlzDQo+ICAg
ICAgICAgYWxyZWFkeSBhbiBlbnRyeSBmb3IgdGhlIGRlc2lyZWQgbmFtZS4gIElmIHRoZXJlIGlz
IGFscmVhZHkgYW4NCj4gICAgICAgICBlbnRyeSB1bmRlciB0aGUgbmFtZSwgY2hvb3NlIGEgZGlm
ZmVyZW50IHNjaGVtZSBuYW1lLCBvciB1cGRhdGUNCj4gICAgICAgICB0aGUgZXhpc3Rpbmcgc2No
ZW1lIHNwZWNpZmljYXRpb24uDQo+IFRoZSBsYXN0IGNsYXVzZSBtYXkgYmUgaW50ZXJwcmV0ZWQg
dG8gYWxsb3cgaGlqYWNraW5nLiBJdCBzaG91bGQgYmUgbWFkZQ0KPiBjbGVhciB0aGF0IHRoaXMg
aXNuJ3QgdGhlIGludGVudC4NCg0KRGVsZXRlZCBsYXN0IGNsYXVzZS4NCiANCj4gICAgIDIuICBQ
cmVwYXJlIGEgc2NoZW1lIHJlZ2lzdHJhdGlvbiByZXF1ZXN0IHVzaW5nIHRoZSB0ZW1wbGF0ZQ0K
PiAgICAgICAgIHNwZWNpZmllZCBpbiBTZWN0aW9uIDcuNC4NCj4gSW4gdGhpcyBwYXJhZ3JhcGgs
IGl0IHNob3VsZCBiZSBtYWRlIGNsZWFyIHRoYXQgdGhlIHRlbXBsYXRlIHNob3VsZCBiZQ0KPiBj
b21wbGV0ZSBvbiBpdHMgb3duLiBBcyBhbiBleGFtcGxlLA0KPiAgICAgU2NoZW1lIHN5bnRheDoN
Cj4gICAgICAgIFNlZSB0aGUgc3ludGF4IGRlZmluaXRpb24gaW4gc2VjdGlvbiBGT08uDQo+IGlz
IGJhZCwgYnV0DQo+ICAgICBTY2hlbWUgc3ludGF4Og0KPiAgICAgICAgU2VlIHRoZSBzeW50YXgg
ZGVmaW5pdGlvbiBpbiBzZWN0aW9uIEZPTyBvZiB0aGUgQkFSIHNwZWNpZmljYXRpb24uDQo+IG1h
eSBiZSBva2F5LCBldmVuIGlmIGl0IHJlYWRzIHNvbWV3aGF0IHJlZHVuZGFudGx5IHdoZW4gaW5z
aWRlIHRoZSBCQVINCj4gc3BlY2lmaWNhdGlvbiBpdHNlbGYuDQoNCkNoYW5nZWQgYXMgZm9sbG93
czoNCk9MRDogVGhpcyB0ZW1wbGF0ZSBkZXNjcmliZXMgdGhlIGZpZWxkcyB0aGF0IE1VU1QgYmUg
c3VwcGxpZWQgaW4gYQ0KT0xEOiBzY2hlbWUgcmVnaXN0cmF0aW9uIHJlcXVlc3Q6DQoNCk5FVzog
VGhpcyB0ZW1wbGF0ZSBkZXNjcmliZXMgdGhlIGZpZWxkcyB0aGF0IE1VU1QgYmUgc3VwcGxpZWQg
aW4gYQ0KTkVXOiBzY2hlbWUgcmVnaXN0cmF0aW9uIHJlcXVlc3QsIHN1aXRhYmxlIGZvciBhZGRp
bmcgdG8gdGhlIHJlZ2lzdHJ5Og0KDQpTZWUgYWxzbyB0aGUgcmVzcG9uc2UgdG8gdGhlIHRlbXBs
YXRlIGZpZWxkcyBwb2ludCBiZWxvdywgd2hpY2ggZ29lcw0KdG9nZXRoZXIgd2l0aCB0aGUgYWJv
dmUgY2hhbmdlLg0KDQo+ICAgICAgICAgMi4gIFNlbmQgYSBjb3B5IG9mIHRoZSBjb21wbGV0ZWQg
dGVtcGxhdGUgb3IgYSBwb2ludGVyIHRvIHRoZQ0KPiAgICAgICAgICAgICBjb250YWluaW5nIGRv
Y3VtZW50ICh3aXRoIHNwZWNpZmljIHJlZmVyZW5jZSB0byB0aGUgc2VjdGlvbg0KPiAgICAgICAg
ICAgICB3aXRoIHRoZSBjb21wbGV0ZWQgdGVtcGxhdGUpIHRvIHRoZSBtYWlsaW5nIGxpc3QgdXJp
LQ0KPiAgICAgICAgICAgICByZXZpZXdAaWV0Zi5vcmcgLCByZXF1ZXN0aW5nIHJldmlldy4NCj4g
SXQgc2hvdWxkIGJlIG1hZGUgY2xlYXIgdGhhdCBzZW5kaW5nIGEgZnVsbCBjb3B5IG9mIHRoZSB0
ZW1wbGF0ZSBpcw0KPiBzdHJvbmdseSBwcmVmZXJyZWQsIGJlY2F1c2UgaXQgc2lnbmlmaWNhbnRs
eSBpbmNyZWFzZXMgdGhlIGNoYW5jZSBhbmQNCj4gdGltZWxpbmVzcyBvZiBjb21tZW50cy4NCg0K
QWxsIHRoZSB0ZWNobmljYWwgaW5mb3JtYXRpb24gbmVlZGVkIHRvIHJldmlldyBpcyBubyBsb25n
ZXIgaW4gdGhlIA0KdGVtcGxhdGUsIHBlciBXRyBjb25zZW5zdXMuICBUaGUgc2NoZW1lIHN5bnRh
eCwgc2NoZW1lIHNlbWFudGljcywNCmVuY29kaW5nIGNvbnNpZGVyYXRpb25zLCBpbnRlcm9wZXJh
YmlsaXR5IGNvbnNpZGVyYXRpb25zLCBhbmQgc2VjdXJpdHkNCmNvbnNpZGVyYXRpb25zIHNlY3Rp
b25zIGFyZSBub3cgb25seSBpbiB0aGUgc2NoZW1lIGRlZmluaW5nDQpkb2N1bWVudCBub3QgdGhl
IHJlcXVlc3QvdGVtcGxhdGUgaXRzZWxmLiAgIChBcyBhIHJlbWluZGVyLCB0aGF0IGNoYW5nZQ0K
d2FzIGRvbmUgYmVjYXVzZSAoYSkgdGhpcmQtcGFydHkgcmVnaXN0cmF0aW9ucyBkb24ndCBrbm93
IGl0IGFuZCBzbw0KY2Fubm90IHJlcXVpcmUgaXQsIGFuZCAoYikgd2UgYWdyZWVkIHRvIGxvd2Vy
IHRoZSBiYXIgZm9yIHByb3Zpc2lvbmFsDQpzbyBub3RoaW5nIGlzIHJlcXVpcmVkIGJleW9uZCB3
aGF0IGEgdGhpcmQtcGFydHkgcmVnaXN0cmF0aW9uIHdvdWxkDQpyZXF1aXJlLiAgIEl0J3Mgc3Rp
bGwgYWxsb3dlZCBhbmQgZW5jb3VyYWdlZCBpbiBhIHJlZmVyZW5jZWQgZG9jdW1lbnQNCnRob3Vn
aCwgaWYgYXZhaWxhYmxlLikNCg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEZvcg0KPiAgICAgICAgICAgICBleGFt
cGxlLCBnZW5lcmFsIGRpc2N1c3Npb24gb2YgVVJJIHN5bnRhY3RpY2FsIGlzc3VlcyBjb3VsZA0K
PiAgICAgICAgICAgICBiZSBkaXNjdXNzZWQgb24gdXJpQHczLm9yZzsgc2NoZW1lcyBmb3IgYSBu
ZXR3b3JrIHByb3RvY29sDQo+ICAgICAgICAgICAgIGNvdWxkIGJlIGRpc2N1c3NlZCBvbiBhIG1h
aWxpbmcgbGlzdCBmb3IgdGhhdCBwcm90b2NvbC4NCj4gQ2hhbmdlICJjb3VsZCIgdG8gIm91Z2h0
IiBvciAiY2FuIiAodHdvIHRpbWVzKS4NCg0KRG9uZQ0KIA0KPiAgICAgNC4gIFN1Ym1pdCB0aGUg
KHBvc3NpYmx5IHVwZGF0ZWQpIHJlZ2lzdHJhdGlvbiB0ZW1wbGF0ZSAob3IgcG9pbnRlcg0KPiAg
ICAgICAgIHRvIGRvY3VtZW50IGNvbnRhaW5pbmcgaXQpIHRvIElBTkEgYXQgaWFuYUBpYW5hLm9y
Zy4NCj4gSXQgbWF5IGJlIG9idmlvdXMgdG8gaW5zaWRlcnMsIGJ1dCB3b3J0aCBwb2ludGluZyBv
dXQgYmVjYXVzZSB3ZSB3YW50IHRvDQo+IHJlYWNoIG91dHNpZGVycywgdG9vOiBJdCBpcyBpbXBv
cnRhbnQgdG8gbm90ZSB0aGF0IHN1Ym1pc3Npb24gdG8gSUFOQQ0KPiBmb3IgcmVnaXN0cmF0aW9u
IGRvZXNuJ3QgaGFwcGVuIGF1dG9tYXRpY2FsbHkgYnV0IGhhcyB0byBiZSBkb25lIGJ5IHRoZQ0K
PiByZWdpc3RyYW50Lg0KDQpDby1hdXRob3JzIHRob3VnaHQgaXQgd2FzIGFscmVhZHkgb2J2aW91
cyBlbm91Z2ggaW4gdmFyaW91cyBwbGFjZXMgaW4gdGhlIGRvYy4NCg0KPiAgICAgMS4gIElBTkEg
Y2hlY2tzIHRoZSBzdWJtaXNzaW9uIGZvciBjb21wbGV0ZW5lc3M7IGlmIHNlY3Rpb25zIG9mIHRo
ZQ0KPiAgICAgICAgIHRlbXBsYXRlIGFyZSBtaXNzaW5nIG9yIGFueSBjaXRhdGlvbnMgYXJlIG5v
dCBjb3JyZWN0LCBJQU5BIHdpbGwNCj4gICAgICAgICByZWplY3QgdGhlIHJlZ2lzdHJhdGlvbiBy
ZXF1ZXN0Lg0KPiBBZ2FpbiwgaXQgbWF5IGJlIG9idmlvdXMgdG8gaW5zaWRlcnMsIGJ1dCB3b3J0
aCBhZGRpbmc6IFRoaXMgZG9lc24ndA0KPiBwcmVjbHVkZSBuZXcsIGZpeGVkIHN1Ym1pc3Npb25z
Lg0KDQpBZGRlZCAiQSByZWdpc3RyYW50IGNhbiByZXN1Ym1pdCBhIGNvcnJlY3RlZCByZXF1ZXN0
IGlmIGRlc2lyZWQuIg0KDQo+ICAgICAzLiAgT3RoZXJ3aXNlLCBJQU5BIGVudGVycyB0aGUgcmVn
aXN0cmF0aW9uIHJlcXVlc3QgaW4gdGhlIElBTkENCj4gICAgICAgICByZWdpc3RyeSwgd2l0aCBz
dGF0dXMgbWFya2VkIGFzICJQZW5kaW5nIFJldmlldyIgYW5kIHRoZQ0KPiAgICAgICAgIHJlbWFp
bmRlciBvZiB0aGlzIHNlY3Rpb24gYXBwbGllcy4NCj4gUGxlYXNlIGFkZCBhIGNvbW1hIGFmdGVy
ICJQZW5kaW5nIFJldmlldyIgKGVuZCBvZiAnd2l0aCcgY2xhdXNlKS4NCg0KRG9uZQ0KIA0KPiAg
ICAgNi4gIEluIHRoZSBjYXNlIG9mIGEgUGVybWFuZW50IHJlZ2lzdHJhdGlvbiByZXF1ZXN0LCB0
aGUgRGVzaWduYXRlZA0KPiAgICAgICAgIEV4cGVydCBtYXk6DQo+ICAgICAgICAgKiAgUmVxdWVz
dCBhZGRpdGlvbmFsIHJldmlldyBvciBkaXNjdXNzaW9uLCBhcyBuZWNlc3NhcnkuDQo+IEFnYWlu
IHRoaXMgbWF5IGJlIG9idmlvdXMgdG8gaW5zaWRlcnMsIGJ1dCBpdCBtYXkgYmUgd29ydGggc2F5
aW5nIHRoYXQNCj4gdGhpcyBzaG91bGQgYXMgbXVjaCBhcyBwb3NzaWJsZSBiZSBjb25kdWN0ZWQg
b24gcHVibGljIG1haWxpbmcgbGlzdHMuDQoNCldlIGZlbHQgdGhpcyBzaG91bGQgYmUgbGVmdCB1
cCB0byB0aGUgRGVzaWduYXRlZCBFeHBlcnQgdG8gZG8gdGhlIHJpZ2h0IHRoaW5nLg0KKEkuZS4g
bm8gY29uc2Vuc3VzIHRvIHN1Z2dlc3QgbW9yZSB0aGFuIHRoYXQuKQ0KDQo+ICAgICBFaXRoZXIg
YmFzZWQgb24gYW4gZXhwbGljaXQgcmVxdWVzdCBvciBpbmRlcGVuZGVudGx5IGluaXRpYXRlZCwg
dGhlDQo+ICAgICBEZXNpZ25hdGVkIEV4cGVydCBvciBJRVNHIGNhbiByZXF1ZXN0IHRoZSB1cGdy
YWRlIG9mIGEgJ3Byb3Zpc2lvbmFsJw0KPiAgICAgcmVnaXN0cmF0aW9uIHRvIGEgJ3Blcm1hbmVu
dCcgb25lLg0KPiAiSUVTRyIgLT4gInRoZSBJRVNHIg0KDQpEb25lDQoNCj4gSXQgd291bGQgcHJv
YmFibHkgYmUgYmV0dGVyIGlmIHRoZSBwYXJhZ3JhcGggc3RhcnRpbmcgd2l0aCB0aGUgYWJvdmUN
Cj4gbGluZXMgd291bGQgbW92ZSBmcm9tIHRoZSBlbmQgb2Ygc2VjdGlvbiA3LjIgdG8gdGhlIGVu
ZCBvZiBzZWN0aW9uIDcuMy4NCg0KU2VjdGlvbiA3LjIgaXMgYWJvdXQgbmV3IHJlZ2lzdHJhdGlv
bnMgYW5kIDcuMyBpcyBhYm91dCBsYXRlciB1cGRhdGVzIHRvIG9uZS4NClNvIHRoZSBtZWFuaW5n
IGlzIGRpZmZlcmVudC4NCg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIFR5cGljYWxseSB0aGlzIHdvdWxkIG9ubHkNCj4gICAgIG9jY3VyIGlmIHRoZSB1c2Ug
aXMgY29uc2lkZXJlZCBhIHN0YW5kYXJkIChub3QgbmVjZXNzYXJpbHkgYW4gSUVURg0KPiAgICAg
c3RhbmRhcmQpLg0KPiBBIHN0YW5kYXJkIG1heSBiZSB1c2VkLCBidXQgJ3VzZScgaXNuJ3QgYSBz
dGFuZGFyZC4gRWl0aGVyIHNheSAidXNlIGlzDQo+IGNvbnNpZGVyZWQgdG8gYmUgdmVyeSB3aWRl
c3ByZWFkIiAoSSdkIGF2b2lkIHRoZSB3b3JkICJzdGFuZGFyZCIgaW4gdGhhdA0KPiBzZW5zZSkg
YW5kIHJlbW92ZSB0aGUgIklFVEYgc3RhbmRhcmQiIHBhcmVudGhldGljYWwsIG9yIGNoYW5nZSB0
byAiaWYNCj4gdGhlIHNjaGVtZSBpcyBkZWZpbmVkIGluIGEgc3RhbmRhcmQiIChpbiB0aGF0IGNh
c2UgIklFVEYgc3RhbmRhcmQiDQo+IHNob3VsZCBiZSBjaGFuZ2VkIHRvIChJRVRGKSBJbnRlcm5l
dCBTdGFuZGFyZCkuDQoNClRoaXMgaXMganVzdCBleHBsYWluaW5nIHdoYXQgdGhlIGV4aXN0aW5n
IERFIChHcmFoYW0pIHNhaWQgd291bGQgYXBwbHksDQphbmQgaXMgaGVyZSBqdXN0IGluIGNhc2Ug
dGhlIERFIGNoYW5nZXMgYXQgc29tZSBwb2ludCBkb3duIHRoZSByb2FkLg0KVGhpcyB0ZXh0IGlz
IGVzc2VudGlhbGx5IHN0cmFpZ2h0IGZyb20gR3JhaGFtIGFuZCB0YWtlcyBpbnRvIGFjY291bnQg
dGhpbmdzDQp0aGUgREUgY29uc2lkZXJzIGEgImRlIGZhY3RvIiBzdGFuZGFyZC4gIFRoaXMgaXMg
bm90IG5vcm1hdGl2ZSBndWlkYW5jZSwNCml0J3MganVzdCBhICJ0eXBpY2FsbHkiIGluZm9ybWF0
aW9uYWwgYml0Lg0KDQo+IDcuNC4gVVJJIFNjaGVtZSBSZWdpc3RyYXRpb24gVGVtcGxhdGUNCj4g
ICAgIENvbnRhY3Q6DQo+ICAgICAgIFBlcnNvbiAoaW5jbHVkaW5nIGNvbnRhY3QgaW5mb3JtYXRp
b24pIHRvIGNvbnRhY3QgZm9yIGZ1cnRoZXINCj4gICAgICAgaW5mb3JtYXRpb24uDQo+IA0KPiAg
ICAgQXV0aG9yL0NoYW5nZSBjb250cm9sbGVyOg0KPiAgICAgICBQZXJzb24gKGluY2x1ZGluZyBj
b250YWN0IGluZm9ybWF0aW9uKSBhdXRob3JpemVkIHRvIGNoYW5nZSB0aGlzLg0KPiBUaGlzIGlz
IGEgcHJvYmxlbSB3aXRoIG1hbnkgb3RoZXIgcmVnaXN0cmF0aW9uIHRlbXBsYXRlcywgdG9vLCB3
aGljaCB3ZQ0KPiBzaG91bGQgZml4IHdoZW5ldmVyIHdlIGNhbjogSSBoYXZlIHNlZW4gbWFueSBw
ZW9wbGUgc3RydWdnbGluZyB3aXRoIHRoaXMNCj4gZGlzdGluY3Rpb24uIEl0J3MgcmFyZWx5IHZl
cnkgdXNlZnVsLg0KPiANCj4gV2hhdCBpcyB1c2VmdWwgaW4gc29tZSBjYXNlcyBpcyB0byBtYWtl
IGEgZGlzdGluY3Rpb24gYmV0d2VlbiB0aGUNCj4gc3VibWl0dGVyL2F1dGhvciBhbmQgdGhlIG9y
Z2FuaXphdGlvbiBpbiBjaGFyZ2UsIGJ1dCAiQXV0aG9yL0NoYW5nZQ0KPiBjb250cm9sbGVyIiBt
aXhlcyB0aGUgdHdvLiBUaGUgbWluaW11bSBpbXByb3ZlbWVudCB0aGF0IEknZCBwcm9wb3NlIGlz
DQo+IHRoZSBmb2xsb3dpbmc6DQo+ICAgICBBdXRob3IvQ29udGFjdDoNCj4gICAgICAgUGVyc29u
IChpbmNsdWRpbmcgY29udGFjdCBpbmZvcm1hdGlvbikgdG8gY29udGFjdCBmb3IgZnVydGhlcg0K
PiAgICAgICBpbmZvcm1hdGlvbi4NCj4gDQo+ICAgICBDaGFuZ2UgY29udHJvbGxlcjoNCj4gICAg
ICAgT3JnYW5pemF0aW9uIG9yIHBlcnNvbiAoaW5jbHVkaW5nIGNvbnRhY3QgaW5mb3JtYXRpb24p
IGF1dGhvcml6ZWQNCj4gICAgICAgdG8gY2hhbmdlIHRoaXMuDQo+IFRoaXMgd291bGQgYXQgbGVh
c3QgbWFrZSBpdCBtb2RlcmF0ZWx5IGVhc3kgZm9yIHJlZ2lzdHJhdGlvbnMgZnJvbSB0aGUgSUVU
Ri4NCg0KUmVtb3ZlZCAiQXV0aG9yIiBmcm9tIHRoZSBsYWJlbCBhbmQgYWRkZWQgIihvZnRlbiB0
aGUgYXV0aG9yKSIgaW50byB0aGUNCmNoYW5nZSBjb250cm9sbGVyIHRleHQuICAgVW5sZXNzIHRo
ZSBhdXRob3IgaXMgdGhlIGN1cnJlbnQgY2hhbmdlIGNvbnRyb2xsZXINCm9yIHRoZSBjdXJyZW50
IGNvbnRhY3QsIHRoZSByZWdpc3RyeSBkb2Vzbid0IG5lZWQgdG8gdHJhY2sgdGhlIGF1dGhvciBw
ZXIgc2UNCg0KPiAgICAgVGhlIGZvbGxvd2luZyBmaWVsZHMgYXJlIG5vIGxvbmdlciByZXF1aXJl
ZCBpbiBhIHNjaGVtZSByZWdpc3RyYXRpb24NCj4gICAgIHJlcXVlc3QuICBUaGUgYW5zd2VycyBp
bnN0ZWFkIGJlbG9uZyBpbiB0aGUgc2NoZW1lIHNwZWNpZmljYXRpb24uDQo+ICJubyBsb25nZXIg
cmVxdWlyZWQiIGFuZCAiYmVsb25nIiBjb25mbGljdCwgaW4gdGhhdCAibm8gbG9uZ2VyIHJlcXVp
cmVkIg0KPiBkb2Vzbid0IGV4Y2x1ZGUgdGhlbSwgYnV0ICJiZWxvbmciIGRvZXMuICBJJ2QgcHJl
ZmVyIHRvIHNheSB0aGF0IGlmIHRoZXkNCj4gYXJlIHNob3J0IG9yIHZlcnkgaW1wb3J0YW50LCB0
aGV5IHNob3VsZCBiZSBnaXZlbiBpbiB0aGUgdGVtcGxhdGUsIGlmDQo+IHRoZXkgYXJlIGxlbmd0
aHksIHRoZXkgc2hvdWxkIGJlIGdpdmVuIHNlcGFyYXRlbHksIGFuZCBpZiB0aGV5IGFyZQ0KPiBp
cnJlbGV2YW50LCB0aGV5IGNhbiBiZSBpZ25vcmVkLg0KDQpBZ2FpbiBwZXIgV0cgY29uc2Vuc3Vz
IHRoZXkgYXJlIHJlbW92ZWQgZnJvbSB0aGUgdGVtcGxhdGUuDQoNCkRyYWZ0IC0wNSB1cGRhdGVz
IHRoZSB0ZXh0IG1hcmdpbmFsbHkgYXMgZm9sbG93czoNCg0KICAgVGhlIHByZXZpb3VzIHZlcnNp
b24gb2YgdGhpcyBzcGVjaWZpY2F0aW9uIHJlcXVpcmVkIHRoZSBmb2xsb3dpbmcNCiAgIGFkZGl0
aW9uYWwgZmllbGRzIGluIGEgc2NoZW1lIHJlZ2lzdHJhdGlvbiByZXF1ZXN0LiAgVGhlc2UgZmll
bGRzIGFyZQ0KICAgbm8gbG9uZ2VyIHBhcnQgb2YgdGhlIHRlbXBsYXRlLiAgVGhlIGFuc3dlcnMg
aW5zdGVhZCBiZWxvbmcgaW4gdGhlDQogICBzY2hlbWUgc3BlY2lmaWNhdGlvbi4NCg0KVGhlIGNv
LWF1dGhvcnMgYW5kIGRvYyBzaGVwaGVyZCB0b2dldGhlciBmZWx0IHRoYXQgYW55IG1vcmUgdGhh
biB0aGF0DQp3b3VsZCBwcm9iYWJseSBub3QgYmUgaW4gbGluZSB3aXRoIGRlY2xhcmVkIFdHIGNv
bnNlbnN1cy4NCg0KPiAgICAgSW50ZXJvcGVyYWJpbGl0eSBjb25zaWRlcmF0aW9uczoNCj4gICAg
ICAgICAgICAgICAgaW5hYmlsaXR5IHRvIHN1cHBvcnQgbXVsdGlieXRlIGNoYXJhY3RlciBzZXRz
Ow0KPiBUaGUgbW9kZXJuIEludGVybmV0LCBpbiBwYXJ0aWN1bGFyIGluIFVSSXMgYW5kIElSSXMs
IGRvZXMgaGF2ZQ0KPiBhYnNvbHV0ZWx5IG5vIG5lZWQgdG8gc3VwcG9ydCBtdWx0aWJ5dGUgY2hh
cmFjdGVyIHNldHMsIGFuZCBldmVuIGxlc3Mgb2YNCj4gYSBuZWVkIHRvIHVzZSBzdWNoIGEgdGVy
bSAoc2VlDQo+IGh0dHA6Ly93d3cudzMub3JnL01hcmtVcC9odG1sLXNwZWMvY2hhcnNldC1oYXJt
ZnVsLmh0bWwpLiBQbGVhc2UgY2hhbmdlDQo+IHRoaXMgdG8gc29tZXRoaW5nIGxpa2UNCj4gImlu
YWJpbGl0eSB0byBzdXBwb3J0IG5vbi1BU0NJSSBjaGFyYWN0ZXJzIi4NCg0KUmVtb3ZlZCBwaHJh
c2UsIHNpbmNlIGl0IHdhcyBqdXN0IG9uZSBvZiB0aHJlZSBleGFtcGxlcywgYW5kIHRoZXJlJ3Mg
YWxyZWFkeQ0Kb3RoZXIgdGV4dCBpbiB0aGUgZG9jIGFib3V0IGludGVybmF0aW9uYWxpemF0aW9u
Lg0KDQo+ICAgICBTY2hlbWUgc3ludGF4OiAgVGhlIGVudGlyZSByYW5nZSBvZiBhbGxvd2FibGUg
c3ludGF4IHNwZWNpZmllZCBpbg0KPiAgICAgICBbUkZDMzk4Nl0gaXMgYWxsb3dlZCBmb3IgImV4
YW1wbGUiIFVSSXMuDQo+IFBsZWFzZSBhZGQ6IFRoZSBlbnRpcmUgcmFuZ2Ugb2YgYWxsb3dhYmxl
IHN5bnRheCBzcGVjaWZpZWQgaW4gW1JGQzM5ODddDQo+IGlzIGFsbG93ZWQgZm9yICJleGFtcGxl
IiBJUklzLg0KDQpEb25lDQoNCj4gOC4xLiAiRXhhbXBsZSIgU2NoZW1lIFJlZ2lzdHJhdGlvbiBS
ZXF1ZXN0DQo+IFBsZWFzZSBjaGFuZ2UgdGhpcyB0aXRsZSB0byAiRXhhbXBsZSIgU2NoZW1lIFJl
Z2lzdHJhdGlvbiBUZW1wbGF0ZS4NCg0KTm90IGRvbmUgc2luY2UgdGhlIG1lYW5pbmcgaXMgZGlm
ZmVyZW50IChzZWUgZWFybGllciBkZWZpbml0aW9uIG9mICJ0ZW1wbGF0ZSIpLg0KDQo+IDEwLiBT
ZWN1cml0eSBDb25zaWRlcmF0aW9ucw0KPiAgICAgQWxsIHJlZ2lzdGVyZWQgdmFsdWVzIGFyZSBl
eHBlY3RlZCB0byBjb250YWluIGFjY3VyYXRlIHNlY3VyaXR5DQo+ICAgICBjb25zaWRlcmF0aW9u
IHNlY3Rpb25zOyAncGVybWFuZW50JyByZWdpc3RlcmVkIHNjaGVtZSBuYW1lcyBhcmUNCj4gICAg
IGV4cGVjdGVkIHRvIGNvbnRhaW4gY29tcGxldGUgZGVmaW5pdGlvbnMuDQo+IFdvcmRzIHN1Y2gg
YXMgImFjY3VyYXRlIiBhbmQgImNvbXBsZXRlIiBhcmUgd2lzaGZ1bCB0aGlua2luZy4gV2hlbiBp
dA0KPiBjb21lcyB0byBzZWN1cml0eSwgdGhlcmUgaXMgYWx3YXlzIHRoZSBjaGFuY2Ugb2YgYSBk
aXNjb3Zlcnkgb2YgbmV3DQo+IHNlY3VyaXR5IGlzc3Vlcy4gVGhpcyBzZWN0aW9uIHNob3VsZCBt
YWtlIGl0IGNsZWFyIHRoYXQgYmVzdCBlZmZvcnQgaXMNCj4gZXhwZWN0ZWQgb2YgdGhlIHJlZ2lz
dHJhbnRzLCBhbmQgdGhhdCB0aGlyZCBwYXJ0aWVzIG1heSByZXF1ZXN0IHRoZQ0KPiBhZGRpdGlv
biBvZiBuZXcgaXNzdWVzLCBidXQgdGhhdCB0aGUgc2VjdXJpdHkgaW5mb3JtYXRpb24gaW4gYSBz
Y2hlbWUNCj4gcmVnaXN0cmF0aW9uIHNob3VsZCBuZXZlciBiZSBzZWVuIGFzIGNvbXBsZXRlIGFu
ZCBmaW5hbC4NCg0KUmVwbGFjZWQgd2l0aCBhIHJlZmVyZW5jZSB0byBzZWN0aW9uIDMuNyB3aGlj
aCBhbHJlYWR5IGNvbnRhaW5lZCBiZXR0ZXIgdGV4dC4NCg0KRGF2ZQ0K


From nobody Thu Apr  2 14:30:32 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F0D51A6F07 for ; Thu,  2 Apr 2015 14:30:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id McHBHf1BYKzs for ; Thu,  2 Apr 2015 14:30:21 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC43E1A6F02 for ; Thu,  2 Apr 2015 14:30:21 -0700 (PDT)
Received: from [192.168.0.78] (unknown [120.149.147.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 3679C22E264 for ; Thu,  2 Apr 2015 17:30:17 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: Mark Nottingham 
In-Reply-To: <20150327163331.20999.18776.idtracker@ietfa.amsl.com>
Date: Fri, 3 Apr 2015 08:30:14 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: <7EC6D912-3211-44E0-A739-D43BA7214BD5@mnot.net>
References: <20150327163331.20999.18776.idtracker@ietfa.amsl.com>
To: IETF Apps Discuss 
X-Mailer: Apple Mail (2.2070.6)
Archived-At: 
Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-uri-scheme-reg-05.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 02 Apr 2015 21:30:26 -0000

Just a bit of feedback =E2=80=94

* The new text in Section 3 ("A scheme definition cannot override=E2=80=A6=
") seems like it's equally applicable to provisional schemes. I'd =
suggest moving this to 3.2 and then referring to it from Section 4 (as a =
MUST?).

* Section 4 constructs a conflicting requirement "=E2=80=A6 the =
following are REQUIRED: =E2=80=A6 The scheme definition SHOULD =E2=80=A6" =
 This is confusing =E2=80=94 is it REQUIRED or SHOULD? I'd suggest =
changing the start to "=E2=80=A6 the following requirements apply:".

Cheers,


> On 28 Mar 2015, at 3:33 am, internet-drafts@ietf.org wrote:
>=20
>=20
> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
> This draft is a work item of the Applications Area Working Group =
Working Group of the IETF.
>=20
>        Title           : Guidelines and Registration Procedures for =
URI Schemes
>        Authors         : Dave Thaler
>                          Tony Hansen
>                          Ted Hardie
>                          Larry Masinter
> 	Filename        : draft-ietf-appsawg-uri-scheme-reg-05.txt
> 	Pages           : 19
> 	Date            : 2015-03-27
>=20
> Abstract:
>   This document updates the guidelines and recommendations, as well as
>   the IANA registration processes, for the definition of Uniform
>   Resource Identifier (URI) schemes.  It obsoletes RFC 4395.
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-appsawg-uri-scheme-reg/
>=20
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-appsawg-uri-scheme-reg-05
>=20
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-uri-scheme-reg-05
>=20
>=20
> Please note that it may take a couple of minutes from the time of =
submission
> until the htmlized version and diff are available at tools.ietf.org.
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss

--
Mark Nottingham   https://www.mnot.net/





From nobody Fri Apr  3 09:18:30 2015
Return-Path: 
X-Original-To: expand-draft-ietf-appsawg-uri-scheme-reg.all@virtual.ietf.org
Delivered-To: apps-discuss@ietfa.amsl.com
Received: by ietfa.amsl.com (Postfix, from userid 65534) id 5AA211A0687; Thu,  2 Apr 2015 11:57:41 -0700 (PDT)
X-Original-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com
Delivered-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 351F51A19F7; Thu,  2 Apr 2015 11:57:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.19
X-Spam-Level: 
X-Spam-Status: No, score=-3.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rpy2G9JrJlCI; Thu,  2 Apr 2015 11:57:39 -0700 (PDT)
Received: from smtp1.lax.icann.org (smtp01.icann.org [192.0.33.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69B661A0687; Thu,  2 Apr 2015 11:57:39 -0700 (PDT)
Received: from request3.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp1.lax.icann.org (8.13.8/8.13.8) with ESMTP id t32Ivd45026660;  Thu, 2 Apr 2015 18:57:39 GMT
Received: by request3.lax.icann.org (Postfix, from userid 48) id 25382C2081F; Thu,  2 Apr 2015 18:57:39 +0000 (UTC)
RT-Owner: pearl.liang
From: "Pearl Liang via RT" 
In-Reply-To: <20150327192825.8728.9848.idtracker@ietfa.amsl.com>
References:  <20150327192825.8728.9848.idtracker@ietfa.amsl.com>
Message-ID: 
X-RT-Loop-Prevention: IANA
X-RT-Ticket: IANA #815901
X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/)
X-RT-Originator: pearl.liang@icann.org
Content-Type: text/plain; charset="utf-8"
X-RT-Original-Encoding: utf-8
Precedence: bulk
Date: Thu, 02 Apr 2015 18:57:39 +0000
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Archived-At: 
X-Mailman-Approved-At: Fri, 03 Apr 2015 09:18:29 -0700
Cc: appsawg-chairs@ietf.org, draft-ietf-appsawg-uri-scheme-reg.all@ietf.org, iesg@ietf.org
Subject: [apps-discuss] [IANA #815901] Evaluation:  to Best Current Practice
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: drafts-eval@iana.org
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 02 Apr 2015 18:57:41 -0000

IESG:

IANA OK. Comments in tracker.
IANA Actions - YES

This version is okay, as per Graham Klyne's review.  He just noted a few nits below:

----------

Running through my comments:


> Section 3.
>
> "For IETF Standards-Track documents, Permanent registration status is
> REQUIRED."
> Reading this now, I find the drafting here is potentially confusing.
> Suggest:
>
> "For URI schemes defined or normatively referenced by IETF Standards-
> Track
> documents, Permanent registration status is REQUIRED."

Looks good. (Is it the accepted style for this document to capitalize 
"Permanent" here?)


> Section 3.3
>
> "Schemes that are not intended to be used as locators SHOULD describe
> how the
> resource identified can be determined or accessed by software that
> obtains a URI
> of that scheme."
>
> This doesn't seem quite right to me. Schemes that are not intended to
> be used
> as locators aren't generally expected to be accessed by software
> (though they
> may be in particular circumstances).
>
> I think then point that needs to be made here is that there should be
> some
> defined structure of naming authority for the scheme, which is not
> necessarily
> interpretable by software. E.g., something like:
>
> "Schemes that are not intended to be used as locators SHOULD describe
> how the
> resource identified can be determined or accessed by an agent that
> obtains a URI
> of that scheme."

Looks good.

>
>
> Section 7.2:
>
> " 8. Once Expert Review approves registration for a given status,
> IANA
> adds the registration to the registry."
>
> I note that the scheme has already been added to the registry at prior
> step 3.
>
> Suggest:
>
> " 8. Once Expert Review approves registration for a given status,
> IANA
> updates the registration (per step 3) to indicate the approved
> status. "

Looks OK, but where it says "the "Pending Review" request is removed from the 
registry" I might add ", and the scheme remains as a provisional registration".

>
>
> Section 8:
>
> I was somewhat thrown by the heading of section 8.1.
>
> "8.1. "Example" Scheme Registration Request"
>
> I think the intent would be clearer if the section title were given
> as:
>
> "8.1. "Example" Scheme Registration Template"
>

This point has not been addressed, but I don't think it's a blocker.


-----------

Thank you,

Pearl Liang
ICANN


On Fri Mar 27 19:28:56 2015, iesg-secretary@ietf.org wrote:
> Evaluation for  can be found
> at
> http://datatracker.ietf.org/doc/draft-ietf-appsawg-uri-scheme-reg/
> 
> Last call to expire on: 2015-03-12 00:00 PDT
> 
> 
> Please return the full line with your position.
> 
> Yes  No-Objection  Discuss  Abstain
> Barry Leiba          [ X ]     [   ]      [   ]    [   ]
> 
> 
> Needs 9 more YES or NO OBJECTION positions to pass.
> 
> DISCUSSES AND COMMENTS
> ======================
> 
> ---- following is a DRAFT of message to be sent AFTER approval ---
> From: The IESG 
> To: IETF-Announce 
> Cc: RFC Editor 
> Subject: Protocol Action: 'Guidelines and Registration Procedures for
> URI Schemes' to Best Current Practice (draft-ietf-appsawg-uri-scheme-
> reg-04.txt)
> 
> The IESG has approved the following document:
> - 'Guidelines and Registration Procedures for URI Schemes'
>   (draft-ietf-appsawg-uri-scheme-reg-04.txt) as Best Current Practice
> 
> This document is the product of the Applications Area Working Group.
> 
> The IESG contact persons are Pete Resnick and Barry Leiba.
> 
> A URL of this Internet Draft is:
> http://datatracker.ietf.org/doc/draft-ietf-appsawg-uri-scheme-reg/
> 
> 
> 
> 
> 
> Technical Summary
> 
> Based on experience with registering provisional and permanent URIs,
> this document
> updates RFC 4395 (which was itself a BCP itself). In particular rules
> for provisional
> registrations were relaxed to make registrations easier.
> 
> Review and Consensus
> 
> This document was reviewed by people who had to deal with URI
> definitions and
> registrations, including former Apps ADs and the current URI
> registration expert reviewer.
> The document had thorough and sufficient reviews.
> 
> Personnel
> 
> The document shepherd is Alexey Melnikov.  The Responsible Area
> Director is Barry
> Leiba.



From nobody Fri Apr  3 09:18:32 2015
Return-Path: 
X-Original-To: expand-draft-ietf-appsawg-uri-scheme-reg.all@virtual.ietf.org
Delivered-To: apps-discuss@ietfa.amsl.com
Received: by ietfa.amsl.com (Postfix, from userid 65534) id A933D1A1A76; Thu,  2 Apr 2015 13:39:41 -0700 (PDT)
X-Original-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com
Delivered-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8135A1A1A63; Thu,  2 Apr 2015 13:39:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.19
X-Spam-Level: 
X-Spam-Status: No, score=-3.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pq5DkupqX1bs; Thu,  2 Apr 2015 13:39:34 -0700 (PDT)
Received: from smtp1.lax.icann.org (smtp01.icann.org [192.0.33.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE61F1A1A5A; Thu,  2 Apr 2015 13:39:32 -0700 (PDT)
Received: from request3.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp1.lax.icann.org (8.13.8/8.13.8) with ESMTP id t32KdWx4031341;  Thu, 2 Apr 2015 20:39:32 GMT
Received: by request3.lax.icann.org (Postfix, from userid 48) id A894BC207E8; Thu,  2 Apr 2015 20:39:32 +0000 (UTC)
RT-Owner: Nobody
From: "Pearl Liang via RT" 
In-Reply-To: 
References:     
Message-ID: 
X-RT-Loop-Prevention: IANA
X-RT-Ticket: IANA #816939
X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/)
X-RT-Originator: pearl.liang@icann.org
Content-Type: text/plain; charset="utf-8"
X-RT-Original-Encoding: utf-8
Precedence: bulk
Date: Thu, 02 Apr 2015 20:39:32 +0000
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Archived-At: 
X-Mailman-Approved-At: Fri, 03 Apr 2015 09:18:29 -0700
Cc: appsawg-chairs@ietf.org, draft-ietf-appsawg-uri-scheme-reg.all@ietf.org, iesg@ietf.org
Subject: [apps-discuss] [IANA #816939] RE: Expert Review - draft-ietf-appsawg-uri-scheme-reg-04
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: drafts-expert-review@iana.org
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 02 Apr 2015 20:39:41 -0000

Dave,

I've forwarded Graham's comments for version -05 in the Evaluation ticket
under an IANA ticket #815901.  Did you receive that message?

Thanks,
~pl



On Thu Apr 02 19:18:00 2015, dthaler@microsoft.com wrote:
> Thanks for the review.  Below is what the co-authors did in response
> in -05:
> 
> > -----Original Message-----
> > From: Pearl Liang via RT [mailto:drafts-expert-review@iana.org]
> > Sent: Monday, March 16, 2015 10:59 AM
> > Cc: draft-ietf-appsawg-uri-scheme-reg.all@ietf.org; appsawg-
> > chairs@ietf.org;
> > apps-discuss@ietf.org; iesg@ietf.org
> > Subject: [IANA #812412] Expert Review - draft-ietf-appsawg-uri-
> > scheme-reg-04
> >
> > Dear Authors,
> >
> > Upon review, Graham Klyne has approved the requested new URI scheme
> > and
> > raised some comments and question:
> >
> > ...
> >
> > I'm also taking this opportunity to review the current version and
> > make some
> > final comments. These are pretty much all editorial, and I'm assuming
> > they
> > could be addressed (or not) in any AUTH48 period without requiring
> > further
> > public review.
> >
> >
> > Section 3.
> >
> > "For IETF Standards-Track documents, Permanent registration status is
> > REQUIRED."
> > Reading this now, I find the drafting here is potentially confusing.
> > Suggest:
> >
> > "For URI schemes defined or normatively referenced by IETF Standards-
> > Track
> > documents, Permanent registration status is REQUIRED."
> 
> This was the subject of the rest of this thread, with comments from
> the AD,
> the doc shepherd, co-authors, and other WG participants.
> 
> We thought the concensus was to accept this and so made the change.
> (I see this discussion continues regarding -05...)
> 
> > Section 3.3
> >
> > "Schemes that are not intended to be used as locators SHOULD describe
> > how
> > the
> > resource identified can be determined or accessed by software that
> > obtains a
> > URI
> > of that scheme."
> >
> > This doesn't seem quite right to me. Schemes that are not intended to
> > be
> > used
> > as locators aren't generally expected to be accessed by software
> > (though they
> > may be in particular circumstances).
> >
> > I think then point that needs to be made here is that there should be
> > some
> > defined structure of naming authority for the scheme, which is not
> > necessarily
> > interpretable by software. E.g., something like:
> >
> > "Schemes that are not intended to be used as locators SHOULD describe
> > how
> > the
> > resource identified can be determined or accessed by an agent that
> > obtains a
> > URI
> > of that scheme."
> 
> The term "agent" is undefined and as co-authors we think the statement
> was
> more correct as is.  In any case, the language here is unchanged from
> RFC 4395,
> and so was kept as it appeared in RFC 4395, lacking consensus to
> change.
> 
> > Section 7.2:
> >
> > " 8. Once Expert Review approves registration for a given status,
> > IANA
> > adds the registration to the registry."
> >
> > I note that the scheme has already been added to the registry at
> > prior step 3.
> >
> > Suggest:
> >
> > " 8. Once Expert Review approves registration for a given status,
> > IANA
> > updates the registration (per step 3) to indicate the approved
> > status. "
> 
> Done.
> 
> > Section 8:
> >
> > I was somewhat thrown by the heading of section 8.1.
> >
> > "8.1. "Example" Scheme Registration Request"
> >
> > I think the intent would be clearer if the section title were given
> > as:
> >
> > "8.1. "Example" Scheme Registration Template"
> 
> Not done.  The term "template" is defined in section 2 as being the
> (unfilled) form.   The term "registration request" is defined in the
> doc
> as being the completed form that gets submitted.  Tweaked wording
> of section 2 to make this even more clear.
> 
> > - Regarding the Pending Review Status:
> >
> > Section 7.2, a step 3 said:
> >
> > 3. Otherwise, IANA enters the registration request in the IANA
> > registry, with status marked as "Pending Review" and the
> > remainder of this section applies.
> >
> > Question: Shall IANA remove the "Pending Review" URI scheme from the
> > registry
> > if a new 'requested' permanent URI scheme is not being accepted after
> > DE
> > reviewed (step 4/5)?  Or it is okay to keep the Pending Review entry
> > in the
> > such status
> > as long as it is under "additional review or discussion"?
> >
> > The scheme may not be approved for its requested status. If not
> > accepted, I
> > imagine would would revert to "provisional" status (which does not
> > require
> > approval if it meets the minimal criteria set out). But I agree that
> > this
> > should probably be clarified.
> 
> The intent was that if it is rejected, then it no longer appears in
> the registry
>   (same as if a rejection happened with RFC 4395, no change intended).
> Updated point 8 of the process to explicitly state this.
> 
> Dave




From nobody Fri Apr  3 09:18:33 2015
Return-Path: 
X-Original-To: expand-draft-ietf-appsawg-multipart-form-data.all@virtual.ietf.org
Delivered-To: apps-discuss@ietfa.amsl.com
Received: by ietfa.amsl.com (Postfix, from userid 65534) id AE1951A916E; Fri,  3 Apr 2015 00:35:05 -0700 (PDT)
X-Original-To: xfilter-draft-ietf-appsawg-multipart-form-data.all@ietfa.amsl.com
Delivered-To: xfilter-draft-ietf-appsawg-multipart-form-data.all@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 916481A916C for ; Fri,  3 Apr 2015 00:35:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.333
X-Spam-Level: 
X-Spam-Status: No, score=-1.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AWCFmjwjRol6 for ; Fri,  3 Apr 2015 00:35:04 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F1511A9169 for ; Fri,  3 Apr 2015 00:35:04 -0700 (PDT)
Received: from mail-wi0-f178.google.com ([209.85.212.178]:38194) by zinfandel.tools.ietf.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Ydw86-0006SN-Fg for draft-ietf-appsawg-multipart-form-data.all@tools.ietf.org; Fri, 03 Apr 2015 00:35:03 -0700
Received: by wibgn9 with SMTP id gn9so131498562wib.1 for ; Fri, 03 Apr 2015 00:34:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:to:cc:subject:date:message-id:mime-version:content-type :thread-index:content-language; bh=0FeAybbdRJfMvwUWX2CP1ifROHecZOhNalQ2rgCqQXI=; b=eaYs0H6oHTj5oWiy4ke3RInJi2koxp/tzs73TcDOkqVfrpWHgA3tPsBWIWbYSsGBkv AlOiAKLz92HiIqRAs+J5y4P95SVNFT0MqJt+hbRKFko6V3I2AMnSYhBcWHZUMUx5Dg7s 1NEA4MrnHU7zxXsqGkgxK9ZUa2FGiy++suWrmUSI6OrAOjXru/MXeuLAc5rBvCp9c/hB Q4RLfCKVQeGop/6P2kr8BSnzlKlx6BMYy+NAgX9IK5e56tjKLdQtbKfaInh/aLQhq3se kRWsokDp9uv3274QRzjA4bSo0qG5moq1os847uzctc4h1H5j+v+ku83KCh3G0sL7C8Mi A+Bw==
X-Received: by 10.180.75.73 with SMTP id a9mr3000316wiw.45.1428046489927; Fri, 03 Apr 2015 00:34:49 -0700 (PDT)
Received: from RoniE (bzq-79-177-166-235.red.bezeqint.net. [79.177.166.235]) by mx.google.com with ESMTPSA id ed14sm1584898wic.11.2015.04.03.00.34.47 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 03 Apr 2015 00:34:48 -0700 (PDT)
From: "Roni Even" 
To: 
Date: Fri, 3 Apr 2015 10:34:42 +0300
Message-ID: <020201d06de0$a8379060$f8a6b120$@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0203_01D06DF9.CD858BB0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdBt4KYrAlf7IyIHQuyzgn1uOJAZ4Q==
Content-Language: en-us
X-SA-Exim-Connect-IP: 209.85.212.178
X-SA-Exim-Rcpt-To: draft-ietf-appsawg-multipart-form-data.all@tools.ietf.org
X-SA-Exim-Mail-From: ron.even.tlv@gmail.com
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org)
Resent-To: draft-ietf-appsawg-multipart-form-data.all@ietf.org
Resent-Message-Id: <20150403073504.0F1511A9169@ietfa.amsl.com>
Resent-Date: Fri,  3 Apr 2015 00:35:04 -0700 (PDT)
Resent-From: ron.even.tlv@gmail.com
Archived-At: 
Archived-At: 
X-Mailman-Approved-At: Fri, 03 Apr 2015 09:18:29 -0700
Cc: gen-art@ietf.org, ietf@ietf.org
Subject: [apps-discuss] Gen-ART LC review of draft-ietf-appsawg-multipart-form-data-08
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 03 Apr 2015 07:35:05 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0203_01D06DF9.CD858BB0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
.

Please resolve these comments along with any other Last Call comments you
may receive.

Document:  draft-ietf-appsawg-multipart-form-data-08

Reviewer: Roni Even

Review Date:2015-4-3

IETF LC End Date: 2015-4-6

IESG Telechat date: 

 

Summary: This draft is almost ready for publication as an Standard Track
RFC.

 

 

Major issues:

 

Minor issues:

 

In the IANA considerations I think you missed to mention the Content
Disposition Vlaues form-data

See  
http://www.iana.org/assignments/cont-disp/cont-disp.xhtml 

 

 

Nits/editorial comments:

 


------=_NextPart_000_0203_01D06DF9.CD858BB0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


I am the assigned Gen-ART =
reviewer for this draft. For background on Gen-ART, please see the FAQ =
at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq=
>.
Please resolve these =
comments along with any other Last Call comments you may =
receive.
Document:&n=
bsp; draft-ietf-appsawg-multipart-form-data-08
Reviewer: =
Roni Even
Review =
Date:2015–4-3
IETF LC =
End Date: 2015–4-6
IESG =
Telechat date: 
 =

Summary: =
This draft is almost ready for publication as an Standard Track  =
RFC.
 =

 =

Major =
issues:
 =

Minor =
issues:
 =

In the =
IANA considerations I think you missed to mention the Content =
Disposition Vlaues form-data
See =
http://www.=
iana.org/assignments/cont-disp/cont-disp.xhtml =

 =

 =

Nits/editorial =
comments:
 

------=_NextPart_000_0203_01D06DF9.CD858BB0--


From nobody Fri Apr  3 09:18:34 2015
Return-Path: 
X-Original-To: expand-draft-ietf-appsawg-uri-scheme-reg.all@virtual.ietf.org
Delivered-To: apps-discuss@ietfa.amsl.com
Received: by ietfa.amsl.com (Postfix, from userid 65534) id 7790E1A88EC; Fri,  3 Apr 2015 04:32:43 -0700 (PDT)
X-Original-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com
Delivered-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 581CC1A88DB for ; Fri,  3 Apr 2015 04:32:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.898
X-Spam-Level: 
X-Spam-Status: No, score=-101.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_FAIL=0.001, USER_IN_WHITELIST=-100] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-ZhWmUf1Uyq for ; Fri,  3 Apr 2015 04:32:40 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F8F81A87E6 for ; Fri,  3 Apr 2015 04:32:36 -0700 (PDT)
Received: from mail-bn1bbn0109.outbound.protection.outlook.com ([157.56.111.109]:19264 helo=na01-bn1-obe.outbound.protection.outlook.com) by zinfandel.tools.ietf.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Ydzpv-0005Oq-W8 for draft-ietf-appsawg-uri-scheme-reg.all@tools.ietf.org; Fri, 03 Apr 2015 04:32:35 -0700
Received: from BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) by BY2PR03MB409.namprd03.prod.outlook.com (10.141.141.11) with Microsoft SMTP Server (TLS) id 15.1.130.12; Thu, 2 Apr 2015 18:48:55 +0000
Received: from BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) by BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) with mapi id 15.01.0130.020; Thu, 2 Apr 2015 18:48:55 +0000
From: Dave Thaler 
To: Qin Wu 
Thread-Topic: OPS-DIR review of draft-ietf-appsawg-uri-scheme-reg-04
Thread-Index: AdBVqoBBzKB16QZoQqSP3Y7FahtJFgXyo5Lg
Date: Thu, 2 Apr 2015 18:48:55 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:4898:80e0:ee43::5]
authentication-results: huawei.com; dkim=none (message not signed) header.d=none;
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB409;
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(377454003)(99286002)(15975445007)(77096005)(77156002)(2656002)(2950100001)(230783001)(122556002)(92566002)(76576001)(2900100001)(102836002)(62966003)(33656002)(87936001)(19625215002)(16236675004)(76176999)(50986999)(54356999)(74316001)(86612001)(46102003)(110136001)(19580395003)(86362001)(19300405004)(19580405001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB409; H:BY2PR03MB412.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:BY2PR03MB409; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB409; 
x-forefront-prvs: 0534947130
Content-Type: multipart/alternative; boundary="_000_BY2PR03MB412EFFA41F5A99FE96EE4E7A3F20BY2PR03MB412namprd_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.onmicrosoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Apr 2015 18:48:55.0562 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB409
X-Helo-Check-Failed: Verification failed for HELO na01-bn1-obe.outbound.protection.outlook.com
X-SA-Exim-Connect-IP: 157.56.111.109
X-SA-Exim-Rcpt-To: draft-ietf-appsawg-uri-scheme-reg.all@tools.ietf.org
X-SA-Exim-Mail-From: dthaler@microsoft.com
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org)
Resent-To: draft-ietf-appsawg-uri-scheme-reg.all@ietf.org
Resent-Message-Id: <20150403113236.3F8F81A87E6@ietfa.amsl.com>
Resent-Date: Fri,  3 Apr 2015 04:32:36 -0700 (PDT)
Resent-From: dthaler@microsoft.com
Archived-At: 
Archived-At: 
X-Mailman-Approved-At: Fri, 03 Apr 2015 09:18:29 -0700
Cc: "draft-ietf-appsawg-uri-scheme-reg.all@tools.ietf.org" , "ops-dir@ietf.org" 
Subject: Re: [apps-discuss] OPS-DIR review of draft-ietf-appsawg-uri-scheme-reg-04
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 03 Apr 2015 11:32:43 -0000

--_000_BY2PR03MB412EFFA41F5A99FE96EE4E7A3F20BY2PR03MB412namprd_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Thanks Qin for your review.  Below is what we did in -05..

From: Qin Wu [mailto:bill.wu@huawei.com]
Sent: Tuesday, March 3, 2015 4:07 AM
To: ops-dir@ietf.org; draft-ietf-appsawg-uri-scheme-reg.all@tools.ietf.org
Subject: OPS-DIR review of draft-ietf-appsawg-uri-scheme-reg-04


Folks:

I have reviewed this document as part of the Operational directorate's ongo=
ing effort to review all IETF documents being processed by the IESG.  These=
 comments were written with the intent of improving the operational aspects=
 of the IETF drafts. Comments that are not addressed in last call may be in=
cluded in AD reviews during the IESG review.  Document editors and WG chair=
s should treat these comments just like any other last call comments.



This draft discusses Guidelines and Registration Procedures for URI Schemes=
. It looks Operations and Management Review Checklist defined in RFC5706 do=
esn't apply since there is no new protocol or protocol extension defined in=
 this draft.

I think this draft is ready for publication. Here are a few editorial comme=
nts:



1.       Section 1, last two paragraphs
s/Interationalized/Internationalized
s/accomodate/accommodate

[DT] Done


2.       Section 1, last two paragraphs
It looks these two paragraphs more fit into Scheme definition requirements =
section, why split it out from section 3? would it be good to incorporate t=
hese two paragraphs into section 3, No,?

[DT] Done.


3.       Section 3, the 6th paragraph said:
"
The URI scheme name registration procedure can be used in such an event.
"

Pointing to section 7 would be good.



[DT] Done.  Martin Durst said the same in his review.



4.       Section 4 and 5

Are there guidelines for permanent URI Scheme Registration if there is perm=
anent URI Scheme Registration? Or Permanent URI Scheme Registration can onl=
y be possible by upgrading provision URI Scheme Registration?



[DT] Not sure we parsed your question correctly, but as co-authors we discu=
ssed and believe the draft is already clear about a couple points:

1)      "Can you register a new permanent scheme, or must you go to provisi=
onal first?"  A: can go directly to permanent, as discussed in section 7.2 =
(intro sentence plus point 3).

2)      "Can you update an existing permanent scheme?" A: yes, as discussed=
 in section 7.3.



-Qin


--_000_BY2PR03MB412EFFA41F5A99FE96EE4E7A3F20BY2PR03MB412namprd_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Thank=
s Qin for your review.  Below is what we did in -05..


=
 








From: =
Qin Wu [mailto:bill.wu@huawei.com]


Sent: Tuesday, March 3, 2015 4:07 AM

To: ops-dir@ietf.org; draft-ietf-appsawg-uri-scheme-reg.all@tools.ie=
tf.org

Subject: OPS-DIR review of draft-ietf-appsawg-uri-scheme-reg-04=







 =



Folks:=



I have=
 reviewed this document as part of the Operational directorate's ongoing ef=
fort to review all IETF documents being processed by the IESG.  These =
comments were written with the intent of
 improving the operational aspects of the IETF drafts. Comments that are no=
t addressed in last call may be included in AD reviews during the IESG revi=
ew.  Document editors and WG chairs should treat these comments just l=
ike any other last call comments.


&=
nbsp;


This d=
raft discusses Guidelines and Registration Procedures for URI Schemes. It l=
ooks Operations and Management Review Checklist defined in RFC5706 doesn't =
apply since there is no new protocol
 or protocol extension defined in this draft.


I thin=
k this draft is ready for publication. Here are a few editorial comments:


&=
nbsp;



1.      
S=
ection 1, last two paragraphs


s/Interat=
ionalized/Internationalized



s/accomod=
ate/accommodate


 


[DT] Done


 



2.      
S=
ection 1, last two paragraphs


It looks =
these two paragraphs more fit into Scheme definition requirements section, =
why split it out from section 3? would it be good to incorporate these two =
paragraphs into section 3, No,?


 


[DT] Done.


&nbs=
p;



3.      
S=
ection 3, the 6th paragraph said:


“


The URI scheme name registration procedure can be used in such an event.=



”


Poin=
ting to section 7 would be good.


 


[DT] Done.  Martin Durst said the same in h=
is review.


 



4.      
S=
ection 4 and 5


Are =
there guidelines for permanent URI Scheme Registration if there is permanen=
t URI Scheme Registration? Or Permanent URI Scheme Registration can only be=
 possible by upgrading provision URI
 Scheme Registration?


 


[DT] Not sure we parsed your question correctly,=
 but as co-authors we discussed and believe the draft is already clear abou=
t a couple points:



1)     
“Can you register a new permanent schem=
e, or must you go to provisional first?”  A: can go directly to =
permanent, as discussed in section 7.2 (intro sentence
 plus point 3).



2)     
“Can you update an existing permanent s=
cheme?” A: yes, as discussed in section 7.3.


 


-Qin=



&nbs=
p;








--_000_BY2PR03MB412EFFA41F5A99FE96EE4E7A3F20BY2PR03MB412namprd_--


From nobody Sat Apr  4 07:40:49 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA391B2B9B; Sat,  4 Apr 2015 07:40:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZ_ZnjOJJEDk; Sat,  4 Apr 2015 07:40:44 -0700 (PDT)
Received: from relay12.mail.ox.ac.uk (relay12.mail.ox.ac.uk [129.67.1.163]) by ietfa.amsl.com (Postfix) with ESMTP id 934C81A8AB5; Sat,  4 Apr 2015 07:40:42 -0700 (PDT)
Received: from smtp4.mail.ox.ac.uk ([129.67.1.207]) by relay12.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1YePFX-0002b8-dd; Sat, 04 Apr 2015 15:40:39 +0100
Received: from host109-152-232-46.range109-152.btcentralplus.com ([109.152.232.46] helo=cheery.atuin.ninebynine.org) by smtp4.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YePFX-00046f-DQ; Sat, 04 Apr 2015 15:40:39 +0100
Message-ID: <551FF7EC.9050606@ninebynine.org>
Date: Sat, 04 Apr 2015 15:40:44 +0100
From: Graham Klyne 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Barry Leiba 
References: <2E49FA112B054FFAED69D8A1@JcK-HP8200.jck.com>	<551D0F27.9030201@ninebynine.org> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Oxford-Username: zool0635
Archived-At: 
Cc: "draft-ietf-appsawg-uri-scheme-reg.all@ietf.org" , IESG , Apps Discuss 
Subject: Re: [apps-discuss] Retroactive application of draft-ietf-appsawg-uri-scheme-reg - comprehensive review
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 04 Apr 2015 14:40:46 -0000

On 02/04/2015 14:08, Barry Leiba wrote:
> Just to one point:
>
>> My reason is that there is software out there that is written to accept
>> *anything* that is a valid URI, and legitimately expect such strings to
>> confirm to RFC3986 syntax (not withstanding Sam Ruby's efforts to document
>> variations between systems about what they accept as a valid URI).
>
> Absolutely.  And the URNbis document maintains that, but keeping URNs
> syntactically URIs.
>

Yes, and as long as URNs are used simply as strings meeting certain syntactic 
constraints, there's no problem...

>> If URNs
>> are to be usable as URIs in such circumstances, I think it's important that
>> they follow the rules, including those concerning the role of fragment
>> identifiers.
>
> Here's where I don't agree.  If URN fragments (f-components, or
> friggle-fraggles... the bit after the "#") are semantically somewhat
> different to what 3986 says about fragments in locators, because
> that's what semantically makes sense for URNs, why does that stop
> anyone from continuing to use them in places where URIs are
> syntactically required?

The problems potentially arise when a URI is used for dereferencing.  The Web 
architecture is quite clear that the fragment is not used when dereferencing a 
resource on the web (http://www.w3.org/TR/webarch/#media-type-fragid).  (I 
assert that URIs are, first and foremost, a central protocol element of the Web, 
and anything that claims to be a URI should conform to Web architecture principles.)

To the case in point, if URNs are ever to be used for dereferencing (in the 
Web), then it is important that the fragment identifier may be stripped at this 
point, as that is how URI-dereferencing software may be written.  (You might say 
that URNs are not used for dereferencing.  I say never say never - e.g. consider 
the IETF spec for DDDS (https://tools.ietf.org/html/rfc3402)).

In summary, if URNs adopt fragment syntax as a part of the primary resource 
identifier (as opposed to a secondary resource in the sense indicated by web 
architecture - http://www.w3.org/TR/webarch/#fragid), then I think there's a 
risk that they may become unusable on the Web in some situations where URIs are 
used.  They would not be URIs.

#g
--


From nobody Sat Apr  4 07:40:51 2015
Return-Path: 
X-Original-To: expand-draft-ietf-appsawg-uri-scheme-reg.all@virtual.ietf.org
Delivered-To: apps-discuss@ietfa.amsl.com
Received: by ietfa.amsl.com (Postfix, from userid 65534) id 7DDAE1B2B9C; Sat,  4 Apr 2015 07:40:46 -0700 (PDT)
X-Original-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com
Delivered-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA391B2B9B; Sat,  4 Apr 2015 07:40:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZ_ZnjOJJEDk; Sat,  4 Apr 2015 07:40:44 -0700 (PDT)
Received: from relay12.mail.ox.ac.uk (relay12.mail.ox.ac.uk [129.67.1.163]) by ietfa.amsl.com (Postfix) with ESMTP id 934C81A8AB5; Sat,  4 Apr 2015 07:40:42 -0700 (PDT)
Received: from smtp4.mail.ox.ac.uk ([129.67.1.207]) by relay12.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1YePFX-0002b8-dd; Sat, 04 Apr 2015 15:40:39 +0100
Received: from host109-152-232-46.range109-152.btcentralplus.com ([109.152.232.46] helo=cheery.atuin.ninebynine.org) by smtp4.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YePFX-00046f-DQ; Sat, 04 Apr 2015 15:40:39 +0100
Message-ID: <551FF7EC.9050606@ninebynine.org>
Date: Sat, 04 Apr 2015 15:40:44 +0100
From: Graham Klyne 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Barry Leiba 
References: <2E49FA112B054FFAED69D8A1@JcK-HP8200.jck.com>	<551D0F27.9030201@ninebynine.org> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Oxford-Username: zool0635
Archived-At: 
Cc: "draft-ietf-appsawg-uri-scheme-reg.all@ietf.org" , IESG , Apps Discuss 
Subject: Re: [apps-discuss] Retroactive application of draft-ietf-appsawg-uri-scheme-reg - comprehensive review
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 04 Apr 2015 14:40:46 -0000

On 02/04/2015 14:08, Barry Leiba wrote:
> Just to one point:
>
>> My reason is that there is software out there that is written to accept
>> *anything* that is a valid URI, and legitimately expect such strings to
>> confirm to RFC3986 syntax (not withstanding Sam Ruby's efforts to document
>> variations between systems about what they accept as a valid URI).
>
> Absolutely.  And the URNbis document maintains that, but keeping URNs
> syntactically URIs.
>

Yes, and as long as URNs are used simply as strings meeting certain syntactic 
constraints, there's no problem...

>> If URNs
>> are to be usable as URIs in such circumstances, I think it's important that
>> they follow the rules, including those concerning the role of fragment
>> identifiers.
>
> Here's where I don't agree.  If URN fragments (f-components, or
> friggle-fraggles... the bit after the "#") are semantically somewhat
> different to what 3986 says about fragments in locators, because
> that's what semantically makes sense for URNs, why does that stop
> anyone from continuing to use them in places where URIs are
> syntactically required?

The problems potentially arise when a URI is used for dereferencing.  The Web 
architecture is quite clear that the fragment is not used when dereferencing a 
resource on the web (http://www.w3.org/TR/webarch/#media-type-fragid).  (I 
assert that URIs are, first and foremost, a central protocol element of the Web, 
and anything that claims to be a URI should conform to Web architecture principles.)

To the case in point, if URNs are ever to be used for dereferencing (in the 
Web), then it is important that the fragment identifier may be stripped at this 
point, as that is how URI-dereferencing software may be written.  (You might say 
that URNs are not used for dereferencing.  I say never say never - e.g. consider 
the IETF spec for DDDS (https://tools.ietf.org/html/rfc3402)).

In summary, if URNs adopt fragment syntax as a part of the primary resource 
identifier (as opposed to a secondary resource in the sense indicated by web 
architecture - http://www.w3.org/TR/webarch/#fragid), then I think there's a 
risk that they may become unusable on the Web in some situations where URIs are 
used.  They would not be URIs.

#g
--


From nobody Sat Apr  4 08:02:30 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3E591B2BB2; Sat,  4 Apr 2015 08:02:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rsgLFEYUblSW; Sat,  4 Apr 2015 08:02:23 -0700 (PDT)
Received: from relay15.mail.ox.ac.uk (relay15.mail.ox.ac.uk [163.1.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id 183A91B2BAD; Sat,  4 Apr 2015 08:02:23 -0700 (PDT)
Received: from smtp4.mail.ox.ac.uk ([129.67.1.207]) by relay15.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1YePaV-0004rc-oR; Sat, 04 Apr 2015 16:02:19 +0100
Received: from host109-152-232-46.range109-152.btcentralplus.com ([109.152.232.46] helo=cheery.atuin.ninebynine.org) by smtp4.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YePaV-0005YI-EV; Sat, 04 Apr 2015 16:02:19 +0100
Message-ID: <551FFD00.8020903@ninebynine.org>
Date: Sat, 04 Apr 2015 16:02:24 +0100
From: Graham Klyne 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Barry Leiba 
References: <2E49FA112B054FFAED69D8A1@JcK-HP8200.jck.com>	<551D0F27.9030201@ninebynine.org> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Oxford-Username: zool0635
Archived-At: 
Cc: "draft-ietf-appsawg-uri-scheme-reg.all@ietf.org" , IESG , Apps Discuss 
Subject: Re: [apps-discuss] Retroactive application of draft-ietf-appsawg-uri-scheme-reg - comprehensive review
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 04 Apr 2015 15:02:25 -0000

Barry,

(backtracking on my previous response...)

I just realized my last response to you wasn't right.  I argued that the 
fragment should not be part of a primary resource identifier.  On reflection, I 
think that's wrong - there are already examples of URIs with fragment 
identifiers used as (primary) resource identifiers.  (E.g. they are commonly so 
used in RDF.)

They key point, I think, is that the identifier including fragment cannot be 
used directly to retrieve a representation of the identified resource on the Web.

So if a URN does use a fragment as part of an identifier (other than by 
"indirect identification of a secondary resource by reference to a primary 
resource" [http://tools.ietf.org/html/rfc3986#section-3.5]), then that form of 
URN cannot be used directly for Web dereferencing of the identified resource. 
But it could be mapped by a particular access protocol to some other URI that 
can be so used (e.g. using DDDS).

I therefore soften my previous stance about the role of fragment identifiers in 
URNs, but I would tend to recommend against using them unless the fragment-less 
identifier can be understood as identifying some appropriate "gateway" resource.

However, there is another aspect of fragment identifiers as defined by RFC3986 
that is purely syntactic - they are part of the hierarchy that comes into play 
when resolving a URI reference against some base URI, and I still think that 
aspect should be respected by URNs.

#g
--


On 02/04/2015 14:08, Barry Leiba wrote:
> Just to one point:
>
>> My reason is that there is software out there that is written to accept
>> *anything* that is a valid URI, and legitimately expect such strings to
>> confirm to RFC3986 syntax (not withstanding Sam Ruby's efforts to document
>> variations between systems about what they accept as a valid URI).
>
> Absolutely.  And the URNbis document maintains that, but keeping URNs
> syntactically URIs.
>
>> If URNs
>> are to be usable as URIs in such circumstances, I think it's important that
>> they follow the rules, including those concerning the role of fragment
>> identifiers.
>
> Here's where I don't agree.  If URN fragments (f-components, or
> friggle-fraggles... the bit after the "#") are semantically somewhat
> different to what 3986 says about fragments in locators, because
> that's what semantically makes sense for URNs, why does that stop
> anyone from continuing to use them in places where URIs are
> syntactically required?
>
> Barry
>


From nobody Sat Apr  4 08:02:31 2015
Return-Path: 
X-Original-To: expand-draft-ietf-appsawg-uri-scheme-reg.all@virtual.ietf.org
Delivered-To: apps-discuss@ietfa.amsl.com
Received: by ietfa.amsl.com (Postfix, from userid 65534) id F20FF1B2BB3; Sat,  4 Apr 2015 08:02:24 -0700 (PDT)
X-Original-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com
Delivered-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3E591B2BB2; Sat,  4 Apr 2015 08:02:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rsgLFEYUblSW; Sat,  4 Apr 2015 08:02:23 -0700 (PDT)
Received: from relay15.mail.ox.ac.uk (relay15.mail.ox.ac.uk [163.1.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id 183A91B2BAD; Sat,  4 Apr 2015 08:02:23 -0700 (PDT)
Received: from smtp4.mail.ox.ac.uk ([129.67.1.207]) by relay15.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1YePaV-0004rc-oR; Sat, 04 Apr 2015 16:02:19 +0100
Received: from host109-152-232-46.range109-152.btcentralplus.com ([109.152.232.46] helo=cheery.atuin.ninebynine.org) by smtp4.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YePaV-0005YI-EV; Sat, 04 Apr 2015 16:02:19 +0100
Message-ID: <551FFD00.8020903@ninebynine.org>
Date: Sat, 04 Apr 2015 16:02:24 +0100
From: Graham Klyne 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Barry Leiba 
References: <2E49FA112B054FFAED69D8A1@JcK-HP8200.jck.com>	<551D0F27.9030201@ninebynine.org> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Oxford-Username: zool0635
Archived-At: 
Cc: "draft-ietf-appsawg-uri-scheme-reg.all@ietf.org" , IESG , Apps Discuss 
Subject: Re: [apps-discuss] Retroactive application of draft-ietf-appsawg-uri-scheme-reg - comprehensive review
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 04 Apr 2015 15:02:25 -0000

Barry,

(backtracking on my previous response...)

I just realized my last response to you wasn't right.  I argued that the 
fragment should not be part of a primary resource identifier.  On reflection, I 
think that's wrong - there are already examples of URIs with fragment 
identifiers used as (primary) resource identifiers.  (E.g. they are commonly so 
used in RDF.)

They key point, I think, is that the identifier including fragment cannot be 
used directly to retrieve a representation of the identified resource on the Web.

So if a URN does use a fragment as part of an identifier (other than by 
"indirect identification of a secondary resource by reference to a primary 
resource" [http://tools.ietf.org/html/rfc3986#section-3.5]), then that form of 
URN cannot be used directly for Web dereferencing of the identified resource. 
But it could be mapped by a particular access protocol to some other URI that 
can be so used (e.g. using DDDS).

I therefore soften my previous stance about the role of fragment identifiers in 
URNs, but I would tend to recommend against using them unless the fragment-less 
identifier can be understood as identifying some appropriate "gateway" resource.

However, there is another aspect of fragment identifiers as defined by RFC3986 
that is purely syntactic - they are part of the hierarchy that comes into play 
when resolving a URI reference against some base URI, and I still think that 
aspect should be respected by URNs.

#g
--


On 02/04/2015 14:08, Barry Leiba wrote:
> Just to one point:
>
>> My reason is that there is software out there that is written to accept
>> *anything* that is a valid URI, and legitimately expect such strings to
>> confirm to RFC3986 syntax (not withstanding Sam Ruby's efforts to document
>> variations between systems about what they accept as a valid URI).
>
> Absolutely.  And the URNbis document maintains that, but keeping URNs
> syntactically URIs.
>
>> If URNs
>> are to be usable as URIs in such circumstances, I think it's important that
>> they follow the rules, including those concerning the role of fragment
>> identifiers.
>
> Here's where I don't agree.  If URN fragments (f-components, or
> friggle-fraggles... the bit after the "#") are semantically somewhat
> different to what 3986 says about fragments in locators, because
> that's what semantically makes sense for URNs, why does that stop
> anyone from continuing to use them in places where URIs are
> syntactically required?
>
> Barry
>


From nobody Sat Apr  4 08:05:04 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FA0F1B2BB5; Sat,  4 Apr 2015 08:05:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2W5nJ67IdTQn; Sat,  4 Apr 2015 08:05:01 -0700 (PDT)
Received: from relay13.mail.ox.ac.uk (relay13.mail.ox.ac.uk [129.67.1.166]) by ietfa.amsl.com (Postfix) with ESMTP id 66DE01B2BB3; Sat,  4 Apr 2015 08:05:01 -0700 (PDT)
Received: from smtp4.mail.ox.ac.uk ([129.67.1.207]) by relay13.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1YePd4-0004cQ-hK; Sat, 04 Apr 2015 16:04:58 +0100
Received: from host109-152-232-46.range109-152.btcentralplus.com ([109.152.232.46] helo=cheery.atuin.ninebynine.org) by smtp4.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YePd4-0005jF-Dt; Sat, 04 Apr 2015 16:04:58 +0100
Message-ID: <551FFDA0.5030507@ninebynine.org>
Date: Sat, 04 Apr 2015 16:05:04 +0100
From: Graham Klyne 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: John C Klensin ,  draft-ietf-appsawg-uri-scheme-reg.all@ietf.org, iesg@ietf.org,  apps-discuss@ietf.org
References: <2E49FA112B054FFAED69D8A1@JcK-HP8200.jck.com> <551D0F27.9030201@ninebynine.org> <1AFEBE03F8FCCEB215C30DEC@JcK-HP8200.jck.com>
In-Reply-To: <1AFEBE03F8FCCEB215C30DEC@JcK-HP8200.jck.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Oxford-Username: zool0635
Archived-At: 
Subject: Re: [apps-discuss] Retroactive application of draft-ietf-appsawg-uri-scheme-reg - comprehensive review
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 04 Apr 2015 15:05:03 -0000

On 02/04/2015 15:19, John C Klensin wrote:
> Barry has commented on the more important part of this, but an
> observation on the other part...
>
> --On Thursday, April 02, 2015 10:43 +0100 Graham Klyne
>  wrote:
>
>>> If we can agree that this is not applicable to existing
>>> registered scheme definitions or updates to them and that
>>> future URN-like schemes are unlikely, then that is a
>>> non-issue.  If we cannot, the AppsAWG and IESG should be
>>> formally aware (the former has certainly been told about this
>>> in various area meetings) that the current consensus within
>>> URNBIS is to separate URNs from the semantic requirements of
>>> 3986 [2].  That position was the result of a difficult
>>> compromise in which the main alternative was to separate URNs
>>> entirely from what the WG believes are the many assumptions
>>> (most derived from locators) and some of the confusing
>>> language in 3986.
>>
>> Procedural matters aside, I think this is an important
>> clarification, and that urn: URIs SHOULD be constrained by
>> this.  This is not about existing and new URI schemes, but
>> about what is required to be a a valid URI.
>
> Procedural issues very much not aside, I would like to see if we
> can navigate the very large collection of URI issues (including
> those being discussed outside IETF) in a way that doesn't make
> everything so dependent on everything else that we cannot move
> any document (including this one) forward without moving
> everything else forward at the same time.
>
> If, as you suggest, language in
> draft-ietf-appsawg-uri-scheme-reg-05 "clarifies" what is
> required to be a valid URI, especially in a way that affects
> both existing and future ones, then it necessarily updates 3986.

I certainly did not mean to suggest that.

I think that draft-ietf-appsawg-uri-scheme-reg-05 has no place "clarifying" what 
it is to be a URI - that is the role of RFC3986.  I did not think it does this, 
but if you think it does, I would be interested to understand where and why.

#g
--

> If it does that, then it is missing the required "Updates"
> indication (trivial) and the required explanation of what parts
> or provisions of 3986 are being updated and how.  So, if you
> believe the above, you have just made a significant procedural
> objection to processing the draft in its current form.   While
> that might be a minor issue for some documents, easily corrected
> by an RFC Editor note, I believe there is ample reason to
> believe that a description of what is being updated and why
> would turn out to be controversial and difficult in terms of
> achieving consensus.
>
> At least from my perspective, the problem goes beyond that and
> into issues I have identified earlier.  If
> draft-ietf-appsawg-uri-scheme-reg modifies what it is possible
> to do in ongoing URN work beyond whatever is clearly specified
> in 3986, then any of the active participants in URNBIS (or those
> concerned about its output, whether actively participating or
> not) are entitled to raise the issue of whether openness and
> fairness allows draft-ietf-appsawg-uri-scheme-reg to be
> processed independently of the URN documents that it claims to
> restrict.   Equally frighteningly, if
> draft-ietf-appsawg-uri-scheme-reg changes the fundamental
> validity criteria for URIs as specified (or claimed to be
> specified) in 3986, it presumably [re]opens all of the issues
> about what 3986 actually requires rather than recommending or
> discussing and probably requires reaching consensus on and
> documenting such topics as those raised in the rather extensive
> threads about 3986 validity and scope that showed up in January
> and not moving _any_ of these documents forward until 3986bis
> (the right place to apply such clarifications) is ready for IETF
> Last Call.
>
> Another complication is that if there is disagreement in the
> community about the scope of draft-ietf-appsawg-uri-scheme-reg
> before it is even approved, you are a partisan for one position
> in that matter and that combination might cause reasonable
> people to be concerned about perceptions of possible
> interactions between those issues and your role as Designated
> Expert.
>
> I hope we can avoid going into a place where all of these issues
> become procedurally interlocked but when some of the authors and
> a subset of the (I believe few) people who carefully reviewed
> draft-ietf-appsawg-uri-scheme-reg disagree on its scope and
> applicability, we are not in good shape for avoiding that
> outcome.
>
>      john
>


From nobody Sat Apr  4 08:05:09 2015
Return-Path: 
X-Original-To: expand-draft-ietf-appsawg-uri-scheme-reg.all@virtual.ietf.org
Delivered-To: apps-discuss@ietfa.amsl.com
Received: by ietfa.amsl.com (Postfix, from userid 65534) id 659681B2BB8; Sat,  4 Apr 2015 08:05:03 -0700 (PDT)
X-Original-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com
Delivered-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FA0F1B2BB5; Sat,  4 Apr 2015 08:05:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2W5nJ67IdTQn; Sat,  4 Apr 2015 08:05:01 -0700 (PDT)
Received: from relay13.mail.ox.ac.uk (relay13.mail.ox.ac.uk [129.67.1.166]) by ietfa.amsl.com (Postfix) with ESMTP id 66DE01B2BB3; Sat,  4 Apr 2015 08:05:01 -0700 (PDT)
Received: from smtp4.mail.ox.ac.uk ([129.67.1.207]) by relay13.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1YePd4-0004cQ-hK; Sat, 04 Apr 2015 16:04:58 +0100
Received: from host109-152-232-46.range109-152.btcentralplus.com ([109.152.232.46] helo=cheery.atuin.ninebynine.org) by smtp4.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YePd4-0005jF-Dt; Sat, 04 Apr 2015 16:04:58 +0100
Message-ID: <551FFDA0.5030507@ninebynine.org>
Date: Sat, 04 Apr 2015 16:05:04 +0100
From: Graham Klyne 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: John C Klensin ,  draft-ietf-appsawg-uri-scheme-reg.all@ietf.org, iesg@ietf.org,  apps-discuss@ietf.org
References: <2E49FA112B054FFAED69D8A1@JcK-HP8200.jck.com> <551D0F27.9030201@ninebynine.org> <1AFEBE03F8FCCEB215C30DEC@JcK-HP8200.jck.com>
In-Reply-To: <1AFEBE03F8FCCEB215C30DEC@JcK-HP8200.jck.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Oxford-Username: zool0635
Archived-At: 
Subject: Re: [apps-discuss] Retroactive application of draft-ietf-appsawg-uri-scheme-reg - comprehensive review
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 04 Apr 2015 15:05:03 -0000

On 02/04/2015 15:19, John C Klensin wrote:
> Barry has commented on the more important part of this, but an
> observation on the other part...
>
> --On Thursday, April 02, 2015 10:43 +0100 Graham Klyne
>  wrote:
>
>>> If we can agree that this is not applicable to existing
>>> registered scheme definitions or updates to them and that
>>> future URN-like schemes are unlikely, then that is a
>>> non-issue.  If we cannot, the AppsAWG and IESG should be
>>> formally aware (the former has certainly been told about this
>>> in various area meetings) that the current consensus within
>>> URNBIS is to separate URNs from the semantic requirements of
>>> 3986 [2].  That position was the result of a difficult
>>> compromise in which the main alternative was to separate URNs
>>> entirely from what the WG believes are the many assumptions
>>> (most derived from locators) and some of the confusing
>>> language in 3986.
>>
>> Procedural matters aside, I think this is an important
>> clarification, and that urn: URIs SHOULD be constrained by
>> this.  This is not about existing and new URI schemes, but
>> about what is required to be a a valid URI.
>
> Procedural issues very much not aside, I would like to see if we
> can navigate the very large collection of URI issues (including
> those being discussed outside IETF) in a way that doesn't make
> everything so dependent on everything else that we cannot move
> any document (including this one) forward without moving
> everything else forward at the same time.
>
> If, as you suggest, language in
> draft-ietf-appsawg-uri-scheme-reg-05 "clarifies" what is
> required to be a valid URI, especially in a way that affects
> both existing and future ones, then it necessarily updates 3986.

I certainly did not mean to suggest that.

I think that draft-ietf-appsawg-uri-scheme-reg-05 has no place "clarifying" what 
it is to be a URI - that is the role of RFC3986.  I did not think it does this, 
but if you think it does, I would be interested to understand where and why.

#g
--

> If it does that, then it is missing the required "Updates"
> indication (trivial) and the required explanation of what parts
> or provisions of 3986 are being updated and how.  So, if you
> believe the above, you have just made a significant procedural
> objection to processing the draft in its current form.   While
> that might be a minor issue for some documents, easily corrected
> by an RFC Editor note, I believe there is ample reason to
> believe that a description of what is being updated and why
> would turn out to be controversial and difficult in terms of
> achieving consensus.
>
> At least from my perspective, the problem goes beyond that and
> into issues I have identified earlier.  If
> draft-ietf-appsawg-uri-scheme-reg modifies what it is possible
> to do in ongoing URN work beyond whatever is clearly specified
> in 3986, then any of the active participants in URNBIS (or those
> concerned about its output, whether actively participating or
> not) are entitled to raise the issue of whether openness and
> fairness allows draft-ietf-appsawg-uri-scheme-reg to be
> processed independently of the URN documents that it claims to
> restrict.   Equally frighteningly, if
> draft-ietf-appsawg-uri-scheme-reg changes the fundamental
> validity criteria for URIs as specified (or claimed to be
> specified) in 3986, it presumably [re]opens all of the issues
> about what 3986 actually requires rather than recommending or
> discussing and probably requires reaching consensus on and
> documenting such topics as those raised in the rather extensive
> threads about 3986 validity and scope that showed up in January
> and not moving _any_ of these documents forward until 3986bis
> (the right place to apply such clarifications) is ready for IETF
> Last Call.
>
> Another complication is that if there is disagreement in the
> community about the scope of draft-ietf-appsawg-uri-scheme-reg
> before it is even approved, you are a partisan for one position
> in that matter and that combination might cause reasonable
> people to be concerned about perceptions of possible
> interactions between those issues and your role as Designated
> Expert.
>
> I hope we can avoid going into a place where all of these issues
> become procedurally interlocked but when some of the authors and
> a subset of the (I believe few) people who carefully reviewed
> draft-ietf-appsawg-uri-scheme-reg disagree on its scope and
> applicability, we are not in good shape for avoiding that
> outcome.
>
>      john
>


From nobody Sat Apr  4 09:07:18 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B32BF1B2BE8 for ; Sat,  4 Apr 2015 09:07:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NK75nypLr_nG for ; Sat,  4 Apr 2015 09:07:13 -0700 (PDT)
Received: from relay11.mail.ox.ac.uk (relay11.mail.ox.ac.uk [129.67.1.162]) by ietfa.amsl.com (Postfix) with ESMTP id B73B61B2BE7 for ; Sat,  4 Apr 2015 09:07:13 -0700 (PDT)
Received: from smtp4.mail.ox.ac.uk ([129.67.1.207]) by relay11.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1YeQbI-0005BJ-aa for apps-discuss@ietf.org; Sat, 04 Apr 2015 17:07:12 +0100
Received: from host109-152-232-46.range109-152.btcentralplus.com ([109.152.232.46] helo=cheery.atuin.ninebynine.org) by smtp4.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YeQbI-0002eh-DY for apps-discuss@ietf.org; Sat, 04 Apr 2015 17:07:12 +0100
Message-ID: <55200C35.1000708@ninebynine.org>
Date: Sat, 04 Apr 2015 17:07:17 +0100
From: Graham Klyne 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: apps-discuss@ietf.org
References:  <551AE31E.1070009@ninebynine.org> <306B3AB5-02E3-4958-9D05-4E4FF82AD114@isode.com> <266EAB2393341CF1F491F327@JcK-HP8200.jck.com> <551D0C47.5090603@ninebynine.org> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Oxford-Username: zool0635
Archived-At: 
Subject: Re: [apps-discuss] FW: New Version Notification - draft-ietf-appsawg-uri-scheme-reg-05.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 04 Apr 2015 16:07:16 -0000

John,

>> You mean
>> https://tools.ietf.org/html/draft-ietf-urnbis-rfc2141bis-urn-1
>> 1#section-7.2 ?
>
> Yes.
>
>> I'm seeing:
>>
>> "For namespaces or their definitions that are intended to
>> become standards
>>      or normative components of standards, the output of the
>> Expert Review
>>      process is intended to be a report, rather than
>> instructions to IANA
>>      to take action (see below)."
>>
>> and
>>
>> "If standardization is anticipated, the designated
>>          experts will prepare a report and forward it to the
>> appropriate
>>          standards approval body (the IESG in the case of the
>> IETF) and
>>          IANA will register the requested NID only after
>> receiving
>>          directions from that body and a copy of the expert
>> review report."
>>
>> I'm OK with this in principle but have a couple of possible
>> concerns:
>>
>> 1. "prepare a report" starts to sound a bit heavyweight.
>
> I didn't like it either, but it was the best I could come up
> with when I was writing that.  Better wording would be welcome.

Let's see:

...

"For namespaces or their definitions that are intended to become standards or 
normative components of standards, the output of the Expert Review process is 
intended to be a report, rather than instructions to IANA to take action (see 
below)."

I think this may be redundant.  When a request for registration is made, there 
are three possible outcomes:

1. DE says it's OK, in which case IANA makes the entry as requested.  I don't 
see any need to change this.  No "report" appears to be needed in this case.

2. DE has a problem with the request, in which case the reasons are fed back to 
the submitter (which may be an IETF working group or some other standards body). 
  I think this corresponds to your "report".

3. DE has reservations and recommends registration with additional "health 
warning".  In practice, this does not happen until there has been some dialogue 
following (2).

...

"If standardization is anticipated, the designated experts will prepare a report 
and forward it to the appropriate standards approval body (the IESG in the case 
of the IETF) and IANA will register the requested NID only after receiving 
directions from that body and a copy of the expert review report."

I'm finding there's devil in the detail here.  I think the effect of this would 
be (a) to complicate the process, and (b) to reduce the DE's discretion to 
recommend acceptance of a straitforward registration request.

If standardization is anticipated, I look for some indication that the standards 
process (IETF or otherwise) is being followed appropriately, and that is 
sufficiently well advanced (e.g., in the IETF, passing last call for Proposed 
Standard.);  in practice, if the approval for standards action is not yet 
achieved, I recommend provisional registration until that point.

So my suggestion would be, rather than to actually change the procedure to 
introduce formally defined lines of reporting, to provide some guidelines for 
anticipated standards submissions; e.g.

"If standardization is anticipated, the working group or individuals concerned 
are advised to submit an early permanent registration request, rather than 
waiting until the standardization process has run its course.  IANA will pass 
this to the DE who may recommend provisional registration until the 
specification is approved as a standard.  This will provide opportunity for 
feedback while specification development and review is still active, and the 
submitter(s) are still in a position to respond to any issues that might be 
raised.  If and when the specification is approved as a standard, the submitters 
should submit a request to change the registration status to permanent."

I think something like this can work for any standardization organization or 
process and, in conjunction with the previous text suggested, positions the DE 
as part of the review process rather than a gatekeeper with power of veto over 
the standards process.

(I note that, currently, there is an arrangement that IANA will send me an early 
review request when an IETF  document goes to last call with a URI scheme 
registration request, so that my comments can be fed into the last call 
discussions.  But this wouldn't work so easily for other standards organizations.)

> However, unlike the URI registration case in which the
> presumption is that any formal standards process would be within
> the IETF, the URN namespace registration text anticipates
> handing off final review and approval to what the media type
> registration procedure calls "recognized standards bodies" when
> the namespaces themselves are under the control of those bodies.

Actually, that's my understanding of the URI scheme registration process.  For 
example, I would expect to give careful consideration to a permanent scheme 
proposed by a W3C working group.

> In some of those cases, especially if the DE concludes that the
> registration proposal is a hopeless mess, a "report" is going to
> be precisely what is needed.  My hope is that we can avoid any
> tendencies to overspecify that but the motivation is the same as
> it was with media types: if a namespace registration shows up
> that involves highly technical matters that are under the
> control of, or standardized by, some competent and recognized
> standards body or scientific group, having the IETF demonstrate
> community ignorance by debating the issues is not helpful to
> anyone.

That's pretty much what happens now.  Maybe there's scope for some additional 
guidance, e.g.

"If the DE feels unable to recommend acceptance of a requested permanent 
registration, they should respond to IANA stating this, along with their reasons 
and, if possible, what changes the submitter might be able offer to improve the 
submission, which IANA in term will relay to the submitter.  In cases where some 
discussion seems needed, the DE can also respond directly to the contact named 
in the submission (also advising IANA of this).  In such situations, the scheme 
may be registered provisionally while discussions are in progress."

I think this could cover pretty much the additional points and scenarios you 
discuss below.  There has already been some "corridor discussion" that including 
more helpful guidance might be more effective than creating a more detailed 
process (this was some time ago, and not much has happened since; we started to 
create a guidance FAQ on the IETF Wiki, but that initiative fizzled out.).  I 
also try to frame the DE's input as "recommendation" rather than "instruction" 
to IANA.

>>    If
>> we can be clear that a "report" may be a short email at the
>> level of "this is fine" or "I have concerns with  and
>> " then it's OK.  But if you envisage something more
>> formal then that could (from my perspective) seriously impair
>> my ability to perform the DE role.
>
> See above.  I would hope that whatever reporting would occur
> would be appropriate to the circumstances.  Certainly, under the
> obvious circumstances (and remembering that the issue of
> delegation to other standards bodies is presumably not an issue
> for URI scheme registrations), "this is fine", "I don't see any
> issues", etc., would be perfectly reasonable "reports".
>
> Again, text suggestions for the URN namespace version of this
> would be very welcome.
>
>> 2. I am not sure that it is appropriate for the IETF to have a
>> procedure that requires us to become formally involved in the
>> machinations of external standards bodies.  We already have
>> and recommend submissions to the URI-review list, and the
>> registration procedures already operate to promote dialog with
>> external bodies (or individuals) who wish to make permanent
>> registrations, so I'm unconvinced that greater formality is
>> needed vis-a-vis interaction with external standards bodies.
>
> First, what was anticipated was closer to a delegation and
> handoff rather than "involved with the machinations".  Second,
> we've had provisions equivalent to this for many years (see,
> e.g., the discussion in Section 2.1.5 of RFC 2048).  The
> thinking that drove that model ran something like this: Suppose
> the IAU decided it need a media type for subplanetary objects or
> IUPAC decided it needed one for chemical synthesis of some
> flavor.  Noting that examples like that are actually far more
> likely for URN namespaces than for media types, while an Expert
> Review (and, if appropriate, advice) about whether the template
> was adequate and whether suggestions about format or syntax were
> in order, IETF debates about what objects or processes were to
> be included in the namespace or how they were to be named would
> not be helpful and might turn into a public embarrassment.
> Consider ISBNs as an example: I would hope that a Designated
> Expert would offer advice about the tradeoffs between allowing
> NSS strings both with and without hyphens, including those
> involving the two not being equal when comparisons were made
> using generic URI rules with no scheme-specific information or
> generic URN rules with no namespace-specific information.  It
> seems to me that neither of those is a showstopper that should
> block NID registration, but there should be an informed choice
> made and that the International ISBN Agency should make it, not
> the IETF (or the Designated Expert).
>
> Again, I am _not_ suggesting this is the right model for URI
> schemes even though, if things continue in the directions they
> seem to be going in lately, I can image some sort of deal being
> worked out between the IETF and W3C.
>
>> What I might do is suggest that external standards bodies make
>> initial registration requests early/ier in their process so
>> that they can receive and respond to feedback while there is
>> still scope to do so within the constraints of their process.
>> For example, to submit a permanent registration request early
>> on the understanding that it may initially be accepted
>> provisionally, and upgraded to permanent as and when any
>> concerns raised are resolved (including progression to the
>> appropriate status by the requesting organization).
>
> For URI schemes, I'm going to continue to try to not have an
> opinion.  For a variety of other registration activities,
> including DNS RRTYPEs and media types and I believe URN
> namespaces, I suggest that "provisional" or similar vocabulary
> has not worked out well because things get registered and
> deployed and then, when the time comes to standardize or make
> them permanent, the claim is made that they cannot be altered
> without causing serious disruption.  I am reminded that similar
> behavior sequences were part of what caused RFC 6648.

Well, I think that's always a tension.  Implementers will implement, then 
deploy!  The (perceived) failure of the old 'X-' convention was a big part of 
what lead to this more open, tiered style of registry.

#g
--


From nobody Sat Apr  4 09:20:04 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD351B2BF3 for ; Sat,  4 Apr 2015 09:20:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LaR-v-XfLvgt for ; Sat,  4 Apr 2015 09:20:01 -0700 (PDT)
Received: from relay15.mail.ox.ac.uk (relay15.mail.ox.ac.uk [163.1.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id CBBA81B2BED for ; Sat,  4 Apr 2015 09:20:00 -0700 (PDT)
Received: from smtp6.mail.ox.ac.uk ([163.1.2.206]) by relay15.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1YeQnf-0003oo-nh; Sat, 04 Apr 2015 17:19:59 +0100
Received: from host109-152-232-46.range109-152.btcentralplus.com ([109.152.232.46] helo=cheery.atuin.ninebynine.org) by smtp6.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YeQnf-0004J1-KV; Sat, 04 Apr 2015 17:19:59 +0100
Message-ID: <55200F35.2070904@ninebynine.org>
Date: Sat, 04 Apr 2015 17:20:05 +0100
From: Graham Klyne 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: John C Klensin ,  Dave Thaler 
References: <550164DD.6020509@it.aoyama.ac.jp>  <080D2D237EF9714533B15BDB@JcK-HP8200.jck.com>
In-Reply-To: <080D2D237EF9714533B15BDB@JcK-HP8200.jck.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Oxford-Username: zool0635
Archived-At: 
Cc: apps-discuss@ietf.org, Larry Masinter 
Subject: Re: [apps-discuss] Last Call:  (Guidelines and Registration Procedures for URI Schemes) to Best Current Practice
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 04 Apr 2015 16:20:02 -0000

On 02/04/2015 20:57, John C Klensin wrote:
>
> Just because this may be an illustration of how much 3986 (with
> or without this I-D) is confusing everyone, my reading of the
> syntax in 3986 is that
>     somescheme://domain/foobar#sss#yyy
> is perfectly valid.  The actual fragment is "foo#yyy" and there
> is no requirement that the embedded "#" be %-encoded.

Exerpted from http://tools.ietf.org/html/rfc3986#appendix-A:

   fragment      = *( pchar / "/" / "?" )

   pchar         = unreserved / pct-encoded / sub-delims / ":" / "@"

   unreserved    = ALPHA / DIGIT / "-" / "." / "_" / "~"

   pct-encoded   = "%" HEXDIG HEXDIG

   sub-delims    = "!" / "$" / "&" / "'" / "(" / ")"
                    / "*" / "+" / "," / ";" / "="

I think it's clear: there's no way an unencoded '#' can appear in a fragment.

#g
--


From nobody Sun Apr  5 21:06:12 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2597B1A00F9; Sun,  5 Apr 2015 21:06:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HCCrPU_GLQ06; Sun,  5 Apr 2015 21:06:10 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 427411A00FB; Sun,  5 Apr 2015 21:06:09 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
To: , ,  ,  , 
X-Test-IDTracker: no
X-IETF-IDTracker: 5.13.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150406040609.3455.54096.idtracker@ietfa.amsl.com>
Date: Sun, 05 Apr 2015 21:06:09 -0700
From: IETF Secretariat 
Archived-At: 
Subject: [apps-discuss] ID Tracker State Update Notice: 
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Apr 2015 04:06:11 -0000

IANA review state changed to IANA OK - Actions Needed
ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-multipart-form-data/


From nobody Sun Apr  5 22:13:31 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55A6C1A01BA for ; Sun,  5 Apr 2015 22:13:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.609
X-Spam-Level: 
X-Spam-Status: No, score=-0.609 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nxHLh8B7cDnO for ; Sun,  5 Apr 2015 22:13:28 -0700 (PDT)
Received: from nm18-vm0.bullet.mail.bf1.yahoo.com (nm18-vm0.bullet.mail.bf1.yahoo.com [98.139.213.138]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8779D1A01D6 for ; Sun,  5 Apr 2015 22:13:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1428297207; bh=yHEQEO6lIc8QpBMy8m+Mm8z7kl0kPL25efMbji6oN60=; h=Date:From:Reply-To:To:Subject:From:Subject; b=GXfGnQUTQZ5xQsly3R1EfXpz492ryX0kz97wDnB3XDrfZrhZmKDOJc/ZwUtqmu7GOpOQ+F36xdVWAoyykoSWAu1v1gORC1majKR+C8k4ZAgvulvXnDd96lPZhP7nc+IDJ38RaRsUaL2tq/ks/L15iL9pqE7dCwFbegDYfsGMn+f/K/lsxwjF7cRypn/3jDMQ+1Y1V/epDs7fMrvxM+DqmGnQQzHJdjg9BWpJe/UVvL8csuhjLa8D2JmLgvM/pkCfVpZ8k8fIiOGJrtWiDQsy/dhxFy0+3hSynIAJ/1RO2Kf6Xnj2IUyBi0jpqdp7NbwNdrSi/gelHRoKFxBVbQw9vw==
Received: from [98.139.214.32] by nm18.bullet.mail.bf1.yahoo.com with NNFMP; 06 Apr 2015 05:13:27 -0000
Received: from [98.139.212.231] by tm15.bullet.mail.bf1.yahoo.com with NNFMP;  06 Apr 2015 05:13:27 -0000
Received: from [127.0.0.1] by omp1040.mail.bf1.yahoo.com with NNFMP; 06 Apr 2015 05:13:27 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 790214.82002.bm@omp1040.mail.bf1.yahoo.com
X-YMail-OSG: JraxoQAVM1lClcq72jlQpW_zVgpZiAjrUDXcUYrIRcZgR_55E9gK1X_FX9mp0E2 l1ma3ZN.Nuw7ype_r9XkZxRlbUqgKO9cdthkTlyLPhNSvZRGXpYiq0lpNjRzuyZyXJgUBHLTh2Le 6d1DtMPi.DB6Vt7kOM6rwFVfj_Jq7R_XG3vzrB9htNlRq.RuOuDRXFEFXJwF_uGYK24tBYzBPF_B MD.oER3u6L6UDMJ0AZBcGUJExuZ84UlyO87vsj3rNPQdIBNEtQl_5y4DrMM3cU21.NFoOAHaZmTX coD0W8AWB11h8.pG.8rtnkEfNE180Pcunayg0skxgOPeLsbVBUL5.c_4JJcwY6lmqFplof7zgggQ Wqk7uPK_.0_R.bd4cRMEPgRlmcugiKq.Gjyixa_OiNPlBf16izkglwQZPt8K649IgSICH1lTNmWM 8tt8loYhTDW4g.PTZ7xgTrjokZOdb37veYm5v5kuBQoBOtWe6A6IslHEXAXaKWwV1_S63w_HXXwH N5_97xXpdynhWIGuXVKUjLpcHF06mz0ZpQtcSRIgchxd5EYVx.wbhgoE.JsCCZEpg4F_wLfXXPO3 h9W1PbZw5oGe5azDhlkLxY1qgy1MoNPKhYvXeaPdSmybvGKUKFDAaZg--
Received: by 66.196.80.151; Mon, 06 Apr 2015 05:13:27 +0000 
Date: Mon, 6 Apr 2015 05:13:26 +0000 (UTC)
From: Jitendra Lulla 
To: "apps-discuss@ietf.org" 
Message-ID: <2015057679.25302.1428297206551.JavaMail.yahoo@mail.yahoo.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_25301_142311522.1428297206547"
Archived-At: 
Subject: [apps-discuss] review request
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Jitendra Lulla 
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Apr 2015 05:13:30 -0000

------=_Part_25301_142311522.1428297206547
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,
Please ignore if you have already received this mail. I am re-sending as my=
 previous mail got blocked.=C2=A0
I am writing this mail to request you to please provide me with the group e=
mails where I can send my internet draft=C2=A0URL: =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0http://www.ietf.org/internet-drafts/draft-jlulla-whois-ip-=
validation-00.txt

The document is about querying the whois server with (1. a hostname and 2. =
local dns provided IP for this hostname) =C2=A0and expecting a response fro=
m the whois server about how probable is the validity of the given pair (na=
me, IP) is.=C2=A0
This is in new state and I am not sure how I can find/request people to rev=
iew and provide their useful comments on it.
So please advise me which working group this document should be sent for re=
view.
Or if this group ie appsawg is appropriate, please review the document and =
provide the comments.
The document is about querying the whois server with (1. a hostname and 2. =
local dns provided IP for this hostname) =C2=A0and expecting a response fro=
m the whois server about how probable is the validity of the given pair (na=
me, IP) is.=C2=A0
The need for this service is arising from the fact that a compromised DNS m=
ay lead to unintended connections. If before initiating the connection, if =
there exist a means to get a hint on the IP's association with its name, we=
 may decide whether to proceed or not with the connection. This need is app=
licable for both plain as well as secure connections. For secure connection=
s, though there exist a certificate based authentication method but still i=
f the=C2=A0
certificate has been signed by a rogue trusted CA, the client may end up ha=
ving a connection with the server with that fake certificate.
Please copy my email LULLAJD@yahoo.com if possible while responding using a=
ny ietf website.=C2=A0
ThanksJitendra Lulla


------=_Part_25301_142311522.1428297206547
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi,

Please ignore if you have already received t=
his mail. I am re-sending as my previous mail got blocked. 

I am writing this mail to request you =
to please provide me with the group emails where I can send my internet dra=
ft 





=

The document is about querying the whois server with (1. a=
 hostname and 2. local dns provided IP for this hostname)  and expecti=
ng a response from the whois server about how probable is the validity of t=
he given pair (name, IP) is. 
The need for this service is arising from the fact that a compromi=
sed DNS may lead to unintended connections. If before initiating the connec=
tion, if there exist a means to get a hint on the IP's association with its=
 name, we may decide whether to proceed or not with the connection. This ne=
ed is applicable for both plain as well as secure connections. For secure c=
onnections, though there exist a certificate based authentication method bu=
t still if the 
certifi=
cate has been signed by a rogue trusted CA, the client may end up having a =
connection with the server with that fake certificate.

Please copy my email LULLA=
JD@yahoo.com if possible while responding using any ietf website. 

Thanks
Jitendra Lulla



------=_Part_25301_142311522.1428297206547--


From nobody Sun Apr  5 23:28:50 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29FD21A0204 for ; Sun,  5 Apr 2015 23:28:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XLcWvyqD5Enz for ; Sun,  5 Apr 2015 23:28:47 -0700 (PDT)
Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C6921A0074 for ; Sun,  5 Apr 2015 23:28:35 -0700 (PDT)
Received: by wizk4 with SMTP id k4so22125327wiz.1 for ; Sun, 05 Apr 2015 23:28:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:date:message-id:subject:from:to:content-type; bh=V+EquUQxbSm+sahhLwwRdlJPytWrxsiEaK44ICBfbK8=; b=ddIjAH4WGhEJieT7dYM6XYEw1ICBePQSjsj6SzXrHSogBuUvX6g/8Cwc0df05n0Xko dDhrJm81/TIwpMKutBk21UzXE4Mxw9R2E3G4f5eYq4Ib0f5xyal7A31DuzRPStFBJor8 aqVnpw8/rgKpMkFv3H7jMZ5wttOZhUK4V3AdhXx0aHciblucNCU3uFE9o32ncoOd1Dt6 Lh1WMnz1S4/ziOccm5CFycYR6xsFQRIgvbg65obtpbhdgBgfUInftTOCf/BNbg3sKgxX +aIa1OPKUgM1fpbxaQdoTuvB/TglIU7N4Vo+vN9OBFeuHuRFl7DSkYk37PRdwxdqhVdL QGyA==
MIME-Version: 1.0
X-Received: by 10.180.75.243 with SMTP id f19mr27153179wiw.94.1428301713920; Sun, 05 Apr 2015 23:28:33 -0700 (PDT)
Received: by 10.27.92.17 with HTTP; Sun, 5 Apr 2015 23:28:33 -0700 (PDT)
Date: Sun, 5 Apr 2015 23:28:33 -0700
Message-ID: 
From: "Murray S. Kucherawy" 
To: IETF Apps Discuss 
Content-Type: multipart/alternative; boundary=f46d0438951b4a595e0513086892
Archived-At: 
Subject: [apps-discuss] IETF 92 APPSAWG/APPAREA minutes up for review
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 06 Apr 2015 06:28:49 -0000

--f46d0438951b4a595e0513086892
Content-Type: text/plain; charset=UTF-8

Colleagues,

The preliminary minutes from the IETF 92 meeting in Dallas for APPSAWG and
APPAREA are now available for your review:

https://www.ietf.org/proceedings/92/minutes/minutes-92-appsawg

Please let appsawg-chairs@tools.ietf.org know if any corrections or
additions are needed.  Corrections are requested by April 17.  The final
versions are due May 11.

-MSK, APPSAWG co-chair

--f46d0438951b4a595e0513086892
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Please let appsawg-chairs@tools.ietf.org know if any correct=
ions or additions are needed.=C2=A0 Corrections are requested by April 17.=
=C2=A0 The final versions are due May 11.

-MSK, APPSAWG co-cha=
ir



--f46d0438951b4a595e0513086892--


From nobody Sun Apr  5 23:55:23 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58C3D1A0687 for ; Sun,  5 Apr 2015 23:55:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xIEdK-mdBDx2 for ; Sun,  5 Apr 2015 23:55:21 -0700 (PDT)
Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DE4F1A065C for ; Sun,  5 Apr 2015 23:55:20 -0700 (PDT)
Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 7B772FA0010; Mon,  6 Apr 2015 06:55:18 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1428303318; bh=H1JK3q90mVWhEtB0jjsBa7lof1N0ZqnZj2eaJ67vXU0=; h=From:To:Subject:References:Date:From; b=NbhAPgg++3/feSwWumKLTb4AdWyUu8xcwCbnvXqON8FBV0DwFJVH8OZaTQjRCwpID GHbXO7wHO7eA+jMtq0H1YYFugmWiYzxsVd22i9+cTC0Bakqax4L29YNeHFu1t/VQWq vT1cUrKs6H8eaM9UtUz1UtJkLDvjr1JwYKvA74rc=
Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1428303317-31136-31135/12/238; Mon, 6 Apr 2015 06:55:17 +0000
From: Arnt Gulbrandsen 
To: apps-discuss@ietf.org, Jitendra Lulla 
Message-Id: 
References: <2015057679.25302.1428297206551.JavaMail.yahoo@mail.yahoo.com>
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Date: Mon, 6 Apr 2015 06:55:17 +0000
Archived-At: 
Subject: Re: [apps-discuss] review request
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 06 Apr 2015 06:55:22 -0000

It sounds as if you have not heard of DNSSEC. Have a look at that, I 
think you may find that it provides a reasonable solution to your 
problem.

Arnt


From nobody Mon Apr  6 00:08:50 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B68C11A1A0F; Mon,  6 Apr 2015 00:08:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level: 
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6SJxziDmfDGU; Mon,  6 Apr 2015 00:08:48 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB3E1A1A04; Mon,  6 Apr 2015 00:08:48 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: DraftTracker Mail System 
To: , , ,  ,  , 
X-Test-IDTracker: no
X-IETF-IDTracker: 5.13.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150406070848.10372.7000.idtracker@ietfa.amsl.com>
Date: Mon, 06 Apr 2015 00:08:48 -0700
Archived-At: 
Cc: iesg-secretary@ietf.org
Subject: [apps-discuss] Last Call Expired: 
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Apr 2015 07:08:49 -0000

Please DO NOT reply to this email.

I-D: 
ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-multipart-form-data/

IETF Last Call has ended, and the state has been changed to
Waiting for AD Go-Ahead.


From nobody Mon Apr  6 01:51:54 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08B3B1A1DE2 for ; Mon,  6 Apr 2015 01:51:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.711
X-Spam-Level: 
X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xz0_cxj67GcM for ; Mon,  6 Apr 2015 01:51:52 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22F241A1C02 for ; Mon,  6 Apr 2015 01:51:52 -0700 (PDT)
Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Yf2l5-000B3A-2n; Mon, 06 Apr 2015 04:51:51 -0400
Date: Mon, 06 Apr 2015 04:51:46 -0400
From: John C Klensin 
To: Arnt Gulbrandsen , apps-discuss@ietf.org, Jitendra Lulla 
Message-ID: 
In-Reply-To: 
References: <2015057679.25302.1428297206551.JavaMail.yahoo@mail.yahoo.com> 
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.35
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: 
Subject: Re: [apps-discuss] review request
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 06 Apr 2015 08:51:54 -0000

--On Monday, April 06, 2015 06:55 +0000 Arnt Gulbrandsen
 wrote:

> It sounds as if you have not heard of DNSSEC. Have a look at
> that, I think you may find that it provides a reasonable
> solution to your problem.

In addition, what you have described in your message and the I-D
[1] is unlikely to work because:

(1) Very few whois services are provided for domain names below
the second (or where structural subdomains are used, third)
level and, if those services were supported one would then have
a location and validation problem with them.

(2) Whois servers and databases for domain names rarely give out
information about hosts.  The only addresses usually provided
are those of the DNS servers for the relevant domains.
Sometimes those are in the same domains and address ranges as
actual hoses; very often, especially at the second level, they
are the addresses of DNS servers belonging to service providers
and tell one more about a registrar than about the specific
domains.  By contrast, queries of, e.g., regional registry whose
servers about addresses will yield ranges and owners but, except
for fairly large ("provider indepentent") allocations are more
likely to identify an ISP than to have any information
associated with the hosts you are interested in.

(3) While a Whois server can be configured to accept almost
anything (as long as the characters are NVT ASCII), they can't
return anything that is not in their databases.  As far as the
whois protocol is concerned, addressing a request to a
particular server for information about what you had for lunch
yesterday would be perfectly reasonable and, if the server
located has that information (and no privacy concerns about it),
that information could be returned.  But few, if any, whois
servers for, e.g., second-level domain names have the
information you are looking for and many registries and
registrars have protested very loudly, and then rejected and
refused, suggested requirements that they keep and provide data
to support much smaller changes to the services provided,
citing, among other things, privacy and the huge aggregate costs
involved, for the databases and interface changes.  Were your
approach adopted and used at even a few orders of magnitude
fewer times than the number of DNS queries, they would also be
concerned about costs and legitimately so (noting that the DNS
provides for caching, slave servers, and other ways to reduce or
distribute load and whois has no such provisions.

(4) In general, whois queries and responses, and whois servers
themselves, are as easily or more easily spoofed than DNS
queries, responses, and servers.  That is the case even without
DNSSEC; DNSSEC makes the difference much larger.  Your Security
Considerations section seems to suggest querying whois servers
by knowing their IP address, but gives no information about how
those addresses can be reliably and securely obtained.  

Something like this might have been a useful idea with an
Internet that was designed and structured around very
centralized administration and administrative databases.
However, the present Internet is very highly distributed
operationally and administratively.  Many people consider that a
strength but one of the side effects is to make a reliable
system of network informational and information-validating
servers quite difficult.

     john


From nobody Mon Apr  6 07:04:43 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EA351A1ADC for ; Mon,  6 Apr 2015 07:04:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QYA14rFABTsi for ; Mon,  6 Apr 2015 07:04:40 -0700 (PDT)
Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F044A1A1AA9 for ; Mon,  6 Apr 2015 07:04:39 -0700 (PDT)
Received: by widdi4 with SMTP id di4so31684573wid.0 for ; Mon, 06 Apr 2015 07:04:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0M9VcCgLzBJQPbzK/SOcjdqEaAVfJH2wKHO4cZzHwm8=; b=vFfj9dvwUUSSHWAJ983wRjS+DDZKAorpGRQ1O8GRKZPb/mJ9Q4bDwFCNhswcwb9oL7 Xm4Mf1bKxpqAZT89XlDCYy+y9izVFfwRo/oxbsJpk1ZrTVdSKIaF6TGs8TuvsgGO2WwE 29SvlY1zK1ONYjpBZMe7BxeyZ49+1IKDew05KonqwwS7mFXX2E7q9vcBNJuKkORyg84m LuFQKqR64VHlokPH3a++P0onb0V4ncFebkDBuvox5VSCniO9bTPQ6Z7kPBZdkinSGkXZ kHulfYTRTI7KpAPKJrRlEXJvDrN8sU2QNfLJjQ1IGOoBUlPnSeXqlkPiKia5j9acB33f vHbA==
MIME-Version: 1.0
X-Received: by 10.194.185.68 with SMTP id fa4mr30311069wjc.111.1428329078644;  Mon, 06 Apr 2015 07:04:38 -0700 (PDT)
Received: by 10.27.92.17 with HTTP; Mon, 6 Apr 2015 07:04:38 -0700 (PDT)
In-Reply-To: 
References: <2015057679.25302.1428297206551.JavaMail.yahoo@mail.yahoo.com>  
Date: Mon, 6 Apr 2015 07:04:38 -0700
Message-ID: 
From: "Murray S. Kucherawy" 
To: John C Klensin 
Content-Type: multipart/alternative; boundary=047d7bacb11e5aea2305130ec742
Archived-At: 
Cc: IETF Apps Discuss 
Subject: Re: [apps-discuss] review request
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 06 Apr 2015 14:04:41 -0000

--047d7bacb11e5aea2305130ec742
Content-Type: text/plain; charset=UTF-8

I hate to pile on, but:

On Mon, Apr 6, 2015 at 1:51 AM, John C Klensin  wrote:

> In addition, what you have described in your message and the I-D
> [1] is unlikely to work because:
>

(5) I don't think there are many operators interested in extending WHOIS,
which generally speaking no longer serves the community well for several
reasons.  The WEIRDS working group just finished development of RDAP which
appears to have the interest of both name and number registry operators
going forward.

-MSK

--047d7bacb11e5aea2305130ec742
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


I hate to pile on, but:

On Mon, Apr 6, 2015 at 1:51=
 AM, John C Klensin <john-ietf@jck.com> wrote:
=
In addition, what you have described in your message and the I-D

[1] is unlikely to work because:

(5) I =
don't think there are many operators interested in extending WHOIS, whi=
ch generally speaking no longer serves the community well for several reaso=
ns.=C2=A0 The WEIRDS working group just finished development of RDAP which =
appears to have the interest of both name and number registry operators goi=
ng forward.

-MSK 


--047d7bacb11e5aea2305130ec742--


From nobody Mon Apr  6 08:52:31 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0AB21A8A94; Mon,  6 Apr 2015 08:52:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2YZe9DEbFz6g; Mon,  6 Apr 2015 08:52:23 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A46211A8AA5; Mon,  6 Apr 2015 08:52:17 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
To: , ,  ,  , 
X-Test-IDTracker: no
X-IETF-IDTracker: 5.13.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150406155217.32761.60041.idtracker@ietfa.amsl.com>
Date: Mon, 06 Apr 2015 08:52:17 -0700
From: IETF Secretariat 
Archived-At: 
Subject: [apps-discuss] ID Tracker State Update Notice: 
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Apr 2015 15:52:30 -0000

IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead
ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-multipart-form-data/


From nobody Mon Apr  6 08:54:57 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6357E1A8AA4; Mon,  6 Apr 2015 08:54:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-MNp-cUgK0Y; Mon,  6 Apr 2015 08:54:55 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AE94D1A8AA9; Mon,  6 Apr 2015 08:54:53 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
To: , , 
X-Test-IDTracker: no
X-IETF-IDTracker: 5.13.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150406155453.5191.13436.idtracker@ietfa.amsl.com>
Date: Mon, 06 Apr 2015 08:54:53 -0700
From: IETF Secretariat 
Archived-At: 
Subject: [apps-discuss] ID Tracker State Update Notice: 
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Apr 2015 15:54:56 -0000

IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead
ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-uri-scheme-reg/


From nobody Mon Apr  6 16:04:11 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E79851ACDFD; Mon,  6 Apr 2015 16:04:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YtcImeDDX4yh; Mon,  6 Apr 2015 16:04:07 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EC8B91ACE08; Mon,  6 Apr 2015 16:03:46 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Ben Campbell" 
To: "The IESG" 
X-Test-IDTracker: no
X-IETF-IDTracker: 5.13.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150406230346.17020.71285.idtracker@ietfa.amsl.com>
Date: Mon, 06 Apr 2015 16:03:46 -0700
Archived-At: 
Cc: apps-discuss@ietf.org, appsawg-chairs@ietf.org
Subject: [apps-discuss] Ben Campbell's No Objection on draft-ietf-appsawg-uri-scheme-reg-05: (with COMMENT)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Apr 2015 23:04:09 -0000

Ben Campbell has entered the following ballot position for
draft-ietf-appsawg-uri-scheme-reg-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-appsawg-uri-scheme-reg/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I am curious how the expert review required in the document interacts
with bona-fide standards actions. There's already an ongoing discussion
on that, and Barry has noted it in his on comments, so I will leave this
as a comment. In particular I wonder if the "On receipt of a registration
request" section of 7.2 should be different if the request was part of an
IETF/IESG reviewed and approved action in the first place.

There are a lot of SHOULDs in this document. I wonder how an expert
reviewer is supposed to interpret deviations from SHOULD level
requirements. This is especially true in statements like "... SHOULD
include clear security considerations or explain [why not]". The expert's
life might be easier if there was some text encouraging that deviations
from SHOULDs be accompanied by an explanation.



From nobody Mon Apr  6 16:18:41 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CCF71ACE39 for ; Mon,  6 Apr 2015 16:18:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.15
X-Spam-Level: *
X-Spam-Status: No, score=1.15 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rGiFo1ESuLej for ; Mon,  6 Apr 2015 16:18:37 -0700 (PDT)
Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CA411ACE38 for ; Mon,  6 Apr 2015 16:18:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t36NIOSi003127; Tue, 7 Apr 2015 01:18:24 +0200 (CEST)
Received: from alma.local (p5DC7F099.dip0.t-ipconnect.de [93.199.240.153]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3lLSTq5kcPzCsXB; Tue,  7 Apr 2015 01:18:23 +0200 (CEST)
Message-ID: <5523143E.3070503@tzi.org>
Date: Tue, 07 Apr 2015 01:18:22 +0200
From: Carsten Bormann 
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: "Francois Le Faucheur (flefauch)" 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: draft-ietf-cdni-control-triggers.all@tools.ietf.org, apps-discuss@ietf.org
Subject: [apps-discuss] Appsdir review for draft-ietf-cdni-control-triggers-06
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 06 Apr 2015 23:18:39 -0000

I have been selected as an Applications Area Directorate reviewer for
this draft (for background on appsdir, please see
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate
), with a specific view on the JSON usage in this specification.

Please resolve these comments along with any other comments you may
receive. Please wait for direction from your document shepherd or AD
before posting a new version of the draft.  (Feel free to forward
these comments to the WG list if that helps in resolving the comments.)

Document:  draft-ietf-cdni-control-triggers-06
Title: CDNI Control Interface / Triggers
Reviewer: Carsten Bormann
Review Date: 2015-04-06

* Summary: This draft is ready for publication as a standards track RFC,
after a few misphrasings and minor details in the usage of HTTP have
been corrected.

* Major issues: None.

* Minor issues:

The protocol is REST-based in that it creates dCDN activities using a
POST-based interface, which then can be examined using GET on the
location returned (making good use of HTTP, e.g., for caching) and be
DELETEd for canceling them.  It is not making use of the fact that the
subject of these activities are REST resources themselves.  This
paragraph just takes note of this fact, without necessarily suggesting
a need (or even usefulness) for a change.

Is "authenticate" the right word in the 2nd para of 4.1?
(How do you authenticate a CI/T command?  There is no authentication
information provided.)

For the benefit of the implementer, the last paragraph of section 4.1
could say what is "an appropriate HTTP status code" here -- 405 Method
not allowed?

4.2.1 could give a little additional guidance on how to use the ETag
for the collection (possibly pointing to the examples).

4.3 uses 403 forbidden to indicate that a feature is not implemented?

4.6 the phrasing "into the cdn-path key" used here is misleading: The
intent is to have one array element appended to the end of the array
under the entry named "cdn-path".

4.7 uses 401 for no permission, while section 8.1 correctly proposes
403 Forbidden (or 404 Not Found) for this case.

5.1.2 uses the phrasing "list of" Error Descriptions, apparently with
the intention that this be an array of Error Descriptions.  Prefer
making this explicit.  Are empty lists allowed?  (The whole entry is
non-mandatory.)

(More generally, the spec could be explicit where empty arrays are
allowed and where not.)

5.1.3: Is staleresourcetime allowed to be negative?  zero?
(Note also that Absolute Time is a general JSON number, which includes
floating point, while this is an integer?)

5.2.6 fails to say that Error Descriptions are JSON objects.

Why is the third request in 6.2.4 not using an ETag, contrary to
its own recommendation?

* Gratuitous formalization of the JSON data:

(I have validated the examples against this formalization, using the
CDDL tool.)


CIT-object = CIT-command / Trigger-Status-Resource / Trigger-Collection

CIT-command ; use media type application/cdni.ci.TriggerCommand+json
 = {
  ? trigger: Triggerspec
  ? cancel: [* URI]
  cdn-path: [* Cdn-PID]
}

Trigger-Status-Resource ; application/cdni.ci.TriggerStatus+json.
 = {
  trigger: Triggerspec
  ctime: Absolute-Time
  mtime: Absolute-Time
  ? etime: Absolute-Time
  status: Trigger-Status
  ? errors: [* Error-Description]
}

Trigger-Collection ; application/cdni.ci.TriggerCollection+json
 = {
  triggers: [* URI]
  ? staleresourcetime: int ; time in seconds
  ? coll-all: URI
  ? coll-pending: URI
  ? coll-active: URI
  ? coll-complete: URI
  ? coll-failed: URI
  ? cdn-id: Cdn-PID
}

Triggerspec = { ; 5.2.1
  type: Trigger-Type
  ? metadata.urls: [* URI]
  ? content.urls: [* URI]
  ? content.ccid: [* Ccid]
  ? metadata.patterns: [* Pattern-Match]
  ? content.patterns: [* Pattern-Match]
}

Trigger-Type = "preposition" / "invalidate" / "purge" ; 5.2.2

Trigger-Status = "pending" / "active" / "complete" / "processed"
   / "failed" / "cancelling" / "cancelled" ; 5.2.3

Pattern-Match = { ; 5.2.4
  pattern: tstr
  ? case-sensitive: bool
  ? match-query-string: bool
}

Absolute-Time = number ; seconds since UNIX epoch, 5.2.5

Error-Description = { ; 5.2.6
  error: Error-Code
  ? metadata.urls: [* URI]
  ? content.urls: [* URI]
  ? metadata.patterns: [* Pattern-Match]
  ? content.patterns: [* Pattern-Match]
  ? description: tstr
}

Error-Code = "emeta" / "econtent" / "eperm" / "ereject"
   / "ecdn" / "ecancelled"  ; 5.2.7

Ccid = tstr ; see I-D.ietf-cdni-metadata

Cdn-PID = tstr .regexp "AS[0-9]+:[0-9]+"

URI = tstr


From nobody Mon Apr  6 19:32:04 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 341F21B2D8A; Mon,  6 Apr 2015 19:32:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t9dwivPeqkMw; Mon,  6 Apr 2015 19:32:01 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 789FF1B2D85; Mon,  6 Apr 2015 19:32:01 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Ben Campbell" 
To: "The IESG" 
X-Test-IDTracker: no
X-IETF-IDTracker: 5.13.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150407023201.9608.96532.idtracker@ietfa.amsl.com>
Date: Mon, 06 Apr 2015 19:32:01 -0700
Archived-At: 
Cc: draft-ietf-appsawg-multipart-form-data@ietf.org, apps-discuss@ietf.org, appsawg-chairs@ietf.org, draft-ietf-appsawg-multipart-form-data.ad@ietf.org
Subject: [apps-discuss] Ben Campbell's Discuss on draft-ietf-appsawg-multipart-form-data-08: (with DISCUSS and COMMENT)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Apr 2015 02:32:03 -0000

Ben Campbell has entered the following ballot position for
draft-ietf-appsawg-multipart-form-data-08: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-appsawg-multipart-form-data/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Hopefully this will be easy to resolve:

Roni Even pointed out in his Gen-ART review that the IANA considerations
section seems to have omitted the content-disposition value of
"form-data", which also currently points to 2388. I suspect this is an
oversight, since "name" is included.

If, on the other hand, the omission was intentional, let me know and I
will clear.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

In the abstract, I suggest changing "... replaces RFC 2388" to "obsoletes
RFC 2388", just to get the right magic words in place.

I concur with Kathleen's comment to move the last paragraph in the
security considerations to the front.



From nobody Tue Apr  7 10:36:29 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC8A1A1BE9; Mon,  6 Apr 2015 15:21:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IvP6Oox6MPWX; Mon,  6 Apr 2015 15:20:58 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A18D1A1BCB; Mon,  6 Apr 2015 15:20:58 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Kathleen Moriarty" 
To: "The IESG" 
X-Test-IDTracker: no
X-IETF-IDTracker: 5.13.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150406222058.29747.96333.idtracker@ietfa.amsl.com>
Date: Mon, 06 Apr 2015 15:20:58 -0700
Archived-At: 
X-Mailman-Approved-At: Tue, 07 Apr 2015 10:36:28 -0700
Cc: draft-ietf-appsawg-multipart-form-data@ietf.org, apps-discuss@ietf.org, appsawg-chairs@ietf.org, draft-ietf-appsawg-multipart-form-data.ad@ietf.org
Subject: [apps-discuss] Kathleen Moriarty's No Objection on draft-ietf-appsawg-multipart-form-data-08: (with COMMENT)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Apr 2015 22:21:00 -0000

Kathleen Moriarty has entered the following ballot position for
draft-ietf-appsawg-multipart-form-data-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-appsawg-multipart-form-data/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Please consider moving the last paragraph to the first in the security
considerations section.  I agree with the point made by the SecDir
reviewer that it improves readability and makes this point clear with
reasons before subsequent paragraphs detail it a bit more specifically.
https://www.ietf.org/mail-archive/web/secdir/current/msg05555.html

I also agree with the SecDir reviewer and suggest you reword the
following paragraph in Appendix B:
   More problematic is the ambiguity introduced because implementations
   did not follow [RFC2388] because it used "may" instead of "MUST" when
   specifying encoding of field names, and for other unknown reasons, so
   now, parsers need to be more complex for fuzzy matching against the
   possible outputs of various encoding methods.

Perhaps to something like:

   More problematic is the ambiguity introduced because implementations
   of [RFC2388] opted to not follow the specification of encoding field
names when the term "may" appeared, where in hindsight it should have
been "MUST". As a result,
   parsers need to be more complex for fuzzy matching against the
   possible outputs of various encoding methods.

If I go something wrong, hopefully you get the point and can easily
adjust the text.

>From the SecDir review:
Please correct me if I'm off base here, but it sounds like the ambiguity
set in because implementations WERE following RFC 2388 by making
choices on their own (due to the "may"s) rather than being directed to
make uniform choices which would have been mandated if that RFC had used
"MUST"s.

Thanks for your work on this draft!



From nobody Tue Apr  7 10:36:43 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 732E01B3204 for ; Mon,  6 Apr 2015 23:43:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bOlXYSGLW1Bl for ; Mon,  6 Apr 2015 23:43:07 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F98C1B3203 for ; Mon,  6 Apr 2015 23:43:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5223; q=dns/txt; s=iport; t=1428388988; x=1429598588; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=dxlmQo6enBPdt0mDJn1lzHH/wDW0Fp9zKam/LGCUJkU=; b=PyCVKvJhTFr0hUNzB8ibJzsPhqkiOnbdSNSXRg8HGG1DhgVItROkMpvV BkUq6pC2VRKyddkM+iKbg12jyYTJaiTdEhtaNY+zG3Z26qfODNQiLBG57 NzT9US42f0Tlo67GKiE+Iv3Vi1G1liBqNaPHZ5gS2ip8eMHHcCTUVnk7a k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DoCwCdeyNV/49dJa1cgwhSXAXCfoJChXsCgShMAQEBAQEBfoQeAQEBAwE6PwULAgEIDgYEHhAyJQIEDgWIJwgNyyUBAQEBAQEBAQEBAQEBAQEBAQEBARiLKYR5B4MXgRYFkGuDdYYNgR06gnuMOoNIIoIDHIFQbwGBAQICHAYcfwEBAQ
X-IronPort-AV: E=Sophos;i="5.11,536,1422921600"; d="scan'208";a="410104141"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-2.cisco.com with ESMTP; 07 Apr 2015 06:43:06 +0000
Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t376h5HW003234 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 7 Apr 2015 06:43:05 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.175]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0195.001; Tue, 7 Apr 2015 01:43:05 -0500
From: "Francois Le Faucheur (flefauch)" 
To: Carsten Bormann 
Thread-Topic: Appsdir review for draft-ietf-cdni-control-triggers-06
Thread-Index: AQHQcMAGJhzM55/dX0yHwAc+Onpkmp1Bbn8A
Date: Tue, 7 Apr 2015 06:43:04 +0000
Message-ID: <860ED8E0-529E-466C-A765-2839A6F7D16A@cisco.com>
References: <5523143E.3070503@tzi.org>
In-Reply-To: <5523143E.3070503@tzi.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.61.69.200]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <57ACCCD0433C60468C9B3EDCB0CD229A@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
X-Mailman-Approved-At: Tue, 07 Apr 2015 10:36:42 -0700
Cc: "draft-ietf-cdni-control-triggers.all@tools.ietf.org" , "Francois Le Faucheur \(flefauch\)" , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Appsdir review for draft-ietf-cdni-control-triggers-06
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 07 Apr 2015 06:43:09 -0000

Carsten,
Thanks very much for your review.

Authors,
Please address these comments.

Cheers

Francois


> On 7 Apr 2015, at 01:18, Carsten Bormann  wrote:
>=20
> I have been selected as an Applications Area Directorate reviewer for
> this draft (for background on appsdir, please see
> http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate
> ), with a specific view on the JSON usage in this specification.
>=20
> Please resolve these comments along with any other comments you may
> receive. Please wait for direction from your document shepherd or AD
> before posting a new version of the draft.  (Feel free to forward
> these comments to the WG list if that helps in resolving the comments.)
>=20
> Document:  draft-ietf-cdni-control-triggers-06
> Title: CDNI Control Interface / Triggers
> Reviewer: Carsten Bormann
> Review Date: 2015-04-06
>=20
> * Summary: This draft is ready for publication as a standards track RFC,
> after a few misphrasings and minor details in the usage of HTTP have
> been corrected.
>=20
> * Major issues: None.
>=20
> * Minor issues:
>=20
> The protocol is REST-based in that it creates dCDN activities using a
> POST-based interface, which then can be examined using GET on the
> location returned (making good use of HTTP, e.g., for caching) and be
> DELETEd for canceling them.  It is not making use of the fact that the
> subject of these activities are REST resources themselves.  This
> paragraph just takes note of this fact, without necessarily suggesting
> a need (or even usefulness) for a change.
>=20
> Is "authenticate" the right word in the 2nd para of 4.1?
> (How do you authenticate a CI/T command?  There is no authentication
> information provided.)
>=20
> For the benefit of the implementer, the last paragraph of section 4.1
> could say what is "an appropriate HTTP status code" here -- 405 Method
> not allowed?
>=20
> 4.2.1 could give a little additional guidance on how to use the ETag
> for the collection (possibly pointing to the examples).
>=20
> 4.3 uses 403 forbidden to indicate that a feature is not implemented?
>=20
> 4.6 the phrasing "into the cdn-path key" used here is misleading: The
> intent is to have one array element appended to the end of the array
> under the entry named "cdn-path".
>=20
> 4.7 uses 401 for no permission, while section 8.1 correctly proposes
> 403 Forbidden (or 404 Not Found) for this case.
>=20
> 5.1.2 uses the phrasing "list of" Error Descriptions, apparently with
> the intention that this be an array of Error Descriptions.  Prefer
> making this explicit.  Are empty lists allowed?  (The whole entry is
> non-mandatory.)
>=20
> (More generally, the spec could be explicit where empty arrays are
> allowed and where not.)
>=20
> 5.1.3: Is staleresourcetime allowed to be negative?  zero?
> (Note also that Absolute Time is a general JSON number, which includes
> floating point, while this is an integer?)
>=20
> 5.2.6 fails to say that Error Descriptions are JSON objects.
>=20
> Why is the third request in 6.2.4 not using an ETag, contrary to
> its own recommendation?
>=20
> * Gratuitous formalization of the JSON data:
>=20
> (I have validated the examples against this formalization, using the
> CDDL tool.)
>=20
>=20
> CIT-object =3D CIT-command / Trigger-Status-Resource / Trigger-Collection
>=20
> CIT-command ; use media type application/cdni.ci.TriggerCommand+json
> =3D {
>  ? trigger: Triggerspec
>  ? cancel: [* URI]
>  cdn-path: [* Cdn-PID]
> }
>=20
> Trigger-Status-Resource ; application/cdni.ci.TriggerStatus+json.
> =3D {
>  trigger: Triggerspec
>  ctime: Absolute-Time
>  mtime: Absolute-Time
>  ? etime: Absolute-Time
>  status: Trigger-Status
>  ? errors: [* Error-Description]
> }
>=20
> Trigger-Collection ; application/cdni.ci.TriggerCollection+json
> =3D {
>  triggers: [* URI]
>  ? staleresourcetime: int ; time in seconds
>  ? coll-all: URI
>  ? coll-pending: URI
>  ? coll-active: URI
>  ? coll-complete: URI
>  ? coll-failed: URI
>  ? cdn-id: Cdn-PID
> }
>=20
> Triggerspec =3D { ; 5.2.1
>  type: Trigger-Type
>  ? metadata.urls: [* URI]
>  ? content.urls: [* URI]
>  ? content.ccid: [* Ccid]
>  ? metadata.patterns: [* Pattern-Match]
>  ? content.patterns: [* Pattern-Match]
> }
>=20
> Trigger-Type =3D "preposition" / "invalidate" / "purge" ; 5.2.2
>=20
> Trigger-Status =3D "pending" / "active" / "complete" / "processed"
>   / "failed" / "cancelling" / "cancelled" ; 5.2.3
>=20
> Pattern-Match =3D { ; 5.2.4
>  pattern: tstr
>  ? case-sensitive: bool
>  ? match-query-string: bool
> }
>=20
> Absolute-Time =3D number ; seconds since UNIX epoch, 5.2.5
>=20
> Error-Description =3D { ; 5.2.6
>  error: Error-Code
>  ? metadata.urls: [* URI]
>  ? content.urls: [* URI]
>  ? metadata.patterns: [* Pattern-Match]
>  ? content.patterns: [* Pattern-Match]
>  ? description: tstr
> }
>=20
> Error-Code =3D "emeta" / "econtent" / "eperm" / "ereject"
>   / "ecdn" / "ecancelled"  ; 5.2.7
>=20
> Ccid =3D tstr ; see I-D.ietf-cdni-metadata
>=20
> Cdn-PID =3D tstr .regexp "AS[0-9]+:[0-9]+"
>=20
> URI =3D tstr


From nobody Tue Apr  7 15:24:30 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E188C1ACD27; Tue,  7 Apr 2015 15:24:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A1LOXOJ3gkzT; Tue,  7 Apr 2015 15:24:25 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF541ACD22; Tue,  7 Apr 2015 15:24:25 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Stephen Farrell" 
To: "The IESG" 
X-Test-IDTracker: no
X-IETF-IDTracker: 5.13.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150407222425.30169.23524.idtracker@ietfa.amsl.com>
Date: Tue, 07 Apr 2015 15:24:25 -0700
Archived-At: 
Cc: apps-discuss@ietf.org, appsawg-chairs@ietf.org
Subject: [apps-discuss] Stephen Farrell's No Objection on draft-ietf-appsawg-uri-scheme-reg-05: (with COMMENT)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Apr 2015 22:24:27 -0000

Stephen Farrell has entered the following ballot position for
draft-ietf-appsawg-uri-scheme-reg-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-appsawg-uri-scheme-reg/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


I put what I think it my most important comment first and hope
to see a response to that. (I don't think it'd be correct for
it to be a DISCUSS, but it's close.)

- 3.7, probably too late in the day to ask for it, but if
there are privacy considerations those would also be good to
note - and there will be for some of the application-specific
schemes, that e.g. have personally identifying information in
the scheme specific part. I'd suggest that renaming 3.7 to
"security and privacy considerations" would be good and saying
e.g. that where the scheme specific part is likely to be
privacy sensitive, then that ought be documented and ways of
minimising privacy-unfriendliness ought be documented.

- 3.2, all except the last para: I personally think the
SHOULDs here are bogus. Why does it matter at all, really?  In
any case, even if you maintain it matters, I'd suggest adding
a bit saying that even minor deployment is a reasonable
justification for going against the SHOULDs. If that's not
likely to garner immediate consensus, as I suspect, then I'll
not insist - we can drop the topic and leave it to folks
registering new schemes to continue to battle the URI
police:-(

- 3.2, last para: I'd suggest moving this quite reasonable
constraint away from the rest of this section.

- 3.6, 2nd para: I don't think you've quite said what you mean
here. "As restrictive as possible" could favour "all octets
are U+00A2" - that is very restrictive, but would be
problematic for many parsers I guess. (The U+00A2 value has no
specific significance.) I think what you meant to say was that
the scheme specification SHOULD be as close as possible to (or
deviate as little as possible from) what is allowed in 3986.

- 3.8: (very nitty nit:-) com.example.info isn't a good choice
as both com and info are gTLDs which may confuse some reader.
I'd suggest com.example.mything or similar.

- 3.8: I'm not sure, but are you really saying here that the
these scheme, after you take away the rightmost component,
ought be in the public suffix list? If so, that might actually
be good guidance as com.example.a.b.c.d is much more likely to
suffer bitrot over time I'd say. (Compared to com.example.abcd
I mean.)

- 7.3, 1st para: it'd have been nice if you could have avoided
IESG action being required for some details (e.g.  a change of
contact address from a@example.com to b@example.com), but I
guess that might be too tricky to get right in text, so ok.

- I agree with Ben's comment wrt loads of SHOULDs



From nobody Tue Apr  7 18:06:09 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DAFB1B2A81; Tue,  7 Apr 2015 18:06:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.902
X-Spam-Level: 
X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rbgx8M-eWK5w; Tue,  7 Apr 2015 18:06:04 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0737.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:737]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78BD61B2A86; Tue,  7 Apr 2015 18:06:03 -0700 (PDT)
Received: from BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) by BY2PR03MB411.namprd03.prod.outlook.com (10.141.141.22) with Microsoft SMTP Server (TLS) id 15.1.130.12; Wed, 8 Apr 2015 01:05:41 +0000
Received: from BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) by BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) with mapi id 15.01.0130.020; Wed, 8 Apr 2015 01:05:42 +0000
From: Dave Thaler 
To: John C Klensin , "draft-ietf-appsawg-uri-scheme-reg.all@ietf.org" , "iesg@ietf.org" , "apps-discuss@ietf.org" 
Thread-Topic: Retroactive application of draft-ietf-appsawg-uri-scheme-reg - comprehensive review
Thread-Index: AQHQbLK+cqpU3jvXIEilgc+GV25Eep1CR4hg
Date: Wed, 8 Apr 2015 01:05:41 +0000
Message-ID: 
References: <2E49FA112B054FFAED69D8A1@JcK-HP8200.jck.com>
In-Reply-To: <2E49FA112B054FFAED69D8A1@JcK-HP8200.jck.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:4898:80e0:ee43::3]
authentication-results: jck.com; dkim=none (message not signed) header.d=none; 
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB411;
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(24454002)(51914003)(52604005)(31014004)(51704005)(230783001)(86362001)(106116001)(2501003)(2656002)(2201001)(19580395003)(33656002)(2950100001)(87936001)(86612001)(92566002)(107886001)(99286002)(2900100001)(76176999)(50986999)(54356999)(40100003)(122556002)(15975445007)(77096005)(102836002)(62966003)(77156002)(76576001)(46102003)(74316001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB411; H:BY2PR03MB412.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:BY2PR03MB411; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB411; 
x-forefront-prvs: 0540846A1D
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.onmicrosoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2015 01:05:41.8810 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB411
Archived-At: 
Subject: Re: [apps-discuss] Retroactive application of draft-ietf-appsawg-uri-scheme-reg - comprehensive review
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 08 Apr 2015 01:06:08 -0000

John Klensin wrote:
> (1) I note that there has been a title change between RFC 4395 ("Guidelin=
es
> and Registration Procedures for New URI Schemes") and 4395bis ("Guideline=
s
> and Registration Procedures for URI
> Schemes") that the authors of the latter did not consider significant eno=
ugh
> to note in their discussion of changes in Appendix A.

Correct, because RFC 4395 already covered guidelines and procedures for
updating existing schemes as well as registering new schemes.  The word "Ne=
w"
in the title of the original RFC simply did not match the actual content.

> The third paragraph of Section 1 begins "This document provides updated
> guidelines for the definition of new schemes..." and "new" is repeated at=
 the
> beginning of Section 3 and at several other points in the document.  I in=
fer
> from that, as well as the above, that the change of title is not intended=
 to be
> substantive=20

Correct as noted above.

> and that, in particular, the procedures established or updated by
> this document do not alter or constrain any of

Not quite correct.  The statement in section 1 and section 3 are about new =
schemes.
*Other* sections of the document (section 7.3 in particular, which replaces
Section 5.3 of RFC 4395) update the process for updating established regist=
rations.
=20
>=20
>  (i) Procedures for updating established registrations
>=20
>  (ii) The ability for a new registration to specify appropriate updating
> procedures for that scheme definition
>=20
>  (iii) The ability for the authoritative entity for a particular already-=
registered
> scheme to change the rules for updating that scheme.  When that scheme
> definition is part of an IETF standards-track document, the usual rules f=
or
> updating standards-track documents apply.
>=20
> and that,
>  (iv) As (probably) pointed out at the end of the second paragraph of the
> introduction, URN namespaces are not part of the scope of this document.
>=20
> As I read 4395bis, all of those statements seem clear to me.
> However, if Larry, especially in his capacity as a listed co-author of 43=
95bis,
> reads it in a different way, I think some clarification is probably neces=
sary
> (and that, if there is no agreement that these are really clarifications,=
 that the
> document should be returned to the WG):
>=20
>  Clarification #1: Either restore "new" to the title and add it to the Ab=
stract or
> insert an explicit statement in the Introduction that reflects the above,=
 ideally
> all three.
>=20
>  Clarification #2: Either clarify very precisely what "explicitly" means =
in the
> sentence  'URN "namespaces"
> ([RFC3406]) are specific to the "urn" scheme and are not covered explicit=
ly by
> this specification.' (a sentence 4395bis appears to have incorporated wit=
hout
> change from
> 4395) or drop "explicitly" from that sentence.

Currently the URN text is unchanged from RFC 4395, and I'm getting the impr=
ession
that it might be challenging to agree on what it should say.
Personally I would be inclined to simply drop that sentence (and mention
of URN the preceding sentence) if it helped move this forward.
The URNbis spec can then take on the task of stating how this doc applies t=
o URNs.

> (2) Section 3 of 4395bis cites the "overall syntax for URIs"
> from RFC 3986 and then says
>=20
> "A scheme definition cannot override the overall syntax for URIs.  For
> example, this means that fragment identifiers cannot be re-used outside t=
he
> generic syntax restrictions, and fragment identifiers are not scheme-spec=
ific."
>=20
> If we can agree that this is not applicable to existing registered scheme
> definitions or updates to them and that future URN-like schemes are unlik=
ely,
> then that is a non-issue.  If we cannot, the AppsAWG and IESG should be
> formally aware (the former has certainly been told about this in various =
area
> meetings) that the current consensus within URNBIS is to separate URNs fr=
om
> the semantic requirements of 3986 [2].  That position was the result of a
> difficult compromise in which the main alternative was to separate URNs
> entirely from what the WG believes are the many assumptions (most derived
> from locators) and some of the confusing language in 3986.
>=20
> The paragraph quoted above appears to be new to 4395bis, does not appear
> to be noted in the appendix that lists changes, and I wonder why it was f=
elt to
> be necessary.=20

I don't think the omission was intentional.  I thought it was in the append=
ix,
and agree it should be added, e.g.:

14. Clarified that since, per RFC 3986, fragment identifiers are not scheme=
-specific
      and hence are not part of the scheme definition.

BTW, the specific text in RFC 3986 section 3.5 which says this is:
" Fragment identifier semantics are independent of the
   URI scheme and thus cannot be redefined by scheme specifications."
together with the text around that sentence which also discusses fragment i=
dentifier syntax.
So this constraint is not new in either RFC 4395 or this update.
As such, it's not a change in meaning, just an editorial change for clarity=
.

> Whether it is applicable to the "urn" scheme or not, the
> statement is factually false.  The only constraint the "overall syntax fo=
r URIs"
> imposes on what 3986 calls a "fragment" is that it be preceded by "#", th=
at it
> extend to the end of the URI, and that it obey the usual rules about
> permitted characters and character
> escaping.   Statements about fragment identifiers being
> scheme-specific are _semantic_ restrictions and, absent a good deal of
> semantics, I can't even figure out what "fragment identifiers cannot be r=
e-
> used outside the generic syntax restrictions" might mean.

I don't think that phrase came from me, but I suspect the intent was that
fragments are defined by RFC 3986 and not by the scheme definition.

>  Clarification #3: Either explicitly exempt URNs (either by name or by "n=
ot
> applicable to existing
> registrations") or fix that paragraph to clarify the difference between s=
yntax
> and semantic restrictions.  In the interest of correctness and technical
> accuracy, a fix seems preferable to an exemption.  The thing I think we s=
hould
> avoid (even though it would be easy from a textual standpoint) is having =
to
> put text in the URNBIS documents that updates 4395bis to remove this
> particular
> apparent requirement.   If we have to have a battle over
> the applicability of that text, it seems to me that the
>    time to do it is while both documents are still under consideration, i=
.e.,
> now.

This document needs to be consistent with RFC 3986 and what generic URI
parsers do.  Do you have a suggestion on what you're looking for in terms o=
f
"the difference between syntax and semantic restrictions"?  I'm not quite
sure what you're getting at, but hopefully you understand my personal posit=
ion
enough to suggest something I can understand.
=20
> (3) I observe that 4395bis appears to considerably increase and tighten t=
he
> binding to 3986 relative to 4395, with the above being just one example.
> Those who have been watching developments closely are aware that there
> are multiple efforts in progress in different organizations that have the=
 intent
> to revise or even supercede 3986.  The IETF has not taken a strong positi=
on
> about those other efforts and there have apparently been AD-level
> discussions about ceding generic URI work to other
> bodies.   Given that state of uncertainty and the IETF's
> presumed desire to avoid having changes in the status of 3986 drag this
> 4395bis specification into obsolescence, it would seem desirable to make =
this
> document and procedure less, rather than more, dependent on specific text
> and wording in 3986.
> Alternately, if the intent of those additional dependencies is to try to =
defend
> against internal or external alterations to 3986, I believe that should b=
e
> handled up front rather than trying to use this registration specificatio=
n as a
> back door.

I believe the constraint on 4395bis was indeed to depend on RFC 3986.
That is, I believe this is intentional.

>  Clarification #4/ Recommendation: The authors or others should make a
> careful pass through this document, eliminating specific dependencies on
> 3986 where possible and clarifying the intent of what remains sufficientl=
y to
> preserve the effectiveness of this specification
> should 3986 be superceded.   If that is not feasible,
> the IANA Considerations section of this document should be clear about th=
e
> status of the registration procedure (and the registry that it specifies)=
 should
> the references on which the spec is normatively dependent be superceded
> (that would probably be a good idea for all registration specifications t=
hat are
> not self-contained, but it is important in this case because there appear=
s to
> be a real possibility that documents that supercede
> 3986 will not be under IETF change control).

I don't believe the former is feasible, but an IANA note as you suggest
might be feasible.  Personally, I believe that such a note would best be
authored by the IESG, should the IESG wish such a note.   However, I am
not convinced that any such note is necessary.
=20
> (4) The second sentence of the first paragraph of Section 3.3
> ("Well-defined") says:
>=20
> "Schemes that are not intended to be used as locators SHOULD describe how
> the resource identified can be determined or accessed by software that
> obtains a URI of that scheme."
>=20
> If this is intended to be applicable to URN or URN-like schemes that are =
used
> as what URNBIS has been calling "indicators", it is not clear what the
> requirement statement means.  Requirement statements without clean
> meaning vis-a-vis all of the cases to which they might apply are undesira=
ble
> and are indeed "technical deficiencies".
>
>  Clarification #5: Either clarify the excluded cases implied by the "SHOU=
LD" or
> explicitly exempt URNs and any similar schemes that might be developed or
> registered in the future.

It's just a SHOULD, not a MUST.  I don't think IETF specs need to enumerate
all cases where SHOULDs might not apply.   Since URIs can be used for anyth=
ing
(mathematical equations, numeric values, etc.), I don't think it's possible
to try to clarify excluded cases in any meaningful way.

> (5)  The last paragraph of Section 3.3, much of it copied intact from RFC=
 4395,
> suggests a requirement that all "legal protocol interactions" of another
> protocol must be capable of being mapped into the URI and calls out "ftp"=
 as
> an example.  One significant change from 4395 (not noted in the Appendix
> that lists changes) is the transformation from an informal "must"
> suggestion about the mapping model to a normative "MUST". That "MUST"
> actually contradicts the final sentence of the paragraph which begins "If=
 not
> all legal values or protocol interactions of the base standard can be
> represented..."

That was presumably seen as synonymous and a simple editorial fix.
However I agree with the point that the last sentence envisions the lack of=
 the MUST
in which case it should be SHOULD for consistency.  As editor of the curren=
t version,
I can say there was no intent I am aware of to change the actual meaning.
Hence I think s/MUST/SHOULD/

> This raises two issues.  First, if 4395bis (especially its normative requ=
irements)
> is to be applied retroactively to existing registrations, then the regist=
ration of
> the ftp scheme is now invalid (whether that last sentence is considered a=
s a
> path to an exception or not).  First, the discussion in RFC 1738, which i=
s
> referenced as the definition of the scheme from the IANA registry, is not
> complete relative to the functionality of the FTP protocol as of the time=
 RFC
> 1738 was written and does not explain the exceptions.  It even says that =
it is
> incomplete with the rather magical sentence (in Section 3.2.2 of RFC 1738=
)
> that reads "The mechanism for doing so is not spelled out here."
> The IETF has also chosen to standardize a number of extensions to FTP
> (including, in these IPv6 and security-conscious days, RFCs 2428 and 4217=
)
> that have not been reflected in either the registration or in an update t=
o RFC
> 1738.  Second, even for new registrations, changing informal guidance tha=
t
> happens to use the word "must" to a normative absolute requirement (with
> "MUST") should require much more careful review and evaluation by the
> community than this change appears to have gotten (especially given the
> apparent contradiction it introduces).
>=20
> FWIW, I haven't done a careful review, but it is not clear to me that eve=
n the
> "http:" scheme, as reflected in the IANA registry, would be considered va=
lid by
> the criteria in 4395bis given functionality changes introduced by HTTP2 a=
nd
> other relatively recent changes and extensions.
>=20
> I note, also FWIW, that Section 3.4 is much more balanced and reasoned an=
d
> that it uses "SHOULD" consistently and not "MUST".

And I agree that section 3.3 should do the same.

>=20
> Retroactive application of Section 3.7 ("Clear Security
> Considerations") would also invalidate a number of existing registrations=
.

There is no intent to be retroactive, only to apply to new requests to IANA
(whether those are requests for new schemes, or new requests to update
existing schemes.)

>=20
>  Clarification #6: This example, which has nothing to do with URNs or, un=
less
> the long-expired draft-hoffman-ftp-uri is considered, any other active UR=
I-
> defining work in the IETF, points out another reason why it is important =
that
> this 4395bis document explicitly disclaim applicability to any already-
> registered scheme or updates to it except as the most general guidance an=
d
> recommendations of issues to
>    be considered.
>=20
>  Clarification #7: The MUST in the cited paragraph should be, at most, a
> "SHOULD" or the paragraph should be reworded to correctly reflect realist=
ic
> intent.

Again, agreed (and done in my local copy).

>  Clarification #8/Recommendation: The list of Changes in Appendix A shoul=
d
> be expanded to reflect all changes from general guidance (expressed in, e=
.g.,
> "must" or
> "should") to normative requirements.  Treating such changes as editorial
> corrections is appropriate only when the context clearly indicates normat=
ive
> intent and the changes do not introduce contradictions either within the =
text
> or to established practices.

Added (in my local copy) #14 as I suggested above.

> (6) URN work has made it clear that defining the scope of applicability o=
f a
> URI scheme is, at best, a shared responsibility between whatever
> documentation defines the scheme and the documentation that defines the
> referencing context.
> Attempts to shift all of that responsibility to the scheme definition, as=
 Section
> 3.5 can be interpreted to do, is unrealistic if only because the scheme
> definition cannot predict referencing contexts that might be defined or
> redefined in the future.  Given that the current text uses a "SHOULD", it=
 is
> probably ok, but a clarification that contexts that incorporate URI refer=
ences
> also bear some responsibility for describing the schemes that are valid a=
nd
> meaningful (preferably on an inclusion basis) would be helpful to avoid
> outrageous claims in the future.  Anyone contemplating a 4395ter might
> consider whether adding an "applicable application, protocol, or context"
> field to the IANA registry would be useful.
>
>  Clarification #9: Add a sentence to Section 3.5 to clarify that its prov=
isions do
> not eliminate the requirement for the applications and/or protocols from
> which URIs are used to discuss the schemes that are (or are not) relevant=
 and
> appropriate for use in those contexts.

How's this:
NEW: This does not obviate the need for documentation on applications and/o=
r
NEW: protocols to discuss URI schemes relevant to them.

> (7) In my capacity as someone who is supposed to know a bit about i18n
> issues, I think I understand the intent that motivated the inclusion of t=
he last
> paragraph of Section 3.6.
> However, after reading that paragraph several times, I am not sure what i=
t
> actually means.  If the term "variant" (which I would encourage authors t=
o
> avoid) is interpreted in its ICANN usage or even as defined in Section 7.=
2 of
> RFC 6365, I am _sure_ I don't know what the paragraph means.
>=20
>  Clarification #10: That paragraph needs to be rewritten and carefully ch=
ecked
> by i18n experts.  Encouraging the registration to make a clear statement
> about normalization and/or other comparison-related issues would probably
> be desirable.

Is this better:
NEW: Percent-encoded character sequences are automatically included by
NEW: definition for characters given in IRI productions.

> (8) Section 7.3 is not explicit that an updated registration can change t=
he
> mechanism for future updates, nor that registrations, especially those
> associated with IETF documents, can specify update/change mechanisms
> different from those specified in this
> document.   Had I been asked a month ago, I would have said that
> both were obvious and that further explanation was not required.
> Since recent discussions have called both into question, I think some
> clarification is needed.

Personally I still think that both are obvious (Larry's email notwithstandi=
ng)
and that further explanation is not required.  That is, I still agree with
the John of last month :)
=20
>  Clarification #11: Add text to Section 7.3 to make it explicit that sche=
me
> registrations MAY specify updating procedures that are more specific than
> those outlined in 4395bis, including identifying other approval mechanism=
s or
> responsible parties, and that scheme registration updates may modify the
> updating mechanism as well as other aspects of the registration.

I'm not even sure what that means after reading it twice.
 =20
>  Clarification #12: In the template shown in Section 7.4, add to the "Cha=
nge
> controller:" entry a statement equivalent to "Any special considerations
> about updating or updating procedures should also appear as part of this
> item."

I'm not convinced that's necessary (not sure what the WG thinks) but this
seems like a new issue and so I'm hesitant to delay for something that woul=
d
be a MAY statement anyway.   I.e., doesn't sound like a blocker to me.

> (9) Further evidence that this document is confused about existing
> registrations, retroactive application, and its own
> requirements appears in Section 8.   The "example" URI scheme
> registration that is specified in that section does not appear to conform=
 to
> the "fields that MUST be supplied" requirements of Section 7.4: there is =
no
> contact given and the "Change controller" field is identified as
> "Author/Change controller".
> If that flexibility was intended by Section 7.4, the document should say =
so.

Oops, I'll take the blame for that one.  I held the pen on doing the latest=
 updates
and I missed section 8 when I updated section 7.4.  Thanks for pointing tha=
t out,
I've corrected section 8 in my local copy.

Thanks for the careful review,
Dave

>=20
> thanks,
>     john
>=20
>=20
>=20
> [1]
> http://www.ietf.org/mail-archive/web/urn/current/msg02873.html
>=20
> [2]
> https://datatracker.ietf.org/doc/draft-ietf-urnbis-semantics-clarif/
>=20


From nobody Tue Apr  7 18:06:13 2015
Return-Path: 
X-Original-To: expand-draft-ietf-appsawg-uri-scheme-reg.all@virtual.ietf.org
Delivered-To: apps-discuss@ietfa.amsl.com
Received: by ietfa.amsl.com (Postfix, from userid 65534) id 829941B2A87; Tue,  7 Apr 2015 18:06:08 -0700 (PDT)
X-Original-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com
Delivered-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DAFB1B2A81; Tue,  7 Apr 2015 18:06:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.902
X-Spam-Level: 
X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rbgx8M-eWK5w; Tue,  7 Apr 2015 18:06:04 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0737.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:737]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78BD61B2A86; Tue,  7 Apr 2015 18:06:03 -0700 (PDT)
Received: from BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) by BY2PR03MB411.namprd03.prod.outlook.com (10.141.141.22) with Microsoft SMTP Server (TLS) id 15.1.130.12; Wed, 8 Apr 2015 01:05:41 +0000
Received: from BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) by BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) with mapi id 15.01.0130.020; Wed, 8 Apr 2015 01:05:42 +0000
From: Dave Thaler 
To: John C Klensin , "draft-ietf-appsawg-uri-scheme-reg.all@ietf.org" , "iesg@ietf.org" , "apps-discuss@ietf.org" 
Thread-Topic: Retroactive application of draft-ietf-appsawg-uri-scheme-reg - comprehensive review
Thread-Index: AQHQbLK+cqpU3jvXIEilgc+GV25Eep1CR4hg
Date: Wed, 8 Apr 2015 01:05:41 +0000
Message-ID: 
References: <2E49FA112B054FFAED69D8A1@JcK-HP8200.jck.com>
In-Reply-To: <2E49FA112B054FFAED69D8A1@JcK-HP8200.jck.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:4898:80e0:ee43::3]
authentication-results: jck.com; dkim=none (message not signed) header.d=none; 
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB411;
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(24454002)(51914003)(52604005)(31014004)(51704005)(230783001)(86362001)(106116001)(2501003)(2656002)(2201001)(19580395003)(33656002)(2950100001)(87936001)(86612001)(92566002)(107886001)(99286002)(2900100001)(76176999)(50986999)(54356999)(40100003)(122556002)(15975445007)(77096005)(102836002)(62966003)(77156002)(76576001)(46102003)(74316001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB411; H:BY2PR03MB412.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:BY2PR03MB411; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB411; 
x-forefront-prvs: 0540846A1D
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.onmicrosoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2015 01:05:41.8810 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB411
Archived-At: 
Subject: Re: [apps-discuss] Retroactive application of draft-ietf-appsawg-uri-scheme-reg - comprehensive review
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 08 Apr 2015 01:06:08 -0000

John Klensin wrote:
> (1) I note that there has been a title change between RFC 4395 ("Guidelin=
es
> and Registration Procedures for New URI Schemes") and 4395bis ("Guideline=
s
> and Registration Procedures for URI
> Schemes") that the authors of the latter did not consider significant eno=
ugh
> to note in their discussion of changes in Appendix A.

Correct, because RFC 4395 already covered guidelines and procedures for
updating existing schemes as well as registering new schemes.  The word "Ne=
w"
in the title of the original RFC simply did not match the actual content.

> The third paragraph of Section 1 begins "This document provides updated
> guidelines for the definition of new schemes..." and "new" is repeated at=
 the
> beginning of Section 3 and at several other points in the document.  I in=
fer
> from that, as well as the above, that the change of title is not intended=
 to be
> substantive=20

Correct as noted above.

> and that, in particular, the procedures established or updated by
> this document do not alter or constrain any of

Not quite correct.  The statement in section 1 and section 3 are about new =
schemes.
*Other* sections of the document (section 7.3 in particular, which replaces
Section 5.3 of RFC 4395) update the process for updating established regist=
rations.
=20
>=20
>  (i) Procedures for updating established registrations
>=20
>  (ii) The ability for a new registration to specify appropriate updating
> procedures for that scheme definition
>=20
>  (iii) The ability for the authoritative entity for a particular already-=
registered
> scheme to change the rules for updating that scheme.  When that scheme
> definition is part of an IETF standards-track document, the usual rules f=
or
> updating standards-track documents apply.
>=20
> and that,
>  (iv) As (probably) pointed out at the end of the second paragraph of the
> introduction, URN namespaces are not part of the scope of this document.
>=20
> As I read 4395bis, all of those statements seem clear to me.
> However, if Larry, especially in his capacity as a listed co-author of 43=
95bis,
> reads it in a different way, I think some clarification is probably neces=
sary
> (and that, if there is no agreement that these are really clarifications,=
 that the
> document should be returned to the WG):
>=20
>  Clarification #1: Either restore "new" to the title and add it to the Ab=
stract or
> insert an explicit statement in the Introduction that reflects the above,=
 ideally
> all three.
>=20
>  Clarification #2: Either clarify very precisely what "explicitly" means =
in the
> sentence  'URN "namespaces"
> ([RFC3406]) are specific to the "urn" scheme and are not covered explicit=
ly by
> this specification.' (a sentence 4395bis appears to have incorporated wit=
hout
> change from
> 4395) or drop "explicitly" from that sentence.

Currently the URN text is unchanged from RFC 4395, and I'm getting the impr=
ession
that it might be challenging to agree on what it should say.
Personally I would be inclined to simply drop that sentence (and mention
of URN the preceding sentence) if it helped move this forward.
The URNbis spec can then take on the task of stating how this doc applies t=
o URNs.

> (2) Section 3 of 4395bis cites the "overall syntax for URIs"
> from RFC 3986 and then says
>=20
> "A scheme definition cannot override the overall syntax for URIs.  For
> example, this means that fragment identifiers cannot be re-used outside t=
he
> generic syntax restrictions, and fragment identifiers are not scheme-spec=
ific."
>=20
> If we can agree that this is not applicable to existing registered scheme
> definitions or updates to them and that future URN-like schemes are unlik=
ely,
> then that is a non-issue.  If we cannot, the AppsAWG and IESG should be
> formally aware (the former has certainly been told about this in various =
area
> meetings) that the current consensus within URNBIS is to separate URNs fr=
om
> the semantic requirements of 3986 [2].  That position was the result of a
> difficult compromise in which the main alternative was to separate URNs
> entirely from what the WG believes are the many assumptions (most derived
> from locators) and some of the confusing language in 3986.
>=20
> The paragraph quoted above appears to be new to 4395bis, does not appear
> to be noted in the appendix that lists changes, and I wonder why it was f=
elt to
> be necessary.=20

I don't think the omission was intentional.  I thought it was in the append=
ix,
and agree it should be added, e.g.:

14. Clarified that since, per RFC 3986, fragment identifiers are not scheme=
-specific
      and hence are not part of the scheme definition.

BTW, the specific text in RFC 3986 section 3.5 which says this is:
" Fragment identifier semantics are independent of the
   URI scheme and thus cannot be redefined by scheme specifications."
together with the text around that sentence which also discusses fragment i=
dentifier syntax.
So this constraint is not new in either RFC 4395 or this update.
As such, it's not a change in meaning, just an editorial change for clarity=


From nobody Tue Apr  7 18:34:49 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABA7A1ACE4E for ; Tue,  7 Apr 2015 18:34:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.902
X-Spam-Level: 
X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id soVrafAO9J9h for ; Tue,  7 Apr 2015 18:34:46 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0788.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::788]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E0061ACE5B for ; Tue,  7 Apr 2015 18:34:46 -0700 (PDT)
Received: from BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) by BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) with Microsoft SMTP Server (TLS) id 15.1.130.12; Wed, 8 Apr 2015 01:34:23 +0000
Received: from BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) by BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) with mapi id 15.01.0130.020; Wed, 8 Apr 2015 01:34:23 +0000
From: Dave Thaler 
To: Mark Nottingham , IETF Apps Discuss 
Thread-Topic: [apps-discuss] I-D Action: draft-ietf-appsawg-uri-scheme-reg-05.txt
Thread-Index: AQHQaKveeIsZSSe1JESyWl6FTPekhJ06RxEAgAgeZOA=
Date: Wed, 8 Apr 2015 01:34:23 +0000
Message-ID: 
References: <20150327163331.20999.18776.idtracker@ietfa.amsl.com> <7EC6D912-3211-44E0-A739-D43BA7214BD5@mnot.net>
In-Reply-To: <7EC6D912-3211-44E0-A739-D43BA7214BD5@mnot.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:4898:80e0:ee43::3]
authentication-results: mnot.net; dkim=none (message not signed) header.d=none;
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB412;
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(51704005)(377454003)(13464003)(164054003)(24454002)(377424004)(46102003)(86362001)(2950100001)(2900100001)(230783001)(19580395003)(50986999)(92566002)(19580405001)(76176999)(2656002)(87936001)(74316001)(99286002)(86612001)(15975445007)(122556002)(106116001)(33656002)(54356999)(76576001)(77156002)(1720100001)(62966003)(107886001)(77096005)(40100003)(102836002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB412; H:BY2PR03MB412.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:BY2PR03MB412; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB412; 
x-forefront-prvs: 0540846A1D
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.onmicrosoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2015 01:34:23.4417 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB412
Archived-At: 
Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-uri-scheme-reg-05.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 08 Apr 2015 01:34:48 -0000

PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBhcHBzLWRpc2N1c3MgW21haWx0
bzphcHBzLWRpc2N1c3MtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1hcmsNCj4gTm90
dGluZ2hhbQ0KPiBTZW50OiBUaHVyc2RheSwgQXByaWwgMiwgMjAxNSAyOjMwIFBNDQo+IFRvOiBJ
RVRGIEFwcHMgRGlzY3Vzcw0KPiBTdWJqZWN0OiBSZTogW2FwcHMtZGlzY3Vzc10gSS1EIEFjdGlv
bjogZHJhZnQtaWV0Zi1hcHBzYXdnLXVyaS1zY2hlbWUtcmVnLTA1LnR4dA0KPiANCj4gSnVzdCBh
IGJpdCBvZiBmZWVkYmFjayDigJQNCj4gDQo+ICogVGhlIG5ldyB0ZXh0IGluIFNlY3Rpb24gMyAo
IkEgc2NoZW1lIGRlZmluaXRpb24gY2Fubm90IG92ZXJyaWRl4oCmIikgc2VlbXMNCj4gbGlrZSBp
dCdzIGVxdWFsbHkgYXBwbGljYWJsZSB0byBwcm92aXNpb25hbCBzY2hlbWVzLiBJJ2Qgc3VnZ2Vz
dCBtb3ZpbmcgdGhpcyB0bw0KPiAzLjIgYW5kIHRoZW4gcmVmZXJyaW5nIHRvIGl0IGZyb20gU2Vj
dGlvbiA0IChhcyBhIE1VU1Q/KS4NCg0KSXQgbWF5IGJlIGFwcGxpY2FibGUgYnV0IGl0J3Mgbm90
ICJlcXVhbGx5IiBhcHBsaWNhYmxlIGJlY2F1c2UgYSBwcm92aXNpb25hbA0Kc2NoZW1lIGlzIG5v
IGxvbmdlciByZXF1aXJlZCB0byBoYXZlIGEgc2NoZW1lIGRlZmluaW5nIGRvY3VtZW50Lg0KQWxz
bywgaW4gbXkgb3BpbmlvbiBpdCdzIG5vdCBhIG5vcm1hdGl2ZSByZXF1aXJlbWVudCAoTVVTVCkg
YnV0IHJhdGhlciANCmEgc2ltcGxlIHN0YXRlbWVudCBvZiBmYWN0Li4uIHlvdSBjYW5ub3Qgb3Zl
cnJpZGUgd2hhdCBhIGdlbmVyaWMgcGFyc2VyDQp3aXRoIG5vIHNjaGVtZS1zcGVjaWZpYyBrbm93
bGVkZ2Ugd2lsbCBkbywgYnkgZGVmaW5pdGlvbi4NCg0KPiAqIFNlY3Rpb24gNCBjb25zdHJ1Y3Rz
IGEgY29uZmxpY3RpbmcgcmVxdWlyZW1lbnQgIuKApiB0aGUgZm9sbG93aW5nIGFyZQ0KPiBSRVFV
SVJFRDog4oCmIFRoZSBzY2hlbWUgZGVmaW5pdGlvbiBTSE9VTEQg4oCmIiAgVGhpcyBpcyBjb25m
dXNpbmcg4oCUIGlzIGl0DQo+IFJFUVVJUkVEIG9yIFNIT1VMRD8gSSdkIHN1Z2dlc3QgY2hhbmdp
bmcgdGhlIHN0YXJ0IHRvICLigKYgdGhlIGZvbGxvd2luZw0KPiByZXF1aXJlbWVudHMgYXBwbHk6
Ii4NCg0KR29vZCBwb2ludCwgdGhpcyBuZWVkcyBhIGdyYW1tYXRpY2FsIGZpeCBhcyB5b3Ugc3Vn
Z2VzdC4gIEkgYWdyZWUgd2l0aA0KeW91ciB3b3JkaW5nIGZpeCBleGNlcHQgdGhhdCB0aGUgZmly
c3QgYW5kIHRoaXJkIGJ1bGxldHMgbmVlZCBhIGdyYW1tYXRpY2FsDQpmaXggd2l0aCB0aGUgbmV3
IHdvcmRpbmcsIHNpbmNlIHRoZXkgcmVsaWVkIG9uIHRoZSB3b3JkIFJFUVVJUkVELiAgIEkgd2ls
bA0KYWRkIE1VU1QgdG8gdGhvc2UgdHdvIGJ1bGxldHMgdG8gcmV0YWluIHRoZSBtZWFuaW5nLg0K
DQpUaGFua3MsDQpEYXZlDQoNCj4gDQo+IENoZWVycywNCj4gDQo+IA0KPiA+IE9uIDI4IE1hciAy
MDE1LCBhdCAzOjMzIGFtLCBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgd3JvdGU6DQo+ID4NCj4g
Pg0KPiA+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5l
IEludGVybmV0LURyYWZ0cw0KPiBkaXJlY3Rvcmllcy4NCj4gPiBUaGlzIGRyYWZ0IGlzIGEgd29y
ayBpdGVtIG9mIHRoZSBBcHBsaWNhdGlvbnMgQXJlYSBXb3JraW5nIEdyb3VwIFdvcmtpbmcNCj4g
R3JvdXAgb2YgdGhlIElFVEYuDQo+ID4NCj4gPiAgICAgICAgVGl0bGUgICAgICAgICAgIDogR3Vp
ZGVsaW5lcyBhbmQgUmVnaXN0cmF0aW9uIFByb2NlZHVyZXMgZm9yIFVSSSBTY2hlbWVzDQo+ID4g
ICAgICAgIEF1dGhvcnMgICAgICAgICA6IERhdmUgVGhhbGVyDQo+ID4gICAgICAgICAgICAgICAg
ICAgICAgICAgIFRvbnkgSGFuc2VuDQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgIFRlZCBI
YXJkaWUNCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgTGFycnkgTWFzaW50ZXINCj4gPiAJ
RmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1hcHBzYXdnLXVyaS1zY2hlbWUtcmVnLTA1LnR4
dA0KPiA+IAlQYWdlcyAgICAgICAgICAgOiAxOQ0KPiA+IAlEYXRlICAgICAgICAgICAgOiAyMDE1
LTAzLTI3DQo+ID4NCj4gPiBBYnN0cmFjdDoNCj4gPiAgIFRoaXMgZG9jdW1lbnQgdXBkYXRlcyB0
aGUgZ3VpZGVsaW5lcyBhbmQgcmVjb21tZW5kYXRpb25zLCBhcyB3ZWxsIGFzDQo+ID4gICB0aGUg
SUFOQSByZWdpc3RyYXRpb24gcHJvY2Vzc2VzLCBmb3IgdGhlIGRlZmluaXRpb24gb2YgVW5pZm9y
bQ0KPiA+ICAgUmVzb3VyY2UgSWRlbnRpZmllciAoVVJJKSBzY2hlbWVzLiAgSXQgb2Jzb2xldGVz
IFJGQyA0Mzk1Lg0KPiA+DQo+ID4NCj4gPiBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFn
ZSBmb3IgdGhpcyBkcmFmdCBpczoNCj4gPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv
Yy9kcmFmdC1pZXRmLWFwcHNhd2ctdXJpLXNjaGVtZS1yZWcvDQo+ID4NCj4gPiBUaGVyZSdzIGFs
c28gYSBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDoNCj4gPiBodHRwOi8vdG9vbHMuaWV0
Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWFwcHNhd2ctdXJpLXNjaGVtZS1yZWctMDUNCj4gPg0KPiA+
IEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCj4gPiBo
dHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWFwcHNhd2ctdXJpLXNj
aGVtZS1yZWctMDUNCj4gPg0KPiA+DQo+ID4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBh
IGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCj4gPiBzdWJtaXNzaW9uIHVudGls
IHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0
Zi5vcmcuDQo+ID4NCj4gPiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFu
b255bW91cyBGVFAgYXQ6DQo+ID4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8N
Cj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
DQo+ID4gYXBwcy1kaXNjdXNzIG1haWxpbmcgbGlzdA0KPiA+IGFwcHMtZGlzY3Vzc0BpZXRmLm9y
Zw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXBwcy1kaXNjdXNz
DQo+IA0KPiAtLQ0KPiBNYXJrIE5vdHRpbmdoYW0gICBodHRwczovL3d3dy5tbm90Lm5ldC8NCj4g
DQo+IA0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fDQo+IGFwcHMtZGlzY3VzcyBtYWlsaW5nIGxpc3QNCj4gYXBwcy1kaXNjdXNzQGlldGYu
b3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXBwcy1kaXNjdXNz
DQo=


From nobody Tue Apr  7 18:38:57 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE6C91ACE6F; Tue,  7 Apr 2015 18:38:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.902
X-Spam-Level: 
X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gg-9srz8L6da; Tue,  7 Apr 2015 18:38:54 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0725.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:725]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44CD31A0013; Tue,  7 Apr 2015 18:38:54 -0700 (PDT)
Received: from BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) by BY2PR03MB411.namprd03.prod.outlook.com (10.141.141.22) with Microsoft SMTP Server (TLS) id 15.1.130.12; Wed, 8 Apr 2015 01:38:38 +0000
Received: from BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) by BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) with mapi id 15.01.0130.020; Wed, 8 Apr 2015 01:38:38 +0000
From: Dave Thaler 
To: Ben Campbell , The IESG 
Thread-Topic: [apps-discuss] Ben Campbell's No Objection on draft-ietf-appsawg-uri-scheme-reg-05: (with COMMENT)
Thread-Index: AQHQcL4C9soaX+5mOU2q46dUbMyZ1J1CVx1A
Date: Wed, 8 Apr 2015 01:38:38 +0000
Message-ID: 
References: <20150406230346.17020.71285.idtracker@ietfa.amsl.com>
In-Reply-To: <20150406230346.17020.71285.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:4898:80e0:ee43::3]
authentication-results: nostrum.com; dkim=none (message not signed) header.d=none;
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB411;
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(377454003)(13464003)(51704005)(52044002)(230783001)(86362001)(106116001)(2656002)(19580405001)(19580395003)(33656002)(2950100001)(87936001)(86612001)(92566002)(99286002)(2900100001)(76176999)(50986999)(54356999)(40100003)(122556002)(15975445007)(77096005)(102836002)(62966003)(77156002)(76576001)(46102003)(74316001)(411114002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB411; H:BY2PR03MB412.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:BY2PR03MB411; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB411; 
x-forefront-prvs: 0540846A1D
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.onmicrosoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2015 01:38:38.4906 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB411
Archived-At: 
Cc: "appsawg-chairs@ietf.org" , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Ben Campbell's No Objection on draft-ietf-appsawg-uri-scheme-reg-05: (with COMMENT)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 08 Apr 2015 01:38:56 -0000

> -----Original Message-----
> From: apps-discuss [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Be=
n
> Campbell
> Sent: Monday, April 6, 2015 4:04 PM
> To: The IESG
> Cc: apps-discuss@ietf.org; appsawg-chairs@ietf.org
> Subject: [apps-discuss] Ben Campbell's No Objection on draft-ietf-appsawg=
-
> uri-scheme-reg-05: (with COMMENT)
>=20
> Ben Campbell has entered the following ballot position for
> draft-ietf-appsawg-uri-scheme-reg-05: No Objection
>=20
> When responding, please keep the subject line intact and reply to all ema=
il
> addresses included in the To and CC lines. (Feel free to cut this introdu=
ctory
> paragraph, however.)
>=20
>=20
> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>=20
>=20
> The document, along with other ballot positions, can be found here:
> http://datatracker.ietf.org/doc/draft-ietf-appsawg-uri-scheme-reg/
>=20
>=20
>=20
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>=20
> I am curious how the expert review required in the document interacts wit=
h
> bona-fide standards actions. There's already an ongoing discussion on tha=
t,
> and Barry has noted it in his on comments, so I will leave this as a comm=
ent.
> In particular I wonder if the "On receipt of a registration request" sect=
ion of
> 7.2 should be different if the request was part of an IETF/IESG reviewed =
and
> approved action in the first place.

RFC 4395 made no distinction and the WG has not discussed making any
such distinction.  So unless it's a blocker (which does not seem to be the =
case
in your comment at least), the current answer is "no difference".
=20
> There are a lot of SHOULDs in this document. I wonder how an expert
> reviewer is supposed to interpret deviations from SHOULD level requiremen=
ts.
> This is especially true in statements like "... SHOULD include clear secu=
rity
> considerations or explain [why not]". The expert's life might be easier i=
f there
> was some text encouraging that deviations from SHOULDs be accompanied by
> an explanation.

FYI, in this particular case, the meaning isn't different from RFC 4395 whi=
ch was even
less precise, so the expert in question has already been dealing with this =
and
anything we say won't make his life easier unless we change the actual mean=
ing
(which is not the intent).

Dave


From nobody Tue Apr  7 18:56:38 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA8E1B2AF2; Tue,  7 Apr 2015 18:56:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.902
X-Spam-Level: 
X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3pDAsCZMY5dc; Tue,  7 Apr 2015 18:56:31 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0146.outbound.protection.outlook.com [65.55.169.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AB7E1B2AFC; Tue,  7 Apr 2015 18:56:24 -0700 (PDT)
Received: from BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) by BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) with Microsoft SMTP Server (TLS) id 15.1.130.12; Wed, 8 Apr 2015 01:56:22 +0000
Received: from BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) by BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) with mapi id 15.01.0130.020; Wed, 8 Apr 2015 01:56:22 +0000
From: Dave Thaler 
To: Stephen Farrell , The IESG 
Thread-Topic: [apps-discuss] Stephen Farrell's No Objection on draft-ietf-appsawg-uri-scheme-reg-05: (with COMMENT)
Thread-Index: AQHQcYGfAl9j2zyYQU2SQnVtgcEVj51CVpIQ
Date: Wed, 8 Apr 2015 01:56:22 +0000
Message-ID: 
References: <20150407222425.30169.23524.idtracker@ietfa.amsl.com>
In-Reply-To: <20150407222425.30169.23524.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:4898:80e0:ee43::3]
authentication-results: cs.tcd.ie; dkim=none (message not signed) header.d=none;
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB412;
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(51704005)(377454003)(13464003)(52044002)(86362001)(46102003)(2950100001)(50986999)(2900100001)(19580395003)(230783001)(92566002)(19580405001)(76176999)(2656002)(87936001)(74316001)(99286002)(86612001)(77156002)(122556002)(15975445007)(33656002)(106116001)(76576001)(54356999)(62966003)(77096005)(40100003)(102836002)(3826002)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB412; H:BY2PR03MB412.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:BY2PR03MB412; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB412; 
x-forefront-prvs: 0540846A1D
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.onmicrosoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2015 01:56:22.1709 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB412
Archived-At: 
Cc: "appsawg-chairs@ietf.org" , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Stephen Farrell's No Objection on draft-ietf-appsawg-uri-scheme-reg-05: (with COMMENT)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 08 Apr 2015 01:56:34 -0000

> -----Original Message-----
> From: apps-discuss [mailto:apps-discuss-bounces@ietf.org] On Behalf Of
> Stephen Farrell
> Sent: Tuesday, April 7, 2015 3:24 PM
> To: The IESG
> Cc: apps-discuss@ietf.org; appsawg-chairs@ietf.org
> Subject: [apps-discuss] Stephen Farrell's No Objection on draft-ietf-apps=
awg-
> uri-scheme-reg-05: (with COMMENT)
>=20
> Stephen Farrell has entered the following ballot position for
> draft-ietf-appsawg-uri-scheme-reg-05: No Objection
>=20
> When responding, please keep the subject line intact and reply to all ema=
il
> addresses included in the To and CC lines. (Feel free to cut this introdu=
ctory
> paragraph, however.)
>=20
>=20
> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>=20
>=20
> The document, along with other ballot positions, can be found here:
> http://datatracker.ietf.org/doc/draft-ietf-appsawg-uri-scheme-reg/
>=20
>=20
>=20
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>=20
>=20
> I put what I think it my most important comment first and hope to see a
> response to that. (I don't think it'd be correct for it to be a DISCUSS, =
but it's
> close.)
>=20
> - 3.7, probably too late in the day to ask for it, but if there are priva=
cy
> considerations those would also be good to note - and there will be for s=
ome
> of the application-specific schemes, that e.g. have personally identifyin=
g
> information in the scheme specific part. I'd suggest that renaming 3.7 to
> "security and privacy considerations" would be good and saying e.g. that
> where the scheme specific part is likely to be privacy sensitive, then th=
at
> ought be documented and ways of minimising privacy-unfriendliness ought b=
e
> documented.

As current editor, I have no objection to that (and I think it's still in l=
ine with
the intent of the current text).  Personally I consider privacy considerati=
ons=20
to just be a subtype of "security considerations" (i.e. already implied)
but I agree it's useful to call out to make sure people don't forget.

> - 3.2, all except the last para: I personally think the SHOULDs here are =
bogus.
> Why does it matter at all, really?  In any case, even if you maintain it =
matters,
> I'd suggest adding a bit saying that even minor deployment is a reasonabl=
e
> justification for going against the SHOULDs. If that's not likely to garn=
er
> immediate consensus, as I suspect, then I'll not insist - we can drop the=
 topic
> and leave it to folks registering new schemes to continue to battle the U=
RI
> police:-(

It matters because people may not get the behavior they think they get.
The third paragraph at least now explains this more clearly.   The SHOULDs
apply to 'permanent' registrations, especially IETF Standards-Track documen=
ts.
So I think the "URI police" will (or ought to) be looking for IETF docs tha=
t don't follow the
SHOULDs and help authors/WGs just like there's MIB doctors, i18n experts,
security reviewers, etc.

> - 3.2, last para: I'd suggest moving this quite reasonable constraint awa=
y from
> the rest of this section.

I don't follow what you're suggesting.  The last paragraph is still about
syntactic compatibility.

> - 3.6, 2nd para: I don't think you've quite said what you mean here. "As
> restrictive as possible" could favour "all octets are U+00A2" - that is v=
ery
> restrictive, but would be problematic for many parsers I guess. (The U+00=
A2
> value has no specific significance.) I think what you meant to say was th=
at the
> scheme specification SHOULD be as close as possible to (or deviate as lit=
tle as
> possible from) what is allowed in 3986.

No... from my understanding (discussed in Dallas with at least one other co=
-author
since this predates my time as editor), it means as restrictive as possible=
 (i.e.,
_more_ restrictive than "anything allowed in 3986").

Also keep in mind the saying usually attributed to Einstein,=20
"Everything Should Be Made as Simple as Possible, But Not Simpler".

>=20
> - 3.8: (very nitty nit:-) com.example.info isn't a good choice as both co=
m and
> info are gTLDs which may confuse some reader.
> I'd suggest com.example.mything or similar.

Good point about .info, though pretty much anything reasonable we pick woul=
d be
a legal gtld too so I think this is unavoidable.   (I could go register ".m=
ything" if
I had the money...)   That said, I have no objection to changing to use "my=
thing".

> - 3.8: I'm not sure, but are you really saying here that the these scheme=
, after
> you take away the rightmost component, ought be in the public suffix list=
? If
> so, that might actually be good guidance as com.example.a.b.c.d is much
> more likely to suffer bitrot over time I'd say. (Compared to com.example.=
abcd
> I mean.)

There is no intent to introduce any dependency on a "public suffix list".
The point is to recommend using a DNS domain name that is allocated to you.

> - 7.3, 1st para: it'd have been nice if you could have avoided IESG actio=
n being
> required for some details (e.g.  a change of contact address from
> a@example.com to b@example.com), but I guess that might be too tricky to
> get right in text, so ok.

We already require less IESG actions than RFC 4395 did.
But yes it's tricky to get any better than the current text.

-Dave

> - I agree with Ben's comment wrt loads of SHOULDs
>=20
>=20
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss


From nobody Tue Apr  7 19:11:32 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9252A1B2B4B; Tue,  7 Apr 2015 19:11:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oa8JDbB6l_uV; Tue,  7 Apr 2015 19:11:24 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C2711B2B01; Tue,  7 Apr 2015 19:11:24 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C2008BED6; Wed,  8 Apr 2015 03:11:22 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v-iBWz5hefhs; Wed,  8 Apr 2015 03:11:20 +0100 (IST)
Received: from [10.87.48.73] (unknown [86.46.18.59]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B3A7EBE59; Wed,  8 Apr 2015 03:11:20 +0100 (IST)
Message-ID: <55248E48.4000208@cs.tcd.ie>
Date: Wed, 08 Apr 2015 03:11:20 +0100
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Dave Thaler , The IESG 
References: <20150407222425.30169.23524.idtracker@ietfa.amsl.com> 
In-Reply-To: 
OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: "appsawg-chairs@ietf.org" , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Stephen Farrell's No Objection on draft-ietf-appsawg-uri-scheme-reg-05: (with COMMENT)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 08 Apr 2015 02:11:28 -0000

Hi Dave,

On 08/04/15 02:56, Dave Thaler wrote:
>> -----Original Message-----
>> From: apps-discuss [mailto:apps-discuss-bounces@ietf.org] On Behalf Of
>> Stephen Farrell
>> Sent: Tuesday, April 7, 2015 3:24 PM
>> To: The IESG
>> Cc: apps-discuss@ietf.org; appsawg-chairs@ietf.org
>> Subject: [apps-discuss] Stephen Farrell's No Objection on draft-ietf-appsawg-
>> uri-scheme-reg-05: (with COMMENT)
>>
>> Stephen Farrell has entered the following ballot position for
>> draft-ietf-appsawg-uri-scheme-reg-05: No Objection
>>
>> When responding, please keep the subject line intact and reply to all email
>> addresses included in the To and CC lines. (Feel free to cut this introductory
>> paragraph, however.)
>>
>>
>> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> http://datatracker.ietf.org/doc/draft-ietf-appsawg-uri-scheme-reg/
>>
>>
>>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>>
>> I put what I think it my most important comment first and hope to see a
>> response to that. (I don't think it'd be correct for it to be a DISCUSS, but it's
>> close.)
>>
>> - 3.7, probably too late in the day to ask for it, but if there are privacy
>> considerations those would also be good to note - and there will be for some
>> of the application-specific schemes, that e.g. have personally identifying
>> information in the scheme specific part. I'd suggest that renaming 3.7 to
>> "security and privacy considerations" would be good and saying e.g. that
>> where the scheme specific part is likely to be privacy sensitive, then that
>> ought be documented and ways of minimising privacy-unfriendliness ought be
>> documented.
> 
> As current editor, I have no objection to that (and I think it's still in line with
> the intent of the current text).  Personally I consider privacy considerations 
> to just be a subtype of "security considerations" (i.e. already implied)
> but I agree it's useful to call out to make sure people don't forget.

If there's agreement with adding a bit of text like that, I think
that'd be very good. I suspect a lot of the application-specific
schemes could involve privacy sensitive information in the scheme
specific part and such text might help those defining schemes, or
implementing, to do better. I'm happy to try help craft text if
that's useful.

>> - 3.2, all except the last para: I personally think the SHOULDs here are bogus.
>> Why does it matter at all, really?  In any case, even if you maintain it matters,
>> I'd suggest adding a bit saying that even minor deployment is a reasonable
>> justification for going against the SHOULDs. If that's not likely to garner
>> immediate consensus, as I suspect, then I'll not insist - we can drop the topic
>> and leave it to folks registering new schemes to continue to battle the URI
>> police:-(
> 
> It matters because people may not get the behavior they think they get.

Right, that's what I've never understood (or perhaps accepted;-). But I
do accept that other sensible folks consider it important, while at the
same time thinking: nah - that's irrelevant nonsense - a parser won't be
either helped or hindered by any of these SHOULDs. Anyway, I'm fine
with letting this go.

> The third paragraph at least now explains this more clearly.   The SHOULDs
> apply to 'permanent' registrations, especially IETF Standards-Track documents.
> So I think the "URI police" will (or ought to) be looking for IETF docs that don't follow the
> SHOULDs and help authors/WGs just like there's MIB doctors, i18n experts,
> security reviewers, etc.
> 
>> - 3.2, last para: I'd suggest moving this quite reasonable constraint away from
>> the rest of this section.
> 
> I don't follow what you're suggesting.  The last paragraph is still about
> syntactic compatibility.

Ah, 'twas just that I think the last para is sensible but those
preceding it in 3.2 are not. Ignore me again:-)

> 
>> - 3.6, 2nd para: I don't think you've quite said what you mean here. "As
>> restrictive as possible" could favour "all octets are U+00A2" - that is very
>> restrictive, but would be problematic for many parsers I guess. (The U+00A2
>> value has no specific significance.) I think what you meant to say was that the
>> scheme specification SHOULD be as close as possible to (or deviate as little as
>> possible from) what is allowed in 3986.
> 
> No... from my understanding (discussed in Dallas with at least one other co-author
> since this predates my time as editor), it means as restrictive as possible (i.e.,
> _more_ restrictive than "anything allowed in 3986").
> 
> Also keep in mind the saying usually attributed to Einstein, 
> "Everything Should Be Made as Simple as Possible, But Not Simpler".

Right, but you didn't say "but no simpler" in the text. And that is an
aspect of the cliche that is frequently ignored.

>> - 3.8: (very nitty nit:-) com.example.info isn't a good choice as both com and
>> info are gTLDs which may confuse some reader.
>> I'd suggest com.example.mything or similar.
> 
> Good point about .info, though pretty much anything reasonable we pick would be
> a legal gtld too so I think this is unavoidable.   (I could go register ".mything" if
> I had the money...)   That said, I have no objection to changing to use "mything".
> 
>> - 3.8: I'm not sure, but are you really saying here that the these scheme, after
>> you take away the rightmost component, ought be in the public suffix list? If
>> so, that might actually be good guidance as com.example.a.b.c.d is much
>> more likely to suffer bitrot over time I'd say. (Compared to com.example.abcd
>> I mean.)
> 
> There is no intent to introduce any dependency on a "public suffix list".
> The point is to recommend using a DNS domain name that is allocated to you.

I'm fine if that kind of thing is considered too much detail.

> 
>> - 7.3, 1st para: it'd have been nice if you could have avoided IESG action being
>> required for some details (e.g.  a change of contact address from
>> a@example.com to b@example.com), but I guess that might be too tricky to
>> get right in text, so ok.
> 
> We already require less IESG actions than RFC 4395 did.
> But yes it's tricky to get any better than the current text.

Yep.

Thanks,
S.


> 
> -Dave
> 
>> - I agree with Ben's comment wrt loads of SHOULDs
>>
>>
>> _______________________________________________
>> apps-discuss mailing list
>> apps-discuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/apps-discuss
> 


From nobody Tue Apr  7 20:22:30 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 525221A1B78; Tue,  7 Apr 2015 20:22:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MisfM4Itfj78; Tue,  7 Apr 2015 20:22:24 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C797C1B2A62; Tue,  7 Apr 2015 20:22:24 -0700 (PDT)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t383MDh7009597 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Apr 2015 22:22:24 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23]
From: "Ben Campbell" 
To: "Dave Thaler" 
Date: Tue, 07 Apr 2015 22:22:13 -0500
Message-ID: <5A5694CB-1397-4EE1-9C45-D88AF3FE1712@nostrum.com>
In-Reply-To: 
References: <20150406230346.17020.71285.idtracker@ietfa.amsl.com> 
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
X-Mailer: MailMate (1.9.1r5084)
Archived-At: 
Cc: "appsawg-chairs@ietf.org" , The IESG , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Ben Campbell's No Objection on draft-ietf-appsawg-uri-scheme-reg-05: (with COMMENT)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 08 Apr 2015 03:22:26 -0000

On 7 Apr 2015, at 20:38, Dave Thaler wrote:

>> -----Original Message-----
>> From: apps-discuss [mailto:apps-discuss-bounces@ietf.org] On Behalf 
>> Of Ben
>> Campbell
>> Sent: Monday, April 6, 2015 4:04 PM
>> To: The IESG
>> Cc: apps-discuss@ietf.org; appsawg-chairs@ietf.org
>> Subject: [apps-discuss] Ben Campbell's No Objection on 
>> draft-ietf-appsawg-
>> uri-scheme-reg-05: (with COMMENT)
>>
>> Ben Campbell has entered the following ballot position for
>> draft-ietf-appsawg-uri-scheme-reg-05: No Objection
>>
>> When responding, please keep the subject line intact and reply to all 
>> email
>> addresses included in the To and CC lines. (Feel free to cut this 
>> introductory
>> paragraph, however.)
>>
>>
>> Please refer to 
>> http://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> http://datatracker.ietf.org/doc/draft-ietf-appsawg-uri-scheme-reg/
>>
>>
>>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>> I am curious how the expert review required in the document interacts 
>> with
>> bona-fide standards actions. There's already an ongoing discussion on 
>> that,
>> and Barry has noted it in his on comments, so I will leave this as a 
>> comment.
>> In particular I wonder if the "On receipt of a registration request" 
>> section of
>> 7.2 should be different if the request was part of an IETF/IESG 
>> reviewed and
>> approved action in the first place.
>
> RFC 4395 made no distinction and the WG has not discussed making any
> such distinction.  So unless it's a blocker (which does not seem to be 
> the case
> in your comment at least), the current answer is "no difference".

No, neither this or the next are blockers. (Thus the comment, not 
discuss.)

>
>> There are a lot of SHOULDs in this document. I wonder how an expert
>> reviewer is supposed to interpret deviations from SHOULD level 
>> requirements.
>> This is especially true in statements like "... SHOULD include clear 
>> security
>> considerations or explain [why not]". The expert's life might be 
>> easier if there
>> was some text encouraging that deviations from SHOULDs be accompanied 
>> by
>> an explanation.
>
> FYI, in this particular case, the meaning isn't different from RFC 
> 4395 which was even
> less precise, so the expert in question has already been dealing with 
> this and
> anything we say won't make his life easier unless we change the actual 
> meaning
> (which is not the intent).
>
> Dave


From nobody Wed Apr  8 00:09:49 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 674C71A008F for ; Wed,  8 Apr 2015 00:09:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G3CNxu7Cr7_O for ; Wed,  8 Apr 2015 00:09:44 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0071.outbound.protection.outlook.com [65.55.169.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CB6F1A014D for ; Wed,  8 Apr 2015 00:09:43 -0700 (PDT)
Received: from DM2PR02MB1322.namprd02.prod.outlook.com (25.161.142.21) by DM2PR02MB1324.namprd02.prod.outlook.com (25.161.142.23) with Microsoft SMTP Server (TLS) id 15.1.118.21; Wed, 8 Apr 2015 07:09:42 +0000
Received: from DM2PR02MB1322.namprd02.prod.outlook.com ([25.161.142.21]) by DM2PR02MB1322.namprd02.prod.outlook.com ([25.161.142.21]) with mapi id 15.01.0118.029; Wed, 8 Apr 2015 07:09:42 +0000
From: Larry Masinter 
To: t.petch , Salvatore Loreto , IETF Apps Discuss 
Thread-Topic: [apps-discuss] Working Group Last Call ondraft-ietf-appsawg-multipart-form-data
Thread-Index: AQHP/aksVswX27+VxU29eG0NYufBEJ1DJUoA
Date: Wed, 8 Apr 2015 07:09:42 +0000
Message-ID: 
References:      <3D8DFE75-8015-4CA2-BF2B-8B62C9E450B5@ericsson.com> <045a01cffda8$b3f45120$4001a8c0@gateway.2wire.net>
In-Reply-To: <045a01cffda8$b3f45120$4001a8c0@gateway.2wire.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/15.8.0.150303
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [50.184.24.49]
authentication-results: btconnect.com; dkim=none (message not signed) header.d=none;
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR02MB1324;
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10009020)(6009001)(377454003)(479174004)(24454002)(51704005)(66066001)(46102003)(1720100001)(2900100001)(2950100001)(87936001)(2656002)(92566002)(36756003)(15975445007)(102836002)(54356999)(122556002)(50986999)(40100003)(76176999)(107886001)(82746002)(83506001)(86362001)(33656002)(230783001)(62966003)(83716003)(99286002)(19580405001)(77156002)(93886004)(19580395003)(106116001)(7059030)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR02MB1324; H:DM2PR02MB1322.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:DM2PR02MB1324; BCL:0; PCL:0; RULEID:;  SRVR:DM2PR02MB1324; 
x-forefront-prvs: 0540846A1D
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: adobe.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2015 07:09:42.2085 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR02MB1324
Archived-At: 
Subject: Re: [apps-discuss] Working Group Last Call ondraft-ietf-appsawg-multipart-form-data
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 08 Apr 2015 07:09:47 -0000

VGhpcyB3YXMgYSB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBjb21tZW50IHRoYXQgSSB0aGluayBJ
IG92ZXJsb29rZWQuDQoNCg0KDQpPbiAxMS8xMS8xNCwgMzoxMSBBTSwgInQucGV0Y2giIDxpZXRm
Y0BidGNvbm5lY3QuY29tPiB3cm90ZToNCg0KPkkgbm90ZSB0aGF0IHRoaXMgSS1EIHNwZWNpZmll
cw0KPg0KPiAgIEVuY29kaW5nIGNvbnNpZGVyYXRpb25zOiAgQ29tbW9uIHVzZSBpcyBCSU5BUlku
DQo+DQo+TG9va2luZyBhdA0KPmh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvbWVkaWEt
dHlwZXMvbXVsdGlwYXJ0L3JlbGF0ZWQNCj5JIHNlZQ0KPg0KPkVuY29kaW5nIGNvbnNpZGVyYXRp
b25zOiAgIE11bHRpcGFydCBjb250ZW50LXR5cGVzIGNhbm5vdCBoYXZlDQo+ICAgICAgICAgICAg
ICAgICAgICAgICAgICAgZW5jb2RpbmdzLg0KPg0KPkkgaGF2ZSBsb29rZWQgYXQgbW9yZSByZWNl
bnQgUkZDLCBzdWNoIGFzIFJGQzY4MzgsIGFuZCBjYW4gc2VlIG5vdGhpbmcNCj50byBnYWluc2F5
IHRoaXMuICBEb2VzIHRoaXMgcmVzdHJpY3Rpb24gc3RpbGwgYXBwbHk/DQoNCkkgZG9u4oCZdCBr
bm93IHdoZXRoZXIgTXVsdGlwYXJ0IGNvbnRlbnQtdHlwZXMgY2FuIGhhdmUgZW5jb2RpbmdzLCBv
ciBpZiBub3QsIHdoeSBub3QuDQpCdXQgRW5jb2RpbmcgY29uc2lkZXJhdGlvbnMgYXBwbHkgZXZl
biBpZiB0aGV5IGNhbuKAmXQgYmUgZW5jb2RlZCwgdG8gdGVsbCB5b3UgdGhhdCB0cmFuc3BvcnQg
aXMgaW1wb3NzaWJsZSBpZiB5b3UgaGF2ZSBhIDctYml0IGNoYW5uZWwgYW5kIHlvdSB3YW50IHRv
IHNlbmQgY29udGVudCB0aGF0IG5lZWRzIGVpdGhlciBhbiA4LWJpdCBjaGFubmVsIChCSU5BUlkp
IG9yIGFuIGVuY29kaW5nLg0KDQpNYXliZSB0aGUgdGVtcGxhdGUgbmFtZSDigJhFbmNvZGluZyBj
b25zaWRlcmF0aW9uc+KAmSBpcyB0b28gZWFzeSB0byB0YWtlIGxpdGVyYWxseT8NCg0KTGFycnkN
Cg0K


From nobody Wed Apr  8 00:27:54 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEEA01A037D; Wed,  8 Apr 2015 00:27:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kPNUHjF_AO2x; Wed,  8 Apr 2015 00:27:49 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FC4A1A8952; Wed,  8 Apr 2015 00:27:48 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 5.13.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150408072748.15812.4945.idtracker@ietfa.amsl.com>
Date: Wed, 08 Apr 2015 00:27:48 -0700
Archived-At: 
Cc: apps-discuss@ietf.org
Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-multipart-form-data-09.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Apr 2015 07:27:51 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Applications Area Working Group Working Group of the IETF.

        Title           : Returning Values from Forms: multipart/form-data
        Author          : Larry Masinter
	Filename        : draft-ietf-appsawg-multipart-form-data-09.txt
	Pages           : 13
	Date            : 2015-04-08

Abstract:
   This specification (re)defines the multipart/form-data Internet Media
   Type, which can be used by a wide variety of applications and
   transported by a wide variety of protocols as a way of returning a
   set of values as the result of a user filling out a form.  It
   obsoletes RFC 2388.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-appsawg-multipart-form-data/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-appsawg-multipart-form-data-09

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-multipart-form-data-09


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Wed Apr  8 00:27:55 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8E9F1A037D; Wed,  8 Apr 2015 00:27:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rs4qUtTr5e4s; Wed,  8 Apr 2015 00:27:50 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ACB0C1A8AE5; Wed,  8 Apr 2015 00:27:48 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: , ,  ,  , , , 
X-Test-IDTracker: no
X-IETF-IDTracker: 5.13.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150408072748.15812.85239.idtracker@ietfa.amsl.com>
Date: Wed, 08 Apr 2015 00:27:48 -0700
Archived-At: 
Subject: [apps-discuss] New Version Notification - draft-ietf-appsawg-multipart-form-data-09.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Apr 2015 07:27:52 -0000

A new version (-09) has been submitted for draft-ietf-appsawg-multipart-form-data:
http://www.ietf.org/internet-drafts/draft-ietf-appsawg-multipart-form-data-09.txt


The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-appsawg-multipart-form-data/

Diff from previous version:
http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-multipart-form-data-09

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

IETF Secretariat.


From nobody Wed Apr  8 05:40:34 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD6BE1A1A9E; Wed,  8 Apr 2015 05:40:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qz4YAu_nu8Na; Wed,  8 Apr 2015 05:40:31 -0700 (PDT)
Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B68901A1A9A; Wed,  8 Apr 2015 05:40:31 -0700 (PDT)
Received: by ignm3 with SMTP id m3so28379648ign.0; Wed, 08 Apr 2015 05:40:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=w91SbnEXc9HwOgZxBt85J2s9Cu6m9hWzaylvfkX9v/s=; b=cCBPM8OMXDyWQPI65sSiwPxvfjxcCaW3vZI8WIxdZP+V80iwxJpIwExWk8Mf7MtcCE lUlnd4yhHcVJXA1YYZWVVM5WxL7CY1FTscvVEGmG3UoFkiDnTKspPAP/rpw5/Bml18OD 7VM4vu5xzkQfVoNnx4IW4ugHac3ezZ3H6cjTQDtzL2DMS0QVLF4SGLs0QEnK5LJAMSqm Ylin2YBu1H9SV0QCq7U4w/m7odUdXbM6CAX6OLxC1SgZy5cGae3GPCkKv7gna+xI100F tDbthhoj5XRI+XzB/oHU7mngNvjKUcbcQias8tuSDa2zw1BaHU4mpJxHuIi0EBGdFncw Zcug==
MIME-Version: 1.0
X-Received: by 10.107.3.17 with SMTP id 17mr37031096iod.60.1428496831227; Wed, 08 Apr 2015 05:40:31 -0700 (PDT)
Sender: barryleiba@gmail.com
Received: by 10.107.7.130 with HTTP; Wed, 8 Apr 2015 05:40:31 -0700 (PDT)
In-Reply-To: 
References: <20150406230346.17020.71285.idtracker@ietfa.amsl.com> 
Date: Wed, 8 Apr 2015 08:40:31 -0400
X-Google-Sender-Auth: b5Vvi1vMs7deEompHByhWu0T5GA
Message-ID: 
From: Barry Leiba 
To: Dave Thaler 
Content-Type: text/plain; charset=ISO-8859-1
Archived-At: 
Cc: Ben Campbell , The IESG , "apps-discuss@ietf.org" , "appsawg-chairs@ietf.org" 
Subject: Re: [apps-discuss] Ben Campbell's No Objection on draft-ietf-appsawg-uri-scheme-reg-05: (with COMMENT)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 08 Apr 2015 12:40:33 -0000

>> I am curious how the expert review required in the document interacts with
>> bona-fide standards actions. There's already an ongoing discussion on that,
>> and Barry has noted it in his on comments, so I will leave this as a comment.
>> In particular I wonder if the "On receipt of a registration request" section of
>> 7.2 should be different if the request was part of an IETF/IESG reviewed and
>> approved action in the first place.
>
> RFC 4395 made no distinction and the WG has not discussed making any
> such distinction.  So unless it's a blocker (which does not seem to be the case
> in your comment at least), the current answer is "no difference".

Well, Ben's not blocking it, but my comment (in my Yes ballot) does
say that I'm not going to send the document through until the "how
does this relate to what working groups decide" issue is done being
hashed out.

The fact is that we have a very good DE now, in Graham Klyne, who
understand the relationship of his comments to working group
consensus, and handles things appropriately (and has said so).

But Graham will retire at some point, and perhaps while we're still
using URIs and minting new schemes.  Perhaps the next DE appointed
will have a different view and will hold out against working group
decisions rather more strongly.  The IESG then, in that future time of
Morlocks and Eloi, could deal with it... but it might be good to have
a paragraph of advice to the DE that says what the DE is expected to
do when reviewing requests that come from Standards Track IETF work
that has community consensus.  Basically, Graham could write those
sentences, I imagine, based on what he does now.

Barry


From nobody Wed Apr  8 06:30:19 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 794A61A82E2; Wed,  8 Apr 2015 06:30:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2WAnl1jMmZY4; Wed,  8 Apr 2015 06:30:17 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E26361A710D; Wed,  8 Apr 2015 06:30:14 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Ben Campbell" 
To: "The IESG" 
X-Test-IDTracker: no
X-IETF-IDTracker: 5.13.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150408133014.13540.26867.idtracker@ietfa.amsl.com>
Date: Wed, 08 Apr 2015 06:30:14 -0700
Archived-At: 
Cc: draft-ietf-appsawg-multipart-form-data@ietf.org, apps-discuss@ietf.org, appsawg-chairs@ietf.org, draft-ietf-appsawg-multipart-form-data.ad@ietf.org
Subject: [apps-discuss] Ben Campbell's No Objection on draft-ietf-appsawg-multipart-form-data-09: (with COMMENT)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Apr 2015 13:30:18 -0000

Ben Campbell has entered the following ballot position for
draft-ietf-appsawg-multipart-form-data-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-appsawg-multipart-form-data/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for adding the form-data parameter to the registration update.

I concur with Kathleen's comment to move the last paragraph in the
security considerations to the front.



From nobody Wed Apr  8 06:41:32 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 579E31A8734; Wed,  8 Apr 2015 06:41:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pXdMa50tH-Qp; Wed,  8 Apr 2015 06:41:29 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 059471A8718; Wed,  8 Apr 2015 06:41:29 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Stephen Farrell" 
To: "The IESG" 
X-Test-IDTracker: no
X-IETF-IDTracker: 5.13.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150408134129.7310.7115.idtracker@ietfa.amsl.com>
Date: Wed, 08 Apr 2015 06:41:29 -0700
Archived-At: 
Cc: draft-ietf-appsawg-multipart-form-data@ietf.org, apps-discuss@ietf.org, appsawg-chairs@ietf.org, draft-ietf-appsawg-multipart-form-data.ad@ietf.org
Subject: [apps-discuss] Stephen Farrell's No Objection on draft-ietf-appsawg-multipart-form-data-09: (with COMMENT)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Apr 2015 13:41:30 -0000

Stephen Farrell has entered the following ballot position for
draft-ietf-appsawg-multipart-form-data-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-appsawg-multipart-form-data/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


- abstract: the "(re)defines" is a bit confusing, I'd say just
stick with "defines"

- 4.3, typo "may seems to be present"



From nobody Wed Apr  8 07:29:16 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB4991B3139 for ; Wed,  8 Apr 2015 07:29:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.298
X-Spam-Level: 
X-Spam-Status: No, score=0.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MANGLED_TOOL=2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Vt3mV07JeA8 for ; Wed,  8 Apr 2015 07:29:13 -0700 (PDT)
Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2905E1B312D for ; Wed,  8 Apr 2015 07:29:13 -0700 (PDT)
Received: from kitterma-e6430.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 2AFF3C4001A for ; Wed,  8 Apr 2015 09:29:12 -0500 (CDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1428503352; bh=tcA/MtHRTFLAinuKSoC4sOaYh0D09aEFFP4q/3eSNj4=; h=From:To:Subject:Date:In-Reply-To:References:From; b=fQSh38aKlJxaznbgjOBF3yMD3KRR00/CMJais9FNcI40p9k45LTyvJAaAfXS5v3ok b6MeEMiRV08PGKOMCV4L6EiLZn7s3CKdiEUN4nEkX+Qj0qRpGy8L2JTwT4/PndfTF/ +Rb0eCUS84xHVbHtQoT9Drmt0lfc6RxywInDq2HM=
From: Scott Kitterman 
To: apps-discuss@ietf.org
Date: Wed, 08 Apr 2015 10:29:11 -0400
Message-ID: <2383989.tErOfD7dMh@kitterma-e6430>
User-Agent: KMail/4.13.3 (Linux/3.13.0-48-generic; KDE/4.13.3; x86_64; ; )
In-Reply-To: <5518019A.7080508@isode.com>
References: <5518019A.7080508@isode.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: 
Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-rfc7001bis-05
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 08 Apr 2015 14:29:15 -0000

On Sunday, March 29, 2015 02:43:54 PM Alexey Melnikov wrote:
> This message is starting 3 weeks (*) Working Group Last Calls on
> draft-ietf-appsawg-rfc7001bis-05 (Message Header Field for Indicating
> Message Authentication Status). The WGLC ends on
> April 19th.
> 
> Please send your comments on the document in a reply to this message or
> directly to me. If you read the document and you think the document is
> ready for publication, saying so would also be helpful.

I've reviewed the document and believe it's essentially ready for publication.  
I think there is a bit of editorial adjustment needed in the prose about 
different a-r methods.

Here's my list of A-R related RFCs:

RFC 5451/7001 Message Header Field for Indicating Message Authentication 
Status
RFC 5617 DKIM/ADSP
RFC 6008 DKIM signature identification (header.b)
RFC 6212 Vouch By Reference (VBR)
RFC 6577 Sender Policy Framework (SPF)
RFC 7281 Authentication-Results Registration for S/MIME
RFC 7293 The Require-Recipient-Valid-Since Header Field
RFC7489 DMARC

Here's what the draft currently says about different methods:

  At the time of publication of this document, the following are
  published, domain-level email authentication methods in common use:

  o  Author Domain Signing Practices ([ADSP])
  o  SMTP Service Extension for Authentication ([AUTH])
  o  DomainKeys Identified Mail Signatures ([DKIM])
  o  Sender Policy Framework ([SPF])
  o  Vouch By Reference ([VBR])
  o  reverse IP address name validation ("iprev", defined in Section 3)

   In addition, the following are non-standard methods recognized by
   this specification that are no longer common:

  o  DomainKeys ([DOMAINKEYS]) (Historic)
  o  Sender ID ([SENDERID]) (Experimental)

I think the list misses DMARC, S/MIME and RRVS.  I also question the 
description of ADSP and VBR as "common".  Additionally, ADSP is historic.

Instead of getting into a bike shed discussion about what's common and how can 
we tell, what about something like this:

  At the time of publication of this document, the following are
  published, authentication methods:

  o  Author Domain Signing Practices ([ADSP]) (Historic)
  o  Domain-based Message Authentication,  Reporting and Conformance ([DMARC])
  o  DomainKeys ([DOMAINKEYS]) (Historic)
  o  DomainKeys Identified Mail Signatures ([DKIM])
  o  reverse IP address name validation ("iprev", defined in Section 3)
  o  Require-Recipient-Valid-Since Header Field and SMTP Service Extension
       ([RRVS])
  o  SMTP Service Extension for Authentication ([AUTH])
  o  Sender ID ([SENDERID]) (Experimental)
  o  Sender Policy Framework ([SPF])
  o  S/MIME Signature Verification [SMIME-REG]
  o  Vouch By Reference ([VBR])

None of these are marked deprecated in the registry:

http://www.iana.org/assignments/email-auth/email-auth.xhtml

As a result, I don't think we should treat them differently in the text beyond 
noting the status of the relevant RFC.

Scott K


From nobody Wed Apr  8 07:36:36 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44D851B3149; Wed,  8 Apr 2015 07:36:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x_jEBEzG7eMZ; Wed,  8 Apr 2015 07:36:32 -0700 (PDT)
Received: from relay16.mail.ox.ac.uk (relay16.mail.ox.ac.uk [163.1.2.166]) by ietfa.amsl.com (Postfix) with ESMTP id 0F18C1B3157; Wed,  8 Apr 2015 07:36:24 -0700 (PDT)
Received: from smtp6.mail.ox.ac.uk ([163.1.2.206]) by relay16.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1Yfr5Z-0002Qe-sa; Wed, 08 Apr 2015 15:36:21 +0100
Received: from oerc-dynamic-222.oerc.ox.ac.uk ([129.67.194.222]) by smtp6.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Yfr5Z-0003eO-Lp; Wed, 08 Apr 2015 15:36:21 +0100
Message-ID: <55253CF9.7050206@ninebynine.org>
Date: Wed, 08 Apr 2015 15:36:41 +0100
From: Graham Klyne 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Barry Leiba , Dave Thaler 
References: <20150406230346.17020.71285.idtracker@ietfa.amsl.com>  
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Oxford-Username: zool0635
Archived-At: 
Cc: Ben Campbell , The IESG , "apps-discuss@ietf.org" , "appsawg-chairs@ietf.org" 
Subject: Re: [apps-discuss] Ben Campbell's No Objection on draft-ietf-appsawg-uri-scheme-reg-05: (with COMMENT)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 08 Apr 2015 14:36:34 -0000

FWIW, I did make a suggestion in a message of 02/04/2015 10:30 ...

For ease of reference, here is what I said:

[[
 From memory, the revised procedure (and maybe the current) already have it that 
a DE decision can be overruled by the IESG, who (I would judge) are ultimately 
the guardians of the IETF consensus process.  So I think the DE cannot override 
the consensus process.

But I would be happy for this to be clarified.  For example, in section 7.1 
(http://tools.ietf.org/html/draft-ietf-appsawg-uri-scheme-reg-05#section-7.1), 
maybe add something like this:

"The role of the designated expert in the procedure for permanent registrations 
described here is to ensure that normal IETF open review process has been 
properly followed, and to raise possible concerns about wider implications of 
proposals for the use and deployment of URIs.  Nothing in the procedure empowers 
the Designated Expert to override properly arrived-at IETF or working group 
consensus."
]]

#g
--


On 08/04/2015 13:40, Barry Leiba wrote:
>>> I am curious how the expert review required in the document interacts with
>>> bona-fide standards actions. There's already an ongoing discussion on that,
>>> and Barry has noted it in his on comments, so I will leave this as a comment.
>>> In particular I wonder if the "On receipt of a registration request" section of
>>> 7.2 should be different if the request was part of an IETF/IESG reviewed and
>>> approved action in the first place.
>>
>> RFC 4395 made no distinction and the WG has not discussed making any
>> such distinction.  So unless it's a blocker (which does not seem to be the case
>> in your comment at least), the current answer is "no difference".
>
> Well, Ben's not blocking it, but my comment (in my Yes ballot) does
> say that I'm not going to send the document through until the "how
> does this relate to what working groups decide" issue is done being
> hashed out.
>
> The fact is that we have a very good DE now, in Graham Klyne, who
> understand the relationship of his comments to working group
> consensus, and handles things appropriately (and has said so).
>
> But Graham will retire at some point, and perhaps while we're still
> using URIs and minting new schemes.  Perhaps the next DE appointed
> will have a different view and will hold out against working group
> decisions rather more strongly.  The IESG then, in that future time of
> Morlocks and Eloi, could deal with it... but it might be good to have
> a paragraph of advice to the DE that says what the DE is expected to
> do when reviewing requests that come from Standards Track IETF work
> that has community consensus.  Basically, Graham could write those
> sentences, I imagine, based on what he does now.
>
> Barry
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>


From nobody Wed Apr  8 09:20:20 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBC791B33C2 for ; Wed,  8 Apr 2015 09:20:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.399
X-Spam-Level: 
X-Spam-Status: No, score=0.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_TOOL=2.3, SPF_HELO_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YrlisbPFd8Xy for ; Wed,  8 Apr 2015 09:20:17 -0700 (PDT)
Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0702.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::702]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C8441B33B7 for ; Wed,  8 Apr 2015 09:20:17 -0700 (PDT)
Received: from pc6 (81.151.162.168) by DB3PR07MB057.eurprd07.prod.outlook.com (10.242.137.144) with Microsoft SMTP Server (TLS) id 15.1.130.23; Wed, 8 Apr 2015 16:08:16 +0000
Message-ID: <039901d07216$10243640$4001a8c0@gateway.2wire.net>
From: t.petch 
To: Scott Kitterman , 
References: <5518019A.7080508@isode.com> <2383989.tErOfD7dMh@kitterma-e6430>
Date: Wed, 8 Apr 2015 17:06:57 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [81.151.162.168]
X-ClientProxiedBy: DB5PR02CA0038.eurprd02.prod.outlook.com (25.161.237.48) To DB3PR07MB057.eurprd07.prod.outlook.com (10.242.137.144)
Authentication-Results: kitterman.com; dkim=none (message not signed) header.d=none;
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB3PR07MB057;
X-Forefront-Antispam-Report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(24454002)(51704005)(13464003)(377454003)(77156002)(62966003)(87976001)(15975445007)(77096005)(1556002)(42186005)(33646002)(107886001)(230783001)(62236002)(116806002)(122386002)(61296003)(44716002)(50986999)(47776003)(46102003)(76176999)(81686999)(81816999)(40100003)(14496001)(66066001)(19580405001)(84392001)(92566002)(86362001)(19580395003)(1456003)(50226001)(23756003)(50466002)(44736004); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR07MB057; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; 
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:DB3PR07MB057; BCL:0; PCL:0; RULEID:; SRVR:DB3PR07MB057; 
X-Forefront-PRVS: 0540846A1D
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Apr 2015 16:08:16.1109 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR07MB057
Archived-At: 
Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-rfc7001bis-05
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 08 Apr 2015 16:20:20 -0000

----- Original Message -----
From: "Scott Kitterman" 
To: 
Sent: Wednesday, April 08, 2015 3:29 PM
> On Sunday, March 29, 2015 02:43:54 PM Alexey Melnikov wrote:
> > This message is starting 3 weeks (*) Working Group Last Calls on
> > draft-ietf-appsawg-rfc7001bis-05 (Message Header Field for
Indicating
> > Message Authentication Status). The WGLC ends on
> > April 19th.
> >
>
> I've reviewed the document and believe it's essentially ready for
publication.
> I think there is a bit of editorial adjustment needed in the prose
about
> different a-r methods.
>
> Here's my list of A-R related RFCs:
>
> RFC 5451/7001 Message Header Field for Indicating Message
Authentication
> Status
> RFC 5617 DKIM/ADSP
> RFC 6008 DKIM signature identification (header.b)
> RFC 6212 Vouch By Reference (VBR)
> RFC 6577 Sender Policy Framework (SPF)
> RFC 7281 Authentication-Results Registration for S/MIME
> RFC 7293 The Require-Recipient-Valid-Since Header Field
> RFC7489 DMARC
>
> Here's what the draft currently says about different methods:
>
>   At the time of publication of this document, the following are
>   published, domain-level email authentication methods in common use:
>
>   o  Author Domain Signing Practices ([ADSP])
>   o  SMTP Service Extension for Authentication ([AUTH])
>   o  DomainKeys Identified Mail Signatures ([DKIM])
>   o  Sender Policy Framework ([SPF])
>   o  Vouch By Reference ([VBR])
>   o  reverse IP address name validation ("iprev", defined in Section
3)
>
>    In addition, the following are non-standard methods recognized by
>    this specification that are no longer common:
>
>   o  DomainKeys ([DOMAINKEYS]) (Historic)
>   o  Sender ID ([SENDERID]) (Experimental)
>
> I think the list misses DMARC, S/MIME and RRVS.  I also question the
> description of ADSP and VBR as "common".  Additionally, ADSP is
historic.
>
> Instead of getting into a bike shed discussion about what's common and
how can
> we tell, what about something like this:
>
>   At the time of publication of this document, the following are
>   published, authentication methods:
>
>   o  Author Domain Signing Practices ([ADSP]) (Historic)
>   o  Domain-based Message Authentication,  Reporting and Conformance
([DMARC])
>   o  DomainKeys ([DOMAINKEYS]) (Historic)
>   o  DomainKeys Identified Mail Signatures ([DKIM])
>   o  reverse IP address name validation ("iprev", defined in Section
3)
>   o  Require-Recipient-Valid-Since Header Field and SMTP Service
Extension
>        ([RRVS])
>   o  SMTP Service Extension for Authentication ([AUTH])
>   o  Sender ID ([SENDERID]) (Experimental)
>   o  Sender Policy Framework ([SPF])
>   o  S/MIME Signature Verification [SMIME-REG]
>   o  Vouch By Reference ([VBR])
>
> None of these are marked deprecated in the registry:
>
> http://www.iana.org/assignments/email-auth/email-auth.xhtml

Scott

but if you were to look at the updated registry, as for example in the
one I have prepared by hand (but which the IETF mailing system refuses
to post - perhaps I  have upset the Privacy Police:-) then you will find
that domainkeys and DKIM-ADSP are deprecated in the registry.

Tom Petch

> As a result, I don't think we should treat them differently in the
text beyond
> noting the status of the relevant RFC.
>
> Scott K
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss


From nobody Wed Apr  8 09:40:33 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F22791B33FE; Wed,  8 Apr 2015 09:40:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pkWs7DWP00-g; Wed,  8 Apr 2015 09:40:30 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B3A51B3405; Wed,  8 Apr 2015 09:40:29 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 5.13.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150408164029.18251.55588.idtracker@ietfa.amsl.com>
Date: Wed, 08 Apr 2015 09:40:29 -0700
Archived-At: 
Cc: apps-discuss@ietf.org
Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-multipart-form-data-10.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Apr 2015 16:40:32 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Applications Area Working Group Working Group of the IETF.

        Title           : Returning Values from Forms: multipart/form-data
        Author          : Larry Masinter
	Filename        : draft-ietf-appsawg-multipart-form-data-10.txt
	Pages           : 13
	Date            : 2015-04-08

Abstract:
   This specification defines the multipart/form-data Internet Media
   Type, which can be used by a wide variety of applications and
   transported by a wide variety of protocols as a way of returning a
   set of values as the result of a user filling out a form.  It
   obsoletes RFC 2388.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-appsawg-multipart-form-data/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-appsawg-multipart-form-data-10

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-multipart-form-data-10


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Wed Apr  8 09:40:41 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2A491B3414; Wed,  8 Apr 2015 09:40:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BKD4E95rUsAn; Wed,  8 Apr 2015 09:40:32 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DDB91B340A; Wed,  8 Apr 2015 09:40:29 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: , ,  ,  , , 
X-Test-IDTracker: no
X-IETF-IDTracker: 5.13.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150408164029.18251.55563.idtracker@ietfa.amsl.com>
Date: Wed, 08 Apr 2015 09:40:29 -0700
Archived-At: 
Subject: [apps-discuss] New Version Notification - draft-ietf-appsawg-multipart-form-data-10.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Apr 2015 16:40:33 -0000

A new version (-10) has been submitted for draft-ietf-appsawg-multipart-form-data:
http://www.ietf.org/internet-drafts/draft-ietf-appsawg-multipart-form-data-10.txt


The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-appsawg-multipart-form-data/

Diff from previous version:
http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-multipart-form-data-10

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

IETF Secretariat.


From nobody Wed Apr  8 10:02:02 2015
Return-Path: 
X-Original-To: expand-draft-ietf-appsawg-uri-scheme-reg.all@virtual.ietf.org
Delivered-To: apps-discuss@ietfa.amsl.com
Received: by ietfa.amsl.com (Postfix, from userid 65534) id 2A6861ACD50; Tue,  7 Apr 2015 16:56:41 -0700 (PDT)
X-Original-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com
Delivered-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04BEB1ACD4F for ; Tue,  7 Apr 2015 16:56:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.902
X-Spam-Level: 
X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JMYDwEQ3ajMW for ; Tue,  7 Apr 2015 16:56:38 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0124.outbound.protection.outlook.com [207.46.100.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBE4F1ACD4C for ; Tue,  7 Apr 2015 16:56:38 -0700 (PDT)
Received: from BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) by BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) with Microsoft SMTP Server (TLS) id 15.1.130.12; Tue, 7 Apr 2015 23:56:37 +0000
Received: from BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) by BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) with mapi id 15.01.0130.020; Tue, 7 Apr 2015 23:56:37 +0000
From: Dave Thaler 
To: Alexey Melnikov , Barry Leiba 
Thread-Topic: FW: [apps-discuss] New Version Notification - draft-ietf-appsawg-uri-scheme-reg-05.txt
Thread-Index: AQHQailxBvO33HrLqkmFnLTAQMhclp1CRimQ
Date: Tue, 7 Apr 2015 23:56:37 +0000
Message-ID: 
References: <20150327163331.20999.30881.idtracker@ietfa.amsl.com>   <551806AD.2010409@isode.com>
In-Reply-To: <551806AD.2010409@isode.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:4898:80e0:ee43::3]
authentication-results: isode.com; dkim=none (message not signed) header.d=none;
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB412;
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(51704005)(377454003)(13464003)(24454002)(479174004)(46102003)(86362001)(2950100001)(230783001)(2900100001)(19580395003)(76176999)(92566002)(19580405001)(50986999)(2656002)(87936001)(74316001)(99286002)(93886004)(33656002)(86612001)(62966003)(15975445007)(122556002)(106116001)(54356999)(76576001)(77156002)(2420400003)(77096005)(40100003)(102836002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB412; H:BY2PR03MB412.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:BY2PR03MB412; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB412; 
x-forefront-prvs: 0539EEBD11
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.onmicrosoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Apr 2015 23:56:37.2386 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB412
Archived-At: 
X-Mailman-Approved-At: Wed, 08 Apr 2015 10:01:59 -0700
Cc: "draft-ietf-appsawg-uri-scheme-reg.all@ietf.org" 
Subject: Re: [apps-discuss] FW: New Version Notification - draft-ietf-appsawg-uri-scheme-reg-05.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 07 Apr 2015 23:56:41 -0000

> -----Original Message-----
> From: Alexey Melnikov [mailto:alexey.melnikov@isode.com]
> Sent: Sunday, March 29, 2015 7:06 AM
> To: Barry Leiba
> Cc: Dave Thaler; draft-ietf-appsawg-uri-scheme-reg.all@ietf.org
> Subject: Re: FW: [apps-discuss] New Version Notification - draft-ietf-app=
sawg-
> uri-scheme-reg-05.txt
>=20
> On 27/03/2015 19:29, Barry Leiba wrote:
> >> I will send email responses to the feedback received with what we did.
> >> I may not get those out today though. But I think the doc should be
> >> ready for the IESG telechat.
> > Thanks.  I've issued the ballot; I'll wait to change the state until I
> > hear that your co-authors & shepherd are OK with it.
> This is almost perfect :-).
>=20
> A couple of comments:
>=20
> 1) The last paragraph in Section 3.6  (Internationalization and Character
> Encoding)  now reads (the last sentence is new):
>=20
>     All percent-encoded variants are automatically included by definition
>     for any character given in an IRI production.  This means that if you
>     want to restrict the URI percent-encoded forms in some way, you must
>     restrict the Unicode forms that would lead to them.  In most cases,
>     it is advisable to define the actual characters allowed in an IRI
>     production, to allow the 'pct-encoded' definition from Section 2.1 of
>     [RFC3986] at the same places, and to add prose that limits percent-
>     escapes to those that can be created by converting valid character
>     sequences to percent-encoding via UTF-8.
>=20
>=20
> The last part of the sentence doesn't read well (and I can't understand e=
xactly
> what is it trying to do):
>=20
>     and to add prose that limits percent-
>     escapes to those that can be created by converting valid UTF-8
>     character sequences to their percent-encoding.
>=20
>=20
> Dave, is this what you intended?

Yes

> 2) Regarding my earlier disagreement about text suggested by Graham:
>=20
> 3.  Requirements for Permanent Scheme Definitions
>=20
>   This section gives considerations for new schemes. Meeting these
>   guidelines is REQUIRED for permanent scheme registration.
>   Permanent status is appropriate for, but not limited to,
>   use in standards. For URI schemes defined or normatively
>   referenced by IETF Standards-Track documents, Permanent registration
> status is REQUIRED.
>=20
> He added "or normatively referenced" which now appears in the draft.
>=20
> Here is a real world example of a problem with this text. SIDR WG decided=
 to
> use rsync protocol, they needed to use rsync URIs. rsync URIs are current=
ly
> provisional, defined in an Informational RFC.  So this text is basically =
saying
> that under the new rule the registration have to be upgraded to Permanent=
,
> allowing the expert reviewer (no disrespect to Graham or his future
> replacement) to be a person that blocks consensus of a WG to use a
> particular technology. I find this to be problematic.
>=20
> Do people agree that this is problematic?

This was basically discussed in the thread month ago.  See
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg14045.html=20
for Barry's message in that thread, which I agree with.   That thread is wh=
ere
it looked like there was consensus that the intent was as currently worded.

Specifically, Barry's point was:
> without some change like that, one can simply pull
> a URI scheme definition out of a Standards Track document, post it on
> a web site, get a provisional registration for it, and use it in the
> Standards Track document... making this requirement fairly pointless.

We already got consensus (including advice from the AD during the WG meetin=
g)
to empower the Expert Reviewer more and lessen the load on the IESG.
I think the current text is also in keeping with that consensus.  If a bloc=
kage
happens, it can be escalated to the IESG, which also controls who the Exper=
t
Reviewer is, so the IESG always has a way of overriding the Expert anyway.
Since that escape hatch is there, I believe the current text is correct as =
is,
and reflects consensus both in the meeting and on the list.

-Dave


From nobody Wed Apr  8 10:02:03 2015
Return-Path: 
X-Original-To: expand-draft-ietf-appsawg-uri-scheme-reg.all@virtual.ietf.org
Delivered-To: apps-discuss@ietfa.amsl.com
Received: by ietfa.amsl.com (Postfix, from userid 65534) id 7D1961ACDD6; Tue,  7 Apr 2015 17:09:32 -0700 (PDT)
X-Original-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com
Delivered-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 584711ACDD4; Tue,  7 Apr 2015 17:09:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.902
X-Spam-Level: 
X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id amv7IffMGdVw; Tue,  7 Apr 2015 17:09:30 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0116.outbound.protection.outlook.com [207.46.100.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 303091ACDA3; Tue,  7 Apr 2015 17:09:30 -0700 (PDT)
Received: from BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) by BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) with Microsoft SMTP Server (TLS) id 15.1.130.12; Wed, 8 Apr 2015 00:09:28 +0000
Received: from BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) by BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) with mapi id 15.01.0130.020; Wed, 8 Apr 2015 00:09:28 +0000
From: Dave Thaler 
To: John C Klensin , Alexey Melnikov , Barry Leiba 
Thread-Topic: [apps-discuss] FW: New Version Notification - draft-ietf-appsawg-uri-scheme-reg-05.txt
Thread-Index: AQHQalrhkv9nwJjIwUqSz15OYYohZp1CST2A
Date: Wed, 8 Apr 2015 00:09:28 +0000
Message-ID: 
References: <20150327163331.20999.30881.idtracker@ietfa.amsl.com>   <551806AD.2010409@isode.com> <4F34805800F3B75F9752C8A5@JcK-HP8200.jck.com>
In-Reply-To: <4F34805800F3B75F9752C8A5@JcK-HP8200.jck.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:4898:80e0:ee43::3]
authentication-results: jck.com; dkim=none (message not signed) header.d=none; 
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB412;
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(24454002)(51704005)(86612001)(40100003)(2420400003)(77096005)(102836002)(62966003)(122556002)(15975445007)(77156002)(76576001)(106116001)(54356999)(33656002)(2900100001)(19580395003)(230783001)(2950100001)(50986999)(76176999)(92566002)(46102003)(86362001)(99286002)(87936001)(74316001)(93886004)(2656002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB412; H:BY2PR03MB412.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:BY2PR03MB412; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB412; 
x-forefront-prvs: 0540846A1D
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.onmicrosoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2015 00:09:28.7916 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB412
Archived-At: 
X-Mailman-Approved-At: Wed, 08 Apr 2015 10:01:59 -0700
Cc: "draft-ietf-appsawg-uri-scheme-reg.all@ietf.org" , "iesg@ietf.org" 
Subject: Re: [apps-discuss] FW: New Version Notification - draft-ietf-appsawg-uri-scheme-reg-05.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 08 Apr 2015 00:09:32 -0000

John C Klensin wrote:
> Larry Masinter has raised several issues in the URNBIS WG in which he cla=
ims
> that draft-ietf-appsawg-uri-scheme-reg constrains what that WG is proposi=
ng
> to do with URNs [1].  I also believe that some of his comments mix up
> registration of schemes (e.g., "urn:") with registrations of URN namespac=
es
> and NIDs  I think those issues need to be considered in that WG.
> However, procedurally, it seems to me that either:
>=20
> (1) Existing registrations are existing registrations and any updates to =
them
> are grandfathered, i.e., whatever draft-ietf-appsawg-uri-scheme-reg says =
is not
> applicable to the original or updated registration of any URI scheme
> registered or deployed before it is approved and published.  That obvious=
ly
> includes the revised URN registration contemplated by draft-ietf-urnbis-
> rfc2141bis-urn.

It's certainly not applicable to the original registration before the new p=
rocedure
is published.   I believe it ought to apply to updates though the IESG and/=
or
the Expert Reviewer should take into account the existing registration and
act accordingly.   An example of why I think it should apply to updates is =
that
say an actual owner wants to update a registration of a Provisional scheme
that I or Alexey registered as a third-party scheme, doing so should not
require an Expert Review, where the old process did.

The new doc lowers the bar, it doesn't raise it.
To my knowledge there's no MUST in it that's more strict than RFC 4395, tog=
ether
with RFC 3986 and 3987, was intended to be.

The issues with URN are about where one can argue that it doesn't/didn't me=
et
one or more of RFC 4395, 3986, or 3987.   The new doc doesn't change it exc=
ept
to make it clearer, and to make some requirements (i.e. for Provisional) we=
aker.

> (2) We have a mess on our hands in which not only do the mandates of
> different WGs overlap but in which an area WG that is not noted for very
> intense reviews can constrain and override the work of more topic-focused
> (and, therefore, presumably more expert on their own topics) WGs and othe=
r
> efforts.  This is particularly problematic in the case of URIs, where par=
allel
> (and not entirely consistent) work is going on to further develop specifi=
c URI
> schemes (URNs being only one such example) and groups outside the IETF
> (including WHATWG and W3C groups) with coordination processes that are
> still being negotiated and in groups that are heavily dependent on URIs a=
nd
> URI handling (certainly including HTTPbis).
>=20
> If it is applicable to existing registrations and ongoing work in other W=
Gs, this
> spec is even more problematic because it is heavily dependent on details =
of
> RFC 3986, a specification whose exact meaning, implications, and
> consequences continue to be debated and which is a candidate for
> preemption or replacement by those other bodies.
>=20
> I suggest that any IESG action on
> draft-ietf-appsawg-uri-scheme-reg be deferred until which of the above
> principles applies can be clarified (and clarified in the
> document) and, if the second option is chosen, that formal reviews and
> impact assessments be sought from all active WGs that are involved with o=
r
> use URIs as well as from W3C.

In my opinion, delaying publication of draft-ietf-appsawg-uri-scheme-reg
would be harmful since it keeps the bar high and disincents people from reg=
istering
at all.   I believe the issues you're worried about should be dealt with se=
parately
from draft-ietf-appsawg-uri-scheme-reg.   If it turns out that some change =
is
needed to draft-ietf-appsawg-uri-scheme-reg later, we can always rev then.
But we should not hold up lowering the bar for Provisional until some indef=
inite
future period.

Dave

> Sorry to be raising this so late in the process, but it never occurred to=
 me that
> anyone would claim that draft-ietf-appsawg-uri-scheme-reg constrained oth=
er
> IETF WGs, standards-track updates to existing registrations that were mad=
e as
> the result of standards actions, etc.  Since that claim has now been made=
, and
> made by one of the authors of the new draft who presumably understands
> the intent, a "wait a minute"
> response seems necessary.
>=20
>      john
>=20
>=20
> [1]
> http://www.ietf.org/mail-archive/web/urn/current/msg02873.html


From nobody Wed Apr  8 10:02:04 2015
Return-Path: 
X-Original-To: expand-draft-ietf-appsawg-uri-scheme-reg.all@virtual.ietf.org
Delivered-To: apps-discuss@ietfa.amsl.com
Received: by ietfa.amsl.com (Postfix, from userid 65534) id 109921B2B0C; Tue,  7 Apr 2015 18:23:47 -0700 (PDT)
X-Original-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com
Delivered-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E63681B2B09; Tue,  7 Apr 2015 18:23:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.902
X-Spam-Level: 
X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6jkV9_nNOePE; Tue,  7 Apr 2015 18:23:45 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0789.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:789]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C29391B2A7D; Tue,  7 Apr 2015 18:23:44 -0700 (PDT)
Received: from BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) by BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) with Microsoft SMTP Server (TLS) id 15.1.130.12; Wed, 8 Apr 2015 01:23:29 +0000
Received: from BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) by BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) with mapi id 15.01.0130.020; Wed, 8 Apr 2015 01:23:29 +0000
From: Dave Thaler 
To: "drafts-eval@iana.org" 
Thread-Topic: [IANA #815901] Evaluation:  to Best Current Practice
Thread-Index: AQHQbXbnKKnf2GHeWUSP7Rw/pvVmQJ1CVx5w
Date: Wed, 8 Apr 2015 01:23:28 +0000
Message-ID: 
References:  <20150327192825.8728.9848.idtracker@ietfa.amsl.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:4898:80e0:ee43::3]
authentication-results: iana.org; dkim=none (message not signed) header.d=none;
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB412;
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(51704005)(377454003)(13464003)(46102003)(86362001)(2950100001)(2900100001)(230783001)(19580395003)(50986999)(92566002)(19580405001)(76176999)(2656002)(87936001)(74316001)(99286002)(86612001)(2351001)(15975445007)(122556002)(106116001)(110136001)(2501003)(33656002)(54356999)(76576001)(77156002)(62966003)(77096005)(40100003)(102836002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB412; H:BY2PR03MB412.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:BY2PR03MB412; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB412; 
x-forefront-prvs: 0540846A1D
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.onmicrosoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2015 01:23:28.8739 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB412
Archived-At: 
X-Mailman-Approved-At: Wed, 08 Apr 2015 10:01:59 -0700
Cc: "appsawg-chairs@ietf.org" , "draft-ietf-appsawg-uri-scheme-reg.all@ietf.org" , "iesg@ietf.org" 
Subject: Re: [apps-discuss] [IANA #815901] Evaluation:  to Best Current Practice
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 08 Apr 2015 01:23:47 -0000

PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBQZWFybCBMaWFuZyB2aWEgUlQg
W21haWx0bzpkcmFmdHMtZXZhbEBpYW5hLm9yZ10NCj4gU2VudDogVGh1cnNkYXksIEFwcmlsIDIs
IDIwMTUgMTE6NTggQU0NCj4gQ2M6IGRyYWZ0LWlldGYtYXBwc2F3Zy11cmktc2NoZW1lLXJlZy5h
bGxAaWV0Zi5vcmc7IGFwcHNhd2ctY2hhaXJzQGlldGYub3JnOw0KPiBpZXNnQGlldGYub3JnDQo+
IFN1YmplY3Q6IFtJQU5BICM4MTU5MDFdIEV2YWx1YXRpb246IDxkcmFmdC1pZXRmLWFwcHNhd2ct
dXJpLXNjaGVtZS1yZWctDQo+IDA1LnR4dD4gdG8gQmVzdCBDdXJyZW50IFByYWN0aWNlDQo+IA0K
PiBJRVNHOg0KPiANCj4gSUFOQSBPSy4gQ29tbWVudHMgaW4gdHJhY2tlci4NCj4gSUFOQSBBY3Rp
b25zIC0gWUVTDQo+IA0KPiBUaGlzIHZlcnNpb24gaXMgb2theSwgYXMgcGVyIEdyYWhhbSBLbHlu
ZSdzIHJldmlldy4gIEhlIGp1c3Qgbm90ZWQgYSBmZXcgbml0cw0KPiBiZWxvdzoNCj4gDQo+IC0t
LS0tLS0tLS0NCj4gDQo+IFJ1bm5pbmcgdGhyb3VnaCBteSBjb21tZW50czoNCj4gDQo+IA0KPiA+
IFNlY3Rpb24gMy4NCj4gPg0KPiA+ICJGb3IgSUVURiBTdGFuZGFyZHMtVHJhY2sgZG9jdW1lbnRz
LCBQZXJtYW5lbnQgcmVnaXN0cmF0aW9uIHN0YXR1cyBpcw0KPiA+IFJFUVVJUkVELiINCj4gPiBS
ZWFkaW5nIHRoaXMgbm93LCBJIGZpbmQgdGhlIGRyYWZ0aW5nIGhlcmUgaXMgcG90ZW50aWFsbHkg
Y29uZnVzaW5nLg0KPiA+IFN1Z2dlc3Q6DQo+ID4NCj4gPiAiRm9yIFVSSSBzY2hlbWVzIGRlZmlu
ZWQgb3Igbm9ybWF0aXZlbHkgcmVmZXJlbmNlZCBieSBJRVRGIFN0YW5kYXJkcy0NCj4gPiBUcmFj
ayBkb2N1bWVudHMsIFBlcm1hbmVudCByZWdpc3RyYXRpb24gc3RhdHVzIGlzIFJFUVVJUkVELiIN
Cj4gDQo+IExvb2tzIGdvb2QuIChJcyBpdCB0aGUgYWNjZXB0ZWQgc3R5bGUgZm9yIHRoaXMgZG9j
dW1lbnQgdG8gY2FwaXRhbGl6ZQ0KPiAiUGVybWFuZW50IiBoZXJlPykNCg0KQ29udmVudGlvbiB3
YXMgaW5jb25zaXN0ZW50Li4uIHNvbWV0aW1lcyBQZXJtYW5lbnQsIHNvbWV0aW1lcw0KcGVybWFu
ZW50LCBzb21ldGltZXMgJ3Blcm1hbmVudCcuICAgUkZDIDQzOTUgdXNlZCB0aGUgbGF0dGVyIGZv
cm0uDQpJIHRoaW5rIHRoaXMgc2hvdWxkIGRvIHRoZSBzYW1lLg0KDQo+ID4gU2VjdGlvbiA3LjI6
DQo+ID4NCj4gPiAiIDguIE9uY2UgRXhwZXJ0IFJldmlldyBhcHByb3ZlcyByZWdpc3RyYXRpb24g
Zm9yIGEgZ2l2ZW4gc3RhdHVzLA0KPiA+IElBTkENCj4gPiBhZGRzIHRoZSByZWdpc3RyYXRpb24g
dG8gdGhlIHJlZ2lzdHJ5LiINCj4gPg0KPiA+IEkgbm90ZSB0aGF0IHRoZSBzY2hlbWUgaGFzIGFs
cmVhZHkgYmVlbiBhZGRlZCB0byB0aGUgcmVnaXN0cnkgYXQgcHJpb3INCj4gPiBzdGVwIDMuDQo+
ID4NCj4gPiBTdWdnZXN0Og0KPiA+DQo+ID4gIiA4LiBPbmNlIEV4cGVydCBSZXZpZXcgYXBwcm92
ZXMgcmVnaXN0cmF0aW9uIGZvciBhIGdpdmVuIHN0YXR1cywNCj4gPiBJQU5BDQo+ID4gdXBkYXRl
cyB0aGUgcmVnaXN0cmF0aW9uIChwZXIgc3RlcCAzKSB0byBpbmRpY2F0ZSB0aGUgYXBwcm92ZWQN
Cj4gPiBzdGF0dXMuICINCj4gDQo+IExvb2tzIE9LLCBidXQgd2hlcmUgaXQgc2F5cyAidGhlICJQ
ZW5kaW5nIFJldmlldyIgcmVxdWVzdCBpcyByZW1vdmVkIGZyb20NCj4gdGhlDQo+IHJlZ2lzdHJ5
IiBJIG1pZ2h0IGFkZCAiLCBhbmQgdGhlIHNjaGVtZSByZW1haW5zIGFzIGEgcHJvdmlzaW9uYWwg
cmVnaXN0cmF0aW9uIi4NCg0KTm8sIGlmIGl0J3MgcmVqZWN0ZWQgaXQncyBub3QgaW4gdGhlIHJl
Z2lzdHJ5IGF0IGFsbCAoc2FtZSBhcyB0aGUgb2xkIHByb2Nlc3MpLg0KU2luY2UgeW91IHNhaWQg
eW91ICJtaWdodCIgYWRkLCBJIHdpbGwgdGFrZSB0aGlzIGFzIG5vdCBhIHN0cm9uZyBvcGluaW9u
Lg0KDQo+ID4gU2VjdGlvbiA4Og0KPiA+DQo+ID4gSSB3YXMgc29tZXdoYXQgdGhyb3duIGJ5IHRo
ZSBoZWFkaW5nIG9mIHNlY3Rpb24gOC4xLg0KPiA+DQo+ID4gIjguMS4gIkV4YW1wbGUiIFNjaGVt
ZSBSZWdpc3RyYXRpb24gUmVxdWVzdCINCj4gPg0KPiA+IEkgdGhpbmsgdGhlIGludGVudCB3b3Vs
ZCBiZSBjbGVhcmVyIGlmIHRoZSBzZWN0aW9uIHRpdGxlIHdlcmUgZ2l2ZW4NCj4gPiBhczoNCj4g
Pg0KPiA+ICI4LjEuICJFeGFtcGxlIiBTY2hlbWUgUmVnaXN0cmF0aW9uIFRlbXBsYXRlIg0KPiA+
DQo+IA0KPiBUaGlzIHBvaW50IGhhcyBub3QgYmVlbiBhZGRyZXNzZWQsIGJ1dCBJIGRvbid0IHRo
aW5rIGl0J3MgYSBibG9ja2VyLg0KDQpJIHJlc3BvbmRlZCB0byB0aGlzIGluIGVhcmxpZXIgZW1h
aWwgZXhwbGFpbmluZyB3aHkgaXQncyBjb3JyZWN0IGFzIGlzLg0KU28gaXQgd2FzIGFkZHJlc3Nl
ZCB2aWEgZW1haWwgYXQNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9hcHBz
LWRpc2N1c3MvY3VycmVudC9tc2cxNDEwNS5odG1sIA0KDQpEYXZlIA0KDQo=


From nobody Wed Apr  8 10:02:06 2015
Return-Path: 
X-Original-To: expand-draft-ietf-appsawg-multipart-form-data.all@virtual.ietf.org
Delivered-To: apps-discuss@ietfa.amsl.com
Received: by ietfa.amsl.com (Postfix, from userid 65534) id D08471B2FA6; Wed,  8 Apr 2015 04:05:37 -0700 (PDT)
X-Original-To: xfilter-draft-ietf-appsawg-multipart-form-data.all@ietfa.amsl.com
Delivered-To: xfilter-draft-ietf-appsawg-multipart-form-data.all@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7D4E1B2FA6 for ; Wed,  8 Apr 2015 04:05:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_FAIL=0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KDgt9RInFQxo for ; Wed,  8 Apr 2015 04:05:35 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F34D61B2FA5 for ; Wed,  8 Apr 2015 04:05:34 -0700 (PDT)
Received: from mail-bn1on0066.outbound.protection.outlook.com ([157.56.110.66]:44448 helo=na01-bn1-obe.outbound.protection.outlook.com) by zinfandel.tools.ietf.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YfnnW-0007Kp-Fd for draft-ietf-appsawg-multipart-form-data.all@tools.ietf.org; Wed, 08 Apr 2015 04:05:34 -0700
Received: from DM2PR02MB1322.namprd02.prod.outlook.com (25.161.142.21) by DM2PR02MB1324.namprd02.prod.outlook.com (25.161.142.23) with Microsoft SMTP Server (TLS) id 15.1.118.21; Wed, 8 Apr 2015 06:30:44 +0000
Received: from DM2PR02MB1322.namprd02.prod.outlook.com ([25.161.142.21]) by DM2PR02MB1322.namprd02.prod.outlook.com ([25.161.142.21]) with mapi id 15.01.0118.029; Wed, 8 Apr 2015 06:30:44 +0000
From: Larry Masinter 
To: Chris Lonvick , "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-appsawg-multipart-form-data.all@tools.ietf.org" 
Thread-Topic: SECDIR review of draft-ietf-appsawg-multipart-form-data-08
Thread-Index: AQHQbJ9sAFA7MLO800ael97UJqkWgZ1CPHyA
Date: Wed, 8 Apr 2015 06:30:44 +0000
Message-ID: <22407EB2-5E94-42F1-B191-6955F35F4098@adobe.com>
References: <551C2791.7090206@gmail.com>
In-Reply-To: <551C2791.7090206@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/15.8.0.150303
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [50.184.24.49]
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR02MB1324;
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10009020)(377454003)(479174004)(66066001)(2201001)(46102003)(2900100001)(2950100001)(87936001)(2656002)(92566002)(16236675004)(36756003)(15975445007)(102836002)(54356999)(122556002)(50986999)(40100003)(76176999)(107886001)(82746002)(83506001)(86362001)(33656002)(230783001)(62966003)(83716003)(99286002)(19580405001)(77156002)(19617315012)(16601075003)(19580395003)(2501003)(106116001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR02MB1324; H:DM2PR02MB1322.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:DM2PR02MB1324; BCL:0; PCL:0; RULEID:;  SRVR:DM2PR02MB1324; 
x-forefront-prvs: 0540846A1D
Content-Type: multipart/alternative; boundary="_000_22407EB25E9442F1B1916955F35F4098adobecom_"
MIME-Version: 1.0
X-OriginatorOrg: adobe.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2015 06:30:44.2221 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR02MB1324
X-Helo-Check-Failed: Verification failed for HELO na01-bn1-obe.outbound.protection.outlook.com
X-SA-Exim-Connect-IP: 157.56.110.66
X-SA-Exim-Rcpt-To: draft-ietf-appsawg-multipart-form-data.all@tools.ietf.org
X-SA-Exim-Mail-From: masinter@adobe.com
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org)
Resent-To: draft-ietf-appsawg-multipart-form-data.all@ietf.org
Resent-Message-Id: <20150408110534.F34D61B2FA5@ietfa.amsl.com>
Resent-Date: Wed,  8 Apr 2015 04:05:34 -0700 (PDT)
Resent-From: masinter@adobe.com
Archived-At: 
Archived-At: 
X-Mailman-Approved-At: Wed, 08 Apr 2015 10:01:59 -0700
Subject: Re: [apps-discuss] SECDIR review of draft-ietf-appsawg-multipart-form-data-08
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 08 Apr 2015 11:05:38 -0000

--_000_22407EB25E9442F1B1916955F35F4098adobecom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

DQoNCk9uIDQvMS8xNSwgMTA6MTQgQU0sICJDaHJpcyBMb252aWNrIiA8bG9udmljay5pZXRmQGdt
YWlsLmNvbTxtYWlsdG86bG9udmljay5pZXRmQGdtYWlsLmNvbT4+IHdyb3RlOg0KPiBJIHdvdWxk
IHN1Z2dlc3QgcGxhY2luZyB0aGUgbGFzdCBwYXJhZ3JhcGggb2YgdGhlIFNlY3VyaXR5IENvbnNp
ZGVyYXRpb25zIHNlY3Rpb24gYXQgdGhlIHRvcCBvZiB0aGUgc2VjdGlvbi4gVGhhdCBwYXJhZ3Jh
cGggc2VlbXMgdG8gYmUgdGhlIG1vc3QgY29tcHJlaGVuc2l2ZSBpbiB0aGVzZSBjb25zaWRlcmF0
aW9ucywgYW5kIHRoZSBvdGhlciBwYXJhZ3JhcGhzIHNlZW0gdG8gYXVnbWVudCBhbmQgZ2l2ZSBz
cGVjaWZpYyBkZXRhaWxzLiBJdCBqdXN0IHNlZW1zIHRvIG1lIHRoYXQgaXQgd291bGQgcHJvdmlk
ZSBhIGJldHRlciBmbG93IHRvIHJlYWRpbmcgdGhhdCBzZWN0aW9uLg0KDQpJIHRyaWVkIGl0IGFu
ZCBpdCBkaWRu4oCZdCBmbG93IGFueSBiZXR0ZXIuICBJ4oCZZCBtYWtlIHRoZSBlZGl0IGlmIEkg
ZmVsdCBpdCBtYWRlIGEgZGlmZmVyZW5jZSBidXQgSSBkb27igJl0IHRoaW5rIGl0IGhlbHBzLg0K
DQoNCkFsc28sIEknbSBqdXN0IG5vdCBzdXJlIHRoYXQgSSdtIGZvbGxvd2luZyB0aGUgc2Vjb25k
IHBhcmFncmFwaCBvZg0KQXBwZW5kaXggQjoNCiAgIE1vcmUgcHJvYmxlbWF0aWMgaXMgdGhlIGFt
YmlndWl0eSBpbnRyb2R1Y2VkIGJlY2F1c2UgaW1wbGVtZW50YXRpb25zDQogICBkaWQgbm90IGZv
bGxvdyBbUkZDMjM4ODxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMjM4OD5dIGJlY2F1
c2UgaXQgdXNlZCAibWF5IiBpbnN0ZWFkIG9mICJNVVNUIiB3aGVuDQogICBzcGVjaWZ5aW5nIGVu
Y29kaW5nIG9mIGZpZWxkIG5hbWVzLCBhbmQgZm9yIG90aGVyIHVua25vd24gcmVhc29ucywgc28N
CiAgIG5vdywgcGFyc2VycyBuZWVkIHRvIGJlIG1vcmUgY29tcGxleCBmb3IgZnV6enkgbWF0Y2hp
bmcgYWdhaW5zdCB0aGUNCiAgIHBvc3NpYmxlIG91dHB1dHMgb2YgdmFyaW91cyBlbmNvZGluZyBt
ZXRob2RzLg0KUGxlYXNlIGNvcnJlY3QgbWUgaWYgSSdtIG9mZiBiYXNlIGhlcmUsIGJ1dCBpdCBz
b3VuZHMgbGlrZSB0aGUgYW1iaWd1aXR5DQpzZXQgaW4gYmVjYXVzZSBpbXBsZW1lbnRhdGlvbnMg
V0VSRSBmb2xsb3dpbmcgUkZDIDIzODggYnkgbWFraW5nDQpjaG9pY2VzIG9uIHRoZWlyIG93biAo
ZHVlIHRvIHRoZSAibWF5InMpIHJhdGhlciB0aGFuIGJlaW5nIGRpcmVjdGVkIHRvDQptYWtlIHVu
aWZvcm0gY2hvaWNlcyB3aGljaCB3b3VsZCBoYXZlIGJlZW4gbWFuZGF0ZWQgaWYgdGhhdCBSRkMg
aGFkIHVzZWQNCiJNVVNUInMuDQoNClRoaXMgaXMgYWxzbyBlZGl0b3JpYWwsIGFzIHRvIHdobyBp
cyBhdCBmYXVsdC4gIGlmIHRoZSBzcGVjIHNheXMg4oCceW91IGNhbiB1c2UgbWV0aG9kIEEgZm9y
IHNpdHVhdGlvbiBT4oCdIGFuZA0KaW1wbGVtZW50b3Igc2F5cyDigJxkaWRu4oCZdCBzYXkgTVVT
VCwgc28gSeKAmWxsIHVzZSBtZXRob2QgQiBpbnN0ZWFk4oCdLCBkbyB5b3UgYmxhbWUgdGhlIHNw
ZWMgd3JpdGVyIG9yDQp0aGUgaW1wbGVtZW50b3IuICBJJ2QgaW1wbGVtZW50b3JzIHRvIHJlYWQg
SUVURiBSRkNzIHdpdGggZW5naW5lZXJpbmcgY29tbW9uIHNlbnNlIGFuZCBub3QgcGxheQ0KbGVn
YWxpc3RpYyBnYW1lcyBhcm91bmQgbm9ybWF0aXZlIHRlcm1zLiBTbyBJ4oCZbG0gZ29pbmcgdG8g
c3RpY2sgd2l0aCBteSBsYW5ndWFnZS4NCg0KDQpGaW5hbGx5LCBJIHVzdWFsbHkgYWR2b2NhdGUg
Z2l2aW5nIGRpcmVjdGlvbnMgdG8gaW1wbGVtZW50ZXJzIGFib3V0IHdoYXQgdG8gZG8gaWYgdGhl
eSBmaW5kIGltcGxlbWVudGF0aW9ucyB1c2luZyB0aGUgb2xkZXIsIG91dGRhdGVkIHNwZWMuIEFz
IGFuIGV4YW1wbGUsIHdoYXQgc2hvdWxkIGEgcmVjZWl2ZXIgZG8gaWYgaXQgZ2V0cyBhIENvbnRl
bnRUeXBlIHRoYXQgZG9lcyBub3QgaGF2ZSBhICJib3VuZGFyeSIgcGFyYW1ldGVyPyBIb3dldmVy
LCBhcyBJJ20gbm90IHJlYWxseSBmYW1pbGlhciB3aXRoIHRoaXMgdGVjaG5vbG9neSwgYW5kIGFz
IHRoZSBkb2N1bWVudCBzYXlzIHRoZXJlIGFyZSBtYW55IHdheXMgdG8gZG8gYWxsIG9mIHRoaXMs
IHRoZW4gSSdtIG5vdCBzdXJlIHRoYXQgY291bGQgb3Igc2hvdWxkIGJlIGRpc2N1c3NlZC4gSWYg
aXQgaXMgc29tZXRoaW5nIHRoYXQgd291bGQgYmV0dGVyIGRlZmluZSBiZWhhdmlvciB0aGVuIEkg
d291bGQgc3VnZ2VzdCBwcm92aWRpbmcgc29tZSBndWlkYW5jZSBoZXJlLg0KDQp0aGUgYm91bmRh
cnkgcGFyYW1ldGVyIGlzIHVzZWQgaW4gYWxsIG11bHRpcGFydCB0eXBlcywgd2hpY2ggYXJlIHdp
ZGVzcHJlYWQgaW4gdGhlIEludGVybmV0LiBUaGUNCmNvbW1vbiB1bmRlcnN0YW5kaW5nIG9mIG11
bHRpcGFydCBpcyB3aHkgd2UgcGlja2VkIGl0IGZvciBmcmFtaW5nIGZvcm0tZGF0YSwgZXZlbiB0
aG91Z2ggaXTigJlzDQp1Z2x5IGFuZCB0aGUgcHJvYmFiaWxpc3RpYyBib3VuZGFyeSBnZW5lcmF0
aW9uIGRyaXZlcyBsb3RzIG9mIHBlb3BsZSBjcmF6eS4gU28gdGhpcyBraW5kIG9mIHN0dWZmIHRo
YXQNCmlzIGluaGVyaXRlZCBmcm9tIE1JTUUgZG9lc27igJl0IG5lZWQgZGlzY3Vzc2luZy4NCg0K
VGhlIG1haW4gcmVhc29uIHRoaXMgdXBkYXRlIHdhcyBldmVuIG5lY2Vzc2FyeSBpcyBiZWNhdXNl
IHRoYXQgYWR2YW50YWdlIHdhc27igJl0IGFzIGdyZWF0IGFueSBtb3JlLA0KYW5kIHRodXMgdGhl
IGRpdmVyZ2VuY2VzIGZyb20gb3RoZXIgbXVsdGlwYXJ0IHR5cGVzLg0KDQpMYXJyeQ0K4oCUDQpo
dHRwOi8vbGFycnkubWFzaW50ZXIubmV0DQoNCg0K

--_000_22407EB25E9442F1B1916955F35F4098adobecom_
Content-Type: text/html; charset="utf-8"
Content-ID: <97C98C65226FF540B2E62A54152E3CEF@namprd02.prod.outlook.com>
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy
ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsiPg0KPGRpdj4NCjxk
aXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgaWQ9Ik1BQ19PVVRMT09LX1NJR05B
VFVSRSI+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0K
PHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXY+DQo8ZGl2Pk9uIDQvMS8xNSwg
MTA6MTQgQU0sICZxdW90O0NocmlzIExvbnZpY2smcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzps
b252aWNrLmlldGZAZ21haWwuY29tIj5sb252aWNrLmlldGZAZ21haWwuY29tPC9hPiZndDsgd3Jv
dGU6PC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW46MCAwIDAgNDBweDsg
Ym9yZGVyOm5vbmU7IHBhZGRpbmc6MHB4OyI+DQo8ZGl2PjxpPiZndDsgSSB3b3VsZCBzdWdnZXN0
IHBsYWNpbmcgdGhlIGxhc3QgcGFyYWdyYXBoIG9mIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9u
cyBzZWN0aW9uIGF0IHRoZSB0b3Agb2YgdGhlIHNlY3Rpb24uIFRoYXQgcGFyYWdyYXBoIHNlZW1z
IHRvIGJlIHRoZSBtb3N0IGNvbXByZWhlbnNpdmUgaW4gdGhlc2UgY29uc2lkZXJhdGlvbnMsIGFu
ZCB0aGUgb3RoZXIgcGFyYWdyYXBocyBzZWVtIHRvIGF1Z21lbnQgYW5kIGdpdmUgc3BlY2lmaWMg
ZGV0YWlscy4NCiBJdCBqdXN0IHNlZW1zIHRvIG1lIHRoYXQgaXQgd291bGQgcHJvdmlkZSBhIGJl
dHRlciBmbG93IHRvIHJlYWRpbmcgdGhhdCBzZWN0aW9uLjwvaT48L2Rpdj4NCjwvYmxvY2txdW90
ZT4NCjwvc3Bhbj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkkgdHJpZWQgaXQgYW5kIGl0IGRp
ZG7igJl0IGZsb3cgYW55IGJldHRlci4gJm5ic3A7SeKAmWQgbWFrZSB0aGUgZWRpdCBpZiBJIGZl
bHQgaXQgbWFkZSBhIGRpZmZlcmVuY2UgYnV0IEkgZG9u4oCZdCB0aGluayBpdCBoZWxwcy48L2Rp
dj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0K
PGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW46MCAwIDAgNDBweDsgYm9yZGVyOm5vbmU7
IHBhZGRpbmc6MHB4OyI+DQo8ZGl2IHRleHQ9IiMwMDAwMDAiIGJnY29sb3I9IiNGRkZGRkYiPg0K
PHByZSBjbGFzcz0id2lraSI+PGk+QWxzbywgSSdtIGp1c3Qgbm90IHN1cmUgdGhhdCBJJ20gZm9s
bG93aW5nIHRoZSBzZWNvbmQgcGFyYWdyYXBoIG9mDQpBcHBlbmRpeCBCOg0KICAgTW9yZSBwcm9i
bGVtYXRpYyBpcyB0aGUgYW1iaWd1aXR5IGludHJvZHVjZWQgYmVjYXVzZSBpbXBsZW1lbnRhdGlv
bnMNCiAgIGRpZCBub3QgZm9sbG93IFs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0
bWwvcmZjMjM4OCIgdGl0bGU9IiZxdW90O1JldHVybmluZyBWYWx1ZXMgZnJvbSBGb3JtczogbXVs
dGlwYXJ0LyBmb3JtLWRhdGEmcXVvdDsiPlJGQzIzODg8L2E+XSBiZWNhdXNlIGl0IHVzZWQgJnF1
b3Q7bWF5JnF1b3Q7IGluc3RlYWQgb2YgJnF1b3Q7TVVTVCZxdW90OyB3aGVuDQogICBzcGVjaWZ5
aW5nIGVuY29kaW5nIG9mIGZpZWxkIG5hbWVzLCBhbmQgZm9yIG90aGVyIHVua25vd24gcmVhc29u
cywgc28NCiAgIG5vdywgcGFyc2VycyBuZWVkIHRvIGJlIG1vcmUgY29tcGxleCBmb3IgZnV6enkg
bWF0Y2hpbmcgYWdhaW5zdCB0aGUNCiAgIHBvc3NpYmxlIG91dHB1dHMgb2YgdmFyaW91cyBlbmNv
ZGluZyBtZXRob2RzLg0KUGxlYXNlIGNvcnJlY3QgbWUgaWYgSSdtIG9mZiBiYXNlIGhlcmUsIGJ1
dCBpdCBzb3VuZHMgbGlrZSB0aGUgYW1iaWd1aXR5DQpzZXQgaW4gYmVjYXVzZSBpbXBsZW1lbnRh
dGlvbnMgV0VSRSBmb2xsb3dpbmcgUkZDIDIzODggYnkgbWFraW5nDQpjaG9pY2VzIG9uIHRoZWly
IG93biAoZHVlIHRvIHRoZSAmcXVvdDttYXkmcXVvdDtzKSByYXRoZXIgdGhhbiBiZWluZyBkaXJl
Y3RlZCB0bw0KbWFrZSB1bmlmb3JtIGNob2ljZXMgd2hpY2ggd291bGQgaGF2ZSBiZWVuIG1hbmRh
dGVkIGlmIHRoYXQgUkZDIGhhZCB1c2VkDQomcXVvdDtNVVNUJnF1b3Q7cy48L2k+PC9wcmU+DQo8
L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9zcGFuPg0KPGRpdj5UaGlzIGlzIGFsc28g
ZWRpdG9yaWFsLCBhcyB0byB3aG8gaXMgYXQgZmF1bHQuICZuYnNwO2lmIHRoZSBzcGVjIHNheXMg
4oCceW91IGNhbiB1c2UgbWV0aG9kIEEgZm9yIHNpdHVhdGlvbiBT4oCdIGFuZDwvZGl2Pg0KPGRp
dj5pbXBsZW1lbnRvciBzYXlzIOKAnGRpZG7igJl0IHNheSBNVVNULCBzbyBJ4oCZbGwgdXNlIG1l
dGhvZCBCIGluc3RlYWTigJ0sIGRvIHlvdSBibGFtZSB0aGUgc3BlYyB3cml0ZXIgb3I8L2Rpdj4N
CjxkaXY+dGhlIGltcGxlbWVudG9yLiAmbmJzcDtJJ2QgaW1wbGVtZW50b3JzIHRvIHJlYWQgSUVU
RiBSRkNzIHdpdGggZW5naW5lZXJpbmcgY29tbW9uIHNlbnNlIGFuZCBub3QgcGxheTwvZGl2Pg0K
PGRpdj5sZWdhbGlzdGljIGdhbWVzIGFyb3VuZCBub3JtYXRpdmUgdGVybXMuIFNvIEnigJlsbSBn
b2luZyB0byBzdGljayB3aXRoIG15IGxhbmd1YWdlLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N
CjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy
Z2luOjAgMCAwIDQwcHg7IGJvcmRlcjpub25lOyBwYWRkaW5nOjBweDsiPg0KPGRpdiB0ZXh0PSIj
MDAwMDAwIiBiZ2NvbG9yPSIjRkZGRkZGIj4NCjxwcmUgY2xhc3M9Indpa2kiPjxwcmUgY2xhc3M9
Im5ld3BhZ2UiPjwvcHJlPjxpPkZpbmFsbHksIEkgdXN1YWxseSBhZHZvY2F0ZSBnaXZpbmcgZGly
ZWN0aW9ucyB0byBpbXBsZW1lbnRlcnMgYWJvdXQgd2hhdA0KdG8gZG8gaWYgdGhleSBmaW5kIGlt
cGxlbWVudGF0aW9ucyB1c2luZyB0aGUgb2xkZXIsIG91dGRhdGVkIHNwZWMuICBBcw0KYW4gZXhh
bXBsZSwgd2hhdCBzaG91bGQgYSByZWNlaXZlciBkbyBpZiBpdCBnZXRzIGEgQ29udGVudFR5cGUg
dGhhdCBkb2VzDQpub3QgaGF2ZSBhICZxdW90O2JvdW5kYXJ5JnF1b3Q7IHBhcmFtZXRlcj8gIEhv
d2V2ZXIsIGFzIEknbSBub3QgcmVhbGx5IGZhbWlsaWFyIA0Kd2l0aCB0aGlzIHRlY2hub2xvZ3ks
IGFuZCBhcyB0aGUgZG9jdW1lbnQgc2F5cyB0aGVyZSBhcmUgbWFueSB3YXlzIHRvDQpkbyBhbGwg
b2YgdGhpcywgdGhlbiBJJ20gbm90IHN1cmUgdGhhdCBjb3VsZCBvciBzaG91bGQgYmUgZGlzY3Vz
c2VkLiAgSWYNCml0IGlzIHNvbWV0aGluZyB0aGF0IHdvdWxkIGJldHRlciBkZWZpbmUgYmVoYXZp
b3IgdGhlbiBJIHdvdWxkIHN1Z2dlc3QNCnByb3ZpZGluZyBzb21lIGd1aWRhbmNlIGhlcmUuPC9p
Pg0KPC9wcmU+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj4NCjxkaXY+dGhlIGJvdW5k
YXJ5IHBhcmFtZXRlciBpcyB1c2VkIGluIGFsbCBtdWx0aXBhcnQgdHlwZXMsIHdoaWNoIGFyZSB3
aWRlc3ByZWFkIGluIHRoZSBJbnRlcm5ldC4gVGhlPC9kaXY+DQo8ZGl2PmNvbW1vbiB1bmRlcnN0
YW5kaW5nIG9mIG11bHRpcGFydCBpcyB3aHkgd2UgcGlja2VkIGl0IGZvciBmcmFtaW5nIGZvcm0t
ZGF0YSwgZXZlbiB0aG91Z2ggaXTigJlzPC9kaXY+DQo8ZGl2PnVnbHkgYW5kIHRoZSBwcm9iYWJp
bGlzdGljIGJvdW5kYXJ5IGdlbmVyYXRpb24gZHJpdmVzIGxvdHMgb2YgcGVvcGxlIGNyYXp5LiBT
byB0aGlzIGtpbmQgb2Ygc3R1ZmYgdGhhdDwvZGl2Pg0KPGRpdj5pcyBpbmhlcml0ZWQgZnJvbSBN
SU1FIGRvZXNu4oCZdCBuZWVkIGRpc2N1c3NpbmcuJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwv
ZGl2Pg0KPGRpdj5UaGUgbWFpbiByZWFzb24gdGhpcyB1cGRhdGUgd2FzIGV2ZW4gbmVjZXNzYXJ5
IGlzIGJlY2F1c2UgdGhhdCBhZHZhbnRhZ2Ugd2FzbuKAmXQgYXMgZ3JlYXQgYW55IG1vcmUsPC9k
aXY+DQo8ZGl2PmFuZCB0aHVzIHRoZSBkaXZlcmdlbmNlcyBmcm9tIG90aGVyIG11bHRpcGFydCB0
eXBlcy48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkxhcnJ5PC9kaXY+DQo8ZGl2PuKA
lDwvZGl2Pg0KPGRpdj5odHRwOi8vbGFycnkubWFzaW50ZXIubmV0PC9kaXY+DQo8ZGl2Pjxicj4N
CjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxibG9ja3F1b3RlIHN0
eWxlPSJtYXJnaW46IDBweCAwcHggMHB4IDQwcHg7IGJvcmRlcjogbm9uZTsgcGFkZGluZzogMHB4
OyI+DQo8ZGl2IHRleHQ9IiMwMDAwMDAiIGJnY29sb3I9IiNGRkZGRkYiPg0KPHByZSBjbGFzcz0i
d2lraSI+PGJyPjwvcHJlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+DQo8L2JvZHk+
DQo8L2h0bWw+DQo=

--_000_22407EB25E9442F1B1916955F35F4098adobecom_--


From nobody Wed Apr  8 10:02:07 2015
Return-Path: 
X-Original-To: expand-draft-ietf-appsawg-multipart-form-data.all@virtual.ietf.org
Delivered-To: apps-discuss@ietfa.amsl.com
Received: by ietfa.amsl.com (Postfix, from userid 65534) id 616E91A8731; Wed,  8 Apr 2015 06:38:46 -0700 (PDT)
X-Original-To: xfilter-draft-ietf-appsawg-multipart-form-data.all@ietfa.amsl.com
Delivered-To: xfilter-draft-ietf-appsawg-multipart-form-data.all@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BAF71A8730 for ; Wed,  8 Apr 2015 06:38:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.612
X-Spam-Level: 
X-Spam-Status: No, score=-0.612 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j3c1yfVGvlNg for ; Wed,  8 Apr 2015 06:38:45 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86BA71A872C for ; Wed,  8 Apr 2015 06:38:45 -0700 (PDT)
Received: from mail-ig0-x229.google.com ([2607:f8b0:4001:c05::229]:35879) by zinfandel.tools.ietf.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YfqBo-0004Xf-UU for draft-ietf-appsawg-multipart-form-data.all@tools.ietf.org; Wed, 08 Apr 2015 06:38:45 -0700
Received: by igblo3 with SMTP id lo3so39300084igb.1 for ; Wed, 08 Apr 2015 06:38:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=7Nv53X6Ckl5j/0drWFN09wcvv+qmwfEfUUtuAW+KM/Q=; b=Rj9dA7DLcHuuiJv18h4IBthafSLXbZky4tT7Nm5/Zdabnj2w0JiODXeK6rVjH8ZhLY 2iv0ybYJrr5KYGcfOsbQBXCxGCdiN0lZBOgZHlpn1Swm5QcyxQOr8oUsce1Dl0xo20Or /DujSbeuo8IE+MohSFYK6G4NbH71qKXLajWGj9aFEsDtTrjsV0jmpEaowkylaG//tDaf tBFm1fAuX8RNIk2DUPPTFWmEsHlxeJCbzSELkdFiDPxo8Kr9YnjXoe9K2fGHlrqss+lE wwYxSQM2AYMaw0ZkLarOJU2QbmboaQ8fwYnbiB15aVy7xE/dSe1hx+JnS/xYlFioWZwX QciA==
MIME-Version: 1.0
X-Received: by 10.107.3.17 with SMTP id 17mr37441367iod.60.1428500318338; Wed, 08 Apr 2015 06:38:38 -0700 (PDT)
Sender: barryleiba@gmail.com
Received: by 10.107.7.130 with HTTP; Wed, 8 Apr 2015 06:38:38 -0700 (PDT)
In-Reply-To: <22407EB2-5E94-42F1-B191-6955F35F4098@adobe.com>
References: <551C2791.7090206@gmail.com> <22407EB2-5E94-42F1-B191-6955F35F4098@adobe.com>
Date: Wed, 8 Apr 2015 09:38:38 -0400
X-Google-Sender-Auth: _s83POg1Yh27WuNjnORBBUyTXMA
Message-ID: 
From: Barry Leiba 
To: Larry Masinter 
Content-Type: text/plain; charset=ISO-8859-1
X-SA-Exim-Connect-IP: 2607:f8b0:4001:c05::229
X-SA-Exim-Rcpt-To: draft-ietf-appsawg-multipart-form-data.all@tools.ietf.org
X-SA-Exim-Mail-From: barryleiba@gmail.com
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org)
Resent-To: draft-ietf-appsawg-multipart-form-data.all@ietf.org
Resent-Message-Id: <20150408133845.86BA71A872C@ietfa.amsl.com>
Resent-Date: Wed,  8 Apr 2015 06:38:45 -0700 (PDT)
Resent-From: barryleiba@gmail.com
Archived-At: 
Archived-At: 
X-Mailman-Approved-At: Wed, 08 Apr 2015 10:01:59 -0700
Cc: "draft-ietf-appsawg-multipart-form-data.all@tools.ietf.org" , "secdir@ietf.org" , Chris Lonvick , "iesg@ietf.org" 
Subject: Re: [apps-discuss] SECDIR review of draft-ietf-appsawg-multipart-form-data-08
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 08 Apr 2015 13:38:46 -0000

>> I would suggest placing the last paragraph of the Security Considerations
>> section at the top of the section. That paragraph seems to be the most
>> comprehensive in these considerations, and the other paragraphs seem to
>> augment and give specific details. It just seems to me that it would provide
>> a better flow to reading that section.
>
> I tried it and it didn't flow any better.  I'd make the edit if I felt it
> made a difference but I don't think it helps.

At least three ADs have now agreed with Chris, and I have to say that
I do as well.  None of us think it's at the level of DISCUSS, and if
you, Larry, really feel strongly about leaving it as it is I won't
hold things up for it.  But please do consider that a Security
Directorate reviewer thinks it would read better with the last graf up
front, and that four ADs agree.

Barry


From nobody Wed Apr  8 10:03:55 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 654851B3441 for ; Wed,  8 Apr 2015 10:03:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.299
X-Spam-Level: 
X-Spam-Status: No, score=0.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MANGLED_TOOL=2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S5CebaltF8Hw for ; Wed,  8 Apr 2015 10:03:52 -0700 (PDT)
Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 314FF1B3462 for ; Wed,  8 Apr 2015 10:03:52 -0700 (PDT)
Received: from [100.80.113.105] (121.sub-70-208-142.myvzw.com [70.208.142.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id E2353C40243; Wed,  8 Apr 2015 12:03:50 -0500 (CDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1428512631; bh=NpM1TyI581248msX5XlgeKEzcT1PlczKZoIHI096kqk=; h=In-Reply-To:References:Subject:From:Date:To:From; b=APwy4cHHMNphl0pMfr0RTj3wKmscnyCSyM3sfZ59eGsKTklipz2N6rpdKHyghvLpa YQQ/FtOugNjrtVw/8uFS+Xje1mAXkwUSIwewcoSbgAIS6AHINbhs40VFE+rSFENnl6 kmNIDRO92UVJUP0PxBiMXm+KpcBIrUhRwvS1K0ww=
User-Agent: K-9 Mail for Android
In-Reply-To: <039901d07216$10243640$4001a8c0@gateway.2wire.net>
References: <5518019A.7080508@isode.com> <2383989.tErOfD7dMh@kitterma-e6430> <039901d07216$10243640$4001a8c0@gateway.2wire.net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----4N62GNZQ9TOZ84RVPPHNU53YYFLVI8"
Content-Transfer-Encoding: 8bit
From: Scott Kitterman 
Date: Wed, 08 Apr 2015 13:03:35 -0400
To: apps-discuss@ietf.org
Message-ID: <8B93A4F5-3411-4561-8D39-768375CC6B06@kitterman.com>
Archived-At: 
Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-rfc7001bis-05
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 08 Apr 2015 17:03:54 -0000

------4N62GNZQ9TOZ84RVPPHNU53YYFLVI8
Content-Transfer-Encoding: 8bit
Content-Type: text/plain;
 charset=UTF-8

Good point. Thanks. 

That still doesn't match the current text. 

Scott

On April 8, 2015 12:06:57 PM EDT, "t.petch"  wrote:
>----- Original Message -----
>From: "Scott Kitterman" 
>To: 
>Sent: Wednesday, April 08, 2015 3:29 PM
>> On Sunday, March 29, 2015 02:43:54 PM Alexey Melnikov wrote:
>> > This message is starting 3 weeks (*) Working Group Last Calls on
>> > draft-ietf-appsawg-rfc7001bis-05 (Message Header Field for
>Indicating
>> > Message Authentication Status). The WGLC ends on
>> > April 19th.
>> >
>>
>> I've reviewed the document and believe it's essentially ready for
>publication.
>> I think there is a bit of editorial adjustment needed in the prose
>about
>> different a-r methods.
>>
>> Here's my list of A-R related RFCs:
>>
>> RFC 5451/7001 Message Header Field for Indicating Message
>Authentication
>> Status
>> RFC 5617 DKIM/ADSP
>> RFC 6008 DKIM signature identification (header.b)
>> RFC 6212 Vouch By Reference (VBR)
>> RFC 6577 Sender Policy Framework (SPF)
>> RFC 7281 Authentication-Results Registration for S/MIME
>> RFC 7293 The Require-Recipient-Valid-Since Header Field
>> RFC7489 DMARC
>>
>> Here's what the draft currently says about different methods:
>>
>>   At the time of publication of this document, the following are
>>   published, domain-level email authentication methods in common use:
>>
>>   o  Author Domain Signing Practices ([ADSP])
>>   o  SMTP Service Extension for Authentication ([AUTH])
>>   o  DomainKeys Identified Mail Signatures ([DKIM])
>>   o  Sender Policy Framework ([SPF])
>>   o  Vouch By Reference ([VBR])
>>   o  reverse IP address name validation ("iprev", defined in Section
>3)
>>
>>    In addition, the following are non-standard methods recognized by
>>    this specification that are no longer common:
>>
>>   o  DomainKeys ([DOMAINKEYS]) (Historic)
>>   o  Sender ID ([SENDERID]) (Experimental)
>>
>> I think the list misses DMARC, S/MIME and RRVS.  I also question the
>> description of ADSP and VBR as "common".  Additionally, ADSP is
>historic.
>>
>> Instead of getting into a bike shed discussion about what's common
>and
>how can
>> we tell, what about something like this:
>>
>>   At the time of publication of this document, the following are
>>   published, authentication methods:
>>
>>   o  Author Domain Signing Practices ([ADSP]) (Historic)
>>   o  Domain-based Message Authentication,  Reporting and Conformance
>([DMARC])
>>   o  DomainKeys ([DOMAINKEYS]) (Historic)
>>   o  DomainKeys Identified Mail Signatures ([DKIM])
>>   o  reverse IP address name validation ("iprev", defined in Section
>3)
>>   o  Require-Recipient-Valid-Since Header Field and SMTP Service
>Extension
>>        ([RRVS])
>>   o  SMTP Service Extension for Authentication ([AUTH])
>>   o  Sender ID ([SENDERID]) (Experimental)
>>   o  Sender Policy Framework ([SPF])
>>   o  S/MIME Signature Verification [SMIME-REG]
>>   o  Vouch By Reference ([VBR])
>>
>> None of these are marked deprecated in the registry:
>>
>> http://www.iana.org/assignments/email-auth/email-auth.xhtml
>
>Scott
>
>but if you were to look at the updated registry, as for example in the
>one I have prepared by hand (but which the IETF mailing system refuses
>to post - perhaps I  have upset the Privacy Police:-) then you will
>find
>that domainkeys and DKIM-ADSP are deprecated in the registry.
>
>Tom Petch
>
>> As a result, I don't think we should treat them differently in the
>text beyond
>> noting the status of the relevant RFC.
>>
>> Scott K
>>
>> _______________________________________________
>> apps-discuss mailing list
>> apps-discuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/apps-discuss

------4N62GNZQ9TOZ84RVPPHNU53YYFLVI8
Content-Type: text/html;
 charset=utf-8
Content-Transfer-Encoding: 8bit

Good point. Thanks. 



That still doesn't match the current text. 



Scott

On April 8, 2015 12:06:57 PM EDT, "t.petch" <ietfc@btconnect.com> wrote:


----- Original Message -----
From: "Scott Kitterman" <scott@kitterman.com>
To: <apps-discuss@ietf.org>
Sent: Wednesday, April 08, 2015 3:29 PM
 On Sunday, March 29, 2015 02:43:54 PM Alexey Melnikov wrote:
 This message is starting 3 weeks (*) Working Group Last Calls on
 draft-ietf-appsawg-rfc7001bis-05 (Message Header Field for
Indicating
 Message Authentication Status). The WGLC ends on
 April 19th.


 I've reviewed the document and believe it's essentially ready for
publication.
 I think there is a bit of editorial adjustment needed in the prose
about
 different a-r methods.

 Here's my list of A-R related RFCs:

 RFC 5451/7001 Message Header Field for Indicating Message
Authentication
 Status
 RFC 5617 DKIM/ADSP
 RFC 6008 DKIM signature identification (header.b)
 RFC 6212 Vouch By Reference (VBR)
 RFC 6577 Sender Policy Framework (SPF)
 RFC 7281 Authentication-Results Registration for S/MIME
 RFC 7293 The
Require-Recipient-Valid-Since Header Field
 RFC7489 DMARC

 Here's what the draft currently says about different methods:

   At the time of publication of this document, the following are
   published, domain-level email authentication methods in common use:

   o  Author Domain Signing Practices ([ADSP])
   o  SMTP Service Extension for Authentication ([AUTH])
   o  DomainKeys Identified Mail Signatures ([DKIM])
   o  Sender Policy Framework ([SPF])
   o  Vouch By Reference ([VBR])
   o  reverse IP address name validation ("iprev", defined in Section
3)

    In addition, the following are non-standard methods recognized by
    this specification that are no longer common:

   o  DomainKeys ([DOMAINKEYS]) (Historic)
   o  Sender ID ([SENDERID])
(Experimental)

 I think the list misses DMARC, S/MIME and RRVS.  I also question the
 description of ADSP and VBR as "common".  Additionally, ADSP is
historic.

 Instead of getting into a bike shed discussion about what's common and
how can
 we tell, what about something like this:

   At the time of publication of this document, the following are
   published, authentication methods:

   o  Author Domain Signing Practices ([ADSP]) (Historic)
   o  Domain-based Message Authentication,  Reporting and Conformance
([DMARC])
   o  DomainKeys ([DOMAINKEYS]) (Historic)
   o  DomainKeys Identified Mail Signatures ([DKIM])
   o  reverse IP address name validation ("iprev", defined in Section
3)
   o  Require-Recipient-Valid-Since Header Field and SMTP Service
Extension
        ([RRVS])
   o  SMTP Service Extension for Authentication ([AUTH])
   o  Sender ID ([SENDERID]) (Experimental)
   o  Sender Policy Framework ([SPF])
   o  S/MIME Signature Verification [SMIME-REG]
   o  Vouch By Reference ([VBR])

 None of these are marked deprecated in the registry:

 http://www.iana.org/assignments/email-auth/email-auth.xhtml

Scott

but if you were to look at the updated registry, as for example in the
one I have prepared by hand (but which the IETF mailing system refuses
to post - perhaps I  have upset the Privacy Police:-) then you will find
that domainkeys and DKIM-ADSP are deprecated in the registry.

Tom Petch

 As a result, I don't think we should treat them differently in the
text beyond
 noting the status of the relevant RFC.

 Scott K


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



------4N62GNZQ9TOZ84RVPPHNU53YYFLVI8--


From nobody Wed Apr  8 10:07:19 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A7791B34A4 for ; Wed,  8 Apr 2015 10:07:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gYbXRqo2aLYM for ; Wed,  8 Apr 2015 10:07:16 -0700 (PDT)
Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29CB31B3499 for ; Wed,  8 Apr 2015 10:07:06 -0700 (PDT)
Received: by widdi4 with SMTP id di4so62815930wid.0 for ; Wed, 08 Apr 2015 10:07:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RX+BOEPYhNOCkXl68LEeJOpY9lmY+3OYF+k4r0gJmHg=; b=UF0vrWyVi+NK8LnTdIQAhW88y00HCkVMpy9Vo96b2ihRE17Z1G5+JR1ELDnpLg7urq E2foi+ZJse0id9IrlXCGvRHf9hJTV9F5UG6yK2RlKrdvA7d+JBQ0IcydjRFTviM1vNvu 6B2LT9Xm0lTBwK7y9IjPjrn2a8BoevLukozJ9ZdmluU3iAti3kYWT9ATq9OsKgVDY85g Xr11cZl3RrJVB6SnSr3JJqzHq/6vpcjauu9PLid0Am5FWpaQd/Mq2YlXUxfvrkIdjyv+ AuY0Rgv5JGIJBYPGm/UKa56ENPcK66cJQAIQO9/jPy9IFGm5DFkIHjP+wqZGrS4BREDc XKSg==
MIME-Version: 1.0
X-Received: by 10.180.206.98 with SMTP id ln2mr16003160wic.94.1428512824508; Wed, 08 Apr 2015 10:07:04 -0700 (PDT)
Received: by 10.27.92.17 with HTTP; Wed, 8 Apr 2015 10:07:04 -0700 (PDT)
In-Reply-To: <2383989.tErOfD7dMh@kitterma-e6430>
References: <5518019A.7080508@isode.com> <2383989.tErOfD7dMh@kitterma-e6430>
Date: Wed, 8 Apr 2015 10:07:04 -0700
Message-ID: 
From: "Murray S. Kucherawy" 
To: Scott Kitterman 
Content-Type: multipart/alternative; boundary=001a11c381ce76466b0513398f25
Archived-At: 
Cc: IETF Apps Discuss 
Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-rfc7001bis-05
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 08 Apr 2015 17:07:18 -0000

--001a11c381ce76466b0513398f25
Content-Type: text/plain; charset=UTF-8

On Wed, Apr 8, 2015 at 7:29 AM, Scott Kitterman  wrote:

> Instead of getting into a bike shed discussion about what's common and how
> can
> we tell, what about something like this:
>
>   At the time of publication of this document, the following are
>   published, authentication methods:
>
>   o  Author Domain Signing Practices ([ADSP]) (Historic)
>   o  Domain-based Message Authentication,  Reporting and Conformance
> ([DMARC])
>   o  DomainKeys ([DOMAINKEYS]) (Historic)
>   o  DomainKeys Identified Mail Signatures ([DKIM])
>   o  reverse IP address name validation ("iprev", defined in Section 3)
>   o  Require-Recipient-Valid-Since Header Field and SMTP Service Extension
>        ([RRVS])
>   o  SMTP Service Extension for Authentication ([AUTH])
>   o  Sender ID ([SENDERID]) (Experimental)
>   o  Sender Policy Framework ([SPF])
>   o  S/MIME Signature Verification [SMIME-REG]
>   o  Vouch By Reference ([VBR])
>
> None of these are marked deprecated in the registry:
>
> http://www.iana.org/assignments/email-auth/email-auth.xhtml
>
> As a result, I don't think we should treat them differently in the text
> beyond
> noting the status of the relevant RFC.
>

Seems reasonable to me.  I'll do that in the next version, which I won't
submit until WGLC closes.

Tom is correct that the IANA Considerations section does update the
registries appropriately.

-MSK

--001a11c381ce76466b0513398f25
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On Wed, Apr 8, 2015 at 7:29 AM, Scott Kitterman <scott=
@kitterman.com> wrote:

Instead of getting into a bike shed discussion about what's common and =
how can

we tell, what about something like this:



=C2=A0 At the time of publication of this document, the following are

=C2=A0 published, authentication methods:



=C2=A0 o=C2=A0 Author Domain Signing Practices ([ADSP]) (Historic)

=C2=A0 o=C2=A0 Domain-based Message Authentication,=C2=A0 Reporting and Con=
formance ([DMARC])

=C2=A0 o=C2=A0 DomainKeys ([DOMAINKEYS]) (Historic)

=C2=A0 o=C2=A0 DomainKeys Identified Mail Signatures ([DKIM])

=C2=A0 o=C2=A0 reverse IP address name validation ("iprev", defin=
ed in Section 3)

=C2=A0 o=C2=A0 Require-Recipient-Valid-Since Header Field and SMTP Service =
Extension

=C2=A0 =C2=A0 =C2=A0 =C2=A0([RRVS])

=C2=A0 o=C2=A0 SMTP Service Extension for Authentication ([AUTH])

=C2=A0 o=C2=A0 Sender ID ([SENDERID]) (Experimental)

=C2=A0 o=C2=A0 Sender Policy Framework ([SPF])

=C2=A0 o=C2=A0 S/MIME Signature Verification [SMIME-REG]

=C2=A0 o=C2=A0 Vouch By Reference ([VBR])



None of these are marked deprecated in the registry:



http://www.iana.org/assignments/email-auth/email-auth.xhtml<=
/a>



As a result, I don't think we should treat them differently in the text=
 beyond

noting the status of the relevant RFC.



--001a11c381ce76466b0513398f25--


From nobody Wed Apr  8 10:52:22 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0C401A8860; Wed,  8 Apr 2015 10:52:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Npoyr4XOFKC4; Wed,  8 Apr 2015 10:52:15 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0688.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:688]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F7B31A879D; Wed,  8 Apr 2015 10:52:15 -0700 (PDT)
Received: from DM2PR02MB1322.namprd02.prod.outlook.com (25.161.142.21) by DM2PR02MB1324.namprd02.prod.outlook.com (25.161.142.23) with Microsoft SMTP Server (TLS) id 15.1.118.21; Wed, 8 Apr 2015 17:51:58 +0000
Received: from DM2PR02MB1322.namprd02.prod.outlook.com ([25.161.142.21]) by DM2PR02MB1322.namprd02.prod.outlook.com ([25.161.142.21]) with mapi id 15.01.0118.029; Wed, 8 Apr 2015 17:51:58 +0000
From: Larry Masinter 
To: Graham Klyne , Barry Leiba , Dave Thaler 
Thread-Topic: [apps-discuss] Ben Campbell's No Objection on draft-ietf-appsawg-uri-scheme-reg-05: (with COMMENT)
Thread-Index: AQHQcL4Bl1Ep8PUSLU6urm3BX87/sZ1CV/wAgAC47YCAACB1gP//wTUA
Date: Wed, 8 Apr 2015 17:51:58 +0000
Message-ID: <3461CD3A-84A7-48EB-9770-396AB5C3A1AC@adobe.com>
References: <20150406230346.17020.71285.idtracker@ietfa.amsl.com>   <55253CF9.7050206@ninebynine.org>
In-Reply-To: <55253CF9.7050206@ninebynine.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/15.8.0.150303
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [50.184.24.49]
authentication-results: ninebynine.org; dkim=none (message not signed) header.d=none;
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR02MB1324;
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10009020)(6009001)(230783001)(33656002)(62966003)(99286002)(82746002)(40100003)(76176999)(83506001)(86362001)(106116001)(77156002)(83716003)(87936001)(2656002)(2900100001)(46102003)(66066001)(2950100001)(2561002)(122556002)(102836002)(50986999)(54356999)(92566002)(36756003)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR02MB1324; H:DM2PR02MB1322.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:DM2PR02MB1324; BCL:0; PCL:0; RULEID:;  SRVR:DM2PR02MB1324; 
x-forefront-prvs: 0540846A1D
Content-Type: text/plain; charset="utf-8"
Content-ID: <5D991A6FD6CF114A9B030F248B4A144E@namprd02.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: adobe.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2015 17:51:58.5214 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR02MB1324
Archived-At: 
Cc: Ben Campbell , The IESG , "apps-discuss@ietf.org" , "appsawg-chairs@ietf.org" 
Subject: Re: [apps-discuss] Ben Campbell's No Objection on draft-ietf-appsawg-uri-scheme-reg-05: (with COMMENT)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 08 Apr 2015 17:52:17 -0000

R3JhaGFtIHByb3Bvc2VkOg0KDQo+IlRoZSByb2xlIG9mIHRoZSBkZXNpZ25hdGVkIGV4cGVydCBp
biB0aGUgcHJvY2VkdXJlIGZvciBwZXJtYW5lbnQgcmVnaXN0cmF0aW9ucyANCj5kZXNjcmliZWQg
aGVyZSBpcyB0byBlbnN1cmUgdGhhdCBub3JtYWwgSUVURiBvcGVuIHJldmlldyBwcm9jZXNzIGhh
cyBiZWVuIA0KPnByb3Blcmx5IGZvbGxvd2VkLCBhbmQgdG8gcmFpc2UgcG9zc2libGUgY29uY2Vy
bnMgYWJvdXQgd2lkZXIgaW1wbGljYXRpb25zIG9mIA0KPnByb3Bvc2FscyBmb3IgdGhlIHVzZSBh
bmQgZGVwbG95bWVudCBvZiBVUklzLiAgTm90aGluZyBpbiB0aGUgcHJvY2VkdXJlIGVtcG93ZXJz
IA0KPnRoZSBEZXNpZ25hdGVkIEV4cGVydCB0byBvdmVycmlkZSBwcm9wZXJseSBhcnJpdmVkLWF0
IElFVEYgb3Igd29ya2luZyBncm91cCANCj5jb25zZW5zdXMuIg0KDQpJIHRoaW5rIGlmIHRoZSBE
RSBmb3IgYSByZWdpc3RyYXRpb24gZG9lc27igJl0IGFncmVlIHRoYXQgYSBkb2N1bWVudCBtZWV0
cw0KdGhlIHJlcXVpcmVtZW50cyBmb3IgdGhhdCByZWdpc3RyYXRpb24sIHRoYXQgdGhlIERF4oCZ
cyBkaXNhZ3JlZW1lbnQNClNIT1VMRCBiZSBjb25zaWRlcmVkICBhcyBldmlkZW5jZSB0aGF0IHRo
ZXJlIGlzIG5vdCBJRVRGIGNvbnNlbnN1cywNCndoZXRoZXIgb3Igbm90IHRoZXJlIGlzIHdvcmtp
bmcgZ3JvdXAgY29uc2Vuc3VzLCBhdCBsZWFzdCBhcyBzZXJpb3VzDQphcyBJQU5BIG9yIFNFQ0RJ
UiBvciBPUFMgYXJlYSByZXZpZXcuDQoNCkdyYWhhbeKAmXMgd29yZGluZyBmb2N1c2VzIG9uIHRo
ZSBwcm9jZXNzL3Bvd2VyIGFzcGVjdCByYXRoZXIgdGhhbiB0aGUgdGVjaG5pY2FsLA0KYnV0IEkg
dGhpbmsgdGhlIHBhcmFncmFwaCBnaXZlcyB0aGUgaW1wcmVzc2lvbiB0aGF0IFdHIGNvbnNlbnN1
cw0KdHJ1bXBzIHN1Y2ggY29uc2lkZXJhdGlvbi4NCg0KSWYgYW4gUkZDIHNwZWNpZmllcyBhIG5l
dyBvciB1cGRhdGVkIElBTkEgcmVnaXN0cmF0aW9uLCB0aGVuIHRoYXQNCnNwZWMgc2hvdWxkIGJl
IGhlbGQgdG8gbWVldGluZyB0aG9zZSByZXF1aXJlbWVudHMsIGV2ZW4gd2hlbiB0aGUNCndvcmtp
bmcgZ3JvdXAgaGFzIChjaGFpci1kZWNsYXJlZCDigJxyb3VnaOKAnSkgY29uc2Vuc3VzIG9mIHRo
ZSANCndvcmtpbmcgZ3JvdXAgdGhhdCB0aGV5IGRvbuKAmXQgbmVlZCB0by4NCg0KDQoNCg==


From nobody Wed Apr  8 11:26:06 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 639361A8AC5; Wed,  8 Apr 2015 11:26:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uGn43rtCZENR; Wed,  8 Apr 2015 11:26:04 -0700 (PDT)
Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B75E1A8AC4; Wed,  8 Apr 2015 11:26:04 -0700 (PDT)
Received: by iedfl3 with SMTP id fl3so92170221ied.1; Wed, 08 Apr 2015 11:26:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=AqOrtMLwDtOd9ZmZ2Sd0XWJ4SCQeOYfCkWAGRHNBrfc=; b=L2Q8BT6ZLvUW/z3hPgf82T6NVzikiPK86DbH0zFzEp0L8HQfP96n5n9JNC/16p/j+F VV2256LOQ1Ip0EyQVxQmbthApRZ0neK54zeBW4R6ugZ0Pw3Y1eZPgAGW3j6AjUEVdyrZ LjBzmeqz8Fp8zMmnN0FYGUi3+K4TUBn/ahYCRuWKgLoiEOw9RBepCCLrZCSCaaq1jyqP 2hc6O++22IxkaQ7XJ8uf3m438F55eCTdrADlhdWCGP7ZnVo/6y0bVhQp+3VYc/3GOAut Uov3uDrOHuxOvrXILv58gUfTcPssEsKwg3OMVPjBU/4miO/01PamqHmUVYcm+2ZccneC dGew==
MIME-Version: 1.0
X-Received: by 10.43.55.12 with SMTP id vw12mr34392138icb.30.1428517563959; Wed, 08 Apr 2015 11:26:03 -0700 (PDT)
Sender: barryleiba@gmail.com
Received: by 10.107.7.130 with HTTP; Wed, 8 Apr 2015 11:26:03 -0700 (PDT)
In-Reply-To: <3461CD3A-84A7-48EB-9770-396AB5C3A1AC@adobe.com>
References: <20150406230346.17020.71285.idtracker@ietfa.amsl.com>   <55253CF9.7050206@ninebynine.org> <3461CD3A-84A7-48EB-9770-396AB5C3A1AC@adobe.com>
Date: Wed, 8 Apr 2015 14:26:03 -0400
X-Google-Sender-Auth: va36cC2d7blqCY8xLAD_835Zq2E
Message-ID: 
From: Barry Leiba 
To: Larry Masinter 
Content-Type: text/plain; charset=ISO-8859-1
Archived-At: 
Cc: Ben Campbell , "apps-discuss@ietf.org" , "appsawg-chairs@ietf.org" , Graham Klyne , The IESG 
Subject: Re: [apps-discuss] Ben Campbell's No Objection on draft-ietf-appsawg-uri-scheme-reg-05: (with COMMENT)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 08 Apr 2015 18:26:05 -0000

>>"The role of the designated expert in the procedure for permanent registrations
>>described here is to ensure that normal IETF open review process has been
>>properly followed, and to raise possible concerns about wider implications of
>>proposals for the use and deployment of URIs.  Nothing in the procedure empowers
>>the Designated Expert to override properly arrived-at IETF or working group
>>consensus."
>
> I think if the DE for a registration doesn't agree that a document meets
> the requirements for that registration, that the DE's disagreement
> SHOULD be considered  as evidence that there is not IETF consensus,
> whether or not there is working group consensus, at least as serious
> as IANA or SECDIR or OPS area review.
>
> Graham's wording focuses on the process/power aspect rather than the technical,
> but I think the paragraph gives the impression that WG consensus
> trumps such consideration.

Not at all.  What it means is that the individual who serves as DE
gives his input as an individual, and it's considered as part of the
consensus process.  And that's separate from his role as DE.

This is a similar situation to the ports registry and the media types
registry, except that in those cases the DE isn't even consulted for
Standards Track RFCs.  The DEs are just expected to participate as
individuals.

Barry


From nobody Wed Apr  8 11:56:04 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98AA91B3505 for ; Wed,  8 Apr 2015 11:56:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.902
X-Spam-Level: 
X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26cTAFU4e1ic for ; Wed,  8 Apr 2015 11:56:00 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0739.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::739]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D64321B3503 for ; Wed,  8 Apr 2015 11:55:59 -0700 (PDT)
Received: from BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) by BY2PR03MB410.namprd03.prod.outlook.com (10.141.141.16) with Microsoft SMTP Server (TLS) id 15.1.136.17; Wed, 8 Apr 2015 18:55:38 +0000
Received: from BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) by BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) with mapi id 15.01.0130.020; Wed, 8 Apr 2015 18:55:38 +0000
From: Dave Thaler 
To: Graham Klyne , "apps-discuss@ietf.org" 
Thread-Topic: [apps-discuss] FW: New Version Notification - draft-ietf-appsawg-uri-scheme-reg-05.txt
Thread-Index: AQHQalu7kv9nwJjIwUqSz15OYYohZp0250MAgAB9q4CAAJ9agIABdmaAgACP/QCAAwN1gIAGdg6A
Date: Wed, 8 Apr 2015 18:55:38 +0000
Message-ID: 
References:  <551AE31E.1070009@ninebynine.org> <306B3AB5-02E3-4958-9D05-4E4FF82AD114@isode.com> <266EAB2393341CF1F491F327@JcK-HP8200.jck.com> <551D0C47.5090603@ninebynine.org>  <55200C35.1000708@ninebynine.org>
In-Reply-To: <55200C35.1000708@ninebynine.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: ninebynine.org; dkim=none (message not signed) header.d=none;
x-originating-ip: [2001:4898:80e0:ed43::3]
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB410;
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(24454002)(51704005)(230783001)(107886001)(106116001)(74316001)(76576001)(92566002)(122556002)(99286002)(40100003)(54356999)(76176999)(50986999)(86612001)(86362001)(2900100001)(87936001)(2656002)(2950100001)(2501003)(77156002)(77096005)(561944003)(62966003)(46102003)(33656002)(102836002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB410; H:BY2PR03MB412.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:BY2PR03MB410; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB410; 
x-forefront-prvs: 0540846A1D
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.onmicrosoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2015 18:55:38.2467 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB410
Archived-At: 
Subject: Re: [apps-discuss] FW: New Version Notification - draft-ietf-appsawg-uri-scheme-reg-05.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 08 Apr 2015 18:56:02 -0000

Graham wrote:=20
> So my suggestion would be, rather than to actually change the procedure t=
o
> introduce formally defined lines of reporting, to provide some guidelines=
 for=20
> anticipated standards submissions; e.g.
>
> "If standardization is anticipated, the working group or individuals conc=
erned=20
> are advised to submit an early permanent registration request, rather tha=
n
> waiting until the standardization process has run its course.  IANA will =
pass=20
> this to the DE who may recommend provisional registration until the speci=
fication
> is approved as a standard.  This will provide opportunity for feedback wh=
ile
> specification development and review is still active, and the
> submitter(s) are still in a position to respond to any issues that might =
be raised.
> If and when the specification is approved as a standard, the submitters s=
hould
> submit a request to change the registration status to permanent."
>
> I think something like this can work for any standardization organization=
 or=20
> process and, in conjunction with the previous text suggested, positions t=
he
> DE as part of the review process rather than a gatekeeper with power of v=
eto over the standards process.
>=20
> (I note that, currently, there is an arrangement that IANA will send me a=
n early=20
> review request when an IETF  document goes to last call with a URI scheme=
=20
> registration request, so that my comments can be fed into the last call d=
iscussions.
> But this wouldn't work so easily for other standards organizations.)

That seems like fine advice, and since it's not mandatory and roughly match=
es
how things work now for IETF standards as you've explained, I've accepted
this text into -06.

>> In some of those cases, especially if the DE concludes that the=20
>> registration proposal is a hopeless mess, a "report" is going to be=20
>> precisely what is needed.  My hope is that we can avoid any tendencies=20
>> to overspecify that but the motivation is the same as it was with=20
>> media types: if a namespace registration shows up that involves highly=20
>> technical matters that are under the control of, or standardized by,=20
>> some competent and recognized standards body or scientific group,=20
>> having the IETF demonstrate community ignorance by debating the issues=20
>> is not helpful to anyone.
>
>That's pretty much what happens now.  Maybe there's scope for some additio=
nal guidance, e.g.
>
> "If the DE feels unable to recommend acceptance of a requested permanent=
=20
> registration, they should respond to IANA stating this, along with their =
reasons=20
> and, if possible, what changes the submitter might be able offer to impro=
ve the
> submission, which IANA in term will relay to the submitter.  In cases whe=
re some
> discussion seems needed, the DE can also respond directly to the contact =
named
> in the submission (also advising IANA of this).  In such situations, the =
scheme may
> be registered provisionally while discussions are in progress."

My opinion is that the above is not required given the other two paragraphs
you suggested, i.e. the one quoted farther above, plus your earlier suggest=
ion of
"The role of the designated expert in the procedure for permanent registrat=
ions=20
described here is to ensure that normal IETF open review process has been p=
roperly=20
followed, and to raise possible concerns about wider implications of propos=
als for the
use and deployment of URIs.  Nothing in the procedure empowers the Designat=
ed=20
Expert to override properly arrived-at IETF or working group consensus."

Anything beyond those is really no different from any other Expert Review r=
egistry,
and further details are, in my view, best done by a separate registry-agnos=
tic=20
document about Expert Reviews, e.g. a new draft titled, say,
"Guidelines for IANA Designated Experts".

Dave


From nobody Wed Apr  8 12:05:34 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A14DF1B351A for ; Wed,  8 Apr 2015 12:05:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.902
X-Spam-Level: 
X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDvDHNQWzfTT for ; Wed,  8 Apr 2015 12:05:31 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0710.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:710]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F0451B3516 for ; Wed,  8 Apr 2015 12:05:28 -0700 (PDT)
Received: from BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) by BY2PR03MB409.namprd03.prod.outlook.com (10.141.141.11) with Microsoft SMTP Server (TLS) id 15.1.136.17; Wed, 8 Apr 2015 19:05:07 +0000
Received: from BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) by BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) with mapi id 15.01.0130.020; Wed, 8 Apr 2015 19:05:07 +0000
From: Dave Thaler 
To: Dave Thaler , Graham Klyne , "apps-discuss@ietf.org" 
Thread-Topic: [apps-discuss] FW: New Version Notification - draft-ietf-appsawg-uri-scheme-reg-05.txt
Thread-Index: AQHQalu7kv9nwJjIwUqSz15OYYohZp0250MAgAB9q4CAAJ9agIABdmaAgACP/QCAAwN1gIAGdg6AgAAEgKA=
Date: Wed, 8 Apr 2015 19:05:07 +0000
Message-ID: 
References:  <551AE31E.1070009@ninebynine.org> <306B3AB5-02E3-4958-9D05-4E4FF82AD114@isode.com> <266EAB2393341CF1F491F327@JcK-HP8200.jck.com> <551D0C47.5090603@ninebynine.org>  <55200C35.1000708@ninebynine.org> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: microsoft.com; dkim=none (message not signed) header.d=none;
x-originating-ip: [2001:4898:80e0:ed43::3]
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB409;
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(24454002)(230783001)(106116001)(76576001)(122556002)(74316001)(40100003)(2900100001)(2950100001)(92566002)(99286002)(107886001)(86362001)(77156002)(33656002)(62966003)(86612001)(2501003)(2656002)(46102003)(2561002)(102836002)(50986999)(76176999)(87936001)(54356999)(77096005); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB409; H:BY2PR03MB412.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:BY2PR03MB409; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB409; 
x-forefront-prvs: 0540846A1D
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.onmicrosoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2015 19:05:07.8137 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB409
Archived-At: 
Subject: Re: [apps-discuss] FW: New Version Notification - draft-ietf-appsawg-uri-scheme-reg-05.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 08 Apr 2015 19:05:32 -0000

Graham Klyne wrote:
> "The role of the designated expert in the procedure for permanent registr=
ations=20
> described here is to ensure that normal IETF open review process has been=
=20
> properly followed, and to raise possible concerns about wider implication=
s of=20
> proposals for the use and deployment of URIs.  Nothing in the procedure=20
> empowers the Designated Expert to override properly arrived-at IETF or wo=
rking group consensus."

Accepted in -06 except
 s/IETF open review process/open review process/
since a permanent registration might come from W3C or another SDO.

Dave


From nobody Wed Apr  8 12:05:49 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2C161B3527; Wed,  8 Apr 2015 12:05:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TXlqX5Z-Eekz; Wed,  8 Apr 2015 12:05:45 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AF3B21B3530; Wed,  8 Apr 2015 12:05:39 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 5.13.0.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150408190539.26541.68570.idtracker@ietfa.amsl.com>
Date: Wed, 08 Apr 2015 12:05:39 -0700
Archived-At: 
Cc: apps-discuss@ietf.org
Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-uri-scheme-reg-06.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Apr 2015 19:05:46 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Applications Area Working Group Working Group of the IETF.

        Title           : Guidelines and Registration Procedures for URI Schemes
        Authors         : Dave Thaler
                          Tony Hansen
                          Ted Hardie
                          Larry Masinter
	Filename        : draft-ietf-appsawg-uri-scheme-reg-06.txt
	Pages           : 20
	Date            : 2015-04-08

Abstract:
   This document updates the guidelines and recommendations, as well as
   the IANA registration processes, for the definition of Uniform
   Resource Identifier (URI) schemes.  It obsoletes RFC 4395.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-appsawg-uri-scheme-reg/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-appsawg-uri-scheme-reg-06

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-uri-scheme-reg-06


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Wed Apr  8 12:05:51 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3CA21B3533; Wed,  8 Apr 2015 12:05:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iXVolaehXSPk; Wed,  8 Apr 2015 12:05:46 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D0C761B3534; Wed,  8 Apr 2015 12:05:39 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: , , , 
X-Test-IDTracker: no
X-IETF-IDTracker: 5.13.0.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150408190539.26541.92252.idtracker@ietfa.amsl.com>
Date: Wed, 08 Apr 2015 12:05:39 -0700
Archived-At: 
Subject: [apps-discuss] New Version Notification - draft-ietf-appsawg-uri-scheme-reg-06.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Apr 2015 19:05:48 -0000

A new version (-06) has been submitted for draft-ietf-appsawg-uri-scheme-reg:
http://www.ietf.org/internet-drafts/draft-ietf-appsawg-uri-scheme-reg-06.txt


The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-appsawg-uri-scheme-reg/

Diff from previous version:
http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-uri-scheme-reg-06

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

IETF Secretariat.


From nobody Wed Apr  8 12:28:32 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BB661B3530; Wed,  8 Apr 2015 12:28:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k-CtEdm6VN2E; Wed,  8 Apr 2015 12:28:29 -0700 (PDT)
Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58BB11A8ABB; Wed,  8 Apr 2015 12:28:29 -0700 (PDT)
Received: by iebmp1 with SMTP id mp1so83313436ieb.0; Wed, 08 Apr 2015 12:28:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=4fz9HpfDWsDOUBs8hbA8csU2F6wyIsX+1VM7TBpuVss=; b=dFyWcNVIcsvelHBqIDOc4KBiqVRbsx/VcXjGB8Zuc9OE0DR+17o2zE9SODbO4buxC5 ZjbH1vhn+s8VWYLyhUmc3SjB0kyVfns20+atG1z4kCB+IspN4OEEqCLbj4P+qRPRznLr Zy37cfTb5HX14wdvngAOqUcNw0tLwQptW1Bde78WLnZ8LrsnuqWrZ3CuaP1/mcUWJ65T Ci1OWPwyHrMI9QkTRPvos78jf8ZKOCY6yqQRqJ2e7gJPDC1Yq3YJYqksBa9nKsKZ/j/X Ao5EOCn+VQkkBKZYboaJZ8439PfKUXiQqpS3941aVZvrQYm/je1ox4yVtvC7WGFHffo2 C4nA==
MIME-Version: 1.0
X-Received: by 10.42.23.17 with SMTP id q17mr18431976icb.4.1428521308751; Wed, 08 Apr 2015 12:28:28 -0700 (PDT)
Sender: barryleiba@gmail.com
Received: by 10.107.7.130 with HTTP; Wed, 8 Apr 2015 12:28:28 -0700 (PDT)
In-Reply-To: <2E49FA112B054FFAED69D8A1@JcK-HP8200.jck.com>
References: <2E49FA112B054FFAED69D8A1@JcK-HP8200.jck.com>
Date: Wed, 8 Apr 2015 15:28:28 -0400
X-Google-Sender-Auth: nAsYz-x5lfxoJJKHULrU-ofdqco
Message-ID: 
From: Barry Leiba 
To: John C Klensin 
Content-Type: text/plain; charset=ISO-8859-1
Archived-At: 
Cc: "draft-ietf-appsawg-uri-scheme-reg.all@ietf.org" , IESG , Apps Discuss 
Subject: Re: [apps-discuss] Retroactive application of draft-ietf-appsawg-uri-scheme-reg - comprehensive review
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 08 Apr 2015 19:28:30 -0000

> I've been thinking more about Larry's claim [1] that
> draft-ietf-appsawg-uri-scheme-reg (referred to as "4395bis"
> below) constrains work going on in the URNBIS WG and, in
> particular, draft-ietf-urnbis-rfc2141bis-urn and have been
> studying both documents.

John (and others), please check the -06 version, looking especially at
the new last paragraph of Section 7.1.  I believe that takes care of
this case by codifying how Graham already handles registration
requests that come from IETF working groups.

For the specific case of urnbis, consensus on 2141bis would allow it
to specify how urn: registrations work, independent of what's said
here.  I would say that if 2141bis specifically contradicts something
here, it should explicitly call that out, to be absolutely clear about
it.

Barry


From nobody Wed Apr  8 12:28:36 2015
Return-Path: 
X-Original-To: expand-draft-ietf-appsawg-uri-scheme-reg.all@virtual.ietf.org
Delivered-To: apps-discuss@ietfa.amsl.com
Received: by ietfa.amsl.com (Postfix, from userid 65534) id BC0D41B3539; Wed,  8 Apr 2015 12:28:30 -0700 (PDT)
X-Original-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com
Delivered-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BB661B3530; Wed,  8 Apr 2015 12:28:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k-CtEdm6VN2E; Wed,  8 Apr 2015 12:28:29 -0700 (PDT)
Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58BB11A8ABB; Wed,  8 Apr 2015 12:28:29 -0700 (PDT)
Received: by iebmp1 with SMTP id mp1so83313436ieb.0; Wed, 08 Apr 2015 12:28:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=4fz9HpfDWsDOUBs8hbA8csU2F6wyIsX+1VM7TBpuVss=; b=dFyWcNVIcsvelHBqIDOc4KBiqVRbsx/VcXjGB8Zuc9OE0DR+17o2zE9SODbO4buxC5 ZjbH1vhn+s8VWYLyhUmc3SjB0kyVfns20+atG1z4kCB+IspN4OEEqCLbj4P+qRPRznLr Zy37cfTb5HX14wdvngAOqUcNw0tLwQptW1Bde78WLnZ8LrsnuqWrZ3CuaP1/mcUWJ65T Ci1OWPwyHrMI9QkTRPvos78jf8ZKOCY6yqQRqJ2e7gJPDC1Yq3YJYqksBa9nKsKZ/j/X Ao5EOCn+VQkkBKZYboaJZ8439PfKUXiQqpS3941aVZvrQYm/je1ox4yVtvC7WGFHffo2 C4nA==
MIME-Version: 1.0
X-Received: by 10.42.23.17 with SMTP id q17mr18431976icb.4.1428521308751; Wed, 08 Apr 2015 12:28:28 -0700 (PDT)
Sender: barryleiba@gmail.com
Received: by 10.107.7.130 with HTTP; Wed, 8 Apr 2015 12:28:28 -0700 (PDT)
In-Reply-To: <2E49FA112B054FFAED69D8A1@JcK-HP8200.jck.com>
References: <2E49FA112B054FFAED69D8A1@JcK-HP8200.jck.com>
Date: Wed, 8 Apr 2015 15:28:28 -0400
X-Google-Sender-Auth: nAsYz-x5lfxoJJKHULrU-ofdqco
Message-ID: 
From: Barry Leiba 
To: John C Klensin 
Content-Type: text/plain; charset=ISO-8859-1
Archived-At: 
Cc: "draft-ietf-appsawg-uri-scheme-reg.all@ietf.org" , IESG , Apps Discuss 
Subject: Re: [apps-discuss] Retroactive application of draft-ietf-appsawg-uri-scheme-reg - comprehensive review
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 08 Apr 2015 19:28:30 -0000

> I've been thinking more about Larry's claim [1] that
> draft-ietf-appsawg-uri-scheme-reg (referred to as "4395bis"
> below) constrains work going on in the URNBIS WG and, in
> particular, draft-ietf-urnbis-rfc2141bis-urn and have been
> studying both documents.

John (and others), please check the -06 version, looking especially at
the new last paragraph of Section 7.1.  I believe that takes care of
this case by codifying how Graham already handles registration
requests that come from IETF working groups.

For the specific case of urnbis, consensus on 2141bis would allow it
to specify how urn: registrations work, independent of what's said
here.  I would say that if 2141bis specifically contradicts something
here, it should explicitly call that out, to be absolutely clear about
it.

Barry


From nobody Wed Apr  8 14:32:46 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F9D01B36DD for ; Wed,  8 Apr 2015 14:32:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level: 
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5PZsdYYqi0V3 for ; Wed,  8 Apr 2015 14:32:43 -0700 (PDT)
Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D58F1B36E1 for ; Wed,  8 Apr 2015 14:32:42 -0700 (PDT)
Received: from [100.80.113.105] (121.sub-70-208-142.myvzw.com [70.208.142.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 8AC0EC40243; Wed,  8 Apr 2015 16:32:40 -0500 (CDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1428528761; bh=jv0jP7rU8M+udgkx4r/6t7G8Qb67hwbn2xrKOle+CNc=; h=In-Reply-To:References:Subject:From:Date:To:From; b=rsXml3dBWooeiYXw0/i5EIqg/MxHFUhEhglHFKt1P3ZlM8u2+h8kmbGB8RMd/1gPy qFlQPJ9eK8XV8iFTlDLyPRlLEudpeUUj1NGWNCaNQz025O2Lcp4ShjjjP1gjzfcfOl /yg9tpIZHvsQYHl+4ii5BXwjqePXpFlNzFykruqE=
User-Agent: K-9 Mail for Android
In-Reply-To: 
References: <5518019A.7080508@isode.com> <2383989.tErOfD7dMh@kitterma-e6430> 
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8
From: Scott Kitterman 
Date: Wed, 08 Apr 2015 17:32:33 -0400
To: IETF Apps Discuss 
Message-ID: 
Archived-At: 
Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-rfc7001bis-05
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 08 Apr 2015 21:32:45 -0000

On April 8, 2015 1:07:04 PM EDT, "Murray S. Kucherawy"  wrote:
>On Wed, Apr 8, 2015 at 7:29 AM, Scott Kitterman 
>wrote:
>
>> Instead of getting into a bike shed discussion about what's common
>and how
>> can
>> we tell, what about something like this:
>>
>>   At the time of publication of this document, the following are
>>   published, authentication methods:
>>
>>   o  Author Domain Signing Practices ([ADSP]) (Historic)
>>   o  Domain-based Message Authentication,  Reporting and Conformance
>> ([DMARC])
>>   o  DomainKeys ([DOMAINKEYS]) (Historic)
>>   o  DomainKeys Identified Mail Signatures ([DKIM])
>>   o  reverse IP address name validation ("iprev", defined in Section
>3)
>>   o  Require-Recipient-Valid-Since Header Field and SMTP Service
>Extension
>>        ([RRVS])
>>   o  SMTP Service Extension for Authentication ([AUTH])
>>   o  Sender ID ([SENDERID]) (Experimental)
>>   o  Sender Policy Framework ([SPF])
>>   o  S/MIME Signature Verification [SMIME-REG]
>>   o  Vouch By Reference ([VBR])
>>
>> None of these are marked deprecated in the registry:
>>
>> http://www.iana.org/assignments/email-auth/email-auth.xhtml
>>
>> As a result, I don't think we should treat them differently in the
>text
>> beyond
>> noting the status of the relevant RFC.
>>
>
>Seems reasonable to me.  I'll do that in the next version, which I
>won't
>submit until WGLC closes.
>
>Tom is correct that the IANA Considerations section does update the
>registries appropriately.

Great. Given that, it might also warrant a sentence along the lines of "Methods marked as historic are deprecated in this update".

Scott K


From nobody Wed Apr  8 15:20:45 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA211A9060 for ; Wed,  8 Apr 2015 15:20:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N6iiAjq0S-qg for ; Wed,  8 Apr 2015 15:20:42 -0700 (PDT)
Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54B8D1A905C for ; Wed,  8 Apr 2015 15:20:41 -0700 (PDT)
Received: by widdi4 with SMTP id di4so71531824wid.0 for ; Wed, 08 Apr 2015 15:20:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+dr7DAQYmfxK77nvfdW7BG7s9ohwOOhA4b2Xv9imyI8=; b=pzMAJHEtdSpNLRdLxHYN0wXiqta+tnERnK/HwyLK77ZBc1jGyvDxRIne0YqDHbhJj/ Q7MuZy7oU8tnq3LTdPAMA+PgpWD2ckZQjXEA+Vo4mBdtmUBQNrV18F6esQ0sGiGIBq8K 3Jpozz8RZ0W46F9mhLxSUyfVvEdJj2u5Od7WndMevpHq+oCAiSLbNGlbwaU8XIv6qrsV S0t//kZThIn75gH9PsGCo/qE+EaZDygXdDktQmNUSgVsEi+7mCDB9LkHlFFeDE6Ne2XW eGMHpIkDw5KGOOSfGhwAQXpZe7peyDmxgzcgR/HqyhXBjrUJteOGF7l/+IHUoICZuqs2 vUPA==
MIME-Version: 1.0
X-Received: by 10.180.77.166 with SMTP id t6mr791108wiw.52.1428531640129; Wed, 08 Apr 2015 15:20:40 -0700 (PDT)
Received: by 10.27.92.17 with HTTP; Wed, 8 Apr 2015 15:20:39 -0700 (PDT)
In-Reply-To: 
References: <5518019A.7080508@isode.com> <2383989.tErOfD7dMh@kitterma-e6430>  
Date: Wed, 8 Apr 2015 15:20:39 -0700
Message-ID: 
From: "Murray S. Kucherawy" 
To: Scott Kitterman 
Content-Type: multipart/alternative; boundary=f46d043d645ff5dc5e05133df076
Archived-At: 
Cc: IETF Apps Discuss 
Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-rfc7001bis-05
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 08 Apr 2015 22:20:43 -0000

--f46d043d645ff5dc5e05133df076
Content-Type: text/plain; charset=UTF-8

On Wed, Apr 8, 2015 at 2:32 PM, Scott Kitterman  wrote:

> >Seems reasonable to me.  I'll do that in the next version, which I
> >won't
> >submit until WGLC closes.
> >
> >Tom is correct that the IANA Considerations section does update the
> >registries appropriately.
>
> Great. Given that, it might also warrant a sentence along the lines of
> "Methods marked as historic are deprecated in this update".
>

I'll say something more comprehensive, basically a forward reference to
IANA Considerations.

-MSK

--f46d043d645ff5dc5e05133df076
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On Wed, Apr 8, 2015 at 2:32 PM, Scott Kitterman <scott=
@kitterman.com> wrote:
>Seems reasonable to me.=C2=A0 I'll do that in the ne=
xt version, which I

>won't

>submit until WGLC closes.

>

>Tom is correct that the IANA Considerations section does update the

>registries appropriately.




Great. Given that, it might also warrant a sentence along the l=
ines of "Methods marked as historic are deprecated in this update"=
;.

I'll say something more comprehe=
nsive, basically a forward reference to IANA Considerations.

<=
div>-MSK


--f46d043d645ff5dc5e05133df076--


From nobody Thu Apr  9 02:07:08 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03C7E1B29C8 for ; Thu,  9 Apr 2015 02:07:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KBy30HKrl8WH for ; Thu,  9 Apr 2015 02:07:04 -0700 (PDT)
Received: from relay15.mail.ox.ac.uk (relay15.mail.ox.ac.uk [163.1.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id 12FF41B29C2 for ; Thu,  9 Apr 2015 02:07:03 -0700 (PDT)
Received: from smtp5.mail.ox.ac.uk ([163.1.2.207]) by relay15.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1Yg8QQ-0004nq-nz; Thu, 09 Apr 2015 10:07:02 +0100
Received: from host109-152-232-46.range109-152.btcentralplus.com ([109.152.232.46] helo=cheery.atuin.ninebynine.org) by smtp5.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Yg8QQ-00061f-HQ; Thu, 09 Apr 2015 10:07:02 +0100
Message-ID: <55264134.5070302@ninebynine.org>
Date: Thu, 09 Apr 2015 10:07:00 +0100
From: Graham Klyne 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Dave Thaler ,  "apps-discuss@ietf.org" 
References:  <551AE31E.1070009@ninebynine.org> <306B3AB5-02E3-4958-9D05-4E4FF82AD114@isode.com> <266EAB2393341CF1F491F327@JcK-HP8200.jck.com> <551D0C47.5090603@ninebynine.org>  <55200C35.1000708@ninebynine.org> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Oxford-Username: zool0635
Archived-At: 
Subject: Re: [apps-discuss] FW: New Version Notification - draft-ietf-appsawg-uri-scheme-reg-05.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 09 Apr 2015 09:07:07 -0000

(Small comment below.  In summary: +1.)

On 08/04/2015 19:55, Dave Thaler wrote:
> Graham wrote:
>> So my suggestion would be, rather than to actually change the procedure to
>> introduce formally defined lines of reporting, to provide some guidelines for
>> anticipated standards submissions; e.g.
>>
>> "If standardization is anticipated, the working group or individuals concerned
>> are advised to submit an early permanent registration request, rather than
>> waiting until the standardization process has run its course.  IANA will pass
>> this to the DE who may recommend provisional registration until the specification
>> is approved as a standard.  This will provide opportunity for feedback while
>> specification development and review is still active, and the
>> submitter(s) are still in a position to respond to any issues that might be raised.
>> If and when the specification is approved as a standard, the submitters should
>> submit a request to change the registration status to permanent."
>>
>> I think something like this can work for any standardization organization or
>> process and, in conjunction with the previous text suggested, positions the
>> DE as part of the review process rather than a gatekeeper with power of veto over the standards process.
>>
>> (I note that, currently, there is an arrangement that IANA will send me an early
>> review request when an IETF  document goes to last call with a URI scheme
>> registration request, so that my comments can be fed into the last call discussions.
>> But this wouldn't work so easily for other standards organizations.)
>
> That seems like fine advice, and since it's not mandatory and roughly matches
> how things work now for IETF standards as you've explained, I've accepted
> this text into -06.
>
>>> In some of those cases, especially if the DE concludes that the
>>> registration proposal is a hopeless mess, a "report" is going to be
>>> precisely what is needed.  My hope is that we can avoid any tendencies
>>> to overspecify that but the motivation is the same as it was with
>>> media types: if a namespace registration shows up that involves highly
>>> technical matters that are under the control of, or standardized by,
>>> some competent and recognized standards body or scientific group,
>>> having the IETF demonstrate community ignorance by debating the issues
>>> is not helpful to anyone.
>>
>> That's pretty much what happens now.  Maybe there's scope for some additional guidance, e.g.
>>
>> "If the DE feels unable to recommend acceptance of a requested permanent
>> registration, they should respond to IANA stating this, along with their reasons
>> and, if possible, what changes the submitter might be able offer to improve the
>> submission, which IANA in term will relay to the submitter.  In cases where some
>> discussion seems needed, the DE can also respond directly to the contact named
>> in the submission (also advising IANA of this).  In such situations, the scheme may
>> be registered provisionally while discussions are in progress."
>
> My opinion is that the above is not required given the other two paragraphs
> you suggested, i.e. the one quoted farther above, plus your earlier suggestion of
> "The role of the designated expert in the procedure for permanent registrations
> described here is to ensure that normal IETF open review process has been properly
> followed, and to raise possible concerns about wider implications of proposals for the
> use and deployment of URIs.  Nothing in the procedure empowers the Designated
> Expert to override properly arrived-at IETF or working group consensus."
>
> Anything beyond those is really no different from any other Expert Review registry,
> and further details are, in my view, best done by a separate registry-agnostic
> document about Expert Reviews, e.g. a new draft titled, say,
> "Guidelines for IANA Designated Experts".

I agree that's pretty much redundant in light of the other comments.  I was 
responding point-by-point to what I felt were legitimate observations, and 
realized at the time I was probably repeating myself somewhat.

#g
--


From nobody Thu Apr  9 04:52:55 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E4DD1A0371 for ; Thu,  9 Apr 2015 04:52:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VHnRt9yxL0H4 for ; Thu,  9 Apr 2015 04:52:50 -0700 (PDT)
Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0788.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::788]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26E041A020B for ; Thu,  9 Apr 2015 04:52:50 -0700 (PDT)
Received: from pc6 (81.151.162.168) by AMSPR07MB049.eurprd07.prod.outlook.com (10.242.81.11) with Microsoft SMTP Server (TLS) id 15.1.125.19; Thu, 9 Apr 2015 11:26:59 +0000
Message-ID: <005901d072b7$ee4930a0$4001a8c0@gateway.2wire.net>
From: t.petch 
To: Dave Thaler 
References: <550164DD.6020509@it.aoyama.ac.jp>  <080D2D237EF9714533B15BDB@JcK-HP8200.jck.com>
Date: Thu, 9 Apr 2015 12:25:30 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [81.151.162.168]
X-ClientProxiedBy: AM3PR01CA035.eurprd01.prod.exchangelabs.com (10.141.191.25) To AMSPR07MB049.eurprd07.prod.outlook.com (10.242.81.11)
Authentication-Results: microsoft.com; dkim=none (message not signed) header.d=none;
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB049;
X-Forefront-Antispam-Report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(1511001)(66066001)(62236002)(50226001)(40100003)(44736004)(47776003)(62966003)(92566002)(44716002)(23756003)(77096005)(14496001)(50466002)(46102003)(122386002)(61296003)(86362001)(42186005)(116806002)(230783001)(50986999)(33646002)(81686999)(81816999)(77156002)(76176999)(87976001)(110136001)(229853001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMSPR07MB049; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; 
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:AMSPR07MB049; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB049; 
X-Forefront-PRVS: 0541031FF6
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Apr 2015 11:26:59.1379 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB049
Archived-At: 
Cc: apps-discuss@ietf.org, Larry Masinter 
Subject: [apps-discuss] Last Call:  (Guidelines and Registration Procedures for URI Schemes) to Best Current Practice
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 09 Apr 2015 11:52:52 -0000

One thought has been bugging me on this on which I have belatedly done
my homework.

How do IRTF documents fit into this?

Over the past few years, the processes for the publication of RFC have
been revised and the procedures for IRTF (and IAB and Individual
Submission) documents have been formalised.

Thus RFC5226 or draft-leiba-cotton sort of imply that they are for IETF
stream documents only whereas IRTF RFC can and do have IANA
Considerations. Both leiba-cotton and this I-D make reference to the
IESG as the place to go for resolution of uncertainties yet the IESG has
no such role for IRTF RFC apart from establishing that there is no
conflict with the work of the IETF - it is nowadays up to the IRSG to
resolve any issues.

And all the talk about Designated Experts and Expert Review refers to
the role of the IESG as being in charge, no mention of the IRSG.

So if an IRTF I-D asks for permanent registration, the IESG sees no
conflict with the work of the IETF but the Designated Expert is unhappy,
where does this go next?  IESG? IRSG? IAB?


Tom Petch


From nobody Thu Apr  9 04:52:56 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15B4C1A0371 for ; Thu,  9 Apr 2015 04:52:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bGmhf0u08eoZ for ; Thu,  9 Apr 2015 04:52:51 -0700 (PDT)
Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0788.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::788]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A44821A0369 for ; Thu,  9 Apr 2015 04:52:50 -0700 (PDT)
Received: from pc6 (81.151.162.168) by AMSPR07MB049.eurprd07.prod.outlook.com (10.242.81.11) with Microsoft SMTP Server (TLS) id 15.1.125.19; Thu, 9 Apr 2015 11:32:15 +0000
Message-ID: <006301d072b8$ab1e8f40$4001a8c0@gateway.2wire.net>
From: t.petch 
To: Alexey Melnikov , 
References: <5518019A.7080508@isode.com> <012f01d06a34$447b0160$4001a8c0@gateway.2wire.net>
Date: Thu, 9 Apr 2015 12:30:54 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [81.151.162.168]
X-ClientProxiedBy: AM3PR01CA039.eurprd01.prod.exchangelabs.com (10.141.191.29) To AMSPR07MB049.eurprd07.prod.outlook.com (10.242.81.11)
Authentication-Results: isode.com; dkim=none (message not signed) header.d=none;
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB049;
X-Forefront-Antispam-Report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(51704005)(377454003)(13464003)(116806002)(50986999)(230783001)(86362001)(61296003)(42186005)(19580405001)(107886001)(19580395003)(81816999)(33646002)(81686999)(87976001)(76176999)(77156002)(62966003)(92566002)(15975445007)(77096005)(44716002)(23756003)(62236002)(50226001)(66066001)(47776003)(44736004)(40100003)(122386002)(50466002)(46102003)(14496001)(2101003); DIR:OUT; SFP:1102; SCL:1; SRVR:AMSPR07MB049; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; 
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:AMSPR07MB049; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB049; 
X-Forefront-PRVS: 0541031FF6
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Apr 2015 11:32:15.9583 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB049
Archived-At: 
Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-rfc7001bis-05
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 09 Apr 2015 11:52:53 -0000

I said I would post my hand-crafted revision to the IANA registry to the
list.  I should have said that I would send an e-mail for posting, which
I have now done three times and, as you may have seen, there is nothing
on the mailing list, or in the List Archive.  The e-mail successfully
arrives at another mailbox  with a different ISP so my MTA is fine with
it, looks like the AMS servers are not.  No DSN, nothing, just the
appearance of a black hole.

So I still have it and will e-mail it individually to anyone who wants
it.

Tom Petch

----- Original Message -----
From: "t.petch" 
To: "Alexey Melnikov" ;

Sent: Sunday, March 29, 2015 4:14 PM

> I think that this I-D is ready to advance.
>
> It has as complex an IANA Considerations as I can recall,
> comprising, depending on how you count, several hundred changes to the
> underlying HTML.  I could not readily tell what the new registries
would
> look like, so I applied the changes, by hand, to the current
registries
> and have the result in
> .mhtml.  The file is 175kbyte (mostly SCRIPT, probably not needed) and
I
> will post that separately in case others want to peruse it.
>
> Picking my words with care, with so much to do, it is possible that
IANA
> will find an alternative interpretation to the one on which the WG has
> consensus.  I have seen that happen before and seen it fixed, without
> having to change the RFC, but cannot recall just how.  It may have
been
> a
> consensus call on the WG List, or even just an e-mail from AD or WG
> Chairs; it might be prudent to have the mechanics of this to hand.
>
> And/or might it be prudent to insert a further check, perhaps after
> 'IANA
> OK', to see what IANA are going to come up with prior to AUTH48?
>
> As you may guess, I am a pessimist (but have learnt that the problems
> that I anticipate are less likely to be problems:-)
>
> Tom Petch
>
> ----- Original Message -----
> From: "Alexey Melnikov" 
> To: 
> Sent: Sunday, March 29, 2015 2:43 PM
> > This message is starting 3 weeks (*) Working Group Last Calls on
> > draft-ietf-appsawg-rfc7001bis-05 (Message Header Field for
Indicating
> > Message Authentication Status). The WGLC ends on
> > April 19th.
> >
> > Please send your comments on the document in a reply to this message
> or
> > directly to me. If you read the document and you think the document
is
> > ready for publication, saying so would also be helpful.
> >
> > Alexey,
> > As a co-chair.
> >
> > (*) - this is to allow people to recover from the Dallas IETF.
> >
> > _______________________________________________
> > apps-discuss mailing list
> > apps-discuss@ietf.org
> > https://www.ietf.org/mailman/listinfo/apps-discuss
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss


From nobody Thu Apr  9 07:42:00 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76DE41A7025; Thu,  9 Apr 2015 07:41:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level: 
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cIcLtCL6Gqn4; Thu,  9 Apr 2015 07:41:43 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4033F1A8724; Thu,  9 Apr 2015 07:41:41 -0700 (PDT)
Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YgDeF-000CN7-0H; Thu, 09 Apr 2015 10:41:39 -0400
Date: Thu, 09 Apr 2015 10:41:33 -0400
From: John C Klensin 
To: Barry Leiba 
Message-ID: <723FBC93979E1019101319C5@JcK-HP8200.jck.com>
In-Reply-To: 
References: <2E49FA112B054FFAED69D8A1@JcK-HP8200.jck.com> 
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.35
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: 
Cc: draft-ietf-appsawg-uri-scheme-reg.all@ietf.org, IESG , Apps Discuss 
Subject: Re: [apps-discuss] Retroactive application of draft-ietf-appsawg-uri-scheme-reg - comprehensive review
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 09 Apr 2015 14:41:49 -0000

--On Wednesday, April 08, 2015 15:28 -0400 Barry Leiba
 wrote:

>> I've been thinking more about Larry's claim [1] that
>> draft-ietf-appsawg-uri-scheme-reg (referred to as "4395bis"
>> below) constrains work going on in the URNBIS WG and, in
>> particular, draft-ietf-urnbis-rfc2141bis-urn and have been
>> studying both documents.
> 
> John (and others), please check the -06 version, looking
> especially at the new last paragraph of Section 7.1.  I
> believe that takes care of this case by codifying how Graham
> already handles registration requests that come from IETF
> working groups.

That section, and the other changes from -05, represent huge
improvements.  Thanks.

> For the specific case of urnbis, consensus on 2141bis would
> allow it to specify how urn: registrations work, independent
> of what's said here.  I would say that if 2141bis specifically
> contradicts something here, it should explicitly call that
> out, to be absolutely clear about it.

That is fine.  I would appreciate it if you and/or others who
are relevant would figure out, now, if 2141bis said something
contradictory to what is said in
draft-ietf-appsawg-uri-scheme-reg whether it should be noted as
updating this document.   I don't care what the answer is; I
just do not want to have a time-consuming late-stage controversy
about the issue.

More important, neither the changes nor your note address the
particular issue that caused my review and concerns about
draft-ietf-appsawg-uri-scheme-reg.  The issue was the claim that
this document imposed additional constraints or requirements in
addition to those of RFC 3986, requirements that could (or did)
invalidate what the URNBIS WG is trying to do with
draft-ietf-urnbis-semantics-clarif.  

I believe the key issue is that, as far as the _syntax_
specified in RFC 3986 is concerned, there is a syntax component,
given the name "fragment" in the defining production, that,
informally, is delimited by the first appearance of "#" in a URI
and that extends to the end of the URI.  Anything more --
bindings to schemes, relationships to media types, even the
binding of the term "fragment" to anything one might find in a
dictionary-- are matters of semantics (or maybe something else)
but not syntax. 

Consequently, when this document says, in the second paragraph
of Section 3,

	"A scheme definition cannot override the overall syntax
	for URIs.  For example, this means that fragment
	identifiers cannot be re-used outside the generic syntax
	restrictions, and fragment identifiers are not
	scheme-specific."

we have at statement that is at least confusing (if not a
logical fallacy) and one that creates an opportunity for
arguments about what an effort to specify or update a URI scheme
(even a standards-track one associated with at WG) attempts to
do.   In addition to whatever was intended, the statement could
be read as "fragments are required to be allowed with all URI
schemes and no individual scheme can prohibit them".  I'm fairly
confident that is not what the authors of either this document
or 3986 intended, but, if that sort of ambiguity exists, it is
unreasonable to claim that there is informed community consensus
about this document.

I note that the following sentence and syntax excerpt is
completely consistent with my comment.  It shows '"#" fragment'
as optional, which implies that it can be prohibited on a
scheme-specific basis.  The example text just confuses things.

Note too that every syntax-defining metalanguage I've works
with, from original BNF (which does not allow brackets of
equivalent to optional parts) through ABNF and beyond, treats
the sequence

 URI = scheme ":" scheme-specific-part [ "#" fragment ]
 scheme-specific-part = hier-part [ "?" query ]

And

  URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]

as specifying _exactly_ the same syntax.  The distinction may be
useful for clarity but makes no syntax distinction.

If the example simply said something like:

	'For example, this means that the "#" character cannot be
	used except to introduce what RFC 3986 describes as a
	fragment, and URI schemes cannot change that
	interpretation of the syntax.'

with or without an additional sentence saying:

	'Particular scheme definitions may disallow use of
	fragments entirely.'

then I don't believe we would have a problem.

While I think this document could be improved, especially wrt to
statements like the above where the example is not really an
illustration of the restriction statement and attempts to use
syntax productions to make distinctions that the productions
don't support, I recognize the value of what the document is
trying to accomplish and, as I have said earlier, do not want to
hold it up over fine points of meaning and boundaries between,
e.g., syntax and semantics.   At the same time, it cannot be in
the IETF's best interest to have someone complicate the very
difficult issues and choices facing the URNBIS WG by using this
document to play "gotcha", especially if the player is one of
the document's co-authors.

So I continue to believe that it is necessary to do at least one
of the following:

(1) Correct this document to remove all statements or so-called
examples that appear to impose restrictions not present in 3986
and all ambiguities of the variety illustrated above.

(2) Alter this document to exclude existing schemes (including
revisions of their definitions) whose definitions are included
in or normatively referenced by standards-track documents.

(3) Alter the document to make it clear that a standards-track
document may treat this document as advisory and override
anything it says by providing a clear explanation of why it is
doing so _and_ make a clear public note, in the tracker or an
IESG statement, that language in this document can not by used
as an authority to block discussions of alternate strategies in
IETF WGs or other standards-track efforts.

(4) Hold this document until 2141bis (and associated documents)
are ready and then issue a new Last Call on the two documents
together.  Or, perhaps equivalently in practice, hold this
document until the APPAWG and URNBIS WG can reach joint
consensus about what it should say, at least on the subject of
revisions to existing URH scheme definitions.

>From my point of view, option 4 is the least desirable of that
collection.

best,
    john


From nobody Thu Apr  9 07:42:01 2015
Return-Path: 
X-Original-To: expand-draft-ietf-appsawg-uri-scheme-reg.all@virtual.ietf.org
Delivered-To: apps-discuss@ietfa.amsl.com
Received: by ietfa.amsl.com (Postfix, from userid 65534) id 9FBC21A874A; Thu,  9 Apr 2015 07:41:49 -0700 (PDT)
X-Original-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com
Delivered-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76DE41A7025; Thu,  9 Apr 2015 07:41:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level: 
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cIcLtCL6Gqn4; Thu,  9 Apr 2015 07:41:43 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4033F1A8724; Thu,  9 Apr 2015 07:41:41 -0700 (PDT)
Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YgDeF-000CN7-0H; Thu, 09 Apr 2015 10:41:39 -0400
Date: Thu, 09 Apr 2015 10:41:33 -0400
From: John C Klensin 
To: Barry Leiba 
Message-ID: <723FBC93979E1019101319C5@JcK-HP8200.jck.com>
In-Reply-To: 
References: <2E49FA112B054FFAED69D8A1@JcK-HP8200.jck.com> 
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.35
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: 
Cc: draft-ietf-appsawg-uri-scheme-reg.all@ietf.org, IESG , Apps Discuss 
Subject: Re: [apps-discuss] Retroactive application of draft-ietf-appsawg-uri-scheme-reg - comprehensive review
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 09 Apr 2015 14:41:49 -0000

--On Wednesday, April 08, 2015 15:28 -0400 Barry Leiba
 wrote:

>> I've been thinking more about Larry's claim [1] that
>> draft-ietf-appsawg-uri-scheme-reg (referred to as "4395bis"
>> below) constrains work going on in the URNBIS WG and, in
>> particular, draft-ietf-urnbis-rfc2141bis-urn and have been
>> studying both documents.
> 
> John (and others), please check the -06 version, looking
> especially at the new last paragraph of Section 7.1.  I
> believe that takes care of this case by codifying how Graham
> already handles registration requests that come from IETF
> working groups.

That section, and the other changes from -05, represent huge
improvements.  Thanks.

> For the specific case of urnbis, consensus on 2141bis would
> allow it to specify how urn: registrations work, independent
> of what's said here.  I would say that if 2141bis specifically
> contradicts something here, it should explicitly call that
> out, to be absolutely clear about it.

That is fine.  I would appreciate it if you and/or others who
are relevant would figure out, now, if 2141bis said something
contradictory to what is said in
draft-ietf-appsawg-uri-scheme-reg whether it should be noted as
updating this document.   I don't care what the answer is; I
just do not want to have a time-consuming late-stage controversy
about the issue.

More important, neither the changes nor your note address the
particular issue that caused my review and concerns about
draft-ietf-appsawg-uri-scheme-reg.  The issue was the claim that
this document imposed additional constraints or requirements in
addition to those of RFC 3986, requirements that could (or did)
invalidate what the URNBIS WG is trying to do with
draft-ietf-urnbis-semantics-clarif.  

I believe the key issue is that, as far as the _syntax_
specified in RFC 3986 is concerned, there is a syntax component,
given the name "fragment" in the defining production, that,
informally, is delimited by the first appearance of "#" in a URI
and that extends to the end of the URI.  Anything more --
bindings to schemes, relationships to media types, even the
binding of the term "fragment" to anything one might find in a
dictionary-- are matters of semantics (or maybe something else)
but not syntax. 

Consequently, when this document says, in the second paragraph
of Section 3,

	"A scheme definition cannot override the overall syntax
	for URIs.  For example, this means that fragment
	identifiers cannot be re-used outside the generic syntax
	restrictions, and fragment identifiers are not
	scheme-specific."

we have at statement that is at least confusing (if not a
logical fallacy) and one that creates an opportunity for
arguments about what an effort to specify or update a URI scheme
(even a standards-track one associated with at WG) attempts to
do.   In addition to whatever was intended, the statement could
be read as "fragments are required to be allowed with all URI
schemes and no individual scheme can prohibit them".  I'm fairly
confident that is not what the authors of either this document
or 3986 intended, but, if that sort of ambiguity exists, it is
unreasonable to claim that there is informed community consensus
about this document.

I note that the following sentence and syntax excerpt is
completely consistent with my comment.  It shows '"#" fragment'
as optional, which implies that it can be prohibited on a
scheme-specific basis.  The example text just confuses things.

Note too that every syntax-defining metalanguage I've works
with, from original BNF (which does not allow brackets of
equivalent to optional parts) through ABNF and beyond, treats
the sequence

 URI = scheme ":" scheme-specific-part [ "#" fragment ]
 scheme-specific-part = hier-part [ "?" query ]

And

  URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]

as specifying _exactly_ the same syntax.  The distinction may be
useful for clarity but makes no syntax distinction.

If the example simply said something like:

	'For example, this means that the "#" character cannot be
	used except to introduce what RFC 3986 describes as a
	fragment, and URI schemes cannot change that
	interpretation of the syntax.'

with or without an additional sentence saying:

	'Particular scheme definitions may disallow use of
	fragments entirely.'

then I don't believe we would have a problem.

While I think this document could be improved, especially wrt to
statements like the above where the example is not really an
illustration of the restriction statement and attempts to use
syntax productions to make distinctions that the productions
don't support, I recognize the value of what the document is
trying to accomplish and, as I have said earlier, do not want to
hold it up over fine points of meaning and boundaries between,
e.g., syntax and semantics.   At the same time, it cannot be in
the IETF's best interest to have someone complicate the very
difficult issues and choices facing the URNBIS WG by using this
document to play "gotcha", especially if the player is one of
the document's co-authors.

So I continue to believe that it is necessary to do at least one
of the following:

(1) Correct this document to remove all statements or so-called
examples that appear to impose restrictions not present in 3986
and all ambiguities of the variety illustrated above.

(2) Alter this document to exclude existing schemes (including
revisions of their definitions) whose definitions are included
in or normatively referenced by standards-track documents.

(3) Alter the document to make it clear that a standards-track
document may treat this document as advisory and override
anything it says by providing a clear explanation of why it is
doing so _and_ make a clear public note, in the tracker or an
IESG statement, that language in this document can not by used
as an authority to block discussions of alternate strategies in
IETF WGs or other standards-track efforts.

(4) Hold this document until 2141bis (and associated documents)
are ready and then issue a new Last Call on the two documents
together.  Or, perhaps equivalently in practice, hold this
document until the APPAWG and URNBIS WG can reach joint
consensus about what it should say, at least on the subject of
revisions to existing URH scheme definitions.

>From my point of view, option 4 is the least desirable of that
collection.

best,
    john


From nobody Thu Apr  9 09:36:48 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F04661B2EA7 for ; Thu,  9 Apr 2015 09:36:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xRqoLYXFtMg6 for ; Thu,  9 Apr 2015 09:36:41 -0700 (PDT)
Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0722.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::722]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B383E1B2E9F for ; Thu,  9 Apr 2015 09:36:40 -0700 (PDT)
Received: from pc6 (81.151.162.168) by AMSPR07MB052.eurprd07.prod.outlook.com (10.242.81.27) with Microsoft SMTP Server (TLS) id 15.1.130.23; Thu, 9 Apr 2015 16:36:23 +0000
Message-ID: <020401d072e3$279408a0$4001a8c0@gateway.2wire.net>
From: t.petch 
To: Dave Thaler 
References: <550164DD.6020509@it.aoyama.ac.jp>  <080D2D237EF9714533B15BDB@JcK-HP8200.jck.com> <005901d072b7$ee4930a0$4001a8c0@gateway.2wire.net>
Date: Thu, 9 Apr 2015 17:35:06 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [81.151.162.168]
X-ClientProxiedBy: AM3PR01CA032.eurprd01.prod.exchangelabs.com (10.141.191.22) To AMSPR07MB052.eurprd07.prod.outlook.com (10.242.81.27)
Authentication-Results: microsoft.com; dkim=none (message not signed) header.d=none;
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB052;
X-Forefront-Antispam-Report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(62236002)(44716002)(62966003)(77156002)(77096005)(116806002)(1456003)(93886004)(87976001)(230783001)(122386002)(84392001)(33646002)(86362001)(40100003)(44736004)(50226001)(76176999)(92566002)(50986999)(81816999)(81686999)(1511001)(47776003)(50466002)(66066001)(2421001)(110136001)(23756003)(46102003)(229853001)(42186005)(61296003)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMSPR07MB052; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; 
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:AMSPR07MB052; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB052; 
X-Forefront-PRVS: 0541031FF6
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Apr 2015 16:36:23.8106 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB052
Archived-At: 
Cc: apps-discuss , Larry Masinter 
Subject: [apps-discuss]  (Guidelines and Registration Procedures for URI Schemes) to Best Current Practice
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 09 Apr 2015 16:36:46 -0000

Dave

Looking at the IANA Considerations of -06, I would suggest specifying a
name for the new, combined registry.

With the terminology of -leiba-cotton-, 'Uniform Resource Identifier
Schemes' would be a grouping with the new registry one of the registries
under it.  The obvious name for the new registry would be, well 'Uniform
Resource Identifier Schemes ' but that is taken and I struggle to think
of an epithet which would cover both registered and yet to be
registered, historic and not historic, permanent and not permanent URI
scemes; but IANA are going to need one.

And the 'Note' under the grouping will need updating as well.
e.g.
OLD
[RFC4395] defines an IANA-maintained registry of URI Schemes.
These registries include the Permanent and Provisional URI Schemes.

NEW
[RFC4395] defined an IANA-maintained registry of URI Schemes.  [RFC2B]
updates the procedure for registering schemes.  There is now a single
combined registry of Permanent, Provisional, Historic and Pending Review
URI Schemes.

And the Registration Procedure changes as well to a mix of FCFS and
Expert Review but I am not sure how to word that.

Tom Petch


From nobody Thu Apr  9 10:48:33 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E6F71B3000; Thu,  9 Apr 2015 10:48:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vPAscHcInZMk; Thu,  9 Apr 2015 10:48:31 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 56C4A1B300F; Thu,  9 Apr 2015 10:48:20 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
To: , , 
X-Test-IDTracker: no
X-IETF-IDTracker: 5.13.0.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150409174820.13917.97534.idtracker@ietfa.amsl.com>
Date: Thu, 09 Apr 2015 10:48:20 -0700
From: IETF Secretariat 
Archived-At: 
Subject: [apps-discuss] ID Tracker State Update Notice: 
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Apr 2015 17:48:32 -0000

IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation
ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-uri-scheme-reg/


From nobody Thu Apr  9 10:49:00 2015
Return-Path: 
X-Original-To: expand-draft-ietf-appsawg-multipart-form-data.all@virtual.ietf.org
Delivered-To: apps-discuss@ietfa.amsl.com
Received: by ietfa.amsl.com (Postfix, from userid 65534) id C44AC1B355A; Wed,  8 Apr 2015 12:31:45 -0700 (PDT)
X-Original-To: xfilter-draft-ietf-appsawg-multipart-form-data.all@ietfa.amsl.com
Delivered-To: xfilter-draft-ietf-appsawg-multipart-form-data.all@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2B3F1B3553 for ; Wed,  8 Apr 2015 12:31:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_FAIL=0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ThVHtC9QPZMC for ; Wed,  8 Apr 2015 12:31:42 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEDAC1B3558 for ; Wed,  8 Apr 2015 12:31:41 -0700 (PDT)
Received: from mail-bn1bon0085.outbound.protection.outlook.com ([157.56.111.85]:62496 helo=na01-bn1-obe.outbound.protection.outlook.com) by zinfandel.tools.ietf.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YfvhM-0000pb-Rm for draft-ietf-appsawg-multipart-form-data.all@tools.ietf.org; Wed, 08 Apr 2015 12:31:41 -0700
Received: from DM2PR02MB1322.namprd02.prod.outlook.com (25.161.142.21) by DM2PR02MB1324.namprd02.prod.outlook.com (25.161.142.23) with Microsoft SMTP Server (TLS) id 15.1.118.21; Wed, 8 Apr 2015 16:56:43 +0000
Received: from DM2PR02MB1322.namprd02.prod.outlook.com ([25.161.142.21]) by DM2PR02MB1322.namprd02.prod.outlook.com ([25.161.142.21]) with mapi id 15.01.0118.029; Wed, 8 Apr 2015 16:56:43 +0000
From: Larry Masinter 
To: Barry Leiba 
Thread-Topic: New Version Notification for draft-ietf-appsawg-multipart-form-data-10.txt
Thread-Index: AQHQchz9cL6gWwvF/0Kwne7pYXQgPw==
Date: Wed, 8 Apr 2015 16:56:43 +0000
Message-ID: <868AA964-D30D-4750-8F3D-5DE7073BA0C6@adobe.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/15.8.0.150303
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [50.184.24.49]
authentication-results: computer.org; dkim=none (message not signed) header.d=none;
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR02MB1324;
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10009020)(6009001)(33656002)(230783001)(62966003)(99286002)(82746002)(40100003)(110136001)(83506001)(86362001)(229853001)(19580395003)(106116001)(77156002)(83716003)(87936001)(2656002)(2900100001)(1720100001)(46102003)(66066001)(2420400003)(122556002)(50986999)(102836002)(54356999)(92566002)(36756003)(15975445007)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR02MB1324; H:DM2PR02MB1322.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:DM2PR02MB1324; BCL:0; PCL:0; RULEID:;  SRVR:DM2PR02MB1324; 
x-forefront-prvs: 0540846A1D
Content-Type: text/plain; charset="utf-8"
Content-ID: <67ACFC53840DC34EA7243713E09E777C@namprd02.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: adobe.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2015 16:56:43.3455 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR02MB1324
X-Helo-Check-Failed: Verification failed for HELO na01-bn1-obe.outbound.protection.outlook.com
X-SA-Exim-Connect-IP: 157.56.111.85
X-SA-Exim-Rcpt-To: draft-ietf-appsawg-multipart-form-data.all@tools.ietf.org
X-SA-Exim-Mail-From: masinter@adobe.com
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org)
Resent-To: draft-ietf-appsawg-multipart-form-data.all@ietf.org
Resent-Message-Id: <20150408193141.DEDAC1B3558@ietfa.amsl.com>
Resent-Date: Wed,  8 Apr 2015 12:31:41 -0700 (PDT)
Resent-From: masinter@adobe.com
Archived-At: 
Archived-At: 
X-Mailman-Approved-At: Thu, 09 Apr 2015 10:48:58 -0700
Cc: "draft-ietf-appsawg-multipart-form-data.all@tools.ietf.org" , "secdir@ietf.org" , Chris Lonvick , "iesg@ietf.org" 
Subject: [apps-discuss] New Version Notification for draft-ietf-appsawg-multipart-form-data-10.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 08 Apr 2015 19:31:45 -0000

VG8gYWRkcmVzcyBJRVNHIGxhc3QgY2FsbCBjb21tZW50cyBiZXR0ZXI6DQoNClVSTDogICAgICAg
ICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLWFwcHNh
d2ctbXVsdGlwYXJ0LWZvcm0tZGF0YS0xMC50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2Rh
dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWFwcHNhd2ctbXVsdGlwYXJ0LWZvcm0t
ZGF0YS8NCkh0bWxpemVkOiAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p
ZXRmLWFwcHNhd2ctbXVsdGlwYXJ0LWZvcm0tZGF0YS0xMA0KRGlmZjogICAgICAgICAgIGh0dHA6
Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtYXBwc2F3Zy1tdWx0aXBhcnQt
Zm9ybS1kYXRhLTEwDQoNCj09PT09PQ0KDQphZGRpdGlvbmFsIHR5cG9zIG5vdGVkIG5vdyBmaXhl
ZC4NCg0KcmV2aXNpdGluZyBwcmV2aW91cyByZXBsaWVzOg0KDQoNClNlY3VyaXR5IGNvbnNpZGVy
YXRpb25zOg0KDQpVbmNsZS4gSSB3YXMganVzdCB1bmhhcHB5IHRoYXQgdGhlIFNlY3VyaXR5IENv
bnNpZGVyYXRpb25zIHNlY3Rpb24gY291bGQgYmUNCmJldHRlciwgbW9yZSBjb2hlcmVudCwgYW5k
IGFjdHVhbGx5IGZsb3dlZCByYXRoZXIgdGhhbiB3aGF04oCZcyB0aGVyZS4NCkJ1dCBhcyBzdWdn
ZXN0ZWQsIEkgaGF2ZSBtb3ZlZCB0aGUgbGFzdCBwYXJhZ3JhcGggdG8gdGhlIGZpcnN0Lg0KDQoN
CkluIC0xMCBJIGFsc28gcmV3cm90ZSBteSBwcmV2aW91c2x5IHNuYXJreToNCk9MRA0KICAgTW9y
ZSBwcm9ibGVtYXRpYyBpcyB0aGUgYW1iaWd1aXR5IGludHJvZHVjZWQgYmVjYXVzZSBpbXBsZW1l
bnRhdGlvbnMNCiAgIGRpZCBub3QgZm9sbG93IFtSRkMyMzg4XSBiZWNhdXNlIGl0IHVzZWQgIm1h
eSIgaW5zdGVhZCBvZiAiTVVTVCIgd2hlbg0KICAgc3BlY2lmeWluZyBlbmNvZGluZyBvZiBmaWVs
ZCBuYW1lcywgYW5kIGZvciBvdGhlciB1bmtub3duIHJlYXNvbnMsIHNvDQogICBub3csIHBhcnNl
cnMgbmVlZCB0byBiZSBtb3JlIGNvbXBsZXggZm9yIGZ1enp5IG1hdGNoaW5nIGFnYWluc3QgdGhl
DQogICBwb3NzaWJsZSBvdXRwdXRzIG9mIHZhcmlvdXMgZW5jb2RpbmcgbWV0aG9kcy4NCg0KDQp0
byBhIGxlc3Mgc25hcmt5Og0KTkVXDQogICBNb3JlIHByb2JsZW1hdGljIGFyZSB0aGUgZGlmZmVy
ZW5jZXMgaW50cm9kdWNlZCB3aGVuIGltcGxlbWVudG9ycw0KICAgb3B0ZWQgdG8gbm90IGZvbGxv
dyBbUkZDMjM4OF0gd2hlbiBlbmNvZGluZyBub24tQVNDSUkgZmllbGQgbmFtZXMNCiAgIChwZXJo
YXBzIGJlY2F1c2UgIm1heSIgc2hvdWxkIGhhdmUgYmVlbiAiTVVTVCIpLiAgQXMgYSByZXN1bHQs
DQogICBwYXJzZXJzIG5lZWQgdG8gYmUgbW9yZSBjb21wbGV4IGZvciBtYXRjaGluZyBhZ2FpbnN0
IHRoZSBwb3NzaWJsZQ0KICAgb3V0cHV0cyBvZiB2YXJpb3VzIGVuY29kaW5nIG1ldGhvZHMuDQoN
Cg0KdG8gbm90IGZ1cnRoZXIgZGlzcGFyYWdlIGltcGxlbWVudG9yIGlubm92YXRpb24uDQoNCkxh
cnJ5DQrigJQNCmh0dHA6Ly9sYXJyeS5tYXNpbnRlci5uZXQNCg0KDQoNCg0KDQo=


From nobody Thu Apr  9 10:49:01 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 444691A1DBE; Wed,  8 Apr 2015 17:13:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level: 
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A_ODyN6ALAEW; Wed,  8 Apr 2015 17:13:55 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D1EC71A1B83; Wed,  8 Apr 2015 17:13:55 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Kathleen Moriarty" 
To: "The IESG" 
X-Test-IDTracker: no
X-IETF-IDTracker: 5.13.0.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150409001355.11418.62250.idtracker@ietfa.amsl.com>
Date: Wed, 08 Apr 2015 17:13:55 -0700
Archived-At: 
X-Mailman-Approved-At: Thu, 09 Apr 2015 10:48:56 -0700
Cc: apps-discuss@ietf.org, appsawg-chairs@ietf.org
Subject: [apps-discuss] Kathleen Moriarty's No Objection on draft-ietf-appsawg-uri-scheme-reg-06: (with COMMENT)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Apr 2015 00:13:57 -0000

Kathleen Moriarty has entered the following ballot position for
draft-ietf-appsawg-uri-scheme-reg-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-appsawg-uri-scheme-reg/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I support Stephen's comments and was wondering about privacy
considerations for the contact information provided as well in scheme
registration requests.  Just noting the concern would be good and maybe
recommending using a generic organizational contact if possible cold work
if that's possible, may not always be.



From nobody Thu Apr  9 10:49:02 2015
Return-Path: 
X-Original-To: expand-draft-ietf-appsawg-multipart-form-data.all@virtual.ietf.org
Delivered-To: apps-discuss@ietfa.amsl.com
Received: by ietfa.amsl.com (Postfix, from userid 65534) id 156511B3328; Thu,  9 Apr 2015 04:03:31 -0700 (PDT)
X-Original-To: xfilter-draft-ietf-appsawg-multipart-form-data.all@ietfa.amsl.com
Delivered-To: xfilter-draft-ietf-appsawg-multipart-form-data.all@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCCA21B331E for ; Thu,  9 Apr 2015 04:03:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=unavailable
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id apq8-0yTSiml for ; Thu,  9 Apr 2015 04:03:29 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B31A1B3328 for ; Thu,  9 Apr 2015 04:03:28 -0700 (PDT)
Received: from p130.piuha.net ([193.234.218.130]:53974) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YgAF2-0005DF-KG for draft-ietf-appsawg-multipart-form-data.all@tools.ietf.org; Thu, 09 Apr 2015 04:03:28 -0700
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id E849C2CC6F; Thu,  9 Apr 2015 14:03:18 +0300 (EEST) (envelope-from jari.arkko@piuha.net)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ewvvcwzk_mhy; Thu,  9 Apr 2015 14:03:18 +0300 (EEST)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 2B4BD2CC5D; Thu,  9 Apr 2015 14:03:18 +0300 (EEST) (envelope-from jari.arkko@piuha.net)
Content-Type: multipart/signed; boundary="Apple-Mail=_58A7E04B-BA39-44CC-AA9C-7DE102197FAA"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Jari Arkko 
In-Reply-To: <020201d06de0$a8379060$f8a6b120$@gmail.com>
Date: Thu, 9 Apr 2015 14:03:16 +0300
Message-Id: <52273F26-D0AB-4AFE-BB40-158DC5E53083@piuha.net>
References: <020201d06de0$a8379060$f8a6b120$@gmail.com>
To: Roni Even 
X-Mailer: Apple Mail (2.1878.6)
X-SA-Exim-Connect-IP: 193.234.218.130
X-SA-Exim-Rcpt-To: draft-ietf-appsawg-multipart-form-data.all@tools.ietf.org
X-SA-Exim-Mail-From: jari.arkko@piuha.net
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org)
Resent-To: draft-ietf-appsawg-multipart-form-data.all@ietf.org
Resent-Message-Id: <20150409110328.8B31A1B3328@ietfa.amsl.com>
Resent-Date: Thu,  9 Apr 2015 04:03:28 -0700 (PDT)
Resent-From: jari.arkko@piuha.net
Archived-At: 
Archived-At: 
X-Mailman-Approved-At: Thu, 09 Apr 2015 10:48:58 -0700
Cc: draft-ietf-appsawg-multipart-form-data.all@tools.ietf.org, gen-art@ietf.org, ietf@ietf.org
Subject: Re: [apps-discuss] Gen-ART LC review of draft-ietf-appsawg-multipart-form-data-08
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 09 Apr 2015 11:03:31 -0000

--Apple-Mail=_58A7E04B-BA39-44CC-AA9C-7DE102197FAA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Thanks for the review. I think the new version addressed your one =
comment.

Jari

On 03 Apr 2015, at 10:34, Roni Even  wrote:

> I am the assigned Gen-ART reviewer for this draft. For background on =
Gen-ART, please see the FAQ at =
.
>=20
> Please resolve these comments along with any other Last Call comments =
you may receive.
>=20
> Document:  draft-ietf-appsawg-multipart-form-data-08
> Reviewer: Roni Even
> Review Date:2015=964-3
> IETF LC End Date: 2015=964-6
> IESG Telechat date:
> =20
> Summary: This draft is almost ready for publication as an Standard =
Track  RFC.
> =20
> =20
> Major issues:
> =20
> Minor issues:
> =20
> In the IANA considerations I think you missed to mention the Content =
Disposition Vlaues form-data
> See http://www.iana.org/assignments/cont-disp/cont-disp.xhtml
> =20
> =20
> Nits/editorial comments:
>=20


--Apple-Mail=_58A7E04B-BA39-44CC-AA9C-7DE102197FAA
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJVJlx0AAoJEM80gCTQU46q7awQAI5mUJ7DZckwDehccpgda9qg
OJSZ6dwl6aFuY+HnDAnzUMwrAAxcJX5YVmevKUQhox0ZavP9/XDzjqmEtRdILHM/
a+VwClyKUggA3mJOWAPc8s/Q8rDSBmS1SHFiQRRhDW5kv46ZKiE4ZQQnjOK2xGw9
Ih7ENsWnLkom7MkSYmRO8Qkf4P5fGO5iY7ro0j0974uthC4x2gCWBf2WbRcWdhUA
Kz8Y3M5NEOz9tO6iY/21TiFyhMTeWwymcb9UBGA8st3ff+3u111a1Cfag7cbO7+t
KoGCDP3aN5r4JdCkRPdUICaCTQkc8WFN1SDC4PyOe589f8HGSKKbqdMjChzQNw3/
538vzk3E2djnnUDziJaaL0sT+0U93MtegACO7u27weMSCJtZuwGCB6vhiHdtjiTO
dvZEPn74eUjYuPlgoJ0E6tg887/4dUOGPvh5nYFf4tc21coRMbxya2J8dFeOiAZu
YcxvtoymQmD52qbdeoV68HnPZg9mDdJGdJXM98qQsPPc8ndGc7urUvawPJcGTIkL
YYYisl7002DKIAubA7QPJWZNfDVpwyQ1MXlenaaa/Pq0551pOma8745/w8IgHmRI
S/pkxYUk22XrV/AvOZd0mMoomoVeEGqfJa+4MzEpKv7wt4ndBnt4H7OxoLOXgd0r
XTUmuVzBQ2VFsvlxrGgS
=FS8g
-----END PGP SIGNATURE-----

--Apple-Mail=_58A7E04B-BA39-44CC-AA9C-7DE102197FAA--


From nobody Thu Apr  9 10:53:11 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D37E1A8A71; Thu,  9 Apr 2015 10:53:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KswcF9vylBEO; Thu,  9 Apr 2015 10:53:08 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AB3681A891E; Thu,  9 Apr 2015 10:52:58 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
To: , ,  ,  , 
X-Test-IDTracker: no
X-IETF-IDTracker: 5.13.0.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150409175258.12065.97788.idtracker@ietfa.amsl.com>
Date: Thu, 09 Apr 2015 10:52:58 -0700
From: IETF Secretariat 
Archived-At: 
Subject: [apps-discuss] ID Tracker State Update Notice: 
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Apr 2015 17:53:10 -0000

IESG state changed to Approved-announcement to be sent from IESG Evaluation
ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-multipart-form-data/


From nobody Thu Apr  9 12:13:40 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF5241A8A86; Thu,  9 Apr 2015 12:13:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.666
X-Spam-Level: 
X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9GSdTrkHY0wS; Thu,  9 Apr 2015 12:13:34 -0700 (PDT)
Received: from homiemail-a26.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 113561A8986; Thu,  9 Apr 2015 12:13:34 -0700 (PDT)
Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id BFBF4B8079; Thu,  9 Apr 2015 12:13:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=gbiv.com; bh=9xxWNBimgotqKvrDPaDypxBezd0=; b=6cm6yYzt9SDjNTN1wYfMjHyEczIK 5M3g50eDbRqCzEuzdzZPJ0aHum4fFbYAHMkuP0x1wGJ1lNws4WGGORtnQhRRQcsz XcUIGLoRqwDYCqJi0BuGyihKTAWa9wRgzCaGCaKvaYYmpS1kaInavi6K0KaulVDp go6uEyuHZRuyzJM=
Received: from [192.168.1.12] (ip68-228-83-124.oc.oc.cox.net [68.228.83.124]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTPSA id 8FE10B8058; Thu,  9 Apr 2015 12:13:32 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=us-ascii
From: "Roy T. Fielding" 
In-Reply-To: <723FBC93979E1019101319C5@JcK-HP8200.jck.com>
Date: Thu, 9 Apr 2015 12:13:30 -0700
Content-Transfer-Encoding: 7bit
Message-Id: <4EA0B2F8-5109-49EA-8BAF-0199D1640407@gbiv.com>
References: <2E49FA112B054FFAED69D8A1@JcK-HP8200.jck.com>  <723FBC93979E1019101319C5@JcK-HP8200.jck.com>
To: John C Klensin 
X-Mailer: Apple Mail (2.1283)
Archived-At: 
Cc: Apps Discuss , Barry Leiba , IESG , draft-ietf-appsawg-uri-scheme-reg.all@ietf.org
Subject: Re: [apps-discuss] Retroactive application of draft-ietf-appsawg-uri-scheme-reg - comprehensive review
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 09 Apr 2015 19:13:36 -0000

On Apr 9, 2015, at 7:41 AM, John C Klensin wrote:

>> For the specific case of urnbis, consensus on 2141bis would
>> allow it to specify how urn: registrations work, independent
>> of what's said here.  I would say that if 2141bis specifically
>> contradicts something here, it should explicitly call that
>> out, to be absolutely clear about it.
> 
> That is fine.  I would appreciate it if you and/or others who
> are relevant would figure out, now, if 2141bis said something
> contradictory to what is said in
> draft-ietf-appsawg-uri-scheme-reg whether it should be noted as
> updating this document.   I don't care what the answer is; I
> just do not want to have a time-consuming late-stage controversy
> about the issue.
> 
> More important, neither the changes nor your note address the
> particular issue that caused my review and concerns about
> draft-ietf-appsawg-uri-scheme-reg.  The issue was the claim that
> this document imposed additional constraints or requirements in
> addition to those of RFC 3986, requirements that could (or did)
> invalidate what the URNBIS WG is trying to do with
> draft-ietf-urnbis-semantics-clarif.  
> 
> I believe the key issue is that, as far as the _syntax_
> specified in RFC 3986 is concerned, there is a syntax component,
> given the name "fragment" in the defining production, that,
> informally, is delimited by the first appearance of "#" in a URI
> and that extends to the end of the URI.  Anything more --
> bindings to schemes, relationships to media types, even the
> binding of the term "fragment" to anything one might find in a
> dictionary-- are matters of semantics (or maybe something else)
> but not syntax. 

They are a product of what it is to be a URI.  Whether you call that
syntax or semantics is irrelevant.

> Consequently, when this document says, in the second paragraph
> of Section 3,
> 
> 	"A scheme definition cannot override the overall syntax
> 	for URIs.  For example, this means that fragment
> 	identifiers cannot be re-used outside the generic syntax
> 	restrictions, and fragment identifiers are not
> 	scheme-specific."
> 
> we have at statement that is at least confusing (if not a
> logical fallacy) and one that creates an opportunity for
> arguments about what an effort to specify or update a URI scheme
> (even a standards-track one associated with at WG) attempts to
> do.

No, it is a statement of fact.  Wherever a URI might be used as a
protocol element, there is an explicit role assigned to the fragment
portion of the syntax that cannot be redefined by any scheme.
Any claim to the contrary, whether that be by an individual or
by IETF standards track working group consensus, is wrong.

This does not, however, have any impact on the ability of the urn
scheme to define identifiers that exclude a fragment, nor on the
use of urn identifiers with arbitrary fragments as defined by 3986.
The fragment is part of the overall identifier -- it just isn't
dependent on the scheme and cannot be forbidden by a scheme.

The semantics, if any, for a fragment depend entirely on how the
identifier is used.  If it is used as an HTTP request-target, the
fragment portion will not be sent, regardless of the URI scheme.
The same is true for other retrieval protocols.  If the identifier
is never used for retrieval, the fragment's semantics are unbounded.

Now, you might claim that "urn" schemes are not intended for retrieval.
Even if that were true (it isn't), it still wouldn't matter.  Given any URI,
an HTTP request can be used to attempt retrieval of a representation,
which means that any URI (sans fragment) can be used for retrieval
if it is possible to configure a suitable service for such resolution,
where "suitable" is judged by the provider and users of that service,
not by the working group that defines the identifiers.

No scheme definition can escape those facts, which is why both 3986
and the scheme registration document say so explicitly.  This does
not prevent anyone from using (or not using) fragments with some
urn identifiers.  It only prevents them from escaping how they are
processed when used as a URI protocol element, since that processing
is independent of scheme.

>   In addition to whatever was intended, the statement could
> be read as "fragments are required to be allowed with all URI
> schemes and no individual scheme can prohibit them".  I'm fairly
> confident that is not what the authors of either this document
> or 3986 intended, but, if that sort of ambiguity exists, it is
> unreasonable to claim that there is informed community consensus
> about this document.

Of course that is what 3986 intended.  We have archived history of
the URI protocol discussions.  None of this should be a surprise.

> I note that the following sentence and syntax excerpt is
> completely consistent with my comment.  It shows '"#" fragment'
> as optional, which implies that it can be prohibited on a
> scheme-specific basis.  The example text just confuses things.
> 
> Note too that every syntax-defining metalanguage I've works
> with, from original BNF (which does not allow brackets of
> equivalent to optional parts) through ABNF and beyond, treats
> the sequence
> 
> URI = scheme ":" scheme-specific-part [ "#" fragment ]
> scheme-specific-part = hier-part [ "?" query ]
> 
> And
> 
>  URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]
> 
> as specifying _exactly_ the same syntax.  The distinction may be
> useful for clarity but makes no syntax distinction.

Yes, the URI syntax specifies that fragment is optional.  But the syntax
does not specify the fragment processing behavior, which is what you are
claiming the scheme has some control over.  As stated, the presence
or absence of fragment is syntax independent of the scheme.
Hence, scheme definition documents have no ability to control the
use or absence of fragments.

> If the example simply said something like:
> 
> 	'For example, this means that the "#" character cannot be
> 	used except to introduce what RFC 3986 describes as a
> 	fragment, and URI schemes cannot change that
> 	interpretation of the syntax.'
> 
> with or without an additional sentence saying:
> 
> 	'Particular scheme definitions may disallow use of
> 	fragments entirely.'
> 
> then I don't believe we would have a problem.

That would be factually wrong.  Go ahead and try it in software.
A document might specify all sorts of requirements associated with
the scheme it defines, and some users might even adhere to them,
but that won't change client behavior when processing a URI protocol
element.

> While I think this document could be improved, especially wrt to
> statements like the above where the example is not really an
> illustration of the restriction statement and attempts to use
> syntax productions to make distinctions that the productions
> don't support, I recognize the value of what the document is
> trying to accomplish and, as I have said earlier, do not want to
> hold it up over fine points of meaning and boundaries between,
> e.g., syntax and semantics.   At the same time, it cannot be in
> the IETF's best interest to have someone complicate the very
> difficult issues and choices facing the URNBIS WG by using this
> document to play "gotcha", especially if the player is one of
> the document's co-authors.
> 
> So I continue to believe that it is necessary to do at least one
> of the following:
> 
> (1) Correct this document to remove all statements or so-called
> examples that appear to impose restrictions not present in 3986
> and all ambiguities of the variety illustrated above.
> 
> (2) Alter this document to exclude existing schemes (including
> revisions of their definitions) whose definitions are included
> in or normatively referenced by standards-track documents.
> 
> (3) Alter the document to make it clear that a standards-track
> document may treat this document as advisory and override
> anything it says by providing a clear explanation of why it is
> doing so _and_ make a clear public note, in the tracker or an
> IESG statement, that language in this document can not by used
> as an authority to block discussions of alternate strategies in
> IETF WGs or other standards-track efforts.
> 
> (4) Hold this document until 2141bis (and associated documents)
> are ready and then issue a new Last Call on the two documents
> together.  Or, perhaps equivalently in practice, hold this
> document until the APPAWG and URNBIS WG can reach joint
> consensus about what it should say, at least on the subject of
> revisions to existing URH scheme definitions.

John, the only appropriate thing to do here is, once again, repeat
that 2141bis contains significant errors, and that failing to fix
those errors in your document does not, in any way, justify that
other parts of the IETF that have correctly defined their protocols
be held up until the URNbis working group decides to listen to the
input they have already received.

....Roy


From nobody Thu Apr  9 12:13:42 2015
Return-Path: 
X-Original-To: expand-draft-ietf-appsawg-uri-scheme-reg.all@virtual.ietf.org
Delivered-To: apps-discuss@ietfa.amsl.com
Received: by ietfa.amsl.com (Postfix, from userid 65534) id 027951A8A89; Thu,  9 Apr 2015 12:13:35 -0700 (PDT)
X-Original-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com
Delivered-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF5241A8A86; Thu,  9 Apr 2015 12:13:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.666
X-Spam-Level: 
X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9GSdTrkHY0wS; Thu,  9 Apr 2015 12:13:34 -0700 (PDT)
Received: from homiemail-a26.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 113561A8986; Thu,  9 Apr 2015 12:13:34 -0700 (PDT)
Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id BFBF4B8079; Thu,  9 Apr 2015 12:13:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=subject :mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=gbiv.com; bh=9xxWNBimgotqKvrDPaDypxBezd0=; b=6cm6yYzt9SDjNTN1wYfMjHyEczIK 5M3g50eDbRqCzEuzdzZPJ0aHum4fFbYAHMkuP0x1wGJ1lNws4WGGORtnQhRRQcsz XcUIGLoRqwDYCqJi0BuGyihKTAWa9wRgzCaGCaKvaYYmpS1kaInavi6K0KaulVDp go6uEyuHZRuyzJM=
Received: from [192.168.1.12] (ip68-228-83-124.oc.oc.cox.net [68.228.83.124]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTPSA id 8FE10B8058; Thu,  9 Apr 2015 12:13:32 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=us-ascii
From: "Roy T. Fielding" 
In-Reply-To: <723FBC93979E1019101319C5@JcK-HP8200.jck.com>
Date: Thu, 9 Apr 2015 12:13:30 -0700
Content-Transfer-Encoding: 7bit
Message-Id: <4EA0B2F8-5109-49EA-8BAF-0199D1640407@gbiv.com>
References: <2E49FA112B054FFAED69D8A1@JcK-HP8200.jck.com>  <723FBC93979E1019101319C5@JcK-HP8200.jck.com>
To: John C Klensin 
X-Mailer: Apple Mail (2.1283)
Archived-At: 
Cc: Apps Discuss , Barry Leiba , IESG , draft-ietf-appsawg-uri-scheme-reg.all@ietf.org
Subject: Re: [apps-discuss] Retroactive application of draft-ietf-appsawg-uri-scheme-reg - comprehensive review
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 09 Apr 2015 19:13:36 -0000

On Apr 9, 2015, at 7:41 AM, John C Klensin wrote:

>> For the specific case of urnbis, consensus on 2141bis would
>> allow it to specify how urn: registrations work, independent
>> of what's said here.  I would say that if 2141bis specifically
>> contradicts something here, it should explicitly call that
>> out, to be absolutely clear about it.
> 
> That is fine.  I would appreciate it if you and/or others who
> are relevant would figure out, now, if 2141bis said something
> contradictory to what is said in
> draft-ietf-appsawg-uri-scheme-reg whether it should be noted as
> updating this document.   I don't care what the answer is; I
> just do not want to have a time-consuming late-stage controversy
> about the issue.
> 
> More important, neither the changes nor your note address the
> particular issue that caused my review and concerns about
> draft-ietf-appsawg-uri-scheme-reg.  The issue was the claim that
> this document imposed additional constraints or requirements in
> addition to those of RFC 3986, requirements that could (or did)
> invalidate what the URNBIS WG is trying to do with
> draft-ietf-urnbis-semantics-clarif.  
> 
> I believe the key issue is that, as far as the _syntax_
> specified in RFC 3986 is concerned, there is a syntax component,
> given the name "fragment" in the defining production, that,
> informally, is delimited by the first appearance of "#" in a URI
> and that extends to the end of the URI.  Anything more --
> bindings to schemes, relationships to media types, even the
> binding of the term "fragment" to anything one might find in a
> dictionary-- are matters of semantics (or maybe something else)
> but not syntax. 

They are a product of what it is to be a URI.  Whether you call that
syntax or semantics is irrelevant.

> Consequently, when this document says, in the second paragraph
> of Section 3,
> 
> 	"A scheme definition cannot override the overall syntax
> 	for URIs.  For example, this means that fragment
> 	identifiers cannot be re-used outside the generic syntax
> 	restrictions, and fragment identifiers are not
> 	scheme-specific."
> 
> we have at statement that is at least confusing (if not a
> logical fallacy) and one that creates an opportunity for
> arguments about what an effort to specify or update a URI scheme
> (even a standards-track one associated with at WG) attempts to
> do.

No, it is a statement of fact.  Wherever a URI might be used as a
protocol element, there is an explicit role assigned to the fragment
portion of the syntax that cannot be redefined by any scheme.
Any claim to the contrary, whether that be by an individual or
by IETF standards track working group consensus, is wrong.

This does not, however, have any impact on the ability of the urn
scheme to define identifiers that exclude a fragment, nor on the
use of urn identifiers with arbitrary fragments as defined by 3986.
The fragment is part of the overall identifier -- it just isn't
dependent on the scheme and cannot be forbidden by a scheme.

The semantics, if any, for a fragment depend entirely on how the
identifier is used.  If it is used as an HTTP request-target, the
fragment portion will not be sent, regardless of the URI scheme.
The same is true for other retrieval protocols.  If the identifier
is never used for retrieval, the fragment's semantics are unbounded.

Now, you might claim that "urn" schemes are not intended for retrieval.
Even if that were true (it isn't), it still wouldn't matter.  Given any URI,
an HTTP request can be used to attempt retrieval of a representation,
which means that any URI (sans fragment) can be used for retrieval
if it is possible to configure a suitable service for such resolution,
where "suitable" is judged by the provider and users of that service,
not by the working group that defines the identifiers.

No scheme definition can escape those facts, which is why both 3986
and the scheme registration document say so explicitly.  This does
not prevent anyone from using (or not using) fragments with some
urn identifiers.  It only prevents them from escaping how they are
processed when used as a URI protocol element, since that processing
is independent of scheme.

>   In addition to whatever was intended, the statement could
> be read as "fragments are required to be allowed with all URI
> schemes and no individual scheme can prohibit them".  I'm fairly
> confident that is not what the authors of either this document
> or 3986 intended, but, if that sort of ambiguity exists, it is
> unreasonable to claim that there is informed community consensus
> about this document.

Of course that is what 3986 intended.  We have archived history of
the URI protocol discussions.  None of this should be a surprise.

> I note that the following sentence and syntax excerpt is
> completely consistent with my comment.  It shows '"#" fragment'
> as optional, which implies that it can be prohibited on a
> scheme-specific basis.  The example text just confuses things.
> 
> Note too that every syntax-defining metalanguage I've works
> with, from original BNF (which does not allow brackets of
> equivalent to optional parts) through ABNF and beyond, treats
> the sequence
> 
> URI = scheme ":" scheme-specific-part [ "#" fragment ]
> scheme-specific-part = hier-part [ "?" query ]
> 
> And
> 
>  URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]
> 
> as specifying _exactly_ the same syntax.  The distinction may be
> useful for clarity but makes no syntax distinction.

Yes, the URI syntax specifies that fragment is optional.  But the syntax
does not specify the fragment processing behavior, which is what you are
claiming the scheme has some control over.  As stated, the presence
or absence of fragment is syntax independent of the scheme.
Hence, scheme definition documents have no ability to control the
use or absence of fragments.

> If the example simply said something like:
> 
> 	'For example, this means that the "#" character cannot be
> 	used except to introduce what RFC 3986 describes as a
> 	fragment, and URI schemes cannot change that
> 	interpretation of the syntax.'
> 
> with or without an additional sentence saying:
> 
> 	'Particular scheme definitions may disallow use of
> 	fragments entirely.'
> 
> then I don't believe we would have a problem.

That would be factually wrong.  Go ahead and try it in software.
A document might specify all sorts of requirements associated with
the scheme it defines, and some users might even adhere to them,
but that won't change client behavior when processing a URI protocol
element.

> While I think this document could be improved, especially wrt to
> statements like the above where the example is not really an
> illustration of the restriction statement and attempts to use
> syntax productions to make distinctions that the productions
> don't support, I recognize the value of what the document is
> trying to accomplish and, as I have said earlier, do not want to
> hold it up over fine points of meaning and boundaries between,
> e.g., syntax and semantics.   At the same time, it cannot be in
> the IETF's best interest to have someone complicate the very
> difficult issues and choices facing the URNBIS WG by using this
> document to play "gotcha", especially if the player is one of
> the document's co-authors.
> 
> So I continue to believe that it is necessary to do at least one
> of the following:
> 
> (1) Correct this document to remove all statements or so-called
> examples that appear to impose restrictions not present in 3986
> and all ambiguities of the variety illustrated above.
> 
> (2) Alter this document to exclude existing schemes (including
> revisions of their definitions) whose definitions are included
> in or normatively referenced by standards-track documents.
> 
> (3) Alter the document to make it clear that a standards-track
> document may treat this document as advisory and override
> anything it says by providing a clear explanation of why it is
> doing so _and_ make a clear public note, in the tracker or an
> IESG statement, that language in this document can not by used
> as an authority to block discussions of alternate strategies in
> IETF WGs or other standards-track efforts.
> 
> (4) Hold this document until 2141bis (and associated documents)
> are ready and then issue a new Last Call on the two documents
> together.  Or, perhaps equivalently in practice, hold this
> document until the APPAWG and URNBIS WG can reach joint
> consensus about what it should say, at least on the subject of
> revisions to existing URH scheme definitions.

John, the only appropriate thing to do here is, once again, repeat
that 2141bis contains significant errors, and that failing to fix
those errors in your document does not, in any way, justify that
other parts of the IETF that have correctly defined their protocols
be held up until the URNbis working group decides to listen to the
input they have already received.

....Roy


From nobody Thu Apr  9 20:21:05 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 981221ABD3D for ; Thu,  9 Apr 2015 20:21:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IOEi2UZGqzF3 for ; Thu,  9 Apr 2015 20:21:01 -0700 (PDT)
Received: from mail-ie0-f169.google.com (mail-ie0-f169.google.com [209.85.223.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D6101ABD3B for ; Thu,  9 Apr 2015 20:21:01 -0700 (PDT)
Received: by iebmp1 with SMTP id mp1so8068979ieb.0 for ; Thu, 09 Apr 2015 20:21:00 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=HvC6eOpDu0UD4Y83qThACY5dnfxfcBCfifCu1zhad24=; b=LUnhl4MTsxIuEdMUKbohc9alHcWkFstjCDSPoeOPyxQbg3GQNfzFZy28M8pswRMfb7 RsX754AJ6GfQ5gH1YIg95LIayjfrKkzpLjYz4ANe5WEUC+edxDVbuDQHn/xcwMhoaDXf lvw4pyZr3irWyLlDcBfzoCV0vqCQ8i8J1EOrzpeIN0oayOjYvsW+tyd+13AjYta/6SHa N/Jlom+QYFg7n9gtLi09upyDPLKIVjzA4LUsFmq8LQDDa3NBQb8jaFiCCi8SjOP+LBc1 UIJa0xNfP5oELaby0ivS7jzAtZQUFAkizlvItOa2WOMzXk06TNZOZ/+yMO7Q3dlWc36H 0QsA==
X-Gm-Message-State: ALoCoQmqSB1hcq8ILdrUoMIIdNKXUJD9lqcKag5qRx967lZFSmOFumx6JWG2iWWaOWUnlseW6QiO
X-Received: by 10.42.250.9 with SMTP id mm9mr845230icb.56.1428636060318; Thu, 09 Apr 2015 20:21:00 -0700 (PDT)
Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id gz4sm10008283igb.19.2015.04.09.20.20.58 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Apr 2015 20:20:59 -0700 (PDT)
Message-ID: <55274198.5030309@andyet.net>
Date: Thu, 09 Apr 2015 21:20:56 -0600
From: Peter Saint-Andre - &yet 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: "Roy T. Fielding" , John C Klensin 
References: <2E49FA112B054FFAED69D8A1@JcK-HP8200.jck.com>  <723FBC93979E1019101319C5@JcK-HP8200.jck.com> <4EA0B2F8-5109-49EA-8BAF-0199D1640407@gbiv.com>
In-Reply-To: <4EA0B2F8-5109-49EA-8BAF-0199D1640407@gbiv.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: Barry Leiba , draft-ietf-appsawg-uri-scheme-reg.all@ietf.org, IESG , Apps Discuss 
Subject: Re: [apps-discuss] Retroactive application of draft-ietf-appsawg-uri-scheme-reg - comprehensive review
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Apr 2015 03:21:03 -0000

On 4/9/15 1:13 PM, Roy T. Fielding wrote:
> On Apr 9, 2015, at 7:41 AM, John C Klensin wrote:
>
>>> For the specific case of urnbis, consensus on 2141bis would
>>> allow it to specify how urn: registrations work, independent
>>> of what's said here.  I would say that if 2141bis specifically
>>> contradicts something here, it should explicitly call that
>>> out, to be absolutely clear about it.
>>
>> That is fine.  I would appreciate it if you and/or others who
>> are relevant would figure out, now, if 2141bis said something
>> contradictory to what is said in
>> draft-ietf-appsawg-uri-scheme-reg whether it should be noted as
>> updating this document.   I don't care what the answer is; I
>> just do not want to have a time-consuming late-stage controversy
>> about the issue.
>>
>> More important, neither the changes nor your note address the
>> particular issue that caused my review and concerns about
>> draft-ietf-appsawg-uri-scheme-reg.  The issue was the claim that
>> this document imposed additional constraints or requirements in
>> addition to those of RFC 3986, requirements that could (or did)
>> invalidate what the URNBIS WG is trying to do with
>> draft-ietf-urnbis-semantics-clarif.
>>
>> I believe the key issue is that, as far as the _syntax_
>> specified in RFC 3986 is concerned, there is a syntax component,
>> given the name "fragment" in the defining production, that,
>> informally, is delimited by the first appearance of "#" in a URI
>> and that extends to the end of the URI.  Anything more --
>> bindings to schemes, relationships to media types, even the
>> binding of the term "fragment" to anything one might find in a
>> dictionary-- are matters of semantics (or maybe something else)
>> but not syntax.
>
> They are a product of what it is to be a URI.  Whether you call that
> syntax or semantics is irrelevant.
>
>> Consequently, when this document says, in the second paragraph
>> of Section 3,
>>
>> 	"A scheme definition cannot override the overall syntax
>> 	for URIs.  For example, this means that fragment
>> 	identifiers cannot be re-used outside the generic syntax
>> 	restrictions, and fragment identifiers are not
>> 	scheme-specific."
>>
>> we have at statement that is at least confusing (if not a
>> logical fallacy) and one that creates an opportunity for
>> arguments about what an effort to specify or update a URI scheme
>> (even a standards-track one associated with at WG) attempts to
>> do.
>
> No, it is a statement of fact.  Wherever a URI might be used as a
> protocol element, there is an explicit role assigned to the fragment
> portion of the syntax that cannot be redefined by any scheme.

My understanding of "role" here is that you probably intend it to denote 
a specific semantic meaning.

> Any claim to the contrary, whether that be by an individual or
> by IETF standards track working group consensus, is wrong.
>
> This does not, however, have any impact on the ability of the urn
> scheme to define identifiers that exclude a fragment, nor on the
> use of urn identifiers with arbitrary fragments as defined by 3986.
> The fragment is part of the overall identifier -- it just isn't
> dependent on the scheme and cannot be forbidden by a scheme.

If I understand this correctly, it means that no scheme can say that 
URIs in general cannot contain fragment identifiers. But no scheme 
definition tries to do that, AFAIK.

> The semantics, if any, for a fragment depend entirely on how the
> identifier is used.  If it is used as an HTTP request-target, the
> fragment portion will not be sent, regardless of the URI scheme.
> The same is true for other retrieval protocols.  If the identifier
> is never used for retrieval, the fragment's semantics are unbounded.
>
> Now, you might claim that "urn" schemes are not intended for retrieval.
> Even if that were true (it isn't), it still wouldn't matter.  Given any URI,
> an HTTP request can be used to attempt retrieval of a representation,
> which means that any URI (sans fragment) can be used for retrieval

What does it mean to make an HTTP request for, say, a SIP URI?

> if it is possible to configure a suitable service for such resolution,
> where "suitable" is judged by the provider and users of that service,
> not by the working group that defines the identifiers.
>
> No scheme definition can escape those facts, which is why both 3986
> and the scheme registration document say so explicitly.

I don't see anything in RFC 3986 that says a URI must be "resolvable" 
via HTTP.

> This does
> not prevent anyone from using (or not using) fragments with some
> urn identifiers.  It only prevents them from escaping how they are
> processed when used as a URI protocol element, since that processing
> is independent of scheme.

But IMHO it doesn't always make sense to use URIs with any random URI 
scheme in any given URI protocol slot. What does it mean to place a 
'sip' or 'data' or 'iax' or 'msrp' (etc.) URI in the 'xmlns' protocol 
slot in XML? What does it mean to place an 'http' URI in the Request-URI 
protocol slot in SIP? (In fact, RFC 3261 says that only a SIP or SIPS 
URI is allowed there.) To say that every protocol slot in which a URI 
can appear must accept URIs from all schemes seems off-base to me.

>>    In addition to whatever was intended, the statement could
>> be read as "fragments are required to be allowed with all URI
>> schemes and no individual scheme can prohibit them".  I'm fairly
>> confident that is not what the authors of either this document
>> or 3986 intended, but, if that sort of ambiguity exists, it is
>> unreasonable to claim that there is informed community consensus
>> about this document.
>
> Of course that is what 3986 intended.  We have archived history of
> the URI protocol discussions.  None of this should be a surprise.

No scheme can prohibit fragments in that scheme as a matter of "local 
policy" (as it were), or no scheme can prohibit fragments in general?



Peter

-- 
Peter Saint-Andre
https://andyet.com/


From nobody Thu Apr  9 20:21:09 2015
Return-Path: 
X-Original-To: expand-draft-ietf-appsawg-uri-scheme-reg.all@virtual.ietf.org
Delivered-To: apps-discuss@ietfa.amsl.com
Received: by ietfa.amsl.com (Postfix, from userid 65534) id 6A8E01ABD3C; Thu,  9 Apr 2015 20:21:05 -0700 (PDT)
X-Original-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com
Delivered-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5137F1ABD39 for ; Thu,  9 Apr 2015 20:21:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JHcfoLwJnVkQ for ; Thu,  9 Apr 2015 20:21:03 -0700 (PDT)
Received: from mail-ig0-f180.google.com (mail-ig0-f180.google.com [209.85.213.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F35411ABC75 for ; Thu,  9 Apr 2015 20:21:00 -0700 (PDT)
Received: by igbqf9 with SMTP id qf9so8016110igb.1 for ; Thu, 09 Apr 2015 20:21:00 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=HvC6eOpDu0UD4Y83qThACY5dnfxfcBCfifCu1zhad24=; b=gXdPeECEVwP7kI7sje0b9dUdLlQ1UgOGaDnjgJekzMS/e3YEg4ffPxHKcmfKPAnmOo Oqj58wzBxNxF5xPJduorJlSv17V8iZPxDYRh7e0VNhc2Fcw0xM9FgU2o2XXYFxYvKoDX luBLeI1MKj83uQs6VQizGmFinLeUE9QE6Jddlmt9GUgu4Te/0/zXJyqhS6wdJYCLORb2 +2AZFkq73dyW8nzvbqusjVliaJcmv1/TVLiCtkJYpHTD9TgEBmovLrn8zg3dqUXinIAb S53G/iVlXHO/UVQq/9FEYVdRLmP+GOSrEnAQNyhGLlRpwyHWMJEAhd6BRf8dy5SVBdOt cBbA==
X-Gm-Message-State: ALoCoQnAfhTTsF0FyGkLK5fJT45gZgv+aVgp6wT7rxN/gaC6YfCD44UUKQvqkzVm7lCU5QqdrMEu
X-Received: by 10.42.250.9 with SMTP id mm9mr845230icb.56.1428636060318; Thu, 09 Apr 2015 20:21:00 -0700 (PDT)
Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id gz4sm10008283igb.19.2015.04.09.20.20.58 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Apr 2015 20:20:59 -0700 (PDT)
Message-ID: <55274198.5030309@andyet.net>
Date: Thu, 09 Apr 2015 21:20:56 -0600
From: Peter Saint-Andre - &yet 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: "Roy T. Fielding" , John C Klensin 
References: <2E49FA112B054FFAED69D8A1@JcK-HP8200.jck.com>  <723FBC93979E1019101319C5@JcK-HP8200.jck.com> <4EA0B2F8-5109-49EA-8BAF-0199D1640407@gbiv.com>
In-Reply-To: <4EA0B2F8-5109-49EA-8BAF-0199D1640407@gbiv.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: Barry Leiba , draft-ietf-appsawg-uri-scheme-reg.all@ietf.org, IESG , Apps Discuss 
Subject: Re: [apps-discuss] Retroactive application of draft-ietf-appsawg-uri-scheme-reg - comprehensive review
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Apr 2015 03:21:05 -0000

On 4/9/15 1:13 PM, Roy T. Fielding wrote:
> On Apr 9, 2015, at 7:41 AM, John C Klensin wrote:
>
>>> For the specific case of urnbis, consensus on 2141bis would
>>> allow it to specify how urn: registrations work, independent
>>> of what's said here.  I would say that if 2141bis specifically
>>> contradicts something here, it should explicitly call that
>>> out, to be absolutely clear about it.
>>
>> That is fine.  I would appreciate it if you and/or others who
>> are relevant would figure out, now, if 2141bis said something
>> contradictory to what is said in
>> draft-ietf-appsawg-uri-scheme-reg whether it should be noted as
>> updating this document.   I don't care what the answer is; I
>> just do not want to have a time-consuming late-stage controversy
>> about the issue.
>>
>> More important, neither the changes nor your note address the
>> particular issue that caused my review and concerns about
>> draft-ietf-appsawg-uri-scheme-reg.  The issue was the claim that
>> this document imposed additional constraints or requirements in
>> addition to those of RFC 3986, requirements that could (or did)
>> invalidate what the URNBIS WG is trying to do with
>> draft-ietf-urnbis-semantics-clarif.
>>
>> I believe the key issue is that, as far as the _syntax_
>> specified in RFC 3986 is concerned, there is a syntax component,
>> given the name "fragment" in the defining production, that,
>> informally, is delimited by the first appearance of "#" in a URI
>> and that extends to the end of the URI.  Anything more --
>> bindings to schemes, relationships to media types, even the
>> binding of the term "fragment" to anything one might find in a
>> dictionary-- are matters of semantics (or maybe something else)
>> but not syntax.
>
> They are a product of what it is to be a URI.  Whether you call that
> syntax or semantics is irrelevant.
>
>> Consequently, when this document says, in the second paragraph
>> of Section 3,
>>
>> 	"A scheme definition cannot override the overall syntax
>> 	for URIs.  For example, this means that fragment
>> 	identifiers cannot be re-used outside the generic syntax
>> 	restrictions, and fragment identifiers are not
>> 	scheme-specific."
>>
>> we have at statement that is at least confusing (if not a
>> logical fallacy) and one that creates an opportunity for
>> arguments about what an effort to specify or update a URI scheme
>> (even a standards-track one associated with at WG) attempts to
>> do.
>
> No, it is a statement of fact.  Wherever a URI might be used as a
> protocol element, there is an explicit role assigned to the fragment
> portion of the syntax that cannot be redefined by any scheme.

My understanding of "role" here is that you probably intend it to denote 
a specific semantic meaning.

> Any claim to the contrary, whether that be by an individual or
> by IETF standards track working group consensus, is wrong.
>
> This does not, however, have any impact on the ability of the urn
> scheme to define identifiers that exclude a fragment, nor on the
> use of urn identifiers with arbitrary fragments as defined by 3986.
> The fragment is part of the overall identifier -- it just isn't
> dependent on the scheme and cannot be forbidden by a scheme.

If I understand this correctly, it means that no scheme can say that 
URIs in general cannot contain fragment identifiers. But no scheme 
definition tries to do that, AFAIK.

> The semantics, if any, for a fragment depend entirely on how the
> identifier is used.  If it is used as an HTTP request-target, the
> fragment portion will not be sent, regardless of the URI scheme.
> The same is true for other retrieval protocols.  If the identifier
> is never used for retrieval, the fragment's semantics are unbounded.
>
> Now, you might claim that "urn" schemes are not intended for retrieval.
> Even if that were true (it isn't), it still wouldn't matter.  Given any URI,
> an HTTP request can be used to attempt retrieval of a representation,
> which means that any URI (sans fragment) can be used for retrieval

What does it mean to make an HTTP request for, say, a SIP URI?

> if it is possible to configure a suitable service for such resolution,
> where "suitable" is judged by the provider and users of that service,
> not by the working group that defines the identifiers.
>
> No scheme definition can escape those facts, which is why both 3986
> and the scheme registration document say so explicitly.

I don't see anything in RFC 3986 that says a URI must be "resolvable" 
via HTTP.

> This does
> not prevent anyone from using (or not using) fragments with some
> urn identifiers.  It only prevents them from escaping how they are
> processed when used as a URI protocol element, since that processing
> is independent of scheme.

But IMHO it doesn't always make sense to use URIs with any random URI 
scheme in any given URI protocol slot. What does it mean to place a 
'sip' or 'data' or 'iax' or 'msrp' (etc.) URI in the 'xmlns' protocol 
slot in XML? What does it mean to place an 'http' URI in the Request-URI 
protocol slot in SIP? (In fact, RFC 3261 says that only a SIP or SIPS 
URI is allowed there.) To say that every protocol slot in which a URI 
can appear must accept URIs from all schemes seems off-base to me.

>>    In addition to whatever was intended, the statement could
>> be read as "fragments are required to be allowed with all URI
>> schemes and no individual scheme can prohibit them".  I'm fairly
>> confident that is not what the authors of either this document
>> or 3986 intended, but, if that sort of ambiguity exists, it is
>> unreasonable to claim that there is informed community consensus
>> about this document.
>
> Of course that is what 3986 intended.  We have archived history of
> the URI protocol discussions.  None of this should be a surprise.

No scheme can prohibit fragments in that scheme as a matter of "local 
policy" (as it were), or no scheme can prohibit fragments in general?



Peter

-- 
Peter Saint-Andre
https://andyet.com/


From nobody Thu Apr  9 21:42:55 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B84301B2E5F; Thu,  9 Apr 2015 21:42:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.666
X-Spam-Level: 
X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qd0WnnXCxk0l; Thu,  9 Apr 2015 21:42:46 -0700 (PDT)
Received: from homiemail-a27.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 023EB1B2DAC; Thu,  9 Apr 2015 21:42:46 -0700 (PDT)
Received: from homiemail-a27.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTP id B0F82598085; Thu,  9 Apr 2015 21:42:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=content-type :mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=gbiv.com; bh=edsX5PxRutdRkR7U/w0EhPQg8oU=; b=b4hlfwcBhpcHfki+YSGAmgsCQ20W FUYZarI7CPE/pGvDj9wsqdZGERdiClUXnwJhUSDAf5K4HRsCtjMOJ7wK3Fj2H2SL CUzWAUzKVn/x1tD+DYXFPu1cwcAq4phtTKVV8FylKaM02SKdf9HmlFrMWsrfw6cy XkvbX3hNj8C1jIk=
Received: from [192.168.1.38] (ip68-228-83-124.oc.oc.cox.net [68.228.83.124]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTPSA id 9CCF1598055; Thu,  9 Apr 2015 21:42:45 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
From: "Roy T. Fielding" 
X-Mailer: iPhone Mail (12D508)
In-Reply-To: <55274198.5030309@andyet.net>
Date: Thu, 9 Apr 2015 21:42:44 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <2E49FA112B054FFAED69D8A1@JcK-HP8200.jck.com>  <723FBC93979E1019101319C5@JcK-HP8200.jck.com> <4EA0B2F8-5109-49EA-8BAF-0199D1640407@gbiv.com> <55274198.5030309@andyet.net>
To: Peter Saint-Andre - &yet 
Archived-At: 
Cc: Barry Leiba , "draft-ietf-appsawg-uri-scheme-reg.all@ietf.org" , IESG , Apps Discuss 
Subject: Re: [apps-discuss] Retroactive application of draft-ietf-appsawg-uri-scheme-reg - comprehensive review
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Apr 2015 04:42:47 -0000

>=20
> On Apr 9, 2015, at 8:20 PM, Peter Saint-Andre - &yet  wr=
ote:
>=20
>> On 4/9/15 1:13 PM, Roy T. Fielding wrote:
>> On Apr 9, 2015, at 7:41 AM, John C Klensin wrote:
>>=20
>>>> For the specific case of urnbis, consensus on 2141bis would
>>>> allow it to specify how urn: registrations work, independent
>>>> of what's said here.  I would say that if 2141bis specifically
>>>> contradicts something here, it should explicitly call that
>>>> out, to be absolutely clear about it.
>>>=20
>>> That is fine.  I would appreciate it if you and/or others who
>>> are relevant would figure out, now, if 2141bis said something
>>> contradictory to what is said in
>>> draft-ietf-appsawg-uri-scheme-reg whether it should be noted as
>>> updating this document.   I don't care what the answer is; I
>>> just do not want to have a time-consuming late-stage controversy
>>> about the issue.
>>>=20
>>> More important, neither the changes nor your note address the
>>> particular issue that caused my review and concerns about
>>> draft-ietf-appsawg-uri-scheme-reg.  The issue was the claim that
>>> this document imposed additional constraints or requirements in
>>> addition to those of RFC 3986, requirements that could (or did)
>>> invalidate what the URNBIS WG is trying to do with
>>> draft-ietf-urnbis-semantics-clarif.
>>>=20
>>> I believe the key issue is that, as far as the _syntax_
>>> specified in RFC 3986 is concerned, there is a syntax component,
>>> given the name "fragment" in the defining production, that,
>>> informally, is delimited by the first appearance of "#" in a URI
>>> and that extends to the end of the URI.  Anything more --
>>> bindings to schemes, relationships to media types, even the
>>> binding of the term "fragment" to anything one might find in a
>>> dictionary-- are matters of semantics (or maybe something else)
>>> but not syntax.
>>=20
>> They are a product of what it is to be a URI.  Whether you call that
>> syntax or semantics is irrelevant.
>>=20
>>> Consequently, when this document says, in the second paragraph
>>> of Section 3,
>>>=20
>>>    "A scheme definition cannot override the overall syntax
>>>    for URIs.  For example, this means that fragment
>>>    identifiers cannot be re-used outside the generic syntax
>>>    restrictions, and fragment identifiers are not
>>>    scheme-specific."
>>>=20
>>> we have at statement that is at least confusing (if not a
>>> logical fallacy) and one that creates an opportunity for
>>> arguments about what an effort to specify or update a URI scheme
>>> (even a standards-track one associated with at WG) attempts to
>>> do.
>>=20
>> No, it is a statement of fact.  Wherever a URI might be used as a
>> protocol element, there is an explicit role assigned to the fragment
>> portion of the syntax that cannot be redefined by any scheme.
>=20
> My understanding of "role" here is that you probably intend it to denote a=
 specific semantic meaning.

No. It is a piece of syntax reserved for a specific role in the processing o=
f hypertext references. It might gain semantics when used in a certain way, b=
ut it doesn't have semantics in and of itself (or at least no more semantics=
 than any other name).

>=20
>> Any claim to the contrary, whether that be by an individual or
>> by IETF standards track working group consensus, is wrong.
>>=20
>> This does not, however, have any impact on the ability of the urn
>> scheme to define identifiers that exclude a fragment, nor on the
>> use of urn identifiers with arbitrary fragments as defined by 3986.
>> The fragment is part of the overall identifier -- it just isn't
>> dependent on the scheme and cannot be forbidden by a scheme.
>=20
> If I understand this correctly, it means that no scheme can say that URIs i=
n general cannot contain fragment identifiers. But no scheme definition trie=
s to do that, AFAIK.

The fragment doesn't have anything to do with the scheme, period. This is a l=
ayer violation as obvious as defining TLS within HTTP. Yes, we do that some t=
imes, but that doesn't make it right. If you don't want that role to be in e=
ffect, then don't use fragment.

>=20
>> The semantics, if any, for a fragment depend entirely on how the
>> identifier is used.  If it is used as an HTTP request-target, the
>> fragment portion will not be sent, regardless of the URI scheme.
>> The same is true for other retrieval protocols.  If the identifier
>> is never used for retrieval, the fragment's semantics are unbounded.
>>=20
>> Now, you might claim that "urn" schemes are not intended for retrieval.
>> Even if that were true (it isn't), it still wouldn't matter.  Given any U=
RI,
>> an HTTP request can be used to attempt retrieval of a representation,
>> which means that any URI (sans fragment) can be used for retrieval
>=20
> What does it mean to make an HTTP request for, say, a SIP URI?

What does it mean to make a Web request for a SIP URI? It doesn't have to be=
 using HTTP. If you can define what it means for SIP, then it can be represe=
nted via HTTP as well. If not, then the attempt will fail. Nevertheless, the=
 attempt will exclude the fragment because that information is reserved for c=
lient-side processing (if any). =20

If such a URI is never used in that fashion, then no semantics are assumed f=
or the fragment. This does not mean a scheme like sip can redefine or disall=
ow fragments, since it doesn't control how its identifiers might be used.

>> if it is possible to configure a suitable service for such resolution,
>> where "suitable" is judged by the provider and users of that service,
>> not by the working group that defines the identifiers.
>>=20
>> No scheme definition can escape those facts, which is why both 3986
>> and the scheme registration document say so explicitly.
>=20
> I don't see anything in RFC 3986 that says a URI must be "resolvable" via H=
TTP.

There is no need for it to say anything like that. It does not change the fa=
ct that the fragment has a specific role when present in a URI. It is a unif=
orm syntax for a reason.

>=20
>> This does
>> not prevent anyone from using (or not using) fragments with some
>> urn identifiers.  It only prevents them from escaping how they are
>> processed when used as a URI protocol element, since that processing
>> is independent of scheme.
>=20
> But IMHO it doesn't always make sense to use URIs with any random URI sche=
me in any given URI protocol slot. What does it mean to place a 'sip' or 'da=
ta' or 'iax' or 'msrp' (etc.) URI in the 'xmlns' protocol slot in XML? What d=
oes it mean to place an 'http' URI in the Request-URI protocol slot in SIP? (=
In fact, RFC 3261 says that only a SIP or SIPS URI is allowed there.) To say=
 that every protocol slot in which a URI can appear must accept URIs from al=
l schemes seems off-base to me.

It doesn't matter. To the extent that some use is not allowed or simply does=
n't make sense, the fragment remains free of any semantics and can be used a=
s a name. It can therefore be used with such URIs even if the scheme is comp=
letely unaware of its possible existence.

>>>   In addition to whatever was intended, the statement could
>>> be read as "fragments are required to be allowed with all URI
>>> schemes and no individual scheme can prohibit them".  I'm fairly
>>> confident that is not what the authors of either this document
>>> or 3986 intended, but, if that sort of ambiguity exists, it is
>>> unreasonable to claim that there is informed community consensus
>>> about this document.
>>=20
>> Of course that is what 3986 intended.  We have archived history of
>> the URI protocol discussions.  None of this should be a surprise.
>=20
> No scheme can prohibit fragments in that scheme as a matter of "local poli=
cy" (as it were), or no scheme can prohibit fragments in general?

No scheme can prohibit fragments. They are not part of the scheme's syntax.

....Roy


From nobody Thu Apr  9 21:42:57 2015
Return-Path: 
X-Original-To: expand-draft-ietf-appsawg-uri-scheme-reg.all@virtual.ietf.org
Delivered-To: apps-discuss@ietfa.amsl.com
Received: by ietfa.amsl.com (Postfix, from userid 65534) id D93051B2E70; Thu,  9 Apr 2015 21:42:47 -0700 (PDT)
X-Original-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com
Delivered-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B84301B2E5F; Thu,  9 Apr 2015 21:42:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.666
X-Spam-Level: 
X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qd0WnnXCxk0l; Thu,  9 Apr 2015 21:42:46 -0700 (PDT)
Received: from homiemail-a27.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 023EB1B2DAC; Thu,  9 Apr 2015 21:42:46 -0700 (PDT)
Received: from homiemail-a27.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTP id B0F82598085; Thu,  9 Apr 2015 21:42:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=content-type :mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=gbiv.com; bh=edsX5PxRutdRkR7U/w0EhPQg8oU=; b=b4hlfwcBhpcHfki+YSGAmgsCQ20W FUYZarI7CPE/pGvDj9wsqdZGERdiClUXnwJhUSDAf5K4HRsCtjMOJ7wK3Fj2H2SL CUzWAUzKVn/x1tD+DYXFPu1cwcAq4phtTKVV8FylKaM02SKdf9HmlFrMWsrfw6cy XkvbX3hNj8C1jIk=
Received: from [192.168.1.38] (ip68-228-83-124.oc.oc.cox.net [68.228.83.124]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTPSA id 9CCF1598055; Thu,  9 Apr 2015 21:42:45 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
From: "Roy T. Fielding" 
X-Mailer: iPhone Mail (12D508)
In-Reply-To: <55274198.5030309@andyet.net>
Date: Thu, 9 Apr 2015 21:42:44 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <2E49FA112B054FFAED69D8A1@JcK-HP8200.jck.com>  <723FBC93979E1019101319C5@JcK-HP8200.jck.com> <4EA0B2F8-5109-49EA-8BAF-0199D1640407@gbiv.com> <55274198.5030309@andyet.net>
To: Peter Saint-Andre - &yet 
Archived-At: 
Cc: Barry Leiba , "draft-ietf-appsawg-uri-scheme-reg.all@ietf.org" , IESG , Apps Discuss 
Subject: Re: [apps-discuss] Retroactive application of draft-ietf-appsawg-uri-scheme-reg - comprehensive review
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Apr 2015 04:42:48 -0000

>=20
> On Apr 9, 2015, at 8:20 PM, Peter Saint-Andre - &yet  wr=
ote:
>=20
>> On 4/9/15 1:13 PM, Roy T. Fielding wrote:
>> On Apr 9, 2015, at 7:41 AM, John C Klensin wrote:
>>=20
>>>> For the specific case of urnbis, consensus on 2141bis would
>>>> allow it to specify how urn: registrations work, independent
>>>> of what's said here.  I would say that if 2141bis specifically
>>>> contradicts something here, it should explicitly call that
>>>> out, to be absolutely clear about it.
>>>=20
>>> That is fine.  I would appreciate it if you and/or others who
>>> are relevant would figure out, now, if 2141bis said something
>>> contradictory to what is said in
>>> draft-ietf-appsawg-uri-scheme-reg whether it should be noted as
>>> updating this document.   I don't care what the answer is; I
>>> just do not want to have a time-consuming late-stage controversy
>>> about the issue.
>>>=20
>>> More important, neither the changes nor your note address the
>>> particular issue that caused my review and concerns about
>>> draft-ietf-appsawg-uri-scheme-reg.  The issue was the claim that
>>> this document imposed additional constraints or requirements in
>>> addition to those of RFC 3986, requirements that could (or did)
>>> invalidate what the URNBIS WG is trying to do with
>>> draft-ietf-urnbis-semantics-clarif.
>>>=20
>>> I believe the key issue is that, as far as the _syntax_
>>> specified in RFC 3986 is concerned, there is a syntax component,
>>> given the name "fragment" in the defining production, that,
>>> informally, is delimited by the first appearance of "#" in a URI
>>> and that extends to the end of the URI.  Anything more --
>>> bindings to schemes, relationships to media types, even the
>>> binding of the term "fragment" to anything one might find in a
>>> dictionary-- are matters of semantics (or maybe something else)
>>> but not syntax.
>>=20
>> They are a product of what it is to be a URI.  Whether you call that
>> syntax or semantics is irrelevant.
>>=20
>>> Consequently, when this document says, in the second paragraph
>>> of Section 3,
>>>=20
>>>    "A scheme definition cannot override the overall syntax
>>>    for URIs.  For example, this means that fragment
>>>    identifiers cannot be re-used outside the generic syntax
>>>    restrictions, and fragment identifiers are not
>>>    scheme-specific."
>>>=20
>>> we have at statement that is at least confusing (if not a
>>> logical fallacy) and one that creates an opportunity for
>>> arguments about what an effort to specify or update a URI scheme
>>> (even a standards-track one associated with at WG) attempts to
>>> do.
>>=20
>> No, it is a statement of fact.  Wherever a URI might be used as a
>> protocol element, there is an explicit role assigned to the fragment
>> portion of the syntax that cannot be redefined by any scheme.
>=20
> My understanding of "role" here is that you probably intend it to denote a=
 specific semantic meaning.

No. It is a piece of syntax reserved for a specific role in the processing o=
f hypertext references. It might gain semantics when used in a certain way, b=
ut it doesn't have semantics in and of itself (or at least no more semantics=
 than any other name).

>=20
>> Any claim to the contrary, whether that be by an individual or
>> by IETF standards track working group consensus, is wrong.
>>=20
>> This does not, however, have any impact on the ability of the urn
>> scheme to define identifiers that exclude a fragment, nor on the
>> use of urn identifiers with arbitrary fragments as defined by 3986.
>> The fragment is part of the overall identifier -- it just isn't
>> dependent on the scheme and cannot be forbidden by a scheme.
>=20
> If I understand this correctly, it means that no scheme can say that URIs i=
n general cannot contain fragment identifiers. But no scheme definition trie=
s to do that, AFAIK.

The fragment doesn't have anything to do with the scheme, period. This is a l=
ayer violation as obvious as defining TLS within HTTP. Yes, we do that some t=
imes, but that doesn't make it right. If you don't want that role to be in e=
ffect, then don't use fragment.

>=20
>> The semantics, if any, for a fragment depend entirely on how the
>> identifier is used.  If it is used as an HTTP request-target, the
>> fragment portion will not be sent, regardless of the URI scheme.
>> The same is true for other retrieval protocols.  If the identifier
>> is never used for retrieval, the fragment's semantics are unbounded.
>>=20
>> Now, you might claim that "urn" schemes are not intended for retrieval.
>> Even if that were true (it isn't), it still wouldn't matter.  Given any U=
RI,
>> an HTTP request can be used to attempt retrieval of a representation,
>> which means that any URI (sans fragment) can be used for retrieval
>=20
> What does it mean to make an HTTP request for, say, a SIP URI?

What does it mean to make a Web request for a SIP URI? It doesn't have to be=
 using HTTP. If you can define what it means for SIP, then it can be represe=
nted via HTTP as well. If not, then the attempt will fail. Nevertheless, the=
 attempt will exclude the fragment because that information is reserved for c=
lient-side processing (if any). =20

If such a URI is never used in that fashion, then no semantics are assumed f=
or the fragment. This does not mean a scheme like sip can redefine or disall=
ow fragments, since it doesn't control how its identifiers might be used.

>> if it is possible to configure a suitable service for such resolution,
>> where "suitable" is judged by the provider and users of that service,
>> not by the working group that defines the identifiers.
>>=20
>> No scheme definition can escape those facts, which is why both 3986
>> and the scheme registration document say so explicitly.
>=20
> I don't see anything in RFC 3986 that says a URI must be "resolvable" via H=
TTP.

There is no need for it to say anything like that. It does not change the fa=
ct that the fragment has a specific role when present in a URI. It is a unif=
orm syntax for a reason.

>=20
>> This does
>> not prevent anyone from using (or not using) fragments with some
>> urn identifiers.  It only prevents them from escaping how they are
>> processed when used as a URI protocol element, since that processing
>> is independent of scheme.
>=20
> But IMHO it doesn't always make sense to use URIs with any random URI sche=
me in any given URI protocol slot. What does it mean to place a 'sip' or 'da=
ta' or 'iax' or 'msrp' (etc.) URI in the 'xmlns' protocol slot in XML? What d=
oes it mean to place an 'http' URI in the Request-URI protocol slot in SIP? (=
In fact, RFC 3261 says that only a SIP or SIPS URI is allowed there.) To say=
 that every protocol slot in which a URI can appear must accept URIs from al=
l schemes seems off-base to me.

It doesn't matter. To the extent that some use is not allowed or simply does=
n't make sense, the fragment remains free of any semantics and can be used a=
s a name. It can therefore be used with such URIs even if the scheme is comp=
letely unaware of its possible existence.

>>>   In addition to whatever was intended, the statement could
>>> be read as "fragments are required to be allowed with all URI
>>> schemes and no individual scheme can prohibit them".  I'm fairly
>>> confident that is not what the authors of either this document
>>> or 3986 intended, but, if that sort of ambiguity exists, it is
>>> unreasonable to claim that there is informed community consensus
>>> about this document.
>>=20
>> Of course that is what 3986 intended.  We have archived history of
>> the URI protocol discussions.  None of this should be a surprise.
>=20
> No scheme can prohibit fragments in that scheme as a matter of "local poli=
cy" (as it were), or no scheme can prohibit fragments in general?

No scheme can prohibit fragments. They are not part of the scheme's syntax.

....Roy


From nobody Fri Apr 10 00:43:53 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D18A91B2A57; Fri, 10 Apr 2015 00:43:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 294Zfv3Ivt1B; Fri, 10 Apr 2015 00:43:47 -0700 (PDT)
Received: from relay11.mail.ox.ac.uk (relay11.mail.ox.ac.uk [129.67.1.162]) by ietfa.amsl.com (Postfix) with ESMTP id 3B2C21B2A66; Fri, 10 Apr 2015 00:43:20 -0700 (PDT)
Received: from smtp4.mail.ox.ac.uk ([129.67.1.207]) by relay11.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1YgTav-0007dT-Zs; Fri, 10 Apr 2015 08:43:17 +0100
Received: from host109-152-232-46.range109-152.btcentralplus.com ([109.152.232.46] helo=cheery.atuin.ninebynine.org) by smtp4.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YgTau-0005zJ-Fx; Fri, 10 Apr 2015 08:43:16 +0100
Message-ID: <55277F13.8020409@ninebynine.org>
Date: Fri, 10 Apr 2015 08:43:15 +0100
From: Graham Klyne 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: "Roy T. Fielding" ,  Peter Saint-Andre - &yet 
References: <2E49FA112B054FFAED69D8A1@JcK-HP8200.jck.com>  <723FBC93979E1019101319C5@JcK-HP8200.jck.com> <4EA0B2F8-5109-49EA-8BAF-0199D1640407@gbiv.com> <55274198.5030309@andyet.net> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Oxford-Username: zool0635
Archived-At: 
Cc: Apps Discuss , Barry Leiba , IESG , "draft-ietf-appsawg-uri-scheme-reg.all@ietf.org" 
Subject: Re: [apps-discuss] Retroactive application of draft-ietf-appsawg-uri-scheme-reg - comprehensive review
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Apr 2015 07:43:49 -0000

On 10/04/2015 05:42, Roy T. Fielding wrote:
>>
>> On Apr 9, 2015, at 8:20 PM, Peter Saint-Andre - &yet  wrote:
>>
>> What does it mean to make an HTTP request for, say, a SIP URI?
>
> What does it mean to make a Web request for a SIP URI? It doesn't have to be using HTTP. If you can define what it means for SIP, then it can be represented via HTTP as well. If not, then the attempt will fail. Nevertheless, the attempt will exclude the fragment because that information is reserved for client-side processing (if any).
>
> If such a URI is never used in that fashion, then no semantics are assumed for the fragment. This does not mean a scheme like sip can redefine or disallow fragments, since it doesn't control how its identifiers might be used.
>

My understanding is that a request to an HTTP server may convey a SIP 
request-URI, and it's up to the configuration of the receiving (gateway?) server 
what it does with it.

(Was it not once common to issue ftp: requests through HTTP in this way?)

I believe that the HTTP prohibition on including a fragment identifier would 
still apply here.

#g
--


From nobody Fri Apr 10 00:43:54 2015
Return-Path: 
X-Original-To: expand-draft-ietf-appsawg-uri-scheme-reg.all@virtual.ietf.org
Delivered-To: apps-discuss@ietfa.amsl.com
Received: by ietfa.amsl.com (Postfix, from userid 65534) id 013021B2A5D; Fri, 10 Apr 2015 00:43:48 -0700 (PDT)
X-Original-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com
Delivered-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D18A91B2A57; Fri, 10 Apr 2015 00:43:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 294Zfv3Ivt1B; Fri, 10 Apr 2015 00:43:47 -0700 (PDT)
Received: from relay11.mail.ox.ac.uk (relay11.mail.ox.ac.uk [129.67.1.162]) by ietfa.amsl.com (Postfix) with ESMTP id 3B2C21B2A66; Fri, 10 Apr 2015 00:43:20 -0700 (PDT)
Received: from smtp4.mail.ox.ac.uk ([129.67.1.207]) by relay11.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1YgTav-0007dT-Zs; Fri, 10 Apr 2015 08:43:17 +0100
Received: from host109-152-232-46.range109-152.btcentralplus.com ([109.152.232.46] helo=cheery.atuin.ninebynine.org) by smtp4.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YgTau-0005zJ-Fx; Fri, 10 Apr 2015 08:43:16 +0100
Message-ID: <55277F13.8020409@ninebynine.org>
Date: Fri, 10 Apr 2015 08:43:15 +0100
From: Graham Klyne 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: "Roy T. Fielding" ,  Peter Saint-Andre - &yet 
References: <2E49FA112B054FFAED69D8A1@JcK-HP8200.jck.com>  <723FBC93979E1019101319C5@JcK-HP8200.jck.com> <4EA0B2F8-5109-49EA-8BAF-0199D1640407@gbiv.com> <55274198.5030309@andyet.net> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Oxford-Username: zool0635
Archived-At: 
Cc: Apps Discuss , Barry Leiba , IESG , "draft-ietf-appsawg-uri-scheme-reg.all@ietf.org" 
Subject: Re: [apps-discuss] Retroactive application of draft-ietf-appsawg-uri-scheme-reg - comprehensive review
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Apr 2015 07:43:49 -0000

On 10/04/2015 05:42, Roy T. Fielding wrote:
>>
>> On Apr 9, 2015, at 8:20 PM, Peter Saint-Andre - &yet  wrote:
>>
>> What does it mean to make an HTTP request for, say, a SIP URI?
>
> What does it mean to make a Web request for a SIP URI? It doesn't have to be using HTTP. If you can define what it means for SIP, then it can be represented via HTTP as well. If not, then the attempt will fail. Nevertheless, the attempt will exclude the fragment because that information is reserved for client-side processing (if any).
>
> If such a URI is never used in that fashion, then no semantics are assumed for the fragment. This does not mean a scheme like sip can redefine or disallow fragments, since it doesn't control how its identifiers might be used.
>

My understanding is that a request to an HTTP server may convey a SIP 
request-URI, and it's up to the configuration of the receiving (gateway?) server 
what it does with it.

(Was it not once common to issue ftp: requests through HTTP in this way?)

I believe that the HTTP prohibition on including a fragment identifier would 
still apply here.

#g
--


From nobody Fri Apr 10 00:45:38 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E71801B2A53 for ; Fri, 10 Apr 2015 00:45:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.6
X-Spam-Level: 
X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sixMfFlMYb_L for ; Fri, 10 Apr 2015 00:45:36 -0700 (PDT)
Received: from relay15.mail.ox.ac.uk (relay15.mail.ox.ac.uk [163.1.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id 31A8E1B2A51 for ; Fri, 10 Apr 2015 00:45:36 -0700 (PDT)
Received: from smtp4.mail.ox.ac.uk ([129.67.1.207]) by relay15.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1YgTd8-0003fb-oM; Fri, 10 Apr 2015 08:45:34 +0100
Received: from host109-152-232-46.range109-152.btcentralplus.com ([109.152.232.46] helo=cheery.atuin.ninebynine.org) by smtp4.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YgTd8-00068X-EW; Fri, 10 Apr 2015 08:45:34 +0100
Message-ID: <55277F9E.9030508@ninebynine.org>
Date: Fri, 10 Apr 2015 08:45:34 +0100
From: Graham Klyne 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: "t.petch" , Dave Thaler 
References: <550164DD.6020509@it.aoyama.ac.jp>  <080D2D237EF9714533B15BDB@JcK-HP8200.jck.com> <005901d072b7$ee4930a0$4001a8c0@gateway.2wire.net>
In-Reply-To: <005901d072b7$ee4930a0$4001a8c0@gateway.2wire.net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Oxford-Username: zool0635
Archived-At: 
Cc: apps-discuss@ietf.org, Larry Masinter 
Subject: Re: [apps-discuss] Last Call:  (Guidelines and Registration Procedures for URI Schemes) to Best Current Practice
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Apr 2015 07:45:38 -0000

My interpretation is: IESG.  The document indicates that IESG is the final arbiter.

#g
--

On 09/04/2015 12:25, t.petch wrote:
> One thought has been bugging me on this on which I have belatedly done
> my homework.
>
> How do IRTF documents fit into this?
>
> Over the past few years, the processes for the publication of RFC have
> been revised and the procedures for IRTF (and IAB and Individual
> Submission) documents have been formalised.
>
> Thus RFC5226 or draft-leiba-cotton sort of imply that they are for IETF
> stream documents only whereas IRTF RFC can and do have IANA
> Considerations. Both leiba-cotton and this I-D make reference to the
> IESG as the place to go for resolution of uncertainties yet the IESG has
> no such role for IRTF RFC apart from establishing that there is no
> conflict with the work of the IETF - it is nowadays up to the IRSG to
> resolve any issues.
>
> And all the talk about Designated Experts and Expert Review refers to
> the role of the IESG as being in charge, no mention of the IRSG.
>
> So if an IRTF I-D asks for permanent registration, the IESG sees no
> conflict with the work of the IETF but the Designated Expert is unhappy,
> where does this go next?  IESG? IRSG? IAB?
>
>
> Tom Petch
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>


From nobody Fri Apr 10 03:01:08 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C4CE1B2B4A for ; Fri, 10 Apr 2015 03:01:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.61
X-Spam-Level: 
X-Spam-Status: No, score=-3.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hq3_krDf8LG8 for ; Fri, 10 Apr 2015 03:01:04 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B27F1B2B48 for ; Fri, 10 Apr 2015 03:01:04 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 05C73BEFA; Fri, 10 Apr 2015 11:01:03 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oEq9v5SWeazr; Fri, 10 Apr 2015 11:01:00 +0100 (IST)
Received: from [10.87.48.73] (unknown [86.46.18.59]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 9D558BEE8; Fri, 10 Apr 2015 11:01:00 +0100 (IST)
Message-ID: <55279F5C.4080402@cs.tcd.ie>
Date: Fri, 10 Apr 2015 11:01:00 +0100
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Graham Klyne , "t.petch" ,  Dave Thaler 
References: <550164DD.6020509@it.aoyama.ac.jp>  <080D2D237EF9714533B15BDB@JcK-HP8200.jck.com> <005901d072b7$ee4930a0$4001a8c0@gateway.2wire.net> <55277F9E.9030508@ninebynine.org>
In-Reply-To: <55277F9E.9030508@ninebynine.org>
OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: apps-discuss@ietf.org, Larry Masinter 
Subject: Re: [apps-discuss] Last Call:  (Guidelines and Registration Procedures for URI Schemes) to Best Current Practice
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Apr 2015 10:01:07 -0000

On 10/04/15 08:45, Graham Klyne wrote:
> My interpretation is: IESG.  The document indicates that IESG is the
> final arbiter.

Yep, I think that's the case too.

There are some IRTF RFCs that created registries with DEs, for
example [1,2]. So far nobody's asked for a registration and no
experts have been assigned;-) I'm not sure if any other IRTF
RGs have created IANA registries.

When a request does arrive, I'd expect IANA to ask the IESG
as usual. But since there's now an IETF WG on DTN, that isn't
a deal for [1,2].

If a DE was needed for a registry created by an RG and there's
no obvious IETF "home" for that work, I'd not be at all surprised
if the IESG asked the IRTF chair for advice.

S.

[1]
https://www.iana.org/assignments/bundle/bundle.xhtml#block-processing-control
[2]
https://www.iana.org/assignments/ltp-parameters/ltp-parameters.xhtml#cancel-segment-reason-codes

> 
> #g
> -- 
> 
> On 09/04/2015 12:25, t.petch wrote:
>> One thought has been bugging me on this on which I have belatedly done
>> my homework.
>>
>> How do IRTF documents fit into this?
>>
>> Over the past few years, the processes for the publication of RFC have
>> been revised and the procedures for IRTF (and IAB and Individual
>> Submission) documents have been formalised.
>>
>> Thus RFC5226 or draft-leiba-cotton sort of imply that they are for IETF
>> stream documents only whereas IRTF RFC can and do have IANA
>> Considerations. Both leiba-cotton and this I-D make reference to the
>> IESG as the place to go for resolution of uncertainties yet the IESG has
>> no such role for IRTF RFC apart from establishing that there is no
>> conflict with the work of the IETF - it is nowadays up to the IRSG to
>> resolve any issues.
>>
>> And all the talk about Designated Experts and Expert Review refers to
>> the role of the IESG as being in charge, no mention of the IRSG.
>>
>> So if an IRTF I-D asks for permanent registration, the IESG sees no
>> conflict with the work of the IETF but the Designated Expert is unhappy,
>> where does this go next?  IESG? IRSG? IAB?
>>
>>
>> Tom Petch
>>
>> _______________________________________________
>> apps-discuss mailing list
>> apps-discuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/apps-discuss
>>
> 
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
> 
> 


From nobody Fri Apr 10 08:38:14 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 089DC1A1B0B; Fri, 10 Apr 2015 08:38:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGAXi8DtqISm; Fri, 10 Apr 2015 08:38:12 -0700 (PDT)
Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E9CF1A1A79; Fri, 10 Apr 2015 08:38:12 -0700 (PDT)
Received: by iejt8 with SMTP id t8so20364255iej.2; Fri, 10 Apr 2015 08:38:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=6PBQOZbK4GYsAyND5wNjjMIKFSTMlUxwk3b9gTdGeTc=; b=CG8BLXTHzAw860LKXZoBow1Y0V2ZGBG4DnUB/hed+tucnsqVb6olGIwHeK3AgLD/D7 lXH/czsFGXnRA1kJhn9ZRaBSHoU7zOW6yh3q5Sh8ZD/Uy+IAPwSuP2OWPCV4MQ147Z2u 7/8vvO0chq+0vF4XGR+e9QFxUsfI3u0I+svg8aiINrnGeFdUDOYaItD3t+Dfj47V03vV 96oCYDcLlSp5XNZk7Kr4dZ89iRMObC0y6z0xo+GAw7KTF08sqDqnFiHgX/f+IIkM79Pq gwMewaQE71HmGqrnmcYOm0nOO4yh2lrqCrxaIqAeukHmq0+G7gF1LFmjiFjIJo8AO5wk UKFA==
MIME-Version: 1.0
X-Received: by 10.50.35.195 with SMTP id k3mr29699341igj.11.1428680291518; Fri, 10 Apr 2015 08:38:11 -0700 (PDT)
Sender: barryleiba@gmail.com
Received: by 10.107.7.130 with HTTP; Fri, 10 Apr 2015 08:38:11 -0700 (PDT)
In-Reply-To: 
References: <2E49FA112B054FFAED69D8A1@JcK-HP8200.jck.com>  <723FBC93979E1019101319C5@JcK-HP8200.jck.com> <4EA0B2F8-5109-49EA-8BAF-0199D1640407@gbiv.com> <55274198.5030309@andyet.net> 
Date: Fri, 10 Apr 2015 11:38:11 -0400
X-Google-Sender-Auth: 2HHJV-Tc3vxlZei49HezJJXCLbQ
Message-ID: 
From: Barry Leiba 
To: "Roy T. Fielding" 
Content-Type: text/plain; charset=ISO-8859-1
Archived-At: 
Cc: Apps Discuss , "draft-ietf-appsawg-uri-scheme-reg.all@ietf.org" , IESG 
Subject: Re: [apps-discuss] Retroactive application of draft-ietf-appsawg-uri-scheme-reg - comprehensive review
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Apr 2015 15:38:13 -0000

> No scheme can prohibit fragments. They are not part of the scheme's syntax.

We continue to have a confusion between syntax and semantics here.

I absolutely agree that no scheme can say that fragments are
syntactically invalid, because the schemes do not control the syntax
of a URI.

But a scheme can certainly say that fragments make no semantic sense
within that scheme, and that if a URIs uses that scheme and contains a
fragment, it is not a well formed URI within that scheme.

It's rather like saying that English words are composed of characters
from the set "abcdefghijklmnopqrstuvwxyz", and, therefore, the string
"qwx" is a valid piece of an English word (syntax)... but that, in
fact, no valid English words contain "qwx" (semantics).

That's not a layering violation at all -- it has to be up to the
scheme to say what the semantic meaning of a fragment is within that
scheme, or whether fragments have any meaning at all.

Barry


From nobody Fri Apr 10 08:38:18 2015
Return-Path: 
X-Original-To: expand-draft-ietf-appsawg-uri-scheme-reg.all@virtual.ietf.org
Delivered-To: apps-discuss@ietfa.amsl.com
Received: by ietfa.amsl.com (Postfix, from userid 65534) id 23DBB1A1AC9; Fri, 10 Apr 2015 08:38:13 -0700 (PDT)
X-Original-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com
Delivered-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 089DC1A1B0B; Fri, 10 Apr 2015 08:38:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGAXi8DtqISm; Fri, 10 Apr 2015 08:38:12 -0700 (PDT)
Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E9CF1A1A79; Fri, 10 Apr 2015 08:38:12 -0700 (PDT)
Received: by iejt8 with SMTP id t8so20364255iej.2; Fri, 10 Apr 2015 08:38:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=6PBQOZbK4GYsAyND5wNjjMIKFSTMlUxwk3b9gTdGeTc=; b=CG8BLXTHzAw860LKXZoBow1Y0V2ZGBG4DnUB/hed+tucnsqVb6olGIwHeK3AgLD/D7 lXH/czsFGXnRA1kJhn9ZRaBSHoU7zOW6yh3q5Sh8ZD/Uy+IAPwSuP2OWPCV4MQ147Z2u 7/8vvO0chq+0vF4XGR+e9QFxUsfI3u0I+svg8aiINrnGeFdUDOYaItD3t+Dfj47V03vV 96oCYDcLlSp5XNZk7Kr4dZ89iRMObC0y6z0xo+GAw7KTF08sqDqnFiHgX/f+IIkM79Pq gwMewaQE71HmGqrnmcYOm0nOO4yh2lrqCrxaIqAeukHmq0+G7gF1LFmjiFjIJo8AO5wk UKFA==
MIME-Version: 1.0
X-Received: by 10.50.35.195 with SMTP id k3mr29699341igj.11.1428680291518; Fri, 10 Apr 2015 08:38:11 -0700 (PDT)
Sender: barryleiba@gmail.com
Received: by 10.107.7.130 with HTTP; Fri, 10 Apr 2015 08:38:11 -0700 (PDT)
In-Reply-To: 
References: <2E49FA112B054FFAED69D8A1@JcK-HP8200.jck.com>  <723FBC93979E1019101319C5@JcK-HP8200.jck.com> <4EA0B2F8-5109-49EA-8BAF-0199D1640407@gbiv.com> <55274198.5030309@andyet.net> 
Date: Fri, 10 Apr 2015 11:38:11 -0400
X-Google-Sender-Auth: 2HHJV-Tc3vxlZei49HezJJXCLbQ
Message-ID: 
From: Barry Leiba 
To: "Roy T. Fielding" 
Content-Type: text/plain; charset=ISO-8859-1
Archived-At: 
Cc: Apps Discuss , "draft-ietf-appsawg-uri-scheme-reg.all@ietf.org" , IESG 
Subject: Re: [apps-discuss] Retroactive application of draft-ietf-appsawg-uri-scheme-reg - comprehensive review
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Apr 2015 15:38:13 -0000

> No scheme can prohibit fragments. They are not part of the scheme's syntax.

We continue to have a confusion between syntax and semantics here.

I absolutely agree that no scheme can say that fragments are
syntactically invalid, because the schemes do not control the syntax
of a URI.

But a scheme can certainly say that fragments make no semantic sense
within that scheme, and that if a URIs uses that scheme and contains a
fragment, it is not a well formed URI within that scheme.

It's rather like saying that English words are composed of characters
from the set "abcdefghijklmnopqrstuvwxyz", and, therefore, the string
"qwx" is a valid piece of an English word (syntax)... but that, in
fact, no valid English words contain "qwx" (semantics).

That's not a layering violation at all -- it has to be up to the
scheme to say what the semantic meaning of a fragment is within that
scheme, or whether fragments have any meaning at all.

Barry


From nobody Fri Apr 10 09:00:16 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11B851A7005 for ; Fri, 10 Apr 2015 09:00:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.012
X-Spam-Level: 
X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p2xslnlNrwDs for ; Fri, 10 Apr 2015 09:00:12 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id A168D1A7025 for ; Fri, 10 Apr 2015 09:00:11 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PKN1411B4000JJC7@mauve.mrochek.com> for apps-discuss@ietf.org; Fri, 10 Apr 2015 08:55:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1428681308; bh=nMhGc/fY2Efzb+eyzYusd6Ipv6LtphwyrF1TKuMBYzM=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=npcLAUhYIt2iABx5X8gMklmOwmS9Qi8aUnnw0rZGbbamTQfCJRc86qMMcIaFzDwDU N+KwabIl7dA9smxGTsnEt0i6pBKx8KzYFM6cc04VXzH5Nm627J42gdISFS+mzYWGMP Xzl84M6aDYolaVyIhwrePyyBJH0+bKrgeLjeIo7Q=
MIME-version: 1.0
Content-transfer-encoding: 8BIT
Content-type: TEXT/PLAIN; charset=utf-8
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PKJBBQ6BO00000AQ@mauve.mrochek.com>; Fri, 10 Apr 2015 08:55:06 -0700 (PDT)
Message-id: <01PKN13ZJQRK0000AQ@mauve.mrochek.com>
Date: Fri, 10 Apr 2015 08:51:50 -0700 (PDT)
From: Ned Freed 
In-reply-to: "Your message dated Wed, 08 Apr 2015 07:09:42 +0000" 
References:      <3D8DFE75-8015-4CA2-BF2B-8B62C9E450B5@ericsson.com> <045a01cffda8$b3f45120$4001a8c0@gateway.2wire.net> 
To: Larry Masinter 
Archived-At: 
Cc: IETF Apps Discuss 
Subject: Re: [apps-discuss] Working Group Last Call ondraft-ietf-appsawg-multipart-form-data
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Apr 2015 16:00:16 -0000

> This was a working group last call comment that I think I overlooked.



> On 11/11/14, 3:11 AM, "t.petch"  wrote:

> >I note that this I-D specifies
> >
> >   Encoding considerations:  Common use is BINARY.
> >
> >Looking at
> >http://www.iana.org/assignments/media-types/multipart/related
> >I see
> >
> >Encoding considerations:   Multipart content-types cannot have
> >                           encodings.
> >
> >I have looked at more recent RFC, such as RFC6838, and can see nothing
> >to gainsay this.  Does this restriction still apply?

> I don’t know whether Multipart content-types can have encodings, or if not,
> why not.

MIME specified that CTEs are not allowed on multipart and message top-level
types in email. (Web encoding: fields are a separate issue.) This was
done to avoid the possibility of nested encodings.

This restriction was recently lifted for the message/global part in EAI, but
not, AFAIK for any sort of multipart.

> But Encoding considerations apply even if they can’t be encoded, to tell
> you that transport is impossible if you have a 7-bit channel and you want to
> send content that needs either an 8-bit channel (BINARY) or an encoding.

Exactly right.

> Maybe the template name ‘Encoding considerations’ is too easy to take
> literally?

Yes, that's definitely a problem.

				Ned


From nobody Fri Apr 10 11:59:23 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76C0E1B2D72; Fri, 10 Apr 2015 11:59:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mlJ50ITwzXjv; Fri, 10 Apr 2015 11:59:19 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 342D71B2D78; Fri, 10 Apr 2015 11:59:18 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 5.13.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150410185918.28011.28215.idtracker@ietfa.amsl.com>
Date: Fri, 10 Apr 2015 11:59:18 -0700
Archived-At: 
Cc: apps-discuss@ietf.org
Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-multipart-form-data-11.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Apr 2015 18:59:20 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Applications Area Working Group Working Group of the IETF.

        Title           : Returning Values from Forms: multipart/form-data
        Author          : Larry Masinter
	Filename        : draft-ietf-appsawg-multipart-form-data-11.txt
	Pages           : 13
	Date            : 2015-04-10

Abstract:
   This specification defines the multipart/form-data Internet Media
   Type, which can be used by a wide variety of applications and
   transported by a wide variety of protocols as a way of returning a
   set of values as the result of a user filling out a form.  It
   obsoletes RFC 2388.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-appsawg-multipart-form-data/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-appsawg-multipart-form-data-11

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-multipart-form-data-11


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Fri Apr 10 11:59:25 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C2021B2D78; Fri, 10 Apr 2015 11:59:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bhnram2Ok8lm; Fri, 10 Apr 2015 11:59:20 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6EC1B2D7B; Fri, 10 Apr 2015 11:59:18 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: , ,  ,  , , 
X-Test-IDTracker: no
X-IETF-IDTracker: 5.13.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150410185918.28011.12819.idtracker@ietfa.amsl.com>
Date: Fri, 10 Apr 2015 11:59:18 -0700
Archived-At: 
Subject: [apps-discuss] New Version Notification - draft-ietf-appsawg-multipart-form-data-11.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Apr 2015 18:59:21 -0000

A new version (-11) has been submitted for draft-ietf-appsawg-multipart-form-data:
http://www.ietf.org/internet-drafts/draft-ietf-appsawg-multipart-form-data-11.txt


The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-appsawg-multipart-form-data/

Diff from previous version:
http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-multipart-form-data-11

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

IETF Secretariat.


From nobody Fri Apr 10 14:44:47 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CAFB1A8AEA for ; Fri, 10 Apr 2015 14:44:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.373
X-Spam-Level: 
X-Spam-Status: No, score=0.373 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bneVEVvwUHEt for ; Fri, 10 Apr 2015 14:44:44 -0700 (PDT)
Received: from mail-vn0-x22b.google.com (mail-vn0-x22b.google.com [IPv6:2607:f8b0:400c:c0f::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 900DB1A8AEB for ; Fri, 10 Apr 2015 14:44:44 -0700 (PDT)
Received: by vnbg190 with SMTP id g190so8790434vnb.8 for ; Fri, 10 Apr 2015 14:44:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:date:message-id:subject:from:to:content-type;  bh=X5IJ8x2qMYqoJA9iEmysMMqUESxAz2zm5whFofgD2c4=; b=NggKi8efvx1c9jQN2zi7UiZe+B5uCAbhh0pAEiQl2ay0ifQfj8CzXm6x1AE+Q8ZOAU 0up4TCFYWKFXZl7YKq+prK6HcoitUOVdoEVnuE6QozRPYiCK1mmapKMxtTJUYo7TQ/aL aOEXRdJAuFTCs/an/JKUHuxHlhAgDB0wDt23y3QrC7SP2uy0izKAYmbM4hr2C9zlUEfq bd0B4DSrPPPERU7P5nkAbFLDCUMQrOttodlgQDbQlxnWjuA5qRLYFFKvrapXM693A9hs soCYLII6iX8cyC3x9QJwiweFoiWRbIBU2/sowiajmdeFPXOB/DEM0vozwXYpfyEZgmhW w9uw==
MIME-Version: 1.0
X-Received: by 10.60.139.1 with SMTP id qu1mr4396864oeb.83.1428702283694; Fri, 10 Apr 2015 14:44:43 -0700 (PDT)
Sender: phluid61@gmail.com
Received: by 10.202.178.3 with HTTP; Fri, 10 Apr 2015 14:44:43 -0700 (PDT)
Date: Sat, 11 Apr 2015 07:44:43 +1000
X-Google-Sender-Auth: 6QPGVD5HuAAE2HH_2X5V9kiDSbI
Message-ID: 
From: Matthew Kerwin 
To: IETF Apps Discuss 
Content-Type: multipart/alternative; boundary=047d7b4724361c0900051365acfc
Archived-At: 
Subject: [apps-discuss] file scheme status
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 10 Apr 2015 21:44:46 -0000

--047d7b4724361c0900051365acfc
Content-Type: text/plain; charset=UTF-8

Hi folks,

First my apologies for not getting to this sooner, the past four months
have been particularly difficult for me IRL.

In the time I've had, I've been trying to rearrange the 'file' URI scheme
draft to generally meet the comments and discussions we've had on list:

* reducing the normative syntax to the the common core that will provide
most of the interoperability we desire,
* moving commonly seen non-normative (and non-3986-compatible) variations
to informative appendices,
* and moving common usages to informative appendices.

I've focused on the first point, since that's the chunky part. Until I get
that completed, it's hard to target more specific comments, since it's a
pretty big rewrite. The in-progress draft can be viewed at github[1].

If anybody has any comments on the direction the text seems to be taking,
please feel free to comment here on-list. I'll try to get a new revision
pushed out over the weekend.

I've also been keeping a tentative eye on the work on the uri-scheme-reg
draft; I think I'm doing the right things in this draft, but if anyone sees
me conflicting with that draft's requirements please call it out.

Cheers


[1]: http://phluid61.github.io/internet-drafts/file-scheme/

-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/

--047d7b4724361c0900051365acfc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi folks,

First =
my apologies for not getting to this sooner, the past four months have been=
 particularly difficult for me IRL.

In the=
 time I've had, I've been trying to rearrange the 'file' UR=
I scheme draft to generally meet the comments and discussions we've had=
 on list:

* reducing the normative syntax =
to the the common core that will provide most of the interoperability we de=
sire,
* moving commonly seen non-normative (and non-3986-comp=
atible) variations to informative appendices,
* and moving co=
mmon usages to informative appendices.

I=
've focused on the first point, since that's the chunky part. Until=
 I get that completed, it's hard to target more specific comments, sinc=
e it's a pretty big rewrite. The in-progress draft can be viewed at git=
hub[1].

If anybody has any comments on the=
 direction the text seems to be taking, please feel free to comment here on=
-list. I'll try to get a new revision pushed out over the weekend.

I've also been keeping a tentative eye on =
the work on the uri-scheme-reg draft; I think I'm doing the right thing=
s in this draft, but if anyone sees me conflicting with that draft's re=
quirements please call it out.

Cheers


[1]: http://phluid61.github.io/in=
ternet-drafts/file-scheme/

-- 
=C2=A0 Matthew Kerwin
=C2=A0 http://matthew.kerwin.net.a=
u/




--047d7b4724361c0900051365acfc--


From nobody Fri Apr 10 19:40:30 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 914F51A89A9; Fri, 10 Apr 2015 19:40:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.027
X-Spam-Level: 
X-Spam-Status: No, score=-1.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kNeqXrjYfoTq; Fri, 10 Apr 2015 19:40:27 -0700 (PDT)
Received: from mail-vn0-x22e.google.com (mail-vn0-x22e.google.com [IPv6:2607:f8b0:400c:c0f::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 055AF1A89A5; Fri, 10 Apr 2015 19:40:27 -0700 (PDT)
Received: by vnbf1 with SMTP id f1so10096692vnb.5; Fri, 10 Apr 2015 19:40:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=m+I1trL8Km72FhC7p21qSRD/CmxKpzg/pPt13m/NV1Y=; b=rUDVmbcsjldQ0Hut/zYN26BTAXzm7I2yoUhdl1q9oBc6w4EaqWfZVV1kxwM0JSTtcq CNTin6fTTOKU1DODFo5ZKM9c1fLAUZzg1tasSlNduLpYcNQo/PskI0fyYX62bEuCg+C9 YmyMtFIh1BBTtVr9/LkPD/8ree7nWhaBGMWvaizRgsuJBX/Jc6E9luu8xMHC2blTtziT frr1Er0a1owVNPkovrXW3SM1enRv3WtCUpRiK2feuBAVJC4THOrww1PyB42sG5qCvn26 mQP0W8Pv7jBCh210prg5UHvvpxHT8yqJZQmbxRgsu+zVgnnTPCuT55IKHCQV5ej5pP+Y jouQ==
MIME-Version: 1.0
X-Received: by 10.60.83.233 with SMTP id t9mr5013263oey.73.1428720026208; Fri, 10 Apr 2015 19:40:26 -0700 (PDT)
Sender: phluid61@gmail.com
Received: by 10.202.178.3 with HTTP; Fri, 10 Apr 2015 19:40:26 -0700 (PDT)
In-Reply-To: 
References: <2E49FA112B054FFAED69D8A1@JcK-HP8200.jck.com>  <723FBC93979E1019101319C5@JcK-HP8200.jck.com> <4EA0B2F8-5109-49EA-8BAF-0199D1640407@gbiv.com> <55274198.5030309@andyet.net>  
Date: Sat, 11 Apr 2015 12:40:26 +1000
X-Google-Sender-Auth: LBGziRdQGXn5waOEWPYLDSZXq2I
Message-ID: 
From: Matthew Kerwin 
To: Barry Leiba 
Content-Type: multipart/alternative; boundary=089e01182c8ea5524c051369cd18
Archived-At: 
Cc: "Roy T. Fielding" , "draft-ietf-appsawg-uri-scheme-reg.all@ietf.org" , IESG , Apps Discuss 
Subject: Re: [apps-discuss] Retroactive application of draft-ietf-appsawg-uri-scheme-reg - comprehensive review
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 11 Apr 2015 02:40:29 -0000

--089e01182c8ea5524c051369cd18
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 11 April 2015 at 01:38, Barry Leiba  wrote:

> > No scheme can prohibit fragments. They are not part of the scheme's
> syntax.
>
> We continue to have a confusion between syntax and semantics here.
>
> I absolutely agree that no scheme can say that fragments are
> syntactically invalid, because the schemes do not control the syntax
> of a URI.
>
> But a scheme can certainly say that fragments make no semantic sense
> within that scheme, and that if a URIs uses that scheme and contains a
> fragment, it is not a well formed URI within that scheme.
>
>
RFC 3986, S3.5: "=E2=80=8BThe fragment's format and resolution is therefore
dependent on the media type [RFC2046] of a potentially retrieved
representation, even though such a retrieval is only performed if the
URI is dereferenced.  If no such representation exists, then the
semantics of the fragment are considered unknown and are effectively
unconstrained.  Fragment identifier semantics are independent of the
URI scheme and thus cannot be redefined by scheme specifications."

To me that says that schemes cannot touch fragments at all, except
indirectly -- through representation retrieval. In the case of 'http' that
actually makes it the purview of the protocol (not the scheme), however in
'file' it's a bit fuzzier because representation retrieval doesn't have a
protocol to lean on. For URN it's completely obscure to me, because names
aren't inherently dereferenceable (?). I interpret it as: don't mention
fragments at all.



> It's rather like saying that English words are composed of characters
> from the set "abcdefghijklmnopqrstuvwxyz", and, therefore, the string
> "qwx" is a valid piece of an English word (syntax)... but that, in
> fact, no valid English words contain "qwx" (semantics).
>
> That's not a layering violation at all -- it has to be up to the
> scheme to say what the semantic meaning of a fragment is within that
> scheme, or whether fragments have any meaning at all.
>
>
=E2=80=8BThe analogy is over-simplified. If I were to write "Section 4.8.1 =
of RFC
1045" in some English prose, the syntax and semantics of English language
may lead us to understand that "RFC 1045" is a technical document, and
"Section ... of ..." is a fragment reference, so the question becomes: what
types of fragments can be referenced within a technical document?

If the 'English language' also defines the structure of 'technical
documents' then it can say that they contain sections, tables, and images,
for example; but if not then there's no way to know that "Quadrant 3 of RFC
6215" is nonsense, even though "Quadrant ... of ..." is also a fragment
reference.

I think it's up to the scheme to see what (if any) representations can
exist, and then those representations have to say what the fragment
semantics mean. The best the scheme can say is: "All representations are
SVG, therefore fragment semantics are defined by the W3C." Or: "There are
no representations, therefore fragments are undefined."


Cheers
--=20
  Matthew Kerwin
  http://matthew.kerwin.net.au/

--089e01182c8ea5524c051369cd18
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On 11 April 2015 at 01:38, Barry Leiba <barryleib=
a@computer.org> wrote:
> No sche=
me can prohibit fragments. They are not part of the scheme's syntax.


We continue to have a confusion between syntax and semantics here.


I absolutely agree that no scheme can say that fragments are

syntactically invalid, because the schemes do not control the syntax

of a URI.



But a scheme can certainly say that fragments make no semantic sense

within that scheme, and that if a URIs uses that scheme and contains a

fragment, it is not a well formed URI within that scheme.



RFC 3986, S3.5: "=E2=80=
=8BThe fragment's format and resolution is therefore
depe=
ndent on the media type [RFC2046] of a potentially retrieved
=
representation, even though such a retrieval is only performed if the
=

URI is dereferenced.=C2=A0 If no such representation exists, then =
the
semantics of the fragment are considered unknown and are =
effectively
unconstrained.=C2=A0 Fragment identifier semantic=
s are independent of the
URI scheme and thus cannot be redefi=
ned by scheme specifications."

To me =
that says that schemes cannot touch fragments at all, except indirectly -- =
through representation retrieval. In the case of 'http' that actual=
ly makes it the purview of the protocol (not the scheme), however in 'f=
ile' it's a bit fuzzier because representation retrieval doesn'=
t have a protocol to lean on. For URN it's completely obscure to me, be=
cause names aren't inherently dereferenceable (?). I interpret it as: d=
on't mention fragments at all.

=C2=A0

It's rather like saying that English words are composed of characters
from the set "abcdefghijklmnopqrstuvwxyz", and, therefore, the st=
ring

"qwx" is a valid piece of an English word (syntax)... but that, i=
n

fact, no valid English words contain "qwx" (semantics).


That's not a layering violation at al=
l -- it has to be up to the

scheme to say what the semantic meaning of a fragment is within that

scheme, or whether fragments have any meaning at all.




=E2=80=8BThe analogy is over-simplified. If I =
were to write "Section 4.8.1 of RFC 1045" in some English prose, =
the syntax and semantics of English language may lead us to understand that=
 "RFC 1045" is a technical document, and "Section ... of ...=
" is a fragment reference, so the question becomes: what types of frag=
ments can be referenced within a technical document?

If the 'English language' also defines the structure of =
'technical documents' then it can say that they contain sections, t=
ables, and images, for example; but if not then there's no way to know =
that "Quadrant 3 of RFC 6215" is nonsense, even though "Quad=
rant ... of ..." is also a fragment reference.

I think it's up to the scheme to see what (if any) repr=
esentations can exist, and then those representations have to say what the =
fragment semantics mean. The best the scheme can say is: "All represen=
tations are SVG, therefore fragment semantics are defined by the W3C."=
 Or: "There are no representations, therefore fragments are undefined.=
"


Cheers
-- <=
br>
=C2=A0 Matthew Kerwin
=C2=A0 http://matthew.kerwin.net.au/=





--089e01182c8ea5524c051369cd18--


From nobody Fri Apr 10 19:40:42 2015
Return-Path: 
X-Original-To: expand-draft-ietf-appsawg-uri-scheme-reg.all@virtual.ietf.org
Delivered-To: apps-discuss@ietfa.amsl.com
Received: by ietfa.amsl.com (Postfix, from userid 65534) id B01B51A89AC; Fri, 10 Apr 2015 19:40:29 -0700 (PDT)
X-Original-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com
Delivered-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 914F51A89A9; Fri, 10 Apr 2015 19:40:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.027
X-Spam-Level: 
X-Spam-Status: No, score=-1.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kNeqXrjYfoTq; Fri, 10 Apr 2015 19:40:27 -0700 (PDT)
Received: from mail-vn0-x22e.google.com (mail-vn0-x22e.google.com [IPv6:2607:f8b0:400c:c0f::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 055AF1A89A5; Fri, 10 Apr 2015 19:40:27 -0700 (PDT)
Received: by vnbf1 with SMTP id f1so10096692vnb.5; Fri, 10 Apr 2015 19:40:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=m+I1trL8Km72FhC7p21qSRD/CmxKpzg/pPt13m/NV1Y=; b=rUDVmbcsjldQ0Hut/zYN26BTAXzm7I2yoUhdl1q9oBc6w4EaqWfZVV1kxwM0JSTtcq CNTin6fTTOKU1DODFo5ZKM9c1fLAUZzg1tasSlNduLpYcNQo/PskI0fyYX62bEuCg+C9 YmyMtFIh1BBTtVr9/LkPD/8ree7nWhaBGMWvaizRgsuJBX/Jc6E9luu8xMHC2blTtziT frr1Er0a1owVNPkovrXW3SM1enRv3WtCUpRiK2feuBAVJC4THOrww1PyB42sG5qCvn26 mQP0W8Pv7jBCh210prg5UHvvpxHT8yqJZQmbxRgsu+zVgnnTPCuT55IKHCQV5ej5pP+Y jouQ==
MIME-Version: 1.0
X-Received: by 10.60.83.233 with SMTP id t9mr5013263oey.73.1428720026208; Fri, 10 Apr 2015 19:40:26 -0700 (PDT)
Sender: phluid61@gmail.com
Received: by 10.202.178.3 with HTTP; Fri, 10 Apr 2015 19:40:26 -0700 (PDT)
In-Reply-To: 
References: <2E49FA112B054FFAED69D8A1@JcK-HP8200.jck.com>  <723FBC93979E1019101319C5@JcK-HP8200.jck.com> <4EA0B2F8-5109-49EA-8BAF-0199D1640407@gbiv.com> <55274198.5030309@andyet.net>  
Date: Sat, 11 Apr 2015 12:40:26 +1000
X-Google-Sender-Auth: LBGziRdQGXn5waOEWPYLDSZXq2I
Message-ID: 
From: Matthew Kerwin 
To: Barry Leiba 
Content-Type: multipart/alternative; boundary=089e01182c8ea5524c051369cd18
Archived-At: 
Cc: "Roy T. Fielding" , "draft-ietf-appsawg-uri-scheme-reg.all@ietf.org" , IESG , Apps Discuss 
Subject: Re: [apps-discuss] Retroactive application of draft-ietf-appsawg-uri-scheme-reg - comprehensive review
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 11 Apr 2015 02:40:29 -0000

--089e01182c8ea5524c051369cd18
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 11 April 2015 at 01:38, Barry Leiba  wrote:

> > No scheme can prohibit fragments. They are not part of the scheme's
> syntax.
>
> We continue to have a confusion between syntax and semantics here.
>
> I absolutely agree that no scheme can say that fragments are
> syntactically invalid, because the schemes do not control the syntax
> of a URI.
>
> But a scheme can certainly say that fragments make no semantic sense
> within that scheme, and that if a URIs uses that scheme and contains a
> fragment, it is not a well formed URI within that scheme.
>
>
RFC 3986, S3.5: "=E2=80=8BThe fragment's format and resolution is therefore
dependent on the media type [RFC2046] of a potentially retrieved
representation, even though such a retrieval is only performed if the
URI is dereferenced.  If no such representation exists, then the
semantics of the fragment are considered unknown and are effectively
unconstrained.  Fragment identifier semantics are independent of the
URI scheme and thus cannot be redefined by scheme specifications."

To me that says that schemes cannot touch fragments at all, except
indirectly -- through representation retrieval. In the case of 'http' that
actually makes it the purview of the protocol (not the scheme), however in
'file' it's a bit fuzzier because representation retrieval doesn't have a
protocol to lean on. For URN it's completely obscure to me, because names
aren't inherently dereferenceable (?). I interpret it as: don't mention
fragments at all.



> It's rather like saying that English words are composed of characters
> from the set "abcdefghijklmnopqrstuvwxyz", and, therefore, the string
> "qwx" is a valid piece of an English word (syntax)... but that, in
> fact, no valid English words contain "qwx" (semantics).
>
> That's not a layering violation at all -- it has to be up to the
> scheme to say what the semantic meaning of a fragment is within that
> scheme, or whether fragments have any meaning at all.
>
>
=E2=80=8BThe analogy is over-simplified. If I were to write "Section 4.8.1 =
of RFC
1045" in some English prose, the syntax and semantics of English language
may lead us to understand that "RFC 1045" is a technical document, and
"Section ... of ..." is a fragment reference, so the question becomes: what
types of fragments can be referenced within a technical document?

If the 'English language' also defines the structure of 'technical
documents' then it can say that they contain sections, tables, and images,
for example; but if not then there's no way to know that "Quadrant 3 of RFC
6215" is nonsense, even though "Quadrant ... of ..." is also a fragment
reference.

I think it's up to the scheme to see what (if any) representations can
exist, and then those representations have to say what the fragment
semantics mean. The best the scheme can say is: "All representations are
SVG, therefore fragment semantics are defined by the W3C." Or: "There are
no representations, therefore fragments are undefined."


Cheers
--=20
  Matthew Kerwin
  http://matthew.kerwin.net.au/

--089e01182c8ea5524c051369cd18
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On 11 April 2015 at 01:38, Barry Leiba <barryleib=
a@computer.org> wrote:
> No sche=
me can prohibit fragments. They are not part of the scheme's syntax.


We continue to have a confusion between syntax and semantics here.


I absolutely agree that no scheme can say that fragments are

syntactically invalid, because the schemes do not control the syntax

of a URI.



But a scheme can certainly say that fragments make no semantic sense

within that scheme, and that if a URIs uses that scheme and contains a

fragment, it is not a well formed URI within that scheme.



RFC 3986, S3.5: "=E2=80=
=8BThe fragment's format and resolution is therefore
depe=
ndent on the media type [RFC2046] of a potentially retrieved
=
representation, even though such a retrieval is only performed if the
=

URI is dereferenced.=C2=A0 If no such representation exists, then =
the
semantics of the fragment are considered unknown and are =
effectively
unconstrained.=C2=A0 Fragment identifier semantic=
s are independent of the
URI scheme and thus cannot be redefi=
ned by scheme specifications."

To me =
that says that schemes cannot touch fragments at all, except indirectly -- =
through representation retrieval. In the case of 'http' that actual=
ly makes it the purview of the protocol (not the scheme), however in 'f=
ile' it's a bit fuzzier because representation retrieval doesn'=
t have a protocol to lean on. For URN it's completely obscure to me, be=
cause names aren't inherently dereferenceable (?). I interpret it as: d=
on't mention fragments at all.

=C2=A0

It's rather like saying that English words are composed of characters
from the set "abcdefghijklmnopqrstuvwxyz", and, therefore, the st=
ring

"qwx" is a valid piece of an English word (syntax)... but that, i=
n

fact, no valid English words contain "qwx" (semantics).


That's not a layering violation at al=
l -- it has to be up to the

scheme to say what the semantic meaning of a fragment is within that

scheme, or whether fragments have any meaning at all.




=E2=80=8BThe analogy is over-simplified. If I =
were to write "Section 4.8.1 of RFC 1045" in some English prose, =
the syntax and semantics of English language may lead us to understand that=
 "RFC 1045" is a technical document, and "Section ... of ...=
" is a fragment reference, so the question becomes: what types of frag=
ments can be referenced within a technical document?

If the 'English language' also defines the structure of =
'technical documents' then it can say that they contain sections, t=
ables, and images, for example; but if not then there's no way to know =
that "Quadrant 3 of RFC 6215" is nonsense, even though "Quad=
rant ... of ..." is also a fragment reference.

I think it's up to the scheme to see what (if any) repr=
esentations can exist, and then those representations have to say what the =
fragment semantics mean. The best the scheme can say is: "All represen=
tations are SVG, therefore fragment semantics are defined by the W3C."=
 Or: "There are no representations, therefore fragments are undefined.=
"


Cheers
-- <=
br>
=C2=A0 Matthew Kerwin
=C2=A0 http://matthew.kerwin.net.au/=





--089e01182c8ea5524c051369cd18--


From nobody Fri Apr 10 20:44:46 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C066E1B2F3A; Fri, 10 Apr 2015 20:44:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.666
X-Spam-Level: 
X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wOpKddX-LCWR; Fri, 10 Apr 2015 20:44:44 -0700 (PDT)
Received: from homiemail-a113.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 3EA4B1B2F39; Fri, 10 Apr 2015 20:44:44 -0700 (PDT)
Received: from homiemail-a113.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a113.g.dreamhost.com (Postfix) with ESMTP id 011F720058DAC; Fri, 10 Apr 2015 20:44:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=content-type :mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=gbiv.com; bh=CbMnNnHZo9CT8ihHORAzYc9v25Y=; b=ANiuYHBC1WigGgVufg8rFfi3mfgL NCQFpyfmNaDhAnOF+U1INhqv+qAGW/dWmWxeeBbOjlp9MPKae6Ij97eGZzecgCvG svjbMyFxAvNrFuB0qAdNc0G4H5HhrGznpb++e8tHzkLV6JrmY4ATC4oBzzO3jDtb hGRnM9ADYglFtpI=
Received: from [192.168.1.18] (ip68-228-83-124.oc.oc.cox.net [68.228.83.124]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by homiemail-a113.g.dreamhost.com (Postfix) with ESMTPSA id DD6A320058DAB; Fri, 10 Apr 2015 20:44:43 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: "Roy T. Fielding" 
In-Reply-To: 
Date: Fri, 10 Apr 2015 20:44:34 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <327268B5-3817-42F1-90B3-D44158B0AA5D@gbiv.com>
References: <2E49FA112B054FFAED69D8A1@JcK-HP8200.jck.com>  <723FBC93979E1019101319C5@JcK-HP8200.jck.com> <4EA0B2F8-5109-49EA-8BAF-0199D1640407@gbiv.com> <55274198.5030309@andyet.net>  
To: Barry Leiba 
X-Mailer: Apple Mail (2.2098)
Archived-At: 
Cc: "draft-ietf-appsawg-uri-scheme-reg.all@ietf.org" , IESG , Apps Discuss 
Subject: Re: [apps-discuss] Retroactive application of draft-ietf-appsawg-uri-scheme-reg - comprehensive review
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 11 Apr 2015 03:44:45 -0000

> On Apr 10, 2015, at 8:38 AM, Barry Leiba  =
wrote:
>=20
>> No scheme can prohibit fragments. They are not part of the scheme's =
syntax.
>=20
> We continue to have a confusion between syntax and semantics here.
>=20
> I absolutely agree that no scheme can say that fragments are
> syntactically invalid, because the schemes do not control the syntax
> of a URI.
>=20
> But a scheme can certainly say that fragments make no semantic sense
> within that scheme, and that if a URIs uses that scheme and contains a
> fragment, it is not a well formed URI within that scheme.

No, they can't, or at least they cannot say that truthfully.

> It's rather like saying that English words are composed of characters
> from the set "abcdefghijklmnopqrstuvwxyz", and, therefore, the string
> "qwx" is a valid piece of an English word (syntax)... but that, in
> fact, no valid English words contain "qwx" (semantics).

Sorry, you've lost me.

It is more like saying that, because host and port are adjacent to each =
other in
the syntax, it is therefore possible for DNS to specify what ports are =
allowed.

> That's not a layering violation at all -- it has to be up to the
> scheme to say what the semantic meaning of a fragment is within that
> scheme, or whether fragments have any meaning at all.

It has nothing to do with the scheme. Nothing whatsoever. It is true =
that there
are many resources, regardless of scheme, for which a fragment =
identifier wouldn't
have much practical purpose other than as a name, but that's only =
because
nobody has found a reason to resolve them yet. In most cases, this is =
because
deployment of the scheme is so small that it isn't worth anyone's bother =
to create
a gateway for information about its identified resources.

The problem is that if we let people write incorrect statements about =
fragments
within scheme specifications, we lose interoperability around one of the =
main
extension points in Web architecture. We lose the ability to process the =
results
of interactions independently of the protocols and systems used to =
obtain them.

....Roy


From nobody Fri Apr 10 20:44:55 2015
Return-Path: 
X-Original-To: expand-draft-ietf-appsawg-uri-scheme-reg.all@virtual.ietf.org
Delivered-To: apps-discuss@ietfa.amsl.com
Received: by ietfa.amsl.com (Postfix, from userid 65534) id E1E991B2F3B; Fri, 10 Apr 2015 20:44:45 -0700 (PDT)
X-Original-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com
Delivered-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C066E1B2F3A; Fri, 10 Apr 2015 20:44:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.666
X-Spam-Level: 
X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wOpKddX-LCWR; Fri, 10 Apr 2015 20:44:44 -0700 (PDT)
Received: from homiemail-a113.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 3EA4B1B2F39; Fri, 10 Apr 2015 20:44:44 -0700 (PDT)
Received: from homiemail-a113.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a113.g.dreamhost.com (Postfix) with ESMTP id 011F720058DAC; Fri, 10 Apr 2015 20:44:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=content-type :mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=gbiv.com; bh=CbMnNnHZo9CT8ihHORAzYc9v25Y=; b=ANiuYHBC1WigGgVufg8rFfi3mfgL NCQFpyfmNaDhAnOF+U1INhqv+qAGW/dWmWxeeBbOjlp9MPKae6Ij97eGZzecgCvG svjbMyFxAvNrFuB0qAdNc0G4H5HhrGznpb++e8tHzkLV6JrmY4ATC4oBzzO3jDtb hGRnM9ADYglFtpI=
Received: from [192.168.1.18] (ip68-228-83-124.oc.oc.cox.net [68.228.83.124]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by homiemail-a113.g.dreamhost.com (Postfix) with ESMTPSA id DD6A320058DAB; Fri, 10 Apr 2015 20:44:43 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: "Roy T. Fielding" 
In-Reply-To: 
Date: Fri, 10 Apr 2015 20:44:34 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <327268B5-3817-42F1-90B3-D44158B0AA5D@gbiv.com>
References: <2E49FA112B054FFAED69D8A1@JcK-HP8200.jck.com>  <723FBC93979E1019101319C5@JcK-HP8200.jck.com> <4EA0B2F8-5109-49EA-8BAF-0199D1640407@gbiv.com> <55274198.5030309@andyet.net>  
To: Barry Leiba 
X-Mailer: Apple Mail (2.2098)
Archived-At: 
Cc: "draft-ietf-appsawg-uri-scheme-reg.all@ietf.org" , IESG , Apps Discuss 
Subject: Re: [apps-discuss] Retroactive application of draft-ietf-appsawg-uri-scheme-reg - comprehensive review
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 11 Apr 2015 03:44:46 -0000

> On Apr 10, 2015, at 8:38 AM, Barry Leiba  =
wrote:
>=20
>> No scheme can prohibit fragments. They are not part of the scheme's =
syntax.
>=20
> We continue to have a confusion between syntax and semantics here.
>=20
> I absolutely agree that no scheme can say that fragments are
> syntactically invalid, because the schemes do not control the syntax
> of a URI.
>=20
> But a scheme can certainly say that fragments make no semantic sense
> within that scheme, and that if a URIs uses that scheme and contains a
> fragment, it is not a well formed URI within that scheme.

No, they can't, or at least they cannot say that truthfully.

> It's rather like saying that English words are composed of characters
> from the set "abcdefghijklmnopqrstuvwxyz", and, therefore, the string
> "qwx" is a valid piece of an English word (syntax)... but that, in
> fact, no valid English words contain "qwx" (semantics).

Sorry, you've lost me.

It is more like saying that, because host and port are adjacent to each =
other in
the syntax, it is therefore possible for DNS to specify what ports are =
allowed.

> That's not a layering violation at all -- it has to be up to the
> scheme to say what the semantic meaning of a fragment is within that
> scheme, or whether fragments have any meaning at all.

It has nothing to do with the scheme. Nothing whatsoever. It is true =
that there
are many resources, regardless of scheme, for which a fragment =
identifier wouldn't
have much practical purpose other than as a name, but that's only =
because
nobody has found a reason to resolve them yet. In most cases, this is =
because
deployment of the scheme is so small that it isn't worth anyone's bother =
to create
a gateway for information about its identified resources.

The problem is that if we let people write incorrect statements about =
fragments
within scheme specifications, we lose interoperability around one of the =
main
extension points in Web architecture. We lose the ability to process the =
results
of interactions independently of the protocols and systems used to =
obtain them.

....Roy


From nobody Sun Apr 12 12:38:07 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C2AA1B382B for ; Sun, 12 Apr 2015 12:38:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.701
X-Spam-Level: 
X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7cwbXdvz3Awb for ; Sun, 12 Apr 2015 12:38:04 -0700 (PDT)
Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F3051B382A for ; Sun, 12 Apr 2015 12:38:04 -0700 (PDT)
Received: by iggg4 with SMTP id g4so31130997igg.0 for ; Sun, 12 Apr 2015 12:38:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:date:message-id:subject:from:to:content-type; bh=9ked2HwuaTCap4xkZt6EdlRg0Bu7i5NfejAicUvxYWI=; b=fmBAZEBPuIKMDvhZ3oDNVYtqFT7Km4BN9EDZSwxqsxBbrPSpmuPWVITnJxf8gb2Kz/ Fre1R5dI4m2ctHk5tN6qHN6ISkshDnmJHl4ifvJGUBTHgx0q3n4dd/9JXm39x7GkqkJQ CEzW+E/x+6hLX9CyPz16vNQ7Ym89dHdlDABjGXOaMzNcchA9+aIt1AeNTN4rKGAYe/fW 5mK3ShqNeLhNz73O+PNwb3kkRGOx+SAgcHrA2wwt9LcAIhb5iwY7Ma+YaFAuVK+Mj29J wa1Pr6fwqBgmHXtiaO5Vwp2BoceuD0WlMECB4IR7uMfiuxFz4Lj1sazocZ6C3Qwhn73r CTug==
MIME-Version: 1.0
X-Received: by 10.42.207.206 with SMTP id fz14mr15349699icb.34.1428867483387;  Sun, 12 Apr 2015 12:38:03 -0700 (PDT)
Received: by 10.107.12.4 with HTTP; Sun, 12 Apr 2015 12:38:03 -0700 (PDT)
Date: Sun, 12 Apr 2015 15:38:03 -0400
Message-ID: 
From: Nick Matavka 
To: apps-discuss@ietf.org
Content-Type: multipart/alternative; boundary=20cf30426df6c74bb605138c2232
Archived-At: 
Subject: [apps-discuss] Gopher - updated spec
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 12 Apr 2015 19:38:05 -0000

--20cf30426df6c74bb605138c2232
Content-Type: text/plain; charset=UTF-8

Hello world!

For the dinosaurs that still care about Gopher, I submitted an
Internet-Draft to the IETF people... if you're interested in helping me
with it, or constructive criticism, it's entirely welcome.

The document may be accessed at
http://datatracker.ietf.org/submit/status/68408/

Unfortunately, the Internet-Draft submission tool must have been written by
someone who was smoking something, as no matter what the hell I do, I can't
get my name and the name of my co-writer to appear in the appropriate
field, so have had to add them manually.  Waiting for the Secretariat,
whatever that is, to add my name on there.

With fraternal greetings,

Edward Matavka.

--20cf30426df6c74bb605138c2232
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hello world!

For the dinosaurs that sti=
ll care about Gopher, I submitted an Internet-Draft to the IETF people... i=
f you're interested in helping me with it, or constructive criticism, i=
t's entirely welcome.

The document may be acce=
ssed at=C2=A0http://datatracker.=
ietf.org/submit/status/68408/

Unfortunately, t=
he Internet-Draft submission tool must have been written by someone who was=
 smoking something, as no matter what the hell I do, I can't get my nam=
e and the name of my co-writer to appear in the appropriate field, so have =
had to add them manually.=C2=A0 Waiting for the Secretariat, whatever that =
is, to add my name on there.

With fraternal greeti=
ngs,

Edward Matavka.


--20cf30426df6c74bb605138c2232--


From nobody Sun Apr 12 13:21:26 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 005381A886F for ; Sun, 12 Apr 2015 13:21:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.164
X-Spam-Level: 
X-Spam-Status: No, score=0.164 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XVF2bkY0dwUb for ; Sun, 12 Apr 2015 13:21:23 -0700 (PDT)
Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 1AD9B1A886C for ; Sun, 12 Apr 2015 13:21:23 -0700 (PDT)
Received: from [IPv6:2602:ae:17d2:9000:5d20:21a1:4fe1:c6ab] (unknown [IPv6:2602:ae:17d2:9000:5d20:21a1:4fe1:c6ab]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 8A90B2013A; Sun, 12 Apr 2015 22:21:21 +0200 (CEST)
Message-ID: <552AD3BF.7090307@acm.org>
Date: Sun, 12 Apr 2015 14:21:19 -0600
From: Marc Petit-Huguenin 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.6.0
MIME-Version: 1.0
To: Nick Matavka , apps-discuss@ietf.org
References: 
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [apps-discuss] Gopher - updated spec
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 12 Apr 2015 20:21:25 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 04/12/2015 01:38 PM, Nick Matavka wrote:
> Hello world!
> 
> For the dinosaurs that still care about Gopher, I submitted an
> Internet-Draft to the IETF people... if you're interested in helping me
> with it, or constructive criticism, it's entirely welcome.
> 
> The document may be accessed at
> http://datatracker.ietf.org/submit/status/68408/
> 
> Unfortunately, the Internet-Draft submission tool must have been written by
> someone who was smoking something, as no matter what the hell I do, I can't

Probably because the degree of membership of your document to the Internet-Draft fuzzy set is close to 0.

See RFC 7322, RFC 5741, and RFC 2629 to improve that.

> get my name and the name of my co-writer to appear in the appropriate
> field, so have had to add them manually.  Waiting for the Secretariat,
> whatever that is, to add my name on there.
> 
> With fraternal greetings,
> 
> Edward Matavka.
> 

- -- 
Marc Petit-Huguenin
Email: marc@petit-huguenin.org
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJVKtO/AAoJECnERZXWan7Ebr4QAMKsaceaD9Scc6l8GL6Lm8jZ
mMLW9Pe5j0BQ8kGy7yJJSUTCQFsHT7qjT4SuKbNnzUQuiv2YD+LeYisX/Q6+q1Lv
x1MQtxWFK9RmchQHacZC/QXSiEd2nAQL9Y8mgmwhQYi4tx/E4CCvAvoU3v+zT1XV
AQ0eT0KOLli61AV7pSF7f8RbSIEH/fJ+Wpeh7hR0jxqG4n5dBNYF4A9wIxQxbMDj
aTCDcH0VXpBMqokRTPBzbTKESCrcsvMNZqyp2MGU0rgb6GKZNSEyiRwwqemLAGr1
GP3bvyocTPRnxni67owut87U69tubQNkmrrPN/hQSrQfqDJQN21eD12mJLQVxXBV
N2wmU9dRYnonnazkN7YFPnpb24F2QWPqPEeeZ9QouvweWbBmB6FV1jstAFnmMH+3
cpcZ40lMDDmIZAr6j1XZH9u/c88PdgPQx28ZJ0jIZ2Eew6N+kz9iw0uWQfB54Edi
WBVIwH61gkGgHGt2Z+Zxa4X9XJWz68qhVuYISRxzlLzE03G/7aPQTuLlAxcD40V/
S9Yb/BCQR34X1mNTpnoHZs4R9c7QcPBe9EL2NJisp2qdGxiBTJSi13G6n58jF6dJ
997k2e1BL4FWhlSjDitKK7qcgoMKRn7MNbaiI6veQnoILgnoPE2vmofSdc7N/lvo
kSKVQ4DqZjS9yucPEc51
=ismE
-----END PGP SIGNATURE-----


From nobody Sun Apr 12 18:44:25 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44C581A8829 for ; Sun, 12 Apr 2015 18:44:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ptBW3YxyKezm for ; Sun, 12 Apr 2015 18:44:21 -0700 (PDT)
Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0BA71A8823 for ; Sun, 12 Apr 2015 18:44:21 -0700 (PDT)
Received: by igbpi8 with SMTP id pi8so18415647igb.0 for ; Sun, 12 Apr 2015 18:44:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:date:message-id:subject:from:to:content-type; bh=hekVpl1ZST2dhgadN1meTnhtzxraq1hUBDhkUhYRkXQ=; b=jgG3E+nWN9w5bW8vcAVIa2bm6MXviP1WicqNEB4PD2jhx5fiLgQ9n++POGfl3509Jg slgziC53rFbWHTqNlpZJsIYFHJxAdHCHqgXn1Cmo6mQ1G3UzD2edWXlbVe0FA8YJTM+S kDXZiY52dnjaA+CrhfmrujW7s6KiNUKHhfMrx9Ywwr/oTEsiq8p/2+CjXF8EDfBJBYGB UsD84npVL/JxFd12Cn6mTwVr6Ufz+cliugggENCp0P3dW3hQqzAX6KoHci+H6uHpW/M3 k1c8+1zZ7WwPv2Hj9TXvchvXAB2QO8BSBy3QqWcen/PUUP4zOpY2WliEJPOYPVoPzcm/ 82dg==
MIME-Version: 1.0
X-Received: by 10.50.127.232 with SMTP id nj8mr13230863igb.32.1428889461239; Sun, 12 Apr 2015 18:44:21 -0700 (PDT)
Received: by 10.107.12.4 with HTTP; Sun, 12 Apr 2015 18:44:21 -0700 (PDT)
Date: Sun, 12 Apr 2015 21:44:21 -0400
Message-ID: 
From: Nick Matavka 
To: apps-discuss@ietf.org
Content-Type: multipart/alternative; boundary=089e013a01eac2b64d05139140cc
Archived-At: 
Subject: [apps-discuss] Gopher Internet-Draft
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 13 Apr 2015 01:44:23 -0000

--089e013a01eac2b64d05139140cc
Content-Type: text/plain; charset=UTF-8

Hello World!

I tried changing the authors' names section to the format suggested by Mr
(Dr?) Klensin but the heuristic still doesn't pick up on the authors'
names, so I cancelled it and re-submitted it manually.

The slightly updated I-D can be seen at
http://datatracker.ietf.org/submit/status/68412/

With fraternal greetings,

Edward Matavka

-- 
       /^\/^\
       \----|
   _---'---~~~~-_
    ~~~|~~L~|~~~~
       (/_  /~~--
     \~ \  /  /~
   __~\  ~ /   ~~----,
   \    | |       /  \
   /|   |/       |    |
   | | | o  o     /~   |
 _-~_  |        ||  \  /
(// )) | o  o    \\---'
//_- |  |          \
//   |____|\______\__\
~      |   / |    |
       |_ /   \ _|
     /~___|  /____\

--089e013a01eac2b64d05139140cc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hello World!

I tried changing the autho=
rs' names section to the format suggested by Mr (Dr?) Klensin but the h=
euristic still doesn't pick up on the authors' names, so I cancelle=
d it and re-submitted it manually.

The slightly up=
dated I-D can be seen at=C2=A0http://datatracker.ietf.org/submit/status/68412/
<=
div>
With fraternal greetings,

Edwar=
d Matavka

-- 
 =C2=A0 =C2=A0 =C2=A0 =C2=A0/^\/^\
 =C2=A0 =C2=A0 =C2=A0 =C2=A0\---=
-|
 =C2=A0 =C2=A0_---'---~~~~-_ =C2=A0
 =C2=A0 =C2=A0 ~~~|~~L~|~~=
~~
 =C2=A0 =C2=A0 =C2=A0 =C2=A0(/_ =C2=A0/~~--
 =C2=A0 =C2=A0 =C2=A0\=
~ \ =C2=A0/ =C2=A0/~
 =C2=A0 =C2=A0__~\ =C2=A0~ / =C2=A0 ~~----,
 =C2=
=A0 =C2=A0\ =C2=A0 =C2=A0| | =C2=A0 =C2=A0 =C2=A0 / =C2=A0\ =C2=A0
 =C2=
=A0 =C2=A0/| =C2=A0 |/ =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0|
 =C2=A0 =C2=
=A0| | | o =C2=A0o =C2=A0 =C2=A0 /~ =C2=A0 | =C2=A0
 =C2=A0_-~_ =C2=A0| =
=C2=A0 =C2=A0 =C2=A0 =C2=A0|| =C2=A0\ =C2=A0/
 (// )) | o =C2=A0o =C2=A0=
 =C2=A0\\---'
 //_- | =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0\ // =C2=A0 |____|\______\__\
~ =C2=A0 =C2=A0 =C2=A0| =C2=A0 / | =C2=A0 =
=C2=A0|
 =C2=A0 =C2=A0 =C2=A0 =C2=A0|_ / =C2=A0 \ _|
 =C2=A0 =C2=A0 =
=C2=A0/~___| =C2=A0/____\ =C2=A0 =C2=A0 =C2=A0 =C2=A0 




--089e013a01eac2b64d05139140cc--


From nobody Sun Apr 12 19:58:23 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C07CD1A8A6D for ; Sun, 12 Apr 2015 19:58:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.1
X-Spam-Level: 
X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DzXcWoS7PpnS for ; Sun, 12 Apr 2015 19:58:20 -0700 (PDT)
Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D8CF1A8A6C for ; Sun, 12 Apr 2015 19:58:20 -0700 (PDT)
Received: by wgin8 with SMTP id n8so66562085wgi.0 for ; Sun, 12 Apr 2015 19:58:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZgTM0jfyrxlI8ZrLamnLhbaMOYXl7ORBrxA6IlVDljU=; b=ryZ6PK1WDjLD0yHwgnRVwfMRF0dDY+49W+v4TOABOCQYF2eUM80KWUYWGsK9E6xKdW vaQRfiX4hqrR6SldR0wjjfsLj3P7MNKmGKgCXIJKlwNiuW69r5s5qdAdNYQnZPovhgAJ auIVHBcHJANy4kaRZXIQPrl2j8q2OquBIYOXE0EuJxD8+56tEyyldQxquhUkD/r3WvZM BPTpXr0wo73BEJi0ZXXceY8LqGWQfKit2zYr/MpHked0ne3wMrIpv5E5HYyJeO5d52+C rTaDWZ7mtnQOtITG2b//Sir38SjQZO3fmJ7Dfq7u70IV1qTudWd1e218pn5E61WY8n0E OUag==
MIME-Version: 1.0
X-Received: by 10.180.77.166 with SMTP id t6mr17880447wiw.52.1428893899156; Sun, 12 Apr 2015 19:58:19 -0700 (PDT)
Received: by 10.27.92.17 with HTTP; Sun, 12 Apr 2015 19:58:18 -0700 (PDT)
In-Reply-To: 
References: 
Date: Sun, 12 Apr 2015 19:58:18 -0700
Message-ID: 
From: "Murray S. Kucherawy" 
To: Nick Matavka 
Content-Type: multipart/alternative; boundary=f46d043d645f47f32305139249e4
Archived-At: 
Cc: IETF Apps Discuss 
Subject: Re: [apps-discuss] Gopher Internet-Draft
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 13 Apr 2015 02:58:21 -0000

--f46d043d645f47f32305139249e4
Content-Type: text/plain; charset=UTF-8

On Sun, Apr 12, 2015 at 6:44 PM, Nick Matavka <
n.theodore.matavka.files@gmail.com> wrote:

> I tried changing the authors' names section to the format suggested by Mr
> (Dr?) Klensin but the heuristic still doesn't pick up on the authors'
> names, so I cancelled it and re-submitted it manually.
>

Have you considered using xml2rfc?  It (nearly) always produces something
in the required formats so automatic posting works fine.

-MSK

--f46d043d645f47f32305139249e4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On Sun, Apr 12, 2015 at 6:44 PM, Nick Matavka <n.theodore.matavka.files@gmail.com> wrote:
I tried changing the authors' names section to the f=
ormat suggested by Mr (Dr?) Klensin but the heuristic still doesn't pic=
k up on the authors' names, so I cancelled it and re-submitted it manua=
lly.

Have you considered using xm=
l2rfc?=C2=A0 It (nearly) always produces something in the required formats =
so automatic posting works fine.

-MSK 


--f46d043d645f47f32305139249e4--


From nobody Mon Apr 13 06:16:06 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF67D1A0030 for ; Mon, 13 Apr 2015 06:16:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level: 
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Arj6Ho1g28K8 for ; Mon, 13 Apr 2015 06:16:03 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FD551A000F for ; Mon, 13 Apr 2015 06:16:03 -0700 (PDT)
Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YheDZ-000ICd-Uz; Mon, 13 Apr 2015 09:16:01 -0400
Date: Mon, 13 Apr 2015 09:15:56 -0400
From: John C Klensin 
To: Nick Matavka , apps-discuss@ietf.org
Message-ID: 
In-Reply-To: 
References: 
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.35
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: 
Subject: Re: [apps-discuss] Gopher Internet-Draft
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 13 Apr 2015 13:16:05 -0000

--On Sunday, April 12, 2015 21:44 -0400 Nick Matavka
 wrote:

> Hello World!
> 
> I tried changing the authors' names section to the format
> suggested by Mr (Dr?) Klensin but the heuristic still doesn't
> pick up on the authors' names, so I cancelled it and
> re-submitted it manually.

Sorry... I thought that might do it, but I don't know how the
algorithm works.  It is worthwhile noting that the "nits
checker" built into the submission tool doesn't report anything
but the I-Ds is forced into manual posting.  I hope the
Secretariat will be able to take care of that today or tomorrow.

Other than that, no advice other than than you adhere very
carefully to the normal format (e.g., the way you have
underlined titles isn't part of it) or, as Murray suggested, use
xml2rfc (or some other tool) that automatically produces a
conforming format.

   john

> 
> The slightly updated I-D can be seen at
> http://datatracker.ietf.org/submit/status/68412/
> 
> With fraternal greetings,
> 
> Edward Matavka





From nobody Mon Apr 13 08:54:47 2015
Return-Path: 
X-Original-To: expand-draft-ietf-appsawg-uri-scheme-reg.all@virtual.ietf.org
Delivered-To: apps-discuss@ietfa.amsl.com
Received: by ietfa.amsl.com (Postfix, from userid 65534) id E911B1B2D30; Sun, 12 Apr 2015 22:57:40 -0700 (PDT)
X-Original-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com
Delivered-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB1581B2D2F for ; Sun, 12 Apr 2015 22:57:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.216
X-Spam-Level: *
X-Spam-Status: No, score=1.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id giM806FcMoRk for ; Sun, 12 Apr 2015 22:57:37 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4DD21B2D2B for ; Sun, 12 Apr 2015 22:57:37 -0700 (PDT)
Received: from szxga01-in.huawei.com ([58.251.152.64]:38092) by zinfandel.tools.ietf.org with esmtps (TLS1.0:RSA_ARCFOUR_128_SHA1:128) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YhXNH-0006J1-Hr for draft-ietf-appsawg-uri-scheme-reg.all@tools.ietf.org; Sun, 12 Apr 2015 22:57:37 -0700
Received: from 172.24.2.119 (EHLO nkgeml406-hub.china.huawei.com) ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CMA54726; Mon, 13 Apr 2015 13:57:21 +0800 (CST)
Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.244]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Mon, 13 Apr 2015 13:57:18 +0800
From: Qin Wu 
To: Dave Thaler 
Thread-Topic: OPS-DIR review of draft-ietf-appsawg-uri-scheme-reg-04
Thread-Index: AdBVqoBBzKB16QZoQqSP3Y7FahtJFgXyo5LgAg5jYQA=
Date: Mon, 13 Apr 2015 05:57:18 +0000
Message-ID: 
References:  
In-Reply-To: 
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.138.41.180]
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA8471994Bnkgeml501mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-SA-Exim-Connect-IP: 58.251.152.64
X-SA-Exim-Rcpt-To: draft-ietf-appsawg-uri-scheme-reg.all@tools.ietf.org
X-SA-Exim-Mail-From: bill.wu@huawei.com
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org)
Resent-To: draft-ietf-appsawg-uri-scheme-reg.all@ietf.org
Resent-Message-Id: <20150413055737.B4DD21B2D2B@ietfa.amsl.com>
Resent-Date: Sun, 12 Apr 2015 22:57:37 -0700 (PDT)
Resent-From: bill.wu@huawei.com
Archived-At: 
Archived-At: 
X-Mailman-Approved-At: Mon, 13 Apr 2015 08:54:46 -0700
Cc: "draft-ietf-appsawg-uri-scheme-reg.all@tools.ietf.org" , "ops-dir@ietf.org" 
Subject: Re: [apps-discuss] OPS-DIR review of draft-ietf-appsawg-uri-scheme-reg-04
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 13 Apr 2015 05:57:41 -0000

--_000_B8F9A780D330094D99AF023C5877DABA8471994Bnkgeml501mbschi_
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64

VGhhbmtzIERhdmUgZm9yIGNsYXJpZmljYXRpb24sIHlvdSBhZGRyZXNzIG15IGNvbW1lbnRzLg0K
DQotUWluDQq3orz+yMs6IERhdmUgVGhhbGVyIFttYWlsdG86ZHRoYWxlckBtaWNyb3NvZnQuY29t
XQ0Kt6LLzcqxvOQ6IDIwMTXE6jTUwjPI1SAyOjQ5DQrK1bz+yMs6IFFpbiBXdQ0Ks63LzTogb3Bz
LWRpckBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1hcHBzYXdnLXVyaS1zY2hlbWUtcmVnLmFsbEB0b29s
cy5pZXRmLm9yZw0K1vfM4jogUkU6IE9QUy1ESVIgcmV2aWV3IG9mIGRyYWZ0LWlldGYtYXBwc2F3
Zy11cmktc2NoZW1lLXJlZy0wNA0KDQpUaGFua3MgUWluIGZvciB5b3VyIHJldmlldy4gIEJlbG93
IGlzIHdoYXQgd2UgZGlkIGluIC0wNS4uDQoNCkZyb206IFFpbiBXdSBbbWFpbHRvOmJpbGwud3VA
aHVhd2VpLmNvbV0NClNlbnQ6IFR1ZXNkYXksIE1hcmNoIDMsIDIwMTUgNDowNyBBTQ0KVG86IG9w
cy1kaXJAaWV0Zi5vcmc8bWFpbHRvOm9wcy1kaXJAaWV0Zi5vcmc+OyBkcmFmdC1pZXRmLWFwcHNh
d2ctdXJpLXNjaGVtZS1yZWcuYWxsQHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLWFw
cHNhd2ctdXJpLXNjaGVtZS1yZWcuYWxsQHRvb2xzLmlldGYub3JnPg0KU3ViamVjdDogT1BTLURJ
UiByZXZpZXcgb2YgZHJhZnQtaWV0Zi1hcHBzYXdnLXVyaS1zY2hlbWUtcmVnLTA0DQoNCg0KRm9s
a3M6DQoNCkkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIE9wZXJh
dGlvbmFsIGRpcmVjdG9yYXRlJ3Mgb25nb2luZyBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRv
Y3VtZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlIElFU0cuICBUaGVzZSBjb21tZW50cyB3ZXJl
IHdyaXR0ZW4gd2l0aCB0aGUgaW50ZW50IG9mIGltcHJvdmluZyB0aGUgb3BlcmF0aW9uYWwgYXNw
ZWN0cyBvZiB0aGUgSUVURiBkcmFmdHMuIENvbW1lbnRzIHRoYXQgYXJlIG5vdCBhZGRyZXNzZWQg
aW4gbGFzdCBjYWxsIG1heSBiZSBpbmNsdWRlZCBpbiBBRCByZXZpZXdzIGR1cmluZyB0aGUgSUVT
RyByZXZpZXcuICBEb2N1bWVudCBlZGl0b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxkIHRyZWF0IHRo
ZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLg0KDQoN
Cg0KVGhpcyBkcmFmdCBkaXNjdXNzZXMgR3VpZGVsaW5lcyBhbmQgUmVnaXN0cmF0aW9uIFByb2Nl
ZHVyZXMgZm9yIFVSSSBTY2hlbWVzLiBJdCBsb29rcyBPcGVyYXRpb25zIGFuZCBNYW5hZ2VtZW50
IFJldmlldyBDaGVja2xpc3QgZGVmaW5lZCBpbiBSRkM1NzA2IGRvZXNuJ3QgYXBwbHkgc2luY2Ug
dGhlcmUgaXMgbm8gbmV3IHByb3RvY29sIG9yIHByb3RvY29sIGV4dGVuc2lvbiBkZWZpbmVkIGlu
IHRoaXMgZHJhZnQuDQoNCkkgdGhpbmsgdGhpcyBkcmFmdCBpcyByZWFkeSBmb3IgcHVibGljYXRp
b24uIEhlcmUgYXJlIGEgZmV3IGVkaXRvcmlhbCBjb21tZW50czoNCg0KDQoNCjEuICAgICAgIFNl
Y3Rpb24gMSwgbGFzdCB0d28gcGFyYWdyYXBocw0Kcy9JbnRlcmF0aW9uYWxpemVkL0ludGVybmF0
aW9uYWxpemVkDQpzL2FjY29tb2RhdGUvYWNjb21tb2RhdGUNCg0KW0RUXSBEb25lDQoNCg0KMi4g
ICAgICAgU2VjdGlvbiAxLCBsYXN0IHR3byBwYXJhZ3JhcGhzDQpJdCBsb29rcyB0aGVzZSB0d28g
cGFyYWdyYXBocyBtb3JlIGZpdCBpbnRvIFNjaGVtZSBkZWZpbml0aW9uIHJlcXVpcmVtZW50cyBz
ZWN0aW9uLCB3aHkgc3BsaXQgaXQgb3V0IGZyb20gc2VjdGlvbiAzPyB3b3VsZCBpdCBiZSBnb29k
IHRvIGluY29ycG9yYXRlIHRoZXNlIHR3byBwYXJhZ3JhcGhzIGludG8gc2VjdGlvbiAzLCBObyw/
DQoNCltEVF0gRG9uZS4NCg0KDQozLiAgICAgICBTZWN0aW9uIDMsIHRoZSA2dGggcGFyYWdyYXBo
IHNhaWQ6DQqhsA0KVGhlIFVSSSBzY2hlbWUgbmFtZSByZWdpc3RyYXRpb24gcHJvY2VkdXJlIGNh
biBiZSB1c2VkIGluIHN1Y2ggYW4gZXZlbnQuDQqhsQ0KDQpQb2ludGluZyB0byBzZWN0aW9uIDcg
d291bGQgYmUgZ29vZC4NCg0KDQoNCltEVF0gRG9uZS4gIE1hcnRpbiBEdXJzdCBzYWlkIHRoZSBz
YW1lIGluIGhpcyByZXZpZXcuDQoNCg0KDQo0LiAgICAgICBTZWN0aW9uIDQgYW5kIDUNCg0KQXJl
IHRoZXJlIGd1aWRlbGluZXMgZm9yIHBlcm1hbmVudCBVUkkgU2NoZW1lIFJlZ2lzdHJhdGlvbiBp
ZiB0aGVyZSBpcyBwZXJtYW5lbnQgVVJJIFNjaGVtZSBSZWdpc3RyYXRpb24/IE9yIFBlcm1hbmVu
dCBVUkkgU2NoZW1lIFJlZ2lzdHJhdGlvbiBjYW4gb25seSBiZSBwb3NzaWJsZSBieSB1cGdyYWRp
bmcgcHJvdmlzaW9uIFVSSSBTY2hlbWUgUmVnaXN0cmF0aW9uPw0KDQoNCg0KW0RUXSBOb3Qgc3Vy
ZSB3ZSBwYXJzZWQgeW91ciBxdWVzdGlvbiBjb3JyZWN0bHksIGJ1dCBhcyBjby1hdXRob3JzIHdl
IGRpc2N1c3NlZCBhbmQgYmVsaWV2ZSB0aGUgZHJhZnQgaXMgYWxyZWFkeSBjbGVhciBhYm91dCBh
IGNvdXBsZSBwb2ludHM6DQoNCjEpICAgICAgobBDYW4geW91IHJlZ2lzdGVyIGEgbmV3IHBlcm1h
bmVudCBzY2hlbWUsIG9yIG11c3QgeW91IGdvIHRvIHByb3Zpc2lvbmFsIGZpcnN0P6GxICBBOiBj
YW4gZ28gZGlyZWN0bHkgdG8gcGVybWFuZW50LCBhcyBkaXNjdXNzZWQgaW4gc2VjdGlvbiA3LjIg
KGludHJvIHNlbnRlbmNlIHBsdXMgcG9pbnQgMykuDQoNCjIpICAgICAgobBDYW4geW91IHVwZGF0
ZSBhbiBleGlzdGluZyBwZXJtYW5lbnQgc2NoZW1lP6GxIEE6IHllcywgYXMgZGlzY3Vzc2VkIGlu
IHNlY3Rpb24gNy4zLg0KDQoNCg0KLVFpbg0KDQo=

--_000_B8F9A780D330094D99AF023C5877DABA8471994Bnkgeml501mbschi_
Content-Type: text/html; charset="gb2312"
Content-Transfer-Encoding: quoted-printable











Thanks =
Dave for clarification, you address my comments.


&n=
bsp;


-Qin






=B7=A2=BC=FE=C8=CB: Dave Thaler [mailto:dthaler@microsoft.com]


=B7=A2=CB=CD=
=CA=B1=BC=E4: 2015=C4=EA4=D4=C2<=
span lang=3D"EN-US">3=C8=D5
 2:49

=CA=D5=BC=FE=C8=CB: Qin Wu

=B3=AD=CB=CD: ops-dir@ietf.org; draft-ietf-appsawg-uri-scheme-reg.all@tools.ietf.org
=D6=F7=CC=E2: RE: OPS-DIR review of draft-ietf-appsawg-uri-scheme-reg-04






 


Thanks Qin for your review.  Below is what we did in -05..


 








From: Qin Wu [mailto:bill.wu@huawei.com]


Sent: Tuesday, March 3, 2015 4:07 AM

To: ops-dir@ietf.org; 
draft-ietf-appsawg-uri-scheme-reg.all@tools.ietf.org

Subject: OPS-DIR review of draft-ietf-appsawg-uri-scheme-reg-04=







 


Folks:


I have reviewed this documen=
t as part of the Operational directorate's ongoing effort to review all IET=
F documents being processed by the IESG.  These comments were written =
with the intent of improving the operational
 aspects of the IETF drafts. Comments that are not addressed in last call m=
ay be included in AD reviews during the IESG review.  Document editors=
 and WG chairs should treat these comments just like any other last call co=
mments.


 


This draft discusses Guideli=
nes and Registration Procedures for URI Schemes. It looks Operations and Ma=
nagement Review Checklist defined in RFC5706 doesn't apply since there is n=
o new protocol or protocol extension
 defined in this draft.


I think this draft is ready =
for publication. Here are a few editorial comments:


 


1.  =
;    
Section 1, last two paragraphs


s/Interationalized/Internationa=
lized 



s/accomodate/accommodate


 


[DT] Done


 


2.  =
;    
Section 1, last two paragraphs


It looks these two paragraphs m=
ore fit into Scheme definition requirements section, why split it out from =
section 3? would it be good to incorporate these two paragraphs into sectio=
n 3, No,?


 


[DT] Done.


 


3.  =
;    
Section 3, the 6th paragraph said:


=A1=B0


The URI scheme name registration p=
rocedure can be used in such an event.


=A1=B1


Pointing to section 7 woul=
d be good.


 


[DT] Done.  Martin Durst said the same in his review.


 

4.  =
;    
Section 4 and 5


Are there guidelines for p=
ermanent URI Scheme Registration if there is permanent URI Scheme Registrat=
ion? Or Permanent URI Scheme Registration can only be possible by upgrading=
 provision URI Scheme Registration?


 


[DT] Not sure we parsed your question correctly, but as co-a=
uthors we discussed and believe the draft is already clear about a couple p=
oints:


1)     
=A1=B0=
Can you register a new permanent scheme, or must you go to provisional firs=
t?=A1=B1  A: can go directly to permanent, as discussed in section 7.2=
 (intro sentence plus point 3).


2)     
=A1=B0=
Can you update an existing permanent scheme?=A1=B1 A: yes, as discussed in =
section 7.3.


 

-Qin


 








--_000_B8F9A780D330094D99AF023C5877DABA8471994Bnkgeml501mbschi_--


From nobody Mon Apr 13 10:45:06 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C78DE1AD0C1; Mon, 13 Apr 2015 10:45:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yxw4DTIrTgDK; Mon, 13 Apr 2015 10:45:03 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A3E91AD0C2; Mon, 13 Apr 2015 10:45:01 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
To: , ,  ,  , 
X-Test-IDTracker: no
X-IETF-IDTracker: 5.13.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150413174501.15074.28741.idtracker@ietfa.amsl.com>
Date: Mon, 13 Apr 2015 10:45:01 -0700
From: IETF Secretariat 
Archived-At: 
Subject: [apps-discuss] ID Tracker State Update Notice: 
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Apr 2015 17:45:04 -0000

IESG has approved the document and state has been changed to Approved-announcement sent
ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-multipart-form-data/


From nobody Mon Apr 13 12:05:27 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0EDB1B3191; Mon, 13 Apr 2015 12:05:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MGTIqx3S_Kx8; Mon, 13 Apr 2015 12:05:23 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 571831B2A90; Mon, 13 Apr 2015 12:05:23 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
To: , ,  ,  , 
X-Test-IDTracker: no
X-IETF-IDTracker: 5.13.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150413190523.32303.80756.idtracker@ietfa.amsl.com>
Date: Mon, 13 Apr 2015 12:05:23 -0700
From: IETF Secretariat 
Archived-At: 
Subject: [apps-discuss] ID Tracker State Update Notice: 
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 13 Apr 2015 19:05:24 -0000

IANA action state changed to In Progress
ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-multipart-form-data/


From nobody Mon Apr 13 12:05:50 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 511AF1B2A4C; Mon, 13 Apr 2015 12:05:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.711
X-Spam-Level: 
X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id puruqufcRnEJ; Mon, 13 Apr 2015 12:05:43 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AB2B1B31C3; Mon, 13 Apr 2015 12:05:29 -0700 (PDT)
Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Yhjfh-000KFz-L6; Mon, 13 Apr 2015 15:05:25 -0400
Date: Mon, 13 Apr 2015 15:05:20 -0400
From: John C Klensin 
To: "Roy T. Fielding" , Barry Leiba 
Message-ID: <7AD26B88CD9C663FE291611C@JcK-HP8200.jck.com>
In-Reply-To: <327268B5-3817-42F1-90B3-D44158B0AA5D@gbiv.com>
References: <2E49FA112B054FFAED69D8A1@JcK-HP8200.jck.com>  <723FBC93979E1019101319C5@JcK-HP8200.jck.com> <4EA0B2F8-5109-49EA-8BAF-0199D1640407@gbiv.com> <55274198.5030309@andyet.net>   <327268B5-3817-42F1-90B3-D44158B0AA5D@gbiv.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.35
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: 
Cc: draft-ietf-appsawg-uri-scheme-reg.all@ietf.org, IESG , Apps Discuss 
Subject: Re: [apps-discuss] Retroactive application of draft-ietf-appsawg-uri-scheme-reg - comprehensive review
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 13 Apr 2015 19:05:48 -0000

Roy,

I think I've having serious trouble with the position you are
taking but, before I overreact (again?) and confuse things
further, I would appreciate your clarifying something for me.

Let's put 2141bis aside for a moment and go back to 2141 itself.
Section 2 of 2141 says (trimming irrelevant material):

	All URNs have the following syntax [...]:

        ::= "urn:"  ":" 

	The Namespace ID determines the _syntactic_
	interpretation of the Namespace Specific String (as
	discussed in [1])."

Reference [1] points to an I-D that I assume evolved into RFC
2276.

2141 then goes on to say:

      ::= 1*
    ::=  |
        "%"  
    ::=   |  |  |  |
        
      ::=  | "A" | "B" | "C" | "D" | "E" |
       "F" | "a" | "b" | "c" | "d" | "e" | "f"
     ::= "(" | ")" | "+" | "," | "-" | "." |
       ":" | "=" | "@" | ";" | "$" | "_" | "!" | "*" | "'"

Note that, if fragments (or anything delimited by a leading "#")
were allowed, the above would make them part of the NSS.  If I
understand you correctly, that is invalid because, in the syntax
of 3986, the 2141 NSS is necessarily a substring of hier-part,
while 3986 appears to allow "#" (and a fragment) only after the
hier-part.  Is that correct?

And, in section 2.3,

   The reserved character set is:

       ::= '%" | "/" | "?" | "#"

   [...]
  2.3.2 The other reserved characters

  RFC 1630 [2] reserves the characters "/", "?", and "#" for
  particular purposes. The URN-WG has not yet debated the
  applicability and precise semantics of those purposes as
  applied to URNs. Therefore, these characters are RESERVED
  for future developments.  Namespace developers SHOULD NOT
  use these characters in unencoded form, but rather use the
  appropriate %-encoding for each character.

Now, am I correct in my understanding that the above statement
is invalid on its face because no URI scheme can prohibit the
use of fragments, even to the extent of saying that they SHOULD
NOT be used?

Am I also correct in my understanding that the rule(s) that
invalidate the above have nothing to do with any of 4395bis, RFC
4995, or even RFC 3986 but depend only on  RFC 1738 or possibly
RFC 2396?

If any of that is not correct, could you please explain?

thanks,
    john


--On Friday, April 10, 2015 20:44 -0700 "Roy T. Fielding"
 wrote:

>> On Apr 10, 2015, at 8:38 AM, Barry Leiba
>>  wrote:
>> 
>>> No scheme can prohibit fragments. They are not part of the
>>> scheme's syntax.
>> 
>> We continue to have a confusion between syntax and semantics
>> here.
>> 
>> I absolutely agree that no scheme can say that fragments are
>> syntactically invalid, because the schemes do not control the
>> syntax of a URI.
>> 
>> But a scheme can certainly say that fragments make no
>> semantic sense within that scheme, and that if a URIs uses
>> that scheme and contains a fragment, it is not a well formed
>> URI within that scheme.
> 
> No, they can't, or at least they cannot say that truthfully.
>...


From nobody Mon Apr 13 12:05:54 2015
Return-Path: 
X-Original-To: expand-draft-ietf-appsawg-uri-scheme-reg.all@virtual.ietf.org
Delivered-To: apps-discuss@ietfa.amsl.com
Received: by ietfa.amsl.com (Postfix, from userid 65534) id 7F1931B2FD7; Mon, 13 Apr 2015 12:05:48 -0700 (PDT)
X-Original-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com
Delivered-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 511AF1B2A4C; Mon, 13 Apr 2015 12:05:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.711
X-Spam-Level: 
X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id puruqufcRnEJ; Mon, 13 Apr 2015 12:05:43 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AB2B1B31C3; Mon, 13 Apr 2015 12:05:29 -0700 (PDT)
Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Yhjfh-000KFz-L6; Mon, 13 Apr 2015 15:05:25 -0400
Date: Mon, 13 Apr 2015 15:05:20 -0400
From: John C Klensin 
To: "Roy T. Fielding" , Barry Leiba 
Message-ID: <7AD26B88CD9C663FE291611C@JcK-HP8200.jck.com>
In-Reply-To: <327268B5-3817-42F1-90B3-D44158B0AA5D@gbiv.com>
References: <2E49FA112B054FFAED69D8A1@JcK-HP8200.jck.com>  <723FBC93979E1019101319C5@JcK-HP8200.jck.com> <4EA0B2F8-5109-49EA-8BAF-0199D1640407@gbiv.com> <55274198.5030309@andyet.net>   <327268B5-3817-42F1-90B3-D44158B0AA5D@gbiv.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.35
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: 
Cc: draft-ietf-appsawg-uri-scheme-reg.all@ietf.org, IESG , Apps Discuss 
Subject: Re: [apps-discuss] Retroactive application of draft-ietf-appsawg-uri-scheme-reg - comprehensive review
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 13 Apr 2015 19:05:48 -0000

Roy,

I think I've having serious trouble with the position you are
taking but, before I overreact (again?) and confuse things
further, I would appreciate your clarifying something for me.

Let's put 2141bis aside for a moment and go back to 2141 itself.
Section 2 of 2141 says (trimming irrelevant material):

	All URNs have the following syntax [...]:

        ::= "urn:"  ":" 

	The Namespace ID determines the _syntactic_
	interpretation of the Namespace Specific String (as
	discussed in [1])."

Reference [1] points to an I-D that I assume evolved into RFC
2276.

2141 then goes on to say:

      ::= 1*
    ::=  |
        "%"  
    ::=   |  |  |  |
        
      ::=  | "A" | "B" | "C" | "D" | "E" |
       "F" | "a" | "b" | "c" | "d" | "e" | "f"
     ::= "(" | ")" | "+" | "," | "-" | "." |
       ":" | "=" | "@" | ";" | "$" | "_" | "!" | "*" | "'"

Note that, if fragments (or anything delimited by a leading "#")
were allowed, the above would make them part of the NSS.  If I
understand you correctly, that is invalid because, in the syntax
of 3986, the 2141 NSS is necessarily a substring of hier-part,
while 3986 appears to allow "#" (and a fragment) only after the
hier-part.  Is that correct?

And, in section 2.3,

   The reserved character set is:

       ::= '%" | "/" | "?" | "#"

   [...]
  2.3.2 The other reserved characters

  RFC 1630 [2] reserves the characters "/", "?", and "#" for
  particular purposes. The URN-WG has not yet debated the
  applicability and precise semantics of those purposes as
  applied to URNs. Therefore, these characters are RESERVED
  for future developments.  Namespace developers SHOULD NOT
  use these characters in unencoded form, but rather use the
  appropriate %-encoding for each character.

Now, am I correct in my understanding that the above statement
is invalid on its face because no URI scheme can prohibit the
use of fragments, even to the extent of saying that they SHOULD
NOT be used?

Am I also correct in my understanding that the rule(s) that
invalidate the above have nothing to do with any of 4395bis, RFC
4995, or even RFC 3986 but depend only on  RFC 1738 or possibly
RFC 2396?

If any of that is not correct, could you please explain?

thanks,
    john


--On Friday, April 10, 2015 20:44 -0700 "Roy T. Fielding"
 wrote:

>> On Apr 10, 2015, at 8:38 AM, Barry Leiba
>>  wrote:
>> 
>>> No scheme can prohibit fragments. They are not part of the
>>> scheme's syntax.
>> 
>> We continue to have a confusion between syntax and semantics
>> here.
>> 
>> I absolutely agree that no scheme can say that fragments are
>> syntactically invalid, because the schemes do not control the
>> syntax of a URI.
>> 
>> But a scheme can certainly say that fragments make no
>> semantic sense within that scheme, and that if a URIs uses
>> that scheme and contains a fragment, it is not a well formed
>> URI within that scheme.
> 
> No, they can't, or at least they cannot say that truthfully.
>...


From nobody Mon Apr 13 13:11:04 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B6721A1B61; Mon, 13 Apr 2015 13:11:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CXEVSzDzqWPg; Mon, 13 Apr 2015 13:11:00 -0700 (PDT)
Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85DB01A1B05; Mon, 13 Apr 2015 13:11:00 -0700 (PDT)
Received: by igbpi8 with SMTP id pi8so34179736igb.0; Mon, 13 Apr 2015 13:11:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TxZGHeTTs2u7kccT2Ru1NQmmORPtvwQqTkEbT38/njc=; b=AXrGoVRb0HzE44IOxfyUJQOT04gOROD3Q0yKCKxHCqmZ9rZY5/TIADIP0C3sfTQJjq 4d8TBF4zAks1L3ExrtZNkWaswk459QRyQOvtKCzQAEDmAgkHLa4eBWEY5JqmzhS90sH1 tHqhr5euglJ494nmcpaRzJGKoVbRp7PjywQebNthyqvSppkbEGW8ASI2xk2C9Y0vhXFZ SAS9eJYRdprvAsyr4wAAzzdulq/pFSUxa2S1NaJn2x/1MSpixPoXCnWGCxclZDFXLhTV QWjp4lmdzs/iH0JpX5bEgdHLgCGKGAOtFR1WIRppdG5f9jcAm7oC/x5osp4ScZEQ1N9A yNQg==
MIME-Version: 1.0
X-Received: by 10.50.122.39 with SMTP id lp7mr18964176igb.24.1428955860033; Mon, 13 Apr 2015 13:11:00 -0700 (PDT)
Received: by 10.107.12.4 with HTTP; Mon, 13 Apr 2015 13:10:59 -0700 (PDT)
In-Reply-To: 
References:  <20150413014159.22807.61234.idtracker@ietfa.amsl.com> 
Date: Mon, 13 Apr 2015 16:10:59 -0400
Message-ID: 
From: Nick Matavka 
To: iesg-secretary@ietf.org
Content-Type: multipart/alternative; boundary=001a11c1e5326fe92c0513a0b608
Archived-At: 
Cc: internet-drafts@ietf.org, apps-discuss@ietf.org
Subject: [apps-discuss] Fwd: [www.ietf.org/rt #92672] Manual Post Requested for draft-matavka-gopher-ii
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 13 Apr 2015 20:11:02 -0000

--001a11c1e5326fe92c0513a0b608
Content-Type: text/plain; charset=UTF-8

To whom it may concern:

The draft that I wrote had a Notice of Compliance with BCP 78/79 and a
guidelines paragraph... the IDNITS checker on the Draft Submission Tool
passed it with no problem.  Could you please explain to my why Mr Khan has
rejected the draft even though the BCP compliance notice was in fact
present, as was the guidelines paragraph?

Thanks

Ted Matavka


---------- Forwarded message ----------
From: Naveen Khan via RT 
Date: 13 April 2015 at 14:02
Subject: [www.ietf.org/rt #92672] Manual Post Requested for
draft-matavka-gopher-ii
To: idsubmission@ietf.org, n.theodore.matavka.files@gmail.com,
wolfgangmcq@gmail.com


Hi Ted & Wolfgang,

Your draft did not pass IDNITS for the following reasons:

** The document seems to lack a Notice of Compliance with BCP 78 and BCP 79
according to IETF Trust Provisions of 28 Dec 2009, Section 6.a or
Provisions of
12 Sep 2009, Section 6.a. IETF Trust Legal Provisions of 28-dec-2009,
Section
6.a: This Internet-Draft is submitted in full conformance with the
provisions
of BCP 78 and BCP 79.

** The document seems to lack a 1id_guidelines paragraph about
Internet-Drafts
being working documents. 1id_guidelines, paragraph 1: Internet-Drafts are
working documents of the Internet Engineering Task Force (IETF), its areas,
and
its working groups. Note that other groups may also distribute working
documents as Internet-Drafts.

Please fix these errors and resubmit, and I will be happy to get this posted
for you.

Sincerely,
Naveen Khan
IETF Secretariat



On Sun Apr 12 18:42:01 2015, idsubmission@ietf.org wrote:
>
> Hi,
>
> Manual posting has been requested for the following Internet-Draft:
>
> I-D Submission Tool URL:
> http://datatracker.ietf.org/submit/status/68412/
>
> File name : draft-matavka-gopher-ii
> Revision : 00
> Submission date : 2015-04-12
> Group : Individual Submission
>
> Title : Gopher-II: The Next Generation Gopher WWIS
> Document date : 2015-04-11
> Pages : 24
> File size : 59.3 KB
>
> Submitter : Ted Matavka 
>
> Abstract : The Gopher protocol is over twenty years old.
> Changing practices and
> unofficial extensions have caused Gopher as currently used to differ,
> but remain largely compatible with, the standard established in its
> official governing document, *The Internet Gopher Protocol (a
> distributed document search and retrieval protocol)*, known as *RFC
> 1436*. Therefore, this document attempts to establish a contemporary
> specification of the Gopher communications protocol, departing as
> little as possible from current practice.
>
>
>
> Authors:
> Ted Matavka 
> Wolfgang Faust 
>
>
> Comment to the secretariat:
>
>
>




-- 
       /^\/^\
       \----|
   _---'---~~~~-_
    ~~~|~~L~|~~~~
       (/_  /~~--
     \~ \  /  /~
   __~\  ~ /   ~~----,
   \    | |       /  \
   /|   |/       |    |
   | | | o  o     /~   |
 _-~_  |        ||  \  /
(// )) | o  o    \\---'
//_- |  |          \
//   |____|\______\__\
~      |   / |    |
       |_ /   \ _|
     /~___|  /____\

--001a11c1e5326fe92c0513a0b608
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


To whom it may concern:

The draft that =
I wrote had a Notice of Compliance with BCP 78/79 and a guidelines paragrap=
h... the IDNITS checker on the Draft Submission Tool passed it with no prob=
lem.=C2=A0 Could you please explain to my why Mr Khan has rejected the draf=
t even though the BCP compliance notice was in fact present, as was the gui=
delines paragraph?

Thanks

Ted Matavka


------=
---- Forwarded message ----------
From: Na=
veen Khan via RT <ietf-draft-submission@ietf.org><=
/span>
Date: 13 April 2015 at 14:02
Subject: [www.ietf.org/rt #92672] Manual Post Reque=
sted for draft-matavka-gopher-ii
To: idsubmission@ietf.org, n.theodore.matavka.files@gm=
ail.com, wol=
fgangmcq@gmail.com


Hi Ted & Wolfgang,



Your draft did not pass IDNITS for the following reasons:



** The document seems to lack a Notice of Compliance with BCP 78 and BCP 79=


according to IETF Trust Provisions of 28 Dec 2009, Section 6.a or Provision=
s of

12 Sep 2009, Section 6.a. IETF Trust Legal Provisions of 28-dec-2009, Secti=
on

6.a: This Internet-Draft is submitted in full conformance with the provisio=
ns

of BCP 78 and BCP 79.



** The document seems to lack a 1id_guidelines paragraph about Internet-Dra=
fts

being working documents. 1id_guidelines, paragraph 1: Internet-Drafts are
working documents of the Internet Engineering Task Force (IETF), its areas,=
 and

its working groups. Note that other groups may also distribute working

documents as Internet-Drafts.



Please fix these errors and resubmit, and I will be happy to get this poste=
d

for you.



Sincerely,

Naveen Khan

IETF Secretariat








On Sun Apr 12 18:42:01 2015, idsubmission@ietf.org wrote:

>

> Hi,

>

> Manual posting has been requested for the following Internet-Draft:
>

> I-D Submission Tool URL:

> http://datatracker.ietf.org/submit/status/68412/

>

> File name : draft-matavka-gopher-ii

> Revision : 00

> Submission date : 2015-04-12

> Group : Individual Submission

>

> Title : Gopher-II: The Next Generation Gopher WWIS

> Document date : 2015-04-11

> Pages : 24

> File size : 59.3 KB

>

> Submitter : Ted Matavka <n.theodore.matavka.files@gmail.com>
>

> Abstract : The Gopher protocol is over twenty years old.

> Changing practices and

> unofficial extensions have caused Gopher as currently used to differ,<=
br>
> but remain largely compatible with, the standard established in its
> official governing document, *The Internet Gopher Protocol (a

> distributed document search and retrieval protocol)*, known as *RFC
> 1436*. Therefore, this document attempts to establish a contemporary
> specification of the Gopher communications protocol, departing as

> little as possible from current practice.

>

>

>

> Authors:

> Ted Matavka <n.theodore.matavka.files@gmail.com>

> Wolfgang Faust <wolfgangmcq@gmail.com>

>

>

> Comment to the secretariat:

>

>

>







-- 
 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0/^\/^\
 =C2=A0 =C2=A0 =C2=A0 =C2=A0\----|
 =C2=A0=
 =C2=A0_---'---~~~~-_ =C2=A0
 =C2=A0 =C2=A0 ~~~|~~L~|~~~~
 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0(/_ =C2=A0/~~--
 =C2=A0 =C2=A0 =C2=A0\~ \ =C2=A0/ =
=C2=A0/~
 =C2=A0 =C2=A0__~\ =C2=A0~ / =C2=A0 ~~----,
 =C2=A0 =C2=A0\ =
=C2=A0 =C2=A0| | =C2=A0 =C2=A0 =C2=A0 / =C2=A0\ =C2=A0
 =C2=A0 =C2=A0/| =
=C2=A0 |/ =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0|
 =C2=A0 =C2=A0| | | o =
=C2=A0o =C2=A0 =C2=A0 /~ =C2=A0 | =C2=A0
 =C2=A0_-~_ =C2=A0| =C2=A0 =C2=
=A0 =C2=A0 =C2=A0|| =C2=A0\ =C2=A0/
 (// )) | o =C2=A0o =C2=A0 =C2=A0\\-=
--'
 //_- | =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0\ 
// =C2=
=A0 |____|\______\__\
~ =C2=A0 =C2=A0 =C2=A0| =C2=A0 / | =C2=A0 =C2=A0|<=
br> =C2=A0 =C2=A0 =C2=A0 =C2=A0|_ / =C2=A0 \ _|
 =C2=A0 =C2=A0 =C2=A0/~_=
__| =C2=A0/____\ =C2=A0 =C2=A0 =C2=A0 =C2=A0 




--001a11c1e5326fe92c0513a0b608--


From nobody Mon Apr 13 14:35:27 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4FD81A8867 for ; Mon, 13 Apr 2015 14:35:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1cL_OOaBSXvB for ; Mon, 13 Apr 2015 14:35:24 -0700 (PDT)
Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A88DF1A8862 for ; Mon, 13 Apr 2015 14:35:24 -0700 (PDT)
Received: by igbqf9 with SMTP id qf9so248710igb.1 for ; Mon, 13 Apr 2015 14:35:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:date:message-id:subject:from:to:content-type; bh=KEKdkkU7zWtJXvaYqSeanHynxxoAV2dSJjEfLSb738Q=; b=OHXsPs87qUktQh/vypn46p6Bxywf2ruU31YubN3VsfNoDeAmbgGpLEmycltFCH0J8u v8XnrKMpj8exd2QafUDNDpSvgAJgQsGRVNEkg/lzOzYpR9zmKfY003Fr3jJPcawdr0rc 2jcmWwFalohSkj1atPEa6dHzzFp5wFUINDunHAcjuzeMwI8DMAR/P4pGLwRQKkNyJbEE sc8Q3A6/gneXz9gfwjmxebjMGFxogk7woPDEK/vwZ/4BHt/prhu2wETsFmBD/KA2mmSj WGIkBqCqY1IywnwvuesoyssFm+P/xU0JsvOSdthW673mVwb3hE3eF6IC6rK7E78/54JP Rsew==
MIME-Version: 1.0
X-Received: by 10.107.160.212 with SMTP id j203mr24523899ioe.43.1428960924057;  Mon, 13 Apr 2015 14:35:24 -0700 (PDT)
Received: by 10.107.12.4 with HTTP; Mon, 13 Apr 2015 14:35:24 -0700 (PDT)
Date: Mon, 13 Apr 2015 17:35:24 -0400
Message-ID: 
From: Nick Matavka 
To: apps-discuss@ietf.org
Content-Type: multipart/alternative; boundary=001a1140375c46c8370513a1e4a7
Archived-At: 
Subject: [apps-discuss] Gopher Internet-Draft
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 13 Apr 2015 21:35:26 -0000

--001a1140375c46c8370513a1e4a7
Content-Type: text/plain; charset=UTF-8

Welp, here we go.

Gopher I-D now in the IETF process.

Accessible at http://datatracker.ietf.org/doc/draft-matavka-gopher-ii/

With fraternal greetings,

N. E. Matavka

-- 
       /^\/^\
       \----|
   _---'---~~~~-_
    ~~~|~~L~|~~~~
       (/_  /~~--
     \~ \  /  /~
   __~\  ~ /   ~~----,
   \    | |       /  \
   /|   |/       |    |
   | | | o  o     /~   |
 _-~_  |        ||  \  /
(// )) | o  o    \\---'
//_- |  |          \
//   |____|\______\__\
~      |   / |    |
       |_ /   \ _|
     /~___|  /____\

--001a1140375c46c8370513a1e4a7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: base64

PGRpdiBkaXI9Imx0ciI+V2VscCwgaGVyZSB3ZSBnby48ZGl2Pjxicj48L2Rpdj48ZGl2PkdvcGhl
ciBJLUQgbm93IGluIHRoZSBJRVRGIHByb2Nlc3MuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5B
Y2Nlc3NpYmxlIGF0wqA8YSBocmVmPSJodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry
YWZ0LW1hdGF2a2EtZ29waGVyLWlpLyI+aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k
cmFmdC1tYXRhdmthLWdvcGhlci1paS88L2E+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5XaXRo
IGZyYXRlcm5hbCBncmVldGluZ3MsPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5OLiBFLiBNYXRh
dmthPGJyIGNsZWFyPSJhbGwiPjxkaXY+PGJyPjwvZGl2Pi0tIDxicj48ZGl2IGNsYXNzPSJnbWFp
bF9zaWduYXR1cmUiPiDCoCDCoCDCoCDCoC9eXC9eXDxicj4gwqAgwqAgwqAgwqBcLS0tLXw8YnI+
IMKgIMKgXy0tLSYjMzk7LS0tfn5+fi1fIMKgPGJyPiDCoCDCoCB+fn58fn5Mfnx+fn5+PGJyPiDC
oCDCoCDCoCDCoCgvXyDCoC9+fi0tPGJyPiDCoCDCoCDCoFx+IFwgwqAvIMKgL348YnI+IMKgIMKg
X19+XCDCoH4gLyDCoCB+fi0tLS0sPGJyPiDCoCDCoFwgwqAgwqB8IHwgwqAgwqAgwqAgLyDCoFwg
wqA8YnI+IMKgIMKgL3wgwqAgfC8gwqAgwqAgwqAgfCDCoCDCoHw8YnI+IMKgIMKgfCB8IHwgbyDC
oG8gwqAgwqAgL34gwqAgfCDCoDxicj4gwqBfLX5fIMKgfCDCoCDCoCDCoCDCoHx8IMKgXCDCoC88
YnI+ICgvLyApKSB8IG8gwqBvIMKgIMKgXFwtLS0mIzM5Ozxicj4gLy9fLSB8IMKgfCDCoCDCoCDC
oCDCoCDCoFwgPGJyPi8vIMKgIHxfX19ffFxfX19fX19cX19cPGJyPn4gwqAgwqAgwqB8IMKgIC8g
fCDCoCDCoHw8YnI+IMKgIMKgIMKgIMKgfF8gLyDCoCBcIF98PGJyPiDCoCDCoCDCoC9+X19ffCDC
oC9fX19fXCDCoCDCoCDCoCDCoCA8YnI+PC9kaXY+DQo8L2Rpdj48L2Rpdj4NCg==
--001a1140375c46c8370513a1e4a7--


From nobody Mon Apr 13 21:28:22 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 877931B3329; Mon, 13 Apr 2015 21:28:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.666
X-Spam-Level: 
X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kpykjReZH5L9; Mon, 13 Apr 2015 21:28:17 -0700 (PDT)
Received: from homiemail-a33.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 4424B1B3328; Mon, 13 Apr 2015 21:28:17 -0700 (PDT)
Received: from homiemail-a33.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTP id 2381759406B; Mon, 13 Apr 2015 21:28:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=content-type :mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=gbiv.com; bh=aKtSXzS+1nfrRnMek1jdMh8ZlCk=; b=vRjt/+mjpdLuR2QPYMHfLOA/YTLk NQz/8BbdCkTniqmYIKUuTafqsZ8vZY07g7EaaO5HxWcldD1/k/zx1W53fRAOMlUZ ZVI6w6LVGACcIHZ8/GqV3JnRJlxrwXj4NqXQcAznTzPkC7UckK6Ta9OORBt6vNde iPxMPIa1rLNs0C0=
Received: from [10.71.5.221] (unknown [207.238.37.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTPSA id A5B40594057; Mon, 13 Apr 2015 21:28:16 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: "Roy T. Fielding" 
In-Reply-To: <7AD26B88CD9C663FE291611C@JcK-HP8200.jck.com>
Date: Mon, 13 Apr 2015 23:28:17 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <4D6A426F-8905-4DFC-90D2-86B85939A58E@gbiv.com>
References: <2E49FA112B054FFAED69D8A1@JcK-HP8200.jck.com>  <723FBC93979E1019101319C5@JcK-HP8200.jck.com> <4EA0B2F8-5109-49EA-8BAF-0199D1640407@gbiv.com> <55274198.5030309@andyet.net>   <327268B5-3817-42F1-90B3-D44158B0AA5D@gbiv.com> <7AD26B88CD9C663FE291611C@JcK-HP8200.jck.com>
To: John C Klensin 
X-Mailer: Apple Mail (2.2098)
Archived-At: 
Cc: Apps Discuss , Barry Leiba , IESG , draft-ietf-appsawg-uri-scheme-reg.all@ietf.org
Subject: Re: [apps-discuss] Retroactive application of draft-ietf-appsawg-uri-scheme-reg - comprehensive review
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 14 Apr 2015 04:28:18 -0000

> On Apr 13, 2015, at 2:05 PM, John C Klensin  wrote:
>=20
> Roy,
>=20
> I think I've having serious trouble with the position you are
> taking but, before I overreact (again?) and confuse things
> further, I would appreciate your clarifying something for me.
>=20
> Let's put 2141bis aside for a moment and go back to 2141 itself.
> Section 2 of 2141 says (trimming irrelevant material):
>=20
> 	All URNs have the following syntax [...]:
>=20
>        ::=3D "urn:"  ":" 
>=20
> 	The Namespace ID determines the _syntactic_
> 	interpretation of the Namespace Specific String (as
> 	discussed in [1])."
>=20
> Reference [1] points to an I-D that I assume evolved into RFC
> 2276.
>=20
> 2141 then goes on to say:
>=20
>      ::=3D 1*
>    ::=3D  |
>        "%"  
>    ::=3D   |  |  |  |
>        
>      ::=3D  | "A" | "B" | "C" | "D" | "E" |
>       "F" | "a" | "b" | "c" | "d" | "e" | "f"
>     ::=3D "(" | ")" | "+" | "," | "-" | "." |
>       ":" | "=3D" | "@" | ";" | "$" | "_" | "!" | "*" | "'"
>=20
> Note that, if fragments (or anything delimited by a leading "#")
> were allowed, the above would make them part of the NSS.  If I
> understand you correctly, that is invalid because, in the syntax
> of 3986, the 2141 NSS is necessarily a substring of hier-part,
> while 3986 appears to allow "#" (and a fragment) only after the
> hier-part.  Is that correct?

Umm, not sure I understand the question.  The syntax above should not =
allow
a fragment delimiter "#" to be part of the NSS, which should mean that =
the 
would match the absolute-URI production of 3986.  In other words, it =
would be
valid if it excludes the fragment.

  http://tools.ietf.org/html/rfc3986#section-4.3

> And, in section 2.3,
>=20
>   The reserved character set is:
>=20
>       ::=3D '%" | "/" | "?" | "#"

And there is the bug.  In RFC1808 and RFC2396, the "#" wasn't in the =
reserved set.
It was in the punctuation or delims set, which meant it was never =
allowed outside
of the specific occurrence as the fragment delimiter.  In RFC3986, the =
"#" is in
the reserved set, but the reserved set is for illustrative purposes only =
in both
2396 and 3986 (the URI grammar itself does not make use of the reserved =
production).

  http://tools.ietf.org/html/rfc2396#section-2.4.3

>   [...]
>  2.3.2 The other reserved characters
>=20
>  RFC 1630 [2] reserves the characters "/", "?", and "#" for
>  particular purposes. The URN-WG has not yet debated the
>  applicability and precise semantics of those purposes as
>  applied to URNs. Therefore, these characters are RESERVED
>  for future developments.  Namespace developers SHOULD NOT
>  use these characters in unencoded form, but rather use the
>  appropriate %-encoding for each character.
>=20
> Now, am I correct in my understanding that the above statement
> is invalid on its face because no URI scheme can prohibit the
> use of fragments, even to the extent of saying that they SHOULD
> NOT be used?

Yes.  More to the point, it should have said that they MUST NOT be
in NSS, since the fragment is not part of the URL, and they should have
been referring to RFC1808 (a proposed standard at that time), not
RFC1630 (an informational RFC).  In general, though, this was understood
and expected to be resolved as part of the development of RFC2396 and
finally in the form of RFC3986.  The IETF did a lot of work on URI
in the 18 years since RFC2141.

> Am I also correct in my understanding that the rule(s) that
> invalidate the above have nothing to do with any of 4395bis, RFC
> 4995, or even RFC 3986 but depend only on  RFC 1738 or possibly
> RFC 2396?

RFC1808, RFC2396, and RFC3986 (in succession).  We did have these =
discussions
about fragment, each time, which is why the requirement in RFC3986 (sec =
4.3)
is very clear (IMO), and why it is repeated in 4395bis.  It is specified
that way because scheme-specific fragment is neither desirable (from the
architecture PoV) nor interoperable (most software separates the =
fragment
as part of reference parsing, before doing anything with the scheme).


Cheers,

Roy T. Fielding                     
Senior Principal Scientist, Adobe   


From nobody Mon Apr 13 21:28:24 2015
Return-Path: 
X-Original-To: expand-draft-ietf-appsawg-uri-scheme-reg.all@virtual.ietf.org
Delivered-To: apps-discuss@ietfa.amsl.com
Received: by ietfa.amsl.com (Postfix, from userid 65534) id A38881B332A; Mon, 13 Apr 2015 21:28:18 -0700 (PDT)
X-Original-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com
Delivered-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 877931B3329; Mon, 13 Apr 2015 21:28:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.666
X-Spam-Level: 
X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kpykjReZH5L9; Mon, 13 Apr 2015 21:28:17 -0700 (PDT)
Received: from homiemail-a33.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 4424B1B3328; Mon, 13 Apr 2015 21:28:17 -0700 (PDT)
Received: from homiemail-a33.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTP id 2381759406B; Mon, 13 Apr 2015 21:28:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=content-type :mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=gbiv.com; bh=aKtSXzS+1nfrRnMek1jdMh8ZlCk=; b=vRjt/+mjpdLuR2QPYMHfLOA/YTLk NQz/8BbdCkTniqmYIKUuTafqsZ8vZY07g7EaaO5HxWcldD1/k/zx1W53fRAOMlUZ ZVI6w6LVGACcIHZ8/GqV3JnRJlxrwXj4NqXQcAznTzPkC7UckK6Ta9OORBt6vNde iPxMPIa1rLNs0C0=
Received: from [10.71.5.221] (unknown [207.238.37.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTPSA id A5B40594057; Mon, 13 Apr 2015 21:28:16 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: "Roy T. Fielding" 
In-Reply-To: <7AD26B88CD9C663FE291611C@JcK-HP8200.jck.com>
Date: Mon, 13 Apr 2015 23:28:17 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <4D6A426F-8905-4DFC-90D2-86B85939A58E@gbiv.com>
References: <2E49FA112B054FFAED69D8A1@JcK-HP8200.jck.com>  <723FBC93979E1019101319C5@JcK-HP8200.jck.com> <4EA0B2F8-5109-49EA-8BAF-0199D1640407@gbiv.com> <55274198.5030309@andyet.net>   <327268B5-3817-42F1-90B3-D44158B0AA5D@gbiv.com> <7AD26B88CD9C663FE291611C@JcK-HP8200.jck.com>
To: John C Klensin 
X-Mailer: Apple Mail (2.2098)
Archived-At: 
Cc: Apps Discuss , Barry Leiba , IESG , draft-ietf-appsawg-uri-scheme-reg.all@ietf.org
Subject: Re: [apps-discuss] Retroactive application of draft-ietf-appsawg-uri-scheme-reg - comprehensive review
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 14 Apr 2015 04:28:18 -0000

> On Apr 13, 2015, at 2:05 PM, John C Klensin  wrote:
>=20
> Roy,
>=20
> I think I've having serious trouble with the position you are
> taking but, before I overreact (again?) and confuse things
> further, I would appreciate your clarifying something for me.
>=20
> Let's put 2141bis aside for a moment and go back to 2141 itself.
> Section 2 of 2141 says (trimming irrelevant material):
>=20
> 	All URNs have the following syntax [...]:
>=20
>        ::=3D "urn:"  ":" 
>=20
> 	The Namespace ID determines the _syntactic_
> 	interpretation of the Namespace Specific String (as
> 	discussed in [1])."
>=20
> Reference [1] points to an I-D that I assume evolved into RFC
> 2276.
>=20
> 2141 then goes on to say:
>=20
>      ::=3D 1*
>    ::=3D  |
>        "%"  
>    ::=3D   |  |  |  |
>        
>      ::=3D  | "A" | "B" | "C" | "D" | "E" |
>       "F" | "a" | "b" | "c" | "d" | "e" | "f"
>     ::=3D "(" | ")" | "+" | "," | "-" | "." |
>       ":" | "=3D" | "@" | ";" | "$" | "_" | "!" | "*" | "'"
>=20
> Note that, if fragments (or anything delimited by a leading "#")
> were allowed, the above would make them part of the NSS.  If I
> understand you correctly, that is invalid because, in the syntax
> of 3986, the 2141 NSS is necessarily a substring of hier-part,
> while 3986 appears to allow "#" (and a fragment) only after the
> hier-part.  Is that correct?

Umm, not sure I understand the question.  The syntax above should not =
allow
a fragment delimiter "#" to be part of the NSS, which should mean that =
the 
would match the absolute-URI production of 3986.  In other words, it =
would be
valid if it excludes the fragment.

  http://tools.ietf.org/html/rfc3986#section-4.3

> And, in section 2.3,
>=20
>   The reserved character set is:
>=20
>       ::=3D '%" | "/" | "?" | "#"

And there is the bug.  In RFC1808 and RFC2396, the "#" wasn't in the =
reserved set.
It was in the punctuation or delims set, which meant it was never =
allowed outside
of the specific occurrence as the fragment delimiter.  In RFC3986, the =
"#" is in
the reserved set, but the reserved set is for illustrative purposes only =
in both
2396 and 3986 (the URI grammar itself does not make use of the reserved =
production).

  http://tools.ietf.org/html/rfc2396#section-2.4.3

>   [...]
>  2.3.2 The other reserved characters
>=20
>  RFC 1630 [2] reserves the characters "/", "?", and "#" for
>  particular purposes. The URN-WG has not yet debated the
>  applicability and precise semantics of those purposes as
>  applied to URNs. Therefore, these characters are RESERVED
>  for future developments.  Namespace developers SHOULD NOT
>  use these characters in unencoded form, but rather use the
>  appropriate %-encoding for each character.
>=20
> Now, am I correct in my understanding that the above statement
> is invalid on its face because no URI scheme can prohibit the
> use of fragments, even to the extent of saying that they SHOULD
> NOT be used?

Yes.  More to the point, it should have said that they MUST NOT be
in NSS, since the fragment is not part of the URL, and they should have
been referring to RFC1808 (a proposed standard at that time), not
RFC1630 (an informational RFC).  In general, though, this was understood
and expected to be resolved as part of the development of RFC2396 and
finally in the form of RFC3986.  The IETF did a lot of work on URI
in the 18 years since RFC2141.

> Am I also correct in my understanding that the rule(s) that
> invalidate the above have nothing to do with any of 4395bis, RFC
> 4995, or even RFC 3986 but depend only on  RFC 1738 or possibly
> RFC 2396?

RFC1808, RFC2396, and RFC3986 (in succession).  We did have these =
discussions
about fragment, each time, which is why the requirement in RFC3986 (sec =
4.3)
is very clear (IMO), and why it is repeated in 4395bis.  It is specified
that way because scheme-specific fragment is neither desirable (from the
architecture PoV) nor interoperable (most software separates the =
fragment
as part of reference parsing, before doing anything with the scheme).


Cheers,

Roy T. Fielding                     
Senior Principal Scientist, Adobe   


From nobody Tue Apr 14 01:06:59 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A46C1B351D; Tue, 14 Apr 2015 01:06:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WE7l-13wey-G; Tue, 14 Apr 2015 01:06:57 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7791B1B3524; Tue, 14 Apr 2015 01:06:48 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.0.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150414080648.20012.38227.idtracker@ietfa.amsl.com>
Date: Tue, 14 Apr 2015 01:06:48 -0700
Archived-At: 
Cc: apps-discuss@ietf.org
Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Apr 2015 08:06:58 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Applications Area Working Group Working Group of the IETF.

        Title           : The file URI Scheme
        Author          : Matthew Kerwin
	Filename        : draft-ietf-appsawg-file-scheme-01.txt
	Pages           : 17
	Date            : 2015-04-14

Abstract:
   This document specifies the "file" Uniform Resource Identifier (URI)
   scheme, obsoleting the definition in RFC 1738.

   It attemps to define a common core which is intended to interoperate
   across the broad spectrum of existing implementations, while at the
   same time documenting other current practices.

Note to Readers (To be removed by the RFC Editor)

   This draft should be discussed on the IETF Applications Area Working
   Group discussion list .


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-appsawg-file-scheme/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-appsawg-file-scheme-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-file-scheme-01


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Tue Apr 14 03:38:05 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 096871A8868 for ; Tue, 14 Apr 2015 03:38:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.027
X-Spam-Level: 
X-Spam-Status: No, score=-1.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gY26VWGJBYXQ for ; Tue, 14 Apr 2015 03:38:01 -0700 (PDT)
Received: from mail-vn0-x231.google.com (mail-vn0-x231.google.com [IPv6:2607:f8b0:400c:c0f::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 507E11A885F for ; Tue, 14 Apr 2015 03:38:01 -0700 (PDT)
Received: by vnbf129 with SMTP id f129so1807629vnb.9 for ; Tue, 14 Apr 2015 03:38:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=dc1V6dFSLfMW27wOjRUG7CICT9zXfgPhwuqLwYiGMxE=; b=e0Rtr/Us/odBc9LJNjj0TfcNdr9EJ9EGGne96ln7+nksbKxQhDHFGxztKUB82LO46q afu756cuu0yfwMBQGF6Y5fyoDXcARs3MHhSMFn8gsPO5957VjOTwzr7957jPeCzsj6hy d2wl/DKl2Q5FcM3i9syejm6TadqzFYiwI26pzy0SXwuGgEoLNp2G91ssUWatvgHgMH9L mu/6atnvEn1ckVaSLiOlnxZEImIbyt0Ky9RMnxXLT/OkPTW2MN4Z8YxaW2Ph98U8A/J1 cfWH8ZqhLK05UGnhbQorzbRoZEKHI6kVLI81n0wepy70J4+sAHc4isTuc1mmoA/hQudm or7w==
MIME-Version: 1.0
X-Received: by 10.202.192.7 with SMTP id q7mr10740622oif.85.1429007880463; Tue, 14 Apr 2015 03:38:00 -0700 (PDT)
Sender: phluid61@gmail.com
Received: by 10.202.178.3 with HTTP; Tue, 14 Apr 2015 03:38:00 -0700 (PDT)
In-Reply-To: <20150414080648.20012.38227.idtracker@ietfa.amsl.com>
References: <20150414080648.20012.38227.idtracker@ietfa.amsl.com>
Date: Tue, 14 Apr 2015 20:38:00 +1000
X-Google-Sender-Auth: Kp7KruA2RqcUhDGflkBDusHvqEM
Message-ID: 
From: Matthew Kerwin 
To: IETF Apps Discuss 
Content-Type: multipart/alternative; boundary=001a113dcdd218ae180513acd3d9
Archived-At: 
Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 14 Apr 2015 10:38:04 -0000

--001a113dcdd218ae180513acd3d9
Content-Type: text/plain; charset=UTF-8

Hi again folks,

I managed to get a new version pushed out. It's not ready for publication,
but it should be ready for proper critique. Between -00 and -01 I focused
on addressing the broad thrust of the comments received so far, notably:

* cutting out everything but a central core from the normative syntax,
moving the non-universal bits to optional appendices

* less normative content and references, hopefully putting less burden on
implementers (especially those who are only mildly interested in supporting
the scheme)

* putting a bit more effort into defining meaningful operations

There are some obvious editorial issues, especially some incomplete text in
the appendices.  What I'd really appreciate advice on is:

1) whether the new structure broadly satisfies a bunch of the concerns that
have been raised, and

2) how to deal with the IANA Considerations section (especially considering
the uri-scheme-reg draft.) Back at draft-kerwin-file-scheme-11 it had a
fully fleshed out registration template, but somebody (I forget who, sorry)
suggested that I could replace it with the current (much terser) text.
Which way should I go with it?

I'm going to go back through the archives and see what remaining concerns
still apply, so I can create some issues in my github repository. Please
feel free to provide feedback and critique in the meantime.

Cheers!


On 14 April 2015 at 18:06,  wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>  This draft is a work item of the Applications Area Working Group Working
> Group of the IETF.
>
>         Title           : The file URI Scheme
>         Author          : Matthew Kerwin
>         Filename        : draft-ietf-appsawg-file-scheme-01.txt
>         Pages           : 17
>         Date            : 2015-04-14
>
> Abstract:
>    This document specifies the "file" Uniform Resource Identifier (URI)
>    scheme, obsoleting the definition in RFC 1738.
>
>    It attemps to define a common core which is intended to interoperate
>    across the broad spectrum of existing implementations, while at the
>    same time documenting other current practices.
>
> Note to Readers (To be removed by the RFC Editor)
>
>    This draft should be discussed on the IETF Applications Area Working
>    Group discussion list .
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-appsawg-file-scheme/
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-appsawg-file-scheme-01
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-file-scheme-01
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>



-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/

--001a113dcdd218ae180513acd3d9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi again folks,

=
I managed to get a new version pushed out. It's not ready for publicati=
on, but it should be ready for proper critique. Between -00 and -01 I focus=
ed on addressing the broad thrust of the comments received so far, notably:=


* cutting out everything but a central co=
re from the normative syntax, moving the non-universal bits to optional app=
endices

* less normative content and refer=
ences, hopefully putting less burden on implementers (especially those who =
are only mildly interested in supporting the scheme)

* putting a bit more effort into defining meaningful operations<=
/div>

There are some obvious editorial issues, e=
specially some incomplete text in the appendices.=C2=A0 What I'd really=
 appreciate advice on is:

1) whether the n=
ew structure broadly satisfies a bunch of the concerns that have been raise=
d, and

2) how to deal with the IANA Consid=
erations section (especially considering the uri-scheme-reg draft.) Back at=
=C2=A0draft-kerwin-file-scheme-11 it had a fully fleshed out registration t=
emplate, but somebody (I forget who, sorry) suggested that I could replace =
it with the current (much terser) text. Which way should I go with it?

I'm going to go back through the archives =
and see what remaining concerns still apply, so I can create some issues in=
 my github repository. Please feel free to provide feedback and critique in=
 the meantime.

Cheers!
<=
br>

On 14 Ap=
ril 2015 at 18:06,  <internet-drafts@ietf.org> wrote:=



A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.

=C2=A0This draft is a work item of the Applications Area Working Group Work=
ing Group of the IETF.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=
 The file URI Scheme

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Matt=
hew Kerwin

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet=
f-appsawg-file-scheme-01.txt

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:=
 17

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 :=
 2015-04-14



Abstract:

=C2=A0 =C2=A0This document specifies the "file" Uniform Resource =
Identifier (URI)

=C2=A0 =C2=A0scheme, obsoleting the definition in RFC 1738.



=C2=A0 =C2=A0It attemps to define a common core which is intended to intero=
perate

=C2=A0 =C2=A0across the broad spectrum of existing implementations, while a=
t the

=C2=A0 =C2=A0same time documenting other current practices.



Note to Readers (To be removed by the RFC Editor)



=C2=A0 =C2=A0This draft should be discussed on the IETF Applications Area W=
orking

=C2=A0 =C2=A0Group discussion list <apps-discuss@ietf.org>.





The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/doc/draft-ietf-appsawg-fil=
e-scheme/



There's also a htmlized version available at:

http://tools.ietf.org/html/draft-ietf-appsawg-file-scheme-0=
1



A diff from the previous version is available at:

http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsa=
wg-file-scheme-01





Please note that it may take a couple of minutes from the time of submissio=
n

until the htmlized version and diff are available at tools.ietf.org.



Internet-Drafts are also available by anonymous FTP at:

ftp://ftp=
.ietf.org/internet-drafts/



_______________________________________________

apps-discuss mailing list

apps-discuss@ietf.org

https://www.ietf.org/mailman/listinfo/apps-discuss





-- 
=C2=A0 Matthew Kerwin
=C2=A0 http://matthew.kerwi=
n.net.au/




--001a113dcdd218ae180513acd3d9--


From nobody Tue Apr 14 04:03:49 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D2371A88F4 for ; Tue, 14 Apr 2015 04:03:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fBvMUAZlCxNi for ; Tue, 14 Apr 2015 04:03:43 -0700 (PDT)
Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0719.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::719]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 502641A88F1 for ; Tue, 14 Apr 2015 04:03:15 -0700 (PDT)
Received: from AMSPR07MB050.eurprd07.prod.outlook.com (10.242.81.24) by AMSPR07MB376.eurprd07.prod.outlook.com (10.242.21.20) with Microsoft SMTP Server (TLS) id 15.1.130.23; Tue, 14 Apr 2015 11:01:25 +0000
Received: from pc6 (81.151.162.168) by AMSPR07MB050.eurprd07.prod.outlook.com (10.242.81.24) with Microsoft SMTP Server (TLS) id 15.1.130.23; Tue, 14 Apr 2015 11:01:24 +0000
Message-ID: <023401d076a2$2be127e0$4001a8c0@gateway.2wire.net>
From: t.petch 
To: Nick Matavka 
References:  <20150413014159.22807.61234.idtracker@ietfa.amsl.com>  
Date: Tue, 14 Apr 2015 12:00:00 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [81.151.162.168]
X-ClientProxiedBy: DB3PR08CA0020.eurprd08.prod.outlook.com (25.161.51.158) To AMSPR07MB050.eurprd07.prod.outlook.com (10.242.81.24)
Authentication-Results: gmail.com; dkim=none (message not signed) header.d=none;
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB050; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB376; 
X-Microsoft-Antispam-PRVS: 
X-Forefront-Antispam-Report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(377424004)(377454003)(2473001)(51704005)(24454002)(92566002)(15975445007)(40100003)(61296003)(62236002)(93886004)(33646002)(44716002)(1456003)(46102003)(5890100001)(62966003)(50466002)(50226001)(122386002)(77156002)(42186005)(77096005)(116806002)(19580395003)(19580405001)(86362001)(44736004)(230783001)(110136001)(14496001)(84392001)(87976001)(81816999)(76176999)(50986999)(66066001)(47776003)(23676002)(81686999)(74416001)(7726001)(163123001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMSPR07MB050; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; 
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:AMSPR07MB050; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB050; 
X-Forefront-PRVS: 054642504A
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Apr 2015 11:01:24.1230 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB050
X-OriginatorOrg: btconnect.com
Archived-At: 
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Fwd: [www.ietf.org/rt #92672] Manual Post Requested for draft-matavka-gopher-ii
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 14 Apr 2015 11:03:46 -0000

Nick

You do not attach the draft so it is difficult to know what went wrong,
but I would assume that you did not comply with the legal requirements
surrounding copyright.  Also, note the the internet-drafts mailing list
is the one that sends to you, not one that you ever send to.

Meanwhile, learn xml2rfc!  If you stick around and submit more I-D, it
will save you a lot of grief.  Yes, learning a new technology is a pain
and costs time, but the investment pays for itself in reducing the
stress of interacting with the IETF's computer systems.  And, like any
language source, you only ever have to produce it once and then copy it
for all future ones; in fact, if you are judicious, you can purloin an
existing source from the IETF website.  Bear in mind that the copyright
rules are that anything submitted to the IETF can be used by anyone for
the production of any I-D, so I can lift anything I like by anyone for
use in another I-D (but I would not recommend the xml of my own I-Ds, I
don't know what I am doing:-).

Tom Petch

----- Original Message -----
From: "Nick Matavka" 
To: 
Cc: ; 
Sent: Monday, April 13, 2015 9:10 PM
Subject: [apps-discuss] Fwd: [www.ietf.org/rt #92672] Manual Post
Requested for draft-matavka-gopher-ii


> To whom it may concern:
>
> The draft that I wrote had a Notice of Compliance with BCP 78/79 and a
> guidelines paragraph... the IDNITS checker on the Draft Submission
Tool
> passed it with no problem.  Could you please explain to my why Mr Khan
has
> rejected the draft even though the BCP compliance notice was in fact
> present, as was the guidelines paragraph?
>
> Thanks
>
> Ted Matavka
>
>
> ---------- Forwarded message ----------
> From: Naveen Khan via RT 
> Date: 13 April 2015 at 14:02
> Subject: [www.ietf.org/rt #92672] Manual Post Requested for
> draft-matavka-gopher-ii
> To: idsubmission@ietf.org, n.theodore.matavka.files@gmail.com,
> wolfgangmcq@gmail.com
>
>
> Hi Ted & Wolfgang,
>
> Your draft did not pass IDNITS for the following reasons:
>
> ** The document seems to lack a Notice of Compliance with BCP 78 and
BCP 79
> according to IETF Trust Provisions of 28 Dec 2009, Section 6.a or
> Provisions of
> 12 Sep 2009, Section 6.a. IETF Trust Legal Provisions of 28-dec-2009,
> Section
> 6.a: This Internet-Draft is submitted in full conformance with the
> provisions
> of BCP 78 and BCP 79.
>
> ** The document seems to lack a 1id_guidelines paragraph about
> Internet-Drafts
> being working documents. 1id_guidelines, paragraph 1: Internet-Drafts
are
> working documents of the Internet Engineering Task Force (IETF), its
areas,
> and
> its working groups. Note that other groups may also distribute working
> documents as Internet-Drafts.
>
> Please fix these errors and resubmit, and I will be happy to get this
posted
> for you.
>
> Sincerely,
> Naveen Khan
> IETF Secretariat
>
>
>
> On Sun Apr 12 18:42:01 2015, idsubmission@ietf.org wrote:
> >
> > Hi,
> >
> > Manual posting has been requested for the following Internet-Draft:
> >
> > I-D Submission Tool URL:
> > http://datatracker.ietf.org/submit/status/68412/
> >
> > File name : draft-matavka-gopher-ii
> > Revision : 00
> > Submission date : 2015-04-12
> > Group : Individual Submission
> >
> > Title : Gopher-II: The Next Generation Gopher WWIS
> > Document date : 2015-04-11
> > Pages : 24
> > File size : 59.3 KB
> >
> > Submitter : Ted Matavka 
> >
> > Abstract : The Gopher protocol is over twenty years old.
> > Changing practices and
> > unofficial extensions have caused Gopher as currently used to
differ,
> > but remain largely compatible with, the standard established in its
> > official governing document, *The Internet Gopher Protocol (a
> > distributed document search and retrieval protocol)*, known as *RFC
> > 1436*. Therefore, this document attempts to establish a contemporary
> > specification of the Gopher communications protocol, departing as
> > little as possible from current practice.
> >
> >
> >
> > Authors:
> > Ted Matavka 
> > Wolfgang Faust 
> >
> >
> > Comment to the secretariat:
> >
> >
> >
>
>
>
>
> --
>        /^\/^\
>        \----|
>    _---'---~~~~-_
>     ~~~|~~L~|~~~~
>        (/_  /~~--
>      \~ \  /  /~
>    __~\  ~ /   ~~----,
>    \    | |       /  \
>    /|   |/       |    |
>    | | | o  o     /~   |
>  _-~_  |        ||  \  /
> (// )) | o  o    \\---'
> //_- |  |          \
> //   |____|\______\__\
> ~      |   / |    |
>        |_ /   \ _|
>      /~___|  /____\
>


------------------------------------------------------------------------
--------


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


From nobody Tue Apr 14 07:27:02 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7EFF1AC3A6; Tue, 14 Apr 2015 07:26:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.211
X-Spam-Level: 
X-Spam-Status: No, score=-14.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8HJ4_lplR479; Tue, 14 Apr 2015 07:26:54 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C8361AC39F; Tue, 14 Apr 2015 07:26:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3383; q=dns/txt; s=iport; t=1429021613; x=1430231213; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=onmkAQx3hctsyZqQVuU8bn2RJedZUabLU4Rfiz4dOF8=; b=SANdB3UJqnRl/c8AKcrN2GPxkzILDIeUTVR4lOE06DYjLR+HXwBcF0cc yAk8ooOM/+ZCuJsZauExabZn6aAxViIyUZTA27iz+433iYmgu178kwvTj w8LFivoFCGkyGy/twEJ17YEcvTbia1hInX5iicbx3nkjDYIjhzBFfeyKu M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BcBADfIi1V/49dJa1cgwxSXAWDEMJRCYFOhgECgUE4FAEBAQEBAQF9hCABAQMBIw8BRQEFCwsUBgIFFgsCAgkDAgECATUQBg0BBwEBiB4IDbVLlXoBAQEBAQEBAQEBAQEBAQEBAQEBAQEXgSGKCoQxGDMHgmiBRQWLMIlXhhiBHTqCfYJEigeDTSKCAh2Bb1ABgUN/AQEB
X-IronPort-AV: E=Sophos;i="5.11,576,1422921600"; d="scan'208";a="141064936"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-1.cisco.com with ESMTP; 14 Apr 2015 14:26:52 +0000
Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t3EEQq29032238 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 14 Apr 2015 14:26:52 GMT
Received: from [64.101.72.55] (64.101.72.55) by xhc-aln-x01.cisco.com (173.36.12.75) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 14 Apr 2015 09:26:51 -0500
Message-ID: <552D23AC.7050703@cisco.com>
Date: Tue, 14 Apr 2015 08:26:52 -0600
From: =?UTF-8?B?4oyYIE1hdHQgTWlsbGVy?= 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: 
References: <552C3E12.50607@cisco.com>
In-Reply-To: <552C3E12.50607@cisco.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-Originating-IP: [64.101.72.55]
Archived-At: 
Cc: cdni@ietf.org, IETF Apps Discuss 
Subject: Re: [apps-discuss] appsdir early review of draft-ietf-cdni-redirection
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 14 Apr 2015 14:26:59 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

[ Resending to include apps-discuss ]

> I have been selected as the Applications Area Directorate early 
> reviewer for this draft (for background on appsdir, please see 
> http://trac.tools.ietf.org/area/app/trac/wiki/ 
> ApplicationsAreaDirectorate).
> 
> Please resolve these comments along with any other Last Call 
> comments you may receive. Please wait for direction from your 
> document shepherd or AD before posting a new version of the draft.
> 
> Document: draft-ietf-cdni-redirection Title: Request Routing 
> Redirection Interface for CDN Interconnection Reviewer: Matthew 
> Miller Review Date: 2015-04-13 IETF Last Call Date: N/A IESG 
> Telechat Date: N/A
> 
> 
> Summary: This draft has minor issues, and is ready for publication
>  as a Proposed Standard once these issues are resolved.
> 
> Major Issues:  None
> 
> Minor Issues:
> 
> * In Section 4.2., some of the language about the JSON encoding 
> correctness can be handled by conforming to I-JSON [RFC7493],
> which this draft already does in spirit.
> 
> * In Section 4.5.2., it's not clear why the keys "sc(location)", 
> "sc(cache-control)", and "sc()" are different from the 
> other "sc-"-based keys; I would have expected them to be 
> "sc-location", "sc-cache-control", and "sc-".  This 
> deviates from the text in Section 4.5 that says "sc- is prefixed
> to keys for information to be passed by the Server (uCDN) to the 
> Client (User Agent)."  I suggest you either change the keys to be 
> "sc-" instead of "sc()", or change the text in 
> Section 4.5 .
> 
> * In Section 4.7., it seems very odd that all of the error object 
> keys are optional.  Is the intent really that the following is 
> valid?
> 
> "error": {}
> 
> If it is, then an explanation of when and why that is valid would 
> be very helpful to me.  Otherwise, I suggest mandating at least 
> "error-code ".
> 
> * In Section 5., I would strongly consider referring to 
> draft-ietf-uta-tls-bcp (currently in the RFC Editor's Queue), and 
> incorporating its recommendations.  I think this draft
> accomplishes the basics, but I think you get a more complete
> picture with -tls-bcp.
> 
> Nits:
> 
> * The acronym CDN should be expanded in the Abstract.  Some might 
> also argue it should be expanded in the title, but not me.
> 
> * The terms list in Section 2. is editorially a bit awkward to me;
>  I expected there to be hanging indents.  In the XML, this can be 
> accomplished by wrapping the new terms'  with  style='hanging'> and placing the attribute hangtext equal to the 
> term for each terms'  (e.g., The act of using an application ...)
> 
> 
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJVLSOsAAoJEDWi+S0W7cO1fZ8H/0Ew+qOZGyMz5JnBiFgajGWA
JddcGDOKES3wSdO4rwnG0y+D9GRHz/3JYmhDalyo/8MvDSsxQ+Z8vDuN0AEk5dLV
QOe/4DR4T10v9z5ZPcwQSEXY3dYSJoXc7Je0f7gw4Dhnp1croQ4o+6Qo8+W7pGwt
7jLzkeeKR8FJ9gPf5sQ0/zPBXf5Nhmgs9d/ZjbzuLVJOIpt77sr09dIwq8k30PaB
O3765+dgH0jRjgaZuu7VZU429/TwDE/uaffCG8UcBDXjh6j/7zEgHwTDIwTj+5Ed
3onZ2bha/Q10vGUO7ooaj5jNNB2r1I/P9F4FSk8DMH7ioMP5KEI6e5Bml4z0/8U=
=oeMr
-----END PGP SIGNATURE-----


From nobody Tue Apr 14 10:46:34 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 291E71A1A7F; Tue, 14 Apr 2015 10:46:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GKyLDspPInrP; Tue, 14 Apr 2015 10:46:32 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 08F081A1A68; Tue, 14 Apr 2015 10:46:32 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
To: , ,  ,  , 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.0.0.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150414174632.8472.12414.idtracker@ietfa.amsl.com>
Date: Tue, 14 Apr 2015 10:46:32 -0700
From: IETF Secretariat 
Archived-At: 
Subject: [apps-discuss] ID Tracker State Update Notice: 
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Apr 2015 17:46:33 -0000

IESG state changed to RFC Ed Queue from Approved-announcement sent
ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-multipart-form-data/


From nobody Tue Apr 14 12:50:37 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC7641B2F98; Tue, 14 Apr 2015 12:50:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.211
X-Spam-Level: 
X-Spam-Status: No, score=-14.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pRyMss1LeMFL; Tue, 14 Apr 2015 12:50:33 -0700 (PDT)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97C2E1B2F97; Tue, 14 Apr 2015 12:50:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5037; q=dns/txt; s=iport; t=1429041033; x=1430250633; h=message-id:date:from:mime-version:to:cc:subject: content-transfer-encoding; bh=rfDxqDjQ/mOaaWcoP+iLcGLlwt4RlvxiVydqedf19K0=; b=jn1X7TkLV1pGvbpY6atMq8u16F9lmXbKUMU5JzgLB/gZoD8+uVqLIJOG 9jkTGZl+nKzPD/RILR5UzPCME80/IKduuyUxDqAcfqyK36uNCuDs6Ks6g xsBu8pwKF5qx1RUdx25rAPjDaI/vULYV3fUXtoWpE4jOJzsDQp0JV1Icg I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AYBQA3by1V/5xdJa1cgwxSXAWDEMQvhX+BSzsRAQEBAQEBAX2EIicPAUUBLwYCBRYLAgsDAgECAUsBDAEFAgEBiCYNtXiWAAEBAQEBAQEBAQEBAQEBAQEBAQEZgSGPBoJvgUUFizCJV4YYgR06gn2CRIoHg00iggIdgW9QAYFDfwEBAQ
X-IronPort-AV: E=Sophos;i="5.11,577,1422921600"; d="scan'208";a="141229904"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-2.cisco.com with ESMTP; 14 Apr 2015 19:50:12 +0000
Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t3EJoBTD019144 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 14 Apr 2015 19:50:11 GMT
Received: from [64.101.72.55] (64.101.72.55) by xhc-aln-x01.cisco.com (173.36.12.75) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 14 Apr 2015 14:50:11 -0500
Message-ID: <552D6F72.7060901@cisco.com>
Date: Tue, 14 Apr 2015 13:50:10 -0600
From: =?UTF-8?B?4oyYIE1hdHQgTWlsbGVy?= 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: , 
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Originating-IP: [64.101.72.55]
Archived-At: 
Cc: IETF Apps Discuss 
Subject: [apps-discuss] Appsdir early review of draft-ietf-cdni-metadata-09
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 14 Apr 2015 19:50:36 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

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

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

Document: draft-ietf-cdni-metadata
Title: CDN Interconnection Metadata
Reviewer: Matthew Miller
Review Date: 2015-04-14
IETF Last Call Date: N/A
IESG Telechat Date: N/A

Summary: This draft is not ready for publication as a Proposed
Standard and should be revised.

Comments:

This draft is written expecting multiple encodings in the future, then
spends very little space discussing the one encoding that is defined
(JSON).  The end result is a document that, in my opinion, is too
abstract.  I think it would be more understandable if this draft
mentioned and used JSON throughout (e.g., a micro-example for each of
the defined types).  I think it's appropriate to do this and yet still
reserve the right to support other encoding formats in the future.

Also, this draft is not very internally consistent (e.g., terminology
usage, editorial structuring, etc.), which I found made it hard to
follow at times.  I would recommend that the authors do a round of
editing to be more internally consistent; I've noted in the nits a
number of specific examples.

Major Issues:

* I think Section 6.4.2. is underspecified.  There are a number of
quirks and gotchas I noticed that are not discussed:

  - dealing with large (requiring more than ~53 bits) integers (encode
as JSON String)
  - dealing with duplicate keys within a JSON Object (MUST NOT have
duplicates)
  - dealing with escaping (see Minor Issue #2)

  I note that the examples in 6.4.2.1. illustrate some of the
concerns, but nowhere are they explicitly discussed.  I would strongly
recommend outlining these concerns, better would be to refer to RFC
7492 (I-JSON) and follow its recommendations explicitly.  I don't
think this is much of a burden since this document appears to already
follow them implicitly.


Minor Issues:

* In Section 3.1., I find Table 2 hard to follow.  I suggest each row
be broken out to its own item in an unordered list.  It would also
help to point to each item's full definition.

* In Section 4.1.5., note that '\' must be escaped as '\\' in JSON,
which means the JSON string for a  with a literal '\' would have
'\\\\' (this also applies for literal '?' and '*').  I can understand
why an alternative form of escaping, such as percent encoding, would
be undesirable, but it will be surprising to some to see this "extra
escaping".  This effect on pattern escaping ought to be called out; if
not in Section 4.1.5. then I suggest in Section 6.4.2.

* Sections 8.2., 8.3., and 8.5., seem to cover the concerns, but I
would recommend reviewing and referencing draf-ietf-uta-tls-bcp, as I
think you would get a more complete picture here.

Nits:

* In Abstract, CDN is not expanded on first occurrence.

* In Abstract, CDNI is not expanded on first occurrence.

* In Section 1.2., dCDN is not expanded on first occurrence.

* In Section 1.2., uCDN is not expanded on first occurrence.

* Reference to HTTPv1.1 (commonly referred to as "HTTP/1.1") (RFC7230,
et al) comes very late (Section 7.2.), first noted in Section 1.2.

* No reference to HTTPv2.0 (often referred to as "http/2")
(draft-ietf-httpbis-http2-17), first noted in Section 1.2.

* Reference to HTTP over TLS (RFC 2818) comes very late (Section
7.2.), first noted in Section 1.2.

* No reference to JSON (RFC 7159), first noted in Section 2.

* In Section 3.2., the two tables are not captioned.

* In Section 4.2.4.1., "protocol" is not capitalized (i.e.,
"Protocol") like other type references in "Type: List of protocol object
s"

* In Section 6. and many of its subsections, "Downstream CDN" is often
used instead of "dCDN", which is elsewhere in this document.  I would
recommend more consistency and use "dCDN".

* In Section 6. and many of its subsections, "Upstream CDN" is often
used instead of "uCDN", which is elsewhere in this document.  I would
recommend more consistency and use "uCDN".


- -- 
- - m&m

Matt Miller < mamille2@cisco.com >
Cisco Systems, Inc.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJVLW9yAAoJEDWi+S0W7cO1g9UIAJIV8yShj/0KiqhC82m/ixk6
VkW5IZvB8iWp9mVStx+fQtwwm1B7LrvccFnSr5CwmyURjmaljSBKP97F6I/QnjpL
6YJkfGyRLTP1r/fpH7N9ptpHZJQpNd5iQlBElWforfBaNHd5xm4mhLkCzlv8UKjk
TP8SDYeW5pKvUkHtK7fhW7h2eTcs/EuPZr/GlTb9yIWQAAwN0q7JTnwXVN1Lo9uQ
ap1mqUnG2YdZMuAKqrDUQRywazIuBGPu8DopbKX6Hl9fyuSEnPUry73P+7aK727x
T+/qHyARqy5PGSgesRYAQdFy3gS4/8SeeYWHpkE+7MPSjTNj4nTralxfcu7uxAU=
=+QNl
-----END PGP SIGNATURE-----


From nobody Wed Apr 15 14:05:39 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32E4E1A8FD7; Wed, 15 Apr 2015 14:05:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fK4IdPlxnfyH; Wed, 15 Apr 2015 14:05:27 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E2E281A8F4B; Wed, 15 Apr 2015 14:05:27 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
To: , ,  ,  , 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.0.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150415210527.4264.6642.idtracker@ietfa.amsl.com>
Date: Wed, 15 Apr 2015 14:05:27 -0700
From: IETF Secretariat 
Archived-At: 
Subject: [apps-discuss] ID Tracker State Update Notice: 
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Apr 2015 21:05:35 -0000

IANA action state changed to Waiting on Authors
ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-multipart-form-data/


From nobody Wed Apr 15 21:55:49 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49C681B2FA5; Wed, 15 Apr 2015 21:55:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94x7ESxym_Ga; Wed, 15 Apr 2015 21:55:46 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71A7E1B2F86; Wed, 15 Apr 2015 21:55:46 -0700 (PDT)
Received: from [192.168.123.110] (unknown [23.241.1.22]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id B9A5C22E1F4; Thu, 16 Apr 2015 00:55:43 -0400 (EDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_0B93A74B-117D-4AD6-A59E-5727ED0FB600"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Sean Leonard 
In-Reply-To: <327268B5-3817-42F1-90B3-D44158B0AA5D@gbiv.com>
Date: Wed, 15 Apr 2015 21:54:54 -0700
Message-Id: <46C605DB-0885-428F-90BD-C2988DA161DD@seantek.com>
References: <2E49FA112B054FFAED69D8A1@JcK-HP8200.jck.com>  <723FBC93979E1019101319C5@JcK-HP8200.jck.com> <4EA0B2F8-5109-49EA-8BAF-0199D1640407@gbiv.com> <55274198.5030309@andyet.net>   <327268B5-3817-42F1-90B3-D44158B0AA5D@gbiv.com>
To: "Roy T. Fielding" 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: 
Cc: Apps Discuss , Barry Leiba , IESG , "draft-ietf-appsawg-uri-scheme-reg.all@ietf.org" 
Subject: Re: [apps-discuss] Retroactive application of draft-ietf-appsawg-uri-scheme-reg - comprehensive review
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 16 Apr 2015 04:55:48 -0000

--Apple-Mail=_0B93A74B-117D-4AD6-A59E-5727ED0FB600
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


On Apr 10, 2015, at 8:44 PM, Roy T. Fielding  wrote:

>> On Apr 10, 2015, at 8:38 AM, Barry Leiba  =
wrote:
>>=20
>>> No scheme can prohibit fragments. They are not part of the scheme's =
syntax.
>>=20
>> We continue to have a confusion between syntax and semantics here.
>>=20
>> I absolutely agree that no scheme can say that fragments are
>> syntactically invalid, because the schemes do not control the syntax
>> of a URI.
>>=20
>> But a scheme can certainly say that fragments make no semantic sense
>> within that scheme, and that if a URIs uses that scheme and contains =
a
>> fragment, it is not a well formed URI within that scheme.
>=20
> No, they can't, or at least they cannot say that truthfully.
>=20
>> It's rather like saying that English words are composed of characters
>> from the set "abcdefghijklmnopqrstuvwxyz", and, therefore, the string
>> "qwx" is a valid piece of an English word (syntax)... but that, in
>> fact, no valid English words contain "qwx" (semantics).
>=20
> Sorry, you've lost me.
>=20
> It is more like saying that, because host and port are adjacent to =
each other in
> the syntax, it is therefore possible for DNS to specify what ports are =
allowed.
>=20
>> That's not a layering violation at all -- it has to be up to the
>> scheme to say what the semantic meaning of a fragment is within that
>> scheme, or whether fragments have any meaning at all.
>=20
> It has nothing to do with the scheme. Nothing whatsoever. It is true =
that there
> are many resources, regardless of scheme, for which a fragment =
identifier wouldn't
> have much practical purpose other than as a name, but that's only =
because
> nobody has found a reason to resolve them yet. In most cases, this is =
because
> deployment of the scheme is so small that it isn't worth anyone's =
bother to create
> a gateway for information about its identified resources.

I agree with Barry.

The scheme transitively defines the semantic meaning of fragments =
because the scheme defines the kinds of resources (if any) that are =
identified by it. Those resources may or may not have Internet media =
types, and those resources may or may not assign semantic meanings to =
fragments.

mailto: defines a URI scheme that does not identify representations of =
anything; it is used to launch a compose window to create new mail. =
(Arguably a mailto: URI identifies a mailbox.) Therefore fragment =
identifiers have no semantic meaning in mailto: because mailto: doesn=92t =
use them.

[RFC6068] says:
   Note that this specification, like any URI scheme specification, does
   not define syntax or meaning of a fragment identifier (see [STD66]),
   because these depend on the type of a retrieved representation.  In
   the currently known usage scenarios, a 'mailto' URI cannot be used to
   retrieve such representations.  Therefore, fragment identifiers are
   meaningless, SHOULD NOT be used on 'mailto' URIs, and SHOULD be
   ignored upon resolution.  The character "#" in s MUST be
   escaped as %23.


This text is entirely consistent with Barry=92s point. The scheme may =
not define the semantics of the fragment directly, but it defines the =
resources (representations), which in turn define the fragments.

Sean

PS I could be wrong but [RFC3966] looks like it permits the # character =
in the tel: URI in the path part. Is there a legacy reason for that, or =
just an oversight?=

--Apple-Mail=_0B93A74B-117D-4AD6-A59E-5727ED0FB600
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ9jCCBK8w
ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF
MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l
dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw
WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl
c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV
BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls
IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW
51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD
FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI
kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az
aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA
P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD
VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG
AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw
RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu
YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl
cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm
am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7
BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl
nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK
2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7
mzCCBT8wggQnoAMCAQICEBpCSs8n+cQbczyWKtueyecwDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV
BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY
BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg
QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTAyMDIwMDAwMDBaFw0xNjAy
MDIyMzU5NTlaMCUxIzAhBgkqhkiG9w0BCQEWFGRlditpZXRmQHNlYW50ZWsuY29tMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz4n20qAOzUtC1oNz5zgTny0JRBE1mJZszV2s6EurahKP
vku7E+utnLhcaNahAWr2oZgeCK9uhEqijaC4qLZHnGt/+lnbsQtjmMJrcFCzhDZjDOJdYzmuS2cU
vZqY7YwzCG6jSfs4gwNh+29MS6faY6ucncbnfO9rBB0xu5GIdI3BzsPNYnACNlBYU7w4X4GA0/Mw
NAabNhDgxU2Tw1fl5w1Vt+6xRTXBk6V93LyVZN9wBIOpr2MuhoCJLHZrLirv/mbQE5ao4pkJLR/s
yYhS1Ko4MSiJmR3ugKPkxEo6DZkuJrfck36hLmtMo3yuzi7hkXmDzPKkdLlNj+Xek1GWtwIDAQAB
o4IB8jCCAe4wHwYDVR0jBBgwFoAUkmFrguGioKpP7GfxwqP3tIAAwewwHQYDVR0OBBYEFBpm5d7y
8PBT6NqnIVbfNK8hbpPGMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcG
CCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7Bgwr
BgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMw
XQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp
ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBkAYIKwYBBQUHAQEEgYMwgYAw
WAYIKwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVudEF1
dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw
LmNvbW9kb2NhLmNvbTAfBgNVHREEGDAWgRRkZXYraWV0ZkBzZWFudGVrLmNvbTANBgkqhkiG9w0B
AQsFAAOCAQEAeIf/Nevvv10ssk0unrJb9FC8lJi41sSpq5AFYtmC8IXwUmNxL7L5uE3tGlNJVoTK
ZvGeklYWDRCzq6zqte221TowXYmFO7G27rJZbQRjLzQoY63rMlFPFrjqQCEA6rDgo9DlFO9/81P7
ZC7xvZ52WH7e3p/yJNA4Av8E0eeavhC+l+cwtrw0wCp3gUs5xJT0koGVvli2wR18zecG3ib3ml+G
nDDv2AH7OhcyhVoj6V9AeGQa2HqaVpOQVRUNPamqr3xeARKk5sUSeBvxlF+0FWhl+AnhqNdxmeEp
qpgSvbcS1jbTsqApvgsBcDzjC09wV8mtBoMCtqlHvF3YY2z55jGCA8MwggO/AgEBMIGwMIGbMQsw
CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk
MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xp
ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBpCSs8n+cQbczyWKtueyecw
CQYFKw4DAhoFAKCCAecwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN
MTUwNDE2MDQ1NTQxWjAjBgkqhkiG9w0BCQQxFgQUerwZvFRXkqz4VLDrnj788iOlV6EwgcEGCSsG
AQQBgjcQBDGBszCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl
cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMT
OENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB
AhAaQkrPJ/nEG3M8lirbnsnnMIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0Ix
GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR
Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50
aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAaQkrPJ/nEG3M8lirbnsnnMA0GCSqGSIb3DQEB
AQUABIIBAAu1EVRea0W/J0BvJbF8+XvJcHwBIii4AGd8e1dz4x+5yNITB0Qb2nbNCmL+4QbCTaej
f0su6+c3BuwZTVW2LATRLLkZfp+qkP4T+8b+43WphLob1M5iIOK3fBcdr72w/wj2GxmGcKKoMD6w
tM66k/gBsfFRiqniYuEXJWODK8XBu04f1kQLq397800yhfMjO5v3cyr9ZDPRLw34ss3A+Ddkkvzc
2gXJFz9bqADcChsptVqFk0MYXlNXKC9JuFCh01FAiqmMTel2faN+UhrpDZZ0IYsxMnjWuj9r1dXI
V5P4l3kf9nRSnq1fYbu+LCQ3PptkD7j0Y9YJgdIWpEz7VgwAAAAAAAA=

--Apple-Mail=_0B93A74B-117D-4AD6-A59E-5727ED0FB600--


From nobody Wed Apr 15 21:56:00 2015
Return-Path: 
X-Original-To: expand-draft-ietf-appsawg-uri-scheme-reg.all@virtual.ietf.org
Delivered-To: apps-discuss@ietfa.amsl.com
Received: by ietfa.amsl.com (Postfix, from userid 65534) id 770861B2FAA; Wed, 15 Apr 2015 21:55:48 -0700 (PDT)
X-Original-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com
Delivered-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49C681B2FA5; Wed, 15 Apr 2015 21:55:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94x7ESxym_Ga; Wed, 15 Apr 2015 21:55:46 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71A7E1B2F86; Wed, 15 Apr 2015 21:55:46 -0700 (PDT)
Received: from [192.168.123.110] (unknown [23.241.1.22]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id B9A5C22E1F4; Thu, 16 Apr 2015 00:55:43 -0400 (EDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_0B93A74B-117D-4AD6-A59E-5727ED0FB600"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Sean Leonard 
In-Reply-To: <327268B5-3817-42F1-90B3-D44158B0AA5D@gbiv.com>
Date: Wed, 15 Apr 2015 21:54:54 -0700
Message-Id: <46C605DB-0885-428F-90BD-C2988DA161DD@seantek.com>
References: <2E49FA112B054FFAED69D8A1@JcK-HP8200.jck.com>  <723FBC93979E1019101319C5@JcK-HP8200.jck.com> <4EA0B2F8-5109-49EA-8BAF-0199D1640407@gbiv.com> <55274198.5030309@andyet.net>   <327268B5-3817-42F1-90B3-D44158B0AA5D@gbiv.com>
To: "Roy T. Fielding" 
X-Mailer: Apple Mail (2.1878.6)
Archived-At: 
Cc: Apps Discuss , Barry Leiba , IESG , "draft-ietf-appsawg-uri-scheme-reg.all@ietf.org" 
Subject: Re: [apps-discuss] Retroactive application of draft-ietf-appsawg-uri-scheme-reg - comprehensive review
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 16 Apr 2015 04:55:48 -0000

--Apple-Mail=_0B93A74B-117D-4AD6-A59E-5727ED0FB600
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


On Apr 10, 2015, at 8:44 PM, Roy T. Fielding  wrote:

>> On Apr 10, 2015, at 8:38 AM, Barry Leiba  =
wrote:
>>=20
>>> No scheme can prohibit fragments. They are not part of the scheme's =
syntax.
>>=20
>> We continue to have a confusion between syntax and semantics here.
>>=20
>> I absolutely agree that no scheme can say that fragments are
>> syntactically invalid, because the schemes do not control the syntax
>> of a URI.
>>=20
>> But a scheme can certainly say that fragments make no semantic sense
>> within that scheme, and that if a URIs uses that scheme and contains =
a
>> fragment, it is not a well formed URI within that scheme.
>=20
> No, they can't, or at least they cannot say that truthfully.
>=20
>> It's rather like saying that English words are composed of characters
>> from the set "abcdefghijklmnopqrstuvwxyz", and, therefore, the string
>> "qwx" is a valid piece of an English word (syntax)... but that, in
>> fact, no valid English words contain "qwx" (semantics).
>=20
> Sorry, you've lost me.
>=20
> It is more like saying that, because host and port are adjacent to =
each other in
> the syntax, it is therefore possible for DNS to specify what ports are =
allowed.
>=20
>> That's not a layering violation at all -- it has to be up to the
>> scheme to say what the semantic meaning of a fragment is within that
>> scheme, or whether fragments have any meaning at all.
>=20
> It has nothing to do with the scheme. Nothing whatsoever. It is true =
that there
> are many resources, regardless of scheme, for which a fragment =
identifier wouldn't
> have much practical purpose other than as a name, but that's only =
because
> nobody has found a reason to resolve them yet. In most cases, this is =
because
> deployment of the scheme is so small that it isn't worth anyone's =
bother to create
> a gateway for information about its identified resources.

I agree with Barry.

The scheme transitively defines the semantic meaning of fragments =
because the scheme defines the kinds of resources (if any) that are =
identified by it. Those resources may or may not have Internet media =
types, and those resources may or may not assign semantic meanings to =
fragments.

mailto: defines a URI scheme that does not identify representations of =
anything; it is used to launch a compose window to create new mail. =
(Arguably a mailto: URI identifies a mailbox.) Therefore fragment =
identifiers have no semantic meaning in mailto: because mailto: doesn=92t =
use them.

[RFC6068] says:
   Note that this specification, like any URI scheme specification, does
   not define syntax or meaning of a fragment identifier (see [STD66]),
   because these depend on the type of a retrieved representation.  In
   the currently known usage scenarios, a 'mailto' URI cannot be used to
   retrieve such representations.  Therefore, fragment identifiers are
   meaningless, SHOULD NOT be used on 'mailto' URIs, and SHOULD be
   ignored upon resolution.  The character "#" in s MUST be
   escaped as %23.


This text is entirely consistent with Barry=92s point. The scheme may =
not define the semantics of the fragment directly, but it defines the =
resources (representations), which in turn define the fragments.

Sean

PS I could be wrong but [RFC3966] looks like it permits the # character =
in the tel: URI in the path part. Is there a legacy reason for that, or =
just an oversight?=

--Apple-Mail=_0B93A74B-117D-4AD6-A59E-5727ED0FB600
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ9jCCBK8w
ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF
MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l
dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw
WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl
c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV
BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls
IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW
51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD
FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI
kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az
aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA
P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD
VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG
AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw
RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu
YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl
cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm
am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7
BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl
nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK
2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7
mzCCBT8wggQnoAMCAQICEBpCSs8n+cQbczyWKtueyecwDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV
BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY
BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg
QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTAyMDIwMDAwMDBaFw0xNjAy
MDIyMzU5NTlaMCUxIzAhBgkqhkiG9w0BCQEWFGRlditpZXRmQHNlYW50ZWsuY29tMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAz4n20qAOzUtC1oNz5zgTny0JRBE1mJZszV2s6EurahKP
vku7E+utnLhcaNahAWr2oZgeCK9uhEqijaC4qLZHnGt/+lnbsQtjmMJrcFCzhDZjDOJdYzmuS2cU
vZqY7YwzCG6jSfs4gwNh+29MS6faY6ucncbnfO9rBB0xu5GIdI3BzsPNYnACNlBYU7w4X4GA0/Mw
NAabNhDgxU2Tw1fl5w1Vt+6xRTXBk6V93LyVZN9wBIOpr2MuhoCJLHZrLirv/mbQE5ao4pkJLR/s
yYhS1Ko4MSiJmR3ugKPkxEo6DZkuJrfck36hLmtMo3yuzi7hkXmDzPKkdLlNj+Xek1GWtwIDAQAB
o4IB8jCCAe4wHwYDVR0jBBgwFoAUkmFrguGioKpP7GfxwqP3tIAAwewwHQYDVR0OBBYEFBpm5d7y
8PBT6NqnIVbfNK8hbpPGMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcG
CCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7Bgwr
BgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMw
XQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp
ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBkAYIKwYBBQUHAQEEgYMwgYAw
WAYIKwYBBQUHMAKGTGh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNsaWVudEF1
dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw
LmNvbW9kb2NhLmNvbTAfBgNVHREEGDAWgRRkZXYraWV0ZkBzZWFudGVrLmNvbTANBgkqhkiG9w0B
AQsFAAOCAQEAeIf/Nevvv10ssk0unrJb9FC8lJi41sSpq5AFYtmC8IXwUmNxL7L5uE3tGlNJVoTK
ZvGeklYWDRCzq6zqte221TowXYmFO7G27rJZbQRjLzQoY63rMlFPFrjqQCEA6rDgo9DlFO9/81P7
ZC7xvZ52WH7e3p/yJNA4Av8E0eeavhC+l+cwtrw0wCp3gUs5xJT0koGVvli2wR18zecG3ib3ml+G
nDDv2AH7OhcyhVoj6V9AeGQa2HqaVpOQVRUNPamqr3xeARKk5sUSeBvxlF+0FWhl+AnhqNdxmeEp
qpgSvbcS1jbTsqApvgsBcDzjC09wV8mtBoMCtqlHvF3YY2z55jGCA8MwggO/AgEBMIGwMIGbMQsw
CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk
MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xp
ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBpCSs8n+cQbczyWKtueyecw
CQYFKw4DAhoFAKCCAecwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN
MTUwNDE2MDQ1NTQxWjAjBgkqhkiG9w0BCQQxFgQUerwZvFRXkqz4VLDrnj788iOlV6EwgcEGCSsG
AQQBgjcQBDGBszCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl
cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMT
OENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB
AhAaQkrPJ/nEG3M8lirbnsnnMIHDBgsqhkiG9w0BCRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0Ix
GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMR
Q09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50
aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAaQkrPJ/nEG3M8lirbnsnnMA0GCSqGSIb3DQEB
AQUABIIBAAu1EVRea0W/J0BvJbF8+XvJcHwBIii4AGd8e1dz4x+5yNITB0Qb2nbNCmL+4QbCTaej
f0su6+c3BuwZTVW2LATRLLkZfp+qkP4T+8b+43WphLob1M5iIOK3fBcdr72w/wj2GxmGcKKoMD6w
tM66k/gBsfFRiqniYuEXJWODK8XBu04f1kQLq397800yhfMjO5v3cyr9ZDPRLw34ss3A+Ddkkvzc
2gXJFz9bqADcChsptVqFk0MYXlNXKC9JuFCh01FAiqmMTel2faN+UhrpDZZ0IYsxMnjWuj9r1dXI
V5P4l3kf9nRSnq1fYbu+LCQ3PptkD7j0Y9YJgdIWpEz7VgwAAAAAAAA=

--Apple-Mail=_0B93A74B-117D-4AD6-A59E-5727ED0FB600--


From nobody Wed Apr 15 22:34:54 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B115D1A011B; Wed, 15 Apr 2015 22:34:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZfkLuh7c6Yx; Wed, 15 Apr 2015 22:34:49 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B72481A0222; Wed, 15 Apr 2015 22:34:47 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.0.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150416053447.7613.75348.idtracker@ietfa.amsl.com>
Date: Wed, 15 Apr 2015 22:34:47 -0700
Archived-At: 
Cc: apps-discuss@ietf.org
Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-text-markdown-07.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Apr 2015 05:34:50 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Applications Area Working Group Working Group of the IETF.

        Title           : The text/markdown Media Type
        Author          : Sean Leonard
	Filename        : draft-ietf-appsawg-text-markdown-07.txt
	Pages           : 15
	Date            : 2015-04-15

Abstract:
   This document registers the text/markdown media type for use with
   Markdown, a family of plain text formatting syntaxes that optionally
   can be converted to formal markup languages such as HTML.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-appsawg-text-markdown/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-appsawg-text-markdown-07

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-text-markdown-07


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Thu Apr 16 07:51:41 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7341A1B327D for ; Thu, 16 Apr 2015 07:51:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xHhzWgs0HG-H for ; Thu, 16 Apr 2015 07:51:38 -0700 (PDT)
Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0793.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::793]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEDCD1B31A7 for ; Thu, 16 Apr 2015 07:51:29 -0700 (PDT)
Received: from pc6 (81.151.162.168) by DBXPR07MB063.eurprd07.prod.outlook.com (10.242.147.22) with Microsoft SMTP Server (TLS) id 15.1.125.19; Thu, 16 Apr 2015 14:51:12 +0000
Message-ID: <00f901d07854$99087a40$4001a8c0@gateway.2wire.net>
From: t.petch 
To: Scott Kitterman , IETF Apps Discuss 
References: <5518019A.7080508@isode.com> <2383989.tErOfD7dMh@kitterma-e6430>  
Date: Thu, 16 Apr 2015 15:40:55 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [81.151.162.168]
X-ClientProxiedBy: HE1PR02CA0041.eurprd02.prod.outlook.com (25.162.33.51) To DBXPR07MB063.eurprd07.prod.outlook.com (10.242.147.22)
Authentication-Results: kitterman.com; dkim=none (message not signed) header.d=none;
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB063;
X-Forefront-Antispam-Report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(24454002)(51704005)(13464003)(377454003)(77096005)(15975445007)(87976001)(62236002)(47776003)(1720100001)(77156002)(62966003)(4001410100001)(66066001)(86362001)(46102003)(33646002)(93886004)(116806002)(23756003)(61296003)(92566002)(42186005)(81686999)(81816999)(122386002)(50466002)(19580405001)(1456003)(19580395003)(40100003)(230783001)(44736004)(50226001)(84392001)(76176999)(50986999)(44716002)(107886001); DIR:OUT; SFP:1102; SCL:1; SRVR:DBXPR07MB063; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; 
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:DBXPR07MB063; BCL:0; PCL:0; RULEID:; SRVR:DBXPR07MB063; 
X-Forefront-PRVS: 0548586081
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Apr 2015 14:51:12.1257 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR07MB063
Archived-At: 
Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-rfc7001bis-05
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 16 Apr 2015 14:51:40 -0000

A new consideration:-(

http://www.iana.org/assignments/smtp-enhanced-status-codes/smtp-enhanced
-status-codes.xhtml#smtp-enhanced-status-codes-3

X.7.25 has a reference of [Section 3 of RFC7001]   (although I am not
clear why).

Perhaps that will need updating.

Tom Petch


----- Original Message -----
From: "Scott Kitterman" 
To: "IETF Apps Discuss" 
Sent: Wednesday, April 08, 2015 10:32 PM
Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-rfc7001bis-05


>
>
> On April 8, 2015 1:07:04 PM EDT, "Murray S. Kucherawy"
 wrote:
> >On Wed, Apr 8, 2015 at 7:29 AM, Scott Kitterman 
> >wrote:
> >
> >> Instead of getting into a bike shed discussion about what's common
> >and how
> >> can
> >> we tell, what about something like this:
> >>
> >>   At the time of publication of this document, the following are
> >>   published, authentication methods:
> >>
> >>   o  Author Domain Signing Practices ([ADSP]) (Historic)
> >>   o  Domain-based Message Authentication,  Reporting and
Conformance
> >> ([DMARC])
> >>   o  DomainKeys ([DOMAINKEYS]) (Historic)
> >>   o  DomainKeys Identified Mail Signatures ([DKIM])
> >>   o  reverse IP address name validation ("iprev", defined in
Section
> >3)
> >>   o  Require-Recipient-Valid-Since Header Field and SMTP Service
> >Extension
> >>        ([RRVS])
> >>   o  SMTP Service Extension for Authentication ([AUTH])
> >>   o  Sender ID ([SENDERID]) (Experimental)
> >>   o  Sender Policy Framework ([SPF])
> >>   o  S/MIME Signature Verification [SMIME-REG]
> >>   o  Vouch By Reference ([VBR])
> >>
> >> None of these are marked deprecated in the registry:
> >>
> >> http://www.iana.org/assignments/email-auth/email-auth.xhtml
> >>
> >> As a result, I don't think we should treat them differently in the
> >text
> >> beyond
> >> noting the status of the relevant RFC.
> >>
> >
> >Seems reasonable to me.  I'll do that in the next version, which I
> >won't
> >submit until WGLC closes.
> >
> >Tom is correct that the IANA Considerations section does update the
> >registries appropriately.
>
> Great. Given that, it might also warrant a sentence along the lines of
"Methods marked as historic are deprecated in this update".
>
> Scott K
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss


From nobody Thu Apr 16 09:03:56 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 092711ACDD5 for ; Thu, 16 Apr 2015 09:03:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level: 
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mwi6Ru9_jcSJ for ; Thu, 16 Apr 2015 09:03:54 -0700 (PDT)
Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7BDF1ACDAB for ; Thu, 16 Apr 2015 09:03:48 -0700 (PDT)
Received: by wgso17 with SMTP id o17so86163340wgs.1 for ; Thu, 16 Apr 2015 09:03:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LbZdUCG3YLJTGWif5cwbw8HRxdgNvfELg81Y1eSQt0o=; b=xknS9ZODXws+50grVJWMTRNGEFAFLr3dBQfxFYK5F53ktQiQw9f0mOuxjvNESx48as ef06BzKIF2qi0EL5jrlIMYDlsT+NT9R8AGbkgD+rPVR7rokH4UeL9nvyr44ZMhvW8KK0 T+1j9TjIZ8qu/2REpa58Vqy5IISY2cgq/UmFD831rQphQto3jeGVy+AbWLPJ0gKy5Fen il63L/Py+ZNOl/pDyfQoXM0VNX2EBfDia/yiF6v6LUGkpszfF69x+bb3FRNpSxJycOED 3335wROQc8l6t9CUUqD1ym5p+KeSFRck7voPU72e1N+Tf6hf2xxcQROEGnfVdSgwQapa k7iw==
MIME-Version: 1.0
X-Received: by 10.194.185.68 with SMTP id fa4mr60222145wjc.111.1429200227536;  Thu, 16 Apr 2015 09:03:47 -0700 (PDT)
Received: by 10.27.92.17 with HTTP; Thu, 16 Apr 2015 09:03:47 -0700 (PDT)
In-Reply-To: <00f901d07854$99087a40$4001a8c0@gateway.2wire.net>
References: <5518019A.7080508@isode.com> <2383989.tErOfD7dMh@kitterma-e6430>   <00f901d07854$99087a40$4001a8c0@gateway.2wire.net>
Date: Thu, 16 Apr 2015 09:03:47 -0700
Message-ID: 
From: "Murray S. Kucherawy" 
To: "t.petch" 
Content-Type: multipart/alternative; boundary=047d7bacb11ee0157f0513d99b5c
Archived-At: 
Cc: Scott Kitterman , IETF Apps Discuss 
Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-rfc7001bis-05
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 16 Apr 2015 16:03:55 -0000

--047d7bacb11ee0157f0513d99b5c
Content-Type: text/plain; charset=UTF-8

On Thu, Apr 16, 2015 at 7:40 AM, t.petch  wrote:

> A new consideration:-(
>
> http://www.iana.org/assignments/smtp-enhanced-status-codes/smtp-enhanced
> -status-codes.xhtml#smtp-enhanced-status-codes-3
>
> X.7.25 has a reference of [Section 3 of RFC7001]   (although I am not
> clear why).
>

RFC7001 is, as far as I'm aware, the only place where the common reverse IP
check done by MTAs is defined, hence the reference.

Good catch; -06 will take care of this.

-MSK

--047d7bacb11ee0157f0513d99b5c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On Thu, Apr 16, 2015 at 7:40 AM, t.petch <ietfc@btconne=
ct.com> wrote:
A new consideration:-(



http://=
www.iana.org/assignments/smtp-enhanced-status-codes/smtp-enhanced

-status-codes.xhtml#smtp-enhanced-status-codes-3



X.7.25 has a reference of [Section 3 of RFC7001]=C2=A0 =C2=A0(although I am=
 not

clear why).

RFC7001 is, as far as I'=
;m aware, the only place where the common reverse IP check done by MTAs is =
defined, hence the reference.

Good catch; -06 will take c=
are of this.

-MSK


--047d7bacb11ee0157f0513d99b5c--


From nobody Thu Apr 16 09:04:12 2015
Return-Path: 
X-Original-To: expand-draft-ietf-appsawg-multipart-form-data.all@virtual.ietf.org
Delivered-To: apps-discuss@ietfa.amsl.com
Received: by ietfa.amsl.com (Postfix, from userid 65534) id D33D51A8A3C; Wed, 15 Apr 2015 13:25:25 -0700 (PDT)
X-Original-To: xfilter-draft-ietf-appsawg-multipart-form-data.all@ietfa.amsl.com
Delivered-To: xfilter-draft-ietf-appsawg-multipart-form-data.all@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AECEE1A8A3B for ; Wed, 15 Apr 2015 13:25:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.879
X-Spam-Level: 
X-Spam-Status: No, score=-0.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 97h_tkl-i9MG for ; Wed, 15 Apr 2015 13:25:24 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94AF11A8A13 for ; Wed, 15 Apr 2015 13:25:24 -0700 (PDT)
Received: from smtp01.icann.org ([192.0.33.81]:46467 helo=smtp1.lax.icann.org) by zinfandel.tools.ietf.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YiTsC-0007kb-0x for draft-ietf-appsawg-multipart-form-data.all@tools.ietf.org; Wed, 15 Apr 2015 13:25:24 -0700
Received: from request3.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp1.lax.icann.org (8.13.8/8.13.8) with ESMTP id t3FKPIWW011541 for ; Wed, 15 Apr 2015 20:25:18 GMT
Received: by request3.lax.icann.org (Postfix, from userid 48) id 0D034C20828; Wed, 15 Apr 2015 20:25:18 +0000 (UTC)
RT-Owner: amanda.baber
From: "Amanda Baber via RT" 
In-Reply-To: <20150413174501.15074.76858.idtracker@ietfa.amsl.com>
References:  <20150413174501.15074.76858.idtracker@ietfa.amsl.com>
Message-ID: 
X-RT-Loop-Prevention: IANA
X-RT-Ticket: IANA #818655
X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/)
X-RT-Originator: amanda.baber@icann.org
Content-Type: text/plain; charset="utf-8"
X-RT-Original-Encoding: utf-8
Precedence: bulk
Date: Wed, 15 Apr 2015 20:25:17 +0000
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-SA-Exim-Connect-IP: 192.0.33.81
X-SA-Exim-Rcpt-To: draft-ietf-appsawg-multipart-form-data.all@tools.ietf.org
X-SA-Exim-Mail-From: iana-shared@icann.org
X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000)
X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org)
Resent-To: draft-ietf-appsawg-multipart-form-data.all@ietf.org
Resent-Message-Id: <20150415202524.94AF11A8A13@ietfa.amsl.com>
Resent-Date: Wed, 15 Apr 2015 13:25:24 -0700 (PDT)
Resent-From: iana-shared@icann.org
Archived-At: 
Archived-At: 
X-Mailman-Approved-At: Thu, 16 Apr 2015 09:04:11 -0700
Cc: draft-ietf-appsawg-multipart-form-data.all@tools.ietf.org
Subject: [apps-discuss] [IANA #818655] Protocol Action: 'Returning Values from Forms: multipart/form-data' to Proposed Standard (draft-ietf-appsawg-multipart-form-data-11.txt)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: drafts-approval@iana.org
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Apr 2015 20:25:26 -0000

Dear Author:

ATTENTION: A RESPONSE TO THIS MESSAGE IS NEEDED 

We've completed the IANA Actions for the following RFC-to-be:

draft-ietf-appsawg-multipart-form-data-11

ACTION 1:

IANA has updated the reference for the following assignment in the Content Disposition Values registry:

form-data   process as form response   [RFC-ietf-appsawg-multipart-form-data-11]

Please see
http://www.iana.org/assignments/cont-disp


ACTION 2:

IANA has updated the reference for the following assignment in the Content Disposition Parameters registry:

name   original field name in form   [RFC-ietf-appsawg-multipart-form-data-11]

Please see
http://www.iana.org/assignments/cont-disp


ACTION 3:

IANA has updated the reference and template for the following media type:

multipart/form-data	[RFC-ietf-appsawg-multipart-form-data-11]

Please see
http://www.iana.org/assignments/media-types


Please let us know whether the above IANA Actions look OK. As soon as we receive your confirmation, we'll notify the RFC Editor that this document's IANA Actions are complete.

We'll update the reference when the RFC Editor notifies us that they've assigned a number.

Thanks,

Amanda Baber
IANA Request Specialist
ICANN


From nobody Thu Apr 16 10:58:21 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A5761B33F7; Thu, 16 Apr 2015 10:58:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.666
X-Spam-Level: 
X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z6goc3Cxtuxs; Thu, 16 Apr 2015 10:58:18 -0700 (PDT)
Received: from homiemail-a29.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 858451B2E72; Thu, 16 Apr 2015 10:58:18 -0700 (PDT)
Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id 3B12567406A; Thu, 16 Apr 2015 10:58:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=content-type :mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=gbiv.com; bh=x8IAOqkuzyYTTWG93QaqdRiCw4g=; b=Iv6Gvcj4aljUxei6DJhaC/Mu3Ljl 4jZ9Mr9CWgISBxqZefff0D+B0bVl7pqTloEhV9k+5AQiSQrB95ciNGPrJ3+3OLvG w+xnlNt9xzSXeIbgAxif6MvH7p4u72xOYPNtnpGZ3qN5COgJinOyPaLDhPcJTvem sJe/799rY0hcVfc=
Received: from [192.168.1.18] (ip68-228-83-124.oc.oc.cox.net [68.228.83.124]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPSA id 920CC6740C6; Thu, 16 Apr 2015 10:58:16 -0700 (PDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: "Roy T. Fielding" 
In-Reply-To: <46C605DB-0885-428F-90BD-C2988DA161DD@seantek.com>
Date: Thu, 16 Apr 2015 12:58:15 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <1F29A2BA-BC93-4BEC-A436-EFA97B951992@gbiv.com>
References: <2E49FA112B054FFAED69D8A1@JcK-HP8200.jck.com>  <723FBC93979E1019101319C5@JcK-HP8200.jck.com> <4EA0B2F8-5109-49EA-8BAF-0199D1640407@gbiv.com> <55274198.5030309@andyet.net>   <327268B5-3817-42F1-90B3-D44158B0AA5D@gbiv.com> <46C605DB-0885-428F-90BD-C2988DA161DD@seantek.com>
To: Sean Leonard 
X-Mailer: Apple Mail (2.2098)
Archived-At: 
Cc: Barry Leiba , "draft-ietf-appsawg-uri-scheme-reg.all@ietf.org" , IESG , Apps Discuss 
Subject: Re: [apps-discuss] Retroactive application of draft-ietf-appsawg-uri-scheme-reg - comprehensive review
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 16 Apr 2015 17:58:20 -0000

> On Apr 15, 2015, at 11:54 PM, Sean Leonard  =
wrote:
>=20
> On Apr 10, 2015, at 8:44 PM, Roy T. Fielding  =
wrote:
>=20
>>> On Apr 10, 2015, at 8:38 AM, Barry Leiba  =
wrote:
>>>=20
>>>> No scheme can prohibit fragments. They are not part of the scheme's =
syntax.
>>>=20
>>> We continue to have a confusion between syntax and semantics here.
>>>=20
>>> I absolutely agree that no scheme can say that fragments are
>>> syntactically invalid, because the schemes do not control the syntax
>>> of a URI.
>>>=20
>>> But a scheme can certainly say that fragments make no semantic sense
>>> within that scheme, and that if a URIs uses that scheme and contains =
a
>>> fragment, it is not a well formed URI within that scheme.
>>=20
>> No, they can't, or at least they cannot say that truthfully.
>>=20
>>> It's rather like saying that English words are composed of =
characters
>>> from the set "abcdefghijklmnopqrstuvwxyz", and, therefore, the =
string
>>> "qwx" is a valid piece of an English word (syntax)... but that, in
>>> fact, no valid English words contain "qwx" (semantics).
>>=20
>> Sorry, you've lost me.
>>=20
>> It is more like saying that, because host and port are adjacent to =
each other in
>> the syntax, it is therefore possible for DNS to specify what ports =
are allowed.
>>=20
>>> That's not a layering violation at all -- it has to be up to the
>>> scheme to say what the semantic meaning of a fragment is within that
>>> scheme, or whether fragments have any meaning at all.
>>=20
>> It has nothing to do with the scheme. Nothing whatsoever. It is true =
that there
>> are many resources, regardless of scheme, for which a fragment =
identifier wouldn't
>> have much practical purpose other than as a name, but that's only =
because
>> nobody has found a reason to resolve them yet. In most cases, this is =
because
>> deployment of the scheme is so small that it isn't worth anyone's =
bother to create
>> a gateway for information about its identified resources.
>=20
> I agree with Barry.
>=20
> The scheme transitively defines the semantic meaning of fragments =
because the scheme defines the kinds of resources (if any) that are =
identified by it. Those resources may or may not have Internet media =
types, and those resources may or may not assign semantic meanings to =
fragments.

You are confusing resources with representations.  Resources do not have =
media types,
though they might have representations that are consistently the same =
media type.
Resources don't even need to have representations.

Regardless, the scheme does not define the kinds of representations. It =
only defines the
rules for name allocation within a uniform syntax for that name.  What =
kinds of
representations are so named depends *entirely* on how the identifiers =
are used, not on
the scheme.  For example, a VIN (physical identifier assigned to a =
vehicle by its
manufacturer) is clearly intended to uniquely identify a car.  However, =
its primary
uses are to indirectly identify registration records, odometer readings, =
and insurance
policies.  If a urn namespace for vin is assigned and a urn:vin: is used =
in HTTP for a
GET of a representation, the response will not be a car.

> mailto: defines a URI scheme that does not identify representations of =
anything; it is used to launch a compose window to create new mail. =
(Arguably a mailto: URI identifies a mailbox.) Therefore fragment =
identifiers have no semantic meaning in mailto: because mailto: doesn=92t =
use them.

Actually, what it identifies is a pre-defined template for an email =
message.
Fragment identifiers are rarely used here because implementations are =
inconsistent,
not because there is anything unusual about the scheme.  Note that =
mailto is *also*
used for other things, like mailbox identifiers, in which the context of =
use clearly
does not support the use of fragments (just like they don't support =
subject or body
definitions within query).  That's fine.

> [RFC6068] says:
>   Note that this specification, like any URI scheme specification, =
does
>   not define syntax or meaning of a fragment identifier (see [STD66]),
>   because these depend on the type of a retrieved representation.  In
>   the currently known usage scenarios, a 'mailto' URI cannot be used =
to
>   retrieve such representations.  Therefore, fragment identifiers are
>   meaningless, SHOULD NOT be used on 'mailto' URIs, and SHOULD be
>   ignored upon resolution.  The character "#" in s MUST be
>   escaped as %23.

Obviously, that is a bug in that spec.  An errata should be attached to =
it.
For example,

   mailto:fielding@gbiv.com#cc

is a valid use of fragment for the mailto URI (it instructs the user =
agent to
place the input context on the cc field after presentation of the =
template).

> This text is entirely consistent with Barry=92s point. The scheme may =
not define the semantics of the fragment directly, but it defines the =
resources (representations), which in turn define the fragments.

The text violates the requirements of STD66, the standard upon which it =
is
supposed to be entirely dependent.  It is an obvious bug,

> Sean
>=20
> PS I could be wrong but [RFC3966] looks like it permits the # =
character in the tel: URI in the path part.

It does not.  Read the text around gen-delims in section 2.2.

....Roy


From nobody Thu Apr 16 10:58:28 2015
Return-Path: 
X-Original-To: expand-draft-ietf-appsawg-uri-scheme-reg.all@virtual.ietf.org
Delivered-To: apps-discuss@ietfa.amsl.com
Received: by ietfa.amsl.com (Postfix, from userid 65534) id 37EE81B33FA; Thu, 16 Apr 2015 10:58:20 -0700 (PDT)
X-Original-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com
Delivered-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A5761B33F7; Thu, 16 Apr 2015 10:58:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.666
X-Spam-Level: 
X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z6goc3Cxtuxs; Thu, 16 Apr 2015 10:58:18 -0700 (PDT)
Received: from homiemail-a29.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 858451B2E72; Thu, 16 Apr 2015 10:58:18 -0700 (PDT)
Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id 3B12567406A; Thu, 16 Apr 2015 10:58:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gbiv.com; h=content-type :mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=gbiv.com; bh=x8IAOqkuzyYTTWG93QaqdRiCw4g=; b=Iv6Gvcj4aljUxei6DJhaC/Mu3Ljl 4jZ9Mr9CWgISBxqZefff0D+B0bVl7pqTloEhV9k+5AQiSQrB95ciNGPrJ3+3OLvG w+xnlNt9xzSXeIbgAxif6MvH7p4u72xOYPNtnpGZ3qN5COgJinOyPaLDhPcJTvem sJe/799rY0hcVfc=
Received: from [192.168.1.18] (ip68-228-83-124.oc.oc.cox.net [68.228.83.124]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPSA id 920CC6740C6; Thu, 16 Apr 2015 10:58:16 -0700 (PDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: "Roy T. Fielding" 
In-Reply-To: <46C605DB-0885-428F-90BD-C2988DA161DD@seantek.com>
Date: Thu, 16 Apr 2015 12:58:15 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <1F29A2BA-BC93-4BEC-A436-EFA97B951992@gbiv.com>
References: <2E49FA112B054FFAED69D8A1@JcK-HP8200.jck.com>  <723FBC93979E1019101319C5@JcK-HP8200.jck.com> <4EA0B2F8-5109-49EA-8BAF-0199D1640407@gbiv.com> <55274198.5030309@andyet.net>   <327268B5-3817-42F1-90B3-D44158B0AA5D@gbiv.com> <46C605DB-0885-428F-90BD-C2988DA161DD@seantek.com>
To: Sean Leonard 
X-Mailer: Apple Mail (2.2098)
Archived-At: 
Cc: Barry Leiba , "draft-ietf-appsawg-uri-scheme-reg.all@ietf.org" , IESG , Apps Discuss 
Subject: Re: [apps-discuss] Retroactive application of draft-ietf-appsawg-uri-scheme-reg - comprehensive review
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 16 Apr 2015 17:58:20 -0000

> On Apr 15, 2015, at 11:54 PM, Sean Leonard  =
wrote:
>=20
> On Apr 10, 2015, at 8:44 PM, Roy T. Fielding  =
wrote:
>=20
>>> On Apr 10, 2015, at 8:38 AM, Barry Leiba  =
wrote:
>>>=20
>>>> No scheme can prohibit fragments. They are not part of the scheme's =
syntax.
>>>=20
>>> We continue to have a confusion between syntax and semantics here.
>>>=20
>>> I absolutely agree that no scheme can say that fragments are
>>> syntactically invalid, because the schemes do not control the syntax
>>> of a URI.
>>>=20
>>> But a scheme can certainly say that fragments make no semantic sense
>>> within that scheme, and that if a URIs uses that scheme and contains =
a
>>> fragment, it is not a well formed URI within that scheme.
>>=20
>> No, they can't, or at least they cannot say that truthfully.
>>=20
>>> It's rather like saying that English words are composed of =
characters
>>> from the set "abcdefghijklmnopqrstuvwxyz", and, therefore, the =
string
>>> "qwx" is a valid piece of an English word (syntax)... but that, in
>>> fact, no valid English words contain "qwx" (semantics).
>>=20
>> Sorry, you've lost me.
>>=20
>> It is more like saying that, because host and port are adjacent to =
each other in
>> the syntax, it is therefore possible for DNS to specify what ports =
are allowed.
>>=20
>>> That's not a layering violation at all -- it has to be up to the
>>> scheme to say what the semantic meaning of a fragment is within that
>>> scheme, or whether fragments have any meaning at all.
>>=20
>> It has nothing to do with the scheme. Nothing whatsoever. It is true =
that there
>> are many resources, regardless of scheme, for which a fragment =
identifier wouldn't
>> have much practical purpose other than as a name, but that's only =
because
>> nobody has found a reason to resolve them yet. In most cases, this is =
because
>> deployment of the scheme is so small that it isn't worth anyone's =
bother to create
>> a gateway for information about its identified resources.
>=20
> I agree with Barry.
>=20
> The scheme transitively defines the semantic meaning of fragments =
because the scheme defines the kinds of resources (if any) that are =
identified by it. Those resources may or may not have Internet media =
types, and those resources may or may not assign semantic meanings to =
fragments.

You are confusing resources with representations.  Resources do not have =
media types,
though they might have representations that are consistently the same =
media type.
Resources don't even need to have representations.

Regardless, the scheme does not define the kinds of representations. It =
only defines the
rules for name allocation within a uniform syntax for that name.  What =
kinds of
representations are so named depends *entirely* on how the identifiers =
are used, not on
the scheme.  For example, a VIN (physical identifier assigned to a =
vehicle by its
manufacturer) is clearly intended to uniquely identify a car.  However, =
its primary
uses are to indirectly identify registration records, odometer readings, =
and insurance
policies.  If a urn namespace for vin is assigned and a urn:vin: is used =
in HTTP for a
GET of a representation, the response will not be a car.

> mailto: defines a URI scheme that does not identify representations of =
anything; it is used to launch a compose window to create new mail. =
(Arguably a mailto: URI identifies a mailbox.) Therefore fragment =
identifiers have no semantic meaning in mailto: because mailto: doesn=92t =
use them.

Actually, what it identifies is a pre-defined template for an email =
message.
Fragment identifiers are rarely used here because implementations are =
inconsistent,
not because there is anything unusual about the scheme.  Note that =
mailto is *also*
used for other things, like mailbox identifiers, in which the context of =
use clearly
does not support the use of fragments (just like they don't support =
subject or body
definitions within query).  That's fine.

> [RFC6068] says:
>   Note that this specification, like any URI scheme specification, =
does
>   not define syntax or meaning of a fragment identifier (see [STD66]),
>   because these depend on the type of a retrieved representation.  In
>   the currently known usage scenarios, a 'mailto' URI cannot be used =
to
>   retrieve such representations.  Therefore, fragment identifiers are
>   meaningless, SHOULD NOT be used on 'mailto' URIs, and SHOULD be
>   ignored upon resolution.  The character "#" in s MUST be
>   escaped as %23.

Obviously, that is a bug in that spec.  An errata should be attached to =
it.
For example,

   mailto:fielding@gbiv.com#cc

is a valid use of fragment for the mailto URI (it instructs the user =
agent to
place the input context on the cc field after presentation of the =
template).

> This text is entirely consistent with Barry=92s point. The scheme may =
not define the semantics of the fragment directly, but it defines the =
resources (representations), which in turn define the fragments.

The text violates the requirements of STD66, the standard upon which it =
is
supposed to be entirely dependent.  It is an obvious bug,

> Sean
>=20
> PS I could be wrong but [RFC3966] looks like it permits the # =
character in the tel: URI in the path part.

It does not.  Read the text around gen-delims in section 2.2.

....Roy


From nobody Thu Apr 16 11:06:15 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64BD61B2ECB; Thu, 16 Apr 2015 11:06:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oH6RnagsjYab; Thu, 16 Apr 2015 11:06:11 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 605181A023E; Thu, 16 Apr 2015 11:06:11 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
To: , ,  ,  , 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.0.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150416180611.23655.99079.idtracker@ietfa.amsl.com>
Date: Thu, 16 Apr 2015 11:06:11 -0700
From: IETF Secretariat 
Archived-At: 
Subject: [apps-discuss] ID Tracker State Update Notice: 
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Apr 2015 18:06:12 -0000

IANA action state changed to Waiting on RFC Editor
ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-multipart-form-data/


From nobody Thu Apr 16 11:25:04 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F9D41B3431; Thu, 16 Apr 2015 11:25:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id teo31vRW6ang; Thu, 16 Apr 2015 11:25:02 -0700 (PDT)
Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12DDB1B342E; Thu, 16 Apr 2015 11:25:02 -0700 (PDT)
Received: by iget9 with SMTP id t9so14150294ige.1; Thu, 16 Apr 2015 11:25:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=DVAK21pFWL8MW6I5Ezg9fOU0BaUTOTSZ7XJFZFUYK0s=; b=mZ1T3bG6nvo1HwWwbJGwTLQ9N6NQs3PaognH0OZDpOGloWwQhk+z0IThChVNmZoCqJ COFae8e5NlL7X2ahnCDx8ZDVQFPAwUd/TMhlVAgumg0qzZ19ohc8aqx5M5AW6eO675mg AjwMt7pMYe9OXs1iSnUpW0vnbidDNO30FeABoxvNRFaJrzuNwGGYUn5et+z0OWZ+dSpR tEWfSZ29laOl/gmDyu4/YERP5VVy5hGLekHAuhBtdL9MqKGaMgfBox7rYZkv7sfdHLE5 SEo1nTGO1Rl0rPat9u+LuQPkn1N0MvRvVxxl7f0drpKNYgPZFjSCRiGe1m76XGH3eAEf 0euQ==
MIME-Version: 1.0
X-Received: by 10.107.15.82 with SMTP id x79mr44740013ioi.75.1429208701544; Thu, 16 Apr 2015 11:25:01 -0700 (PDT)
Sender: barryleiba@gmail.com
Received: by 10.107.7.130 with HTTP; Thu, 16 Apr 2015 11:25:01 -0700 (PDT)
In-Reply-To: <723FBC93979E1019101319C5@JcK-HP8200.jck.com>
References: <2E49FA112B054FFAED69D8A1@JcK-HP8200.jck.com>  <723FBC93979E1019101319C5@JcK-HP8200.jck.com>
Date: Thu, 16 Apr 2015 14:25:01 -0400
X-Google-Sender-Auth: Um0b-DkbzkdLfq2B_1_z2NiduAs
Message-ID: 
From: Barry Leiba 
To: John C Klensin 
Content-Type: text/plain; charset=ISO-8859-1
Archived-At: 
Cc: "draft-ietf-appsawg-uri-scheme-reg.all@ietf.org" , IESG , Apps Discuss 
Subject: Re: [apps-discuss] Retroactive application of draft-ietf-appsawg-uri-scheme-reg - comprehensive review
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 16 Apr 2015 18:25:03 -0000

>> John (and others), please check the -06 version, looking
>> especially at the new last paragraph of Section 7.1.  I
>> believe that takes care of this case by codifying how Graham
>> already handles registration requests that come from IETF
>> working groups.
>
> That section, and the other changes from -05, represent huge
> improvements.  Thanks.

Great.

> More important, neither the changes nor your note address the
> particular issue that caused my review and concerns about
> draft-ietf-appsawg-uri-scheme-reg.  The issue was the claim that
> this document imposed additional constraints or requirements in
> addition to those of RFC 3986, requirements that could (or did)
> invalidate what the URNBIS WG is trying to do with
> draft-ietf-urnbis-semantics-clarif.
>
> I believe the key issue is that, as far as the _syntax_
> specified in RFC 3986 is concerned, there is a syntax component,
> given the name "fragment" in the defining production, that,
> informally, is delimited by the first appearance of "#" in a URI
> and that extends to the end of the URI.  Anything more --
> bindings to schemes, relationships to media types, even the
> binding of the term "fragment" to anything one might find in a
> dictionary-- are matters of semantics (or maybe something else)
> but not syntax.

I understand the concern here, and as I read the rest of the
conversation I see that we still have controversy about details such
as fragment vs syntax vs semantics, and such.

That said, I don't think that controversy affects this document.  I
think this document says what it needs to say about the registration
and update of URI schemes, and the roles of the DE and of working
group/community consensus.  I don't think there's a benefit to holding
up this document for the resolution of those other issues, which we'll
continue bashing around here and in the urnbis working group.

So I plan to push "GO" on this document imminently.  If you think this
absolutely *must* be resolved before this document is published,
please say why we can't defer it to discussion of 2141bis, an update
to 3986, or some other such.

We do need this uri scheme registration update -- which primarily
relaxes and clarifies existing rules -- and I don't want to make it
wait longer if we can handle the controversies elsewhere.

Barry


From nobody Thu Apr 16 11:25:09 2015
Return-Path: 
X-Original-To: expand-draft-ietf-appsawg-uri-scheme-reg.all@virtual.ietf.org
Delivered-To: apps-discuss@ietfa.amsl.com
Received: by ietfa.amsl.com (Postfix, from userid 65534) id 7D20D1B3432; Thu, 16 Apr 2015 11:25:03 -0700 (PDT)
X-Original-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com
Delivered-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F9D41B3431; Thu, 16 Apr 2015 11:25:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id teo31vRW6ang; Thu, 16 Apr 2015 11:25:02 -0700 (PDT)
Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12DDB1B342E; Thu, 16 Apr 2015 11:25:02 -0700 (PDT)
Received: by iget9 with SMTP id t9so14150294ige.1; Thu, 16 Apr 2015 11:25:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=DVAK21pFWL8MW6I5Ezg9fOU0BaUTOTSZ7XJFZFUYK0s=; b=mZ1T3bG6nvo1HwWwbJGwTLQ9N6NQs3PaognH0OZDpOGloWwQhk+z0IThChVNmZoCqJ COFae8e5NlL7X2ahnCDx8ZDVQFPAwUd/TMhlVAgumg0qzZ19ohc8aqx5M5AW6eO675mg AjwMt7pMYe9OXs1iSnUpW0vnbidDNO30FeABoxvNRFaJrzuNwGGYUn5et+z0OWZ+dSpR tEWfSZ29laOl/gmDyu4/YERP5VVy5hGLekHAuhBtdL9MqKGaMgfBox7rYZkv7sfdHLE5 SEo1nTGO1Rl0rPat9u+LuQPkn1N0MvRvVxxl7f0drpKNYgPZFjSCRiGe1m76XGH3eAEf 0euQ==
MIME-Version: 1.0
X-Received: by 10.107.15.82 with SMTP id x79mr44740013ioi.75.1429208701544; Thu, 16 Apr 2015 11:25:01 -0700 (PDT)
Sender: barryleiba@gmail.com
Received: by 10.107.7.130 with HTTP; Thu, 16 Apr 2015 11:25:01 -0700 (PDT)
In-Reply-To: <723FBC93979E1019101319C5@JcK-HP8200.jck.com>
References: <2E49FA112B054FFAED69D8A1@JcK-HP8200.jck.com>  <723FBC93979E1019101319C5@JcK-HP8200.jck.com>
Date: Thu, 16 Apr 2015 14:25:01 -0400
X-Google-Sender-Auth: Um0b-DkbzkdLfq2B_1_z2NiduAs
Message-ID: 
From: Barry Leiba 
To: John C Klensin 
Content-Type: text/plain; charset=ISO-8859-1
Archived-At: 
Cc: "draft-ietf-appsawg-uri-scheme-reg.all@ietf.org" , IESG , Apps Discuss 
Subject: Re: [apps-discuss] Retroactive application of draft-ietf-appsawg-uri-scheme-reg - comprehensive review
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 16 Apr 2015 18:25:03 -0000

>> John (and others), please check the -06 version, looking
>> especially at the new last paragraph of Section 7.1.  I
>> believe that takes care of this case by codifying how Graham
>> already handles registration requests that come from IETF
>> working groups.
>
> That section, and the other changes from -05, represent huge
> improvements.  Thanks.

Great.

> More important, neither the changes nor your note address the
> particular issue that caused my review and concerns about
> draft-ietf-appsawg-uri-scheme-reg.  The issue was the claim that
> this document imposed additional constraints or requirements in
> addition to those of RFC 3986, requirements that could (or did)
> invalidate what the URNBIS WG is trying to do with
> draft-ietf-urnbis-semantics-clarif.
>
> I believe the key issue is that, as far as the _syntax_
> specified in RFC 3986 is concerned, there is a syntax component,
> given the name "fragment" in the defining production, that,
> informally, is delimited by the first appearance of "#" in a URI
> and that extends to the end of the URI.  Anything more --
> bindings to schemes, relationships to media types, even the
> binding of the term "fragment" to anything one might find in a
> dictionary-- are matters of semantics (or maybe something else)
> but not syntax.

I understand the concern here, and as I read the rest of the
conversation I see that we still have controversy about details such
as fragment vs syntax vs semantics, and such.

That said, I don't think that controversy affects this document.  I
think this document says what it needs to say about the registration
and update of URI schemes, and the roles of the DE and of working
group/community consensus.  I don't think there's a benefit to holding
up this document for the resolution of those other issues, which we'll
continue bashing around here and in the urnbis working group.

So I plan to push "GO" on this document imminently.  If you think this
absolutely *must* be resolved before this document is published,
please say why we can't defer it to discussion of 2141bis, an update
to 3986, or some other such.

We do need this uri scheme registration update -- which primarily
relaxes and clarifies existing rules -- and I don't want to make it
wait longer if we can handle the controversies elsewhere.

Barry


From nobody Thu Apr 16 12:53:47 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE1E1B35A9; Thu, 16 Apr 2015 12:53:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.21
X-Spam-Level: 
X-Spam-Status: No, score=-1.21 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fk57Q9Z23gRY; Thu, 16 Apr 2015 12:53:44 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA6A91B35A3; Thu, 16 Apr 2015 12:53:40 -0700 (PDT)
Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Yipr0-000CbS-UW; Thu, 16 Apr 2015 15:53:38 -0400
Date: Thu, 16 Apr 2015 15:53:33 -0400
From: John C Klensin 
To: Barry Leiba 
Message-ID: 
In-Reply-To: 
References: <2E49FA112B054FFAED69D8A1@JcK-HP8200.jck.com>  <723FBC93979E1019101319C5@JcK-HP8200.jck.com> 
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.35
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: 
Cc: draft-ietf-appsawg-uri-scheme-reg.all@ietf.org, IESG , Apps Discuss 
Subject: Re: [apps-discuss] Retroactive application of draft-ietf-appsawg-uri-scheme-reg - comprehensive review
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 16 Apr 2015 19:53:46 -0000

--On Thursday, April 16, 2015 14:25 -0400 Barry Leiba
 wrote:

>> I believe the key issue is that, as far as the _syntax_
>> specified in RFC 3986 is concerned, there is a syntax
>> component, given the name "fragment" in the defining
>> production, that, informally, is delimited by the first
>> appearance of "#" in a URI and that extends to the end of the
>> URI.  Anything more -- bindings to schemes, relationships to
>> media types, even the binding of the term "fragment" to
>> anything one might find in a dictionary-- are matters of
>> semantics (or maybe something else) but not syntax.
> 
> I understand the concern here, and as I read the rest of the
> conversation I see that we still have controversy about
> details such as fragment vs syntax vs semantics, and such.
> 
> That said, I don't think that controversy affects this
> document.  I think this document says what it needs to say
> about the registration and update of URI schemes, and the
> roles of the DE and of working group/community consensus.  I
> don't think there's a benefit to holding up this document for
> the resolution of those other issues, which we'll continue
> bashing around here and in the urnbis working group.
> 
> So I plan to push "GO" on this document imminently.  If you
> think this absolutely *must* be resolved before this document
> is published, please say why we can't defer it to discussion
> of 2141bis, an update to 3986, or some other such.
> 
> We do need this uri scheme registration update -- which
> primarily relaxes and clarifies existing rules -- and I don't
> want to make it wait longer if we can handle the controversies
> elsewhere.

To repeat what I have tried to say before, I think there is one
important distinction to be made here.  To state it as narrowly
as I can, either this document imposes requirements on existing
schemes and revisions of them that 3986 does not or it doesn't.
If it does impose new requirements, then, according to
long-established IESG requirements, it must indicate that it
updates 3986 and explain the nature of the update/change(s).  In
addition and depending on what that text says, it is likely to
be inevitably bound to the controversies.   If it does not
impose new requirements, then I'm comfortable letting this
document go forward based on your assurances (and, implicitly,
that of the IESG) that future arguments that cite this document
in discussions of the controversies to which you refer will be
disregarded a without substance.

Put differently, either those controversies are rooted in the
requirements of, and "details such as fragment vs syntax vs
semantics" based on, 3986, or they are about some combination of
3986 and this document.  If the first, as you seem to believe
(and, btw, I agree), then the controversy does not affect this
document and it should go forward.   If the second, then this
document is inherently part of the controversy and it is
inappropriate for it to go forward at this time.

        john





From nobody Thu Apr 16 12:53:57 2015
Return-Path: 
X-Original-To: expand-draft-ietf-appsawg-uri-scheme-reg.all@virtual.ietf.org
Delivered-To: apps-discuss@ietfa.amsl.com
Received: by ietfa.amsl.com (Postfix, from userid 65534) id 62AE81B35AB; Thu, 16 Apr 2015 12:53:46 -0700 (PDT)
X-Original-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com
Delivered-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE1E1B35A9; Thu, 16 Apr 2015 12:53:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.21
X-Spam-Level: 
X-Spam-Status: No, score=-1.21 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fk57Q9Z23gRY; Thu, 16 Apr 2015 12:53:44 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA6A91B35A3; Thu, 16 Apr 2015 12:53:40 -0700 (PDT)
Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Yipr0-000CbS-UW; Thu, 16 Apr 2015 15:53:38 -0400
Date: Thu, 16 Apr 2015 15:53:33 -0400
From: John C Klensin 
To: Barry Leiba 
Message-ID: 
In-Reply-To: 
References: <2E49FA112B054FFAED69D8A1@JcK-HP8200.jck.com>  <723FBC93979E1019101319C5@JcK-HP8200.jck.com> 
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.35
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: 
Cc: draft-ietf-appsawg-uri-scheme-reg.all@ietf.org, IESG , Apps Discuss 
Subject: Re: [apps-discuss] Retroactive application of draft-ietf-appsawg-uri-scheme-reg - comprehensive review
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 16 Apr 2015 19:53:46 -0000

--On Thursday, April 16, 2015 14:25 -0400 Barry Leiba
 wrote:

>> I believe the key issue is that, as far as the _syntax_
>> specified in RFC 3986 is concerned, there is a syntax
>> component, given the name "fragment" in the defining
>> production, that, informally, is delimited by the first
>> appearance of "#" in a URI and that extends to the end of the
>> URI.  Anything more -- bindings to schemes, relationships to
>> media types, even the binding of the term "fragment" to
>> anything one might find in a dictionary-- are matters of
>> semantics (or maybe something else) but not syntax.
> 
> I understand the concern here, and as I read the rest of the
> conversation I see that we still have controversy about
> details such as fragment vs syntax vs semantics, and such.
> 
> That said, I don't think that controversy affects this
> document.  I think this document says what it needs to say
> about the registration and update of URI schemes, and the
> roles of the DE and of working group/community consensus.  I
> don't think there's a benefit to holding up this document for
> the resolution of those other issues, which we'll continue
> bashing around here and in the urnbis working group.
> 
> So I plan to push "GO" on this document imminently.  If you
> think this absolutely *must* be resolved before this document
> is published, please say why we can't defer it to discussion
> of 2141bis, an update to 3986, or some other such.
> 
> We do need this uri scheme registration update -- which
> primarily relaxes and clarifies existing rules -- and I don't
> want to make it wait longer if we can handle the controversies
> elsewhere.

To repeat what I have tried to say before, I think there is one
important distinction to be made here.  To state it as narrowly
as I can, either this document imposes requirements on existing
schemes and revisions of them that 3986 does not or it doesn't.
If it does impose new requirements, then, according to
long-established IESG requirements, it must indicate that it
updates 3986 and explain the nature of the update/change(s).  In
addition and depending on what that text says, it is likely to
be inevitably bound to the controversies.   If it does not
impose new requirements, then I'm comfortable letting this
document go forward based on your assurances (and, implicitly,
that of the IESG) that future arguments that cite this document
in discussions of the controversies to which you refer will be
disregarded a without substance.

Put differently, either those controversies are rooted in the
requirements of, and "details such as fragment vs syntax vs
semantics" based on, 3986, or they are about some combination of
3986 and this document.  If the first, as you seem to believe
(and, btw, I agree), then the controversy does not affect this
document and it should go forward.   If the second, then this
document is inherently part of the controversy and it is
inappropriate for it to go forward at this time.

        john





From nobody Thu Apr 16 13:04:30 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 499271B35D9; Thu, 16 Apr 2015 13:04:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NfyHAU_D6eze; Thu, 16 Apr 2015 13:04:20 -0700 (PDT)
Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C03A1B35EE; Thu, 16 Apr 2015 13:04:20 -0700 (PDT)
Received: by iebrs15 with SMTP id rs15so60305990ieb.3; Thu, 16 Apr 2015 13:04:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=6CHGaUT9ZeDf2bJNLHMNVDvTS9X+TYCNl+12rpEar8M=; b=CZHC35b3fnuieaRxfEi10rzioA8D9k2gesJSXCDBjjy4l2NB6ZseU3PODqDkIQy0f4 zNpJoK1MR4XAJnNbdq/8VJyCEwNDG+kid/rO/03WHDI5huHxddX5QZQoji9IfXnBlWPO +GkOd7RBpOf4fkIVIn4INl3FQ+Ri40UQD4sibNa05/LeE4qp3m76rnYFxH9ur78eskVQ DVoV7WfHSFGYPa3FcNPgocZzF37BJEBLFmT4xLfDt80Wg3YensJ4Kc4mX1sYfWIlt6v1 iTdYx2Rko/80nLssw6GCNTrJ+Gu2kl04452pkD971IEEtbczID355ngEjUgMiELZQ3XC MxYQ==
MIME-Version: 1.0
X-Received: by 10.107.29.21 with SMTP id d21mr46054868iod.11.1429214659807; Thu, 16 Apr 2015 13:04:19 -0700 (PDT)
Sender: barryleiba@gmail.com
Received: by 10.107.7.130 with HTTP; Thu, 16 Apr 2015 13:04:19 -0700 (PDT)
In-Reply-To: 
References: <2E49FA112B054FFAED69D8A1@JcK-HP8200.jck.com>  <723FBC93979E1019101319C5@JcK-HP8200.jck.com>  
Date: Thu, 16 Apr 2015 16:04:19 -0400
X-Google-Sender-Auth: Ubtdp05I7-3d3SJ9T_2fyqNJsUg
Message-ID: 
From: Barry Leiba 
To: John C Klensin 
Content-Type: text/plain; charset=ISO-8859-1
Archived-At: 
Cc: "draft-ietf-appsawg-uri-scheme-reg.all@ietf.org" , IESG , Apps Discuss 
Subject: Re: [apps-discuss] Retroactive application of draft-ietf-appsawg-uri-scheme-reg - comprehensive review
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 16 Apr 2015 20:04:21 -0000

> To repeat what I have tried to say before, I think there is one
> important distinction to be made here.  To state it as narrowly
> as I can, either this document imposes requirements on existing
> schemes and revisions of them that 3986 does not or it doesn't.
> If it does impose new requirements, then, according to
> long-established IESG requirements, it must indicate that it
> updates 3986 and explain the nature of the update/change(s).  In
> addition and depending on what that text says, it is likely to
> be inevitably bound to the controversies.   If it does not
> impose new requirements, then I'm comfortable letting this
> document go forward based on your assurances (and, implicitly,
> that of the IESG) that future arguments that cite this document
> in discussions of the controversies to which you refer will be
> disregarded a without substance.
>
> Put differently, either those controversies are rooted in the
> requirements of, and "details such as fragment vs syntax vs
> semantics" based on, 3986, or they are about some combination of
> 3986 and this document.  If the first, as you seem to believe
> (and, btw, I agree), then the controversy does not affect this
> document and it should go forward.   If the second, then this
> document is inherently part of the controversy and it is
> inappropriate for it to go forward at this time.

Thanks for succintifying things.

I think the answer is that this document does not update 3986, and
does not intend to impose new requirements.  I think the controversies
are purely about 3986, and not about what this document is doing.

I will wait for confirmation of that from a document author or two...
or refutation of it from anyone who thinks I'm wrong about where this
document sits.

Barry


From nobody Thu Apr 16 13:04:31 2015
Return-Path: 
X-Original-To: expand-draft-ietf-appsawg-uri-scheme-reg.all@virtual.ietf.org
Delivered-To: apps-discuss@ietfa.amsl.com
Received: by ietfa.amsl.com (Postfix, from userid 65534) id 7757A1B35F1; Thu, 16 Apr 2015 13:04:21 -0700 (PDT)
X-Original-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com
Delivered-To: xfilter-draft-ietf-appsawg-uri-scheme-reg.all@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 499271B35D9; Thu, 16 Apr 2015 13:04:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NfyHAU_D6eze; Thu, 16 Apr 2015 13:04:20 -0700 (PDT)
Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C03A1B35EE; Thu, 16 Apr 2015 13:04:20 -0700 (PDT)
Received: by iebrs15 with SMTP id rs15so60305990ieb.3; Thu, 16 Apr 2015 13:04:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=6CHGaUT9ZeDf2bJNLHMNVDvTS9X+TYCNl+12rpEar8M=; b=CZHC35b3fnuieaRxfEi10rzioA8D9k2gesJSXCDBjjy4l2NB6ZseU3PODqDkIQy0f4 zNpJoK1MR4XAJnNbdq/8VJyCEwNDG+kid/rO/03WHDI5huHxddX5QZQoji9IfXnBlWPO +GkOd7RBpOf4fkIVIn4INl3FQ+Ri40UQD4sibNa05/LeE4qp3m76rnYFxH9ur78eskVQ DVoV7WfHSFGYPa3FcNPgocZzF37BJEBLFmT4xLfDt80Wg3YensJ4Kc4mX1sYfWIlt6v1 iTdYx2Rko/80nLssw6GCNTrJ+Gu2kl04452pkD971IEEtbczID355ngEjUgMiELZQ3XC MxYQ==
MIME-Version: 1.0
X-Received: by 10.107.29.21 with SMTP id d21mr46054868iod.11.1429214659807; Thu, 16 Apr 2015 13:04:19 -0700 (PDT)
Sender: barryleiba@gmail.com
Received: by 10.107.7.130 with HTTP; Thu, 16 Apr 2015 13:04:19 -0700 (PDT)
In-Reply-To: 
References: <2E49FA112B054FFAED69D8A1@JcK-HP8200.jck.com>  <723FBC93979E1019101319C5@JcK-HP8200.jck.com>  
Date: Thu, 16 Apr 2015 16:04:19 -0400
X-Google-Sender-Auth: Ubtdp05I7-3d3SJ9T_2fyqNJsUg
Message-ID: 
From: Barry Leiba 
To: John C Klensin 
Content-Type: text/plain; charset=ISO-8859-1
Archived-At: 
Cc: "draft-ietf-appsawg-uri-scheme-reg.all@ietf.org" , IESG , Apps Discuss 
Subject: Re: [apps-discuss] Retroactive application of draft-ietf-appsawg-uri-scheme-reg - comprehensive review
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 16 Apr 2015 20:04:21 -0000

> To repeat what I have tried to say before, I think there is one
> important distinction to be made here.  To state it as narrowly
> as I can, either this document imposes requirements on existing
> schemes and revisions of them that 3986 does not or it doesn't.
> If it does impose new requirements, then, according to
> long-established IESG requirements, it must indicate that it
> updates 3986 and explain the nature of the update/change(s).  In
> addition and depending on what that text says, it is likely to
> be inevitably bound to the controversies.   If it does not
> impose new requirements, then I'm comfortable letting this
> document go forward based on your assurances (and, implicitly,
> that of the IESG) that future arguments that cite this document
> in discussions of the controversies to which you refer will be
> disregarded a without substance.
>
> Put differently, either those controversies are rooted in the
> requirements of, and "details such as fragment vs syntax vs
> semantics" based on, 3986, or they are about some combination of
> 3986 and this document.  If the first, as you seem to believe
> (and, btw, I agree), then the controversy does not affect this
> document and it should go forward.   If the second, then this
> document is inherently part of the controversy and it is
> inappropriate for it to go forward at this time.

Thanks for succintifying things.

I think the answer is that this document does not update 3986, and
does not intend to impose new requirements.  I think the controversies
are purely about 3986, and not about what this document is doing.

I will wait for confirmation of that from a document author or two...
or refutation of it from anyone who thinks I'm wrong about where this
document sits.

Barry


From nobody Thu Apr 16 13:39:17 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24AE41B36A3; Thu, 16 Apr 2015 13:39:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.902
X-Spam-Level: 
X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zhi4gLKzEa6u; Thu, 16 Apr 2015 13:39:13 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0130.outbound.protection.outlook.com [65.55.169.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45C171B36A4; Thu, 16 Apr 2015 13:39:12 -0700 (PDT)
Received: from BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) by BY2PR03MB410.namprd03.prod.outlook.com (10.141.141.16) with Microsoft SMTP Server (TLS) id 15.1.136.17; Thu, 16 Apr 2015 20:39:10 +0000
Received: from BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) by BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) with mapi id 15.01.0136.026; Thu, 16 Apr 2015 20:39:10 +0000
From: Dave Thaler 
To: Barry Leiba , John C Klensin 
Thread-Topic: Retroactive application of draft-ietf-appsawg-uri-scheme-reg - comprehensive review
Thread-Index: AQHQbLK+cqpU3jvXIEilgc+GV25Eep1DivsAgAFCK4CACz7BgIAAGL2AgAADAoCAAAmY4A==
Date: Thu, 16 Apr 2015 20:39:10 +0000
Message-ID: 
References: <2E49FA112B054FFAED69D8A1@JcK-HP8200.jck.com>  <723FBC93979E1019101319C5@JcK-HP8200.jck.com>   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: computer.org; dkim=none (message not signed) header.d=none;
x-originating-ip: [131.107.192.62]
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB410;
x-o365ent-eop-header: Message processed by -  O365_ENT: Allow from ranges (Engineering ONLY)
x-microsoft-antispam-prvs: 
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(51704005)(77096005)(46102003)(106116001)(76576001)(86362001)(86612001)(102836002)(2656002)(230783001)(93886004)(77156002)(87936001)(50986999)(54356999)(76176999)(2950100001)(92566002)(99286002)(40100003)(74316001)(62966003)(4001410100001)(2900100001)(33656002)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB410; H:BY2PR03MB412.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:BY2PR03MB410; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB410; 
x-forefront-prvs: 0548586081
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.onmicrosoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Apr 2015 20:39:10.4285 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB410
Archived-At: 
Cc: "draft-ietf-appsawg-uri-scheme-reg.all@ietf.org" , IESG , Apps Discuss 
Subject: Re: [apps-discuss] Retroactive application of draft-ietf-appsawg-uri-scheme-reg - comprehensive review
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 16 Apr 2015 20:39:15 -0000

Barry Leiba writes:
> I think the answer is that this document does not update 3986, and does n=
ot
> intend to impose new requirements.  I think the controversies are purely
> about 3986, and not about what this document is doing.
>=20
> I will wait for confirmation of that from a document author or two...
> or refutation of it from anyone who thinks I'm wrong about where this
> document sits.

I agree with Barry and above matches what I've previously stated on the lis=
t.

Dave


From nobody Thu Apr 16 13:47:06 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC0B61B36C1; Thu, 16 Apr 2015 13:47:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z7YoByzj_QGH; Thu, 16 Apr 2015 13:47:00 -0700 (PDT)
Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B4541B36A0; Thu, 16 Apr 2015 13:47:00 -0700 (PDT)
Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id 1cf10355.0.2244639.00-2137.6380397.nbfkord-smmo05.seg.att.com (envelope-from );  Thu, 16 Apr 2015 20:47:00 +0000 (UTC)
X-MXL-Hash: 55301fc434fd6020-2ba7d33ee94fb2d58a574229e20b86f4de64c7bb
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t3GKkvmF022123; Thu, 16 Apr 2015 16:46:57 -0400
Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t3GKkm3P021997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 16 Apr 2015 16:46:52 -0400
Received: from alpi153.aldc.att.com (alpi153.aldc.att.com [130.8.42.31]) by alpi131.aldc.att.com (RSA Interceptor); Thu, 16 Apr 2015 20:46:34 GMT
Received: from aldc.att.com (localhost [127.0.0.1]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id t3GKkYb8032577; Thu, 16 Apr 2015 16:46:34 -0400
Received: from mailgw1.maillennium.att.com (maillennium.att.com [135.25.114.99]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id t3GKkPaj032029; Thu, 16 Apr 2015 16:46:25 -0400
Received: from tonys-macbook-pro.local (unknown[135.110.240.247](untrusted sender)) by maillennium.att.com (mailgw1) with ESMTP id <20150416204624gw1000ce08e>; Thu, 16 Apr 2015 20:46:25 +0000
X-Originating-IP: [135.110.240.247]
Message-ID: <55301F9F.5080207@att.com>
Date: Thu, 16 Apr 2015 16:46:23 -0400
From: Tony Hansen 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Barry Leiba , John C Klensin 
References: <2E49FA112B054FFAED69D8A1@JcK-HP8200.jck.com>  <723FBC93979E1019101319C5@JcK-HP8200.jck.com>   
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-AnalysisOut: [v=2.0 cv=ZfOqwLpA c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a]
X-AnalysisOut: [=5hWoPXNsKEoA:10 a=-vuXD3bPMhwA:10 a=BLceEmwcHowA:10 a=N65]
X-AnalysisOut: [9UExz7-8A:10 a=zQP7CpKOAAAA:8 a=e9J7MTPGsLIA:10 a=eno8Rlkg]
X-AnalysisOut: [uwdJ0U3-oP8A:9 a=pILNOxqGKmIA:10]
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)]
X-MAIL-FROM: 
X-SOURCE-IP: [144.160.229.23]
Archived-At: 
Cc: "draft-ietf-appsawg-uri-scheme-reg.all@ietf.org" , IESG , Apps Discuss 
Subject: Re: [apps-discuss] Retroactive application of draft-ietf-appsawg-uri-scheme-reg - comprehensive review
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 16 Apr 2015 20:47:02 -0000

On 4/16/15 4:04 PM, Barry Leiba wrote:
>> Put differently, either those controversies are rooted in the
>> requirements of, and "details such as fragment vs syntax vs
>> semantics" based on, 3986, or they are about some combination of
>> 3986 and this document.  If the first, as you seem to believe
>> (and, btw, I agree), then the controversy does not affect this
>> document and it should go forward.   If the second, then this
>> document is inherently part of the controversy and it is
>> inappropriate for it to go forward at this time.
> Thanks for succintifying things.
>
> I think the answer is that this document does not update 3986, and
> does not intend to impose new requirements.  I think the controversies
> are purely about 3986, and not about what this document is doing.
>
> I will wait for confirmation of that from a document author or two...
> or refutation of it from anyone who thinks I'm wrong about where this
> document sits.

Just now, I've re-reviewed all references to 3986 within 
draft-ietf-appsawg-uri-scheme-reg-06 and don't see anywhere that it 
should be construed as >updating< 3986. There are lots of places where 
people are directed to looking at 3986 and 3987, and a thorough 
understanding of those is needed to fully appreciate some of the things 
being said in here. But if there's ANY doubt about us NOT updating them, 
is there a need to explicitly state that, say in the introduction?

     Tony Hansen


From nobody Thu Apr 16 13:56:16 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD93E1A1DBC for ; Thu, 16 Apr 2015 13:56:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-ArNkdoA6vX for ; Thu, 16 Apr 2015 13:56:13 -0700 (PDT)
Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E0161A1C03 for ; Thu, 16 Apr 2015 13:56:12 -0700 (PDT)
Received: by wiax7 with SMTP id x7so20303589wia.0 for ; Thu, 16 Apr 2015 13:56:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:date:message-id:subject:from:to:content-type; bh=fNjhP1uZpvOwY2cPdO7bJYylNN77fh/u75827ilxM+g=; b=oQfW/HVnxJKg26eMAnWnPkGcBDfzcPFXsBBb1SDz7vH3rGd5ibqr9bWmaxZOmNjf+F 3jrV4fO5G9Ac+z2ydbPAXgX6FK/3vxUqFUlWN6ra8AukzNKYeLBMh+Q2qydo/DOvJIy2 lLMh2aXzOFUIqdY55f6JlJmIt0moOycfE9bJMI0rmNW+e/wKpUV2mo+D20iIfd38XFYV yM+1TCyDi4P6p+yz5Lr2ddLCZpUjYAobUvjXxDrManVFamepoudlLU8IT18HJrbvdazI raxdMvt9S4mgubzRLfQdrtxI0qkmAdfVddVM+2j/GZKOwSjaDiImcj8n3PEl60JNL6A3 dVjg==
MIME-Version: 1.0
X-Received: by 10.194.185.9 with SMTP id ey9mr64845976wjc.135.1429217771319; Thu, 16 Apr 2015 13:56:11 -0700 (PDT)
Received: by 10.27.92.17 with HTTP; Thu, 16 Apr 2015 13:56:11 -0700 (PDT)
Date: Thu, 16 Apr 2015 13:56:11 -0700
Message-ID: 
From: "Murray S. Kucherawy" 
To: IETF Apps Discuss 
Content-Type: multipart/alternative; boundary=047d7bd6adce90f6cd0513ddb1e0
Archived-At: 
Subject: [apps-discuss] Seeking a shepherd for draft-ietf-appsawg-file-scheme
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 16 Apr 2015 20:56:14 -0000

--047d7bd6adce90f6cd0513ddb1e0
Content-Type: text/plain; charset=UTF-8

Colleagues,

We're looking for a volunteer to act as document shepherd for
draft-ietf-appsawg-file-scheme.  APPSAWG exercised chair discretion to
assign non-chair shepherds to many of its documents, in part as an avenue
to get relatively new participants familiar with an important part of a
document's lifecycle.

In essence, the shepherd's function is to make an independent review and
confirmation that proper process has been followed in the document's
evolution, that key things necessary in any document are present and
well-formed, that references are checked, and finally to summarize the
apparent consensus of the document.  It helps if you've been following the
development of the particular document, but it's also possible to summarize
all of that from the list archive and the document itself.

If you would be interested in acting as shepherd for this document, please
email appsawg-chairs@tools.ietf.org.  We would prefer to give a new person
a chance, but we'll ultimately consider anyone that volunteers.

-MSK, APPSAWG co-chair

--047d7bd6adce90f6cd0513ddb1e0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Colleagues,

We're looking for a volun=
teer to act as document shepherd for draft-ietf-appsawg-file-scheme.=C2=A0 =
APPSAWG exercised chair discretion to assign non-chair shepherds to many of=
 its documents, in part as an avenue to get relatively new participants fam=
iliar with an important part of a document's lifecycle.

In essence, the shepherd's function is to make an independent review=
 and confirmation that proper process has been followed in the document'=
;s evolution, that key things necessary in any document are present and wel=
l-formed, that references are checked, and finally to summarize the apparen=
t consensus of the document.=C2=A0 It helps if you've been following th=
e development of the particular document, but it's also possible to sum=
marize all of that from the list archive and the document itself.

If you would be interested in acting as shepherd for this document, ple=
ase email appsawg-chairs@t=
ools.ietf.org.=C2=A0 We would prefer to give a new person a chance, but=
 we'll ultimately consider anyone that volunteers.

-MSK, A=
PPSAWG co-chair



     =20
      


--047d7bd6adce90f6cd0513ddb1e0--


From nobody Thu Apr 16 15:35:46 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7A7A1B2FAD; Thu, 16 Apr 2015 15:35:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level: 
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g7iEwvJXfYP3; Thu, 16 Apr 2015 15:35:41 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2DCE1A1B81; Thu, 16 Apr 2015 15:35:40 -0700 (PDT)
Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YisNk-000DA4-C6; Thu, 16 Apr 2015 18:35:36 -0400
Date: Thu, 16 Apr 2015 18:35:30 -0400
From: John C Klensin 
To: Tony Hansen , Barry Leiba 
Message-ID: 
In-Reply-To: <55301F9F.5080207@att.com>
References: <2E49FA112B054FFAED69D8A1@JcK-HP8200.jck.com>  <723FBC93979E1019101319C5@JcK-HP8200.jck.com>    <55301F9F.5080207@att.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.35
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: 
Cc: draft-ietf-appsawg-uri-scheme-reg.all@ietf.org, IESG , Apps Discuss 
Subject: Re: [apps-discuss] Retroactive application of draft-ietf-appsawg-uri-scheme-reg - comprehensive review
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 16 Apr 2015 22:35:42 -0000

--On Thursday, April 16, 2015 16:46 -0400 Tony Hansen
 wrote:

> Just now, I've re-reviewed all references to 3986 within
> draft-ietf-appsawg-uri-scheme-reg-06 and don't see anywhere
> that it should be construed as >updating< 3986. There are lots
> of places where people are directed to looking at 3986 and
> 3987, and a thorough understanding of those is needed to fully
> appreciate some of the things being said in here. But if
> there's ANY doubt about us NOT updating them, is there a need
> to explicitly state that, say in the introduction?

In the spirit of moving on, I'd prefer to avoid requiring
another rev and will happily settle for the assurance that
everyone involved will provide support for my pushing back if
anyone stands up and says "you can't do  in URNs because
draft-ietf-appsawg-urn-scheme-reg clarified 3986 to prohibit it".

    john


From nobody Thu Apr 16 18:22:46 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC7FA1A8969; Thu, 16 Apr 2015 18:22:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SlE9xgCJHC3Y; Thu, 16 Apr 2015 18:22:39 -0700 (PDT)
Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C23FF1A895E; Thu, 16 Apr 2015 18:22:39 -0700 (PDT)
Received: by igblo3 with SMTP id lo3so3353746igb.1; Thu, 16 Apr 2015 18:22:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=gn26uy0DGFMArcWplNbXeL43Py9xgJsZPVwuIuIombU=; b=uG/pUNalP9DCtA4HRgb+9ZMv6jndrJCNXx8H0LHVJ3O7fBAbKLkyjdXT6fZ8oH5HDV yghgeAtonm51aKHoXVjNKdmfgKotF4qM40hODdOPlA2+mM7zJF/8yclQwUYQvTVqDtfr kEI86OFJjoFfluL2Y02pZ7gUL0hENix2Nxj0R24gQ45OaWu0qM77whQ0vWPWmYcKYwBY U1mFQ0DLXdiAmXUTakWUANmJzr0TenJTLamDK9R+wQGW/Ri+54NrjwScL6xbYNGDzPOW VPt/gYK5NjjCHN98SkHYDHdwk8/u9i948r69odr33IJdqHjTmi3fkzeyIV2Gd/QVOkuy shOQ==
MIME-Version: 1.0
X-Received: by 10.107.15.82 with SMTP id x79mr723162ioi.75.1429233759295; Thu, 16 Apr 2015 18:22:39 -0700 (PDT)
Sender: barryleiba@gmail.com
Received: by 10.107.7.130 with HTTP; Thu, 16 Apr 2015 18:22:39 -0700 (PDT)
In-Reply-To: 
References: <2E49FA112B054FFAED69D8A1@JcK-HP8200.jck.com>  <723FBC93979E1019101319C5@JcK-HP8200.jck.com>    <55301F9F.5080207@att.com> 
Date: Thu, 16 Apr 2015 21:22:39 -0400
X-Google-Sender-Auth: 0-VYiek7UeIjHGIQZ7ndaPw8cjo
Message-ID: 
From: Barry Leiba 
To: John C Klensin 
Content-Type: text/plain; charset=ISO-8859-1
Archived-At: 
Cc: "draft-ietf-appsawg-uri-scheme-reg.all@ietf.org" , IESG , Apps Discuss 
Subject: Re: [apps-discuss] Retroactive application of draft-ietf-appsawg-uri-scheme-reg - comprehensive review
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 17 Apr 2015 01:22:41 -0000

>> Just now, I've re-reviewed all references to 3986 within
>> draft-ietf-appsawg-uri-scheme-reg-06 and don't see anywhere
>> that it should be construed as >updating< 3986. There are lots
>> of places where people are directed to looking at 3986 and
>> 3987, and a thorough understanding of those is needed to fully
>> appreciate some of the things being said in here. But if
>> there's ANY doubt about us NOT updating them, is there a need
>> to explicitly state that, say in the introduction?
>
> In the spirit of moving on, I'd prefer to avoid requiring
> another rev and will happily settle for the assurance that
> everyone involved will provide support for my pushing back if
> anyone stands up and says "you can't do  in URNs because
> draft-ietf-appsawg-urn-scheme-reg clarified 3986 to prohibit it".

Thanks, John!  I'm off to ask the Secretariat to make the approval announcement.

Barry


From nobody Fri Apr 17 06:39:08 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10D8E1B2CAD for ; Fri, 17 Apr 2015 06:39:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.291
X-Spam-Level: 
X-Spam-Status: No, score=0.291 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, J_CHICKENPOX_15=0.6, SPF_HELO_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ez_ZddRSPZ3J for ; Fri, 17 Apr 2015 06:39:05 -0700 (PDT)
Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0791.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::791]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE76C1B2C85 for ; Fri, 17 Apr 2015 06:39:04 -0700 (PDT)
Received: from pc6 (81.151.162.168) by AMXPR07MB056.eurprd07.prod.outlook.com (10.242.67.151) with Microsoft SMTP Server (TLS) id 15.1.130.23; Fri, 17 Apr 2015 13:38:45 +0000
Message-ID: <01c301d07913$a4287a00$4001a8c0@gateway.2wire.net>
From: t.petch 
To: "Murray S. Kucherawy" 
References: <5518019A.7080508@isode.com>	<2383989.tErOfD7dMh@kitterma-e6430><00f901d07854$99087a40$4001a8c0@gateway.2wire.net> 
Date: Fri, 17 Apr 2015 09:13:02 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [81.151.162.168]
X-ClientProxiedBy: AM2PR08CA0018.eurprd08.prod.outlook.com (25.162.32.28) To AMXPR07MB056.eurprd07.prod.outlook.com (10.242.67.151)
Authentication-Results: gmail.com; dkim=none (message not signed) header.d=none;
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB056;
X-Microsoft-Antispam-PRVS: 
X-Forefront-Antispam-Report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(24454002)(43544003)(377454003)(51704005)(1720100001)(116806002)(46102003)(230783001)(62966003)(77156002)(50986999)(84392001)(77096005)(15975445007)(1456003)(92566002)(44716002)(93886004)(62236002)(33646002)(19580395003)(66066001)(47776003)(40100003)(50226001)(110136001)(42186005)(86362001)(44736004)(61296003)(1411001)(14496001)(19580405001)(5820100001)(76176999)(87976001)(81686999)(81816999)(122386002)(50466002)(23676002); DIR:OUT; SFP:1102; SCL:1; SRVR:AMXPR07MB056; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; 
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:AMXPR07MB056; BCL:0; PCL:0; RULEID:; SRVR:AMXPR07MB056; 
X-Forefront-PRVS: 0549E6FD50
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Apr 2015 13:38:45.2223 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMXPR07MB056
Archived-At: 
Cc: Scott Kitterman , IETF Apps Discuss 
Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-rfc7001bis-05
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 17 Apr 2015 13:39:07 -0000

----- Original Message -----
From: "Murray S. Kucherawy" 
To: "t.petch" 
Cc: "Scott Kitterman" ; "IETF Apps Discuss"

Sent: Thursday, April 16, 2015 5:03 PM
> On Thu, Apr 16, 2015 at 7:40 AM, t.petch  wrote:
>
> > A new consideration:-(
> >
> >
http://www.iana.org/assignments/smtp-enhanced-status-codes/smtp-enhanced
> > -status-codes.xhtml#smtp-enhanced-status-codes-3
> >
> > X.7.25 has a reference of [Section 3 of RFC7001]   (although I am
not
> > clear why).
> >
>
> RFC7001 is, as far as I'm aware, the only place where the common
reverse IP
> check done by MTAs is defined, hence the reference.
>
> Good catch; -06 will take care of this.

I have a sense of deja vu - all over again!

When I follow the references from X.7.25, RFC7372 says no more than that
which is already in the IANA entry while the reference to RFC7001 takes
me to a paragraph that I read, and re-read and think 'eh?'  A bit like
going straight from IANA to the domainkeys RFC for authentication
results, something you have now fixed in rfc7001bis.

Reading section 3 thereof, for iprev, there is nothing about X.7.25 - is
it really the right RFC?  well yes, RFC7372 says so, but I read the
'iprev' paragraph as something that might happen when an MUA EHLOs an
MSA, in which case I struggle to see how an Authentication-Results
header will ever get into an e-mail. Reverse DNS is fine, it is the way
it fits into e-mail that I struggle with.

So, like domainkeys, I think another sentence or two is needed in
section 3 to bridge the gap between what is in IANA and the text which
that takes you to for further explanation.

Tom Petch

>
> -MSK
>


From nobody Fri Apr 17 10:35:28 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F0811A8984 for ; Thu, 16 Apr 2015 13:16:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.101
X-Spam-Level: 
X-Spam-Status: No, score=0.101 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qw0jSamtJhtc for ; Thu, 16 Apr 2015 13:16:02 -0700 (PDT)
Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEA3D1A897F for ; Thu, 16 Apr 2015 13:16:02 -0700 (PDT)
Received: from Philemon (unknown [4.30.143.226]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id C73BC2C9F7; Thu, 16 Apr 2015 13:16:01 -0700 (PDT)
From: "Jim Schaad" 
To: 
Date: Thu, 16 Apr 2015 13:14:50 -0700
Message-ID: <00dc01d07881$fe5b3950$fb11abf0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00DD_01D07847.51FF6E90"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdB4cgW+CtSzLmafTpKHTFegEUIn6g==
Content-Language: en-us
Archived-At: 
X-Mailman-Approved-At: Fri, 17 Apr 2015 10:35:26 -0700
Cc: apps-discuss@ietf.org
Subject: [apps-discuss] Comments on draft-greevenbosch-appsawg-cbor-cddl-05
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 16 Apr 2015 20:16:06 -0000

This is a multipart message in MIME format.

------=_NextPart_000_00DD_01D07847.51FF6E90
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

I am finally getting around to transcribing the comments that I made on my
kindle so here they are:

 

Section 2.1 - "The parentheses for groups are optional" - This statement is
not always true.  There are a large number of cases where the grouping
parentheses are required.  Suggest "In this case the grouping parentheses
are optional"

 

Counter example is given in Figure 1.  Or maybe not after reading the ABNF.
It appears that the only place where the parens are mandatory for a group is
when following an '&' character.  However, parens are also used in rule
type2 where it can be confused with a group since it is using parens to
delimit things.

 

Section 2.1.2 - "The end of a group can be marked by a ')'" - I think that
this bullet should be combined with the previous bullet because you don't
want to be in the situation where people think that only one of these is
required.   Thus "Groups can be marked by wrapping them in '(' and ')'."

 

Section 2.2.2 - Choices:  In using the CDDL compiler with a syntax enforcer,
I have gotten very upset with the current gramper where you are using type1
and not type in the grpent rule.  The problem is that one comes up with a
very inconsistent view of the world where you get

 

Attire = a / b / c

 

Is legal but

 

Person = {

   name: tstr,

   attrire: a / b / c

}

 

Is not the same thing as using 'Attire' instead.  There is nothing that
tells a person why the first should be ok and the second not be ok.  I don't
know what other problems come into existence if this is changed however I
believe that a structure like

     (name:tstr) / ( bstr)

Is more understandable to a reader than

     name: tstr / bstr

The second to me says that both items are attached to 'name:' rather than
being what is stated in the first line.

 

Section 3.5.2 - In the example where you define 'x', you should highlight
for readers that 'int' is a defined type that includes a choice.  This is
not clear if you don't managed to remember it so that it does not seem on
first blush that this is really a multi-valued keytype.

 

Appendix E - I would like to be able to place groups into choices.  (See my
COSE draft for how I want to do this).

 

Open issues:  My expectation is that the following are going to do the same
thing:

 

[* groupname ]

[* (group elements)]

 

And I would have guessed that it works the opposite of how the tool is
described.  That is I would assume that the group would be multiplied and
not the individual elements of the group.  (Gets real confusing if there are
nested groups or the syntax changes later.)

 

Open Issue:  Should there be a convention - possibly a comment - to indicate
that there is a module from another specification that is to be appended to
this one.  I don't know that we want people to cut and paste this
specification into another specification just to get the same effect as the
Prelude.

 

Jim

 

 

 


------=_NextPart_000_00DD_01D07847.51FF6E90
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


I am =
finally getting around to transcribing the comments that I made on my =
kindle so here they are:
 
Section 2.1 =
– “The parentheses for groups are optional” – =
This statement is not always true.  There are a large number of =
cases where the grouping parentheses are required.  Suggest =
“In this case the grouping parentheses are =
optional”
 
Counter =
example is given in Figure 1.  Or maybe not after reading the ABNF. =
It appears that the only place where the parens are mandatory for a =
group is when following an ‘&’ character.  However, =
parens are also used in rule type2 where it can be confused with a group =
since it is using parens to delimit things.
 
Section =
2.1.2 – “The end of a group can be marked by a =
‘)’” – I think that this bullet should be =
combined with the previous bullet because you don’t want to be in =
the situation where people think that only one of these is =
required.   Thus “Groups can be marked by wrapping them =
in ‘(‘ and ‘)’.”
 
Section =
2.2.2 – Choices:  In using the CDDL compiler with a syntax =
enforcer, I have gotten very upset with the current gramper where you =
are using type1 and not type in the grpent rule.  The problem is =
that one comes up with a very inconsistent view of the world where you =
get
 
Attire =3D a / b / c
 
Is legal =
but
 
Person =3D {
   name: tstr,
   attrire: a / b / c
}
 
Is not the =
same thing as using ‘Attire’ instead.  There is nothing =
that tells a person why the first should be ok and the second not be =
ok.  I don’t know what other problems come into existence if =
this is changed however I believe that a structure like
     (name:tstr) / ( =
bstr)
Is more understandable to a =
reader than
     =
name: tstr / bstr
The second to me =
says that both items are attached to ‘name:’ rather than =
being what is stated in the first line.
 
Section =
3.5.2 – In the example where you define ‘x’, you =
should highlight for readers that ‘int’ is a defined type =
that includes a choice.  This is not clear if you don’t =
managed to remember it so that it does not seem on first blush that this =
is really a multi-valued keytype.
 
Appendix E =
– I would like to be able to place groups into choices.  (See =
my COSE draft for how I want to do this).
 
Open =
issues:  My expectation is that the following are going to do the =
same thing:
 
[* groupname ]
[* =
(group elements)]
 
And I would =
have guessed that it works the opposite of how the tool is =
described.  That is I would assume that the group would be =
multiplied and not the individual elements of the group.  (Gets =
real confusing if there are nested groups or the syntax changes =
later.)
 
Open Issue:  Should there be a convention – =
possibly a comment – to indicate that there is a module from =
another specification that is to be appended to this one.  I =
don’t know that we want people to cut and paste this specification =
into another specification just to get the same effect as the =
Prelude.
 
Jim
 
 
 

------=_NextPart_000_00DD_01D07847.51FF6E90--


From nobody Fri Apr 17 10:47:44 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD751AC3B3 for ; Fri, 17 Apr 2015 10:47:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level: 
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JfZutIrxcggK for ; Fri, 17 Apr 2015 10:47:41 -0700 (PDT)
Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC2CC1ABB1A for ; Fri, 17 Apr 2015 10:47:40 -0700 (PDT)
Received: by wgyo15 with SMTP id o15so120858318wgy.2 for ; Fri, 17 Apr 2015 10:47:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jMoFHrGSj0I9IB3v/H3BRUME3xEiC1TrP8jrWESVeKU=; b=cgSESi1IrkVcsJxmU1bJYalevoEVW4FCTpBpMAJUCiw0tApLkvDX5vzCum1yObDmnk SiwlBDuvoRzlg50MMP427XdZjWQRExxIKXR6iKYg7edqESKoby2xPX0zAlGEWjWdoQvM XHdv8pN9X+tuIUlCYiFCvtIVZuPMcVPqZfwJgI6ZnmPshBQ9yzSC6lfZaOYRQoTSE2kU tY8p97+e91FZkhvptLgncNaNvWzqFFbjWml+syrP0/M1P6kAFO03kZKjIgC767CSztTb wjzQrHZQaeJSUXJgCDayXZ+zEBsxJxizQGMjJ5jAa7zWNFalE4EMO7oin36aXZIogzIL KsYw==
MIME-Version: 1.0
X-Received: by 10.194.179.194 with SMTP id di2mr8095631wjc.4.1429292859587; Fri, 17 Apr 2015 10:47:39 -0700 (PDT)
Received: by 10.27.92.17 with HTTP; Fri, 17 Apr 2015 10:47:39 -0700 (PDT)
In-Reply-To: <01c301d07913$a4287a00$4001a8c0@gateway.2wire.net>
References: <5518019A.7080508@isode.com> <2383989.tErOfD7dMh@kitterma-e6430>   <00f901d07854$99087a40$4001a8c0@gateway.2wire.net>  <01c301d07913$a4287a00$4001a8c0@gateway.2wire.net>
Date: Fri, 17 Apr 2015 10:47:39 -0700
Message-ID: 
From: "Murray S. Kucherawy" 
To: "t.petch" 
Content-Type: multipart/alternative; boundary=089e01419d1c2d03240513ef2d6f
Archived-At: 
Cc: Scott Kitterman , IETF Apps Discuss 
Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-rfc7001bis-05
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 17 Apr 2015 17:47:42 -0000

--089e01419d1c2d03240513ef2d6f
Content-Type: text/plain; charset=UTF-8

On Fri, Apr 17, 2015 at 1:13 AM, t.petch  wrote:

> When I follow the references from X.7.25, RFC7372 says no more than that
> which is already in the IANA entry while the reference to RFC7001 takes
> me to a paragraph that I read, and re-read and think 'eh?'  A bit like
> going straight from IANA to the domainkeys RFC for authentication
> results, something you have now fixed in rfc7001bis.
>

X.7.25 is a code one might return if the "iprev" test fails and the MTA
chooses to reject the message rather than let it pass.  If rejecting,
RFC7001 doesn't apply (obviously) other than being the only place in the
RFC series that there's currently a definition of what the "iprev" check is
in the first place.

Reading section 3 thereof, for iprev, there is nothing about X.7.25 - is
> it really the right RFC?  well yes, RFC7372 says so, but I read the
> 'iprev' paragraph as something that might happen when an MUA EHLOs an
> MSA, in which case I struggle to see how an Authentication-Results
> header will ever get into an e-mail. Reverse DNS is fine, it is the way
> it fits into e-mail that I struggle with.
>

Does the above clarify?  If so, then I guess there are two things I could
do here:

1) Basically explain this in a subsection of the "iprev" definition, but
that seems an odd thing to do.

2) Put the definition of "iprev" into its own document, and then have
X.7.25 and this document point to that one.

-MSK

--089e01419d1c2d03240513ef2d6f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On Fri, Apr 17, 2015 at 1:13 AM, t.petch <ietfc@btconne=
ct.com> wrote:
When I follow the references from=
 X.7.25, RFC7372 says no more than that

which is already in the IANA entry while the reference to RFC7001 takes

me to a paragraph that I read, and re-read and think 'eh?'=C2=A0 A =
bit like

going straight from IANA to the domainkeys RFC for authentication

results, something you have now fixed in rfc7001bis.
<=
br>
X.7.25 is a code one might return if the "iprev" te=
st fails and the MTA chooses to reject the message rather than let it pass.=
=C2=A0 If rejecting, RFC7001 doesn't apply (obviously) other than being=
 the only place in the RFC series that there's currently a definition o=
f what the "iprev" check is in the first place.


Reading section 3 thereof, for iprev, there is nothing about X.7.25 - is
it really the right RFC?=C2=A0 well yes, RFC7372 says so, but I read the
'iprev' paragraph as something that might happen when an MUA EHLOs =
an

MSA, in which case I struggle to see how an Authentication-Results

header will ever get into an e-mail. Reverse DNS is fine, it is the way

it fits into e-mail that I struggle with.

Does the above clarify?=C2=A0 If so, then I guess there are two things I=
 could do here:

1) Basically explain this in a subsection=
 of the "iprev" definition, but that seems an odd thing to do.
2) Put the definition of "iprev" into its own doc=
ument, and then have X.7.25 and this document point to that one.

-MSK


--089e01419d1c2d03240513ef2d6f--


From nobody Sat Apr 18 00:25:29 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 881691A038D; Sat, 18 Apr 2015 00:25:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.657
X-Spam-Level: 
X-Spam-Status: No, score=-2.657 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GpqybQMwKl41; Sat, 18 Apr 2015 00:25:24 -0700 (PDT)
Received: from relay12.mail.ox.ac.uk (relay12.mail.ox.ac.uk [129.67.1.163]) by ietfa.amsl.com (Postfix) with ESMTP id 3E4021A0390; Sat, 18 Apr 2015 00:25:22 -0700 (PDT)
Received: from smtp6.mail.ox.ac.uk ([163.1.2.206]) by relay12.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1YjN7t-0005uJ-fL; Sat, 18 Apr 2015 08:25:17 +0100
Received: from 94.197.121.208.threembb.co.uk ([94.197.121.208] helo=[192.168.43.120]) by smtp6.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YjN7t-000095-LK; Sat, 18 Apr 2015 08:25:17 +0100
Message-ID: <55316A2B.5090900@ninebynine.org>
Date: Fri, 17 Apr 2015 21:16:43 +0100
From: Graham Klyne 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: John C Klensin , Tony Hansen ,  Barry Leiba 
References: <2E49FA112B054FFAED69D8A1@JcK-HP8200.jck.com>  <723FBC93979E1019101319C5@JcK-HP8200.jck.com>    <55301F9F.5080207@att.com> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Oxford-Username: zool0635
Archived-At: 
Cc: draft-ietf-appsawg-uri-scheme-reg.all@ietf.org, IESG , Apps Discuss 
Subject: Re: [apps-discuss] Retroactive application of draft-ietf-appsawg-uri-scheme-reg - comprehensive review
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 18 Apr 2015 07:25:25 -0000

On 16/04/2015 23:35, John C Klensin wrote:
>
>
> --On Thursday, April 16, 2015 16:46 -0400 Tony Hansen
>  wrote:
>
>> Just now, I've re-reviewed all references to 3986 within
>> draft-ietf-appsawg-uri-scheme-reg-06 and don't see anywhere
>> that it should be construed as >updating< 3986. There are lots
>> of places where people are directed to looking at 3986 and
>> 3987, and a thorough understanding of those is needed to fully
>> appreciate some of the things being said in here. But if
>> there's ANY doubt about us NOT updating them, is there a need
>> to explicitly state that, say in the introduction?
>
> In the spirit of moving on, I'd prefer to avoid requiring
> another rev and will happily settle for the assurance that
> everyone involved will provide support for my pushing back if
> anyone stands up and says "you can't do  in URNs because
> draft-ietf-appsawg-urn-scheme-reg clarified 3986 to prohibit it".

I assume you meant "draft-ietf-appsawg-uri-scheme-reg" above (not "*-urn-*"). 
I'd be pushing back on any aspect which appeared to change what is required by 
RFC3986.

(All of this leaves me wondering if it would be helpful to state that explicitly 
in the registration document, but at this stage in the process I'm reluctant to 
introduce suggestions for shadow-dodging changes.)

#g
--


From nobody Sat Apr 18 01:57:52 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B72271A1B13 for ; Sat, 18 Apr 2015 01:57:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.301
X-Spam-Level: 
X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, SPF_HELO_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YgXPummh4hXk for ; Sat, 18 Apr 2015 01:57:50 -0700 (PDT)
Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0764.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::764]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0629D1A1B0E for ; Sat, 18 Apr 2015 01:57:49 -0700 (PDT)
Authentication-Results: gmail.com; dkim=none (message not signed) header.d=none;
Received: from pc6 (81.151.162.168) by DBXPR07MB064.eurprd07.prod.outlook.com (10.242.147.24) with Microsoft SMTP Server (TLS) id 15.1.136.25; Sat, 18 Apr 2015 08:57:31 +0000
Message-ID: <022d01d079b5$842b0e00$4001a8c0@gateway.2wire.net>
From: t.petch 
To: "Murray S. Kucherawy" 
References: <5518019A.7080508@isode.com>	<2383989.tErOfD7dMh@kitterma-e6430><00f901d07854$99087a40$4001a8c0@gateway.2wire.net><01c301d07913$a4287a00$4001a8c0@gateway.2wire.net> 
Date: Sat, 18 Apr 2015 09:56:04 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [81.151.162.168]
X-ClientProxiedBy: DB4PR05CA0005.eurprd05.prod.outlook.com (25.160.40.15) To DBXPR07MB064.eurprd07.prod.outlook.com (10.242.147.24)
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB064;
X-Microsoft-Antispam-PRVS: 
X-Forefront-Antispam-Report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(377454003)(13464003)(24454002)(81686999)(81816999)(61296003)(86362001)(46102003)(62236002)(44716002)(77096005)(50986999)(42186005)(76176999)(93886004)(47776003)(66066001)(23676002)(92566002)(122386002)(116806002)(77156002)(62966003)(40100003)(1411001)(50226001)(44736004)(230783001)(33646002)(14496001)(110136001)(50466002)(19580395003)(19580405001)(1556002)(87976001)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DBXPR07MB064; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; 
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:DBXPR07MB064; BCL:0; PCL:0; RULEID:; SRVR:DBXPR07MB064; 
X-Forefront-PRVS: 0550778858
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Apr 2015 08:57:31.8573 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR07MB064
Archived-At: 
Cc: Scott Kitterman , IETF Apps Discuss 
Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-rfc7001bis-05
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 18 Apr 2015 08:57:51 -0000

----- Original Message -----
From: "Murray S. Kucherawy" 
To: "t.petch" 
Cc: "Scott Kitterman" ; "IETF Apps Discuss"

Sent: Friday, April 17, 2015 6:47 PM
> On Fri, Apr 17, 2015 at 1:13 AM, t.petch  wrote:
>
> > When I follow the references from X.7.25, RFC7372 says no more than
that
> > which is already in the IANA entry while the reference to RFC7001
takes
> > me to a paragraph that I read, and re-read and think 'eh?'  A bit
like
> > going straight from IANA to the domainkeys RFC for authentication
> > results, something you have now fixed in rfc7001bis.
> >
>
> X.7.25 is a code one might return if the "iprev" test fails and the
MTA
> chooses to reject the message rather than let it pass.  If rejecting,
> RFC7001 doesn't apply (obviously) other than being the only place in
the
> RFC series that there's currently a definition of what the "iprev"
check is
> in the first place.
>
> Reading section 3 thereof, for iprev, there is nothing about X.7.25 -
is
> > it really the right RFC?  well yes, RFC7372 says so, but I read the
> > 'iprev' paragraph as something that might happen when an MUA EHLOs
an
> > MSA, in which case I struggle to see how an Authentication-Results
> > header will ever get into an e-mail. Reverse DNS is fine, it is the
way
> > it fits into e-mail that I struggle with.
> >
>
> Does the above clarify?  If so, then I guess there are two things I
could
> do here:
>
> 1) Basically explain this in a subsection of the "iprev" definition,
but
> that seems an odd thing to do.
>
> 2) Put the definition of "iprev" into its own document, and then have
> X.7.25 and this document point to that one.

Murray

Unless there are a lot of enthusiastic supporters of 'iprev' out there,
then I think that another document is overkill, making things more
complex than they need be.  Yet having the IANA registry for X.7.25
point to a paragraph, a document,  that has no mention of X.7.25 -
well, seems underkill.   A single sentence with X.7.25 in it would
satisfy me. It doesn't matter much what the sentence says, just having
it there so that a follower of the reference from the IANA website knows
that they have landed in the right place and now must understand what it
says.

Tom Petch

> -MSK
>


From nobody Sat Apr 18 05:28:49 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84D581A86E0; Sat, 18 Apr 2015 05:28:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level: 
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2NTmoF6TZaYh; Sat, 18 Apr 2015 05:28:45 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AF5F1A802D; Sat, 18 Apr 2015 05:28:45 -0700 (PDT)
Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YjRrS-0008YT-F9; Sat, 18 Apr 2015 08:28:38 -0400
Date: Sat, 18 Apr 2015 08:28:30 -0400
From: John C Klensin 
To: Graham Klyne , Tony Hansen , Barry Leiba 
Message-ID: 
In-Reply-To: <55316A2B.5090900@ninebynine.org>
References: <2E49FA112B054FFAED69D8A1@JcK-HP8200.jck.com>  <723FBC93979E1019101319C5@JcK-HP8200.jck.com>    <55301F9F.5080207@att.com>  <55316A2B.5090900@ninebynine.org>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.35
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: 
Cc: draft-ietf-appsawg-uri-scheme-reg.all@ietf.org, IESG , Apps Discuss 
Subject: Re: [apps-discuss] Retroactive application of draft-ietf-appsawg-uri-scheme-reg - comprehensive review
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 18 Apr 2015 12:28:47 -0000

--On Friday, April 17, 2015 21:16 +0100 Graham Klyne
 wrote:

> On 16/04/2015 23:35, John C Klensin wrote:
>> 
>> 
>> --On Thursday, April 16, 2015 16:46 -0400 Tony Hansen
>>  wrote:
>> 
>>> Just now, I've re-reviewed all references to 3986 within
>>> draft-ietf-appsawg-uri-scheme-reg-06 and don't see anywhere
>>> that it should be construed as >updating< 3986. There are
>...
>> In the spirit of moving on, I'd prefer to avoid requiring
>> another rev and will happily settle for the assurance that
>> everyone involved will provide support for my pushing back if
>> anyone stands up and says "you can't do  in URNs because
>> draft-ietf-appsawg-urn-scheme-reg clarified 3986 to prohibit
>> it".
>...

> I assume you meant "draft-ietf-appsawg-uri-scheme-reg" above
> (not "*-urn-*"). 

Yes.  Sorry.

>  I'd be pushing back on any aspect which
> appeared to change what is required by RFC3986.

Then we are in agreement (!).

Because my concern still seems to be unclear, let me try to
explain it in a different way and as a series of logical
statements and propositions.  I do not believe that anything in
the first three bullets below should be controversial.  The
fourth one may be but, IMO, only if long-established principles
and terminology in computer science have become irrelevant to
the IETF and, at the risk of invoking another conversation, the
Humpty Dumpty philological system has taken over entirely.

(1) The community approved RFCs 2141 and 3406 as a Proposed
Standardsd and BCP, respectively.  RFC 1737 provides useful
information and context, but it is an Informational document and
has never been seriously claimed to represent community
consensus.   I note that such a document would not be allowed to
have "Requirements" in its title today.  It is interesting the
the title of RFC 1736 includes "Recommendations", not
"Requirements".

(2) RFC 3986 is not identified as updating, altering, or
restricting any of 2141 or 3406, nor, for that matter, 1737.
RFC 2396 is not identified as changing any of those
specifications either.  The sentences in Section 1.1.3 of RFC
3986 (and Section 1.2 of 1737 read as an explanatory and
tutorial "overview" not normative requirements.

(3) RFC 3986 Section 1.1.3 indicates that "A URI can be further
classified as a locator, a name, or both".   While that text
reinforces the (IMO, unfortunate) confusion between generic
name-class URIs and the "urn" scheme, there appears to be
nothing in 3986 (in that section or otherwise) that allows, much
less requires, one scheme to constrain another, either within
classes or across them.  It would be as unreasonable to claim
that the definition of the "urn" scheme imposes a constraint on
a hypothetical member of the "both" class at is would be to
claim that the definition of the "xmpp" or "sip" schemes
constrain the "http" scheme.

(4) While the title and abstract of 3986 appear very clear that
it, and its normative requirements, are about syntax, the
document also contains a great deal of explanatory, descriptive,
and other semantic information.  It is possible to separate
those things from the syntax, if necessary by modifying 3986
which does not (and could not) contain provisions that write its
provisions into stone with no possibility of modification.

At least so far, the IETF has not given up on the importance of
good sense and deployment experience and practices (sometimes
included under "running code") in interpreting written standards
and practices, including "BCP" documents that lay out procedures
or hopes for the future rather than documenting practices
already in widespread use.  When a standards-track document
exists, specifies things that are widely deployed and have been
for years, is associated with values in a registry, and clearly
anticipates certain future extensions, a claim that a later set
of documents prevent those extensions (or bar a designated
expert from approving IANA's installing an updated
registration), that would be a serious issue, requiring wide and
careful community review of the tradeoffs involved.  

I do not believe that either draft-ietf-appsawg-uri-scheme-reg
or RFC 3986 impose such requirements on the "urn" scheme.
Therefore, I do not believe there is a substantive problem with
draft-ietf-appsawg-uri-scheme-reg even though (as with most
other IETF documents) we could, if so inclined, quibble over
exact choices of words for months or years.  I am not so
inclined if it can be avoided.   

On the other hand, if claims are made that
draft-ietf-appsawg-uri-scheme-reg either adds constraints to
those that are clearly present in RFC 3986 or reinterprets (or
"clarifies") text in 3986 to impose stronger or different
requirements than are present there, especially on URI schemes
that existed long before 3986 and that were not explicitly
modified by it (or registration of updates to them), then there
are, IMO, serious problems with either the interpretation, of
this new specification, or both and fairness and reasonableness
require that they be sorted out now.

Finally, an observation: It has been said many times that the
primary purpose of  draft-ietf-appsawg-uri-scheme-reg is to make
registrations easier, especially for schemes that are, or are
reasonably expected to become, widely deployed and significant
to the Internet.    It seems ironic, perhaps even perverse, that
a document that is justified on that basis is being held up
because of claims that it will, as soon as approved, impose more
stringent requirements on one or more URI schemes that are
already broadly deployed and demonstrably important to the
community.

> (All of this leaves me wondering if it would be helpful to
> state that explicitly in the registration document, but at
> this stage in the process I'm reluctant to introduce
> suggestions for shadow-dodging changes.)

See above.

best,
   john




From nobody Sat Apr 18 11:58:48 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F29EC1A0262 for ; Sat, 18 Apr 2015 11:58:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2EltzsKzSipb for ; Sat, 18 Apr 2015 11:58:45 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EC531A01CB for ; Sat, 18 Apr 2015 11:58:44 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id B3E702081D for ; Sat, 18 Apr 2015 14:58:43 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Sat, 18 Apr 2015 14:58:43 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=Ic0NNAcluznxngp wpM4Nw6xg/VE=; b=K9gFd31uL31W5tM751l97Bqn2pzwRdy4ULMWW+8R9OFyqXZ f7PepGsXSJqs7IMAbHO5WgpEjfe89NebUWZOzYNQ77hjEN1nmOXL9b0Urg0rD9Ps k4j7IeO/C1Ck8UlYzztkG9WYXrK0SbZdJJF04r6TUUw5773QgrvAcF30yD60=
X-Sasl-enc: cbSVw2Zz7svwo/sKP/z+ffDihtddkIx0AF3sjST4gi89 1429383523
Received: from [104.55.94.41] (unknown [104.55.94.41]) by mail.messagingengine.com (Postfix) with ESMTPA id 5C827C00013; Sat, 18 Apr 2015 14:58:43 -0400 (EDT)
Message-ID: <5532A948.1090705@network-heretics.com>
Date: Sat, 18 Apr 2015 14:58:16 -0400
From: Keith Moore 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <2E49FA112B054FFAED69D8A1@JcK-HP8200.jck.com>  <723FBC93979E1019101319C5@JcK-HP8200.jck.com>    <55301F9F.5080207@att.com>  <55316A2B.5090900@ninebynine.org> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [apps-discuss] Retroactive application of draft-ietf-appsawg-uri-scheme-reg - comprehensive review
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 18 Apr 2015 18:58:47 -0000

I might comment on the rest of John's note later, but for now I'll just 
limit my response to this portion:

On 04/18/2015 08:28 AM, John C Klensin wrote:
> (1) The community approved RFCs 2141 and 3406 as a Proposed
> Standardsd and BCP, respectively.  RFC 1737 provides useful
> information and context, but it is an Informational document and
> has never been seriously claimed to represent community
> consensus.   I note that such a document would not be allowed to
> have "Requirements" in its title today.  It is interesting the
> the title of RFC 1736 includes "Recommendations", not
> "Requirements".

RFC 1737 was approved at a time that BCPs didn't yet exist.   Since it's 
not a protocol document, it wouldn't have been suitable for 
standards-track, and there wasn't any other way that the IESG could 
indicate community approval.   Informational was the only label that 
could be given to it.   So one can't really derive much significance 
from the lack of a BCP label.

It might not represent community-wide consensus at the time.  But to the 
best of my recollection it does represent a consensus of the URN WG.

Keith


From nobody Sat Apr 18 13:43:30 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E98F31A9050; Sat, 18 Apr 2015 13:43:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jZDN5QRyzUwa; Sat, 18 Apr 2015 13:43:24 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0664.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:664]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E0451A9047; Sat, 18 Apr 2015 13:43:24 -0700 (PDT)
Received: from SN1PR02MB1328.namprd02.prod.outlook.com (25.162.0.146) by SN1PR02MB1327.namprd02.prod.outlook.com (25.162.0.145) with Microsoft SMTP Server (TLS) id 15.1.125.19; Sat, 18 Apr 2015 20:43:00 +0000
Received: from SN1PR02MB1328.namprd02.prod.outlook.com ([25.162.0.146]) by SN1PR02MB1328.namprd02.prod.outlook.com ([25.162.0.146]) with mapi id 15.01.0125.002; Sat, 18 Apr 2015 20:43:00 +0000
From: Larry Masinter 
To: John C Klensin , Graham Klyne , "Tony Hansen" , Barry Leiba 
Thread-Topic: [apps-discuss] Retroactive application of draft-ietf-appsawg-uri-scheme-reg - comprehensive review
Thread-Index: AQHQbLK9y6upYE7RxEa2QJ3yBFYKbp1DivsAgAFCK4CACz7BgIAAGL2AgAADAoCAAAvBgIAAHnwAgAFrjoCAAQ+EAIAAFM2A
Date: Sat, 18 Apr 2015 20:42:59 +0000
Message-ID: 
References: <2E49FA112B054FFAED69D8A1@JcK-HP8200.jck.com>  <723FBC93979E1019101319C5@JcK-HP8200.jck.com>    <55301F9F.5080207@att.com>  <55316A2B.5090900@ninebynine.org> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/15.9.0.150408
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [50.184.24.49]
authentication-results: jck.com; dkim=none (message not signed) header.d=none; 
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR02MB1327;
x-microsoft-antispam-prvs: 
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10009020)(6009001)(86362001)(66066001)(83506001)(122556002)(99286002)(230783001)(19580395003)(83716003)(40100003)(2656002)(82746002)(93886004)(36756003)(2900100001)(33656002)(2950100001)(76176999)(54356999)(4001350100001)(92566002)(102836002)(87936001)(77156002)(62966003)(15975445007)(5001770100001)(50986999)(46102003)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR02MB1327; H:SN1PR02MB1328.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:SN1PR02MB1327; BCL:0; PCL:0; RULEID:;  SRVR:SN1PR02MB1327; 
x-forefront-prvs: 0550778858
Content-Type: text/plain; charset="utf-8"
Content-ID: <1CED9CFDC49D5A4D9BC8E9324CE0CC53@namprd02.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: adobe.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Apr 2015 20:42:59.2136 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR02MB1327
Archived-At: 
Cc: "draft-ietf-appsawg-uri-scheme-reg.all@ietf.org" , IESG , Apps Discuss 
Subject: Re: [apps-discuss] Retroactive application of draft-ietf-appsawg-uri-scheme-reg - comprehensive review
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 18 Apr 2015 20:43:27 -0000

QkNQIDM1IHNwZWNpZmllcyB0aGUgcHJvY2VzcyBhbmQgZ3VpZGVsaW5lcyBmb3IgVVJJIHNjaGVt
ZXMsIGFuZCBkcmFmdC1pZXRmLWFwcHNhd2ctdXJpLXNjaGVtZS1yZWcgdXBkYXRlcyBCQ1AgMzUs
IGFuZCBpcyBlZmZlY3RpdmUgYXMgc29vbiBhcyBpdCBpcyBwdWJsaXNoZWQuDQoNCkFzIGZhciBh
cyBhIHByaW9yIHJ1bGluZyBvZiBub24tYXBwbGljYWJpbGl0eSAgdG8gVVJOcyDigJQgIHdoYXQg
T1RIRVIgZ3VpZGVsaW5lcyBvciBwcm9jZXNzZXMgd291bGQgYXBwbHkgdG8gdXBkYXRlcyBvZiBh
IHByZXZpb3VzbHkgcmVnaXN0ZXJlZCBzY2hlbWU/IA0KQnV0IHRoZXNlIGFyZSBHVUlERUxJTkVT
LiBUaGVyZSBpcyBubyBmb3JtYWwgb3IgSUFOQS1lbmZvcmNlZCByZXF1aXJlbWVudHMgb3IgRXhw
ZXJ0IFJldmlld2VyIG92ZXJyaWRlLiAgSUVURiBjb25zZW5zdXMgb24gYSBVUk4gZG9jdW1lbnQg
dGhhdCBkaXJlY3RzIElBTkEgdG8gY2hhbmdlIHRoZSDigJx1cm464oCdIHNjaGVtZSByZWdpc3Ry
YXRpb24gd2lsbCBjYXVzZSB0aGUgcmVnaXN0cmF0aW9uIHRvIGNoYW5nZS4gRXhwbGFpbmluZyB3
aHkgeW914oCZcmUgbm90IGZvbGxvd2luZyBCQ1AgMzUgbWlnaHQgYmUgaGVscGZ1bCBpbiBnZXR0
aW5nIElFVEYgY29uc2Vuc3VzLCBidXQgdGhlcmUgaXMgbm8gc3BlY2lmaWNzIG9uIHdoYXQgY29u
c3RpdHV0ZXMgYW4gYWRlcXVhdGUganVzdGlmaWNhdGlvbi4gDQoNCklmIHRoZXJlIHdlcmUgc3Bl
Y2lmaWMgc3VnZ2VzdGlvbnMgb3IgY29tbWVudHMgb24gaG93IHRvIG1ha2UgQkNQIDM1IGludG8g
YmV0dGVyIOKAnGJlc3QgY3VycmVudCBwcmFjdGljZeKAnSBmb3IgdGhlIElBTkEgVVJJIHNjaGVt
ZSwgd2Ugc2hvdWxkIGZpeCBpdC4gDQoNClRvIGNhbGlicmF0ZSwgSSB0aGluayBsaWZldGltZSBv
ZiB0aGlzIGVkaXRpb24gb2YgQkNQIDM1IHdpbGwgYmUgc2hvcnQuIEl0IG1heSB3ZWxsIGJlIHRo
YXQgYSBtb3JlIHdob2xlc2FsZSBzZXQgb2YgY2hhbmdlcyBvZiBzcGVjaWZpY2F0aW9uIGFuZCBt
b2RlbCBvZiBVUkwgc2NoZW1lcyBhcmUgbmVlZGVkLg0KDQpUaGUgdXNlIG9mIElBTkEgdG8gZW51
bWVyYXRlIHNjaGVtZXMgaXMgaW4gcXVlc3Rpb24sIGZvciAidGhlIHdlYuKAnTsgIEkgdGhpbmsg
aXQgZG9lc27igJl0IHJlYWxseSBtZXNoIHdlbGwgd2l0aCBhIHdvcmxkIHdpdGgg4oCYcmVnaXN0
ZXJQcm90b2NvbEhhbmRsZXLigJksIHdoaWNoIHNlZW1zIHRvDQphc3N1bWUgYSBtb3JlIGR5bmFt
aWMgbWF0Y2hpbmcgb2Ygc2NoZW1lIHRvIGhhbmRsZXIgKG5vIElBTkEgaW52b2x2ZW1lbnQgYXQg
YWxsKS4NCg0KU28gSSB0aGluayBpdOKAmXMgdGltZSB0byByZWV4YW1pbmUgdGhlIGJyb2FkZXIg
cGljdHVyZS4gQXJlIOKAnHdlYuKAnSBhbmQg4oCcbm9uLXdlYuKAnSBhbmQg4oCcVVJO4oCdIFVS
TC9VUkkvVVJOcyBkaWZmZXJlbnQgdGhpbmdzLCBvciBhcmUgd2UgZ29pbmcgdG8gdHJ5IHRvIGtl
ZXAgdGhlbSB0b2dldGhlcj8gVGhlIHRlbnNpb24gYmV0d2VlbiBoYXZpbmcgYSBzaW5nbGUgcHJv
dG9jb2wgZWxlbWVudCB3aGljaCBpcyB1c2VkIGZvciBtdWx0aXBsZSBwdXJwb3NlcyBpcyBpbiBj
b25mbGljdCB3aXRoIHRoZSByZXF1aXJlbWVudHMgb2Ygb3B0aW11bSBhZGFwdGF0aW9uIGZvciBz
cGVjaWZpYyBjYXRlZ29yaWVzIG9mIGFwcGxpY2F0aW9ucy4NCg0KaHR0cHM6Ly90b29scy5pZXRm
Lm9yZy9odG1sL2RyYWZ0LXJ1YnktdXJsLXByb2JsZW0tMDENCg0KDQppbiB0aGUgbWVhbndoaWxl
LCBsZXTigJlzIGdldCB0aGlzIHVwZGF0ZSBvdXQuDQoNCg0KTGFycnkNCuKAlA0KaHR0cDovL2xh
cnJ5Lm1hc2ludGVyLm5ldA0K


From nobody Sat Apr 18 19:14:43 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85AEB1A0204; Sat, 18 Apr 2015 19:14:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ty0PiyPYnEEM; Sat, 18 Apr 2015 19:14:41 -0700 (PDT)
Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4AB61A0123; Sat, 18 Apr 2015 19:14:41 -0700 (PDT)
Received: by iejt8 with SMTP id t8so95708024iej.2; Sat, 18 Apr 2015 19:14:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=0h8UcZ9k2I7S7krCXD0vQ2p1H7WF9m/8gGo/TC/QLSM=; b=hnAhcyZ3ldqqAPflTEceFYGKD4YDSKflf4UFTcaMVfDgyJuX2ZsqvR/6NOxb5Dssae doUWh10nNyYqLGjx6B1wvB+7yoREbjYZh46hY5aAWP8KOr/fzMrrjz/wvhzujpL1e2F1 rUnMKwMRwya/GmwfQoNtZyZR3I9hJil7HFk9vuaS9qycCYIQgRE05QU/G+rfx9v41zot 7Ayr7KA+/6xlnOOFJW8bPw6wfUO1aZeYYkefT5nZq+bHsNgjKuJLDQnvfqMKhtZZ0gVn fMp7FmvH0WgDJQgxmwArnSQu+2gEFfOtPeEoT3zJW1J1ZQNOfEOiEOVxtu0ydbQUzMSQ zCYQ==
MIME-Version: 1.0
X-Received: by 10.50.138.70 with SMTP id qo6mr12671049igb.40.1429409681076; Sat, 18 Apr 2015 19:14:41 -0700 (PDT)
Sender: barryleiba@gmail.com
Received: by 10.107.7.130 with HTTP; Sat, 18 Apr 2015 19:14:40 -0700 (PDT)
In-Reply-To: 
References: <2E49FA112B054FFAED69D8A1@JcK-HP8200.jck.com>  <723FBC93979E1019101319C5@JcK-HP8200.jck.com>    <55301F9F.5080207@att.com>  <55316A2B.5090900@ninebynine.org>  
Date: Sat, 18 Apr 2015 22:14:40 -0400
X-Google-Sender-Auth: jm28g8F_ANk1vjbNL00mnO1QFB4
Message-ID: 
From: Barry Leiba 
To: Larry Masinter 
Content-Type: text/plain; charset=ISO-8859-1
Archived-At: 
Cc: Apps Discuss , Graham Klyne , "draft-ietf-appsawg-uri-scheme-reg.all@ietf.org" , IESG 
Subject: Re: [apps-discuss] Retroactive application of draft-ietf-appsawg-uri-scheme-reg - comprehensive review
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 19 Apr 2015 02:14:42 -0000

I think what Larry says here is exactly right -- this, in particular:

> But these are GUIDELINES. There is no formal or IANA-enforced
> requirements or Expert Reviewer override.  IETF consensus on a
> URN document that directs IANA to change the "urn:" scheme
> registration will cause the registration to change. Explaining why
> you're not following BCP 35 might be helpful in getting IETF
> consensus, but there is no specifics on what constitutes an
> adequate justification.

I'm happy to consider that this is the last that needs to be said on
this topic with respect to this document.  Thanks, Larry.

Barry


From nobody Sun Apr 19 09:18:00 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 075EA1A1BBC for ; Sun, 19 Apr 2015 09:17:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.663
X-Spam-Level: *
X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RM_TuS4GDIFT for ; Sun, 19 Apr 2015 09:17:58 -0700 (PDT)
Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D933E1A1B62 for ; Sun, 19 Apr 2015 09:17:57 -0700 (PDT)
Received: (qmail 62604 invoked from network); 19 Apr 2015 16:17:56 -0000
Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 19 Apr 2015 16:17:56 -0000
Date: 19 Apr 2015 16:17:34 -0000
Message-ID: <20150419161734.5518.qmail@ary.lan>
From: "John Levine" 
To: apps-discuss@ietf.org
In-Reply-To: <022d01d079b5$842b0e00$4001a8c0@gateway.2wire.net>
Organization: 
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Archived-At: 
Subject: Re: [apps-discuss] WGLC on draft-ietf-appsawg-rfc7001bis-05
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 19 Apr 2015 16:17:59 -0000

>Unless there are a lot of enthusiastic supporters of 'iprev' out there,
>then I think that another document is overkill, making things more
>complex than they need be.  Yet having the IANA registry for X.7.25
>point to a paragraph, a document,  that has no mention of X.7.25 -
>well, seems underkill.   A single sentence with X.7.25 in it would
>satisfy me.

For me, the main reason we're doing 7001bis is that several of the
current IANA registry entries point to documents that don't actually
define the thing in the registry, but rather something else that the
registry item uses.

So long as we find all the dangling references, describing them in
7001bis and pointing the registry at 7001bis should solve the problem.

R's,
John


From nobody Sun Apr 19 23:35:29 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC5C31ACE5E; Sun, 19 Apr 2015 23:35:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id haitj6_ZI-3n; Sun, 19 Apr 2015 23:35:25 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C54F41ACE60; Sun, 19 Apr 2015 23:35:24 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.0.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150420063524.15216.81562.idtracker@ietfa.amsl.com>
Date: Sun, 19 Apr 2015 23:35:24 -0700
Archived-At: 
Cc: apps-discuss@ietf.org
Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc7001bis-06.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Apr 2015 06:35:27 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Applications Area Working Group Working Group of the IETF.

        Title           : Message Header Field for Indicating Message Authentication Status
        Author          : Murray S. Kucherawy
	Filename        : draft-ietf-appsawg-rfc7001bis-06.txt
	Pages           : 52
	Date            : 2015-04-19

Abstract:
   This document specifies a message header field called Authentication-
   Results for use with electronic mail messages to indicate the results
   of message authentication efforts.  Any receiver-side software, such
   as mail filters or Mail User Agents (MUAs), can use this header field
   to relay that information in a convenient and meaningful way to users
   or to make sorting and filtering decisions.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-appsawg-rfc7001bis/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-appsawg-rfc7001bis-06

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-rfc7001bis-06


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Mon Apr 20 01:18:00 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29A461ACEFB for ; Mon, 20 Apr 2015 01:17:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RCGklXMk7gmA for ; Mon, 20 Apr 2015 01:17:57 -0700 (PDT)
Received: from mail-qg0-f54.google.com (mail-qg0-f54.google.com [209.85.192.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B20341ACEFA for ; Mon, 20 Apr 2015 01:17:57 -0700 (PDT)
Received: by qgej70 with SMTP id j70so49030944qge.2 for ; Mon, 20 Apr 2015 01:17:57 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=JNIC4GXRn+VPvZn5Y4nkmKubv64OGVsVp4gvX3bjN5Y=; b=bTPOjmjj2A4Wi7sG5WzJvoQBLZ5MM/PuCcSW2FbBg8a8ga01vvp/5iL5IfNkBDJUP/ 3FZ3uf0c+Iyz1Rj2bfYO7Cyc070/5hRsvzwBxDH3at7StqU9CeVgUygeJYPF84oiGqWT 0hIuzkD0p3LYO/QGIC7UEFjOd68nr0HJXxUP1848yENQR6sHyonUiZ6KQ7mECsReN2A0 SXAAcYjlbDQ5n8NAN2Ua0CgQVnxBKIXw+Waw0xwOS7sywqxqdih1J0na1cEQ/RGtEElu 1uxUdEY446brqg/fnKHxDd0+k9b7Obssmjhw0pjlSnr86F4R/9vwkmqACAqykzu9Yx3o V5YA==
X-Gm-Message-State: ALoCoQmi+pum1nGGWcepf8UCg6j2YUbONf6PZkR95Gcp3AvKHXXhSqZYz8dzrGgSbaFduPVbbaj0
MIME-Version: 1.0
X-Received: by 10.140.232.14 with SMTP id d14mr16593142qhc.79.1429517876971; Mon, 20 Apr 2015 01:17:56 -0700 (PDT)
Received: by 10.96.70.133 with HTTP; Mon, 20 Apr 2015 01:17:56 -0700 (PDT)
Received: by 10.96.70.133 with HTTP; Mon, 20 Apr 2015 01:17:56 -0700 (PDT)
Date: Mon, 20 Apr 2015 09:17:56 +0100
Message-ID: 
From: Phil Lello 
To: apps-discuss@ietf.org
Content-Type: multipart/alternative; boundary=001a11354eaa41e5dc05142391ee
Archived-At: 
Subject: [apps-discuss] SSH WG/protocol additions
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 20 Apr 2015 08:17:59 -0000

--001a11354eaa41e5dc05142391ee
Content-Type: text/plain; charset=UTF-8

Hi,

I believe the SSH protocol falls under applications rather than security;
what would be the appropriate place to discuss standardising additions?

I am approaching this from the perspective of applications using ssh as a
transport, rather than for system shells. Specifically, the areas I am
looking at are:

- Authentication integration with federated identities
- Using web sockets as a transport

Best wishes,

Phil Lello

--001a11354eaa41e5dc05142391ee
Content-Type: text/html; charset=UTF-8


Hi,


I believe the SSH protocol falls under applications rather than security; what would be the appropriate place to discuss standardising additions?


I am approaching this from the perspective of applications using ssh as a transport, rather than for system shells. Specifically, the areas I am looking at are:


- Authentication integration with federated identities

- Using web sockets as a transport


Best wishes,


Phil Lello


--001a11354eaa41e5dc05142391ee--


From nobody Mon Apr 20 02:44:00 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 161231B29B1 for ; Mon, 20 Apr 2015 02:43:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wLQM8hS9H1gM for ; Mon, 20 Apr 2015 02:43:56 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AA3F1B29B0 for ; Mon, 20 Apr 2015 02:43:54 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E203EBE4C; Mon, 20 Apr 2015 10:43:51 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9owsxQK8C-5b; Mon, 20 Apr 2015 10:43:50 +0100 (IST)
Received: from [10.87.48.73] (unknown [86.46.17.62]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id DFD25BE56; Mon, 20 Apr 2015 10:43:49 +0100 (IST)
Message-ID: <5534CA55.2070007@cs.tcd.ie>
Date: Mon, 20 Apr 2015 10:43:49 +0100
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Phil Lello , apps-discuss@ietf.org
References: 
In-Reply-To: 
OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [apps-discuss] SSH WG/protocol additions
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 20 Apr 2015 09:43:58 -0000

The secsh WG [1] was in the security area so it might be better
to use the saag@ietf.org list to discuss this. Or at least be a
good idea to send a mail there.

S.

On 20/04/15 09:17, Phil Lello wrote:
> Hi,
> 
> I believe the SSH protocol falls under applications rather than security;
> what would be the appropriate place to discuss standardising additions?
> 
> I am approaching this from the perspective of applications using ssh as a
> transport, rather than for system shells. Specifically, the areas I am
> looking at are:
> 
> - Authentication integration with federated identities
> - Using web sockets as a transport
> 
> Best wishes,
> 
> Phil Lello
> 
> 
> 
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
> 


From nobody Mon Apr 20 02:44:43 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBE921B29B2 for ; Mon, 20 Apr 2015 02:44:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4MR4TPXAFzHn for ; Mon, 20 Apr 2015 02:44:41 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B6A21B29B1 for ; Mon, 20 Apr 2015 02:44:41 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4A48CBE51; Mon, 20 Apr 2015 10:44:40 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S7oyAa9Yw0Lj; Mon, 20 Apr 2015 10:44:38 +0100 (IST)
Received: from [10.87.48.73] (unknown [86.46.17.62]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id DBCADBE4C; Mon, 20 Apr 2015 10:44:38 +0100 (IST)
Message-ID: <5534CA86.2040402@cs.tcd.ie>
Date: Mon, 20 Apr 2015 10:44:38 +0100
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Phil Lello , apps-discuss@ietf.org
References:  <5534CA55.2070007@cs.tcd.ie>
In-Reply-To: <5534CA55.2070007@cs.tcd.ie>
OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [apps-discuss] SSH WG/protocol additions
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 20 Apr 2015 09:44:43 -0000

Sorry, omitted the URL

On 20/04/15 10:43, Stephen Farrell wrote:
> 
> The secsh WG [1] was in the security area so it might be better
> to use the saag@ietf.org list to discuss this. Or at least be a
> good idea to send a mail there.
> 
> S.

[1]
https://tools.ietf.org/wg/secsh/charters?item=./charter.d/charter.2009-10-16_0859,1.txt

> 
> On 20/04/15 09:17, Phil Lello wrote:
>> Hi,
>>
>> I believe the SSH protocol falls under applications rather than security;
>> what would be the appropriate place to discuss standardising additions?
>>
>> I am approaching this from the perspective of applications using ssh as a
>> transport, rather than for system shells. Specifically, the areas I am
>> looking at are:
>>
>> - Authentication integration with federated identities
>> - Using web sockets as a transport
>>
>> Best wishes,
>>
>> Phil Lello
>>
>>
>>
>> _______________________________________________
>> apps-discuss mailing list
>> apps-discuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/apps-discuss
>>
> 
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
> 
> 


From nobody Mon Apr 20 03:19:13 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD89E1A92E7 for ; Mon, 20 Apr 2015 03:19:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level: 
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s8oWxH2METtx for ; Mon, 20 Apr 2015 03:19:09 -0700 (PDT)
Received: from ppsw-41.csi.cam.ac.uk (ppsw-41.csi.cam.ac.uk [131.111.8.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 922371A8AC0 for ; Mon, 20 Apr 2015 03:19:09 -0700 (PDT)
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:38014) by ppsw-41.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1Yk8nD-0005eP-Qh (Exim 4.82_3-c0e5623) (return-path ); Mon, 20 Apr 2015 11:19:07 +0100
Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1Yk8nD-0002ZS-7T (Exim 4.72) (return-path ); Mon, 20 Apr 2015 11:19:07 +0100
Date: Mon, 20 Apr 2015 11:19:07 +0100
From: Tony Finch 
X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk
To: Phil Lello 
In-Reply-To: 
Message-ID: 
References: 
User-Agent: Alpine 2.00 (LSU 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Tony Finch 
Archived-At: 
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] SSH WG/protocol additions
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 20 Apr 2015 10:19:11 -0000

Phil Lello  wrote:
>
> I am approaching this from the perspective of applications using ssh as a
> transport, rather than for system shells. Specifically, the areas I am
> looking at are:
>
> - Authentication integration with federated identities

Is this related to Project Moonshot?
https://www.ja.net/products-services/janet-futures/moonshot
https://community.jisc.ac.uk/groups/moonshot

Tony.
-- 
f.anthony.n.finch    http://dotat.at/
South Biscay: Cyclonic, becoming easterly, 4 or 5. Moderate or rough. Fair.
Good.


From nobody Mon Apr 20 06:36:57 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E42361A8A4C for ; Mon, 20 Apr 2015 06:36:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xl3z3RWtoRsv for ; Mon, 20 Apr 2015 06:36:55 -0700 (PDT)
Received: from mail-qg0-f52.google.com (mail-qg0-f52.google.com [209.85.192.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FEC21A8727 for ; Mon, 20 Apr 2015 06:36:55 -0700 (PDT)
Received: by qgdy78 with SMTP id y78so52307473qgd.0 for ; Mon, 20 Apr 2015 06:36:54 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=hMTDrPnZPs1tR4zDQ522jqLZtORh6h0x8QEICoD/E+Y=; b=OuzGPAaKX4+awSMxboXZ40NyrIXaAHYdnVRZnk1weZkK+/3z5oibw9JyufcDPI/8L8 jkK4uamukWJ0AL7J93rkE8XIgpuaCJk4oOBabOFX7zEAFSDE2xo1+vfFgh7I8imZgZQZ fOxcDI8dd1637V9jh8RIoRFxVqWRNc59f5uWGWIVHVthL0MHsMFSeQf85Cdu6YJxGT+I jxnAPXimIhS+x4JGlOqMQYMgICNjPJtzwYnowESGbKiaeIqdlYizlBGMaNXxuGasYs7k Awy4CSZQvLwBgigbZmIH3vfCMcEKvwT9xWxhXPiwwFJy81Tbrq1zDnQTgL9ulh3sjijL 2enA==
X-Gm-Message-State: ALoCoQm/ZmEM57saBjEAETzA6DnY76FDtF7lbhw7e87xqXLfnNGmr9jFRApxuPU/WBWdDjEbZdpx
MIME-Version: 1.0
X-Received: by 10.140.41.213 with SMTP id z79mr16797416qgz.103.1429537014503;  Mon, 20 Apr 2015 06:36:54 -0700 (PDT)
Received: by 10.96.70.133 with HTTP; Mon, 20 Apr 2015 06:36:54 -0700 (PDT)
In-Reply-To: 
References:  
Date: Mon, 20 Apr 2015 14:36:54 +0100
Message-ID: 
From: Phil Lello 
To: Tony Finch 
Content-Type: multipart/alternative; boundary=001a11c13c02f18187051428052f
Archived-At: 
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] SSH WG/protocol additions
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 20 Apr 2015 13:36:57 -0000

--001a11c13c02f18187051428052f
Content-Type: text/plain; charset=UTF-8

>
> > I am approaching this from the perspective of applications using ssh as a
> > transport, rather than for system shells. Specifically, the areas I am
> > looking at are:
> >
> > - Authentication integration with federated identities
>
> Is this related to Project Moonshot?
> https://www.ja.net/products-services/janet-futures/moonshot
> https://community.jisc.ac.uk/groups/moonshot
>

I have grazed the documentation for Moonshot, and whilst it is certainly an
interesting and potentially useful technology, it seems to require more
infrastructure (e.g. Radius/RadSec) than I am looking at. However, I
haven't yet had an opportunity to spin up a Moonshot test environment, and
it's possible I may have misunderstood the minimum requirements vs.
reference implementation.

I'll try moving discussion over to the saag list, however I am envisaging a
lightweight Authentication Protocol "asserted-identity", which passes a
namespace (e.g. "urn:oasis:names:tc:SAML:2.0:protocol") and assertion (e.g.
a urn:oasis:names:tc:SAML:2.0:assertion xml message) from the client to the
server. Local policy would be responsible for deciding supported
protocol(s), support for encypted/unencypted and signed/unsigned assertions.

Phil

--001a11c13c02f18187051428052f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



> I am approaching this from the perspective of applications using ssh a=
s a

> transport, rather than for system shells. Specifically, the areas I am=


> looking at are:

>

> - Authentication integration with federated identities



Is this related to Project Moonshot?

https://www.ja.net/products-services/janet-futures/moonshot<=
/a>

=
https://community.jisc.ac.uk/groups/moonshot



I have grazed the =
documentation for Moonshot, and whilst it is certainly an interesting and p=
otentially useful technology, it seems to require more infrastructure (e.g.=
 Radius/RadSec) than I am looking at. However, I haven't yet had an opp=
ortunity to spin up a Moonshot test environment, and it's possible I ma=
y have misunderstood the minimum requirements vs. reference implementation.=


I'll try moving discussion over to the saag list, ho=
wever I am envisaging a lightweight Authentication Protocol "asserted-=
identity", which passes a namespace (e.g. "urn:oasis:names:tc:SAM=
L:2.0:protocol") and assertion (e.g. a urn:oasis:names:tc:SAML:2.0:ass=
ertion xml message) from the client to the server. Local policy would be re=
sponsible for deciding supported protocol(s), support for encypted/unencypt=
ed and signed/unsigned assertions.

Phil


--001a11c13c02f18187051428052f--


From nobody Mon Apr 20 10:19:48 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B2991B2C53 for ; Mon, 20 Apr 2015 10:19:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lsplZQuS_C1q for ; Mon, 20 Apr 2015 10:19:41 -0700 (PDT)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDF621B2C4F for ; Mon, 20 Apr 2015 10:19:41 -0700 (PDT)
Received: from [10.10.39.129] (unknown [12.176.89.153]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 9682F509BF for ; Mon, 20 Apr 2015 13:19:40 -0400 (EDT)
From: Mark Nottingham 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <6597280E-DF2F-4F69-A276-CACFB35A1A5D@mnot.net>
Date: Mon, 20 Apr 2015 10:15:43 -0700
To: IETF Apps Discuss 
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
X-Mailer: Apple Mail (2.2098)
Archived-At: 
Subject: [apps-discuss] meta - removing list banner?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 20 Apr 2015 17:19:47 -0000

What do people think about removing the [apps-discuss] banner from the =
Subject line on this list?

IME it just makes it harder to fit the actual content of the Subject =
line into your reader.

Cheers,

--
Mark Nottingham   https://www.mnot.net/





From nobody Mon Apr 20 10:22:02 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EACCA1B2C5D for ; Mon, 20 Apr 2015 10:21:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -96.665
X-Spam-Level: 
X-Spam-Status: No, score=-96.665 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_HELO_EQ_D_D_D_D=1.597, HELO_DYNAMIC_IPADDR=1.951, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6GgS-MUhuqLe for ; Mon, 20 Apr 2015 10:21:58 -0700 (PDT)
Received: from lvps5-35-241-16.dedicated.hosteurope.de (www.gondrom.org [5.35.241.16]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A2BF1B2C60 for ; Mon, 20 Apr 2015 10:21:58 -0700 (PDT)
Received: from [163.119.49.41] (unknown [163.119.49.41]) by lvps5-35-241-16.dedicated.hosteurope.de (Postfix) with ESMTPSA id 049AD6366C; Mon, 20 Apr 2015 19:21:55 +0200 (CEST)
DomainKey-Signature: a=rsa-sha1;  q=dns; c=nofws; s=default; d=gondrom.org; b=A0aDdXjer7qWFrbhoL9SCGNQLULgH37vTWY7CpQx1qfK0azZMRvyi+cJoGcPgXJh43FMyUuB11EiNQsMRLmf+VDDMsv7KMgFRH9/ZfS7203k62XGU+Sf7qqw/NVtqbj9q90zktUqXwgAL8KUf0xaG+rXLlXzAvhzKuKLA4eo6dE=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:X-Priority:References:In-Reply-To:Content-Type:Content-Transfer-Encoding;
Message-ID: <553535B3.9030902@gondrom.org>
Date: Mon, 20 Apr 2015 18:21:55 +0100
From: Tobias Gondrom 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: mnot@mnot.net, apps-discuss@ietf.org
X-Priority: 4 (Low)
References: <6597280E-DF2F-4F69-A276-CACFB35A1A5D@mnot.net>
In-Reply-To: <6597280E-DF2F-4F69-A276-CACFB35A1A5D@mnot.net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [apps-discuss] meta - removing list banner?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 20 Apr 2015 17:22:00 -0000

I would prefer to keep the mailing-list banner. If you like feel free to 
make it shorter.
It helps quick sorting.
Just my 2cents.
Tobias


On 20/04/15 18:15, Mark Nottingham wrote:
> What do people think about removing the [apps-discuss] banner from the Subject line on this list?
>
> IME it just makes it harder to fit the actual content of the Subject line into your reader.
>
> Cheers,
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>
>
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss


From nobody Mon Apr 20 10:28:13 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1D741A89C6 for ; Mon, 20 Apr 2015 10:28:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yFK_fWSq2lIS for ; Mon, 20 Apr 2015 10:28:09 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5B5F1A89B3 for ; Mon, 20 Apr 2015 10:28:09 -0700 (PDT)
Received: from [192.168.1.87] (76-218-10-206.lightspeed.sntcca.sbcglobal.net [76.218.10.206]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t3KHS0di031074 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 20 Apr 2015 10:28:04 -0700
Message-ID: <5535371B.9030209@dcrocker.net>
Date: Mon, 20 Apr 2015 10:27:55 -0700
From: Dave Crocker 
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Tobias Gondrom , mnot@mnot.net, apps-discuss@ietf.org
References: <6597280E-DF2F-4F69-A276-CACFB35A1A5D@mnot.net> <553535B3.9030902@gondrom.org>
In-Reply-To: <553535B3.9030902@gondrom.org>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Mon, 20 Apr 2015 10:28:04 -0700 (PDT)
Archived-At: 
Subject: Re: [apps-discuss] meta - removing list banner?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Apr 2015 17:28:10 -0000

On 4/20/2015 10:21 AM, Tobias Gondrom wrote:
> I would prefer to keep the mailing-list banner. If you like feel free to
> make it shorter.
> It helps quick sorting.

+1

I've always found those tags for mailing lists quite helpful.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


From nobody Mon Apr 20 10:39:49 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C299B1A8AAC for ; Mon, 20 Apr 2015 10:39:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id la5LVRCb667N for ; Mon, 20 Apr 2015 10:39:46 -0700 (PDT)
Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6B691A8AA4 for ; Mon, 20 Apr 2015 10:39:45 -0700 (PDT)
Received: by wiax7 with SMTP id x7so89063548wia.0 for ; Mon, 20 Apr 2015 10:39:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=sRgeGQHRHJNVdC5r6r/UVqToKQWeVJbQHdI9l/+dMQ0=; b=jaurAIuEXdaaxM5/AYdkIRC7AZJm/rJJ/q6ULdemCm9fpQcyw2Bofm4n2lkycIMrNx T+rxVrCQRvewMNyAocI8dT0pJPMkYcCCSXaBh8w9fBNncv0J+ZX3EoYAN8OsvxaPBacl GHHF5SYP5xXIxzMBrNRc7pzsYW8MW7jF4Y5nfyXR/s1euC85t3CfU7joLbYHIz6WPVO8 cd1OPqbCWxsB+zypGU2xhcMbMyx+nbZ698qViV3DUs9zPSnn3Yh1o6U95o7OEqXMvXQc ZnMF78FYfaq+2QYdVnX7Tj2fa1KXeq7j0W3pTGqS1266C59uGWQOhnALrIezCv8VHMFl eaBg==
X-Received: by 10.180.20.14 with SMTP id j14mr27449502wie.45.1429551581724; Mon, 20 Apr 2015 10:39:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.27.179.224 with HTTP; Mon, 20 Apr 2015 10:39:21 -0700 (PDT)
In-Reply-To: <6597280E-DF2F-4F69-A276-CACFB35A1A5D@mnot.net>
References: <6597280E-DF2F-4F69-A276-CACFB35A1A5D@mnot.net>
From: Ira McDonald 
Date: Mon, 20 Apr 2015 13:39:21 -0400
Message-ID: 
To: Mark Nottingham , Ira McDonald 
Content-Type: multipart/alternative; boundary=90e6ba475d6937837005142b6ab7
Archived-At: 
Cc: IETF Apps Discuss 
Subject: Re: [apps-discuss] meta - removing list banner?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 20 Apr 2015 17:39:47 -0000

--90e6ba475d6937837005142b6ab7
Content-Type: text/plain; charset=UTF-8

Hi Mark,

I'm opposed to removing the banner.

I get messages from over 40 mailing lists in 6 standards bodies.  The
banners help,
when trying to find time-critical messages.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: blueroofmusic@gmail.com
Winter  579 Park Place  Saline, MI  48176  734-944-0094
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434


On Mon, Apr 20, 2015 at 1:15 PM, Mark Nottingham  wrote:

> What do people think about removing the [apps-discuss] banner from the
> Subject line on this list?
>
> IME it just makes it harder to fit the actual content of the Subject line
> into your reader.
>
> Cheers,
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>
>
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

--90e6ba475d6937837005142b6ab7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Mark,

I'm opposed to removing the banner.

I get messag=
es from over 40 mailing lists in 6 standards bodies.=C2=A0 The banners help=
,
when trying to find time-critical messages.

Cheers,
- Ira
Ira=
 McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobilit=
y Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary - =
IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printi=
ng Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Ro=
of Music / High North Inc
http://sites.goog=
le.com/site/blueroofmusic
http://sites.g=
oogle.com/site/highnorthinc
mailto: blueroofmusic@gmail.com
Winter=C2=A0 57=
9 Park Place=C2=A0 Saline, MI=C2=A0 48176=C2=A0 734-944-0094
Summer=C2=
=A0 PO Box 221=C2=A0 Grand Marais, MI 49839=C2=A0 906-494-2434



On Mon, Apr 20, 2015 at 1:15 PM, Mark Nottin=
gham <mnot@mnot.net> wrote:
Wh=
at do people think about removing the [apps-discuss] banner from the Subjec=
t line on this list?



IME it just makes it harder to fit the actual content of the Subject line i=
nto your reader.



Cheers,



--

Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/









_______________________________________________

apps-discuss mailing list

apps-discuss@ietf.org

https://www.ietf.org/mailman/listinfo/apps-discuss





--90e6ba475d6937837005142b6ab7--


From nobody Mon Apr 20 10:45:46 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F125F1A039B for ; Mon, 20 Apr 2015 10:45:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ioW4wmk6znEL for ; Mon, 20 Apr 2015 10:45:43 -0700 (PDT)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20C051A0151 for ; Mon, 20 Apr 2015 10:45:43 -0700 (PDT)
Received: from [10.10.39.204] (unknown [12.176.89.153]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 545F8509BC; Mon, 20 Apr 2015 13:45:39 -0400 (EDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-C1B55F27-98FA-46D4-B1EA-6B45987D2D2F
Mime-Version: 1.0 (1.0)
From: Mark Nottingham 
X-Mailer: iPhone Mail (12F70)
In-Reply-To: 
Date: Mon, 20 Apr 2015 10:45:27 -0700
Content-Transfer-Encoding: 7bit
Message-Id: <8F041FE8-26E8-4074-AB19-77B75FDD3678@mnot.net>
References: <6597280E-DF2F-4F69-A276-CACFB35A1A5D@mnot.net> 
To: Ira McDonald 
Archived-At: 
Cc: IETF Apps Discuss 
Subject: Re: [apps-discuss] meta - removing list banner?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 20 Apr 2015 17:45:45 -0000

--Apple-Mail-C1B55F27-98FA-46D4-B1EA-6B45987D2D2F
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Ok, it sounds like people are still getting utility out of it, no need to co=
ntinue the thread.=20

Personally, I filter on list-id...

Sent from my iPhone

> On 20 Apr 2015, at 10:39 am, Ira McDonald  wrote:=

>=20
> Hi Mark,
>=20
> I'm opposed to removing the banner.
>=20
> I get messages from over 40 mailing lists in 6 standards bodies.  The bann=
ers help,
> when trying to find time-critical messages.
>=20
> Cheers,
> - Ira
>=20
> Ira McDonald (Musician / Software Architect)
> Co-Chair - TCG Trusted Mobility Solutions WG
> Chair - Linux Foundation Open Printing WG
> Secretary - IEEE-ISTO Printer Working Group
> Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
> IETF Designated Expert - IPP & Printer MIB
> Blue Roof Music / High North Inc
> http://sites.google.com/site/blueroofmusic
> http://sites.google.com/site/highnorthinc
> mailto: blueroofmusic@gmail.com
> Winter  579 Park Place  Saline, MI  48176  734-944-0094
> Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434
>=20
>=20
>> On Mon, Apr 20, 2015 at 1:15 PM, Mark Nottingham  wrote:
>> What do people think about removing the [apps-discuss] banner from the Su=
bject line on this list?
>>=20
>> IME it just makes it harder to fit the actual content of the Subject line=
 into your reader.
>>=20
>> Cheers,
>>=20
>> --
>> Mark Nottingham   https://www.mnot.net/
>>=20
>>=20
>>=20
>>=20
>> _______________________________________________
>> apps-discuss mailing list
>> apps-discuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/apps-discuss
>=20

--Apple-Mail-C1B55F27-98FA-46D4-B1EA-6B45987D2D2F
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


Ok, it sounds like people are still ge=
tting utility out of it, no need to continue the thread. 
Personally, I filter on list-id...

Sent from my iPhone

On 20 Apr 2015, at 10:39 am, Ira McDonald <blueroofmusic@gmail.com> wrote:

Hi Mark,

I'm opposed to removing the b=
anner.

I get messages from over 40 mailing lists in 6 standards bodie=
s.  The banners help,
when trying to find time-critical messages.
Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Co-Chair=
 - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printi=
ng WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO=
 PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Pri=
nter MIB
Blue Roof Music / High North Inc
=
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: blueroofmusic@gmail.com
Wi=
nter  579 Park Place  Saline, MI  48176  734-944-0094Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434
=

=



On Mon, Apr 20, 2015 at 1:15 PM, Mark Notting=
ham <mnot@mnot.net> wrote:
What d=
o people think about removing the [apps-discuss] banner from the Subject lin=
e on this list?



IME it just makes it harder to fit the actual content of the Subject line in=
to your reader.



Cheers,



--

Mark Nottingham   https://www.mnot.net/









_______________________________________________

apps-discuss mailing list

apps-discuss@ietf.org

https://www.ietf.org/mailman/listinfo/apps-discuss





=

--Apple-Mail-C1B55F27-98FA-46D4-B1EA-6B45987D2D2F--


From nobody Mon Apr 20 10:51:34 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2FD61A8AE2 for ; Mon, 20 Apr 2015 10:51:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.612
X-Spam-Level: 
X-Spam-Status: No, score=-0.612 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQ3Qlsxa5bfv for ; Mon, 20 Apr 2015 10:51:33 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.159.242.17]) by ietfa.amsl.com (Postfix) with ESMTP id EB8F41A8AD1 for ; Mon, 20 Apr 2015 10:51:32 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PL13WK9PNK00LXOZ@mauve.mrochek.com> for apps-discuss@ietf.org; Mon, 20 Apr 2015 10:46:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mrochek.com; s=mauve; t=1429551990; bh=FgVT3AaTJzpa8P3VWILaoGn2ISxZWWpNkjKznBlNbeU=; h=Cc:Date:From:Subject:In-reply-to:References:To; b=OCXRmTbG7DSOPWidm1CtRndLrtJw2MSsoKveIdnVHlLdYJVCGC0Zr1nIxqjBXR480 HFZEk0dLv66YvxEg+70omywHLiEHe/CH2Dzs3V9IKDVBJE5mDAl9wOGWFr7uH37Sd5 BqjiNlenLUF8iJfIltcccgRAe2ZyX3/Ayjllh1Kk=
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01PKU1OPTSVK0000AQ@mauve.mrochek.com>; Mon, 20 Apr 2015 10:46:28 -0700 (PDT)
Message-id: <01PL13WJ06V00000AQ@mauve.mrochek.com>
Date: Mon, 20 Apr 2015 10:46:04 -0700 (PDT)
From: Ned Freed 
In-reply-to: "Your message dated Mon, 20 Apr 2015 10:27:55 -0700" <5535371B.9030209@dcrocker.net>
References: <6597280E-DF2F-4F69-A276-CACFB35A1A5D@mnot.net> <553535B3.9030902@gondrom.org> <5535371B.9030209@dcrocker.net>
To: Dave Crocker 
Archived-At: 
Cc: mnot@mnot.net, apps-discuss@ietf.org
Subject: Re: [apps-discuss] meta - removing list banner?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 20 Apr 2015 17:51:33 -0000

> On 4/20/2015 10:21 AM, Tobias Gondrom wrote:
> > I would prefer to keep the mailing-list banner. If you like feel free to
> > make it shorter.
> > It helps quick sorting.

> +1

> I've always found those tags for mailing lists quite helpful.

Same here. This one is a bit long but still not unreasonable.

				Ned


From nobody Mon Apr 20 10:54:55 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4B921A8AEE for ; Mon, 20 Apr 2015 10:54:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SPMbNuH3qvFJ for ; Mon, 20 Apr 2015 10:54:51 -0700 (PDT)
Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A598F1A8BB3 for ; Mon, 20 Apr 2015 10:54:42 -0700 (PDT)
Received: by widdi4 with SMTP id di4so109283242wid.0 for ; Mon, 20 Apr 2015 10:54:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:date:message-id:subject:from:to:content-type; bh=IedK7nF+sCa9oDDGtNfGUiSO41NlzLOE6YrQ5mcgxck=; b=EaHhNJhA6r8Ojg96BfFBbvKrcE8tmXUkgc69vtaOgX/VzlKBx70357mEAS5UAM0Y31 qLzpCUMAqSc75YGy4Z/MySGMVy9fDk9I4ZVMNXge/1zSiA5cn4v9+PfrF/W1nHGuo3n7 y68YLFohizlDf1rxc88FZE8iVcPavTrpguQ1Rz0mM5yIm7U2Ty3KP3di57Eg/uFHdbS+ IhOOkZyl7isgH/adlPxP2ZovaeJzQHqLEFCD4Uityv7i3Kp15GkUmf6uXgnQnjvsUnYV VtMG59Cx8QtQ/ySuQX6Tm6N3Et43MQWjbb/1aNuPnGx/0g5nKWb4m+USWBvwDvLkckGe /F4Q==
MIME-Version: 1.0
X-Received: by 10.180.99.2 with SMTP id em2mr27572350wib.59.1429552481368; Mon, 20 Apr 2015 10:54:41 -0700 (PDT)
Received: by 10.27.92.17 with HTTP; Mon, 20 Apr 2015 10:54:41 -0700 (PDT)
Date: Mon, 20 Apr 2015 10:54:41 -0700
Message-ID: 
From: "Murray S. Kucherawy" 
To: IETF Apps Discuss 
Content-Type: multipart/alternative; boundary=f46d04426c68d700a405142b9f5a
Archived-At: 
Subject: [apps-discuss] Working Group Last Calls: draft-ietf-appsawg-text-markdown and draft-ietf-appsawg-text-markdown-use-cases
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 20 Apr 2015 17:54:53 -0000

--f46d04426c68d700a405142b9f5a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Colleagues,

This note starts a Working Group Last Call for
draft-ietf-appsawg-text-markdown and
draft-ietf-appsawg-text-markdown-use-cases.  As you may recall, this work
comes to us for registration of a new media type around the "markdown" text
format and establishes a registry for its variants.  The latter document
was separated from the former per working group consensus.

Please provide review comments or expressions of support for the current
versions either on this list or privately to .all@tools.ietf.org
or to appsawg-chairs@tools.ietf.org on or before May 1, 2015.  Be as
detailed as possible.  The co-chairs need to determine if the document has
working group consensus, which means we need to know people have read the
latest version and agree with its content and with the idea that it is
ready to proceed.  A simple =E2=80=9C+1=E2=80=9D doesn=E2=80=99t tell us an=
ything.

Also, if any participant has knowledge of IPR that needs to be declared on
this work, please do so, as required by BCPs 78 and 79.

I will be fulfilling the duties of document shepherd.

Thanks,
-MSK, APPSAWG co-chair

--f46d04426c68d700a405142b9f5a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Colleagues,

This note starts a Working Group Last C=
all for draft-ietf-appsawg-text-markdown and draft-ietf-appsawg-text-markdo=
wn-use-cases.=C2=A0 As you may recall, this work comes to us for registrati=
on of a new media type around the "markdown" text format and esta=
blishes a registry for its variants.=C2=A0 The latter document was separate=
d from the former per working group consensus.

Please provide review=
 comments or expressions of support for the current versions either on this=
 list or privately to <document>.all@tools.ietf.org or to appsawg-chairs@tools.ietf.org on or before May 1, 2015.=C2=A0 Be a=
s detailed as possible.=C2=A0 The co-chairs need to determine if the docume=
nt has working group consensus, which means we need to know people have rea=
d the latest version and agree with its content and with the idea that it i=
s ready to proceed.=C2=A0 A simple =E2=80=9C+1=E2=80=9D doesn=E2=80=99t tel=
l us anything.

Also, if any participant has knowledge of IPR that ne=
eds to be declared on this work, please do so, as required by BCPs 78 and 7=
9.

I will be fulfilling the duties of document shepherd.

Than=
ks,
-MSK, APPSAWG co-chair


--f46d04426c68d700a405142b9f5a--


From nobody Mon Apr 20 10:57:08 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BB381A8BB2 for ; Mon, 20 Apr 2015 10:57:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vKrExVtNHEJz for ; Mon, 20 Apr 2015 10:57:04 -0700 (PDT)
Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DB761A8BB0 for ; Mon, 20 Apr 2015 10:57:04 -0700 (PDT)
Received: by widdi4 with SMTP id di4so109361221wid.0 for ; Mon, 20 Apr 2015 10:57:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AMklT5wYcqsDHXQmdhmwPKSiB/iLCsHA4qdzEWBfQ7U=; b=xeKk/2lywxXSsIIYeK6K/og2VAXEVzlQQQnTIAcF22Ymu8bYeheEvmbPAercWymSZa GeRqryocJnTq+3jVa0NQpI+RNwGicK9/sI4qqeH3KuwVG5GW6LFkF6JJnj4z0IpUZ/ID DJBsu4bBCnBoTVKTAXVPgrd29yKiyE84CiIq58zrxxBpg0fjd5X8e542cTxH3Z+jgah8 LuMP22bq3Ac0gey4tfqg0XQoFj70yMhPC+z1vIPVvX9LY66m9f2c+U/f0x52349J0pfV ZRff4bY92DI5FbgRioeSH/5X7Uoe26+hNioDRwFxvJ2IgODMz3m1Csy1D6WHQTcvDfb/ Ojkg==
MIME-Version: 1.0
X-Received: by 10.194.179.194 with SMTP id di2mr32804444wjc.4.1429552623303; Mon, 20 Apr 2015 10:57:03 -0700 (PDT)
Received: by 10.27.92.17 with HTTP; Mon, 20 Apr 2015 10:57:02 -0700 (PDT)
In-Reply-To: <01PL13WJ06V00000AQ@mauve.mrochek.com>
References: <6597280E-DF2F-4F69-A276-CACFB35A1A5D@mnot.net> <553535B3.9030902@gondrom.org> <5535371B.9030209@dcrocker.net> <01PL13WJ06V00000AQ@mauve.mrochek.com>
Date: Mon, 20 Apr 2015 10:57:02 -0700
Message-ID: 
From: "Murray S. Kucherawy" 
To: Ned Freed 
Content-Type: multipart/alternative; boundary=089e01419d1c4cc46705142ba8f3
Archived-At: 
Cc: IETF Apps Discuss 
Subject: Re: [apps-discuss] meta - removing list banner?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 20 Apr 2015 17:57:06 -0000

--089e01419d1c4cc46705142ba8f3
Content-Type: text/plain; charset=UTF-8

On Mon, Apr 20, 2015 at 10:46 AM, Ned Freed  wrote:

> > On 4/20/2015 10:21 AM, Tobias Gondrom wrote:
> > > I would prefer to keep the mailing-list banner. If you like feel free
> to
> > > make it shorter.
> > > It helps quick sorting.
>
> > +1
>
> > I've always found those tags for mailing lists quite helpful.
>
> Same here. This one is a bit long but still not unreasonable.
>

You're not the only one to say that.  We could shorten it to "apps" if
people would find that helpful, though anyone with an apps-discuss rule
would then have to change to match.

-MSK

--089e01419d1c4cc46705142ba8f3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On Mon, Apr 20, 2015 at 10:46 AM, Ned Freed <ned.free=
d@mrochek.com> wrote:
> On 4=
/20/2015 10:21 AM, Tobias Gondrom wrote:

> > I would prefer to keep the mailing-list banner. If you like feel =
free to

> > make it shorter.

> > It helps quick sorting.



> +1



> I've always found those tags for mailing lists quite helpful.



Same here. This one is a bit long but still not unreasonable.



You're n=
ot the only one to say that.=C2=A0 We could shorten it to "apps" =
if people would find that helpful, though anyone with an apps-discuss rule =
would then have to change to match.

-MSK 
=



--089e01419d1c4cc46705142ba8f3--


From nobody Mon Apr 20 10:59:11 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F7BA1A8BB0 for ; Mon, 20 Apr 2015 10:59:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nwtf-Y2LYuBz for ; Mon, 20 Apr 2015 10:59:08 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6319D1B2C85 for ; Mon, 20 Apr 2015 10:58:49 -0700 (PDT)
Received: from [192.168.1.87] (76-218-10-206.lightspeed.sntcca.sbcglobal.net [76.218.10.206]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t3KHwiGh031603 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 20 Apr 2015 10:58:47 -0700
Message-ID: <55353E52.7070904@dcrocker.net>
Date: Mon, 20 Apr 2015 10:58:42 -0700
From: Dave Crocker 
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Mark Nottingham , Ira McDonald 
References: <6597280E-DF2F-4F69-A276-CACFB35A1A5D@mnot.net>  <8F041FE8-26E8-4074-AB19-77B75FDD3678@mnot.net>
In-Reply-To: <8F041FE8-26E8-4074-AB19-77B75FDD3678@mnot.net>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Mon, 20 Apr 2015 10:58:47 -0700 (PDT)
Archived-At: 
Cc: IETF Apps Discuss 
Subject: [apps-discuss] List-ID vs. [list-id] (was Re: meta - removing list banner?)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Apr 2015 17:59:09 -0000

On 4/20/2015 10:45 AM, Mark Nottingham wrote:
> Personally, I filter on list-id...


This ought to be better.  More structured by virtue of explicitly
labeling the nature of the attribute string, etc.

Yet the current reality it isn't, in most/all MUAs.  In fact, relying
only on List-ID would represent a serious /reduction/ in utility.

This goes to the challenges of creating supporting infrastructure for a
construct.

The current convention allows extremely useful, one-click sorting in
many MUAs.  The major win is that it is at the beginning of the Subject
field; so the column sort mechanism with message summary lists, works
just right.

By contrast, List-ID is almost entirely unknown to MUAs.  Consider what
it would take to upgrade each of them, to support this construct.

Would it be cleaner?  Sure.

Now go convince all those MUA developers to do the work.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


From nobody Mon Apr 20 11:00:24 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BBE91B2CBD for ; Mon, 20 Apr 2015 11:00:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ny8GhosIv18i for ; Mon, 20 Apr 2015 11:00:22 -0700 (PDT)
Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3956D1B2C9B for ; Mon, 20 Apr 2015 11:00:10 -0700 (PDT)
Received: by pdbqa5 with SMTP id qa5so214612205pdb.1 for ; Mon, 20 Apr 2015 11:00:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=vvpWrtONDMKWlHux7IR6MLI4lQdbtX0DMw1vrloSd/c=; b=Dx9cI2aSVFbLnLlR+v9zMWwKiELd0w1TFg2Ed+7pAkh0YRMWHxPurbXwKrasJXwV4a MFYYcOpVLiFIiLa54q8Q/cKszDdzDQbWP4vCMFvcrUkk+E98ph7TXwKt/psNl/XIOHhl 6kJfS8TDiEQxxvflhg3v70nnGhC1oMZpM2zV6Qvqpha7YdvUSu6dzApLY5F1KFm41Uv1 KuVtjAODh43JXBnaysHNMd1Wwep2BlO0rHgAAKX++JkCehH6T6xs1gy2ppXpHpyIkM22 emcCvMDu1A19r1E4pV4EgAPndyuyUX7KZ7qAm/EQ8fho4ou3Xrd1MgvXfgC5RRQQcai8 H86w==
X-Received: by 10.66.149.8 with SMTP id tw8mr30513430pab.69.1429552808806; Mon, 20 Apr 2015 11:00:08 -0700 (PDT)
Received: from [192.168.1.4] (184-76-96-188.war.clearwire-wmx.net. [184.76.96.188]) by mx.google.com with ESMTPSA id jx5sm18746178pbc.85.2015.04.20.11.00.07 for  (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Apr 2015 11:00:07 -0700 (PDT)
Message-ID: <55353EA3.5090800@gmail.com>
Date: Mon, 20 Apr 2015 12:00:03 -0600
From: Doug Royer 
Organization: http://SoftwareAndServices.NET
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <6597280E-DF2F-4F69-A276-CACFB35A1A5D@mnot.net>
In-Reply-To: <6597280E-DF2F-4F69-A276-CACFB35A1A5D@mnot.net>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090801090904060906020003"
Archived-At: 
Subject: Re: [apps-discuss] meta - removing list banner?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 20 Apr 2015 18:00:23 -0000

This is a cryptographically signed message in MIME format.

--------------ms090801090904060906020003
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable

On 04/20/2015 11:15 AM, Mark Nottingham wrote:
> What do people think about removing the [apps-discuss] banner from the =
Subject line on this list?
>
No. They are useful as additional email filters.
Especially when the messages get cross posted or you get Cc'd, it helps t=
o filter them it into the correct folder

--=20

Doug Royer - (http://K7DMR.us / http://DougRoyer.US)
DouglasRoyer@gmail.com
714-989-6135



--------------ms090801090904060906020003
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMbDCC
BjAwggUYoAMCAQICAw2hujANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl
IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh
dGUgQ2xpZW50IENBMB4XDTE1MDQwODAxMzMzM1oXDTE2MDQwODE3Mjc0N1owSDEfMB0GA1UE
AwwWZG91Z2xhc3JveWVyQGdtYWlsLmNvbTElMCMGCSqGSIb3DQEJARYWZG91Z2xhc3JveWVy
QGdtYWlsLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANXyUMrxMu8vCOZr
gttripw7pERzobvbKSg/nzn4IWjai3FOp/KDqb+abKc6QS6kvsQzYm+w86mlod6g1eqTZuJr
Sll68brMtrNDEYaVMzKV72q6au7nUg27JVV0/CXInpO6G9lVTvO4iKdFZohmA+ZFD6OZPwBt
2mPQFk/7dyYNNSGRIS2wAcXXUjSFBzK4j8thZ/UQE26M3en23PDFjkkojQkcEO2LPh43nedP
hBB4qjZoGsIldUhPTPFvkjPE/O8o/KLbQdSuKC0WliUBPr8rCimbci5ZGZCsSdM/yDgmZpw6
3EaCes9m82ySNufCq1cEeXJVqgPd4vSPsJ/L9KECAwEAAaOCAtwwggLYMAkGA1UdEwQCMAAw
CwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU
OfuPno/bm4d4TYB5N1gCufNJbuEwHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw
IQYDVR0RBBowGIEWZG91Z2xhc3JveWVyQGdtYWlsLmNvbTCCAUwGA1UdIASCAUMwggE/MIIB
OwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNv
bS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9u
IEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGlu
ZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRD
b20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBp
biBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8E
LzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggr
BgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3Vi
L2NsYXNzMS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29t
L2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3
LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAAMjuAConCkc6BuIzHJGnYqqbEAi
m5sB32+Bg+WuOwGZO/O1KbY+IkVQXa4aoIYqS9MBVZUYyhXRAN+2FTUacWbdiCZmdNnsBv+C
pdOuX6CBRBdWMdxvMurDInfy0ppcdGCe83DMdT2kFi7A7tkSz7ikHp9yfKOCRuqKB+78V3FM
8KYnA1oLZLWxhx6xXPqJkRcZsCCaS4NbdqUL0zZcJxPiNiusIywqEGsrl/4en9q29gdNJUnH
mzKKVymUc5D4yDZ+AIMVVW8MvUb5gRRQDRovIPa4Yu08YX0TnuRgN792ISams3PbAtlHgXU/
MJU8Xnk1qiSN8TKtESP+5KFkLIUwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0x
CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg
RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp
Y2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQsw
CQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp
Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQ
cmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw
ggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6E
RKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9
f1+1PKHG/FaR/wpbfuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89l
GxahNvuryGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZn
a//jdiSyrrSMTGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGj
ggGtMIIBqTAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Lt
kpzg2ssBXHx+ljVO8tS4UYIwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYI
KwYBBQUHAQEEWjBYMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2Ew
LQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8E
VDBSMCegJaAjhiFodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0
dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1
NwECATBmMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRm
MDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRm
MA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkF
gdtY1o95CfegFJTwqBBmf8pyTUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA
5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4q
SfQoCRcLN5A0t4DkuVhTMXIzuQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y
0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3
OHQgWI270g+5MYA8GfgI/EPT5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0Lw
Zrp8MQ+Z77U1uL7TelWO5lApsbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0q
ZW2Niy/QvVNKbb43A43ny076khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6Tcv
GbjxkJh8BYtv9ePsXklAxtm8J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZj
oEhdGwXV27ioRKbj/cIq7JRXun0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jGCA90wggPZ
AgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE
CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD
b20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAw2hujAJBgUrDgMC
GgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTA0
MjAxODAwMDNaMCMGCSqGSIb3DQEJBDEWBBSiFsecZvJ5JHYn/AkRqIGe1F3H9zBsBgkqhkiG
9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZI
hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkr
BgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu
MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQD
Ey9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDDaG6
MIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx
ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50
IENBAgMNobowDQYJKoZIhvcNAQEBBQAEggEAns6Ap13Myxj3LI4o3iz+J03EPNbNkkGsp267
ZF0bU5QDL7GiIb3BiAdPGAracA5aY1fIh8gqk+Tau0ZmCeHSC3eSEjMzlzD53ufYoJeMTegs
PS25tny8P8/00WH/0ApawJ08729zMrNLfbjKqXwzbHuD2FQK4NNNqcQis3O+TIhl+Uq0nDx4
BzQGorfXXRc6J3w95uDK4nR4PnKKWDZMRho//44Imd0rGAIgtVEjwI4PfrN7kAx3C/iLZqZC
ob/1mRlZwArnukpquX1AUcCy2e6/oyV17C1aQ6S66RRE7KrHOaP+TNsdWc3VbeyxYCf34qk3
wwUsOtgXuBZnuQ5o+gAAAAAAAA==
--------------ms090801090904060906020003--


From nobody Mon Apr 20 11:01:17 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 721551B2C8B for ; Mon, 20 Apr 2015 11:01:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ytT8o6c9LgOt for ; Mon, 20 Apr 2015 11:01:15 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C1741B2C97 for ; Mon, 20 Apr 2015 11:01:11 -0700 (PDT)
Received: from [192.168.1.87] (76-218-10-206.lightspeed.sntcca.sbcglobal.net [76.218.10.206]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t3KI16gn031710 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 20 Apr 2015 11:01:10 -0700
Message-ID: <55353EE0.7040704@dcrocker.net>
Date: Mon, 20 Apr 2015 11:01:04 -0700
From: Dave Crocker 
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: "Murray S. Kucherawy" , Ned Freed 
References: <6597280E-DF2F-4F69-A276-CACFB35A1A5D@mnot.net> <553535B3.9030902@gondrom.org> <5535371B.9030209@dcrocker.net> <01PL13WJ06V00000AQ@mauve.mrochek.com> 
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Mon, 20 Apr 2015 11:01:10 -0700 (PDT)
Archived-At: 
Cc: IETF Apps Discuss 
Subject: Re: [apps-discuss] meta - removing list banner?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 20 Apr 2015 18:01:16 -0000

On 4/20/2015 10:57 AM, Murray S. Kucherawy wrote:
> You're not the only one to say that.  We could shorten it to "apps

some -* conventions have developed, to distinguish sub-groups.  So
 is more verbose, but also more helpful, with -discuss
being one of the standard choices.

Perhaps we could do some trailblazing and try to make -gen (for general)
be the convention, thereby saving 4 characters?

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


From nobody Mon Apr 20 11:30:41 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5C021B2CE1 for ; Mon, 20 Apr 2015 11:30:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iERPP3ehLirb for ; Mon, 20 Apr 2015 11:30:36 -0700 (PDT)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 674C51B3014 for ; Mon, 20 Apr 2015 11:30:35 -0700 (PDT)
Received: from [10.10.39.129] (unknown [12.176.89.153]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id AED9F509BD; Mon, 20 Apr 2015 14:30:33 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: Mark Nottingham 
In-Reply-To: <55353E52.7070904@dcrocker.net>
Date: Mon, 20 Apr 2015 11:30:31 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <6597280E-DF2F-4F69-A276-CACFB35A1A5D@mnot.net>  <8F041FE8-26E8-4074-AB19-77B75FDD3678@mnot.net> <55353E52.7070904@dcrocker.net>
To: Dave Crocker 
X-Mailer: Apple Mail (2.2098)
Archived-At: 
Cc: IETF Apps Discuss 
Subject: Re: [apps-discuss] List-ID vs. [list-id] (was Re: meta - removing list banner?)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 20 Apr 2015 18:30:39 -0000

I don't use it for sorting, I use it to filter into per-list IMAP =
mailboxes on the server side, using SIEVE. But most MUAs can also do =
that client-side, IME>

Cheers,


> On 20 Apr 2015, at 10:58 am, Dave Crocker  wrote:
>=20
> On 4/20/2015 10:45 AM, Mark Nottingham wrote:
>> Personally, I filter on list-id...
>=20
>=20
> This ought to be better.  More structured by virtue of explicitly
> labeling the nature of the attribute string, etc.
>=20
> Yet the current reality it isn't, in most/all MUAs.  In fact, relying
> only on List-ID would represent a serious /reduction/ in utility.
>=20
> This goes to the challenges of creating supporting infrastructure for =
a
> construct.
>=20
> The current convention allows extremely useful, one-click sorting in
> many MUAs.  The major win is that it is at the beginning of the =
Subject
> field; so the column sort mechanism with message summary lists, works
> just right.
>=20
> By contrast, List-ID is almost entirely unknown to MUAs.  Consider =
what
> it would take to upgrade each of them, to support this construct.
>=20
> Would it be cleaner?  Sure.
>=20
> Now go convince all those MUA developers to do the work.
>=20
> d/
>=20
> --=20
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net

--
Mark Nottingham   https://www.mnot.net/





From nobody Mon Apr 20 13:04:44 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 545B91B2D16 for ; Mon, 20 Apr 2015 13:04:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.302
X-Spam-Level: 
X-Spam-Status: No, score=-99.302 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nk3alSHypo8i for ; Mon, 20 Apr 2015 13:04:37 -0700 (PDT)
Received: from mail.santronics.com (winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id A92F31B2D1A for ; Mon, 20 Apr 2015 13:04:37 -0700 (PDT)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=372; t=1429560271; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=sfxv1ii8uuXcZBLvv2VcyYpU8NI=; b=MrSNzBNLRA9eMlHB4ete VJhLBjxw2MVUf6p6ds7N003NqYtxKFZZKbeva3B6LZpWLhFLZR4yqWxIraBlgsBx sB0ma/vS0UqUQalP57BCABPIY+U9/+gW8SVZwNRfgaZnQQApZpk+qvjacNAUC5EL uHlJgUdIZR0md8v064comEA=
Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Mon, 20 Apr 2015 16:04:31 -0400
Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com;  adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; dmarc=pass author.d=isdg.net signer.d=beta.winserver.com (atps signer);
Received: from hector.wildcatblog.com (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3270280449.3933.5860; Mon, 20 Apr 2015 16:04:30 -0400
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=372; t=1429560029; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=UQzcNl9 K0gFjswCxcYYz2FkwVdWdX5iAcV1zFaT26gc=; b=FYK+emOe64DtGI/S0MyNcy8 2qI+AhdgH4e8gQHwYkLc69pnUpGma/yVuymc+U4syCrxYT3ltwtMPbldnAZ4O9sF SxIbAN/fDBJBefgiOXZAKGomjET5IwFdRkntqpmRftCh9cp2Gck36fS0MIZQz8OX 85vzP5D7oXpsdzRJ5ec4=
Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Mon, 20 Apr 2015 16:00:29 -0400
Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1862564754.9.10176; Mon, 20 Apr 2015 16:00:28 -0400
Message-ID: <55355BCD.1070804@isdg.net>
Date: Mon, 20 Apr 2015 16:04:29 -0400
From: Hector Santos 
Organization: Santronics Software, Inc.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <6597280E-DF2F-4F69-A276-CACFB35A1A5D@mnot.net>  <8F041FE8-26E8-4074-AB19-77B75FDD3678@mnot.net>
In-Reply-To: <8F041FE8-26E8-4074-AB19-77B75FDD3678@mnot.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [apps-discuss] meta - removing list banner?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 20 Apr 2015 20:04:43 -0000

On 4/20/2015 1:45 PM, Mark Nottingham wrote:
> Ok, it sounds like people are still getting utility out of it, no need
> to continue the thread.
>
> Personally, I filter on list-id...

Right, which is the right way to do it if you are moving stuff into a 
"list-id" folder.   But visually, the list subject tag helps when its 
all keep in one "in-box."



-- 
HLS



From nobody Mon Apr 20 13:06:42 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC7D21B2D2E for ; Mon, 20 Apr 2015 13:06:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t5L0mX5ZkFxZ for ; Mon, 20 Apr 2015 13:06:40 -0700 (PDT)
Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D117C1B2D2A for ; Mon, 20 Apr 2015 13:06:39 -0700 (PDT)
Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id e4c55355.0.258241.00-2108.745261.nbfkord-smmo05.seg.att.com (envelope-from );  Mon, 20 Apr 2015 20:06:39 +0000 (UTC)
X-MXL-Hash: 55355c4f23b45e90-e61286a21d4acd055714201c160a50fe9da60881
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t3KK6cOG018252 for ; Mon, 20 Apr 2015 16:06:38 -0400
Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t3KK6UJX018171 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 20 Apr 2015 16:06:33 -0400
Received: from alpi153.aldc.att.com (alpi153.aldc.att.com [130.8.42.31]) by alpi132.aldc.att.com (RSA Interceptor) for ; Mon, 20 Apr 2015 20:06:10 GMT
Received: from aldc.att.com (localhost [127.0.0.1]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id t3KK6Afp029606 for ; Mon, 20 Apr 2015 16:06:10 -0400
Received: from dns.maillennium.att.com (maillennium.att.com [135.25.114.99]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id t3KK65kb029224 for ; Mon, 20 Apr 2015 16:06:05 -0400
Received: from utcdtl09rn987q.itservices.sbc.com (win10entpre.itservices.sbc.com[135.110.241.151](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20150420200604gw1000ce1ee>; Mon, 20 Apr 2015 20:06:04 +0000
X-Originating-IP: [135.110.241.151]
Message-ID: <55355C2B.3010106@att.com>
Date: Mon, 20 Apr 2015 16:06:03 -0400
From: Tony Hansen 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: IETF Apps Discuss 
References: <6597280E-DF2F-4F69-A276-CACFB35A1A5D@mnot.net>
In-Reply-To: <6597280E-DF2F-4F69-A276-CACFB35A1A5D@mnot.net>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-AnalysisOut: [v=2.0 cv=Kvf6LxqN c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a]
X-AnalysisOut: [=5hWoPXNsKEoA:10 a=ozIisaXup1cA:10 a=BLceEmwcHowA:10 a=N65]
X-AnalysisOut: [9UExz7-8A:10 a=zQP7CpKOAAAA:8 a=e9J7MTPGsLIA:10 a=N7DAwZXd]
X-AnalysisOut: [-QXd36EGIKcA:9 a=pILNOxqGKmIA:10 a=t4Ica_R32LwA:10 a=Knk0c]
X-AnalysisOut: [LqwdFkA:10 a=bYA0P6JAxLUA:10]
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)]
X-MAIL-FROM: 
X-SOURCE-IP: [144.160.229.23]
Archived-At: 
Subject: Re: [apps-discuss] meta - removing list banner?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 20 Apr 2015 20:06:41 -0000

On 4/20/15 1:15 PM, Mark Nottingham wrote:
> What do people think about removing the [apps-discuss] banner from the Subject line on this list?
> 
> IME it just makes it harder to fit the actual content of the Subject line into your reader.

-1


From nobody Mon Apr 20 19:18:38 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09F651A8747 for ; Mon, 20 Apr 2015 19:18:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.663
X-Spam-Level: *
X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BqfvRgDMCGEm for ; Mon, 20 Apr 2015 19:18:36 -0700 (PDT)
Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12DF41A8745 for ; Mon, 20 Apr 2015 19:18:35 -0700 (PDT)
Received: (qmail 6001 invoked from network); 21 Apr 2015 02:18:35 -0000
Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 21 Apr 2015 02:18:35 -0000
Date: 21 Apr 2015 02:18:13 -0000
Message-ID: <20150421021813.1597.qmail@ary.lan>
From: "John Levine" 
To: apps-discuss@ietf.org
In-Reply-To: <55353E52.7070904@dcrocker.net>
Organization: 
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Archived-At: 
Cc: dcrocker@bbiw.net
Subject: Re: [apps-discuss] List-ID vs. [list-id] (was Re: meta - removing list banner?)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 21 Apr 2015 02:18:37 -0000

>Yet the current reality it isn't, in most/all MUAs.  In fact, relying
>only on List-ID would represent a serious /reduction/ in utility.

It's true -- Yahoo and Hotmail still can't sort on list-id.  Gmail
can, I think most desktop MUAs can.

R's,
John


From nobody Tue Apr 21 00:36:41 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3C271B36DE; Tue, 21 Apr 2015 00:36:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s01KoxOhEC-H; Tue, 21 Apr 2015 00:36:33 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D4571B31AB; Tue, 21 Apr 2015 00:36:33 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.0.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150421073633.23707.35248.idtracker@ietfa.amsl.com>
Date: Tue, 21 Apr 2015 00:36:33 -0700
Archived-At: 
Cc: apps-discuss@ietf.org
Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc7001bis-07.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Apr 2015 07:36:37 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Applications Area Working Group Working Group of the IETF.

        Title           : Message Header Field for Indicating Message Authentication Status
        Author          : Murray S. Kucherawy
	Filename        : draft-ietf-appsawg-rfc7001bis-07.txt
	Pages           : 52
	Date            : 2015-04-21

Abstract:
   This document specifies a message header field called Authentication-
   Results for use with electronic mail messages to indicate the results
   of message authentication efforts.  Any receiver-side software, such
   as mail filters or Mail User Agents (MUAs), can use this header field
   to relay that information in a convenient and meaningful way to users
   or to make sorting and filtering decisions.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-appsawg-rfc7001bis/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-appsawg-rfc7001bis-07

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-rfc7001bis-07


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Tue Apr 21 02:38:26 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAC2E1A8840 for ; Tue, 21 Apr 2015 02:38:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xAuzjxMprjTx for ; Tue, 21 Apr 2015 02:38:22 -0700 (PDT)
Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0751.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::751]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 509481A6F22 for ; Tue, 21 Apr 2015 02:38:22 -0700 (PDT)
Authentication-Results: gmail.com; dkim=none (message not signed) header.d=none;
Received: from pc6 (81.151.162.168) by AMXPR07MB055.eurprd07.prod.outlook.com (10.242.67.149) with Microsoft SMTP Server (TLS) id 15.1.136.25; Tue, 21 Apr 2015 09:38:00 +0000
Message-ID: <028001d07c16$a91fc260$4001a8c0@gateway.2wire.net>
From: t.petch 
To: "Murray S. Kucherawy" 
References: <6597280E-DF2F-4F69-A276-CACFB35A1A5D@mnot.net> <553535B3.9030902@gondrom.org> <5535371B.9030209@dcrocker.net> <01PL13WJ06V00000AQ@mauve.mrochek.com> 
Date: Tue, 21 Apr 2015 10:29:28 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [81.151.162.168]
X-ClientProxiedBy: DB3PR05CA0042.eurprd05.prod.outlook.com (25.160.41.170) To AMXPR07MB055.eurprd07.prod.outlook.com (10.242.67.149)
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMXPR07MB055;
X-Forefront-Antispam-Report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(24454002)(51704005)(13464003)(479174004)(377454003)(46102003)(1456003)(33646002)(62236002)(42186005)(19580395003)(19580405001)(15975445007)(92566002)(93886004)(77096005)(62966003)(77156002)(1411001)(44716002)(50986999)(110136001)(50226001)(23676002)(86362001)(66066001)(81686999)(76176999)(50466002)(47776003)(40100003)(61296003)(122386002)(87976001)(81816999); DIR:OUT; SFP:1102; SCL:1; SRVR:AMXPR07MB055; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; 
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:AMXPR07MB055; BCL:0; PCL:0; RULEID:; SRVR:AMXPR07MB055; 
X-Forefront-PRVS: 0553CBB77A
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Apr 2015 09:38:00.7805 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMXPR07MB055
Archived-At: 
Cc: IETF Apps Discuss 
Subject: Re: [apps-discuss] meta - removing list banner?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 21 Apr 2015 09:38:25 -0000

---- Original Message -----
From: "Murray S. Kucherawy" 
To: "Ned Freed" 
Cc: "IETF Apps Discuss" 
Sent: Monday, April 20, 2015 6:57 PM
> On Mon, Apr 20, 2015 at 10:46 AM, Ned Freed 
wrote:
>
> > > On 4/20/2015 10:21 AM, Tobias Gondrom wrote:
> > > > I would prefer to keep the mailing-list banner. If you like feel
free
> > to
> > > > make it shorter.
> > > > It helps quick sorting.
> >
> > > +1
> >
> > > I've always found those tags for mailing lists quite helpful.
> >
> > Same here. This one is a bit long but still not unreasonable.
> >
>
> You're not the only one to say that.  We could shorten it to "apps" if
> people would find that helpful, though anyone with an apps-discuss
rule
> would then have to change to match.

I agree it is most useful to have but shorter would be better but not
shorter than three a-z characters.

Of course I will have to change my rules (plural) but given notice that
it is coming, then that is easy to manage (unlike unannounced changes to
the IETF data tracker website especially when most of it does not work
with IE8 mumble grumble)

Tom Petch






>
> -MSK
>


------------------------------------------------------------------------
--------


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


From nobody Tue Apr 21 09:02:33 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA14B1ACF57; Tue, 21 Apr 2015 09:02:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1
X-Spam-Level: 
X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  J_CHICKENPOX_35=0.6, MIME_8BIT_HEADER=0.3] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lze6YFqmtnyH; Tue, 21 Apr 2015 09:02:28 -0700 (PDT)
Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id A15871ACF59; Tue, 21 Apr 2015 09:02:28 -0700 (PDT)
Received: from host4.velocix.com ([81.134.152.4] helo=macbook-pro.corp.velocix.com) by smtp04.mailcore.me with esmtpa (Exim 4.80.1) (envelope-from ) id 1Ykad0-00062p-H2; Tue, 21 Apr 2015 17:02:26 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: Ben Niven-Jenkins 
In-Reply-To: <552D23AC.7050703@cisco.com>
Date: Tue, 21 Apr 2015 17:02:24 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <155E6729-DB7E-4934-B447-9A8D2D7A68C1@niven-jenkins.co.uk>
References: <552C3E12.50607@cisco.com> <552D23AC.7050703@cisco.com>
To: =?utf-8?Q?=E2=8C=98_Matt_Miller?= 
X-Mailer: Apple Mail (2.2070.6)
X-Mailcore-Auth: 9600544
X-Mailcore-Domain: 172912
Archived-At: 
Cc: "" , cdni@ietf.org, IETF Apps Discuss 
Subject: Re: [apps-discuss] appsdir early review of draft-ietf-cdni-redirection
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 21 Apr 2015 16:02:31 -0000

Hi Matt,

Thanks for the review, some responses inline.

> On 14 Apr 2015, at 15:26, =E2=8C=98 Matt Miller  =
wrote:
>=20
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>=20
> [ Resending to include apps-discuss ]
>=20
>> Minor Issues:
>>=20
>> * In Section 4.2., some of the language about the JSON encoding=20
>> correctness can be handled by conforming to I-JSON [RFC7493],
>> which this draft already does in spirit.

I'm not sure it results in being able to remove much text from Section =
4.2 because from a quick scan of RFC7493 the only overlap is both =
documents state the JSON object MUST NOT contain duplicate keys/names =
but I'm OK with adding a reference to I-JSON e.g.=20

OLD:
The body of RI requests and responses is a JSON object [RFC7159] =
containing a dictionary of key:value pairs.

NEW:
The body of RI requests and responses is a JSON object [RFC7159] that =
MUST conform to [RFC7493] containing a dictionary of key:value pairs.

>> * In Section 4.5.2., it's not clear why the keys "sc(location)",=20
>> "sc(cache-control)", and "sc()" are different from the=20
>> other "sc-"-based keys; I would have expected them to be=20
>> "sc-location", "sc-cache-control", and "sc-".  This=20
>> deviates from the text in Section 4.5 that says "sc- is prefixed
>> to keys for information to be passed by the Server (uCDN) to the=20
>> Client (User Agent)."  I suggest you either change the keys to be=20
>> "sc-" instead of "sc()", or change the text in=20
>> Section 4.5 .

The keys sc(location), sc(cache-control) and sc() are =
different to the other sc- keys because their values encode the values =
of HTTP headers, whereas the values of the other sc- keys encode =
information about the HTTP request/response that are not sent in HTTP =
headers (method, version, etc).

[Actually sc(location) and sc(cache-control) aren't special but are =
specific instances of sc() called out as they are likely to =
be of particular interest for the use case of redirection between CDNs.]

The thinking of putting the header name in () was to avoid possible =
clashes, e.g. if someone wanted to return a HTTP Header called "status" =
they wouldn't be able to do so because sc-status is already used for =
carrying the HTTP response's status code.

The simple fix would be to change sc() to sc-() =
so we avoid any potential clash and the format of the key is aligned =
with section 4.5 that says they start sc- (and do the same for the cs- =
keys too).

>> * In Section 4.7., it seems very odd that all of the error object=20
>> keys are optional.  Is the intent really that the following is=20
>> valid?
>>=20
>> "error": {}
>>=20
>> If it is, then an explanation of when and why that is valid would=20
>> be very helpful to me.  Otherwise, I suggest mandating at least=20
>> "error-code ".

Good catch, will change so that error-code is mandatory.

>> * In Section 5., I would strongly consider referring to=20
>> draft-ietf-uta-tls-bcp (currently in the RFC Editor's Queue), and=20
>> incorporating its recommendations.  I think this draft
>> accomplishes the basics, but I think you get a more complete
>> picture with -tls-bcp.

There are some discussions ongoing in the CDNI WG on referencing =
draft-ietf-uta-tls-bcp instead of articulating specific requirements in =
each of the CDNI specifications and we plan to align =
draft-ietf-cdni-redirection with the CDNI WG consensus for that text, =
which looks likely to end up being a reference to =
draft-ietf-uta-tls-bcp.

>>=20
>> Nits:
>>=20
>> * The acronym CDN should be expanded in the Abstract.  Some might=20
>> also argue it should be expanded in the title, but not me.

Thanks, will expand.

>> * The terms list in Section 2. is editorially a bit awkward to me;
>> I expected there to be hanging indents.  In the XML, this can be=20
>> accomplished by wrapping the new terms'  with > style=3D'hanging'> and placing the attribute hangtext equal to the=20
>> term for each terms'  (e.g., > Redirection:">The act of using an application ...)

Thanks, will try this in the next revision.

Ben

>>=20
>>=20
>>=20
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
> Comment: GPGTools - https://gpgtools.org
>=20
> iQEcBAEBCgAGBQJVLSOsAAoJEDWi+S0W7cO1fZ8H/0Ew+qOZGyMz5JnBiFgajGWA
> JddcGDOKES3wSdO4rwnG0y+D9GRHz/3JYmhDalyo/8MvDSsxQ+Z8vDuN0AEk5dLV
> QOe/4DR4T10v9z5ZPcwQSEXY3dYSJoXc7Je0f7gw4Dhnp1croQ4o+6Qo8+W7pGwt
> 7jLzkeeKR8FJ9gPf5sQ0/zPBXf5Nhmgs9d/ZjbzuLVJOIpt77sr09dIwq8k30PaB
> O3765+dgH0jRjgaZuu7VZU429/TwDE/uaffCG8UcBDXjh6j/7zEgHwTDIwTj+5Ed
> 3onZ2bha/Q10vGUO7ooaj5jNNB2r1I/P9F4FSk8DMH7ioMP5KEI6e5Bml4z0/8U=3D
> =3DoeMr
> -----END PGP SIGNATURE-----
>=20
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss


From nobody Tue Apr 21 11:34:54 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B1D91A8909; Tue, 21 Apr 2015 11:34:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level: 
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h7ZEn12oHYI2; Tue, 21 Apr 2015 11:34:50 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A2CE1A88C8; Tue, 21 Apr 2015 11:34:50 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG 
To: "IETF-Announce" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.0.1.p1
Auto-Submitted: auto-generated
Precedence: bulk
Sender: 
Message-ID: <20150421183450.14859.54816.idtracker@ietfa.amsl.com>
Date: Tue, 21 Apr 2015 11:34:50 -0700
Archived-At: 
Cc: apps-discuss@ietf.org
Subject: [apps-discuss] Last Call:  (Message Header Field for Indicating Message Authentication Status) to Proposed Standard
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: ietf@ietf.org
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Apr 2015 18:34:51 -0000

The IESG has received a request from the Applications Area Working Group
WG (appsawg) to consider the following document:
- 'Message Header Field for Indicating Message Authentication Status'
   as 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 2015-05-05. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


   This document specifies a message header field called Authentication-
   Results for use with electronic mail messages to indicate the results
   of message authentication efforts.  Any receiver-side software, such
   as mail filters or Mail User Agents (MUAs), can use this header field
   to relay that information in a convenient and meaningful way to users
   or to make sorting and filtering decisions.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-appsawg-rfc7001bis/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-appsawg-rfc7001bis/ballot/


No IPR declarations have been submitted directly on this I-D.



From nobody Tue Apr 21 12:57:43 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDE1E1A0439 for ; Tue, 21 Apr 2015 12:57:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.456
X-Spam-Level: 
X-Spam-Status: No, score=0.456 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, IXHASH_X1=1.5, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y7HWhOufXdGk for ; Tue, 21 Apr 2015 12:57:34 -0700 (PDT)
Received: from homiemail-a102.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 43AE51A0277 for ; Tue, 21 Apr 2015 12:57:26 -0700 (PDT)
Received: from homiemail-a102.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a102.g.dreamhost.com (Postfix) with ESMTP id 18BEC20047B83 for ; Tue, 21 Apr 2015 12:57:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=ZZLpNtShjybpNQyZ4H2a lu0LXTQ=; b=H/g1pir9TDT8nDtEjI7wfTUOHWbbrHTOOMx69oGAGxux6ED4ZeTJ sQG6ZMNR7rVnqQEOBs2PVcCPwCA276L7C8QsloafWF7ElaRIRAdUTJrWA0XaN4RT UozcyvX6JvaxuYI6yIT/0DGM3o0N7YoIxrt3d7OFNeFfwmC6Kxy/JCI=
Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a102.g.dreamhost.com (Postfix) with ESMTPSA id EC37120047B81 for ; Tue, 21 Apr 2015 12:57:25 -0700 (PDT)
Received: by iejt8 with SMTP id t8so22271273iej.2 for ; Tue, 21 Apr 2015 12:57:25 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.107.157.70 with SMTP id g67mr804313ioe.11.1429646245320; Tue, 21 Apr 2015 12:57:25 -0700 (PDT)
Received: by 10.64.128.133 with HTTP; Tue, 21 Apr 2015 12:57:25 -0700 (PDT)
In-Reply-To: <6597280E-DF2F-4F69-A276-CACFB35A1A5D@mnot.net>
References: <6597280E-DF2F-4F69-A276-CACFB35A1A5D@mnot.net>
Date: Tue, 21 Apr 2015 14:57:25 -0500
Message-ID: 
From: Nico Williams 
To: Mark Nottingham 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: IETF Apps Discuss 
Subject: Re: [apps-discuss] meta - removing list banner?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 21 Apr 2015 19:57:36 -0000

I don't need the banner for filtering, but I do use it for visual
filtering in a big IETF mail folder.  FWIW.


From nobody Thu Apr 23 08:10:45 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77CD11AC3CC; Thu, 23 Apr 2015 08:10:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1
X-Spam-Level: 
X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  J_CHICKENPOX_35=0.6, MIME_8BIT_HEADER=0.3] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SLzP5Ixv5MWG; Thu, 23 Apr 2015 08:10:41 -0700 (PDT)
Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.144]) by ietfa.amsl.com (Postfix) with ESMTP id 1B5A31AC3DF; Thu, 23 Apr 2015 08:10:24 -0700 (PDT)
Received: from dab-glb1-h-1-8.dab.02.net ([82.132.218.244] helo=[172.20.10.4]) by smtp04.mailcore.me with esmtpa (Exim 4.80.1) (envelope-from ) id 1YlIlS-0007P7-Kc; Thu, 23 Apr 2015 16:10:23 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: Ben Niven-Jenkins 
In-Reply-To: <155E6729-DB7E-4934-B447-9A8D2D7A68C1@niven-jenkins.co.uk>
Date: Thu, 23 Apr 2015 16:10:03 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <552C3E12.50607@cisco.com> <552D23AC.7050703@cisco.com> <155E6729-DB7E-4934-B447-9A8D2D7A68C1@niven-jenkins.co.uk>
To: =?utf-8?Q?=E2=8C=98_Matt_Miller?= 
X-Mailer: Apple Mail (2.2070.6)
X-Mailcore-Auth: 9600544
X-Mailcore-Domain: 172912
Archived-At: 
Cc: "" , cdni@ietf.org, IETF Apps Discuss 
Subject: Re: [apps-discuss] appsdir early review of draft-ietf-cdni-redirection
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 23 Apr 2015 15:10:43 -0000

Hi Matt,

Following up on my previous email, FYI I pushed out a -09 version of =
draft-ietf-cdni-redirection which I believe addresses all of your =
comments except the security considerations (which I will change once =
consensus is reached in the CDNI WG on appropriate text).

New draft here:
http://www.ietf.org/internet-drafts/draft-ietf-cdni-redirection-09.txt

Diff from -08 here:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-redirection-09


Ben


> On 21 Apr 2015, at 17:02, Ben Niven-Jenkins  =
wrote:
>=20
> Hi Matt,
>=20
> Thanks for the review, some responses inline.
>=20
>> On 14 Apr 2015, at 15:26, =E2=8C=98 Matt Miller  =
wrote:
>>=20
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA512
>>=20
>> [ Resending to include apps-discuss ]
>>=20
>>> Minor Issues:
>>>=20
>>> * In Section 4.2., some of the language about the JSON encoding=20
>>> correctness can be handled by conforming to I-JSON [RFC7493],
>>> which this draft already does in spirit.
>=20
> I'm not sure it results in being able to remove much text from Section =
4.2 because from a quick scan of RFC7493 the only overlap is both =
documents state the JSON object MUST NOT contain duplicate keys/names =
but I'm OK with adding a reference to I-JSON e.g.=20
>=20
> OLD:
> The body of RI requests and responses is a JSON object [RFC7159] =
containing a dictionary of key:value pairs.
>=20
> NEW:
> The body of RI requests and responses is a JSON object [RFC7159] that =
MUST conform to [RFC7493] containing a dictionary of key:value pairs.
>=20
>>> * In Section 4.5.2., it's not clear why the keys "sc(location)",=20
>>> "sc(cache-control)", and "sc()" are different from the=20=

>>> other "sc-"-based keys; I would have expected them to be=20
>>> "sc-location", "sc-cache-control", and "sc-".  This=20
>>> deviates from the text in Section 4.5 that says "sc- is prefixed
>>> to keys for information to be passed by the Server (uCDN) to the=20
>>> Client (User Agent)."  I suggest you either change the keys to be=20
>>> "sc-" instead of "sc()", or change the text in=20
>>> Section 4.5 .
>=20
> The keys sc(location), sc(cache-control) and sc() are =
different to the other sc- keys because their values encode the values =
of HTTP headers, whereas the values of the other sc- keys encode =
information about the HTTP request/response that are not sent in HTTP =
headers (method, version, etc).
>=20
> [Actually sc(location) and sc(cache-control) aren't special but are =
specific instances of sc() called out as they are likely to =
be of particular interest for the use case of redirection between CDNs.]
>=20
> The thinking of putting the header name in () was to avoid possible =
clashes, e.g. if someone wanted to return a HTTP Header called "status" =
they wouldn't be able to do so because sc-status is already used for =
carrying the HTTP response's status code.
>=20
> The simple fix would be to change sc() to =
sc-() so we avoid any potential clash and the format of the =
key is aligned with section 4.5 that says they start sc- (and do the =
same for the cs- keys too).
>=20
>>> * In Section 4.7., it seems very odd that all of the error object=20
>>> keys are optional.  Is the intent really that the following is=20
>>> valid?
>>>=20
>>> "error": {}
>>>=20
>>> If it is, then an explanation of when and why that is valid would=20
>>> be very helpful to me.  Otherwise, I suggest mandating at least=20
>>> "error-code ".
>=20
> Good catch, will change so that error-code is mandatory.
>=20
>>> * In Section 5., I would strongly consider referring to=20
>>> draft-ietf-uta-tls-bcp (currently in the RFC Editor's Queue), and=20
>>> incorporating its recommendations.  I think this draft
>>> accomplishes the basics, but I think you get a more complete
>>> picture with -tls-bcp.
>=20
> There are some discussions ongoing in the CDNI WG on referencing =
draft-ietf-uta-tls-bcp instead of articulating specific requirements in =
each of the CDNI specifications and we plan to align =
draft-ietf-cdni-redirection with the CDNI WG consensus for that text, =
which looks likely to end up being a reference to =
draft-ietf-uta-tls-bcp.
>=20
>>>=20
>>> Nits:
>>>=20
>>> * The acronym CDN should be expanded in the Abstract.  Some might=20
>>> also argue it should be expanded in the title, but not me.
>=20
> Thanks, will expand.
>=20
>>> * The terms list in Section 2. is editorially a bit awkward to me;
>>> I expected there to be hanging indents.  In the XML, this can be=20
>>> accomplished by wrapping the new terms'  with >> style=3D'hanging'> and placing the attribute hangtext equal to the=20=

>>> term for each terms'  (e.g., >> Redirection:">The act of using an application ...)
>=20
> Thanks, will try this in the next revision.
>=20
> Ben
>=20
>>>=20
>>>=20
>>>=20
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
>> Comment: GPGTools - https://gpgtools.org
>>=20
>> iQEcBAEBCgAGBQJVLSOsAAoJEDWi+S0W7cO1fZ8H/0Ew+qOZGyMz5JnBiFgajGWA
>> JddcGDOKES3wSdO4rwnG0y+D9GRHz/3JYmhDalyo/8MvDSsxQ+Z8vDuN0AEk5dLV
>> QOe/4DR4T10v9z5ZPcwQSEXY3dYSJoXc7Je0f7gw4Dhnp1croQ4o+6Qo8+W7pGwt
>> 7jLzkeeKR8FJ9gPf5sQ0/zPBXf5Nhmgs9d/ZjbzuLVJOIpt77sr09dIwq8k30PaB
>> O3765+dgH0jRjgaZuu7VZU429/TwDE/uaffCG8UcBDXjh6j/7zEgHwTDIwTj+5Ed
>> 3onZ2bha/Q10vGUO7ooaj5jNNB2r1I/P9F4FSk8DMH7ioMP5KEI6e5Bml4z0/8U=3D
>> =3DoeMr
>> -----END PGP SIGNATURE-----
>>=20
>> _______________________________________________
>> apps-discuss mailing list
>> apps-discuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/apps-discuss
>=20


From nobody Thu Apr 23 08:17:40 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 380831A89C7 for ; Thu, 23 Apr 2015 08:17:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.301
X-Spam-Level: 
X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7VvG-s3Xw095 for ; Thu, 23 Apr 2015 08:17:38 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 601551A0382 for ; Thu, 23 Apr 2015 08:17:15 -0700 (PDT)
Received: from [192.168.1.87] (76-218-10-206.lightspeed.sntcca.sbcglobal.net [76.218.10.206]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t3NFHAAF023514 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 23 Apr 2015 08:17:14 -0700
Message-ID: <55390CF3.3000403@dcrocker.net>
Date: Thu, 23 Apr 2015 08:17:07 -0700
From: Dave Crocker 
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: John Levine , apps-discuss@ietf.org
References: <20150421021813.1597.qmail@ary.lan>
In-Reply-To: <20150421021813.1597.qmail@ary.lan>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Thu, 23 Apr 2015 08:17:14 -0700 (PDT)
Archived-At: 
Cc: dcrocker@bbiw.net
Subject: Re: [apps-discuss] List-ID vs. [list-id] (was Re: meta - removing list banner?)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Apr 2015 15:17:39 -0000

On 4/20/2015 7:18 PM, John Levine wrote:
> It's true -- Yahoo and Hotmail still can't sort on list-id.  Gmail
> can, I think most desktop MUAs can.


It isn't obvious to me how Thunderbird could sort on List-ID.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


From nobody Thu Apr 23 08:45:47 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF6E1ACD8A; Thu, 23 Apr 2015 08:45:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -13.611
X-Spam-Level: 
X-Spam-Status: No, score=-13.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_35=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SeSp16whxxX4; Thu, 23 Apr 2015 08:45:43 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4AEE1B30C6; Thu, 23 Apr 2015 08:45:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6160; q=dns/txt; s=iport; t=1429803901; x=1431013501; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=hJhQYxnb/nuKSEdTJ29vSas1HscKcau5HwGnJiARgUA=; b=GnDH6DDiV5iBZt/JRAFRvoHyMlMSognWH+z4flaZxQWkcA2TvhFwDDNf +xEztxWSBPrkEjpcpPXzuCn93pNq466p9XTKYHpFmPpqyDbrmvp0+l6ZR OAbosv0OVJXvQhyyGCnzvbUKjvFeqf+uSXjTjaU+ndkbodIwpy+1mY6uk 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BZBAApEjlV/5pdJa1bgwxSVwUFgxXDCgmBRwqGBAKBNjgUAQEBAQEBAYEKhCEBAQQBAQEgDwE7CgEQCxgCAgUWCwICCQMCAQIBFSAQBg0BBQIBAQWIIggFt3SUZgEBAQEBAQEBAQEBAQEBAQEBAQEBAReBIYoWhCERAQYYMweCaIFFBYtUg1aGIYY0gSKGFIpHg04jgWUhHYFwUAGBCjmBAAEBAQ
X-IronPort-AV: E=Sophos;i="5.11,631,1422921600"; d="scan'208";a="143923761"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-5.cisco.com with ESMTP; 23 Apr 2015 15:45:00 +0000
Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t3NFj0KA004724 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 Apr 2015 15:45:00 GMT
Received: from [64.101.72.55] (64.101.72.55) by xhc-aln-x12.cisco.com (173.36.12.86) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 23 Apr 2015 10:45:00 -0500
Message-ID: <5539137A.5090802@cisco.com>
Date: Thu, 23 Apr 2015 09:44:58 -0600
From: =?UTF-8?B?4oyYIE1hdHQgTWlsbGVy?= 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Ben Niven-Jenkins 
References: <552C3E12.50607@cisco.com> <552D23AC.7050703@cisco.com> <155E6729-DB7E-4934-B447-9A8D2D7A68C1@niven-jenkins.co.uk> 
In-Reply-To: 
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-Originating-IP: [64.101.72.55]
Archived-At: 
Cc: "" , cdni@ietf.org, IETF Apps Discuss 
Subject: Re: [apps-discuss] appsdir early review of draft-ietf-cdni-redirection
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 23 Apr 2015 15:45:45 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Thanks Ben.

All of your suggested changes below look good, and I'll review -09 as
my earliest chance.


- -- 
- - m&m

Matt Miller < mamille2@cisco.com >
Cisco Systems, Inc.

On 4/23/15 9:10 AM, Ben Niven-Jenkins wrote:
> Hi Matt,
> 
> Following up on my previous email, FYI I pushed out a -09 version
> of draft-ietf-cdni-redirection which I believe addresses all of
> your comments except the security considerations (which I will
> change once consensus is reached in the CDNI WG on appropriate
> text).
> 
> New draft here: 
> http://www.ietf.org/internet-drafts/draft-ietf-cdni-redirection-09.txt
>
>  Diff from -08 here: 
> http://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-redirection-09
> 
> 
> Ben
> 
> 
>> On 21 Apr 2015, at 17:02, Ben Niven-Jenkins
>>  wrote:
>> 
>> Hi Matt,
>> 
>> Thanks for the review, some responses inline.
>> 
>>> On 14 Apr 2015, at 15:26, ⌘ Matt Miller 
>>> wrote:
>>> 
> [ Resending to include apps-discuss ]
> 
>>>>> Minor Issues:
>>>>> 
>>>>> * In Section 4.2., some of the language about the JSON
>>>>> encoding correctness can be handled by conforming to I-JSON
>>>>> [RFC7493], which this draft already does in spirit.
>>> 
>>> I'm not sure it results in being able to remove much text from
>>> Section 4.2 because from a quick scan of RFC7493 the only
>>> overlap is both documents state the JSON object MUST NOT
>>> contain duplicate keys/names but I'm OK with adding a reference
>>> to I-JSON e.g.
>>> 
>>> OLD: The body of RI requests and responses is a JSON object
>>> [RFC7159] containing a dictionary of key:value pairs.
>>> 
>>> NEW: The body of RI requests and responses is a JSON object
>>> [RFC7159] that MUST conform to [RFC7493] containing a
>>> dictionary of key:value pairs.
>>> 
>>>>> * In Section 4.5.2., it's not clear why the keys
>>>>> "sc(location)", "sc(cache-control)", and "sc()"
>>>>> are different from the other "sc-"-based keys; I would have
>>>>> expected them to be "sc-location", "sc-cache-control", and
>>>>> "sc-".  This deviates from the text in Section
>>>>> 4.5 that says "sc- is prefixed to keys for information to
>>>>> be passed by the Server (uCDN) to the Client (User Agent)."
>>>>> I suggest you either change the keys to be "sc-"
>>>>> instead of "sc()", or change the text in Section 4.5
>>>>> .
>>> 
>>> The keys sc(location), sc(cache-control) and sc()
>>> are different to the other sc- keys because their values encode
>>> the values of HTTP headers, whereas the values of the other sc-
>>> keys encode information about the HTTP request/response that
>>> are not sent in HTTP headers (method, version, etc).
>>> 
>>> [Actually sc(location) and sc(cache-control) aren't special but
>>> are specific instances of sc() called out as they
>>> are likely to be of particular interest for the use case of
>>> redirection between CDNs.]
>>> 
>>> The thinking of putting the header name in () was to avoid
>>> possible clashes, e.g. if someone wanted to return a HTTP
>>> Header called "status" they wouldn't be able to do so because
>>> sc-status is already used for carrying the HTTP response's
>>> status code.
>>> 
>>> The simple fix would be to change sc() to
>>> sc-() so we avoid any potential clash and the
>>> format of the key is aligned with section 4.5 that says they
>>> start sc- (and do the same for the cs- keys too).
>>> 
>>>>> * In Section 4.7., it seems very odd that all of the error
>>>>> object keys are optional.  Is the intent really that the
>>>>> following is valid?
>>>>> 
>>>>> "error": {}
>>>>> 
>>>>> If it is, then an explanation of when and why that is valid
>>>>> would be very helpful to me.  Otherwise, I suggest
>>>>> mandating at least "error-code ".
>>> 
>>> Good catch, will change so that error-code is mandatory.
>>> 
>>>>> * In Section 5., I would strongly consider referring to 
>>>>> draft-ietf-uta-tls-bcp (currently in the RFC Editor's
>>>>> Queue), and incorporating its recommendations.  I think
>>>>> this draft accomplishes the basics, but I think you get a
>>>>> more complete picture with -tls-bcp.
>>> 
>>> There are some discussions ongoing in the CDNI WG on
>>> referencing draft-ietf-uta-tls-bcp instead of articulating
>>> specific requirements in each of the CDNI specifications and we
>>> plan to align draft-ietf-cdni-redirection with the CDNI WG
>>> consensus for that text, which looks likely to end up being a
>>> reference to draft-ietf-uta-tls-bcp.
>>> 
>>>>> 
>>>>> Nits:
>>>>> 
>>>>> * The acronym CDN should be expanded in the Abstract.  Some
>>>>> might also argue it should be expanded in the title, but
>>>>> not me.
>>> 
>>> Thanks, will expand.
>>> 
>>>>> * The terms list in Section 2. is editorially a bit awkward
>>>>> to me; I expected there to be hanging indents.  In the XML,
>>>>> this can be accomplished by wrapping the new terms' 
>>>>> with  and placing the attribute
>>>>> hangtext equal to the term for each terms'  (e.g., >>>> hangtext="Application Level Redirection:">The act of using
>>>>> an application ...)
>>> 
>>> Thanks, will try this in the next revision.
>>> 
>>> Ben
>>> 
>>>>> 
>>>>> 
>>>>> 
>>> 
>>> _______________________________________________ apps-discuss
>>> mailing list apps-discuss@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/apps-discuss
>> 
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJVORN6AAoJEDWi+S0W7cO1vlcH/1QZa7dkCjK0LIvHV1rvxQGr
MIcXoZAOf1xFHHAYjof+7YBWpvT5W1zIVfJ7ai1Bw8LD0x+1uRh3GiitaITx3Zfa
5cD10WQ0BWaEPbVM1XkZlUdt//Bln9dLsmLpOEnVICxMJzK+0tMCMV6leqrzP7Qt
4kqkf59gfKt8qU20DkcUvgGFQ+F4/yuX9rn/bbX+jHVKTKihyAC2BTu2Xb1hWFjP
cjyvhFnp4AdcmIumzQYQBrLmVh9vzoMgoL0QwYlqLix4rVVNz/SIa8ETGnelceSN
VC95/rqSyLAI9WDDUU0g+p9MxWjnChKAHD0lxbKYOLJP7wZj3xoCcFCHfQI/gXk=
=Wfdi
-----END PGP SIGNATURE-----


From nobody Thu Apr 23 13:23:20 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FBCF1B32EC for ; Thu, 23 Apr 2015 13:23:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.388
X-Spam-Level: 
X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YgTm50Tx0ZI0 for ; Thu, 23 Apr 2015 13:23:18 -0700 (PDT)
Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FA851B32F0 for ; Thu, 23 Apr 2015 13:23:13 -0700 (PDT)
Received: by oica37 with SMTP id a37so24377653oic.0 for ; Thu, 23 Apr 2015 13:23:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nlUDKsnrNfm+c8fEfxneBlVXauDBG5F14FU3XvsHStE=; b=CQ/hxsJ01sKaEFq5rkViTSkGPHLfosFV1SXC53v08lKWLJpx9AcsF9R9SnIjqulJwu yduZ+K5RT8xXMW2Y+uswo4iKdFodDriHqWAOqWEpVzlaDmajV8guIH5BQee+Kyd4Yd4k fqwrHfcU6d1JaKDx65cR3zCmfLSsv3Pw6TpZe7MxwLTC6kJ5MqT14uiecnU+JW7Hsse7 golqSP3vOMD7lo8B8K5ecTZWZPXc4svViSSaQ6ayA30xrLAUyC49Bu5s+Hzln3dkmSsY e/YkWiMT1yAkYPUP+s3KxpieXgM2Nhar7PiQblPRnt6XJh5QzI46CON/N1+agmpxuGLE UU7A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=nlUDKsnrNfm+c8fEfxneBlVXauDBG5F14FU3XvsHStE=; b=gY9eZVcwt3Lep4TbQ4xouDcbgD6k/i4RZ9+z/IUV+JQ+iRDt2N2q/ehsQyDaj5YIzd 0qtA1JQTqNLWCRf1+/sgbifCRKbj8lnb4Io0h9NLqF542lyIda9zyEOd3vsfa2609vkf 5tiVzdsFaI3dfio1eRGoxU/ycXbTfnyGaybvSNiqculu21ZR3t4OCVMqlIlgA/EOnZ4U tTEOuYvZxLkg/w5CH1jtGemTtSgJuAAg2DJYzvUay7duyqdUB18EhujKeWoQ982oORwt sf6siU2Jsp8u0Sw70OISiop0VcNznLs7vN4aI9er4kLNpWY0xnm/qf1etaGkume3t+DK BKCw==
X-Gm-Message-State: ALoCoQlP9F4+dUuqxojgVA9heePyUfT2EMKCihn5g1TKYhrVvSA2Nth/MUSCVdxN6TBt/bPGu/FP
MIME-Version: 1.0
X-Received: by 10.60.149.166 with SMTP id ub6mr4246468oeb.41.1429820592974; Thu, 23 Apr 2015 13:23:12 -0700 (PDT)
Received: by 10.182.108.7 with HTTP; Thu, 23 Apr 2015 13:23:12 -0700 (PDT)
In-Reply-To: <55390CF3.3000403@dcrocker.net>
References: <20150421021813.1597.qmail@ary.lan> <55390CF3.3000403@dcrocker.net>
Date: Thu, 23 Apr 2015 13:23:12 -0700
Message-ID: 
From: Brandon Long 
To: dcrocker@bbiw.net
Content-Type: multipart/alternative; boundary=e89a8f64272c89a34705146a0ce6
Archived-At: 
Cc: John Levine , apps-discuss@ietf.org
Subject: Re: [apps-discuss] List-ID vs. [list-id] (was Re: meta - removing list banner?)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 23 Apr 2015 20:23:19 -0000

--e89a8f64272c89a34705146a0ce6
Content-Type: text/plain; charset=UTF-8

Do you mean search?  I don't think Gmail sorts on anything except received
date.  We do have the list: and listid: operators, however.

Brandon

On Thu, Apr 23, 2015 at 8:17 AM, Dave Crocker  wrote:

> On 4/20/2015 7:18 PM, John Levine wrote:
> > It's true -- Yahoo and Hotmail still can't sort on list-id.  Gmail
> > can, I think most desktop MUAs can.
>
>
> It isn't obvious to me how Thunderbird could sort on List-ID.
>
> d/
>
> --
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

--e89a8f64272c89a34705146a0ce6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Do you mean search?=C2=A0 I don't think Gmail sorts on=
 anything except received date.=C2=A0 We do have the list: and listid: oper=
ators, however.

Brandon

On Thu, Apr 23, 2015 at 8:17 AM, Dave =
Crocker <dhc@dcrocker.net> wrote:
On 4/20/2015 7:18 PM, John Levine wrote:

> It's true -- Yahoo and Hotmail still can't sort on list-id.=C2=
=A0 Gmail

> can, I think most desktop MUAs can.





It isn't obvious to me how Thunderbird could sort on List-ID.


d/



--

Dave Crocker

Brandenburg InternetWorking

bbiw.net




____________________________=
___________________

apps-discuss mailing list

apps-discuss@ietf.org

https://www.ietf.org/mailman/listinfo/apps-discuss





--e89a8f64272c89a34705146a0ce6--


From nobody Thu Apr 23 13:29:09 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2C6A1B3327 for ; Thu, 23 Apr 2015 13:29:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhIgwou0BGJD for ; Thu, 23 Apr 2015 13:29:06 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E28F91B332A for ; Thu, 23 Apr 2015 13:28:57 -0700 (PDT)
Received: from [192.168.1.87] (76-218-10-206.lightspeed.sntcca.sbcglobal.net [76.218.10.206]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t3NKSoJb032411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 23 Apr 2015 13:28:54 -0700
Message-ID: <553955FB.8020504@dcrocker.net>
Date: Thu, 23 Apr 2015 13:28:43 -0700
From: Dave Crocker 
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Brandon Long 
References: <20150421021813.1597.qmail@ary.lan> <55390CF3.3000403@dcrocker.net> 
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Thu, 23 Apr 2015 13:28:54 -0700 (PDT)
Archived-At: 
Cc: John Levine , apps-discuss@ietf.org
Subject: Re: [apps-discuss] List-ID vs. [list-id] (was Re: meta - removing list banner?)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Apr 2015 20:29:07 -0000

I am used to considering the column-sort of a folder summary display as
being a 'sort', and rules for moving/copying to different folders as
being 'filtering'.  Search is a third function, whether within or across
folders.

It is common for MUAs to permit clicking on the column label, to have it
serve as the primary sort key.

d/

On 4/23/2015 1:23 PM, Brandon Long wrote:
> Do you mean search?  I don't think Gmail sorts on anything except
> received date.  We do have the list: and listid: operators, however.
> 
> Brandon
> 
> On Thu, Apr 23, 2015 at 8:17 AM, Dave Crocker  > wrote:
> 
>     On 4/20/2015 7:18 PM, John Levine wrote:
>     > It's true -- Yahoo and Hotmail still can't sort on list-id.  Gmail
>     > can, I think most desktop MUAs can.
> 
> 
>     It isn't obvious to me how Thunderbird could sort on List-ID.


-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


From nobody Thu Apr 23 14:11:21 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 698091B346E for ; Thu, 23 Apr 2015 14:11:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.137
X-Spam-Level: 
X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Dx7WD-83p3A for ; Thu, 23 Apr 2015 14:11:17 -0700 (PDT)
Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B35F1B2AA0 for ; Thu, 23 Apr 2015 14:11:07 -0700 (PDT)
Received: (qmail 4911 invoked from network); 23 Apr 2015 21:11:06 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=132e.55395fea.k1504; bh=vjFTFSWpVQb3ZeDFLjdw+hMdtdGYZLAs0RN0j5lcoL4=; b=J3VpexHUZ/i+oSUPQpPQ2r4T9Qoct8gEs+YcfpRT2djDgwGvseh3lAox9pE5WR260OgPGKIi3vWR6flOQPGR4cuz/59Mhph/cvHpFap1Qotz+nNkmSuyE3l8pGKZUjprk8Enll3lC9svbUfx5fNtcsi5b7K+9/IRpd960L1dmVD5Y2NLbGx6tQfT9/pPn9GJTsB1wJVn/RyybQDhpHjvbvv9yqLTcLjKlO1l5Esn8sr+aQ/f4UpoqkUdviqHdZgz
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=132e.55395fea.k1504; bh=vjFTFSWpVQb3ZeDFLjdw+hMdtdGYZLAs0RN0j5lcoL4=; b=wZxYWhyGSxLk8q2NM9kYVl/UB+ryLBKnTYbgv6ZRMp7X6wwAboEP52KebnPHyeT/WX0fYQzr3X5aH2MdSt5G8MAt08be8Zlzc0AGGZPNqRJfZ8TUYE2PEG47NN89Y1CjB1RLmbUNVzrkTJ5N3LZsBRDOUPAbPGuTUujmoonlDE8RDL1NVzWccF/UIL3qjumfn8tDcNVSy5tpnuIJSJODLq0CogdfoV7TpMg139daviRnzo40+lv42vMWpYbDvxfL
Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 23 Apr 2015 21:11:06 -0000
Date: 23 Apr 2015 17:11:05 -0400
Message-ID: 
From: "John R Levine" 
To: "Brandon Long" 
In-Reply-To: 
References: <20150421021813.1597.qmail@ary.lan> <55390CF3.3000403@dcrocker.net> 
User-Agent: Alpine 2.11 (OSX 23 2013-08-11)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
Archived-At: 
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] List-ID vs. [list-id] (was Re: meta - removing list banner?)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 23 Apr 2015 21:11:19 -0000

> Do you mean search?  I don't think Gmail sorts on anything except received
> date.  We do have the list: and listid: operators, however.

I was using sort in the usual (among people who use procmail and similar 
tools) sense of putting it into folders or the like, what Dave calls 
filtering.

Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.


From nobody Sat Apr 25 00:21:32 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DD291B2AEF for ; Sat, 25 Apr 2015 00:21:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nNI1eE6kxOGz for ; Sat, 25 Apr 2015 00:21:30 -0700 (PDT)
Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D52B01B2AEA for ; Sat, 25 Apr 2015 00:21:29 -0700 (PDT)
Received: by igbyr2 with SMTP id yr2so31350456igb.0 for ; Sat, 25 Apr 2015 00:21:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:date:message-id:subject:from:to:content-type; bh=ip5W38qUr8K1l8Z2zyFeKHK60I2jI2kRlekqGHfwjRo=; b=bg9b/mcT9MJfRVgjSuZnkvxU42RFAvuvWrnV8OlpNsFIGqul2rz0/0N6g4Hk/17Tvz HYoUrfmzQRoqoG2WcLX4zZCuYblQ7GMG6GmzDLo1aqVwXf2FpDs46mc27qpH92rsH+tj FEmwWZeuRAcwF3/NmMzGebTtLjwAmLKazAintQaGHpbFZRVoaq3kZtyiIGiiY0X9sDxj OFy65jVVK7/NoHW3oIIKwvW9nHT1hwzoYBHRyXWvH3nkGC1QUdejoB4IEbhbzRN/HCK8 lJqDUkXgorzbLE2I7BA74iA0/GrgxwruIApDlm5yVk6prc0FaUhzg58QtcwZQczr0mi+ GcaA==
MIME-Version: 1.0
X-Received: by 10.42.207.206 with SMTP id fz14mr2845218icb.34.1429946489042; Sat, 25 Apr 2015 00:21:29 -0700 (PDT)
Received: by 10.107.12.4 with HTTP; Sat, 25 Apr 2015 00:21:22 -0700 (PDT)
Date: Sat, 25 Apr 2015 03:21:22 -0400
Message-ID: 
From: Nick Matavka 
To: apps-discuss@ietf.org
Content-Type: multipart/alternative; boundary=20cf30426df68700510514875c6b
Archived-At: 
Subject: [apps-discuss] independent submission process for draft-matavka-gopher-ii
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 25 Apr 2015 07:21:31 -0000

--20cf30426df68700510514875c6b
Content-Type: text/plain; charset=UTF-8

Hello, world!

I sent off an independent submission as a proposed standard, in regards to
extensions to the Gopher WWIS.  Although the current iteration of the
Gopher protocol is half-Informational and half-unofficial memo (by which I
mean the optional Gopher+ extensions), it was recommended to me that I put
my draft on the Standards Track.  I'm not opposed to this idea, which is
why draft-matavka-gopher-ii is currently sitting on IETF servers on said
Standards Track.

My concerns are mostly related to IETF process.  How are independent
submissions handled?  Am I supposed to receive an eMail from one of the
review people stating the nits that need to be corrected?  The structure is
fine, I'm now curious as to how an Internet-Draft becomes a Standard.  I'm
also curious as to how ongoing fixes are incorporated.  For instance, the
informal workgroup that discusses Gopher is now floating the idea of Gopher
over TLS, and they have reached the consensus that GopherS (as they have
called it) would be a beneficial, but optional, part of the Gopher system.
Perhaps a footnote to that effect would fit in the Internet-Draft, but I'm
not sure how 00 becomes 01 and 02 and 03.

Anyway, any help you could give me is appreciated.

Edward Matavka



-- 
       /^\/^\
       \----|
   _---'---~~~~-_
    ~~~|~~L~|~~~~
       (/_  /~~--
     \~ \  /  /~
   __~\  ~ /   ~~----,
   \    | |       /  \
   /|   |/       |    |
   | | | o  o     /~   |
 _-~_  |        ||  \  /
(// )) | o  o    \\---'
//_- |  |          \
//   |____|\______\__\
~      |   / |    |
       |_ /   \ _|
     /~___|  /____\

--20cf30426df68700510514875c6b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hello, world!

I sent off an independent=
 submission as a proposed standard, in regards to extensions to the Gopher =
WWIS.=C2=A0 Although the current iteration of the Gopher protocol is half-I=
nformational and half-unofficial memo (by which I mean the optional Gopher+=
 extensions), it was recommended to me that I put my draft on the Standards=
 Track.=C2=A0 I'm not opposed to this idea, which is why=C2=A0draft-mat=
avka-gopher-ii is currently sitting on IETF servers on said Standards Track=
.

My concerns are mostly related to IETF process.=
=C2=A0 How are independent submissions handled?=C2=A0 Am I supposed to rece=
ive an eMail from one of the review people stating the nits that need to be=
 corrected?=C2=A0 The structure is fine, I'm now curious as to how an I=
nternet-Draft becomes a Standard.=C2=A0 I'm also curious as to how ongo=
ing fixes are incorporated.=C2=A0 For instance, the informal workgroup that=
 discusses Gopher is now floating the idea of Gopher over TLS, and they hav=
e reached the consensus that GopherS (as they have called it) would be a be=
neficial, but optional, part of the Gopher system.=C2=A0 Perhaps a footnote=
 to that effect would fit in the Internet-Draft, but I'm not sure how 0=
0 becomes 01 and 02 and 03.

Anyway, any help you c=
ould give me is appreciated. =C2=A0

Edward Matavka=




-- 
 =C2=A0 =C2=A0 =C2=A0 =C2=A0/^\/^\
 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0\----|
 =C2=A0 =C2=A0_---'---~~~~-_ =C2=A0
 =C2=A0 =
=C2=A0 ~~~|~~L~|~~~~
 =C2=A0 =C2=A0 =C2=A0 =C2=A0(/_ =C2=A0/~~--
 =C2=
=A0 =C2=A0 =C2=A0\~ \ =C2=A0/ =C2=A0/~
 =C2=A0 =C2=A0__~\ =C2=A0~ / =C2=
=A0 ~~----,
 =C2=A0 =C2=A0\ =C2=A0 =C2=A0| | =C2=A0 =C2=A0 =C2=A0 / =C2=
=A0\ =C2=A0
 =C2=A0 =C2=A0/| =C2=A0 |/ =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=
=A0|
 =C2=A0 =C2=A0| | | o =C2=A0o =C2=A0 =C2=A0 /~ =C2=A0 | =C2=A0
 =
=C2=A0_-~_ =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0|| =C2=A0\ =C2=A0/
 (// ))=
 | o =C2=A0o =C2=A0 =C2=A0\\---'
 //_- | =C2=A0| =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0\ 
// =C2=A0 |____|\______\__\
~ =C2=A0 =C2=A0 =C2=
=A0| =C2=A0 / | =C2=A0 =C2=A0|
 =C2=A0 =C2=A0 =C2=A0 =C2=A0|_ / =C2=A0 \=
 _|
 =C2=A0 =C2=A0 =C2=A0/~___| =C2=A0/____\ =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 




--20cf30426df68700510514875c6b--


From nobody Sat Apr 25 05:32:51 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 618621A6EE2 for ; Sat, 25 Apr 2015 05:32:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.301
X-Spam-Level: 
X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AO18Uoea_5iH for ; Sat, 25 Apr 2015 05:32:47 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 812881A6EDA for ; Sat, 25 Apr 2015 05:32:47 -0700 (PDT)
Received: from [192.168.1.87] (76-218-10-206.lightspeed.sntcca.sbcglobal.net [76.218.10.206]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t3PCWhZ1032164 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Sat, 25 Apr 2015 05:32:47 -0700
Message-ID: <553B8967.80601@dcrocker.net>
Date: Sat, 25 Apr 2015 05:32:39 -0700
From: Dave Crocker 
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: "apps-discuss@ietf.org" 
References: <20150421021813.1597.qmail@ary.lan> <55390CF3.3000403@dcrocker.net>  
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Sat, 25 Apr 2015 05:32:47 -0700 (PDT)
Archived-At: 
Subject: Re: [apps-discuss] List-ID vs. [list-id] (was Re: meta - removing list banner?)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: General discussion of application-layer protocols 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 25 Apr 2015 12:32:50 -0000

>> Do you mean search?  I don't think Gmail sorts on anything except
>> received
>> date.  We do have the list: and listid: operators, however.
> 
> I was using sort in the usual (among people who use procmail and similar
> tools) sense of putting it into folders or the like, what Dave calls
> filtering.

     The essential semantic point, for this thread, is that email
software often has a convenient column-based mechanism for arranging the
order of messages seen in the summary message list.  Clicking on a
column makes it the primary key for organizing messages.  This is
extremely convenient and useful.

     Having the [list-id] convention at the beginning of the Subject
line permits easy organizing of messages in a folder, according to
mailing list.  Losing that capability would be a significant downgrade
in utility.

     For clarity, I suggest distinguishing this 'within folder' sorting
from any mechanism that puts messages into folders, tabs, or the like.


As for terminology...

Gmail uses the 'sort' term the way John is, but note it also uses
'filtering' (see below):

     "sorts messages into categories, or “tabs.”


Yahoo, Earthlink, Thunderbird, Outlook use the term the way I do (and
the way the dictionary does):

      "You can sort your messages based on different kinds of
information: the date you received them, who you received them from, or
their subject. You can sort messages in a couple of ways: using the
Actions menu or using the column headers."

     "Reading and Sorting Messages -- You can change the order by
clicking one of the column titles at the top of the message list."

     "Sort Mail by the Order It Was Received in Mozilla Thunderbird"

     "So if you wanted to sort all mail by Thread, Descending (newest at
top), the preferences in the config editor will look like this"

     "Click to sort"


And I didn't invent the usage 'filtering'. Eg, Thunderbird, Wikipedia,
Gmail:

     "Organize Your Messages by Using Filters"

     "Email filtering is the processing of email to organize it
according to specified criteria."

     "Using filters, you can automatically send email to a label,
archive, delete,"


d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


From nobody Sat Apr 25 07:03:53 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90D5E1B2CB3 for ; Sat, 25 Apr 2015 07:03:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level: 
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v7exrsZHMKqe for ; Sat, 25 Apr 2015 07:03:49 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0C7E1B2CB2 for ; Sat, 25 Apr 2015 07:03:49 -0700 (PDT)
Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Ym0gO-0000bn-68; Sat, 25 Apr 2015 10:03:48 -0400
Date: Sat, 25 Apr 2015 10:03:43 -0400
From: John C Klensin 
To: Nick Matavka 
Message-ID: <7EBB46C3F03620A468C8101C@JcK-HP8200.jck.com>
In-Reply-To: 
References: 
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.35
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: 
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] independent submission process for	draft-matavka-gopher-ii
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 25 Apr 2015 14:03:51 -0000

Nick,

It appears that circumstances have created a good deal of
confusion here.  I'll try to clarify as much as I can inline
below.  I believe everything not identified as "personal
opinion" or the equivalent below accurately reflects IETF and
RFC Editor procedures and processing rules. 

--On Saturday, April 25, 2015 03:21 -0400 Nick Matavka
 wrote:

>...
> I sent off an independent submission as a proposed standard,

First, I know this is confusing, but, to keep the confusion from
getting worse, note that there are "independent submissions"
that go through one review process (via the Independent
Submission Editor) and "individual submissions" which are
processed via the IETF Stream.   There is no such thing as an
"independent submission as proposed standard" because only the
IETF Stream can process standards track documents.

> in regards to extensions to the Gopher WWIS.  Although the
> current iteration of the Gopher protocol is half-Informational
> and half-unofficial memo (by which I mean the optional Gopher+
> extensions), it was recommended to me that I put my draft on
> the Standards Track.

I'm not sure what you mean by "half-unofficial" because I have
no idea, in either the Independent Submission or IETF streams,
what an "official memo" would be.  Personal opinion: bad advice
(see below) or a misunderstanding.

> I'm not opposed to this idea, which is
> why draft-matavka-gopher-ii is currently sitting on IETF
> servers on said Standards Track.

I don't even know what that means, unless you are just referring
to a "proposed status" line in the Internet Draft.

> My concerns are mostly related to IETF process.  How are
> independent submissions handled?  Am I supposed to receive an
> eMail from one of the review people stating the nits that need
> to be corrected?  The structure is fine, I'm now curious as to
> how an Internet-Draft becomes a Standard.

To save you more time, I'll review the two options separately
and add a third.

(i) For an individual submission of a standards track document,
you need to get an AD to sign up to "sponsor" it, i.e., to take
the lead in moving the document through the system.  It is not
clear to me, especially after the Area reorganization started,
who the best candidate would be, but I think it would be
reasonable for you to send an inquiry to iesg@ietf.org and hope
someone responds.  If any of the current ADs have expressed
interest, I'd start with a discussion with him or her.

Personal opinion: Unless you can find a sponsoring AD would is
_really_ committed to the document and/or to you and your
situation, successfully getting a document processed in this way
is likely to be time-consuming and painful for anyone without a
lot of IETF experience.   It may be worth noting that efforts to
get FTP updates and extensions processed onto the standards
track have rarely gotten significant traction and, whatever the
other relationships may be, FTP has a much longer standards
history and is far more widely deployed than gopher.

(ii) For an independent submission, remove anything "standards
track" from the document and send a note to ise@rfc-editor.org
indicating that you would like to submit the document and asking
for instructions as to how to proceed.

(iii) The third possibility is to ask the Applications Area WG,
via this list and/or a note to the chairs, to take this on and
process it as a standards track document.  I don't know if you
can get that agreement, but, if you can, it would provide you
with much more help and support with standards track mechanisms
than the individual submission approach would.

>  I'm also curious as
> to how ongoing fixes are incorporated.  For instance, the
> informal workgroup that discusses Gopher is now floating the
> idea of Gopher over TLS, and they have reached the consensus
> that GopherS (as they have called it) would be a beneficial,
> but optional, part of the Gopher system. Perhaps a footnote to
> that effect would fit in the Internet-Draft, but I'm not sure
> how 00 becomes 01 and 02 and 03.

As long as this is an individual or independent submission, you
are free to modify the I-D in any way that you find appropriate.
Discussions, perhaps in an appendix, of what changes were made
and, if it is not obvious, why, can be a great help to readers
but there are no specific requirements.  There is no provision
in the Internet-Draft format for footnotes although some of us
have devised variation on endnotes on occasion.

Note that, as far as IETF Standards Track is concerned, there is
no such thing as an "informal workgroup" or consensus within it.
It is just you and some of your friends making an individual
submission or trying to either form an IETF WG (a fourth option
deliberately omitted above) or getting an existing WG to take
the work on.

> Anyway, any help you could give me is appreciated.

Personal opinion/recommendation: put a solid document together
that describes what has actually been implemented, deployed, and
put into non-trivial use.   If you want to speculate about
changes that should be made, do that, but treat it is
speculation and maybe put it in an appendix.  Keep it
descriptive rather than making normative and/or conformance
statements.  Hand that off to the Independent Submission Editor
and get it reviewed and published as a baseline.  Once you have
accomplished that, you will have an informative document for the
community and a better baseline for future work than the 20+
year old (and also Informational) spec in RFC 1436.  Because
1436 was Informational, nothing prevents your new document from
updating it or, if it is complete enough, obsoleting it, and you
should specify one or the other unless the ISE recommends
otherwise.  Then, if you want to, develop an IETF-stream,
standards track, normative document that specifies, e.g.,
interoperability requirements and applicability for modern
Gopher.   

Others may disagree with that strategy.  In particular, I hope
the people on this list who were more closely involved with
Gopher development and deployment in the 1990s than I was (i.e.,
more than zero) would at least comment and possibly offer
support and guidance.

     john


From nobody Sat Apr 25 15:15:54 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E7011A1B67 for ; Sat, 25 Apr 2015 15:15:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fk3GRIDQNmkh for ; Sat, 25 Apr 2015 15:15:47 -0700 (PDT)
Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1B661B30BF for ; Sat, 25 Apr 2015 15:15:46 -0700 (PDT)
Received: by iecrt8 with SMTP id rt8so104908055iec.0 for ; Sat, 25 Apr 2015 15:15:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:content-type:message-id:mime-version:subject:date:references :to:in-reply-to; bh=xI9tkfe6p6YiAeFNvJRAeC2ptTK5g79XBnWIqLYdThg=; b=xJHj/KUBbyezRtki2mqEV9sLpGlEUGO/tRlFQ+ru6z6Tfaoyes24GMd9dgjQ6r0EcN gJrzpzrSX3aHk+LwZXnxgd7Vr82qeqMhwuv48+WL3Q24hAuqaqd89T05WghjFdHvqXYN fjoX4wmRzKOb4Q/kV1gUg3pLuFeLIBoaS4t8e/WgQUNJAAAFW8dEuLXYpAb7XkCzxxO/ 2Ykg03FhzQpf5Sz+WdMwKiYttkqsiF4gtRAUAXP8MxsUS/ucfacEB54Pn+xGyjc6A/V6 c75eyOPrLOdQcc7ZQGRP+O+GYFkSYnahmdQGPdr9DmJ5XFWqyEdGy4S4F/0i8S26x5ee G8PA==
X-Received: by 10.43.171.70 with SMTP id nt6mr5305971icc.73.1430000146441; Sat, 25 Apr 2015 15:15:46 -0700 (PDT)
Received: from [192.168.1.13] (dsl-173-206-101-76.tor.primus.ca. [173.206.101.76]) by mx.google.com with ESMTPSA id k37sm9800337iod.39.2015.04.25.15.15.44 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 25 Apr 2015 15:15:45 -0700 (PDT)
From: Nick Matavka 
Content-Type: multipart/alternative; boundary="Apple-Mail=_63838739-D61C-4EA6-8D47-9DA19789DACA"
Message-Id: <3C78D500-2389-4234-B0BD-0B4690A45EB9@gmail.com>
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
Date: Sat, 25 Apr 2015 18:15:42 -0400
References: 
To: apps-discuss@ietf.org
In-Reply-To: 
X-Mailer: Apple Mail (2.2070.6)
Archived-At: 
Subject: Re: [apps-discuss] apps-discuss Digest, Vol 87, Issue 51
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 25 Apr 2015 22:15:53 -0000

--Apple-Mail=_63838739-D61C-4EA6-8D47-9DA19789DACA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


> On Apr 25, 2015, at 3:00 PM, apps-discuss-request@ietf.org wrote:
>=20
> Send apps-discuss mailing list submissions to
> 	apps-discuss@ietf.org
>=20
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://www.ietf.org/mailman/listinfo/apps-discuss
> or, via email, send a message with subject or body 'help' to
> 	apps-discuss-request@ietf.org
>=20
> You can reach the person managing the list at
> 	apps-discuss-owner@ietf.org
>=20
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of apps-discuss digest..."
>=20
>=20
> Today's Topics:
>=20
>   1.  independent submission process for	draft-matavka-gopher-ii
>      (Nick Matavka)
>   2. Re:  List-ID vs. [list-id] (was Re: meta - removing list
>      banner?) (Dave Crocker)
>   3. Re:  independent submission process for
>      draft-matavka-gopher-ii (John C Klensin)
>=20
>=20
> ----------------------------------------------------------------------
>=20
> Message: 1
> Date: Sat, 25 Apr 2015 03:21:22 -0400
> From: Nick Matavka 
> To: apps-discuss@ietf.org
> Subject: [apps-discuss] independent submission process for
> 	draft-matavka-gopher-ii
> Message-ID:
> 	=

> Content-Type: text/plain; charset=3D"utf-8"
>=20
> Hello, world!
>=20
> I sent off an independent submission as a proposed standard, in =
regards to
> extensions to the Gopher WWIS.  Although the current iteration of the
> Gopher protocol is half-Informational and half-unofficial memo (by =
which I
> mean the optional Gopher+ extensions), it was recommended to me that I =
put
> my draft on the Standards Track.  I'm not opposed to this idea, which =
is
> why draft-matavka-gopher-ii is currently sitting on IETF servers on =
said
> Standards Track.
>=20
> My concerns are mostly related to IETF process.  How are independent
> submissions handled?  Am I supposed to receive an eMail from one of =
the
> review people stating the nits that need to be corrected?  The =
structure is
> fine, I'm now curious as to how an Internet-Draft becomes a Standard.  =
I'm
> also curious as to how ongoing fixes are incorporated.  For instance, =
the
> informal workgroup that discusses Gopher is now floating the idea of =
Gopher
> over TLS, and they have reached the consensus that GopherS (as they =
have
> called it) would be a beneficial, but optional, part of the Gopher =
system.
> Perhaps a footnote to that effect would fit in the Internet-Draft, but =
I'm
> not sure how 00 becomes 01 and 02 and 03.
>=20
> Anyway, any help you could give me is appreciated.
>=20
> Edward Matavka
>=20
>=20
>=20
> --=20
>       /^\/^\
>       \----|
>   _---'---~~~~-_
>    ~~~|~~L~|~~~~
>       (/_  /~~--
>     \~ \  /  /~
>   __~\  ~ /   ~~----,
>   \    | |       /  \
>   /|   |/       |    |
>   | | | o  o     /~   |
> _-~_  |        ||  \  /
> (// )) | o  o    \\---'
> //_- |  |          \
> //   |____|\______\__\
> ~      |   / |    |
>       |_ /   \ _|
>     /~___|  /____\
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: =

>=20
> ------------------------------
>=20
> Message: 2
> Date: Sat, 25 Apr 2015 05:32:39 -0700
> From: Dave Crocker 
> To: "apps-discuss@ietf.org" 
> Subject: Re: [apps-discuss] List-ID vs. [list-id] (was Re: meta -
> 	removing list banner?)
> Message-ID: <553B8967.80601@dcrocker.net>
> Content-Type: text/plain; charset=3Dutf-8
>=20
>=20
>>> Do you mean search?  I don't think Gmail sorts on anything except
>>> received
>>> date.  We do have the list: and listid: operators, however.
>>=20
>> I was using sort in the usual (among people who use procmail and =
similar
>> tools) sense of putting it into folders or the like, what Dave calls
>> filtering.
>=20
>     The essential semantic point, for this thread, is that email
> software often has a convenient column-based mechanism for arranging =
the
> order of messages seen in the summary message list.  Clicking on a
> column makes it the primary key for organizing messages.  This is
> extremely convenient and useful.
>=20
>     Having the [list-id] convention at the beginning of the Subject
> line permits easy organizing of messages in a folder, according to
> mailing list.  Losing that capability would be a significant downgrade
> in utility.
>=20
>     For clarity, I suggest distinguishing this 'within folder' sorting
> from any mechanism that puts messages into folders, tabs, or the like.
>=20
>=20
> As for terminology...
>=20
> Gmail uses the 'sort' term the way John is, but note it also uses
> 'filtering' (see below):
>=20
>     "sorts messages into categories, or ?tabs.?
>=20
>=20
> Yahoo, Earthlink, Thunderbird, Outlook use the term the way I do (and
> the way the dictionary does):
>=20
>      "You can sort your messages based on different kinds of
> information: the date you received them, who you received them from, =
or
> their subject. You can sort messages in a couple of ways: using the
> Actions menu or using the column headers."
>=20
>     "Reading and Sorting Messages -- You can change the order by
> clicking one of the column titles at the top of the message list."
>=20
>     "Sort Mail by the Order It Was Received in Mozilla Thunderbird"
>=20
>     "So if you wanted to sort all mail by Thread, Descending (newest =
at
> top), the preferences in the config editor will look like this"
>=20
>     "Click to sort"
>=20
>=20
> And I didn't invent the usage 'filtering'. Eg, Thunderbird, Wikipedia,
> Gmail:
>=20
>     "Organize Your Messages by Using Filters"
>=20
>     "Email filtering is the processing of email to organize it
> according to specified criteria."
>=20
>     "Using filters, you can automatically send email to a label,
> archive, delete,"
>=20
>=20
> d/
> --=20
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net
>=20
>=20
>=20
> ------------------------------
>=20
> Message: 3
> Date: Sat, 25 Apr 2015 10:03:43 -0400
> From: John C Klensin 
> To: Nick Matavka 
> Cc: apps-discuss@ietf.org
> Subject: Re: [apps-discuss] independent submission process for
> 	draft-matavka-gopher-ii
> Message-ID: <7EBB46C3F03620A468C8101C@JcK-HP8200.jck.com>
> Content-Type: text/plain; charset=3Dus-ascii
>=20
> Nick,
>=20
> It appears that circumstances have created a good deal of
> confusion here.  I'll try to clarify as much as I can inline
> below.  I believe everything not identified as "personal
> opinion" or the equivalent below accurately reflects IETF and
> RFC Editor procedures and processing rules.=20
>=20
> --On Saturday, April 25, 2015 03:21 -0400 Nick Matavka
>  wrote:
>=20
>> ...
>> I sent off an independent submission as a proposed standard,
>=20
> First, I know this is confusing, but, to keep the confusion from
> getting worse, note that there are "independent submissions"
> that go through one review process (via the Independent
> Submission Editor) and "individual submissions" which are
> processed via the IETF Stream.   There is no such thing as an
> "independent submission as proposed standard" because only the
> IETF Stream can process standards track documents.
>=20
>> in regards to extensions to the Gopher WWIS.  Although the
>> current iteration of the Gopher protocol is half-Informational
>> and half-unofficial memo (by which I mean the optional Gopher+
>> extensions), it was recommended to me that I put my draft on
>> the Standards Track.
>=20
> I'm not sure what you mean by "half-unofficial" because I have
> no idea, in either the Independent Submission or IETF streams,
> what an "official memo" would be.  Personal opinion: bad advice
> (see below) or a misunderstanding.

What I mean is that Gopher as it exists today is "standardised" (I know =
it doesn't quite work that way) by two documents: the Gopher RFC, which =
has official status (that is, it's an IETF document), and the Gopher+ =
memo, which is internal work by the University of Minnesota and contains =
more spelling and grammar errors than you can shake a stick at.  There =
is no formal "standard" for Gopher, but it is informally "standardised" =
by those two documents. =20

>=20
>> I'm not opposed to this idea, which is
>> why draft-matavka-gopher-ii is currently sitting on IETF
>> servers on said Standards Track.
>=20
> I don't even know what that means, unless you are just referring
> to a "proposed status" line in the Internet Draft.

Yeah, that's what I'm referring to.  This is my first time at this =
particular rodeo, so please forgive me if I act like a newbie, because I =
am.

>=20
>> My concerns are mostly related to IETF process.  How are
>> independent submissions handled?  Am I supposed to receive an
>> eMail from one of the review people stating the nits that need
>> to be corrected?  The structure is fine, I'm now curious as to
>> how an Internet-Draft becomes a Standard.
>=20
> To save you more time, I'll review the two options separately
> and add a third.
>=20
> (i) For an individual submission of a standards track document,
> you need to get an AD to sign up to "sponsor" it, i.e., to take
> the lead in moving the document through the system.  It is not
> clear to me, especially after the Area reorganization started,
> who the best candidate would be, but I think it would be
> reasonable for you to send an inquiry to iesg@ietf.org and hope
> someone responds.  If any of the current ADs have expressed
> interest, I'd start with a discussion with him or her.
>=20
> Personal opinion: Unless you can find a sponsoring AD would is
> _really_ committed to the document and/or to you and your
> situation, successfully getting a document processed in this way
> is likely to be time-consuming and painful for anyone without a
> lot of IETF experience.   It may be worth noting that efforts to
> get FTP updates and extensions processed onto the standards
> track have rarely gotten significant traction and, whatever the
> other relationships may be, FTP has a much longer standards
> history and is far more widely deployed than gopher.

I did talk to Barry Leiba in January of '15, but totally forgot the =
salient points of the discussion.  I do remember you "had a full and =
frank exchange of views and opinions" with him about Proposed Standard v =
Informational then.

>=20
> (ii) For an independent submission, remove anything "standards
> track" from the document and send a note to ise@rfc-editor.org
> indicating that you would like to submit the document and asking
> for instructions as to how to proceed.
>=20
> (iii) The third possibility is to ask the Applications Area WG,
> via this list and/or a note to the chairs, to take this on and
> process it as a standards track document.  I don't know if you
> can get that agreement, but, if you can, it would provide you
> with much more help and support with standards track mechanisms
> than the individual submission approach would.

What would you suggest, John?  You wrote me way back in January, =
"Initial versions of I-Ds are typically _very_informal.  It is entirely =
reasonable to post one that if [sic] full of both stylistic and =
substantive errors and then iterate on it as comments come in (certainly =
I have done so and had a -01 version be radically different from a -00). =
 Don't hesitate to post whatever you have as an I-D and don't assume =
that whatever you post will be final -- there are a fairly large =
population of dinosaurs around and some of them (us) are still in touch =
with the developers of that period."

"But, if this is a "live" protocol in active use and you are describing =
the current versions, why not just push for Proposed Standard?  Some of =
us would certainly support that action and status."

I think you advised me well the first time, just don't know how to =
proceed.  I think option (iii) would be the right one, but I don't know =
how, rather than if, I can get their agreement.  I assume there's some =
sort of boilerplate. =20

>=20
>> I'm also curious as
>> to how ongoing fixes are incorporated.  For instance, the
>> informal workgroup that discusses Gopher is now floating the
>> idea of Gopher over TLS, and they have reached the consensus
>> that GopherS (as they have called it) would be a beneficial,
>> but optional, part of the Gopher system. Perhaps a footnote to
>> that effect would fit in the Internet-Draft, but I'm not sure
>> how 00 becomes 01 and 02 and 03.
>=20
> As long as this is an individual or independent submission, you
> are free to modify the I-D in any way that you find appropriate.
> Discussions, perhaps in an appendix, of what changes were made
> and, if it is not obvious, why, can be a great help to readers
> but there are no specific requirements.  There is no provision
> in the Internet-Draft format for footnotes although some of us
> have devised variation on endnotes on occasion.

I'm just wondering what the technical way to do that is.  Is there an =
"edit" link to click on?

>=20
> Note that, as far as IETF Standards Track is concerned, there is
> no such thing as an "informal workgroup" or consensus within it.
> It is just you and some of your friends making an individual
> submission or trying to either form an IETF WG (a fourth option
> deliberately omitted above) or getting an existing WG to take
> the work on.

I know.

>=20
>> Anyway, any help you could give me is appreciated.
>=20
> Personal opinion/recommendation: put a solid document together
> that describes what has actually been implemented, deployed, and
> put into non-trivial use.   If you want to speculate about
> changes that should be made, do that, but treat it is
> speculation and maybe put it in an appendix.  Keep it
> descriptive rather than making normative and/or conformance
> statements.  Hand that off to the Independent Submission Editor
> and get it reviewed and published as a baseline.  Once you have
> accomplished that, you will have an informative document for the
> community and a better baseline for future work than the 20+
> year old (and also Informational) spec in RFC 1436.  Because
> 1436 was Informational, nothing prevents your new document from
> updating it or, if it is complete enough, obsoleting it, and you
> should specify one or the other unless the ISE recommends
> otherwise.  Then, if you want to, develop an IETF-stream,
> standards track, normative document that specifies, e.g.,
> interoperability requirements and applicability for modern
> Gopher.  =20

That's what I've already done.  The document I have put together =
describes the standard as it exists today.  I did use a few conformance =
statements, but only because what they're conforming with is consensus.  =
I want to formalise the consensus, that's all, not bring in new features =
and make Gopher as bloated as the Web is.  I simply wanted to add the =
sentence "Nothing in this document prevents Gopher from being used over =
SSL/TLS; the protocol, in this case, is Gophers://"

>=20
> Others may disagree with that strategy.  In particular, I hope
> the people on this list who were more closely involved with
> Gopher development and deployment in the 1990s than I was (i.e.,
> more than zero) would at least comment and possibly offer
> support and guidance.
>=20
>     john
>=20
>=20
>=20
> ------------------------------
>=20
> Subject: Digest Footer
>=20
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>=20
>=20
> ------------------------------
>=20
> End of apps-discuss Digest, Vol 87, Issue 51
> ********************************************


--Apple-Mail=_63838739-D61C-4EA6-8D47-9DA19789DACA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii


On Apr 25, 2015, at 3:00 PM, apps-discuss-request@ietf.org wrote:

Send apps-discuss =
mailing list submissions to
	apps-discuss@ietf.org

To =
subscribe or unsubscribe via the World Wide Web, visit
	=
https://www.ietf.org/mailman/listinfo/apps-discuss
or, via email, send a message with subject or body 'help' =
to
=
	apps-discuss-request@ietf.org

You can reach the person managing the list at
	=
apps-discuss-owner@ietf.org

When =
replying, please edit your Subject line so it is more specific
than "Re: Contents of apps-discuss digest..."

Today's Topics:

 =
  1.  independent submission process for	=
draft-matavka-gopher-ii
 =
     (Nick Matavka)
 =
  2. Re:  List-ID vs. [list-id] (was Re: meta - removing =
list
      banner?) (Dave =
Crocker)
   3. Re:  independent submission =
process for
 =
     draft-matavka-gopher-ii (John C =
Klensin)


---------------------------------------------------------------=
-------

Message: 1
Date: Sat, =
25 Apr 2015 03:21:22 -0400
From: Nick Matavka =
<n.theodore.matavka.files@gmail.com>
To: =
apps-discuss@ietf.org
Subject: [apps-discuss] independent =
submission process for
	draft-matavka-gopher-ii
Message-ID:
	=
<CANroBD3jaeVVi_LiRivOW4Km2n=3DSb9Px5y2u=3DDpO2-qwMjP3aA@mail.gm=
ail.com>
Content-Type: text/plain; charset=3D"utf-8"

Hello, world!

I =
sent off an independent submission as a proposed standard, in regards =
to
extensions to the Gopher WWIS.  Although the =
current iteration of the
Gopher protocol is =
half-Informational and half-unofficial memo (by which I
mean=
 the optional Gopher+ extensions), it was recommended to me that I =
put
my draft on the Standards Track.  I'm not opposed =
to this idea, which is
why draft-matavka-gopher-ii is =
currently sitting on IETF servers on said
Standards =
Track.

My concerns are mostly related to =
IETF process.  How are independent
submissions =
handled?  Am I supposed to receive an eMail from one of the
review people stating the nits that need to be corrected? =
 The structure is
fine, I'm now curious as to how an =
Internet-Draft becomes a Standard.  I'm
also curious =
as to how ongoing fixes are incorporated.  For instance, the
informal workgroup that discusses Gopher is now floating the =
idea of Gopher
over TLS, and they have reached the =
consensus that GopherS (as they have
called it) would be a =
beneficial, but optional, part of the Gopher system.
Perhaps=
 a footnote to that effect would fit in the Internet-Draft, but I'm
not sure how 00 becomes 01 and 02 and 03.

Anyway, any help you could give me is appreciated.

Edward Matavka



-- 
 =
      /^\/^\
 =
      \----|
 =
  _---'---~~~~-_
 =
   ~~~|~~L~|~~~~
 =
      (/_  /~~--
 =
    \~ \  /  /~
 =
  __~\  ~ /   ~~----,
 =
  \    | | =
      /  \
 =
  /|   |/       | =
   |
   | | | o  o =
    /~   |
 _-~_  | =
       ||  \  /
(// )) | o  o    \\---'
//_- =
|  |          \
//   |____|\______\__\
~ =
     |   / |    |
       |_ /   \ _|
     /~___|  /____\
-------------- next part --------------
An HTML =
attachment was scrubbed...
URL: =
<http://www.ietf.org/mail-archive/web/apps-discuss/attachments/20150425=
/d7934470/attachment.html>

------------------------------

Message: 2
Date: Sat, 25 Apr 2015 05:32:39 =
-0700
From: Dave Crocker <dhc@dcrocker.net>
To: "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] List-ID vs. [list-id] (was Re: =
meta -
	removing list banner?)
Message-ID: <553B8967.80601@dcrocker.net>
Content-Type: text/plain; charset=3Dutf-8


Do you mean search?  I don't think Gmail =
sorts on anything except
received
date. =
 We do have the list: and listid: operators, however.

I was using sort in the usual =
(among people who use procmail and similar
tools) sense of =
putting it into folders or the like, what Dave calls
filtering.

 =
    The essential semantic point, for this thread, =
is that email
software often has a convenient column-based =
mechanism for arranging the
order of messages seen in the =
summary message list.  Clicking on a
column makes it =
the primary key for organizing messages.  This is
extremely convenient and useful.

 =
    Having the [list-id] convention at the beginning =
of the Subject
line permits easy organizing of messages in =
a folder, according to
mailing list.  Losing that =
capability would be a significant downgrade
in utility.

     For clarity, I =
suggest distinguishing this 'within folder' sorting
from =
any mechanism that puts messages into folders, tabs, or the like.


As for terminology...

Gmail uses the 'sort' term the way John is, =
but note it also uses
'filtering' (see below):

     "sorts messages into =
categories, or ?tabs.?


Yahoo, =
Earthlink, Thunderbird, Outlook use the term the way I do (and
the way the dictionary does):

 =
     "You can sort your messages based on =
different kinds of
information: the date you received =
them, who you received them from, or
their subject. You =
can sort messages in a couple of ways: using the
Actions =
menu or using the column headers."

 =
    "Reading and Sorting Messages -- You can change =
the order by
clicking one of the column titles at the top =
of the message list."

 =
    "Sort Mail by the Order It Was Received in =
Mozilla Thunderbird"

 =
    "So if you wanted to sort all mail by Thread, =
Descending (newest at
top), the preferences in the config =
editor will look like this"

 =
    "Click to sort"


And I didn't invent the usage 'filtering'. Eg, Thunderbird, =
Wikipedia,
Gmail:

 =
    "Organize Your Messages by Using Filters"

     "Email filtering is =
the processing of email to organize it
according to =
specified criteria."

 =
    "Using filters, you can automatically send email =
to a label,
archive, delete,"


d/
-- 
Dave =
Crocker
Brandenburg InternetWorking
bbiw.net



------------------------------

Message: 3
Date: Sat, 25 Apr 2015 10:03:43 =
-0400
From: John C Klensin <john-ietf@jck.com>
To: Nick Matavka =
<n.theodore.matavka.files@gmail.com>
Cc: =
apps-discuss@ietf.org
Subject: Re: [apps-discuss] =
independent submission process for
	=
draft-matavka-gopher-ii
Message-ID: =
<7EBB46C3F03620A468C8101C@JcK-HP8200.jck.com>
Content-Type: text/plain; charset=3Dus-ascii

Nick,

It appears that =
circumstances have created a good deal of
confusion here. =
 I'll try to clarify as much as I can inline
below. =
 I believe everything not identified as "personal
opinion" or the equivalent below accurately reflects IETF =
and
RFC Editor procedures and processing rules. 

--On Saturday, April 25, 2015 03:21 -0400 Nick =
Matavka
<n.theodore.matavka.files@gmail.com> =
wrote:

...
I sent off an independent submission as a =
proposed standard,

First, I =
know this is confusing, but, to keep the confusion from
getting worse, note that there are "independent =
submissions"
that go through one review process (via the =
Independent
Submission Editor) and "individual =
submissions" which are
processed via the IETF Stream. =
  There is no such thing as an
"independent =
submission as proposed standard" because only the
IETF =
Stream can process standards track documents.

in regards to extensions =
to the Gopher WWIS.  Although the
current iteration =
of the Gopher protocol is half-Informational
and =
half-unofficial memo (by which I mean the optional Gopher+
extensions), it was recommended to me that I put my draft =
on
the Standards Track.

I'm not sure what you mean by "half-unofficial" because I =
have
no idea, in either the Independent Submission or IETF =
streams,
what an "official memo" would be.  Personal =
opinion: bad advice
(see below) or a misunderstanding.

What I mean =
is that Gopher as it exists today is "standardised" (I know it doesn't =
quite work that way) by two documents: the Gopher RFC, which has =
official status (that is, it's an IETF document), and the Gopher+ memo, =
which is internal work by the University of Minnesota and contains more =
spelling and grammar errors than you can shake a stick at.  There =
is no formal "standard" for Gopher, but it is informally "standardised" =
by those two documents.  


I'm not opposed to this idea, which is
why draft-matavka-gopher-ii is currently sitting on IETF
servers on said Standards Track.
I don't even know what that means, unless you are just =
referring
to a "proposed status" line in the Internet =
Draft.

Yeah, that's what I'm referring to.  This is =
my first time at this particular rodeo, so please forgive me if I act =
like a newbie, because I am.


My concerns are mostly related to IETF process.  How =
are
independent submissions handled?  Am I supposed =
to receive an
eMail from one of the review people stating =
the nits that need
to be corrected?  The structure is =
fine, I'm now curious as to
how an Internet-Draft becomes =
a Standard.

To save you more =
time, I'll review the two options separately
and add a =
third.

(i) For an individual submission of =
a standards track document,
you need to get an AD to sign =
up to "sponsor" it, i.e., to take
the lead in moving the =
document through the system.  It is not
clear to me, =
especially after the Area reorganization started,
who the =
best candidate would be, but I think it would be
reasonable =
for you to send an inquiry to iesg@ietf.org and hope
someone responds. =
 If any of the current ADs have expressed
interest, =
I'd start with a discussion with him or her.

Personal opinion: Unless you can find a sponsoring AD would =
is
_really_ committed to the document and/or to you and =
your
situation, successfully getting a document processed =
in this way
is likely to be time-consuming and painful for =
anyone without a
lot of IETF experience.   It =
may be worth noting that efforts to
get FTP updates and =
extensions processed onto the standards
track have rarely =
gotten significant traction and, whatever the
other =
relationships may be, FTP has a much longer standards
history and is far more widely deployed than gopher.

I did talk to Barry Leiba in January of '15, but =
totally forgot the salient points of the discussion.  I do remember =
you "had a full and frank exchange of views and opinions" with him about =
Proposed Standard v Informational then.


(ii) For an independent submission, remove =
anything "standards
track" from the document and send a =
note to ise@rfc-editor.org
indicating that you =
would like to submit the document and asking
for =
instructions as to how to proceed.

(iii) =
The third possibility is to ask the Applications Area WG,
via this list and/or a note to the chairs, to take this on =
and
process it as a standards track document.  I =
don't know if you
can get that agreement, but, if you can, =
it would provide you
with much more help and support with =
standards track mechanisms
than the individual submission =
approach would.

What would you suggest, John?  You wrote me =
way back in January, "Initial versions of =
I-Ds are typically _very_informal.  It is =
entirely reasonable to post one that if [sic] full of both stylistic and substantive errors and then iterate on it =
as comments come in (certainly I have done =
so and had a -01 version be radically different =
from a -00).  Don't hesitate to post whatever you have as an I-D and don't assume that whatever =
you post will be final -- there are a fairly =
large population of dinosaurs around and =
some of them (us) are still in touch with the developers of that period."

"But, if this is a "live" protocol in active use and you =
are describing the current versions, why not =
just push for Proposed Standard?  Some of us would certainly support that action =
and status."

I think you advised me well the first time, just don't know =
how to proceed.  I think option (iii) would be the right one, but I =
don't know how, rather than if, I =
can get their agreement.  I assume there's some sort of =
boilerplate.  


 I'm also curious as
to how ongoing fixes are incorporated.  For instance, =
the
informal workgroup that discusses Gopher is now =
floating the
idea of Gopher over TLS, and they have =
reached the consensus
that GopherS (as they have called =
it) would be a beneficial,
but optional, part of the =
Gopher system. Perhaps a footnote to
that effect would fit =
in the Internet-Draft, but I'm not sure
how 00 becomes 01 =
and 02 and 03.

As long as this =
is an individual or independent submission, you
are free =
to modify the I-D in any way that you find appropriate.
Discussions, perhaps in an appendix, of what changes were =
made
and, if it is not obvious, why, can be a great help =
to readers
but there are no specific requirements. =
 There is no provision
in the Internet-Draft format =
for footnotes although some of us
have devised variation =
on endnotes on occasion.

I'm just wondering what the technical way to do that is.  Is =
there an "edit" link to click on?


Note that, as =
far as IETF Standards Track is concerned, there is
no such =
thing as an "informal workgroup" or consensus within it.
It =
is just you and some of your friends making an individual
submission or trying to either form an IETF WG (a fourth =
option
deliberately omitted above) or getting an existing =
WG to take
the work on.

I know.


Anyway, any help you =
could give me is appreciated.

Personal opinion/recommendation: put a solid document =
together
that describes what has actually been =
implemented, deployed, and
put into non-trivial use. =
  If you want to speculate about
changes that =
should be made, do that, but treat it is
speculation and =
maybe put it in an appendix.  Keep it
descriptive =
rather than making normative and/or conformance
statements. =
 Hand that off to the Independent Submission Editor
and=
 get it reviewed and published as a baseline.  Once you have
accomplished that, you will have an informative document for =
the
community and a better baseline for future work than =
the 20+
year old (and also Informational) spec in RFC =
1436.  Because
1436 was Informational, nothing =
prevents your new document from
updating it or, if it is =
complete enough, obsoleting it, and you
should specify one =
or the other unless the ISE recommends
otherwise. =
 Then, if you want to, develop an IETF-stream,
standards track, normative document that specifies, e.g.,
interoperability requirements and applicability for modern
Gopher.   

That's what I've already done.  The document =
I have put together describes the standard as it exists today.  I =
did use a few conformance statements, but only because what they're =
conforming with is consensus.  I want to formalise the consensus, =
that's all, not bring in new features and make Gopher as bloated as the =
Web is.  I simply wanted to add the sentence "Nothing in this =
document prevents Gopher from being used over SSL/TLS; the protocol, in =
this case, is Gophers://"


Others may disagree with that =
strategy.  In particular, I hope
the people on this =
list who were more closely involved with
Gopher =
development and deployment in the 1990s than I was (i.e.,
more than zero) would at least comment and possibly offer
support and guidance.

 =
    john



------------------------------
Subject: Digest Footer

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


------------------------------
End of apps-discuss Digest, Vol 87, Issue =
51
********************************************

=

--Apple-Mail=_63838739-D61C-4EA6-8D47-9DA19789DACA--


From nobody Sat Apr 25 17:25:14 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A186A1B32CA for ; Sat, 25 Apr 2015 17:25:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level: 
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KOgMoGFIgRdj for ; Sat, 25 Apr 2015 17:25:11 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA1B01B32C9 for ; Sat, 25 Apr 2015 17:25:11 -0700 (PDT)
Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YmANh-0009Ft-QF; Sat, 25 Apr 2015 20:25:09 -0400
Date: Sat, 25 Apr 2015 20:25:04 -0400
From: John C Klensin 
To: Nick Matavka , apps-discuss@ietf.org
Message-ID: <61A491CDEF77B0BE1F647AE3@JcK-HP8200.jck.com>
In-Reply-To: <3C78D500-2389-4234-B0BD-0B4690A45EB9@gmail.com>
References:  <3C78D500-2389-4234-B0BD-0B4690A45EB9@gmail.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.35
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: 
Subject: Re: [apps-discuss] independent submission process for draft-matavka-gopher-ii
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 26 Apr 2015 00:25:13 -0000

--On Saturday, April 25, 2015 18:15 -0400 Nick Matavka
 wrote:

>> I'm not sure what you mean by "half-unofficial" because I have
>> no idea, in either the Independent Submission or IETF streams,
>> what an "official memo" would be.  Personal opinion: bad
>> advice (see below) or a misunderstanding.
> 
> What I mean is that Gopher as it exists today is
> "standardised" (I know it doesn't quite work that way) by two
> documents: the Gopher RFC, which has official status (that is,
> it's an IETF document),

It is an Information specification and has no "official" status
at all, at least as far as normal IETF procedures are concerned.

> and the Gopher+ memo, which is
> internal work by the University of Minnesota and contains more
> spelling and grammar errors than you can shake a stick at.
> There is no formal "standard" for Gopher, but it is informally
> "standardised" by those two documents.  

No, it is described by those two documents and some of the users
and implementers have chosen to treat those descriptions as a de
facto standard.  I'm sorry to keep pushing at this but, if you
want IETF Standards Track treatment for your document, the
distinctions are quite important.

>>> I'm not opposed to this idea, which is
>>> why draft-matavka-gopher-ii is currently sitting on IETF
>>> servers on said Standards Track.
>> 
>> I don't even know what that means, unless you are just
>> referring to a "proposed status" line in the Internet Draft.
> 
> Yeah, that's what I'm referring to.  This is my first time at
> this particular rodeo, so please forgive me if I act like a
> newbie, because I am.

That is why you are getting the careful explanations.

>...
>> (i) For an individual submission of a standards track
>> document, you need to get an AD to sign up to "sponsor" it,
>> i.e., to take the lead in moving the document through the
>> system. 
>...
>> Personal opinion: Unless you can find a sponsoring AD would is
>> _really_ committed to the document and/or to you and your
>> situation, successfully getting a document processed in this
>> way is likely to be time-consuming and painful for anyone
>> without a lot of IETF experience.   It may be worth noting
>> that efforts to get FTP updates and extensions processed onto
>> the standards track have rarely gotten significant traction
>> and, whatever the other relationships may be, FTP has a much
>> longer standards history and is far more widely deployed than
>> gopher.
 
> I did talk to Barry Leiba in January of '15, but totally
> forgot the salient points of the discussion.  
>...

Then I suggest you try to work with Barry to reconstruct.
 
>> (ii) For an independent submission, remove anything "standards
>> track" from the document and send a note to ise@rfc-editor.org
>> indicating that you would like to submit the document and
>> asking for instructions as to how to proceed.
>> 
>> (iii) The third possibility is to ask the Applications Area
>> WG, via this list and/or a note to the chairs, to take this
>> on and process it as a standards track document.  I don't
>> know if you can get that agreement, but, if you can, it would
>> provide you with much more help and support with standards
>> track mechanisms than the individual submission approach
>> would.
 
> What would you suggest, John?  You wrote me way back in
> January, "Initial versions of I-Ds are typically
> _very_informal.  It is entirely reasonable to post one that if
> [sic] full of both stylistic and substantive errors and then
> iterate on it as comments come in (certainly I have done so
> and had a -01 version be radically different from a -00).
> Don't hesitate to post whatever you have as an I-D and don't
> assume that whatever you post will be final -- there are a
> fairly large population of dinosaurs around and some of them
> (us) are still in touch with the developers of that period."
 
> "But, if this is a "live" protocol in active use and you are
> describing the current versions, why not just push for
> Proposed Standard?  Some of us would certainly support that
> action and status."
> 
> I think you advised me well the first time, just don't know
> how to proceed.  I think option (iii) would be the right one,
> but I don't know how, rather than if, I can get their
> agreement.  I assume there's some sort of boilerplate.  

Not really.  We are really a much less formal group than the
impressions that we cause sometimes.  Watch for a follow-up note
immediately after this one.

>>> I'm also curious as
>>> to how ongoing fixes are incorporated.  For instance, the
>>> informal workgroup that discusses Gopher is now floating the
>...
> I'm just wondering what the technical way to do that is.  Is
> there an "edit" link to click on?

Sorry.  I misunderstood your question.   Prepare a new draft
with your changes, give it the same name as the earlier one with
-00 replaced by -01, and submit it the same way.  There is no
option for editing documents in place.

>...

best,
   john

p.s. _Please, if you are going to receive this mailing list as a
digest, trim everything not directly relevant to your response,
the text of especially completely unrelated messages, before
replying.  Fixing the subject line to reflect the actual message
thread is a good idea too -- something about "apps-discuss
digest" is really not helpful.




From nobody Sat Apr 25 17:25:29 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 667C61B32D0 for ; Sat, 25 Apr 2015 17:25:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level: 
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TFuC5cSyX5ay for ; Sat, 25 Apr 2015 17:25:22 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6BFE1B32CE for ; Sat, 25 Apr 2015 17:25:21 -0700 (PDT)
Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YmANr-0009Gb-Vp; Sat, 25 Apr 2015 20:25:19 -0400
Date: Sat, 25 Apr 2015 20:25:14 -0400
From: John C Klensin 
To: appsawg-chairs@tools.ietf.org
Message-ID: <810A79A34BFE6E493CC1A167@JcK-HP8200.jck.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.35
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: 
Cc: Nick Matavka , apps-discuss@ietf.org
Subject: [apps-discuss] Proposal for adoption of Gopher document as an AppsAWG task
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 26 Apr 2015 00:25:27 -0000

Murray and Alexey,

In order to shortcut some potential confusion and thrashing
around, consider this note a request, on the lead author's
behalf, to adopt Gopher-II: The Next Generation Gopher WWIS
(draft-matavka-gopher-ii) as a WG document with the intention of
processing it for standards track.

If there is interest in proceeding on that basis, I
recommend/request that you try to identify a shepherd or
equivalent now so that he or she can help Nick with technical
and procedural details.  For reasons which which you are both
familiar, relying on me to do that job in the time I have
available would be unwise and unfair to Nick although I'd be
happy to try to help someonw who was taking the lead if that
were needed.

If the WG takes this on, one of the decisions that will need to
be made early on is whether to go directly to a standards-track
spec or to first publish an informational "state of the protocol
in 2015" document and then build on it.

thanks,
    john


From nobody Sun Apr 26 08:39:10 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A351F1B2A46 for ; Sun, 26 Apr 2015 08:39:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.002
X-Spam-Level: 
X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95TeJj99ZD15 for ; Sun, 26 Apr 2015 08:39:07 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0088.outbound.protection.outlook.com [207.46.100.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC0371B2A4A for ; Sun, 26 Apr 2015 08:39:06 -0700 (PDT)
Received: from DM2PR02MB1322.namprd02.prod.outlook.com (25.161.142.21) by DM2PR02MB1324.namprd02.prod.outlook.com (25.161.142.23) with Microsoft SMTP Server (TLS) id 15.1.148.15; Sun, 26 Apr 2015 15:39:05 +0000
Received: from DM2PR02MB1322.namprd02.prod.outlook.com ([25.161.142.21]) by DM2PR02MB1322.namprd02.prod.outlook.com ([25.161.142.21]) with mapi id 15.01.0136.026; Sun, 26 Apr 2015 15:39:05 +0000
From: Larry Masinter 
To: John C Klensin 
Thread-Topic: [apps-discuss] Proposal for adoption of Gopher document as an AppsAWG task
Thread-Index: AQHQf7eCHYmdTOHmRkq/H8/Ai7KmKp1fbtL3
Date: Sun, 26 Apr 2015 15:39:05 +0000
Message-ID: <285C30B6-2481-4BB7-9B52-422C947B1965@adobe.com>
References: <810A79A34BFE6E493CC1A167@JcK-HP8200.jck.com>
In-Reply-To: <810A79A34BFE6E493CC1A167@JcK-HP8200.jck.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: jck.com; dkim=none (message not signed) header.d=none; 
x-originating-ip: [70.194.64.21]
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR02MB1324;
x-microsoft-antispam-prvs: 
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10009020)(6009001)(24454002)(377454003)(82746002)(2656002)(36756003)(19580395003)(46102003)(86362001)(77156002)(40100003)(19580405001)(561944003)(87936001)(33656002)(54356999)(99286002)(122556002)(2900100001)(102836002)(92566002)(2950100001)(15975445007)(16601075003)(83716003)(76176999)(110136001)(50986999)(66066001)(587094005)(62966003)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR02MB1324; H:DM2PR02MB1322.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010)(3002001); SRVR:DM2PR02MB1324; BCL:0; PCL:0;  RULEID:; SRVR:DM2PR02MB1324; 
x-forefront-prvs: 0558D3C5AC
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: adobe.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Apr 2015 15:39:05.5829 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR02MB1324
Archived-At: 
Cc: "appsawg-chairs@tools.ietf.org" , Nick Matavka , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Proposal for adoption of Gopher document as an AppsAWG task
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 26 Apr 2015 15:39:08 -0000

I don't think there is sufficient evidence that this proposal has a serious=
 audience. Appsawg should decline.

--
http://larry.masinter.net

> On Apr 26, 2015, at 2:25 AM, John C Klensin  wrote:
>=20
> Murray and Alexey,
>=20
> In order to shortcut some potential confusion and thrashing
> around, consider this note a request, on the lead author's
> behalf, to adopt Gopher-II: The Next Generation Gopher WWIS
> (draft-matavka-gopher-ii) as a WG document with the intention of
> processing it for standards track.
>=20
> If there is interest in proceeding on that basis, I
> recommend/request that you try to identify a shepherd or
> equivalent now so that he or she can help Nick with technical
> and procedural details.  For reasons which which you are both
> familiar, relying on me to do that job in the time I have
> available would be unwise and unfair to Nick although I'd be
> happy to try to help someonw who was taking the lead if that
> were needed.
>=20
> If the WG takes this on, one of the decisions that will need to
> be made early on is whether to go directly to a standards-track
> spec or to first publish an informational "state of the protocol
> in 2015" document and then build on it.
>=20
> thanks,
>    john
>=20
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss


From nobody Sun Apr 26 08:44:20 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6CA1B2A75 for ; Sun, 26 Apr 2015 08:44:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.002
X-Spam-Level: 
X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Wwt8J24K6W0 for ; Sun, 26 Apr 2015 08:44:18 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0094.outbound.protection.outlook.com [65.55.169.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF9131B2A71 for ; Sun, 26 Apr 2015 08:44:17 -0700 (PDT)
Received: from DM2PR02MB1322.namprd02.prod.outlook.com (25.161.142.21) by DM2PR02MB1323.namprd02.prod.outlook.com (25.161.142.22) with Microsoft SMTP Server (TLS) id 15.1.136.25; Sun, 26 Apr 2015 15:44:16 +0000
Received: from DM2PR02MB1322.namprd02.prod.outlook.com ([25.161.142.21]) by DM2PR02MB1322.namprd02.prod.outlook.com ([25.161.142.21]) with mapi id 15.01.0136.026; Sun, 26 Apr 2015 15:44:16 +0000
From: Larry Masinter 
To: Nick Matavka 
Thread-Topic: [apps-discuss] independent submission process for draft-matavka-gopher-ii
Thread-Index: AQHQfyh4ojCGhgt9LU+lFckHiKgI6J1fcWJv
Date: Sun, 26 Apr 2015 15:44:15 +0000
Message-ID: <04BE725F-B29F-497D-B15A-BAFA711BA57B@adobe.com>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;
x-originating-ip: [70.194.64.21]
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR02MB1323;
x-microsoft-antispam-prvs: 
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10009020)(6009001)(377454003)(24454002)(52314003)(36756003)(15975445007)(102836002)(110136001)(16601075003)(62966003)(77156002)(46102003)(50986999)(54356999)(76176999)(92566002)(2900100001)(2950100001)(2656002)(87936001)(33656002)(230783001)(122556002)(66066001)(587094005)(82746002)(40100003)(19580395003)(83716003)(86362001)(99286002)(19580405001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR02MB1323; H:DM2PR02MB1322.namprd02.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010)(3002001); SRVR:DM2PR02MB1323; BCL:0; PCL:0;  RULEID:; SRVR:DM2PR02MB1323; 
x-forefront-prvs: 0558D3C5AC
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: adobe.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Apr 2015 15:44:15.9012 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR02MB1323
Archived-At: 
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] independent submission process for draft-matavka-gopher-ii
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 26 Apr 2015 15:44:20 -0000

Gopher is suitable for marking historic.=20
I think this should be referred to httpbis.

--
http://larry.masinter.net

> On Apr 25, 2015, at 9:21 AM, Nick Matavka  wrote:
>=20
> Hello, world!
>=20
> I sent off an independent submission as a proposed standard, in regards t=
o extensions to the Gopher WWIS.  Although the current iteration of the Gop=
her protocol is half-Informational and half-unofficial memo (by which I mea=
n the optional Gopher+ extensions), it was recommended to me that I put my =
draft on the Standards Track.  I'm not opposed to this idea, which is why d=
raft-matavka-gopher-ii is currently sitting on IETF servers on said Standar=
ds Track.
>=20
> My concerns are mostly related to IETF process.  How are independent subm=
issions handled?  Am I supposed to receive an eMail from one of the review =
people stating the nits that need to be corrected?  The structure is fine, =
I'm now curious as to how an Internet-Draft becomes a Standard.  I'm also c=
urious as to how ongoing fixes are incorporated.  For instance, the informa=
l workgroup that discusses Gopher is now floating the idea of Gopher over T=
LS, and they have reached the consensus that GopherS (as they have called i=
t) would be a beneficial, but optional, part of the Gopher system.  Perhaps=
 a footnote to that effect would fit in the Internet-Draft, but I'm not sur=
e how 00 becomes 01 and 02 and 03.
>=20
> Anyway, any help you could give me is appreciated. =20
>=20
> Edward Matavka
>=20
>=20
>=20
> --=20
>        /^\/^\
>        \----|
>    _---'---~~~~-_ =20
>     ~~~|~~L~|~~~~
>        (/_  /~~--
>      \~ \  /  /~
>    __~\  ~ /   ~~----,
>    \    | |       /  \ =20
>    /|   |/       |    |
>    | | | o  o     /~   | =20
>  _-~_  |        ||  \  /
> (// )) | o  o    \\---'
> //_- |  |          \=20
> //   |____|\______\__\
> ~      |   / |    |
>        |_ /   \ _|
>      /~___|  /____\        =20
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss


From nobody Sun Apr 26 08:57:38 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B3631A1BFE for ; Sun, 26 Apr 2015 08:57:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 4.118
X-Spam-Level: ****
X-Spam-Status: No, score=4.118 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FRT_ADOBE2=2.455, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rXX2q3ercTbs for ; Sun, 26 Apr 2015 08:57:36 -0700 (PDT)
Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0589C1A1B82 for ; Sun, 26 Apr 2015 08:57:35 -0700 (PDT)
Received: (qmail 76409 invoked from network); 26 Apr 2015 15:57:35 -0000
Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 26 Apr 2015 15:57:35 -0000
Date: 26 Apr 2015 15:57:12 -0000
Message-ID: <20150426155712.28596.qmail@ary.lan>
From: "John Levine" 
To: apps-discuss@ietf.org
In-Reply-To: <285C30B6-2481-4BB7-9B52-422C947B1965@adobe.com>
Organization: 
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Archived-At: 
Cc: masinter@adobe.com
Subject: Re: [apps-discuss] Proposal for adoption of Gopher document as an AppsAWG task
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 26 Apr 2015 15:57:37 -0000

In article <285C30B6-2481-4BB7-9B52-422C947B1965@adobe.com> you write:
>I don't think there is sufficient evidence that this proposal has a serious
>audience. Appsawg should decline.

Gopher got a full chapter in Internet for Dummies in 1993, but by the
third edition in 1995 it was down in the laundry list of other
applications.  It's 20 years later, Gopher lives on only for fans of
retrocomputing, and it's hard to see any benefit of us spending time
on it.

R's,
John


From nobody Sun Apr 26 09:22:08 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D3481B2B35 for ; Sun, 26 Apr 2015 09:22:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.194
X-Spam-Level: ***
X-Spam-Status: No, score=3.194 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FRT_ADOBE2=2.455, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gc7sJ2u10BxM for ; Sun, 26 Apr 2015 09:22:05 -0700 (PDT)
Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.185]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02FE51B2B34 for ; Sun, 26 Apr 2015 09:22:04 -0700 (PDT)
Received: from [192.168.1.189] (frobbit.cust.teleservice.net [85.30.128.225]) by mail.frobbit.se (Postfix) with ESMTPSA id 3FE741FD46; Sun, 26 Apr 2015 18:22:02 +0200 (CEST)
From: "Patrik =?utf-8?b?RsOkbHRzdHLDtm0=?=" 
To: "John Levine" 
Date: Sun, 26 Apr 2015 18:22:01 +0200
Message-ID: <40CF66E3-DA69-4491-8730-17EA8F35248F@frobbit.se>
In-Reply-To: <20150426155712.28596.qmail@ary.lan>
References: <20150426155712.28596.qmail@ary.lan>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=_MailMate_EBCF2110-AA80-42C7-B007-84256235D8A7_="; micalg=pgp-sha1; protocol="application/pgp-signature"
X-Mailer: MailMate Trial (1.9.1r5084)
Archived-At: 
Cc: apps-discuss@ietf.org, masinter@adobe.com
Subject: Re: [apps-discuss] Proposal for adoption of Gopher document as an AppsAWG task
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 26 Apr 2015 16:22:06 -0000

This is an OpenPGP/MIME signed message (RFC 3156 and 4880).

--=_MailMate_EBCF2110-AA80-42C7-B007-84256235D8A7_=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On 26 Apr 2015, at 17:57, John Levine wrote:

> In article <285C30B6-2481-4BB7-9B52-422C947B1965@adobe.com> you write:
>
>> I don't think there is sufficient evidence that this proposal has a se=
rious
>> audience. Appsawg should decline.
>
>
> Gopher got a full chapter in Internet for Dummies in 1993, but by the
> third edition in 1995 it was down in the laundry list of other
> applications.  It's 20 years later, Gopher lives on only for fans of
> retrocomputing, and it's hard to see any benefit of us spending time
> on it.

I disagree and further think the wording you have chosen John is not opti=
mal when someone regardless of popularity (or lack thereof) of a protocol=
 tries to increase interoperability, and because of that approach IETF.

I want an inclusive IETF process.

I also think what is described here:  describe more use than many other crazy ideas that are disc=
ussed in the IETF.

If you are worried about cycles used by busy officers of the IETF (or som=
ething else), which btw is a view I share, I think Klensin has come up wi=
th a good proposal on a path forward.

I further do think it is not correct to give this task to an HTTP related=
 wg in the IETF but instead I suggest:

- The document is submitted as an individual submission.

- Help is given so that the document and process is followed correctly.

- IESG do add an appropriate note that point out the limited, but still u=
se.

I.e. use minimal IETF energy, ensure process is followed, have IESG add a=
 note about Gopher.

   Patrik

--=_MailMate_EBCF2110-AA80-42C7-B007-84256235D8A7_=
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename=signature.asc
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iEYEARECAAYFAlU9EKkACgkQrMabGguI180XDgCfW8zuqSV24ov08EAsFTEYX3lA
h20An1qfLteAFRxDOsOArTxttUGVQ5Oe
=G4vD
-----END PGP SIGNATURE-----

--=_MailMate_EBCF2110-AA80-42C7-B007-84256235D8A7_=--


From nobody Sun Apr 26 09:54:41 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72D411B2BBC for ; Sun, 26 Apr 2015 09:54:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.863
X-Spam-Level: *
X-Spam-Status: No, score=1.863 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aEJKzB97ReBz for ; Sun, 26 Apr 2015 09:54:39 -0700 (PDT)
Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 936A11A8913 for ; Sun, 26 Apr 2015 09:54:39 -0700 (PDT)
Received: (qmail 83897 invoked from network); 26 Apr 2015 16:54:39 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=147b8.553d184f.k1504; bh=EGvbwK1WWx6SV6EoQZSEAzCmO9xXmspq4Q/jzGT9Mt0=; b=vrZGmQRQYYaEczke1jrkFz3kvt9yxtI+CrZQAc9x/CnReauXGoEZoDKI1KgUIchyTNlTaltnB22B2V6daQNsT/DUvYVOI+iANheh6I3UYGHFGBYiCLbJ7IHY/PpwrkWS8uYtTl8IJ1sFreKb5GYvPzVRYBoRv/l5jeSZHfpk0cphb5S5bBAbfspYBeScIkvXKPDBqOZYQnqIiMGKyiiSZh69VjWy1K3MtmhTSphjqsRkHfnX+X/R3X32g/D3Vz3y
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=147b8.553d184f.k1504; bh=EGvbwK1WWx6SV6EoQZSEAzCmO9xXmspq4Q/jzGT9Mt0=; b=d1yV7p2LureuQBewETb7tdDuZvmNlvFdvVO45BlQ/pPWCoeeJdvwoe7/fH5VHTu31l3ypjZjTK/IfdhRJ53X8owhDKb3urqDZzDOdsOGQbgxyJW8uX7BCXvq3wNsEYQKYMK9HDAX5S/17MgLSUjoeYs32RiJFzYG/dVz9p6GWKSjgtYhefpD4+zyFyeeYmhQtKVFBHE6CG/OKPVmAVn2A070Cb+EE5Osb4V0acJEuRBsbQfw/C/e57ASDjpfXmBh
Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 26 Apr 2015 16:54:39 -0000
Date: 26 Apr 2015 12:54:37 -0400
Message-ID: 
From: "John R Levine" 
To: "=?UTF-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?=" 
In-Reply-To: <40CF66E3-DA69-4491-8730-17EA8F35248F@frobbit.se>
References: <20150426155712.28596.qmail@ary.lan> <40CF66E3-DA69-4491-8730-17EA8F35248F@frobbit.se>
User-Agent: Alpine 2.11 (OSX 23 2013-08-11)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
Archived-At: 
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Proposal for adoption of Gopher document as an AppsAWG task
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 26 Apr 2015 16:54:40 -0000

> I disagree and further think the wording you have chosen John is not optimal when someone regardless of popularity (or lack thereof) of a protocol tries to increase interoperability, and because of that approach IETF.
>
> I want an inclusive IETF process.

So do I, but we do not have unlimited time, and appsawg has chronic 
problems handling drafts on topics in much wider use than gopher.

On the other hand, if you're volunteering to shepherd the gopher draft, 
nobody will object to that.

Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.


From nobody Sun Apr 26 10:09:52 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E83901A9095 for ; Sun, 26 Apr 2015 10:09:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.439
X-Spam-Level: *
X-Spam-Status: No, score=1.439 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UpF9kyNrrzaV for ; Sun, 26 Apr 2015 10:09:50 -0700 (PDT)
Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10DB61A9044 for ; Sun, 26 Apr 2015 10:09:50 -0700 (PDT)
Received: from [192.168.1.189] (frobbit.cust.teleservice.net [85.30.128.225]) by mail.frobbit.se (Postfix) with ESMTPSA id 266AB1FE26; Sun, 26 Apr 2015 19:09:48 +0200 (CEST)
From: "Patrik =?utf-8?b?RsOkbHRzdHLDtm0=?=" 
To: "John R Levine" 
Date: Sun, 26 Apr 2015 19:09:47 +0200
Message-ID: 
In-Reply-To: 
References: <20150426155712.28596.qmail@ary.lan> <40CF66E3-DA69-4491-8730-17EA8F35248F@frobbit.se> 
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=_MailMate_B510EEA0-C2C5-4EDA-A9AC-D13F2A321184_="; micalg=pgp-sha1; protocol="application/pgp-signature"
X-Mailer: MailMate Trial (1.9.1r5084)
Archived-At: 
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Proposal for adoption of Gopher document as an AppsAWG task
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 26 Apr 2015 17:09:51 -0000

This is an OpenPGP/MIME signed message (RFC 3156 and 4880).

--=_MailMate_B510EEA0-C2C5-4EDA-A9AC-D13F2A321184_=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On 26 Apr 2015, at 18:54, John R Levine wrote:

> So do I, but we do not have unlimited time, and appsawg has chronic pro=
blems handling drafts on topics in much wider use than gopher.

I agree with this.

> On the other hand, if you're volunteering to shepherd the gopher draft,=
 nobody will object to that.

Fair, let me try to get the document in correct shape/format, without usi=
ng any of your cycles.

We have the same goal here. Spend IETF time on what matters.

The only difference, as far as I see it, is that I think "saying no" is n=
ot the correct answer when someone want to do work.

No, I do not have any crystal clear response that I know works. But I *wa=
nt* to have a different answer.

Thanks for this response John!

   Patrik

--=_MailMate_B510EEA0-C2C5-4EDA-A9AC-D13F2A321184_=
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename=signature.asc
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iEYEARECAAYFAlU9G9sACgkQrMabGguI183zKACbB4R/3TTRzgFWjnMSA3I1clai
VswAn0tBhmvuZYJ1p4NQ0rxXRvSYb4SZ
=FLeb
-----END PGP SIGNATURE-----

--=_MailMate_B510EEA0-C2C5-4EDA-A9AC-D13F2A321184_=--


From nobody Sun Apr 26 10:34:32 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 194E11AC3E6 for ; Sun, 26 Apr 2015 10:34:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.545
X-Spam-Level: **
X-Spam-Status: No, score=2.545 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w2-3E0nZhyp3 for ; Sun, 26 Apr 2015 10:34:30 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECC991AC3E2 for ; Sun, 26 Apr 2015 10:34:29 -0700 (PDT)
Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YmQRm-000Ch7-CI; Sun, 26 Apr 2015 13:34:26 -0400
Date: Sun, 26 Apr 2015 13:34:21 -0400
From: John C Klensin 
To: John Levine , apps-discuss@ietf.org, Nick Matavka 
Message-ID: <5EF79395E9C32A15465EA29E@JcK-HP8200.jck.com>
In-Reply-To: <20150426155712.28596.qmail@ary.lan>
References: <20150426155712.28596.qmail@ary.lan>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.35
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: 
Cc: masinter@adobe.com
Subject: Re: [apps-discuss] Proposal for adoption of Gopher document as an AppsAWG task
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 26 Apr 2015 17:34:31 -0000

--On Sunday, April 26, 2015 15:57 +0000 John Levine
 wrote:

> In article <285C30B6-2481-4BB7-9B52-422C947B1965@adobe.com>
> you write:
>> I don't think there is sufficient evidence that this proposal
>> has a serious audience. Appsawg should decline.
> 
> Gopher got a full chapter in Internet for Dummies in 1993, but
> by the third edition in 1995 it was down in the laundry list
> of other applications.  It's 20 years later, Gopher lives on
> only for fans of retrocomputing, and it's hard to see any
> benefit of us spending time on it.

In case it wasn't clear, I made the suggestion/request to help
Nick get clarity on whether it was better to pursue an
independent submission or some standards-track approach (and, if
so, which one), rather than having him waste his time and ours
trying to go in all directions at once and that is still my
position.

However, let me play devil's advocate for a moment.  The advent
and great success of the web, especially in combination with
powerful, advertising-enhanced, full-text search engines, swept
away a great deal of prior, function-specific, work and arguably
continues to do so.  That success has even worked against some
improvements to the web: legitimate concerns about backward
compatibility with whatever browsers or page authors are doing
has made it very hard to discuss and specify new but potentially
disruptive ideas and kludges are accumulating.  I suggest that
even work on and really creative thinking about the semantic web
has been impeded by the requirement to fit new ideas (and even a
few old, 1945-ish, ones) into the deployed model.  

IMO, homogeneity has costs and, e.g., the rather different
information models represented by systems based on authoritative
classification, managed identifiers, and/or intentionally
populated directories still have value and are likely to have
value far into the future.  Trying to stuff them all into the
same HTTP-constrained Procrustean bed really does the population
of Internet users no favors. 

For whatever it is worth, I believe it is inconsistent to argue
that the Internet is the home of permissionless innovation and
that the IETF is strongly committed to that idea and to try to
consign some protocols, without a hearing, to specific WGs where
the purpose of the assignment is to kill them.

Whether an updated version of Gopher is the right way to address
those issues is another question.  But, given that Nick has
argued that there is not only an active user community, but a
development one, I think they are entitled to try to demonstrate
that they are not just "fans of retrocomputing" and that, if
IETF review and interaction can add value to what they are
doing, it is reasonable to give them an opportunity to make the
case that we should invest the effort.

At least, unlike several of the proposals we have seen on this
list,  I don't think there is any risk that some people
developing and using an updated version of Gopher will cause
harm to the Internet or its other users.

best,
    john




From nobody Sun Apr 26 11:18:27 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C7D41B2C07 for ; Sun, 26 Apr 2015 11:18:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.263
X-Spam-Level: 
X-Spam-Status: No, score=0.263 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6HNKDvUQDZcL for ; Sun, 26 Apr 2015 11:18:24 -0700 (PDT)
Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35EE11B2C05 for ; Sun, 26 Apr 2015 11:18:24 -0700 (PDT)
Received: (qmail 94310 invoked from network); 26 Apr 2015 18:18:24 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=17065.553d2bf0.k1504; bh=lCn6YfrXbhO2FOoWz8h/YnZgI67wejz9jHO+Vfadi9Y=; b=v2p8qz8q6Uv1PkTHr1TdgkLc9dhfh2nJ1meCsTmH+gYGNu4GTR8wDLMzjv2nnBKsdF37uxkYmmD3hVW4oUd7r6etC31odtCOaraQBwMQ4H7vax+U89210MECYJJJaflwIist1GNoWi6oHiezzkl3ubyz/RTO59J1bog4cTti1t3offKOOzeowTlUpe/VYEyJsmoxWy9l4rJyz1n78nA2QhLNfl1kbtJSg+eGHHASz0LVU0XM9SOuFPlGOeaK98xJ
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=17065.553d2bf0.k1504; bh=lCn6YfrXbhO2FOoWz8h/YnZgI67wejz9jHO+Vfadi9Y=; b=hFMnNSfRz3kaqcbsuer/tKFfyYQZA7KBLmk1VDQmCFLDkAakDWhbrH/60L/5+QQ2KjV92JQ2ZiNWHm+UIwkDeC6OraUm567jIGdhZWa7ojArWHaJA1RWVWO7lj9aatBROcymWI2pE22T7anepTh+ASW2K/Np6ecnaKdSVJHp9PyP1CylkXw2YaoISZtDBz/xmQiyAKU6PW/KaKP2TLdpdRhpwzTxKCOrwAYTRX7GFHZJpjb4pZa1G22a1cNLfUW5
Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 26 Apr 2015 18:18:24 -0000
Date: 26 Apr 2015 14:18:22 -0400
Message-ID: 
From: "John R Levine" 
To: "John C Klensin" 
In-Reply-To: <5EF79395E9C32A15465EA29E@JcK-HP8200.jck.com>
References: <20150426155712.28596.qmail@ary.lan> <5EF79395E9C32A15465EA29E@JcK-HP8200.jck.com>
User-Agent: Alpine 2.11 (OSX 23 2013-08-11)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Archived-At: 
Cc: "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] Proposal for adoption of Gopher document as an AppsAWG task
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 26 Apr 2015 18:18:25 -0000

> At least, unlike several of the proposals we have seen on this
> list,  I don't think there is any risk that some people
> developing and using an updated version of Gopher will cause
> harm to the Internet or its other users.

I think that Gopher is just dandy.  My concern is only that appsawg has 
limited cycles, and spending time on A makes it less likely we'll have 
time to do B.

Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.


From nobody Sun Apr 26 11:30:59 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C07F1B2C26 for ; Sun, 26 Apr 2015 11:30:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level: 
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yoU7oa0S0_ld for ; Sun, 26 Apr 2015 11:30:56 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 315A91B2C22 for ; Sun, 26 Apr 2015 11:30:56 -0700 (PDT)
Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YmRKQ-000CnI-Ju; Sun, 26 Apr 2015 14:30:54 -0400
Date: Sun, 26 Apr 2015 14:30:49 -0400
From: John C Klensin 
To: John R Levine 
Message-ID: <96E9C7CE263F01126D865014@JcK-HP8200.jck.com>
In-Reply-To: 
References: <20150426155712.28596.qmail@ary.lan> <5EF79395E9C32A15465EA29E@JcK-HP8200.jck.com> 
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.35
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: 
Cc: Nick Matavka , apps-discuss@ietf.org
Subject: Re: [apps-discuss] Proposal for adoption of Gopher document as an AppsAWG task
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 26 Apr 2015 18:30:57 -0000

--On Sunday, April 26, 2015 14:18 -0400 John R Levine
 wrote:

>> At least, unlike several of the proposals we have seen on this
>> list,  I don't think there is any risk that some people
>> developing and using an updated version of Gopher will cause
>> harm to the Internet or its other users.
> 
> I think that Gopher is just dandy.  My concern is only that
> appsawg has limited cycles, and spending time on A makes it
> less likely we'll have time to do B.

I actually share that concern.  I just did not consider it
appropriate to have, or encourage Nick to have, a serious
discussion with the IESG about individual submission processing
without inquiring here first.   I do think the quality of
discussion and interaction that several things the WG agreed to
publish is such that I can't imagine Gopher getting much less.
This is ultimately up to Nick, but I don't personally see much
advantage in IETF standards track process (of any sort) unless
the IETF is actually able to add value.    On the other hand, I
suspect from your comment above that you and I would probably
agree that poor-quality review of earlier documents implies a
higher bar than we have been using rather than, e.g., getting
into a "the WG did X therefore it should do Y too" discussion.

FWIW, had you said "I don't care about it and don't imagine that
others on this list will either" I would have simply waited to
see if anyone disagreed with you and then moved on.  What set me
off was the much broader claim that appeared to be that everyone
with any interest in Gopher was somehow retrograde or retarded.

best,
     john




From nobody Sun Apr 26 12:48:47 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9062E1A1A15 for ; Sun, 26 Apr 2015 12:48:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.101
X-Spam-Level: 
X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JLMQ2aEi3xbA for ; Sun, 26 Apr 2015 12:48:44 -0700 (PDT)
Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CD611A1A02 for ; Sun, 26 Apr 2015 12:48:44 -0700 (PDT)
Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 83886FA0090; Sun, 26 Apr 2015 19:48:41 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1430077721; bh=co4UPL9+raGqBPVI4VEejFiKnHFjFe31beSP05pn+sU=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Dabdhy7F/QOseFPLyxezuX2gBHtUkvF05o2XckCkUa5JZuXj9wMQwCTYxjrKDn4NW giMh3bVhWKbB7PRDIDTm+5HI9SY5tFDYP8KqHM86rGoF43dfvCKci7udY86uc/Jfo4 3ATdrNKvBihgh7JrruFYcTLzOTVpqdEUhoAgBqfc=
Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1430077720-31136-31135/12/1071; Sun, 26 Apr 2015 19:48:40 +0000
From: Arnt Gulbrandsen 
To: apps-discuss@ietf.org
Date: Sun, 26 Apr 2015 21:48:39 +0200
User-Agent: Trojita/v0.5-9-g8961725; Qt/4.8.6; X11; Linux; Ubuntu 15.04
Mime-Version: 1.0
Message-Id: <8ac2b0c3-b8da-4695-9ab3-82f952876aeb@gulbrandsen.priv.no>
In-Reply-To: <5EF79395E9C32A15465EA29E@JcK-HP8200.jck.com>
References: <20150426155712.28596.qmail@ary.lan> <5EF79395E9C32A15465EA29E@JcK-HP8200.jck.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Archived-At: 
Subject: Re: [apps-discuss] Proposal for adoption of Gopher document as an AppsAWG task
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 26 Apr 2015 19:48:45 -0000

+1

If Nick can demonstrate rough consensus and running code (and I don't think 
there's real doubt about either of those, even if the running code is 
little-used) then that should be enough. In real life there's also a third 
condition: This is not the kind of draft that survives being a timesink for 
the IETF regulars.

Arnt


From dominic.parkes@realvnc.com  Tue Apr 28 04:48:29 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04F871A88AC for ; Tue, 28 Apr 2015 04:48:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.6
X-Spam-Level: 
X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HOST_MISMATCH_COM=0.311, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GIY1OzksHnr1 for ; Tue, 28 Apr 2015 04:48:27 -0700 (PDT)
Received: from SP39.realvnc.ltd (mx.realvnc.com [212.69.41.4]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7B6C1A8A1E for ; Tue, 28 Apr 2015 04:48:26 -0700 (PDT)
Received: from SP39.realvnc.ltd (10.10.99.12) by SP39.realvnc.ltd (10.10.99.12) with Microsoft SMTP Server (TLS) id 15.0.775.38; Tue, 28 Apr 2015 12:48:17 +0100
Received: from SP39.realvnc.ltd ([fe80::8456:5aa7:9e32:c70b]) by SP39.realvnc.ltd ([fe80::8456:5aa7:9e32:c70b%13]) with mapi id 15.00.0775.031; Tue, 28 Apr 2015 12:48:05 +0100
From: Dominic Parkes 
To: "apps-discuss@ietf.org" 
Thread-Topic: Re: [apps-discuss] New Proposed VNC URI Scheme
Thread-Index: AdCBqSc6crl3F8tOSzma47AJ62ytMA==
Date: Tue, 28 Apr 2015 11:48:05 +0000
Message-ID: <740110e9cb994e2986cee6109e2b58d1@SP39.realvnc.ltd>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.0.128]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [apps-discuss] New Proposed VNC URI Scheme
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 28 Apr 2015 11:58:27 -0000

On Tue, Mar 24, 2015 at 2:08 PM,  wrote:
>My co-author and I have prepared a proposed VNC URI scheme for review by t=
he community available at:
>http://www.ietf.org/internet-drafts/draft-warden-appsawg-vnc-scheme-00.
>txt

Hi all,

I'm co-ordinating a group at RealVNC with an interest in URI schemes, speci=
fically tasked with looking at the proposal David and Iordan prepared.
First of all: thanks David for putting this forward and reaching out to us.=
 We agree; it would be good to try to standardize use of VNC URI schemes, a=
nd you've provided a considered first step toward that.

Here are our comments by section:



Section 2.1 URI Scheme Syntax

>   A "vnc" URI has the general form:
>
>      vnc://host:port?parm1=3Dvalue1¶m2=3Dvalue2...

Per RFC3986 "username:password@" is deprecated, but we'd like to see some f=
acility for credential passing being recognised here, even if the inclusion=
 of passwords is strongly discouraged. Perhaps the more general "userinfo@"=
 field. Existing VNC viewers such as Apple's Screen Sharing VNC client, and=
 some of our own products use this form.

We also feel that there should be a note specifying that password data SHOU=
LD be percent encoded.

Also on this section - might it be worth allowing an optional path componen=
t? This could be used to identify a particular view/monitor or other implem=
entation-specific subdivision.=20



Section 2.1.1 URI Parameters

>   o  IdHashAlgorithm, IdHash

Minor point; this perhaps ought not default to SHA1 unless chosen to aid so=
me sort of compatibility with existing implementations.

> o  ColorModel

The name ColorModel implies choosing between representations of color, rath=
er than a pixel format. Perhaps ColorLevel would be more appropriate? Also =
we feel the default value and behaviour defined here to perhaps be too impl=
ementation-specific to include.=20

> o  ConnectionName, SaveConnection

The default for saving connections should be that it is up to the implement=
ation - there is a common use case for completely stateless clients launche=
d via URI.

> o  VncUsername, VncPassword, SecurityType

> The VNC client will use this information to determine which parameters=20
> are required and establish the connection.

Normal RFB behaviour is that the server lists the security types it can sup=
port, and the viewer chooses a valid, supported one. Is this parameter inte=
nded to control that negotiation (as well as determining the required param=
eters)? What happens in the case where the server's security types are not =
matched by the choice here? Perhaps some clarification is required.=20
We feel the default (for widest compatibility) should be to allow the norma=
l security handshake to occur.

> o  LaunchKey

This is a licensing feature which would seem to be quite implementation spe=
cific. We'd prefer that the scheme mentions that other unspecified paramete=
rs may exist (as per the note about distinguishing prefixes).

>   Parameter names and values shall be interpreted in a case sensitive man=
ner, unless otherwise noted.

Case sensitivity - in order to support the widest range of existing and fut=
ure implementations perhaps it would be better to specify a canonical case =
for each parameter, which SHOULD be used, but that clients SHOULD also acce=
pt them as case-insensitive?

> VNC Clients supporting  application-specific parameters SHOULD include=20
> a distinguishing prefix within the parameter name [...]
>=20
>    vnc://?com.dell.vncclient.ScreenMode=3D2&

This seems like a good idea - perhaps we could specify a facility to define=
 a namespace alias and encourage people to use it for multiple arguments, e=
.g.:=20

  vnc://?ns.Dell=3Dcom.dell.vncclient&Dell.SecurityType=3D1&Dell.ViewOnly=
=3Dtrue&



Section 2.3 Integrated Security Types

A broad comment on this section is that we'd prefer a scheme which attempts=
 to separate SSH and TLS tunnel security types from a more basic VNC URI sp=
ecification. Perhaps with a scheme looking something like this:

  vnc+ssh://hostname:port/?parameter=3Dvalue&



2.3.1 The "Integrated SSH" Security Type &
  2.3.2 The "Secure Tunnel" Security Type

There should probably be some discussion here about how SSH and TLS paramet=
ers such as cipher suites and version are expected to be configured.

>   Since the TLS protocol provides backwards compatibility with SSLv3,
>   and SSL tunnel MAY be used if supported.

Perhaps add a note discouraging the use of SSLv3? (https://tools.ietf.org/h=
tml/draft-ietf-tls-sslv3-diediedie-03).=20

>      When providing identifying information of a host identified by an
>      X509 certificate [x.509], the certificate subject, issuer,
>      validity period, and certificate hash MUST be included.  The VNC
>      client MAY give users the option of verifying the certificate
>      name, certificate authority, certificate revocation list, and
>      validity period.  If information on the validity of a certificate
>      is not displayed, the console application MUST include a
>      statement indicating such information has not been verified.

Should this also include the option that the client verifies the certificat=
e automatically? Perhaps add a reference to the relevant RFC (2818?).



Section 4. IANA Considerations

> The "vnc" scheme should be registered in the URI schemes registry.

This should have a specific reference to http://www.iana.org/assignments/ur=
i-schemes/uri-schemes.xhtml




Thanks,
Dominic Parkes
RealVNC Ltd.


From nobody Tue Apr 28 11:13:13 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E68341B2BC2 for ; Tue, 28 Apr 2015 11:13:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.566
X-Spam-Level: 
X-Spam-Status: No, score=-1.566 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RKrefT9yJ3jZ for ; Tue, 28 Apr 2015 11:13:10 -0700 (PDT)
Received: from homiemail-a90.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id DDAEA1B2BBC for ; Tue, 28 Apr 2015 11:13:07 -0700 (PDT)
Received: from homiemail-a90.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTP id 7E7A02AC075 for ; Tue, 28 Apr 2015 11:13:07 -0700 (PDT)
Received: from [192.168.1.18] (ip68-228-83-124.oc.oc.cox.net [68.228.83.124]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: fielding@gbiv.com) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTPSA id 21E722AC06E for ; Tue, 28 Apr 2015 11:13:05 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: "Roy T. Fielding" 
In-Reply-To: <740110e9cb994e2986cee6109e2b58d1@SP39.realvnc.ltd>
Date: Tue, 28 Apr 2015 11:13:01 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <9BCFFC92-69D3-4CBD-8B57-2628E1A5E52A@gbiv.com>
References: <740110e9cb994e2986cee6109e2b58d1@SP39.realvnc.ltd>
To: "apps-discuss@ietf.org" 
X-Mailer: Apple Mail (2.2098)
Archived-At: 
Subject: Re: [apps-discuss] New Proposed VNC URI Scheme
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 28 Apr 2015 18:13:12 -0000

> On Apr 28, 2015, at 4:48 AM, Dominic Parkes =
 wrote:
>=20
> On Tue, Mar 24, 2015 at 2:08 PM,  wrote:
>> My co-author and I have prepared a proposed VNC URI scheme for review =
by the community available at:
>> =
http://www.ietf.org/internet-drafts/draft-warden-appsawg-vnc-scheme-00.
>> txt
>=20
> Section 2.1 URI Scheme Syntax
>=20
>>  A "vnc" URI has the general form:
>>=20
>>     vnc://host:port?parm1=3Dvalue1¶m2=3Dvalue2...
>=20
> Per RFC3986 "username:password@" is deprecated, but we'd like to see =
some facility for credential passing being recognised here, even if the =
inclusion of passwords is strongly discouraged. Perhaps the more general =
"userinfo@" field. Existing VNC viewers such as Apple's Screen Sharing =
VNC client, and some of our own products use this form.

FYI, how we handled that for HTTP is in RFC7230, sec. 2.7.1:

   The URI generic syntax for authority also includes a deprecated
   userinfo subcomponent ([RFC3986], Section 3.2.1) for including user
   authentication information in the URI.  Some implementations make use
   of the userinfo component for internal configuration of
   authentication information, such as within command invocation
   options, configuration files, or bookmark lists, even though such
   usage might expose a user identifier or password.  A sender MUST NOT
   generate the userinfo subcomponent (and its "@" delimiter) when an
   "http" URI reference is generated within a message as a request
   target or header field value.  Before making use of an "http" URI
   reference received from an untrusted source, a recipient SHOULD parse
   for userinfo and treat its presence as an error; it is likely being
   used to obscure the authority for the sake of phishing attacks.


Cheers,

Roy T. Fielding                     
Senior Principal Scientist, Adobe   


From nobody Tue Apr 28 11:14:00 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A4061B2BC8 for ; Tue, 28 Apr 2015 11:13:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.391
X-Spam-Level: **
X-Spam-Status: No, score=2.391 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DATE_IN_PAST_03_06=1.592, SPF_HELO_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AdrsDA4GemAP for ; Tue, 28 Apr 2015 11:13:58 -0700 (PDT)
Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0702.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::702]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C0461B2BCC for ; Tue, 28 Apr 2015 11:13:55 -0700 (PDT)
Authentication-Results: gulbrandsen.priv.no; dkim=none (message not signed) header.d=none;
Received: from pc6 (81.151.162.168) by DBXPR07MB063.eurprd07.prod.outlook.com (10.242.147.22) with Microsoft SMTP Server (TLS) id 15.1.148.16; Tue, 28 Apr 2015 17:45:14 +0000
Message-ID: <046001d081da$dd0fd3c0$4001a8c0@gateway.2wire.net>
From: t.petch 
To: Arnt Gulbrandsen , 
References: <20150426155712.28596.qmail@ary.lan> <5EF79395E9C32A15465EA29E@JcK-HP8200.jck.com> <8ac2b0c3-b8da-4695-9ab3-82f952876aeb@gulbrandsen.priv.no>
Date: Tue, 28 Apr 2015 15:34:14 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [81.151.162.168]
X-ClientProxiedBy: DB4PR05CA0035.eurprd05.prod.outlook.com (25.160.40.45) To DBXPR07MB063.eurprd07.prod.outlook.com (10.242.147.22)
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB063;
X-Forefront-Antispam-Report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(377454003)(51704005)(13464003)(19580405001)(14496001)(77156002)(81816999)(81686999)(50226001)(1556002)(46102003)(76176999)(19580395003)(44736004)(50466002)(1456003)(86362001)(62966003)(23756003)(84392001)(116806002)(92566002)(44716002)(5001770100001)(61296003)(33646002)(15975445007)(66066001)(47776003)(40100003)(77096005)(87976001)(122386002)(107886001)(50986999)(42186005)(81156007)(62236002)(74416001)(7726001)(2101003); DIR:OUT; SFP:1102; SCL:1; SRVR:DBXPR07MB063; H:pc6; FPR:; SPF:None; MLV:nov; PTR:InfoNoRecords; LANG:en; 
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006)(3002001); SRVR:DBXPR07MB063; BCL:0; PCL:0; RULEID:; SRVR:DBXPR07MB063; 
X-Forefront-PRVS: 0560A2214D
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Apr 2015 17:45:14.7576 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR07MB063
Archived-At: 
Subject: Re: [apps-discuss] Proposal for adoption of Gopher document as an AppsAWG task
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 28 Apr 2015 18:13:59 -0000

----- Original Message -----
From: "Arnt Gulbrandsen" 
To: 
Sent: Sunday, April 26, 2015 8:48 PM

> +1
>
> If Nick can demonstrate rough consensus and running code (and I don't
think
> there's real doubt about either of those, even if the running code is
> little-used) then that should be enough. In real life there's also a
third
> condition: This is not the kind of draft that survives being a
timesink for
> the IETF regulars.

Not sure if I quite understand the third condition but, my personal form
of congestion control is such that I would want to see the work on file:
progress, perhaps to the sight of a Shepherd's write-up, before I commit
time to gopher:.

Tom Petch

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


From nobody Wed Apr 29 17:14:06 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C33A1A8A55 for ; Wed, 29 Apr 2015 17:14:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qPrG7CmnQ5N8 for ; Wed, 29 Apr 2015 17:14:03 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 738F51A8A5E for ; Wed, 29 Apr 2015 17:14:03 -0700 (PDT)
Received: from [192.168.0.3] (unknown [120.149.147.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id ED29C22E260 for ; Wed, 29 Apr 2015 20:14:01 -0400 (EDT)
From: Mark Nottingham 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Thu, 30 Apr 2015 10:13:59 +1000
References: <55414621.8060400@w3.org>
To: IETF Apps Discuss 
Message-Id: <43A6F50F-A9F2-4708-ADD1-879309ABB386@mnot.net>
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
X-Mailer: Apple Mail (2.2098)
Archived-At: 
Subject: [apps-discuss] Fwd: First Public Working Draft: Web Payments Use Cases 1.0
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 30 Apr 2015 00:14:06 -0000

FYI - W3C is beginning work on Web Payments.

> Begin forwarded message:
>=20
> Web Payments Use Cases 1.0
> W3C First Public Working Draft 16 April 2015
>=20
> http://www.w3.org/TR/2015/WD-web-payments-use-cases-20150416/
>=20
> Abstract
>=20
> This document is a prioritized list of Web payments use cases. Guided =
by these use cases, the W3C Web Payments Interest Group plans to derive =
architecture and associated technology requirements to integrate =
payments into the Open Web Platform. That work will form the basis of =
conversations with W3C groups and the broader payments industry about =
what standards (from W3C or other organizations) will be necessary to =
fulfill the use cases and make payments over the Web easier and more =
secure.
>=20
> Status
>=20
> The Web Payments IG has only had the opportunity to review a handful =
of the 40+ use cases, 120+ requirements, hundreds of pages of payments =
research submitted to the group via various other standards group output =
such as ISO20022, research documents from X9 and the US Federal Reserve, =
documents from the Web Payments Community Group, and input from the =
general public. Our desire is to align with the larger payments industry =
when it's possible to do so. Expect this document to be rapidly iterated =
upon with that desire in mind.
> [...]
> If you wish to make comments regarding this document, please send them =
to public-webpayments-comments@w3.org =


--
Mark Nottingham   https://www.mnot.net/


From nobody Wed Apr 29 23:44:36 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C3ED1ACD7B for ; Wed, 29 Apr 2015 23:44:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oz2XqZg5uKI1 for ; Wed, 29 Apr 2015 23:44:34 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF7571ACD25 for ; Wed, 29 Apr 2015 23:44:33 -0700 (PDT)
Received: from mb-aye.local ([IPv6:2601:9:3402:7bb1:7d28:eba:d78b:a4c9]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t3U6iVb5061549 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 30 Apr 2015 06:44:31 GMT (envelope-from joelja@bogus.com)
To: John C Klensin , appsawg-chairs@tools.ietf.org
references: <810A79A34BFE6E493CC1A167@JcK-HP8200.jck.com>
From: joel jaeggli 
x-enigmail-draft-status: N1110
message-id: <5541CF4E.10006@bogus.com>
Date: Wed, 29 Apr 2015 23:44:30 -0700
user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0
mime-version: 1.0
in-reply-to: <810A79A34BFE6E493CC1A167@JcK-HP8200.jck.com>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="iGckv3FVg4K00OQerE62c34rdnqesxeoa"
Archived-At: 
Cc: Nick Matavka , apps-discuss@ietf.org
Subject: Re: [apps-discuss] Proposal for adoption of Gopher document as an AppsAWG task
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 30 Apr 2015 06:44:35 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--iGckv3FVg4K00OQerE62c34rdnqesxeoa
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On 4/25/15 5:25 PM, John C Klensin wrote:
> Murray and Alexey,
>=20
> In order to shortcut some potential confusion and thrashing
> around, consider this note a request, on the lead author's
> behalf, to adopt Gopher-II: The Next Generation Gopher WWIS
> (draft-matavka-gopher-ii) as a WG document with the intention of
> processing it for standards track.
>=20
> If there is interest in proceeding on that basis, I
> recommend/request that you try to identify a shepherd or
> equivalent now so that he or she can help Nick with technical
> and procedural details.  For reasons which which you are both
> familiar, relying on me to do that job in the time I have
> available would be unwise and unfair to Nick although I'd be
> happy to try to help someonw who was taking the lead if that
> were needed.
>=20
> If the WG takes this on, one of the decisions that will need to
> be made early on is whether to go directly to a standards-track
> spec or to first publish an informational "state of the protocol
> in 2015" document and then build on it.

good lord, I hope that's not a hard decision...

gopher://gopher.floodgap.com/I/gophervr/gopherhd.png

> thanks,
>     john
>=20
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>=20



--iGckv3FVg4K00OQerE62c34rdnqesxeoa
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - http://gpgtools.org

iEYEARECAAYFAlVBz08ACgkQ8AA1q7Z/VrLLOgCghjEcJZfTWJYyA1JgxW42c1kI
3WMAn17DWBIlb0Dvfa1j/evcFLVhzdh7
=eIfw
-----END PGP SIGNATURE-----

--iGckv3FVg4K00OQerE62c34rdnqesxeoa--


From nobody Thu Apr 30 04:46:35 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91E071AD255 for ; Thu, 30 Apr 2015 04:46:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cqIJek9JwUjf for ; Thu, 30 Apr 2015 04:46:32 -0700 (PDT)
Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60ED71AD26E for ; Thu, 30 Apr 2015 04:46:31 -0700 (PDT)
Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 7025CFA0090; Thu, 30 Apr 2015 11:46:28 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1430394388; bh=3WqP7D0TjykgHVKyHFLhZcKa4cS6STktzC7P79EoaoY=; h=From:To:Subject:Date:In-Reply-To:References:From; b=C61fhURSrFQzxoxiS5YONT/2Oi0yZHaQXi2M47XCnzBShdSGzCYRRW8rsHtzfrm82 cUDWhIaTfI1JH+fHDBqkfcFGO4AcyTHLWcRvCUlqamWbkCPirsoxP8uvYxa8J/j2cU d1wz4heTVppUmOOxUiw3IpMPzYD7LsTwjVT596jY=
Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1430394387-31136-31135/12/4553; Thu, 30 Apr 2015 11:46:27 +0000
From: Arnt Gulbrandsen 
To: apps-discuss@ietf.org
Date: Thu, 30 Apr 2015 13:46:26 +0200
User-Agent: Trojita/v0.5-9-g8961725; Qt/4.8.6; X11; Linux; Ubuntu 15.04
Mime-Version: 1.0
Message-Id: <60d99f82-ebfe-4610-809d-6b20d7f1bd20@gulbrandsen.priv.no>
In-Reply-To: <046001d081da$dd0fd3c0$4001a8c0@gateway.2wire.net>
References: <20150426155712.28596.qmail@ary.lan> <5EF79395E9C32A15465EA29E@JcK-HP8200.jck.com> <8ac2b0c3-b8da-4695-9ab3-82f952876aeb@gulbrandsen.priv.no> <046001d081da$dd0fd3c0$4001a8c0@gateway.2wire.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Archived-At: 
Subject: Re: [apps-discuss] Proposal for adoption of Gopher document as an AppsAWG task
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 30 Apr 2015 11:46:33 -0000

t. petch writes:
> Not sure if I quite understand the third condition but, my personal form
> of congestion control is such that I would want to see the work on file:
> progress, perhaps to the sight of a Shepherd's write-up, before I commit
> time to gopher:.

Sorry. That was poorly phrased. I was just predicting that even if the 
gophers have running code and rough agreement on what it should do, they 
can still lose if they cause controversy and waste time _here_.

The draft will not survive controversy. I'm just predicting that
 - because it has rough consensus and running code, it can get to RFC
 - but if it wears out IETF people with quarrels of any sort, it'll die.

Arnt


From nobody Thu Apr 30 08:13:48 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 496D41A038A for ; Thu, 30 Apr 2015 08:13:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level: 
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eAPc_Yw0w8e6 for ; Thu, 30 Apr 2015 08:13:45 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99DBA1A877D for ; Thu, 30 Apr 2015 08:13:45 -0700 (PDT)
Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1Ynq9h-000FR2-5C; Thu, 30 Apr 2015 11:13:37 -0400
Date: Thu, 30 Apr 2015 11:13:32 -0400
From: John C Klensin 
To: joel jaeggli , appsawg-chairs@tools.ietf.org
Message-ID: <52ECC31927EED442FEB6A0E0@JcK-HP8200.jck.com>
In-Reply-To: <5541CF4E.10006@bogus.com>
References: <810A79A34BFE6E493CC1A167@JcK-HP8200.jck.com> <5541CF4E.10006@bogus.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.35
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: 
Cc: Nick Matavka , apps-discuss@ietf.org
Subject: Re: [apps-discuss] Proposal for adoption of Gopher document as an AppsAWG task
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 30 Apr 2015 15:13:47 -0000

--On Wednesday, April 29, 2015 23:44 -0700 joel jaeggli
 wrote:

>> If the WG takes this on, one of the decisions that will need
>> to be made early on is whether to go directly to a
>> standards-track spec or to first publish an informational
>> "state of the protocol in 2015" document and then build on it.
> 
> good lord, I hope that's not a hard decision...
> 
> gopher://gopher.floodgap.com/I/gophervr/gopherhd.png

Joel,

Unless and unless someone picks up the windmill-charging spear,
I'm trying to be as much of a facilitator of, and as neutral
about, this as possible.  As a result, I'm more inclined to say
"this is a possibility" than "this is what we ought to do".
Even where bringing the "do you want it" question to AppsAWG is
concerned, I believed (and believe) it was procedurally correct
to ask independent of my opinions about what should be done and
how this should be handled.

However, as to what is a hard decision or not, even getting the
posted draft into a form that makes it easy to move forward (in
any stream) involved more than bit of work, work that wouldn't
be worth doing if neither the IETF nor the ISE had any interest.
Nick how has an xml2rfc conversion in hand and is presumably
working on/with it, but we (for some version of "we". appear to
need to choose among the following (exaggerating a few slightly):

(1) Note Gopher's location in the trashbin of history and
optionally make other suggestions about what people might do (or
where to find larger piles of sand to pound).

(2) Whip Nick's I-D into shape and ask the ISE to publish it as
a purely informational opinion piece about Gopher role and
status.

(3) Decide that some of the work that has been done on Gopher-2
already constitutes a standard from an external body and decide
that it (or pointers to it) should be published for the
information of the community (as either an individual submission
to the IETF or an independent submission).

(4) Decide that Gopher-2 really deserves to be standardized in
the IETF and that there is sufficient interest and willingness
to review to make an assertion of IETF consensus meaningful.
If we make that decision, we still need to decide among AppsAWG,
a separate WG, and an individual submission.  I have a bias
about that (and think it is consistent with Barry's initial
thoughts) but, for the moment, am keeping it mostly to myself.

Except for (1), to which I'm definitely opposed because I think
it is incorrect, I'm trying to remain fairly agnostic about the
options, preferring to see a consensus develop about what the
right thing is to do rather than to advocate for one approach.
I believe that Nick is in much the same situation although I
haven't discussed it with him explicitly.

best,
    john



From nobody Thu Apr 30 08:37:27 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75B531A1EED for ; Thu, 30 Apr 2015 08:37:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level: 
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ij3U8_IP3vt9 for ; Thu, 30 Apr 2015 08:37:19 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 658A61B2CC7 for ; Thu, 30 Apr 2015 08:37:19 -0700 (PDT)
Received: from [198.252.137.35] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1YnqWc-000Fhm-8V; Thu, 30 Apr 2015 11:37:18 -0400
Date: Thu, 30 Apr 2015 11:37:13 -0400
From: John C Klensin 
To: Arnt Gulbrandsen , apps-discuss@ietf.org
Message-ID: <79C3716EE141838E0FCF95E6@JcK-HP8200.jck.com>
In-Reply-To: <60d99f82-ebfe-4610-809d-6b20d7f1bd20@gulbrandsen.priv.no>
References: <20150426155712.28596.qmail@ary.lan> <5EF79395E9C32A15465EA29E@JcK-HP8200.jck.com> <8ac2b0c3-b8da-4695-9ab3-82f952876aeb@gulbrandsen.priv.no> <046001d081da$dd0fd3c0$4001a8c0@gateway.2wire.net> <60d99f82-ebfe-4610-809d-6b20d7f1bd20@gulbrandsen.priv.no>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.35
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: 
Subject: Re: [apps-discuss] Proposal for adoption of Gopher document as an AppsAWG task
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 30 Apr 2015 15:37:24 -0000

--On Thursday, April 30, 2015 13:46 +0200 Arnt Gulbrandsen
 wrote:

> Sorry. That was poorly phrased. I was just predicting that
> even if the gophers have running code and rough agreement on
> what it should do, they can still lose if they cause
> controversy and waste time _here_.
> 
> The draft will not survive controversy. I'm just predicting
> that
>  - because it has rough consensus and running code, it can get
> to RFC
>  - but if it wears out IETF people with quarrels of any sort,
> it'll die.

Arnt,

At one level I completely agree with you, and do so from the
perspective of one person who is easily worn out by long,
repetitive or low-content threads.   However, if there is a
protocol that has active development and user communities (and,
by definition, running code, etc.) and people in the IETF
community who are sincerely interested in contributing to it and
adding value to it, it would say some very bad things about the
state of the IETF if a small group of people who either don't
like a protocol on aesthetic grounds or because they are
advocates for something else can kill IETF involvement with that
protocol by simply generating enough noise.

So I think there is something of a balance to be found and I'm
not sure we have it yet.

On the other hand, if a significant fraction of the community
wants a "modern Gopher" standard, then perhaps the risk of being
overwhelmed by noise is an argument for trying to do the work in
a tightly-focused WG whose leadership could more easily push
those whose interest is in disruption (by starting fights or
otherwise) off the mailing list to enable work to get done.

best,
   john


From nobody Thu Apr 30 10:13:05 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57DB01A90F6 for ; Thu, 30 Apr 2015 10:13:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.7
X-Spam-Level: 
X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6oT8R_tqI6v for ; Thu, 30 Apr 2015 10:13:01 -0700 (PDT)
Received: from strange.aox.org (strange.aox.org [80.244.248.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3D351A9044 for ; Thu, 30 Apr 2015 10:13:01 -0700 (PDT)
Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 6C190FA0090; Thu, 30 Apr 2015 17:12:59 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1430413979; bh=J8268/bfyMdyvnZIToyd2TVCzHyj3sx5ShUkow13wyY=; h=From:To:Subject:Date:In-Reply-To:References:From; b=e0YEt7vk499jsvH83wzoXsV4ZajUQfOV2Ta9VBnJLpzahp0LOKRwJWstEkX/SgU4X E5DHgLxyAukzVxorK9zCQ1I95IrluD1g/J/8/1pWp0LJXuwxOJ+wNOPBUtgPVhAe0H sMxYLqgcDWk+lSIxm0f5pWTCZ9uYAGFi8RI6P/Oc=
Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1430413978-18511-18510/12/1; Thu, 30 Apr 2015 17:12:58 +0000
From: Arnt Gulbrandsen 
To: apps-discuss@ietf.org
Date: Thu, 30 Apr 2015 19:12:57 +0200
User-Agent: Trojita/v0.5-9-g8961725; Qt/4.8.6; X11; Linux; Ubuntu 15.04
Mime-Version: 1.0
Message-Id: <2e6e927d-2965-45a9-969c-dda3a93600a8@gulbrandsen.priv.no>
In-Reply-To: <79C3716EE141838E0FCF95E6@JcK-HP8200.jck.com>
References: <20150426155712.28596.qmail@ary.lan> <5EF79395E9C32A15465EA29E@JcK-HP8200.jck.com> <8ac2b0c3-b8da-4695-9ab3-82f952876aeb@gulbrandsen.priv.no> <046001d081da$dd0fd3c0$4001a8c0@gateway.2wire.net> <60d99f82-ebfe-4610-809d-6b20d7f1bd20@gulbrandsen.priv.no> <79C3716EE141838E0FCF95E6@JcK-HP8200.jck.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Archived-At: 
Subject: Re: [apps-discuss] Proposal for adoption of Gopher document as an AppsAWG task
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 30 Apr 2015 17:13:03 -0000

I have to agree that we occasionally have problems with noisy rhetoric. 
(RFC6851 isn't very different from a draft someone posted in 2001, and I 
don't think that draft was the first one, either. Most of the delay was due 
to rhetoric.)

I'll review the gopher document. Don't care at all about its formal status 
so long as the status includes the letters "r", "f" and "c" and four 
digits.

Arnt


From nobody Thu Apr 30 10:21:07 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C519A1B2E5A for ; Thu, 30 Apr 2015 10:21:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.103
X-Spam-Level: 
X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zsqivjb-D1Zd for ; Thu, 30 Apr 2015 10:21:04 -0700 (PDT)
Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [IPv6:2607:f0d0:3001:aa::2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD7681A88B9 for ; Thu, 30 Apr 2015 10:21:04 -0700 (PDT)
Received: from kitterma-e6430.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id 15081C4016C for ; Thu, 30 Apr 2015 12:21:03 -0500 (CDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1430414463; bh=o82X/o2Ua7q7O4HqQotnNtDsZzA3oQmskZBkSnWQymM=; h=From:To:Subject:Date:In-Reply-To:References:From; b=oxkcjRm0DbXLZAm6uT0ceObaDwPEOf+WL2qn8ciwn7D8r7rcDw62vYeuddc8apRZQ zgIs71zHNBhbGz7Ctx4pFipUlMEhaIiy3wEX3IKiSghxB/wGInoJa/iYvZd2axHjsF nF/4Ky0Unw54bld0S/CPwm+yGTB4wndPZsCem2Es=
From: Scott Kitterman 
To: apps-discuss@ietf.org
Date: Thu, 30 Apr 2015 13:21:02 -0400
Message-ID: <1661391.eimJUi6lYJ@kitterma-e6430>
User-Agent: KMail/4.13.3 (Linux/3.13.0-51-generic; KDE/4.13.3; x86_64; ; )
In-Reply-To: <2e6e927d-2965-45a9-969c-dda3a93600a8@gulbrandsen.priv.no>
References: <20150426155712.28596.qmail@ary.lan> <79C3716EE141838E0FCF95E6@JcK-HP8200.jck.com> <2e6e927d-2965-45a9-969c-dda3a93600a8@gulbrandsen.priv.no>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: 
Subject: Re: [apps-discuss] Proposal for adoption of Gopher document as an AppsAWG task
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 30 Apr 2015 17:21:05 -0000

On Thursday, April 30, 2015 07:12:57 PM Arnt Gulbrandsen wrote:
> I have to agree that we occasionally have problems with noisy rhetoric.
> (RFC6851 isn't very different from a draft someone posted in 2001, and I
> don't think that draft was the first one, either. Most of the delay was due
> to rhetoric.)
> 
> I'll review the gopher document. Don't care at all about its formal status
> so long as the status includes the letters "r", "f" and "c" and four
> digits.
 
For a moment, I thought I saw another DoS vector, but then I remembered that 
the number with five digits also has four.

Scott K


From nobody Thu Apr 30 19:16:08 2015
Return-Path: 
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9CD51B2FD1 for ; Thu, 30 Apr 2015 19:16:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.147
X-Spam-Level: 
X-Spam-Status: No, score=-0.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AMWzmvlqb2nG for ; Thu, 30 Apr 2015 19:16:04 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0BAE1B2FCF for ; Thu, 30 Apr 2015 19:16:04 -0700 (PDT)
Received: from [192.168.0.3] (unknown [120.149.147.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 6081722E260; Thu, 30 Apr 2015 22:16:02 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: Mark Nottingham 
In-Reply-To: <04BE725F-B29F-497D-B15A-BAFA711BA57B@adobe.com>
Date: Fri, 1 May 2015 12:15:58 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <17579F18-2849-4CB1-B399-B921FED8213C@mnot.net>
References:  <04BE725F-B29F-497D-B15A-BAFA711BA57B@adobe.com>
To: Larry Masinter 
X-Mailer: Apple Mail (2.2098)
Archived-At: 
Cc: Nick Matavka , "apps-discuss@ietf.org" 
Subject: Re: [apps-discuss] independent submission process for draft-matavka-gopher-ii
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
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, 01 May 2015 02:16:06 -0000

Oh, no you don't.

APPSWG is more than appropriate for this.

Cheers,


> On 27 Apr 2015, at 1:44 am, Larry Masinter  wrote:
>=20
> Gopher is suitable for marking historic.=20
> I think this should be referred to httpbis.
>=20
> --
> http://larry.masinter.net
>=20
>> On Apr 25, 2015, at 9:21 AM, Nick Matavka =
 wrote:
>>=20
>> Hello, world!
>>=20
>> I sent off an independent submission as a proposed standard, in =
regards to extensions to the Gopher WWIS.  Although the current =
iteration of the Gopher protocol is half-Informational and =
half-unofficial memo (by which I mean the optional Gopher+ extensions), =
it was recommended to me that I put my draft on the Standards Track.  =
I'm not opposed to this idea, which is why draft-matavka-gopher-ii is =
currently sitting on IETF servers on said Standards Track.
>>=20
>> My concerns are mostly related to IETF process.  How are independent =
submissions handled?  Am I supposed to receive an eMail from one of the =
review people stating the nits that need to be corrected?  The structure =
is fine, I'm now curious as to how an Internet-Draft becomes a Standard. =
 I'm also curious as to how ongoing fixes are incorporated.  For =
instance, the informal workgroup that discusses Gopher is now floating =
the idea of Gopher over TLS, and they have reached the consensus that =
GopherS (as they have called it) would be a beneficial, but optional, =
part of the Gopher system.  Perhaps a footnote to that effect would fit =
in the Internet-Draft, but I'm not sure how 00 becomes 01 and 02 and 03.
>>=20
>> Anyway, any help you could give me is appreciated. =20
>>=20
>> Edward Matavka
>>=20
>>=20
>>=20
>> --=20
>>       /^\/^\
>>       \----|
>>   _---'---~~~~-_ =20
>>    ~~~|~~L~|~~~~
>>       (/_  /~~--
>>     \~ \  /  /~
>>   __~\  ~ /   ~~----,
>>   \    | |       /  \ =20
>>   /|   |/       |    |
>>   | | | o  o     /~   | =20
>> _-~_  |        ||  \  /
>> (// )) | o  o    \\---'
>> //_- |  |          \=20
>> //   |____|\______\__\
>> ~      |   / |    |
>>       |_ /   \ _|
>>     /~___|  /____\        =20
>> _______________________________________________
>> apps-discuss mailing list
>> apps-discuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/apps-discuss
>=20
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss

--
Mark Nottingham   https://www.mnot.net/