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.

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



--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
--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 --_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 :)
--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 sko