From nobody Sun Feb 1 09:13: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 966961A898B for ; Sun, 1 Feb 2015 09:12:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 a3c4LiYHutm7 for ; Sun, 1 Feb 2015 09:12:56 -0800 (PST) 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 65B5F1A899A for ; Sun, 1 Feb 2015 09:12:56 -0800 (PST) Received: from [192.168.123.7] (unknown [23.241.1.22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id B91CD22E263; Sun, 1 Feb 2015 12:12:54 -0500 (EST) Message-ID: <54CE5E92.4090108@seantek.com> Date: Sun, 01 Feb 2015 09:12:50 -0800 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: IETF Apps Discuss References: <20141222230149.31980.3522.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-text-markdown-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: Sun, 01 Feb 2015 17:12:58 -0000 On 1/9/2015 7:02 AM, Michel Fortin wrote: > The complexity has been scaled down from the earlier drafts, that's goo= d. > > Having a registry for variants remains unnecessary in my view, and, whi= le I understand Sean personally has a use case for it, what remains uncle= ar to me is how the registry is going to be populated. It seems to me tha= t the only person that needs it is Sean and thus he'll either be the one = populating it or it'll be left mostly empty. Perhaps I'm wrong, but who e= lse has shown interest in the thing? I wanted to respond to this point (and if any disagree, please voice a=20 different view). First of all, compared to prior drafts (particularly draft-03) this=20 latest draft-05 and use-cases-01 are drastically simplified. I am=20 willing to simplify them further...but need concrete direction.=20 Otherwise I think we are on the final stretch. Various efforts over the years to resolve the Markdown "standardization=20 problem" have turned into cat-herding exercises. Even now in the "stmd"=20 community (aka CommonMark community) , most = threads have turned into "me too" pleas to add "just one more feature".=20 Constantly changing specs and definitions hinder interoperability, i.e., = getting two different implementations (possibly across space and time)=20 to produce consistent results. As folks are desiring to use Markdown for = various archival or pre-archival purposes, this is a problem because=20 just labeling content as .markdown or text/markdown alone will not=20 result in uniform behavior across space and time. I do not believe that Markdown has a standardization problem, because it = was not meant to be standardized. It's like MIT's old Building 20: if=20 the wall doesn't work for you, poke a hole in it for your own purposes=20 and ask questions later. That was part of John Gruber's design=20 philosophy. However, since Markdown is ever-changing, there is a=20 labeling problem for people who want or need consistent behavior. The registry is going to be populated by "people who have a need to=20 interoperate". I.e., if you want interop (per above: consistent=20 referenceable behavior), you'll take the trouble to register an=20 identifier. I have tried to simplify the registration template as much=20 as possible, without sacrificing the information required for=20 interoperability. For example, I removed the version sub-identifier=20 since that was a source of additional complexity. If someone wants to=20 register "CommonMark-0.17" distinctly from "CommonMark" (version=20 unspecified), that is possible. Both the Markdown community and this (IETF) community have expressed a=20 need for registered variants. See, e.g.,=20 point 5. If the=20 registration activity slows down, that's fine. Either people will have=20 moved from Markdown to the shiny new thing, or they don't need to label=20 their content in an interoperable way. Thanks, Sean From nobody Wed Feb 4 07: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 DE8E31A8A06 for ; Wed, 4 Feb 2015 07:22:44 -0800 (PST) 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_20=-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 rZaQXGscyGvN for ; Wed, 4 Feb 2015 07:22:43 -0800 (PST) Received: from relay12.mail.ox.ac.uk (relay12.mail.ox.ac.uk [129.67.1.163]) by ietfa.amsl.com (Postfix) with ESMTP id 057E91A046D for ; Wed, 4 Feb 2015 07:22:43 -0800 (PST) Received: from smtp5.mail.ox.ac.uk ([163.1.2.207]) by relay12.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from ) id 1YJ1mr-00079V-f6; Wed, 04 Feb 2015 15:22:41 +0000 Received: from gklyne.plus.com ([80.229.154.156] 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 1YJ1mr-0003Ih-Hp; Wed, 04 Feb 2015 15:22:41 +0000 Message-ID: <54D23945.6000204@ninebynine.org> Date: Wed, 04 Feb 2015 15:22:45 +0000 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: Larry Masinter , Bjoern Hoehrmann References: <54B9B78F.3060000@intertwingly.net> <54BB2AB3.5090805@intertwingly.net> <54BBC640.5000607@intertwingly.net> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Scope of RFC3986 and successor - what is a URI? 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, 04 Feb 2015 15:22:45 -0000 (Responding here because I think it's my claim that's quoted here...) On 01/02/2015 00:31, Larry Masinter wrote: > "A parser can only be RFC3986-compliant in the extent to which it correctly makes this determination in accordance with RFC3986" > > Just to make sure we're using the same vocabulary: > > We usually talk about "conformance" and not "compliance", I think. A specification has a scope and defines roles, and conformance requirements for agents that fill those roles. With a language or protocol element kind of definition, the roles usually include "writer", "reader", "validator". A reader does parsing (the parser part) and interpreting (the part that does something with the parsed components that are the result of parsing. I'm a bit vague about this conformance/compliance terminology distinction, but I'm happy to accept your terminology here. I'm less clear about where you are going with "reader", "writer" and "validation" roles. Particularly it's not clear to me that a reader always parses. > > If you agree with those definitions, then it is reasonable to not require conforming readers to not be "liberal in what they accept", and RFC 3986 makes no explicit conformance requirement for parsers used by readers of the URI protocol element. I agree with this, modulo any implications of my previous comment. My thoughts on conformance requirements: reader: must accept valid URIs (i.e. that conform to given syntax); may also accept other strings, but the effects of so doing may be ill-defined. writer: must generate/present valid URIs validator: determines if a given string conforms the defined syntax. I generally consider *part* of the role of a parser is to be a validator, hence my comment quoted above. (I do agree that *useful* parsers generally do more that that - I'm saying it's just the validation part that might be considered to be RFC3986 conformant or not.) With reference to the prior discussions about scope, I note that many libraries act as readers and provide additional helpful functions (IMO beyond the scope of RFC3986) - the regex appendix in RFC3986 would be an example of this. Failure to reject a non-confirming URI string does not, IMO, mean that either they or RFC3986 are broken. Which I think is the point you also make? #g From nobody Wed Feb 4 07:33: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 C700B1A8A7B for ; Wed, 4 Feb 2015 07:33:41 -0800 (PST) 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_20=-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 PCp5hvb5cQRn for ; Wed, 4 Feb 2015 07:33:39 -0800 (PST) Received: from relay13.mail.ox.ac.uk (relay13.mail.ox.ac.uk [129.67.1.166]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD931A87E8 for ; Wed, 4 Feb 2015 07:33:39 -0800 (PST) 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 1YJ1xS-00073X-fz; Wed, 04 Feb 2015 15:33:38 +0000 Received: from gklyne.plus.com ([80.229.154.156] 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 1YJ1xR-0007hu-F5; Wed, 04 Feb 2015 15:33:37 +0000 Message-ID: <54D23BD3.9020202@ninebynine.org> Date: Wed, 04 Feb 2015 15:33:39 +0000 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: Sean Leonard , IETF Apps Discuss References: <20141222230149.31980.3522.idtracker@ietfa.amsl.com> <54CE5E92.4090108@seantek.com> In-Reply-To: <54CE5E92.4090108@seantek.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Oxford-Username: zool0635 Archived-At: Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-text-markdown-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, 04 Feb 2015 15:33:42 -0000 Sean, You asked for feedback - I'm not exactly disagreeing, but don't think the registry is a sword to be fallen upon... I agree with the general gist that it's sometimes useful to be able to describe or name Markdown variants for specific purposes. Hence I believe a variant parameter for the MIME content-type is useful to have. How to document consensus on what the variant values mean? An IANA registry is one way of doing this, and seems a reasonable option to the extent it relates to a parameter defined in an IETF protocol element. But other options are also possible, and if there's significant push-back against defining an IANA registry, I'd be inclined to create a wiki somewhere (GitHub?) and point to that instead. If it turns out to be useful, a more formal registry could be defined later. It might even be the case that the best design for a registry would be clearer if there were some track record of (less formal) documentation of variants. Just my 2¢. #g -- On 01/02/2015 17:12, Sean Leonard wrote: > On 1/9/2015 7:02 AM, Michel Fortin wrote: >> The complexity has been scaled down from the earlier drafts, that's good. >> >> Having a registry for variants remains unnecessary in my view, and, while I >> understand Sean personally has a use case for it, what remains unclear to me >> is how the registry is going to be populated. It seems to me that the only >> person that needs it is Sean and thus he'll either be the one populating it or >> it'll be left mostly empty. Perhaps I'm wrong, but who else has shown interest >> in the thing? > > I wanted to respond to this point (and if any disagree, please voice a different > view). > > First of all, compared to prior drafts (particularly draft-03) this latest > draft-05 and use-cases-01 are drastically simplified. I am willing to simplify > them further...but need concrete direction. Otherwise I think we are on the > final stretch. > > Various efforts over the years to resolve the Markdown "standardization problem" > have turned into cat-herding exercises. Even now in the "stmd" community (aka > CommonMark community) , most threads have turned > into "me too" pleas to add "just one more feature". Constantly changing specs > and definitions hinder interoperability, i.e., getting two different > implementations (possibly across space and time) to produce consistent results. > As folks are desiring to use Markdown for various archival or pre-archival > purposes, this is a problem because just labeling content as .markdown or > text/markdown alone will not result in uniform behavior across space and time. > > I do not believe that Markdown has a standardization problem, because it was not > meant to be standardized. It's like MIT's old Building 20: if the wall doesn't > work for you, poke a hole in it for your own purposes and ask questions later. > That was part of John Gruber's design philosophy. However, since Markdown is > ever-changing, there is a labeling problem for people who want or need > consistent behavior. > > The registry is going to be populated by "people who have a need to > interoperate". I.e., if you want interop (per above: consistent referenceable > behavior), you'll take the trouble to register an identifier. I have tried to > simplify the registration template as much as possible, without sacrificing the > information required for interoperability. For example, I removed the version > sub-identifier since that was a source of additional complexity. If someone > wants to register "CommonMark-0.17" distinctly from "CommonMark" (version > unspecified), that is possible. > > Both the Markdown community and this (IETF) community have expressed a need for > registered variants. See, e.g., > point 5. If the > registration activity slows down, that's fine. Either people will have moved > from Markdown to the shiny new thing, or they don't need to label their content > in an interoperable way. > > Thanks, > > Sean > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From nobody Wed Feb 4 10:22: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 70BDE1A1AF6 for ; Wed, 4 Feb 2015 10:22:17 -0800 (PST) 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 V8btjd7Jf9yg for ; Wed, 4 Feb 2015 10:22:15 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0778.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::778]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B90F81A0155 for ; Wed, 4 Feb 2015 10:22:14 -0800 (PST) Received: from pc6 (81.151.167.59) by AMSPR07MB049.eurprd07.prod.outlook.com (10.242.81.11) with Microsoft SMTP Server (TLS) id 15.1.75.20; Wed, 4 Feb 2015 18:21:51 +0000 Message-ID: <01a401d040a7$3bfb85c0$4001a8c0@gateway.2wire.net> From: t.petch To: "Murray S. Kucherawy" , Matthew Kerwin References: <20150112011216.17665.13268.idtracker@ietfa.amsl.com> Date: Wed, 4 Feb 2015 18:20:14 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit 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.167.59] X-ClientProxiedBy: DB4PR03CA0022.eurprd03.prod.outlook.com (25.160.39.160) To AMSPR07MB049.eurprd07.prod.outlook.com (10.242.81.11) Authentication-Results: gmail.com; dkim=none (message not signed) header.d=none; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB049; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:AMSPR07MB049; X-Forefront-PRVS: 04772EA191 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(24454002)(377454003)(13464003)(23676002)(66066001)(42186005)(77156002)(46102003)(40100003)(122386002)(62966003)(50466002)(230783001)(1556002)(33646002)(84392001)(116806002)(47776003)(62236002)(19580395003)(19580405001)(44716002)(61296003)(87976001)(77096005)(92566002)(50226001)(15975445007)(44736004)(76176999)(81686999)(50986999)(81816999)(86362001)(1456003); DIR:OUT; SFP:1102; SCL:1; SRVR:AMSPR07MB049; H:pc6; FPR:; SPF:None; MLV:sfv; LANG:en; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB049; X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Feb 2015 18:21:51.4433 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB049 Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-00.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, 04 Feb 2015 18:22:17 -0000 I was about to ask about progress with the mini-charter and then I noticed that this I-D is in the deliverables for July 2015. Digging further, I see ================================================= The "file" URI scheme is woefully out of date. The document that defines it, RFC 1738, has been superseded by the generic URI syntax of RFC 3986, and the status of RFC 1738 is listed as "Obsolete". As such, the "file" URI scheme is viewed by many in the Internet community as being without a current defining standard, and in need of updating to match current standards and implementations. This document defines an updated "file" URI scheme, promoting interoperability by being compatible with the generic syntax of RFC 3986, while enumerating commonly-encountered variations that have arisen during the scheme's long history of vague standardisation. Specifically: A normative syntax specification that defines a subset of RFC 3986 URI syntax that will be considered valid "file" URI strings, and sufficient to cover common "file" URI usage in the wild where it does not conflict with RFC 3986. An informative section describing common syntaxes that are not compatible with RFC 3986, possibly with advice for translating to a compatible syntax. An informative section that describes some common "file" URI usages and how they map onto underlying file systems. Reviewers: Julian Reschke <​julian.reschke@gmx.de> Nico Williams <​nico@cryptonector.com> Sean Leonard <​dev+ietf@seantek.com> ========================================= I do not recall seeing this on the list - well, I do now. And I think that this means that we can start work! Tom Petch ----- Original Message ----- From: "Murray S. Kucherawy" To: "Matthew Kerwin" Cc: "IETF Apps Discuss" Sent: Monday, January 12, 2015 5:01 PM Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-file-scheme-00.txt > On Sun, Jan 11, 2015 at 5:26 PM, Matthew Kerwin > wrote: > > > As you can see below, the file: scheme draft has been adopted by the WG. > > I'm in the process of writing a mini-charter, part of which is a list of > > people who will commit to doing timely reviews of the document. > > > > Could I please ask for volunteers to provide reviews, whose names I can > > list in the charter? > > > > APPSAWG also regularly invites people other than the co-chairs to act as > document shepherd for the documents we develop. If anyone would be > interested in filling this role for this document, please email > appsawg-chairs@tools.ietf.org. > > -MSK > ------------------------------------------------------------------------ -------- > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From nobody Fri Feb 6 06:34: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 2BA7D1A1AC6 for ; Fri, 6 Feb 2015 06:34:18 -0800 (PST) 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 WRYnIuyd8mzy for ; Fri, 6 Feb 2015 06:34:16 -0800 (PST) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::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 3280C1A1AD2 for ; Fri, 6 Feb 2015 06:34:16 -0800 (PST) Received: by mail-lb0-f170.google.com with SMTP id z11so4947446lbi.1 for ; Fri, 06 Feb 2015 06:34:14 -0800 (PST) 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:cc:content-type; bh=SZnV+pQ4q7Lg8GLjriyvFYRK00FhuvsBCd/S8fWdrYA=; b=XVhCa1P8Yq1HtmqI1mD8v2fc1M766XYjlKeMgNS856QblI1Ve2MZZFbvksev9o8kwz tSJWY3MSP0YqIsjxqo/jzN6PmuZjmsPvOoeTn+u/z7MCSOrCW2cBd/YeeX0VWb1VEu/z 0fSNz7jtNsPbsn/kP8nVBxdhXYVRs4YjxwKi/Q/DvryCjznAj2PR7M4I44a6L6bGELfH 5oId/y1TZOZRSByVMR16/46KtcNtXNos44A30co81YGngh5pZZPfHHoLN1c+9dkL5uum NhSfvqY3NEnEQTjPULcc7LUdYBEB8n3+lJMjn2+PopIxToUoVIxEVqbpBhQOwsadgBSE lcrg== MIME-Version: 1.0 X-Received: by 10.152.28.129 with SMTP id b1mr2977799lah.37.1423233254620; Fri, 06 Feb 2015 06:34:14 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.152.183.225 with HTTP; Fri, 6 Feb 2015 06:34:14 -0800 (PST) Date: Fri, 6 Feb 2015 09:34:14 -0500 X-Google-Sender-Auth: L7bBMUBMnS_BhoUEcl7T295EDHI Message-ID: From: Barry Leiba To: draft-ietf-appsawg-multipart-form-data@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Cc: Apps Discuss Subject: [apps-discuss] AD review of draft-ietf-appsawg-multipart-form-data-07 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, 06 Feb 2015 14:34:20 -0000 Larry, I'm sorry for the huge delay in handling this. I've given the document a review, and here are my comments -- most are editorial, but there are a few that I think we should sort out before I request last call. -- Section 1 should have a note for the RFC Editor to remove it at publication. Better, just remove it now, yes? -- Section 3 -- You should include a reference to the definition of URL encoding -- it's called "percent-encoding" in RFC 3986. Also, that encoding isn't used just for non-ASCII characters, but for any characters outside the set that can be legally included with ASCII encoding. You should rephrase this. Also also, percent-encoding is not case-sensitive (the characters don't have to be lower case). If this differs from what's defined elsewhere, it should explicitly say so, and why. -- Section 5.1 -- Each field's form data of the form is sent, in the order defined by the sending application and form, as a part of the multipart stream. Can you re-word this and explain it better? I find it unclear in a few ways, the most important of which is that I don't know what "part of the multipart stream" means. The boundary is supplied as a "boundary" parameter to the "multipart/form-data type". The closing quote is misplaced. -- Section 5.2 -- with the body of the part corresponding to the form data of the "user" field. "Corresponding to"? I think "containing" is the right word here. -- Section 5.3 -- For form data that represents the content of a file, a name for the file SHOULD be supplied as well Why "SHOULD"? Why does this affect interoperability, if the other end can't figure out whether you just didn't feel like including the file name, or that the file name is meaningless or private? NOTE: the method in [RFC5987] for using a "filename*" paramter of the "Content-Disposition" header SHOULD NOT be used. What method? RFC 5987 does not contain any of the strings "filename", "content-", nor "disposition". Ah. Perhaps you mean this?: NEW The encoding method described in [RFC5987], which would add a "filename*" paramter to the "Content-Disposition" header, SHOULD NOT be used. END Again, why is this a 2119 "SHOULD NOT"? What happens if I do use it? Why might I decide use it, despite the "SHOULD NOT" here? -- Section 5.4 -- [RFC2388] suggested that multiple files for a single form field be transmitted using a nested multipart/mixed part. To match widely deployed implementations, multiple files SHOULD be sent by supplying each file in a separate part, but all with the same "name" parameter. Is it intended that the mechanism in the first paragraph be deprecated? That's what it looks like from what you say in this section. So why not say that, and why is the SHOULD not a MUST (you already advise receivers to tolerate the deprecated mechanism, so that should be fine)? That way, you'd be saying "MUST generate the new way; SHOULD accept the old way on receipt." -- Section 6.1 -- While [RFC2388] suggested that non-ASCII field names should be encoded according to the method in [RFC2047] if they contain characters outside of US- ASCII, this practice doesn't seem to have been followed widely. There's redundancy in there; I suggest removing " if they contain characters outside of US- ASCII", as you already say "non-ASCII". -- Section 6.1.1 -- For broadest interoperability with existing deployed software, those creating forms SHOULD avoid non-ASCII field names. This should not be a burden, because in general the field names are not visible to users. I think it's worth adding a reminder that the field names in the underlying form don't have to match the names the user might see on the screen. That would clarify the "not visible to users" part. -- Section 6.2 -- Form processors given forms with a well-defined ordering SHOULD send back results in the order received and preserve duplicate field names, in order. Intermediaries MUST NOT reorder the results. (Note that there are some forms which do not define a natural order of appearance.) Why is this SHOULD, and not MUST? What do I need to take into account when I'm deciding whether to comply with this SHOULD or not? Why might I want or need not to do it? -- Section 8 -- Now that many (all major) browsers have autofill options, it strikes me that it might be possible for a server to include in an otherwise unremarkable form some fields that are presented in a way that a user won't notice (white on white, very tiny, or the like) and that have names that the browser will fill information in when the user autofills the other fields and doesn't notice that these are being autofilled as well. That could expose information that the user isn't intending to send to this site. This is a UI issue, not directly an issue with the protocol here... but this is the only place to note the exposure and warn implementors to be aware of it. Might it be worth putting something in here? -- Section 9 -- What is this meant to be? It's not in the IANA Considerations section. It's not a complete template. Is it meant to be an update to the original template? Or what? -- Barry From nobody Fri Feb 6 06:34: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 6262F1A1AD2; Fri, 6 Feb 2015 06:34:52 -0800 (PST) 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 5gEagR32TqWs; Fri, 6 Feb 2015 06:34:42 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD631A1AFE; Fri, 6 Feb 2015 06:34:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.10.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150206143441.28694.30094.idtracker@ietfa.amsl.com> Date: Fri, 06 Feb 2015 06:34:41 -0800 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: Fri, 06 Feb 2015 14:34:53 -0000 IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-multipart-form-data/ From nobody Fri Feb 6 06:34:58 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 E3D101A1AF8; Fri, 6 Feb 2015 06:34:53 -0800 (PST) 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 6262F1A1AD2; Fri, 6 Feb 2015 06:34:52 -0800 (PST) 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 5gEagR32TqWs; Fri, 6 Feb 2015 06:34:42 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD631A1AFE; Fri, 6 Feb 2015 06:34:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.10.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150206143441.28694.30094.idtracker@ietfa.amsl.com> Date: Fri, 06 Feb 2015 06:34:41 -0800 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: Fri, 06 Feb 2015 14:34:54 -0000 IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-multipart-form-data/ From nobody Sun Feb 8 10:58: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 D0E381A1BC9 for ; Sun, 8 Feb 2015 10:54:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.022 X-Spam-Level: * X-Spam-Status: No, score=1.022 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, MANGLED_TOOL=2.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 p9f_RTBSaU9O for ; Sun, 8 Feb 2015 10:54:18 -0800 (PST) Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::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 A139B1A1BC8 for ; Sun, 8 Feb 2015 10:54:18 -0800 (PST) Received: by mail-qc0-f178.google.com with SMTP id b13so19556637qcw.9 for ; Sun, 08 Feb 2015 10:54:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=HlNSzciiOBTfzJXmIlWbfRBCAqopi8It4ZT6IMKzBwo=; b=AgY0HaHIjC4UYUv7exE5aosUBg8vVvU5NKdlCeS7DwVMb4Qr3lc3FBlGnyThONdkCA 5QrphVYczYPKYF4RGgzvQcD2iC+T9Wc6DxwiId9EIcWI+Jx7VMX+bHEq2NV+aP49/K4R 461r6wYY16JYbUiEKh3aa7aUKaUXeUSklqzLN3qZlEMwT3FtyQwvVn0hWAVO2UsC/GAf sNCnv3tr8axNiqVNqTv95i8p/3bBcxmHJIxa8TSqZYrftoPYyQqfj8fWscWAMn0OkBCM v/Jqg997rXgcS7LMyHZ2Xb7lQmO2giqUWZT2o/2sU7Yn+Jckw833catlSrp9DcsaRJTq yCkw== MIME-Version: 1.0 X-Received: by 10.140.40.70 with SMTP id w64mr31968630qgw.14.1423421657830; Sun, 08 Feb 2015 10:54:17 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.140.39.163 with HTTP; Sun, 8 Feb 2015 10:54:17 -0800 (PST) In-Reply-To: References: <20141224194714.27569.qmail@ary.lan> Date: Sun, 8 Feb 2015 13:54:17 -0500 X-Google-Sender-Auth: aBlizwdSE239sM_bjgNxvhkVy-w Message-ID: From: Barry Leiba To: "Murray S. Kucherawy" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: John Levine , IETF Apps Discuss Subject: Re: [apps-discuss] [Technical Errata Reported] RFC7001 (4201) 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, 08 Feb 2015 18:54:20 -0000 >> So what should we do about this? I'm thinking that the gaps are large >> enough that it'd be worth doing a new revision that includes the missing >> stuff, replacing 7001. ... >> PS: Yes. I'll help. > > Happy to spin up a full update once the holidays are over. I had been > planning to do that already, but the main issue I had was resolved with > RFC7410. So with respect to this errata report: do you want this marked as "Held for Document Update"? Barry From nobody Sun Feb 8 19:01: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 978E11A8704 for ; Sun, 8 Feb 2015 19:01:12 -0800 (PST) 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 Wf06qbWMmnlw for ; Sun, 8 Feb 2015 19:01:11 -0800 (PST) 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 CA4701A86F1 for ; Sun, 8 Feb 2015 19:01:10 -0800 (PST) Received: (qmail 6577 invoked from network); 9 Feb 2015 03:01:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=19b0.54d822f5.k1502; bh=EC4pleczEMTAu5ZLCDjoBdvF1E3JO1IhnkHkUY88kHo=; b=jP/Woyy7DW+euOlrHbmAlFif8c4X/vSG4abKBS1fY5/oe+DUoZUINrgxgRbU6BjYKxNfw2ITEjUHsZhUvnlawNkPVCABGS8JBwR3d4/J8oqb+ou32fqwvDJclhlqRPAofgrU2zoWMSNJoFiNyS4vPolQKAwnqTxK59SvJe5JnXsjzJpo0jezCzf3FEWVvpdeuJr6OGRTC9gFVWsNzXSWefbjjS25a8sbfDJ7xlCctMm2hImTBzqnY5iDeTkv03+v 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=19b0.54d822f5.k1502; bh=EC4pleczEMTAu5ZLCDjoBdvF1E3JO1IhnkHkUY88kHo=; b=VFnistUiSaZeqjm1W3DF4ozVO+7FHQ+wFNnEpTmPTt6IFfqNExmuh0IHsmZUrq/0G7MwWVCBcca+AmsswPckgpWtLD9mcXmnMufgX5s2W719p3dO/MZ0ywhe8ATtT/jS9Fst6QkB0cyLSltDVNRJLVpQ3AwyxISaGuSbEOUCpTdsJ1BEQAiJBxRMeVf7gDp1FaMsh+jj+dny/CIt2KYPHD+CvyavN7hgusD+NCKRnfcOWiMfncB03J36lqI8ifgS 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; 09 Feb 2015 03:01:09 -0000 Date: 9 Feb 2015 11:01:05 +0800 Message-ID: From: "John R Levine" To: "Barry Leiba" In-Reply-To: References: <20141224194714.27569.qmail@ary.lan> 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: IETF Apps Discuss Subject: Re: [apps-discuss] [Technical Errata Reported] RFC7001 (4201) 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, 09 Feb 2015 03:01:12 -0000 >> Happy to spin up a full update once the holidays are over. I had been >> planning to do that already, but the main issue I had was resolved with >> RFC7410. > > So with respect to this errata report: do you want this marked as > "Held for Document Update"? It's up to Murray. I do think we need to revise it to include the missing descriptions of the properties, but since we are truly documenting what the running code does and shouldn't need to invent anything, it shouldn't be very hard. Regards from the ICG session in Singapore, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Sun Feb 8 20: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 7400E1A0012 for ; Sun, 8 Feb 2015 20:25:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_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 sRLxOH6RDQSx for ; Sun, 8 Feb 2015 20:25:26 -0800 (PST) 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 7A6721A0011 for ; Sun, 8 Feb 2015 20:25:26 -0800 (PST) Received: by mail-wg0-f54.google.com with SMTP id l18so8390054wgh.13 for ; Sun, 08 Feb 2015 20:25:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wAW/kXLqaQiRRyVYYkqSEg9alMZyjM87X+SKOoNyG9E=; b=gGRPXZ0uCoVKd3N5IbF8RJ6Tie3PrxQro2FdX5gIWDqq8qlflTfRcTgHbzwy4F3tx/ 9ojedYIuoRebHc17xtjYZIaZ3z9IXDf2NDjiOEMT4PZf3BRVQvOBEkRy1zdn8ekQ7LrE PdrquW6OGm2APQXIbFSKgihnCmtRvrVw1TZH4JF2rPsJz2JS3VDgRO/HKuLwOAYNkC5m nK5oje/6C2YFa8ogJuleUGijaFo/8tYU1adJfHUXTd9Ax2MHYEjtPVyIeAp36EyCLuSA fCcvXcLsiEUWk6mh3EeHEKEmYmborZaFbSAsH8EMyYUrF27nz1YeBGR//MTheA3GuaTD Gy7g== MIME-Version: 1.0 X-Received: by 10.194.185.68 with SMTP id fa4mr36520370wjc.111.1423455925293; Sun, 08 Feb 2015 20:25:25 -0800 (PST) Received: by 10.27.85.157 with HTTP; Sun, 8 Feb 2015 20:25:25 -0800 (PST) In-Reply-To: References: <20141224194714.27569.qmail@ary.lan> Date: Sun, 8 Feb 2015 20:25:25 -0800 Message-ID: From: "Murray S. Kucherawy" To: John R Levine Content-Type: multipart/alternative; boundary=047d7bacb11ec7d9eb050ea028dc Archived-At: Cc: Barry Leiba , IETF Apps Discuss Subject: Re: [apps-discuss] [Technical Errata Reported] RFC7001 (4201) 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, 09 Feb 2015 04:25:28 -0000 --047d7bacb11ec7d9eb050ea028dc Content-Type: text/plain; charset=UTF-8 On Sun, Feb 8, 2015 at 7:01 PM, John R Levine wrote: > Happy to spin up a full update once the holidays are over. I had been >>> planning to do that already, but the main issue I had was resolved with >>> RFC7410. >>> >> >> So with respect to this errata report: do you want this marked as >> "Held for Document Update"? >> > > It's up to Murray. I do think we need to revise it to include the missing > descriptions of the properties, but since we are truly documenting what the > running code does and shouldn't need to invent anything, it shouldn't be > very hard. > Apologies for dropping the ball on this. I agree this is under-specified. Would we prefer to do a document that includes just the clarification that updates RFC7001, or a full re-publication that replaces it? I'm happy to do either. -MSK --047d7bacb11ec7d9eb050ea028dc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sun, Feb 8, 2015 at 7:01 PM, John R Levine <johnl@taugh.= com> wrote:
Happy to spin up a full update once the holidays are over.=C2=A0 I had been=
planning to do that already, but the main issue I had was resolved with
RFC7410.

So with respect to this errata report: do you want this marked as
"Held for Document Update"?

 It's up to Murray.=C2=A0 I do think we need to revise it to include the= missing descriptions of the properties, but since we are truly documenting= what the running code does and shouldn't need to invent anything, it s= houldn't be very hard.

Apologies fo= r dropping the ball on this.

I agree this is under-specif= ied.=C2=A0 Would we prefer to do a document that includes just the clarific= ation that updates RFC7001, or a full re-publication that replaces it?=C2= =A0 I'm happy to do either.

-MSK
--047d7bacb11ec7d9eb050ea028dc-- From nobody Sun Feb 8 20:35: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 39E2A1A001B for ; Sun, 8 Feb 2015 20:31:49 -0800 (PST) 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 YbxBUurjYjiX for ; Sun, 8 Feb 2015 20:31:48 -0800 (PST) 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 BF1351A0011 for ; Sun, 8 Feb 2015 20:31:47 -0800 (PST) Received: (qmail 17523 invoked from network); 9 Feb 2015 04:31:46 -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=4472.54d83832.k1502; bh=+68jmZgyMw8Sbd72FiB4Yzb/9sZUbw8qs5UQbE7Q2D0=; b=BPOfMjKWn3DhPLSEDbD9pOJcbD9vveyn4EgU8EOBpe/0VckUJOUGfsYjqSU1yHT2LnGRkESqDeb9FAiSj2QO9BQJVh+k74oKZdai75TmyqUZ1Cfu/JlH2UW0nn4ud22s1JUKgBbOM2Ho9n27A3EwurM6lZTKGov9Z1IsM5pcVitUy1jZYIt3jM03cjt0g/yrW7SqG4HwWKrymB2b24LwOZJXmMg6sLy3XyHa+C68IDGXKXtV+e2ourrlswSlyy2z 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=4472.54d83832.k1502; bh=+68jmZgyMw8Sbd72FiB4Yzb/9sZUbw8qs5UQbE7Q2D0=; b=CccyRsdRwg0FbxKRIgMBBGz/hahvi3BJwfxDRlvAqwgueDyfxEXi2lyxKHDHYu+vJo2nMa8fNl0S/OVxpdrI7ul8uudUQ/6G/x/grmfET359Z02H7RjjSUP/ONo0ikxnIwPFMZW/0jhDfBw0cOILkTr88LKKZ6ErSc634Fnjxj3A4HmUq/jmuvCAHgCXUJxlfOvE4QJy+wbpwMyjORsBR82jNuaBPJ8ZAiaThERYr1eKmRMEIu/JPIGAUGffAdS+ 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; 09 Feb 2015 04:31:46 -0000 Date: 9 Feb 2015 12:31:42 +0800 Message-ID: From: "John R Levine" To: "Murray S. Kucherawy" In-Reply-To: References: <20141224194714.27569.qmail@ary.lan> 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: IETF Apps Discuss Subject: Re: [apps-discuss] [Technical Errata Reported] RFC7001 (4201) 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, 09 Feb 2015 04:31:49 -0000 > I agree this is under-specified. Would we prefer to do a document that > includes just the clarification that updates RFC7001, or a full > re-publication that replaces it? I'm happy to do either. I'd lean toward a replacement. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Sun Feb 8 21:31: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 5BF851A003A for ; Sun, 8 Feb 2015 21:31:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_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 eqLMNCcrbjbc for ; Sun, 8 Feb 2015 21:31:14 -0800 (PST) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::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 8D8DC1A0035 for ; Sun, 8 Feb 2015 21:31:14 -0800 (PST) Received: by mail-wg0-f47.google.com with SMTP id n12so24501657wgh.6 for ; Sun, 08 Feb 2015 21:31:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MBj+wK2BkqlYANyuAsuRwbfJqfpgRF216GCsr0ugNFo=; b=XqoPqsXtrcMGBPwoTZnSmURzMcbIN/cgxoYI7y8IqDyztqADlY/EMT0mLDVjiAOmkF JpdCjx+R0vVbdxAPkvNlPArfXdIrUtThtck4BaSSubNTtvD+ff+E9UIw4CfrRQ26oiVR /0u9nqZ6W/Fj1Bd19T4I/PSCrzO5AzztdBCDBxf0AuKMrafFvO/aukZNnI45D5aFWmGI SpvFSTs/DpKNqJz0dM5iNkpQt+4KWCoCJunjuzcF91HUP/TP7IK14QXp4Qc/vRHhDHM1 6MrfVSTRNGSl0PgppAo+5Q+Ik0HZIGAmU+I0EKUVqljpGrq7gpKJIBX5kCw69DN3riuj 3PwA== MIME-Version: 1.0 X-Received: by 10.194.185.197 with SMTP id fe5mr3199957wjc.135.1423459873292; Sun, 08 Feb 2015 21:31:13 -0800 (PST) Received: by 10.27.85.157 with HTTP; Sun, 8 Feb 2015 21:31:13 -0800 (PST) In-Reply-To: References: <20141224194714.27569.qmail@ary.lan> Date: Sun, 8 Feb 2015 21:31:13 -0800 Message-ID: From: "Murray S. Kucherawy" To: John R Levine Content-Type: multipart/alternative; boundary=047d7bdc8f9e198496050ea114c4 Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] [Technical Errata Reported] RFC7001 (4201) 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, 09 Feb 2015 05:31:16 -0000 --047d7bdc8f9e198496050ea114c4 Content-Type: text/plain; charset=UTF-8 On Sun, Feb 8, 2015 at 8:31 PM, John R Levine wrote: > I agree this is under-specified. Would we prefer to do a document that >> includes just the clarification that updates RFC7001, or a full >> re-publication that replaces it? I'm happy to do either. >> > > I'd lean toward a replacement. > If nobody else feels strongly about just doing an update document, I'll spin up a replacement in the next day or so. -MSK --047d7bdc8f9e198496050ea114c4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sun, Feb 8, 2015 at 8:31 PM, John R Levine <johnl@taugh.= com> wrote:
I agree this is under-specified.=C2=A0 Would we prefer to do a document tha= t
includes just the clarification that updates RFC7001, or a full
re-publication that replaces it?=C2=A0 I'm happy to do either.

 I'd lean toward a replacement.

If n= obody else feels strongly about just doing an update document, I'll spi= n up a replacement in the next day or so.

-MSK
=
--047d7bdc8f9e198496050ea114c4-- From nobody Sun Feb 8 22:32: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 1C2871A006C for ; Sun, 8 Feb 2015 22:32:44 -0800 (PST) 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 noZXQTYaP3ud for ; Sun, 8 Feb 2015 22:32:42 -0800 (PST) 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 95C841A001C for ; Sun, 8 Feb 2015 22:32:42 -0800 (PST) Received: (qmail 33177 invoked from network); 9 Feb 2015 06:32:40 -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=8198.54d85488.k1502; bh=9s8wpTcCF2DIyleIUvH0U1ZmRe3S/meQce7diSqC+Ew=; b=zJFlcYw5X7tkH9TdtOcqCXb+CrtaDVnYiP02Er7BkgOboKtx4Ymm8l+UUMj/5ysdlCtAuy8WLHKPt6Nfmto26bK8xmHbsOchzL/uyJ4fkiVSIp82zQo8Gbuqw73/9G+dQNCwz3opvLRk7m/oCNk7appnkSnFBcXqqeen76uZdKDk1MsZBe1g7LaoLOFG8q11nxyye5s4/Ty4hluQhS5iiv3+AenMqxnZq41D0/AcPRWZKfXOgJxzmpWDw4NdmIaP 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=8198.54d85488.k1502; bh=9s8wpTcCF2DIyleIUvH0U1ZmRe3S/meQce7diSqC+Ew=; b=rlbvBZpmIY7ygqbR0rgK2uy9auKd9oXxvgt+xNM0wZzl3gliaF5M+PUFt4Cnqx/QDWtu56YYJ5hfHedMujf0IFcf+wwNq80qJaZQ6TLQM1Rw/nhVnvYxcnIRjbOj1VuHui6GNKlhHBkC6KpHr2Qqrjrx0+8n6BMwDuU1XZGvXOhMv0XMcL21rN1Y08nSeJWyr9sLgs56kNxnfE/HlcxMRxSj1VOeYzop2uhuko/59aY0L3x6nRp1x/8tkTBqBu3H 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; 09 Feb 2015 06:32:39 -0000 Date: 9 Feb 2015 14:32:36 +0800 Message-ID: From: "John R Levine" To: "Murray S. Kucherawy" In-Reply-To: References: <20141224194714.27569.qmail@ary.lan> 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: John R Levine , IETF Apps Discuss Subject: Re: [apps-discuss] [Technical Errata Reported] RFC7001 (4201) 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, 09 Feb 2015 06:32:44 -0000 > If nobody else feels strongly about just doing an update document, I'll > spin up a replacement in the next day or so. Just in case it's not clear to anyone, I hope we agree the goal here is to document the existing practice that somehow got left out of earlier versions, not to invent anything new. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Sun Feb 8 23:57: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 2AFB11A0087 for ; Sun, 8 Feb 2015 23:57:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 aA2RojXGFYsr for ; Sun, 8 Feb 2015 23:57:51 -0800 (PST) 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 587EB1A008C for ; Sun, 8 Feb 2015 23:57:51 -0800 (PST) Received: from [192.168.123.7] (unknown [23.241.1.22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 23AC422E1F4; Mon, 9 Feb 2015 02:57:48 -0500 (EST) Message-ID: <54D8687A.8050104@seantek.com> Date: Sun, 08 Feb 2015 23:57:46 -0800 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Graham Klyne , IETF Apps Discuss References: <20141222230149.31980.3522.idtracker@ietfa.amsl.com> <54CE5E92.4090108@seantek.com> <54D23BD3.9020202@ninebynine.org> In-Reply-To: <54D23BD3.9020202@ninebynine.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-text-markdown-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: Mon, 09 Feb 2015 07:57:54 -0000 "ok" Thanks for the feedback. In draft-05, the registry is optional, not required. The text says "To=20 promote interoperability, identifiers MAY be registered in the=20 registry..." so I think that both options are covered. If folks do not=20 want to use the registry, they do not have to. At the same time, we may=20 as well create the registry for folks who want to use it, especially to=20 guarantee stability of what values mean. I guess I am wary of punting on = the registry now since that means there is another uphill battle to get=20 a document through IETF consensus specifically to create the registry.=20 We want this to be easy for folks to use, i.e., have everything tied=20 down and handed to the community in one IETF Action (passing this draft=20 + the use cases draft). There is a track record of documentation of variants...just check out:=20 =20 =20 =20 =20 None of these references are stable enough to promote interoperability=20 with named identifiers, but I think that it shows that the community is=20 trying. Hopefully we are mostly on the same page, at least enough to move=20 forward with this draft. Cheers, Sean On 2/4/2015 7:33 AM, Graham Klyne wrote: > Sean, > > You asked for feedback - I'm not exactly disagreeing, but don't think=20 > the registry is a sword to be fallen upon... > > I agree with the general gist that it's sometimes useful to be able to = > describe or name Markdown variants for specific purposes. Hence I=20 > believe a variant parameter for the MIME content-type is useful to have= =2E > > How to document consensus on what the variant values mean? An IANA=20 > registry is one way of doing this, and seems a reasonable option to=20 > the extent it relates to a parameter defined in an IETF protocol=20 > element. But other options are also possible, and if there's=20 > significant push-back against defining an IANA registry, I'd be=20 > inclined to create a wiki somewhere (GitHub?) and point to that=20 > instead. If it turns out to be useful, a more formal registry could=20 > be defined later. > > It might even be the case that the best design for a registry would be = > clearer if there were some track record of (less formal) documentation = > of variants. > > Just my 2=A2. > > #g > --=20 > > > On 01/02/2015 17:12, Sean Leonard wrote: >> On 1/9/2015 7:02 AM, Michel Fortin wrote: >>> The complexity has been scaled down from the earlier drafts, that's=20 >>> good. >>> >>> Having a registry for variants remains unnecessary in my view, and,=20 >>> while I >>> understand Sean personally has a use case for it, what remains=20 >>> unclear to me >>> is how the registry is going to be populated. It seems to me that=20 >>> the only >>> person that needs it is Sean and thus he'll either be the one=20 >>> populating it or >>> it'll be left mostly empty. Perhaps I'm wrong, but who else has=20 >>> shown interest >>> in the thing? >> >> I wanted to respond to this point (and if any disagree, please voice=20 >> a different >> view). >> >> First of all, compared to prior drafts (particularly draft-03) this=20 >> latest >> draft-05 and use-cases-01 are drastically simplified. I am willing to = >> simplify >> them further...but need concrete direction. Otherwise I think we are=20 >> on the >> final stretch. >> >> Various efforts over the years to resolve the Markdown=20 >> "standardization problem" >> have turned into cat-herding exercises. Even now in the "stmd"=20 >> community (aka >> CommonMark community) , most threads=20 >> have turned >> into "me too" pleas to add "just one more feature". Constantly=20 >> changing specs >> and definitions hinder interoperability, i.e., getting two different >> implementations (possibly across space and time) to produce=20 >> consistent results. >> As folks are desiring to use Markdown for various archival or=20 >> pre-archival >> purposes, this is a problem because just labeling content as=20 >> .markdown or >> text/markdown alone will not result in uniform behavior across space=20 >> and time. >> >> I do not believe that Markdown has a standardization problem, because = >> it was not >> meant to be standardized. It's like MIT's old Building 20: if the=20 >> wall doesn't >> work for you, poke a hole in it for your own purposes and ask=20 >> questions later. >> That was part of John Gruber's design philosophy. However, since=20 >> Markdown is >> ever-changing, there is a labeling problem for people who want or need= >> consistent behavior. >> >> The registry is going to be populated by "people who have a need to >> interoperate". I.e., if you want interop (per above: consistent=20 >> referenceable >> behavior), you'll take the trouble to register an identifier. I have=20 >> tried to >> simplify the registration template as much as possible, without=20 >> sacrificing the >> information required for interoperability. For example, I removed the = >> version >> sub-identifier since that was a source of additional complexity. If=20 >> someone >> wants to register "CommonMark-0.17" distinctly from "CommonMark"=20 >> (version >> unspecified), that is possible. >> >> Both the Markdown community and this (IETF) community have expressed=20 >> a need for >> registered variants. See, e.g., >> point 5. If the= >> registration activity slows down, that's fine. Either people will=20 >> have moved >> from Markdown to the shiny new thing, or they don't need to label=20 >> their content >> in an interoperable way. >> >> Thanks, >> >> Sean >> >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss >> From nobody Mon Feb 9 00:08: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 0A2A31A0097 for ; Mon, 9 Feb 2015 00:08:08 -0800 (PST) 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 Bv7EbuqvFqvJ for ; Mon, 9 Feb 2015 00:08:05 -0800 (PST) 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 6636A1A00A2 for ; Mon, 9 Feb 2015 00:08:05 -0800 (PST) Received: from [192.168.123.7] (unknown [23.241.1.22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 4AB1122E260 for ; Mon, 9 Feb 2015 03:08:04 -0500 (EST) Message-ID: <54D86AE1.2080906@seantek.com> Date: Mon, 09 Feb 2015 00:08:01 -0800 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20141222230149.31980.3522.idtracker@ietfa.amsl.com> In-Reply-To: <20141222230149.31980.3522.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [apps-discuss] (ABNF notes) Re: I-D Action: draft-ietf-appsawg-text-markdown-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: Mon, 09 Feb 2015 08:08:08 -0000 Just some public notes on some ABNF nits/issues in draft-markdown-05: Currently Section 6.1 says: ALPHA [*(%d33-126) (ALPHA / DIGIT)] This should be changed to: ALPHA [*VCHAR (ALPHA / DIGIT)] which means the same thing. The rules import rule names from the RFC 5234 Core Rules. Currently there is no RFC 5234 reference. I am not inclined to add one because it is "obvious", but in my last draft the IESG requested a RFC 5234 reference, so I figured I would poll the list to see if there is consensus that it needs to be added, before it goes to LC. Recently on rfc-interest there has been some discussion about making ABNF more formalized and complicated. I think the ABNF in this draft is a prime example of ABNF that does *not* need to be formalized in an "ABNF module" with imports and exports. It is also an example of ABNF that exists in the prose text, rather than ABNF that is sequestered into discrete Figure blocks. The ABNF is really just for expository purposes; furthermore, they are not even comprised of complete ABNF statements (there are no rulenames provided). Sean On 12/22/2014 3:01 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Applications Area Working Group Working Group of the IETF. > > Title : The text/markdown Media Type > Author : Sean Leonard > Filename : draft-ietf-appsawg-text-markdown-05.txt > Pages : 14 > Date : 2014-12-22 > > 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. From nobody Mon Feb 9 01:01: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 9C3B91A00FF for ; Mon, 9 Feb 2015 00:59:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.17 X-Spam-Level: X-Spam-Status: No, score=0.17 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_RP_RNBL=1.31, RCVD_IN_SORBS_WEB=0.77, 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 ULiEJOXsWBvn for ; Mon, 9 Feb 2015 00:59:24 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 131DA1A00E9 for ; Mon, 9 Feb 2015 00:59:21 -0800 (PST) Received: from netb ([89.204.137.153]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LnkiR-1Xgzj11zB9-00hsVM; Mon, 09 Feb 2015 09:59:17 +0100 From: Bjoern Hoehrmann To: Sean Leonard Date: Mon, 09 Feb 2015 09:59:16 +0100 Message-ID: References: <20141222230149.31980.3522.idtracker@ietfa.amsl.com> <54D86AE1.2080906@seantek.com> In-Reply-To: <54D86AE1.2080906@seantek.com> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:reNxe00sr5vpNNzOlq9bkV45TnjlAQyORkNCYI4ZVMY8J2pj1Tl 40pLyOHiWPNFR8o+O6HvVaZooEHHExmRVeJm5x/atl16s+iYIyxJJcTUL2byYc5/0ltvimw OOfGgdYS8PzbN4KFadguFDW5jwL9QQlYsZk3teizy06My3p/8/NaBiGdJEatw+vR+2luV8o /amNKqAj8wLJAQkNq8zvg== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] (ABNF notes) Re: I-D Action: draft-ietf-appsawg-text-markdown-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: Mon, 09 Feb 2015 08:59:25 -0000 * Sean Leonard wrote: >Just some public notes on some ABNF nits/issues in draft-markdown-05: > >Currently Section 6.1 says: > > ALPHA [*(%d33-126) (ALPHA / DIGIT)] > > >This should be changed to: > > ALPHA [*VCHAR (ALPHA / DIGIT)] > > >which means the same thing. > >The rules import rule names from the RFC 5234 Core Rules. Currently >there is no RFC 5234 reference. I am not inclined to add one because it >is "obvious", but in my last draft the IESG requested a RFC 5234 >reference, so I figured I would poll the list to see if there is >consensus that it needs to be added, before it goes to LC. That something like `ALPHA / DIGIT` is an unordered choice between the two non-terminals is not obvious, it could just as well be an ordered choice or something else entirely. If you have an ABNF grammar, you do need to reference a specification for the semantics of the syntax. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de Available for hire in Berlin (early 2015) · http://www.websitedev.de/ From nobody Mon Feb 9 01:06: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 9798C1A00E8 for ; Mon, 9 Feb 2015 01:05:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.601 X-Spam-Level: X-Spam-Status: No, score=-4.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, 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 fSAQJsRFRDcx for ; Mon, 9 Feb 2015 01:05:04 -0800 (PST) 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 26E971A00E5 for ; Mon, 9 Feb 2015 01:05:04 -0800 (PST) Received: from [192.168.123.7] (unknown [23.241.1.22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id EFDB022E266; Mon, 9 Feb 2015 04:05:02 -0500 (EST) Message-ID: <54D8783C.3080906@seantek.com> Date: Mon, 09 Feb 2015 01:05:00 -0800 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Bjoern Hoehrmann References: <20141222230149.31980.3522.idtracker@ietfa.amsl.com> <54D86AE1.2080906@seantek.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] (ABNF notes) Re: I-D Action: draft-ietf-appsawg-text-markdown-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: Mon, 09 Feb 2015 09:05:05 -0000 On 2/9/2015 12:59 AM, Bjoern Hoehrmann wrote: > * Sean Leonard wrote: >> Just some public notes on some ABNF nits/issues in draft-markdown-05: >> >> Currently Section 6.1 says: >> >> ALPHA [*(%d33-126) (ALPHA / DIGIT)] >> >> >> This should be changed to: >> >> ALPHA [*VCHAR (ALPHA / DIGIT)] >> >> >> which means the same thing. >> >> The rules import rule names from the RFC 5234 Core Rules. Currently >> there is no RFC 5234 reference. I am not inclined to add one because it >> is "obvious", but in my last draft the IESG requested a RFC 5234 >> reference, so I figured I would poll the list to see if there is >> consensus that it needs to be added, before it goes to LC. > That something like `ALPHA / DIGIT` is an unordered choice between the > two non-terminals is not obvious, it could just as well be an ordered > choice or something else entirely. Sorry but I am not sure that I follow. Can you clarify what you mean? The specification says: I.e., the identifier MUST start with a letter and MAY contain punctuation in the middle, but not at the end: the last character MUST be alphanumeric. So, the alphanumeric {ALPHA / DIGIT} is at the end; it is not "between" anything (whether terminal or non-terminal). Thanks, Sean From nobody Mon Feb 9 01:18: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 EDF741A0137 for ; Mon, 9 Feb 2015 01:18:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.83 X-Spam-Level: X-Spam-Status: No, score=-1.83 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_RP_RNBL=1.31, RCVD_IN_SORBS_WEB=0.77, 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 fMAnpRF56uer for ; Mon, 9 Feb 2015 01:18:05 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 811011A00E6 for ; Mon, 9 Feb 2015 01:18:05 -0800 (PST) Received: from netb ([89.204.137.153]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LiHc7-1XqrJs0JYh-00nQU9; Mon, 09 Feb 2015 10:18:02 +0100 From: Bjoern Hoehrmann To: Sean Leonard Date: Mon, 09 Feb 2015 10:17:57 +0100 Message-ID: <4fugda1iefmair2tj8u3qm36rlnji3rksb@hive.bjoern.hoehrmann.de> References: <20141222230149.31980.3522.idtracker@ietfa.amsl.com> <54D86AE1.2080906@seantek.com> <54D8783C.3080906@seantek.com> In-Reply-To: <54D8783C.3080906@seantek.com> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:SlejnfjcUVmp8IWPiOkYaKIrUthcszczdUZtWsfZRCrOnb0yIaP RW/HnU+NxrlUZKkcCIsZ2Ue+iWWj2lHjhPAqv3eOjaWUuaO59ORHF7KPw4U7u6w3R5QdLjr VwLrevh5kZmRq5GbXhrI4sZilGJJkYYOz6yOwN+FlZeAwKzttcTkbqawCqO8d85bgpTfqmC DS0nSdiooVAT7TGA9NmAw== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] (ABNF notes) Re: I-D Action: draft-ietf-appsawg-text-markdown-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: Mon, 09 Feb 2015 09:18:08 -0000 * Sean Leonard wrote: >On 2/9/2015 12:59 AM, Bjoern Hoehrmann wrote: >> That something like `ALPHA / DIGIT` is an unordered choice between the >> two non-terminals is not obvious, it could just as well be an ordered >> choice or something else entirely. > >Sorry but I am not sure that I follow. Can you clarify what you mean? > >The specification says: >I.e., the identifier MUST start with a letter and MAY contain >punctuation in the middle, but not at the end: the last character MUST >be alphanumeric. > >So, the alphanumeric {ALPHA / DIGIT} is at the end; it is not "between" >anything (whether terminal or non-terminal). I am just saying that it does not make sense to use ABNF syntax without referencing a specification for ABNF (starting with the fact that there are other "ABNF"s than "IETF ABNF"). As for the specific example, there are ABNF-like formats that, for instance, use `|` as distinct from `/` where `|` is an unordered choice and `/` is an ordered choice (consider how you interpret them if both sides of the operator match; with un- ordered choices you have an ambiguity in the grammar, while an ordered choice does not allow ambiguity). -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de Available for hire in Berlin (early 2015) · http://www.websitedev.de/ From nobody Mon Feb 9 03:11: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 6BF371A0222 for ; Mon, 9 Feb 2015 03:11:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 Lju6JhWfU7be for ; Mon, 9 Feb 2015 03:11:49 -0800 (PST) Received: from waldorf.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id 6CABF1A0123 for ; Mon, 9 Feb 2015 03:11:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1423480308; d=isode.com; s=selector; i=@isode.com; bh=Ibd1cmX6bTmOa7ldhi44t6JnTfRCfEavG8yrFE8UzuU=; 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=bUH4auHRAyLM34rlcghl4uCbvQ318QahxWfp4JzCULklxgfUlhWo3YmhuD6egfNuEsjZwi OmyHHA/joXQM+g0+Z5ni4PjTLA09MjcrbjR53V1jH5eBUUFL0WO6ioL4R2LjbmtaBa2mc2 1mQPSjxj/xkUNCbyWIJG86upDi74a/o=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 9 Feb 2015 11:11:48 +0000 Message-ID: <54D895C0.5020500@isode.com> Date: Mon, 09 Feb 2015 11:10:56 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 To: Sean Leonard , apps-discuss@ietf.org References: <20141222230149.31980.3522.idtracker@ietfa.amsl.com> <54D86AE1.2080906@seantek.com> In-Reply-To: <54D86AE1.2080906@seantek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [apps-discuss] (ABNF notes) Re: I-D Action: draft-ietf-appsawg-text-markdown-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: Mon, 09 Feb 2015 11:11:51 -0000 Hi Sean, On 09/02/2015 08:08, Sean Leonard wrote: > Just some public notes on some ABNF nits/issues in draft-markdown-05: > > Currently Section 6.1 says: > > ALPHA [*(%d33-126) (ALPHA / DIGIT)] > > > This should be changed to: > > ALPHA [*VCHAR (ALPHA / DIGIT)] > > > which means the same thing. > > The rules import rule names from the RFC 5234 Core Rules. Currently > there is no RFC 5234 reference. I am not inclined to add one because > it is "obvious", There is no such thing as "obvious RFC reference". There are no implicit RFC references. > but in my last draft the IESG requested a RFC 5234 reference, so I > figured I would poll the list to see if there is consensus that it > needs to be added, before it goes to LC. Please just add it :-). > > > Recently on rfc-interest there has been some discussion about making > ABNF more formalized and complicated. I think the ABNF in this draft > is a prime example of ABNF that does *not* need to be formalized in an > "ABNF module" with imports and exports. It is also an example of ABNF > that exists in the prose text, rather than ABNF that is sequestered > into discrete Figure blocks. The ABNF is really just for expository > purposes; furthermore, they are not even comprised of complete ABNF > statements (there are no rulenames provided). > > > Sean > > On 12/22/2014 3:01 PM, internet-drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Applications Area Working Group >> Working Group of the IETF. >> >> Title : The text/markdown Media Type >> Author : Sean Leonard >> Filename : draft-ietf-appsawg-text-markdown-05.txt >> Pages : 14 >> Date : 2014-12-22 >> >> 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. > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From nobody Mon Feb 9 05:30: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 BCC411A0370 for ; Mon, 9 Feb 2015 05:28:05 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 K4-kmjIrnk29 for ; Mon, 9 Feb 2015 05:28:03 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) (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 5F94F1A039D for ; Mon, 9 Feb 2015 05:28:02 -0800 (PST) Received: by labgd6 with SMTP id gd6so4332943lab.7 for ; Mon, 09 Feb 2015 05:28:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=zDkK2l0khOc9QG6TS7jkcm2nM/kR7v+V/E2xwzz8V+U=; b=JQ0+SR8/tDuZhk1AgMTclby97jSfImi9T3kcAG3gRv9lvQnOMJJ78VxxrGG8XJRAkl YiDfQdiOx6WUBq21ndw48bagj7zxxi2pSU+634mrAX+DG3eEKAm6NmCi2DL9cNngCWGr +e6PLCN+l8HcWj86p5U0P0PSuAlm8Az9GX3C2m573sf6ad9iO0rp+OmbljaV7FsDDOv+ Q8Cb+X38D2+PdDcxVA0uHlchcGDoqaXIC+X4VJfasszWcfYN+WBaXV0Ge89DXm17hIB8 ahUWLzlU5lcdWtT2U9THgDtg3tlqZALMwZMq4qZ+MQ+/WidLLGJbnH1GWihfpHoS833k 4diQ== MIME-Version: 1.0 X-Received: by 10.152.29.6 with SMTP id f6mr16774957lah.82.1423488480898; Mon, 09 Feb 2015 05:28:00 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.152.21.73 with HTTP; Mon, 9 Feb 2015 05:28:00 -0800 (PST) In-Reply-To: References: <20141224194714.27569.qmail@ary.lan> Date: Mon, 9 Feb 2015 08:28:00 -0500 X-Google-Sender-Auth: s1jE6zj5a8f3W2L269eISox_0EI Message-ID: From: Barry Leiba To: "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=089e0158c78a3ef603050ea7bdfe Archived-At: Cc: John R Levine , IETF Apps Discuss Subject: Re: [apps-discuss] [Technical Errata Reported] RFC7001 (4201) 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, 09 Feb 2015 13:28:05 -0000 --089e0158c78a3ef603050ea7bdfe Content-Type: text/plain; charset=ISO-8859-1 I'm happy to write some sort of "It's not as straightforward as that," note, and mark it HFDU. Barry On Sunday, February 8, 2015, Murray S. Kucherawy wrote: > On Sun, Feb 8, 2015 at 7:01 PM, John R Levine > wrote: > >> Happy to spin up a full update once the holidays are over. I had been >>>> planning to do that already, but the main issue I had was resolved with >>>> RFC7410. >>>> >>> >>> So with respect to this errata report: do you want this marked as >>> "Held for Document Update"? >>> >> >> It's up to Murray. I do think we need to revise it to include the >> missing descriptions of the properties, but since we are truly documenting >> what the running code does and shouldn't need to invent anything, it >> shouldn't be very hard. >> > > Apologies for dropping the ball on this. > > I agree this is under-specified. Would we prefer to do a document that > includes just the clarification that updates RFC7001, or a full > re-publication that replaces it? I'm happy to do either. > > -MSK > --089e0158c78a3ef603050ea7bdfe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'm happy to write some sort of "It's not as straightforward a= s that," note, and mark it HFDU.

Barry

On Su= nday, February 8, 2015, Murray S. Kucherawy <superuser@gmail.com> wrote:
On Sun, Feb 8, 2015 at 7:01 PM, John R Levine <johnl@taugh.com> wrote:
Happy to spin up a full update once the holidays are over.=A0 I had been planning to do that already, but the main issue I had was resolved with
RFC7410.

So with respect to this errata report: do you want this marked as
"Held for Document Update"?

 It's up to Murray.=A0 I do think we need to revise it to include the mi= ssing descriptions of the properties, but since we are truly documenting wh= at the running code does and shouldn't need to invent anything, it shou= ldn't be very hard.

Apologies for d= ropping the ball on this.

I agree this is under-specified= .=A0 Would we prefer to do a document that includes just the clarification = that updates RFC7001, or a full re-publication that replaces it?=A0 I'm= happy to do either.

-MSK
--089e0158c78a3ef603050ea7bdfe-- From nobody Mon Feb 9 06:36: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 EF02E1A0430 for ; Mon, 9 Feb 2015 06:36:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_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 TO3nTUVyp7RG for ; Mon, 9 Feb 2015 06:36:47 -0800 (PST) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::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 2BCD81A040B for ; Mon, 9 Feb 2015 06:36:47 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id z2so6626131wiv.1 for ; Mon, 09 Feb 2015 06:36:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yL0hL5vzVom3P236P8RHRXWw29I7xRaII16XWHtBTwY=; b=MOnfB7pO6eZGPnxrQQne9HQcZ5t6VCAgURZEvQNHCuvsg6TS7qidqh6xIaZY3OvtZ7 xFau2RnooaWol32Oh3OiTpCE7QEtbv2ck4EM0Dc7rn+UIZUNkK7gyyynBQrvxkLtGXa8 OHL7abEYkvQh1Bi79cmk24y1DExFWOJBAsiruOz8s9mzqYWPDRWqzt0BkVNZfCdtDuHn y/Mv3BqC2sRJ5uyLOaSK1tOhxJF1n507eAD1vgu25VfIuYbDCTehWyMwNbDiudDhw3A5 XUZxzO8Y0BE5VFHrNpQYdhGaIiOnTK6KbTb61p0UUM1Fpe8cmcE08qPmCE1buHf5R/xL yBcQ== MIME-Version: 1.0 X-Received: by 10.194.185.68 with SMTP id fa4mr41675921wjc.111.1423492605902; Mon, 09 Feb 2015 06:36:45 -0800 (PST) Received: by 10.27.85.157 with HTTP; Mon, 9 Feb 2015 06:36:45 -0800 (PST) In-Reply-To: <54D895C0.5020500@isode.com> References: <20141222230149.31980.3522.idtracker@ietfa.amsl.com> <54D86AE1.2080906@seantek.com> <54D895C0.5020500@isode.com> Date: Mon, 9 Feb 2015 06:36:45 -0800 Message-ID: From: "Murray S. Kucherawy" To: Alexey Melnikov Content-Type: multipart/alternative; boundary=047d7bacb11e1d84cd050ea8b322 Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] (ABNF notes) Re: I-D Action: draft-ietf-appsawg-text-markdown-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: Mon, 09 Feb 2015 14:36:49 -0000 --047d7bacb11e1d84cd050ea8b322 Content-Type: text/plain; charset=UTF-8 On Mon, Feb 9, 2015 at 3:10 AM, Alexey Melnikov wrote: The rules import rule names from the RFC 5234 Core Rules. Currently there > is no RFC 5234 reference. I am not inclined to add one because it is > "obvious", > There is no such thing as "obvious RFC reference". There are no implicit > RFC references. > >> but in my last draft the IESG requested a RFC 5234 reference, so I >> figured I would poll the list to see if there is consensus that it needs to >> be added, before it goes to LC. >> > Please just add it :-). +1. What's the harm? -MSK --047d7bacb11e1d84cd050ea8b322 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Feb 9, 2015 at 3:10 AM, Alexey Melnikov <alexey.melnikov@isode.com> wrote:

The rule= s import rule names from the RFC 5234 Core Rules. Currently there is no RFC= 5234 reference. I am not inclined to add one because it is "obvious&q= uot;,
There is no such thing as "obvious RFC reference". There are no i= mplicit RFC references.
but in my last draft the IESG requested a RFC 5234 reference, so I figured = I would poll the list to see if there is consensus that it needs to be adde= d, before it goes to LC.
 Please just add it :-).

+1. What's the = harm?

-MSK
--047d7bacb11e1d84cd050ea8b322-- From nobody Mon Feb 9 13:21: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 9F5BD1A88C7 for ; Mon, 9 Feb 2015 12:29:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_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 rWU6efLJ8ukR for ; Mon, 9 Feb 2015 12:29:09 -0800 (PST) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::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 1BD061A88C3 for ; Mon, 9 Feb 2015 12:29:09 -0800 (PST) Received: by mail-wg0-f41.google.com with SMTP id b13so9304380wgh.0 for ; Mon, 09 Feb 2015 12:29:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=k8kHERmzVAkq8njENn5Szljd7OFReGfvA+0+A4HGtvY=; b=eBLTfec6wpmEiru1RFcJNMWJd965FeCOLWbApevBrqxXS5LENdGXKUq0zGOxbDLe96 kLW/euNjaQiAfreEHKcoOgTTKmqPDC7jxvcVCEMWwnWZJAKUdS32mVO60udLF3t5apc6 Se8wzr9qAME0IT/sFkOqiwT2LuywDdFlX/8jOn8k9gqpiEfWBJFnVxaW7PLLBca8Yubw YGuPouCAuJaT1dymvlXM/S0yAKXqSMArSBIf6JNUdDC20lg0c0PK174XynfG2V5AJB9L uJw6C8R72j/eKHtLQ7qM3EXLRzsJKEUwSWQigI61LrPG12he7aQo18XjbrwF95T1kHyk 0Wtg== MIME-Version: 1.0 X-Received: by 10.180.198.74 with SMTP id ja10mr38677964wic.52.1423513747812; Mon, 09 Feb 2015 12:29:07 -0800 (PST) Received: by 10.27.85.157 with HTTP; Mon, 9 Feb 2015 12:29:07 -0800 (PST) In-Reply-To: <20150209202528.6853.69034.idtracker@ietfa.amsl.com> References: <20150209202528.6853.69034.idtracker@ietfa.amsl.com> Date: Mon, 9 Feb 2015 12:29:07 -0800 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=047d7b62498c457849050ead9f14 Archived-At: Subject: [apps-discuss] Fwd: New Version Notification for draft-kucherawy-rfc7001bis-00.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: Mon, 09 Feb 2015 20:29:11 -0000 --047d7b62498c457849050ead9f14 Content-Type: text/plain; charset=UTF-8 As discussued, to resolve erratum #4201. This is the XML for RFC7001 produced by the RFC Editor post-AUTH48, with only minor changes like clearing out the old "Changes since..." section. This should enable easy tracking of changes since RFC7001. I've put a "To Do" section listing the few things I think should be handled in this update, but haven't done any of the work listed there yet. With my chair hat off, as I am the author: I propose processing this via APPSAWG since the documents it replaces also followed that path. Alexey, you'll have to push the buttons on this one. :-) -MSK ---------- Forwarded message ---------- From: Date: Mon, Feb 9, 2015 at 12:25 PM Subject: New Version Notification for draft-kucherawy-rfc7001bis-00.txt To: "Murray S. Kucherawy" A new version of I-D, draft-kucherawy-rfc7001bis-00.txt has been successfully submitted by Murray S. Kucherawy and posted to the IETF repository. Name: draft-kucherawy-rfc7001bis Revision: 00 Title: Message Header Field for Indicating Message Authentication Status Document date: 2015-02-09 Group: Individual Submission Pages: 43 URL: http://www.ietf.org/internet-drafts/draft-kucherawy-rfc7001bis-00.txt Status: https://datatracker.ietf.org/doc/draft-kucherawy-rfc7001bis/ Htmlized: http://tools.ietf.org/html/draft-kucherawy-rfc7001bis-00 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. 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. The IETF Secretariat --047d7b62498c457849050ead9f14 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As discussued, to resolve erratum #4201.=C2=A0 T= his is the XML for RFC7001 produced by the RFC Editor post-AUTH48, with onl= y minor changes like clearing out the old "Changes since..." sect= ion.=C2=A0 This should enable easy tracking of changes since RFC7001.=C2=A0= I've put a "To Do" section listing the few things I think sh= ould be handled in this update, but haven't done any of the work listed= there yet.

With my chair hat off, as I am the author: I propo= se processing this via APPSAWG since the documents it replaces also followe= d that path.=C2=A0 Alexey, you'll have to push the buttons on this one.= =C2=A0 :-)

-MSK

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Mon, Feb 9, 2015 a= t 12:25 PM
Subject: New Version Notification for draft-kucherawy-rfc7001= bis-00.txt
To: "Murray S. Kucherawy" <superuser@gmail.com>



A new version of I-D, draft-kucherawy-rfc7001bis-00.txt
has been successfully submitted by Murray S. Kucherawy and posted to the IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-kucherawy-rfc7001bis Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Message Header Field for Indicatin= g Message Authentication Status
Document date:=C2=A0 2015-02-09
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 43
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http= ://www.ietf.org/internet-drafts/draft-kucherawy-rfc7001bis-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracke= r.ietf.org/doc/draft-kucherawy-rfc7001bis/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0http://tools.ietf.org/html/= draft-kucherawy-rfc7001bis-00


Abstract:
=C2=A0 =C2=A0This document specifies a message header field called Authenti= cation-
=C2=A0 =C2=A0Results for use with electronic mail messages to indicate the = results
=C2=A0 =C2=A0of message authentication efforts.=C2=A0 Any receiver-side sof= tware, such
=C2=A0 =C2=A0as mail filters or Mail User Agents (MUAs), can use this heade= r field
=C2=A0 =C2=A0to relay that information in a convenient and meaningful way t= o users
=C2=A0 =C2=A0or to make sorting and filtering decisions.




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.

The IETF Secretariat


--047d7b62498c457849050ead9f14-- From nobody Mon Feb 9 15:49: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 C3D171A1A03 for ; Mon, 9 Feb 2015 07:32:47 -0800 (PST) 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 B3F1GvoRwABk for ; Mon, 9 Feb 2015 07:32:40 -0800 (PST) Received: from relay16.mail.ox.ac.uk (relay16.mail.ox.ac.uk [163.1.2.166]) by ietfa.amsl.com (Postfix) with ESMTP id 685891A0AF7 for ; Mon, 9 Feb 2015 07:32:40 -0800 (PST) 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 1YKqKD-0005Et-rj; Mon, 09 Feb 2015 15:32:37 +0000 Received: from gklyne.plus.com ([80.229.154.156] helo=conina.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 1YKqKD-000C8R-Kj; Mon, 09 Feb 2015 15:32:37 +0000 Message-ID: <54D8D317.9070609@ninebynine.org> Date: Mon, 09 Feb 2015 15:32:39 +0000 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: Sean Leonard , IETF Apps Discuss References: <20141222230149.31980.3522.idtracker@ietfa.amsl.com> <54CE5E92.4090108@seantek.com> <54D23BD3.9020202@ninebynine.org> <54D8687A.8050104@seantek.com> In-Reply-To: <54D8687A.8050104@seantek.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Oxford-Username: zool0635 Archived-At: Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-text-markdown-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: Mon, 09 Feb 2015 15:32:48 -0000 On 09/02/2015 07:57, Sean Leonard wrote: > "ok" > > Thanks for the feedback. > > In draft-05, the registry is optional, not required. The text says "To promote > interoperability, identifiers MAY be registered in the registry..." so I think > that both options are covered. If folks do not want to use the registry, they do > not have to. At the same time, we may as well create the registry for folks who > want to use it, especially to guarantee stability of what values mean. I guess I > am wary of punting on the registry now since that means there is another uphill > battle to get a document through IETF consensus specifically to create the > registry. We want this to be easy for folks to use, i.e., have everything tied > down and handed to the community in one IETF Action (passing this draft + the > use cases draft). > > There is a track record of documentation of variants...just check out: > > > > > > > None of these references are stable enough to promote interoperability with > named identifiers, but I think that it shows that the community is trying. > > Hopefully we are mostly on the same page, at least enough to move forward with > this draft. Yes, mostly. Let's move forwards! I was mainly offering an alternative in case the registry proves to be a sticking point in IETF review. One point I'd make about "documentation of variants" is that my suggestion would be that the specification would indicate a preferred venue for this, to avoid the proliferation problems. Beyond that, assuming one chooses a stable venue, stability is really a function of how much the interested parties care about stability. #g -- > > Cheers, > > Sean > > On 2/4/2015 7:33 AM, Graham Klyne wrote: >> Sean, >> >> You asked for feedback - I'm not exactly disagreeing, but don't think the >> registry is a sword to be fallen upon... >> >> I agree with the general gist that it's sometimes useful to be able to >> describe or name Markdown variants for specific purposes. Hence I believe a >> variant parameter for the MIME content-type is useful to have. >> >> How to document consensus on what the variant values mean? An IANA registry >> is one way of doing this, and seems a reasonable option to the extent it >> relates to a parameter defined in an IETF protocol element. But other options >> are also possible, and if there's significant push-back against defining an >> IANA registry, I'd be inclined to create a wiki somewhere (GitHub?) and point >> to that instead. If it turns out to be useful, a more formal registry could >> be defined later. >> >> It might even be the case that the best design for a registry would be clearer >> if there were some track record of (less formal) documentation of variants. >> >> Just my 2¢. >> >> #g >> -- >> >> >> On 01/02/2015 17:12, Sean Leonard wrote: >>> On 1/9/2015 7:02 AM, Michel Fortin wrote: >>>> The complexity has been scaled down from the earlier drafts, that's good. >>>> >>>> Having a registry for variants remains unnecessary in my view, and, while I >>>> understand Sean personally has a use case for it, what remains unclear to me >>>> is how the registry is going to be populated. It seems to me that the only >>>> person that needs it is Sean and thus he'll either be the one populating it or >>>> it'll be left mostly empty. Perhaps I'm wrong, but who else has shown interest >>>> in the thing? >>> >>> I wanted to respond to this point (and if any disagree, please voice a different >>> view). >>> >>> First of all, compared to prior drafts (particularly draft-03) this latest >>> draft-05 and use-cases-01 are drastically simplified. I am willing to simplify >>> them further...but need concrete direction. Otherwise I think we are on the >>> final stretch. >>> >>> Various efforts over the years to resolve the Markdown "standardization problem" >>> have turned into cat-herding exercises. Even now in the "stmd" community (aka >>> CommonMark community) , most threads have turned >>> into "me too" pleas to add "just one more feature". Constantly changing specs >>> and definitions hinder interoperability, i.e., getting two different >>> implementations (possibly across space and time) to produce consistent results. >>> As folks are desiring to use Markdown for various archival or pre-archival >>> purposes, this is a problem because just labeling content as .markdown or >>> text/markdown alone will not result in uniform behavior across space and time. >>> >>> I do not believe that Markdown has a standardization problem, because it was not >>> meant to be standardized. It's like MIT's old Building 20: if the wall doesn't >>> work for you, poke a hole in it for your own purposes and ask questions later. >>> That was part of John Gruber's design philosophy. However, since Markdown is >>> ever-changing, there is a labeling problem for people who want or need >>> consistent behavior. >>> >>> The registry is going to be populated by "people who have a need to >>> interoperate". I.e., if you want interop (per above: consistent referenceable >>> behavior), you'll take the trouble to register an identifier. I have tried to >>> simplify the registration template as much as possible, without sacrificing the >>> information required for interoperability. For example, I removed the version >>> sub-identifier since that was a source of additional complexity. If someone >>> wants to register "CommonMark-0.17" distinctly from "CommonMark" (version >>> unspecified), that is possible. >>> >>> Both the Markdown community and this (IETF) community have expressed a need for >>> registered variants. See, e.g., >>> point 5. If the >>> registration activity slows down, that's fine. Either people will have moved >>> from Markdown to the shiny new thing, or they don't need to label their content >>> in an interoperable way. >>> >>> Thanks, >>> >>> Sean >>> >>> _______________________________________________ >>> apps-discuss mailing list >>> apps-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/apps-discuss >>> > > > From nobody Mon Feb 9 15:49: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 14C631A1A59 for ; Mon, 9 Feb 2015 07:37:04 -0800 (PST) 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 3RKCWRcALCKy for ; Mon, 9 Feb 2015 07:37:01 -0800 (PST) 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 CE3641A1A27 for ; Mon, 9 Feb 2015 07:37:01 -0800 (PST) Received: from [192.168.123.7] (unknown [23.241.1.22]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id C228E22E266; Mon, 9 Feb 2015 10:36:42 -0500 (EST) Message-ID: <54D8D408.20209@seantek.com> Date: Mon, 09 Feb 2015 07:36:40 -0800 From: Sean Leonard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" , Alexey Melnikov References: <20141222230149.31980.3522.idtracker@ietfa.amsl.com> <54D86AE1.2080906@seantek.com> <54D895C0.5020500@isode.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] (ABNF notes) Re: I-D Action: draft-ietf-appsawg-text-markdown-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: Mon, 09 Feb 2015 15:37:04 -0000 On 2/9/2015 6:36 AM, Murray S. Kucherawy wrote: > On Mon, Feb 9, 2015 at 3:10 AM, Alexey Melnikov > > wrote: > > The rules import rule names from the RFC 5234 Core Rules. > Currently there is no RFC 5234 reference. I am not inclined to add > one because it is "obvious", > There is no such thing as "obvious RFC reference". There are no > implicit RFC references. > > but in my last draft the IESG requested a RFC 5234 reference, > so I figured I would poll the list to see if there is > consensus that it needs to be added, before it goes to LC. > > Please just add it :-). > > > +1. What's the harm? Ok; I'll add the RFC 5234 reference. Sean From nobody Tue Feb 10 10:47: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 C627D1A1B6C for ; Tue, 10 Feb 2015 10:47:20 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MANGLED_TOOL=2.3, 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 CirCZX72EUYM for ; Tue, 10 Feb 2015 10:47:19 -0800 (PST) Received: from statler.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id CA2681A1B74 for ; Tue, 10 Feb 2015 10:47:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1423594038; d=isode.com; s=selector; i=@isode.com; bh=TYOUX0+bsJ/44F2AyZkIqkdTwfWIzWHL3n4ObMeCru0=; 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=Jf5rrZAQdTm39XqfY9Kl9TGsWadz/jSHXPHzjrMptqrcRHnZSL1kfUA9DjmTmA8dY7DhYh pT9Bz3qc3VO1yDaevHpxDOWjCjqvmsfvRp4jamQOwyZhp9b7DVxRrcq2tvAmnGU6WkXiNb nHDfDPrs8KaoGxgMAPYc6oPPfRa6uLo=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 10 Feb 2015 18:47:17 +0000 Message-ID: <54DA5231.7050705@isode.com> Date: Tue, 10 Feb 2015 18:47:13 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 To: "Murray S. Kucherawy" , IETF Apps Discuss References: <20150209202528.6853.69034.idtracker@ietfa.amsl.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------010201030702030309090804" Archived-At: Subject: [apps-discuss] draft-kucherawy-rfc7001bis-00.txt as APPSAWG document (was Re: Fwd: New Version Notification for draft-kucherawy-rfc7001bis-00.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, 10 Feb 2015 18:47:20 -0000 --------------010201030702030309090804 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 09/02/2015 20:29, Murray S. Kucherawy wrote: > As discussued, to resolve erratum #4201. This is the XML for RFC7001 > produced by the RFC Editor post-AUTH48, with only minor changes like > clearing out the old "Changes since..." section. This should enable > easy tracking of changes since RFC7001. I've put a "To Do" section > listing the few things I think should be handled in this update, but > haven't done any of the work listed there yet. > > With my chair hat off, as I am the author: I propose processing this > via APPSAWG since the documents it replaces also followed that path. > Alexey, you'll have to push the buttons on this one. :-) Considering that RFC 7001 was produced by APPSAWG and there is enough interest to revise it, this co-chair states that there is support for doing rfc7001bis in APPSAWG. Please state any objections with 1 week. Thank you, Alexey, as co-chair. > > -MSK > > ---------- Forwarded message ---------- > From: > > Date: Mon, Feb 9, 2015 at 12:25 PM > Subject: New Version Notification for draft-kucherawy-rfc7001bis-00.txt > To: "Murray S. Kucherawy" > > > > > A new version of I-D, draft-kucherawy-rfc7001bis-00.txt > has been successfully submitted by Murray S. Kucherawy and posted to the > IETF repository. > > Name: draft-kucherawy-rfc7001bis > Revision: 00 > Title: Message Header Field for Indicating Message > Authentication Status > Document date: 2015-02-09 > Group: Individual Submission > Pages: 43 > URL: http://www.ietf.org/internet-drafts/draft-kucherawy-rfc7001bis-00.txt > Status: https://datatracker.ietf.org/doc/draft-kucherawy-rfc7001bis/ > Htmlized: http://tools.ietf.org/html/draft-kucherawy-rfc7001bis-00 > > > 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. > > > > > 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 > . > > The IETF Secretariat > > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --------------010201030702030309090804 Content-Type: text/html; charset=windows-1252 Content-transfer-encoding: quoted-printable On 09/02/2015 20:29, Murray S. Kucherawy wrote:
As discussued, to resolve erratum #4201.=A0 This is the XML for RFC7001 produced by the RFC Editor post-AUTH48, with only minor changes like clearing out the old "Changes since..." section.=A0 This should enable easy tracking of changes since RFC7001.=A0 I've put a "To Do" section listing the few things I think should be handled in this update, but haven't done any of the work listed there yet.

With my chair hat off, as I am the author: I propose processing this via APPSAWG since the documents it replaces also followed that path.=A0 Alexey, you'll have to push the buttons on this one.=A0 :-)
Considering that RFC 7001 was produced by APPSAWG and there is enough interest to revise it, this co-chair states that there is support for doing rfc7001bis in APPSAWG. Please state any objections with 1 week.

Thank you,
Alexey, as co-chair.

-MSK

---------- Forwarded message ----------
From: <internet-draf= ts@ietf.org>
Date: Mon, Feb 9, 2015 at 12:25 PM
Subject: New Version Notification for draft-kucherawy-rfc7001bis-00.txt
To: "Murray S. Kucherawy" <superuser@gmail.com<= /a>>



A new version of I-D, draft-kucherawy-rfc7001bis-00.txt
has been successfully submitted by Murray S. Kucherawy and posted to the
IETF repository.

Name:=A0 =A0 =A0 =A0 =A0 =A0draft-kucherawy-rfc7001bis
Revision:=A0 =A0 =A0 =A000
Title:=A0 =A0 =A0 =A0 =A0 Message Header Field for Indicat= ing Message Authentication Status
Document date:=A0 2015-02-09
Group:=A0 =A0 =A0 =A0 =A0 Individual Submission
Pages:=A0 =A0 =A0 =A0 =A0 43
URL:=A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/internet-drafts/dr= aft-kucherawy-rfc7001bis-00.txt
Status:=A0 =A0 =A0 =A0 =A0https://datatracker.ietf.org/doc/draft= -kucherawy-rfc7001bis/
Htmlized:=A0 =A0 =A0 =A0http://tools.ietf.org/html/draft-kuche= rawy-rfc7001bis-00


Abstract:
=A0 =A0This document specifies a message header field called Authentication-
=A0 =A0Results for use with electronic mail messages to indicate the results
=A0 =A0of message authentication efforts.=A0 Any receiver-side software, such
=A0 =A0as mail filters or Mail User Agents (MUAs), can use this header field
=A0 =A0to relay that information in a convenient and meaningful way to users
=A0 =A0or to make sorting and filtering decisions.




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.

The IETF Secretariat




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

--------------010201030702030309090804-- From nobody Tue Feb 17 11:06: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 C5C841A90C4; Tue, 17 Feb 2015 11:06:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.012 X-Spam-Level: X-Spam-Status: No, score=-99.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_44=0.6, MANGLED_TOOL=2.3, SPF_HELO_PASS=-0.001, 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 8d4dTi-lWznj; Tue, 17 Feb 2015 11:06:27 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id F0ABF1A9093; Tue, 17 Feb 2015 11:05:49 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id C72CF182534; Tue, 17 Feb 2015 11:05:46 -0800 (PST) To: bortzmeyer+rfceditor@nic.fr, superuser@gmail.com X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20150217190546.C72CF182534@rfc-editor.org> Date: Tue, 17 Feb 2015 11:05:46 -0800 (PST) Archived-At: Cc: barryleiba@computer.org, iesg@ietf.org, apps-discuss@ietf.org, rfc-editor@rfc-editor.org Subject: [apps-discuss] [Errata Held for Document Update] RFC7001 (4201) 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, 17 Feb 2015 19:06:28 -0000 The following errata report has been held for document update for RFC7001, "Message Header Field for Indicating Message Authentication Status". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7001&eid=4201 -------------------------------------- Status: Held for Document Update Type: Technical Reported by: Stéphane Bortzmeyer Date Reported: 2014-12-15 Held by: Barry Leiba (IESG) Section: C.5 Original Text ------------- Authentication-Results: example.com; sender-id=fail header.from=example.com; dkim=pass (good signature) header.d=example.com Corrected Text -------------- No idea Notes ----- The Sender-ID test is OK (header From:) but the DKIM one names a field in the DKIM-Signature: header (d=). Isn't it a violation of section 2.2, which says 'if "ptype" is "header", this indicates from which header field the value being evaluated was extracted' Or is section 2.2 an insufficient description? ----- Verifier Notes ----- The resolution of this isn't straightforward, and will require discussion and a proper update. That is now ongoing. -------------------------------------- RFC7001 (draft-ietf-appsawg-rfc5451bis-10) -------------------------------------- Title : Message Header Field for Indicating Message Authentication Status Publication Date : September 2013 Author(s) : M. Kucherawy Category : PROPOSED STANDARD Source : Applications Area Working Group Area : Applications Stream : IETF Verifying Party : IESG From nobody Tue Feb 17 11:25: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 603D31A909C for ; Tue, 17 Feb 2015 11:25:07 -0800 (PST) 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 hQlvUNt41YAZ for ; Tue, 17 Feb 2015 11:25:05 -0800 (PST) Received: from mail-qc0-x22f.google.com (mail-qc0-x22f.google.com [IPv6:2607:f8b0:400d:c01::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 D03711A90A2 for ; Tue, 17 Feb 2015 11:25:02 -0800 (PST) Received: by mail-qc0-f175.google.com with SMTP id b13so24543330qcw.6 for ; Tue, 17 Feb 2015 11:25:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=1uI5rvYgQWKUqT3EYLL0szKBCV3baHs7000H35he5mE=; b=BctkUgfygmMMzaMmKkt4l109uOmPVYl2Vpuq6wsjfzKxLqFU4alfZSzIeyx5DZsLKK MfbFTDDXtrPB7AdFaKrbHXboTR0fBbUGVWJ3/Bz0NBs96C1ikRGmfclzVRxzMgbD3f5I zJvqQf6h1HT+VYNd4Zh8RWyZxfNpKZD0SZB6Y/EhzIz83oavblAf6y/DVGvkm+fAKbdk qfccZp1UhTCZ0Gc+Mqti15Le/LHFMG+Pt8KAXQ1ZuuZ0VjTIyCmPzHqKtfqkCTyP0LwJ AjS7pzlUAEbn7/PI7SaFhlc2bOCXGx5nnSx4mH+Et7DrDTbcIn8W1tcpXaWQ0okSosw7 3K8g== MIME-Version: 1.0 X-Received: by 10.140.134.198 with SMTP id 189mr1365344qhg.7.1424201102041; Tue, 17 Feb 2015 11:25:02 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.140.39.164 with HTTP; Tue, 17 Feb 2015 11:25:01 -0800 (PST) In-Reply-To: References: Date: Tue, 17 Feb 2015 14:25:01 -0500 X-Google-Sender-Auth: yAIuybidjwemrUlIy6WCRV_C4vo Message-ID: From: Barry Leiba To: Apps Discuss Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [apps-discuss] Designated experts needed for LDAP registries 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, 17 Feb 2015 19:25:07 -0000 Having seen no response to this (yet?), I only have one other suggestion to make: As we no longer have any participants with the experience and interest to serve as designated experts for the LDAP registries, I propose that we change the registration policies of these registries to First Come First Served, and have done with it. I am fielding objections to this approach, along with volunteers to server as designated experts, at this address. Barry, Applications AD On Tue, Jan 20, 2015 at 6:15 PM, Applications Area Directors wrote: > Kurt Zeilenga has served for many years as the designated expert for a > number of LDAP-related registries. He's asked to be replaced, as he's > been out of the LDAP world for quite some time, and no longer has the > resources to do this. Thanks very much to Kurt for all the time he's > put in until now. > > I need to find one or two (ideally, two) people who know LDAP well > enough to serve as designated experts for the following registries: > > LDAP Parameters, created by RFC 4520: > - Attribute Description Options > - Bind Authentication Method > - LDAP authzid prefixes > - LDAP ModifyRequest Operations > - LDAP Search Scopes > - Object Identifier Descriptors > - resultCode values > > LDAP-related media types, created by RFC 2425: > - text/directory Parameters > - text/directory Profiles > - text/directory Types > > These are all very low-activity registries, but it's important that we > have someone to review new and updated registrations when they come > up. The Applications Directorate list no longer shows anyone with > LDAP expertise. Is there anyone out there who can step up and handle > this? Please give generously....... > > Barry & Pete, Applications ADs > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From nobody Thu Feb 19 05:14: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 83CF01A8774; Thu, 19 Feb 2015 05:14:08 -0800 (PST) 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 JFUVnSaLu_Sw; Thu, 19 Feb 2015 05:14:06 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E68551A802E; Thu, 19 Feb 2015 05:14:06 -0800 (PST) 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.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150219131406.19242.40370.idtracker@ietfa.amsl.com> Date: Thu, 19 Feb 2015 05:14:06 -0800 Archived-At: Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc7001bis-00.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, 19 Feb 2015 13:14:08 -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-00.txt Pages : 43 Date : 2015-02-18 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-00 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 Feb 19 13:25: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 5B04A1A0250 for ; Thu, 19 Feb 2015 13:25:23 -0800 (PST) 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 OZRrMTyJU2r5 for ; Thu, 19 Feb 2015 13:25:22 -0800 (PST) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::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 AC1A51A01F9 for ; Thu, 19 Feb 2015 13:25:21 -0800 (PST) Received: by labms9 with SMTP id ms9so2322650lab.10 for ; Thu, 19 Feb 2015 13:25:20 -0800 (PST) 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=C4TDmJ6hoMszqvZKa8PKTdDzvbhX9pEwRwRwA8J2P40=; b=f8xO8yWVn0ogJTVFPnPsflntCjf6M0j3eDp/rphZULzsddL3oZmS6HZCeLU/s0mYWm 7Jjfo7ZTFaSAeb9D/SUgX2hOk0kN91FLJ5ssta1Ui1TwxeOyf2e8GNiroOolOTIJbt3C DXGuKTawgIIQFNd92bVqKNL0HRYdqCzFQFnKICry2SZpZ8V8zTY9AcFH//8nm3rJWPGR GNz0WUHLkc7U5M2NaclXoi/MbVJBv/kwVooe4AGBeYUELPuYkrbNq8XgpAH+PshStFsu a9DxBDG4NV7m7XLJs8EfroAKAKuP0e9lJj+CAdsKeMfHlgFKW96q2REpZ/Q7D/yHjar1 n8IA== MIME-Version: 1.0 X-Received: by 10.112.141.228 with SMTP id rr4mr5535922lbb.119.1424381119761; Thu, 19 Feb 2015 13:25:19 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.152.127.165 with HTTP; Thu, 19 Feb 2015 13:25:19 -0800 (PST) Date: Thu, 19 Feb 2015 13:25:19 -0800 X-Google-Sender-Auth: KuBrYqo58N_RQBvJC3DfIV4isYg Message-ID: From: Barry Leiba To: Apps Discuss Content-Type: text/plain; charset=ISO-8859-1 Archived-At: Subject: [apps-discuss] (no subject) 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, 19 Feb 2015 21:25:23 -0000 For those of you following or otherwise interested in the recent discussions regarding RFC 3986 and URI semantics and syntax, now is a good time to take a look at the current work going on in the URNbis Working Group. Consensus in that working group has been to drop 3986 *semantics* compatibility for URNs, while continuing to have URNs adhere to 3986 *syntax*. The separation of URN semantics from URLs may offer more latitude in any effort to update RFC 3986. Anyone interested in URI development, please look at URNs and the URNbis work, and, especially, please provide feedback to the URNbis working group . There will also be a URNbis working group session at IETF 92 in Dallas (right now it looks like it will be on Friday). Barry, Applications AD From nobody Thu Feb 19 21:44: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 6FBF91A01D5; Thu, 19 Feb 2015 21:44:04 -0800 (PST) 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 9ZSx4RaHpdxi; Thu, 19 Feb 2015 21:44:02 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E82A21A6FDB; Thu, 19 Feb 2015 21:44:01 -0800 (PST) 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.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150220054401.14356.12115.idtracker@ietfa.amsl.com> Date: Thu, 19 Feb 2015 21:44:01 -0800 Archived-At: Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc7001bis-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: Fri, 20 Feb 2015 05:44:04 -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-01.txt Pages : 44 Date : 2015-02-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-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-rfc7001bis-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 Fri Feb 20 08:24: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 2C8331A877A for ; Fri, 20 Feb 2015 08:24:04 -0800 (PST) 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 tbRRg2zQ_12A for ; Fri, 20 Feb 2015 08:24:02 -0800 (PST) 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 58C4E1A0066 for ; Fri, 20 Feb 2015 08:24:02 -0800 (PST) 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 A148FC400BD for ; Fri, 20 Feb 2015 10:24:00 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1424449441; bh=qWO2eBNmlUXLsoDJ87qCBfnvp+tV+FQwtlY8FWq76Nw=; h=From:To:Subject:Date:In-Reply-To:References:From; b=MIcXmb8xrk/y50nTmeK43s+3H1YIsJM5ftRIutxCPxyj7QGfWZM5FlP0Ko3V9vDXJ IY9bIVmhEcn6dw18MRcnPT9kgJ+eO6bOMjyMRfAKcqzG5ySvr0uY4oypOyMR0PvtOL RxTrsIFMF9PETlkDM3T4FKZCT5c753dPLorvfNQc= From: Scott Kitterman To: apps-discuss@ietf.org Date: Fri, 20 Feb 2015 11:24:04 -0500 Message-ID: <2731344.KQsXzmbl8d@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-45-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: <20150220054401.14356.12115.idtracker@ietfa.amsl.com> References: <20150220054401.14356.12115.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc7001bis-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: Fri, 20 Feb 2015 16:24:04 -0000 On Thursday, February 19, 2015 09:44:01 PM internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Applications Area Working > Group Working Group of the IETF. > > Title : Message Header Field for Indicating Message > Authentication Status Author : Murray S. Kucherawy > Filename : draft-ietf-appsawg-rfc7001bis-01.txt > Pages : 44 > Date : 2015-02-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. I've reviewed the draft. I think it's on the right track, but there's a lot of redundancy between the new words in the new sections 2.3 and 2.5, so that could possibly be tightened up. I'll suggest something if I get some time to work it out. I'm not sure it fully addresses the errata, but it may. Trying to read both the draft and the registry naively, leads me to think it might be confusing. http://www.iana.org/assignments/email-auth/email-auth.xhtml I think 2.5 should emphasize that the registry is the canonical location to find information about the different methods that can be used with each ptype. The list in the draft is merely exemplary. Part of the "I don't know" in the what should it say requires one to look at the registry to figure out. Definitely on the right track, in fact almost there. On a related note: In order to understand the universe of authentication results, it's necessary to look at the following RFCs (reference to 5451 is still required since 7001 doesn't include all the IANA information to establish the initial registries): RFC 5451 Message Header Field for Indicating Message Authentication Status RFC 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) draft-kucherawy-dmarc-base (DMARC) RFC 7218 Authentication-Results Registration for S/MIME RFC 7410 A Property Types Registry for the Authentication-Results Header Field Seven RFCs to understand one header field seems to me to be a lot. would it make sense to obsolete 5617, 6008, 6212, and 7218 as part of the update and create one document that (less DMARC) covers everything? Scott K From nobody Fri Feb 20 09:48: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 AC14B1A882B; Fri, 20 Feb 2015 02:31:16 -0800 (PST) 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 LFobtOAXHMN6; Fri, 20 Feb 2015 02:31:14 -0800 (PST) Received: from relay11.mail.ox.ac.uk (relay11.mail.ox.ac.uk [129.67.1.162]) by ietfa.amsl.com (Postfix) with ESMTP id 2FFFC1A87A4; Fri, 20 Feb 2015 02:31:14 -0800 (PST) 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 1YOkrY-0003dz-bZ; Fri, 20 Feb 2015 10:31:12 +0000 Received: from oerc-dynamic-225.oerc.ox.ac.uk ([129.67.194.225]) by smtp4.mail.ox.ac.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1YOkrY-0005Z2-Ei; Fri, 20 Feb 2015 10:31:12 +0000 Message-ID: <54E70CEE.8030203@ninebynine.org> Date: Fri, 20 Feb 2015 10:31:10 +0000 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: urn@ietf.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Oxford-Username: zool0635 Archived-At: X-Mailman-Approved-At: Fri, 20 Feb 2015 09:48:13 -0800 Cc: Graham Klyne Subject: Re: [apps-discuss] URN "semantics clarification", aka "syntax only" 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: Fri, 20 Feb 2015 10:31:16 -0000 Hi John, all, (bcc: apps-discuss@ietf.org) I've just taken a skim of http://tools.ietf.org/html/draft-ietf-urnbis-semantics-clarif-01, and I think the intent is fine but have a couple of questions or points of clarification. My main concern is that URNs should be considered to be a kind of URI, and should be consistently usable in all contexts where a URI is usable (though, clearly, use in a context that requires dereferencing would be undefined in the same way as use of an unknown URI scheme would be). Failure to satisfy this constraint would, IMO, force a bifurcation between URIs and URNs, which is something you say you want to avoid. This means that not only should they conform to URI syntax, but also should conform to RFC3986 URI relative resolution rules. For example, my code applies relative resolution without concern for the URI scheme used. ("Traditional" URNs avoid syntactic constructions that include the possibility of relative references.) (FWIW, I also happen to find that relative references are useful in naming contexts as well as retrieval contexts.) Jumping to section 4, which appears to be the substantive part of this document, the main change I am seeing is a change of terminology from "path", "query" and "fragment" to "p-component", "q-component" and "f-component". I take this to be a distancing of these elements in URNs from some commonly used conventions used with location-based URIs (aka URLs). To the extent that this helps to reduce confusion, this seems fine to me (thought I also think it's an open question as to whether new terminology does reduce confusion). ... You claim: "In particular, the Generic URI Syntax specification goes beyond syntax to specify the meaning and interpretation of various fields, especially the "query" and "fragment" ones and the various syntax forms and interpretations it allows for . " I disagree with this characterization with respect to "query" elements ("The query component contains non-hierarchical data that, along with data in the path component (Section 3.3), serves to identify a resource within the scope of the URI's scheme and naming authority (if any)." -- http://tools.ietf.org/html/rfc3986#section-3.4), though I accept it's commonly used to invoke dynamic search type operations. For fragments, I accept that for a URN, where there is no dereferencing, the dependence on media type is difficult. RDF [http://www.w3.org/TR/rdf11-concepts/] addresses this by simply treating the fragment as part of the overall name string, without further interpretation. It then becomes an application design/implementation issue to avoid use of fragments of retrieved entities in ways that conflict with their use in names (cf. http://www.w3.org/TR/webarch/#fragid, http://www.w3.org/TR/webarch/#media-type-fragid). In partyicular: "If no such representation exists, then the semantics of the fragment are considered unknown and, effectively, unconstrained." [ibid] For paths, it's not clear to me whether you consider the relative resolution algorithm of RFC3986 to be part of the path semantics. Per my comments above, I would be very concerned if you try to say that the resolution algorithm is not applicable to URNs, as that would mean that an application needs to know if its dealing with a URN or URI when performing otherwise scheme-independent processing. ... In summary, assuming that you do not intend to exclude relative resolution from URN handling, the documents appears to me to be a "null specification", in that it does not actually exclude anything that is required by RFC3986. I don't mean that its not useful - I think there are issues here that are usefully articulated and explained, but in the final analysis these clarifications should apply to *any* URI scheme used as a name rather than a locator. And URI schemes are always allowed to layer their own semantics on top of RFC3986, so again the notion "removes URN semantics from the scope of RFC 3896" isn't really saying anything new that I can see. So I think section 4 would more usefully be titled "Clarifications to RFC3986 as applied to URNs". #g -- By way of (partial) background to these comments, I'm currently working on a tool for small-scale research data management for which these are very real issues [https://github.com/gklyne/annalist]. I use URIs as both names and as locators, depending on context (not on the form of URI used). Goals of my work include facilitation of data sharing, and provision of a path for data on researchers' desktops to library-managed data repositories - so both location and naming issues come in to play. From nobody Fri Feb 20 10:14: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 3220A1A037C for ; Fri, 20 Feb 2015 10:14:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 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, MANGLED_TOOL=2.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 FC5av5IangbF for ; Fri, 20 Feb 2015 10:14:08 -0800 (PST) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::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 A489C1A0068 for ; Fri, 20 Feb 2015 10:14:07 -0800 (PST) Received: by mail-wg0-f44.google.com with SMTP id k14so14721521wgh.3 for ; Fri, 20 Feb 2015 10:14:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DYrtJnwTEtc328+I3cRe5X2MRUCSIBz9ohgXKSV9F0Y=; b=rmO4261SjFxw1LAQTfaYpWNj8f4NpcKMfvJhegZiFAHZlS4MGMNcMqTBaNs6W7t5id Pw5waXAJnnZ1UgqMb2d15pZ1ckssvo0b1lDFecoRbK1G5rjIviXR++rfQb9iFnHAZ/It BwxhiUdBk1i/O03r30zx+mlu2U+Oo/XGfLLCXi2q86OikLGxiPX1bQSJB5O0Hwr6wfiL 3uMHt5kkjFupc6KjparGFxguvijAjaDA/UJ9LBEolfMWLY+aRTfEFLHMlkl1CJB1fewt 37KMceqR8o0calLfc5bp/1pGewTKUHJm+x09D0GQMJXLw0XyImXv4b/EePaaoQQw4I+m jM3A== MIME-Version: 1.0 X-Received: by 10.180.106.103 with SMTP id gt7mr10280wib.59.1424456044898; Fri, 20 Feb 2015 10:14:04 -0800 (PST) Received: by 10.27.179.146 with HTTP; Fri, 20 Feb 2015 10:14:04 -0800 (PST) In-Reply-To: <2731344.KQsXzmbl8d@kitterma-e6430> References: <20150220054401.14356.12115.idtracker@ietfa.amsl.com> <2731344.KQsXzmbl8d@kitterma-e6430> Date: Fri, 20 Feb 2015 13:14:04 -0500 Message-ID: From: "Murray S. Kucherawy" To: Scott Kitterman Content-Type: multipart/alternative; boundary=f46d04428f448df62e050f8904aa Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc7001bis-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: Fri, 20 Feb 2015 18:14:10 -0000 --f46d04428f448df62e050f8904aa Content-Type: text/plain; charset=UTF-8 On Fri, Feb 20, 2015 at 11:24 AM, Scott Kitterman wrote: > I've reviewed the draft. I think it's on the right track, but there's a > lot > of redundancy between the new words in the new sections 2.3 and 2.5, so > that > could possibly be tightened up. I'll suggest something if I get some time > to > work it out. > Thanks for the suggestion. I'll take another look at it. > I'm not sure it fully addresses the errata, but it may. > I think it does, but of course I wrote the changes. I've emailed the author of the erratum to ask what he thinks. > Trying to read both the draft and the registry naively, leads me to think > it > might be confusing. > > http://www.iana.org/assignments/email-auth/email-auth.xhtml > > I think 2.5 should emphasize that the registry is the canonical location to > find information about the different methods that can be used with each > ptype. > The list in the draft is merely exemplary. Part of the "I don't know" in > the > what should it say requires one to look at the registry to figure out. > I don't know that what's in this draft is really exemplary, but rather just contains definitions and seed information as did RFC5451. But yes, some text making this more clear would probably be good. > Definitely on the right track, in fact almost there. > > On a related note: > > In order to understand the universe of authentication results, it's > necessary > to look at the following RFCs (reference to 5451 is still required since > 7001 > doesn't include all the IANA information to establish the initial > registries): > > RFC 5451 Message Header Field for Indicating Message Authentication Status > RFC 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) > draft-kucherawy-dmarc-base (DMARC) > RFC 7218 Authentication-Results Registration for S/MIME > RFC 7410 A Property Types Registry for the Authentication-Results Header > Field > > Seven RFCs to understand one header field seems to me to be a lot. would > it > make sense to obsolete 5617, 6008, 6212, and 7218 as part of the update and > create one document that (less DMARC) covers everything? > RFC5451 is fully obsoleted by RFC7001, unless one is curious about how the registries were originally created. RFC5617 can't be obsoleted by this because that document not only declares the A-R registry entries for ADSP, but defines ADSP itself. It seems out of scope for an A-R revision to obsolete a separate protocol document. RFC6008, RFC6212 and RFC7218 are all registration actions. I think those should be separate, and the registry considered canonical as you've suggested. There's no need to consolidate in general, otherwise we'd be long overdue for a re-issuing of MIME, SMTP, etc. for all the new registrations that have come along. RFC7001 and RFC7410 are incorporated into this draft and obsoleted (see the title page), so those are covered. -MSK --f46d04428f448df62e050f8904aa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Feb 20, 2015 at 11:24 AM, Scott Kitterman <scot= t@kitterman.com> wrote:
I've reviewed the dr= aft.=C2=A0 I think it's on the right track, but there's a lot
of=C2=A0 redundancy between the new words in the new sections 2.3 and 2.5, = so that
could possibly be tightened up.=C2=A0 I'll suggest something if I get s= ome time to
work it out.

Thanks for the suggestion.= =C2=A0 I'll take another look at it.
=C2=A0
I'm not sure it fully addresses the errata, but it may.

I think it does, but of course I wrote the changes.=C2= =A0 I've emailed the author of the erratum to ask what he thinks.
= =C2=A0
Trying to read both the draft and the registry naively, leads me to think i= t
might be confusing.

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

I think 2.5 should emphasize that the registry is the canonical location to=
find information about the different methods that can be used with each pty= pe.
The list in the draft is merely exemplary.=C2=A0 Part of the "I don= 9;t know" in the
what should it say requires one to look at the registry to figure out.
<= /blockquote>
I don't know that what= 's in this draft is really exemplary, but rather just contains definiti= ons and seed information as did RFC5451.=C2=A0 But yes, some text making th= is more clear would probably be good.
Definitely on the right track, in fact almost there.

On a related note:

In order to understand the universe of authentication results, it's nec= essary
to look at the following RFCs (reference to 5451 is still required since 70= 01
doesn't include all the IANA information to establish the initial regis= tries):

RFC 5451 Message Header Field for Indicating Message Authentication Status<= br> RFC 7001 Message Header Field for Indicating Message Authentication Status<= br> RFC 5617 DKIM/ADSP
RFC 6008 DKIM signature identification (header.b)
RFC 6212 Vouch By Reference (VBR)
draft-kucherawy-dmarc-base (DMARC)
RFC 7218 Authentication-Results Registration for S/MIME
RFC 7410 A Property Types Registry for the Authentication-Results Header Fi= eld

Seven RFCs to understand one header field seems to me to be a lot.=C2=A0 wo= uld it
make sense to obsolete 5617, 6008, 6212, and 7218 as part of the update and=
create one document that (less DMARC) covers everything?

RFC7001 and RFC7410 are incorporated into this draft and obsoleted (see th= e title page), so those are covered.

--f46d04428f448df62e050f8904aa-- From nobody Fri Feb 20 19:15: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 1EF421A1A31; Fri, 20 Feb 2015 19:14:58 -0800 (PST) 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 k5zQWNz_oLOz; Fri, 20 Feb 2015 19:14:56 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD4D1A1A60; Fri, 20 Feb 2015 19:14:55 -0800 (PST) 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.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150221031455.12745.58697.idtracker@ietfa.amsl.com> Date: Fri, 20 Feb 2015 19:14:55 -0800 Archived-At: Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc7001bis-02.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: Sat, 21 Feb 2015 03:14: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 : Message Header Field for Indicating Message Authentication Status Author : Murray S. Kucherawy Filename : draft-ietf-appsawg-rfc7001bis-02.txt Pages : 44 Date : 2015-02-20 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-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-rfc7001bis-02 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 Feb 20 21:17: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 1B05F1A1B0C for ; Fri, 20 Feb 2015 21:17:42 -0800 (PST) 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 zfr7L4_am343 for ; Fri, 20 Feb 2015 21:17:40 -0800 (PST) Received: from mailout03.controlledmail.com (mailout03.controlledmail.com [208.43.65.50]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63A4A1A1B0B for ; Fri, 20 Feb 2015 21:17:40 -0800 (PST) Received: from [192.168.111.2] (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout03.controlledmail.com (Postfix) with ESMTPSA id BBAACC402B1; Fri, 20 Feb 2015 23:17:36 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1424495858; bh=pHgdJYxtnx56mallrvavZzsdkteEgAbhTGU1/vOhmGg=; h=In-Reply-To:References:Subject:From:Date:To:From; b=VD9nuZT4mIjvHf0YIwsSjaDEs/H6sIH0lsob0Pkdnsw8Pn09Z7xvxDEn9LaM1ex9a 29XM8MqDnXvKryJxqFBINaYVdGzoRSJCyqu1Fd9BmVtcDkHhHIrCVSSy4QGN0FkfRu leSvJqWOdhiIwGIiNXKh2OlxaAbRZk/T63VeIy4I= User-Agent: K-9 Mail for Android In-Reply-To: <20150221031455.12745.58697.idtracker@ietfa.amsl.com> References: <20150221031455.12745.58697.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Scott Kitterman Date: Sat, 21 Feb 2015 00:16:57 -0500 To: apps-discuss@ietf.org Message-ID: <5E5B4DA0-D745-449C-B28C-81D32756BFD3@kitterman.com> Archived-At: Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc7001bis-02.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, 21 Feb 2015 05:17:42 -0000 On February 20, 2015 10:14:55 PM EST, internet-drafts@ietf.org wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the Applications Area Working Group >Working Group of the IETF. > >Title : Message Header Field for Indicating Message >Authentication Status > Author : Murray S. Kucherawy > Filename : draft-ietf-appsawg-rfc7001bis-02.txt > Pages : 44 > Date : 2015-02-20 Thanks. Your earlier email and -02 address my comments on -01. I think this covers it. Scott K From nobody Sat Feb 21 20:03: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 415B41A1A31 for ; Sat, 21 Feb 2015 20:03:49 -0800 (PST) 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 nCqCaKot_3hS for ; Sat, 21 Feb 2015 20:03:47 -0800 (PST) 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 B9F0D1A0439 for ; Sat, 21 Feb 2015 20:03:47 -0800 (PST) Received: (qmail 11820 invoked from network); 22 Feb 2015 04:03:46 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 22 Feb 2015 04:03:46 -0000 Date: 22 Feb 2015 04:03:24 -0000 Message-ID: <20150222040324.1007.qmail@ary.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <5E5B4DA0-D745-449C-B28C-81D32756BFD3@kitterman.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: scott@kitterman.com Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc7001bis-02.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: Sun, 22 Feb 2015 04:03:49 -0000 >Thanks. Your earlier email and -02 address my comments on -01. I think >this covers it. I've been on the road for the last two weeks, will try to read and comment when I finally get home tomorrow. R's, John From nobody Sat Feb 21 21:29: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 769F01A011E; Fri, 20 Feb 2015 12:05:19 -0800 (PST) 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 Jru4fZxaHmtS; Fri, 20 Feb 2015 12:05:17 -0800 (PST) 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 2C2591A0089; Fri, 20 Feb 2015 12:05:15 -0800 (PST) Received: from [10.37.3.37] (unknown [38.104.134.62]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 2CE2B509BF; Fri, 20 Feb 2015 15:05:11 -0500 (EST) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=windows-1252 From: Sean Leonard In-Reply-To: <54E70CEE.8030203@ninebynine.org> Date: Fri, 20 Feb 2015 12:05:09 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <129582A1-F3E5-4EC5-A3A9-EEFBDA75B345@seantek.com> References: <54E70CEE.8030203@ninebynine.org> To: urn@ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: X-Mailman-Approved-At: Sat, 21 Feb 2015 21:29:11 -0800 Cc: Graham Klyne , Graham Klyne Subject: Re: [apps-discuss] URN "semantics clarification", aka "syntax only" 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: Fri, 20 Feb 2015 20:05:19 -0000 (also bcc=92ing apps-discuss=85although not exactly sure why it=92s = bcc=92ed) On Feb 20, 2015, at 2:31 AM, Graham Klyne wrote: > Hi John, all, >=20 > (bcc: apps-discuss@ietf.org) >=20 > I've just taken a skim of = http://tools.ietf.org/html/draft-ietf-urnbis-semantics-clarif-01, and I = think the intent is fine but have a couple of questions or points of = clarification. >=20 > My main concern is that URNs should be considered to be a kind of URI, = and should be consistently usable in all contexts where a URI is usable = (though, clearly, use in a context that requires dereferencing would be = undefined in the same way as use of an unknown URI scheme would be). =20 +1. I agree with Graham, namely, that a URN should be considered a kind = of URI. (On that particular sentence I agree +1000.) It=92s not just = that they are syntactically the same=97a URN is a species of URI, = namely, a URI scheme. Compare with HTTP URI being a URI. It=92s worth = pointing out that since RFC 3986 says that URIs are semantics-free = (mostly), that part of the URI spec may be cited in support of the = premise that just because a URN is a kind of URI, it doesn=92t imply = much else with regard to semantics. > Failure to satisfy this constraint would, IMO, force a bifurcation = between URIs and URNs, which is something you say you want to avoid. >=20 > This means that not only should they conform to URI syntax, but also = should conform to RFC3986 URI relative resolution rules. For example, = my code applies relative resolution without concern for the URI scheme = used. ("Traditional" URNs avoid syntactic constructions that include = the possibility of relative references.) (FWIW, I also happen to find = that relative references are useful in naming contexts as well as = retrieval contexts.) There are philosophical and practical problems with URI=92s relative = resolution rules as applied to urn: URIs, which have been covered = extensively on the urn mailing list around October-November 2014, so = best to check that. I am happy to elaborate on my understanding if that = helps things but want to keep this e-mail short now. >=20 > Jumping to section 4, which appears to be the substantive part of this = document, the main change I am seeing is a change of terminology from = "path", "query" and "fragment" to "p-component", "q-component" and = "f-component". I take this to be a distancing of these elements in URNs = from some commonly used conventions used with location-based URIs (aka = URLs). To the extent that this helps to reduce confusion, this seems = fine to me (thought I also think it's an open question as to whether new = terminology does reduce confusion). I actually disagree with the terms p-component, q-component, and = f-component on editorial grounds. The problem is that =93path=94, = =93query=94, and =93fragment=94 were thought to imply some things that = URNBIS people disagreed with. However, calling them x-component is = annoying to me=85particularly because a fragment is a fragment is a = fragment. For discussion purposes in I-Ds I was okay with it, but in any final = RFCs I request that we go back to calling them =93path=94, =93query=94, = and =93fragment=94. Specifically, how about referring to them as the = =93path production of [RFC3986]=94 and similar? By calling it =93path = production=94 you are specifically referring to the RFC 3986 URI ABNF = grammar, which is about syntax, and does not imply that URNs are = =93path-oriented=94 or the like. Cheers, Sean= From nobody Sat Feb 21 21: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 6F2FB1A1A9D; Sat, 21 Feb 2015 21:30:39 -0800 (PST) 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 laMTX2Whm_sf; Sat, 21 Feb 2015 21:30:37 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 885311A1A9B; Sat, 21 Feb 2015 21:30:37 -0800 (PST) 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.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150222053037.21715.55249.idtracker@ietfa.amsl.com> Date: Sat, 21 Feb 2015 21:30:37 -0800 Archived-At: Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-text-markdown-use-cases-00.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: Sun, 22 Feb 2015 05:30:39 -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 : text/markdown Use Cases Author : Sean Leonard Filename : draft-ietf-appsawg-text-markdown-use-cases-00.txt Pages : 18 Date : 2015-02-21 Abstract: This document elaborates upon 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. Background information, local storage strategies, and additional syntax registrations are supplied. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-text-markdown-use-cases/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-text-markdown-use-cases-00 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 Sat Feb 21 21:39: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 2B2741A1A9F for ; Sat, 21 Feb 2015 21:39:11 -0800 (PST) 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 AaMIdpdnW1jh for ; Sat, 21 Feb 2015 21:39:10 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D80071A1AA1 for ; Sat, 21 Feb 2015 21:39:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150222053908.27776.66019.idtracker@ietfa.amsl.com> Date: Sat, 21 Feb 2015 21:39:08 -0800 From: IETF Secretariat Archived-At: Subject: [apps-discuss] Milestones changed for appsawg WG 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: Sun, 22 Feb 2015 05:39:11 -0000 Changed milestone "Publication requested for draft-ietf-appsawg-rfc7001bis", set state to active from review, accepting new milestone. Changed milestone "Publication requested for draft-ietf-appsawg-text-markdown-use-cases", set state to active from review, accepting new milestone. URL: http://datatracker.ietf.org/wg/appsawg/charter/ From nobody Sun Feb 22 18:28: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 65C961A00FD for ; Sun, 22 Feb 2015 18:28:20 -0800 (PST) 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 t6u2tSY0814H for ; Sun, 22 Feb 2015 18:28:19 -0800 (PST) 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 284081A00FB for ; Sun, 22 Feb 2015 18:28:18 -0800 (PST) Received: (qmail 90847 invoked from network); 23 Feb 2015 02:28:17 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 23 Feb 2015 02:28:17 -0000 Date: 23 Feb 2015 02:27:55 -0000 Message-ID: <20150223022755.57459.qmail@ary.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <20150221031455.12745.58697.idtracker@ietfa.amsl.com> 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] I-D Action: draft-ietf-appsawg-rfc7001bis-02.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: Mon, 23 Feb 2015 02:28:20 -0000 Either I'm going blind, or this draft doesn't address the issues in errata 4201 which was the main reason we're doing this revision. It needs to define the ptypes and properties for each result type. Section 2.7.1 (or some place) needs to say that for DKIM results, the ptype is "header" and the property for each header is the name of fields in the DKIM signature header with the values are the value of the field. Section 2.7.2 needs to say that for SPF results, the ptype is "spf", the properties are helo and mailfrom, with the values being the arguments to those commands, with the mailfrom value just being the address, not any extra keywords. For Sender-ID, I suppose the ptype is sender-id and the properties are the PRA or something, but I've never seen a Sender-ID A-R header so I'm not sure. Section 2.7.3 and 2.7.4 and 2.7.5 similarly need to define the ptype and properties that appear for iprev and SMTP AUTH and VBR and ATPS and ADSP. Again, I haven't seen any of those and I don't know what the running code does. R's, John From nobody Sun Feb 22 18:41: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 713EC1A00FB for ; Sun, 22 Feb 2015 18:41:15 -0800 (PST) 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 HYH7gvI0wO12 for ; Sun, 22 Feb 2015 18:41:14 -0800 (PST) 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 191241A0121 for ; Sun, 22 Feb 2015 18:41:11 -0800 (PST) Received: (qmail 92225 invoked from network); 23 Feb 2015 02:41:08 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 23 Feb 2015 02:41:08 -0000 Date: 23 Feb 2015 02:40:46 -0000 Message-ID: <20150223024046.57508.qmail@ary.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc7001bis-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: Mon, 23 Feb 2015 02:41:15 -0000 PS: Now that I look at the IANA registry, I see that the property values are all collected there, but the sources are quite confusing. For example, it says that for sender-id, the ptype is header and the property is the header that PRA used, but the source is claimed to be RFC 4406 which predates A-R. Where did the IANA registry entry come from? Similarly the domainkeys entries say they're from RFC 4870 which defines a Domainkey-Status: header but says nothing about A-R. And the "auth" results say they're from RFC 4954, ditto. At the very least the 2.7.x sections in 7001bis should tell you where the ptypes and properties are defined, and the ones that aren't actually defined anywhere should be defined there. R's, John From nobody Mon Feb 23 07:52: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 E9BA51A1B6E for ; Mon, 23 Feb 2015 07:52:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.099 X-Spam-Level: *** X-Spam-Status: No, score=3.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 Aw855zQf7VMq for ; Mon, 23 Feb 2015 07:52:37 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0704.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::704]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 593C41A1A1D for ; Mon, 23 Feb 2015 07:52:34 -0800 (PST) Received: from pc6 (81.151.167.59) by DB3PR07MB059.eurprd07.prod.outlook.com (10.242.137.149) with Microsoft SMTP Server (TLS) id 15.1.87.18; Mon, 23 Feb 2015 15:52:13 +0000 Message-ID: <01fa01d04f80$6bb9eee0$4001a8c0@gateway.2wire.net> From: t.petch To: Scott Kitterman , apps-discuss References: <20150220054401.14356.12115.idtracker@ietfa.amsl.com> <2731344.KQsXzmbl8d@kitterma-e6430> Date: Mon, 23 Feb 2015 15:49:19 +0000 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.167.59] X-ClientProxiedBy: DB3PR05CA0012.eurprd05.prod.outlook.com (25.160.41.140) To DB3PR07MB059.eurprd07.prod.outlook.com (10.242.137.149) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DB3PR07MB059; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005003); SRVR:DB3PR07MB059; X-Forefront-PRVS: 0496DF6962 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(51444003)(199003)(51704005)(189002)(13464003)(377454003)(377424004)(50466002)(64706001)(62236002)(44716002)(46102003)(50226001)(97736003)(116806002)(33646002)(62966003)(230783001)(66066001)(40100003)(47776003)(86362001)(106356001)(122386002)(105586002)(23756003)(61296003)(14496001)(15975445007)(81686999)(42186005)(1556002)(77156002)(92566002)(19580405001)(81816999)(1456003)(77096005)(44736004)(50986999)(84392001)(87976001)(68736005)(19580395003)(76176999)(101416001)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR07MB059; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DB3PR07MB059; X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Feb 2015 15:52:13.7580 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR07MB059 Archived-At: Cc: "\"John Levine\"" Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc7001bis-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: Mon, 23 Feb 2015 15:52:40 -0000 ----- Original Message ----- From: "Scott Kitterman" To: Sent: Friday, February 20, 2015 4:24 PM > On Thursday, February 19, 2015 09:44:01 PM internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. This draft is a work item of the Applications Area Working > > Group Working Group of the IETF. > > > > Title : Message Header Field for Indicating Message > > Authentication Status Author : Murray S. Kucherawy > > Filename : draft-ietf-appsawg-rfc7001bis-01.txt > > Pages : 44 > > Date : 2015-02-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. > > I've reviewed the draft. I think it's on the right track, but there's a lot > of redundancy between the new words in the new sections 2.3 and 2.5, so that > could possibly be tightened up. I'll suggest something if I get some time to > work it out. > > I'm not sure it fully addresses the errata, but it may. > > Trying to read both the draft and the registry naively, leads me to think it > might be confusing. > > http://www.iana.org/assignments/email-auth/email-auth.xhtml > > I think 2.5 should emphasize that the registry is the canonical location to > find information about the different methods that can be used with each ptype. > The list in the draft is merely exemplary. Part of the "I don't know" in the > what should it say requires one to look at the registry to figure out. > > Definitely on the right track, in fact almost there. > > On a related note: > > In order to understand the universe of authentication results, it's necessary > to look at the following RFCs (reference to 5451 is still required since 7001 > doesn't include all the IANA information to establish the initial registries): > > RFC 5451 Message Header Field for Indicating Message Authentication Status > RFC 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) > draft-kucherawy-dmarc-base (DMARC) > RFC 7218 Authentication-Results Registration for S/MIME > RFC 7410 A Property Types Registry for the Authentication-Results Header Field > > Seven RFCs to understand one header field seems to me to be a lot. would it > make sense to obsolete 5617, 6008, 6212, and 7218 as part of the update and > create one document that (less DMARC) covers everything? I think that it is worse than that. I started with Authentication Methods, reckoning I needed to be clear on them before Results would make sense to me. IANA references 4406, 4408, 4870, 4954, 5617, 5751, 6212, 6376, 6541 several of which have no IANA section at all and those that do, mostly do not mention the Authentication Methods registry. With hindsight, it all went wrong with RFC5451 which set up the registry but did not provide the entries which could be presumed to occur in the earlier RFC4xxx had the registry been in existence a few years earlier. So we start with foundations of sand which were 'built' on by RFC7001 and ...well, I don't know where to go now except a bit more cautiously and thoroughly than in the past. Tom Petch > > Scott K > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From nobody Mon Feb 23 08:08: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 2C6861A1B30 for ; Mon, 23 Feb 2015 08:08:24 -0800 (PST) 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 v0CtAQDrpBAw for ; Mon, 23 Feb 2015 08:08:23 -0800 (PST) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::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 CFFBB1A1AAA for ; Mon, 23 Feb 2015 08:08:21 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id h11so18485636wiw.1 for ; Mon, 23 Feb 2015 08:08:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZmP47w0Zd+Uwv+A6gu3NQ6GU9UERzF7R5gmuDea712A=; b=dir2BH0/5+j3tEFHyeW9a12VSg4H9GdbXN67enkZ1sa/Gv3J2GKpEYSdbZRplQxggC KaoW7/lzhxrc1XKlw8f+jxm+tMM4e/0U0jBlzuLfQvQst3x5HRf0TEX1kGTnYvXRPwZr 2nAYywNJiVPPR6dP5OITj2RQLTrdcmPvr45YRvgVBTLgSkBYUT75aaoTbbnvtk9h3R9p YeySKPtEbLRBCvz8clbg/TMNthqF5dwSKS1je+4E9ldIVLP9EC9oYBj66CIPagKU+ZQ6 H2LPv7Mksy/QDbH/ILo5WlMgaqn65uWf9+fLoEybLuP67en1y6Q3jWVZxBV+vX6uGSxv heuA== MIME-Version: 1.0 X-Received: by 10.194.185.9 with SMTP id ey9mr24026488wjc.135.1424707700562; Mon, 23 Feb 2015 08:08:20 -0800 (PST) Received: by 10.27.179.146 with HTTP; Mon, 23 Feb 2015 08:08:20 -0800 (PST) In-Reply-To: <01fa01d04f80$6bb9eee0$4001a8c0@gateway.2wire.net> References: <20150220054401.14356.12115.idtracker@ietfa.amsl.com> <2731344.KQsXzmbl8d@kitterma-e6430> <01fa01d04f80$6bb9eee0$4001a8c0@gateway.2wire.net> Date: Mon, 23 Feb 2015 11:08:20 -0500 Message-ID: From: "Murray S. Kucherawy" To: "t.petch" Content-Type: multipart/alternative; boundary=047d7bd6adce669ff5050fc39c68 Archived-At: Cc: Scott Kitterman , John Levine , apps-discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc7001bis-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: Mon, 23 Feb 2015 16:08:24 -0000 --047d7bd6adce669ff5050fc39c68 Content-Type: text/plain; charset=UTF-8 On Mon, Feb 23, 2015 at 10:49 AM, t.petch wrote: > I think that it is worse than that. I started with Authentication > Methods, reckoning I needed to be clear on them before Results would > make sense to me. IANA references 4406, 4408, 4870, 4954, 5617, 5751, > 6212, 6376, 6541 > several of which have no IANA section at all and those that do, mostly > do not mention the Authentication Methods registry. With hindsight, it > all went wrong with RFC5451 which set up the registry but did not > provide the entries which could be presumed to occur in the earlier > RFC4xxx had the registry been in existence a few years earlier. So we > start with foundations of sand which were 'built' on by RFC7001 and > ...well, I don't know where to go now except a bit more cautiously and > thoroughly than in the past. > What entries do you think are missing that RFC5451 should've added? It did register methods and results for all of those protocol RFCs (except, of course, the ones that came after it). -MSK --047d7bd6adce669ff5050fc39c68 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Feb 23, 2015 at 10:49 AM, t.petch <ietfc@btconn= ect.com> wrote:
I think that it is worse than th= at.=C2=A0 I started with Authentication
Methods, reckoning I needed to be clear on them before Results would
make sense to me.=C2=A0 IANA references 4406, 4408, 4870, 4954, 5617, 5751,=
6212, 6376, 6541
=C2=A0several of which have no IANA section at all=C2=A0 and those that do,= mostly
do not mention the Authentication Methods registry.=C2=A0 With hindsight, i= t
all went wrong with RFC5451 which set up the registry but did not
provide the entries which could be presumed to occur in the earlier
RFC4xxx had the registry been in existence a few years earlier.=C2=A0 So we=
start with foundations of sand which were 'built' on by RFC7001 and=
...well, I don't know where to go now except a bit more cautiously and<= br> thoroughly than in the past.

What entri= es do you think are missing that RFC5451 should've added?=C2=A0 It did = register methods and results for all of those protocol RFCs (except, of cou= rse, the ones that came after it).

-MSK
--047d7bd6adce669ff5050fc39c68-- From nobody Mon Feb 23 08:31: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 00F1D1A1AAA for ; Mon, 23 Feb 2015 08:31:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_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 t1vUS1a6PD53 for ; Mon, 23 Feb 2015 08:31:51 -0800 (PST) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::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 265341A00D0 for ; Mon, 23 Feb 2015 08:31:51 -0800 (PST) Received: by mail-wi0-f174.google.com with SMTP id em10so19003269wid.1 for ; Mon, 23 Feb 2015 08:31:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=W6ryWv6CqgSqnoshALzCIk7HuxOUw4isX/9D4Ruhu1U=; b=aWZq9/3gF0PYyGrLrEjhU7QLXe2NxzpmnsrzbUUW3uGb6dLM0Mkoq14gvHbJ2lSfrz BeE9Qm7J4I5sMx1h6hMaVOOKkjLYkvK54k4Q8KBCssTrKH/qeECa/9aE7ID3hD8cDsG3 8K2BjE8d5FHYGQqp8cAn3uuYLg1BztjyXSVMQDqcpkRkqX64B+c3LBg1xNjisE25/Hts qLGyls673lsNcSzzZha1G+gP5gHA26z5BN+7c0mhQFabCScM5mPvxwbgDNHuPCLGBij6 fMP1yG4tGOWtMDwbSFEvvTCcwR/j9BBSSIR44kT0V5yoicdZ5Ad2AlidGrXHY8taR3pp lnKg== MIME-Version: 1.0 X-Received: by 10.194.179.194 with SMTP id di2mr23652236wjc.4.1424709109679; Mon, 23 Feb 2015 08:31:49 -0800 (PST) Received: by 10.27.179.146 with HTTP; Mon, 23 Feb 2015 08:31:49 -0800 (PST) In-Reply-To: <20150223024046.57508.qmail@ary.lan> References: <20150223024046.57508.qmail@ary.lan> Date: Mon, 23 Feb 2015 11:31:49 -0500 Message-ID: From: "Murray S. Kucherawy" To: John Levine Content-Type: multipart/alternative; boundary=089e01419d1c640c37050fc3f0e3 Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc7001bis-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: Mon, 23 Feb 2015 16:31:53 -0000 --089e01419d1c640c37050fc3f0e3 Content-Type: text/plain; charset=UTF-8 On Sun, Feb 22, 2015 at 9:40 PM, John Levine wrote: > PS: Now that I look at the IANA registry, I see that the property > values are all collected there, but the sources are quite confusing. > > For example, it says that for sender-id, the ptype is header and the > property is the header that PRA used, but the source is claimed to be > RFC 4406 which predates A-R. Where did the IANA registry entry come > from? > RFC5451 created entries for protocols that existed prior to its existence. The definition of "senderid" and the PRA appear in RFC4406. So the methods registry's "sender-id" entry points to RFC4406. The results registry points to RFC5451 because that's where you go to find out what (for example) "fail" means. For things like SPF and SID that included those definitions, it could go either way, and consensus was to do what we did here. For things like DomainKeys and DKIM which didn't define failure codes, the original reference was RFC5451. Similarly the domainkeys entries say they're from RFC 4870 which > defines a Domainkey-Status: header but says nothing about A-R. And > the "auth" results say they're from RFC 4954, ditto. > Same idea there too; we'd have to reissue all of those RFCs if the rule is that the protocol document has to also contain all of the places that protocol might be registered. > At the very least the 2.7.x sections in 7001bis should tell you where > the ptypes and properties are defined, and the ones that aren't > actually defined anywhere should be defined there. > I'm confused. The known method/property/ptype combinations are enumerated in the registry, which is what it's for. Is that not sufficient? It sounds like you want to add a column to the registry that points back to the RFC that added each entry. Is that the case? -MSK --089e01419d1c640c37050fc3f0e3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sun, Feb 22, 2015 at 9:40 PM, John Levine <johnl@taugh.c= om> wrote:
PS: Now that I look at the IANA regis= try, I see that the property
values are all collected there, but the sources are quite confusing.

For example, it says that for sender-id, the ptype is header and the
property is the header that PRA used, but the source is claimed to be
RFC 4406 which predates A-R.=C2=A0 Where did the IANA registry entry come from?

RFC5451 created entries for proto= cols that existed prior to its existence.=C2=A0 The definition of "sen= derid" and the PRA appear in RFC4406.=C2=A0 So the methods registry= 9;s "sender-id" entry points to RFC4406.

The re= sults registry points to RFC5451 because that's where you go to find ou= t what (for example) "fail" means.=C2=A0 For things like SPF and = SID that included those definitions, it could go either way, and consensus = was to do what we did here.=C2=A0 For things like DomainKeys and DKIM which= didn't define failure codes, the original reference was RFC5451.
Similarly the domainkeys entries say they're from RFC 4870 which
defines a Domainkey-Status: header but says nothing about A-R.=C2=A0 And the "auth" results say they're from RFC 4954, ditto.

Same idea there too; we'd have to reissue a= ll of those RFCs if the rule is that the protocol document has to also cont= ain all of the places that protocol might be registered.
=C2=A0
At the very least the 2.7.x sections in 7001bis should tell you where
the ptypes and properties are defined, and the ones that aren't
actually defined anywhere should be defined there.
I'm confused.=C2=A0 The known method/property/ptype combina= tions are enumerated in the registry, which is what it's for.=C2=A0 Is = that not sufficient?

It sounds like you want to add a col= umn to the registry that points back to the RFC that added each entry.=C2= =A0 Is that the case?

-MSK
--089e01419d1c640c37050fc3f0e3-- From nobody Mon Feb 23 08:39:58 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 5CB2E1A1ADD for ; Mon, 23 Feb 2015 08:39:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_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 7Kx9hZkiUFfh for ; Mon, 23 Feb 2015 08:39:55 -0800 (PST) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::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 4CBED1A1B23 for ; Mon, 23 Feb 2015 08:39:55 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id h11so18833463wiw.1 for ; Mon, 23 Feb 2015 08:39:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=c5FWBMneRH6x0RoPS31SjhWjEkRqsOfmw2lHaJlvYP8=; b=yNaa8hFQjE5ANrOLjnemAmpgok75NyIdKDGcadO7qKDLhcJAsHsXp2iiVfw6iqgr+y y07wU496aIQENUac7qb9tfcQGBHn1TpLgX8qghkuRfUQBgxO+QDklVQMvG+A1AnO3c+x labYZaXVQnI1KDi4AGSt0WF6a6uEFA8qRi/xQcmQjy+GLNNzGTVSCJCL9rtLTjA8RPr4 kJt40gBx3hME51/8jZnTdMIko3sYMMThT5wkBMRT4Lgc2kwBMCMWQ+1/x3yXVjDxJNYD IGOEN0iLlmAxY/hcFmDaq0o+hhDNO6OyuinCMrTL4fIAh0SY4Be4khzXa5gGXCVKuOPX U7CQ== MIME-Version: 1.0 X-Received: by 10.180.206.98 with SMTP id ln2mr22153310wic.94.1424709592867; Mon, 23 Feb 2015 08:39:52 -0800 (PST) Received: by 10.27.179.146 with HTTP; Mon, 23 Feb 2015 08:39:52 -0800 (PST) In-Reply-To: <20150223022755.57459.qmail@ary.lan> References: <20150221031455.12745.58697.idtracker@ietfa.amsl.com> <20150223022755.57459.qmail@ary.lan> Date: Mon, 23 Feb 2015 11:39:52 -0500 Message-ID: From: "Murray S. Kucherawy" To: John Levine Content-Type: multipart/alternative; boundary=001a11c381ce30ed9e050fc40de5 Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc7001bis-02.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: Mon, 23 Feb 2015 16:39:57 -0000 --001a11c381ce30ed9e050fc40de5 Content-Type: text/plain; charset=UTF-8 On Sun, Feb 22, 2015 at 9:27 PM, John Levine wrote: > Either I'm going blind, or this draft doesn't address the issues in > errata 4201 which was the main reason we're doing this revision. It > needs to define the ptypes and properties for each result type. > My understanding of the erratum is that the definition of "header" as a ptype is that the property will then contain a header field name, while "d" (which is what DKIM uses to report the signing domain) is not a known header field name. I think that's addressed by what I just proposed to Stephane. > Section 2.7.1 (or some place) needs to say that for DKIM results, the > ptype is "header" and the property for each header is the name of > fields in the DKIM signature header with the values are the value of > the field. > That's in 2.3 now, and I proposed splitting it off to 2.8.1, which aligns it with your suggestion. > Section 2.7.2 needs to say that for SPF results, the ptype is "spf", > the properties are helo and mailfrom, with the values being the > arguments to those commands, with the mailfrom value just being the > address, not any extra keywords. For Sender-ID, I suppose the ptype > is sender-id and the properties are the PRA or something, but I've > never seen a Sender-ID A-R header so I'm not sure. > The ptype is "header", the property is whatever header field the PRA was pulled from, and the value is the PRA. That's shown in the registry, which was created by RFC5451 in Section 6.2. That's at least what my running code does, but that's the only implementation with which I'm familiar. Section 2.7.3 and 2.7.4 and 2.7.5 similarly need to define the ptype > and properties that appear for iprev and SMTP AUTH and VBR and ATPS > and ADSP. Again, I haven't seen any of those and I don't know what > the running code does. > Same answer as above. The registry contains the specific method/ptype/property combinations that have been registered and what they mean. Many of them were first created by the IANA Considerations section of RFC5451, but they don't have a specific bit of prose dedicated to them beyond that. They seemed pretty straightforward for the last two versions to get consensus; what's changed? -MSK --001a11c381ce30ed9e050fc40de5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sun, Feb 22, 2015 at 9:27 PM, John Levine <johnl@taugh.c= om> wrote:
Either I'm going blind, or this d= raft doesn't address the issues in
errata 4201 which was the main reason we're doing this revision.=C2=A0 = It
needs to define the ptypes and properties for each result type.

My understanding of the erratum is that the defini= tion of "header" as a ptype is that the property will then contai= n a header field name, while "d" (which is what DKIM uses to repo= rt the signing domain) is not a known header field name.=C2=A0 I think that= 's addressed by what I just proposed to Stephane.
=C2=A0
Section 2.7.1 (or some place) needs to say that for DKIM results, the
ptype is "header" and the property for each header is the name of=
fields in the DKIM signature header with the values are the value of
the field.

That's in 2.3 now, and I= proposed splitting it off to 2.8.1, which aligns it with your suggestion.<= br>=C2=A0
Section 2.7.2 needs to say that for SPF results, the ptype is "spf&quo= t;,
the properties are helo and mailfrom, with the values being the
arguments to those commands, with the mailfrom value just being the
address, not any extra keywords.=C2=A0 For Sender-ID, I suppose the ptype is sender-id and the properties are the PRA or something, but I've
never seen a Sender-ID A-R header so I'm not sure.

The ptype is "header", the property is whatever h= eader field the PRA was pulled from, and the value is the PRA.=C2=A0 That&#= 39;s shown in the registry, which was created by RFC5451 in Section 6.2.=C2= =A0 That's at least what my running code does, but that's the only = implementation with which I'm familiar.

Section 2.7.3 and 2.7.4 and 2.7.5 similarly need to define the ptype
and properties that appear for iprev and SMTP AUTH and VBR and ATPS
and ADSP.=C2=A0 Again, I haven't seen any of those and I don't know= what
the running code does.

Same answer as a= bove.=C2=A0 The registry contains the specific method/ptype/property combin= ations that have been registered and what they mean.=C2=A0 Many of them wer= e first created by the IANA Considerations section of RFC5451, but they don= 't have a specific bit of prose dedicated to them beyond that.=C2=A0 Th= ey seemed pretty straightforward for the last two versions to get consensus= ; what's changed?

-MSK
--001a11c381ce30ed9e050fc40de5-- From nobody Mon Feb 23 08:50: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 3E4BA1A1BED for ; Mon, 23 Feb 2015 08:50:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.163 X-Spam-Level: * X-Spam-Status: No, score=1.163 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, MANGLED_TOOL=2.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 G1ktjuge2FZf for ; Mon, 23 Feb 2015 08:50:53 -0800 (PST) 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 2E5051A1BE3 for ; Mon, 23 Feb 2015 08:50:47 -0800 (PST) Received: (qmail 15934 invoked from network); 23 Feb 2015 16:50:46 -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=3e3d.54eb5a66.k1502; bh=cnnOdCdHxLhrGlbGwyLDl9qWNZ7OIV4GSw2HQz6QGq8=; b=t3O0s0n02JePZp9CannAOZTPzowX4+pDzz0FQJGMgd4IGHDUqX1TFC0/A4/z6uLcLa3g9zLKCdMbHmw2iHZGW4p9N6A73XDJ/mQzhHPI79JG6fYuWJrVZskSy+dcwwy21oQ8+rfvOwfwPewKrn4AwL0LZQBvXQ7ZPIjDrXVSHNe+wzajVPd8HII3Ey81ggS+DJeREe0S2TZJNj4Qt7sOW1e3y5APd2hRJ0V0QXHQ3PfsayJLHnQcaO11e3SexpEF 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=3e3d.54eb5a66.k1502; bh=cnnOdCdHxLhrGlbGwyLDl9qWNZ7OIV4GSw2HQz6QGq8=; b=BCykQc6egfzoGjI8QV32HKtHLbbPqwCad8iFRutihVmiivnxVLPYEPTEkRQA7j26qdCm9cVuNBlq9xipkCKwcSwVjH5LcKvRP68jegLdrt59Q5UBEzOmdJQ62MgSgBx8gCLaPw2e0SPmaVoa0DcXY272P5zMX1OyriOZxiIbM3Xeh9RfL5WXCvPAkuxEng7/f7FmGtKuxNTO98BiCXnQRhQH1pLwa8rXVcMzvG0rPbkkB26BnkSrBydA9ItjG/o0 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 Feb 2015 16:50:45 -0000 Date: 23 Feb 2015 11:50:45 -0500 Message-ID: From: "John R Levine" To: "Murray S. Kucherawy" In-Reply-To: References: <20150223024046.57508.qmail@ary.lan> 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: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc7001bis-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: Mon, 23 Feb 2015 16:50:54 -0000 > RFC5451 created entries for protocols that existed prior to its existence. > The definition of "senderid" and the PRA appear in RFC4406. So the methods > registry's "sender-id" entry points to RFC4406. Oh, right, there they are. I was confused (and I don't think I'm the only one) because 7001 obsoletes 5451, but the IANA considerations section in 7001 copies the definition text but not the initial values. It was fine not to copy them since they didn't change, but it feels like a cruel joke not to remind people that 7001 is missing the good bits. (I'm happy to skip the theological issues about whether one RFC truly obsoletes another if you can't implement the new one without also reading the old one.) > It sounds like you want to add a column to the registry that points back to > the RFC that added each entry. Is that the case? That would certainly help. Or in the "defined" column in the registry, change it to RFC5451 for all the methods that are actually defined there and nowhere else. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Mon Feb 23 09:46: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 81C961A1EF9 for ; Mon, 23 Feb 2015 09:46:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.197 X-Spam-Level: ** X-Spam-Status: No, score=2.197 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 WTdOoBR6BGE2 for ; Mon, 23 Feb 2015 09:46:43 -0800 (PST) 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 8A5AB1A1F20 for ; Mon, 23 Feb 2015 09:46:11 -0800 (PST) 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 A8C10C40485 for ; Mon, 23 Feb 2015 11:46:10 -0600 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=201409; t=1424713570; bh=TIGBN5QWN2XBa/zhQelkNfWya2xvdS0yfgoVIlIvXtA=; h=From:To:Subject:Date:In-Reply-To:References:From; b=BYdnlt81YxFDzjxEU6adm3N5Lw1yn4tpFxLyyUmEZfTPL91WfougiBTnPeO7jcF/8 fUQmd3NM/YZ3OCQCxmfGP/y1ThuiOKEOuUIF1bHepX8RaiAkMz2IE8/mHobn3bumxL lhqwEPz8GgnIlAMX2vjGf/TdzukDCku5DOjjDcKo= From: Scott Kitterman To: apps-discuss@ietf.org Date: Mon, 23 Feb 2015 12:46:10 -0500 Message-ID: <4468700.rA7HXESEbV@kitterma-e6430> User-Agent: KMail/4.13.3 (Linux/3.13.0-45-generic; KDE/4.13.3; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc7001bis-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: Mon, 23 Feb 2015 17:46:44 -0000 On Monday, February 23, 2015 11:50:45 AM John R Levine wrote: > > RFC5451 created entries for protocols that existed prior to its existence. > > The definition of "senderid" and the PRA appear in RFC4406. So the > > methods > > registry's "sender-id" entry points to RFC4406. > > Oh, right, there they are. I was confused (and I don't think I'm the only > one) because 7001 obsoletes 5451, but the IANA considerations section in > 7001 copies the definition text but not the initial values. It was fine > not to copy them since they didn't change, but it feels like a cruel joke > not to remind people that 7001 is missing the good bits. (I'm happy to > skip the theological issues about whether one RFC truly obsoletes another > if you can't implement the new one without also reading the old one.) > > > It sounds like you want to add a column to the registry that points back > > to > > the RFC that added each entry. Is that the case? > > That would certainly help. Or in the "defined" column in the registry, > change it to RFC5451 for all the methods that are actually defined there > and nowhere else. RFC 5451 doesn't say much more than is in the registry. I don't think you actually need to read 5451. You need to read 7001/7001bis and the registry. I thought the changes msk made in response to my comments made that clear. If $CURRENTRFC + registry is enough for implementers, then I think it's adequately specified. Since the standard for addition to the registry is expert review, I don't believe there's a guarantee that every item in the registry will have a companion RFC. Scott K From nobody Mon Feb 23 10:02: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 4D82C1A1DE1 for ; Mon, 23 Feb 2015 10:02:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 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, MANGLED_TOOL=2.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 yfOIObS6oAYO for ; Mon, 23 Feb 2015 10:02:05 -0800 (PST) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::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 393821A1EB7 for ; Mon, 23 Feb 2015 10:01:59 -0800 (PST) Received: by mail-wi0-f177.google.com with SMTP id bs8so19519640wib.4 for ; Mon, 23 Feb 2015 10:01:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/plTSQrwb55e5x7cPXBpsufc37mQphs6Zf+5XZvCRO0=; b=sFHDYpKBLEipsKWFKDCpWPaCsQnvwUP2+9hoNjem9Ep9aRWFQro87reb4W+Q+8tr++ 8NwF6hiFGMyk57f+FjpXE1yg3dCBPMQae2x8ps+pibtmt9DVjyDcPd+dSCmjqbPtZWpo lMSS+MvJcnjS8CdATjt25uGGV7SWzHOqMXL9J6E6ovHhyIG5fUEhOlOZo38nl0YFQX0E rvjUZXn0m3aUlv/G4Xs+2vQQ5ydNsb67FcS5Gdx0yeiskn3hQXeM6qHBrZbISW4hDVbd yjAdfOhnFZn/lXxJtrlf9jF09i7yjYSh+rQrcw9XIWfKc4Oh1yTWPLmnuuS5eLr4IGnM ox7w== MIME-Version: 1.0 X-Received: by 10.194.185.68 with SMTP id fa4mr24017971wjc.111.1424714517982; Mon, 23 Feb 2015 10:01:57 -0800 (PST) Received: by 10.27.179.146 with HTTP; Mon, 23 Feb 2015 10:01:57 -0800 (PST) In-Reply-To: References: <20150223024046.57508.qmail@ary.lan> Date: Mon, 23 Feb 2015 13:01:57 -0500 Message-ID: From: "Murray S. Kucherawy" To: John R Levine Content-Type: multipart/alternative; boundary=047d7bacb11ec032b1050fc532d0 Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc7001bis-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: Mon, 23 Feb 2015 18:02:06 -0000 --047d7bacb11ec032b1050fc532d0 Content-Type: text/plain; charset=UTF-8 On Mon, Feb 23, 2015 at 11:50 AM, John R Levine wrote: > RFC5451 created entries for protocols that existed prior to its existence. >> The definition of "senderid" and the PRA appear in RFC4406. So the >> methods >> registry's "sender-id" entry points to RFC4406. >> > > Oh, right, there they are. I was confused (and I don't think I'm the only > one) because 7001 obsoletes 5451, but the IANA considerations section in > 7001 copies the definition text but not the initial values. It was fine > not to copy them since they didn't change, but it feels like a cruel joke > not to remind people that 7001 is missing the good bits. (I'm happy to > skip the theological issues about whether one RFC truly obsoletes another > if you can't implement the new one without also reading the old one.) > I think the goal is that 7001/7001bis plus the registry is complete. As Scott correctly notes, we've lowered the bar to Expert Review, so the registry entries thus created do need to be self-sufficient as much as possible. -MSK --047d7bacb11ec032b1050fc532d0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Feb 23, 2015 at 11:50 AM, John R Levine <johnl@tau= gh.com> wrote:
RFC5451 created entries for protocols that existed prior to its existence.<= br> The definition of "senderid" and the PRA appear in RFC4406.=C2=A0= So the methods
registry's "sender-id" entry points to RFC4406.

 Oh, right, there they are.=C2=A0 I was confused (and I don't think I= 9;m the only one) because 7001 obsoletes 5451, but the IANA considerations = section in 7001 copies the definition text but not the initial values.=C2= =A0 It was fine not to copy them since they didn't change, but it feels= like a cruel joke not to remind people that 7001 is missing the good bits.= =C2=A0 (I'm happy to skip the theological issues about whether one RFC = truly obsoletes another if you can't implement the new one without also= reading the old one.)

I think the goal is that 7001/7001bis plus the registry is complete= .=C2=A0 As Scott correctly notes, we've lowered the bar to Expert Revie= w, so the registry entries thus created do need to be self-sufficient as mu= ch as possible.

-MSK
--047d7bacb11ec032b1050fc532d0-- From nobody Mon Feb 23 11:02: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 932FD1A6EDA for ; Mon, 23 Feb 2015 11:02:56 -0800 (PST) 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 DaYrmkrmMlll for ; Mon, 23 Feb 2015 11:02:50 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0798.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::798]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 855A51A6EDB for ; Mon, 23 Feb 2015 11:02:40 -0800 (PST) Received: from pc6 (81.151.167.59) by DBXPR07MB064.eurprd07.prod.outlook.com (10.242.147.24) with Microsoft SMTP Server (TLS) id 15.1.93.16; Mon, 23 Feb 2015 19:02:20 +0000 Message-ID: <03c401d04f9a$faa639a0$4001a8c0@gateway.2wire.net> From: t.petch To: "Murray S. Kucherawy" , John R Levine References: <20150223024046.57508.qmail@ary.lan> Date: Mon, 23 Feb 2015 19:00:19 +0000 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.167.59] X-ClientProxiedBy: DB3PR05CA0034.eurprd05.prod.outlook.com (25.160.41.162) To DBXPR07MB064.eurprd07.prod.outlook.com (10.242.147.24) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB064; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005003); SRVR:DBXPR07MB064; X-Forefront-PRVS: 0496DF6962 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(189002)(377454003)(13464003)(24454002)(199003)(50226001)(77096005)(77156002)(97736003)(42186005)(19580395003)(14496001)(101416001)(62966003)(19580405001)(92566002)(1456003)(44736004)(68736005)(106356001)(40100003)(230783001)(84392001)(116806002)(5820100001)(66066001)(81816999)(122386002)(64706001)(93886004)(44716002)(86362001)(105586002)(87976001)(23676002)(61296003)(62236002)(33646002)(46102003)(81686999)(76176999)(47776003)(50986999)(50466002)(1556002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DBXPR07MB064; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB064; X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Feb 2015 19:02:20.4926 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR07MB064 Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc7001bis-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: Mon, 23 Feb 2015 19:02:56 -0000 ---- Original Message ----- From: "Murray S. Kucherawy" To: "John R Levine" Cc: "IETF Apps Discuss" Sent: Monday, February 23, 2015 6:01 PM > On Mon, Feb 23, 2015 at 11:50 AM, John R Levine wrote: > > > RFC5451 created entries for protocols that existed prior to its existence. > >> The definition of "senderid" and the PRA appear in RFC4406. So the > >> methods > >> registry's "sender-id" entry points to RFC4406. > > > > Oh, right, there they are. I was confused (and I don't think I'm the only > > one) because 7001 obsoletes 5451, but the IANA considerations section in > > 7001 copies the definition text but not the initial values. It was fine > > not to copy them since they didn't change, but it feels like a cruel joke > > not to remind people that 7001 is missing the good bits. (I'm happy to > > skip the theological issues about whether one RFC truly obsoletes another > > if you can't implement the new one without also reading the old one.) > > > > I think the goal is that 7001/7001bis plus the registry is complete. As > Scott correctly notes, we've lowered the bar to Expert Review, so the > registry entries thus created do need to be self-sufficient as much as > possible. When I go to the Methods Registry in IANA and see domainkeys [RFC4870] header sender-id [RFC4406] header I have an expectation that those RFC will have an IANA Considerations that tells me what I need to know, or points me to a section in the RFC (or another RFC) that does; those RFC have no IANA Considerations at all. When I go to the Methods Registry in IANA and see auth [RFC4954] smtp auth smime [RFC5751] body smime-part spf [RFC4408] smtp helo I have an expectation that those RFC will have an IANA Considerations that tells me what I need to know, or points me to a section in the RFC (or another RFC) that does; those RFC have IANA Considerations but make no mention of Authentication Methods - again I am left stranded. What RFC5451 failed to do - and I note that the IANA Methods registry now contains no mention of this RFC - was to identify itself to IANA as the point of contact for all those entries, and then RFC5451 should have contained a further reference to where more detail could be found; and by more detail I mean the section in the RFC, not just the whole RFC. This is, after all, what almost all IANA Considerations that I am familiar do, they tell me which section, e.g. 2.3.6.2, of which RFC to go to for more detail. Reading this with a naive eye, which I more or less have, then I think it too hard to follow. (Try working out what the name of header field used by PRA is from RFC4406). Self-sufficient is not the word that comes to mind. Tom Petch > -MSK > ------------------------------------------------------------------------ -------- > From nobody Mon Feb 23 14:22: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 4F56D1A0143 for ; Mon, 23 Feb 2015 14:22:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.963 X-Spam-Level: *** X-Spam-Status: No, score=3.963 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, MANGLED_TOOL=2.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 yG6WHN9xATMH for ; Mon, 23 Feb 2015 14:22:31 -0800 (PST) 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 387961A0018 for ; Mon, 23 Feb 2015 14:22:31 -0800 (PST) Received: (qmail 66846 invoked from network); 23 Feb 2015 22:22:29 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 23 Feb 2015 22:22:29 -0000 Date: 23 Feb 2015 22:22:07 -0000 Message-ID: <20150223222207.61207.qmail@ary.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc7001bis-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: Mon, 23 Feb 2015 22:22:32 -0000 >I think the goal is that 7001/7001bis plus the registry is complete. The registries are, as I understand it, supposed to be collections of information from other places, with references to the source where you can find the background, more details, and so forth. If the registry is corrected to point to 5451 for the entries that are defined there, and the 2.7.x parts of 7001bis say where to look for the definitions of the properties and values, I'd be happy. I realize that the registry is likely to be updated later to add new entries, but I doubt that any of the stuff for the existing methods will change. R's, John From nobody Mon Feb 23 16:18: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 137A41A1AFB for ; Mon, 23 Feb 2015 16:18:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 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, MANGLED_TOOL=2.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 YNniDTuaMozd for ; Mon, 23 Feb 2015 16:18:55 -0800 (PST) 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 91ED31A1A2C for ; Mon, 23 Feb 2015 16:18:52 -0800 (PST) Received: by wghn12 with SMTP id n12so2082571wgh.1 for ; Mon, 23 Feb 2015 16:18:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iHfhYCYHfNz/sFJIT81V5dKWPeql5h5XMZ5snNl7Mow=; b=ASncWQQSoXahYxD5YyShsE9P+4YVsIYUj4f6XUYhdI3QuiARHSAkNVdgGFhgQvzybT 7yIkMldOLyN2LFJCEMXodfwdIfHonMLl/yiG8+KzB+nz7fAj+rWbwqqi9J07302HrYtX i6/xukUx7aBIeoJLm5HhN9LCBP/0zy8sGl2c/dKdFVy7RRy9VZA3M5LBOlUbRinMpJiL yYGi6uqGU83mMqLnfWbtaHxbTLezzXNIfjtHWM+MgKcpJAttNF8TzLq0b7fVHebXYbqn Jdjjc30Te4xuZaQQrCGLrFZHgYF8bGk3iAqllD1iW0LVkH3qJt5ulbP6+URRxzJtitZt uiSQ== MIME-Version: 1.0 X-Received: by 10.194.185.9 with SMTP id ey9mr27712699wjc.135.1424737131382; Mon, 23 Feb 2015 16:18:51 -0800 (PST) Received: by 10.27.179.146 with HTTP; Mon, 23 Feb 2015 16:18:51 -0800 (PST) In-Reply-To: <20150223222207.61207.qmail@ary.lan> References: <20150223222207.61207.qmail@ary.lan> Date: Mon, 23 Feb 2015 19:18:51 -0500 Message-ID: From: "Murray S. Kucherawy" To: John Levine Content-Type: multipart/alternative; boundary=047d7bd6adce9d4cc9050fca76d3 Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc7001bis-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, 24 Feb 2015 00:18:56 -0000 --047d7bd6adce9d4cc9050fca76d3 Content-Type: text/plain; charset=UTF-8 On Mon, Feb 23, 2015 at 5:22 PM, John Levine wrote: > >I think the goal is that 7001/7001bis plus the registry is complete. > > The registries are, as I understand it, supposed to be collections of > information from other places, with references to the source where you > can find the background, more details, and so forth. > > If the registry is corrected to point to 5451 for the entries that are > defined there, and the 2.7.x parts of 7001bis say where to look for > the definitions of the properties and values, I'd be happy. I realize > that the registry is likely to be updated later to add new entries, > but I doubt that any of the stuff for the existing methods will > change. > If something gets added down the line someplace without an RFC, what would we reference? We're at Expert Review, not Specification Required. Do we want to do something that is in effect "Specification Optional"? It seems like that would satisfy what you and Tom are saying. -MSK --047d7bd6adce9d4cc9050fca76d3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Feb 23, 2015 at 5:22 PM, John Levine <johnl@taugh.c= om> wrote:
>I think the goal= is that 7001/7001bis plus the registry is complete.

The registries are, as I understand it, supposed to be collections o= f
information from other places, with references to the source where you
can find the background, more details, and so forth.

If the registry is corrected to point to 5451 for the entries that are
defined there, and the 2.7.x parts of 7001bis say where to look for
the definitions of the properties and values, I'd be happy.=C2=A0 I rea= lize
that the registry is likely to be updated later to add new entries,
but I doubt that any of the stuff for the existing methods will
change.

If something gets added down th= e line someplace without an RFC, what would we reference?=C2=A0 We're a= t Expert Review, not Specification Required.

Do we want t= o do something that is in effect "Specification Optional"?=C2=A0 = It seems like that would satisfy what you and Tom are saying.

=
-MSK
--047d7bd6adce9d4cc9050fca76d3-- From nobody Mon Feb 23 18:30: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 C297A1A0181 for ; Mon, 23 Feb 2015 18:30:34 -0800 (PST) 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 hfQYjWrDK_nO for ; Mon, 23 Feb 2015 18:30:34 -0800 (PST) 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 C7D951A005F for ; Mon, 23 Feb 2015 18:30:33 -0800 (PST) Received: (qmail 4821 invoked from network); 24 Feb 2015 02:30:31 -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=12d4.54ebe247.k1502; bh=L7nYcX5+dlpt87RDlovtE8eu3ztKoIJja0QebEx+8Og=; b=kiyKInpdaJMfHEeNLQluhmbXdDaa4BlMPbMSntAZ8rQkexJAGuBwBrTfjZCs38VvUY4qGbQ+/gAxMOW+yS4Obm7CfDxmF8LePunb8u8zm+ckktL9oY3ZsWppZNUliwRqpD5cnL+w6HOHEoLIQAL377KfqY7QAszrhVGOluuQg+72D6l6wIG5kDTFh/SfmXWSyg+RCHbcuqgBrJKRLa6sVj2JgfZyL2KF7nFoQdOhgHxnjUZLqceY4tyxXfFVNigM 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=12d4.54ebe247.k1502; bh=L7nYcX5+dlpt87RDlovtE8eu3ztKoIJja0QebEx+8Og=; b=mQRUGxttziwoGjEPsZDkRItZW6WiYtZRvByVQzCwHrnuod8sf96YsWxOb5QGmtP3MHJp03NOMdnQGyaYRHbjL7futfZ0TOU4EEgO1WBT03cSHh/Piw3f/zfD1R4ptyjZFIaop9GVDzafYWK2TWEULwREkDQKuzY37iEic0HE7szNqZMemgDyPs22PCMMF9ZroIURJUKEYRL1UP2NeeVbrLiZ1BYZpkjzqBMHwek0sUm7+AEhF9u8tGguegYEoKjW 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; 24 Feb 2015 02:30:31 -0000 Date: 23 Feb 2015 21:30:30 -0500 Message-ID: From: "John R Levine" To: "Murray S. Kucherawy" In-Reply-To: References: <20150223222207.61207.qmail@ary.lan> 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: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc7001bis-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, 24 Feb 2015 02:30:34 -0000 > If something gets added down the line someplace without an RFC, what would > we reference? We're at Expert Review, not Specification Required. Whatever we have that explains what it is. If you look through the registries, you'll find URLs, people's e-mail addresses, and occasional notes that IANA has a copy of the paper spec if you need to look at it. In general, there appear to be two kinds of entries in IANA protocol registries. Some are just place holders to reserve a point in the namespace for private values, but most are intended to tell you how to implement whatever it is so you can interoperate. In this case, I don't see any reason to forbid private place holders, but for all the ones we have now, they're supposed to be public and interoperate so as t.p. and I have been asking, please give us pointers to enough info to implement them. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Tue Feb 24 02:09: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 767521A03AB for ; Tue, 24 Feb 2015 02:09:25 -0800 (PST) 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 9ppPidD4zen7 for ; Tue, 24 Feb 2015 02:09:23 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0721.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::721]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC0E21A0194 for ; Tue, 24 Feb 2015 02:09:22 -0800 (PST) Received: from pc6 (81.151.167.59) by AMSPR07MB051.eurprd07.prod.outlook.com (10.242.81.26) with Microsoft SMTP Server (TLS) id 15.1.93.16; Tue, 24 Feb 2015 09:57:11 +0000 Message-ID: <00eb01d05017$fc2fb800$4001a8c0@gateway.2wire.net> From: t.petch To: "Murray S. Kucherawy" , John Levine References: <20150223222207.61207.qmail@ary.lan> Date: Tue, 24 Feb 2015 09:55:06 +0000 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.167.59] X-ClientProxiedBy: DB4PR03CA0039.eurprd03.prod.outlook.com (25.160.39.177) To AMSPR07MB051.eurprd07.prod.outlook.com (10.242.81.26) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB051; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005004); SRVR:AMSPR07MB051; X-Forefront-PRVS: 04976078F0 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(51444003)(199003)(189002)(24454002)(13464003)(377454003)(81686999)(92566002)(86362001)(33646002)(1556002)(62966003)(19580395003)(47776003)(64706001)(105586002)(66066001)(1456003)(15975445007)(77096005)(77156002)(68736005)(84392001)(19580405001)(23676002)(62236002)(50986999)(230783001)(122386002)(81816999)(44716002)(40100003)(101416001)(87976001)(5820100001)(116806002)(97736003)(61296003)(50226001)(46102003)(42186005)(76176999)(50466002)(14496001)(44736004)(106356001)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AMSPR07MB051; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB051; X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Feb 2015 09:57:11.2372 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB051 Archived-At: Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc7001bis-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, 24 Feb 2015 10:09:25 -0000 ----- Original Message ----- From: "Murray S. Kucherawy" To: "John Levine" Cc: "IETF Apps Discuss" Sent: Tuesday, February 24, 2015 12:18 AM > On Mon, Feb 23, 2015 at 5:22 PM, John Levine wrote: > > > >I think the goal is that 7001/7001bis plus the registry is complete. > > > > The registries are, as I understand it, supposed to be collections of > > information from other places, with references to the source where you > > can find the background, more details, and so forth. > > > > If the registry is corrected to point to 5451 for the entries that are > > defined there, and the 2.7.x parts of 7001bis say where to look for > > the definitions of the properties and values, I'd be happy. I realize > > that the registry is likely to be updated later to add new entries, > > but I doubt that any of the stuff for the existing methods will > > change. > > > > If something gets added down the line someplace without an RFC, what would > we reference? We're at Expert Review, not Specification Required. When Expert Review is set up, then the rules for the review can be specified as indeed RFC7001 does "The designated expert has discretion to request that a publication be referenced if a clear, concise definition of the authentication method cannot be provided such that interoperability is assured." I would have preferred 'stable publication' or some such but think that what we have will do going forward. It is looking back, trying to make sense of e.g. sender-id [RFC4406] header name of header field used by PRA or auth [RFC4954] smtp auth AUTH parameter of the MAIL command where I think that RFC5451 should have had a pointer to itself with either a brief explanation if such could be provided or an onward reference to the applicable section of the other RFC when necessary. So reinstating that part of RFC5451 in rfc7001bis is not a satisfactory solution in my book (and just where in RFC4406 do I find a list of applicable header fields?). RFC7001 has added a layer of confusion IMHO on top of this to which rfc7001bis adds more. Sometimes it is necessary to go back and give a complete explanation rather than deltaing a delta which is a .... and I think that that is where we are now. Tom Petch > > Do we want to do something that is in effect "Specification Optional"? It > seems like that would satisfy what you and Tom are saying. > > -MSK > ------------------------------------------------------------------------ -------- > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From nobody Wed Feb 25 07:30: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 2BB3A1A8837 for ; Wed, 25 Feb 2015 07:30:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, TVD_SPACE_RATIO=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 EYzfyy74Ilp1 for ; Wed, 25 Feb 2015 07:30:47 -0800 (PST) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::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 36EC81A87BD for ; Wed, 25 Feb 2015 07:30:04 -0800 (PST) Received: by ykr200 with SMTP id 200so1158543ykr.12 for ; Wed, 25 Feb 2015 07:30:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=tsLRijYSVlKgsH+emu6cwxCYZHhE8bA3rmfbpEFF8sM=; b=oMQnY1EUeaauXwTHuPGWIh3vRKWCpJfQyb/QHc/8a22b1VTwCt7/Hin83aijheIzdn eeB+62Fpj4khcrkLBluq1Wx2AcWzyOQk2mHl6MEEb2t8dgJgWm8wBaNJZ+Zik07+jrmD APl2uzN5xyh1idv2clhrUqB/XJOrSuJCsGYjpdzpiXM9PJ/weLGy+7HzqX7Y1ZsDeTo0 oefDtYvZCo8M39Txo/xXERuCPeLEzunMWfsa6EWEGNKFV9OEI27Ut0Oaq364RcsQix/I KXU7ORsIjGAti8ppbDpxrfBj8Pd3ELksFfFA6rwMXeV60jLDnK/RzxJXKRuGkaPRR8x2 NhQQ== MIME-Version: 1.0 X-Received: by 10.170.130.86 with SMTP id w83mr2283118ykb.5.1424878203465; Wed, 25 Feb 2015 07:30:03 -0800 (PST) Received: by 10.170.47.70 with HTTP; Wed, 25 Feb 2015 07:30:03 -0800 (PST) Received: by 10.170.47.70 with HTTP; Wed, 25 Feb 2015 07:30:03 -0800 (PST) Date: Wed, 25 Feb 2015 07:30:03 -0800 Message-ID: From: chris jamison To: apps-discuss@ietf.org Content-Type: multipart/alternative; boundary=001a113a67882a7531050feb4fe0 Archived-At: Subject: [apps-discuss] re 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, 25 Feb 2015 15:30:48 -0000 --001a113a67882a7531050feb4fe0 Content-Type: text/plain; charset=UTF-8 verify --001a113a67882a7531050feb4fe0 Content-Type: text/html; charset=UTF-8

verify

--001a113a67882a7531050feb4fe0-- From nobody Thu Feb 26 11:47: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 691591A1BB1; Thu, 26 Feb 2015 11:47:39 -0800 (PST) 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 4IZBTtE7uhrk; Thu, 26 Feb 2015 11:47:38 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E6A9E1A1BBC; Thu, 26 Feb 2015 11:47:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150226194736.7336.99467.idtracker@ietfa.amsl.com> Date: Thu, 26 Feb 2015 11:47:36 -0800 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, 26 Feb 2015 19:47:39 -0000 IESG state changed to Last Call Requested from AD Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-uri-scheme-reg/ From nobody Thu Feb 26 11:47: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 8B8921A1BB8; Thu, 26 Feb 2015 11:47:39 -0800 (PST) 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 691591A1BB1; Thu, 26 Feb 2015 11:47:39 -0800 (PST) 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 4IZBTtE7uhrk; Thu, 26 Feb 2015 11:47:38 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E6A9E1A1BBC; Thu, 26 Feb 2015 11:47:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150226194736.7336.99467.idtracker@ietfa.amsl.com> Date: Thu, 26 Feb 2015 11:47:36 -0800 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, 26 Feb 2015 19:47:39 -0000 IESG state changed to Last Call Requested from AD Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-uri-scheme-reg/ From nobody Thu Feb 26 12:05: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 18C091A70FE; Thu, 26 Feb 2015 12:05:28 -0800 (PST) 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 TGdAtiHs_r6C; Thu, 26 Feb 2015 12:05:26 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F3CD31A1B59; Thu, 26 Feb 2015 12:05:18 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20150226200518.21140.38099.idtracker@ietfa.amsl.com> Date: Thu, 26 Feb 2015 12:05:18 -0800 Archived-At: Cc: apps-discuss@ietf.org 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 Reply-To: ietf@ietf.org List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Feb 2015 20:05:28 -0000 The IESG has received a request from the Applications Area Working Group WG (appsawg) to consider the following document: - 'Guidelines and Registration Procedures for URI Schemes' as Best Current Practice The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-03-12. 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 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 file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-appsawg-uri-scheme-reg/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-appsawg-uri-scheme-reg/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Thu Feb 26 12:05: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 B74A21AC3D9; Thu, 26 Feb 2015 12:05:44 -0800 (PST) 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 wwax1V4zj0TN; Thu, 26 Feb 2015 12:05:38 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A7CBA1AC3D6; Thu, 26 Feb 2015 12:05:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150226200521.21140.44800.idtracker@ietfa.amsl.com> Date: Thu, 26 Feb 2015 12:05:21 -0800 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, 26 Feb 2015 20:05:44 -0000 Last call has been made for draft-ietf-appsawg-uri-scheme-reg and state has been changed to In Last Call ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-uri-scheme-reg/ From nobody Thu Feb 26 12:05:52 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 E91E61AC3D6; Thu, 26 Feb 2015 12:05:44 -0800 (PST) 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 B74A21AC3D9; Thu, 26 Feb 2015 12:05:44 -0800 (PST) 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 wwax1V4zj0TN; Thu, 26 Feb 2015 12:05:38 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A7CBA1AC3D6; Thu, 26 Feb 2015 12:05:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150226200521.21140.44800.idtracker@ietfa.amsl.com> Date: Thu, 26 Feb 2015 12:05:21 -0800 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, 26 Feb 2015 20:05:45 -0000 Last call has been made for draft-ietf-appsawg-uri-scheme-reg and state has been changed to In Last Call ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-uri-scheme-reg/