From mnot@mnot.net Sun Sep 1 16:52:17 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 895EE11E82BD for ; Sun, 1 Sep 2013 16:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.149 X-Spam-Level: X-Spam-Status: No, score=-104.149 tagged_above=-999 required=5 tests=[AWL=-1.550, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32k9Smzg7MUe for ; Sun, 1 Sep 2013 16:52:13 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 4731A11E82BC for ; Sun, 1 Sep 2013 16:52:12 -0700 (PDT) Received: from [192.168.1.64] (unknown [118.209.199.29]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 8851522E1F3; Sun, 1 Sep 2013 19:52:05 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Mark Nottingham In-Reply-To: Date: Mon, 2 Sep 2013 09:52:02 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.1508) Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Call for WG Adoption: draft-nottingham-uri-get-off-my-lawn X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 23:52:17 -0000 Examples would definitely be helpful. I'd be inclined to use fictitious = ones. Cheers, On 30/08/2013, at 10:02 PM, Phillip Hallam-Baker = wrote: >=20 >=20 >=20 > On Thu, Aug 29, 2013 at 2:40 PM, Murray S. Kucherawy = wrote: > There appears to be some good support for processing this through = APPSAWG, so let's make this a formal call for adoption. If there's no = sustained objection in the next couple of weeks, we'll make it a work = item. >=20 > Would anyone like to propose a milestone (month/year for IESG = handoff)? >=20 > -MSK, APPSAWG co-chair >=20 >=20 > I support it but would like to see some more concrete examples of the = offending URIs >=20 > =20 >=20 >=20 > --=20 > Website: http://hallambaker.com/ > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Mark Nottingham http://www.mnot.net/ From glenn.parsons@ericsson.com Mon Sep 2 09:42:00 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2F2C21F9EE5; Mon, 2 Sep 2013 09:42:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ypbUEgOd4Q-r; Mon, 2 Sep 2013 09:41:55 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1EDA621F99FD; Mon, 2 Sep 2013 09:41:55 -0700 (PDT) X-AuditID: c618062d-b7fda8e0000024c6-9e-5224bfd21de1 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 5C.1E.09414.2DFB4225; Mon, 2 Sep 2013 18:41:54 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0328.009; Mon, 2 Sep 2013 12:41:53 -0400 From: Glenn Parsons To: "apps-discuss@ietf.org" , "draft-ietf-tsvwg-sctp-sack-immediately.all@tools.ietf.org" Thread-Topic: AppsDir review of draft-ietf-tsvwg-sctp-sack-immediately Thread-Index: Ac6n+1N1dwe4zct/RgeKDnHS50LLjw== Date: Mon, 2 Sep 2013 16:41:52 +0000 Message-ID: <2BBEF519D867E04EA729626C246A978702EEDBE4@eusaamb101.ericsson.se> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: multipart/alternative; boundary="_000_2BBEF519D867E04EA729626C246A978702EEDBE4eusaamb101erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrALMWRmVeSWpSXmKPExsUyuXRPgu6l/SpBBrfvS1usfrmCzeLP+4XM FjP+TGR2YPZYsuQnk8eXy5/ZApiiuGxSUnMyy1KL9O0SuDJez33MWvBTtGLB8uoGxoNCXYyc HBICJhJLln5khLDFJC7cW8/WxcjFISRwlFHiy/+brBDOMkaJPY9OMoFUsQkYSNy9cpUNxBYR 2MAoMadfCsRmFpCQaPn8jBXEFhZwlLh96DlQDQdQjZtE0/dIiHI9if/dU9lBbBYBFYmjj56y g5TwCvhKrFgANpFRQFZi99nrTBATxSVuPZnPBHGbgMSSPeeZIWxRiZeP/7FC2MoSS57sZ4Go z5d4evoOWJxXQFDi5MwnLBMYhWchGTULSdksJGUQcR2JBbs/sUHY2hLLFr5mhrHPHHjMhCy+ gJF9FSNHaXFqWW66kcEmRmCsHJNg093BuOel5SFGaQ4WJXHeVXpnAoUE0hNLUrNTUwtSi+KL SnNSiw8xMnFwSjUwsvrOXn3rZsRD2fRtc+KOB0/K3720fILqwyfJp/c+qzHdYSJhlvn8hu2J HF6WLflSa9amqN9nYf3cl2HNduSJrzJ/qPqOxxE/71zOOxox9/8D7Qnxef3L+7nMPuT8UPsk ONHE8MhFlbDNkZekrvYsP3ToROwOs1XdAWXvNFa+PvNhu/Z37ps/25RYijMSDbWYi4oTAUBh QtBjAgAA Cc: IESG Subject: [apps-discuss] AppsDir review of draft-ietf-tsvwg-sctp-sack-immediately X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 02 Sep 2013 16:42:00 -0000 --_000_2BBEF519D867E04EA729626C246A978702EEDBE4eusaamb101erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello all, I have been selected as the Applications Area Directorate reviewer for this= draft (for background on appsdir, please see http://trac.tools.ietf.org/ar= ea/app/trac/wiki/ApplicationsAreaDirectorate). Please resolve these comments along with any other Last Call comments you m= ay receive. Please wait for direction from your document shepherd or AD bef= ore posting a new version of the draft. Document: draft-ietf-tsvwg-sctp-sack-immediately-04 Title: SACK-IMMEDIATELY Extension for the Stream Control Transmission Proto= col Reviewer: Glenn Parsons Review Date: September 2nd, 2013 Summary: The draft is ready for publication as a Proposed Standard. Major issues: None Minor Issues: None Nits: None. Cheers, Glenn. --_000_2BBEF519D867E04EA729626C246A978702EEDBE4eusaamb101erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello all,

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

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

Document:  draft-ietf-tsvwg-sctp-sack-immediately-04

Title: SACK-IMMEDIATELY Extension for the Stream Control Transmission Proto= col

Reviewer: Glenn Parsons
Review Date: September 2nd, 2013

Summary: The draft is ready for publication as a Proposed Standard.

Major issues:

None

Minor Issues:

None

Nits:

None.
 
Cheers,
Glenn.
 
 --_000_2BBEF519D867E04EA729626C246A978702EEDBE4eusaamb101erics_-- From doug.mtview@gmail.com Fri Aug 30 16:24:22 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 763CD21E808F; Fri, 30 Aug 2013 16:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9YMcmrxwIow; Fri, 30 Aug 2013 16:24:22 -0700 (PDT) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 0107C21E8082; Fri, 30 Aug 2013 16:24:21 -0700 (PDT) Received: by mail-pd0-f170.google.com with SMTP id x10so2447379pdj.29 for ; Fri, 30 Aug 2013 16:24:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=tXTYvHVqzvg35hizl4RCZ07gMCmiPV19J+oa6MuMOKM=; b=lkavhXKf+oSS87DF8y0oTB3mY4uSOCU/7yDJLdTLmMNHbB5hERoybgK34CUp8HSAKb aZYm8QEPR8X+HQBCfsIKHVVa/RoMN8ztfQ07AeAFsOiVZ+o1dRpHa4cV9PjleVrVDLeD sXtrBXaHmiKiuWIMr/bCLiuGSu6lBMbGU+l8ZJUPXmsmh8SpCOXicL7lu+8KpYe37WmK ztd/A+SYMe4zf1+4I0qkCtXeSK4xexsYh9koAWzwk1WERBCyh3r06sPpp43zhPZPlLLF givhD1AdqOFQnRZPizm8H5MLk+DT5x5fXoWYM9Fy9H2B40Hf0Z7cWft6PxZyGhu/QU56 nVvg== X-Received: by 10.68.228.230 with SMTP id sl6mr12485359pbc.98.1377905061766; Fri, 30 Aug 2013 16:24:21 -0700 (PDT) Received: from [192.168.2.201] (c-24-6-103-174.hsd1.ca.comcast.net. [24.6.103.174]) by mx.google.com with ESMTPSA id tr10sm332391pbc.22.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 30 Aug 2013 16:24:20 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_A1B8A873-E72A-4726-95DC-CB77011E11A6" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Douglas Otis In-Reply-To: <52211BF8.80907@att.com> Date: Fri, 30 Aug 2013 16:24:17 -0700 Message-Id: References: <5220B055.2000704@att.com> <5220E659.1070906@isdg.net> <52211BF8.80907@att.com> To: Tony Hansen X-Mailer: Apple Mail (2.1508) X-Mailman-Approved-At: Wed, 04 Sep 2013 10:33:07 -0700 Cc: draft-ietf-repute-model.all@tools.ietf.org, IETF Discussion , General discussion of application-layer protocols Subject: Re: [apps-discuss] AppsDir review of draft-ietf-repute-model-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 23:24:22 -0000 --Apple-Mail=_A1B8A873-E72A-4726-95DC-CB77011E11A6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear Tony, Use of DKIM offers a very poor authentication example, since this draft = makes the same errors made in RFC5863. It is wrong to suggest the DKIM = protocol permits associating a validated identifier to a message as = stated in the Introduction. This is the same erroneous conflation of a = message fragment with that of a message. In most cases, DKIM does not = adequately protect message integrity as explained in = http://tools.ietf.org/html/draft-otis-dkim-harmful-03. In addition, = DKIM can not authenticate who is accountable for having sent the message = which makes it impossible to safely assign reputation. As such, DKIM = should never be referred to as a message authentication protocol. = StartTLS would represent a much better example.=20 Regards, Douglas Otis= --Apple-Mail=_A1B8A873-E72A-4726-95DC-CB77011E11A6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Dear = Tony,

Use of DKIM offers a very poor authentication = example, since this draft makes the same errors made in RFC5863. =  It is wrong to suggest the DKIM protocol permits = associating a validated identifier to a message as stated in the = Introduction.  This is the same erroneous conflation of a message = fragment with that of a message.  In most cases, DKIM does not = adequately protect message integrity as explained in http://tool= s.ietf.org/html/draft-otis-dkim-harmful-03.  In addition, DKIM = can not authenticate who is accountable for having sent the message = which makes it impossible to safely assign reputation.  As such, = DKIM should never be referred to as a message authentication protocol. =  StartTLS would represent a much better = example. 

Regards,
Douglas = Otis
= --Apple-Mail=_A1B8A873-E72A-4726-95DC-CB77011E11A6-- From doug.mtview@gmail.com Tue Sep 3 12:35:03 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC10121E804E; Tue, 3 Sep 2013 12:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cvAg9BCGNUqC; Tue, 3 Sep 2013 12:35:02 -0700 (PDT) Received: from mail-pb0-x22a.google.com (mail-pb0-x22a.google.com [IPv6:2607:f8b0:400e:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 80BD321E804B; Tue, 3 Sep 2013 12:35:01 -0700 (PDT) Received: by mail-pb0-f42.google.com with SMTP id un15so6429760pbc.29 for ; Tue, 03 Sep 2013 12:35:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=y7TGoKbA/fUxgR+5Mj80ErVmdqhXFsSBQmDXNw3FJWo=; b=JkOZ6IBa2wmQA/+mpOJ3/A6Lt/UwzL/6/QU/445kPwNxMi/6ejrupSXfIf8WqwCL7m xqgAdQbz2z4uB5JykgHbnIjWsrq49gxYSs6PgCfbEsvCLZqkN4zwuPoMrny6cZaN+Dlw W44vb/UIDF2ChtcJOnHH/pk5WKEAqBK+n/kLpuWjOeaRHXD5pSxpVhYeaHGkbPA8uhvI VSoggdNfUevEJsIwsmZUuAL9KuDG8RwQyyhLzqdSTeYWBg326aDPtrtYIJj4dwHkIzRs mzNHxY8AE0yjLLIpZhZaihwrmM5oR2/tSr9H8nMzVNfu8aPN/9vTwT3TNeh1Sy7yzMaS 2wqA== X-Received: by 10.66.156.199 with SMTP id wg7mr33461606pab.81.1378236901190; Tue, 03 Sep 2013 12:35:01 -0700 (PDT) Received: from [192.168.2.249] (c-24-6-103-174.hsd1.ca.comcast.net. [24.6.103.174]) by mx.google.com with ESMTPSA id sb9sm24194653pbb.0.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 03 Sep 2013 12:35:00 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_6A3FA952-0AAB-4194-B1E5-65BFFEBC46FF" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Douglas Otis In-Reply-To: <20130831025054.GC58179@mx1.yitter.info> Date: Tue, 3 Sep 2013 12:34:57 -0700 Message-Id: <1F2E740E-9A0B-4C6B-B5A5-04FDB49AB38F@gmail.com> References: <5220B055.2000704@att.com> <5220E659.1070906@isdg.net> <52211BF8.80907@att.com> <20130830233923.GY56500@mx1.yitter.info> <20130831025054.GC58179@mx1.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1508) X-Mailman-Approved-At: Wed, 04 Sep 2013 10:33:19 -0700 Cc: ietf@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] AppsDir review of draft-ietf-repute-model-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 19:35:03 -0000 --Apple-Mail=_6A3FA952-0AAB-4194-B1E5-65BFFEBC46FF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Aug 30, 2013, at 7:50 PM, Andrew Sullivan = wrote: > Colleagues, and Doug especially, >=20 > The message I sent (below) wasn't intended as a "shut up and go away" > message, but a genuine query. I have grave doubts that TLS is the > right example (to begin with, I think fitting it into the REPUTE > approach, given the existing CA structure, would also be > controversial); but I'm genuinely trying to understand how to make the > document better, & not trying to tell anyone to go away. >=20 > Best, >=20 > A >=20 > On Fri, Aug 30, 2013 at 07:39:24PM -0400, Andrew Sullivan wrote: >> Hi Doug! >>=20 >> On Fri, Aug 30, 2013 at 04:24:17PM -0700, Douglas Otis wrote: >>=20 >>> Use of DKIM offers a very poor authentication example >>=20 >> Thanks for the feedback. I don't recall you having made this point = on >> the repute mailing list. Did you, & I missed it? Dear Andrew, Sorry for the delay. I have been overwhelmed by pressing personal = matters. When the REPUTE list first started, I commented about DKIM's inability = to support fair reputation, and about 1 year ago, and then again a few = months ago IIRC. These comments were ignored with some denouncement = appearing in other venues by various DKIM advocates. This is = understandable since motivation for REPUTE was aimed at establishing = DKIM domain reputations to supplant a lack of adoption of a DKIM = reputation service. Lack of adoption was not because DNS was unable to = return a resource record referenced at a domain managed by a reputation = service. Even during DKIM's inception, issues related to DKIM's replay = feature (to be compatible with SMTP) and its impact on ensuring fair = reputation was discussed. DKIM's validity is not related to intended = recipients nor the entity issuing the message. It seems some expect the = "authenticated" signed DKIM message fragment can act as a proxy for a = message's provenance. Unfortunately, DKIM provides inadequate = protection of the message's integrity as seen by recipients.=20 I'll repeat the information contained in=20 http://tools.ietf.org/html/draft-otis-dkim-harmful-03 DKIM and email in general lack a status indicating whether a message = structure is valid as defined by RFC5322, RFC6152, RFC6532, and RFC6854. = Logically, a valid message structure with respect to singleton header = fields should have been a DKIM requirement for valid signatures. = Without valid message structure, what a recipient sees can be trivially = exploited and abused whenever extending a signed DKIM message fragment = as a proxy for the message's source. The hacks recommended in RFC5863 = section 8.15 were offered as a method to better ensure message = structure, but these are seldom implemented or noted. Both the repute model and RFC5863 erroneously conflate verification of a = DKIM message fragment with that of the entire message. Such conflation = is valid in reference to actual message sources as determined by the IP = address (ignoring BGP spoofing) or via StartTLS with certificates = obtained from trusted CAs or via DANE. XMPP use of StartTLS further = leverages CAs using OCSP as does most of the protection afforded Today's = websites. XMPP represents a scalable model that could apply to SMTP. ATPS (RFC6541) also offers a broken example in how a domain is able to = authorize an unlimited number of third-party service providers. ATPS = is broken because it must be used in conjunction with a non-standard = DKIM signature which defeats its purpose.=20 Getting a domain's reputation wrong can prove costly for those hosting = reputation services. Costs include the handling of complaints, = notification of abuse, and at times extremely expensive legal defenses. = Some have suggested DKIM reputation can become a type of crowd sourcing = as a means to overcome DKIM's limitations, especially since these same = advocates also insist DKIM is not being abused.=20 A myopic view about reputation and what is meant by "Authentication" = will not offer a protocol able to ensure interchange nor will related = statistics offer conclusive evidence. The scale of abuse can be both = massive and unfair. >> Do you have a better example, specifically excluding =85 It would be better to not use examples than to offer broken examples. >>=20 >>> StartTLS would represent a much better example. >>=20 >> =85this, which strikes me as suffering from a different but related = set >> of issues along the lines you're complaining about? Can you describe these concerns? How are these different from most = Internet services. Unlike StartTLS, DKIM is trivially exploited. I confirmed the ease of this exploit when contacted by Larry Seltzer by = using it to achieve both acceptance and inbox placement as a type of = phishing demonstration. What do you think this does to those whose = email address or domain is being exploited? It seems highly unlikely = any reputation will ever affect those providers that must be considered = Too Big to Block. = http://www.zdnet.com/dkim-useless-or-just-disappointing-spam-yahoo-google-= 7000019351/ >> Alternatively, if we recast the description of DKIM to call it >> something else, but still used it as an example of what REPUTE is >> trying to do, would that solve your objection? Using DKIM as a basis for reputation is irresponsible. DKIM does not = support negative reputation. Since DKIM messages can be trivially = exploited in most cases, this makes any positive reputation assertion = highly dangerous. Repute's purpose seems aimed at promoting a very bad practice of not = really caring about actual accountable entities as evidenced by using = DKIM as an example. Regards, Douglas Otis= --Apple-Mail=_6A3FA952-0AAB-4194-B1E5-65BFFEBC46FF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 ajs@anvilwalrusden.com> = wrote:
Colleagues, and Doug especially,

The message I sent = (below) wasn't intended as a "shut up and go away"
message, but a = genuine query.  I have grave doubts that TLS is the
right = example (to begin with, I think fitting it into the REPUTE
approach, = given the existing CA structure, would also be
controversial); but = I'm genuinely trying to understand how to make the
document better, = & not trying to tell anyone to go = away.

Best,

A

On Fri, Aug 30, 2013 at 07:39:24PM = -0400, Andrew Sullivan wrote:
Hi = Doug!

On Fri, Aug 30, 2013 at 04:24:17PM -0700, Douglas Otis = wrote:

Use of DKIM offers a very poor = authentication example

Thanks for the feedback. =  I don't recall you having made this point on
the repute mailing = list.  Did you, & I missed = it?

Dear = Andrew,

Sorry for the delay.  I have been = overwhelmed by pressing personal = matters.

When the REPUTE list first = started, I commented about DKIM's inability to support fair reputation, = and about 1 year ago, and then again a few months ago IIRC.  These = comments were ignored with some denouncement appearing in other venues = by various DKIM advocates.  This is understandable since motivation = for REPUTE was aimed at establishing DKIM domain reputations to supplant = a lack of adoption of a DKIM reputation service.  Lack of adoption = was not because DNS was unable to return a resource record referenced at = a domain managed by a reputation service.  Even during DKIM's = inception, issues related to DKIM's replay feature (to be compatible = with SMTP) and its impact on ensuring fair reputation was = discussed.  DKIM's validity is not related to intended recipients = nor the entity issuing the message.  It seems some expect the = "authenticated" signed DKIM message fragment can act as a proxy for a = message's provenance.  Unfortunately, DKIM provides inadequate = protection of the message's integrity as seen by = recipients. 

I'll repeat the information = contained in 

DK= IM and email in general lack a status indicating whether a message = structure is valid as defined by RFC5322, RFC6152, RFC6532, = and RFC6854.  Logically, a valid message structure with respect to = singleton header fields should have been a DKIM requirement for valid = signatures.  Without valid message structure, what a recipient sees = can be trivially exploited and abused whenever extending a signed DKIM = message fragment as a proxy for the message's source.  The hacks = recommended in RFC5863 section 8.15 were offered as a method to = better ensure message structure, but these are seldom implemented or = noted.

Both the repute model and RFC5863 = erroneously conflate verification of a DKIM message fragment with that = of the entire message.  Such conflation is valid in reference to = actual message sources as determined by the IP address (ignoring BGP = spoofing) or via StartTLS with certificates obtained from trusted CAs or = via DANE.  XMPP use of StartTLS further leverages CAs using OCSP as = does most of the protection afforded Today's websites.  XMPP = represents a scalable model that could apply to = SMTP.

ATPS (RFC6541) also offers a broken = example in how a domain is able to authorize an unlimited number of = third-party service providers.   ATPS is broken because it must be = used in conjunction with a non-standard DKIM signature which defeats its = purpose. 

Getting a domain's reputation = wrong can prove costly for those hosting reputation services. =  Costs include the handling of complaints, notification of abuse, = and at times extremely expensive legal defenses.   Some have = suggested DKIM reputation can become a type of crowd sourcing as a means = to overcome DKIM's limitations, especially since these same advocates = also insist DKIM is not being abused. 

A = myopic view about reputation and what is meant by "Authentication" will = not offer a protocol able to ensure interchange nor will related = statistics offer conclusive evidence.   The scale of abuse can be = both massive and unfair.

Do you have a better example, = specifically excluding = =85

It would be better = to not use examples than to offer broken examples.


StartTLS would represent a much better = example.

=85this, which strikes me as suffering from = a different but related set
of issues along the lines you're = complaining about?

Can = you describe these concerns?  How are these different from most = Internet services.  Unlike StartTLS, DKIM is trivially = exploited.

I confirmed the ease of this exploit = when contacted by Larry Seltzer by using it to achieve both acceptance = and inbox placement as a type of phishing demonstration.  What do = you think this does to those whose email address or domain is being = exploited?  It seems highly unlikely any reputation will ever = affect those providers that must be considered Too Big to = Block.


Alternatively, if we recast the = description of DKIM to call it
something else, but still used it as = an example of what REPUTE is
trying to do, would that solve your = objection?

Using DKIM = as a basis for reputation is irresponsible. DKIM does not support = negative reputation.  Since DKIM messages can be trivially = exploited in most cases, this makes any positive reputation assertion = highly dangerous.

Repute's  purpose seems = aimed at promoting a very bad practice of not really caring about actual = accountable entities as evidenced by using DKIM as an = example.

Regards,
Douglas = Otis
= --Apple-Mail=_6A3FA952-0AAB-4194-B1E5-65BFFEBC46FF-- From hsantos@isdg.net Fri Aug 30 11:37:39 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4B9321F9FF1 for ; Fri, 30 Aug 2013 11:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.448 X-Spam-Level: X-Spam-Status: No, score=-102.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LiRpaxDxxF52 for ; Fri, 30 Aug 2013 11:37:34 -0700 (PDT) Received: from secure.winserver.com (winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 3ABD821F9D45 for ; Fri, 30 Aug 2013 11:37:23 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1993; t=1377887840; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=hjiLyK+ZTqlVEY++eB9T8nQDJqI=; b=CtI7Q3OH5JdK3gw4bfeF YIgAjB7DX5kZjEqWcnj4t6cBEqlDUcGVBMq1aJngzzzIaKW6S8YnmmfJqZg6HVJN vLSjvwpmvg5sGvKTAaKS6f31Y63jh6yDWj5gY5nmoQHuCvbyx+d5xLmzck/CDxpI aDYzR7nD7WJkhpMWmeg5h64= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Fri, 30 Aug 2013 14:37:20 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 55379968.13298.2956; Fri, 30 Aug 2013 14:37:19 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1993; t=1377887515; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=e4Nir9L /yvzPaob3KVbwmpPpeaEodx5+9w8c16hF4bM=; b=mTVCqg1q9/g2fMLiGfvsk3G fz22Gk/Eqwcd1PY5GPXW/i2tILfFEF2Ncs1nXbtaKD75x/c2kCjhI/1Rk7AEM5Ig lwBLkW03IKItcENTO46jKxSqygm2+RuEf/OXguvJhKsuP5YSNy5OQWJnILcOCem9 9iLjz42fYKF1nhu+60jk= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Fri, 30 Aug 2013 14:31:55 -0400 Received: from [192.168.1.74] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3796762596.9.2896; Fri, 30 Aug 2013 14:31:53 -0400 Message-ID: <5220E659.1070906@isdg.net> Date: Fri, 30 Aug 2013 14:37:13 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Tony Hansen References: <5220B055.2000704@att.com> In-Reply-To: <5220B055.2000704@att.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 04 Sep 2013 10:33:35 -0700 Cc: draft-ietf-repute-model.all@tools.ietf.org, IETF Discussion , General discussion of application-layer protocols Subject: Re: [apps-discuss] AppsDir review of draft-ietf-repute-model-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 18:37:40 -0000 On 8/30/2013 10:46 AM, Tony Hansen wrote: > > The document describes a model for reputation services, particularly those being produced by the Repute WG. It follows the recommendations of RFc4101 for describing a protocol model, which requires answers to 1) the problem the protocol is trying to achieve, 2) the meaning of messages transmitted, and 3) important unobvious features of the protocol. This document accomplishes its goals quite well. Hi Tony, As a high potential implementator of this DKIM-REPUTE framework and user of any future REPUTE products based on this DKIM-REPUTE framework, I am somewhat disappointed to find not a single integration consideration for the highly adopted SPF technology. Not a single mentioning of the word or the integrated use of this highly adopted mail transport augmented technology. Any adopter of this framework or its products who are also SPF implementors would need to know at the very least how current protocols are affected and also can affect DKIM-REPUTE product designers. For example, DKIM-REPUTE product designers would need to consider SPF reputons product models. Simple text as follows can resolve the integration consideration with little SPF fanfare the draft obviously tried to avoid: REPUTE protocols based on this framework need to consider reputons based on SMTP level filtering protocols such SPF [RFC4408], IP based filtering [DNSRBL] or others. The design consideration for operations may necessitate disabling or relaxing SMTP level filters in order to enable filtering based on this DKIM-REPUTE model. I am seeing all this as an integrator of all mentioned mail technologies; SPF, SENDERID/SUBMITTER, DKIM, ADSP, VBR. I welcome this REPUTE framework. It should consider the existence of other protocols and integrators need some design tips. Besides, for any provider of a REPUTE service, they will benefit by these integrated considerations as well. Thanks -- HLS From hsantos@isdg.net Fri Aug 30 12:39:30 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18B6011E8113 for ; Fri, 30 Aug 2013 12:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.457 X-Spam-Level: X-Spam-Status: No, score=-102.457 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5BXq8-nMlwU2 for ; Fri, 30 Aug 2013 12:39:24 -0700 (PDT) Received: from mail.santronics.com (ntbbs.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 97C6F11E80FA for ; Fri, 30 Aug 2013 12:39:24 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1667; t=1377891562; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=Z5KjKQPKxIVKf/dSqK7Kt4YwDsc=; b=lcHvRMCz0Q4yFgthaccA x0nmHj6ezwaYySFATfSesAsogW0hdsrsCArac98rG91IkgPBabd/mD4wsW31/QuB iuajnuHvKPaFz6qHx/tERNKmD14vdqFctzmcmaCNj4xYbNEZ4vHD7Hmd/j7/oxyA Apm2LR9V4D4H/3YUyoDsA2o= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Fri, 30 Aug 2013 15:39:22 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 59100888.13298.3728; Fri, 30 Aug 2013 15:39:20 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1667; t=1377891236; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=QL8FPtP 6qZqoSBxQEE57by/Hspo0rYFzyQYD1aGjOvk=; b=BhZaIMsucyl6Is6l4fO5kx0 TQHvnMIYAybop6ok+oi0VIaYtLUfF4IlSUbVArlv8Q1c8Y1LIo7GjRbSahSjXXDo V84M3tRUx4tHAqbRlkAvPjCZm8ZIQXV4l6gvVJihPLmROcf+PlFHCiVhU4vfZiZD CzeVPd/VSzd1KMiyzmiw= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Fri, 30 Aug 2013 15:33:56 -0400 Received: from [192.168.1.74] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3800483987.9.4308; Fri, 30 Aug 2013 15:33:55 -0400 Message-ID: <5220F4E2.7030005@isdg.net> Date: Fri, 30 Aug 2013 15:39:14 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Andrew Sullivan References: <5220B055.2000704@att.com> <5220E659.1070906@isdg.net> <20130830192034.GP56500@mx1.yitter.info> In-Reply-To: <20130830192034.GP56500@mx1.yitter.info> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 04 Sep 2013 10:33:45 -0700 Cc: ietf@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] AppsDir review of draft-ietf-repute-model-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 19:39:30 -0000 Hi Andrew, I think it can be generalized functional description without specifics. Designs based on REPUTE and its users of such products, will need some information. That may come (hopefully) from the REPUTE product designer. I am suggesting to remind such future REPUTE product designers of such considerations. I think it will help the technical marketing of REPUTE products and REPUTE service providers. If a choice has to be made between an SMTP layer filtering protocols and some new REPUTE payload filter, then what choices are those to be considered. Keep in mind I would be a classic target audience new reader and user of this document. I did not participate in the WG. We should not expect the audience of the document to be required to visit archives of the Repute WG to find or extract these very real and practical integration considerations. The document should have these general considerations summarized. Thanks On 8/30/2013 3:20 PM, Andrew Sullivan wrote: > On Fri, Aug 30, 2013 at 02:37:13PM -0400, Hector Santos wrote: >> >> For example, DKIM-REPUTE product designers would need to consider >> SPF reputons product models. Simple text as follows can resolve the >> integration consideration with little SPF fanfare the draft >> obviously tried to avoid: > > Why should the framework document contain details of how various > particular reputation services interact? If you want a discussion of > reputation-service-interaction mechanisms in the draft, that's one > thing. If you want to talk about how SPF and DKIM interact, then I > think this is probably the wrong draft. > > Best, > > A > -- HLS From hsantos@isdg.net Fri Aug 30 13:45:50 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 658F021F9FBE for ; Fri, 30 Aug 2013 13:45:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.995 X-Spam-Level: X-Spam-Status: No, score=-101.995 tagged_above=-999 required=5 tests=[AWL=-0.318, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ph0rKiUbLD+j for ; Fri, 30 Aug 2013 13:45:45 -0700 (PDT) Received: from ftp.catinthebox.net (groups.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 02D9D21F9F51 for ; Fri, 30 Aug 2013 13:45:44 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1084; t=1377895542; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=S+ZE0gfW06CgeXN27JlTze1AXaI=; b=R/B7+CItHZwqRPzUkVAI FufYTEH68M8t+r2sGjT/5RL6Dp620Yha7zdoFg8r/EeTIiWQdeD2Jz4G7JOZMgmj euXqnNkaXJiCKDrIXx3MTMa0rs5OPqdbQb5nh4NOsYoUE3npRyiP2JeKQEPu3J2n n1hHrP113WaMHChrpciqS30= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Fri, 30 Aug 2013 16:45:42 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from hector.wildcatblog.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 63081300.13298.4596; Fri, 30 Aug 2013 16:45:41 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1084; t=1377895217; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=4wxD8WU NFVM5Qitx2NFTABp7Tt57ZDl8AxzQ0UcP+IU=; b=QYAwDeT+3hlTGtgj8sUwdPz k45UdZUZE5BxVtmC9xbx9H1rRixkq6fR6Gijg5v/3Nt4kLuG5ruYHsDN+fw5ONBG SwNkbE+NlA9VWgT81QH359du3pBvTSt0n62MW/+685+rG6+598A2muNyKIQ79JWe GVmYlj9WUhNz+G1zlh9s= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Fri, 30 Aug 2013 16:40:17 -0400 Received: from [192.168.1.74] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 3804465533.9.2216; Fri, 30 Aug 2013 16:40:16 -0400 Message-ID: <52210470.1080905@isdg.net> Date: Fri, 30 Aug 2013 16:45:36 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Andrew Sullivan References: <5220B055.2000704@att.com> <5220E659.1070906@isdg.net> <20130830192034.GP56500@mx1.yitter.info> <5220F4E2.7030005@isdg.net> <20130830200920.GS56500@mx1.yitter.info> In-Reply-To: <20130830200920.GS56500@mx1.yitter.info> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 04 Sep 2013 10:34:05 -0700 Cc: ietf@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] AppsDir review of draft-ietf-repute-model-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2013 20:45:51 -0000 On 8/30/2013 4:09 PM, Andrew Sullivan wrote: > On Fri, Aug 30, 2013 at 03:39:14PM -0400, Hector Santos wrote: > >> archives of the Repute WG to find or extract these very real and >> practical integration considerations. The document should have >> these general considerations summarized. > > But your suggestion was for protocol-specific advice. I don't know > how to write that in a generic way. If you have specific text you > want, I can evaluate. I had the start of one in my original post: REPUTE protocols based on this framework need to consider reputons based on SMTP level filtering protocols such SPF [RFC4408], IP based filtering [DNSRBL] or others. If too specific (but explain why DKIM is mentioned?), then REPUTE protocols based on this framework should consider any reputons based on SMTP level filtering protocols in their designs. with and/or: The design consideration for operations may necessitate disabling or relaxing SMTP level filters in order to enable filtering based on this DKIM-REPUTE model. Thanks -- HLS From martin.thomson@gmail.com Wed Sep 4 10:44:41 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5C8B11E80F6; Wed, 4 Sep 2013 10:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.603 X-Spam-Level: X-Spam-Status: No, score=-2.603 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dMQ9OlF5eIZp; Wed, 4 Sep 2013 10:44:40 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id D420021E8145; Wed, 4 Sep 2013 10:44:39 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id cb5so3934104wib.3 for ; Wed, 04 Sep 2013 10:44:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WN6UBE9GbmwzZK65cDx0+HAH7sCS24b8TmIeIPH0ZQk=; b=OpJn0IYZ1yG1J1E5bX4s94IETH2Rgt0xJ2Xc9SyX61v8AJpidScpFHAikWCFp+A9uR TPCWKGNfhwCa65xq+oc4p9dgk2jWWix/vf/X8vmoMXziVjYL0lPQceGFmfEQAPjpqRQo gSNQqK9RrXU/2VdlDSSFAONN+IPsU3DzHcnIr9TBZ3tp11ACm0qpWMi1tULN722R7X+d ylQ3A1YjCROjcFoWZqz79TlG9SMSCwWLos6zwj3ddlOiJo3R6EHjkEII0oZCP/wl3k5c Pd/mjow9Z4VtVnFe+HfbbCWTXvxFzc4Csw50NfYa6RFptbNLzOKrmgRwKHBJVzRf4Wjj m4Qg== MIME-Version: 1.0 X-Received: by 10.194.235.138 with SMTP id um10mr3501242wjc.30.1378316678943; Wed, 04 Sep 2013 10:44:38 -0700 (PDT) Received: by 10.194.28.39 with HTTP; Wed, 4 Sep 2013 10:44:38 -0700 (PDT) In-Reply-To: <201308190703.r7J73c0h064636@medusa.blackops.org> References: <201308190703.r7J73c0h064636@medusa.blackops.org> Date: Wed, 4 Sep 2013 10:44:38 -0700 Message-ID: From: Martin Thomson To: "Murray S. Kucherawy" Content-Type: text/plain; charset=UTF-8 Cc: draft-ietf-geopriv-res-gw-lis-discovery.all@tools.ietf.org, Apps Discuss , The IESG Subject: Re: [apps-discuss] AppsDir reivew of draft-ietf-geopriv-res-gw-lis-discovery X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 17:44:41 -0000 Thanks Murray, Inline responses, with added proof of the relevant changes in case you get some crazy urge to review changes prior to the next revision coming out. On 19 August 2013 00:03, Murray S. Kucherawy wrote: > I found an issue with the flow of the document going from 4.1 to 4.2. I had > to re-read 4.2 several times to understand what's going on here. Maybe > a quick set of ordered bullets that show the general steps the algorithm > will follow, probably up in Section 4, would help. Excellent point, and a good suggestion that I have ripped off: https://github.com/martinthomson/drafts/commit/d739f1a085d93b9700777b7ea7ed1339e37bd782 > The use of "Device" as (apparently) a proper noun without a definition is > curious. There are some uses of "device" as well, and I don't know how > they're different. It's capitalized in that way intentionally, because that's how RFC 6280 (and it's predecessor) operate, but it's probably worth pointing out specially. (I caught one lowercase mistake, thanks.) https://github.com/martinthomson/drafts/commit/4a1eccec14f435f9139172f2911c43a39c414dcb > In Section 3.1, the sixth paragraph ("Existing residential gateways...") seems > unnecessary given the content of the one right before it. I think that the latter part regarding software update is still relevant. https://github.com/martinthomson/drafts/commit/f429e52094f77e9062d1e1805982873dc958cf96 > In Section 4.2, the SHOULD NOT doesn't seem to be right to me as it doesn't > affect this protocol at all should that advice be ignored. I agree a bunch > of extra unnecessary DNS traffic is avoided if an operator complies, which > is hardly a bad thing, but this specific protocol is unaffected. That's a fair cop, I think that world needs fewer uppercase words and this is a good place to start. https://github.com/martinthomson/drafts/commit/12d69045e6f28bb673bfea2f2b68928982c24e2e > Section 4.2 would really benefit from at least one example. OK https://github.com/martinthomson/drafts/commit/29a4c98deaa1c9f9be66633e7bdfc7fd971318e9 > The second paragraph of Section 4.6 seems redundant to the discussion in > Section 4.1. OK https://github.com/martinthomson/drafts/commit/8863446d6f58b315d9ea5696a31f1e6d55f15df6 > Are the SHOULDs in Section 4.7 meant to describe protocol interoperability > requirements, or capability requirements (a la an Applicability Statement)? Operational requirements that are necessary to ensure protocol interoperability. Since we're describing a protocol, the record provisioning is one end of that protocol. > Sections 4.2 and 4.7 talk about the "upward" walk to find the NAPTR record. > If, say, a v4 operator only puts a record at a /16 node, then it's > guaranteed to get three queries for every Device connecting. It's guaranteed > four in the case of a v6 operator who only puts a record at a /32 node. > I wonder if this is worth mentioning as a tradeoff versus a smaller zone file, > or if it's just plain obvious, or if caching is expected to handle most of > this. I had thought that this was obvious. And yes, I expect that this stuff is going to be highly cacheable. > Shouldn't RFC3424 be Informative? Yep. Fixed. > NITS: https://github.com/martinthomson/drafts/commit/1fc55d3acb3cef23fea892dcd367c51e5916152f > The acronym "UNSAF" has to make at least some security people giggle. I'm sure that JDR is at least a little bit proud of that. From dret@berkeley.edu Fri Sep 6 18:58:39 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EDA621F9D5E for ; Fri, 6 Sep 2013 18:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.449 X-Spam-Level: X-Spam-Status: No, score=-5.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TLXWGNu0VDBK for ; Fri, 6 Sep 2013 18:58:34 -0700 (PDT) Received: from cm04fe.IST.Berkeley.EDU (cm04fe.IST.Berkeley.EDU [169.229.218.145]) by ietfa.amsl.com (Postfix) with ESMTP id 71ADB21F9D31 for ; Fri, 6 Sep 2013 18:58:34 -0700 (PDT) Received: from c-24-6-239-29.hsd1.ca.comcast.net ([24.6.239.29] helo=dretpro.local) by cm04fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1VI7nE-0003Ll-EP; Fri, 06 Sep 2013 18:58:34 -0700 Message-ID: <522A8845.6060709@berkeley.edu> Date: Fri, 06 Sep 2013 18:58:29 -0700 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "apps-discuss@ietf.org application-layer protocols" References: <20130907014129.18614.59207.idtracker@ietfa.amsl.com> In-Reply-To: <20130907014129.18614.59207.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130907014129.18614.59207.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: LDP , REST-Discuss Subject: [apps-discuss] Fwd: New Version Notification for draft-wilde-accept-post-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Sep 2013 01:58:40 -0000 changes from -00 to -01 (http://tools.ietf.org/html/draft-wilde-accept-post-01#section-9.1): o Changed ABNF for header field from RFC 2616 to HTTPbis convention (only specify the header field value grammar). o Added implementations (all from the LDP community for now). o Added open issue for aligning accept-post as defined by the "HTTP Link Hints" draft. -------- Original Message -------- Subject: New Version Notification for draft-wilde-accept-post-01.txt Date: Fri, 06 Sep 2013 18:41:29 -0700 From: internet-drafts@ietf.org A new version of I-D, draft-wilde-accept-post-01.txt has been successfully submitted by John Arwe and posted to the IETF repository. Filename: draft-wilde-accept-post Revision: 01 Title: The Accept-Post HTTP Header Creation date: 2013-09-06 Group: Individual Submission Number of pages: 10 URL: http://www.ietf.org/internet-drafts/draft-wilde-accept-post-01.txt Status: http://datatracker.ietf.org/doc/draft-wilde-accept-post Htmlized: http://tools.ietf.org/html/draft-wilde-accept-post-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-wilde-accept-post-01 Abstract: This specification defines a new HTTP response header field Accept- Post, which indicates server support for specific media types for entity bodies in HTTP POST requests. Note to Readers This draft should be discussed on the apps-discuss mailing list [1]. Online access to all versions and files is available on github [2]. From superuser@gmail.com Sat Sep 7 00:04:43 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27D4B21F9EBE; Sat, 7 Sep 2013 00:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0TKFdD1IkcB3; Sat, 7 Sep 2013 00:04:42 -0700 (PDT) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id EFFD021F9DCF; Sat, 7 Sep 2013 00:04:41 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id t60so3795558wes.28 for ; Sat, 07 Sep 2013 00:04:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nd1NvfHmj3vHBwycf3yrzro8paREXJ3kZHl44T8ytyY=; b=kClkNhs+qVHlPG+AlAWvBlhDP2WPF3cDSVtgox8p1z/aSriC53YouAR40qWe2NRVr2 KdeetE2vFoYKQgvgDz4hOPMPb2hC4bfcaFcKDDqDKiSoyeDb1qzLiz3F9bHYjREjyWpo JbtxlGvwpypqZFKVT2kjPhruAWg8WFrGrVPv4/MleXUhqk6UmJLFXZCOPcjosWO5AT9A I9kl7AGmPkG7AWXUaBJlXR643gloLOXWQzUv3RkOF00ICoV2MTDiQvXQFZofWotwKboU OUKgflSwXOoy50sclcm4SJOOVzyZyMIwHaaG3oqea7mhkVobKJrKkvgmDALW4wXu6arV kkcQ== MIME-Version: 1.0 X-Received: by 10.180.183.51 with SMTP id ej19mr1235099wic.60.1378537480955; Sat, 07 Sep 2013 00:04:40 -0700 (PDT) Received: by 10.180.106.169 with HTTP; Sat, 7 Sep 2013 00:04:40 -0700 (PDT) In-Reply-To: <5220B055.2000704@att.com> References: <5220B055.2000704@att.com> Date: Sat, 7 Sep 2013 00:04:40 -0700 Message-ID: From: "Murray S. Kucherawy" To: Tony Hansen Content-Type: multipart/alternative; boundary=001a11c2409edcad8f04e5c5c442 Cc: draft-ietf-repute-model.all@tools.ietf.org, IETF Discussion , General discussion of application-layer protocols Subject: Re: [apps-discuss] AppsDir review of draft-ietf-repute-model-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Sep 2013 07:04:43 -0000 --001a11c2409edcad8f04e5c5c442 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Tony, thanks for the review. Apologies for the long delay replying. On Fri, Aug 30, 2013 at 7:46 AM, Tony Hansen wrote: > I have been selected as the Applications Area Directorate reviewer for t= his draft (for background on appsdir, please see http://trac.tools.ietf.org= /area/app/trac/wiki/ApplicationsAreaDirectorate). > > Please resolve these comments along with any other Last Call comments you= may receive. Please wait for direction from your document shepherd or AD b= efore posting a new version of the draft. > > > > Document: draft-ietf-repute-model-08 > Title: A Model for Reputation Reporting > > Reviewer: Tony Hansen > Review Date: 2013-08-29 > IESG Telechat Date: 9/12 > IETF Last Call Expires: LC for 07 expired on 2013-08-29, but 08 supersede= d that > > > Summary: > The document is ready for publication. Minor notes follow that can be fix= ed in AUTH48. > > The document describes a model for reputation services, particularly thos= e being produced by the Repute WG. It follows the recommendations of RFc410= 1 for describing a protocol model, which requires answers to 1) the problem= the protocol is trying to achieve, 2) the meaning of messages transmitted,= and 3) important unobvious features of the protocol. This document accompl= ishes its goals quite well. > > > > =3D=3D=3D=3D ORGANIZATIONAL COMMENT =3D=3D=3D=3D > > Section 3 "High-Level Architecture" starts with an extended example of wh= ere a reputation service would fit into an existing service. Finally, more = than a page later, it starts describing the architecture that is supposed t= o be the topic of this section. I suggest that the section be split into tw= o, with the beginning given the heading along the lines of "Example of a Re= putation Service Being Used", and the "High-Level Architecture" heading mov= ed right before the paragraph that starts "This document outlines". Alterna= tively, add subsection titles. > > Seems reasonable. I'll do that in the next version. > > =3D=3D=3D=3D MINOR NITS =3D=3D=3D=3D > > Changes below are marked with >>><<<. > > All applied as well. Thanks again, -MSK --001a11c2409edcad8f04e5c5c442 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Tony, thanks for the review.=A0 Apologies for the long = delay replying.


On Fri, Aug 30, 2013 at 7:46 AM, Tony Hansen <tony@att.com>= wrote:
=20 =20 =20 =20 
I have been selected as the Applications Area Directorate reviewer=
 for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDire=
ctorate).

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



Document:  draft-ietf-repute-model-08
Title: A Model for Reputation Reporting

Reviewer: Tony Hansen
Review Date: 2013-08-29
IESG Telechat Date: 9/12
IETF Last Call Expires: LC for 07 expired on 2013-08-29, but 08 superseded =
that


Summary:
The document is ready for publication. Minor notes follow that can be fixed=
 in AUTH48.

The document describes a model for reputation services, particularly those =
being produced by the Repute WG. It follows the recommendations of RFc4101 =
for describing a protocol model, which requires answers to 1) the problem t=
he protocol is trying to achieve, 2) the meaning of messages transmitted, a=
nd 3) important unobvious features of the protocol. This document accomplis=
hes its goals quite well.



=3D=3D=3D=3D ORGANIZATIONAL COMMENT =3D=3D=3D=3D

Section 3 "High-Level Architecture" starts with an extended examp=
le of where a reputation service would fit into an existing service. Finall=
y, more than a page later, it starts describing the architecture that is su=
pposed to be the topic of this section. I suggest that the section be split=
 into two, with the beginning given the heading along the lines of "Ex=
ample of a Reputation Service Being Used", and the "High-Level Ar=
chitecture" heading moved right before the paragraph that starts "=
;This document outlines". Alternatively, add subsection titles.
Seems reasonable.=A0 I'll do that in the = next version.
=A0
=A0
=3D=3D=3D=3D MINOR NITS =3D=3D=3D=3D

Changes below are marked with >>><<<.

All applied as well.

Thanks again,

<= /div>
-MSK
--001a11c2409edcad8f04e5c5c442-- From superuser@gmail.com Sat Sep 7 00:32:28 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA9DD21F9F84; Sat, 7 Sep 2013 00:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YEG02FZAomEo; Sat, 7 Sep 2013 00:32:27 -0700 (PDT) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id B74BB21F9F5B; Sat, 7 Sep 2013 00:32:26 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id t60so3797125wes.14 for ; Sat, 07 Sep 2013 00:32:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ztznv5yFD/TSm9AbBUqiagsZtfart9R3rpQPG8UyPAo=; b=pQYNlRrHum9FJpD77RFDAA/MbEwd/uk4voQszHNkXYLHnPm/o60BW95rcKyJZyimvu CBDKYEwgaG8oq20Py6ZDF/xyZRmjZxjnUp8GH8Tb09z2c+N9auVmfgvnX1zwurRrUSxm fViH60rTQneZvM8veGyhxghRsuY2+eLsqnhW5eST9AW4eZkCK6YsayD7WbWeiW4WUVKq mpBOurOSCBcTP+naKqD7cBn0GvP7G7dmKW/KjNbw9yrSZHj2b0hGsp9MpNuW1mS1LLrY ZXNb3VXN+zHDDC0vDwnLpIIpUgKyAPtFhqh+41ED9mIgo4j8O5Jp+2jC5A5Nytf0HhBM 8VjA== MIME-Version: 1.0 X-Received: by 10.180.211.19 with SMTP id my19mr1277018wic.19.1378539145974; Sat, 07 Sep 2013 00:32:25 -0700 (PDT) Received: by 10.180.106.169 with HTTP; Sat, 7 Sep 2013 00:32:25 -0700 (PDT) In-Reply-To: <1F2E740E-9A0B-4C6B-B5A5-04FDB49AB38F@gmail.com> References: <5220B055.2000704@att.com> <5220E659.1070906@isdg.net> <52211BF8.80907@att.com> <20130830233923.GY56500@mx1.yitter.info> <20130831025054.GC58179@mx1.yitter.info> <1F2E740E-9A0B-4C6B-B5A5-04FDB49AB38F@gmail.com> Date: Sat, 7 Sep 2013 00:32:25 -0700 Message-ID: From: "Murray S. Kucherawy" To: Douglas Otis Content-Type: multipart/alternative; boundary=001a11c385561ad88b04e5c6287f Cc: IETF Apps Discuss , ietf Subject: Re: [apps-discuss] AppsDir review of draft-ietf-repute-model-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Sep 2013 07:32:29 -0000 --001a11c385561ad88b04e5c6287f Content-Type: text/plain; charset=ISO-8859-1 On Tue, Sep 3, 2013 at 12:34 PM, Douglas Otis wrote: > > When the REPUTE list first started, I commented about DKIM's inability to > support fair reputation, and about 1 year ago, and then again a few months > ago IIRC. These comments were ignored with some denouncement appearing in > other venues by various DKIM advocates. This is understandable since > motivation for REPUTE was aimed at establishing DKIM domain reputations to > supplant a lack of adoption of a DKIM reputation service. Lack of adoption > was not because DNS was unable to return a resource record referenced at a > domain managed by a reputation service. Even during DKIM's inception, > issues related to DKIM's replay feature (to be compatible with SMTP) and > its impact on ensuring fair reputation was discussed. DKIM's validity is > not related to intended recipients nor the entity issuing the message. It > seems some expect the "authenticated" signed DKIM message fragment can act > as a proxy for a message's provenance. Unfortunately, DKIM provides > inadequate protection of the message's integrity as seen by recipients. > [...] The document under review here provides an architecture for including reputation evaluation of an identifier, and describes how one would do so in an existing system such as a mail flow. Since there are several existing systems that offer some kind of reputation service predicated on DKIM and others, DKIM seems a perfectly reasonable example to include. Some very large operators are on record as stating that they find such systems useful despite these persistent claims about how insecure DKIM is. At a very basic level, I don't think REPUTE is the right place to rehash the discussion about whether DKIM has particular security issues. I would refer concerned participants to the DKIM WG mailing list archives for a record of the protracted debate on that topic, and to the IESG appeals page for a recent formal revisiting of the issues Doug is identifying here. Both the repute model and RFC5863 erroneously conflate verification of a > DKIM message fragment with that of the entire message. Such conflation is > valid in reference to actual message sources as determined by the IP > address (ignoring BGP spoofing) or via StartTLS with certificates obtained > from trusted CAs or via DANE. XMPP use of StartTLS further leverages CAs > using OCSP as does most of the protection afforded Today's websites. XMPP > represents a scalable model that could apply to SMTP. > If RFC5863 needs correction or update, then that work can be considered, but it's out of scope for the document under discussion here or the WG that produced it. The REPUTE model does not make any statements about the "entire message" issue being raised here. Moreover, the Security Considerations section of the REPUTE email identifiers document does tell implementers to be aware of the limitations of the protocols on which they are building services, but again, I don't think REPUTE documents are the right place to re-tackle those issues. > Getting a domain's reputation wrong can prove costly for those hosting > reputation services. Costs include the handling of complaints, > notification of abuse, and at times extremely expensive legal defenses. > Some have suggested DKIM reputation can become a type of crowd sourcing as > a means to overcome DKIM's limitations, especially since these same > advocates also insist DKIM is not being abused. > The first part of that paragraph is discussed in the REPUTE considerations document. Further contributions to that document are welcome since it is still under WG development. > It would be better to not use examples than to offer broken examples. > I think that would do this document rather a disservice, since it's describing how REPUTE works with real-world examples. I understand that you don't agree with the safety of the protocols used in the examples, but I don't agree that removing the examples makes this document a better one. -MSK --001a11c385561ad88b04e5c6287f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Sep 3, 2013 at 12:34 PM, Douglas Otis <doug.m= tview@gmail.com> wrote:

When the REPUTE list first started, I commented about DKIM's inab= ility to support fair reputation, and about 1 year ago, and then again a fe= w months ago IIRC. =A0These comments were ignored with some denouncement ap= pearing in other venues by various DKIM advocates. =A0This is understandabl= e since motivation for REPUTE was aimed at establishing DKIM domain reputat= ions to supplant a lack of adoption of a DKIM reputation service. =A0Lack o= f adoption was not because DNS was unable to return a resource record refer= enced at a domain managed by a reputation service. =A0Even during DKIM'= s inception, issues related to DKIM's replay feature (to be compatible = with SMTP) and its=A0impact on ensuring fair reputation=A0was discussed. = =A0DKIM's validity is not related to intended recipients nor the entity= issuing the message. =A0It seems some expect the "authenticated"= signed DKIM message fragment can act as a proxy for a message's proven= ance. =A0Unfortunately, DKIM provides inadequate protection of the message&= #39;s integrity as seen by recipients.

[...]

The document unde= r review here provides an architecture for including reputation evaluation = of an identifier, and describes how one would do so in an existing system s= uch as a mail flow.=A0 Since there are several existing systems that offer = some kind of reputation service predicated on DKIM and others, DKIM seems a= perfectly reasonable example to include.=A0 Some very large operators are = on record as stating that they find such systems useful despite these persi= stent claims about how insecure DKIM is.

At a very basic level, I don't think REPUTE is the right place to r= ehash the discussion about whether DKIM has particular security issues.=A0 = I would refer concerned participants to the DKIM WG mailing list archives f= or a record of the protracted debate on that topic, and to the IESG appeals= page for a recent formal revisiting of the issues Doug is identifying here= .

Both the repute model and=A0RFC5863 erroneously conflate verifi= cation of a DKIM message fragment with that of the entire message. =A0Such = conflation is valid in reference to actual message sources as determined by= the IP address (ignoring BGP spoofing) or via StartTLS with certificates o= btained from trusted CAs or via DANE. =A0XMPP use of StartTLS further lever= ages CAs using OCSP as does most of the protection afforded Today's web= sites. =A0XMPP represents a scalable model that could apply to SMTP.

If RFC5863 needs correction or= update, then that work can be considered, but it's out of scope for th= e document under discussion here or the WG that produced it.=A0 The REPUTE = model does not make any statements about the "entire message" iss= ue being raised here.=A0 Moreover, the Security Considerations section of t= he REPUTE email identifiers document does tell implementers to be aware of = the limitations of the protocols on which they are building services, but a= gain, I don't think REPUTE documents are the right place to re-tackle t= hose issues.


Getting a domain's reputation wrong can prov= e costly for those hosting reputation services. =A0Costs include the handli= ng of complaints, notification of abuse, and at times extremely expensive l= egal defenses. =A0 Some have suggested DKIM reputation can become a type of= crowd sourcing as a means to overcome DKIM's limitations, especially s= ince these same advocates also insist DKIM is not being abused.=A0

The first part of that paragra= ph is discussed in the REPUTE considerations document.=A0 Further contribut= ions to that document are welcome since it is still under WG development. =A0
It would be better to not use examples than to offer broken examp= les.

I think that would do this document = rather a disservice, since it's describing how REPUTE works with real-w= orld examples.=A0 I understand that you don't agree with the safety of = the protocols used in the examples, but I don't agree that removing the= examples makes this document a better one.

-MSK
--001a11c385561ad88b04e5c6287f-- From cabo@tzi.org Mon Sep 9 09:16:08 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D966021F9A90; Mon, 9 Sep 2013 09:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QwUTvnZgvYsB; Mon, 9 Sep 2013 09:16:03 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 074F111E8109; Mon, 9 Sep 2013 08:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r89Frqbw014457; Mon, 9 Sep 2013 17:53:52 +0200 (CEST) Received: from [192.168.217.105] (p54893FE2.dip0.t-ipconnect.de [84.137.63.226]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 55FBA8E0; Mon, 9 Sep 2013 17:53:52 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann In-Reply-To: <20130909154432.GA22605@amoureux.home> Date: Mon, 9 Sep 2013 17:53:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <81194C29-85CB-4E4A-935A-4503B021DE26@tzi.org> References: <20130716195803.9658.64560.idtracker@ietfa.amsl.com> <20130909154432.GA22605@amoureux.home> To: "Pierre Thierry" X-Mailer: Apple Mail (2.1508) Cc: ietf@ietf.org, apps-discuss@ietf.org Subject: Re: [apps-discuss] High-volume benchmark (was Re: cbor-05) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 16:16:09 -0000 On Sep 9, 2013, at 17:44, "Pierre Thierry" wrote: > Carsten, >=20 > in draft-bormann-cbor-05, you mention that "The format must be > applicable to (=85) high-volume applications." in section 1.1. >=20 > Do you already have a benchmark in place to measure the volume that a > CBOR implementation is able to manage? Do you plan to compare CBOR > implementations to implementations of other similar formats? Hi Pierre, of course, I do have some informal benchmarks for my implementations; = their purpose is to avoid performance regressions when evolving the = code. However, it has been my experience that, unless you make mistakes in = defining the format (e.g., requiring extensive data conversions, = two-pass implementations, or back-patching) the actual performance of a = data format encoder/decoder is largely dependent on system issues, such = as the data model you are using and the memory allocation principles. = So I'm not sure a formal benchmark would help a lot. What kind of application do you have in mind? Maybe I can come up with a = better, more tailored benchmark for that. Gr=FC=DFe, Carsten From pierre@nothos.net Mon Sep 9 09:21:59 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6374421E81F1; Mon, 9 Sep 2013 09:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f7gzcNePIl7y; Mon, 9 Sep 2013 09:21:54 -0700 (PDT) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) by ietfa.amsl.com (Postfix) with ESMTP id C88C921F9D3A; Mon, 9 Sep 2013 08:44:48 -0700 (PDT) Received: from nothos.net (unknown [IPv6:2001:660:2402:14:76de:2bff:fe41:2f1]) (Authenticated sender: pierre@nothos.net) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id B5D191720AC; Mon, 9 Sep 2013 17:44:33 +0200 (CEST) Received: by nothos.net (sSMTP sendmail emulation); Mon, 09 Sep 2013 17:44:33 +0200 From: "Pierre Thierry" Date: Mon, 9 Sep 2013 17:44:33 +0200 To: Carsten Bormann , apps-discuss@ietf.org Message-ID: <20130909154432.GA22605@amoureux.home> References: <20130716195803.9658.64560.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pWyiEgJYm5f9v55/" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: ietf@ietf.org, IETF Apps Discuss Subject: [apps-discuss] High-volume benchmark (was Re: cbor-05) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 16:21:59 -0000 --pWyiEgJYm5f9v55/ Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Carsten, in draft-bormann-cbor-05, you mention that "The format must be applicable to (=E2=80=A6) high-volume applications." in section 1.1. Do you already have a benchmark in place to measure the volume that a CBOR implementation is able to manage? Do you plan to compare CBOR implementations to implementations of other similar formats? Curiously, Pierre Thierry --=20 pierre@nothos.net OpenPGP OxD9D50D8A --pWyiEgJYm5f9v55/ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlIt7OAACgkQxe13INnVDYpSRgCg1aTDlh9SQT8iJPm2+WQavpfz cNQAnR86onSpNPixh/Y8vrcfNjf4m3o4 =muwL -----END PGP SIGNATURE----- --pWyiEgJYm5f9v55/-- From martin.thomson@gmail.com Mon Sep 9 11:42:32 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 373F711E8123 for ; Mon, 9 Sep 2013 11:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.3 X-Spam-Level: X-Spam-Status: No, score=-0.3 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_TOOL=2.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id moiHur4o4j-O for ; Mon, 9 Sep 2013 11:42:31 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 2AAC611E80E6 for ; Mon, 9 Sep 2013 11:42:31 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id b12so3094551wgh.1 for ; Mon, 09 Sep 2013 11:42:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rqvLYbOOTYXO8NFGzW+w4gvpl0rYgEpp21up8q2hXlk=; b=GTN98Eb4ks1R8ftWuQd/o83WNxWuqWTAsJZteRAdHzNZ0SduT4tIH/pKo1C4uNIkfc vihOJ5B8Cy5ir371b0p9Ggi/iIrKJUxyfjWLPpobw/PjIR1Nymq6CH/YARl2nbEzlLFK sVdxalOCzbFt7IGRYRilN6p6ty/7AFArxODNHSmBFbKRs7ch8NVnVHgQOZM9Li9p20xi x7BQhIMJI+L2rojgGCcVfNGlEc3MAC3xyRUC3+bObrG3yvVT0GHfYwuycmi3Lo91mBj9 22avTQTSu2RC93BMz0cXJ6nvr8s98HpnW/AdTD1YyRUrFCBTVvSbqAyJQibIY61KpK8c uCUQ== MIME-Version: 1.0 X-Received: by 10.194.202.230 with SMTP id kl6mr14295963wjc.9.1378752150322; Mon, 09 Sep 2013 11:42:30 -0700 (PDT) Received: by 10.194.28.39 with HTTP; Mon, 9 Sep 2013 11:42:30 -0700 (PDT) In-Reply-To: <522A8845.6060709@berkeley.edu> References: <20130907014129.18614.59207.idtracker@ietfa.amsl.com> <522A8845.6060709@berkeley.edu> Date: Mon, 9 Sep 2013 11:42:30 -0700 Message-ID: From: Martin Thomson To: Erik Wilde Content-Type: text/plain; charset=UTF-8 Cc: "apps-discuss@ietf.org application-layer protocols" Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-wilde-accept-post-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 18:42:32 -0000 Apologies if I missed an earlier discussion, but why is this restricted specifically to POST requests? Is there value in also having Accept-Put (useful if the resource can be retrieved in multiple forms, but only uploaded in a subset of those, such that it is difficult to learn what types are acceptable), as well as Accept-Blah, for any future method that contains a body or any request that might return 415? On 6 September 2013 18:58, Erik Wilde wrote: > changes from -00 to -01 > (http://tools.ietf.org/html/draft-wilde-accept-post-01#section-9.1): > > o Changed ABNF for header field from RFC 2616 to HTTPbis convention > (only specify the header field value grammar). > o Added implementations (all from the LDP community for now). > o Added open issue for aligning accept-post as defined by the "HTTP Link > Hints" draft. > > > -------- Original Message -------- > Subject: New Version Notification for draft-wilde-accept-post-01.txt > Date: Fri, 06 Sep 2013 18:41:29 -0700 > From: internet-drafts@ietf.org > > A new version of I-D, draft-wilde-accept-post-01.txt > has been successfully submitted by John Arwe and posted to the > IETF repository. > > Filename: draft-wilde-accept-post > Revision: 01 > Title: The Accept-Post HTTP Header > Creation date: 2013-09-06 > Group: Individual Submission > Number of pages: 10 > URL: http://www.ietf.org/internet-drafts/draft-wilde-accept-post-01.txt > Status: http://datatracker.ietf.org/doc/draft-wilde-accept-post > Htmlized: http://tools.ietf.org/html/draft-wilde-accept-post-01 > Diff: http://www.ietf.org/rfcdiff?url2=draft-wilde-accept-post-01 > > Abstract: > This specification defines a new HTTP response header field Accept- > Post, which indicates server support for specific media types for > entity bodies in HTTP POST requests. > > Note to Readers > > This draft should be discussed on the apps-discuss mailing list [1]. > Online access to all versions and files is available on github [2]. > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From jasnell@gmail.com Mon Sep 9 11:50:41 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF8911E8123 for ; Mon, 9 Sep 2013 11:50:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.3 X-Spam-Level: ** X-Spam-Status: No, score=2.3 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MANGLED_TOOL=2.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7SO2BPisbBB6 for ; Mon, 9 Sep 2013 11:50:40 -0700 (PDT) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 0A7E911E80F2 for ; Mon, 9 Sep 2013 11:50:39 -0700 (PDT) Received: by mail-ob0-f178.google.com with SMTP id ef5so6351149obb.9 for ; Mon, 09 Sep 2013 11:50:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ki/8dkBfXlhHCsY5Kob8Ii/ZdBswDBwMvTGfeZX4gbY=; b=HyfxQS3UBR6qIZgep9aPhNBFvmnk88Wr2jNu8a0mfgPqax9oM4UL6EPpLYgzNB0Tcf zYPjq8p9S+I9b8BjfSaQmW/vrVySHMVe0yulo86QoKirtDiDsEl3gWomBCi/CBFF/Bvm lqZ2a/8tIT5SZiRV0S9jSVAMT8R1RNuTvQp5p3eJHdMSTX5XCysfdLoejuEdJuMMyVN/ ovsRqQDq79p5Xl6ngbJBrL9ZoWerb+p14my1RlfzTAXyY0qaBjs44Onwa3Id9mb3UIgy 8DmkqjlhHHARUZXYvo+IGrPsdQhZDOdEYZukaPqkDRntr3q0PNqo8OuZTP9ICjN3CsCx QsTg== X-Received: by 10.182.117.195 with SMTP id kg3mr9403881obb.17.1378752639637; Mon, 09 Sep 2013 11:50:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.124.137 with HTTP; Mon, 9 Sep 2013 11:50:19 -0700 (PDT) In-Reply-To: References: <20130907014129.18614.59207.idtracker@ietfa.amsl.com> <522A8845.6060709@berkeley.edu> From: James M Snell Date: Mon, 9 Sep 2013 11:50:19 -0700 Message-ID: To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Cc: "apps-discuss@ietf.org application-layer protocols" Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-wilde-accept-post-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 18:50:41 -0000 An Accept-Put (or Accept-{whatever}) would be useful if and only if there are practical known use cases where we know they'd be used. The two we currently have (Accept-Patch and Accept-Post) have very clear, specific real world use cases that solve immediate non-theoretical needs. If someone eventually finds need for Accept-Put, they can easily draft up a quick I-D that defines it :-) On Mon, Sep 9, 2013 at 11:42 AM, Martin Thomson wrote: > Apologies if I missed an earlier discussion, but why is this > restricted specifically to POST requests? Is there value in also > having Accept-Put (useful if the resource can be retrieved in multiple > forms, but only uploaded in a subset of those, such that it is > difficult to learn what types are acceptable), as well as Accept-Blah, > for any future method that contains a body or any request that might > return 415? > > On 6 September 2013 18:58, Erik Wilde wrote: >> changes from -00 to -01 >> (http://tools.ietf.org/html/draft-wilde-accept-post-01#section-9.1): >> >> o Changed ABNF for header field from RFC 2616 to HTTPbis convention >> (only specify the header field value grammar). >> o Added implementations (all from the LDP community for now). >> o Added open issue for aligning accept-post as defined by the "HTTP Link >> Hints" draft. >> >> >> -------- Original Message -------- >> Subject: New Version Notification for draft-wilde-accept-post-01.txt >> Date: Fri, 06 Sep 2013 18:41:29 -0700 >> From: internet-drafts@ietf.org >> >> A new version of I-D, draft-wilde-accept-post-01.txt >> has been successfully submitted by John Arwe and posted to the >> IETF repository. >> >> Filename: draft-wilde-accept-post >> Revision: 01 >> Title: The Accept-Post HTTP Header >> Creation date: 2013-09-06 >> Group: Individual Submission >> Number of pages: 10 >> URL: http://www.ietf.org/internet-drafts/draft-wilde-accept-post-01.txt >> Status: http://datatracker.ietf.org/doc/draft-wilde-accept-post >> Htmlized: http://tools.ietf.org/html/draft-wilde-accept-post-01 >> Diff: http://www.ietf.org/rfcdiff?url2=draft-wilde-accept-post-01 >> >> Abstract: >> This specification defines a new HTTP response header field Accept- >> Post, which indicates server support for specific media types for >> entity bodies in HTTP POST requests. >> >> Note to Readers >> >> This draft should be discussed on the apps-discuss mailing list [1]. >> Online access to all versions and files is available on github [2]. >> _______________________________________________ >> apps-discuss mailing list >> apps-discuss@ietf.org >> https://www.ietf.org/mailman/listinfo/apps-discuss > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From superuser@gmail.com Mon Sep 9 12:01:23 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61CB321F9D65 for ; Mon, 9 Sep 2013 12:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nj-HnI5B-4Yv for ; Mon, 9 Sep 2013 12:01:19 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id BDF4621E8196 for ; Mon, 9 Sep 2013 12:01:03 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id b12so3110212wgh.5 for ; Mon, 09 Sep 2013 12:01:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=QfmQZDbztdZ/xXPRkYrZI8M+E2EDXmBwOmbzRKzn+TI=; b=YZtv6ZrcZC5CyYHal05SR7NXlUbT/7YbA5VKIQEOuNq4toCUqY1xMgxnBZA6VMLgc3 c6cNNk/n5adSVEWHvoa19wgdYInoRpJWCztkS+QIkc5LqtWyafLUVbR6f0Q1N7yJIctd ugdTtUWAH7lXKzM0EtAuQhVx0pFyTEnXW2T+ncMZumHbfqsriTYlM+M69a/kSNfdzHyl rrCOJ0pVfqAJXIH1Ps9HNTDYeknwZt41OU0F8WD+RJcdV8IIYcmQTXdMUGxVPGR4N5cN ikW9rjNa28LKjqQrjRhPokJWWcm3MclWhCc93K6RWLpmPUKONBHomKTfrIjjc/Q42lH7 gr4Q== MIME-Version: 1.0 X-Received: by 10.180.189.9 with SMTP id ge9mr9645112wic.52.1378753262576; Mon, 09 Sep 2013 12:01:02 -0700 (PDT) Received: by 10.180.106.169 with HTTP; Mon, 9 Sep 2013 12:01:02 -0700 (PDT) Date: Mon, 9 Sep 2013 12:01:02 -0700 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=001a11c3430272eb3c04e5f80251 Subject: [apps-discuss] Call for APPSAWG topics for November meeting X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 19:01:25 -0000 --001a11c3430272eb3c04e5f80251 Content-Type: text/plain; charset=ISO-8859-1 Colleagues, It's that time again. If you would like to make a presentation to APPSAWG or to the APP Area General Meeting when we convene in November, or if you would like to request that someone cover a specific topic, please email appsawg-chairs@tools.ietf.org with your topic and requested time. We need some idea of how long the meeting will be so we can request an appropriate time slot. The deadline for us to request a time slot is only a few weeks away, so please don't leave your requests until the last minute. Thanks! -MSK, APPSAWG co-chair --001a11c3430272eb3c04e5f80251 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Colleagues,

It's that time again.=A0 If yo= u would like to make a presentation to APPSAWG or to the APP Area General M= eeting when we convene in November, or if you would like to request that so= meone cover a specific topic, please email appsawg-chairs@tools.ietf.org with your topic and requ= ested time.=A0 We need some idea of how long the meeting will be so we can = request an appropriate time slot.

The deadline for us to request a time slot is only a few weeks away, so= please don't leave your requests until the last minute.

Thanks!=

-MSK, APPSAWG co-chair
--001a11c3430272eb3c04e5f80251-- From dret@berkeley.edu Mon Sep 9 12:10:53 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84B1121F9FBC for ; Mon, 9 Sep 2013 12:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PQVP1CEBECFQ for ; Mon, 9 Sep 2013 12:10:49 -0700 (PDT) Received: from cm05fe.IST.Berkeley.EDU (cm05fe.IST.Berkeley.EDU [169.229.218.146]) by ietfa.amsl.com (Postfix) with ESMTP id 2623421F9D7A for ; Mon, 9 Sep 2013 12:10:49 -0700 (PDT) Received: from c-24-6-239-29.hsd1.ca.comcast.net ([24.6.239.29] helo=dretpro.local) by cm05fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1VJ6rG-0003SS-It; Mon, 09 Sep 2013 12:10:48 -0700 Message-ID: <522E1D37.1030602@berkeley.edu> Date: Mon, 09 Sep 2013 12:10:47 -0700 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "apps-discuss@ietf.org application-layer protocols" References: <20130907014129.18614.59207.idtracker@ietfa.amsl.com> <522A8845.6060709@berkeley.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-wilde-accept-post-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 19:10:53 -0000 hello. On 2013-09-09 11:50 , James M Snell wrote: > An Accept-Put (or Accept-{whatever}) would be useful if and only if > there are practical known use cases where we know they'd be used. The > two we currently have (Accept-Patch and Accept-Post) have very clear, > specific real world use cases that solve immediate non-theoretical > needs. If someone eventually finds need for Accept-Put, they can > easily draft up a quick I-D that defines it :-) > On Mon, Sep 9, 2013 at 11:42 AM, Martin Thomson > wrote: >> Apologies if I missed an earlier discussion, but why is this >> restricted specifically to POST requests? Is there value in also >> having Accept-Put (useful if the resource can be retrieved in multiple >> forms, but only uploaded in a subset of those, such that it is >> difficult to learn what types are acceptable), as well as Accept-Blah, >> for any future method that contains a body or any request that might >> return 415? james' response is right along the lines what i would say. you might be able to come up with a model for an Accept-AnyMethod field, but it would necessarily be more complicated. and not that this proves anything, but link hints as they are defined in the current draft support method-specific hints such as accept-post: http://tools.ietf.org/html/draft-nottingham-link-hint-00#section-3.4 when we (the W3C LDP WG) came up with Accept-Post, we followed the model of Accept-Patch, which already exists as a registered header field: http://tools.ietf.org/html/rfc5789#section-4.1 personally, i don't think there's a functional difference between what you can do with method-specific fields, or with one field that openly covers all methods. the reasons for doing it per method include: - there is precedent (Accept-Patch) - link hints currently follow the same method-specific model. - the "content model" is simpler than for a more general header field. the preference of the LDP WG of course is to follow the path we're proposing, also because we already have implementations using it: http://tools.ietf.org/html/draft-wilde-accept-post-01#section-6 thanks and cheers, dret. -- erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | | UC Berkeley - School of Information (ISchool) | | http://dret.net/netdret http://twitter.com/dret | From stpeter@stpeter.im Mon Sep 9 12:54:56 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8400721F937E for ; Mon, 9 Sep 2013 12:54:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZMONW9BYuQLO for ; Mon, 9 Sep 2013 12:54:49 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 74B2111E8131 for ; Mon, 9 Sep 2013 12:54:40 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C909B414CF; Mon, 9 Sep 2013 13:59:01 -0600 (MDT) Message-ID: <522E277D.90205@stpeter.im> Date: Mon, 09 Sep 2013 13:54:37 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Call for APPSAWG topics for November meeting X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 19:54:56 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/9/13 1:01 PM, Murray S. Kucherawy wrote: > Colleagues, > > It's that time again. If you would like to make a presentation to > APPSAWG or to the APP Area General Meeting when we convene in > November, or if you would like to request that someone cover a > specific topic, please email appsawg-chairs@tools.ietf.org Perhaps it would make sense to have a discussion about core aspects of application security, instead of the usual smorgasbord of topics. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSLid9AAoJEOoGpJErxa2pQ00P/iY8V95QmjYfmyiz8fhRZFxY JGv3j29VG4tOkcStk1nLS/Oyn/B5hwUu6CvEEDbLTBSn3mZpMO3NgIIT9Cz5NPiL sJCjV5hQcrc+l9KY/g7cYJQRz541jA9yW6oaJetq+gYEkOalG4JkShovMNg6Trst RyjtiMweFyMSFkosS0C9vVsq+ZuCFx8sWTB3JFCA1nKSfnRVvojgzRz6bQfv4v1p N1aGBNusTjbOYonDJic6KiM8jNnrst4ALpQAzTk0rL/6QvDcfNU3LJGCLk9GmsVv +kCptQwMDmclZE2EqCyxZTTsmFUU2RodhfuREgnm0H+YzkFHdLYeLg7aG2UG+J0C 6IPfA9sEC3qPOWdEhOESeozu1vmTHcpz4tfbtmipHthvQTCGlDWkR629/XBuOm8f O+iEbJYWSf0OzIVzEw9Yl7B8qd5wYnfOBSe/DsUNN6r9vACaFljM9MN471q3eZ/E USshCkRJM3bK/iurLrkOArwnDE1oYJzEYLNSxuR2dy/k8NoWjVxOnVRP7c2xj4az xR0iPJFl9vPqG5GZ212KPh5axbXCQv87hx8pyWcbvO+aHLRIhyNvLxZ5dx4UGxqZ VM89dAHvwdExXtYc1Od3u8uEoBo4XOyasBzK3hBsR+o5zgsp1IawWlNJV9V8bBnS QVakDQ545vOVD7ixZqKB =JXJ+ -----END PGP SIGNATURE----- From martin.thomson@gmail.com Mon Sep 9 13:35:08 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6196521F8413 for ; Mon, 9 Sep 2013 13:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.45 X-Spam-Level: X-Spam-Status: No, score=-1.45 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-Q+TOruKFGN for ; Mon, 9 Sep 2013 13:35:00 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id A5FA621F84D0 for ; Mon, 9 Sep 2013 13:34:59 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id hm2so3955502wib.16 for ; Mon, 09 Sep 2013 13:34:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=o3YzjHiptsHiJWWTggk7h/xQNX4dYdH96VjkqxjQiLA=; b=C70NxCDDWMTnkBYYmFmdH3rjsd/w+vadC09GOlldn27TfY/XRyLCpemxgh6QTxyrOs 7g1CkyRowGVoP6YonkMa70GBJgwQwz4b+wlDlhPzGnXZLMoLMiI6JALzXC8TyS8KD8kT UpGQJUK9qM/RIblzS//M4pLKgZIA8827WQV5h/pxrdryQsS1AN4wwwku8HXfKAJnp9T/ UbELjthTUDDaSf8gHKQvSC0O2WvaJm7jactDM3YP1HlakjZlCV7ewm4SnzCWzLBeNcKF p7//gHnqKVYqypGp1pFbR0dH4oeoBM4kW43RcIs2+J/XOD9y21AUCY58WnilyH3rL5pE aj4g== MIME-Version: 1.0 X-Received: by 10.194.110.138 with SMTP id ia10mr14656086wjb.3.1378758898770; Mon, 09 Sep 2013 13:34:58 -0700 (PDT) Received: by 10.194.28.39 with HTTP; Mon, 9 Sep 2013 13:34:58 -0700 (PDT) In-Reply-To: <522E1D37.1030602@berkeley.edu> References: <20130907014129.18614.59207.idtracker@ietfa.amsl.com> <522A8845.6060709@berkeley.edu> <522E1D37.1030602@berkeley.edu> Date: Mon, 9 Sep 2013 13:34:58 -0700 Message-ID: From: Martin Thomson To: Erik Wilde Content-Type: text/plain; charset=UTF-8 Cc: "apps-discuss@ietf.org application-layer protocols" Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-wilde-accept-post-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 20:35:09 -0000 I was really just giving you a nudge. The draft would be better, in my opinion, if you answered this question in the draft itself. On 9 September 2013 12:10, Erik Wilde wrote: > - there is precedent (Accept-Patch) I never regard precedent as a good reason. So: bad reason. > - link hints currently follow the same method-specific model. Same reason as the bad reason. > - the "content model" is simpler than for a more general header field. Good enough reason, in the absence of other reasons. And I think that James provided the other reason: there just isn't that much of a need for this for other methods. > we already have implementations using it Not that convincing an argument honestly. From barryleiba.mailing.lists@gmail.com Mon Sep 9 18:56:48 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85F4A21F9FCF for ; Mon, 9 Sep 2013 18:56:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.017 X-Spam-Level: X-Spam-Status: No, score=-102.017 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cl3h1GxWiOus for ; Mon, 9 Sep 2013 18:56:46 -0700 (PDT) Received: from mail-vc0-x22d.google.com (mail-vc0-x22d.google.com [IPv6:2607:f8b0:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 12B2111E817D for ; Mon, 9 Sep 2013 18:56:09 -0700 (PDT) Received: by mail-vc0-f173.google.com with SMTP id id13so4664194vcb.32 for ; Mon, 09 Sep 2013 18:56:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=vQ545TRoZs9IAhvT0OH+XVF6ia1AAFxrkvmSyvGZl04=; b=Xhz7tfa8v0Wx/gZDQSj1mpfhYzWFmpq2hGd06L00SeXmt+mSO7axahT+5R4/fTWvqM XyY+qz2nZ6oaPsUW9vs2RCiR/arFkCsNTfFs6X3pMKlXHA0JavQ2sNzAqUGZY8D/ft3w /fQW7Z5DOhB6bLpTjz0ovWTk+DPa23vdk5R/SeqdAwCN6m7E9trjDYR9hYG3352F+1Eq PRAHZ1+WRLQFbgEm9qgXKz1tY13Ef1ZWwKFfEv/3MkBUdHZuRcxQCSKPQQT1EAUFRy3O 3rxQA6EAb0xFndaB5KliShcw852DPoIxJeg9/7/MoK9nxxZZcLWn4fH00tP5nXhtWaJg F8sw== MIME-Version: 1.0 X-Received: by 10.58.211.227 with SMTP id nf3mr4700082vec.20.1378778169240; Mon, 09 Sep 2013 18:56:09 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.215.16 with HTTP; Mon, 9 Sep 2013 18:56:09 -0700 (PDT) In-Reply-To: References: Date: Mon, 9 Sep 2013 21:56:09 -0400 X-Google-Sender-Auth: hyhMWGTrAW4gMKq_6cDaF9oKxp0 Message-ID: From: Barry Leiba To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Call for APPSAWG topics for November meeting X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 01:56:48 -0000 > It's that time again. If you would like to make a presentation to APPSAWG > or to the APP Area General Meeting when we convene in November, or if you > would like to request that someone cover a specific topic, please email > appsawg-chairs@tools.ietf.org with your topic and requested time. We need > some idea of how long the meeting will be so we can request an appropriate > time slot. > > The deadline for us to request a time slot is only a few weeks away, so > please don't leave your requests until the last minute. One alert: there has been some pushback in the IESG that we have been taking the Monday morning slot for a long time. We might be able to get it again... or there might be some competition, and we might wind up in a different slot. We'll have to see. Barry From mnot@mnot.net Mon Sep 9 23:56:08 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A271521E80D3 for ; Mon, 9 Sep 2013 23:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.949 X-Spam-Level: X-Spam-Status: No, score=-105.949 tagged_above=-999 required=5 tests=[AWL=-3.350, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QNpgtsyWwJSY for ; Mon, 9 Sep 2013 23:55:48 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF7821F8756 for ; Mon, 9 Sep 2013 23:55:43 -0700 (PDT) Received: from mnot-mini.mnot.net (unknown [118.209.157.42]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id E40C122E256; Tue, 10 Sep 2013 02:55:32 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Mark Nottingham In-Reply-To: Date: Tue, 10 Sep 2013 16:55:30 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <4C0A2118-ACF1-4866-BF3A-0B9CD3379E29@mnot.net> References: To: Barry Leiba X-Mailer: Apple Mail (2.1508) Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Call for APPSAWG topics for November meeting X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 06:56:08 -0000 On 10/09/2013, at 11:56 AM, Barry Leiba wrote: >> It's that time again. If you would like to make a presentation to = APPSAWG >> or to the APP Area General Meeting when we convene in November, or if = you >> would like to request that someone cover a specific topic, please = email >> appsawg-chairs@tools.ietf.org with your topic and requested time. We = need >> some idea of how long the meeting will be so we can request an = appropriate >> time slot. >>=20 >> The deadline for us to request a time slot is only a few weeks away, = so >> please don't leave your requests until the last minute. >=20 > One alert: there has been some pushback in the IESG that we have been > taking the Monday morning slot for a long time. We might be able to > get it again... or there might be some competition, and we might wind > up in a different slot. We'll have to see. How could that possibly be an issue?=20 Are the ADs secretly Hollywood stars who need top billing? Or are they = just trying to keep us on our toes? -- Mark Nottingham http://www.mnot.net/ From barryleiba@gmail.com Tue Sep 10 09:48:32 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D915B21F844D for ; Tue, 10 Sep 2013 09:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[AWL=-0.021, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qoXFx9MxgYqa for ; Tue, 10 Sep 2013 09:48:22 -0700 (PDT) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) by ietfa.amsl.com (Postfix) with ESMTP id DCAD621F8445 for ; Tue, 10 Sep 2013 09:47:52 -0700 (PDT) Received: by mail-lb0-f175.google.com with SMTP id y6so6515150lbh.34 for ; Tue, 10 Sep 2013 09:47:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=9teqYljyOqCcksfpKL14ekn7OmbBwtlRgxuX5ayp3yM=; b=n3FglhbV7mnBpcH78gIMy5gpJPRQbooDM00n9/V+TecIFFejKrHp0uzKhisIBdIsM2 1LE68lcj3wNlaJx4kuE1cFKBrxMAT5GO6xrCQM0MW3DOTlt3jlVl+X+vXb/jsOgwcdgP XGlNwuaLTYl80uAVXhnEC+By8IgKZM+j4vE+D630vizPjbQidjgmGKHHBfFoRxKubDqD Q70la8VRVLCq116CY28CecTkRIiGA//I+fcUjmKCcDEk5KquDF2fBKcIMvWvc/RZbQUn Z8dlOEtHdT5XJORV9t96J4MMEat1EkfmUcM6fPfz0Ir+x90JwaAVYK08W1yAPZH1557h 7NDQ== MIME-Version: 1.0 X-Received: by 10.152.8.115 with SMTP id q19mr22254612laa.16.1378831671816; Tue, 10 Sep 2013 09:47:51 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.112.130.39 with HTTP; Tue, 10 Sep 2013 09:47:51 -0700 (PDT) In-Reply-To: <4C0A2118-ACF1-4866-BF3A-0B9CD3379E29@mnot.net> References: <4C0A2118-ACF1-4866-BF3A-0B9CD3379E29@mnot.net> Date: Tue, 10 Sep 2013 12:47:51 -0400 X-Google-Sender-Auth: g17jz3xxizn9kVHazudhqoLfSLU Message-ID: From: Barry Leiba To: Mark Nottingham Content-Type: text/plain; charset=ISO-8859-1 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Call for APPSAWG topics for November meeting X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 16:48:33 -0000 >> One alert: there has been some pushback in the IESG that we have been >> taking the Monday morning slot for a long time. We might be able to >> get it again... or there might be some competition, and we might wind >> up in a different slot. We'll have to see. > > How could that possibly be an issue? > > Are the ADs secretly Hollywood stars who need top billing? Or are they just > trying to keep us on our toes? I don't understand either the question or the snark. Care to explain? We don't schedule different area meetings in conflict with each other. We don't schedule BoFs in conflict with area meetings. Other areas want to use an early slot to do planning and outlook for the week. We prefer to schedule BoFs early in the week. All of those mean that the Monday morning slot is one that's in some demand. Barry From stpeter@stpeter.im Tue Sep 10 09:54:45 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F153821E816A for ; Tue, 10 Sep 2013 09:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5XAc37TedYqB for ; Tue, 10 Sep 2013 09:54:40 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 7AAA221E8166 for ; Tue, 10 Sep 2013 09:54:38 -0700 (PDT) Received: from sjc-vpn6-59.cisco.com (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E69B44150A; Tue, 10 Sep 2013 10:59:02 -0600 (MDT) Message-ID: <522F4ECB.5000109@stpeter.im> Date: Tue, 10 Sep 2013 10:54:35 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Barry Leiba References: <4C0A2118-ACF1-4866-BF3A-0B9CD3379E29@mnot.net> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Mark Nottingham , IETF Apps Discuss Subject: Re: [apps-discuss] Call for APPSAWG topics for November meeting X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 16:54:45 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/10/13 10:47 AM, Barry Leiba wrote: >>> One alert: there has been some pushback in the IESG that we >>> have been taking the Monday morning slot for a long time. We >>> might be able to get it again... or there might be some >>> competition, and we might wind up in a different slot. We'll >>> have to see. >> >> How could that possibly be an issue? >> >> Are the ADs secretly Hollywood stars who need top billing? Or are >> they just trying to keep us on our toes? > > I don't understand either the question or the snark. Care to > explain? > > We don't schedule different area meetings in conflict with each > other. We don't schedule BoFs in conflict with area meetings. Other > areas want to use an early slot to do planning and outlook for the > week. We prefer to schedule BoFs early in the week. > > All of those mean that the Monday morning slot is one that's in > some demand. FWIW, I see no special need for AppsArea to meet on Monday morning. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSL07LAAoJEOoGpJErxa2pG0UP/2DrgQYffh+gI8n8gycP3rDz /XqsZbqvBEBQGd5GnxszYj/mQJeJJsl8lD9vt3QFFWG+BnviHf9bUuq3HR5rG0Jt QEdt2FYQPAFsTZjE9/TUzxQk0M9+8SHXN3PQuarBMHrJ6wyDXgUstqjyJIFoJY64 80qrxBBlUM3W5i/3E2SROsrxfSvV40TBuMfHphwKXE9TIUbL1FIhbf9Erb42Mn6n skfxHJVZBN1nqGcOMxuWktd1SmkZcF12ErctKSCEkZ7aeGQT1XcueUdYIjqhYWnX ziLFqVhLx6TX1c9u6EuhS5La6fyIAe8hRVhirReiB/Q3NCUhT0KM4hTtwZewWC+A l6m5M5+VKFdk3xZUNOG+0TWXykOoDzCecF77Riu5yKIKceHli2BvXfDJ2jIKTcv2 jDrHAVG15IiQ7E9oc1O3BClhSoZdzpwveiwWPl+UYp7kvYG9C83frvofpn5ChF2/ De85iimpiTXPQOuD0hEONP5rR+3cyuGzq/sP7VPLfGHVQL2rp8a08yZbyv5lUogz dSS5dPy6jW98dVp0hFJ2IeR2KqugdCKZ9PoIhPBtSqOczclsHDxhPpp8+vAvaYrL CttTp+LC6EpKPT2xyNtKrLtVVgXQIVlc/no6Dm/g+lWD8rq5oyKaAMgQJU3hlc/o a0KoSHGGGPA3XHNoSwpc =8j8y -----END PGP SIGNATURE----- From mnot@mnot.net Tue Sep 10 22:45:35 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF74A11E8168 for ; Tue, 10 Sep 2013 22:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.833 X-Spam-Level: X-Spam-Status: No, score=-104.833 tagged_above=-999 required=5 tests=[AWL=-2.233, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJo0mISKwmeW for ; Tue, 10 Sep 2013 22:45:28 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 28B6511E8166 for ; Tue, 10 Sep 2013 22:45:27 -0700 (PDT) Received: from [192.168.1.64] (unknown [118.209.157.42]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 9FC6522E255; Wed, 11 Sep 2013 01:45:20 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Mark Nottingham In-Reply-To: Date: Wed, 11 Sep 2013 15:45:14 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <425E17E7-A789-495F-996F-3FBEBAB9A9DB@mnot.net> References: <4C0A2118-ACF1-4866-BF3A-0B9CD3379E29@mnot.net> To: Barry Leiba X-Mailer: Apple Mail (2.1508) Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Call for APPSAWG topics for November meeting X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 11 Sep 2013 05:45:35 -0000 On 11/09/2013, at 2:47 AM, Barry Leiba wrote: >>> One alert: there has been some pushback in the IESG that we have = been >>> taking the Monday morning slot for a long time. We might be able to >>> get it again... or there might be some competition, and we might = wind >>> up in a different slot. We'll have to see. >>=20 >> How could that possibly be an issue? >>=20 >> Are the ADs secretly Hollywood stars who need top billing? Or are = they just >> trying to keep us on our toes? >=20 > I don't understand either the question or the snark. Care to explain? In general, I find planning my IETF weeks very frustrating. There are = very often conflicts (in terms of things I need to see), and the agenda = is available very late. Remember that IETF travel for me is expensive, = especially when done at the last minute, and time-consuming; juggling = priorities, work commitments and the realities of travelling across = multiple hemispheres is very difficult.=20 The one bit of sanity-preserving information that I've had when doing = this planning is that I've known that APPSAREA is on Monday AM. Now the = IESG is taking that away. So, apologies for my outburst of snark. Other organisations do this better. E.g., the W3C is having a plenary = week in November, and the agenda has been known for some time. Their = groups have two-day meetings, so they can actually get some work done, = and it's possible to arrange things so you can slip out of one meeting = to catch a topic in another (without the hall sprints that ADs are = becoming legendary for). It's true that they have ~31 groups meeting in a week and we have ~110, = but that only makes me wonder if we're really seeing value by packing so = much into one week (or indeed, one organisation). Regards, -- Mark Nottingham http://www.mnot.net/ From alexey.melnikov@isode.com Wed Sep 11 06:36:10 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 818C721F894E for ; Wed, 11 Sep 2013 06:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.5 X-Spam-Level: X-Spam-Status: No, score=-102.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Npu8OANMYFHs for ; Wed, 11 Sep 2013 06:36:10 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id C3BBC21F85E6 for ; Wed, 11 Sep 2013 06:36:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1378906568; d=isode.com; s=selector; i=@isode.com; bh=WDkpGb6b7Gbi2degI47dox3BkB0YNW7hqIKMmPlDGrw=; 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=t9pmi8ISJbDeKtQahbFFFQqDJY+xaQoqHYHf9eeAEeb4NEtjc8Qgz/eQ2vWvpwosdjdb2P GfbUKvypX2PNHueZ0tzoHCczJHWozVIEO4gpJvwv5Rd9eG56OTVhyG599BYwue8/H9m51i Mv7xdClq5YRwiLMJ7easrqpg2JKzzvw=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 11 Sep 2013 14:36:08 +0100 Message-ID: <523071C8.6090703@isode.com> Date: Wed, 11 Sep 2013 14:36:08 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 To: Peter Saint-Andre References: <4C0A2118-ACF1-4866-BF3A-0B9CD3379E29@mnot.net> <522F4ECB.5000109@stpeter.im> In-Reply-To: <522F4ECB.5000109@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Mark Nottingham , Barry Leiba , IETF Apps Discuss Subject: Re: [apps-discuss] Call for APPSAWG topics for November meeting X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 11 Sep 2013 13:36:10 -0000 On 10/09/2013 17:54, Peter Saint-Andre wrote: > On 9/10/13 10:47 AM, Barry Leiba wrote: >>>> One alert: there has been some pushback in the IESG that we >>>> have been taking the Monday morning slot for a long time. We >>>> might be able to get it again... or there might be some >>>> competition, and we might wind up in a different slot. We'll >>>> have to see. >>> How could that possibly be an issue? >>> >>> Are the ADs secretly Hollywood stars who need top billing? Or are >>> they just trying to keep us on our toes? >> I don't understand either the question or the snark. Care to >> explain? >> >> We don't schedule different area meetings in conflict with each >> other. We don't schedule BoFs in conflict with area meetings. Other >> areas want to use an early slot to do planning and outlook for the >> week. We prefer to schedule BoFs early in the week. >> >> All of those mean that the Monday morning slot is one that's in >> some demand. > FWIW, I see no special need for AppsArea to meet on Monday morning. I do find a fixed time for Apps Area to be a good thing for personal planning. I wish all Areas do the same (Security have SAAG in pretty much fixed slot as well.) From barryleiba@gmail.com Wed Sep 11 09:07:22 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8C2E21E80E2 for ; Wed, 11 Sep 2013 09:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.014 X-Spam-Level: X-Spam-Status: No, score=-102.014 tagged_above=-999 required=5 tests=[AWL=-0.036, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r8hbjNJfnNxu for ; Wed, 11 Sep 2013 09:07:21 -0700 (PDT) Received: from mail-qe0-x236.google.com (mail-qe0-x236.google.com [IPv6:2607:f8b0:400d:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id CC3F521F84E3 for ; Wed, 11 Sep 2013 09:06:50 -0700 (PDT) Received: by mail-qe0-f54.google.com with SMTP id cy11so5523475qeb.41 for ; Wed, 11 Sep 2013 09:06:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=qo2kqIU4bc73q48oGRlIrbJsAV8W7AbWLfLLayTwGIk=; b=Oyiuj2BRvX130ZJaRHCsZCCZyOLecsm8WoXysXAHUbBD8fq1WxvbqrNMEbc7G37c0k XmF1R9Jz/qS9ZepH481W+L4nzYFqfKjBz9ShmYWVZgzIdE/Ofhb+4yzXGa7d2dkp1Nfz hQ8QKa4epUfUlP4iFshp1Tb1f7fF69kavmiv9QMHdsurda/kejSTH1P4tE/BK2KZYJ6/ 9u+pH6vHILKbp6qUBY5dwyAMUPNjis1XDFOtDCG4NwRgph0bF/GjUwPwb6hU4HVWGhSb HbM9IThdFuIaRH8Ke8iQRuZ69qZJS2ovMXuAkz4DOXC1vB2SDuByNZDjvuVVR/BjoyJK im9g== MIME-Version: 1.0 X-Received: by 10.229.127.74 with SMTP id f10mr4669975qcs.16.1378915606000; Wed, 11 Sep 2013 09:06:46 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.49.50.197 with HTTP; Wed, 11 Sep 2013 09:06:45 -0700 (PDT) In-Reply-To: <425E17E7-A789-495F-996F-3FBEBAB9A9DB@mnot.net> References: <4C0A2118-ACF1-4866-BF3A-0B9CD3379E29@mnot.net> <425E17E7-A789-495F-996F-3FBEBAB9A9DB@mnot.net> Date: Wed, 11 Sep 2013 12:06:45 -0400 X-Google-Sender-Auth: b7fI16RRer6MAz5kczDAZbbAIxc Message-ID: From: Barry Leiba To: Mark Nottingham Content-Type: text/plain; charset=ISO-8859-1 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Call for APPSAWG topics for November meeting X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 11 Sep 2013 16:07:22 -0000 > In general, I find planning my IETF weeks very frustrating. Indeed; you're not alone. > The one bit of sanity-preserving information that I've had when doing this planning > is that I've known that APPSAREA is on Monday AM. And that's one reason we've tried to keep it there. Another is that it's a good slot when we want to use it to introduce and plan the week, and to set people up for hallway or bar conversations later in the week. > Now the IESG is taking that away. We're not sure about that. What happened last time is that a couple of ADs noted - that we've had that slot for a long time, and - that it's a slot they would also find useful, and - having appsawg in that slot means that certain other things can't be scheduled there, so it exacerbates some of the scheduling difficulties. At this point, I'm not sure what will happen. It's certainly true that we have no particular claim to that slot, and it's hard to justify saying, "No, your area can't have it because we were there first," much as I might like to. > Other organisations do this better. I understand that our scheduling is different to that of other organizations. The problem is that what you call "better", others would call "worse". To get a firm agenda earlier, we'd have to have WGCs get their plans and agendas in earlier (and every time I suggest that I get WGCs pounding on my door, carrying torches and axes), we'd have to get the BoF requests in earlier... etc. A large reason our face-to-face scheduling is the way it is, is that our work is done in a way that's different to other organizations: we're working stuff out on the mailing lists constantly (at least for the really active work), and we don't know two months before the meeting what we'll need to talk about at the meeting. That's also why we don't have the "two days of concentrated work" model for WG meetings: the WGs are expected to be doing that work on the mailing list, day to day, month to month, and the meeting time is meant to be brief and to the point, only for working out sticky points that need 20 minutes of fisticuffs rather than weeks of circular arguments on the list. > that only makes me wonder if we're really seeing value by packing so much into one > week (or indeed, one organisation). That is, indeed, a discussion that comes up periodically. If you really want to have that one, head for the main IETF discussion list. Barry From dhc@dcrocker.net Wed Sep 11 16:52:36 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F25F721F9D2A for ; Wed, 11 Sep 2013 16:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id agT55++eblkD for ; Wed, 11 Sep 2013 16:52:30 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 230AD21F85BB for ; Wed, 11 Sep 2013 16:52:30 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r8BNqOBN030215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 11 Sep 2013 16:52:27 -0700 Message-ID: <52310222.6040601@dcrocker.net> Date: Wed, 11 Sep 2013 16:52:02 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: DKIM IETF WG , Apps Discuss References: <5230F81A.2030901@bbiw.net> In-Reply-To: <5230F81A.2030901@bbiw.net> X-Forwarded-Message-Id: <5230F81A.2030901@bbiw.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Wed, 11 Sep 2013 16:52:27 -0700 (PDT) Subject: [apps-discuss] Fwd: Request to move RFC 5617 (ADSP) to Historic X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Sep 2013 23:52:36 -0000 Folks, Barry has agreed to sponsor the enclosed status change. He would like to see discussion formal request. (If you've already responded to my /in/formal query earlier today on the dmarc@ietf list, please now lodge any formal comments you wish to make on either of the two lists here. d/ -------- Original Message -------- Subject: Request to move RFC 5617 (ADSP) to Historic Date: Wed, 11 Sep 2013 16:09:14 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking To: Barry Leiba , Pete Resnick Folks, This is a formal request, to have DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP) (RFC 5617) moved to Historic status. It has garnered almost no deployment and use, in the 4 years since its advancement to IETF Proposed Standard. In addition, newer work, DMARC, covers the same general email functional area and already has garnered quite a bit of deployment and use. Hence it will clarify things for the marketplace to remove standards status from the apparently-competing, but actually-useless ADSP specification. Today I sent a query to the MAAWG Technical committee and the IETF DMARC mailing lists, to assess support for the status change. Within only a few hours, I've already seen quite a few +1s, and no -1s. Thanks. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From mnot@mnot.net Wed Sep 11 17:18:49 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B64611E80C5 for ; Wed, 11 Sep 2013 17:18:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.274 X-Spam-Level: X-Spam-Status: No, score=-104.274 tagged_above=-999 required=5 tests=[AWL=-1.675, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8SUt8vvZfqsS for ; Wed, 11 Sep 2013 17:18:44 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id C3F2F11E80DC for ; Wed, 11 Sep 2013 17:18:43 -0700 (PDT) Received: from [192.168.1.64] (unknown [118.209.157.42]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 5C48C22E253; Wed, 11 Sep 2013 20:18:33 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Mark Nottingham In-Reply-To: Date: Thu, 12 Sep 2013 10:18:30 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <73A4A3DC-15D7-456B-956A-E7D6BBFA509E@mnot.net> References: <4C0A2118-ACF1-4866-BF3A-0B9CD3379E29@mnot.net> <425E17E7-A789-495F-996F-3FBEBAB9A9DB@mnot.net> To: Barry Leiba X-Mailer: Apple Mail (2.1508) Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Call for APPSAWG topics for November meeting X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 12 Sep 2013 00:18:49 -0000 On 12/09/2013, at 2:06 AM, Barry Leiba wrote: >=20 > We're not sure about that. What happened last time is that a couple > of ADs noted > - that we've had that slot for a long time, and > - that it's a slot they would also find useful, and > - having appsawg in that slot means that certain other things can't be > scheduled there, so it exacerbates some of the scheduling > difficulties. >=20 > At this point, I'm not sure what will happen Suggestion: AD cage match > . It's certainly true > that we have no particular claim to that slot, and it's hard to > justify saying, "No, your area can't have it because we were there > first," much as I might like to. >=20 >> Other organisations do this better. >=20 > I understand that our scheduling is different to that of other > organizations. The problem is that what you call "better", others > would call "worse". To get a firm agenda earlier, we'd have to have > WGCs get their plans and agendas in earlier (and every time I suggest > that I get WGCs pounding on my door, carrying torches and axes), we'd > have to get the BoF requests in earlier... etc. >=20 > A large reason our face-to-face scheduling is the way it is, is that > our work is done in a way that's different to other organizations: > we're working stuff out on the mailing lists constantly (at least for > the really active work), and we don't know two months before the > meeting what we'll need to talk about at the meeting. >=20 > That's also why we don't have the "two days of concentrated work" > model for WG meetings: the WGs are expected to be doing that work on > the mailing list, day to day, month to month, and the meeting time is > meant to be brief and to the point, only for working out sticky points > that need 20 minutes of fisticuffs rather than weeks of circular > arguments on the list. >=20 >> that only makes me wonder if we're really seeing value by packing so = much into one >> week (or indeed, one organisation). >=20 > That is, indeed, a discussion that comes up periodically. If you > really want to have that one, head for the main IETF discussion list. My windmill quota is full, but thanks. Cheers, -- Mark Nottingham http://www.mnot.net/ From tzink@exchange.microsoft.com Wed Sep 11 17:46:32 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75DA121E80F9 for ; Wed, 11 Sep 2013 17:46:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TY27u3PZOc7V for ; Wed, 11 Sep 2013 17:46:28 -0700 (PDT) Received: from na01-sn2-obe.outbound.o365filtering.com (na01-sn2-obe.ptr.o365filtering.com [157.55.158.24]) by ietfa.amsl.com (Postfix) with ESMTP id 47F0B21E804D for ; Wed, 11 Sep 2013 17:46:28 -0700 (PDT) Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com (10.255.109.167) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com (10.255.109.167) with Microsoft SMTP Server (TLS) id 15.0.785.4; Thu, 12 Sep 2013 00:46:25 +0000 Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.6.175]) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.6.175]) with mapi id 15.00.0785.001; Thu, 12 Sep 2013 00:46:25 +0000 From: Terry Zink To: DKIM IETF WG , Apps Discuss Thread-Topic: [apps-discuss] Fwd: Request to move RFC 5617 (ADSP) to Historic Thread-Index: AQHOr0oE9cCCq03w1kmxyXunbiNwyJnBRGTw Date: Thu, 12 Sep 2013 00:46:24 +0000 Message-ID: <1cee8f23e9fc46169193c41a25b680b9@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> References: <5230F81A.2030901@bbiw.net> <52310222.6040601@dcrocker.net> In-Reply-To: <52310222.6040601@dcrocker.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.157.4] x-forefront-prvs: 0967749BC1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(13464003)(377454003)(2473001)(199002)(189002)(33646001)(15975445006)(47736001)(47976001)(80976001)(79102001)(50986001)(561944002)(49866001)(80022001)(74366001)(69226001)(76796001)(83072001)(76786001)(81686001)(63696002)(56816003)(77096001)(74876001)(54356001)(53806001)(19580405001)(76482001)(59766001)(4396001)(81542001)(74706001)(31966008)(77982001)(83322001)(51856001)(81816001)(56776001)(54316002)(46102001)(74502001)(74662001)(19580395003)(47446002)(81342001)(65816001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2SR01MB605; H:BL2SR01MB605.namsdf01.sdf.exchangelabs.com; CLIP:10.255.157.4; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: DuplicateDomain-61ba7064-737a-4e22-89e1-0398ba8005ed.exchange.microsoft.com Subject: Re: [apps-discuss] Fwd: Request to move RFC 5617 (ADSP) to Historic X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 12 Sep 2013 00:46:32 -0000 I agree with this proposal. -- Terry -----Original Message----- From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = On Behalf Of Dave Crocker Sent: Wednesday, September 11, 2013 4:52 PM To: DKIM IETF WG; Apps Discuss Subject: [apps-discuss] Fwd: Request to move RFC 5617 (ADSP) to Historic Folks, Barry has agreed to sponsor the enclosed status change. He would like to see discussion formal request. (If you've already responded to my /in/formal query earlier today on the dm= arc@ietf list, please now lodge any formal comments you wish to make on eit= her of the two lists here. d/ -------- Original Message -------- Subject: Request to move RFC 5617 (ADSP) to Historic Date: Wed, 11 Sep 2013 16:09:14 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking To: Barry Leiba , Pete Resnick Folks, This is a formal request, to have DomainKeys Identified Mail (DKIM) Author = Domain Signing Practices (ADSP) (RFC 5617) moved to Historic status. It has garnered almost no deployment and use, in the 4 years since its adva= ncement to IETF Proposed Standard. In addition, newer work, DMARC, covers the same general email functional ar= ea and already has garnered quite a bit of deployment and use. Hence it wil= l clarify things for the marketplace to remove standards status from the ap= parently-competing, but actually-useless ADSP specification. Today I sent a query to the MAAWG Technical committee and the IETF DMARC ma= iling lists, to assess support for the status change. Within only a few hou= rs, I've already seen quite a few +1s, and no -1s. Thanks. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From superuser@gmail.com Wed Sep 11 18:15:54 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B27C611E8227 for ; Wed, 11 Sep 2013 18:15:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.594 X-Spam-Level: X-Spam-Status: No, score=-2.594 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wo-7dutpHZnC for ; Wed, 11 Sep 2013 18:15:53 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) by ietfa.amsl.com (Postfix) with ESMTP id 5D11D11E8169 for ; Wed, 11 Sep 2013 18:15:47 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id ez12so2886406wid.3 for ; Wed, 11 Sep 2013 18:15:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bQ+5qaW5tTRKcLxGuWEU2um/AoZzyxKdLnatgGA2BAQ=; b=lc5zlCDvln3SfWIjjoV6tGVnF0qCLscQQRVtcrR/mxmAvyUVEGiU+snXGL+a9nYeI1 MIchluKNezx9lLGZmhgx7TwotIujCjjbwNlKJJwuwwfbs8zm9MktzKfasKx5Bx9mLXt7 B8IewEYC/NznxoWtfPJTa+2g5igarWKIfQZtd/Z9leLD+nfxz8+KHo8FW2+b4O7En7I2 3l39E1q+N41taxjEjbxYErvgI0frVriuUd51cj4ICeKq3GM4zi3PyV3A09euNoAUWTCc ATHWpdKY4+0Ie0RtAUYcymKhgtte/BuLBj45fSFc5dlJ2WAEo7npYdfJbQB+ChjFA+pO w4EA== MIME-Version: 1.0 X-Received: by 10.180.183.51 with SMTP id ej19mr3636133wic.60.1378948546506; Wed, 11 Sep 2013 18:15:46 -0700 (PDT) Received: by 10.180.106.169 with HTTP; Wed, 11 Sep 2013 18:15:46 -0700 (PDT) In-Reply-To: <1cee8f23e9fc46169193c41a25b680b9@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> References: <5230F81A.2030901@bbiw.net> <52310222.6040601@dcrocker.net> <1cee8f23e9fc46169193c41a25b680b9@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> Date: Wed, 11 Sep 2013 18:15:46 -0700 Message-ID: From: "Murray S. Kucherawy" To: Terry Zink Content-Type: multipart/alternative; boundary=001a11c2409e4735a304e6257aae Cc: DKIM IETF WG , Apps Discuss Subject: Re: [apps-discuss] Fwd: Request to move RFC 5617 (ADSP) to Historic X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 12 Sep 2013 01:15:54 -0000 --001a11c2409e4735a304e6257aae Content-Type: text/plain; charset=ISO-8859-1 I also agree with this proposal. I don't have much to add over the text in the formal request; it lays out the case based on my experience implementing DKIM and ADSP in open source. I can also say that I have never encountered an operation that actively uses it, including current and previous employers. -MSK On Wed, Sep 11, 2013 at 5:46 PM, Terry Zink wrote: > I agree with this proposal. > > -- Terry > > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] > On Behalf Of Dave Crocker > Sent: Wednesday, September 11, 2013 4:52 PM > To: DKIM IETF WG; Apps Discuss > Subject: [apps-discuss] Fwd: Request to move RFC 5617 (ADSP) to Historic > > Folks, > > Barry has agreed to sponsor the enclosed status change. > > He would like to see discussion formal request. > > (If you've already responded to my /in/formal query earlier today on the > dmarc@ietf list, please now lodge any formal comments you wish to make on > either of the two lists here. > > d/ > > > -------- Original Message -------- > Subject: Request to move RFC 5617 (ADSP) to Historic > Date: Wed, 11 Sep 2013 16:09:14 -0700 > From: Dave Crocker > Organization: Brandenburg InternetWorking > To: Barry Leiba , Pete Resnick < > resnick@episteme-software.com> > > Folks, > > This is a formal request, to have DomainKeys Identified Mail (DKIM) Author > Domain Signing Practices (ADSP) (RFC 5617) moved to Historic status. > > It has garnered almost no deployment and use, in the 4 years since its > advancement to IETF Proposed Standard. > > In addition, newer work, DMARC, covers the same general email functional > area and already has garnered quite a bit of deployment and use. Hence it > will clarify things for the marketplace to remove standards status from the > apparently-competing, but actually-useless ADSP specification. > > Today I sent a query to the MAAWG Technical committee and the IETF DMARC > mailing lists, to assess support for the status change. Within only a few > hours, I've already seen quite a few +1s, and no -1s. > > Thanks. > > > d/ > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --001a11c2409e4735a304e6257aae Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I also agree with this proposal.=A0 I don't have = much to add over the text in the formal request; it lays out the case based= on my experience implementing DKIM and ADSP in open source.=A0 I can also = say that I have never encountered an operation that actively uses it, inclu= ding current and previous employers.

-MSK


On Wed, Sep 11, 2013 at 5:46 PM, Terry Zink &l= t;tzink@e= xchange.microsoft.com> wrote:
I agree with this proposal.

-- Terry

-----Original Message-----
From: apps-discuss-bounces= @ietf.org [mailto:apps= -discuss-bounces@ietf.org] On Behalf Of Dave Crocker
Sent: Wednesday, September 11, 2013 4:52 PM
To: DKIM IETF WG; Apps Discuss
Subject: [apps-discuss] Fwd: Request to move RFC 5617 (ADSP) to Historic
Folks,

Barry has agreed to sponsor the enclosed status change.

He would like to see discussion formal request.

(If you've already responded to my /in/formal query earlier today on th= e dmarc@ietf list, please now lodge any formal comments you wish to make on= either of the two lists here.

d/


-------- Original Message --------
Subject: Request to move RFC 5617 (ADSP) to Historic
Date: Wed, 11 Sep 2013 16:09:14 -0700
From: Dave Crocker <dcrocker@bbiw.n= et>
Organization: Brandenburg InternetWorking
To: Barry Leiba <barryleiba@c= omputer.org>, =A0Pete Resnick <resnick@episteme-software.com>

Folks,

This is a formal request, to have DomainKeys Identified Mail (DKIM) Author = Domain Signing Practices (ADSP) (RFC 5617) moved to Historic status.

It has garnered almost no deployment and use, in the 4 years since its adva= ncement to IETF Proposed Standard.

In addition, newer work, DMARC, covers the same general email functional ar= ea and already has garnered quite a bit of deployment and use. Hence it wil= l clarify things for the marketplace to remove standards status from the ap= parently-competing, but actually-useless ADSP specification.

Today I sent a query to the MAAWG Technical committee and the IETF DMARC ma= iling lists, to assess support for the status change. Within only a few hou= rs, I've already seen quite a few +1s, and no -1s.

Thanks.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss
_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--001a11c2409e4735a304e6257aae-- From johnl@iecc.com Wed Sep 11 18:40:12 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB91921E80C6 for ; Wed, 11 Sep 2013 18:40:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.382 X-Spam-Level: X-Spam-Status: No, score=-102.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gRure3O5HGCc for ; Wed, 11 Sep 2013 18:40:08 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 7399011E80D5 for ; Wed, 11 Sep 2013 18:40:08 -0700 (PDT) Received: (qmail 97869 invoked from network); 12 Sep 2013 01:40:07 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 12 Sep 2013 01:40:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=52311b77.xn--yuvv84g.k1309; i=johnl@user.iecc.com; bh=2/ISI0pqG/zYa42q/NtNClMzpFAKLxJvBXLZE7ejl40=; b=wp+u72c4OymzUbQp89l9xVS0xMu9mvCVAwFz6anoHZ2hvwSkVw4npUxUC0BEi2T+2UjH9Zk6fi+uZ/YvbcBwlhLb0l95W1ZD/h1IQEnDjxxBXp0elQHZCKkdM3LCKxHTRHyza1UCeVcuTQ/T8IxcUexDLSMs8CPW0FE7Y/BPj9Su1jRGdUfAkZMiCV7WwJcF3d0hTKfm5aEe4b62iBX18YIa78ZSNcZpg542MEjVYh525h5xMUmMGQy4aOZcUl3S DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=52311b77.xn--yuvv84g.k1309; olt=johnl@user.iecc.com; bh=2/ISI0pqG/zYa42q/NtNClMzpFAKLxJvBXLZE7ejl40=; b=PshaUcgNsEx97NBsKsRHDL4xsZ1IgDeW5MysGloofFwJZrpg89NokZ+iUH1/L4aI2P9egeQMeC8VH2/mtlI8HltxzuNhbpCglwWlJWqD1rjuJJo3dQUE4gWXNR6PAC+TzaSU7AyG8qWSumJCN3ZwHzURKcAsqv+FkwkBTagsQ/m4N/A1CSnLhcMvJvAWFuZvUo4Jt8RKuQn49hXUWv9u4CsChTB50AJz7COONZU86zYRIro+JykJUdcLO5ilRgyx Date: 12 Sep 2013 01:39:45 -0000 Message-ID: <20130912013945.42949.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <52310222.6040601@dcrocker.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Cc: dcrocker@bbiw.net Subject: Re: [apps-discuss] Fwd: Request to move RFC 5617 (ADSP) to Historic X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 12 Sep 2013 01:40:12 -0000 >This is a formal request, to have DomainKeys Identified Mail (DKIM) >Author Domain Signing Practices (ADSP) (RFC 5617) moved to Historic status. I'm one of the authors, and I think it's a dandy idea. Other than a few experiments and one or two impressive misfires, such as one that bounced innocent bystanders off an IETF mailing list, nobody's ever used it. R's, John From tony@att.com Wed Sep 11 20:10:29 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9B331F0ED1 for ; Wed, 11 Sep 2013 20:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.307 X-Spam-Level: X-Spam-Status: No, score=-105.307 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Ht1Zwa8H0Uk for ; Wed, 11 Sep 2013 20:10:23 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id AA77B1F0EDB for ; Wed, 11 Sep 2013 20:10:22 -0700 (PDT) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id e9031325.0.1053220.00-268.2918445.nbfkord-smmo05.seg.att.com (envelope-from ); Thu, 12 Sep 2013 03:10:22 +0000 (UTC) X-MXL-Hash: 5231309e0bf0899e-88c65791453c5b96f5effd328fcb0c53e14db5dc Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r8C3ALDY009511 for ; Wed, 11 Sep 2013 23:10:21 -0400 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r8C3A9rx009453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 11 Sep 2013 23:10:17 -0400 Received: from alpi153.aldc.att.com (alpi153.aldc.att.com [130.8.42.31]) by alpi132.aldc.att.com (RSA Interceptor) for ; Thu, 12 Sep 2013 03:10:02 GMT Received: from aldc.att.com (localhost [127.0.0.1]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id r8C3A2Tv006683 for ; Wed, 11 Sep 2013 23:10:02 -0400 Received: from dns.maillennium.att.com (maillennium.att.com [135.25.114.99]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id r8C39qjF006365 for ; Wed, 11 Sep 2013 23:09:58 -0400 Received: from [135.70.114.175] (vpn-135-70-114-175.vpn.swst.att.com[135.70.114.175]) by maillennium.att.com (mailgw1) with ESMTP id <20130912030948gw1004nhfse> (Authid: tony); Thu, 12 Sep 2013 03:09:52 +0000 X-Originating-IP: [135.70.114.175] Message-ID: <5231307B.3070902@att.com> Date: Wed, 11 Sep 2013 23:09:47 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 References: <5230F81A.2030901@bbiw.net> <52310222.6040601@dcrocker.net> In-Reply-To: <52310222.6040601@dcrocker.net> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] X-AnalysisOut: [v=2.0 cv=dr9s/Sc4 c=1 sm=0 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=oSlXaJep1AoA:10 a=sCfsyOEanakA:10 a=dKfqzFh-JMUA:10 a=ofM] X-AnalysisOut: [gfj31e3cA:10 a=BLceEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=zQP7CpK] X-AnalysisOut: [OAAAA:8 a=mxGT-tIOq6YA:10 a=k7Ga1wGzAAAA:8 a=8qSefF8wAAAA:] X-AnalysisOut: [8 a=K-k2FXPAAAAA:8 a=DW2FPfv6ruJyg1hIQCIA:9 a=wPNLvfGTeEIA] X-AnalysisOut: [:10 a=fcAx7uNQz4EA:10 a=mHZC5r8sFEQA:10 a=bjbuiri_3MwA:10] Cc: DKIM IETF WG , Apps Discuss Subject: Re: [apps-discuss] Fwd: Request to move RFC 5617 (ADSP) to Historic X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 12 Sep 2013 03:10:29 -0000 This seems like a reasonable step to take. Tony Hansen On 9/11/2013 7:52 PM, Dave Crocker wrote: > Folks, > > Barry has agreed to sponsor the enclosed status change. > > He would like to see discussion formal request. > > (If you've already responded to my /in/formal query earlier today on > the dmarc@ietf list, please now lodge any formal comments you wish to > make on either of the two lists here. > > d/ > > > -------- Original Message -------- > Subject: Request to move RFC 5617 (ADSP) to Historic > Date: Wed, 11 Sep 2013 16:09:14 -0700 > From: Dave Crocker > Organization: Brandenburg InternetWorking > To: Barry Leiba , Pete Resnick > > > Folks, > > This is a formal request, to have DomainKeys Identified Mail (DKIM) > Author Domain Signing Practices (ADSP) (RFC 5617) moved to Historic > status. > > It has garnered almost no deployment and use, in the 4 years since its > advancement to IETF Proposed Standard. > > In addition, newer work, DMARC, covers the same general email functional > area and already has garnered quite a bit of deployment and use. Hence > it will clarify things for the marketplace to remove standards status > from the apparently-competing, but actually-useless ADSP specification. > > Today I sent a query to the MAAWG Technical committee and the IETF DMARC > mailing lists, to assess support for the status change. Within only a > few hours, I've already seen quite a few +1s, and no -1s. > > Thanks. > > > d/ > From lear@cisco.com Wed Sep 11 23:47:56 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E360711E81DD for ; Wed, 11 Sep 2013 23:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 87X63SsxWRky for ; Wed, 11 Sep 2013 23:47:51 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 649AF11E822F for ; Wed, 11 Sep 2013 23:47:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=480; q=dns/txt; s=iport; t=1378968468; x=1380178068; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=fWX/boZwZGfrF7s0EmuHuKWXOB+p38nMDG5pvH9/lYk=; b=I3NLzsaD4+XsFAAXM6A7t6Nd5GSyWuB5sWiRpyHh9pZqDMMsHL6kQXoK vkh3mMAQ0XmjmytSm45sQ2xomb4UpV+/mjWowJ+iX5qRK4bkVk7RLGBZA 16DPm254iBT0gPw/gIYNdmGkhlVfoOpFQ5JUoAZl5VR9Wpv4gJbe3WUZK M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAI5iMVKQ/khN/2dsb2JhbABbgweENL0UgSMWdIIlAQEBBCNVARALGAICBRYLAgIJAwIBAgFFEwEHAQGHfqt0kgyBKY5CBxaCU4E0A5d5kXKDJDo X-IronPort-AV: E=Sophos;i="4.90,888,1371081600"; d="scan'208";a="17951999" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-4.cisco.com with ESMTP; 12 Sep 2013 06:47:41 +0000 Received: from ams3-vpn-dhcp5223.cisco.com (ams3-vpn-dhcp5223.cisco.com [10.61.84.102]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r8C6ldZR020577 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Sep 2013 06:47:39 GMT Message-ID: <5231638B.7080100@cisco.com> Date: Thu, 12 Sep 2013 08:47:39 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: dcrocker@bbiw.net References: <5230F81A.2030901@bbiw.net> <52310222.6040601@dcrocker.net> In-Reply-To: <52310222.6040601@dcrocker.net> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: DKIM IETF WG , Apps Discuss Subject: Re: [apps-discuss] Fwd: Request to move RFC 5617 (ADSP) to Historic X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 12 Sep 2013 06:47:57 -0000 Dave, On 9/12/13 1:52 AM, Dave Crocker wrote: > Folks, > > Barry has agreed to sponsor the enclosed status change. > > He would like to see discussion formal request. > > (If you've already responded to my /in/formal query earlier today on > the dmarc@ietf list, please now lodge any formal comments you wish to > make on either of the two lists here. I agree. To my knowledge there has not been uptake and realistically DMARC is meant to correct this. Eliot From Claudio.Allocchio@garr.it Thu Sep 12 00:02:24 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 966F221F9FAC for ; Thu, 12 Sep 2013 00:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id adFVYwF7ZWAt for ; Thu, 12 Sep 2013 00:02:13 -0700 (PDT) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [193.206.158.29]) by ietfa.amsl.com (Postfix) with ESMTP id CA3E321E814C for ; Thu, 12 Sep 2013 00:01:52 -0700 (PDT) Received: internal info suppressed Date: Thu, 12 Sep 2013 09:01:12 +0200 (CEST) From: Claudio Allocchio X-X-Sender: claudio@vpnclnt01.dir.garr.it To: dcrocker@bbiw.net In-Reply-To: <52310222.6040601@dcrocker.net> Message-ID: References: <5230F81A.2030901@bbiw.net> <52310222.6040601@dcrocker.net> User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=garr.it; s=cyrus; t=1378969305; bh=J+4PSqBFcrkvzcI43nu7fz23neQ+duCpVXxdJSnMn+w=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Rr4JCLVlYjnZjRDbMnkrQ/2FB1pONuMw0SynNb9vQmOqq26NMbTAnGyFtRLfo6ll+ PTrb81TGMVyiZsmrHd8DCYYK6cuRl/RPDIBMi5qTpOYOr0e6Q63XobGptgQU8KO6+g Oiu1gydSyOtMFVTC+OTSL3BSHvxKCoh4T5hUj76s= Cc: DKIM IETF WG , Apps Discuss Subject: Re: [apps-discuss] Fwd: Request to move RFC 5617 (ADSP) to Historic X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 12 Sep 2013 07:02:24 -0000 On Wed, 11 Sep 2013, Dave Crocker wrote: > Folks, > > Barry has agreed to sponsor the enclosed status change. > > He would like to see discussion formal request. > > (If you've already responded to my /in/formal query earlier today on the > dmarc@ietf list, please now lodge any formal comments you wish to make on > either of the two lists here. that's fine for me. > > d/ > > > -------- Original Message -------- > Subject: Request to move RFC 5617 (ADSP) to Historic > Date: Wed, 11 Sep 2013 16:09:14 -0700 > From: Dave Crocker > Organization: Brandenburg InternetWorking > To: Barry Leiba , Pete Resnick > > > Folks, > > This is a formal request, to have DomainKeys Identified Mail (DKIM) > Author Domain Signing Practices (ADSP) (RFC 5617) moved to Historic status. > > It has garnered almost no deployment and use, in the 4 years since its > advancement to IETF Proposed Standard. > > In addition, newer work, DMARC, covers the same general email functional > area and already has garnered quite a bit of deployment and use. Hence > it will clarify things for the marketplace to remove standards status > from the apparently-competing, but actually-useless ADSP specification. > > Today I sent a query to the MAAWG Technical committee and the IETF DMARC > mailing lists, to assess support for the status change. Within only a > few hours, I've already seen quite a few +1s, and no -1s. > > Thanks. > > > d/ > > -- > Dave Crocker > Brandenburg InternetWorking > bbiw.net > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca From hsantos@isdg.net Thu Sep 12 05:34:26 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDF3E11E8166 for ; Thu, 12 Sep 2013 05:34:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g7L37qZrn-Wz for ; Thu, 12 Sep 2013 05:34:22 -0700 (PDT) Received: from winserver.com (ntbbs.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 3D5BB11E8113 for ; Thu, 12 Sep 2013 05:34:22 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3190; t=1378989254; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:Subject:To: List-ID; bh=+kEqbmIEZ/TT8SOFXpTo8K0ADLY=; b=rcePl/NMvU4ONkeVOXDI /tdMXia+g0xoG1eOh2HBOVKaATbEkHgd+Uh0r7iRlXYQI6/2kHfKxXiJ4A9mMtFg 4wLg3uE16D6cDqS715dRIwqsRlXZ763sg+rg0MR/pUpDD3d64kf0wUzOwjfEKIEU uOIw1spuhP0PR9T7Ixz6xnY= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Thu, 12 Sep 2013 08:34:14 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from opensite.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1156781175.30534.4604; Thu, 12 Sep 2013 08:34:13 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3190; t=1378988905; h=Received:Received: Message-ID:Date:From:Organization:Subject:To:List-ID; bh=fBQf0cA 2wJ8+WZJX/NEpYnDrfzqYFTyUPMHzJqZcNoE=; b=wkhPg5vrnnFoS2MNzi3WKdi NYnA1OJmkLufxIWfCGDvJmxVBBUSO9waxEB0o5CWBsZXw8D0VdVbXPL1umjhXTg8 jxW3p4mpRBUKVT6EBY8it6dMcwyEdyjyB3XwrBAtBmvdcO3gsm8t8BIfFlZrEIiV A4OpotTPPD+Eqgr97Jfw= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Thu, 12 Sep 2013 08:28:25 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 603186019.9.4236; Thu, 12 Sep 2013 08:28:24 -0400 Message-ID: <5231B4C6.9000600@isdg.net> Date: Thu, 12 Sep 2013 08:34:14 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 CC: Apps Discuss References: <5230F81A.2030901@bbiw.net> <52310222.6040601@dcrocker.net> In-Reply-To: <52310222.6040601@dcrocker.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Comment: Missing recipient address appended by wcSMTP router. To: apps-discuss@ietf.org Subject: Re: [apps-discuss] [ietf-dkim] Fwd: Request to move RFC 5617 (ADSP) to Historic X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 12 Sep 2013 12:34:27 -0000 -1 This will require a substantial review before any change of status is done and should be done as part of WG working on Domain Policies. There is already substantial work with ADSP and APIs implemented and deployed. We continue to get world wide usage of our ADSP zone record generator wizard: http://www.winserver.com/public/wcadsp Logs can provided upon request. Commercial software exist that has it deployed -- Ours is one of them. I would like a study done of all the entire scope of Domain Policy support whether its for DKIM, SPF or any other future message authentication/authorization protocol. This will help to address and eliminate the huge redundancy and waste of at least 4-5 TXT record DNS calls for each mail transaction. The IETF should review all the related mail protocols; SPF, DKIM, ADSP, extensions for ADSP such as ATPS and ASL, we have also VBR and now yet another one DMARC as one. Yet, I don't think DMARC covers what was needed. It fundamentally lacks addressing the #1 issue, #1 desire and #1 problem that plagued DKIM with SSP and ADSP -- 3rd party signer controls and policy support. I am considering to re-introduce DSAP (DKIM Signature Authorization Protocol) I-D solution and proposed it to the IETF. http://tools.ietf.org/html/draft-santos-dkim-dsap-00 The DSAP protocol covers how to handle receiver actions and authorized 3rd party signer concepts. It also expects any reputation layer to work together in integrated fashion. -- HLS On 9/11/2013 7:52 PM, Dave Crocker wrote: > Folks, > > Barry has agreed to sponsor the enclosed status change. > > He would like to see discussion formal request. > > (If you've already responded to my /in/formal query earlier today on the > dmarc@ietf list, please now lodge any formal comments you wish to make > on either of the two lists here. > > d/ > > > -------- Original Message -------- > Subject: Request to move RFC 5617 (ADSP) to Historic > Date: Wed, 11 Sep 2013 16:09:14 -0700 > From: Dave Crocker > Organization: Brandenburg InternetWorking > To: Barry Leiba , Pete Resnick > > > Folks, > > This is a formal request, to have DomainKeys Identified Mail (DKIM) > Author Domain Signing Practices (ADSP) (RFC 5617) moved to Historic status. > > It has garnered almost no deployment and use, in the 4 years since its > advancement to IETF Proposed Standard. > > In addition, newer work, DMARC, covers the same general email functional > area and already has garnered quite a bit of deployment and use. Hence > it will clarify things for the marketplace to remove standards status > from the apparently-competing, but actually-useless ADSP specification. > > Today I sent a query to the MAAWG Technical committee and the IETF DMARC > mailing lists, to assess support for the status change. Within only a > few hours, I've already seen quite a few +1s, and no -1s. > > Thanks. _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html -- HLS From hsantos@santronics.com Thu Sep 12 05:19:08 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD63821F9DAF for ; Thu, 12 Sep 2013 05:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NiEhJdTWaLik for ; Thu, 12 Sep 2013 05:19:03 -0700 (PDT) Received: from winserver.com (ntbbs.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id AD50011E8113 for ; Thu, 12 Sep 2013 05:19:02 -0700 (PDT) DKIM-Signature: v=1; d=santronics.com; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2225; t=1378988331; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=OYBJbwb F81OdSds0IuXJICh+XxA=; b=Vo6C/KvPQapT2N86OcUEkeZIcEasq4Bf5YnKEqw Jk8dA1MMhLyXIvkCrZyrj/+rX7m2aZ2SjR6mFfsSjhBkBB60EiQiXH1n2FH5w276 lnRwlvNQYaFavHn4TaEXiN8GVDyOrGxAVnRfF3qLjx/rMN/F6WhHdKWyYyFTj8xG Hb3w= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Thu, 12 Sep 2013 08:18:51 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1155858039.30534.5172; Thu, 12 Sep 2013 08:18:50 -0400 Message-ID: <5231B12E.8020909@santronics.com> Date: Thu, 12 Sep 2013 08:18:54 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Eliot Lear References: <5230F81A.2030901@bbiw.net> <52310222.6040601@dcrocker.net> <5231638B.7080100@cisco.com> In-Reply-To: <5231638B.7080100@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 12 Sep 2013 07:19:45 -0700 Cc: dcrocker@bbiw.net, Apps Discuss , DKIM IETF WG Subject: Re: [apps-discuss] [ietf-dkim] Fwd: Request to move RFC 5617 (ADSP) to Historic X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 12 Sep 2013 12:19:08 -0000 On 9/12/2013 2:47 AM, Eliot Lear wrote: > Dave, > > On 9/12/13 1:52 AM, Dave Crocker wrote: >> Folks, >> >> Barry has agreed to sponsor the enclosed status change. >> >> He would like to see discussion formal request. >> >> (If you've already responded to my /in/formal query earlier today on >> the dmarc@ietf list, please now lodge any formal comments you wish to >> make on either of the two lists here. > > I agree. To my knowledge there has not been uptake and realistically > DMARC is meant to correct this. > There are ADSP implementations, deployments, APIs and wizards too! It may not be within the exclusive club of an external trade, non-IETF group, but to suggest the investment has not be done, would not be correct. The bottom line is that DMARC does not address 3rd party controls which was the central issue with DOMAIN POLICIES layers for DKIM. It was for SSP, DSAP and made worst with ADSP when it intentionally and blindly removed 3rd party considerations from SSP and relabeled it ADSP. It was added back in with ADSP 3rd party control extensions. DMARC is mainly for reporting which does not solve the problem. It doesn't solve the main problem with protecting the copyright holding AUTHOR domain with DKIM signatures from 3rd party interference. Until DMARC can prove to be a valued replacement, that truly resolves the 3rd party issue, ADSP should not be moved to historic. I am not going to invest money and time in DMARC research when we already have much effort done with ADSP. More importantly, DMARC is not a IETF network wide solution and the key authors are not going to allow 3rd party solutions to be augmented into it. If that was the case, then we may have something to consider. But until thing, we are in the same boat. The IETF needs a thorough review of the entire concept of DOMAIN POLICIES via TXT records and the issue of 3rd party interference with security controls. Far too many TXT calls with little to no payoff value whatsoever and to add yet another DMARC TXT call exploration with absolutely NO payoff value, no added value, will be hard to take really serious. -- Sincerely Hector Santos http://www.santronics.com From hsantos@isdg.net Wed Sep 11 18:25:13 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3225D21F9D87 for ; Wed, 11 Sep 2013 18:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.691 X-Spam-Level: X-Spam-Status: No, score=-101.691 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nc5C86R2AtOh for ; Wed, 11 Sep 2013 18:24:58 -0700 (PDT) Received: from ftp.catinthebox.net (mail.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 08D1621F9BFA for ; Wed, 11 Sep 2013 18:24:52 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3023; t=1378949078; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=kKll19DAxkmNijLZwDXBUgfim4o=; b=GuCVDjeFDphroBPuR4ZE 95XpE9ZxjSvpSI9bGDJGG8h7WOgQZocMNwUQGhGTE5N25qSlFGDfiX8Noj53cFzY Rus9N7rfnZaQVx4/7opS3gdF+SfoFfc3IAZ/Me+IJqXvvVH6puhJ3i0mHvk5RjER Lpk3kHmNjlUy73jrd/UQpfE= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Wed, 11 Sep 2013 21:24:38 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from hector.wildcatblog.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1116605067.29028.2764; Wed, 11 Sep 2013 21:24:37 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3023; t=1378948729; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=Qzfh9Zp +H8E/HYtk9rUYPcq+VPN6ELxJ/k+JYEpqQ3A=; b=WUmNaFb3F2Pdq84agwoX0PB S8E1TCjKnQGwxybMvHssir3MfG3t/DM8KE8sFDt4vKq/pDh/3fLw2WX/rK9MZ72e ud0a104Rqtzr+0nW/ANsA9iLCnR2voLmbP6kCL7PE6dsdVzOF0WoaNSscPuxRgwo /FfU2Pju+ruHMa9yE84A= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Wed, 11 Sep 2013 21:18:49 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 563010487.9.6856; Wed, 11 Sep 2013 21:18:49 -0400 Message-ID: <523117D5.3030806@isdg.net> Date: Wed, 11 Sep 2013 21:24:37 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: DKIM IETF WG References: <5230F81A.2030901@bbiw.net> <52310222.6040601@dcrocker.net> In-Reply-To: <52310222.6040601@dcrocker.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 12 Sep 2013 07:20:04 -0700 Cc: Pete Resnick , Barry Leiba , Dave Crocker , Apps Discuss Subject: Re: [apps-discuss] [ietf-dkim] Fwd: Request to move RFC 5617 (ADSP) to Historic X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 12 Sep 2013 01:25:13 -0000 This will require a substantial review before any change of status is done and should be done as part of WG working on Domain Policies. There is already substantial work with ADSP and APIs implemented and deployed. We continue to get world wide usage of our ADSP zone record generator wizard: http://www.winserver.com/public/wcadsp Logs can provided upon request. Commercial software exist that has it deployed -- Ours is one of them. I would like a study done of all the entire scope of Domain Policy support whether its for DKIM, SPF or any other future message authentication/authorization protocol. This will help to address and eliminate the huge redundancy and waste of at least 4-5 TXT record DNS calls for each mail transaction. The IETF should review all the related mail protocols; SPF, DKIM, ADSP, extensions for ADSP such as ATPS and ASL, we have also VBR and now yet another one DMARC as one. Yet, I don't think DMARC covers what was needed. It fundamentally lacks addressing the #1 issue, #1 desire and #1 problem that plagued DKIM with SSP and ADSP -- 3rd party signer controls and policy support. I am considering to re-introduce DSAP (DKIM Signature Authorization Protocol) I-D solution and proposed it to the IETF. http://tools.ietf.org/html/draft-santos-dkim-dsap-00 The DSAP protocol covers how to handle receiver actions and authorized 3rd party signer concepts. It also expects any reputation layer to work together in integrated fashion. -- HLS On 9/11/2013 7:52 PM, Dave Crocker wrote: > Folks, > > Barry has agreed to sponsor the enclosed status change. > > He would like to see discussion formal request. > > (If you've already responded to my /in/formal query earlier today on the > dmarc@ietf list, please now lodge any formal comments you wish to make > on either of the two lists here. > > d/ > > > -------- Original Message -------- > Subject: Request to move RFC 5617 (ADSP) to Historic > Date: Wed, 11 Sep 2013 16:09:14 -0700 > From: Dave Crocker > Organization: Brandenburg InternetWorking > To: Barry Leiba , Pete Resnick > > > Folks, > > This is a formal request, to have DomainKeys Identified Mail (DKIM) > Author Domain Signing Practices (ADSP) (RFC 5617) moved to Historic status. > > It has garnered almost no deployment and use, in the 4 years since its > advancement to IETF Proposed Standard. > > In addition, newer work, DMARC, covers the same general email functional > area and already has garnered quite a bit of deployment and use. Hence > it will clarify things for the marketplace to remove standards status > from the apparently-competing, but actually-useless ADSP specification. > > Today I sent a query to the MAAWG Technical committee and the IETF DMARC > mailing lists, to assess support for the status change. Within only a > few hours, I've already seen quite a few +1s, and no -1s. > > Thanks. From kurta@drkurt.com Thu Sep 12 08:01:01 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D8A511E8244 for ; Thu, 12 Sep 2013 08:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D1NoE3yab5N4 for ; Thu, 12 Sep 2013 08:00:59 -0700 (PDT) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 57CF311E824A for ; Thu, 12 Sep 2013 08:00:06 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id f12so682304wgh.17 for ; Thu, 12 Sep 2013 07:59:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=cma3QT8CS6GwbsAloQrHIy2IiZiRsHP4EYXfd9yswnU=; b=OCuMf5bAtsEW88+I9N7dl7RJBmBx+gPA8uQEjt023bxD8qVuI6/F4j1LwD7HwEBN4B vEob7h7HFd9HW+p1flAiY/zVn81YlyCZnlcNp3q1WM2xiQyAqiaYJKJOIXK9jijeDjT3 4G0VTOvGq8sPENCV3Iq1qPwpTM7mErfQcK6+Q= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=cma3QT8CS6GwbsAloQrHIy2IiZiRsHP4EYXfd9yswnU=; b=GjsIX6q8fBazVBYLLa3cQmJ9TF5xu6VS3A/XNtLQi7hA6bKX1tNHAIL5S3ZoHIaLTm 5G0oLyapoQVnDF6jvbsyOwz/hHbICRi3V3GWPLDWXbgY9lBMveZdzdXt6ksuQmDn4sTY 0eymk6Xl+jvx1SjG3F6U/nLn1x7hKLrVo0O7SzMD+oWgA1sm9q0Nps3pkgbWw5DH92kM DitjW59WKr+fgxK/r2xrIjeLO9ITrqDtjJnpMydTvd4pw2PXMYkIXr7NAPcMLs5dSPJn CXuyfNu36trbXaTADCOQmgELoOOuwuU4RR1YskKXrmmSBvqSqne2mEKyn5os7l6r7zYs tsVQ== X-Gm-Message-State: ALoCoQleAu7Nm4Bv5UJcoU7fANz3/SzsJG7vBisD0dRLG3uBzbTcDp61ILntq397QY4sL36WzOl6 MIME-Version: 1.0 X-Received: by 10.194.250.69 with SMTP id za5mr469753wjc.80.1378997997474; Thu, 12 Sep 2013 07:59:57 -0700 (PDT) Sender: kurta@drkurt.com Received: by 10.194.21.97 with HTTP; Thu, 12 Sep 2013 07:59:57 -0700 (PDT) In-Reply-To: <5231638B.7080100@cisco.com> References: <5230F81A.2030901@bbiw.net> <52310222.6040601@dcrocker.net> <5231638B.7080100@cisco.com> Date: Thu, 12 Sep 2013 07:59:57 -0700 X-Google-Sender-Auth: WOfelc4GQC2FlbTX-f2MuoKtBMQ Message-ID: From: Kurt Andersen To: Apps Discuss Content-Type: multipart/alternative; boundary=001a11c1b95cc9341704e630fd4c Cc: Dave Crocker Subject: Re: [apps-discuss] Fwd: Request to move RFC 5617 (ADSP) to Historic X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 12 Sep 2013 15:01:02 -0000 --001a11c1b95cc9341704e630fd4c Content-Type: text/plain; charset=ISO-8859-1 > > On 9/12/13 1:52 AM, Dave Crocker wrote: > > Folks, > > > > Barry has agreed to sponsor the enclosed status change. > > > > He would like to see discussion formal request. > > > > (If you've already responded to my /in/formal query earlier today on > > the dmarc@ietf list, please now lodge any formal comments you wish to > > make on either of the two lists here > +1 --Kurt Andersen --001a11c1b95cc9341704e630fd4c Content-Type: text/html; charset=ISO-8859-1
On 9/12/13 1:52 AM, Dave Crocker wrote:
> Folks,
>
> Barry has agreed to sponsor the enclosed status change.
>
> He would like to see discussion formal request.
>
> (If you've already responded to my /in/formal query earlier today on
> the dmarc@ietf list, please now lodge any formal comments you wish to
> make on either of the two lists here

+1

--Kurt Andersen

--001a11c1b95cc9341704e630fd4c-- From steve@wordtothewise.com Thu Sep 12 08:50:57 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CDCE21E80C8 for ; Thu, 12 Sep 2013 08:50:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NdpKctWJxUxP for ; Thu, 12 Sep 2013 08:50:50 -0700 (PDT) Received: from m.wordtothewise.com (misc.wordtothewise.com [184.105.179.154]) by ietfa.amsl.com (Postfix) with ESMTP id 8E16711E81C0 for ; Thu, 12 Sep 2013 08:50:50 -0700 (PDT) Received: from satsuke.wordtothewise.com (204.11.227.194.static.etheric.net [204.11.227.194]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: steve) by m.wordtothewise.com (Postfix) with ESMTPSA id 181A32DDE4 for ; Thu, 12 Sep 2013 08:50:48 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Steve Atkins In-Reply-To: <20130912013945.42949.qmail@joyce.lan> Date: Thu, 12 Sep 2013 08:50:47 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130912013945.42949.qmail@joyce.lan> To: apps-discuss@ietf.org X-Mailer: Apple Mail (2.1508) Subject: Re: [apps-discuss] Request to move RFC 5617 (ADSP) to Historic X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 12 Sep 2013 15:50:57 -0000 On Sep 11, 2013, at 6:39 PM, John Levine wrote: >> This is a formal request, to have DomainKeys Identified Mail (DKIM) >> Author Domain Signing Practices (ADSP) (RFC 5617) moved to Historic = status. >=20 > I'm one of the authors, and I think it's a dandy idea. >=20 > Other than a few experiments and one or two impressive misfires, such > as one that bounced innocent bystanders off an IETF mailing list, > nobody's ever used it. +1 Cheers, Steve From fenton@bluepopcorn.net Thu Sep 12 12:20:46 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1BBA11E81A4 for ; Thu, 12 Sep 2013 12:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VChop+lufJK9 for ; Thu, 12 Sep 2013 12:20:46 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) by ietfa.amsl.com (Postfix) with ESMTP id BDD7C11E81CE for ; Thu, 12 Sep 2013 12:20:33 -0700 (PDT) Received: from splunge-2.local (70-90-161-117-ca.sfba.hfc.comcastbusiness.net [70.90.161.117]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.3/8.14.3/Debian-9.4) with ESMTP id r8CJKHWD025231 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Sep 2013 12:20:19 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1379013619; bh=JxBoafJzR7HA4cBzYFLmLMOs2kXVhCJUUHr52VLviE4=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=bhcjZUoTYJpf7CBGrE1dRLfq/pOajpzOCdCaXjlaWEp0pBx4Qid558AP9X7FVrim6 mG+QNCpaeLMPGrpgnAn4ZpMEeqmb66ovb4G1kLLcaFlbquJWg1V4X8SV4nsslYOIEF tiIoxLbu8KJeUhvyE2YQptUuPOgDkjj4ZGSyoLyI= Message-ID: <523213F1.7000005@bluepopcorn.net> Date: Thu, 12 Sep 2013 12:20:17 -0700 From: Jim Fenton User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: dcrocker@bbiw.net References: <5230F81A.2030901@bbiw.net> <52310222.6040601@dcrocker.net> In-Reply-To: <52310222.6040601@dcrocker.net> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: DKIM IETF WG , Apps Discuss Subject: Re: [apps-discuss] [ietf-dkim] Fwd: Request to move RFC 5617 (ADSP) to Historic X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 12 Sep 2013 19:20:47 -0000 This might be the right thing to do, but it seems like the more appropriate time might be to do this when DMARC becomes standards-track. I will note that vanilla, uncustomized SpamAssassin does implement ADSP, so there might be more checking of ADSP records than some realize. See, for example: http://wiki.apache.org/spamassassin/Rules/DKIM_ADSP_CUSTOM_MED -Jim P.S. I owe the DMARC folks a review of the DMARC spec, which I have begun and already have quite a few questions. I expect to complete this within a week. On 9/11/13 4:52 PM, Dave Crocker wrote: > Folks, > > Barry has agreed to sponsor the enclosed status change. > > He would like to see discussion formal request. > > (If you've already responded to my /in/formal query earlier today on the > dmarc@ietf list, please now lodge any formal comments you wish to make > on either of the two lists here. > > d/ > > > -------- Original Message -------- > Subject: Request to move RFC 5617 (ADSP) to Historic > Date: Wed, 11 Sep 2013 16:09:14 -0700 > From: Dave Crocker > Organization: Brandenburg InternetWorking > To: Barry Leiba , Pete Resnick > > > Folks, > > This is a formal request, to have DomainKeys Identified Mail (DKIM) > Author Domain Signing Practices (ADSP) (RFC 5617) moved to Historic status. > > It has garnered almost no deployment and use, in the 4 years since its > advancement to IETF Proposed Standard. > > In addition, newer work, DMARC, covers the same general email functional > area and already has garnered quite a bit of deployment and use. Hence > it will clarify things for the marketplace to remove standards status > from the apparently-competing, but actually-useless ADSP specification. > > Today I sent a query to the MAAWG Technical committee and the IETF DMARC > mailing lists, to assess support for the status change. Within only a > few hours, I've already seen quite a few +1s, and no -1s. > > Thanks. > > > d/ > From dhc@dcrocker.net Thu Sep 12 12:29:07 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B5E611E80F4 for ; Thu, 12 Sep 2013 12:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iRsR4BbC55rR for ; Thu, 12 Sep 2013 12:29:02 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4ADEA21F9FF2 for ; Thu, 12 Sep 2013 12:29:02 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r8CJSvYv019130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 12 Sep 2013 12:29:00 -0700 Message-ID: <523215E2.3010501@dcrocker.net> Date: Thu, 12 Sep 2013 12:28:34 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Jim Fenton References: <5230F81A.2030901@bbiw.net> <52310222.6040601@dcrocker.net> <523213F1.7000005@bluepopcorn.net> In-Reply-To: <523213F1.7000005@bluepopcorn.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Thu, 12 Sep 2013 12:29:00 -0700 (PDT) Cc: DKIM IETF WG , Apps Discuss Subject: Re: [apps-discuss] [ietf-dkim] Fwd: Request to move RFC 5617 (ADSP) to Historic X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 19:29:08 -0000 On 9/12/2013 12:20 PM, Jim Fenton wrote: > This might be the right thing to do, but it seems like the more > appropriate time might be to do this when DMARC becomes standards-track. 1. There is not going to be any change the adoption of ADSP between now and then. 2. I don't see any obvious reason for linking them. The mere fact that they are playing in roughly the same sandbox does not provide any obvious requirement for fate-sharing that I can see. 3. IF DMARC is never standardized, it still makes sense to deprecate ADSP. > I will note that vanilla, uncustomized SpamAssassin does implement ADSP, > so there might be more checking of ADSP records than some realize. See, > for example: > > http://wiki.apache.org/spamassassin/Rules/DKIM_ADSP_CUSTOM_MED There seems to be a pattern that has developed, of demanding that failure mean literally no adoption. It doesn't mean that. It means that it has no community traction. ADSP more than qualifies on the pragmatics of failure. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From fenton@bluepopcorn.net Thu Sep 12 13:02:57 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 110A121E8201 for ; Thu, 12 Sep 2013 13:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QiNTeljEaEkt for ; Thu, 12 Sep 2013 13:02:56 -0700 (PDT) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) by ietfa.amsl.com (Postfix) with ESMTP id 91C6B21E81F4 for ; Thu, 12 Sep 2013 13:02:56 -0700 (PDT) Received: from splunge-2.local (70-90-161-117-ca.sfba.hfc.comcastbusiness.net [70.90.161.117]) (authenticated bits=0) by v2.bluepopcorn.net (8.14.3/8.14.3/Debian-9.4) with ESMTP id r8CK2jAo025344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Sep 2013 13:02:46 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=supersize; t=1379016166; bh=KpHz1CyIJyLEQQHWt6yQpHNexBuL/WuC73G+0DD+SWM=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=NucU3dQPgkf26Hnv3WGC6rJ36ibnUxL5iHVlHL7WJbmtiGlBzas/dCvLdwGLiBOlp T5j+AbeD0eos5nv1pVVMl2wcjorffOqjuT+G9KY0t6r3+QhhU+BFbXyt0Ry7uPca3i Wqm+7A9lHANWo6EA+6LAGMVXuRm6hLn0seMIRzNk= Message-ID: <52321DE4.2050006@bluepopcorn.net> Date: Thu, 12 Sep 2013 13:02:44 -0700 From: Jim Fenton User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: dcrocker@bbiw.net References: <5230F81A.2030901@bbiw.net> <52310222.6040601@dcrocker.net> <523213F1.7000005@bluepopcorn.net> <523215E2.3010501@dcrocker.net> In-Reply-To: <523215E2.3010501@dcrocker.net> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: DKIM IETF WG , Apps Discuss Subject: Re: [apps-discuss] [ietf-dkim] Fwd: Request to move RFC 5617 (ADSP) to Historic X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 12 Sep 2013 20:02:57 -0000 On 9/12/13 12:28 PM, Dave Crocker wrote: > On 9/12/2013 12:20 PM, Jim Fenton wrote: > >> I will note that vanilla, uncustomized SpamAssassin does implement ADSP, >> so there might be more checking of ADSP records than some realize. See, >> for example: >> >> http://wiki.apache.org/spamassassin/Rules/DKIM_ADSP_CUSTOM_MED > > There seems to be a pattern that has developed, of demanding that > failure mean literally no adoption. It doesn't mean that. It means > that it has no community traction. ADSP more than qualifies on the > pragmatics of failure. This was a response to your statement to Barry and Pete, "It has garnered almost no deployment and use." If that comment was relevant, so is a comment that there is, in fact, some deployment. -Jim From barryleiba.mailing.lists@gmail.com Thu Sep 12 14:27:18 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED60421E80BB for ; Thu, 12 Sep 2013 14:27:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.978 X-Spam-Level: X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oi4KxO2twp0e for ; Thu, 12 Sep 2013 14:27:18 -0700 (PDT) Received: from mail-ve0-x231.google.com (mail-ve0-x231.google.com [IPv6:2607:f8b0:400c:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 1531A11E80F4 for ; Thu, 12 Sep 2013 14:27:18 -0700 (PDT) Received: by mail-ve0-f177.google.com with SMTP id db12so327538veb.22 for ; Thu, 12 Sep 2013 14:27:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=sb7rWbFFKGnHayd1/OSVu/VFjgu/Ss0j+4h8+7UD1A0=; b=dq6E3UKVxLGj6BeoF8yCT2NTqxMKjf1f2gtSTeAGE6CfFid83ZJmnPXgnEYfp8sd7A wjFg/YXOHMM5evqEALEZBLpUBlD5mxrQZ/OTxFjladBpOCvX/xWGJtaP32LS40v67jVR j9OogtWS7AbmW67K0t8c9PbUXpqlc06ZF7vSZbOUZoR4sIQjEJeGSKwaOjfH4N0seP3V P7RXInoikJSKVww/7bdEdkE9rwyEpjh0jSpEhps8M/Uf7nF5oqI7OBFHZDVn+L5qRL3d q+spvc70Qv+PXrEguCcpZg51CyHMSHAy0J/IsriHcWOlmqZV0GR+NS8QkNm+eJYxkog6 vZzw== MIME-Version: 1.0 X-Received: by 10.220.181.136 with SMTP id by8mr8599820vcb.11.1379021235421; Thu, 12 Sep 2013 14:27:15 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.215.16 with HTTP; Thu, 12 Sep 2013 14:27:15 -0700 (PDT) In-Reply-To: <5231B4C6.9000600@isdg.net> References: <5230F81A.2030901@bbiw.net> <52310222.6040601@dcrocker.net> <5231B4C6.9000600@isdg.net> Date: Thu, 12 Sep 2013 17:27:15 -0400 X-Google-Sender-Auth: G77qoZ4fxTFpgWDjgnK2zLvbdqA Message-ID: From: Barry Leiba To: Hector Santos Content-Type: text/plain; charset=ISO-8859-1 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [ietf-dkim] Fwd: Request to move RFC 5617 (ADSP) to Historic X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 12 Sep 2013 21:27:19 -0000 Addressing some technical issues here, and thanks for raising them. On Thu, Sep 12, 2013 at 8:34 AM, Hector Santos wrote: > -1 > > This will require a substantial review before any change of status is done > and should be done as part of WG working on Domain Policies. > > There is already substantial work with ADSP and APIs implemented and > deployed. We continue to get world wide usage of our ADSP zone record > generator wizard: > > http://www.winserver.com/public/wcadsp > > Logs can provided upon request. Commercial software exist that has it > deployed -- Ours is one of them. There's no question that code is out there to process ADSP records. I'm willing to have a conversation about this point, but: I don't think that code in the field is what makes us decide that a standard is now Historic, though RFC 2026 is vague on this point, saying only this: A specification that has been superseded by a more recent specification or is for any other reason considered to be obsolete is assigned to the "Historic" level. I think the points in this case are that (1) there's little or no evidence that the standard is providing the benefit that it's meant to provide, and (2) we have rough consensus that we no longer want to recommend the specification as a current standard. Part (2) is what I assign to "for any other reason considered to be obsolete." Therefore, discussion about whether (1) and (2) are true is fully within scope here. That said, I'd like to see arguments not that code to assess ADSP is deployed, or even very widely deployed, but that the protocol is providing benefits commensurate with keeping it as a current standard. Data that supports that view is welcome. Barry, Applications AD From hsantos@isdg.net Thu Sep 12 14:29:33 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1936711E813B for ; Thu, 12 Sep 2013 14:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.268 X-Spam-Level: X-Spam-Status: No, score=-102.268 tagged_above=-999 required=5 tests=[AWL=-0.269, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VzwgBfJY1knf for ; Thu, 12 Sep 2013 14:29:27 -0700 (PDT) Received: from ntbbs.santronics.com (secure.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id A669A11E80E2 for ; Thu, 12 Sep 2013 14:29:26 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1754; t=1379021361; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=ITJS5sgD9dx3LsgE9Zp5P77hi6k=; b=r3qRNcu+pekJSovcgQMv wAcCHXm5FR2hOjgc1723t3uyD+QbgB5UMn1dqQWFMjXe+YtRxdW/wjIp7pbV44Xv 8JHkhg8W+wTPKa0kVCqvPmKKmpNTHi2DAbdxTUCuQXlr9/g3yAFQ8bhx77bxG3Dn AUOUfbBdhC73A/J2bUQuS7g= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Thu, 12 Sep 2013 17:29:21 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from hector.wildcatblog.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1188886695.30534.3424; Thu, 12 Sep 2013 17:29:19 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1754; t=1379021011; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=q0+B9bi VyGQsWSqxVihWvBk3loLdaOxihcfC5TVOmM0=; b=Ri0fvrDQY6Q3fAA93XezbHT Ld0Uucu+b9tQOxA/5W4OESmggsPeptCsN6RacmLHSWmIuWUZYyavvNhQSrcFwHLN ykAxYUZEGBUtP2mN3mi1Ae6Znx9tcFpcznEPRurBUtjXRLdQTrokDUft6wszf/Sb WsUv3DaDqTBEy8ApUwHE= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Thu, 12 Sep 2013 17:23:31 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 635292300.9.2540; Thu, 12 Sep 2013 17:23:30 -0400 Message-ID: <52323232.5050009@isdg.net> Date: Thu, 12 Sep 2013 17:29:22 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: DKIM IETF WG References: <5230F81A.2030901@bbiw.net> <52310222.6040601@dcrocker.net> <523213F1.7000005@bluepopcorn.net> <523215E2.3010501@dcrocker.net> In-Reply-To: <523215E2.3010501@dcrocker.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Apps Discuss Subject: Re: [apps-discuss] [ietf-dkim] Fwd: Request to move RFC 5617 (ADSP) to Historic X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 12 Sep 2013 21:29:33 -0000 On 9/12/2013 3:28 PM, Dave Crocker wrote: > > There seems to be a pattern that has developed, of demanding that > failure mean literally no adoption. It doesn't mean that. It means > that it has no community traction. ADSP more than qualifies on the > pragmatics of failure. > > d/ > The pragmatics of failure also can include implementations but see zero payoff in the field. Pure wasted redundant overhead in DNS calls and crypto processing is all that is highly measurable. In our implementation, DKIM and VBR certainly fits in that category. Yet, we did it for its "marketing" value. ADSP is also implemented and deployed. The payoff measured is still another matter. Even if ADSP domains have DKIM=DISCARDABLE, its been hard to add logic to reject or negatively classify failed DKIM messages. Yet, you don't how sites local policies filters are done. Sites and even users might just apply an ADSP DKIM=DISCARDABLE policy rejection to certain high value domains, like PAYPAL.COM but not others. If Authentication-Results headers are used, what is done locally is a matter of local policy. What is to say the same is not possible with DMARC with its p=reject action attribute? I haven't seen any MUA show a different view yet, but I am sure there are some in the field. Some have an icon or indicator but its not always profound. We have the same issue with 3rd party signing problems with DMARC. ADSP has extensions such as TPA, ATPS and ASL that attempts to address authorized 3rd party signatures. There is interest and deployments of these extensions. DMARC will not attempt to address 3rd party signatures. Whats to stop an DMARC extension to emerge which can piggy back off the _DMARC record? -- HLS From hsantos@isdg.net Fri Sep 13 07:04:48 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B782D11E80F1 for ; Fri, 13 Sep 2013 07:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.282 X-Spam-Level: X-Spam-Status: No, score=-102.282 tagged_above=-999 required=5 tests=[AWL=-0.547, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LZjfgjOxaBmX for ; Fri, 13 Sep 2013 07:04:43 -0700 (PDT) Received: from ntbbs.winserver.com (ftp.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 33D2E21F9D62 for ; Fri, 13 Sep 2013 07:04:42 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3974; t=1379081077; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=O3ET7kt/4lWuCkz9HLImbbcmEnc=; b=auSXTyRSrWPJ1w2058ha 52kHfbd+NP2X6DBSTevYuj4a3I4l6NxJ7T06F4RFJOpAtXg3joWMxBnHNFRKEMeR nrrVdkbndPDneqp3MYb7HN0dZLs3bmL8lTFCcsFbKqnZXuP6Aoqyl5SHaUs/jIoH 4P8KO4crIlfDj+k85YwNRSI= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Fri, 13 Sep 2013 10:04:37 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from hector.wildcatblog.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1248602630.31800.5204; Fri, 13 Sep 2013 10:04:36 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3974; t=1379080723; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=CV1+KMz x29XYlbcOb41+NpWIWZuLbEJoCfQmNkOTWqA=; b=o3BE4cMC66H93CiNsvFG0ju e6o1JYeS1VZzvIrbzh17uJ+g4YAnVysaPVfPZqV6cNBXFjQ/iqcXLwr1yVzo+33H uERRVNbA7LIuKXJVK3pGh4rS7w8/N10wSH87PpxxiD8zgUIm5JrxaYub/MLO6nbC CF5GD53ZTJT12PHlh78k= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Fri, 13 Sep 2013 09:58:43 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 695003534.9.4684; Fri, 13 Sep 2013 09:58:42 -0400 Message-ID: <52331B68.1020903@isdg.net> Date: Fri, 13 Sep 2013 10:04:24 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Barry Leiba References: <5230F81A.2030901@bbiw.net> <52310222.6040601@dcrocker.net> <5231B4C6.9000600@isdg.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [ietf-dkim] Fwd: Request to move RFC 5617 (ADSP) to Historic X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Sep 2013 14:04:48 -0000 On 9/12/2013 5:27 PM, Barry Leiba wrote: > There's no question that code is out there to process ADSP records. > I'm willing to have a conversation about this point, but: I don't > think that code in the field is what makes us decide that a standard > is now Historic, though RFC 2026 is vague on this point, saying only > this: > > A specification that has been superseded by a more recent > specification or is for any other reason considered to be obsolete is > assigned to the "Historic" level. > > I think the points in this case are that (1) there's little or no > evidence that the standard is providing the benefit that it's meant to > provide, and (2) we have rough consensus that we no longer want to > recommend the specification as a current standard. Part (2) is what I > assign to "for any other reason considered to be obsolete." > > Therefore, discussion about whether (1) and (2) are true is fully > within scope here. > > That said, I'd like to see arguments not that code to assess ADSP is > deployed, or even very widely deployed, but that the protocol is > providing benefits commensurate with keeping it as a current standard. > Data that supports that view is welcome. > > Barry, Applications AD Hi Barry, in all honesty I had difficulty trying to figure out why the burden should be on deployments to answer your question. Are we asking if the proof of concept is still valid? Does it have a payoff, a useful utility? We know all the answers was and still is yes. The issue has always been two folds: First, how to leverage DKIM signatures in two layers: - Deterministic Domain Policy Layer to describe the practice of domain signing and the failure points for the operations. - For valid signatures, use a (futuristic) reputation (3rd Party Trust Service) concept to vouch for the signature and hence message. Both, individually or integrated, has benefits commensurate with seeking a standard, so both were pursued. DKIM has no reputation layer yet in wide practice but the modeling is being done. Thats still all in the air. In the mean time, currently, DKIM only has a single protection layer and that is with ADSP (with also ATPS, ACL). Second, the most critical issue was about how to apply and scale 3rd party DKIM signing controls for the larger systems. ADSP stripped down SSP to remove 3rd party controls. This was a unpopular move. The ADSP extensions ATPS, ASL and TPA helped correct this operational role by offering again 3rd party signature authorization policies for domains to use for help protect there DKIM signing investment. Shouldn't the burden be on the proposer to provide an applicability and impact study how DKIM will be impacted by making ADSP obsolete and also replace it with an alternative? This is about DKIM. Why should all the IETF-MAN-YEARS be lost, require many of the DKIM related RFCs to be modified, updated also made obsolete where there is no apparent IETF alternative solution? I guess I am not sure what you are looking for, if (significant) "running code" is not good enough any more. This move will surely set a precedence to steer early adopters away from IETF proposals until it finally completed. This will only allow the largest to dictate the direction of technology with lesser regard to the wider community of technology users. It feels all wrong. This feels nothing more to me as a competing solution being proposed with ADSP apparently in the way. Thats not a better idea if it provided a better solution. It does not. Same above two issues still apply; lack of DKIM protection and 3rd party controls. Keep in mind that replacing ADSP with DMARC will be advocating a _DMARC migration path for ADSP. If it does not, then this should mean to a greater extent an applicability and impact study should be done before pulling the rug from under ADSP publishers and receivers feet. Thanks -- HLS From sm@resistor.net Fri Sep 13 10:55:44 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A202C11E80FC for ; Fri, 13 Sep 2013 10:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LYdj+rv4FN8H for ; Fri, 13 Sep 2013 10:55:43 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 459CB21F9FCF for ; Fri, 13 Sep 2013 10:55:42 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r8DHtVFh028752; Fri, 13 Sep 2013 10:55:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1379094935; bh=T7RzvxZXAcZQ7PeNLXqZej1c6BwU+FCP9LcDDGpdscc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=xSPgIFGuxmjjJ5lBNGCo9aaP4JiYTGGzSfkZlH/QI/duYnWK+Xotjz6ACqiJm0nwg 9KqF8XFWXUGuq0C9iGA/9WTgZy69k04PZEHEq7cp9zLSdi7L08oriPYaX9fnX1CUlv LUjYTN/JK2fl0Sx2809L+u8fPoFhrMQNyvRo+w3U= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1379094935; i=@resistor.net; bh=T7RzvxZXAcZQ7PeNLXqZej1c6BwU+FCP9LcDDGpdscc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=3Zh5jzx/2hnq2751Iqe9GL0mGAo0g9u16xkT/+lj50tE1RQ8zhtoucsTASZDXiMsK k2PoBeIHbXTnWOO35YQubMUl3TJdzY0FCp+KSvmAZFN9/AoUFiRdTbxcm/sGyeiro5 B5FzzaFMTxa/3Xb8OBpEjlOUDuRIO/CejeKFRTKs= Message-Id: <6.2.5.6.2.20130913102609.0c70bb28@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 13 Sep 2013 10:55:08 -0700 To: apps-discuss@ietf.org From: SM In-Reply-To: <52310222.6040601@dcrocker.net> References: <5230F81A.2030901@bbiw.net> <52310222.6040601@dcrocker.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: dcrocker@bbiw.net Subject: Re: [apps-discuss] Fwd: Request to move RFC 5617 (ADSP) to Historic X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Sep 2013 17:55:45 -0000 At 16:52 11-09-2013, Dave Crocker wrote: >Date: Wed, 11 Sep 2013 16:09:14 -0700 [snip] >This is a formal request, to have DomainKeys Identified Mail (DKIM) >Author Domain Signing Practices (ADSP) (RFC 5617) moved to Historic status. In my opinion RFC 5617 has not seen significant deployment. There are instances where the signing practice is overridden by local considerations. Based on that I don't think that it is worth pursing further standardization and move the RFC to Historic. There is likely some clean-up work to do. I haven't looked into the paperwork. That may require a RFC. Regards, -sm From johnl@iecc.com Fri Sep 13 11:20:58 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6CDD11E81B8 for ; Fri, 13 Sep 2013 11:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.844 X-Spam-Level: X-Spam-Status: No, score=-102.844 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sv7nIDkRwrrb for ; Fri, 13 Sep 2013 11:20:53 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id B13ED21E80F3 for ; Fri, 13 Sep 2013 11:20:49 -0700 (PDT) Received: (qmail 85629 invoked from network); 13 Sep 2013 18:20:47 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 13 Sep 2013 18:20:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=5233577f.xn--i8sz2z.k1309; i=johnl@user.iecc.com; bh=UAj7XSnD6PriB95FN7bfS9+kuWYKkwcaQTJZaCo6nkk=; b=jOagPfXZMXiraC0FHFtNRVSLKYqKEIqpCUq2U/KLHY7DM6JHgeWxh672oBkl8lTvp6Ee7BPNbbt276DocCqFtXgTe1P8zVGkvSp/iZN7t+yP+9eOnecoEph6d8HobQwlwO169RMNTAMRXXUZsDtX2bDNh45mUTE3dg40PUmtrjzTvgfcGeiyoz+4DE64PzYu3xdI51UZX49gKQNXHduNXgYC+T2yJphcYlM819ckLfYtUk9Mdqi3zsqpL9Y/rSmq DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=5233577f.xn--i8sz2z.k1309; olt=johnl@user.iecc.com; bh=UAj7XSnD6PriB95FN7bfS9+kuWYKkwcaQTJZaCo6nkk=; b=lcz5HQNIUDlGvK+/aYF5GO69EVj9+5bhnBcfVy2XkWlCyFWEXncI4FMLNsBBkK9vi+YxGazMLD9rEbzLfTnEEWW5btW//IV4F++LWzXSmuBejYfEpEwfKpYo8TGIptxUE1MkDdD8TJ2YGfHgSmDdC+4rxomDmipGshfgz9yOVsP/vcedKzkDFFKXn56XSh1qmp4nG5rdhCdhDQ8Q+KA0cQbVMnBTm3b5+SF6wbRXTQIQRbx83IPyO9WZ5R8Mv0r+ Date: 13 Sep 2013 18:20:24 -0000 Message-ID: <20130913182024.76067.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <6.2.5.6.2.20130913102609.0c70bb28@resistor.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [apps-discuss] Fwd: Request to move RFC 5617 (ADSP) to Historic X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 13 Sep 2013 18:20:58 -0000 >There is likely some clean-up work to do. I haven't looked into the >paperwork. That may require a RFC. I don't think so. We defined it as an entirely optional add-on to DKIM, and there's no reference to it in RFC 6376. R's, John From barryleiba.mailing.lists@gmail.com Fri Sep 13 19:27:09 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A44A721F9C12 for ; Fri, 13 Sep 2013 19:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.919 X-Spam-Level: X-Spam-Status: No, score=-102.919 tagged_above=-999 required=5 tests=[AWL=1.059, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HBvRmRSl3ui5 for ; Fri, 13 Sep 2013 19:27:09 -0700 (PDT) Received: from mail-ve0-x230.google.com (mail-ve0-x230.google.com [IPv6:2607:f8b0:400c:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id A69BF21F9A90 for ; Fri, 13 Sep 2013 19:27:08 -0700 (PDT) Received: by mail-ve0-f176.google.com with SMTP id jx11so1613943veb.35 for ; Fri, 13 Sep 2013 19:27:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=h1YjjW+wmS76OtbB9KOBeBs4VQPPOfpTYokhYXE7niA=; b=DbRU9687zNI1kzCNaGSUFIQ4DLvOVMIE2LbLjTh3rnyRMDdNGF8WOvjSK0mdpXR/PF GWJ10Lh8BWy95JUYO5UbS5mRRPi+1LrAgrWaOgnSCHgfY4z3DnufPAQkDjBlf7veG6dj 2rgUsmkY9xFfZee0Z4/Sa1ibNNn2np3jgpyX+ineolVFJZ8DccQ0TZ3gtHfPLi/tKqwe w2ZFedtDNsPxxNWNcPTUPHM0GC/BJJmcGa/TOALU2MyrSLvlsDqFtxsovUoGuQLz4H2I nbYf9oZwynMn3hI4+f2t89RhxpaMAcIq3amFegrK+JEUl7oUjF69YIe5cJ6fvOBvcKH8 7/hQ== MIME-Version: 1.0 X-Received: by 10.52.37.69 with SMTP id w5mr19694vdj.32.1379125626109; Fri, 13 Sep 2013 19:27:06 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.215.16 with HTTP; Fri, 13 Sep 2013 19:27:05 -0700 (PDT) In-Reply-To: <52331B68.1020903@isdg.net> References: <5230F81A.2030901@bbiw.net> <52310222.6040601@dcrocker.net> <5231B4C6.9000600@isdg.net> <52331B68.1020903@isdg.net> Date: Fri, 13 Sep 2013 22:27:05 -0400 X-Google-Sender-Auth: sdPiHTT3_rsJxC3wKYfy2z8qBz8 Message-ID: From: Barry Leiba To: Hector Santos Content-Type: text/plain; charset=ISO-8859-1 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [ietf-dkim] Fwd: Request to move RFC 5617 (ADSP) to Historic X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 14 Sep 2013 02:27:09 -0000 >> That said, I'd like to see arguments not that code to assess ADSP is >> deployed, or even very widely deployed, but that the protocol is >> providing benefits commensurate with keeping it as a current standard. >> Data that supports that view is welcome. > > Hi Barry, in all honesty I had difficulty trying to figure out why the > burden should be on deployments to answer your question. That's a fair question. There are a bunch of people saying that they are not seeing a benefit from ADSP. Those who are saying that include some large email handlers and some high-profile phishing targets, so we have it from both sides of the ADSP pond -- the ones trying to filter and the ones trying to protect their domain identities. They're all saying that ADSP isn't doing it. But when things aren't happening, it's difficult to come up with hard numbers. They could show us what ADSP isn't helping them block, but we wouldn't know what else ADSP might be helping them block. Given that, someone who says that ADSP *is* helping to block this stuff... is the one who can provide evidence for that. If we can see some numbers showing what was blocked with the help of ADSP *that would have gotten through without it*, we can consider that in determining what benefit ADSP is providing. That's the sort of thing I'm asking for: arguments, backed by whatever evidence we have, that there *is* a benefit from having ADSP as a standard, and that we should therefore not retire it. In the rest of your note you talk about why ADSP is here: what it's intended to accomplish. We know that... but the discussion that's on the table is that it's not accomplishing it. Yes, you're right: ADSP is what we have. Where is the evidence that it's working? As to IETF work lost, well, there are many IETF standards that have not been successful, and that have withered and been, arguably, lost work. It happens. We usually just leave them dead on the vine. In this case, we've seen real-Internet demonstrations that mis-applied ADSP has caused real damage, in lost mail and screwed-up mailing lists. Officially making ADSP Historic will discourage domains from publishing ADSP records, if there's no significant benefit from them, but a demonstrated potential for damage. Don't read from that that I'm supporting this move; I'm not supporting either side of it. It's my job to judge the result of the conversation. Provide some evidence of benefit, and it'll be considered. Who knows?: you might sway some who have already said "+1" to making it Historic. And I'll repeat: we're judging ADSP on its own here, not in comparison with anything else that might have one more letter in its name. If we can see value in ADSP, that will matter, regardless of any alternatives. It's not a "competing solution" thing, so let's please have no more of that. Barry From superuser@gmail.com Fri Sep 13 22:22:15 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F04E511E80E6 for ; Fri, 13 Sep 2013 22:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.423 X-Spam-Level: X-Spam-Status: No, score=-2.423 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y29-cxpKYcjO for ; Fri, 13 Sep 2013 22:22:15 -0700 (PDT) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 3969C11E80D1 for ; Fri, 13 Sep 2013 22:22:15 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id b13so1859432wgh.11 for ; Fri, 13 Sep 2013 22:22:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PzZa5aFtQxudkfim950xwBLd5t1K3lh+M2JEwT2yCSI=; b=engf5xrUTRS7lls7uO5m7VDb1GlPQ25oGSLCH07Unvts2qES9Rf3qcAFsk+Jvtk3/J 4drY50SMS0TcEZWnBYGXm3AsS6sNiKeacH22abJBvlWDYE34zSGr3iLpNztHW3H3xc1q ODxYE5tlP1jATOlbiTI69BDpoxsLHwMJ27LblQFwbLlKT9NNj95zt8UeeKIhHrpJkSn1 cItcxwVPh2tcaGazFf/dMRF9Po8aXlL3JK0teUhMoSGSg5oWl/Q+lEIcHobd19jb4ITv Hp/uwNR0R+wka6OUxbY12JyVCxDaeXCNZ/GA8++coM3HwqKs3UDd4RHMYQDt3IE2s3FO 09LQ== MIME-Version: 1.0 X-Received: by 10.180.184.107 with SMTP id et11mr5258601wic.60.1379136133120; Fri, 13 Sep 2013 22:22:13 -0700 (PDT) Received: by 10.180.106.169 with HTTP; Fri, 13 Sep 2013 22:22:12 -0700 (PDT) In-Reply-To: References: <5230F81A.2030901@bbiw.net> <52310222.6040601@dcrocker.net> <5231B4C6.9000600@isdg.net> <52331B68.1020903@isdg.net> Date: Fri, 13 Sep 2013 22:22:12 -0700 Message-ID: From: "Murray S. Kucherawy" To: Barry Leiba Content-Type: multipart/alternative; boundary=001a11c227ee4fca3c04e6512723 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [ietf-dkim] Fwd: Request to move RFC 5617 (ADSP) to Historic X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 14 Sep 2013 05:22:16 -0000 --001a11c227ee4fca3c04e6512723 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Sep 13, 2013 at 7:27 PM, Barry Leiba wrote: > There are a bunch of people saying that they are not seeing a benefit > from ADSP. Those who are saying that include some large email > handlers and some high-profile phishing targets, so we have it from > both sides of the ADSP pond -- the ones trying to filter and the ones > trying to protect their domain identities. They're all saying that > ADSP isn't doing it. > An important thing to consider, too, is the observation that ADSP actually causes damage. Consider its interaction with mailing lists, for example. There hasn't been a workable solution provided to this problem, and the damage also isn't theoretical. If it has serious damage possibilities and no noteworthy uptake, it seems unlikely to enjoy any sudden adoption even if there's ample code out there that actually implements it. OpenDKIM ships with ADSP support in both the library and the filter and has since ADSP was in development. I'm going to ask on our mailing lists whether anyone's using it and seeing real benefit from it. I'll report back any useful replies. -MSK --001a11c227ee4fca3c04e6512723 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Sep 13, 2013 at 7:27 PM, Barry Leiba <barry= leiba@computer.org> wrote:
There are a bunch of people saying that they= are not seeing a benefit
from ADSP. =A0Those who are saying that include some large email
handlers and some high-profile phishing targets, so we have it from
both sides of the ADSP pond -- the ones trying to filter and the ones
trying to protect their domain identities. =A0They're all saying that ADSP isn't doing it.

An important t= hing to consider, too, is the observation that ADSP actually causes damage.= =A0 Consider its interaction with mailing lists, for example.=A0 There hasn= 't been a workable solution provided to this problem, and the damage al= so isn't theoretical.

If it has serious damage possibilities and no noteworthy upt= ake, it seems unlikely to enjoy any sudden adoption even if there's amp= le code out there that actually implements it.

OpenDKIM ships with A= DSP support in both the library and the filter and has since ADSP was in de= velopment.=A0 I'm going to ask on our mailing lists whether anyone'= s using it and seeing real benefit from it.=A0 I'll report back any use= ful replies.

-MSK
--001a11c227ee4fca3c04e6512723-- From apps-discuss@lapsedordinary.net Sat Sep 14 07:48:24 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9211621E8121 for ; Sat, 14 Sep 2013 07:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F6dMtGkgABav for ; Sat, 14 Sep 2013 07:48:20 -0700 (PDT) Received: from mail.lapsedordinary.net (thinksmall.vps.bitfolk.com [85.119.83.85]) by ietfa.amsl.com (Postfix) with ESMTP id 3A3F311E8195 for ; Sat, 14 Sep 2013 07:48:20 -0700 (PDT) Received: by mail.lapsedordinary.net (Postfix, from userid 1000) id 89D4D34133; Sat, 14 Sep 2013 15:37:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lapsedordinary.net; s=mail; t=1379173066; bh=EtcJFOGgYaELhmY74DW50otqo6+KM+FKQnxWpDTQ864=; h=Date:From:To:Subject:In-Reply-To:Message-ID:References: MIME-Version:Content-Type; b=db8moVaw4v4XZl6IlPpUFpR0VQCXCUyvE/s/fhzm8De8HR7eKGLDwKS7FtK+sojlS 7jf1vLDLQzfRRBwkAcY8aAfhT482Zb3BoJglwQyhRO6onCaO4mf9hQ5zxwYqfON8nM 2sGNkZzp3tjV7hKC33Cq+MSMyHYXA9TVUEO/K+fI= Received: from localhost (localhost [127.0.0.1]) by mail.lapsedordinary.net (Postfix) with ESMTP id 8780F34132 for ; Sat, 14 Sep 2013 15:37:46 +0000 (UTC) Date: Sat, 14 Sep 2013 15:37:46 +0000 (UTC) From: Martijn Grooten X-X-Sender: martijn@home.lapsedordinary.net To: "apps-discuss@ietf.org" In-Reply-To: Message-ID: References: <5230F81A.2030901@bbiw.net> <52310222.6040601@dcrocker.net> <5231B4C6.9000600@isdg.net> <52331B68.1020903@isdg.net> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="2002081107-502709292-1379173066=:5087" Subject: Re: [apps-discuss] [ietf-dkim] Fwd: Request to move RFC 5617 (ADSP) to Historic X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 14 Sep 2013 14:48:24 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --2002081107-502709292-1379173066=:5087 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT On Fri, 13 Sep 2013, Murray S. Kucherawy wrote: > An important thing to consider, too, is the observation that ADSP > actually causes damage.  Consider its interaction with mailing lists, > for example.  There hasn't been a workable solution provided to this > problem, and the damage also isn't theoretical. +1 And +1 therefore to the request to have RFC 5617 moved to history. Martijn. --2002081107-502709292-1379173066=:5087-- From johnl@iecc.com Sat Sep 14 08:27:09 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC0F11E819E for ; Sat, 14 Sep 2013 08:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.807 X-Spam-Level: X-Spam-Status: No, score=-102.807 tagged_above=-999 required=5 tests=[AWL=-0.208, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FlCdybCBPgek for ; Sat, 14 Sep 2013 08:27:00 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id A07F411E80F6 for ; Sat, 14 Sep 2013 08:26:58 -0700 (PDT) Received: (qmail 75847 invoked from network); 14 Sep 2013 15:26:57 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 14 Sep 2013 15:26:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=52348041.xn--3zv.k1309; i=johnl@user.iecc.com; bh=15CIv4uXL/qHcicEnqa2n+AVdcQFmVAMVJVLpe4At3k=; b=XrAMiFsM+/hztbPfuj1nFXUhj7kyxprjuUVx23PaS29oHrcoQOC1Mc4wPWVyWlrnXwHoe4Yf4rObecEO/1e0wsipH1PMBleXvcPatPcghJ6otGGZTLqCPI5D7HQigxiRIAbIuDTVXFu0e6nineZE1dtr+KAmuRgFHyHbitAB3VztjcKzowNS44ocg8QhSUD7yZ7EHdlt05mnLo+eypP9FCYxWlj+Y7oX3qjxgNUEdjTXzCd94eMOhvo/gJvj6ol+ DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=52348041.xn--3zv.k1309; olt=johnl@user.iecc.com; bh=15CIv4uXL/qHcicEnqa2n+AVdcQFmVAMVJVLpe4At3k=; b=G5nhXR98mwzLgN/EfyXdsmeIQc42idCv65buUWqpI1ZsD+1vf93AMyKpLYgGHUR+GGiXH4VENEsgaAP41JfXO5+84k4xSgqRTGhQrqZCh4owr3uI8TDFLgF6CrvuBHBSZYDSuNP3h9wOlWOTUFb5qpzeP36y99/LoVJhw08m3eMG9XOQRE9X9YQDGZCCElFOYQcp8NfQpsnN/hp8E7bXpYCbYaJjNBJDlaAw6llgzbCvrGZxPgbETi50AbVJo2wH Date: 14 Sep 2013 15:26:35 -0000 Message-ID: <20130914152635.85382.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [apps-discuss] [ietf-dkim] Fwd: Request to move RFC 5617 (ADSP) to Historic X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 14 Sep 2013 15:27:09 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >OpenDKIM ships with ADSP support in both the library and the filter and has >since ADSP was in development. I'm going to ask on our mailing lists >whether anyone's using it and seeing real benefit from it. I'll report >back any useful replies. I see that there are still ADSP records for paypal.com and paypal.co.uk, so you might start there. On my own DNS server, I see a certain number of lookups for _adsp records, but I also see some for _ssp and _policy, so I suspect there's a lot of ancient software running on autopilot. If anyone has contacts at the University of Pennsylvania, I see a few _adsp lookups from DNS hosts at upenn.edu. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (FreeBSD) iEYEARECAAYFAlI0gD8ACgkQkEiFRdeC/kWcpwCfWqhdn9vPRjloyOE/Wzys2zCt dMwAn1lROw5htIL1pvYW21EpFgKe6FXT =rFKA -----END PGP SIGNATURE----- From sm@elandsys.com Sat Sep 14 14:29:58 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2406C11E816F for ; Sat, 14 Sep 2013 14:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id os4Hv0QVLWgj for ; Sat, 14 Sep 2013 14:29:57 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 83BDE11E80D3 for ; Sat, 14 Sep 2013 14:29:57 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.134.26]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r8ELThN3027842 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Sep 2013 14:29:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1379194194; bh=oizwJ8CF1OnNtExydrDwAsj3wxsz82W9eeU6hNwCjyc=; h=Date:To:From:Subject; b=BA2XqrDWO/mB07/3pdj79PCEnAcYoDz4QTdB1ur2BA9osI40tl9usUMRdwc7eFEqG 7gI1BlMZwgj3BMfzLNfu/dvG8n0d0UBWTt51shImuCoDMylARWUBGqSGZ03uwSiabk hzMY9A1aglKw/s/EV5235WT9t4c0QRjUKjdAYSOQ= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1379194194; i=@elandsys.com; bh=oizwJ8CF1OnNtExydrDwAsj3wxsz82W9eeU6hNwCjyc=; h=Date:To:From:Subject; b=CbQ3xhGWsI8ktyKtIZGVnCDrgHssUf4g8VwBv7GWj1UhshmGuLhguHX1u9twxgbKx vlnG5ve4vtxVkEkDVwmEq9Hu3YFNi0/pRkqcJ9ZlMqkI1AzNv9ShV+fSt8OWzVo0tr S2+0N/gqeh7xDqwcjdNuTxhE3QMWc0AW97SKS3KA= Message-Id: <6.2.5.6.2.20130914142312.0b968c10@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 14 Sep 2013 14:29:01 -0700 To: draft-ietf-appsawg-malformed-mail.all@tools.ietf.org, apps-discuss@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [apps-discuss] Document Shepherd review of draft-ietf-appsawg-malformed-mail-07 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 14 Sep 2013 21:29:58 -0000 Hello, Here's my review of draft-ietf-appsawg-malformed-mail-07. Sorry for the long delay in getting this out. The draft is almost ready for publication as Informational RFC. There are a few minor changes not included in this message which I discussed about with the authors. In Section 1.2: "It is important to understand that this work is not an effort to endorse or standardize certain common malformations. The code and culture that introduces such messages into the mail stream needs to be repaired, as the security penalty now being paid for this lax processing arguably outweighs the reduction in support costs to end users who are not expected to understand the standards." Section 1 quotes Postel's directive. I read that directive as favoring interoperability as it is not possible to fix the code already in the wild. I don't think that it is about support costs. It is more about both of us being able to communicate with each other through, for example, email. It might be better to argue that the malformations give more leeway to security issues. Regards, S. Moonesamy From sm@elandsys.com Sat Sep 14 17:09:52 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E70511E80E2; Sat, 14 Sep 2013 17:09:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.878 X-Spam-Level: X-Spam-Status: No, score=-101.878 tagged_above=-999 required=5 tests=[AWL=-0.675, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qdYrw6snI+WY; Sat, 14 Sep 2013 17:09:50 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E35021F9F23; Sat, 14 Sep 2013 17:09:50 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.134.26]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r8F09X5H024675 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Sep 2013 17:09:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1379203787; bh=1otWdXNyZqnoNew51eYAHLTVIfbtR3UoiPW3vs3bI6o=; h=Date:To:From:Subject:Cc; b=giMK4tTEUh8uWefjs7Y061nUVUd3QbnCYQ+GqEVazHLhc2LST+V6uGMlz3XFRgCLg QalwdIYjLzNnF665a6GUEDDMlKaZ8zvo6BhBlosTC1pDPE+vd/uxs7/VdatxUZLCW4 N34cHFWQpEN+fmBqQPyUo47fEpX57Osq0uPtBmF4= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1379203787; i=@elandsys.com; bh=1otWdXNyZqnoNew51eYAHLTVIfbtR3UoiPW3vs3bI6o=; h=Date:To:From:Subject:Cc; b=Vm8Fau6mTfGiqvFrS0fSekC+2cPjkDFL+pgdWLp2mJn3N7gXdDd/dz0l/otEPkNQ5 acebjfFQqudI+Iy7EBYYiT9KYnk3osNh2g9YhvZiHdaSibM5BffaDG210A3qDpZV9O 8vng6I/BpKVkncS51OUUEXvdfDtbCLjfHZdh5O90= Message-Id: <6.2.5.6.2.20130914143222.0b9590f0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 14 Sep 2013 17:06:52 -0700 To: apps-discuss@ietf.org, draft-ietf-homenet-arch.all@tools.ietf.org, iesg@ietf.org From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: homenet@ietf.org Subject: [apps-discuss] APPSDIR review of draft-ietf-homenet-arch-10 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 15 Sep 2013 00:09:52 -0000 I have been selected as the Applications Area=20 Directorate reviewer for this draft (for=20 background on APPSDIR, please see=20 http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ). Please resolve these comments along with any=20 other Last Call comments you may receive. Please=20 wait for direction from your document shepherd or=20 AD before posting a new version of the draft. Document: draft-ietf-homenet-arch-10 Title: Home Networking Architecture for IPv6 Reviewer: S. Moonesamy Review Date: September 14, 2013 IETF Last Call Date: August 8, 2013 IESG Evaluation: September 26, 2013 Summary: This draft is not ready for publication as an Informational RFC. The document defines a general architecture for=20 IPv6-based home networking, describing the=20 associated principles, considerations and=20 requirements. It draws parallels with IPv4=20 scenarios to explain the proposed architecture to=20 the reader. There is an assumption that the IPv6=20 home network runs as an IPv6-only or dual-stack network. I am not sure whether application developers will=20 be able to understand the document as it is=20 written from a routing perspective. I found the=20 document confusing. After reading the document I=20 am left with a sense that it tried to solve the=20 problems the working group participants could=20 think about instead of taking an architectural view of IPv6 home networking. Major issues: I am listing these issues as major mainly for the=20 attention of the Applications Area Directors. According to RFC 1958: "4.2 A single naming structure should be used." This document introduces a "Locally Qualified=20 Domain Name" in Section 1.1. Section 3.7.3=20 refers to it as a "Unique Locally Qualified=20 Domain Name". There is also a mention of=20 "Ambiguous Local Qualified Domain Name space" in that section. The document mentions ".sitelocal (or an=20 appropriate name reserved for the purpose)". Quoting RFC 6761: "Are writers of application software expected to make their software recognize these names as special and treat them differently? In what way?" In Section 3.7.7: "Similarly the search domains for local FQDN-derived zones should be included." Why is the document recommending search domains? Minor issues: In Section 2.6: "It is likely that IPv6-only networking will be deployed first in 'greenfield' homenet scenarios, or perhaps as one element of an otherwise dual-stack network." Given that this is an architectural document=20 intended for a wide audience it would be clearer=20 to the non-English reader to have a description instead of "greenfield". In Section 3.2.3: "A general recommendation is to follow the same topology for IPv6 as is used for IPv4, but not to use NAT." As a non-actionable comment, there are benefits=20 to such an approach, i.e. IPv6 is like IPv4. The=20 drawback is that it may encourage an IPv4 mindset. "In some cases IPv4 home networks may feature cascaded NATs. End users are frequently unaware that they have created such networks as 'home routers' and 'home switches' are frequently confused." I don't see the relevance of the second sentence=20 in a document about architecture. The document=20 has a tendency to get into IPv4 NAT details=20 (first sentence). That is odd for a document about IPv6 home networking. In Section 3.4.1: 'One particular situation that must be avoided is having an end site feel compelled to use IPv6-to-IPv6 Network Address Translation or other burdensome address conservation techniques because it could not get sufficient address space."' The document references RFC 6177 for address=20 assignments to end sites. It then goes into the=20 details of IPv6 prefix length and highlights that NPTv6 must be avoided. "There are many problems that would arise from a homenet not being offered a sufficient prefix size for its needs." The above argues that not having an acceptable=20 prefix side for the homenet can be a problem. It=20 would be easier to start with an assumption that=20 the IPv6 homenet will have sufficient address space. "For a typical IPv6 homenet, it is not recommended that an ISP offer less than a /60 prefix, and it is highly preferable that the ISP offers at least a /56." From RFC 6177: "RFC 3177 [RFC3177] called for a default end site IPv6 assignment size of /48. Subsequently, the Regional Internet Registries (RIRs) developed and adopted IPv6 address assignment and allocation policies consistent with the recommendations of RFC 3177" What follows after that is a mention of policies=20 no longer consistent with RFC 3177. This=20 document seems to be taking the same approach as=20 RFC 3177 which has to be updated because of policy issues. "There may be cases where local law means some ISPs are required to change IPv6 prefixes (current IPv4 addresses) for privacy reasons for their customers." In Section 3.6: "The most notable difference to the IPv4 operational model is the removal of NAT" The following is under a "Security" heading. I=20 assumed that the stance of the IETF was that NAT does not provide security. In Section 3.7.3: "Such name spaces may be acquired by the user or provided/generated by their ISP or an alternative cloud-based service." What is a cloud-based service and what name space does it provide? "Also, with the introduction of new 'dotless' top level domains, there is also potential for ambiguity between, for example, a local host called 'computer' and (if it is registered) a .computer gTLD." The IAB has issued a statement about "dotless=20 domain considered as harmful" (=20 http://www.iab.org/2013/07/10/iab-statement-dotless-domains-considered-harmf= ul/=20 ). I don't understand why this document=20 discusses about the introduction of dotless domains. In Section 3.7.8: "It is likely that some devices which have registered names within the homenet Internet name space and that are mobile will attach to the Internet at other locations and acquire an IP address at those locations." What is the homenet Internet name space? There=20 is an IAB technical comment about a unique DNS Root (RFC 2826). Nits: I suggest fixing "This text" in the Abstract. This review does not include other editorial nits. I am including the review from Dave Cridland for APPSDIR: =A71 para 5: Apparently home networks are what they=20 are. I admit to being easily baffled, but I=20 cannot understand how they might not be what they are. Perhaps: "We assume that the IPv4 network architecture=20 currently deployed in home networks can not be=20 modified by new recommendations." In general, =A71 uses a lot of the terms of art=20 from =A71.1, which I found quite hard to deal with=20 - perhaps some of the paragraphs of =A71 could be=20 moved below =A71.1, either as a =A71.2 or something else. =A71.1 "CER" I understand as "the router"; that is, it's=20 the pre-existing DSL/Cable router that's in the=20 majority of home networks now, right? The term=20 used elsewhere in the document is "modern home=20 router", which seems obvious enough, but isn't present in the definition. I've read through the rest of the document, it=20 looks good to me (though some parts I've only skimmed). =A74 seems less of a conclusion and more of a=20 summary; I'm not really sure what it's there for.=20 What I was hoping to find here was a bullet point=20 list of new work needed. Instead, potential new=20 work items are scattered throughout the text,=20 making them hard to locate and enumerate. Regards, S. Moonesamy From superuser@gmail.com Sat Sep 14 18:07:51 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1FDA21E8056 for ; Sat, 14 Sep 2013 18:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DtczJiUi6mhR for ; Sat, 14 Sep 2013 18:07:51 -0700 (PDT) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id C139611E8100 for ; Sat, 14 Sep 2013 18:07:50 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id u56so2393843wes.21 for ; Sat, 14 Sep 2013 18:07:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eXUyXDbdlEsxWXigVqS2Ty43Y/1TA+vvTbeBKqPfKyQ=; b=SSR/Da8CzpPDSUaYRq1AtIRctr+2UF6QtaiszZfKOvO4c9EE8VkTkzxN4R4DTrxtkO s+pwTjf+b0vlNY0AMFwmN+yN8OFnJnrnmQGKrrMLOUwkITqHpJoGLOuYLsPiog+r7Dbt qSS5lSkTx97f4ZRnecdexsr9xzM/WdsXfvO0sHW0xxgMv3niUIawPZ9hwEiobkJLJsJL WwbmdoKWbh9RNePgjfeKDbiEPJDpikSCmUUBb2BV/GQa6rNUV0LT7UUrF32k9NjyYvTF M/ptV49YdYYivEDnbPW90ZqAchXFwDh96Ub06mGjr/AGOE389/VLlxarA0TYgZ304/ua Bx6g== MIME-Version: 1.0 X-Received: by 10.180.189.132 with SMTP id gi4mr7964827wic.19.1379207268766; Sat, 14 Sep 2013 18:07:48 -0700 (PDT) Received: by 10.180.106.169 with HTTP; Sat, 14 Sep 2013 18:07:48 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20130914142312.0b968c10@elandnews.com> References: <6.2.5.6.2.20130914142312.0b968c10@elandnews.com> Date: Sat, 14 Sep 2013 18:07:48 -0700 Message-ID: From: "Murray S. Kucherawy" To: S Moonesamy Content-Type: multipart/alternative; boundary=001a11c35294539b7604e661b7b0 Cc: IETF Apps Discuss , draft-ietf-appsawg-malformed-mail.all@tools.ietf.org Subject: Re: [apps-discuss] Document Shepherd review of draft-ietf-appsawg-malformed-mail-07 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 15 Sep 2013 01:07:51 -0000 --001a11c35294539b7604e661b7b0 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Sep 14, 2013 at 2:29 PM, S Moonesamy wrote: > > In Section 1.2: > > "It is important to understand that this work is not an effort to > endorse or standardize certain common malformations. The code and > culture that introduces such messages into the mail stream needs to > be repaired, as the security penalty now being paid for this lax > processing arguably outweighs the reduction in support costs to end > users who are not expected to understand the standards." > > Section 1 quotes Postel's directive. I read that directive as favoring > interoperability as it is not possible to fix the code already in the wild. > I don't think that it is about support costs. It is more about both of us > being able to communicate with each other through, for example, email. It > might be better to argue that the malformations give more leeway to > security issues. > > What Postel said encourages interoperability, to be sure, and I don't believe he had support costs in mind. When applied to protocols far from layers 7 and up, it works as he stated. I think, though, that taken to an extreme, and especially in the higher layers where the air is thin, we get to the situation in which we now find ourselves. It has introduced security concerns at least in the area of email handling. Hence, I believe the document does exactly what you're suggesting already. -MSK --001a11c35294539b7604e661b7b0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, Sep 14, 2013 at 2:29 PM, S Moonesamy <sm+ietf@= elandsys.com> wrote:

In Section 1.2:

=A0 "It is important to understand that this work is not an effort to<= br> =A0 =A0endorse or standardize certain common malformations. =A0The code and=
=A0 =A0culture that introduces such messages into the mail stream needs to<= br> =A0 =A0be repaired, as the security penalty now being paid for this lax
=A0 =A0processing arguably outweighs the reduction in support costs to end<= br> =A0 =A0users who are not expected to understand the standards."

Section 1 quotes Postel's directive. =A0I read that directive as favori= ng interoperability as it is not possible to fix the code already in the wi= ld. =A0I don't think that it is about support costs. =A0It is more abou= t both of us being able to communicate with each other through, for example= , email. =A0It might be better to argue that the malformations give more le= eway to security issues.


What Postel said encourages inte= roperability, to be sure, and I don't believe he had support costs in m= ind.=A0 When applied to protocols far from layers 7 and up, it works as he = stated.=A0 I think, though, that taken to an extreme, and especially in the= higher layers where the air is thin, we get to the situation in which we n= ow find ourselves.=A0 It has introduced security concerns at least in the a= rea of email handling.

Hence, I believe the document does exactly what you're s= uggesting already.

-MSK
--001a11c35294539b7604e661b7b0-- From masinter@adobe.com Sun Sep 15 01:23:06 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECDCF11E80ED for ; Sun, 15 Sep 2013 01:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.38 X-Spam-Level: X-Spam-Status: No, score=-4.38 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, TVD_SPACE_RATIO=2.219] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q8rJaVM9eEGu for ; Sun, 15 Sep 2013 01:22:58 -0700 (PDT) Received: from exprod6og111.obsmtp.com (exprod6og111.obsmtp.com [64.18.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id CA55821F9BF1 for ; Sun, 15 Sep 2013 01:22:57 -0700 (PDT) Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob111.postini.com ([64.18.5.12]) with SMTP ID DSNKUjVuYPpiJplc9Wo314nXy4nRBLILwnke@postini.com; Sun, 15 Sep 2013 01:22:57 PDT Received: from inner-relay-1.corp.adobe.com (inner-relay-1.adobe.com [153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r8F8Ms2r009890 for ; Sun, 15 Sep 2013 01:22:55 -0700 (PDT) Received: from nacas01.corp.adobe.com (nacas01.corp.adobe.com [10.8.189.99]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r8F8Mr6A020846 for ; Sun, 15 Sep 2013 01:22:53 -0700 (PDT) Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nacas01.corp.adobe.com ([10.8.189.99]) with mapi; Sun, 15 Sep 2013 01:22:53 -0700 From: Larry Masinter To: "apps-discuss@ietf.org" Date: Sun, 15 Sep 2013 01:22:50 -0700 Thread-Topic: multipart/form-data Thread-Index: Ac6x6D79+LSIkDonSle6bdpLkVYUHA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [apps-discuss] multipart/form-data X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 15 Sep 2013 08:23:07 -0000 I made an initial pass over updating multipart/form-data, see: http://tools.ietf.org/html/draft-masinter-multipart-form-data-00=20 initial diff from rfc 2388 http://tools.ietf.org/rfcdiff?url1=3Drfc2388&url2=3Ddraft-masinter-multipar= t-form-data-00.txt and a repo https://github.com/masinter/multipart-form-data with issue tracker https://github.com/masinter/multipart-form-data/issues From cabo@tzi.org Sun Sep 15 01:57:33 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E23B421E804B for ; Sun, 15 Sep 2013 01:57:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lo-sK44dsSPm for ; Sun, 15 Sep 2013 01:57:29 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id C6FD221E80AA for ; Sun, 15 Sep 2013 01:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r8F8vH88007889; Sun, 15 Sep 2013 10:57:17 +0200 (CEST) Received: from [172.16.42.101] (p54894767.dip0.t-ipconnect.de [84.137.71.103]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id DFE631F1; Sun, 15 Sep 2013 10:57:16 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Sun, 15 Sep 2013 10:57:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7FACE7DF-F504-428E-8AD6-65CA39B38757@tzi.org> References: To: Larry Masinter X-Mailer: Apple Mail (2.1510) Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] multipart/form-data X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 15 Sep 2013 08:57:34 -0000 Made a quick scan. Nits: s/proscriptive/prescriptive/ You have two references to HTML4.0 (one called html4). I would kill Appendix B; RFC 2388 is not going away. --AaB03x content-disposition: form-data; name=3D"field1" content-type: text/plain;charset=3Dwindows-1250 content-transfer-encoding: quoted-printable Joe owes =3D80100. --AaB03x You need an empty line before the "Joe owes" (unfortunately, this was = turned into a page break in RFC 2388). I think some clarification of the "can" in 3.2 is required. Maybe say = something like "the handling of file input fields that allow multiple = files to be specified varies between browsers. Some send these as sets = of files (wrapping all the parts for the files in one multipart/mixed), = some just send multiple form-data parts with the same "name" attribute. = HTML5 specifies the latter behavior." (See:) = http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of= -controls-and-forms.html#multipart-form-data > In particular, this means that multiple files submitted as part of a = single element will result in each file = having its own field; the "sets of files" feature ("multipart/mixed") of = RFC 2388 is not used. My view is that this use of multipart/mixed now qualifies for a NOT = RECOMMENDED. Thanks for doing this work! Gr=FC=DFe, Carsten From superuser@gmail.com Mon Sep 16 10:42:11 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E0E511E82A7 for ; Mon, 16 Sep 2013 10:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJmchLfHGSfU for ; Mon, 16 Sep 2013 10:42:11 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id D769F11E812D for ; Mon, 16 Sep 2013 10:42:10 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id hj3so3892781wib.0 for ; Mon, 16 Sep 2013 10:42:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=UeR/sEvYpAAiYArp/tjIKcJuaKS2hPyLPT9QdQGN5jg=; b=wb2sZXDt3+kNs5jXtpDLbUIYqnsgFnVHcjS933a5DFj8VmGTJAZvUcFDUNeXTIIGxu Y87Uq9jtBM5kZ8FnZlM3uCqc9wcG74vDEnmhzVyccLK0yGypsNS3ot35nwBUuOvJSnmG pxngLxBh+qpPwyHrk+EsW57TBfxDIV9l+nAQHvzG2+Q1fug8s0X3EwXWnlHQk1ub4DbU JHmF1UnXNkX3ZjXB3mVy1eMErszRjyALCedXOUmYb/qVSLqsnOkpz8Q+/Yox8AigwnpC eyGT4th16Q1Nx4L+7vT2qPT2SHlyA8bqzqkty0hX9EqPmtaouo2Hqjs5hHL9kLNc2Spb 0uXA== MIME-Version: 1.0 X-Received: by 10.194.174.36 with SMTP id bp4mr22930781wjc.7.1379353329985; Mon, 16 Sep 2013 10:42:09 -0700 (PDT) Received: by 10.180.106.169 with HTTP; Mon, 16 Sep 2013 10:42:09 -0700 (PDT) Date: Mon, 16 Sep 2013 10:42:09 -0700 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=089e0141a0ae40f09504e683b945 Subject: [apps-discuss] Call for Adoption: draft-masinter-multipart-form-data X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 16 Sep 2013 17:42:11 -0000 --089e0141a0ae40f09504e683b945 Content-Type: text/plain; charset=ISO-8859-1 Colleagues, Larry Masinter has been developing draft-masinter-multipart-form-data, to replace RFC2388. It was supposed to get some agenda time in Berlin but we ran long (apologies, again, to Larry for that!). We believe it qualifies for processing through APPSAWG under our charter and had some prior discussion on this list in July and August. This is a call for adoption for doing so. Please indicate support or objection on this thread. We'll make a determination around the end of this month. Larry and others, we'd also welcome suggestions for a milestone month/year for handoff to the IESG. -MSK, APPSAWG co-chair --089e0141a0ae40f09504e683b945 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Colleagues,

Larry Masinte= r has been developing draft-masinter-multipart-form-data, to replace RFC238= 8.=A0 It was supposed to get some agenda time in Berlin but we ran long (ap= ologies, again, to Larry for that!).=A0 We believe it qualifies for process= ing through APPSAWG under our charter and had some prior discussion on this= list in July and August.

This is a call for adoption for doing so.=A0 Please indicate supp= ort or objection on this thread.=A0 We'll make a determination around t= he end of this month.

Larry and others, we'd also welcome = suggestions for a milestone month/year for handoff to the IESG.

-MSK, APPSAWG co-chair
--089e0141a0ae40f09504e683b945-- From tony@att.com Mon Sep 16 11:28:28 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FE0A11E8140 for ; Mon, 16 Sep 2013 11:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.953 X-Spam-Level: X-Spam-Status: No, score=-105.953 tagged_above=-999 required=5 tests=[AWL=0.646, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rsc9MKxANWxN for ; Mon, 16 Sep 2013 11:28:21 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 9088211E8141 for ; Mon, 16 Sep 2013 11:28:21 -0700 (PDT) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 5cd47325.0.1389899.00-445.3816033.nbfkord-smmo06.seg.att.com (envelope-from ); Mon, 16 Sep 2013 18:28:21 +0000 (UTC) X-MXL-Hash: 52374dc55607cbd7-2a9be8199d47c4c0b9c115b7f0c3e9448f063a07 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r8GISKUf012203 for ; Mon, 16 Sep 2013 14:28:20 -0400 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r8GISEqr012159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 16 Sep 2013 14:28:19 -0400 Received: from alpi153.aldc.att.com (alpi153.aldc.att.com [130.8.42.31]) by alpi133.aldc.att.com (RSA Interceptor) for ; Mon, 16 Sep 2013 18:28:09 GMT Received: from aldc.att.com (localhost [127.0.0.1]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id r8GIS9KG025724 for ; Mon, 16 Sep 2013 14:28:09 -0400 Received: from mailgw1.maillennium.att.com (maillennium.att.com [135.25.114.99]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id r8GIS4nH025442 for ; Mon, 16 Sep 2013 14:28:04 -0400 Received: from [135.70.121.115] (vpn-135-70-121-115.vpn.swst.att.com[135.70.121.115]) by maillennium.att.com (mailgw1) with ESMTP id <20130916182803gw1004nhi7e> (Authid: tony); Mon, 16 Sep 2013 18:28:03 +0000 X-Originating-IP: [135.70.121.115] Message-ID: <52374DB2.8020404@att.com> Date: Mon, 16 Sep 2013 14:28:02 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] X-AnalysisOut: [v=2.0 cv=WrCcx6jv c=1 sm=0 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=G1fKPtwPdWcA:10 a=sCfsyOEanakA:10 a=wfU3BWp5r2QA:10 a=ofM] X-AnalysisOut: [gfj31e3cA:10 a=BLceEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=zQP7CpK] X-AnalysisOut: [OAAAA:8 a=-3PEobTyzeQA:10 a=KBdkNXzvcNv0HOhFQ20A:9 a=wPNLv] X-AnalysisOut: [fGTeEIA:10] Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Call for Adoption: draft-masinter-multipart-form-data X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 16 Sep 2013 18:28:28 -0000 On 9/16/2013 1:42 PM, Murray S. Kucherawy wrote: > Larry Masinter has been developing draft-masinter-multipart-form-data, > to replace RFC2388. It was supposed to get some agenda time in Berlin > but we ran long (apologies, again, to Larry for that!). We believe it > qualifies for processing through APPSAWG under our charter and had > some prior discussion on this list in July and August. > > This is a call for adoption for doing so. Please indicate support or > objection on this thread. We'll make a determination around the end > of this month. +1 From dhc@dcrocker.net Mon Sep 16 11:47:57 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2141411E82D5 for ; Mon, 16 Sep 2013 11:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q9qoHZKJJ23x for ; Mon, 16 Sep 2013 11:47:44 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA5311E8141 for ; Mon, 16 Sep 2013 11:47:44 -0700 (PDT) Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r8GIlcho031457 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Sep 2013 11:47:42 -0700 Message-ID: <5237522F.1000903@dcrocker.net> Date: Mon, 16 Sep 2013 11:47:11 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Mon, 16 Sep 2013 11:47:42 -0700 (PDT) Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Call for Adoption: draft-masinter-multipart-form-data X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Sep 2013 18:47:57 -0000 > Larry Masinter has been developing draft-masinter-multipart-form-data, > to replace RFC2388. It was supposed to get some agenda time in Berlin > but we ran long (apologies, again, to Larry for that!). We believe it > qualifies for processing through APPSAWG under our charter and had some > prior discussion on this list in July and August. > > This is a call for adoption for doing so. Please indicate support or > objection on this thread. We'll make a determination around the end of > this month. +1 d/ ps. Perhaps the examples section of his document can include a convention for attaching a +1 response form? -- Dave Crocker Brandenburg InternetWorking bbiw.net From dave@cridland.net Mon Sep 16 12:29:13 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E16DA21F9433 for ; Mon, 16 Sep 2013 12:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c2z6Z-3Udup0 for ; Mon, 16 Sep 2013 12:29:02 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 608FD11E8198 for ; Mon, 16 Sep 2013 12:27:05 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id cb5so4022949wib.1 for ; Mon, 16 Sep 2013 12:27:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=to:message-id:from:cc:date:mime-version:subject:content-type; bh=7JfRQb5a7S5MO4ml7OEFoIQjTI+2AwohOKlOEsszdBQ=; b=X59tu0TgB8Jzh839cKcmC8TtOGcNy2oYevWeMQpjDjJrMA59Es6AbcWrBk81X+bAE0 utjl0yVIqtZnM6mNMsGt7cbyBM4p6LvbzP6rSDefzw/G9kT3w3AlT/tylnkHNmkUtpwL 2OULIQL/KeqPSaHB8uvSpHm8k6S/DPOyulCuY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:message-id:from:cc:date:mime-version:subject :content-type; bh=7JfRQb5a7S5MO4ml7OEFoIQjTI+2AwohOKlOEsszdBQ=; b=nNHAV7yvbxYFRIHZwvi5e8stR9ssQCUVJ0X1YYDk4jhAje9Yjn1xCa56c/m4MyOQ3A J65c4usHWdfOofpg0wSR7yOoGqFzQ0KcJxk6OLWqQSq1MWuBAsiwH2dTokVmrE7nMPrb JjEtBs4mtAimmnF8eAq1TlckbnQnH0K6hd+aK5QC8hwMohXaeTdAvfLu90DqlskV3AgW 5Ybm9xbamK0pfkjOYPW3Ixf6L9XSyTHZkzFV9x/W58yDLGO/PlHrf2w8V3gNpzWqOnQ6 pPqzQBzFfAeAul0rkrhtbTA/wc0d+8ZjqErcVv5mMfdYImYrowBucBxFppHQPdtb9ooF KGRA== X-Gm-Message-State: ALoCoQkW8WaSaJmqk8V8gUrVqpIaTLGHM5cbyR65FEIyHaY/3Ybep3khLItp+k5CMeH234GNf0i/ X-Received: by 10.194.23.73 with SMTP id k9mr24796281wjf.24.1379359622189; Mon, 16 Sep 2013 12:27:02 -0700 (PDT) Received: from Mac-mini.local (peirce.dave.cridland.net. [217.155.137.61]) by mx.google.com with ESMTPSA id iz19sm25872307wic.9.1969.12.31.16.00.00 (version=TLSv1.1 cipher=RC4-SHA bits=128/128); Mon, 16 Sep 2013 12:27:01 -0700 (PDT) To: "Murray S. Kucherawy" Message-Id: From: Dave Cridland Date: Mon, 16 Sep 2013 19:26:59 -0000 Mime-Version: 1.0 X-Mailer: Inky (TM) v2.0.5237.38E2 ("Ink Different") Content-Type: text/plain; charset="us-ascii" Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Call for Adoption: draft-masinter-multipart-form-data X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 16 Sep 2013 19:29:13 -0000 Murray S. Kucherawy wrote: Colleagues, Larry Masinter has been developing draft-masinter-multipart-form-data, to replace RFC2388. It was supposed to get some agenda time in Berlin but we ran long (apologies, again, to Larry for that!). We believe it qualifies for processing through APPSAWG under our charter and had some prior discussion on this list in July and August. This is a call for adoption for doing so. Please indicate support or objection on this thread. We'll make a determination around the end of this month. Larry and others, we'd also welcome suggestions for a milestone month/year for handoff to the IESG. -MSK, APPSAWG co-chair _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss I'm in favour of adoption, and will commit to reviewing. I have recently implemented RFC 2388 (client-side) and deployed it against existing services. Sent with [inky: ] From johnl@iecc.com Mon Sep 16 12:29:28 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DBF011E831D for ; Mon, 16 Sep 2013 12:29:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.681 X-Spam-Level: X-Spam-Status: No, score=-102.681 tagged_above=-999 required=5 tests=[AWL=-0.082, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EGhqxo7BGr-2 for ; Mon, 16 Sep 2013 12:29:24 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id EE2FD21F88B7 for ; Mon, 16 Sep 2013 12:28:52 -0700 (PDT) Received: (qmail 99365 invoked from network); 16 Sep 2013 19:28:50 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 16 Sep 2013 19:28:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=52375bf2.xn--9vv.k1309; i=johnl@user.iecc.com; bh=N0UdhDqBK0Xyhy++PzV1jXo+wwPZIGGccJvwXYGbED0=; b=HThYjO36z3Xhf173es+jKiU31a1spWInawUBRtHFa5lmDsk1xSCXhID+Mzu1sBR8C54hpE3w/bUKw6PqD63bzCo+tJ3f3/dvLg91SFIZFCOmzEmmhwYgKalNrl9qkuKjW3hcWdRe0n2d1SecjB0Z/1AAml0/bxfDsDQKYlCdgL2JFdlrY5dmolbqgXeZHYpyrS0vSSJjo5zRr/aNw21rRHn7z6MgwwBbwEk169oQg6be66l8oVNv98xh2eB0hv5f DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=52375bf2.xn--9vv.k1309; olt=johnl@user.iecc.com; bh=N0UdhDqBK0Xyhy++PzV1jXo+wwPZIGGccJvwXYGbED0=; b=b2CJsMCZHDkGE53SC7KEl/hcDjgbEmCvoCuXUACZ8B9UwEZiZMf22B+wHlF3hIt5q6rCXoSQ8jU3ln3+3fKLmTTNTC7LAT2qAhaHIt33mipEsy5Mzqo4MAYtHd7HSiZY9zrk/8YU7bPQAlUxmk31+zI4KgRUns1YP/Y+RthwMBh+nnlNYPOYHKyiiIMjUeZJnlRGx9RnVSwcnvoa77fHsP2rY8ZbwHmeBDLnC95C7Ur+4m2YEDBgSudD5AnLPa2U Date: 16 Sep 2013 19:28:28 -0000 Message-ID: <20130916192828.86618.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [apps-discuss] Call for Adoption: draft-masinter-multipart-form-data X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 16 Sep 2013 19:29:28 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >This is a call for adoption for doing so. Please indicate support or >objection on this thread. We'll make a determination around the end of >this month. I've actually read the draft and support adoption. multipart/form-data is very widely used, and it's long past time to give implementers better advice about how to do it. R's, John -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (FreeBSD) iEYEARECAAYFAlI3W/AACgkQkEiFRdeC/kU97wCffgzDNzPkED3E6Tba2awJrkib ORwAnRl7nxfSqOsya8kF1t1h628V5abg =gTp1 -----END PGP SIGNATURE----- From alexey.melnikov@isode.com Tue Sep 17 03:27:23 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 709F011E83C7 for ; Tue, 17 Sep 2013 03:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.42 X-Spam-Level: X-Spam-Status: No, score=-102.42 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NFwqsGrOMeJb for ; Tue, 17 Sep 2013 03:27:18 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 14E0B11E80F3 for ; Tue, 17 Sep 2013 03:27:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1379413636; d=isode.com; s=selector; i=@isode.com; bh=Z+J4C+rodtJlqYyQjUJlGxtA0KtjZluahWH/Iybbyyo=; 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=OgnB50ne2EEN8xrZNV8deMMLlDk8RwQomxZjST1qMdVtVRfTNNAhtPcYZxaSCXJK6MrFxt kg9Q5h1DbDaevowyJRUND8cxHMSYZK+x831qjCgVbjZlqHOfXAIZXXPRo3Jc0XZLnVH6m+ 9g8Ao2NnfN5WvpFviGU45p9CHDs32iA=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 17 Sep 2013 11:27:16 +0100 Message-ID: <52382E84.5020302@isode.com> Date: Tue, 17 Sep 2013 11:27:16 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 To: Larry Masinter MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" Subject: [apps-discuss] Comments on draft-masinter-multipart-form-data-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 10:27:23 -0000 Hi Larry, Some comments after reviewing your draft: In Section 2: As with all multipart MIME types, each part has an optional "Content- Type", which defaults to "text/plain". If the contents of a file are returned via filling out a form, then the file input is identified as the appropriate media type, if known, or "application/octet-stream". The inclusion of multiple files returned for a single file input result in multiple parts, one for each file, with the same name. I would insert references to where various mentioned media types are defined. As with all multipart MIME types, each part has an optional "Content- Type", which defaults to "text/plain". If the contents of a file are returned via filling out a form, then the file input is identified as the appropriate media type, if known, or "application/octet-stream". The inclusion of multiple files returned for a single file input result in multiple parts, one for each file, with the same name. It took me multiple passes to understand the last sentence. I am not sure I got it. Can you insert an example or qualify various use of "file"? 3.5. Charset of text in form data For example, a form with a text field in which a user typed 'Joe owes 100' where is the Euro symbol might have form data returned as: --AaB03x content-disposition: form-data; name="field1" content-type: text/plain;charset=windows-1250 content-transfer-encoding: quoted-printable Joe owes =80100. --AaB03x Are you missing an empty line after "content-transfer-encoding:"? This doesn't look like a proper MIME fragment. 6. Media type registration for multipart/form-data Media Type name: multipart Media subtype name: form-data Required parameters: none Optional parameters: none This doesn't look correct. What about "boundary"? Example multipart/form-data would be useful. I had to search the web to find some. Best Regards, Alexey From alexey.melnikov@isode.com Tue Sep 17 03:28:58 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0C0511E80F3 for ; Tue, 17 Sep 2013 03:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.438 X-Spam-Level: X-Spam-Status: No, score=-102.438 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0HiFubW7rfI5 for ; Tue, 17 Sep 2013 03:28:52 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 054C511E83C7 for ; Tue, 17 Sep 2013 03:28:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1379413727; d=isode.com; s=selector; i=@isode.com; bh=FSkSWDsjuJoWwQGRjJDswZjUtsJcI0azv1EpexdNBws=; 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=EeeX4pU4+ETqBc7UBqleP/k9ByJy8SOzqs16EqbNX+fcJhjI3VK+nlXG7+Y+v7myZcROhy V6AXv8F5Z9/k2gDT3EMLxQ0J1xsL/2gJQl7RGGjAEwVDb9vxhztBqd7tB3LJMXg8j/VC+F NNi1dN+ZRjE/OwAHiDjzIzQ+diZuhJw=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 17 Sep 2013 11:28:47 +0100 Message-ID: <52382EE0.1090803@isode.com> Date: Tue, 17 Sep 2013 11:28:48 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 To: "Murray S. Kucherawy" References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Call for Adoption: draft-masinter-multipart-form-data X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 10:28:58 -0000 On 16/09/2013 18:42, Murray S. Kucherawy wrote: > Colleagues, > > Larry Masinter has been developing draft-masinter-multipart-form-data, > to replace RFC2388. It was supposed to get some agenda time in Berlin > but we ran long (apologies, again, to Larry for that!). We believe it > qualifies for processing through APPSAWG under our charter and had > some prior discussion on this list in July and August. > > This is a call for adoption for doing so. Please indicate support or > objection on this thread. We'll make a determination around the end > of this month. I support WG adoption of this document. I will send my review comments separately. From ht@inf.ed.ac.uk Tue Sep 17 04:33:16 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F3EA11E83EF for ; Tue, 17 Sep 2013 04:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.185 X-Spam-Level: X-Spam-Status: No, score=-4.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-LLsPUXNWMW for ; Tue, 17 Sep 2013 04:33:10 -0700 (PDT) Received: from nougat.ucs.ed.ac.uk (nougat.ucs.ed.ac.uk [129.215.13.205]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA5F11E8100 for ; Tue, 17 Sep 2013 04:33:10 -0700 (PDT) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by nougat.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id r8HBWxq1011814 for ; Tue, 17 Sep 2013 12:32:59 +0100 (BST) Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id r8HBWw7q003549 for ; Tue, 17 Sep 2013 12:32:58 +0100 Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id r8HBWxHr004268 for ; Tue, 17 Sep 2013 12:32:59 +0100 Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id r8HBWwKY004264; Tue, 17 Sep 2013 12:32:58 +0100 X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: apps-discuss@ietf.org References: <828708BA-E4BF-48DE-9E44-3C21063AA3D8@gmail.com> <6.2.5.6.2.20130813230340.0b0d4968@resistor.net> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Tue, 17 Sep 2013 12:32:58 +0100 In-Reply-To: <6.2.5.6.2.20130813230340.0b0d4968@resistor.net> (sm@resistor.net's message of "Tue\, 13 Aug 2013 23\:44\:11 -0700") Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at nougat.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.13.205 Subject: Re: [apps-discuss] Working Group Last Call: draft-ietf-appsawg-xml-mediatypes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 11:33:16 -0000 At 22:52 13-08-2013, Murray S. Kucherawy wrote: > A gentle reminder that this WGLC is in effect, closing in a few > days. To date there have been no comments or reviews on the WGLC at > all. It will be hard for me to argue that consensus exists without > at least a few reviews on the record. This reminder produced only one reply, with what I believe are essentially editorial suggestions. _Please_ can we get a few more reviews, even if they are just "Yes, it's time to take this forward". This RFC documents a moderately important part of the Web infrastructure, and its predecessor is out-of-date and indeed misleading in important ways, so we really do need to get it out the door. Thanks, ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From internet-drafts@ietf.org Tue Sep 17 06:44:28 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81B6811E8248; Tue, 17 Sep 2013 06:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oDqPREirsYPH; Tue, 17 Sep 2013 06:44:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F27511E83F0; Tue, 17 Sep 2013 06:44:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.71.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130917134421.31881.71485.idtracker@ietfa.amsl.com> Date: Tue, 17 Sep 2013 06:44:21 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-uri-get-off-my-lawn-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 13:44:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Working G= roup of the IETF. Title : Standardising Structure in URIs Author(s) : Mark Nottingham Filename : draft-ietf-appsawg-uri-get-off-my-lawn-00.txt Pages : 8 Date : 2013-09-16 Abstract: Sometimes, it is attractive to add features to protocols or applications by specifying a particular structure for URIs (or parts thereof). This document cautions against this practice in standards (sometimes called "URI Squatting"). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-uri-get-off-my-lawn There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-uri-get-off-my-lawn-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 ietf-secretariat-reply@ietf.org Tue Sep 17 06:47:32 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA3D311E8111 for ; Tue, 17 Sep 2013 06:47:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fmx+JxQ7+tTJ for ; Tue, 17 Sep 2013 06:47:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A5CB811E8260 for ; Tue, 17 Sep 2013 06:47:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: apps-discuss@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.71.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130917134701.16674.44819.idtracker@ietfa.amsl.com> Date: Tue, 17 Sep 2013 06:47:01 -0700 From: IETF Secretariat Subject: [apps-discuss] Milestones changed for appsawg WG X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 13:47:32 -0000 URL: http://datatracker.ietf.org/wg/appsawg/charter/ From julian.reschke@gmx.de Tue Sep 17 08:04:51 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB60111E8462 for ; Tue, 17 Sep 2013 08:04:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.999 X-Spam-Level: X-Spam-Status: No, score=-104.999 tagged_above=-999 required=5 tests=[AWL=-2.400, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y9LQARO7xNcM for ; Tue, 17 Sep 2013 08:04:45 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 696D711E846C for ; Tue, 17 Sep 2013 08:04:40 -0700 (PDT) Received: from [192.168.1.102] ([217.91.35.233]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LmbVT-1Vw6Wj0cap-00aCUs for ; Tue, 17 Sep 2013 17:04:38 +0200 Message-ID: <52386F75.9050802@gmx.de> Date: Tue, 17 Sep 2013 17:04:21 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <828708BA-E4BF-48DE-9E44-3C21063AA3D8@gmail.com> In-Reply-To: <828708BA-E4BF-48DE-9E44-3C21063AA3D8@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:v+zoJZkGo93T32cT5QXrw2x20m1EUZUCPfmlmmKviJ/CWxosjMF LhK+C7D6dK4cf3/FKy+bsKtMhvOoyYkiOqDh0evq4Z+j6Xu+GrBWuo2yBitrHY1T8VrIlKa eHK+XjQS27TAqH0sAjdD8CX8L8MADiaB4iD9avmetO87zSa/n6HFhyaVi9GXVaDE/UP+VBE praqcQu2vaEhuBCkEcqvA== Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Working Group Last Call: draft-ietf-appsawg-xml-mediatypes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 15:04:51 -0000 On 2013-07-29 10:08, Murray S. Kucherawy wrote: > This note begins a Working Group Last Call for draft-ietf-appsawg-xml-mediatypes, ending on Friday, August 16. Please provide reviews and comments on this list or privately to the authors as soon as possible. > > -MSK, APPSAWG co-chair and document shepherd > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss Checking reference nits using : > Normative References: > RFC2045: [DRAFT STANDARD] ok > RFC2046: [DRAFT STANDARD] ok > RFC2119: [BEST CURRENT PRACTICE] (-> BCP0014) ok > RFC2616: [DRAFT STANDARD] ok > RFC2781: [INFORMATIONAL] ok > RFC3986: [INTERNET STANDARD] (-> STD0066) ok > RFC3987: [PROPOSED STANDARD] ok > RFC6657: [PROPOSED STANDARD] ok > RFC6838: [BEST CURRENT PRACTICE] (-> BCP0013) ok > RFC6839: [INFORMATIONAL] ok > xmlbase: document unknown > REC-xml: [Description] ok > REC-xml: [Description] ok > REC-XPointer-Element: document unknown > REC-XPointer-Framework: document unknown > XPtrReg: not checked For all the W3C documents, I recommend to pull in the elements from -- this makes the format consistent and enables automatic up-to-date checking. > Informative References: > ASCII: not checked > REC-CSS2: [Description] ok > HTTPbis: not checked This should either be dropped as not being relevant, or be an actual up-to-date Internet Draft reference to draft-ietf-httpbis-p2-semantics-23. > ISO8859: not checked > RFC1557: [INFORMATIONAL] ok > RFC2130: [INFORMATIONAL] ok > RFC2376: [INFORMATIONAL] obsoleted by RFC3023 > RFC2703: [INFORMATIONAL] ok > RFC3023: not checked > RFC3629: [INTERNET STANDARD] (-> STD0063) ok > RFC3977: [PROPOSED STANDARD] ok > RFC4289: [BEST CURRENT PRACTICE] (-> BCP0013) ok > RFC5321: [DRAFT STANDARD] ok > RFC6152: [INTERNET STANDARD] (-> STD0071) ok > TAGMIME: not checked > xhtml1: document unknown Best regards, Julian From vkg@bell-labs.com Tue Sep 17 08:49:27 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28F3911E829E; Tue, 17 Sep 2013 08:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4GKRwO5yjaW3; Tue, 17 Sep 2013 08:49:22 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 7247611E8110; Tue, 17 Sep 2013 08:49:22 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r8HFnJta022599 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 17 Sep 2013 10:49:19 -0500 (CDT) Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id r8HFnIJx012654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 17 Sep 2013 10:49:18 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.237.229]) by umail.lucent.com (8.13.8/TPES) with ESMTP id r8HFnImY011182; Tue, 17 Sep 2013 10:49:18 -0500 (CDT) Message-ID: <52387B2A.9020102@bell-labs.com> Date: Tue, 17 Sep 2013 10:54:18 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130805 Thunderbird/17.0.8 MIME-Version: 1.0 To: draft-ietf-insipid-session-id-reqts.all@tools.ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Cc: IESG IESG , "apps-discuss@ietf.org" Subject: [apps-discuss] APPSDIR review of draft-ietf-insipid-session-id-reqts-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 15:49:27 -0000 I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see ​ http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-insipid-session-id-reqts-08 Title: Diameter Overload Control Requirements Reviewer: Vijay K. Gurbani Review Date: Sep-17-2013 IETF Last Call Date: Not known IESG Telechat Date: Not known Summary: This draft is almost ready for publication as an Informational RFC; two minor issues follow. Major: 0 Minor: 2 Nits: 2 Minor: - S3.2, the list of what are not considered communication sessions appears rather arbitrary. What criteria makes you consider these are not communication sessions? Is it the fact that some sort of conferencing (ad-hoc or organized) is being used? If so, best to state this up front. Otherwise I am left wondering why these cases are not considered to be a communication session. I can certainly see the benefit of knowing which endpoints participated in a conference call that is indexed by a unique Session-ID. So, why preclude this? Any reason for doing so will help understand the decision for considering conferencing out of scope. - S7, third paragraph: In cleartext traffic that is not subject to an rfc4474-type mechanism, I am not sure how you can prevent an attacker from spoofing (i.e., changing) the identifier to render is useless? Likewise, under similar conditions I am not sure how an application can verify that the session identifier was not changed. Unless, of course, you are stating that the identifier must be transmitted over a confidential and privacy preserving channel (which seems to be the gist of the last sentence of the section). If that is the case, then you may want to highlight in a more prominent form than currently stated. Nits: - S3.1, first paragraph: s/that,/which,/ - S3.1, seventh paragraph: s/speaks of/considers/ (less colloquial that way). Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq From dret@berkeley.edu Tue Sep 17 11:06:30 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7C0C21F8503 for ; Tue, 17 Sep 2013 11:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cjsuXoYriAXs for ; Tue, 17 Sep 2013 11:06:26 -0700 (PDT) Received: from cm02fe.IST.Berkeley.EDU (cm02fe.IST.Berkeley.EDU [169.229.218.143]) by ietfa.amsl.com (Postfix) with ESMTP id B1CB511E82C9 for ; Tue, 17 Sep 2013 11:04:29 -0700 (PDT) Received: from c-24-6-239-29.hsd1.ca.comcast.net ([24.6.239.29] helo=dretair.local) by cm02fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1VLzdO-0003ZN-89; Tue, 17 Sep 2013 11:04:23 -0700 Message-ID: <523899A3.1010503@berkeley.edu> Date: Tue, 17 Sep 2013 11:04:19 -0700 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Henry S. Thompson" , apps-discuss@ietf.org References: <828708BA-E4BF-48DE-9E44-3C21063AA3D8@gmail.com> <6.2.5.6.2.20130813230340.0b0d4968@resistor.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] Working Group Last Call: draft-ietf-appsawg-xml-mediatypes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 18:06:30 -0000 hello. On 2013-09-17 04:32 , Henry S. Thompson wrote: > At 22:52 13-08-2013, Murray S. Kucherawy wrote: >> A gentle reminder that this WGLC is in effect, closing in a few >> days. To date there have been no comments or reviews on the WGLC at >> all. It will be hard for me to argue that consensus exists without >> at least a few reviews on the record. > This reminder produced only one reply, with what I believe are > essentially editorial suggestions. _Please_ can we get a few more > reviews, even if they are just "Yes, it's time to take this forward". > This RFC documents a moderately important part of the Web > infrastructure, and its predecessor is out-of-date and indeed > misleading in important ways, so we really do need to get it out the > door. it would be great to see this getting published. if there's anything i can do to help, please let me know. (and i still think it would be nice to have media types for XSD and maybe sneak them in this way, but maybe that's more counter-productive for this to be finished than it is helpful... :-) thanks and cheers, dret. -- erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | | UC Berkeley - School of Information (ISchool) | | http://dret.net/netdret http://twitter.com/dret | From superuser@gmail.com Tue Sep 17 11:10:29 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8E611E82AC for ; Tue, 17 Sep 2013 11:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FW17GinFwbmw for ; Tue, 17 Sep 2013 11:10:28 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id 5ADEF11E812B for ; Tue, 17 Sep 2013 11:10:28 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id c11so5522798wgh.30 for ; Tue, 17 Sep 2013 11:10:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RSo18Qp7fUEHongaRbi2xV9y68U4ZuK2rgaXJedygMk=; b=F+bs29bbkQ2p3klhA/iWwpUIOLw1rDUZ0gzKyEN00rcFtHtWPLwwZSIcWS1PVQgNR3 mWkSFsdXshEE38wnQxV5quXZQjRE4Yeg+eQ2yNBdIHuK2riTVcAIi4F8vHRNmuNrWdJQ aWqueEtyrn+FZCMpuwNzqDxwqpwZXlISeg7lnIYEk3uq0vEAzd6nXvO21P2FFEjjUbyc dpubQuDi9CIR+AW8fiWjv6V8va6wtSDfmAi/AuaLqQ1YeASFYjgjUtE9VKjy7JbpvqtE DkTvEF9IYAP/f/2gSUnTtFEabzEZW3OIdveW1T0ayFUb2AWVbrBeHeApP0502wSxG2fU 6ACA== MIME-Version: 1.0 X-Received: by 10.180.72.226 with SMTP id g2mr3579924wiv.52.1379441420162; Tue, 17 Sep 2013 11:10:20 -0700 (PDT) Received: by 10.180.106.169 with HTTP; Tue, 17 Sep 2013 11:10:19 -0700 (PDT) In-Reply-To: <523899A3.1010503@berkeley.edu> References: <828708BA-E4BF-48DE-9E44-3C21063AA3D8@gmail.com> <6.2.5.6.2.20130813230340.0b0d4968@resistor.net> <523899A3.1010503@berkeley.edu> Date: Tue, 17 Sep 2013 11:10:19 -0700 Message-ID: From: "Murray S. Kucherawy" To: Erik Wilde Content-Type: multipart/alternative; boundary=f46d043890edd65e6504e6983b72 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Working Group Last Call: draft-ietf-appsawg-xml-mediatypes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 18:10:30 -0000 --f46d043890edd65e6504e6983b72 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Sep 17, 2013 at 11:04 AM, Erik Wilde wrote: > it would be great to see this getting published. if there's anything i can > do to help, please let me know. > > How about a review of the version that was last-called earlier this summer? ;-) -MSK --f46d043890edd65e6504e6983b72 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Sep 17, 2013 at 11:04 AM, Erik Wilde <dret@berkel= ey.edu> wrote:
it would be great to see this getting publis= hed. if there's anything i can do to help, please let me know.


How about a review of the version that= was last-called earlier this summer?=A0 ;-)

-MSK
--f46d043890edd65e6504e6983b72-- From sm@elandsys.com Tue Sep 17 11:18:14 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A673511E854D for ; Tue, 17 Sep 2013 11:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R2ZxITnn9DKB for ; Tue, 17 Sep 2013 11:18:14 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 11FC511E8546 for ; Tue, 17 Sep 2013 11:18:12 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.158.202]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r8HIHlpl003293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Sep 2013 11:17:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1379441881; bh=aqlKpPh504d2ZNQC3X4RBEMqasqlD7hPaO3Km9gl0fY=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=gaQ9eB/rSzJ+VPNTt+1TBP+ky6ejb1XvB/YB4S06pE/rAeS6cZn0NX+cjD/ysE2mf fnAGAgr22IberRr94/vpsCqgf6eCkMQX2TdXiDe8Mf+d0G3sogZWCyaGzyjO3UuxuF YBeOd7VIKx6lizp8YSgUqdYNfu5e1SAf1RGiXuqA= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1379441881; i=@elandsys.com; bh=aqlKpPh504d2ZNQC3X4RBEMqasqlD7hPaO3Km9gl0fY=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=f6uX+uAqsaSWHQ/Lp5BkSKGEsIMK30rPHq/PFadV1dLP71WB5y8Yo0c9KdzgUek2p pc9bpFbvki15WipejsyJOI3zdg5gs91D2gxe5eAFZNYYFsMJl1qnrzSbXMZLcoVTun 2yJCmmxQf6FCSCe5Psd3dprCUecKWYjoebuwVKbQ= Message-Id: <6.2.5.6.2.20130917111446.0c5256c0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 17 Sep 2013 11:17:35 -0700 To: "Murray S. Kucherawy" From: S Moonesamy In-Reply-To: References: <6.2.5.6.2.20130914142312.0b968c10@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-discuss@ietf.org, draft-ietf-appsawg-malformed-mail.all@tools.ietf.org Subject: Re: [apps-discuss] Document Shepherd review of draft-ietf-appsawg-malformed-mail-07 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 18:18:14 -0000 Hi Murray, At 18:07 14-09-2013, Murray S. Kucherawy wrote: >What Postel said encourages interoperability, to be sure, and I >don't believe he had support costs in mind. When applied to >protocols far from layers 7 and up, it works as he stated. I think, >though, that taken to an extreme, and especially in the higher >layers where the air is thin, we get to the situation in which we >now find ourselves. It has introduced security concerns at least in >the area of email handling. > >Hence, I believe the document does exactly what you're suggesting already. As nobody else expressed an opinion I suggest leaving the text as it is. Can you submit -08 and I'll post the write-up? Sorry for the very long delay. Regards, S. Moonesamy From internet-drafts@ietf.org Tue Sep 17 11:22:18 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE41511E854E; Tue, 17 Sep 2013 11:22:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G00+3EMXSeeQ; Tue, 17 Sep 2013 11:22:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A3BB11E82C3; Tue, 17 Sep 2013 11:22:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.71.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130917182217.12916.18972.idtracker@ietfa.amsl.com> Date: Tue, 17 Sep 2013 11:22:17 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-malformed-mail-08.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 18:22:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Working G= roup of the IETF. Title : Advice for Safe Handling of Malformed Messages Author(s) : Murray S. Kucherawy Gregory N. Shapiro N. Freed Filename : draft-ietf-appsawg-malformed-mail-08.txt Pages : 21 Date : 2013-09-17 Abstract: Although Internet mail formats have been precisely defined since the 1970s, authoring and handling software often show only mild conformance to the specifications. The distributed and non- interactive nature of email has often prompted adjustments to receiving software, to handle these variations, rather than trying to gain better conformance by senders, since the receiving operator is primarily driven by complaining recipient users and has no authority over the sending side of the system. Processing with such flexibility comes at some cost, since mail software is faced with decisions about whether or not to permit non-conforming messages to continue toward their destinations unaltered, adjust them to conform (possibly at the cost of losing some of the original message), or outright rejecting them. A core requirement for interoperability is that both sides of an exchange work from the same details and semantics. By having receivers be flexible, beyond the specifications, there can be -- and often has been -- a good chance that a message will not be fully interoperable. Worse, a well-established pattern of tolerance for variations can sometimes be used as an attack vector. This document includes a collection of the best advice available regarding a variety of common malformed mail situations, to be used as implementation guidance. These malformations are typically based around loose interpretations or implementations of specifications such as Internet Message Format [MAIL] and Multipurpose Internet Mail Extensions [MIME]. It must be emphasized, however, that the intent of this document is not to standardize malformations or otherwise encourage their proliferation. The messages are manifestly malformed, and the code and culture that generates them needs to be fixed. Therefore, these messages should be rejected outright if at all possible. Nevertheless, many malformed messages from otherwise legitimate senders are in circulation and will be for some time, and, unfortunately, commercial reality shows that we cannot always simply reject or discard them. Accordingly, this document presents alternatives for dealing with them in ways that seem to do the least additional harm until the infrastructure is tightened up to match the standards. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-malformed-mail There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-malformed-mail-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-malformed-mail-08 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 internet-drafts@ietf.org Tue Sep 17 11:49:54 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF09311E82E6; Tue, 17 Sep 2013 11:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UDE29RyI+MmV; Tue, 17 Sep 2013 11:49:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3051611E812B; Tue, 17 Sep 2013 11:49:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.71.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130917184954.13174.93816.idtracker@ietfa.amsl.com> Date: Tue, 17 Sep 2013 11:49:54 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-json-merge-patch-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 18:49:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Working G= roup of the IETF. Title : The application/json-merge-patch Media Type Author(s) : James M Snell Filename : draft-ietf-appsawg-json-merge-patch-01.txt Pages : 11 Date : 2013-09-17 Abstract: This specification defines the application/json-merge-patch media type and its intended use with the HTTP PATCH method defined by RFC 5789. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-json-merge-patch There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-json-merge-patch-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-json-merge-patch-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 dret@berkeley.edu Tue Sep 17 12:07:01 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6270111E8475 for ; Tue, 17 Sep 2013 12:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.166 X-Spam-Level: X-Spam-Status: No, score=-6.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2SGn4Blku5t6 for ; Tue, 17 Sep 2013 12:06:54 -0700 (PDT) Received: from cm03fe.IST.Berkeley.EDU (cm03fe.IST.Berkeley.EDU [169.229.218.144]) by ietfa.amsl.com (Postfix) with ESMTP id 3F7A111E812E for ; Tue, 17 Sep 2013 12:06:54 -0700 (PDT) Received: from c-24-6-239-29.hsd1.ca.comcast.net ([24.6.239.29] helo=dretair.local) by cm03fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1VM0bs-0000TA-BB; Tue, 17 Sep 2013 12:06:53 -0700 Message-ID: <5238A849.50009@berkeley.edu> Date: Tue, 17 Sep 2013 12:06:49 -0700 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "apps-discuss@ietf.org application-layer protocols" , James Snell References: <20130917184954.13174.93816.idtracker@ietfa.amsl.com> In-Reply-To: <20130917184954.13174.93816.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-json-merge-patch-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 19:07:01 -0000 hello james. On 2013-09-17 11:49 , 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 application/json-merge-patch Media Type > Author(s) : James M Snell > Filename : draft-ietf-appsawg-json-merge-patch-01.txt > Pages : 11 > Date : 2013-09-17 > > Abstract: > This specification defines the application/json-merge-patch media > type and its intended use with the HTTP PATCH method defined by RFC > 5789. i think it would be useful if the draft mentioned http://tools.ietf.org/html/rfc6902 and explained the differences, and maybe even tried to explain when to use one and when to use the other. after all, both specs are about how to use PATCH requests with JSON. shouldn't the media type name be application/json-merge-patch+json with http://tools.ietf.org/html/rfc6839 in mind? thanks and cheers, dret. -- erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | | UC Berkeley - School of Information (ISchool) | | http://dret.net/netdret http://twitter.com/dret | From ietf-secretariat-reply@ietf.org Tue Sep 17 12:07:04 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2708711E82CD for ; Tue, 17 Sep 2013 12:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.554 X-Spam-Level: X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CEGVEhuCgeYq for ; Tue, 17 Sep 2013 12:07:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CA71E11E8561 for ; Tue, 17 Sep 2013 12:07:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: apps-discuss@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.71.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130917190703.20018.61964.idtracker@ietfa.amsl.com> Date: Tue, 17 Sep 2013 12:07:03 -0700 From: IETF Secretariat Subject: [apps-discuss] Milestones changed for appsawg WG X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 19:07:04 -0000 Changed milestone "Publication requested for draft-ietf-appsawg-uri-get-off-my-lawn", set state to active from review, accepting new milestone. URL: http://datatracker.ietf.org/wg/appsawg/charter/ From superuser@gmail.com Tue Sep 17 12:16:14 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB87E11E82EE for ; Tue, 17 Sep 2013 12:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fF-GPJdKU3VD for ; Tue, 17 Sep 2013 12:16:14 -0700 (PDT) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 38A5A11E8138 for ; Tue, 17 Sep 2013 12:16:14 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id x55so5434432wes.38 for ; Tue, 17 Sep 2013 12:16:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=PVfkWE0cGAQt8+Ev0MwYibYIH2ADWDnQdgiu0bx40B8=; b=L68JxiytPQ1ARslzTPRF61YGaEkzloYHYAs1frvAMFOBTdNhzKqBRD9xr+sQZvAq0p GJgw6W9c3LSju51Pf+p3u9ABb84FUacT641wXB/wSEFOnQOe4g3YzX0cdgQDnxvkCvEU z04tbm2sEY6T4golVEm4bZh4ZxV8cDP0P6fSw0AE6zcZMn4+vDQDPtvSfuvnCVWdZox0 Dt7HV5Gia1voXMK7QEI/Tizu1ftmDv7r2uTuNvhmoC/Uzd8vONTZt80mW7XSnSS4TNGH koGYJVuqyec2E3SAo1TIqBRekaH7dGMNki5nnw6hDYx06YpvvHNxO2rZdMgwRzqxMkvd xW5g== MIME-Version: 1.0 X-Received: by 10.194.174.36 with SMTP id bp4mr27833765wjc.7.1379445373394; Tue, 17 Sep 2013 12:16:13 -0700 (PDT) Received: by 10.180.106.169 with HTTP; Tue, 17 Sep 2013 12:16:13 -0700 (PDT) Date: Tue, 17 Sep 2013 12:16:13 -0700 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=089e0141a0ae77e92f04e6992756 Subject: [apps-discuss] Working Group Last Call: draft-ietf-appsawg-json-merge-patch X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 19:16:15 -0000 --089e0141a0ae77e92f04e6992756 Content-Type: text/plain; charset=ISO-8859-1 This note begins Working Group Last Call for draft-ietf-appsawg-json-merge-patch, ending October 4, 2013. Please review the document and post review comments to this list. Please indicate in your reply whether you support publication in its current form, with your constructive comments accommodated, or if it needs more development. A simple "+1" is not especially useful. The more detailed your review comments are, the more useful they are. We also need to see enough of these to be able to say unsarcastically that the document has consensus support of the working group. Thanks, -MSK, APPSAWG co-chair --089e0141a0ae77e92f04e6992756 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This note begins Working Group Last Ca= ll for draft-ietf-appsawg-json-merge-patch, ending October 4, 2013.

=
Please review the document and post review comments to this list.=A0 = Please indicate in your reply whether you support publication in its curren= t form, with your constructive comments accommodated, or if it needs more d= evelopment.=A0 A simple "+1" is not especially useful.=A0 The mor= e detailed your review comments are, the more useful they are.

We also need to see enough of these to be able to say unsarcastic= ally that the document has consensus support of the working group.

<= /div>Thanks,

-MSK, APPSAWG co-chair

--089e0141a0ae77e92f04e6992756-- From jasnell@gmail.com Tue Sep 17 12:26:04 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A032A11E84BB for ; Tue, 17 Sep 2013 12:26:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-IAtDuv14RY for ; Tue, 17 Sep 2013 12:26:03 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 9A2DD11E8140 for ; Tue, 17 Sep 2013 12:26:03 -0700 (PDT) Received: by mail-ob0-f169.google.com with SMTP id wp4so6249615obc.28 for ; Tue, 17 Sep 2013 12:26:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Q1nzhRTwUqn1Nf1fSf0lTvfgD9E54KE2umxZJC8PRc0=; b=XbzJ0PpxwFORk1QHxtgM8/IKyrSpct5++s2d06/Y1wvvahMMpPHqt9L9ED1m0LItou tTlX+BHvu8kk/ud6J1/aNDPH6bio4oKxTGaj1/dj9xP+BDJdR2GJT6C6GOrwg7tV2X6j aGru1yregZ1XnAAmP+5rfdYh687hJCq+QVyd77vF597gevkjqL3bjP7t4jz8s6jHfw88 eqV7Fo2OqknZ7rL1b7E3s2KY1FcKVQPkUOc8o9fWC70Bc+kmA7vlWBOCU/EoaLfUArI6 OrMTEOvdKh4gIrsQWe2KbaPXxUByWXPOjjBwA9gQif6e7bMn5EL9mae90+lpAuqAJHNX idLQ== X-Received: by 10.182.60.194 with SMTP id j2mr30829542obr.2.1379445963090; Tue, 17 Sep 2013 12:26:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.124.137 with HTTP; Tue, 17 Sep 2013 12:25:42 -0700 (PDT) In-Reply-To: <5238A849.50009@berkeley.edu> References: <20130917184954.13174.93816.idtracker@ietfa.amsl.com> <5238A849.50009@berkeley.edu> From: James M Snell Date: Tue, 17 Sep 2013 12:25:42 -0700 Message-ID: To: Erik Wilde Content-Type: text/plain; charset=UTF-8 Cc: "apps-discuss@ietf.org application-layer protocols" Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-json-merge-patch-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 19:26:04 -0000 On Tue, Sep 17, 2013 at 12:06 PM, Erik Wilde wrote: > hello james. >[snip] > > i think it would be useful if the draft mentioned > http://tools.ietf.org/html/rfc6902 and explained the differences, and maybe > even tried to explain when to use one and when to use the other. after all, > both specs are about how to use PATCH requests with JSON. > Ok, I can take a stab at something here. > shouldn't the media type name be application/json-merge-patch+json with > http://tools.ietf.org/html/rfc6839 in mind? > I'd be fine with application/merge-patch+json - James > thanks and cheers, > > dret. > > -- > erik wilde | mailto:dret@berkeley.edu - tel:+1-510-2061079 | > | UC Berkeley - School of Information (ISchool) | > | http://dret.net/netdret http://twitter.com/dret | From dave@cridland.net Tue Sep 17 12:49:18 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64DFF11E8570 for ; Tue, 17 Sep 2013 12:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7NSjb+Xlbkzz for ; Tue, 17 Sep 2013 12:49:17 -0700 (PDT) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 76B1311E854E for ; Tue, 17 Sep 2013 12:49:17 -0700 (PDT) Received: by mail-ob0-f175.google.com with SMTP id uz6so5977864obc.6 for ; Tue, 17 Sep 2013 12:49:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=d1DMPGpt8Yw9wPEwjeSKOoAfRYdfKp0Eg9rLijhDNBw=; b=DrRzLYudzjLm34kWyWL5dUSnF2LnHVFC9ko0JZpot7GTGr1FYd/9RJmlZJwBaYCJbJ 9KEGc+z23FvGy6hpkjR98zTHLyFnGgD+5KkhqXZftvvaxdoFY53LXPy7EUeT8yT9tq4u Uvbdr6vzQejwV1WCGktGdgOUvucmOb6ke6Vms= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=d1DMPGpt8Yw9wPEwjeSKOoAfRYdfKp0Eg9rLijhDNBw=; b=XaZ6eodeC0H0SGXgnGQZzAoKtz4lFzlfJ2tXBfiMA8EUjCVz1AljXdYXTxr3sOnmsW DSPtF8nUSH6i+zcIA2Yzv4+nQicGLMzz3nkWDfY52V4DlcyHAokI1aixMNKC3uly4JRJ ADOBq4h00N8rDLFyDI9ZTHmKO4aS78q5eY9YTeXfK1t9k+LRWnxdYqF9L6TrnTDf5+lh jiVaOHpwFdli2LlM+BM8tWg0rNNFgeYmBadI4GGy68Aa4VnnnOyUYA6akaAHEQ5ZIY2a vIgdOpYGxJUN9AmRZ7HFdKXWjIIeJA30/54ZMZfodSCTR72mnd/6gUNjFadjVqlGCzIA JuMw== X-Gm-Message-State: ALoCoQlaSK6sKV2jcE8wrLnau/kaf7GT+7fCRW7oWh9ukTv9nnpuOTBKMKYH+MEsR9oTM31q9429 MIME-Version: 1.0 X-Received: by 10.60.116.230 with SMTP id jz6mr6549369oeb.21.1379447355672; Tue, 17 Sep 2013 12:49:15 -0700 (PDT) Received: by 10.60.121.97 with HTTP; Tue, 17 Sep 2013 12:49:15 -0700 (PDT) In-Reply-To: References: <828708BA-E4BF-48DE-9E44-3C21063AA3D8@gmail.com> <6.2.5.6.2.20130813230340.0b0d4968@resistor.net> Date: Tue, 17 Sep 2013 20:49:15 +0100 Message-ID: From: Dave Cridland To: "Henry S. Thompson" Content-Type: multipart/alternative; boundary=089e0115e84a9f682204e6999d30 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Working Group Last Call: draft-ietf-appsawg-xml-mediatypes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 19:49:18 -0000 --089e0115e84a9f682204e6999d30 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable A quick review. Top of page 6, inside =A73, there's a slightly mangled paragraph: The top-level media type "text" has some restrictions on MIME entities and they are described in [RFC2045] and [RFC2046]. In particular, for transports other than HTTP [RFC2616] or HTTPS (which uses a MIME-like mechanism). the UTF-16 family, UCS-4, and UTF-32 are not allowed However, section 4.3.3 of [XML] says: Beyond the apparent mangling, I'm pretty sure that nothing prevents the use of UTF-16 in a text/xml within email, as long as it has a suitable Content-Transfer-Encoding for the transmission path (ie, base64, probably). The encoding considerations in =A73.1, which =A73.2 points to, seem to agre= e with me. I think what it's trying to say is that an XML document using UTF-16 encoding will by definition have NUL octets, and these are not allowed unencoded along 7- or 8-bit transmission paths, and therefore must be encoded using Base64 on non-binary paths. =A711 I don't know if it's worthwhile discussing XML based attacks such as the Billion Laughs attack; I don't think it'd hurt. Otherwise, all looks good to my eyes. On Tue, Sep 17, 2013 at 12:32 PM, Henry S. Thompson wrote= : > At 22:52 13-08-2013, Murray S. Kucherawy wrote: > > > A gentle reminder that this WGLC is in effect, closing in a few > > days. To date there have been no comments or reviews on the WGLC at > > all. It will be hard for me to argue that consensus exists without > > at least a few reviews on the record. > > This reminder produced only one reply, with what I believe are > essentially editorial suggestions. _Please_ can we get a few more > reviews, even if they are just "Yes, it's time to take this forward". > > This RFC documents a moderately important part of the Web > infrastructure, and its predecessor is out-of-date and indeed > misleading in important ways, so we really do need to get it out the > door. > > Thanks, > > ht > -- > Henry S. Thompson, School of Informatics, University of Edinburgh > 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-444= 0 > Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk > URL: http://www.ltg.ed.ac.uk/~ht/ > [mail from me _always_ has a .sig like this -- mail without it is forged > spam] > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --089e0115e84a9f682204e6999d30 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
A quick review.

Top of page 6, insi= de =A73, there's a slightly mangled paragraph:

=A0 =A0 =A0 The top-level media type "text" has some restri= ctions on MIME
=A0 =A0 =A0 entities and they are described in [RFC2045] and [RFC2046]= . =A0In
=A0 =A0 =A0 particular, for transports other than HTTP [R= FC2616] or HTTPS
=A0 =A0 =A0 (which uses a MIME-like mechanism). = =A0the UTF-16 family, UCS-4, and
=A0 =A0 =A0 UTF-32 are not allowed However, section 4.3.3 of [XML] say= s:

Beyond the apparent mangling, I'm pre= tty sure that nothing prevents the use of UTF-16 in a text/xml within email= , as long as it has a suitable Content-Transfer-Encoding for the transmissi= on path (ie, base64, probably). The encoding considerations in =A73.1, whic= h =A73.2 points to, seem to agree with me.

I think what it's trying to say is that an XML docu= ment using UTF-16 encoding will by definition have NUL octets, and these ar= e not allowed unencoded along 7- or 8-bit transmission paths, and therefore= must be encoded using Base64 on non-binary paths.

=A711

I don't know if it&#= 39;s worthwhile discussing XML based attacks such as the Billion Laughs att= ack; I don't think it'd hurt.

Otherwise, a= ll looks good to my eyes.


On Tue,= Sep 17, 2013 at 12:32 PM, Henry S. Thompson <ht@inf.ed.ac.uk> wrote:
At 22:52 13-08-2013, Murra= y S. Kucherawy wrote:

> A gentle reminder that this WGLC is in effect, closing in a few
> days. =A0To date there have been no comments or reviews on the WGLC at=
> all. =A0It will be hard for me to argue that consensus exists wi= thout
> at least a few reviews on the record.

This reminder produced only one reply, with what I believe are
essentially editorial suggestions. =A0_Please_ can we get a few more
reviews, even if they are just "Yes, it's time to take this forwar= d".

This RFC documents a moderately important part of the Web
infrastructure, and its predecessor is out-of-date and indeed
misleading in important ways, so we really do need to get it out the
door.

Thanks,

ht
--
=A0 =A0 =A0 =A0Henry S. Thompson, School of Informatics, University of Edin= burgh
=A0 =A0 =A0 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650= -4440
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0URL: http://www.ltg.ed.ac.uk/~ht/
=A0[mail from me _always_ has a .sig like this -- mail without it is forged= spam]
_____________________= __________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--089e0115e84a9f682204e6999d30-- From julian.reschke@gmx.de Tue Sep 17 13:22:20 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 897C411E8319 for ; Tue, 17 Sep 2013 13:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.299 X-Spam-Level: X-Spam-Status: No, score=-104.299 tagged_above=-999 required=5 tests=[AWL=-2.300, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VC1-wR-DlQeW for ; Tue, 17 Sep 2013 13:22:14 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id DA42811E81A7 for ; Tue, 17 Sep 2013 13:22:13 -0700 (PDT) Received: from [192.168.1.102] ([217.91.35.233]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LjaEi-1VssZ63JM0-00bbig for ; Tue, 17 Sep 2013 22:22:09 +0200 Message-ID: <5238B9E9.7010204@gmx.de> Date: Tue, 17 Sep 2013 22:22:01 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" , "apps-discuss@ietf.org" References: <828708BA-E4BF-48DE-9E44-3C21063AA3D8@gmail.com> In-Reply-To: <828708BA-E4BF-48DE-9E44-3C21063AA3D8@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:BKifSCCUGcR3lCRHUKSppPlp54+3pZMW1WKB9I6tqi2fTzdX3I3 0+0gM/8s8spSfePYfazuJRByFFPqXXj0plL1KZ3w55k1oJCQGNSNwW1F0grPN9RNas/15zE ZTVJFXOpBB1Y0COb5vAt3aUWcMnQ08vqVEa/GrHFrQXl1KRsHAV43B7NNBVEYT7UZmMX8qq 8KWI40rPONLWd202rvr0Q== Subject: Re: [apps-discuss] Working Group Last Call: draft-ietf-appsawg-xml-mediatypes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 20:22:20 -0000 On 2013-07-29 10:08, Murray S. Kucherawy wrote: > This note begins a Working Group Last Call for draft-ietf-appsawg-xml-mediatypes, ending on Friday, August 16. Please provide reviews and comments on this list or privately to the authors as soon as possible. > ... Here's my late feedback (IETF, interim meetings, vacation, etc pp): Updates: 4289, 6839 (if approved) Really? Major differences from [RFC3023] are alignment of charset handling for text/xml and text/xml-external-parsed-entity with application/ xml, the addition of XPointer and XML Base as fragment identifiers and base URIs, respectively, mention of the XPointer Registry, and updating of many references. I don't think this needs to be in the Abstract. Also, references are discouraged here because the abstract should be usable stand-alone. So maybe move into the Introduction. document entities The media types application/xml or text/xml MAY be used s/used/used./ Application/xml and application/xml-external-parsed-entity are recommended. Compared to [RFC2376] or [RFC3023], this specification alters the charset handling of text/xml and text/xml-external-parsed- entity, treating them no differently from the respective application/ types. The reasons are as follows: s/Application/application/ Also, avoid lowercase "recommended" it it's not a "RECOMMENDED". Conflicting specifications regarding the character encoding have caused confusion. On the one hand, [RFC2046] specifies "The default character set, which must be assumed in the absence of a charset parameter, is US-ASCII.", [RFC2616] Section 3.7.1, defines that "media subtypes of the 'text' type are defined to have a default charset value of 'ISO-8859-1'", and [RFC2376] as well as [RFC3023] specify the default charset is US-ASCII. I think this just repeats history already captureed in RFC 6557. Do we really need to repeat it over here? The current situation, reflected in this specification, has been simplified by [RFC6657] updating [RFC2046] to remove the US-ASCII default. Furthermore, in accordance with [RFC6657]'s other recommendations, [HTTPbis] changes [RFC2616] by removing the ISO-8859-1 default and not defining any default at all. This is a bit misleading as the change in httpbis predates RFC6657 significantly. The top-level media type "text" has some restrictions on MIME entities and they are described in [RFC2045] and [RFC2046]. In particular, for transports other than HTTP [RFC2616] or HTTPS (which uses a MIME-like mechanism). the UTF-16 family, UCS-4, and It would be helpful if the reference to 2045/6 would be a bite more specific. I'd also prefer to get rid of all RFC2616 references except when referring to the specification's history. However, developers of such media types are STRONGLY RECOMMENDED to use this specification as a basis for their registration. In particular, the charset parameter, if used, MUST agree with the in- band XML encoding of the XML entity, as described in Section 3.6, in order to enhance interoperability. There's no "STRONGLY" keyword. In general, I'd avoid to use BCP14 keywords for recommendations to people. Encoding considerations: This media type MAY be encoded as appropriate for the charset and the capabilities of the underlying MIME transport. For 7-bit transports, data in either UTF-8 or I don't understand the "MAY" here. Published specification: Extensible Markup Language (XML) 1.0 (Fifth Edition) [XML], Extensible Markup Language (XML) 1.1 (Second Edition) [XML1.1]. OK, so I can use the same media type for both XML 1.0 and 1.1. However, the way this is phrased makes it appear as if XML 1.1 is somehow more ... recent when in fact it was a dead-end. I recommend dropping the references about 1.1 from everywhere, and just have a single place that points out that what's said about 1.0 is also true for 1.1. Interoperability considerations: XML DTDs have proven to be interoperable by DTD authoring tools and XML browsers, among others. What is an "XML browser"? If this is about web browsers I really have my doubts that they work interoperably :-) The charset parameter MUST only be used, when the charset is reliably known and agrees with the in-band XML encoding declaration. This s/used,/used/ Also, what if there is no in-band declaration? authoritatively the charset of the XML MIME entity. The charset parameter can also be used to provide protocol-specific operations, such as charset-based content negotiation in HTTP. That's misleading. charset-based content negotiation happens by use of Accept-Encoding, bot the charset parameter. There are several reasons that the charset parameter is optionally allowed. First, recent web servers have been improved so that users That text is 12 years old. We may want to drop or rephrase it :-) can specify the charset parameter. Second, [RFC2130] (informative) specifies that the recommended specification scheme is the "charset" parameter. That refers to a document from 1996. Is this really relevant here? On the other hand, it has been argued that the charset parameter should be omitted and the mechanism described in Appendix F of [XML] (which is non-normative) should be solely relied on. This approach would allow users to avoid configuration of the charset parameter; an XML document stored in a file is likely to contain a correct encoding declaration or BOM (if necessary), since the operating system does not typically provide charset information for files. If users would like to rely on the in-band XML encoding declaration or BOM and/or to conceal charset information from non-XML processors, they can omit the parameter. This now is really the recommended approach, no? Maybe the whole of 3.6.1 should be removed then. Uniform Resource Identifiers (URIs) may contain fragment identifiers (see Section 3.5 of [RFC3986]). Likewise, Internationalized Resource Identifiers (IRIs) [RFC3987] may contain fragment identifiers. s/may/can/ Also, the reference to RFC3987 really doesn't add anything useful here. See Section 8.1 for additional rquirements which apply when an XML- based MIME media type follows the naming convention '+xml'. s/rquirenents/requirements/ If [XPointerFramework] and [XPointerElement] are inappropriate for some XML-based media type, it SHOULD NOT follow the naming convention '+xml'. Really? Why not? What about application/xhtml+xml? When a URI has a fragment identifier, it is encoded by a limited subset of the repertoire of US-ASCII [ASCII] characters, as defined in [RFC3986]. When an IRI contains a fragment identifier, it is encoded by a much wider repertoire of characters. The conversion between IRI fragment identifiers and URI fragment identifiers is presented in Section 7 of [RFC3987]. I recommend to drop the IRI specific part. This is not specific to XML types. Note that the base URI may be embedded in a different MIME entity, since the default value for the xml:base attribute may be specified in an external DTD subset or external parameter entity. s/may/might/ s/may/can/ application/xml, application/xml-external-parsed-entity, and application/xml-dtd, text/xml and text/xml-external-parsed-entity are to be used with [XML] In all examples herein where version="1.0" is s/[XML]/[XML]./ This specification recommends the use of a naming convention (a suffix of '+xml') for identifying XML-based MIME media types, s/MIME// (there may be more instances of this) whatever their particular content may represent, in line with the What is the "whatever their particular content may represent" about? When a new media type is introduced for an XML-based format, the name of the media type SHOULD end with '+xml'. This convention will allow Which may be in conflict with the SHOULD NOT I complained about earlier on :-) NOTE: Section 14.1 of HTTP [RFC2616] does not support Accept headers of the form "Accept: */*+xml" and so this header MUST NOT be used in this way. Instead, content negotiation [RFC2703] could potentially be used if an XML-based MIME type were needed. Please cite HTTPbis P2. Also, content negotiation is defined by HTTP, not RFC 2703. XML generic processing is not always appropriate for XML-based media types. For example, authors of some such media types may wish that the types remain entirely opaque except to applications that are specifically designed to deal with that media type. By NOT following the naming convention '+xml', such media types can avoid XML-generic processing. Since generic processing will be useful in many cases, however -- including in some situations that are difficult to predict ahead of time -- those registering media types SHOULD use the '+xml' convention unless they have a particularly compelling reason not to. I recommend to avoid the use of SHOULD here. Just explain the pros and cons. The registration process for specific '+xml' media types is described in [RFC6838] and [RFC6839]. The registrar for the IETF tree will Just RFC6838, as far as I can tell. The use of the charset parameter is STRONGLY RECOMMENDED, since this information can be used by XML processors to determine authoritatively the charset of the XML MIME entity. If there are some reasons not to follow this advice, they SHOULD be included as part of the registration. As shown above, two such reasons are "UTF-8 only" or "UTF-8 or UTF-16 only". That's misleading. People may read it as saying that the *presence* of the charset parameter is RECOMMENDED. In practice these constraints imply that for a fragment identifier addressed to an instance of a specific "xxx/yyy+xml" type, there are three cases: For fragment identifiers matching the syntax defined in Section 5, where the fragment identifier resolves per the rules specified there, then process as specified there; Section 5 does not define the syntax (other then referencing XPointer). So this is a bit hard to process. For fragment identifiers _not_ matching the syntax defined in Section 5, then process as specified in "xxx/yyy+xml". What would be an example for this case? All the examples below apply to all five media types declared above in Section 3, as well as to any media types declared using the '+xml' convention. See the XML MIME entities table (Section 3, Paragraph 2) Well, unless that type does not define the charset parameter, right? This section is non-normative. In particular, note that all "MUST" language herein reproduces or summarizes the consequences of normative statement already made above, and have no independent normative force. Can we avoid the use of MUST here, then? :-) Content-type charset: charset="utf-8" Maybe it would be less confusing to say: "charset specified in content-type:" printable or base64. For an 8-bit clean transport (e.g., 8BITMIME ESMTP or NNTP), or a binary clean transport (e.g., HTTP), no content- transfer-encoding is necessary. ...as HTTP does not even define content-transfer-encoding. (same applies to parts below) As described in [RFC2781], the UTF-16 family MUST NOT be used with media types under the top-level type "text" except over HTTP or HTTPS (see section 19.4.1 of [RFC2616] for details). Hence this example is Not sure how that section of 2616 is relevant here. Omitting the charset parameter is NOT RECOMMENDED for application/... when used with transports other than HTTP or HTTPS---text/... SHOULD NOT be used for 16-bit MIME with transports other than HTTP or HTTPS (see discussion above (Section 9.2, Paragraph 6)). Please avoid uppercasing not-BCP14 keywords :-) Since the charset parameter is provided in the Content-Type header and differs from the XML encoding declaration, MIME and XML processors will not interoperate. MIME processors will treat the enclosed entity as UTF-8 encoded. That is, the "iso-8859-1" encoding will be ignored. XML processors on the other hand will ignore the charset parameter and treat the XML entity as encoded in iso-8859-1. Do we have a definition of "MIME processor"? As described in Section 8, this specification updates the [RFC6838] and [RFC6839] registration process for XML-based MIME types. My understanding is that the registration process is defined in 6838 only. the most dangerous option available to crackers is redefining default s/crackers/attackers/ Fourth, many references are updated, and the existence and relevance of XML 1.1 acknowledged. Finally, a number of justifications and As far as I can tell, XML 1.1 is totally irrelevant... Best regards, Julian From vkg@bell-labs.com Tue Sep 17 13:59:32 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C169E11E82F1; Tue, 17 Sep 2013 13:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pHccgZuEJbpM; Tue, 17 Sep 2013 13:59:27 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id CA33311E810A; Tue, 17 Sep 2013 13:59:27 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r8HKxOeh026903 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 17 Sep 2013 15:59:24 -0500 (CDT) Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id r8HKxNQn006003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 17 Sep 2013 15:59:23 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.237.229]) by umail.lucent.com (8.13.8/TPES) with ESMTP id r8HKxNnN011761; Tue, 17 Sep 2013 15:59:23 -0500 (CDT) Message-ID: <5238C3D6.2010907@bell-labs.com> Date: Tue, 17 Sep 2013 16:04:22 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130805 Thunderbird/17.0.8 MIME-Version: 1.0 To: James Polk References: <52387B2A.9020102@bell-labs.com> <201309172004.r8HK4jft009629@rcdn-core-4.cisco.com> In-Reply-To: <201309172004.r8HK4jft009629@rcdn-core-4.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Cc: draft-ietf-insipid-session-id-reqts.all@tools.ietf.org, IESG IESG , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-insipid-session-id-reqts-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 20:59:32 -0000 On 09/17/2013 03:04 PM, James Polk wrote: > Vijay > > comments below James: Thanks for your time. More inline. > I guess I don't know what you are asking for clarity on. The INSIPID > solutions draft (mostly done, if we can get around a backwards > compatibility inconsistency within the WG) certainly has conferencing as > one of the main use-cases of that draft. However, these two drafts we > written at about the same time (with the reqs ID reaching WG consensus > first), and by pretty much the same author set (at least the same two > editors) and some wording might have been overlooked in one draft where > it is in the other draft. In that case, I would strongly suggest to harmonize the text between the mechanism draft and the requirement draft. You can see the problem if the former considers conferencing in scope and the latter does not. > That's a roundabout way of saying that if you or anyone has suggested > text or a list of bullets/summary of what should be here in the reqs > draft, we'll certainly give strong consideration to putting that text > in. Paul and I did struggle with this section of what is and what is not > a communication session, and felt a short list would be better than a > longer, more exhaustive list. It's picking how many examples - but not > too many - are included. Any help here would be appreciated. But it seems to me that the short list in the draft right now precludes the use cases that the mechanism draft supports. So, at the very least, the current short list should be expunged. As to what exactly is a communication session? Hmmm ... initially I was going to suggest that the Replaces header creates a new communication session, disjoint from its parent; but it seems that the mechanism draft considers the Replaces to have the same session identification (Section 6 of draft-ietf-insipid-session-id-02). So, in the end I am not sure what to suggest here. Alternatively, why bother providing a list of what does NOT constitute a communication session? Unless hampered by interoperation between protocols (i.e., H.323 to SIP, Q.931 to SIP and vice-versa), it seems to me that the notion of a communication session is already defined in your draft. Just leave it at that. No? > we'll attempt to make this more clear - that "...the identifier must be > transmitted over a confidential and privacy preserving channel..." as > you say. Or more appropriately, the SIP message containing the identifier must be transmitted over a confidential and privacy preserving channel. > Thanks for the review Thank you for taking my feedback into consideration. Cheers, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq From derhoermi@gmx.net Tue Sep 17 14:10:47 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE4C811E857C for ; Tue, 17 Sep 2013 14:10:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6cBjtQDwUitR for ; Tue, 17 Sep 2013 14:10:43 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id A459B11E8587 for ; Tue, 17 Sep 2013 14:10:42 -0700 (PDT) Received: from netb.Speedport_W_700V ([91.35.56.57]) by mail.gmx.com (mrgmx102) with ESMTPA (Nemesis) id 0MC7em-1VDH7I1yLY-008sKT for ; Tue, 17 Sep 2013 23:10:40 +0200 From: Bjoern Hoehrmann To: Dave Cridland Date: Tue, 17 Sep 2013 23:10:38 +0200 Message-ID: References: <828708BA-E4BF-48DE-9E44-3C21063AA3D8@gmail.com> <6.2.5.6.2.20130813230340.0b0d4968@resistor.net> In-Reply-To: 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:DPKAZno+V0JqGHDj3zBpuz1DatN1U/YYZgBQjRmky6SXjBcwd8Y Vf0LwfNq4QcYIC/xYGuo5ZQtz8qBOhx9HXEefkHKJO1dE5HmS98Qa4O5Xsr/UBjji7R46tA fBE8MjuGUMBkb7AGbRka/4M4XdssCPwCqEZ2WaO1UZikRLZ2tYqCX+hxDjG+/ye28Qjf5x7 Jr+hbFcdeRruiWlLhutRA== Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Working Group Last Call: draft-ietf-appsawg-xml-mediatypes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 21:10:47 -0000 * Dave Cridland wrote: >A quick review. > >Top of page 6, inside §3, there's a slightly mangled paragraph: > > The top-level media type "text" has some restrictions on MIME > entities and they are described in [RFC2045] and [RFC2046]. In > particular, for transports other than HTTP [RFC2616] or HTTPS > (which uses a MIME-like mechanism). the UTF-16 family, UCS-4, and > UTF-32 are not allowed However, section 4.3.3 of [XML] says: > >Beyond the apparent mangling, I'm pretty sure that nothing prevents the use >of UTF-16 in a text/xml within email, as long as it has a suitable >Content-Transfer-Encoding for the transmission path (ie, base64, probably). >The encoding considerations in §3.1, which §3.2 points to, seem to agree >with me. > >I think what it's trying to say is that an XML document using UTF-16 >encoding will by definition have NUL octets, and these are not allowed >unencoded along 7- or 8-bit transmission paths, and therefore must be >encoded using Base64 on non-binary paths. It's partly about . -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From paulej@packetizer.com Tue Sep 17 14:14:20 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A39111E81E6; Tue, 17 Sep 2013 14:14:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZBeXwXIjeQo; Tue, 17 Sep 2013 14:14:15 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id E7CC611E812D; Tue, 17 Sep 2013 14:14:14 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r8HLEBeq022983 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 17 Sep 2013 17:14:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1379452452; bh=8LCfy6woLdFXL9PLttTnTMROQFU8llUL696V8KsO1JE=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=ZM6LWumgdO5T4aBI+ux7dJEacl4UHVCxxCieMX53XxA5QcCVSAEBu+CwIrRDo0ezF 0V0EmYBTWZmA8ayPSGSfK4ssCknsqUvES1ZVw++s2TNx+67fpAQ/E+uGN/+kYvRmQ8 wTkrtzkH6Vjd93zw2uo224g27fc6seMUODvUtgi4= From: "Paul E. Jones" To: "'James Polk'" , "'Vijay K. Gurbani'" , References: <52387B2A.9020102@bell-labs.com> <201309172004.r8HK4jft009629@rcdn-core-4.cisco.com> In-Reply-To: <201309172004.r8HK4jft009629@rcdn-core-4.cisco.com> Date: Tue, 17 Sep 2013 17:14:26 -0400 Message-ID: <01b601ceb3ea$e47a42e0$ad6ec8a0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQIaHTzUoV3TKePfh5W0TyKDGDYHbgGbV8E2mSa/vaA= Content-Language: en-us Cc: 'IESG IESG' , apps-discuss@ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-insipid-session-id-reqts-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 21:14:20 -0000 Guys, > > Unless, of course, you are stating that the identifier must be > > transmitted over a confidential and privacy preserving channel (which > > seems to be the gist of the last sentence of the section). If that > > is the case, then you may want to highlight in a more prominent form > > than currently stated. > > we'll attempt to make this more clear - that > "...the identifier must be transmitted over a > confidential and privacy preserving channel..." as you say. It's not critical that this value be hidden, necessarily. Ideally, all SIP signaling would be secured against snooping, but that does not directly affect the Session-ID header value itself. The main point of that paragraph is that we adhere to REQ6 to ensure that values are unique in time and space. They need to be random such that somebody who wants to be a troublemaker cannot easily guess what Session-ID values might be in use and re-use them for a different call in the same time and place. Paul From vkg@bell-labs.com Tue Sep 17 14:32:42 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC92F11E85C1; Tue, 17 Sep 2013 14:32:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vVRVH-o8uYYH; Tue, 17 Sep 2013 14:32:37 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id D5FB011E85BA; Tue, 17 Sep 2013 14:31:36 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r8HLVYgC008420 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 17 Sep 2013 16:31:35 -0500 (CDT) Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id r8HLVYsa030416 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 17 Sep 2013 16:31:34 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.237.229]) by umail.lucent.com (8.13.8/TPES) with ESMTP id r8HLVY40001684; Tue, 17 Sep 2013 16:31:34 -0500 (CDT) Message-ID: <5238CB61.6060703@bell-labs.com> Date: Tue, 17 Sep 2013 16:36:33 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130805 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Paul E. Jones" References: <52387B2A.9020102@bell-labs.com> <201309172004.r8HK4jft009629@rcdn-core-4.cisco.com> <01b601ceb3ea$e47a42e0$ad6ec8a0$@packetizer.com> In-Reply-To: <01b601ceb3ea$e47a42e0$ad6ec8a0$@packetizer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Cc: draft-ietf-insipid-session-id-reqts.all@tools.ietf.org, 'James Polk' , 'IESG IESG' , apps-discuss@ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-insipid-session-id-reqts-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 21:32:42 -0000 On 09/17/2013 04:14 PM, Paul E. Jones wrote: > The main point of that paragraph is that we adhere to REQ6 to ensure that > values are unique in time and space. They need to be random such that > somebody who wants to be a troublemaker cannot easily guess what Session-ID > values might be in use and re-use them for a different call in the same time > and place. But that is not what the text in question says (c.f., third paragraph of Section 7). The text talks about "surreptitiously spoof[ing] the identifier". To me this means changing the identifier such that the origin does not know that the change occurred. If what you are worried about is using the same Session-ID to replay a message in the same time quantum and space, then saying what you write above is sufficient. That is, "[The identifier needs] to be random such that it is impervious to guess and reuse for a different session in the same time and space." Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq From paulej@packetizer.com Tue Sep 17 16:32:26 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0E5D11E81DB; Tue, 17 Sep 2013 16:32:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jWRsE1oofwym; Tue, 17 Sep 2013 16:32:22 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id AE7E111E81DA; Tue, 17 Sep 2013 16:32:22 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r8HNVw6x031908 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 17 Sep 2013 19:32:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1379460731; bh=l2asPz8/j3rgAs1OgE1LCbhR3IXf2JNXmbL35nyo13Q=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=qEY/hpgXpL5wdFSMElTOB9/jF/eYz6f3Eyk1QeaA94WhQc9cMaO3rnOBuI/0LTu4M jeQY234S2xX0InA8+8WH4vkyOjt5DbUPhOjaKOL1sAMPaM1ql81b/OA82JlS0kZfOm BWml5ZN9QTPwtXGt8Bi4ilnNdFOcGNG3QnAprkck= From: "Paul E. Jones" To: "'Vijay K. Gurbani'" References: <52387B2A.9020102@bell-labs.com> <201309172004.r8HK4jft009629@rcdn-core-4.cisco.com> <01b601ceb3ea$e47a42e0$ad6ec8a0$@packetizer.com> <5238CB61.6060703@bell-labs.com> In-Reply-To: <5238CB61.6060703@bell-labs.com> Date: Tue, 17 Sep 2013 19:32:11 -0400 Message-ID: <022401ceb3fe$2aca2900$805e7b00$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQIaHTzUoV3TKePfh5W0TyKDGDYHbgGbV8E2AfBFCcIBICx0CpkOYpQQ Content-Language: en-us Cc: draft-ietf-insipid-session-id-reqts.all@tools.ietf.org, 'James Polk' , 'IESG IESG' , apps-discuss@ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-insipid-session-id-reqts-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 23:32:27 -0000 Vijay, I believe that those things are covered. In that paragraph, it talks about the fact that one should an attacker who might use the same value. It then talks about the fact the value should be random (or otherwise really hard to just guess). It also talks about the secure transport of the session-ID. Aside from REQ6, none of the language in that paragraph is normative. I'm not sure exactly what you think we need to further clarify in that paragraph (the last one in Section 7), but I'm happy to make changes as you suggest. Paul > -----Original Message----- > From: Vijay K. Gurbani [mailto:vkg@bell-labs.com] > Sent: Tuesday, September 17, 2013 5:37 PM > To: Paul E. Jones > Cc: 'James Polk'; draft-ietf-insipid-session-id-reqts.all@tools.ietf.org; > 'IESG IESG'; apps-discuss@ietf.org > Subject: Re: APPSDIR review of draft-ietf-insipid-session-id-reqts-08 > > On 09/17/2013 04:14 PM, Paul E. Jones wrote: > > The main point of that paragraph is that we adhere to REQ6 to ensure > that > > values are unique in time and space. They need to be random such that > > somebody who wants to be a troublemaker cannot easily guess what > Session-ID > > values might be in use and re-use them for a different call in the same > time > > and place. > > But that is not what the text in question says (c.f., third paragraph of > Section 7). > > The text talks about "surreptitiously spoof[ing] the identifier". To me > this means changing the identifier such that the origin does not know > that the change occurred. > > If what you are worried about is using the same Session-ID to replay a > message in the same time quantum and space, then saying what you write > above is sufficient. That is, "[The identifier needs] to be random such > that it is impervious to guess and reuse for a different session in the > same time and space." > > Thanks, > > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) > Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com > Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq From hsantos@isdg.net Tue Sep 17 17:00:33 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F80611E81F4 for ; Tue, 17 Sep 2013 17:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.753 X-Spam-Level: X-Spam-Status: No, score=-102.753 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_43=0.6, J_CHICKENPOX_46=0.6, J_CHICKENPOX_47=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z-TtFQYy4GvJ for ; Tue, 17 Sep 2013 17:00:28 -0700 (PDT) Received: from secure.winserver.com (winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 08F8711E8153 for ; Tue, 17 Sep 2013 17:00:27 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=9615; t=1379462412; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=rppeziJpCOHuPIxiUnOgtRW67gU=; b=qxITZxpVw7i/cWywU18d HdGHfv30n7JMSg5MSAXlxf4sH50ZE/KB1daON6wEiy+M+LfBNiy2ikDfM5wZO0Uc aLF6Fa8pyu5xIX2yrMddfCtR8fvajgDEk2W/WSRGyHdpQUmkTlIvhqjVWjQHhFcm VjDNJRdVqy/TkkeImkwLXBs= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Tue, 17 Sep 2013 20:00:12 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1629933268.6080.4948; Tue, 17 Sep 2013 20:00:11 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=9615; t=1379462050; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=b5IZA3C YPsx/nUGa5TpIFtWkAhVXX9CxQAXVtNLcvF8=; b=HFtpIIehpLJHsp3t7pA0V3I Kw5o5qb5PA76pzTUZ+H/rbKGZM51k1LJaEph8uK/aHYTa9TNZnE7E2/ZBncoHenH o+oJHL3j7L7ye3f/lMTzsKv5nu94xHnICmcNTHPamnuN5w7+vAe5LalmpgQlkb0o prLE/+aX4QTS5oUdHlrg= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Tue, 17 Sep 2013 19:54:10 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1076330581.9.3788; Tue, 17 Sep 2013 19:54:09 -0400 Message-ID: <5238ECFD.5040004@isdg.net> Date: Tue, 17 Sep 2013 19:59:57 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Barry Leiba References: <5230F81A.2030901@bbiw.net> <52310222.6040601@dcrocker.net> <5231B4C6.9000600@isdg.net> <52331B68.1020903@isdg.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] [ietf-dkim] Fwd: Request to move RFC 5617 (ADSP) to Historic X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 18 Sep 2013 00:00:33 -0000 Hi Barry, It is difficult to ignore the total picture, to separate the judgment and logistics of a DKIM investment with (ADSP) domain signing practices support, and the suggestion to either replace it or remove the general idea of protecting restrictive Domain Signing Practices from the DKIM framework. However, I will try to outline a few key points for your consideration. First, ADSP is not complete. This WG work item was intentionally pushed aside to allow DKIM to move forward. DKIM was just recently made an IS and it is prudent for the IETF to determine if that endorsement included the basic premise and idea of Domain Signing Practice protocols along with other future considerations. There are ADSP extensions which are getting interest and increase usage if only from a tracing standpoint -- which was a major goal. This should indicate a WG review of the concepts to see if it can be completed now, as it was basically understood would eventually be done. I was hoping the DKIM IS would be begin this process. Second, ADSP or checking Domain Signing Practices (DSP) is a fundamental part of the DKIM Service Architecture as illustrated in RFC5585: | |- RFC5322 Message V +--------------------------------+ | Message Signed? | +-----+--------------------+-----+ |yes |no | | |SDID/AUID |AUID | | V | +-------------+ SDID/AUID | | Verify +---------+ | | Signature | | | +------+------+ | | pass| fail| | V | | +-------------+ | | | SDID | | | | Assessments | | | | | V V +-----+--+----+ +-------+ | | / Check \ | +--SDID-->/ Signing \ | / Practices \ | +-------+-------+ | | V V DKIM has one basic requirement for binding headers: the 5322.From header. As much as it may be desired by Reputation framework advocates, we can not separate the question of how the Author Domain is strongly related to a signed messages or even the signer of the message. We have no other anchor to work with. The signer id is still theoretical and only at the local white list level. Third, ADSP is a major part of the RFC5863 DKIM Deployment Guide . So overall, a consideration to end ADSP will need review of the entire DKIM process and usage in the market place. What is it that didn't work? What is the impact of relaxing the DKIM security threat entry points as highlighted in the threat analysis RFC4686? Forth, the mailing list interop issue was reported by me. I proved it can happen once I saw the DKIM WG mailing list begin to "eat its own dog food" by (re)signing messages and I was exploring with these implementing and exploring these exclusive policy domains. But the theory was well known and published in 2006. I wrote (in DSAP) about the need for MLS (Mail List Servers) or resigners in general who became DKIM compliant, the need to consider the security around restrictive ADSP domains: http://tools.ietf.org/html/draft-santos-dkim-dsap-00#section-3.3 3.3. Mailing List Servers Mailing List Servers (MLS) applications who are compliant with DKIM and DSAP operations, SHOULD adhere to the following guidelines: Subscription Controls MLS subscription processes should perform a DSAP check to determine if a subscribing email domain DSAP policy is restrictive in regards to mail integrity changes or 3rd party signatures. The MLS SHOULD only allow original domain policies who allow 3rd party signatures. Message Content Integrity Change List Servers which will alter the message content SHOULD only do so for original domains with optional DKIM signing practices and it should remove the original signature if present. If the List Server is not going to alter the message, it SHOULD NOT remove the signature, if present. This MLS guideline was carried on in RFC6377 "DKIM and Mailing Lists" with the same insight. Our MLS package followed thru with this required MLS RESIGNER design considerations as you can see at this subscription site: http://www.winserver.com/public/code/html-subscribe?list=winserver So another question is whether MLS made the required consideration to securing restrictive domains? If no, why not? I was aware back during the RFC6377 production that there were others MLS authors or developers who liked the idea. It made sense. As it was pointed out but unfortunately missed in the externally produced fast tracked RFC5863 deployment guide, this conflict had its genesis in RFC5863 with its description of resigner operations and ADSP operations. It didn't provide the insight regarding resigners needs to consider this policy signing controls. In addition, DKIM+POLICY considerations also required that the more restrictive domains begin to clean up their usage of using private, corporate, high value domains in public. Domains needed to understand of the DKIM "blind" resigners existence without controls to prevent interop issues. There are three policies: DKIM=unknown DKIM=all DKIM=discardable By far, unknown is found more than DKIM=all. DKIM=Discardable is being used only by exclusive private operations. Its not designed for public usage which is obvious. One confusion was with DKIM=ALL and whether it excluded 3rd party signers. It also had no actionable semantics. Only Discardable had actionable material. DISCARD was the intent, but a REJECT was also possible and hence the MLS has to be consider of the REJECT as well. Overall, one of the goals was to process and trace the results with Authentication-Results to hopefully gain better insight in writing MFA (Mail Filter Agents), if possible. This was done and its still being done and this needs to be strongly considered. MFAs will be developed at some point. We can not use the lack of actionable material as evidence of lack of usage or lack of utility. Our package supports ADSP but out of the box it does not take action of failed DKIM messages. However, it is documented of what an operator can do with their backend mail processing scripts. It should be part of the research to see what we have learned from ADSP. If we are going to pull the rug from under the feet of implementators and publishers, it can not be done blindly and inconsiderate of all the above and then some. The suggestion that it can be replaced with DMARC does not eliminate all the above learned considerations. Or are we in a more better position to also strongly and support inform MLS authors to follow DMARC policies now? -- HLS On 9/13/2013 10:27 PM, Barry Leiba wrote: >>> That said, I'd like to see arguments not that code to assess ADSP is >>> deployed, or even very widely deployed, but that the protocol is >>> providing benefits commensurate with keeping it as a current standard. >>> Data that supports that view is welcome. >> >> Hi Barry, in all honesty I had difficulty trying to figure out why the >> burden should be on deployments to answer your question. > > That's a fair question. > > There are a bunch of people saying that they are not seeing a benefit > from ADSP. Those who are saying that include some large email > handlers and some high-profile phishing targets, so we have it from > both sides of the ADSP pond -- the ones trying to filter and the ones > trying to protect their domain identities. They're all saying that > ADSP isn't doing it. > > But when things aren't happening, it's difficult to come up with hard > numbers. They could show us what ADSP isn't helping them block, but > we wouldn't know what else ADSP might be helping them block. > > Given that, someone who says that ADSP *is* helping to block this > stuff... is the one who can provide evidence for that. If we can see > some numbers showing what was blocked with the help of ADSP *that > would have gotten through without it*, we can consider that in > determining what benefit ADSP is providing. > > That's the sort of thing I'm asking for: arguments, backed by whatever > evidence we have, that there *is* a benefit from having ADSP as a > standard, and that we should therefore not retire it. > > In the rest of your note you talk about why ADSP is here: what it's > intended to accomplish. We know that... but the discussion that's on > the table is that it's not accomplishing it. Yes, you're right: ADSP > is what we have. Where is the evidence that it's working? > > As to IETF work lost, well, there are many IETF standards that have > not been successful, and that have withered and been, arguably, lost > work. It happens. We usually just leave them dead on the vine. In > this case, we've seen real-Internet demonstrations that mis-applied > ADSP has caused real damage, in lost mail and screwed-up mailing > lists. Officially making ADSP Historic will discourage domains from > publishing ADSP records, if there's no significant benefit from them, > but a demonstrated potential for damage. > > Don't read from that that I'm supporting this move; I'm not supporting > either side of it. It's my job to judge the result of the > conversation. Provide some evidence of benefit, and it'll be > considered. Who knows?: you might sway some who have already said > "+1" to making it Historic. > > And I'll repeat: we're judging ADSP on its own here, not in comparison > with anything else that might have one more letter in its name. If we > can see value in ADSP, that will matter, regardless of any > alternatives. It's not a "competing solution" thing, so let's please > have no more of that. > > Barry > > -- HLS From vkg@bell-labs.com Wed Sep 18 08:50:29 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6584811E8246; Wed, 18 Sep 2013 08:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cPHYQHtvGV3Z; Wed, 18 Sep 2013 08:50:24 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4594E11E8124; Wed, 18 Sep 2013 08:50:23 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r8IFoKse029517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 18 Sep 2013 10:50:21 -0500 (CDT) Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id r8IFoJ87009835 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 18 Sep 2013 10:50:20 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.237.229]) by umail.lucent.com (8.13.8/TPES) with ESMTP id r8IFoI31022906; Wed, 18 Sep 2013 10:50:19 -0500 (CDT) Message-ID: <5239CCE6.8000709@bell-labs.com> Date: Wed, 18 Sep 2013 10:55:18 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130805 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Paul E. Jones" References: <52387B2A.9020102@bell-labs.com> <201309172004.r8HK4jft009629@rcdn-core-4.cisco.com> <01b601ceb3ea$e47a42e0$ad6ec8a0$@packetizer.com> <5238CB61.6060703@bell-labs.com> <022401ceb3fe$2aca2900$805e7b00$@packetizer.com> In-Reply-To: <022401ceb3fe$2aca2900$805e7b00$@packetizer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Cc: draft-ietf-insipid-session-id-reqts.all@tools.ietf.org, 'James Polk' , 'IESG IESG' , apps-discuss@ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-insipid-session-id-reqts-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 15:50:29 -0000 On 09/17/2013 06:32 PM, Paul E. Jones wrote: > I'm not sure exactly what you think we need to further clarify in that > paragraph (the last one in Section 7), but I'm happy to make changes as you > suggest. Paul: I did not do the review to tick a process box somewhere. I did it for the normal reasons related to any peer review including rendering the resulting draft less ambiguous and more useful to people tasked with actually implementing this piece of work. > I believe that those things are covered. In that paragraph, it talks about > the fact that one should an attacker who might use the same value. It then > talks about the fact the value should be random (or otherwise really hard to > just guess). It also talks about the secure transport of the session-ID. > Aside from REQ6, none of the language in that paragraph is normative. Regarding your assertion that "those things are covered", let me simply say that they are not covered in sufficient detail to allow a random implementer to pick this draft and implement the work. The phrase "surreptitiously spoof[ing]" implies (to me) changing the identifier such that the origin does not know that the change occurred. If what you mean is that the identifier should not be copied and replayed, just say so. Drop the spoofing bit. But really, the problem is broader than that. Underlying REQ5 is the unstated assumption that the SIP traffic is protected through normal hop-by-hop TLS. If this was not the case, then how do you know that the intermediary that injected the identifier is malicious or benign? Furthermore, the paragraph in question also asks for "sufficient verification ... to ensure integrity" of the identifier. Note that no means is given as to how the verification is to be performed. Clearly, what you have in mind is hop-by-hop TLS, but you have not stated this explicitly. In fact, this all encompassing hop-by-hop TLS is not present as a requirement, and is only mentioned as the last sentence in Section 7. Simply saying that RFC3261 threat model applies is not sufficient. RFC3261 allows you to send SIP messages in cleartext. You really need to make a case in Section 7 that (a) identifiers must not reveal privacy (REQ4), (b) identifiers must not be amenable to insertion by untrusted intermediaries (REQ5), (c) identifiers must be globally unique in time and space (REQ6), (d) must not be amenable to copy-and-replay attacks (no requirement in S5 for this); otherwise, diagnostic equipment will not know what to do with duplicate identifiers, (e) identifiers must not be amenable to guessing, i.e., if an adversary possesses the current identifier, this knowledge must not allow it to guess the next identifier (no requirement in S5 for this), (f) identifiers must be verfiable at the receiving endpoint (no requirement in S5 for this). TLS takes care of (b), (d), (f), and to a certain extent (e). If an adversary cannot observe the current identifier, it cannot use it to guess the next one. Unfortunately, I don't see such a logical progression in the last paragraph of Section 7. The second paragraph makes a good job of ensuring REQ4 is met, but the third paragraph appears to be more a stream of consciousness. I believe that we write these drafts so that others, probably not well versed with the assumptions as we are, can read the drafts and implement the work with minimum ambiguity. I don't think the draft passes that test. In the end, I have indicated my disposition with "Minor comments", not "Major comments". So if I have not convinced you that parts of the draft should be looked at again, you are of course, free to disregard the advice and move ahead. From my part, the review is certainly not binding. However, if you buy my arguments, I'd be more than happy to work with you to suggest text to make the draft better. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq From aallen@blackberry.com Mon Sep 16 15:03:44 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B32111E81D0; Mon, 16 Sep 2013 15:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.421 X-Spam-Level: X-Spam-Status: No, score=-1.421 tagged_above=-999 required=5 tests=[AWL=-2.322, BAYES_50=0.001, J_CHICKENPOX_22=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zNH8W8h0HlzT; Mon, 16 Sep 2013 15:03:40 -0700 (PDT) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id 9750411E819C; Mon, 16 Sep 2013 15:03:39 -0700 (PDT) Received: from xct104ads.rim.net ([10.67.111.45]) by mhs214cnc.rim.net with ESMTP/TLS/AES128-SHA; 16 Sep 2013 18:03:34 -0400 Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT104ADS.rim.net ([fe80::90f9:3b89:1d94:aa9b%22]) with mapi id 14.03.0123.003; Mon, 16 Sep 2013 17:03:33 -0500 From: Andrew Allen To: =?iso-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= , "apps-discuss@ietf.org" Thread-Topic: APPSDIR review of draft-montemurro-gsma-imei-urn-16 Thread-Index: AQHOmpCRbH1SI+yZ3kqKvKkJWg7GDZnI2aPw Date: Mon, 16 Sep 2013 22:03:33 +0000 Message-ID: References: <6.2.5.6.2.20130816075127.0d5b05b0@elandnews.com> In-Reply-To: <6.2.5.6.2.20130816075127.0d5b05b0@elandnews.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.254] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 18 Sep 2013 11:17:44 -0700 Cc: "draft-montemurro-gsma-imei-urn@tools.ietf.org" , IESG Subject: Re: [apps-discuss] APPSDIR review of draft-montemurro-gsma-imei-urn-16 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 16 Sep 2013 22:03:44 -0000 Martin Thank you for the review and I hope you enjoyed your vacation. My responses are inline prepended with [AA]. I also have a couple of questi= ons for guidance and would welcome your feedback on these. Andrew = -----Original Message----- From: "Martin J. D=FCrst" [mailto:duerst@it.aoyama.ac.jp] = Sent: Friday, August 16, 2013 10:54 AM To: apps-discuss@ietf.org Cc: IESG; draft-montemurro-gsma-imei-urn@tools.ietf.org Subject: APPSDIR review of draft-montemurro-gsma-imei-urn-16 I have been selected as the Applications Area Directorate reviewer for this= draft (for background on APPSDIR, please see http://trac.tools.ietf.org/ar= ea/app/trac/wiki/ApplicationsAreaDirectorate ). Please resolve these comments along with any other Last Call comments you m= ay receive. Please wait for direction from your document shepherd or AD bef= ore posting a new version of the draft. Document: draft-montemurro-gsma-imei-urn-16 Title: A Uniform Resource Name Namespace for the GSM Association (GSMA) and= the International Mobile station Equipment Identity (IMEI) Reviewer: Martin D=FCrst Review Date: August 16, 2013 IETF Last Call Date: August 16, 2013 Note: I'm on vacation, so the review and in particular the writeup is rathe= r cursory. Summary: This document is nearly ready for publication as a Proposed Standa= rd. Major issues: The document registers both the 'gsma' URN Namespace ID as well as a single= subspace therein. It would be overkill to write two separate documents for= this, but it would clearly make the document more readable (and make futur= e addditions easier) if the 'gsma' Namespace ID and the subnamespace were c= learly separated. This would also simplify/untangle the grammar. The syntax after the subnamespace ID (gsma-specifier) is too specific. It is geared towards the current needs on= ly, and may be too restrictive. I'd change the overall syntax to something = like the following: gsma-urn =3D "urn:gsma:" gsma-specifier *(":" gsma-specifier-defined-substring) gsma-specifier =3D gsma-specifier-defined-string gsma-specifier-defined-string =3D gsma-approved-nonempty-string gsma-specifier-defined-substring =3D ; allow any URN character gsma-approved-nonempty-string =3D 1*unreserved ; needs to be ; approved by GSMA unreserved =3D ALPHA / DIGIT / "-" / "." / "_" The 'vers' parameter is overkill. I'm not a GSMA expert, but my feeling is = that such a basic identifier is changed extremely rarely. If that happens, = it's much easier to just create 'imei2'. = That would also eliminate the need to define that the absence of this param= eter is the same as "vers=3D0". Likewise, I'd remove the 'svn' parameter, and either use 'imeisv' or just m= ake the IDs with software versions a few digits longer (they can easily be = distinguished by length). [One could then completely get rid of the paramet= er syntax.] [AA] With regard to the general ABNF comments. Cullen Jennings has been ve= ry clear that he wants all uses of the sub namespaces under the GSMA namesp= ace to be documented in RFCs. Therefore in the draft we need to document th= e currently defined usage and it makes sense to me that the ABNF for that i= s also documented here. The draft is already referenced by 3GPP specificati= ons and these rely on the ABNF defined here. I think unreserved =3D ALPHA = / DIGIT / "-" / "." / "_" covers all the unreserved characters except the "= ~" character (which I cannot see any valid use for within the GSMA namespac= e) and the % character which as you suggest ought to be added so that perc= ent-encoded UTF-8 strings can be used . = [AA] With regard to defining parameters. Early versions of this draft did d= efine IMEISV as a separate sub namespace but Cullen Jennings provided feedb= ack that since the IMEISV always contains as a subset the IMEI that it made= sense to define the software version as a parameter. The version number c= ould have been defined as a separate sub namespace IMEI2, however keeping t= he namespace as IMEI with a "vers" parameter allows for some backward comp= atibility as many entities will not need to decode the IMEI value just perf= orm string compares on the IMEI value and so many IMEI version 0 compliant = entities will still be able to understand that they have received an IMEI a= nd be able to perform equality comparisons on the IMEI even if the format o= f the IMEI value is changed to for example hexadecimal or the number of dig= its is changed in a future version. = [AA] My proposal is therefore to only include in the revision the % charact= er (to allow percent-encoded UTF-8 strings) and the gsma-approved-nonempty= -string =3D 1*unreserved ; needs to be approved by GSMA I don't understand why the check digit (spare) is set to '0'. URIs in gener= al and URNs in particular are often used by humans, and in that context, a = check digit is valuable (although I understand that imeis shouldn't be pass= ed among humans too often for privacy reasons). [AA] When transmitted the spare digit is always set to zero. The spare digi= t is only non-zero when displayed on the equipment and is used as a check d= igit to make sure that when a human being communicates an IMEI that the com= municated digits transmitted (e.g. orally) and received (e.g. heard) correc= tly. The intention is that the URN is used within communication protocol me= ssages and so as is stated in the draft the value of the spare digit is set= to "0". The draft says: Any identifier in GSMA namespaces can be compared using the normal mechanisms for percent-encoded UTF-8 strings. The syntax currently doesn't allow percent-encoded UTF-8 strings, but it should. [AA] See above comments regarding ABNF. In sections 4.1.4 and 4.2.4, things are rather unclear. 4.1.4 has least to = most, 4.2.4 has most to most as a correspondence. Given the text, I'd have = no confidence at all to get this right. = Also, sometimes half of an octet isn't used; this should be explained and s= hown in the drawings. = Also, if an octet spans two decimal digits, there should be no 'tic' in the= middle of the octet value. I.e., like this: +-----+-----+-----+-----+-----+-----+-----+--- 1 2 3 4 5 6 7 8 Octets and not like this: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 1 2 3 4 5 6 7 8 Octets [AA] The text and figures regarding the binary representation of the IMEI a= re only meant to be informative. The key concepts that were trying to be co= nveyed are the when used in cellular signaling messages the IMEI is BCD enc= oded, that the IMEI and IMEISV are encoded in 8 octets, and that the most s= ignificant digit of the TAC is in the 1st Octet. The actual alignment of th= e digits to octets when used as an identity element in a cellular signaling= message depends on the alignment of the identity element within the coding= of the cellular signaling message. I can certainly remove the 'tic" or '+'= between the nibbles of each octet and explain the half octet better. Wording addressing the issue brought up by Tim Bray on ietf@ietf.org is sti= ll missing. [AA] this version is the same version that Tim Bray commented on. Tim's com= ments will also be taken into account in the next revision. Minor issues: The draft says: A sub-namespace for the IMEI is defined under the GSMA namespace. Other sub-namespaces may be defined in the future to include other identifiers in the GSM, UMTS or LTE networks or future networks deployed by members of the GSMA. This seems needlessly restricted to networks. = Just saying something like "for future identifiers needed by the GSMA". [AA] This comment will be taken on board in the next revision. The draft says: Each field has its value printed as a decimal digit string with the most significant digit first. "printed" is too narrow. Change to 'visual = representation', or better yet, change to = 'representation for humans' (which includes = auditory and tactile representations). [AA] This can be changed to use the proposed 'representation for humans' te= xt. The draft says: Identifier uniqueness considerations: Identifiers in the "gsma" namespace are defined and assigned in the requested namespace by the GSMA after ensuring that the URNs to be assigned are unique. Uniqueness is achieved by checking against the registry of previously assigned names. Does the GSMA indeed plan to set up a registry? = Or is this just implicit, i.e., check all the = relevant RFCs? In the later case, please don't = use the term 'registry'. In the former case, = please be more explicit about location,... [AA] as the draft states: additional sub-namespaces under the GSMA namespac= e may be specified in the future by the GSMA through the publication of fut= ure Informational RFCs. Therefore it is expected that the IANA registry wil= l be updated if any sub namespaces are registered in the future. The draft says: Identifier persistence considerations: The GSMA is committed to maintaining uniqueness and persistence of all resources identified by assigned URNs. IMEIs identify devices, but the GMSA can't = guarantee the persistence of a device (I can shred and burn my cell phone). The draft says: As the NID sought is "gsma" and GSMA is the long standing acronym for the trade association that represents the mobile phone operators the URN should also persist indefinitely (at least as long as there is a need for its use). The assignment process guarantees that names are not reassigned. The binding between the name and its resource is permanent. I don't think this paragraph is necessary. The = parsistence consideratios are abuout persistence = in the namespace, not of the namespace ID itself. [AA] it seems we have misunderstood what persistence meant in the registrat= ion template. We have interpreted this as meaning that the GSMA has defined= storage requirements such that the IMEI is not easily modified and once as= signed persists as long as the device exists. What persistence property is = being sought by the template here? RFC 5234 needs to be normative. [AA] This will be made into a normative reference. Editorial: There are many abbreviations, many of them not = very familiar with IETF people, and some of them = not or not consistently expanded. E.g. GSM = appears in the second line of the abstract, but = is only expanded at the end of the abstract. [AA] This will be fixed and another scrub done for others There's no need for section 3.1, because it's the = only subsection in section 3. On the other hand, = it would be good if it could have subsections. = Because this is a template, that may be = impossible. As an alternative, I suggest = shortening the template by moving descriptive = materail out of the template into separate subsections. [AA] OK will look at doing that Intro (and maybe elswhhere): Please put the = namespace name into quotes, like this: 'gsma'. [AA] OK References: if possible, please replace numeric = reference ids (e.g. [8]) with something like = [RFC5234]. That reduces manual lookups. [AA] This is done automatically by XML2RFC. What I can do is also insert th= e document ID e.g RFC 5234 [8] Intro: "so this namespace would be managed by the = GSMA": When the document is published, this is no = longer a conditional, so please change "would" to "is". [AA] OK There are inconsistencies with punctuation. E.g. = "TS" (an acronym that's not expanded) is spelled = "TS" as we0ll as "TS.". Also, there should always = be spaces outside parentheses. [AA] OK will check for these (if parameters are kept) means that the "=3D" character can only occur as an operator for =3D> means that the "=3D" character can only occur as a separator ... [AA] OK will revise as proposed The security sectiion needs a careful grammar check (singular/plural,...) [AA] OK will check "Phone: unlisted": Just remove these useless fields. [AA] OK Regards, Martin. --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. From aallen@blackberry.com Mon Sep 16 16:04:16 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4369211E81F3; Mon, 16 Sep 2013 16:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.467 X-Spam-Level: X-Spam-Status: No, score=-1.467 tagged_above=-999 required=5 tests=[AWL=-0.728, BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QGH0hCK5BFrp; Mon, 16 Sep 2013 16:04:12 -0700 (PDT) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id A0F4A11E81F0; Mon, 16 Sep 2013 16:04:11 -0700 (PDT) Received: from xct105ads.rim.net ([10.67.111.46]) by mhs215cnc.rim.net with ESMTP/TLS/AES128-SHA; 16 Sep 2013 19:04:04 -0400 Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT105ADS.rim.net ([fe80::2d01:2041:eea3:819b%22]) with mapi id 14.03.0123.003; Mon, 16 Sep 2013 18:04:03 -0500 From: Andrew Allen To: Tim Bray , "apps-discuss@ietf.org" , "draft-allen-dispatch-imei-urn-as-instanceid.all@tools.ietf.org" , The IESG Thread-Topic: Apps Area review of draft-allen-dispatch-imei-urn-as-instanceid-10 Thread-Index: AQHOmI4kZggAU7SqY0CFPOlmhniBZZnJJqpg Date: Mon, 16 Sep 2013 23:04:03 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.254] Content-Type: multipart/alternative; boundary="_000_BBF5DDFE515C3946BC18D733B20DAD2338E17DD2XMB104ADSrimnet_" MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 18 Sep 2013 11:17:45 -0700 Subject: Re: [apps-discuss] Apps Area review of draft-allen-dispatch-imei-urn-as-instanceid-10 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 16 Sep 2013 23:04:16 -0000 --_000_BBF5DDFE515C3946BC18D733B20DAD2338E17DD2XMB104ADSrimnet_ Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 VGltDQoNClRoYW5rIHlvdSBmb3IgdGhlIHJldmlldw0KDQpNeSByZXNwb25zZXMgaW5saW5lIGJl bG93IHByZXBlbmRlZCB3aXRoIFtBQV0uIFRoZXJlIGFyZSBzdGlsbCBzb21lIGNvbW1lbnRzIHRo YXQgSSBzdGlsbCBuZWVkIGZ1cnRoZXIgY2xhcmlmaWNhdGlvbiBvbi4NCg0KUmVnYXJkcw0KQW5k cmV3DQoNCkZyb206IFRpbSBCcmF5IFttYWlsdG86dGJyYXlAdGV4dHVhbGl0eS5jb21dDQpTZW50 OiBUdWVzZGF5LCBBdWd1c3QgMTMsIDIwMTMgOTozMiBQTQ0KVG86IGFwcHMtZGlzY3Vzc0BpZXRm Lm9yZzsgZHJhZnQtYWxsZW4tZGlzcGF0Y2gtaW1laS11cm4tYXMtaW5zdGFuY2VpZC5hbGxAdG9v bHMuaWV0Zi5vcmc7IFRoZSBJRVNHDQpTdWJqZWN0OiBBcHBzIEFyZWEgcmV2aWV3IG9mIGRyYWZ0 LWFsbGVuLWRpc3BhdGNoLWltZWktdXJuLWFzLWluc3RhbmNlaWQtMTANCg0KSSBoYXZlIGJlZW4g c2VsZWN0ZWQgYXMgdGhlIEFwcGxpY2F0aW9ucyBBcmVhIERpcmVjdG9yYXRlIHJldmlld2VyIGZv ciB0aGlzIGRyYWZ0IChmb3IgYmFja2dyb3VuZCBvbiBhcHBzZGlyLCBwbGVhc2Ugc2VlIGh0dHA6 Ly90cmFjLnRvb2xzLmlldGYub3JnL2FyZWEvYXBwL3RyYWMvd2lraS9BcHBsaWNhdGlvbnNBcmVh RGlyZWN0b3JhdGUgKS4NCg0KUGxlYXNlIHJlc29sdmUgdGhlc2UgY29tbWVudHMgYWxvbmcgd2l0 aCBhbnkgb3RoZXIgTGFzdCBDYWxsIGNvbW1lbnRzIHlvdSBtYXkgcmVjZWl2ZS4gUGxlYXNlIHdh aXQgZm9yIGRpcmVjdGlvbiBmcm9tIHlvdXIgZG9jdW1lbnQgc2hlcGhlcmQgb3IgQUQgYmVmb3Jl IHBvc3RpbmcgYSBuZXcgdmVyc2lvbiBvZiB0aGUgZHJhZnQuDQoNCkRvY3VtZW50OiBkcmFmdC1h bGxlbi1kaXNwYXRjaC1pbWVpLXVybi1hcy1pbnN0YW5jZWlkLTEwDQpUaXRsZTogVXNpbmcgdGhl IEludGVybmF0aW9uYWwgTW9iaWxlIHN0YXRpb24gRXF1aXBtZW50IElkZW50aXR5KElNRUkpVVJO IGFzIGFuIEluc3RhbmNlIElEDQpSZXZpZXdlcjogVGltIEJyYXkNClJldmlldyBEYXRlOiBBdWd1 c3QgMTMNCg0KU3VtbWFyeTogVGhlIGRvY3VtZW50IG5lZWRzIGEgY2VydGFpbiBhbW91bnQgb2Yg ZWRpdG9yaWFsIHBvbGlzaGluZywgYW5kIHRoZSBpc3N1ZXMgcmFpc2VkIG9uIHRoZSBJRVRGIG1h aWxpbmcgbGlzdCBuZWVkIHRvIGJlIGNvbnNpZGVyZWQgYnkgdGhlIElFU0cuIFRoYXQgYXNpZGUs IHRoZSBkZXNjcmlwdGlvbiBvZiB0aGUgdXNhZ2Ugb2YgdGhlIElNRUkgVVJOIHNlZW1zIE9LLg0K DQpNYWpvciBJc3N1ZXM6IFRoZSBkaXNjdXNzaW9uIG9uIHRoZSBpZXRmQCBtYWlsaW5nIGxpc3Qg aXMgaW5jbHVkZWQgaGVyZSBieSByZWZlcmVuY2UuDQpbQUFdIFRoZXNlIGNvbW1lbnRzIEkgaGF2 ZSByZXNwb25kZWQgdG8gaW4gcHJldmlvdXMgZW1haWxzLiBUaGUgcmV2aXNpb24gd2lsbCBhZGRy ZXNzIHRob3NlIGNvbW1lbnRzDQpNaW5vciBJc3N1ZXM6IEluIHNlY3Rpb24gMywgVGhlIHF1YWxp dHkgb2YgdGhlIEVuZ2xpc2ggaXMgc3VmZmljaWVudGx5IGJhZCBhcyB0byBtYWtlIHRoZSBzZWN0 aW9uIGhhcmQgdG8gcmVhZCBhbmQgdW5kZXJzdGFuZC4gIEl0IGlzIHNldmVyZWx5IGluIG5lZWQg b2YgbW9yZSBjb21tYXMgYW5kIHBhcmFncmFwaCBicmVha3MuDQpbQUFdIFRoaXMgd2lsbCBiZSBp bXByb3ZlZA0KTml0czoNCg0KQWJzdHJhY3Q6DQoNCuKAnGFuIFJGQyAoZnJvbSB0aGUgSUVURiBz dHJlYW0p4oCdIGlzIGEgbGl0dGxlIGFtYmlndW91cywgdGhlcmUgYXJlIG11bHRpcGxlIElFVEYg c3RyZWFtcw0KDQpbQUFdIHRoaXMgaXMgYSBxdW90YXRpb24gb2YgYSByZXF1aXJlbWVudCBmcm9t IFJGQyA1NjI2IHdoaWNoIHRoaXMgZHJhZnQgYXR0ZW1wdHMgdG8gZnVsZmlsbC4NCg0KVGhlIGFj cm9ueW0g4oCcVUHigJ0gaXMgbmV2ZXIgZGVmaW5lZC4gVXNlci1BZ2VudD8NCg0KW0FBXSBZZXMg VXNlciBBZ2VudCDigJMgSSB3aWxsIG1ha2Ugc3VyZSB0aGlzIGlzIGFsc28gZGVmaW5lZC4NCg0K U2VjdGlvbiAxLg0KDQpzL3N1YiBuYW1lc3BhY2Uvc3ViLW5hbWVzcGFjZS8NCltBQV0gT0sgSSB3 aWxsIGNvcnJlY3QgdGhpcyBmb3IgY29uc2lzdGVuY3kNCg0K4oCcVVJOIGFzIHBlciBSRkMgMjE0 MeKAnSBzdGFuZGFyZGl6ZSBSRkMgY2l0ZSBzeW50YXgNCltBQV0gSSBhbSBub3Qgc3VyZSB3aGF0 IHlvdSBtZWFudCBieSB0aGlzIGNvbW1lbnQuIFBsZWFzZSBhZHZpc2UuDQoNCuKAnHNvIHRoYXQg cmVnaXN0cmFyIGNhbiByZWNvZ25pemUgdGhhdCB0aGUgY29udGFjdHPigJ0NCi0gd2hhdCByZWdp c3RyYXI/IE5vdCBkZWZpbmVkLiBPaCB3YWl0Li4uIGlzIHRoZSByZWYgdG8gUkZDIDU2MjYgZW5v dWdoPw0KLSBzL3JlZ2lzdHJhci90aGUgcmVnaXN0cmFyLw0KW0FBXSBUaGlzIGlzIGRlZmluZWQg aW4gUkZDIDMyNjEuIEkgd2lsbCBiZSBzdXJlIHRoYXQgcmVmZXJlbmNlIGlzIHJlZmVycmVkIHRv IHdoZW4gbWVudGlvbmluZyByZWdpc3RyYXINCg0K4oCcUkZDIDU2MjYgWzFdIGRlZmluZXMgdGhh dCBhIFVBIFNIT1VMROKAnSAtIHMvZGVmaW5lcy9zcGVjaWZpZXMvIG9yIC9yZXF1aXJlcy8NCltB QV0gd2lsbCBjaGFuZ2UgdG8gcmVxdWlyZXMNCg0K4oCcb3RoZXIgVVJOIHNjaGVtZXMgdG8gYmUg dXNlZOKAnSBzL3RvIGJlIHVzZWQvLw0KDQpbQUFdIEkgYW0gbm90IHN1cmUgd2hhdCBpcyB0aGUg aXNzdWUgaGVyZS4gUGxlYXNlIHJldmlzZS4NCg0K4oCcb3V0Ym91bmQgYmVoYXZpb3IgYW5k4oCd IC0gY29tbWEgYmVmb3JlIOKAnGFuZOKAnQ0KW0FBXSBBZ2FpbiB0aGlzIGlzIGEgcXVvdGUgZnJv bSBSRkMgNTYyNg0KDQrigJxUaGUgR1NNQSBJTUVJIFVSTiBpcyBhIG5hbWVzcGFjZSBmb3IgdGhl IElNRUkgYSBnbG9iYWxseSB1bmlxdWUgaWRlbnRpZmllcuKAnSAtIHRoZXJl4oCZcyBzb21ldGhp bmcgYnJva2VuIGluIHRoaXMgc2VudGVuY2UuICBEbyB5b3UgbWVhbiB0aGlzIGlzIGEgVVJOIG5h bWVzcGFjZT8gIFVSTnMgbm9ybWFsbHkgYXJlbuKAmXQgbmFtZXNwYWNlcyBpbiBhbmQgb2YgdGhl bXNlbHZlcywgc28gc29tZSBtb3JlIGV4cGxhbmF0aW9uIGlzIHJlcXVpcmVkLg0KW0FBXSBXb3Vs ZCBUaGUgR1NNQSBJTUVJIGlzIGEgVVJOIGZvciB0aGUgSU1FSSBiZSBiZXR0ZXI/DQpTZWN0aW9u IDUuDQoNCuKAnG90aGVyIHRoYW4gZXF1YWwgdG8gMOKAnSAtIHMvZXF1YWwgdG8vLw0KDQrigJxU aGUgVUFDIE1VU1QgcHJvdmlkZSBsZXhpY2FsbHkgZXF1aXZhbGVudCBVUk5zIGluIGVhY2ggcmVn aXN0cmF0aW9u4oCdIC0gdGhlIHRlcm0g4oCcbGV4aWNhbGx5IGVxdWl2YWxlbnTigJ0gaXMgcHJv YmFibHkgdW5kZXJzcGVjaWZpZWQ7IHNlZSBTZWN0aW9uIDYgb2YgUkZDMzk4Ni4gSWYgeW91IG1l YW4g4oCcY2hhcmFjdGVyLWJ5LWNoYXJhY3RlciBpZGVudGljYWzigJ0geW91IHNob3VsZCBwcm9i YWJseSBzYXkgc28gKGFuZCBJIHN1c3BlY3QgeW91IGRvKS4NCltBQV0gT0sgd2lsbCBjaGFuZ2Ug dG8gY2hhcmFjdGVyLWJ5LWNoYXJhY3RlciBpZGVudGljYWwgYXMgcHJvcG9zZWQuDQoNCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQpUaGlzIHRyYW5zbWlzc2lvbiAoaW5jbHVkaW5nIGFueSBhdHRhY2htZW50cykgbWF5 IGNvbnRhaW4gY29uZmlkZW50aWFsIGluZm9ybWF0aW9uLCBwcml2aWxlZ2VkIG1hdGVyaWFsIChp bmNsdWRpbmcgbWF0ZXJpYWwgcHJvdGVjdGVkIGJ5IHRoZSBzb2xpY2l0b3ItY2xpZW50IG9yIG90 aGVyIGFwcGxpY2FibGUgcHJpdmlsZWdlcyksIG9yIGNvbnN0aXR1dGUgbm9uLXB1YmxpYyBpbmZv cm1hdGlvbi4gQW55IHVzZSBvZiB0aGlzIGluZm9ybWF0aW9uIGJ5IGFueW9uZSBvdGhlciB0aGFu IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgaXMgcHJvaGliaXRlZC4gSWYgeW91IGhhdmUgcmVjZWl2 ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIHBsZWFzZSBpbW1lZGlhdGVseSByZXBseSB0 byB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBpbmZvcm1hdGlvbiBmcm9tIHlvdXIgc3lzdGVt LiBVc2UsIGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgb3IgcmVwcm9kdWN0aW9uIG9mIHRo aXMgdHJhbnNtaXNzaW9uIGJ5IHVuaW50ZW5kZWQgcmVjaXBpZW50cyBpcyBub3QgYXV0aG9yaXpl ZCBhbmQgbWF5IGJlIHVubGF3ZnVsLgo= --_000_BBF5DDFE515C3946BC18D733B20DAD2338E17DD2XMB104ADSrimnet_ Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGltPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5U aGFuayB5b3UgZm9yIHRoZSByZXZpZXc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk15IHJlc3BvbnNlcyBpbmxpbmUgYmVs b3cgcHJlcGVuZGVkIHdpdGggW0FBXS4gVGhlcmUgYXJlIHN0aWxsIHNvbWUgY29tbWVudHMgdGhh dCBJIHN0aWxsIG5lZWQgZnVydGhlciBjbGFyaWZpY2F0aW9uIG9uLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmVnYXJk czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BbmRyZXc8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFRpbSBCcmF5IFttYWlsdG86dGJyYXlAdGV4dHVhbGl0 eS5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgQXVndXN0IDEzLCAyMDEzIDk6MzIg UE08YnI+DQo8Yj5Ubzo8L2I+IGFwcHMtZGlzY3Vzc0BpZXRmLm9yZzsgZHJhZnQtYWxsZW4tZGlz cGF0Y2gtaW1laS11cm4tYXMtaW5zdGFuY2VpZC5hbGxAdG9vbHMuaWV0Zi5vcmc7IFRoZSBJRVNH PGJyPg0KPGI+U3ViamVjdDo8L2I+IEFwcHMgQXJlYSByZXZpZXcgb2YgZHJhZnQtYWxsZW4tZGlz cGF0Y2gtaW1laS11cm4tYXMtaW5zdGFuY2VpZC0xMDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkkgaGF2ZSBi ZWVuIHNlbGVjdGVkIGFzIHRoZSBBcHBsaWNhdGlvbnMgQXJlYSBEaXJlY3RvcmF0ZSByZXZpZXdl ciBmb3IgdGhpcyBkcmFmdCAoZm9yIGJhY2tncm91bmQgb24gYXBwc2RpciwgcGxlYXNlIHNlZQ0K PGEgaHJlZj0iaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYXJlYS9hcHAvdHJhYy93aWtpL0Fw cGxpY2F0aW9uc0FyZWFEaXJlY3RvcmF0ZSIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cDovL3RyYWMu dG9vbHMuaWV0Zi5vcmcvYXJlYS9hcHAvdHJhYy93aWtpL0FwcGxpY2F0aW9uc0FyZWFEaXJlY3Rv cmF0ZTwvYT4gKS48YnI+DQo8YnI+DQpQbGVhc2UgcmVzb2x2ZSB0aGVzZSBjb21tZW50cyBhbG9u ZyB3aXRoIGFueSBvdGhlciBMYXN0IENhbGwgY29tbWVudHMgeW91IG1heSByZWNlaXZlLiBQbGVh c2Ugd2FpdCBmb3IgZGlyZWN0aW9uIGZyb20geW91ciBkb2N1bWVudCBzaGVwaGVyZCBvciBBRCBi ZWZvcmUgcG9zdGluZyBhIG5ldyB2ZXJzaW9uIG9mIHRoZSBkcmFmdC48YnI+DQo8YnI+DQpEb2N1 bWVudDogZHJhZnQtYWxsZW4tZGlzcGF0Y2gtaW1laS11cm4tYXMtaW5zdGFuY2VpZC0xMDxicj4N ClRpdGxlOiBVc2luZyB0aGUgSW50ZXJuYXRpb25hbCBNb2JpbGUgc3RhdGlvbiBFcXVpcG1lbnQg SWRlbnRpdHkoSU1FSSlVUk4gYXMgYW4gSW5zdGFuY2UgSUQ8YnI+DQpSZXZpZXdlcjogVGltIEJy YXk8YnI+DQpSZXZpZXcgRGF0ZTogQXVndXN0IDEzPGJyPg0KPGJyPg0KU3VtbWFyeTogVGhlIGRv Y3VtZW50IG5lZWRzIGEgY2VydGFpbiBhbW91bnQgb2YgZWRpdG9yaWFsIHBvbGlzaGluZywgYW5k IHRoZSBpc3N1ZXMgcmFpc2VkIG9uIHRoZSBJRVRGIG1haWxpbmcgbGlzdCBuZWVkIHRvIGJlIGNv bnNpZGVyZWQgYnkgdGhlIElFU0cuIFRoYXQgYXNpZGUsIHRoZSBkZXNjcmlwdGlvbiBvZiB0aGUg dXNhZ2Ugb2YgdGhlIElNRUkgVVJOIHNlZW1zIE9LLjxicj4NCjxicj4NCk1ham9yIElzc3Vlczog VGhlIGRpc2N1c3Npb24gb24gdGhlIGlldGZAIG1haWxpbmcgbGlzdCBpcyBpbmNsdWRlZCBoZXJl IGJ5IHJlZmVyZW5jZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPltBQV0gVGhlc2UgY29tbWVudHMgSSBoYXZlIHJlc3BvbmRlZCB0byBpbiBwcmV2 aW91cyBlbWFpbHMuIFRoZSByZXZpc2lvbiB3aWxsIGFkZHJlc3MgdGhvc2UgY29tbWVudHM8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPk1pbm9yIElzc3VlczogSW4gc2VjdGlvbiAzLCBU aGUgcXVhbGl0eSBvZiB0aGUgRW5nbGlzaCBpcyBzdWZmaWNpZW50bHkgYmFkIGFzIHRvIG1ha2Ug dGhlIHNlY3Rpb24gaGFyZCB0byByZWFkIGFuZCB1bmRlcnN0YW5kLiZuYnNwOyBJdCBpcyBzZXZl cmVseSBpbiBuZWVkIG9mIG1vcmUgY29tbWFzIGFuZCBwYXJhZ3JhcGggYnJlYWtzLg0KPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bQUFdIFRoaXMg d2lsbCBiZSBpbXByb3ZlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk5pdHM6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFic3RyYWN0OiA8YnI+DQo8YnI+DQrigJxhbiBSRkMgKGZy b20gdGhlIElFVEYgc3RyZWFtKeKAnSBpcyBhIGxpdHRsZSBhbWJpZ3VvdXMsIHRoZXJlIGFyZSBt dWx0aXBsZSBJRVRGIHN0cmVhbXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W0FBXSB0aGlzIGlzIGEgcXVvdGF0aW9uIG9mIGEgcmVx dWlyZW1lbnQgZnJvbSBSRkMgNTYyNiB3aGljaCB0aGlzIGRyYWZ0IGF0dGVtcHRzIHRvIGZ1bGZp bGwuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGJyPg0KVGhlIGFjcm9ueW0g4oCcVUHigJ0gaXMgbmV2ZXIgZGVmaW5lZC4gVXNlci1B Z2VudD88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+W0FBXSBZZXMgVXNlciBBZ2VudCDigJMgSSB3aWxsIG1ha2Ugc3VyZSB0aGlzIGlz IGFsc28gZGVmaW5lZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlNlY3Rpb24gMS4gPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxi cj4NCnMvc3ViIG5hbWVzcGFjZS9zdWItbmFtZXNwYWNlLzxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5bQUFdIE9LIEkgd2lsbCBjb3JyZWN0IHRoaXMgZm9yIGNvbnNpc3RlbmN5PC9zcGFu Pjxicj4NCjxicj4NCuKAnFVSTiBhcyBwZXIgUkZDIDIxNDHigJ0gc3RhbmRhcmRpemUgUkZDIGNp dGUgc3ludGF4PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltBQV0gSSBhbSBub3Qgc3Vy ZSB3aGF0IHlvdSBtZWFudCBieSB0aGlzIGNvbW1lbnQuIFBsZWFzZSBhZHZpc2UuPC9zcGFuPjxi cj4NCjxicj4NCuKAnHNvIHRoYXQgcmVnaXN0cmFyIGNhbiByZWNvZ25pemUgdGhhdCB0aGUgY29u dGFjdHPigJ08YnI+DQotIHdoYXQgcmVnaXN0cmFyPyBOb3QgZGVmaW5lZC4gT2ggd2FpdC4uLiBp cyB0aGUgcmVmIHRvIFJGQyA1NjI2IGVub3VnaD88YnI+DQotIHMvcmVnaXN0cmFyL3RoZSByZWdp c3RyYXIvPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltBQV0gVGhpcyBpcyBkZWZpbmVk IGluIFJGQyAzMjYxLiBJIHdpbGwgYmUgc3VyZSB0aGF0IHJlZmVyZW5jZSBpcyByZWZlcnJlZCB0 byB3aGVuIG1lbnRpb25pbmcgcmVnaXN0cmFyPC9zcGFuPjxicj4NCjxicj4NCuKAnFJGQyA1NjI2 IFsxXSBkZWZpbmVzIHRoYXQgYSBVQSBTSE9VTETigJ0gLSBzL2RlZmluZXMvc3BlY2lmaWVzLyBv ciAvcmVxdWlyZXMvPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltBQV0gd2lsbCBjaGFu Z2UgdG8gcmVxdWlyZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCuKAnG90aGVyIFVSTiBzY2hlbWVz IHRvIGJlIHVzZWTigJ0gcy90byBiZSB1c2VkLy88YnI+DQo8YnI+DQo8c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+W0FBXSBJIGFtIG5vdCBzdXJlIHdoYXQgaXMgdGhlIGlzc3VlIGhlcmUu IFBsZWFzZSByZXZpc2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQrigJxvdXRib3VuZCBiZWhhdmlv ciBhbmTigJ0gLSBjb21tYSBiZWZvcmUg4oCcYW5k4oCdPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPltBQV0gQWdhaW4gdGhpcyBpcyBhIHF1b3RlIGZyb20gUkZDIDU2MjY8L3NwYW4+PGJy Pg0KPGJyPg0K4oCcVGhlIEdTTUEgSU1FSSBVUk4gaXMgYSBuYW1lc3BhY2UgZm9yIHRoZSBJTUVJ IGEgZ2xvYmFsbHkgdW5pcXVlIGlkZW50aWZpZXLigJ0gLSB0aGVyZeKAmXMgc29tZXRoaW5nIGJy b2tlbiBpbiB0aGlzIHNlbnRlbmNlLiZuYnNwOyBEbyB5b3UgbWVhbiB0aGlzIGlzIGEgVVJOIG5h bWVzcGFjZT8mbmJzcDsgVVJOcyBub3JtYWxseSBhcmVu4oCZdCBuYW1lc3BhY2VzIGluIGFuZCBv ZiB0aGVtc2VsdmVzLCBzbyBzb21lIG1vcmUgZXhwbGFuYXRpb24gaXMgcmVxdWlyZWQuPHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltBQV0gV291bGQNCjwvc3Bhbj5UaGUgR1NNQSBJTUVJ IGlzIGEgVVJOIGZvciB0aGUgSU1FSTxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj4gYjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ZSBiZXR0ZXI/PC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbToxMi4wcHQiPlNlY3Rpb24gNS48YnI+DQo8YnI+DQrigJxvdGhlciB0aGFu IGVxdWFsIHRvIDDigJ0gLSBzL2VxdWFsIHRvLy88YnI+DQo8YnI+DQrigJxUaGUgVUFDIE1VU1Qg cHJvdmlkZSBsZXhpY2FsbHkgZXF1aXZhbGVudCBVUk5zIGluIGVhY2ggcmVnaXN0cmF0aW9u4oCd IC0gdGhlIHRlcm0g4oCcbGV4aWNhbGx5IGVxdWl2YWxlbnTigJ0gaXMgcHJvYmFibHkgdW5kZXJz cGVjaWZpZWQ7IHNlZSBTZWN0aW9uIDYgb2YgUkZDMzk4Ni4gSWYgeW91IG1lYW4g4oCcY2hhcmFj dGVyLWJ5LWNoYXJhY3RlciBpZGVudGljYWzigJ0geW91IHNob3VsZCBwcm9iYWJseSBzYXkgc28g KGFuZCBJIHN1c3BlY3QgeW91IGRvKS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPltBQV0gT0sgd2lsbCBjaGFuZ2UgdG8gY2hhcmFjdGVyLWJ5LWNo YXJhY3RlciBpZGVudGljYWwgYXMgcHJvcG9zZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPlRoaXMgdHJhbnNt aXNzaW9uIChpbmNsdWRpbmcgYW55IGF0dGFjaG1lbnRzKSBtYXkgY29udGFpbiBjb25maWRlbnRp YWwgaW5mb3JtYXRpb24sIHByaXZpbGVnZWQgbWF0ZXJpYWwgKGluY2x1ZGluZyBtYXRlcmlhbCBw cm90ZWN0ZWQgYnkgdGhlIHNvbGljaXRvci1jbGllbnQgb3Igb3RoZXIgYXBwbGljYWJsZSBwcml2 aWxlZ2VzKSwgb3IgY29uc3RpdHV0ZSBub24tcHVibGljIGluZm9ybWF0aW9uLiBBbnkgdXNlIG9m IHRoaXMgaW5mb3JtYXRpb24gYnkgYW55b25lIG90aGVyIHRoYW4gdGhlIGludGVuZGVkIHJlY2lw aWVudCBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lv biBpbiBlcnJvciwgcGxlYXNlIGltbWVkaWF0ZWx5IHJlcGx5IHRvIHRoZSBzZW5kZXIgYW5kIGRl bGV0ZSB0aGlzIGluZm9ybWF0aW9uIGZyb20geW91ciBzeXN0ZW0uIFVzZSwgZGlzc2VtaW5hdGlv biwgZGlzdHJpYnV0aW9uLCBvciByZXByb2R1Y3Rpb24gb2YgdGhpcyB0cmFuc21pc3Npb24gYnkg dW5pbnRlbmRlZCByZWNpcGllbnRzIGlzIG5vdCBhdXRob3JpemVkIGFuZCBtYXkgYmUgdW5sYXdm dWwuPGJyPjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BBF5DDFE515C3946BC18D733B20DAD2338E17DD2XMB104ADSrimnet_-- From jmpolk@cisco.com Tue Sep 17 13:04:50 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56C9E11E82D3; Tue, 17 Sep 2013 13:04:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.407 X-Spam-Level: X-Spam-Status: No, score=-110.407 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o-fciIy2GcEj; Tue, 17 Sep 2013 13:04:46 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 3097E11E8165; Tue, 17 Sep 2013 13:04:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4106; q=dns/txt; s=iport; t=1379448286; x=1380657886; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version:content-transfer-encoding; bh=Pi3gmM9/93T+uwiFT+QIXSggQSM3BXNrwNuepdA6K1Y=; b=VIMc9mflc2EVlKtU01IkjaJH1clztD3MA6brKhtBgzBYk/ojZXENMZKy YrLGTxjFP7rhvwuDzl3fCxWAxDymQV/uEYzwPj0DnIr9F/NP+sYw4yAr4 OZA5+79Fkx0H8241FTRR0MlS7+eg6AxhlA/DexZv7B83mrUfe68eQP6cB o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjoFAI60OFKtJV2b/2dsb2JhbABbgwc4TMEpgR8WdIIlAQEBAwE4MBEFCwcEFAQJJQ8KPgYBEhuHYgYHBbpmjh6BFjMHhB4DiQA4j3KLFQGFL4NCHjYBAX0 X-IronPort-AV: E=Sophos;i="4.90,926,1371081600"; d="scan'208";a="261040720" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 17 Sep 2013 20:04:45 +0000 Received: from jmpolk-WS.cisco.com ([10.89.10.22]) (authenticated bits=0) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r8HK4jft009629 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Sep 2013 20:04:45 GMT Message-Id: <201309172004.r8HK4jft009629@rcdn-core-4.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 17 Sep 2013 15:04:42 -0500 To: "Vijay K. Gurbani" , From: James Polk In-Reply-To: <52387B2A.9020102@bell-labs.com> References: <52387B2A.9020102@bell-labs.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Authenticated-User: jmpolk X-Mailman-Approved-At: Wed, 18 Sep 2013 11:17:45 -0700 Cc: IESG IESG , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-insipid-session-id-reqts-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Sep 2013 20:04:50 -0000 Vijay comments below At 10:54 AM 9/17/2013, Vijay K. Gurbani wrote: >I have been selected as the Applications Area Directorate reviewer for >this draft (for background on appsdir, please see =E2=80=8B >http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate= ). > >Please resolve these comments along with any other Last Call comments >you may receive. Please wait for direction from your document shepherd >or AD before posting a new version of the draft. > >Document: draft-ietf-insipid-session-id-reqts-08 >Title: Diameter Overload Control Requirements >Reviewer: Vijay K. Gurbani >Review Date: Sep-17-2013 >IETF Last Call Date: Not known >IESG Telechat Date: Not known > >Summary: This draft is almost ready for publication as an Informational >RFC; two minor issues follow. > >Major: 0 >Minor: 2 >Nits: 2 > >Minor: > >- S3.2, the list of what are not considered communication sessions > appears rather arbitrary. What criteria makes you consider these > are not communication sessions? Is it the fact that some sort of > conferencing (ad-hoc or organized) is being used? If so, best to > state this up front. Otherwise I am left wondering why these cases > are not considered to be a communication session. I can certainly > see the benefit of knowing which endpoints participated in a > conference call that is indexed by a unique Session-ID. So, why > preclude this? Any reason for doing so will help understand the > decision for considering conferencing out of scope. I guess I don't know what you are asking for=20 clarity on. The INSIPID solutions draft (mostly=20 done, if we can get around a backwards=20 compatibility inconsistency within the WG)=20 certainly has conferencing as one of the main=20 use-cases of that draft. However, these two=20 drafts we written at about the same time (with=20 the reqs ID reaching WG consensus first), and by=20 pretty much the same author set (at least the=20 same two editors) and some wording might have=20 been overlooked in one draft where it is in the other draft. That's a roundabout way of saying that if you or=20 anyone has suggested text or a list of=20 bullets/summary of what should be here in the=20 reqs draft, we'll certainly give strong=20 consideration to putting that text in. Paul and I=20 did struggle with this section of what is and=20 what is not a communication session, and felt a=20 short list would be better than a longer, more=20 exhaustive list. It's picking how many examples -=20 but not too many - are included. Any help here would be appreciated. >- S7, third paragraph: In cleartext traffic that is not subject to an > rfc4474-type mechanism, I am not sure how you can prevent an attacker > from spoofing (i.e., changing) the identifier to render is useless? I agree with this, but SIP entities need to be=20 prepared to receive Session-ID header-values that=20 are different. The draft says this. > Likewise, under similar conditions I am not sure how an application > can verify that the session identifier was not changed. see about > Unless, of course, you are stating that the identifier must be > transmitted over a confidential and privacy preserving channel (which > seems to be the gist of the last sentence of the section). If that > is the case, then you may want to highlight in a more prominent form > than currently stated. we'll attempt to make this more clear - that=20 "...the identifier must be transmitted over a=20 confidential and privacy preserving channel..." as you say. Thanks for the review James >Nits: > >- S3.1, first paragraph: s/that,/which,/ > >- S3.1, seventh paragraph: s/speaks of/considers/ > (less colloquial that way). > >Thanks, > >- vijay >-- >Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent >1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) >Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com >Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq From sm@elandsys.com Wed Sep 18 11:53:47 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 513DA11E8108 for ; Wed, 18 Sep 2013 11:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id weJXHxgKHMjm for ; Wed, 18 Sep 2013 11:53:46 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id CB02911E8133 for ; Wed, 18 Sep 2013 11:53:40 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.139.230]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r8IIrIOH029274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Sep 2013 11:53:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1379530410; bh=HSwYdpoHCAmgLVCjqjZV6/CEIyv3hcz2sAm0r+6ZNg4=; h=Date:To:From:Subject:Cc; b=StJ8dirXqZJFMpObBGk6v7JM7la32svUNP1WFrXgDIwSc4jhbfhJl7ecWkEHP1E0a wxxb5gvbH5T20+PrnMvnTmZpg7bDLIFr5ve0XY4e/QjQFkOpfmSIR6vjomtfaC+W8l hbp/1YjIy5ylDS3C/QD2SqVKHJhXKGy8f6cxf5D4= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1379530410; i=@elandsys.com; bh=HSwYdpoHCAmgLVCjqjZV6/CEIyv3hcz2sAm0r+6ZNg4=; h=Date:To:From:Subject:Cc; b=b3aVjQ2WWq5eseXfZqSxyUJZVqlp9tjfPCFmDWRWFJB0wBdKUAj9wa8FVLMIg02FI 2PxNGBmnYmNWn4hEPK8cl+Y/BIsgN0YUIiZvs8+zFOm6AZfAt7v6xuKO1D2c3lRd3Q fVqwiTmviSk9t/2tx7Xq54CFTgH7TGgV09w83MKM= Message-Id: <6.2.5.6.2.20130918110803.0c7029d0@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 18 Sep 2013 11:38:40 -0700 To: Barry Leiba From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-discuss@ietf.org Subject: [apps-discuss] Publication request for draft-ietf-appsawg-malformed-mail-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 18:53:47 -0000 Hi Barry, The Appsawg requests publication of draft-ietf-appsawg-malformed-mail-08. The Document Shepherd Write-Up is below. 1. Summary The document shepherd is S. Moonesamy. The Responsible Area Director is Barry Leiba. draft-ietf-appsawg-malformed-mail-08 provides a collection of the best advice available regarding a variety of common malformed mail situations, to be used as implementation guidance. The intended status is Informational. 2. Review and Consensus The document was discussed by a few participants within the Applications Area Working Group and it has the consensus of the working group. 3. Intellectual Property There isn't any IPR disclosure referencing this document. The authors has confirmed that the document is in full conformance with BCP 78 and BCP 79. 4. Other points The obsolete references to RFC 733 and RFC 1113 are intentional. Regards, S. Moonesamy (as document shepherd) From barryleiba.mailing.lists@gmail.com Wed Sep 18 15:16:43 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC0C011E8263 for ; Wed, 18 Sep 2013 15:16:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.982 X-Spam-Level: X-Spam-Status: No, score=-101.982 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9CksPWnhxFKf for ; Wed, 18 Sep 2013 15:16:43 -0700 (PDT) Received: from mail-ve0-x22c.google.com (mail-ve0-x22c.google.com [IPv6:2607:f8b0:400c:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 6041B11E8112 for ; Wed, 18 Sep 2013 15:16:43 -0700 (PDT) Received: by mail-ve0-f172.google.com with SMTP id oz11so6253115veb.3 for ; Wed, 18 Sep 2013 15:16:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=tDkxJYm6Oy6+lLoVE3ubp37D2BllSBJIc+/1SAie+kc=; b=aUmsFchxBVQ678Q9LWSHDCPBSClrgEgnxL8yNjWbq6/JvJJOsQRp70qSuvb7egyRMt Uu/MMJRxBDQoyFqAhVZ10610HOUKVhV8SS/Um5XGDMyRnkc/FE5wsl42JCGor3Jr6CU1 Dfi6Auki1ihBkEaAqfQ6nx6cHeOMdBqRoPtlYGOxkLHRiCE6i2KuEpLwTACtczSK2dXa kViYcYpmVkdEw1Nb2KjRBrpqKQYpJyzm/v3B6r+97e9Yn+VYUE3Gx0R6BPRJ6HQJOJOB 47SF/9MVmL2GCu7VzRFoQjrqACmxPYurQHRV4ROSpOopYJarXk0Uup5+MX3IXjJQPIr0 q8/w== MIME-Version: 1.0 X-Received: by 10.52.122.68 with SMTP id lq4mr33659537vdb.21.1379542601690; Wed, 18 Sep 2013 15:16:41 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.58.215.16 with HTTP; Wed, 18 Sep 2013 15:16:41 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20130918110803.0c7029d0@elandnews.com> References: <6.2.5.6.2.20130918110803.0c7029d0@elandnews.com> Date: Wed, 18 Sep 2013 18:16:41 -0400 X-Google-Sender-Auth: 1aK0lgOV8cPUrei0DhbeBjm2vM8 Message-ID: From: Barry Leiba To: S Moonesamy Content-Type: text/plain; charset=ISO-8859-1 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Publication request for draft-ietf-appsawg-malformed-mail-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2013 22:16:44 -0000 > 2. Review and Consensus > > The document was discussed by a few participants within the Applications > Area Working Group and it has the consensus of the working group. Is that really all that makes sense to say about this? Nothing else worth noting about the discussion, which the IESG might find useful? As I remember, there was some significant discussion about whether it was even a good idea to publish such a document, and a view that doing so was making some sort of "standardization" of the malformations and the suggested behaviour. This was a significant concern, causing some to object to the document on the whole. As I recall, the language in the document reflects that discussion, and that, while some participants are likely still not happy, the current language has allayed the concerns at least enough to remove the objections. That's as I remember, though I'm aging and my beard is ever greyer; perhaps I'm thinking of another discussion, of another document in a galaxy farther away? Barry From sm@elandsys.com Wed Sep 18 19:05:49 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9FCC11E8170 for ; Wed, 18 Sep 2013 19:05:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id myNmLodflR6Z for ; Wed, 18 Sep 2013 19:05:48 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 509C811E80D7 for ; Wed, 18 Sep 2013 19:05:47 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.139.230]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r8J25O6w000298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Sep 2013 19:05:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1379556335; bh=Gxpej9E/bwa/5Pk6ZSBHfWg4wKM0lqHpx6xSZMczyrA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=cwlEx+frCBfCnpNP26BFyE7lRG/+mRTbUACpnWkk5C3gdCWPMwfwLiJGeaZHfnUn0 8XjPd22b20Pqn989GQqzR9hh15iXaTFwVbIrj8ojQF6WTkI885UPM7/X80K79mlFrV 6ft/NXZRbqScVJ0jl8Yxi21iPOEyAQhdlLpfHegs= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1379556335; i=@elandsys.com; bh=Gxpej9E/bwa/5Pk6ZSBHfWg4wKM0lqHpx6xSZMczyrA=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=tP2ApNWoFYhPNb3Bj4wrgH7axlBHblhjqPV8Mgb283x7yfKTByfn4JBLk3BqtG/C/ OMiiZaaYUHfybSH37hdOvpKHfvwzqiqGpsU0asshznuPsw9lwnkBye3whHS0SG5BC1 JYTXCxFrDZUKfLqgGxz1BELKgK+UzqFQMDqM4eiA= Message-Id: <6.2.5.6.2.20130918163626.0d085360@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 18 Sep 2013 19:04:58 -0700 To: Barry Leiba From: S Moonesamy In-Reply-To: References: <6.2.5.6.2.20130918110803.0c7029d0@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Publication request for draft-ietf-appsawg-malformed-mail-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 02:05:49 -0000 Hi Barry, At 15:16 18-09-2013, Barry Leiba wrote: >Is that really all that makes sense to say about this? Nothing else >worth noting about the discussion, which the IESG might find useful? Sorry about the botched write-up. I see that I missed the review part entirely. >As I remember, there was some significant discussion about whether it >was even a good idea to publish such a document, and a view that doing >so was making some sort of "standardization" of the malformations and >the suggested behaviour. This was a significant concern, causing some >to object to the document on the whole. As I recall, the language in >the document reflects that discussion, and that, while some >participants are likely still not happy, the current language has >allayed the concerns at least enough to remove the objections. Yes. The initial version of the draft was intended as a BCP and it switched to Informational in -02. What I missed, among other things, is that the first discussions about the draft was in 2011. >That's as I remember, though I'm aging and my beard is ever greyer; >perhaps I'm thinking of another discussion, of another document in a >galaxy farther away? No. :-) Summary The document shepherd is S. Moonesamy. The Responsible Area Director is Barry Leiba. The document provides a collection of the best advice available regarding a variety of common malformed mail situations, to be used as implementation guidance. The intended status is Informational as the document provides guidance instead of setting best current practices. Review and Consensus The document was originally intended as best current practices for handling malformed messages. There was a discussion about doing a registry of malformations and their corresponding handling advice rather than updating an RFC whenever the list changes. There was a comment that violations of a protocol specification does not qualify as protocol parameters. It was suggested to use a wiki. The working group decided on having a document that provides advice about the safe handling of malformed messages as it did not make sense to have a uniform policy for dealing with malformed messages and there was a view that it was in the best interest of everyone to document less-harmful avenues to take. During the working group discussions it was mentioned that the robustness principle has had some controversy over the years because deployed servers that accepted non-compliant messages were responsible for widespread deployment of broken clients. This resulted in "standards creep" where new servers were forced to accept common but erroneous messages and protocol usage, and that made it harder to develop extensions. There was a comment about the market exerts strong pressures on receivers to accept malformed messages if the receivers can possibly make sense of them and it was pointed out that enforcement of RFC 5322 and its predecessors tend to cause loss of legitimate messages instead of unwanted messages. There were discussions about the related mail-related standards, MIME, and about examples of malformed messages. There wasn't any noteworthy controversy except for the original intended status of the document. There were reviews from Dave Crocker, John Levine, and Alexey Melnikov. Timo Sirainen reviewed the document from an IMAP developer's point of view. The document has the consensus of the working group. Regards, S. Moonesamy From duerst@it.aoyama.ac.jp Thu Sep 19 01:42:18 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87E4621F99F7 for ; Thu, 19 Sep 2013 01:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.044 X-Spam-Level: X-Spam-Status: No, score=-107.044 tagged_above=-999 required=5 tests=[AWL=-3.254, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Wpxc6iVRaNT for ; Thu, 19 Sep 2013 01:42:12 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id B1D7821F91C9 for ; Thu, 19 Sep 2013 01:42:10 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id r8J8fsAs013768; Thu, 19 Sep 2013 17:41:54 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 0692_e0d9_56586dae_2107_11e3_b098_001e6722eec2; Thu, 19 Sep 2013 17:41:54 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 18A16BF510; Thu, 19 Sep 2013 17:41:54 +0900 (JST) Message-ID: <523AB8C2.9000402@it.aoyama.ac.jp> Date: Thu, 19 Sep 2013 17:41:38 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Alexey Melnikov References: <52382E84.5020302@isode.com> In-Reply-To: <52382E84.5020302@isode.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Comments on draft-masinter-multipart-form-data-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Sep 2013 08:42:18 -0000 Hello Larry, On 2013/09/17 19:27, Alexey Melnikov wrote: > Hi Larry, > Some comments after reviewing your draft: > 3.5. Charset of text in form data > > For example, a form with a text field in which a user typed 'Joe owes > 100' where is the Euro symbol might have form data returned > as: > > --AaB03x > content-disposition: form-data; name="field1" > content-type: text/plain;charset=windows-1250 > content-transfer-encoding: quoted-printable > Joe owes =80100. > --AaB03x > > Are you missing an empty line after "content-transfer-encoding:"? This > doesn't look like a proper MIME fragment. It would be great to have an example with UTF-8, too. This would look as follows: --AaB03x content-disposition: form-data; name="field1" content-type: text/plain;charset=UTF-8 content-transfer-encoding: quoted-printable Joe owes =E2=82=AC100. --AaB03x Regards, Martin. From julian.reschke@gmx.de Thu Sep 19 03:28:06 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB4621F9302 for ; Thu, 19 Sep 2013 03:28:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.155 X-Spam-Level: X-Spam-Status: No, score=-106.155 tagged_above=-999 required=5 tests=[AWL=-3.556, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41Y-uccuV4W6 for ; Thu, 19 Sep 2013 03:28:01 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 30F3021F9196 for ; Thu, 19 Sep 2013 03:28:00 -0700 (PDT) Received: from [192.168.2.117] ([93.217.69.230]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0Lj1Xa-1Vu1nl2lSQ-00dEJ9 for ; Thu, 19 Sep 2013 12:28:00 +0200 Message-ID: <523AD1A3.6000808@gmx.de> Date: Thu, 19 Sep 2013 12:27:47 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Larry Masinter , "apps-discuss@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:O7NOvYt+OfhQsOcdIobK0ZeZ8kDDjYXRqZYUCMnJmt2vXNb7j3a Zudfdbo1J83pA9TSLD4O2UJBemvd9KZ/H6vw7QxEXP0yYRRARwbENA86n7UZc5Y5KbhIXRs 7SofiB0YJ8lvQucfHHA7MkBOsp6n1MwKV+g8c1ccKN7o5buP6bPJcQf9uK3Hh/6B1lARIBj vM+qD6OX4JZxOlzXnxo+w== Cc: Ian Hickson Subject: Re: [apps-discuss] Feedback on multipart/form-data X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 10:28:06 -0000 On 2013-08-15 20:28, Larry Masinter wrote: > I'm working on a revision to RFC 2388 multipart/form-data > but I want some feedback before submitting a first draft. > > I sent a pointer before, > https://www.w3.org/Bugs/Public/show_bug.cgi?id=16909#c8 > > but perhaps you can comment instead on > https://github.com/masinter/multipart-form-data > > > RFC 2388 was clear: > Field names originally in non-ASCII character sets may be encoded > within the value of the "name" parameter using the standard method > described in RFC 2047. > > For reasons I don't understand, browsers did different, incompatible > things. Insane complexity? :-) Too many ways to do the same thing? > I think the main advice is: > > * those creating HTML forms > SHOULD use ASCII field names, since deployed HTML processors vary, > and field names shouldn't be visible to the user anyway. +1 > * Those developing server infrastructure to read multipart/form-data uploads > SHOULD be aware of the varying behavior of the browsers in translating > non-ASCII field names, and look for any of the variants (if they're > expecting non-ASCII field names). If this is a SHOULD we need to better understand what these variants are. Study standard libraries? Write tests? > * Those developing browsers should migrate toward a standard > encoding, but the server infrastructure will still have to do > fuzzy match for a long while. > > What should the browsers migrate to? > > http://www.rfc-editor.org/rfc/rfc5987.txt > seems like a more recent proposal and possibly implemented in HTTP anyway. +1 > Sites that use non-ASCII field names and want to work with multiple > browsers already have to do fuzzy matching. > > The problem is that the fuzzy matchers already deployed might not > recognize any *NEW* encodings. Also, they probably vary on User-Agent. > So I suppose having a name* value would be necessary. Indeed. We had the same conversation for Content-Disposition (the HTTP header field), and in the those UA vendors opposed to RFC2231/5987 gave up and implemented it (IE, Chrome, Safari). Best regards, Julian From sm@elandsys.com Thu Sep 19 04:00:51 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FEC021F999C; Thu, 19 Sep 2013 04:00:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.863 X-Spam-Level: X-Spam-Status: No, score=-101.863 tagged_above=-999 required=5 tests=[AWL=-0.660, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OKvXZgr2KDIj; Thu, 19 Sep 2013 04:00:49 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id D2D3B21F999B; Thu, 19 Sep 2013 04:00:49 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.139.230]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r8JAxrLq008034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Sep 2013 04:00:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1379588411; bh=cfeCFEKsXt3+3XWRExV+aYLY7LT/PAK9OAtCg6qXWyo=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=ub2HzyncmRRgMyCSGwCEqrS5t8vFVuR5mzkJ/FyeRfY6+mNggydIrGBKysWJuUy2N j7acYaa4bn79NYHKAwY6bwMIJ+PfsoE/PxcTxbmbW71euozI4IK49VcmgQdWBmxITo KcvCstyLT5TFmf4QS3bztkjiCT2GyqZz6GXinxPc= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1379588411; i=@elandsys.com; bh=cfeCFEKsXt3+3XWRExV+aYLY7LT/PAK9OAtCg6qXWyo=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=GbtHolSCG+PPRHh13D0+1JAQaAtWE/RC1PqghXE+D0kSnMVJqPoy6EWHKHOyzCgSP DMHfkf+wPSXvMhVvrTcJkDXjT+Fa5Pr/6MUS7WMG6uwowwR5Rc+OqEfZVgnE2mAIyu okArIaOedAn2o4pIQyD7PiyifQ7dXaqTmbQl+lls= Message-Id: <6.2.5.6.2.20130918225335.0d0e2478@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 19 Sep 2013 03:59:30 -0700 To: Tim Chown From: S Moonesamy In-Reply-To: References: <6.2.5.6.2.20130914143222.0b9590f0@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: homenet@ietf.org, draft-ietf-homenet-arch.all@tools.ietf.org, apps-discuss@ietf.org, iesg@ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-homenet-arch-10 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 11:00:51 -0000 Hi Tim I added Dave Cridland to the Cc so that he can=20 follow up on your response to his comments. At 16:10 18-09-2013, Tim Chown wrote: >The document was produced with five general=20 >areas in mind, which was the brief agreed by the=20 >chairs after the original interim meeting in=20 >Philiadelphia. Those are routing, prefix=20 >configuration, name resolution, service=20 >discovery, and network security. There is thus=20 >no specific consideration of applications. That=20 >said, such guidance would be very useful, and it=20 >would be quite feasible to draft a separate=20 >application-oriented/perspective text, including=20 >expertise from apps area - would that address your concern? The intent of my comment was not about adding=20 more text, or application-specific=20 considerations, to the document. The title of=20 the document is "Home Networking Architecture for=20 IPv6". My guess is that if IPv6 home networking=20 takes off people, e.g. application developers,=20 will look for some material to understand what it=20 is about. As this document is about the=20 architecture it looks like a good starting point=20 to understand the subject. Section 1 is lengthy=20 but it does not provide a concise description of=20 what IPv6 home networking is about. That=20 section has some discussion about what can be=20 assumed and what should not be assumed. Section=20 2 discusses about the effects of IPv6 on home=20 networking. The reader has to reach Section 3 to=20 see the general principles (Page 12). There is=20 then a description of different network=20 topologies. The average or application reader=20 might conclude that the document is about routing=20 stuff and it is not useful to spend more time=20 reading. Please note that although the intended=20 status is Informational I am reading the document=20 as one intended for the standards track as it is about architecture. The Chairs have already agreed about the five=20 topics to be covered. It's not a problem. The=20 next step would be to take these topics, make=20 them accessible to the average reader, and=20 organize them. This may require avoiding too many details if it is doable. (a) Should effects be before principles? Do you even need that section? (b) Will the application developer, for=20 example, understand PI and end sites? (c) Does the document need seven paragraphs about ULA? (d) What are realms, borders and demarcation about? (e) What is important about prefixes? (f) Why have stable internal IP addresses and ULA separately? (g) How does naming and service discovery affect my application? (h) Should I assume end-to-end (with a global namespace)? (i) What is the security model? Please note that the above questions are there=20 mostly to look at the different from a different=20 perspective. They do not need to be answered and it is not an exhaustive= list. >There is already a split namespace for existing=20 >home networks. Devices may live under .local=20 >(for mDNS/DNS-SD), which has meaning on the=20 >subnet in question (though some emerging vendor=20 >products are proxying this through routers -=20 >hence the desire to form a dnssdext WG to look=20 >at that topic), and/or may use a globally unique name space. > >The issue in future home networks is how naming=20 >and SD works across a routed, multi-link home.=20 >What is the equivalent "local" name space, that=20 >can be used whether the home is externally=20 >connected or not, providing independent operation where necessary. > >That section discusses how that "local" name=20 >space might look, and is the result of=20 >considerable discussion in the homenet WG. > >Do you have something specific to propose to say instead? From the above I gather that the namespace issue=20 is currently unresolved. I suggest stabilizing=20 the document and put the part about namespace on=20 hold. You could document the discussion for now=20 and list that as unresolved issues. > > The document mentions ".sitelocal (or an=20 > appropriate name reserved for the purpose)". Quoting RFC 6761: > > > > "Are writers of application software expected to make their > > software recognize these names as special and treat them > > differently? In what way?" > >It's interesting that the dnssdext BoF pushed=20 >back on tackling name space issues, and focusing=20 >on service discovery, should that WG be formed.=20 >But there has been plenty of discussion in the BoF(s) That sounds like hot potato routing. :-) > and (old name) mdnsext list about the issues.=20 > For example how names used in "local" service=20 > discovery protocols might be published in a=20 > global DNS name space. One of the three=20 > proposed deliverables of dnssdext would be to=20 > identify and document those issues as the SD=20 > work progresses. Input from application developers would be welcome. I suggest talking to the relevant Area Directors about the above. >The point here is that hosts in a=20 >self-configuring routed home network need to=20 >learn the DNS resolvers to use. How for example=20 >the leaf router determines which DNS resolvers=20 >to put into RAs. There has been discussion on=20 >homenet and elsewhere about how that could be=20 >done, whether it might (for example) be passed=20 >in the routing protocol (e.g. OSPF could support=20 >it) or whether a separate protocol is=20 >required. The search domain sentence is an=20 >example of other configuration information. It could be omited if prefered. The above is what the IETF calls a chicken and=20 egg problem. I mentioned search domains because=20 of RFC 1535. Search domains are not related to=20 DNS resolvers. Even if you get information about=20 DNS resolvers from your upstream you still have=20 to consider the disconnected scenario (Section 3.7.5). The document discusses about independent=20 operation in Section 3.7.5 while namespace (e.g.=20 Local Qualified Domain Name) is discussed in=20 Section 3.7.3 (re. previous comment about=20 organizing topics). It may be easier for the=20 reader if the principle is introduced before the discussion relating to it. RFC 1123 discusses about requirements for=20 Internet hosts. There is a discussion of search=20 lists in Section 6.1.4.3. I suggest considering=20 whether there is a conflict between that and the=20 architecture which is being proposed, and what=20 are the workable alternatives between the layer=20 you are working at and the application layer. As=20 a matter of individual preference I would omit=20 the search domain sentence as there isn't an=20 explanation about why it should be included. >This was a general principle agreed early on in=20 >the WG, and appears to have wide consensus. The=20 >sentence is in the context of a dual-stack homenet. Ok. >The second sentence stems from the 'support=20 >arbitrary topologies' principle. Do you have=20 >alternative text, or would you prefer it was=20 >omited? I think we'd need to have words there to=20 >suggest that the homenet user is most likely=20 >unaware of the creation of internal NAT, be that=20 >from introducing an IPv4 internal router, or by=20 >running a VM or something similar. So long as it "just works". I would consider moving the text (and other IPv4=20 related discussions) to an appendix. I don't=20 think that it is that important for the homenet=20 user to be informed about the creation of hidden=20 NATs, or being confused about home routers and=20 home switches. What you are looking at is=20 cascaded NATs. Does it fit within an existing=20 topology? If the answer is yes the scenario is=20 already covered. The same applies for Virtual=20 Machine Hypervisors. RFC 4101 states that=20 abstraction is good. I think that there would be=20 agreement about it "just works". If some finer=20 details can be omitted to get there I suggest=20 omitting them. My preference would be to remove the second sentence. >There is very strong consensus in homenet=20 >against introducing NPTv6. Whether that affects=20 >what ISPs do is of course another question. Ok. >Certainly. The above text stems from some ISPs=20 >already only offering a /64. Currently some=20 >offer /48, while many offer a /56. But it's too=20 >early still to make any firm comment on common practices. The above explanation is clear. You could add=20 some text and put the details in an unresolved issues. >Well, RFC 3177 is now considered=20 >obsolete. There is strong consensus in the=20 >homenet WG that the text from RFC 6177 is=20 >appropriate, and I have spoken to a number of=20 >ISPs about it, who seem to agree. So emphasising=20 >what RFC 6177 says today seems a reasonable approach. I'll highlight that the previous comment=20 mentioned that it is to early to make a firm=20 comment on common practices. The lesson learnt=20 from RFC 3177 is what people will agree to=20 something now and disagree later. The argument=20 is then of a political nature. I suggest not=20 attempting to tackle assignment policies in the document. >Of course, some countries may introduce laws or=20 >regulations that make RFC 6177 hard to=20 >follow. But that shouldn't affect our document=20 >on architectural principles, should it? draft-kolkman-proposed-standards-clarified is=20 also about taking care of regulatory issues. If=20 RFC 6177 was revisited it can affect this document. >My understanding is that this was added as a result of German law. Ok. >It provides some security. Is there specific=20 >text in 3.6 or one of its subsections that's problematic for you? It's not problematic for me. >That could instead say "third party service" - would that be better? That sounds better. The other part of the=20 question was what name space does it provide. > > "Also, with the introduction of new 'dotless' top level domains, there > > is also potential for ambiguity between, for example, a local host > > called 'computer' and (if it is registered) a .computer gTLD." > > > > The IAB has issued a statement about "dotless=20 > domain considered as harmful" (=20 >= http://www.iab.org/2013/07/10/iab-statement-dotless-domains-considered-harm= ful/=20 > ). I don't understand why this document=20 > discusses about the introduction of dotless domains. > >I don't understand why it would not mention the=20 >issue. The IAB statement post-dated the (brief)=20 >text in this draft. Would a reference to the IAB statement address your= point? Version -10 is dated August 1. That is after the=20 IAB statement. My suggestion is to avoid having=20 any text about=20 dotless. draft-moonesamy-dotless-domains-00 is a=20 quick attempt to list the application perspective. >The wording is clumsy here I agree. The point is=20 >that some devices in the homenet may be=20 >registered under the/a global name space=20 >associated with the homenet, but where mobile=20 >may acquire a different IP address to that=20 >registered to that name in their home network.=20 >Hence the next sentence and next paragraph. We=20 >can rewrite that text to be clearer. Ok. > > Nits: > > > > I suggest fixing "This text" in the Abstract. > >This document? Or=85? "This document" could be used throughout the draft. > > I am including the review from Dave Cridland for APPSDIR: [snip] >Yes, it could be improved. An AD I think asked=20 >if there should be a summary of=20 >recommendations/principles, perhaps as an=20 >appendix. In an earlier version we had these=20 >enumerated in each section, but that was undone=20 >at the request of the chairs, because (I think)=20 >they felt it broke the flow of the text. Do you=20 >think an appendix summary (with pointers back to=20 >the sections they are taken from) is desirable=20 >as a form of "checklist" for readers? I'll leave this question for Dave Cridland to answer. Regards, S. Moonesamy=20 From dave@cridland.net Thu Sep 19 04:34:30 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE51E21F915C for ; Thu, 19 Sep 2013 04:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8aIwudUmfQJQ for ; Thu, 19 Sep 2013 04:34:28 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 804D721F8E2D for ; Thu, 19 Sep 2013 04:34:28 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id l18so6907858wgh.2 for ; Thu, 19 Sep 2013 04:34:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=to:message-id:from:cc:date:mime-version:subject:content-type; bh=eDimfH0NbZMJyHOvTBh84KYd7hxl+aw3iEirBSMxD5c=; b=g8DikId/3eBmbV7MKxCh4OCrCI75rdcWoUBzNlQ62tXPD42AQTlSRfmGb8A+c6sxMF jac1DnIqlLZxHMop9K6hnx5nCMRx014iEzgQSi4VNPdJhXNOkFKkMYPVcX2gPlEgRJpn MOUjfTZsTZwlwq+wATV65WN9iEQVdIfESEV9Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:message-id:from:cc:date:mime-version:subject :content-type; bh=eDimfH0NbZMJyHOvTBh84KYd7hxl+aw3iEirBSMxD5c=; b=AgCDwRlD0VGP4J1/mJB1SlqhoaPh9CMfAh+ZAtHKITK7+DojhVWXdMY+O8m/bFlHmp tzbZX24FxNbbaXpXBBNM2XQ+RP5tx1Nh+Kgq896bAKfoXJWVXNDnagjXOFQH+T7E8jr1 ojkU8ziCMsqXG8MM/088CaHsykk7dxd/9kg0vtP9JJpuJyuRFXIyX4bKHckK8pTLlv3a GxrR84zBZda2L0k7gPFIqdnvh8xILwGED/iDmzydRDbeAibiOXbraqmvW4ElGK4vJKPs 1EmocawJWCVTFE7SAxy8mnIrNdmgfprOVnXM951eO/8xQuAvjCl3Z8wqKmCKT/HgM7S6 dw8g== X-Gm-Message-State: ALoCoQnLCyRHp7U65XtQMdINt3MYpD/gc9VFlJNWSHAnNNtdu79936yKET8i5FzrnG1nPWizNijL X-Received: by 10.194.77.2 with SMTP id o2mr944645wjw.57.1379590467472; Thu, 19 Sep 2013 04:34:27 -0700 (PDT) Received: from Mac-mini.local (peirce.dave.cridland.net. [217.155.137.61]) by mx.google.com with ESMTPSA id dq11sm18168648wid.3.1969.12.31.16.00.00 (version=TLSv1.1 cipher=RC4-SHA bits=128/128); Thu, 19 Sep 2013 04:34:26 -0700 (PDT) To: Julian Reschke Message-Id: From: Dave Cridland Date: Thu, 19 Sep 2013 11:34:24 -0000 Mime-Version: 1.0 X-Mailer: Inky (TM) v2.0.523A.D3E0 ("Ink Different") Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Ian Hickson , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Feedback on multipart/form-data X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 11:34:31 -0000 Julian Reschke wrote: > On 2013-08-15 20:28, Larry Masinter wrote: >> I'm working on a revision to RFC 2388 multipart/form-data >> but I want some feedback before submitting a first draft. >> >> I sent a pointer before, >> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16909#c8 >> >> but perhaps you can comment instead on >> https://github.com/masinter/multipart-form-data >> >> >> RFC 2388 was clear: >> Field names originally in non-ASCII character sets may be encoded >> within the value of the "name" parameter using the standard method >> described in RFC 2047. >> >> For reasons I don't understand, browsers did different, incompatible >> things. > > Insane complexity? :-) Too many ways to do the same thing? RFC 2047 doesn't discuss parameters; though at least some mail MIME generators use it, instead of RFC 2231. (Google, for instance, generates mail using RFC 2047 encoded-words in parameters, but accepts either RFC 2047 or RFC 2231 encoded parameters). >> I think the main advice is: >> >> * those creating HTML forms >> SHOULD use ASCII field names, since deployed HTML processors vary, >> and field names shouldn't be visible to the user anyway. > > +1 That's all well and good, but filenames are considerably more of a problem, I'd have thought. Moreover, I think existing HTTP clients don't escape '"' properly, as well. >> * Those developing server infrastructure to read multipart/form-data >> uploads >> SHOULD be aware of the varying behavior of the browsers in translating >> non-ASCII field names, and look for any of the variants (if they're >> expecting non-ASCII field names). > > If this is a SHOULD we need to better understand what these variants are. > Study standard libraries? Write tests? I know of RFC 2047 and RFC 2231, as well as unencoded UTF-8 and unencoded ISO-8859-1 (I think). I'd also note that I've yet to find a receiving processor that handles multipart/form-data when chunked - I'll admit I've not been looking much, though. It might be as well to note the interaction with chunked encoding. Sent with [inky: ] From julian.reschke@gmx.de Thu Sep 19 04:58:28 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF5221F92B8 for ; Thu, 19 Sep 2013 04:58:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.799 X-Spam-Level: X-Spam-Status: No, score=-105.799 tagged_above=-999 required=5 tests=[AWL=-3.200, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BwmB2+USHJUw for ; Thu, 19 Sep 2013 04:58:24 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 1337021F92CD for ; Thu, 19 Sep 2013 04:58:17 -0700 (PDT) Received: from [192.168.2.117] ([93.217.69.230]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0Mh9cj-1Va37P0lN3-00MI4p for ; Thu, 19 Sep 2013 13:58:14 +0200 Message-ID: <523AE6D5.9000105@gmx.de> Date: Thu, 19 Sep 2013 13:58:13 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Dave Cridland References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:wtBfccnDJG3pNSWa1ZQ/2wmg7I6bWEp9Kk2qYqdPbcRylSGseXI WCxyx1ZdhF2E56Aqrcjt+q23LartBONCc8VrvXOtbwP1QmLFgaiqEhOjNLd4zxCI3iqcdVE Vzlb2VPKNp3aiVzIdo0JtxaNXhRzWlHMhSaqgbd27z5UvXXFNOa7ECoS3KklDgnsg6Qfcmf ITJpT18Y039CRj+i/CVlw== Cc: Ian Hickson , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Feedback on multipart/form-data X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 11:58:28 -0000 On 2013-09-19 13:34, Dave Cridland wrote: > Julian Reschke wrote: >> On 2013-08-15 20:28, Larry Masinter wrote: >>> I'm working on a revision to RFC 2388 multipart/form-data >>> but I want some feedback before submitting a first draft. >>> >>> I sent a pointer before, >>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16909#c8 >>> >>> but perhaps you can comment instead on >>> https://github.com/masinter/multipart-form-data >>> >>> >>> RFC 2388 was clear: >>> Field names originally in non-ASCII character sets may be encoded >>> within the value of the "name" parameter using the standard method >>> described in RFC 2047. >>> >>> For reasons I don't understand, browsers did different, incompatible >>> things. >> >> Insane complexity? :-) Too many ways to do the same thing? > > RFC 2047 doesn't discuss parameters; though at least some mail MIME > generators use it, instead of RFC 2231. (Google, for instance, generates > mail using RFC 2047 encoded-words in parameters, but accepts either RFC > 2047 or RFC 2231 encoded parameters). Yup, it's wide-spread in mail, but not used a lot on the web. >>> I think the main advice is: >>> >>> * those creating HTML forms >>> SHOULD use ASCII field names, since deployed HTML processors vary, >>> and field names shouldn't be visible to the user anyway. >> >> +1 > > That's all well and good, but filenames are considerably more of a > problem, I'd have thought. Moreover, I think existing HTTP clients don't > escape '"' properly, as well. Yes. There's also the issue clients not escaping backslashes in path names. (IE?) >>> * Those developing server infrastructure to read >>> multipart/form-data uploads >>> SHOULD be aware of the varying behavior of the browsers in >>> translating >>> non-ASCII field names, and look for any of the variants (if they're >>> expecting non-ASCII field names). >> >> If this is a SHOULD we need to better understand what these variants >> are. Study standard libraries? Write tests? > > I know of RFC 2047 and RFC 2231, as well as unencoded UTF-8 and > unencoded ISO-8859-1 (I think). No surprise here :-) > I'd also note that I've yet to find a receiving processor that handles > multipart/form-data when chunked - I'll admit I've not been looking > much, though. It might be as well to note the interaction with chunked > encoding. > > Sent with [inky: ] Best regards, Julian From Ted.Lemon@nominum.com Thu Sep 19 05:55:26 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D5B121F9654; Thu, 19 Sep 2013 05:55:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.511 X-Spam-Level: X-Spam-Status: No, score=-106.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tRpi6ynR6GcM; Thu, 19 Sep 2013 05:55:20 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id DF41E21F9385; Thu, 19 Sep 2013 05:55:19 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKUjr0N6E1RQ2OVYlnERSIAAXBW5sX9rji@postini.com; Thu, 19 Sep 2013 05:55:20 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 292E41B82DE; Thu, 19 Sep 2013 05:55:19 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 92F6A190068; Thu, 19 Sep 2013 05:55:16 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 19 Sep 2013 05:55:16 -0700 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1811\)) From: Ted Lemon In-Reply-To: <6.2.5.6.2.20130918225335.0d0e2478@elandnews.com> Date: Thu, 19 Sep 2013 08:55:14 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <6.2.5.6.2.20130914143222.0b9590f0@elandnews.com> <6.2.5.6.2.20130918225335.0d0e2478@elandnews.com> To: S Moonesamy X-Mailer: Apple Mail (2.1811) X-Originating-IP: [192.168.1.10] Cc: "" , Tim Chown , The IESG , draft-ietf-homenet-arch.all@tools.ietf.org, "homenet@ietf.org Group" Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-homenet-arch-10 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 12:55:26 -0000 On Sep 19, 2013, at 6:59 AM, S Moonesamy wrote: > The Chairs have already agreed about the five topics to be covered. = It's not a problem. The next step would be to take these topics, make = them accessible to the average reader, and organize them. This may = require avoiding too many details if it is doable. I think that you are interpreting this document to be something that it = is not, and cannot yet be. What this document is is an architecture = for the homenet working group=97a crib sheet that tells us what we are = trying to accomplish. I don't think it's intended to be something that = a random person who is not implementing home gateways would find useful. = The working group is hoping that subsequent versions of this document = will evolve over time, and I think it would be good for the working = group to evolve the document into something that meets the goals that = you've set out above. However, I think that if the working group attempts to do that now, two = things will happen. First, the working group won't actually get to the = work it's supposed to be doing, because completing the architecture = document will continue to be an all-consuming effort. Second, the = document that is produced will be purely theoretical, not based on = actual practice, and probably useless. So I would like you to consider whether you can accept this restatement = of the purpose of the document. Do you feel that this document cannot = be of use until it meets the goals you've set out above, or does the = different purpose I've expressed here make sense to you? If the = latter, can you reconsider your review in light of this new stated = purpose for the document? Is part of the problem that the goals of the = document are poorly expressed in the document? Given the goals I've = stated, do all of your comments still apply, or would you have responded = differently to the document if you'd been evaluating it on the basis I'm = proposing? From dave@cridland.net Thu Sep 19 06:24:46 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95C0721F92B8 for ; Thu, 19 Sep 2013 06:24:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X6m4UHRq+Xar for ; Thu, 19 Sep 2013 06:24:46 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id 96BCA21F938E for ; Thu, 19 Sep 2013 06:24:45 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id ex4so7996096wid.14 for ; Thu, 19 Sep 2013 06:24:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=to:message-id:from:cc:date:mime-version:subject:content-type :content-transfer-encoding; bh=L2Bxz29988mR9SYEi0EZrA4g3MXWPu5K2qDjVUmexy0=; b=Dp3Cjdtql3FvXplOIwKCnRPXsuNda7daNX33Ai0b6g9lr/LXsMsV8aEyy5gkgUclYP g6r/P1qNF4872j/g1lXUgGxWBdZ24laS7KC2ssOzwxTrBZuhIx3OoumF3YFMJewWJY2d 3L3i3oTfvl1sD5F1aEx3Al+5WZM/7xh7OOtJc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:message-id:from:cc:date:mime-version:subject :content-type:content-transfer-encoding; bh=L2Bxz29988mR9SYEi0EZrA4g3MXWPu5K2qDjVUmexy0=; b=aPCmQ4f0jqweX36kgvOjny595HD01ODAakheDIAKsTQqKMWZa02LqrIZSfOHYT0f0G Vl31kavwadP6+3G0zJJhEOPijEctS6s8I3UCpHf3dDe7R6D2HH0DB68JF2YWIQXrG1Q2 NgTQc3c89AeKMvHMEXkNCqoRVjD4pxioNLmVsQw+Bk+ZCeA19qx5Ux71sad7bsGXa76u DWvn1RBfxvehbi4MdT5CMU4+i7HA8oabGTjtQi/UUcIGAXi5d81Bl3FLhX7mubJMpVBl LudfhHeJ0e9Pa8tdJr3C4vmyCf8AaY0eR6IsYWfnfB9EQJUKX+xqO75gy9bDCdgaFS+q EjXQ== X-Gm-Message-State: ALoCoQkUfwr2hminEV7WnKqzcsw16tdfdjpNgl/W9Ds+2sLf7dMprb/hLE15K+sMr0+X2Zhkm/kz X-Received: by 10.180.219.8 with SMTP id pk8mr11472746wic.58.1379597084666; Thu, 19 Sep 2013 06:24:44 -0700 (PDT) Received: from Mac-mini.local (peirce.dave.cridland.net. [217.155.137.61]) by mx.google.com with ESMTPSA id e1sm18883833wij.6.1969.12.31.16.00.00 (version=TLSv1.1 cipher=RC4-SHA bits=128/128); Thu, 19 Sep 2013 06:24:43 -0700 (PDT) To: Ted Lemon Message-Id: From: Dave Cridland Date: Thu, 19 Sep 2013 13:24:37 -0000 Mime-Version: 1.0 X-Mailer: Inky (TM) v2.0.523A.D3E0 ("Ink Different") Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Cc: "" , S Moonesamy , Tim Chown , The IESG , draft-ietf-homenet-arch.all@tools.ietf.org, "homenet@ietf.org Group" Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-homenet-arch-10 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 13:24:46 -0000 Ted Lemon wrote: > On Sep 19, 2013, at 6:59 AM, S Moonesamy wrote: > > The Chairs have already agreed about the five topics to be covered. > It's not a problem. The next step would be to take these topics, make > them accessible to the average reader, and organize them. This may > require avoiding too many details if it is doable. > > I think that you are interpreting this document to be something that it is > not, and cannot yet be. What this document is is an architecture for the > homenet working group—a crib sheet that tells us what we are trying to > accomplish. I don't think it's intended to be something that a random > person who is not implementing home gateways would find useful. The working > group is hoping that subsequent versions of this document will evolve over > time, and I think it would be good for the working group to evolve the > document into something that meets the goals that you've set out above. > > However, I think that if the working group attempts to do that now, two > things will happen. First, the working group won't actually get to the work > it's supposed to be doing, because completing the architecture document will > continue to be an all-consuming effort. Second, the document that is > produced will be purely theoretical, not based on actual practice, and > probably useless. > > So I would like you to consider whether you can accept this restatement of > the purpose of the document. Do you feel that this document cannot be of > use until it meets the goals you've set out above, or does the different > purpose I've expressed here make sense to you? If the latter, can you > reconsider your review in light of this new stated purpose for the document? > Is part of the problem that the goals of the document are poorly expressed in > the document? Given the goals I've stated, do all of your comments still > apply, or would you have responded differently to the document if you'd been > evaluating it on the basis I'm proposing? > Then the title ought to call itself Requirements, or Proposed, or something. Actually, I genuinely struggle to understand the purpose of publishing documents which are intended as working documents for a particular Working Group as an RFC, but on the basis that it's required for some reason I don't understand, then calling it the "Home Networking Architecture for IPv6" is confusing - I read that, perhaps terribly naively, as being a document defining the Home Networking Architecture for IPv6. Partly because, right at the top, it says "The goal of this document is to define a general architecture for IPv6-based home networking". It really had me fooled. I appreciate I'm obviously foolish and easily mislead, but perhaps calling entitling it "Architectural Requirements for IPv6 Home Networking", or "Proposals and Considerations for Home Networking Architecture for IPv6", might give the reader the hint that it's not defining an architecture as such. Dave. Sent with [inky: ] From dave@cridland.net Thu Sep 19 06:29:37 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16D0321F9477 for ; Thu, 19 Sep 2013 06:29:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TjrjWjXKCaTw for ; Thu, 19 Sep 2013 06:29:36 -0700 (PDT) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 5F2C721F9473 for ; Thu, 19 Sep 2013 06:29:36 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id z12so7999710wgg.10 for ; Thu, 19 Sep 2013 06:29:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=to:message-id:from:cc:date:mime-version:subject:content-type; bh=Z0FLylfn0rL/Xds2RFbdTVW75A2wgQwTp2pF/pgEA8E=; b=YtSMSeV0goxrCsp+rVjZYqOn+bJIKLfzzDWdzn+4vNfJWE9/Rk4OkOm6WVu51DyiEe CJ9Q1aPUFSew7P58b7tdAQmarOjKgbB1A2XeSOoKdoWGH9T2PcYPlFsHkmfs/yWrMmUo nSB/S1Ahk4Lh4c6sjk/jKUxXJC0GI9An41eQk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:message-id:from:cc:date:mime-version:subject :content-type; bh=Z0FLylfn0rL/Xds2RFbdTVW75A2wgQwTp2pF/pgEA8E=; b=UIz+vmUVn35EdItfQPtDjE8XitKrYIwNfS16Sc7cDjqBpM+svOysEWZsGvf1ygn2XS K1nllzTf6GzXOceVnMbzYAPzQmXEc3h0P8r/dRNb0oqqp531XHx9aUQWcm1zfP442Lur qb8HesvdEvMtt1GYp2XZOqiMA4j6l1QCW8vrai+lyQ6z9h75Qe7ffq5ouJgQfCeksLsY 2Go44IguhRQU8PRUc51OiAZFRA6QYJzJNCMDQw+fWLcSehnfVt+U19+TA67e/H+ZV78M kKbZemIA9VuQgtLgIDyJW9mMr77izrHjacdixbigAUvJiooBUJrmxBsxar4g/eQSZi7r 0zvQ== X-Gm-Message-State: ALoCoQlKzqYM+pogHuYFwq750bbhPnFgj+cnX1AGz50HEPd0IlGMNd4DTU2wwNsq5N0+80EN5091 X-Received: by 10.194.239.74 with SMTP id vq10mr333534wjc.70.1379597375510; Thu, 19 Sep 2013 06:29:35 -0700 (PDT) Received: from Mac-mini.local (peirce.dave.cridland.net. [217.155.137.61]) by mx.google.com with ESMTPSA id mw9sm17646172wib.0.1969.12.31.16.00.00 (version=TLSv1.1 cipher=RC4-SHA bits=128/128); Thu, 19 Sep 2013 06:29:34 -0700 (PDT) To: Julian Reschke Message-Id: From: Dave Cridland Date: Thu, 19 Sep 2013 13:29:33 -0000 Mime-Version: 1.0 X-Mailer: Inky (TM) v2.0.523A.D3E0 ("Ink Different") Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Ian Hickson , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Feedback on multipart/form-data X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 13:29:37 -0000 Julian Reschke wrote: >> >> I know of RFC 2047 and RFC 2231, as well as unencoded UTF-8 and >> unencoded ISO-8859-1 (I think). > > No surprise here Yes, but one wonders if the unencoded UTF-8 actually does any harm at all in a 8bit/binary-safe protocol like HTTP. If most processors accept this - and I have no idea - it might even be useful to document. Dave. Sent with [inky: ] From julian.reschke@gmx.de Thu Sep 19 06:40:55 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1812B21F9323 for ; Thu, 19 Sep 2013 06:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.537 X-Spam-Level: X-Spam-Status: No, score=-105.537 tagged_above=-999 required=5 tests=[AWL=-2.938, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BfasWplVSCMO for ; Thu, 19 Sep 2013 06:40:48 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF7221F942D for ; Thu, 19 Sep 2013 06:40:47 -0700 (PDT) Received: from [192.168.2.117] ([93.217.69.230]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0Lskr7-1W2TWm1Txp-012FkZ for ; Thu, 19 Sep 2013 15:40:46 +0200 Message-ID: <523AFED3.5040404@gmx.de> Date: Thu, 19 Sep 2013 15:40:35 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Dave Cridland References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:p5FcHe9O/iVoq0QC7Q9iDjPR9521llrZVLs3aDiJ9Z/VGgJSTYr xeRzBBr/6070bLQDuWm5luBaJuwh/taw4MOfYuuZ+wWF7bTWJHAB/tz6tajWuE0uojmsS4p DVl5ZVcfSfdsrgl3LdsFaKgLklQToSrKAln62T8PnBfGFRwO3fE7MQw/eLxhMkO5TRez86n yj7S18mMqrA3q8rKJtgMw== Cc: Ian Hickson , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Feedback on multipart/form-data X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 13:40:55 -0000 On 2013-09-19 15:29, Dave Cridland wrote: > Julian Reschke wrote: >>> >>> I know of RFC 2047 and RFC 2231, as well as unencoded UTF-8 and >>> unencoded ISO-8859-1 (I think). >> >> No surprise here > > Yes, but one wonders if the unencoded UTF-8 actually does any harm at > all in a 8bit/binary-safe protocol like HTTP. > > If most processors accept this - and I have no idea - it might even be > useful to document. The risk here is that some UAs send ISO-8859-1 (or something based on the locale), and servers parse based on the User-Agent. We have the same problem with the Content-Disposition response header field. It's hard to change these kinds of workarounds in deployed code, and that's why a new mechanism that can't be confused with the old syntax may work better (thus RFC 5987). Best regards, Julian From dave@cridland.net Thu Sep 19 07:43:17 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEA0D21F9929 for ; Thu, 19 Sep 2013 07:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qqZptK567AoU for ; Thu, 19 Sep 2013 07:43:16 -0700 (PDT) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id C6D9D21F92C2 for ; Thu, 19 Sep 2013 07:43:13 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id f12so8151762wgh.5 for ; Thu, 19 Sep 2013 07:43:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=to:message-id:from:cc:date:mime-version:subject:content-type; bh=6p3ld/mcpxMOcmrMJU08GOPLm91onlPDJIM1ACMXGyU=; b=ESXRxMa/SqcVHNyTnYBgK19dwTIjRvqUi3m7PmYWDU2SibFLRhPmbLNq+LZPqvEhqn Ih0sE0KjhJqgOrZd6kj0Em5JqXHuVo2HFc/UgVu6Me/D4j1UieM5Koi/a0m/ezzoO7O7 Q2CdxNVZ9NnSS7n5/KOVUgG96yGSwCqxZlJvs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:message-id:from:cc:date:mime-version:subject :content-type; bh=6p3ld/mcpxMOcmrMJU08GOPLm91onlPDJIM1ACMXGyU=; b=I/uGX5QFOk6zb+9in4gaPGUkPLZ1nYJ+uxcHKvvXMfclid/K2xE4zBQEr0AYCYljzx U+Bg7Z6KRzqZYjHFg0ROXnrK8j/17ZrTEKlYymk283BHRDX/kdq97BjJBQzr0PM+AsIK mlUq0hbcMNJs6BiWybWjUm8gZHqXE7DAZJCex9E3NNg1FRYlyR6oFuGToAfSWj2BwkSJ rUjOwZHoqmrtDKnwjy9Fptdeax9ul1iQ58OqhQRUCKjRun5p3xU8xyy3g3ZStcjiAIrH qYq/vbYuTWWIpGX4Gumm634hlCKvYlNcTCDSvA3YF2nGOoFOwtZBoBHO67uX3VkKB8KD 6TBw== X-Gm-Message-State: ALoCoQmn3GU7cUBYUtjL9dFTBH2C33M6JrfqDUenE36e5tqaj4GfiUlSwisZ0xrOQWm5nULDdJ24 X-Received: by 10.194.5.35 with SMTP id p3mr1691128wjp.47.1379601789757; Thu, 19 Sep 2013 07:43:09 -0700 (PDT) Received: from Mac-mini.local (peirce.dave.cridland.net. [217.155.137.61]) by mx.google.com with ESMTPSA id ey2sm10292268wib.5.1969.12.31.16.00.00 (version=TLSv1.1 cipher=RC4-SHA bits=128/128); Thu, 19 Sep 2013 07:43:09 -0700 (PDT) To: Julian Reschke Message-Id: From: Dave Cridland Date: Thu, 19 Sep 2013 14:43:07 -0000 Mime-Version: 1.0 X-Mailer: Inky (TM) v2.0.523A.D3E0 ("Ink Different") Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Ian Hickson , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Feedback on multipart/form-data X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 14:43:17 -0000 Julian Reschke wrote: > On 2013-09-19 15:29, Dave Cridland wrote: >> Julian Reschke wrote: >>>> >>>> I know of RFC 2047 and RFC 2231, as well as unencoded UTF-8 and >>>> unencoded ISO-8859-1 (I think). >>> >>> No surprise here >> >> Yes, but one wonders if the unencoded UTF-8 actually does any harm at >> all in a 8bit/binary-safe protocol like HTTP. >> >> If most processors accept this - and I have no idea - it might even be >> useful to document. > > The risk here is that some UAs send ISO-8859-1 (or something based on the > locale), and servers parse based on the User-Agent. We have the same problem > with the Content-Disposition response header field. > > It's hard to change these kinds of workarounds in deployed code, and that's > why a new mechanism that can't be confused with the old syntax may work > better (thus RFC 5987). Yes, agreed, though UTF-8 is very difficult to accidentally mimic, from what I've found. I wonder if an EAI expert might suggest something here? Or if a top-level parameter or header might be useful to indicate UTF-8 header content? I can't help but feel it's a simpler construct to adhere to. Sent with [inky: ] From Ted.Lemon@nominum.com Thu Sep 19 08:31:25 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D40B21F9473; Thu, 19 Sep 2013 08:31:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.514 X-Spam-Level: X-Spam-Status: No, score=-106.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CrOr-FRnh2yW; Thu, 19 Sep 2013 08:31:19 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id 9E88821F9956; Thu, 19 Sep 2013 08:31:17 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKUjsYxdGNtJxA+l9gJNeysLx6RFZhj8o7@postini.com; Thu, 19 Sep 2013 08:31:17 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 142351B814F; Thu, 19 Sep 2013 08:31:17 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id B702B190068; Thu, 19 Sep 2013 08:31:15 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 19 Sep 2013 08:31:15 -0700 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1811\)) From: Ted Lemon In-Reply-To: <6.2.5.6.2.20130918225335.0d0e2478@elandnews.com> Date: Thu, 19 Sep 2013 11:31:11 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <6.2.5.6.2.20130914143222.0b9590f0@elandnews.com> <6.2.5.6.2.20130918225335.0d0e2478@elandnews.com> To: S Moonesamy X-Mailer: Apple Mail (2.1811) X-Originating-IP: [192.168.1.10] Cc: "" , Tim Chown , "iesg@ietf.org IESG" , draft-ietf-homenet-arch.all@tools.ietf.org, "homenet@ietf.org Group" Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-homenet-arch-10 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 15:31:25 -0000 Dave Cridland and I had a bit of a side conversation about this, which = started out with me being a bit shirty, but eventually produced some = useful output (I think) which I have included below (with Dave's = permission): On Sep 19, 2013, at 10:40 AM, Dave Cridland wrote: > Ted Lemon wrote: >> On Sep 19, 2013, at 10:06 AM, Dave Cridland = wrote: >>> I reiterate for you: If the IETF publishes this document as it = stands, it will look like, and be taken as, the official "Home = Networking Architecture for IPv6". Change the title (at least) to = avoid this. I even proposed alternate title texts. How much more = constructive would you like? >>=20 >> That is the goal of the document. And that is what the document is. = The problem with your suggestions is that they propose that we give = the document at title that does not describe what it is. Perhaps a = better title would be "Preliminary Home Network Architecture for IPv6." >=20 > That would work as well, I'm fine with that. >=20 > A note saying that at the time of publication, this topic was under = active work by the homenet WG would be good too, but IETF tradition = seems to be to avoid such things. >=20 >> But my criticism of your criticism about publishing the document = stands. The point of the document is for the IETF to say "this is what = we are trying to do." It's entirely appropriate for this information = to be available to the IETF as a whole, and not just to the homenet = working group. AFAIK the homenet working group has IETF consensus to = do this work, and there is no competing work. So it would IMHO be = wrong for the working group to propose an architecture and not publish = it=97to do so would be essentially to shortcut the IETF consensus = process. >=20 > There's been a few cases over the years where a document has been = published knowing full well it's not complete, or that there would be a = replacement within the lifetime of the working group, I know. But all = the ones I can immediately think of were cases where the document could = clearly provide value to people outside the IETF, and the document stood = on its own. >=20 > This document is, to my eyes, borderline for this. In point of fact, = you don't seem to be arguing it should be thrust in front of the noses = of every TP-Link and so on; you talk above about making it available to = "the IETF as a whole". I appreciate an RFC (and the publication process = surrounding it) acts as a useful mechanism for internal publicity and = awareness, of course, but I'd be more comfortable if this were handled = by an explicit note to ietf@ietf.org asking for cross-area review. >=20 > However, I'm certainly willing to stand in the rough here. >=20 > What I do suspect is that a number of external parties, including most = particularly consumer-grade ISPs, may well read this with interest, and = I think that kind of audience could use a few more hints (and less hints = to the contrary) of the actual status of the document. >=20 > Sent with [inky: ] Hm, okay, now I think we're getting somewhere. I think the reason the = IETF should publish this is that there is no clear "outside" to the = IETF=97everybody is welcome. So part of the goal of publishing it = ought to be to put a stake in the sand that CPE vendors will pay = attention to, and possibly criticize. That won't happen with a working = group document. But I think you are right that it would help to be = clearer about that. Do you mind if I forward this discussion (that is, = the contents of this particular email message) back to the original = distribution? I'm the one who took it private, but I don't want to = presume. From blueroofmusic@gmail.com Thu Sep 19 09:35:02 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8BF21F9635 for ; Thu, 19 Sep 2013 09:35:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jCzB7a692yPE for ; Thu, 19 Sep 2013 09:35:01 -0700 (PDT) Received: from mail-qa0-x234.google.com (mail-qa0-x234.google.com [IPv6:2607:f8b0:400d:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id 72C1121F960D for ; Thu, 19 Sep 2013 09:35:01 -0700 (PDT) Received: by mail-qa0-f52.google.com with SMTP id k4so3752249qaq.18 for ; Thu, 19 Sep 2013 09:35:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=oKpKxFpKL1NrSnZmgtR2grofeeKq6Edy9BUMgzmyQtA=; b=vdSGIJGWGk6X0FSLPR0bOJwgY3ZkZd8s7w7cPqqdvRRd+Abxcv2wWi6w379b6IWtdS NV6dz0TMEGDR7xDESr1LGuCYT3jTnv9P+Ndnab6gJr+ZMtMzNRd3LD2R0ZzhQJRb81YK 88a0/gMqw0jO4R93bbJ/JYAjTuSWT0qjSeBFMcv6yUvBkAXGdKIwvjz7m3hme0FI7v5t kXn8OEkhTJq548aNLo0NQ+uLs+5M5DydAe4Vn8Hq4q6NfCZFH0MX6oeiEhy0OrYvGMvX chlY1GNFvN4u1BGbPC+wFzuIoQ01WHbVPR0oXiaRoprURPSeGOxBVXxR+RnJ0PSwsXpv ZCRA== X-Received: by 10.49.30.227 with SMTP id v3mr5290016qeh.92.1379608500877; Thu, 19 Sep 2013 09:35:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.116.11 with HTTP; Thu, 19 Sep 2013 09:34:40 -0700 (PDT) From: Ira McDonald Date: Thu, 19 Sep 2013 12:34:40 -0400 Message-ID: To: "apps-discuss@ietf.org" , Ira McDonald , Pat Fleming Content-Type: multipart/alternative; boundary=047d7bd767ae9fbe5604e6bf22a2 Subject: [apps-discuss] Request for Apps Area review of LDAP Printer Schema (19 September 2013) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 16:35:02 -0000 --047d7bd767ae9fbe5604e6bf22a2 Content-Type: text/plain; charset=ISO-8859-1 Hello, The IEEE-ISTO PWG Internet Printing Protocol WG would like to request IETF Apps Area review of our updated LDAP Printer Schema (updates RFC 3712). http://www.ietf.org/internet-drafts/draft-mcdonald-ldap-printer-schema-05.txt Cheers, - Ira (co-chair of IEEE-ISTO PWG IPP WG and co-editor of this document) Ira McDonald (Musician / Software Architect) Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG IPP WG Co-Chair - TCG Trusted Mobility Solutions WG Chair - TCG Embedded Systems Hardcopy SG IETF Designated Expert - IPP & Printer MIB Blue Roof Music/High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto:blueroofmusic@gmail.com Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 --047d7bd767ae9fbe5604e6bf22a2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello,

The IEEE-ISTO= PWG Internet Printing Protocol WG would like to request
IETF Apps= Area review of our updated LDAP Printer Schema (updates
RFC 3712)= .

http://www.ietf.org/internet-drafts/dr= aft-mcdonald-ldap-printer-schema-05.txt

Cheers,
- Ira (co-chair of IEEE-ISTO PWG IPP WG and co-editor of this document)


Ira McDonald (Musi= cian / Software Architect)
Chair - Linux Foundation Open Printing WG
= Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG IPP= WG
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - TCG Embedded System= s Hardcopy SG
IETF Designated Expert - IPP & Printer MIB
Blue Roo= f Music/High North Inc
http://sites.google.= com/site/blueroofmusic
http://sites.google.com/site/highnorthincmailto:bluer= oofmusic@gmail.com
Winter=A0 579 Park Place=A0 Saline, MI=A0 48176=A0 734-944-0094
Summer= =A0 PO Box 221=A0 Grand Marais, MI 49839=A0 906-494-2434

--047d7bd767ae9fbe5604e6bf22a2-- From blueroofmusic@gmail.com Thu Sep 19 09:46:18 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D274121F9005; Thu, 19 Sep 2013 09:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iLk5Xebz4GBg; Thu, 19 Sep 2013 09:46:18 -0700 (PDT) Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id C15B221F8BFD; Thu, 19 Sep 2013 09:46:17 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id l13so5718848qcy.31 for ; Thu, 19 Sep 2013 09:46:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=m3c+4Z5cvGh6ur0lfKxVeAqbyVbl61QCtYwdAJkmgF0=; b=Qy9Jnydojlgi75D28bpv5KcbjEwXqPWbCdpyD27j/oYR9o2z/0lkLQTXNpUjK4Hh9o jFb7zkXnuq6KnXik0+wvf8l678okyJK6q1iIGx9WCeVYLaB8YACv+9ICTmyjWNKrSJd0 kDiEuF2AvEudTJlTcrKpCHrVRvF8se1Ks1Wh+R9CavQgegQzQTXqt/Wwfcy6Dlsi5CJj 9QF/I1ouMCzjIYJJUXCTPb/Dvmn48Cc8RcF1GZv1+jOORsdKjazbSCNbizkWZdcsyAgf 64xv1yx03fzcv/IlnFZzK3Z+uvS1xCUQTJiimaYZVJoPuzok5dwgcrTAQDcAY5o51dXz KEjw== X-Received: by 10.49.30.227 with SMTP id v3mr5398473qeh.92.1379609176881; Thu, 19 Sep 2013 09:46:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.116.11 with HTTP; Thu, 19 Sep 2013 09:45:56 -0700 (PDT) From: Ira McDonald Date: Thu, 19 Sep 2013 12:45:56 -0400 Message-ID: To: "apps-discuss@ietf.org" , "uri-review@ietf.org" , Ira McDonald , Michael R Sweet Content-Type: multipart/alternative; boundary=047d7bd767aeeac14504e6bf4a28 Subject: [apps-discuss] Request for Apps Area review of IPP over HTTPs and 'ipps' URI Scheme (19 September 2013) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 16:46:19 -0000 --047d7bd767aeeac14504e6bf4a28 Content-Type: text/plain; charset=ISO-8859-1 Hello, The IEEE-ISTO PWG Internet Printing Protocol WG would like to request IETF Apps Area review of our IPP over HTTPS Transport Binding and 'ipps' URI Scheme: http://www.ietf.org/internet-drafts/draft-mcdonald-ipps-uri-scheme-08.txt Please note that this document has been already been reviewed on the IETF URI Review mailing list (and revised accordingly). This document does NOT specify a new protocol, but merely a transport binding for IETF IPP/1.1 (RFC 2910/1911) that requires that TLS always be started *before* sending any HTTP application layer requests - as opposed to using the rarely implemented HTTP Upgrade (RFC 2817), a source of security problems in shipping IPP printers (essentially all network printers for the last decade). Cheers, - Ira (co-chair of IEEE-ISTO PWG IPP WG and co-editor of this document) Ira McDonald (Musician / Software Architect) Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG IPP WG Co-Chair - TCG Trusted Mobility Solutions WG Chair - TCG Embedded Systems Hardcopy SG IETF Designated Expert - IPP & Printer MIB Blue Roof Music/High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto:blueroofmusic@gmail.com Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 --047d7bd767aeeac14504e6bf4a28 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello,

The IEEE-ISTO= PWG Internet Printing Protocol WG would like to request
IETF Apps= Area review of our IPP over HTTPS Transport Binding and
'= ;ipps' URI Scheme:

http://www.ietf.org/internet-drafts/draft-mcdo= nald-ipps-uri-scheme-08.txt

Please note that this doc= ument has been already been reviewed on the
IETF URI Review mailing list (and revised accordingly).

This document does NOT specify a new protocol, but mer= ely a transport
binding for IETF IPP/1.1 (RFC 2910/1911) that= requires that TLS always
be started *before* sending any HTTP application layer requests - as
opposed to using the rarely implemented HTTP Upgrade (RFC 2817),
a source of security problems in shipping IPP printers (essenti= ally all
network printers for the last decade).

Cheers,
<= /div>- Ira (co-chair of IEEE-ISTO PWG IPP WG and co-editor of this document= )


Ira McDonald (Musician / Software Architect)
Chair - L= inux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG IPP= WG
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - TCG Embedded= Systems Hardcopy SG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites= .google.com/site/blueroofmusic
http://si= tes.google.com/site/highnorthinc
mailto:blueroo= fmusic@gmail.com
Winter=A0 579 Park Place=A0 Saline, MI=A0 48176=A0 = 734-944-0094
Summer=A0 PO Box 221=A0 Grand Marais, MI 49839=A0 906-494-2= 434

--047d7bd767aeeac14504e6bf4a28-- From sm@elandsys.com Thu Sep 19 12:34:01 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 505A621F8266 for ; Thu, 19 Sep 2013 12:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.547 X-Spam-Level: X-Spam-Status: No, score=-102.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SXYiol-5687N for ; Thu, 19 Sep 2013 12:34:00 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A96F21F9005 for ; Thu, 19 Sep 2013 12:34:00 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.144.105]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r8JJXgI2028399 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Sep 2013 12:33:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1379619237; bh=lXkLDpzojbRUJC7L+abjs5J2tim+xJJbGpY6isrBR1w=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Yl3KjRCwafpKABVxNwk8nKaM6SdMvji/V/kRknCjPgW0bJdq97iokl/IZtbW3LWRa XOlFsEKrSgbWKT4zMjKoNsldyLZMWgGgWg3BXL/s3Hc5aEesCQ8oVirCF7GOZi6AhM ySsVfwALF3cuK4hI9Fl4eL5L//ItnYO7wsW1vdhQ= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1379619237; i=@elandsys.com; bh=lXkLDpzojbRUJC7L+abjs5J2tim+xJJbGpY6isrBR1w=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=yUNi6xeHCe8WgjmJ0A09qwB4jPKSPUJMuvfGwOVTxNE2oLZ/RwvSSwal5w1ZnsKX1 9y7RgE4X3hBsNwTtEdvcYjOV5DM4zf3UFzYjCP3zCtX7ceXVYj9whknzTBW8RNgE/X h35+rE0X0H99NhjY9XM+XPxZRVrQGWwtHWBG2E3I= Message-Id: <6.2.5.6.2.20130919074156.0cd2d900@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 19 Sep 2013 10:36:24 -0700 To: Ted Lemon From: S Moonesamy In-Reply-To: References: <6.2.5.6.2.20130914143222.0b9590f0@elandnews.com> <6.2.5.6.2.20130918225335.0d0e2478@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org, Tim Chown , The IESG , draft-ietf-homenet-arch.all@tools.ietf.org, homenet@ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-homenet-arch-10 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 19:34:01 -0000 Hi Ted, At 05:55 19-09-2013, Ted Lemon wrote: >I think that you are interpreting this document=20 >to be something that it is not, and cannot yet=20 >be. What this document is is an architecture=20 >for the homenet working group=97a crib sheet that=20 >tells us what we are trying to accomplish. I=20 >don't think it's intended to be something that a=20 >random person who is not implementing home=20 >gateways would find useful. The working group=20 >is hoping that subsequent versions of this=20 >document will evolve over time, and I think it=20 >would be good for the working group to evolve=20 >the document into something that meets the goals that you've set out above. The problem may be that the document uses the=20 word "architecture". The sense I got after=20 reviewing the document was that it was more of a=20 requirements document instead of one about=20 architecture. I may not be implementing home=20 gateways but I would still read the document to=20 understand what assumptions I can make for my=20 IPv6 application. This entails understanding how=20 what the working group is trying to accomplish=20 affects my area of interest. If I look at the=20 document as one about requirements I'll conclude=20 that there isn't anything that has an impact on application technologies. I agree that it would be good for the working=20 group to evolve the document (see my previous=20 comments about stabilizing the document and=20 having a discussion about unresolved issues). It=20 might have been missed in my comments; what I am=20 saying is that the working group already has the=20 text it needs to get the work done; what's left=20 is some rearrangement and tightening of the text to get a crisp document. >However, I think that if the working group=20 >attempts to do that now, two things will=20 >happen. First, the working group won't actually=20 >get to the work it's supposed to be doing,=20 >because completing the architecture document=20 >will continue to be an all-consuming=20 >effort. Second, the document that is produced=20 >will be purely theoretical, not based on actual practice, and probably= useless. Agreed. That's why I emphasized the it "just works" in my=20 previous comment. I would leave it to the=20 working group to make the trade-offs so that the=20 document is about something that will actually=20 work in practice. I would assess the effort so=20 that it does not turn into an all-consuming one. >So I would like you to consider whether you can=20 >accept this restatement of the purpose of the=20 >document. Do you feel that this document=20 >cannot be of use until it meets the goals you've=20 >set out above, or does the different purpose=20 >I've expressed here make sense to you? If the=20 >latter, can you reconsider your review in light=20 >of this new stated purpose for the=20 >document? Is part of the problem that the=20 >goals of the document are poorly expressed in=20 >the document? Given the goals I've stated, do=20 >all of your comments still apply, or would you=20 >have responded differently to the document if=20 >you'd been evaluating it on the basis I'm proposing? I think that the document can be of use to the=20 working group. The document may not be that=20 clear to people from outside the area. I guess=20 that the problem may be, as mentioned above, the=20 goals of the document. If the document is a=20 (Informational) crib sheet I would rate it as good enough. It's unfair of me to submit such a review at this=20 late stage. I have not taken into consideration=20 the amount of effort involved in getting the=20 draft this far. I'll defer to the document shepherd (or you). Regards, S. Moonesamy =20 From sm@elandsys.com Thu Sep 19 12:34:58 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 646CB21F963F for ; Thu, 19 Sep 2013 12:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.548 X-Spam-Level: X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fsTTA32T6eja for ; Thu, 19 Sep 2013 12:34:57 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id A338D21F9633 for ; Thu, 19 Sep 2013 12:34:57 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.144.105]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r8JJYgas010744 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Sep 2013 12:34:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1379619296; bh=b4esdBTh4Gjp4TOMprATtiPOJNFmjNDUlNxUly6ddLM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Xqz0ElGBUKDYLmC/+VfWpuUBnUefVYco+YYXkp1dLpcmVhn3MviM3nHTV4fzZIbD6 tkUqS7C1iXZFJkAGMSQ6iTS9BIhQtsqgxtnDhGP93gDWDOylQRh3rNzSpRLpOBhHFf EAn9l9XL7TIPwlBRLujKk0wiF8pivQnbF8RnqQWo= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1379619296; i=@elandsys.com; bh=b4esdBTh4Gjp4TOMprATtiPOJNFmjNDUlNxUly6ddLM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=YYzs0njqSZmJJxrLN1FwewV10x9N52a1Skw6YM3ZRV94JlXEhr5oJjQVXVMFp1doS uKyFrhUkQuGjOqnn1qPBra2onbKzMne1P9QZMmqVdcCbVOPDbAm4j3k19MprLtMqCi 2Ovl6TLzHOCcJTysIV0lSqthBoDTIgvxEthKjYqI= Message-Id: <6.2.5.6.2.20130919120656.0e8ce8a8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 19 Sep 2013 12:34:38 -0700 To: Ted Lemon From: S Moonesamy In-Reply-To: References: <6.2.5.6.2.20130914143222.0b9590f0@elandnews.com> <6.2.5.6.2.20130918225335.0d0e2478@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: apps-discuss@ietf.org, Tim Chown , iesg@ietf.org, draft-ietf-homenet-arch.all@tools.ietf.org, homenet@ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-homenet-arch-10 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 19:34:58 -0000 Hi Ted, At 08:31 19-09-2013, Ted Lemon wrote: >On Sep 19, 2013, at 10:40 AM, Dave Cridland wrote: > > > Ted Lemon wrote: > >> On Sep 19, 2013, at 10:06 AM, Dave Cridland wrote: > >>> I reiterate for you: If the IETF publishes=20 > this document as it stands, it will look=20 > like, and be taken as, the official "Home=20 > Networking Architecture for IPv6". Change=20 > the title (at least) to avoid this. I=20 > even proposed alternate title texts. How=20 > much more constructive would you like? > >> > >> That is the goal of the document. And that=20 > is what the document is. The problem with=20 > your suggestions is that they propose that we=20 > give the document at title that does not=20 > describe what it is. Perhaps a better title=20 > would be "Preliminary Home Network Architecture for IPv6." I like Dave's idea of having a different title=20 for the draft. The problem, to state it in=20 simple terms, was "architecture". The problem=20 could be solved by using a different term, e.g.=20 framework. I would avoid "preliminary architecture" (see comment below). > > There's been a few cases over the years where=20 > a document has been published knowing full well=20 > it's not complete, or that there would be a=20 > replacement within the lifetime of the working=20 > group, I know. But all the ones I can=20 > immediately think of were cases where the=20 > document could clearly provide value to people=20 > outside the IETF, and the document stood on its own. I am not keen on the idea of committing to do future work on a replacement. > > This document is, to my eyes, borderline for=20 > this. In point of fact, you don't seem to be=20 > arguing it should be thrust in front of the=20 > noses of every TP-Link and so on; you talk=20 > above about making it available to "the IETF as=20 > a whole". I appreciate an RFC (and the=20 > publication process surrounding it) acts as a=20 > useful mechanism for internal publicity and=20 > awareness, of course, but I'd be more=20 > comfortable if this were handled by an explicit=20 > note to ietf@ietf.org asking for cross-area review. Yes. >Hm, okay, now I think we're getting=20 >somewhere. I think the reason the IETF should=20 >publish this is that there is no clear "outside"=20 >to the IETF=97everybody is welcome. So part of=20 >the goal of publishing it ought to be to put a=20 >stake in the sand that CPE vendors will pay=20 >attention to, and possibly criticize. That=20 >won't happen with a working group=20 >document. But I think you are right that it=20 >would help to be clearer about that. Do I understand the goal and I am okay with it. Regards, S. Moonesamy =20 From Ted.Lemon@nominum.com Thu Sep 19 12:43:28 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA41C21F9005; Thu, 19 Sep 2013 12:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.515 X-Spam-Level: X-Spam-Status: No, score=-106.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SSwO3G87mDMp; Thu, 19 Sep 2013 12:43:13 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id 05B4121F8FF8; Thu, 19 Sep 2013 12:43:13 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKUjtT0A0ieR5GxvVwZkEAf2sGZ/NLzHGL@postini.com; Thu, 19 Sep 2013 12:43:13 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id ED0FA1B82C3; Thu, 19 Sep 2013 12:43:11 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 9CFE0190068; Thu, 19 Sep 2013 12:43:10 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 19 Sep 2013 12:43:10 -0700 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1811\)) From: Ted Lemon In-Reply-To: <6.2.5.6.2.20130919074156.0cd2d900@elandnews.com> Date: Thu, 19 Sep 2013 15:43:07 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <3105F809-7E03-41D9-A634-DE32446FB19B@nominum.com> References: <6.2.5.6.2.20130914143222.0b9590f0@elandnews.com> <6.2.5.6.2.20130918225335.0d0e2478@elandnews.com> <6.2.5.6.2.20130919074156.0cd2d900@elandnews.com> To: S Moonesamy X-Mailer: Apple Mail (2.1811) X-Originating-IP: [192.168.1.10] Cc: "" , Tim Chown , The IESG , draft-ietf-homenet-arch.all@tools.ietf.org, "homenet@ietf.org Group" Subject: Re: [apps-discuss] [homenet] APPSDIR review of draft-ietf-homenet-arch-10 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 19:43:28 -0000 On Sep 19, 2013, at 1:36 PM, S Moonesamy wrote: > I agree that it would be good for the working group to evolve the = document (see my previous comments about stabilizing the document and = having a discussion about unresolved issues). It might have been missed = in my comments; what I am saying is that the working group already has = the text it needs to get the work done; what's left is some = rearrangement and tightening of the text to get a crisp document. Possibly Tim got that from your comments=97I didn't. I should probably = let Tim respond rather than continuing to muddy the waters. From brian.e.carpenter@gmail.com Thu Sep 19 13:59:11 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD2FF21F83E2; Thu, 19 Sep 2013 13:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dn3RIKyGTNjA; Thu, 19 Sep 2013 13:59:10 -0700 (PDT) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id B2CC821F8235; Thu, 19 Sep 2013 13:59:10 -0700 (PDT) Received: by mail-pd0-f177.google.com with SMTP id y10so8796351pdj.8 for ; Thu, 19 Sep 2013 13:59:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=eGghMd6NN+XvWqNVRMF+eLeuSUIJNochQjUABAlMYw4=; b=bc+TfQAEfEnnX7GLyfARUaUhZM9JrV/SmxUA5a08jU7kpOBXCyWJhE1oJEj4AiKaO9 sa0e2I0dyuoGPFXcZm6bv/NlDeSuX3zeyJGOiKeyce5wXKNanWErIYUmm1VjQyF7pLft +AZu6ufib5vwWkHq3lBQ++GA3W4sxTjSmJRu6wEsM6c/f3CVsf1GCw5XJK6aQsBHKVcg JAkbrjMXvgCDWXEv9iv7DIMdgZjSjlII1ZbsYz0HJwrZhp0yepJ9O8PZvWfiuuj3q9Q3 oY3389UcWmxcCHZurzma4OcJgEQZGl57p/yALAJIpur4kRQSZBdcMtAmMsfsWjawVCSG M9vw== X-Received: by 10.68.175.67 with SMTP id by3mr4080170pbc.114.1379624344648; Thu, 19 Sep 2013 13:59:04 -0700 (PDT) Received: from [192.168.178.20] (171.201.69.111.dynamic.snap.net.nz. [111.69.201.171]) by mx.google.com with ESMTPSA id j9sm14261757paj.18.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 19 Sep 2013 13:59:03 -0700 (PDT) Message-ID: <523B659D.2000408@gmail.com> Date: Fri, 20 Sep 2013 08:59:09 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ted Lemon References: <6.2.5.6.2.20130914143222.0b9590f0@elandnews.com> <6.2.5.6.2.20130918225335.0d0e2478@elandnews.com> <6.2.5.6.2.20130919074156.0cd2d900@elandnews.com> <3105F809-7E03-41D9-A634-DE32446FB19B@nominum.com> In-Reply-To: <3105F809-7E03-41D9-A634-DE32446FB19B@nominum.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "" , S Moonesamy , Tim Chown , The IESG , draft-ietf-homenet-arch.all@tools.ietf.org, "homenet@ietf.org Group" Subject: Re: [apps-discuss] [homenet] APPSDIR review of draft-ietf-homenet-arch-10 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 20:59:12 -0000 On 20/09/2013 07:43, Ted Lemon wrote: > On Sep 19, 2013, at 1:36 PM, S Moonesamy wrote: >> I agree that it would be good for the working group to evolve the docu= ment (see my previous comments about stabilizing the document and having = a discussion about unresolved issues). It might have been missed in my c= omments; what I am saying is that the working group already has the text = it needs to get the work done; what's left is some rearrangement and tigh= tening of the text to get a crisp document. >=20 > Possibly Tim got that from your comments=E2=80=94I didn't. I should p= robably let Tim respond rather than continuing to muddy the waters. Reading this thread, I perceive big differences in understandings of the scope of the document (and of the WG). IMHO the document (and the WG) are about making the networking layer (layer 3), and routing, work consistently in zero-management home networks. That inevitably spills over into DNS. The document (and the WG) are not about making the application eco-system work consistently. That is completely absent from the WG charter; after all, it's an Internet Area WG. I believe the draft meets the charter goals. It's certainly a snapshot, and should be labelled as such, but it isn't intended to stray much outside layer 3, and shouldn't. Whether work is need in the application eco-system for home networks is a separate discussion. Brian From presnick@qti.qualcomm.com Thu Sep 19 14:33:29 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1D4421F847C; Thu, 19 Sep 2013 14:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.436 X-Spam-Level: X-Spam-Status: No, score=-106.436 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4fswCsedWTeq; Thu, 19 Sep 2013 14:33:25 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 821A321F8417; Thu, 19 Sep 2013 14:33:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1379626405; x=1411162405; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Fh0OJk7xwYA4DP34F3mLGxQL1+r6muPqwIeZuDlODgw=; b=MNV3JxMT9/fEPFgnMhfKBrDwOKaiVwgYV7hlAD20j9UZsP37g4OiZORL Jomstu0m+l5/TLeg9CJmeJvRVJxDC2MqrSKrOTg9Hy5W2sRkIkXjccGYR 3uBwHzn00fr4W+B+hvhCkuwwv/HQQkUeahV+cj2+MAqbgRNZ5yDUCE7js s=; X-IronPort-AV: E=McAfee;i="5400,1158,7203"; a="75372616" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine01.qualcomm.com with ESMTP; 19 Sep 2013 14:33:25 -0700 X-IronPort-AV: E=McAfee;i="5400,1158,7203"; a="604628342" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 19 Sep 2013 14:33:24 -0700 Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by nasanexhc04.na.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.3.146.2; Thu, 19 Sep 2013 14:33:24 -0700 Received: from resnick2.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.2) with Microsoft SMTP Server (TLS) id 14.3.146.2; Thu, 19 Sep 2013 14:33:24 -0700 Message-ID: <523B6DAD.5030308@qti.qualcomm.com> Date: Thu, 19 Sep 2013 16:33:33 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Brian E Carpenter References: <6.2.5.6.2.20130914143222.0b9590f0@elandnews.com> <6.2.5.6.2.20130918225335.0d0e2478@elandnews.com> <6.2.5.6.2.20130919074156.0cd2d900@elandnews.com> <3105F809-7E03-41D9-A634-DE32446FB19B@nominum.com> <523B659D.2000408@gmail.com> In-Reply-To: <523B659D.2000408@gmail.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Cc: "" , S Moonesamy , Tim Chown , The IESG , draft-ietf-homenet-arch.all@tools.ietf.org, "homenet@ietf.org Group" , Ted Lemon Subject: Re: [apps-discuss] [homenet] APPSDIR review of draft-ietf-homenet-arch-10 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 21:33:30 -0000 Understand that I still haven't done my review of the document, and that I was the one who pushed for an APPSDIR review: On 9/19/13 3:59 PM, Brian E Carpenter wrote: > Reading this thread, I perceive big differences in understandings > of the scope of the document (and of the WG). > > IMHO the document (and the WG) are about making the networking layer > (layer 3), and routing, work consistently in zero-management home > networks. That inevitably spills over into DNS. > > The document (and the WG) are not about making the application > eco-system work consistently. That is completely absent from the WG > charter; after all, it's an Internet Area WG. > > I believe the draft meets the charter goals. It's certainly a snapshot, > and should be labelled as such, but it isn't intended to stray much > outside layer 3, and shouldn't. > > Whether work is need in the application eco-system for home networks > is a separate discussion. > Let's be fair: The charter talks about tackling requirements in name resolution *and* service discovery. Once you get into those areas, but especially the latter, you're dealing with the needs of applications. Most of the work in this WG requires INT area expertise, but APP issues are inevitably going to pop up. I think to say that the draft shouldn't stray much outside of layer 3 is a bit naive. But since we're being fair: I've tried to keep an eye on things going on in homenet and to attend homenet meetings myself, and I've tried to encourage other applications folks to do so, and I've failed miserably on both counts. In large part, the former has been due to time and scheduling issues, and for the latter I clearly was unable to make the case to applications folks that this work *did* require cross-area review. What else is new in the IETF lately? It sounds like we have a path forward for this document. But I've always been wary about INT groups doing things for applications without serious APP area input. (Lists of bad things available upon request.) Blame all around, including myself, for not making that situation better. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From tjc@ecs.soton.ac.uk Wed Sep 18 16:13:37 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C159211E8166; Wed, 18 Sep 2013 16:13:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_20=-0.74] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oQG5k9j-9sAj; Wed, 18 Sep 2013 16:13:36 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 05F8111E815B; Wed, 18 Sep 2013 16:13:34 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r8INCW4W009989; Thu, 19 Sep 2013 00:12:32 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk r8INCW4W009989 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1379545952; bh=gDFU8YfpwfLdNHC2n3L0ra/tPPs=; h=Subject:Mime-Version:From:In-Reply-To:Date:Cc:References:To; b=C2qZ6fGPRkC90ZG0TyPOnm/l+2fpAMytDjSU1NS81cxsHjogS8x8L2IT6y3PU0Rnh WSxLfBrAQMFpRcNfTOKSdD62V4WOVdov+2n16mYvYPROsGi23flg7PB31NrTGyCSSm JAmoq4KZ3X42qCnFsnEkykiJAvMu8PweTTz0bC94= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id p8I0CV0544514586bd ret-id none; Thu, 19 Sep 2013 00:12:32 +0100 Received: from [192.168.1.110] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r8INAoES007964 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 19 Sep 2013 00:10:57 +0100 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: text/plain; charset=windows-1252 From: Tim Chown In-Reply-To: <6.2.5.6.2.20130914143222.0b9590f0@elandnews.com> Date: Thu, 19 Sep 2013 00:10:50 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <6.2.5.6.2.20130914143222.0b9590f0@elandnews.com> To: S Moonesamy X-Mailer: Apple Mail (2.1508) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=p8I0CV054451458600; tid=p8I0CV0544514586bd; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=5:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: r8INCW4W009989 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk X-Mailman-Approved-At: Thu, 19 Sep 2013 14:53:31 -0700 Cc: homenet@ietf.org, draft-ietf-homenet-arch.all@tools.ietf.org, apps-discuss@ietf.org, iesg@ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-homenet-arch-10 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 18 Sep 2013 23:13:37 -0000 Hi, Some comments in line. On 15 Sep 2013, at 01:06, S Moonesamy wrote: > I have been selected as the Applications Area Directorate reviewer for = this draft (for background on APPSDIR, please see = http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate = ). >=20 > Please resolve these comments along with any other Last Call comments = you may receive. Please wait for direction from your document shepherd = or AD before posting a new version of the draft. >=20 > Document: draft-ietf-homenet-arch-10 > Title: Home Networking Architecture for IPv6 > Reviewer: S. Moonesamy > Review Date: September 14, 2013 > IETF Last Call Date: August 8, 2013 > IESG Evaluation: September 26, 2013 >=20 > Summary: This draft is not ready for publication as an Informational = RFC. >=20 > The document defines a general architecture for IPv6-based home = networking, describing the associated principles, considerations and = requirements. It draws parallels with IPv4 scenarios to explain the = proposed architecture to the reader. There is an assumption that the = IPv6 home network runs as an IPv6-only or dual-stack network. >=20 > I am not sure whether application developers will be able to = understand the document as it is written from a routing perspective. I = found the document confusing. After reading the document I am left with = a sense that it tried to solve the problems the working group = participants could think about instead of taking an architectural view = of IPv6 home networking. The document was produced with five general areas in mind, which was the = brief agreed by the chairs after the original interim meeting in = Philiadelphia. Those are routing, prefix configuration, name resolution, = service discovery, and network security. There is thus no specific = consideration of applications. That said, such guidance would be very = useful, and it would be quite feasible to draft a separate = application-oriented/perspective text, including expertise from apps = area - would that address your concern? > Major issues: >=20 > I am listing these issues as major mainly for the attention of the = Applications Area Directors. >=20 > According to RFC 1958: >=20 > "4.2 A single naming structure should be used." >=20 > This document introduces a "Locally Qualified Domain Name" in Section = 1.1. Section 3.7.3 refers to it as a "Unique Locally Qualified Domain = Name". There is also a mention of "Ambiguous Local Qualified Domain = Name space" in that section. There is already a split namespace for existing home networks. Devices = may live under .local (for mDNS/DNS-SD), which has meaning on the subnet = in question (though some emerging vendor products are proxying this = through routers - hence the desire to form a dnssdext WG to look at that = topic), and/or may use a globally unique name space. The issue in future home networks is how naming and SD works across a = routed, multi-link home. What is the equivalent "local" name space, that = can be used whether the home is externally connected or not, providing = independent operation where necessary. That section discusses how that "local" name space might look, and is = the result of considerable discussion in the homenet WG. Do you have something specific to propose to say instead? > The document mentions ".sitelocal (or an appropriate name reserved for = the purpose)". Quoting RFC 6761: >=20 > "Are writers of application software expected to make their > software recognize these names as special and treat them > differently? In what way?" It's interesting that the dnssdext BoF pushed back on tackling name = space issues, and focusing on service discovery, should that WG be = formed. But there has been plenty of discussion in the BoF(s) and (old = name) mdnsext list about the issues. For example how names used in = "local" service discovery protocols might be published in a global DNS = name space. One of the three proposed deliverables of dnssdext would be = to identify and document those issues as the SD work progresses. Input = from application developers would be welcome. > In Section 3.7.7: >=20 > "Similarly the search domains for local FQDN-derived zones should > be included." >=20 > Why is the document recommending search domains? The point here is that hosts in a self-configuring routed home network = need to learn the DNS resolvers to use. How for example the leaf router = determines which DNS resolvers to put into RAs. There has been = discussion on homenet and elsewhere about how that could be done, = whether it might (for example) be passed in the routing protocol (e.g. = OSPF could support it) or whether a separate protocol is required. The = search domain sentence is an example of other configuration information. = It could be omited if prefered. > Minor issues: >=20 > In Section 2.6: >=20 > "It is likely that IPv6-only networking will be deployed first in > 'greenfield' homenet scenarios, or perhaps as one element of an > otherwise dual-stack network." >=20 > Given that this is an architectural document intended for a wide = audience it would be clearer to the non-English reader to have a = description instead of "greenfield". OK. > In Section 3.2.3: >=20 > "A general recommendation is to follow the same topology for IPv6 as > is used for IPv4, but not to use NAT." >=20 > As a non-actionable comment, there are benefits to such an approach, = i.e. IPv6 is like IPv4. The drawback is that it may encourage an IPv4 = mindset. This was a general principle agreed early on in the WG, and appears to = have wide consensus. The sentence is in the context of a dual-stack = homenet. > "In some cases IPv4 home networks may feature cascaded NATs. End > users are frequently unaware that they have created such networks > as 'home routers' and 'home switches' are frequently confused." >=20 > I don't see the relevance of the second sentence in a document about = architecture. The document has a tendency to get into IPv4 NAT details = (first sentence). That is odd for a document about IPv6 home = networking. The second sentence stems from the 'support arbitrary topologies' = principle. Do you have alternative text, or would you prefer it was = omited? I think we'd need to have words there to suggest that the = homenet user is most likely unaware of the creation of internal NAT, be = that from introducing an IPv4 internal router, or by running a VM or = something similar. So long as it "just works". > In Section 3.4.1: >=20 > 'One particular situation that must be avoided is having an end site > feel compelled to use IPv6-to-IPv6 Network Address Translation or > other burdensome address conservation techniques because it could = not > get sufficient address space."' >=20 > The document references RFC 6177 for address assignments to end sites. = It then goes into the details of IPv6 prefix length and highlights that = NPTv6 must be avoided. There is very strong consensus in homenet against introducing NPTv6. = Whether that affects what ISPs do is of course another question. > "There are many problems that would arise from a homenet not being > offered a sufficient prefix size for its needs." >=20 > The above argues that not having an acceptable prefix side for the = homenet can be a problem. It would be easier to start with an = assumption that the IPv6 homenet will have sufficient address space. Certainly. The above text stems from some ISPs already only offering a = /64. Currently some offer /48, while many offer a /56. But it's too = early still to make any firm comment on common practices. > "For a typical IPv6 homenet, it is not recommended that an ISP offer > less than a /60 prefix, and it is highly preferable that the ISP > offers at least a /56." >=20 > =46rom RFC 6177: >=20 > "RFC 3177 [RFC3177] called for a default end site IPv6 assignment > size of /48. Subsequently, the Regional Internet Registries (RIRs) > developed and adopted IPv6 address assignment and allocation = policies > consistent with the recommendations of RFC 3177" >=20 > What follows after that is a mention of policies no longer consistent = with RFC 3177. This document seems to be taking the same approach as = RFC 3177 which has to be updated because of policy issues. Well, RFC 3177 is now considered obsolete. There is strong consensus in = the homenet WG that the text from RFC 6177 is appropriate, and I have = spoken to a number of ISPs about it, who seem to agree. So emphasising = what RFC 6177 says today seems a reasonable approach. Of course, some countries may introduce laws or regulations that make = RFC 6177 hard to follow. But that shouldn't affect our document on = architectural principles, should it? > "There may be cases where local law means some ISPs are required to > change IPv6 prefixes (current IPv4 addresses) for privacy reasons = for > their customers." My understanding is that this was added as a result of German law.=20 > In Section 3.6: >=20 > "The most notable difference to the IPv4 operational model is the > removal of NAT" >=20 > The following is under a "Security" heading. I assumed that the = stance of the IETF was that NAT does not provide security. It provides some security. Is there specific text in 3.6 or one of its = subsections that's problematic for you? > In Section 3.7.3: >=20 > "Such name spaces may be acquired by the user or provided/generated > by their ISP or an alternative cloud-based service." >=20 > What is a cloud-based service and what name space does it provide? That could instead say "third party service" - would that be better? > "Also, with the introduction of new 'dotless' top level domains, = there > is also potential for ambiguity between, for example, a local host > called 'computer' and (if it is registered) a .computer gTLD." >=20 > The IAB has issued a statement about "dotless domain considered as = harmful" ( = http://www.iab.org/2013/07/10/iab-statement-dotless-domains-considered-har= mful/ ). I don't understand why this document discusses about the = introduction of dotless domains. I don't understand why it would not mention the issue. The IAB statement = post-dated the (brief) text in this draft. Would a reference to the IAB = statement address your point? > In Section 3.7.8: >=20 > "It is likely that some devices which have registered names within = the > homenet Internet name space and that are mobile will attach to the > Internet at other locations and acquire an IP address at those > locations." >=20 > What is the homenet Internet name space? There is an IAB technical = comment about a unique DNS Root (RFC 2826). The wording is clumsy here I agree. The point is that some devices in = the homenet may be registered under the/a global name space associated = with the homenet, but where mobile may acquire a different IP address to = that registered to that name in their home network. Hence the next = sentence and next paragraph. We can rewrite that text to be clearer. > Nits: >=20 > I suggest fixing "This text" in the Abstract. This document? Or=85? > This review does not include other editorial nits. >=20 > I am including the review from Dave Cridland for APPSDIR: >=20 > =A71 para 5: Apparently home networks are what they are. I admit to = being easily baffled, but I cannot understand how they might not be what = they are. Perhaps: >=20 > "We assume that the IPv4 network architecture currently deployed in = home networks can not be modified by new recommendations." That's fine by me. > In general, =A71 uses a lot of the terms of art from =A71.1, which I = found quite hard to deal with - perhaps some of the paragraphs of =A71 = could be moved below =A71.1, either as a =A71.2 or something else. Ah yes, we could do that. > =A71.1 >=20 > "CER" I understand as "the router"; that is, it's the pre-existing = DSL/Cable router that's in the majority of home networks now, right? The = term used elsewhere in the document is "modern home router", which seems = obvious enough, but isn't present in the definition. Yes. Though I can only find one instance of "modern home router". But = that can certainly be changed to CER. > I've read through the rest of the document, it looks good to me = (though some parts I've only skimmed). >=20 > =A74 seems less of a conclusion and more of a summary; I'm not really = sure what it's there for. What I was hoping to find here was a bullet = point list of new work needed. Instead, potential new work items are = scattered throughout the text, making them hard to locate and enumerate. Yes, it could be improved. An AD I think asked if there should be a = summary of recommendations/principles, perhaps as an appendix. In an = earlier version we had these enumerated in each section, but that was = undone at the request of the chairs, because (I think) they felt it = broke the flow of the text. Do you think an appendix summary (with = pointers back to the sections they are taken from) is desirable as a = form of "checklist" for readers? Tim >=20 > Regards, > S. Moonesamy >=20 From internet-drafts@ietf.org Fri Sep 20 05:20:06 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78D3D21F943C; Fri, 20 Sep 2013 05:20:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fgmK5iDnQAk3; Fri, 20 Sep 2013 05:20:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D3B9121F95DD; Fri, 20 Sep 2013 05:20:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.71.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130920122004.18281.86697.idtracker@ietfa.amsl.com> Date: Fri, 20 Sep 2013 05:20:04 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-masinter-multipart-form-data-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 12:20:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Working G= roup of the IETF. Title : Returning Values from Forms: multipart/form-data Author(s) : Larry Masinter Filename : draft-masinter-multipart-form-data-01.txt Pages : 9 Date : 2013-09-20 Abstract: This specification defines an Internet Media Type, multipart/form- data, which can be used by a wide variety of applications and transported by a wide variety of protocols as a way of returning a set of values as the result of a user filling out a form. It replaces RFC 2388. NOTE The Currently, XML source for this Internet Draft may be found in [1], as well as an issue tracker. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-masinter-multipart-form-data There's also a htmlized version available at: http://tools.ietf.org/html/draft-masinter-multipart-form-data-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-masinter-multipart-form-data-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 julian.reschke@gmx.de Fri Sep 20 05:40:50 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1860B21F960A for ; Fri, 20 Sep 2013 05:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.27 X-Spam-Level: X-Spam-Status: No, score=-104.27 tagged_above=-999 required=5 tests=[AWL=-1.671, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IQHb7vys8EyW for ; Fri, 20 Sep 2013 05:40:45 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id AB1FD21F8BD8 for ; Fri, 20 Sep 2013 05:40:37 -0700 (PDT) Received: from [192.168.1.102] ([217.91.35.233]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0Lz0aC-1W0iXa2nTs-014A1V for ; Fri, 20 Sep 2013 14:40:34 +0200 Message-ID: <523C4240.8050409@gmx.de> Date: Fri, 20 Sep 2013 14:40:32 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20130920122004.18281.86697.idtracker@ietfa.amsl.com> In-Reply-To: <20130920122004.18281.86697.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:Arr5XK5E5wcFf+UOOsc+V6nEh2/LQRES+GvanTiOU7Wu3feleCk gapShVfAdQGeZZoa2vQNs+xx2NDiG8StZYlPkxm2WAkR2fhyqhM0zzTady2czZM7U7VGaVu EvsYJRpZmmfzHJzmtdkn2QJkcmUBLseQAJC3nO6yCIbsuv5LuXgy7Zy9qFDB2O+oo672Huf pkjnF2Vdoa2iCvhPBeqRQ== Subject: [apps-discuss] _charset_ parameter, was I-D Action: draft-masinter-multipart-form-data-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 12:40:50 -0000 Hi there, claims: 2.6. The _charset_ field Forms have the convention that the value of a form entry with entry name "_charset_" and type "hidden" is automatically set to the name of the form-charset. In this case, the value of the default charset of each text/plain part without a charset parameter is the supplied value. I wasn't aware if the auto-filling feature but it appears to be true. I supposed we should a reference to a spec where that is defined (HTML5 I guess?) Best regards, Julian From salvatore.loreto@ericsson.com Fri Sep 20 06:57:40 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52E7521F9A3D for ; Fri, 20 Sep 2013 06:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.662 X-Spam-Level: X-Spam-Status: No, score=-104.662 tagged_above=-999 required=5 tests=[AWL=1.587, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZeLIJbiSG5fN for ; Fri, 20 Sep 2013 06:57:34 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 450DD21F9A40 for ; Fri, 20 Sep 2013 06:57:33 -0700 (PDT) X-AuditID: c1b4fb30-b7f9a8e000005620-75-523c544c4663 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 61.42.22048.C445C325; Fri, 20 Sep 2013 15:57:33 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.183.150) by smtp.internal.ericsson.com (153.88.183.41) with Microsoft SMTP Server id 14.2.328.9; Fri, 20 Sep 2013 15:57:32 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 5D6CF1102E6 for ; Fri, 20 Sep 2013 16:57:32 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 3DA0E561BA for ; Fri, 20 Sep 2013 16:57:25 +0300 (EEST) Received: from n94.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id DFECD561B9 for ; Fri, 20 Sep 2013 16:57:24 +0300 (EEST) Message-ID: <523C544B.7020901@ericsson.com> Date: Fri, 20 Sep 2013 16:57:31 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: References: <522E277D.90205@stpeter.im> In-Reply-To: <522E277D.90205@stpeter.im> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLLMWRmVeSWpSXmKPExsUyM+Jvja5viE2Qwd5DzBarX65gc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxtlrcgW32Sq2Xj7A3MC4jrWLkYNDQsBE4uQ1ry5GTiBTTOLC vfVsXYxcHEIChxklXk/4xgrhbGCUeDjnGwtIlZDATUaJt6cdIRKnGCWWb5kHlTjEKPHoYi3I VF4BbYln7/VBwiwCqhL/5lxjBLHZBMwknj/cwgxiiwokSzRdvg/WyisgKHFy5hMwW0RAWqLl 0E2wemEBD4mvWw4zQozPkWjv62EFsTkFNCR+zm1lArGZBWwlLsy5zgJhy0tsfzuHGeIbNYmr 5zYxQ/RqSfSe7WSawCgyC8m6WUjaZyFpX8DIvIqRPTcxMye93HwTIzCID275bbCDcdN9sUOM 0hwsSuK8m/XOBAoJpCeWpGanphakFsUXleakFh9iZOLglGpgrDi6/HxS5MmnSw9IqN9d0hrk yeZ8+NOzyQEvH1RUsE7vdeWsv/nFY3LPv9+397lq6HnFvOB9EWZyNurhybAzy2f0W6RfPHhz qfeWm4wqpfGm75uqbnk3eMd7LFsZdi5379bV99QfJn/WWT/V7Axr7OksyR3P9ix0VD5u5bNo /5rL6669OhKx87gSS3FGoqEWc1FxIgDmDtyqMAIAAA== Subject: Re: [apps-discuss] Call for APPSAWG topics for November meeting X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 13:57:40 -0000 On 9/9/13 10:54 PM, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 9/9/13 1:01 PM, Murray S. Kucherawy wrote: >> Colleagues, >> >> It's that time again. If you would like to make a presentation to >> APPSAWG or to the APP Area General Meeting when we convene in >> November, or if you would like to request that someone cover a >> specific topic, please email appsawg-chairs@tools.ietf.org > Perhaps it would make sense to have a discussion about core aspects of > application security, instead of the usual smorgasbord of topics. (as individual) I like this proposal, and I think it would an interesting session if we manage to dedicate at least the majority of the time to this argument with some short presentation, time for discussion /Salvatore -- Salvatore Loreto, PhD www.sloreto.com From sm@elandsys.com Fri Sep 20 07:52:15 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7320E21F9A7E for ; Fri, 20 Sep 2013 07:52:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oz+udt2lA7Me for ; Fri, 20 Sep 2013 07:52:14 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id DE95921F9649 for ; Fri, 20 Sep 2013 07:52:14 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.153.197]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r8KEptlk021529 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Sep 2013 07:52:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1379688728; bh=q5lsXRpMPhj3PZeJrGd1OyfG6LtCplgYDKlyXQSNzcc=; h=Date:To:From:Subject:Cc; b=JbFPHtjZDtSXIPFOJgXjW9f0QsbQ/Y3PmQsFBY71qLIrdazqkAZzEtqM7knemYXec HTNV96KAMWDd2/yREjwU3P45MDgdF7t5dVrqldPks75aKok6lE+bQby4PjBZT0Vp+i KsXXbva5A9FfTO2iUDO8uP0N7o5ZyW3uLC87PD2Y= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1379688728; i=@elandsys.com; bh=q5lsXRpMPhj3PZeJrGd1OyfG6LtCplgYDKlyXQSNzcc=; h=Date:To:From:Subject:Cc; b=gBOcAs5Dh/wJC/iTlHXxTbtepByVOisayR0l4Q9ui/n4XyoGglfae4LHKMILyIScG h2vdeVbwoxyfZ1aB8OjrtYB6BTTI/FHGrhzNG3vn905eoBEd8Fggrf/fRPQ69Y8tFo uYAE4cFvI81YtiVUmD0xPbwP1WdgNiC4ZfgSfHHI= Message-Id: <6.2.5.6.2.20130920074610.0de02648@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 20 Sep 2013 07:50:28 -0700 To: Murray Kucherawy , Salvatore Loreto From: S Moonesamy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-discuss@ietf.org Subject: [apps-discuss] The case of dotless domains - draft-moonesamy-dotless-domains-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 14:52:15 -0000 Hi Sal, Murray, I would like to request adoption of draft-moonesamy-dotless-domains-00 as an Appsawg draft. Regards, S. Moonesamy From jari.arkko@piuha.net Fri Sep 20 08:04:11 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D70AE21F9654; Fri, 20 Sep 2013 08:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UTFNuS+NDiYr; Fri, 20 Sep 2013 08:04:06 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 61E1D21F9611; Fri, 20 Sep 2013 08:04:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id B43E62CC6B; Fri, 20 Sep 2013 18:04:04 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VmxNrEoHDPCQ; Fri, 20 Sep 2013 18:04:04 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 1DC5D2CC60; Fri, 20 Sep 2013 18:04:04 +0300 (EEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jari Arkko In-Reply-To: <523B659D.2000408@gmail.com> Date: Fri, 20 Sep 2013 18:04:03 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6.2.5.6.2.20130914143222.0b9590f0@elandnews.com> <6.2.5.6.2.20130918225335.0d0e2478@elandnews.com> <6.2.5.6.2.20130919074156.0cd2d900@elandnews.com> <3105F809-7E03-41D9-A634-DE32446FB19B@nominum.com> <523B659D.2000408@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1508) Cc: "" , S Moonesamy , Tim Chown , The IESG , draft-ietf-homenet-arch.all@tools.ietf.org, "homenet@ietf.org Group" , Ted Lemon Subject: Re: [apps-discuss] [homenet] APPSDIR review of draft-ietf-homenet-arch-10 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 15:04:12 -0000 > Reading this thread, I perceive big differences in understandings > of the scope of the document (and of the WG). >=20 > IMHO the document (and the WG) are about making the networking layer > (layer 3), and routing, work consistently in zero-management home > networks. That inevitably spills over into DNS. >=20 > The document (and the WG) are not about making the application > eco-system work consistently. That is completely absent from the WG > charter; after all, it's an Internet Area WG. >=20 > I believe the draft meets the charter goals. It's certainly a = snapshot, > and should be labelled as such, but it isn't intended to stray much > outside layer 3, and shouldn't. >=20 > Whether work is need in the application eco-system for home networks > is a separate discussion. FWIW, I agree with Brian. (And I'm speaking as an author and WG = participant, not with my AD hat on.) Jari From hallam@gmail.com Fri Sep 20 08:08:26 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B338E21F96B1 for ; Fri, 20 Sep 2013 08:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.978 X-Spam-Level: X-Spam-Status: No, score=-2.978 tagged_above=-999 required=5 tests=[AWL=0.620, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mIFHRxeHF8Wb for ; Fri, 20 Sep 2013 08:08:22 -0700 (PDT) Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) by ietfa.amsl.com (Postfix) with ESMTP id 9E82421F9654 for ; Fri, 20 Sep 2013 08:08:21 -0700 (PDT) Received: by mail-lb0-f175.google.com with SMTP id y6so653247lbh.34 for ; Fri, 20 Sep 2013 08:08:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9ZTqw5Xv3/2ma6nIQDAQMhkGf6lct8N/cy8rRqROOX0=; b=q22vsIBHC/xIriWFajFQ/bPhBpq1UNMKRtmcdueW3Ip1BU2vUEB4uWSMFKtk6dXNPt wJt5Q/RqdR+zy9l5lKv9ZpubwkWEs83dgpxvlvT0uvRXXfonfhhtnTz91lXULSQn5jz2 RzvQLF1IuyRnPA1fsncbB8cm+JNl/dNXbPna8oh83b+iwSn6azydEnvu6E6N/Qx8UIxd K8YsRp2vCqANnmb9eCqdTxQFRToLV+dqDzIyJXzuP47V/pxGoONIjFexzKsj9vgI4fBo /ZOOyb77Np0AvmtYlRO7OwupyJStI69joln5UIeQQ5r7jqd7/02XjPerfKaVGStBbtH2 dLmQ== MIME-Version: 1.0 X-Received: by 10.152.22.198 with SMTP id g6mr6429672laf.5.1379689684316; Fri, 20 Sep 2013 08:08:04 -0700 (PDT) Received: by 10.112.148.165 with HTTP; Fri, 20 Sep 2013 08:08:04 -0700 (PDT) In-Reply-To: References: Date: Fri, 20 Sep 2013 11:08:04 -0400 Message-ID: From: Phillip Hallam-Baker To: Dave Cridland Content-Type: multipart/alternative; boundary=089e0160bab088b70404e6d20918 Cc: Julian Reschke , Ian Hickson , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Feedback on multipart/form-data X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 15:08:26 -0000 --089e0160bab088b70404e6d20918 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Sep 19, 2013 at 10:43 AM, Dave Cridland wrote: > Julian Reschke wrote: > >> On 2013-09-19 15:29, Dave Cridland wrote: >> >>> Julian Reschke wrote: >>> >>>> >>>>> I know of RFC 2047 and RFC 2231, as well as unencoded UTF-8 and >>>>> unencoded ISO-8859-1 (I think). >>>>> >>>> >>>> No surprise here >>>> >>> >>> Yes, but one wonders if the unencoded UTF-8 actually does any harm at >>> all in a 8bit/binary-safe protocol like HTTP. >>> >>> If most processors accept this - and I have no idea - it might even >>> be >>> useful to document. >>> >> >> The risk here is that some UAs send ISO-8859-1 (or something based on the >> locale), and servers parse based on the User-Agent. We have the same >> problem with the Content-Disposition response header field. >> >> It's hard to change these kinds of workarounds in deployed code, and >> that's why a new mechanism that can't be confused with the old syntax may >> work better (thus RFC 5987). >> > > Yes, agreed, though UTF-8 is very difficult to accidentally mimic, from > what I've found. > > I wonder if an EAI expert might suggest something here? Or if a top-level > parameter or header might be useful to indicate UTF-8 header content? I > can't help but feel it's a simpler construct to adhere to. > > I think it is useful to do whatever we can to standardize multipart/form-data. But it is going to be an imperfect solution. Every browser already has to support JSON in practice. JSON is where the industry is going. JSON already has full compliance with UTF-8 etc. We should definitely try to clean up multipart/form-data but we should try to build a long term transition path to JSON. -- Website: http://hallambaker.com/ --089e0160bab088b70404e6d20918 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Sep 19, 2013 at 10:43 AM, Dave Cridland &= lt;dave@cridland.net= > wrote:
Julian Reschke wrote:
On 2013-09-19 15:29, Dave Cridland wrote:
=A0 =A0 Julian Reschke wrote:

=A0 =A0 I know of RFC 2047 and RFC 2231, as well as unencoded UTF-8 and
=A0 =A0 unencoded ISO-8859-1 (I think).

=A0 =A0 No surprise here

=A0 =A0 Yes, but one wonders if the unencoded UTF-8 actually does any harm = at
=A0 =A0 all in a 8bit/binary-safe protocol like HTTP.

=A0 =A0 If most processors accept this - and I have no idea - it might even= be
=A0 =A0 useful to document.

The risk here is that some UAs send ISO-8859-1 (or something based on the l= ocale), and servers parse based on the User-Agent. We have the same problem= with the Content-Disposition response header field.

It's hard to change these kinds of workarounds in deployed code, and th= at's why a new mechanism that can't be confused with the old syntax= may work better (thus RFC 5987).

Yes, agreed, though UTF-8 is very difficult to accidentally mimic, from wha= t I've found.

I wonder if an EAI expert might suggest something here? Or if a top-level p= arameter or header might be useful to indicate UTF-8 header content? I can&= #39;t help but feel it's a simpler construct to adhere to.


I think it is useful to do whate= ver we can to standardize multipart/form-data. But it is going to be an imp= erfect solution.

Every browser already has to supp= ort JSON in practice. JSON is where the industry is going. JSON already has= full compliance with UTF-8 etc.


We should definitely try to clean up mul= tipart/form-data but we should try to build a long term transition path to = JSON.
=A0
--
Website: http://hallambaker.com/
--089e0160bab088b70404e6d20918-- From paul.hoffman@vpnc.org Fri Sep 20 08:39:14 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFC5C21F93B9 for ; Fri, 20 Sep 2013 08:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4erP3AKgbSYJ for ; Fri, 20 Sep 2013 08:39:10 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 3A23821F994C for ; Fri, 20 Sep 2013 08:39:08 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.5) with ESMTP id r8KFd6Z7086006 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 20 Sep 2013 08:39:07 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Paul Hoffman In-Reply-To: <6.2.5.6.2.20130920074610.0de02648@elandnews.com> Date: Fri, 20 Sep 2013 08:39:06 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7004CAF3-AD74-4AA5-B32C-34C79A8545F6@vpnc.org> References: <6.2.5.6.2.20130920074610.0de02648@elandnews.com> To: apps-discuss@ietf.org X-Mailer: Apple Mail (2.1510) Subject: Re: [apps-discuss] The case of dotless domains - draft-moonesamy-dotless-domains-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 15:39:14 -0000 On Sep 20, 2013, at 7:50 AM, S Moonesamy wrote: > I would like to request adoption of draft-moonesamy-dotless-domains-00 = as an Appsawg draft. This seems like a really bad idea. The IAB report already does a much = better job of discussing the technical issues. Further, this document is = about an event (the Charleston Road application) that may be resolved = well before the RFC is published. Further still, it is not clear what = practices are being proposed as "best". If there is a desire for an RFC (as compared to a report), people should = ask the IAB to publish theirs on the IAB track. --Paul Hoffman= From masinter@adobe.com Fri Sep 20 08:57:02 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0E1F21F9BAD for ; Fri, 20 Sep 2013 08:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.489 X-Spam-Level: X-Spam-Status: No, score=-5.489 tagged_above=-999 required=5 tests=[AWL=1.110, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 91kQi5coGGfh for ; Fri, 20 Sep 2013 08:56:53 -0700 (PDT) Received: from exprod6og127.obsmtp.com (exprod6og127.obsmtp.com [64.18.1.78]) by ietfa.amsl.com (Postfix) with ESMTP id 8590F21F9B8D for ; Fri, 20 Sep 2013 08:56:40 -0700 (PDT) Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob127.postini.com ([64.18.5.12]) with SMTP ID DSNKUjxwNSKgUQumHtVWUknayUnhNk6quM3x@postini.com; Fri, 20 Sep 2013 08:56:42 PDT Received: from inner-relay-2.corp.adobe.com (inner-relay-2.adobe.com [153.32.1.52]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r8KFuZrb005340; Fri, 20 Sep 2013 08:56:36 -0700 (PDT) Received: from nacas03.corp.adobe.com (nacas03.corp.adobe.com [10.8.189.121]) by inner-relay-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r8KFuYw7028085; Fri, 20 Sep 2013 08:56:34 -0700 (PDT) Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nacas03.corp.adobe.com ([10.8.189.121]) with mapi; Fri, 20 Sep 2013 08:56:34 -0700 From: Larry Masinter To: "julian.reschke@gmx.de" , "apps-discuss@ietf.org" Date: Fri, 20 Sep 2013 08:56:33 -0700 Thread-Topic: [apps-discuss] _charset_ parameter, was I-D Action: draft-masinter-multipart-form-data-01.txt Thread-Index: Ac61/qZ0yya5Q0oLRBi2u2gHQwW9fQAGydrw Message-ID: References: <20130920122004.18281.86697.idtracker@ietfa.amsl.com> <523C4240.8050409@gmx.de> In-Reply-To: <523C4240.8050409@gmx.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [apps-discuss] _charset_ parameter, was I-D Action: draft-masinter-multipart-form-data-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 15:57:05 -0000 The goal is to describe it in this document, as a convention for anyone usi= ng multipart/form-data.=20 Parsers of multipart/form-data need to be aware of both content-type;charse= t=3D.... as well as _charset_ values. > -----Original Message----- > From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org= ] > On Behalf Of Julian Reschke > Sent: Friday, September 20, 2013 5:41 AM > To: apps-discuss@ietf.org > Subject: [apps-discuss] _charset_ parameter, was I-D Action: draft-masint= er- > multipart-form-data-01.txt >=20 > Hi there, >=20 > 2.6> > claims: >=20 > 2.6. The _charset_ field >=20 > Forms have the convention that the value of a form entry with entry > name "_charset_" and type "hidden" is automatically set to the name > of the form-charset. In this case, the value of the default charset > of each text/plain part without a charset parameter is the supplied > value. >=20 > I wasn't aware if the auto-filling feature but it appears to be true. I > supposed we should a reference to a spec where that is defined (HTML5 I > guess?) >=20 > Best regards, Julian > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From julian.reschke@gmx.de Fri Sep 20 09:05:58 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7428721F9BD5 for ; Fri, 20 Sep 2013 09:05:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.573 X-Spam-Level: X-Spam-Status: No, score=-106.573 tagged_above=-999 required=5 tests=[AWL=-3.974, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K+AQn9wqxceL for ; Fri, 20 Sep 2013 09:05:52 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 62CDC21F9BB6 for ; Fri, 20 Sep 2013 09:05:52 -0700 (PDT) Received: from [192.168.178.36] ([84.187.42.55]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MGB7j-1V9Wp70sUR-00FFVI for ; Fri, 20 Sep 2013 18:05:50 +0200 Message-ID: <523C725C.1040608@gmx.de> Date: Fri, 20 Sep 2013 18:05:48 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Larry Masinter , "apps-discuss@ietf.org" References: <20130920122004.18281.86697.idtracker@ietfa.amsl.com> <523C4240.8050409@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:eP9MMBxQnV9Z4NSsUJnpioVsupOaJLtH/+7C096jsLgw+rwESvl f1DZ5JkxZj1tRbmIlgbpQSwKw/pCvx3y/MWWkQjX7BGlm9nkNVariG/H+wGZmIP6Tl1LFXh ZWGiq+n0CSe45kCouzXvX4q3QTMqSiiMZQTe4cZqAmkVDlgpgiecGdWfs3X70AkV4AJ7cjg SzbvUHfV8mb8LS39QEasQ== Subject: Re: [apps-discuss] _charset_ parameter, was I-D Action: draft-masinter-multipart-form-data-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 16:05:58 -0000 On 2013-09-20 17:56, Larry Masinter wrote: > The goal is to describe it in this document, as a convention for anyone using multipart/form-data. > Parsers of multipart/form-data need to be aware of both content-type;charset=.... as well as _charset_ values. > ... Right. Right? Is this a difference from application/x-www-form-urlencoded where the charset parameter isn't defined at all? Best regards, Julian From julian.reschke@gmx.de Fri Sep 20 09:07:21 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3A1C21F9BFF for ; Fri, 20 Sep 2013 09:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.076 X-Spam-Level: X-Spam-Status: No, score=-106.076 tagged_above=-999 required=5 tests=[AWL=-3.477, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZluA4jo1a+Fp for ; Fri, 20 Sep 2013 09:07:12 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id B957021F9BB6 for ; Fri, 20 Sep 2013 09:07:11 -0700 (PDT) Received: from [192.168.178.36] ([84.187.42.55]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0M3eDF-1WEBzA2iPJ-00rIHm for ; Fri, 20 Sep 2013 18:07:09 +0200 Message-ID: <523C72AB.1080200@gmx.de> Date: Fri, 20 Sep 2013 18:07:07 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Phillip Hallam-Baker , Dave Cridland References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:/h/+Z0Z0a7d8D0P9QeqtHtg4j2I/jU5fyNywPUuop7c/RSp2orp ngdQG60AA+yB6FZcSf7nrXWep3g/n0xB183SELwaZRMWTgVHS9Zte2DGn5InGjXV3t1GjTG wy50gq2SgMNejHnAZphID/wpQgB/AJTUR+zPBAuyqDifGlr4utIC9uInxAhq6MzL7wnAhG2 ybrntVwxoV2dSCmkcIwlw== Cc: Ian Hickson , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Feedback on multipart/form-data X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 16:07:21 -0000 On 2013-09-20 17:08, Phillip Hallam-Baker wrote: > ... > We should definitely try to clean up multipart/form-data but we should > try to build a long term transition path to JSON. > ... Replacements for the both form upload media types would be cool, but then, how to get them deployed? Best regards, Julian From masinter@adobe.com Fri Sep 20 10:00:15 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E11721F99E9 for ; Fri, 20 Sep 2013 10:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.894 X-Spam-Level: X-Spam-Status: No, score=-5.894 tagged_above=-999 required=5 tests=[AWL=0.405, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gz6wikM-9qwN for ; Fri, 20 Sep 2013 10:00:05 -0700 (PDT) Received: from exprod6og105.obsmtp.com (exprod6og105.obsmtp.com [64.18.1.189]) by ietfa.amsl.com (Postfix) with ESMTP id D328B21F99BD for ; Fri, 20 Sep 2013 09:59:12 -0700 (PDT) Received: from outbound-smtp-1.corp.adobe.com ([192.150.11.134]) by exprod6ob105.postini.com ([64.18.5.12]) with SMTP ID DSNKUjx+2IFTB44+g7UP9EBIWUohgK2WgWMi@postini.com; Fri, 20 Sep 2013 09:59:22 PDT Received: from inner-relay-2.corp.adobe.com ([153.32.1.52]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r8KGtRiH008321; Fri, 20 Sep 2013 09:55:28 -0700 (PDT) Received: from nacas03.corp.adobe.com (nacas03.corp.adobe.com [10.8.189.121]) by inner-relay-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r8KGtJw7003640; Fri, 20 Sep 2013 09:57:47 -0700 (PDT) Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nacas03.corp.adobe.com ([10.8.189.121]) with mapi; Fri, 20 Sep 2013 09:53:55 -0700 From: Larry Masinter To: =?utf-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= , Alexey Melnikov Date: Fri, 20 Sep 2013 09:53:53 -0700 Thread-Topic: [apps-discuss] Comments on draft-masinter-multipart-form-data-00.txt Thread-Index: Ac61FB9GCO2xYPExTU64dHfOld2lsgBBeUBQ Message-ID: References: <52382E84.5020302@isode.com> <523AB8C2.9000402@it.aoyama.ac.jp> In-Reply-To: <523AB8C2.9000402@it.aoyama.ac.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Comments on draft-masinter-multipart-form-data-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 17:00:15 -0000 PiA+IEFyZSB5b3UgbWlzc2luZyBhbiBlbXB0eSBsaW5lIGFmdGVyICJjb250ZW50LXRyYW5zZmVy LWVuY29kaW5nOiI/IA0KDQpmaXhlZA0KDQo+IEl0IHdvdWxkIGJlIGdyZWF0IHRvIGhhdmUgYW4g ZXhhbXBsZSB3aXRoIFVURi04LCB0b28uIFRoaXMgd291bGQgbG9vayBhcw0KPiBmb2xsb3dzOg0K PiANCj4gLS1BYUIwM3gNCj4gY29udGVudC1kaXNwb3NpdGlvbjogZm9ybS1kYXRhOyBuYW1lPSJm aWVsZDEiDQo+IGNvbnRlbnQtdHlwZTogdGV4dC9wbGFpbjtjaGFyc2V0PVVURi04DQo+IGNvbnRl bnQtdHJhbnNmZXItZW5jb2Rpbmc6IHF1b3RlZC1wcmludGFibGUNCj4gDQo+IEpvZSBvd2VzID1F Mj04Mj1BQzEwMC4NCj4gLS1BYUIwM3gNCg0KSSdtIHJlbHVjdGFudCB0byBnaXZlIGFuIGV4YW1w bGUgdGhhdCBkb2Vzbid0IGNvcnJlc3BvbmQgdG8gYSANCnJlYWwgd29ybGQgZXhhbXBsZS4gSSBk b24ndCBrbm93IGFueW9uZSB3aG8gY3JlYXRlcyBxdW90ZWQtcHJpbnRhYmxlLg0KDQoNCg== From ietfdbh@comcast.net Fri Sep 20 07:21:55 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2675F21F9A57 for ; Fri, 20 Sep 2013 07:21:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.915 X-Spam-Level: X-Spam-Status: No, score=-99.915 tagged_above=-999 required=5 tests=[AWL=0.522, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DAe+KTyY1AtM for ; Fri, 20 Sep 2013 07:21:50 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id F271F21F9A37 for ; Fri, 20 Sep 2013 07:21:44 -0700 (PDT) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta15.westchester.pa.mail.comcast.net with comcast id TQPX1m00827AodY5FSMk4Y; Fri, 20 Sep 2013 14:21:44 +0000 Received: from [192.168.13.104] ([38.101.90.254]) by omta19.westchester.pa.mail.comcast.net with comcast id TSLc1m00H5VGBPJ3fSLiK4; Fri, 20 Sep 2013 14:21:39 +0000 User-Agent: Microsoft-MacOutlook/14.3.7.130812 Date: Fri, 20 Sep 2013 10:20:35 -0400 From: David Harrington To: Pete Resnick , Brian E Carpenter Message-ID: Thread-Topic: [homenet] APPSDIR review of draft-ietf-homenet-arch-10 In-Reply-To: <523B6DAD.5030308@qti.qualcomm.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1379686904; bh=TTFzlc5at9Lm1xP/MM1Bo4R9zZ8jDfjlg7aUx0GwK5U=; h=Received:Received:Date:Subject:From:To:Message-ID:Mime-version: Content-type; b=cZweylQNCToGeo7TDyrXUjeIIwwlhipnkV7EwIPHBSuYqKAGMqF+83P4PQIiQnUUz PePfdcWPzkvn3+FdY38TFF0/rw8rcKGkSqmpkUy4SRgQYuDbFBlf1gHU4UANPuKkSf PeG2UItfFzR8YLCcIDRlysv/PqcL1i435tra9jR0Ej6mqQueBlRWFZwcCBODjoM/HS tbKuwVBAi/EOSP1f/sjmOl5Jt4znZl0900RQfsJCvkIgy5Dx3bpCxPy2aO3Ji5UVxH /kQKXPpqehOxI/r2OIg8gGR+GVy2VdshBLH/cJbCrSnfn5JUDDTCa2yX/52Kfh+skw TiEI7LpnVSCxw== X-Mailman-Approved-At: Fri, 20 Sep 2013 10:32:39 -0700 Cc: "" , S Moonesamy , Tim Chown , The IESG , draft-ietf-homenet-arch.all@tools.ietf.org, "homenet@ietf.org Group" , Ted Lemon Subject: Re: [apps-discuss] [homenet] APPSDIR review of draft-ietf-homenet-arch-10 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 14:21:55 -0000 Which reinforces the point that the title and intro are misleading if this is just a temporary "snapshot of current thinking" document. I personally am not convinced publishing this as an RFC is beneficial - submitting for RFC publication starts a series of reviews etc. that might effected by asking for those external reviews directly. Publishing as an RFC, even an Informational one, tends to cast things into stone to a degree. And this document doesn't sound ready for that step. If the document is very clear that it is a temporary snapshot of current thinking for the WG, maybe publishing as an RFC could be justified, but I'M clear it meets the bar for RFC publication, even with the requested changes to title and intro. My $.02 -- David Harrington Ietfdbh@comcast.net +1-603-828-1401 On 9/19/13 5:33 PM, "Pete Resnick" wrote: >Understand that I still haven't done my review of the document, and that >I was the one who pushed for an APPSDIR review: > >On 9/19/13 3:59 PM, Brian E Carpenter wrote: >> Reading this thread, I perceive big differences in understandings >> of the scope of the document (and of the WG). >> >> IMHO the document (and the WG) are about making the networking layer >> (layer 3), and routing, work consistently in zero-management home >> networks. That inevitably spills over into DNS. >> >> The document (and the WG) are not about making the application >> eco-system work consistently. That is completely absent from the WG >> charter; after all, it's an Internet Area WG. >> >> I believe the draft meets the charter goals. It's certainly a snapshot, >> and should be labelled as such, but it isn't intended to stray much >> outside layer 3, and shouldn't. >> >> Whether work is need in the application eco-system for home networks >> is a separate discussion. >> > >Let's be fair: The charter talks about tackling requirements in name >resolution *and* service discovery. Once you get into those areas, but >especially the latter, you're dealing with the needs of applications. >Most of the work in this WG requires INT area expertise, but APP issues >are inevitably going to pop up. I think to say that the draft shouldn't >stray much outside of layer 3 is a bit naive. But since we're being >fair: I've tried to keep an eye on things going on in homenet and to >attend homenet meetings myself, and I've tried to encourage other >applications folks to do so, and I've failed miserably on both counts. >In large part, the former has been due to time and scheduling issues, >and for the latter I clearly was unable to make the case to applications >folks that this work *did* require cross-area review. What else is new >in the IETF lately? > >It sounds like we have a path forward for this document. But I've always >been wary about INT groups doing things for applications without serious >APP area input. (Lists of bad things available upon request.) Blame all >around, including myself, for not making that situation better. > >pr > >-- >Pete Resnick >Qualcomm Technologies, Inc. - +1 (858)651-4478 > >_______________________________________________ >homenet mailing list >homenet@ietf.org >https://www.ietf.org/mailman/listinfo/homenet From tjc@ecs.soton.ac.uk Fri Sep 20 09:30:03 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B096621F9343; Fri, 20 Sep 2013 09:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 615GOQQzmnnN; Fri, 20 Sep 2013 09:30:02 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id EBB2F21F9A71; Fri, 20 Sep 2013 09:30:01 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r8KGTelI002911; Fri, 20 Sep 2013 17:29:40 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk r8KGTelI002911 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1379694581; bh=K7IC7x5ZfW7UL2/eU5u5DbsJTkQ=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=QtNW/GHR8NiIMQXLL3UqqeTnbNVRhLrUs9/UZ2StVMfBBUeqVRA72x6FER5bt+m2k hbLeOHSU+gofgRC/c79EL8UFyAD3BtXFbjW6KyzJtPFr7filGdO5aqCIz3FR6d2WcY RVdABML7hsf4A1V5hYccN8l/2adv6Cd7iAN6zLf0= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id p8JHYe054453634417 ret-id none; Fri, 20 Sep 2013 17:29:41 +0100 Received: from dhcp-204-220.wireless.soton.ac.uk (dhcp-204-220.wireless.soton.ac.uk [152.78.204.220]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r8KGTahV019837 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 20 Sep 2013 17:29:36 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_02D50A52-F6C4-42E0-BD1F-811E19AF8D80" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Tim Chown In-Reply-To: <3105F809-7E03-41D9-A634-DE32446FB19B@nominum.com> Date: Fri, 20 Sep 2013 17:29:35 +0100 Message-ID: References: <6.2.5.6.2.20130914143222.0b9590f0@elandnews.com> <6.2.5.6.2.20130918225335.0d0e2478@elandnews.com> <6.2.5.6.2.20130919074156.0cd2d900@elandnews.com> <3105F809-7E03-41D9-A634-DE32446FB19B@nominum.com> <89570788-2319-4922-B8DD-4359349683F7@ecs.soton.ac.uk> To: Ted Lemon X-Mailer: Apple Mail (2.1508) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=p8JHYe054453634400; tid=p8JHYe054453634417; client=relay,ipv6; mail=; rcpt=; nrcpt=7:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: r8KGTelI002911 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk X-Mailman-Approved-At: Fri, 20 Sep 2013 10:32:48 -0700 Cc: "" , S Moonesamy , The IESG , draft-ietf-homenet-arch.all@tools.ietf.org, "homenet@ietf.org Group" Subject: Re: [apps-discuss] [homenet] APPSDIR review of draft-ietf-homenet-arch-10 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 16:30:03 -0000 --Apple-Mail=_02D50A52-F6C4-42E0-BD1F-811E19AF8D80 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 19 Sep 2013, at 20:43, Ted Lemon wrote: > On Sep 19, 2013, at 1:36 PM, S Moonesamy wrote: >> I agree that it would be good for the working group to evolve the = document (see my previous comments about stabilizing the document and = having a discussion about unresolved issues). It might have been missed = in my comments; what I am saying is that the working group already has = the text it needs to get the work done; what's left is some = rearrangement and tightening of the text to get a crisp document. >=20 > Possibly Tim got that from your comments=97I didn't. I should = probably let Tim respond rather than continuing to muddy the waters. Long email threads are prone to misunderstanding, so I'll just try to = state my interpretation of where the arch doc is, and how it got there. The arch doc, which is Informational, emerged from the original homenet = charter, as per http://datatracker.ietf.org/wg/homenet/charter/. This = talks about, for example, emerging IPv6 home networks with internal = routing, heterogeneous links, and internal service separation. As well = as the implications of moving from private IPv4+NAT to global IPv6. It = says "The task of the group is to produce an architecture document that = outlines how to construct home networks involving multiple routers and = subnets" and also specifies the five areas to include: routing, prefix = configuration, security, naming and service discovery. So the arch text = that has evolved over some 15 iterations over a year and a half reflects = that, and the layer 3 focus. You can argue that it's a snapshot of current thinking, and we have = discussed the notion of homenet versions (and indeed current discussions = about hipnet and homenet are potentially about such an evolution, and = whether it can be made to work), but I think it's a little more than = that given the 18+ months of discussion that have led us to where we = are, including literally thousands of list emails, and at least five = IETF meetings. Some paragraphs have been the result of 200+ emails. The = document title has remained unchanged over that time, and the structure = relatively stable. While there are some very valid DISCUSSes on the = text, I believe it represents, as a whole, a good consensus of the WG. I think the vast majority of DISCUSSes can be addressed without any = serious surgery. And it's good to have such interest focused on the = document. The questions from APPSDIR seem to focus around a) the document = structure and how/whether it's readily digestible by APPSDIR people, and = whether certain application-oriented aspects are discussed/made clear, = and b) the document title. As the document editor, I agree with Jari and Brian that I believe the = text meets the original brief. That said, the reality is that whatever = is built at layer 3, and the way in which security and naming/SD are = handled, will have an affect on applications. I've always assumed there = would be a separate text aimed at application developers, just as I = expect further texts on naming/SD, security, and routing protocol/prefix = configuration solutions. The arch doc is not intended to be a standards = track complete spec, rather as an Informational document it states the = WG consensus on the path that we'll be taking in that future work. Could = it be more concise? Yes, but having had some long threads to get = consensus, I'm wary of significant pruning that might spark further long = discussions. Might some of the documented principles change with the = benefit of future hindsight? Yes, it's possible some may, but we need = something to work from, and to point at when dojng the future work. And = the RFC library is full of examples of -bis documents. Do we want to spend more time now, given the desire to move ahead with = the other work, restructuring the arch doc? It could be done, but I = wonder whether the gain is a worthwhile tradeoff, when a separate = document could be produced, co-authored perhaps by APPSDIR people. Or = perhaps we might instead add a short section early in the document on = application implications, answering some or all of the questions SM = raised. And the title? Well, personally I have no emotional attachment to the = current title. If the IESG were to say let's rename it "Networking = Principles for Future IPv6 Home Networks" then I would lose no sleep. Sorry if that was a bit rambling, but hopefully it makes some of the = history and how we got where we are at least a bit clearer. If any of = the above sounds in any way tetchy, my apologies, its the result of = parsing a few thousand emails to get to the document that we currently = have... Tim= --Apple-Mail=_02D50A52-F6C4-42E0-BD1F-811E19AF8D80 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Ted.Lemon@nominum.com> = wrote:

On Sep 19, 2013, at 1:36 PM, S Moonesamy <sm+ietf@elandsys.com> = wrote:
I agree that it would be good for = the working group to evolve the document (see my previous comments about = stabilizing the document and having a discussion about unresolved = issues).  It might have been missed in my comments; what I am = saying is that the working group already has the text it needs to get = the work done; what's left is some rearrangement and tightening of the = text to get a crisp document.

Possibly Tim got that = from your comments=97I didn't.   I should probably let Tim = respond rather than continuing to muddy the = waters.

Long email threads are prone to = misunderstanding, so I'll just try to state my interpretation of where = the arch doc is, and how it got there.

The arch = doc, which is Informational, emerged from the original homenet charter, = as per http://datatracke= r.ietf.org/wg/homenet/charter/. This talks about, for example, = emerging IPv6 home networks with internal routing, heterogeneous links, = and internal service separation. As well as the implications of moving = from private IPv4+NAT to global IPv6. It says "The task of the group is to produce an architecture document = that outlines how to construct home networks = involving multiple routers andsubnets" and also = specifies the five areas to include: routing, prefix configuration, = security, naming and service discovery. So the arch text that has = evolved over some 15 iterations over a year and a half reflects that, = and the layer 3 focus.

You can = argue that it's a snapshot of current thinking, and we have discussed = the notion of homenet versions (and indeed current discussions about = hipnet and homenet are potentially about such an evolution, and whether = it can be made to work), but I think it's a little more than that given = the 18+ months of discussion that have led us to where we are, including = literally thousands of list emails, and at least five IETF meetings. = Some paragraphs have been the result of 200+ emails. The document title = has remained unchanged over that time, and the structure relatively = stable. While there are some very valid DISCUSSes on the text, I believe = it represents, as a whole, a good consensus of the = WG.

I think = the vast majority of DISCUSSes can be addressed without any serious = surgery. And it's good to have such interest focused on the = document.

The = questions from APPSDIR seem to focus around a) the document structure = and how/whether it's readily digestible by APPSDIR people, and whether = certain application-oriented aspects are discussed/made clear, and b) = the document title.

As the = document editor, I agree with Jari and Brian that I believe the text = meets the original brief. That said, the reality is that whatever is = built at layer 3, and the way in which security and naming/SD are = handled, will have an affect on applications. I've always assumed there = would be a separate text aimed at application developers, just as I = expect further texts on naming/SD, security, and routing protocol/prefix = configuration solutions. The arch doc is not intended to be a standards = track complete spec, rather as an Informational document it states the = WG consensus on the path that we'll be taking in that future work. Could = it be more concise? Yes, but having had some long threads to get = consensus, I'm wary of significant pruning that might spark further long = discussions. Might some of the documented principles change with the = benefit of future hindsight? Yes, it's possible some may, but we need = something to work from, and to point at when dojng the future work. And = the RFC library is full of examples of -bis = documents.

Do we = want to spend more time now, given the desire to move ahead with the = other work, restructuring the arch doc? It could be done, but I wonder = whether the gain is a worthwhile tradeoff, when a separate document = could be produced, co-authored perhaps by APPSDIR people.  Or = perhaps we might instead add a short section early in the document on = application implications, answering some or all of the questions SM = raised.

And the = title? Well, personally I have no emotional attachment to the current = title. If the IESG were to say let's rename it "Networking Principles = for Future IPv6 Home Networks" then I would lose no = sleep.

Sorry if = that was a bit rambling, but hopefully it makes some of the history and = how we got where we are at least a bit clearer. If any of the above = sounds in any way tetchy, my apologies, its the result of parsing a few = thousand emails to get to the document that we currently = have...

Tim
= --Apple-Mail=_02D50A52-F6C4-42E0-BD1F-811E19AF8D80-- From tjc@ecs.soton.ac.uk Fri Sep 20 09:38:18 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84E2D21F9C60; Fri, 20 Sep 2013 09:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DlmTBl0yTmHA; Fri, 20 Sep 2013 09:38:17 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 8F41621F9A3D; Fri, 20 Sep 2013 09:38:17 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r8KGc1d5005595; Fri, 20 Sep 2013 17:38:01 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk r8KGc1d5005595 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1379695081; bh=RCdiLsmYh0/7j8INC7YHetDOJRk=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=HldmBviRqrERtLlLILppArKkBvqqPc1lpHqCzlJJnvBNLY+3O/rxj0ilSU7TP59SD 7xkoOdNO4F2HO8mf6YX1EPHQa1JDNkYNuPcBwlms0v+7hQWPE/XVPLLVlmPOfl46gZ Dly3bwc6r1d9AJaDHHYg7Vu4mFK3gPaJypquOOC8= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id p8JHc10544536432Lo ret-id none; Fri, 20 Sep 2013 17:38:01 +0100 Received: from dhcp-204-220.wireless.soton.ac.uk (dhcp-204-220.wireless.soton.ac.uk [152.78.204.220]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r8KGbvk5022360 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 20 Sep 2013 17:37:57 +0100 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Tim Chown In-Reply-To: <6.2.5.6.2.20130918225335.0d0e2478@elandnews.com> Date: Fri, 20 Sep 2013 17:37:57 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <6.2.5.6.2.20130914143222.0b9590f0@elandnews.com> <6.2.5.6.2.20130918225335.0d0e2478@elandnews.com> To: S Moonesamy X-Mailer: Apple Mail (2.1508) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=p8JHc1054453643200; tid=p8JHc10544536432Lo; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=6:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: r8KGc1d5005595 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk X-Mailman-Approved-At: Fri, 20 Sep 2013 10:32:56 -0700 Cc: iesg@ietf.org, homenet@ietf.org, apps-discuss@ietf.org, draft-ietf-homenet-arch.all@tools.ietf.org Subject: Re: [apps-discuss] [homenet] APPSDIR review of draft-ietf-homenet-arch-10 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 16:38:18 -0000 On 19 Sep 2013, at 11:59, S Moonesamy wrote: > At 16:10 18-09-2013, Tim Chown wrote: >=20 >> There is already a split namespace for existing home networks. = Devices may live under .local (for mDNS/DNS-SD), which has meaning on = the subnet in question (though some emerging vendor products are = proxying this through routers - hence the desire to form a dnssdext WG = to look at that topic), and/or may use a globally unique name space. >>=20 >> The issue in future home networks is how naming and SD works across a = routed, multi-link home. What is the equivalent "local" name space, that = can be used whether the home is externally connected or not, providing = independent operation where necessary. >>=20 >> That section discusses how that "local" name space might look, and is = the result of considerable discussion in the homenet WG. >>=20 >> Do you have something specific to propose to say instead? >=20 > =46rom the above I gather that the namespace issue is currently = unresolved. I suggest stabilizing the document and put the part about = namespace on hold. You could document the discussion for now and list = that as unresolved issues. Apologies for the grievous chop in the above included text, but I think = it's worth adding here that the dnssdext proposed charter (under review = by the IESG currently I believe) focuses on service discovery, and has = been steered away from naming issues. It instead proposes to document = the issues arising. But additionally, thanks to Toerless, the proposed = charter not only talk about the networking elements of a SD solution, = but also what the API would look like to application developers who may = be advertising or discovering the services. As per Mike's question today, the relationship between homenet and a = potential dnssdext WG would need further clarification, but there is = overlap and there are some mutual interests.=20 I'll do a more detailed review of your other comments later.=20 Tim= From masinter@adobe.com Fri Sep 20 10:38:20 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E767D21F9CBF for ; Fri, 20 Sep 2013 10:38:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.179 X-Spam-Level: X-Spam-Status: No, score=-6.179 tagged_above=-999 required=5 tests=[AWL=0.420, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DX1zkaKc+eQH for ; Fri, 20 Sep 2013 10:38:14 -0700 (PDT) Received: from exprod6og115.obsmtp.com (exprod6og115.obsmtp.com [64.18.1.35]) by ietfa.amsl.com (Postfix) with ESMTP id 4360221F9CF1 for ; Fri, 20 Sep 2013 10:38:13 -0700 (PDT) Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob115.postini.com ([64.18.5.12]) with SMTP ID DSNKUjyIAgJNcpOdAUraU0GY9BJ90wvjFsXe@postini.com; Fri, 20 Sep 2013 10:38:13 PDT Received: from inner-relay-2.corp.adobe.com (mail-321.pac.adobe.com [153.32.1.52]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r8KHc8rb017293; Fri, 20 Sep 2013 10:38:09 -0700 (PDT) Received: from nahub02.corp.adobe.com (nahub02.corp.adobe.com [10.8.189.98]) by inner-relay-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r8KHRHx4019849; Fri, 20 Sep 2013 10:38:07 -0700 (PDT) Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nahub02.corp.adobe.com ([10.8.189.98]) with mapi; Fri, 20 Sep 2013 10:38:01 -0700 From: Larry Masinter To: "julian.reschke@gmx.de" , "apps-discuss@ietf.org" Date: Fri, 20 Sep 2013 10:38:00 -0700 Thread-Topic: [apps-discuss] _charset_ parameter, was I-D Action: draft-masinter-multipart-form-data-01.txt Thread-Index: Ac62KCU01/bsOkxGSt22qDAuaU1o2Q== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [apps-discuss] _charset_ parameter, was I-D Action: draft-masinter-multipart-form-data-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 17:38:21 -0000 > Is this a difference from application/x-www-form-urlencoded where the > charset parameter isn't defined at all? x-www-form-urlencoded forms also support _charset_ autofill. So no. From sm@elandsys.com Fri Sep 20 11:30:46 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64F7021F93F8; Fri, 20 Sep 2013 11:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.554 X-Spam-Level: X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OiqtVgBCDmPU; Fri, 20 Sep 2013 11:30:44 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id D98AD21F9D52; Fri, 20 Sep 2013 11:30:44 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.153.197]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r8KITq9B003059 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Sep 2013 11:30:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1379701807; bh=XW2cojEeY7TdIHmhEOkXkXT0ONG/Xj/z0ZLfnkJA7As=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=inC4WneuJB6ZIOwD81Yrfp1QrWDaWlR/6j0VG96JOUgGa06A0x4R/Zfr8JT6W5LLu jU3+uMuN9oNjH9tQkHnE6pK2sr9y9U6bMX7Ccu1qqPmxS9qm+8M3N2uSj2aJmVgU1P Y/BuvXmxDjrY4HXFeYJwE+ZqfbEZ4TDuKQiDtnlg= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1379701807; i=@elandsys.com; bh=XW2cojEeY7TdIHmhEOkXkXT0ONG/Xj/z0ZLfnkJA7As=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=e7xLFe7s9V3mqAGhUpEpkFIpSd/sMPwvX/PEMaHFqcZv0SEAue0wKhk67SP3lFL1V TAg7R+CZx2/EilSvQ5VWc+cRlUlkI9DBNbPdBzMyc0MVMzbG1AoELrhMXL+2MWw+6F tsTdSSdm07GlBX4DWOeilPXB6Z1NYvbmdxdqcnUw= Message-Id: <6.2.5.6.2.20130920100656.0c72ae18@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 20 Sep 2013 11:27:24 -0700 To: Tim Chown From: S Moonesamy In-Reply-To: References: <6.2.5.6.2.20130914143222.0b9590f0@elandnews.com> <6.2.5.6.2.20130918225335.0d0e2478@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: iesg@ietf.org, homenet@ietf.org, apps-discuss@ietf.org, draft-ietf-homenet-arch.all@tools.ietf.org Subject: Re: [apps-discuss] [homenet] APPSDIR review of draft-ietf-homenet-arch-10 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 18:30:46 -0000 Hi Tim, At 09:37 20-09-2013, Tim Chown wrote: >Apologies for the grievous chop in the above included text, but I >think it's worth adding here that the dnssdext proposed charter >(under review by the IESG currently I believe) focuses on service >discovery, and has been steered away from naming issues. It instead >proposes to document the issues arising. But additionally, thanks to >Toerless, the proposed charter not only talk about the networking >elements of a SD solution, but also what the API would look like to >application developers who may be advertising or discovering the services. > >As per Mike's question today, the relationship between homenet and a >potential dnssdext WG would need further clarification, but there is >overlap and there are some mutual interests. Pete Resnick explained why the APPSDIR review was requested ( http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10461.html ). The follow-up on the review is getting more difficult as what is being discussed in the document is related to a working group and a proposed working group (dnssdext). Please note that I am okay with your previous message (see http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10475.html ). Someone will have to pick a path forward and we can take it from there. Regards, S. Moonesamy From wwwrun@rfc-editor.org Fri Sep 20 12:56:09 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1E0821F9DDE; Fri, 20 Sep 2013 12:56:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.86 X-Spam-Level: X-Spam-Status: No, score=-100.86 tagged_above=-999 required=5 tests=[AWL=-1.160, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, MANGLED_TOOL=2.3, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lP9bgqZaFLoj; Fri, 20 Sep 2013 12:56:09 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 6443721F9DD5; Fri, 20 Sep 2013 12:56:09 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 0FABDB1E00B; Fri, 20 Sep 2013 12:49:33 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20130920194933.0FABDB1E00B@rfc-editor.org> Date: Fri, 20 Sep 2013 12:49:33 -0700 (PDT) Cc: drafts-update-ref@iana.org, apps-discuss@ietf.org, rfc-editor@rfc-editor.org Subject: [apps-discuss] RFC 7001 on Message Header Field for Indicating Message Authentication Status X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 19:56:09 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7001 Title: Message Header Field for Indicating Message Authentication Status Author: M. Kucherawy Status: Standards Track Stream: IETF Date: September 2013 Mailbox: superuser@gmail.com Pages: 43 Characters: 101316 Obsoletes: RFC 5451, RFC 6577 I-D Tag: draft-ietf-appsawg-rfc5451bis-10.txt URL: http://www.rfc-editor.org/rfc/rfc7001.txt 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. This document is a product of the Applications Area Working Group Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search/rfc_search.php For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From daniel@haxx.se Fri Sep 20 13:30:17 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1618721F9E3F for ; Fri, 20 Sep 2013 13:30:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PWwlJAJqZEcM for ; Fri, 20 Sep 2013 13:30:16 -0700 (PDT) Received: from giant.haxx.se (www.haxx.se [IPv6:2a00:1a28:1200:9::2]) by ietfa.amsl.com (Postfix) with ESMTP id B749021F9E3A for ; Fri, 20 Sep 2013 13:30:14 -0700 (PDT) Received: from giant.haxx.se (dast@localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id r8KKU4nm000887 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 20 Sep 2013 22:30:04 +0200 Received: from localhost (dast@localhost) by giant.haxx.se (8.14.4/8.14.4/Submit) with ESMTP id r8KKU3kU000843; Fri, 20 Sep 2013 22:30:03 +0200 X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs Date: Fri, 20 Sep 2013 22:30:03 +0200 (CEST) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: Phillip Hallam-Baker In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) X-fromdanielhimself: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Julian Reschke , Ian Hickson , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Feedback on multipart/form-data X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 20:30:17 -0000 On Fri, 20 Sep 2013, Phillip Hallam-Baker wrote: > I think it is useful to do whatever we can to standardize > multipart/form-data. But it is going to be an imperfect solution. > > Every browser already has to support JSON in practice. JSON is where the > industry is going. JSON already has full compliance with UTF-8 etc. I'll take this opputunity to remind readers that multipart/form-data is *WIDELY* used by non-browsers as well. And those non-browsers may not all have any JSON awareness at all. -- / daniel.haxx.se From paulej@packetizer.com Fri Sep 20 14:03:56 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBBC921F9E3F; Fri, 20 Sep 2013 14:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mQWqU4gmmwdE; Fri, 20 Sep 2013 14:03:52 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC6821F9DF3; Fri, 20 Sep 2013 14:03:52 -0700 (PDT) Received: from [192.168.1.20] (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r8KL3efO016520 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 20 Sep 2013 17:03:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1379711021; bh=T81b8Hvvuq0Lsr2nSwLo2GU6+gulOMaPX2LD/dIBdqI=; h=From:To:Subject:Cc:Date:Content-Transfer-Encoding:Content-Type: In-Reply-To:Message-Id:Mime-Version:Reply-To; b=V9kS9SjkKt98Uvl2KUEz9I2krJrj8Vmq0UAddn6H09R2ZRA+EuwwjGBrDnW6G0uW4 6HHRjfTiSYoV1wvPbn5ZV2LNTpp7BFvY5Mm+NC2R9BpHgASRtbzm0rhw5rSnAAD31l m+TQcn23lAy+aMS80LLAgmpYoBB1Uk/S5fSPXjqE= From: "Paul E. Jones" To: "Vijay K. Gurbani" Date: Fri, 20 Sep 2013 21:03:47 +0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 In-Reply-To: <5239CCE6.8000709@bell-labs.com> Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/5.0.18661.0 Cc: draft-ietf-insipid-session-id-reqts.all@tools.ietf.org, 'James Polk' , 'IESG IESG' , apps-discuss@ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-insipid-session-id-reqts-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "Paul E. Jones" List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 21:03:56 -0000 Vijay, I apologize for taking so long to get back to you. This has been an=20 extremely busy week for me. Please see comments below. ------ Original Message ------ From: "Vijay K. Gurbani" To: "Paul E. Jones" Cc: draft-ietf-insipid-session-id-reqts.all@tools.ietf.org; "'James=20 Polk'" ; "'IESG IESG'" ;=20 apps-discuss@ietf.org Sent: 9/18/2013 11:55:18 AM Subject: Re: [apps-discuss] APPSDIR review of=20 draft-ietf-insipid-session-id-reqts-08 >On 09/17/2013 06:32 PM, Paul E. Jones wrote: >>I'm not sure exactly what you think we need to further clarify in that >>paragraph (the last one in Section 7), but I'm happy to make changes=20 >>as you >>suggest. > >Paul: I did not do the review to tick a process box somewhere. I did >it for the normal reasons related to any peer review including=20 >rendering >the resulting draft less ambiguous and more useful to people tasked=20 >with >actually implementing this piece of work. I understand. I wasn't trying to be combative. Rather, I'm just=20 stating that I'm not sure what more is needed. Please don't assume I=20 was being argumentative, as that certainly was not the intent. >>I believe that those things are covered. In that paragraph, it talks=20 >>about >>the fact that one should an attacker who might use the same value. It=20 >>then >>talks about the fact the value should be random (or otherwise really=20 >>hard to >>just guess). It also talks about the secure transport of the=20 >>session-ID. >>Aside from REQ6, none of the language in that paragraph is normative. > >Regarding your assertion that "those things are covered", let me >simply say that they are not covered in sufficient detail to allow a >random implementer to pick this draft and implement the work. > >The phrase "surreptitiously spoof[ing]" implies (to me) changing the >identifier such that the origin does not know that the change occurred. >If what you mean is that the identifier should not be copied and >replayed, just say so. Drop the spoofing bit. I cannot recall who introduced that language into that text, but the=20 desire would be prevent two things: 1) We would not want an attacker changing the values in an existing SIP=20 session, as this makes it more challenging for logging systems, for=20 example 2) We would not want an attacker to send SIP messages through the=20 network presenting a given Session Identifier that is used by another=20 session. The reason is that such abuse interferes with any use network elements=20 might have for the Session Identifier, effectively rendering it useless. The proposed remedies in that paragraph are to mandate REQ6 and=20 encourage encryption. > But really, the problem is broader than that. Underlying REQ5 is the >unstated assumption that the SIP traffic is protected through normal >hop-by-hop TLS. If this was not the case, then how do you know that the >intermediary that injected the identifier is malicious or benign? REQ5 does not, in itself, assume or require some kind of security. In a= =20 trusted service provider network, for example, the value might be=20 inserted at the edge by an SBC and no encryption used through the=20 service provider domain. >Furthermore, the paragraph in question also asks for "sufficient >verification ... to ensure integrity" of the identifier. Note that >no means is given as to how the verification is to be performed. >Clearly, what you have in mind is hop-by-hop TLS, but you have not >stated this explicitly. In fact, this all encompassing hop-by-hop TLS >is not present as a requirement, and is only mentioned as the last >sentence in Section 7. Simply saying that RFC3261 threat model applies >is not sufficient. RFC3261 allows you to send SIP messages in >cleartext. The required security differs based on the environment. As I mentioned=20 above, a service provider domain may have minimal internal security=20 requirements, placing all security at the edge. Likewise, the issues=20 related to the Session-ID are not unlike those of the Call-ID. In fact,= =20 an attack on the Call-ID or "To" header in SIP is far more problematic=20 than an attack on the Session-ID. So, while I think most real-world=20 implementations of SIP (ignoring Session-ID) should use TLS, at the very= =20 least, we cannot insert a requirement for use of any particular security= =20 mechanism. > You really need to make a case in Section 7 that > > (a) identifiers must not reveal privacy (REQ4), > (b) identifiers must not be amenable to insertion by untrusted > intermediaries (REQ5), > (c) identifiers must be globally unique in time and space (REQ6), > (d) must not be amenable to copy-and-replay attacks (no requirement in > S5 for this); otherwise, diagnostic equipment will not know what > to do with duplicate identifiers, > (e) identifiers must not be amenable to guessing, i.e., if an=20 >adversary > possesses the current identifier, this knowledge must not allow it > to guess the next identifier (no requirement in S5 for this), > (f) identifiers must be verfiable at the receiving endpoint (no > requirement in S5 for this). > >TLS takes care of (b), (d), (f), and to a certain extent (e). If an >adversary cannot observe the current identifier, it cannot use it to >guess the next one. I do not disagree, but I cannot insert a requirement into this text that= =20 says TLS must be used. There may be folks who would oppose that. I=20 think the particular means through which the requirements are met should= =20 be spelled out only in the solution text. If you really disagree, we=20 can go back to the WG and raise the point. I certainly have no=20 objection to that. >Unfortunately, I don't see such a logical progression in the last >paragraph of Section 7. The second paragraph makes a good job of >ensuring REQ4 is met, but the third paragraph appears to be more a >stream of consciousness. > >I believe that we write these drafts so that others, probably not well >versed with the assumptions as we are, can read the drafts and >implement the work with minimum ambiguity. I don't think the draft >passes that test. > >In the end, I have indicated my disposition with "Minor comments", >not "Major comments". So if I have not convinced you that parts of >the draft should be looked at again, you are of course, free to >disregard the advice and move ahead. From my part, the review is >certainly not binding. However, if you buy my arguments, I'd be more >than happy to work with you to suggest text to make the draft better. I would wholeheartedly welcome concrete suggestions. I know from=20 experience that being too close to a piece of work can blind a person=20 from seeing the problems. A fresh pair of eyes and one who understands=20 the issues is always helpful. Paul > >Thanks, > >- vijay >-- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent >1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) >Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com >Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq From paulej@packetizer.com Fri Sep 20 14:08:08 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8041821F9E3B; Fri, 20 Sep 2013 14:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SrQkrN8iPHTo; Fri, 20 Sep 2013 14:08:04 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id CCBD221F9DF3; Fri, 20 Sep 2013 14:07:50 -0700 (PDT) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r8KL7lEp016777 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 20 Sep 2013 17:07:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1379711267; bh=DQmjJ1icq+shBzOWLdLNeaJ2Tfgqqng5H0uGfKmRV1c=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=uWSC7rko3QR8A6bjOsSUn7a2tbAv/9SaTgCPwqf25ocIo1xUqpyFkuPbafbLAdFr0 bAP2ol0/X+wRsRkL1/51KoH9z2x2H9ZxMWN9nglg2fRHeKzYi/uIh8mjIb2JKA8yag DlpI9FixpPxF/H3q/3tz9wNLlPejVxdVh5yFJ1KE= From: "Paul E. Jones" To: "'Vijay K. Gurbani'" References: <5239CCE6.8000709@bell-labs.com> In-Reply-To: Date: Fri, 20 Sep 2013 17:07:54 -0400 Message-ID: <01c601ceb645$796ae3d0$6c40ab70$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQJiEsesw72kYXCa6TAVVeYOnF0+ppioZI2Q Content-Language: en-us Cc: draft-ietf-insipid-session-id-reqts.all@tools.ietf.org, 'James Polk' , 'IESG IESG' , apps-discuss@ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-insipid-session-id-reqts-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 21:08:08 -0000 Vijay, (My email client did not format that well. Let me try to correct that...) I apologize for taking so long to get back to you. This has been an extremely busy week for me. Please see comments below. ------ Original Message ------ From: "Vijay K. Gurbani" To: "Paul E. Jones" Cc: draft-ietf-insipid-session-id-reqts.all@tools.ietf.org; "'James Polk'" ; "'IESG IESG'" ; apps-discuss@ietf.org Sent: 9/18/2013 11:55:18 AM Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-insipid-session-id-reqts-08 >On 09/17/2013 06:32 PM, Paul E. Jones wrote: >>I'm not sure exactly what you think we need to further clarify in that >>paragraph (the last one in Section 7), but I'm happy to make changes >>as you >>suggest. > >Paul: I did not do the review to tick a process box somewhere. I did >it for the normal reasons related to any peer review including >rendering >the resulting draft less ambiguous and more useful to people tasked >with >actually implementing this piece of work. I understand. I wasn't trying to be combative. Rather, I'm just stating that I'm not sure what more is needed. Please don't assume I was being argumentative, as that certainly was not the intent. >>I believe that those things are covered. In that paragraph, it talks >>about >>the fact that one should an attacker who might use the same value. It >>then >>talks about the fact the value should be random (or otherwise really >>hard to >>just guess). It also talks about the secure transport of the >>session-ID. >>Aside from REQ6, none of the language in that paragraph is normative. > >Regarding your assertion that "those things are covered", let me >simply say that they are not covered in sufficient detail to allow a >random implementer to pick this draft and implement the work. > >The phrase "surreptitiously spoof[ing]" implies (to me) changing the >identifier such that the origin does not know that the change occurred. >If what you mean is that the identifier should not be copied and >replayed, just say so. Drop the spoofing bit. I cannot recall who introduced that language into that text, but the desire would be prevent two things: 1) We would not want an attacker changing the values in an existing SIP session, as this makes it more challenging for logging systems, for example 2) We would not want an attacker to send SIP messages through the network presenting a given Session Identifier that is used by another session. The reason is that such abuse interferes with any use network elements might have for the Session Identifier, effectively rendering it useless. The proposed remedies in that paragraph are to mandate REQ6 and encourage encryption. > But really, the problem is broader than that. Underlying REQ5 is the >unstated assumption that the SIP traffic is protected through normal >hop-by-hop TLS. If this was not the case, then how do you know that the >intermediary that injected the identifier is malicious or benign? REQ5 does not, in itself, assume or require some kind of security. In a trusted service provider network, for example, the value might be inserted at the edge by an SBC and no encryption used through the service provider domain. >Furthermore, the paragraph in question also asks for "sufficient >verification ... to ensure integrity" of the identifier. Note that >no means is given as to how the verification is to be performed. >Clearly, what you have in mind is hop-by-hop TLS, but you have not >stated this explicitly. In fact, this all encompassing hop-by-hop TLS >is not present as a requirement, and is only mentioned as the last >sentence in Section 7. Simply saying that RFC3261 threat model applies >is not sufficient. RFC3261 allows you to send SIP messages in >cleartext. The required security differs based on the environment. As I mentioned above, a service provider domain may have minimal internal security requirements, placing all security at the edge. Likewise, the issues related to the Session-ID are not unlike those of the Call-ID. In fact, an attack on the Call-ID or "To" header in SIP is far more problematic than an attack on the Session-ID. So, while I think most real-world implementations of SIP (ignoring Session-ID) should use TLS, at the very least, we cannot insert a requirement for use of any particular security mechanism. > You really need to make a case in Section 7 that > > (a) identifiers must not reveal privacy (REQ4), > (b) identifiers must not be amenable to insertion by untrusted > intermediaries (REQ5), > (c) identifiers must be globally unique in time and space (REQ6), > (d) must not be amenable to copy-and-replay attacks (no requirement in > S5 for this); otherwise, diagnostic equipment will not know what > to do with duplicate identifiers, > (e) identifiers must not be amenable to guessing, i.e., if an >adversary > possesses the current identifier, this knowledge must not allow it > to guess the next identifier (no requirement in S5 for this), > (f) identifiers must be verfiable at the receiving endpoint (no > requirement in S5 for this). > >TLS takes care of (b), (d), (f), and to a certain extent (e). If an >adversary cannot observe the current identifier, it cannot use it to >guess the next one. I do not disagree, but I cannot insert a requirement into this text that says TLS must be used. There may be folks who would oppose that. I think the particular means through which the requirements are met should be spelled out only in the solution text. If you really disagree, we can go back to the WG and raise the point. I certainly have no objection to that. >Unfortunately, I don't see such a logical progression in the last >paragraph of Section 7. The second paragraph makes a good job of >ensuring REQ4 is met, but the third paragraph appears to be more a >stream of consciousness. > >I believe that we write these drafts so that others, probably not well >versed with the assumptions as we are, can read the drafts and >implement the work with minimum ambiguity. I don't think the draft >passes that test. > >In the end, I have indicated my disposition with "Minor comments", >not "Major comments". So if I have not convinced you that parts of >the draft should be looked at again, you are of course, free to >disregard the advice and move ahead. From my part, the review is >certainly not binding. However, if you buy my arguments, I'd be more >than happy to work with you to suggest text to make the draft better. I would wholeheartedly welcome concrete suggestions. I know from experience that being too close to a piece of work can blind a person from seeing the problems. A fresh pair of eyes and one who understands the issues is always helpful. Paul > >Thanks, > >- vijay >-- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent >1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) >Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com >Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq From internet-drafts@ietf.org Fri Sep 20 19:09:06 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28CA921F99E8; Fri, 20 Sep 2013 19:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WsZSHH3sIDQ5; Fri, 20 Sep 2013 19:09:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 80D2021F9AF8; Fri, 20 Sep 2013 19:09:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.72 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130921020905.3240.5036.idtracker@ietfa.amsl.com> Date: Fri, 20 Sep 2013 19:09:05 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-masinter-multipart-form-data-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Sep 2013 02:09:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Working G= roup of the IETF. Title : Returning Values from Forms: multipart/form-data Author(s) : Larry Masinter Filename : draft-masinter-multipart-form-data-02.txt Pages : 9 Date : 2013-09-20 Abstract: This specification defines an Internet Media Type, multipart/form- data, which can be used by a wide variety of applications and transported by a wide variety of protocols as a way of returning a set of values as the result of a user filling out a form. It replaces RFC 2388. NOTE The Currently, XML source for this Internet Draft may be found in [1], as well as an issue tracker. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-masinter-multipart-form-data There's also a htmlized version available at: http://tools.ietf.org/html/draft-masinter-multipart-form-data-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-masinter-multipart-form-data-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 masinter@adobe.com Fri Sep 20 19:34:19 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30F4A21F9A1C for ; Fri, 20 Sep 2013 19:34:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.284 X-Spam-Level: X-Spam-Status: No, score=-6.284 tagged_above=-999 required=5 tests=[AWL=0.315, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N8OVBVm9AnV8 for ; Fri, 20 Sep 2013 19:34:14 -0700 (PDT) Received: from exprod6og116.obsmtp.com (exprod6og116.obsmtp.com [64.18.1.37]) by ietfa.amsl.com (Postfix) with ESMTP id 256AE21F99DD for ; Fri, 20 Sep 2013 19:34:13 -0700 (PDT) Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob116.postini.com ([64.18.5.12]) with SMTP ID DSNKUj0FnmPnGmsS6iAMC9FIShClbr1zuep8@postini.com; Fri, 20 Sep 2013 19:34:14 PDT Received: from inner-relay-2.corp.adobe.com (inner-relay-2.adobe.com [153.32.1.52]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r8L2Y2rb002515; Fri, 20 Sep 2013 19:34:04 -0700 (PDT) Received: from nahub01.corp.adobe.com (nahub01.corp.adobe.com [10.8.189.97]) by inner-relay-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r8L2Y2OU000425; Fri, 20 Sep 2013 19:34:02 -0700 (PDT) Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nahub01.corp.adobe.com ([10.8.189.97]) with mapi; Fri, 20 Sep 2013 19:34:01 -0700 From: Larry Masinter To: Daniel Stenberg , Phillip Hallam-Baker Date: Fri, 20 Sep 2013 19:34:00 -0700 Thread-Topic: [apps-discuss] multipart/form-data Thread-Index: Ac62cQRzCmpnn5+HQh6jn6639gt9qA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "julian.reschke@gmx.de" , Ian Hickson , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] multipart/form-data X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 02:34:19 -0000 Sorry for the hiccups on this, I was bouncing around on the filename issue. http://tools.ietf.org/html/draft-masinter-multipart-form-data-02.txt=20 (and .xml, .pdf) http://larry.masinter.net/multipart-form-data/multipart-form-data.html I wanted to get to a stable baseline and tweak from there. It's better if you use the tracker (hit 'issues' on the=20 https://github.com/masinter/multipart-form-data ) Anyway, please (re)review.=20 > I know of RFC 2047 and RFC 2231, as well as unencoded UTF-8 and unencoded > ISO-8859-1 (I think). I mentioned these. > I'd also note that I've yet to find a receiving processor that handles > multipart/form-data when chunked - I'll admit I've not been looking much, > though. It might be as well to note the interaction with chunked encoding= . Does HTTP2 even have "chunked encoding" ? I'm not sure where I would put the advice -- it might as well belong in HTTP/1.1 and not here. Larry From sm@elandsys.com Fri Sep 20 23:29:03 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E8DA11E810A for ; Fri, 20 Sep 2013 23:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ly-Xe4zAoeMv for ; Fri, 20 Sep 2013 23:29:02 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 79E4111E8105 for ; Fri, 20 Sep 2013 23:28:58 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.153.197]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r8L6Sj8M015959 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Sep 2013 23:28:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1379744937; bh=gdm1X5aOuObhd720VpXCJbWz5R7NRsUyfXqN23Eulec=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=k1kxgTP+uq+buHgIDh6OaozmdtqnC7OXVwPX2dLP14b9R0o8tqhpfa6V0IcpDXBEm 3aQMnRGtThFx28Zd1OtcodJWkxjTVl0bSG3NvXFGu+61r0tFDMfjWWcPBvIVik1GWR kcatWtOFovrHXalsIeZT4woA6g2fnr0ba+5lNVts= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1379744937; i=@elandsys.com; bh=gdm1X5aOuObhd720VpXCJbWz5R7NRsUyfXqN23Eulec=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=ItoF6Z/2JKyM/Vy2sdhRQ4CI+Ocx3NnLtDozTWedXR/EBmpbRuMdMGGYPGjj89IT3 DobpH4wUQvhM40bOD2VSZQXRsiTTW8LhGJkmxI7dMJFoVQ3T7O5xRoWAINSTeFsGT3 9jDTOUkuyx7td7u33ClKSSkSeFlJYZFoI1EO94H8= Message-Id: <6.2.5.6.2.20130920230035.0b5becd0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 20 Sep 2013 23:28:24 -0700 To: Paul Hoffman From: S Moonesamy In-Reply-To: <7004CAF3-AD74-4AA5-B32C-34C79A8545F6@vpnc.org> References: <6.2.5.6.2.20130920074610.0de02648@elandnews.com> <7004CAF3-AD74-4AA5-B32C-34C79A8545F6@vpnc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] The case of dotless domains - draft-moonesamy-dotless-domains-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Sep 2013 06:29:03 -0000 Hi Paul, At 08:39 20-09-2013, Paul Hoffman wrote: >This seems like a really bad idea. The IAB report already does a >much better job of discussing the technical issues. Further, this >document is about an event (the Charleston Road application) that >may be resolved well before the RFC is published. Further still, it >is not clear what practices are being proposed as "best". > >If there is a desire for an RFC (as compared to a report), people >should ask the IAB to publish theirs on the IAB track. Thanks for the comments. As background information I performed an APPSDIR review about a week ago and I noticed that it mentioned "dotless domains". I raised it as a minor issue ( http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10404.html ). I followed up on the review. An Area Director raised a question about a reference in his review and I commented about that. I asked the APPSAWG Chairs whether they would consider adoption of the draft (see my message to the mailing list). I don't understand the comment about the desire for a RFC. I have been working on two other drafts where the next step was Last Call. I put that effort on hold because of other IETF activities. Section 1 is to provide some context. I don't feel strongly about it. I don't feel strongly about "best". I can discuss about the intended status if the WG Chairs believe that it is necessary to do that at this stage. Please note that I am okay if anyone says that "this is a bad idea". I prefer not to comment about the IAB statement. If the WG Chairs believe that it would be constructive to have that discussion I can comment. I am not deriving any material benefit, directly or indirectly, through the draft. Please note that if there are any question about conflict of interest I am willing to disclosure any information which anyone would like to know about. Regards, S. Moonesamy From julian.reschke@gmx.de Sat Sep 21 11:01:41 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 108D021F9A43 for ; Sat, 21 Sep 2013 11:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.487 X-Spam-Level: X-Spam-Status: No, score=-105.487 tagged_above=-999 required=5 tests=[AWL=-2.888, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oo0Rogni3g13 for ; Sat, 21 Sep 2013 11:01:35 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id F201721F964C for ; Sat, 21 Sep 2013 11:01:34 -0700 (PDT) Received: from [192.168.2.117] ([93.217.65.56]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0Mcgur-1VehMe3kyP-00HvB1 for ; Sat, 21 Sep 2013 20:01:30 +0200 Message-ID: <523DDEF5.9010500@gmx.de> Date: Sat, 21 Sep 2013 20:01:25 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Larry Masinter , "apps-discuss@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:R+t65Ooa+sb832wWthkLQfcOj0ck+C99fbNB+s3u9K0uKYxUxD2 jZ11ZMqIyKAMezf0HnXxW8ch9FVGpR19zQrHQ+x6jjbzEZRighg7cdQj15L3uV+20bS5PHf yrp4up6S7R7JePuw7PgxIVkIP6Ag8rX4ybQV0YWpKHPfJnvLQgQEJeh/6Q4AwjNfSSHzZ7L Wl0xv/bnYqgfzYBPG8T+A== Subject: Re: [apps-discuss] _charset_ parameter, was I-D Action: draft-masinter-multipart-form-data-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Sep 2013 18:01:41 -0000 On 2013-09-20 19:38, Larry Masinter wrote: >> Is this a difference from application/x-www-form-urlencoded where the >> charset parameter isn't defined at all? > > x-www-form-urlencoded forms also support _charset_ autofill. So no. But they do not use the charset parameter on the content type (it's both not defined and irrelevant as the payload is US-ASCII anyway). Best regards, Julian From masinter@adobe.com Sat Sep 21 14:22:43 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 359BC11E819A for ; Sat, 21 Sep 2013 14:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.389 X-Spam-Level: X-Spam-Status: No, score=-6.389 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8qgOD1JXnaOG for ; Sat, 21 Sep 2013 14:22:37 -0700 (PDT) Received: from exprod6og106.obsmtp.com (exprod6og106.obsmtp.com [64.18.1.191]) by ietfa.amsl.com (Postfix) with ESMTP id 9719511E819B for ; Sat, 21 Sep 2013 14:22:36 -0700 (PDT) Received: from outbound-smtp-1.corp.adobe.com ([192.150.11.134]) by exprod6ob106.postini.com ([64.18.5.12]) with SMTP ID DSNKUj4OHNljM8vH65JRFMUoDBfIIUSJQ6qn@postini.com; Sat, 21 Sep 2013 14:22:37 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r8LLIxiH022158 for ; Sat, 21 Sep 2013 14:19:00 -0700 (PDT) Received: from nacas03.corp.adobe.com (nacas03.corp.adobe.com [10.8.189.121]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r8LLMY6A025268 for ; Sat, 21 Sep 2013 14:22:34 -0700 (PDT) Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nacas03.corp.adobe.com ([10.8.189.121]) with mapi; Sat, 21 Sep 2013 14:22:34 -0700 From: Larry Masinter To: "apps-discuss@ietf.org" Date: Sat, 21 Sep 2013 14:22:33 -0700 Thread-Topic: Unicode normalization and Content-Disposition filename (RFC6266) Thread-Index: Ac63D8EN77yxL4ZsQE+qRm2Vn7Jv6w== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [apps-discuss] Unicode normalization and Content-Disposition filename (RFC6266) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 21:22:43 -0000 RFC 6266 defines a "filename*" parameter for content-disposition, as well a= s "filename".=20 We weren't going to do that for form-data, as it seemed like overkill and n= o one implements it. While I was looking into this, though, I noticed that RFC6266 doesn't mention the fact that different file systems handle Unicode normalization differently. So an a with an accent grave is represented as two Unicode characters in some file systems and as one Unicode character in another. When sending a file name from one system to the other, these representation= s need to be mapped, but there is no completely reliable indication of the file system defaults. How is this handled in practice? If I upload a file with an unnormalized name to a server which uses normalized names for files, who does the normalization?=20 Larry -- http://larry.masinter.net From internet-drafts@ietf.org Sat Sep 21 14:46:03 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F93411E819B; Sat, 21 Sep 2013 14:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BKVqs+I3pQAP; Sat, 21 Sep 2013 14:46:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B95F11E81A4; Sat, 21 Sep 2013 14:46:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.72 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130921214602.21119.38399.idtracker@ietfa.amsl.com> Date: Sat, 21 Sep 2013 14:46:02 -0700 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-masinter-multipart-form-data-03.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Sep 2013 21:46:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Applications Area Working Group Working G= roup of the IETF. Title : Returning Values from Forms: multipart/form-data Author(s) : Larry Masinter Filename : draft-masinter-multipart-form-data-03.txt Pages : 9 Date : 2013-09-21 Abstract: This specification (re)defines the multipart/form-data Internet Media Type, which can be used by a wide variety of applications and transported by a wide variety of protocols as a way of returning a set of values as the result of a user filling out a form. It replaces RFC 2388. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-masinter-multipart-form-data There's also a htmlized version available at: http://tools.ietf.org/html/draft-masinter-multipart-form-data-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-masinter-multipart-form-data-03 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 nico@cryptonector.com Sat Sep 21 17:15:01 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2835E11E81DB for ; Sat, 21 Sep 2013 17:15:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ryPLp4klYnDQ for ; Sat, 21 Sep 2013 17:14:56 -0700 (PDT) Received: from homiemail-a97.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id CAD8011E81DC for ; Sat, 21 Sep 2013 17:14:56 -0700 (PDT) Received: from homiemail-a97.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTP id 2FC28286059; Sat, 21 Sep 2013 17:14:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=m9wnwv1FCy6HI4 h6+dJ8lrUbq24=; b=gyVUwtOQGaSt4aCqBHjoaL5fBrxur9U2UA56efId+rIMVn fu35lhXQvwqX3zUJtBErgYZ9Tdib2WfEF9iUS9fWcJ0kznGvMDuEgfXztx1bZDMU cy3hKxjz4SeEwAeRiflI2CdhJ6PZX0+DXUyxjphkG01EKA0+LFZzAZmUBageo= Received: from gmail.com (unknown [186.136.131.234]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTPSA id 6DDFD286058; Sat, 21 Sep 2013 17:14:55 -0700 (PDT) Date: Sat, 21 Sep 2013 19:14:42 -0500 From: Nico Williams To: Larry Masinter Message-ID: <20130922001440.GA11751@gmail.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Unicode normalization and Content-Disposition filename (RFC6266) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 00:15:01 -0000 On Sat, Sep 21, 2013 at 02:22:33PM -0700, Larry Masinter wrote: > How is this handled in practice? If I upload a file with an > unnormalized name to a server which uses normalized names for files, > who does the normalization? How timely. We're discussing this very subject in NFSv4 WG. NFSv4 was supposed to have gotten this right back in RFC3530. Reality intruded however. I've written up an I-D (just submitted) discussing the those realities, I18N lessons learned in the NFSv4 space, boundary analysis for filesystem protocols / implementations in general, and some advice: http://tools.ietf.org/html/draft-williams-i18n-boundary-analysis-00 Some things to note: - I bet most implementations of RFC6266 use plain local filesystems, so what those filesystems do must be of interest to you :) - HFS+ normalizes to NFD on CREATE (and on LOOKUP IIRC); Arguably this violates POSIX. - ZFS has an option to normalize on LOOKUP (but NOT on CREATE) (i.e., normalization-insensitive but form-preserving, like case-insensitivity, which it also has an option for); Arguably this violates POSIX. - no other filesystem (to my knowledge) does anything at all as far as Unicode equivalence goes; - Unicode input methods generally produce NFC or close to it (even OS X does), at least for Latin scripts; - legacy filesystem metadata (file/directory names) in codesets other than Unicode abounds IMO the right thing to do is for filesystems (note: not file *servers*) to normalize on LOOKUP. Nico -- From julian.reschke@gmx.de Sun Sep 22 01:51:51 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC7421F9E1D for ; Sun, 22 Sep 2013 01:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.317 X-Spam-Level: X-Spam-Status: No, score=-105.317 tagged_above=-999 required=5 tests=[AWL=-2.718, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X6PDpDt6v7Od for ; Sun, 22 Sep 2013 01:51:46 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id CF76521F9D23 for ; Sun, 22 Sep 2013 01:51:45 -0700 (PDT) Received: from [192.168.2.117] ([93.217.80.202]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0M8JyQ-1W9SY83V5u-00vwa1 for ; Sun, 22 Sep 2013 10:51:44 +0200 Message-ID: <523EAF95.6000608@gmx.de> Date: Sun, 22 Sep 2013 10:51:33 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Larry Masinter , "apps-discuss@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:cLZp3DYQl3StcV0o/eyFl85ImD4UrQChAu7mk/dLuKa4qvFQKBo RduYGHGdNOYb2VGMsSE+vG5LH7w0BCfnW6Kcm2zVybdukorBttSWSGuH8mrVadpUhDTRLL/ gf/Z+7EGOxFBXlkLxWEV7tr+e/DsBgmsBN4LEg2q0LSiO9EQoffSsNrY+pSPEWB0qDnt9/f 6biFmcwmkZi+aj3ZpHGFQ== Subject: Re: [apps-discuss] Unicode normalization and Content-Disposition filename (RFC6266) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 08:51:51 -0000 On 2013-09-21 23:22, Larry Masinter wrote: > RFC 6266 defines a "filename*" parameter for content-disposition, as well as "filename". > We weren't going to do that for form-data, as it seemed like overkill and no one > implements it. > > While I was looking into this, though, I noticed that RFC6266 doesn't > mention the fact that different file systems handle Unicode normalization > differently. So an a with an accent grave is represented as two Unicode > characters in some file systems and as one Unicode character in another. > > When sending a file name from one system to the other, these representations > need to be mapped, but there is no completely reliable indication of > the file system defaults. > > How is this handled in practice? If I upload a file with an unnormalized > name to a server which uses normalized names for files, who does > the normalization? For C-D, I have this test case: On Windows, the mapping *does* happen; not sure whether it's the filesystem or the browser. Note that these kind of problems bug any system that maps HTTP directly to file system resources; such as WebDAV and whatever Subversion uses today... Best regards, Julian From yaojk@cnnic.cn Sun Sep 22 02:53:10 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35BEB21F9F2B for ; Sun, 22 Sep 2013 02:53:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.421 X-Spam-Level: X-Spam-Status: No, score=-100.421 tagged_above=-999 required=5 tests=[AWL=0.423, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x32OJThVTdIL for ; Sun, 22 Sep 2013 02:53:06 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [218.241.118.7]) by ietfa.amsl.com (Postfix) with SMTP id 35A1A21F9F1B for ; Sun, 22 Sep 2013 02:52:56 -0700 (PDT) X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown127.0.0.1 (HELO healthyao-think) (127.0.0.1) by 127.0.0.1 with SMTP; Sun, 22 Sep 2013 17:52:43 +0800 Date: Sun, 22 Sep 2013 17:52:43 +0800 From: "Jiankang Yao" To: "Murray S. Kucherawy" , "Salvatore Loreto" , sm References: <6.2.5.6.2.20130920074610.0de02648@elandnews.com> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.92[cn] Mime-Version: 1.0 Message-ID: <2013092217523714174334@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart180657625365_=----" Cc: =?gb2312?B?PGFwcHMtZGlzY3Vzc0BpZXRmLm9yZz4=?= Subject: Re: [apps-discuss] The case of dotless domains - draft-moonesamy-dotless-domains-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: yaojk List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Sep 2013 09:53:10 -0000 This is a multi-part message in MIME format. ------=_001_NextPart180657625365_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 DQpJIHN1cHBvcnQgU00ncyBzdWdnZXN0aW9uLiBXaXRoIHRoZSBleHBsb3NpdmUgZ3Jvd3RoIG9m IG5ldyBUTEQgbmFtZXMgaW4gSUNBTk4gb3IgaW4gRE5TIHpvbmUsIGl0IGlzIHJlYXNvbmFibGUg dG8gcHVzaCB0aGlzIGRyYWZ0IG9yIHNpbWxhciBpZGVhLg0KSXQgaXMgYmV0dGVyIHRoYXQgU00n cyBkcmFmdCBjYW4gY29tYmluZSBteSBkcmFmdCBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC15YW8tZG5zb3AtdGxkLW5hbWVzLTAwLg0KDQoNCg0KDQoNCkppYW5rYW5nIFlhbw0KDQpG cm9tOiBTIE1vb25lc2FteQ0KRGF0ZTogMjAxMy0wOS0yMCAyMjo1MA0KVG86IE11cnJheSBLdWNo ZXJhd3k7IFNhbHZhdG9yZSBMb3JldG8NCkNDOiBhcHBzLWRpc2N1c3MNClN1YmplY3Q6IFthcHBz LWRpc2N1c3NdIFRoZSBjYXNlIG9mIGRvdGxlc3MgZG9tYWlucyAtIGRyYWZ0LW1vb25lc2FteS1k b3RsZXNzLWRvbWFpbnMtMDANCkhpIFNhbCwgTXVycmF5LA0KDQpJIHdvdWxkIGxpa2UgdG8gcmVx dWVzdCBhZG9wdGlvbiBvZiANCmRyYWZ0LW1vb25lc2FteS1kb3RsZXNzLWRvbWFpbnMtMDAgYXMg YW4gQXBwc2F3ZyBkcmFmdC4NCg0KUmVnYXJkcywNClMuIE1vb25lc2FteQ0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KYXBwcy1kaXNjdXNzIG1haWxp bmcgbGlzdA0KYXBwcy1kaXNjdXNzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2FwcHMtZGlzY3Vzcw== ------=_001_NextPart180657625365_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
 
I support SM's suggestion. With the ex= plosive=20 growth of new TLD names in ICANN or in DNS zone, it is reasonable to push = this=20 draft or simlar idea.
It is better that SM's draft can combi= ne my=20 draft http://to= ols.ietf.org/html/draft-yao-dnsop-tld-names-00.
 
 
Jiankang Yao
 
Date: 2013-09-20 22:50
To: Murray Kuchera= wy;=20 Salvatore Loreto
CC: apps-discuss
Subject: [apps-discuss] The case of dotless domains -=20 draft-moonesamy-dotless-domains-00
Hi Sal, Murray,
 
I would like to request adoption of&nbs= p;
draft-moonesamy-dotless-domains-00 as an Appsawg = draft.
 
Regards,
S. Moonesamy
 
_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss
= ------=_001_NextPart180657625365_=------ From derhoermi@gmx.net Sun Sep 22 03:40:42 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3BBA21F9F20 for ; Sun, 22 Sep 2013 03:40:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k6JamcQYXy2h for ; Sun, 22 Sep 2013 03:40:37 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 51D3521F9EE5 for ; Sun, 22 Sep 2013 03:40:37 -0700 (PDT) Received: from netb.Speedport_W_700V ([84.180.239.50]) by mail.gmx.com (mrgmx101) with ESMTPA (Nemesis) id 0Lu3J4-1W3sPM1CBK-011V71 for ; Sun, 22 Sep 2013 12:40:35 +0200 From: Bjoern Hoehrmann To: Julian Reschke Date: Sun, 22 Sep 2013 12:40:28 +0200 Message-ID: <5qht39l6k1i4lqo13qkn31kfopsutoa7ff@hive.bjoern.hoehrmann.de> References: <523EAF95.6000608@gmx.de> In-Reply-To: <523EAF95.6000608@gmx.de> 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:lHlu7qXzlXvsP5nL0KpINPPPcJUpr36peRlbL7OQFLV9SuvR3OW G0GBISGYcj58uZAFmToJLn2IiTe/owejnW3vcyKAO/q3GSt1IWYc01yMZUzt8FcIA9IoEp2 WO10d7Uf0XWUIpP8KVaj17XplrqYKLfiXN59tuH/fefsuhhugvik4Dh3ptQeNDvQ4cbPZK0 IC1pQj9N1B+n5Ib+Ft36A== Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Unicode normalization and Content-Disposition filename (RFC6266) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 10:40:42 -0000 * Julian Reschke wrote: >For C-D, I have this test case: > > > >On Windows, the mapping *does* happen; not sure whether it's the >filesystem or the browser. I tested Opera 12.x and IE 9.x on Windows 7 and in both the "Save As" dialog contains the decomposed form and the saved file is named with the decomposed form. I figured perhaps some standard user interface might normalise the file name to explain the discrepancy, but neither Explorer nor the file properties dialog seems to. Could you re-run this test? -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From julian.reschke@gmx.de Sun Sep 22 03:55:18 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 562ED21F9E7C for ; Sun, 22 Sep 2013 03:55:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.166 X-Spam-Level: X-Spam-Status: No, score=-105.166 tagged_above=-999 required=5 tests=[AWL=-2.567, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZ24A79dn+CV for ; Sun, 22 Sep 2013 03:55:13 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id E4D3321F9E52 for ; Sun, 22 Sep 2013 03:55:12 -0700 (PDT) Received: from [192.168.2.117] ([93.217.80.202]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MUTSJ-1VWBvQ2xAR-00REnL for ; Sun, 22 Sep 2013 12:55:03 +0200 Message-ID: <523ECC85.9010805@gmx.de> Date: Sun, 22 Sep 2013 12:55:01 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Bjoern Hoehrmann References: <523EAF95.6000608@gmx.de> <5qht39l6k1i4lqo13qkn31kfopsutoa7ff@hive.bjoern.hoehrmann.de> In-Reply-To: <5qht39l6k1i4lqo13qkn31kfopsutoa7ff@hive.bjoern.hoehrmann.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:zv/0/CpA0Cxg9n9BOhXaHWYNDOxa/da08FHyiArC72aSADhcsXU PiLwLEVV/esWnS2ceALCAt9i1JRZbghcN5937VkvZckUBh9yI+EZH3rBwcWqPdR//sqeCHE vIRTOQxna0730FnhOMwsodYasLIfTGFp9XPcWMtTr1apaLhE2tqpfXuGNWuyHsNzYhJ+Dng NGWCTSqRwMB7mfJ3bVhjw== Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Unicode normalization and Content-Disposition filename (RFC6266) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 10:55:18 -0000 On 2013-09-22 12:40, Bjoern Hoehrmann wrote: > * Julian Reschke wrote: >> For C-D, I have this test case: >> >> >> >> On Windows, the mapping *does* happen; not sure whether it's the >> filesystem or the browser. > > I tested Opera 12.x and IE 9.x on Windows 7 and in both the "Save As" > dialog contains the decomposed form and the saved file is named with > the decomposed form. I figured perhaps some standard user interface > might normalise the file name to explain the discrepancy, but neither > Explorer nor the file properties dialog seems to. Could you re-run > this test? That's what I see as well. (so the UA displays the lowercase a umlaut). Best regards, Julian From julian.reschke@gmx.de Sun Sep 22 04:16:14 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 884CB21F93B9 for ; Sun, 22 Sep 2013 04:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.031 X-Spam-Level: X-Spam-Status: No, score=-105.031 tagged_above=-999 required=5 tests=[AWL=-2.432, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YBrh8wiirD48 for ; Sun, 22 Sep 2013 04:16:06 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id EFB5E21F9EB6 for ; Sun, 22 Sep 2013 04:16:05 -0700 (PDT) Received: from [192.168.2.117] ([93.217.80.202]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MXVr0-1VQPJ422Qo-00WTVN for ; Sun, 22 Sep 2013 13:16:04 +0200 Message-ID: <523ED172.1000005@gmx.de> Date: Sun, 22 Sep 2013 13:16:02 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Bjoern Hoehrmann References: <523EAF95.6000608@gmx.de> <5qht39l6k1i4lqo13qkn31kfopsutoa7ff@hive.bjoern.hoehrmann.de> <523ECC85.9010805@gmx.de> In-Reply-To: <523ECC85.9010805@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:JQYhM3SZlZ6XdtfIdPrSAjJ5w3sVGVVXRwHZAD+IK4FNhy36VzD nqEQLfRFeG34kDUVb4ZydPuYGuHzz94B0yXL4HIGsiZ3in3cI4xKxsIbfF9Li4l5C8rlCD4 d6aV3m1uVNTKwl/jng06uZ9Wso9kFBnqKIX+dCvucClPAg5Z//EdTMy3YMq0MizHSM4QlqU 0tHALfKCGTi2zM1Umyp+A== Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Unicode normalization and Content-Disposition filename (RFC6266) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 11:16:27 -0000 On 2013-09-22 12:55, Julian Reschke wrote: > On 2013-09-22 12:40, Bjoern Hoehrmann wrote: >> * Julian Reschke wrote: >>> For C-D, I have this test case: >>> >>> >>> >>> On Windows, the mapping *does* happen; not sure whether it's the >>> filesystem or the browser. >> >> I tested Opera 12.x and IE 9.x on Windows 7 and in both the "Save As" >> dialog contains the decomposed form and the saved file is named with >> the decomposed form. I figured perhaps some standard user interface >> might normalise the file name to explain the discrepancy, but neither >> Explorer nor the file properties dialog seems to. Could you re-run >> this test? > > That's what I see as well. (so the UA displays the lowercase a umlaut). Ok, so yes, the UI (both browser and Windows Explorer) show the umlaut, but what ends up in the filesystem is the composed form (checked with cygwin). I'll have to clarify the test results. Best regards, Julian From derhoermi@gmx.net Sun Sep 22 04:31:11 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 641F521F9F26 for ; Sun, 22 Sep 2013 04:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EFT2TpOvv3Q9 for ; Sun, 22 Sep 2013 04:31:07 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id ED63521F9F3D for ; Sun, 22 Sep 2013 04:31:06 -0700 (PDT) Received: from netb.Speedport_W_700V ([84.180.239.50]) by mail.gmx.com (mrgmx101) with ESMTPA (Nemesis) id 0MVIva-1VOD9L2Rjy-00Ym7u for ; Sun, 22 Sep 2013 13:31:05 +0200 From: Bjoern Hoehrmann To: Julian Reschke Date: Sun, 22 Sep 2013 13:31:05 +0200 Message-ID: References: <523EAF95.6000608@gmx.de> <5qht39l6k1i4lqo13qkn31kfopsutoa7ff@hive.bjoern.hoehrmann.de> <523ECC85.9010805@gmx.de> <523ED172.1000005@gmx.de> In-Reply-To: <523ED172.1000005@gmx.de> 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:1Asie3+KX4LAbvFDu0Mfrae99AWM1KYedayujEVpV/nwFl3dS8e fqTjt1F6wva9MGLInosNEEJKIGccyhnOWfV5GuzvEVfrcaM4h9OJ7pcBurc68qdj50YivV/ iaa4t8ItY3q+A0dQ8clV8KjSR8WYc9FqRepOT4mZlq63IVa1ivLn4ZIW+elkIwysiiRkO29 yItCKgIXoRQUytXVisFIw== Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Unicode normalization and Content-Disposition filename (RFC6266) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 11:31:11 -0000 * Julian Reschke wrote: >On 2013-09-22 12:55, Julian Reschke wrote: >> On 2013-09-22 12:40, Bjoern Hoehrmann wrote: >>> * Julian Reschke wrote: >>>> For C-D, I have this test case: >>>> >>>> >>>> >>>> On Windows, the mapping *does* happen; not sure whether it's the >>>> filesystem or the browser. >>> >>> I tested Opera 12.x and IE 9.x on Windows 7 and in both the "Save As" >>> dialog contains the decomposed form and the saved file is named with >>> the decomposed form. I figured perhaps some standard user interface >>> might normalise the file name to explain the discrepancy, but neither >>> Explorer nor the file properties dialog seems to. Could you re-run >>> this test? >> >> That's what I see as well. (so the UA displays the lowercase a umlaut). > >Ok, so yes, the UI (both browser and Windows Explorer) show the umlaut, >but what ends up in the filesystem is the composed form (checked with >cygwin). > >I'll have to clarify the test results. To be perfectly clear, the test case suggests `foo-a.html` and whatever I did, I never saw that turned into `foo-.html`, so the browsers and operating system used the file name literally as suggested, with no normalisation or other modification of any kind. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From cabo@tzi.org Sun Sep 22 04:35:46 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EE2F21F9EA2 for ; Sun, 22 Sep 2013 04:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.196 X-Spam-Level: X-Spam-Status: No, score=-106.196 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pZsEM5LsYdIm for ; Sun, 22 Sep 2013 04:35:41 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 775BF21F9DFA for ; Sun, 22 Sep 2013 04:35:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r8MBZYZP018822; Sun, 22 Sep 2013 13:35:35 +0200 (CEST) Received: from [192.168.217.105] (p54892010.dip0.t-ipconnect.de [84.137.32.16]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 82880FCE; Sun, 22 Sep 2013 13:35:34 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <20130922001440.GA11751@gmail.com> Date: Sun, 22 Sep 2013 13:35:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <48B94FDB-681A-4DB2-9051-8B69DB7C761F@tzi.org> References: <20130922001440.GA11751@gmail.com> To: Nico Williams X-Mailer: Apple Mail (2.1510) Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Unicode normalization and Content-Disposition filename (RFC6266) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 11:35:46 -0000 On Sep 22, 2013, at 02:14, Nico Williams wrote: > IMO the right thing to do is for filesystems (note: not file = *servers*) > to normalize on LOOKUP. That would mean you won't be able to get back at some of the files that = all have the same name after normalization. If you normalize on LOOKUP, you have to normalize on CREATE. (You also = MAY want to keep the unnormalized form around for directory listings, = just as you would do this in a case-insensitive filesystem. Or maybe = better not...:) Unless you normalize to NFC on CREATE, the principle of least surprise = more or less requires you to normalize to NFC on directory listing. (I don't agree with the backward facing direction of your section 3.6 in http://tools.ietf.org/html/draft-williams-i18n-boundary-analysis-00 -- = file servers and file access protocols SHOULD do almost nothing of what = you ask them to do. You may HAVE TO do ugly backwards stuff for legacy, but SHOULD restrict = this to the presence of an appropriate mount option etc. Non-legacy = code should never come into contact with it.) Gr=FC=DFe, Carsten From hsantos@isdg.net Sun Sep 22 07:17:20 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E804021F9FD6 for ; Sun, 22 Sep 2013 07:17:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.655 X-Spam-Level: X-Spam-Status: No, score=-102.655 tagged_above=-999 required=5 tests=[AWL=-0.056, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U9qjt7O3eSIM for ; Sun, 22 Sep 2013 07:17:16 -0700 (PDT) Received: from secure.winserver.com (news.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 1A63C21F9FB4 for ; Sun, 22 Sep 2013 07:17:15 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=3759; t=1379859430; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:Subject:To: List-ID; bh=eTqGCQ2s8Bs3FHOZmbwMHQ+Am68=; b=c5TrcMccjRas7d7k0AUL bgOvSdKV9mvPlH4QSZcmt9SgkBMNDdyefmtaVtg9JOI4Hog4Ar9sBZrMV20splQJ R2cSUTqEy0Q0lb+oSZtkrF9ceV3UvfDwIe8v2IRmWqKBL1pKd0stNbgRasooQDCk B9ZzD3Y9S6n9KNRhzvhYbWk= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Sun, 22 Sep 2013 10:17:10 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from hector.wildcatblog.com ([208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2026947654.12233.4564; Sun, 22 Sep 2013 10:17:10 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=3759; t=1379859065; h=Received:Received: Message-ID:Date:From:Organization:Subject:To:List-ID; bh=K9aaGxu h27gK9kyQid9eErO+KMMqEXj7sXjbfmxV1Rs=; b=ZKx9PvxHnEbRyJxY0FZshWa 5E5mPgXKzCi2g9Ed06iXKqFYe6cuLF1tBnf/QwmjWJKV/ktCtqhcTiLsJ1c454qZ 38AmsGZ3fY5M41u5lhcQU4jAbuajQ9qFUqIR+GKR3dM0NVGppflz4FHaEgdAvy70 RP4GsIp0q3vj1KjXR+KM= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Sun, 22 Sep 2013 10:11:05 -0400 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1473346550.9.9220; Sun, 22 Sep 2013 10:11:05 -0400 Message-ID: <523EFBE3.5010901@isdg.net> Date: Sun, 22 Sep 2013 10:17:07 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 CC: "apps-discuss@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Comment: Missing recipient address appended by wcSMTP router. To: apps-discuss@ietf.org Subject: Re: [apps-discuss] Unicode normalization and Content-Disposition filename (RFC6266) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 14:17:21 -0000 I think I can offer some legacy considerations. I would like to run some test on our backend server that supports all of the original and traditional methods of evolving file transfer methods such as: - Ascii, XYZ, Kermit over RS232 - Ascii, XYZ, Kermit over X.25, CIS - Ascii, XYZ, Kermit over TCP/IP (Telnet) - Java wire for native clients (PPP-like framing, very close to WebSockets) - FTP with extended QUOTE system for optional file info - HTTP - HTTP REST/automation and see what are the current issues are for the TCP/IP methods. Of course, escaping was already the main thing but I have been seeing more of the I8LN, UTF8 stuff not only with files but mostly currently with messages. So the mail part is now doing the transformation thru ejected blackbox functions. That would be one of the key issues of where in the backend does any transformation need to be done: - Client upload handler (hosting script), - Backend Database Server (ISAM/BTREE API, SQL, etc). For some, the backend can offer the single source entry point where it will support all incoming clients and APIs as well. Despite where its done, the main thing I recall was basically detecting the type of transformation needed, if any. With files, escaping was the main thing and I believe it is mostly done for the HTTP clients. Anyway, I think a good solution to the multi-functionality issues; - data transfer, - data storage, - data displaying, and - data lookup (searching) is to provide guidelines for the backend server of what sort of functionality is possible (and desirable for the future). So for example, the last big file transfer file name transformation industry revamping done was related to 8.3 file name vs Long File names. For backend API and compiled clients backward capability, we had to keep two file names on record for all files uploaded: Backend File Info Fields: ... ShortFileName (was FileName) FileName (new field, supports LFN) This allows us to support the structured binary API as well. So with the more modern clients now issuing LFNs, the backend would call a special (Windows) API that would reflect the file system naming nomenclature to obtain and reserve the *would be* 8.3 file name. I recall one case where this was not possible with a particular brand NFS. This required the NFS's file system driver to be supportive of this Win32/64 File I/O functionality. So one additional question for the backend server is whether to keep multiple forms of a normalized or unnormalized filename for backend and clients compatibility. -- HLS On 9/21/2013 5:22 PM, Larry Masinter wrote: > RFC 6266 defines a "filename*" parameter for content-disposition, as well as "filename". > We weren't going to do that for form-data, as it seemed like overkill and no one > implements it. > > While I was looking into this, though, I noticed that RFC6266 doesn't > mention the fact that different file systems handle Unicode normalization > differently. So an a with an accent grave is represented as two Unicode > characters in some file systems and as one Unicode character in another. > > When sending a file name from one system to the other, these representations > need to be mapped, but there is no completely reliable indication of > the file system defaults. > > How is this handled in practice? If I upload a file with an unnormalized > name to a server which uses normalized names for files, who does > the normalization? > > Larry > -- > http://larry.masinter.net > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > > -- HLS From nico@cryptonector.com Sun Sep 22 13:33:31 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9853321F9BD5 for ; Sun, 22 Sep 2013 13:33:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.939 X-Spam-Level: X-Spam-Status: No, score=-1.939 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T+pDEREI6pT8 for ; Sun, 22 Sep 2013 13:33:26 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id B240E21F9BD3 for ; Sun, 22 Sep 2013 13:33:26 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTP id 50D30508072 for ; Sun, 22 Sep 2013 13:33:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=YLJ6nYdZz1nmZVKkhlDx F3XdyxY=; b=ecyz28S7xHmeLFn/VeDeNQL1/dZMTQ7C6UoygYpPHI6D2hx0tKSJ w5kn73CWNC1XA02mO4LNnv3JCWLv7oniKyWceN75k3SWFzz3dlQ0HG1/LjuOoLlf uXtXW3TcM7zL63K2Z43T7SIKSv1auyV4YkD8TNpFtza84YKEpBS2Q0U= Received: from mail-we0-f170.google.com (mail-we0-f170.google.com [74.125.82.170]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTPSA id 0368D508064 for ; Sun, 22 Sep 2013 13:33:25 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id w62so2397813wes.29 for ; Sun, 22 Sep 2013 13:33:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=amVIooB0eL/z9wJAwjpniMnr5/m7c0OOFAeio8VfeQA=; b=bcGlYwUb2u0wbt0UZAVbYIIkbCsoloPlDR0cILdICmd765RgMA7CizGfl2OuLKrd7e mFFSWRtTssjrxfA68g5oPZyKk/aGIbyz4nJKBJKkH/23o8O6w3euHOiHX1ptkJ2jLrEO BX4ujgMocJtVyP7WoV99CbvJHD5p7U7fHxkfvdAdeZlUNGrNqZOCCGBrQTldkJlFEMPP 0Uyn5ewrvtqdWqxs5UvW6iLxBf/THAT/cX0+nFqWLo4POWuWoQwjenUn7mC+tVnGgl4W 2CevqRXxNnm4NVcJwXpFGhY0fhSLk5t9JmhScA7MIc7NX/qJTNPUgBGpAF3RZKLVNobP CVmA== MIME-Version: 1.0 X-Received: by 10.194.173.163 with SMTP id bl3mr14881012wjc.10.1379882004291; Sun, 22 Sep 2013 13:33:24 -0700 (PDT) Received: by 10.216.240.70 with HTTP; Sun, 22 Sep 2013 13:33:24 -0700 (PDT) In-Reply-To: <48B94FDB-681A-4DB2-9051-8B69DB7C761F@tzi.org> References: <20130922001440.GA11751@gmail.com> <48B94FDB-681A-4DB2-9051-8B69DB7C761F@tzi.org> Date: Sun, 22 Sep 2013 15:33:24 -0500 Message-ID: From: Nico Williams To: Carsten Bormann Content-Type: text/plain; charset=UTF-8 Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Unicode normalization and Content-Disposition filename (RFC6266) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 20:33:31 -0000 On Sun, Sep 22, 2013 at 6:35 AM, Carsten Bormann wrote: > On Sep 22, 2013, at 02:14, Nico Williams wrote: > >> IMO the right thing to do is for filesystems (note: not file *servers*) >> to normalize on LOOKUP. > > That would mean you won't be able to get back at some of the files that all have the same name after normalization. Not so, and I have an existence proof (ZFS). ZFS with this enabled will NOT allow you to have two files with equivalent names in the same directory. ZFS will also not allow you to enable this feature except at dataset (filesystem) creation time, so you can't create such conflicts ex-post. Given that there may not be multiple equivalent names in the same namespace then normalization on LOOKUP is indeed sufficient, and it provides the least surprise: the names you CREATE are the names you get back on READDIR. > If you normalize on LOOKUP, you have to normalize on CREATE. (You also MAY want to keep the unnormalized form around for directory listings, just as you would do this in a case-insensitive filesystem. Or maybe better not...:) The analogy of normalization-[in]sensitivity/preservation to case-[in]sensitivity/preservation is correct. A filesystem need not fold case on CREATE in order to be case-insensitive, folding case on LOOKUP will do. > Unless you normalize to NFC on CREATE, the principle of least surprise more or less requires you to normalize to NFC on directory listing. You're mixing layers. If your filesystem does not normalize on LOOKUP then your only workaround is to normalize on CREATE, LOOKUP, and READDIR at the next layer up (the fileserver, the application, whatever). Nico -- From cabo@tzi.org Sun Sep 22 13:37:56 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BE2D21F9C8E for ; Sun, 22 Sep 2013 13:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.202 X-Spam-Level: X-Spam-Status: No, score=-106.202 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y+VhK9pfByk0 for ; Sun, 22 Sep 2013 13:37:42 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 6F9B521F9C83 for ; Sun, 22 Sep 2013 13:37:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r8MKbXtY008678; Sun, 22 Sep 2013 22:37:33 +0200 (CEST) Received: from [192.168.217.105] (p54892010.dip0.t-ipconnect.de [84.137.32.16]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id A6354B7; Sun, 22 Sep 2013 22:37:32 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Sun, 22 Sep 2013 22:37:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130922001440.GA11751@gmail.com> <48B94FDB-681A-4DB2-9051-8B69DB7C761F@tzi.org> To: Nico Williams X-Mailer: Apple Mail (2.1510) Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Unicode normalization and Content-Disposition filename (RFC6266) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 20:37:56 -0000 On Sep 22, 2013, at 22:33, Nico Williams wrote: > ZFS with this enabled > will NOT allow you to have two files with equivalent names in the same > directory.=20 Yeah, that's exactly what I'd call normalize on CREATE. (But you are right, these terms aren't really well-defined.) Gr=FC=DFe, Carsten From nico@cryptonector.com Sun Sep 22 15:25:28 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27FA821F9B08 for ; Sun, 22 Sep 2013 15:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.943 X-Spam-Level: X-Spam-Status: No, score=-1.943 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mXBpt0gQj8hW for ; Sun, 22 Sep 2013 15:25:23 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 6A88221F9798 for ; Sun, 22 Sep 2013 15:25:10 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id F110C350079 for ; Sun, 22 Sep 2013 15:25:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=IYWAZSPO7YsncTHgHoXj pM5Fy9E=; b=mthA01HBIqQuoXJ87lvpe1NloxN/dK3hzPZMw5LsSUSgohb/FD2/ dAPzH9cASmDKOHlzxdufnpnOwoMN5bZAN6k6/a2irkRdVRklg1VZ9445ZPXmP5V2 O3v0iHpxfpKjiyTO3ua4jZhpkpU2pA+gC6ZpCaCJXVN12pkuvjLXtZ4= Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPSA id A5265350078 for ; Sun, 22 Sep 2013 15:25:09 -0700 (PDT) Received: by mail-wg0-f54.google.com with SMTP id m15so2502935wgh.9 for ; Sun, 22 Sep 2013 15:25:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=x7Vnvs7WQ8jlr/E4bvD4xVugL6LuciHuUSqIEuxelJg=; b=XwSNhFO/7jg5jTeMszjcHaTKhrKpPDXJ7ALzKvhIyAOB0xQbNpwctEbdP0Hh9iljHS CzOtmK4bEey4US+e6GHPGCEQWrPGUHHiSVITLPat3ah0JUsI1obwDo7+Snw+ePSMNPGC oIkzdtPZRxO2GG3Ewc6IZ5xZgWPj0YxgCtmdJmEQ46larwA07/6gFDDy18JWYMn8ZOvg C4kQo1zqj96z8QUgc58E+de0UmpvGC9+XloNZRyRvQvsKcAIHEi6etSBeKdGjXroV5vw u5II6AL+jHrCFdUWYL/WMLICfuF5jIOXtnUsLTzH5AwGPSJj5KAXiNBvtSlYOwj9vI6s Nw+w== MIME-Version: 1.0 X-Received: by 10.180.19.169 with SMTP id g9mr1138210wie.39.1379888707887; Sun, 22 Sep 2013 15:25:07 -0700 (PDT) Received: by 10.216.240.70 with HTTP; Sun, 22 Sep 2013 15:25:07 -0700 (PDT) In-Reply-To: References: <20130922001440.GA11751@gmail.com> <48B94FDB-681A-4DB2-9051-8B69DB7C761F@tzi.org> Date: Sun, 22 Sep 2013 17:25:07 -0500 Message-ID: From: Nico Williams To: Carsten Bormann Content-Type: text/plain; charset=UTF-8 Cc: "apps-discuss@ietf.org Discuss" Subject: Re: [apps-discuss] Unicode normalization and Content-Disposition filename (RFC6266) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 22:25:28 -0000 On Sun, Sep 22, 2013 at 3:37 PM, Carsten Bormann wrote: > On Sep 22, 2013, at 22:33, Nico Williams wrote: > >> ZFS with this enabled >> will NOT allow you to have two files with equivalent names in the same >> directory. > > Yeah, that's exactly what I'd call normalize on CREATE. > (But you are right, these terms aren't really well-defined.) Ah, perhaps we have a terminology problem, and we agree after all. Maybe we should come up with terms we can agree on widely? The three behaviors implemented in the wild are: - form-insensitive and -preserving (ZFS) - form-insensitive but not form-preserving (HFS+) - no normalization anywhere at any time (all other filesystems, to my knowledge) What should we call these? Creation of named objects in filesystems is generally expected to be atomic, and involves an implied lookup in the relevant namespace -- to me this went without saying, but perhaps it really should be stated explicitly in any document discussing this subject. That's made it convenient for me to speak of "normalization on CREATE (and LOOKUP)" as "create objects with normalized names" and "normalization on LOOKUP" as "preserve name forms, but be form-insensitive". I've seen complaints about HFS+'s normalization of object names to NFD at CREATE time (i.e., they are normalized then stored normalized). I've never seen a complaint about form-insensitive/preserving behavior, but, of course, it helps that most input modes reliably produce names in the same form (something close to NFC), so that usually one would not notice any problems. HFS+'s behavior causes problems more than anything because its choice of NF results in different forms on-disk than what users can input with usual input modes. This means we don't have very solid evidence for deciding what is the best behavior empirically, but I think f-i/f-p behavior produces the least surprising and most interoperable results. Nico -- From duerst@it.aoyama.ac.jp Sun Sep 22 23:42:00 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8ACA21F9E02 for ; Sun, 22 Sep 2013 23:42:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.092 X-Spam-Level: X-Spam-Status: No, score=-103.092 tagged_above=-999 required=5 tests=[AWL=-3.302, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fzC8TMEKB8Ne for ; Sun, 22 Sep 2013 23:41:55 -0700 (PDT) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 184BC21F9E14 for ; Sun, 22 Sep 2013 23:41:54 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id r8N6fZHS003930; Mon, 23 Sep 2013 15:41:35 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 413e_2a29_31170e58_241b_11e3_b013_001e6722eec2; Mon, 23 Sep 2013 15:41:35 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 105DABF4E2; Mon, 23 Sep 2013 15:41:35 +0900 (JST) Message-ID: <523FE289.6040007@it.aoyama.ac.jp> Date: Mon, 23 Sep 2013 15:41:13 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Julian Reschke References: <523DDEF5.9010500@gmx.de> In-Reply-To: <523DDEF5.9010500@gmx.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] _charset_ parameter, was I-D Action: draft-masinter-multipart-form-data-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 06:42:01 -0000 On 2013/09/22 3:01, Julian Reschke wrote: > On 2013-09-20 19:38, Larry Masinter wrote: >>> Is this a difference from application/x-www-form-urlencoded where the >>> charset parameter isn't defined at all? >> >> x-www-form-urlencoded forms also support _charset_ autofill. So no. > > But they do not use the charset parameter on the content type (it's both > not defined and irrelevant as the payload is US-ASCII anyway). In the case of application/x-www-form-urlencoded, the _charset_ convention has value as it tells the server the character encoding that was actually used. In the case of multipart/form-data, the _charset_ parameter is ideally redundant. Are there cases in the wild where there is conflicting character encoding information in multipart/form-data? What does server-side logic do? If some server side logic relies on _charset_ and some on the charset parameter in the content type, that means that clients have to send both. Please note that server logic also just can rely on the heuristic that form fields come back in the same encoding that the page was sent out, although there are a few corner cases where that doesn't work. Regards, Martin. > Best regards, Julian > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From duerst@it.aoyama.ac.jp Sun Sep 22 23:49:01 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF1711E819B for ; Sun, 22 Sep 2013 23:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.542 X-Spam-Level: X-Spam-Status: No, score=-102.542 tagged_above=-999 required=5 tests=[AWL=-2.752, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RGiKMI3742Bw for ; Sun, 22 Sep 2013 23:48:55 -0700 (PDT) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id BAA2811E819F for ; Sun, 22 Sep 2013 23:48:49 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id r8N6mkVf008860; Mon, 23 Sep 2013 15:48:46 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 413a_e91d_31fbe644_241c_11e3_8c44_001e6722eec2; Mon, 23 Sep 2013 15:48:46 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 0B745BF4E2; Mon, 23 Sep 2013 15:48:46 +0900 (JST) Message-ID: <523FE438.8040206@it.aoyama.ac.jp> Date: Mon, 23 Sep 2013 15:48:24 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Larry Masinter References: <52382E84.5020302@isode.com> <523AB8C2.9000402@it.aoyama.ac.jp> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Comments on draft-masinter-multipart-form-data-00.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 06:49:01 -0000 Hello Larry, On 2013/09/21 1:53, Larry Masinter wrote: >> It would be great to have an example with UTF-8, too. This would look as >> follows: >> >> --AaB03x >> content-disposition: form-data; name="field1" >> content-type: text/plain;charset=UTF-8 >> content-transfer-encoding: quoted-printable >> >> Joe owes =E2=82=AC100. >> --AaB03x > > I'm reluctant to give an example that doesn't correspond to a > real world example. I don't know anyone who creates quoted-printable. I just copied the windows-1250 example, so I'm a bit surprised that you use that with quoted-printable, but claim that nobody creates quoted-printable. Or are you trying to say that nobody creates quoted-printable with UTF-8? If that's the case, I can of course redo my example with base64. Regards, Martin. From duerst@it.aoyama.ac.jp Mon Sep 23 00:48:45 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9670B11E80DF for ; Mon, 23 Sep 2013 00:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.104 X-Spam-Level: X-Spam-Status: No, score=-102.104 tagged_above=-999 required=5 tests=[AWL=-2.314, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HROdA4GPjP3U for ; Mon, 23 Sep 2013 00:48:39 -0700 (PDT) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id E651A11E80D3 for ; Mon, 23 Sep 2013 00:48:38 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id r8N7mUfM017320; Mon, 23 Sep 2013 16:48:31 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 413e_40d2_8a54e13a_2424_11e3_b013_001e6722eec2; Mon, 23 Sep 2013 16:48:30 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 31B85BF4E2; Mon, 23 Sep 2013 16:48:30 +0900 (JST) Message-ID: <523FF238.6000200@it.aoyama.ac.jp> Date: Mon, 23 Sep 2013 16:48:08 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Nico Williams References: <20130922001440.GA11751@gmail.com> In-Reply-To: <20130922001440.GA11751@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Unicode normalization and Content-Disposition filename (RFC6266) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 07:48:45 -0000 On 2013/09/22 9:14, Nico Williams wrote: > - HFS+ normalizes to NFD on CREATE (and on LOOKUP IIRC); Please be careful. As far as I'm aware, this is a form closer to NFD than to NFC, but not identical to NFD. Regards, Martin. > Arguably this violates POSIX. From Ted.Lemon@nominum.com Fri Sep 20 11:29:23 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF62F21F994C; Fri, 20 Sep 2013 11:29:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.498 X-Spam-Level: X-Spam-Status: No, score=-106.498 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Txi7NPGlil5u; Fri, 20 Sep 2013 11:29:17 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id 05C5221F9A65; Fri, 20 Sep 2013 11:29:15 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKUjyT+iQ2bvGeQ48zgstiZ5AVuP5MdPec@postini.com; Fri, 20 Sep 2013 11:29:15 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 6ED501B82DB; Fri, 20 Sep 2013 11:29:14 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 5FD4E190068; Fri, 20 Sep 2013 11:29:14 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 20 Sep 2013 11:29:14 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1811\)) From: Ted Lemon In-Reply-To: Date: Fri, 20 Sep 2013 10:30:37 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: To: David Harrington X-Mailer: Apple Mail (2.1811) X-Originating-IP: [192.168.1.10] X-Mailman-Approved-At: Mon, 23 Sep 2013 06:26:26 -0700 Cc: "" , Pete Resnick , S Moonesamy , Tim Chown , The IESG , draft-ietf-homenet-arch.all@tools.ietf.org, "homenet@ietf.org Group" , Brian E Carpenter Subject: Re: [apps-discuss] [homenet] APPSDIR review of draft-ietf-homenet-arch-10 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 18:29:23 -0000 On Sep 20, 2013, at 10:20 AM, David Harrington = wrote: > If the document is very clear that it is a temporary snapshot of = current > thinking for the WG, maybe publishing as an RFC could be justified, = but > I'M clear it meets the bar for RFC publication, even with the = requested > changes to title and intro. This is not a temporary snapshot of current thinking for the WG. It is = a specification of what we think we are trying to achieve. It is = likely that some things will be removed, and some things will be made = clearer, as work progresses. But this isn't just a strand of spaghetti = cast at the wall in hopes that it will stick. If you have specific criticisms of the document, that would be very = helpful. If you think it's going in the wrong direction, please say = so, and say why. But "I am personally not convinced that publishing = this is a good idea" is the opposite of a helpful comment. If it's not = ready, please say why, not just that you think so. From mark@townsley.net Mon Sep 23 00:43:42 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6C7211E8170 for ; Mon, 23 Sep 2013 00:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.513 X-Spam-Level: X-Spam-Status: No, score=-3.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bDZE6WnPoQCw for ; Mon, 23 Sep 2013 00:43:35 -0700 (PDT) Received: from mail-ee0-f51.google.com (mail-ee0-f51.google.com [74.125.83.51]) by ietfa.amsl.com (Postfix) with ESMTP id 2E40711E80DE for ; Mon, 23 Sep 2013 00:43:35 -0700 (PDT) Received: by mail-ee0-f51.google.com with SMTP id c1so1513613eek.10 for ; Mon, 23 Sep 2013 00:43:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=ycxuOZLiN1iV4Vz288D6AlCqSxiFAqB1BxtzdVEIB2M=; b=i13rY6CWPlIaTe6/Fnac31P9umCGP23zBSLNeDmMb51QeIQDT7QgHhCVAFQTt8bIeU sMe3F+9uFdV7GHLyvs5ZoUgO+8u1L7YpbN8e+ivEPc50VEbkXA7oDPkCJItcRhlW4SDj 2RT7cija6HldDx/FscRXXhnGir6pXm1rARKIU1JvgJ/1od+nHIYfhuyHI+UjIxFrOQf8 wsW4K4qdJ6Tr7z8rRUZ07zloM63aFuRszZuWq9HyuMrH8JQSpJSrn6g1X0uqlrHNrFrC PCDPFaEr4dfI0/G9h+y511RrwHoU1sbyRIhMTebUBtquRPToJ8ruS39QiIjO0xn+YK/f 8A1Q== X-Gm-Message-State: ALoCoQlOVafnH+/mn3U6BB0ZBGViiqdIo6clnHPn7a5b7D6qr6VmG2ZZSRxgiGFtV0QjjvXhCIF/ X-Received: by 10.14.241.74 with SMTP id f50mr35230591eer.29.1379922214211; Mon, 23 Sep 2013 00:43:34 -0700 (PDT) Received: from dhcp-10-61-99-17.cisco.com (173-38-208-169.cisco.com. [173.38.208.169]) by mx.google.com with ESMTPSA id a6sm39749909eei.10.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 23 Sep 2013 00:43:31 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: Date: Mon, 23 Sep 2013 00:43:23 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7C925E3C-2437-41A7-BAA8-1332BE61E097@townsley.net> References: <6.2.5.6.2.20130914143222.0b9590f0@elandnews.com> <6.2.5.6.2.20130918225335.0d0e2478@elandnews.com> <6.2.5.6.2.20130919074156.0cd2d900@elandnews.com> <3105F809-7E03-41D9-A634-DE32446FB19B@nominum.com> <523B659D.2000408@gmail.com> To: Jari Arkko X-Mailer: Apple Mail (2.1283) X-Mailman-Approved-At: Mon, 23 Sep 2013 06:26:44 -0700 Cc: "" , S Moonesamy , Tim Chown , Ted Lemon , draft-ietf-homenet-arch.all@tools.ietf.org, "homenet@ietf.org Group" , Brian E Carpenter , The IESG Subject: Re: [apps-discuss] [homenet] APPSDIR review of draft-ietf-homenet-arch-10 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 07:43:43 -0000 On Sep 20, 2013, at 8:04 AM, Jari Arkko wrote: >=20 >> Reading this thread, I perceive big differences in understandings >> of the scope of the document (and of the WG). >>=20 >> IMHO the document (and the WG) are about making the networking layer >> (layer 3), and routing, work consistently in zero-management home >> networks. That inevitably spills over into DNS. >>=20 >> The document (and the WG) are not about making the application >> eco-system work consistently. That is completely absent from the WG >> charter; after all, it's an Internet Area WG. >>=20 >> I believe the draft meets the charter goals. It's certainly a = snapshot, >> and should be labelled as such, but it isn't intended to stray much >> outside layer 3, and shouldn't. >>=20 >> Whether work is need in the application eco-system for home networks >> is a separate discussion. >=20 > FWIW, I agree with Brian. (And I'm speaking as an author and WG = participant, not with my AD hat on.) Same here. I've said many a time from the chair seat that we are working = on the "plumbing", "IP" and, tongue-in-cheek a bit, "Layer 3 plus or = minus half a layer" Of course, the network layer affects the transport layer affects the app = layer, etc. The cross area review of the IETF and IESG helps to remind = us of this lest we forget. It's not just what goes on above that = matters, we've had IEEE folks come in to let us know what's happening = below us as well. Ultimately though, this group is as tightly focused as we can manage to = be on the Internet Area in terms of deliverables. It would be a farce to = believe we had the ability to do otherwise. - Mark >=20 > Jari >=20 From paul.hoffman@vpnc.org Mon Sep 23 08:02:18 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D983321F9F0E for ; Mon, 23 Sep 2013 08:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SDw3Jx8NFKsv for ; Mon, 23 Sep 2013 08:02:17 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 7E4A921F9ECE for ; Mon, 23 Sep 2013 08:02:17 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.5) with ESMTP id r8NF21ka037691 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 23 Sep 2013 08:02:02 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-185.dsl.dynamic.sonic.net [50.1.98.185] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Paul Hoffman In-Reply-To: <6.2.5.6.2.20130920230035.0b5becd0@resistor.net> Date: Mon, 23 Sep 2013 08:02:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <97F5B1B3-299A-44DF-8934-E91A2E0B3FD8@vpnc.org> References: <6.2.5.6.2.20130920074610.0de02648@elandnews.com> <7004CAF3-AD74-4AA5-B32C-34C79A8545F6@vpnc.org> <6.2.5.6.2.20130920230035.0b5becd0@resistor.net> To: S Moonesamy X-Mailer: Apple Mail (2.1510) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] The case of dotless domains - draft-moonesamy-dotless-domains-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 15:02:19 -0000 On Sep 20, 2013, at 11:28 PM, S Moonesamy wrote: > Hi Paul, > At 08:39 20-09-2013, Paul Hoffman wrote: >> This seems like a really bad idea. The IAB report already does a much = better job of discussing the technical issues. Further, this document is = about an event (the Charleston Road application) that may be resolved = well before the RFC is published. Further still, it is not clear what = practices are being proposed as "best". >>=20 >> If there is a desire for an RFC (as compared to a report), people = should ask the IAB to publish theirs on the IAB track. >=20 > Thanks for the comments. As background information I performed an = APPSDIR review about a week ago and I noticed that it mentioned "dotless = domains". I raised it as a minor issue ( = http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10404.html = ). I followed up on the review. An Area Director raised a question = about a reference in his review and I commented about that. I asked the = APPSAWG Chairs whether they would consider adoption of the draft (see my = message to the mailing list). It seems useful to have an RFC that defines "dotless domains" and lists = the technical (and possibly political) problems with them. I believe = that the IAB's report is a much better starting point than = draft-moonesamy-dotless-domains. > I don't understand the comment about the desire for a RFC. I have = been working on two other drafts where the next step was Last Call. I = put that effort on hold because of other IETF activities. And I don't understand what that has to do with your proposal to advance = this as a WG work item. The purpose of having a WG work item is to = eventually publish one or more RFCs. I am proposing that effort be = focused on the IAB, not draft-moonesamy-dotless-domains. > Section 1 is to provide some context. I don't feel strongly about it. The same "context" is in the abstract. Maybe produce a draft that has = what you really want in it? > I don't feel strongly about "best". I can discuss about the intended = status if the WG Chairs believe that it is necessary to do that at this = stage. It is vastly different for a WG work item to be informational than = standards track, particularly when discussing something with which a WG = has little experience. > Please note that I am okay if anyone says that "this is a bad idea". = I prefer not to comment about the IAB statement. If the WG Chairs = believe that it would be constructive to have that discussion I can = comment. It is a bad idea for this WG to produce a document that somewhat = overlaps with the IAB report and somewhat does not, but is not clear = where it does and does not. It is a bad idea to write a Best Current = Practices document when we have no idea what the best current practices = are. > I am not deriving any material benefit, directly or indirectly, = through the draft. Please note that if there are any question about = conflict of interest I am willing to disclosure any information which = anyone would like to know about. No one suggested any such benefit to you or the IAB. --Paul Hoffman= From vkg@bell-labs.com Mon Sep 23 08:24:41 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53D6D21F9F8F; Mon, 23 Sep 2013 08:24:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6GvX8Ri54bt; Mon, 23 Sep 2013 08:24:36 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 6876021F9FB3; Mon, 23 Sep 2013 08:24:36 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r8NFOVR4008670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 23 Sep 2013 10:24:32 -0500 (CDT) Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id r8NFOTuR018334 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 23 Sep 2013 10:24:31 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.237.229]) by umail.lucent.com (8.13.8/TPES) with ESMTP id r8NFOSjG012655; Mon, 23 Sep 2013 10:24:28 -0500 (CDT) Message-ID: <52405E5B.7080207@bell-labs.com> Date: Mon, 23 Sep 2013 10:29:31 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130805 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Paul E. Jones" References: <5239CCE6.8000709@bell-labs.com> <01c601ceb645$796ae3d0$6c40ab70$@packetizer.com> In-Reply-To: <01c601ceb645$796ae3d0$6c40ab70$@packetizer.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: draft-ietf-insipid-session-id-reqts.all@tools.ietf.org, 'James Polk' , 'IESG IESG' , apps-discuss@ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-insipid-session-id-reqts-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 15:24:41 -0000 On 09/20/2013 04:07 PM, Paul E. Jones wrote: > Vijay, > > (My email client did not format that well. Let me try to correct that...) > > I apologize for taking so long to get back to you. This has been an > extremely busy week for me. Paul: No problem. Please see inline. > I understand. I wasn't trying to be combative. Rather, I'm just > stating that I'm not sure what more is needed. Please don't assume I > was being argumentative, as that certainly was not the intent. No worries; I just wanted to make sure that if you made any changes, they would be driven by what you would also consider actual problems, and not driven by just trying to placate me :-) > I cannot recall who introduced that language into that text, but the > desire would be prevent two things: [...] > The proposed remedies in that paragraph are to mandate REQ6 and > encourage encryption. Right, it is the "encourage encryption" part that I think should garner some attention. One way to do so is suggested below. > REQ5 does not, in itself, assume or require some kind of security. In a > trusted service provider network, for example, the value might be > inserted at the edge by an SBC and no encryption used through the > service provider domain. SIP has developed this notion of a trust domain as a set of SIP nodes, including B2BUAs, that are trusted to exchange some private information among (and between) themselves. This function goes by the wonderful name of Spec(T) and is fully defined in rfc3324. Other pieces of work [1,2] that forsee a need to define a trust domain simply use the Spec(T) function to do so. > The required security differs based on the environment. As I mentioned > above, a service provider domain may have minimal internal security > requirements, placing all security at the edge. Likewise, the issues > related to the Session-ID are not unlike those of the Call-ID. In fact, > an attack on the Call-ID or "To" header in SIP is far more problematic > than an attack on the Session-ID. So, while I think most real-world > implementations of SIP (ignoring Session-ID) should use TLS, at the very > least, we cannot insert a requirement for use of any particular security > mechanism. The Spec(T) mechanism at least allows you to state that you have thought of the security ramifications of the header being sent out in cleartext, and therefore, domains that wish to exchange the header in non cleartext format should comply to Spec(T). You can define Spec(T) as is done in [1], without having to delve into the mandating TLS or choosing cipher specs for TLS. It seems appropriate that if we know that usurping the session identifier will lead to problems then we at least try to provide a way to mitigate these problems without mandating specific security policies. I think Spec(T) allows you to do so. Regarding the statement that an attack on the Call-ID or "To" header being more disruptive than an attack on Session-ID, sure I agree. But at least we have rfc4474 to mitigate that (I understand it is not used widely, but it *is* there). > I do not disagree, but I cannot insert a requirement into this text that > says TLS must be used. There may be folks who would oppose that. I > think the particular means through which the requirements are met should > be spelled out only in the solution text. If you really disagree, we > can go back to the WG and raise the point. I certainly have no > objection to that. I am not privy to the discussions that happened in the working group along making TLS mandatory. But from your description it seems that the working group does not want to mandate it. Maybe couching the security aspects in terms of Spec(T) will suffice? [1] See Section 5.4 of http://tools.ietf.org/html/draft-ietf-soc-load-control-event-package-09 [2] http://tools.ietf.org/html/draft-vanelburg-dispatch-private-network-ind-02 Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq From superuser@gmail.com Mon Sep 23 11:01:38 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82D0421F9F0E for ; Mon, 23 Sep 2013 11:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g56cZNXsk2Em for ; Mon, 23 Sep 2013 11:01:38 -0700 (PDT) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id D77F221F8F4A for ; Mon, 23 Sep 2013 11:01:37 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id b13so3343726wgh.11 for ; Mon, 23 Sep 2013 11:01:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=2BwtzDiel+tybDVAS/b6gf24nbFnRdZ1m79qJBSG7Vo=; b=pbdxICCfCDJwRHLzLGWI/Rpqniw3l/yKXH5q1DPSo4+KbfTFcNQyUv2TwjVi5SlI6o +amEACXWY150rQHm3vijEWFJBYhf/P+LmoWpcLjGaacnOf6kwnhHWq3Pqz1TDGfS6+Tc gZ6VI8ZSMEeYqnjxvkTWamDn0qPyf29HNpUCCGyo2VtjHZbW5Rml5TNvjsI9KgJgMxdC /eJ1Y27twjNOC0WBNHGeCu+Uehq62bPDulzf1Z3KAZSx73h5vuy93pkm7bKYrwdTsw0J dXMRmmkbV/MP9O9LgoegZB+0J5dTCMeQbUG9WhtOmNzt0CYFG3XBwz78GdlfzVNBEOtd 1hRQ== MIME-Version: 1.0 X-Received: by 10.180.198.227 with SMTP id jf3mr14597897wic.19.1379959296959; Mon, 23 Sep 2013 11:01:36 -0700 (PDT) Received: by 10.180.18.202 with HTTP; Mon, 23 Sep 2013 11:01:36 -0700 (PDT) Date: Mon, 23 Sep 2013 11:01:36 -0700 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=047d7b622588b32d3a04e710cf7b Subject: [apps-discuss] IETF 88 session request submitted X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 18:01:38 -0000 --047d7b622588b32d3a04e710cf7b Content-Type: text/plain; charset=ISO-8859-1 Colleagues, I've submitted a request for our usual 2.5-hour Monday morning slot. I'll advise when it's been formally scheduled. We are still accepting agenda items. We're a month away from having to settle on that, so there's still time, but please don't wait until the last minute as we may not be able to accommodate your request if you do. -MSK, APPSAWG co-chair --047d7b622588b32d3a04e710cf7b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Colleagues,

I've submitted a request = for our usual 2.5-hour Monday morning slot.=A0 I'll advise when it'= s been formally scheduled.

We are still accepting agenda items= .=A0 We're a month away from having to settle on that, so there's s= till time, but please don't wait until the last minute as we may not be= able to accommodate your request if you do.

-MSK, APPSAWG co-chair

--047d7b622588b32d3a04e710cf7b-- From sm@elandsys.com Mon Sep 23 11:05:43 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B90CB21F9C78 for ; Mon, 23 Sep 2013 11:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nAZM6MO6yaRp for ; Mon, 23 Sep 2013 11:05:42 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id A3BC221F8EB2 for ; Mon, 23 Sep 2013 11:05:22 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.157.76]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r8NI56uu007135 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Sep 2013 11:05:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1379959520; bh=buRRXbTkr8Z+zGDHqojDQx3XQ+0jhuAIo9imgHORAX8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=yuXDoVX6kaRFD2xAabs5Y+zb0DZVl4zgTTwfRvHRqFpujLPdX6w+mOMGNbIpBzMGI u4nBL9t4yoOpUuuzCq6AXBN9BGeji/P499Mvl1SAHVKZvCQPSKoFnd35APsOZ5EZWr 1XyJxJi8h00WUzDMLW6JmjUl28gUMIPiD21v8Yok= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1379959520; i=@elandsys.com; bh=buRRXbTkr8Z+zGDHqojDQx3XQ+0jhuAIo9imgHORAX8=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=e4WSOawTYuAklie6DPKIxiRzBp93JHGYwq/lCCRqjEKMybgirvlN0OT5Wk/6uFdCg PjmXDWa0S4//y6ga1BZXvadMV+Gz2i8+TfarZ1eurxukJ02gbAswf9aKzIKxpfWE0/ RhTG8eNvAR72isJlUrkMdyREyufQz8Zv1ifvcHD0= Message-Id: <6.2.5.6.2.20130923083356.07bdbff8@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 23 Sep 2013 09:55:29 -0700 To: Paul Hoffman From: S Moonesamy In-Reply-To: <97F5B1B3-299A-44DF-8934-E91A2E0B3FD8@vpnc.org> References: <6.2.5.6.2.20130920074610.0de02648@elandnews.com> <7004CAF3-AD74-4AA5-B32C-34C79A8545F6@vpnc.org> <6.2.5.6.2.20130920230035.0b5becd0@resistor.net> <97F5B1B3-299A-44DF-8934-E91A2E0B3FD8@vpnc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] The case of dotless domains - draft-moonesamy-dotless-domains-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 18:05:43 -0000 Hi Paul, At 08:02 23-09-2013, Paul Hoffman wrote: >It seems useful to have an RFC that defines "dotless domains" and >lists the technical (and possibly political) problems with them. I >believe that the IAB's report is a much better starting point than >draft-moonesamy-dotless-domains. The reason I did not rely only on the RFCs mentioned in the IAB statement was because of a comment from John Klensin: "My personal bias is that, if the IAB starts making Statements about the implications of a technological choice, they should be comprehensive about the relevant subject." I went through the specifications which are listed as Informational references in the draft. I am aware of cases such as: ; QUESTION SECTION: ;io. IN MX ;; ANSWER SECTION: io. 1 IN MX 10 mailer2.io. as they have been discussed previously within the Applications Area. I preferred not to assume that there aren't any technical problems because of that. >The same "context" is in the abstract. Maybe produce a draft that >has what you really want in it? [snip] >It is vastly different for a WG work item to be informational than >standards track, particularly when discussing something with which a >WG has little experience. The Abstract and Section 1 mentions that: "This memo discusses about the case of the dotless domains in terms of the technical standards published by the IETF." Section 4 is about "Domain names in Application Protocols". The protocols mentioned are: 1. FTP 2. HTTP 3. IMAP 4. SMTP 5. XMPP In my opinion the above-mentioned protocols are usually discussed within the Applications Area. There was a thread on the SMTP mailing list where Dave Crocker commented that: 'From ICANN SSAC SAC 053 (www.icann.org/en/groups/ssac/documents/sac-053-en.pdf): "3.4 Electronic Mail One serious and prevalent concern is that dotless domains would not work with protocols that specify additional rules of what constitutes a legal domain. The most prominent example is the Simple Mail Transfer Protocol (SMTP) to deliver electronic mail. It requires at least two labels in the FQDN of a mail address. Thus standard-compliant mail servers would reject emails to addresses such as user at brand." I'm not seeing this requirement/limitation in RFC 5321. It merely requires an FQDN. Does anyone have an explanation for the assessment in the ICANN report that at least two levels are required?' John Levine commented that "they goofed". Tony Finch commented that ICANN may have looked at RFC 2821. John Levine posted a comment to the IETF discussion mailing list: "The only reason this has come up is that one (1) of the 1900 new TLD applications has asked for a waiver to do a dotless domain, and that applicant happens to be Google applying for .SEARCH. ICANN can just say no. Or they might not even have to, since Google's is only one of four competing applicants for .SEARCH, and there is no reason to assume that they would necessarily be the winner at the end of the negotiations." The context in the Abstract is similar to what John Levine wrote. It's in the -00 version as that was, according to John Levine, the reason why the discussion started. Jiankang Yao commented that: "With the explosive growth of new TLD names in ICANN or in DNS zone, it is reasonable to push this draft or similar idea." and made a suggestion to combine his draft and mine. In my opinion Jiankang understood that the my draft was about application protocols. Regards, S. Moonesamy From nico@cryptonector.com Mon Sep 23 11:38:01 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 255E621F9C3A for ; Mon, 23 Sep 2013 11:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.827 X-Spam-Level: X-Spam-Status: No, score=-1.827 tagged_above=-999 required=5 tests=[AWL=-0.149, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kEDAOggNamqF for ; Mon, 23 Sep 2013 11:37:49 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 0454C21F8EA8 for ; Mon, 23 Sep 2013 11:37:49 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTP id DB0E42C806B for ; Mon, 23 Sep 2013 11:37:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=kM011iqcNckr3phBHt4IQwmKWC4=; b=Lt9Nls0okgn 8uXvtaJPpmj5oFncBvIoTj/lZy0kU17bRa5y5No2cznLt4nvTFSxlbVkKRoAFV7H f7EYEDwjObLNdCkGs9InbgXzAfx/IOBirAgo2ZEG8CbzZAHY31sOzz4Zre72pR+h QDmYdSBwXRaT9RoB226/xnveH8rj6ETE= Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTPSA id 752012C806E for ; Mon, 23 Sep 2013 11:37:34 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id u16so7050160iet.39 for ; Mon, 23 Sep 2013 11:37:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=3tZwn8AI2S+II4FQSYIwTh97KLAGRcE3QHFdFNSa4hQ=; b=RYn1tzDPinMa31R2XA8klhMPn1jOWD1j3H/S5sjcS4FGoFzX4mA6wF0gWqjvrYDdPr BfiAZ+rAU/s0gr/DefiqCdZs+MRIrdVatV8gx1jQ/xQeDaI3UqtAjQF4HOCHRyY41pI0 xsabB+YGyWOl22UBvWQmh/0x4gnaiXjJs4rWeywvLt4fdworaSehId294k4OSm1lrnYQ VwuZ6+1SJvShSaKn7CeXsXoTPhN1MvBvSjIfismCYE9k8gd6px7CKJEovCoPYRWcsKUK +agTLzwCYvn+VVOn7MmACUWDfKwbkAXAO9OY4fONhHu86o1geUP1oqJOC3vgNkQxqvel q+9Q== MIME-Version: 1.0 X-Received: by 10.42.30.143 with SMTP id v15mr14090317icc.24.1379961449539; Mon, 23 Sep 2013 11:37:29 -0700 (PDT) Received: by 10.64.128.225 with HTTP; Mon, 23 Sep 2013 11:37:29 -0700 (PDT) In-Reply-To: <523FF238.6000200@it.aoyama.ac.jp> References: <20130922001440.GA11751@gmail.com> <523FF238.6000200@it.aoyama.ac.jp> Date: Mon, 23 Sep 2013 13:37:29 -0500 Message-ID: From: Nico Williams To: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Unicode normalization and Content-Disposition filename (RFC6266) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 18:38:01 -0000 On Mon, Sep 23, 2013 at 2:48 AM, "Martin J. D=C3=BCrst" wrote: > On 2013/09/22 9:14, Nico Williams wrote: > >> - HFS+ normalizes to NFD on CREATE (and on LOOKUP IIRC); > > Please be careful. As far as I'm aware, this is a form closer to NFD than= to > NFC, but not identical to NFD. You're right, and the differences are described here: https://developer.apple.com/legacy/library/technotes/tn/tn1150.html#Unicode= Subtleties The key point, however, is that there is a noticeable difference between what OS X (and Windows, and *nix, and probably every) input modes produce and what HFS+ produces. If you run "touch fo=C3=B3" in a shell and then move/copy that to a filesystem that doesn't normalize on lookup then a subsequent "ls fo=C3=B3" will fail. I know because I tried and blogged about this back in 2006[*]. This is, in fact, what led us to add form-insensitive/form-preserving functionality to ZFS (or at least it's what caused me to push for it). I find the explanation given for why HFS+ decomposes characters in filenames confusing: "To reduce complexity in the B-tree key comparison routines (which have to compare Unicode strings), HFS Plus defines that Unicode strings will be stored in fully decomposed form, with composing characters stored in canonical order." The use of *any* canonical form would permit the use of memcmp() semantics in the B-tre key comparator. Clearly using a form that more closely matches the input modes' output form would have been better for interoperability. There must be subtleties that are not described, such as trade-offs in string size vs normalization performance (NFC is specified as a two stage process the first of which is decomposition, therefore NFD requires less computation than NFC), and/or memcmp() collation (which will be different for NFC and NFD). In the case of ZFS we optimized for mostly-ASCII filenames, so that the comparator compares by sliding two-byte windows one byte down in its fast path, branching to a slow path when a difference involves at least one byte value outside the ASCII range. The ZFS slow path normalizes one character at a time, so as to avoid allocation. This is used both, where ZFS compares strings and where it hashes them. [8] http://cryptonector.com/2006/12/filesystem-i18n/ Nico -- From jasnell@gmail.com Mon Sep 23 12:17:23 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A410321F9D5D for ; Mon, 23 Sep 2013 12:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KkWBiGwfdsU8 for ; Mon, 23 Sep 2013 12:17:23 -0700 (PDT) Received: from mail-vc0-x229.google.com (mail-vc0-x229.google.com [IPv6:2607:f8b0:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 2A7DE21F9CCC for ; Mon, 23 Sep 2013 12:17:23 -0700 (PDT) Received: by mail-vc0-f169.google.com with SMTP id ib11so2554966vcb.14 for ; Mon, 23 Sep 2013 12:17:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=3WiUw7wX821uGF5SJ6yPgLxeGHrofmooYPHwX00X+eo=; b=NGu0k9EOXGlixamx6JIillRNKszfPznDoEdSHA0rNdse33sUIxfc8it/gfIsq61VzE 5ciPSIrdG1ixz5FJJRdHe9nS8Qa/QDPD6L7yHyEuf0HKi1ymm96UXfd4QSi2J+jWBU5R awVDJKjEyLs78U0JFFy8MOjz4IUFfAPGgPVXWSRtpyJoO3nLX9BcI632MW0Yy34QeJXS Neg07867Q8zTp0IJoLkyt6lU2uMxdnMahnXk5cc0bayK15r6cO0XuzD9RRAGug70rOUp +0n8J8gTvE3hgA+EbRgEosapOfEjHd5AuXhJDd7Xlt7RXoB6D+lQvp6NHuQ8XJHweFsU A3og== X-Received: by 10.220.174.200 with SMTP id u8mr23469514vcz.6.1379963842656; Mon, 23 Sep 2013 12:17:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.47.8 with HTTP; Mon, 23 Sep 2013 12:17:02 -0700 (PDT) From: James M Snell Date: Mon, 23 Sep 2013 12:17:02 -0700 Message-ID: To: "ietf-http-wg@w3.org" , IETF Apps Discuss Content-Type: text/plain; charset=UTF-8 Subject: [apps-discuss] FYI: LINK and UNLINK X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 19:17:23 -0000 Just a general FYI... I have submitted iteration -04 of the LINK/UNLINK draft with a few minor editorial fixes... and, I have formally requested Last Call status as an Independent Submission on the Standards Track. http://tools.ietf.org/html/draft-snell-link-method-04 - James From pierre@nothos.net Mon Sep 23 14:49:55 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A21021F9F97 for ; Mon, 23 Sep 2013 14:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.39 X-Spam-Level: X-Spam-Status: No, score=-0.39 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cIK5Q0561GNZ for ; Mon, 23 Sep 2013 14:49:48 -0700 (PDT) Received: from smtp.smtpout.orange.fr (smtp08.smtpout.orange.fr [80.12.242.130]) by ietfa.amsl.com (Postfix) with ESMTP id 1C6FC21F9FAE for ; Mon, 23 Sep 2013 14:49:43 -0700 (PDT) Received: from pthierry.pck.nerim.net ([90.48.179.147]) by mwinf5d43 with ME id Ulpf1m0023BCBhE03lpfWC; Mon, 23 Sep 2013 23:49:41 +0200 Received: by pthierry.pck.nerim.net (Postfix, from userid 1000) id ECDBC180092; Mon, 23 Sep 2013 23:49:38 +0200 (CEST) Date: Mon, 23 Sep 2013 23:49:38 +0200 From: Pierre Thierry To: apps-discuss@ietf.org Message-ID: <20130923214938.GE10268@pape.arcanes.fr.eu.org> References: <20130716195803.9658.64560.idtracker@ietfa.amsl.com> <20130909154432.GA22605@amoureux.home> <81194C29-85CB-4E4A-935A-4503B021DE26@tzi.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oFbHfjnMgUMsrGjO" Content-Disposition: inline In-Reply-To: <81194C29-85CB-4E4A-935A-4503B021DE26@tzi.org> X-Operating-System: Debian GNU/Linux User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [apps-discuss] High-volume benchmark (was Re: cbor-05) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2013 21:49:55 -0000 --oFbHfjnMgUMsrGjO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Scribit Carsten Bormann dies 09/09/2013 hora 17:53: > What kind of application do you have in mind? Maybe I can come up > with a better, more tailored benchmark for that. I actually don't, I'm wondering if formats like CBOR, BULK or BSON would fare differently and how. I suspect that a high-volume benckmark should include trivial calculations to ensure correctness but that it also should avoid storing any data to avoid storage to interfere with measurements. Although to be fair, multiple benchmarks would probably be necessary: at least pure reading speed (calculate only) and throughput (where the program both reads and writes serialized data). Curiously, Pierre Thierry --=20 pierre@nothos.net OpenPGP 0xD9D50D8A --oFbHfjnMgUMsrGjO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlJAt3IACgkQxe13INnVDYpL7QCfekbNxS979taYfhvj3ebdCzfh t4MAn3RY/TASnf2nnHIdDRX27fR/lV1b =M9KF -----END PGP SIGNATURE----- --oFbHfjnMgUMsrGjO-- From salvatore.loreto@ericsson.com Mon Sep 23 22:40:35 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E2C021F8201 for ; Mon, 23 Sep 2013 22:40:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.979 X-Spam-Level: X-Spam-Status: No, score=-104.979 tagged_above=-999 required=5 tests=[AWL=1.269, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dum-ARpm6ni1 for ; Mon, 23 Sep 2013 22:40:22 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id B21D011E80D1 for ; Mon, 23 Sep 2013 22:40:21 -0700 (PDT) X-AuditID: c1b4fb2d-b7f738e000003ee3-af-524125c4e39a Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 0A.A6.16099.4C521425; Tue, 24 Sep 2013 07:40:20 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.183.149) by smtp.internal.ericsson.com (153.88.183.32) with Microsoft SMTP Server id 14.2.328.9; Tue, 24 Sep 2013 07:40:19 +0200 Received: from Salvatore-Loretos-MacBook-Pro.local (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id C2BDF110455; Tue, 24 Sep 2013 08:40:19 +0300 (EEST) Message-ID: <524125C3.3040701@ericsson.com> Date: Tue, 24 Sep 2013 08:40:19 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------060005010108060500060302" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFLMWRmVeSWpSXmKPExsUyM+Jvre4RVccgg1VvpSxWv1zBZjF97zV2 ByaPtd1X2TyWLPnJFMAUxWWTkpqTWZZapG+XwJXxbdYS5oIWyYoZ7S9YGxibhLsYOTkkBEwk vq7fzw5hi0lcuLeerYuRi0NI4DCjxIIte6GcDYwSCy9+YodwjjFKfL+0B6yFV0BbYuednywg NouAqkRr+3RGEJtNwEzi+cMtzCC2qECyRNPl+ywQ9YISJ2c+AbNFBKQlWg7dBKtnFtCX2D/t OBOILSxgKvHo5zawXiGBAIl7HyewgticAoESLx9NZYKoD5O4vX4FC0SNlkTv2U6mCYyCs5Cs mIWkDMK2lbgw5zqULS+x/e0cZghbV+LC/yko4gsY2VYxsucmZuaklxtuYgSG98Etv3V3MJ46 J3KIUZqDRUmcd5PemUAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjDMkdvZa1O/uEn37t0Gn zfCO1rlJq+rUOu41qZ/cm3vScsmG5QIfdoVJPlp8Jq6zpDgiKFXY3V8pZtXr/dP35l3NnB08 pXjhynXN8+oaW7kUBT3lm3hKNl5/17iu9fO+qPopKZpm3guSWMw1E39/Oh/Lfks/lOPhM8tF jnyy2TMmPC5l9Ve+rMRSnJFoqMVcVJwIAFtRh689AgAA Subject: [apps-discuss] IETF88 session focused on SECURITY from APP? X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 05:40:35 -0000 --------------060005010108060500060302 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Hi there, it has been proposed to focus part of the 2.5-hours meeting on a subject, specifically on Security from the APP point of view of course. We are already working on the agenda, so if you have any specific item please contact us. -Salvatore, APPSAWG co-chair On 9/23/13 9:01 PM, Murray S. Kucherawy wrote: > Colleagues, > > I've submitted a request for our usual 2.5-hour Monday morning slot. > I'll advise when it's been formally scheduled. > > We are still accepting agenda items. We're a month away from having > to settle on that, so there's still time, but please don't wait until > the last minute as we may not be able to accommodate your request if > you do. > > -MSK, APPSAWG co-chair > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --------------060005010108060500060302 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
Hi there,

it has been proposed to focus part of the 2.5-hours meeting on a subject,
specifically on Security from the APP point of view of course.

We are already working on the agenda,
so if you have any specific item please contact us.

-Salvatore, APPSAWG co-chair


On 9/23/13 9:01 PM, Murray S. Kucherawy wrote:
Colleagues,

I've submitted a request for our usual 2.5-hour Monday morning slot.  I'll advise when it's been formally scheduled.

We are still accepting agenda items.  We're a month away from having to settle on that, so there's still time, but please don't wait until the last minute as we may not be able to accommodate your request if you do.

-MSK, APPSAWG co-chair



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

--------------060005010108060500060302-- From ht@inf.ed.ac.uk Tue Sep 24 02:19:33 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F9EC11E80D5 for ; Tue, 24 Sep 2013 02:19:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.392 X-Spam-Level: X-Spam-Status: No, score=-5.392 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3cFvzHJWe4LL for ; Tue, 24 Sep 2013 02:19:28 -0700 (PDT) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id 1E83921F9E45 for ; Tue, 24 Sep 2013 02:19:26 -0700 (PDT) Received: from crunchie.inf.ed.ac.uk (crunchie.inf.ed.ac.uk [129.215.33.180]) by treacle.ucs.ed.ac.uk (8.13.8/8.13.4) with ESMTP id r8O9JAFB025914 for ; Tue, 24 Sep 2013 10:19:15 +0100 (BST) Received: from troutbeck.inf.ed.ac.uk (troutbeck.inf.ed.ac.uk [129.215.25.32]) by crunchie.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id r8O9J9i3026085 for ; Tue, 24 Sep 2013 10:19:09 +0100 Received: from troutbeck.inf.ed.ac.uk (localhost [127.0.0.1]) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4) with ESMTP id r8O9JAS6018083 for ; Tue, 24 Sep 2013 10:19:10 +0100 Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id r8O9J9Rh018079; Tue, 24 Sep 2013 10:19:09 +0100 X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: apps-discuss@ietf.org From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Tue, 24 Sep 2013 10:19:08 +0100 Message-ID: User-Agent: Gnus/5.101 (Gnus v5.10.10) XEmacs/21.5-b33 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Edinburgh-Scanned: at treacle.ucs.ed.ac.uk with MIMEDefang 2.60, Sophie, Sophos Anti-Virus, Clam AntiVirus X-Scanned-By: MIMEDefang 2.60 on 129.215.16.102 Subject: [apps-discuss] Priority of in-band vs. out-of-band encoding information X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 09:19:33 -0000 In reviewing the relationship between draft-ietf-appsawg-xml-mediatypes and the XML specification itself, I was reminded that the XML spec. defers to "RFC3023 or successor" with respect to the relative priority of the charset parameter and any available document-internal information about character encoding (BOM and/or the XML encoding declaration). Empirical evidence suggests that wrt both XML and HTML media types, web browsers give priority to a BOM. That is, if the body of an HTTP response begins with a BOM, it is treated as authoritative and any charset parameter in a Content-Type header is ignored. The current draft of the HTML5 spec. makes this explicit. Is anyone aware of any existing media type registration or other RFC which addresses this issue explicitly? Thanks, ht -- Henry S. Thompson, School of Informatics, University of Edinburgh 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail from me _always_ has a .sig like this -- mail without it is forged spam] From Ray.Bellis@nominet.org.uk Tue Sep 24 08:54:18 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 015B511E816F; Tue, 24 Sep 2013 08:54:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.062 X-Spam-Level: X-Spam-Status: No, score=-10.062 tagged_above=-999 required=5 tests=[AWL=0.537, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K8ulfM+I3JGK; Tue, 24 Sep 2013 08:54:12 -0700 (PDT) Received: from mx2.nominet.org.uk (mx2.nominet.org.uk [213.248.242.49]) by ietfa.amsl.com (Postfix) with ESMTP id E042B11E8169; Tue, 24 Sep 2013 08:54:11 -0700 (PDT) DomainKey-Signature: s=main2.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:X-IPAS-Result:Received:Received:From:To:CC: Subject:Thread-Topic:Thread-Index:Date:Message-ID: References:In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: Content-Type:Content-ID:Content-Transfer-Encoding: MIME-Version; b=WYvKq7LKGgVCxDz6w1d9jEaVwBJVuPwJZE+LxAT0BTwauN7bDo1kxmCD eeqkniww/zpv1051pMFk9bVDZDCkladrcNiPXC224lqPmPmIjKkwJ0n5p TyA5vN0cS4tr+UHXT8znY1Dp4kJVETci4oN3Vr0LVAnB7GXhytHt6FwyD 2wklxPhQyUSIqZ9gDCV2OAnmWaBnTJkEPhN8JxafyIQIaWWOJSy0QlUXs 9Dv2Gt85ajnN0JXgBwpAM0RUyK0ty; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=@nominet.org.uk; q=dns/txt; s=main2.dkim.nominet.selector; t=1380038052; x=1411574052; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=NLCLygHgR70zNruXpkwtS3Juru8pap47iOrpIRQi9zU=; b=YSoRheN20MnbjiBKzcPItpd32i4MzbE2+EYCVETj95JPo+ZKASrReD7E 4eGPJ4l3WBAenFz5JbsT1zARoenOv+KMzj8wZrxXMiYNZJHrRK86LyvBJ wUC/HsBbNdey29JuSXJ6PZoD9+5yLCPH58lNaKrNecQNY7HyJpQ/sWSVZ JOXYI8aZ0DGsDAjiq4FyHhta44FTOE86j63HY/u6KxV+f1sBZHh4iNp1c 6xRW5/SY8BMJpC4IvzRNaDK6CSTGh; X-IronPort-AV: E=Sophos;i="4.90,971,1371078000"; d="scan'208";a="3240656" X-IPAS-Result: AgkFAE60QVLV+MWR/2dsb2JhbABagmYhgQrAToEfFnSCJQEBAQECAToZIQUQAgEIEgYKFBAyFw4CBA4FCId3BwO9NI8eAjEHgx2BAAOpc4Mkgio Received: from wds-exc2.okna.nominet.org.uk ([213.248.197.145]) by mx2.nominet.org.uk with ESMTP; 24 Sep 2013 16:54:09 +0100 Received: from WDS-EXC1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f]) by wds-exc2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4%17]) with mapi id 14.02.0318.004; Tue, 24 Sep 2013 16:54:09 +0100 From: Ray Bellis To: Michael Richardson Thread-Topic: [homenet] APPSDIR review of draft-ietf-homenet-arch-10 Thread-Index: AQHOtXB/eUFBBvqySkGVj7Xr8gt0B5nOwYqAgAY+K4CAAAFCgA== Date: Tue, 24 Sep 2013 15:54:08 +0000 Message-ID: <53F00E5CD8B2E34C81C0C89EB0B4FE732DEB122E@wds-exc1.okna.nominet.org.uk> References: <6.2.5.6.2.20130914143222.0b9590f0@elandnews.com> <6.2.5.6.2.20130918225335.0d0e2478@elandnews.com> <6.2.5.6.2.20130919074156.0cd2d900@elandnews.com> <3105F809-7E03-41D9-A634-DE32446FB19B@nominum.com> <89570788-2319-4922-B8DD-4359349683F7@ecs.soton.ac.uk> <19897.1380037779@sandelman.ca> In-Reply-To: <19897.1380037779@sandelman.ca> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.1] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , S Moonesamy , Tim Chown , The IESG , "" , "homenet@ietf.org Group" , Ted Lemon Subject: Re: [apps-discuss] [homenet] APPSDIR review of draft-ietf-homenet-arch-10 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 15:54:18 -0000 On 24 Sep 2013, at 16:49, Michael Richardson wrote: >=20 > Tim Chown wrote: > tim> Do we want to spend more time now, given the desire to move ahead > tim> with the > tim> other work, restructuring the arch doc? It could be done, but I > tim> wonder whether >=20 > I am opposed to any restructuring. I am in favour of two rounds of exter= nal > tweaks. I believe that by addressing the review now, we will avoid doing > further work at IESG stage, and that's what the directorates are about. >=20 > tim> And the title? Well, personally I have no emotional attachment to > tim> the current > tim> title. If the IESG were to say let's rename it "Networking > tim> Principles for > tim> Future IPv6 Home Networks" then I would lose no sleep. >=20 > That's not the name I would pick. I think it is too weak: there is > significant design decisions made. We have something which is much more = than > requirements, but not quite architectural. >=20 > In *building* terms (where we think we know the waterfall process of > architecture, civil, structure engineering, and construction planning, bu= t > really we are wrong. It's way more complex than we think)... >=20 > We know how many stories the building will have... but it might be that > putting the highest efficiency HVAC on the roof will reduce that by one= . > We know that the building will have a glass exterior, but the exact > dimensions of the panes is not yet known, estetically and weight wise, it= 's > understood, and they won't be mirrored because the neighbours won't like > that... but there are seismic considerations, and a new city bylaw on > mitigation of falling glass... (to make some stuff up) So would you consider what we have now to be a "framework" ? Ray From Ted.Lemon@nominum.com Tue Sep 24 09:02:01 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95B9D21F9985; Tue, 24 Sep 2013 09:01:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.527 X-Spam-Level: X-Spam-Status: No, score=-106.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qWvfSw-fBdrY; Tue, 24 Sep 2013 09:01:47 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id E431411E816D; Tue, 24 Sep 2013 09:01:08 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKUkG3Q5vX/zadL7vvWKBvRJVbRRhl0MTH@postini.com; Tue, 24 Sep 2013 09:01:09 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 83E6B1B82E1; Tue, 24 Sep 2013 09:01:07 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 23DCE19006E; Tue, 24 Sep 2013 09:01:06 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from [10.0.10.40] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 24 Sep 2013 09:01:06 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1811\)) From: Ted Lemon In-Reply-To: <14439.1380035891@sandelman.ca> Date: Tue, 24 Sep 2013 12:01:03 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <76716D93-E946-4682-BE1C-CF2DC0434CE5@nominum.com> References: <6.2.5.6.2.20130914143222.0b9590f0@elandnews.com> <6.2.5.6.2.20130918225335.0d0e2478@elandnews.com> <14439.1380035891@sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1811) X-Originating-IP: [192.168.1.10] Cc: "" , S Moonesamy , Tim Chown , The IESG , draft-ietf-homenet-arch.all@tools.ietf.org, "homenet@ietf.org Group" Subject: Re: [apps-discuss] [homenet] APPSDIR review of draft-ietf-homenet-arch-10 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 16:02:02 -0000 On Sep 24, 2013, at 11:18 AM, Michael Richardson = wrote: > I believe that perhaps the title is now wrong. > I think that it should say: > "Requirements for Home Networking for IPv6" >=20 > (But, it's really more than requirements. It's just less than = architecture) I previously suggested "Preliminary architecture ..." Would that = address your concern? I don't think it's precisely a requirements = document; the document does what the working group currently needs it to = do, and I would hate to see us spend another couple of meeting cycles = turning it into a formal requirements document unless someone can make a = clear argument that doing so is necessary. From scott.brim@gmail.com Tue Sep 24 09:16:33 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E69D21F9BF7; Tue, 24 Sep 2013 09:16:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.528 X-Spam-Level: X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5WQ9+lpVCu+J; Tue, 24 Sep 2013 09:16:32 -0700 (PDT) Received: from mail-oa0-x235.google.com (mail-oa0-x235.google.com [IPv6:2607:f8b0:4003:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 22DD321F9BFA; Tue, 24 Sep 2013 09:16:32 -0700 (PDT) Received: by mail-oa0-f53.google.com with SMTP id i7so2432197oag.12 for ; Tue, 24 Sep 2013 09:16:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FIqj3HOFPaJ6w2eLTDoHEchUqitwr43Ce16S3ivOpW4=; b=vMUsQP+uFQYurl/SdKfoyze2M3UU+vOc2iuyv4oZ+rof4oXQRDqoSf8RcayZo9KuiL OjY1pu0nrDfVczXYDI24hCxV4yPUXMWrKvCp41m5aQRGc6jIeOxRKxFx8lyPXAf2msL1 aIaBKQuaJNLBpVCE/1qqmgIHfc03qhOF1ElsABQ5PqzuOyXhiB/+jswhIVvDjP+EiG9y nzioffoQP7i7+1maZzGLeSnx0T0f2HzezdG20BMiArQvuYjLHBOYQbSJL+mc8mXUSJdo GpnIzqaMnAOeCN/I5kEZS7DPiezf+ik7KPp53V0sItZjej0QGa7YgezTPRft1p+Hf3gT 07AQ== MIME-Version: 1.0 X-Received: by 10.182.241.33 with SMTP id wf1mr2023404obc.59.1380039391446; Tue, 24 Sep 2013 09:16:31 -0700 (PDT) Received: by 10.182.2.134 with HTTP; Tue, 24 Sep 2013 09:16:31 -0700 (PDT) Received: by 10.182.2.134 with HTTP; Tue, 24 Sep 2013 09:16:31 -0700 (PDT) In-Reply-To: <76716D93-E946-4682-BE1C-CF2DC0434CE5@nominum.com> References: <6.2.5.6.2.20130914143222.0b9590f0@elandnews.com> <6.2.5.6.2.20130918225335.0d0e2478@elandnews.com> <14439.1380035891@sandelman.ca> <76716D93-E946-4682-BE1C-CF2DC0434CE5@nominum.com> Date: Tue, 24 Sep 2013 12:16:31 -0400 Message-ID: From: Scott Brim To: Ted Lemon Content-Type: multipart/alternative; boundary=001a11c2fc20b41fa304e72375b7 Cc: "<, apps-discuss@ietf.org>, " , Michael Richardson , S Moonesamy , Tim Chown , IESG IESG , draft-ietf-homenet-arch.all@tools.ietf.org, "homenet@ietf.org Group" Subject: Re: [apps-discuss] [homenet] APPSDIR review of draft-ietf-homenet-arch-10 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 16:16:33 -0000 --001a11c2fc20b41fa304e72375b7 Content-Type: text/plain; charset=ISO-8859-1 Architectural overview? On Sep 24, 2013 12:02 PM, "Ted Lemon" wrote: > On Sep 24, 2013, at 11:18 AM, Michael Richardson > wrote: > > I believe that perhaps the title is now wrong. > > I think that it should say: > > "Requirements for Home Networking for IPv6" > > > > (But, it's really more than requirements. It's just less than > architecture) > > I previously suggested "Preliminary architecture ..." Would that address > your concern? I don't think it's precisely a requirements document; the > document does what the working group currently needs it to do, and I would > hate to see us spend another couple of meeting cycles turning it into a > formal requirements document unless someone can make a clear argument that > doing so is necessary. > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --001a11c2fc20b41fa304e72375b7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Architectural overview?

On Sep 24, 2013 12:02 PM, "Ted Lemon" = <ted.lemon@nominum.com> = wrote:
On Sep 24, 2013, at 11:18 AM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
> I believe that perhaps the title is now wrong.
> I think that it should say:
> =A0 =A0"Requirements for Home Networking for IPv6"
>
> (But, it's really more than requirements. It's just less than = architecture)

I previously suggested "Preliminary architecture ..." =A0 Would t= hat address your concern? =A0 I don't think it's precisely a requir= ements document; the document does what the working group currently needs i= t to do, and I would hate to see us spend another couple of meeting cycles = turning it into a formal requirements document unless someone can make a cl= ear argument that doing so is necessary.

_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss
--001a11c2fc20b41fa304e72375b7-- From brian.e.carpenter@gmail.com Tue Sep 24 16:04:48 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA12F11E8183; Tue, 24 Sep 2013 16:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NSeEgI0FsOIe; Tue, 24 Sep 2013 16:04:48 -0700 (PDT) Received: from mail-pb0-x236.google.com (mail-pb0-x236.google.com [IPv6:2607:f8b0:400e:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 2102D11E8186; Tue, 24 Sep 2013 16:04:47 -0700 (PDT) Received: by mail-pb0-f54.google.com with SMTP id ro12so5236783pbb.27 for ; Tue, 24 Sep 2013 16:04:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=qrDohcqREBBlnCqm4m+NRy0apFHOoiKxSkD9O05KQMY=; b=W7OL+VhGPCqXkYuMZKuRSBGm7Znq53m9YThoQuO6VKbuq6dWPq/uJaHPUzTNtriAix yb/pouovRUR4lYr4OYPBT6UjrKfREE26mfx1ISkm/XFelkpm7yRErJ5Fxvr5Wbts1XRe eZZHDvKBamyGdpljCV5x4rQ7D7k8teT8tu/zd4wZY1cmuXd9LhBzb/+42P7FvFSdpkjO axuBmiLxkmUR+uUbRIqYQaa9sL7Fn0SagIN91FYNY+Ovn3+wyhnWp9dMd5CRzctmnmc+ xdU6gwGOKqo+LkxW4C9ms5T5+H7gBy5yVGvmQF5OfAbml9mWkInrFlYRiuXQBOrW0bId 3Tyg== X-Received: by 10.67.11.103 with SMTP id eh7mr8804229pad.153.1380063887545; Tue, 24 Sep 2013 16:04:47 -0700 (PDT) Received: from [172.24.31.170] (wireless-nat-1.auckland.ac.nz. [130.216.30.112]) by mx.google.com with ESMTPSA id xe9sm48500004pab.0.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 24 Sep 2013 16:04:46 -0700 (PDT) Message-ID: <52421A8F.2090603@gmail.com> Date: Wed, 25 Sep 2013 11:04:47 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Ted Lemon References: <6.2.5.6.2.20130914143222.0b9590f0@elandnews.com> <6.2.5.6.2.20130918225335.0d0e2478@elandnews.com> <14439.1380035891@sandelman.ca> <76716D93-E946-4682-BE1C-CF2DC0434CE5@nominum.com> In-Reply-To: <76716D93-E946-4682-BE1C-CF2DC0434CE5@nominum.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "" , Michael Richardson , S Moonesamy , Tim Chown , The IESG , draft-ietf-homenet-arch.all@tools.ietf.org, "homenet@ietf.org Group" Subject: Re: [apps-discuss] [homenet] APPSDIR review of draft-ietf-homenet-arch-10 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 23:04:49 -0000 On 25/09/2013 04:01, Ted Lemon wrote: > On Sep 24, 2013, at 11:18 AM, Michael Richardson wrote: >> I believe that perhaps the title is now wrong. >> I think that it should say: >> "Requirements for Home Networking for IPv6" >> >> (But, it's really more than requirements. It's just less than architecture) > > I previously suggested "Preliminary architecture ..." Would that address your concern? I don't think it's precisely a requirements document; the document does what the working group currently needs it to do, and I would hate to see us spend another couple of meeting cycles turning it into a formal requirements document unless someone can make a clear argument that doing so is necessary. Both 'framework' and 'architecture' mean different things to different people. I could say the same about 'guidelines' too. It doesn't matter which of these vague words we use. 'Preliminary architecture' is fine. Just make sure that the abstract and introduction set the reader's expectations correctly, which judging by SM's review is not quite the case yet. Brian From scott.brim@gmail.com Tue Sep 24 16:08:27 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8A8C11E8186; Tue, 24 Sep 2013 16:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eElzaXRUwXJS; Tue, 24 Sep 2013 16:08:27 -0700 (PDT) Received: from mail-oa0-x231.google.com (mail-oa0-x231.google.com [IPv6:2607:f8b0:4003:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id DA6A611E80F8; Tue, 24 Sep 2013 16:08:26 -0700 (PDT) Received: by mail-oa0-f49.google.com with SMTP id i4so87796oah.36 for ; Tue, 24 Sep 2013 16:08:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ggm8u+26nbFfvk7PdynFKG0i9ywtfPBgI41kZQTe7qc=; b=oJ0+QTtLzOXKH6lgjo7o3EbfDYQl34f7S+IK39Aevi6Pyy5/Hqb3N+GxdzEVEZSC9L 8nDn7jWuz0Asdd/59aRneuHvK3kFbtTmivYlC4obQOguysQGt0WAsv+DvUKGoYlufd0A 26/VHTbTOgfFLe2Hd96i6mkwnjqX68rHxK6QuEMA2l/dAEeT5vTLIlbxMUhnAPs24c/e 1a4QmWHzM1WGJWOHtFxO7tiERy+7Kdg7lFxnwRAZ4QfsChcHm77r1mpUA85RtbuZ1hpe AVd4/KUdY7hCNjllcRI53FkYuQdKQbnnOeW/1IKV06WnRN3UFCrBKVDmiEuGNItfHNTa nQOQ== MIME-Version: 1.0 X-Received: by 10.182.99.231 with SMTP id et7mr27634777obb.10.1380064099963; Tue, 24 Sep 2013 16:08:19 -0700 (PDT) Received: by 10.182.2.134 with HTTP; Tue, 24 Sep 2013 16:08:19 -0700 (PDT) Received: by 10.182.2.134 with HTTP; Tue, 24 Sep 2013 16:08:19 -0700 (PDT) In-Reply-To: <52421A8F.2090603@gmail.com> References: <6.2.5.6.2.20130914143222.0b9590f0@elandnews.com> <6.2.5.6.2.20130918225335.0d0e2478@elandnews.com> <14439.1380035891@sandelman.ca> <76716D93-E946-4682-BE1C-CF2DC0434CE5@nominum.com> <52421A8F.2090603@gmail.com> Date: Tue, 24 Sep 2013 19:08:19 -0400 Message-ID: From: Scott Brim To: Brian Carpenter Content-Type: multipart/alternative; boundary=089e0158a92e721ad804e72936bb Cc: "<, apps-discuss@ietf.org>, " , Michael Richardson , S Moonesamy , Tim Chown , Ted Lemon , draft-ietf-homenet-arch.all@tools.ietf.org, "homenet@ietf.org Group" , The IESG Subject: Re: [apps-discuss] [homenet] APPSDIR review of draft-ietf-homenet-arch-10 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 23:08:27 -0000 --089e0158a92e721ad804e72936bb Content-Type: text/plain; charset=ISO-8859-1 I propose Architecture Overview. On Sep 24, 2013 7:04 PM, "Brian E Carpenter" wrote: > On 25/09/2013 04:01, Ted Lemon wrote: > > On Sep 24, 2013, at 11:18 AM, Michael Richardson > wrote: > >> I believe that perhaps the title is now wrong. > >> I think that it should say: > >> "Requirements for Home Networking for IPv6" > >> > >> (But, it's really more than requirements. It's just less than > architecture) > > > > I previously suggested "Preliminary architecture ..." Would that > address your concern? I don't think it's precisely a requirements > document; the document does what the working group currently needs it to > do, and I would hate to see us spend another couple of meeting cycles > turning it into a formal requirements document unless someone can make a > clear argument that doing so is necessary. > > Both 'framework' and 'architecture' mean different things to different > people. I could say the same about 'guidelines' too. > > It doesn't matter which of these vague words we use. 'Preliminary > architecture' is fine. Just make sure that the abstract and introduction > set the reader's expectations correctly, which judging by SM's review > is not quite the case yet. > > Brian > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --089e0158a92e721ad804e72936bb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

I propose Architecture Overview.

On Sep 24, 2013 7:04 PM, "Brian E Carpenter= " <brian.e.carpenter= @gmail.com> wrote:
On 25/09/2013 04:01, Ted Lemon wrote:
> On Sep 24, 2013, at 11:18 AM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
>> I believe that perhaps the title is now wrong.
>> I think that it should say:
>> =A0 =A0"Requirements for Home Networking for IPv6"
>>
>> (But, it's really more than requirements. It's just less t= han architecture)
>
> I previously suggested "Preliminary architecture ..." =A0 Wo= uld that address your concern? =A0 I don't think it's precisely a r= equirements document; the document does what the working group currently ne= eds it to do, and I would hate to see us spend another couple of meeting cy= cles turning it into a formal requirements document unless someone can make= a clear argument that doing so is necessary.

Both 'framework' and 'architecture' mean different things t= o different
people. I could say the same about 'guidelines' too.

It doesn't matter which of these vague words we use. 'Preliminary architecture' is fine. Just make sure that the abstract and introductio= n
set the reader's expectations correctly, which judging by SM's revi= ew
is not quite the case yet.

=A0 =A0 Brian
_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss
--089e0158a92e721ad804e72936bb-- From paulej@packetizer.com Tue Sep 24 17:47:17 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AD9D11E819B; Tue, 24 Sep 2013 17:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f+kRwrRrj6pG; Tue, 24 Sep 2013 17:47:12 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 9212211E819A; Tue, 24 Sep 2013 17:47:12 -0700 (PDT) Received: from [192.168.1.20] (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r8P0l6Z0007371 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 24 Sep 2013 20:47:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1380070028; bh=n73/Ip7dNOFO6M3kpDsWJR6CEt4YGheX8PbrRenKq3Y=; h=From:To:Subject:Cc:Date:Content-Transfer-Encoding:Content-Type: In-Reply-To:Message-Id:Mime-Version:Reply-To; b=iI9I8LrX1vPEBWFbuix0N2UWV86PMIJlp4UC+Hnvtr1F3nL2PWTdAMs0pkuCKnFGe L98wcyqoCeElq2Z0n74GB4PQYH5S5JqG+BUkSQjn3YvGNKg+gzgUBEsdMPgohSfJeu qGPAjdiILAvQ/3uwpYdM/hsPGBaGKjRegpZvrm4E= From: "Paul E. Jones" To: "Vijay K. Gurbani" Date: Wed, 25 Sep 2013 00:47:12 +0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 In-Reply-To: <52405E5B.7080207@bell-labs.com> Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/5.0.18661.0 Cc: draft-ietf-insipid-session-id-reqts.all@tools.ietf.org, 'James Polk' , 'IESG IESG' , apps-discuss@ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-insipid-session-id-reqts-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "Paul E. Jones" List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 00:47:17 -0000 Vijay, Thanks for the additional feedback. I will consult with a few of the=20 folks in the WG to see how we can best address your points. Paul ------ Original Message ------ From: "Vijay K. Gurbani" To: "Paul E. Jones" Cc: draft-ietf-insipid-session-id-reqts.all@tools.ietf.org; "'James=20 Polk'" ; "'IESG IESG'" ;=20 apps-discuss@ietf.org Sent: 9/23/2013 11:29:31 AM Subject: Re: [apps-discuss] APPSDIR review of=20 draft-ietf-insipid-session-id-reqts-08 >On 09/20/2013 04:07 PM, Paul E. Jones wrote: >>Vijay, >> >>(My email client did not format that well. Let me try to correct=20 >>that...) >> >>I apologize for taking so long to get back to you. This has been an >>extremely busy week for me. > >Paul: No problem. Please see inline. > >>I understand. I wasn't trying to be combative. Rather, I'm just >>stating that I'm not sure what more is needed. Please don't assume I >>was being argumentative, as that certainly was not the intent. > >No worries; I just wanted to make sure that if you made any changes, >they would be driven by what you would also consider actual problems, >and not driven by just trying to placate me :-) > >>I cannot recall who introduced that language into that text, but the >>desire would be prevent two things: [...] >>The proposed remedies in that paragraph are to mandate REQ6 and >>encourage encryption. > >Right, it is the "encourage encryption" part that I think should garner >some attention. One way to do so is suggested below. > >>REQ5 does not, in itself, assume or require some kind of security. In=20 >>a >>trusted service provider network, for example, the value might be >>inserted at the edge by an SBC and no encryption used through the >>service provider domain. > >SIP has developed this notion of a trust domain as a set of SIP nodes, >including B2BUAs, that are trusted to exchange some private information >among (and between) themselves. This function goes by the wonderful >name of Spec(T) and is fully defined in rfc3324. Other pieces of work >[1,2] that forsee a need to define a trust domain simply use the >Spec(T) function to do so. > >>The required security differs based on the environment. As I mentioned >>above, a service provider domain may have minimal internal security >>requirements, placing all security at the edge. Likewise, the issues >>related to the Session-ID are not unlike those of the Call-ID. In=20 >>fact, >>an attack on the Call-ID or "To" header in SIP is far more problematic >>than an attack on the Session-ID. So, while I think most real-world >>implementations of SIP (ignoring Session-ID) should use TLS, at the=20 >>very >>least, we cannot insert a requirement for use of any particular=20 >>security >>mechanism. > >The Spec(T) mechanism at least allows you to state that you have >thought of the security ramifications of the header being sent out in >cleartext, and therefore, domains that wish to exchange the header in >non cleartext format should comply to Spec(T). You can define Spec(T) >as is done in [1], without having to delve into the mandating TLS or >choosing cipher specs for TLS. > >It seems appropriate that if we know that usurping the session >identifier will lead to problems then we at least try to provide a way >to mitigate these problems without mandating specific security=20 >policies. >I think Spec(T) allows you to do so. > >Regarding the statement that an attack on the Call-ID or "To" header >being more disruptive than an attack on Session-ID, sure I agree. But >at least we have rfc4474 to mitigate that (I understand it is not used >widely, but it *is* there). > >>I do not disagree, but I cannot insert a requirement into this text=20 >>that >>says TLS must be used. There may be folks who would oppose that. I >>think the particular means through which the requirements are met=20 >>should >>be spelled out only in the solution text. If you really disagree, we >>can go back to the WG and raise the point. I certainly have no >>objection to that. > >I am not privy to the discussions that happened in the working group >along making TLS mandatory. But from your description it seems that >the working group does not want to mandate it. Maybe couching the >security aspects in terms of Spec(T) will suffice? > >[1] See Section 5.4 of=20 >http://tools.ietf.org/html/draft-ietf-soc-load-control-event-package-09 >[2]=20 >http://tools.ietf.org/html/draft-vanelburg-dispatch-private-network-ind-02 > >Thanks, > >- vijay >-- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent >1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) >Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com >Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq From vkg@bell-labs.com Wed Sep 25 10:35:44 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF6C11E8132; Wed, 25 Sep 2013 10:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RPghGJlVgf5q; Wed, 25 Sep 2013 10:35:39 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 0C33F11E8131; Wed, 25 Sep 2013 10:35:31 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r8PHZTUf024524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 25 Sep 2013 12:35:30 -0500 (CDT) Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id r8PHZT4h020362 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 25 Sep 2013 12:35:29 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.237.229]) by umail.lucent.com (8.13.8/TPES) with ESMTP id r8PHZTBZ015591; Wed, 25 Sep 2013 12:35:29 -0500 (CDT) Message-ID: <52432012.9070104@bell-labs.com> Date: Wed, 25 Sep 2013 12:40:34 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130805 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Paul E. Jones" References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: draft-ietf-insipid-session-id-reqts.all@tools.ietf.org, 'James Polk' , 'IESG IESG' , apps-discuss@ietf.org Subject: Re: [apps-discuss] APPSDIR review of draft-ietf-insipid-session-id-reqts-08 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2013 17:35:44 -0000 On 09/24/2013 07:47 PM, Paul E. Jones wrote: > Vijay, > > Thanks for the additional feedback. I will consult with a few of the > folks in the WG to see how we can best address your points. Paul: Sure, no worries. Thanks for your time. - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq From sm@elandsys.com Wed Sep 25 13:38:04 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB8A21F9E3B for ; Wed, 25 Sep 2013 13:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5rFit+VhLgdY for ; Wed, 25 Sep 2013 13:38:02 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 62BF621F970E for ; Wed, 25 Sep 2013 13:38:01 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.132.253]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r8PKbhBu005346 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Sep 2013 13:37:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1380141475; bh=w22NQeGSdVWzBZ9Pg+JDas2Qb5oCekD4KzrO77ys0eQ=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=aqFs0d1NeJK4JC/uxe4Ddnv2BPj0dRFiMqyIlH5UJGv/HHKozgKEJen0tOZkL5Syp Z5t/qVsh40HovGN/mKW3A41+HUm1YwCE5smYQ9IntOr/r+HYZyojZ757Quo/tRxAGq 6M0rYkkcSRdLmx1UdxpnzwcgIKqtf7p0UvtHm3aM= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1380141475; i=@elandsys.com; bh=w22NQeGSdVWzBZ9Pg+JDas2Qb5oCekD4KzrO77ys0eQ=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=QRpAc3shHgjEC5o+HGk688BORKlk0X2cHbfktcyJbzNmIpbopcFKoOu5W4Lq226Hj D7V7BY7rf2TO37fg/rgjTAH0jHEbWfTMaap5qJ9LbjQBBDP7BMhytP2TNkiMHUFxrs ps74n2jzjdvMEPCjfhEc+re4AgfuV32UhfU5mH0o= Message-Id: <6.2.5.6.2.20130925133232.0d9f3070@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 25 Sep 2013 13:37:11 -0700 To: Ira McDonald , Pat Fleming From: S Moonesamy In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] Request for Apps Area review of LDAP Printer Schema (19 September 2013) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 20:38:04 -0000 Hi Ira, At 09:34 19-09-2013, Ira McDonald wrote: >The IEEE-ISTO PWG Internet Printing Protocol WG would like to request >IETF Apps Area review of our updated LDAP Printer Schema (updates >RFC 3712). > >http://www.ietf.org/internet-drafts/draft-mcdonald-ldap-printer-schema-05.txt > >Cheers, >- Ira (co-chair of IEEE-ISTO PWG IPP WG and co-editor of this document) This is an individual comment. From Section 1 of the draft: "This document is published by the IETF on behalf of the Internet Printing Protocol Working Group [PWGIPP] of the IEEE-ISTO Printer Working Group [PWG]." Is there an IETF working group which will adopt this draft so that it can be published as a RFC by the IETF? Regards, S. Moonesamy From blueroofmusic@gmail.com Wed Sep 25 14:34:52 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 314C321F99BD for ; Wed, 25 Sep 2013 14:34:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dDpx2wO9oXje for ; Wed, 25 Sep 2013 14:34:51 -0700 (PDT) Received: from mail-qe0-x22a.google.com (mail-qe0-x22a.google.com [IPv6:2607:f8b0:400d:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 5AAC021F98EE for ; Wed, 25 Sep 2013 14:34:51 -0700 (PDT) Received: by mail-qe0-f42.google.com with SMTP id 1so208163qec.29 for ; Wed, 25 Sep 2013 14:34:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=QFVhVGMSWn4LIkHwCrNOf2jygZfZQ7XyBbv+HbR4se8=; b=NEvf5gd0ARiLCNVv1r507aDEn0M3VR3Rz4NCbHc6pYyQRqNvHehvSwW82S2Rgu0voy XlsfIFdKVA5DUnZedrkofk3mu6J4pCJDX5k8ewOt20kBCFq+6ohf8uTj9RdR1rpON5uS Yb+9CQTD85LeMVvslDoYvK00oPVKkIeybvHSpaJ1bX7AzDOUVENLeGjd+K9YqsSMVL8p OENfJ6BD7MDgVsJWeoF050MgT3P6E6ZXR57wWN3tW39KGxqzx+yc8JtXfoXIXiyGGYxy Q7SNA4IuEmEgAaDc+G5OOkcRmMfTjwVBgLTYI+AU4vjAQFNutnp9uyNwHXkrHzEydpcH WA6A== X-Received: by 10.49.71.106 with SMTP id t10mr5356441qeu.26.1380144890822; Wed, 25 Sep 2013 14:34:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.116.11 with HTTP; Wed, 25 Sep 2013 14:34:30 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20130925133232.0d9f3070@resistor.net> References: <6.2.5.6.2.20130925133232.0d9f3070@resistor.net> From: Ira McDonald Date: Wed, 25 Sep 2013 17:34:30 -0400 Message-ID: To: S Moonesamy , Ira McDonald Content-Type: multipart/alternative; boundary=047d7b6777d6f4f8c404e73c05df Cc: Pat Fleming , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Request for Apps Area review of LDAP Printer Schema (19 September 2013) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 21:34:52 -0000 --047d7b6777d6f4f8c404e73c05df Content-Type: text/plain; charset=ISO-8859-1 Hi, At the IEEE-ISTO PWG we understood that individual submissions could still be published as an RFC by the IETF. On the advice of Barry Leiba (Apps AD), we sent this document to the Apps Area WG mailing list for review (along w/ the related 'ipps' URI scheme). There is no active LDAP WG in the IETF as far as I know. The original LDAP Printer Schema (RFC 3712) was reviewed by Kurt Zeilenga and others in the LDAP community. Cheers, - Ira Ira McDonald (Musician / Software Architect) Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG IPP WG Co-Chair - TCG Trusted Mobility Solutions WG Chair - TCG Embedded Systems Hardcopy SG IETF Designated Expert - IPP & Printer MIB Blue Roof Music/High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto:blueroofmusic@gmail.com Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 On Wed, Sep 25, 2013 at 4:37 PM, S Moonesamy wrote: > Hi Ira, > > At 09:34 19-09-2013, Ira McDonald wrote: > >> The IEEE-ISTO PWG Internet Printing Protocol WG would like to request >> IETF Apps Area review of our updated LDAP Printer Schema (updates >> RFC 3712). >> >> http://www.ietf.org/internet-**drafts/draft-mcdonald-ldap-** >> printer-schema-05.txt >> >> Cheers, >> - Ira (co-chair of IEEE-ISTO PWG IPP WG and co-editor of this document) >> > > This is an individual comment. > > From Section 1 of the draft: > > "This document is published by the IETF on behalf of the Internet > Printing Protocol Working Group [PWGIPP] of the IEEE-ISTO Printer > Working Group [PWG]." > > Is there an IETF working group which will adopt this draft so that it can > be published as a RFC by the IETF? > > Regards, > S. Moonesamy > --047d7b6777d6f4f8c404e73c05df Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

At the IEEE-ISTO = PWG we understood that individual submissions could still be
published = as an RFC by the IETF.

On the advice of Barry Leiba (Apps AD),= we sent this document to the Apps Area WG
mailing list for review (along w/ the related 'ipps' URI sche= me).

There is no active LDAP WG in the IETF as far as I know.= =A0 The original LDAP Printer
Schema (RFC 3712) was reviewed by Ku= rt Zeilenga and others in the LDAP community.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair = - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Workin= g Group
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Trusted Mobility Solution= s WG
Chair - TCG Embedded Systems Hardcopy SG
IETF Designated Expert = - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthincmailto:bluer= oofmusic@gmail.com
Winter=A0 579 Park Place=A0 Saline, MI=A0 48176=A0 734-944-0094
Summer= =A0 PO Box 221=A0 Grand Marais, MI 49839=A0 906-494-2434



On Wed, Sep 25, 2013 at 4:37 PM, S Moone= samy <sm+ietf@elandsys.com> wrote:
Hi Ira,

At 09:34 19-09-2013, Ira McDonald wrote:
The IEEE-ISTO PWG Internet Printing Protocol WG would like to request
IETF Apps Area review of our updated LDAP Printer Schema (updates
RFC 3712).

http://www.ietf.org/internet-drafts= /draft-mcdonald-ldap-printer-schema-05.txt

Cheers,
- Ira (co-chair of IEEE-ISTO PWG IPP WG and co-editor of this document)

This is an individual comment.

>From Section 1 of the draft:

=A0 "This document is published by the IETF on behalf of the Internet<= br> =A0 =A0Printing Protocol Working Group [PWGIPP] of the IEEE-ISTO Printer =A0 =A0Working Group [PWG]."

Is there an IETF working group which will adopt this draft so that it can b= e published as a RFC by the IETF?

Regards,
S. Moonesamy

--047d7b6777d6f4f8c404e73c05df-- From Claudio.Allocchio@garr.it Thu Sep 26 02:28:12 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF9E21F9AA4; Thu, 26 Sep 2013 02:28:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.601 X-Spam-Level: X-Spam-Status: No, score=-0.601 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UDagFYw1fNs0; Thu, 26 Sep 2013 02:28:07 -0700 (PDT) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [193.206.158.29]) by ietfa.amsl.com (Postfix) with ESMTP id 0545C21F9B8A; Thu, 26 Sep 2013 02:27:51 -0700 (PDT) Received: internal info suppressed Date: Thu, 26 Sep 2013 11:27:46 +0200 (CEST) From: Claudio Allocchio X-X-Sender: claudio@vpnclnt04.dir.garr.it To: apps-discuss@ietf.org, draft-ietf-clue-telepresence-use-cases.all@tools.ietf.org Message-ID: User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-2000082971-1380187667=:56750" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=garr.it; s=cyrus; t=1380187670; bh=GFRBnQmZ2Lb7bdRGIoRruWggD2nmbpU0kic8o1m8ACM=; h=Date:From:To:cc:Subject; b=UCDjFeecMCMmgHz2/cs5vHHh8xp9m2OPM2aDbHYAeDAzi7Anp0Suf5cEOhKICsDzt DuJ95W1sNGb3NrfF8433cHonKRO+F+lX7GdpcUqERrFwAUZ6s9hzymc3WaFREQrP+M TZetT7MSkZY9ya1sMR0SBBg9nT0l6GYIs0XRY7PI= Cc: IESG Subject: [apps-discuss] APPSDIR review of draft-ietf-clue-telepresence-use-cases-07 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 26 Sep 2013 09:28:12 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-2000082971-1380187667=:56750 Content-Type: TEXT/PLAIN; format=flowed; charset=UTF-8 Content-Transfer-Encoding: 8BIT Hello all, I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see ​ http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-clue-telepresence-use-cases-07 Title: Use Cases for Telepresence Multi-streams Reviewer: Claudio Allocchio Review Date: Sep 26th 2013 IETF Last Call Date: Sep 26th 2013 IESG Telechat Date: Not known Summary: This draft is almost ready for publication as an Informational RFC. However it needs some editing and maybe a re-ordering of some sections. Also a more detailed descprition of the "audio scenario" in all sections is worth an efort before publication. Major issues: none. Minor issues: General comment: most of the documet focuses a lot on the video aspect of telepresence, and only is some section the "audio presence" is quickly described as possible stereo, or surround or multible monophonic channels. I think the audio aspect is as important as the video one in making participatns feel the telepresence effect, thus each section should add a carful audio setup scenario as detailed as the video on. The voice of a partiipants must come from where his/her virtual image is. There is a text repetition in Introduction and in section 2 (page 5): The basic features that give telepresence its distinctive characteristics are implemented in disparate ways in different systems. Currently Telepresence systems from diverse vendors interoperate to some extent, but this is not supported in a standards based fashion. Interworking requires that translation and transcoding devices be included in the architecture. Such devices increase latency, reducing the quality of interpersonal interaction. Use of these devices is often not automatic; it frequently requires substantial manual configuration and a detailed understanding of the nature of underlying audio and video streams. This state of affairs is not acceptable for the continued growth of telepresence - telepresence systems should have the same ease of interoperability as do telephones. Either you make a shorter statement in the Introduction, of you just refer to the introduction text in section 2, page 5. 3.2 section. The whole section describes possible techniques to overcome the mismatched situation at the 2 sites... but it does not analyse at all possible effects that different proposed solutions have on the "telepresence effect" itself, and on human participants. As this is a "scenario introduction", we should also consider this aspect, as then technical specification can also handle possible mitigation actions to reduce the problm. For example, in some of the cases - remote participants chenging dynamically on the screens - a potential very bad seasick situation will happen easily, making the telepresence esperience a nightmare. Note that this comment also applies to 3.3 section. 3.3 section. The description applies to current techniques for multisites, bue there is no mention of possible overcome situations when different systems are used. Of course this is very similar to 3.2 case, but with complexity multiplied by the number of dirrefent sites. It should be useful to mention explicitly also this fact. 3.4 section. The currect text describes what you do with the H.239 equivalent channel data, and suggests the need of additional streams (not a sigle one): fine but what is the problem to solve here, is any? Ok, maybe you just need to state that you need to make interoperable the sigle "presentaton channel" provided by any site. 3.5 section. A basic doubt: is this section into the scope of this Informational document? If we aim to help deployment of complete interoparting systems, maybe it is, because most existing telepresence systems have proprietary (or likely) ways to allow participatns with non telepresence devices. If we are only aiming to real telepresence systems interoperability, then this section could go into an appendix section. 3.6 section. I tend to think that also this case is worth for an appendix (see 3.5 comments). 3.8 section. My basic doubt here is "does this belong to telepresence scenario at all? Immersive scnenario in this situation is quite different that the one described in the beginning (a typical business meeting). This comment also applies to section 3.6 Nits: none. ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca --0-2000082971-1380187667=:56750-- From ietfc@btconnect.com Thu Sep 26 04:14:25 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2CD011E8195 for ; Thu, 26 Sep 2013 04:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yqLz0nR57GHn for ; Thu, 26 Sep 2013 04:14:19 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0251.outbound.messaging.microsoft.com [213.199.154.251]) by ietfa.amsl.com (Postfix) with ESMTP id 1335E11E8197 for ; Thu, 26 Sep 2013 04:14:16 -0700 (PDT) Received: from mail56-db9-R.bigfish.com (10.174.16.233) by DB9EHSOBE020.bigfish.com (10.174.14.83) with Microsoft SMTP Server id 14.1.225.22; Thu, 26 Sep 2013 11:14:14 +0000 Received: from mail56-db9 (localhost [127.0.0.1]) by mail56-db9-R.bigfish.com (Postfix) with ESMTP id 3126F2600A6; Thu, 26 Sep 2013 11:14:14 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.250.181; KIP:(null); UIP:(null); IPV:NLI; H:AMSPRD0711HT004.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -11 X-BigFish: PS-11(zz9371I542I1432Idbf2izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h20f7h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah1de097h186068h1d68deh8275bh8275dh18f31ejz2dh2a8h5a9h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h304l1d11m1155h) Received: from mail56-db9 (localhost.localdomain [127.0.0.1]) by mail56-db9 (MessageSwitch) id 1380194053142028_2015; Thu, 26 Sep 2013 11:14:13 +0000 (UTC) Received: from DB9EHSMHS009.bigfish.com (unknown [10.174.16.228]) by mail56-db9.bigfish.com (Postfix) with ESMTP id 0613780269; Thu, 26 Sep 2013 11:14:13 +0000 (UTC) Received: from AMSPRD0711HT004.eurprd07.prod.outlook.com (157.56.250.181) by DB9EHSMHS009.bigfish.com (10.174.14.19) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 26 Sep 2013 11:14:12 +0000 Received: from pc6 (86.135.129.38) by pod51017.outlook.com (10.242.14.165) with Microsoft SMTP Server (TLS) id 14.16.359.1; Thu, 26 Sep 2013 11:14:11 +0000 Message-ID: <042201cebaa9$529a3400$4001a8c0@gateway.2wire.net> From: t.petch To: Ira McDonald , , Michael R Sweet References: Date: Thu, 26 Sep 2013 12:11:46 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.135.129.38] X-OriginatorOrg: btconnect.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [apps-discuss] Request for Apps Area review of IPP over HTTPs and 'ipps' URI Scheme (19 September 2013) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 26 Sep 2013 11:14:25 -0000 Ira The aspect that strikes me most is not so much an apps one as a security one, that current I-Ds using TLS tend to say more about what forms of security are acceptable. For example, there has been much recently about the checks to perform on a certificate and often there are comments about the acceptable cipher suites. Also, all the references are to TLS 1.2 which, last I saw, is not widely supported - again, I would expect some comment thereon. I expect that the applicability of this is not the usual 'across the public Internet' one which may colour what is acceptable. Otherwise, I find the style slightly unfamiliar. The abbreviations come at the end whereas they are commonly at the beginning. There is a non-normative section 3 in the middle of normative ones - commonly, that is an appendix. The definitions in section 2 I would find easier without the repeated In this document, which I think redundant. You include query in the scheme syntax but it is never reference or appears in any example. Has this I-D any relationship to RFC3510? Tom Petch ----- Original Message ----- From: "Ira McDonald" To: ; ; "Ira McDonald" ; "Michael R Sweet" Sent: Thursday, September 19, 2013 5:45 PM > Hello, > > The IEEE-ISTO PWG Internet Printing Protocol WG would like to request > IETF Apps Area review of our IPP over HTTPS Transport Binding and > 'ipps' URI Scheme: > > http://www.ietf.org/internet-drafts/draft-mcdonald-ipps-uri-scheme-08.tx t > > Please note that this document has been already been reviewed on the > IETF URI Review mailing list (and revised accordingly). > > This document does NOT specify a new protocol, but merely a transport > binding for IETF IPP/1.1 (RFC 2910/1911) that requires that TLS always > be started *before* sending any HTTP application layer requests - as > opposed to using the rarely implemented HTTP Upgrade (RFC 2817), > a source of security problems in shipping IPP printers (essentially all > network printers for the last decade). > > Cheers, > - Ira (co-chair of IEEE-ISTO PWG IPP WG and co-editor of this document) > > > Ira McDonald (Musician / Software Architect) > Chair - Linux Foundation Open Printing WG > Secretary - IEEE-ISTO Printer Working Group > Co-Chair - IEEE-ISTO PWG IPP WG > Co-Chair - TCG Trusted Mobility Solutions WG > Chair - TCG Embedded Systems Hardcopy SG > IETF Designated Expert - IPP & Printer MIB > Blue Roof Music/High North Inc > http://sites.google.com/site/blueroofmusic > http://sites.google.com/site/highnorthinc > mailto:blueroofmusic@gmail.com > Winter 579 Park Place Saline, MI 48176 734-944-0094 > Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 > ------------------------------------------------------------------------ -------- > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From blueroofmusic@gmail.com Thu Sep 26 08:50:27 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9581921F9D1E for ; Thu, 26 Sep 2013 08:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZgHQI9kGdcpn for ; Thu, 26 Sep 2013 08:50:25 -0700 (PDT) Received: from mail-qa0-x236.google.com (mail-qa0-x236.google.com [IPv6:2607:f8b0:400d:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 25CA221E80A3 for ; Thu, 26 Sep 2013 08:48:51 -0700 (PDT) Received: by mail-qa0-f54.google.com with SMTP id bv4so946926qab.20 for ; Thu, 26 Sep 2013 08:48:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=an8KWtZ1qkP/sXqbURyaDNhBD7TCdJB/Vn0vrWfobcU=; b=BKKcLisyRCyTIsV7ILYUSseUk4AX93Uemaw6tn9aWRx3UrNsOBNWPgoxuv1+ubFT6x Xtb+8gFEsFF2GEJ0m2CRibOzDovdlaEzwR3NoOfrMDGjHo4tzP7mBN61klZGWMLmhkgf yH5cjO6IG7r2tqB3V9WjD570YhfXzFv1Tpy0JSFpFHi1p5T+LbiEfRKe4mSh0Ix0oZA5 yPhyRq1VnOdYBEoYz8yNSp8E7wplwvgqYvLeX0ziqQsaGeSAC5+4E5vYCeT4tF8skq6u WIsZ+WaEp694toVmnpgA2hqfUykplrIc8Mna4QpkGOLzawieAdIQbP8OaB+tH48EOaIp JaNg== X-Received: by 10.224.88.136 with SMTP id a8mr3405092qam.106.1380210525782; Thu, 26 Sep 2013 08:48:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.116.11 with HTTP; Thu, 26 Sep 2013 08:48:25 -0700 (PDT) In-Reply-To: <042201cebaa9$529a3400$4001a8c0@gateway.2wire.net> References: <042201cebaa9$529a3400$4001a8c0@gateway.2wire.net> From: Ira McDonald Date: Thu, 26 Sep 2013 11:48:25 -0400 Message-ID: To: "t.petch" , Ira McDonald Content-Type: multipart/alternative; boundary=001a11c2bb4c1ac64a04e74b4e62 Cc: Michael R Sweet , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Request for Apps Area review of IPP over HTTPs and 'ipps' URI Scheme (19 September 2013) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 26 Sep 2013 15:50:27 -0000 --001a11c2bb4c1ac64a04e74b4e62 Content-Type: text/plain; charset=ISO-8859-1 Hi Tom, Thanks for you comments and questions. My replies are inline below. Cheers, - Ira Ira McDonald (Musician / Software Architect) Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG IPP WG Co-Chair - TCG Trusted Mobility Solutions WG Chair - TCG Embedded Systems Hardcopy SG IETF Designated Expert - IPP & Printer MIB Blue Roof Music/High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto:blueroofmusic@gmail.com Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 On Thu, Sep 26, 2013 at 7:11 AM, t.petch wrote: > Ira > > The aspect that strikes me most is not so much an apps one as a security > one, that current I-Ds using TLS tend to say more about what forms of > security are acceptable. For example, there has been much recently > about the checks to perform on a certificate and often there are > comments about the acceptable cipher suites. Also, all the references > are to TLS 1.2 which, last I saw, is not widely supported - again, I > would expect some comment thereon. I expect that the applicability of > this is not the usual 'across the public Internet' one which may colour > what is acceptable. > We brought this document to the IETF Apps Area because all original IETF IPP standards were developed there, including RFC 3510. The intended usage is primarily 'across the public Internet', in support of IEEE-ISTO PWG IPP Everywhere (PWG 5100.14) which support high-function printing from mobile devices (cellphones, tablets, laptops). Mobile phones and major operating systems are now implementing this standard. ftp://ftp.pwg.org/pub/pwg/candidates/cs-ippeve10-20130128-5100.14.pdf In the near future, this intended usage will be much more important with the new IPP Shared Infrastructure Extensions (new IPP cloud print operations). ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippsix10-20130923-rev.pdf TLS 1.2 is commonly supported by printers and multifunction devices, due due to use of IPP/2.0 w/ TLS 1.2 in the Apple AirPrint technology in 2010. We didn't want to place mandatory conformance requirements on TLS 1.2 usage, beyond those specified in RFC 5246 itself. Since quite a few cipher suites are now defined for use w/ TLS 1.2, this seems problematic. Your advice and guidance would be much appreciated. We could consider allowing alternate use of TLS 1.1, if that's appropriate, although IPP Everywhere certified printers will begin shipping in October, so we'll have to be a bit careful in making changes. > > Otherwise, I find the style slightly unfamiliar. > > The abbreviations come at the end whereas they are commonly at the > beginning. > I'm confused - do you mean "ABC (Another Big Cloud)" or the location of the Abbreviations section in an appendix? We put this section in an appendix based on advice on the IETF URI review mailing list, although the IEEE-ISTO PWG document template now puts it into section 2 with other terminology - would that be more appropriate? There is a non-normative section 3 in the middle of normative ones - > commonly, that is an appendix. > Should we move the informative section 3.1 to an appendix? It was placed in section 3 to introduce the behavior differences between 'ipp' and 'ipps' URI schemes. > The definitions in section 2 I would find easier without the repeated > In this document, > which I think redundant. > Thanks - we'll remove the redundant phrases. > You include query in the scheme syntax but it is never reference or > appears in any example. > We included it because it was present in RFC 3510 and RFC 3986. It is *never* used in the IPP protocol (on port 631), because filtering is done in-band in the IPP Get-Printer-Attributes and Get-Job-Attributes operations. Should we just remove the query syntax? This could cause breakage with some existing IPP print spoolers, since it was present in RFC 3510. > Has this I-D any relationship to RFC3510? > Yes - it complements RFC 3510, as stated in Appendix A and elsewhere. The 'ipps' URI scheme was developed first in CUPS (standard print spooler on Mac OS X and all UNIX and Linux distributions) because printers were in fact not supporting HTTP TLS Upgrade (RFC 2817) or else were doing it wrong (e.g., partway through an IPP session - defeating strong authentication of client identity). For mobile print over the public Internet, failure to negotiate a TLS secure transport with data encryption is not acceptable. Should we add discussion of the relationship to RFC 3510 to Introduction? > Tom Petch > > ----- Original Message ----- > From: "Ira McDonald" > To: ; ; "Ira McDonald" > ; "Michael R Sweet" > Sent: Thursday, September 19, 2013 5:45 PM > > > Hello, > > > > The IEEE-ISTO PWG Internet Printing Protocol WG would like to request > > IETF Apps Area review of our IPP over HTTPS Transport Binding and > > 'ipps' URI Scheme: > > > > > http://www.ietf.org/internet-drafts/draft-mcdonald-ipps-uri-scheme-08.tx > t > > > > Please note that this document has been already been reviewed on the > > IETF URI Review mailing list (and revised accordingly). > > > > This document does NOT specify a new protocol, but merely a transport > > binding for IETF IPP/1.1 (RFC 2910/1911) that requires that TLS always > > be started *before* sending any HTTP application layer requests - as > > opposed to using the rarely implemented HTTP Upgrade (RFC 2817), > > a source of security problems in shipping IPP printers (essentially > all > > network printers for the last decade). > > > > Cheers, > > - Ira (co-chair of IEEE-ISTO PWG IPP WG and co-editor of this > document) > > > > > > Ira McDonald (Musician / Software Architect) > > Chair - Linux Foundation Open Printing WG > > Secretary - IEEE-ISTO Printer Working Group > > Co-Chair - IEEE-ISTO PWG IPP WG > > Co-Chair - TCG Trusted Mobility Solutions WG > > Chair - TCG Embedded Systems Hardcopy SG > > IETF Designated Expert - IPP & Printer MIB > > Blue Roof Music/High North Inc > > http://sites.google.com/site/blueroofmusic > > http://sites.google.com/site/highnorthinc > > mailto:blueroofmusic@gmail.com > > Winter 579 Park Place Saline, MI 48176 734-944-0094 > > Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 > > > > > ------------------------------------------------------------------------ > -------- > > > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss > > > > > --001a11c2bb4c1ac64a04e74b4e62 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Tom,

Thanks for you comment= s and questions.=A0 My replies are inline below.

Cheers,
- Ira


Ira McDo= nald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer = Working Group
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Trusted = Mobility Solutions WG
Chair - TCG Embedded Systems Hardcopy SG
IETF D= esignated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites= .google.com/site/blueroofmusic
http://si= tes.google.com/site/highnorthinc
mailto:blueroo= fmusic@gmail.com
Winter=A0 579 Park Place=A0 Saline, MI=A0 48176=A0 = 734-944-0094
Summer=A0 PO Box 221=A0 Grand Marais, MI 49839=A0 906-494-2= 434



On Thu, Sep 26, 2013 at 7:11 AM, t.petch= <ietfc@btconnect.com> wrote:
Ira

The aspect that strikes me most is not so much an apps one as a security one, that current I-Ds using TLS tend to say more about what forms of
security are acceptable. =A0For example, there has been much recently
about the checks to perform on a certificate and often there are
comments about the acceptable cipher suites. =A0Also, all the references are to TLS 1.2 which, last I saw, is not widely supported - again, I
would expect some comment thereon. =A0I expect that the applicability of this is not the usual 'across the public Internet' one which may co= lour
what is acceptable.

We brought this doc= ument to the IETF Apps Area because all original
IETF IPP sta= ndards were developed there, including RFC 3510.

The inte= nded usage is primarily 'across the public Internet', in support of=
IEEE-ISTO PWG IPP Everywhere (PWG 5100.14) which support high-function
= printing from mobile devices (cellphones, tablets, laptops).=A0 Mobile phon= es
and major operating systems are now implementing this standard.

=A0 ftp://ftp.pwg.org/pub/pwg/candidates/cs-ippeve10-20130128-51= 00.14.pdf

In the near future, this intended usage wil= l be much more important with the
new IPP Shared Infrastructure Extensions (new IPP cloud print op= erations).


TLS 1.2 is commonly supported by printers and mul= tifunction devices, due
due to use of IPP/2.0 w/ TLS 1.2 in t= he Apple AirPrint technology in 2010.

We didn't want = to place mandatory conformance requirements on TLS 1.2
usage, beyond those specified in RFC 5246 itself.=A0 Since quite= a few cipher
suites are now defined for use w/ TLS 1.2, this= seems problematic.=A0 Your
advice and guidance would be much appreciate= d.

We could consider allowing alternate use of TLS 1= .1, if that's appropriate,
although IPP Everywhere certif= ied printers will begin shipping in October,
so we'll have to be a b= it careful in making changes.
=A0

Otherwise, I find the style slightly unfamiliar.

The abbreviations come at the end whereas they are commonly at the
beginning.

I'm confused - do you me= an "ABC (Another Big Cloud)" or the location of
the Abbreviati= ons section in an appendix?=A0 We put this section in an
appe= ndix based on advice on the IETF URI review mailing list, although
the IEEE-ISTO PWG document template now puts it into section 2 w= ith
other terminology - would that be more appropriate?
=A0

There is a non-normative section 3 in the middle of normative ones -
commonly, that is an appendix.

Should we move the = informative section 3.1 to an appendix?=A0 It was placed
in section 3 to= introduce the behavior differences between 'ipp' and 'ipps'= ;
URI schemes.


The definitions in section 2 I would find easier without the repeated
=A0In this document,
which I think redundant.

Thanks - we= 9;ll remove the redundant phrases.


You include query in the scheme syntax but it is never reference or
appears in any example.

We included it = because it was present in RFC 3510 and RFC 3986. It is
*never* used in = the IPP protocol (on port 631), because filtering is done
in-band in th= e IPP Get-Printer-Attributes and Get-Job-Attributes operations.=A0

Should we just remove the query syntax?=A0=A0 This could cause breakage=
with some existing IPP print spoolers, since it was present = in RFC 3510.


Has this I-D any relationship to RFC3510?

Yes - it complements RFC 3510, as stated in Appendix A and elsewhere.

The 'ipps' URI scheme was developed first in CUPS (= standard print spooler
on Mac OS X and all UNIX and Linux distributions) because printe= rs were
in fact not supporting HTTP TLS Upgrade (RFC 2817) or= else were doing it
wrong (e.g., partway through an IPP session - defea= ting strong authentication
of client identity).

For mobile print over the= public Internet, failure to negotiate a TLS secure
transport with data = encryption is not acceptable.

Should we add discussion of= the relationship to RFC 3510 to Introduction?


Tom Petch

----- Original Message -----
From: "Ira McDonald" <blueroofmusic@gmail.com>
To: <apps-discuss@ietf.org&= gt;; <uri-review@ietf.org>= ; "Ira McDonald"
<blueroofmusic@gmail.com&= gt;; "Michael R Sweet" <ms= weet@apple.com>
Sent: Thursday, September 19, 2013 5:45 PM

> Hello,
>
> The IEEE-ISTO PWG Internet Printing Protocol WG would like to request<= br> > IETF Apps Area review of our IPP over HTTPS Transport Binding and
> 'ipps' URI Scheme:
>
>
http://www.ietf.org/internet-drafts/draft-mcdonald-ipp= s-uri-scheme-08.tx
t
>
> Please note that this document has been already been reviewed on the > IETF URI Review mailing list (and revised accordingly).
>
> This document does NOT specify a new protocol, but merely a transport<= br> > binding for IETF IPP/1.1 (RFC 2910/1911) that requires that TLS always=
> be started *before* sending any HTTP application layer requests - as > opposed to using the rarely implemented HTTP Upgrade (RFC 2817),
> a source of security problems in shipping IPP printers (essentially all
> network printers for the last decade).
>
> Cheers,
> - Ira (co-chair of IEEE-ISTO PWG IPP WG and co-editor of this
document)
>
>
> Ira McDonald (Musician / Software Architect)
> Chair - Linux Foundation Open Printing WG
> Secretary - IEEE-ISTO Printer Working Group
> Co-Chair - IEEE-ISTO PWG IPP WG
> Co-Chair - TCG Trusted Mobility Solutions WG
> Chair - TCG Embedded Systems Hardcopy SG
> IETF Designated Expert - IPP & Printer MIB
> Blue Roof Music/High North Inc
> http://sites.google.com/site/blueroofmusic
> http://sites.google.com/site/highnorthinc
> mailto:blueroofmusic@gmail.= com
> Winter =A0579 Park Place =A0Saline, MI =A048176 =A0734-944-0094
> Summer =A0PO Box 221 =A0Grand Marais, MI 49839 =A0906-494-2434
>


---------------------------------------------------------------= ---------
--------


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



--001a11c2bb4c1ac64a04e74b4e62-- From Claudio.Allocchio@garr.it Thu Sep 26 09:11:58 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F99311E8110 for ; Thu, 26 Sep 2013 09:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.313 X-Spam-Level: X-Spam-Status: No, score=-0.313 tagged_above=-999 required=5 tests=[AWL=-0.194, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W56hkGmYCorp for ; Thu, 26 Sep 2013 09:11:54 -0700 (PDT) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [193.206.158.29]) by ietfa.amsl.com (Postfix) with ESMTP id B543C11E81A5 for ; Thu, 26 Sep 2013 09:10:32 -0700 (PDT) Received: internal info suppressed Date: Thu, 26 Sep 2013 18:10:20 +0200 (CEST) From: Claudio Allocchio X-X-Sender: claudio@vpnclnt04.dir.garr.it To: Ira McDonald In-Reply-To: Message-ID: References: <042201cebaa9$529a3400$4001a8c0@gateway.2wire.net> User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=garr.it; s=cyrus; t=1380211823; bh=Gxseia4ivacHEGPqKhGm3GoTKdWz4p1nmwBB6bIbVgI=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=sr4vHC1VP6tF0FydNPMEtAQe57kAJ4gsqFmLrQ7IDaKg2tMQPp0qjVPdNRFsvQ9ns er8tTlTg64TRtbaGGRcIHlEEh05hP6l2gV8D/mr+rzVkKhNC8rD4oSZ+dzG/X/lKq4 iKKklSGvgCCAo5pZ/H/tPRwfkEc/o8nIPvMjlpoo= Cc: "apps-discuss@ietf.org" , Michael R Sweet Subject: Re: [apps-discuss] Request for Apps Area review of IPP over HTTPs and 'ipps' URI Scheme (19 September 2013) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 26 Sep 2013 16:11:58 -0000 Hi Ira, We also have the reviews from APPSDIR avalable now. BTW, when do you need the review to be done? best! Claudio On Thu, 26 Sep 2013, Ira McDonald wrote: > Hi Tom, > > Thanks for you comments and questions. My replies are inline below. > > Cheers, > - Ira > > > Ira McDonald (Musician / Software Architect) > Chair - Linux Foundation Open Printing WG > Secretary - IEEE-ISTO Printer Working Group > Co-Chair - IEEE-ISTO PWG IPP WG > Co-Chair - TCG Trusted Mobility Solutions WG > Chair - TCG Embedded Systems Hardcopy SG > IETF Designated Expert - IPP & Printer MIB > Blue Roof Music/High North Inc > http://sites.google.com/site/blueroofmusic > http://sites.google.com/site/highnorthinc > mailto:blueroofmusic@gmail.com > Winter 579 Park Place Saline, MI 48176 734-944-0094 > Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 > > > > On Thu, Sep 26, 2013 at 7:11 AM, t.petch wrote: > >> Ira >> >> The aspect that strikes me most is not so much an apps one as a security >> one, that current I-Ds using TLS tend to say more about what forms of >> security are acceptable. For example, there has been much recently >> about the checks to perform on a certificate and often there are >> comments about the acceptable cipher suites. Also, all the references >> are to TLS 1.2 which, last I saw, is not widely supported - again, I >> would expect some comment thereon. I expect that the applicability of >> this is not the usual 'across the public Internet' one which may colour >> what is acceptable. >> > > We brought this document to the IETF Apps Area because all original > IETF IPP standards were developed there, including RFC 3510. > > The intended usage is primarily 'across the public Internet', in support of > IEEE-ISTO PWG IPP Everywhere (PWG 5100.14) which support high-function > printing from mobile devices (cellphones, tablets, laptops). Mobile phones > and major operating systems are now implementing this standard. > > ftp://ftp.pwg.org/pub/pwg/candidates/cs-ippeve10-20130128-5100.14.pdf > > In the near future, this intended usage will be much more important with the > new IPP Shared Infrastructure Extensions (new IPP cloud print operations). > > ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippsix10-20130923-rev.pdf > > TLS 1.2 is commonly supported by printers and multifunction devices, due > due to use of IPP/2.0 w/ TLS 1.2 in the Apple AirPrint technology in 2010. > > We didn't want to place mandatory conformance requirements on TLS 1.2 > usage, beyond those specified in RFC 5246 itself. Since quite a few cipher > suites are now defined for use w/ TLS 1.2, this seems problematic. Your > advice and guidance would be much appreciated. > > We could consider allowing alternate use of TLS 1.1, if that's appropriate, > although IPP Everywhere certified printers will begin shipping in October, > so we'll have to be a bit careful in making changes. > > >> >> Otherwise, I find the style slightly unfamiliar. >> >> The abbreviations come at the end whereas they are commonly at the >> beginning. >> > > I'm confused - do you mean "ABC (Another Big Cloud)" or the location of > the Abbreviations section in an appendix? We put this section in an > appendix based on advice on the IETF URI review mailing list, although > the IEEE-ISTO PWG document template now puts it into section 2 with > other terminology - would that be more appropriate? > > > There is a non-normative section 3 in the middle of normative ones - >> commonly, that is an appendix. >> > > Should we move the informative section 3.1 to an appendix? It was placed > in section 3 to introduce the behavior differences between 'ipp' and 'ipps' > URI schemes. > > >> The definitions in section 2 I would find easier without the repeated >> In this document, >> which I think redundant. >> > > Thanks - we'll remove the redundant phrases. > > >> You include query in the scheme syntax but it is never reference or >> appears in any example. >> > > We included it because it was present in RFC 3510 and RFC 3986. It is > *never* used in the IPP protocol (on port 631), because filtering is done > in-band in the IPP Get-Printer-Attributes and Get-Job-Attributes > operations. > > Should we just remove the query syntax? This could cause breakage > with some existing IPP print spoolers, since it was present in RFC 3510. > > >> Has this I-D any relationship to RFC3510? >> > > Yes - it complements RFC 3510, as stated in Appendix A and elsewhere. > > The 'ipps' URI scheme was developed first in CUPS (standard print spooler > on Mac OS X and all UNIX and Linux distributions) because printers were > in fact not supporting HTTP TLS Upgrade (RFC 2817) or else were doing it > wrong (e.g., partway through an IPP session - defeating strong > authentication > of client identity). > > For mobile print over the public Internet, failure to negotiate a TLS secure > transport with data encryption is not acceptable. > > Should we add discussion of the relationship to RFC 3510 to Introduction? > > >> Tom Petch >> >> ----- Original Message ----- >> From: "Ira McDonald" >> To: ; ; "Ira McDonald" >> ; "Michael R Sweet" >> Sent: Thursday, September 19, 2013 5:45 PM >> >>> Hello, >>> >>> The IEEE-ISTO PWG Internet Printing Protocol WG would like to request >>> IETF Apps Area review of our IPP over HTTPS Transport Binding and >>> 'ipps' URI Scheme: >>> >>> >> http://www.ietf.org/internet-drafts/draft-mcdonald-ipps-uri-scheme-08.tx >> t >>> >>> Please note that this document has been already been reviewed on the >>> IETF URI Review mailing list (and revised accordingly). >>> >>> This document does NOT specify a new protocol, but merely a transport >>> binding for IETF IPP/1.1 (RFC 2910/1911) that requires that TLS always >>> be started *before* sending any HTTP application layer requests - as >>> opposed to using the rarely implemented HTTP Upgrade (RFC 2817), >>> a source of security problems in shipping IPP printers (essentially >> all >>> network printers for the last decade). >>> >>> Cheers, >>> - Ira (co-chair of IEEE-ISTO PWG IPP WG and co-editor of this >> document) >>> >>> >>> Ira McDonald (Musician / Software Architect) >>> Chair - Linux Foundation Open Printing WG >>> Secretary - IEEE-ISTO Printer Working Group >>> Co-Chair - IEEE-ISTO PWG IPP WG >>> Co-Chair - TCG Trusted Mobility Solutions WG >>> Chair - TCG Embedded Systems Hardcopy SG >>> IETF Designated Expert - IPP & Printer MIB >>> Blue Roof Music/High North Inc >>> http://sites.google.com/site/blueroofmusic >>> http://sites.google.com/site/highnorthinc >>> mailto:blueroofmusic@gmail.com >>> Winter 579 Park Place Saline, MI 48176 734-944-0094 >>> Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 >>> >> >> >> ------------------------------------------------------------------------ >> -------- >> >> >>> _______________________________________________ >>> apps-discuss mailing list >>> apps-discuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/apps-discuss >>> >> >> >> > ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca From blueroofmusic@gmail.com Thu Sep 26 09:23:05 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C72321F992A for ; Thu, 26 Sep 2013 09:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.211 X-Spam-Level: X-Spam-Status: No, score=0.211 tagged_above=-999 required=5 tests=[AWL=-2.056, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GObuMC+xqBOc for ; Thu, 26 Sep 2013 09:23:04 -0700 (PDT) Received: from mail-qa0-x230.google.com (mail-qa0-x230.google.com [IPv6:2607:f8b0:400d:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id 3838921F9E76 for ; Thu, 26 Sep 2013 09:23:03 -0700 (PDT) Received: by mail-qa0-f48.google.com with SMTP id hu16so981377qab.14 for ; Thu, 26 Sep 2013 09:23:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ikeni6+xgH+A3bZhHYrmoWaqfOqmc0gi7pux7l8rQBY=; b=QdElGYyfy96vKePwqwtQ8UZl4vART8G5TptchoW62TbSgb3h9HmhX8RDjmWWaFV3oJ FgmK4dMd7NSDEOJpVQ17jQsUTNI8PUJrFubpzm7wgE447a0YvEXuceG+Q8GP+Bs6hu3P Cflo9CrdQCeCe3smxFTlbw3ot145e1TYDPh2+RsuKRxouuD8ZeLV6K9SCDE1Vc+fL0ET cnz53V1o4j5DLbWngrAoiVcuFQWxixV1yej5NJCrYfFjGAWKlgw62rOyDL27wAlO3qj9 6Dr7sIQ0sWVVGtm2gQqJ6OPVIdXTVQBdRAjjwWDCdVROrK6tDAYrYk85EPazn6CYlrYk kssA== X-Received: by 10.49.120.72 with SMTP id la8mr2751138qeb.62.1380212581625; Thu, 26 Sep 2013 09:23:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.116.11 with HTTP; Thu, 26 Sep 2013 09:22:41 -0700 (PDT) In-Reply-To: References: <042201cebaa9$529a3400$4001a8c0@gateway.2wire.net> From: Ira McDonald Date: Thu, 26 Sep 2013 12:22:41 -0400 Message-ID: To: Claudio Allocchio , Ira McDonald Content-Type: multipart/alternative; boundary=047d7b6d8996a476ba04e74bc8f9 Cc: "apps-discuss@ietf.org" , Michael R Sweet Subject: Re: [apps-discuss] Request for Apps Area review of IPP over HTTPs and 'ipps' URI Scheme (19 September 2013) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 26 Sep 2013 16:23:05 -0000 --047d7b6d8996a476ba04e74bc8f9 Content-Type: text/plain; charset=ISO-8859-1 Hi Claudio, I think we'd like the review to be done ASAP - IPP Everywhere printers will start shipping October and major operating system support (on the client side) will also come quite soon. Cheers, - Ira Ira McDonald (Musician / Software Architect) Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG IPP WG Co-Chair - TCG Trusted Mobility Solutions WG Chair - TCG Embedded Systems Hardcopy SG IETF Designated Expert - IPP & Printer MIB Blue Roof Music/High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto:blueroofmusic@gmail.com Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 On Thu, Sep 26, 2013 at 12:10 PM, Claudio Allocchio < Claudio.Allocchio@garr.it> wrote: > > Hi Ira, > > We also have the reviews from APPSDIR avalable now. > > BTW, when do you need the review to be done? > > best! > Claudio > > > On Thu, 26 Sep 2013, Ira McDonald wrote: > > Hi Tom, >> >> Thanks for you comments and questions. My replies are inline below. >> >> Cheers, >> - Ira >> >> >> Ira McDonald (Musician / Software Architect) >> Chair - Linux Foundation Open Printing WG >> Secretary - IEEE-ISTO Printer Working Group >> Co-Chair - IEEE-ISTO PWG IPP WG >> Co-Chair - TCG Trusted Mobility Solutions WG >> Chair - TCG Embedded Systems Hardcopy SG >> IETF Designated Expert - IPP & Printer MIB >> Blue Roof Music/High North Inc >> http://sites.google.com/site/**blueroofmusic >> http://sites.google.com/site/**highnorthinc >> mailto:blueroofmusic@gmail.com >> Winter 579 Park Place Saline, MI 48176 734-944-0094 >> Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 >> >> >> >> On Thu, Sep 26, 2013 at 7:11 AM, t.petch wrote: >> >> Ira >>> >>> The aspect that strikes me most is not so much an apps one as a security >>> one, that current I-Ds using TLS tend to say more about what forms of >>> security are acceptable. For example, there has been much recently >>> about the checks to perform on a certificate and often there are >>> comments about the acceptable cipher suites. Also, all the references >>> are to TLS 1.2 which, last I saw, is not widely supported - again, I >>> would expect some comment thereon. I expect that the applicability of >>> this is not the usual 'across the public Internet' one which may colour >>> what is acceptable. >>> >>> >> We brought this document to the IETF Apps Area because all original >> IETF IPP standards were developed there, including RFC 3510. >> >> The intended usage is primarily 'across the public Internet', in support >> of >> IEEE-ISTO PWG IPP Everywhere (PWG 5100.14) which support high-function >> printing from mobile devices (cellphones, tablets, laptops). Mobile >> phones >> and major operating systems are now implementing this standard. >> >> ftp://ftp.pwg.org/pub/pwg/**candidates/cs-ippeve10-** >> 20130128-5100.14.pdf >> >> In the near future, this intended usage will be much more important with >> the >> new IPP Shared Infrastructure Extensions (new IPP cloud print operations). >> >> ftp://ftp.pwg.org/pub/pwg/ipp/**wd/wd-ippsix10-20130923-rev.**pdf >> >> TLS 1.2 is commonly supported by printers and multifunction devices, due >> due to use of IPP/2.0 w/ TLS 1.2 in the Apple AirPrint technology in 2010. >> >> We didn't want to place mandatory conformance requirements on TLS 1.2 >> usage, beyond those specified in RFC 5246 itself. Since quite a few >> cipher >> suites are now defined for use w/ TLS 1.2, this seems problematic. Your >> advice and guidance would be much appreciated. >> >> We could consider allowing alternate use of TLS 1.1, if that's >> appropriate, >> although IPP Everywhere certified printers will begin shipping in October, >> so we'll have to be a bit careful in making changes. >> >> >> >>> Otherwise, I find the style slightly unfamiliar. >>> >>> The abbreviations come at the end whereas they are commonly at the >>> beginning. >>> >>> >> I'm confused - do you mean "ABC (Another Big Cloud)" or the location of >> the Abbreviations section in an appendix? We put this section in an >> appendix based on advice on the IETF URI review mailing list, although >> the IEEE-ISTO PWG document template now puts it into section 2 with >> other terminology - would that be more appropriate? >> >> >> There is a non-normative section 3 in the middle of normative ones - >> >>> commonly, that is an appendix. >>> >>> >> Should we move the informative section 3.1 to an appendix? It was placed >> in section 3 to introduce the behavior differences between 'ipp' and >> 'ipps' >> URI schemes. >> >> >> The definitions in section 2 I would find easier without the repeated >>> In this document, >>> which I think redundant. >>> >>> >> Thanks - we'll remove the redundant phrases. >> >> >> You include query in the scheme syntax but it is never reference or >>> appears in any example. >>> >>> >> We included it because it was present in RFC 3510 and RFC 3986. It is >> *never* used in the IPP protocol (on port 631), because filtering is done >> in-band in the IPP Get-Printer-Attributes and Get-Job-Attributes >> operations. >> >> Should we just remove the query syntax? This could cause breakage >> with some existing IPP print spoolers, since it was present in RFC 3510. >> >> >> Has this I-D any relationship to RFC3510? >>> >>> >> Yes - it complements RFC 3510, as stated in Appendix A and elsewhere. >> >> The 'ipps' URI scheme was developed first in CUPS (standard print spooler >> on Mac OS X and all UNIX and Linux distributions) because printers were >> in fact not supporting HTTP TLS Upgrade (RFC 2817) or else were doing it >> wrong (e.g., partway through an IPP session - defeating strong >> authentication >> of client identity). >> >> For mobile print over the public Internet, failure to negotiate a TLS >> secure >> transport with data encryption is not acceptable. >> >> Should we add discussion of the relationship to RFC 3510 to Introduction? >> >> >> Tom Petch >>> >>> ----- Original Message ----- >>> From: "Ira McDonald" >>> To: ; ; "Ira McDonald" >>> ; "Michael R Sweet" >>> Sent: Thursday, September 19, 2013 5:45 PM >>> >>> Hello, >>>> >>>> The IEEE-ISTO PWG Internet Printing Protocol WG would like to request >>>> IETF Apps Area review of our IPP over HTTPS Transport Binding and >>>> 'ipps' URI Scheme: >>>> >>>> >>>> http://www.ietf.org/internet-**drafts/draft-mcdonald-ipps-** >>> uri-scheme-08.tx >>> t >>> >>>> >>>> Please note that this document has been already been reviewed on the >>>> IETF URI Review mailing list (and revised accordingly). >>>> >>>> This document does NOT specify a new protocol, but merely a transport >>>> binding for IETF IPP/1.1 (RFC 2910/1911) that requires that TLS always >>>> be started *before* sending any HTTP application layer requests - as >>>> opposed to using the rarely implemented HTTP Upgrade (RFC 2817), >>>> a source of security problems in shipping IPP printers (essentially >>>> >>> all >>> >>>> network printers for the last decade). >>>> >>>> Cheers, >>>> - Ira (co-chair of IEEE-ISTO PWG IPP WG and co-editor of this >>>> >>> document) >>> >>>> >>>> >>>> Ira McDonald (Musician / Software Architect) >>>> Chair - Linux Foundation Open Printing WG >>>> Secretary - IEEE-ISTO Printer Working Group >>>> Co-Chair - IEEE-ISTO PWG IPP WG >>>> Co-Chair - TCG Trusted Mobility Solutions WG >>>> Chair - TCG Embedded Systems Hardcopy SG >>>> IETF Designated Expert - IPP & Printer MIB >>>> Blue Roof Music/High North Inc >>>> http://sites.google.com/site/**blueroofmusic >>>> http://sites.google.com/site/**highnorthinc >>>> mailto:blueroofmusic@gmail.com >>>> Winter 579 Park Place Saline, MI 48176 734-944-0094 >>>> Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 >>>> >>>> >>> >>> ------------------------------**------------------------------** >>> ------------ >>> -------- >>> >>> >>> ______________________________**_________________ >>>> apps-discuss mailing list >>>> apps-discuss@ietf.org >>>> https://www.ietf.org/mailman/**listinfo/apps-discuss >>>> >>>> >>> >>> >>> >> > ------------------------------**------------------------------** > ------------------ > Claudio Allocchio G A R R > Claudio.Allocchio@garr.it > Senior Technical Officer > tel: +39 040 3758523 Italian Academic and G=Claudio; > S=Allocchio; > fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; > > PGP Key: http://www.cert.garr.it/PGP/**keys.php3#ca > --047d7b6d8996a476ba04e74bc8f9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Claudio,

I think = we'd like the review to be done ASAP - IPP Everywhere printers will sta= rt
shipping October and major operating system support (on the cli= ent side) will
also come quite soon.

Cheers,
- Ira


Ira McDonald (Musician = / Software Architect)
Chair - Linux Foundation Open Printing WG
Secre= tary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Trusted Mobility Solution= s WG
Chair - TCG Embedded Systems Hardcopy SG
IETF Designated Expert = - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthincmailto:bluer= oofmusic@gmail.com
Winter=A0 579 Park Place=A0 Saline, MI=A0 48176=A0 734-944-0094
Summer= =A0 PO Box 221=A0 Grand Marais, MI 49839=A0 906-494-2434



On Thu, Sep 26, 2013 at 12:10 PM, Claudi= o Allocchio <Claudio.Allocchio@garr.it> wrote:

Hi Ira,

We also have the reviews from APPSDIR avalable now.

BTW, when do you need the review to be done?

best!
Claudio


On Thu, 26 Sep 2013, Ira McDonald wrote:

Hi Tom,

Thanks for you comments and questions. =A0My replies are inline below.

Cheers,
- Ira


Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - TCG Embedded Systems Hardcopy SG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
ht= tp://sites.google.com/site/blueroofmusic
htt= p://sites.google.com/site/highnorthinc
mailto:blueroo= fmusic@gmail.com
Winter =A0579 Park Place =A0Saline, MI =A048176 =A0734-944-0094
Summer =A0PO Box 221 =A0Grand Marais, MI 49839 =A0906-494-2434



On Thu, Sep 26, 2013 at 7:11 AM, t.petch <ietfc@btconnect.com> wrote:

Ira

The aspect that strikes me most is not so much an apps one as a security one, that current I-Ds using TLS tend to say more about what forms of
security are acceptable. =A0For example, there has been much recently
about the checks to perform on a certificate and often there are
comments about the acceptable cipher suites. =A0Also, all the references are to TLS 1.2 which, last I saw, is not widely supported - again, I
would expect some comment thereon. =A0I expect that the applicability of this is not the usual 'across the public Internet' one which may co= lour
what is acceptable.


We brought this document to the IETF Apps Area because all original
IETF IPP standards were developed there, including RFC 3510.

The intended usage is primarily 'across the public Internet', in su= pport of
IEEE-ISTO PWG IPP Everywhere (PWG 5100.14) which support high-function
printing from mobile devices (cellphones, tablets, laptops). =A0Mobile phon= es
and major operating systems are now implementing this standard.

=A0ftp://ftp.pwg.org/pub/pwg/candidates/cs-= ippeve10-20130128-5100.14.pdf

In the near future, this intended usage will be much more important with th= e
new IPP Shared Infrastructure Extensions (new IPP cloud print operations).<= br>
=A0ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippsix10-201= 30923-rev.pdf

TLS 1.2 is commonly supported by printers and multifunction devices, due due to use of IPP/2.0 w/ TLS 1.2 in the Apple AirPrint technology in 2010.<= br>
We didn't want to place mandatory conformance requirements on TLS 1.2 usage, beyond those specified in RFC 5246 itself. =A0Since quite a few ciph= er
suites are now defined for use w/ TLS 1.2, this seems problematic. =A0Your<= br> advice and guidance would be much appreciated.

We could consider allowing alternate use of TLS 1.1, if that's appropri= ate,
although IPP Everywhere certified printers will begin shipping in October,<= br> so we'll have to be a bit careful in making changes.



Otherwise, I find the style slightly unfamiliar.

The abbreviations come at the end whereas they are commonly at the
beginning.


I'm confused - do you mean "ABC (Another Big Cloud)" or the l= ocation of
the Abbreviations section in an appendix? =A0We put this section in an
appendix based on advice on the IETF URI review mailing list, although
the IEEE-ISTO PWG document template now puts it into section 2 with
other terminology - would that be more appropriate?


There is a non-normative section 3 in the middle of normative ones -
commonly, that is an appendix.


Should we move the informative section 3.1 to an appendix? =A0It was placed=
in section 3 to introduce the behavior differences between 'ipp' an= d 'ipps'
URI schemes.


The definitions in section 2 I would find easier without the repeated
=A0In this document,
which I think redundant.


Thanks - we'll remove the redundant phrases.


You include query in the scheme syntax but it is never reference or
appears in any example.


We included it because it was present in RFC 3510 and RFC 3986. It is
*never* used in the IPP protocol (on port 631), because filtering is done in-band in the IPP Get-Printer-Attributes and Get-Job-Attributes
operations.

Should we just remove the query syntax? =A0 This could cause breakage
with some existing IPP print spoolers, since it was present in RFC 3510.

Has this I-D any relationship to RFC3510?


Yes - it complements RFC 3510, as stated in Appendix A and elsewhere.

The 'ipps' URI scheme was developed first in CUPS (standard print s= pooler
on Mac OS X and all UNIX and Linux distributions) because printers were
in fact not supporting HTTP TLS Upgrade (RFC 2817) or else were doing it wrong (e.g., partway through an IPP session - defeating strong
authentication
of client identity).

For mobile print over the public Internet, failure to negotiate a TLS secur= e
transport with data encryption is not acceptable.

Should we add discussion of the relationship to RFC 3510 to Introduction?

Tom Petch

----- Original Message -----
From: "Ira McDonald" <blueroofmusic@gmail.com>
To: <apps-dis= cuss@ietf.org>; <uri-review@ietf.org>; "Ira McDonald"
<blueroofmu= sic@gmail.com>; "Michael R Sweet" <msweet@apple.com>
Sent: Thursday, September 19, 2013 5:45 PM

Hello,

The IEEE-ISTO PWG Internet Printing Protocol WG would like to request
IETF Apps Area review of our IPP over HTTPS Transport Binding and
'ipps' URI Scheme:


http://www.ietf.org/internet-drafts/draf= t-mcdonald-ipps-uri-scheme-08.tx
t

Please note that this document has been already been reviewed on the
IETF URI Review mailing list (and revised accordingly).

This document does NOT specify a new protocol, but merely a transport
binding for IETF IPP/1.1 (RFC 2910/1911) that requires that TLS always
be started *before* sending any HTTP application layer requests - as
opposed to using the rarely implemented HTTP Upgrade (RFC 2817),
a source of security problems in shipping IPP printers (essentially
all
network printers for the last decade).

Cheers,
- Ira (co-chair of IEEE-ISTO PWG IPP WG and co-editor of this
document)


Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - TCG Embedded Systems Hardcopy SG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
ht= tp://sites.google.com/site/blueroofmusic
htt= p://sites.google.com/site/highnorthinc
mailto:blueroo= fmusic@gmail.com
Winter =A0579 Park Place =A0Saline, MI =A048176 =A0734-944-0094
Summer =A0PO Box 221 =A0Grand Marais, MI 49839 =A0906-494-2434



-------------------------------------------------------------= -----------
--------


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






-------------------------------------------------------------= -----------------
Claudio Allocchio =A0 =A0 =A0 =A0 =A0 =A0 G =A0 A =A0 R =A0 R =A0 =A0 =A0 = =A0 =A0Claud= io.Allocchio@garr.it
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Senior Technical Officer tel: +39 040 3758523 =A0 =A0 =A0Italian Academic and =A0 =A0 =A0= G=3DClaudio; S=3DAllocchio;
fax: +39 040 3758565 =A0 =A0 =A0 =A0Research Network =A0 =A0 =A0= =A0 P=3Dgarr; A=3Dgarr; C=3Dit;

=A0 =A0 =A0 =A0 =A0 =A0PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca=

--047d7b6d8996a476ba04e74bc8f9-- From ietfc@btconnect.com Thu Sep 26 10:32:37 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 841FD21F9FA7 for ; Thu, 26 Sep 2013 10:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_50=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7uo+04yWROy6 for ; Thu, 26 Sep 2013 10:32:32 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by ietfa.amsl.com (Postfix) with ESMTP id 1460221F9E5A for ; Thu, 26 Sep 2013 10:32:29 -0700 (PDT) Received: from mail35-tx2-R.bigfish.com (10.9.14.253) by TX2EHSOBE007.bigfish.com (10.9.40.27) with Microsoft SMTP Server id 14.1.225.22; Thu, 26 Sep 2013 17:32:28 +0000 Received: from mail35-tx2 (localhost [127.0.0.1]) by mail35-tx2-R.bigfish.com (Postfix) with ESMTP id C04034203A8; Thu, 26 Sep 2013 17:32:28 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.250.181; KIP:(null); UIP:(null); IPV:NLI; H:AMSPRD0711HT001.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -12 X-BigFish: PS-12(zz98dI9371I542I1432I853kzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h20f7h1d1ah1d2ah1fc6hz8dhz1de098h1033IL1de097h8275bh8275dhz2dh2a8h5a9h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h304l1d11m1155h) Received: from mail35-tx2 (localhost.localdomain [127.0.0.1]) by mail35-tx2 (MessageSwitch) id 1380216679716017_22171; Thu, 26 Sep 2013 17:31:19 +0000 (UTC) Received: from TX2EHSMHS025.bigfish.com (unknown [10.9.14.249]) by mail35-tx2.bigfish.com (Postfix) with ESMTP id 9D2322A0254; Thu, 26 Sep 2013 17:31:19 +0000 (UTC) Received: from AMSPRD0711HT001.eurprd07.prod.outlook.com (157.56.250.181) by TX2EHSMHS025.bigfish.com (10.9.99.125) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 26 Sep 2013 17:31:19 +0000 Received: from pc6 (86.135.129.38) by pod51017.outlook.com (10.242.14.162) with Microsoft SMTP Server (TLS) id 14.16.359.1; Thu, 26 Sep 2013 17:31:17 +0000 Message-ID: <0f5d01cebade$007e3420$4001a8c0@gateway.2wire.net> From: t.petch To: Ira McDonald References: <042201cebaa9$529a3400$4001a8c0@gateway.2wire.net> Date: Thu, 26 Sep 2013 18:29:41 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.135.129.38] X-OriginatorOrg: btconnect.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: Michael R Sweet , apps-discuss@ietf.org Subject: Re: [apps-discuss] Request for Apps Area review of IPP over HTTPs and 'ipps' URI Scheme (19 September 2013) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 26 Sep 2013 17:32:37 -0000 ----- Original Message ----- From: "Ira McDonald" To: "t.petch" ; "Ira McDonald" Cc: ; "Michael R Sweet" Sent: Thursday, September 26, 2013 4:48 PM > Hi Tom, > > Thanks for you comments and questions. My replies are inline below. > > Cheers, > - Ira > > On Thu, Sep 26, 2013 at 7:11 AM, t.petch wrote: > > > Ira > > > > The aspect that strikes me most is not so much an apps one as a security > > one, that current I-Ds using TLS tend to say more about what forms of > > security are acceptable. For example, there has been much recently > > about the checks to perform on a certificate and often there are > > comments about the acceptable cipher suites. Also, all the references > > are to TLS 1.2 which, last I saw, is not widely supported - again, I > > would expect some comment thereon. I expect that the applicability of > > this is not the usual 'across the public Internet' one which may colour > > what is acceptable. > > > > We brought this document to the IETF Apps Area because all original > IETF IPP standards were developed there, including RFC 3510. > > The intended usage is primarily 'across the public Internet', in support of > IEEE-ISTO PWG IPP Everywhere (PWG 5100.14) which support high-function > printing from mobile devices (cellphones, tablets, laptops). Mobile phones > and major operating systems are now implementing this standard. > > ftp://ftp.pwg.org/pub/pwg/candidates/cs-ippeve10-20130128-5100.14.pdf > > In the near future, this intended usage will be much more important with the > new IPP Shared Infrastructure Extensions (new IPP cloud print operations). > > ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippsix10-20130923-rev.pdf > > TLS 1.2 is commonly supported by printers and multifunction devices, due > due to use of IPP/2.0 w/ TLS 1.2 in the Apple AirPrint technology in 2010. > > We didn't want to place mandatory conformance requirements on TLS 1.2 > usage, beyond those specified in RFC 5246 itself. Since quite a few cipher > suites are now defined for use w/ TLS 1.2, this seems problematic. Your > advice and guidance would be much appreciated. > > We could consider allowing alternate use of TLS 1.1, if that's appropriate, > although IPP Everywhere certified printers will begin shipping in October, > so we'll have to be a bit careful in making changes. Ira TLS 1.2 is quite rare but has few flaws, TLS 1.0 is common but flawed, so if you can get support for 1.2, then that is the right choice. You do not have interoperability without a common ciphersuite so I am used to 'XXX over TLS' specifying one, even if it is the default from RFC5246 - TLS_RSA_WITH_AES_128_CBC_SHA - (which is, perhaps, not as secure as it might be, e.g. not for a protocol which will be around for a long time in exposed places and, I imagine, will see a lot of attacks, not something I realised on first reading. I am not competent to assess the threats and recommend a better one but I do see the discussions thereof on the TLS list. I would like to see a Security Directorate review sooner rather than later. In general, I see much more focus on this aspect of protocols than a few years ago and so was expecting a stronger Security Considerations). > > > > Otherwise, I find the style slightly unfamiliar. > > > > The abbreviations come at the end whereas they are commonly at the > > beginning. > > > I'm confused - do you mean "ABC (Another Big Cloud)" or the location of > the Abbreviations section in an appendix? We put this section in an > appendix based on advice on the IETF URI review mailing list, although > the IEEE-ISTO PWG document template now puts it into section 2 with > other terminology - would that be more appropriate? I am used to RFC putting it in section 2 (and I am used to URI reviews on the uri@w3.org list, where I would have commented earlier:-). > There is a non-normative section 3 in the middle of normative ones - > > commonly, that is an appendix. > > > > Should we move the informative section 3.1 to an appendix? It was placed > in section 3 to introduce the behavior differences between 'ipp' and 'ipps' > URI schemes. You clearly label it as Informative so .... Is your intended audience one that is already familiar with ipp scheme? If so, I would move it, if not, leave it alone. > > The definitions in section 2 I would find easier without the repeated > > In this document, > > which I think redundant. > > > > Thanks - we'll remove the redundant phrases. > > > You include query in the scheme syntax but it is never reference or > > appears in any example. > > > > We included it because it was present in RFC 3510 and RFC 3986. It is > *never* used in the IPP protocol (on port 631), because filtering is done > in-band in the IPP Get-Printer-Attributes and Get-Job-Attributes > operations. > > Should we just remove the query syntax? This could cause breakage > with some existing IPP print spoolers, since it was present in RFC 3510. No, but add a comment on its nonuse as you have here. > > Has this I-D any relationship to RFC3510? > > > > Yes - it complements RFC 3510, as stated in Appendix A and elsewhere. > > The 'ipps' URI scheme was developed first in CUPS (standard print spooler > on Mac OS X and all UNIX and Linux distributions) because printers were > in fact not supporting HTTP TLS Upgrade (RFC 2817) or else were doing it > wrong (e.g., partway through an IPP session - defeating strong > authentication > of client identity). > > For mobile print over the public Internet, failure to negotiate a TLS secure > transport with data encryption is not acceptable. > > Should we add discussion of the relationship to RFC 3510 to Introduction? Good idea but I was thinking more does this update RFC3510 in any way, or just sit alongside it as an alternative? Tom Petch > > From Claudio.Allocchio@garr.it Wed Sep 25 00:48:26 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C298321F9F8F; Wed, 25 Sep 2013 00:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.579 X-Spam-Level: X-Spam-Status: No, score=-0.579 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E41qUWxp0hNX; Wed, 25 Sep 2013 00:48:22 -0700 (PDT) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [193.206.158.29]) by ietfa.amsl.com (Postfix) with ESMTP id 233B221F9E7E; Wed, 25 Sep 2013 00:48:21 -0700 (PDT) Received: internal info suppressed Date: Wed, 25 Sep 2013 09:47:11 +0200 (CEST) From: Claudio Allocchio X-X-Sender: claudio@vpnclnt04.dir.garr.it To: Scott Brim In-Reply-To: Message-ID: References: <6.2.5.6.2.20130914143222.0b9590f0@elandnews.com> <6.2.5.6.2.20130918225335.0d0e2478@elandnews.com> <14439.1380035891@sandelman.ca> <76716D93-E946-4682-BE1C-CF2DC0434CE5@nominum.com> <52421A8F.2090603@gmail.com> User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=garr.it; s=cyrus; t=1380095241; bh=859OcgODL+3fZZbVSu5ETmo1GGLWY+AuwkwiJJ+A/Aw=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=UzSJY4mEuiEUxqfkMpIZTUUaR4P87/WAJbMmf68scZ7EOaIjPH6bWUR/UEx83PDGM CLI1rD1wu9MCsG1GEvL2Vt32CH44k7T282brxP3ubnWD7zRbjCsyWb9r7aUkccpN0e 40nSlxGV5U4elBzW1B344RPL1mEMBUNQXuU0dbUE= X-Mailman-Approved-At: Thu, 26 Sep 2013 10:48:09 -0700 Cc: "<, apps-discuss@ietf.org>, " , Michael Richardson , S Moonesamy , Tim Chown , Ted Lemon , draft-ietf-homenet-arch.all@tools.ietf.org, "homenet@ietf.org Group" , Brian Carpenter , The IESG Subject: Re: [apps-discuss] [homenet] APPSDIR review of draft-ietf-homenet-arch-10 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 07:48:26 -0000 On Tue, 24 Sep 2013, Scott Brim wrote: > I propose Architecture Overview. it's a very tricky definition to choose, but I also like more "Architecture Overview". +1 ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca From mcr@sandelman.ca Tue Sep 24 08:18:40 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E8B711E8142; Tue, 24 Sep 2013 08:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8KuPJnzzX4WH; Tue, 24 Sep 2013 08:18:35 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id DDA5911E815C; Tue, 24 Sep 2013 08:18:30 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id CAE252016E; Tue, 24 Sep 2013 12:27:34 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id D924B63B18; Tue, 24 Sep 2013 11:18:11 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id BB4EB63848; Tue, 24 Sep 2013 11:18:11 -0400 (EDT) From: Michael Richardson To: S Moonesamy In-Reply-To: <6.2.5.6.2.20130918225335.0d0e2478@elandnews.com> References: <6.2.5.6.2.20130914143222.0b9590f0@elandnews.com> <6.2.5.6.2.20130918225335.0d0e2478@elandnews.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca X-Mailman-Approved-At: Thu, 26 Sep 2013 10:48:25 -0700 Cc: apps-discuss@ietf.org, Tim Chown , iesg@ietf.org, draft-ietf-homenet-arch.all@tools.ietf.org, homenet@ietf.org Subject: Re: [apps-discuss] [homenet] APPSDIR review of draft-ietf-homenet-arch-10 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 15:18:40 -0000 --=-=-= S Moonesamy wrote: > The intent of my comment was not about adding more text, or > application-specific considerations, to the document. The title of the > document is "Home Networking Architecture for IPv6". My guess is that I believe that perhaps the title is now wrong. I think that it should say: "Requirements for Home Networking for IPv6" (But, it's really more than requirements. It's just less than architecture) I think that we can't really write the architecture until we are clear what the tradeoffsof the final consensus solution is. -- Michael Richardson , Sandelman Software Works --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUkGtM4qHRg3pndX9AQLtoAP+PDBV0zidofW7o78GHtFob8Eok8KSQg2Q VSYdN/9f5ufvDz+F43/Sx71lmxIB86rSRfMwC9W05nyjFdCFY2Ru25WadlqjUL2c dmTnUZ18Rh+sDDCT+W188Plz625e82xApPpXWm2Ugy/2yXmH75jrp7mwkePogxEC g+hwECK4YGI= =W4B4 -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Tue Sep 24 08:49:56 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8451611E8159; Tue, 24 Sep 2013 08:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DzgKbcXuOFDA; Tue, 24 Sep 2013 08:49:52 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id D7D6B11E8151; Tue, 24 Sep 2013 08:49:51 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 409932016E; Tue, 24 Sep 2013 12:59:02 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 74E3263B18; Tue, 24 Sep 2013 11:49:39 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 669E763848; Tue, 24 Sep 2013 11:49:39 -0400 (EDT) From: Michael Richardson To: Tim Chown In-Reply-To: References: <6.2.5.6.2.20130914143222.0b9590f0@elandnews.com> <6.2.5.6.2.20130918225335.0d0e2478@elandnews.com> <6.2.5.6.2.20130919074156.0cd2d900@elandnews.com> <3105F809-7E03-41D9-A634-DE32446FB19B@nominum.com> <89570788-2319-4922-B8DD-4359349683F7@ecs.soton.ac.uk> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca X-Mailman-Approved-At: Thu, 26 Sep 2013 10:48:26 -0700 Cc: "" , S Moonesamy , The IESG , draft-ietf-homenet-arch.all@tools.ietf.org, "homenet@ietf.org Group" , Ted Lemon Subject: Re: [apps-discuss] [homenet] APPSDIR review of draft-ietf-homenet-arch-10 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 15:49:56 -0000 --=-=-= Tim Chown wrote: tim> Do we want to spend more time now, given the desire to move ahead tim> with the tim> other work, restructuring the arch doc? It could be done, but I tim> wonder whether I am opposed to any restructuring. I am in favour of two rounds of external tweaks. I believe that by addressing the review now, we will avoid doing further work at IESG stage, and that's what the directorates are about. tim> And the title? Well, personally I have no emotional attachment to tim> the current tim> title. If the IESG were to say let's rename it "Networking tim> Principles for tim> Future IPv6 Home Networks" then I would lose no sleep. That's not the name I would pick. I think it is too weak: there is significant design decisions made. We have something which is much more than requirements, but not quite architectural. In *building* terms (where we think we know the waterfall process of architecture, civil, structure engineering, and construction planning, but really we are wrong. It's way more complex than we think)... We know how many stories the building will have... but it might be that putting the highest efficiency HVAC on the roof will reduce that by one. We know that the building will have a glass exterior, but the exact dimensions of the panes is not yet known, estetically and weight wise, it's understood, and they won't be mirrored because the neighbours won't like that... but there are seismic considerations, and a new city bylaw on mitigation of falling glass... (to make some stuff up) -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson , Sandelman Software Works --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUkG0k4qHRg3pndX9AQJ+RwP/WxoqJ7uZ6g4lQhUM1FeuoCot+ZgJXSpl wKQizNjXWsGIkWjgQOlOuxDAODj0ddylNxE5FNuzwprtTWR2rHfjuJxqIjQrF/rX zfTBs1Da+kX4etEmD3SExBZuNRFqytP2FiFn7y76bdl8FLgevYMUxVgKE5q55bHw qggU1H2F7HY= =0V72 -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Tue Sep 24 10:22:26 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7421421F9E4F; Tue, 24 Sep 2013 10:22:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YPRYTp5yQvq2; Tue, 24 Sep 2013 10:22:18 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id D8F8821F9A72; Tue, 24 Sep 2013 10:22:12 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 424682024C; Tue, 24 Sep 2013 14:31:26 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 0B1F963B18; Tue, 24 Sep 2013 13:22:02 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id E131563848; Tue, 24 Sep 2013 13:22:02 -0400 (EDT) From: Michael Richardson To: Ted Lemon In-Reply-To: <76716D93-E946-4682-BE1C-CF2DC0434CE5@nominum.com> References: <6.2.5.6.2.20130914143222.0b9590f0@elandnews.com> <6.2.5.6.2.20130918225335.0d0e2478@elandnews.com> <14439.1380035891@sandelman.ca> <76716D93-E946-4682-BE1C-CF2DC0434CE5@nominum.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca X-Mailman-Approved-At: Thu, 26 Sep 2013 10:48:26 -0700 Cc: "" , S Moonesamy , Tim Chown , The IESG , draft-ietf-homenet-arch.all@tools.ietf.org, "homenet@ietf.org Group" Subject: Re: [apps-discuss] [homenet] APPSDIR review of draft-ietf-homenet-arch-10 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 17:22:26 -0000 --=-=-= Ted Lemon wrote: >> I think that it should say: >> "Requirements for Home Networking for IPv6" >> >> (But, it's really more than requirements. It's just less than architecture) > I previously suggested "Preliminary architecture ..." Would that > address your concern? I don't think it's precisely a requirements > document; the document does what the working group currently needs it to > do, and I would hate to see us spend another couple of meeting cycles > turning it into a formal requirements document unless someone can make > clear argument that doing so is necessary. I agree. It's not the document that's wrong: the document does exactly what the WG needs. And I agree that it's not *formal* requirements. What it is *consensus requirements". Perhaps there is a more eloquent phrase that eludes me. -- Michael Richardson , Sandelman Software Works --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUkHKOYqHRg3pndX9AQLACgP/W7bvymOlcWq37DLgsYvgaOpjI3vD64W+ ylJEkn+4OyNVFkp52H40wLCDHFiDnPGrwwISRMWgjauStq+rJpbuh4cjnAJtULLs 5oKwcn3yaZk6bJY3bO679tUnhh7MTYU73VJCNWHhupLhIkm6rsyJgCwpzgNbllP/ QiHD6bouILU= =fso/ -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Tue Sep 24 10:25:18 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48ED511E8172; Tue, 24 Sep 2013 10:25:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kBRJ6L7LvfwE; Tue, 24 Sep 2013 10:25:12 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 136D221E8064; Tue, 24 Sep 2013 10:25:10 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 805882024C; Tue, 24 Sep 2013 14:34:24 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 6690E63B18; Tue, 24 Sep 2013 13:25:01 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 53AFE63848; Tue, 24 Sep 2013 13:25:01 -0400 (EDT) From: Michael Richardson To: Ray Bellis In-Reply-To: <53F00E5CD8B2E34C81C0C89EB0B4FE732DEB122E@wds-exc1.okna.nominet.org.uk> References: <6.2.5.6.2.20130914143222.0b9590f0@elandnews.com> <6.2.5.6.2.20130918225335.0d0e2478@elandnews.com> <6.2.5.6.2.20130919074156.0cd2d900@elandnews.com> <3105F809-7E03-41D9-A634-DE32446FB19B@nominum.com> <89570788-2319-4922-B8DD-4359349683F7@ecs.soton.ac.uk> <19897.1380037779@sandelman.ca> <53F00E5CD8B2E34C81C0C89EB0B4FE732DEB122E@wds-exc1.okna.nominet.org.uk> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca X-Mailman-Approved-At: Thu, 26 Sep 2013 10:48:26 -0700 Cc: "" , S Moonesamy , Tim Chown , The IESG , "" , "homenet@ietf.org Group" , Ted Lemon Subject: Re: [apps-discuss] [homenet] APPSDIR review of draft-ietf-homenet-arch-10 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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 Sep 2013 17:25:18 -0000 --=-=-= Ray Bellis wrote: >> understood, and they won't be mirrored because the neighbours won't like >> that... but there are seismic considerations, and a new city bylaw on >> mitigation of falling glass... (to make some stuff up) > So would you consider what we have now to be a "framework" ? /me makes sign of cross, reaches for wooden dagger and mutters a few hail mary's. === translation: "framework" is an evil word. A vampire that won't die. I think it's content-free at this point. -- Michael Richardson , Sandelman Software Works --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUkHK7YqHRg3pndX9AQLjyAP/artgg3OKV0mo6REzu7Qz3g3sYJ0re7fj 8ryR36AB1V/I1B6+kjX+EuhgAfioamKmsa365Ox8zoG4gXaSa1Q6w+L0bhROrcuV 9pHdfS64x3V566T9/TBcYOH/hgmdhOytHXpOUEYf25FlyB0gyv7fqZ7ozw0CAwD6 Kqkgpdm8XKk= =Qooa -----END PGP SIGNATURE----- --=-=-=-- From salvatore.loreto@ericsson.com Thu Sep 26 11:23:46 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43BA821F9CA4 for ; Thu, 26 Sep 2013 11:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.455 X-Spam-Level: X-Spam-Status: No, score=-103.455 tagged_above=-999 required=5 tests=[AWL=-0.856, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eJcHrtXRDHdw for ; Thu, 26 Sep 2013 11:23:40 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 329B321E8099 for ; Thu, 26 Sep 2013 11:23:28 -0700 (PDT) X-AuditID: c1b4fb38-b7fcf8e0000062b8-68-52447b9f50e8 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 52.DE.25272.F9B74425; Thu, 26 Sep 2013 20:23:28 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.183.18) by smtp.internal.ericsson.com (153.88.183.62) with Microsoft SMTP Server id 14.2.328.9; Thu, 26 Sep 2013 20:23:27 +0200 Received: from Salvatore-Loretos-MacBook-Pro.local (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 6E66E11024B; Thu, 26 Sep 2013 21:23:27 +0300 (EEST) Message-ID: <52447BA0.1030204@ericsson.com> Date: Thu, 26 Sep 2013 20:23:28 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "apps-discuss@ietf.org" , Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLJMWRmVeSWpSXmKPExsUyM+Jvre6Capcgg/dvWSxWv1zBZrFr73lm ByaPJUt+Mnl8ufyZLYApissmJTUnsyy1SN8ugStj2Yk+xoLXrBX7t79gaWB8x9LFyMkhIWAi Mbn7AiOELSZx4d56ti5GLg4hgaOMEhOXPWICSQgJrGeUuPtCHMI+xijx/a0ciM0roC1x6XEb G4jNIqAq0TzzNlg9m4CZxPOHW5hBbFGBZImmy/dZIOoFJU7OfAJmiwhkSBz/cwCsRljATmLV 7wXsIDazgIXE4jcHoWx5ieats5kh9mpJ9J7tZJrAyD8LyahZSFpmIWlZwMi8ipGjOLU4KTfd yGATIzDIDm75bbGD8fJfm0OM0hwsSuK8H986BwkJpCeWpGanphakFsUXleakFh9iZOLglGpg zG1dPvs3R+iKv4XWmvlSHn4lsU4Lajx//UlulHzCzvZw7ub1+pYsXb2/rAVyTjiZcFvyOBsc D1rAsidWefOvZxf3q+hK/QoPjX48NTNPMa/kzEvBe80MLdN91lpf0RDVeGdQJPbG+vX2YOaL kgcuaAX0uaq+cOjS/Na/tPDSXQe1qwd/SmQpsRRnJBpqMRcVJwIAt3+LzQACAAA= Subject: [apps-discuss] AppsDir review of draft-ietf-dime-app-design-guide-19 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 26 Sep 2013 18:23:46 -0000 I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see ​ http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ). Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-dime-app-design-guide-19 Title: Diameter Applications Design Guidelines Reviewer: Salvatore Loreto Review Date: Sept-26-2013 Summary: This draft is ready for publication as Informational. Major Issues: none Minor Issues: none Nits: none best regards Salvatore -- Salvatore Loreto, PhD www.sloreto.com From blueroofmusic@gmail.com Thu Sep 26 14:01:21 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C99AA21E8083 for ; Thu, 26 Sep 2013 14:01:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.511 X-Spam-Level: X-Spam-Status: No, score=-1.511 tagged_above=-999 required=5 tests=[AWL=0.488, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9J0sjfkZEmGe for ; Thu, 26 Sep 2013 14:01:17 -0700 (PDT) Received: from mail-qa0-x22f.google.com (mail-qa0-x22f.google.com [IPv6:2607:f8b0:400d:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id BC38721E80B5 for ; Thu, 26 Sep 2013 14:01:09 -0700 (PDT) Received: by mail-qa0-f47.google.com with SMTP id k4so4731560qaq.20 for ; Thu, 26 Sep 2013 14:01:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=CKrjpGTdmGfnCaLWGr17E46ZPafqLXKZhF8S4j86+b8=; b=X9ocGn28VHXP7dLMgCVDCYSFsDbMVlxf76t/5ZmIbdpUUP2sNOqlT7YDDtIuVO6pwB ZupkJ/Hd9zpBF+gyVgjra54KErEvbENpdq9//NmG1GdnFQV5ClQFtqj0dYdNWH9CWf+p dO51ARe9xn1jw/26Egyj5sex8LNo+kX1GNfakL8hTKDPL1VOt3Q/6ADEJNujp9VEqXZm h0SFaSh6vVz5F0k+KYxwXhbI0fB0ePVo0qNeVohthcVH9Lva91fUfHNt4konBLhi4Zz8 CPoQ+zJ+B3TECefJlKqC4hg8UWu59Lgxk83BYHtaEWk7Ty0+rV8NZVLl8QaAh8SITu2d YvmQ== X-Received: by 10.49.30.227 with SMTP id v3mr4335160qeh.92.1380229268924; Thu, 26 Sep 2013 14:01:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.116.11 with HTTP; Thu, 26 Sep 2013 14:00:48 -0700 (PDT) In-Reply-To: <0f5d01cebade$007e3420$4001a8c0@gateway.2wire.net> References: <042201cebaa9$529a3400$4001a8c0@gateway.2wire.net> <0f5d01cebade$007e3420$4001a8c0@gateway.2wire.net> From: Ira McDonald Date: Thu, 26 Sep 2013 17:00:48 -0400 Message-ID: To: "t.petch" , Ira McDonald Content-Type: multipart/alternative; boundary=047d7bd767ae4870c604e74faba3 Cc: Michael R Sweet , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Request for Apps Area review of IPP over HTTPs and 'ipps' URI Scheme (19 September 2013) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 26 Sep 2013 21:01:21 -0000 --047d7bd767ae4870c604e74faba3 Content-Type: text/plain; charset=ISO-8859-1 Hi Tom, Thanks your quick and helpful replies. Review by the Security Directorate would certainly be a good idea. We can *recommend* other cipher suites, in addition to the requirements in RFC 5246, but we can't *mandate* those, because a LOT of printers have shipped w/ 'ipps' support for several years now. We'll make your other suggested changes in the next draft. The IPP over HTTPS Transport Binding and 'ipps' URI Scheme (which mandates starting TLS before sending any HTTP requests) is just an alternative to 'ipp' URI Scheme (RFC 3510). This spec does not update RFC 3510. In general 'ipp' URI should only be used inside an enterprise network - they are not safe in the public Internet. I think it's better to move the review of the order of protocol setups in RFC 3510 back to an appendix. Only operating system vendors and printer vendors will ever read this RFC (probably), because the hoped for uptake of IPP/1.1 by browser vendors never happened. Cheers, - Ira Ira McDonald (Musician / Software Architect) Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG IPP WG Co-Chair - TCG Trusted Mobility Solutions WG Chair - TCG Embedded Systems Hardcopy SG IETF Designated Expert - IPP & Printer MIB Blue Roof Music/High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto:blueroofmusic@gmail.com Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 On Thu, Sep 26, 2013 at 1:29 PM, t.petch wrote: > ----- Original Message ----- > From: "Ira McDonald" > To: "t.petch" ; "Ira McDonald" > > Cc: ; "Michael R Sweet" > Sent: Thursday, September 26, 2013 4:48 PM > > Hi Tom, > > > > Thanks for you comments and questions. My replies are inline below. > > > > Cheers, > > - Ira > > > > On Thu, Sep 26, 2013 at 7:11 AM, t.petch wrote: > > > > > Ira > > > > > > The aspect that strikes me most is not so much an apps one as a > security > > > one, that current I-Ds using TLS tend to say more about what forms > of > > > security are acceptable. For example, there has been much recently > > > about the checks to perform on a certificate and often there are > > > comments about the acceptable cipher suites. Also, all the > references > > > are to TLS 1.2 which, last I saw, is not widely supported - again, I > > > would expect some comment thereon. I expect that the applicability > of > > > this is not the usual 'across the public Internet' one which may > colour > > > what is acceptable. > > > > > > > We brought this document to the IETF Apps Area because all original > > IETF IPP standards were developed there, including RFC 3510. > > > > The intended usage is primarily 'across the public Internet', in > support of > > IEEE-ISTO PWG IPP Everywhere (PWG 5100.14) which support high-function > > printing from mobile devices (cellphones, tablets, laptops). Mobile > phones > > and major operating systems are now implementing this standard. > > > > > ftp://ftp.pwg.org/pub/pwg/candidates/cs-ippeve10-20130128-5100.14.pdf > > > > In the near future, this intended usage will be much more important > with the > > new IPP Shared Infrastructure Extensions (new IPP cloud print > operations). > > > > ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippsix10-20130923-rev.pdf > > > > TLS 1.2 is commonly supported by printers and multifunction devices, > due > > due to use of IPP/2.0 w/ TLS 1.2 in the Apple AirPrint technology in > 2010. > > > > We didn't want to place mandatory conformance requirements on TLS 1.2 > > usage, beyond those specified in RFC 5246 itself. Since quite a few > cipher > > suites are now defined for use w/ TLS 1.2, this seems problematic. > Your > > advice and guidance would be much appreciated. > > > > We could consider allowing alternate use of TLS 1.1, if that's > appropriate, > > although IPP Everywhere certified printers will begin shipping in > October, > > so we'll have to be a bit careful in making changes. > > Ira > > TLS 1.2 is quite rare but has few flaws, TLS 1.0 is common but flawed, > so if you can get support for 1.2, then that is the right choice. > > You do not have interoperability without a common ciphersuite so I am > used to 'XXX over TLS' specifying one, even if it is the default from > RFC5246 - TLS_RSA_WITH_AES_128_CBC_SHA - (which is, perhaps, not as > secure as it might be, e.g. not for a protocol which will be around for > a long time in exposed places and, I imagine, will see a lot of attacks, > not something I realised on first reading. I am not competent to assess > the threats and recommend a better one but I do see the discussions > thereof on the TLS list. I would like to see a Security Directorate > review sooner rather than later. In general, I see much more focus on > this aspect of protocols than a few years ago and so was expecting a > stronger Security Considerations). > > > > > > > Otherwise, I find the style slightly unfamiliar. > > > > > > The abbreviations come at the end whereas they are commonly at the > > > beginning. > > > > > I'm confused - do you mean "ABC (Another Big Cloud)" or the location > of > > the Abbreviations section in an appendix? We put this section in an > > appendix based on advice on the IETF URI review mailing list, although > > the IEEE-ISTO PWG document template now puts it into section 2 with > > other terminology - would that be more appropriate? > > I am used to RFC putting it in section 2 (and I am used to URI reviews > on the uri@w3.org list, where I would have commented earlier:-). > > > There is a non-normative section 3 in the middle of normative ones - > > > commonly, that is an appendix. > > > > > > > Should we move the informative section 3.1 to an appendix? It was > placed > > in section 3 to introduce the behavior differences between 'ipp' and > 'ipps' > > URI schemes. > > You clearly label it as Informative so .... Is your intended audience > one that is already familiar with ipp scheme? If so, I would move it, > if not, leave it alone. > > > > The definitions in section 2 I would find easier without the > repeated > > > In this document, > > > which I think redundant. > > > > > > > Thanks - we'll remove the redundant phrases. > > > > > You include query in the scheme syntax but it is never reference or > > > appears in any example. > > > > > > > We included it because it was present in RFC 3510 and RFC 3986. It is > > *never* used in the IPP protocol (on port 631), because filtering is > done > > in-band in the IPP Get-Printer-Attributes and Get-Job-Attributes > > operations. > > > > Should we just remove the query syntax? This could cause breakage > > with some existing IPP print spoolers, since it was present in RFC > 3510. > > No, but add a comment on its nonuse as you have here. > > > > Has this I-D any relationship to RFC3510? > > > > > > > Yes - it complements RFC 3510, as stated in Appendix A and elsewhere. > > > > The 'ipps' URI scheme was developed first in CUPS (standard print > spooler > > on Mac OS X and all UNIX and Linux distributions) because printers > were > > in fact not supporting HTTP TLS Upgrade (RFC 2817) or else were doing > it > > wrong (e.g., partway through an IPP session - defeating strong > > authentication > > of client identity). > > > > For mobile print over the public Internet, failure to negotiate a TLS > secure > > transport with data encryption is not acceptable. > > > > Should we add discussion of the relationship to RFC 3510 to > Introduction? > > Good idea but I was thinking more does this update RFC3510 in any way, > or just sit alongside it as an alternative? > > Tom Petch > > > > > > > --047d7bd767ae4870c604e74faba3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Tom,

Thanks your quick and helpful replies.
=
Review by the Security Directorate would certainly be a good idea= .

We can *recommend* other cipher suites, in addition to the requir= ements
in RFC 5246, but we can't *mandate* those, because a LO= T of printers
have shipped w/ 'ipps' support for several y= ears now.

We'll make your other suggested changes in the next draft.
The IPP over HTTPS Transport Binding and 'ipps' URI Sche= me (which
mandates starting TLS before sending any HTTP requests) is jus= t an
alternative to 'ipp' URI Scheme (RFC 3510).=A0 This spe= c does not
update RFC 3510.=A0 In general 'ipp' URI should= only be used inside
an enterprise network - they are not saf= e in the public Internet.

I think it's better to move the review of the orde= r of protocol setups
in RFC 3510 back to an appendix.=A0 Only ope= rating system vendors
and printer vendors will ever read this RFC = (probably), because the
hoped for uptake of IPP/1.1 by browser vendors never happened.

Cheers,
- Ira


Ira McDonald (Musician / Software Architect)
Chair - Linux Foundati= on Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Ch= air - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Trusted Mobility Solutions WG<= br> Chair - TCG Embedded Systems Hardcopy SG
IETF Designated Expert - IPP &a= mp; Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthincmailto:bluer= oofmusic@gmail.com
Winter=A0 579 Park Place=A0 Saline, MI=A0 48176=A0 734-944-0094
Summer= =A0 PO Box 221=A0 Grand Marais, MI 49839=A0 906-494-2434



On Thu, Sep 26, 2013 at 1:29 PM, t.petch= <ietfc@btconnect.com> wrote:
----- Original Message -----
From: "Ira McDonald" <blueroofmusic@gmail.com>
To: "t.petch" <ietfc@btconnect.com>; "Ira McDonald"
<blueroofmusic@gmail.com&= gt;
Cc: <apps-discuss@ietf.org&= gt;; "Michael R Sweet" <ms= weet@apple.com>
Sent: Thursday, September 26, 2013 4:48 PM
> Hi Tom,
>
> Thanks for you comments and questions. =A0My replies are inline below.=
>
> Cheers,
> - Ira
>
> On Thu, Sep 26, 2013 at 7:11 AM, t.petch = <ietfc@btconnect.com> wrot= e:
>
> > Ira
> >
> > The aspect that strikes me most is not so much an apps one as a security
> > one, that current I-Ds using TLS tend to say more about what form= s
of
> > security are acceptable. =A0For example, there has been much rece= ntly
> > about the checks to perform on a certificate and often there are<= br> > > comments about the acceptable cipher suites. =A0Also, all the
references
> > are to TLS 1.2 which, last I saw, is not widely supported - again= , I
> > would expect some comment thereon. =A0I expect that the applicabi= lity
of
> > this is not the usual 'across the public Internet' one wh= ich may
colour
> > what is acceptable.
> >
>
> We brought this document to the IETF Apps Area because all original > IETF IPP standards were developed there, including RFC 3510.
>
> The intended usage is primarily 'across the public Internet', = in
support of
> IEEE-ISTO PWG IPP Everywhere (PWG 5100.14) which support high-function=
> printing from mobile devices (cellphones, tablets, laptops). =A0Mobile=
phones
> and major operating systems are now implementing this standard.
>
>
ftp://ftp.pwg.org/pub/pwg/candidates/cs-ippeve10-2= 0130128-5100.14.pdf
>
> In the near future, this intended usage will be much more important with the
> new IPP Shared Infrastructure Extensions (new IPP cloud print
operations).
>
> =A0 ftp://ftp.pwg.org/pub/pwg/ipp/wd/wd-ippsix10-2013= 0923-rev.pdf
>
> TLS 1.2 is commonly supported by printers and multifunction devices, due
> due to use of IPP/2.0 w/ TLS 1.2 in the Apple AirPrint technology in 2010.
>
> We didn't want to place mandatory conformance requirements on TLS = 1.2
> usage, beyond those specified in RFC 5246 itself. =A0Since quite a few=
cipher
> suites are now defined for use w/ TLS 1.2, this seems problematic.
Your
> advice and guidance would be much appreciated.
>
> We could consider allowing alternate use of TLS 1.1, if that's
appropriate,
> although IPP Everywhere certified printers will begin shipping in
October,
> so we'll have to be a bit careful in making changes.

Ira

TLS 1.2 is quite rare but has few flaws, TLS 1.0 is common but flawed,
so if you can get support for 1.2, then that is the right choice.

You do not have interoperability without a common ciphersuite so I am
used to 'XXX over TLS' specifying one, even if it is the default fr= om
RFC5246 - TLS_RSA_WITH_AES_128_CBC_SHA - (which is, perhaps, not as
secure as it might be, e.g. not for a protocol which will be around for
a long time in exposed places and, I imagine, will see a lot of attacks, not something I realised on first reading. =A0I am not competent to assess<= br> the threats and recommend a better one but I do see the discussions
thereof on the TLS list. =A0I would like to see a Security Directorate
review sooner rather than later. =A0In general, I see much more focus on this aspect of protocols than a few years ago and so was expecting a
stronger Security Considerations).

> >
> > Otherwise, I find the style slightly unfamiliar.
> >
> > The abbreviations come at the end whereas they are commonly at th= e
> > beginning.
> >
> I'm confused - do you mean "ABC (Another Big Cloud)" or = the location
of
> the Abbreviations section in an appendix? =A0We put this section in an=
> appendix based on advice on the IETF URI review mailing list, although=
> the IEEE-ISTO PWG document template now puts it into section 2 with > other terminology - would that be more appropriate?

I am used to RFC putting it in section 2 (and I am used to URI review= s
on the uri@w3.org list, where I would hav= e commented earlier:-).

> There is a non-normative section 3 in the middle of normative ones - > > commonly, that is an appendix.
> >
>
> Should we move the informative section 3.1 to an appendix? =A0It was placed
> in section 3 to introduce the behavior differences between 'ipp= 9; and
'ipps'
> URI schemes.

You clearly label it as Informative so .... =A0Is your intended audie= nce
one that is already familiar with ipp scheme? =A0If so, I would move it, if not, leave it alone.

> > The definitions in section 2 I would find easier without the
repeated
> > =A0In this document,
> > which I think redundant.
> >
>
> Thanks - we'll remove the redundant phrases.
>
> > You include query in the scheme syntax but it is never reference = or
> > appears in any example.
> >
>
> We included it because it was present in RFC 3510 and RFC 3986. It is<= br> > *never* used in the IPP protocol (on port 631), because filtering is done
> in-band in the IPP Get-Printer-Attributes and Get-Job-Attributes
> operations.
>
> Should we just remove the query syntax? =A0 This could cause breakage<= br> > with some existing IPP print spoolers, since it was present in RFC
3510.

No, but add a comment on its nonuse as you have here.

> > Has this I-D any relationship to RFC3510?
> >
>
> Yes - it complements RFC 3510, as stated in Appendix A and elsewhere.<= br> >
> The 'ipps' URI scheme was developed first in CUPS (standard pr= int
spooler
> on Mac OS X and all UNIX and Linux distributions) because printers
were
> in fact not supporting HTTP TLS Upgrade (RFC 2817) or else were doing<= br> it
> wrong (e.g., partway through an IPP session - defeating strong
> authentication
> of client identity).
>
> For mobile print over the public Internet, failure to negotiate a TLS<= br> secure
> transport with data encryption is not acceptable.
>
> Should we add discussion of the relationship to RFC 3510 to
Introduction?

Good idea but I was thinking more does this update RFC3510 in any way= ,
or just sit alongside it as an alternative?

Tom Petch

> ><snip>



--047d7bd767ae4870c604e74faba3-- From wwwrun@rfc-editor.org Fri Sep 27 14:44:19 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E25921F994A; Fri, 27 Sep 2013 14:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102 X-Spam-Level: X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id syq3em1E79id; Fri, 27 Sep 2013 14:44:18 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 2FE2B21F970E; Fri, 27 Sep 2013 14:44:13 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 8CCB5B1E00B; Fri, 27 Sep 2013 14:37:11 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20130927213711.8CCB5B1E00B@rfc-editor.org> Date: Fri, 27 Sep 2013 14:37:11 -0700 (PDT) Cc: drafts-update-ref@iana.org, apps-discuss@ietf.org, rfc-editor@rfc-editor.org Subject: [apps-discuss] RFC 7033 on WebFinger X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 27 Sep 2013 21:44:19 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7033 Title: WebFinger Author: P. Jones, G. Salgueiro, M. Jones, J. Smarr Status: Standards Track Stream: IETF Date: September 2013 Mailbox: paulej@packetizer.com, gsalguei@cisco.com, mbj@microsoft.com, jsmarr@google.com Pages: 28 Characters: 61552 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-appsawg-webfinger-18.txt URL: http://www.rfc-editor.org/rfc/rfc7033.txt This specification defines the WebFinger protocol, which can be used to discover information about people or other entities on the Internet using standard HTTP methods. WebFinger discovers information for a URI that might not be usable as a locator otherwise, such as account or email URIs. This document is a product of the Applications Area Working Group Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search/rfc_search.php For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From gsalguei@cisco.com Fri Sep 27 15:09:18 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C16D621F9E50; Fri, 27 Sep 2013 15:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EM6qqCUF9bSt; Fri, 27 Sep 2013 15:09:14 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id C6DBC21F8E51; Fri, 27 Sep 2013 15:09:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3078; q=dns/txt; s=iport; t=1380319754; x=1381529354; h=from:to:cc:subject:date:message-id:references:content-id: content-transfer-encoding:mime-version; bh=RTsHxg6AO/eArGv9aWE0zEe/fvRvcd0kP5muWf+H2h0=; b=V02l1IRYwg2z6PFm0WqEhFH6i4IQJ4M5KfRAsDYlfMRCDMaLB7+A7H2b dEGRlcd937I1sEo4dAjtYepnfuDTIcOwJ9BQaPfUoJP6G5hzFpVzTHwGB aFyaBQVrTRHBA3FfQZB3IVZFNtEN+gvLHvbcLMpRNpM7rp2wyGbTgMs6i k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFACABRlKtJXHB/2dsb2JhbABBGoMHOFLAU4EhFnSCJQEBAQMBAQEBNxQgCwULAgEZAwECCwIJCRAnCgEbAggCBAENBQgBCwcCBIdfBgw2uVWOCA+BCTECCwSDFYEBA5kuiw+FOoMkgXE5 X-IronPort-AV: E=Sophos;i="4.90,996,1371081600"; d="scan'208";a="265472757" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-2.cisco.com with ESMTP; 27 Sep 2013 22:09:13 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r8RM9Cmh023868 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 27 Sep 2013 22:09:13 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.202]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Fri, 27 Sep 2013 17:09:12 -0500 From: "Gonzalo Salgueiro (gsalguei)" To: webfinger , "apps-discuss@ietf.org application-layer protocols" Thread-Topic: [rfc-dist] RFC 7033 on WebFinger Thread-Index: AQHOu8q8WK9MXW8PR0WCym9pkH25Xw== Date: Fri, 27 Sep 2013 22:09:12 +0000 Message-ID: References: <20130927213711.8CCB5B1E00B@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.132.55] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "webfinger@googlegroups.com" Subject: [apps-discuss] Fwd: [rfc-dist] RFC 7033 on WebFinger X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 27 Sep 2013 22:09:19 -0000 [Forgive the cross-post...] Finally, we've arrived! Thanks to the many of you who generously contribu= ted. An especially big shout out to Paul Jones for his passion and dedicat= ion, who as editor had the unenviable job of trying to appease everyone. Cheers, Gonzalo Begin forwarded message: > From: > Subject: [rfc-dist] RFC 7033 on WebFinger > Date: September 27, 2013 5:37:11 PM EDT > To: , > Cc: , , >=20 > A new Request for Comments is now available in online RFC libraries. >=20 >=20 > RFC 7033 >=20 > Title: WebFinger=20 > Author: P. Jones, G. Salgueiro, > M. Jones, J. Smarr > Status: Standards Track > Stream: IETF > Date: September 2013 > Mailbox: paulej@packetizer.com,=20 > gsalguei@cisco.com,=20 > mbj@microsoft.com, > jsmarr@google.com > Pages: 28 > Characters: 61552 > Updates/Obsoletes/SeeAlso: None >=20 > I-D Tag: draft-ietf-appsawg-webfinger-18.txt >=20 > URL: http://www.rfc-editor.org/rfc/rfc7033.txt >=20 > This specification defines the WebFinger protocol, which can be used > to discover information about people or other entities on the > Internet using standard HTTP methods. WebFinger discovers > information for a URI that might not be usable as a locator > otherwise, such as account or email URIs. >=20 > This document is a product of the Applications Area Working Group Working= Group of the IETF. >=20 > This is now a Proposed Standard. >=20 > STANDARDS TRACK: This document specifies an Internet standards track > protocol for the Internet community,and requests discussion and suggestio= ns > for improvements. Please refer to the current edition of the Internet > Official Protocol Standards (STD 1) for the standardization state and > status of this protocol. Distribution of this memo is unlimited. >=20 > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist >=20 > For searching the RFC series, see http://www.rfc-editor.org/search/rfc_se= arch.php > For downloading RFCs, see http://www.rfc-editor.org/rfc.html >=20 > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. >=20 >=20 > The RFC Editor Team > Association Management Solutions, LLC >=20 >=20 > _______________________________________________ > rfc-dist mailing list > rfc-dist@rfc-editor.org > https://www.rfc-editor.org/mailman/listinfo/rfc-dist > http://www.rfc-editor.org From Michael.Jones@microsoft.com Fri Sep 27 15:42:48 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F84211E8102; Fri, 27 Sep 2013 15:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HOkgC0KPYN2c; Fri, 27 Sep 2013 15:42:43 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0243.outbound.protection.outlook.com [207.46.163.243]) by ietfa.amsl.com (Postfix) with ESMTP id 94B1811E80DE; Fri, 27 Sep 2013 15:42:43 -0700 (PDT) Received: from BLUPR03CA028.namprd03.prod.outlook.com (10.141.30.21) by BLUPR03MB036.namprd03.prod.outlook.com (10.255.209.148) with Microsoft SMTP Server (TLS) id 15.0.775.9; Fri, 27 Sep 2013 22:42:42 +0000 Received: from BN1AFFO11FD039.protection.gbl (2a01:111:f400:7c10::195) by BLUPR03CA028.outlook.office365.com (2a01:111:e400:879::21) with Microsoft SMTP Server (TLS) id 15.0.775.9 via Frontend Transport; Fri, 27 Sep 2013 22:42:42 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1AFFO11FD039.mail.protection.outlook.com (10.58.52.243) with Microsoft SMTP Server (TLS) id 15.0.785.10 via Frontend Transport; Fri, 27 Sep 2013 22:42:41 +0000 Received: from TK5EX14MBXC290.redmond.corp.microsoft.com ([169.254.1.39]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.03.0136.001; Fri, 27 Sep 2013 22:41:52 +0000 From: Mike Jones To: "Gonzalo Salgueiro (gsalguei)" , webfinger , "apps-discuss@ietf.org application-layer protocols" Thread-Topic: [rfc-dist] RFC 7033 on WebFinger Thread-Index: AQHOu85GOj0585jG5Eq7Bb0S+TyY4JnaLa1Q Date: Fri, 27 Sep 2013 22:41:50 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394371FFCE41@TK5EX14MBXC290.redmond.corp.microsoft.com> References: <20130927213711.8CCB5B1E00B@rfc-editor.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.72] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(51704005)(199002)(189002)(377454003)(69234005)(13464003)(478834004)(16601075003)(77982001)(59766001)(20776003)(63696002)(15202345003)(66066001)(74706001)(15188155005)(81542001)(80022001)(65816001)(79102001)(83072001)(69226001)(56816003)(6806004)(50466002)(47776003)(16799955002)(19300405004)(81342001)(54356001)(23726002)(53806001)(56776001)(81816001)(15975445006)(74876001)(44976005)(76482001)(47976001)(50986001)(4396001)(80976001)(49866001)(51856001)(19580405001)(74502001)(47736001)(55846006)(19580395003)(83322001)(46102001)(31966008)(77096001)(54316002)(74366001)(47446002)(76786001)(76796001)(74662001)(81686001)(33656001)(46406003)(562404015)(6606295002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB036; H:mail.microsoft.com; CLIP:131.107.125.37; FPR:; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 098291215C X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com Cc: "webfinger@googlegroups.com" Subject: Re: [apps-discuss] [rfc-dist] RFC 7033 on WebFinger X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 27 Sep 2013 22:42:48 -0000 FYI, I've posted about this at http://self-issued.info/?p=3D1125 and on Twi= tter as @selfissued. Have a good weekend, everyone! -- Mike -----Original Message----- From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] = On Behalf Of Gonzalo Salgueiro (gsalguei) Sent: Friday, September 27, 2013 3:09 PM To: webfinger; apps-discuss@ietf.org application-layer protocols Cc: webfinger@googlegroups.com Subject: [apps-discuss] Fwd: [rfc-dist] RFC 7033 on WebFinger [Forgive the cross-post...] Finally, we've arrived! Thanks to the many of you who generously contribu= ted. An especially big shout out to Paul Jones for his passion and dedicat= ion, who as editor had the unenviable job of trying to appease everyone. Cheers, Gonzalo Begin forwarded message: > From: > Subject: [rfc-dist] RFC 7033 on WebFinger > Date: September 27, 2013 5:37:11 PM EDT > To: , > Cc: , ,=20 > >=20 > A new Request for Comments is now available in online RFC libraries. >=20 >=20 > RFC 7033 >=20 > Title: WebFinger=20 > Author: P. Jones, G. Salgueiro, > M. Jones, J. Smarr > Status: Standards Track > Stream: IETF > Date: September 2013 > Mailbox: paulej@packetizer.com,=20 > gsalguei@cisco.com,=20 > mbj@microsoft.com, > jsmarr@google.com > Pages: 28 > Characters: 61552 > Updates/Obsoletes/SeeAlso: None >=20 > I-D Tag: draft-ietf-appsawg-webfinger-18.txt >=20 > URL: http://www.rfc-editor.org/rfc/rfc7033.txt >=20 > This specification defines the WebFinger protocol, which can be used=20 > to discover information about people or other entities on the Internet=20 > using standard HTTP methods. WebFinger discovers information for a=20 > URI that might not be usable as a locator otherwise, such as account=20 > or email URIs. >=20 > This document is a product of the Applications Area Working Group Working= Group of the IETF. >=20 > This is now a Proposed Standard. >=20 > STANDARDS TRACK: This document specifies an Internet standards track=20 > protocol for the Internet community,and requests discussion and=20 > suggestions for improvements. Please refer to the current edition of=20 > the Internet Official Protocol Standards (STD 1) for the=20 > standardization state and status of this protocol. Distribution of this = memo is unlimited. >=20 > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist >=20 > For searching the RFC series, see=20 > http://www.rfc-editor.org/search/rfc_search.php > For downloading RFCs, see http://www.rfc-editor.org/rfc.html >=20 > Requests for special distribution should be addressed to either the=20 > author of the RFC in question, or to rfc-editor@rfc-editor.org. =20 > Unless specifically noted otherwise on the RFC itself, all RFCs are=20 > for unlimited distribution. >=20 >=20 > The RFC Editor Team > Association Management Solutions, LLC >=20 >=20 > _______________________________________________ > rfc-dist mailing list > rfc-dist@rfc-editor.org > https://www.rfc-editor.org/mailman/listinfo/rfc-dist > http://www.rfc-editor.org _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss From julian.reschke@gmx.de Mon Sep 30 06:01:56 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 776BD21F9C78 for ; Mon, 30 Sep 2013 06:01:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.293 X-Spam-Level: X-Spam-Status: No, score=-104.293 tagged_above=-999 required=5 tests=[AWL=-3.183, BAYES_05=-1.11, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AszmI6aJvO7t for ; Mon, 30 Sep 2013 06:01:51 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 12AE021F8F29 for ; Mon, 30 Sep 2013 06:01:51 -0700 (PDT) Received: from [192.168.1.102] ([217.91.35.233]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MCLx3-1VZ7YD0cQz-0095hE for ; Mon, 30 Sep 2013 15:01:48 +0200 Message-ID: <5249762E.7010206@gmx.de> Date: Mon, 30 Sep 2013 15:01:34 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Larry Masinter , "apps-discuss@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:uslqMPu988hQ6wWPtEuCmLn5AacY/xHv50CVRf5cnsAimsA74b8 9zf/mmGGt3E9lvPEMrj5m2OfAg0OlVIMTJ6xWHfSQ5yTBAw6Uh8Fbap2qfY2C/K/FqjKSfJ rqVSRTWazTmxq4dsTp/VdzCnRGfChjraKAntDqSKkskFcDGpvnOKCqN9lBn/8sQJ//sRtxE bEuhhvy0lpaaglY07CfCA== Subject: Re: [apps-discuss] Unicode normalization and Content-Disposition filename (RFC6266) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 30 Sep 2013 13:01:56 -0000 On 2013-09-21 23:22, Larry Masinter wrote: > RFC 6266 defines a "filename*" parameter for content-disposition, as well as "filename". > We weren't going to do that for form-data, as it seemed like overkill and no one > implements it. > > While I was looking into this, though, I noticed that RFC6266 doesn't > mention the fact that different file systems handle Unicode normalization > differently. So an a with an accent grave is represented as two Unicode > characters in some file systems and as one Unicode character in another. > > When sending a file name from one system to the other, these representations > need to be mapped, but there is no completely reliable indication of > the file system defaults. > > How is this handled in practice? If I upload a file with an unnormalized > name to a server which uses normalized names for files, who does > the normalization? > ... Funny enough, this just turned into a product issue for me (hey, paid work!). Interesting links: https://bugzilla.mozilla.org/show_bug.cgi?id=695995 and https://www.w3.org/Bugs/Public/show_bug.cgi?id=14526 Best regards, Julian From Claudio.Allocchio@garr.it Mon Sep 30 06:49:06 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C87D921F9BB1 for ; Mon, 30 Sep 2013 06:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.552 X-Spam-Level: X-Spam-Status: No, score=-0.552 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KfQbvCoQ+7CG for ; Mon, 30 Sep 2013 06:48:55 -0700 (PDT) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [193.206.158.29]) by ietfa.amsl.com (Postfix) with ESMTP id E7C0321F9B90 for ; Mon, 30 Sep 2013 06:48:54 -0700 (PDT) Received: internal info suppressed Date: Mon, 30 Sep 2013 15:48:51 +0200 (CEST) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.garrtest.units.it To: apps-discuss@ietf.org Message-ID: User-Agent: Alpine 2.02 (OSX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=garr.it; s=cyrus; t=1380548932; bh=FKHmrC9nhixlmqMbBGWp/u0LhF0O9zr6u1tVaiW1K74=; h=Date:From:To:Subject; b=m2L6BPueFlo7k1H5DiMybe8+gwJwa8AomwZuGVierTf/7xA/yVJz0paLUU66ItgZG Jb1pVaKpaQc0y3afzD+idCnmHjcrYFJ4oDgYtpyBzE/HbH90EgCPph5aqCoUcp0W7P q0LeETXjSr0bBB/Mc1cG64O5cFz/meioLT92d6KM= Subject: [apps-discuss] RFC2326bis reviews received X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 30 Sep 2013 13:49:06 -0000 Hello all, a couple of comments and reviews were sent to the WG chairs directly over the last week, thus maybe it it better to add the also here. See below the messages. ------------------------- >From stpeter@stpeter.im Thu Sep 26 19:28:01 2013 Date: Thu, 26 Sep 2013 11:27:51 -0600 From: Peter Saint-Andre To: mmusic@ietf.org Cc: Claudio Allocchio Subject: base64 and datetimes in 2326bis Here is some brief feedback on 2326bis. I'm sorry that I don't have time for a longer review. BASE64 The usages of Base64 do not specify which exact encoding of Base64 they require and what to do about padding bits. For example, Section 18.54 says: The binary MIKEY message SHALL be Base64 [RFC4648] encoded before being included in the value part of the parameter. If the specification assumes that the rules from Section 4 of RFC 4648 are to be used, that text would be more accurate as: The binary MIKEY message SHALL be BASE64 [RFC4648] encoded before being included in the value part of the parameter, where the encoding adheres to the definition in Section 4 of RFC 4648 and where the padding bits are set to zero. DATETIME FORMATS Section 4.4.3 seems to be underspecified: Absolute time is expressed as ISO 8601 [ISO.8601.2000] timestamps, using UTC (GMT). Fractions of a second may be indicated. Example for clock format range request for a starting time of November 8, 1996 at 14h 37 min and 20 and a quarter seconds UTC playing for 10 min and 5 seconds, a Media-Properties header's "Time- Limited UTC property for 24th of December 2014 at 15 hours and 00 mins, and a Terminate-Readon headers "time" property for 18th of June 2013 at 16 hours, 12 minutes and 56 seconds: clock=19961108T143720.25Z-19961108T144725.25Z Time-Limited=20141224T1500Z time=20130618T161256Z ISO 8601 has many profiles. Is the profile defined in RFC 3339 supported? That would result in a datetime of the following form: 1996-11-08T14:37:20.25Z Also are timezone offsets allowed? If the answers are "no" then it would be good to explain that in the text. Peter -- Peter Saint-Andre https://stpeter.im/ ---------------------------------- >From Claudio.Allocchio@garr.it Mon Sep 30 15:40:43 2013 Date: Mon, 30 Sep 2013 15:40:25 +0200 (CEST) From: Claudio Allocchio To: Magnus Westerlund Cc: Claudio Allocchio , Gonzalo Camarillo , Peter Saint-Andre , draft-ietf-mmusic-rfc2326bis@tools.ietf.org, mmusic-chairs@tools.ietf.org Subject: Re: Review of rfc2326bis Ok, here are the notes I did on v34, which I now checked against v37 (they're from last June...) 1 Intro: - ok no isses 2 Protocol overview - ok no issues. 3.1 Notational Conventions: - nits: "smaller-type" may not be a term which anybody understands immediatley, expecially when reading the official text based RFC-to-be. *** this was fixed already *** 4.1: minore issue: "Leading zeros MUST be ignored by recipients and MUST NOT be sent." Well, we do not really need both compulsory specifications... If leading zeroes MUST NOT be sent, then it will never happen that recipients get them :-) Either "SHALL NOT be sent" and "MUST be ingored" or change the sentence in a different way. 4.4.2: nit: "... not to be confused with the Network Time Protocol" :-) well.. then we have SNMP and SMTP etc etc... I would delete this part of the sentence and its reference. minor issue: ISO.13818-6.1995 (same as your point). 10. Connections. minor issue: should the chapter about connectionless mode be more explicit, stating something like "MUST NOT use connectionless mechanisms" ? indeed the text say the same... but in a much more nromative way. Security Considerations: I made an extensive check of this section and I find it OK, no issues. IPv6 considerations in general: minor issue: the whole specification is still very much IPv4 focused, apart making compulsory the acceptance of IPv6 literal addresses. But it should be made explicit in various sections (see for example proxies and NAT etc...) that there are IPv4 only specific parts. I did not find other evident issues in the other sections. Claudio From jonathan.robie@emc.com Sat Sep 28 15:33:10 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9C8E11E8127 for ; Sat, 28 Sep 2013 15:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hkHadhgAuoVQ for ; Sat, 28 Sep 2013 15:33:06 -0700 (PDT) Received: from mailuogwdur.emc.com (mailuogwdur.emc.com [128.221.224.79]) by ietfa.amsl.com (Postfix) with ESMTP id 0DA1D11E8107 for ; Sat, 28 Sep 2013 15:33:04 -0700 (PDT) Received: from maildlpprd55.lss.emc.com (maildlpprd55.lss.emc.com [10.106.48.159]) by mailuogwprd52.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id r8SMWvNH024290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 28 Sep 2013 18:32:57 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com r8SMWvNH024290 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1380407577; bh=nzuKq+E9rTNO4ru2HIKuxhSi1OY=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=q/6GmgyJUHrTfKoF8com8hy+9ZFxFoR6w7ygx5PZXGeQNs6cnLaqqtxM5GBeOQur2 yedAdjtC+YSPEXn5GeQKBe9ljxoM+PHKa7K2o4LZMxif4Tend3yQKBdNOCtJkQjjn9 aTWVAHaR2weudHG6E8zJEVidjAAOrDI9HGAKNRhw= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd52.lss.emc.com r8SMWvNH024290 Received: from mailusrhubprd52.lss.emc.com (mailusrhubprd52.lss.emc.com [10.106.48.25]) by maildlpprd55.lss.emc.com (RSA Interceptor) for ; Sat, 28 Sep 2013 18:32:49 -0400 Received: from mxhub16.corp.emc.com (mxhub16.corp.emc.com [128.222.70.237]) by mailusrhubprd52.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id r8SMWmrc026045 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 28 Sep 2013 18:32:48 -0400 Received: from MXHUB108.corp.emc.com (10.253.58.24) by mxhub16.corp.emc.com (128.222.70.237) with Microsoft SMTP Server (TLS) id 8.3.297.1; Sat, 28 Sep 2013 18:32:48 -0400 Received: from MX104CL01.corp.emc.com ([169.254.7.202]) by MXHUB108.corp.emc.com ([10.253.58.24]) with mapi id 14.02.0342.003; Sat, 28 Sep 2013 18:32:48 -0400 From: "Robie, Jonathan" To: "apps-discuss@ietf.org" Thread-Topic: Deleting all members of an Atompub collection Thread-Index: Ac68mqe2g3LkzQPaQvapghIYsaW12g== Date: Sat, 28 Sep 2013 22:32:47 +0000 Message-ID: <41539B7FA57A2A4A9FB00AB9F328823339C8DAA5@MX104CL01.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.13.39.106] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd52.lss.emc.com X-EMM-GWVC: 1 X-EMM-McAfeeVC: 1 X-RSA-Classifications: public X-Mailman-Approved-At: Mon, 30 Sep 2013 10:13:08 -0700 Subject: [apps-discuss] Deleting all members of an Atompub collection X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 28 Sep 2013 22:33:10 -0000 Are there established conventions for deleting all members of a collection? Atompub does not provide this functionality, what is the best idiom to exte= nd its functionality to make this possible? Jonathan From lionel.morand@orange.com Thu Sep 26 17:06:41 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FE6021E80D4 for ; Thu, 26 Sep 2013 17:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.656 X-Spam-Level: X-Spam-Status: No, score=-2.656 tagged_above=-999 required=5 tests=[AWL=-0.058, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8iCeq0zRXmRG for ; Thu, 26 Sep 2013 17:06:37 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by ietfa.amsl.com (Postfix) with ESMTP id CFD6821E80DE for ; Thu, 26 Sep 2013 17:06:20 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 0C4A42AC28E; Fri, 27 Sep 2013 02:06:14 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id E7D54384094; Fri, 27 Sep 2013 02:06:13 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Fri, 27 Sep 2013 02:06:13 +0200 From: To: Salvatore Loreto , "apps-discuss@ietf.org" , "draft-ietf-dime-app-design-guide@tools.ietf.org" Thread-Topic: AppsDir review of draft-ietf-dime-app-design-guide-19 Thread-Index: AQHOuuWFxr75d4dEQEC99uNndr3bi5nYtMbA Date: Fri, 27 Sep 2013 00:06:12 +0000 Message-ID: <14576_1380240373_5244CBF5_14576_166_1_6B7134B31289DC4FAF731D844122B36E27B041@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <52447BA0.1030204@ericsson.com> In-Reply-To: <52447BA0.1030204@ericsson.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.3] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.9.20.115714 X-Mailman-Approved-At: Mon, 30 Sep 2013 10:14:02 -0700 Subject: Re: [apps-discuss] AppsDir review of draft-ietf-dime-app-design-guide-19 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.12 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, 27 Sep 2013 00:06:41 -0000 SGkgU2FsdmF0b3JlLA0KDQpUaGFuayB5b3UgZm9yIHRoaXMgZmVlZGJhY2suDQoNClJlZ2FyZHMs DQoNCkxpb25lbA0KDQotLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCkRlwqA6IFNhbHZhdG9y ZSBMb3JldG8gW21haWx0bzpzYWx2YXRvcmUubG9yZXRvQGVyaWNzc29uLmNvbV0gDQpFbnZvecOp wqA6IGpldWRpIDI2IHNlcHRlbWJyZSAyMDEzIDIwOjIzDQrDgMKgOiBhcHBzLWRpc2N1c3NAaWV0 Zi5vcmc7IGRyYWZ0LWlldGYtZGltZS1hcHAtZGVzaWduLWd1aWRlQHRvb2xzLmlldGYub3JnDQpP YmpldMKgOiBBcHBzRGlyIHJldmlldyBvZiBkcmFmdC1pZXRmLWRpbWUtYXBwLWRlc2lnbi1ndWlk ZS0xOQ0KDQpJIGhhdmUgYmVlbiBzZWxlY3RlZCBhcyB0aGUgQXBwbGljYXRpb25zIEFyZWEgRGly ZWN0b3JhdGUgcmV2aWV3ZXIgZm9yDQp0aGlzIGRyYWZ0IChmb3IgYmFja2dyb3VuZCBvbiBhcHBz ZGlyLCBwbGVhc2Ugc2VlIOKAiw0KaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYXJlYS9hcHAv dHJhYy93aWtpL0FwcGxpY2F0aW9uc0FyZWFEaXJlY3RvcmF0ZSApLiANCg0KDQpQbGVhc2UgcmVz b2x2ZSB0aGVzZSBjb21tZW50cyBhbG9uZyB3aXRoIGFueSBvdGhlciBMYXN0IENhbGwgY29tbWVu dHMNCnlvdSBtYXkgcmVjZWl2ZS4gUGxlYXNlIHdhaXQgZm9yIGRpcmVjdGlvbiBmcm9tIHlvdXIg ZG9jdW1lbnQgc2hlcGhlcmQNCm9yIEFEIGJlZm9yZSBwb3N0aW5nIGEgbmV3IHZlcnNpb24gb2Yg dGhlIGRyYWZ0Lg0KDQpEb2N1bWVudDogZHJhZnQtaWV0Zi1kaW1lLWFwcC1kZXNpZ24tZ3VpZGUt MTkNClRpdGxlOiBEaWFtZXRlciBBcHBsaWNhdGlvbnMgRGVzaWduIEd1aWRlbGluZXMNClJldmll d2VyOiBTYWx2YXRvcmUgTG9yZXRvDQpSZXZpZXcgRGF0ZTogU2VwdC0yNi0yMDEzDQoNClN1bW1h cnk6IFRoaXMgZHJhZnQgaXMgcmVhZHkgZm9yIHB1YmxpY2F0aW9uIGFzIEluZm9ybWF0aW9uYWwu DQoNCk1ham9yIElzc3Vlczogbm9uZQ0KTWlub3IgSXNzdWVzOiBub25lDQpOaXRzOiBub25lDQoN CmJlc3QgcmVnYXJkcw0KU2FsdmF0b3JlDQotLSANClNhbHZhdG9yZSBMb3JldG8sIFBoRA0Kd3d3 LnNsb3JldG8uY29tDQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMg cGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2 aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMg b3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdl IHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRl dHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJv bmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRv dXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91 IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBj b250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJl IHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBv ciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlz IGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlz IG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBP cmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQs IGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo=