From presnick@qti.qualcomm.com Sun Dec 1 15:27:36 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62ACC1AE1A0; Sun, 1 Dec 2013 15:27:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LELzqgKF8ttl; Sun, 1 Dec 2013 15:27:35 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 2F26E1AE07E; Sun, 1 Dec 2013 15:27:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1385940453; x=1417476453; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=gMp/XvVzSR4vSyDOpgII6+XmrKfQXvwPRZNvjf+qNZg=; b=EfVIQLboF2hBMqhvHHbeo0TvLoRlSDt30bw2iTTLq2jeVaJwXCZTdYL+ REzzoafic6a5QuoKwzE38ZZKVZVRDnSiPaEXdUGibq36mP9rdpcq7Sbra LvI8rDNWi1gDgD0kYV4W0gaa0KD0Iz1W2z2WjKEHCplFpzL2wL4cLhKez U=; X-IronPort-AV: E=McAfee;i="5400,1158,7276"; a="89630016" Received: from ironmsg01-lv.qualcomm.com ([10.47.202.180]) by wolverine01.qualcomm.com with ESMTP; 01 Dec 2013 15:27:33 -0800 X-IronPort-AV: E=McAfee;i="5400,1158,7276"; a="23730247" Received: from nasanexhc03.na.qualcomm.com ([172.30.48.26]) by ironmsg01-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 01 Dec 2013 15:27:32 -0800 Received: from nasanexhc05.na.qualcomm.com (172.30.48.2) by NASANEXHC03.na.qualcomm.com (172.30.48.26) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 1 Dec 2013 15:27:32 -0800 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.158.1; Sun, 1 Dec 2013 15:27:31 -0800 Message-ID: <529BC5E2.7010003@qti.qualcomm.com> Date: Sun, 1 Dec 2013 17:27:30 -0600 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: "Murray S. Kucherawy" References: <20131120223533.8958.23858.idtracker@ietfa.amsl.com> <01P14CWFCE5A00004G@mauve.mrochek.com> <5294DDEE.4070000@qti.qualcomm.com> <529613CD.8060307@qti.qualcomm.com> <01P1CS3LR0X000004G@mauve.mrochek.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020406000700000502020701" X-Originating-IP: [172.30.48.1] Cc: "draft-ietf-appsawg-malformed-mail@tools.ietf.org" , Ned Freed , IETF Apps Discuss , SM , "appsawg-chairs@tools.ietf.org" , The IESG Subject: Re: [apps-discuss] Pete Resnick's Yes on draft-ietf-appsawg-malformed-mail-10: (with COMMENT) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Dec 2013 23:27:36 -0000 --------------020406000700000502020701 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit On 11/30/13 10:33 PM, Murray S. Kucherawy wrote: > http://www.blackops.org/~msk/draft-ietf-appsawg-malformed-mail-from--10.diff.html > > > I'll send it Monday unless I hear otherwise. Looks good to me. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 --------------020406000700000502020701 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit On 11/30/13 10:33 PM, Murray S. Kucherawy wrote:

Looks good to me.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478
--------------020406000700000502020701-- From mnot@mnot.net Sun Dec 1 16:39:42 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1CC91AE273 for ; Sun, 1 Dec 2013 16:39:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K6WJ-qVb3-eu for ; Sun, 1 Dec 2013 16:39:40 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id AAEE31AE233 for ; Sun, 1 Dec 2013 16:39:40 -0800 (PST) Received: from [192.168.1.52] (unknown [118.209.249.181]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 7C0FE509B5; Sun, 1 Dec 2013 19:39:32 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Mark Nottingham In-Reply-To: <5295F411.7040002@gmx.de> Date: Mon, 2 Dec 2013 11:39:27 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <4245CDAC-FAEF-45BC-B5E6-FC7F62A99269@mnot.net> References: <52934147.90304@michielbdejong.com> <52934626.8060503@gmx.de> <52935C62.1010301@michielbdejong.com> <5294E443.5050308@michielbdejong.com> <5294E795.2010806@gmx.de> <5295E0D6.6020505@michielbdejong.com> <5295E3FB.4050407@gmx.de> <5295F13B.4070504@michielbdejong.com> <5295F411.7040002@gmx.de> To: "Julian F. Reschke" X-Mailer: Apple Mail (2.1822) Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] remote storage: per-user cloud storage for the web X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 00:39:42 -0000 On 28 Nov 2013, at 12:30 am, Julian Reschke = wrote: > On 2013-11-27 14:18, Michiel B. de Jong wrote: >>=20 >> On 27-Nov-13 13:22, Julian Reschke wrote: >>> Quoting: >>>=20 >>>> * Whereas [HTTP, section 10] allows many different status = codes, >>>> remoteStorage servers SHOULD send the status codes = mentioned >>>> in section 5 of this Internet Draft, and clients MAY treat = any >>>> deviation from this as a server malfunction. >>>=20 >>> I still don't understand how that helps. What problem are you = solving >>> here? >>>=20 >>=20 >> if we allow servers a choice of all response codes then the client >> implement code to deal with each one of them. most of that code would >> never be used in practice, and thus be easily end up being buggy and >> lead to incompatibility. >=20 > The code to implement unknown codes is trivial. Just treat 2xx as 200, = 3xx as 300, 4xx as 400, and 5xx as 500. More to the point, many status codes are generated somewhere =93in = between=94, whether that be a proxy, a load balancer used by the = service, a CDN, a reverse proxy cache, a captive portal, etc. etc. A = client that isn=92t written to deal with a broad variety of status codes = is going to fail when exposed to the real Internet. Cheers, -- Mark Nottingham http://www.mnot.net/ From patrickdlogan@gmail.com Sun Dec 1 16:52:09 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82D781AE293 for ; Sun, 1 Dec 2013 16:52:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sryPFBIar6lH for ; Sun, 1 Dec 2013 16:52:07 -0800 (PST) Received: from mail-pb0-x233.google.com (mail-pb0-x233.google.com [IPv6:2607:f8b0:400e:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 83B261AE292 for ; Sun, 1 Dec 2013 16:52:07 -0800 (PST) Received: by mail-pb0-f51.google.com with SMTP id up15so17696381pbc.38 for ; Sun, 01 Dec 2013 16:52:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FcOZE2Tjf3Jy6EgokTwiE94iummFiYbb7ozm9U6k+QY=; b=Etwx5AL8eSJ45UdETLh9HDnhz42pt6LkeWcWwB1zUFYk8PQAefZcBkVt9gFWyPGqRK daoTFP7Mwns+BjFaT2fzaBHky+FwAKfQa+rEXF10/WOBys5yUf7rcHFRpwbPlRCblX4k 9vXN12Dpv+59aHYa1IjjXLZWdhdtw4XplQ5GfOtNsIIVw+3HszMGgYSZUO/psVzwOLQ/ pywnCtTFYMI8+8i0464OaXQFtuy4dpQfRHBEQliJ+5abScf3dD+wmi6mAIC8EwjIGjau GXjezGUAYIzKDchcjX8+AklY4i2eUB7VsNQZdXanHJx2j10IR+43Kw6SfQ+sZDXIN2Ox W3IA== MIME-Version: 1.0 X-Received: by 10.68.143.132 with SMTP id se4mr482723pbb.167.1385945525564; Sun, 01 Dec 2013 16:52:05 -0800 (PST) Received: by 10.70.75.70 with HTTP; Sun, 1 Dec 2013 16:52:05 -0800 (PST) Received: by 10.70.75.70 with HTTP; Sun, 1 Dec 2013 16:52:05 -0800 (PST) In-Reply-To: <5295F411.7040002@gmx.de> References: <52934147.90304@michielbdejong.com> <52934626.8060503@gmx.de> <52935C62.1010301@michielbdejong.com> <5294E443.5050308@michielbdejong.com> <5294E795.2010806@gmx.de> <5295E0D6.6020505@michielbdejong.com> <5295E3FB.4050407@gmx.de> <5295F13B.4070504@michielbdejong.com> <5295F411.7040002@gmx.de> Date: Sun, 1 Dec 2013 19:52:05 -0500 Message-ID: From: Patrick Logan To: Julian Reschke Content-Type: multipart/alternative; boundary=047d7b2e48eababa2104ec829654 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] remote storage: per-user cloud storage for the web X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 00:52:09 -0000 --047d7b2e48eababa2104ec829654 Content-Type: text/plain; charset=ISO-8859-1 Some redirects instruct the client to use the same method. Others, to use GET no matter the original method. On Nov 27, 2013 5:32 AM, "Julian Reschke" wrote: > On 2013-11-27 14:18, Michiel B. de Jong wrote: > >> >> On 27-Nov-13 13:22, Julian Reschke wrote: >> >>> Quoting: >>> >>> * Whereas [HTTP, section 10] allows many different status codes, >>>> remoteStorage servers SHOULD send the status codes mentioned >>>> in section 5 of this Internet Draft, and clients MAY treat any >>>> deviation from this as a server malfunction. >>>> >>> >>> I still don't understand how that helps. What problem are you solving >>> here? >>> >>> >> if we allow servers a choice of all response codes then the client >> implement code to deal with each one of them. most of that code would >> never be used in practice, and thus be easily end up being buggy and >> lead to incompatibility. >> > > The code to implement unknown codes is trivial. Just treat 2xx as 200, 3xx > as 300, 4xx as 400, and 5xx as 500. > > we are solving those three problems (unnecessary work for client >> implementers, risk of bugs, and risk of incompatibility) by saying >> exactly which 13 out of 41 (if i counted correctly) status codes we >> need, to get the job done. the other 28 status codes are useful to some >> part of the web, but they are useless to our specific problem space, so >> it's safer to disable them. >> > > I disagree. By unnecessarily creating a profile: > > a) you teach people to handle status codes incorrectly, > > b) make it impossible to introduce new codes, > > c) might make it impossible to use existing libraries, > > d) ignore that intermediaries might change messages, > > e) make it unnecessarily hard to have a server that supports "your" > protocol and somebody else's protocol on the same URI. > > Best regards, Julian > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --047d7b2e48eababa2104ec829654 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Some redirects instruct the client to use the same method. O= thers, to use GET no matter the original method.

On Nov 27, 2013 5:32 AM, "Julian Reschke&qu= ot; <julian.reschke@gmx.de&= gt; wrote:
On 2013-11-27 14:18, Michiel B. de Jong wrote:

On 27-Nov-13 13:22, Julian Reschke wrote:
Quoting:

=A0 =A0 =A0 =A0 * Whereas [HTTP, section 10] allows many different status c= odes,
=A0 =A0 =A0 =A0 =A0 remoteStorage servers SHOULD send the status codes ment= ioned
=A0 =A0 =A0 =A0 =A0 in section 5 of this Internet Draft, and clients MAY tr= eat any
=A0 =A0 =A0 =A0 =A0 deviation from this as a server malfunction.

I still don't understand how that helps. What problem are you solving here?


if we allow servers a choice of all response codes then the client
implement code to deal with each one of them. most of that code would
never be used in practice, and thus be easily end up being buggy and
lead to incompatibility.

The code to implement unknown codes is trivial. Just treat 2xx as 200, 3xx = as 300, 4xx as 400, and 5xx as 500.

we are solving those three problems (unnecessary work for client
implementers, risk of bugs, and risk of incompatibility) by saying
exactly which 13 out of 41 (if i counted correctly) status codes we
need, to get the job done. the other 28 status codes are useful to some
part of the web, but they are useless to our specific problem space, so
it's safer to disable them.

I disagree. By unnecessarily creating a profile:

a) you teach people to handle status codes incorrectly,

b) make it impossible to introduce new codes,

c) might make it impossible to use existing libraries,

d) ignore that intermediaries might change messages,

e) make it unnecessarily hard to have a server that supports "your&quo= t; protocol and somebody else's protocol on the same URI.

Best regards, Julian

_______________________________________________
apps-discuss mailing list
apps-discuss@iet= f.org
https://www.ietf.org/mailman/listinfo/apps-discuss
--047d7b2e48eababa2104ec829654-- From melvincarvalho@gmail.com Sun Dec 1 22:25:41 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FCE11AE305 for ; Sun, 1 Dec 2013 22:25:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6kYBnXqFubKL for ; Sun, 1 Dec 2013 22:25:39 -0800 (PST) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id D00E21AE192 for ; Sun, 1 Dec 2013 22:25:38 -0800 (PST) Received: by mail-ie0-f174.google.com with SMTP id at1so19792774iec.5 for ; Sun, 01 Dec 2013 22:25:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QcGs6q9DJO84g5AxUlruZjWA5jMK70MLNdUGTYRQcX8=; b=VVEIeoXTZ5mwOOzCPJmER0EuQGuoqZBcxj7ycfBbms5ZqWMcQQEWy/Fn55lu/P8hwr 57CcPbx780rOBa9pfLVDOQJaqQY8kC5beXdeSbKujnuIqn/HMefgiQ1NIx8d7Zp3GTlo tItuPiJLwnnChCN3m4s3AR6q230iFlrgJ9DxjVj77KehZdlixjz23Ft1P9YSao/k06Fb UYCwuVQ1QWhBpi9ZkaEdN7qTC1m20ZfkkcUAB+s+XlFpbWMiy59ttYT+9DUgLBPbE0Nj xiJH1U9H3MtqZvOMoWR1px9idiWuKG9Cyo6DkgCC0n1+8fqFGqCmorPWokdpjssRElbf 1EUg== MIME-Version: 1.0 X-Received: by 10.50.134.99 with SMTP id pj3mr16231364igb.14.1385965536498; Sun, 01 Dec 2013 22:25:36 -0800 (PST) Received: by 10.64.17.167 with HTTP; Sun, 1 Dec 2013 22:25:36 -0800 (PST) In-Reply-To: <52960930.8090506@michielbdejong.com> References: <52934147.90304@michielbdejong.com> <52934626.8060503@gmx.de> <52935C62.1010301@michielbdejong.com> <5294E443.5050308@michielbdejong.com> <5294E795.2010806@gmx.de> <5295E0D6.6020505@michielbdejong.com> <5295E3FB.4050407@gmx.de> <5295F13B.4070504@michielbdejong.com> <52960930.8090506@michielbdejong.com> Date: Mon, 2 Dec 2013 07:25:36 +0100 Message-ID: From: Melvin Carvalho To: "Michiel B. de Jong" Content-Type: multipart/alternative; boundary=047d7b41402e795a1704ec873fff Cc: Apps Discuss Subject: Re: [apps-discuss] remote storage: per-user cloud storage for the web X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 06:25:41 -0000 --047d7b41402e795a1704ec873fff Content-Type: text/plain; charset=ISO-8859-1 On 27 November 2013 16:01, Michiel B. de Jong wrote: > OK, i changed it so that the checklist of status codes to take into > account is only a summary of what follows from section 10 of rfc2616 and > section 3.1 of rfc6750: > > https://github.com/remotestorage/spec/blob/30f8b53430fa5fce765e94bb8ff991 > 468875356e/draft-dejong-remotestorage-02.txt#L284-L286 > > so we are no longer sub-setting http. :) thanks a lot for this improvement! > > what do people think in general of the endeavor? is anybody interested in > starting a broader discussion about per-user storage? > > in particular, i think: > > * the current big industry stakeholders in this space are probably: > Dropbox, GoogleDrive, iCloud, and SkyDrive. > * apart from these four, many parties probably have an interest in > disrupting the per-user storage market, either to neutralize it as a > business risk, or to create a level basis for entering. > * remoteStorage is a grassroots project, we are about 1 1/2 people. :) it > is obvious that we cannot do this without the help from you who are reading > this. > > we hope some of the following parties may be interested in joining this > effort: > * ISPs and mobile operators who want to offer more than just bandwidth to > their users > * handset manufacturers who want to disrupt the iOS+iCloud / > Android+GoogleDrive / WindowsPhone+SkyDrive power blocks > * people who care about open and free technology, also on this new layer. > > again, comments very welcome! Things I'd like to see: 1. Compatibility with other systems doing similar things such as Linked Data Platform https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html 2. A modular approach to discovery, such that webfinger is not the *only* supported discovery mechanism. It should be perfectly fine to use well established standards based discovery such as Linked Data. Forcing a split eco systems divides efforts imho. 3. A similar modular approach to authentication. Supporting OAuth is good, but it would be nice to be able to slot in other standards for verifying identity. 4. A standardization of the rel and property links used in discovery of going from a user to storage. The elements in the spec I could not easily understand as they were not self documenting. Consider the work being done by Tim Berners-Lee's lab at MIT, that I recently posted to your mailing list http://www.w3.org/ns/pim/space The principle here is that from a user you can discover preferences. And from preferences you can discover what Tim calls "Workspaces". A works space is storage endpoint where you can save data, per user, or per app, or shared. 5. Consider supporting data mashups, so that data can be pulled from more than one location, and so that apps are able to share data. As remotestorage is a relatively small community and there are other groups working on achieving similar goals, I think it would be advantageous to benefit from each other's work in a modular way. > > > > cheers, > Michiel > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --047d7b41402e795a1704ec873fff Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On 27 November 2013 16:01, Michiel B. de Jong <= ;anything@= michielbdejong.com> wrote:
OK, i changed it so that = the checklist of status codes to take into account is only a summary of wha= t follows from section 10 of rfc2616 and section 3.1 of rfc6750:

https://github.com/remotestorage/spec/blob/30f8b53430= fa5fce765e94bb8ff991468875356e/draft-dejong-remotestorage-02.= txt#L284-L286

so we are no longer sub-setting http. :) thanks a lot for this improvement!=

what do people think in general of the endeavor? is anybody interested in s= tarting a broader discussion about per-user storage?

in particular, i think:

* the current big industry stakeholders in this space are probably: Dropbox= , GoogleDrive, iCloud, and SkyDrive.
* apart from these four, many parties probably have an interest in disrupti= ng the per-user storage market, either to neutralize it as a business risk,= or to create a level basis for entering.
* remoteStorage is a grassroots project, we are about 1 1/2 people. :) it i= s obvious that we cannot do this without the help from you who are reading = this.

we hope some of the following parties may be interested in joining this eff= ort:
* ISPs and mobile operators who want to offer more than just bandwidth to t= heir users
* handset manufacturers who want to disrupt the iOS+iCloud / Android+Google= Drive / WindowsPhone+SkyDrive power blocks
* people who care about open and free technology, also on this new layer.
again, comments very welcome!

Things I'= d like to see:

1. Compatibility with other systems doing = similar things such as Linked Data Platform

https://dvcs.w3.org/hg/ldpwg/raw= -file/default/ldp.html

2. A modular approach to discovery, such that webfinger is n= ot the *only* supported discovery mechanism.=A0 It should be perfectly fine= to use well established standards based discovery such as Linked Data.=A0 = Forcing a split eco systems divides efforts imho.

3. A similar modular approach to authentication.=A0 Supporti= ng OAuth is good, but it would be nice to be able to slot in other standard= s for verifying identity.

4. A standardization of the rel= and property links used in discovery of going from a user to storage.=A0 T= he elements in the spec I could not easily understand as they were not self= documenting.

Consider the work being done by Tim Berners-Lee's lab at= MIT, that I recently posted to your mailing list

http://www.w3.org/ns/pim/space

The principle here is that from a user you can discover pref= erences.=A0 And from preferences you can discover what Tim calls "Work= spaces".=A0 A works space is storage endpoint where you can save data,= per user, or per app, or shared.

5. Consider supporting data mashups, so that data can be pul= led from more than one location, and so that apps are able to share data.

As remotestorage is a relatively small communit= y and there are other groups working on achieving similar goals, I think it= would be advantageous to benefit from each other's work in a modular w= ay.
=A0



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

--047d7b41402e795a1704ec873fff-- From melvincarvalho@gmail.com Mon Dec 2 03:15:15 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AA531AE35B for ; Mon, 2 Dec 2013 03:15:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78IrvWBlHFot for ; Mon, 2 Dec 2013 03:15:13 -0800 (PST) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id C26481AE27F for ; Mon, 2 Dec 2013 03:15:13 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id qd12so20952759ieb.3 for ; Mon, 02 Dec 2013 03:15:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=JpuANPALnpMJPzGQ2wBFzX8H5/AqKpAMdai8b1Y3mcc=; b=TpyYYNlvVem5XbWbXe53rLgTgESNjEVWJBJDJ1+jb3Xr82j0bZteiiFG+w8D10JntL 1xGYc0lL4DajNEek7dHceg9LncMteMd6RGL8OOsnFc84JM/IW4XrPYVYNDgRbxSkvHWz PbyKyqk1UNC2JYbPpjS74N1vaOA5zpQCBsSQkE1rQ+qeNNH1RNC6qM1gA3vugslzPtqJ tY/EOwUepGOk4hnJ/lKLL3AsuwPFEhr9uO3ihz/HuXRuYIfeT6jxMeFEaErTHRyv3qkI pqq/dlkVpZf2f+fVxQ1NN07cxMIrHiY+3ggaxUonKJMhiM+3VRuEeT2086fXHmjBAG3P zUeg== MIME-Version: 1.0 X-Received: by 10.43.170.130 with SMTP id nq2mr404838icc.69.1385982911463; Mon, 02 Dec 2013 03:15:11 -0800 (PST) Received: by 10.64.17.167 with HTTP; Mon, 2 Dec 2013 03:15:11 -0800 (PST) Date: Mon, 2 Dec 2013 12:15:11 +0100 Message-ID: From: Melvin Carvalho To: Apps Discuss Content-Type: multipart/alternative; boundary=001a11c2f7301a470104ec8b4bfc Subject: [apps-discuss] well-known location for uuids X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 11:15:15 -0000 --001a11c2f7301a470104ec8b4bfc Content-Type: text/plain; charset=ISO-8859-1 Looking at http://www.iana.org/assignments/well-known-uris/well-known-uris.xml There seems to be a well known location for named instances (hashes) ni And also skolemized bnodes : genid Would it be a good idea to have one for uuids, do you think? Currently there is urn:uuid: as a URN but not simple way to translate this to a URL Could we maybe just add /.well-known/uuid/ ? Thoughts? --001a11c2f7301a470104ec8b4bfc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
= There seems to be a well known location for named instances (hashes) ni

And also skolemized bnodes : genid

Would it be a goo= d idea to have one for uuids, do you think?

Currently there is= urn:uuid: as a URN but not simple way to translate this to a URL

Could we maybe just add /.well-known/uuid/=A0 ?

Thoughts?
<= /div> --001a11c2f7301a470104ec8b4bfc-- From julian.reschke@gmx.de Mon Dec 2 03:23:34 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89E3C1AE3C3 for ; Mon, 2 Dec 2013 03:23:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZJaKclEzi3f for ; Mon, 2 Dec 2013 03:23:33 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 0B6AA1AE3C1 for ; Mon, 2 Dec 2013 03:23:33 -0800 (PST) Received: from [192.168.1.38] ([217.91.35.233]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0ML6XF-1Vnia03s5B-000KPW for ; Mon, 02 Dec 2013 12:23:30 +0100 Message-ID: <529C6DA2.8010000@gmx.de> Date: Mon, 02 Dec 2013 12:23:14 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Melvin Carvalho , Apps Discuss References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:hgwlGvFjKLqSIpEPWOj/9yhUvEDPJfsms+ZBR+thVLHl0vxcblx q8ggIxIEZeHSSi7AgBxXzNN6aPhVfh/uFJrHcsIeFxqovxH14KP2xMSMwyk5L11LSSNnbq+ eXnBa3I0M74Ax4mwu75XoO8bakQ7YmD3PSk/GTv4rblAB9c2qofdgA6SMDiKbT+JHoY+kWj fKbA1QxRQX5aoL/lSSiZA== Subject: Re: [apps-discuss] well-known location for uuids X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Dec 2013 11:23:34 -0000 On 2013-12-02 12:15, Melvin Carvalho wrote: > Looking at > > http://www.iana.org/assignments/well-known-uris/well-known-uris.xml > > There seems to be a well known location for named instances (hashes) ni > > And also skolemized bnodes : genid > > Would it be a good idea to have one for uuids, do you think? > > Currently there is urn:uuid: as a URN but not simple way to translate > this to a URL > > Could we maybe just add /.well-known/uuid/ ? > > Thoughts? What's the advantage of the urn:uuid notation? Do you plan to resolve it to a resource? Best regards, Julian From superuser@gmail.com Mon Dec 2 19:41:20 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D8491ADBD0 for ; Mon, 2 Dec 2013 19:41:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LyvuGs9qARFK for ; Mon, 2 Dec 2013 19:41:18 -0800 (PST) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id E30691AD698 for ; Mon, 2 Dec 2013 19:41:17 -0800 (PST) Received: by mail-wi0-f173.google.com with SMTP id hn9so1519019wib.0 for ; Mon, 02 Dec 2013 19:41:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=nYf0e2tuqtD5VBcK8NpE57dbqdnKjY1MvsCYK5KMXUc=; b=OMVTV/ZOruoxWCbTtvc+JTX1LobXR0bzNYQ5FqAAN1QGOEScbvDJekchtnyklN0LHJ YYcmvNUhmcR9qkgjsvgMSs+oh3V4uXbQDX5RjkIxAYjiJzI2xrxRU7KRgRNEHi/4B/IG wDhAFe4SdP6arDiEHA5K8/IQ9tZ/AKab2CQJxVuD6gP8ZQFx2F1CR/rSDK7wV6cj1RHu gWRMFsZF8MzlVwSJ8bVRjZXu17hJqeNUBhq71QM8FkYdTXpkbRDcD8EHG75+z7g1pGsY 0hS1UIMsWL5NTBgKuOXdw4znV4By8jACpaqP0e8wGJ49HuwmAoU70cQ82ld8y3EvkQN6 A3yw== MIME-Version: 1.0 X-Received: by 10.194.104.66 with SMTP id gc2mr188499wjb.75.1386042074976; Mon, 02 Dec 2013 19:41:14 -0800 (PST) Received: by 10.181.13.230 with HTTP; Mon, 2 Dec 2013 19:41:14 -0800 (PST) Date: Mon, 2 Dec 2013 19:41:14 -0800 Message-ID: From: "Murray S. Kucherawy" To: Stephan Bosch Content-Type: multipart/alternative; boundary=089e0102ef8485d72a04ec9911c0 Cc: IETF Apps Discuss Subject: [apps-discuss] Reviewers, please (was Re: I-D Action: draft-ietf-appsawg-sieve-duplicate-01.txt) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 03:41:20 -0000 --089e0102ef8485d72a04ec9911c0 Content-Type: text/plain; charset=ISO-8859-1 Can we get some reviewers for this draft, please? -MSK On Mon, Nov 4, 2013 at 9:10 AM, Stephan Bosch wrote: > On 11/4/2013 4:12 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Applications Area Working Group > Working Group of the IETF. > > > > Title : Sieve Email Filtering: Detecting Duplicate > Deliveries > > Author(s) : Stephan Bosch > > Filename : draft-ietf-appsawg-sieve-duplicate-01.txt > > Pages : 11 > > Date : 2013-11-04 > > > > Abstract: > > This document defines a new test command "duplicate" for the "Sieve" > > email filtering language. This test adds the ability to detect > > duplicate message deliveries. The main application for this new test > > is handling duplicate deliveries commonly caused by mailing list > > subscriptions or redirected mail addresses. The detection is > > normally performed by matching the message ID to an internal list of > > message IDs from previously delivered messages. For more complex > > applications, the "duplicate" test can also use the content of a > > specific header or other parts of the message. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-appsawg-sieve-duplicate > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-appsawg-sieve-duplicate-01 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-sieve-duplicate-01 > > The following changes were made in the draft: > > - Documented that the expiry time of entries in the duplicate tracking > list is measured relative to the initial message. When needed, this can > also be performed relative to the last received duplicate by specifying > the new `:last' argument. > - Mentioned interaction with "imapsieve" extension and marked providing > the "duplicate" test in the context of "imapsieve" as NOT RECOMMENDED. > I've made a separate section for interaction with other Sieve extensions > in the process. > - The draft now explicitly states that the message ID value is tracked > independent from its source, meaning that it doesn't matter whether it > is the value of the Message-ID header, the value of some other arbitrary > header specified using `:header', or a explicit string value provided > using the `:uniqueid' argument. > - Addressed a few editorial comments by Ned Freed. > > Any comments are welcome! > > Regards, > > Stephan. > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --089e0102ef8485d72a04ec9911c0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Can we get some reviewers for this draft, please?
=
-MSK


On Mon, Nov 4, 2013 at 9:10 AM, Stephan Bosch <stephan@rename-it.n= l> wrote:
On 11/4/2013 4:12 PM, internet-drafts@ietf.org wrote:=
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> =A0This draft is a work item of the Applications Area Working Group Wo= rking Group of the IETF.
>
> =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Sieve Email Filtering: Detecti= ng Duplicate Deliveries
> =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Stephan Bosch
> =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-appsawg-sieve-duplica= te-01.txt
> =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 11
> =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-11-04
>
> Abstract:
> =A0 =A0This document defines a new test command "duplicate" = for the "Sieve"
> =A0 =A0email filtering language. =A0This test adds the ability to dete= ct
> =A0 =A0duplicate message deliveries. =A0The main application for this = new test
> =A0 =A0is handling duplicate deliveries commonly caused by mailing lis= t
> =A0 =A0subscriptions or redirected mail addresses. =A0The detection is=
> =A0 =A0normally performed by matching the message ID to an internal li= st of
> =A0 =A0message IDs from previously delivered messages. =A0For more com= plex
> =A0 =A0applications, the "duplicate" test can also use the c= ontent of a
> =A0 =A0specific header or other parts of the message.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-app= sawg-sieve-duplicate
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-appsawg-siev= e-duplicate-01
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-i= etf-appsawg-sieve-duplicate-01

The following changes were made in the draft:

- Documented that the expiry time of entries in the duplicate tracking
list is measured relative to the initial message. =A0When needed, this can<= br> also be performed relative to the last received duplicate by specifying
the new `:last' argument.
- Mentioned interaction with "imapsieve" extension and marked pro= viding
the "duplicate" test in the context of "imapsieve" as N= OT RECOMMENDED.
I've made a separate section for interaction with other Sieve extension= s
in the process.
- The draft now explicitly states that the message ID value is tracked
independent from its source, meaning that it doesn't matter whether it<= br> is the value of the Message-ID header, the value of some other arbitrary header specified using `:header', or a explicit string value provided using the `:uniqueid' argument.
- Addressed a few editorial comments by Ned Freed.

Any comments are welcome!

Regards,

Stephan.

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

--089e0102ef8485d72a04ec9911c0-- From superuser@gmail.com Mon Dec 2 19:42:04 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE261ADEA7 for ; Mon, 2 Dec 2013 19:42:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jW1pEUy_nuEf for ; Mon, 2 Dec 2013 19:42:02 -0800 (PST) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 078201AD698 for ; Mon, 2 Dec 2013 19:42:01 -0800 (PST) Received: by mail-we0-f170.google.com with SMTP id w61so13119446wes.1 for ; Mon, 02 Dec 2013 19:41:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/X6COkX9qm+1sKmJnoVw465VN/PyRWmpVSUJCkW7n64=; b=a5IXrYl4HJvH4PpfhWZIKCc95gdOWozPy3hANsrt/XiI5o6ZH7pg8owIapLoCXZ/jC VyD3l5PId48wLbqDQAP91ljM2IXDMMwU8dcRRpWv9DmdtQjlWZTEM0gjCi5Ae05jW8ui t4xAgXV+YncJQVDtZTF9oKW4iqcitwiT0RkQfKSAXQkloPscR3+K4NmzFZ9iz+DGm2EP iUXmQbv4Ynd3MwUjeXQ+9a6yCxTlvIr7JfWZb/TNXNGzKhO6ZjKtKsj0fpj1uHYEPhaa EobV0KEYEoYjqJ0ZyJwNi9WDqq4Zy9TOzpTI8khghMSiOekAfIefrMhl2/7TDWpJsUSx eEzQ== MIME-Version: 1.0 X-Received: by 10.180.211.71 with SMTP id na7mr449251wic.5.1386042119146; Mon, 02 Dec 2013 19:41:59 -0800 (PST) Received: by 10.181.13.230 with HTTP; Mon, 2 Dec 2013 19:41:59 -0800 (PST) In-Reply-To: <52975509.4070401@isode.com> References: <20131120080026.25156.23231.idtracker@ietfa.amsl.com> <52975509.4070401@isode.com> Date: Mon, 2 Dec 2013 19:41:59 -0800 Message-ID: From: "Murray S. Kucherawy" To: Alexey Melnikov Content-Type: multipart/alternative; boundary=001a11c347e027d46704ec991458 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rrvs-header-field-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 03:42:04 -0000 --001a11c347e027d46704ec991458 Content-Type: text/plain; charset=ISO-8859-1 Thanks, Alexey. Any other feedback in support of or requesting changes to this version? Is it ready for WGLC? On Thu, Nov 28, 2013 at 6:36 AM, Alexey Melnikov wrote: > On 20/11/2013 08:02, Murray S. Kucherawy wrote: > > On Wed, Nov 20, 2013 at 12:00 AM, 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 Require-Recipient-Valid-Since Header Field >> and SMTP Service Extension >> Author(s) : William J. Mills >> Murray S. Kucherawy >> Filename : draft-ietf-appsawg-rrvs-header-field-04.txt >> Pages : 20 >> Date : 2013-11-19 >> >> Abstract: >> This document defines an extension for the Simple Mail Transfer >> Protocol called RRVS, and a header field called Require-Recipient- >> Valid-Since, to provide a method for senders to indicate to receivers >> the time when the sender last confirmed the ownership of the target >> mailbox. This can be used to detect changes of mailbox ownership, >> and thus prevent mail from being delivered to the wrong party. >> >> The intended use of these facilities is on automatically generated >> messages that might contain sensitive information, though it may also >> be useful in other applications. >> >> > Incorporates a lot of suggestions from Ned, Alexey, and John. Diff > available from the datatracker. Have at it! > > This version is much better and it addresses various issues related to > mailing list and redirection. I am happy with it. > > --001a11c347e027d46704ec991458 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks, Alexey.

Any other feedback in support of or= requesting changes to this version?=A0 Is it ready for WGLC?


On Thu, Nov 28, 2= 013 at 6:36 AM, Alexey Melnikov <alexey.melnikov@isode.com>= wrote:
=20 =20 =20
On 20/11/2013 08:02, Murray S. Kucherawy wrote:
On Wed, Nov 20, 2013 at 12:00 AM, = <internet-= drafts@ietf.org> wrote:

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

=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : The Require-Recipient-Valid-Since Header Field and SMTP Service Extension
=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : William J. Mills
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Murray S.= Kucherawy
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-appsawg-rrvs-header-field-04.txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 20
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-11-19

Abstract:
=A0 =A0This document defines an extension for the Simple Mail Transfer
=A0 =A0Protocol called RRVS, and a header field called Require-Recipient-
=A0 =A0Valid-Since, to provide a method for senders to indicate to receivers
=A0 =A0the time when the sender last confirmed the ownership of the target
=A0 =A0mailbox. =A0This can be used to detect changes of mail= box ownership,
=A0 =A0and thus prevent mail from being delivered to the wron= g party.

=A0 =A0The intended use of these facilities is on automatically generated
=A0 =A0messages that might contain sensitive information, though it may also
=A0 =A0be useful in other applications.


Incorporates a lot of suggestions from Ned, Alexey, and John.=A0 Diff available from the datatracker.=A0 Have at it!
This version is much better and it addresses various issues related to mailing list and redirection. I am happy with it.


--001a11c347e027d46704ec991458-- From superuser@gmail.com Mon Dec 2 20:14:44 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E16E1ADEA0 for ; Mon, 2 Dec 2013 20:14:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xt1VPmB8-sc9 for ; Mon, 2 Dec 2013 20:14:42 -0800 (PST) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id 05C921ADE84 for ; Mon, 2 Dec 2013 20:14:41 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id ca18so5895819wib.11 for ; Mon, 02 Dec 2013 20:14:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=FQCQ5B6o9o41CEnjLkfrOGZh67zgmbk1VPlqbtEUniw=; b=nH2He12ubcEMm+Jqq/Vd9rfoolgL2yHVgydQ7DCBo85DkhqD5IYdRmwHbJPRtQgUUQ UK8XmW1egWM+aXU0h2hS0HhlGXEL/RVRAnvshKEU569LfrA96fQERp116kxOl44VINc6 riPEhbkLTIsicSUIa4xbBpkNeJmmzZvTR+Lirjlx5USAULB7UfGMCcayX20dgnDW+HYS CnXgNJmKG15nuCT7EZDfHuY2HrUqu+/NDY/kfGHmgtKtMx77PzUooy5XPpNtVcM0K827 F8GWKsAn4zcOvbaBWv11/DVquqm2McBlAJiZyvJoVZtsHR0iZydaZMoUNs5qb4dodXXc IWqw== MIME-Version: 1.0 X-Received: by 10.180.211.71 with SMTP id na7mr529315wic.5.1386044079075; Mon, 02 Dec 2013 20:14:39 -0800 (PST) Received: by 10.181.13.230 with HTTP; Mon, 2 Dec 2013 20:14:39 -0800 (PST) Date: Mon, 2 Dec 2013 20:14:39 -0800 Message-ID: From: "Murray S. Kucherawy" To: "Manger, James H" Content-Type: multipart/alternative; boundary=001a11c347e0f9f8a604ec998876 Cc: IETF Apps Discuss Subject: [apps-discuss] Reviews, please (was Re: Fwd: New Version Notification for draft-ietf-appsawg-json-merge-patch-02.txt) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 04:14:44 -0000 --001a11c347e0f9f8a604ec998876 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Nov 18, 2013 at 6:14 PM, Manger, James H < James.H.Manger@team.telstra.com> wrote: > >> Title: JSON Merge Patch > >> Htmlized: > >> http://tools.ietf.org/html/draft-ietf-appsawg-json-merge-patch-02 > >> Abstract: > >> This specification defines the JSON merge patch format and > >> processing > >> rules. > > > Based on feedback. Fairly significant editorial update and one key > > technical change. This updates the media type registration to follow > > the +json naming policy on the media type (that is, > > application/json-merge-patch becomes application/merge-patch+json). > > Most of these changes are great: title, media type, organization. > > I feel there are still issues (in addition to the outstanding issuing in > my last call comments): [...] > Could we get a few more reviews or comments in support of advancing this document? We'd really like to get this one moving, but we can't without some indication that there's consensus support for doing so. -MSK --001a11c347e0f9f8a604ec998876 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Nov 18, 2013 at 6:14 PM, Manger, James H <James.H.Manger@team.telstra.com> wrote:
>> Title: = =A0 =A0 =A0 =A0 =A0 JSON Merge Patch
>> Htmlized:
>> http://tools.ietf.org/html/draft-ietf-appsawg= -json-merge-patch-02
>> Abstract:
>> =A0 =A0This specification defines the JSON merge patch format and<= br> >> processing
>> =A0 =A0rules.

> Based on feedback. Fairly significant editoria= l update and one key
> technical change. This updates the media type registration to follow > the +json naming policy on the media type (that is,
> application/json-merge-patch becomes application/merge-patch+json).
Most of these changes are great: title, media type, organization.

I feel there are still issues (in addition to the outstanding issuing in my= last call comments):=A0=A0
[...]

Could we get a few more reviews o= r comments in support of advancing this document?=A0 We'd really like t= o get this one moving, but we can't without some indication that there&= #39;s consensus support for doing so.

-MSK
--001a11c347e0f9f8a604ec998876-- From ned.freed@mrochek.com Tue Dec 3 07:18:19 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A85E1AE006 for ; Tue, 3 Dec 2013 07:18:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EtKrUE6nOSCu for ; Tue, 3 Dec 2013 07:18:17 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 049111AD9AB for ; Tue, 3 Dec 2013 07:18:17 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P1I7VBCHB400218D@mauve.mrochek.com> for apps-discuss@ietf.org; Tue, 3 Dec 2013 07:13:10 -0800 (PST) MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=iso-8859-1 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P1EYY8EQQO00004G@mauve.mrochek.com>; Tue, 3 Dec 2013 07:13:04 -0800 (PST) Message-id: <01P1I7V8Q0BQ00004G@mauve.mrochek.com> Date: Tue, 03 Dec 2013 07:12:01 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Mon, 02 Dec 2013 19:41:14 -0800" References: To: "Murray S. Kucherawy" Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Reviewers, please (was Re: I-D Action: draft-ietf-appsawg-sieve-duplicate-01.txt) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 15:18:19 -0000 > Can we get some reviewers for this draft, please? I meant to follow up on this; sorry. Anyway, Stephan and I have been working on this offline and I've reviewed it pretty carefully. I'm happy with the current version. Ned > -MSK > On Mon, Nov 4, 2013 at 9:10 AM, Stephan Bosch wrote: > > On 11/4/2013 4:12 PM, internet-drafts@ietf.org wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > This draft is a work item of the Applications Area Working Group > > Working Group of the IETF. > > > > > > Title : Sieve Email Filtering: Detecting Duplicate > > Deliveries > > > Author(s) : Stephan Bosch > > > Filename : draft-ietf-appsawg-sieve-duplicate-01.txt > > > Pages : 11 > > > Date : 2013-11-04 > > > > > > Abstract: > > > This document defines a new test command "duplicate" for the "Sieve" > > > email filtering language. This test adds the ability to detect > > > duplicate message deliveries. The main application for this new test > > > is handling duplicate deliveries commonly caused by mailing list > > > subscriptions or redirected mail addresses. The detection is > > > normally performed by matching the message ID to an internal list of > > > message IDs from previously delivered messages. For more complex > > > applications, the "duplicate" test can also use the content of a > > > specific header or other parts of the message. > > > > > > > > > The IETF datatracker status page for this draft is: > > > https://datatracker.ietf.org/doc/draft-ietf-appsawg-sieve-duplicate > > > > > > There's also a htmlized version available at: > > > http://tools.ietf.org/html/draft-ietf-appsawg-sieve-duplicate-01 > > > > > > A diff from the previous version is available at: > > > http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-sieve-duplicate-01 > > > > The following changes were made in the draft: > > > > - Documented that the expiry time of entries in the duplicate tracking > > list is measured relative to the initial message. When needed, this can > > also be performed relative to the last received duplicate by specifying > > the new `:last' argument. > > - Mentioned interaction with "imapsieve" extension and marked providing > > the "duplicate" test in the context of "imapsieve" as NOT RECOMMENDED. > > I've made a separate section for interaction with other Sieve extensions > > in the process. > > - The draft now explicitly states that the message ID value is tracked > > independent from its source, meaning that it doesn't matter whether it > > is the value of the Message-ID header, the value of some other arbitrary > > header specified using `:header', or a explicit string value provided > > using the `:uniqueid' argument. > > - Addressed a few editorial comments by Ned Freed. > > > > Any comments are welcome! > > > > Regards, > > > > Stephan. > > > > _______________________________________________ > > apps-discuss mailing list > > apps-discuss@ietf.org > > https://www.ietf.org/mailman/listinfo/apps-discuss > > From touch@isi.edu Tue Dec 3 07:35:41 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E4911AE194 for ; Tue, 3 Dec 2013 07:35:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 079cFUHb6lqx for ; Tue, 3 Dec 2013 07:35:39 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD531AE157 for ; Tue, 3 Dec 2013 07:35:39 -0800 (PST) Received: from [192.168.1.93] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id rB3FZCG1028886 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 3 Dec 2013 07:35:22 -0800 (PST) Message-ID: <529DFA37.3030608@isi.edu> Date: Tue, 03 Dec 2013 07:35:19 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Stephen Farrell , "apps-discuss@ietf.org" References: <20131122173554.16611.88076.idtracker@ietfa.amsl.com> <52935E39.7040802@cs.tcd.ie> In-Reply-To: <52935E39.7040802@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Subject: Re: [apps-discuss] [saag] Fwd: WG Review: Using TLS in Applications (uta) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 15:35:41 -0000 Comments below: On 11/25/2013 6:27 AM, Stephen Farrell wrote: > > FYI, please note this proposed new APPS area WG. We'll need > to try get a bunch of security folks involved in that so > please consider spending a few cycles to help out with the > work. > > I'd say discussion of that charter would be best done on > apps-discuss@ietf.org since its proposed as an APPS area > WG and the apps-discuss list is probably where there's > the best concentration of relevant expertise, so please > direct any substantive discussion there. > > Thanks, > S. > > > -------- Original Message -------- > Subject: WG Review: Using TLS in Applications (uta) > Date: Fri, 22 Nov 2013 09:35:54 -0800 > From: The IESG > Reply-To: ietf@ietf.org > To: IETF-Announce > > A new IETF working group has been proposed in the Applications Area. The > IESG has not made any determination yet. The following draft charter was > submitted, and is provided for informational purposes only. Please send > your comments to the IESG mailing list (iesg at ietf.org) by 2013-12-02. > > Using TLS in Applications (uta) > ------------------------------------------------ > Current Status: Proposed WG > > Assigned Area Director: > Barry Leiba > > > Charter: > > There is a renewed and urgent interest in the IETF to increase the > security of transmissions over the Internet. Many application protocols > have defined methods for using TLS to authenticate the server (and > sometimes the client), and to encrypt the connection between the client > and server. However, there is a diversity of definitions and > requirements, and that diversity has caused confusion for application > developers and also has led to lack of interoperability or lack of > deployment. Implementers and deployers are faced with multiple security > issues in real-world usage of TLS, which currently does not preclude > insecure ciphers and modes of operation. > > This WG has the following tasks: > > - Update the definitions for using TLS over a set of representative > application protocols. This includes communication with proxies, between > servers, and between peers, where appropriate, in addition to > client/server communication. > > - Specify a set of best practices for TLS clients and servers, including > but not limited to recommended versions of TLS, using forward secrecy, > and one or more ciphersuites and extensions that are mandatory to > implement. > > - Consider, and possibly define, a standard way for an application client > and server to use unauthenticated encryption through TLS when server > and/or client authentication cannot be achieved. See BTNS, RFC 5387. This ought to be very easy, but it's not clear whether associated connection latching (RFC 5660) is useful here, because there might not be a useful upper-layer security standard to latch to. It would also be very important to discuss the limitations of TLS, notably in protecting the transport connection from interference (RFC 4953). > - Create a document that helps application protocol developers use TLS in > future application definitions. > > The initial set of representative application protocols is SMTP, POP, > IMAP, XMPP, and HTTP 1.1. It is expected that other protocols that use > TLS might later be updated using the guidelines from this WG, and that > those updates will happen through other WGs or through individual > submissions. > > The WG will make the fewest changes needed to achieve good interoperable > security for the applications using TLS. No changes to TLS itself will > be made in this WG, and the WG will ensure that changes to current > versions of popular TLS libaries will not be required to conform to the > WG's specifications. > > This WG will collaborate with other IETF WGs, in particular with the TLS > and DANE WGs. > > Milestones: > > > > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > From mamille2@cisco.com Tue Dec 3 10:31:58 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46C4B1AD6D1 for ; Tue, 3 Dec 2013 10:31:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MPhmQjPa7ihz for ; Tue, 3 Dec 2013 10:31:56 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD4C1A8032 for ; Tue, 3 Dec 2013 10:31:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4408; q=dns/txt; s=iport; t=1386095514; x=1387305114; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=YG6myLwJWQSGivD7s7hKcWdRBNxjRg89cMkhGp7bEkM=; b=gHUVYrsCqoNR9qNMG8YBMRxOob21Gf7eCpDRLQyP3b3v9Tm5Dd9pN/vl pQZ6bH1ORFL+6APFQgLBmqaZ3tWoU8xDOMN6US9xrJwwcql0Cf1SeoVBF aHk7qWcy2tAxypUj8mFmwACSzqRuMxpCmUZXBSWQ2RD9rYp8EMt1aWFih k=; X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMFAGEinlKtJV2Y/2dsb2JhbABagwc4U7hngRsWdIIlAQEBAwF3AgULAgEIGCMLIRElAgQOBQ6HYQMJBg25dQ0QhxcXjG2CEQeDIIETA5AxgTGCT4F4gWuBMIsqhTmBa4E+gio X-IronPort-AV: E=Sophos;i="4.93,819,1378857600"; d="asc'?scan'208";a="4027899" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-3.cisco.com with ESMTP; 03 Dec 2013 18:31:53 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rB3IVr8O024264 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Dec 2013 18:31:53 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.57]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Tue, 3 Dec 2013 12:31:53 -0600 From: "Matt Miller (mamille2)" To: "Murray S. Kucherawy" Thread-Topic: [apps-discuss] Reviews, please (was Re: Fwd: New Version Notification for draft-ietf-appsawg-json-merge-patch-02.txt) Thread-Index: AQHO7940nSBUfN8YyUq8jehEmAZjkJpDMLcA Date: Tue, 3 Dec 2013 18:31:52 +0000 Message-ID: <50C6A070-CED3-45F0-A39F-263CBCAC46DD@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [64.101.72.35] Content-Type: multipart/signed; boundary="Apple-Mail=_939AFDCB-71B3-4DA4-972A-CACA3B10CF5F"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Reviews, please (was Re: Fwd: New Version Notification for draft-ietf-appsawg-json-merge-patch-02.txt) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 18:31:58 -0000 --Apple-Mail=_939AFDCB-71B3-4DA4-972A-CACA3B10CF5F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Dec 2, 2013, at 9:14 PM, Murray S. Kucherawy = wrote: > On Mon, Nov 18, 2013 at 6:14 PM, Manger, James H = wrote: > >> Title: JSON Merge Patch > >> Htmlized: > >> http://tools.ietf.org/html/draft-ietf-appsawg-json-merge-patch-02 > >> Abstract: > >> This specification defines the JSON merge patch format and > >> processing > >> rules. >=20 > > Based on feedback. Fairly significant editorial update and one key > > technical change. This updates the media type registration to follow > > the +json naming policy on the media type (that is, > > application/json-merge-patch becomes application/merge-patch+json). >=20 > Most of these changes are great: title, media type, organization. >=20 > I feel there are still issues (in addition to the outstanding issuing = in my last call comments): =20 > [...] >=20 > Could we get a few more reviews or comments in support of advancing = this document? We'd really like to get this one moving, but we can't = without some indication that there's consensus support for doing so. >=20 My apologies for the late comments. I think this document discusses a very useful technology and should = progress. It's understandable and implementable, though I have what I = think is one major issue and a few minor issues. MAJOR ISSUES: * This document does not explicitly state that a merge patch document = can only be a JSON array or JSON object. This is fine with regards to = RFC 4627, but might be problematic given the current and near-future = state of JSON specifications and implementations which now -- or shortly = will -- allow for any JSON value at the top level. If a merge patch = document only makes sense as a JSON array or JSON object, that = stipulation needs to be made explicit; otherwise some accommodation of = any top-level value ought to be made. MINOR ISSUES: * The abstract seems too light. While I understand the reluctance to = repeat oneself, the abstract does get distributed rather widely, and = I've seen people read just the abstract to determine if it probably fits = their needs. Having a fuller abstract can help people determine at a = glance if the document is applicable for their needs. * In section 2. Processing Merge Patch Documents, it states that null = values for Object members and Array elements "MUST be ignored" but then = states that it is to be treated "as if the member was undefined". I = think "MUST be ignored" is confusing; better to state "MUST be removed". * Still in section 2. Processing Merge Patch Documents, the last two = paragraphs seem to be in conflict given the current order. The former = states a processor MUST fail if a modification cannot be made, but the = latter states that a process SHOULD treat the removal of a non-existant = member as a no-op. It would seem just switching the order of the two = paragraph would resolve the conflict. * Yet again in section 2. Processing Merge Patch Documents, I think the = SHOULDs about accepting the merge patch are fine, but I think it would = help to add some rationales for why a processor might reject what = appears to be a perfectly valid merge patch. One example might be if = the merge patch would remove a required member. - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. --Apple-Mail=_939AFDCB-71B3-4DA4-972A-CACA3B10CF5F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSniOYAAoJEDWi+S0W7cO144wIAKqlZK6ZkinicpvOtVHGo4e6 ZupeR0CF63SGg+uhJxe8KoFS2MTeqX/X92r7PSqzjrClPZJYNCTJYNC8rl1XxOi0 e8BCXfy8Vl0u5pAER8pYn5wMgT3smHUPnSgbFei5zUM5E95my5+TCm3K4Yi0CImd Z1wRNEHlCWerxyahQYz03WZfaD4aqL5x0PdvB/NMO6r7mFKX0U6XAiDRnZw0jZLx PtpSnnJPtGQ+9OtiDAscQR3M0WAPpY4AlqPVeiyA/NubUyov76DxT4FBe0z3QRwA TQuHkgXdY/g9DMdsxopGOf9t54EpvKvbeWHN8GLJe7M9vg2ZXLUsCSOudB35Qpg= =R+t1 -----END PGP SIGNATURE----- --Apple-Mail=_939AFDCB-71B3-4DA4-972A-CACA3B10CF5F-- From wmills@yahoo-inc.com Tue Dec 3 20:22:34 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 247A51ADDDA for ; Tue, 3 Dec 2013 20:22:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.22 X-Spam-Level: X-Spam-Status: No, score=-16.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779, USER_IN_DEF_WHITELIST=-15] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AYZRfpEF3eDt for ; Tue, 3 Dec 2013 20:22:33 -0800 (PST) Received: from mrout2-b.corp.bf1.yahoo.com (mrout2-b.corp.bf1.yahoo.com [98.139.253.105]) by ietfa.amsl.com (Postfix) with ESMTP id C7FD51AD937 for ; Tue, 3 Dec 2013 20:22:32 -0800 (PST) Received: from BF1-EX10-CAHT04.y.corp.yahoo.com (bf1-ex10-caht04.corp.bf1.yahoo.com [10.74.209.59]) by mrout2-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id rB44LwCL081234 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 3 Dec 2013 20:21:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1386130919; bh=PRAy1rupWNoQ9pNurlsB7+G2xkZCGevo4mpcty3DoH0=; h=References:Message-ID:Date:From:Reply-To:Subject:To:CC: In-Reply-To:MIME-Version:Content-Type; b=YXxkE7h0ZLAo1t+4FSN/VN7Cxll65RDtdhpAXz4QROCngb9QRtPrlYMp5IHoPtU2v 1DUj0HE38lT7arnpWokgMJ/i4q5AjChlAFyj+QCvqPfhFYkce3hSVPDPGT7JFlyMhr s/e7IBHKukv/wBZNXruquh40U9RVT/SfGwURyGU4= Received: from omp1063.mail.ne1.yahoo.com (98.138.226.162) by BF1-EX10-CAHT04.y.corp.yahoo.com (10.74.209.170) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 3 Dec 2013 23:20:45 -0500 Received: (qmail 13591 invoked by uid 1000); 4 Dec 2013 04:21:57 -0000 Received: (qmail 649 invoked by uid 60001); 4 Dec 2013 04:21:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1386130917; bh=ZA37+ManFIO+K/K7HTYVe2GgKrIu6roVaWlIlxtoU58=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=pMnCZJ4qBQgu616O32x0AVYwB6puLj0hvtpdESfyJulP+j0lUsMPbVXU2GCLQrSNtWLTSgiLCORZAIFgJRoRYz0jDOXLXdxyvAaiUS60EdIzQ9CqpWPEt8U7QSJoMf3Gv9PTnY0bciIubglsUkQm1E72Sd+pZl711jDefBeiGc0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=h133v0qv2HkS4V613oobgpG5EKkF/vRs/jsVNHBeVtCfgx4TQutHn2zHg3cvw5rDcohx3nH7MQIEEe/prRPbZMGlDg6XxDKkpsfyuivo7wyOgrb8qHMh7DFe1CowoF5bcZ9hFMyJrDTQcXXEcBHeLB0OW8W2x2ro5RQW4+ftx9c=; X-YMail-OSG: .qfsgdAVM1nrQXhdFiIStpXujbRNfrC7mrQ4kbI_UM63rnA 53s_N9fDN9MXWDrTKaIKsjhKL_QkxHMmDFct7gihRmo_pNqowy1XY4fZd3FZ 7DgQGaewV7JmJzXCp94S7TtVpclrLn1P5GrvTMrLqlGQlR2_NGNbglUuUarc vdXsXE3gYagpCcoU5IXb4xQxLTOuReZMFtR5vExzy6x73z0BUPyZ5QpI8IVi 4A9MNwM6K9z5FnC0fikTLuJCZLlWt4ic57x89Rai59eTSZNvlgPpvJICy1hM E2h_vylajxcH00ulWbCZFzAQpxUrhGQ-- Received: from [209.131.62.115] by web125601.mail.ne1.yahoo.com via HTTP; Tue, 03 Dec 2013 20:21:57 PST X-Rocket-MIMEInfo: 002.001, U2VjdGlvbiAzLjE6IGlzIGFuIGV4cGxpY2l0IEJORiBzeW50YXggcmVxdWlyZWQgZm9yIHRoZSBJQU5BIHJlZ2lzdHJhdGlvbj_CoCBPciBpcyAiUlJWUz0iICsgZGF0ZS10aW1lIGltcGxpY2l0IGZyb20gdGhlIGRlZmluaXRpb24gaW4gNTMyMT8KCgpTZWN0aW9uIDMuMiAiQ0ZXUyIgaXMgZGVmaW5lZCBidXQgbm90IHJlZmVycmVkIHRvIGFueXdoZXJlIGVsc2U_CgpTZWN0aW9uIDUuMzrCoCBJIHRoaW5rICMzIGlzIG9ubHkgYXBwcm9wcmlhdGUgaWYgIzIgZmlyZWQsIHNob3VsZCAjMyBhY3R1YWxseSBiZSABMAEBAQE- X-Mailer: YahooMailWebService/0.8.167.602 References: <20131120080026.25156.23231.idtracker@ietfa.amsl.com> <52975509.4070401@isode.com> Message-ID: <1386130917.78002.YahooMailNeo@web125601.mail.ne1.yahoo.com> Date: Tue, 3 Dec 2013 20:21:57 -0800 From: Bill Mills To: "Murray S. Kucherawy" , Alexey Melnikov In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1981468715-1360698741-1386130917=:78002" X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 130919000 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rrvs-header-field-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 04:22:34 -0000 ---1981468715-1360698741-1386130917=:78002 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Section 3.1: is an explicit BNF syntax required for the IANA registration?= =A0 Or is "RRVS=3D" + date-time implicit from the definition in 5321?=0A=0A= =0ASection 3.2 "CFWS" is defined but not referred to anywhere else?=0A=0ASe= ction 5.3:=A0 I think #3 is only appropriate if #2 fired, should #3 actuall= y be 2.1?=0A=0AThat's all I see.=0A=0A=A0=0A-bill=0A=0A=0A=0A--------------= ------------------=0AWilliam J. Mills=0A"Paranoid" Yahoo!=0A=0A=0A=0A=0A=0A= On Monday, December 2, 2013 7:42 PM, Murray S. Kucherawy wrote:=0A =0AThanks, Alexey.=0A=0AAny other feedback in support of or r= equesting changes to this version?=A0 Is it ready for WGLC? ---1981468715-1360698741-1386130917=:78002 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Section 3.1: is an explicit BNF syntax required for the IANA registration= ?  Or is "RRVS=3D" + date-time implicit from the definition in 5321?

Section 3.2 "CFWS" is defined but not referred to anywhere else?=

Section 5.3:  I think #3 is only appropriate if #2 fired, shoul= d #3 actually be 2.1?

That's all I see.
 =
-bill


--------------------------------
William J.= Mills
"Paranoid" Yahoo!



On Monday, December 2, 2013 7:42 PM, Murray S. Kucherawy <= ;superuser@gmail.com> wrote:
Thanks, Alexey.

Any other feedback in support of or reque= sting changes to this version?  Is it ready for WGLC?



---1981468715-1360698741-1386130917=:78002-- From jasnell@gmail.com Tue Dec 3 20:43:33 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 019CA1ADF86 for ; Tue, 3 Dec 2013 20:43:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iidTY4w5PKK5 for ; Tue, 3 Dec 2013 20:43:31 -0800 (PST) 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 DC0881ADF23 for ; Tue, 3 Dec 2013 20:43:30 -0800 (PST) Received: by mail-wg0-f42.google.com with SMTP id a1so6469784wgh.1 for ; Tue, 03 Dec 2013 20:43:27 -0800 (PST) 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=M7FUa5H//OM6CSqkO0dzaA9cXb4r7oPInikHo9Y049o=; b=SP+44r0Gjz/Meq475MUoVrFeaY+6hvwym+fcaEwTQqZIaKLnAMhN4rbmgw9Z0QDwXL yLE3KNuxVjhV7KzLVIgpXd0+sO8XpsFRYhjegVlH1alY9zxx8ywx0XyGC4Smn0lPaIFg 6OYepdV4BW9A4hnPYr5CrHy14iQCSysJB7dddlLaNHisv8rM2kResNWruJLJM8i6RoMQ m4+OpvRh2JRKfq9YZuKEUuSN9Fz46OmEYEAOnoWad43tviqzAMUYq9+YA18hjZ1K9B/m A/YQPPVLe8adjUQUbhX5xOpCnDnBpyPAWSQ6KSowBmNYzLJSr/fPJM9WfczhLG2pyuYr 17Xg== X-Received: by 10.194.59.240 with SMTP id c16mr22104195wjr.13.1386132207610; Tue, 03 Dec 2013 20:43:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.221.133 with HTTP; Tue, 3 Dec 2013 20:43:06 -0800 (PST) In-Reply-To: References: From: James M Snell Date: Tue, 3 Dec 2013 20:43:06 -0800 Message-ID: To: "Murray S. Kucherawy" Content-Type: text/plain; charset=UTF-8 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Reviews, please (was Re: Fwd: New Version Notification for draft-ietf-appsawg-json-merge-patch-02.txt) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 04:43:33 -0000 I will take another pass at addressing James M's comments later on this week. I want to wrap this one up also. On Mon, Dec 2, 2013 at 8:14 PM, Murray S. Kucherawy wrote: > On Mon, Nov 18, 2013 at 6:14 PM, Manger, James H > wrote: >> >> >> Title: JSON Merge Patch >> >> Htmlized: >> >> http://tools.ietf.org/html/draft-ietf-appsawg-json-merge-patch-02 >> >> Abstract: >> >> This specification defines the JSON merge patch format and >> >> processing >> >> rules. >> >> > Based on feedback. Fairly significant editorial update and one key >> > technical change. This updates the media type registration to follow >> > the +json naming policy on the media type (that is, >> > application/json-merge-patch becomes application/merge-patch+json). >> >> Most of these changes are great: title, media type, organization. >> >> I feel there are still issues (in addition to the outstanding issuing in >> my last call comments): >> >> [...] > > > Could we get a few more reviews or comments in support of advancing this > document? We'd really like to get this one moving, but we can't without > some indication that there's consensus support for doing so. > > -MSK From ht@inf.ed.ac.uk Wed Dec 4 04:23:24 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9E201AE216 for ; Wed, 4 Dec 2013 04:23:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.502 X-Spam-Level: X-Spam-Status: No, score=-2.502 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8rgrBr3vwuCw for ; Wed, 4 Dec 2013 04:23:21 -0800 (PST) Received: from nougat.ucs.ed.ac.uk (nougat.ucs.ed.ac.uk [129.215.13.205]) by ietfa.amsl.com (Postfix) with ESMTP id 325DF1AE122 for ; Wed, 4 Dec 2013 04:23:20 -0800 (PST) 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 rB4CMrI0023578; Wed, 4 Dec 2013 12:22:58 GMT 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 rB4CMpRe024089; Wed, 4 Dec 2013 12:22:52 GMT 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 rB4CMqXv025802; Wed, 4 Dec 2013 12:22:52 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id rB4CMoKk025798; Wed, 4 Dec 2013 12:22:50 GMT X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: =?iso-8859-1?Q?Martin_J=2E_D=FCrst?= References: <20131119120919.12901.59046.idtracker@ietfa.amsl.com> <528C980D.7070106@it.aoyama.ac.jp> <5295C454.6050006@it.aoyama.ac.jp> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Wed, 04 Dec 2013 12:22:50 +0000 In-Reply-To: <5295C454.6050006@it.aoyama.ac.jp> ("Martin J. =?iso-8859-1?Q?D=FCrst=22's?= message of "Wed\, 27 Nov 2013 19\:07\:16 +0900") 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=iso-8859-1 Content-Transfer-Encoding: quoted-printable 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 Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-xml-mediatypes-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 12:23:24 -0000 Martin J. D=FCrst writes: > This is quite a good start, but has some inaccuracies (and loses the > distinction between "the UTF-16 family" and "utf-16" in the text > above, which is quite relevant (because of the special treatment that > that XML gives "utf-16"). In fact the spec doesn't use the distinction properly, and mostly says UTF-16 when it means the UTF-16 family, what the UNICODE spec calls the UTF-16 encoding form, I think. > Also, both CCS and CES are used for a single character encoding. XML > does not have a single CCS, but a single 'document character set'. So > I don't think any text about CCS or CES is needed. OK > So I have tried a re-write, but I'm not totally sure this will work > for all of the document. Please check. Thanks! I'll mostly use this, modulo the above about family. ht [oops, this has been sitting in my outbox for days :-[ --=20 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 s= pam] From cyrus@daboo.name Wed Dec 4 07:59:37 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AAE01AE2CB for ; Wed, 4 Dec 2013 07:59:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZOj6Bx4GtE-A for ; Wed, 4 Dec 2013 07:59:34 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id 526431AE2C0 for ; Wed, 4 Dec 2013 07:59:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 45C9254F62E0; Wed, 4 Dec 2013 10:59:31 -0500 (EST) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GML5svvKEjy4; Wed, 4 Dec 2013 10:59:30 -0500 (EST) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id 7AB0454F62CB; Wed, 4 Dec 2013 10:59:29 -0500 (EST) Date: Wed, 04 Dec 2013 10:59:26 -0500 From: Cyrus Daboo To: "Murray S. Kucherawy" , Stephan Bosch Message-ID: <1BC1A404FE3E89FEA37FAB45@caldav.corp.apple.com> In-Reply-To: References: X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; size=1410 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Reviewers, please (was Re: I-D Action: draft-ietf-appsawg-sieve-duplicate-01.txt) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Dec 2013 15:59:37 -0000 Hi Murray, Please note discussion of this draft started on the SIEVE mailing list=20 (mailto:sieve@ietf.org>). I have posted a message there asking for reviews=20 to be posted to apps-discuss. --On December 2, 2013 at 7:41:14 PM -0800 "Murray S. Kucherawy"=20 wrote: > Can we get some reviewers for this draft, please? My review: I only minor/editorial issues. This is a potentially useful extension and=20 should be standardized. Minor issues: - =C2=A73 talks about how :header field values are normalized = (leading/trailing=20 spaces removed). I don=E2=80=99t see any text about how Message-ID ought to = be=20 normalized - is that needed? - =C2=A73: talks about using SIEVE-MIME to extract message body text, but = what=20 about the SIEVE body extension (RFC 5173)? - =C2=A75.3: some of the examples have =E2=80=9Cif=E2=80=9D statements that = erroneously end=20 with a =E2=80=9C)=E2=80=9D - =C2=A75.3: I would like to see an example of the use of :handle as I am = not=20 entirely sure when that would be applicable Editorial: - Abstract - no need to quote Sieve - =C2=A71 =C2=B62: change "through mailing list=E2=80=9D to "through the = mailing list=E2=80=9D - =C2=A73 =C2=B66: change "If that limit is exceeded,=E2=80=9D to "If that = limit is=20 exceeded by the =E2=80=9C:seconds=E2=80=9D argument,=E2=80=9D - =C2=A75.2 =C2=B62: change "script above the=E2=80=9D to "script above, = the=E2=80=9D - =C2=A76 =C2=B61: change "Implementations therefore SHOULD implement = limits=E2=80=9D to=20 "Implementations SHOULD apply limits" --=20 Cyrus Daboo From stephan@rename-it.nl Thu Dec 5 00:41:39 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C1F51AD8F6 for ; Thu, 5 Dec 2013 00:41:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.194 X-Spam-Level: X-Spam-Status: No, score=0.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BzHGZcz3gRIR for ; Thu, 5 Dec 2013 00:41:36 -0800 (PST) Received: from drpepper.rename-it.nl (drpepper.rename-it.nl [217.119.238.16]) by ietfa.amsl.com (Postfix) with ESMTP id 0C20B1AD8F2 for ; Thu, 5 Dec 2013 00:41:35 -0800 (PST) Received: from klara.student.utwente.nl ([130.89.162.218]:52657 helo=[10.168.3.2]) by drpepper.rename-it.nl with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1VoUUw-00018k-A0; Thu, 05 Dec 2013 09:41:29 +0100 Message-ID: <52A03BD6.8020303@rename-it.nl> Date: Thu, 05 Dec 2013 09:39:50 +0100 From: Stephan Bosch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Cyrus Daboo References: <1BC1A404FE3E89FEA37FAB45@caldav.corp.apple.com> In-Reply-To: <1BC1A404FE3E89FEA37FAB45@caldav.corp.apple.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-RenameIT-MailScanner-SpamScore: -2.3 (--) X-RenameIT-MailScanner-SpamCheck: No, score=-2.3 required=5.0 tests=ALL_TRUSTED, BAYES_00 autolearn=ham version=3.3.1 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Reviewers, please (was Re: I-D Action: draft-ietf-appsawg-sieve-duplicate-01.txt) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 08:41:39 -0000 Hi, On 12/4/2013 4:59 PM, Cyrus Daboo wrote: > I only minor/editorial issues. This is a potentially useful extension > and should be standardized. > > Minor issues: > > - §3 talks about how :header field values are normalized > (leading/trailing spaces removed). I don’t see any text about how > Message-ID ought to be normalized - is that needed? Yes that is need. It is mentioned, albeit indirect: "If the tracked unique ID value is extracted directly from a message header field, i.e., when the ":uniqueid" argument is not used, leading and trailing whitespace (see Section 2.2 of RFC 5228 [SIEVE]) MUST first be trimmed from the value before performing the actual duplicate verification.". This statement is perhaps a bit too indirect, so I'll make it more explicit. > - §3: talks about using SIEVE-MIME to extract message body text, but > what about the SIEVE body extension (RFC 5173)? As stated in RFC5173, Section 6 (http://tools.ietf.org/html/rfc5173#section-6) the body test is exempt from setting match variables in combination with the variables extension and therefore it cannot be used to extract text from the message body for use with the "duplicate" test. > - §5.3: some of the examples have “if” statements that erroneously end > with a “)” Right. I should feed these to my compiler. I will fix these. > - §5.3: I would like to see an example of the use of :handle as I am > not entirely sure when that would be applicable So, just to be clear: do you want an example of why :handle is useful, or do you want an example of how :handle works? > Editorial: > > - Abstract - no need to quote Sieve > - §1 ¶2: change "through mailing list” to "through the mailing list” > - §3 ¶6: change "If that limit is exceeded,” to "If that limit is > exceeded by the “:seconds” argument,” > - §5.2 ¶2: change "script above the” to "script above, the” > - §6 ¶1: change "Implementations therefore SHOULD implement limits” to > "Implementations SHOULD apply limits" Thanks for the review! I'll make a new version within a week. Regards, Stephan. From cyrus@daboo.name Thu Dec 5 06:53:52 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7112C1AE020 for ; Thu, 5 Dec 2013 06:53:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mi9WznCbY9V1 for ; Thu, 5 Dec 2013 06:53:51 -0800 (PST) Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id DEBF91AE007 for ; Thu, 5 Dec 2013 06:53:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id BDCCD5513A38; Thu, 5 Dec 2013 09:53:47 -0500 (EST) X-Virus-Scanned: amavisd-new at example.com Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kTq1uS6KyMgG; Thu, 5 Dec 2013 09:53:47 -0500 (EST) Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id 08E815513A2C; Thu, 5 Dec 2013 09:53:45 -0500 (EST) Date: Thu, 05 Dec 2013 09:53:42 -0500 From: Cyrus Daboo To: Stephan Bosch Message-ID: <8C2F00E5BD774D5CC8B82B67@caldav.corp.apple.com> In-Reply-To: <52A03BD6.8020303@rename-it.nl> References: <1BC1A404FE3E89FEA37FAB45@caldav.corp.apple.com> <52A03BD6.8020303@rename-it.nl> X-Mailer: Mulberry/4.1.0a3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; size=531 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Reviewers, please (was Re: I-D Action: draft-ietf-appsawg-sieve-duplicate-01.txt) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 14:53:52 -0000 Hi Stephan, --On December 5, 2013 at 9:39:50 AM +0100 Stephan Bosch=20 wrote: >> - =C2=A75.3: I would like to see an example of the use of :handle as I = am >> not entirely sure when that would be applicable > > So, just to be clear: do you want an example of why :handle is useful, > or do you want an example of how :handle works? > I guess I am more interested in why it is useful (and thus whether it is=20 needed at all). Based on that, it may or may not be worthwhile to include=20 an example. --=20 Cyrus Daboo From internet-drafts@ietf.org Thu Dec 5 09:19:29 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E24711AE107; Thu, 5 Dec 2013 09:19:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OvntqlH6Biny; Thu, 5 Dec 2013 09:19:28 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C081A1AE115; Thu, 5 Dec 2013 09:19:27 -0800 (PST) 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.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131205171927.30883.60954.idtracker@ietfa.amsl.com> Date: Thu, 05 Dec 2013 09:19:27 -0800 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-xml-mediatypes-06.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 17:19:30 -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 : XML Media Types Author(s) : Henry S. Thompson Chris Lilley Filename : draft-ietf-appsawg-xml-mediatypes-06.txt Pages : 31 Date : 2013-12-05 Abstract: This specification standardizes three media types -- application/xml, application/xml-external-parsed-entity, and application/xml-dtd -- for use in exchanging network entities that are related to the Extensible Markup Language (XML) while defining text/xml and text/ xml-external-parsed-entity as aliases for the respective application/ types. This specification also standardizes the '+xml' suffix for naming media types outside of these five types when those media types represent XML MIME entities. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-xml-mediatypes There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-xml-mediatypes-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-xml-mediatypes-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ht@inf.ed.ac.uk Thu Dec 5 09:31:17 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 154111AE009 for ; Thu, 5 Dec 2013 09:31:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UAtr78hO4zFO for ; Thu, 5 Dec 2013 09:31:13 -0800 (PST) Received: from nougat.ucs.ed.ac.uk (nougat.ucs.ed.ac.uk [129.215.13.205]) by ietfa.amsl.com (Postfix) with ESMTP id CF13A1A802B for ; Thu, 5 Dec 2013 09:31:12 -0800 (PST) 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 rB5HV8pD022457 for ; Thu, 5 Dec 2013 17:31:08 GMT 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 rB5HV79a005082 for ; Thu, 5 Dec 2013 17:31:07 GMT 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 rB5HV8JR030838 for ; Thu, 5 Dec 2013 17:31:08 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id rB5HV7SU030834; Thu, 5 Dec 2013 17:31:07 GMT 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: <20131205171927.30883.60954.idtracker@ietfa.amsl.com> From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Thu, 05 Dec 2013 17:31:07 +0000 In-Reply-To: <20131205171927.30883.60954.idtracker@ietfa.amsl.com> (internet-drafts@ietf.org's message of "Thu\, 05 Dec 2013 09\:19\:27 -0800") 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] I-D Action: draft-ietf-appsawg-xml-mediatypes-06.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 17:31:17 -0000 internet-drafts writes: > 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 : XML Media Types > Author(s) : Henry S. Thompson > Chris Lilley > Filename : draft-ietf-appsawg-xml-mediatypes-06.txt > Pages : 31 > Date : 2013-12-05 As usual, a disposition of comments against the previous draft is available at http://www.w3.org/XML/2012/10/3023bis/05-comments.html and an author's diff is at http://www.w3.org/XML/2012/10/3023bis/draft-ietf-appsawg-xml-mediatypes-06_diff.html The changes in this draft are mostly in response to extensive and helpful comments from Martin Duerst, and are mostly fairly low-level, although in some cases pervasive, particularly in that I've tried to be much more careful and consistent wrt terminology around the issue of character encodings. There are a few substantive changes, most notably as a result of helpful feedback from Bjoern Hoehrmann about backwards-compatibility problems arising from the promotion of BOMs to 'most authoritative' status. * UTF-32 encoding is NOT RECOMMENDED for XML MIME entities * The requirement in XML to include an encoding declaration at the beginning of external parsed entities in the absence of a charset parameter is made unqualified (that is, is extended to the case where there _is_ a charset parameter) when the entity begins with a byte-sequence that would otherwise risk being taken for a BOM. Comments hereby solicited on these changes, and all other aspects of the draft. 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 ietf-secretariat-reply@ietf.org Thu Dec 5 12:16:54 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 429571AE16D for ; Thu, 5 Dec 2013 12:16:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2lToQE6nnoDZ for ; Thu, 5 Dec 2013 12:16:52 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 72FEE1AE17A for ; Thu, 5 Dec 2013 12:16:50 -0800 (PST) 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.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131205201650.28748.41244.idtracker@ietfa.amsl.com> Date: Thu, 05 Dec 2013 12:16:50 -0800 From: IETF Secretariat Subject: [apps-discuss] Milestones changed for appsawg WG X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 20:16:54 -0000 Changed milestone "Publication requested for draft-ietf-appsawg-malformed-mail", resolved as "Done". Changed milestone "Publication requested for draft-ietf-appsawg-xml-mediatypes", set due date to December 2013 from November 2013. Changed milestone "Publication requested for draft-ietf-appsawg-rrvs-header-field", set due date to December 2013 from November 2013. Changed milestone "Publication requested for draft-ietf-appsawg-json-merge-patch", set due date to December 2013 from September 2013. Changed milestone "Publication requested for draft-ietf-appsawg-sieve-duplicate", set due date to December 2013 from November 2013. URL: http://datatracker.ietf.org/wg/appsawg/charter/ From superuser@gmail.com Thu Dec 5 12:32:18 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD3D31AE088 for ; Thu, 5 Dec 2013 12:32:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gBqtUabPrBVq for ; Thu, 5 Dec 2013 12:32:17 -0800 (PST) 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 3A7591A16F0 for ; Thu, 5 Dec 2013 12:32:16 -0800 (PST) Received: by mail-wi0-f181.google.com with SMTP id hq4so250789wib.14 for ; Thu, 05 Dec 2013 12:32:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=0plB5N0wLIe7TueFN1vv1h4tzzxuYwWv+ZxdEOPIQOc=; b=dCnIPENs3s9tU0kD2nYj+vCVXbfysziDB5JCjXRLD/5etjQR5YbWKZqQgyLa6YOgPe m+1jwZlSfR+CdwKHqB3/e58ofBDBYpKJz5lcgwF3/50FyxgAxEESAy4FNz1wv8m8Vg0G yZgc9lII94cK4IUXOxGkFTQ4VdrUaDd860oIFTN0DRRDqqdSUdDabEsXyUjqVeGMtRpT 7ilUseUoO4myko4++GxT1UNBmx+Y4VAHYgSyTvnVI4jU2DKzFmRxvVOcdZlaedLDRtmG iPWTK98hUCxEkVw8mC5I4rviz7HSSvuECNGzw6+OF3dVEeW7PvrMrHzThR9re1/25p9a S/3A== MIME-Version: 1.0 X-Received: by 10.194.219.165 with SMTP id pp5mr9304wjc.92.1386275533200; Thu, 05 Dec 2013 12:32:13 -0800 (PST) Received: by 10.181.13.230 with HTTP; Thu, 5 Dec 2013 12:32:12 -0800 (PST) Date: Thu, 5 Dec 2013 12:32:12 -0800 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=001a11c1b808b7a83504eccf6c86 Subject: [apps-discuss] Reviewers, please, for draft-ietf-appsawg-uri-get-off-my-lawn X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 20:32:19 -0000 --001a11c1b808b7a83504eccf6c86 Content-Type: text/plain; charset=ISO-8859-1 There was originally quite a bit of support for this document, but I haven't seen any reviews or comments posted about it since its adoption as a WG item. Could people give it a review and post comments, please? If it's ready for last call as-is, that would be useful to know as well. Thanks, -MSK --001a11c1b808b7a83504eccf6c86 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
There was originally quite a bit of support for this = document, but I haven't seen any reviews or comments posted about it si= nce its adoption as a WG item.=A0 Could people give it a review and post co= mments, please?=A0 If it's ready for last call as-is, that would be use= ful to know as well.

Thanks,
-MSK
--001a11c1b808b7a83504eccf6c86-- From ietf-secretariat-reply@ietf.org Thu Dec 5 12:33:51 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDA951A16F0 for ; Thu, 5 Dec 2013 12:33:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IEPe49OyRzf4 for ; Thu, 5 Dec 2013 12:33:50 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 392C41AE088 for ; Thu, 5 Dec 2013 12:33:49 -0800 (PST) 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.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131205203349.28748.48891.idtracker@ietfa.amsl.com> Date: Thu, 05 Dec 2013 12:33:49 -0800 From: IETF Secretariat Subject: [apps-discuss] Milestones changed for appsawg WG X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 20:33:52 -0000 URL: http://datatracker.ietf.org/wg/appsawg/charter/ From ietf-secretariat-reply@ietf.org Thu Dec 5 12:37:26 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE70B1AD8D8 for ; Thu, 5 Dec 2013 12:37:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qjczpG9lmi4Z for ; Thu, 5 Dec 2013 12:37:24 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7237B1AE04F for ; Thu, 5 Dec 2013 12:37:23 -0800 (PST) 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.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131205203723.2118.69404.idtracker@ietfa.amsl.com> Date: Thu, 05 Dec 2013 12:37:23 -0800 From: IETF Secretariat Subject: [apps-discuss] Milestones changed for appsawg WG X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 20:37:27 -0000 Changed milestone "Publication requested for draft-ietf-appsawg-multipart-form-data", set state to active from review, accepting new milestone. URL: http://datatracker.ietf.org/wg/appsawg/charter/ From dret@berkeley.edu Thu Dec 5 13:15:09 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F5EB1AE16D for ; Thu, 5 Dec 2013 13:15:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B_B3dJFNWjSK for ; Thu, 5 Dec 2013 13:14:55 -0800 (PST) Received: from cm05fe.IST.Berkeley.EDU (cm05fe.IST.Berkeley.EDU [169.229.218.146]) by ietfa.amsl.com (Postfix) with ESMTP id D75C81AE16A for ; Thu, 5 Dec 2013 13:14:55 -0800 (PST) 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 1VogG3-0000u1-Gf; Thu, 05 Dec 2013 13:14:52 -0800 Message-ID: <52A0ECC8.1010108@berkeley.edu> Date: Thu, 05 Dec 2013 13:14:48 -0800 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" , IETF Apps Discuss References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] Reviewers, please, for draft-ietf-appsawg-uri-get-off-my-lawn X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Dec 2013 21:15:09 -0000 X-List-Received-Date: Thu, 05 Dec 2013 21:15:09 -0000 hello all. On 2013-12-05, 12:32 , Murray S. Kucherawy wrote: > There was originally quite a bit of support for this document, but I > haven't seen any reviews or comments posted about it since its adoption > as a WG item. Could people give it a review and post comments, please? > If it's ready for last call as-is, that would be useful to know as well. http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10722.html is where i commented on this draft a little while ago. i think it is useful as it is, but (as written in that earlier comment), it might be even more useful is it listed some popular anti-patterns as well. i've become a fan of well-explained anti-patterns (meaning that there should be an easy-to-follow explanation of *why* they should be avoided), as they work well as educational examples, and as references to point people to. i'd be more than happy to collect, curate, and contribute a couple of anti-patterns, if people think that would be a useful thing to add. i don't think there's a shortage of those in existing work out there :-) 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 franck@peachymango.org Thu Dec 5 19:12:35 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E0031AE22A for ; Thu, 5 Dec 2013 19:12:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OrIikMmPVPlh for ; Thu, 5 Dec 2013 19:12:31 -0800 (PST) Received: from smtp.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id BD5A71AD9A9 for ; Thu, 5 Dec 2013 19:12:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 379BD3F435E for ; Thu, 5 Dec 2013 21:12:28 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZeGqXUiqhkP for ; Thu, 5 Dec 2013 21:12:28 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 1A0CC3F437D for ; Thu, 5 Dec 2013 21:12:28 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 0494E3F436F for ; Thu, 5 Dec 2013 21:12:28 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id cOCyjZKH9V95 for ; Thu, 5 Dec 2013 21:12:27 -0600 (CST) Received: from mail-2.01.com (mail.01.com [172.18.30.178]) by smtp-out-1.01.com (Postfix) with ESMTP id DFDEF3F435E for ; Thu, 5 Dec 2013 21:12:27 -0600 (CST) Date: Thu, 5 Dec 2013 21:12:27 -0600 (CST) From: Franck Martin To: IETF Apps Discuss Message-ID: <83737770.209987.1386299547311.JavaMail.zimbra@peachymango.org> In-Reply-To: <1671208202.209936.1386299205123.JavaMail.zimbra@peachymango.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_209986_1141658245.1386299547310" X-Originating-IP: [69.28.149.129] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF25 (Mac)/8.0.5_GA_5839) Thread-Topic: New Version Notification for draft-martin-smtp-target-host-selection-ipv4-ipv6-01.txt Thread-Index: 3FWx07o0ljZ8RO52FjB9m7pnmor0Xw== Subject: [apps-discuss] New Version Notification for draft-martin-smtp-target-host-selection-ipv4-ipv6-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 03:12:35 -0000 ------=_Part_209986_1141658245.1386299547310 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit I took some of the comments, and tried to clarify things. I hope I did not make it more complex. :P A new version of I-D, draft-martin-smtp-target-host-selection-ipv4-ipv6-01.txt has been successfully submitted by Franck Martin and posted to the IETF repository. Filename: draft-martin-smtp-target-host-selection-ipv4-ipv6 Revision: 01 Title: SMTP target host selection in Mixed IPv4/IPv6 environments Creation date: 2013-12-05 Group: Individual Submission Number of pages: 8 URL: http://www.ietf.org/internet-drafts/draft-martin-smtp-target-host-selection-ipv4-ipv6-01.txt Status: http://datatracker.ietf.org/doc/draft-martin-smtp-target-host-selection-ipv4-ipv6 Htmlized: http://tools.ietf.org/html/draft-martin-smtp-target-host-selection-ipv4-ipv6-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-martin-smtp-target-host-selection-ipv4-ipv6-01 Abstract: The Simple Mail Transfer Protocol (SMTP) is defined in [RFC5321]. Section 5 of that document describes the process of host selection. While locating the target host in IPv4 is well defined, this process is unclear for systems in IPv4 and IPv6 environments. This specification extends [RFC5321] to provide a standard way of selecting the target host in mixed environments. ------=_Part_209986_1141658245.1386299547310 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I took some of the comments, and tried to cla= rify things. I hope I did not make it more complex. :P

A = new version of I-D, draft-martin-smtp-target-host-selection-ipv4-ipv6-01.tx= t
has been successfully submitted by Franck Martin and posted to the
= IETF repository.

Filename:     draft-martin-smtp-targ= et-host-selection-ipv4-ipv6
Revision:     01
Title:&nb= sp;        SMTP target host selection in Mixed IPv= 4/IPv6 environments
Creation date:     2013-12-05
Grou= p:         Individual Submission
Number of= pages: 8
URL:         &nbs= p;   http://www.ietf.org/internet-drafts/draft-martin-smtp-target= -host-selection-ipv4-ipv6-01.txt
Status:     &n= bsp;    http://datatracker.ietf.org/doc/draft-martin-smtp-ta= rget-host-selection-ipv4-ipv6
Htmlized:     &nb= sp;  http://tools.ietf.org/html/draft-martin-smtp-target-host-selectio= n-ipv4-ipv6-01
Diff:        &nbs= p;   http://www.ietf.org/rfcdiff?url2=3Ddraft-martin-smtp-target-= host-selection-ipv4-ipv6-01

Abstract:
  The Simple Mail Tran= sfer Protocol (SMTP) is defined in [RFC5321].
  Section 5 of that d= ocument describes the process of host selection.
  While locating t= he target host in IPv4 is well defined, this process
  is unclear f= or systems in IPv4 and IPv6 environments.  This
  specificatio= n extends [RFC5321] to provide a standard way of
  selecting the ta= rget host in mixed environments.
------=_Part_209986_1141658245.1386299547310-- From stpeter@stpeter.im Thu Dec 5 19:17:51 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE89C1AE22A for ; Thu, 5 Dec 2013 19:17:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jbCki982OS7g for ; Thu, 5 Dec 2013 19:17:48 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 4B7541AE17F for ; Thu, 5 Dec 2013 19:17:48 -0800 (PST) Received: from ergon.local (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5E6AB40332; Thu, 5 Dec 2013 20:17:44 -0700 (MST) Message-ID: <52A141D7.4040103@stpeter.im> Date: Thu, 05 Dec 2013 20:17:43 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Erik Wilde , "Murray S. Kucherawy" , IETF Apps Discuss References: <52A0ECC8.1010108@berkeley.edu> In-Reply-To: <52A0ECC8.1010108@berkeley.edu> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] Reviewers, please, for draft-ietf-appsawg-uri-get-off-my-lawn X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 03:17:51 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/5/13 2:14 PM, Erik Wilde wrote: > hello all. > > On 2013-12-05, 12:32 , Murray S. Kucherawy wrote: >> There was originally quite a bit of support for this document, >> but I haven't seen any reviews or comments posted about it since >> its adoption as a WG item. Could people give it a review and >> post comments, please? If it's ready for last call as-is, that >> would be useful to know as well. > > http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10722.html > > is where i commented on this draft a little while ago. i think it is > useful as it is, but (as written in that earlier comment), it might > be even more useful is it listed some popular anti-patterns as > well. Having just read the I-D again, I would concur that more examples would be helpful. 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/ iQIcBAEBAgAGBQJSoUHXAAoJEOoGpJErxa2pauIQAIW8rfwUf+VbxW8yilz2HuOT bgVZmr2Fp5aXfOOzQboduh4omj+WdVFx79a7qT7ZXhI73jkLTZkyqQ6M+jbtH9Ul W3EtRt/MiOEetSG1GjGTkUmR1KIU64ptsQylST3h/c7Mtlh90BOvNbZeTFy0/BV9 pHUvNha2l+Ej4tXb7BNIwmjsS6uThBAWNU12PcjrJnf9Ft58BqUxnY0gKaL0/3UX /vBi1vm2XnRPnMJfPcVaSQPQu1QGOeKMqkebxR0h+oXIUIBYFneOhgIc5Q5YJ2/I f258WzdhvY/vk+xa9ku+ygs/unnDVv3GFrAo+Eu/9ymIyoEdtpt1X0rj5tHaP+xD 14ttksAmHj7h4Yn1f4DRHxDa3c2H6V9ZdqERJW1oHDDPzyef4xy7EuM1GKdnRi5O TmtFPXfDNDTWQtUMYTBjJZNXGclbLFp+0YLDKtCDOY0ndnnc2hhBbeU0U8zjasqw 3HhAvQIHD/BrIJqMD4mzgxQ3prDLqvtSA1es0hK26C3+IcMj1o/P4pXcvd5X5kLs nQwwSPS7JeBjAaGMk7oiHPzH+vnGN+j6oeLaHaF1WqrYYTOV0KrTLuuIx3z4VqCI j8lnJaL9S41GvuXWNEN2EZBZ7l43s5IdaFRaOjT8+TrWDebzfiAtieoXssFjNwro a2ctwb498+323ZuPmsCo =P477 -----END PGP SIGNATURE----- From mnot@mnot.net Thu Dec 5 21:46:45 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA3B1AE229 for ; Thu, 5 Dec 2013 21:46:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhuu0GIqA13p for ; Thu, 5 Dec 2013 21:46:43 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 1A7491ADF23 for ; Thu, 5 Dec 2013 21:46:43 -0800 (PST) Received: from [192.168.1.55] (unknown [118.209.134.50]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 7EB31509B8; Fri, 6 Dec 2013 00:46:35 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Mark Nottingham In-Reply-To: <52A141D7.4040103@stpeter.im> Date: Fri, 6 Dec 2013 16:46:31 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <5E0AFB6D-4E9F-41A3-A5E3-AE2C083766E0@mnot.net> References: <52A0ECC8.1010108@berkeley.edu> <52A141D7.4040103@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1822) Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Reviewers, please, for draft-ietf-appsawg-uri-get-off-my-lawn X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 05:46:45 -0000 On 6 Dec 2013, at 2:17 pm, Peter Saint-Andre wrote: >> On 2013-12-05, 12:32 , Murray S. Kucherawy wrote: >>> There was originally quite a bit of support for this document, >>> but I haven't seen any reviews or comments posted about it since >>> its adoption as a WG item. Could people give it a review and >>> post comments, please? If it's ready for last call as-is, that >>> would be useful to know as well. >>=20 >> = http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10722.html >>=20 >>=20 > is where i commented on this draft a little while ago. i think it is >> useful as it is, but (as written in that earlier comment), it might >> be even more useful is it listed some popular anti-patterns as >> well. >=20 > Having just read the I-D again, I would concur that more examples > would be helpful. I'm more than happy to incorporate more examples (I shied away from = doing so a bit so as not to ruffle feathers of particular efforts). As I've said many times, I strongly do NOT want this to become a = repository of anti-patterns, because doing so will inevitably become an = attractive nuisance and seriously delay this document. This isn't the = last BCP ever published; there will be ample opportunity in other, = future documents to document more bad things people do. Cheers, -- Mark Nottingham http://www.mnot.net/ From dwing@cisco.com Thu Dec 5 22:04:45 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F37641AE2D0 for ; Thu, 5 Dec 2013 22:04:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NWd4WCouqwrp for ; Thu, 5 Dec 2013 22:04:43 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 5367F1AE2C8 for ; Thu, 5 Dec 2013 22:04:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2469; q=dns/txt; s=iport; t=1386309880; x=1387519480; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=/rwuBrgaUYnrkutpiJjZMaHpvG9qMasblzIho8aVtHY=; b=CzhTyj3oFy+nxHkiNbm3baXtGlB8SnfO8ewlKb1TH9jAcNsxWtwvqlqs n/pDc/3uLEKAb8HvrYMY515FOP9/AgL890K5WgtSxSqpiZ9L+a0axflp4 1DExfUdUheyJ5L/A1lzzKEx0JZ88IZyyOtvb50jjPqEUJ6WIBG35/RCv3 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAJpooVKrRDoH/2dsb2JhbABZgwc4uUaBJBZ0giUBAQEDAQEBATc0CQIFCws7CycwBgoJCYdzBQ7BDReOLwEBHDMHgyCBEwOJQo5SgTCQY4FrgV8bgTU X-IronPort-AV: E=Sophos;i="4.93,839,1378857600"; d="scan'208";a="99589436" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 06 Dec 2013 06:04:28 +0000 Received: from sjc-vpn7-1898.cisco.com (sjc-vpn7-1898.cisco.com [10.21.151.106]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rB6642Ec026585; Fri, 6 Dec 2013 06:04:15 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Dan Wing In-Reply-To: <83737770.209987.1386299547311.JavaMail.zimbra@peachymango.org> Date: Thu, 5 Dec 2013 22:04:02 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <8BBD1945-9AA0-42D5-85A2-D4B4639204E7@cisco.com> References: <83737770.209987.1386299547311.JavaMail.zimbra@peachymango.org> To: Franck Martin X-Mailer: Apple Mail (2.1510) Cc: IETF Apps Discuss Subject: Re: [apps-discuss] New Version Notification for draft-martin-smtp-target-host-selection-ipv4-ipv6-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 06:04:45 -0000 ... In some ways, this strategy is similar to the Happy Eveballs [RFC6555] strategy where web browsers initiate parralel connections to web servers using IPv4 and IPv6 and select the better connection. ... RFC6555 does not describe initiating parallel connections, reference = http://tools.ietf.org/html/rfc6555#section-5.5 I think your I-D would be improved by providing guidance for how long to = wait for TCP connection itself. I see = http://tools.ietf.org/search/rfc5321#section-4.5.3.2.1 says 5 minutes = for the initial 220, but it is silent on the TCP connection timeout. A = 5 minute delay for IPv6 path brokenness makes for slow mail delivery, = and can convince many a system administrator to disable IPv6 to reduce = user complaints of slow delivery. -d On Dec 5, 2013, at 7:12 PM, Franck Martin = wrote: > I took some of the comments, and tried to clarify things. I hope I did = not make it more complex. :P >=20 > A new version of I-D, = draft-martin-smtp-target-host-selection-ipv4-ipv6-01.txt > has been successfully submitted by Franck Martin and posted to the > IETF repository. >=20 > Filename: draft-martin-smtp-target-host-selection-ipv4-ipv6 > Revision: 01 > Title: SMTP target host selection in Mixed IPv4/IPv6 = environments > Creation date: 2013-12-05 > Group: Individual Submission > Number of pages: 8 > URL: = http://www.ietf.org/internet-drafts/draft-martin-smtp-target-host-selectio= n-ipv4-ipv6-01.txt > Status: = http://datatracker.ietf.org/doc/draft-martin-smtp-target-host-selection-ip= v4-ipv6 > Htmlized: = http://tools.ietf.org/html/draft-martin-smtp-target-host-selection-ipv4-ip= v6-01 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-martin-smtp-target-host-selection= -ipv4-ipv6-01 >=20 > Abstract: > The Simple Mail Transfer Protocol (SMTP) is defined in [RFC5321]. > Section 5 of that document describes the process of host selection. > While locating the target host in IPv4 is well defined, this process > is unclear for systems in IPv4 and IPv6 environments. This > specification extends [RFC5321] to provide a standard way of > selecting the target host in mixed environments. > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From tbray@textuality.com Thu Dec 5 22:22:13 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 854371AE2E7 for ; Thu, 5 Dec 2013 22:22:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1zwFkNUadSrE for ; Thu, 5 Dec 2013 22:22:12 -0800 (PST) Received: from mail-vc0-f170.google.com (mail-vc0-f170.google.com [209.85.220.170]) by ietfa.amsl.com (Postfix) with ESMTP id C9B251AE2D7 for ; Thu, 5 Dec 2013 22:22:11 -0800 (PST) Received: by mail-vc0-f170.google.com with SMTP id ht10so276922vcb.15 for ; Thu, 05 Dec 2013 22:22:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=CXttAeceZCJKjkXf+vV6nKkVnPK9luQ8+NCXfh/bS6E=; b=Pk28oGKRlF88aRDjhcwxfXxx8Oj0zbcY6TBRtc9lDSVPopzNoikJyQQwgZpXSm2mjz Hs8t9wKYHkF/VMMLy+G3Z2MVtgH07HaTne054POItUupHHAAay0eiT3izIvE20Ivahl7 O9+SQNul4fqZqRhHczHKgSiOcCoOTURqyJ5NyKBWMsJrLjpZR5TZ6b2h1Dgl+oT0210V A9GsTvZ0g0PUbOA+bjsngCaEIX82yEpxozHto+kbSfHC1/PfLwZ0XButUnf8lS4LA/hX a5I8KdMCMHZFwboCxvmuRAEc34BUd08DPRA9w93NbnYuO9XAgilTW1jX4M+C0se70av5 TjlA== X-Gm-Message-State: ALoCoQmU0LcMcMgqcuZc5aKGyPAE9uMpuZkGpTWz2N/0lufvppHjUiVvmGOlflju6M7oweP04HDm MIME-Version: 1.0 X-Received: by 10.220.48.194 with SMTP id s2mr524564vcf.43.1386310927898; Thu, 05 Dec 2013 22:22:07 -0800 (PST) Received: by 10.220.198.199 with HTTP; Thu, 5 Dec 2013 22:22:07 -0800 (PST) X-Originating-IP: [24.84.235.32] Date: Thu, 5 Dec 2013 22:22:07 -0800 Message-ID: From: Tim Bray To: "apps-discuss@ietf.org" Content-Type: multipart/alternative; boundary=001a11c1e7fc684ad404ecd7aa03 Subject: [apps-discuss] Review of draft-ietf-appsawg-uri-get-off-my-lawn X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 06:22:13 -0000 --001a11c1e7fc684ad404ecd7aa03 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think this should be published as a Best Common Practice soon as possible= . Minor issues: * The title and introduction: =E2=80=9CStandardising Structure in URIs=E2=80=9C is unfortunate because th= e central message is =E2=80=9CDon=E2=80=99t try to standardize structure in URIs=E2= =80=9D. How about =E2=80=9CPreserving URI Space Design Freedom=E2=80=9D or =E2=80=9CURI Struc= ture Design Considered Harmful=E2=80=9D or =E2=80=9CURI Space Design Ownership=E2=80=9D - I think = that last one is a serious suggestion. : This document cautions against this practice in standards (sometimes called "URI Squatting"). I=E2=80=99m not sure the =E2=80=9Csometimes called=E2=80=9D parenthetical r= eally adds value, but if preserved, it should be moved to immediately after =E2=80=9Cthis practice= =E2=80=9D. Also, the document doesn=E2=80=99t caution against it, it bristles with MUST NOTs= . How about =E2=80=9CThis document is intended to prevent the use of this practic= e (sometimes called "URI Squatting") in standards.=E2=80=9D * 1. Introduction The bullet point beginning =E2=80=9CDilution=E2=80=9D is grammatically stra= ined. The =E2=80=9Cextra information=E2=80=9D is the subject of both verbs, so turn i= t around to read something like =E2=80=9CExtra information, added to URIs to support standardization, dilutes their usefulness as ..., and causes alternate forms of the URI to exist. And I=E2=80=99m not sure Dilution is the right = label; the key point is weakening the URI=E2=80=99s utility as an identifier. Havi= ng said that I can=E2=80=99t think of a one-word alternative. In that list of bullet points, you might also want to add that query parameters are problematic for two more reasons: There=E2=80=99s not a good= hook in 3986 to use to say what you=E2=80=99re talking about, and also you=E2=80=99= re doing a parameter-name land-grab, which means you now have another design problem, you have to prefix or otherwise clutter your parameter names to in effect create a namespace for them. Or worse, don=E2=80=99t. 2nd-last para: The phrase that begins =E2=80=9Cpublishing standards that m= andate URI structure is inappropriate... =E2=80=9D is the central tl;dr of this wh= ole draft, very nicely crystallized. Could it be pulled out and featured in the introduction or even abstract? * 2. =E2=80=9CDifferent components of a URI have differing practices recommended= .=E2=80=9D Passive voice, turn it around: =E2=80=9CBest practices differ depending on = the URI component=E2=80=9D, or some such. * 3. I think you could just subtract this whole section and not much would be lost. I think you=E2=80=99re trying to hint at HATEOS without actually nami= ng it. In particular, I find the second paragraph entirely baffling, and have no idea what it=E2=80=99s trying to say. --001a11c1e7fc684ad404ecd7aa03 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think this should be published as a Best Common Practice= soon as possible.

Minor issues:

* The title and introduction:=C2=A0

=E2=80=9CSta= ndardising Structure in URIs=E2=80=9C is unfortunate because the central me= ssage is =E2=80=9CDon=E2=80=99t try to standardize structure in URIs=E2=80= =9D. How about =E2=80=9CPreserving URI Space Design Freedom=E2=80=9D or =E2= =80=9CURI Structure Design Considered Harmful=E2=80=9D or =E2=80=9CURI Spac= e Design Ownership=E2=80=9D - I think that last one is a serious suggestion= .

: This document cautions against this practice in = standards (sometimes called "URI Squatting").
I=E2=80=99m not sure the =E2=80=9Csometimes called=E2=80=9D par= enthetical really adds value, but if preserved, it should be moved to immed= iately after =E2=80=9Cthis practice=E2=80=9D. Also, the document doesn=E2= =80=99t caution against it, it bristles with MUST NOTs. =C2=A0How about =E2= =80=9CThis document is intended to prevent the use of this practice (someti= mes called "URI Squatting") in standards.=E2=80=9D

* 1. Introduction

The bullet p= oint beginning =E2=80=9CDilution=E2=80=9D is grammatically strained. =C2=A0= The =E2=80=9Cextra information=E2=80=9D is the subject of both verbs, so tu= rn it around to read something like =E2=80=9CExtra information, added to UR= Is to support standardization, dilutes their usefulness as ..., and causes = alternate forms of the URI to exist. =C2=A0And I=E2=80=99m not sure Dilutio= n is the right label; the key point is weakening the URI=E2=80=99s utility = as an identifier. Having said that I can=E2=80=99t think of a one-word alte= rnative.

In that list of bullet points, you might also want to a= dd that query parameters are problematic for two more reasons: There=E2=80= =99s not a good hook in 3986 to use to say what you=E2=80=99re talking abou= t, and also you=E2=80=99re doing a parameter-name land-grab, which means yo= u now have another design problem, you have to prefix or otherwise clutter = your parameter names to in effect create a namespace for them. =C2=A0Or wor= se, don=E2=80=99t.

2nd-last para: =C2=A0The phrase that begins =E2=80=9Cpu= blishing standards that mandate URI structure is inappropriate... =E2=80=9D= is the central tl;dr of this whole draft, very nicely crystallized. Could = it be pulled out and featured in the introduction or even abstract?

* 2.

=E2=80=9CDifferent compon= ents of a URI have differing practices recommended.=E2=80=9D Passive voice,= turn it around: =E2=80=9CBest practices differ depending on the URI compon= ent=E2=80=9D, or some such.

* 3.

I think you could just su= btract this whole section and not much would be lost. I think you=E2=80=99r= e trying to hint at HATEOS without actually naming it. =C2=A0In particular,= I find the second paragraph entirely baffling, and have no idea what it=E2= =80=99s trying to say.





--001a11c1e7fc684ad404ecd7aa03-- From jan.algermissen@nordsc.com Thu Dec 5 23:43:13 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA4A81A1F71 for ; Thu, 5 Dec 2013 23:43:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.348 X-Spam-Level: X-Spam-Status: No, score=0.348 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id noL7nZA1jt9b for ; Thu, 5 Dec 2013 23:43:12 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by ietfa.amsl.com (Postfix) with ESMTP id 2C0901A1F5F for ; Thu, 5 Dec 2013 23:43:12 -0800 (PST) Received: from [192.168.2.103] (p548F81EB.dip0.t-ipconnect.de [84.143.129.235]) by mrelayeu.kundenserver.de (node=mreu3) with ESMTP (Nemesis) id 0La6Qc-1VAbVE39m2-00luir; Fri, 06 Dec 2013 08:43:07 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jan Algermissen In-Reply-To: Date: Fri, 6 Dec 2013 08:43:05 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2BB959D2-9D49-49AC-9A3A-A24A7796E3A2@nordsc.com> References: To: Tim Bray X-Mailer: Apple Mail (2.1510) X-Provags-ID: V02:K0:NB/FymvGAiic/lFgFFskD5j7SIPyY4uuMdmTW8xMARb vtI716SZ80DzCIfJmf6wDNOOK6NX8POVz/B6h0KFBQd23U46NU 28mUPpXfjh4MnZ4F+MY2ivWt8aTrRNcxHZh2hq/vd3jbiPjG8+ 3d8dqgWDa5227jy3kiLnIHG3rNcWfOv7YofKUHdDJal/iX0UFI BVa7heGx0/kI7dbARN8JY5pTUi0q5arJ3U1w2+7ipkmmQcoAW9 1dVnnhR8sdwekPTTYH1M8DtkH7xaz8RweIjTeWFHsVw8km0e4+ UtEQrnauIqhbFn+2qC8/PnRIq2JHFFkSRY6pwYvhzn0iadBoR2 N9voMYtNik2YZS7/K3gHyOsrA89TgnJNbWzcDge2HcNHdi3S9x Jlchy/urImGkA== Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Review of draft-ietf-appsawg-uri-get-off-my-lawn X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 07:43:13 -0000 On 06.12.2013, at 07:22, Tim Bray wrote: >=20 > * 3. >=20 > I think you could just subtract this whole section and not much would = be lost. I think you=92re trying to hint at HATEOS without actually = naming it. In particular, I find the second paragraph entirely = baffling, and have no idea what it=92s trying to say. I (think) Mark is referring to using something like JSON-Home[1] to have = clients discover URIs at runtime. Jan [1] http://tools.ietf.org/html/draft-nottingham-json-home-03 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From ietfc@btconnect.com Fri Dec 6 01:40:27 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 133D11AE307 for ; Fri, 6 Dec 2013 01:40:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.151 X-Spam-Level: X-Spam-Status: No, score=-3.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gQ0WctGE4SGd for ; Fri, 6 Dec 2013 01:40:23 -0800 (PST) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe001.messaging.microsoft.com [207.46.163.24]) by ietfa.amsl.com (Postfix) with ESMTP id B3D581AD72A for ; Fri, 6 Dec 2013 01:40:23 -0800 (PST) Received: from mail61-co9-R.bigfish.com (10.236.132.243) by CO9EHSOBE036.bigfish.com (10.236.130.99) with Microsoft SMTP Server id 14.1.225.22; Fri, 6 Dec 2013 09:40:19 +0000 Received: from mail61-co9 (localhost [127.0.0.1]) by mail61-co9-R.bigfish.com (Postfix) with ESMTP id CFA2FA017B; Fri, 6 Dec 2013 09:40:19 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.249.213; KIP:(null); UIP:(null); IPV:NLI; H:AM2PRD0710HT002.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -13 X-BigFish: PS-13(zzbb2dI98dI9371I542I1432Idbf2izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h20f7h2189h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah8275bh8275dh1de097h186068h1d68deh18f31ejz2dh2a8h5a9h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah2222h224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h2218h2216h226dh22d0h2327h2336h304l1d11m1155h) X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(24454002)(479174003)(189002)(199002)(377454003)(51704005)(13464003)(85306002)(15975445006)(31966008)(49866001)(47736001)(50226001)(74662001)(80976001)(47446002)(74502001)(87286001)(87266001)(51856001)(19580395003)(76482001)(19580405001)(83322001)(87976001)(23756003)(83072001)(74876001)(47976001)(44736004)(50986001)(84392001)(88136002)(4396001)(19273905006)(77982001)(59766001)(81342001)(77096001)(61296002)(77156001)(50466002)(15202345003)(66066001)(14496001)(62966002)(80022001)(65816001)(53806001)(74366001)(74706001)(76796001)(42186004)(85852002)(46102001)(90146001)(56816005)(47776003)(54316002)(33646001)(76786001)(81542001)(56776001)(69226001)(79102001)(62236002)(44716002)(63696002)(89996001)(74416001)(7726001)(16351025005)(563064011); DIR:OUT; SFP:; SCL:1; SRVR:DB3PR07MB060; H:DBXPRD0210HT005.eurprd02.prod.outlook.com; CLIP:157.56.253.181; FPR:; RD:InfoNoRecords; MX:1; A:0; LANG:en; Received: from mail61-co9 (localhost.localdomain [127.0.0.1]) by mail61-co9 (MessageSwitch) id 1386322817552566_8174; Fri, 6 Dec 2013 09:40:17 +0000 (UTC) Received: from CO9EHSMHS023.bigfish.com (unknown [10.236.132.237]) by mail61-co9.bigfish.com (Postfix) with ESMTP id 82C6A700071; Fri, 6 Dec 2013 09:40:17 +0000 (UTC) Received: from AM2PRD0710HT002.eurprd07.prod.outlook.com (157.56.249.213) by CO9EHSMHS023.bigfish.com (10.236.130.33) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 6 Dec 2013 09:40:17 +0000 Received: from DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) by AM2PRD0710HT002.eurprd07.prod.outlook.com (10.255.165.37) with Microsoft SMTP Server (TLS) id 14.16.383.1; Fri, 6 Dec 2013 09:40:02 +0000 Received: from DBXPRD0210HT005.eurprd02.prod.outlook.com (157.56.253.181) by DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) with Microsoft SMTP Server (TLS) id 15.0.837.10; Fri, 6 Dec 2013 09:40:00 +0000 Message-ID: <002801cef266$b35681a0$4001a8c0@gateway.2wire.net> From: t.petch To: Claudio Allocchio , Ira McDonald References: Date: Thu, 5 Dec 2013 18:05:44 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.253.181] X-ClientProxiedBy: AM3PR07CA005.eurprd07.prod.outlook.com (10.242.16.45) To DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) X-Forefront-PRVS: 0052308DC6 X-OriginatorOrg: btconnect.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: apps-discuss Subject: Re: [apps-discuss] [IETF procedure question] AppsDir review of draft-mcdonald-ldap-printer-schema-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 09:40:27 -0000 ----- Original Message ----- From: "Claudio Allocchio" To: "Ira McDonald" Cc: "Pat Fleming" ; Sent: Tuesday, November 26, 2013 5:05 PM > > On Tue, 26 Nov 2013, Ira McDonald wrote: > > > Hi Alexey, > > > > I'm confused about current IETF procedures. > > > > You requested that I should NOT post a new draft until directed to do so > > by my document shepherd or AD. > > > > But, according to the IETF datatracker there is NO assigned document > > shepherd or AD for this document: > > > > http://datatracker.ietf.org/doc/draft-mcdonald-ldap-printer-schema/ > > > > And the same holds true for the closely related IPPS URI Scheme draft: > > > > http://datatracker.ietf.org/doc/draft-mcdonald-ipps-uri-scheme/ > > > > How do I get a responsible AD or document shepherd assigned to these > > documents? > > Ira, > > that's because the whole Datatracker was designed to describe "reviews" > being performed when the IETF Last Call is issued by the IESG, and as such > "there is a Shepard and AD". > > but lately we started the "Early Review" experiment, when WG chairs can > request reviews even before the LC is out, to make easier and more > efficient the process. > > Alexey (but I made the same slight mistake!) used a template form which is > for the traditional "in LC period" reviews... also because we do not have > one (yet) for the Early Review ones... > > ... yes something to fix into the documentation! Indeed, and being engineers, we can cope with things like that. Meanwhile, I hope that there will be an AD for these two I-Ds. I would like them to progress, bringing RFC2910, RFC2911 up-to-date, and presume that that would be as an individual submission, which then needs an AD. I am willing to review them (although my expertise in printing is more user than implementor). Tom Petch > Cheers, > > - Ira > > Ira McDonald (Musician / Software Architect) > > Co-Chair - TCG Trusted Mobility Solutions WG > > Chair - Linux Foundation Open Printing WG > > Secretary - IEEE-ISTO Printer Working Group > > Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG > > IETF Designated Expert - IPP & Printer MIB > > Blue Roof Music / High North Inc > > http://sites.google.com/site/blueroofmusic > > http://sites.google.com/site/highnorthinc > > mailto: blueroofmusic@gmail.com > > Winter 579 Park Place Saline, MI 48176 734-944-0094 > > Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 > > On Fri, Nov 22, 2013 at 1:14 PM, Ira McDonald wrote: > > > >> Hi Alexey, > >> > >> Thanks for you excellent comments! My apologies for not acknowledging > >> them sooner. > >> > >> I need to think about resolutions and discuss w/ the IEEE-ISTO PWG > >> Internet Printing > >> Protocol WG, so I'll be a week or so responding yet (our next meeting is 2 > >> December). > >> > >> Cheers, > >> - Ira (co-editor of LDAP Printer Schema, co-chair of PWG IPP WG) > >> > >> > >> Ira McDonald (Musician / Software Architect) > >> Co-Chair - TCG Trusted Mobility Solutions WG > >> Chair - Linux Foundation Open Printing WG > >> Secretary - IEEE-ISTO Printer Working Group > >> Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG > >> IETF Designated Expert - IPP & Printer MIB > >> Blue Roof Music / High North Inc > >> http://sites.google.com/site/blueroofmusic > >> http://sites.google.com/site/highnorthinc > >> mailto: blueroofmusic@gmail.com > >> Winter 579 Park Place Saline, MI 48176 734-944-0094 > >> Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 > >> > >> > >> > >> On Mon, Nov 18, 2013 at 10:37 AM, Alexey Melnikov < > >> alexey.melnikov@isode.com> wrote: > >> > >>> On 19/09/2013 17:34, Ira McDonald wrote: > >>> > >>>> 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) > >>>> > >>> > >>> My apologies for belated review. I hope you find them useful. > >>> > >>> ----------------------------------------- > >>> > >>> 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/ApplicationsAreaDirectorat e). > >>> > >>> Please resolve these comments along with any other Last Call comments you > >>> may receive. Please wait for direction from your document shepherd or AD > >>> before posting a new version of the draft. > >>> > >>> Document: draft-mcdonald-ldap-printer-schema-05.txt > >>> Title: Lightweight Directory Access Protocol (LDAP): Schema for Printer > >>> Services > >>> Reviewer: Alexey Melnikov > >>> Review Date: November 18, 2013 > >>> IETF Last Call Date: N/A > >>> > >>> Summary: This draft is nearly reading for publication. > >>> > >>> This document defines a schema, object classes and attributes, for > >>> Printers and Print Services, for use with directories that support > >>> Lightweight Directory Access Protocol (RFC 4510). This document is > >>> based on the Printer attributes listed in Appendix E of Internet > >>> Printing Protocol/1.1 (IPP) (RFC 2911). Additional Printer > >>> attributes are based on definitions in the Printer MIB v2 (RFC 3805), > >>> IEEE-ISTO PWG Command Set for IEEE 1284 Device ID (PWG 5107.2), > >>> IEEE-ISTO PWG IPP Job and Printer Extensions - Set 3 (PWG 5100.13), > >>> and IEEE-ISTO PWG IPP Everywhere (PWG 5100.14). > >>> > >>> This document is published by the IETF on behalf of the Internet > >>> Printing Protocol Working Group of the IEEE-ISTO Printer Working > >>> Group. > >>> > >>> > >>> Most of the issues I found are minor. In general the document is quite > >>> readable. > >>> > >>> General comments: > >>> > >>> I noticed that you redifined various syntaxes to have upper limits on > >>> Directory strings. URI and Language Tags have no upper limits. I suspect > >>> that limits that you added are going to be sufficient in most cases, but it > >>> would be better for your document to call these out explicitly in text. > >>> > >>> > >>> In Section 1: > >>> > >>> This document updates RFC 3712. > >>> > >>> But the draft header says that it Obsoletes it. I think Obsolete is > >>> correct, so the statement in Section 1 should be updated to match. > >>> > >>> > >>> In Section 3.3: > >>> > >>> Note: When extending other structural classes with auxiliary > >>>> classes, printerService SHOULD not be used. > >>>> > >>> You should also capitalize "not" according to RFC 2119. There are > >>> multiple occurrences of the same problem in multiple places in the document. > >>> > >>> > >>> 3.4. printerServiceAuxClass > >>>> ( 1.3.18.0.2.6.257 > >>>> NAME 'printerServiceAuxClass' > >>>> DESC 'Printer information.' > >>>> > >>>> Fleming, McDonald Expires 19 March 2014 [Page 11] > >>>> > >>>> Internet-Draft LDAP Schema for Printer Services 19 September 2013 > >>>> > >>>> AUXILIARY > >>>> SUP printerAbstract > >>>> MAY ( printer-uri $ > >>>> printer-xri-supported ) > >>>> ) > >>>> This auxiliary class defines Printer information. It is derived > >>>> from > >>>> class printerAbstract and thus inherits common Printer attributes. > >>>> This class SHOULD be used with a structural class. > >>>> > >>> Each directory entry requires a structural object class, so I think this > >>> SHOULD is misleading. Also, why is this not a MUST? > >>> I suggest you just delete this sentence or reword it to make it non > >>> normative (and point to the document which makes the authoritative > >>> statement on this matter.) > >>> > >>> > >>> Similar text in 3.5 and 3.6. > >>> > >>> 4. Definition of Attribute Types > >>>> > >>>> The following attribute types reference matching rule names (instead > >>>> of OIDs) for clarity (see Section 6 below). For optional attributes, > >>>> if the Printer information is not known, the attribute value SHOULD > >>>> not be set. In the following definitions, referenced matching rules > >>>> are defined in Section 4 of [RFC4517] (see Section 6 'Definition of > >>>> Matching Rules' below). > >>>> > >>> > >>> I think you still meant section 4. > >>> > >>> Note: For interoperability and consistent text display, values of > >>>> attributes defined in this document: (a) SHOULD be normalized as > >>>> recommended in Unicode Format for Network Interchange [RFC5198]; (b) > >>>> SHOULD not contain DEL or any C0 or C1 control characters except for > >>>> > >>> "SHOULD not" --> "SHOULD NOT" > >>> > >>>> HT, CR, and LF; (c) SHOULD only contain CR and LF characters together > >>>> (not as singletons); and SHOULD NOT contain HT, CR, or LF characters > >>>> in names, e.g., printer-name and printer-aliases. > >>>> > >>> > >>> In 4.1: > >>> > >>> Note: LDAP application clients SHOULD not attempt to use malformed > >>>> URI values read from this attribute. LDAP administrative clients > >>>> SHOULD not write malformed URI values into this attribute. > >>>> > >>> "SHOULD not" --> "SHOULD NOT" (twice) > >>> > >>> > >>> In 4.4: > >>> > >>> Values of language tags SHOULD conform to Tags for Identifying > >>>> Languages [BCP47]. > >>>> > >>> Why is this a SHOULD and not a MUST? I.e. what are possible reason to put > >>> anything not specified in BCP47 here? > >>> > >>> > >>> 4.12. printer-charset-supported > >>>> ( 1.3.18.0.2.4.1131 > >>>> NAME 'printer-charset-supported' > >>>> DESC 'One of the charsets supported for the attribute values of > >>>> syntax DirectoryString for this directory entry.' > >>>> > >>> I don't understand this description. DirectoryString is always in UTF-8. > >>> > >>> How is this LDAP attribute being used? > >>> > >>>> EQUALITY caseIgnoreMatch > >>>> SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{255} > >>>> ) > >>>> > >>> > >>> 4.13. printer-generated-natural-language-supported > >>>> ( 1.3.18.0.2.4.1137 > >>>> NAME 'printer-generated-natural-language-supported' > >>>> DESC 'One of the natural languages supported for this directory > >>>> entry.' > >>>> > >>> Again, I am not entirely sure how this is used. Can you clarify? > >>> > >>> 4.20. printer-number-up-supported > >>>> ( 1.3.18.0.2.4.1124 > >>>> NAME 'printer-number-up-supported' > >>>> DESC 'Maximum number of print-stream pages that can be imposed upon a > >>>> single side of an instance of selected medium by this Printer.' > >>>> EQUALITY integerMatch > >>>> ORDERING integerOrderingMatch > >>>> SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 > >>>> ) > >>>> > >>> This is not defined as single-valued. What is the meaning of multiple > >>> values? > >>> > >>> 4.35. printer-device-id > >>>> ( 1.3.18.0.2.24.46.1.101 > >>>> NAME 'printer-device-id' > >>>> DESC 'The IEEE 1284 Device ID for this Printer.' > >>>> EQUALITY caseIgnoreMatch > >>>> SUBSTR caseIgnoreSubstringsMatch > >>>> SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{255} > >>>> ) > >>>> Values of this attribute SHOULD conform to IEEE-ISTO PWG Command > >>>> Set > >>>> Format for IEEE 1284 Device ID [PWG5107.2]. > >>>> Note: For interoperatibility, values of this attribute SHOULD > >>>> include key/value pairs in the following order: (a) all required > >>>> key/value pairs (i.e., MANUFACTURER/MFG, MODEL/MDL, and COMMAND > >>>> SET/CMD); (b) all optional key/value pairs; and (c) all vendor > >>>> key/value pairs. > >>>> > >>> How does the advice on ordering interacts with multiple values of the > >>> attribute? LDAP multivalued attributes have no ordering of values. > >>> > >>> printer-device-id 1.3.18.0.2.24.46.1.101 > >>> printer-device-service-count 1.3.18.0.2.24.46.1.102 > >>> printer-uuid 1.3.18.0.2.24.46.1.104 > >>> printer-charge-info 1.3.18.0.2.24.46.1.105 > >>> printer-charge-info-uri 1.3.18.0.2.24.46.1.106 > >>> printer-geo-location 1.3.18.0.2.24.46.1.107 > >>> printer-ipp-features-supported 1.3.18.0.2.24.46.1.108 > >>> > >>> This is not necessarily a problem, but I couldn't find a registration for > >>> the 1.3.18.0.2.24 OID. The parent OID is owned by IBM. > >>> > >>> > >>> 13. Appendix X - Change History > >>> > >>> [ [RFC Editor: This section to be deleted before RFC publication] ] > >>> > >>> -bis document are required to include "Changes since RFC XXXX" section. > >>> So you should replace this Appendix with another one that details changes > >>> since RFC 3712. > >>> > >>> Best Regards, > >>> Alexey > >>> > >>> > >> > > > > ---------------------------------------------------------------------- -------- > 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 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > From ht@inf.ed.ac.uk Fri Dec 6 03:03:53 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A6F21ADE7C for ; Fri, 6 Dec 2013 03:03:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18b3H5Cq38Mc for ; Fri, 6 Dec 2013 03:03:50 -0800 (PST) Received: from treacle.ucs.ed.ac.uk (treacle.ucs.ed.ac.uk [129.215.16.102]) by ietfa.amsl.com (Postfix) with ESMTP id 7A51C1ADBF7 for ; Fri, 6 Dec 2013 03:03:49 -0800 (PST) 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 rB6B1Rlr003259; Fri, 6 Dec 2013 11:01:27 GMT 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 rB6B1PPh014854; Fri, 6 Dec 2013 11:01:25 GMT 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 rB6B1Qku018619; Fri, 6 Dec 2013 11:01:26 GMT Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id rB6B1Pk4018615; Fri, 6 Dec 2013 11:01:25 GMT X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f To: ietf-charsets@iana.org, www-international@w3.org, unicode@unicode.org From: ht@inf.ed.ac.uk (Henry S. Thompson) Date: Fri, 06 Dec 2013 11:01:25 +0000 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 Cc: apps-discuss@ietf.org Subject: [apps-discuss] Request for review: 3023bis (XML media types) makes significant changes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 11:03:53 -0000 I'm one of the editors of a proposed replacement for RFC3023 [1], the media type registration for application/xml, text/xml and 3 others. The draft replacement [2] includes several significant changes in the handling of information about character encoding: * In cases where conflicting information is supplied (from charset param, BOM and/or XML encoding declaration) it give a BOM, if present, authoritative status; * It recommends against the use of UTF-32. The interoperability situation in this space is currently poor, with some tools treating a charset parameter as authoritative, but the HTML 5 spec and most browsers preferring the BOM. The goal of the draft is to specify an approach which will promote convergence, while minimising the risk of damage from backward incompatibilities. Since these changes overlap with a wide range of technologies, I'm seeking review from the wider community, as represented by the above address list -- please take a look if you can, particularly at Section 3 [3] and Appendix C [4]. Thanks, ht [1] http://tools.ietf.org/html/rfc3023 [2] http://tools.ietf.org/html/draft-ietf-appsawg-xml-mediatypes-06 [3] http://tools.ietf.org/html/draft-ietf-appsawg-xml-mediatypes-06#section-3 [4] http://tools.ietf.org/html/draft-ietf-appsawg-xml-mediatypes-06#appendix-C -- 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 Claudio.Allocchio@garr.it Fri Dec 6 03:13:29 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C39121AE33C; Fri, 6 Dec 2013 03:13:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.122 X-Spam-Level: X-Spam-Status: No, score=-0.122 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eS2Ihd8KUhkG; Fri, 6 Dec 2013 03:13:28 -0800 (PST) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [193.206.158.29]) by ietfa.amsl.com (Postfix) with ESMTP id 6BCE21AE336; Fri, 6 Dec 2013 03:13:28 -0800 (PST) Received: internal info suppressed Date: Fri, 6 Dec 2013 12:13:20 +0100 (CET) From: Claudio Allocchio X-X-Sender: claudio@synx02.dir.garr.it To: "t.petch" In-Reply-To: <002801cef266$b35681a0$4001a8c0@gateway.2wire.net> Message-ID: References: <002801cef266$b35681a0$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=1386328402; bh=GkuWf+h0Uxuy6vYTzaIC9Bd01Q8p4Dz2ri7Yg6v2xwA=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=XgLAgtoHzHRRnhnKS3io0a6jHP0+UOcrTZz2vbeKGjhMbmoPMfTSaInZoU73+nBBm cLsIe6YZXJvosW+d9FmR+RQOwfkOs7HP8UFAl41sgLNZnXJxe84f/9yhYQ6WLX3qwN R03yQs0LHNNc4P8O1EH1cqwvX2D6Cd4cKP1csK7Q= Cc: appsdir@ietf.org, apps-discuss Subject: [apps-discuss] templates for early review and documentation update X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 11:13:30 -0000 >> Alexey (but I made the same slight mistake!) used a template form > which is >> for the traditional "in LC period" reviews... also because we do not > have >> one (yet) for the Early Review ones... >> >> ... yes something to fix into the documentation! > > Indeed, and being engineers, we can cope with things like that. Just to say that I fixed it also in the documentation now: http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate http://trac.tools.ietf.org/area/app/trac/wiki/template comments are welcome! ------------------------------------------------------------------------------ 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 melvincarvalho@gmail.com Fri Dec 6 06:22:28 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F1E31AE3AA for ; Fri, 6 Dec 2013 06:22:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qqCFs14pH01F for ; Fri, 6 Dec 2013 06:22:26 -0800 (PST) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 78B7C1ADFF3 for ; Fri, 6 Dec 2013 06:22:26 -0800 (PST) Received: by mail-ie0-f173.google.com with SMTP id to1so1282919ieb.4 for ; Fri, 06 Dec 2013 06:22:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Eb6YqeUSSCSOOgOFQTKNHbQczwvQbJ7eYzKOSF2Lbao=; b=aoBrdgyoxbNv2VnR+ITpRaSj8G1b+KuI5ed/2M8OEz5rOvOkbywwgFdkLKmPDN469J 0t3DgZ3uSag4EggV8fzX7VdSaq4RpcpZG/zoMjMa4LFZH+ofbVeL4skru7SPBWbLu0+3 GfiozUgEH58pd7CDIRMq92M6K9bxOxN6xYWmunKx0mWZ33p++Sj2FUaywOweP7GA+I8U 7Jhkw8XmMfzb9e+/6GSaMmCMdbqb4EnwwAVvS2t46AlT+iW71oy+bFxYjiuYWxWpBXXV pjvos/k00nI0pOipmJLKCYvmmf2A3WEOZ2Bc6Po1njgcNeFAwWl8ElLcPSt/7Eex6Y8H mzWQ== MIME-Version: 1.0 X-Received: by 10.50.98.10 with SMTP id ee10mr2915152igb.30.1386339742708; Fri, 06 Dec 2013 06:22:22 -0800 (PST) Received: by 10.64.17.167 with HTTP; Fri, 6 Dec 2013 06:22:22 -0800 (PST) In-Reply-To: <529C6DA2.8010000@gmx.de> References: <529C6DA2.8010000@gmx.de> Date: Fri, 6 Dec 2013 15:22:22 +0100 Message-ID: From: Melvin Carvalho To: Julian Reschke Content-Type: multipart/alternative; boundary=047d7b2e10d3e7145004ecde5f8a Cc: Apps Discuss Subject: Re: [apps-discuss] well-known location for uuids X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 14:22:28 -0000 --047d7b2e10d3e7145004ecde5f8a Content-Type: text/plain; charset=ISO-8859-1 On 2 December 2013 12:23, Julian Reschke wrote: > On 2013-12-02 12:15, Melvin Carvalho wrote: > >> Looking at >> >> http://www.iana.org/assignments/well-known-uris/well-known-uris.xml >> >> There seems to be a well known location for named instances (hashes) ni >> >> And also skolemized bnodes : genid >> >> Would it be a good idea to have one for uuids, do you think? >> >> Currently there is urn:uuid: as a URN but not simple way to translate >> this to a URL >> >> Could we maybe just add /.well-known/uuid/ ? >> >> Thoughts? >> > > What's the advantage of the urn:uuid notation? Do you plan to resolve it > to a resource? > I like to give every identifier a URI if possible. I guessed from the wikipedia urn aricle urn:uuid was a of the standard ways of doing this? http://en.wikipedia.org/wiki/Uniform_resource_name (See under examples) As a background I'm writing a distributed task manager which I'd like to give each task a unique identifier (e.g. UUID) but I dont necessarily want to make it domain specific. Ideally I'd like the tasks to be dereferancable, so my thought was that one option could be a UUID. So I'm trying to work out what notation represented good practice? > > Best regards, Julian > > --047d7b2e10d3e7145004ecde5f8a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On 2 December 2013 12:23, Julian Reschke <julian.reschke@gmx.d= e> wrote:
On 2013-12-02 12:15, Melvin Carvalho wrote:
Looking at

http://www.iana.org/assignments/well-known-ur= is/well-known-uris.xml

There seems to be a well known location for named instances (hashes) ni

And also skolemized bnodes : genid

Would it be a good idea to have one for uuids, do you think?

Currently there is urn:uuid: as a URN but not simple way to translate
this to a URL

Could we maybe just add /.well-known/uuid/ =A0?

Thoughts?

What's the advantage of the urn:uuid notation? Do you plan to resolve i= t to a resource?

I like to give every i= dentifier a URI if possible.=A0 I guessed from the wikipedia urn aricle urn= :uuid was a of the standard ways of doing this?

http://e= n.wikipedia.org/wiki/Uniform_resource_name

(See under= examples)

As a background I'm writing a distributed = task manager which I'd like to give each task a unique identifier (e.g.= UUID) but I dont necessarily want to make it domain specific.

Ideally I'd like the tasks to be dereferancable, so my t= hought was that one option could be a UUID.=A0

So I'm trying to= work out what notation represented good practice?
=A0

Best regards, Julian


--047d7b2e10d3e7145004ecde5f8a-- From vkg@bell-labs.com Fri Dec 6 06:38:11 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40E811ADF10; Fri, 6 Dec 2013 06:38:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Otj6HHdXdwjJ; Fri, 6 Dec 2013 06:38:09 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 20B211AD83F; Fri, 6 Dec 2013 06:38:09 -0800 (PST) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id rB6Ec32K028463 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 6 Dec 2013 08:38:04 -0600 (CST) Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id rB6Ec2Et001518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 6 Dec 2013 08:38:03 -0600 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 rB6Ec1d8000583; Fri, 6 Dec 2013 08:38:02 -0600 (CST) Message-ID: <52A1E155.5020206@bell-labs.com> Date: Fri, 06 Dec 2013 08:38:13 -0600 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: draft-ietf-payload-rtp-aptx.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.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: IESG IESG , "apps-discuss@ietf.org" Subject: [apps-discuss] APPSDIR review of draft-ietf-payload-rtp-aptx-04 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 14:38:11 -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-payload-rtp-aptx-04 Title: RTP Payload Format for Standard apt-X and Enhanced apt-X Codecs Reviewer: Vijay K. Gurbani Review Date: Dec-06-2013 IETF Last Call Date: Dec-06-2013 IESG Telechat Date: Not known Summary: This draft is ready for publication as a Proposed Standard. Major: 0 Minor: 0 Nits: 0 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 Fri Dec 6 09:41:05 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2ED91AE0FA for ; Fri, 6 Dec 2013 09:41:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jt-J32zJoBcG for ; Fri, 6 Dec 2013 09:41:04 -0800 (PST) Received: from cm06fe.IST.Berkeley.EDU (cm06fe.IST.Berkeley.EDU [169.229.218.147]) by ietfa.amsl.com (Postfix) with ESMTP id 13E401AE0CF for ; Fri, 6 Dec 2013 09:41:03 -0800 (PST) Received: from c-24-6-239-29.hsd1.ca.comcast.net ([24.6.239.29] helo=dretpro.local) by cm06fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from ) id 1VozOc-0001eg-Lc for apps-discuss@ietf.org; Fri, 06 Dec 2013 09:40:59 -0800 Message-ID: <52A20C27.1050401@berkeley.edu> Date: Fri, 06 Dec 2013 09:40:55 -0800 From: Erik Wilde User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "apps-discuss@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [apps-discuss] Review of draft-ietf-appsawg-uri-get-off-my-lawn X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 17:41:05 -0000 hello all. On 2013-12-05, 22:22 , Tim Bray wrote: > * The title and introduction: > “Standardising Structure in URIs“ is unfortunate because the central > message is “Don’t try to standardize structure in URIs”. How about > “Preserving URI Space Design Freedom” or “URI Structure Design > Considered Harmful” or “URI Space Design Ownership” - I think that last > one is a serious suggestion. reading this, there's another issue that i regularly run into in various designs, which might be useful to mention in the document: it's the question of whether a URI used in some representation is meant as an identifier only, or as a retrievable resource. XML namespace URIs are a very popular example. and then there's the famous example of the HTML DTD URI which until this day generates substantial amounts of pretty useless traffic, because software accesses it instead of just using it as an identifier. maybe it would be helpful to add a section saying that if a standard intends a URI to be an identifier only, it SHOULD clearly say so, and it SHOULD discourage clients from accessing it. clients SHOULD be encouraged to use comparison (as opposed to access) as the only meaningful operation for these kinds of URIs. 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 franck@peachymango.org Fri Dec 6 10:29:45 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D82921AE0E1 for ; Fri, 6 Dec 2013 10:29:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s4yy9RO79RhD for ; Fri, 6 Dec 2013 10:29:43 -0800 (PST) Received: from smtp.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id C5C701AE06F for ; Fri, 6 Dec 2013 10:29:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id A0C554F422E; Fri, 6 Dec 2013 12:29:38 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WlhQODkI9PmU; Fri, 6 Dec 2013 12:29:38 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 7D8BF4F40BF; Fri, 6 Dec 2013 12:29:38 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 6783D4F422E; Fri, 6 Dec 2013 12:29:38 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id CO2X3GgqL22W; Fri, 6 Dec 2013 12:29:38 -0600 (CST) Received: from mail-2.01.com (mail.01.com [172.18.30.178]) by smtp-out-2.01.com (Postfix) with ESMTP id 4D9CD4F422C; Fri, 6 Dec 2013 12:29:38 -0600 (CST) Date: Fri, 6 Dec 2013 12:29:37 -0600 (CST) From: Franck Martin To: Dan Wing Message-ID: <1120917196.230494.1386354577665.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <83737770.209987.1386299547311.JavaMail.zimbra@peachymango.org> <8BBD1945-9AA0-42D5-85A2-D4B4639204E7@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [69.28.149.129] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF25 (Mac)/8.0.5_GA_5839) Thread-Topic: New Version Notification for draft-martin-smtp-target-host-selection-ipv4-ipv6-01.txt Thread-Index: 3rjdRLxD0sGmkLkmyaaB8rF0HQSZxg== Cc: IETF Apps Discuss Subject: Re: [apps-discuss] New Version Notification for draft-martin-smtp-target-host-selection-ipv4-ipv6-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 18:29:46 -0000 ----- Original Message ----- > From: "Dan Wing" > To: "Franck Martin" > Cc: "IETF Apps Discuss" > Sent: Thursday, December 5, 2013 10:04:02 PM > Subject: Re: [apps-discuss] New Version Notification for draft-martin-smtp-target-host-selection-ipv4-ipv6-01.txt > > ... In some ways, this strategy is similar to the > Happy Eveballs [RFC6555] strategy where web browsers initiate > parralel connections to web servers using IPv4 and IPv6 and select > the better connection. ... > > RFC6555 does not describe initiating parallel connections, reference > http://tools.ietf.org/html/rfc6555#section-5.5 http://tools.ietf.org/html/rfc6555#section-4 Indicates TCP SYN are initiated on IPv4 and IPv6 and the first one that answers with a ACK wins, while the other one get a RST... Then this information is cached. We are not doing the same with SMTP, because there is already a process with MX to round robin connections. We just need to remember what worked. > > > I think your I-D would be improved by providing guidance for how long to wait > for TCP connection itself. I see > http://tools.ietf.org/search/rfc5321#section-4.5.3.2.1 says 5 minutes for > the initial 220, but it is silent on the TCP connection timeout. A 5 minute > delay for IPv6 path brokenness makes for slow mail delivery, and can > convince many a system administrator to disable IPv6 to reduce user > complaints of slow delivery. > SMTP is not XMPP. Once a connection is established there is PIPELINING and still you can send more than one email in a connection, and MTAs usually keep connections open in case they get another email to send. I don't think it is the purpose of this document to modify deeply the way SMTP works. Already overriding the DNS TTL on the MX made me a bit uncomfortable. Remember also, the purpose of this document is to encourage the MTA to remember what path works best for most email destinations. I would also add if you claim to have IPv6 but cannot reach a lot of MXes on V6, then I think disabling IPv6 for mail till you get your network sorted out seems advisable. From paul.hoffman@vpnc.org Fri Dec 6 10:54:12 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D68AB1AE066 for ; Fri, 6 Dec 2013 10:54:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mCWsWS5O9G91 for ; Fri, 6 Dec 2013 10:54:12 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 1B1A41AE016 for ; Fri, 6 Dec 2013 10:54:11 -0800 (PST) Received: from [10.20.30.90] (50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id rB6Is3FY077569 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 6 Dec 2013 11:54:05 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-0-66-41.dsl.dynamic.sonic.net [50.0.66.41] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Paul Hoffman In-Reply-To: <52A20C27.1050401@berkeley.edu> Date: Fri, 6 Dec 2013 10:54:03 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7CEF0F2D-AB1B-461A-BC40-9EEB8D0DDAAA@vpnc.org> References: <52A20C27.1050401@berkeley.edu> To: Erik Wilde X-Mailer: Apple Mail (2.1822) Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Review of draft-ietf-appsawg-uri-get-off-my-lawn X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 18:54:13 -0000 On Dec 6, 2013, at 9:40 AM, Erik Wilde wrote: > reading this, there's another issue that i regularly run into in = various designs, which might be useful to mention in the document: it's = the question of whether a URI used in some representation is meant as an = identifier only, or as a retrievable resource. From julian.reschke@gmx.de Fri Dec 6 11:11:12 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD031AE0A0 for ; Fri, 6 Dec 2013 11:11:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vTrhZzzD4zam for ; Fri, 6 Dec 2013 11:11:10 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 8BEA21AE046 for ; Fri, 6 Dec 2013 11:11:10 -0800 (PST) Received: from [192.168.2.117] ([93.217.89.125]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LeMij-1VF7dE2qb7-00q9LP for ; Fri, 06 Dec 2013 20:11:05 +0100 Message-ID: <52A22147.4070100@gmx.de> Date: Fri, 06 Dec 2013 20:11:03 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Melvin Carvalho References: <529C6DA2.8010000@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:utFDrRCmd5J3/6P7Ofp+XMPo4dnRfcyMy1+P49ku3caATjg0M9s Q9JjdsC3FmHa5EDi+Uda33AmPdvLdK0PDMT0SIYJVStLcIWt8P5AND3LAFkVF07JEbt1udT ttHD1qnfZ+/WZRpl+oQM5nmhHuHmYGDMMRSkClAuvGXjIVslaXILR0x1EhKzz6XnpViBi8Y fnLMw/p0IxstXBdozvZ3A== Cc: Apps Discuss Subject: Re: [apps-discuss] well-known location for uuids X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 19:11:12 -0000 On 2013-12-06 15:22, Melvin Carvalho wrote: > > > > On 2 December 2013 12:23, Julian Reschke > wrote: > > On 2013-12-02 12:15, Melvin Carvalho wrote: > > Looking at > > http://www.iana.org/__assignments/well-known-uris/__well-known-uris.xml > > > There seems to be a well known location for named instances > (hashes) ni > > And also skolemized bnodes : genid > > Would it be a good idea to have one for uuids, do you think? > > Currently there is urn:uuid: as a URN but not simple way to > translate > this to a URL > > Could we maybe just add /.well-known/uuid/ ? > > Thoughts? > > > What's the advantage of the urn:uuid notation? Do you plan to > resolve it to a resource? > > > I like to give every identifier a URI if possible. I guessed from the > wikipedia urn aricle urn:uuid was a of the standard ways of doing this? > > http://en.wikipedia.org/wiki/Uniform_resource_name Well, a urn:uuid *is* a URI already. Best regards, Julian From martin.thomson@gmail.com Fri Dec 6 11:22:01 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 494451AE066 for ; Fri, 6 Dec 2013 11:22:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PiR7evbCjZTF for ; Fri, 6 Dec 2013 11:21:59 -0800 (PST) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id 60E101AD84D for ; Fri, 6 Dec 2013 11:21:59 -0800 (PST) Received: by mail-wg0-f52.google.com with SMTP id x13so1105303wgg.7 for ; Fri, 06 Dec 2013 11:21:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Z1V+vBbQxiLjBvRE5y88i67u5HF7FYBWEYKkGl0GI7g=; b=pHZtXWGm03oFMqaxiNb2pDNeNV4Tlt0uhW7ok1cniz8z0QNrPQ8Grk+L3uH41Dk87r GMzYWKTs3u0xwu9SYAWkDqoCwMJWCjbPPEFVzNRO8YaH+zVwFEgZ/9VUjDRE6zAkdqsN Vune8jUItVmhth8FvxB6HUxJCTgNYFkW1dxA67g4H0Ev06zjj5vQE9Aozqcf11HHu5Ti aDQGmvrvqzPG33cNI11quwih+FIr4iz9kGz8LPzNBDil45yWkVW3Iz38T3Wb9c/wWCZL HEJ9B1E/8JW51/RRl74lC10exW8Se2VqaQ5Igt3aNv7Ud7Hw1D6kVls7/t/pdybg2WOP ooHQ== MIME-Version: 1.0 X-Received: by 10.194.174.36 with SMTP id bp4mr4764909wjc.7.1386357714956; Fri, 06 Dec 2013 11:21:54 -0800 (PST) Received: by 10.227.134.195 with HTTP; Fri, 6 Dec 2013 11:21:54 -0800 (PST) In-Reply-To: <7CEF0F2D-AB1B-461A-BC40-9EEB8D0DDAAA@vpnc.org> References: <52A20C27.1050401@berkeley.edu> <7CEF0F2D-AB1B-461A-BC40-9EEB8D0DDAAA@vpnc.org> Date: Fri, 6 Dec 2013 11:21:54 -0800 Message-ID: From: Martin Thomson To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Review of draft-ietf-appsawg-uri-get-off-my-lawn X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 19:22:01 -0000 On 6 December 2013 10:54, Paul Hoffman wrote: > On Dec 6, 2013, at 9:40 AM, Erik Wilde wrote: > >> reading this, there's another issue that i regularly run into in various= designs, which might be useful to mention in the document: it's the questi= on of whether a URI used in some representation is meant as an identifier o= nly, or as a retrievable resource. > > I used to find this annoying, but I got over. In the realm of annoyances, this just doesn't rate that highly any more for me. That said, it is definitely an issue. My main concern is that I don't see how this fits into the draft in question. I'd in support of publishing that one liner for sure, but think perhaps it's inappropriate to throw more turnips on this particular donkey cart, just because it's headed in the right direction. From tbray@textuality.com Fri Dec 6 11:31:41 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 520661AE108 for ; Fri, 6 Dec 2013 11:31:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jAUkj8Nx_F5b for ; Fri, 6 Dec 2013 11:31:37 -0800 (PST) Received: from mail-vc0-f171.google.com (mail-vc0-f171.google.com [209.85.220.171]) by ietfa.amsl.com (Postfix) with ESMTP id D5EAE1AE0A0 for ; Fri, 6 Dec 2013 11:31:36 -0800 (PST) Received: by mail-vc0-f171.google.com with SMTP id ik5so1187422vcb.2 for ; Fri, 06 Dec 2013 11:31:32 -0800 (PST) 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=t28uWwTbdb6HohL9n9NXT2k4WoD9qfWNDTvTywEKv5I=; b=ZtPqcfKwSqhCDyOH8C2X0vy4d8v4cpS4HjI/Ps6drGD/jZKuFoOq4oAKFk+wZR0eun W/dfzgIUyEY2MJU1+jdwSP0ziyms4bcrxwrYU1IkmxBLkhyQY0aK58NI18Sjf0x1ywL/ SDo2YYyOgxBVYgcS+rg4JbuQvVKljnPCWWrdr/vNbKo0H/cWyk6zDc4V5cKT6062QU25 H3F2cCo72R/K1AuQ85ZPd91z5MLR+DiRHN98Zg/PUG7Y0/8LpnjujIk8KykI2mUvTm3+ Kb/Q/jUQp+CVPowhswOkIe7JPZvXfCb2LKGNhCXAsC6+O76Z+x5SNKOt0wtEtIgaijDS 8DqQ== X-Gm-Message-State: ALoCoQlTYw5vEhytS47v6sHjSUWHuf/lF7Zh6iFowKE3VtsqCqG+Yx9M+N8QLrqKUF3Na6BbpG5z MIME-Version: 1.0 X-Received: by 10.52.52.137 with SMTP id t9mr2402010vdo.22.1386358292705; Fri, 06 Dec 2013 11:31:32 -0800 (PST) Received: by 10.220.198.199 with HTTP; Fri, 6 Dec 2013 11:31:32 -0800 (PST) X-Originating-IP: [96.49.81.176] In-Reply-To: <52A20C27.1050401@berkeley.edu> References: <52A20C27.1050401@berkeley.edu> Date: Fri, 6 Dec 2013 11:31:32 -0800 Message-ID: From: Tim Bray To: Erik Wilde Content-Type: multipart/alternative; boundary=089e0122f65e91e46104ece2b181 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Review of draft-ietf-appsawg-uri-get-off-my-lawn X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Dec 2013 19:31:41 -0000 --089e0122f65e91e46104ece2b181 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable We could have a lot of arguments about this, but I think it=E2=80=99s ortho= gonal to the issue Mark is trying to address in an admirably tightly-focused way in the draft. On Fri, Dec 6, 2013 at 9:40 AM, Erik Wilde wrote: > hello all. > > > On 2013-12-05, 22:22 , Tim Bray wrote: > >> * The title and introduction: >> =E2=80=9CStandardising Structure in URIs=E2=80=9C is unfortunate because= the central >> message is =E2=80=9CDon=E2=80=99t try to standardize structure in URIs= =E2=80=9D. How about >> =E2=80=9CPreserving URI Space Design Freedom=E2=80=9D or =E2=80=9CURI St= ructure Design >> Considered Harmful=E2=80=9D or =E2=80=9CURI Space Design Ownership=E2=80= =9D - I think that last >> one is a serious suggestion. >> > > reading this, there's another issue that i regularly run into in various > designs, which might be useful to mention in the document: it's the > question of whether a URI used in some representation is meant as an > identifier only, or as a retrievable resource. > > XML namespace URIs are a very popular example. and then there's the famou= s > example of the HTML DTD URI which until this day generates substantial > amounts of pretty useless traffic, because software accesses it instead o= f > just using it as an identifier. > > maybe it would be helpful to add a section saying that if a standard > intends a URI to be an identifier only, it SHOULD clearly say so, and it > SHOULD discourage clients from accessing it. clients SHOULD be encouraged > to use comparison (as opposed to access) as the only meaningful operation > for these kinds of URIs. > > 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 | > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --089e0122f65e91e46104ece2b181 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We could have a lot of arguments about this, but I think i= t=E2=80=99s orthogonal to the issue Mark is trying to address in an admirab= ly tightly-focused way in the draft.

On Fri, Dec 6, 2013 at 9:40 AM, Erik Wilde <dret@berkeley.edu> wrote:
hello all.


On 2013-12-05, 22:22 , Tim Bray wrote:
* The title and introduction:
=E2=80=9CStandardising Structure in URIs=E2=80=9C is unfortunate because th= e central
message is =E2=80=9CDon=E2=80=99t try to standardize structure in URIs=E2= =80=9D. How about
=E2=80=9CPreserving URI Space Design Freedom=E2=80=9D or =E2=80=9CURI Struc= ture Design
Considered Harmful=E2=80=9D or =E2=80=9CURI Space Design Ownership=E2=80=9D= - I think that last
one is a serious suggestion.

reading this, there's another issue that i regularly run into in variou= s designs, which might be useful to mention in the document: it's the q= uestion of whether a URI used in some representation is meant as an identif= ier only, or as a retrievable resource.

XML namespace URIs are a very popular example. and then there's the fam= ous example of the HTML DTD URI which until this day generates substantial = amounts of pretty useless traffic, because software accesses it instead of = just using it as an identifier.

maybe it would be helpful to add a section saying that if a standard intend= s a URI to be an identifier only, it SHOULD clearly say so, and it SHOULD d= iscourage clients from accessing it. clients SHOULD be encouraged to use co= mparison (as opposed to access) as the only meaningful operation for these = kinds of URIs.

cheers,

dret.

--
erik wilde | mailto:= dret@berkeley.edu =C2=A0- =C2=A0tel:+1-510-2061079 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| UC Berkeley =C2=A0- =C2=A0School= of Information (ISchool) |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| http://dret.net/netdret http://twitter.com/dret |

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

--089e0122f65e91e46104ece2b181-- From mnot@mnot.net Fri Dec 6 21:40:10 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2218D1AE209 for ; Fri, 6 Dec 2013 21:40:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_22=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rOok5hbqVhGd for ; Fri, 6 Dec 2013 21:40:08 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 8711B1AE1EB for ; Fri, 6 Dec 2013 21:40:08 -0800 (PST) Received: from [192.168.1.57] (unknown [118.209.134.50]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 4DAD2509B8; Sat, 7 Dec 2013 00:40:00 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Mark Nottingham In-Reply-To: Date: Sat, 7 Dec 2013 16:39:56 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Tim Bray X-Mailer: Apple Mail (2.1822) Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] Review of draft-ietf-appsawg-uri-get-off-my-lawn X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2013 05:40:10 -0000 Thanks, Tim =97 all good feedback, will try to incorporate and come back = if I have issues. On 6 Dec 2013, at 5:22 pm, Tim Bray wrote: > I think this should be published as a Best Common Practice soon as = possible. >=20 > Minor issues: >=20 > * The title and introduction:=20 >=20 > =93Standardising Structure in URIs=93 is unfortunate because the = central message is =93Don=92t try to standardize structure in URIs=94. = How about =93Preserving URI Space Design Freedom=94 or =93URI Structure = Design Considered Harmful=94 or =93URI Space Design Ownership=94 - I = think that last one is a serious suggestion. >=20 > : This document cautions against this practice in standards (sometimes = called "URI Squatting"). >=20 > I=92m not sure the =93sometimes called=94 parenthetical really adds = value, but if preserved, it should be moved to immediately after =93this = practice=94. Also, the document doesn=92t caution against it, it = bristles with MUST NOTs. How about =93This document is intended to = prevent the use of this practice (sometimes called "URI Squatting") in = standards.=94 >=20 > * 1. Introduction >=20 > The bullet point beginning =93Dilution=94 is grammatically strained. = The =93extra information=94 is the subject of both verbs, so turn it = around to read something like =93Extra information, added to URIs to = support standardization, dilutes their usefulness as ..., and causes = alternate forms of the URI to exist. And I=92m not sure Dilution is the = right label; the key point is weakening the URI=92s utility as an = identifier. Having said that I can=92t think of a one-word alternative. >=20 > In that list of bullet points, you might also want to add that query = parameters are problematic for two more reasons: There=92s not a good = hook in 3986 to use to say what you=92re talking about, and also you=92re = doing a parameter-name land-grab, which means you now have another = design problem, you have to prefix or otherwise clutter your parameter = names to in effect create a namespace for them. Or worse, don=92t. >=20 > 2nd-last para: The phrase that begins =93publishing standards that = mandate URI structure is inappropriate... =94 is the central tl;dr of = this whole draft, very nicely crystallized. Could it be pulled out and = featured in the introduction or even abstract? >=20 > * 2. >=20 > =93Different components of a URI have differing practices = recommended.=94 Passive voice, turn it around: =93Best practices differ = depending on the URI component=94, or some such. >=20 > * 3. >=20 > I think you could just subtract this whole section and not much would = be lost. I think you=92re trying to hint at HATEOS without actually = naming it. In particular, I find the second paragraph entirely = baffling, and have no idea what it=92s trying to say. >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Mark Nottingham http://www.mnot.net/ From huangng@gmail.com Sat Dec 7 05:25:06 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF031AE2C7 for ; Sat, 7 Dec 2013 05:25:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id APWOP69TFYKf for ; Sat, 7 Dec 2013 05:25:04 -0800 (PST) Received: from mail-ve0-x233.google.com (mail-ve0-x233.google.com [IPv6:2607:f8b0:400c:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id C035E1ADF8D for ; Sat, 7 Dec 2013 05:25:03 -0800 (PST) Received: by mail-ve0-f179.google.com with SMTP id jw12so2038205veb.10 for ; Sat, 07 Dec 2013 05:24:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=ASp/02FK/Y01tJqxmJ5VYuKoCrhxpoPfZCkRO0dZvwo=; b=eybHWL9FbbvwU06Ez3GKAFKdRTQK4w2jX3zSFyM5tMe5B8KudJXbcQz1uD4Klx66iT k9sZ8o9EeqSPVnu+xPHtUtdegZ27d2vNTaPobLuos1L0+UZn9ysuJI6zF5TqtwzliqM+ v+J3hHJ+YmpEyG9KTpMruRekra64TUztlgIEv2tRdHDRA3AcHkY6wX5nAEVIAbE+F2Kq sFzEekHu3QGeqawAM41eH8rGhHbD9YPG+YBEnMLNgVRw6pB9WMwn+vLg/8kd/G6BLHRR UyYvtxUpys9UGanagdAwCP0PwZ2YmSSI7rlJpJxhAMEtPkkAgSNg5wQ0on4M7HmfTyKz IuKw== MIME-Version: 1.0 X-Received: by 10.52.50.177 with SMTP id d17mr4612309vdo.23.1386422699402; Sat, 07 Dec 2013 05:24:59 -0800 (PST) Received: by 10.52.116.166 with HTTP; Sat, 7 Dec 2013 05:24:59 -0800 (PST) Date: Sat, 7 Dec 2013 21:24:59 +0800 Message-ID: From: Neng Geng Huang To: apps-discuss@ietf.org Content-Type: multipart/alternative; boundary=089e0111c2dc81e2c404ecf1b0c8 Subject: [apps-discuss] Two new Internet Drafts (Independent Submissions) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Dec 2013 13:25:06 -0000 --089e0111c2dc81e2c404ecf1b0c8 Content-Type: text/plain; charset=ISO-8859-1 Hello, everybody: I sent a post to this mailing list but didn't get it posted, I think. So I post it again as following. Sorry for the inconvenience if you received two duplicate posts. I have submitted two Internet Drafts as Independent Submissions as follows: Filename: draft-huangng-utid Revision: 01 Title: Universally Traceable Identifier (UTID) Creation date: 2013-12-02 Group: Individual Submission Number of pages: 21 Htmlized: http://tools.ietf.org/html/draft-huangng-utid-01 Abstract: A Universally Traceable Identifier (UTID) is a compact string of characters for identifying an abstract or physical object. A unique feature of UTID is that it contains two types of forwarding messages to achieve traceability. UTIDs are designed specially for Identifier Tracing Protocol (ITDP) [I-D-IDTP]. This document defines the generic syntax of UTID, a generative grammar for UTID, and the guidelines for their use, too. Filename: draft-huangng-idtp Revision: 01 Title: Identifier Tracing Protocol (IDTP) Creation date: 2013-12-02 Group: Individual Submission Number of pages: 38 Htmlized: http://tools.ietf.org/html/draft-huangng-idtp-01 Abstract: The Identifier Tracing Protocol (IDTP) is an application-level protocol for distributed and collaborative information systems. It is a generic communication protocol which can be used for many tasks with two types of forwarding mechanisms to achieve traceability by using Universal Traceable Identifier (UTID) [I-D-UTID] which contains two types of forwarding messages. This document provides the specification of IDTP, including syntax, data format, and the guidelines for their use, too. A reference implementation, which is called "busilet", of UTID and IDTP has been developed as open source software and could be downloaded from http://sourceforge.net/projects/busilet/. For more information, please visit: http://www.utid.org/ http://www.codeproject.com/Articles/669577/IDTP-An-Innovative-Communication-Protocol Comments and suggestions are welcome. Cheers Huang -- ------------------------------ Mr. Huang Neng Geng ------------------------------ Associate Professor School of the Internet of Things Wuxi Institute of Technology Wuxi, Jiangsu, China, 214121 Mobile: 86-13921501950 email: huangng@gmail.com --089e0111c2dc81e2c404ecf1b0c8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello, everybody:

I sent a p= ost to this mailing list but didn't get it posted, I think. So I post i= t
=A0 =A0again as following. Sorry for the inconvenience if you r= eceived two duplicate
=A0 =A0posts.

I have submitted two Internet D= rafts as Independent Submissions as follows:

Filen= ame: =A0 =A0 =A0 =A0draft-huangng-utid
Revision: =A0 =A0 =A0 =A00= 1
Title: =A0 =A0 =A0 =A0 =A0 Universally Traceable Identifier (UT= ID)
Creation date: =A0 2013-12-02
Group: =A0 =A0 =A0 =A0 =A0 Ind= ividual Submission
Number of pages: 21

Abstract:
=A0 =A0A Universally Traceable Iden= tifier (UTID) is a compact string of
=A0 =A0characters for identi= fying an abstract or physical object. A unique
=A0 =A0feature of = UTID is that it contains two types of forwarding messages
=A0 =A0to achieve traceability. UTIDs are designed specially for Ident= ifier
=A0 =A0Tracing Protocol (ITDP) [I-D-IDTP].

=A0 =A0This document defines the generic syntax of UTID, a generat= ive
=A0 =A0grammar for UTID, and the guidelines for their use, too.
<= div>
Filename: =A0 =A0 =A0 =A0draft-huangng-idtp
Re= vision: =A0 =A0 =A0 =A001
Title: =A0 =A0 =A0 =A0 =A0 Identifier T= racing Protocol (IDTP)
Creation date: =A0 2013-12-02
Group: =A0 =A0 =A0 =A0 =A0 Ind= ividual Submission
Number of pages: 38

Abstract:
=A0 =A0The Identifier Tracing Proto= col (IDTP) is an application-level
=A0 =A0protocol for distribute= d and collaborative information systems. It
=A0 =A0is a generic c= ommunication protocol which can be used for many tasks
=A0 =A0with two types of forwarding mechanisms to achieve traceability= by
=A0 =A0using Universal Traceable Identifier (UTID) [I-D-UTID]= which
=A0 =A0contains two types of forwarding messages.

=A0 =A0This document provides the specification of IDTP, including syn= tax,
=A0 =A0data format, and the guidelines for their use, too.

A reference implementation, which is called "b= usilet", of UTID and
=A0 =A0IDTP has been developed as open source software and could be

=
For more information, please visit:
=


Comments and suggestions are welcome.

Cheers


Huang=

--
------------------------------=
Mr. Huang Neng Geng
------------------------------
Associate Professo= r
School of the Internet of Things
Wuxi Institute of Technology
Wu= xi, Jiangsu, China, 214121
Mobile: 86-13921501950
email: huangng@gmail.com

--089e0111c2dc81e2c404ecf1b0c8-- From superuser@gmail.com Sun Dec 8 08:09:56 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D37931ADFCC for ; Sun, 8 Dec 2013 08:09:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTAqWEcpdscU for ; Sun, 8 Dec 2013 08:09:55 -0800 (PST) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 353A41ADFBC for ; Sun, 8 Dec 2013 08:09:54 -0800 (PST) Received: by mail-we0-f177.google.com with SMTP id u56so2517628wes.36 for ; Sun, 08 Dec 2013 08:09:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=PamqmwNlC/SFWNkW9Y7D0srgBYSXj6KGCUsOxABY/d8=; b=F/tyrKfHBWFcvUPCnpefi8TiCcbQgWwVOqWhKK8/osG+MkEdWthkN/nAKOcNF5/FJF DJLpk9tTEvlwBqHZ5fDP8pjIhM/FE8RR2cAud8p8JcaH7CHCzAu3DEACetSSUAk+RAeW O9esKR3CMm4ZjD3w2rQ5Vtlj+EIOcQDa8uUhmDom6J+KjaSNRGt/P/iIRdF5SHAJAy6e wPmuX39w3dJH55afszf7i1IXJae3ZAb6PakKCXuyubr43zfCi+qWCb4sMmup4xP9/bGA 4Et5xHHU+Au0zVrts0xcN+bTFZ294C8YPNSJm9MVna0PtP1p5MCtvY9PZ9AB+eMb1wmI mHXQ== MIME-Version: 1.0 X-Received: by 10.180.187.72 with SMTP id fq8mr10473906wic.26.1386518990154; Sun, 08 Dec 2013 08:09:50 -0800 (PST) Received: by 10.181.13.230 with HTTP; Sun, 8 Dec 2013 08:09:50 -0800 (PST) Date: Sun, 8 Dec 2013 08:09:50 -0800 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=001a11c2679ce1eeea04ed081be0 Subject: [apps-discuss] IETF 88 APPSAWG/APPAREA Minutes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Dec 2013 16:09:57 -0000 --001a11c2679ce1eeea04ed081be0 Content-Type: text/plain; charset=ISO-8859-1 The minutes for the Vancouver APPSAWG/APPAREA meeting are now (finally) available for review at: http://www.ietf.org/proceedings/88/minutes/minutes-88-appsawg Apologies that it took a long time to get these done. Please review these as soon as possible to ensure their correctness, especially if you were at the microphone at some point during the session. The Secretariat will be grabbing them very soon to make the official permanent copy of the proceedings. -MSK, APPSAWG co-chair --001a11c2679ce1eeea04ed081be0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The minutes for the Vancouver APPSAWG/APPAREA me= eting are now (finally) available for review at:

http://www.ietf.org/= proceedings/88/minutes/minutes-88-appsawg

Apologies that it took a long time to get these done.=A0 Please r= eview these as soon as possible to ensure their correctness, especially if = you were at the microphone at some point during the session.=A0 The Secreta= riat will be grabbing them very soon to make the official permanent copy of= the proceedings.

-MSK, APPSAWG co-chair
--001a11c2679ce1eeea04ed081be0-- From blueroofmusic@gmail.com Sun Dec 8 10:09:17 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EEF01AE069 for ; Sun, 8 Dec 2013 10:09:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yR-DQnHK_rdK for ; Sun, 8 Dec 2013 10:09:12 -0800 (PST) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id 64FB61AE062 for ; Sun, 8 Dec 2013 10:09:12 -0800 (PST) Received: by mail-ig0-f169.google.com with SMTP id hk11so710531igb.0 for ; Sun, 08 Dec 2013 10:09:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=nWpfpOfff+YuIxPBNVqTLEQ+VaXtfQTR0RGdJ27oJkE=; b=kp4R/bSD4j+tiHYAaR0zfgQJgYZtvS6ZL7bJ54q6k/IM7G5v8AJZ4hHykgNtsjfX2D jWBftoGZMPvcunvtHu6Ag7FcPIlN3/27lXiZ1+JA5Wcs+acn4fh118IuKeKOj2YgPDGd b5gNxvFhx/JL4E0zatmVeI6dBj5ippoN3cpFoSeADXqd7YvQpFXbA59gz5d/r7Y1Aycc EE01s1vSnyHsBspGgCJsSimp3ktnYbdF69vNObr584SykqNahxVEl1ct6k15+dEtJ4R7 2y8Tl7QA5v91CMUpzqEaqkyQj6u/+VqGsBTr8IkhpbJaChw/I7XWOBtkv09zytTPeddP 9krQ== X-Received: by 10.50.134.99 with SMTP id pj3mr12780855igb.14.1386526147743; Sun, 08 Dec 2013 10:09:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.203.38 with HTTP; Sun, 8 Dec 2013 10:08:47 -0800 (PST) In-Reply-To: <528A3430.6080900@isode.com> References: <528A3430.6080900@isode.com> From: Ira McDonald Date: Sun, 8 Dec 2013 13:08:47 -0500 Message-ID: To: Alexey Melnikov , Ira McDonald Content-Type: multipart/alternative; boundary=047d7b41402e82188d04ed09c6b5 Cc: Pat Fleming , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] AppsDir review of draft-mcdonald-ldap-printer-schema-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Dec 2013 18:09:17 -0000 --047d7b41402e82188d04ed09c6b5 Content-Type: text/plain; charset=ISO-8859-1 Hi Alexey, Thank you very much for your careful review of our revised LDAP Printer Schema I-D. Our responses to your comments are inline below. We plan to issue a new draft before Christmas. Cheers, - Ira Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmusic@gmail.com Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 On Mon, Nov 18, 2013 at 10:37 AM, Alexey Melnikov wrote: > On 19/09/2013 17:34, Ira McDonald wrote: > >> 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) >> > > My apologies for belated review. I hope you find them useful. > > ----------------------------------------- > > 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-mcdonald-ldap-printer-schema-05.txt > Title: Lightweight Directory Access Protocol (LDAP): Schema for Printer > Services > Reviewer: Alexey Melnikov > Review Date: November 18, 2013 > IETF Last Call Date: N/A > > Summary: This draft is nearly reading for publication. > > This document defines a schema, object classes and attributes, for > Printers and Print Services, for use with directories that support > Lightweight Directory Access Protocol (RFC 4510). This document is > based on the Printer attributes listed in Appendix E of Internet > Printing Protocol/1.1 (IPP) (RFC 2911). Additional Printer > attributes are based on definitions in the Printer MIB v2 (RFC 3805), > IEEE-ISTO PWG Command Set for IEEE 1284 Device ID (PWG 5107.2), > IEEE-ISTO PWG IPP Job and Printer Extensions - Set 3 (PWG 5100.13), > and IEEE-ISTO PWG IPP Everywhere (PWG 5100.14). > > This document is published by the IETF on behalf of the Internet > Printing Protocol Working Group of the IEEE-ISTO Printer Working > Group. > > > Most of the issues I found are minor. In general the document is quite > readable. > > General comments: > > I noticed that you redifined various syntaxes to have upper limits on > Directory strings. URI and Language Tags have no upper limits. I suspect > that limits that you added are going to be sufficient in most cases, but it > would be better for your document to call these out explicitly in text. > We'll remove the upper limits from the ASN.1 and add them to the text of each relevant attribute. We'll also add an Implementation Note that explains the rationale for the limits and compatibility considerations w/ RFC 3712 implementations deployed over the past ten years - which is the string length limits in the underlying attributes in the Job Monitoring MIB (RFC 2707) and IPP/1.1 (RFC 2911). > > In Section 1: > > This document updates RFC 3712. > > But the draft header says that it Obsoletes it. I think Obsolete is > correct, so the statement in Section 1 should be updated to match. > Good catch. We'll fix this to "Obsoletes". > In Section 3.3: > > Note: When extending other structural classes with auxiliary >> classes, printerService SHOULD not be used. >> > You should also capitalize "not" according to RFC 2119. There are multiple > occurrences of the same problem in multiple places in the document. > Oops. This was an artifact of the RFC 3712 text. We'll fix it globally. > > 3.4. printerServiceAuxClass >> ( 1.3.18.0.2.6.257 >> NAME 'printerServiceAuxClass' >> DESC 'Printer information.' >> >> Fleming, McDonald Expires 19 March 2014 [Page 11] >> >> Internet-Draft LDAP Schema for Printer Services 19 September 2013 >> >> AUXILIARY >> SUP printerAbstract >> MAY ( printer-uri $ >> printer-xri-supported ) >> ) >> This auxiliary class defines Printer information. It is derived >> from >> class printerAbstract and thus inherits common Printer attributes. >> This class SHOULD be used with a structural class. >> > Each directory entry requires a structural object class, so I think this > SHOULD is misleading. Also, why is this not a MUST? > I suggest you just delete this sentence or reword it to make it non > normative (and point to the document which makes the authoritative > statement on this matter.) > > Similar text in 3.5 and 3.6. > Oops. We'll fix this by deleting the misleading sentences globally. > > 4. Definition of Attribute Types >> >> The following attribute types reference matching rule names (instead >> of OIDs) for clarity (see Section 6 below). For optional attributes, >> if the Printer information is not known, the attribute value SHOULD >> not be set. In the following definitions, referenced matching rules >> are defined in Section 4 of [RFC4517] (see Section 6 'Definition of >> Matching Rules' below). >> > > I think you still meant section 4. > Actually it should be a forward reference to section 6 of this document, but we'll clarify the wording in the next draft, e.g., to "...Section 4 of [RFC4517] and discussed in Section 6 ' Definition of Matching Rules' later in this document." OK? > > Note: For interoperability and consistent text display, values of >> attributes defined in this document: (a) SHOULD be normalized as >> recommended in Unicode Format for Network Interchange [RFC5198]; (b) >> SHOULD not contain DEL or any C0 or C1 control characters except for >> > "SHOULD not" --> "SHOULD NOT" > Oops. We'll fix in the global check for "SHOULD not" to "SHOULD NOT". HT, CR, and LF; (c) SHOULD only contain CR and LF characters together >> (not as singletons); and SHOULD NOT contain HT, CR, or LF characters >> in names, e.g., printer-name and printer-aliases. >> > > In 4.1: > > Note: LDAP application clients SHOULD not attempt to use malformed >> URI values read from this attribute. LDAP administrative clients >> SHOULD not write malformed URI values into this attribute. >> > "SHOULD not" --> "SHOULD NOT" (twice) > Oops. This was an artifact of the RFC 3712 text. We'll fix it globally. > > In 4.4: > > Values of language tags SHOULD conform to Tags for Identifying >> Languages [BCP47]. >> > Why is this a SHOULD and not a MUST? I.e. what are possible reason to put > anything not specified in BCP47 here? > Oops. We'll change "SHOULD" to "MUST". The original "SHOULD" (I think) was an attempt to allow for the rigorous ABNF in the earlier version of BCP47. > > 4.12. printer-charset-supported >> ( 1.3.18.0.2.4.1131 >> NAME 'printer-charset-supported' >> DESC 'One of the charsets supported for the attribute values of >> syntax DirectoryString for this directory entry.' >> > I don't understand this description. DirectoryString is always in UTF-8. > Oops. We'll fix the description to refer (as intended) to the underlying IPP/1.1 (RFC 2911) corresponding attribute which does allow legacy character sets (although they are discouraged) and to restate that the values of DirectoryString in this LDAP Schema MUST always be UTF-8. > > How is this LDAP attribute being used? > >> EQUALITY caseIgnoreMatch >> SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{255} >> ) >> > We have an EQUALITY clause for every string attribute. The values of this attribute are used to inform the LDAP Client of what the supported values of the underlying IPP/1.1 (RFC 2911) attribute are, i.e., what are the possible charsets that can be sent in string attributes in IPP/1.1 requests. We'll rewrite this description to clarify the usage. > > 4.13. printer-generated-natural-language-supported >> ( 1.3.18.0.2.4.1137 >> NAME 'printer-generated-natural-language-supported' >> DESC 'One of the natural languages supported for this directory >> entry.' >> > Again, I am not entirely sure how this is used. Can you clarify? > Same description problem as the previous attribute (it really refers to the supported values of the underlying IPP/1.1 (RFC 2911) attribute). We'll rewrite this description to clarify the usage. > > 4.20. printer-number-up-supported >> ( 1.3.18.0.2.4.1124 >> NAME 'printer-number-up-supported' >> DESC 'Maximum number of print-stream pages that can be imposed upon a >> single side of an instance of selected medium by this Printer.' >> EQUALITY integerMatch >> ORDERING integerOrderingMatch >> SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 >> ) >> > This is not defined as single-valued. What is the meaning of multiple > values? > Oops. This is an RFC 3712 bug. The underlying IPP/1.1 (RFC 2911) attribute has a complex syntax of "1setOf (integer (1:MAX)" or "rangeOfInteger (1:MAX)". We intended to flatten it in the LDAP Printer Schema to the simple maximum. I think we should delete the erroneous ORDERING clause. OK? > > 4.35. printer-device-id >> ( 1.3.18.0.2.24.46.1.101 >> NAME 'printer-device-id' >> DESC 'The IEEE 1284 Device ID for this Printer.' >> EQUALITY caseIgnoreMatch >> SUBSTR caseIgnoreSubstringsMatch >> SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{255} >> ) >> Values of this attribute SHOULD conform to IEEE-ISTO PWG Command >> Set >> Format for IEEE 1284 Device ID [PWG5107.2]. >> Note: For interoperatibility, values of this attribute SHOULD >> include key/value pairs in the following order: (a) all required >> key/value pairs (i.e., MANUFACTURER/MFG, MODEL/MDL, and COMMAND >> SET/CMD); (b) all optional key/value pairs; and (c) all vendor >> key/value pairs. >> > How does the advice on ordering interacts with multiple values of the > attribute? LDAP multivalued attributes have no ordering of values. > The ordering advice is for the three keywords that are mandatory in the source IEEE 1284 standard. I suggest that we simply delete the "Note" clause that is already covered in much greater detail in PWG 5107.2 with a rationale (which is the preservation of the three mandatory keywords when string truncation may occur in various other directory and service location protocols). OK? > > printer-device-id 1.3.18.0.2.24.46.1.101 > printer-device-service-count 1.3.18.0.2.24.46.1.102 > printer-uuid 1.3.18.0.2.24.46.1.104 > printer-charge-info 1.3.18.0.2.24.46.1.105 > printer-charge-info-uri 1.3.18.0.2.24.46.1.106 > printer-geo-location 1.3.18.0.2.24.46.1.107 > printer-ipp-features-supported 1.3.18.0.2.24.46.1.108 > > This is not necessarily a problem, but I couldn't find a registration for > the 1.3.18.0.2.24 OID. The parent OID is owned by IBM. > In October 2011, IBM permanently assigned this base OID to IEEE-ISTO PWG for use in the LDAP Printer Schema and any other future PWG standard that needed an ASN.1 OID (which wouldn't be covered by the PWG's SMI arc). We'll add a labelled section (to show up in Table of Contents) to document this assignment. > > 13. Appendix X - Change History > > [ [RFC Editor: This section to be deleted before RFC publication] ] > > -bis document are required to include "Changes since RFC XXXX" section. So > you should replace this Appendix with another one that details changes > since RFC 3712. > We'll add a new permanent appendix for "Changes since RFC 3712". We prefer to leave the Change History appendix until final publication as an RFC, to document the serpentine path to the final text and to acknowledge specific contributions that led to draft changes. OK? > Best Regards, > Alexey > > --047d7b41402e82188d04ed09c6b5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Alexey,

Thank you very much for = your careful review of our revised LDAP Printer
Schema I-D.= =A0 Our responses to your comments are inline below.

We p= lan to issue a new draft before Christmas.

Cheers,
- Ira


Ira McDonald (Mu= sician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions W= G
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer = Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
= IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High No= rth Inc
http://sites.google.com/site/blueroofmusic=
http://sites.google.com/site/highnorthinc
mailto: bluero= ofmusic@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 Mon, Nov 18, 2013 at 10:37 AM, Alexey= Melnikov <alexey.melnikov@isode.com> wrote:
On 19/09/2013 17:34, Ira McDonald wrote:
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)

My apologies for belated review. I hope you find them useful.

-----------------------------------------

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/ApplicationsAre= aDirectorate ).

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-mcdonald-ldap-printer-schema-05.txt
Title: Lightweight Directory Access Protocol (LDAP): Schema for Printer Ser= vices
Reviewer: Alexey Melnikov
Review Date: November 18, 2013
IETF Last Call Date: N/A

Summary: This draft is nearly reading for publication.

This document defines a schema, object classes and attributes, for
Printers and Print Services, for use with directories that support
Lightweight Directory Access Protocol (RFC 4510). =A0This document is
based on the Printer attributes listed in Appendix E of Internet
Printing Protocol/1.1 (IPP) (RFC 2911). =A0Additional Printer
attributes are based on definitions in the Printer MIB v2 (RFC 3805),
IEEE-ISTO PWG Command Set for IEEE 1284 Device ID (PWG 5107.2),
IEEE-ISTO PWG IPP Job and Printer Extensions - Set 3 (PWG 5100.13),
and IEEE-ISTO PWG IPP Everywhere (PWG 5100.14).

This document is published by the IETF on behalf of the Internet
Printing Protocol Working Group of the IEEE-ISTO Printer Working
Group.


Most of the issues I found are minor. In general the document is quite read= able.

General comments:

I noticed that you redifined various syntaxes to have upper limits on Direc= tory strings. URI and Language Tags have no upper limits. =A0I suspect that= limits that you added are going to be sufficient in most cases, but it wou= ld be better for your document to call these out explicitly in text.

<ira>
We'll remove= the upper limits from the ASN.1 and add them to the text of each
=
relevant attribute.=A0

We'll also add an Implementation No= te that explains the rationale for the limits
and compatibility considerations w/ RFC 3712 implementations deployed over<= br>the past ten years - which is the string length limits in the underlying= attributes
in the Job Monitoring MIB (RFC 2707) and IPP/1.1 (RFC 2911)= .
<ira>

In Section 1:

This document updates RFC 3712.

But the draft header says that it Obsoletes it. I think Obsolete is correct= , so the statement in Section 1 should be updated to match.

<ira>
Good catch.=A0 We'll fix= this to "Obsoletes".
</ira>
=A0
In Section 3.3:

=A0 =A0Note: =A0When extending other structural classes with auxiliary
=A0 =A0 classes, printerService SHOULD not be used.
You should also capitalize "not" according to RFC 2119. There are= multiple occurrences of the same problem in multiple places in the documen= t.

<ira>
Oops.=A0 T= his was an artifact of the RFC 3712 text.=A0 We'll fix it globally.
</ira>

3.4. =A0printerServiceAuxClass
=A0 =A0 =A0 =A0 ( 1.3.18.0.2.6.257
=A0 =A0 NAME =A0'printerServiceAuxClass'
=A0 =A0 DESC =A0'Printer information.'

Fleming, McDonald =A0 =A0 =A0 =A0 =A0 =A0Expires 19 March 2014 =A0 =A0 =A0 = =A0 =A0 =A0 [Page 11]
=0C
Internet-Draft =A0 =A0LDAP Schema for Printer Services =A0 =A0 19 September= 2013

=A0 =A0 AUXILIARY
=A0 =A0 SUP =A0 printerAbstract
=A0 =A0 MAY =A0 ( printer-uri $
=A0 =A0 =A0 =A0 =A0 =A0 printer-xri-supported )
=A0 =A0 )
=A0 =A0 =A0 =A0 This auxiliary class defines Printer information. =A0It is = derived from
=A0 =A0 class printerAbstract and thus inherits common Printer attributes.<= br> =A0 =A0 This class SHOULD be used with a structural class.
Each directory entry requires a structural object class, so I think this SH= OULD is misleading. Also, why is this not a MUST?
I suggest you just delete this sentence or reword it to make it non normati= ve (and point to the document which makes the authoritative statement on th= is matter.)

Similar text in 3.5 and 3.6.

<ira>= ;
Oops. We'll fix this by deleting the misleading sentenc= es globally.
</ira>

4. =A0Definition of Attribute Types

=A0 =A0The following attribute types reference matching rule names (instead=
=A0 =A0of OIDs) for clarity (see Section 6 below). =A0For optional attribut= es,
=A0 =A0if the Printer information is not known, the attribute value SHOULD<= br> =A0 =A0not be set. =A0In the following definitions, referenced matching rul= es
=A0 =A0are defined in Section 4 of [RFC4517] (see Section 6 'Definition= of
=A0 =A0Matching Rules' below).

I think you still meant section 4.

<= ira>
Actually it should be a forward reference to section = 6 of this document,
but we'll clarify the wording in the = next draft, e.g., to
"...Section 4 of [RFC4517] and discussed in Section 6 '= Definition of
Matching Rules' later in this document.&qu= ot;
OK?
</ira>

=A0 =A0 Note: =A0For interoperability and consistent text display, values o= f
=A0 =A0 attributes defined in this document: =A0(a) SHOULD be normalized as=
=A0 =A0 recommended in Unicode Format for Network Interchange [RFC5198]; (b= )
=A0 =A0 SHOULD not contain DEL or any C0 or C1 control characters except fo= r
"SHOULD not" --> "SHOULD NOT"
<= br>
<ira>
Oops.=A0 We'll fix in the globa= l check for "SHOULD not" to "SHOULD NOT".
</ira>

=A0 =A0 HT, CR, and LF; (c) SHOULD only contain CR and LF characters togeth= er
=A0 =A0 (not as singletons); and SHOULD NOT contain HT, CR, or LF character= s
=A0 =A0 in names, e.g., printer-name and printer-aliases.

=A0In 4.1:

=A0 =A0 Note: =A0LDAP application clients SHOULD not attempt to use malform= ed
=A0 =A0 URI values read from this attribute. =A0LDAP administrative clients=
=A0 =A0 SHOULD not write malformed URI values into this attribute.
"SHOULD not" --> "SHOULD NOT" (twice)

<ira>
Oops.=A0 This was an artifact of = the RFC 3712 text.=A0 We'll fix it globally.
</ira>

In 4.4:

=A0 =A0 Values of language tags SHOULD conform to Tags for Identifying
=A0 =A0 Languages [BCP47].
Why is this a SHOULD and not a MUST? I.e. what are possible reason to put a= nything not specified in BCP47 here?

&l= t;ira>
Oops.=A0 We'll change "SHOULD" to &qu= ot;MUST".=A0 The original "SHOULD" (I think)
was an attempt to allow for the rigorous ABNF in the earlier ver= sion of BCP47.
</ira>

=A0 =A0 4.12. =A0printer-charset-supported
=A0 =A0 =A0 =A0 ( 1.3.18.0.2.4.1131
=A0 =A0 NAME 'printer-charset-supported'
=A0 =A0 DESC 'One of the charsets supported for the attribute values of=
=A0 =A0 =A0 =A0 =A0 syntax DirectoryString for this directory entry.'
I don't understand this description. DirectoryString is always in UTF-8= .

<ira>
Oops.=A0 We= 'll fix the description to refer (as intended) to the underlying
IPP/1.1 (RFC 2911) corresponding attribute which does allow lega= cy
character sets (although they are discouraged) and to rest= ate that the
values of DirectoryString in this LDAP Schema MU= ST always be UTF-8.
</ira>

How is this LDAP attribute being used?
=A0 =A0 EQUALITY caseIgnoreMatch
=A0 =A0 SYNTAX =A01.3.6.1.4.1.1466.115.121.1.15{255}
=A0 =A0 )

<ira>
<= /div>
We have an EQUALITY clause for every string attribute.=A0 The val= ues
of this attribute are used to inform the LDAP Client of w= hat the supported
values of the underlying IPP/1.1 (RFC 2911) attribute are, i.e.,= what are
the possible charsets that can be sent in string at= tributes in IPP/1.1
requests.=A0 We'll rewrite this description to c= larify the usage.
</ira>

=A0 =A04.13. =A0printer-generated-natural-language-supported
=A0 =A0 =A0 =A0 ( 1.3.18.0.2.4.1137
=A0 =A0 NAME 'printer-generated-natural-language-supported'<= br> =A0 =A0 DESC 'One of the natural languages supported for this directory=
=A0 =A0 =A0 =A0 =A0 entry.'
Again, I am not entirely sure how this is used. Can you clarify?

<ira>
Same description proble= m as the previous attribute (it really refers to
the supported values of= the underlying IPP/1.1 (RFC 2911) attribute).
We'll rewrite this description to clarify the usage.
<= /ira>

=A0 =A04.20. =A0printer-number-up-supported
=A0 =A0 =A0 =A0 ( 1.3.18.0.2.4.1124
=A0 =A0 NAME 'printer-number-up-supported'
=A0 =A0 DESC 'Maximum number of print-stream pages that can be imposed = upon a
=A0 =A0 =A0 =A0 =A0 single side of an instance of selected medium by this P= rinter.'
=A0 =A0 EQUALITY integerMatch
=A0 =A0 ORDERING integerOrderingMatch
=A0 =A0 SYNTAX =A01.3.6.1.4.1.1466.115.121.1.27
=A0 =A0 )
This is not defined as single-valued. What is the meaning of multiple value= s?

<ira>
Oops.=A0 T= his is an RFC 3712 bug.=A0 The underlying IPP/1.1 (RFC 2911) attribute
has a complex syntax of "1setOf (integer (1:MAX)" or &= quot;rangeOfInteger (1:MAX)".
We intended to flatten it = in the LDAP Printer Schema to the simple maximum.
I think we = should delete the erroneous ORDERING clause.
OK?
</ira>

=A0 =A0 4.35. =A0printer-device-id
=A0 =A0 =A0 =A0 ( 1.3.18.0.2.24.46.1.101
=A0 =A0 NAME 'printer-device-id'
=A0 =A0 DESC 'The IEEE 1284 Device ID for this Printer.'
=A0 =A0 EQUALITY caseIgnoreMatch
=A0 =A0 SUBSTR caseIgnoreSubstringsMatch
=A0 =A0 SYNTAX =A01.3.6.1.4.1.1466.115.121.1.15{255}
=A0 =A0 )
=A0 =A0 =A0 =A0 Values of this attribute SHOULD conform to IEEE-ISTO PWG Co= mmand Set
=A0 =A0 Format for IEEE 1284 Device ID [PWG5107.2].
=A0 =A0 =A0 =A0 Note: =A0For interoperatibility, values of this attribute S= HOULD
=A0 =A0 include key/value pairs in the following order: =A0(a) all required=
=A0 =A0 key/value pairs (i.e., MANUFACTURER/MFG, MODEL/MDL, and COMMAND
=A0 =A0 SET/CMD); (b) all optional key/value pairs; and (c) all vendor
=A0 =A0 key/value pairs.
How does the advice on ordering interacts with multiple values of the attri= bute? LDAP multivalued attributes have no ordering of values.

<ira>
The ordering advice is for= the three keywords that are mandatory in the source
IEEE 1284 standard.=A0 I suggest that we simply delete the "= ;Note" clause that is
already covered in much greater de= tail in PWG 5107.2 with a rationale (which
is the preservatio= n of the three mandatory keywords when string truncation may
occur in various other directory and service location protocols)= .
OK?
</ira>

=A0 =A0printer-device-id =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 1.3.18.0.2.24.46.1.101
=A0 =A0printer-device-service-count =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A01.3.= 18.0.2.24.46.1.102
=A0 =A0printer-uuid =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A01.3.18.0.2.24.46.1.104
=A0 =A0printer-charge-info =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 1.3.18.0.2.24.46.1.105
=A0 =A0printer-charge-info-uri =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = 1.3.18.0.2.24.46.1.106
=A0 =A0printer-geo-location =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A01.3.18.0.2.24.46.1.107
=A0 =A0printer-ipp-features-supported =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A01.3.18= .0.2.24.46.1.108

This is not necessarily a problem, but I couldn't find a registration f= or the 1.3.18.0.2.24 OID. The parent OID is owned by IBM.
<= div>
<ira>
In October 2011, IBM permanent= ly assigned this base OID to IEEE-ISTO PWG
for use in the LDAP Printer Schema and any other future PWG stan= dard that
needed an ASN.1 OID (which wouldn't be covered = by the PWG's SMI arc).
We'll add a labelled section = (to show up in Table of Contents) to document this
assignment.
</ira>

13. =A0Appendix X - Change History

=A0 =A0[ [RFC Editor: =A0This section to be deleted before RFC publication]= ]

-bis document are required to include "Changes since RFC XXXX" se= ction. So you should replace this Appendix with another one that details ch= anges since RFC 3712.

<ira>
We'll add a new permanent appendix for "Changes since R= FC 3712".
We prefer to leave the Change History appendix= until final publication
as an RFC, to document the serpentine path to t= he final text and to
acknowledge specific contributions that led to draft changes.
OK?
</ira>
=A0
Best Regards,
Alexey


--047d7b41402e82188d04ed09c6b5-- From mnot@mnot.net Sun Dec 8 21:57:42 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B5221AD8DA for ; Sun, 8 Dec 2013 21:57:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nQxbVrN1ju7u for ; Sun, 8 Dec 2013 21:57:40 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 3D1F01AD34C for ; Sun, 8 Dec 2013 21:57:40 -0800 (PST) Received: from [192.168.1.55] (unknown [118.209.134.50]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 06519509B6; Mon, 9 Dec 2013 00:57:33 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Mark Nottingham Date: Mon, 9 Dec 2013 16:57:28 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20131209055506.26533.39656.idtracker@ietfa.amsl.com> To: IETF Apps Discuss X-Mailer: Apple Mail (2.1822) Subject: [apps-discuss] Fwd: New Version Notification for draft-nottingham-http-problem-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 05:57:42 -0000 FYI; a new version with a new media type and non-camelCase keys, to make = it go down easier. Cheers, Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-nottingham-http-problem-05.txt > Date: 9 December 2013 4:55:06 pm AEDT > To: Erik Wilde , Mark Nottingham >=20 >=20 > A new version of I-D, draft-nottingham-http-problem-05.txt > has been successfully submitted by Mark Nottingham and posted to the > IETF repository. >=20 > Filename: draft-nottingham-http-problem > Revision: 05 > Title: Problem Details for HTTP APIs > Creation date: 2013-12-09 > Group: Individual Submission > Number of pages: 13 > URL: = http://www.ietf.org/internet-drafts/draft-nottingham-http-problem-05.txt > Status: = http://datatracker.ietf.org/doc/draft-nottingham-http-problem > Htmlized: = http://tools.ietf.org/html/draft-nottingham-http-problem-05 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-nottingham-http-problem-05 >=20 > Abstract: > This document defines a "problem detail" as a way to carry machine- > readable details of errors in a HTTP response, to avoid the need to > invent new error response formats for HTTP APIs. >=20 > Note to Readers >=20 > This draft should be discussed on the apps-discuss mailing list [1]. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 -- Mark Nottingham http://www.mnot.net/ From alexey.melnikov@isode.com Sun Dec 8 23:59:03 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26BFD1AE22A for ; Sun, 8 Dec 2013 23:59:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SXkztwwz4GpN for ; Sun, 8 Dec 2013 23:58:59 -0800 (PST) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id B733F1ADED6 for ; Sun, 8 Dec 2013 23:58:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1386575931; d=isode.com; s=selector; i=@isode.com; bh=j7pyvWci9SPavAt3owEF1J0N+uPwlpWkbYcBgmlaz38=; 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=OQKXOPyH0QUreJn/JQxu95nYvOPE+Kh7Vlh9J5RGvPDQG6P0aoFIo925ATfShGVoHXt/mG /mOYM8C+9AsmOkTOER9cRCtghl4Mp7yfDsyNMn0tPX4eTvTlAhPt+bdPHPeJb8xS9IfjQ5 AUL4s40T8qoS0fMLak3yHEmXWoCCayI=; Received: from [192.168.0.12] (cpc5-nmal20-2-0-cust24.19-2.cable.virginm.net [92.234.84.25]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 9 Dec 2013 07:58:50 +0000 X-SMTP-Protocol-Errors: PIPELINING From: Alexey Melnikov X-Mailer: iPad Mail (11B511) In-Reply-To: Date: Mon, 9 Dec 2013 07:59:48 +0000 Message-Id: References: <528A3430.6080900@isode.com> To: Ira McDonald MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=Apple-Mail-981AA6CD-1AA2-444A-9B97-63930607CAC8 Content-Transfer-Encoding: 7bit Cc: Pat Fleming , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] AppsDir review of draft-mcdonald-ldap-printer-schema-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 07:59:03 -0000 --Apple-Mail-981AA6CD-1AA2-444A-9B97-63930607CAC8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi Ira, I've deleted your replies where we are in agreement and I have no further co= mments. On 8 Dec 2013, at 18:08, Ira McDonald wrote: >>> 4. Definition of Attribute Types >>>=20 >>> The following attribute types reference matching rule names (instead >>> of OIDs) for clarity (see Section 6 below). For optional attributes,= >>> if the Printer information is not known, the attribute value SHOULD >>> not be set. In the following definitions, referenced matching rules >>> are defined in Section 4 of [RFC4517] (see Section 6 'Definition of >>> Matching Rules' below). >>=20 >> I think you still meant section 4. >=20 > > Actually it should be a forward reference to section 6 of this document, > but we'll clarify the wording in the next draft, e.g., to > "...Section 4 of [RFC4517] and discussed in Section 6 ' Definition of > Matching Rules' later in this document." > OK? > Ah, that is fine. [...] >>=20 >>> 4.12. printer-charset-supported >>> ( 1.3.18.0.2.4.1131 >>> NAME 'printer-charset-supported' >>> DESC 'One of the charsets supported for the attribute values of >>> syntax DirectoryString for this directory entry.' >> I don't understand this description. DirectoryString is always in UTF-8. >=20 > > Oops. We'll fix the description to refer (as intended) to the underlying > IPP/1.1 (RFC 2911) corresponding attribute which does allow legacy > character sets (although they are discouraged) and to restate that the > values of DirectoryString in this LDAP Schema MUST always be UTF-8. Much better, thank you. > >>> 4.13. printer-generated-natural-language-supported >>> ( 1.3.18.0.2.4.1137 >>> NAME 'printer-generated-natural-language-supported' >>> DESC 'One of the natural languages supported for this directory >>> entry.' >> Again, I am not entirely sure how this is used. Can you clarify? >=20 > > Same description problem as the previous attribute (it really refers to > the supported values of the underlying IPP/1.1 (RFC 2911) attribute). > We'll rewrite this description to clarify the usage. Excellent. > >>=20 >>> 4.20. printer-number-up-supported >>> ( 1.3.18.0.2.4.1124 >>> NAME 'printer-number-up-supported' >>> DESC 'Maximum number of print-stream pages that can be imposed upon a= >>> single side of an instance of selected medium by this Printer.= ' >>> EQUALITY integerMatch >>> ORDERING integerOrderingMatch >>> SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 >>> ) >> This is not defined as single-valued. What is the meaning of multiple val= ues? >=20 > > Oops. This is an RFC 3712 bug. The underlying IPP/1.1 (RFC 2911) attribu= te > has a complex syntax of "1setOf (integer (1:MAX)" or "rangeOfInteger (1:MA= X)". > We intended to flatten it in the LDAP Printer Schema to the simple maximum= . > I think we should delete the erroneous ORDERING clause. > OK? Ok. So are you going to make it single-valued then? > >>=20 >>> 4.35. printer-device-id >>> ( 1.3.18.0.2.24.46.1.101 >>> NAME 'printer-device-id' >>> DESC 'The IEEE 1284 Device ID for this Printer.' >>> EQUALITY caseIgnoreMatch >>> SUBSTR caseIgnoreSubstringsMatch >>> SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{255} >>> ) >>> Values of this attribute SHOULD conform to IEEE-ISTO PWG Command= Set >>> Format for IEEE 1284 Device ID [PWG5107.2]. >>> Note: For interoperatibility, values of this attribute SHOULD >>> include key/value pairs in the following order: (a) all required >>> key/value pairs (i.e., MANUFACTURER/MFG, MODEL/MDL, and COMMAND >>> SET/CMD); (b) all optional key/value pairs; and (c) all vendor >>> key/value pairs. >> How does the advice on ordering interacts with multiple values of the att= ribute? LDAP multivalued attributes have no ordering of values. >=20 > > The ordering advice is for the three keywords that are mandatory in the so= urce > IEEE 1284 standard. I suggest that we simply delete the "Note" clause tha= t is > already covered in much greater detail in PWG 5107.2 with a rationale (whi= ch > is the preservation of the three mandatory keywords when string truncation= may > occur in various other directory and service location protocols). > OK? Sounds sensible. > >>=20 >> printer-device-id 1.3.18.0.2.24.46.1.101 >> printer-device-service-count 1.3.18.0.2.24.46.1.102 >> printer-uuid 1.3.18.0.2.24.46.1.104 >> printer-charge-info 1.3.18.0.2.24.46.1.105 >> printer-charge-info-uri 1.3.18.0.2.24.46.1.106 >> printer-geo-location 1.3.18.0.2.24.46.1.107 >> printer-ipp-features-supported 1.3.18.0.2.24.46.1.108 >>=20 >> This is not necessarily a problem, but I couldn't find a registration for= the 1.3.18.0.2.24 OID. The parent OID is owned by IBM. >=20 > > In October 2011, IBM permanently assigned this base OID to IEEE-ISTO PWG > for use in the LDAP Printer Schema and any other future PWG standard that > needed an ASN.1 OID (which wouldn't be covered by the PWG's SMI arc).=20 > We'll add a labelled section (to show up in Table of Contents) to document= this > assignment. Perfect, thank you. > >>=20 >> 13. Appendix X - Change History >>=20 >> [ [RFC Editor: This section to be deleted before RFC publication] ] >>=20 >> -bis document are required to include "Changes since RFC XXXX" section. S= o you should replace this Appendix with another one that details changes sin= ce RFC 3712. >=20 > > We'll add a new permanent appendix for "Changes since RFC 3712". > We prefer to leave the Change History appendix until final publication > as an RFC, to document the serpentine path to the final text and to > acknowledge specific contributions that led to draft changes. > OK? What you suggest is fine! Best Regards, Alexey > > =20 >> Best Regards, >> Alexey --Apple-Mail-981AA6CD-1AA2-444A-9B97-63930607CAC8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Hi Ira,
I've deleted your replies where we are in agreement and I have no further comments.

On 8 Dec 2013, at 18:08, Ira McDonald <blueroofmusic@gmail.com> wrote:

4.  Definition of Attribute Types

   The following attribute types reference matching rule names (instead
   of OIDs) for clarity (see Section 6 below).  For optional attributes,
   if the Printer information is not known, the attribute value SHOULD
   not be set.  In the following definitions, referenced matching rules
   are defined in Section 4 of [RFC4517] (see Section 6 'Definition of
   Matching Rules' below).


I think you still meant section 4.


<ira>
Actually it should be a forward reference to section 6 of this document,
but we'll clarify the wording in the next draft, e.g., to
"...Section 4 of [RFC4517] and discussed in Section 6 ' Definition of
Matching Rules' later in this document."
OK?
</ira>

Ah, that is fine.
 [...]

    4.12.  printer-charset-supported
        ( 1.3.18.0.2.4.1131
    NAME 'printer-charset-supported'
    DESC 'One of the charsets supported for the attribute values of
          syntax DirectoryString for this directory entry.'

I don't understand this description. DirectoryString is always in UTF-8.


<ira>
Oops.  We'll fix the description to refer (as intended) to the underlying
IPP/1.1 (RFC 2911) corresponding attribute which does allow legacy
character sets (although they are discouraged) and to restate that the
values of DirectoryString in this LDAP Schema MUST always be UTF-8.

Much better, thank you.

</ira>

   4.13.  printer-generated-natural-language-supported
        ( 1.3.18.0.2.4.1137
    NAME 'printer-generated-natural-language-supported'
    DESC 'One of the natural languages supported for this directory
          entry.'

Again, I am not entirely sure how this is used. Can you clarify?


<ira>
Same description problem as the previous attribute (it really refers to
the supported values of the underlying IPP/1.1 (RFC 2911) attribute).
We'll rewrite this description to clarify the usage.

Excellent.
</ira>

   4.20.  printer-number-up-supported
        ( 1.3.18.0.2.4.1124
    NAME 'printer-number-up-supported'
    DESC 'Maximum number of print-stream pages that can be imposed upon a
          single side of an instance of selected medium by this Printer.'
    EQUALITY integerMatch
    ORDERING integerOrderingMatch
    SYNTAX  1.3.6.1.4.1.1466.115.121.1.27
    )

This is not defined as single-valued. What is the meaning of multiple values?


<ira>
Oops.  This is an RFC 3712 bug.  The underlying IPP/1.1 (RFC 2911) attribute
has a complex syntax of "1setOf (integer (1:MAX)" or "rangeOfInteger (1:MAX)".
We intended to flatten it in the LDAP Printer Schema to the simple maximum.
I think we should delete the erroneous ORDERING clause.
OK?

Ok. So are you going to make it single-valued then?
</ira>

    4.35.  printer-device-id
        ( 1.3.18.0.2.24.46.1.101
    NAME 'printer-device-id'
    DESC 'The IEEE 1284 Device ID for this Printer.'
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX  1.3.6.1.4.1.1466.115.121.1.15{255}
    )
        Values of this attribute SHOULD conform to IEEE-ISTO PWG Command Set
    Format for IEEE 1284 Device ID [PWG5107.2].
        Note:  For interoperatibility, values of this attribute SHOULD
    include key/value pairs in the following order:  (a) all required
    key/value pairs (i.e., MANUFACTURER/MFG, MODEL/MDL, and COMMAND
    SET/CMD); (b) all optional key/value pairs; and (c) all vendor
    key/value pairs.

How does the advice on ordering interacts with multiple values of the attribute? LDAP multivalued attributes have no ordering of values.


<ira>
The ordering advice is for the three keywords that are mandatory in the source
IEEE 1284 standard.  I suggest that we simply delete the "Note" clause that is
already covered in much greater detail in PWG 5107.2 with a rationale (which
is the preservation of the three mandatory keywords when string truncation may
occur in various other directory and service location protocols).
OK?

Sounds sensible.
</ira>

   printer-device-id                             1.3.18.0.2.24.46.1.101
   printer-device-service-count                  1.3.18.0.2.24.46.1.102
   printer-uuid                                  1.3.18.0.2.24.46.1.104
   printer-charge-info                           1.3.18.0.2.24.46.1.105
   printer-charge-info-uri                       1.3.18.0.2.24.46.1.106
   printer-geo-location                          1.3.18.0.2.24.46.1.107
   printer-ipp-features-supported                1.3.18.0.2.24.46.1.108

This is not necessarily a problem, but I couldn't find a registration for the 1.3.18.0.2.24 OID. The parent OID is owned by IBM.


<ira>
In October 2011, IBM permanently assigned this base OID to IEEE-ISTO PWG
for use in the LDAP Printer Schema and any other future PWG standard that
needed an ASN.1 OID (which wouldn't be covered by the PWG's SMI arc).
We'll add a labelled section (to show up in Table of Contents) to document this
assignment.

Perfect, thank you.
</ira>

13.  Appendix X - Change History

   [ [RFC Editor:  This section to be deleted before RFC publication] ]

-bis document are required to include "Changes since RFC XXXX" section. So you should replace this Appendix with another one that details changes since RFC 3712.


<ira>
We'll add a new permanent appendix for "Changes since RFC 3712".
We prefer to leave the Change History appendix until final publication
as an RFC, to document the serpentine path to the final text and to
acknowledge specific contributions that led to draft changes.
OK?

What you suggest is fine!

Best Regards,
Alexey
</ira>
 
Best Regards,
Alexey


--Apple-Mail-981AA6CD-1AA2-444A-9B97-63930607CAC8-- From blueroofmusic@gmail.com Mon Dec 9 04:20:47 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6960F1AE26E for ; Mon, 9 Dec 2013 04:20:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rahrOG2eRc0D for ; Mon, 9 Dec 2013 04:20:44 -0800 (PST) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 1F6101AE280 for ; Mon, 9 Dec 2013 04:20:44 -0800 (PST) Received: by mail-ig0-f171.google.com with SMTP id c10so1238048igq.4 for ; Mon, 09 Dec 2013 04:20:39 -0800 (PST) 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=TJcHHzKlyDRkLP49r07x3yyEr4ox+NXTcDGcXF/3PPg=; b=BbS6Sunn3v10mQFmxY8j7mNy0FnSrI9Y5TssT6oXbfdYduoIotUMHXqsgiRBbdwj2m qZq+Hmy68sE1x/w8xYcHkNIEdSKTpwZPmW20bhw/kTdAyMZbJCtBeFslMXSkmz9UYhhl Gx33QtvjzH9FLOh+uQWEnKwGHCwqBasBR8MDUn2Vt7v4Mq/g98l8GnwsrnpI1tFm3NtO 2ZmGb8VOVIT0NREGGEBds7ZE7l+f4LQR8n6pYKHbuvgMn5ExF0ywNvplLvYv86Q9LExH gpncSTIMMYPLdJ+VQmSMr3w0bvGQVyuOmXa3fadoMtrE62Q8fkJeNuJoK1BXCJ9rVThB JSRA== X-Received: by 10.42.224.10 with SMTP id im10mr1551293icb.46.1386591639252; Mon, 09 Dec 2013 04:20:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.203.38 with HTTP; Mon, 9 Dec 2013 04:20:18 -0800 (PST) In-Reply-To: References: <528A3430.6080900@isode.com> From: Ira McDonald Date: Mon, 9 Dec 2013 07:20:18 -0500 Message-ID: To: Alexey Melnikov Content-Type: multipart/alternative; boundary=001a11332dbc1b356004ed190606 Cc: Pat Fleming , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] AppsDir review of draft-mcdonald-ldap-printer-schema-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 12:20:47 -0000 --001a11332dbc1b356004ed190606 Content-Type: text/plain; charset=ISO-8859-1 Hi Alexey, Thanks for your lightning fast response/ I just realized that I got one thing wrong, I think. Pat Fleming's the LDAP expert and I'm the IPP expert in this team. The attribute "printer-number-up-supported' was always meant to be single-valued (which is implied by its description). So, to be consistent with "printer-pages-per-minute" and others, I think I should *keep* the ORDERING clause but add the accidentally missing SINGLE-VALUE clause. Is that right? I will also proof-read the whole list of attributes again before the next draft and make sure that there are no other missing SINGLE-VALUE clauses. Cheers, - Ira Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmusic@gmail.com Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 On Mon, Dec 9, 2013 at 2:59 AM, Alexey Melnikov wrote: > Hi Ira, > I've deleted your replies where we are in agreement and I have no further > comments. > > On 8 Dec 2013, at 18:08, Ira McDonald wrote: > > 4. Definition of Attribute Types >>> >>> The following attribute types reference matching rule names (instead >>> of OIDs) for clarity (see Section 6 below). For optional attributes, >>> if the Printer information is not known, the attribute value SHOULD >>> not be set. In the following definitions, referenced matching rules >>> are defined in Section 4 of [RFC4517] (see Section 6 'Definition of >>> Matching Rules' below). >>> >>> >> I think you still meant section 4. >> >> > > Actually it should be a forward reference to section 6 of this document, > but we'll clarify the wording in the next draft, e.g., to > "...Section 4 of [RFC4517] and discussed in Section 6 ' Definition of > Matching Rules' later in this document." > OK? > > > > Ah, that is fine. > [...] > > >> 4.12. printer-charset-supported >>> ( 1.3.18.0.2.4.1131 >>> NAME 'printer-charset-supported' >>> DESC 'One of the charsets supported for the attribute values of >>> syntax DirectoryString for this directory entry.' >>> >>> I don't understand this description. DirectoryString is always in UTF-8. >> >> > > Oops. We'll fix the description to refer (as intended) to the underlying > IPP/1.1 (RFC 2911) corresponding attribute which does allow legacy > character sets (although they are discouraged) and to restate that the > values of DirectoryString in this LDAP Schema MUST always be UTF-8. > > > Much better, thank you. > > > > > 4.13. printer-generated-natural-language-supported >>> ( 1.3.18.0.2.4.1137 >>> NAME 'printer-generated-natural-language-supported' >>> DESC 'One of the natural languages supported for this directory >>> entry.' >>> >>> Again, I am not entirely sure how this is used. Can you clarify? >> >> > > Same description problem as the previous attribute (it really refers to > the supported values of the underlying IPP/1.1 (RFC 2911) attribute). > We'll rewrite this description to clarify the usage. > > > Excellent. > > > >> >> 4.20. printer-number-up-supported >>> ( 1.3.18.0.2.4.1124 >>> NAME 'printer-number-up-supported' >>> DESC 'Maximum number of print-stream pages that can be imposed upon a >>> single side of an instance of selected medium by this Printer.' >>> EQUALITY integerMatch >>> ORDERING integerOrderingMatch >>> SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 >>> ) >>> >>> This is not defined as single-valued. What is the meaning of multiple >> values? >> >> > > Oops. This is an RFC 3712 bug. The underlying IPP/1.1 (RFC 2911) > attribute > has a complex syntax of "1setOf (integer (1:MAX)" or "rangeOfInteger > (1:MAX)". > We intended to flatten it in the LDAP Printer Schema to the simple maximum. > I think we should delete the erroneous ORDERING clause. > OK? > > > Ok. So are you going to make it single-valued then? > > > >> >> 4.35. printer-device-id >>> ( 1.3.18.0.2.24.46.1.101 >>> NAME 'printer-device-id' >>> DESC 'The IEEE 1284 Device ID for this Printer.' >>> EQUALITY caseIgnoreMatch >>> SUBSTR caseIgnoreSubstringsMatch >>> SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{255} >>> ) >>> Values of this attribute SHOULD conform to IEEE-ISTO PWG Command >>> Set >>> Format for IEEE 1284 Device ID [PWG5107.2]. >>> Note: For interoperatibility, values of this attribute SHOULD >>> include key/value pairs in the following order: (a) all required >>> key/value pairs (i.e., MANUFACTURER/MFG, MODEL/MDL, and COMMAND >>> SET/CMD); (b) all optional key/value pairs; and (c) all vendor >>> key/value pairs. >>> >>> How does the advice on ordering interacts with multiple values of the >> attribute? LDAP multivalued attributes have no ordering of values. >> >> > > The ordering advice is for the three keywords that are mandatory in the > source > IEEE 1284 standard. I suggest that we simply delete the "Note" clause > that is > already covered in much greater detail in PWG 5107.2 with a rationale > (which > is the preservation of the three mandatory keywords when string truncation > may > occur in various other directory and service location protocols). > OK? > > > Sounds sensible. > > > >> >> printer-device-id 1.3.18.0.2.24.46.1.101 >> printer-device-service-count 1.3.18.0.2.24.46.1.102 >> printer-uuid 1.3.18.0.2.24.46.1.104 >> printer-charge-info 1.3.18.0.2.24.46.1.105 >> printer-charge-info-uri 1.3.18.0.2.24.46.1.106 >> printer-geo-location 1.3.18.0.2.24.46.1.107 >> printer-ipp-features-supported 1.3.18.0.2.24.46.1.108 >> >> This is not necessarily a problem, but I couldn't find a registration for >> the 1.3.18.0.2.24 OID. The parent OID is owned by IBM. >> >> > > In October 2011, IBM permanently assigned this base OID to IEEE-ISTO PWG > for use in the LDAP Printer Schema and any other future PWG standard that > needed an ASN.1 OID (which wouldn't be covered by the PWG's SMI arc). > We'll add a labelled section (to show up in Table of Contents) to document > this > assignment. > > > Perfect, thank you. > > > >> >> 13. Appendix X - Change History >> >> [ [RFC Editor: This section to be deleted before RFC publication] ] >> >> -bis document are required to include "Changes since RFC XXXX" section. >> So you should replace this Appendix with another one that details changes >> since RFC 3712. >> >> > > We'll add a new permanent appendix for "Changes since RFC 3712". > We prefer to leave the Change History appendix until final publication > as an RFC, to document the serpentine path to the final text and to > acknowledge specific contributions that led to draft changes. > OK? > > > What you suggest is fine! > > Best Regards, > Alexey > > > > >> Best Regards, >> Alexey >> >> >> --001a11332dbc1b356004ed190606 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Alexey,

Thanks for your lightnin= g fast response/

I just realized that I got on= e thing wrong, I think.=A0 Pat Fleming's the LDAP
expert and I'm= the IPP expert in this team.

The attribute "printer-number-up-supported' was alw= ays meant to be
single-valued (which is implied by its description).=A0= So, to be consistent
with "printer-pages-per-minute" and oth= ers, I think I should *keep* the
ORDERING clause but add the accidentally missing SINGLE-VALUE
clause.=A0= Is that right?

I will also proof-read the whole list of = attributes again before the next draft
and make sure=A0 that = there are no other missing SINGLE-VALUE clauses.

Cheers,
- Ira

Ira McDonald (Musicia= n / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
= Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Int= ernet Printing Protocol WG
IETF Designated Expert - IPP & Printer MI= B
Blue Roof Music / High North Inc
http:= //sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthincmailto: blue= roofmusic@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 Mon, Dec 9, 2013 at 2:59 AM, Alexey M= elnikov <alexey.melnikov@isode.com> wrote:
Hi Ira,
I've deleted your replies wher= e we are in agreement and I have no further comments.

On 8 Dec 2013, at 18:08, Ira McDonald <blueroofmusic@gmail.com> wrote:

4. =A0Definition of Attribute Types

=A0 =A0The following attribute types reference matching rule names (instead=
=A0 =A0of OIDs) for clarity (see Section 6 below). =A0For optional attribut= es,
=A0 =A0if the Printer information is not known, the attribute value SHOULD<= br> =A0 =A0not be set. =A0In the following definitions, referenced matching rul= es
=A0 =A0are defined in Section 4 of [RFC4517] (see Section 6 'Definition= of
=A0 =A0Matching Rules' below).


I think you still meant section 4.


Ah, that is fine.
=A0[...]


=A0 =A0 4.12. =A0printer-charset-supported
=A0 =A0 =A0 =A0 ( 1.3.18.0.2.4.1131
=A0 =A0 NAME 'printer-charset-supported'
=A0 =A0 DESC 'One of the charsets supported for the attribute values of=
=A0 =A0 =A0 =A0 =A0 syntax DirectoryString for this directory entry.'
I don't understand this description. DirectoryString is always in UTF-8= .


<ira>
= Oops.=A0 We'll fix the description to refer (as intended) to the underl= ying
IPP/1.1 (RFC 2911) corresponding attribute which does allow lega= cy
character sets (although they are discouraged) and to rest= ate that the
values of DirectoryString in this LDAP Schema MU= ST always be UTF-8.

Much better, thank you.
=

</ira>

=A0 =A04.13. =A0printer-generated-natural-language-supported
=A0 =A0 =A0 =A0 ( 1.3.18.0.2.4.1137
=A0 =A0 NAME 'printer-generated-natural-language-supported'<= br> =A0 =A0 DESC 'One of the natural languages supported for this directory=
=A0 =A0 =A0 =A0 =A0 entry.'

Again, I am not entirely sure how this is used. Can you clarify?


<ira>
Same descrip= tion problem as the previous attribute (it really refers to
the supporte= d values of the underlying IPP/1.1 (RFC 2911) attribute).
We'll rewrite this description to clarify the usage.

Excellent.

</ira>

=A0 =A04.20. =A0printer-number-up-supported
=A0 =A0 =A0 =A0 ( 1.3.18.0.2.4.1124
=A0 =A0 NAME 'printer-number-up-supported'
=A0 =A0 DESC 'Maximum number of print-stream pages that can be imposed = upon a
=A0 =A0 =A0 =A0 =A0 single side of an instance of selected medium by this P= rinter.'
=A0 =A0 EQUALITY integerMatch
=A0 =A0 ORDERING integerOrderingMatch
=A0 =A0 SYNTAX =A01.3.6.1.4.1.1466.115.121.1.27
=A0 =A0 )

This is not defined as single-valued. What is the meaning of multiple value= s?


<ira>
Oops.=A0 This is an RFC 3712 bug.=A0 The underlying IPP/1.1 (RFC 2911) att= ribute
has a complex syntax of "1setOf (integer (1:MAX)" or &= quot;rangeOfInteger (1:MAX)".
We intended to flatten it = in the LDAP Printer Schema to the simple maximum.
I think we = should delete the erroneous ORDERING clause.
OK?

Ok. So are = you going to make it single-valued then?

</ira>

=A0 =A0 4.35. =A0printer-device-id
=A0 =A0 =A0 =A0 ( 1.3.18.0.2.24.46.1.101
=A0 =A0 NAME 'printer-device-id'
=A0 =A0 DESC 'The IEEE 1284 Device ID for this Printer.'
=A0 =A0 EQUALITY caseIgnoreMatch
=A0 =A0 SUBSTR caseIgnoreSubstringsMatch
=A0 =A0 SYNTAX =A01.3.6.1.4.1.1466.115.121.1.15{255}
=A0 =A0 )
=A0 =A0 =A0 =A0 Values of this attribute SHOULD conform to IEEE-ISTO PWG Co= mmand Set
=A0 =A0 Format for IEEE 1284 Device ID [PWG5107.2].
=A0 =A0 =A0 =A0 Note: =A0For interoperatibility, values of this attribute S= HOULD
=A0 =A0 include key/value pairs in the following order: =A0(a) all required=
=A0 =A0 key/value pairs (i.e., MANUFACTURER/MFG, MODEL/MDL, and COMMAND
=A0 =A0 SET/CMD); (b) all optional key/value pairs; and (c) all vendor
=A0 =A0 key/value pairs.

How does the advice on ordering interacts with multiple values of the attri= bute? LDAP multivalued attributes have no ordering of values.


<ira>
The ordering ad= vice is for the three keywords that are mandatory in the source
IEEE 1284 standard.=A0 I suggest that we simply delete the "= ;Note" clause that is
already covered in much greater de= tail in PWG 5107.2 with a rationale (which
is the preservatio= n of the three mandatory keywords when string truncation may
occur in various other directory and service location protocols)= .
OK?

Sounds= sensible.

</ira>

</ira>

13. =A0Appendix X - Change History

=A0 =A0[ [RFC Editor: =A0This section to be deleted before RFC publication]= ]

-bis document are required to include "Changes since RFC XXXX" se= ction. So you should replace this Appendix with another one that details ch= anges since RFC 3712.


<ir= a>
We'll add a new permanent appendix for "Changes since R= FC 3712".
We prefer to leave the Change History appendix= until final publication
as an RFC, to document the serpentine path to t= he final text and to
acknowledge specific contributions that led to draft changes.
OK?

What you suggest is f= ine!


--001a11332dbc1b356004ed190606-- From mmn@hethane.se Mon Dec 9 06:01:25 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B4B11AE2EA for ; Mon, 9 Dec 2013 06:01:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.347 X-Spam-Level: X-Spam-Status: No, score=0.347 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LiBXgbR4-Vej for ; Mon, 9 Dec 2013 06:01:23 -0800 (PST) Received: from smtp.hethane.se (hethane.se [85.11.25.76]) by ietfa.amsl.com (Postfix) with ESMTP id 32EE31AE2E3 for ; Mon, 9 Dec 2013 06:01:22 -0800 (PST) From: Mikael Nordfeldth To: Apps Discuss X-Mailer: Modest 3.90.7 References: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-ID: <1386597672.16544.4.camel@Nokia-N900> Date: Mon, 09 Dec 2013 15:01:12 +0100 Message-Id: <1386597672.16544.5.camel@Nokia-N900> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: Re: [apps-discuss] well-known location for uuids X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Mikael Nordfeldth List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 14:01:25 -0000 On Mon,  2 Dec 2013, 12:15:11 CET, Melvin Carvalho wrote: > Currently there is urn:uuid: as a URN but not simple way to translate > this to a URL > > Could we maybe just add /.well-known/uuid/  ? If we're gonna make a HTTP resource anyway, why not just use the already specified WebFinger, which allows you to lookup any URI resource through https://example.com/.well-known/webfinger?resource=urn:uuid:myuniquehash HTTPS without the S was of course dropped during WebFinger discussions for some reason, so this wouldn't solve unencrypted URL lookups though... -- Mikael Nordfeldth XMPP/mail: mmn@hethane.se From alexey.melnikov@isode.com Mon Dec 9 07:11:05 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 390CB1ADF57 for ; Mon, 9 Dec 2013 07:11:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3HVHtw5s-Dxn for ; Mon, 9 Dec 2013 07:11:01 -0800 (PST) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 8AA5A1AE2DB for ; Mon, 9 Dec 2013 07:11:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1386601854; d=isode.com; s=selector; i=@isode.com; bh=C3INUrC24k6oYFdqp+EmAPbS2hP8oVMft/WBAJi3KmA=; 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=qTQPUl0F/FXEwToW3K+ZUL3JCAQirToH+HfuZ/EC0pnTv9OjGatBugLbMUbYST6yJ06KC/ 9krZDOv55kd8lWp0OiMq/Pe9oFS2cyAcLhn4sANaJVmsO9YGOTG3lAqVplyXoKO331HTmx 4l/1o/7+zY4duSxyo7Tvu8hZ1Lb5NN8=; Received: from [172.17.128.75] (richard.isode.com [62.3.217.249]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 9 Dec 2013 15:10:54 +0000 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <52A5DD7E.1090600@isode.com> Date: Mon, 09 Dec 2013 15:10:54 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 To: Ira McDonald References: <528A3430.6080900@isode.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------070308030209060604000005" Cc: Pat Fleming , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] AppsDir review of draft-mcdonald-ldap-printer-schema-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 15:11:05 -0000 This is a multi-part message in MIME format. --------------070308030209060604000005 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 09/12/2013 12:20, Ira McDonald wrote: > Hi Alexey, Hi Ira, > Thanks for your lightning fast response/ > > I just realized that I got one thing wrong, I think. Pat Fleming's > the LDAP > expert and I'm the IPP expert in this team. > > The attribute "printer-number-up-supported' was always meant to be > single-valued (which is implied by its description). So, to be > consistent > with "printer-pages-per-minute" and others, I think I should *keep* the > ORDERING clause but add the accidentally missing SINGLE-VALUE > clause. Is that right? Yes. > I will also proof-read the whole list of attributes again before the > next draft > and make sure that there are no other missing SINGLE-VALUE clauses. Sounds great to me, thank you! > > Cheers, > - Ira > > Ira McDonald (Musician / Software Architect) > Co-Chair - TCG Trusted Mobility Solutions WG > Chair - Linux Foundation Open Printing WG > Secretary - IEEE-ISTO Printer Working Group > Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG > IETF Designated Expert - IPP & Printer MIB > Blue Roof Music / High North Inc > http://sites.google.com/site/blueroofmusic > http://sites.google.com/site/highnorthinc > mailto: blueroofmusic@gmail.com > Winter 579 Park Place Saline, MI 48176 734-944-0094 > Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 > > > > On Mon, Dec 9, 2013 at 2:59 AM, Alexey Melnikov > > wrote: > > Hi Ira, > I've deleted your replies where we are in agreement and I have no > further comments. > > On 8 Dec 2013, at 18:08, Ira McDonald > wrote: > >> 4. Definition of Attribute Types >> >> The following attribute types reference matching rule >> names (instead >> of OIDs) for clarity (see Section 6 below). For >> optional attributes, >> if the Printer information is not known, the attribute >> value SHOULD >> not be set. In the following definitions, referenced >> matching rules >> are defined in Section 4 of [RFC4517] (see Section 6 >> 'Definition of >> Matching Rules' below). >> >> >> I think you still meant section 4. >> >> >> >> Actually it should be a forward reference to section 6 of this >> document, >> but we'll clarify the wording in the next draft, e.g., to >> "...Section 4 of [RFC4517] and discussed in Section 6 ' Definition of >> Matching Rules' later in this document." >> OK? >> > > Ah, that is fine. > [...] > >> >> 4.12. printer-charset-supported >> ( 1.3.18.0.2.4.1131 >> NAME 'printer-charset-supported' >> DESC 'One of the charsets supported for the attribute >> values of >> syntax DirectoryString for this directory entry.' >> >> I don't understand this description. DirectoryString is >> always in UTF-8. >> >> >> >> Oops. We'll fix the description to refer (as intended) to the >> underlying >> IPP/1.1 (RFC 2911) corresponding attribute which does allow legacy >> character sets (although they are discouraged) and to restate >> that the >> values of DirectoryString in this LDAP Schema MUST always be UTF-8. > > Much better, thank you. > >> > >> 4.13. printer-generated-natural-language-supported >> ( 1.3.18.0.2.4.1137 >> NAME 'printer-generated-natural-language-supported' >> DESC 'One of the natural languages supported for this >> directory >> entry.' >> >> Again, I am not entirely sure how this is used. Can you clarify? >> >> >> >> Same description problem as the previous attribute (it really >> refers to >> the supported values of the underlying IPP/1.1 (RFC 2911) attribute). >> We'll rewrite this description to clarify the usage. > > Excellent. > >> >> >> >> 4.20. printer-number-up-supported >> ( 1.3.18.0.2.4.1124 >> NAME 'printer-number-up-supported' >> DESC 'Maximum number of print-stream pages that can >> be imposed upon a >> single side of an instance of selected medium >> by this Printer.' >> EQUALITY integerMatch >> ORDERING integerOrderingMatch >> SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 >> ) >> >> This is not defined as single-valued. What is the meaning of >> multiple values? >> >> >> >> Oops. This is an RFC 3712 bug. The underlying IPP/1.1 (RFC >> 2911) attribute >> has a complex syntax of "1setOf (integer (1:MAX)" or >> "rangeOfInteger (1:MAX)". >> We intended to flatten it in the LDAP Printer Schema to the >> simple maximum. >> I think we should delete the erroneous ORDERING clause. >> OK? > > Ok. So are you going to make it single-valued then? > >> >> >> >> 4.35. printer-device-id >> ( 1.3.18.0.2.24.46.1.101 >> NAME 'printer-device-id' >> DESC 'The IEEE 1284 Device ID for this Printer.' >> EQUALITY caseIgnoreMatch >> SUBSTR caseIgnoreSubstringsMatch >> SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{255} >> ) >> Values of this attribute SHOULD conform to >> IEEE-ISTO PWG Command Set >> Format for IEEE 1284 Device ID [PWG5107.2]. >> Note: For interoperatibility, values of this >> attribute SHOULD >> include key/value pairs in the following order: (a) >> all required >> key/value pairs (i.e., MANUFACTURER/MFG, MODEL/MDL, >> and COMMAND >> SET/CMD); (b) all optional key/value pairs; and (c) >> all vendor >> key/value pairs. >> >> How does the advice on ordering interacts with multiple >> values of the attribute? LDAP multivalued attributes have no >> ordering of values. >> >> >> >> The ordering advice is for the three keywords that are mandatory >> in the source >> IEEE 1284 standard. I suggest that we simply delete the "Note" >> clause that is >> already covered in much greater detail in PWG 5107.2 with a >> rationale (which >> is the preservation of the three mandatory keywords when string >> truncation may >> occur in various other directory and service location protocols). >> OK? > > Sounds sensible. > >> >> >> >> printer-device-id 1.3.18.0.2.24.46.1.101 >> printer-device-service-count 1.3.18.0.2.24.46.1.102 >> printer-uuid 1.3.18.0.2.24.46.1.104 >> printer-charge-info 1.3.18.0.2.24.46.1.105 >> printer-charge-info-uri 1.3.18.0.2.24.46.1.106 >> printer-geo-location 1.3.18.0.2.24.46.1.107 >> printer-ipp-features-supported 1.3.18.0.2.24.46.1.108 >> >> This is not necessarily a problem, but I couldn't find a >> registration for the 1.3.18.0.2.24 OID. The parent OID is >> owned by IBM. >> >> >> >> In October 2011, IBM permanently assigned this base OID to >> IEEE-ISTO PWG >> for use in the LDAP Printer Schema and any other future PWG >> standard that >> needed an ASN.1 OID (which wouldn't be covered by the PWG's SMI >> arc). >> We'll add a labelled section (to show up in Table of Contents) to >> document this >> assignment. > > Perfect, thank you. > >> >> >> >> 13. Appendix X - Change History >> >> [ [RFC Editor: This section to be deleted before RFC >> publication] ] >> >> -bis document are required to include "Changes since RFC >> XXXX" section. So you should replace this Appendix with >> another one that details changes since RFC 3712. >> >> >> >> We'll add a new permanent appendix for "Changes since RFC 3712". >> We prefer to leave the Change History appendix until final >> publication >> as an RFC, to document the serpentine path to the final text and to >> acknowledge specific contributions that led to draft changes. >> OK? > > What you suggest is fine! > > Best Regards, > Alexey >> >> >> Best Regards, >> Alexey >> >> > --------------070308030209060604000005 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 09/12/2013 12:20, Ira McDonald wrote:
Hi Alexey,
Hi Ira,

Thanks for your lightning fast response/

I just realized that I got one thing wrong, I think.  Pat Fleming's the LDAP
expert and I'm the IPP expert in this team.

The attribute "printer-number-up-supported' was always meant to be
single-valued (which is implied by its description).  So, to be consistent
with "printer-pages-per-minute" and others, I think I should *keep* the
ORDERING clause but add the accidentally missing SINGLE-VALUE
clause.  Is that right?
Yes.

I will also proof-read the whole list of attributes again before the next draft
and make sure  that there are no other missing SINGLE-VALUE clauses.
Sounds great to me, thank you!

Cheers,
- Ira

On Mon, Dec 9, 2013 at 2:59 AM, Alexey Melnikov <alexey.melnikov@isode.com> wrote:
Hi Ira,
I've deleted your replies where we are in agreement and I have no further comments.

On 8 Dec 2013, at 18:08, Ira McDonald <blueroofmusic@gmail.com> wrote:

4.  Definition of Attribute Types

   The following attribute types reference matching rule names (instead
   of OIDs) for clarity (see Section 6 below).  For optional attributes,
   if the Printer information is not known, the attribute value SHOULD
   not be set.  In the following definitions, referenced matching rules
   are defined in Section 4 of [RFC4517] (see Section 6 'Definition of
   Matching Rules' below).


I think you still meant section 4.


<ira>
Actually it should be a forward reference to section 6 of this document,
but we'll clarify the wording in the next draft, e.g., to
"...Section 4 of [RFC4517] and discussed in Section 6 ' Definition of
Matching Rules' later in this document."
OK?
</ira>

Ah, that is fine.
 [...]


    4.12.  printer-charset-supported
        ( 1.3.18.0.2.4.1131
    NAME 'printer-charset-supported'
    DESC 'One of the charsets supported for the attribute values of
          syntax DirectoryString for this directory entry.'

I don't understand this description. DirectoryString is always in UTF-8.


<ira>
Oops.  We'll fix the description to refer (as intended) to the underlying
IPP/1.1 (RFC 2911) corresponding attribute which does allow legacy
character sets (although they are discouraged) and to restate that the
values of DirectoryString in this LDAP Schema MUST always be UTF-8.

Much better, thank you.

</ira>

   4.13.  printer-generated-natural-language-supported
        ( 1.3.18.0.2.4.1137
    NAME 'printer-generated-natural-language-supported'
    DESC 'One of the natural languages supported for this directory
          entry.'

Again, I am not entirely sure how this is used. Can you clarify?


<ira>
Same description problem as the previous attribute (it really refers to
the supported values of the underlying IPP/1.1 (RFC 2911) attribute).
We'll rewrite this description to clarify the usage.

Excellent.

</ira>

   4.20.  printer-number-up-supported
        ( 1.3.18.0.2.4.1124
    NAME 'printer-number-up-supported'
    DESC 'Maximum number of print-stream pages that can be imposed upon a
          single side of an instance of selected medium by this Printer.'
    EQUALITY integerMatch
    ORDERING integerOrderingMatch
    SYNTAX  1.3.6.1.4.1.1466.115.121.1.27
    )

This is not defined as single-valued. What is the meaning of multiple values?


<ira>
Oops.  This is an RFC 3712 bug.  The underlying IPP/1.1 (RFC 2911) attribute
has a complex syntax of "1setOf (integer (1:MAX)" or "rangeOfInteger (1:MAX)".
We intended to flatten it in the LDAP Printer Schema to the simple maximum.
I think we should delete the erroneous ORDERING clause.
OK?

Ok. So are you going to make it single-valued then?

</ira>

    4.35.  printer-device-id
        ( 1.3.18.0.2.24.46.1.101
    NAME 'printer-device-id'
    DESC 'The IEEE 1284 Device ID for this Printer.'
    EQUALITY caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX  1.3.6.1.4.1.1466.115.121.1.15{255}
    )
        Values of this attribute SHOULD conform to IEEE-ISTO PWG Command Set
    Format for IEEE 1284 Device ID [PWG5107.2].
        Note:  For interoperatibility, values of this attribute SHOULD
    include key/value pairs in the following order:  (a) all required
    key/value pairs (i.e., MANUFACTURER/MFG, MODEL/MDL, and COMMAND
    SET/CMD); (b) all optional key/value pairs; and (c) all vendor
    key/value pairs.

How does the advice on ordering interacts with multiple values of the attribute? LDAP multivalued attributes have no ordering of values.


<ira>
The ordering advice is for the three keywords that are mandatory in the source
IEEE 1284 standard.  I suggest that we simply delete the "Note" clause that is
already covered in much greater detail in PWG 5107.2 with a rationale (which
is the preservation of the three mandatory keywords when string truncation may
occur in various other directory and service location protocols).
OK?

Sounds sensible.

</ira>

   printer-device-id                             1.3.18.0.2.24.46.1.101
   printer-device-service-count                  1.3.18.0.2.24.46.1.102
   printer-uuid                                  1.3.18.0.2.24.46.1.104
   printer-charge-info                           1.3.18.0.2.24.46.1.105
   printer-charge-info-uri                       1.3.18.0.2.24.46.1.106
   printer-geo-location                          1.3.18.0.2.24.46.1.107
   printer-ipp-features-supported                1.3.18.0.2.24.46.1.108

This is not necessarily a problem, but I couldn't find a registration for the 1.3.18.0.2.24 OID. The parent OID is owned by IBM.


<ira>
In October 2011, IBM permanently assigned this base OID to IEEE-ISTO PWG
for use in the LDAP Printer Schema and any other future PWG standard that
needed an ASN.1 OID (which wouldn't be covered by the PWG's SMI arc).
We'll add a labelled section (to show up in Table of Contents) to document this
assignment.

Perfect, thank you.

</ira>

13.  Appendix X - Change History

   [ [RFC Editor:  This section to be deleted before RFC publication] ]

-bis document are required to include "Changes since RFC XXXX" section. So you should replace this Appendix with another one that details changes since RFC 3712.


<ira>
We'll add a new permanent appendix for "Changes since RFC 3712".
We prefer to leave the Change History appendix until final publication
as an RFC, to document the serpentine path to the final text and to
acknowledge specific contributions that led to draft changes.
OK?

What you suggest is fine!

Best Regards,
Alexey
</ira>
 
Best Regards,
Alexey




--------------070308030209060604000005-- From superuser@gmail.com Mon Dec 9 08:07:34 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 768D41AE247 for ; Mon, 9 Dec 2013 08:07:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w0ezpwXh_ZRf for ; Mon, 9 Dec 2013 08:07:32 -0800 (PST) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 95AFA1ADF73 for ; Mon, 9 Dec 2013 08:07:32 -0800 (PST) Received: by mail-we0-f182.google.com with SMTP id q59so3699483wes.13 for ; Mon, 09 Dec 2013 08:07:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gi36dWN/k5NB0PgC+YdwVyC365LUhYwX5bDVxVb5oZs=; b=DRwGCO1PProRTvda4UoWer0jEtvri8k0i1rYcjdMf60AwhSxl3AuPe0SBW5S21iq3H qv3dPhWAGgzpA/4ZcaDVp0mkmQw+K2aGBzYcWQ/A12hG7VoD8A12XS/eaR9Zxh9WhG5P /HorEUQyYKasAfTRctxAkg0NUrEzCo9c9WypwzTltDC8V3om1Q+Wgke9EftVmFMQZnSR nVVg3r5cs2O1v+7tjYH1YuOeyqyzAgKrP4wHZy4/rsOmIVmsM/b+m3WbRlxV/JWa4jK3 AEf4OfhXdd9GyAjRCK0YRF/AxrDGxtf4TcUkS1b4MhJdn+iCiiYf+9482t4Llcm4OUbf xHrg== MIME-Version: 1.0 X-Received: by 10.180.75.202 with SMTP id e10mr14712293wiw.8.1386605247268; Mon, 09 Dec 2013 08:07:27 -0800 (PST) Received: by 10.181.13.230 with HTTP; Mon, 9 Dec 2013 08:07:26 -0800 (PST) In-Reply-To: <1386130917.78002.YahooMailNeo@web125601.mail.ne1.yahoo.com> References: <20131120080026.25156.23231.idtracker@ietfa.amsl.com> <52975509.4070401@isode.com> <1386130917.78002.YahooMailNeo@web125601.mail.ne1.yahoo.com> Date: Mon, 9 Dec 2013 08:07:26 -0800 Message-ID: From: "Murray S. Kucherawy" To: Bill Mills Content-Type: multipart/alternative; boundary=f46d0438956935167c04ed1c3116 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rrvs-header-field-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 16:07:34 -0000 --f46d0438956935167c04ed1c3116 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Dec 3, 2013 at 8:21 PM, Bill Mills wrote: > Section 3.1: is an explicit BNF syntax required for the IANA > registration? Or is "RRVS=" + date-time implicit from the definition in > 5321? > The other examples I've seen don't appear to require anything beyond what we already have. > Section 3.2 "CFWS" is defined but not referred to anywhere else? > Fixed in -05. > > Section 5.3: I think #3 is only appropriate if #2 fired, should #3 > actually be 2.1? > > There isn't a 5.3 in the -04 (current) version. Can you clarify? I'll post -05 shortly, unless this last point needs followup. -MSK --f46d0438956935167c04ed1c3116 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Dec 3, 2013 at 8:21 PM, Bill Mills <wmills@yah= oo-inc.com> wrote:
Section 3.1: = is an explicit BNF syntax required for the IANA registration?=A0 Or is &quo= t;RRVS=3D" + date-time implicit from the definition in 5321?

The other example= s I've seen don't appear to require anything beyond what we already= have.
=A0
Section 3.2 "CFWS" is defined but not referred to anywhere = else?

Fixed in -05= .

=A0

Section 5.3:=A0 I think #3 is only appropriate if #2 fired, shoul= d #3 actually be 2.1?


There isn't a 5.3 in the -04 (current) version.=A0 Can you clar= ify?

I'll post -05 shortly, unless this last point needs foll= owup.

-MSK
--f46d0438956935167c04ed1c3116-- From wmills@yahoo-inc.com Mon Dec 9 08:15:19 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E4831ADFA9 for ; Mon, 9 Dec 2013 08:15:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.92 X-Spam-Level: X-Spam-Status: No, score=-16.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779, USER_IN_DEF_WHITELIST=-15] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4PZzRNc-OIdy for ; Mon, 9 Dec 2013 08:15:16 -0800 (PST) Received: from mrout2.yahoo.com (mrout2.yahoo.com [216.145.54.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4D6241ADF73 for ; Mon, 9 Dec 2013 08:15:16 -0800 (PST) Received: from GQ1-EX10-CAHT18.y.corp.yahoo.com (gq1-ex10-caht18.corp.gq1.yahoo.com [10.73.119.199]) by mrout2.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id rB9GEfkZ015649 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 9 Dec 2013 08:14:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1386605682; bh=VHCmJDgMQE6RFiNpvmpG9Z398Hc7vf1ARyUT0zGA0eM=; h=References:Message-ID:Date:From:Reply-To:Subject:To:CC: In-Reply-To:MIME-Version:Content-Type; b=XWOG4N4uvfL8igdqUEsZHmnTEll13900mF5Jp+1v/xwTMcNzjZM5Kjwy/YK5nFhEO CPHvkFrEOGumw7HYyRTMeQJ6r6rO3oLiSxFhI69icr9Rz4Gm1aovO76HqPZcbNsd4w MTgWO5A0MAP0VhA1r9Y9qx4TNU9LZ/09k6Jw7+lk= Received: from omp1005.mail.ne1.yahoo.com (98.138.87.5) by GQ1-EX10-CAHT18.y.corp.yahoo.com (10.72.228.24) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 9 Dec 2013 08:14:41 -0800 Received: (qmail 44637 invoked by uid 1000); 9 Dec 2013 16:14:40 -0000 Received: (qmail 84932 invoked by uid 60001); 9 Dec 2013 16:14:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1386605680; bh=CHMxCzzRmnVA2uDcBKpUJ+bKyuFTIF3O/YshWNWnzVI=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=axBkfefK3ni0oMTodKd8kCu2oqfJ9FciyHLer7sVpCAyF2H4ZEFSg9zL8FisPLvBNBKIXmvkz7dOSNXoQANTIuSWQFmhHhb/iIjg4HQTtnu7YqFWYHL/ppiTzbliR0DnO7Fw7PjMeycYVmIWccWqyRJ9E2u8L+3DqAhlTgL4ChA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=kPNTC2HuQJWfBIGEunnkE80ga/q/gkj9zICxVLFSiutcodjk7PypZGKTRcyQB4W5xFa5evO7GWz1HsifzpJxiBkamOXv2hw1mABVYbtOaVy0JXdpUomROCwLoMsPo38J9KJDU9W17UxyWGI1vDW+RVnZexYFUoAE04GzU/8jRTA=; X-YMail-OSG: 8bHVYEAVM1kD6bHLfRbGDAJAxz9TDZxFo8sWShw9dAWxGcm TBWrI9vbnMoLCx_V5O3La9z5jFTFUdq.1sZJWOuAOPTHd658tvRS5cRKgaVS 8BAp.KnpcNlSEwrHQGgDqLdYUcbM.ZwY0y9S1BavSxokEvl5htDyIfWAYgY9 iOEfbP2NZb5PsPNLzaL2YoHNNGAaaQtISOsV0kjjTxt2aPqpGk.ylqEcgdNC kdOuT4N7eSAjxxCW4s3uDOpgsLKoj5tyr2ISScXdqzb0tab6l6hlZ5E3Kfge 3bgiYSUAfgVcDdCrTbm_0iR5bS2JY_RAX0ro- Received: from [209.131.62.115] by web125602.mail.ne1.yahoo.com via HTTP; Mon, 09 Dec 2013 08:14:40 PST X-Rocket-MIMEInfo: 002.001, VGhhdCBzaG91bGQgaGF2ZSBiZWVuIDUuMSBub3QgNS4zLgoKCsKgCi1iaWxsCgoKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCldpbGxpYW0gSi4gTWlsbHMKIlBhcmFub2lkIiBZYWhvbyEKCgoKCgpPbiBNb25kYXksIERlY2VtYmVyIDksIDIwMTMgODowOCBBTSwgTXVycmF5IFMuIEt1Y2hlcmF3eSA8c3VwZXJ1c2VyQGdtYWlsLmNvbT4gd3JvdGU6CiAKT24gVHVlLCBEZWMgMywgMjAxMyBhdCA4OjIxIFBNLCBCaWxsIE1pbGxzIDx3bWlsbHNAeWFob28taW5jLmNvbT4gd3JvdGU6CgpTZWN0aW8BMAEBAQE- X-Mailer: YahooMailWebService/0.8.169.609 References: <20131120080026.25156.23231.idtracker@ietfa.amsl.com> <52975509.4070401@isode.com> <1386130917.78002.YahooMailNeo@web125601.mail.ne1.yahoo.com> Message-ID: <1386605680.43696.YahooMailNeo@web125602.mail.ne1.yahoo.com> Date: Mon, 9 Dec 2013 08:14:40 -0800 From: Bill Mills To: "Murray S. Kucherawy" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1088529044-1592113456-1386605680=:43696" X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 605682000 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rrvs-header-field-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 16:15:19 -0000 ---1088529044-1592113456-1386605680=:43696 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable That should have been 5.1 not 5.3.=0A=0A=0A=A0=0A-bill=0A=0A=0A=0A---------= -----------------------=0AWilliam J. Mills=0A"Paranoid" Yahoo!=0A=0A=0A=0A= =0A=0AOn Monday, December 9, 2013 8:08 AM, Murray S. Kucherawy wrote:=0A =0AOn Tue, Dec 3, 2013 at 8:21 PM, Bill Mills wrote:=0A=0ASection 3.1: is an explicit BNF syntax required f= or the IANA registration?=A0 Or is "RRVS=3D" + date-time implicit from the = definition in 5321?=0A>=0A=0AThe other examples I've seen don't appear to r= equire anything beyond what we already have.=0A=A0=0A=0ASection 3.2 "CFWS" = is defined but not referred to anywhere else?=0A=0AFixed in -05.=0A=0A=0A= =A0=0A=0A=0A>Section 5.3:=A0 I think #3 is only appropriate if #2 fired, sh= ould #3 actually be 2.1?=0A>=0A=0AThere isn't a 5.3 in the -04 (current) ve= rsion.=A0 Can you clarify? =0A=0A=0AI'll post -05 shortly, unless this last= point needs followup.=0A=0A=0A-MSK ---1088529044-1592113456-1386605680=:43696 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
That shou= ld have been 5.1 not 5.3.

 
<= div>-bill


--------------------------------
William J. Mills<= br>"Paranoid" Yahoo!



On Monday, December 9, 2013 8:08 AM, Murray S. Kucherawy <superu= ser@gmail.com> wrote:
On Tue, Dec 3, 2013 at 8:21 PM,= Bill Mills <wmills@yahoo-inc.com> wrote:
=
=0A
Section 3.1: is an explicit BNF syntax required for the IANA = registration?  Or is "RRVS=3D" + date-time implicit from the definitio= n in 5321?
=0A
=
The other examples I've seen don't appear to = require anything beyond what we already have.
 
=0A
=0ASection 3.2 "CFWS" is defin= ed but not referred to anywhere else?
=

Fixed in -05.


 
=0A
=0A
Sec= tion 5.3:  I think #3 is only appropriate if #2 fired, should #3 actua= lly be 2.1?

<= div>
There isn't a 5.3 in the -04 (current) ve= rsion.  Can you clarify?
=0A
I'll post -05 shortly, unless this last point needs followup.

-MSK

=


<= /body> ---1088529044-1592113456-1386605680=:43696-- From alexey.melnikov@isode.com Mon Dec 9 08:57:16 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A4AC1ADFDA for ; Mon, 9 Dec 2013 08:57:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vosanVuZZChL for ; Mon, 9 Dec 2013 08:57:14 -0800 (PST) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 998791ADFCD for ; Mon, 9 Dec 2013 08:57:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1386608228; d=isode.com; s=selector; i=@isode.com; bh=EV8zA8ZlvZWds4WCBPrdAP39JO527sy4WntQmoHLFzk=; 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=wZuwVgPQNyllB9NMc2bF1Ynj/Z6wyCyR3pf6tc/Se3thDor2jOTFjOmBQ/grGLKx6HrurK o5KVO+/lNmSiRJx1STwVAw+j1R8FFSJVLzQAxsyZE5myDrYczCBQ1CU16Gi8+4aWkBVE/v 9dr/1Ras+TW5nClsFQBFnSATlHpfSMQ=; Received: from [172.17.128.75] (richard.isode.com [62.3.217.249]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 9 Dec 2013 16:57:08 +0000 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <52A5F663.2080803@isode.com> Date: Mon, 09 Dec 2013 16:57:07 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 To: "Murray S. Kucherawy" References: <20131120080026.25156.23231.idtracker@ietfa.amsl.com> <52975509.4070401@isode.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------090807010307060205000205" Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rrvs-header-field-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 16:57:16 -0000 This is a multi-part message in MIME format. --------------090807010307060205000205 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 03/12/2013 03:41, Murray S. Kucherawy wrote: > Thanks, Alexey. Hi Murray, > Any other feedback in support of or requesting changes to this > version? Is it ready for WGLC? I think it is ready for WGLC. I have one minor issue which I already raised, but I am trying to decide whether it is worth bringing up again. But anyway, it doesn't affect WGLC initiation. > On Thu, Nov 28, 2013 at 6:36 AM, Alexey Melnikov > > wrote: > > On 20/11/2013 08:02, Murray S. Kucherawy wrote: >> On Wed, Nov 20, 2013 at 12:00 AM, > > 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 Require-Recipient-Valid-Since >> Header Field and SMTP Service Extension >> Author(s) : William J. Mills >> Murray S. Kucherawy >> Filename : >> draft-ietf-appsawg-rrvs-header-field-04.txt >> Pages : 20 >> Date : 2013-11-19 >> >> Abstract: >> This document defines an extension for the Simple Mail >> Transfer >> Protocol called RRVS, and a header field called >> Require-Recipient- >> Valid-Since, to provide a method for senders to indicate >> to receivers >> the time when the sender last confirmed the ownership of >> the target >> mailbox. This can be used to detect changes of mailbox >> ownership, >> and thus prevent mail from being delivered to the wrong party. >> >> The intended use of these facilities is on automatically >> generated >> messages that might contain sensitive information, though >> it may also >> be useful in other applications. >> >> >> Incorporates a lot of suggestions from Ned, Alexey, and John. >> Diff available from the datatracker. Have at it! > This version is much better and it addresses various issues > related to mailing list and redirection. I am happy with it. > --------------090807010307060205000205 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 03/12/2013 03:41, Murray S. Kucherawy wrote:
Thanks, Alexey.
Hi Murray,

Any other feedback in support of or requesting changes to this version?  Is it ready for WGLC?
I think it is ready for WGLC. I have one minor issue which I already raised, but I am trying to decide whether it is worth bringing up again. But anyway, it doesn't affect WGLC initiation.

On Thu, Nov 28, 2013 at 6:36 AM, Alexey Melnikov <alexey.melnikov@isode.com> wrote:
On 20/11/2013 08:02, Murray S. Kucherawy wrote:
On Wed, Nov 20, 2013 at 12:00 AM, <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 Require-Recipient-Valid-Since Header Field and SMTP Service Extension
        Author(s)       : William J. Mills
                          Murray S. Kucherawy
        Filename        : draft-ietf-appsawg-rrvs-header-field-04.txt
        Pages           : 20
        Date            : 2013-11-19

Abstract:
   This document defines an extension for the Simple Mail Transfer
   Protocol called RRVS, and a header field called Require-Recipient-
   Valid-Since, to provide a method for senders to indicate to receivers
   the time when the sender last confirmed the ownership of the target
   mailbox.  This can be used to detect changes of mailbox ownership,
   and thus prevent mail from being delivered to the wrong party.

   The intended use of these facilities is on automatically generated
   messages that might contain sensitive information, though it may also
   be useful in other applications.


Incorporates a lot of suggestions from Ned, Alexey, and John.  Diff available from the datatracker.  Have at it!
This version is much better and it addresses various issues related to mailing list and redirection. I am happy with it.


--------------090807010307060205000205-- From superuser@gmail.com Mon Dec 9 09:48:16 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ACA01AE375 for ; Mon, 9 Dec 2013 09:48:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yr94h5FO3hrw for ; Mon, 9 Dec 2013 09:48:11 -0800 (PST) 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 310131AE3B1 for ; Mon, 9 Dec 2013 09:48:09 -0800 (PST) Received: by mail-we0-f176.google.com with SMTP id w62so3735123wes.7 for ; Mon, 09 Dec 2013 09:48:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=D0J3jcdwo17k+aFPKO13CB8NJOsVcbDZBVqxsaIBcr0=; b=AdPDg3zsZf/ibMIU8ffbplBDLHgwXayLLBdgAOZXMYcZ0OHBomM90WOQg7Jwn+4jUr Nw94gw6f5oLA438Xfm+CMSYlaO2x+8Nh+etL2FVK+U7ZhSuFAI559EBz3zCpY+wYZloW nYoDT43wEQyAR22Vhc6r3bUF6xXg1utsMIss3u8dpXpNJt7RQm/L3XKniCm9zxgdzbsi rgv9RJs22GbM81YrXhHvRiMvTqpd+6BAIKaCwGypoB5PukBm2tyFvpOMaSdT+L+YrFc2 MOHmTUFe+YBHJQvqlu4EJ92QZfj18LEpsYsa5eI/MTFZq9Np/0rJnUxWfvrRiuMvFkJ0 95Dg== MIME-Version: 1.0 X-Received: by 10.180.187.72 with SMTP id fq8mr15274033wic.26.1386611284856; Mon, 09 Dec 2013 09:48:04 -0800 (PST) Received: by 10.181.13.230 with HTTP; Mon, 9 Dec 2013 09:48:04 -0800 (PST) In-Reply-To: <1386605680.43696.YahooMailNeo@web125602.mail.ne1.yahoo.com> References: <20131120080026.25156.23231.idtracker@ietfa.amsl.com> <52975509.4070401@isode.com> <1386130917.78002.YahooMailNeo@web125601.mail.ne1.yahoo.com> <1386605680.43696.YahooMailNeo@web125602.mail.ne1.yahoo.com> Date: Mon, 9 Dec 2013 09:48:04 -0800 Message-ID: From: "Murray S. Kucherawy" To: Bill Mills Content-Type: multipart/alternative; boundary=001a11c2679c13568f04ed1d991e Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rrvs-header-field-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 17:48:16 -0000 --001a11c2679c13568f04ed1d991e Content-Type: text/plain; charset=ISO-8859-1 Actually #3 is only applied if #2 didn't fire. If #2 fired, the message has been rejected, and wouldn't make it to #3. On Mon, Dec 9, 2013 at 8:14 AM, Bill Mills wrote: > That should have been 5.1 not 5.3. > > > > -bill > > > -------------------------------- > William J. Mills > "Paranoid" Yahoo! > > > > On Monday, December 9, 2013 8:08 AM, Murray S. Kucherawy < > superuser@gmail.com> wrote: > On Tue, Dec 3, 2013 at 8:21 PM, Bill Mills wrote: > > Section 3.1: is an explicit BNF syntax required for the IANA > registration? Or is "RRVS=" + date-time implicit from the definition in > 5321? > > > The other examples I've seen don't appear to require anything beyond what > we already have. > > > Section 3.2 "CFWS" is defined but not referred to anywhere else? > > > Fixed in -05. > > > > > > Section 5.3: I think #3 is only appropriate if #2 fired, should #3 > actually be 2.1? > > > There isn't a 5.3 in the -04 (current) version. Can you clarify? > > I'll post -05 shortly, unless this last point needs followup. > > -MSK > > > > --001a11c2679c13568f04ed1d991e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Actually #3 is only applied if #2 didn't fire.=A0 If #= 2 fired, the message has been rejected, and wouldn't make it to #3.
=


On Mon,= Dec 9, 2013 at 8:14 AM, Bill Mills <wmills@yahoo-inc.com> wrote:
That should have been 5.= 1 not 5.3.


=A0
-bill


<= div style=3D"font-style:normal;font-size:13px;background-color:transparent;= font-family:arial,helvetica,clean,sans-serif">-----------------------------= ---
William J. Mills
"Paranoid" Yahoo!


Fixed in -05.


=A0




--001a11c2679c13568f04ed1d991e-- From superuser@gmail.com Mon Dec 9 10:00:54 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED0C1AE409 for ; Mon, 9 Dec 2013 10:00:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pVGnl7ZM7p7E for ; Mon, 9 Dec 2013 10:00:52 -0800 (PST) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 7372A1AE406 for ; Mon, 9 Dec 2013 10:00:52 -0800 (PST) Received: by mail-we0-f180.google.com with SMTP id t61so3794427wes.39 for ; Mon, 09 Dec 2013 10:00:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=JpRTsI9C5CDkcwP0hjE3Pmr3kIGDaxcnz+bb3ESfyX0=; b=z8aLruJjmF2k26otveWzoBSvhrLM5Ks36VykAsip1eXHe5H3Hjs+8Unvw8KCY2zB// vvznO3eqTa/EFtczgxmYzBdlmTsFogd9A0nGjw/pOI5n0paIlIe+dvlXW8DirlHSEY+B JpdGNSdHpvKKC8oY2hGIo+lJOd0BmtNsdKRIUWJWu9lY0Ec9yfKuQNmUBsvvqjedB/+l 5Evj9bRcSkAz11GSb1a98FnnhGoyU2B+DfY38gcNVQ7iiQPS+zmjU7ATesp4Qd+rWtYM hWzxs/lm1Tr64sInBVDCv61fLtOtKNnsDPtXyzkR3XHm7qbIXtrKdz1pZkO/jbINQ4pv jFvQ== MIME-Version: 1.0 X-Received: by 10.194.5.138 with SMTP id s10mr137030wjs.91.1386612046965; Mon, 09 Dec 2013 10:00:46 -0800 (PST) Received: by 10.181.13.230 with HTTP; Mon, 9 Dec 2013 10:00:46 -0800 (PST) Date: Mon, 9 Dec 2013 10:00:46 -0800 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=047d7b5d87b380323b04ed1dc6ab Subject: [apps-discuss] Multiple Working Group Last Calls initiating X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 18:00:54 -0000 --047d7b5d87b380323b04ed1dc6ab Content-Type: text/plain; charset=ISO-8859-1 Colleagues, We have several documents that appear to be in a largely stable state and for which there have been rumblings here, or at IETF 88, or on other IETF lists, that they are ready for Working Group Last Calls. On the other hand, we have the holidays fast approaching, so people's availabilities will be variable through the end of the month. Accordingly, we will be initiating an extended WGLC on each of the following four documents, all lasting until January 10th: draft-ietf-appsawg-xml-mediatypes draft-ietf-appsawg-sieve-duplicate draft-ietf-appsawg-rrvs-header-field draft-ietf-appsawg-uri-get-off-my-lawn There will be separate emails for each of them so that the various feedback streams can be appropriately separated. As usual, we need to see a number of reviews and expressions of support enough to demonstrate consensus before the documents can proceed. Document shepherds, we ask for your help in ensuring these come into being and make their way to the list. You might also want to start working on your PROTO writeups sooner rather than later. I have requested APPSDIR start looking at these now, and they have made a call for volunteers to submit their official reviews. Please let us know if you have any concerns with this approach. -MSK, APPSAWG co-chair --047d7b5d87b380323b04ed1dc6ab Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Colleagues,

We have several documen= ts that appear to be in a largely stable state and for which there have bee= n rumblings here, or at IETF 88, or on other IETF lists, that they are read= y for Working Group Last Calls.=A0 On the other hand, we have the holidays = fast approaching, so people's availabilities will be variable through t= he end of the month.

Accordingly, we will be initiating an extended WGLC on each of the foll= owing four documents, all lasting until January 10th:

draft-ietf-app= sawg-xml-mediatypes
draft-ietf-appsawg-sieve-duplicate
draft-ietf-app= sawg-rrvs-header-field
draft-ietf-appsawg-uri-get-off-my-lawn

There will be sepa= rate emails for each of them so that the various feedback streams can be ap= propriately separated.

As usual, we need to see a number = of reviews and expressions of support enough to demonstrate consensus befor= e the documents can proceed.=A0 Document shepherds, we ask for your help in= ensuring these come into being and make their way to the list.=A0 You migh= t also want to start working on your PROTO writeups sooner rather than late= r.

I have requested APPSDIR start looking at these now, and the= y have made a call for volunteers to submit their official reviews.

=
Please let us know if you have any concerns with this approach.<= br>
-MSK, APPSAWG co-chair
--047d7b5d87b380323b04ed1dc6ab-- From prvs=048d5389d=kandersen@linkedin.com Sun Dec 8 19:18:02 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5AEA1A1F19 for ; Sun, 8 Dec 2013 19:18:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.069 X-Spam-Level: X-Spam-Status: No, score=-2.069 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8XmFMvTLvhT9 for ; Sun, 8 Dec 2013 19:18:01 -0800 (PST) Received: from esv4-mav05.corp.linkedin.com (esv4-mav05.corp.linkedin.com [69.28.149.81]) by ietfa.amsl.com (Postfix) with ESMTP id 8C4D31AE1D0 for ; Sun, 8 Dec 2013 19:18:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkedin.com; i=@linkedin.com; q=dns/txt; s=proddkim1024; t=1386559077; x=1418095077; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=GAvYblQgu6ZdZbNfJhaazv/nWr6WRZSsj+4CAodqA2w=; b=n1sV6oHMkVYF7c4rT2Xd6ubax+BVOS6WnbyL3Qxnd5tx0DjyRjGMJFnK QupeqgqCe3alsT5P4fBwMadThKh7yfvLbBRYhiZ6FaR5BujvkaU79+Rad 3VOu2n6q1E+vsTsFENCQAk6RN1AkOLqiCvBkBVWO25ruZknwbYcnSmM0s k=; X-IronPort-AV: E=Sophos;i="4.93,855,1378882800"; d="scan'208";a="73922766" Received: from ESV4-HT02.linkedin.biz (172.18.46.236) by esv4-cas01.linkedin.biz (172.18.46.140) with Microsoft SMTP Server (TLS) id 14.2.328.11; Sun, 8 Dec 2013 19:17:56 -0800 Received: from ESV4-EXC01.linkedin.biz ([fe80::d7c:dc04:aea1:97d7]) by ESV4-HT02.linkedin.biz ([::1]) with mapi id 14.02.0328.009; Sun, 8 Dec 2013 19:17:56 -0800 From: Kurt Andersen To: "apps-discuss@ietf.org" Thread-Topic: I-D Action: draft-ietf-appsawg-rrvs-header-field-04.txt Thread-Index: AQHO9I1AWoCWExM2RUaONEtm3B+L7Q== Date: Mon, 9 Dec 2013 03:17:55 +0000 Message-ID: <3560C13B3A3EC9408B4BFEDB3B728395601E3D0E@esv4-exc01.linkedin.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.46.250] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 09 Dec 2013 10:23:48 -0800 Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rrvs-header-field-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 03:18:02 -0000 On 2013-11-20 02:00 , "internet-drafts@ietf.org" wrote: > Title : The Require-Recipient-Valid-Since Header Field and >SMTP Service Extension > Filename : draft-ietf-appsawg-rrvs-header-field-04.txt > Date : 2013-11-19 A few comments and questions, mostly detail clarification except for the last one: * Section 3.0 last para, sentence 1 says "under the continuous ownership. . ." but I think that the key factor here is that the mailbox in question has been associated with the expected entity. Continuity is not necessarily the necessary piece (for instance, if a user's subscription lapses, but is subsequently renewed, rrvs should still pass). * Section 7.1 para 2 - Recommending that MTAs change from headers to extension may break signing if MTAs arbitrarily delete headers based on next-hop capabilities. I can see downgrading if needed. * Section 9.1 How will an MTA know whether it is handing over to a "mailing list"? Wouldn't this be better determined/handled by the mailing list software itself? * Section 10 seems to be three different points (paragraph 1/ everything in the middle / the last paragraph) * Section 14.2 para 3 - and the suggested handling would be? It is unclear whether the suggestion is to ignore the rrvs header in this case or to treat the result as unkown. * Not addressed anywhere: What happens if a message is received with conflicting information between the extension mechanism and the header mechanism? In this case, it seem like the header info should be ignored, but suggesting deletion risks damaging DKIM signatures. --Kurt Andersen From superuser@gmail.com Mon Dec 9 11:28:55 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF7C61AE4DA for ; Mon, 9 Dec 2013 11:28:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OU25KQUMB38K for ; Mon, 9 Dec 2013 11:28:52 -0800 (PST) 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 9017B1AE07C for ; Mon, 9 Dec 2013 11:28:52 -0800 (PST) Received: by mail-wi0-f182.google.com with SMTP id en1so4253524wid.9 for ; Mon, 09 Dec 2013 11:28:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jGj14jauDtdaNcQwDOdmE7xwNlAQISOdQXHuaxi1AZU=; b=0YxZGc7DFYYzCwPxZoJKD/49TXO+uJwWYh8yAIoV2DSOFeTQeC62e+ysjI9FBv4+Cd L/6G+u3uPB0rtMI22OYEDVnV41Rs20K0HEEasH5Ooxvj5AZPdLQMJnWDFE3QEmMtuT64 vtULbfsq9g8oTHpF/WbnNCqJLLl0L/jRaU1xi55H1VI27aKF6j+/RCHs2s6xYNtMK0By ZmFocK9W2U4ZmUi/QOUN16G79v2oDJScLJkrRKIctJyVNcyqiaCAP5zQX3PhRAK1vMWq K2qkh5hJuK5Ewr3EG+AGGAGjQFNiY9n83CLTWVspxUw+98f2ruFGZRzeNilOBZ6bxQ2s EktA== MIME-Version: 1.0 X-Received: by 10.180.211.71 with SMTP id na7mr15647686wic.5.1386617327108; Mon, 09 Dec 2013 11:28:47 -0800 (PST) Received: by 10.181.13.230 with HTTP; Mon, 9 Dec 2013 11:28:46 -0800 (PST) In-Reply-To: <3560C13B3A3EC9408B4BFEDB3B728395601E3D0E@esv4-exc01.linkedin.biz> References: <3560C13B3A3EC9408B4BFEDB3B728395601E3D0E@esv4-exc01.linkedin.biz> Date: Mon, 9 Dec 2013 11:28:46 -0800 Message-ID: From: "Murray S. Kucherawy" To: Kurt Andersen Content-Type: multipart/alternative; boundary=001a11c347e038c83004ed1f01a6 Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rrvs-header-field-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 19:28:55 -0000 --001a11c347e038c83004ed1f01a6 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Dec 8, 2013 at 7:17 PM, Kurt Andersen wrote: > * Section 3.0 last para, sentence 1 says "under the continuous ownership. > . ." but I think that the key factor here is that the mailbox in question > has been associated with the expected entity. Continuity is not > necessarily the necessary piece (for instance, if a user's subscription > lapses, but is subsequently renewed, rrvs should still pass). > So you're looking at the case where a mailbox owner changes from A to B, then back to A? I'll add a paragraph at the top of Section 11 that accounts for this possibility > > * Section 7.1 para 2 - Recommending that MTAs change from headers to > extension may break signing if MTAs arbitrarily delete headers based on > next-hop capabilities. I can see downgrading if needed. > I'll add a remark to this effect. However, we do need to encourage the upgrade wherever possible. > > * Section 9.1 How will an MTA know whether it is handing over to a > "mailing list"? Wouldn't this be better determined/handled by the mailing > list software itself? > We're not saying here that the MTA has to know anything. The point being made is that the MLM can't expect any RRVS information to be passed to it by the MTA. > > * Section 10 seems to be three different points (paragraph 1/ everything > in the middle / the last paragraph) > Right, it's a general discussion section. All but the first paragraph explain why the current syntax was chosen. > > * Section 14.2 para 3 - and the suggested handling would be? It is unclear > whether the suggestion is to ignore the rrvs header in this case or to > treat the result as unkown. > Will say so. > > * Not addressed anywhere: What happens if a message is received with > conflicting information between the extension mechanism and the header > mechanism? In this case, it seem like the header info should be ignored, > but suggesting deletion risks damaging DKIM signatures. > Will say something about that as well. Thanks! -MSK --001a11c347e038c83004ed1f01a6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sun, Dec 8, 2013 at 7:17 PM, Kurt Andersen <kande= rsen@linkedin.com> wrote:
* Section 3.0 last para, sentence 1 says &qu= ot;under the continuous ownership.
. ." but I think that the key factor here is that the mailbox in quest= ion
has been associated with the expected entity. =A0Continuity is not
necessarily the necessary piece (for instance, if a user's subscription=
lapses, but is subsequently renewed, rrvs should still pass).

So you're looking at the case where a mailbox ow= ner changes from A to B, then back to A?

I'll add a p= aragraph at the top of Section 11 that accounts for this possibility
=A0

* Section 7.1 para 2 - Recommending that MTAs change from headers to
extension may break signing if MTAs arbitrarily delete headers based on
next-hop capabilities. =A0I can see downgrading if needed.
=

I'll add a remark to this effect.=A0 However, we do= need to encourage the upgrade wherever possible.
=A0

* Section 9.1 How will an MTA know whether it is handing over to a
"mailing list"? Wouldn't this be better determined/handled by= the mailing
list software itself?

We're not say= ing here that the MTA has to know anything.=A0 The point being made is that= the MLM can't expect any RRVS information to be passed to it by the MT= A.
=A0

* Section 10 seems to be three different points (paragraph 1/ everything in the middle / the last paragraph)

Rig= ht, it's a general discussion section.=A0 All but the first paragraph e= xplain why the current syntax was chosen.
=A0

* Section 14.2 para 3 - and the suggested handling would be? It is unclear<= br> whether the suggestion is to ignore the rrvs header in this case or to
treat the result as unkown.

Will say so= .
=A0

* Not addressed anywhere: What happens if a message is received with
conflicting information between the extension mechanism and the header
mechanism? =A0In this case, it seem like the header info should be ignored,=
but suggesting deletion risks damaging DKIM signatures.

Will say something about that as well.

Thanks!
<= br>
-MSK
--001a11c347e038c83004ed1f01a6-- From dave@cridland.net Mon Dec 9 12:59:27 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 539841AE565 for ; Mon, 9 Dec 2013 12:59:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q2ax3beJXMDx for ; Mon, 9 Dec 2013 12:59:25 -0800 (PST) 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 B8FA41AE521 for ; Mon, 9 Dec 2013 12:59:25 -0800 (PST) Received: by mail-oa0-f49.google.com with SMTP id i4so4451769oah.8 for ; Mon, 09 Dec 2013 12:59:20 -0800 (PST) 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=DflYHAwLsTLjlrHGjtv1dkyx3ybAxufEInyiGXa03/E=; b=c3Tiy7gzsaAbbk1LIfPl8WEY/hKpCYOg2Z72ziSk14/3Zo17IYUzmx6uD6EYg08bs1 DQUR/m3iv/gAcpxXiBcPIuCuUp5FJsufe2ae8eUqrSBxjqZjLRbWw2njla+mfrUlWa05 S0+bazfY+oJ7Bem3fIlZGhHytqnyuYEI+yY3s= 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=DflYHAwLsTLjlrHGjtv1dkyx3ybAxufEInyiGXa03/E=; b=Sx+1jx5Kn0QH41w8Y2wXOjMa7RDYAslxpg1Z3DCvsVigbg4OPhEkpoUfo20kTAe61m oDfFJi+AfYN17SzoxPXYJ1LJvtFxJFHjVpe1DcK3WGJHLX/B5Bt5C8Ts9obO7zGjDHaP ONU3A4rabHI7btgtCEc1L7EVPHm6RYNQGElTyK0m27EE6aHFj9G6bqM92kqYk3vTmwTl R2P3rrkZURf6o27gR37XTMrgdLcTiYml59eRpgUl1OuHJ6U4+/7OfUlhOxLFw2/tW+et 1E5qVOLe417/atp5IIPcgBod+bQla2/4rwIJqaRzgZkNmKou0WlCgaw57bFXtuI4DxF+ 8vpg== X-Gm-Message-State: ALoCoQlN1383nRkp5YO6lmlf8frQxYHe8tKlS2vvEhgddrGo7V3rWQvTZpVitGNjl3y9/Q2C3Leu MIME-Version: 1.0 X-Received: by 10.182.221.230 with SMTP id qh6mr13924230obc.7.1386622760671; Mon, 09 Dec 2013 12:59:20 -0800 (PST) Received: by 10.60.144.38 with HTTP; Mon, 9 Dec 2013 12:59:20 -0800 (PST) In-Reply-To: References: <3560C13B3A3EC9408B4BFEDB3B728395601E3D0E@esv4-exc01.linkedin.biz> Date: Mon, 9 Dec 2013 20:59:20 +0000 Message-ID: From: Dave Cridland To: "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=001a11c2fcb816bfff04ed20453c Cc: Kurt Andersen , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rrvs-header-field-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 20:59:27 -0000 --001a11c2fcb816bfff04ed20453c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Dec 9, 2013 at 7:28 PM, Murray S. Kucherawy wr= ote: > On Sun, Dec 8, 2013 at 7:17 PM, Kurt Andersen wro= te: > >> * Section 3.0 last para, sentence 1 says "under the continuous ownership= . >> . ." but I think that the key factor here is that the mailbox in questio= n >> has been associated with the expected entity. Continuity is not >> necessarily the necessary piece (for instance, if a user's subscription >> lapses, but is subsequently renewed, rrvs should still pass). >> > > So you're looking at the case where a mailbox owner changes from A to B, > then back to A? > > I'll add a paragraph at the top of Section 11 that accounts for this > possibility > Ooooh, ouch, no, please. I think that opens too many weird edge cases. I'd prefer s/continuous/exclusive/ - so it can go from A to nobody to A - but the place to discuss this in detail is probably a new first paragraph of =A711, and simply insert a pointer to this detailed definition in =A73 a= s a new second sentence. So in =A73, a new sentence: [confirmed its understanding of who owned that mailbox.] The precise definition of "continuous ownership" is discussed in Section 11. [Two mechanisms are defined here: an] And in =A711, we add a paragraph as first: For the purposes of this specification, we define an address as having been under continuous ownership since a given date if a message sent to the address at any point since the given date would not go to anyone except the owner at that given date. That is, while an address may have been suspended, or otherwise disabled, for some period, any mail actually delivered would have been delivered exclusively to the same owner. Dave. --001a11c2fcb816bfff04ed20453c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Dec 9, 2013 at 7:28 PM, Murray S. Kucherawy <superuser@g= mail.com> wrote:
On Sun, Dec 8, 2013 at = 7:17 PM, Kurt Andersen <kandersen@linkedin.com> wrote:<= br>
* Section 3.0 last para, sentence 1 says "under the c= ontinuous ownership.
. ." but I think that the key factor here is that the mailbox in quest= ion
has been associated with the expected entity. =A0Continuity is not
necessarily the necessary piece (for instance, if a user's subscription=
lapses, but is subsequently renewed, rrvs should still pass).

So you're looking at the case where a mail= box owner changes from A to B, then back to A?

I'll a= dd a paragraph at the top of Section 11 that accounts for this possibility<= br>


Ooo= oh, ouch, no, please. I think that opens too many weird edge cases.

I'd prefer s/continuous/exclusive/ - so it can go fro= m A to nobody to A - but the place to discuss this in detail is probably a = new first paragraph of =A711, and simply insert a pointer to this detailed = definition in =A73 as a new second sentence.

So in =A73, a new sentence:

[c= onfirmed its understanding of who owned
=A0 =A0that mailbox.] The= precise definition of "continuous ownership" is discussed in Sec= tion 11. [Two mechanisms are defined here: an]

And in =A711, we add a paragraph as first:
<t>For the purposes of this specification, we define an = address as having been under continuous ownership since a given date if a m= essage sent to the address at any point since the given date would not go t= o anyone except the owner at that given date. That is, while an address may= have been suspended, or otherwise disabled, for some period, any mail actu= ally delivered would have been delivered exclusively to the same owner.<= /t>

Dave.
--001a11c2fcb816bfff04ed20453c-- From wmills@yahoo-inc.com Mon Dec 9 13:09:14 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFD821AE5AB for ; Mon, 9 Dec 2013 13:09:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.22 X-Spam-Level: X-Spam-Status: No, score=-16.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779, USER_IN_DEF_WHITELIST=-15] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id enQk6Ckh0f3D for ; Mon, 9 Dec 2013 13:09:13 -0800 (PST) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) by ietfa.amsl.com (Postfix) with ESMTP id 5F6151AE5A2 for ; Mon, 9 Dec 2013 13:09:12 -0800 (PST) Received: from GQ1-EX10-CAHT19.y.corp.yahoo.com (gq1-ex10-caht19.corp.gq1.yahoo.com [10.73.119.200]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id rB9L8dsI037099 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 9 Dec 2013 13:08:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1386623321; bh=f1e8EaUNleJjZYjm/LenJWG+SLlY4Le3XbxHh/BfP3Q=; h=References:Message-ID:Date:From:Reply-To:Subject:To:CC: In-Reply-To:MIME-Version:Content-Type; b=eGR5Y7I73kRWeJYazOtPhbmtSjeuVjev37z+hylWa1SKJDO43/mlANEaBmXvQ8dLi 226nmhgkRSlnH6ASRsMgodxJ2yXS8nuOjD0gciKf5uoecSIem+1t4Fu50H2Oo/RytR H5EsBN4RWYZI9Grk+yV+UgdV4/JtwU55QZ/C9BTg= Received: from omp1031.mail.ne1.yahoo.com (98.138.89.175) by GQ1-EX10-CAHT19.y.corp.yahoo.com (10.72.228.24) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 9 Dec 2013 13:08:38 -0800 Received: (qmail 58125 invoked by uid 1000); 9 Dec 2013 21:08:37 -0000 Received: (qmail 47289 invoked by uid 60001); 9 Dec 2013 21:08:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1386623317; bh=bbPBV4iWsDoiw8fA+JUfrP4g1LzjQgLSude05BUAJE0=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=dauDOupmGl2gbrOCUWvtcvk6NCaYEWBmyAE1FehcB7ubr6Soyi3c5L6oY5+lG3XPdQwlrJv22MoAkTMkJerJxuHav9+U1BWJl4OX0/EniVtEXKfrNiutbGBPy1cv7dsJxVRyPQb1JtlkgZB9pZiVBvZRqwz8mkhT0FrFah0HtIQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=kbDVR/EgDcslwKvCjxrH6r/eJEq3b6zpm7tH5m5bUZVD0GCc31soBxIQijLOq+ELQBr5czS3tS84p/f1nSvQ58oajlmJxH0dGeOkVC8XHEdRNBv7+AmREzo3uYTnWkUYSlMnWR1rEu5rMMV37bJ8z3Qn1jvXr/pdoPmkxU1F28M=; X-YMail-OSG: amkhteEVM1mB2owkBeHt6z9WiuTMA626lNEaAF0T6g9jc6V qEgqFQ8ne2p0rtJ7WJ8RJz3ZHYg3ILuDlf5Ca7mVWN0pX5pBvtvHJqgKArRb 7X9yL1rixE8i4.6PrUUG5dNGMBEDehiaCHtTP0Y9eXs_q5dlOJ17Am7Jzhw0 nn4UPiu40.a0i.DHDMY_luVvCO6MGyV0K7d0lzhJYytKLx8BOlxwg3iE.X1R A8SOmijhsNJogWa3h6R5E2l0rIIc2jEqFxC.jzgxYaaEWEoHRAOVexRzbQ6x zKbrGEf7BTzlW78KLLq.8y_tjIAzlsRsFD7E- Received: from [209.131.62.115] by web125605.mail.ne1.yahoo.com via HTTP; Mon, 09 Dec 2013 13:08:37 PST X-Rocket-MIMEInfo: 002.001, SSBhZ3JlZSB3aXRoIERhdmUncyBwb2ludCBhbmQgbGlrZSBoaXMgcHJvcG9zZWQgcGFyYWdyYXBoLgoKCsKgCi1iaWxsCgoKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCldpbGxpYW0gSi4gTWlsbHMKIlBhcmFub2lkIiBZYWhvbyEKCgoKCgpPbiBNb25kYXksIERlY2VtYmVyIDksIDIwMTMgMTI6NTkgUE0sIERhdmUgQ3JpZGxhbmQgPGRhdmVAY3JpZGxhbmQubmV0PiB3cm90ZToKIAoKCgoKCk9uIE1vbiwgRGVjIDksIDIwMTMgYXQgNzoyOCBQTSwgTXVycmF5IFMuIEt1Y2hlcmF3eSA8c3VwZXIBMAEBAQE- X-Mailer: YahooMailWebService/0.8.169.609 References: <3560C13B3A3EC9408B4BFEDB3B728395601E3D0E@esv4-exc01.linkedin.biz> Message-ID: <1386623317.5479.YahooMailNeo@web125605.mail.ne1.yahoo.com> Date: Mon, 9 Dec 2013 13:08:37 -0800 From: Bill Mills To: Dave Cridland , "Murray S. Kucherawy" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1124617404-911605111-1386623317=:5479" X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 623320004 Cc: Kurt Andersen , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rrvs-header-field-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 21:09:14 -0000 ---1124617404-911605111-1386623317=:5479 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I agree with Dave's point and like his proposed paragraph.=0A=0A=0A=A0=0A-b= ill=0A=0A=0A=0A--------------------------------=0AWilliam J. Mills=0A"Paran= oid" Yahoo!=0A=0A=0A=0A=0A=0AOn Monday, December 9, 2013 12:59 PM, Dave Cri= dland wrote:=0A =0A=0A=0A=0A=0A=0AOn Mon, Dec 9, 2013 a= t 7:28 PM, Murray S. Kucherawy wrote:=0A=0AOn Sun, De= c 8, 2013 at 7:17 PM, Kurt Andersen wrote:=0A>=0A>= * Section 3.0 last para, sentence 1 says "under the continuous ownership.= =0A>>. ." but I think that the key factor here is that the mailbox in quest= ion=0A>>has been associated with the expected entity. =A0Continuity is not= =0A>>necessarily the necessary piece (for instance, if a user's subscriptio= n=0A>>lapses, but is subsequently renewed, rrvs should still pass).=0A>>=0A= >=0A>=0A>So you're looking at the case where a mailbox owner changes from A= to B, then back to A?=0A>=0A>=0A>I'll add a paragraph at the top of Sectio= n 11 that accounts for this possibility=0A>=0A=0A=0AOoooh, ouch, no, please= . I think that opens too many weird edge cases.=0A=0AI'd prefer s/continuou= s/exclusive/ - so it can go from A to nobody to A - but the place to discus= s this in detail is probably a new first paragraph of =A711, and simply ins= ert a pointer to this detailed definition in =A73 as a new second sentence.= =0A=0ASo in =A73, a new sentence:=0A=0A[confirmed its understanding of who = owned=0A=A0 =A0that mailbox.] The precise definition of "continuous ownersh= ip" is discussed in Section 11. [Two mechanisms are defined here: an]=0A=0A= And in =A711, we add a paragraph as first:=0A=0AFor the purposes of this= specification, we define an address as having been under continuous owners= hip since a given date if a message sent to the address at any point since = the given date would not go to anyone except the owner at that given date. = That is, while an address may have been suspended, or otherwise disabled, f= or some period, any mail actually delivered would have been delivered exclu= sively to the same owner.=0A=0ADave.=0A=0A_____________________________= __________________=0Aapps-discuss mailing list=0Aapps-discuss@ietf.org=0Aht= tps://www.ietf.org/mailman/listinfo/apps-discuss ---1124617404-911605111-1386623317=:5479 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I agree w= ith Dave's point and like his proposed paragraph.

=
 
-bill


-----------------------------= ---
William J. Mills
"Paranoid" Yahoo!



On Monday, December 9, 2013 12:59 PM, Dave C= ridland <dave@cridland.net> wrote:
=


On Mon, Dec 9, = 2013 at 7:28 PM, Murray S. Kucherawy <superuser@gmail.com> wro= te:
=0A
On Sun, Dec 8, 2013 at 7:17 PM, Kurt Andersen = <kandersen@linkedin.com> wrote:
=0A
=0A
* = Section 3.0 last para, sentence 1 says "under the continuous ownership.
=0A=0A. ." but I think that the key factor here is that the = mailbox in question
=0Ahas been associated with the expec= ted entity.  Continuity is not
=0Anecessarily the ne= cessary piece (for instance, if a user's subscription
=0A= lapses, but is subsequently renewed, rrvs should still pass).

So you're lookin= g at the case where a mailbox owner changes from A to B, then back to A?
I'll add a paragraph at the t= op of Section 11 that accounts for this possibility
=0A


Ooooh, ouch, no, please. I think that opens too ma= ny weird edge cases.

I'd prefer s/c= ontinuous/exclusive/ - so it can go from A to nobody to A - but the place t= o discuss this in detail is probably a new first paragraph of =A711, and si= mply insert a pointer to this detailed definition in =A73 as a new second s= entence.
=0A

So in =A73, a new sente= nce:

[confirmed its understanding o= f who owned
   that mailbox.] The precise definition of= "continuous ownership" is discussed in Section 11. [Two mechanisms are def= ined here: an]
=0A

And in =A711, we = add a paragraph as first:

<t>= For the purposes of this specification, we define an address as having been= under continuous ownership since a given date if a message sent to the add= ress at any point since the given date would not go to anyone except the ow= ner at that given date. That is, while an address may have been suspended, = or otherwise disabled, for some period, any mail actually delivered would h= ave been delivered exclusively to the same owner.</t>
=0A
Dave.
=
________________________= _______________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss<= /a>


---1124617404-911605111-1386623317=:5479-- From kurta@drkurt.com Mon Dec 9 13:56:27 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80D9E1AE5B7 for ; Mon, 9 Dec 2013 13:56:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fdIGBT06_O5P for ; Mon, 9 Dec 2013 13:56:25 -0800 (PST) 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 A28B31AE108 for ; Mon, 9 Dec 2013 13:56:25 -0800 (PST) Received: by mail-wg0-f50.google.com with SMTP id a1so4126852wgh.5 for ; Mon, 09 Dec 2013 13:56:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=UuH0I6pxp8t+9q+HJQXEwqmmAZRtSHUCRZmt8Pe+DW0=; b=VgJHZYNuX6Iex1ARJfVwj+7O2//8drrUeRHv/PjSbDkHYFPRavFMXlyQSm6R/4kw1H un7geZV79KkPSUVXvKqJmxzzdtAbHUkRBN+fj6x3d8ETHMtuvbgLCAMnEdKV1oiN0c+R 1HK4EqyB2tE4fPy4BQAwTa0so3TgXWbyIdKKU= 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:date:message-id:subject:from :to:cc:content-type; bh=UuH0I6pxp8t+9q+HJQXEwqmmAZRtSHUCRZmt8Pe+DW0=; b=U1qwXE8CQLOnDfBokg8Do7mbQy/fAejkzelec6D2DazDlbAFiBzdbH7QOi4X0cUGPl aclfqtb9T49VX5qEIcVaJgFkEB4kFt+rzP3fgycXKDIARHx3Yc3cw9K4iIIEalYdhTbN 7PQCBlX3HbIlbjX4b+gDMPiwZeif5Ul1maeYt5OlW1tEL8hDGqxTj6xeVGB67FX3hAG8 Mfdsdgj2S0J0Tq843iKdOgaT4N8CCBbdN/K1g9UXGEb4dj3JE0+SBDaEa4iZ4YyzLwqs JXpqxUu2BgOwmq4AM1Qg0Z2CK8K7Zz4XwMMX32GyAhF3RPXR9xhLzkle+o+awzA+PF+/ 6L9Q== X-Gm-Message-State: ALoCoQn8+sZP0wXnNGNVLOoDgYOcX++m8xONx2qdomi6IhijLD9pT6lN6V6xSIIDq+DnK07G2fVX MIME-Version: 1.0 X-Received: by 10.180.39.177 with SMTP id q17mr16408782wik.16.1386626180060; Mon, 09 Dec 2013 13:56:20 -0800 (PST) Sender: kurta@drkurt.com Received: by 10.194.152.68 with HTTP; Mon, 9 Dec 2013 13:56:20 -0800 (PST) Date: Mon, 9 Dec 2013 13:56:20 -0800 X-Google-Sender-Auth: R9GeVY07V_UlM8-Yrxw8XlZtZm4 Message-ID: From: Kurt Andersen To: Dave Cridland Content-Type: multipart/alternative; boundary=001a11c228d2e64a0e04ed211093 Cc: Kurt Andersen , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rrvs-header-field-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 21:56:27 -0000 --001a11c228d2e64a0e04ed211093 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Dec 9, 2013 at 12:59 PM, Dave Cridland wrote: > > > And in =A711, we add a paragraph as first: > > For the purposes of this specification, we define an address as having > been under continuous ownership since a given date if a message sent to t= he > address at any point since the given date would not go to anyone except t= he > owner at that given date. That is, while an address may have been > suspended, or otherwise disabled, for some period, any mail actually > delivered would have been delivered exclusively to the same owner. > I agree with this change and think that, in general, Murray's suggested changes capture the intent of the points I raised. I'm slightly concerned with the risk of breaking message signatures with this information (potentially) moving back and forth between extension and header modes since there is an implication that if it is found in a header then it should be signed to be considered. For a security mechanism, I also think that an "unknown" verdict should translate into a refusal to deliver, but it would be nice to communicate the ambiguity back to the sender with a distinct response code so that information was available. This would also apply to cover the case where an error causes a ridiculous date-time to be evaluated (circa the epoch, for instance). --Kurt --001a11c228d2e64a0e04ed211093 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On M= on, Dec 9, 2013 at 12:59 PM, Dave Cridland <dave@cridland.net> wrote:


And in =A711, we add a paragraph as= first:

<t>For the purposes of this specification, we def= ine an address as having been under continuous ownership since a given date= if a message sent to the address at any point since the given date would n= ot go to anyone except the owner at that given date. That is, while an addr= ess may have been suspended, or otherwise disabled, for some period, any ma= il actually delivered would have been delivered exclusively to the same own= er.</t>

I agree with this change= and think that, in general, Murray's suggested changes capture the int= ent of the points I raised. I'm slightly concerned with the risk of bre= aking message signatures with this information (potentially) moving back an= d forth between extension and header modes since there is an implication th= at if it is found in a header then it should be signed to be considered.
For a security mechanism, I also think that an "unknown= " verdict should translate into a refusal to deliver, but it would be = nice to communicate the ambiguity back to the sender with a distinct respon= se code so that information was available.=A0 This would also apply to cove= r the case where an error causes a ridiculous date-time to be evaluated (ci= rca the epoch, for instance).

--Kurt
=A0
--001a11c228d2e64a0e04ed211093-- From superuser@gmail.com Mon Dec 9 14:02:37 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 959281AE5DB for ; Mon, 9 Dec 2013 14:02:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60WnQZffoiE2 for ; Mon, 9 Dec 2013 14:02:35 -0800 (PST) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 8C9471AE5D7 for ; Mon, 9 Dec 2013 14:02:31 -0800 (PST) Received: by mail-wg0-f49.google.com with SMTP id x12so4032163wgg.4 for ; Mon, 09 Dec 2013 14:02:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dl1nkfsQ4+44k8aRph4DxK4rjSdh4zTzZg41Pj/UKp4=; b=uNyaB/FcmvOXPcVBPqL7189cvHBiKRD4The78mCn26LIpFY3YEnleWLcERMbU/B1vu xFUCdBeR8qMkTbKhYf5Z2tXmmdGUE7XsljYIc5mAXHowFGYMLZ172nmq2FO7bj4LRzKi gNZJsB1N1/jibQSDgpQXfNY9osemxB3WiZm2wHNg3+SbgLbeU5MSPQRu4aN2duE7iewc 4AvPnLeJuZyD0XMoQd0gTBh6zEEgPewsRb3Jk4YI7LBHGxBzCICNc1+g+5PXVF+rhTKG X3/57ONeo8O2RatjS9O92Zw2VjVx8sPAfCo7dLdm2Jfss6T0/nTbLeMiNQwCKdz6Kb2G 9beg== MIME-Version: 1.0 X-Received: by 10.180.24.137 with SMTP id u9mr16184126wif.5.1386626546169; Mon, 09 Dec 2013 14:02:26 -0800 (PST) Received: by 10.181.13.230 with HTTP; Mon, 9 Dec 2013 14:02:26 -0800 (PST) In-Reply-To: References: Date: Mon, 9 Dec 2013 14:02:26 -0800 Message-ID: From: "Murray S. Kucherawy" To: Kurt Andersen Content-Type: multipart/alternative; boundary=f46d04447f67b87cfa04ed2126ab Cc: Kurt Andersen , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rrvs-header-field-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 22:02:37 -0000 --f46d04447f67b87cfa04ed2126ab Content-Type: text/plain; charset=ISO-8859-1 On Mon, Dec 9, 2013 at 1:56 PM, Kurt Andersen wrote: > > I agree with this change and think that, in general, Murray's suggested > changes capture the intent of the points I raised. I'm slightly concerned > with the risk of breaking message signatures with this information > (potentially) moving back and forth between extension and header modes > since there is an implication that if it is found in a header then it > should be signed to be considered. > Actually I think the opposite is true. The advice in RFC6376 (Section 5.4.1, to be exact) doesn't include this field in what it recommends be signed, as it's not part of the core message content. Further, we're already talking in this draft about how hashes can be clobbered if the content is altered in that way. > > For a security mechanism, I also think that an "unknown" verdict should > translate into a refusal to deliver, but it would be nice to communicate > the ambiguity back to the sender with a distinct response code so that > information was available. This would also apply to cover the case where > an error causes a ridiculous date-time to be evaluated (circa the epoch, > for instance). > > I'm not sure that we should get into specific rejection advice. Every operator will have its own sensitivities on this topic as to what it wants to reveal in terms of the cause for a message rejection. I don't think we could really say a "right" thing here. Anyone else have a thought on this? -MSK --f46d04447f67b87cfa04ed2126ab Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Dec 9, 2013 at 1:56 PM, Kurt Andersen <kboth@drkur= t.com> wrote:
=

I agree with th= is change and think that, in general, Murray's suggested changes captur= e the intent of the points I raised. I'm slightly concerned with the ri= sk of breaking message signatures with this information (potentially) movin= g back and forth between extension and header modes since there is an impli= cation that if it is found in a header then it should be signed to be consi= dered.

Actually I think t= he opposite is true.=A0 The advice in RFC6376 (Section 5.4.1, to be exact) = doesn't include this field in what it recommends be signed, as it's= not part of the core message content.=A0 Further, we're already talkin= g in this draft about how hashes can be clobbered if the content is altered= in that way.
=A0

For a security mechanism, = I also think that an "unknown" verdict should translate into a re= fusal to deliver, but it would be nice to communicate the ambiguity back to= the sender with a distinct response code so that information was available= .=A0 This would also apply to cover the case where an error causes a ridicu= lous date-time to be evaluated (circa the epoch, for instance).


= I'm not sure that we should get into specific rejection advice.=A0 Ever= y operator will have its own sensitivities on this topic as to what it want= s to reveal in terms of the cause for a message rejection.=A0 I don't t= hink we could really say a "right" thing here.=A0 Anyone else hav= e a thought on this?

-MSK
--f46d04447f67b87cfa04ed2126ab-- From wmills@yahoo-inc.com Mon Dec 9 14:07:21 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 594E91AE5D1 for ; Mon, 9 Dec 2013 14:07:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.92 X-Spam-Level: X-Spam-Status: No, score=-16.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779, USER_IN_DEF_WHITELIST=-15] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j91jGwJIZRIg for ; Mon, 9 Dec 2013 14:07:18 -0800 (PST) Received: from mrout2.yahoo.com (mrout2.yahoo.com [216.145.54.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9DB401AE121 for ; Mon, 9 Dec 2013 14:07:18 -0800 (PST) Received: from GQ1-EX10-CAHT15.y.corp.yahoo.com (gq1-ex10-caht15.corp.gq1.yahoo.com [10.73.119.196]) by mrout2.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id rB9M6jRq064927 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 9 Dec 2013 14:06:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1386626806; bh=+pIH/F7MWM9WfkFyeJoRBM5Yc8tD97Ai3QrCZ9zjM78=; h=References:Message-ID:Date:From:Reply-To:Subject:To:CC: In-Reply-To:MIME-Version:Content-Type; b=DrYVG0icSnz+D70wgmzBB4MbH6RV/vRimEQVcUlMgVa08C2qWPySeJH/ebvT5u6Lb GZ9TUwCkP1UW85NyBqjvOlOlJICg62ey8pMOicP/R+R/ro6cSo3Mi8fccO2mVRzSxR scGWxaofqan/W5l4pgd8OycwRMPxYINjAJvRTbVM= Received: from omp1046.mail.ne1.yahoo.com (98.138.89.254) by GQ1-EX10-CAHT15.y.corp.yahoo.com (10.72.228.24) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 9 Dec 2013 14:06:45 -0800 Received: (qmail 10334 invoked by uid 1000); 9 Dec 2013 22:06:44 -0000 Received: (qmail 56684 invoked by uid 60001); 9 Dec 2013 22:06:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1386626804; bh=ZmhP9vE/la+maaNi1OOxdMnyLx34MwCjDDkG/QHfSu4=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=BVZLUJHpK2fT/cr7njDPTvAS/nc8jnQNRPF3fHtTuo2m0rCO9m0BV7GVtPwp58lQf5AfJARbI82nnK4YqkW+ta1oczHiaAu+WQ8acHQfsZs/1hFJjSncaCS+sh9HS/Wudv83u9AjIYEEwVWBdF2XDZfGljQJByM+86tyEh5Pemw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=PLBjBaO+YGQ8agse3f6rV/DBE2n6EwdeChysdKZBaBQQlS3tja0koZxJX8UwfD/CA+bcXQrwsc7CMzMJPnnJNEHxebDOD22GlFYBF2hqmYrXDpM6Gt4jh9drpWM0W8N+IbRY70vmIUZo7tSrVMquYwcXhQdMNta39bq7/aySHmQ=; X-YMail-OSG: AF3yzXwVM1lUyHWRHYs71Sd5.HWxEElZcc3APrKLVHTpQDq fr1oNAsGqKHLwpzaFUxhv2lDVwRIiqlWehQqeuCpl_FzpNJS6.5jg5fihaW1 AOC64k5BPaMIfxGOpCDnGIcDJXNBsUppK_WVAFcl0d8ICHMvDkoXs_M4riqD 1kswWCfbYaNJfv6vwLYSOu2C5JnPBvW76VdYDTMQpld7uHQUdLyL4CY3xM7c JJQ4RgAgs8IIzv4bX0R8jJ_2F5XRg_gASchMb3jQMwtbQZ2LA9bPHI4pvRdp MmFlbdTlFedEXg3uObhzICO4rDL6mwQ-- Received: from [209.131.62.115] by web125606.mail.ne1.yahoo.com via HTTP; Mon, 09 Dec 2013 14:06:44 PST X-Rocket-MIMEInfo: 002.001, QnJlYWtpbmcgc2lnbmF0dXJlcyBpcyBhbiBleGNlbGxlbnQgcmVhc29uIHRvIHByZWZlciB0aGUgZXh0ZW5zaW9uIG92ZXIgdGhlIGhlYWRlci4gNS4yIGRvZXMgY292ZXIgdGhpcywgcGVyaGFwcyBub3QgYXMgc3Ryb25nbHkgYXMgaXQgY291bGQsIGJ1dCBpdCdzIGNvdmVyZWQuCgoKwqAKLWJpbGwKCgoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KV2lsbGlhbSBKLiBNaWxscwoiUGFyYW5vaWQiIFlhaG9vIQoKCgoKCk9uIE1vbmRheSwgRGVjZW1iZXIgOSwgMjAxMyAxOjU3IFBNLCBLdXJ0IEEBMAEBAQE- X-Mailer: YahooMailWebService/0.8.169.609 References: Message-ID: <1386626804.8469.YahooMailNeo@web125606.mail.ne1.yahoo.com> Date: Mon, 9 Dec 2013 14:06:44 -0800 From: Bill Mills To: Kurt Andersen , Dave Cridland In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="607277540-950063341-1386626804=:8469" X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 626806001 Cc: Kurt Andersen , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rrvs-header-field-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 22:07:21 -0000 --607277540-950063341-1386626804=:8469 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Breaking signatures is an excellent reason to prefer the extension over the= header. 5.2 does cover this, perhaps not as strongly as it could, but it's= covered.=0A=0A=0A=A0=0A-bill=0A=0A=0A=0A--------------------------------= =0AWilliam J. Mills=0A"Paranoid" Yahoo!=0A=0A=0A=0A=0A=0AOn Monday, Decembe= r 9, 2013 1:57 PM, Kurt Andersen wrote:=0A =0AOn Mon, De= c 9, 2013 at 12:59 PM, Dave Cridland wrote:=0A=0A=0A>= =0A>=0A>=0A>And in =A711, we add a paragraph as first:=0A>=0A>=0A>For th= e purposes of this specification, we define an address as having been under= continuous ownership since a given date if a message sent to the address a= t any point since the given date would not go to anyone except the owner at= that given date. That is, while an address may have been suspended, or oth= erwise disabled, for some period, any mail actually delivered would have be= en delivered exclusively to the same owner.=0A=0AI agree with this chan= ge and think that, in general, Murray's suggested changes capture the inten= t of the points I raised. I'm slightly concerned with the risk of breaking = message signatures with this information (potentially) moving back and fort= h between extension and header modes since there is an implication that if = it is found in a header then it should be signed to be considered.=0A=0A=0A= For a security mechanism, I also think that an "unknown" verdict should tra= nslate into a refusal to deliver, but it would be nice to communicate the a= mbiguity back to the sender with a distinct response code so that informati= on was available.=A0 This would also apply to cover the case where an error= causes a ridiculous date-time to be evaluated (circa the epoch, for instan= ce).=0A=0A=0A--Kurt=0A=0A=A0=0A=0A_________________________________________= ______=0Aapps-discuss mailing list=0Aapps-discuss@ietf.org=0Ahttps://www.ie= tf.org/mailman/listinfo/apps-discuss --607277540-950063341-1386626804=:8469 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Breaking = signatures is an excellent reason to prefer the extension over the header. = 5.2 does cover this, perhaps not as strongly as it could, but it's covered.=

 
-bill


---= -----------------------------
William J. Mills
"Paranoid" Yahoo!
<= /div>

=

On Monday, Decembe= r 9, 2013 1:57 PM, Kurt Andersen <kboth@drkurt.com> wrote:
=
=
On Mon, Dec 9, 2013 at 12:59 PM, Dave Cridland <<= a rel=3D"nofollow" ymailto=3D"mailto:dave@cridland.net" target=3D"_blank" h= ref=3D"mailto:dave@cridland.net">dave@cridland.net> wrote:=0A


And in =A711, we add a paragraph as first:
=0A

=
<t>For the purposes of this specification, we define an address = as having been under continuous ownership since a given date if a message s= ent to the address at any point since the given date would not go to anyone= except the owner at that given date. That is, while an address may have be= en suspended, or otherwise disabled, for some period, any mail actually del= ivered would have been delivered exclusively to the same owner.</t>=0A

I agree with this= change and think that, in general, Murray's suggested changes capture the = intent of the points I raised. I'm slightly concerned with the risk of brea= king message signatures with this information (potentially) moving back and= forth between extension and header modes since there is an implication tha= t if it is found in a header then it should be signed to be considered.
= =0A
For a security mechanism, I also think that an "unknown" = verdict should translate into a refusal to deliver, but it would be nice to= communicate the ambiguity back to the sender with a distinct response code= so that information was available.  This would also apply to cover th= e case where an error causes a ridiculous date-time to be evaluated (circa = the epoch, for instance).
=0A
--Kurt
 <= br>

______________________________________= _________
apps-discuss mailing list
apps-discuss@ietf.org<= br>https://www.ietf.org/mailman/listinfo/apps-discuss


=
--607277540-950063341-1386626804=:8469-- From cabo@tzi.org Mon Dec 9 14:15:09 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78F4A1AE5F2 for ; Mon, 9 Dec 2013 14:15:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.251 X-Spam-Level: X-Spam-Status: No, score=-1.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VK8I0zrdP648 for ; Mon, 9 Dec 2013 14:15:07 -0800 (PST) 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 3A4B11AE5BE for ; Mon, 9 Dec 2013 14:15:07 -0800 (PST) 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.5/8.14.5) with ESMTP id rB9MExMr013359; Mon, 9 Dec 2013 23:14:59 +0100 (CET) Received: from [192.168.217.144] (p54890261.dip0.t-ipconnect.de [84.137.2.97]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 9B25529; Mon, 9 Dec 2013 23:14:58 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Mon, 9 Dec 2013 23:14:56 +0100 To: "apps-discuss@ietf.org Discuss" , =?utf-8?Q?draft-ietf-appsawg-json-merge-patch=E2=80=8B=2Eall?=@tools.ietf.org Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) X-Mailer: Apple Mail (2.1822) Subject: [apps-discuss] AppsDir early review for draft-ietf-appsawg-json-merge-patch-02 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Dec 2013 22:15:09 -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 WG chair(s) before posting a new version of the draft. Document: draft-ietf-appsawg-json-merge-patch-02 Title: JSON Merge Patch Reviewer: Carsten Bormann Review Date: 2013-12-09 WG Last Call Date: WGLC ended October 4, 2013 Summary: This draft is NOT ready to progress now as a Proposed Standard and should be revised before an IETF Last Call is issued. MAJOR: 1) The language defining the operation of the patch mechanism is unnecessarily confusing. Several phrases are simply not accessible to this reader. E.g., "Any null member contained in the merge patch MUST be ignored and treated as if those members are undefined." (Members in JSON are name/value pairs. Only the values could be the null value. There is no undefined value in JSON. A member can't be both ignored and treated in a specific way.) 2) As the algorithm appears to be defined, there is never a reason for a server to send arrays with null elements. (In JSON, arrays have elements, not members; I'm not sure I'm reading some of the text right.) The purge_nulls mechanism is therefore completely unneeded. Why would a sender send nulls in arrays only to have them removed by the receiver? By removing this unnecessary processing, the description could be simplified considerably and implementations could be more performant. https://developers.google.com/blogger/docs/3.0/performance?hl=3Den#patch which was cited as a real-world early inspiration for merge-patch does not do any of this superfluous processing either. Rationalizing the existing algorithm means that an implementation only needs to descend recursively through objects, never through other JSON values. Only this descent is justified, as it is the only productive function of the merge algorithm. (The fix also would allow to have nulls in replacement arrays.) The value =BBnull=AB should only ever be special = in the value position of a name/value pair of an object. The text then would only need to distingish object and non-object values, considerably simplifying it and increasing the chance of interoperability. Fixing this will also make the example code much shorter and thus more accessible. 3) The text needs to be modified to take the recent changes to JSON into account. While 4627bis is not yet approved, it is likely that the change to allow non-containers as JSON texts will stand. Merge-patch would then immediately become obsolete once 4627bis is approved. 4) The definition of a charset media type parameter is unacceptable for a +json media type. (Even if it were acceptable, its semantics would need to be defined.) MINOR: 5) Several of the examples contain weird instances of whitespace that are inconsistent between the pre-patch and the post-patch state. This is not just about appearance: It might make the reader wonder whether the patch algorithm is also about changing/updating whitespace. (Clearly, the algorithm is operating at the JSON data model level.) 6) The SHOULD NOTs at the end of section 2 are confusing, as they already seem to be implied by processing required (at a MUST level) further above. NITS: Section 2, item 2: s/or/and/ Gr=FC=DFe, Carsten PS.: The appsdir review template doesn=92t have a space for comments. Let me just add at this point that I like what the draft is trying to do and I strongly believe it will be a useful specification to have available. From prvs=004919cf23=johnl@iecc.com Mon Dec 9 20:54:42 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD9D51AE185 for ; Mon, 9 Dec 2013 20:54:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.393 X-Spam-Level: X-Spam-Status: No, score=-0.393 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fz7P0JYWRkNO for ; Mon, 9 Dec 2013 20:54:41 -0800 (PST) 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 823D91AE144 for ; Mon, 9 Dec 2013 20:54:41 -0800 (PST) Received: (qmail 67845 invoked from network); 10 Dec 2013 04:54:36 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 10 Dec 2013 04:54:36 -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=52a69e8c.xn--yuvv84g.k1310; i=johnl@user.iecc.com; bh=5bw19FmVkL8lOlwwS+Vs9y17D48OKkz0E4xgdTt5UUQ=; b=rnzNmDpzJpYLMU3bU42y2vhmK7KUgDwvHk4dlw5/7kg4d4R+e5zog2pSORp5B4LzYv+/F+uUggdKFQxqVwX9AyzJbyRIXmK1fen/puYsa0XxAAKoW4pb8vF5u7NxR41gejd3ozFRyproaBVozXU7Qc89lpYMT0O626A0i1d8jcgKcwe/BlwCFeo49Clf61IlYzJBUmoEOmTDyN3Lr+/ws7ZAefR8jf1TBdNjSAE480MrkZU3Eug/cfkqd4Fd3Gyy 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=52a69e8c.xn--yuvv84g.k1310; olt=johnl@user.iecc.com; bh=5bw19FmVkL8lOlwwS+Vs9y17D48OKkz0E4xgdTt5UUQ=; b=TMSditzGqePnoYetUORMe1ZxkFsE26RVbrq0GpL35B1bMTonyoDUITra0vNjDPkWGluPFjbm1IpnBWCtYq4c17168iLXVUWCgAuQPIRkHiwtlInn8dVWzGQrdjZU/5fjpcYdoZ0uHAhSW+lD7XMX2lWQfZMFF9MQfByoeDVB1MuyZcgmB8qYCpgGif3ye7Lu/Yu/65VsA1itIUiJi9UFeD4EhNj/Ko5xEu1nnWfqd40gxgGi4QrqrCJJth23ylzC Date: 10 Dec 2013 04:54:14 -0000 Message-ID: <20131210045414.4330.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] I-D Action: draft-ietf-appsawg-rrvs-header-field-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 04:54:42 -0000 >> * Section 3.0 last para, sentence 1 says "under the continuous ownership. >> . ." but I think that the key factor here is that the mailbox in question >> has been associated with the expected entity. Continuity is not >> necessarily the necessary piece (for instance, if a user's subscription >> lapses, but is subsequently renewed, rrvs should still pass). >> > >So you're looking at the case where a mailbox owner changes from A to B, >then back to A? There's a whole range of possibilities that I don't think we want to try to enumerate. The key question is whether the party who receives mail at that address now is the same as or an appropriate replacement for the person who received it at the RRVS time. When I say appropriate replacement, I'm thinking of both stuff like role accounts where noc@blah is whoever handles NOC tickets, or my someone's died and a family member or executor deals with the mail. >We're not saying here that the MTA has to know anything. The point being >made is that the MLM can't expect any RRVS information to be passed to it >by the MTA. Surely it could get RRVS info for the list itself. R's, John From superuser@gmail.com Mon Dec 9 22:25:04 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE1341AE244 for ; Mon, 9 Dec 2013 22:25:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1g11LF38H8eL for ; Mon, 9 Dec 2013 22:25:02 -0800 (PST) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id BE7A71ADFB7 for ; Mon, 9 Dec 2013 22:25:01 -0800 (PST) Received: by mail-we0-f175.google.com with SMTP id t60so4542702wes.34 for ; Mon, 09 Dec 2013 22:24:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0ceDoJCjzXHAWbwI0VJ6P18skbKJ02iseep3GfgacBk=; b=Q4F+CZyMoGSVuDQpmFfC4eVVLDrFOzsXrS/+ksZOEuEGysiNHyRicxKxmz7o20Ud0N r2MCGgZqjEyiH9fXe81VQTJSaDMlKVqLa9x7DS9faNCw3GsNe4j0rTMycZBTUvpdn8yG 6izSx/QCLbB2kxCVyKgnXSWQWWjOmml1hiQ2IRx3s5ktJJHruZ6E8sd6qXY0O7LZ6Zgo HQZG8Jcrgoa/mHnMDFALtW0SbHWiDYMbFHwVwYjacvvmqj5/eFNR4Ewp6noS0i39+InB HF4Zf7TReoQEkllV1dZqHU7Hs/2PH/rV61N96OLlUsFxPu4Zlr2ilPav3l8hwfTtI5Nu mK1Q== MIME-Version: 1.0 X-Received: by 10.194.104.66 with SMTP id gc2mr309831wjb.75.1386656696225; Mon, 09 Dec 2013 22:24:56 -0800 (PST) Received: by 10.181.13.230 with HTTP; Mon, 9 Dec 2013 22:24:56 -0800 (PST) In-Reply-To: <20131210045414.4330.qmail@joyce.lan> References: <20131210045414.4330.qmail@joyce.lan> Date: Mon, 9 Dec 2013 22:24:56 -0800 Message-ID: From: "Murray S. Kucherawy" To: John Levine Content-Type: multipart/alternative; boundary=089e0102ef84cdd68204ed282b2f Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rrvs-header-field-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 06:25:04 -0000 --089e0102ef84cdd68204ed282b2f Content-Type: text/plain; charset=ISO-8859-1 On Mon, Dec 9, 2013 at 8:54 PM, John Levine wrote: > >We're not saying here that the MTA has to know anything. The point being > >made is that the MLM can't expect any RRVS information to be passed to it > >by the MTA. > > Surely it could get RRVS info for the list itself. > > > What for? I would think the MTA knows when the list was established, but it goes no further than that. -MSK --089e0102ef84cdd68204ed282b2f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Dec 9, 2013 at 8:54 PM, John Levine <johnl@taugh.co= m> wrote:
>We're not saying here that the MTA has to know anything. =A0The poi= nt being
>made is that the MLM can't expect any RRVS information to be passed= to it
>by the MTA.

Surely it could get RRVS info for the list itself.



What for?=A0 I would think the MTA= knows when the list was established, but it goes no further than that.
=
-MSK

--089e0102ef84cdd68204ed282b2f-- From kurta@drkurt.com Mon Dec 9 22:33:42 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB3B01ADFB7 for ; Mon, 9 Dec 2013 22:33:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hlVNyXCE77pg for ; Mon, 9 Dec 2013 22:33:41 -0800 (PST) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 3A3311AD8F5 for ; Mon, 9 Dec 2013 22:33:41 -0800 (PST) Received: by mail-we0-f182.google.com with SMTP id q59so4545911wes.13 for ; Mon, 09 Dec 2013 22:33:35 -0800 (PST) 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=nbClVLlXrrF9zjbOcx/oEezQsMLu8Jjy1v8hnxPC3tI=; b=G6uo819ArxaA0r+urs0lZlU+uc43zl1B+qqsr+QeX71ZgvLo/p4icCA7nkI1j3Rq4q A9N5pdO6/E4NGMX+J5Qvfz7OKgCNc/FeGkSodmvkVPucCk6woH9TvSTaYArrO6lMlOYJ w+YMgSPr+0YcmFacm7tYog4VbJFA7/dH9onSM= 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=nbClVLlXrrF9zjbOcx/oEezQsMLu8Jjy1v8hnxPC3tI=; b=kJeSGnY4+HjGW2ElCcBJTsShSY7g0d0pvhNVbVbayb09I7GzzKYz/24oFh1G5l5oSX PpnNl+RdJYbx/igt6nllSvI6z+1Tru8/GUip5pg7OMpkUF6sfAjRR26GV8MPStA4WGgQ f4tONsSMLODwSdz8jyANGrv9eLWkH8aCrjTpPCtN7C1GfvEAmsGV/QGVTPXO15Ks/que u2+1DZww6nU915LjcRUHogMhZntCaBaslsBW+Csrif8UsvXgdOxhRJmZ8vbHBIwoHjaL ZC+jVUUsgXnQJyu+kIgpdDMYWOgzoQTcZkEBV4ljrkCiH8kJ7N1o04DLwqFCUc8RiedP Dtsg== X-Gm-Message-State: ALoCoQnlTiVk8aO0+Qf379/JUqDRrriOdOP6+9ukcC86K5Xk1H1gm8r85rbxcvxQPbVdUDugjZ27 MIME-Version: 1.0 X-Received: by 10.180.183.72 with SMTP id ek8mr17471387wic.31.1386657215703; Mon, 09 Dec 2013 22:33:35 -0800 (PST) Sender: kurta@drkurt.com Received: by 10.194.152.68 with HTTP; Mon, 9 Dec 2013 22:33:35 -0800 (PST) In-Reply-To: References: Date: Mon, 9 Dec 2013 22:33:35 -0800 X-Google-Sender-Auth: AxesE2zYPiGw5VJogW6092YF2qg Message-ID: From: Kurt Andersen To: "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=001a11c3556ec47f8504ed284a29 Cc: Kurt Andersen , "apps-discuss@ietf.org" Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rrvs-header-field-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 06:33:43 -0000 --001a11c3556ec47f8504ed284a29 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Dec 9, 2013 at 2:02 PM, Murray S. Kucherawy wrote: > On Mon, Dec 9, 2013 at 1:56 PM, Kurt Andersen wrote: > >> >> I agree with this change and think that, in general, Murray's suggested >> changes capture the intent of the points I raised. I'm slightly concerned >> with the risk of breaking message signatures with this information >> (potentially) moving back and forth between extension and header modes >> since there is an implication that if it is found in a header then it >> should be signed to be considered. >> > > Actually I think the opposite is true. The advice in RFC6376 (Section > 5.4.1, to be exact) doesn't include this field in what it recommends be > signed, as it's not part of the core message content. Further, we're > already talking in this draft about how hashes can be clobbered if the > content is altered in that way. > The allusion to signing the header was something that I inferred from the second example in section 13.2 (top of page 14 in the -04 draft). It may be worth annotating that example to indicate that this is a hypothetical scenario and not necessarily recommended. --Kurt --001a11c3556ec47f8504ed284a29 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On M= on, Dec 9, 2013 at 2:02 PM, Murray S. Kucherawy <superuser@gmail.com= > wrote:
On Mon, D= ec 9, 2013 at 1:56 PM, Kurt Andersen <kboth@drkurt.com> wrote= :
=

I agree with this change and= think that, in general, Murray's suggested changes capture the intent = of the points I raised. I'm slightly concerned with the risk of breakin= g message signatures with this information (potentially) moving back and fo= rth between extension and header modes since there is an implication that i= f it is found in a header then it should be signed to be considered.

Actually I t= hink the opposite is true.=A0 The advice in RFC6376 (Section 5.4.1, to be e= xact) doesn't include this field in what it recommends be signed, as it= 's not part of the core message content.=A0 Further, we're already = talking in this draft about how hashes can be clobbered if the content is a= ltered in that way.

The allusion to si= gning the header was something that I inferred from the second example in s= ection 13.2 (top of page 14 in the -04 draft). It may be worth annotating t= hat example to indicate that this is a hypothetical scenario and not necess= arily recommended.

--Kurt

--001a11c3556ec47f8504ed284a29-- From prvs=0049baed04=johnl@taugh.com Mon Dec 9 22:36:42 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B48E1AE1FC for ; Mon, 9 Dec 2013 22:36:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dBgHkafds-Bq for ; Mon, 9 Dec 2013 22:36:40 -0800 (PST) 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 671951AE1E9 for ; Mon, 9 Dec 2013 22:36:40 -0800 (PST) Received: (qmail 83090 invoked from network); 10 Dec 2013 06:36:35 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 10 Dec 2013 06:36:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=8672.52a6b673.k1312; i=johnl%iecc.com@submit.iecc.com; bh=jSUKpINMYpKiucFYNRUbrv5EwH5vqvxe+p/RDa+d4ZU=; b=SIvOiep5wHfgmKiERMS098XHn4y9a/ZDnQUWSZEARYDb5fG/7RdP7Nk7yzM9QyesuF86UzYCKVnEmXoOQMel4LDBbeLkz+vo1eaukKuygkEzdx56nRq6bNDMUtzYW3Pw6vIj72MPcfFjxdCTRCCDiOshvcnzxYA0i7HnnuqaQHQSveqagPLaDZiTzOOnCDSpUJlqi/lPsTDrAajUGrRFubPXWmq5Vu5wqd0Oh2LL4SWBKhZo/gSfOBItAgCoukM2 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=8672.52a6b673.k1312; olt=johnl%iecc.com@submit.iecc.com; bh=jSUKpINMYpKiucFYNRUbrv5EwH5vqvxe+p/RDa+d4ZU=; b=LsW6WYvoFUXjeoIB3uFPPHv7/EBTZ6m3Ee+6ThSgeYXz/4GCJV8MDYM8COwX67XUu6ClUOXhPsyKs9VbkrxhkZNB2xPHKZHfTU0Xt3GS7J07tJ19/e6P6x20xPLmclCkIV0FWV6qsTaAGHuTWqqICCLLv0/95Gz3Hxc4t6pE3Enoui7wlwHLz9CoxFgmriifxgg19LaAGuwwn/sYrCcX/96vqEsZ4KQCNSI12ovhu3up+mmf/rZxjmXHr8XaF051 Received: from joyce.lan ([24.58.62.56]) by nimap.iecc.com ([64.57.183.76]) with ESMTPSA (TLS1.0/X.509/SHA1, johnl@iecc.com) via TCP; 10 Dec 2013 06:36:34 -0000 Date: 10 Dec 2013 01:36:33 -0500 Message-ID: From: "John R Levine" To: "Murray S. Kucherawy" In-Reply-To: References: <20131210045414.4330.qmail@joyce.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rrvs-header-field-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 06:36:42 -0000 >>> We're not saying here that the MTA has to know anything. The point being >>> made is that the MLM can't expect any RRVS information to be passed to it >>> by the MTA. >> >> Surely it could get RRVS info for the list itself. >> > What for? I would think the MTA knows when the list was established, but > it goes no further than that. You could imagine some Google Groups sort of setup recycling abandoned list names, but I agree it's not very plausible. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From ned.freed@mrochek.com Mon Dec 9 22:57:02 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A7FB1AE0F7 for ; Mon, 9 Dec 2013 22:57:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jO-GcZu8nqt0 for ; Mon, 9 Dec 2013 22:57:01 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 7DBB51AE2D1 for ; Mon, 9 Dec 2013 22:56:56 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P1RIF232XS000LOI@mauve.mrochek.com> for apps-discuss@ietf.org; Mon, 9 Dec 2013 22:51:46 -0800 (PST) MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=utf-8; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P1LCO3K7RK0000AS@mauve.mrochek.com>; Mon, 9 Dec 2013 22:51:40 -0800 (PST) Message-id: <01P1RIEZHLQQ0000AS@mauve.mrochek.com> Date: Mon, 09 Dec 2013 22:41:49 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Thu, 05 Dec 2013 09:53:42 -0500" <8C2F00E5BD774D5CC8B82B67@caldav.corp.apple.com> References: <1BC1A404FE3E89FEA37FAB45@caldav.corp.apple.com> <52A03BD6.8020303@rename-it.nl> <8C2F00E5BD774D5CC8B82B67@caldav.corp.apple.com> To: Cyrus Daboo Cc: Stephan Bosch , IETF Apps Discuss Subject: Re: [apps-discuss] Reviewers, please (was Re: I-D Action: draft-ietf-appsawg-sieve-duplicate-01.txt) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 06:57:02 -0000 > Hi Stephan, > --On December 5, 2013 at 9:39:50 AM +0100 Stephan Bosch > wrote: > >> - §5.3: I would like to see an example of the use of :handle as I am > >> not entirely sure when that would be applicable > > > > So, just to be clear: do you want an example of why :handle is useful, > > or do you want an example of how :handle works? > > > I guess I am more interested in why it is useful (and thus whether it is > needed at all). Based on that, it may or may not be worthwhile to include > an example. As the draft states, :handle is so a single user can have multiple independent tests of the same string value (Message-id: or whatever) and they won't interfere with each other. An obvious use-case would be a script that has been built up from multiple sources. :handle isn't essential; you can do the same thing with variables, set, and :uniqueid. But it's a hassle, and the one of the really nice things about this extension is it presents itself in such a simple way. Ned From ned.freed@mrochek.com Mon Dec 9 22:57:02 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47D1B1AE2D1 for ; Mon, 9 Dec 2013 22:57:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bPAgRxoiral3 for ; Mon, 9 Dec 2013 22:57:01 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 047811AE306 for ; Mon, 9 Dec 2013 22:56:57 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P1RIK0ASTS000LOI@mauve.mrochek.com> for apps-discuss@ietf.org; Mon, 9 Dec 2013 22:55:45 -0800 (PST) MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=iso-8859-1 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P1LCO3K7RK0000AS@mauve.mrochek.com>; Mon, 9 Dec 2013 22:55:40 -0800 (PST) Message-id: <01P1RIJXPOTS0000AS@mauve.mrochek.com> Date: Mon, 09 Dec 2013 22:54:04 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Mon, 09 Dec 2013 22:24:56 -0800" References: <20131210045414.4330.qmail@joyce.lan> To: "Murray S. Kucherawy" Cc: John Levine , IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rrvs-header-field-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 06:57:02 -0000 > On Mon, Dec 9, 2013 at 8:54 PM, John Levine wrote: > > >We're not saying here that the MTA has to know anything. The point being > > >made is that the MLM can't expect any RRVS information to be passed to it > > >by the MTA. > > > > Surely it could get RRVS info for the list itself. > > > > > > > What for? I would think the MTA knows when the list was established, but > it goes no further than that. It's not when the list was established, it's when a given address was added to it. Ned From superuser@gmail.com Tue Dec 10 00:28:19 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45A8A1AE401 for ; Tue, 10 Dec 2013 00:28:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nulxF77ZSsf8 for ; Tue, 10 Dec 2013 00:28:16 -0800 (PST) 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 976971AE424 for ; Tue, 10 Dec 2013 00:28:16 -0800 (PST) Received: by mail-pb0-f42.google.com with SMTP id uo5so7215388pbc.29 for ; Tue, 10 Dec 2013 00:28:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=n5wComRrz2Ow2hcoS6UEU6z5ZrpbfFxbp/yVw4wRa7A=; b=Ndv0CubeoIvaGujC+b6RSavpkq5pZ7dVIiWTWKi5yFOumTkvkp7eW3vLHHqs5zCAXi PWC5xCEMu/z0lADNljAJ153TUaCOmDlIqtU3WGo/QlIxzKX88D6I83NN8r9VgTCxKlRk 2nKJ3fNPKgURIVfLEyKMzHGudVezfrInomdrmdeJ2ZxaAzekLfL6aRvswDo3f3Qs1y2S o5n1bM/PNs0UQr706UaA8N2xhtPiMMG44Fz8lmjqwMmKIhg3tPUPCfUhgVcTOCJq9zRe XkTjDSVsjVCz8q6z2UESQxcReq9EAIlrPhvr6oWTWGXQmglDGb5nH6klppHrbtrlsMa7 vDZw== MIME-Version: 1.0 X-Received: by 10.66.118.71 with SMTP id kk7mr26143513pab.14.1386664091596; Tue, 10 Dec 2013 00:28:11 -0800 (PST) Received: by 10.66.251.5 with HTTP; Tue, 10 Dec 2013 00:28:11 -0800 (PST) In-Reply-To: <01P1RIJXPOTS0000AS@mauve.mrochek.com> References: <20131210045414.4330.qmail@joyce.lan> <01P1RIJXPOTS0000AS@mauve.mrochek.com> Date: Tue, 10 Dec 2013 00:28:11 -0800 Message-ID: From: "Murray S. Kucherawy" To: Ned Freed Content-Type: multipart/alternative; boundary=e89a8ffbad059a3d6c04ed29e422 Cc: John Levine , IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rrvs-header-field-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 08:28:19 -0000 --e89a8ffbad059a3d6c04ed29e422 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Dec 9, 2013 at 10:54 PM, Ned Freed wrote: > > On Mon, Dec 9, 2013 at 8:54 PM, John Levine wrote: > > > >We're not saying here that the MTA has to know anything. The point > being > > > >made is that the MLM can't expect any RRVS information to be passed > to it > > > >by the MTA. > > > > > > Surely it could get RRVS info for the list itself. > > > > > > > > > > > What for? I would think the MTA knows when the list was established, but > > it goes no further than that. > > It's not when the list was established, it's when a given address was > added to > it. > Doesn't that mean mail addressed to a list has to consider the subscription times of all of the subscribers? That seems way beyond the reach of this work, especially when the result will be Boolean for a list with an arbitrary number of subscribers. -MSK --e89a8ffbad059a3d6c04ed29e422 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Dec 9, 2013 at 10:54 PM, Ned Freed <ned.freed= @mrochek.com> wrote:
>= On Mon, Dec 9, 2013 at 8:54 PM, John Levine <johnl@taugh.com> wrote:
> > >We're not saying here that the MTA has to know anything. = =A0The point being
> > >made is that the MLM can't expect any RRVS information to= be passed to it
> > >by the MTA.
> >
> > Surely it could get RRVS info for the list itself.
> >
> >
> >
> What for? =A0I would think the MTA knows when the list was established= , but
> it goes no further than that.

It's not when the list was established, it's when a giv= en address was added to
it.

Doesn't = that mean mail addressed to a list has to consider the subscription times o= f all of the subscribers?=A0 That seems way beyond the reach of this work, = especially when the result will be Boolean for a list with an arbitrary num= ber of subscribers.

-MSK
--e89a8ffbad059a3d6c04ed29e422-- From ned.freed@mrochek.com Tue Dec 10 08:21:24 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 442401ADF62 for ; Tue, 10 Dec 2013 08:21:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iPYzrzyZ36vY for ; Tue, 10 Dec 2013 08:21:22 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id A4B711ADF4F for ; Tue, 10 Dec 2013 08:21:22 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P1S24XE9OW000M5G@mauve.mrochek.com> for apps-discuss@ietf.org; Tue, 10 Dec 2013 08:16:15 -0800 (PST) MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=iso-8859-1 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P1LCO3K7RK0000AS@mauve.mrochek.com>; Tue, 10 Dec 2013 08:16:11 -0800 (PST) Message-id: <01P1S24VNQDM0000AS@mauve.mrochek.com> Date: Tue, 10 Dec 2013 07:58:49 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Tue, 10 Dec 2013 00:28:11 -0800" References: <20131210045414.4330.qmail@joyce.lan> <01P1RIJXPOTS0000AS@mauve.mrochek.com> To: "Murray S. Kucherawy" Cc: John Levine , Ned Freed , IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rrvs-header-field-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 16:21:24 -0000 > On Mon, Dec 9, 2013 at 10:54 PM, Ned Freed wrote: > > > On Mon, Dec 9, 2013 at 8:54 PM, John Levine wrote: > > > > >We're not saying here that the MTA has to know anything. The point > > being > > > > >made is that the MLM can't expect any RRVS information to be passed > > to it > > > > >by the MTA. > > > > > > > > Surely it could get RRVS info for the list itself. > > > > > > > > > > > > > > > What for? I would think the MTA knows when the list was established, but > > > it goes no further than that. > > > > It's not when the list was established, it's when a given address was > > added to > > it. > > > Doesn't that mean mail addressed to a list has to consider the subscription > times of all of the subscribers? The answer is no, it doesn't. > That seems way beyond the reach of this > work, especially when the result will be Boolean for a list with an > arbitrary number of subscribers. On the contrary, it's a use-case that fits perfectly within the scope of this work. A mailing list is just another means of sending mail to a bunch of people whose addresses may no longer be valid. But the key point here is we have to be careful not to comflate two separate things: Sending mail to the list itself and the list sending mail to all of its subscribers. Semantically this is a delivery-resubmit event, and RRVS information doesn't make it across that any more than it makes it across delivering a message to a user and the user subsequently forwarding or resending the message. I don't really see much point to having a valid-since date on the list itself, but if you want to do that, you can. But once that check is made, the valid-since information has been used up and is itself no longer valid. Look at it this way: The minute an envelope recipient address is changed downstream from whoever originally attached valid-since information to it, the new address is coming from someone who has different information about the validity of the addresses they are using. It's entirely possible for a message to be sent to two recipient addresses, one of which is still valid and the other not, and then for the one valid recipient to forward the message to the other address, except this time the address is valid. Ned From superuser@gmail.com Tue Dec 10 09:02:45 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DC711AE1FD for ; Tue, 10 Dec 2013 09:02:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eDZfo9_7d1pc for ; Tue, 10 Dec 2013 09:02:44 -0800 (PST) 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 C79841AE1FA for ; Tue, 10 Dec 2013 09:02:43 -0800 (PST) Received: by mail-we0-f179.google.com with SMTP id q59so5317656wes.10 for ; Tue, 10 Dec 2013 09:02:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DsunTXVCmTh3QioP6fST4rRCarSfdAV6zPiiQ1hFlkQ=; b=s/OtRl49D/K9O6Itaf50qhrATVugoRNB3kdtNjAibZfDURVkFLO96L6bY79aqYvpFq f25FKDuqWk2SigvTT+urtnhYlto0b+oNIO9XvYQNEtCN9xr+3kc6CcbS/6LWS9JQz9pG +b01LgZ7Jn23Ii5/lcE4n7gvcK2d/wosqz1gl8QqLZ9TdcWYQBwxY2ompjix1Uh2u/CP 5Wm6xdUQVRvsAhvTpZTPaxZikj3uxeB6gOr5ovQKWYy7IBZutjEI/7qwvWok6gjmRWUn Bcw59BAkOHNPeAEUYaBV/QCLIOAzhMde6hZ0b3lp+wTgl8+M1Ijmvy1woDsn8xU/aPmV WU0Q== MIME-Version: 1.0 X-Received: by 10.180.75.202 with SMTP id e10mr20047020wiw.8.1386694957937; Tue, 10 Dec 2013 09:02:37 -0800 (PST) Received: by 10.180.84.106 with HTTP; Tue, 10 Dec 2013 09:02:37 -0800 (PST) In-Reply-To: <01P1S24VNQDM0000AS@mauve.mrochek.com> References: <20131210045414.4330.qmail@joyce.lan> <01P1RIJXPOTS0000AS@mauve.mrochek.com> <01P1S24VNQDM0000AS@mauve.mrochek.com> Date: Tue, 10 Dec 2013 09:02:37 -0800 Message-ID: From: "Murray S. Kucherawy" To: Ned Freed Content-Type: multipart/alternative; boundary=f46d0438956961395504ed3114a4 Cc: John Levine , IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rrvs-header-field-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 17:02:45 -0000 --f46d0438956961395504ed3114a4 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Dec 10, 2013 at 7:58 AM, Ned Freed wrote: > On the contrary, it's a use-case that fits perfectly within the scope of > this > work. A mailing list is just another means of sending mail to a bunch of > people whose addresses may no longer be valid. > > But the key point here is we have to be careful not to comflate two > separate > things: Sending mail to the list itself and the list sending mail to all of > its subscribers. Semantically this is a delivery-resubmit event, and RRVS > information doesn't make it across that any more than it makes it across > delivering a message to a user and the user subsequently forwarding or > resending the message. > > I don't really see much point to having a valid-since date on the list > itself, > but if you want to do that, you can. But once that check is made, the > valid-since information has been used up and is itself no longer valid. > > Look at it this way: The minute an envelope recipient address is changed > downstream from whoever originally attached valid-since information to it, > the > new address is coming from someone who has different information about the > validity of the addresses they are using. It's entirely possible for a > message > to be sent to two recipient addresses, one of which is still valid and the > other not, and then for the one valid recipient to forward the message to > the > other address, except this time the address is valid. > OK, I think the draft already says all of this. I guess I misunderstood your earlier message. Let me know if you think there's other text that needs to be added. -MSK --f46d0438956961395504ed3114a4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Dec 10, 2013 at 7:58 AM, Ned Freed <ned.freed= @mrochek.com> wrote:
On the contrary, it's a use-case that fi= ts perfectly within the scope of this
work. A mailing list is just another means of sending mail to a bunch of people whose addresses may no longer be valid.

But the key point here is we have to be careful not to comflate two separat= e
things: Sending mail to the list itself and the list sending mail to all of=
its subscribers. Semantically this is a delivery-resubmit event, and RRVS information doesn't make it across that any more than it makes it acros= s
delivering a message to a user and the user subsequently forwarding or
resending the message.

I don't really see much point to having a valid-since date on the list = itself,
but if you want to do that, you can. But once that check is made, the
valid-since information has been used up and is itself no longer valid.

Look at it this way: The minute an envelope recipient address is changed downstream from whoever originally attached valid-since information to it, = the
new address is coming from someone who has different information about the<= br> validity of the addresses they are using. It's entirely possible for a = message
to be sent to two recipient addresses, one of which is still valid and the<= br> other not, and then for the one valid recipient to forward the message to t= he
other address, except this time the address is valid.

OK, I think = the draft already says all of this.=A0 I guess I misunderstood your earlier= message.=A0 Let me know if you think there's other text that needs to = be added.

-MSK
--f46d0438956961395504ed3114a4-- From hsantos@isdg.net Tue Dec 10 15:24:26 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ABA71AE22F for ; Tue, 10 Dec 2013 15:24:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.08 X-Spam-Level: X-Spam-Status: No, score=-101.08 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F_cJ3IB20JAe for ; Tue, 10 Dec 2013 15:24:24 -0800 (PST) Received: from catinthebox.net (winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id B91261ADEA6 for ; Tue, 10 Dec 2013 15:24:23 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2888; t=1386717852; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=d9s0mPfCgVxhAaZ5V1aZIRq6mJw=; b=uqrjUH3d0aXccyOYM5yE 6G3kLgDYr9iojhubKxKRJCbTgspa3uCbQnBlHejWP2lSx+7ibAcZCwYkQseWZM8Q WH2VCy4ClCUorexbMBe90jLj+hEzlBHSi+lWB+Y8lqmy5OUKyttqxmmlZrasimTA HBzWeuZIk6Fz1LK40/u2J2g= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Tue, 10 Dec 2013 18:24:12 -0500 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 (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 295355919.8910.388; Tue, 10 Dec 2013 18:24:11 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2888; t=1386717348; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=34L4Ha/ N/nB2NAh2+h/MWy0oAkhd1S0YYBUXfVjHq7k=; b=Vg76VHDA1EYtAbMM0xx4uWZ oSDqrLoYgT4/bzllY/YfI4UWn3qH6FxyidH32wQxmVaQcFPsS5C8L4b2fmygXxxM baY7oDhhbyzd8ihqUIvOaEFbMFiBKyZDiyggoCXjioHBloBNKbIkFLOuWWufqqGS YsT6ZqhTs2tlJ6fUbryY= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Tue, 10 Dec 2013 18:15:48 -0500 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 4036661457.9.4256; Tue, 10 Dec 2013 18:15:47 -0500 Message-ID: <52A7A29B.3070608@isdg.net> Date: Tue, 10 Dec 2013 18:24:11 -0500 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: "Murray S. Kucherawy" References: <20131210045414.4330.qmail@joyce.lan> <01P1RIJXPOTS0000AS@mauve.mrochek.com> <01P1S24VNQDM0000AS@mauve.mrochek.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rrvs-header-field-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Dec 2013 23:24:26 -0000 On 12/10/2013 12:02 PM, Murray S. Kucherawy wrote: > > Let me know if you think there's > other text that needs to be added. > Why not tell us how Facebook and Yahoo is intending to use this as a joint venture? You never addressed my questions I think, what is this "RRVS" time? It seems the basic, across the board change and proposal that you are asking systems to create is a new field in their user databases and to carry this new "field" as part of some new "good/bad" message acceptance/authorization concept. We have CREATION, LAST_UPDATE, EXPIRATION dates in our databases, we even have birth dates, etc. What is this "RRVS" data/time going to be compared to if its implemented with the single purpose to do rejection of what is otherwise a 250 (accept) operation? All I can see here is a proposed need to create a new "Validity" date/time field in user records that can be shared, leverage in transactions. This is important because not all backend systems is a SQL database system where a new database record field can be added without sweat. But even then, one problem I see is who's validity would a receiver be comparing too? How would a new "RRVS" field be initialized? The first time? By whom? Sender A, B, or C? This is why I asked about how Facebook & Yahoo are intending to use this. What is their logic for others to follow or get a better grip to also emulate in their own hosting system? I understand the problem YAHOO is seeing. All public hosting systems A.K.A BBS software have had this problem since the days of allowing users to create their own accounts. But it was less of an issue because the collisions were minimal, and if you did have a collision, you got a different address, period. The old school MHS and naming formats are perhaps still common, using first name initial and full last names, or vice-versa, e.g. hsantos@example.com, santosh@example.com. Basically, this is about REUSING addressing and doing so safely. The collision rates are higher, i.e. there are many "Hector Santos" out there, as opposes to the early days developing and using hosting sites. I guess older, possibly expired, unused addresses can become a "premium" today. I can see the theory to help address part of this problem but only because all systems would need to have a common understanding on what "date/time' this is. The security can only exist when a consistent rejection taking place. No rejection - no security. Anyway, the problem I see with this draft/proposal is its attempt to be "open ended" when it really isn't an open-ended solution. I believe it can help make it more general by having a specific outline or example design requirement needed by systems in order to make it work. Do systems need to add a "Validity" field to their user database records? Is this sufficient? -- HLS From superuser@gmail.com Tue Dec 10 16:19:20 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE0831AE294 for ; Tue, 10 Dec 2013 16:19:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ta58scUAAX-p for ; Tue, 10 Dec 2013 16:19:17 -0800 (PST) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 85AF41ADF91 for ; Tue, 10 Dec 2013 16:19:17 -0800 (PST) Received: by mail-we0-f175.google.com with SMTP id t60so5721189wes.20 for ; Tue, 10 Dec 2013 16:19:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nws3xPRxkvim8WDIjiBjCY2JyLEa0liRvwUwxp9gxC4=; b=VqpBrsGXPYPGwKSwZoYULoFpYs/cf7FdeFGEZe8+gvkDZqYyKu+AF6nDsbYdMCni9i w6y/CZLMHexB419Zn8w8wvJbgt/j+dl83lByDJVTGYkJqiMaO+wesoFYWpvFT/IEXllq EP4YBUglLix2l4pk+BUG9tAVFS9znhrIscOLXvnpYcIGPE/LaHLPR4P6zA/fxnZcIRmb Aru9TjJhy3i4iOP5zW0QN6+U24yhRNO1dzlTDUuEexhW4QhmdnLpOiYY9k7mi4+eSP6h SFy/rvW8polTYuHx8luXyEnMVhLCU7LQwxzsta75SuYhNKtjkiX3QCVVzk1wOHXh2qyA QKMw== MIME-Version: 1.0 X-Received: by 10.180.75.202 with SMTP id e10mr21536638wiw.8.1386721151613; Tue, 10 Dec 2013 16:19:11 -0800 (PST) Received: by 10.180.84.106 with HTTP; Tue, 10 Dec 2013 16:19:11 -0800 (PST) In-Reply-To: <52A7A29B.3070608@isdg.net> References: <20131210045414.4330.qmail@joyce.lan> <01P1RIJXPOTS0000AS@mauve.mrochek.com> <01P1S24VNQDM0000AS@mauve.mrochek.com> <52A7A29B.3070608@isdg.net> Date: Tue, 10 Dec 2013 16:19:11 -0800 Message-ID: From: "Murray S. Kucherawy" To: Hector Santos Content-Type: multipart/alternative; boundary=f46d04389569a5047f04ed372d0c Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rrvs-header-field-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 00:19:21 -0000 --f46d04389569a5047f04ed372d0c Content-Type: text/plain; charset=ISO-8859-1 On Tue, Dec 10, 2013 at 3:24 PM, Hector Santos wrote: > > Why not tell us how Facebook and Yahoo is intending to use this as a joint > venture? > The header field version of this has been deployed as a prototype, and we're getting some useful results out of it. We're considering the switch to the SMTP extension given the issues raised in this working group. > > You never addressed my questions I think, what is this "RRVS" time? > I did: http://www.ietf.org/mail-archive/web/apps-discuss/current/msg10847.html > > It seems the basic, across the board change and proposal that you are > asking systems to create is a new field in their user databases and to > carry this new "field" as part of some new "good/bad" message > acceptance/authorization concept. > > We have CREATION, LAST_UPDATE, EXPIRATION dates in our databases, we even > have birth dates, etc. > > What is this "RRVS" data/time going to be compared to if its implemented > with the single purpose to do rejection of what is otherwise a 250 (accept) > operation? > That's entirely up to you. The protocol only explains what the test is supposed to accomplish, provides you with a date-time for comparison, and explains how the sender probably got the value being presented. How you answer that question when it's posed to you is entirely a local matter, because every receiver has a different data set about its mailboxes and users. It doesn't make sense to try to require receivers conform to a specific schema or something like that. > > All I can see here is a proposed need to create a new "Validity" date/time > field in user records that can be shared, leverage in transactions. This > is important because not all backend systems is a SQL database system where > a new database record field can be added without sweat. > Right, if you want to participate in this extension (which is entirely optional), you'd obviously have to keep that information about your mailbox owners. > > But even then, one problem I see is who's validity would a receiver be > comparing too? How would a new "RRVS" field be initialized? The first > time? By whom? Sender A, B, or C? This is why I asked about how Facebook > & Yahoo are intending to use this. What is their logic for others to > follow or get a better grip to also emulate in their own hosting system? > The same logic we're using in production is spelled out in the document already. Essentially, when a user registers for an account at a particular service, she also includes an email address that can be used for things like password recovery. There's a confirmation step there to confirm ownership of the mailbox. The timestamp when that confirmation completes would be what's used as the RRVS parameter, because that's when the sender was certain of who owned the mailbox. (One might periodically re-confirm, and update the timestamp.) The receiver would likewise record a timestamp of when that mailbox was created. If the mailbox is ever reassigned, that receiver timestamp would be updated. Then, if the creation date of the mailbox is newer than the RRVS parameter, then the sender no longer has a correct notion of who owns the mailbox, and the message shouldn't be delivered. > > Anyway, the problem I see with this draft/proposal is its attempt to be > "open ended" when it really isn't an open-ended solution. > It's not open-ended, but at the same time we do lay out only the minimum requirements for what data each end has to keep in order for the protocol to be useful. We can't be more specific than that because, as I said above, every environment is different. We can only say in the abstract what you need to do to participate. -MSK --f46d04389569a5047f04ed372d0c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Dec 10, 2013 at 3:24 PM, Hector Santos <hsantos@= isdg.net> wrote:

Why not tell us how Facebook and Yahoo is intending to use this as a joint = venture?

The header field version of th= is has been deployed as a prototype, and we're getting some useful resu= lts out of it.=A0 We're considering the switch to the SMTP extension gi= ven the issues raised in this working group.
=A0

You never addressed my questions I think, =A0what is this "RRVS" = time?


It seems the basic, across the board change and proposal that you are askin= g systems to create is a new field in their user databases and to carry thi= s new "field" as part of some new "good/bad" message ac= ceptance/authorization concept.

We have CREATION, LAST_UPDATE, EXPIRATION dates in our databases, we even h= ave birth dates, etc.

What is this "RRVS" data/time going to be compared to if its impl= emented with the single purpose to do rejection of what is otherwise a 250 = (accept) operation?

That's entirely= up to you.=A0 The protocol only explains what the test is supposed to acco= mplish, provides you with a date-time for comparison, and explains how the = sender probably got the value being presented.=A0 How you answer that quest= ion when it's posed to you is entirely a local matter, because every re= ceiver has a different data set about its mailboxes and users.=A0 It doesn&= #39;t make sense to try to require receivers conform to a specific schema o= r something like that.
=A0

All I can see here is a proposed need to create a new "Validity" = date/time field in user records that can be shared, leverage in transaction= s. =A0This is important because not all backend systems is a SQL database s= ystem where a new database record field can be added without sweat.

Right, if you want to participate in this = extension (which is entirely optional), you'd obviously have to keep th= at information about your mailbox owners.
=A0

But even then, one problem I see is who's validity would a receiver be = comparing too? =A0 How would a new "RRVS" field be initialized? = =A0The first time? By whom? Sender A, B, or C? =A0 This is why I asked abou= t how Facebook & Yahoo are intending to use this. =A0 What is their log= ic for others to follow or get a better grip to also emulate in their own h= osting system?

The same logic we're using in producti= on is spelled out in the document already.=A0 Essentially, when a user regi= sters for an account at a particular service, she also includes an email ad= dress that can be used for things like password recovery.=A0 There's a = confirmation step there to confirm ownership of the mailbox.=A0 The timesta= mp when that confirmation completes would be what's used as the RRVS pa= rameter, because that's when the sender was certain of who owned the ma= ilbox.=A0 (One might periodically re-confirm, and update the timestamp.)=A0= The receiver would likewise record a timestamp of when that mailbox was cr= eated.=A0 If the mailbox is ever reassigned, that receiver timestamp would = be updated.=A0 Then, if the creation date of the mailbox is newer than the = RRVS parameter, then the sender no longer has a correct notion of who owns = the mailbox, and the message shouldn't be delivered.
=A0

Anyway, the problem I see with this draft/proposal is its attempt to be &qu= ot;open ended" when it really isn't an open-ended solution.

It's not open-ended, but at the same time= we do lay out only the minimum requirements for what data each end has to = keep in order for the protocol to be useful.=A0 We can't be more specif= ic than that because, as I said above, every environment is different.=A0 W= e can only say in the abstract what you need to do to participate.

-MSK
--f46d04389569a5047f04ed372d0c-- From prvs=0050d13e24=johnl@iecc.com Tue Dec 10 18:18:38 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C205E1AE2FF for ; Tue, 10 Dec 2013 18:18:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.193 X-Spam-Level: X-Spam-Status: No, score=-1.193 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, J_CHICKENPOX_47=0.6, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id grhIZK_MzCdn for ; Tue, 10 Dec 2013 18:18:37 -0800 (PST) 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 39C7A1AE08D for ; Tue, 10 Dec 2013 18:18:37 -0800 (PST) Received: (qmail 86888 invoked from network); 11 Dec 2013 02:18:31 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 11 Dec 2013 02:18:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:content-transfer-encoding; s=52a7cb77.xn--hew.k1310; i=johnl@user.iecc.com; bh=+K+xMg8Eeu6KWYcFq6GblkRPjTk0pW0abaM2/LSHEn0=; b=REbM42WU1lM/A9latjTERqRA3nIw0DX50G3tVORtuRWX4Hu0YLEdK3X6oYbAPR8iFeLoanDSEzv7PJLyKa+ao7gefnTQi2npXDUVZAhVBpUtbWObH/0I22PcCRdiop+hzZdiQz2UEvc15DtKpuAdUNpvqUNSb6tLRg3+pvcxHRm7M69ZuLggB3TOPcZxeC9znOLTK09LFG8BE/kwRe1U0P4LwO7ikz/qq1o3J7GujZqFC3XDrQ557sM5i7v8L/tk DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:mime-version:content-type:content-transfer-encoding; s=52a7cb77.xn--hew.k1310; olt=johnl@user.iecc.com; bh=+K+xMg8Eeu6KWYcFq6GblkRPjTk0pW0abaM2/LSHEn0=; b=hqXgpT5zWrNA28QOb9/V93co1+yQlhUwVlZqh51QTgAd3086JoGuu38/1WMQvKKeJVLxiw2S6vcTEuPmUy8Q+Nl229tdEkaiqzOUr3G+hB/j01YVmQdnLYe+86TAThfW+JaBZdV+tDmyulatj5ZDturGIjSmxQLVlo33/FF86oOFrJa/arzS5RI2Yq3auzrFX1zWWFlE067pg1kVXKq/ThiYkAGhqVBqpcTVRPqQtIWKwEr/aMfjH71oGrH3IpxS Date: 11 Dec 2013 02:18:08 -0000 Message-ID: <20131211021808.14191.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: [apps-discuss] draft-delany-nullmx-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 02:18:39 -0000 Mark Delany originally wrote this draft back in 2005. I resuscitated it with his consent in July. I would like appsawg to adopt it and, assuming you don't hate it, publish it on the standards track. The point of null MX is really simple: if a domain does not receive mail, it publishes this DNS record to say so: blah.example MX 0 . Currently, if a domain has an A or AAAA record but no MX, there's no way to tell whether or not the A is supposed to be a default MX, so MTAs will hammer on it for a week before giving up. This prevents the hammering, and allows sending MTAs to return a useful error message right away rather than an ambiguous message after a week. I believe people have been using this informally since Mark published the original draft in 2005, and I haven't heard any bad reports. Note that SPF -all means I send no mail, which although highly correlated with I receive no mail, is not the same thing. R's, John From hsantos@isdg.net Tue Dec 10 19:18:38 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B20B21AE338 for ; Tue, 10 Dec 2013 19:18:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.402 X-Spam-Level: X-Spam-Status: No, score=-101.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_47=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cX5s5c1ghsXx for ; Tue, 10 Dec 2013 19:18:36 -0800 (PST) Received: from winserver.com (groups.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0E5291AD948 for ; Tue, 10 Dec 2013 19:18:35 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1893; t=1386731907; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=7SR2semv5HMI9xDHKpJ5edaSnnI=; b=ppPmfESQJ/rmtxWS0vNN TuTPTz9FdUdkvd3twHyw4TAnyJMHLtaWw93vYszUt4QAwJWVu4lpuIIGT9rWywbP 4chW2tHpWjNv8bku3NoUj/x/4rjxBixZc3IMeOszEbrbKRJKCZ5WByTxwqazlHRi a0HraLMM+kwoqNEcOTwpeno= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Tue, 10 Dec 2013 22:18:27 -0500 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 (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 309411234.8910.5284; Tue, 10 Dec 2013 22:18:26 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1893; t=1386731401; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=hivkIFI IZoIcHDw0taWPKW6CbKbUdFAe4IXdZUVuVas=; b=KJbVB+tjQRpnfOZLO9J/Net 6gIEX2VZSDOBIgFk/GHlvOdtDbmY/wklgzbBCsgUEJ2Am9tuqp8zoX7m9UfRMpti 7CNlVj5xo+CJRvFt8J1HC579VyrccYSwRK330SdCwj017nKVlFyVJByXIJ7yvmDU 8q6/wX3CJdykttUfrvPw= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Tue, 10 Dec 2013 22:10:01 -0500 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 4050714348.9.8340; Tue, 10 Dec 2013 22:10:00 -0500 Message-ID: <52A7D980.5090902@isdg.net> Date: Tue, 10 Dec 2013 22:18:24 -0500 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: apps-discuss@ietf.org References: <20131211021808.14191.qmail@joyce.lan> In-Reply-To: <20131211021808.14191.qmail@joyce.lan> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] draft-delany-nullmx-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 03:18:38 -0000 On 12/10/2013 9:18 PM, John Levine wrote: > Mark Delany originally wrote this draft back in 2005. I resuscitated > it with his consent in July. I would like appsawg to adopt it and, > assuming you don't hate it, publish it on the standards track. > > The point of null MX is really simple: if a domain does not receive > mail, it publishes this DNS record to say so: > > blah.example MX 0 . > > Currently, if a domain has an A or AAAA record but no MX, there's no > way to tell whether or not the A is supposed to be a default MX, so > MTAs will hammer on it for a week before giving up. This prevents the > hammering, and allows sending MTAs to return a useful error message > right away rather than an ambiguous message after a week. > > I believe people have been using this informally since Mark published > the original draft in 2005, and I haven't heard any bad reports. Note > that SPF -all means I send no mail, which although highly correlated > with I receive no mail, is not the same thing. I think the fallback to A is too prevalent to be ignored. I also thought the "BCP" was: No MX ---> Single Shot A record (if any) attempt. That has been our implementation (as a default enabled feature) since day one and I recall past discussions (in IETF-SMTP) where others has stated they also followed a similar "No MX, Try A once" logic as well. This avoided or minimized the "hammering" to just one attempt before a bounce is initiated. Anyway, I am willing to consider support a logic for MX preference equal zero means no transaction SHOULD be attempted. Actually, what it SHOULD technically mean is its not included in the total grouping/sorting of MX records. This will allow for backward compatibility for the traditional NO MX records yields a Try A record fallback logic (local policy dictating how many tries are attempted). -- HLS From ogud@ogud.com Tue Dec 10 20:15:42 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 004CF1ADFB6 for ; Tue, 10 Dec 2013 20:15:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l7YflZjYep-h for ; Tue, 10 Dec 2013 20:15:41 -0800 (PST) Received: from smtp118.ord1c.emailsrvr.com (smtp118.ord1c.emailsrvr.com [108.166.43.118]) by ietfa.amsl.com (Postfix) with ESMTP id 0415E1ADF8A for ; Tue, 10 Dec 2013 20:15:40 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp7.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 9B09E1B825F; Tue, 10 Dec 2013 23:15:35 -0500 (EST) X-Virus-Scanned: OK Received: by smtp7.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 7DCF71B8299; Tue, 10 Dec 2013 23:15:34 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Olafur Gudmundsson In-Reply-To: <20131211021808.14191.qmail@joyce.lan> Date: Tue, 10 Dec 2013 23:15:34 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <01A730F8-0CCE-4BDC-9B23-45E6611C964A@ogud.com> References: <20131211021808.14191.qmail@joyce.lan> To: John Levine X-Mailer: Apple Mail (2.1510) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-delany-nullmx-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 04:15:42 -0000 On Dec 10, 2013, at 9:18 PM, John Levine wrote: > Mark Delany originally wrote this draft back in 2005. I resuscitated > it with his consent in July. I would like appsawg to adopt it and, > assuming you don't hate it, publish it on the standards track. >=20 > The point of null MX is really simple: if a domain does not receive > mail, it publishes this DNS record to say so: >=20 > blah.example MX 0 . >=20 I think having the "." as server name is not a good idea as it is always = possible that an A or AAAA record will show up there.=20 Joe Abley and I proposed this some time back;=20 http://tools.ietf.org/html/draft-jabley-sink-arpa-01 That proposal needs to be updated to follow RFC6761 to register a = reserved name in .arpa for this=20 purpose like "no-mail.arpa." blah.example. MX 0 no-mail.arpa.=20 > Currently, if a domain has an A or AAAA record but no MX, there's no > way to tell whether or not the A is supposed to be a default MX, so > MTAs will hammer on it for a week before giving up. This prevents the > hammering, and allows sending MTAs to return a useful error message > right away rather than an ambiguous message after a week. >=20 > I believe people have been using this informally since Mark published > the original draft in 2005, and I haven't heard any bad reports. Note > that SPF -all means I send no mail, which although highly correlated > with I receive no mail, is not the same thing. >=20 > R's, > John >=20 Other than that minuscule point of what the name is this is a good = draft.=20 Olafur From prvs=0050d13e24=johnl@iecc.com Tue Dec 10 20:29:42 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C49A1AE187 for ; Tue, 10 Dec 2013 20:29:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.793 X-Spam-Level: X-Spam-Status: No, score=-1.793 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DyiV6Hf2XHgd for ; Tue, 10 Dec 2013 20:29:41 -0800 (PST) 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 CA4C51AE186 for ; Tue, 10 Dec 2013 20:29:40 -0800 (PST) Received: (qmail 18609 invoked from network); 11 Dec 2013 04:29:34 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 11 Dec 2013 04:29:34 -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=52a7ea2e.xn--3zv.k1310; i=johnl@user.iecc.com; bh=d1KknEq3JLI+//Bm+ofU26dwXYVwPSY4Q3QVLDZEYfM=; b=e8LF0qroFlC1yE9KKFEMj/qQPh7myCkj+ruJRjvhaIWqH5tUrZ+W6p/jEcvpoWj/fH0A/5shwWP8+G+uM3KtET5z2ghOzhZvnAk1c7TopipXRX4oAKwD1zx06cW7uJq+Z52Mc0rh7/AXFHIR2DmM62EjkFU0TocfyfS1tj2WYBK5RnkQI6H0n79BioUo5k4qZvQO5jy0bz7GVMB3IKPTGY9JoyZejHsTPFamECfcgONfw1uHUQScAUf2zHqcks1M 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=52a7ea2e.xn--3zv.k1310; olt=johnl@user.iecc.com; bh=d1KknEq3JLI+//Bm+ofU26dwXYVwPSY4Q3QVLDZEYfM=; b=sWO2UAWSKUSAnU7UQoenIfe7CZKVEG5Gy6stDCSYoz/oA4HzmTDkY9W3h2q+/MJ7bTKvjJ9fzodb0UwIEXLjaJ/nzIQckISYHE+UFw3BBO6K2ZsdGbfSIY2s5Rdk4de1A8mgYx459khOzcVEO0KZze33xanA8GUoo86wMA0r2Z8KJakC9UhrQ6nD0EFvBmBG8ubYtP7biMghD0KYwUzZ3fCQOUROZ2/WJ5k91vLZ71Pf3/z/eJXxVkGnXHSOtGyN Date: 11 Dec 2013 04:29:12 -0000 Message-ID: <20131211042912.14864.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <01A730F8-0CCE-4BDC-9B23-45E6611C964A@ogud.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [apps-discuss] draft-delany-nullmx-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 04:29:42 -0000 > I think having the "." as server name is not a good idea as it is > always possible that an A or AAAA record >will show up there. An A record at the root? You must be kidding. R's, John From ogud@ogud.com Tue Dec 10 20:38:50 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F22B31AE366 for ; Tue, 10 Dec 2013 20:38:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YtRIe75ayaRN for ; Tue, 10 Dec 2013 20:38:48 -0800 (PST) Received: from smtp70.ord1c.emailsrvr.com (smtp70.ord1c.emailsrvr.com [108.166.43.70]) by ietfa.amsl.com (Postfix) with ESMTP id A7D271AE365 for ; Tue, 10 Dec 2013 20:38:48 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp1.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 151E8148046; Tue, 10 Dec 2013 23:38:43 -0500 (EST) X-Virus-Scanned: OK Received: by smtp1.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id D18F4148036; Tue, 10 Dec 2013 23:38:42 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Olafur Gudmundsson In-Reply-To: <20131211042912.14864.qmail@joyce.lan> Date: Tue, 10 Dec 2013 23:38:42 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20131211042912.14864.qmail@joyce.lan> To: "John Levine" X-Mailer: Apple Mail (2.1510) Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-delany-nullmx-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 04:38:50 -0000 On Dec 10, 2013, at 11:29 PM, "John Levine" wrote: >> I think having the "." as server name is not a good idea as it is >> always possible that an A or AAAA record >will show up there.=20 >=20 > An A record at the root? You must be kidding. >=20 > R's, > John In ICANN's world nothing is impossible.=20 But more seriously=20 as the draft is written it takes mail server 3 DNS queries to assert = there is no place to send=20 mail too. With a non-existing domain the mail server only needs one query.=20 You only get a NXDOMAIN when there is NOTHING at the name in question=20 thus a lookup for "." A currently gets back RCODE=3D0 (no error) and = empty answer section=20 Olafur From prvs=0050608447=johnl@taugh.com Tue Dec 10 20:45:38 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFDEE1AE194 for ; Tue, 10 Dec 2013 20:45:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a1rCCW56k4vW for ; Tue, 10 Dec 2013 20:45:37 -0800 (PST) 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 238661A1F5F for ; Tue, 10 Dec 2013 20:45:37 -0800 (PST) Received: (qmail 21912 invoked from network); 11 Dec 2013 04:45:31 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 11 Dec 2013 04:45:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=a1fc.52a7edeb.k1312; i=johnl%iecc.com@submit.iecc.com; bh=UU91lJBc8uiLY0/EFJgjUqnfEI9kxcObrdd4bgSJF48=; b=Z/Tp46hZfJlmgQLImnAhChVV/lpS1I7wgbOgBp0fyQijzfA/ZRJfsVL5v+43ldBpcRMIHbMowUblt0QNhg8Az5erk75bJx1zXkT2/bdxJWzSba1ohlFymnyPHGfJf8diNWnyqjR5arPngkqTw3THB7HwliJUR+iY0MTJIsV1lpmYDMP3NqpUQ4RyQhR8w/d+OSRovbN+mBMKvzGYnkPQhZloapofRWEJg/QMlEe8gcLUpKSvDPMRrorJ5JzKTNEX DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=a1fc.52a7edeb.k1312; olt=johnl%iecc.com@submit.iecc.com; bh=UU91lJBc8uiLY0/EFJgjUqnfEI9kxcObrdd4bgSJF48=; b=EnfJ6idrKLoeVgFz5i/BmWuJ1bqt8xKX0/8Zn16kQFyWoc1t17U2BKyqseRmzN/Dsk4XECEMeB0LEkj2i1rf7hFa2vyLftjXlgjTj79Eno8p/CPPdw/k2wb27mEcPURK6J/GkrcZ2QWYuGoGg1QxQ/dAmdVa5p8B0YoPXOvNXi3GbHCaR7+llWQ47rhUd6jmpxOn+wXWLz7K0jNNuJWRAK5gn/YXsO8oJoNGYuas8nFgMdTketD0dghdSXadNjm7 Received: from joyce.lan ([24.58.62.56]) by nimap.iecc.com ([64.57.183.76]) with ESMTPSA (TLS1.0/X.509/SHA1, johnl@iecc.com) via TCP; 11 Dec 2013 04:45:31 -0000 Date: 10 Dec 2013 23:45:30 -0500 Message-ID: From: "John R Levine" To: "Olafur Gudmundsson" In-Reply-To: References: <20131211042912.14864.qmail@joyce.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-delany-nullmx-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 04:45:39 -0000 >> An A record at the root? You must be kidding. > In ICANN's world nothing is impossible. Given the foofarrah about dotless domains, I'm not too worried about it. > as the draft is written it takes mail server 3 DNS queries to assert there is no place to send > mail too. Huh? The client does one lookup for the MX, and it's done. I suppose that MTAs that don't understand this hack might try to look for a A record at the root, but the point is that with this as a standard, MTAs recognize it as a flag so they can immediately fail the message. I checked a while ago and a lot already do. R's, John From Claudio.Allocchio@garr.it Tue Dec 10 23:45:46 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2C571AE3A1 for ; Tue, 10 Dec 2013 23:45:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.478 X-Spam-Level: X-Spam-Status: No, score=0.478 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_47=0.6, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ekXG7-KFqM4n for ; Tue, 10 Dec 2013 23:45:44 -0800 (PST) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [193.206.158.29]) by ietfa.amsl.com (Postfix) with ESMTP id 6A4A91AE2D1 for ; Tue, 10 Dec 2013 23:45:44 -0800 (PST) Received: internal info suppressed Date: Wed, 11 Dec 2013 08:45:32 +0100 (CET) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.garrtest.units.it To: Hector Santos In-Reply-To: <52A7D980.5090902@isdg.net> Message-ID: References: <20131211021808.14191.qmail@joyce.lan> <52A7D980.5090902@isdg.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=1386747937; bh=hfispJfEDdb1WlXKQgkUH2ZC+CzBjeyzVzlQ4b7LBtU=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=DN2/+Te9Hbu7N20BHcAnMDpXLpqm2/Obc999dZ53PpcB4qLCbqtUNAgYEcwKkN94b sqB/wEh1ckY9prss+m86fGYTLFOWLrQuYwuJx0E0Ln6TGfm7+GLPOJdgUuYuo2pFAo bo6PffA1/CsfLjlpgrhqst59z64AtP6aqfS4vxpU= Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-delany-nullmx-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 07:45:47 -0000 On Tue, 10 Dec 2013, Hector Santos wrote: > On 12/10/2013 9:18 PM, John Levine wrote: >> Mark Delany originally wrote this draft back in 2005. I resuscitated >> it with his consent in July. I would like appsawg to adopt it and, >> assuming you don't hate it, publish it on the standards track. >> >> The point of null MX is really simple: if a domain does not receive >> mail, it publishes this DNS record to say so: >> >> blah.example MX 0 . >> >> Currently, if a domain has an A or AAAA record but no MX, there's no >> way to tell whether or not the A is supposed to be a default MX, so >> MTAs will hammer on it for a week before giving up. This prevents the >> hammering, and allows sending MTAs to return a useful error message >> right away rather than an ambiguous message after a week. >> >> I believe people have been using this informally since Mark published >> the original draft in 2005, and I haven't heard any bad reports. Note >> that SPF -all means I send no mail, which although highly correlated >> with I receive no mail, is not the same thing. > > I think the fallback to A is too prevalent to be ignored. I also thought the > "BCP" was: > > No MX ---> Single Shot A record (if any) attempt. > > That has been our implementation (as a default enabled feature) since day one > and I recall past discussions (in IETF-SMTP) where others has stated they > also followed a similar "No MX, Try A once" logic as well. This avoided or > minimized the "hammering" to just one attempt before a bounce is initiated. But this is also the know cause of a mumber of failed deliveries, which instead was fully legitimate: many embedded (expecially into web site scripts) SMTP small servers do that... and when they meet a graylist, fail! > Anyway, I am willing to consider support a logic for MX preference equal zero > means no transaction SHOULD be attempted. Actually, what it SHOULD > technically mean is its not included in the total grouping/sorting of MX > records. This will allow for backward compatibility for the traditional NO > MX records yields a Try A record fallback logic (local policy dictating how > many tries are attempted). I agree... MX 0 is likely a better "legalization" of a practice... > > -- > HLS > > > > _______________________________________________ > 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 anything@michielbdejong.com Wed Dec 11 00:39:01 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBEA21ADF63 for ; Wed, 11 Dec 2013 00:39:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZCLLIou8NBn for ; Wed, 11 Dec 2013 00:39:00 -0800 (PST) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [IPv6:2001:4b98:c:538::196]) by ietfa.amsl.com (Postfix) with ESMTP id DD6271AE1C0 for ; Wed, 11 Dec 2013 00:38:59 -0800 (PST) Received: from mfilter2-d.gandi.net (mfilter2-d.gandi.net [217.70.178.140]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id A119E17209F; Wed, 11 Dec 2013 09:38:53 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter2-d.gandi.net Received: from relay4-d.mail.gandi.net ([217.70.183.196]) by mfilter2-d.gandi.net (mfilter2-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id BLOYI1FIJ9cu; Wed, 11 Dec 2013 09:38:52 +0100 (CET) X-Originating-IP: 213.144.123.242 Received: from [192.168.1.78] (unknown [213.144.123.242]) (Authenticated sender: anything@michielbdejong.com) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 1BA78172098; Wed, 11 Dec 2013 09:38:50 +0100 (CET) Message-ID: <52A82499.2040900@michielbdejong.com> Date: Wed, 11 Dec 2013 10:38:49 +0200 From: "Michiel B. de Jong" User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Mark Nottingham , "Julian F. Reschke" References: <52934147.90304@michielbdejong.com> <52934626.8060503@gmx.de> <52935C62.1010301@michielbdejong.com> <5294E443.5050308@michielbdejong.com> <5294E795.2010806@gmx.de> <5295E0D6.6020505@michielbdejong.com> <5295E3FB.4050407@gmx.de> <5295F13B.4070504@michielbdejong.com> <5295F411.7040002@gmx.de> <4245CDAC-FAEF-45BC-B5E6-FC7F62A99269@mnot.net> In-Reply-To: <4245CDAC-FAEF-45BC-B5E6-FC7F62A99269@mnot.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Cc: "apps-discuss@ietf.org" Subject: Re: [apps-discuss] remote storage: per-user cloud storage for the web X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 08:39:02 -0000 On 02-Dec-13 2:39, Mark Nottingham wrote: > On 28 Nov 2013, at 12:30 am, Julian Reschke wro= te: > >> On 2013-11-27 14:18, Michiel B. de Jong wrote: >>> On 27-Nov-13 13:22, Julian Reschke wrote: >>>> Quoting: >>>> >>>>> * Whereas [HTTP, section 10] allows many different status c= odes, >>>>> remoteStorage servers SHOULD send the status codes mentio= ned >>>>> in section 5 of this Internet Draft, and clients MAY trea= t any >>>>> deviation from this as a server malfunction. >>>> I still don't understand how that helps. What problem are you solvin= g >>>> here? >>>> >>> if we allow servers a choice of all response codes then the client >>> implement code to deal with each one of them. most of that code would >>> never be used in practice, and thus be easily end up being buggy and >>> lead to incompatibility. >> The code to implement unknown codes is trivial. Just treat 2xx as 200,= 3xx as 300, 4xx as 400, and 5xx as 500. > More to the point, many status codes are generated somewhere =93in betw= een=94, whether that be a proxy, a load balancer used by the service, a C= DN, a reverse proxy cache, a captive portal, etc. etc. A client that isn=92= t written to deal with a broad variety of status codes is going to fail w= hen exposed to the real Internet. ok! we fixed this. thanks all for the feedback! cheers, Michiel From anything@michielbdejong.com Wed Dec 11 00:39:42 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 883571AE2AC for ; Wed, 11 Dec 2013 00:39:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mQWHlx5WWH8Z for ; Wed, 11 Dec 2013 00:39:40 -0800 (PST) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [IPv6:2001:4b98:c:538::197]) by ietfa.amsl.com (Postfix) with ESMTP id 25CFB1ADF63 for ; Wed, 11 Dec 2013 00:39:40 -0800 (PST) Received: from mfilter1-d.gandi.net (mfilter1-d.gandi.net [217.70.178.130]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id BB71241C05C for ; Wed, 11 Dec 2013 09:39:33 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter1-d.gandi.net Received: from relay5-d.mail.gandi.net ([217.70.183.197]) by mfilter1-d.gandi.net (mfilter1-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id f1LXo3c0PEdc for ; Wed, 11 Dec 2013 09:39:32 +0100 (CET) X-Originating-IP: 213.144.123.242 Received: from [192.168.1.78] (unknown [213.144.123.242]) (Authenticated sender: anything@michielbdejong.com) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 0A4C341C060 for ; Wed, 11 Dec 2013 09:39:31 +0100 (CET) Message-ID: <52A824C2.7080305@michielbdejong.com> Date: Wed, 11 Dec 2013 10:39:30 +0200 From: "Michiel B. de Jong" User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "apps-discuss@ietf.org" References: <20131210192148.22505.54573.idtracker@ietfa.amsl.com> In-Reply-To: <20131210192148.22505.54573.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20131210192148.22505.54573.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------090602030504070303050304" Subject: [apps-discuss] Fwd: New Version Notification for draft-dejong-remotestorage-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 08:39:42 -0000 This is a multi-part message in MIME format. --------------090602030504070303050304 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit FYI -------- Original Message -------- Subject: New Version Notification for draft-dejong-remotestorage-02.txt Date: Tue, 10 Dec 2013 11:21:48 -0800 From: internet-drafts@ietf.org To: Michiel B. de Jong , F. Kooman A new version of I-D, draft-dejong-remotestorage-02.txt has been successfully submitted by Michiel B. de Jong and posted to the IETF repository. Filename: draft-dejong-remotestorage Revision: 02 Title: remoteStorage Creation date: 2013-12-10 Group: Individual Submission Number of pages: 20 URL: http://www.ietf.org/internet-drafts/draft-dejong-remotestorage-02.txt Status: http://datatracker.ietf.org/doc/draft-dejong-remotestorage Htmlized: http://tools.ietf.org/html/draft-dejong-remotestorage-02 Diff: http://www.ietf.org/rfcdiff?url2=draft-dejong-remotestorage-02 Abstract: This draft describes a protocol by which client-side applications, running inside a web browser, can communicate with a data storage server that is hosted on a different domain name. This way, the provider of a web application need not also play the role of data storage provider. The protocol supports storing, retrieving, and removing individual documents, as well as listing the contents of an individual directory, and access control is based on bearer tokens. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------090602030504070303050304 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit FYI


-------- Original Message --------
Subject: New Version Notification for draft-dejong-remotestorage-02.txt
Date: Tue, 10 Dec 2013 11:21:48 -0800
From: internet-drafts@ietf.org
To: Michiel B. de Jong <michiel@michielbdejong.com>, F. Kooman <fkooman@tuxed.net> 


A new version of I-D, draft-dejong-remotestorage-02.txt
has been successfully submitted by Michiel B. de Jong and posted to the
IETF repository.

Filename:	 draft-dejong-remotestorage
Revision:	 02
Title:		 remoteStorage
Creation date:	 2013-12-10
Group:		 Individual Submission
Number of pages: 20
URL:             http://www.ietf.org/internet-drafts/draft-dejong-remotestorage-02.txt
Status:          http://datatracker.ietf.org/doc/draft-dejong-remotestorage
Htmlized:        http://tools.ietf.org/html/draft-dejong-remotestorage-02
Diff:            http://www.ietf.org/rfcdiff?url2=draft-dejong-remotestorage-02

Abstract:
    This draft describes a protocol by which client-side applications,
    running inside a web browser, can communicate with a data storage
    server that is hosted on a different domain name. This way, the
    provider of a web application need not also play the role of data
    storage provider. The protocol supports storing, retrieving, and
    removing individual documents, as well as listing the contents of an
    individual directory, and access control is based on bearer tokens.

                                                                                  


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

The IETF Secretariat


--------------090602030504070303050304-- From superuser@gmail.com Wed Dec 11 00:49:09 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD2951AE02B for ; Wed, 11 Dec 2013 00:49:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_47=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q5ja4hUe4L-r for ; Wed, 11 Dec 2013 00:49:07 -0800 (PST) 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 44F8F1ADF99 for ; Wed, 11 Dec 2013 00:49:07 -0800 (PST) Received: by mail-we0-f176.google.com with SMTP id w62so6186790wes.35 for ; Wed, 11 Dec 2013 00:49:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/gdFMwM53PTUOUtE2KNvm0/ZZfwM5zCwzjlCufix3fs=; b=bYvgrUSjrux2KLRUBKv2eFl1LJMDVyyJdiSKFg9DZSrflOYEeEIiXgDSWHBacAMns4 uya1PtDqH5AIVFyZJ8NqbhhMIh7liMTNbZlqmUm5VP+w3h75mp0wQZEmweKJ5hdRjCeX e6V9DaH/i80W+TaxmQZKVxrbUtVDeP+8cndwV4xSviQmqvki5gL0+hbBxqyonaXE4IBJ 5xCBR0w6mrRtvnumQhFoxo/r3Qxcp7BTqh3FH6/pAVySa2CZqs3+4dwPBYQuZqptENO5 0Rcsl0WMVTB5IrcLK9cUVW520SiDCBU8Np30eoqONLcrCkdz4orVF4QCdWx1cqDnD6IH /MFw== MIME-Version: 1.0 X-Received: by 10.195.12.75 with SMTP id eo11mr20573wjd.92.1386751741060; Wed, 11 Dec 2013 00:49:01 -0800 (PST) Received: by 10.180.84.106 with HTTP; Wed, 11 Dec 2013 00:49:00 -0800 (PST) In-Reply-To: References: <20131211021808.14191.qmail@joyce.lan> <52A7D980.5090902@isdg.net> Date: Wed, 11 Dec 2013 00:49:00 -0800 Message-ID: From: "Murray S. Kucherawy" To: Claudio Allocchio Content-Type: multipart/alternative; boundary=047d7bfcec5ceaec3f04ed3e4c84 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-delany-nullmx-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 08:49:09 -0000 --047d7bfcec5ceaec3f04ed3e4c84 Content-Type: text/plain; charset=ISO-8859-1 Separate from the specific mechanism chosen, does the working group want to put time into producing a document that proposes a standard way of saying "We do not accept mail?" We could use this document as a starting point for such work if the WG thinks it's appropriate. If the answer to the first question is "yes" but the second is "no", does anyone have an alternative proposal? -MSK, APPSAWG co-chair On Tue, Dec 10, 2013 at 11:45 PM, Claudio Allocchio < Claudio.Allocchio@garr.it> wrote: > > On Tue, 10 Dec 2013, Hector Santos wrote: > > On 12/10/2013 9:18 PM, John Levine wrote: >> >>> Mark Delany originally wrote this draft back in 2005. I resuscitated >>> it with his consent in July. I would like appsawg to adopt it and, >>> assuming you don't hate it, publish it on the standards track. >>> >>> The point of null MX is really simple: if a domain does not receive >>> mail, it publishes this DNS record to say so: >>> >>> blah.example MX 0 . >>> >>> Currently, if a domain has an A or AAAA record but no MX, there's no >>> way to tell whether or not the A is supposed to be a default MX, so >>> MTAs will hammer on it for a week before giving up. This prevents the >>> hammering, and allows sending MTAs to return a useful error message >>> right away rather than an ambiguous message after a week. >>> >>> I believe people have been using this informally since Mark published >>> the original draft in 2005, and I haven't heard any bad reports. Note >>> that SPF -all means I send no mail, which although highly correlated >>> with I receive no mail, is not the same thing. >>> >> >> I think the fallback to A is too prevalent to be ignored. I also thought >> the "BCP" was: >> >> No MX ---> Single Shot A record (if any) attempt. >> >> That has been our implementation (as a default enabled feature) since day >> one and I recall past discussions (in IETF-SMTP) where others has stated >> they also followed a similar "No MX, Try A once" logic as well. This >> avoided or minimized the "hammering" to just one attempt before a bounce is >> initiated. >> > > But this is also the know cause of a mumber of failed deliveries, which > instead was fully legitimate: many embedded (expecially into web site > scripts) SMTP small servers do that... and when they meet a graylist, fail! > > > Anyway, I am willing to consider support a logic for MX preference equal >> zero means no transaction SHOULD be attempted. Actually, what it SHOULD >> technically mean is its not included in the total grouping/sorting of MX >> records. This will allow for backward compatibility for the traditional NO >> MX records yields a Try A record fallback logic (local policy dictating how >> many tries are attempted). >> > > I agree... MX 0 is likely a better "legalization" of a practice... > > >> -- >> HLS >> >> >> >> _______________________________________________ >> 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 > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --047d7bfcec5ceaec3f04ed3e4c84 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Separate from the specific mechanism chosen, does the= working group want to put time into producing a document that proposes a s= tandard way of saying "We do not accept mail?"

We could us= e this document as a starting point for such work if the WG thinks it's= appropriate.=A0 If the answer to the first question is "yes" but= the second is "no", does anyone have an alternative proposal?
-MSK, APPSAWG co-chair


On Tue, Dec 10, 2013 at 11:45 PM, Claudio = Allocchio <Claudio.Allocchio@garr.it> wrote:

On Tue, 10 Dec 2013, Hector Santos wrote:

On 12/10/2013 9:18 PM, John Levine wrote:
Mark Delany originally wrote this draft back in 2005. =A0I resuscitated
it with his consent in July. =A0I would like appsawg to adopt it and,
assuming you don't hate it, publish it on the standards track.

The point of null MX is really simple: if a domain does not receive
mail, it publishes this DNS record to say so:

=A0 =A0 =A0 =A0 blah.example MX 0 .

Currently, if a domain has an A or AAAA record but no MX, there's no way to tell whether or not the A is supposed to be a default MX, so
MTAs will hammer on it for a week before giving up. =A0This prevents the hammering, and allows sending MTAs to return a useful error message
right away rather than an ambiguous message after a week.

I believe people have been using this informally since Mark published
the original draft in 2005, and I haven't heard any bad reports. =A0Not= e
that SPF -all means I send no mail, which although highly correlated
with I receive no mail, is not the same thing.

I think the fallback to A is too prevalent to be ignored. I also thought th= e "BCP" was:

=A0 =A0 =A0 =A0 =A0 No MX ---> Single Shot A record (if any) attempt.
That has been our implementation (as a default enabled feature) since day o= ne and I recall past discussions (in IETF-SMTP) where others has stated the= y also followed a similar "No MX, Try A once" logic as well. This= avoided or minimized the "hammering" to just one attempt before = a bounce is initiated.

But this is also the know cause of a mumber of failed deliveries, which ins= tead was fully legitimate: many embedded (expecially into web site scripts)= SMTP small servers do that... and when they meet a graylist, fail!


Anyway, I am willing to consider support a logic for MX preference equal ze= ro means no transaction SHOULD be attempted. =A0Actually, what it SHOULD te= chnically mean is its not included in the total grouping/sorting of MX reco= rds. =A0This will allow for backward compatibility for the traditional NO M= X records yields a Try A record fallback logic (local policy dictating how = many tries are attempted).

I agree... MX 0 is likely a better "legalization" of a practice..= .


--
HLS



_______________________________________________
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=

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

--047d7bfcec5ceaec3f04ed3e4c84-- From duerst@it.aoyama.ac.jp Wed Dec 11 02:00:47 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B08D51AD8DB for ; Wed, 11 Dec 2013 02:00:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.508 X-Spam-Level: * X-Spam-Status: No, score=1.508 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_47=0.6, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ThuxKTnLJ3w for ; Wed, 11 Dec 2013 02:00:46 -0800 (PST) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 20A841AD73E for ; Wed, 11 Dec 2013 02:00:45 -0800 (PST) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id rBBA0SSh002460; Wed, 11 Dec 2013 19:00:28 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 5e35_0949_104e26ac_624b_11e3_abd4_001e6722eec2; Wed, 11 Dec 2013 19:00:27 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id EA1A2BF548; Wed, 11 Dec 2013 19:00:27 +0900 (JST) Message-ID: <52A837AD.3070304@it.aoyama.ac.jp> Date: Wed, 11 Dec 2013 19:00: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: "Murray S. Kucherawy" References: <20131211021808.14191.qmail@joyce.lan> <52A7D980.5090902@isdg.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-delany-nullmx-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 10:00:47 -0000 On 2013/12/11 17:49, Murray S. Kucherawy wrote: > Separate from the specific mechanism chosen, does the working group want to > put time into producing a document that proposes a standard way of saying > "We do not accept mail?" Having something like that seems to make sense. > We could use this document as a starting point for such work if the WG > thinks it's appropriate. If the answer to the first question is "yes" but > the second is "no", does anyone have an alternative proposal? Because of the nature of this WG, I'd prefer to work on improving specific drafts rather than starting from scratch. But I'm not enough of an email expert to say that this is the one and only right approach. Regards, Martin. > -MSK, APPSAWG co-chair > > > > On Tue, Dec 10, 2013 at 11:45 PM, Claudio Allocchio< > Claudio.Allocchio@garr.it> wrote: > >> >> On Tue, 10 Dec 2013, Hector Santos wrote: >> >> On 12/10/2013 9:18 PM, John Levine wrote: >>> >>>> Mark Delany originally wrote this draft back in 2005. I resuscitated >>>> it with his consent in July. I would like appsawg to adopt it and, >>>> assuming you don't hate it, publish it on the standards track. >>>> >>>> The point of null MX is really simple: if a domain does not receive >>>> mail, it publishes this DNS record to say so: >>>> >>>> blah.example MX 0 . >>>> >>>> Currently, if a domain has an A or AAAA record but no MX, there's no >>>> way to tell whether or not the A is supposed to be a default MX, so >>>> MTAs will hammer on it for a week before giving up. This prevents the >>>> hammering, and allows sending MTAs to return a useful error message >>>> right away rather than an ambiguous message after a week. >>>> >>>> I believe people have been using this informally since Mark published >>>> the original draft in 2005, and I haven't heard any bad reports. Note >>>> that SPF -all means I send no mail, which although highly correlated >>>> with I receive no mail, is not the same thing. >>>> >>> >>> I think the fallback to A is too prevalent to be ignored. I also thought >>> the "BCP" was: >>> >>> No MX ---> Single Shot A record (if any) attempt. >>> >>> That has been our implementation (as a default enabled feature) since day >>> one and I recall past discussions (in IETF-SMTP) where others has stated >>> they also followed a similar "No MX, Try A once" logic as well. This >>> avoided or minimized the "hammering" to just one attempt before a bounce is >>> initiated. >>> >> >> But this is also the know cause of a mumber of failed deliveries, which >> instead was fully legitimate: many embedded (expecially into web site >> scripts) SMTP small servers do that... and when they meet a graylist, fail! >> >> >> Anyway, I am willing to consider support a logic for MX preference equal >>> zero means no transaction SHOULD be attempted. Actually, what it SHOULD >>> technically mean is its not included in the total grouping/sorting of MX >>> records. This will allow for backward compatibility for the traditional NO >>> MX records yields a Try A record fallback logic (local policy dictating how >>> many tries are attempted). >>> >> >> I agree... MX 0 is likely a better "legalization" of a practice... >> >> >>> -- >>> HLS >>> >>> >>> >>> _______________________________________________ >>> 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 >> >> _______________________________________________ >> 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 fanf2@hermes.cam.ac.uk Wed Dec 11 03:16:32 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6022B1A1F55 for ; Wed, 11 Dec 2013 03:16:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_47=0.6, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1_we3u7c7Nh for ; Wed, 11 Dec 2013 03:16:30 -0800 (PST) Received: from ppsw-42.csi.cam.ac.uk (ppsw-42.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f42]) by ietfa.amsl.com (Postfix) with ESMTP id 11F951A1F5E for ; Wed, 11 Dec 2013 03:16:29 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:44296) by ppsw-42.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1VqhmA-00056v-6e (Exim 4.82_3-c0e5623) (return-path ); Wed, 11 Dec 2013 11:16:22 +0000 Received: from fanf2 by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1Vqhm9-00044S-VW (Exim 4.72) (return-path ); Wed, 11 Dec 2013 11:16:22 +0000 Date: Wed, 11 Dec 2013 11:16:21 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: John Levine In-Reply-To: <20131211021808.14191.qmail@joyce.lan> Message-ID: References: <20131211021808.14191.qmail@joyce.lan> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-delany-nullmx-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 11:16:32 -0000 John Levine wrote: > > The point of null MX is really simple: if a domain does not receive > mail, it publishes this DNS record to say so: > > blah.example MX 0 . > > I believe people have been using this informally since Mark published > the original draft in 2005, and I haven't heard any bad reports. Exim has implemented these semantics since version 4.31 released in March 2004. This was partly a side-effect of its experimental support for using SRV records to route mail which shares code with its MX handling, so Exim's MX handling gained SRV-style no-service semantics. Here's a quick sample of domains which are using MX 0 . - it seems to be popular with a certain class of fraudulent domains... Aenean.com account2.com adsl.xs4all.nl ahoo.com allweb.org alyahoo.com apsn.com ayhoo.com bedfordconservatives.com bricon.com cbnnig.com cdmnet.com cex.net cis.com complexmatters.com customsoffice.com dahoo.com daymassage.com dci.iran.com djd.net dominio.com elit.org eqp.net erepairs.com fcn.net fhy.org galacticgalaxy.com glk.com glotrade.com gmil.com gtat.net hjw.net hotmil.com inmovie.com johnnywatts.com karm.net kellerhewitt.com le.net leq.net loveki.com lsfco.com lxg.org mailadministrator.com mailoman.com mailyahoo.com majjo.com meupainel.com microlabtech.com missionnews.com mnmail.com ndyou.com nru.net ntinternet.com orci.org otrebor.com payqal.com prioritycatalyst.com repairbooking.com rfm.net senders.org tbranch.com tradelinkers.com uqs.org vel.org webmailprovider.com yaho.com yahoo.com.es yahoo.net yahooi.com yahoolotto.com yahoomail.com yahooo.com yanhoo.com yashoo.com yayhoo.com yhaoo.com yhoo.com yooho.com Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From fanf2@hermes.cam.ac.uk Wed Dec 11 03:25:12 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 812141AC85E for ; Wed, 11 Dec 2013 03:25:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJtvn0NYBCEX for ; Wed, 11 Dec 2013 03:25:11 -0800 (PST) Received: from ppsw-42.csi.cam.ac.uk (ppsw-42.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f42]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB091AC4AB for ; Wed, 11 Dec 2013 03:25:11 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:44605) by ppsw-42.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1VqhuY-0004g2-7I (Exim 4.82_3-c0e5623) (return-path ); Wed, 11 Dec 2013 11:25:02 +0000 Received: from fanf2 by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1VqhuY-0004c7-71 (Exim 4.72) (return-path ); Wed, 11 Dec 2013 11:25:02 +0000 Date: Wed, 11 Dec 2013 11:25:02 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Olafur Gudmundsson In-Reply-To: <01A730F8-0CCE-4BDC-9B23-45E6611C964A@ogud.com> Message-ID: References: <20131211021808.14191.qmail@joyce.lan> <01A730F8-0CCE-4BDC-9B23-45E6611C964A@ogud.com> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: John Levine , apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-delany-nullmx-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 11:25:12 -0000 Olafur Gudmundsson wrote: > > I think having the "." as server name is not a good idea It is a good choice because it matches what is already specified for SRV records and there has been running code working this way for nearly 10 years. > as it is always possible that an A or AAAA record will show up there. Haha. Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From ietf@rozanak.com Wed Dec 11 07:56:59 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B9821ADF5F; Wed, 11 Dec 2013 07:56:59 -0800 (PST) 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_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I87Nd3Ltp-CA; Wed, 11 Dec 2013 07:56:57 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 2C0121ADC03; Wed, 11 Dec 2013 07:56:57 -0800 (PST) Received: from kopoli ([141.89.226.146]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0MUp6q-1W2zUv3QoG-00YriV; Wed, 11 Dec 2013 10:56:50 -0500 From: "Hosnieh Rafiee" To: , , , References: In-Reply-To: Date: Wed, 11 Dec 2013 16:56:41 +0100 Message-ID: <004101cef689$99b93f90$cd2bbeb0$@rozanak.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0042_01CEF691.FB7F0720" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac72iSvPgVYgbXT9Tp2rb9e4S1H5BQAABB3g Content-Language: en-us X-Provags-ID: V02:K0:zsorZVhW8HgeflfAdkqx44XEhAz1ybLvxGiEIOStOdR l6APmNSpArup54roxvO9Uil1wRt+vU2S8n5NF1qF2IZvqk9Urn 8+zdGx8jNCUMNu+jibJdw9ekKma8VAmZiEv4xBVQiSoEt5odYs 8+lqvf5E0supOsi8Cg3PsJ17ki+OfTmOzzDdPJUXyaa6ofnfy4 b7E16COcPOxjWS1Rfxi7JypZv7WKu96HJrB3L/k2K+ADOmr/u6 a+XNj0mY4xcXCqvKwJAPc4RHfHikBps5GLzWWJBatVoqfzW+JN dzgpMURtRaqsMwVc0Da//ZBinNwv0QGMi+U/S8QCQ1tDIQ+mtU q3lmcZ2n6HT80UoXWwaI= Subject: [apps-discuss] new mailing list in security area X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 15:56:59 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0042_01CEF691.FB7F0720 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, There is a new mailing list in security area. The discussion will be fruitful if there are people from different backgrounds and not only security (security, operational views, application layer, network layer, privacy, etc). I already invited the people who I could remember. If I missed to invite you, just feel free to join this mailing list. The purpose is to find solutions to automate authentication and use network layer for this means but at the same time take care of performance, privacy and the possibility of this solution. https://www.ietf.org/mailman/listinfo/secauth This is the description of this mailing list. This list is for the discussions relating to using the IP layer as a means of authentication in other upper layers, especially the application layer, by considering both security and privacy on one hand and performance on the other hand. The goal is to come up with the implementation of a library for this purpose. The focus is on both nodes with limited resources (battery, memory, etc) and other nodes. We are also discussing the possible implementation or implementation barriers from operational points of view. Looking forward to see your participations there :-) Thanks, Smile Hosnieh ------=_NextPart_000_0042_01CEF691.FB7F0720 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Hello,

 

There = is a new mailing list in security area. The discussion will be fruitful = if there are people from different backgrounds and not only security = (security, operational views, application layer, network layer, privacy, = etc). I already invited the people who I could remember. If I missed to = invite you, just feel free to join this mailing list. The purpose is to = find solutions to automate authentication and use network layer for this = means but at the same time take care of performance, privacy and the = possibility of this solution.

https://www.ietf.org/mail= man/listinfo/secauth

 

This = is the description of this mailing list.

 

This = list is for the discussions relating to using the IP layer as a  = means of authentication in other upper layers, especially the  = application layer, by considering both security and privacy on one  = hand and performance on the other hand. The goal is to come up = with  the implementation of a library for this purpose. The focus = is on  both nodes with limited resources (battery, memory, etc) and = other nodes.

We are also = discussing the possible implementation or implementation  barriers = from operational points of view.

 

Looking forward to see your participations there = :-)

 

 

Thanks,

 

Smile

 

= Hosnieh

 

 

------=_NextPart_000_0042_01CEF691.FB7F0720-- From dhc@dcrocker.net Wed Dec 11 08:52:29 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4031A1AE182 for ; Wed, 11 Dec 2013 08:52:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rMJGIk1Nr7de for ; Wed, 11 Dec 2013 08:52:27 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id BE18D1AE17A for ; Wed, 11 Dec 2013 08:52:27 -0800 (PST) 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 rBBGq37W006651 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 11 Dec 2013 08:52:07 -0800 Message-ID: <52A897F4.5070403@dcrocker.net> Date: Wed, 11 Dec 2013 08:51:00 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "Murray S. Kucherawy" , Claudio Allocchio References: <20131211021808.14191.qmail@joyce.lan> <52A7D980.5090902@isdg.net> 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]); Wed, 11 Dec 2013 08:52:07 -0800 (PST) Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-delany-nullmx-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 16:52:29 -0000 On 12/11/2013 12:49 AM, Murray S. Kucherawy wrote: > Separate from the specific mechanism chosen, does the working group want > to put time into producing a document that proposes a standard way of > saying "We do not accept mail?" > > We could use this document as a starting point for such work if the WG > thinks it's appropriate. If the answer to the first question is "yes" > but the second is "no", does anyone have an alternative proposal? The proposed mechanism eliminates a relevant class of wasted mail traffic -- /prior to transmission across the open Internet/. The mechanism is quite simple, quite inexpensive for the domain owner, and essentially free for the host attempting transmission. It's unlikely anyone is going to propose a better mechanism for handling this class of traffic. The draft is straightforward, seems to be well-structured and reasonably thorough. It needs wordsmithing, but probably does not need massive technical enhancement. If that doesn't make it an excellent, direct candidate for the apps wg, I can't imagine what does. Besides that, any IETF-related draft that might be useful and is only 5 pages long ought to be published, just to show we are capable of promoting short documents... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From ned.freed@mrochek.com Wed Dec 11 09:28:59 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39D791ADF6B for ; Wed, 11 Dec 2013 09:28:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j2lBibVVy512 for ; Wed, 11 Dec 2013 09:28:57 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 6913F1AD7C0 for ; Wed, 11 Dec 2013 09:28:57 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P1TIS2RUOG000OK7@mauve.mrochek.com> for apps-discuss@ietf.org; Wed, 11 Dec 2013 09:23:50 -0800 (PST) MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=iso-8859-1 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P1T68P6PZK0000AS@mauve.mrochek.com>; Wed, 11 Dec 2013 09:23:47 -0800 (PST) Message-id: <01P1TIS1LKO80000AS@mauve.mrochek.com> Date: Wed, 11 Dec 2013 09:20:03 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Wed, 11 Dec 2013 00:49:00 -0800" References: <20131211021808.14191.qmail@joyce.lan> <52A7D980.5090902@isdg.net> To: "Murray S. Kucherawy" Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-delany-nullmx-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 17:28:59 -0000 > Separate from the specific mechanism chosen, does the working group want to > put time into producing a document that proposes a standard way of saying > "We do not accept mail?" I'm in favor of it. > We could use this document as a starting point for such work if the WG > thinks it's appropriate. If the answer to the first question is "yes" but > the second is "no", does anyone have an alternative proposal? I think the current proposal needs to be the starting point. I'll add that from what I've seen change for change's sake, while never a good idea, is particularly likely to backfire when it comes to mechanisms like this. Ned From dave@cridland.net Wed Dec 11 09:32:55 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFAD91ADF90 for ; Wed, 11 Dec 2013 09:32:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9bKVDTdIvYW for ; Wed, 11 Dec 2013 09:32:54 -0800 (PST) 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 39C731ADF82 for ; Wed, 11 Dec 2013 09:32:54 -0800 (PST) Received: by mail-ob0-f178.google.com with SMTP id uz6so7247214obc.37 for ; Wed, 11 Dec 2013 09:32:48 -0800 (PST) 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=W+27meuB4Ve7gbl0xZtSepLsH/cRa5NaLonIvWQoLNY=; b=fkG3J4jCk27meV8Y5v/cAcc0ReGAsSrNvdA5A7L4M1m1U2QQdld1HgjorlG5HSUXYD NmVgcG67SQmFc3EP78cIXXL5EINVXhzz67P3H/eqLB3qo3f/Ebv4bMaAjHuCT2oFGcUe je8SXK6LZBCBq9tW0sN+CKZnrxJHGHl9mZEUQ= 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=W+27meuB4Ve7gbl0xZtSepLsH/cRa5NaLonIvWQoLNY=; b=jVBEoNzAObpaLD62mr66y3Cl15Xd8nhCLj9F7h3qISyPzwvNTGPDhwTxeWD2YtYLGL VZzCmm/CEhr/4woMgja6YURHPDDmRGzlf+wmCksu363rUSCk4JXPuaIHN7jT5HrzKqW3 xjD6zvfPqCnAjxx+w3ojppeydEazEYM5P6sN34waCoFP8k++/PbmcVOFwN8rfU1cRro9 PFbKknbXt9OMeq6blWwcrj16Ow+Wc9qRA21kyja4P6Vqk9u+M6wWColIu43MKEMQ5Og8 HzcFypp8ODxjNJDt7EW6HifZVP4YbuzM8G6NFf8Dz5s3ChlrjDe4/i/KlvHCKq1AIN8O g86Q== X-Gm-Message-State: ALoCoQlxPmk+/Mnncv/VUQLpJitqlmxmoNri2J9qfYE4y58gLcTOhugUZQU8wozsMzt0qLPFpaOA MIME-Version: 1.0 X-Received: by 10.182.88.202 with SMTP id bi10mr2075450obb.52.1386783168488; Wed, 11 Dec 2013 09:32:48 -0800 (PST) Received: by 10.60.144.38 with HTTP; Wed, 11 Dec 2013 09:32:48 -0800 (PST) In-Reply-To: References: <20131211021808.14191.qmail@joyce.lan> <52A7D980.5090902@isdg.net> Date: Wed, 11 Dec 2013 17:32:48 +0000 Message-ID: From: Dave Cridland To: "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=089e0111be7623794104ed459ecf Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-delany-nullmx-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 17:32:55 -0000 --089e0111be7623794104ed459ecf Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Dec 11, 2013 at 8:49 AM, Murray S. Kucherawy w= rote: > Separate from the specific mechanism chosen, does the working group want > to put time into producing a document that proposes a standard way of > saying "We do not accept mail?" > > Yes. > We could use this document as a starting point for such work if the WG > thinks it's appropriate. If the answer to the first question is "yes" bu= t > the second is "no", does anyone have an alternative proposal? > > As Dave Crocker says, it's a useful draft and only 5 pages, and as Tony Finch says, this one is essentially a parallel to SRV, and deployed already= . I'm in support of adopting. Two comments on the draft as-is: Second paragraph of =A74 suggests that if there are multiple MX RRs includi= ng the NULL MX record, then the NULL MX record is treated as any other; this seems unlikely to be actually desirable. Instead, I suggest that it is ignored, with a note that if it is merely treated as any other MX RR, it is unlikely to cause significant damage. I'd be fascinated to know what Exim does currently. The Security Considerations in =A76 might point out that a single NULL MX R= R might be spoofable more easily via poison cache style attacks - it's not entirely clear to me that this would cause more problems than any other DNS poisoning attack based around MX records, but my gut feeling is that it's a slightly softer target, and could be less immediately identifiable. Dave. --089e0111be7623794104ed459ecf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On W= ed, Dec 11, 2013 at 8:49 AM, Murray S. Kucherawy <superuser@gmail.com> wrote:
Separate from the spec= ific mechanism chosen, does the working group want to put time into produci= ng a document that proposes a standard way of saying "We do not accept= mail?"


Yes.
=A0
We could use this docume= nt as a starting point for such work if the WG thinks it's appropriate.= =A0 If the answer to the first question is "yes" but the second i= s "no", does anyone have an alternative proposal?


As Dave Crocker says, it&#= 39;s a useful draft and only 5 pages, and as Tony Finch says, this one is e= ssentially a parallel to SRV, and deployed already.

I'm in support of adopting.

Two comments = on the draft as-is:

Second paragraph of =A74 sugge= sts that if there are multiple MX RRs including the NULL MX record, then th= e NULL MX record is treated as any other; this seems unlikely to be actuall= y desirable. Instead, I suggest that it is ignored, with a note that if it = is merely treated as any other MX RR, it is unlikely to cause significant d= amage. I'd be fascinated to know what Exim does currently.

The Security Considerations in =A76 might point out tha= t a single NULL MX RR might be spoofable more easily via poison cache style= attacks - it's not entirely clear to me that this would cause more pro= blems than any other DNS poisoning attack based around MX records, but my g= ut feeling is that it's a slightly softer target, and could be less imm= ediately identifiable.

Dave.
--089e0111be7623794104ed459ecf-- From alexey.melnikov@isode.com Wed Dec 11 09:53:20 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBAD31AE066 for ; Wed, 11 Dec 2013 09:53:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 68Io6kcIlOoo for ; Wed, 11 Dec 2013 09:53:19 -0800 (PST) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 4F1641ADF97 for ; Wed, 11 Dec 2013 09:53:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1386784393; d=isode.com; s=selector; i=@isode.com; bh=Ty2gFbiJtQaomJIJ31s9a2WSSHImGZqjFAuvjLdhwQQ=; 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=n03sHXQnwC9nYX9DExt21aJNz1WPy+VKBbsBJ4sO2zjqB5cxYJ0S3Md+iYYIUjFzrHH33S kqulFZVFC/bwiijq6Htrh9az5CRMO2O71/9MI4j+pwtowe5D62I/mzzH5ryKlxldic8j/w E12bXw9EzvRwmnY0/VWmiSMWY6bzLPo=; Received: from [172.16.1.29] (richard.isode.com [62.3.217.249]) by statler.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 11 Dec 2013 17:53:13 +0000 Message-ID: <52A8A68E.2040805@isode.com> Date: Wed, 11 Dec 2013 17:53:18 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 To: "Murray S. Kucherawy" References: <20131211021808.14191.qmail@joyce.lan> <52A7D980.5090902@isdg.net> 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] draft-delany-nullmx-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 17:53:21 -0000 On 11/12/2013 08:49, Murray S. Kucherawy wrote: > Separate from the specific mechanism chosen, does the working group > want to put time into producing a document that proposes a standard > way of saying "We do not accept mail?" Yes. > We could use this document as a starting point for such work if the WG > thinks it's appropriate. Yes. > If the answer to the first question is "yes" but the second is "no", > does anyone have an alternative proposal? From ned.freed@mrochek.com Wed Dec 11 10:44:37 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74A321AE121 for ; Wed, 11 Dec 2013 10:44:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e9QzE1iEN4fL for ; Wed, 11 Dec 2013 10:44:36 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 505231AE109 for ; Wed, 11 Dec 2013 10:44:36 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P1TLEVBIV4000MJL@mauve.mrochek.com> for apps-discuss@ietf.org; Wed, 11 Dec 2013 10:39:29 -0800 (PST) MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=iso-8859-1 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P1T68P6PZK0000AS@mauve.mrochek.com>; Wed, 11 Dec 2013 10:39:24 -0800 (PST) Message-id: <01P1TLET6LV00000AS@mauve.mrochek.com> Date: Wed, 11 Dec 2013 10:38:45 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Tue, 10 Dec 2013 09:02:37 -0800" References: <20131210045414.4330.qmail@joyce.lan> <01P1RIJXPOTS0000AS@mauve.mrochek.com> <01P1S24VNQDM0000AS@mauve.mrochek.com> To: "Murray S. Kucherawy" Cc: John Levine , Ned Freed , IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rrvs-header-field-04.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 18:44:37 -0000 > OK, I think the draft already says all of this. I guess I misunderstood > your earlier message. Let me know if you think there's other text that > needs to be added. I haven't had a chance to review the current draft in detail, but I think the language in the draft about this is fine. Ned From scott.brim@gmail.com Wed Dec 11 11:02:32 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B33891ADBCD; Wed, 11 Dec 2013 11:02:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VrvwBGx2pYfh; Wed, 11 Dec 2013 11:02:31 -0800 (PST) Received: from mail-oa0-x230.google.com (mail-oa0-x230.google.com [IPv6:2607:f8b0:4003:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id D517A1AD8D5; Wed, 11 Dec 2013 11:02:30 -0800 (PST) Received: by mail-oa0-f48.google.com with SMTP id l6so7725320oag.21 for ; Wed, 11 Dec 2013 11:02:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=795yZDj7DdiP12YnAA7TxcketLfq0rVudJbrto9egtY=; b=lTDwakyGst7PvmVqYGCrcWxsxos8MAniri3M0aco11rnMLOu+KUi1KNBXFOuCEugkL 3OLPFIS9i74cUOBuhLSgqkdQZBCSth6JzP3YoaO8NWIvSMzhwiKnv7gsJ5oFwIzkWTQO 57DizCFCJvXurkFSVQ/5/xjpR/oW5BhiR22MkbCFwUWfcE6plWj6MeccMFVz1sO0oJ+Z UtBGr/CW4BysZJs1QQN7fsnAy1NzhCZB+ssdI/fv9hcL7Ruu2xe81lVVgbP+hhfK4kMV dwD8xvlNrKnGEY3uowFF3g60GpTJA1pwDzuftkHEMjbRH02w8Xp+XQgs2rWxeSgEAH2l km3Q== X-Received: by 10.60.146.229 with SMTP id tf5mr2362568oeb.27.1386788545081; Wed, 11 Dec 2013 11:02:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.48.9 with HTTP; Wed, 11 Dec 2013 11:02:04 -0800 (PST) In-Reply-To: <004101cef689$99b93f90$cd2bbeb0$@rozanak.com> References: <004101cef689$99b93f90$cd2bbeb0$@rozanak.com> From: Scott Brim Date: Wed, 11 Dec 2013 14:02:04 -0500 Message-ID: To: Hosnieh Rafiee Content-Type: text/plain; charset=ISO-8859-1 Cc: IPv6 Ops WG , IETF Security Area Advisory Group , "<, apps-discuss@ietf.org>, " , sacm@ietf.org Subject: Re: [apps-discuss] new mailing list in security area X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 19:02:32 -0000 On Wed, Dec 11, 2013 at 10:56 AM, Hosnieh Rafiee wrote: > The purpose > is to find solutions to automate authentication and use network layer for > this means but at the same time take care of performance, privacy and the > possibility of this solution. > > https://www.ietf.org/mailman/listinfo/secauth Hosnieh, I look forward to this. I start out skeptical, because I suspect that all the reasons for the end-to-end argument will be applicable here, but I remain open-minded. Scott From hsantos@isdg.net Wed Dec 11 11:14:50 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDF5F1AE12C for ; Wed, 11 Dec 2013 11:14:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.001 X-Spam-Level: X-Spam-Status: No, score=-102.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GkgYh9_LZvdb for ; Wed, 11 Dec 2013 11:14:47 -0800 (PST) Received: from ntbbs.santronics.com (ntbbs.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id F11071AE13C for ; Wed, 11 Dec 2013 11:14:46 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2979; t=1386789274; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=ZNnAvJTwj4XBbDMKZBnFynRTXqo=; b=avC5lfJ9tyjt+ZddMJxp RVafCu9Q5654Y8EWUW/3BhBb5ASnt/NQiOLsR1gbIdcKzfkpx2lTR6hZzsZzqc/O oUmivv2FOJB6VQ37DXwgj/ilN1hY7VoSO8HdEb6E4/jWpP0ziNn+3gw9vRRSqUYn M2SZQVjqjwHe6ThOey24DDE= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Wed, 11 Dec 2013 14:14:34 -0500 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 (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 366776983.10114.5040; Wed, 11 Dec 2013 14:14:33 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2979; t=1386788766; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=6k3Rpnd hFcS19uLOqnp9UqOvyozPVZMthljt+q0cm40=; b=VKb0KgogQCr3LH7bdH+jIQ4 sSJtCqx+MOLgMp6yHJK2ip2QzcmxclC+9/RvSb0a2Elhfo02QLMU/Ak2bPJvF4yp 1MecvTR0P0fmloRU6TVXRaDz9rfDdoCzP7nAdylnRWtOcViC8n2yO+6XvrEgrB4S MliVqtLpTG4tdZi04NBQ= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Wed, 11 Dec 2013 14:06:06 -0500 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 4108079816.9.4128; Wed, 11 Dec 2013 14:06:05 -0500 Message-ID: <52A8B998.1060904@isdg.net> Date: Wed, 11 Dec 2013 14:14:32 -0500 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: "Murray S. Kucherawy" References: <20131211021808.14191.qmail@joyce.lan> <52A7D980.5090902@isdg.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-delany-nullmx-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 19:14:51 -0000 On 12/11/2013 3:49 AM, Murray S. Kucherawy wrote: > Separate from the specific mechanism chosen, does the working group > want to put time into producing a document that proposes a standard > way of saying "We do not accept mail?" > > We could use this document as a starting point for such work if the WG > thinks it's appropriate.ďż˝ If the answer to the first question is "yes" > but the second is "no", does anyone have an alternative proposal? > > -MSK, APPSAWG co-chair The beauty of the NULLMX proposal is that it would fit in with existing MX lookups logic for mail senders. The lookup discovery logic exist. It would be relatively easy to add logic to exclude the MX=0 record from the MX grouping/sorting required to be done already and also use this mx=0 condition to "skip" the outbound transaction or end the attempts so that a bounce is started. But in general, I agree with a consideration for a new all encompassing, flexible, single source, domain-based receiver policy discovery protocol that will combine many (and future) receiver attributes concepts along these lines. Here are other server/receiver discovery attributes that can be very useful leveraging information for mail senders: - We do not accept mail. - We only accept authenticated mail (no public anonymous mail). - We accept anonymous mail during X to Y hours. Z hours reserved for private transactions. (This allows for the DMA market to coexist during controlled hours). - This service requires ALL transactions to be DKIM signed. - We don't allow mail over X MB/GB size. - We will perform SPF checks. - WE WILL REJECT ON SPF -ALL policy Results! - We will perform DKIM checks. - We will do greylisting. - We will limit connections to X clients. - WE WILL REJECT ON ADSP reject policy results. - WE WILL REJECT ON DMARC reject policy results. - WE SUPPORT RRVS reject results. and so on. Such a flexible server/receiver protocol will be a major benefit to the internet mail framework to help reduces all sorts of overheads, waste and also better secure security requirements in transactions. It can also assist in raising the email-bar and migration to stronger enforcement policies. The 2006 DSAP [1] draft explored the idea of allowing companies to query customer's email address receiver policies for possible DKIM signing policies and restrictions. So if a BANK required its eBanking users to have a DKIM-checking email address receiver, it can double check this strong transaction requirement and if also a vendor email domain address that does offer DKIM support. Same idea applies for other conditions we want the receivers to have today. Certainly, we can do much of this within the existing ESMTP framework (expose Receiver capabilities during the EHLO response). -- HLS [1] DKIM Signature Authorization Protocol http://tools.ietf.org/html/draft-santos-dkim-dsap-00 From ietf@rozanak.com Wed Dec 11 12:13:49 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD7611AE0E3; Wed, 11 Dec 2013 12:13:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E6Jo81IobzgX; Wed, 11 Dec 2013 12:13:48 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 07E9E1ADFA1; Wed, 11 Dec 2013 12:13:48 -0800 (PST) Received: from kopoli (g231191095.adsl.alicedsl.de [92.231.191.95]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0LmbFL-1VIKM82IcN-00a1zI; Wed, 11 Dec 2013 15:13:42 -0500 From: "Hosnieh Rafiee" To: "'Mouse'" , , , , References: <004101cef689$99b93f90$cd2bbeb0$@rozanak.com> <201312111940.OAA29160@Chip.Rodents-Montreal.ORG> In-Reply-To: <201312111940.OAA29160@Chip.Rodents-Montreal.ORG> Date: Wed, 11 Dec 2013 21:13:30 +0100 Message-ID: <004201cef6ad$7b2991a0$717cb4e0$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEbq7nIPHMLdLerYKkR6aMsmA3rUQIznEoGm6RhcbA= Content-Language: en-us X-Provags-ID: V02:K0:oflu91ICOJRXypAx6hSBhPz7vQ4+vbOdldVUBGMY/Et hofng2iypgYTDfKHK0x1C/4hv746RJi9VZ3y73mZ3LMPV7FtGr NZlGxgw/5QelW9ArmkN4gC881vsmN22OJpcJA7e+a73C4ZnEyp EGBHWVovX4KbZ0KVIs2MJewgcqvKVpRiV5MwIDUUfe/41GJSQ0 553grgsCeCQj6yYyaEtdjPxjRFNwos8aFvrDXa1CXo6ME7Eiwc 72lEwpI6JvJHPkiBVoi1Sqagj5p5qfOD2lXpF0grRaUHl/Uq9I 9zSvaelSzxV+jS+YaTZEFyc77G7NNjV52EjL/a4kzSEfEzYyQT wW5oZHaFG5Y/QX8ad1bU= Subject: Re: [apps-discuss] [saag] new mailing list in security area X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 20:13:49 -0000 Hi, > -----Original Message----- > From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Mouse > Sent: Wednesday, December 11, 2013 8:40 PM > To: saag@ietf.org > Subject: Re: [saag] new mailing list in security area > > > There is a new mailing list in security area. [...] > > Sounds possibly up my alley. But... > > > Looking forward to see your participations there :-) > > ...it'd help if you gave the list management address (or at least the list post > address, to which I trust we can just append -request). All I saw was a Web > URL (oddly, present twice, with no explanation of why), and one that was > HTTPS and thus useless to me even if I were willing to use the Web to manage > email (which I'm not). To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/secauth or, via email, send a message with subject or body 'help' to secauth-request@ietf.org You can reach the person managing the list at: secauth-owner@ietf.org Send secaut mailing list submissions to: secauth@ietf.org thanks, smile, Hosnieh From internet-drafts@ietf.org Wed Dec 11 14:43:49 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25E9A1AE053; Wed, 11 Dec 2013 14:43:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SiB3hx1ZYWbs; Wed, 11 Dec 2013 14:43:47 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B99811AE1D3; Wed, 11 Dec 2013 14:43:46 -0800 (PST) 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.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131211224346.9714.84088.idtracker@ietfa.amsl.com> Date: Wed, 11 Dec 2013 14:43:46 -0800 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-sieve-duplicate-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 22:43:49 -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 : Sieve Email Filtering: Detecting Duplicate Deliveries Author(s) : Stephan Bosch Filename : draft-ietf-appsawg-sieve-duplicate-02.txt Pages : 11 Date : 2013-12-11 Abstract: This document defines a new test command "duplicate" for the "Sieve" email filtering language. This test adds the ability to detect duplicate message deliveries. The main application for this new test is handling duplicate deliveries commonly caused by mailing list subscriptions or redirected mail addresses. The detection is normally performed by matching the message ID to an internal list of message IDs from previously delivered messages. For more complex applications, the "duplicate" test can also use the content of a specific header or other parts of the message. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-sieve-duplicate There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-sieve-duplicate-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-sieve-duplicate-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 stephan@rename-it.nl Wed Dec 11 14:50:04 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 193F81AE1FA for ; Wed, 11 Dec 2013 14:50:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.194 X-Spam-Level: X-Spam-Status: No, score=0.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CBja8JYhdC4z for ; Wed, 11 Dec 2013 14:50:02 -0800 (PST) Received: from drpepper.rename-it.nl (drpepper.rename-it.nl [217.119.238.16]) by ietfa.amsl.com (Postfix) with ESMTP id 8E4AF1AE19B for ; Wed, 11 Dec 2013 14:50:01 -0800 (PST) Received: from klara.student.utwente.nl ([130.89.162.218]:55923 helo=[10.168.3.2]) by drpepper.rename-it.nl with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1VqsbG-0007OF-D0; Wed, 11 Dec 2013 23:49:52 +0100 Message-ID: <52A8EC0B.2000807@rename-it.nl> Date: Wed, 11 Dec 2013 23:49:47 +0100 From: Stephan Bosch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Cyrus Daboo References: <1BC1A404FE3E89FEA37FAB45@caldav.corp.apple.com> <52A03BD6.8020303@rename-it.nl> In-Reply-To: <52A03BD6.8020303@rename-it.nl> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-RenameIT-MailScanner-SpamScore: -2.3 (--) X-RenameIT-MailScanner-SpamCheck: No, score=-2.3 required=5.0 tests=ALL_TRUSTED, BAYES_00 autolearn=ham version=3.3.1 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Reviewers, please (was Re: I-D Action: draft-ietf-appsawg-sieve-duplicate-01.txt) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 22:50:04 -0000 Hi, On 12/5/2013 9:39 AM, Stephan Bosch wrote: > Hi, > > On 12/4/2013 4:59 PM, Cyrus Daboo wrote: >> I only minor/editorial issues. This is a potentially useful extension >> and should be standardized. Most of your comments were processed in the -02 I just uploaded. Ned answered your question about the :handle argument. Is that answer satisfactory? Do you think that topic requires more clarification in the document? Regards, Stephan. From stephan@rename-it.nl Wed Dec 11 14:54:47 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9E421AE211 for ; Wed, 11 Dec 2013 14:54:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.194 X-Spam-Level: X-Spam-Status: No, score=0.194 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oTC1-Ui5a5Hr for ; Wed, 11 Dec 2013 14:54:46 -0800 (PST) Received: from drpepper.rename-it.nl (drpepper.rename-it.nl [217.119.238.16]) by ietfa.amsl.com (Postfix) with ESMTP id 06D761AE20D for ; Wed, 11 Dec 2013 14:54:44 -0800 (PST) Received: from klara.student.utwente.nl ([130.89.162.218]:55997 helo=[10.168.3.2]) by drpepper.rename-it.nl with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Vqsfr-0007TG-KW for apps-discuss@ietf.org; Wed, 11 Dec 2013 23:54:38 +0100 Message-ID: <52A8ED29.3030802@rename-it.nl> Date: Wed, 11 Dec 2013 23:54:33 +0100 From: Stephan Bosch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20131211224346.9714.84088.idtracker@ietfa.amsl.com> In-Reply-To: <20131211224346.9714.84088.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-RenameIT-MailScanner-SpamScore: -2.3 (--) X-RenameIT-MailScanner-SpamCheck: No, score=-2.3 required=5.0 tests=ALL_TRUSTED, BAYES_00 autolearn=ham version=3.3.1 Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-sieve-duplicate-02.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 22:54:47 -0000 On 12/11/2013 11:43 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Applications Area Working Group Working Group of the IETF. > > Title : Sieve Email Filtering: Detecting Duplicate Deliveries > Author(s) : Stephan Bosch > Filename : draft-ietf-appsawg-sieve-duplicate-02.txt > Pages : 11 > Date : 2013-12-11 > > Abstract: > This document defines a new test command "duplicate" for the "Sieve" > email filtering language. This test adds the ability to detect > duplicate message deliveries. The main application for this new test > is handling duplicate deliveries commonly caused by mailing list > subscriptions or redirected mail addresses. The detection is > normally performed by matching the message ID to an internal list of > message IDs from previously delivered messages. For more complex > applications, the "duplicate" test can also use the content of a > specific header or other parts of the message. This new version addresses comments by Cyrus Daboo (see thread of about a week ago). More reviews are welcome! Regards, Stephan. From superuser@gmail.com Wed Dec 11 15:35:45 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 056B21AE1A1 for ; Wed, 11 Dec 2013 15:35:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iiiaryXayRFZ for ; Wed, 11 Dec 2013 15:35:43 -0800 (PST) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 1C73E1AE19A for ; Wed, 11 Dec 2013 15:35:42 -0800 (PST) Received: by mail-we0-f180.google.com with SMTP id t61so7173749wes.39 for ; Wed, 11 Dec 2013 15:35:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mjEHjcDpwm13N3v5tctgqaVUus8tltBNQYTSqsipklY=; b=xgJKujKrNgyZM6kv52alhoHrFKbtuEP5Fd8FhUcMD2vrxNqoxRVXn59E63JBdbI1t5 jrvOnCrj0EXnLakrQvMbIrYvqrOXW3mHdDhL8YZPnzVOiOo+93q5ErtXErXjnQwX1Yna wWglU/odW436AGAcjFMoyaNhvCOEekRbzj3mqGlzs+PB2pHIrNA2O9XXxkCwd5kdrWmW QGiCCFdGb3PdNpwtcoWH7zyQGDw/FrnZ1tqsL/hCb9JHRG1e75U+1ayanF/WlEud7sEh sGu2RBs92hfje2JN5wggaVUyDyBztSwrKowu7csKdLkhONP2/0AFbtNKX0Znr5/CMPHS ngpQ== MIME-Version: 1.0 X-Received: by 10.194.104.66 with SMTP id gc2mr3695566wjb.75.1386804936965; Wed, 11 Dec 2013 15:35:36 -0800 (PST) Received: by 10.180.84.106 with HTTP; Wed, 11 Dec 2013 15:35:36 -0800 (PST) In-Reply-To: <52A8A68E.2040805@isode.com> References: <20131211021808.14191.qmail@joyce.lan> <52A7D980.5090902@isdg.net> <52A8A68E.2040805@isode.com> Date: Wed, 11 Dec 2013 15:35:36 -0800 Message-ID: From: "Murray S. Kucherawy" To: Alexey Melnikov Content-Type: multipart/alternative; boundary=089e0102ef84a403b804ed4aaf0e Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-delany-nullmx-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 23:35:45 -0000 --089e0102ef84a403b804ed4aaf0e Content-Type: text/plain; charset=ISO-8859-1 I don't believe we can do a formal call for adoption until we have at least a couple of our current documents submitted to the IESG. In the past we've received complaints when we've had a docket of active WG documents at the current size, so we can't enlarge it now. Perhaps this is incentive for people interested in draft-delany-nullmx to submit reviews for the other documents that are waiting for them, so that we can get them out of the way... :-) -MSK On Wed, Dec 11, 2013 at 9:53 AM, Alexey Melnikov wrote: > On 11/12/2013 08:49, Murray S. Kucherawy wrote: > >> Separate from the specific mechanism chosen, does the working group want >> to put time into producing a document that proposes a standard way of >> saying "We do not accept mail?" >> > Yes. > > > We could use this document as a starting point for such work if the WG >> thinks it's appropriate. >> > Yes. > > > If the answer to the first question is "yes" but the second is "no", does >> anyone have an alternative proposal? >> > > --089e0102ef84a403b804ed4aaf0e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I don't believe we can do a formal call for adopt= ion until we have at least a couple of our current documents submitted to t= he IESG.=A0 In the past we've received complaints when we've had a = docket of active WG documents at the current size, so we can't enlarge = it now.

Perhaps this is incentive for people interested in draft-delany-n= ullmx to submit reviews for the other documents that are waiting for them, = so that we can get them out of the way... :-)

-MSK



On Wed, Dec 1= 1, 2013 at 9:53 AM, Alexey Melnikov <alexey.melnikov@isode.com= > wrote:
On 11/12/2013 08:49, Murra= y S. Kucherawy wrote:
Separate from the specific mechanism chosen, does the working group want to= put time into producing a document that proposes a standard way of saying = "We do not accept mail?"
Yes.


We could use this document as a starting point for such work if the WG thin= ks it's appropriate.
Yes.


If the answer to the first question is "yes" but the second is &q= uot;no", does anyone have an alternative proposal?


--089e0102ef84a403b804ed4aaf0e-- From internet-drafts@ietf.org Wed Dec 11 15:39:27 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC3201AE11B; Wed, 11 Dec 2013 15:39:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kQDJFWcxU3jE; Wed, 11 Dec 2013 15:39:26 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 780421AE1CC; Wed, 11 Dec 2013 15:39:24 -0800 (PST) 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.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131211233924.25337.38138.idtracker@ietfa.amsl.com> Date: Wed, 11 Dec 2013 15:39:24 -0800 Cc: apps-discuss@ietf.org Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-rrvs-header-field-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Dec 2013 23:39: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 : The Require-Recipient-Valid-Since Header Field and SMTP = Service Extension Author(s) : William J. Mills Murray S. Kucherawy Filename : draft-ietf-appsawg-rrvs-header-field-05.txt Pages : 20 Date : 2013-12-11 Abstract: This document defines an extension for the Simple Mail Transfer Protocol called RRVS, and a header field called Require-Recipient- Valid-Since, to provide a method for senders to indicate to receivers the time when the sender last confirmed the ownership of the target mailbox. This can be used to detect changes of mailbox ownership, and thus prevent mail from being delivered to the wrong party. The intended use of these facilities is on automatically generated messages that might contain sensitive information, though it may also be useful in other applications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-appsawg-rrvs-header-field There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-appsawg-rrvs-header-field-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-rrvs-header-field-05 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 superuser@gmail.com Wed Dec 11 16:22:00 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 421DE1AD791 for ; Wed, 11 Dec 2013 16:22:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OAWLdSaIrMsm for ; Wed, 11 Dec 2013 16:21:58 -0800 (PST) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 89E3E1A8028 for ; Wed, 11 Dec 2013 16:21:58 -0800 (PST) Received: by mail-we0-f180.google.com with SMTP id t61so7157037wes.25 for ; Wed, 11 Dec 2013 16:21:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=fpV3iIQyi68L/oZtiUrcrRbEo91Fd85z3odUsja7Ep4=; b=nJX0zxO6sH34vaAC4VlQtc5ZfKCRuOGyXwOeJd9gfQH9dlgM08FmE8b/Kyert6f0OS TGOtTD/y57H0JWTB+8rtnc11uwtZ3UyINIzF2bAl+/08UXgKS+z/C1ne157q2DjiZjNr JIMN18fH9QRyEhMpbLl21QOhZXakWDbHH0FW1Go/AL4yXhr+IbYTGjH3JiN/xm4YTgCa ZP++o4n/uQ/ZzDhbBIe9sfLcAxL+b2xshoOW3fY4+I0sBsVeRfactlUiBwzu1npsxQXc 2rhLvDF9mbSwvqr+1QqyqFZFT/nsgUNxh8Aa3voyXsXguGDxVxAiOulcrEPn2KD4hzsv gZJQ== MIME-Version: 1.0 X-Received: by 10.180.39.43 with SMTP id m11mr2445027wik.8.1386807712369; Wed, 11 Dec 2013 16:21:52 -0800 (PST) Received: by 10.180.84.106 with HTTP; Wed, 11 Dec 2013 16:21:52 -0800 (PST) In-Reply-To: <20131211233924.25337.38138.idtracker@ietfa.amsl.com> References: <20131211233924.25337.38138.idtracker@ietfa.amsl.com> Date: Wed, 11 Dec 2013 16:21:52 -0800 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=001a1134cdd811530f04ed4b5507 Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rrvs-header-field-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 00:22:00 -0000 --001a1134cdd811530f04ed4b5507 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Dec 11, 2013 at 3:39 PM, 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 Require-Recipient-Valid-Since Header Field > and SMTP Service Extension > Author(s) : William J. Mills > Murray S. Kucherawy > Filename : draft-ietf-appsawg-rrvs-header-field-05.txt > Pages : 20 > Date : 2013-12-11 > > Abstract: > This document defines an extension for the Simple Mail Transfer > Protocol called RRVS, and a header field called Require-Recipient- > Valid-Since, to provide a method for senders to indicate to receivers > the time when the sender last confirmed the ownership of the target > mailbox. This can be used to detect changes of mailbox ownership, > and thus prevent mail from being delivered to the wrong party. > > The intended use of these facilities is on automatically generated > messages that might contain sensitive information, though it may also > be useful in other applications. > Addresses the suggested changes received since -04. Thanks to everyone that provided comments! -MSK --001a1134cdd811530f04ed4b5507 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Dec 11, 2013 at 3:39 PM, <internet-drafts= @ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=A0This draft is a work item of the Applications Area Working Group Working= Group of the IETF.

=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : The Require-Recipient-Valid-Sin= ce Header Field and SMTP Service Extension
=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : William J. Mills
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Murray S. Kucherawy
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-appsawg-rrvs-header-fi= eld-05.txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 20
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-12-11

Abstract:
=A0 =A0This document defines an extension for the Simple Mail Transfer
=A0 =A0Protocol called RRVS, and a header field called Require-Recipient- =A0 =A0Valid-Since, to provide a method for senders to indicate to receiver= s
=A0 =A0the time when the sender last confirmed the ownership of the target<= br> =A0 =A0mailbox. =A0This can be used to detect changes of mailbox ownership,=
=A0 =A0and thus prevent mail from being delivered to the wrong party.

=A0 =A0The intended use of these facilities is on automatically generated =A0 =A0messages that might contain sensitive information, though it may als= o
=A0 =A0be useful in other applications.

Addresses the suggested changes received since -04.=A0 Thanks to everyone = that provided comments!

-MSK
--001a1134cdd811530f04ed4b5507-- From franck@peachymango.org Wed Dec 11 16:57:56 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D674F1ADF95 for ; Wed, 11 Dec 2013 16:57:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id slCt1Z2dyu5e for ; Wed, 11 Dec 2013 16:57:55 -0800 (PST) Received: from smtp.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id 5ECB91AD791 for ; Wed, 11 Dec 2013 16:57:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 778B34F4216; Wed, 11 Dec 2013 18:57:49 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S2nX-jSGf6xQ; Wed, 11 Dec 2013 18:57:49 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 592F54F42DF; Wed, 11 Dec 2013 18:57:49 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 422624F4216; Wed, 11 Dec 2013 18:57:49 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id lRkIXTutPxCD; Wed, 11 Dec 2013 18:57:49 -0600 (CST) Received: from mail-2.01.com (mail.01.com [172.18.30.178]) by smtp-out-2.01.com (Postfix) with ESMTP id 2794F4F42DF; Wed, 11 Dec 2013 18:57:48 -0600 (CST) Date: Wed, 11 Dec 2013 18:57:48 -0600 (CST) From: Franck Martin To: John Levine Message-ID: <689548087.150615.1386809868145.JavaMail.zimbra@peachymango.org> In-Reply-To: References: <20131211021808.14191.qmail@joyce.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [69.28.149.129] X-Mailer: Zimbra 8.0.5_GA_5839 (ZimbraWebClient - FF25 (Mac)/8.0.5_GA_5839) Thread-Topic: draft-delany-nullmx-01 Thread-Index: YKJQiwzYRBUSoYVkXQ2/wc6ecY27ew== Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-delany-nullmx-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 00:57:57 -0000 ----- Original Message ----- > From: "John Levine" > To: apps-discuss@ietf.org > Sent: Tuesday, December 10, 2013 6:18:08 PM > Subject: [apps-discuss] draft-delany-nullmx-01 > > Mark Delany originally wrote this draft back in 2005. I resuscitated > it with his consent in July. I would like appsawg to adopt it and, > assuming you don't hate it, publish it on the standards track. > > The point of null MX is really simple: if a domain does not receive > mail, it publishes this DNS record to say so: > > blah.example MX 0 . > My worry is that this structure indicates that the domain name may be sending emails. It is not uncommon to check if a domain has a A, AAAA or MX record before accepting email. If the domain cannot receive, then how do you handle replies? http://svn.apache.org/repos/asf/spamassassin/branches/3.2/lib/Mail/SpamAssassin/Plugin/DNSEval.pm --- sub check_dns_sender { ... dbg("dns: checking A and MX for host $host"); $pms->do_dns_lookup($rule, 'A', $host); $pms->do_dns_lookup($rule, 'MX', $host); ... } --- I think the draft needs to be extended to indicate, that this also means the domain is not sending any emails. From prvs=00516f8256=johnl@taugh.com Wed Dec 11 17:05:38 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57CCC1AE1C7 for ; Wed, 11 Dec 2013 17:05:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_47=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0JFHRh-hWbRz for ; Wed, 11 Dec 2013 17:05:37 -0800 (PST) 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 469631AE187 for ; Wed, 11 Dec 2013 17:05:37 -0800 (PST) Received: (qmail 30980 invoked from network); 12 Dec 2013 01:05:31 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 12 Dec 2013 01:05:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=12b01.52a90bdb.k1312; i=johnl%iecc.com@submit.iecc.com; bh=b5SJkF7WpjxSN0Ef9J2nVV2h/gWNaHw/WywDLfn0GAg=; b=iAZ9AvJVN/knrLU6H0tcmyy3FOlKQuh2+9mlicEwQaxJcN7y4e2St+zNuinQEJU6Q4lqKxxEX26R1zYEGQci7s8ARYJY/qxI+eYBy6cq0vcG8EAdDcEc/vO+O2PaT88sPdezPido8x57CjUs/c23lJ6LKlqVXavSIUxUQDLz+tvz0fKD0szRL9vzUD7ID4NDjJx98SkbW4CYEPldu06/IcZJDw5pnv0oLaNJ3bEaVFFl14h78lu5qtK8lxd9JkFQ DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=12b01.52a90bdb.k1312; olt=johnl%iecc.com@submit.iecc.com; bh=b5SJkF7WpjxSN0Ef9J2nVV2h/gWNaHw/WywDLfn0GAg=; b=f4emwPR8ZPtjXyJcBU84v+KnyGE2ZxWVn41Pm/m0XlhUmkp3+ADM5LRCaZ0VMAIyMIHEOHroRjCUckwEoz9IomtfvEVSXa37nwnK4EgFRznyLoPMToYxKBtVhO2xqmx/n7pK6+iFK+lZb2TXPUteo0jYravjP8hZd4o1HNUmyhjrJEvlIeEwTEbjq5YafxPwwQxfZEkyv1Br1htbl+KO1Cv14y26GK66aO9tpw9JEQW+MmUVAkU9Gi/eV6W10Z1a Received: from joyce.lan ([24.58.62.56]) by nimap.iecc.com ([64.57.183.76]) with ESMTPSA (TLS1.0/X.509/SHA1, johnl@iecc.com) via TCP; 12 Dec 2013 01:05:30 -0000 Date: 11 Dec 2013 20:05:30 -0500 Message-ID: From: "John R Levine" To: "Franck Martin" In-Reply-To: <689548087.150615.1386809868145.JavaMail.zimbra@peachymango.org> References: <20131211021808.14191.qmail@joyce.lan> <689548087.150615.1386809868145.JavaMail.zimbra@peachymango.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-delany-nullmx-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 01:05:38 -0000 >> blah.example MX 0 . > > My worry is that this structure indicates that the domain name may be sending emails. It is not uncommon to check if a domain has a A, AAAA or MX record before accepting email. If the domain cannot receive, then how do you handle replies? Um, if you'd read the draft, you'd know that it specifically says that it makes no assertions about whether a domain sends mail. We already have SPF -all to say a domain sends no mail. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From franck@peachymango.org Wed Dec 11 18:25:25 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B9DA1AE15D for ; Wed, 11 Dec 2013 18:25:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4rqe_f47YzUM for ; Wed, 11 Dec 2013 18:25:24 -0800 (PST) Received: from smtp.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id 808201AD945 for ; Wed, 11 Dec 2013 18:25:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id AF5234F4258; Wed, 11 Dec 2013 20:25:18 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zMcc7dGQSuHZ; Wed, 11 Dec 2013 20:25:18 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 922DB4F439B; Wed, 11 Dec 2013 20:25:18 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 85DB04F4378; Wed, 11 Dec 2013 20:25:18 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-2.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id zo0GrALS8DaW; Wed, 11 Dec 2013 20:25:18 -0600 (CST) Received: from [10.0.0.12] (c-24-5-172-97.hsd1.ca.comcast.net [24.5.172.97]) by smtp-out-2.01.com (Postfix) with ESMTPSA id D62504F4258; Wed, 11 Dec 2013 20:25:17 -0600 (CST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Franck Martin In-Reply-To: Date: Wed, 11 Dec 2013 18:26:03 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <3B0F68DB-57F3-42F1-857E-27460B5681EC@peachymango.org> References: <20131211021808.14191.qmail@joyce.lan> <689548087.150615.1386809868145.JavaMail.zimbra@peachymango.org> To: John R Levine X-Mailer: Apple Mail (2.1822) Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-delany-nullmx-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 02:25:25 -0000 On Dec 11, 2013, at 5:05 PM, John R Levine wrote: >>> blah.example MX 0 . >>=20 >> My worry is that this structure indicates that the domain name may be = sending emails. It is not uncommon to check if a domain has a A, AAAA or = MX record before accepting email. If the domain cannot receive, then how = do you handle replies? >=20 > Um, if you'd read the draft, you'd know that it specifically says that = it makes no assertions about whether a domain sends mail. >=20 > We already have SPF -all to say a domain sends no mail. >=20 If you read my email, this is my point, adding an MX to a domain breaks = the more common check to see if a receiver should accept emails from = such domain. To fix this situation, this draft needs to say, you should not accept = emails from such domain. From prvs=00516f8256=johnl@taugh.com Wed Dec 11 18:28:27 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37B6F1AE1B6 for ; Wed, 11 Dec 2013 18:28:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TpPEHqOtmu2i for ; Wed, 11 Dec 2013 18:28:25 -0800 (PST) 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 588721ADF38 for ; Wed, 11 Dec 2013 18:28:25 -0800 (PST) Received: (qmail 43661 invoked from network); 12 Dec 2013 02:28:19 -0000 Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 12 Dec 2013 02:28:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=12bbd.52a91f43.k1312; i=johnl%iecc.com@submit.iecc.com; bh=Mak7Q8kFgoDFqiXvkadiMhXshvnWmbu462MBATAEuTE=; b=Y6cYGb0sOnWdr9f9jDLQsdJES+PRny/5CWkCGPIk/caNXeVPN/uNFwhCPhv7ZMNUYgk5WMtIdiRKbv7dLaQQat92hYknvgSGiaKbLKIlhDiXHgvRAqYhGxJoSaz387ZSECo/26BI7Zh8U/c3r4OPkT59hBpS5l6UK2JAoRKENkQKsAFruGM0PvWTjA1eobbp/mJK4YK+mScSVJjh06L9UesoJ/9uCm0avVSYf0YBK0KyfZI93Y+U7gQQ1o4o7lyF DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=12bbd.52a91f43.k1312; olt=johnl%iecc.com@submit.iecc.com; bh=Mak7Q8kFgoDFqiXvkadiMhXshvnWmbu462MBATAEuTE=; b=YPU4cnRXdBYyrS2miIg+XNt9uAhyrMQJJFJ1pmL3T+3PYwXf5oioOWaAnsVKJAHjqY0xdsUlbRfbMp9qqWK4u34XOnui4f79UhipGWWLagYzUOsDMSqMMydEsyXxCC5GO2DCnWd+jAMgtICK3vtJrO0+7D2WFqgJrAA1U6Bh3oIdoL+JEmSsX2kxIFKbIh/LxXhgxUJNsL4fxHiW18K6amj4HDUBnxstZN2cw501Sy6CrvjYRTKoUP4nwlFebPk0 Received: from joyce.lan ([24.58.62.56]) by nimap.iecc.com ([64.57.183.76]) with ESMTPSA (TLS1.0/X.509/SHA1, johnl@iecc.com) via TCP; 12 Dec 2013 02:28:19 -0000 Date: 11 Dec 2013 21:28:17 -0500 Message-ID: From: "John R Levine" To: "Franck Martin" In-Reply-To: <3B0F68DB-57F3-42F1-857E-27460B5681EC@peachymango.org> References: <20131211021808.14191.qmail@joyce.lan> <689548087.150615.1386809868145.JavaMail.zimbra@peachymango.org> <3B0F68DB-57F3-42F1-857E-27460B5681EC@peachymango.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-delany-nullmx-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 02:28:27 -0000 >> We already have SPF -all to say a domain sends no mail. >> > If you read my email, this is my point, adding an MX to a domain breaks the more common check to see if a receiver should accept emails from such domain. > > To fix this situation, this draft needs to say, you should not accept emails from such domain. I disagree, but first let's see if the WG adopts the draft before we start arguing about what it should say. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From wmills@yahoo-inc.com Wed Dec 11 21:04:04 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ECF61AE024 for ; Wed, 11 Dec 2013 21:04:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.22 X-Spam-Level: X-Spam-Status: No, score=-16.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779, USER_IN_DEF_WHITELIST=-15] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PFnps5pTqqlb for ; Wed, 11 Dec 2013 21:04:02 -0800 (PST) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) by ietfa.amsl.com (Postfix) with ESMTP id 3631E1AE04B for ; Wed, 11 Dec 2013 21:04:02 -0800 (PST) Received: from BF1-EX10-CAHT09.y.corp.yahoo.com (bf1-ex10-caht09.corp.bf1.yahoo.com [10.74.209.198]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id rBC53Y2F088965 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 11 Dec 2013 21:03:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1386824615; bh=FgdJ6Tm843Uq6IcAeSD88SuCeIJ5aOTuvqnEN6VphRA=; h=References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To: MIME-Version:Content-Type; b=Q4tNk6fIpH0DCNXpwr4PXqzqw2FEUky6fabVSdBwP+gAqa+2OlW63a7NurVaASOYW m7pQimThgFB85aLDxlv18apA6XvihLwOfFVPCHuh4FRbc/XgwEE5u4fIwZD+Vbc/Ly Pz0Rn7Xvj1oXQwqYmjZCHj4Gl2fqysS4I8Uytxbs= Received: from omp1074.mail.ne1.yahoo.com (98.138.101.163) by BF1-EX10-CAHT09.y.corp.yahoo.com (10.74.209.170) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 12 Dec 2013 00:03:34 -0500 Received: (qmail 62363 invoked by uid 1000); 12 Dec 2013 05:03:33 -0000 Received: (qmail 74123 invoked by uid 60001); 12 Dec 2013 05:03:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1386824613; bh=KqSlwjiGSZJwq998zNQuAIrLL25xGPYDsixUMKGCWLo=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=DnzRTH79selphZtRuwj99Xdq6Y9ZbzxsJ85EURNJABpPf1WNMNuMh9Dv2KRZ16YOzAX8dXx2B404x7KJbrdysA3dATepVTSKjAmlH/O1zmtqzpEUIHJQ3ycldZ6F84mwpBr6m4I6eercqrWYDPc0G9rN0AdIpFr7z5USHCje9Tg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=kZz4zH1WOeIpiekz6UvkMW5PPSbWsscgCUDqQg1lMfsjMZBScpPwGta8lu50VBgxcLjgFrzc8fZbSwfgwIl35L0dKi/LB+e2I29qrJnDQ7RvRcXZTswj9sceY5jy+9K//nhE1/lLcwOloygYiLL5IGg2z/CMFgp7Tar8Onv3ZC4=; X-YMail-OSG: pNBlnPAVM1nae5dGfwkhnEoQ9Rp0V4QdXqsfL.vUmKklRXU soLBx3p3zOO8DUfmdMjpor3FOBymMvyLo622CMFlEiN1Gd7WyKPz5X9ivW.u xvAWlMqFpzznEtOocb6DdVM.T6E4LNSpYF.n8dHFHNzGBUaQcIHg.KswtQvE NJOW_pz9qtOfzOXRin4cMbQj1WVGNSIUM12U_OaUFjQxKjMKsppTSlEbKMEC XnOuUzaFvHz5jX_wQH.pBlvkPBymEpBYujfgSRDvBeTTGDAALZ1CrwvDqBAn Fgb7A2NfDAB7iSnCq56ru4TdUTFlMqQEI6vlr Received: from [99.31.212.42] by web125606.mail.ne1.yahoo.com via HTTP; Wed, 11 Dec 2013 21:03:33 PST X-Rocket-MIMEInfo: 002.001, TG9va3MgZ29vZCB0byBtZS4KCsKgCi1iaWxsCgoKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCldpbGxpYW0gSi4gTWlsbHMKIlBhcmFub2lkIiBZYWhvbyEKCgoKCgpPbiBXZWRuZXNkYXksIERlY2VtYmVyIDExLCAyMDEzIDQ6MjMgUE0sIE11cnJheSBTLiBLdWNoZXJhd3kgPHN1cGVydXNlckBnbWFpbC5jb20.IHdyb3RlOgogCk9uIFdlZCwgRGVjIDExLCAyMDEzIGF0IDM6MzkgUE0sIDxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc.IHdyb3RlOgoKCj5BIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyABMAEBAQE- X-Mailer: YahooMailWebService/0.8.169.609 References: <20131211233924.25337.38138.idtracker@ietfa.amsl.com> Message-ID: <1386824613.80020.YahooMailNeo@web125606.mail.ne1.yahoo.com> Date: Wed, 11 Dec 2013 21:03:33 -0800 From: Bill Mills To: "Murray S. Kucherawy" , IETF Apps Discuss In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="607277540-720138722-1386824613=:80020" X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 824614004 Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rrvs-header-field-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 05:04:04 -0000 --607277540-720138722-1386824613=:80020 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Looks good to me.=0A=0A=A0=0A-bill=0A=0A=0A=0A-----------------------------= ---=0AWilliam J. Mills=0A"Paranoid" Yahoo!=0A=0A=0A=0A=0A=0AOn Wednesday, D= ecember 11, 2013 4:23 PM, Murray S. Kucherawy wrote:= =0A =0AOn Wed, Dec 11, 2013 at 3:39 PM, wrote:= =0A=0A=0A>A New Internet-Draft is available from the on-line Internet-Draft= s directories.=0A>=A0This draft is a work item of the Applications Area Wor= king Group Working Group of the IETF.=0A>=0A>=A0 =A0 =A0 =A0 Title =A0 =A0 = =A0 =A0 =A0 : The Require-Recipient-Valid-Since Header Field and SMTP Servi= ce Extension=0A>=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : William J. Mills=0A= >=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Murray S. Kucherawy=0A= >=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-appsawg-rrvs-header-f= ield-05.txt=0A>=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 20=0A>=A0 =A0 = =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-12-11=0A>=0A>Abstract:=0A>=A0 = =A0This document defines an extension for the Simple Mail Transfer=0A>=A0 = =A0Protocol called RRVS, and a header field called Require-Recipient-=0A>= =A0 =A0Valid-Since, to provide a method for senders to indicate to receiver= s=0A>=A0 =A0the time when the sender last confirmed the ownership of the ta= rget=0A>=A0 =A0mailbox. =A0This can be used to detect changes of mailbox ow= nership,=0A>=A0 =A0and thus prevent mail from being delivered to the wrong = party.=0A>=0A>=A0 =A0The intended use of these facilities is on automatical= ly generated=0A>=A0 =A0messages that might contain sensitive information, t= hough it may also=0A>=A0 =A0be useful in other applications.=0A>=0A=0AAddre= sses the suggested changes received since -04.=A0 Thanks to everyone that p= rovided comments!=0A=0A=0A-MSK=0A=0A=0A____________________________________= ___________=0Aapps-discuss mailing list=0Aapps-discuss@ietf.org=0Ahttps://w= ww.ietf.org/mailman/listinfo/apps-discuss --607277540-720138722-1386824613=:80020 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Looks good to me.
 
-bill


---= -----------------------------
William J. Mills
"Paranoid" Yahoo!
<= /div>

=

On Wednesday, Dece= mber 11, 2013 4:23 PM, Murray S. Kucherawy <superuser@gmail.com> wrot= e:
On Wed, Dec 11, 2013 at 3:39 PM, <internet-drafts@ie= tf.org> wrote:
=0A

=0AA New Internet-Draft is avai= lable from the on-line Internet-Drafts directories.
=0A&n= bsp;This draft is a work item of the Applications Area Working Group Workin= g Group of the IETF.
=0A
=0A  &nbs= p;     Title           : The Require-Rec= ipient-Valid-Since Header Field and SMTP Service Extension
=0A        Author(s)       : William J= . Mills
=0A            &nbs= p;             Murray S. Kucherawy
=0A        Filename       &nbs= p;: draft-ietf-appsawg-rrvs-header-field-05.txt
=0A =       Pages           : 20
=0A        Date         =    : 2013-12-11
=0A
=0AAbstra= ct:
=0A   This document defines an extension fo= r the Simple Mail Transfer
=0A   Protocol calle= d RRVS, and a header field called Require-Recipient-
=0A&= nbsp;  Valid-Since, to provide a method for senders to indicate to rec= eivers
=0A   the time when the sender last conf= irmed the ownership of the target
=0A   mailbox= .  This can be used to detect changes of mailbox ownership,
=0A   and thus prevent mail from being delivered to the= wrong party.
=0A
=0A   The i= ntended use of these facilities is on automatically generated
=0A   messages that might contain sensitive information, tho= ugh it may also
=0A   be useful in other applic= ations.

A= ddresses the suggested changes received since -04.  Thanks to everyone= that provided comments!

-M= SK

____________________________________= ___________
apps-discuss mailing list
<= a shape=3D"rect" ymailto=3D"mailto:apps-discuss@ietf.org" href=3D"mailto:ap= ps-discuss@ietf.org">apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss


--607277540-720138722-1386824613=:80020-- From dhc@dcrocker.net Wed Dec 11 21:36:05 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC4E31AE08F; Wed, 11 Dec 2013 21:36:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3 X-Spam-Level: X-Spam-Status: No, score=-3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=0.6, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iNFZsiPErGBh; Wed, 11 Dec 2013 21:36:01 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 216741A802D; Wed, 11 Dec 2013 21:36:01 -0800 (PST) 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 rBC5ZpSF017650 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 11 Dec 2013 21:35:54 -0800 Message-ID: <52A94AF6.8090702@dcrocker.net> Date: Wed, 11 Dec 2013 21:34:46 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Apps Discuss , draft-ietf-stox-presence.all@tools.ietf.org, stox@ietf.org 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 Dec 2013 21:35:55 -0800 (PST) Cc: iesg Subject: [apps-discuss] Review of: draft-ietf-stox-presence-06 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 05:36:06 -0000 G'day. I have been selected as the Applications Area Review Team reviewer for this draft (for background on apps-review, please see http://www.apps.ietf.org/content/applications-area-review-team). 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. Review of: Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Presence I-D: draft-ietf-stox-presence-06 Reviewer: D. Crocker Review date: 12 Dec 13 Summary: XMPP and SIP both have deployed versions of instant messaging and presence. The current draft is part of a set of specifications that define a gateway capability between the the two services. In particular, the current draft specifies the translation mechanism between the presence mechanisms used by SIP and XMPP. The draft is well-structured and the text is mostly clear. For an implementer already familiar with the details of the two services and the basics of the gatewaying specified here, the document probably is sufficient -- although responses to some of the detailed comments, below, might to turn out to show that a bit more work is needed. However at the most, any technical improvements that might be needed will be minor. And I expect these to more in the nature of clarifying language than of changing bits over the wire. However for a reader who is new to the topic, the document needs to be clearer and sometimes more complete. Specific changes or concerns: 1. When citing the earlier efforts, there should be something to explain why the current work is expected to be more successful. That is, what makes the current approach notably tractable for implementation and deployment? 2. The document is not clear about the prerequisites for reading this draft. What must the reader already know in depth? What must they have at least superficial knowledge of? I suspect that, in particular, they need deep familiarity with stox-core. 3. Saying that terms are taken from a substantial number of other documents, and then merely citing the documents in their entirety, is not helpful to the reader, unless the reader is required to be deeply familiar with those documents. If that's what this document requires, say that. If it's not, I suggest listing terms explicitly and indicating what document they are drawn from. 4. As the architecture diagram in Section 3 of stox-core shows, this service has at least separate actors Actually I think it actually has at least 6, which that diagram probably should show explicitly. The six are: a. SIP user b. SIP server c. SIP-XMPP gateway d. XMPP-SIP gateway e. XMPP server f. XMPP user In any event, the specification needs to be very diligent to carefully identify each actor involved in an activity and the interaction between actors. The current document uses language that often left me wondering such things as who was the target of the action. Much of this would be aided by some form of protocol sequence diagrams, to show who does what and in what order. 5. When showing protocol examples, usually only one side of the sequence is shown. For gatewaying that does interesting transforms, such as this one, an example should show both the before and after versions. That is, the 'native' protocol unit that was created and then the one that results from the translation. Detailed Comments: > Table of Contents Nicely organized and concise TOC [ie, document structure). > 1. Introduction ... > One approach to helping ensure interworking between these protocols > is to map each protocol to the abstract semantics described in > [RFC3860]; that is the approach taken by both [RFC3922] and > [I-D.ietf-simple-cpim-mapping]. The approach taken in this document > is to directly map semantics from one protocol to another (i.e., from > SIP/SIMPLE to XMPP and vice-versa). This begs the obvious question: Why? What was wrong with the previous approach? The purpose of the question is not for criticizing prior work but to understand the expected benefit of the approach taken in the current work. What are the function, or OA&M differences produced through this new approach, that are expected to be helpful? > The architectural assumptions underlying such direct mappings are > provided in [I-D.ietf-stox-core], including mapping of addresses and > error conditions. The mappings specified in this document cover > basic presence functionality. Mapping of more advanced functionality > (e.g., so-called "rich presence") is out of scope for this document. > > SIP and XMPP differ significantly in their presence subscription > models, since SIP subscriptions are short-lived (requiring relatively > frequent refreshes even during a presence session) whereas XMPP > subscriptions last across presence sessions until they are explicitly > cancelled. This document provides suggestions for bridging the gap > between these very different models. > > > 2. Terminology > > A number of terms used here are explained in [RFC3261], [RFC3856], > [RFC6120], and [RFC6121]. This sentence probably implies that the current draft should not be read in the absence of familiarity with all 4 of those RFCs. I suggest some sort of explicit statement about how much prior knowledge is needed for understanding the current draft, and where to get that knowledge. In purely mechanical terms, the problem with the above sentence is that it means that when the reader sees a term they don't understand, they have to run around to four different documents looking for definitions. This mostly ensures reader frustration, for everyone but experts. The cleanest fix for this is to list terms and where they are defined. The other, usual fix is to indeed say that the reader must be familiar with those other documents before reading this one. (sigh.) > 3.1. Overview ... > As described in [RFC6121], XMPP presence subscriptions are managed > using XMPP presence stanzas of type "subscribe", "subscribed", > "unsubscribe", and "unsubscribed". The main subscription states are > "none" (neither the user nor the contact is subscribed to the other's > presence information), "from" (the user has a subscription from the > contact), "to" (the user has a subscription to the contact's presence > information), and "both" (both user and contact are subscribed to > each other's presence information). Nit: for technical documents, lists like the above should be shown in list format. It really does help for quick comprehension. > > As described in [RFC3856], SIP presence subscriptions are managed > through the use of SIP SUBSCRIBE events sent from a SIP user agent to > an intended recipient who is most generally referenced by a Presence > URI of the form but who might be referenced by a > SIP or SIPS URI of the form or . > > The subscription models underlying XMPP and SIP are quite different. > For instance, XMPP presence subscriptions are long-lived (indeed > permanent if not explicitly cancelled), whereas SIP presence > subscriptions are short-lived (the default time-to-live of a SIP > presence subscription is 3600 seconds, as specified in Section 6.4 of > [RFC3856]). These differences are addressed below. The text that follows this 'addresses' the differences in terms of specifying how to handle specific differences. What's missing -- but I think would aid for the framework of this document's effort -- is for the above "For instance" to instead be expanded into a detailed statement of what the differences are, separate from the later text that says how to deal with the differences. Someone needing to implement this spec, probably will be starting with a reasonable model of one side -- or at least, reasonable knowledge of the details, if not a thoughtful, higher-level model -- and considerable ignorance of the other. Text that discusses details of differences, distinct from how to resolve them, will put the implementer into a better position of understanding what's being done. This probably raises a larger issue: How much expertise is expected of someone who is implementing this or otherwise reading for deep comprehension? In the extreme, they will need to have serious expertise on both protocol sets. The other extreme would be a cookbook inside this document, with no outside knowledge required. The document needs to specify the nature and extent of the expertise required. (In fact, the document seems pretty clean, in terms of explaining things, so I suspect that 'fair' knowledge of one suite will suffice. But the author and wg beliefs about the requirement should be made explicit.) > 3.2. XMPP to SIP > > 3.2.1. Establishing a Presence Subscription > > An XMPP user (e.g., juliet@example.com) initiates a subscription by > sending a subscription request to another entity (e.g., > romeo@example.net), and the other entity (conventionally called a Move definition of contact up to first occurrence, above. > "contact") either accepts or declines the request. If the contact > accepts the request, the user will have a subscription to the > contact's presence information until (1) the user unsubscribes or (2) > the contact cancels the subscription. The subscription request is > encapsulated in a presence stanza of type "subscribe": > > > > > Saint-Andre, et al. Expires April 21, 2014 [Page 4] > > Internet-Draft SIP-XMPP Interworking: Presence October 2013 > > > Example 1: XMPP user subscribes to SIP contact: > > | | to='romeo@example.net' > | type='subscribe'/> > > Upon receiving such a presence stanza, the XMPP server to which > Juliet has connected needs to determine the identity of the > domainpart in the 'to' address, which it does by following the > procedures discussed in [I-D.ietf-stox-core]. Here we assume that Unfortunately, given the context of a citation like this, it really needs much greater precision, to point the reader to the exact portion of the document that is relevant to this context. Unless, of course, the premise of the current document is that the reader must be deeply familiar with the -core document. In which case, /that's/ what should be specified early in this document. Based on what follows, I fear that indeed, this document requires deep familiarity with -core. > the XMPP server has determined the domain is serviced by a SIMPLE > server, that it contains or has available to it an XMPP-SIMPLE > gateway or connection manager (which enables it to speak natively to > SIMPLE servers), and that it hands off the presence stanza to the > XMPP-SIMPLE gateway. > > The XMPP-SIMPLE gateway is then responsible for translating the XMPP > subscription request into a SIP SUBSCRIBE request from the XMPP user > to the SIP user: > > Example 2: XMPP user subscribes to SIP contact (SIP transformation): It took a moment to decide whether I was looking at XMPP form or SIP form. Perhaps a more helpufl title for the example would be something like: Example 2: Translation of XMPP user's subscription request into SIP > | SUBSCRIBE sip:romeo@example.net SIP/2.0 Later text (section 4.1) equates the label pres: with sip: and sips:. Why choose sip: here? > | Via: SIP/2.0/TCP x2s.example.com;branch=z9hG4bKna998sk > | From: ;tag=ffd2 > | Call-ID: 5BCF940D-793D-43F8-8972-218F7F4EAA8C > | Event: presence > | Max-Forwards: 70 > | CSeq: 123 SUBSCRIBE > | Contact: > | Accept: application/pidf+xml > | Expires: 3600 > | Content-Length: 0 > > The SIP user then SHOULD send a response indicating acceptance of the > subscription request: > > Example 3: SIP accepts subscription request: > > | SIP/2.0 200 OK > | Via: SIP/2.0/TCP s2x.example.net;branch=z9hG4bKna998sk > | From: ;tag=ffd2 > | To: ;tag=j89d > | Call-ID: 5BCF940D-793D-43F8-8972-218F7F4EAA8C > | CSeq: 234 SUBSCRIBE > | Contact: > | Expires: 3600 > | Content-Length: 0 Hmmm. This appears to be the original SIP acceptance, but with no separate display of it's being translated into XMPP. > > Saint-Andre, et al. Expires April 21, 2014 [Page 5] > > Internet-Draft SIP-XMPP Interworking: Presence October 2013 > > > In accordance with [RFC6665], the XMPP-SIMPLE gateway SHOULD consider > the subscription state to be "neutral" until it receives a NOTIFY > message. Therefore the SIP user or SIP-XMPP gateway at the SIP > user's domain SHOULD immediately send a NOTIFY message containing a > "Subscription-State" header whose value contains the string "active" > (see Section 4). > > Example 4: SIP user sends presence notification: > > | NOTIFY sip:192.0.2.1 SIP/2.0 > | Via: SIP/2.0/TCP simple.example.net;branch=z9hG4bKna998sk > | From: ;tag=yt66 > | To: ;tag=bi54 > | Call-ID: 5BCF940D-793D-43F8-8972-218F7F4EAA8C > | Event: presence > | Subscription-State: active;expires=499 > | Max-Forwards: 70 > | CSeq: 8775 NOTIFY > | Contact: > | Content-Type: application/pidf+xml > | Content-Length: 193 > | > | > | | entity='pres:romeo@example.net'> > | > | > | open > | away > | > | > | Where is the xmpp translation of this? > In response, the SIMPLE-XMPP gateway would send a 200 OK (not shown Sent it to whom? (I probably know the answer, but the reader shouldn't have to guess; this is a spec.) > here since it is not translated into an XMPP stanza). > > Upon receiving the first NOTIFY with a subscription state of active, > the XMPP-SIMPLE gateway MUST generate a presence stanza of type > "subscribed": > > Example 5: XMPP user receives acknowledgement from SIP contact: > > | | to='juliet@example.com' > | type='subscribed'/> > > As described under Section 4, the gateway MUST also generate a > presence notification to the XMPP user: > > > Saint-Andre, et al. Expires April 21, 2014 [Page 6] > > Internet-Draft SIP-XMPP Interworking: Presence October 2013 > > > Example 6: XMPP user receives presence notification from SIP contact: > > | | to='juliet@example.com'/> This sequence feels like it should have a protocol sequence diagram, of the type used in rfc5263. > 3.2.3. Cancelling a Presence Subscription > > At any time after subscribing, the XMPP user can unsubscribe from the > contact's presence. This is done by sending a presence stanza of > type "unsubscribe": > > Example 7: XMPP user unsubscribes from SIP contact: > > | | to='romeo@example.net' > | type='unsubscribe'/> > > The XMPP-SIMPLE gateway is responsible for translating the > unsubscribe command into a SIP SUBSCRIBE request with the "Expires" > header set to a value of zero: > > Example 8: XMPP user unsubscribes from SIP contact (SIP > transformation): > > | SUBSCRIBE sip:romeo@example.net SIP/2.0 > | Via: SIP/2.0/TCP s2x.example.net;branch=z9hG4bKna998sk > | From: ;tag=j89d > | Call-ID: 9D9F00DF-FCA9-4E7E-B970-80B638D5218A > | Event: presence > | Max-Forwards: 70 > | CSeq: 789 SUBSCRIBE > | Contact: > | Accept: application/pidf+xml > | Expires: 0 > | Content-Length: 0 > > > > Saint-Andre, et al. Expires April 21, 2014 [Page 7] > > Internet-Draft SIP-XMPP Interworking: Presence October 2013 > > > Upon sending the transformed unsubscribe, the XMPP-SIMPLE gateway > SHOULD send a presence stanza of type "unsubscribed" to the XMPP > user: > > Example 9: XMPP user receives unsubscribed notification: > > | | to='juliet@example.com' > | type='unsubscribed'/> One of the advantages of showing sequences like these in a protocol sequence diagram is that it concisely shows which of the 4 actors does what and when. Being able to see visual summaries like that will make the life of an implementer /much/ easier. > 3.3. SIP to XMPP > > 3.3.1. Establishing a Presence Subscription > > A SIP user initiates a subscription to a contact's presence > information by sending a SIP SUBSCRIBE request to the contact. The > following is an example of such a request: > > Example 10: SIP user subscribes to XMPP contact: > > | SUBSCRIBE sip:juliet@example.com SIP/2.0 > | Via: SIP/2.0/TCP s2x.example.net;branch=z9hG4bKna998sk > | From: ;tag=xfg9 > | Call-ID: AA5A8BE5-CBB7-42B9-8181-6230012B1E11 > | Event: presence > | Max-Forwards: 70 > | CSeq: 263 SUBSCRIBE > | Contact: > | Accept: application/pidf+xml > | Content-Length: 0 > > Notice that the "Expires" header was not included in the SUBSCRIBE > request; this means that the default value of 3600 (i.e., 3600 > seconds = 1 hour) applies. > > Upon receiving the SUBSCRIBE, the SIP server needs to determine the > identity of the domain portion of the Request-URI or To header, which > it does by following the procedures discussed in > [I-D.ietf-stox-core]. Here we assume that the SIP server has > determined that the domain is serviced by an XMPP server, that it This seems to mean that a regular SIP server needs to be familiar with technical details in a gatewaying specification?? > Example 11: SIP user subscribes to XMPP contact (XMPP > transformation): > > | | to='juliet@example.com' > | type='subscribe'/> > > In accordance with [RFC6121], the XMPP user's server MUST deliver the > presence subscription request to the XMPP user (or, if a subscription > already exists in the XMPP user's roster, send a presence stanza of > type 'subscribed'). > > If the XMPP user approves the subscription request, the XMPP server > then MUST return a presence stanza of type "subscribed" from the XMPP > user to the SIP user; if a subscription already exists, the XMPP The XMPP server does not communicate (directly) with the SIP user. It has to go through one or both gateways. (From the architectural diagram, I assume the sequence is through both.) This spec needs to be very careful to identify what entity is talking with what entity directly and who is mediating, when it isn't direct. > 3.3.2. Refreshing a Presence Subscription > > For as long as a SIP user is online and interested in receiving > presence notifications from the XMPP users, the user's SIP user agent > is responsible for periodically refreshing the subscription by > sending an updated SUBSCRIBE request with an appropriate value for sending it to which actor directly? > the Expires header. In response, the SIMPLE-XMPP gateway MUST send a > > > > Saint-Andre, et al. Expires April 21, 2014 [Page 9] > > Internet-Draft SIP-XMPP Interworking: Presence October 2013 > > > SIP NOTIFY to the user agent (per [RFC6665]; if the gateway has > meaningful information about the availability state of the XMPP user This prompts the thought that early in the document, there should probably be some discussion about what state information needs to be maintained in the gateways. > then the NOTIFY MUST communicate that information (e.g., by including > a PIDF body [RFC3863] with the relevant data), whereas if the gateway > does not have meaningful information about the availability state of > the XMPP user then the NOTIFY MUST be empty as allowed by [RFC6665]. > > Once the SIP user goes offline at the end of a presence session, it "goes offline" seems odd phrasing here; I'm not entirely sure what it means. isn't the simple point that the SIP user terminates the presence session (for whatever reason)? If the point is that the SIP user literally disappears from the session -- again, there are lots of possible reasons, where 'going offline' is only one -- some language like that might work better. > 4.1. Overview In general, this overview (4.1) section seems odd to have appear so late in the document. Everything in it feels like stuff that should be in Section 1, not Section 4. > Both XMPP and presence-aware SIP systems enable entities (often but > not necessarily human users) to send presence notifications to other > entities. At a minimum, the term "presence" refers to information > about an entity's availability for communication on a network (on/ > off), often supplemented by information that further specifies the > entity's communications context (e.g., "do not disturb"). Some > systems and protocols extend this notion even further and refer to > any relatively ephemeral information about an entity as a kind of > presence; categories of such "extended presence" include geographical The above text seems a bit confusing. First it distinguishes between presence and status, and then describes something which is both as 'extended status.' Here's my guess about what is needed: 1. Very narrow and precise use of the term presence; I think that means it only mean "connected to a presence service", or somesuch. 2. Consistent distinction of presence-related attributes, like do not disturb. What's missing here is a simple term for it. 3. Clarity that "ephemeral information about an entity" is probably a form of #2, rather than #1. That is, I think it's a presence attribute, rather than "a presence". And if I've gotten this entirely confused, then that means the text needs a different kind of fixing... > location (e.g., GPS coordinates), user mood (e.g., grumpy), user > activity (e.g., walking), and ambient environment (e.g., noisy). In > this document, we focus on the "least common denominator" of network > availability only, although future documents might address broader > notions of presence, including extended presence. > > > > > Saint-Andre, et al. Expires April 21, 2014 [Page 12] > > Internet-Draft SIP-XMPP Interworking: Presence October 2013 > > > [RFC6121] defines how XMPP presence stanzas can indicate availability > (via absence of a 'type' attribute) or lack of availability (via a > 'type' attribute with a value of "unavailable"). SIP presence using > a SIP event package for presence is specified in [RFC3856]. > > As described in [RFC6121], presence information about an entity is information -> XMPP information > communicated by means of an XML stanza sent over an XML > stream. In this document we will assume that such a presence stanza > is sent from an XMPP client to an XMPP server over an XML stream > negotiated between the client and the server, and that the client is > controlled by a human user (again, this is a simplifying assumption > introduced for explanatory purposes only). In general, XMPP presence > is sent by the user to the user's server and then broadcasted to all > entities who are subscribed to the user's presence information. http://www.dailywritingtips.com/broadcast-vs-broadcasted-as-past-form/ In spite of having some formal linguistic legitimacy, I suggest using 'broadcast'. > > As described in [RFC3856], presence information about an entity is > communicated by means of a SIP NOTIFY event sent from a SIP user > agent to an intended recipient who is most generally referenced by an > Presence URI of the form but who might be > referenced by a SIP or SIPS URI of the form or > . Here again we introduce the simplifying > assumption that the user agent is controlled by a human user. I guess I'm not understanding how the nature of what is controlling the agent affects anything in this document. Might be worth explaining that. > 4.2. XMPP to SIP > > When Juliet interacts with her XMPP client to modify her presence > information (or when her client automatically updates her presence > information, e.g. via an "auto-away" feature), her client generates > an XMPP stanza. The syntax of the stanza, > including required and optional elements and attributes, is defined > in [RFC6121]. The following is an example of such a stanza: > > Example 17: XMPP user sends presence notification: > > | > > Upon receiving such a stanza, the XMPP server to which Juliet has > connected broadcasts it to all subscribers who are authorized to > receive presence notifications from Juliet (this is similar to the > SIP NOTIFY method). For each subscriber, broadcasting the presence > notification involves either delivering it to a local recipient (if > the hostname in the subscriber's address matches one of the hostnames > serviced by the XMPP server) or attempting to route it to the foreign > domain that services the hostname in the subscriber's address. Thus > > > > Saint-Andre, et al. Expires April 21, 2014 [Page 13] > > Internet-Draft SIP-XMPP Interworking: Presence October 2013 > > > the XMPP server needs to determine the identity of the domainpart in > the 'to' address, which it does by following the procedures discussed > in [I-D.ietf-stox-core]. Here we assume that the XMPP server has > determined the domain is serviced by a SIMPLE server, that it again, the idea that a pure xmpp server can 'know' about a simple destination doesn't make sense to me. (And by that way, is it simple or is it sip...? Note that the term 'simple' hasn't been getting used in this document.) at a minimum, this is a good place to repeat the pointer to text that explains how gateways are operational fit into two native networks, where their nature is transparent -- that is, with the native entities thinking they are merely talking to other native entities. > contains or has available to it an XMPP-SIMPLE gateway or connection > manager (which enables it to speak natively to SIMPLE servers), and > that it hands off the presence stanza to the XMPP-SIMPLE gateway. > > The XMPP-SIMPLE gateway is then responsible for translating the XMPP > presence stanza into a SIP NOTIFY request and included PIDF document > from the XMPP user to the SIP user. > > Example 18: XMPP user sends presence notification (SIP > transformation): > > | NOTIFY sip:192.0.2.2 SIP/2.0 > | Via: SIP/2.0/TCP x2s.example.com;branch=z9hG4bKna998sk > | From: ;tag=gh19 > | To: ;tag=yt66 > | Contact: ;gr=balcony > | Call-ID: 2B44E147-3B53-45E4-9D48-C051F3216D14 > | Event: presence > | Subscription-State: active;expires=599 > | Max-Forwards: 70 > | CSeq: 157 NOTIFY > | Contact: > | Content-Type: application/pidf+xml > | Content-Length: 192 > | > | > | | entity='pres:juliet@example.com'> > | > | > | open > | away > | > | > | > > The mapping of XMPP syntax elements to SIP syntax elements SHOULD be > as shown in the following table. (Mappings for elements not > mentioned are undefined.) > > > > > > > > > Saint-Andre, et al. Expires April 21, 2014 [Page 14] > > Internet-Draft SIP-XMPP Interworking: Presence October 2013 > > > Table 1: Presence syntax mapping from XMPP to SIP > > +-----------------------------+---------------------------+ > | XMPP Element or Attribute | SIP Header or PIDF Data | > +-----------------------------+---------------------------+ > | stanza | "Event: presence" (1) | > | XMPP resource identifer | tuple 'id' attribute (2) | > | from | From | > | id | CSeq (3) | > | to | To | > | type | basic status (4) (5) | > | xml:lang | Content-Language | > | | priority for tuple (6) | > | | no mapping (7) | > | | | > +-----------------------------+---------------------------+ The format of this makes the table reads as two (unsynchronized) columns, rather than a series of rows. I suggest different formatting, such as (in spite of it's being longer: +-----------------------------+---------------------------+ | XMPP Element or Attribute | SIP Header or PIDF Data | +-----------------------------+---------------------------+ | priority for tuple (6) | +-----------------------------+---------------------------+ | no mapping (7) | +-----------------------------+---------------------------+ | | +-----------------------------+---------------------------+ > Note the following regarding these mappings: > > 1. Only a presence stanza that lacks a 'type' attribute or whose presence -> XMPP presence > 'type' attribute has a value of "unavailable" SHOULD be mapped by > an XMPP-SIMPLE gateway to a SIP NOTIFY request, since those are > the only presence stanzas that represent notifications. > 2. The PIDF schema defines the tuple 'id' attribute as having a > datatype of "xs:ID"; because this datatype is more restrictive > than the "xs:string" datatype for XMPP resourceparts (in > particular, a number is not allowed as the first character of an > ID), it is RECOMMENDED to prepend the resourcepart with "ID-" or > some other alphabetic string when mapping from XMPP to SIP. > 3. This mapping is OPTIONAL. What does that mean? This sort of mapping is usually the essence of gatewaying semantics. How can interoperability tolerate it's being optional? > 4.3. SIP to XMPP > > When Romeo changes his presence, his SIP user agent generates a SIP Romeo is doing SIP? And Juliet does XMPP? So, SIP is more macho than XMPP??? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net -- Dave Crocker Brandenburg InternetWorking bbiw.net From salvatore.loreto@ericsson.com Wed Dec 11 23:20:48 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B88E21AE1C5 for ; Wed, 11 Dec 2013 23:20:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.239 X-Spam-Level: X-Spam-Status: No, score=-1.239 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zZmwQk7R7p0E for ; Wed, 11 Dec 2013 23:20:47 -0800 (PST) Received: from sesbmg21.mgmt.ericsson.se (sesbmg21.ericsson.net [193.180.251.49]) by ietfa.amsl.com (Postfix) with ESMTP id AA98E1AE1BD for ; Wed, 11 Dec 2013 23:20:46 -0800 (PST) X-AuditID: c1b4fb31-b7fa78e0000005dd-2a-52a963c74d3a Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg21.mgmt.ericsson.se (Symantec Mail Security) with SMTP id CF.F7.01501.7C369A25; Thu, 12 Dec 2013 08:20:40 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.192]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0347.000; Thu, 12 Dec 2013 08:20:39 +0100 From: Salvatore Loreto To: "Murray S. Kucherawy" Thread-Topic: [apps-discuss] draft-delany-nullmx-01 Thread-Index: AQHO9hdNn6HDdra7B0+sDSlDNZoEwppOQlsAgABKogCAABG8AIAAmBMAgABfpACAAIHrAA== Date: Thu, 12 Dec 2013 07:20:38 +0000 Message-ID: References: <20131211021808.14191.qmail@joyce.lan> <52A7D980.5090902@isdg.net> <52A8A68E.2040805@isode.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_EE4EE36C8BF54630BD0532042390F12Aericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgkeLIzCtJLcpLzFFi42KZGfG3VvdE8soggy9yFjNWF1msfrmCzWLi 9wY2B2aPnbPusnssWfKTyeNUs2EAcxSXTUpqTmZZapG+XQJXxrclG5gKZqtULJ/1m6WB8YFc FyMnh4SAicS576/ZIWwxiQv31rN1MXJxCAmcYJSYeuIuE4SzBMj5P4cFpIpNwEzi+cMtzCC2 iIC+xIfe2YwgNrNAjMS6lzvAbGEBI4lDix9C1RhLdB/fwQZhh0kc/vwayObgYBFQlZj1VRok zCtgL9HQ8QZq1zEmiRNzL4DN4RQIlDjcDGEzAl33/dQaJohd4hK3nsxngrhaQGLJnvPMELao xMvH/1ghbCWJFdsvMYLsYhZIlpj4uQxil6DEyZlPWCYwis5CMmkWQtUsJFUQJXoSN6ZOYYOw tSWWLXzNDGHrSsz4dwiqxlpi0eR37MhqFjByrGKULE4tTspNNzLUy03PLdFLLcpMLi7Oz9Mr Tt3ECIzNg1t+G+5gnHjN/hCjNAeLkjgvw/TOICGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2M yqnhqY9Oe7wPDd7Fom2j3/FAVGbGzUi+Gw8ffg1YvVJC4XOUmGvccd00u/NX9vKLLsg1iV2d r3ZkJYdkXIRHz4vWvQKXJRwN9U7EpB7IuHTrNOtWm7KzaxuXs60MZLYSXuuWJHTndMeZp+eO tq86lvpjWtm5JXL+u3btkNv39OTEm27MiSc1lViKMxINtZiLihMBqME90psCAAA= Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-delany-nullmx-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 07:20:48 -0000 --_000_EE4EE36C8BF54630BD0532042390F12Aericssoncom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I agree with Murray here /Salvatore On Dec 12, 2013, at 12:35 AM, "Murray S. Kucherawy" > wrote: I don't believe we can do a formal call for adoption until we have at least= a couple of our current documents submitted to the IESG. In the past we'v= e received complaints when we've had a docket of active WG documents at the= current size, so we can't enlarge it now. Perhaps this is incentive for people interested in draft-delany-nullmx to s= ubmit reviews for the other documents that are waiting for them, so that we= can get them out of the way... :-) -MSK On Wed, Dec 11, 2013 at 9:53 AM, Alexey Melnikov > wrote: On 11/12/2013 08:49, Murray S. Kucherawy wrote: Separate from the specific mechanism chosen, does the working group want to= put time into producing a document that proposes a standard way of saying = "We do not accept mail?" Yes. We could use this document as a starting point for such work if the WG thin= ks it's appropriate. Yes. If the answer to the first question is "yes" but the second is "no", does a= nyone have an alternative proposal? _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss --_000_EE4EE36C8BF54630BD0532042390F12Aericssoncom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <8140817B7920A54199F3347C9C7BC63A@ericsson.com> Content-Transfer-Encoding: quoted-printable I agree with Murray here

/Salvatore

On Dec 12, 2013, at 12:35 AM, "Murray S. Kucherawy" <superuser@gmail.com>
 wrote:

I don't believe we can do a formal call for adoption until we have at = least a couple of our current documents submitted to the IESG.  In the= past we've received complaints when we've had a docket of active WG docume= nts at the current size, so we can't enlarge it now.

Perhaps this is incentive for people interested in draft-delany-nullmx to s= ubmit reviews for the other documents that are waiting for them, so that we= can get them out of the way... :-)

-MSK



On Wed, Dec 11, 2013 at 9:53 AM, Alexey Melnikov= <alexey.m= elnikov@isode.com> wrote:
On 11/12/2013 08:49, Murray S. Kucherawy wrote:
Separate from the specific mechanism chosen, does the working group want to= put time into producing a document that proposes a standard way of saying = "We do not accept mail?"
Yes.


We could use this document as a starting point for such work if the WG thin= ks it's appropriate.
Yes.


If the answer to the first question is "yes" but the second is &q= uot;no", does anyone have an alternative proposal?


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

--_000_EE4EE36C8BF54630BD0532042390F12Aericssoncom_-- From fanf2@hermes.cam.ac.uk Thu Dec 12 03:34:37 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DC951A1F48 for ; Thu, 12 Dec 2013 03:34:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lLH2A4oqHn2E for ; Thu, 12 Dec 2013 03:34:35 -0800 (PST) Received: from ppsw-42.csi.cam.ac.uk (ppsw-42.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f42]) by ietfa.amsl.com (Postfix) with ESMTP id D9FA41A1F58 for ; Thu, 12 Dec 2013 03:34:34 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:45795) by ppsw-42.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1Vr4XD-0006g0-9N (Exim 4.82_3-c0e5623) (return-path ); Thu, 12 Dec 2013 11:34:27 +0000 Received: from fanf2 by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1Vr4XD-0003Hs-Rf (Exim 4.72) (return-path ); Thu, 12 Dec 2013 11:34:27 +0000 Date: Thu, 12 Dec 2013 11:34:27 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Dave Cridland In-Reply-To: Message-ID: References: <20131211021808.14191.qmail@joyce.lan> <52A7D980.5090902@isdg.net> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1870870024-1397402470-1386848067=:11548" Sender: Tony Finch Cc: IETF Apps Discuss Subject: Re: [apps-discuss] draft-delany-nullmx-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 11:34:37 -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. --1870870024-1397402470-1386848067=:11548 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Dave Cridland wrote: > > Second paragraph of =C2=A74 suggests that if there are multiple MX RRs in= cluding > the NULL MX record, then the NULL MX record is treated as any other; this > seems unlikely to be actually desirable. Instead, I suggest that it is > ignored, with a note that if it is merely treated as any other MX RR, it = is > unlikely to cause significant damage. I'd be fascinated to know what Exim > does currently. Exim treats them like any other MX record unless there is only one. (Same as its SRV logic.) I don't think it makes much difference either way, though perhaps there should be a requirement to suppress the target host address lookups whenever the target is ".". (But I note that RFC 2782 does not have such a requirement for SRV records, except when there is a single null SRV.) > The Security Considerations in =C2=A76 might point out that a single NULL= MX RR > might be spoofable more easily via poison cache style attacks Feh, just deploy DNSSEC already! :-) Tony. --=20 f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first= =2E Rough, becoming slight or moderate. Showers, rain at first. Moderate or goo= d, occasionally poor at first. --1870870024-1397402470-1386848067=:11548-- From fanf2@hermes.cam.ac.uk Thu Dec 12 03:38:21 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAFD01A1F5E for ; Thu, 12 Dec 2013 03:38:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id clH3RuvJNFiQ for ; Thu, 12 Dec 2013 03:38:20 -0800 (PST) Received: from ppsw-32.csi.cam.ac.uk (ppsw-32.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f32]) by ietfa.amsl.com (Postfix) with ESMTP id 141771A1F3E for ; Thu, 12 Dec 2013 03:38:19 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:48278) by ppsw-32.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpa (EXTERNAL:fanf2) id 1Vr4am-00054E-20 (Exim 4.82_3-c0e5623) (return-path ); Thu, 12 Dec 2013 11:38:08 +0000 Received: from fanf2 by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1Vr4am-0003XB-Ih (Exim 4.72) (return-path ); Thu, 12 Dec 2013 11:38:08 +0000 Date: Thu, 12 Dec 2013 11:38:08 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: Franck Martin In-Reply-To: <689548087.150615.1386809868145.JavaMail.zimbra@peachymango.org> Message-ID: References: <20131211021808.14191.qmail@joyce.lan> <689548087.150615.1386809868145.JavaMail.zimbra@peachymango.org> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: John Levine , apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-delany-nullmx-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 11:38:22 -0000 Franck Martin wrote: > > My worry is that this structure indicates that the domain name may be > sending emails. It is not uncommon to check if a domain has a A, AAAA or > MX record before accepting email. Isn't this covered by section 5, which says that if you send mail from a domain with a null MX, it probably won't be accepted. (Exim will certainly reject it.) Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From prvs=0051aff727=johnl@iecc.com Thu Dec 12 07:41:37 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 642C41A802A for ; Thu, 12 Dec 2013 07:41:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.793 X-Spam-Level: X-Spam-Status: No, score=-1.793 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h3fWCBBTS7y5 for ; Thu, 12 Dec 2013 07:41:35 -0800 (PST) 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 DB9381A1F77 for ; Thu, 12 Dec 2013 07:41:34 -0800 (PST) Received: (qmail 40050 invoked from network); 12 Dec 2013 15:41:27 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 12 Dec 2013 15:41:27 -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=52a9d927.xn--9vv.k1310; i=johnl@user.iecc.com; bh=uq3n+aYsiKK9ciUmesch1oHWYEpmaqNMOBTX9mpzOJo=; b=JOqYYhEHqAqWXvL7xz5Vm+leIXnIdgzO117h8glrnF2mnt3tGpSJO6cxG1PJbVxoA+myzfoUGywUUy0/UAZHKtHWS8kim2rOdZrIPLFZYQB8Lh1K1h464Bx52nvmwOgfa3b1Y+NkSXAURU4pIiuWuheehzxHYyjkNkoiMNtjXo2rBuWHCo3oHnKc/ujovJphNC6MAPLDG0qRftpGRBNpNcIOLawEe7GhmQGZ6Pp3Jgn5RXqevL2STLbM9nOL4njD 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=52a9d927.xn--9vv.k1310; olt=johnl@user.iecc.com; bh=uq3n+aYsiKK9ciUmesch1oHWYEpmaqNMOBTX9mpzOJo=; b=b7OGLG+7HlJTaf3+3Hw2NWUMwWHkHQ9q3Qx3kUjbuSwNi4CbJ3GJ61xhoxH0ki34QbOWDhDsNm1iCbGF+Gd2DTy8akcSSogBXPyybb3HlEos3mdn59Eec7EpAECFzoK9ScdNBO9sV9jO21vJOZCIn0rgA2fRTkUaUCJdy+XSRALcn6+mwZdQrDUCYX4lwqlsmhoss2Q2fygKyoWPnk0r3+STKpe/SJVpADj0mD/mx2qbQbJgoCRi92n1NF+pWTn8 Date: 12 Dec 2013 15:41:05 -0000 Message-ID: <20131212154105.97433.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] draft-delany-nullmx-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 15:41:37 -0000 >Isn't this covered by section 5, which says that if you send mail from a >domain with a null MX, it probably won't be accepted. (Exim will certainly >reject it.) Everyone agrees that as a matter of good practice, any domain that sends mail should also receive mail, if only to collect the bounces. But no RFC has ever *said* that explicitly. It'd be a change to the underlying spec. Perhaps it's one we will agree to make, but it's not the kind of thing to do casually. R's, John From fanf2@hermes.cam.ac.uk Thu Dec 12 07:47:07 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DE501AE316 for ; Thu, 12 Dec 2013 07:47:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 570VxWNRuWNJ for ; Thu, 12 Dec 2013 07:47:04 -0800 (PST) Received: from ppsw-33.csi.cam.ac.uk (ppsw-33.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f33]) by ietfa.amsl.com (Postfix) with ESMTP id F138C1ADF64 for ; Thu, 12 Dec 2013 07:47:03 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:52470) by ppsw-33.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1Vr8TY-00060b-hF (Exim 4.82_3-c0e5623) (return-path ); Thu, 12 Dec 2013 15:46:56 +0000 Received: from fanf2 by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1Vr8TY-0002oc-Bd (Exim 4.72) (return-path ); Thu, 12 Dec 2013 15:46:56 +0000 Date: Thu, 12 Dec 2013 15:46:56 +0000 From: Tony Finch X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk To: John Levine In-Reply-To: <20131212154105.97433.qmail@joyce.lan> Message-ID: References: <20131212154105.97433.qmail@joyce.lan> User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Tony Finch Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] draft-delany-nullmx-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 15:47:07 -0000 John Levine wrote: > >Isn't this covered by section 5, which says that if you send mail from a > >domain with a null MX, it probably won't be accepted. (Exim will certainly > >reject it.) > > Everyone agrees that as a matter of good practice, any domain that > sends mail should also receive mail, if only to collect the bounces. > > But no RFC has ever *said* that explicitly. It'd be a change to the > underlying spec. Perhaps it's one we will agree to make, but it's not > the kind of thing to do casually. I view a null MX record as saying "this is not a mail domain", and that implies that it can't receive mail and shouldn't be used to send mail, just as if you tried to use nxdomain.example.com as a mail domain. The new thing is the ability to say something isn't a mail domain; there is no change to the rest of the service model. Tony. -- f.anthony.n.finch http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. From Walter.H@mathemainzel.info Thu Dec 12 12:17:11 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A03EB1AE1EE for ; Thu, 12 Dec 2013 12:17:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bsoq9lgGjgMz for ; Thu, 12 Dec 2013 12:17:09 -0800 (PST) Received: from mx14lb.world4you.com (mx14lb.world4you.com [IPv6:2a00:1a68:1:101::1b1b:14]) by ietfa.amsl.com (Postfix) with ESMTP id E28E71ADFBD for ; Thu, 12 Dec 2013 12:17:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mathemainzel.info; s=dkim11; h=Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=Iq9yaOtv4vD3Qmuwzq1a8/sGrMWbRNk8MmrE2oi64A0=; b=aHXa9Wx6iKiE5KRSwC6UaOLDKnoPnqjQdSwqiX+Bu/WFD9Gpi3Mxm+IwWxjC27CJCW/1axWj7vGJ1Yo3imqLGOZhaSo/7dLIZ61ev4uAiZCf0jNK/5d5NahPi0QsE43XRqcc+f2xKKYOMud60/3MgKbE0bjLMYprNM/o1gveX+g=; Received: from [90.146.60.113] (helo=cm56-130-134.liwest.at) by mx14lb.world4you.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1VrCgr-00013M-Nw for apps-discuss@ietf.org; Thu, 12 Dec 2013 21:16:57 +0100 Received: from [mailsrvr] by outgoing.mail (mail delivery) Received: from [mailclnt] by [mailsrvr] Message-ID: <52AA19B9.9050701@mathemainzel.info> Date: Thu, 12 Dec 2013 21:16:57 +0100 From: "Walter H." Organization: Home X-Mailer: Mozilla/5.0 (UNIX; U; Cray X-MP/48; en-US; rv:2.70) Gecko/20110929 Communicator/7.20 MIME-Version: 1.0 To: "apps-discuss@ietf.org >> IETF Apps Discuss" References: <20131212154105.97433.qmail@joyce.lan> In-Reply-To: <20131212154105.97433.qmail@joyce.lan> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020404030001040704080203" X-SA-Do-Not-Run: Yes X-AV-Do-Run: Yes X-SA-Exim-Connect-IP: 90.146.60.113 X-SA-Exim-Mail-From: Walter.H@mathemainzel.info X-SA-Exim-Scanned: No (on mx14lb.world4you.com); SAEximRunCond expanded to false Subject: Re: [apps-discuss] draft-delany-nullmx-01 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Dec 2013 20:17:11 -0000 This is a cryptographically signed message in MIME format. --------------ms020404030001040704080203 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable On 12.12.2013 16:41, John Levine wrote: >> Isn't this covered by section 5, which says that if you send mail from= a >> domain with a null MX, it probably won't be accepted. (Exim will certa= inly >> reject it.) > Everyone agrees that as a matter of good practice, any domain that > sends mail should also receive mail, if only to collect the bounces. Why do you need an MX record? if the zone file of the domain example.com contains one host called www, then you can email to somebody@www.example.com without the need of any=20 MX record ... shouldn't there be the reverse, that in case you have a null MX you are=20 not allowed to be the sender of any email? Walter --------------ms020404030001040704080203 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIS7jCC BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6 qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95 m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy 6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9 sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t 5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGVzCCBT+gAwIBAgIDB7IRMA0GCSqGSIb3DQEB BQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTMwOTI4MTMyODMy WhcNMTQwOTI5MTAwMjI5WjBrMRkwFwYDVQQNExBWbVJDM2RlMnhkY2xkV2UzMSMwIQYDVQQD DBp3YWx0ZXIuaEBtYXRoZW1haW56ZWwuaW5mbzEpMCcGCSqGSIb3DQEJARYad2FsdGVyLmhA bWF0aGVtYWluemVsLmluZm8wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCsecjS QVmgix4Jxz2iGhLz6MGEX2UmmwNmIx36iqhbQ5fu+kWjaUnZY8WIyIA0D1eYMUcFeLFyR06J 5LL7r47QdWWjDkcmrT4JzSMflRGOhgheEE8wBIXi6D7bGo9ySCLG7iRbFoxZHzj9yO3kGq38 Afos9rtncxM3rq9jVf5e7bzJ6rIZl/GLCBexQRuZoUZKBtG7rqfLutRIyd/VljnhRPGg31P/ 3FmuDoMiUtTjYw7HdV+bWDUDV5ZYs9gCZzTlqIfaFojIA8zugFOK24izwFHpz/Q7jAQ06gqB EpEUp2Oyr7ohvMBNoVlTqZp8Rrtbxb84xtnqPtxT0p6/RuNtAgMBAAGjggLgMIIC3DAJBgNV HRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYD VR0OBBYEFF3MzuxEgHE/Le6u4xhuQmO8VdTxMB8GA1UdIwQYMBaAFFNy7ZKc4NrLAVx8fpY1 TvLUuFGCMCUGA1UdEQQeMByBGndhbHRlci5oQG1hdGhlbWFpbnplbC5pbmZvMIIBTAYDVR0g BIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1 ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9m IHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRl ZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlv bnMuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNy bC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0 c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5z dGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqG GGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAIzkTeK+tB22s UiCTtoV48QrIcROVvRygTVQMHRihhuNJbnQuAh7bnUB+hyG2mM9PZY+9YxxAdSkqclJ9TJLm k+C8cuIEC8GUi6UFaAkkjlKiaqfkpAD96FTCuUetMLzViDSkpuDQzR9DkX/UamM3qX6fT8jG gDs9XiGXT1E82sbB+4gtnqH1cp1Ci3sMurw3H5q5MUXg1gdyt59JoNuHDsvLZFAHRFuTpcz8 gXkT9J8N9cUvkzd1XgEbmzldQgQZrrrngKG8SGGfUQozwfUIk83LFhIOr9kyzcnKAQTelFqZ zDLbJrn/arofs5ziNVv2oKbdpbrWXgNA5ZiP5uAMZzCCBlcwggU/oAMCAQICAweyETANBgkq hkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0 YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEzMDky ODEzMjgzMloXDTE0MDkyOTEwMDIyOVowazEZMBcGA1UEDRMQVm1SQzNkZTJ4ZGNsZFdlMzEj MCEGA1UEAwwad2FsdGVyLmhAbWF0aGVtYWluemVsLmluZm8xKTAnBgkqhkiG9w0BCQEWGndh bHRlci5oQG1hdGhlbWFpbnplbC5pbmZvMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEArHnI0kFZoIseCcc9ohoS8+jBhF9lJpsDZiMd+oqoW0OX7vpFo2lJ2WPFiMiANA9XmDFH BXixckdOieSy+6+O0HVlow5HJq0+Cc0jH5URjoYIXhBPMASF4ug+2xqPckgixu4kWxaMWR84 /cjt5Bqt/AH6LPa7Z3MTN66vY1X+Xu28yeqyGZfxiwgXsUEbmaFGSgbRu66ny7rUSMnf1ZY5 4UTxoN9T/9xZrg6DIlLU42MOx3Vfm1g1A1eWWLPYAmc05aiH2haIyAPM7oBTituIs8BR6c/0 O4wENOoKgRKRFKdjsq+6IbzATaFZU6mafEa7W8W/OMbZ6j7cU9Kev0bjbQIDAQABo4IC4DCC AtwwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUF BwMEMB0GA1UdDgQWBBRdzM7sRIBxPy3uruMYbkJjvFXU8TAfBgNVHSMEGDAWgBRTcu2SnODa ywFcfH6WNU7y1LhRgjAlBgNVHREEHjAcgRp3YWx0ZXIuaEBtYXRoZW1haW56ZWwuaW5mbzCC AUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFy dENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3 YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVt ZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUg aW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9i bGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBACM5 E3ivrQdtrFIgk7aFePEKyHETlb0coE1UDB0YoYbjSW50LgIe251AfochtpjPT2WPvWMcQHUp KnJSfUyS5pPgvHLiBAvBlIulBWgJJI5Somqn5KQA/ehUwrlHrTC81Yg0pKbg0M0fQ5F/1Gpj N6l+n0/IxoA7PV4hl09RPNrGwfuILZ6h9XKdQot7DLq8Nx+auTFF4NYHcrefSaDbhw7Ly2RQ B0Rbk6XM/IF5E/SfDfXFL5M3dV4BG5s5XUIEGa6654ChvEhhn1EKM8H1CJPNyxYSDq/ZMs3J ygEE3pRamcwy2ya5/2q6H7Oc4jVb9qCm3aW61l4DQOWYj+bgDGcxggPQMIIDzAIBATCBlDCB jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNz IDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMHshEwCQYFKw4DAhoFAKCCAhAw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMxMjEyMjAxNjU3 WjAjBgkqhkiG9w0BCQQxFgQUqxMrs9N27rCDbmz1W2ewNnDonegwXwYJKoZIhvcNAQkPMVIw UDALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGln aXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFBy aW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDB7IRMIGnBgsqhkiG9w0BCRACCzGBl6CB lDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNl Y3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMHshEwDQYJKoZIhvcNAQEB BQAEggEAY4PevES6XZrbFqtVe6PBVGCNa/R8IUMVD/AMyx/8yGWH4g1UNsPJF+/KFzary0Dd fm9wTZB2G65kyVBSklkFkxOaF41puQGDV9Cw+5oCQ6Q3qXJoIlVfkreYfGuLStSGJgnJbpvJ AJ2DbiGB1paQovLh8lI/ZQCNaJcWs1sGe9rLpQJqjwXG6ZzuGZ68SF1gsQ8qQoNEKX1GPzjX b3NzBxyPjmRYIad/qgYVI9LqAhY2uAnlD90OXBLuwWNylG1zGbS+6dlumER45A4xKSPeC2VQ 8LSzEPJ07EJXbyDN/fADguVtAJgWgGhgpJmMTQRZIkGoNtXE1p0tM+MQqbhpQQAAAAAAAA== --------------ms020404030001040704080203-- From dave@cridland.net Fri Dec 13 06:50:47 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 034CC1AE4E1 for ; Fri, 13 Dec 2013 06:50:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G1DuAHkaFWJy for ; Fri, 13 Dec 2013 06:50:46 -0800 (PST) Received: from mail-oa0-x234.google.com (mail-oa0-x234.google.com [IPv6:2607:f8b0:4003:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id D63521AE4E5 for ; Fri, 13 Dec 2013 06:50:45 -0800 (PST) Received: by mail-oa0-f52.google.com with SMTP id h16so2147307oag.11 for ; Fri, 13 Dec 2013 06:50:39 -0800 (PST) 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=buTLa1tUnXYPLhlSLdL3KzscrNkyfrn6gR8Y4rJeeQg=; b=gMQxL56GU9kQQXhTx8DemjvBEw+xI42vWfSttTHAUDCkTNO1MRYkvuiGJIJgDNt00e ll7lsSVWDxn/1AFZtEDuBFAnxI+NViRfQ9bL6oFy1ajqYLDpV9cIylPDR2mF8z395ivN FVCo+QFYBnPwYhDbLxBiVedJF+VCWw2ka+w5U= 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=buTLa1tUnXYPLhlSLdL3KzscrNkyfrn6gR8Y4rJeeQg=; b=JU8DZzsaaJHEivzY3+tQqjhLhLXVsgV14R72Ry7DRrNaULTGIWY3UqJBakYMmIZPUD t16jrAMCMU2Dzsa5lPjCrC3Qv87jp+RjZAgseUFD8bF93NSAb0fJ0Fdrm8HqFnpGFwa+ 6W0JmAUmj+ccxeU04gITCwaCZ3HLNS14PUjTAUFZ5DKGPwUc2N5viFYJlJJdR78Bqhi6 QGdZxDzXKdLbtzJFj+BrHnVbA3HMn1NxTrlK8PJP/LtM1umW8qCOcbNpt1bbLV6AJ/FA OHPSGRhLqEs4zO0dHnF1EdS+4O26+RA5rEuuRmVuc+St1d+DTVRxVHBTQeBTujtzpw4X PwjQ== X-Gm-Message-State: ALoCoQngId43UGm0YN00rZ8XLcLDHBZHxTiIqvRVxOU40bwMn5TrW+lzgVEqEyj0TZk9EbFtenOC MIME-Version: 1.0 X-Received: by 10.60.47.228 with SMTP id g4mr2015585oen.10.1386946239300; Fri, 13 Dec 2013 06:50:39 -0800 (PST) Received: by 10.60.144.38 with HTTP; Fri, 13 Dec 2013 06:50:39 -0800 (PST) In-Reply-To: <1386824613.80020.YahooMailNeo@web125606.mail.ne1.yahoo.com> References: <20131211233924.25337.38138.idtracker@ietfa.amsl.com> <1386824613.80020.YahooMailNeo@web125606.mail.ne1.yahoo.com> Date: Fri, 13 Dec 2013 14:50:39 +0000 Message-ID: From: Dave Cridland To: "Murray S. Kucherawy" Content-Type: multipart/alternative; boundary=001a11c2fcf6ea9a3d04ed6b95b9 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rrvs-header-field-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 14:50:47 -0000 --001a11c2fcf6ea9a3d04ed6b95b9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I've read this through (relatively quickly), and nothing huge leaps out at me. I think it could possibly be clearer on why MTAs should remove the header fields, but maybe a pointer or two to =A715.3 is all that's needed. In any case, I'm good for this to go forward. --001a11c2fcf6ea9a3d04ed6b95b9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I've read this through (relatively quickly), and nothi= ng huge leaps out at me. I think it could possibly be clearer on why MTAs s= hould remove the header fields, but maybe a pointer or two to =A715.3 is al= l that's needed.

In any case, I'm good for this to go forward.
--001a11c2fcf6ea9a3d04ed6b95b9-- From kurta@drkurt.com Fri Dec 13 08:29:29 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 039AD1AE334 for ; Fri, 13 Dec 2013 08:29:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gi5N9UO4Nh2R for ; Fri, 13 Dec 2013 08:29:27 -0800 (PST) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id A00B71AE323 for ; Fri, 13 Dec 2013 08:29:27 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id hn9so1331741wib.1 for ; Fri, 13 Dec 2013 08:29:20 -0800 (PST) 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=5ze6X4PyVrvpmR7c9SrXi9bTm9NS9C7NPFrPufweTgU=; b=T3S9z3WxtIRakCqLOt23v/32BW0/h4OPlFcaDObtFJbAzxDENlaxJP0xwybVpqwDUv plFjQ+hvsfTyfrRPJfdXmG9Q6t8WxA5Klm/9bjWeZib2DqxRK4dlcMW18BFI5hmVX/BM D3Pz1m8OcoGlYkdyG7x56NyIFpsbBSwi4qMnY= 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=5ze6X4PyVrvpmR7c9SrXi9bTm9NS9C7NPFrPufweTgU=; b=YBLmuXYGQCucxw6z4AIex2OUr8/Pf/mxR3ls6hy4knEeDqjTl7E9RB0/6E/pYybGlv r8OkGRqT2uUbXlwhcoc2jSU6XNqbSPcJqQIVXJfuK6VFqnT7liKTTf6qR/lbphT+ODFT XMbSVdWb6DWiaLgBPu5sfaFZCqcW0In4LlzCQkAfJ3dqONJrZkSqy89RQzxg6tvYGC59 CORfzVmWlkgFdqaloFssxCfyC74MCM/iXogbiYvGA0NjmcZA+qNJL719CQbD1VhC/H0D 5jD+NOQttw5KXdM0PQy9wRbWn8CCPofuiwJjq09xm5Gf5oJ6sKLz0LgnRGcBCUPZzVGj GTxA== X-Gm-Message-State: ALoCoQl6Srwvpqkd48OZLvS3hPlBFtKhyFbRGh3ihedCIA+rnw2qL9c53EtZbyGSxjBvgtg7qJwW MIME-Version: 1.0 X-Received: by 10.194.176.163 with SMTP id cj3mr3147309wjc.8.1386952160892; Fri, 13 Dec 2013 08:29:20 -0800 (PST) Sender: kurta@drkurt.com Received: by 10.194.152.68 with HTTP; Fri, 13 Dec 2013 08:29:20 -0800 (PST) In-Reply-To: References: <20131211233924.25337.38138.idtracker@ietfa.amsl.com> <1386824613.80020.YahooMailNeo@web125606.mail.ne1.yahoo.com> Date: Fri, 13 Dec 2013 08:29:20 -0800 X-Google-Sender-Auth: 3CboPnLnRhjuE2_Y9Pqm_s4oh5s Message-ID: From: Kurt Andersen To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=089e013cbfeadee5e804ed6cf65e Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rrvs-header-field-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 16:29:29 -0000 --089e013cbfeadee5e804ed6cf65e Content-Type: text/plain; charset=ISO-8859-1 Looks good to me also. --Kurt Andersen --089e013cbfeadee5e804ed6cf65e Content-Type: text/html; charset=ISO-8859-1
Looks good to me also.

--Kurt Andersen
--089e013cbfeadee5e804ed6cf65e-- From jtrentadams@gmail.com Fri Dec 13 08:46:47 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C5CF1ADF5E for ; Fri, 13 Dec 2013 08:46:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dnccaOsF7bOi for ; Fri, 13 Dec 2013 08:46:45 -0800 (PST) Received: from mail-oa0-x22c.google.com (mail-oa0-x22c.google.com [IPv6:2607:f8b0:4003:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB981ADEB7 for ; Fri, 13 Dec 2013 08:46:45 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id m1so2343624oag.31 for ; Fri, 13 Dec 2013 08:46:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=m4Tn2vlmT7F8s6Q/R8mqyRKZ3Tjh8mg6xi1ZZfH7jXg=; b=eOwnBCr3zRRawY1FHwevRFrd5R5/FlcXpmrQvTOxZMPbc91AVJ+osGML3oLuDVvA89 jBUPnYx69kzccGr4Sl9wqMH7FrDpi3zKXJlyObs+bqDKPMJ7NBpp8z0rFf9RwJRlxOPn QLz5taXnkH3hI9aFM89qLwOe9y5QiIeCBn9qPkFsqJO4ecIEKJraamAkc/YPy1/1Ojay oUuMyz9iLFY+ruuYj+8buCSj7HxM5PMuytqnSWW/j5buMOHYUl6DHqlFgANdPGlfMtpO 2RmCnREFRqRJBEtF0W8OGHWFsgQ0q4Vpl2fpaBsos1rNuhCLeCzlatTm7mL+Xb2toE09 KNWQ== X-Received: by 10.182.142.229 with SMTP id rz5mr2386669obb.12.1386953199200; Fri, 13 Dec 2013 08:46:39 -0800 (PST) Received: from jtrentadams-isoc.local (c-67-166-0-110.hsd1.co.comcast.net. [67.166.0.110]) by mx.google.com with ESMTPSA id c6sm5215568oeu.6.2013.12.13.08.46.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 13 Dec 2013 08:46:38 -0800 (PST) Message-ID: <52AB39ED.9010604@gmail.com> Date: Fri, 13 Dec 2013 09:46:37 -0700 From: "J. Trent Adams" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20131211233924.25337.38138.idtracker@ietfa.amsl.com> <1386824613.80020.YahooMailNeo@web125606.mail.ne1.yahoo.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rrvs-header-field-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 16:46:47 -0000 I reviewed the current -05 draft with a fine-toothed comb and have submitted my shepherd's writeup using the new, simplified writeup template. It can be found in the datatracker: https://datatracker.ietf.org/doc/draft-ietf-appsawg-rrvs-header-field/shepherdwriteup/ There are only a couple of nits that need to be addressed, but they're purely syntax issues. Specifically, some registry names and sub-tables referenced in the IANA Considerations section need to be clarified, and new enumerated error codes need to be requested (since the codes previously identified in the draft have subsequently been registered). I've communicated these issues to Murray and he has already queued them up for a subsequent revision. Other than that, everything appears to be in order. Unless anyone spots any additional issues needing to be addressed, it looks as if the -05 draft is ready to move to Working Group Last Call (WGLC). - Trent (as document shepherd) On 12/13/13 7:50 AM, Dave Cridland wrote: > I've read this through (relatively quickly), and nothing huge leaps > out at me. I think it could possibly be clearer on why MTAs should > remove the header fields, but maybe a pointer or two to §15.3 is all > that's needed. > > In any case, I'm good for this to go forward. > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- J. Trent Adams Profile: http://www.mediaslate.org/jtrentadams/ LinkedIN: http://www.linkedin.com/in/jtrentadams Twitter: http://twitter.com/jtrentadams From ned.freed@mrochek.com Fri Dec 13 09:50:26 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B90381AE6D4 for ; Fri, 13 Dec 2013 09:50:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mxvFFdsygA_9 for ; Fri, 13 Dec 2013 09:50:25 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 7144A1ADE84 for ; Fri, 13 Dec 2013 09:50:25 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P1WC4DFOGW000J3C@mauve.mrochek.com> for apps-discuss@ietf.org; Fri, 13 Dec 2013 09:45:17 -0800 (PST) MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=iso-8859-1 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P1VFBLVM1C0000AS@mauve.mrochek.com>; Fri, 13 Dec 2013 09:45:15 -0800 (PST) Message-id: <01P1WC4BWKYK0000AS@mauve.mrochek.com> Date: Fri, 13 Dec 2013 08:58:10 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Fri, 13 Dec 2013 09:46:37 -0700" <52AB39ED.9010604@gmail.com> References: <20131211233924.25337.38138.idtracker@ietfa.amsl.com> <1386824613.80020.YahooMailNeo@web125606.mail.ne1.yahoo.com> <52AB39ED.9010604@gmail.com> To: "J. Trent Adams" Cc: apps-discuss@ietf.org Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rrvs-header-field-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 17:50:26 -0000 I finally got a change to review this more carefully. My comments follow. The second point in section 5 should state explicitly that it is talking about the case where the header field is present. As it stands it sounds wierd, because the combination of the receiver implementing the extension and the client not using the SMTP parameter doesn't imply that the header(s) will be present. I also think it would be clearer if the first paragraph of section 5 said "implements this specification" rather than saying "implements the RRVS SMTP extension". The former is more inclusive, and this section is talking about header handling as well as how the extension works. Does the first point in section 5.1 regarding role accounts only apply to local role accounts? Or does this also mean that the RRVS parameter can be dropped from an address like postmaster@remote-domain? Whenever this sort of thing comes up, My immediate inclination is always to say "No, you only look at local parts when you have authority over the domain." But this may be a bit trickier than it sounds, because what happens when an the next hop for postmaster@remote-domain doesn't support the RRVS extension? OTOH, perhaps someone who uses a role account for ordering stuff from Amazon deserves what they get? Maybe I'm missing something, but the third point and the last paragraph in section 5.1 seem to be saying more or less the same thing. I think some compliance language may be in order in section 9.1 - in particular, that the extension MUST be dropped and the header MUST be removed by compliant mailing list expanders. Since we're defining an authentication-results field for this, I think it would be very helpful to have an example of its usage in section 13. Nits: There' a "that that" in the last paragraph of section 4. Alaises in misspelled in the title of section 9.2. That's it! Ned From superuser@gmail.com Fri Dec 13 10:26:47 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC611AE084 for ; Fri, 13 Dec 2013 10:26:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ckoQFKJYKqh for ; Fri, 13 Dec 2013 10:26:44 -0800 (PST) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id E2C4F1ADFEF for ; Fri, 13 Dec 2013 10:26:43 -0800 (PST) Received: by mail-wg0-f54.google.com with SMTP id n12so2212353wgh.21 for ; Fri, 13 Dec 2013 10:26:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NSEIsiFhU0n0e+0ZGw186AtrsZf2lPvlHC414q02uvk=; b=HqPhefFOKIygCczHZw0E9Vb57qMnuBntbyEn+zV+nhWDRoZGyG6GOnd2wUtEXSGDwl daxYNsgvhp3zCkd5lPjsZGNdoUeEXI+nTdE6weaiSm2/jkRYdzSxZhieba3gehJNkj4+ p/6sdIBWDBppaowelKYwXVPsnQQ6jpkK/eEqcgPXUBpCdfVV2UKUWFpJmmZXtSMvoi5e m9FSDb1fMjzR+BcoQCggu9cHeli6Mo17eAlqXYNHd3kd6E8XhJIeiIiEROjwuYO4o44d M0w6ZqfJ3f1fUqftAI6LVjto2pjm9k2lBNapx4V6dzHxXxxEsxXKvr+gx+X/Uyt0WZhG MysQ== MIME-Version: 1.0 X-Received: by 10.194.104.66 with SMTP id gc2mr3447899wjb.75.1386959197039; Fri, 13 Dec 2013 10:26:37 -0800 (PST) Received: by 10.180.84.106 with HTTP; Fri, 13 Dec 2013 10:26:36 -0800 (PST) In-Reply-To: <01P1WC4BWKYK0000AS@mauve.mrochek.com> References: <20131211233924.25337.38138.idtracker@ietfa.amsl.com> <1386824613.80020.YahooMailNeo@web125606.mail.ne1.yahoo.com> <52AB39ED.9010604@gmail.com> <01P1WC4BWKYK0000AS@mauve.mrochek.com> Date: Fri, 13 Dec 2013 10:26:36 -0800 Message-ID: From: "Murray S. Kucherawy" To: Ned Freed Content-Type: multipart/alternative; boundary=089e0102ef8441f2e904ed6e9a61 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rrvs-header-field-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 18:26:47 -0000 --089e0102ef8441f2e904ed6e9a61 Content-Type: text/plain; charset=ISO-8859-1 Thanks, Ned. That's all pretty minor stuff; no objections from me and I'd wager the same from my co-author. Any objecting to dealing with this all during or after WGLC? -MSK On Fri, Dec 13, 2013 at 8:58 AM, Ned Freed wrote: > I finally got a change to review this more carefully. My comments follow. > > The second point in section 5 should state explicitly that it is talking > about the case where the header field is present. As it stands it sounds > wierd, because the combination of the receiver implementing the extension > and the client not using the SMTP parameter doesn't imply that the > header(s) > will be present. > > I also think it would be clearer if the first paragraph of section 5 said > "implements this specification" rather than saying "implements the RRVS > SMTP extension". The former is more inclusive, and this section is > talking about header handling as well as how the extension works. > > Does the first point in section 5.1 regarding role accounts only apply to > local > role accounts? Or does this also mean that the RRVS parameter can be > dropped > from an address like postmaster@remote-domain? Whenever this sort of thing > comes up, My immediate inclination is always to say "No, you only look at > local > parts when you have authority over the domain." But this may be a bit > trickier > than it sounds, because what happens when an the next hop for > postmaster@remote-domain doesn't support the RRVS extension? > > OTOH, perhaps someone who uses a role account for ordering stuff from > Amazon > deserves what they get? > > Maybe I'm missing something, but the third point and the last paragraph > in section 5.1 seem to be saying more or less the same thing. > > I think some compliance language may be in order in section 9.1 - in > particular, that the extension MUST be dropped and the header MUST be > removed > by compliant mailing list expanders. > > Since we're defining an authentication-results field for this, I think it > would > be very helpful to have an example of its usage in section 13. > > Nits: > > There' a "that that" in the last paragraph of section 4. > > Alaises in misspelled in the title of section 9.2. > > That's it! > > Ned > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss > --089e0102ef8441f2e904ed6e9a61 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks, Ned.=A0 That's all pretty minor stuff; no= objections from me and I'd wager the same from my co-author.=A0 Any ob= jecting to dealing with this all during or after WGLC?

-MSK


On Fri, Dec 1= 3, 2013 at 8:58 AM, Ned Freed <ned.freed@mrochek.com> wr= ote:
I finally got a change to review this more c= arefully. My comments follow.

The second point in section 5 should state explicitly that it is talking about the case where the header field is present. As it stands it sounds wierd, because the combination of the receiver implementing the extension and the client not using the SMTP parameter doesn't imply that the head= er(s)
will be present.

I also think it would be clearer if the first paragraph of section 5 said "implements this specification" rather than saying "implemen= ts the RRVS
SMTP extension". The former is more inclusive, and this section is
talking about header handling as well as how the extension works.

Does the first point in section 5.1 regarding role accounts only apply to l= ocal
role accounts? Or does this also mean that the RRVS parameter can be droppe= d
from an address like postmaster@remote-domain? Whenever this sort of thing<= br> comes up, My immediate inclination is always to say "No, you only look= at local
parts when you have authority over the domain." But this may be a bit = trickier
than it sounds, because what happens when an the next hop for
postmaster@remote-domain doesn't support the RRVS extension?

OTOH, perhaps someone who uses a role account for ordering stuff from Amazo= n
deserves what they get?

Maybe I'm missing something, but the third point and the last paragraph=
in section 5.1 seem to be saying more or less the same thing.

I think some compliance language may be in order in section 9.1 - in
particular, that the extension MUST be dropped and the header MUST be remov= ed
by compliant mailing list expanders.

Since we're defining an authentication-results field for this, I think = it would
be very helpful to have an example of its usage in section 13.

Nits:

There' a "that that" in the last paragraph of section 4.

Alaises in misspelled in the title of section 9.2.

That's it!

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Ned
_____________________= __________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

--089e0102ef8441f2e904ed6e9a61-- From wmills@yahoo-inc.com Fri Dec 13 10:32:16 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C148D1ADFEF for ; Fri, 13 Dec 2013 10:32:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.92 X-Spam-Level: X-Spam-Status: No, score=-16.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779, USER_IN_DEF_WHITELIST=-15] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bOjgxKlMZY5f for ; Fri, 13 Dec 2013 10:32:14 -0800 (PST) Received: from mrout2.yahoo.com (mrout2.yahoo.com [216.145.54.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD3E1AD939 for ; Fri, 13 Dec 2013 10:32:14 -0800 (PST) Received: from BF1-EX10-CAHT19.y.corp.yahoo.com (bf1-ex10-caht19.corp.bf1.yahoo.com [10.74.226.63]) by mrout2.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id rBDIVdVT059585 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 13 Dec 2013 10:31:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1386959501; bh=twkaT8q5ETpimXzQRf4w+G/QUh58AyUr5ykIszhAymM=; h=References:Message-ID:Date:From:Reply-To:Subject:To:CC: In-Reply-To:MIME-Version:Content-Type; b=lqdZsSjqWxwqpWTmPpie7mqZ9ttBXadF3vqvO+gF72i4/hiIpb2FBn2ipyrPA0v1g IOVWMlMs2Sc/edUvtxORmILtMZY1rPhGF1Xo21al7C7/pRAYZ+33060BQgWUsissZU l2l/T7+lJ5xrnJ8Kx0WloChUypd6zkLm8ddDrK0E= Received: from omp1079.mail.ne1.yahoo.com (98.138.101.168) by BF1-EX10-CAHT19.y.corp.yahoo.com (10.74.209.170) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 13 Dec 2013 13:31:50 -0500 Received: (qmail 57170 invoked by uid 1000); 13 Dec 2013 18:31:37 -0000 Received: (qmail 47751 invoked by uid 60001); 13 Dec 2013 18:31:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1386959497; bh=JUoBXT1BOTtf28MetcNylfj2MJviM3HgWi6mExR9Ess=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=HwTnHH7yBABu2HToI8UG+ky0+TyHPdl3bHUrNTem+x01xiC/zwOncUp7Ig6ZgoEbk/ircQH8w+FKXa52C6asZaPmlCLeNHy/zDZoQsKw1uMmLYlNX7lfzKYnUAfi8PYCKr7GgpawZoS+k6rqFuwsYkaIxoYD23pA6IMU6tiflbY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=e7EQqy/rGLVHbhkjekgQOsuX+iBJal0iOu6yizO+sdP+0DVFNzWE+ZsHss3zxRmP8H/C6cIFs01zevPx+Elunla04OeQL+n1ebBNIpa+NR7T4R4Xvq6zyGNh/8kJxAumqWc9pBBP6IeBH4VUURttCK5ZRw9+RLqpmxljpj4gDbk=; X-YMail-OSG: WwEg7jUVM1kGDrrPGigh5pwTGWVH7zud8OFz8MI2YHUc7vN SIDvYC.VIt7pzOCfk4iwzfqYh6RBf4zmoyk6n0tyVMg.7oscGRiyAyUkeefz 2SPoR_q_mO7u3bTIFQoLHj7pA3S0ao21vHlvuy3SiDQlrxVF74W0K5_l9wb_ bGFk8LmZV5eGROfHTCF6pjmXpMHgj5eTv58Yofm1L7nNFZotplchbb0V27rj EzWHl0r6AEJWEG37IwjMzP4EIFbKXpIhGbKKGNsSqSlIcV5Tx9dcfEb8Bx0z k8mTX8SBNKYLeFZadoPun8n2z Received: from [98.138.3.86] by web125602.mail.ne1.yahoo.com via HTTP; Fri, 13 Dec 2013 10:31:37 PST X-Rocket-MIMEInfo: 002.001, VGhpcyBhbGwgZ2VuZXJhbGx5IGxvb2tzIHNhbmUgYW5kIHJlYXNvbmFibGUuwqAgCgpPbmUgZGlzY3Vzc2lvbiBwb2ludCwgSSdtIGNvbmNlcm5lZCBpZiBtYWlsaW5nIGxpc3RzIGFyZSBmb3JjZWQgdG8gbW9kaWZ5IGhlYWRlcnMgdGhhdCBpdCB3aWxsIG1heWJlIGJyZWFrIERLSU0gb3Igb3RoZXIgc2lnbmF0dXJlcyB0byBJJ2QgcmF0aGVyIGxlYXZlIHRoYXQgYXMgYSBTSE9VTEQuCgoKwqAKLWJpbGwKCgoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KV2lsbGlhbSBKLiBNaWxscwoiUGFyYW4BMAEBAQE- X-Mailer: YahooMailWebService/0.8.169.609 References: <20131211233924.25337.38138.idtracker@ietfa.amsl.com> <1386824613.80020.YahooMailNeo@web125606.mail.ne1.yahoo.com> <52AB39ED.9010604@gmail.com> <01P1WC4BWKYK0000AS@mauve.mrochek.com> Message-ID: <1386959497.44562.YahooMailNeo@web125602.mail.ne1.yahoo.com> Date: Fri, 13 Dec 2013 10:31:37 -0800 From: Bill Mills To: "Murray S. Kucherawy" , Ned Freed In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1088529044-140663440-1386959497=:44562" X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 959500002 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rrvs-header-field-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 18:32:16 -0000 ---1088529044-140663440-1386959497=:44562 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This all generally looks sane and reasonable.=A0 =0A=0AOne discussion point= , I'm concerned if mailing lists are forced to modify headers that it will = maybe break DKIM or other signatures to I'd rather leave that as a SHOULD.= =0A=0A=0A=A0=0A-bill=0A=0A=0A=0A--------------------------------=0AWilliam = J. Mills=0A"Paranoid" Yahoo!=0A=0A=0A=0A=0A=0AOn Friday, December 13, 2013 = 10:27 AM, Murray S. Kucherawy wrote:=0A =0AThanks, Ne= d.=A0 That's all pretty minor stuff; no objections from me and I'd wager th= e same from my co-author.=A0 Any objecting to dealing with this all during = or after WGLC?=0A=0A-MSK=0A=0A=0A=0A=0AOn Fri, Dec 13, 2013 at 8:58 AM, Ned= Freed wrote:=0A=0AI finally got a change to review= this more carefully. My comments follow.=0A>=0A>The second point in sectio= n 5 should state explicitly that it is talking=0A>about the case where the = header field is present. As it stands it sounds=0A>wierd, because the combi= nation of the receiver implementing the extension=0A>and the client not usi= ng the SMTP parameter doesn't imply that the header(s)=0A>will be present.= =0A>=0A>I also think it would be clearer if the first paragraph of section = 5 said=0A>"implements this specification" rather than saying "implements th= e RRVS=0A>SMTP extension". The former is more inclusive, and this section i= s=0A>talking about header handling as well as how the extension works.=0A>= =0A>Does the first point in section 5.1 regarding role accounts only apply = to local=0A>role accounts? Or does this also mean that the RRVS parameter c= an be dropped=0A>from an address like postmaster@remote-domain? Whenever th= is sort of thing=0A>comes up, My immediate inclination is always to say "No= , you only look at local=0A>parts when you have authority over the domain."= But this may be a bit trickier=0A>than it sounds, because what happens whe= n an the next hop for=0A>postmaster@remote-domain doesn't support the RRVS = extension?=0A>=0A>OTOH, perhaps someone who uses a role account for orderin= g stuff from Amazon=0A>deserves what they get?=0A>=0A>Maybe I'm missing som= ething, but the third point and the last paragraph=0A>in section 5.1 seem t= o be saying more or less the same thing.=0A>=0A>I think some compliance lan= guage may be in order in section 9.1 - in=0A>particular, that the extension= MUST be dropped and the header MUST be removed=0A>by compliant mailing lis= t expanders.=0A>=0A>Since we're defining an authentication-results field fo= r this, I think it would=0A>be very helpful to have an example of its usage= in section 13.=0A>=0A>Nits:=0A>=0A>There' a "that that" in the last paragr= aph of section 4.=0A>=0A>Alaises in misspelled in the title of section 9.2.= =0A>=0A>That's it!=0A>=0A>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 Ned=0A>=0A>_______________________________________________= =0A>apps-discuss mailing list=0A>apps-discuss@ietf.org=0A>https://www.ietf.= org/mailman/listinfo/apps-discuss=0A>=0A=0A=0A_____________________________= __________________=0Aapps-discuss mailing list=0Aapps-discuss@ietf.org=0Aht= tps://www.ietf.org/mailman/listinfo/apps-discuss ---1088529044-140663440-1386959497=:44562 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
One discussion point, I'm concerned if mailing lists are f= orced to modify headers that it will maybe break DKIM or other signatures t= o I'd rather leave that as a SHOULD.

 
<= div id=3D"yiv3278021556yui_3_13_0_ym1_23_1386954355084_12">-bill


---------= -----------------------
William J. Mills
"Paranoid" Yahoo!



O= n Friday, December 13, 2013 10:27 AM, Murray S. Kucherawy <superuser@gmail.com> wrote:
Thanks, Ned.  That's all pre= tty minor stuff; no objections from me and I'd wager the same from my co-au= thor.  Any objecting to dealing with this all during or after WGLC?
-MSK
=0A


On Fri, Dec 13, 2013 at 8:58 AM, Ned F= reed <ned.freed@mrochek.com> wrote:
=0A<= blockquote class=3D"yiv3278021556gmail_quote" style=3D"margin:0 0 0 .8ex;bo= rder-left:1px #ccc solid;padding-left:1ex;">I finally got a change to revie= w this more carefully. My comments follow.
=0A
=0AThe second point in section 5 should state explicitly that it = is talking
=0Aabout the case where the header field is pr= esent. As it stands it sounds
=0Awierd, because the combi= nation of the receiver implementing the extension
=0Aand = the client not using the SMTP parameter doesn't imply that the header(s)=0Awill be present.
=0A
=0AI also think it would be clearer if the first paragraph of section 5 sa= id
=0A"implements this specification" rather than saying = "implements the RRVS
=0ASMTP extension". The former is mo= re inclusive, and this section is
=0Atalking about header= handling as well as how the extension works.
=0A
=0ADoes the first point in section 5.1 regarding role accounts o= nly apply to local
=0Arole accounts? Or does this also me= an that the RRVS parameter can be dropped
=0Afrom an addr= ess like postmaster@remote-domain? Whenever this sort of thing
=0Acomes up, My immediate inclination is always to say "No, you only = look at local
=0Aparts when you have authority over the d= omain." But this may be a bit trickier
=0Athan it sounds,= because what happens when an the next hop for
=0Apostmas= ter@remote-domain doesn't support the RRVS extension?
=0A=
=0AOTOH, perhaps someone who uses a role account for ord= ering stuff from Amazon
=0Adeserves what they get?
=0A
=0AMaybe I'm missing something, but the t= hird point and the last paragraph
=0Ain section 5.1 seem = to be saying more or less the same thing.
=0A
=0AI think some compliance language may be in order in section 9.1 -= in
=0Aparticular, that the extension MUST be dropped and= the header MUST be removed
=0Aby compliant mailing list = expanders.
=0A
=0ASince we're defining = an authentication-results field for this, I think it would
=0Abe very helpful to have an example of its usage in section 13.
=0A
=0ANits:
=0A
=0AThere' a "that that" in the last paragraph of section 4.
=0A
=0AAlaises in misspelled in the title of se= ction 9.2.
=0A
=0AThat's it!
=0A=0A               =                 Ned
=0A
_______________________________________________
=0Aapps-discuss mailing list
=0Aapps-discuss@ietf.org
=0Ahttps://www.ietf.org/mailman/l= istinfo/apps-discuss
=0A


______________= _________________________________
apps-discuss mailing li= st
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss


=
---1088529044-140663440-1386959497=:44562-- From superuser@gmail.com Fri Dec 13 10:37:09 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 887ED1ADFC5 for ; Fri, 13 Dec 2013 10:37:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OiygqoRnd0rv for ; Fri, 13 Dec 2013 10:37:07 -0800 (PST) Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id 7270E1ADF85 for ; Fri, 13 Dec 2013 10:37:07 -0800 (PST) Received: by mail-wg0-f53.google.com with SMTP id k14so2232956wgh.8 for ; Fri, 13 Dec 2013 10:37:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=9gNgmGej/Zo00FRozH51C9M94ENL6gsg6sgjBXVaO2w=; b=rGuSjIM5knNmbtjDVBiHSVILVBRIsPg0lN+EHZMXaze6r4CBpZXiaD5EekAoEadiF5 bhnbFGTB3skNaOjfgh3OPe72VuAm52W/P9N8Soor1JejSesJN8wKcPXIkAFJFiAMZsOQ WHi5FQJo3/cnMB19QCm4I1TIFHCfJ3ZcdLPuS3V4tAh96i7p8x2Li59LnqqZs3KRvQlu 1vPDsGfhhEuYBxVcyzwF1gs812tILoYUJkbrypokEIdXGhJ5tgMpMIvdCCPBFrx0ugEi bwav4MYPEV9qTwNpwuz3x3mYjLQfJPKEtJN73jJPcG0/mtmku1pREgZWnVSFlY9TCxZX Nu1A== MIME-Version: 1.0 X-Received: by 10.180.39.43 with SMTP id m11mr4176514wik.8.1386959820682; Fri, 13 Dec 2013 10:37:00 -0800 (PST) Received: by 10.180.84.106 with HTTP; Fri, 13 Dec 2013 10:37:00 -0800 (PST) Date: Fri, 13 Dec 2013 10:37:00 -0800 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=001a1134cdd86dfad104ed6ebfbb Subject: [apps-discuss] Working Group Last Call: draft-ietf-appsawg-sieve-duplicate X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 18:37:09 -0000 --001a1134cdd86dfad104ed6ebfbb Content-Type: text/plain; charset=ISO-8859-1 Colleagues, This message initiates an extended Working Group Last Call for draft-ietf-appsawg-sieve-duplicate, ending Friday, January 10, 2014. Please submit substantive comments of support or other review feedback to apps-discuss@ietf.org (preferably on this thread), or privately to the authors or to appsawg-chairs@tools.ietf.org, prior to that date. We will need to see enough of these to be able to judge rough consensus of the working group before it can be sent to our Area Director to start the formal publication process. Some discussion of this work has also taken place on sieve@ietf.org. This request will be forwarded there as well, but it would be helpful for the WGLC comments to appear on apps-discuss. The document shepherd is welcome to post the writeup to the datatracker whenever it's ready. Thank you, -MSK, APPSAWG co-chair --001a1134cdd86dfad104ed6ebfbb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Colleagues,

This message initiates a= n extended Working Group Last Call for draft-ietf-appsawg-sieve-duplicate, = ending Friday, January 10, 2014.=A0 Please submit substantive comments of s= upport or other review feedback to apps-discuss@ietf.org (preferably on this thread), or privately to the= authors or to appsawg-cha= irs@tools.ietf.org, prior to that date.=A0 We will need to see enough o= f these to be able to judge rough consensus of the working group before it = can be sent to our Area Director to start the formal publication process.
Some discussion of this work has also taken place on sieve@ietf.org.=A0 This request will be forw= arded there as well, but it would be helpful for the WGLC comments to appea= r on apps-discuss.

The document shepherd is welcome to post the writeup t= o the datatracker whenever it's ready.

Thank you,

<= /div>-MSK, APPSAWG co-chair
--001a1134cdd86dfad104ed6ebfbb-- From superuser@gmail.com Fri Dec 13 10:44:30 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C20561ADFD1 for ; Fri, 13 Dec 2013 10:44:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4K4HRwoV1LTS for ; Fri, 13 Dec 2013 10:44:28 -0800 (PST) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id 828A41ADF85 for ; Fri, 13 Dec 2013 10:44:27 -0800 (PST) Received: by mail-wg0-f52.google.com with SMTP id x13so2241578wgg.31 for ; Fri, 13 Dec 2013 10:44:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wJ13pJGc/4+iw6LznhI+qs5me+6EyjzQ2eziES5Tk5s=; b=H92D2ae76Z+h7iA6hCXEoXLsGV7VRSRrSltLR24BdVmme2AL9+InIDOAbXk6452h/L VmcAhiT1XO2C2HMTBGooXMJrQVxrqkS0BadTVqiXoboe8/LJGrR+w6CoFqdMY8E4uSxR k7yBNbVco/WS6GbRsd0ThrTdhx+vgZ++Yyd8GgftQn6Dl4XX2wp6qREXHXXmGZL7xl0u Ma8kLviqDhxZAJ4SsH3ccmyNCE61AXOIIhf2HXt7wYiJ40pr82/QvIL7gDmMVknJmOkG owBvtdVC3GHkJfkYjEd+yVdgZhFHbFfCY0phDCdA5cHlSm8ZAOWDwyUgEp0VQB9Sk9F/ NWAA== MIME-Version: 1.0 X-Received: by 10.180.221.38 with SMTP id qb6mr3517439wic.8.1386960260643; Fri, 13 Dec 2013 10:44:20 -0800 (PST) Received: by 10.180.84.106 with HTTP; Fri, 13 Dec 2013 10:44:20 -0800 (PST) In-Reply-To: <1386959497.44562.YahooMailNeo@web125602.mail.ne1.yahoo.com> References: <20131211233924.25337.38138.idtracker@ietfa.amsl.com> <1386824613.80020.YahooMailNeo@web125606.mail.ne1.yahoo.com> <52AB39ED.9010604@gmail.com> <01P1WC4BWKYK0000AS@mauve.mrochek.com> <1386959497.44562.YahooMailNeo@web125602.mail.ne1.yahoo.com> Date: Fri, 13 Dec 2013 10:44:20 -0800 Message-ID: From: "Murray S. Kucherawy" To: Bill Mills Content-Type: multipart/alternative; boundary=001a1134d2daa7434604ed6ed9c8 Cc: Ned Freed , IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rrvs-header-field-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 18:44:31 -0000 --001a1134d2daa7434604ed6ed9c8 Content-Type: text/plain; charset=ISO-8859-1 There are two sides tugging at this in the document. We acknowledge that DKIM signatures might be invalidated, but we also say that one way to make sure the content of it can be trusted is to sign it. Also, the prose of DKIM (for example) suggests that this isn't an appropriate header field to sign in the first place because it's not part of the core message content. I'm starting to think the text about signing the field as a way of proving its authenticity might need to go. That way removal of the field doesn't affect anything. Anyone else have a thought here? On Fri, Dec 13, 2013 at 10:31 AM, Bill Mills wrote: > This all generally looks sane and reasonable. > > One discussion point, I'm concerned if mailing lists are forced to modify > headers that it will maybe break DKIM or other signatures to I'd rather > leave that as a SHOULD. > > > > -bill > > > -------------------------------- > William J. Mills > "Paranoid" Yahoo! > > > > On Friday, December 13, 2013 10:27 AM, Murray S. Kucherawy < > superuser@gmail.com> wrote: > Thanks, Ned. That's all pretty minor stuff; no objections from me and > I'd wager the same from my co-author. Any objecting to dealing with this > all during or after WGLC? > > -MSK > > > On Fri, Dec 13, 2013 at 8:58 AM, Ned Freed wrote: > > I finally got a change to review this more carefully. My comments follow. > > The second point in section 5 should state explicitly that it is talking > about the case where the header field is present. As it stands it sounds > wierd, because the combination of the receiver implementing the extension > and the client not using the SMTP parameter doesn't imply that the > header(s) > will be present. > > I also think it would be clearer if the first paragraph of section 5 said > "implements this specification" rather than saying "implements the RRVS > SMTP extension". The former is more inclusive, and this section is > talking about header handling as well as how the extension works. > > Does the first point in section 5.1 regarding role accounts only apply to > local > role accounts? Or does this also mean that the RRVS parameter can be > dropped > from an address like postmaster@remote-domain? Whenever this sort of thing > comes up, My immediate inclination is always to say "No, you only look at > local > parts when you have authority over the domain." But this may be a bit > trickier > than it sounds, because what happens when an the next hop for > postmaster@remote-domain doesn't support the RRVS extension? > > OTOH, perhaps someone who uses a role account for ordering stuff from > Amazon > deserves what they get? > > Maybe I'm missing something, but the third point and the last paragraph > in section 5.1 seem to be saying more or less the same thing. > > I think some compliance language may be in order in section 9.1 - in > particular, that the extension MUST be dropped and the header MUST be > removed > by compliant mailing list expanders. > > Since we're defining an authentication-results field for this, I think it > would > be very helpful to have an example of its usage in section 13. > > Nits: > > There' a "that that" in the last paragraph of section 4. > > Alaises in misspelled in the title of section 9.2. > > That's it! > > Ned > _______________________________________________ > 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 > > > --001a1134d2daa7434604ed6ed9c8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
There are two sides tugging at this in the document.= =A0 We acknowledge that DKIM signatures might be invalidated, but we also s= ay that one way to make sure the content of it can be trusted is to sign it= .=A0 Also, the prose of DKIM (for example) suggests that this isn't an = appropriate header field to sign in the first place because it's not pa= rt of the core message content.

I'm starting to think the text about signing the field as a w= ay of proving its authenticity might need to go.=A0 That way removal of the= field doesn't affect anything.=A0 Anyone else have a thought here?


On Fri,= Dec 13, 2013 at 10:31 AM, Bill Mills <wmills@yahoo-inc.com> wrote:
This all generally looks sane and reasonable.=A0

One discussion point, I'm concerned if mailing lists are fo= rced to modify headers that it will maybe break DKIM or other signatures to= I'd rather leave that as a SHOULD.


=A0
-bill


<= div style=3D"font-style:normal;font-size:13px;background-color:transparent;= font-family:arial,helvetica,clean,sans-serif"> --------------------------------
William J. Mills
"Paranoid" Yahoo!



=
On Friday, December 13, 2013 10:27 AM, Murray S. Kucherawy <superuser@gmail.com> wrote:
 <= /div>
Thanks, Ned.=A0 That's all = pretty minor stuff; no objections from me and I'd wager the same from m= y co-author.=A0 Any objecting to dealing with this all during or after WGLC= ?

-MSK


On Fri, Dec 13, 2013 a= t 8:58 AM, Ned Freed <ned.freed@mroche= k.com> wrote:
I finally got a change to review this more carefully. My comments = follow.

The second point in section 5 should state explicitly that it is talking about the case where the header field is present. As it stands it sounds wierd, because the combination of the receiver implementing the extension and the client not using the SMTP parameter doesn't imply that the head= er(s)
will be present.

I also think it would be clearer if the first paragraph of section 5 said "implements this specification" rather than saying "implemen= ts the RRVS
SMTP extension". The former is more inclusive, and this section is
talking about header handling as well as how the extension works.

Does the first point in section 5.1 regarding role accounts only apply to l= ocal
role accounts? Or does this also mean that the RRVS parameter can be droppe= d
from an address like postmaster@remote-domain? Whenever this sort of thing<= br clear=3D"none"> comes up, My immediate inclination is always to say "No, you only look= at local
parts when you have authority over the domain." But this may be a bit = trickier
than it sounds, because what happens when an the next hop for
postmaster@remote-domain doesn't support the RRVS extension?

OTOH, perhaps someone who uses a role account for ordering stuff from Amazo= n
deserves what they get?

Maybe I'm missing something, but the third point and the last paragraph=
in section 5.1 seem to be saying more or less the same thing.

I think some compliance language may be in order in section 9.1 - in
particular, that the extension MUST be dropped and the header MUST be remov= ed
by compliant mailing list expanders.

Since we're defining an authentication-results field for this, I think = it would
be very helpful to have an example of its usage in section 13.

Nits:

There' a "that that" in the last paragraph of section 4.

Alaises in misspelled in the title of section 9.2.

That's it!

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

<= br clear=3D"none">
_______________________________________________
apps-discuss mailing list
a= pps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo= /apps-discuss



--001a1134d2daa7434604ed6ed9c8-- From superuser@gmail.com Fri Dec 13 10:46:43 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD2311ADF85 for ; Fri, 13 Dec 2013 10:46:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QYxHoQ10UYqo for ; Fri, 13 Dec 2013 10:46:42 -0800 (PST) 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 502FD1AD939 for ; Fri, 13 Dec 2013 10:46:42 -0800 (PST) Received: by mail-we0-f176.google.com with SMTP id w62so2296931wes.35 for ; Fri, 13 Dec 2013 10:46:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=zXt0U700rmhxtcyBsR8OnCIBbIsFK3ZqsEPWN2GZ5DA=; b=RflRfvTeXy5c3h5yZ+vDsS9LmvfMsGhHO3BQcnRPjPUWxwj33MpgWB/XIQFKaTM1Al iImghYqndtXllLKrh3q3s6kEJoUUOolAlHB3A+AoRGEmDITYRFha2UTfd/KvfyFLGdxx VFtRddOI0Om2jdzg3QzYQnsgs2jiSPj54UcqyG9y6Tjq/nfw5jrrq/00QGAdjGFgh4B4 Ko+avBqYpwbsfPKV9PyL+5swk3kaSFHyEDibJW8DhSbBGXnFUQt1HKp/caC/DVrzyxPQ ejft50F9kPusx01Z3batQ6ercRYKacsvRDFSvypnJnwhYWqHFP7iwhqz0xInt6hssK2x hvOw== MIME-Version: 1.0 X-Received: by 10.194.21.225 with SMTP id y1mr3696153wje.60.1386960395535; Fri, 13 Dec 2013 10:46:35 -0800 (PST) Received: by 10.180.84.106 with HTTP; Fri, 13 Dec 2013 10:46:35 -0800 (PST) Date: Fri, 13 Dec 2013 10:46:35 -0800 Message-ID: From: "Murray S. Kucherawy" To: IETF Apps Discuss Content-Type: multipart/alternative; boundary=047d7b5d98abb1922404ed6ee158 Subject: [apps-discuss] Working Group Last Call: draft-ietf-appsawg-xml-mediatypes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 18:46:44 -0000 --047d7b5d98abb1922404ed6ee158 Content-Type: text/plain; charset=ISO-8859-1 Colleagues, This message initiates an extended Working Group Last Call for draft-ietf-appsawg-xml-mediatypes, ending Friday, January 10, 2014. Please submit substantive comments of support or other review feedback to apps-discuss@ietf.org (preferably on this thread), or privately to the authors or to appsawg-chairs@tools.ietf.org, prior to that date. We will need to see enough of these to be able to judge rough consensus of the working group before it can be sent to our Area Director to start the formal publication process. The document shepherd is welcome to post the writeup to the datatracker whenever it's ready. Thank you, -MSK, APPSAWG co-chair --047d7b5d98abb1922404ed6ee158 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Colleagues,

This message initiates a= n extended Working Group Last Call for draft-ietf-appsawg-xml-mediatypes, e= nding Friday, January 10, 2014.=A0 Please submit substantive comments of su= pport or other review feedback to apps-discuss@ietf.org (preferably on this thread), or= privately to the authors or to appsawg-chairs@tools.ietf.org, prior to that date.=A0 We will need to see enough of these to be able to= =20 judge rough consensus of the working group before it can be sent to our=20 Area Director to start the formal publication process.

The document shepherd is welcome to post the writeup to the datat= racker whenever it's ready.

Thank you,

-MSK, = APPSAWG co-chair
--047d7b5d98abb1922404ed6ee158-- From wmills@yahoo-inc.com Fri Dec 13 10:54:05 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E8301AE6EE for ; Fri, 13 Dec 2013 10:54:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.92 X-Spam-Level: X-Spam-Status: No, score=-16.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779, USER_IN_DEF_WHITELIST=-15] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TImB1DBMceN8 for ; Fri, 13 Dec 2013 10:54:02 -0800 (PST) Received: from mrout3.yahoo.com (mrout3.yahoo.com [216.145.54.173]) by ietfa.amsl.com (Postfix) with ESMTP id 589851ADFE5 for ; Fri, 13 Dec 2013 10:54:02 -0800 (PST) Received: from GQ1-EX10-CAHT17.y.corp.yahoo.com (gq1-ex10-caht17.corp.gq1.yahoo.com [10.73.119.198]) by mrout3.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id rBDIr81A057992 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 13 Dec 2013 10:53:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1386960789; bh=wY3SuyeY2UBoAgbnFdVhJ/Ad5sEZCfbdf35bbc8eyAU=; h=References:Message-ID:Date:From:Reply-To:Subject:To:CC: In-Reply-To:MIME-Version:Content-Type; b=in7VfIUU4uuWqfkYROLBhpKeFGw+GXBU8JO8fz/xJ3uxcA2rUV6jE+SjB0xtD6e4C eEvHzpNAmjNYg47UVwXNi6D4hG7ReabDRj71tP2ZzMxOSL4oGhaois5vxGVG7pUi42 E+smaws7gnCzj3fjfM4hPrnVkwAUiV3YILeAmBWQ= Received: from omp1085.mail.ne1.yahoo.com (98.138.101.174) by GQ1-EX10-CAHT17.y.corp.yahoo.com (10.72.228.24) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 13 Dec 2013 10:53:07 -0800 Received: (qmail 59045 invoked by uid 1000); 13 Dec 2013 18:53:07 -0000 Received: (qmail 74653 invoked by uid 60001); 13 Dec 2013 18:53:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1386960787; bh=NlpxOY0IlQHUrKKInHX2qrOsgrGAJPjmbvDrLJLoKxM=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=TVrPSHjJm0rtU9SdIzsWFdWZVmrQyMEZYASw6JHDSqS9gSqfDhUDfMZL+yBvmIQ2dlQtbEsztkdbISqbIuqbnugQo94BVTJAw6jsXgiB4CL8W+Pvgtp+6n1ox8BF7RLG27THgMpEOe+4aXXCQqhY1m0IvIB0KxUNS9wHrWW4Sb4= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=EwRWh854XJd75DpBx569KIe54PYoRqdlMe7KvqeQ3psXb486bxBStoq6/VQdgi7nYRHQSZNnZXSFeTQEq8k3x0dDXeHuIUOiH+j5zInhVmCImuDRA50HIAcbanLYGoLDtmZJFXI6Oy7VSl7fsaZ4CCsW9MlL6YnYxmYQhgeXP2Y=; X-YMail-OSG: BNTVp.4VM1nLg1sL4fn78dl7nr_Fq4.eX24ErgYgPfaiXlR it04wkeUjksvwpEEdyy94PpVjkY.ZBgHVO_Uid.Hmui3CChYPyrIcLSn5qLT A0mORpjUQqRjyxAOwtdAAWc9J3M8Kbw15On3Hrm5FdLSM0NOolAaewIRJJ64 ZB0DEs9RMvuqybMXnyJylf8fTNaDPyMrSa0nIG.u9Jsw7a2n8ZxOfHx1xuiq Agce42TSUE2AA0cCfmdmbzGG3Xp12adFWO7Ws7W5c5nEhOpLKIXbq0cD8QL1 EREG.SQ9cDNNMybhyztk- Received: from [98.138.3.86] by web125605.mail.ne1.yahoo.com via HTTP; Fri, 13 Dec 2013 10:53:07 PST X-Rocket-MIMEInfo: 002.001, V2Ugc2hvdWxkIHNheSBpdCBzaG91bGQgbm90IGJlIHBhcnQgb2YgdGhlIERLSU0gc2lnbmF0dXJlLsKgIFRoaXMgbWFrZXMgc2Vuc2UgYmVjYXVzZSB3ZSdyZSBzYXlpbmcgdGhlIGhlYWRlciBpcyBpbiBmYWN0IGVwaGVtZXJhbCBhbmQgZm9yIHRoZSB1c2Ugb2YgdGhlIG1haWxlcnMgYW5kIG5vdCB0aGUgZW5kIHVzZXIgb3IgTVVBLgoKVGhlcmUncyBsaXR0bGUgaW1wYWN0IG9mIGhhdmluZyBpdCBvdXRzaWRlIHRoZSBES0lNIHNpZ25hdHVyZS7CoCBUaGUgb25seSB0aGluZyBJIGNhbiB0aGluayBvZiBpcyABMAEBAQE- X-Mailer: YahooMailWebService/0.8.169.609 References: <20131211233924.25337.38138.idtracker@ietfa.amsl.com> <1386824613.80020.YahooMailNeo@web125606.mail.ne1.yahoo.com> <52AB39ED.9010604@gmail.com> <01P1WC4BWKYK0000AS@mauve.mrochek.com> <1386959497.44562.YahooMailNeo@web125602.mail.ne1.yahoo.com> Message-ID: <1386960787.36390.YahooMailNeo@web125605.mail.ne1.yahoo.com> Date: Fri, 13 Dec 2013 10:53:07 -0800 From: Bill Mills To: "Murray S. Kucherawy" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1124617404-1003454259-1386960787=:36390" X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 960788001 Cc: Ned Freed , IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rrvs-header-field-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 18:54:05 -0000 ---1124617404-1003454259-1386960787=:36390 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We should say it should not be part of the DKIM signature.=A0 This makes se= nse because we're saying the header is in fact ephemeral and for the use of= the mailers and not the end user or MUA.=0A=0AThere's little impact of hav= ing it outside the DKIM signature.=A0 The only thing I can think of is that= if an MX is checking DKIM to decide if it will honor RRVS then an attacker= could probe account age if they could intercept mail in transit.=A0 Not a = big problem.=0A=0A=A0=0A-bill=0A=0A=0A=0A--------------------------------= =0AWilliam J. Mills=0A"Paranoid" Yahoo!=0A=0A=0A=0A=0A=0AOn Friday, Decembe= r 13, 2013 10:44 AM, Murray S. Kucherawy wrote:=0A = =0AThere are two sides tugging at this in the document.=A0 We acknowledge t= hat DKIM signatures might be invalidated, but we also say that one way to m= ake sure the content of it can be trusted is to sign it.=A0 Also, the prose= of DKIM (for example) suggests that this isn't an appropriate header field= to sign in the first place because it's not part of the core message conte= nt.=0A=0AI'm starting to think the text about signing the field as a way of= proving its authenticity might need to go.=A0 That way removal of the fiel= d doesn't affect anything.=A0 Anyone else have a thought here?=0A=0A=0A=0A= =0AOn Fri, Dec 13, 2013 at 10:31 AM, Bill Mills wrot= e:=0A=0AThis all generally looks sane and reasonable.=A0 =0A>=0A>One discus= sion point, I'm concerned if mailing lists are forced to modify headers tha= t it will maybe break DKIM or other signatures to I'd rather leave that as = a SHOULD.=0A>=0A>=0A>=0A>=0A>=A0=0A>-bill=0A>=0A>=0A>=0A>------------------= --------------=0A>William J. Mills=0A>"Paranoid" Yahoo!=0A>=0A>=0A>=0A>=0A>= =0A>=0A>On Friday, December 13, 2013 10:27 AM, Murray S. Kucherawy wrote:=0A> =0A>Thanks, Ned.=A0 That's all pretty minor stuff;= no objections from me and I'd wager the same from my co-author.=A0 Any obj= ecting to dealing with this all during or after WGLC?=0A>=0A>-MSK=0A>=0A>= =0A>=0A>=0A>On Fri, Dec 13, 2013 at 8:58 AM, Ned Freed wrote:=0A>=0A>I finally got a change to review this more carefully. My = comments follow.=0A>>=0A>>The second point in section 5 should state explic= itly that it is talking=0A>>about the case where the header field is presen= t. As it stands it sounds=0A>>wierd, because the combination of the receive= r implementing the extension=0A>>and the client not using the SMTP paramete= r doesn't imply that the header(s)=0A>>will be present.=0A>>=0A>>I also thi= nk it would be clearer if the first paragraph of section 5 said=0A>>"implem= ents this specification" rather than saying "implements the RRVS=0A>>SMTP e= xtension". The former is more inclusive, and this section is=0A>>talking ab= out header handling as well as how the extension works.=0A>>=0A>>Does the f= irst point in section 5.1 regarding role accounts only apply to local=0A>>r= ole accounts? Or does this also mean that the RRVS parameter can be dropped= =0A>>from an address like postmaster@remote-domain? Whenever this sort of t= hing=0A>>comes up, My immediate inclination is always to say "No, you only = look at local=0A>>parts when you have authority over the domain." But this = may be a bit trickier=0A>>than it sounds, because what happens when an the = next hop for=0A>>postmaster@remote-domain doesn't support the RRVS extensio= n?=0A>>=0A>>OTOH, perhaps someone who uses a role account for ordering stuf= f from Amazon=0A>>deserves what they get?=0A>>=0A>>Maybe I'm missing someth= ing, but the third point and the last paragraph=0A>>in section 5.1 seem to = be saying more or less the same thing.=0A>>=0A>>I think some compliance lan= guage may be in order in section 9.1 - in=0A>>particular, that the extensio= n MUST be dropped and the header MUST be removed=0A>>by compliant mailing l= ist expanders.=0A>>=0A>>Since we're defining an authentication-results fiel= d for this, I think it would=0A>>be very helpful to have an example of its = usage in section 13.=0A>>=0A>>Nits:=0A>>=0A>>There' a "that that" in the la= st paragraph of section 4.=0A>>=0A>>Alaises in misspelled in the title of s= ection 9.2.=0A>>=0A>>That's it!=0A>>=0A>>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Ned=0A>>=0A>>______________________________= _________________=0A>>apps-discuss mailing list=0A>>apps-discuss@ietf.org= =0A>>https://www.ietf.org/mailman/listinfo/apps-discuss=0A>>=0A>=0A>=0A>___= ____________________________________________=0A>apps-discuss mailing list= =0A>apps-discuss@ietf.org=0A>https://www.ietf.org/mailman/listinfo/apps-dis= cuss=0A>=0A>=0A> ---1124617404-1003454259-1386960787=:36390 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
We should= say it should not be part of the DKIM signature.  This makes sense be= cause we're saying the header is in fact ephemeral and for the use of the m= ailers and not the end user or MUA.

There's little impact of having = it outside the DKIM signature.  The only thing I can think of is that = if an MX is checking DKIM to decide if it will honor RRVS then an attacker = could probe account age if they could intercept mail in transit.  Not = a big problem.
 
-bill


---------------= -----------------
William J. Mills
"Paranoid" Yahoo!


On Friday, December 13, 2013 10:= 44 AM, Murray S. Kucherawy <superuser@gmail.com> wrote:
 <= /div>
There are two sides tugging at this in the document.  = We acknowledge that DKIM signatures might be invalidated, but we also say t= hat one way to make sure the content of it can be trusted is to sign it.&nb= sp; Also, the prose of DKIM (for example) suggests that this isn't an appro= priate header field to sign in the first place because it's not part of the= core message content.
=0A
I'm st= arting to think the text about signing the field as a way of proving its au= thenticity might need to go.  That way removal of the field doesn't af= fect anything.  Anyone else have a thought here?
=0A=


On Fri, Dec 13, 2013 at 10:31 = AM, Bill Mills <wmills@yahoo-inc.com> wrote:
=0A
=0AThis all generally looks sane and reasona= ble. 

One discussion point, I'm = concerned if mailing lists are forced to modify headers that it will maybe = break DKIM or other signatures to I'd rather leave that as a SHOULD.
=0A

 
-bill


=0A--------------------------------
William J. Mills=
"Paranoid" Yahoo!


=0A
=0A
On Friday, December 13, 2013 10:27=0A AM, Murray S. Kuc= herawy <superuser@g= mail.com> wrote:
<= div dir=3D"ltr">
Thanks, Ned.  That's all pretty minor stuff; no o= bjections from me and I'd wager the same from my co-author.  Any objec= ting to dealing with this all during or after WGLC?
=0A
-MSK
=0A


On Fri, Dec 13, 2013 at 8:58 AM, Ned Free= d <ned.freed@mrochek.com> wrote:
=0A=0A<= blockquote style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le= ft:1ex;">I finally got a change to review this more carefully. My comments = follow.
=0A
=0AThe second point in sect= ion 5 should state explicitly that it is talking
=0Aabout= the case where the header field is present. As it stands it sounds
=0Awierd, because the combination of the receiver implementing t= he extension
=0Aand the client not using the SMTP paramet= er doesn't imply that the header(s)
=0Awill be present.=0A
=0AI also think it would be clearer = if the first paragraph of section 5 said
=0A"implements t= his specification" rather than saying "implements the RRVS
=0ASMTP extension". The former is more inclusive, and this section is
=0Atalking about header handling as well as how the extensio= n works.
=0A
=0ADoes the first point in= section 5.1 regarding role accounts only apply to local
= =0Arole accounts? Or does this also mean that the RRVS parameter can be dro= pped
=0Afrom an address like postmaster@remote-domain? Wh= enever this sort of thing
=0Acomes up, My immediate incli= nation is always to say "No, you only look at local
=0Apa= rts when you have authority over the domain." But this may be a bit trickie= r
=0Athan it sounds, because what happens when an the nex= t hop for
=0Apostmaster@remote-domain doesn't support the= RRVS extension?
=0A
=0AOTOH, perhaps s= omeone who uses a role account for ordering stuff from Amazon
=0Adeserves what they get?
=0A
=0A= Maybe I'm missing something, but the third point and the last paragraph
=0Ain section 5.1 seem to be saying more or less the same th= ing.
=0A
=0AI think some compliance lan= guage may be in order in section 9.1 - in
=0Aparticular, = that the extension MUST be dropped and the header MUST be removed
=0Aby compliant mailing list expanders.
=0A
=0ASince we're defining an authentication-results field for = this, I think it would
=0Abe very helpful to have an exam= ple of its usage in section 13.
=0A
=0A= Nits:
=0A
=0AThere' a "that that" in th= e last paragraph of section 4.
=0A
=0AA= laises in misspelled in the title of section 9.2.
=0A
=0AThat's it!
=0A
=0A             =                   Ned
=0A
_____________________________________= __________
=0Aapps-discuss mailing list
=0Aapps-discuss@i= etf.org
=0Ahtt= ps://www.ietf.org/mailman/listinfo/apps-discuss
=0A

_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
=0Ahttps://www.ietf.org/mailma= n/listinfo/apps-discuss


=0A



---1124617404-1003454259-1386960787=:36390-- From jtrentadams@gmail.com Fri Dec 13 10:57:07 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA5E31ADFA4 for ; Fri, 13 Dec 2013 10:57:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SLPmSagI0BZ1 for ; Fri, 13 Dec 2013 10:57:06 -0800 (PST) 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 0D8721ADC03 for ; Fri, 13 Dec 2013 10:57:06 -0800 (PST) Received: by mail-ob0-f169.google.com with SMTP id wm4so2397344obc.28 for ; Fri, 13 Dec 2013 10:56:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=BpY6Wx9BynbcjNBsHrTHqIMHOAU0kaXifNy16eZnAW4=; b=IuNR8Hz/gFZVZw4ZY1AIiOd8P8YeuP4DI6asYF9BJozK/v+mGnjtU+RsU/FRDB5nEY nmuOA7YTKm+qz9wYunMbM45KmqPnyfGFEt6b+BzGfpxOx/rINxrgYSLWftdyn5ZWKu6Z 6qkTOiwK9Frg5SR1RouI5o0RXNWedwp0MyP+gnuD25QqzB/EBB3kgg+a9VScG4FXAcD0 GdLnKl6oQABw2/pXZEWYVy2cLFa1M3ClxgQWLzQ6tNAmy6ZR5zvfWvEXCamp5c6h8Mw9 S6JPXGKQ9Pl1KZ+mgVa9I8LGq/lKycWdyRP+LH2+2KmZPO9hyc7ft/EiG0taGWoBPUa3 /59g== X-Received: by 10.182.229.34 with SMTP id sn2mr174214obc.86.1386961019577; Fri, 13 Dec 2013 10:56:59 -0800 (PST) Received: from jtrentadams-isoc.local (c-67-166-0-110.hsd1.co.comcast.net. [67.166.0.110]) by mx.google.com with ESMTPSA id ej7sm4697339obb.8.2013.12.13.10.56.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 13 Dec 2013 10:56:59 -0800 (PST) Message-ID: <52AB587A.4030204@gmail.com> Date: Fri, 13 Dec 2013 11:56:58 -0700 From: "J. Trent Adams" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: apps-discuss@ietf.org References: <20131211233924.25337.38138.idtracker@ietfa.amsl.com> <1386824613.80020.YahooMailNeo@web125606.mail.ne1.yahoo.com> <52AB39ED.9010604@gmail.com> <01P1WC4BWKYK0000AS@mauve.mrochek.com> <1386959497.44562.YahooMailNeo@web125602.mail.ne1.yahoo.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rrvs-header-field-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 18:57:08 -0000 On 12/13/13 11:44 AM, Murray S. Kucherawy wrote: > There are two sides tugging at this in the document. We acknowledge > that DKIM signatures might be invalidated, but we also say that one > way to make sure the content of it can be trusted is to sign it. > Also, the prose of DKIM (for example) suggests that this isn't an > appropriate header field to sign in the first place because it's not > part of the core message content. > > I'm starting to think the text about signing the field as a way of > proving its authenticity might need to go. That way removal of the > field doesn't affect anything. Anyone else have a thought here? First, I think that this is an issue we can address within WGLC and shouldn't hold up the process. As far as a possible solution, it might be possible to explore allowing for a DKIM signature dedicated to the RRVS header, which is separate from the main signature. That would allow the RRVS signature to break while allowing the main content signature to remain valid. FFT, Trent > > > On Fri, Dec 13, 2013 at 10:31 AM, Bill Mills > wrote: > > This all generally looks sane and reasonable. > > One discussion point, I'm concerned if mailing lists are forced to > modify headers that it will maybe break DKIM or other signatures > to I'd rather leave that as a SHOULD. > > > > -bill > > > -------------------------------- > William J. Mills > "Paranoid" Yahoo! > > > > On Friday, December 13, 2013 10:27 AM, Murray S. Kucherawy > > wrote: > Thanks, Ned. That's all pretty minor stuff; no objections from me > and I'd wager the same from my co-author. Any objecting to > dealing with this all during or after WGLC? > > -MSK > > > On Fri, Dec 13, 2013 at 8:58 AM, Ned Freed > wrote: > > I finally got a change to review this more carefully. My > comments follow. > > The second point in section 5 should state explicitly that it > is talking > about the case where the header field is present. As it stands > it sounds > wierd, because the combination of the receiver implementing > the extension > and the client not using the SMTP parameter doesn't imply that > the header(s) > will be present. > > I also think it would be clearer if the first paragraph of > section 5 said > "implements this specification" rather than saying "implements > the RRVS > SMTP extension". The former is more inclusive, and this section is > talking about header handling as well as how the extension works. > > Does the first point in section 5.1 regarding role accounts > only apply to local > role accounts? Or does this also mean that the RRVS parameter > can be dropped > from an address like postmaster@remote-domain? Whenever this > sort of thing > comes up, My immediate inclination is always to say "No, you > only look at local > parts when you have authority over the domain." But this may > be a bit trickier > than it sounds, because what happens when an the next hop for > postmaster@remote-domain doesn't support the RRVS extension? > > OTOH, perhaps someone who uses a role account for ordering > stuff from Amazon > deserves what they get? > > Maybe I'm missing something, but the third point and the last > paragraph > in section 5.1 seem to be saying more or less the same thing. > > I think some compliance language may be in order in section > 9.1 - in > particular, that the extension MUST be dropped and the header > MUST be removed > by compliant mailing list expanders. > > Since we're defining an authentication-results field for this, > I think it would > be very helpful to have an example of its usage in section 13. > > Nits: > > There' a "that that" in the last paragraph of section 4. > > Alaises in misspelled in the title of section 9.2. > > That's it! > > Ned > _______________________________________________ > 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 > > > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- J. Trent Adams Profile: http://www.mediaslate.org/jtrentadams/ LinkedIN: http://www.linkedin.com/in/jtrentadams Twitter: http://twitter.com/jtrentadams From prvs=0052a4143e=johnl@iecc.com Fri Dec 13 11:15:26 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AE6F1AE3CA for ; Fri, 13 Dec 2013 11:15:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.793 X-Spam-Level: X-Spam-Status: No, score=-1.793 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mk5EXA_lCltc for ; Fri, 13 Dec 2013 11:15:25 -0800 (PST) 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 AD3B21AE3A2 for ; Fri, 13 Dec 2013 11:15:24 -0800 (PST) Received: (qmail 33565 invoked from network); 13 Dec 2013 19:15:17 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 13 Dec 2013 19:15:17 -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=52ab5cc5.xn--btvx9d.k1310; i=johnl@user.iecc.com; bh=8QCPw1RsXKfhZRo1qNVwb/uthwnVRiCeUcFmC3M0o8U=; b=t1ZbKVd7w52O1ddDusfhTKnB0jwL5QDaCqkIOaLObCzZRLR+eZs87KIvZntaRyACAM5J7O44LOUBc5DCjDEQKbQy6TjvOG17BgZeGZ5L3dLuTjh7u5xfJxiY3dUjG9FJ8mX/soKDl+ugT8npJFs/zTeakLmAPqDPE1BNVq0wlSd/Gnvqtdew9Ce72VgkjFwR5B9FtuueJJY9roqEBwEId4P8gk8LHUScEXvHl+J8t6NgyykHQRQbvfLAuAJw9Zs4 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=52ab5cc5.xn--btvx9d.k1310; olt=johnl@user.iecc.com; bh=8QCPw1RsXKfhZRo1qNVwb/uthwnVRiCeUcFmC3M0o8U=; b=TNyPJMnlzODvzwADeYlNxt1Q6ZfNTbOY+2y+etJMgzGQpz2uPEa6xcFo8gqSbJQz4huG8NS1MLmY0Jvw8uOc89Krxy+S6hxuJo9ELMbAEfQ3Ye4XkTZR0vePIjjRf70q02ZnNj3kqh5ojwqkH7sG5lTbu5i/tz0a6Tw2fo0vPpmDA1jvn5wduLMgOo8BdZ1axIPYBK30OS+chQqmOH+xBO+QZZjd/DCEmvQnkZDutM9JUVL+TxvHYvRrhxOM9zCx Date: 13 Dec 2013 19:14:55 -0000 Message-ID: <20131213191455.10296.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] I-D Action: draft-ietf-appsawg-rrvs-header-field-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 19:15:26 -0000 >I'm starting to think the text about signing the field as a way of proving >its authenticity might need to go. That way removal of the field doesn't >affect anything. Anyone else have a thought here? I'm trying to think of evil things that a Bad Person might do with a fake RRVS header, and none of them are very evil. Either the fake header has a very old date, so the message bounces needlessly, or it has a very recent date so it's delivered like it would be if there were no RRVS header or the recipient didn't interpret them. I'd lose the signing language, or perhaps reverse it to say don't sign the RRVS header so that gateways that delete the header won't break the signature. R's, John From prvs=0052a4143e=johnl@iecc.com Fri Dec 13 11:16:38 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8E011ADF85 for ; Fri, 13 Dec 2013 11:16:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.793 X-Spam-Level: X-Spam-Status: No, score=-1.793 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CuSm8s3xeGuZ for ; Fri, 13 Dec 2013 11:16:37 -0800 (PST) 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 71C5F1ADF5C for ; Fri, 13 Dec 2013 11:16:37 -0800 (PST) Received: (qmail 33754 invoked from network); 13 Dec 2013 19:16:30 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 13 Dec 2013 19:16:30 -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=52ab5d0e.xn--9vv.k1310; i=johnl@user.iecc.com; bh=J71/axrYxuGAyj/IkO59JzRPzM9SIGa+y0jKSQrfRjI=; b=i8vs2mg3Kom9qgcHhGrmtYRnp4gLG3BRfIBqPR/rkU9kOfQEYIvvsKb1qKhQJOdqbtRlPIuwAlFBTVcp2oIp/eTabAbIXE+l87woXNUyWtb+FpS2coH3dC6GrSX8lpEnZuTKDqdwT6L1SnwLMPFL9Ixyj3fNg8S+Qn5puCRukl3QYaGIIEeNFxyhtGb3F8dk2sIHfPrKB8YfjCdi2tG9Q3ZRmg9UGYuuEiYyYxoUXBkA1prhyXdhm0deYB6cpQtQ 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=52ab5d0e.xn--9vv.k1310; olt=johnl@user.iecc.com; bh=J71/axrYxuGAyj/IkO59JzRPzM9SIGa+y0jKSQrfRjI=; b=BSrUezXDo/Thlmx/CuHdGzk3zBhWwtlXBn3Z72aHazpUrhWUrfOEfsM4s+HFUiDsa4+GWOJlJSFQpsFDh2C1UiuS0a6i+GVzIIKgJhYknrE3qlxW6RpELgMjAXiyZ/fKWdgv5PsGBAIybpK9Iw291o6bVOsF2ZrxgLuT01T1K9ZcUJLxzbpe1aPS+OF+LCp/q7Wsu/Q+deUnXlH9rx6Mm2biHHps5WTt2Yh3XKFYy9BUGexSj2/6BzgVFMo4NPhG Date: 13 Dec 2013 19:16:08 -0000 Message-ID: <20131213191608.10318.qmail@joyce.lan> From: "John Levine" To: apps-discuss@ietf.org In-Reply-To: <52AB587A.4030204@gmail.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rrvs-header-field-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 19:16:38 -0000 >As far as a possible solution, it might be possible to explore allowing >for a DKIM signature dedicated to the RRVS header, which is separate >from the main signature. That would allow the RRVS signature to break >while allowing the main content signature to remain valid. You could certainly do two signatures, one with the RRVS header and one without, but I'm still not sure that solves a problem worth solving. R's, John From salvatore.loreto@ericsson.com Fri Dec 13 11:49:13 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD0DC1AE3F2 for ; Fri, 13 Dec 2013 11:49:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.239 X-Spam-Level: X-Spam-Status: No, score=-1.239 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lEYDyYVsrn4O for ; Fri, 13 Dec 2013 11:49:11 -0800 (PST) Received: from sessmg21.mgmt.ericsson.se (sessmg21.ericsson.net [193.180.251.40]) by ietfa.amsl.com (Postfix) with ESMTP id 0C9D91AE110 for ; Fri, 13 Dec 2013 11:49:10 -0800 (PST) X-AuditID: c1b4fb28-b7f268e000001b97-dd-52ab64af489c Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg21.mgmt.ericsson.se (Symantec Mail Security) with SMTP id A8.FA.07063.FA46BA25; Fri, 13 Dec 2013 20:49:03 +0100 (CET) Received: from ESESSMB109.ericsson.se ([169.254.9.192]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.02.0347.000; Fri, 13 Dec 2013 20:48:59 +0100 From: Salvatore Loreto To: IETF Apps Discuss Thread-Topic: Working Group Last Call: draft-ietf-appsawg-rrvs-header-field-05 Thread-Index: AQHO+Dxd1NoT+cKXpUyGqWHCXANuLA== Date: Fri, 13 Dec 2013 19:48:58 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_D012CD2FB9E647319D462455FEF91A32ericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUyM+Jvre76lNVBBn3X5C1Wv1zB5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujK/TTQsmilY0HfvP1MC4WaiLkZNDQsBEYvOT76wQtpjEhXvr 2boYuTiEBE4wSty6e5URwlnCKLH+9h92kCo2ATOJ5w+3MIPYIgK6Ep//XmUCsYUFPCUePzvN CBEPkNi39iYThK0nsXDqBbB6FgFVid8HIWp4Bewlvu3+DVbDCLT5+6k1YDazgLjErSfzmSAu EpBYsuc8M4QtKvHy8T+oS5UkVmy/xAhRnyzx//8vNoiZghInZz5hmcAoNAvJqFlIymYhKYOI 60gs2P2JDcLWlli28DUzjH3mwGOoXmuJ15NXsiKrWcDIsYpRsji1uDg33chQLzc9t0QvtSgz ubg4P0+vOHUTIzBmDm75rbGDsfua/SFGaQ4WJXHeqpmdQUIC6YklqdmpqQWpRfFFpTmpxYcY mTg4pRoYGeaHHu+7fbVeT+uX181er0UTlnAGqno98Joxm5cjS296nNibD69a2K9u/xr34cNc BSWHyEbW7n3VRx9uvDB7+zLZaoOsrt35bPqCUV6sWgtVI99Oz9jhvyt3/9Sprpw7j+00D1Jp U4hfxHv5aU0A/yL/vgt6X+Y/PrfraUJipVd/3o6Ob4GnlViKMxINtZiLihMBYvoToWcCAAA= Subject: [apps-discuss] Working Group Last Call: draft-ietf-appsawg-rrvs-header-field-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 19:49:13 -0000 --_000_D012CD2FB9E647319D462455FEF91A32ericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi there, this mail initiates an extended Working Group Last Call for draft-ietf-apps= awg-rrvs-header-field-05.txt , ending Friday, January 10, 2014. (here the link: http://www.ietf.org/id/draft-ietf-appsawg-rrvs-header-field= -05.txt ) Please submit substantive comments of support or other review feedback to a= pps-discuss@ietf.org , or privately to the authors or to appsawg-chairs@tools.ietf.org, prior to that date. We will need to see enough of these to be able to judge rough consensus of = the working group before it can be sent to our Area Directors to start the formal publication process. The document shepherd is welcome to post the writeup to the datatracker whe= never it's ready. thank you Salvatore --_000_D012CD2FB9E647319D462455FEF91A32ericssoncom_ Content-Type: text/html; charset="us-ascii" Content-ID: <882AC10BE71676468465D5FE20761563@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi there,

this mail initiates an extended Working Group Last Call for draft-ietf= -appsawg-rrvs-header-field-05.txt , ending Friday, January 10, 2014. 

Please submit substantive comments of support or other review feedback= to apps-di= scuss@ietf.org , 
or privately to the authors or to appsawg-chairs@tools.ietf.org, prio= r to that date. 

We will need to see enough of these to be able to judge rough consensu= s of the working group before it can be sent to our 
Area Directors to start the formal publication process.

The document shepherd is welcome to post the writeup to the datatracker whe= never it's ready.

thank you
Salvatore
--_000_D012CD2FB9E647319D462455FEF91A32ericssoncom_-- From superuser@gmail.com Fri Dec 13 12:15:10 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B1381AE056 for ; Fri, 13 Dec 2013 12:15:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sDoZSGAl_pTG for ; Fri, 13 Dec 2013 12:15:07 -0800 (PST) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 915041AE033 for ; Fri, 13 Dec 2013 12:15:06 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id w62so2407154wes.17 for ; Fri, 13 Dec 2013 12:14:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=i+ZfVM/0pzm6i5zgkhy6nJZbVQJikoa9WjbYNaQgmcA=; b=zeRvgH6aU7dB5gOf5o+9wmjFCA1u6atAtAZJ4d3rBMw/Bqxybnp8nMGyUN+prnsobV UQ+EA4Jyyo/0z4svNdw0FD7fHqkWRpR69cKkHhx9dmLSII+qnRz9rBdZBMnMm8RvLouL dXZ0cALyayArTX8hA5yDb7GgjF1U3AxlpuhuYrf6XU3r6mZGqO6QY9eWomQyyyulMLI3 fdwcgl1L2foMSz3RoRTeq0UxwZsv6xVY4hi+Vz6+QV3a2Lpykn4Neyo6hTxEQTUGP8I8 r1yJGSGFpuC9TIqNWtzRawerQfRR+VGUmf0NM123Rzzz+6z73xyAhI+6vqUjzfs537qL R6jQ== MIME-Version: 1.0 X-Received: by 10.180.187.72 with SMTP id fq8mr4395107wic.26.1386965699671; Fri, 13 Dec 2013 12:14:59 -0800 (PST) Received: by 10.180.84.106 with HTTP; Fri, 13 Dec 2013 12:14:59 -0800 (PST) Received: by 10.180.84.106 with HTTP; Fri, 13 Dec 2013 12:14:59 -0800 (PST) In-Reply-To: <1386960787.36390.YahooMailNeo@web125605.mail.ne1.yahoo.com> References: <20131211233924.25337.38138.idtracker@ietfa.amsl.com> <1386824613.80020.YahooMailNeo@web125606.mail.ne1.yahoo.com> <52AB39ED.9010604@gmail.com> <01P1WC4BWKYK0000AS@mauve.mrochek.com> <1386959497.44562.YahooMailNeo@web125602.mail.ne1.yahoo.com> <1386960787.36390.YahooMailNeo@web125605.mail.ne1.yahoo.com> Date: Fri, 13 Dec 2013 12:14:59 -0800 Message-ID: From: "Murray S. Kucherawy" To: William Mills Content-Type: multipart/alternative; boundary=001a11c2679cd841ce04ed701d00 Cc: Ned Freed , IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rrvs-header-field-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 20:15:10 -0000 --001a11c2679cd841ce04ed701d00 Content-Type: text/plain; charset=ISO-8859-1 Right, I'll remove that advice in the next version. Thanks! On Dec 13, 2013 10:53 AM, "Bill Mills" wrote: > We should say it should not be part of the DKIM signature. This makes > sense because we're saying the header is in fact ephemeral and for the use > of the mailers and not the end user or MUA. > > There's little impact of having it outside the DKIM signature. The only > thing I can think of is that if an MX is checking DKIM to decide if it will > honor RRVS then an attacker could probe account age if they could intercept > mail in transit. Not a big problem. > > -bill > > > -------------------------------- > William J. Mills > "Paranoid" Yahoo! > > > > On Friday, December 13, 2013 10:44 AM, Murray S. Kucherawy < > superuser@gmail.com> wrote: > There are two sides tugging at this in the document. We acknowledge > that DKIM signatures might be invalidated, but we also say that one way to > make sure the content of it can be trusted is to sign it. Also, the prose > of DKIM (for example) suggests that this isn't an appropriate header field > to sign in the first place because it's not part of the core message > content. > > I'm starting to think the text about signing the field as a way of proving > its authenticity might need to go. That way removal of the field doesn't > affect anything. Anyone else have a thought here? > > > On Fri, Dec 13, 2013 at 10:31 AM, Bill Mills wrote: > > This all generally looks sane and reasonable. > > One discussion point, I'm concerned if mailing lists are forced to modify > headers that it will maybe break DKIM or other signatures to I'd rather > leave that as a SHOULD. > > > > -bill > > > -------------------------------- > William J. Mills > "Paranoid" Yahoo! > > > > On Friday, December 13, 2013 10:27 AM, Murray S. Kucherawy < > superuser@gmail.com> wrote: > Thanks, Ned. That's all pretty minor stuff; no objections from me and > I'd wager the same from my co-author. Any objecting to dealing with this > all during or after WGLC? > > -MSK > > > On Fri, Dec 13, 2013 at 8:58 AM, Ned Freed wrote: > > I finally got a change to review this more carefully. My comments follow. > > The second point in section 5 should state explicitly that it is talking > about the case where the header field is present. As it stands it sounds > wierd, because the combination of the receiver implementing the extension > and the client not using the SMTP parameter doesn't imply that the > header(s) > will be present. > > I also think it would be clearer if the first paragraph of section 5 said > "implements this specification" rather than saying "implements the RRVS > SMTP extension". The former is more inclusive, and this section is > talking about header handling as well as how the extension works. > > Does the first point in section 5.1 regarding role accounts only apply to > local > role accounts? Or does this also mean that the RRVS parameter can be > dropped > from an address like postmaster@remote-domain? Whenever this sort of thing > comes up, My immediate inclination is always to say "No, you only look at > local > parts when you have authority over the domain." But this may be a bit > trickier > than it sounds, because what happens when an the next hop for > postmaster@remote-domain doesn't support the RRVS extension? > > OTOH, perhaps someone who uses a role account for ordering stuff from > Amazon > deserves what they get? > > Maybe I'm missing something, but the third point and the last paragraph > in section 5.1 seem to be saying more or less the same thing. > > I think some compliance language may be in order in section 9.1 - in > particular, that the extension MUST be dropped and the header MUST be > removed > by compliant mailing list expanders. > > Since we're defining an authentication-results field for this, I think it > would > be very helpful to have an example of its usage in section 13. > > Nits: > > There' a "that that" in the last paragraph of section 4. > > Alaises in misspelled in the title of section 9.2. > > That's it! > > Ned > _______________________________________________ > 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 > > > > > > --001a11c2679cd841ce04ed701d00 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Right, I'll remove that advice in the next version. Than= ks!

On Dec 13, 2013 10:53 AM, "Bill Mills"= <wmills@yahoo-inc.com> w= rote:
We should say it should not be part of the DKIM signatu= re.=A0 This makes sense because we're saying the header is in fact ephe= meral and for the use of the mailers and not the end user or MUA.

There's little impact of having it outside the DKIM signature.=A0 T= he only thing I can think of is that if an MX is checking DKIM to decide if= it will honor RRVS then an attacker could probe account age if they could = intercept mail in transit.=A0 Not a big problem.
=A0
-bill


--------------------------------
William J. Mills
"= ;Paranoid" Yahoo!



On Friday, December 13, 2013 10:44= AM, Murray S. Kucherawy <superuser@gmail.com> wrote:
There are two sides tugging at this in the document.= =A0 We acknowledge that DKIM signatures might be invalidated, but we also s= ay that one way to make sure the content of it can be trusted is to sign it= .=A0 Also, the prose of DKIM (for example) suggests that this isn't an = appropriate header field to sign in the first place because it's not pa= rt of the core message content.

I'm starting to think the text about signing t= he field as a way of proving its authenticity might need to go.=A0 That way= removal of the field doesn't affect anything.=A0 Anyone else have a th= ought here?


On Fri, Dec 13, = 2013 at 10:31 AM, Bill Mills <wmills@ya= hoo-inc.com> wrote:
This all generally looks sane and reasonable.=A0

One discussion point, I'm concerned if mailing lists are fo= rced to modify headers that it will maybe break DKIM or other signatures to= I'd rather leave that as a SHOULD.


=A0
-bill


<= div style=3D"font-style:normal;font-size:13px;background-color:transparent;= font-family:arial,helvetica,clean,sans-serif"> --------------------------------
William J. Mills
"Paranoid" Yahoo!



=
On Friday, December 13, 2013 10:27 AM, Murray S. Kucherawy <superuser@gmail.com> wrot= e:
= Thanks, Ned.=A0 That's all pretty minor stuff; no objections from me an= d I'd wager the same from my co-author.=A0 Any objecting to dealing wit= h this all during or after WGLC?

-MSK


On Fri, Dec 13, 2013 a= t 8:58 AM, Ned Freed <ned.freed@mroche= k.com> wrote:
I finally got a change to review this more carefully. My comments = follow.

The second point in section 5 should state explicitly that it is talking about the case where the header field is present. As it stands it sounds wierd, because the combination of the receiver implementing the extension and the client not using the SMTP parameter doesn't imply that the head= er(s)
will be present.

I also think it would be clearer if the first paragraph of section 5 said "implements this specification" rather than saying "implemen= ts the RRVS
SMTP extension". The former is more inclusive, and this section is
talking about header handling as well as how the extension works.

Does the first point in section 5.1 regarding role accounts only apply to l= ocal
role accounts? Or does this also mean that the RRVS parameter can be droppe= d
from an address like postmaster@remote-domain? Whenever this sort of thing<= br clear=3D"none"> comes up, My immediate inclination is always to say "No, you only look= at local
parts when you have authority over the domain." But this may be a bit = trickier
than it sounds, because what happens when an the next hop for
postmaster@remote-domain doesn't support the RRVS extension?

OTOH, perhaps someone who uses a role account for ordering stuff from Amazo= n
deserves what they get?

Maybe I'm missing something, but the third point and the last paragraph=
in section 5.1 seem to be saying more or less the same thing.

I think some compliance language may be in order in section 9.1 - in
particular, that the extension MUST be dropped and the header MUST be remov= ed
by compliant mailing list expanders.

Since we're defining an authentication-results field for this, I think = it would
be very helpful to have an example of its usage in section 13.

Nits:

There' a "that that" in the last paragraph of section 4.

Alaises in misspelled in the title of section 9.2.

That's it!

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

<= br clear=3D"none">
_______________________________________________
apps-discuss mailing list
a= pps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo= /apps-discuss





=
--001a11c2679cd841ce04ed701d00-- From kurta@drkurt.com Fri Dec 13 12:45:12 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 158231AE103 for ; Fri, 13 Dec 2013 12:45:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lfma6pgnhRfQ for ; Fri, 13 Dec 2013 12:45:10 -0800 (PST) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id CB1761AE028 for ; Fri, 13 Dec 2013 12:45:09 -0800 (PST) Received: by mail-wi0-f173.google.com with SMTP id hn9so1655952wib.12 for ; Fri, 13 Dec 2013 12:45:02 -0800 (PST) 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=3OSAyHVnFV2Ypw8heHmfE7GKSyv9fPfR0g7VrZxeA6w=; b=KW/4VUDeWJAw0B/ph6CyTyjz7rY/LpXraLmvCEKytWEPjeLHaqur5dRANQEWVAaiaw RPGcXMufweMjrWLRlE84GxfzWosV2HlZdW/5kNl9BJzKnM2VL3nvlnOf5JYdiAxbSQ9i tJPGrEFfqyV1yrwMYhqCJcTQ49VlkF2mX1OTI= 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=3OSAyHVnFV2Ypw8heHmfE7GKSyv9fPfR0g7VrZxeA6w=; b=JsITnXgUvGQ1Z4FhI8DBZt2nFabJu7xHcLj/3e0fVrTTUi4WbKIgzp5Osl3AumVZk2 DTY8QPVuIfyZ0BO+eIdT/cQkaJMKudRh2cM8h3adNTPwRzrjIEDFMFYYmvQGGJa/mZSa gyn1wz1GfUwze/B8q9DUt2axwpHStgglzhKY4ecPySvay9rTNY8b/fP9XQxZXBp5VnME 3ENy2njDEsNyhchk3ruoifV1g4zsV+qWLhwM69GVmK9r/5VanqE/tjUB423W9gnHoYFv ES49ifLdPcZyhvo4bOmEDIJW1EHxjXa/SxYOMPAppyCP2fC1n2W/pSmac09GSAErB7fZ iojw== X-Gm-Message-State: ALoCoQla+6OHkSzCPmFEboi3BRxuAw6D5xsHRK7oclCm+cqF1HIaR4JlNfxcllY19zSC/FwfBz1t MIME-Version: 1.0 X-Received: by 10.180.183.72 with SMTP id ek8mr3964445wic.31.1386967499436; Fri, 13 Dec 2013 12:44:59 -0800 (PST) Sender: kurta@drkurt.com Received: by 10.194.152.68 with HTTP; Fri, 13 Dec 2013 12:44:59 -0800 (PST) In-Reply-To: References: <20131211233924.25337.38138.idtracker@ietfa.amsl.com> <1386824613.80020.YahooMailNeo@web125606.mail.ne1.yahoo.com> <52AB39ED.9010604@gmail.com> <01P1WC4BWKYK0000AS@mauve.mrochek.com> <1386959497.44562.YahooMailNeo@web125602.mail.ne1.yahoo.com> <1386960787.36390.YahooMailNeo@web125605.mail.ne1.yahoo.com> Date: Fri, 13 Dec 2013 12:44:59 -0800 X-Google-Sender-Auth: xwrw3PjGsLyBMn4fHYmoHt5GXSQ Message-ID: From: Kurt Andersen To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Cc: Ned Freed , IETF Apps Discuss Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rrvs-header-field-05.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 20:45:12 -0000 On Fri, Dec 13, 2013 at 12:14 PM, Murray S. Kucherawy wrote: > Right, I'll remove that advice in the next version. Thanks! > > On Dec 13, 2013 10:53 AM, "Bill Mills" wrote: >> >> We should say it should not be part of the DKIM signature. I'd be inclined to agree with Bill: "We should say it should not be part of the DKIM signature." which is a stronger position than just removing any references to it. --Kurt From masinter@adobe.com Fri Dec 13 14:10:41 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AACA51AE3AB for ; Fri, 13 Dec 2013 14:10:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zThTFcGUCpKy for ; Fri, 13 Dec 2013 14:10:34 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0235.outbound.protection.outlook.com [207.46.163.235]) by ietfa.amsl.com (Postfix) with ESMTP id 4ADC11AE332 for ; Fri, 13 Dec 2013 14:10:34 -0800 (PST) Received: from BL2PR02MB307.namprd02.prod.outlook.com (10.141.91.21) by BL2PR02MB305.namprd02.prod.outlook.com (10.141.91.17) with Microsoft SMTP Server (TLS) id 15.0.842.7; Fri, 13 Dec 2013 22:10:26 +0000 Received: from BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) by BL2PR02MB307.namprd02.prod.outlook.com ([10.141.91.21]) with mapi id 15.00.0842.003; Fri, 13 Dec 2013 22:10:26 +0000 From: Larry Masinter To: "Murray S. Kucherawy" , IETF Apps Discuss Thread-Topic: Unicode BOM detection in JSON vs. draft-ietf-appsawg-xml-mediatypes Thread-Index: Ac74NOKBpqplsu+tTnu24kjteTdrPg== Date: Fri, 13 Dec 2013 22:10:25 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.184.24.49] x-forefront-prvs: 00594E8DBA x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(189002)(199002)(74706001)(31966008)(76786001)(76176001)(47446002)(74502001)(76796001)(76576001)(81342001)(81542001)(74662001)(16236675002)(74876001)(19300405004)(15202345003)(74316001)(69226001)(79102001)(85852003)(90146001)(63696002)(2656002)(56816005)(66066001)(15975445006)(4396001)(83072002)(80022001)(87266001)(83322001)(19609705001)(65816001)(53806001)(51856001)(47976001)(46102001)(59766001)(49866001)(47736001)(76482001)(56776001)(50986001)(85306002)(33646001)(16601075003)(19580395003)(74366001)(54316002)(54356001)(80976001)(81686001)(81816001)(77982001)(87936001)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR02MB305; H:BL2PR02MB307.namprd02.prod.outlook.com; CLIP:50.184.24.49; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_f3b9264de84c4fa4a4718727fe7d614fBL2PR02MB307namprd02pro_" MIME-Version: 1.0 X-OriginatorOrg: adobe.com Subject: [apps-discuss] Unicode BOM detection in JSON vs. draft-ietf-appsawg-xml-mediatypes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 22:10:41 -0000 --_000_f3b9264de84c4fa4a4718727fe7d614fBL2PR02MB307namprd02pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Compare http://tools.ietf.org/html/draft-ietf-json-rfc4627bis-09#section-= 8.1 and http://tools.ietf.org/html/draft-ietf-appsawg-xml-mediatypes-06#sectio= n-3 it's hard to tell exactly what either is saying, much less whether they're = saying the same thing. I don't want to slow down either of these, but some work = on a model for how MIME types should deal with the relationship between - Charset parameter in content-type - Possible BOM maker - Other in-content character set indication (like in XML) - Other protocol sources of charset information JSON, XML, HTML, IRIs, elements based on those, and likely many other protocol elements are defined using BNF or other syntactic description techniques over the space of sequence-of-Unicode-characters (sequence-of-Unicode-code-point). Has there been any attempts to create a separate BCP that JSON and XML Could (in the future) reference? The JSON working group spent only a few thousand emails on this. Larry -- http://larry.masinter.net --_000_f3b9264de84c4fa4a4718727fe7d614fBL2PR02MB307namprd02pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Compare   http://tools.ietf.org/html/draft-ietf-json-rfc4627bis-09#section-8.1<= /a>

and  http://tools.ietf.org/html/draft-ietf-appsawg-xml-mediatypes-06#section-3

 <= /p>

it’s hard to tell e= xactly what either is saying, much less whether they’re saying

the same thing.  &nb= sp;I don’t want to slow down either of these, but some work on

a model for how MIME type= s should deal with the relationship between

 <= /p>

- =          Charset parameter= in content-type

- =          Possible BOM make= r

- =          Other in-content = character set indication (like in XML)

- =          Other protocol so= urces of charset information

 <= /p>

JSON, XML, HTML, IRIs, el= ements based on those, and likely many other

protocol elements are def= ined using BNF or other syntactic description

techniques over the space= of sequence-of-Unicode-characters

(sequence-of-Unicode-code= -point).

 <= /p>

Has there been any attemp= ts to create a separate BCP that JSON and XML

Could (in the future) ref= erence? The JSON working group spent only

a few thousand emails on = this.

 <= /p>

Larry

--

http://larry.masinter.net

 <= /p>

 <= /p>

--_000_f3b9264de84c4fa4a4718727fe7d614fBL2PR02MB307namprd02pro_-- From superuser@gmail.com Fri Dec 13 14:15:16 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B61691AE423 for ; Fri, 13 Dec 2013 14:15:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5_sZ5ZCbKdXc for ; Fri, 13 Dec 2013 14:15:15 -0800 (PST) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id 214041AE416 for ; Fri, 13 Dec 2013 14:15:14 -0800 (PST) Received: by mail-wi0-f176.google.com with SMTP id hq4so1744785wib.3 for ; Fri, 13 Dec 2013 14:15:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=65Hp6wTBdS003BEyTVAW9YL+4ug5QyKQ+y9CYh9OFmI=; b=u0fxC78CdAYzxL3Xae+iJuPruBTXRFxSXNKvLa5kzBdmRAA5YeWsqCPq0WnX7YJM7E AEa3Rq17HidFac2nUBxJUls6TSSnmZoShTTsJFX3EjaGivS1j1Yb2hEYrQjzMbXtynuE HpzilC6DeJppR+6t/fjmV3oYJe7aBfWOMqQTcWm1KhPoQzoiMrsym9VV2MjDRZTVScP5 Oq6WJJYT2PzuVyZmxERqb7DctwBfwJ2Vd45r/aj8VQXfcHNSuC4Tn5zF1Tt1enkJ2dwD m3i3OZHkV7kd8gJiI1NZsqD6noaLhwZrkwNQgv8E+QBI7z0M51Am5DUi6R3U4n3jGLQE yh2g== MIME-Version: 1.0 X-Received: by 10.194.108.100 with SMTP id hj4mr1518934wjb.83.1386972908267; Fri, 13 Dec 2013 14:15:08 -0800 (PST) Received: by 10.180.84.106 with HTTP; Fri, 13 Dec 2013 14:15:07 -0800 (PST) In-Reply-To: References: Date: Fri, 13 Dec 2013 14:15:07 -0800 Message-ID: From: "Murray S. Kucherawy" To: Larry Masinter Content-Type: multipart/alternative; boundary=047d7bf109fe82af9a04ed71cb96 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Unicode BOM detection in JSON vs. draft-ietf-appsawg-xml-mediatypes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 22:15:16 -0000 --047d7bf109fe82af9a04ed71cb96 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Dec 13, 2013 at 2:10 PM, Larry Masinter wrote: > > > Has there been any attempts to create a separate BCP that JSON and XML > > Could (in the future) reference? The JSON working group spent only > > a few thousand emails on this. > > > > Not in APPSAWG, but it sounds like the JSON WG has already spent a lot of time on it; perhaps they're in a better position to do so? If not, the usual points apply: 1) Is this work APPSAWG should take on? Who will provide reviews? Who will contribute text? 2) We need to get some other stuff moved onward before we can take on new work. -MSK --047d7bf109fe82af9a04ed71cb96 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Dec 13, 2013 at 2:10 PM, Larry Masinter <masint= er@adobe.com> wrote:
=A0

Has there been any attemp= ts to create a separate BCP that JSON and XML

Could (in the future) ref= erence? The JSON working group spent only

a few thousand emails on = this.

=A0<= /p>


Not in APPSAWG, but it = sounds like the JSON WG has already spent a lot of time on it; perhaps they= 're in a better position to do so?

If not, the usual points apply:

1) Is this= work APPSAWG should take on?=A0 Who will provide reviews?=A0 Who will cont= ribute text?

2) We need to get some other stuff moved onw= ard before we can take on new work.

-MSK
--047d7bf109fe82af9a04ed71cb96-- From tbray@textuality.com Fri Dec 13 14:20:42 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 626FE1AE082 for ; Fri, 13 Dec 2013 14:20:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.478 X-Spam-Level: X-Spam-Status: No, score=0.478 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0L_UIxXosqZL for ; Fri, 13 Dec 2013 14:20:40 -0800 (PST) Received: from mail-vc0-f170.google.com (mail-vc0-f170.google.com [209.85.220.170]) by ietfa.amsl.com (Postfix) with ESMTP id 90EE21ADF8B for ; Fri, 13 Dec 2013 14:20:40 -0800 (PST) Received: by mail-vc0-f170.google.com with SMTP id la4so1767241vcb.1 for ; Fri, 13 Dec 2013 14:20:33 -0800 (PST) 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=LAwCZAw0GbGPbTrbSuh0IsRdBuWVVlMpbXpSpy5Jo6s=; b=Vkm3GBxtMM9pKdWFQOnTTpz4sKXJlR5CviAn6n3O0ZGZDFYebjextz6yiROBEkZ88h sf31SMhijPo7ypvqSrhaOcP55BwQWKOR9L/kTfSeNhqMx2aJlBYE249ZQXEnrUdMHCD8 U0hrso25o1ObPZP9kzLdHF+NcFNftTC9O+1pgUYA2O3gXWssv5sJtxHCPBrDTVP23ZXY BPugcEzJOKDDWAO6pQz6ddTc1LDbubp3eFCQd2ZorNYkH47N1Y9kEYf1YpwCn0l+xIzy 4Rs8DQodAao8Jev/1HEN81HRuJBVxgly+4ZYyCGwJsHsQvJWvCYP/nFPdM3Uf9x1OHYe vg4Q== X-Gm-Message-State: ALoCoQkpMLBOQSQh2prac9k/6d5VWqHEPEmhoGf674pcilrBphNX5xS/BVx5fGJacddwRVumzph1 MIME-Version: 1.0 X-Received: by 10.52.157.1 with SMTP id wi1mr1882910vdb.12.1386973233784; Fri, 13 Dec 2013 14:20:33 -0800 (PST) Received: by 10.220.198.199 with HTTP; Fri, 13 Dec 2013 14:20:33 -0800 (PST) X-Originating-IP: [96.49.81.176] In-Reply-To: References: Date: Fri, 13 Dec 2013 14:20:33 -0800 Message-ID: From: Tim Bray To: Larry Masinter Content-Type: multipart/alternative; boundary=089e0160bd3ae9cbbd04ed71ded6 Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Unicode BOM detection in JSON vs. draft-ietf-appsawg-xml-mediatypes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 22:20:42 -0000 --089e0160bd3ae9cbbd04ed71ded6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I actually think 4627bis is perfectly clear. You can use UTF-{8/16/32} in theory; in practice only UTF-8 works over the wire; you MUST NOT emit a BOM but if some dork does, it=E2=80=99s OK to forgive. There=E2=80=99s no chars= et parameter on the media type. If we were doing XML in 2013, I think we=E2=80=99d probably end up at the s= ame place. Note that the original XML spec was written in ISO-8859-1 :) On Fri, Dec 13, 2013 at 2:10 PM, Larry Masinter wrote: > Compare > http://tools.ietf.org/html/draft-ietf-json-rfc4627bis-09#section-8.1 > > and > http://tools.ietf.org/html/draft-ietf-appsawg-xml-mediatypes-06#section-3 > > > > it=E2=80=99s hard to tell exactly what either is saying, much less whethe= r they=E2=80=99re > saying > > the same thing. I don=E2=80=99t want to slow down either of these, but = some work > on > > a model for how MIME types should deal with the relationship between > > > > - Charset parameter in content-type > > - Possible BOM maker > > - Other in-content character set indication (like in XML) > > - Other protocol sources of charset information > > > > JSON, XML, HTML, IRIs, elements based on those, and likely many other > > protocol elements are defined using BNF or other syntactic description > > techniques over the space of sequence-of-Unicode-characters > > (sequence-of-Unicode-code-point). > > > > Has there been any attempts to create a separate BCP that JSON and XML > > Could (in the future) reference? The JSON working group spent only > > a few thousand emails on this. > > > > Larry > > -- > > http://larry.masinter.net > > > > > --089e0160bd3ae9cbbd04ed71ded6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I actually think 4627bis is perfectly clear. You can use U= TF-{8/16/32} in theory; in practice only UTF-8 works over the wire; you MUS= T NOT emit a BOM but if some dork does, it=E2=80=99s OK to forgive. There= =E2=80=99s no charset parameter on the media type.

If we were doing XML in 2013, I think we=E2=80=99d probably = end up at the same place. Note that the original XML spec was written in IS= O-8859-1 :)


On Fri, Dec 13, 2013 at 2:10 PM, Larry Masinter <masinter@adobe.com&g= t; wrote:

Compare=C2=A0=C2=A0 http://tools.ietf.org/html/draft-ietf-json-rfc4627b= is-09#section-8.1

and=C2=A0 http://tools.ietf.org/html/draft-ietf-appsawg-xml-mediatypes-06#section-3

=C2=A0

it=E2=80=99s hard to tell= exactly what either is saying, much less whether they=E2=80=99re saying=

the same thing. =C2=A0=C2= =A0I don=E2=80=99t want to slow down either of these, but some work on

a model for how MIME type= s should deal with the relationship between

=C2=A0

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Charset parameter in= content-type

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Possible BOM maker

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Other in-content cha= racter set indication (like in XML)

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Other protocol sourc= es of charset information

=C2=A0

JSON, XML, HTML, IRIs, el= ements based on those, and likely many other

protocol elements are def= ined using BNF or other syntactic description

techniques over the space= of sequence-of-Unicode-characters

(sequence-of-Unicode-code= -point).

=C2=A0

Has there been any attemp= ts to create a separate BCP that JSON and XML

Could (in the future) ref= erence? The JSON working group spent only

a few thousand emails on = this.

=C2=A0

Larry

--

http://larry.masinter.net<= /span>

=C2=A0

=C2=A0


--089e0160bd3ae9cbbd04ed71ded6-- From stpeter@stpeter.im Fri Dec 13 14:47:20 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD2D61AE448; Fri, 13 Dec 2013 14:47:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.196 X-Spam-Level: * X-Spam-Status: No, score=1.196 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_34=0.6, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rijBw6ZfBwTK; Fri, 13 Dec 2013 14:47:16 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id A022D1AE44F; Fri, 13 Dec 2013 14:47:14 -0800 (PST) Received: from ergon.local (unknown [64.101.72.104]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7DA3E4010C; Fri, 13 Dec 2013 15:47:06 -0700 (MST) Message-ID: <52AB8E69.7070906@stpeter.im> Date: Fri, 13 Dec 2013 15:47:05 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: dcrocker@bbiw.net, Apps Discuss , draft-ietf-stox-presence.all@tools.ietf.org, stox@ietf.org References: <52A94AF6.8090702@dcrocker.net> In-Reply-To: <52A94AF6.8090702@dcrocker.net> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: iesg Subject: Re: [apps-discuss] [Stox] Review of: draft-ietf-stox-presence-06 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Dec 2013 22:47:21 -0000 Hi Dave, thank you for the review. Comments inline. I have not yet proposed text for the issues you raise, because that will take more time. On 12/11/13 10:34 PM, Dave Crocker wrote: > > G'day. > > I have been selected as the Applications Area Review Team reviewer for > this draft (for background on apps-review, please see > http://www.apps.ietf.org/content/applications-area-review-team). > 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. > > > > Review of: Interworking between the Session Initiation Protocol (SIP) > and the > Extensible Messaging and Presence Protocol (XMPP): Presence > I-D: draft-ietf-stox-presence-06 > > Reviewer: D. Crocker > Review date: 12 Dec 13 > > > > Summary: > > XMPP and SIP both have deployed versions of instant messaging and > presence. The current draft is part of a set of specifications that > define a gateway capability between the the two services. In > particular, the current draft specifies the translation mechanism > between the presence mechanisms used by SIP and XMPP. > > The draft is well-structured and the text is mostly clear. For an > implementer already familiar with the details of the two services and > the basics of the gatewaying specified here, the document probably is > sufficient -- although responses to some of the detailed comments, > below, might to turn out to show that a bit more work is needed. However > at the most, any technical improvements that might be needed will be > minor. And I expect these to more in the nature of clarifying language > than of changing bits over the wire. > > However for a reader who is new to the topic, the document needs to be > clearer and sometimes more complete. > > Specific changes or concerns: > > 1. When citing the earlier efforts, there should be something to > explain why the current work is expected to be more successful. Not "expected", but "is". :-) AFAIK there are no implementations of the approach taken by RFC 3922 and draft-ietf-simple-cpim-mapping (i.e., mapping to the abstract semantics of RFC 3860), whereas there are multiple implementations of the approach described here (i.e., direct mapping between SIP and XMPP). > That is, > what makes the current approach notably tractable for implementation and > deployment? Do you think that explaining why would improve the document? IMHO this verges into developer psychology (I've got this SIP thing here and this XMPP thing there, let me see how I can make them work as easily as possible without venturing off into abstract semantic stuff). > 2. The document is not clear about the prerequisites for reading > this draft. What must the reader already know in depth? What must they > have at least superficial knowledge of? I suspect that, in particular, > they need deep familiarity with stox-core. At the very least. Also RFC 3261, RFC 3856, RFC 6120, and RFC 6121. (Note: the total page count of those RFCs is 621.) The specifications normatively referenced by RFC 3856 are also relevant. > 3. Saying that terms are taken from a substantial number of other > documents, and then merely citing the documents in their entirety, is > not helpful to the reader, unless the reader is required to be deeply > familiar with those documents. I do think it's required. > If that's what this document requires, > say that. If it's not, I suggest listing terms explicitly and > indicating what document they are drawn from. > > 4. As the architecture diagram in Section 3 of stox-core shows, this > service has at least separate actors Actually I think it actually has at > least 6, which that diagram probably should show explicitly. The six are: > > a. SIP user > b. SIP server > c. SIP-XMPP gateway > d. XMPP-SIP gateway > e. XMPP server > f. XMPP user > > In any event, the specification needs to be very diligent to > carefully identify each actor involved in an activity and the > interaction between actors. The current document uses language that > often left me wondering such things as who was the target of the action. > > Much of this would be aided by some form of protocol sequence > diagrams, to show who does what and in what order. I'll review the document again with these comments in mind. Your suggestion of sequence diagrams is a good one. > 5. When showing protocol examples, usually only one side of the > sequence is shown. For gatewaying that does interesting transforms, > such as this one, an example should show both the before and after > versions. That is, the 'native' protocol unit that was created and then > the one that results from the translation. I thought we'd already done that. For instance, Example 2 is the SIP transformation of the XMPP stanza shown in Example 1. > Detailed Comments: > > >> Table of Contents > > > Nicely organized and concise TOC [ie, document structure). > > > >> 1. Introduction > ... >> One approach to helping ensure interworking between these protocols >> is to map each protocol to the abstract semantics described in >> [RFC3860]; that is the approach taken by both [RFC3922] and >> [I-D.ietf-simple-cpim-mapping]. The approach taken in this document >> is to directly map semantics from one protocol to another (i.e., from >> SIP/SIMPLE to XMPP and vice-versa). > > This begs the obvious question: Why? What was wrong with the previous > approach? No one implemented it. The running code all takes the direct gatewaying approach. > The purpose of the question is not for criticizing prior work but to > understand the expected benefit of the approach taken in the current > work. What are the function, or OA&M differences produced through this > new approach, that are expected to be helpful? These documents describe what people do in the field, what works and what doesn't, etc. We're not saying that other approaches are bad or infeasible. >> The architectural assumptions underlying such direct mappings are >> provided in [I-D.ietf-stox-core], including mapping of addresses and >> error conditions. The mappings specified in this document cover >> basic presence functionality. Mapping of more advanced functionality >> (e.g., so-called "rich presence") is out of scope for this document. >> >> SIP and XMPP differ significantly in their presence subscription >> models, since SIP subscriptions are short-lived (requiring relatively >> frequent refreshes even during a presence session) whereas XMPP >> subscriptions last across presence sessions until they are explicitly >> cancelled. This document provides suggestions for bridging the gap >> between these very different models. >> >> >> 2. Terminology >> >> A number of terms used here are explained in [RFC3261], [RFC3856], >> [RFC6120], and [RFC6121]. > > This sentence probably implies that the current draft should not be read > in the absence of familiarity with all 4 of those RFCs. I suggest some > sort of explicit statement about how much prior knowledge is needed for > understanding the current draft, and where to get that knowledge. Agreed. > In purely mechanical terms, the problem with the above sentence is that > it means that when the reader sees a term they don't understand, they > have to run around to four different documents looking for definitions. > This mostly ensures reader frustration, for everyone but experts. > > The cleanest fix for this is to list terms and where they are defined. > The other, usual fix is to indeed say that the reader must be familiar > with those other documents before reading this one. (sigh.) I think these documents are for experts. In all likelihood, members of the target audience already have a SIP implementation and need to connect it to the XMPP network, or vice-versa. I don't think someone who is not familiar with either SIP or XMPP (or both) is going to hack up a gateway. There are much more rewarding tasks one might choose. To your point, we need to say that. >> 3.1. Overview > ... >> As described in [RFC6121], XMPP presence subscriptions are managed >> using XMPP presence stanzas of type "subscribe", "subscribed", >> "unsubscribe", and "unsubscribed". The main subscription states are >> "none" (neither the user nor the contact is subscribed to the other's >> presence information), "from" (the user has a subscription from the >> contact), "to" (the user has a subscription to the contact's presence >> information), and "both" (both user and contact are subscribed to >> each other's presence information). > > Nit: for technical documents, lists like the above should be shown in > list format. It really does help for quick comprehension. Will fix. >> As described in [RFC3856], SIP presence subscriptions are managed >> through the use of SIP SUBSCRIBE events sent from a SIP user agent to >> an intended recipient who is most generally referenced by a Presence >> URI of the form but who might be referenced by a >> SIP or SIPS URI of the form or . >> >> The subscription models underlying XMPP and SIP are quite different. >> For instance, XMPP presence subscriptions are long-lived (indeed >> permanent if not explicitly cancelled), whereas SIP presence >> subscriptions are short-lived (the default time-to-live of a SIP >> presence subscription is 3600 seconds, as specified in Section 6.4 of >> [RFC3856]). These differences are addressed below. > > The text that follows this 'addresses' the differences in terms of > specifying how to handle specific differences. > > What's missing -- but I think would aid for the framework of this > document's effort -- is for the above "For instance" to instead be > expanded into a detailed statement of what the differences are, separate > from the later text that says how to deal with the differences. That "for instance" is the main thing, so you're right that it needs to be described in more detail. > Someone needing to implement this spec, probably will be starting with a > reasonable model of one side -- or at least, reasonable knowledge of the > details, if not a thoughtful, higher-level model -- and considerable > ignorance of the other. Text that discusses details of differences, > distinct from how to resolve them, will put the implementer into a > better position of understanding what's being done. > > This probably raises a larger issue: How much expertise is expected of > someone who is implementing this or otherwise reading for deep > comprehension? In the extreme, they will need to have serious expertise > on both protocol sets. The other extreme would be a cookbook inside > this document, with no outside knowledge required. The document needs > to specify the nature and extent of the expertise required. (In fact, > the document seems pretty clean, in terms of explaining things, so I > suspect that 'fair' knowledge of one suite will suffice. But the author > and wg beliefs about the requirement should be made explicit.) See above. Perhaps not expert level, but significant familiarity with one "side" or the other. >> 3.2. XMPP to SIP >> >> 3.2.1. Establishing a Presence Subscription >> >> An XMPP user (e.g., juliet@example.com) initiates a subscription by >> sending a subscription request to another entity (e.g., >> romeo@example.net), and the other entity (conventionally called a > > Move definition of contact up to first occurrence, above. Yes. >> "contact") either accepts or declines the request. If the contact >> accepts the request, the user will have a subscription to the >> contact's presence information until (1) the user unsubscribes or (2) >> the contact cancels the subscription. The subscription request is >> encapsulated in a presence stanza of type "subscribe": >> >> >> >> >> Saint-Andre, et al. Expires April 21, 2014 [Page 4] >> >> Internet-Draft SIP-XMPP Interworking: Presence October 2013 >> >> >> Example 1: XMPP user subscribes to SIP contact: >> >> | > | to='romeo@example.net' >> | type='subscribe'/> >> >> Upon receiving such a presence stanza, the XMPP server to which >> Juliet has connected needs to determine the identity of the >> domainpart in the 'to' address, which it does by following the >> procedures discussed in [I-D.ietf-stox-core]. Here we assume that > > Unfortunately, given the context of a citation like this, it really > needs much greater precision, to point the reader to the exact portion > of the document that is relevant to this context. Agreed. > Unless, of course, the premise of the current document is that the > reader must be deeply familiar with the -core document. In which case, > /that's/ what should be specified early in this document. Based on what > follows, I fear that indeed, this document requires deep familiarity > with -core. I definitely think that's so. All of the STOX WG documents build upon the framework described in draft-ietf-stox-core. >> the XMPP server has determined the domain is serviced by a SIMPLE >> server, that it contains or has available to it an XMPP-SIMPLE >> gateway or connection manager (which enables it to speak natively to >> SIMPLE servers), and that it hands off the presence stanza to the >> XMPP-SIMPLE gateway. >> >> The XMPP-SIMPLE gateway is then responsible for translating the XMPP >> subscription request into a SIP SUBSCRIBE request from the XMPP user >> to the SIP user: >> >> Example 2: XMPP user subscribes to SIP contact (SIP transformation): > > It took a moment to decide whether I was looking at XMPP form or SIP > form. Perhaps a more helpufl title for the example would be something > like: > > Example 2: Translation of XMPP user's subscription request into SIP Yes, that's better. >> | SUBSCRIBE sip:romeo@example.net SIP/2.0 > > Later text (section 4.1) equates the label pres: with sip: and sips:. > Why choose sip: here? In practice, we don't see 'pres' URIs in the wild. >> | Via: SIP/2.0/TCP x2s.example.com;branch=z9hG4bKna998sk >> | From: ;tag=ffd2 >> | Call-ID: 5BCF940D-793D-43F8-8972-218F7F4EAA8C >> | Event: presence >> | Max-Forwards: 70 >> | CSeq: 123 SUBSCRIBE >> | Contact: >> | Accept: application/pidf+xml >> | Expires: 3600 >> | Content-Length: 0 >> >> The SIP user then SHOULD send a response indicating acceptance of the >> subscription request: >> >> Example 3: SIP accepts subscription request: >> >> | SIP/2.0 200 OK >> | Via: SIP/2.0/TCP s2x.example.net;branch=z9hG4bKna998sk >> | From: ;tag=ffd2 >> | To: ;tag=j89d >> | Call-ID: 5BCF940D-793D-43F8-8972-218F7F4EAA8C >> | CSeq: 234 SUBSCRIBE >> | Contact: >> | Expires: 3600 >> | Content-Length: 0 > > Hmmm. This appears to be the original SIP acceptance, but with no > separate display of it's being translated into XMPP. That is Example 5. >> Saint-Andre, et al. Expires April 21, 2014 [Page 5] >> >> Internet-Draft SIP-XMPP Interworking: Presence October 2013 >> >> >> In accordance with [RFC6665], the XMPP-SIMPLE gateway SHOULD consider >> the subscription state to be "neutral" until it receives a NOTIFY >> message. Therefore the SIP user or SIP-XMPP gateway at the SIP >> user's domain SHOULD immediately send a NOTIFY message containing a >> "Subscription-State" header whose value contains the string "active" >> (see Section 4). >> >> Example 4: SIP user sends presence notification: >> >> | NOTIFY sip:192.0.2.1 SIP/2.0 >> | Via: SIP/2.0/TCP simple.example.net;branch=z9hG4bKna998sk >> | From: ;tag=yt66 >> | To: ;tag=bi54 >> | Call-ID: 5BCF940D-793D-43F8-8972-218F7F4EAA8C >> | Event: presence >> | Subscription-State: active;expires=499 >> | Max-Forwards: 70 >> | CSeq: 8775 NOTIFY >> | Contact: >> | Content-Type: application/pidf+xml >> | Content-Length: 193 >> | >> | >> | > | entity='pres:romeo@example.net'> >> | >> | >> | open >> | away >> | >> | >> | > > Where is the xmpp translation of this? That is Example 6. >> In response, the SIMPLE-XMPP gateway would send a 200 OK (not shown > > Sent it to whom? (I probably know the answer, but the reader shouldn't > have to guess; this is a spec.) The gateways sends it to the SIP user agent. Will clarify. >> here since it is not translated into an XMPP stanza). >> >> Upon receiving the first NOTIFY with a subscription state of active, >> the XMPP-SIMPLE gateway MUST generate a presence stanza of type >> "subscribed": >> >> Example 5: XMPP user receives acknowledgement from SIP contact: >> >> | > | to='juliet@example.com' >> | type='subscribed'/> >> >> As described under Section 4, the gateway MUST also generate a >> presence notification to the XMPP user: >> >> >> Saint-Andre, et al. Expires April 21, 2014 [Page 6] >> >> Internet-Draft SIP-XMPP Interworking: Presence October 2013 >> >> >> Example 6: XMPP user receives presence notification from SIP contact: >> >> | > | to='juliet@example.com'/> > > > This sequence feels like it should have a protocol sequence diagram, of > the type used in rfc5263. Yes, some "swim lanes" are in order here and throughout. >> 3.2.3. Cancelling a Presence Subscription >> >> At any time after subscribing, the XMPP user can unsubscribe from the >> contact's presence. This is done by sending a presence stanza of >> type "unsubscribe": >> >> Example 7: XMPP user unsubscribes from SIP contact: >> >> | > | to='romeo@example.net' >> | type='unsubscribe'/> >> >> The XMPP-SIMPLE gateway is responsible for translating the >> unsubscribe command into a SIP SUBSCRIBE request with the "Expires" >> header set to a value of zero: >> >> Example 8: XMPP user unsubscribes from SIP contact (SIP >> transformation): >> >> | SUBSCRIBE sip:romeo@example.net SIP/2.0 >> | Via: SIP/2.0/TCP s2x.example.net;branch=z9hG4bKna998sk >> | From: ;tag=j89d >> | Call-ID: 9D9F00DF-FCA9-4E7E-B970-80B638D5218A >> | Event: presence >> | Max-Forwards: 70 >> | CSeq: 789 SUBSCRIBE >> | Contact: >> | Accept: application/pidf+xml >> | Expires: 0 >> | Content-Length: 0 >> >> >> >> Saint-Andre, et al. Expires April 21, 2014 [Page 7] >> >> Internet-Draft SIP-XMPP Interworking: Presence October 2013 >> >> >> Upon sending the transformed unsubscribe, the XMPP-SIMPLE gateway >> SHOULD send a presence stanza of type "unsubscribed" to the XMPP >> user: >> >> Example 9: XMPP user receives unsubscribed notification: >> >> | > | to='juliet@example.com' >> | type='unsubscribed'/> > > > One of the advantages of showing sequences like these in a protocol > sequence diagram is that it concisely shows which of the 4 actors does > what and when. Being able to see visual summaries like that will make > the life of an implementer /much/ easier. Agreed. >> 3.3. SIP to XMPP >> >> 3.3.1. Establishing a Presence Subscription >> >> A SIP user initiates a subscription to a contact's presence >> information by sending a SIP SUBSCRIBE request to the contact. The >> following is an example of such a request: >> >> Example 10: SIP user subscribes to XMPP contact: >> >> | SUBSCRIBE sip:juliet@example.com SIP/2.0 >> | Via: SIP/2.0/TCP s2x.example.net;branch=z9hG4bKna998sk >> | From: ;tag=xfg9 >> | Call-ID: AA5A8BE5-CBB7-42B9-8181-6230012B1E11 >> | Event: presence >> | Max-Forwards: 70 >> | CSeq: 263 SUBSCRIBE >> | Contact: >> | Accept: application/pidf+xml >> | Content-Length: 0 >> >> Notice that the "Expires" header was not included in the SUBSCRIBE >> request; this means that the default value of 3600 (i.e., 3600 >> seconds = 1 hour) applies. >> >> Upon receiving the SUBSCRIBE, the SIP server needs to determine the >> identity of the domain portion of the Request-URI or To header, which >> it does by following the procedures discussed in >> [I-D.ietf-stox-core]. Here we assume that the SIP server has >> determined that the domain is serviced by an XMPP server, that it > > > This seems to mean that a regular SIP server needs to be familiar with > technical details in a gatewaying specification?? Well, it is (IMHO) really the responsibility of a core "server" to implement this kind of routing functionality, but the "gateway" might make the determination that the remote domain uses SIP or XMPP and if SIP then pass it on to the SIP "server" and if not handle delivery to the remote XMPP domain. To some extent it's a matter of implementation where exactly the code lives to complete these functions, which is why draft-ietf-stox-core talks about a "SIP service" consisting of both a SIP "server" and a "gateway". In XMPP this translation function is often handled by what we call a "connection manager", but that depends a bit on the internal architecture of the overall "service". >> Example 11: SIP user subscribes to XMPP contact (XMPP >> transformation): >> >> | > | to='juliet@example.com' >> | type='subscribe'/> >> >> In accordance with [RFC6121], the XMPP user's server MUST deliver the >> presence subscription request to the XMPP user (or, if a subscription >> already exists in the XMPP user's roster, send a presence stanza of >> type 'subscribed'). >> >> If the XMPP user approves the subscription request, the XMPP server >> then MUST return a presence stanza of type "subscribed" from the XMPP >> user to the SIP user; if a subscription already exists, the XMPP > > The XMPP server does not communicate (directly) with the SIP user. It > has to go through one or both gateways. (From the architectural > diagram, I assume the sequence is through both.) This spec needs to be > very careful to identify what entity is talking with what entity > directly and who is mediating, when it isn't direct. Yes, we need more clarity about "service", "server", and "gateway". >> 3.3.2. Refreshing a Presence Subscription >> >> For as long as a SIP user is online and interested in receiving >> presence notifications from the XMPP users, the user's SIP user agent >> is responsible for periodically refreshing the subscription by >> sending an updated SUBSCRIBE request with an appropriate value for > > sending it to which actor directly? To the XMPP user (although the SIP user wouldn't know that the user is on the XMPP side of the wormhole, since the gateway masks that fact). >> the Expires header. In response, the SIMPLE-XMPP gateway MUST send a >> >> >> >> Saint-Andre, et al. Expires April 21, 2014 [Page 9] >> >> Internet-Draft SIP-XMPP Interworking: Presence October 2013 >> >> >> SIP NOTIFY to the user agent (per [RFC6665]; if the gateway has >> meaningful information about the availability state of the XMPP user > > This prompts the thought that early in the document, there should > probably be some discussion about what state information needs to be > maintained in the gateways. Good point. >> then the NOTIFY MUST communicate that information (e.g., by including >> a PIDF body [RFC3863] with the relevant data), whereas if the gateway >> does not have meaningful information about the availability state of >> the XMPP user then the NOTIFY MUST be empty as allowed by [RFC6665]. >> >> Once the SIP user goes offline at the end of a presence session, it > > "goes offline" seems odd phrasing here; I'm not entirely sure what it > means. isn't the simple point that the SIP user terminates the presence > session (for whatever reason)? If the point is that the SIP user > literally disappears from the session -- again, there are lots of > possible reasons, where 'going offline' is only one -- some language > like that might work better. We can just say "ends its presence session". >> 4.1. Overview > > In general, this overview (4.1) section seems odd to have appear so late > in the document. Everything in it feels like stuff that should be in > Section 1, not Section 4. It's an overview of how notifications work, but you might be right that some of it belongs earlier in the document. I'll review the section with your feedback in mind. >> Both XMPP and presence-aware SIP systems enable entities (often but >> not necessarily human users) to send presence notifications to other >> entities. At a minimum, the term "presence" refers to information >> about an entity's availability for communication on a network (on/ >> off), often supplemented by information that further specifies the >> entity's communications context (e.g., "do not disturb"). Some >> systems and protocols extend this notion even further and refer to >> any relatively ephemeral information about an entity as a kind of >> presence; categories of such "extended presence" include geographical > > The above text seems a bit confusing. First it distinguishes between > presence and status, and then describes something which is both as > 'extended status.' > > Here's my guess about what is needed: > > 1. Very narrow and precise use of the term presence; I think that means > it only mean "connected to a presence service", or somesuch. It's best not to conflate presence with a physical or virtual connection, because one can be present even if disconnected (usually for a short period of time). Citing RFC 2778 might be sensible here. > 2. Consistent distinction of presence-related attributes, like do not > disturb. What's missing here is a simple term for it. In XMPP we refer to "presence" (online/offline) and "availability states" when an entity is online (away, do not disturb, etc.). We also have human-readable descriptions for such states (e.g., "in a meeting"). > 3. Clarity that "ephemeral information about an entity" is probably a > form of #2, rather than #1. That is, I think it's a presence attribute, > rather than "a presence". Such ephemeral information might include things like the user's mood, what tune is playing on their music player, etc. > And if I've gotten this entirely confused, then that means the text > needs a different kind of fixing... > > >> location (e.g., GPS coordinates), user mood (e.g., grumpy), user >> activity (e.g., walking), and ambient environment (e.g., noisy). In >> this document, we focus on the "least common denominator" of network >> availability only, although future documents might address broader >> notions of presence, including extended presence. >> >> >> >> >> Saint-Andre, et al. Expires April 21, 2014 [Page 12] >> >> Internet-Draft SIP-XMPP Interworking: Presence October 2013 >> >> >> [RFC6121] defines how XMPP presence stanzas can indicate availability >> (via absence of a 'type' attribute) or lack of availability (via a >> 'type' attribute with a value of "unavailable"). SIP presence using >> a SIP event package for presence is specified in [RFC3856]. >> >> As described in [RFC6121], presence information about an entity is > > information -> XMPP information Right. >> communicated by means of an XML stanza sent over an XML >> stream. In this document we will assume that such a presence stanza >> is sent from an XMPP client to an XMPP server over an XML stream >> negotiated between the client and the server, and that the client is >> controlled by a human user (again, this is a simplifying assumption >> introduced for explanatory purposes only). In general, XMPP presence >> is sent by the user to the user's server and then broadcasted to all >> entities who are subscribed to the user's presence information. > > http://www.dailywritingtips.com/broadcast-vs-broadcasted-as-past-form/ > > In spite of having some formal linguistic legitimacy, I suggest using > 'broadcast'. Yep. >> As described in [RFC3856], presence information about an entity is >> communicated by means of a SIP NOTIFY event sent from a SIP user >> agent to an intended recipient who is most generally referenced by an >> Presence URI of the form but who might be >> referenced by a SIP or SIPS URI of the form or >> . Here again we introduce the simplifying >> assumption that the user agent is controlled by a human user. > > I guess I'm not understanding how the nature of what is controlling the > agent affects anything in this document. Might be worth explaining that. A "presentity" doesn't have to be a human -- it could be a bot, a device, or some other automated entity. People related more to human users. >> 4.2. XMPP to SIP >> >> When Juliet interacts with her XMPP client to modify her presence >> information (or when her client automatically updates her presence >> information, e.g. via an "auto-away" feature), her client generates >> an XMPP stanza. The syntax of the stanza, >> including required and optional elements and attributes, is defined >> in [RFC6121]. The following is an example of such a stanza: >> >> Example 17: XMPP user sends presence notification: >> >> | >> >> Upon receiving such a stanza, the XMPP server to which Juliet has >> connected broadcasts it to all subscribers who are authorized to >> receive presence notifications from Juliet (this is similar to the >> SIP NOTIFY method). For each subscriber, broadcasting the presence >> notification involves either delivering it to a local recipient (if >> the hostname in the subscriber's address matches one of the hostnames >> serviced by the XMPP server) or attempting to route it to the foreign >> domain that services the hostname in the subscriber's address. Thus >> >> >> >> Saint-Andre, et al. Expires April 21, 2014 [Page 13] >> >> Internet-Draft SIP-XMPP Interworking: Presence October 2013 >> >> >> the XMPP server needs to determine the identity of the domainpart in >> the 'to' address, which it does by following the procedures discussed >> in [I-D.ietf-stox-core]. Here we assume that the XMPP server has >> determined the domain is serviced by a SIMPLE server, that it > > again, the idea that a pure xmpp server can 'know' about a simple > destination doesn't make sense to me. (And by that way, is it simple or > is it sip...? Note that the term 'simple' hasn't been getting used in > this document.) > > at a minimum, this is a good place to repeat the pointer to text that > explains how gateways are operational fit into two native networks, > where their nature is transparent -- that is, with the native entities > thinking they are merely talking to other native entities. Yes. See above. >> contains or has available to it an XMPP-SIMPLE gateway or connection >> manager (which enables it to speak natively to SIMPLE servers), and >> that it hands off the presence stanza to the XMPP-SIMPLE gateway. >> >> The XMPP-SIMPLE gateway is then responsible for translating the XMPP >> presence stanza into a SIP NOTIFY request and included PIDF document >> from the XMPP user to the SIP user. >> >> Example 18: XMPP user sends presence notification (SIP >> transformation): >> >> | NOTIFY sip:192.0.2.2 SIP/2.0 >> | Via: SIP/2.0/TCP x2s.example.com;branch=z9hG4bKna998sk >> | From: ;tag=gh19 >> | To: ;tag=yt66 >> | Contact: ;gr=balcony >> | Call-ID: 2B44E147-3B53-45E4-9D48-C051F3216D14 >> | Event: presence >> | Subscription-State: active;expires=599 >> | Max-Forwards: 70 >> | CSeq: 157 NOTIFY >> | Contact: >> | Content-Type: application/pidf+xml >> | Content-Length: 192 >> | >> | >> | > | entity='pres:juliet@example.com'> >> | >> | >> | open >> | away >> | >> | >> | >> >> The mapping of XMPP syntax elements to SIP syntax elements SHOULD be >> as shown in the following table. (Mappings for elements not >> mentioned are undefined.) >> >> >> >> >> >> >> >> >> Saint-Andre, et al. Expires April 21, 2014 [Page 14] >> >> Internet-Draft SIP-XMPP Interworking: Presence October 2013 >> >> >> Table 1: Presence syntax mapping from XMPP to SIP >> >> +-----------------------------+---------------------------+ >> | XMPP Element or Attribute | SIP Header or PIDF Data | >> +-----------------------------+---------------------------+ >> | stanza | "Event: presence" (1) | >> | XMPP resource identifer | tuple 'id' attribute (2) | >> | from | From | >> | id | CSeq (3) | >> | to | To | >> | type | basic status (4) (5) | >> | xml:lang | Content-Language | >> | | priority for tuple (6) | >> | | no mapping (7) | >> | | | >> +-----------------------------+---------------------------+ > > The format of this makes the table reads as two (unsynchronized) > columns, rather than a series of rows. > > I suggest different formatting, such as (in spite of it's being longer: > > > +-----------------------------+---------------------------+ > | XMPP Element or Attribute | SIP Header or PIDF Data | > +-----------------------------+---------------------------+ > | +-----------------------------+---------------------------+ > | XMPP resource identifer tuple 'id' attribute (2) | > +-----------------------------+---------------------------+ > | from From | > +-----------------------------+---------------------------+ > | id CSeq (3) | > +-----------------------------+---------------------------+ > | to To | > +-----------------------------+---------------------------+ > | type basic status (4) (5) | > +-----------------------------+---------------------------+ > | xml:lang Content-Language | > +-----------------------------+---------------------------+ > | priority for tuple (6) | > +-----------------------------+---------------------------+ > | no mapping (7) | > +-----------------------------+---------------------------+ > | | > +-----------------------------+---------------------------+ Agreed. >> Note the following regarding these mappings: >> >> 1. Only a presence stanza that lacks a 'type' attribute or whose > > presence -> XMPP presence Stanzas are an XMPP artifact. But yes. >> 'type' attribute has a value of "unavailable" SHOULD be mapped by >> an XMPP-SIMPLE gateway to a SIP NOTIFY request, since those are >> the only presence stanzas that represent notifications. >> 2. The PIDF schema defines the tuple 'id' attribute as having a >> datatype of "xs:ID"; because this datatype is more restrictive >> than the "xs:string" datatype for XMPP resourceparts (in >> particular, a number is not allowed as the first character of an >> ID), it is RECOMMENDED to prepend the resourcepart with "ID-" or >> some other alphabetic string when mapping from XMPP to SIP. >> 3. This mapping is OPTIONAL. > > What does that mean? This sort of mapping is usually the essence of > gatewaying semantics. How can interoperability tolerate it's being > optional? In XMPP, the 'id' attribute is not usually included in presence stanzas, and nothing is lost if it's ignored. But I'll give it a bit more thought. >> 4.3. SIP to XMPP >> >> When Romeo changes his presence, his SIP user agent generates a SIP > > Romeo is doing SIP? And Juliet does XMPP? You noticed, eh? "Juliet does Jabber" makes it easy to remember, at least for me. > So, SIP is more macho than XMPP??? Have you configured a SIP client lately? ;-) But seriously, the Romeo and Juliet scenarios enable me to use a male character and a female character for diversity purposes, with message text that is in the public domain and widely translated into something other than English for internationalization examples. Thanks for the thorough review. I'll work to address your feedback and submit a revised I-D. Peter -- Peter Saint-Andre https://stpeter.im/ From jtrentadams@gmail.com Fri Dec 13 16:16:13 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58CF91AE00D for ; Fri, 13 Dec 2013 16:16:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YZRRb1VgXz2a for ; Fri, 13 Dec 2013 16:16:11 -0800 (PST) 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 1867B1ADFAD for ; Fri, 13 Dec 2013 16:16:10 -0800 (PST) Received: by mail-oa0-f53.google.com with SMTP id m1so2865336oag.40 for ; Fri, 13 Dec 2013 16:16:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=e9nbw7WzeJKt3ze4f4PZj6zKzmFBILsZBWLKir411VU=; b=TLDl+svtu+Xd4Y0ZhRpNS6ta6owiqOHllA4gHOReR/vP2IZRdZrjVDgxkBsakZjCLI 9F1HpeCFfPKQzrPdszcFhOvyTc32tKhrPaM71e93KA0fSGw+/zWZKl3bQmJ+d78E5VlI XHv4wsRNI+hv/3dpD7wvtd6oFq2KeHC2gqEOLaUuXqYw2oRcCCCkUuF12YJiGCL30XCA cf+pRK6GbaByMgibzvzmR6SYX9D6MFlqEMweBnp0KcaY/FnQlJD5VguZCUiBsgY+Cnv6 4Wv1Ppw2ALXY26zjN5yvnoHRCSCSEf7O5qBHXmW2z3hrp4MGL4m/DuKMjCm/M6eva+MS ybuA== X-Received: by 10.60.124.138 with SMTP id mi10mr3627244oeb.57.1386980164498; Fri, 13 Dec 2013 16:16:04 -0800 (PST) Received: from jtrentadams-isoc.local (c-67-166-0-110.hsd1.co.comcast.net. [67.166.0.110]) by mx.google.com with ESMTPSA id tr10sm6116821obb.6.2013.12.13.16.16.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 13 Dec 2013 16:16:03 -0800 (PST) Message-ID: <52ABA343.4070104@gmail.com> Date: Fri, 13 Dec 2013 17:16:03 -0700 From: "J. Trent Adams" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: apps-discuss@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [apps-discuss] Working Group Last Call: draft-ietf-appsawg-rrvs-header-field-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Dec 2013 00:16:13 -0000 On 12/13/13 12:48 PM, Salvatore Loreto wrote: > Hi there, > > this mail initiates an extended Working Group Last Call for > draft-ietf-appsawg-rrvs-header-field-05.txt , ending Friday, January > 10, 2014. > (here the link: > http://www.ietf.org/id/draft-ietf-appsawg-rrvs-header-field-05.txt ) > > Please submit substantive comments of support or other review feedback > to apps-discuss@ietf.org , > or privately to the authors or to appsawg-chairs@tools.ietf.org > , prior to that date. > > We will need to see enough of these to be able to judge rough > consensus of the working group before it can be sent to our > Area Directors to start the formal publication process. > > The document shepherd is welcome to post the writeup to the > datatracker whenever it's ready. The document shepherd writeup has been posted: https://datatracker.ietf.org/doc/draft-ietf-appsawg-rrvs-header-field/shepherdwriteup/ NOTE: There are a few issues noted about the IANA Considerations which are expected to be resolved easily in the next revision. I will update the shepherd writeup as the discussion progresses through WGLC. - Trent > thank you > Salvatore > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- J. Trent Adams Profile: http://www.mediaslate.org/jtrentadams/ LinkedIN: http://www.linkedin.com/in/jtrentadams Twitter: http://twitter.com/jtrentadams From duerst@it.aoyama.ac.jp Sat Dec 14 04:30:24 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4A1C1AE06D for ; Sat, 14 Dec 2013 04:30:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.363 X-Spam-Level: *** X-Spam-Status: No, score=3.363 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQOvzFFoMCdE for ; Sat, 14 Dec 2013 04:30:18 -0800 (PST) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 537721AE11F for ; Sat, 14 Dec 2013 04:26:10 -0800 (PST) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id rBECPtDX019615; Sat, 14 Dec 2013 21:25:55 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 0662_4ba1_e130030a_64ba_11e3_bb03_001e6722eec2; Sat, 14 Dec 2013 21:25:55 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id AA799BFBD1; Sat, 14 Dec 2013 21:25:54 +0900 (JST) Message-ID: <52AC4E40.70109@it.aoyama.ac.jp> Date: Sat, 14 Dec 2013 21:25:36 +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: Tim Bray References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Unicode BOM detection in JSON vs. draft-ietf-appsawg-xml-mediatypes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Dec 2013 12:30:24 -0000 On 2013/12/14 7:20, Tim Bray wrote: > I actually think 4627bis is perfectly clear. You can use UTF-{8/16/32} = in > theory; in practice only UTF-8 works over the wire; you MUST NOT emit a= BOM > but if some dork does, it=E2=80=99s OK to forgive. There=E2=80=99s no c= harset parameter on > the media type. > > If we were doing XML in 2013, I think we=E2=80=99d probably end up at t= he same > place. Note that the original XML spec was written in ISO-8859-1 :) Yes. On the surface, some of the issues in JSON and XML may look=20 similar, but in actual practice, they are quite different. So a common=20 model or a common spec doesn't make sense. We have had some kind of common model from around 1996 or so, which was=20 that the outside (charset parameter) has precedence. This was based on=20 the assumption that there were transcoding proxies than didn't look=20 inside the document, and on statements from Netscape (when it was still=20 the dominant browser) that this was what they did. It turned out that there were few if any transcoding proxies, and=20 external information didn't get preserved well in a file system, and so=20 the practice moved more and more to give priority of internal=20 information over external. In ietf-appsawg-xml-mediatypes, we can see one specific example of what=20 this history has resulted in: carefully defined specific steps, but not=20 too pretty an overall picture. The model of the future is much simpler: UTF-8, UTF-8, UTF-8. Once=20 everything is UTF-8, the BOM will die a quiet death, too. Regards, Martin. > On Fri, Dec 13, 2013 at 2:10 PM, Larry Masinter wr= ote: > >> Compare >> http://tools.ietf.org/html/draft-ietf-json-rfc4627bis-09#section-8.1 >> >> and >> http://tools.ietf.org/html/draft-ietf-appsawg-xml-mediatypes-06#sectio= n-3 >> >> >> >> it=E2=80=99s hard to tell exactly what either is saying, much less whe= ther they=E2=80=99re >> saying >> >> the same thing. I don=E2=80=99t want to slow down either of these, b= ut some work >> on >> >> a model for how MIME types should deal with the relationship between >> >> >> >> - Charset parameter in content-type >> >> - Possible BOM maker >> >> - Other in-content character set indication (like in XML) >> >> - Other protocol sources of charset information >> >> >> >> JSON, XML, HTML, IRIs, elements based on those, and likely many other >> >> protocol elements are defined using BNF or other syntactic description >> >> techniques over the space of sequence-of-Unicode-characters >> >> (sequence-of-Unicode-code-point). >> >> >> >> Has there been any attempts to create a separate BCP that JSON and XML >> >> Could (in the future) reference? The JSON working group spent only >> >> a few thousand emails on this. >> >> >> >> Larry >> >> -- >> >> http://larry.masinter.net >> >> >> >> >> > > > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From cabo@tzi.org Sat Dec 14 05:41:25 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 203811AE0C2 for ; Sat, 14 Dec 2013 05:41:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.251 X-Spam-Level: X-Spam-Status: No, score=-1.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WrmYDFZsVYNl for ; Sat, 14 Dec 2013 05:41:23 -0800 (PST) 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 8DAAE1AE160 for ; Sat, 14 Dec 2013 05:25:57 -0800 (PST) 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.5/8.14.5) with ESMTP id rBEDPgms017635; Sat, 14 Dec 2013 14:25:42 +0100 (CET) Received: from [192.168.217.144] (p54891298.dip0.t-ipconnect.de [84.137.18.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 89D37C48; Sat, 14 Dec 2013 14:25:41 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann In-Reply-To: <52AC4E40.70109@it.aoyama.ac.jp> Date: Sat, 14 Dec 2013 14:25:37 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9DE7ACDB-ABAB-4B9A-9175-E303D0C7B783@tzi.org> References: <52AC4E40.70109@it.aoyama.ac.jp> To: =?windows-1252?Q?=22Martin_J=2E_D=FCrst=22?= X-Mailer: Apple Mail (2.1822) Cc: IETF Apps Discuss Subject: Re: [apps-discuss] Unicode BOM detection in JSON vs. draft-ietf-appsawg-xml-mediatypes X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Dec 2013 13:41:25 -0000 On 14 Dec 2013, at 13:25, Martin J. D=FCrst = wrote: > The model of the future is much simpler: UTF-8, UTF-8, UTF-8. Absolutely. Meta-comment: "The future is already here =97 it's just not very evenly = distributed."*) We (as a standardization organization) need to prioritize enabling the = way forward over bracing up the past. (I think we are in reasonable shape now with JSON, but there was more = kicking and screaming than I would have thought.) Gr=FC=DFe, Carsten *) William Gibson, of course. From melvincarvalho@gmail.com Sun Dec 15 10:19:03 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B94CE1AE149 for ; Sun, 15 Dec 2013 10:19:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.301 X-Spam-Level: ** X-Spam-Status: No, score=2.301 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XpuzRYfLto_M for ; Sun, 15 Dec 2013 10:19:02 -0800 (PST) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id E2A8C1AE141 for ; Sun, 15 Dec 2013 10:19:01 -0800 (PST) Received: by mail-ig0-f175.google.com with SMTP id j1so2250866iga.2 for ; Sun, 15 Dec 2013 10:19:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xgFE2ztwKUGXKe+h2S+Aunh0GIzAye2q/cOEXG0OygY=; b=PnAGVNRLlR+ssWQenNQPITh1H0djbIVfkj8AHIK2fGacJvSMUGkeL7mR6+WKgYtc14 QYhAD/809bqtHtbvGiQYmZSLRwYu1F6cOAVqLmAFpgzM4UWuW6q4+E6gdxJHI4N0p3SP Dg3wXALcEhYWuzoo7FIWFIrbvxYDzYYKi7JJpP5rW2DynmfObR9suUkJB4xF2P74Gmn4 o0MsOHscbChhPDz19bhByuksCcihMgHNYn3fcMG4Gg+Aa6w5r4ktdTpgI3NMNAW3Utii WDUsdJVT025qhB0oJt1yUloTyrjx4qaJ59mpaZztgAKaSJTMisjH45OF6rhhKhZZBR/4 0Oxw== MIME-Version: 1.0 X-Received: by 10.50.13.9 with SMTP id d9mr12140312igc.25.1387131541417; Sun, 15 Dec 2013 10:19:01 -0800 (PST) Received: by 10.64.226.233 with HTTP; Sun, 15 Dec 2013 10:19:01 -0800 (PST) In-Reply-To: <52A22147.4070100@gmx.de> References: <529C6DA2.8010000@gmx.de> <52A22147.4070100@gmx.de> Date: Sun, 15 Dec 2013 19:19:01 +0100 Message-ID: From: Melvin Carvalho To: Julian Reschke Content-Type: multipart/alternative; boundary=089e013c68e2c879ec04ed96baa7 Cc: Apps Discuss Subject: Re: [apps-discuss] well-known location for uuids X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Dec 2013 18:19:03 -0000 --089e013c68e2c879ec04ed96baa7 Content-Type: text/plain; charset=ISO-8859-1 On 6 December 2013 20:11, Julian Reschke wrote: > On 2013-12-06 15:22, Melvin Carvalho wrote: > >> >> >> >> On 2 December 2013 12:23, Julian Reschke > > wrote: >> >> On 2013-12-02 12:15, Melvin Carvalho wrote: >> >> Looking at >> >> http://www.iana.org/__assignments/well-known-uris/__ >> well-known-uris.xml >> >> > well-known-uris.xml> >> >> There seems to be a well known location for named instances >> (hashes) ni >> >> And also skolemized bnodes : genid >> >> Would it be a good idea to have one for uuids, do you think? >> >> Currently there is urn:uuid: as a URN but not simple way to >> translate >> this to a URL >> >> Could we maybe just add /.well-known/uuid/ ? >> >> Thoughts? >> >> >> What's the advantage of the urn:uuid notation? Do you plan to >> resolve it to a resource? >> >> >> I like to give every identifier a URI if possible. I guessed from the >> wikipedia urn aricle urn:uuid was a of the standard ways of doing this? >> >> http://en.wikipedia.org/wiki/Uniform_resource_name >> > > Well, a urn:uuid *is* a URI already. > Thanks for the reply. Thinking this over a bit more, it's great that urn:uuid is A) a URI B) non colliding But the same is also true of the ni:///sha256; URIs for example. However the difference with ni: URIs is that they can be dereferenced via the "well-known" pattern at /.well-known/ni/sha-256/base64encID It's nice at times to have both features. But it seems that ni: is more easily dereferenced than uuid right now? > > Best regards, Julian > --089e013c68e2c879ec04ed96baa7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On 6 December 2013 20:11, Julian Reschke <julian.reschke@gmx.d= e> wrote:
On 2013-12-06 15:22, Melvi= n Carvalho wrote:



On 2 December 2013 12:23, Julian Reschke <julian.reschke@gmx.de
<mailto:julia= n.reschke@gmx.de>> wrote:

=A0 =A0 On 2013-12-02 12:15, Melvin Carvalho wrote:

=A0 =A0 =A0 =A0 Looking at

=A0 =A0 =A0 =A0 http://www.iana.org/__ass= ignments/well-known-uris/__well-known-uris.xml
=
=A0 =A0 =A0 =A0 <http://www.iana.org/assig= nments/well-known-uris/well-known-uris.xml>

=A0 =A0 =A0 =A0 There seems to be a well known location for named instances=
=A0 =A0 =A0 =A0 (hashes) ni

=A0 =A0 =A0 =A0 And also skolemized bnodes : genid

=A0 =A0 =A0 =A0 Would it be a good idea to have one for uuids, do you think= ?

=A0 =A0 =A0 =A0 Currently there is urn:uuid: as a URN but not simple way to=
=A0 =A0 =A0 =A0 translate
=A0 =A0 =A0 =A0 this to a URL

=A0 =A0 =A0 =A0 Could we maybe just add /.well-known/uuid/ =A0?

=A0 =A0 =A0 =A0 Thoughts?


=A0 =A0 What's the advantage of the urn:uuid notation? Do you plan to =A0 =A0 resolve it to a resource?


I like to give every identifier a URI if possible. =A0I guessed from the wikipedia urn aricle urn:uuid was a of the standard ways of doing this?

http://en.wikipedia.org/wiki/Uniform_resource_name

Well, a urn:uuid *is* a URI already.

Th= anks for the reply.=A0 Thinking this over a bit more, it's great that u= rn:uuid is A) a URI B) non colliding

But the same is also true of th= e ni:///sha256; URIs for example.

However the difference with ni: URIs is that they can be der= eferenced via the "well-known" pattern at /.well-known/ni/sha-256= /base64encID

It's nice at times to have both features= .=A0 But it seems that ni: is more easily dereferenced than uuid right now?=
=A0

Best regards, Julian

--089e013c68e2c879ec04ed96baa7-- From dhc@dcrocker.net Tue Dec 17 07:40:52 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E2C91ADF73; Tue, 17 Dec 2013 07:40:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jR7YvxAIAAMr; Tue, 17 Dec 2013 07:40:50 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5B9C61ADEBA; Tue, 17 Dec 2013 07:40:50 -0800 (PST) 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 rBHFeZBQ021603 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 17 Dec 2013 07:40:43 -0800 Message-ID: <52B07028.4020609@dcrocker.net> Date: Tue, 17 Dec 2013 07:39:20 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Peter Saint-Andre , Apps Discuss , draft-ietf-stox-presence.all@tools.ietf.org, stox@ietf.org References: <52A94AF6.8090702@dcrocker.net> <52AB8E69.7070906@stpeter.im> In-Reply-To: <52AB8E69.7070906@stpeter.im> 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]); Tue, 17 Dec 2013 07:40:49 -0800 (PST) Cc: iesg Subject: Re: [apps-discuss] [Stox] Review of: draft-ietf-stox-presence-06 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Dec 2013 15:40:52 -0000 Only responded where it seems needed or useful... On 12/13/2013 2:47 PM, Peter Saint-Andre wrote: >> 1. When citing the earlier efforts, there should be something to >> explain why the current work is expected to be more successful. > > Not "expected", but "is". :-) AFAIK there are no implementations of the I'd missed that this is based on deployed work. That is a point that always makes writing text justifying/motivating the document quite easy: just say that. > approach taken by RFC 3922 and draft-ietf-simple-cpim-mapping (i.e., > mapping to the abstract semantics of RFC 3860), whereas there are > multiple implementations of the approach described here (i.e., direct > mapping between SIP and XMPP). > >> That is, >> what makes the current approach notably tractable for implementation and >> deployment? > > Do you think that explaining why would improve the document? IMHO this I'm a fan of context and systems views, because I think it orients the reader usefully, so the simple answer is yes. Whenever there is a lengthy history with alternative efforts, readers can benefit from some context that distinguishes the current work. Not in qualitative terms like better or worse, but in technical and operational terms. Hence I think language like what's already in the document, that distinguishes the 'architectural' difference from earlier work, but also one that says that the current work is based on deployed industry choice. > verges into developer psychology (I've got this SIP thing here and this >> 5. When showing protocol examples, usually only one side of the >> sequence is shown. For gatewaying that does interesting transforms, >> such as this one, an example should show both the before and after >> versions. That is, the 'native' protocol unit that was created and then >> the one that results from the translation. > > I thought we'd already done that. For instance, Example 2 is the SIP > transformation of the XMPP stanza shown in Example 1. Either the document didn't do it as diligently as I'm suggesting, or I didn't understand this aspect of the document, which might be remedied by better labeling. For any example that is done in a gateway and is a translation between sip presence and xmpp presence, something simple and rigorous, such as "before" and "after" labels to source and transformed versions, ought to remedy this. >> This probably raises a larger issue: How much expertise is expected of >> someone who is implementing this or otherwise reading for deep >> comprehension? In the extreme, they will need to have serious expertise >> on both protocol sets. The other extreme would be a cookbook inside >> this document, with no outside knowledge required. The document needs >> to specify the nature and extent of the expertise required. (In fact, >> the document seems pretty clean, in terms of explaining things, so I >> suspect that 'fair' knowledge of one suite will suffice. But the author >> and wg beliefs about the requirement should be made explicit.) > > See above. Perhaps not expert level, but significant familiarity with > one "side" or the other. Just to emphasize, whatever the knowledge-level of reader that's required, the document should make that explicit. I'm always a fan of making documents more accessible to wider readership, but it's not practical to make all documents fully accessible, especially within a suite of docs that build on each other. >>> | SUBSCRIBE sip:romeo@example.net SIP/2.0 >> >> Later text (section 4.1) equates the label pres: with sip: and sips:. >> Why choose sip: here? > > In practice, we don't see 'pres' URIs in the wild. Hmmm. While 'statistics' of use is a relatively fragile basis for putting things into a spec -- since a doc can last for decades and statistics can change -- it might be worth mentioning as the basis for the choice in the doc. I suppose that's in the realm of giving the reader a bit of operational insight. But definitely not an important point. >>> Example 3: SIP accepts subscription request: >>> >>> | SIP/2.0 200 OK >>> | Via: SIP/2.0/TCP s2x.example.net;branch=z9hG4bKna998sk >>> | From: ;tag=ffd2 >>> | To: ;tag=j89d >>> | Call-ID: 5BCF940D-793D-43F8-8972-218F7F4EAA8C >>> | CSeq: 234 SUBSCRIBE >>> | Contact: >>> | Expires: 3600 >>> | Content-Length: 0 >> >> Hmmm. This appears to be the original SIP acceptance, but with no >> separate display of it's being translated into XMPP. > > That is Example 5. Oh. It's worth making that explicit. (My tendency to get confused reading specs is a useful canary in the tunnel, for what needs clarifying for other readers, IMO...) >>> Example 10: SIP user subscribes to XMPP contact: >>> >>> | SUBSCRIBE sip:juliet@example.com SIP/2.0 >>> | Via: SIP/2.0/TCP s2x.example.net;branch=z9hG4bKna998sk >>> | From: ;tag=xfg9 >>> | Call-ID: AA5A8BE5-CBB7-42B9-8181-6230012B1E11 >>> | Event: presence >>> | Max-Forwards: 70 >>> | CSeq: 263 SUBSCRIBE >>> | Contact: >>> | Accept: application/pidf+xml >>> | Content-Length: 0 >>> >>> Notice that the "Expires" header was not included in the SUBSCRIBE >>> request; this means that the default value of 3600 (i.e., 3600 >>> seconds = 1 hour) applies. >>> >>> Upon receiving the SUBSCRIBE, the SIP server needs to determine the >>> identity of the domain portion of the Request-URI or To header, which >>> it does by following the procedures discussed in >>> [I-D.ietf-stox-core]. Here we assume that the SIP server has >>> determined that the domain is serviced by an XMPP server, that it >> >> >> This seems to mean that a regular SIP server needs to be familiar with >> technical details in a gatewaying specification?? > > Well, it is (IMHO) really the responsibility of a core "server" to > implement this kind of routing functionality, but the "gateway" might > make the determination that the remote domain uses SIP or XMPP and if > SIP then pass it on to the SIP "server" and if not handle delivery to I think this matches the usual model: an unchanged server does routing as if all participants were part of its 'native' protocol service. A gateway translates and tries to hide any differences between two services. The current doc language seems confusing on this point, when it talks about a (native) server choosing a server that is part of the other service. This is a sufficiently basic point to probably warrant going into -core, rather than here. But the language here probably therefore ought to just be in terms of originators and recipients (or whatever generic terminology works for presence) with an initial, simple note that knowledge of the need for translation only resides in the gateway(s). But I'm not sure I mentioned another point that confused me from -core: It shows the two types of gateways as talking to each other, but I suspect that's not reality. FOr example, when doing SIP-XMPP, I suspect the actual flow is: SIP User SIP Server SIP-XMPP Server XMPP Server XMPP User whereas the implication from the -core diagram and some of the language in the spec(s) is: SIP User SIP Server SIP-XMPP Server XMPP-SIP Server XMPP Server XMPP Use If it really is the later sequence, I don't understand why. > the remote XMPP domain. To some extent it's a matter of implementation > where exactly the code lives to complete these functions, which is why > draft-ietf-stox-core talks about a "SIP service" consisting of both a > SIP "server" and a "gateway". In XMPP this translation function is often > handled by what we call a "connection manager", but that depends a bit > on the internal architecture of the overall "service". This point highlights the essential difference between a "networking architecture" and an "implementation architecture". Mapping from the first to the second often permits very wide variations. The former concerns distinct functionality that /can/ be distributed, where the latter makes specific choices for what /is/ distributed. >>> As described in [RFC3856], presence information about an entity is >>> communicated by means of a SIP NOTIFY event sent from a SIP user >>> agent to an intended recipient who is most generally referenced by an >>> Presence URI of the form but who might be >>> referenced by a SIP or SIPS URI of the form or >>> . Here again we introduce the simplifying >>> assumption that the user agent is controlled by a human user. >> >> I guess I'm not understanding how the nature of what is controlling the >> agent affects anything in this document. Might be worth explaining that. > > A "presentity" doesn't have to be a human -- it could be a bot, a > device, or some other automated entity. People related more to human users. Sure, but when reading the doc, it felt as if the reference to this issue was relevant to functionality. I'd expect the issue to be raised once in an Intro and then avoided later by use of a neutral term like user or presentity or whatever. >>> Note the following regarding these mappings: >>> >>> 1. Only a presence stanza that lacks a 'type' attribute or whose >> >> presence -> XMPP presence > > Stanzas are an XMPP artifact. But yes. Choosing the level of semantic redundancy in the language is always a balancing act. In a gatewaying document that will be reader by folks likely to be expert in only one half of the necessary technologies, I'd be inclined towards more redundancy, to reduce likelihood of misunderstanding... >>> 'type' attribute has a value of "unavailable" SHOULD be mapped by >>> an XMPP-SIMPLE gateway to a SIP NOTIFY request, since those are >>> the only presence stanzas that represent notifications. >>> 2. The PIDF schema defines the tuple 'id' attribute as having a >>> datatype of "xs:ID"; because this datatype is more restrictive >>> than the "xs:string" datatype for XMPP resourceparts (in >>> particular, a number is not allowed as the first character of an >>> ID), it is RECOMMENDED to prepend the resourcepart with "ID-" or >>> some other alphabetic string when mapping from XMPP to SIP. >>> 3. This mapping is OPTIONAL. >> >> What does that mean? This sort of mapping is usually the essence of >> gatewaying semantics. How can interoperability tolerate it's being >> optional? > > In XMPP, the 'id' attribute is not usually included in presence stanzas, > and nothing is lost if it's ignored. But I'll give it a bit more thought. > >>> 4.3. SIP to XMPP >>> >>> When Romeo changes his presence, his SIP user agent generates a SIP >> >> Romeo is doing SIP? And Juliet does XMPP? > > You noticed, eh? "Juliet does Jabber" makes it easy to remember, at > least for me. So why isn't the other side Steve or Sid or... Nevermind... >> So, SIP is more macho than XMPP??? > > Have you configured a SIP client lately? ;-) > > But seriously, the Romeo and Juliet scenarios enable me to use a male The word seriously is entirely out of scope for this segment. Or at least, it certainly was when I started it... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From markus.lanthaler@gmx.net Wed Dec 18 06:45:35 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C74681AE24D for ; Wed, 18 Dec 2013 06:45:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.461 X-Spam-Level: X-Spam-Status: No, score=0.461 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FREEMAIL_FROM=0.001, MSGID_MULTIPLE_AT=1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TiyvGTGeVDP7 for ; Wed, 18 Dec 2013 06:45:33 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 50D701AE189 for ; Wed, 18 Dec 2013 06:45:33 -0800 (PST) Received: from Vostro3500 ([91.141.0.81]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0M2FhY-1Vcixq2BF6-00s79M for ; Wed, 18 Dec 2013 15:45:31 +0100 From: "Markus Lanthaler" To: Date: Wed, 18 Dec 2013 15:45:24 +0100 Message-ID: <028901cefbff$ca4b2e40$5ee18ac0$@lanthaler@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac77/8jjUkpszPVTTfSFMr0+wpuTmw== Content-Language: de X-Provags-ID: V03:K0:uG8LV+8eadl+3LIyRXeU1zPIRRl5MgJt8h3aUtW/sRx3CIDeGyi YAKPUK5it3bbP45LjcVnJ+F/KAL3yb6s34fvMnd9b32A9OF0lwZUtl2ozTuyUuawC5sfBUr dw8v4kDc2roSSPyTePo1M+7xFIMICkTgbF3k7WW1iLieAz39ZRG0YZH9aclfNaCdhadJ0yx i7NbT2KnGO6x9rKuY/WHg== Cc: draft-dejong-remotestorage@tools.ietf.org Subject: [apps-discuss] draft-dejong-remotestorage-02 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Dec 2013 14:45:35 -0000 Hi Michiel, I just had a look at the final version of draft-dejong-remotestorage-02. I noticed that the draft says: A successful GET request to a folder SHOULD be responded to with a JSON-LD [JSON-LD] document (content type 'application/json'), Is there any reason why you don't use JSON-LD's content type, i.e., application/ld+json? You also use a "charset" parameter in your examples in section 12 Content-Type: application/json; charset=UTF-8 .. but neither JSON nor JSON-LD have a charset parameter. You should thus simply drop it. Cheers, Markus -- Markus Lanthaler @markuslanthaler From melvincarvalho@gmail.com Sat Dec 21 11:30:04 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 250251ADFFF for ; Sat, 21 Dec 2013 11:30:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.001 X-Spam-Level: * X-Spam-Status: No, score=1.001 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Z-sSBr0YVXu for ; Sat, 21 Dec 2013 11:30:02 -0800 (PST) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6991ADEAE for ; Sat, 21 Dec 2013 11:30:01 -0800 (PST) Received: by mail-lb0-f176.google.com with SMTP id l4so1658175lbv.35 for ; Sat, 21 Dec 2013 11:29:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=S80YPyxvsrMsLSQEMSsd2ey8cvUcvw1ZVVd4t3xlsow=; b=O1NamPgN+gGlyTTFLiwi1uwwOa8BKoOK4eW7sQw1U9V9UYkL30Jb9faq/hAJ+Je3IZ Yi8ej4Cd3VD068QJUoxzY1A7+ADJDAJZrNSWcpdvT8GnQVxQgumzDucH6OYeaKP8lmfT GpUS1c7K69CMrKNdDOe6GXTbPlwRIfmhHmbNJyE1UuCnQ2Nb3HSdDO22Fk1CXe1ioPRD jfWW8DluL6bPFs1EH7ksA2M1NnFzmF2Tg2ALf2tTcv1j0SbKXd0M20Vc0sRgI/0zXHbX sEPPsVpn/Op77Weh6JP4dv6CZz8SN/GGRaaacotVH1nfi0gYhfYgmxiABJbRYS8u/TOZ vGzw== MIME-Version: 1.0 X-Received: by 10.152.234.231 with SMTP id uh7mr6997912lac.10.1387654198797; Sat, 21 Dec 2013 11:29:58 -0800 (PST) Received: by 10.112.156.72 with HTTP; Sat, 21 Dec 2013 11:29:58 -0800 (PST) In-Reply-To: References: <529C6DA2.8010000@gmx.de> <52A22147.4070100@gmx.de> Date: Sat, 21 Dec 2013 20:29:58 +0100 Message-ID: From: Melvin Carvalho To: Julian Reschke Content-Type: multipart/alternative; boundary=001a113499a4972b4d04ee106b60 Cc: Apps Discuss Subject: Re: [apps-discuss] well-known location for uuids X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Dec 2013 19:30:04 -0000 --001a113499a4972b4d04ee106b60 Content-Type: text/plain; charset=ISO-8859-1 On 15 December 2013 19:19, Melvin Carvalho wrote: > > > > On 6 December 2013 20:11, Julian Reschke wrote: > >> On 2013-12-06 15:22, Melvin Carvalho wrote: >> >>> >>> >>> >>> On 2 December 2013 12:23, Julian Reschke >> > wrote: >>> >>> On 2013-12-02 12:15, Melvin Carvalho wrote: >>> >>> Looking at >>> >>> http://www.iana.org/__assignments/well-known-uris/__ >>> well-known-uris.xml >>> >>> >> well-known-uris.xml> >>> >>> There seems to be a well known location for named instances >>> (hashes) ni >>> >>> And also skolemized bnodes : genid >>> >>> Would it be a good idea to have one for uuids, do you think? >>> >>> Currently there is urn:uuid: as a URN but not simple way to >>> translate >>> this to a URL >>> >>> Could we maybe just add /.well-known/uuid/ ? >>> >>> Thoughts? >>> >>> >>> What's the advantage of the urn:uuid notation? Do you plan to >>> resolve it to a resource? >>> >>> >>> I like to give every identifier a URI if possible. I guessed from the >>> wikipedia urn aricle urn:uuid was a of the standard ways of doing this? >>> >>> http://en.wikipedia.org/wiki/Uniform_resource_name >>> >> >> Well, a urn:uuid *is* a URI already. >> > > Thanks for the reply. Thinking this over a bit more, it's great that > urn:uuid is A) a URI B) non colliding > > But the same is also true of the ni:///sha256; URIs for example. > > However the difference with ni: URIs is that they can be dereferenced via > the "well-known" pattern at /.well-known/ni/sha-256/base64encID > > It's nice at times to have both features. But it seems that ni: is more > easily dereferenced than uuid right now? > Two possible suggestions, assuming this is not already standarized: 1) I put files in /.well-known/uuid/ 2) I put files in /.well-known/urn/uuid/ (1) seems slightly more developer friendly, so, unless this is a bad idea, I think that makes most sense right now ... > >> >> Best regards, Julian >> > > --001a113499a4972b4d04ee106b60 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On 15 December 2013 19:19, Melvin Carvalho <melvincarvalho@= gmail.com> wrote:



On 6 December 2013 20:11, Julian Reschke <julian.reschke@gmx.d= e> wrote:
On 2013-12-06 15:22,= Melvin Carvalho wrote:



On 2 December 2013 12:23, Julian Reschke <julian.reschke@gmx.de
<mailto:julia= n.reschke@gmx.de>> wrote:

=A0 =A0 On 2013-12-02 12:15, Melvin Carvalho wrote:

=A0 =A0 =A0 =A0 Looking at

=A0 =A0 =A0 =A0 http://www.iana.org/__ass= ignments/well-known-uris/__well-known-uris.xml

=A0 =A0 =A0 =A0 <http://www.iana.org/assig= nments/well-known-uris/well-known-uris.xml>

=A0 =A0 =A0 =A0 There seems to be a well known location for named instances=
=A0 =A0 =A0 =A0 (hashes) ni

=A0 =A0 =A0 =A0 And also skolemized bnodes : genid

=A0 =A0 =A0 =A0 Would it be a good idea to have one for uuids, do you think= ?

=A0 =A0 =A0 =A0 Currently there is urn:uuid: as a URN but not simple way to=
=A0 =A0 =A0 =A0 translate
=A0 =A0 =A0 =A0 this to a URL

=A0 =A0 =A0 =A0 Could we maybe just add /.well-known/uuid/ =A0?

=A0 =A0 =A0 =A0 Thoughts?


=A0 =A0 What's the advantage of the urn:uuid notation? Do you plan to =A0 =A0 resolve it to a resource?


I like to give every identifier a URI if possible. =A0I guessed from the wikipedia urn aricle urn:uuid was a of the standard ways of doing this?

http://en.wikipedia.org/wiki/Uniform_resource_name

Well, a urn:uuid *is* a URI already.

<= /div>
Thanks for the reply.=A0 Thinking this over a bit more, it's = great that urn:uuid is A) a URI B) non colliding

But the same is als= o true of the ni:///sha256; URIs for example.

However the difference with ni: URIs is that they can be der= eferenced via the "well-known" pattern at /.well-known/ni/sha-256= /base64encID

It's nice at times to have both features= .=A0 But it seems that ni: is more easily dereferenced than uuid right now?=

Two possible sugge= stions, assuming this is not already standarized:

1) I pu= t files in /.well-known/uuid/<id>

2) I put files in /.well-kno= wn/urn/uuid/<id>

(1) seems slightly more developer friendly, so, unless this = is a bad idea, I think that makes most sense right now ...
=A0

Best regards, Julian


--001a113499a4972b4d04ee106b60-- From huangng@gmail.com Mon Dec 23 05:24:51 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD7DA1ADFE5 for ; Mon, 23 Dec 2013 05:24:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQR3HBAI5znA for ; Mon, 23 Dec 2013 05:24:49 -0800 (PST) Received: from mail-ve0-x22a.google.com (mail-ve0-x22a.google.com [IPv6:2607:f8b0:400c:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 9E7E61ADFE4 for ; Mon, 23 Dec 2013 05:24:49 -0800 (PST) Received: by mail-ve0-f170.google.com with SMTP id oy12so2999700veb.1 for ; Mon, 23 Dec 2013 05:24:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Y9U0N79C9a/IEutSuktzlQEGhMvdN2GndmWsuWcuZMU=; b=aYI5CTfw6vdW0hjHgMEPQgWaJ6gDPSXDhat2zFUXxgzqNpz2wGHOL5ELy7nfxplpe/ OhwfojT4XxxsbrWYJV6l7RmHjDqrNxn4q182GY7tyIYt1U1SwibLpW6gV1Ha1/5X7CBN r78dlDjqg0d9toAGnw7Xoeepmu1E08omoFmYQ4WFl6oKv+pYNinGBD6gPP4yWMCPLLT6 OBkbxvhQwEhumpNbZEoXSOqZouYyzhKhsZvv4v9b7iJlv30WfHDzl6TuqDq2MvbvcC15 sCLklNACm39knLpo3pDNYsId0hnaO2ZbB0I0yO14HgowZ8Vjcle0WLOLNqjlqyQvx0kT ViGQ== MIME-Version: 1.0 X-Received: by 10.220.186.202 with SMTP id ct10mr13616648vcb.14.1387805086244; Mon, 23 Dec 2013 05:24:46 -0800 (PST) Received: by 10.52.116.166 with HTTP; Mon, 23 Dec 2013 05:24:46 -0800 (PST) Date: Mon, 23 Dec 2013 21:24:46 +0800 Message-ID: From: Neng Geng Huang To: apps-discuss@ietf.org Content-Type: multipart/alternative; boundary=047d7b676fd02ee4fd04ee338db1 Subject: [apps-discuss] I-D draft-huangng-idtp-01.txt X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Dec 2013 13:24:52 -0000 --047d7b676fd02ee4fd04ee338db1 Content-Type: text/plain; charset=ISO-8859-1 Hello, are there any one who interested in a new submitted Internet-Draft IDTP? Filename: draft-huangng-idtp Revision: 01 Title: Identifier Tracing Protocol (IDTP) Creation date: 2013-12-02 Group: Individual Submission Number of pages: 38 URL: http://www.ietf.org/internet-drafts/draft-huangng-idtp-01.txt Status: http://datatracker.ietf.org/doc/draft-huangng-idtp Htmlized: http://tools.ietf.org/html/draft-huangng-idtp-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-huangng-idtp-01 Abstract: The Identifier Tracing Protocol (IDTP) is an application-level protocol for distributed and collaborative information systems. It is a generic communication protocol which can be used for many tasks with two types of forwarding mechanisms to achieve traceability by using Universal Traceable Identifier (UTID) [I-D-UTID] which contains two types of forwarding messages. This document provides the specification of IDTP, including syntax, data format, and the guidelines for their use, too. Thanks -- ------------------------------ Mr. Huang Neng Geng ------------------------------ Associate Professor School of the Internet of Things Wuxi Institute of Technology Wuxi, Jiangsu, China, 214121 Mobile: 86-13921501950 email: huangng@gmail.com --047d7b676fd02ee4fd04ee338db1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello, are there any one who interested in a new submitted= Internet-Draft IDTP?

Filename: =A0 =A0 =A0 =A0draft-huangng-idtp
Revision: =A0 = =A0 =A0 =A001
= Title: =A0 =A0 =A0 =A0 =A0 Identifier Tracing Protocol (IDTP)
Creation= date: =A0 2013-12-02
= Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 38

Abstract:
=A0 =A0The Identifier Tracing Protocol (IDTP) is a= n application-level
= =A0 =A0protocol for distributed and collaborative information systems. It
=A0 =A0is a generic communication protocol which can be used for many tasks=
=A0 =A0with two types of forwarding mechanisms to achieve traceabilit= y by
= =A0 =A0using Universal Traceable Identifier (UTID) [I-D-UTID] which
= =A0 =A0contains two types of forwarding messages.
=
=A0 =A0This document provides the specification of IDTP, includin= g syntax,
= =A0 =A0data format, and the guidelines for their use, too.

=
Thanks

--
------------------------= ------
Mr. Huang Neng Geng
------------------------------
Associat= e Professor
School of the Internet of Things
Wuxi Institute of Techno= logy
Wuxi, Jiangsu, China, 214121
Mobile: 86-13921501950
email: huangng@gmail.com

=
--047d7b676fd02ee4fd04ee338db1-- From eburger@standardstrack.com Mon Dec 23 10:29:59 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 840F21AE22A; Mon, 23 Dec 2013 10:29:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.578 X-Spam-Level: * X-Spam-Status: No, score=1.578 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lkeEdYiMRriA; Mon, 23 Dec 2013 10:29:57 -0800 (PST) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.247.235]) by ietfa.amsl.com (Postfix) with ESMTP id A415B1ADFCC; Mon, 23 Dec 2013 10:29:57 -0800 (PST) Received: from 212.sub-70-215-79.myvzw.com ([70.215.79.212]:6363 helo=[192.168.43.132]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1VvAGC-00036V-5K; Mon, 23 Dec 2013 10:29:50 -0800 From: Eric Burger Content-Type: multipart/signed; boundary="Apple-Mail=_9AB71205-7DF9-478D-8A00-55BF55745EB2"; protocol="application/pgp-signature"; micalg=pgp-sha1 Date: Mon, 23 Dec 2013 13:29:45 -0500 Message-Id: <4EC11DC5-BBB4-47FD-A10B-D9CA71ECFFBF@standardstrack.com> To: apps-discuss@ietf.org, draft-ietf-appsawg-rrvs-header-field.all@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) X-Mailer: Apple Mail (2.1827) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Cc: iesg@ietf.org Subject: [apps-discuss] Applications Area Review of draft-ietf-appsawg-rrvs-header-field-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Dec 2013 18:29:59 -0000 --Apple-Mail=_9AB71205-7DF9-478D-8A00-55BF55745EB2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I have been selected as the Applications Area Review Team reviewer for = this draft. For background on apps-review, please see = http://www.apps.ietf.org/content/applications-area-review-team =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-appsawg-rrvs-header-field-05 Title: The Require-Recipient-Valid-Since Header Field and SMTP Service = Extension Reviewer: Eric Burger Review Date: 23-December-2013 =20 Summary: Short of a toxic waste warning indicating that this mechanism = does not provide a guarantee of delivery to the intended addressee, this = document is pretty much ready for publication. =20 =20 MAJOR ISSUES While this mechanism is not as bad as the ill-fated recall message = mechanism, it shares the same characteristic. Namely, this extension is = at best a request. What makes is not as bad as recall message is the use = case is for big, industrial message senders sending messages to big, = industrial messaging service providers (MSPs). In this scenario, the = sender presumably fully understands this mechanism will not relieve them = of SOX or HIPPA or other regulatory requirement not to inadvertently = release information. Likewise, the MSP is advertising (out of band) to = these large enterprises that they will do their best to honor the RRVS = mechanism. The problem is like anything in the Internet, this mechanism will leak = out from this particular use case. Specifically, someone will invariably = expose the mechanism to a MUA UI. Therefore, I would insert the = following language in the document. My proposal would be at the end of = Section 4, to the effect of: The initial use for the mechanism described in this document is for = machine-generated messages, such as from a bank to a user. This specification presumes = an enterprise application developer understands the limitations of the mechanism. = For an interactive mail application used by casual users, if the user requests the use = of the mechanism described in this document, we RECOMMEND the application displays a = dialog box or other appropriate indicator, in the user's language, stating the RRVS = request is a suggestion only and the message is likely to be delivered, without = warning or notice to the sender. =20 Along the lines of the above, we could use a mechanism such as RFC3459. = If you are a MUA and your SUBMIT server does not support RRVS, fail. If = you are a SUBMIT server or MTA and the next hop does not support RRVS, = fail. =20 There is no way to prevent a bad actor from commandeering a domain for = the purposes of snagging personal information from unsuspecting users. = Because of this, I would insist that the Security section point out that = this mechanism does not provide any security against a sender = inadvertently releasing personal information to a stale address. One = known mechanism to ensure the right user receives the information is to = encrypt the message in such a manner that only the right user can = decrypt the message. See S/MIME (RFC5751) or PGP (RFC4880) for examples = of how to ensure only the right user* can read the message. [* = Admittedly, this only says that an entity with a decryption key can read = the message, but that is infinitely more security than what RRVS = offers.] =20 p. 17, Section 15.3: How would an MTA know the message was forwarded and = not originated? Is this not a UA thing? =20 I would offer Ned's issues raised on 13 December 2013 at 9:50am PT = should all be addressed. I have no opinion on the DKIM signature issues, = other than that if we have a header that pops in and out of existence, = it makes no sense to attempt to calculate a signature over it (except = for hop-by-hop). MINOR ISSUES p. 8, step 7: "being forwarded" is ambiguous. Is this a user forwarding = amessage in a MUA UI or is this a mail server forwarding a message to a = more appropriate address? =20 p. 8, Section 6: Does this say something? If it does, it is not clear = what it is saying. A "user handling those mailboxes" would know if = ownership changed, because they are a "user *handling*" the mailbox. If = it is about a sender learning that ownership changed, then this is a = no-op because the MTA/MUA are not supposed to do RRVS processing on role = mailboxes. =20 p. 8, Section 7: as others have noted, there needs to be a forward = reference to Section 10 here, or move Section 10 earlier in the = document. =20 p. 9, Section 7.1: There is a complement to the spam processing = discussed in Section 14.2. Specifically, if a malevolent actor is = monitoring mail traffic, a RRVS header might be an indicator the message = will be of interest or high value. =20 p. 10ff, Section 9.2: Would it not be better to just say this whole = think is a "matter of local policy"? The goal is to make sure it makes = sense to deliver, or reject, a message in the case of a change of = ownership of the mailbox. These steps are all situation-dependent and = not really of general value. Same for Section 9.4. NITS Others have found them, so no need to reiterate them here. --Apple-Mail=_9AB71205-7DF9-478D-8A00-55BF55745EB2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJSuIEZAAoJEDY/T2tCIPW38BYQAJfMQ5l+B87wH8uuWHSj+3nG xeOB4bR0SbAiB+wOHI5j6uU5jxJTfeGkTA09kolzV4Hibdy3CNQ5lLUpt0Xn89xN hwaVs6aexFdUDUpngocDHXlDpbv9IfJBrlsYhXuJrmwi6xjnymwPhV5clbeKWCTI ZHsnLp4pzOC//6cUjxX1nChSjkpK+7JszmZU0wXtGQGf3PgdwtJiffBbUVUpiw8o nCn7FhLiPH/lZwMYhWKonCfW6+WfPUibPu6j+voeWhYSn49leyCIJ0iSwct9XISe X2NLf9yIRvXk7QgIvznCw7M4XIB4IDJ/ynKx4SbAVljkGvCD7S6QaKYTT6b1oMFx YrmGDX5wMr75Yvj6cBVsPs1HvVOMJE7ZaV0bxcm9QslVJQgWbjpyVmyN/o0EbyGS mCj5vP8ZtLThA7qqIb/YykbxlMop3Ms/+ZPDTEEp03/xusspBjSNnY1zB+Nf3l1f F/qAcKlV/j8T+mMc008/sGtKWZDfA5hqTEo8mSFSdMGuH/4gS9OPv4pKWs9lJkGw 5w8HOdb8cdt7W+aImYLUbvUi7w9IuogC2sIFJ1D8CoX7+4eiEiXwkuDcbRJAlzwY bXPmS5iGTMCJgT9xS9CB2o+CBCITpu9NSekb7oBEyegL519p/P09K/lEEMsLraXO YETlsEHBNUl0ETp6YQmq =dGSE -----END PGP SIGNATURE----- --Apple-Mail=_9AB71205-7DF9-478D-8A00-55BF55745EB2-- From dhc@dcrocker.net Mon Dec 23 10:53:08 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E67091ADFD5; Mon, 23 Dec 2013 10:53:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 877a-jKjCrhY; Mon, 23 Dec 2013 10:53:07 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7CFC01AE24E; Mon, 23 Dec 2013 10:53:07 -0800 (PST) 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 rBNIr0Cx021903 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 23 Dec 2013 10:53:03 -0800 Message-ID: <52B8863D.7070709@dcrocker.net> Date: Mon, 23 Dec 2013 10:51:41 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Eric Burger , apps-discuss@ietf.org, draft-ietf-appsawg-rrvs-header-field.all@tools.ietf.org References: <4EC11DC5-BBB4-47FD-A10B-D9CA71ECFFBF@standardstrack.com> In-Reply-To: <4EC11DC5-BBB4-47FD-A10B-D9CA71ECFFBF@standardstrack.com> 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, 23 Dec 2013 10:53:04 -0800 (PST) Cc: iesg@ietf.org Subject: Re: [apps-discuss] Applications Area Review of draft-ietf-appsawg-rrvs-header-field-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Dec 2013 18:53:09 -0000 On 12/23/2013 10:29 AM, Eric Burger wrote: > The initial use for the mechanism described in this document is for machine-generated > messages, such as from a bank to a user. This specification presumes an enterprise > application developer understands the limitations of the mechanism. For an interactive > mail application used by casual users, if the user requests the use of the mechanism > described in this document, we RECOMMEND the application displays a dialog box or > other appropriate indicator, in the user's language, stating the RRVS request is a > suggestion only and the message is likely to be delivered, without warning or notice > to the sender. The basic concern that the specification highlight the limitations of the mechanism being specified is fine. However IETF specs need to keep away from offering advice about interactions with human users. Every time we try to offer that advice, it demonstrates how little the IETF community knows about human computer interaction, usability, and user-centered design. Hence, if a warning is required, it needs to be from the specification writer to the specification reader. How the reader chooses to act on the warning is not the business of the IETF. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From superuser@gmail.com Tue Dec 24 01:58:30 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E6481ADAEA; Tue, 24 Dec 2013 01:58:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xAh4VMHUmx1b; Tue, 24 Dec 2013 01:58:27 -0800 (PST) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 64BFF1AD942; Tue, 24 Dec 2013 01:58:26 -0800 (PST) Received: by mail-wg0-f45.google.com with SMTP id y10so5680640wgg.0 for ; Tue, 24 Dec 2013 01:58:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=o+sQAyZcy19vWK7/AN8r8LsMrgs38QsvFFjjufFS01k=; b=tmWjo7y5rqxvUCvoy5YgKzfIxbjSWCUG+Ke26a0LThyIUBAkJU8Txj67mjLFBgiHI+ 8qDzZ6blov5hwznujZYO6rh5viw4GmAwJlNgxchbG3XsY+kJ1svEuh9m/IHFlAclivtR ln7T1DIAyNmJf7d/vFUEnqIdO9hb285y9L1b+EsvU/1wisipneBYEwoRk5Kp/H+vDx9l 0t5YnMRnjwQ35J3MmxsYfmZNq0hJDRjjnTNmZuJenslde5uy4Fcl4frhsaykRCA9h+uC z1kpdfh922Z6X+VWSYiWtk9NtvGGxKhpFos2FQU++bqbIIK/kRZ6zWbFKaVQf+kpf0Qq qCdQ== MIME-Version: 1.0 X-Received: by 10.180.108.83 with SMTP id hi19mr21898683wib.26.1387879102335; Tue, 24 Dec 2013 01:58:22 -0800 (PST) Received: by 10.180.84.106 with HTTP; Tue, 24 Dec 2013 01:58:21 -0800 (PST) In-Reply-To: <4EC11DC5-BBB4-47FD-A10B-D9CA71ECFFBF@standardstrack.com> References: <4EC11DC5-BBB4-47FD-A10B-D9CA71ECFFBF@standardstrack.com> Date: Tue, 24 Dec 2013 01:58:21 -0800 Message-ID: From: "Murray S. Kucherawy" To: Eric Burger Content-Type: multipart/alternative; boundary=e89a8f3bb025e2d30004ee44c836 Cc: draft-ietf-appsawg-rrvs-header-field.all@tools.ietf.org, The IESG , IETF Apps Discuss Subject: Re: [apps-discuss] Applications Area Review of draft-ietf-appsawg-rrvs-header-field-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Dec 2013 09:58:30 -0000 --e89a8f3bb025e2d30004ee44c836 Content-Type: text/plain; charset=ISO-8859-1 Hi Eric, thanks for your comments. On Mon, Dec 23, 2013 at 10:29 AM, Eric Burger wrote: > MAJOR ISSUES > While this mechanism is not as bad as the ill-fated recall message > mechanism, it shares the same characteristic. Namely, this extension is at > best a request. What makes is not as bad as recall message is the use case > is for big, industrial message senders sending messages to big, industrial > messaging service providers (MSPs). In this scenario, the sender presumably > fully understands this mechanism will not relieve them of SOX or HIPPA or > other regulatory requirement not to inadvertently release information. > Likewise, the MSP is advertising (out of band) to these large enterprises > that they will do their best to honor the RRVS mechanism. > > The problem is like anything in the Internet, this mechanism will leak out > from this particular use case. Specifically, someone will invariably expose > the mechanism to a MUA UI. Therefore, I would insert the following language > in the document. My proposal would be at the end of Section 4, to the > effect of: > The initial use for the mechanism described in this document is for > machine-generated > messages, such as from a bank to a user. This specification presumes an > enterprise > application developer understands the limitations of the mechanism. For > an interactive > mail application used by casual users, if the user requests the use of > the mechanism > described in this document, we RECOMMEND the application displays a > dialog box or > other appropriate indicator, in the user's language, stating the RRVS > request is a > suggestion only and the message is likely to be delivered, without > warning or notice > to the sender. > I agree with Dave Crocker's reply here; I believe we've gone out of our way lately to acknowledge that UI matters are outside of our scope, and we should consider that a luxury and enjoy it as long as we can. That said, it's probably reasonable to be clear that use of either form of RRVS is not a guarantee of anything. It's more likely to give a sender what it wants if the receiving system advertises the extension, but even then it's not certain to do what's being asked. > > Along the lines of the above, we could use a mechanism such as RFC3459. If > you are a MUA and your SUBMIT server does not support RRVS, fail. If you > are a SUBMIT server or MTA and the next hop does not support RRVS, fail. > > The latter is certainly an option, and some prefer it. Section 7 indicates that preference in general. However, there is running code out there already that we need to acknowledge which isn't so strict. > > There is no way to prevent a bad actor from commandeering a domain for the > purposes of snagging personal information from unsuspecting users. Because > of this, I would insist that the Security section point out that this > mechanism does not provide any security against a sender inadvertently > releasing personal information to a stale address. One known mechanism to > ensure the right user receives the information is to encrypt the message in > such a manner that only the right user can decrypt the message. See S/MIME > (RFC5751) or PGP (RFC4880) for examples of how to ensure only the right > user* can read the message. [* Admittedly, this only says that an entity > with a decryption key can read the message, but that is infinitely more > security than what RRVS offers.] > If by this you mean someone can intercept messages destined for a given domain, then of course that's true, but doesn't that also mean any document about email has to cite that as a possibility? Of course RRVS could be supplanted by S/MIME or PGP to reach the same goals, but those protocols haven't enjoyed anywhere close to enough deployment to make them practical solutions to this application, and that seems unlikely to change in the near future. > p. 17, Section 15.3: How would an MTA know the message was forwarded and > not originated? Is this not a UA thing? > Either way, the RRVS header field is now in the hands of some third party (i.e., not the one named in the header field), and the timestamp is thus no longer private. Given that, is it an important distinction to make? > > I would offer Ned's issues raised on 13 December 2013 at 9:50am PT should > all be addressed. I have no opinion on the DKIM signature issues, other > than that if we have a header that pops in and out of existence, it makes > no sense to attempt to calculate a signature over it (except for > hop-by-hop). > They've all been addressed for the next revision. > > MINOR ISSUES > p. 8, step 7: "being forwarded" is ambiguous. Is this a user forwarding > amessage in a MUA UI or is this a mail server forwarding a message to a > more appropriate address? > The latter. Will change the section to start "A receiving MTA ...". > > p. 8, Section 6: Does this say something? If it does, it is not clear what > it is saying. A "user handling those mailboxes" would know if ownership > changed, because they are a "user *handling*" the mailbox. If it is about a > sender learning that ownership changed, then this is a no-op because the > MTA/MUA are not supposed to do RRVS processing on role mailboxes. > Will clarify. > > p. 8, Section 7: as others have noted, there needs to be a forward > reference to Section 10 here, or move Section 10 earlier in the document. > Section 10 merely discusses our choices for the syntax of the header field. I'm not sure what relocating it or referring to it from Section 7 would accomplish. Can you clarify? > > p. 9, Section 7.1: There is a complement to the spam processing discussed > in Section 14.2. Specifically, if a malevolent actor is monitoring mail > traffic, a RRVS header might be an indicator the message will be of > interest or high value. > Good point. Will mention this in 14.2. > p. 10ff, Section 9.2: Would it not be better to just say this whole think > is a "matter of local policy"? The goal is to make sure it makes sense to > deliver, or reject, a message in the case of a change of ownership of the > mailbox. These steps are all situation-dependent and not really of general > value. Same for Section 9.4. > This seems to go hand-in-hand with your first point about the whole thing being no more than a request to the receiving system. We could probably cover both points in one short paragraph or two. Will take a run at doing so for the next version. -MSK --e89a8f3bb025e2d30004ee44c836 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Eric, thanks for your comments.

On Mon, Dec 23, = 2013 at 10:29 AM, Eric Burger <eburger@standardstrack.com>= wrote:
MAJOR ISSUES
While this mechanism is not as bad as the ill-fated recall message mechanis= m, it shares the same characteristic. Namely, this extension is at best a r= equest. What makes is not as bad as recall message is the use case is for b= ig, industrial message senders sending messages to big, industrial messagin= g service providers (MSPs). In this scenario, the sender presumably fully u= nderstands this mechanism will not relieve them of SOX or HIPPA or other re= gulatory requirement not to inadvertently release information. Likewise, th= e MSP is advertising (out of band) to these large enterprises that they wil= l do their best to honor the RRVS mechanism.

The problem is like anything in the Internet, this mechanism will leak out = from this particular use case. Specifically, someone will invariably expose= the mechanism to a MUA UI. Therefore, I would insert the following languag= e in the document. My proposal would be at the end of Section 4, to the eff= ect of:
=A0 =A0The initial use for the mechanism described in this document is for = machine-generated
=A0 =A0messages, such as from a bank to a user. This specification presumes= an enterprise
=A0 =A0application developer understands the limitations of the mechanism. = For an interactive
=A0 =A0mail application used by casual users, if the user requests the use = of the mechanism
=A0 =A0described in this document, we RECOMMEND the application displays a = dialog box or
=A0 =A0other appropriate indicator, in the user's language, stating the= RRVS request is a
=A0 =A0suggestion only and the message is likely to be delivered, without w= arning or notice
=A0 =A0to the sender.

I agree with Dave= Crocker's reply here; I believe we've gone out of our way lately t= o acknowledge that UI matters are outside of our scope, and we should consi= der that a luxury and enjoy it as long as we can.

That said, it's probably reasonable to be clear that use= of either form of RRVS is not a guarantee of anything.=A0 It's more li= kely to give a sender what it wants if the receiving system advertises the = extension, but even then it's not certain to do what's being asked.=
=A0

Along the lines of the above, we could use a mechanism such as RFC3459. If = you are a MUA and your SUBMIT server does not support RRVS, fail. If you ar= e a SUBMIT server or MTA and the next hop does not support RRVS, fail.


The latter is certainly an option, and= some prefer it.=A0 Section 7 indicates that preference in general.=A0 Howe= ver, there is running code out there already that we need to acknowledge wh= ich isn't so strict.
=A0

There is no way to prevent a bad actor from commandeering a domain for the = purposes of snagging personal information from unsuspecting users. Because = of this, I would insist that the Security section point out that this mecha= nism does not provide any security against a sender inadvertently releasing= personal information to a stale address. One known mechanism to ensure the= right user receives the information is to encrypt the message in such a ma= nner that only the right user can decrypt the message. See S/MIME (RFC5751)= or PGP (RFC4880) for examples of how to ensure only the right user* can re= ad the message. =A0[* Admittedly, this only says that an entity with a decr= yption key can read the message, but that is infinitely more security than = what RRVS offers.]

If by this you mean someone can intercept = messages destined for a given domain, then of course that's true, but d= oesn't that also mean any document about email has to cite that as a po= ssibility?

Of course RRVS could be supplanted by S/MIME or PGP to reach= the same goals, but those protocols haven't enjoyed anywhere close to = enough deployment to make them practical solutions to this application, and= that seems unlikely to change in the near future.


p. 17, Section 15.3: How would an MTA know the message was forwarded and no= t originated? Is this not a UA thing?

E= ither way, the RRVS header field is now in the hands of some third party (i= .e., not the one named in the header field), and the timestamp is thus no l= onger private.=A0 Given that, is it an important distinction to make?
=A0

I would offer Ned's issues raised on 13 December 2013 at 9:50am PT shou= ld all be addressed. I have no opinion on the DKIM signature issues, other = than that if we have a header that pops in and out of existence, it makes n= o sense to attempt to calculate a signature over it (except for hop-by-hop)= .

They've all been addressed for the nex= t revision.
=A0

MINOR ISSUES
p. 8, step 7: "being forwarded" is ambiguous. Is this a user forw= arding amessage in a MUA UI or is this a mail server forwarding a message t= o a more appropriate address?

The latte= r.=A0 Will change the section to start "A receiving MTA ...".
=A0

p. 8, Section 6: Does this say something? If it does, it is not clear what = it is saying. A "user handling those mailboxes" would know if own= ership changed, because they are a "user *handling*" the mailbox.= If it is about a sender learning that ownership changed, then this is a no= -op because the MTA/MUA are not supposed to do RRVS processing on role mail= boxes.

Will clarify.
=A0

p. 8, Section 7: as others have noted, there needs to be a forward referenc= e to Section 10 here, or move Section 10 earlier in the document.

Section 10 merely discusses our choices for the = syntax of the header field.=A0 I'm not sure what relocating it or refer= ring to it from Section 7 would accomplish.=A0 Can you clarify?
=A0

p. 9, Section 7.1: There is a complement to the spam processing discussed i= n Section 14.2. Specifically, if a malevolent actor is monitoring mail traf= fic, a RRVS header might be an indicator the message will be of interest or= high value.

Good point.=A0 Will mention this in 14.2.<= br>

p. 10ff, Section 9.2: Would it not be better to just say this whole think i= s a "matter of local policy"? The goal is to make sure it makes s= ense to deliver, or reject, a message in the case of a change of ownership = of the mailbox. These steps are all situation-dependent and not really of g= eneral value. Same for Section 9.4.

This seems to go hand-in-hand with your fi= rst point about the whole thing being no more than a request to the receivi= ng system.=A0 We could probably cover both points in one short paragraph or= two.=A0 Will take a run at doing so for the next version.

-MSK
--e89a8f3bb025e2d30004ee44c836-- From eburger@standardstrack.com Tue Dec 24 04:20:21 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B83C1ADF4B; Tue, 24 Dec 2013 04:20:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7-7PpLYQTa5; Tue, 24 Dec 2013 04:20:19 -0800 (PST) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.247.235]) by ietfa.amsl.com (Postfix) with ESMTP id B06C61ADF48; Tue, 24 Dec 2013 04:20:19 -0800 (PST) Received: from cpe-74-76-226-118.nycap.res.rr.com ([74.76.226.118]:62222 helo=[192.168.1.120]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1VvQxr-0003xU-LO; Tue, 24 Dec 2013 04:20:08 -0800 Content-Type: multipart/signed; boundary="Apple-Mail=_BC4E1E92-F62C-4C1C-8756-57FDCD13E130"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Eric Burger In-Reply-To: Date: Tue, 24 Dec 2013 07:19:56 -0500 Message-Id: <90686C7B-5484-47AC-A595-28450C89E00F@standardstrack.com> References: <4EC11DC5-BBB4-47FD-A10B-D9CA71ECFFBF@standardstrack.com> To: "Murray S. Kucherawy" X-Mailer: Apple Mail (2.1827) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Cc: draft-ietf-appsawg-rrvs-header-field.all@tools.ietf.org, The IESG , IETF Apps Discuss Subject: Re: [apps-discuss] Applications Area Review of draft-ietf-appsawg-rrvs-header-field-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Dec 2013 12:20:21 -0000 --Apple-Mail=_BC4E1E92-F62C-4C1C-8756-57FDCD13E130 Content-Type: multipart/alternative; boundary="Apple-Mail=_EA14E690-ECEA-49F2-822E-AAD6F5FA8159" --Apple-Mail=_EA14E690-ECEA-49F2-822E-AAD6F5FA8159 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Looks like a plan. Responses in line. Unless someone else wants to jump = in and insist on something. I am happy. Other thoughts in line. On Dec 24, 2013, at 4:58 AM, Murray S. Kucherawy = wrote: > Hi Eric, thanks for your comments. >=20 > On Mon, Dec 23, 2013 at 10:29 AM, Eric Burger = wrote: > MAJOR ISSUES > While this mechanism is not as bad as the ill-fated recall message = mechanism, it shares the same characteristic. Namely, this extension is = at best a request. What makes is not as bad as recall message is the use = case is for big, industrial message senders sending messages to big, = industrial messaging service providers (MSPs). In this scenario, the = sender presumably fully understands this mechanism will not relieve them = of SOX or HIPPA or other regulatory requirement not to inadvertently = release information. Likewise, the MSP is advertising (out of band) to = these large enterprises that they will do their best to honor the RRVS = mechanism. >=20 > The problem is like anything in the Internet, this mechanism will leak = out from this particular use case. Specifically, someone will invariably = expose the mechanism to a MUA UI. Therefore, I would insert the = following language in the document. My proposal would be at the end of = Section 4, to the effect of: > The initial use for the mechanism described in this document is for = machine-generated > messages, such as from a bank to a user. This specification = presumes an enterprise > application developer understands the limitations of the mechanism. = For an interactive > mail application used by casual users, if the user requests the use = of the mechanism > described in this document, we RECOMMEND the application displays a = dialog box or > other appropriate indicator, in the user's language, stating the = RRVS request is a > suggestion only and the message is likely to be delivered, without = warning or notice > to the sender. >=20 > I agree with Dave Crocker's reply here; I believe we've gone out of = our way lately to acknowledge that UI matters are outside of our scope, = and we should consider that a luxury and enjoy it as long as we can. >=20 > That said, it's probably reasonable to be clear that use of either = form of RRVS is not a guarantee of anything. It's more likely to give a = sender what it wants if the receiving system advertises the extension, = but even then it's not certain to do what's being asked. A recommendation carries zero force, but highlights something the IETF = feels is important. How users perceive what the mechanism does is = important. > =20 >=20 > Along the lines of the above, we could use a mechanism such as = RFC3459. If you are a MUA and your SUBMIT server does not support RRVS, = fail. If you are a SUBMIT server or MTA and the next hop does not = support RRVS, fail. >=20 >=20 > The latter is certainly an option, and some prefer it. Section 7 = indicates that preference in general. However, there is running code = out there already that we need to acknowledge which isn't so strict. Which part of =93draft-=93 is not understood by the community? I thought = this was a standards track document, not an individual informational = documenting current practice. > =20 >=20 > There is no way to prevent a bad actor from commandeering a domain for = the purposes of snagging personal information from unsuspecting users. = Because of this, I would insist that the Security section point out that = this mechanism does not provide any security against a sender = inadvertently releasing personal information to a stale address. One = known mechanism to ensure the right user receives the information is to = encrypt the message in such a manner that only the right user can = decrypt the message. See S/MIME (RFC5751) or PGP (RFC4880) for examples = of how to ensure only the right user* can read the message. [* = Admittedly, this only says that an entity with a decryption key can read = the message, but that is infinitely more security than what RRVS = offers.] >=20 > If by this you mean someone can intercept messages destined for a = given domain, then of course that's true, but doesn't that also mean any = document about email has to cite that as a possibility? >=20 > Of course RRVS could be supplanted by S/MIME or PGP to reach the same = goals, but those protocols haven't enjoyed anywhere close to enough = deployment to make them practical solutions to this application, and = that seems unlikely to change in the near future. The difference is RRVS is being marketed as an answer to the problem of = delivering a message to the right *person*, not just the right = *mailbox*. I am not aware of other email protocol proposals that offer = this property, other than S/MIME and PGP. >=20 >=20 > p. 17, Section 15.3: How would an MTA know the message was forwarded = and not originated? Is this not a UA thing? >=20 > Either way, the RRVS header field is now in the hands of some third = party (i.e., not the one named in the header field), and the timestamp = is thus no longer private. Given that, is it an important distinction = to make? It was just confusing to me. If the point is the header To and RRVS are = different, maybe just say that? [snip] > MINOR ISSUES [snip] > p. 8, Section 7: as others have noted, there needs to be a forward = reference to Section 10 here, or move Section 10 earlier in the = document. >=20 > Section 10 merely discusses our choices for the syntax of the header = field. I'm not sure what relocating it or referring to it from Section = 7 would accomplish. Can you clarify? Section 10 also describes how things can break. When I first read the = document, I was thinking to myself =93why all of these rules for putting = in and taking out headers?=94 It became clearer after I got to Section = 10. [snip] --Apple-Mail=_EA14E690-ECEA-49F2-822E-AAD6F5FA8159 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Looks like a plan. Responses in line. Unless someone else = wants to jump in and insist on something. I am happy. Other thoughts in = line.

On Dec 24, = 2013, at 4:58 AM, Murray S. Kucherawy <superuser@gmail.com> = wrote:

Hi Eric, thanks for your = comments.

On Mon, Dec 23, 2013 at 10:29 AM, = Eric Burger <eburger@standardstrack.com> wrote:
=
MAJOR ISSUES
While this mechanism is not as bad as the ill-fated recall message = mechanism, it shares the same characteristic. Namely, this extension is = at best a request. What makes is not as bad as recall message is the use = case is for big, industrial message senders sending messages to big, = industrial messaging service providers (MSPs). In this scenario, the = sender presumably fully understands this mechanism will not relieve them = of SOX or HIPPA or other regulatory requirement not to inadvertently = release information. Likewise, the MSP is advertising (out of band) to = these large enterprises that they will do their best to honor the RRVS = mechanism.

The problem is like anything in the Internet, this mechanism will leak = out from this particular use case. Specifically, someone will invariably = expose the mechanism to a MUA UI. Therefore, I would insert the = following language in the document. My proposal would be at the end of = Section 4, to the effect of:
   The initial use for the mechanism described in this = document is for machine-generated
   messages, such as from a bank to a user. This specification = presumes an enterprise
   application developer understands the limitations of the = mechanism. For an interactive
   mail application used by casual users, if the user requests = the use of the mechanism
   described in this document, we RECOMMEND the application = displays a dialog box or
   other appropriate indicator, in the user's language, = stating the RRVS request is a
   suggestion only and the message is likely to be delivered, = without warning or notice
   to the sender.
I agree with Dave Crocker's reply = here; I believe we've gone out of our way lately to acknowledge that UI = matters are outside of our scope, and we should consider that a luxury = and enjoy it as long as we can.

That said, it's probably reasonable = to be clear that use of either form of RRVS is not a guarantee of = anything.  It's more likely to give a sender what it wants if the = receiving system advertises the extension, but even then it's not = certain to do what's being asked.

A recommendation carries zero force, but highlights = something the IETF feels is important. How users perceive what the = mechanism does is important.

 

Along the lines of the above, we could use a mechanism such as RFC3459. = If you are a MUA and your SUBMIT server does not support RRVS, fail. If = you are a SUBMIT server or MTA and the next hop does not support RRVS, = fail.


The latter is certainly an option, and some prefer it.  = Section 7 indicates that preference in general.  However, there is = running code out there already that we need to acknowledge which isn't = so strict.

Which part of =93draft-=93 is not understood by = the community? I thought this was a standards track document, not an = individual informational documenting current practice.

 

There is no way to prevent a bad actor from commandeering a domain for = the purposes of snagging personal information from unsuspecting users. = Because of this, I would insist that the Security section point out that = this mechanism does not provide any security against a sender = inadvertently releasing personal information to a stale address. One = known mechanism to ensure the right user receives the information is to = encrypt the message in such a manner that only the right user can = decrypt the message. See S/MIME (RFC5751) or PGP (RFC4880) for examples = of how to ensure only the right user* can read the message.  [* = Admittedly, this only says that an entity with a decryption key can read = the message, but that is infinitely more security than what RRVS = offers.]

If by = this you mean someone can intercept messages destined for a given = domain, then of course that's true, but doesn't that also mean any = document about email has to cite that as a possibility?

Of course RRVS could be supplanted = by S/MIME or PGP to reach the same goals, but those protocols haven't = enjoyed anywhere close to enough deployment to make them practical = solutions to this application, and that seems unlikely to change in the = near future.

The difference is RRVS is being marketed as an answer = to the problem of delivering a message to the right *person*, not just = the right *mailbox*. I am not aware of other email protocol proposals = that offer this property, other than S/MIME and PGP.



p. 17, Section 15.3: How would an MTA know the message was forwarded and = not originated? Is this not a UA thing?

Either way, the RRVS = header field is now in the hands of some third party (i.e., not the one = named in the header field), and the timestamp is thus no longer = private.  Given that, is it an important distinction to make?

It was = just confusing to me. If the point is the header To and RRVS are = different, maybe just say that?
[snip]
MINOR ISSUES
[snip]
p. 8, Section 7: as others have noted, there needs = to be a forward reference to Section 10 here, or move Section 10 earlier = in the document.

Section 10 merely discusses our choices = for the syntax of the header field.  I'm not sure what relocating = it or referring to it from Section 7 would accomplish.  Can you = clarify?

Section = 10 also describes how things can break. When I first read the document, = I was thinking to myself =93why all of these rules for putting in and = taking out headers?=94 It became clearer after I got to Section = 10.
[snip]

= --Apple-Mail=_EA14E690-ECEA-49F2-822E-AAD6F5FA8159-- --Apple-Mail=_BC4E1E92-F62C-4C1C-8756-57FDCD13E130 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJSuXvsAAoJEDY/T2tCIPW3I8AP/jjKt1WCjVVqLKzx3xXVuICO Tdx+IbzXL2HcEHK4+yPSlBiV7L7LQOoi9R9CpDumlD1sU73Y5e+0mz4eNBWx8LfZ SHxTHpZFFZE6pozgExW88AS8oUerbknjQ/qeU34L8Md1Eui7OGYPkmNTx5I92I4n FLFWNZhv2WTYla9vzqoqHM5sQczqzpLBoKwHQCYxj6lzwqKQj+YH1hbT9aNCD82z Q7LTESioi4UbJjuhsZPdwRxucdOJiCGFGvaFAxZkMIT3S018dtC4JLiCgsNohVlg nGC4fu7ON9eUbx9X7wn2BeOtiq3DNYAUqlXDVL6NndB2IDiqBi4geusXKM3T7l5R HzLJ58pe5ZTYTbTRZZKqTkPZZ4UwSs5Tfr4/PaI+zWS9JYIAxBdGs2uX6PIBR0YV uZxC0mWCFi+rI9tc+w1l/eReMWUKNZsJWPN/+EfOVEugTfCm9/Zn0WRiIn5UZHpf YifpWm/8GTe8KJCnwX0djCnndGI/tcTR+a+J9l2ndKRcdaMwbnhLUvo/BM/ToCdw IqPZj/rBO/GBdx8bfbULKZLk3weuHqj1vHc0c3jWWpPjwFZF57PcgEd08fa4nNlo dc2Ou4lhWElp8sMHRbkEqjP6AZaLo+JjfNEuP41BLxde61jCwa8150S2qOa8KVrb 6djitBNwJ/uQ6PYhq2Ov =P1xB -----END PGP SIGNATURE----- --Apple-Mail=_BC4E1E92-F62C-4C1C-8756-57FDCD13E130-- From ned.freed@mrochek.com Tue Dec 24 09:50:32 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BDB41AE02A; Tue, 24 Dec 2013 09:50:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.26 X-Spam-Level: X-Spam-Status: No, score=0.26 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DviDwQGKMftq; Tue, 24 Dec 2013 09:50:31 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id EB5911AE032; Tue, 24 Dec 2013 09:50:30 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P2BPBALNOW001JRS@mauve.mrochek.com>; Tue, 24 Dec 2013 09:45:23 -0800 (PST) MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=iso-8859-1 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P23NF74JFK0000AS@mauve.mrochek.com>; Tue, 24 Dec 2013 09:45:19 -0800 (PST) Message-id: <01P2BPB8LLM00000AS@mauve.mrochek.com> Date: Tue, 24 Dec 2013 09:36:47 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Tue, 24 Dec 2013 01:58:21 -0800" References: <4EC11DC5-BBB4-47FD-A10B-D9CA71ECFFBF@standardstrack.com> To: "Murray S. Kucherawy" Cc: IETF Apps Discuss , draft-ietf-appsawg-rrvs-header-field.all@tools.ietf.org, The IESG Subject: Re: [apps-discuss] Applications Area Review of draft-ietf-appsawg-rrvs-header-field-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Dec 2013 17:50:32 -0000 Quick comment here. > > p. 17, Section 15.3: How would an MTA know the message was forwarded and > > not originated? Is this not a UA thing? > > > Either way, the RRVS header field is now in the hands of some third party > (i.e., not the one named in the header field), and the timestamp is thus no > longer private. Given that, is it an important distinction to make? More to the point, nothing in section 15.3 calls for MTAs to have any knowledge of whether a message is forwarded or not. Indeed, this puts the cart before the horse: The sequence is for the field to be removed as the message is delivered, so that if the message is forwarded later the field isn't there to leak information or cause other mischief. That said, there's a problem with the prose in this section: The earlier recommendation is to remove the field as messages are delivered. MDAs deliver messages, not MTAs. And this section does not make it clear that it is talking about delivery-time removal. So how about changing MTAs might not implement the recommendation to remove the header field defined here, either out of ignorance or due to error. to something like MDAs might not implement the recommendation to remove the header field defined here when messages are delivered, either out of ignorance or due to error. Ned From dhc@dcrocker.net Tue Dec 24 09:55:02 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9FCB1AE037; Tue, 24 Dec 2013 09:55:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CrN6kpUlzmVu; Tue, 24 Dec 2013 09:55:01 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id CA1811AE033; Tue, 24 Dec 2013 09:55:01 -0800 (PST) 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 rBOHsrMF020988 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 24 Dec 2013 09:54:56 -0800 Message-ID: <52B9CA1D.3010507@dcrocker.net> Date: Tue, 24 Dec 2013 09:53:33 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Eric Burger , "Murray S. Kucherawy" References: <4EC11DC5-BBB4-47FD-A10B-D9CA71ECFFBF@standardstrack.com> <90686C7B-5484-47AC-A595-28450C89E00F@standardstrack.com> In-Reply-To: <90686C7B-5484-47AC-A595-28450C89E00F@standardstrack.com> 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]); Tue, 24 Dec 2013 09:54:57 -0800 (PST) Cc: draft-ietf-appsawg-rrvs-header-field.all@tools.ietf.org, The IESG , IETF Apps Discuss Subject: Re: [apps-discuss] Applications Area Review of draft-ietf-appsawg-rrvs-header-field-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Dec 2013 17:55:02 -0000 On 12/24/2013 4:19 AM, Eric Burger wrote: > Looks like a plan. Responses in line. Unless someone else wants to jump > in and insist on something. I am happy. Other thoughts in line. > > On Dec 24, 2013, at 4:58 AM, Murray S. Kucherawy > wrote: >> That said, it's probably reasonable to be clear that use of either >> form of RRVS is not a guarantee of anything. +1 > A recommendation carries zero force, but highlights something the IETF > feels is important. How users perceive what the mechanism does is important. The issue is not whether this is important but whether advice that is given is appropriate. With respect to the IETF giving user interface advice, it typically is far outside the scope of the IETF's expertise and frankly what the IETF writes in that realm usually demonstrates the limitation. The typical example I cite is represented here, namely that we tend to think that giving users more information is always a good thing. For the IETF, what is important is making clear the semantics. In this case, making clear that a request is only a request. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From superuser@gmail.com Tue Dec 24 22:31:10 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3F201AE21A; Tue, 24 Dec 2013 22:31:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2BCEgKJ6_DRQ; Tue, 24 Dec 2013 22:31:08 -0800 (PST) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id AADC21AE207; Tue, 24 Dec 2013 22:31:07 -0800 (PST) Received: by mail-wg0-f49.google.com with SMTP id x12so6352656wgg.28 for ; Tue, 24 Dec 2013 22:31:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0sIWrl3LsPIYlAogsmyD7DZYyIy3bYaN0CI2DOwAges=; b=N+zKjdqM+wh18OIjait63c3Jg+LIcxxfimHNvw9oBX3pkV/nQFf2t3+LRHOQXcrg5S efoUujBkj/4+rMUlolzu+v9vFngP7UNMfKfcRGKgv/whNsYsKL+qS8OxK6rNZ9zaqphD zl2NPUW+5Pz9VdKnGA0lbdKH5rIiP/WFzmcKhEApHsn09DCLdCcfmOlf7z3wkaiqRaFK OH5jyY2iYFYdm96MY+mgiVMkCwSXQv8eKt4Qp3FyDC3V7IP7swyqo1WDGLWnWvKy5B4i GfupCQWsbXzJDfbgHm+Bb1yCDSEvsBK15FS6OZFCQh+3DqB7hk5qdRVM8LFrmNnULqER un7Q== MIME-Version: 1.0 X-Received: by 10.180.219.5 with SMTP id pk5mr4574267wic.8.1387953063231; Tue, 24 Dec 2013 22:31:03 -0800 (PST) Received: by 10.180.84.106 with HTTP; Tue, 24 Dec 2013 22:31:03 -0800 (PST) In-Reply-To: <90686C7B-5484-47AC-A595-28450C89E00F@standardstrack.com> References: <4EC11DC5-BBB4-47FD-A10B-D9CA71ECFFBF@standardstrack.com> <90686C7B-5484-47AC-A595-28450C89E00F@standardstrack.com> Date: Tue, 24 Dec 2013 22:31:03 -0800 Message-ID: From: "Murray S. Kucherawy" To: Eric Burger Content-Type: multipart/alternative; boundary=001a1135e4184c863b04ee560164 Cc: draft-ietf-appsawg-rrvs-header-field.all@tools.ietf.org, The IESG , IETF Apps Discuss Subject: Re: [apps-discuss] Applications Area Review of draft-ietf-appsawg-rrvs-header-field-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Dec 2013 06:31:10 -0000 --001a1135e4184c863b04ee560164 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Tue, Dec 24, 2013 at 4:19 AM, Eric Burger wr= ote: > > > >> Along the lines of the above, we could use a mechanism such as RFC3459. >> If you are a MUA and your SUBMIT server does not support RRVS, fail. If = you >> are a SUBMIT server or MTA and the next hop does not support RRVS, fail. >> >> > The latter is certainly an option, and some prefer it. Section 7 > indicates that preference in general. However, there is running code out > there already that we need to acknowledge which isn't so strict. > > > Which part of =93draft-=93 is not understood by the community? I thought = this > was a standards track document, not an individual informational documenti= ng > current practice. > I don't believe "standards track document" and "documenting current practice" are mutually exclusive, are they? > > > >> >> There is no way to prevent a bad actor from commandeering a domain for >> the purposes of snagging personal information from unsuspecting users. >> Because of this, I would insist that the Security section point out that >> this mechanism does not provide any security against a sender inadverten= tly >> releasing personal information to a stale address. One known mechanism t= o >> ensure the right user receives the information is to encrypt the message= in >> such a manner that only the right user can decrypt the message. See S/MI= ME >> (RFC5751) or PGP (RFC4880) for examples of how to ensure only the right >> user* can read the message. [* Admittedly, this only says that an entit= y >> with a decryption key can read the message, but that is infinitely more >> security than what RRVS offers.] >> > > If by this you mean someone can intercept messages destined for a given > domain, then of course that's true, but doesn't that also mean any docume= nt > about email has to cite that as a possibility? > > Of course RRVS could be supplanted by S/MIME or PGP to reach the same > goals, but those protocols haven't enjoyed anywhere close to enough > deployment to make them practical solutions to this application, and that > seems unlikely to change in the near future. > > > The difference is RRVS is being marketed as an answer to the problem of > delivering a message to the right *person*, not just the right *mailbox*.= I > am not aware of other email protocol proposals that offer this property, > other than S/MIME and PGP. > > RRVS also has limitations that don't affect S/MIME and PGP, namely the impacts of forwarding. I believe that the document already discusses those issues sufficiently, however. > > >> p. 17, Section 15.3: How would an MTA know the message was forwarded and >> not originated? Is this not a UA thing? >> > > Either way, the RRVS header field is now in the hands of some third party > (i.e., not the one named in the header field), and the timestamp is thus = no > longer private. Given that, is it an important distinction to make? > > > It was just confusing to me. If the point is the header To and RRVS are > different, maybe just say that? > That isn't the point. The issue here is a message that gets forwarded when it contained the RRVS header field. It might get forwarded by an MTA, a list, or an MUA. If the previous MTA(s) failed to scrub the RRVS information as the spec says they should have, then that information has now possibly been given to someone that shouldn't have it. In the specific case of a user agent doing so, the forwarding user might not (in fact, probably wouldn't) know the RRVS information was there in the message being forwarded because it's likely not a header field made visible to that user. The scrubbing rules don't apply to a message that was locally originated, so that's not the case being discussed here. p. 8, Section 7: as others have noted, there needs to be a forward >> reference to Section 10 here, or move Section 10 earlier in the document= . >> > > Section 10 merely discusses our choices for the syntax of the header > field. I'm not sure what relocating it or referring to it from Section 7 > would accomplish. Can you clarify? > > > Section 10 also describes how things can break. When I first read the > document, I was thinking to myself =93why all of these rules for putting = in > and taking out headers?=94 It became clearer after I got to Section 10. > [snip] > > Ah, I see what you mean. I'll re-distribute the content of Section 10 upward. -MSK --001a1135e4184c863b04ee560164 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Tue, Dec 24, 2013 at 4:19 AM, Eric Burger <eb= urger@standardstrack.com> wrote:
=A0
<= div>

Along the lines of the above, we could use a mechanism such as RFC3459. If = you are a MUA and your SUBMIT server does not support RRVS, fail. If you ar= e a SUBMIT server or MTA and the next hop does not support RRVS, fail.


The latter is certainly an option, and= some prefer it.=A0 Section 7 indicates that preference in general.=A0 Howe= ver, there is running code out there already that we need to acknowledge wh= ich isn't so strict.

Which part o= f =93draft-=93 is not understood by the community? I thought this was a sta= ndards track document, not an individual informational documenting current = practice.

I don't believe &quo= t;standards track document" and "documenting current practice&quo= t; are mutually exclusive, are they?
=A0

=A0

There is no way to prevent a bad actor from commandeering a domain for the = purposes of snagging personal information from unsuspecting users. Because = of this, I would insist that the Security section point out that this mecha= nism does not provide any security against a sender inadvertently releasing= personal information to a stale address. One known mechanism to ensure the= right user receives the information is to encrypt the message in such a ma= nner that only the right user can decrypt the message. See S/MIME (RFC5751)= or PGP (RFC4880) for examples of how to ensure only the right user* can re= ad the message. =A0[* Admittedly, this only says that an entity with a decr= yption key can read the message, but that is infinitely more security than = what RRVS offers.]

If by this you mean someone can intercept = messages destined for a given domain, then of course that's true, but d= oesn't that also mean any document about email has to cite that as a po= ssibility?

Of course RRVS could be supplanted by S/MIME or PGP to reach= the same goals, but those protocols haven't enjoyed anywhere close to = enough deployment to make them practical solutions to this application, and= that seems unlikely to change in the near future.

The difference is= RRVS is being marketed as an answer to the problem of delivering a message= to the right *person*, not just the right *mailbox*. I am not aware of oth= er email protocol proposals that offer this property, other than S/MIME and= PGP.


RRVS also has limitations that don't affect S/MIME and PGP, na= mely the impacts of forwarding.=A0 I believe that the document already disc= usses those issues sufficiently, however.


p. 17, Section 15.3: How would an MTA know the message was forwarded and no= t originated? Is this not a UA thing?

E= ither way, the RRVS header field is now in the hands of some third party (i= .e., not the one named in the header field), and the timestamp is thus no l= onger private.=A0 Given that, is it an important distinction to make?

It was just confu= sing to me. If the point is the header To and RRVS are different, maybe jus= t say that?

That isn'= t the point.=A0 The issue here is a message that gets forwarded when it con= tained the RRVS header field.=A0 It might get forwarded by an MTA, a list, = or an MUA.=A0 If the previous MTA(s) failed to scrub the RRVS information a= s the spec says they should have, then that information has now possibly be= en given to someone that shouldn't have it.=A0 In the specific case of = a user agent doing so, the forwarding user might not (in fact, probably wou= ldn't) know the RRVS information was there in the message being forward= ed because it's likely not a header field made visible to that user.=A0= The scrubbing rules don't apply to a message that was locally originat= ed, so that's not the case being discussed here.

p. 8, Section 7: as others have= noted, there needs to be a forward reference to Section 10 here, or move S= ection 10 earlier in the document.

Section 10 merely discusses our choices fo= r the syntax of the header field.=A0 I'm not sure what relocating it or= referring to it from Section 7 would accomplish.=A0 Can you clarify?

Section 10 also describ= es how things can break. When I first read the document, I was thinking to = myself =93why all of these rules for putting in and taking out headers?=94 = It became clearer after I got to Section 10.
[snip]


Ah, I see what you mean.=A0 I'll re-distribute the conten= t of Section 10 upward.

-MSK
--001a1135e4184c863b04ee560164-- From hsantos@isdg.net Thu Dec 26 08:59:50 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 480BC1AE23E for ; Thu, 26 Dec 2013 08:59:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.38 X-Spam-Level: X-Spam-Status: No, score=-98.38 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TxyfjJEDeuVu for ; Thu, 26 Dec 2013 08:59:48 -0800 (PST) Received: from catinthebox.net (mail.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 05C2C1AE22D for ; Thu, 26 Dec 2013 08:59:47 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=4814; t=1388077173; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=7mOWpLTmgDKUFdZplcvyLuLSIDg=; b=DkkRAKGaf6+KH6ltf7/E zgLlm0AQd+1iswIPWsYGR/fDTKZNN8hXflrsiFgqYIYKsdqHsa6q0R3BW9epI5Sn VYJlbtMD7bVNqS/SDxGCG2yQAGhzAWZOtdP1Tb8nrIobFaDMsvfwJbeenvVV9Kkg qtsPYWkh0djEIlYR1AOiMtI= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Thu, 26 Dec 2013 11:59:33 -0500 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 (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1654661224.13876.4192; Thu, 26 Dec 2013 11:59:32 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=4814; t=1388076642; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=dX8+V4t Pw8DY4ZQaE/h5fG3mTll56RiBAtF4fgGTJAA=; b=o2VaAYNONcTbiMoFGdvipOs Vup2CUMfuDgzLFG6hhWerUnFSLz5823zb9vHiv2npqinrrJVx+69LVyqA2UCe5kY sPPWG+OSSMa4hHEch/Jm7FOqewXotevkON/U4gNd1nH5vzqXQPvVbqxYUlSa44XQ vbgItCPEZlq/FHBDVCAI= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Thu, 26 Dec 2013 11:50:42 -0500 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1100987989.9.5024; Thu, 26 Dec 2013 11:50:41 -0500 Message-ID: <52BC6076.6010202@isdg.net> Date: Thu, 26 Dec 2013 11:59:34 -0500 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: "Murray S. Kucherawy" References: <4EC11DC5-BBB4-47FD-A10B-D9CA71ECFFBF@standardstrack.com> <90686C7B-5484-47AC-A595-28450C89E00F@standardstrack.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: IETF Apps Discuss , draft-ietf-appsawg-rrvs-header-field.all@tools.ietf.org, The IESG Subject: Re: [apps-discuss] Applications Area Review of draft-ietf-appsawg-rrvs-header-field-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Dec 2013 16:59:50 -0000 On 12/25/2013 1:31 AM, Murray S. Kucherawy wrote: > On Tue, Dec 24, 2013 at 4:19 AM, Eric Burger > > wrote: > > � >> >> >> Along the lines of the above, we could use a mechanism such >> as RFC3459. If you are a MUA and your SUBMIT server does not >> support RRVS, fail. If you are a SUBMIT server or MTA and >> the next hop does not support RRVS, fail. >> >> >> The latter is certainly an option, and some prefer it.� Section >> 7 indicates that preference in general.� However, there is >> running code out there already that we need to acknowledge which >> isn't so strict. > > Which part of �draft-� is not understood by the community? I > thought this was a standards track document, not an individual > informational documenting current practice. > > > I don't believe "standards track document" and "documenting current > practice" are mutually exclusive, are they? IMO, in this case, yes, they are. Given a short list of: 1) The unclear, "non-standard" definition of what the RRVS "time" is, 2) Its potential for inconsistent usage, 3) The high risk of user data exposure here, a Pandora Box consideration, 4) The risk of still sending and received unsecured messages, 5) No one is using this yet across the board, not in production mode yet, that I am aware of, etc. This all sounds like an EXPERIMENT, not a standard track item. It could be an INFORMATIONAL document at this time and probably better to be describing a problem looking for a solution. I am not sure the RRVS is it. This is currently an experimentation with a very high potential of being only used for exclusive relationships, i.e. a joint venture (Yahoo and Facebook) with a technology transfer of information to better synchronized heterogeneous user databases. To do this in a standard way, the RRVS time has to be better defined. It is not. The "problem" has long existed for all Online Application Hosting Vendors, such as us with over 30 years of deployments systems in all market segments, all vendors that offer a public signup service had the same constraints. It absolutely did not nor does not apply to just the "big industrial" guys. It applies to all market segments, small, large, even the hobbiest public service system and especially the smaller systems were user account expirations is more frequent. What has changed since yesteryears is the higher collision rates of more people with similar user names, not only within the USA, but global, to be used for authentication and electronic media contact addresses. In the past, the normal practice to deal with a collision was to just assign a different user id. But if the user account was deleted (for whatever reasons), and then reclaimed by a different person or assigned to a different person by the owner domain, we have the email security risk this proposal is attempting to address. So the problem is well understood, But I am not sure the RRVS is the solution without a well defined terminology for the TIME attribute. It is too open-ended for this to be declared a standard. I don't think it is correct to just say this is a local design/policy decision. There has to be some persistency and consistency in the public and private mail transport business. Note, this is not to say I won't support it in our package, but I can't until that TIME value is better defined. The way I see it from an software engineering standpoint, each potential RRVS client can have different definitions of what the RRVS time is and what also different fields of what it is suppose to be compared to in the receiver's local user database. Overall, it sounds like it wants us to create a new "Change of Ownership Date" field in user databases. Yet, it also appears this means this is more of a 1 to Many multiple definition field -- one for each potential RRVS client sending mail to a user but each has their own idea for what this time is. This means that a SENDER DOMAIN field may need to be added as well OwnerShipDateTime.DateTime OwnerShipDateTime.SenderDomain Overall, this smells, walks and talks all like an experimentation. We should slow down on labeling everything that comes out of here as a "Proposed Standard" when there hasn't been any long term, multiple vendors R&D done. I suggest, change this to a experimental status and let Yahoo and Facebook work out the details of this "experiment" as far as what this RRVS TIME field is and come back in a few year and let us know how it worked out. I think once the RRVS field is defined, we might see a higher potential for adoption and rest assured, this is one idea that can apply across all market segments, not just the big guys. -- HLS From eburger@standardstrack.com Thu Dec 26 09:53:41 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 806EF1AE25E; Thu, 26 Dec 2013 09:53:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0q3DDcXwtrXB; Thu, 26 Dec 2013 09:53:39 -0800 (PST) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) by ietfa.amsl.com (Postfix) with ESMTP id 6AF561AE22D; Thu, 26 Dec 2013 09:53:39 -0800 (PST) Received: from 100.sub-70-215-10.myvzw.com ([70.215.10.100]:10540 helo=[10.165.122.37]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.80.1) (envelope-from ) id 1VwF7b-0006vh-FP; Thu, 26 Dec 2013 09:53:30 -0800 Date: Thu, 26 Dec 2013 12:53:20 -0500 Message-ID: <36anqlsvic9n373j1h2qagml.1388080400918@email.android.com> Importance: normal From: Eric Burger To: Hector Santos MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.android.email_191249632264480" X-OutGoing-Spam-Status: No, score=-1.5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Cc: draft-ietf-appsawg-rrvs-header-field.all@tools.ietf.org, The IESG , IETF Apps Discuss Subject: Re: [apps-discuss] Applications Area Review of draft-ietf-appsawg-rrvs-header-field-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Dec 2013 17:53:41 -0000 ----_com.android.email_191249632264480 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 QWdyZWVkCgoKU2VudCBmcm9tIG15IG1vYmlsZSBkZXZpY2UuIFRoYW5rcyBiZSB0byBMRU1PTkFE RTogaHR0cDovL3d3dy5zdGFuZGFyZHN0cmFjay5jb20vaWV0Zi9sZW1vbmFkZQpTMkVSQzogaHR0 cDovL3MyZXJjLmdlb3JnZXRvd24uZWR1LwpHQ1NDOiBodHRwOi8vZ2NzYy5nZW9yZ2V0b3duLmVk dS8KTWU6IGh0dHA6Ly93d3cuY3MuZ2VvcmdldG93bi5lZHUvfiBlYnVyZ2VyCgotLS0tLS0tLSBP cmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0tCkZyb206IEhlY3RvciBTYW50b3MgPGhzYW50b3NAaXNk Zy5uZXQ+IApEYXRlOjEyLzI2LzIwMTMgIDExOjU5IEFNICAoR01ULTA1OjAwKSAKVG86ICJNdXJy YXkgUy4gS3VjaGVyYXd5IiA8c3VwZXJ1c2VyQGdtYWlsLmNvbT4gCkNjOiBFcmljIEJ1cmdlciA8 ZWJ1cmdlckBzdGFuZGFyZHN0cmFjay5jb20+LGRyYWZ0LWlldGYtYXBwc2F3Zy1ycnZzLWhlYWRl ci1maWVsZC5hbGxAdG9vbHMuaWV0Zi5vcmcsVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+LElFVEYg QXBwcyBEaXNjdXNzIDxhcHBzLWRpc2N1c3NAaWV0Zi5vcmc+IApTdWJqZWN0OiBSZTogW2FwcHMt ZGlzY3Vzc10gQXBwbGljYXRpb25zIEFyZWEgUmV2aWV3IG9mIGRyYWZ0LWlldGYtYXBwc2F3Zy1y cnZzLWhlYWRlci1maWVsZC0wNSAKCk9uIDEyLzI1LzIwMTMgMTozMSBBTSwgTXVycmF5IFMuIEt1 Y2hlcmF3eSB3cm90ZToKPiBPbiBUdWUsIERlYyAyNCwgMjAxMyBhdCA0OjE5IEFNLCBFcmljIEJ1 cmdlcgo+IDxlYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNvbSA8bWFpbHRvOmVidXJnZXJAc3RhbmRh cmRzdHJhY2suY29tPj4gd3JvdGU6Cj4KPsKgwqDCoMKgIO+/vQo+Pgo+Pgo+PsKgwqDCoMKgwqDC oMKgwqAgQWxvbmcgdGhlIGxpbmVzIG9mIHRoZSBhYm92ZSwgd2UgY291bGQgdXNlIGEgbWVjaGFu aXNtIHN1Y2gKPj7CoMKgwqDCoMKgwqDCoMKgIGFzIFJGQzM0NTkuIElmIHlvdSBhcmUgYSBNVUEg YW5kIHlvdXIgU1VCTUlUIHNlcnZlciBkb2VzIG5vdAo+PsKgwqDCoMKgwqDCoMKgwqAgc3VwcG9y dCBSUlZTLCBmYWlsLiBJZiB5b3UgYXJlIGEgU1VCTUlUIHNlcnZlciBvciBNVEEgYW5kCj4+wqDC oMKgwqDCoMKgwqDCoCB0aGUgbmV4dCBob3AgZG9lcyBub3Qgc3VwcG9ydCBSUlZTLCBmYWlsLgo+ Pgo+Pgo+PsKgwqDCoMKgIFRoZSBsYXR0ZXIgaXMgY2VydGFpbmx5IGFuIG9wdGlvbiwgYW5kIHNv bWUgcHJlZmVyIGl0Lu+/vSBTZWN0aW9uCj4+wqDCoMKgwqAgNyBpbmRpY2F0ZXMgdGhhdCBwcmVm ZXJlbmNlIGluIGdlbmVyYWwu77+9IEhvd2V2ZXIsIHRoZXJlIGlzCj4+wqDCoMKgwqAgcnVubmlu ZyBjb2RlIG91dCB0aGVyZSBhbHJlYWR5IHRoYXQgd2UgbmVlZCB0byBhY2tub3dsZWRnZSB3aGlj aAo+PsKgwqDCoMKgIGlzbid0IHNvIHN0cmljdC4KPgo+wqDCoMKgwqAgV2hpY2ggcGFydCBvZiDv v71kcmFmdC3vv70gaXMgbm90IHVuZGVyc3Rvb2QgYnkgdGhlIGNvbW11bml0eT8gSQo+wqDCoMKg wqAgdGhvdWdodCB0aGlzIHdhcyBhIHN0YW5kYXJkcyB0cmFjayBkb2N1bWVudCwgbm90IGFuIGlu ZGl2aWR1YWwKPsKgwqDCoMKgIGluZm9ybWF0aW9uYWwgZG9jdW1lbnRpbmcgY3VycmVudCBwcmFj dGljZS4KPgo+Cj4gSSBkb24ndCBiZWxpZXZlICJzdGFuZGFyZHMgdHJhY2sgZG9jdW1lbnQiIGFu ZCAiZG9jdW1lbnRpbmcgY3VycmVudAo+IHByYWN0aWNlIiBhcmUgbXV0dWFsbHkgZXhjbHVzaXZl LCBhcmUgdGhleT8KCklNTywgaW4gdGhpcyBjYXNlLCB5ZXMsIHRoZXkgYXJlLsKgIEdpdmVuIGEg c2hvcnQgbGlzdCBvZjoKCjEpIFRoZSB1bmNsZWFyLCAibm9uLXN0YW5kYXJkIiBkZWZpbml0aW9u IG9mIHdoYXQgdGhlIFJSVlMgInRpbWUiIGlzLAoyKSBJdHMgcG90ZW50aWFsIGZvciBpbmNvbnNp c3RlbnQgdXNhZ2UsCjMpIFRoZSBoaWdoIHJpc2sgb2YgdXNlciBkYXRhIGV4cG9zdXJlIGhlcmUs IGEgUGFuZG9yYSBCb3ggY29uc2lkZXJhdGlvbiwKNCkgVGhlIHJpc2sgb2Ygc3RpbGwgc2VuZGlu ZyBhbmQgcmVjZWl2ZWQgdW5zZWN1cmVkIG1lc3NhZ2VzLAo1KSBObyBvbmUgaXMgdXNpbmcgdGhp cyB5ZXQgYWNyb3NzIHRoZSBib2FyZCwgbm90IGluIHByb2R1Y3Rpb24gbW9kZSAKeWV0LCB0aGF0 IEkgYW0gYXdhcmUgb2YsIGV0Yy4KClRoaXMgYWxsIHNvdW5kcyBsaWtlIGFuIEVYUEVSSU1FTlQs IG5vdCBhIHN0YW5kYXJkIHRyYWNrIGl0ZW0uwqAgSXQgCmNvdWxkIGJlIGFuIElORk9STUFUSU9O QUwgZG9jdW1lbnQgYXQgdGhpcyB0aW1lIGFuZCBwcm9iYWJseSBiZXR0ZXIgdG8gCmJlIGRlc2Ny aWJpbmcgYSBwcm9ibGVtIGxvb2tpbmcgZm9yIGEgc29sdXRpb24uIEkgYW0gbm90IHN1cmUgdGhl IFJSVlMgCmlzIGl0LsKgIFRoaXMgaXMgY3VycmVudGx5IGFuIGV4cGVyaW1lbnRhdGlvbiB3aXRo IGEgdmVyeSBoaWdoIApwb3RlbnRpYWwgb2YgYmVpbmcgb25seSB1c2VkIGZvciBleGNsdXNpdmUg cmVsYXRpb25zaGlwcywgaS5lLiBhIGpvaW50IAp2ZW50dXJlIChZYWhvbyBhbmQgRmFjZWJvb2sp IHdpdGggYSB0ZWNobm9sb2d5IHRyYW5zZmVyIG9mIGluZm9ybWF0aW9uIAp0byBiZXR0ZXIgc3lu Y2hyb25pemVkIGhldGVyb2dlbmVvdXMgdXNlciBkYXRhYmFzZXMuwqDCoCBUbyBkbyB0aGlzIGlu IGEgCnN0YW5kYXJkIHdheSwgdGhlIFJSVlMgdGltZSBoYXMgdG8gYmUgYmV0dGVyIGRlZmluZWQu IEl0IGlzIG5vdC4KClRoZSAicHJvYmxlbSIgaGFzIGxvbmcgZXhpc3RlZCBmb3IgYWxsIE9ubGlu ZSBBcHBsaWNhdGlvbiBIb3N0aW5nIApWZW5kb3JzLCBzdWNoIGFzIHVzIHdpdGggb3ZlciAzMCB5 ZWFycyBvZiBkZXBsb3ltZW50cyBzeXN0ZW1zIGluIGFsbCAKbWFya2V0IHNlZ21lbnRzLCBhbGwg dmVuZG9ycyB0aGF0IG9mZmVyIGEgcHVibGljIHNpZ251cCBzZXJ2aWNlIGhhZCAKdGhlIHNhbWUg Y29uc3RyYWludHMuIEl0IGFic29sdXRlbHkgZGlkIG5vdCBub3IgZG9lcyBub3QgYXBwbHkgdG8g anVzdCAKdGhlICJiaWcgaW5kdXN0cmlhbCIgZ3V5cy7CoCBJdCBhcHBsaWVzIHRvIGFsbCBtYXJr ZXQgc2VnbWVudHMsIHNtYWxsLCAKbGFyZ2UsIGV2ZW4gdGhlIGhvYmJpZXN0IHB1YmxpYyBzZXJ2 aWNlIHN5c3RlbSBhbmQgZXNwZWNpYWxseSB0aGUgCnNtYWxsZXIgc3lzdGVtcyB3ZXJlIHVzZXIg YWNjb3VudCBleHBpcmF0aW9ucyBpcyBtb3JlIGZyZXF1ZW50LgoKV2hhdCBoYXMgY2hhbmdlZCBz aW5jZSB5ZXN0ZXJ5ZWFycyBpcyB0aGUgaGlnaGVyIGNvbGxpc2lvbiByYXRlcyBvZiAKbW9yZSBw ZW9wbGUgd2l0aCBzaW1pbGFyIHVzZXIgbmFtZXMsIG5vdCBvbmx5IHdpdGhpbiB0aGUgVVNBLCBi dXQgCmdsb2JhbCwgdG8gYmUgdXNlZCBmb3IgYXV0aGVudGljYXRpb24gYW5kIGVsZWN0cm9uaWMg bWVkaWEgY29udGFjdCAKYWRkcmVzc2VzLsKgIEluIHRoZSBwYXN0LCB0aGUgbm9ybWFsIHByYWN0 aWNlIHRvIGRlYWwgd2l0aCBhIGNvbGxpc2lvbiAKd2FzIHRvIGp1c3QgYXNzaWduIGEgZGlmZmVy ZW50IHVzZXIgaWQuCgpCdXQgaWYgdGhlIHVzZXIgYWNjb3VudCB3YXMgZGVsZXRlZCAoZm9yIHdo YXRldmVyIHJlYXNvbnMpLCBhbmQgdGhlbiAKcmVjbGFpbWVkIGJ5IGEgZGlmZmVyZW50IHBlcnNv biBvciBhc3NpZ25lZCB0byBhIGRpZmZlcmVudCBwZXJzb24gYnkgCnRoZSBvd25lciBkb21haW4s IHdlIGhhdmUgdGhlIGVtYWlsIHNlY3VyaXR5IHJpc2sgdGhpcyBwcm9wb3NhbCBpcyAKYXR0ZW1w dGluZyB0byBhZGRyZXNzLsKgIFNvIHRoZSBwcm9ibGVtIGlzIHdlbGwgdW5kZXJzdG9vZCwgQnV0 IEkgYW0gCm5vdCBzdXJlIHRoZSBSUlZTIGlzIHRoZSBzb2x1dGlvbiB3aXRob3V0IGEgd2VsbCBk ZWZpbmVkIHRlcm1pbm9sb2d5IApmb3IgdGhlIFRJTUUgYXR0cmlidXRlLsKgIEl0IGlzIHRvbyBv cGVuLWVuZGVkIGZvciB0aGlzIHRvIGJlIGRlY2xhcmVkIAphIHN0YW5kYXJkLsKgIEkgZG9uJ3Qg dGhpbmsgaXQgaXMgY29ycmVjdCB0byBqdXN0IHNheSB0aGlzIGlzIGEgbG9jYWwgCmRlc2lnbi9w b2xpY3kgZGVjaXNpb24uIFRoZXJlIGhhcyB0byBiZSBzb21lIHBlcnNpc3RlbmN5IGFuZCAKY29u c2lzdGVuY3kgaW4gdGhlIHB1YmxpYyBhbmQgcHJpdmF0ZSBtYWlsIHRyYW5zcG9ydCBidXNpbmVz cy4KCk5vdGUsIHRoaXMgaXMgbm90IHRvIHNheSBJIHdvbid0IHN1cHBvcnQgaXQgaW4gb3VyIHBh Y2thZ2UsIGJ1dCBJIApjYW4ndCB1bnRpbCB0aGF0IFRJTUUgdmFsdWUgaXMgYmV0dGVyIGRlZmlu ZWQuwqAgVGhlIHdheSBJIHNlZSBpdCBmcm9tIAphbiBzb2Z0d2FyZSBlbmdpbmVlcmluZyBzdGFu ZHBvaW50LCBlYWNoIHBvdGVudGlhbCBSUlZTIGNsaWVudCBjYW4gCmhhdmUgZGlmZmVyZW50IGRl ZmluaXRpb25zIG9mIHdoYXQgdGhlIFJSVlMgdGltZSBpcyBhbmQgd2hhdCBhbHNvIApkaWZmZXJl bnQgZmllbGRzIG9mIHdoYXQgaXQgaXMgc3VwcG9zZSB0byBiZSBjb21wYXJlZCB0byBpbiB0aGUg CnJlY2VpdmVyJ3MgbG9jYWwgdXNlciBkYXRhYmFzZS7CoCBPdmVyYWxsLCBpdCBzb3VuZHMgbGlr ZSBpdCB3YW50cyB1cyAKdG8gY3JlYXRlIGEgbmV3ICJDaGFuZ2Ugb2YgT3duZXJzaGlwIERhdGUi IGZpZWxkIGluIHVzZXIgZGF0YWJhc2VzLiAKWWV0LCBpdCBhbHNvIGFwcGVhcnMgdGhpcyBtZWFu cyB0aGlzIGlzIG1vcmUgb2YgYSAxIHRvIE1hbnkgbXVsdGlwbGUgCmRlZmluaXRpb24gZmllbGQg LS0gb25lIGZvciBlYWNoIHBvdGVudGlhbCBSUlZTIGNsaWVudCBzZW5kaW5nIG1haWwgdG8gCmEg dXNlciBidXQgZWFjaCBoYXMgdGhlaXIgb3duIGlkZWEgZm9yIHdoYXQgdGhpcyB0aW1lIGlzLsKg IFRoaXMgbWVhbnMgCnRoYXQgYSBTRU5ERVIgRE9NQUlOIGZpZWxkIG1heSBuZWVkIHRvIGJlIGFk ZGVkIGFzIHdlbGwKCsKgwqDCoMKgIE93bmVyU2hpcERhdGVUaW1lLkRhdGVUaW1lCsKgwqDCoMKg IE93bmVyU2hpcERhdGVUaW1lLlNlbmRlckRvbWFpbgoKT3ZlcmFsbCwgdGhpcyBzbWVsbHMsIHdh bGtzIGFuZCB0YWxrcyBhbGwgbGlrZSBhbiBleHBlcmltZW50YXRpb24uwqAgV2UgCnNob3VsZCBz bG93IGRvd24gb24gbGFiZWxpbmcgZXZlcnl0aGluZyB0aGF0IGNvbWVzIG91dCBvZiBoZXJlIGFz IGEgCiJQcm9wb3NlZCBTdGFuZGFyZCIgd2hlbiB0aGVyZSBoYXNuJ3QgYmVlbiBhbnkgbG9uZyB0 ZXJtLCBtdWx0aXBsZSAKdmVuZG9ycyBSJkQgZG9uZS4KCkkgc3VnZ2VzdCwgY2hhbmdlIHRoaXMg dG8gYSBleHBlcmltZW50YWwgc3RhdHVzIGFuZCBsZXQgWWFob28gYW5kIApGYWNlYm9vayB3b3Jr IG91dCB0aGUgZGV0YWlscyBvZiB0aGlzICJleHBlcmltZW50IiBhcyBmYXIgYXMgd2hhdCB0aGlz IApSUlZTIFRJTUUgZmllbGQgaXMgYW5kIGNvbWUgYmFjayBpbiBhIGZldyB5ZWFyIGFuZCBsZXQg dXMga25vdyBob3cgaXQgCndvcmtlZCBvdXQuwqAgSSB0aGluayBvbmNlIHRoZSBSUlZTIGZpZWxk IGlzIGRlZmluZWQsIHdlIG1pZ2h0IHNlZSBhIApoaWdoZXIgcG90ZW50aWFsIGZvciBhZG9wdGlv biBhbmQgcmVzdCBhc3N1cmVkLCB0aGlzIGlzIG9uZSBpZGVhIHRoYXQgCmNhbiBhcHBseSBhY3Jv c3MgYWxsIG1hcmtldCBzZWdtZW50cywgbm90IGp1c3QgdGhlIGJpZyBndXlzLgoKLS0gCkhMUwoK Cg== ----_com.android.email_191249632264480 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSA+PGRpdj5BZ3JlZWQ8L2Rpdj48ZGl2 Pjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj5TZW50IGZyb20gbXkgbW9iaWxlIGRldmljZS4gVGhh bmtzIGJlIHRvIExFTU9OQURFOiBodHRwOi8vd3d3LnN0YW5kYXJkc3RyYWNrLmNvbS9pZXRmL2xl bW9uYWRlPGRpdj5TMkVSQzogaHR0cDovL3MyZXJjLmdlb3JnZXRvd24uZWR1LzwvZGl2PjxkaXY+ R0NTQzogaHR0cDovL2djc2MuZ2VvcmdldG93bi5lZHUvPC9kaXY+PGRpdj5NZTogaHR0cDovL3d3 dy5jcy5nZW9yZ2V0b3duLmVkdS9+IGVidXJnZXI8L2Rpdj48YnI+PGJyPi0tLS0tLS0tIE9yaWdp bmFsIG1lc3NhZ2UgLS0tLS0tLS08YnI+RnJvbTogSGVjdG9yIFNhbnRvcyA8aHNhbnRvc0Bpc2Rn Lm5ldD4gPGJyPkRhdGU6MTIvMjYvMjAxMyAgMTE6NTkgQU0gIChHTVQtMDU6MDApIDxicj5Ubzog Ik11cnJheSBTLiBLdWNoZXJhd3kiIDxzdXBlcnVzZXJAZ21haWwuY29tPiA8YnI+Q2M6IEVyaWMg QnVyZ2VyIDxlYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNvbT4sZHJhZnQtaWV0Zi1hcHBzYXdnLXJy dnMtaGVhZGVyLWZpZWxkLmFsbEB0b29scy5pZXRmLm9yZyxUaGUgSUVTRyA8aWVzZ0BpZXRmLm9y Zz4sSUVURiBBcHBzIERpc2N1c3MgPGFwcHMtZGlzY3Vzc0BpZXRmLm9yZz4gPGJyPlN1YmplY3Q6 IFJlOiBbYXBwcy1kaXNjdXNzXSBBcHBsaWNhdGlvbnMgQXJlYSBSZXZpZXcgb2YgZHJhZnQtaWV0 Zi1hcHBzYXdnLXJydnMtaGVhZGVyLWZpZWxkLTA1IDxicj48YnI+T24gMTIvMjUvMjAxMyAxOjMx IEFNLCBNdXJyYXkgUy4gS3VjaGVyYXd5IHdyb3RlOjxicj4mZ3Q7IE9uIFR1ZSwgRGVjIDI0LCAy MDEzIGF0IDQ6MTkgQU0sIEVyaWMgQnVyZ2VyPGJyPiZndDsgJmx0O2VidXJnZXJAc3RhbmRhcmRz dHJhY2suY29tICZsdDttYWlsdG86ZWJ1cmdlckBzdGFuZGFyZHN0cmFjay5jb20mZ3Q7Jmd0OyB3 cm90ZTo8YnI+Jmd0Ozxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IO+/vTxicj4mZ3Q7 Jmd0Ozxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBBbG9uZyB0aGUgbGluZXMgb2YgdGhlIGFib3ZlLCB3ZSBjb3Vs ZCB1c2UgYSBtZWNoYW5pc20gc3VjaDxicj4mZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhcyBSRkMzNDU5LiBJZiB5b3UgYXJlIGEgTVVBIGFu ZCB5b3VyIFNVQk1JVCBzZXJ2ZXIgZG9lcyBub3Q8YnI+Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc3VwcG9ydCBSUlZTLCBmYWlsLiBJZiB5 b3UgYXJlIGEgU1VCTUlUIHNlcnZlciBvciBNVEEgYW5kPGJyPiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoZSBuZXh0IGhvcCBkb2VzIG5v dCBzdXBwb3J0IFJSVlMsIGZhaWwuPGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoZSBsYXR0ZXIgaXMgY2VydGFpbmx5IGFuIG9wdGlv biwgYW5kIHNvbWUgcHJlZmVyIGl0Lu+/vSBTZWN0aW9uPGJyPiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IDcgaW5kaWNhdGVzIHRoYXQgcHJlZmVyZW5jZSBpbiBnZW5lcmFsLu+/vSBI b3dldmVyLCB0aGVyZSBpczxicj4mZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBydW5u aW5nIGNvZGUgb3V0IHRoZXJlIGFscmVhZHkgdGhhdCB3ZSBuZWVkIHRvIGFja25vd2xlZGdlIHdo aWNoPGJyPiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGlzbid0IHNvIHN0cmljdC48 YnI+Jmd0Ozxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFdoaWNoIHBhcnQgb2Yg77+9 ZHJhZnQt77+9IGlzIG5vdCB1bmRlcnN0b29kIGJ5IHRoZSBjb21tdW5pdHk/IEk8YnI+Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aG91Z2h0IHRoaXMgd2FzIGEgc3RhbmRhcmRzIHRyYWNr IGRvY3VtZW50LCBub3QgYW4gaW5kaXZpZHVhbDxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IGluZm9ybWF0aW9uYWwgZG9jdW1lbnRpbmcgY3VycmVudCBwcmFjdGljZS48YnI+Jmd0Ozxi cj4mZ3Q7PGJyPiZndDsgSSBkb24ndCBiZWxpZXZlICJzdGFuZGFyZHMgdHJhY2sgZG9jdW1lbnQi IGFuZCAiZG9jdW1lbnRpbmcgY3VycmVudDxicj4mZ3Q7IHByYWN0aWNlIiBhcmUgbXV0dWFsbHkg ZXhjbHVzaXZlLCBhcmUgdGhleT88YnI+PGJyPklNTywgaW4gdGhpcyBjYXNlLCB5ZXMsIHRoZXkg YXJlLiZuYnNwOyBHaXZlbiBhIHNob3J0IGxpc3Qgb2Y6PGJyPjxicj4xKSBUaGUgdW5jbGVhciwg Im5vbi1zdGFuZGFyZCIgZGVmaW5pdGlvbiBvZiB3aGF0IHRoZSBSUlZTICJ0aW1lIiBpcyw8YnI+ MikgSXRzIHBvdGVudGlhbCBmb3IgaW5jb25zaXN0ZW50IHVzYWdlLDxicj4zKSBUaGUgaGlnaCBy aXNrIG9mIHVzZXIgZGF0YSBleHBvc3VyZSBoZXJlLCBhIFBhbmRvcmEgQm94IGNvbnNpZGVyYXRp b24sPGJyPjQpIFRoZSByaXNrIG9mIHN0aWxsIHNlbmRpbmcgYW5kIHJlY2VpdmVkIHVuc2VjdXJl ZCBtZXNzYWdlcyw8YnI+NSkgTm8gb25lIGlzIHVzaW5nIHRoaXMgeWV0IGFjcm9zcyB0aGUgYm9h cmQsIG5vdCBpbiBwcm9kdWN0aW9uIG1vZGUgPGJyPnlldCwgdGhhdCBJIGFtIGF3YXJlIG9mLCBl dGMuPGJyPjxicj5UaGlzIGFsbCBzb3VuZHMgbGlrZSBhbiBFWFBFUklNRU5ULCBub3QgYSBzdGFu ZGFyZCB0cmFjayBpdGVtLiZuYnNwOyBJdCA8YnI+Y291bGQgYmUgYW4gSU5GT1JNQVRJT05BTCBk b2N1bWVudCBhdCB0aGlzIHRpbWUgYW5kIHByb2JhYmx5IGJldHRlciB0byA8YnI+YmUgZGVzY3Jp YmluZyBhIHByb2JsZW0gbG9va2luZyBmb3IgYSBzb2x1dGlvbi4gSSBhbSBub3Qgc3VyZSB0aGUg UlJWUyA8YnI+aXMgaXQuJm5ic3A7IFRoaXMgaXMgY3VycmVudGx5IGFuIGV4cGVyaW1lbnRhdGlv biB3aXRoIGEgdmVyeSBoaWdoIDxicj5wb3RlbnRpYWwgb2YgYmVpbmcgb25seSB1c2VkIGZvciBl eGNsdXNpdmUgcmVsYXRpb25zaGlwcywgaS5lLiBhIGpvaW50IDxicj52ZW50dXJlIChZYWhvbyBh bmQgRmFjZWJvb2spIHdpdGggYSB0ZWNobm9sb2d5IHRyYW5zZmVyIG9mIGluZm9ybWF0aW9uIDxi cj50byBiZXR0ZXIgc3luY2hyb25pemVkIGhldGVyb2dlbmVvdXMgdXNlciBkYXRhYmFzZXMuJm5i c3A7Jm5ic3A7IFRvIGRvIHRoaXMgaW4gYSA8YnI+c3RhbmRhcmQgd2F5LCB0aGUgUlJWUyB0aW1l IGhhcyB0byBiZSBiZXR0ZXIgZGVmaW5lZC4gSXQgaXMgbm90Ljxicj48YnI+VGhlICJwcm9ibGVt IiBoYXMgbG9uZyBleGlzdGVkIGZvciBhbGwgT25saW5lIEFwcGxpY2F0aW9uIEhvc3RpbmcgPGJy PlZlbmRvcnMsIHN1Y2ggYXMgdXMgd2l0aCBvdmVyIDMwIHllYXJzIG9mIGRlcGxveW1lbnRzIHN5 c3RlbXMgaW4gYWxsIDxicj5tYXJrZXQgc2VnbWVudHMsIGFsbCB2ZW5kb3JzIHRoYXQgb2ZmZXIg YSBwdWJsaWMgc2lnbnVwIHNlcnZpY2UgaGFkIDxicj50aGUgc2FtZSBjb25zdHJhaW50cy4gSXQg YWJzb2x1dGVseSBkaWQgbm90IG5vciBkb2VzIG5vdCBhcHBseSB0byBqdXN0IDxicj50aGUgImJp ZyBpbmR1c3RyaWFsIiBndXlzLiZuYnNwOyBJdCBhcHBsaWVzIHRvIGFsbCBtYXJrZXQgc2VnbWVu dHMsIHNtYWxsLCA8YnI+bGFyZ2UsIGV2ZW4gdGhlIGhvYmJpZXN0IHB1YmxpYyBzZXJ2aWNlIHN5 c3RlbSBhbmQgZXNwZWNpYWxseSB0aGUgPGJyPnNtYWxsZXIgc3lzdGVtcyB3ZXJlIHVzZXIgYWNj b3VudCBleHBpcmF0aW9ucyBpcyBtb3JlIGZyZXF1ZW50Ljxicj48YnI+V2hhdCBoYXMgY2hhbmdl ZCBzaW5jZSB5ZXN0ZXJ5ZWFycyBpcyB0aGUgaGlnaGVyIGNvbGxpc2lvbiByYXRlcyBvZiA8YnI+ bW9yZSBwZW9wbGUgd2l0aCBzaW1pbGFyIHVzZXIgbmFtZXMsIG5vdCBvbmx5IHdpdGhpbiB0aGUg VVNBLCBidXQgPGJyPmdsb2JhbCwgdG8gYmUgdXNlZCBmb3IgYXV0aGVudGljYXRpb24gYW5kIGVs ZWN0cm9uaWMgbWVkaWEgY29udGFjdCA8YnI+YWRkcmVzc2VzLiZuYnNwOyBJbiB0aGUgcGFzdCwg dGhlIG5vcm1hbCBwcmFjdGljZSB0byBkZWFsIHdpdGggYSBjb2xsaXNpb24gPGJyPndhcyB0byBq dXN0IGFzc2lnbiBhIGRpZmZlcmVudCB1c2VyIGlkLjxicj48YnI+QnV0IGlmIHRoZSB1c2VyIGFj Y291bnQgd2FzIGRlbGV0ZWQgKGZvciB3aGF0ZXZlciByZWFzb25zKSwgYW5kIHRoZW4gPGJyPnJl Y2xhaW1lZCBieSBhIGRpZmZlcmVudCBwZXJzb24gb3IgYXNzaWduZWQgdG8gYSBkaWZmZXJlbnQg cGVyc29uIGJ5IDxicj50aGUgb3duZXIgZG9tYWluLCB3ZSBoYXZlIHRoZSBlbWFpbCBzZWN1cml0 eSByaXNrIHRoaXMgcHJvcG9zYWwgaXMgPGJyPmF0dGVtcHRpbmcgdG8gYWRkcmVzcy4mbmJzcDsg U28gdGhlIHByb2JsZW0gaXMgd2VsbCB1bmRlcnN0b29kLCBCdXQgSSBhbSA8YnI+bm90IHN1cmUg dGhlIFJSVlMgaXMgdGhlIHNvbHV0aW9uIHdpdGhvdXQgYSB3ZWxsIGRlZmluZWQgdGVybWlub2xv Z3kgPGJyPmZvciB0aGUgVElNRSBhdHRyaWJ1dGUuJm5ic3A7IEl0IGlzIHRvbyBvcGVuLWVuZGVk IGZvciB0aGlzIHRvIGJlIGRlY2xhcmVkIDxicj5hIHN0YW5kYXJkLiZuYnNwOyBJIGRvbid0IHRo aW5rIGl0IGlzIGNvcnJlY3QgdG8ganVzdCBzYXkgdGhpcyBpcyBhIGxvY2FsIDxicj5kZXNpZ24v cG9saWN5IGRlY2lzaW9uLiBUaGVyZSBoYXMgdG8gYmUgc29tZSBwZXJzaXN0ZW5jeSBhbmQgPGJy PmNvbnNpc3RlbmN5IGluIHRoZSBwdWJsaWMgYW5kIHByaXZhdGUgbWFpbCB0cmFuc3BvcnQgYnVz aW5lc3MuPGJyPjxicj5Ob3RlLCB0aGlzIGlzIG5vdCB0byBzYXkgSSB3b24ndCBzdXBwb3J0IGl0 IGluIG91ciBwYWNrYWdlLCBidXQgSSA8YnI+Y2FuJ3QgdW50aWwgdGhhdCBUSU1FIHZhbHVlIGlz IGJldHRlciBkZWZpbmVkLiZuYnNwOyBUaGUgd2F5IEkgc2VlIGl0IGZyb20gPGJyPmFuIHNvZnR3 YXJlIGVuZ2luZWVyaW5nIHN0YW5kcG9pbnQsIGVhY2ggcG90ZW50aWFsIFJSVlMgY2xpZW50IGNh biA8YnI+aGF2ZSBkaWZmZXJlbnQgZGVmaW5pdGlvbnMgb2Ygd2hhdCB0aGUgUlJWUyB0aW1lIGlz IGFuZCB3aGF0IGFsc28gPGJyPmRpZmZlcmVudCBmaWVsZHMgb2Ygd2hhdCBpdCBpcyBzdXBwb3Nl IHRvIGJlIGNvbXBhcmVkIHRvIGluIHRoZSA8YnI+cmVjZWl2ZXIncyBsb2NhbCB1c2VyIGRhdGFi YXNlLiZuYnNwOyBPdmVyYWxsLCBpdCBzb3VuZHMgbGlrZSBpdCB3YW50cyB1cyA8YnI+dG8gY3Jl YXRlIGEgbmV3ICJDaGFuZ2Ugb2YgT3duZXJzaGlwIERhdGUiIGZpZWxkIGluIHVzZXIgZGF0YWJh c2VzLiA8YnI+WWV0LCBpdCBhbHNvIGFwcGVhcnMgdGhpcyBtZWFucyB0aGlzIGlzIG1vcmUgb2Yg YSAxIHRvIE1hbnkgbXVsdGlwbGUgPGJyPmRlZmluaXRpb24gZmllbGQgLS0gb25lIGZvciBlYWNo IHBvdGVudGlhbCBSUlZTIGNsaWVudCBzZW5kaW5nIG1haWwgdG8gPGJyPmEgdXNlciBidXQgZWFj aCBoYXMgdGhlaXIgb3duIGlkZWEgZm9yIHdoYXQgdGhpcyB0aW1lIGlzLiZuYnNwOyBUaGlzIG1l YW5zIDxicj50aGF0IGEgU0VOREVSIERPTUFJTiBmaWVsZCBtYXkgbmVlZCB0byBiZSBhZGRlZCBh cyB3ZWxsPGJyPjxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgT3duZXJTaGlwRGF0ZVRpbWUu RGF0ZVRpbWU8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE93bmVyU2hpcERhdGVUaW1lLlNl bmRlckRvbWFpbjxicj48YnI+T3ZlcmFsbCwgdGhpcyBzbWVsbHMsIHdhbGtzIGFuZCB0YWxrcyBh bGwgbGlrZSBhbiBleHBlcmltZW50YXRpb24uJm5ic3A7IFdlIDxicj5zaG91bGQgc2xvdyBkb3du IG9uIGxhYmVsaW5nIGV2ZXJ5dGhpbmcgdGhhdCBjb21lcyBvdXQgb2YgaGVyZSBhcyBhIDxicj4i UHJvcG9zZWQgU3RhbmRhcmQiIHdoZW4gdGhlcmUgaGFzbid0IGJlZW4gYW55IGxvbmcgdGVybSwg bXVsdGlwbGUgPGJyPnZlbmRvcnMgUiZhbXA7RCBkb25lLjxicj48YnI+SSBzdWdnZXN0LCBjaGFu Z2UgdGhpcyB0byBhIGV4cGVyaW1lbnRhbCBzdGF0dXMgYW5kIGxldCBZYWhvbyBhbmQgPGJyPkZh Y2Vib29rIHdvcmsgb3V0IHRoZSBkZXRhaWxzIG9mIHRoaXMgImV4cGVyaW1lbnQiIGFzIGZhciBh cyB3aGF0IHRoaXMgPGJyPlJSVlMgVElNRSBmaWVsZCBpcyBhbmQgY29tZSBiYWNrIGluIGEgZmV3 IHllYXIgYW5kIGxldCB1cyBrbm93IGhvdyBpdCA8YnI+d29ya2VkIG91dC4mbmJzcDsgSSB0aGlu ayBvbmNlIHRoZSBSUlZTIGZpZWxkIGlzIGRlZmluZWQsIHdlIG1pZ2h0IHNlZSBhIDxicj5oaWdo ZXIgcG90ZW50aWFsIGZvciBhZG9wdGlvbiBhbmQgcmVzdCBhc3N1cmVkLCB0aGlzIGlzIG9uZSBp ZGVhIHRoYXQgPGJyPmNhbiBhcHBseSBhY3Jvc3MgYWxsIG1hcmtldCBzZWdtZW50cywgbm90IGp1 c3QgdGhlIGJpZyBndXlzLjxicj48YnI+LS0gPGJyPkhMUzxicj48YnI+PGJyPjwvYm9keT4= ----_com.android.email_191249632264480-- From dhc@dcrocker.net Thu Dec 26 14:17:39 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5DBB1AE08F; Thu, 26 Dec 2013 14:17:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QRmzdkc1GBRw; Thu, 26 Dec 2013 14:17:37 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7FEE61AE075; Thu, 26 Dec 2013 14:17:37 -0800 (PST) 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 rBQMHR78026924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 26 Dec 2013 14:17:31 -0800 Message-ID: <52BCAA9B.60902@dcrocker.net> Date: Thu, 26 Dec 2013 14:15:55 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" , Eric Burger References: <4EC11DC5-BBB4-47FD-A10B-D9CA71ECFFBF@standardstrack.com> <90686C7B-5484-47AC-A595-28450C89E00F@standardstrack.com> 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]); Thu, 26 Dec 2013 14:17:31 -0800 (PST) Cc: draft-ietf-appsawg-rrvs-header-field.all@tools.ietf.org, The IESG , IETF Apps Discuss Subject: Re: [apps-discuss] Applications Area Review of draft-ietf-appsawg-rrvs-header-field-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Dec 2013 22:17:39 -0000 On 12/24/2013 10:31 PM, Murray S. Kucherawy wrote: > RRVS also has limitations that don't affect S/MIME and PGP, namely the > impacts of forwarding. I believe that the document already discusses > those issues sufficiently, however. This sort of discussion can confused about the precise actions and actors that are meant. So, I'll highlight that the sequence being referred to above is relaying, not forwarding. Per RFC 5598, forwarding is one of the things that can happen after delivery when (a version of) the original message is re-posted. RRVS should work transparently for relaying -- assuming the SMTP enforcement mechanism is either not used or is successful -- but as noted, delivery should terminate it. (As for whether s/mime or pgp sigs survive forwarding, well...) And if I've gotten this bit of clarification wrong, well that nicely demonstrates that my concern about accuracy on the term is valid... On 12/26/2013 8:59 AM, Hector Santos wrote:> > 1) The unclear, "non-standard" definition of what the RRVS "time" is, I haven't seen discussion or agreement that it's using a non-standard definition, especially since it specifically cites RFC5322's definition of . What is the basis for the assertion of a non-standard definition? > 2) Its potential for inconsistent usage, The arguments put forward here, concerning non-standard usage, apply to all protocols, and to none. In effect, the logic being attempted, to disallow standardization, means that no new protocol ever qualifies for standards track. Stated differently: Every new protocol has a degree of risk that it will fail. Yet we choose to place them on standards track. So this criterion, as offered, clearly does not disqualify RRVS. > 3) The high risk of user data exposure here, a Pandora Box consideration, The real irony to this claim is that the mechanism has been developed in order to /reduce/ mis-delivery and hence reduce the likelihood of inappropriate user data exposure. > 4) The risk of still sending and received unsecured messages, I don't even know what this one means. > 5) No one is using this yet across the board, not in production mode > yet, that I am aware of, etc. Ahh, so indeed we should not standardize anything until after it has achieved widespread use. That might be a worthy topic of discussion, but it would constitute an IETF-wide policy change and hence is not reasonable for disallowing standardization of the current specification, given current IETF common policies. > This all sounds like an EXPERIMENT, not a standard track item. Sorry, no it doesn't. Experimental status is for the purpose of understanding a protocol that might not be well enough understood, yet, or with exploring its possible dangers. Neither is at issue here. Given the above, I can't tell what Eric's "Agreed" response means or why he issued it. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From mnot@mnot.net Thu Dec 26 15:25:44 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 880021AE2E3; Thu, 26 Dec 2013 15:25:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RY8Tpw_5rpUZ; Thu, 26 Dec 2013 15:25:42 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 6B2971AE2DB; Thu, 26 Dec 2013 15:25:33 -0800 (PST) Received: from [192.168.1.57] (unknown [118.209.180.17]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 0BCA322E2C9; Thu, 26 Dec 2013 18:25:16 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Mark Nottingham In-Reply-To: <4EC11DC5-BBB4-47FD-A10B-D9CA71ECFFBF@standardstrack.com> Date: Fri, 27 Dec 2013 10:25:10 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4EC11DC5-BBB4-47FD-A10B-D9CA71ECFFBF@standardstrack.com> To: Eric Burger X-Mailer: Apple Mail (2.1822) Cc: draft-ietf-appsawg-rrvs-header-field.all@tools.ietf.org, The IESG , IETF Apps Discuss Subject: Re: [apps-discuss] Applications Area Review of draft-ietf-appsawg-rrvs-header-field-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Dec 2013 23:25:44 -0000 On 24 Dec 2013, at 5:29 am, Eric Burger = wrote: > While this mechanism is not as bad as the ill-fated recall message = mechanism, it shares the same characteristic. Namely, this extension is = at best a request. =85which makes me wonder why a header field name beginning in =93Require-=93= was chosen, instead of (for example) =93Request-=93. Even with such a warning in the spec, people=92s understanding of the = header field is going to be (at a minimum) hugely influenced by its = name, and the implication that it can =93require=94 any kind of = behaviour is not a good start. Cheers, -- Mark Nottingham http://www.mnot.net/ From ned.freed@mrochek.com Thu Dec 26 18:08:04 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 133FD1AE6EF; Thu, 26 Dec 2013 18:08:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.04 X-Spam-Level: X-Spam-Status: No, score=-1.04 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YAZuUTA1U0YZ; Thu, 26 Dec 2013 18:08:01 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id A92761AE0EF; Thu, 26 Dec 2013 18:08:01 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P2EZA6B28W001AVZ@mauve.mrochek.com>; Thu, 26 Dec 2013 18:03:12 -0800 (PST) MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=iso-8859-1; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P23NF74JFK0000AS@mauve.mrochek.com>; Thu, 26 Dec 2013 18:03:05 -0800 (PST) Message-id: <01P2EZA2CZDA0000AS@mauve.mrochek.com> Date: Thu, 26 Dec 2013 15:10:57 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Thu, 26 Dec 2013 14:15:55 -0800" <52BCAA9B.60902@dcrocker.net> References: <4EC11DC5-BBB4-47FD-A10B-D9CA71ECFFBF@standardstrack.com> <90686C7B-5484-47AC-A595-28450C89E00F@standardstrack.com> <52BCAA9B.60902@dcrocker.net> To: Dave Crocker Cc: IETF Apps Discuss , draft-ietf-appsawg-rrvs-header-field.all@tools.ietf.org, The IESG Subject: Re: [apps-discuss] Applications Area Review of draft-ietf-appsawg-rrvs-header-field-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Dec 2013 02:08:04 -0000 > On 12/24/2013 10:31 PM, Murray S. Kucherawy wrote: > > RRVS also has limitations that don't affect S/MIME and PGP, namely the > > impacts of forwarding. I believe that the document already discusses > > those issues sufficiently, however. > This sort of discussion can confused about the precise actions and > actors that are meant. So, I'll highlight that the sequence being > referred to above is relaying, not forwarding. > Per RFC 5598, forwarding is one of the things that can happen after > delivery when (a version of) the original message is re-posted. > RRVS should work transparently for relaying -- assuming the SMTP > enforcement mechanism is either not used or is successful -- but as > noted, delivery should terminate it. (As for whether s/mime or pgp sigs > survive forwarding, well...) > And if I've gotten this bit of clarification wrong, well that nicely > demonstrates that my concern about accuracy on the term is valid... This looks correct to me. > On 12/26/2013 8:59 AM, Hector Santos wrote:> > > 1) The unclear, "non-standard" definition of what the RRVS "time" is, > I haven't seen discussion or agreement that it's using a non-standard > definition, especially since it specifically cites RFC5322's definition > of . > What is the basis for the assertion of a non-standard definition? I'm not entirely clear on what's being claimed here either, but I think it has to do with semantics and not syntax. Specifically, I think the complaint is basically that the document does not describe how to map from account provisioning to the valid-since time value this extension requires in order to function. If I'm correct in this, then my position is that the document already provides sufficient information about the semantics that are needed, and it is neither appropriate nor, frankly, possible to get into how such information can or will be generated from whatever account data is available in a given environment. For example, it's possible for user accounts to be keyed to a username rather than an email address, for the account data to only contain the date when the user name was assigned and not the date when the current email address was attached to the account. In such cases it won't be possible to emit correct valid-since information, because the account could be much older than the current address assignment. Or consider the case on the receiving end of a corporate role account like vp-sales@corp.com. Of course such addresses should not be used when setting up personal vendor accounts, but rest assured people are going to do it anyway. When the assignment of such addresses change from one person to another, the only sensible thing for the corp.com to do is not to update the associated valid-since date (even if the actual underlying account does change) since continuity of receiving corporate communications is far more important than the privacy exposure of the previous holder of the address. These variations and doubtless many others are going to crop up out in the field, depending on how accounts are provisioned and managed. However, it is neither our responsibility nor our area of expertise to plumb the depths of the provisioning swamp. So once we've described the needed semantics - which flow directly from the intended purpose of the extension in any case - we're done. > > 2) Its potential for inconsistent usage, > The arguments put forward here, concerning non-standard usage, apply to > all protocols, and to none. In effect, the logic being attempted, to > disallow standardization, means that no new protocol ever qualifies for > standards track. > Stated differently: Every new protocol has a degree of risk that it > will fail. Yet we choose to place them on standards track. So this > criterion, as offered, clearly does not disqualify RRVS. Quite true and nicely stated. > > 3) The high risk of user data exposure here, a Pandora Box consideration, > The real irony to this claim is that the mechanism has been developed in > order to /reduce/ mis-delivery and hence reduce the likelihood of > inappropriate user data exposure. Exactly. And paying a price for this ability is inherent in the store-and-forward nature of email: Valid-since information has to be attached to the messages that are sent in some way, and once that information is there is always the chance that it will leak. Using the extension rather than the header mitigates this, but the clear consensus is to retain the header mechanism. > > 4) The risk of still sending and received unsecured messages, > I don't even know what this one means. Neither do I. > > 5) No one is using this yet across the board, not in production mode > > yet, that I am aware of, etc. > Ahh, so indeed we should not standardize anything until after it has > achieved widespread use. That might be a worthy topic of discussion, > but it would constitute an IETF-wide policy change and hence is not > reasonable for disallowing standardization of the current specification, > given current IETF common policies. In point of fact support for the header variant is already deployed by some large MSPs. But as you say, this is for the most part irreelevant. > > This all sounds like an EXPERIMENT, not a standard track item. > Sorry, no it doesn't. > Experimental status is for the purpose of understanding a protocol that > might not be well enough understood, yet, or with exploring its possible > dangers. Neither is at issue here. Agreed. Ned From superuser@gmail.com Thu Dec 26 20:03:21 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F77A1AE988; Thu, 26 Dec 2013 20:03:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S09ASmoQnjmm; Thu, 26 Dec 2013 20:03:19 -0800 (PST) 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 8C5181AE98B; Thu, 26 Dec 2013 20:03:18 -0800 (PST) Received: by mail-we0-f179.google.com with SMTP id q59so7658420wes.24 for ; Thu, 26 Dec 2013 20:03:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TbZSj5N7gW3OiLrxGVMXfk0Y3u1D5ZX2GXgqFwGFdZM=; b=0pDoKHNQ5hgGeYgfnODpelvJfoiFGYIj0hS8ppwROliguVIZsoJ7C880YgtEjdWsp3 2ZHLkAUPiLD9pILmdJqYOckWpQ3Jz4Lb5XL28l1GRxjn6L+n72zFAROWp0busfxnFyHP z8Gb+7HSykNc0uaMtfFw9yxFJtjhpZ7360v0NPw8j9ONCClCUXzbsAx5mvs4RlmX2z4j VhERKZt/oJpsFbWwY9KrgI2dzIAdDcQ3LAKaK6bZaQpdiUJedoyIfHChcN4YQSX88WRt u38HQhGcAr/edk1Wtk+C6uU0AyEZcmNgty1eKbc0xx34FmXmKnZvg6txLP6IrIqCrEW9 NUHA== MIME-Version: 1.0 X-Received: by 10.180.187.72 with SMTP id fq8mr31655492wic.26.1388116993520; Thu, 26 Dec 2013 20:03:13 -0800 (PST) Received: by 10.180.84.106 with HTTP; Thu, 26 Dec 2013 20:03:13 -0800 (PST) In-Reply-To: <52BC6076.6010202@isdg.net> References: <4EC11DC5-BBB4-47FD-A10B-D9CA71ECFFBF@standardstrack.com> <90686C7B-5484-47AC-A595-28450C89E00F@standardstrack.com> <52BC6076.6010202@isdg.net> Date: Thu, 26 Dec 2013 20:03:13 -0800 Message-ID: From: "Murray S. Kucherawy" To: Hector Santos Content-Type: multipart/alternative; boundary=001a11c2679c4e38f104ee7c2c3c Cc: IETF Apps Discuss , draft-ietf-appsawg-rrvs-header-field.all@tools.ietf.org, The IESG Subject: Re: [apps-discuss] Applications Area Review of draft-ietf-appsawg-rrvs-header-field-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Dec 2013 04:03:21 -0000 --001a11c2679c4e38f104ee7c2c3c Content-Type: text/plain; charset=ISO-8859-1 On Thu, Dec 26, 2013 at 8:59 AM, Hector Santos wrote: > > This all sounds like an EXPERIMENT, not a standard track item. It could > be an INFORMATIONAL document at this time and probably better to be > describing a problem looking for a solution. I am not sure the RRVS is it. > This is currently an experimentation with a very high potential of being > only used for exclusive relationships, i.e. a joint venture (Yahoo and > Facebook) with a technology transfer of information to better synchronized > heterogeneous user databases. To do this in a standard way, the RRVS time > has to be better defined. It is not. > > [...] > Dave and Ned have nicely handled this point-by-point already, but I'll reply more generally by noting that the definition of Proposed Standard in RFC2026 (specifically, Section 4.1.1) allows for something that is relatively young but has significant interest and likely utility. There's a reason we call it "Proposed". I also believe the amount of discussion and contributions that support the work, and the fact that independent implementations exist -- which, in fact, influenced the document's current content -- indicate that it qualifies. The remainder of this message repeated the previous claim that the timestamp involved in the protocol is ill-defined, but I think Ned has re-stated my previous (and unacknowledged) answer to that point, so I don't have anything to add there. -MSK --001a11c2679c4e38f104ee7c2c3c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Dec 26, 2013 at 8:59 AM, Hector Santos <hsantos@= isdg.net> wrote:

This all sounds like an EXPERIMENT, not a standard track item. =A0It could = be an INFORMATIONAL document at this time and probably better to be describ= ing a problem looking for a solution. I am not sure the RRVS is it. =A0This= is currently an experimentation with a very high potential of being only u= sed for exclusive relationships, i.e. a joint venture (Yahoo and Facebook) = with a technology transfer of information to better synchronized heterogene= ous user databases. =A0 To do this in a standard way, the RRVS time has to = be better defined. It is not.

[...]

Dave and Ned have nicely hand= led this point-by-point already, but I'll reply more generally by notin= g that the definition of Proposed Standard in RFC2026 (specifically, Sectio= n 4.1.1) allows for something that is relatively young but has significant = interest and likely utility.=A0 There's a reason we call it "Propo= sed".=A0 I also believe the amount of discussion and contributions tha= t support the work, and the fact that independent implementations exist -- = which, in fact, influenced the document's current content -- indicate t= hat it qualifies.

The remainder of this message repeated the previous claim that th= e timestamp involved in the protocol is ill-defined, but I think Ned has re= -stated my previous (and unacknowledged) answer to that point, so I don'= ;t have anything to add there.

-MSK
--001a11c2679c4e38f104ee7c2c3c-- From duerst@it.aoyama.ac.jp Fri Dec 27 02:28:25 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 684381AE0DA for ; Fri, 27 Dec 2013 02:28:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.771 X-Spam-Level: X-Spam-Status: No, score=0.771 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KECG01C8w8cj for ; Fri, 27 Dec 2013 02:28:22 -0800 (PST) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 9BC9C1ADF66 for ; Fri, 27 Dec 2013 02:28:21 -0800 (PST) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id rBRAS8ns024889; Fri, 27 Dec 2013 19:28:08 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 4c7d_7923_946a416c_6ee1_11e3_8656_001e6722eec2; Fri, 27 Dec 2013 19:28:08 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 0F155BFBD2; Fri, 27 Dec 2013 19:28:08 +0900 (JST) Message-ID: <52BD5629.4040306@it.aoyama.ac.jp> Date: Fri, 27 Dec 2013 19:27:53 +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: apps-discuss@ietf.org, draft-ietf-p2psip-self-tuning.all@tools.ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: [apps-discuss] [APPS-REVIEW] review of draft-ietf-p2psip-self-tuning-09 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Dec 2013 10:28:25 -0000 I have been selected as the Applications Area Review Team reviewer for=20 this draft (for background on apps-review, please see=20 http://www.apps.ietf.org/content/applications-area-review-team). Please resolve these comments along with any other Last Call comments=20 you may receive. Please wait for direction from your document shepherd=20 or AD before posting a new version of the draft. Document: draft-ietf-p2psip-self-tuning Title: Self-tuning Distributed Hash Table (DHT) for REsource LOcation=20 And Discovery (RELOAD) Reviewer: Martin J. D=C3=BCrst Review Date: December 27, 2013 IETF Last Call Date: not yet IESG Telechat Date: not yet Summary: From what I have read, this draft looks like it's almost ready=20 for publication in IETF Standards Track but has a few issues that should=20 be fixed before publication. However, I have to admit that I'm not a SIP=20 expert, nor an expert in P2P systems. Minor Issues: Section 2, definitions of O(g(n)) and Omega(g(n)): The informal=20 definitions are fine, but there should also be a reference to a more=20 formal definition. Definitions of "Predecessor List" and "Successor List": The former has=20 "first predecessors", whereas the later has "first *r* successors"=20 (emphasis by the reviewer). This may be an editorial issue, but it looks=20 to me like the *r* should be present for predecessors, too. Section 3.2, bottom of page 6 and top of page 7: First, the big-O and=20 big-Omega notation makes the base of the logarithm irrelevant, so it=20 should be O(log(N)) rather than O(log2(N)), and so on. But this shows=20 that statements such as "a successor list of size O(log2(N)) makes it=20 unlikely..." are actually flawed, because both a function 0.01*log2(N)=20 and a function 100*log2(N) would be O(log2(N)) (the constant multiple is=20 mentioned in the definitions of O() and Omega()), and I'm pretty sure=20 that with the former, connectivity will be lost quite soon, whereas the=20 later is most probably heavy overkill. The notation log2^2(N) is quite difficult to read. It's a logical=20 combination of the notations N^2 and log2(N), which are both not too=20 difficult to read, but in combination, the mental gymnastics required to=20 translate this to a 2D mathematical formula and then interpret are too=20 much. I'd strongly prefer a more functional notation, e.g.=20 square(log2(N)), which would be much more straightforward to read. This=20 would also work better together with the fact that there are parentheses=20 around the N, which wouldn't be needed in a 2D mathematical formula. Section 6.2: "the finger table MUST be set to max(log2(N), 16)": the finger table=20 size obviously must be integral, but log2(N) will rarely be integral,=20 and it is not clear what kind of rounding to apply. Same for the size of=20 the successor list. Section 6.4: In "Ages[rsize/2]", is the division an integer division=20 (rounding down) or what? Section 6.5, last paragraph: "75th percentile": This probably needs a=20 better definition. See http://en.wikipedia.org/wiki/Percentile, where it=20 says: "Definition: There is no standard definition of percentile,=20 however all definitions yield similar results when the number of=20 observations is very large.". In this draft, we will normally be in a=20 situation with very *few* observations, so a careful definition seems=20 required. Section 7: "This document extends the RELOAD overlay configuration document": It=20 would be good to have a reference here. Actually, I was specifically=20 asked to review this section, but I don't feel I'm able to do a good job=20 here because while I found quite a few references to "RELOAD overlay=20 configuration document *extensions*", I didn't easily find a good=20 reference to the base document. Section 8 (security): "In addition, as long as the amount of malicious peers in the overlay remains modest, the statistical mechanisms applied in Section 6.5 (i.e., the use of 75th percentiles) to process the shared estimates a peer obtains help ensuring that estimates that are clearly different from (i.e., larger or smaller than) other received estimates will not significantly influence the process of adapting the stabilization interval and routing table size." This seems good for the overall network, but it should be mentioned that=20 this is not the case locally. If an attacker wants to e.g. isolate a=20 specific node, it should not be too difficult to generate hashes to=20 place nodes in "strategic" locations on the ring to in effect isolate=20 and detach a specific node. Regards, Martin. From ned.freed@mrochek.com Fri Dec 27 06:42:36 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87B281AE1E0; Fri, 27 Dec 2013 06:42:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3VnWj61htzQX; Fri, 27 Dec 2013 06:42:35 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 160581AE1CE; Fri, 27 Dec 2013 06:42:35 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P2FPM9SO8G001BKV@mauve.mrochek.com>; Fri, 27 Dec 2013 06:37:26 -0800 (PST) MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=windows-1252 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P23NF74JFK0000AS@mauve.mrochek.com>; Fri, 27 Dec 2013 06:37:19 -0800 (PST) Message-id: <01P2FPM68CDW0000AS@mauve.mrochek.com> Date: Fri, 27 Dec 2013 06:29:18 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Fri, 27 Dec 2013 10:25:10 +1100" References: <4EC11DC5-BBB4-47FD-A10B-D9CA71ECFFBF@standardstrack.com> To: Mark Nottingham Cc: IETF Apps Discuss , draft-ietf-appsawg-rrvs-header-field.all@tools.ietf.org, The IESG Subject: Re: [apps-discuss] Applications Area Review of draft-ietf-appsawg-rrvs-header-field-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Dec 2013 14:42:36 -0000 > On 24 Dec 2013, at 5:29 am, Eric Burger wrote: > > While this mechanism is not as bad as the ill-fated recall message > > mechanism, it shares the same characteristic. Namely, this extension is at > > best a request. Not really. It's only a request in the sense that processing of all header fields is contingent on the field being recognized and processed. A compliant implementation will treat what the header says as a requirement that must be met for the message to be delivered. > …which makes me wonder why a header field name beginning in “Require-“ was > chosen, instead of (for example) “Request-“. Perhaps because it specifies a requirement? This is not to say that I think the field is well-named. It isn't, and in fact the entire thing should have been done as an SMTP extension only from the start. But given existing deployment along with the clear consensus to keep the header-based mechanism, changing the field name isn't a reasonable thing to do at this point. > Even with such a warning in the spec, people’s understanding of the header > field is going to be (at a minimum) hugely influenced by its name, and the > implication that it can “require” any kind of behaviour is not a good start. That's true only if those people are unaware of the essential semantics behind the use of header fields in email. And yes, that's a problem from time to time, but one that's far beyond the purview of this specification to try and solve. Ned From dhc@dcrocker.net Fri Dec 27 08:51:24 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 365D21ADF79; Fri, 27 Dec 2013 08:51:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a3PDSAUtU9RB; Fri, 27 Dec 2013 08:51:22 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2EC241AE227; Fri, 27 Dec 2013 08:51:22 -0800 (PST) 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 rBRGpDAr018018 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 27 Dec 2013 08:51:16 -0800 Message-ID: <52BDAFAD.9000800@dcrocker.net> Date: Fri, 27 Dec 2013 08:49:49 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Ned Freed , Mark Nottingham References: <4EC11DC5-BBB4-47FD-A10B-D9CA71ECFFBF@standardstrack.com> <01P2FPM68CDW0000AS@mauve.mrochek.com> In-Reply-To: <01P2FPM68CDW0000AS@mauve.mrochek.com> Content-Type: text/plain; charset=windows-1252; 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]); Fri, 27 Dec 2013 08:51:17 -0800 (PST) Cc: draft-ietf-appsawg-rrvs-header-field.all@tools.ietf.org, The IESG , IETF Apps Discuss Subject: [apps-discuss] Scope of protocol authority (was Re: Applications Area Review of draft-ietf-appsawg-rrvs-header-field-05) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Dec 2013 16:51:24 -0000 On 12/27/2013 6:29 AM, Ned Freed wrote: > >> On 24 Dec 2013, at 5:29 am, Eric Burger wrote: > >>> While this mechanism is not as bad as the ill-fated recall message >>> mechanism, it shares the same characteristic. Namely, this extension is at >>> best a request. > > Not really. It's only a request in the sense that processing of all header > fields is contingent on the field being recognized and processed. A compliant > implementation will treat what the header says as a requirement that must be > met for the message to be delivered. While the above is of course correct, I think there can be two legitimate bases for distinguishing 'request' from 'requirement' within a protocol specification, and I think this is one of them: The first basis is when the issuer is sending blind. Most protocols contain an opening sequence which includes the semantic: both/all agents agree to participate in the sandbox covered by the protocol specification. After that, it's reasonable to have one side impose a 'requirement' on the other, if that's what the protocol spec asserts. However in some protocols, the issuer is sending things in the blind; it has no information that the receiver is playing in the sandbox of the protocol. In such cases, the issuer can only send a 'request'. In effect, what is sent combines two bits of semantics, the first is the opening "please play in this protocol sandbox" and the second is 'if you are playing in the sandbox, here's an action I want done." For the current specification, the two bits are separated, when the SMTP extension is used. The point behind having things implemented in the SMTP infrastructure is to first confirm that the recipient is playing in the sandbox and then enforce -- rather than request -- the semantics of addressee confirmation. So when the SMTP extension is used, the issuer sends a 'requirement' rather than a 'request'. When only the header field is used, it is only a 'request', because there is no step of first confirming that the receiver supports the protocol. The second basis for making the distinction is within a protocol. Here, the semantics of the protocol might be that the issuer really is only making a request, or really is issuing a requirement. It depends entirely on what the specification asserts. What is important here, therefore, is that specification writers be very clear about the distinction, both in making the choice and in explaining it. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From eburger@standardstrack.com Fri Dec 27 09:12:26 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A6FB1AE23B; Fri, 27 Dec 2013 09:12:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.578 X-Spam-Level: * X-Spam-Status: No, score=1.578 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cXn78LVwumRu; Fri, 27 Dec 2013 09:12:24 -0800 (PST) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) by ietfa.amsl.com (Postfix) with ESMTP id 9713C1AE237; Fri, 27 Dec 2013 09:12:24 -0800 (PST) Received: from 152.sub-70-215-24.myvzw.com ([70.215.24.152]:3482 helo=[192.168.43.132]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1VwaxE-0008Vm-8q; Fri, 27 Dec 2013 09:12:14 -0800 Content-Type: multipart/signed; boundary="Apple-Mail=_7D26B162-ABE4-4723-B243-C8E1875285D9"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Eric Burger In-Reply-To: <52BDAFAD.9000800@dcrocker.net> Date: Fri, 27 Dec 2013 12:10:31 -0500 Message-Id: <57C0DC48-18A7-4958-BBF2-7B2A34B156B3@standardstrack.com> References: <4EC11DC5-BBB4-47FD-A10B-D9CA71ECFFBF@standardstrack.com> <01P2FPM68CDW0000AS@mauve.mrochek.com> <52BDAFAD.9000800@dcrocker.net> To: draft-ietf-appsawg-rrvs-header-field.all@tools.ietf.org X-Mailer: Apple Mail (2.1827) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Cc: The IESG , IETF Apps Discuss Subject: [apps-discuss] Back to draft-ietf-appsawg-rrvs-header-field-05 (was Re: Scope of protocol authority) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Dec 2013 17:12:26 -0000 --Apple-Mail=_7D26B162-ABE4-4723-B243-C8E1875285D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 This hits on the request vs. requirement. I like Dave=92s distinction: if I talk with you and you agree to = supporting X, then I can reasonably =91require=92 you to do something in = the scope of X. If I just send you something without =91knowing=92 (via negotiation, = contractual understanding, etc.) that you support X, then I can only = reasonably =91request=92 you to do something in the scope of X. Unfortunately for RRVS, as it is currently specified, it is a request, = not a requirement. Even with the SMTP extension, unless the normative = behavior is to fail if the next MTA or final MUA does not support RRVS, = the present MTA cannot guarantee the delivery chain will support RRVS. = Therefore, it is only a request. As for the folks with this implemented, there is nothing to fear =97 how = many MUA=92a are more than two MTA=92s away from the sending MUA? = Especially since we are talking banks sending messages to = gmail/hotmail/Yahoo!Mail/etc., I do not think anything would break to = make the Require a real require. That is, fail if one or more MTA=92s do = not support the RRVS extension. This also has the nice side effect of = making the header, corner cases which makes up almost a quarter the = draft, by the way, obsolete. If you are really worried about the bank=92s Submit server talking to an = MTA that does not support RRVS but the next MTA does support RRVS, then = call it a Request and be done with it. On Dec 27, 2013, at 11:49 AM, Dave Crocker wrote: > On 12/27/2013 6:29 AM, Ned Freed wrote: >>=20 >>> On 24 Dec 2013, at 5:29 am, Eric Burger = wrote: >>=20 >>>> While this mechanism is not as bad as the ill-fated recall message >>>> mechanism, it shares the same characteristic. Namely, this = extension is at >>>> best a request. >>=20 >> Not really. It's only a request in the sense that processing of all = header >> fields is contingent on the field being recognized and processed. A = compliant >> implementation will treat what the header says as a requirement that = must be >> met for the message to be delivered. >=20 >=20 > While the above is of course correct, I think there can be two = legitimate bases for distinguishing 'request' from 'requirement' within = a protocol specification, and I think this is one of them: >=20 > The first basis is when the issuer is sending blind. >=20 > Most protocols contain an opening sequence which includes the = semantic: both/all agents agree to participate in the sandbox covered by = the protocol specification. After that, it's reasonable to have one = side impose a 'requirement' on the other, if that's what the protocol = spec asserts. >=20 > However in some protocols, the issuer is sending things in the blind; = it has no information that the receiver is playing in the sandbox of the = protocol. In such cases, the issuer can only send a 'request'. In = effect, what is sent combines two bits of semantics, the first is the = opening "please play in this protocol sandbox" and the second is 'if you = are playing in the sandbox, here's an action I want done." >=20 > For the current specification, the two bits are separated, when the = SMTP extension is used. The point behind having things implemented in = the SMTP infrastructure is to first confirm that the recipient is = playing in the sandbox and then enforce -- rather than request -- the = semantics of addressee confirmation. So when the SMTP extension is = used, the issuer sends a 'requirement' rather than a 'request'. >=20 > When only the header field is used, it is only a 'request', because = there is no step of first confirming that the receiver supports the = protocol. >=20 > The second basis for making the distinction is within a protocol. >=20 > Here, the semantics of the protocol might be that the issuer really is = only making a request, or really is issuing a requirement. It depends = entirely on what the specification asserts. What is important here, = therefore, is that specification writers be very clear about the = distinction, both in making the choice and in explaining it. >=20 >=20 > d/ >=20 > --=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss --Apple-Mail=_7D26B162-ABE4-4723-B243-C8E1875285D9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJSvbSIAAoJEDY/T2tCIPW3mokP/1MEWdiUVqOqxn5HsqGCyBmy pu1tcnT3KCz9RQW3hCw5ZmSiezrI3QwAH2M2S03HQz8P1lUASAwaxDfNP2kMqfkd JrTWPx0vKZ/W4tUhs6scbvwZdJnYk/EFxh76FLXqLCjocblrlk1YGpIhxBmOrUqz 1cYWwSUZWnDKjOLbesvSkk18xY0Sm19G9NymTAQURU7kmBYaDQjAUNsFvTJec4CO LK7Q66A4pk7gCY1RfPds/D6em7zgx9ZHf2u5Qa59MTvh5VoT2ySMEQMMwQcj+9Yj ceDtakEEaqtG8mJFPoCFyNujdxPbDpeHQsxEdoA11xWGPw8aXbQuSesoi50x65EB 30W/PYAwtjzlG6LThIK5xmotzgdlsF6rf+RMdMXhTf4LOMNer1uoK8oVkENH4HTX qkGoDvvjlv0ytIu89plkJaTFdb7Sq8Qbdl3pz6nWTdTy1KnPUl3lbrqjY3VaPbsH aycVmmjjMoj9jrQ3M1JcoeLhHw224CQmWOelP3viH/RD7REXA56/pUHrVO2ffvgK 5mv4W8ULfhmA+YJVOQsb6OQGp4P6rFhiB1IkIFcT32slpNKxj/khVfb4xTiCh/6/ uDb7heLw6fuEfzmR7tDJ+8EY6U3GjKO/CYcMUJ35ej4dvluKPSnOv7S7y7+xHcgn KmU4bG1NJPqmTNkZrSDu =JtKC -----END PGP SIGNATURE----- --Apple-Mail=_7D26B162-ABE4-4723-B243-C8E1875285D9-- From dhc@dcrocker.net Fri Dec 27 09:34:03 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB88A1AE23B; Fri, 27 Dec 2013 09:34:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jy_6nYaW9Zu0; Fri, 27 Dec 2013 09:34:01 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id BDA961AE225; Fri, 27 Dec 2013 09:34:01 -0800 (PST) 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 rBRHXrbq018619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 27 Dec 2013 09:33:56 -0800 Message-ID: <52BDB9AD.9060504@dcrocker.net> Date: Fri, 27 Dec 2013 09:32:29 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Eric Burger , draft-ietf-appsawg-rrvs-header-field.all@tools.ietf.org References: <4EC11DC5-BBB4-47FD-A10B-D9CA71ECFFBF@standardstrack.com> <01P2FPM68CDW0000AS@mauve.mrochek.com> <52BDAFAD.9000800@dcrocker.net> <57C0DC48-18A7-4958-BBF2-7B2A34B156B3@standardstrack.com> In-Reply-To: <57C0DC48-18A7-4958-BBF2-7B2A34B156B3@standardstrack.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Fri, 27 Dec 2013 09:33:57 -0800 (PST) Cc: The IESG , IETF Apps Discuss Subject: Re: [apps-discuss] Back to draft-ietf-appsawg-rrvs-header-field-05 (was Re: Scope of protocol authority) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Dec 2013 17:34:04 -0000 On 12/27/2013 9:10 AM, Eric Burger wrote: > As for the folks with this implemented, there is nothing to fear — how many MUA’a are more than two MTA’s away from the sending MUA? Probably quite a bit of b2b mail. Any enterprise with department-level servers introduces larger numbers of MTAs. Even without 'department' servers, large organizations often distinguish internal mail handling from external, so that mail starts with an internal-facing MTA and exits through an external-facing MTA.[*] There is a continuing myth that all Internet mail is now 'direct', but while it's true for a large amount of mail, it's also not true for a large amount. d/ [*] By way of example -- Although I did have to search through the archive a bit, I did finally find an example on the apps-discuss mailing list of author-side, multi-MTA handling before a message hit the open Internet. -- Dave Crocker Brandenburg InternetWorking bbiw.net From eburger@standardstrack.com Fri Dec 27 10:12:52 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A653B1AE248; Fri, 27 Dec 2013 10:12:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.08 X-Spam-Level: ** X-Spam-Status: No, score=2.08 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, HTML_NONELEMENT_30_40=0.001, MIME_BAD_LINEBREAK=0.5, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P5S6F7ZdXu1V; Fri, 27 Dec 2013 10:12:51 -0800 (PST) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) by ietfa.amsl.com (Postfix) with ESMTP id 224421ADFAB; Fri, 27 Dec 2013 10:12:51 -0800 (PST) Received: from 152.sub-70-215-24.myvzw.com ([70.215.24.152]:3468 helo=[10.185.172.72]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.80.1) (envelope-from ) id 1Vwbtk-0001HW-2S; Fri, 27 Dec 2013 10:12:40 -0800 Date: Fri, 27 Dec 2013 13:12:33 -0500 Message-ID: <4gxam5m356qoma0o80r13rpp.1388167953685@email.android.com> Importance: normal From: Eric Burger To: Dave Crocker , draft-ietf-appsawg-rrvs-header-field.all@tools.ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.android.email_783165585763040" X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Cc: The IESG , IETF Apps Discuss Subject: Re: [apps-discuss] Back to draft-ietf-appsawg-rrvs-header-field-05 (was Re: Scope of protocol authority) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Dec 2013 18:12:52 -0000 ----_com.android.email_783165585763040 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 WWVzLCBhbmQgbG9vayBhdCB0aGUgdXNlIGNhc2UuIElmIHlvdSBhcmUgdGhlIGVudGVycHJpc2Ug c2VuZGluZyB0aGUgbWVzc2FnZSwgeW91IHdpbGwgdXBncmFkZSBhbGwgdGhlIE1UQXMgdW5kZXIg eW91ciBjb250cm9sLiBJZiB5b3UgYXJlIHRoZSBtYXNzaXZlLCBwdWJsaWMgTVNQIGFkdmVydGlz aW5nIFJSVlMgb24gdGhlIHJlY2VpdmluZyBzaWRlLCDCoG5vdCBhIHByb2JsZW0uwqAKCklmIGl0 IGlzIGIyYiwgdGhlbiBhcyBOZWQgcG9pbnRlZCBvdXQsIGV2ZW4gaWYgeW91IGFyZSBzZW5kaW5n IHRvIGhyQGV4YW1wbGUuY29tLCB5b3UgbW9zdCBsaWtlbHkgZG9uJ3Qgd2FudCB0aGUgbGFzdCBv bmUuwqAKCgpTZW50IGZyb20gbXkgbW9iaWxlIGRldmljZS4gVGhhbmtzIGJlIHRvIExFTU9OQURF OiBodHRwOi8vd3d3LnN0YW5kYXJkc3RyYWNrLmNvbS9pZXRmL2xlbW9uYWRlClMyRVJDOiBodHRw Oi8vczJlcmMuZ2VvcmdldG93bi5lZHUvCkdDU0M6IGh0dHA6Ly9nY3NjLmdlb3JnZXRvd24uZWR1 LwpNZTogaHR0cDovL3d3dy5jcy5nZW9yZ2V0b3duLmVkdS9+IGVidXJnZXIKCi0tLS0tLS0tIE9y aWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS0KRnJvbTogRGF2ZSBDcm9ja2VyIDxkaGNAZGNyb2NrZXIu bmV0PiAKRGF0ZToxMi8yNy8yMDEzICAxMjozMiBQTSAgKEdNVC0wNTowMCkgClRvOiBFcmljIEJ1 cmdlciA8ZWJ1cmdlckBzdGFuZGFyZHN0cmFjay5jb20+LGRyYWZ0LWlldGYtYXBwc2F3Zy1ycnZz LWhlYWRlci1maWVsZC5hbGxAdG9vbHMuaWV0Zi5vcmcgCkNjOiBUaGUgSUVTRyA8aWVzZ0BpZXRm Lm9yZz4sSUVURiBBcHBzIERpc2N1c3MgPGFwcHMtZGlzY3Vzc0BpZXRmLm9yZz4gClN1YmplY3Q6 IFJlOiBbYXBwcy1kaXNjdXNzXSBCYWNrIHRvIGRyYWZ0LWlldGYtYXBwc2F3Zy1ycnZzLWhlYWRl ci1maWVsZC0wNQ0gICh3YXMgUmU6IFNjb3BlIG9mIHByb3RvY29sIGF1dGhvcml0eSkgCgpPbiAx Mi8yNy8yMDEzIDk6MTAgQU0sIEVyaWMgQnVyZ2VyIHdyb3RlOgo+IEFzIGZvciB0aGUgZm9sa3Mg d2l0aCB0aGlzIGltcGxlbWVudGVkLCB0aGVyZSBpcyBub3RoaW5nIHRvIGZlYXIg4oCUIGhvdyBt YW55IE1VQeKAmWEgYXJlIG1vcmUgdGhhbiB0d28gTVRB4oCZcyBhd2F5IGZyb20gdGhlIHNlbmRp bmcgTVVBPwoKClByb2JhYmx5IHF1aXRlIGEgYml0IG9mIGIyYiBtYWlsLgoKQW55IGVudGVycHJp c2Ugd2l0aCBkZXBhcnRtZW50LWxldmVsIHNlcnZlcnMgaW50cm9kdWNlcyBsYXJnZXIgbnVtYmVy cyAKb2YgTVRBcy7CoCBFdmVuIHdpdGhvdXQgJ2RlcGFydG1lbnQnIHNlcnZlcnMsIGxhcmdlIG9y Z2FuaXphdGlvbnMgb2Z0ZW4gCmRpc3Rpbmd1aXNoIGludGVybmFsIG1haWwgaGFuZGxpbmcgZnJv bSBleHRlcm5hbCwgc28gdGhhdCBtYWlsIHN0YXJ0cyAKd2l0aCBhbiBpbnRlcm5hbC1mYWNpbmcg TVRBIGFuZCBleGl0cyB0aHJvdWdoIGFuIGV4dGVybmFsLWZhY2luZyBNVEEuWypdCgpUaGVyZSBp cyBhIGNvbnRpbnVpbmcgbXl0aCB0aGF0IGFsbCBJbnRlcm5ldCBtYWlsIGlzIG5vdyAnZGlyZWN0 JywgYnV0IAp3aGlsZSBpdCdzIHRydWUgZm9yIGEgbGFyZ2UgYW1vdW50IG9mIG1haWwsIGl0J3Mg YWxzbyBub3QgdHJ1ZSBmb3IgYSAKbGFyZ2UgYW1vdW50LgoKZC8KClsqXSBCeSB3YXkgb2YgZXhh bXBsZSAtLSBBbHRob3VnaCBJIGRpZCBoYXZlIHRvIHNlYXJjaCB0aHJvdWdoIHRoZSAKYXJjaGl2 ZSBhIGJpdCwgSSBkaWQgZmluYWxseSBmaW5kIGFuIGV4YW1wbGUgb24gdGhlIGFwcHMtZGlzY3Vz cyBtYWlsaW5nIApsaXN0IG9mIGF1dGhvci1zaWRlLCBtdWx0aS1NVEEgaGFuZGxpbmcgYmVmb3Jl IGEgbWVzc2FnZSBoaXQgdGhlIG9wZW4gCkludGVybmV0LgoKLS0gCkRhdmUgQ3JvY2tlcgpCcmFu ZGVuYnVyZyBJbnRlcm5ldFdvcmtpbmcKYmJpdy5uZXQK ----_com.android.email_783165585763040 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSA+PGRpdj5ZZXMsIGFuZCBsb29rIGF0 IHRoZSB1c2UgY2FzZS4gSWYgeW91IGFyZSB0aGUgZW50ZXJwcmlzZSBzZW5kaW5nIHRoZSBtZXNz YWdlLCB5b3Ugd2lsbCB1cGdyYWRlIGFsbCB0aGUgTVRBcyB1bmRlciB5b3VyIGNvbnRyb2wuIElm IHlvdSBhcmUgdGhlIG1hc3NpdmUsIHB1YmxpYyBNU1AgYWR2ZXJ0aXNpbmcgUlJWUyBvbiB0aGUg cmVjZWl2aW5nIHNpZGUsICZuYnNwO25vdCBhIHByb2JsZW0uJm5ic3A7PC9kaXY+PGRpdj48YnI+ PC9kaXY+PGRpdj5JZiBpdCBpcyBiMmIsIHRoZW4gYXMgTmVkIHBvaW50ZWQgb3V0LCBldmVuIGlm IHlvdSBhcmUgc2VuZGluZyB0byBockBleGFtcGxlLmNvbSwgeW91IG1vc3QgbGlrZWx5IGRvbid0 IHdhbnQgdGhlIGxhc3Qgb25lLiZuYnNwOzwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwv ZGl2PlNlbnQgZnJvbSBteSBtb2JpbGUgZGV2aWNlLiBUaGFua3MgYmUgdG8gTEVNT05BREU6IGh0 dHA6Ly93d3cuc3RhbmRhcmRzdHJhY2suY29tL2lldGYvbGVtb25hZGU8ZGl2PlMyRVJDOiBodHRw Oi8vczJlcmMuZ2VvcmdldG93bi5lZHUvPC9kaXY+PGRpdj5HQ1NDOiBodHRwOi8vZ2NzYy5nZW9y Z2V0b3duLmVkdS88L2Rpdj48ZGl2Pk1lOiBodHRwOi8vd3d3LmNzLmdlb3JnZXRvd24uZWR1L34g ZWJ1cmdlcjwvZGl2Pjxicj48YnI+LS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLTxi cj5Gcm9tOiBEYXZlIENyb2NrZXIgPGRoY0BkY3JvY2tlci5uZXQ+IDxicj5EYXRlOjEyLzI3LzIw MTMgIDEyOjMyIFBNICAoR01ULTA1OjAwKSA8YnI+VG86IEVyaWMgQnVyZ2VyIDxlYnVyZ2VyQHN0 YW5kYXJkc3RyYWNrLmNvbT4sZHJhZnQtaWV0Zi1hcHBzYXdnLXJydnMtaGVhZGVyLWZpZWxkLmFs bEB0b29scy5pZXRmLm9yZyA8YnI+Q2M6IFRoZSBJRVNHIDxpZXNnQGlldGYub3JnPixJRVRGIEFw cHMgRGlzY3VzcyA8YXBwcy1kaXNjdXNzQGlldGYub3JnPiA8YnI+U3ViamVjdDogUmU6IFthcHBz LWRpc2N1c3NdIEJhY2sgdG8gZHJhZnQtaWV0Zi1hcHBzYXdnLXJydnMtaGVhZGVyLWZpZWxkLTA1 DSAgKHdhcyBSZTogU2NvcGUgb2YgcHJvdG9jb2wgYXV0aG9yaXR5KSA8YnI+PGJyPk9uIDEyLzI3 LzIwMTMgOToxMCBBTSwgRXJpYyBCdXJnZXIgd3JvdGU6PGJyPiZndDsgQXMgZm9yIHRoZSBmb2xr cyB3aXRoIHRoaXMgaW1wbGVtZW50ZWQsIHRoZXJlIGlzIG5vdGhpbmcgdG8gZmVhciDigJQgaG93 IG1hbnkgTVVB4oCZYSBhcmUgbW9yZSB0aGFuIHR3byBNVEHigJlzIGF3YXkgZnJvbSB0aGUgc2Vu ZGluZyBNVUE/PGJyPjxicj48YnI+UHJvYmFibHkgcXVpdGUgYSBiaXQgb2YgYjJiIG1haWwuPGJy Pjxicj5BbnkgZW50ZXJwcmlzZSB3aXRoIGRlcGFydG1lbnQtbGV2ZWwgc2VydmVycyBpbnRyb2R1 Y2VzIGxhcmdlciBudW1iZXJzIDxicj5vZiBNVEFzLiZuYnNwOyBFdmVuIHdpdGhvdXQgJ2RlcGFy dG1lbnQnIHNlcnZlcnMsIGxhcmdlIG9yZ2FuaXphdGlvbnMgb2Z0ZW4gPGJyPmRpc3Rpbmd1aXNo IGludGVybmFsIG1haWwgaGFuZGxpbmcgZnJvbSBleHRlcm5hbCwgc28gdGhhdCBtYWlsIHN0YXJ0 cyA8YnI+d2l0aCBhbiBpbnRlcm5hbC1mYWNpbmcgTVRBIGFuZCBleGl0cyB0aHJvdWdoIGFuIGV4 dGVybmFsLWZhY2luZyBNVEEuWypdPGJyPjxicj5UaGVyZSBpcyBhIGNvbnRpbnVpbmcgbXl0aCB0 aGF0IGFsbCBJbnRlcm5ldCBtYWlsIGlzIG5vdyAnZGlyZWN0JywgYnV0IDxicj53aGlsZSBpdCdz IHRydWUgZm9yIGEgbGFyZ2UgYW1vdW50IG9mIG1haWwsIGl0J3MgYWxzbyBub3QgdHJ1ZSBmb3Ig YSA8YnI+bGFyZ2UgYW1vdW50Ljxicj48YnI+ZC88YnI+PGJyPlsqXSBCeSB3YXkgb2YgZXhhbXBs ZSAtLSBBbHRob3VnaCBJIGRpZCBoYXZlIHRvIHNlYXJjaCB0aHJvdWdoIHRoZSA8YnI+YXJjaGl2 ZSBhIGJpdCwgSSBkaWQgZmluYWxseSBmaW5kIGFuIGV4YW1wbGUgb24gdGhlIGFwcHMtZGlzY3Vz cyBtYWlsaW5nIDxicj5saXN0IG9mIGF1dGhvci1zaWRlLCBtdWx0aS1NVEEgaGFuZGxpbmcgYmVm b3JlIGEgbWVzc2FnZSBoaXQgdGhlIG9wZW4gPGJyPkludGVybmV0Ljxicj48YnI+LS0gPGJyPkRh dmUgQ3JvY2tlcjxicj5CcmFuZGVuYnVyZyBJbnRlcm5ldFdvcmtpbmc8YnI+YmJpdy5uZXQ8YnI+ PC9ib2R5Pg== ----_com.android.email_783165585763040-- From ned.freed@mrochek.com Fri Dec 27 13:34:53 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 755101AE624; Fri, 27 Dec 2013 13:34:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.541 X-Spam-Level: X-Spam-Status: No, score=-0.541 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3bMUlQY7QoRe; Fri, 27 Dec 2013 13:34:51 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 6290F1AE623; Fri, 27 Dec 2013 13:34:51 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P2G41EJ3LC001BC8@mauve.mrochek.com>; Fri, 27 Dec 2013 13:29:41 -0800 (PST) MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=windows-1252 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P23NF74JFK0000AS@mauve.mrochek.com>; Fri, 27 Dec 2013 13:29:36 -0800 (PST) Message-id: <01P2G41BNC1I0000AS@mauve.mrochek.com> Date: Fri, 27 Dec 2013 10:42:56 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Fri, 27 Dec 2013 12:10:31 -0500" <57C0DC48-18A7-4958-BBF2-7B2A34B156B3@standardstrack.com> References: <4EC11DC5-BBB4-47FD-A10B-D9CA71ECFFBF@standardstrack.com> <01P2FPM68CDW0000AS@mauve.mrochek.com> <52BDAFAD.9000800@dcrocker.net> <57C0DC48-18A7-4958-BBF2-7B2A34B156B3@standardstrack.com> To: Eric Burger Cc: draft-ietf-appsawg-rrvs-header-field.all@tools.ietf.org, The IESG , IETF Apps Discuss Subject: Re: [apps-discuss] Back to draft-ietf-appsawg-rrvs-header-field-05 (was Re: Scope of protocol authority) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Dec 2013 21:34:53 -0000 > This hits on the request vs. requirement. Given the semantics you seem to be proposing, the latter is, with the exception of encrpytion schemes, pretty much an empty set. > I like Dave’s distinction: if I talk with you and you agree to supporting X, > then I can reasonably ‘require’ you to do something in the scope of X. No, not really, because interoperability trumps everything else in practice. If I have to offer an extension in order to get you to send me a message my users want to get, and I can't convince you to change your requirements, then that's exactly what I'm going to do. Even if I don't intend to actually conform to the extension in practice. Within the email world X.400 has proved to be the best example of this. Our implementation was forced to offer support of several extensions that we didn't actually support, because sending sites couldn't figure out how to turn them off. In some cases nobody involved had any idea what the extension even was. (Gotta love OID labels.) And similar things have happened in the SMTP world. There used to be (and probably still are) cases of the 8bitmime extension being offered with no actual support for it. Given this reality the distinction you and Dave are making becomes a lot less meaningful than you seem to think. > If I just send you something without ‘knowing’ (via negotiation, contractual > understanding, etc.) that you support X, then I can only reasonably ‘request’ > you to do something in the scope of X. > Unfortunately for RRVS, as it is currently specified, it is a request, not a > requirement. Even with the SMTP extension, unless the normative behavior is to > fail if the next MTA or final MUA does not support RRVS, the present MTA cannot > guarantee the delivery chain will support RRVS. Therefore, it is only a > request. Not quite. The document makes this a SHOULD. By your way of thinking that's more than a request, less than a requirement. > As for the folks with this implemented, there is nothing to fear — how many > MUA’a are more than two MTA’s away from the sending MU I know from direct persanal experience that number is easily in the hundreds of millions. Mind you, the number isn't that much higher than two in most cases, but it *is* higher than two. What you should have asserted here is that the number of ADMDs involved between submission and delivery is rarely more than two. And that is indeed an important observation, and why the extension makes sense. But since the number of MTAs involved is often larger it's also why it doesn't make sense to require transfer of RRVS information. The legitimate exceptions to the SHOULD I can think of all involve various permutations of inter-ADMD relay. Now, I suppose the language could be change to make not dropping the RRVS information a MUST when transitioning out of the ADMD. But as I noted previously, people are gonna do what they think is necessary, and so the criteria for inclusiong of such language isn't "loopholes are bad so let's close them all", but rather "this will actually aid implementators in knowing what to do". > A? Especially since we are talking banks sending messages to > gmail/hotmail/Yahoo!Mail/etc., I do not think anything would break to make the > Require a real require. That is, fail if one or more MTA’s do not support the > RRVS extension. This also has the nice side effect of making the header, corner > cases which makes up almost a quarter the draft, by the way, obsolete. As it happens this is how I implemented RRVS, but even so, I disagree. I think the SHOULD is appropriate here. > If you are really worried about the bank’s Submit server talking to an MTA > that does not support RRVS but the next MTA does support RRVS, then call it a > Request and be done with it. I really don't care about the labels, other than the header needs to remain unchanged for backwards compatibility despite the poor choice of name. Ned From duerst@it.aoyama.ac.jp Fri Dec 27 16:41:56 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8476A1AEA9D; Fri, 27 Dec 2013 16:41:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.929 X-Spam-Level: X-Spam-Status: No, score=-1.929 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dXWzm6CIQccM; Fri, 27 Dec 2013 16:41:54 -0800 (PST) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 420C51AE479; Fri, 27 Dec 2013 16:41:53 -0800 (PST) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id rBS0fWFi022531; Sat, 28 Dec 2013 09:41:33 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 7417_b5e4_cbf893f0_6f58_11e3_afc7_001e6722eec2; Sat, 28 Dec 2013 09:41:31 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 92AFEBF539; Sat, 28 Dec 2013 09:41:31 +0900 (JST) Message-ID: <52BE1E2C.5070405@it.aoyama.ac.jp> Date: Sat, 28 Dec 2013 09:41:16 +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: dcrocker@bbiw.net References: <4EC11DC5-BBB4-47FD-A10B-D9CA71ECFFBF@standardstrack.com> <01P2FPM68CDW0000AS@mauve.mrochek.com> <52BDAFAD.9000800@dcrocker.net> <57C0DC48-18A7-4958-BBF2-7B2A34B156B3@standardstrack.com> <52BDB9AD.9060504@dcrocker.net> In-Reply-To: <52BDB9AD.9060504@dcrocker.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF Apps Discuss , draft-ietf-appsawg-rrvs-header-field.all@tools.ietf.org, The IESG Subject: Re: [apps-discuss] Back to draft-ietf-appsawg-rrvs-header-field-05 (was Re: Scope of protocol authority) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Dec 2013 00:41:56 -0000 On 2013/12/28 2:32, Dave Crocker wrote: > [*] By way of example -- Although I did have to search through the > archive a bit, I did finally find an example on the apps-discuss mailing > list of author-side, multi-MTA handling before a message hit the open > Internet. Just look at mails from me. The way I counted, there were three or four MTAs on the way out (as well as on the way in, but you won't see that). I'm only tangentially involved in one of them, and not at all in the others, but that's how it works. One of these is the departmental MTA, the others are University-wide. If I want to go out (or in) directly (sometimes needed for some special testing), I have to go through lots of hoops and make sure the IT department understands it's for research. Regards, Martin. From eburger@standardstrack.com Fri Dec 27 19:16:01 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 737481AE82C; Fri, 27 Dec 2013 19:16:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.379 X-Spam-Level: ** X-Spam-Status: No, score=2.379 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BAD_LINEBREAK=0.5, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UzM8ZDHjSoGP; Fri, 27 Dec 2013 19:15:59 -0800 (PST) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) by ietfa.amsl.com (Postfix) with ESMTP id C85BE1AE82B; Fri, 27 Dec 2013 19:15:59 -0800 (PST) Received: from 0.sub-70-209-135.myvzw.com ([70.209.135.0]:3117 helo=[10.180.2.81]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.80.1) (envelope-from ) id 1VwkNG-0008IU-9C; Fri, 27 Dec 2013 19:15:42 -0800 Date: Fri, 27 Dec 2013 22:15:37 -0500 Message-ID: Importance: normal From: Eric Burger To: =?ISO-8859-1?Q?Martin_J=2E_D=FCrst?= , dcrocker@bbiw.net MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.android.email_984395530157310" X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Cc: draft-ietf-appsawg-rrvs-header-field.all@tools.ietf.org, The IESG , IETF Apps Discuss Subject: Re: [apps-discuss] Back to draft-ietf-appsawg-rrvs-header-field-05 (was Re: Scope of protocol authority) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Dec 2013 03:16:01 -0000 ----_com.android.email_984395530157310 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 T24gdGhlIG9uZSBoYW5kLCBzYW1lIGhlcmUgaWYgSSB1c2UgbXkgdW5pdmVyc2l0eSBlbWFpbC4g V29yc2UsIGlmIEkgaGF2ZSB0aGUgYXVkYWNpdHkgdG8gZW5jcnlwdCB0aGUgbWVzc2FnZSwgdGhl IHVuaXZlcnNpdHkncyBNVEEgaW5zZXJ0cyBhIHRveGljIHdhc3RlIHdhcm5pbmcgaW50byB0aGUg c3ViamVjdCBoZWFkZXIuwqAKCkhvd2V2ZXIsIHdlIGFyZSBleHBsaWNpdGx5IE5PVCB0aGUgdGFy Z2V0IHVzZXJzIGZvciB0aGUgZXh0ZW5zaW9uLiBUaGUgZG9jdW1lbnRzIGdvZXMgdG8gZ3JlYXQg bGVuZ3RocyB0byBzYXkgdGhpcyBpcyBmb3IgYXV0b21hdGVkIHNlbmRlcnMgYW5kIG5vdCByZWNv bW1lbmRlZCBmb3IgcGVvcGxlIHRvIHVzZS7CoAoKClNlbnQgZnJvbSBteSBtb2JpbGUgZGV2aWNl LiBUaGFua3MgYmUgdG8gTEVNT05BREU6IGh0dHA6Ly93d3cuc3RhbmRhcmRzdHJhY2suY29tL2ll dGYvbGVtb25hZGUKUzJFUkM6IGh0dHA6Ly9zMmVyYy5nZW9yZ2V0b3duLmVkdS8KR0NTQzogaHR0 cDovL2djc2MuZ2VvcmdldG93bi5lZHUvCk1lOiBodHRwOi8vd3d3LmNzLmdlb3JnZXRvd24uZWR1 L34gZWJ1cmdlcgoKLS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLQpGcm9tOiAiTWFy dGluIEouIETDvHJzdCIgPGR1ZXJzdEBpdC5hb3lhbWEuYWMuanA+IApEYXRlOjEyLzI3LzIwMTMg IDc6NDEgUE0gIChHTVQtMDU6MDApIApUbzogZGNyb2NrZXJAYmJpdy5uZXQgCkNjOiBEYXZlIENy b2NrZXIgPGRoY0BkY3JvY2tlci5uZXQ+LEVyaWMgQnVyZ2VyIDxlYnVyZ2VyQHN0YW5kYXJkc3Ry YWNrLmNvbT4sZHJhZnQtaWV0Zi1hcHBzYXdnLXJydnMtaGVhZGVyLWZpZWxkLmFsbEB0b29scy5p ZXRmLm9yZyxUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz4sSUVURiBBcHBzIERpc2N1c3MgPGFwcHMt ZGlzY3Vzc0BpZXRmLm9yZz4gClN1YmplY3Q6IFJlOiBbYXBwcy1kaXNjdXNzXSBCYWNrIHRvIGRy YWZ0LWlldGYtYXBwc2F3Zy1ycnZzLWhlYWRlci1maWVsZC0wNQ0gICh3YXMgUmU6IFNjb3BlIG9m IHByb3RvY29sIGF1dGhvcml0eSkgCgpPbiAyMDEzLzEyLzI4IDI6MzIsIERhdmUgQ3JvY2tlciB3 cm90ZToKCj4gWypdIEJ5IHdheSBvZiBleGFtcGxlIC0tIEFsdGhvdWdoIEkgZGlkIGhhdmUgdG8g c2VhcmNoIHRocm91Z2ggdGhlCj4gYXJjaGl2ZSBhIGJpdCwgSSBkaWQgZmluYWxseSBmaW5kIGFu IGV4YW1wbGUgb24gdGhlIGFwcHMtZGlzY3VzcyBtYWlsaW5nCj4gbGlzdCBvZiBhdXRob3Itc2lk ZSwgbXVsdGktTVRBIGhhbmRsaW5nIGJlZm9yZSBhIG1lc3NhZ2UgaGl0IHRoZSBvcGVuCj4gSW50 ZXJuZXQuCgpKdXN0IGxvb2sgYXQgbWFpbHMgZnJvbSBtZS4gVGhlIHdheSBJIGNvdW50ZWQsIHRo ZXJlIHdlcmUgdGhyZWUgb3IgZm91ciAKTVRBcyBvbiB0aGUgd2F5IG91dCAoYXMgd2VsbCBhcyBv biB0aGUgd2F5IGluLCBidXQgeW91IHdvbid0IHNlZSB0aGF0KS4gCkknbSBvbmx5IHRhbmdlbnRp YWxseSBpbnZvbHZlZCBpbiBvbmUgb2YgdGhlbSwgYW5kIG5vdCBhdCBhbGwgaW4gdGhlIApvdGhl cnMsIGJ1dCB0aGF0J3MgaG93IGl0IHdvcmtzLiBPbmUgb2YgdGhlc2UgaXMgdGhlIGRlcGFydG1l bnRhbCBNVEEsIAp0aGUgb3RoZXJzIGFyZSBVbml2ZXJzaXR5LXdpZGUuCgpJZiBJIHdhbnQgdG8g Z28gb3V0IChvciBpbikgZGlyZWN0bHkgKHNvbWV0aW1lcyBuZWVkZWQgZm9yIHNvbWUgc3BlY2lh bCAKdGVzdGluZyksIEkgaGF2ZSB0byBnbyB0aHJvdWdoIGxvdHMgb2YgaG9vcHMgYW5kIG1ha2Ug c3VyZSB0aGUgSVQgCmRlcGFydG1lbnQgdW5kZXJzdGFuZHMgaXQncyBmb3IgcmVzZWFyY2guCgpS ZWdhcmRzLMKgwqAgTWFydGluLgo= ----_com.android.email_984395530157310 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSA+PGRpdj5PbiB0aGUgb25lIGhhbmQs IHNhbWUgaGVyZSBpZiBJIHVzZSBteSB1bml2ZXJzaXR5IGVtYWlsLiBXb3JzZSwgaWYgSSBoYXZl IHRoZSBhdWRhY2l0eSB0byBlbmNyeXB0IHRoZSBtZXNzYWdlLCB0aGUgdW5pdmVyc2l0eSdzIE1U QSBpbnNlcnRzIGEgdG94aWMgd2FzdGUgd2FybmluZyBpbnRvIHRoZSBzdWJqZWN0IGhlYWRlci4m bmJzcDs8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pkhvd2V2ZXIsIHdlIGFyZSBleHBsaWNpdGx5 IE5PVCB0aGUgdGFyZ2V0IHVzZXJzIGZvciB0aGUgZXh0ZW5zaW9uLiBUaGUgZG9jdW1lbnRzIGdv ZXMgdG8gZ3JlYXQgbGVuZ3RocyB0byBzYXkgdGhpcyBpcyBmb3IgYXV0b21hdGVkIHNlbmRlcnMg YW5kIG5vdCByZWNvbW1lbmRlZCBmb3IgcGVvcGxlIHRvIHVzZS4mbmJzcDs8L2Rpdj48ZGl2Pjxi cj48L2Rpdj48ZGl2Pjxicj48L2Rpdj5TZW50IGZyb20gbXkgbW9iaWxlIGRldmljZS4gVGhhbmtz IGJlIHRvIExFTU9OQURFOiBodHRwOi8vd3d3LnN0YW5kYXJkc3RyYWNrLmNvbS9pZXRmL2xlbW9u YWRlPGRpdj5TMkVSQzogaHR0cDovL3MyZXJjLmdlb3JnZXRvd24uZWR1LzwvZGl2PjxkaXY+R0NT QzogaHR0cDovL2djc2MuZ2VvcmdldG93bi5lZHUvPC9kaXY+PGRpdj5NZTogaHR0cDovL3d3dy5j cy5nZW9yZ2V0b3duLmVkdS9+IGVidXJnZXI8L2Rpdj48YnI+PGJyPi0tLS0tLS0tIE9yaWdpbmFs IG1lc3NhZ2UgLS0tLS0tLS08YnI+RnJvbTogIk1hcnRpbiBKLiBEw7xyc3QiIDxkdWVyc3RAaXQu YW95YW1hLmFjLmpwPiA8YnI+RGF0ZToxMi8yNy8yMDEzICA3OjQxIFBNICAoR01ULTA1OjAwKSA8 YnI+VG86IGRjcm9ja2VyQGJiaXcubmV0IDxicj5DYzogRGF2ZSBDcm9ja2VyIDxkaGNAZGNyb2Nr ZXIubmV0PixFcmljIEJ1cmdlciA8ZWJ1cmdlckBzdGFuZGFyZHN0cmFjay5jb20+LGRyYWZ0LWll dGYtYXBwc2F3Zy1ycnZzLWhlYWRlci1maWVsZC5hbGxAdG9vbHMuaWV0Zi5vcmcsVGhlIElFU0cg PGllc2dAaWV0Zi5vcmc+LElFVEYgQXBwcyBEaXNjdXNzIDxhcHBzLWRpc2N1c3NAaWV0Zi5vcmc+ IDxicj5TdWJqZWN0OiBSZTogW2FwcHMtZGlzY3Vzc10gQmFjayB0byBkcmFmdC1pZXRmLWFwcHNh d2ctcnJ2cy1oZWFkZXItZmllbGQtMDUNICAod2FzIFJlOiBTY29wZSBvZiBwcm90b2NvbCBhdXRo b3JpdHkpIDxicj48YnI+T24gMjAxMy8xMi8yOCAyOjMyLCBEYXZlIENyb2NrZXIgd3JvdGU6PGJy Pjxicj4mZ3Q7IFsqXSBCeSB3YXkgb2YgZXhhbXBsZSAtLSBBbHRob3VnaCBJIGRpZCBoYXZlIHRv IHNlYXJjaCB0aHJvdWdoIHRoZTxicj4mZ3Q7IGFyY2hpdmUgYSBiaXQsIEkgZGlkIGZpbmFsbHkg ZmluZCBhbiBleGFtcGxlIG9uIHRoZSBhcHBzLWRpc2N1c3MgbWFpbGluZzxicj4mZ3Q7IGxpc3Qg b2YgYXV0aG9yLXNpZGUsIG11bHRpLU1UQSBoYW5kbGluZyBiZWZvcmUgYSBtZXNzYWdlIGhpdCB0 aGUgb3Blbjxicj4mZ3Q7IEludGVybmV0Ljxicj48YnI+SnVzdCBsb29rIGF0IG1haWxzIGZyb20g bWUuIFRoZSB3YXkgSSBjb3VudGVkLCB0aGVyZSB3ZXJlIHRocmVlIG9yIGZvdXIgPGJyPk1UQXMg b24gdGhlIHdheSBvdXQgKGFzIHdlbGwgYXMgb24gdGhlIHdheSBpbiwgYnV0IHlvdSB3b24ndCBz ZWUgdGhhdCkuIDxicj5JJ20gb25seSB0YW5nZW50aWFsbHkgaW52b2x2ZWQgaW4gb25lIG9mIHRo ZW0sIGFuZCBub3QgYXQgYWxsIGluIHRoZSA8YnI+b3RoZXJzLCBidXQgdGhhdCdzIGhvdyBpdCB3 b3Jrcy4gT25lIG9mIHRoZXNlIGlzIHRoZSBkZXBhcnRtZW50YWwgTVRBLCA8YnI+dGhlIG90aGVy cyBhcmUgVW5pdmVyc2l0eS13aWRlLjxicj48YnI+SWYgSSB3YW50IHRvIGdvIG91dCAob3IgaW4p IGRpcmVjdGx5IChzb21ldGltZXMgbmVlZGVkIGZvciBzb21lIHNwZWNpYWwgPGJyPnRlc3Rpbmcp LCBJIGhhdmUgdG8gZ28gdGhyb3VnaCBsb3RzIG9mIGhvb3BzIGFuZCBtYWtlIHN1cmUgdGhlIElU IDxicj5kZXBhcnRtZW50IHVuZGVyc3RhbmRzIGl0J3MgZm9yIHJlc2VhcmNoLjxicj48YnI+UmVn YXJkcywmbmJzcDsmbmJzcDsgTWFydGluLjxicj48L2JvZHk+ ----_com.android.email_984395530157310-- From dhc@dcrocker.net Fri Dec 27 19:25:22 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A76C51AEE6F; Fri, 27 Dec 2013 19:25:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pmFSokegHXKG; Fri, 27 Dec 2013 19:25:21 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 57F7A1AEE6D; Fri, 27 Dec 2013 19:25:21 -0800 (PST) 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 rBS3PCBK025547 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 27 Dec 2013 19:25:15 -0800 Message-ID: <52BE4444.8090203@dcrocker.net> Date: Fri, 27 Dec 2013 19:23:48 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Eric Burger , =?UTF-8?B?Ik1hcnRpbiBKLiBEw7w=?= =?UTF-8?B?cnN0Ig==?= , dcrocker@bbiw.net References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; 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]); Fri, 27 Dec 2013 19:25:15 -0800 (PST) Cc: draft-ietf-appsawg-rrvs-header-field.all@tools.ietf.org, The IESG , IETF Apps Discuss Subject: Re: [apps-discuss] Back to draft-ietf-appsawg-rrvs-header-field-05 (was Re: Scope of protocol authority) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Dec 2013 03:25:23 -0000 On 12/27/2013 7:15 PM, Eric Burger wrote: > On the one hand, same here if I use my university email. Worse, if I > have the audacity to encrypt the message, the university's MTA inserts a > toxic waste warning into the subject header. > > However, we are explicitly NOT the target users for the extension. The > documents goes to great lengths to say this is for automated senders and > not recommended for people to use. Eric, The discussion was about topology, not the nature of authors. Hence, examples of email-level multi-hop provide an existance proof that we are a long way from having all mail be "direct". d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From hsantos@isdg.net Sat Dec 28 05:44:36 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E48421AF983 for ; Sat, 28 Dec 2013 05:44:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.302 X-Spam-Level: X-Spam-Status: No, score=-99.302 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z-go8BJeiZGY for ; Sat, 28 Dec 2013 05:44:34 -0800 (PST) Received: from ntbbs.winserver.com (ntbbs.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 030921AF981 for ; Sat, 28 Dec 2013 05:44:33 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2566; t=1388238257; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=AGa5KtzFQInKVZbODNrE6APFG6Y=; b=wnhJ1k7I5+burFAXhomv Qa37MB94bj2Byn3xTkAhnumgaLuG80VPpgsXWjMU3NFEAEFqh+mu5k/Zq5K7OUFL mR8fPAT/BvQB1f5O7SDnaDs3OhEgzMZEA0Agr6bU7aHjzXxljTnRsIPPe1PnneP5 4qzme46yqc5vG5dH7hqP3gU= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Sat, 28 Dec 2013 08:44:17 -0500 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 (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1815743395.15448.3072; Sat, 28 Dec 2013 08:44:16 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2566; t=1388237721; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=uLbtYZt jo4PI8WAj0yZ3RGZq89ZY0jL8c6QY62mRCuI=; b=hrsOZLYFm33geRjL0yBUYpx ZlequQuWYUdWl0bQtP5GU1zV5Qpw0TSeuo0VoWqxnIqXleZ6oF4aunsAD+hkQk50 rd9AfNK2nS6dRRJRpPB+/zsTnhX7cxz04/Ub8g9yarLLxG2zyJmgJruWf8ve6Yxe e9QNsB6rxLA1yK6m8OUo= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Sat, 28 Dec 2013 08:35:21 -0500 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1262067317.9.7872; Sat, 28 Dec 2013 08:35:20 -0500 Message-ID: <52BED5B3.30507@isdg.net> Date: Sat, 28 Dec 2013 08:44:19 -0500 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: dcrocker@bbiw.net References: <4EC11DC5-BBB4-47FD-A10B-D9CA71ECFFBF@standardstrack.com> <90686C7B-5484-47AC-A595-28450C89E00F@standardstrack.com> <52BCAA9B.60902@dcrocker.net> In-Reply-To: <52BCAA9B.60902@dcrocker.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF Apps Discuss , draft-ietf-appsawg-rrvs-header-field.all@tools.ietf.org, The IESG Subject: Re: [apps-discuss] Applications Area Review of draft-ietf-appsawg-rrvs-header-field-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Dec 2013 13:44:37 -0000 On 12/26/2013 5:15 PM, Dave Crocker wrote: > Experimental status is for the purpose of understanding a protocol > that might not be well enough understood, yet, or with exploring its > possible dangers. Neither is at issue here. Dave, This proposal is impossible to implement *without* a sound client/server time negotiation contract and definition. As such, it contains many privacy and security exposure problems. That certainly fits your definition for experimental status. I will add it also increases new level of both client domain and server domains responsibilities and product liability issues that can not be ignored. As Eric pointed out with SOX and HIPAA regulatory compliancy considerations, you also have PCI/DSS (Payment Card Industry/Data Security Systems) industry compliancy issues to contend with as well. Without a client/server time definition, you are not sure what times are being issued by different RRVS clients and the clients themselves will not be sure what backend user times will they be compared with. This is a higher risk and thus until it is well know what times are being used, I can not at this time endorse implementing it (for our package). On the other hand, we perhaps know that times YAHOO or FACEBOOK are expecting so if this proposal is documenting the YAHOO/FACEBOOK behavior for time negotiations as a standard, this would be more acceptable and practical for implementation. If not, there are more project R&D that need to be done. For example, there might be a Sender Domain Time Definition Factor in the negotiating handshake for message acceptability. If you say there is not, then this presumes a single design time definition by all clients. Finally, with the advent of increased industry awareness to better "engineer" privacy and security considerations into our protocols, it is prudent that we have these discussions about having a solid understanding on how these protocols are expected to work. Its about "Getting it right, the first time." Increasing the engineering quality of the work. Hopefully, to reduced all lost of project/product R&D investment being asked to be done. IMO, with all the unknowns, especially with the inability to implement this without resolving these unknowns, eliminating or reduction potential security related concerns with these exposures, qualifies this proposal as an experimental status. The IETF should consider it as an experiment when there are still many unknowns. Thanks for your considerations. -- HLS From eburger@standardstrack.com Sat Dec 28 06:23:02 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CCB51AFA47; Sat, 28 Dec 2013 06:23:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yltXF5-Ixfcs; Sat, 28 Dec 2013 06:23:00 -0800 (PST) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) by ietfa.amsl.com (Postfix) with ESMTP id 6B9A31AFA46; Sat, 28 Dec 2013 06:23:00 -0800 (PST) Received: from 0.sub-70-209-135.myvzw.com ([70.209.135.0]:3124 helo=[10.180.2.81]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.80.1) (envelope-from ) id 1Vwums-0003zN-QA; Sat, 28 Dec 2013 06:22:48 -0800 Date: Sat, 28 Dec 2013 09:22:43 -0500 Message-ID: Importance: normal From: Eric Burger To: Hector Santos , dcrocker@bbiw.net MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.android.email_1063049035006720" X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Cc: draft-ietf-appsawg-rrvs-header-field.all@tools.ietf.org, The IESG , IETF Apps Discuss Subject: Re: [apps-discuss] Applications Area Review of draft-ietf-appsawg-rrvs-header-field-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Dec 2013 14:23:02 -0000 ----_com.android.email_1063049035006720 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 V291bGQgaXQgbm90IG1ha2Ugc2Vuc2UgdG8gc2F5IHRoYXQgdGltZSBpcyBvbiB0aGUgZ3JhbnVs YXJpdHkgb2YgZGF5IG9yIGV2ZW4gd2Vlaz8gSSBkb3VidCB0aW1lIG9mIGRheSB3b3VsZCBiZSBp bXBvcnRhbnQuwqAKCgpTZW50IGZyb20gbXkgbW9iaWxlIGRldmljZS4gVGhhbmtzIGJlIHRvIExF TU9OQURFOiBodHRwOi8vd3d3LnN0YW5kYXJkc3RyYWNrLmNvbS9pZXRmL2xlbW9uYWRlClMyRVJD OiBodHRwOi8vczJlcmMuZ2VvcmdldG93bi5lZHUvCkdDU0M6IGh0dHA6Ly9nY3NjLmdlb3JnZXRv d24uZWR1LwpNZTogaHR0cDovL3d3dy5jcy5nZW9yZ2V0b3duLmVkdS9+IGVidXJnZXIKCi0tLS0t LS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS0KRnJvbTogSGVjdG9yIFNhbnRvcyA8aHNhbnRv c0Bpc2RnLm5ldD4gCkRhdGU6MTIvMjgvMjAxMyAgODo0NCBBTSAgKEdNVC0wNTowMCkgClRvOiBk Y3JvY2tlckBiYml3Lm5ldCAKQ2M6IERhdmUgQ3JvY2tlciA8ZGhjQGRjcm9ja2VyLm5ldD4sIk11 cnJheSBTLiBLdWNoZXJhd3kiIDxzdXBlcnVzZXJAZ21haWwuY29tPixFcmljIEJ1cmdlciA8ZWJ1 cmdlckBzdGFuZGFyZHN0cmFjay5jb20+LGRyYWZ0LWlldGYtYXBwc2F3Zy1ycnZzLWhlYWRlci1m aWVsZC5hbGxAdG9vbHMuaWV0Zi5vcmcsVGhlIElFU0cgPGllc2dAaWV0Zi5vcmc+LElFVEYgQXBw cyBEaXNjdXNzIDxhcHBzLWRpc2N1c3NAaWV0Zi5vcmc+IApTdWJqZWN0OiBSZTogW2FwcHMtZGlz Y3Vzc10gQXBwbGljYXRpb25zIEFyZWEgUmV2aWV3IG9mIGRyYWZ0LWlldGYtYXBwc2F3Zy1ycnZz LWhlYWRlci1maWVsZC0wNSAKCk9uIDEyLzI2LzIwMTMgNToxNSBQTSwgRGF2ZSBDcm9ja2VyIHdy b3RlOgoKPiBFeHBlcmltZW50YWwgc3RhdHVzIGlzIGZvciB0aGUgcHVycG9zZSBvZiB1bmRlcnN0 YW5kaW5nIGEgcHJvdG9jb2wKPiB0aGF0IG1pZ2h0IG5vdCBiZSB3ZWxsIGVub3VnaCB1bmRlcnN0 b29kLCB5ZXQsIG9yIHdpdGggZXhwbG9yaW5nIGl0cwo+IHBvc3NpYmxlIGRhbmdlcnMuwqAgTmVp dGhlciBpcyBhdCBpc3N1ZSBoZXJlLgoKRGF2ZSwKClRoaXMgcHJvcG9zYWwgaXMgaW1wb3NzaWJs ZSB0byBpbXBsZW1lbnQgKndpdGhvdXQqIGEgc291bmQgCmNsaWVudC9zZXJ2ZXIgdGltZSBuZWdv dGlhdGlvbiBjb250cmFjdCBhbmQgZGVmaW5pdGlvbi7CoCBBcyBzdWNoLCBpdCAKY29udGFpbnMg bWFueSBwcml2YWN5IGFuZCBzZWN1cml0eSBleHBvc3VyZSBwcm9ibGVtcy7CoCBUaGF0IGNlcnRh aW5seSAKZml0cyB5b3VyIGRlZmluaXRpb24gZm9yIGV4cGVyaW1lbnRhbCBzdGF0dXMuCgpJIHdp bGwgYWRkIGl0IGFsc28gaW5jcmVhc2VzIG5ldyBsZXZlbCBvZiBib3RoIGNsaWVudCBkb21haW4g YW5kIApzZXJ2ZXIgZG9tYWlucyByZXNwb25zaWJpbGl0aWVzIGFuZCBwcm9kdWN0IGxpYWJpbGl0 eSBpc3N1ZXMgdGhhdCBjYW4gCm5vdCBiZSBpZ25vcmVkLsKgIEFzIEVyaWMgcG9pbnRlZCBvdXQg d2l0aCBTT1ggYW5kIEhJUEFBIHJlZ3VsYXRvcnkgCmNvbXBsaWFuY3kgY29uc2lkZXJhdGlvbnMs IHlvdSBhbHNvIGhhdmUgUENJL0RTUyAoUGF5bWVudCBDYXJkIApJbmR1c3RyeS9EYXRhIFNlY3Vy aXR5IFN5c3RlbXMpIGluZHVzdHJ5IGNvbXBsaWFuY3kgaXNzdWVzIHRvIGNvbnRlbmQgCndpdGgg YXMgd2VsbC4KCldpdGhvdXQgYSBjbGllbnQvc2VydmVyIHRpbWUgZGVmaW5pdGlvbiwgeW91IGFy ZSBub3Qgc3VyZSB3aGF0IHRpbWVzIAphcmUgYmVpbmcgaXNzdWVkIGJ5IGRpZmZlcmVudCBSUlZT IGNsaWVudHMgYW5kIHRoZSBjbGllbnRzIHRoZW1zZWx2ZXMgCndpbGwgbm90IGJlIHN1cmUgd2hh dCBiYWNrZW5kIHVzZXIgdGltZXMgd2lsbCB0aGV5IGJlIGNvbXBhcmVkIHdpdGguIArCoCBUaGlz IGlzIGEgaGlnaGVyIHJpc2sgYW5kIHRodXMgdW50aWwgaXQgaXMgd2VsbCBrbm93IHdoYXQgdGlt ZXMgYXJlIApiZWluZyB1c2VkLCBJIGNhbiBub3QgYXQgdGhpcyB0aW1lIGVuZG9yc2UgaW1wbGVt ZW50aW5nIGl0IChmb3Igb3VyIApwYWNrYWdlKS4KCk9uIHRoZSBvdGhlciBoYW5kLCB3ZSBwZXJo YXBzIGtub3cgdGhhdCB0aW1lcyBZQUhPTyBvciBGQUNFQk9PSyBhcmUgCmV4cGVjdGluZyBzbyBp ZiB0aGlzIHByb3Bvc2FsIGlzIGRvY3VtZW50aW5nIHRoZSBZQUhPTy9GQUNFQk9PSyAKYmVoYXZp b3IgZm9yIHRpbWUgbmVnb3RpYXRpb25zIGFzIGEgc3RhbmRhcmQsIHRoaXMgd291bGQgYmUgbW9y ZSAKYWNjZXB0YWJsZSBhbmQgcHJhY3RpY2FsIGZvciBpbXBsZW1lbnRhdGlvbi4KCklmIG5vdCwg dGhlcmUgYXJlIG1vcmUgcHJvamVjdCBSJkQgdGhhdCBuZWVkIHRvIGJlIGRvbmUuwqAgRm9yIGV4 YW1wbGUsIAp0aGVyZSBtaWdodCBiZSBhIFNlbmRlciBEb21haW4gVGltZSBEZWZpbml0aW9uIEZh Y3RvciBpbiB0aGUgCm5lZ290aWF0aW5nIGhhbmRzaGFrZSBmb3IgbWVzc2FnZSBhY2NlcHRhYmls aXR5LsKgIElmIHlvdSBzYXkgdGhlcmUgaXMgCm5vdCwgdGhlbiB0aGlzIHByZXN1bWVzIGEgc2lu Z2xlIGRlc2lnbiB0aW1lIGRlZmluaXRpb24gYnkgYWxsIGNsaWVudHMuCgpGaW5hbGx5LCB3aXRo IHRoZSBhZHZlbnQgb2YgaW5jcmVhc2VkIGluZHVzdHJ5IGF3YXJlbmVzcyB0byBiZXR0ZXIgCiJl bmdpbmVlciIgcHJpdmFjeSBhbmQgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgaW50byBvdXIgcHJv dG9jb2xzLCBpdCAKaXMgcHJ1ZGVudCB0aGF0IHdlIGhhdmUgdGhlc2UgZGlzY3Vzc2lvbnMgYWJv dXQgaGF2aW5nIGEgc29saWQgCnVuZGVyc3RhbmRpbmcgb24gaG93IHRoZXNlIHByb3RvY29scyBh cmUgZXhwZWN0ZWQgdG8gd29yay7CoCBJdHMgYWJvdXQgCiJHZXR0aW5nIGl0IHJpZ2h0LCB0aGUg Zmlyc3QgdGltZS4iwqAgSW5jcmVhc2luZyB0aGUgZW5naW5lZXJpbmcgCnF1YWxpdHkgb2YgdGhl IHdvcmsuwqAgSG9wZWZ1bGx5LCB0byByZWR1Y2VkIGFsbCBsb3N0IG9mIApwcm9qZWN0L3Byb2R1 Y3QgUiZEIGludmVzdG1lbnQgYmVpbmcgYXNrZWQgdG8gYmUgZG9uZS4KCklNTywgd2l0aCBhbGwg dGhlIHVua25vd25zLCBlc3BlY2lhbGx5IHdpdGggdGhlIGluYWJpbGl0eSB0byBpbXBsZW1lbnQg CnRoaXMgd2l0aG91dCByZXNvbHZpbmcgdGhlc2UgdW5rbm93bnMsIGVsaW1pbmF0aW5nIG9yIHJl ZHVjdGlvbiAKcG90ZW50aWFsIHNlY3VyaXR5IHJlbGF0ZWQgY29uY2VybnMgd2l0aCB0aGVzZSBl eHBvc3VyZXMsIHF1YWxpZmllcyAKdGhpcyBwcm9wb3NhbCBhcyBhbiBleHBlcmltZW50YWwgc3Rh dHVzLsKgwqAgVGhlIElFVEYgc2hvdWxkIGNvbnNpZGVyIGl0IAphcyBhbiBleHBlcmltZW50IHdo ZW4gdGhlcmUgYXJlIHN0aWxsIG1hbnkgdW5rbm93bnMuCgpUaGFua3MgZm9yIHlvdXIgY29uc2lk ZXJhdGlvbnMuCgotLSAKSExTCgoK ----_com.android.email_1063049035006720 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSA+PGRpdj5Xb3VsZCBpdCBub3QgbWFr ZSBzZW5zZSB0byBzYXkgdGhhdCB0aW1lIGlzIG9uIHRoZSBncmFudWxhcml0eSBvZiBkYXkgb3Ig ZXZlbiB3ZWVrPyBJIGRvdWJ0IHRpbWUgb2YgZGF5IHdvdWxkIGJlIGltcG9ydGFudC4mbmJzcDs8 L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj5TZW50IGZyb20gbXkgbW9iaWxlIGRl dmljZS4gVGhhbmtzIGJlIHRvIExFTU9OQURFOiBodHRwOi8vd3d3LnN0YW5kYXJkc3RyYWNrLmNv bS9pZXRmL2xlbW9uYWRlPGRpdj5TMkVSQzogaHR0cDovL3MyZXJjLmdlb3JnZXRvd24uZWR1Lzwv ZGl2PjxkaXY+R0NTQzogaHR0cDovL2djc2MuZ2VvcmdldG93bi5lZHUvPC9kaXY+PGRpdj5NZTog aHR0cDovL3d3dy5jcy5nZW9yZ2V0b3duLmVkdS9+IGVidXJnZXI8L2Rpdj48YnI+PGJyPi0tLS0t LS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS08YnI+RnJvbTogSGVjdG9yIFNhbnRvcyA8aHNh bnRvc0Bpc2RnLm5ldD4gPGJyPkRhdGU6MTIvMjgvMjAxMyAgODo0NCBBTSAgKEdNVC0wNTowMCkg PGJyPlRvOiBkY3JvY2tlckBiYml3Lm5ldCA8YnI+Q2M6IERhdmUgQ3JvY2tlciA8ZGhjQGRjcm9j a2VyLm5ldD4sIk11cnJheSBTLiBLdWNoZXJhd3kiIDxzdXBlcnVzZXJAZ21haWwuY29tPixFcmlj IEJ1cmdlciA8ZWJ1cmdlckBzdGFuZGFyZHN0cmFjay5jb20+LGRyYWZ0LWlldGYtYXBwc2F3Zy1y cnZzLWhlYWRlci1maWVsZC5hbGxAdG9vbHMuaWV0Zi5vcmcsVGhlIElFU0cgPGllc2dAaWV0Zi5v cmc+LElFVEYgQXBwcyBEaXNjdXNzIDxhcHBzLWRpc2N1c3NAaWV0Zi5vcmc+IDxicj5TdWJqZWN0 OiBSZTogW2FwcHMtZGlzY3Vzc10gQXBwbGljYXRpb25zIEFyZWEgUmV2aWV3IG9mIGRyYWZ0LWll dGYtYXBwc2F3Zy1ycnZzLWhlYWRlci1maWVsZC0wNSA8YnI+PGJyPk9uIDEyLzI2LzIwMTMgNTox NSBQTSwgRGF2ZSBDcm9ja2VyIHdyb3RlOjxicj48YnI+Jmd0OyBFeHBlcmltZW50YWwgc3RhdHVz IGlzIGZvciB0aGUgcHVycG9zZSBvZiB1bmRlcnN0YW5kaW5nIGEgcHJvdG9jb2w8YnI+Jmd0OyB0 aGF0IG1pZ2h0IG5vdCBiZSB3ZWxsIGVub3VnaCB1bmRlcnN0b29kLCB5ZXQsIG9yIHdpdGggZXhw bG9yaW5nIGl0czxicj4mZ3Q7IHBvc3NpYmxlIGRhbmdlcnMuJm5ic3A7IE5laXRoZXIgaXMgYXQg aXNzdWUgaGVyZS48YnI+PGJyPkRhdmUsPGJyPjxicj5UaGlzIHByb3Bvc2FsIGlzIGltcG9zc2li bGUgdG8gaW1wbGVtZW50ICp3aXRob3V0KiBhIHNvdW5kIDxicj5jbGllbnQvc2VydmVyIHRpbWUg bmVnb3RpYXRpb24gY29udHJhY3QgYW5kIGRlZmluaXRpb24uJm5ic3A7IEFzIHN1Y2gsIGl0IDxi cj5jb250YWlucyBtYW55IHByaXZhY3kgYW5kIHNlY3VyaXR5IGV4cG9zdXJlIHByb2JsZW1zLiZu YnNwOyBUaGF0IGNlcnRhaW5seSA8YnI+Zml0cyB5b3VyIGRlZmluaXRpb24gZm9yIGV4cGVyaW1l bnRhbCBzdGF0dXMuPGJyPjxicj5JIHdpbGwgYWRkIGl0IGFsc28gaW5jcmVhc2VzIG5ldyBsZXZl bCBvZiBib3RoIGNsaWVudCBkb21haW4gYW5kIDxicj5zZXJ2ZXIgZG9tYWlucyByZXNwb25zaWJp bGl0aWVzIGFuZCBwcm9kdWN0IGxpYWJpbGl0eSBpc3N1ZXMgdGhhdCBjYW4gPGJyPm5vdCBiZSBp Z25vcmVkLiZuYnNwOyBBcyBFcmljIHBvaW50ZWQgb3V0IHdpdGggU09YIGFuZCBISVBBQSByZWd1 bGF0b3J5IDxicj5jb21wbGlhbmN5IGNvbnNpZGVyYXRpb25zLCB5b3UgYWxzbyBoYXZlIFBDSS9E U1MgKFBheW1lbnQgQ2FyZCA8YnI+SW5kdXN0cnkvRGF0YSBTZWN1cml0eSBTeXN0ZW1zKSBpbmR1 c3RyeSBjb21wbGlhbmN5IGlzc3VlcyB0byBjb250ZW5kIDxicj53aXRoIGFzIHdlbGwuPGJyPjxi cj5XaXRob3V0IGEgY2xpZW50L3NlcnZlciB0aW1lIGRlZmluaXRpb24sIHlvdSBhcmUgbm90IHN1 cmUgd2hhdCB0aW1lcyA8YnI+YXJlIGJlaW5nIGlzc3VlZCBieSBkaWZmZXJlbnQgUlJWUyBjbGll bnRzIGFuZCB0aGUgY2xpZW50cyB0aGVtc2VsdmVzIDxicj53aWxsIG5vdCBiZSBzdXJlIHdoYXQg YmFja2VuZCB1c2VyIHRpbWVzIHdpbGwgdGhleSBiZSBjb21wYXJlZCB3aXRoLiA8YnI+Jm5ic3A7 IFRoaXMgaXMgYSBoaWdoZXIgcmlzayBhbmQgdGh1cyB1bnRpbCBpdCBpcyB3ZWxsIGtub3cgd2hh dCB0aW1lcyBhcmUgPGJyPmJlaW5nIHVzZWQsIEkgY2FuIG5vdCBhdCB0aGlzIHRpbWUgZW5kb3Jz ZSBpbXBsZW1lbnRpbmcgaXQgKGZvciBvdXIgPGJyPnBhY2thZ2UpLjxicj48YnI+T24gdGhlIG90 aGVyIGhhbmQsIHdlIHBlcmhhcHMga25vdyB0aGF0IHRpbWVzIFlBSE9PIG9yIEZBQ0VCT09LIGFy ZSA8YnI+ZXhwZWN0aW5nIHNvIGlmIHRoaXMgcHJvcG9zYWwgaXMgZG9jdW1lbnRpbmcgdGhlIFlB SE9PL0ZBQ0VCT09LIDxicj5iZWhhdmlvciBmb3IgdGltZSBuZWdvdGlhdGlvbnMgYXMgYSBzdGFu ZGFyZCwgdGhpcyB3b3VsZCBiZSBtb3JlIDxicj5hY2NlcHRhYmxlIGFuZCBwcmFjdGljYWwgZm9y IGltcGxlbWVudGF0aW9uLjxicj48YnI+SWYgbm90LCB0aGVyZSBhcmUgbW9yZSBwcm9qZWN0IFIm YW1wO0QgdGhhdCBuZWVkIHRvIGJlIGRvbmUuJm5ic3A7IEZvciBleGFtcGxlLCA8YnI+dGhlcmUg bWlnaHQgYmUgYSBTZW5kZXIgRG9tYWluIFRpbWUgRGVmaW5pdGlvbiBGYWN0b3IgaW4gdGhlIDxi cj5uZWdvdGlhdGluZyBoYW5kc2hha2UgZm9yIG1lc3NhZ2UgYWNjZXB0YWJpbGl0eS4mbmJzcDsg SWYgeW91IHNheSB0aGVyZSBpcyA8YnI+bm90LCB0aGVuIHRoaXMgcHJlc3VtZXMgYSBzaW5nbGUg ZGVzaWduIHRpbWUgZGVmaW5pdGlvbiBieSBhbGwgY2xpZW50cy48YnI+PGJyPkZpbmFsbHksIHdp dGggdGhlIGFkdmVudCBvZiBpbmNyZWFzZWQgaW5kdXN0cnkgYXdhcmVuZXNzIHRvIGJldHRlciA8 YnI+ImVuZ2luZWVyIiBwcml2YWN5IGFuZCBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBpbnRvIG91 ciBwcm90b2NvbHMsIGl0IDxicj5pcyBwcnVkZW50IHRoYXQgd2UgaGF2ZSB0aGVzZSBkaXNjdXNz aW9ucyBhYm91dCBoYXZpbmcgYSBzb2xpZCA8YnI+dW5kZXJzdGFuZGluZyBvbiBob3cgdGhlc2Ug cHJvdG9jb2xzIGFyZSBleHBlY3RlZCB0byB3b3JrLiZuYnNwOyBJdHMgYWJvdXQgPGJyPiJHZXR0 aW5nIGl0IHJpZ2h0LCB0aGUgZmlyc3QgdGltZS4iJm5ic3A7IEluY3JlYXNpbmcgdGhlIGVuZ2lu ZWVyaW5nIDxicj5xdWFsaXR5IG9mIHRoZSB3b3JrLiZuYnNwOyBIb3BlZnVsbHksIHRvIHJlZHVj ZWQgYWxsIGxvc3Qgb2YgPGJyPnByb2plY3QvcHJvZHVjdCBSJmFtcDtEIGludmVzdG1lbnQgYmVp bmcgYXNrZWQgdG8gYmUgZG9uZS48YnI+PGJyPklNTywgd2l0aCBhbGwgdGhlIHVua25vd25zLCBl c3BlY2lhbGx5IHdpdGggdGhlIGluYWJpbGl0eSB0byBpbXBsZW1lbnQgPGJyPnRoaXMgd2l0aG91 dCByZXNvbHZpbmcgdGhlc2UgdW5rbm93bnMsIGVsaW1pbmF0aW5nIG9yIHJlZHVjdGlvbiA8YnI+ cG90ZW50aWFsIHNlY3VyaXR5IHJlbGF0ZWQgY29uY2VybnMgd2l0aCB0aGVzZSBleHBvc3VyZXMs IHF1YWxpZmllcyA8YnI+dGhpcyBwcm9wb3NhbCBhcyBhbiBleHBlcmltZW50YWwgc3RhdHVzLiZu YnNwOyZuYnNwOyBUaGUgSUVURiBzaG91bGQgY29uc2lkZXIgaXQgPGJyPmFzIGFuIGV4cGVyaW1l bnQgd2hlbiB0aGVyZSBhcmUgc3RpbGwgbWFueSB1bmtub3ducy48YnI+PGJyPlRoYW5rcyBmb3Ig eW91ciBjb25zaWRlcmF0aW9ucy48YnI+PGJyPi0tIDxicj5ITFM8YnI+PGJyPjxicj48L2JvZHk+ ----_com.android.email_1063049035006720-- From hsantos@isdg.net Sat Dec 28 06:27:35 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7CBC1AFA60 for ; Sat, 28 Dec 2013 06:27:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.002 X-Spam-Level: X-Spam-Status: No, score=-102.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1JT2Js94_zjL for ; Sat, 28 Dec 2013 06:27:33 -0800 (PST) Received: from ntbbs.winserver.com (mail.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 3665C1AFA62 for ; Sat, 28 Dec 2013 06:27:33 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1668; t=1388240842; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=3DI6g1+lG7IGQ9wo7B+wi2X9VuM=; b=r0eYo2rsiHWcyadRDhpP qKK/4PEzqr3XvjhpZ2RebVzzHI9Eth98bgMutMLKwfz42r0icMFph7ntwDj+Oz59 tOzxr1msQ9I41libMrnAV6SEeKgHcsSKnj/Mzz8WpiVp+rYwq6wckhQO+qOAlQZj fDxNVqWy5usatZCxPGUeapI= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Sat, 28 Dec 2013 09:27:22 -0500 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 (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1818328768.15448.3580; Sat, 28 Dec 2013 09:27:21 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1668; t=1388240305; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=dvHn+n+ by4I4BPMu6Bi9ilDwW5CmcjdKVFYVtni0zDE=; b=zNCBm+pQFjGibxjXW/pHIJn pU9/HDeF8RHRTGLMD3TQB+RfP6epoKcodLUBZsXjJ7RhZg0lrg4GxKTKkIFlWktR x334UmMGX0VnkaVycQBdZJ1Y2el45ODMoVrHQUwW9RGAc27G83csET9IG0/ca4T+ Md3+I/obfp6Erx7kzLd0= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Sat, 28 Dec 2013 09:18:25 -0500 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1264651505.9.8752; Sat, 28 Dec 2013 09:18:24 -0500 Message-ID: <52BEDFCC.4090505@isdg.net> Date: Sat, 28 Dec 2013 09:27:24 -0500 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: Eric Burger References: <4EC11DC5-BBB4-47FD-A10B-D9CA71ECFFBF@standardstrack.com> <01P2FPM68CDW0000AS@mauve.mrochek.com> <52BDAFAD.9000800@dcrocker.net> <57C0DC48-18A7-4958-BBF2-7B2A34B156B3@standardstrack.com> In-Reply-To: <57C0DC48-18A7-4958-BBF2-7B2A34B156B3@standardstrack.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: draft-ietf-appsawg-rrvs-header-field.all@tools.ietf.org, The IESG , IETF Apps Discuss Subject: Re: [apps-discuss] Back to draft-ietf-appsawg-rrvs-header-field-05 (was Re: Scope of protocol authority) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Dec 2013 14:27:36 -0000 On 12/27/2013 12:10 PM, Eric Burger wrote: > This hits on the request vs. requirement. > > I like Daveďż˝s distinction: if I talk with you and you agree to supporting X, then I can reasonably ďż˝requireďż˝ you to do something in the scope of X. > > If I just send you something without ďż˝knowingďż˝ (via negotiation, contractual understanding, etc.) that you support X, then I can only reasonably ďż˝requestďż˝ you to do something in the scope of X. > > Unfortunately for RRVS, as it is currently specified, it is a request, not a requirement. Even with the SMTP extension, unless the normative behavior is to fail if the next MTA or final MUA does not support RRVS, the present MTA cannot guarantee the delivery chain will support RRVS. Therefore, it is only a request. > +1. > As for the folks with this implemented, there is nothing to fear ďż˝ how many MUAďż˝a are more than two MTAďż˝s away from the sending MUA? Especially since we are talking banks sending messages to gmail/hotmail/Yahoo!Mail/etc., I do not think anything would break to make the Require a real require. That is, fail if one or more MTAďż˝s do not support the RRVS extension. This also has the nice side effect of making the header, corner cases which makes up almost a quarter the draft, by the way, obsolete. > This is beginning to sound more like a VRFY-like proposal. Perhaps, the reduction of the security concerns, the sending of sensitive content, can be done by delaying the transaction until a destination user can be verified using some other (enhanced) mechanism. BTW, How does VRFY change with the possibility of RCPT command now having RRVS? -- HLS From hsantos@isdg.net Sat Dec 28 08:44:18 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78B901AFD56 for ; Sat, 28 Dec 2013 08:44:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.002 X-Spam-Level: X-Spam-Status: No, score=-102.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QQQhHb-guEKN for ; Sat, 28 Dec 2013 08:44:16 -0800 (PST) Received: from ntbbs.winserver.com (groups.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 97C1B1AFD4B for ; Sat, 28 Dec 2013 08:44:16 -0800 (PST) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1065; t=1388249048; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=FmL5zD280GT951DemcpPIYQSfAs=; b=wRekN1eaeW127kqewroI gDHPB2YwJ5DXcHmP0bJby/S+73BSGHaRh39OLmDcQkCIsQMC+OGaJZT7rY9xX/YR ym8XICUMu+9y8+ec27tWjJiLj+v7hV/HjeagCJ4NwJ2IIyXuCD3niCOy3LRD8H8g 5IViRBo2WJ3kLjLYFN0Y5o8= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Sat, 28 Dec 2013 11:44:08 -0500 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 (hector.wildcatblog.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1826534545.15448.3860; Sat, 28 Dec 2013 11:44:07 -0500 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1065; t=1388248511; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=m7871je vFMcSM4kUiUdizi8J1GfPMZwF9E8bTuBaaok=; b=j7gl+cqPsKyqautTxx1WsCL HZJwHs6W6TbhraikCBi+NxoPbjREL/uzUqVioOlQq89igKffP6QWc29AgEOYzY/i CgR1HIPrdbAhMIgIZDkzWJAnI1p9Va5YG2Ix8X+L9NALKm4bVpKdFIlc5JY29l1j ZeVdr0LhF9hPCxzDjH0A= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Sat, 28 Dec 2013 11:35:11 -0500 Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1272857645.9.10068; Sat, 28 Dec 2013 11:35:10 -0500 Message-ID: <52BEFFDA.6020107@isdg.net> Date: Sat, 28 Dec 2013 11:44:10 -0500 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: Eric Burger References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF Apps Discuss , draft-ietf-appsawg-rrvs-header-field.all@tools.ietf.org, dcrocker@bbiw.net, The IESG Subject: Re: [apps-discuss] Applications Area Review of draft-ietf-appsawg-rrvs-header-field-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Dec 2013 16:44:18 -0000 On 12/28/2013 9:22 AM, Eric Burger wrote: >Would it not make sense to say that time is on the granularity of day > or even week? I doubt time of day would be important. For this special proposed RRVS *security* protocol, the only concern I can see with a reduced granularity would be a security one. At the security level, a possible threat with SMTP session brute force timestamp attacks where different RRVS commands are retried with different time stamps. What may become a PR (and legal) concern with this RRVS "security" proposal and promotion is the claim that traditional SMTP transaction acceptance can be turned into a rejection with the addition of a timestamp, thus providing a new technology and method to offer better secured and user verified and RRVS authenticated communications. Conversely, it also means a rejection can be turned into an acceptance with the issuing of a proper timestamp. So with a reduced granularity, a concern may be that you can zoom in (i.e. binary search) faster at the acceptable date. -- HLS From superuser@gmail.com Sat Dec 28 09:36:29 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B4D21AFE72; Sat, 28 Dec 2013 09:36:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I4Rw2rv_OA_C; Sat, 28 Dec 2013 09:36:27 -0800 (PST) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 64B451AFE2C; Sat, 28 Dec 2013 09:36:27 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id p61so9183221wes.3 for ; Sat, 28 Dec 2013 09:36:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/PICkN/wKZ51Q1xPTzTiKqtvIRYK+y2CcqBgFaD1+nA=; b=kCBzQNIwRvPLf0L9kReJ+QucMoXy9xtLtvxnF48/KeDrRxAU9bn9S7DxIT0yTMseE+ iZNJ/3vVqG+66fhpj5v+JSY68meUSE66vAyO+/Ns30Vs+I0eu402VF09XSE+Zx4INbux Yx8Cqvk428b/j8tuSnma9KVzEcXmksjzMVvbXLKZ8234Yl/+n+3q0kEd+PxC5hX5kbK0 8kmxQJe0up9KLXqMYwhwvfpXG3NXvWV1KYaMxKj1aTBxMbh2gvvsgrhKWB3tuaYby0xL MyoQON1Zcw98Mew9aeFFSvGtPlEpP40CVZMXmrElj8i6VJJwduehW8LVJcaem71wTrCY XVNw== MIME-Version: 1.0 X-Received: by 10.194.61.211 with SMTP id s19mr10647718wjr.73.1388252181808; Sat, 28 Dec 2013 09:36:21 -0800 (PST) Received: by 10.180.84.106 with HTTP; Sat, 28 Dec 2013 09:36:21 -0800 (PST) In-Reply-To: <52BED5B3.30507@isdg.net> References: <4EC11DC5-BBB4-47FD-A10B-D9CA71ECFFBF@standardstrack.com> <90686C7B-5484-47AC-A595-28450C89E00F@standardstrack.com> <52BCAA9B.60902@dcrocker.net> <52BED5B3.30507@isdg.net> Date: Sat, 28 Dec 2013 09:36:21 -0800 Message-ID: From: "Murray S. Kucherawy" To: Hector Santos Content-Type: multipart/alternative; boundary=047d7b86c28c27cd4904ee9ba6d6 Cc: IETF Apps Discuss , draft-ietf-appsawg-rrvs-header-field.all@tools.ietf.org, Dave Crocker , The IESG Subject: Re: [apps-discuss] Applications Area Review of draft-ietf-appsawg-rrvs-header-field-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Dec 2013 17:36:29 -0000 --047d7b86c28c27cd4904ee9ba6d6 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Dec 28, 2013 at 5:44 AM, Hector Santos wrote: > > Without a client/server time definition, you are not sure what times are > being issued by different RRVS clients and the clients themselves will not > be sure what backend user times will they be compared with. This is a > higher risk and thus until it is well know what times are being used, I can > not at this time endorse implementing it (for our package). > > On the other hand, we perhaps know that times YAHOO or FACEBOOK are > expecting so if this proposal is documenting the YAHOO/FACEBOOK behavior > for time negotiations as a standard, this would be more acceptable and > practical for implementation. > None of the enormous complexity being proposed here is necessary for this protocol definition to be effective, nor is dragging a bunch of layer nine stuff down to the level of an SMTP extension. The question the extension asks is a simple one. As Ned has already pointed out, what data one needs to retain in order to answer it is entirely a local matter on the part of the receiving system, and is inappropriate to specify here. If the receiver can't answer that question, for whatever reason, it simply doesn't participate. -MSK --047d7b86c28c27cd4904ee9ba6d6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, Dec 28, 2013 at 5:44 AM, Hector Santos <hsantos@= isdg.net> wrote:

Without a client/server time definition, you are not sure what times are be= ing issued by different RRVS clients and the clients themselves will not be= sure what backend user times will they be compared with. =A0This is a high= er risk and thus until it is well know what times are being used, I can not= at this time endorse implementing it (for our package).

On the other hand, we perhaps know that times YAHOO or FACEBOOK are expecti= ng so if this proposal is documenting the YAHOO/FACEBOOK behavior for time = negotiations as a standard, this would be more acceptable and practical for= implementation.

None of the enormous complexity being prop= osed here is necessary for this protocol definition to be effective, nor is= dragging a bunch of layer nine stuff down to the level of an SMTP extensio= n.=A0 The question the extension asks is a simple one.=A0 As Ned has alread= y pointed out, what data one needs to retain in order to answer it is entir= ely a local matter on the part of the receiving system, and is inappropriat= e to specify here.

If the receiver can't answer that question, for whatever= reason, it simply doesn't participate.

-M= SK
--047d7b86c28c27cd4904ee9ba6d6-- From superuser@gmail.com Sat Dec 28 09:38:19 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB4E41AFE72; Sat, 28 Dec 2013 09:38:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZXebmJNB6pEI; Sat, 28 Dec 2013 09:38:17 -0800 (PST) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id 1A6201AFE2C; Sat, 28 Dec 2013 09:38:16 -0800 (PST) Received: by mail-wi0-f179.google.com with SMTP id z2so10460640wiv.6 for ; Sat, 28 Dec 2013 09:38:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pts9l/ntqaA/kb3d6g+dVibe3l5js9tFPN6661hvKnQ=; b=GUzdZdQ4S4u7N4FLl/t0rOhv/SP2ayPXPfM1CPzH6vZbGqcCm6GLwUkJb/CtMwpRkj bpL5qUVc3r8eLXwh1YVeQzWnACbnxSEOZ9zS9YNUOKIz17Q2AkBG0UeCugdIuYb6o0dy E4wC5NMRnVtdHbwNIGgXH2SsNRgqzBA2uJZKJQ4SbTSE2sTQE7kXd5L/ml7P5iNmm7zu g8Ql5Fixv/o3WXjpZhqP5Jrsq6GXZ+HQpcHuADBaVc8lHD85yq2+jE6N8HFoOj0Qh2Xj uHvZLUX0SOHUPWsIsujEHk0Gv0TXmvlgp0VOifAMBT9AV7cgusAZMNi23lK9aWzjRYNZ H3JA== MIME-Version: 1.0 X-Received: by 10.180.187.72 with SMTP id fq8mr37815764wic.26.1388252291571; Sat, 28 Dec 2013 09:38:11 -0800 (PST) Received: by 10.180.84.106 with HTTP; Sat, 28 Dec 2013 09:38:11 -0800 (PST) In-Reply-To: References: Date: Sat, 28 Dec 2013 09:38:11 -0800 Message-ID: From: "Murray S. Kucherawy" To: Eric Burger Content-Type: multipart/alternative; boundary=001a11c2679cb2a7ca04ee9bac86 Cc: IETF Apps Discuss , draft-ietf-appsawg-rrvs-header-field.all@tools.ietf.org, Dave Crocker , The IESG Subject: Re: [apps-discuss] Applications Area Review of draft-ietf-appsawg-rrvs-header-field-05 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Dec 2013 17:38:19 -0000 --001a11c2679cb2a7ca04ee9bac86 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Dec 28, 2013 at 6:22 AM, Eric Burger wrote: > Would it not make sense to say that time is on the granularity of day or > even week? > > You could, or you as the receiver could simply make your decision based on the date and discard the time-of-day precision. However... > I doubt time of day would be important. > ...it is. -MSK --001a11c2679cb2a7ca04ee9bac86 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, Dec 28, 2013 at 6:22 AM, Eric Burger <eb= urger@standardstrack.com> wrote:
Would it not make sense to say tha= t time is on the granularity of day or even week?


You could, or you as the receiver could simply make your decision = based on the date and discard the time-of-day precision.=A0 However...
= =A0
I doubt time of day would be important.

...it is.

-MSK
--001a11c2679cb2a7ca04ee9bac86-- From dhc@dcrocker.net Sat Dec 28 17:11:25 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B4B01AE448; Sat, 28 Dec 2013 17:11:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zd5wW71mt1rI; Sat, 28 Dec 2013 17:11:19 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 452671AE3AC; Sat, 28 Dec 2013 17:11:19 -0800 (PST) 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 rBT1BABb018663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 28 Dec 2013 17:11:13 -0800 Message-ID: <52BF7658.9020009@dcrocker.net> Date: Sat, 28 Dec 2013 17:09:44 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Eric Burger , draft-ietf-appsawg-rrvs-header-field.all@tools.ietf.org References: <4gxam5m356qoma0o80r13rpp.1388167953685@email.android.com> In-Reply-To: <4gxam5m356qoma0o80r13rpp.1388167953685@email.android.com> Content-Type: text/plain; charset=UTF-8; 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]); Sat, 28 Dec 2013 17:11:14 -0800 (PST) Cc: The IESG , IETF Apps Discuss Subject: Re: [apps-discuss] Back to draft-ietf-appsawg-rrvs-header-field-05 (was Re: Scope of protocol authority) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Dec 2013 01:11:25 -0000 On 12/27/2013 10:12 AM, Eric Burger wrote: > Yes, and look at the use case. If you are the enterprise sending the > message, you will upgrade all the MTAs under your control. If you are > the massive, public MSP advertising RRVS on the receiving side, not a > problem. > > If it is b2b, then as Ned pointed out, even if you are sending to > hr@example.com, you most likely don't want the last one. Eric, You've changed the argument. I was responding to your claim that all mail was one-hop. Now you are claiming that enterprises upgrade all their servers at the same time. But of course, that's not the way operations in large organizations work. Let's move back to the simple architectural and operational reality: Email is a distributed, multi-hop. The fact that quite a bit of mail is essentially one-hop is a distraction from serious architectural discussions. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From eburger@standardstrack.com Sat Dec 28 18:01:05 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2151E1AE46C; Sat, 28 Dec 2013 18:01:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.08 X-Spam-Level: ** X-Spam-Status: No, score=2.08 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, HTML_NONELEMENT_30_40=0.001, MIME_BAD_LINEBREAK=0.5, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IbMduEPsqivD; Sat, 28 Dec 2013 18:01:04 -0800 (PST) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) by ietfa.amsl.com (Postfix) with ESMTP id 17A9E1AE3B8; Sat, 28 Dec 2013 18:01:04 -0800 (PST) Received: from 0.sub-70-209-135.myvzw.com ([70.209.135.0]:3111 helo=[10.180.2.81]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.80.1) (envelope-from ) id 1Vx5gR-0002hG-3I; Sat, 28 Dec 2013 18:00:52 -0800 Date: Sat, 28 Dec 2013 21:00:48 -0500 Message-ID: Importance: normal From: Eric Burger To: Dave Crocker , draft-ietf-appsawg-rrvs-header-field.all@tools.ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.android.email_1142749880429480" X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Cc: The IESG , IETF Apps Discuss Subject: Re: [apps-discuss] Back to draft-ietf-appsawg-rrvs-header-field-05 (was Re: Scope of protocol authority) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Dec 2013 02:01:05 -0000 ----_com.android.email_1142749880429480 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SSBuZXZlciBjbGFpbWVkIGFsbCBtYWlsIHdhcyBvbmUgaG9wLiBNeSBjbGFpbSB3YXMgdGhhdCBn aXZlbiB0aGUgdXNlIGNhc2Ugb2YgYSBsYXJnZSBlbnRlcnByaXNlIHRoYXQgc2VlbmRzIGhpZ2gg dmFsdWUgZW1haWxzIHRvIGNvbnN1bWVycyB3aG8gdXNlIGxhcmdlIE1TUHMsIHRoZSBlbnRlcnBy aXNlIGNvbnRyb2xzIHRoZWlyIE1UQXMgYW5kIHRoZSBsYXJnZSBNU1AgY29udHJvbHMgdGhlaXIg TVRBcy4gSW4gdGhlIHVubGlrZWx5IGV2ZW50IHRoZSBlbnRlcnByaXNlIHJlbGllcyBvbiB0aGVp ciBJU1AgZm9yIG1haWwgZGVsaXZlcnksIHRoZSBsaWtlbGlob29kIG9mIHRoZSBlbnRlcnByaXNl IHN1Y2Nlc3NmdWxseSBuZWdvdGlhdGluZyAoY29tbWVyY2lhbCwgbm90IHByb3RvY29sKSBmb3Ig UlJWUyBzZXJ2aWNlIGlzIHByZXR0eSBoaWdoLiBJdCBpcyBhbHNvIGV4dHJlbWVseSBsaWtlbHkg dGhhdCB0aGUgcGF0aCBmcm9tIHRoZSBlbnRlcnByaXNlJ3MgYm9yZGVyIHRvIHRoZSBNU1AncyBi b3JkZXIgaXMgZGlyZWN0IGlzIHJhdGhlciBoaWdoLsKgCgoKU2VudCBmcm9tIG15IG1vYmlsZSBk ZXZpY2UuIFRoYW5rcyBiZSB0byBMRU1PTkFERTogaHR0cDovL3d3dy5zdGFuZGFyZHN0cmFjay5j b20vaWV0Zi9sZW1vbmFkZQpTMkVSQzogaHR0cDovL3MyZXJjLmdlb3JnZXRvd24uZWR1LwpHQ1ND OiBodHRwOi8vZ2NzYy5nZW9yZ2V0b3duLmVkdS8KTWU6IGh0dHA6Ly93d3cuY3MuZ2VvcmdldG93 bi5lZHUvfiBlYnVyZ2VyCgotLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0tCkZyb206 IERhdmUgQ3JvY2tlciA8ZGhjQGRjcm9ja2VyLm5ldD4gCkRhdGU6MTIvMjgvMjAxMyAgODowOSBQ TSAgKEdNVC0wNTowMCkgClRvOiBFcmljIEJ1cmdlciA8ZWJ1cmdlckBzdGFuZGFyZHN0cmFjay5j b20+LGRyYWZ0LWlldGYtYXBwc2F3Zy1ycnZzLWhlYWRlci1maWVsZC5hbGxAdG9vbHMuaWV0Zi5v cmcgCkNjOiBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz4sSUVURiBBcHBzIERpc2N1c3MgPGFwcHMt ZGlzY3Vzc0BpZXRmLm9yZz4gClN1YmplY3Q6IFJlOiBbYXBwcy1kaXNjdXNzXSBCYWNrIHRvIGRy YWZ0LWlldGYtYXBwc2F3Zy1ycnZzLWhlYWRlci1maWVsZC0wNQ0gICAod2FzIFJlOiBTY29wZSBv ZiBwcm90b2NvbCBhdXRob3JpdHkpIAoKT24gMTIvMjcvMjAxMyAxMDoxMiBBTSwgRXJpYyBCdXJn ZXIgd3JvdGU6Cj4gWWVzLCBhbmQgbG9vayBhdCB0aGUgdXNlIGNhc2UuIElmIHlvdSBhcmUgdGhl IGVudGVycHJpc2Ugc2VuZGluZyB0aGUKPiBtZXNzYWdlLCB5b3Ugd2lsbCB1cGdyYWRlIGFsbCB0 aGUgTVRBcyB1bmRlciB5b3VyIGNvbnRyb2wuIElmIHlvdSBhcmUKPiB0aGUgbWFzc2l2ZSwgcHVi bGljIE1TUCBhZHZlcnRpc2luZyBSUlZTIG9uIHRoZSByZWNlaXZpbmcgc2lkZSzCoCBub3QgYQo+ IHByb2JsZW0uCj4KPiBJZiBpdCBpcyBiMmIsIHRoZW4gYXMgTmVkIHBvaW50ZWQgb3V0LCBldmVu IGlmIHlvdSBhcmUgc2VuZGluZyB0bwo+IGhyQGV4YW1wbGUuY29tLCB5b3UgbW9zdCBsaWtlbHkg ZG9uJ3Qgd2FudCB0aGUgbGFzdCBvbmUuCgoKRXJpYywKCllvdSd2ZSBjaGFuZ2VkIHRoZSBhcmd1 bWVudC4KCkkgd2FzIHJlc3BvbmRpbmcgdG8geW91ciBjbGFpbSB0aGF0IGFsbCBtYWlsIHdhcyBv bmUtaG9wLgoKTm93IHlvdSBhcmUgY2xhaW1pbmcgdGhhdCBlbnRlcnByaXNlcyB1cGdyYWRlIGFs bCB0aGVpciBzZXJ2ZXJzIGF0IHRoZSAKc2FtZSB0aW1lLsKgIEJ1dCBvZiBjb3Vyc2UsIHRoYXQn cyBub3QgdGhlIHdheSBvcGVyYXRpb25zIGluIGxhcmdlIApvcmdhbml6YXRpb25zIHdvcmsuCgpM ZXQncyBtb3ZlIGJhY2sgdG8gdGhlIHNpbXBsZSBhcmNoaXRlY3R1cmFsIGFuZCBvcGVyYXRpb25h bCByZWFsaXR5OiAKRW1haWwgaXMgYSBkaXN0cmlidXRlZCwgbXVsdGktaG9wLsKgIFRoZSBmYWN0 IHRoYXQgcXVpdGUgYSBiaXQgb2YgbWFpbCBpcyAKZXNzZW50aWFsbHkgb25lLWhvcCBpcyBhIGRp c3RyYWN0aW9uIGZyb20gc2VyaW91cyBhcmNoaXRlY3R1cmFsIGRpc2N1c3Npb25zLgoKZC8KCi0t IApEYXZlIENyb2NrZXIKQnJhbmRlbmJ1cmcgSW50ZXJuZXRXb3JraW5nCmJiaXcubmV0Cg== ----_com.android.email_1142749880429480 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSA+PGRpdj5JIG5ldmVyIGNsYWltZWQg YWxsIG1haWwgd2FzIG9uZSBob3AuIE15IGNsYWltIHdhcyB0aGF0IGdpdmVuIHRoZSB1c2UgY2Fz ZSBvZiBhIGxhcmdlIGVudGVycHJpc2UgdGhhdCBzZWVuZHMgaGlnaCB2YWx1ZSBlbWFpbHMgdG8g Y29uc3VtZXJzIHdobyB1c2UgbGFyZ2UgTVNQcywgdGhlIGVudGVycHJpc2UgY29udHJvbHMgdGhl aXIgTVRBcyBhbmQgdGhlIGxhcmdlIE1TUCBjb250cm9scyB0aGVpciBNVEFzLiBJbiB0aGUgdW5s aWtlbHkgZXZlbnQgdGhlIGVudGVycHJpc2UgcmVsaWVzIG9uIHRoZWlyIElTUCBmb3IgbWFpbCBk ZWxpdmVyeSwgdGhlIGxpa2VsaWhvb2Qgb2YgdGhlIGVudGVycHJpc2Ugc3VjY2Vzc2Z1bGx5IG5l Z290aWF0aW5nIChjb21tZXJjaWFsLCBub3QgcHJvdG9jb2wpIGZvciBSUlZTIHNlcnZpY2UgaXMg cHJldHR5IGhpZ2guIEl0IGlzIGFsc28gZXh0cmVtZWx5IGxpa2VseSB0aGF0IHRoZSBwYXRoIGZy b20gdGhlIGVudGVycHJpc2UncyBib3JkZXIgdG8gdGhlIE1TUCdzIGJvcmRlciBpcyBkaXJlY3Qg aXMgcmF0aGVyIGhpZ2guJm5ic3A7PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+ U2VudCBmcm9tIG15IG1vYmlsZSBkZXZpY2UuIFRoYW5rcyBiZSB0byBMRU1PTkFERTogaHR0cDov L3d3dy5zdGFuZGFyZHN0cmFjay5jb20vaWV0Zi9sZW1vbmFkZTxkaXY+UzJFUkM6IGh0dHA6Ly9z MmVyYy5nZW9yZ2V0b3duLmVkdS88L2Rpdj48ZGl2PkdDU0M6IGh0dHA6Ly9nY3NjLmdlb3JnZXRv d24uZWR1LzwvZGl2PjxkaXY+TWU6IGh0dHA6Ly93d3cuY3MuZ2VvcmdldG93bi5lZHUvfiBlYnVy Z2VyPC9kaXY+PGJyPjxicj4tLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0tPGJyPkZy b206IERhdmUgQ3JvY2tlciA8ZGhjQGRjcm9ja2VyLm5ldD4gPGJyPkRhdGU6MTIvMjgvMjAxMyAg ODowOSBQTSAgKEdNVC0wNTowMCkgPGJyPlRvOiBFcmljIEJ1cmdlciA8ZWJ1cmdlckBzdGFuZGFy ZHN0cmFjay5jb20+LGRyYWZ0LWlldGYtYXBwc2F3Zy1ycnZzLWhlYWRlci1maWVsZC5hbGxAdG9v bHMuaWV0Zi5vcmcgPGJyPkNjOiBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz4sSUVURiBBcHBzIERp c2N1c3MgPGFwcHMtZGlzY3Vzc0BpZXRmLm9yZz4gPGJyPlN1YmplY3Q6IFJlOiBbYXBwcy1kaXNj dXNzXSBCYWNrIHRvIGRyYWZ0LWlldGYtYXBwc2F3Zy1ycnZzLWhlYWRlci1maWVsZC0wNQ0gICAo d2FzIFJlOiBTY29wZSBvZiBwcm90b2NvbCBhdXRob3JpdHkpIDxicj48YnI+T24gMTIvMjcvMjAx MyAxMDoxMiBBTSwgRXJpYyBCdXJnZXIgd3JvdGU6PGJyPiZndDsgWWVzLCBhbmQgbG9vayBhdCB0 aGUgdXNlIGNhc2UuIElmIHlvdSBhcmUgdGhlIGVudGVycHJpc2Ugc2VuZGluZyB0aGU8YnI+Jmd0 OyBtZXNzYWdlLCB5b3Ugd2lsbCB1cGdyYWRlIGFsbCB0aGUgTVRBcyB1bmRlciB5b3VyIGNvbnRy b2wuIElmIHlvdSBhcmU8YnI+Jmd0OyB0aGUgbWFzc2l2ZSwgcHVibGljIE1TUCBhZHZlcnRpc2lu ZyBSUlZTIG9uIHRoZSByZWNlaXZpbmcgc2lkZSwmbmJzcDsgbm90IGE8YnI+Jmd0OyBwcm9ibGVt Ljxicj4mZ3Q7PGJyPiZndDsgSWYgaXQgaXMgYjJiLCB0aGVuIGFzIE5lZCBwb2ludGVkIG91dCwg ZXZlbiBpZiB5b3UgYXJlIHNlbmRpbmcgdG88YnI+Jmd0OyBockBleGFtcGxlLmNvbSwgeW91IG1v c3QgbGlrZWx5IGRvbid0IHdhbnQgdGhlIGxhc3Qgb25lLjxicj48YnI+PGJyPkVyaWMsPGJyPjxi cj5Zb3UndmUgY2hhbmdlZCB0aGUgYXJndW1lbnQuPGJyPjxicj5JIHdhcyByZXNwb25kaW5nIHRv IHlvdXIgY2xhaW0gdGhhdCBhbGwgbWFpbCB3YXMgb25lLWhvcC48YnI+PGJyPk5vdyB5b3UgYXJl IGNsYWltaW5nIHRoYXQgZW50ZXJwcmlzZXMgdXBncmFkZSBhbGwgdGhlaXIgc2VydmVycyBhdCB0 aGUgPGJyPnNhbWUgdGltZS4mbmJzcDsgQnV0IG9mIGNvdXJzZSwgdGhhdCdzIG5vdCB0aGUgd2F5 IG9wZXJhdGlvbnMgaW4gbGFyZ2UgPGJyPm9yZ2FuaXphdGlvbnMgd29yay48YnI+PGJyPkxldCdz IG1vdmUgYmFjayB0byB0aGUgc2ltcGxlIGFyY2hpdGVjdHVyYWwgYW5kIG9wZXJhdGlvbmFsIHJl YWxpdHk6IDxicj5FbWFpbCBpcyBhIGRpc3RyaWJ1dGVkLCBtdWx0aS1ob3AuJm5ic3A7IFRoZSBm YWN0IHRoYXQgcXVpdGUgYSBiaXQgb2YgbWFpbCBpcyA8YnI+ZXNzZW50aWFsbHkgb25lLWhvcCBp cyBhIGRpc3RyYWN0aW9uIGZyb20gc2VyaW91cyBhcmNoaXRlY3R1cmFsIGRpc2N1c3Npb25zLjxi cj48YnI+ZC88YnI+PGJyPi0tIDxicj5EYXZlIENyb2NrZXI8YnI+QnJhbmRlbmJ1cmcgSW50ZXJu ZXRXb3JraW5nPGJyPmJiaXcubmV0PGJyPjwvYm9keT4= ----_com.android.email_1142749880429480-- From dhc@dcrocker.net Sat Dec 28 22:58:18 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4B961AE50E; Sat, 28 Dec 2013 22:58:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.8 X-Spam-Level: X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0iFvLgTCfaZ7; Sat, 28 Dec 2013 22:58:17 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 947F61AE50D; Sat, 28 Dec 2013 22:58:17 -0800 (PST) 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 rBT6w8ku021589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 28 Dec 2013 22:58:11 -0800 Message-ID: <52BFC7AA.7060802@dcrocker.net> Date: Sat, 28 Dec 2013 22:56:42 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Eric Burger , draft-ietf-appsawg-rrvs-header-field.all@tools.ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; 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]); Sat, 28 Dec 2013 22:58:12 -0800 (PST) Cc: The IESG , IETF Apps Discuss Subject: Re: [apps-discuss] Back to draft-ietf-appsawg-rrvs-header-field-05 (was Re: Scope of protocol authority) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Dec 2013 06:58:19 -0000 On 12/28/2013 6:00 PM, Eric Burger wrote: > I never claimed all mail was one hop. My claim was that given the use > case of a large enterprise that seends high value emails to consumers > who use large MSPs, the enterprise controls their MTAs and the large MSP > controls their MTAs. In the unlikely event the enterprise relies on > their ISP for mail delivery, the likelihood of the enterprise > successfully negotiating (commercial, not protocol) for RRVS service is > pretty high. It is also extremely likely that the path from the > enterprise's border to the MSP's border is direct is rather high. Eric, With any sufficiently simplified set of assumptions, almost any assertion of feasibility can be justified. However in the real world of enterprise operations, things are usually far more complicated than the model you've put forward. Complicated in a number of different ways. Complicated enough to make assurances of near-term (or 'timely') infrastructure support problematic, in my experience. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From eburger@standardstrack.com Sun Dec 29 04:27:49 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E7DE1AE0A7; Sun, 29 Dec 2013 04:27:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.578 X-Spam-Level: * X-Spam-Status: No, score=1.578 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pDg8y1bQvbqq; Sun, 29 Dec 2013 04:27:48 -0800 (PST) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) by ietfa.amsl.com (Postfix) with ESMTP id 0557E1AE027; Sun, 29 Dec 2013 04:27:48 -0800 (PST) Received: from ip68-100-74-215.dc.dc.cox.net ([68.100.74.215]:61000 helo=[192.168.15.110]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1VxFSz-00069O-8O; Sun, 29 Dec 2013 04:27:37 -0800 Content-Type: multipart/signed; boundary="Apple-Mail=_DF59C286-84DA-42E7-BCD2-8B59DC346C61"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Eric Burger In-Reply-To: <52BFC7AA.7060802@dcrocker.net> Date: Sun, 29 Dec 2013 07:27:33 -0500 Message-Id: <179DBF1C-1A51-4E0E-95C2-57086EF703F0@standardstrack.com> References: <52BFC7AA.7060802@dcrocker.net> To: draft-ietf-appsawg-rrvs-header-field.all@tools.ietf.org X-Mailer: Apple Mail (2.1827) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Cc: The IESG , IETF Apps Discuss Subject: Re: [apps-discuss] Back to draft-ietf-appsawg-rrvs-header-field-05 (was Re: Scope of protocol authority) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Dec 2013 12:27:49 -0000 --Apple-Mail=_DF59C286-84DA-42E7-BCD2-8B59DC346C61 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Thinking about how email gets deployed and why there are multiple MTA=92s = in an enterprise, a lot of them are for filtering. I buy the argument = that it would be a lot easier to change / add a single network element = to implement RRVS than to change everything in the enterprise network. Given that, I would humbly suggest giving up on the SMTP extension and = only rely on the header. The rules and specifications for the header = popping into and out of existence for what everyone on the list is = arguing is a corner case (all MTA=92s in the chain implement RRVS), that = we might as well design for the general case (lots of MTA in the chain, = and almost none of them implement RRVS). Real MTA=92s read headers anyway, so is there any operational harm from = dropping the SMTP extension, even if we all agree it is the right place = to do this processing from an architectural perspective? On Dec 29, 2013, at 1:56 AM, Dave Crocker wrote: > On 12/28/2013 6:00 PM, Eric Burger wrote: >> I never claimed all mail was one hop. My claim was that given the use >> case of a large enterprise that seends high value emails to consumers >> who use large MSPs, the enterprise controls their MTAs and the large = MSP >> controls their MTAs. In the unlikely event the enterprise relies on >> their ISP for mail delivery, the likelihood of the enterprise >> successfully negotiating (commercial, not protocol) for RRVS service = is >> pretty high. It is also extremely likely that the path from the >> enterprise's border to the MSP's border is direct is rather high. >=20 >=20 > Eric, >=20 > With any sufficiently simplified set of assumptions, almost any = assertion of feasibility can be justified. >=20 > However in the real world of enterprise operations, things are usually = far more complicated than the model you've put forward. Complicated in = a number of different ways. Complicated enough to make assurances of = near-term (or 'timely') infrastructure support problematic, in my = experience. >=20 > d/ > --=20 > Dave Crocker > Brandenburg InternetWorking > bbiw.net --Apple-Mail=_DF59C286-84DA-42E7-BCD2-8B59DC346C61 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJSwBU1AAoJEDY/T2tCIPW3wr4P/2ke1lGKyorGnYShFU0yNtDC bcrxrk/ndAVORf5aItQQMsjMPIFpO4ZxGCa0WIu5po+BMNot2iv0NL6rPnQjjzVJ YdFwRCnG97HK3M0MprLqB0vm2wMaN+ejz+udt7mVQzwAGzc+zoBk6jThGL/t7Hmi mwcVDg3zbRVF80EHtQ8RzZjyvFHVwlsOfO8fK+ezikYYc522fbxsYTBwOaRkBXEb bgrFs0VOzMxbZuU6hvRaSLBi9WRS+lxBXs0h971LzAfutkGH4Lt/jXleAEj2c6mx 4E1fta74e2kZDkFCGh8KKrB88ILJ9CMIP7wnaPE2yOnm/duOZzUaDQm2rfMTGip5 itIrgI4h5N3F5iZfp3YDDM9VcBbG3XfjhzjggKeHEIt092EIZRqy8djr0PQvCjk0 24OKu2qBivSpVhj/cROwpXyDm0GvwtAHsWARnjyahIhSN6Tu+3rBtX4Ghog7uf0m 7z6s30O8ltfotz6OBYEwHo6CkYcDExhTGsm/0OeWQDq7VY+C0h/FinIVxhRG1jh6 B5d4qYzOIbj0vVPKheagNuywMvmFdOUfKx4Q6+JcjHQY4REd8RcL0QI9EVqlnuL/ VyVHV+yB7z8j6SscnITCwhyw+0DR9mJCVVHa2CHGyXSiZF92eH1MkyvWLCyo4kjU n16k720CJeT3Y0HTKQBI =muFH -----END PGP SIGNATURE----- --Apple-Mail=_DF59C286-84DA-42E7-BCD2-8B59DC346C61-- From ned.freed@mrochek.com Sun Dec 29 09:09:27 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B90F71AE2D6; Sun, 29 Dec 2013 09:09:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.541 X-Spam-Level: X-Spam-Status: No, score=-0.541 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RgWkWYMkwkrQ; Sun, 29 Dec 2013 09:09:26 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 4D6671AE2D5; Sun, 29 Dec 2013 09:09:26 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P2INBZEK4W001PHS@mauve.mrochek.com>; Sun, 29 Dec 2013 09:04:14 -0800 (PST) MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=windows-1252 Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P23NF74JFK0000AS@mauve.mrochek.com>; Sun, 29 Dec 2013 09:04:08 -0800 (PST) Message-id: <01P2INBWNGTU0000AS@mauve.mrochek.com> Date: Sun, 29 Dec 2013 08:59:07 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Sun, 29 Dec 2013 07:27:33 -0500" <179DBF1C-1A51-4E0E-95C2-57086EF703F0@standardstrack.com> References: <52BFC7AA.7060802@dcrocker.net> <179DBF1C-1A51-4E0E-95C2-57086EF703F0@standardstrack.com> To: Eric Burger Cc: draft-ietf-appsawg-rrvs-header-field.all@tools.ietf.org, The IESG , IETF Apps Discuss Subject: Re: [apps-discuss] Back to draft-ietf-appsawg-rrvs-header-field-05 (was Re: Scope of protocol authority) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Dec 2013 17:09:28 -0000 > Given that, I would humbly suggest giving up on the SMTP extension and only > rely on the header. I strongly object. The extension is both easier to implement correctly as well as far less prone to information leakage. > The rules and specifications for the header popping into and out of > existence for what everyone on the list is arguing is a corner case (all > MTA’s in the chain implement RRVS) I have never made that argument, nor do I believe that this is a corner case. > , that we might as well design for the general case (lots of MTA in the > chain, and almost none of them implement RRVS). And give up on the mechanism that actually works correctly. Not acceptable. > Real MTA’s read headers anyway, so is there any operational harm from > dropping the SMTP extension, even if we all agree it is the right place to do > this processing from an architectural perspective? Yes. See above. Ned From anything@michielbdejong.com Sun Dec 29 18:43:56 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0E991AE38A for ; Sun, 29 Dec 2013 18:43:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LoeVzvNXZ9gw for ; Sun, 29 Dec 2013 18:43:54 -0800 (PST) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [IPv6:2001:4b98:c:538::195]) by ietfa.amsl.com (Postfix) with ESMTP id B3FC61AE389 for ; Sun, 29 Dec 2013 18:43:54 -0800 (PST) Received: from mfilter9-d.gandi.net (mfilter9-d.gandi.net [217.70.178.138]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id 0C9C9A80B4 for ; Mon, 30 Dec 2013 03:43:48 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter9-d.gandi.net Received: from relay3-d.mail.gandi.net ([217.70.183.195]) by mfilter9-d.gandi.net (mfilter9-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id 59ZNtm-9vOPg for ; Mon, 30 Dec 2013 03:43:46 +0100 (CET) X-Originating-IP: 10.58.1.143 Received: from webmail.gandi.net (unknown [10.58.1.143]) (Authenticated sender: anything@michielbdejong.com) by relay3-d.mail.gandi.net (Postfix) with ESMTPA id ABAE7A8092 for ; Mon, 30 Dec 2013 03:43:46 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 30 Dec 2013 08:13:46 +0530 From: "Michiel B. de Jong" To: apps-discuss@ietf.org In-Reply-To: <028901cefbff$ca4b2e40$5ee18ac0$@lanthaler@gmx.net> References: <028901cefbff$ca4b2e40$5ee18ac0$@lanthaler@gmx.net> Message-ID: <98a21b24e4b1da5c7d2b1651a15b6f91@michielbdejong.com> X-Sender: anything@michielbdejong.com User-Agent: Roundcube Webmail/0.9.5 Subject: Re: [apps-discuss] draft-dejong-remotestorage-02 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Dec 2013 02:43:56 -0000 On 2013-12-18 20:15, Markus Lanthaler wrote: > Hi Michiel, > > I just had a look at the final version of > draft-dejong-remotestorage-02. I > noticed that the draft says: > > A successful GET request to a folder SHOULD be responded to with a > JSON-LD [JSON-LD] document (content type 'application/json'), > > Is there any reason why you don't use JSON-LD's content type, i.e., > application/ld+json? > > You also use a "charset" parameter in your examples in section 12 > > Content-Type: application/json; charset=UTF-8 > > .. but neither JSON nor JSON-LD have a charset parameter. You should > thus > simply drop it. ah ok, i didn't know that. thanks! we'll fix this in version -03 (github issue for it is here: https://github.com/remotestorage/spec/issues/55). sorry for the late reply, i was offline for a while. > > > Cheers, > Markus > > > -- > Markus Lanthaler > @markuslanthaler > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From dhc@dcrocker.net Mon Dec 30 10:38:48 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31C281AE538; Mon, 30 Dec 2013 10:38:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JMHPUHvyD2Eb; Mon, 30 Dec 2013 10:38:46 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 705831AE535; Mon, 30 Dec 2013 10:38:46 -0800 (PST) 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 rBUIcaUk018618 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 30 Dec 2013 10:38:40 -0800 Message-ID: <52C1BD55.9050004@dcrocker.net> Date: Mon, 30 Dec 2013 10:37:09 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Eric Burger , draft-ietf-appsawg-rrvs-header-field.all@tools.ietf.org References: <52BFC7AA.7060802@dcrocker.net> <179DBF1C-1A51-4E0E-95C2-57086EF703F0@standardstrack.com> In-Reply-To: <179DBF1C-1A51-4E0E-95C2-57086EF703F0@standardstrack.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Mon, 30 Dec 2013 10:38:40 -0800 (PST) Cc: The IESG , IETF Apps Discuss Subject: Re: [apps-discuss] Back to draft-ietf-appsawg-rrvs-header-field-05 (was Re: Scope of protocol authority) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Dec 2013 18:38:48 -0000 Eric, On 12/29/2013 4:27 AM, Eric Burger wrote: > Thinking about how email gets deployed and why there are multiple > MTA’s in an enterprise, a lot of them are for filtering. I buy the And a lot aren't. Real-world operational networking environments make all sorts of different topology choices. To repeat an example cited earlier, there is case of department-vs-enterprise division of labor. Anyhow the nature of the use seems to be irrelevant to the current discussion. So why do you cite it? The point being made was that email is often multi-hop. It was offered to counter your claim that it's direct. > argument that it would be a lot easier to change / add a single > network element to implement RRVS than to change everything in the > enterprise network. > > Given that, I would humbly suggest giving up on the SMTP extension > and only rely on the header. Except that it doesn't permit the kind of handling assurance the SMTP option does. The two mechanisms have different enforcement and adoption trade-offs and hence satisfy /very/ different operational needs. You don't seem to be raising any claims of technical deficiency, so I do not understand the basis for your insisting that there are problems with the spec. > The rules and specifications for the > header popping into and out of existence for what everyone on the > list is arguing is a corner case (all MTA’s in the chain implement As Ned notes and as I've been trying to stress, multi-hop is more common than folks seem to realize. Hence, not a corner case. > RRVS), that we might as well design for the general case (lots of MTA > in the chain, and almost none of them implement RRVS). > > Real MTA’s read headers anyway, Perhaps you have heard of the Shannon-Weaver model for communication, with the essential enhancement over the original version, where "feedback" is added, to close the loop. What you are proposing loses that essential capability, which the SMTP option provides. Hence it loses the ability to make enforcement assurances to the requester. Again, I'm entirely missing what is driving your concerns, especially since your suggestions seem to keep shifting. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dhc@dcrocker.net Tue Dec 31 07:53:48 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 163B81AE0E9 for ; Tue, 31 Dec 2013 07:53:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S1ta7L34GkDC for ; Tue, 31 Dec 2013 07:53:44 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 229791AE0DA for ; Tue, 31 Dec 2013 07:53:44 -0800 (PST) Received: from [192.168.1.6] (cpe-76-93-140-82.san.res.rr.com [76.93.140.82]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id rBVFrYsn003195 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 31 Dec 2013 07:53:37 -0800 Message-ID: <52C2E825.9010405@dcrocker.net> Date: Tue, 31 Dec 2013 07:52:05 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: draft-ietf-appsawg-uri-get-off-my-lawn.all@tools.ietf.org, apps-discuss@ietf.org 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]); Tue, 31 Dec 2013 07:53:38 -0800 (PST) Subject: [apps-discuss] Review of: draft-ietf-appsawg-uri-get-off-my-lawn-00 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Dec 2013 15:53:48 -0000 G'day. I have been selected as the Applications Area Review Team reviewer for this draft (for background on apps-review, please see http://www.apps.ietf.org/content/applications-area-review-team). Please resolve these comments along with any other comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. NOTE: This was assigned as an 'early' review. So the review is not being sent to the IESG. DISCLAIMER: I've read the discussion thread that took place on the apps list with Tim Bray's review. To the extent that my comments match his, that's great. To the extent that they don't /and/ my comments seem to be wrong or misguided, please consider that many readers of this document will not be experts in URI technical details and probably won't put the effort into reading the spec that I just did. In other words, if I am confused after reading the doc, others probably will be too... Document: draft-ietf-appsawg-uri-get-off-my-lawn-00 Title: Standardising Structure in URIs Reviewer: D. Crocker Review Date: 31 December 2013 Summary: URIs are the core citation and client transaction (request) form on the Internet. Anything used that widely and in such variable circumstances is likely to get ad hoc tailoring for use with particular applications and/or particular implementations and/or particular servers. The "and/or" combinations highlight the potential for chaotic tailoring which, therefore, creates ambiguities and conflicts. The current draft seeks to impose better global discipline on the use of URIs. For a construct as important as a URI, the importance of moving towards clean and unconflicted use can't be overstated. However the requirements that prompt the ad hoc tailoring typically are legitimate, even if the method of dealing with it is problematic. So the challenges here are in clarity and precision about what should /not/ be done, sufficiency in the available alternatives, and clarity in the way all this is explained. Any specification needs to worry that it is adequately understandable to a reader new to the topic, but in the case of a document attempting to repair existing confusion and misbehavior, it is especially important: the document needs an added degree of tight and coherent organization, with very pedantic logical sequences to what is said, and very careful wording that says it. Unfortunately, at the highest level, I'm not sure how this document can be used, for those most needing to use it. It's not a question of whether the document isn't chock full of specific advice. And the issue is separate from agreeing or disagreeing with any of the points made in the document. It's a question of how it is organized for long-term use. The current form of the document doesn't seem tightly-enough organized for that use, but I'm not sure what to suggest. In addition, it varies between portions that appear to be protocol specification, versus portions that appear to be best current practices. Also I found myself periodically confused about the exact meaning of text in the document. Some of this might merely need somewhat more careful wording. Some of the confusion might be due to deeper issues with the document. I'm not sure. Obviously some of the confusion could be my own limitations, but I spent some time trying to track things down and was still left confused, as noted below. The title of the document asserts that it is /creating/ structure for URI's, but I believe it is, instead, mostly clarifying /existing/ structure. Beyond that I believe that it is at most making -- or, at least, intending to make -- modest tweaks. (I see that as a Good Thing, for something like this. Anything more ambitious would probably disrupt current, legitimate uses of URIs...) Detailed Comments: > 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"). This implies that URIs must not have any 'features' or 'structure'. I think that what is meant is more limited than that. So what is needed is a statement to balance, that indicates what is normal and acceptable. Maybe that's just a pointer to Section 3, but I suspect there's more needed than that. Note, for example, that the URI spec (RFC 3986) allocates the role of providing "generative grammar for URIs; that task is performed by the individual specifications of each URI scheme." A grammar is, by definition, a structure. So some sorts of structures are acceptable, in some sorts of specifications. What is ok and what isn't ok needs to be clarified. That leaves a basic question for the current draft: when/where is acceptable for specifying functions and structures in a URI and when/where isn't? In addition, the use of sub-structure in URI's is integral to many, established web practices. Again: this document needs to distinguish between those and whatever others that are /not/ acceptable. > 1. Introduction > > URIs [RFC3986] very often include structured application data. This In spite of the examples provided in the next sentence, it isn't obvious to me what "structured application data" means. Yet it's the key construct for the document. > might include artifacts from filesystems (often occurring in the path > component), and user information (often in the query component). In > some cases, there can even be application-specific data in the > authority component (e.g., some applications are spread across > several hostnames to enable a form of partitioning or dispatch). > > Furthermore, constraints upon the structure of URIs can be imposed by > an implementation; for example, many Web servers use the filename > extension of the last path segment to determine the media type of the > response. Likewise, pre-packaged applications often have highly > structured URIs that can only be changed in limited ways (often, just > the hostname and port they are deployed upon). > > Because the owner of the URI is choosing to use the server or the > software, this can be seen as reasonable delegation of authority. > When such conventions are mandated by standards, however, it can have > several potentially detrimental effects: > > o Collisions - As more conventions for URI structure become > standardised, it becomes more likely that there will be collisions If indeed they are being standardized, then the real issue is to have coordination of the standards documents, through a registry or the like. > between such conventions (especially considering that servers, > applications and individual deployments will have their own > conventions). > o Dilution - Adorning URIs with extra information to support new > standard features dilutes their usefulness as identifiers when > that information is ephemeral (as URIs ought to be stable; see > [webarch] Section 3.5.1), or its inclusion causes several > alternate forms of the URI to exist (see [webarch] Section 2.3.1). hmmm. The more I look the document over, the more it seems that the issue here is a conflict between use of a URI as an actual "identifier" for some data, versus use as a query mechanisms (which produces some data). The latter lends itself to extra parameters and ad hoc techniques, whereas the former seems less likely to. > o Brittleness - A standard that specifies a static URI cannot change > its form in future revisions. I don't really understand what the explanation of brittleness means. But I think the word that fits what is described is "rigidity", not "brittleness". The URI doesn't break. Rather, use of ad hoc conventions means the range of operational uses isn't as flexible as desired. I've searched through a number of the documents cited in the References section. None of them defines "static URI", nor does it appear to be in common use online. I don't have a good guess about its meaning. Perhaps it mean "tied to a specific use"? Anyhow, it needs to be defined. > o Operational Difficulty - Supporting some URI conventions can be > difficult in some implementations. For example, specifying that a > particular query parameter be used precludes the use of Web > servers that serve the response from a filesystem. Huh? > Likewise, an > application that fixes a base path for its operation (e.g., "/v1") > makes it impossible to deploy other applications with the same > prefix on the same host. > o Client Assumptions - When conventions are standardised, some > clients will inevitably assume that the standards are in use when > those conventions are seen. Well, uh, yeah. I suspect the word "standardize" is being used ambiguously in this document, to mean both "formal" standards and "common practice" (de fact). For the text here, perhaps: When ad hoc conventions are used, some clients are likely to assume that they are universal, rather than ad hoc, and so will assume that the conventions apply in scenarios that do not work. > This can lead to interoperability > problems; for example, if a specification documents that the "sig" > URI query parameter indicates that its payload is a cryptographic > signature for the URI, it can lead to false positives. The example seems to presume that the attribute associated with 'sig' will incorrectly validate as a signature. What are the odds of that, if the sig is using competent modern cryptography? False negatives seem more likely. > While it is not ideal when a server or a deployed application > > > > Nottingham Expires March 21, 2014 [Page 3] > > Internet-Draft URI Structure Policies September 2013 > > > constrains URI structure (indeed, this is not recommended practice, > but that discussion is out of scope for this document), publishing > standards that mandate URI structure is inappropriate because the > structure of a URI needs to be firmly under the control of its owner, See comment above, in Abstract: the URI spec assigns exactly that role to exactly such documents. But perhaps I've misunderstood that doc or this one? > and the IETF (as well as other organisations) should not usurp this > ownership; see [webarch] Section 2.2.2.1. Huh? > > This document explains best current practices for establishing URI > structures, conventions and formats in standards. It also offers > strategies for specifications to avoid violating these guidelines in > Section 3. > > 1.1. Who This Document Is For > > These guidelines are IETF Best Current Practice, and are therefore > binding upon IETF standards-track documents, as well as submissions > to the RFC Editor on the Independent and IRTF streams. See [RFC2026] > and [RFC4844] for more information. Having a document like this make such a broad and absolute assertion seems inappropriate. > > Other Open Standards organisations (in the sense of [RFC2026]) are > encouraged to adopt them. Questions as to their applicability ought > to be handled through the liaison relationship, if present. > > Ad hoc efforts are also encouraged to adopt them, as this RFC > reflects Best Current Practice. Instead of making the above statements of "authority" over other documents, it would be more useful for the text to describe the nature of its utility and, therefore, /when/ it should apply. I think the draft text that follows this probably suffices for that. > > This document's requirements specifically targets a few different specifically targets -> target > types of specifications: > > o URI Scheme Definitions ("scheme definitions") - specifications > that define and register URI schemes, as per [RFC4395]. > o Protocol Extensions ("extensions") - specifications that offer new > capabilities to potentially any identifier, or a large subset; > e.g., a new signature mechanism for 'http' URIs, or metadata for > any URI. How are these formally/notationally distinguished? For example, must they be issued as updates to existing definitions? > o Applications Using URIs ("applications") - specifications that use > URIs to meet specific needs; e.g., a HTTP interface to particular > information on a host. > > Requirements that target the generic class "Specifications" apply to > all specifications, including both those enumerated above above and > others. This document makes requirements on all other specifications ever written? > > Note that this specification ought not be interpreted as preventing > the allocation of control of URIs by parties that legitimately own > them, or have delegated that ownership; for example, a specification > might legitimately specify the semantics of a URI on the IANA.ORG Web > site as part of the establishment of a registry. How is that meaningfully different from the specifications done by the IETF, or others, that are /not/ legitimate? > Nottingham Expires March 21, 2014 [Page 4] > > Internet-Draft URI Structure Policies September 2013 > > > 1.2. Notational Conventions > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in [RFC2119]. > > > 2. Best Current Practices for Standardising Structured URIs > > Different components of a URI have differing practices recommended. > > 2.1. URI Schemes > > Applications and extensions MAY require use of specific URI > scheme(s); for example, it is perfectly acceptable to require that an > application support 'http' and 'https' URIs. However, applications > SHOULD NOT preclude the use of other URI schemes in the future, to > promote reuse, unless they are clearly specific to the nominated > schemes. What does it mean, in practical, technical terms, to not preclude use of other schemes? (A desire to avoid limiting future specification choices is always nice, but knowing what will and won't limit things isn't always obvious.) For example, how is it reasonable for a file transfer application to be required to permit use of a mailto: or sip: scheme? zThe current wording seems to imply such flexibility. Also, "reuse"? What does that mean? > Specifications MUST NOT define substructure within URI schemes, > unless they do so by modifying [RFC4395], or they are the > registration document for the URI scheme(s) in question. This should be stated as an affirmative, rather than a negative. For example: A specification that defines substructure within URI scheme MUST do so by modifying [RFC4395], or as a registration document for the URI scheme in question. > > 2.2. URI Authorities > > Scheme definitions define the presence, format and semantics of an > authority component in URIs; all other specifications MUST NOT > constrain, define structure or semantics for them. 'them'? I think the phrasing needs to be: all other specifications MUST NOT constrain or define URI authority structure or semantics. > > 2.3. URI Paths > > Scheme definitions define the presence, format, and semantics of a > path component in URIs; all other specifications MUST NOT constrain, > define structure or semantics for any path component. same suggested rewording, as above. > The only exception to this requirement is registered "well-known" > URIs, as specified by [RFC5785]. See that document for a description > of the applicability of that mechanism. > > 2.4. URI Queries > > The presence, format and semantics of the query component of URIs is > dependent upon many factors, and MAY be constrained by a scheme > definition. Often, they are determined by the implementation of a > resource itself. And again... > Applications SHOULD NOT directly specify the syntax of queries, as > > > > Nottingham Expires March 21, 2014 [Page 5] > > Internet-Draft URI Structure Policies September 2013 > > > this can cause operational difficulties for deployments that do not > support a particular form of a query. The implication of this is that all applications that accept any queries must accept all queries. But that doesn't make sense. The nature of an application constrains what types of queries it can process usefully. > Extensions MUST NOT specify the format or semantics of queries. In > particular, extensions MUST NOT assume that all HTTP(S) resources are > capable of accepting queries in the format defined by [HTML4], > Section 17.13.4. The first sentence seems to mean that a "protocol extension" is not allowed to extend a protocol to support queries. But the second sentence clearly means otherwise. I'm obviously misunderstanding what this means or how it is to be applied. > 2.5. URI Fragment Identifiers > > Media type definitions (as per [RFC6838] SHOULD specify the fragment > identifier syntax(es) to be used with them; other specifications MUST > NOT define structure within the fragment identifier, unless they are > explicitly defining one for reuse by media type definitions. Cite where fragment identifiers are defined: rfc3986, section-3.5 > 3. Alternatives to Specifying Static URIs Per the comment earlier in the review: What is a static URI? > Given the issues above, the most successful strategy for applications > and extensions that wish to use URIs is to use them in the fashion > they were designed; as run-time artifacts that are exchanged as part > of the protocol, rather than statically specified syntax. > > For example, if a specific URI needs to be known to interact with an I'm not sure what it means for a URI to be "known to interact" with an application. A URI isn't a protocol; it's a format. And so I don't think of it as "interacting". Do you mean that an application accepts a particular URI or that the application uses the URI? > application, its "shape" can be determined by interacting with the I've searched a number of the documents cited in the references and none of them uses the word 'shape'. What does it mean here? > application's more general interface (in Web terms, its "home page") > to learn about that URI. How? This seems a hugely important point but it contains no technical detail. In general, this document would be greatly aided by many more examples, including examples that show the wrong way something is often done and then the right way it should be done. > [RFC5988] describes a framework for identifying the semantics of a It seems to be more substantive/precise than a 'framework'. Indeed, it says it "specifies relation types" and a registry for them. So: [RFC5988] specifies relation types for Web links. > link in a "link relation type" to aid this. [RFC6570] provides a > standard syntax for "link templates" that can be used to dynamically That document does not use the term "link template", although it does refer to using URI templates with reference to links: URI Templates can have many uses, including the discovery of available services, configuring resource mappings, defining computed links, specifying interfaces, and other forms of programmatic interaction with resources. I think the sentence here works adequately by simply using that document's own term "URI templates". > insert application-specific variables into a URI to enable such > applications while avoiding impinging upon URI owners' control of > them. > > [RFC5785] allows specific paths to be 'reserved' for standard use on > URI schemes that opt into that mechanism ('http' and 'https' by > default). Note, however, that this is not a general "escape valve" > for applications that need structured URIs; see that specification > for more information. > > Specifying more elaborate structures in an attempt to avoid > collisions is not adequate to conform to this document. For example, > prefixing query parameters with "myapp_" does not help. This last paragraph is a useful, but small, tidbit. It belongs elsewhere in the document, possibly in the introduction, where the case for the current problem is being made. Hence, an example of some hack that doesn't solve the problem makes sense there. However I suggest that the paragraph be expanded to explain why this particular hack does not suffice. (Even if the explanation seems obvious.) > > > > > > > > Nottingham Expires March 21, 2014 [Page 6] > > Internet-Draft URI Structure Policies September 2013 > > > 4. Security Considerations > > This document does not introduce new protocol artifacts with security > considerations. Hmmm. This draft touches on ambiguity and false positives/negatives. I would think that these have some potential security implications. > > > 5. IANA Considerations > > This document clarifies appropriate registry policy for new URI > schemes, and potentially for the creation of new URI-related > registries, if they attempt to mandate structure within URIs. There > are no direct IANA actions specified in this document. > > > 6. References > > 6.1. Normative References > > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, March 1997. > > [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform > Resource Identifier (URI): Generic Syntax", STD 66, > RFC 3986, January 2005. > > [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and > Registration Procedures for New URI Schemes", BCP 35, > RFC 4395, February 2006. > > [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type > Specifications and Registration Procedures", BCP 13, > RFC 6838, January 2013. > > 6.2. Informative References > > [HTML4] Jacobs, I., Le Hors, A., and D. Raggett, "HTML 4.01 > Specification", December 1999, > . > > [RFC2026] Bradner, S., "The Internet Standards Process -- Revision > 3", BCP 9, RFC 2026, October 1996. > > [RFC4844] Daigle, L. and Internet Architecture Board, "The RFC > Series and RFC Editor", RFC 4844, July 2007. > > [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known > Uniform Resource Identifiers (URIs)", RFC 5785, > April 2010. > > > > Nottingham Expires March 21, 2014 [Page 7] > > Internet-Draft URI Structure Policies September 2013 > > > [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. > > [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., > and D. Orchard, "URI Template", RFC 6570, March 2012. > > [webarch] Jacobs, I. and N. Walsh, "Architecture of the World Wide > Web, Volume One", December 2004, > . > > > Appendix A. Acknowledgments > > Thanks to David Booth, Anne van Kesteren and Erik Wilde for their > suggestions and feedback. > > > Author's Address > > Mark Nottingham > > Email: mnot@mnot.net > URI: http://www.mnot.net/ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Nottingham Expires March 21, 2014 [Page 8] > -- Dave Crocker Brandenburg InternetWorking bbiw.net -- Dave Crocker Brandenburg InternetWorking bbiw.net From eburger@standardstrack.com Tue Dec 31 11:55:17 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C2441AE465; Tue, 31 Dec 2013 11:55:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.578 X-Spam-Level: * X-Spam-Status: No, score=1.578 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id egM56w4pkzgs; Tue, 31 Dec 2013 11:55:15 -0800 (PST) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) by ietfa.amsl.com (Postfix) with ESMTP id 4CA341AE46C; Tue, 31 Dec 2013 11:55:15 -0800 (PST) Received: from 20.sub-70-192-226.myvzw.com ([70.192.226.20]:13524 helo=[192.168.43.132]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from ) id 1Vy5P2-0006Lj-Tf; Tue, 31 Dec 2013 11:55:01 -0800 Content-Type: multipart/signed; boundary="Apple-Mail=_052F25E6-29F1-4F12-9167-BF968A675CDE"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Eric Burger In-Reply-To: <52C1BD55.9050004@dcrocker.net> Date: Tue, 31 Dec 2013 14:55:03 -0500 Message-Id: <0C14D25A-FD99-43D7-94B7-71679066D403@standardstrack.com> References: <52BFC7AA.7060802@dcrocker.net> <179DBF1C-1A51-4E0E-95C2-57086EF703F0@standardstrack.com> <52C1BD55.9050004@dcrocker.net> To: Crocker Dave X-Mailer: Apple Mail (2.1827) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Cc: draft-ietf-appsawg-rrvs-header-field.all@tools.ietf.org, The IESG , IETF Apps Discuss Subject: Re: [apps-discuss] Back to draft-ietf-appsawg-rrvs-header-field-05 (was Re: Scope of protocol authority) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Dec 2013 19:55:17 -0000 --Apple-Mail=_052F25E6-29F1-4F12-9167-BF968A675CDE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Dec 30, 2013, at 1:37 PM, Dave Crocker wrote: > Eric, >=20 > On 12/29/2013 4:27 AM, Eric Burger wrote: >> Thinking about how email gets deployed and why there are multiple >> MTA=92s in an enterprise, a lot of them are for filtering. I buy the >=20 > And a lot aren't. Real-world operational networking environments = make all sorts of different topology choices. To repeat an example = cited earlier, there is case of department-vs-enterprise division of = labor. >=20 > Anyhow the nature of the use seems to be irrelevant to the current = discussion. So why do you cite it? The point being made was that email = is often multi-hop. It was offered to counter your claim that it's = direct. Reminder: I NEVER said email was direct. My assertion was that it is = most often, but not always, direct between the sending enterprise and = the MSP. On the one hand, no one has EVER said that was not the case. On = the other hand, it does not matter, so I dropped it last week. > argument that it would be a lot easier to change / add a single >> network element to implement RRVS than to change everything in the >> enterprise network. >>=20 >> Given that, I would humbly suggest giving up on the SMTP extension >> and only rely on the header. >=20 > Except that it doesn't permit the kind of handling assurance the SMTP = option does. >=20 > The two mechanisms have different enforcement and adoption trade-offs = and hence satisfy /very/ different operational needs. >=20 > You don't seem to be raising any claims of technical deficiency, so I = do not understand the basis for your insisting that there are problems = with the spec. I guess my IETF sensibilities were sensitized. The spec is very = confusing and has a lot of machinery to deal with a hop here that = understands RRVS and a hop there that does not and a hop over there that = sort of understands RRVS. My observation was that if one went for = architectural purity, e.g., only have an SMTP Extension, the people who = need this today can get what they need. So far, no one has SAID I am = wrong with this assertion, as people have been focusing on the red = herring of thinking what I said was that email was direct, with no = intervening MTAs. Subsequently, and without anyone pointing it out, *I* pointed out that I = could see situations where it would be hard for an enterprise to get all = of their internal MTA=92s to support RRVS. > The rules and specifications for the >> header popping into and out of existence for what everyone on the >> list is arguing is a corner case (all MTA=92s in the chain implement >=20 > As Ned notes and as I've been trying to stress, multi-hop is more = common than folks seem to realize. Hence, not a corner case. I never said the corner case is multi-hop! RTFE. I said the corner case = is where there are intervening MTAs that are not under the direct = control of the sending enterprise or under the direct control of the = MSP. RTFE. > RRVS), that we might as well design for the general case (lots of MTA >> in the chain, and almost none of them implement RRVS). >>=20 >> Real MTA=92s read headers anyway, >=20 > Perhaps you have heard of the Shannon-Weaver model for communication, = with the essential enhancement over the original version, where = "feedback" is added, to close the loop. What you are proposing loses = that essential capability, which the SMTP option provides. Hence it = loses the ability to make enforcement assurances to the requester. >=20 >=20 > Again, I'm entirely missing what is driving your concerns, especially = since your suggestions seem to keep shifting. What I am not understanding is when I say that we should use a mechanism = with direct feedback (SMTP extension), I get told that most email gets = delivered multi hop. When I say multi hop is a red herring, because = those hops are almost always under the control of those who would = upgrade their servers to support RRVS, I get told that I am ignorant, = because most email gets delivered multi hop. So, here is disconnect #1. = Multi hop is not the issue. Who controls the servers, and whether they = get support for RRVS is the issue. When I say, OK, if the assertion is that email gets delivered multi hop = and most random hops will never support RRVS, then why bother doing RRVS = as an SMTP extension, I get told that it is important to have a real, = closed loop protocol. When I point out that is where I started, I get = told that I am ignorant, because most random MTAs will not implement = RRVS. When I point out that if that is the case, and you do not believe = that the people who want this extension will implement the = specification, I throw up my hands and say enjoy publishing. No veto here, just pointing out that we are in a circular loop of = shifting requirements and a realization and ignoring of the reality of = the network topology this draft is supposed to be addressing. --Apple-Mail=_052F25E6-29F1-4F12-9167-BF968A675CDE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJSwyEXAAoJEDY/T2tCIPW3jzMP/1e+9NG6Ya775qw028hPJqAD MRzboyTQQAvRLFb8AOYSV1SsxkrCXRCgUhtWm7zmZuP5Jlu6pDwmwHu0kdI3pNXr 4of2GzuxPOALNRE4SSJPv6FVtf0mnd46mVXLWH0O6t6lRohYIqYTo+1BHEfS7QpZ aKTTWJO4ZalKcYvQPl5nbTCXv+52v1CFbLw6vjBNqAvpfq0H+bZOG7awoaCOsx0r nkOGjsfmcU6CftUqR8ChJmqVlDfAUrU7bonXs6E2qAUFxU9Ld12nt4qnLFvCQsvH 71mDuo+bcl0XKD20g3YO5T5X1duqEvM84IL7xmRr/22WydsvI/pH0Ue8ks/hOEEf YxIhGcUBaGx9xWqNHHuVWQxkoQFBa5xLCj53tpwL9laZ3iWdtWIw/G8OVh2rjKJ/ TYUr/8SYvkdetSg1Ad32+WwOetCZOAIC7Ccxx2MLOTfg+cAeETz5W7OG9tlYAhkt VCI66NvbZVtRjEhZklTitaj7f0OWZNNzf+g0tp8Zk4SfDZ39NSf5btFiAlHIJnLd yUA/l+w3HWHHlvipwGHr93flZV93gyNQlZNIYA2dPWhTBoNh2fMOMbpv2PWbXc1Y pHcSrOq9LjcB3gMrxogKtJi0LvlcfQK9+8SzDuVS7zrFKjIyR2Wy/JoY3koq8cHj QMvdBXfukdu9MpLEfVZd =v9d6 -----END PGP SIGNATURE----- --Apple-Mail=_052F25E6-29F1-4F12-9167-BF968A675CDE-- From superuser@gmail.com Tue Dec 31 17:25:20 2013 Return-Path: X-Original-To: apps-discuss@ietfa.amsl.com Delivered-To: apps-discuss@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CBF11AE47C; Tue, 31 Dec 2013 17:25:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BAfRE4KhIgVQ; Tue, 31 Dec 2013 17:25:17 -0800 (PST) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 762891AE477; Tue, 31 Dec 2013 17:25:17 -0800 (PST) Received: by mail-we0-f182.google.com with SMTP id q59so11268471wes.41 for ; Tue, 31 Dec 2013 17:25:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4Hh65ImxbPBGNYOFgw37j7W9kbbKQjCTGSIjSwV2bbY=; b=a7fHzvMsVB0lasKU4cIBMJiKbILzZarMmje9xTx1TZSK562Gs5rbKNwhok7EddiV6t DU1fTe8AfCmSAKyYiQ7pXpfA+VfM9senGYVc8Hj2xu6/jjfCgs8caM3UaKbgKcUevs5V mq1pxHIq/DS0035Jxq1T32jaMmXclrAni5UL36dRLzuuXfhlbv8UvQqetQT/NUUMSizy Z/6uHe4Pce5oGX1JhXQ64UbWl6qvvvP6+ZTr5nOpEkp4E2/vWaCzvrVrBGnmk5p3s2J0 WjsfHXE90z+EpnYTSJnlyfQKfdHq7wlelipjBDxUJ6YEGhlklFp73MiXxyupL/sNcdPe RLAw== MIME-Version: 1.0 X-Received: by 10.180.39.177 with SMTP id q17mr27915180wik.5.1388539510472; Tue, 31 Dec 2013 17:25:10 -0800 (PST) Received: by 10.180.84.106 with HTTP; Tue, 31 Dec 2013 17:25:10 -0800 (PST) In-Reply-To: <0C14D25A-FD99-43D7-94B7-71679066D403@standardstrack.com> References: <52BFC7AA.7060802@dcrocker.net> <179DBF1C-1A51-4E0E-95C2-57086EF703F0@standardstrack.com> <52C1BD55.9050004@dcrocker.net> <0C14D25A-FD99-43D7-94B7-71679066D403@standardstrack.com> Date: Tue, 31 Dec 2013 17:25:10 -0800 Message-ID: From: "Murray S. Kucherawy" To: Eric Burger Content-Type: multipart/alternative; boundary=001a11c228d24745e104eede8ca4 Cc: draft-ietf-appsawg-rrvs-header-field.all@tools.ietf.org, Crocker Dave , IETF Apps Discuss , The IESG Subject: Re: [apps-discuss] Back to draft-ietf-appsawg-rrvs-header-field-05 (was Re: Scope of protocol authority) X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jan 2014 01:25:20 -0000 --001a11c228d24745e104eede8ca4 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Dec 31, 2013 at 11:55 AM, Eric Burger wrote: > > No veto here, just pointing out that we are in a circular loop of shifting > requirements and a realization and ignoring of the reality of the network > topology this draft is supposed to be addressing. > > I don't understand why there's a perception of shifting requirements. Rather, the two approaches have different capabilities and attempt to address different parts of the ecosystem. The SMTP extension route is architecturally speaking more correct for reasons identified in the draft -- and according to Ned at least, easier to implement -- while the header field has a much lower barrier to entry and actually is in production use. There isn't a single true topology to address here. The sender can decide which method is most practical given its own operational and security concerns. -MSK --001a11c228d24745e104eede8ca4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Dec 31, 2013 at 11:55 AM, Eric Burger <e= burger@standardstrack.com> wrote:

No veto here, just pointing out that we are in a circular loop of shifting = requirements and a realization and ignoring of the reality of the network t= opology this draft is supposed to be addressing.


I don't understand why there's= a perception of shifting requirements.=A0 Rather, the two approaches have = different capabilities and attempt to address different parts of the ecosys= tem.=A0 The SMTP extension route is architecturally speaking more correct f= or reasons identified in the draft -- and according to Ned at least, easier= to implement -- while the header field has a much lower barrier to entry a= nd actually is in production use.

There isn't a single true topology to address here.=A0 T= he sender can decide which method is most practical given its own operation= al and security concerns.

-MSK
--001a11c228d24745e104eede8ca4--