From superuser@gmail.com  Wed Jan  1 07:05:53 2014
Return-Path: <superuser@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B936B1AE02E for <apps-discuss@ietfa.amsl.com>; Wed,  1 Jan 2014 07:05:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LyCZdwO3QKtX for <apps-discuss@ietfa.amsl.com>; Wed,  1 Jan 2014 07:05:52 -0800 (PST)
Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id B6CAD1AE303 for <apps-discuss@ietf.org>; Wed,  1 Jan 2014 07:05:26 -0800 (PST)
Received: by mail-wi0-f172.google.com with SMTP id en1so17977507wid.17 for <apps-discuss@ietf.org>; Wed, 01 Jan 2014 07:05:19 -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=SS5BOmFgB2A8KRnh1vPC5xt9fIbIb3Jc3yRndM8UCH4=; b=GOJY4Z7812OFLxIku/Jxes/BRmPQSlKTnko8rlYzCVAGpKN5KvVYX245ken2LCBIZw 8S+e8IZCWWuEc52hDdr7QhnU+v+WD+PvVecxWUP2yEFwGeNOKX1+cAFexi4DA37sxnUy WbGVozllCNs5Qq8k+d+9fTkAlkFH6CXhceNDRN+6pQZT+6GgvIKtyhp/q8BA0VTzawXV GzdCqm7gAR958CKElAhQsQXSjyUDcAPBi7EBpa/drWji3fXGFxRKLBATIkhXEIyFbCda Ojavgp4AejgLCmvFXALI3HWYrdwEO6WXIUTI4wzR/jjrWgXRCFTOPN3qWsYcmjK40pky 7aTQ==
MIME-Version: 1.0
X-Received: by 10.180.39.177 with SMTP id q17mr29684792wik.5.1388588719703; Wed, 01 Jan 2014 07:05:19 -0800 (PST)
Received: by 10.180.84.106 with HTTP; Wed, 1 Jan 2014 07:05:19 -0800 (PST)
Date: Wed, 1 Jan 2014 07:05:19 -0800
Message-ID: <CAL0qLwZqJPTssNVLLaSjAP5wqteZ==fuawNF+WUZYvi+YWV1UQ@mail.gmail.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
To: IETF Apps Discuss <apps-discuss@ietf.org>
Content-Type: multipart/alternative; boundary=001a11c228d2608cf704eeea013e
Subject: [apps-discuss] REMINDER: Working Group Last Calls still open
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Jan 2014 15:05:53 -0000

--001a11c228d2608cf704eeea013e
Content-Type: text/plain; charset=ISO-8859-1

Colleagues,

I know many of us are busy or away possibly until next week.  This is just
a reminder that there are three documents in Working Group Last Call state,
extended for the holidays.  After two and a half weeks, there has been a
lot of commentary on one of them, a small amount on a second, and none on
the third.  Please remember to schedule some time to provide reviews and
commentary on all of them early in the new year so they can be advanced to
make room for new work.

The documents are:

draft-ietf-appsawg-sieve-duplicate
draft-ietf-appsawg-rrvs-header-field
draft-ietf-appsawg-xml-mediatypes

Happy 2014 to everyone!

-MSK, APPSAWG co-chair

--001a11c228d2608cf704eeea013e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div>Colleagues,<br><br>I know many of us are busy or=
 away possibly until next week.=A0 This is just a reminder that there are t=
hree documents in Working Group Last Call state, extended for the holidays.=
=A0 After two and a half weeks, there has been a lot of commentary on one o=
f them, a small amount on a second, and none on the third.=A0 Please rememb=
er to schedule some time to provide reviews and commentary on all of them e=
arly in the new year so they can be advanced to make room for new work.<br>
<br></div><div>The documents are:<br><br></div><div>draft-ietf-appsawg-siev=
e-duplicate<br>draft-ietf-appsawg-rrvs-header-field<br>draft-ietf-appsawg-x=
ml-mediatypes<br><br></div>Happy 2014 to everyone!<br><br></div>-MSK, APPSA=
WG co-chair<br>
</div>

--001a11c228d2608cf704eeea013e--

From eburger@standardstrack.com  Wed Jan  1 07:28:00 2014
Return-Path: <eburger@standardstrack.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27EB01AE33A; Wed,  1 Jan 2014 07:28:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.578
X-Spam-Level: *
X-Spam-Status: No, score=1.578 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1IgizUa0Uzqg; Wed,  1 Jan 2014 07:27:59 -0800 (PST)
Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) by ietfa.amsl.com (Postfix) with ESMTP id 1ECA51AE32B; Wed,  1 Jan 2014 07:27:59 -0800 (PST)
Received: from ip68-100-74-215.dc.dc.cox.net ([68.100.74.215]:49802 helo=[192.168.15.106]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from <eburger@standardstrack.com>) id 1VyNhs-000280-Lr; Wed, 01 Jan 2014 07:27:47 -0800
Content-Type: multipart/signed; boundary="Apple-Mail=_1BA2BBAF-A5EA-4F6A-B09D-307C3130BD22"; protocol="application/pgp-signature"; micalg=pgp-sha1
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Eric Burger <eburger@standardstrack.com>
In-Reply-To: <CAL0qLwZ7cL4oDZ084f9PmE+EpV3rQooyM2FKT+8+oz=RQg5SUg@mail.gmail.com>
Date: Wed, 1 Jan 2014 10:27:38 -0500
Message-Id: <DAD9A9AB-5DD1-4F34-AE7D-07F825CB03ED@standardstrack.com>
References: <jdya0djw1375oitm3pnsmljy.1388282448484@email.android.com> <52BFC7AA.7060802@dcrocker.net> <179DBF1C-1A51-4E0E-95C2-57086EF703F0@standardstrack.com> <52C1BD55.9050004@dcrocker.net> <0C14D25A-FD99-43D7-94B7-71679066D403@standardstrack.com> <CAL0qLwZ7cL4oDZ084f9PmE+EpV3rQooyM2FKT+8+oz=RQg5SUg@mail.gmail.com>
To: "Murray S. Kucherawy" <superuser@gmail.com>
X-Mailer: Apple Mail (2.1827)
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Cc: draft-ietf-appsawg-rrvs-header-field.all@tools.ietf.org, The IESG <iesg@ietf.org>, IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Back to draft-ietf-appsawg-rrvs-header-field-05 (was Re: Scope of protocol authority)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Jan 2014 15:28:00 -0000

--Apple-Mail=_1BA2BBAF-A5EA-4F6A-B09D-307C3130BD22
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

I would offer we =93say what we mean.=94 What Murray wrote here is a =
concise explanation of why there are two mechanisms, one sort of broken, =
one harder to get deployed. I am guessing non-Apps AD=92s and other =
reviewers will have similar issues with the appearance of a half-hearted =
attempt at a mechanism (headers) embedded with the right mechanism (SMTP =
extension).

Putting the one sentence you have below about the SMTP extension being =
easier to implement and that the extension does the right thing under =
what today looks like all circumstances but will be quite a while before =
it will be ubiquitous will help on many fronts:
	1. It makes it very clear (if up front, like in the Abstract) =
this document talks about two distinct mechanisms for achieving the goal =
of RRVS and how to make these two, distinct mechanisms interoperate if =
all goes well.
	2. People like me at review time will not freak out about having =
two distinct mechanisms for achieving the goal of RRVS, one of which is =
very complicated and likely to be very brittle (headers) and the other =
which is solid, but hard to deploy (SMTP extension).
	3. People implementing the specification will have clear =
guidance that if they are to implement one thing, it should be the SMTP =
extension. It also lets them know that if they implement the header, =
they need to pay particular attention to getting all of the subtleties =
right (like when to strip out the header, when to ignore it, when to put =
it in, etc.).

Happy New Year.
- Eric

On Dec 31, 2013, at 8:25 PM, Murray S. Kucherawy <superuser@gmail.com> =
wrote:

> On Tue, Dec 31, 2013 at 11:55 AM, Eric Burger =
<eburger@standardstrack.com> wrote:
>=20
> No veto here, just pointing out that we are in a circular loop of =
shifting requirements and a realization and ignoring of the reality of =
the network topology this draft is supposed to be addressing.
>=20
>=20
> I don't understand why there's a perception of shifting requirements.  =
Rather, the two approaches have different capabilities and attempt to =
address different parts of the ecosystem.  The SMTP extension route is =
architecturally speaking more correct for reasons identified in the =
draft -- and according to Ned at least, easier to implement -- while the =
header field has a much lower barrier to entry and actually is in =
production use.
>=20
> There isn't a single true topology to address here.  The sender can =
decide which method is most practical given its own operational and =
security concerns.
>=20
> -MSK


--Apple-Mail=_1BA2BBAF-A5EA-4F6A-B09D-307C3130BD22
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

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

iQIcBAEBAgAGBQJSxDPqAAoJEDY/T2tCIPW3gyAP/i03PXskEYzwJAYAA4u32zvs
cXBljvJjgUIibtMk5Sj2KIpxxTwNXFcG9LavTia00d5FiR9d09fnslOBeQIK8+9C
SS3pfg8TBnAXG+e+7NG5C8dgmpe8LWsQUXF5PiBBgEj0UQwUYkgK/yC8dqVQVy7V
7fYUU9SutAsh4T0Fb44DDmUdf97RzT3XR+p1OE/g5UNMppT6QmP3lIsJ6581/72h
ByrvyQf19lJ29luW2onRUu0UgJHqC4TFWt9GeLyrDeaNYUOKE37ZMeoetQUxdzy6
lRqDqxb+a5VuK00W0nQUhGJvkEyit13wSn/amux2H8/eN+yTWpp7MlyFxiBBXKuE
mQ2fPQDSAiNs7W+XR+rlRYgjLpX3FulF9bD6D2ZvwAaDmaNG2I4xVyfYb/AxaEzP
Ryecb7q3JCPFRyiX47Nn/li1j74jIA95zEe3YIBOliSx4Kc4reMCv7NCOcZcJgyc
nn2mIxsBZeOMRbKOxQSZBewyKab0WhshYw6G20er2tJu8qpQEjtAwOi3/t4rIXDq
22aoQIlTuvyyo67lK5MhFBwSZQlI3MzfAa6P9iiMrN9bGgY8bGvEHAgXaROuVDns
ScPttYF6BJcikSdHDxBIXFZZtg4TTtS0Xxp/0ceh67XjrCyuNB3GGCDLunTrBAHg
05VLykizvOu+udK6ORjl
=qsxd
-----END PGP SIGNATURE-----

--Apple-Mail=_1BA2BBAF-A5EA-4F6A-B09D-307C3130BD22--

From Bert.Greevenbosch@huawei.com  Wed Jan  1 22:06:52 2014
Return-Path: <Bert.Greevenbosch@huawei.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA981AE1CA for <apps-discuss@ietfa.amsl.com>; Wed,  1 Jan 2014 22:06:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.738
X-Spam-Level: 
X-Spam-Status: No, score=-4.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 zl1f8ZQk-OR5 for <apps-discuss@ietfa.amsl.com>; Wed,  1 Jan 2014 22:06:50 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 444791AE17D for <apps-discuss@ietf.org>; Wed,  1 Jan 2014 22:06:50 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZO20094; Thu, 02 Jan 2014 06:06:43 +0000 (GMT)
Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 2 Jan 2014 06:06:28 +0000
Received: from SZXEMA402-HUB.china.huawei.com (10.82.72.34) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 2 Jan 2014 06:06:42 +0000
Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.206]) by SZXEMA402-HUB.china.huawei.com ([10.82.72.34]) with mapi id 14.03.0158.001; Thu, 2 Jan 2014 14:06:36 +0800
From: Bert Greevenbosch <Bert.Greevenbosch@huawei.com>
To: "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Thread-Topic: New draft: "CBOR data definition language: a notational convention to express CBOR data structures."
Thread-Index: Ac8HgDPQHmsshsw4Q8W8K22Y6ECTkQAACbjw
Date: Thu, 2 Jan 2014 06:06:36 +0000
Message-ID: <46A1DF3F04371240B504290A071B4DB63E3CF04B@SZXEMA510-MBX.china.huawei.com>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.66.162.63]
Content-Type: multipart/alternative; boundary="_000_46A1DF3F04371240B504290A071B4DB63E3CF04BSZXEMA510MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: [apps-discuss] New draft: "CBOR data definition language: a notational convention to express CBOR data structures."
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Jan 2014 06:06:52 -0000

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

Hello all,

I have uploaded the following draft:
https://datatracker.ietf.org/doc/draft-greevenbosch-appsawg-cbor-cddl/

The draft introduces a notation to express CBOR data structures.

CBOR has recently been defined in RFC 7049. It is a general binary data for=
mat, which can be used to encode data in a structural way. Next to general =
data fields such as "integer" and "string", CBOR also supports signalling o=
f e.g. arrays and maps.

RFC 7049 does not define how to write down CBOR data structures in specific=
ations. I think it would be useful to have a standardised way for this, hen=
ce this new draft.

Since there is no working group chartered to do CBOR work, I have uploaded =
it as input to the general Applications Area working group.

I look forward to discussions on this, both technical and procedural. :-)

I wish you all a happy 2014!

Best regards,
Bert

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

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span lang=3D"EN-GB">Hello all,<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span lang=3D"EN-GB"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB">I have uploaded the following d=
raft:<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB"><a href=3D"https://datatracker.=
ietf.org/doc/draft-greevenbosch-appsawg-cbor-cddl/">https://datatracker.iet=
f.org/doc/draft-greevenbosch-appsawg-cbor-cddl/</a><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB">The draft introduces a notation=
 to express CBOR data structures.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB">CBOR has recently been defined =
in RFC 7049. It is a general binary data format, which can be used to encod=
e data in a structural way. Next to general data fields such as &quot;integ=
er&quot; and &quot;string&quot;, CBOR also supports signalling
 of e.g. arrays and maps.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB">RFC 7049 does not define how to=
 write down CBOR data structures in specifications. I think it would be use=
ful to have a standardised way for this, hence this new draft.<o:p></o:p></=
span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB">Since there is no working group=
 chartered to do CBOR work, I have uploaded it as input to the general Appl=
ications Area working group.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB">I look forward to discussions o=
n this, both technical and procedural. :-)<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB">I wish you all a happy 2014!<o:=
p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB">Best regards,<o:p></o:p></span>=
</p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB">Bert<o:p></o:p></span></p>
</div>
</body>
</html>

--_000_46A1DF3F04371240B504290A071B4DB63E3CF04BSZXEMA510MBXchi_--

From hsantos@isdg.net  Thu Jan  2 10:16:34 2014
Return-Path: <hsantos@isdg.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00C251ACC82 for <apps-discuss@ietfa.amsl.com>; Thu,  2 Jan 2014 10:16:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.302
X-Spam-Level: 
X-Spam-Status: No, score=-99.302 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6dAW5Ig9X2R0 for <apps-discuss@ietfa.amsl.com>; Thu,  2 Jan 2014 10:16:30 -0800 (PST)
Received: from mail.catinthebox.net (ftp.catinthebox.net [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id D17F91A16F0 for <apps-discuss@ietf.org>; Thu,  2 Jan 2014 10:16:29 -0800 (PST)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=5562; t=1388686572; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=almgrBU1bxVWdyv9YzITDExEM7E=; b=FbZCrkb9I4UYAKRAU3hd GJSXBKj6y03ga8HXaNulOG/k9BwE2gFcgJrcUpyhDfFhuFUX6JQW62Zy6PL99Vi8 d5vHGw7YiyJpD09PObfXhyHlLyPi7nfg68IPL+ivcTR2t47JSYXUWdL/3DGBHi0f Bh1q05OT0a8x3lnN+xeMsDQ=
Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Thu, 02 Jan 2014 13:16: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 beta.winserver.com (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2264053857.20793.3304; Thu, 02 Jan 2014 13:16:11 -0500
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=5562; t=1388686026; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=kC1fhhc TSbhp7E1b20O5PZIZoicH4iA8D4mn5ZrbNxw=; b=lZTBBes0McKX4DW53Lz8l3i v4qSQNZT2Z3mxgnhW/ynKUDrM4vubCEESj2CbKquKi9gx6HPOh7fQJi5ngEoOnRP B+ZjGwaGDj9EaKO9sVdV7PS4QJj1e16z81zEWBw8Kfcsid6kwD6ps0ZfiYUQPaoM JrsB95SjWoPesySKGObg=
Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Thu, 02 Jan 2014 13:07: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 1710371567.9.4892; Thu, 02 Jan 2014 13:07:04 -0500
Message-ID: <52C5ACEA.9090500@isdg.net>
Date: Thu, 02 Jan 2014 13:16:10 -0500
From: Hector Santos <hsantos@isdg.net>
Organization: Santronics Software, Inc.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Eric Burger <eburger@standardstrack.com>
References: <jdya0djw1375oitm3pnsmljy.1388282448484@email.android.com> <52BFC7AA.7060802@dcrocker.net> <179DBF1C-1A51-4E0E-95C2-57086EF703F0@standardstrack.com> <52C1BD55.9050004@dcrocker.net> <0C14D25A-FD99-43D7-94B7-71679066D403@standardstrack.com> <CAL0qLwZ7cL4oDZ084f9PmE+EpV3rQooyM2FKT+8+oz=RQg5SUg@mail.gmail.com> <DAD9A9AB-5DD1-4F34-AE7D-07F825CB03ED@standardstrack.com>
In-Reply-To: <DAD9A9AB-5DD1-4F34-AE7D-07F825CB03ED@standardstrack.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Cc: draft-ietf-appsawg-rrvs-header-field.all@tools.ietf.org, The IESG <iesg@ietf.org>, IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Back to draft-ietf-appsawg-rrvs-header-field-05 (was Re: Scope of protocol authority)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Jan 2014 18:16:34 -0000

At this point as the proposal is written, due to what appears to have 
a high design change complexity in integrated Gateway, MSA, MDA and 
MTA components (keeping the MUA out for the moment), with the many 
unknowns of what are the necessary, shared and minimum process model 
parameters on both ends, I can only feasibly consider this proposal at 
the 5322.RRVS header  exploratory and testing level. For authorized 
relays (direct vs indirect is a moot point, since it all paths must be 
considered), it will be a transparent passthru operation.  So I agree 
with the idea that 5322.RRVS should be the main focus for all 
compliant systems to follow.  At ESMTP there are still other 
considerations such as VRFY.

Even for 5321, while we won't advertise a ESMTP RRVS service until 
RRVS an be fully tested and understood, for local user reception 
(MSA/MDA behavior), this will allow sysop level programmable 5322 
filtering scripts to be available at the 5321.DATA level before the 
EOD (End of Data) server response is provided.  While there is higher 
payload overhead, this does avoids accept/bounce attack potentials.

Currently, I see no interop sites to test with.  I was under the 
impression Yahoo/Facebook are currently in 5322.RRVS production mode. 
I don't see this with testing new signups at these services using our 
domains. So it must be a domain by domain consideration if this is in 
production and currently only between Yahoo/Facebook and perhaps 
others we are not privy too.  It would nice to see interop sites and 
interop reports of what is needed and what new problems were created.

We must keep in mind what the proposed idea would be advocating to all 
in the application hosting service bureau world that it is now 
relatively secure and safe to begin a practice offering reusable email 
addresses.

Even for our own support site, we still get tons of emails (most 
likely spam) for long forgotten, expired and deleted users.  All 
immediately rejected at SMTP and our stats since 2003 consistently 
show a high 60% rejection rate at the RCPT level.  They come from all 
over.  So the idea of now allowing all or some of these addresses to 
be potentially reused comes with the high potential of getting new 
legacy spam.

   Operations may need to inform new owners of ids that their has been
   a continued history of rejects to the transferred id.  In fact, perhaps
   RRVS should recommend that ESPs consider not transferring an id until
   a Quiet Time period has been reached (1 year?).

By promoting a new RRVS feature in our package, while our own 
installation and deployment might disable it for own usages, we need 
to be careful on making any claims to customers that they COULD enable 
it with some degree of secured confidence for success.  Currently I 
don't see that yet.

-- 
HLS

On 1/1/2014 10:27 AM, Eric Burger wrote:
> I would offer we �say what we mean.� What Murray wrote here is a concise explanation of why there are two mechanisms, one sort of broken, one harder to get deployed. I am guessing non-Apps AD�s and other reviewers will have similar issues with the appearance of a half-hearted attempt at a mechanism (headers) embedded with the right mechanism (SMTP extension).
>
> Putting the one sentence you have below about the SMTP extension being easier to implement and that the extension does the right thing under what today looks like all circumstances but will be quite a while before it will be ubiquitous will help on many fronts:
> 	1. It makes it very clear (if up front, like in the Abstract) this document talks about two distinct mechanisms for achieving the goal of RRVS and how to make these two, distinct mechanisms interoperate if all goes well.
> 	2. People like me at review time will not freak out about having two distinct mechanisms for achieving the goal of RRVS, one of which is very complicated and likely to be very brittle (headers) and the other which is solid, but hard to deploy (SMTP extension).
> 	3. People implementing the specification will have clear guidance that if they are to implement one thing, it should be the SMTP extension. It also lets them know that if they implement the header, they need to pay particular attention to getting all of the subtleties right (like when to strip out the header, when to ignore it, when to put it in, etc.).
>
> Happy New Year.
> - Eric
>
> On Dec 31, 2013, at 8:25 PM, Murray S. Kucherawy <superuser@gmail.com> wrote:
>
>> On Tue, Dec 31, 2013 at 11:55 AM, Eric Burger <eburger@standardstrack.com> wrote:
>>
>> No veto here, just pointing out that we are in a circular loop of shifting requirements and a realization and ignoring of the reality of the network topology this draft is supposed to be addressing.
>>
>>
>> I don't understand why there's a perception of shifting requirements.  Rather, the two approaches have different capabilities and attempt to address different parts of the ecosystem.  The SMTP extension route is architecturally speaking more correct for reasons identified in the draft -- and according to Ned at least, easier to implement -- while the header field has a much lower barrier to entry and actually is in production use.
>>
>> There isn't a single true topology to address here.  The sender can decide which method is most practical given its own operational and security concerns.
>>
>> -MSK
>
>
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>




From ietfc@btconnect.com  Thu Jan  2 10:29:27 2014
Return-Path: <ietfc@btconnect.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C856A1A1F61 for <apps-discuss@ietfa.amsl.com>; Thu,  2 Jan 2014 10:29: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, 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 jfXDJSz9q9KT for <apps-discuss@ietfa.amsl.com>; Thu,  2 Jan 2014 10:29:25 -0800 (PST)
Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0188.outbound.messaging.microsoft.com [213.199.154.188]) by ietfa.amsl.com (Postfix) with ESMTP id 1079B1A16F0 for <apps-discuss@ietf.org>; Thu,  2 Jan 2014 10:29:24 -0800 (PST)
Received: from mail151-db8-R.bigfish.com (10.174.8.253) by DB8EHSOBE002.bigfish.com (10.174.4.65) with Microsoft SMTP Server id 14.1.225.22; Thu, 2 Jan 2014 18:29:17 +0000
Received: from mail151-db8 (localhost [127.0.0.1])	by mail151-db8-R.bigfish.com (Postfix) with ESMTP id 6F29146029D;	Thu,  2 Jan 2014 18:29:17 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.249.213; KIP:(null); UIP:(null); IPV:NLI; H:AM2PRD0710HT003.eurprd07.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -15
X-BigFish: PS-15(zz9371I542I1432I1418Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h20f7h2189h1d1ah1d2ah1fc6hzz1de098h1033IL8275bh8275dh1de097h186068hz2dh2a8h5a9h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah2222h224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h2218h2216h226dh22d0h2327h2336h304l1d11m1155h)
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(51444003)(199002)(189002)(51704005)(377454003)(13464003)(31966008)(88136002)(47446002)(74662001)(89996001)(81342001)(51856001)(47976001)(50986001)(69226001)(74876001)(50466002)(74706001)(80976001)(77156001)(76482001)(53806001)(42186004)(77096001)(15975445006)(76786001)(76796001)(74366001)(4396001)(46102001)(44736004)(49866001)(47736001)(50226001)(87976001)(87266001)(87286001)(84392001)(85306002)(33646001)(81542001)(79102001)(62236002)(44716002)(74502001)(62966002)(23756003)(83322001)(19580405001)(19580395003)(54316002)(61296002)(83072002)(66066001)(65816001)(80022001)(85852003)(56776001)(90146001)(56816005)(63696002)(47776003)(14496001)(77982001)(59766001)(74416001)(7726001); DIR:OUT; SFP:1101; SCL:1; SRVR:AMSPR07MB052; H:DB3PRD0411HT001.eurprd04.prod.outlook.com; CLIP:157.56.253.53; FPR:; RD:InfoNoRecords; A:0; MX:1; LANG:en; 
Received: from mail151-db8 (localhost.localdomain [127.0.0.1]) by mail151-db8 (MessageSwitch) id 1388687354878510_26367; Thu,  2 Jan 2014 18:29:14 +0000 (UTC)
Received: from DB8EHSMHS017.bigfish.com (unknown [10.174.8.251])	by mail151-db8.bigfish.com (Postfix) with ESMTP id C7A962004B;	Thu,  2 Jan 2014 18:29:14 +0000 (UTC)
Received: from AM2PRD0710HT003.eurprd07.prod.outlook.com (157.56.249.213) by DB8EHSMHS017.bigfish.com (10.174.4.27) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 2 Jan 2014 18:29:11 +0000
Received: from AMSPR07MB052.eurprd07.prod.outlook.com (10.242.81.27) by AM2PRD0710HT003.eurprd07.prod.outlook.com (10.255.165.38) with Microsoft SMTP Server (TLS) id 14.16.395.1; Thu, 2 Jan 2014 18:29:10 +0000
Received: from DB3PRD0411HT001.eurprd04.prod.outlook.com (157.56.253.53) by AMSPR07MB052.eurprd07.prod.outlook.com (10.242.81.27) with Microsoft SMTP Server (TLS) id 15.0.842.7; Thu, 2 Jan 2014 18:29:09 +0000
Message-ID: <00a301cf07e8$01352160$4001a8c0@gateway.2wire.net>
From: t.petch <ietfc@btconnect.com>
To: "Murray S. Kucherawy" <superuser@gmail.com>, IETF Apps Discuss <apps-discuss@ietf.org>
References: <CAL0qLwZqJPTssNVLLaSjAP5wqteZ==fuawNF+WUZYvi+YWV1UQ@mail.gmail.com>
Date: Thu, 2 Jan 2014 18:24:48 +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.53]
X-ClientProxiedBy: AMXPR07CA006.eurprd07.prod.outlook.com (10.242.64.46) To AMSPR07MB052.eurprd07.prod.outlook.com (10.242.81.27)
X-Forefront-PRVS: 0079056367
X-OriginatorOrg: btconnect.com
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Jan 2014 18:29:28 -0000

This I-D seems to need more thought.

s.1 "For example, if a member of the list decides to
   reply to both the user and the mailing list itself, the user will
   one copy of the message directly and another through the mailing
   list.

Well, they MAY, but they don't on a good list system, such as the one in
use here.

"Also, if someone cross-posts over several mailing lists to
   which the user is subscribed, the user will receive a copy from each
   of those lists."

Ditto, not here.

"   Duplicate messages are normally detected using the Message-ID header
   field, which is required to be unique for each message.  "

REQUIRED maybe, but I seem to recall the malformed-mail I-D raising the
possibility that it was not.  In which case, ...?

s.3
"an earlier Sieve execution."
reading on it is apparent that this is any number of executions limited
by the size of the FIFO cache and the maximum lifetime of entries in the
cache.

"   Usage:  [":header" <header-name: string> /
                          ":uniqueid" <value: string>]

Why have two way of doing the same thing?  As I read it, this test is on
a header field, so why not have just ":header" with a default of message
I-D?

And what happens if I use header field X in one execution and then
header field Y in another? I presume separate caches for X and Y, in
which case, duplicates may not be detected.  The use of multiple fields
opens up all sorts of complications that need more explanation depending
on the concept of the scope of the operation, which I do not see clearly
explained.

"The user can explicitly control the
   length of this expiration time by means of the ":seconds" argument,
   which is always specified in seconds.  "

seconds seems short to me.  On the IETF lists, I typically see a gap of
several hours between a message on one list and a message on another
list, with four hours being the norm.  I would regard 5 minutes as the
minimum and 36 hours, or perhaps less, as the maximum.

"By adding the ":header" argument with a message header
   field name, the content of the specified header field can be used as
"

Does this apply to all headers? I assume it does, since if message I-D
is not used, then it would be an X- proprietary one that would seem to
me to be the next best thing.


"   If the tracked unique ID value is extracted directly from a message
   header field, i.e., when the ":uniqueid" argument is not used,"

you are saying that when uniqueid is not used, then a unique ID is used.
I think that this will cause confusion here and elsewhere - you need
another term than 'unique ID' as the collective noun for the identifying
string you are using in the equality comparison.

"leading and trailing whitespace MUST first be trimmed from the value"

This is a can of worms.  Normalisation often appears on these lists
without, usually, a satisfactory answer, let alone the issues of i18n.
More needs to be considered here.

So, nice idea, but more thought needed.

Tom Petch

----- Original Message -----
From: "Murray S. Kucherawy" <superuser@gmail.com>
To: "IETF Apps Discuss" <apps-discuss@ietf.org>
Sent: Wednesday, January 01, 2014 3:05 PM
Subject: [apps-discuss] REMINDER: Working Group Last Calls still open


> Colleagues,
>
> I know many of us are busy or away possibly until next week.  This is
just
> a reminder that there are three documents in Working Group Last Call
state,
> extended for the holidays.  After two and a half weeks, there has been
a
> lot of commentary on one of them, a small amount on a second, and none
on
> the third.  Please remember to schedule some time to provide reviews
and
> commentary on all of them early in the new year so they can be
advanced to
> make room for new work.
>
> The documents are:
>
> draft-ietf-appsawg-sieve-duplicate
> draft-ietf-appsawg-rrvs-header-field
> draft-ietf-appsawg-xml-mediatypes
>
> Happy 2014 to everyone!
>
> -MSK, APPSAWG co-chair
>


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


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



From hallam@gmail.com  Thu Jan  2 10:29:56 2014
Return-Path: <hallam@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78BA41A16F0 for <apps-discuss@ietfa.amsl.com>; Thu,  2 Jan 2014 10:29:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.1
X-Spam-Level: 
X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sQ0mqAG6ppSJ for <apps-discuss@ietfa.amsl.com>; Thu,  2 Jan 2014 10:29:52 -0800 (PST)
Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id B802B1ACC8B for <apps-discuss@ietf.org>; Thu,  2 Jan 2014 10:29:50 -0800 (PST)
Received: by mail-la0-f45.google.com with SMTP id eh20so7553036lab.18 for <apps-discuss@ietf.org>; Thu, 02 Jan 2014 10:29:43 -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=9uQaVxYAb5lo8EZAjzzITdC6/xay5DuACZolQFsrKDA=; b=F3FB4ENAdW+lFilv78oCeVa8tLxap6XNfd6bNcHg4eaNB109zce4Eo/Y/dFzwXcPUM hr4ZeaTO3TRnWdGie5oV1LFUM9pxI7Mf0GBw0hExDkWs2eCcPihT3thqCg47Asx3eKBM GAhMB8Qg5BTKUazzkqwthTLrBTZsWtQTWILYEaf+8qG6MwAr7GxhlBSmfFJUgee/5U8T OhSlDbB/si++IaGr4gEg6zlk7EdQCsLB8Ll7cZwuDT/a3k/TmmuPxtI0s3BECMuvm+j2 wLbCBlOrqPu4vx7fzPfjWI0bfCJ0vxqBwUt5I82WCsM2c2wTgkQMqCI84Hd+7J55qGce nTGg==
MIME-Version: 1.0
X-Received: by 10.112.201.197 with SMTP id kc5mr3223285lbc.64.1388687382959; Thu, 02 Jan 2014 10:29:42 -0800 (PST)
Received: by 10.112.37.172 with HTTP; Thu, 2 Jan 2014 10:29:42 -0800 (PST)
In-Reply-To: <46A1DF3F04371240B504290A071B4DB63E3CF04B@SZXEMA510-MBX.china.huawei.com>
References: <46A1DF3F04371240B504290A071B4DB63E3CF04B@SZXEMA510-MBX.china.huawei.com>
Date: Thu, 2 Jan 2014 13:29:42 -0500
Message-ID: <CAMm+LwjOXwQsB8u9X9-=0XTC1VfVsp5z9rZDgFAZvvS79XQdKQ@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Bert Greevenbosch <Bert.Greevenbosch@huawei.com>
Content-Type: multipart/alternative; boundary=001a11c2662e2a5c8804ef00fa94
Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] New draft: "CBOR data definition language: a notational convention to express CBOR data structures."
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Jan 2014 18:29:56 -0000

--001a11c2662e2a5c8804ef00fa94
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Jan 2, 2014 at 1:06 AM, Bert Greevenbosch <
Bert.Greevenbosch@huawei.com> wrote:

>  Hello all,
>
>
>
> I have uploaded the following draft:
>
> https://datatracker.ietf.org/doc/draft-greevenbosch-appsawg-cbor-cddl/
>
>
>
> The draft introduces a notation to express CBOR data structures.
>
>
>
> CBOR has recently been defined in RFC 7049. It is a general binary data
> format, which can be used to encode data in a structural way. Next to
> general data fields such as "integer" and "string", CBOR also supports
> signalling of e.g. arrays and maps.
>
>
>
This is what I was worried about when CBOR was first proposed.

The networking world is currently moving to JSON as the interchange
standard. I totally oppose any alternative suggestion or proposal unless
there is an overwhelming need and there is no way to address that need
within the JSON framework.

The only way in which JSON currently falls short of my personal needs is
that it does not support efficient binary or text encodings. Which is why I
propose adding these features to the JSON encoding set which is what I do
in JSON-B. But what I do not do is to change the data model. It is possible
to express every JSON-B data stream in JSON and vice versa. The only area
that is not fully constrained is that since JSON does not have a native
binary type there is an assumption that BASE64 will be used (which is
obviously sub optimal for an encoding that can support UNICODE text strings
but there you have it.


Further, I don't accept the notion that there has to be a new schema for
each encoding format. Having a schema to document protocols is very useful.
My PROTOGEN tool generates the code and the specification from the same
source. But even though PROTOGEN was designed to generate programs that
generate protocols that use JSON format, it can be used to generate a
protocol that uses XML or ASN.1. In fact one of the predecessors of the
tool was used to write SAML/1.0.

It is not possible to use my tool to implement an ASN.1 or XML based
specification using their own schema languages as they are baroque with too
many unnecessary and brain damaged features. Nor is it possible to specify
the tight control on element ordering etc that XML schema provides because
in my experience those features are utterly useless.


I would like to get to a position where we can use a single data model to
represent the protocol flows at all layers in the stack above the IP layer.
There are good reasons for not wanting to use a text based encoding for
every purpose and for wanting to have the option of using compression. But
these can be added within the JSON data model just as there are different
encodings supported in the ASN.1 and XML frameworks.



-- 
Website: http://hallambaker.com/

--001a11c2662e2a5c8804ef00fa94
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Thu, Jan 2, 2014 at 1:06 AM, Bert Greevenbosch <span dir=3D"ltr"=
>&lt;<a href=3D"mailto:Bert.Greevenbosch@huawei.com" target=3D"_blank">Bert=
.Greevenbosch@huawei.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">





<div lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div>
<p class=3D"MsoNormal"><span lang=3D"EN-GB">Hello all,<u></u><u></u></span>=
</p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB"><u></u>=A0<u></u></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB">I have uploaded the following d=
raft:<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB"><a href=3D"https://datatracker.=
ietf.org/doc/draft-greevenbosch-appsawg-cbor-cddl/" target=3D"_blank">https=
://datatracker.ietf.org/doc/draft-greevenbosch-appsawg-cbor-cddl/</a><u></u=
><u></u></span></p>

<p class=3D"MsoNormal"><span lang=3D"EN-GB"><u></u>=A0<u></u></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB">The draft introduces a notation=
 to express CBOR data structures.<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB"><u></u>=A0<u></u></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-GB">CBOR has recently been defined =
in RFC 7049. It is a general binary data format, which can be used to encod=
e data in a structural way. Next to general data fields such as &quot;integ=
er&quot; and &quot;string&quot;, CBOR also supports signalling
 of e.g. arrays and maps.<u></u><u></u></span></p>
<p class=3D"MsoNormal"><br></p></div></div></blockquote><div><br></div><div=
>This is what I was worried about when CBOR was first proposed.</div><div><=
br></div><div>The networking world is currently moving to JSON as the inter=
change standard. I totally oppose any alternative suggestion or proposal un=
less there is an overwhelming need and there is no way to address that need=
 within the JSON framework.</div>
<div><br></div><div>The only way in which JSON currently falls short of my =
personal needs is that it does not support efficient binary or text encodin=
gs. Which is why I propose adding these features to the JSON encoding set w=
hich is what I do in JSON-B. But what I do not do is to change the data mod=
el. It is possible to express every JSON-B data stream in JSON and vice ver=
sa. The only area that is not fully constrained is that since JSON does not=
 have a native binary type there is an assumption that BASE64 will be used =
(which is obviously sub optimal for an encoding that can support UNICODE te=
xt strings but there you have it.</div>
<div><br></div><div><br></div></div>Further, I don&#39;t accept the notion =
that there has to be a new schema for each encoding format. Having a schema=
 to document protocols is very useful. My PROTOGEN tool generates the code =
and the specification from the same source. But even though PROTOGEN was de=
signed to generate programs that generate protocols that use JSON format, i=
t can be used to generate a protocol that uses XML or ASN.1. In fact one of=
 the predecessors of the tool was used to write SAML/1.0.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">It is not p=
ossible to use my tool to implement an ASN.1 or XML based specification usi=
ng their own schema languages as they are baroque with too many unnecessary=
 and brain damaged features. Nor is it possible to specify the tight contro=
l on element ordering etc that XML schema provides because in my experience=
 those features are utterly useless.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><br></div><=
div class=3D"gmail_extra">I would like to get to a position where we can us=
e a single data model to represent the protocol flows at all layers in the =
stack above the IP layer. There are good reasons for not wanting to use a t=
ext based encoding for every purpose and for wanting to have the option of =
using compression. But these can be added within the JSON data model just a=
s there are different encodings supported in the ASN.1 and XML frameworks.<=
br clear=3D"all">
<div><br></div><div><br></div><div><br></div>-- <br>Website: <a href=3D"htt=
p://hallambaker.com/">http://hallambaker.com/</a><br>
</div></div>

--001a11c2662e2a5c8804ef00fa94--

From hsantos@isdg.net  Thu Jan  2 11:17:15 2014
Return-Path: <hsantos@isdg.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51E041A802E for <apps-discuss@ietfa.amsl.com>; Thu,  2 Jan 2014 11:17:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.401
X-Spam-Level: 
X-Spam-Status: No, score=-101.401 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_15=0.6, 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 I2YUZcbPmg7r for <apps-discuss@ietfa.amsl.com>; Thu,  2 Jan 2014 11:17:13 -0800 (PST)
Received: from groups.winserver.com (ntbbs.santronics.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 5C2011A9313 for <apps-discuss@ietf.org>; Thu,  2 Jan 2014 11:17:10 -0800 (PST)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1441; t=1388690222; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=Ah20q0gpmgcZmdFEYLE7MgHgc3Q=; b=hFP8irHXbJmUTQsw9Cvg r1JL2yZpBaZJLNghAUZox3dpB/l35AlKDJJ0qQFTePU3trZ+QuJ7wKNDMcMCI3Dp IxrutYIReXReFTkX1AvoQq4nXs6zb7CPLfuQf4rfOs4f1oRvHKMqpfZGOLCtH0xC NRxv3ydQ+XsBzWqUEFWYSFc=
Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Thu, 02 Jan 2014 14:17:02 -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 2267704546.20793.5820; Thu, 02 Jan 2014 14:17:02 -0500
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1441; t=1388689678; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=+Ko031F FrbvCYACLEmy5dIYMwPpoRtMSHgE93YeO9Ls=; b=ly4NXR9KaTe7aQsekvncwzC pt3zGKFdcBVN9eZYTKU3hwdS/1OlLuK+UgqgaYa1FkxWmM2XTxJ45VQTksw4hPg8 TPvwpS7o+Xp9JWZitJ3NTaJ9UEKmvUtLrWHXqtPUPRiM/SPh7x1iG+1IiXEDhXzY Qsum+h7A1H2HTLBKMLW4=
Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Thu, 02 Jan 2014 14:07:58 -0500
Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 1714024395.9.1444; Thu, 02 Jan 2014 14:07:57 -0500
Message-ID: <52C5BB2F.30807@isdg.net>
Date: Thu, 02 Jan 2014 14:17:03 -0500
From: Hector Santos <hsantos@isdg.net>
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: "t.petch" <ietfc@btconnect.com>
References: <CAL0qLwZqJPTssNVLLaSjAP5wqteZ==fuawNF+WUZYvi+YWV1UQ@mail.gmail.com> <00a301cf07e8$01352160$4001a8c0@gateway.2wire.net>
In-Reply-To: <00a301cf07e8$01352160$4001a8c0@gateway.2wire.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Jan 2014 19:17:15 -0000

On 1/2/2014 1:24 PM, t.petch wrote:

> "   Duplicate messages are normally detected using the Message-ID header
>     field, which is required to be unique for each message.  "
>
> REQUIRED maybe, but I seem to recall the malformed-mail I-D raising the
> possibility that it was not.  In which case, ...?

Small input:

When we dealt with dupe issues in Fidonet, the Message Id was REQUIRED 
to be unique only at the PER DOMAIN basis. Because you could not 
guarantee that it would be unique at other domains nor guarantee that 
it would exist, the first main goal is to make sure you stop DUPES at 
the local domain level first.  I don't see this as any different as we 
migrated to RFC 822/2822/5322 since the same or similar dupe problems 
(and design requirements) applies.

That said, in my experience, dupe methods can range to include other 
factors in an dupe algorithm.  In addition, it depends on the type of 
mail.  For example, in a 1 to 1 (private direct mail), we had to offer 
an option to DISABLE dupe checking for private netmail communications. 
  However, for 1 to Many (public, list, echo, news), there are other 
means included.   Fidonet had "seen-by" lines.  NNTP News Articles has 
the path statement as well to detect dupes.   Our 30+ year old system 
still has a proprietary hashing method that considers TO, FROM, DATE 
and SUBJECT and the body and that normally catches what any RFC MSGID 
methods misses.

-- 
HLS



From Bert.Greevenbosch@huawei.com  Sun Jan  5 17:21:08 2014
Return-Path: <Bert.Greevenbosch@huawei.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E49D1ADED5 for <apps-discuss@ietfa.amsl.com>; Sun,  5 Jan 2014 17:21:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.739
X-Spam-Level: 
X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 Wk8wt3b66W9y for <apps-discuss@ietfa.amsl.com>; Sun,  5 Jan 2014 17:21:02 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9B5A31ADEC1 for <apps-discuss@ietf.org>; Sun,  5 Jan 2014 17:21:01 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZQ71663; Mon, 06 Jan 2014 01:20:51 +0000 (GMT)
Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 6 Jan 2014 01:20:33 +0000
Received: from SZXEMA401-HUB.china.huawei.com (10.82.72.33) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 6 Jan 2014 01:20:50 +0000
Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.206]) by SZXEMA401-HUB.china.huawei.com ([10.82.72.33]) with mapi id 14.03.0158.001; Mon, 6 Jan 2014 09:20:44 +0800
From: Bert Greevenbosch <Bert.Greevenbosch@huawei.com>
To: Phillip Hallam-Baker <hallam@gmail.com>
Thread-Topic: [apps-discuss] New draft: "CBOR data definition language: a notational convention to express CBOR data structures."
Thread-Index: Ac8HgDPQHmsshsw4Q8W8K22Y6ECTkQAACbjwAAlMYAAALw8NIA==
Date: Mon, 6 Jan 2014 01:20:43 +0000
Message-ID: <46A1DF3F04371240B504290A071B4DB63E3D1463@SZXEMA510-MBX.china.huawei.com>
References: <46A1DF3F04371240B504290A071B4DB63E3CF04B@SZXEMA510-MBX.china.huawei.com> <CAMm+LwjOXwQsB8u9X9-=0XTC1VfVsp5z9rZDgFAZvvS79XQdKQ@mail.gmail.com>
In-Reply-To: <CAMm+LwjOXwQsB8u9X9-=0XTC1VfVsp5z9rZDgFAZvvS79XQdKQ@mail.gmail.com>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.66.162.63]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] New draft: "CBOR data definition language: a notational convention to express CBOR data structures."
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Jan 2014 01:21:10 -0000

Hi Phillip,

Thank you for your feedback. Please find my answers inline, indicated with =
[BG].

Best regards,
Bert

From: Phillip Hallam-Baker [mailto:hallam@gmail.com]=20
Sent: 03 January 2014 02:30
To: Bert Greevenbosch
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] New draft: "CBOR data definition language: a no=
tational convention to express CBOR data structures."



On Thu, Jan 2, 2014 at 1:06 AM, Bert Greevenbosch <Bert.Greevenbosch@huawei=
.com> wrote:
Hello all,
=A0
I have uploaded the following draft:
https://datatracker.ietf.org/doc/draft-greevenbosch-appsawg-cbor-cddl/
=A0
The draft introduces a notation to express CBOR data structures.
=A0
CBOR has recently been defined in RFC 7049. It is a general binary data for=
mat, which can be used to encode data in a structural way. Next to general =
data fields such as "integer" and "string", CBOR also supports signalling o=
f e.g. arrays and maps.


This is what I was worried about when CBOR was first proposed.

The networking world is currently moving to JSON as the interchange standar=
d. I totally oppose any alternative suggestion or proposal unless there is =
an overwhelming need and there is no way to address that need within the JS=
ON framework.

The only way in which JSON currently falls short of my personal needs is th=
at it does not support efficient binary or text encodings. Which is why I p=
ropose adding these features to the JSON encoding set which is what I do in=
 JSON-B. But what I do not do is to change the data model. It is possible t=
o express every JSON-B data stream in JSON and vice versa. The only area th=
at is not fully constrained is that since JSON does not have a native binar=
y type there is an assumption that BASE64 will be used (which is obviously =
sub optimal for an encoding that can support UNICODE text strings but there=
 you have it.

[BG] I think there is a straight-forward mapping from JSON to CBOR. This is=
 a strength of CBOR, as - quite similar to your proposed JSON-B - it can be=
 used to encode JSON data without loss of information or structure.
=20
Further, I don't accept the notion that there has to be a new schema for ea=
ch encoding format. Having a schema to document protocols is very useful. M=
y PROTOGEN tool generates the code and the specification from the same sour=
ce. But even though PROTOGEN was designed to generate programs that generat=
e protocols that use JSON format, it can be used to generate a protocol tha=
t uses XML or ASN.1. In fact one of the predecessors of the tool was used t=
o write SAML/1.0.

[BG] One of the main goals indeed is documenting protocols, i.e. writing do=
wn data structures in standards. But CDDL is designed to be processed by ma=
chines too - with low complexity.

It is not possible to use my tool to implement an ASN.1 or XML based specif=
ication using their own schema languages as they are baroque with too many =
unnecessary and brain damaged features. Nor is it possible to specify the t=
ight control on element ordering etc that XML schema provides because in my=
 experience those features are utterly useless.

[BG] Yes, definitely we do not want a complex schema language such as that =
of XML. This is why I would like to try to keep CDDL as concise and simple =
as possible. Each feature needs to have careful consideration on whether it=
s complexity is justifiable.

I would like to get to a position where we can use a single data model to r=
epresent the protocol flows at all layers in the stack above the IP layer. =
There are good reasons for not wanting to use a text based encoding for eve=
ry purpose and for wanting to have the option of using compression. But the=
se can be added within the JSON data model just as there are different enco=
dings supported in the ASN.1 and XML frameworks.

[BG] Yes, binary encoding is good. CBOR certainly can be used to compress J=
SON.

[BG] Thanks again for your comments!
--=20
Website: http://hallambaker.com/

From jhildebr@cisco.com  Mon Jan  6 15:25:25 2014
Return-Path: <jhildebr@cisco.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2915A1AE2F9 for <apps-discuss@ietfa.amsl.com>; Mon,  6 Jan 2014 15:25:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.039
X-Spam-Level: 
X-Spam-Status: No, score=-15.039 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.538, 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 rJDzzH_cXYik for <apps-discuss@ietfa.amsl.com>; Mon,  6 Jan 2014 15:25:22 -0800 (PST)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id BA3201AE2F0 for <apps-discuss@ietf.org>; Mon,  6 Jan 2014 15:25:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2665; q=dns/txt; s=iport; t=1389050714; x=1390260314; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=zF/hmPvMuq2Sa87xrom0gqqioRtpGsFSoHt9OcUm26w=; b=cgjPx4opGe7tjP0PSKYLUea1nIL3O/SD/f2j15gAN8e+0rKv43uNSU5d G/o3/YTCjr61D8rW8C0jpvGHcI5Yvvnb9IwEuAR1PYIBvlJ1UxdxmicSP jpGq+1Nzc6sf/U5jv96IexEFq9ok7ESMs1YSPUubuUR1tHwT2/ZlpLaMO k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AkIFABg7y1KtJXHB/2dsb2JhbABYgws4VblVgQsWdIIsOlEBCDYFPScEARKIBA3DXRMEjxiENQSYF5IVgW+BPoFqJBw
X-IronPort-AV: E=Sophos;i="4.95,615,1384300800"; d="scan'208";a="295578646"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-2.cisco.com with ESMTP; 06 Jan 2014 23:25:03 +0000
Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s06NP3Be019056 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 6 Jan 2014 23:25:03 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.227]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Mon, 6 Jan 2014 17:25:03 -0600
From: "Joe Hildebrand (jhildebr)" <jhildebr@cisco.com>
To: Bert Greevenbosch <Bert.Greevenbosch@huawei.com>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Thread-Topic: [apps-discuss] New draft: "CBOR data definition language: a notational convention to express CBOR data structures."
Thread-Index: AQHPCzaGHmsshsw4Q8W8K22Y6ECTkQ==
Date: Mon, 6 Jan 2014 23:25:03 +0000
Message-ID: <CEF08453.34032%jhildebr@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.9.131030
x-originating-ip: [10.129.24.64]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1E139D0D0FBFB54B821AE960109E5726@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [apps-discuss] New draft: "CBOR data definition language: a notational convention to express CBOR data structures."
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Jan 2014 23:25:25 -0000

Interesting.  Based on experience with XML, calling this "schema" may set
the expectation that this information might be used to validate inputs or
generate special-purpose parsers.  Both of these approaches are fraught
with peril in the real world.  Your requirement G7 in section 2 will lead
people toward the attractive nuisance.

I do agree it would be nice to have a consistent ABNF-like mechanism for
specifying CBOR protocols, but the types of protocols you are envisioning
seem to be a little less self-describing than the kinds of JSON protocols
that are more resilient to change over time.  The typical approach for
these is maps that have a set of keys defined for the first version, with
receivers instructed to ignore any map value they don't understand.  In
subsequent versions, new map values can be added safely.  Your section 4.5
doesn't have the nuance yet to handle this approach.

Sections 4.3-4.5, include simple examples.

Section 4.4, the idea of structs that don't have corresponding CBOR wire
protocol is odd, except as a mechanism to make the schema syntax more
readable.  I'm not sure if that's useful enough in practice.

Section 4.6, the const type does seem less useful than it is complex to
me, as you point out at the end of the section.

Section 4.8, optional values seem to me like they're going to cause
interop problems, particularly if the struct isn't defined in the *
(array) form.

Overall, I think you've got something a little more complicated than it
could be to solve the slightly smaller problem that is safe (ish) to solve.



On 1/1/14 11:06 PM, "Bert Greevenbosch" <Bert.Greevenbosch@huawei.com>
wrote:

>Hello all,
>=20
>I have uploaded the following draft:
>https://datatracker.ietf.org/doc/draft-greevenbosch-appsawg-cbor-cddl/
>=20
>The draft introduces a notation to express CBOR data structures.
>=20
>CBOR has recently been defined in RFC 7049. It is a general binary data
>format, which can be used to encode data in a structural way. Next to
>general data fields such as "integer" and "string", CBOR also supports
>signalling
> of e.g. arrays and maps.
>=20
>RFC 7049 does not define how to write down CBOR data structures in
>specifications. I think it would be useful to have a standardised way for
>this, hence this new draft.
>=20
>Since there is no working group chartered to do CBOR work, I have
>uploaded it as input to the general Applications Area working group.
>=20
>I look forward to discussions on this, both technical and procedural. :-)
>=20
>I wish you all a happy 2014!
>=20
>Best regards,
>Bert
>
>


--=20
Joe Hildebrand




From masinter@adobe.com  Tue Jan  7 11:01:44 2014
Return-Path: <masinter@adobe.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1F071ADF9B for <apps-discuss@ietfa.amsl.com>; Tue,  7 Jan 2014 11:01:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.154
X-Spam-Level: 
X-Spam-Status: No, score=0.154 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, 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 dgDQnle4W1Ya for <apps-discuss@ietfa.amsl.com>; Tue,  7 Jan 2014 11:01:42 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0237.outbound.protection.outlook.com [207.46.163.237]) by ietfa.amsl.com (Postfix) with ESMTP id 5845B1AD935 for <apps-discuss@ietf.org>; Tue,  7 Jan 2014 11:01:42 -0800 (PST)
Received: from BL2PR02MB307.namprd02.prod.outlook.com (10.141.91.21) by BL2PR02MB308.namprd02.prod.outlook.com (10.141.91.24) with Microsoft SMTP Server (TLS) id 15.0.842.7; Tue, 7 Jan 2014 19:01:32 +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; Tue, 7 Jan 2014 19:01:32 +0000
From: Larry Masinter <masinter@adobe.com>
To: =?utf-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= <duerst@it.aoyama.ac.jp>, Tim Bray <tbray@textuality.com>
Thread-Topic: draft-ietf-appsawg-xml-mediatypes vs. JSON and BOM and UTF-8
Thread-Index: Ac8L2XBoRlaAodKPT3Ke5g3Ngorsig==
Date: Tue, 7 Jan 2014 19:01:31 +0000
Message-ID: <dc29826a2bbf48088abe51bb5de22e0d@BL2PR02MB307.namprd02.prod.outlook.com>
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: 008421A8FF
x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(13464003)(24454002)(189002)(199002)(479174003)(51704005)(377454003)(65816001)(80022001)(74706001)(4396001)(85852003)(76176001)(66066001)(19580395003)(76796001)(33646001)(16601075003)(87266001)(76786001)(15975445006)(81816001)(76576001)(63696002)(74876001)(81686001)(56776001)(83072002)(77982001)(54316002)(87936001)(59766001)(80976001)(83322001)(19580405001)(81542001)(2656002)(54356001)(74316001)(76482001)(81342001)(53806001)(46102001)(50986001)(90146001)(74502001)(74662001)(47736001)(56816005)(15202345003)(47976001)(74366001)(85306002)(31966008)(47446002)(49866001)(69226001)(79102001)(51856001)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR02MB308; H:BL2PR02MB307.namprd02.prod.outlook.com; CLIP:50.184.24.49; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; 
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: adobe.com
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: [apps-discuss] draft-ietf-appsawg-xml-mediatypes vs. JSON and BOM and UTF-8
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Jan 2014 19:01:44 -0000

SSBoYXZlIHNvbWUgZGlzY3Vzc2lvbiB0b3BpY3MgZm9yIGRyYWZ0LWlldGYtYXBwc2F3Zy14bWwt
bWVkaWF0eXBlcyB3aGljaCBJIHdpbGwgc2VuZCBvdXQgb25lLWJ5LW9uZS4NClRoaXMgZmlyc3Qg
b25lIHdhcyBkaXNjdXNzZWQgYnV0IGhlcmUgSSdtIG1ha2luZyBzb21lIHNwZWNpZmljIHN1Z2dl
c3Rpb25zLg0KDQpJdCBjYW5ub3QgYmUgcmlnaHQgdGhhdCBldmVyeW9uZSBzcGVjaWZ5aW5nIGEg
dGV4dC1iYXNlZCBtZWRpYSB0eXBlIHNob3VsZCBoYXZlIHRvIGdvIHRocm91Z2ggdGhlIHByb2Nl
c3Mgb2YgZGVjaWRpbmcsIGZvciB0aGVtc2VsdmVzLCBpbmRlcGVuZGVudGx5LCBob3cgdG8gZGVj
aWRlIGJldHdlZW4gY29uZmxpY3Rpbmcgc291cmNlcyBvZiBpbmZvcm1hdGlvbiBhYm91dCBjaGFy
c2V0LCBjb21pbmcgZnJvbSBhbiBpbml0aWFsIEJPTSwgZnJvbSBleHRlcm5hbCBtZXRhZGF0YSwg
ZnJvbSBhbnkgc3VwcGxpZWQgImNoYXJzZXQiIHBhcmFtZXRlciBvZiB0aGUgbWVkaWEgdHlwZSwg
YW5kIGZyb20gaW50ZXJuYWwgZW1iZWRkZWQgbWV0YWRhdGEgc3VjaCBhcyBmb3VuZCBpbiBYTUwu
DQoNCklmIHRoZSBmdXR1cmUgaXMgVVRGLTgsIFVURi04LCBVVEYtOCwgdGhlbiB0aGUgdHdvIGRv
Y3VtZW50cyBzaG91bGQgc2F5IHNvLCByaWdodCBhdCB0aGUgYmVnaW5uaW5nLg0KDQpodHRwOi8v
dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWFwcHNhd2cteG1sLW1lZGlhdHlwZXMtMDYj
c2VjdGlvbi0zDQogICAgICBHb2luZyBmb3J3YXJkLCBYTUwgcHJvZHVjZXJzIFNIT1VMRCB1c2Ug
VVRGLTggZXhjbHVzaXZlbHksIHdpdGhvdXQgYW55IEJPTS4gRm9yIGNvbXBhdGliaWxpdHkgd2l0
aCBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMsIHByb2Nlc3NpbmcgcnVsZXMgYXJlIGdpdmVuLg0K
DQpUaGVuIHNlY3Rpb24gMy4xIFhNTCBNSU1FIHByb2R1Y2Vycw0KICAgICJYTUwgTUlNRSBwcm9k
dWNlcnMiIGdlbmVyYXRpbmcgYSBNSU1FIGJvZHkgKHdobyBTSE9VTEQgZW5jb2RlIHRoZSBYTUwg
YXMgVVRGLTggd2l0aG91dCBhIEJPTSwgYW5kIFNIT1VMRCBhbHNvIGluY2x1ZGUgYSBVVEYtOCBl
bmNvZGluZyBkZWNsYXJhdGlvbikNCkFuZA0KICAgJ1hNTCBNSU1FIHdyYXBwZXJzIiB0aG9zZSB0
aGF0IGFyZSBub3QgcmUtZW5jb2RpbmcgYW4gWE1MIGJvZHkgYW5kIGp1c3Qgd2FudCB0byBkZWxp
dmVyIGl0IHZpYSBNSU1FDQogICB3aG8gY2FuIGZvbGxvdyB0aGUgZ3VpZGVsaW5lcyBpbiAzLjEu
IA0KICAgSSBkb24ndCByZWFsbHkgdW5kZXJzdGFuZCB3aGF0IGEgIlhNTC11bmF3YXJlIE1JTUUg
cHJvZHVjZXIiIGlzLiBJZiB0aGV5J3JlICJ1bmF3YXJlIiwgd2h5IGFyZSB0aGV5IHJlYWRpbmcg
dGhpcyBzcGVjPw0KDQpMYXJyeQ0KLS0NCmh0dHA6Ly9sYXJyeS5tYXNpbnRlci5uZXQNCg0KLS0t
LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206ICJNYXJ0aW4gSi4gRMO8cnN0IiBbbWFpbHRv
OmR1ZXJzdEBpdC5hb3lhbWEuYWMuanBdIA0KU2VudDogU2F0dXJkYXksIERlY2VtYmVyIDE0LCAy
MDEzIDQ6MjYgQU0NClRvOiBUaW0gQnJheQ0KQ2M6IExhcnJ5IE1hc2ludGVyOyBJRVRGIEFwcHMg
RGlzY3Vzcw0KU3ViamVjdDogUmU6IFthcHBzLWRpc2N1c3NdIFVuaWNvZGUgQk9NIGRldGVjdGlv
biBpbiBKU09OIHZzLiBkcmFmdC1pZXRmLWFwcHNhd2cteG1sLW1lZGlhdHlwZXMNCg0KT24gMjAx
My8xMi8xNCA3OjIwLCBUaW0gQnJheSB3cm90ZToNCj4gSSBhY3R1YWxseSB0aGluayA0NjI3Ymlz
IGlzIHBlcmZlY3RseSBjbGVhci4gWW91IGNhbiB1c2UgVVRGLXs4LzE2LzMyfSBpbg0KPiB0aGVv
cnk7IGluIHByYWN0aWNlIG9ubHkgVVRGLTggd29ya3Mgb3ZlciB0aGUgd2lyZTsgeW91IE1VU1Qg
Tk9UIGVtaXQgYSBCT00NCj4gYnV0IGlmIHNvbWUgZG9yayBkb2VzLCBpdOKAmXMgT0sgdG8gZm9y
Z2l2ZS4gVGhlcmXigJlzIG5vIGNoYXJzZXQgcGFyYW1ldGVyIG9uDQo+IHRoZSBtZWRpYSB0eXBl
Lg0KPg0KPiBJZiB3ZSB3ZXJlIGRvaW5nIFhNTCBpbiAyMDEzLCBJIHRoaW5rIHdl4oCZZCBwcm9i
YWJseSBlbmQgdXAgYXQgdGhlIHNhbWUNCj4gcGxhY2UuIE5vdGUgdGhhdCB0aGUgb3JpZ2luYWwg
WE1MIHNwZWMgd2FzIHdyaXR0ZW4gaW4gSVNPLTg4NTktMSA6KQ0KDQpZZXMuIE9uIHRoZSBzdXJm
YWNlLCBzb21lIG9mIHRoZSBpc3N1ZXMgaW4gSlNPTiBhbmQgWE1MIG1heSBsb29rIA0Kc2ltaWxh
ciwgYnV0IGluIGFjdHVhbCBwcmFjdGljZSwgdGhleSBhcmUgcXVpdGUgZGlmZmVyZW50LiBTbyBh
IGNvbW1vbiANCm1vZGVsIG9yIGEgY29tbW9uIHNwZWMgZG9lc24ndCBtYWtlIHNlbnNlLg0KDQpX
ZSBoYXZlIGhhZCBzb21lIGtpbmQgb2YgY29tbW9uIG1vZGVsIGZyb20gYXJvdW5kIDE5OTYgb3Ig
c28sIHdoaWNoIHdhcyANCnRoYXQgdGhlIG91dHNpZGUgKGNoYXJzZXQgcGFyYW1ldGVyKSBoYXMg
cHJlY2VkZW5jZS4gVGhpcyB3YXMgYmFzZWQgb24gDQp0aGUgYXNzdW1wdGlvbiB0aGF0IHRoZXJl
IHdlcmUgdHJhbnNjb2RpbmcgcHJveGllcyB0aGFuIGRpZG4ndCBsb29rIA0KaW5zaWRlIHRoZSBk
b2N1bWVudCwgYW5kIG9uIHN0YXRlbWVudHMgZnJvbSBOZXRzY2FwZSAod2hlbiBpdCB3YXMgc3Rp
bGwgDQp0aGUgZG9taW5hbnQgYnJvd3NlcikgdGhhdCB0aGlzIHdhcyB3aGF0IHRoZXkgZGlkLg0K
DQpJdCB0dXJuZWQgb3V0IHRoYXQgdGhlcmUgd2VyZSBmZXcgaWYgYW55IHRyYW5zY29kaW5nIHBy
b3hpZXMsIGFuZCANCmV4dGVybmFsIGluZm9ybWF0aW9uIGRpZG4ndCBnZXQgcHJlc2VydmVkIHdl
bGwgaW4gYSBmaWxlIHN5c3RlbSwgYW5kIHNvIA0KdGhlIHByYWN0aWNlIG1vdmVkIG1vcmUgYW5k
IG1vcmUgdG8gZ2l2ZSBwcmlvcml0eSBvZiBpbnRlcm5hbCANCmluZm9ybWF0aW9uIG92ZXIgZXh0
ZXJuYWwuDQoNCkluIGlldGYtYXBwc2F3Zy14bWwtbWVkaWF0eXBlcywgd2UgY2FuIHNlZSBvbmUg
c3BlY2lmaWMgZXhhbXBsZSBvZiB3aGF0IA0KdGhpcyBoaXN0b3J5IGhhcyByZXN1bHRlZCBpbjog
Y2FyZWZ1bGx5IGRlZmluZWQgc3BlY2lmaWMgc3RlcHMsIGJ1dCBub3QgDQp0b28gcHJldHR5IGFu
IG92ZXJhbGwgcGljdHVyZS4NCg0KVGhlIG1vZGVsIG9mIHRoZSBmdXR1cmUgaXMgbXVjaCBzaW1w
bGVyOiBVVEYtOCwgVVRGLTgsIFVURi04LiBPbmNlIA0KZXZlcnl0aGluZyBpcyBVVEYtOCwgdGhl
IEJPTSB3aWxsIGRpZSBhIHF1aWV0IGRlYXRoLCB0b28uDQoNClJlZ2FyZHMsICAgTWFydGluLg0K
DQo+IE9uIEZyaSwgRGVjIDEzLCAyMDEzIGF0IDI6MTAgUE0sIExhcnJ5IE1hc2ludGVyPG1hc2lu
dGVyQGFkb2JlLmNvbT4gIHdyb3RlOg0KPg0KPj4gICBDb21wYXJlDQo+PiBodHRwOi8vdG9vbHMu
aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWpzb24tcmZjNDYyN2Jpcy0wOSNzZWN0aW9uLTguMQ0K
Pj4NCj4+IGFuZA0KPj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1hcHBz
YXdnLXhtbC1tZWRpYXR5cGVzLTA2I3NlY3Rpb24tMw0KPj4NCj4+DQo+Pg0KPj4gaXTigJlzIGhh
cmQgdG8gdGVsbCBleGFjdGx5IHdoYXQgZWl0aGVyIGlzIHNheWluZywgbXVjaCBsZXNzIHdoZXRo
ZXIgdGhleeKAmXJlDQo+PiBzYXlpbmcNCj4+DQo+PiB0aGUgc2FtZSB0aGluZy4gICBJIGRvbuKA
mXQgd2FudCB0byBzbG93IGRvd24gZWl0aGVyIG9mIHRoZXNlLCBidXQgc29tZSB3b3JrDQo+PiBv
bg0KPj4NCj4+IGEgbW9kZWwgZm9yIGhvdyBNSU1FIHR5cGVzIHNob3VsZCBkZWFsIHdpdGggdGhl
IHJlbGF0aW9uc2hpcCBiZXR3ZWVuDQo+Pg0KPj4NCj4+DQo+PiAtICAgICAgICAgIENoYXJzZXQg
cGFyYW1ldGVyIGluIGNvbnRlbnQtdHlwZQ0KPj4NCj4+IC0gICAgICAgICAgUG9zc2libGUgQk9N
IG1ha2VyDQo+Pg0KPj4gLSAgICAgICAgICBPdGhlciBpbi1jb250ZW50IGNoYXJhY3RlciBzZXQg
aW5kaWNhdGlvbiAobGlrZSBpbiBYTUwpDQo+Pg0KPj4gLSAgICAgICAgICBPdGhlciBwcm90b2Nv
bCBzb3VyY2VzIG9mIGNoYXJzZXQgaW5mb3JtYXRpb24NCj4+DQo+Pg0KPj4NCj4+IEpTT04sIFhN
TCwgSFRNTCwgSVJJcywgZWxlbWVudHMgYmFzZWQgb24gdGhvc2UsIGFuZCBsaWtlbHkgbWFueSBv
dGhlcg0KPj4NCj4+IHByb3RvY29sIGVsZW1lbnRzIGFyZSBkZWZpbmVkIHVzaW5nIEJORiBvciBv
dGhlciBzeW50YWN0aWMgZGVzY3JpcHRpb24NCj4+DQo+PiB0ZWNobmlxdWVzIG92ZXIgdGhlIHNw
YWNlIG9mIHNlcXVlbmNlLW9mLVVuaWNvZGUtY2hhcmFjdGVycw0KPj4NCj4+IChzZXF1ZW5jZS1v
Zi1Vbmljb2RlLWNvZGUtcG9pbnQpLg0KPj4NCj4+DQo+Pg0KPj4gSGFzIHRoZXJlIGJlZW4gYW55
IGF0dGVtcHRzIHRvIGNyZWF0ZSBhIHNlcGFyYXRlIEJDUCB0aGF0IEpTT04gYW5kIFhNTA0KPj4N
Cj4+IENvdWxkIChpbiB0aGUgZnV0dXJlKSByZWZlcmVuY2U/IFRoZSBKU09OIHdvcmtpbmcgZ3Jv
dXAgc3BlbnQgb25seQ0KPj4NCj4+IGEgZmV3IHRob3VzYW5kIGVtYWlscyBvbiB0aGlzLg0KPj4N
Cj4+DQo+Pg0KPj4gTGFycnkNCj4+DQo+PiAtLQ0KPj4NCj4+IGh0dHA6Ly9sYXJyeS5tYXNpbnRl
ci5uZXQNCj4+DQo+Pg0KPj4NCj4+DQo+Pg0KPg0KPg0KPg0KPiBfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBhcHBzLWRpc2N1c3MgbWFpbGluZyBsaXN0
DQo+IGFwcHMtZGlzY3Vzc0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL2FwcHMtZGlzY3Vzcw0K

From paf@frobbit.se  Tue Jan  7 11:23:39 2014
Return-Path: <paf@frobbit.se>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0CEC1AE14F for <apps-discuss@ietfa.amsl.com>; Tue,  7 Jan 2014 11:23:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.666
X-Spam-Level: 
X-Spam-Status: No, score=0.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gzhVEyJJQcBG for <apps-discuss@ietfa.amsl.com>; Tue,  7 Jan 2014 11:23:38 -0800 (PST)
Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) by ietfa.amsl.com (Postfix) with ESMTP id D3D5A1AE152 for <apps-discuss@ietf.org>; Tue,  7 Jan 2014 11:23:05 -0800 (PST)
Received: from [IPv6:2a02:80:3ffc::2087:3375:684d:61f8] (unknown [IPv6:2a02:80:3ffc:0:2087:3375:684d:61f8]) by mail.frobbit.se (Postfix) with ESMTPSA id 56F572005D; Tue,  7 Jan 2014 20:22:56 +0100 (CET)
Content-Type: multipart/signed; boundary="Apple-Mail=_564A6EB0-8ED6-4427-9A60-97556754739A"; protocol="application/pgp-signature"; micalg=pgp-sha1
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@frobbit.se>
In-Reply-To: <dc29826a2bbf48088abe51bb5de22e0d@BL2PR02MB307.namprd02.prod.outlook.com>
Date: Tue, 7 Jan 2014 20:22:55 +0100
Message-Id: <7E33C6E3-DA4A-48EF-AB20-8A79DD41BE86@frobbit.se>
References: <dc29826a2bbf48088abe51bb5de22e0d@BL2PR02MB307.namprd02.prod.outlook.com>
To: Larry Masinter <masinter@adobe.com>
X-Mailer: Apple Mail (2.1827)
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] draft-ietf-appsawg-xml-mediatypes vs. JSON and BOM and UTF-8
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Jan 2014 19:23:39 -0000

--Apple-Mail=_564A6EB0-8ED6-4427-9A60-97556754739A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


On 7 jan 2014, at 20:01, Larry Masinter <masinter@adobe.com> wrote:

> If the future is UTF-8, UTF-8, UTF-8, then the two documents should =
say so, right at the beginning.

+1000

   Patrik


--Apple-Mail=_564A6EB0-8ED6-4427-9A60-97556754739A
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

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

iD8DBQFSzFQPrMabGguI180RAmPiAJ4l3B0r/3F+6OUs3ABagq6cJQxhYgCggrmg
/QrUy934xzgARwR1WHsL074=
=tS/Z
-----END PGP SIGNATURE-----

--Apple-Mail=_564A6EB0-8ED6-4427-9A60-97556754739A--

From ht@inf.ed.ac.uk  Wed Jan  8 02:00:45 2014
Return-Path: <ht@inf.ed.ac.uk>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29E441AE13B for <apps-discuss@ietfa.amsl.com>; Wed,  8 Jan 2014 02:00:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.84
X-Spam-Level: 
X-Spam-Status: No, score=-2.84 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 APMyw_syiQvN for <apps-discuss@ietfa.amsl.com>; Wed,  8 Jan 2014 02:00:42 -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 39FBA1AE135 for <apps-discuss@ietf.org>; Wed,  8 Jan 2014 02:00:41 -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 s08A0EWp016047;  Wed, 8 Jan 2014 10:00:19 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 s08A0Biq002670; Wed, 8 Jan 2014 10:00:11 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 s08A0CP5016148; Wed, 8 Jan 2014 10:00:12 GMT
Received: (from ht@localhost) by troutbeck.inf.ed.ac.uk (8.14.4/8.14.4/Submit) id s08A0AeC016144; Wed, 8 Jan 2014 10:00:10 GMT
X-Authentication-Warning: troutbeck.inf.ed.ac.uk: ht set sender to ht@inf.ed.ac.uk using -f
To: Larry Masinter <masinter@adobe.com>
References: <dc29826a2bbf48088abe51bb5de22e0d@BL2PR02MB307.namprd02.prod.outlook.com>
From: ht@inf.ed.ac.uk (Henry S. Thompson)
Date: Wed, 08 Jan 2014 10:00:10 +0000
In-Reply-To: <dc29826a2bbf48088abe51bb5de22e0d@BL2PR02MB307.namprd02.prod.outlook.com> (Larry Masinter's message of "Tue\, 7 Jan 2014 19\:01\:31 +0000")
Message-ID: <f5b38kyhjyt.fsf@troutbeck.inf.ed.ac.uk>
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: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] draft-ietf-appsawg-xml-mediatypes vs. JSON and BOM and UTF-8
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Jan 2014 10:00:45 -0000

Larry Masinter writes:

> I have some discussion topics for draft-ietf-appsawg-xml-mediatypes
> which I will send out one-by-one.

Great, thanks.

> This first one was discussed but here I'm making some specific suggestions.

I'll respond later to the larger issue here, but not for a few days,
TAG meeting this week.

> ...

> Then section 3.1 XML MIME producers
>     "XML MIME producers" generating a MIME body (who SHOULD encode
>     the XML as UTF-8 without a BOM, and SHOULD also include a UTF-8
>     encoding declaration)
> And
>    'XML MIME wrappers" those that are not re-encoding an XML body
>    and just want to deliver it via MIME who can follow the
>    guidelines in 3.1.
> I don't really understand what a "XML-unaware MIME producer" is. If
> they're "unaware", why are they reading this spec?

I think this makes sense -- it means any MIME producer who respects
media type registrations as far as possible, including this one, but
doesn't have XML processing capabiities, so in particular can't detect
or make use of XML encoding declarations.

I can try to clarify this in the draft.

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 jan.algermissen@nordsc.com  Wed Jan  8 06:46:21 2014
Return-Path: <jan.algermissen@nordsc.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4866B1AE3C1 for <apps-discuss@ietfa.amsl.com>; Wed,  8 Jan 2014 06:46:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level: 
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 e1zGO6m5ueAf for <apps-discuss@ietfa.amsl.com>; Wed,  8 Jan 2014 06:46:20 -0800 (PST)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by ietfa.amsl.com (Postfix) with ESMTP id DE9D61ACCE2 for <apps-discuss@ietf.org>; Wed,  8 Jan 2014 06:46:19 -0800 (PST)
Received: from [10.90.143.216] ([87.253.171.202]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0LaacB-1VXaz01PQ7-00m3Pl; Wed, 08 Jan 2014 15:46:09 +0100
From: Jan Algermissen <jan.algermissen@nordsc.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <A4A8D5B5-73D7-4F4C-968A-D23337DF4FA2@nordsc.com>
Date: Wed, 8 Jan 2014 15:46:08 +0100
To: "apps-discuss@ietf.org Discuss" <apps-discuss@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
X-Mailer: Apple Mail (2.1510)
X-Provags-ID: V02:K0:WS1zSV1LKURZnBw3wBJvXsnvzfTr+JdZwBYJ69+Ed8H U2rlWCJP+HAC8Jt1u2LJxf49jZPi6SDBf1h0CM8I2cDCMSkHLn j5CRoOEiNyctlSVkIi3X+PQ6+QCDNAiJ39d2evqMNcjWMjK2K4 K7ozdhBAwayHNhDR6MEedFWyqLiJ6ACxNPziR4R/4c+a0zhmAj 6xvAfEpPDHmhIk319RboXVWLQ2MO+j02TrxpttXQ20V+6pLhl9 Azs03EoEMztYpHIWOEmLncpLRwIJWSF0nVjX+IZbruF/S/6mlW hF+jcPCL0DE6t18IldqEyM8iIFL2UZy8w87HeJHZrTCSjckIhK tFNLWj6/NutbxWEosEUq9CuxUa7EL+2PQyH0aKT5CvoXrGFU18 OJmS+Hup3ASWw==
Subject: [apps-discuss] Media type for lists of changed URIs?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Jan 2014 14:46:21 -0000

Hi all,

I am about to work on a media type for transferring lists of URIs of =
resource that have changed to an 'observer' of a collection of =
resources.

It just occurred to me that something like that might already exist in =
the context of cache invalidation protocols.?

Jan



From derhoermi@gmx.net  Wed Jan  8 07:06:25 2014
Return-Path: <derhoermi@gmx.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB341AE420 for <apps-discuss@ietfa.amsl.com>; Wed,  8 Jan 2014 07:06:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.438
X-Spam-Level: 
X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.538, 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 KIso7y-byL6N for <apps-discuss@ietfa.amsl.com>; Wed,  8 Jan 2014 07:06:23 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id B5B071AE41F for <apps-discuss@ietf.org>; Wed,  8 Jan 2014 07:06:22 -0800 (PST)
Received: from netb.Speedport_W_700V ([91.35.45.214]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0M0tr1-1V79rP2xnL-00v4Qy for <apps-discuss@ietf.org>; Wed, 08 Jan 2014 16:06:13 +0100
From: Bjoern Hoehrmann <derhoermi@gmx.net>
To: Jan Algermissen <jan.algermissen@nordsc.com>
Date: Wed, 08 Jan 2014 16:06:13 +0100
Message-ID: <l9qqc9l8fg5ui07l6h31s1bbig9uc7t90d@hive.bjoern.hoehrmann.de>
References: <A4A8D5B5-73D7-4F4C-968A-D23337DF4FA2@nordsc.com>
In-Reply-To: <A4A8D5B5-73D7-4F4C-968A-D23337DF4FA2@nordsc.com>
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K0:9ex6hYH0CyBVpdVQa7uJTZdgV3Pn1L2Z8Cjusgr0CSIaB2uqcV5 JrPmnP9wGaoeyc9K+Fzd5CrBnR2Aj7Q6cXkLOwUzkPFrsLGWGnAgFuvFs+GULSf8uwGnqxa uCQvIE1Q3VEPLBIvVmE/stgm/KVDdPN/OE4vomK2+gP8e2K1XAtkE2Up6D6Z8uqqO+DeGTA ZkcGrCpFdCUVZ8NJPgc+A==
Cc: "apps-discuss@ietf.org Discuss" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Media type for lists of changed URIs?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Jan 2014 15:06:25 -0000

* Jan Algermissen wrote:
>I am about to work on a media type for transferring lists of URIs of 
>resource that have changed to an 'observer' of a collection of 
>resources.
>
>It just occurred to me that something like that might already exist in 
>the context of cache invalidation protocols.?

http://tools.ietf.org/html/rfc2483 defines `text/uri-list`.
-- 
Bj�rn H�hrmann � mailto:bjoern@hoehrmann.de � http://bjoern.hoehrmann.de
Am Badedeich 7 � Telefon: +49(0)160/4415681 � http://www.bjoernsworld.de
25899 Dageb�ll � PGP Pub. KeyID: 0xA4357E78 � http://www.websitedev.de/ 

From darrel.miller@gmail.com  Wed Jan  8 07:08:44 2014
Return-Path: <darrel.miller@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A8581AD9B7 for <apps-discuss@ietfa.amsl.com>; Wed,  8 Jan 2014 07:08:44 -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 Jb2xGBPDPn-K for <apps-discuss@ietfa.amsl.com>; Wed,  8 Jan 2014 07:08:42 -0800 (PST)
Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 36DD31AE428 for <apps-discuss@ietf.org>; Wed,  8 Jan 2014 07:08:38 -0800 (PST)
Received: by mail-ie0-f169.google.com with SMTP id e14so2089798iej.0 for <apps-discuss@ietf.org>; Wed, 08 Jan 2014 07:08:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=fLJ33XJ1XPcbJfG9bYHS9b8gnrcriGP/SQoCmlO/mOY=; b=cedWhbwsSZNVXj9AeBncgMnHJq3MMX/PVz/AqW/ZIMZDpjXHGBQzVY9NPCKZNIVdQk jcYREl6UlSSNdHgbwvRr261t3GbZPfzlBLJD4YlognUUT37ExTiHhfy1/lc0SBGww8IR dlcwZrsXhTHz8pheTXZ4q/Yu/ug6Xf+pNsQ06VrAzFt/6PMvoXFcdbP94pSsae+38Brg wDbV7iSQfnJ/2pSFJP2w5eGf6+FrqIIx1ae6zca/hbwUiNoWuUd0ylQqdH92AHpXV1YM jFoFLAr0FhEYimj7ifF7Pfdm/FnUGk2hPp3I3EcM583qr5lgzuhYMo3AMy2OYvEWcVaJ eRZQ==
MIME-Version: 1.0
X-Received: by 10.50.29.114 with SMTP id j18mr32303006igh.24.1389193708967; Wed, 08 Jan 2014 07:08:28 -0800 (PST)
Received: by 10.42.195.206 with HTTP; Wed, 8 Jan 2014 07:08:28 -0800 (PST)
In-Reply-To: <CAKioOqsz_GPu3LmZjnv6MBWx9ENHEu8nzSDEsN=4WCpZeb_YLg@mail.gmail.com>
References: <A4A8D5B5-73D7-4F4C-968A-D23337DF4FA2@nordsc.com> <CAKioOqsz_GPu3LmZjnv6MBWx9ENHEu8nzSDEsN=4WCpZeb_YLg@mail.gmail.com>
Date: Wed, 8 Jan 2014 10:08:28 -0500
Message-ID: <CAKioOquabW6RpPoAeheVSL0zOv3K6P-eyBB0FcyHvS6PpJ3-HQ@mail.gmail.com>
From: Darrel Miller <darrel.miller@gmail.com>
To: IETF Apps Discuss <apps-discuss@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1
Subject: [apps-discuss] Fwd:  Media type for lists of changed URIs?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: darrel@tavis.ca
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Jan 2014 15:08:44 -0000

Argggh gmail.  Forgot to cc the list.


---------- Forwarded message ----------
From: Darrel Miller <darrel.miller@gmail.com>

Could you instead define a link relation like rel="changed" and then
return text/uri-list ?

Darrel

On Wed, Jan 8, 2014 at 9:46 AM, Jan Algermissen
<jan.algermissen@nordsc.com> wrote:
> Hi all,
>
> I am about to work on a media type for transferring lists of URIs of resource that have changed to an 'observer' of a collection of resources.
>
> It just occurred to me that something like that might already exist in the context of cache invalidation protocols.?
>
> Jan
>
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss

From jan.algermissen@nordsc.com  Wed Jan  8 07:10:40 2014
Return-Path: <jan.algermissen@nordsc.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EF411AE429 for <apps-discuss@ietfa.amsl.com>; Wed,  8 Jan 2014 07:10:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level: 
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 8Nl4q6TEqC54 for <apps-discuss@ietfa.amsl.com>; Wed,  8 Jan 2014 07:10:38 -0800 (PST)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by ietfa.amsl.com (Postfix) with ESMTP id B92AB1AD8D5 for <apps-discuss@ietf.org>; Wed,  8 Jan 2014 07:10:37 -0800 (PST)
Received: from [10.90.143.216] ([87.253.171.202]) by mrelayeu.kundenserver.de (node=mrbap4) with ESMTP (Nemesis) id 0MZDyO-1VfwVy3ha0-00KzQz; Wed, 08 Jan 2014 16:10:27 +0100
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jan Algermissen <jan.algermissen@nordsc.com>
In-Reply-To: <CAKioOquabW6RpPoAeheVSL0zOv3K6P-eyBB0FcyHvS6PpJ3-HQ@mail.gmail.com>
Date: Wed, 8 Jan 2014 16:10:26 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <5DC99287-9CB0-48B6-B237-CFDEAF8BCB8E@nordsc.com>
References: <A4A8D5B5-73D7-4F4C-968A-D23337DF4FA2@nordsc.com> <CAKioOqsz_GPu3LmZjnv6MBWx9ENHEu8nzSDEsN=4WCpZeb_YLg@mail.gmail.com> <CAKioOquabW6RpPoAeheVSL0zOv3K6P-eyBB0FcyHvS6PpJ3-HQ@mail.gmail.com>
To: darrel@tavis.ca
X-Mailer: Apple Mail (2.1510)
X-Provags-ID: V02:K0:SNx5fJ5htnhyylFlPykTPDf2sZOlo09uH/i6N8leW4Y GTMTJ0abytQeGNbZNJU6hOUoJLIkeNHp1txCamgaC0T7hpIxy+ 4woFF7e9p6CqSF7tooZ1K0FvFSC69MsH5XJYcDqguqIbhepOyS VaysKOwIy8pKf9mzsMNLqmZBWB4DQkedaiDVgP8bMZ+Lx9qoPA 85HKptyy9iplVy0y/EecMbNKNLLeUv0JkVtTnsZV+2CYAn7d/R +MU2kWJlGkE3HbfgJeNLzO2I+NBYlwi+NgPWIF1zg3e/9u2NNz lsM/wqqvQInAp21iurgXiqoc9YOBzVWebMVQyGjMz4ZxW4hsoe ZgJxBhkG9WBzKSSOtTchoeqHQnZXp8gBpO2olCzeuPBS+ZITxM M57m5nOAxEu5Q==
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Fwd:  Media type for lists of changed URIs?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Jan 2014 15:10:40 -0000

On 08.01.2014, at 16:08, Darrel Miller <darrel.miller@gmail.com> wrote:

> Argggh gmail.  Forgot to cc the list.

Well then, here's my reply again :-)

>=20
>=20
> ---------- Forwarded message ----------
> From: Darrel Miller <darrel.miller@gmail.com>
>=20
> Could you instead define a link relation like rel=3D"changed" and then
> return text/uri-list ?

Yes, exactly where I am at.

However, I'd like to remove the burdon of timing issues from the =
"protocol" and instead use linked paged (rel=3Dprev-archive) for clients =
to process backwards until their last remembered timestamp.

Hence, I'd need something like

timestamp uri
timestamp uri

and this is where I wrote the last email :-)

Jan



>=20
> Darrel
>=20
> On Wed, Jan 8, 2014 at 9:46 AM, Jan Algermissen
> <jan.algermissen@nordsc.com> wrote:
>> Hi all,
>>=20
>> I am about to work on a media type for transferring lists of URIs of =
resource that have changed to an 'observer' of a collection of =
resources.
>>=20
>> It just occurred to me that something like that might already exist =
in the context of cache invalidation protocols.?
>>=20
>> Jan
>>=20
>>=20
>> _______________________________________________
>> 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 mca@amundsen.com  Wed Jan  8 07:20:17 2014
Return-Path: <mca@amundsen.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD0E1AE407 for <apps-discuss@ietfa.amsl.com>; Wed,  8 Jan 2014 07:20:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.155
X-Spam-Level: *
X-Spam-Status: No, score=1.155 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FM_FORGED_GMAIL=0.622, FORGED_YAHOO_RCVD=1.63, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, NML_ADSP_CUSTOM_MED=0.9, 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 6o6cReI4eUU4 for <apps-discuss@ietfa.amsl.com>; Wed,  8 Jan 2014 07:20:15 -0800 (PST)
Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) by ietfa.amsl.com (Postfix) with ESMTP id 87C401ADEB7 for <apps-discuss@ietf.org>; Wed,  8 Jan 2014 07:20:15 -0800 (PST)
Received: by mail-wi0-f173.google.com with SMTP id hn9so5670101wib.12 for <apps-discuss@ietf.org>; Wed, 08 Jan 2014 07:20:05 -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:sender:in-reply-to:references:from :date:message-id:subject:to:content-type; bh=SSnhJ2k5kgEtfjYuaG4V21DblaMmmDU2aGiHR1KI3/8=; b=l/FIoo6fBFcawAZqp6JzPvbgw5nkluzoieVu/HqYgvgyduEBm1qOaXAiAUxPG7TLB5 gDT6V6oiQRo0A7iKACO9amSo/Bv2rzTHJWt6X+r/dJB1Ce46DDv0aVwRYlEdy9cIv9i9 CRgaAJzo3XpWOP3b1Hl//7uIMpXlnIfvBagYZTR+sNzJYLhhAKewAfflhZzHW++ndqic qnl92TMV1EX4XX46u51mzrIPAtMS021nlOG/HzqvUZ28wh+4YCzPFklOgUQ4HTWO/AD9 /HRvtSicdxCsHiv/zUlaCN7e8UEYVtZi2pPUnXK98xTj8sDxSDCdRmxwRGij6oiWM+Aw lGbw==
X-Gm-Message-State: ALoCoQk56o/+Bzos2LZBOyFS5t5ADEClW0mZVeEwXuDWTKrD/a4dmBA8tr4vIyxvdqpOssrkhYnP
X-Received: by 10.180.14.231 with SMTP id s7mr21904350wic.1.1389194405821; Wed, 08 Jan 2014 07:20:05 -0800 (PST)
MIME-Version: 1.0
Sender: mca@amundsen.com
Received: by 10.194.119.226 with HTTP; Wed, 8 Jan 2014 07:19:45 -0800 (PST)
In-Reply-To: <C8613FAB-B758-44BC-A752-EBAD26D79E7A@nordsc.com>
References: <A4A8D5B5-73D7-4F4C-968A-D23337DF4FA2@nordsc.com> <CAPW_8m7OP8bG4ExEB6Dk867WJkoTgS5ODkM_-J3v0kr6zfyBuQ@mail.gmail.com> <C8613FAB-B758-44BC-A752-EBAD26D79E7A@nordsc.com>
From: mike amundsen <mamund@yahoo.com>
Date: Wed, 8 Jan 2014 10:19:45 -0500
X-Google-Sender-Auth: 7lfsmuK7mDEQpOO90ty2Xvx5SM8
Message-ID: <CAPW_8m5q5hO0QjDiUx9FxU3xhc3b_Kjz3qAwWxQBi2rhJT7nQQ@mail.gmail.com>
To: IETF Apps Discuss <apps-discuss@ietf.org>
Content-Type: multipart/alternative; boundary=f46d040fa004155eb404ef7707d2
Subject: [apps-discuss] Fwd:  Media type for lists of changed URIs?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Jan 2014 15:20:17 -0000

--f46d040fa004155eb404ef7707d2
Content-Type: text/plain; charset=ISO-8859-1

timestamp thing is a wrinkle.

maybe Atom w/ tombstones?
http://tools.ietf.org/html/rfc6721

mamund
+1.859.757.1449
skype: mca.amundsen
http://amundsen.com/blog/
http://twitter.com/mamund
https://github.com/mamund
http://linkedin.com/in/mamund


---------- Forwarded message ----------
From: Jan Algermissen <jan.algermissen@nordsc.com>
Date: Wed, Jan 8, 2014 at 9:57 AM
Subject: Re: [apps-discuss] Media type for lists of changed URIs?
To: mike amundsen <mamund@yahoo.com>



On 08.01.2014, at 15:55, mike amundsen <mamund@yahoo.com> wrote:

> text/uri-list ?

[Same reply as to Darrel :-)] for you:

Yes, exactly where I am at.

However, I'd like to remove the burdon of timing issues from the "protocol"
and instead use linked paged (rel=prev-archive) for clients to process
backwards until their last remembered timestamp.

Hence, I'd need something like

timestamp uri
timestamp uri

and this is where I wrote the last email :-)

Jan







> On Jan 8, 2014 9:46 AM, "Jan Algermissen" <jan.algermissen@nordsc.com>
wrote:
> Hi all,
>
> I am about to work on a media type for transferring lists of URIs of
resource that have changed to an 'observer' of a collection of resources.
>
> It just occurred to me that something like that might already exist in
the context of cache invalidation protocols.?
>
> Jan
>
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss

--f46d040fa004155eb404ef7707d2
Content-Type: text/html; charset=ISO-8859-1

<div dir="ltr">timestamp thing is a wrinkle.<div><br></div><div>maybe Atom w/ tombstones?</div><div><a href="http://tools.ietf.org/html/rfc6721">http://tools.ietf.org/html/rfc6721</a><br clear="all"><div><div dir="ltr"><div>

<br></div>mamund<div><span><span title="Call with Google Voice"><span title="Call with Google Voice"><span id="gc-number-92" class="" title="Call with Google Voice">+1.859.757.1449</span></span></span></span><br>skype: mca.amundsen<br>

<a href="http://amundsen.com/blog/" target="_blank">http://amundsen.com/blog/</a><br><a href="http://twitter.com/mamund" target="_blank">http://twitter.com/mamund</a><br><a href="https://github.com/mamund" target="_blank">https://github.com/mamund</a><br>

<a href="http://linkedin.com/in/mamund" target="_blank">http://linkedin.com/in/mamund</a></div></div></div>
<br><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Jan Algermissen</b> <span dir="ltr">&lt;<a href="mailto:jan.algermissen@nordsc.com">jan.algermissen@nordsc.com</a>&gt;</span><br>

Date: Wed, Jan 8, 2014 at 9:57 AM<br>Subject: Re: [apps-discuss] Media type for lists of changed URIs?<br>To: mike amundsen &lt;<a href="mailto:mamund@yahoo.com">mamund@yahoo.com</a>&gt;<br><br><br><br>
On 08.01.2014, at 15:55, mike amundsen &lt;<a href="mailto:mamund@yahoo.com">mamund@yahoo.com</a>&gt; wrote:<br>
<br>
&gt; text/uri-list ?<br>
<br>
[Same reply as to Darrel :-)] for you:<br>
<br>
Yes, exactly where I am at.<br>
<br>
However, I&#39;d like to remove the burdon of timing issues from the &quot;protocol&quot; and instead use linked paged (rel=prev-archive) for clients to process backwards until their last remembered timestamp.<br>
<br>
Hence, I&#39;d need something like<br>
<br>
timestamp uri<br>
timestamp uri<br>
<br>
and this is where I wrote the last email :-)<br>
<span class=""><font color="#888888"><br>
Jan<br>
</font></span><div class=""><div class="h5"><br>
<br>
<br>
<br>
<br>
<br>
<br>
&gt; On Jan 8, 2014 9:46 AM, &quot;Jan Algermissen&quot; &lt;<a href="mailto:jan.algermissen@nordsc.com">jan.algermissen@nordsc.com</a>&gt; wrote:<br>
&gt; Hi all,<br>
&gt;<br>
&gt; I am about to work on a media type for transferring lists of URIs of resource that have changed to an &#39;observer&#39; of a collection of resources.<br>
&gt;<br>
&gt; It just occurred to me that something like that might already exist in the context of cache invalidation protocols.?<br>
&gt;<br>
&gt; Jan<br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; apps-discuss mailing list<br>
&gt; <a href="mailto:apps-discuss@ietf.org">apps-discuss@ietf.org</a><br>
&gt; <a href="https://www.ietf.org/mailman/listinfo/apps-discuss" target="_blank">https://www.ietf.org/mailman/listinfo/apps-discuss</a><br>
<br>
</div></div></div><br></div></div>

--f46d040fa004155eb404ef7707d2--

From darrel.miller@gmail.com  Wed Jan  8 07:29:54 2014
Return-Path: <darrel.miller@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA1E1ADF5A for <apps-discuss@ietfa.amsl.com>; Wed,  8 Jan 2014 07:29:54 -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 oZxxn6PDnFji for <apps-discuss@ietfa.amsl.com>; Wed,  8 Jan 2014 07:29:52 -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 41D811ADED5 for <apps-discuss@ietf.org>; Wed,  8 Jan 2014 07:29:52 -0800 (PST)
Received: by mail-ie0-f174.google.com with SMTP id at1so2123741iec.19 for <apps-discuss@ietf.org>; Wed, 08 Jan 2014 07:29:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=I5ixHdLe1GpOZv2CeUg7wDwZU+h/xX0+CmZ/LShzsLo=; b=PWBtpIq+GsSCUF+abu9UpG4bOIbrVLX//o1Ypoga/adUleGzepEKoI1yCmimWQVKdo SjVSpzwcxDxnpAg9JELPLnbIIu6M5EAb2QXa41t6JDB3BsL/XLyup2/qKEROW6qmdpya D+M152CdNC0rH07eXJ6z9owDLZKL/auQ4CmbHUgQyOpuDjEdIQ201G8Wxt3bkm92yfpE WruC+GOOJlbpoD1sOuhgXPeYRs+m3Gknn7PE6HqH2zxXFPT6RJVR4Ooge51JLQulvAPK UMXYuHEJ22z6PFaZ0LZmH/Ro2HJe9RJi8UMXgXrvsLTNyyD4vnbM17bywOFymrckALqA CMIA==
MIME-Version: 1.0
X-Received: by 10.43.8.66 with SMTP id or2mr87721863icb.19.1389194982999; Wed, 08 Jan 2014 07:29:42 -0800 (PST)
Received: by 10.42.195.206 with HTTP; Wed, 8 Jan 2014 07:29:42 -0800 (PST)
In-Reply-To: <CAPW_8m5q5hO0QjDiUx9FxU3xhc3b_Kjz3qAwWxQBi2rhJT7nQQ@mail.gmail.com>
References: <A4A8D5B5-73D7-4F4C-968A-D23337DF4FA2@nordsc.com> <CAPW_8m7OP8bG4ExEB6Dk867WJkoTgS5ODkM_-J3v0kr6zfyBuQ@mail.gmail.com> <C8613FAB-B758-44BC-A752-EBAD26D79E7A@nordsc.com> <CAPW_8m5q5hO0QjDiUx9FxU3xhc3b_Kjz3qAwWxQBi2rhJT7nQQ@mail.gmail.com>
Date: Wed, 8 Jan 2014 10:29:42 -0500
Message-ID: <CAKioOqti423aakGfPXWtMjhYOiQ5M_LUYaXfmkfihxLt0JBZbQ@mail.gmail.com>
From: Darrel Miller <darrel.miller@gmail.com>
To: IETF Apps Discuss <apps-discuss@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [apps-discuss] Fwd: Media type for lists of changed URIs?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: darrel@tavis.ca
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Jan 2014 15:29:54 -0000

Jan,

I'm sure you could shoehorn it into a bigger media type like atom or
activity stream, but I haven't seen anything that fits that specific
need.  I'm not sure I follow your prev-archive scenario.  Do you want
a user to be able to ask, "what were the last-updated-dates on these
resources, yesterday, and the day before, etc"?

Darrel

>
>> On Jan 8, 2014 9:46 AM, "Jan Algermissen" <jan.algermissen@nordsc.com>
>> wrote:
>> Hi all,
>>
>> I am about to work on a media type for transferring lists of URIs of
>> resource that have changed to an 'observer' of a collection of resources.
>>
>> It just occurred to me that something like that might already exist in the
>> context of cache invalidation protocols.?
>>
>> Jan
>>
>>
>> _______________________________________________
>> apps-discuss mailing list
>> apps-discuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/apps-discuss
>

From jan.algermissen@nordsc.com  Wed Jan  8 07:37:53 2014
Return-Path: <jan.algermissen@nordsc.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE84A1AE463 for <apps-discuss@ietfa.amsl.com>; Wed,  8 Jan 2014 07:37:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level: 
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 tuX2KhX9UHYX for <apps-discuss@ietfa.amsl.com>; Wed,  8 Jan 2014 07:37:52 -0800 (PST)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by ietfa.amsl.com (Postfix) with ESMTP id 2F90A1ADF7D for <apps-discuss@ietf.org>; Wed,  8 Jan 2014 07:37:52 -0800 (PST)
Received: from [10.90.143.216] ([87.253.171.202]) by mrelayeu.kundenserver.de (node=mreu4) with ESMTP (Nemesis) id 0LgjGE-1VeStY3xiw-00oDes; Wed, 08 Jan 2014 16:37:39 +0100
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jan Algermissen <jan.algermissen@nordsc.com>
In-Reply-To: <CAKioOqti423aakGfPXWtMjhYOiQ5M_LUYaXfmkfihxLt0JBZbQ@mail.gmail.com>
Date: Wed, 8 Jan 2014 16:37:38 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <8825D818-4526-471C-8E60-5EC8DD292162@nordsc.com>
References: <A4A8D5B5-73D7-4F4C-968A-D23337DF4FA2@nordsc.com> <CAPW_8m7OP8bG4ExEB6Dk867WJkoTgS5ODkM_-J3v0kr6zfyBuQ@mail.gmail.com> <C8613FAB-B758-44BC-A752-EBAD26D79E7A@nordsc.com> <CAPW_8m5q5hO0QjDiUx9FxU3xhc3b_Kjz3qAwWxQBi2rhJT7nQQ@mail.gmail.com> <CAKioOqti423aakGfPXWtMjhYOiQ5M_LUYaXfmkfihxLt0JBZbQ@mail.gmail.com>
To: darrel@tavis.ca
X-Mailer: Apple Mail (2.1510)
X-Provags-ID: V02:K0:2FhUO1/ifO5LSOGWy32rjVpszHD6u/h5eKzFdTP5G8j QerblK2nrKFcVLlhXxxYNlUTLWFPlcMBC+azoNari+ZckyzlXJ wdKtJKBlD2OF7BNrtTWDkoDVjreA6VJ3pig2CjUhv9GztfT+58 W+X/chgd6o5gD5bqlAp1Dgu//FE2qOFNjZAWUwteoKi2MtVn51 eslBz3cHFgAvFR0WeYyibU/X5A/u852cBn7ihX3mI8AmhLRLSk CkfQOz1inb/BcogjHN1umUz+ozq1ZYgQiG0LRdUQLb13hEHc3y AFP3q0pdAUfQATT25+YXoqdczadBdHdeI4tE6YneNIzFwxeziC cuh86vAumjmPDUxBRomzO0OrSmLtYaidEiDc+N5jWeD66AwSTx 7UMahyWxqt15Q==
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Fwd: Media type for lists of changed URIs?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Jan 2014 15:37:53 -0000

On 08.01.2014, at 16:29, Darrel Miller <darrel.miller@gmail.com> wrote:

> Jan,
>=20
> I'm sure you could shoehorn it into a bigger media type like atom or

Yeah ... that's the big solution[1] (and [2] for the cooler kids), =
including maybe delta-updates. Wanted the less-overhead solution first.

> activity stream, but I haven't seen anything that fits that specific
> need.  I'm not sure I follow your prev-archive scenario.  Do you want
> a user to be able to ask, "what were the last-updated-dates on these
> resources, yesterday, and the day before, etc"?

I want to avoid the situation where the client needs to understand the =
URI structure of the 'update-event' pages, e.g.

/items/changes/2013/01/01/01
/items/changes/2013/01/01/...
/items/changes/2013/01/01/24
/items/changes/2013/02/01/01
/items/changes/2013/02/01/...
/items/changes/2013/02/01/24

Because then I need more spec-parts (URI template vars, for example).

Instead, the client could start with a /changes/current (uncacheable) =
page and then proceed back in time through archived (cacheable) pages.

Jan


Credit where credit belongs:
[1] http://www.infoq.com/presentations/robinson-restful-enterprise
[2] http://roy.gbiv.com/untangled/2008/paper-tigers-and-hidden-dragons

> Darrel
>=20
>>=20
>>> On Jan 8, 2014 9:46 AM, "Jan Algermissen" =
<jan.algermissen@nordsc.com>
>>> wrote:
>>> Hi all,
>>>=20
>>> I am about to work on a media type for transferring lists of URIs of
>>> resource that have changed to an 'observer' of a collection of =
resources.
>>>=20
>>> It just occurred to me that something like that might already exist =
in the
>>> context of cache invalidation protocols.?
>>>=20
>>> Jan
>>>=20
>>>=20
>>> _______________________________________________
>>> apps-discuss mailing list
>>> apps-discuss@ietf.org
>>> https://www.ietf.org/mailman/listinfo/apps-discuss
>>=20
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss


From markus.lanthaler@gmx.net  Wed Jan  8 07:55:56 2014
Return-Path: <markus.lanthaler@gmx.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 055021ADF7F for <apps-discuss@ietfa.amsl.com>; Wed,  8 Jan 2014 07:55:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.438
X-Spam-Level: 
X-Spam-Status: No, score=-1.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, MSGID_MULTIPLE_AT=1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UAf2GNBodgKc for <apps-discuss@ietfa.amsl.com>; Wed,  8 Jan 2014 07:55:55 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 24BCB1ADF58 for <apps-discuss@ietf.org>; Wed,  8 Jan 2014 07:55:55 -0800 (PST)
Received: from Vostro3500 ([2.34.221.135]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MPUlV-1W52D83JFx-004gZ2 for <apps-discuss@ietf.org>; Wed, 08 Jan 2014 16:55:45 +0100
From: "Markus Lanthaler" <markus.lanthaler@gmx.net>
To: "'Jan Algermissen'" <jan.algermissen@nordsc.com>, <darrel@tavis.ca>
References: <A4A8D5B5-73D7-4F4C-968A-D23337DF4FA2@nordsc.com> <CAPW_8m7OP8bG4ExEB6Dk867WJkoTgS5ODkM_-J3v0kr6zfyBuQ@mail.gmail.com> <C8613FAB-B758-44BC-A752-EBAD26D79E7A@nordsc.com> <CAPW_8m5q5hO0QjDiUx9FxU3xhc3b_Kjz3qAwWxQBi2rhJT7nQQ@mail.gmail.com> <CAKioOqti423aakGfPXWtMjhYOiQ5M_LUYaXfmkfihxLt0JBZbQ@mail.gmail.com> <8825D818-4526-471C-8E60-5EC8DD292162@nordsc.com>
In-Reply-To: <8825D818-4526-471C-8E60-5EC8DD292162@nordsc.com>
Date: Wed, 8 Jan 2014 16:55:45 +0100
Message-ID: <01a301cf0c8a$19248e40$4b6daac0$@lanthaler@gmx.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac8Mh5eQxgAfZ47XT8GMcngFFePooQAAWA2g
Content-Language: de
X-Provags-ID: V03:K0:SEpUSUyVaY64BaxXYREpSs04B8a9lDCU2678iZEM+alr3Xw3dek r7rCLwGu0HDahRAuNm1cpnluatAT5S9pY7dSoI8OJiWrcnIlGNrcMdnprJCv3hhRmwukm+7 9iLyOFoBiwbzrUkt4GmfY+2y2uAxj8MZerNRepszFml1kEwerX1zKU7JY5UPayeZt6sY86M h+uB4H9BvPRM+Tou/BkwA==
Cc: 'IETF Apps Discuss' <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Fwd: Media type for lists of changed URIs?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Jan 2014 15:55:56 -0000

On Wednesday, January 08, 2014 4:38 PM, Jan Algermissen wrote:
> I want to avoid the situation where the client needs to understand the
> URI structure of the 'update-event' pages, e.g.
> 
> /items/changes/2013/01/01/01
> /items/changes/2013/01/01/...
> /items/changes/2013/01/01/24
> /items/changes/2013/02/01/01
> /items/changes/2013/02/01/...
> /items/changes/2013/02/01/24

Why do you need the timestamp in the URL *list*? Can't you just iterate
until you find a URL the client already knows? You could also use HTTP's
Last-Modified header to get the timestamp (but that would probably be very
inefficient).


--
Markus Lanthaler
@markuslanthaler


From jan.algermissen@nordsc.com  Wed Jan  8 08:13:28 2014
Return-Path: <jan.algermissen@nordsc.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 236B51AE4F1 for <apps-discuss@ietfa.amsl.com>; Wed,  8 Jan 2014 08:13:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level: 
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 emWcI4r818sR for <apps-discuss@ietfa.amsl.com>; Wed,  8 Jan 2014 08:13:27 -0800 (PST)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by ietfa.amsl.com (Postfix) with ESMTP id DD1D71AE4EE for <apps-discuss@ietf.org>; Wed,  8 Jan 2014 08:13:26 -0800 (PST)
Received: from [10.90.143.216] ([87.253.171.202]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0M4DQN-1VATn82D2Z-00r5bV; Wed, 08 Jan 2014 17:13:13 +0100
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jan Algermissen <jan.algermissen@nordsc.com>
In-Reply-To: <01a301cf0c8a$19248e40$4b6daac0$@lanthaler@gmx.net>
Date: Wed, 8 Jan 2014 17:13:12 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <23A6F68D-FE52-4E50-A10D-931B5A2E4093@nordsc.com>
References: <A4A8D5B5-73D7-4F4C-968A-D23337DF4FA2@nordsc.com> <CAPW_8m7OP8bG4ExEB6Dk867WJkoTgS5ODkM_-J3v0kr6zfyBuQ@mail.gmail.com> <C8613FAB-B758-44BC-A752-EBAD26D79E7A@nordsc.com> <CAPW_8m5q5hO0QjDiUx9FxU3xhc3b_Kjz3qAwWxQBi2rhJT7nQQ@mail.gmail.com> <CAKioOqti423aakGfPXWtMjhYOiQ5M_LUYaXfmkfihxLt0JBZbQ@mail.gmail.com> <8825D818-4526-471C-8E60-5EC8DD292162@nordsc.com> <01a301cf0c8a$19248e40$4b6daac0$@lanthaler@gmx.net>
To: "Markus Lanthaler" <markus.lanthaler@gmx.net>
X-Mailer: Apple Mail (2.1510)
X-Provags-ID: V02:K0:f5GJeOFxS93VCLmrhqtH7VjSj5AJES3SBAY6rUaxY2V /fi4Y5TcMHCoTSEwepNKPbaCc27JWVWaQycVZMoZ9I6P5mLhRQ bDC5asNN/YY5sS9y45aOskUkNGCT+plUG2NmKxmZFSFdyjvAMv B0qg2DwJtCoWw5xq7J7QyBlngq6JQprMkzHvdSLve3xIPSUBeZ FlCAnvfM9tB+I/9YP57O+J1XYMegAgijo14IuPPkLxHA0s2iXp dV7fRFi3TEaaqOVjPC+4sPQeJolIJccxRf5PBgtGuA+hFHDtnE eu6Hrw3o1WI8xnuAVTVl7ZUObodgHpOsmesE0XsYuMClbfVJZA b3h6woAlbSo2KjotZcvggE3A5GChEAj8OwEnmNyeX2iyE6HsPw SUTok6I1xbkvg==
Cc: darrel@tavis.ca, 'IETF Apps Discuss' <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Media type for lists of changed URIs?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Jan 2014 16:13:28 -0000

On 08.01.2014, at 16:55, "Markus Lanthaler" <markus.lanthaler@gmx.net> =
wrote:

> On Wednesday, January 08, 2014 4:38 PM, Jan Algermissen wrote:
>> I want to avoid the situation where the client needs to understand =
the
>> URI structure of the 'update-event' pages, e.g.
>>=20
>> /items/changes/2013/01/01/01
>> /items/changes/2013/01/01/...
>> /items/changes/2013/01/01/24
>> /items/changes/2013/02/01/01
>> /items/changes/2013/02/01/...
>> /items/changes/2013/02/01/24
>=20
> Why do you need the timestamp in the URL *list*? Can't you just =
iterate
> until you find a URL the client already knows?

Resources can be updated anytime, so I might miss something if I just =
look for URIs.
Jan


> You could also use HTTP's
> Last-Modified header to get the timestamp (but that would probably be =
very
> inefficient).
>=20
>=20
> --
> Markus Lanthaler
> @markuslanthaler
>=20


From mark@coactus.com  Wed Jan  8 08:58:17 2014
Return-Path: <mark@coactus.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C0431AE4FD for <apps-discuss@ietfa.amsl.com>; Wed,  8 Jan 2014 08:58:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 I6oW1R5dTRO6 for <apps-discuss@ietfa.amsl.com>; Wed,  8 Jan 2014 08:58:16 -0800 (PST)
Received: from mail-pa0-f47.google.com (mail-pa0-f47.google.com [209.85.220.47]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA211AE4FB for <apps-discuss@ietf.org>; Wed,  8 Jan 2014 08:58:16 -0800 (PST)
Received: by mail-pa0-f47.google.com with SMTP id kq14so2076024pab.6 for <apps-discuss@ietf.org>; Wed, 08 Jan 2014 08:58:07 -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:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=hhki3W2DBiyT4dZIL8oiK2y8SMSvuAGxFMuigcROgKA=; b=cRmiuBROhlv7hgexDPPII2A0cUO7HVYg611wvwBpMsMdPfqTvGRF+Pk0EH0JL4/Y5A cPKYK/mYUEC0crmJO2YbZdyG6KhiBYGzIOzR4tyAuwrWLPlB/liAUVR+Zcv9Wlqfhh7x QnF8ZnNbkcVWpExWYkMZvGWc1Bpk6DcXL9ZkiG59jiKK5PilQscQ7LQFeEJk8KbNH0k3 d8oB7JLXappZwJye6QiPghok83xs8UT0BUqW3SKoeBih4uWTkilKvXvOoj2Eng2cUfoi ZuwYPBD1fNBc/Vz64EVEcuelKd8sAdb2zs7yq2gbPZFCky/rPuZrXvAwzfdrqcuV3ZQT OvvQ==
X-Gm-Message-State: ALoCoQkQp+dAlfIp+vgtxSpc2I3KiFBpXi8qW2xflD/wG/PhVVGqjkxDTC+vNMhuf+Ge5VJBJBy6
MIME-Version: 1.0
X-Received: by 10.66.219.8 with SMTP id pk8mr14102512pac.28.1389200287019; Wed, 08 Jan 2014 08:58:07 -0800 (PST)
Sender: mark@coactus.com
Received: by 10.70.103.177 with HTTP; Wed, 8 Jan 2014 08:58:06 -0800 (PST)
X-Originating-IP: [192.0.216.13]
In-Reply-To: <5DC99287-9CB0-48B6-B237-CFDEAF8BCB8E@nordsc.com>
References: <A4A8D5B5-73D7-4F4C-968A-D23337DF4FA2@nordsc.com> <CAKioOqsz_GPu3LmZjnv6MBWx9ENHEu8nzSDEsN=4WCpZeb_YLg@mail.gmail.com> <CAKioOquabW6RpPoAeheVSL0zOv3K6P-eyBB0FcyHvS6PpJ3-HQ@mail.gmail.com> <5DC99287-9CB0-48B6-B237-CFDEAF8BCB8E@nordsc.com>
Date: Wed, 8 Jan 2014 11:58:06 -0500
X-Google-Sender-Auth: psrlooRLGqnRVsrUWcjWUwrgQAQ
Message-ID: <CALcoZiptwyTEi=Ac0VO3GdcpAL0eF7s91ZVH8S9N0MVrK48weQ@mail.gmail.com>
From: Mark Baker <distobj@acm.org>
To: Jan Algermissen <jan.algermissen@nordsc.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: Darrel Miller <darrel@tavis.ca>, IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Fwd: Media type for lists of changed URIs?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Jan 2014 16:58:17 -0000

On Wed, Jan 8, 2014 at 10:10 AM, Jan Algermissen
<jan.algermissen@nordsc.com> wrote:
> Hence, I'd need something like
>
> timestamp uri
> timestamp uri

I hear text/csv is making a comeback!

http://www.w3.org/2013/csvw/wiki/Main_Page

One could also argue that for a given set of headers, a +csv suffix
might also be appropriate :P

From markus.lanthaler@gmx.net  Wed Jan  8 09:00:38 2014
Return-Path: <markus.lanthaler@gmx.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F81C1ADFF3 for <apps-discuss@ietfa.amsl.com>; Wed,  8 Jan 2014 09:00:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.438
X-Spam-Level: 
X-Spam-Status: No, score=-1.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, MSGID_MULTIPLE_AT=1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EWf5Nsd9cdiT for <apps-discuss@ietfa.amsl.com>; Wed,  8 Jan 2014 09:00:36 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 9A1291ADBD7 for <apps-discuss@ietf.org>; Wed,  8 Jan 2014 09:00:36 -0800 (PST)
Received: from Vostro3500 ([2.34.221.135]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LnPGI-1VTHV93u7a-00hakn for <apps-discuss@ietf.org>; Wed, 08 Jan 2014 18:00:26 +0100
From: "Markus Lanthaler" <markus.lanthaler@gmx.net>
To: "'Jan Algermissen'" <jan.algermissen@nordsc.com>
References: <A4A8D5B5-73D7-4F4C-968A-D23337DF4FA2@nordsc.com> <CAPW_8m7OP8bG4ExEB6Dk867WJkoTgS5ODkM_-J3v0kr6zfyBuQ@mail.gmail.com> <C8613FAB-B758-44BC-A752-EBAD26D79E7A@nordsc.com> <CAPW_8m5q5hO0QjDiUx9FxU3xhc3b_Kjz3qAwWxQBi2rhJT7nQQ@mail.gmail.com> <CAKioOqti423aakGfPXWtMjhYOiQ5M_LUYaXfmkfihxLt0JBZbQ@mail.gmail.com> <8825D818-4526-471C-8E60-5EC8DD292162@nordsc.com> <01a301cf0c8a$19248e40$4b6daac0$@lanthaler@gmx.net> <23A6F68D-FE52-4E50-A10D-931B5A2E4093@nordsc.com>
In-Reply-To: <23A6F68D-FE52-4E50-A10D-931B5A2E4093@nordsc.com>
Date: Wed, 8 Jan 2014 18:00:27 +0100
Message-ID: <01e601cf0c93$21ff2990$65fd7cb0$@lanthaler@gmx.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac8MjItbiaNJe2CcTIeWeDIXAkmp0AABiTeA
Content-Language: de
X-Provags-ID: V03:K0:VYD/OuTIVCPf2dFjHbska1NpOW4yA5FA7FD5gH8ABzwoVbirV5W +YaOwYsvmxvBf7YdNMaQxuyEpBp6jZYO6pjG7MPEOzTMxk2xqBCh+Jb1whiq8s6hvGcGyKz /QLn5oHyqWNy31pQ9fs0VVwnq8Vo38Dm/JP/AqqiX3yRNR83Gw5omwh5OYZj30dd9vr6vQ7 4yjrz572lrlvBQ8QRg+Ng==
Cc: darrel@tavis.ca, 'IETF Apps Discuss' <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Media type for lists of changed URIs?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Jan 2014 17:00:38 -0000

On Wednesday, January 08, 2014 5:13 PM, Jan Algermissen wrote:
> On 08.01.2014, at 16:55, "Markus Lanthaler" wrote:
> 
> > On Wednesday, January 08, 2014 4:38 PM, Jan Algermissen wrote:
> >> I want to avoid the situation where the client needs to understand
> >> the URI structure of the 'update-event' pages, e.g.
> >>
> >> /items/changes/2013/01/01/01
> >> /items/changes/2013/01/01/...
> >> /items/changes/2013/01/01/24
> >> /items/changes/2013/02/01/01
> >> /items/changes/2013/02/01/...
> >> /items/changes/2013/02/01/24
> >
> > Why do you need the timestamp in the URL *list*? Can't you just
> > iterate until you find a URL the client already knows?
> 
> Resources can be updated anytime, so I might miss something if I just
> look for URIs.

Oh I see, I think I misunderstood what you are trying to build... not sure I
got it now but wouldn't sitemaps [1] offer exactly what you need then (apart
from not being a proper media type).


[1] http://www.sitemaps.org/protocol.html


--
Markus Lanthaler
@markuslanthaler



From jan.algermissen@nordsc.com  Wed Jan  8 09:12:09 2014
Return-Path: <jan.algermissen@nordsc.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 300E21AE520 for <apps-discuss@ietfa.amsl.com>; Wed,  8 Jan 2014 09:12:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level: 
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 1iRl99nREymM for <apps-discuss@ietfa.amsl.com>; Wed,  8 Jan 2014 09:12:08 -0800 (PST)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by ietfa.amsl.com (Postfix) with ESMTP id E91A21AE51B for <apps-discuss@ietf.org>; Wed,  8 Jan 2014 09:12:07 -0800 (PST)
Received: from [172.20.10.3] (tmo-108-23.customers.d1-online.com [80.187.108.23]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0M7o3Q-1VEUoF0Rcm-00vkcK; Wed, 08 Jan 2014 18:11:54 +0100
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jan Algermissen <jan.algermissen@nordsc.com>
In-Reply-To: <CALcoZiptwyTEi=Ac0VO3GdcpAL0eF7s91ZVH8S9N0MVrK48weQ@mail.gmail.com>
Date: Wed, 8 Jan 2014 18:11:30 +0100
Content-Transfer-Encoding: 7bit
Message-Id: <52E919AA-2B7D-4B03-A47D-F9FF11D58BDF@nordsc.com>
References: <A4A8D5B5-73D7-4F4C-968A-D23337DF4FA2@nordsc.com> <CAKioOqsz_GPu3LmZjnv6MBWx9ENHEu8nzSDEsN=4WCpZeb_YLg@mail.gmail.com> <CAKioOquabW6RpPoAeheVSL0zOv3K6P-eyBB0FcyHvS6PpJ3-HQ@mail.gmail.com> <5DC99287-9CB0-48B6-B237-CFDEAF8BCB8E@nordsc.com> <CALcoZiptwyTEi=Ac0VO3GdcpAL0eF7s91ZVH8S9N0MVrK48weQ@mail.gmail.com>
To: Mark Baker <distobj@acm.org>
X-Mailer: Apple Mail (2.1510)
X-Provags-ID: V02:K0:/aP9nK24CRjdxhqtMAIzb2bW583YhKHHcjHpmZeZXAi brs8uh4gQTpO8m8dRpp/4v0KcKqookhO+aaK3GJp/Hl6ep+pdw lR7C/c08qwssQv9L8zJoJ0HSoQSCrL0zxJnKyAz8vnRHkxgAMC rNbBE0mFHwd6I42a0SUBCbzCYnwUala/pwrEAaTNoZgSPRJOEi Qarv4mGerBiiWNlocODbGjT0dvdVxsv2iCqaLJ6fATvCoaP49Z S37Wgix0sLQr4zfFcsWqS+YCfSJiS040VCgWYFG4jPOuo+4Nu6 GGXDVTExEsubOgRcZpZQd0D4R1i+xhKIvSps013vjecJ+8MHyE upOOh6ZmQhGKXFNpDpZ1TOZ7xP5C6x9gHOetqMJ94c/KbbLxMY PMpsN5Ai8ZCuA==
Cc: Darrel Miller <darrel@tavis.ca>, IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Fwd: Media type for lists of changed URIs?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Jan 2014 17:12:09 -0000

On 08.01.2014, at 17:58, Mark Baker <distobj@acm.org> wrote:

> On Wed, Jan 8, 2014 at 10:10 AM, Jan Algermissen
> <jan.algermissen@nordsc.com> wrote:
>> Hence, I'd need something like
>> 
>> timestamp uri
>> timestamp uri
> 
> I hear text/csv is making a comeback!

Great! Love CSV

> 
> http://www.w3.org/2013/csvw/wiki/Main_Page
> 
> One could also argue that for a given set of headers, a +csv suffix
> might also be appropriate :P

Definitely ... makes for better extensibility rules.

Thanks.

Jan



From jan.algermissen@nordsc.com  Wed Jan  8 09:13:51 2014
Return-Path: <jan.algermissen@nordsc.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B08A81ADFF8 for <apps-discuss@ietfa.amsl.com>; Wed,  8 Jan 2014 09:13:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level: 
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 zv3YY7L0C_UG for <apps-discuss@ietfa.amsl.com>; Wed,  8 Jan 2014 09:13:50 -0800 (PST)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by ietfa.amsl.com (Postfix) with ESMTP id 4D8521AE058 for <apps-discuss@ietf.org>; Wed,  8 Jan 2014 09:13:50 -0800 (PST)
Received: from [172.20.10.3] (tmo-108-23.customers.d1-online.com [80.187.108.23]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0MTePA-1VsFWz2iBM-00QgtA; Wed, 08 Jan 2014 18:13:37 +0100
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jan Algermissen <jan.algermissen@nordsc.com>
In-Reply-To: <01e601cf0c93$21ff2990$65fd7cb0$@lanthaler@gmx.net>
Date: Wed, 8 Jan 2014 18:12:56 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <8599BCFA-A367-4680-9589-8DF3F5CB9A3B@nordsc.com>
References: <A4A8D5B5-73D7-4F4C-968A-D23337DF4FA2@nordsc.com> <CAPW_8m7OP8bG4ExEB6Dk867WJkoTgS5ODkM_-J3v0kr6zfyBuQ@mail.gmail.com> <C8613FAB-B758-44BC-A752-EBAD26D79E7A@nordsc.com> <CAPW_8m5q5hO0QjDiUx9FxU3xhc3b_Kjz3qAwWxQBi2rhJT7nQQ@mail.gmail.com> <CAKioOqti423aakGfPXWtMjhYOiQ5M_LUYaXfmkfihxLt0JBZbQ@mail.gmail.com> <8825D818-4526-471C-8E60-5EC8DD292162@nordsc.com> <01a301cf0c8a$19248e40$4b6daac0$@lanthaler@gmx.net> <23A6F68D-FE52-4E50-A10D-931B5A2E4093@nordsc.com> <01e601cf0c93$21ff2990$65fd7cb0$@lanthaler@gmx.net>
To: "Markus Lanthaler" <markus.lanthaler@gmx.net>
X-Mailer: Apple Mail (2.1510)
X-Provags-ID: V02:K0:gP+j5ag9lwSj50i6Mh1kLIyvoZKsH3PvfNnfbqwP8RO cD5T3I+KUXcG3N/iAJL27MvcxSRGSd+PGXY+/FcqwP+Z9nPQbX phvboedrWaigkXYlCUan1HRTHmoNtGDz55h9615GxcxFSMZZdV 0bsVICOn/lzpQB6G51Bie/EyD+N8ol1NJsj+F3UFlv3Gv5l4Io 2CPauQGV3TCazAGF4kI6ChH4Qhygus0+YjTJNK1jO7kl0N5ROn WtIFZ0251GU6nLbcadHrKn8mhXSHZhgD1Y7eb5TARUvDRdDz8E TFAakPM5L0rbzKJHY/tL42cjGvVElWW/grni5nU4XbjSvWnNfq i2tHiHmgOTphCV7ukXANBAXG2Do4uqp1rftNtDMKR4LB+CuvzG b3IatTlua5ilw==
Cc: darrel@tavis.ca, 'IETF Apps Discuss' <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Media type for lists of changed URIs?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Jan 2014 17:13:51 -0000

On 08.01.2014, at 18:00, "Markus Lanthaler" <markus.lanthaler@gmx.net> =
wrote:

> On Wednesday, January 08, 2014 5:13 PM, Jan Algermissen wrote:
>> On 08.01.2014, at 16:55, "Markus Lanthaler" wrote:
>>=20
>>> On Wednesday, January 08, 2014 4:38 PM, Jan Algermissen wrote:
>>>> I want to avoid the situation where the client needs to understand
>>>> the URI structure of the 'update-event' pages, e.g.
>>>>=20
>>>> /items/changes/2013/01/01/01
>>>> /items/changes/2013/01/01/...
>>>> /items/changes/2013/01/01/24
>>>> /items/changes/2013/02/01/01
>>>> /items/changes/2013/02/01/...
>>>> /items/changes/2013/02/01/24
>>>=20
>>> Why do you need the timestamp in the URL *list*? Can't you just
>>> iterate until you find a URL the client already knows?
>>=20
>> Resources can be updated anytime, so I might miss something if I just
>> look for URIs.
>=20
> Oh I see, I think I misunderstood what you are trying to build... not =
sure I
> got it now but wouldn't sitemaps [1] offer exactly what you need then =
(apart
> from not being a proper media type).
>=20

Good point, thanks. Bit chatty, though.

Jan


>=20
> [1] http://www.sitemaps.org/protocol.html

>=20
>=20
> --
> Markus Lanthaler
> @markuslanthaler
>=20
>=20


From masinter@adobe.com  Wed Jan  8 17:15:39 2014
Return-Path: <masinter@adobe.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C499F1AD8F4 for <apps-discuss@ietfa.amsl.com>; Wed,  8 Jan 2014 17:15:39 -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,  HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1lRflSAUzcXU for <apps-discuss@ietfa.amsl.com>; Wed,  8 Jan 2014 17:15:36 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0243.outbound.protection.outlook.com [207.46.163.243]) by ietfa.amsl.com (Postfix) with ESMTP id 8C08F1AD8EE for <apps-discuss@ietf.org>; Wed,  8 Jan 2014 17:15:36 -0800 (PST)
Received: from BL2PR02MB307.namprd02.prod.outlook.com (10.141.91.21) by BL2PR02MB308.namprd02.prod.outlook.com (10.141.91.24) with Microsoft SMTP Server (TLS) id 15.0.842.7; Thu, 9 Jan 2014 01:15:25 +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; Thu, 9 Jan 2014 01:15:25 +0000
From: Larry Masinter <masinter@adobe.com>
To: mike amundsen <mamund@yahoo.com>, IETF Apps Discuss <apps-discuss@ietf.org>
Thread-Topic: [apps-discuss] Fwd:  Media type for lists of changed URIs?
Thread-Index: AQHPDIU7VmyzFZQc9E6/31xZv/o3Xpp7lqKg
Date: Thu, 9 Jan 2014 01:15:25 +0000
Message-ID: <d19ed0e39f2d4c9ab8cb395b6faa1078@BL2PR02MB307.namprd02.prod.outlook.com>
References: <A4A8D5B5-73D7-4F4C-968A-D23337DF4FA2@nordsc.com> <CAPW_8m7OP8bG4ExEB6Dk867WJkoTgS5ODkM_-J3v0kr6zfyBuQ@mail.gmail.com> <C8613FAB-B758-44BC-A752-EBAD26D79E7A@nordsc.com> <CAPW_8m5q5hO0QjDiUx9FxU3xhc3b_Kjz3qAwWxQBi2rhJT7nQQ@mail.gmail.com>
In-Reply-To: <CAPW_8m5q5hO0QjDiUx9FxU3xhc3b_Kjz3qAwWxQBi2rhJT7nQQ@mail.gmail.com>
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: 008663486A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(53754006)(2473001)(377454003)(51704005)(189002)(24454002)(22974006)(199002)(46102001)(19609705001)(53806001)(74662001)(47736001)(50986001)(74502001)(90146001)(76482001)(54356001)(74316001)(2656002)(81342001)(16236675002)(31966008)(69226001)(51856001)(92566001)(47446002)(49866001)(79102001)(47976001)(56816005)(15202345003)(74366001)(85306002)(81542001)(33646001)(76786001)(16601075003)(76796001)(87266001)(81816001)(74706001)(4396001)(15975445006)(80022001)(85852003)(65816001)(19300405004)(19580395003)(66066001)(59766001)(19580405001)(15395725003)(83322001)(81686001)(80976001)(74876001)(76576001)(63696002)(87936001)(77982001)(54316002)(56776001)(83072002)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR02MB308; 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_d19ed0e39f2d4c9ab8cb395b6faa1078BL2PR02MB307namprd02pro_"
MIME-Version: 1.0
X-OriginatorOrg: adobe.com
Subject: Re: [apps-discuss] Fwd:  Media type for lists of changed URIs?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Jan 2014 01:15:40 -0000

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

It sounds like this is an application that needs some extensibility, and yo=
u would be better off with

application/json

since the content doesn't really appear in a context where having a more sp=
ecific media type is useful.

Larry
--
http://larry.masinter.net

From: apps-discuss [mailto:apps-discuss-bounces@ietf.org] On Behalf Of mike=
 amundsen
Sent: Wednesday, January 08, 2014 7:20 AM
To: IETF Apps Discuss
Subject: [apps-discuss] Fwd: Media type for lists of changed URIs?

timestamp thing is a wrinkle.

maybe Atom w/ tombstones?
http://tools.ietf.org/html/rfc6721

mamund
+1.859.757.1449
skype: mca.amundsen
http://amundsen.com/blog/
http://twitter.com/mamund
https://github.com/mamund
http://linkedin.com/in/mamund

---------- Forwarded message ----------
From: Jan Algermissen <jan.algermissen@nordsc.com<mailto:jan.algermissen@no=
rdsc.com>>
Date: Wed, Jan 8, 2014 at 9:57 AM
Subject: Re: [apps-discuss] Media type for lists of changed URIs?
To: mike amundsen <mamund@yahoo.com<mailto:mamund@yahoo.com>>



On 08.01.2014, at 15:55, mike amundsen <mamund@yahoo.com<mailto:mamund@yaho=
o.com>> wrote:

> text/uri-list ?

[Same reply as to Darrel :-)] for you:

Yes, exactly where I am at.

However, I'd like to remove the burdon of timing issues from the "protocol"=
 and instead use linked paged (rel=3Dprev-archive) for clients to process b=
ackwards until their last remembered timestamp.

Hence, I'd need something like

timestamp uri
timestamp uri

and this is where I wrote the last email :-)

Jan







> On Jan 8, 2014 9:46 AM, "Jan Algermissen" <jan.algermissen@nordsc.com<mai=
lto:jan.algermissen@nordsc.com>> wrote:
> Hi all,
>
> I am about to work on a media type for transferring lists of URIs of reso=
urce that have changed to an 'observer' of a collection of resources.
>
> It just occurred to me that something like that might already exist in th=
e context of cache invalidation protocols.?
>
> Jan
>
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org<mailto:apps-discuss@ietf.org>
> https://www.ietf.org/mailman/listinfo/apps-discuss


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

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri","sans-serif";}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">It sounds like this is an=
 application that needs some extensibility, and you would be better off wit=
h<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">application/json
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">since the content doesn&#=
8217;t really appear in a context where having a more specific media type i=
s useful.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Larry<o:p></o:p></span></=
p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">--<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">http://larry.masinter.net=
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:&quot=
;Calibri&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-=
size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;"> apps-d=
iscuss [mailto:apps-discuss-bounces@ietf.org]
<b>On Behalf Of </b>mike amundsen<br>
<b>Sent:</b> Wednesday, January 08, 2014 7:20 AM<br>
<b>To:</b> IETF Apps Discuss<br>
<b>Subject:</b> [apps-discuss] Fwd: Media type for lists of changed URIs?<o=
:p></o:p></span></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<div>
<p class=3D"MsoNormal">timestamp thing is a wrinkle.<o:p></o:p></p>
<div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class=3D"MsoNormal">maybe Atom w/ tombstones?<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><a href=3D"http://tools.ietf.org/html/rfc6721">http:=
//tools.ietf.org/html/rfc6721</a><br clear=3D"all">
<o:p></o:p></p>
<div>
<div>
<div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<p class=3D"MsoNormal">mamund<o:p></o:p></p>
<div>
<p class=3D"MsoNormal">&#43;1.859.757.1449<br>
skype: mca.amundsen<br>
<a href=3D"http://amundsen.com/blog/" target=3D"_blank">http://amundsen.com=
/blog/</a><br>
<a href=3D"http://twitter.com/mamund" target=3D"_blank">http://twitter.com/=
mamund</a><br>
<a href=3D"https://github.com/mamund" target=3D"_blank">https://github.com/=
mamund</a><br>
<a href=3D"http://linkedin.com/in/mamund" target=3D"_blank">http://linkedin=
.com/in/mamund</a><o:p></o:p></p>
</div>
</div>
</div>
<p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><o:p>&nbsp;</o:p></p>
<div>
<p class=3D"MsoNormal">---------- Forwarded message ----------<br>
From: <b>Jan Algermissen</b> &lt;<a href=3D"mailto:jan.algermissen@nordsc.c=
om">jan.algermissen@nordsc.com</a>&gt;<br>
Date: Wed, Jan 8, 2014 at 9:57 AM<br>
Subject: Re: [apps-discuss] Media type for lists of changed URIs?<br>
To: mike amundsen &lt;<a href=3D"mailto:mamund@yahoo.com">mamund@yahoo.com<=
/a>&gt;<br>
<br>
<br>
<br>
On 08.01.2014, at 15:55, mike amundsen &lt;<a href=3D"mailto:mamund@yahoo.c=
om">mamund@yahoo.com</a>&gt; wrote:<br>
<br>
&gt; text/uri-list ?<br>
<br>
[Same reply as to Darrel :-)] for you:<br>
<br>
Yes, exactly where I am at.<br>
<br>
However, I'd like to remove the burdon of timing issues from the &quot;prot=
ocol&quot; and instead use linked paged (rel=3Dprev-archive) for clients to=
 process backwards until their last remembered timestamp.<br>
<br>
Hence, I'd need something like<br>
<br>
timestamp uri<br>
timestamp uri<br>
<br>
and this is where I wrote the last email :-)<br>
<span style=3D"color:#888888"><br>
Jan</span><o:p></o:p></p>
<div>
<div>
<p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br>
<br>
<br>
<br>
<br>
<br>
<br>
&gt; On Jan 8, 2014 9:46 AM, &quot;Jan Algermissen&quot; &lt;<a href=3D"mai=
lto:jan.algermissen@nordsc.com">jan.algermissen@nordsc.com</a>&gt; wrote:<b=
r>
&gt; Hi all,<br>
&gt;<br>
&gt; I am about to work on a media type for transferring lists of URIs of r=
esource that have changed to an 'observer' of a collection of resources.<br=
>
&gt;<br>
&gt; It just occurred to me that something like that might already exist in=
 the context of cache invalidation protocols.?<br>
&gt;<br>
&gt; Jan<br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; apps-discuss mailing list<br>
&gt; <a href=3D"mailto:apps-discuss@ietf.org">apps-discuss@ietf.org</a><br>
&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/apps-discuss" target=
=3D"_blank">https://www.ietf.org/mailman/listinfo/apps-discuss</a><o:p></o:=
p></p>
</div>
</div>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
</div>
</div>
</body>
</html>

--_000_d19ed0e39f2d4c9ab8cb395b6faa1078BL2PR02MB307namprd02pro_--

From tbray@textuality.com  Wed Jan  8 17:21:21 2014
Return-Path: <tbray@textuality.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 356921ADF71 for <apps-discuss@ietfa.amsl.com>; Wed,  8 Jan 2014 17:21:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.078
X-Spam-Level: *
X-Spam-Status: No, score=1.078 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, J_CHICKENPOX_38=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 zt4-jHb8hYIe for <apps-discuss@ietfa.amsl.com>; Wed,  8 Jan 2014 17:21:19 -0800 (PST)
Received: from mail-la0-f48.google.com (mail-la0-f48.google.com [209.85.215.48]) by ietfa.amsl.com (Postfix) with ESMTP id 372771ADF75 for <apps-discuss@ietf.org>; Wed,  8 Jan 2014 17:21:17 -0800 (PST)
Received: by mail-la0-f48.google.com with SMTP id n7so1712120lam.35 for <apps-discuss@ietf.org>; Wed, 08 Jan 2014 17:21:07 -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=Z4qTX46ioOQ42BXa5kdyaaMbLI3gb+RuHqBCRFu1qgo=; b=eG8MsKvlsMBebCYUszZRtnZWsLmmeGSSAktgOnrC6egUPV4dho1pCfXZ30lOfEO+bs Npslvbj333nOo23UUmGrypvUvCXB9k8nco/oizl64L3V3qgmuIzgWCIb4FfVqzRecXXA aHdaws45mErm5dAcGjHqDx4S1UElSyKB9MVr4vFuW1QpJY7/DDx0BY4UZxistfjz+Lsn ID8v7kSruSDi8M84taFngITMC3qVyNoS7CIm2r+PlhE+0OcvS1hrJHQdRzeMglaiKxd4 5Br+geYSJKI0LJs+T1uLVSy91RyYMDLrG9J9dZocZxtpbuY6Gei7wzTaJqkcBg9n5koN N7nQ==
X-Gm-Message-State: ALoCoQkPp3LotEiM1P2Rb+Mgtbwl15kmxjmQG12loZRYzLRuOgz9DgzBoLzSixa4J34pQrs1owYn
MIME-Version: 1.0
X-Received: by 10.112.219.170 with SMTP id pp10mr81230lbc.29.1389230467014; Wed, 08 Jan 2014 17:21:07 -0800 (PST)
Received: by 10.114.24.6 with HTTP; Wed, 8 Jan 2014 17:21:06 -0800 (PST)
X-Originating-IP: [96.49.81.176]
In-Reply-To: <d19ed0e39f2d4c9ab8cb395b6faa1078@BL2PR02MB307.namprd02.prod.outlook.com>
References: <A4A8D5B5-73D7-4F4C-968A-D23337DF4FA2@nordsc.com> <CAPW_8m7OP8bG4ExEB6Dk867WJkoTgS5ODkM_-J3v0kr6zfyBuQ@mail.gmail.com> <C8613FAB-B758-44BC-A752-EBAD26D79E7A@nordsc.com> <CAPW_8m5q5hO0QjDiUx9FxU3xhc3b_Kjz3qAwWxQBi2rhJT7nQQ@mail.gmail.com> <d19ed0e39f2d4c9ab8cb395b6faa1078@BL2PR02MB307.namprd02.prod.outlook.com>
Date: Wed, 8 Jan 2014 17:21:06 -0800
Message-ID: <CAHBU6ivCBSrXME6OuHjwuLk8jO035WHpwbw6D0-Zk7s_yEDYhg@mail.gmail.com>
From: Tim Bray <tbray@textuality.com>
To: Larry Masinter <masinter@adobe.com>
Content-Type: multipart/alternative; boundary=001a11c259927f6a6f04ef7f6cd3
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Fwd: Media type for lists of changed URIs?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Jan 2014 01:21:21 -0000

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

What Larry said, I=E2=80=99d do this in JSON and invest my efforts in the
application semantics.


On Wed, Jan 8, 2014 at 5:15 PM, Larry Masinter <masinter@adobe.com> wrote:

>  It sounds like this is an application that needs some extensibility, and
> you would be better off with
>
>
>
> application/json
>
>
>
> since the content doesn=E2=80=99t really appear in a context where having=
 a more
> specific media type is useful.
>
>
>
> Larry
>
> --
>
> http://larry.masinter.net
>
>
>
> *From:* apps-discuss [mailto:apps-discuss-bounces@ietf.org] *On Behalf Of
> *mike amundsen
> *Sent:* Wednesday, January 08, 2014 7:20 AM
> *To:* IETF Apps Discuss
> *Subject:* [apps-discuss] Fwd: Media type for lists of changed URIs?
>
>
>
> timestamp thing is a wrinkle.
>
>
>
> maybe Atom w/ tombstones?
>
> http://tools.ietf.org/html/rfc6721
>
>
>
> mamund
>
> +1.859.757.1449
> skype: mca.amundsen
> http://amundsen.com/blog/
> http://twitter.com/mamund
> https://github.com/mamund
> http://linkedin.com/in/mamund
>
>
>
> ---------- Forwarded message ----------
> From: *Jan Algermissen* <jan.algermissen@nordsc.com>
> Date: Wed, Jan 8, 2014 at 9:57 AM
> Subject: Re: [apps-discuss] Media type for lists of changed URIs?
> To: mike amundsen <mamund@yahoo.com>
>
>
>
> On 08.01.2014, at 15:55, mike amundsen <mamund@yahoo.com> wrote:
>
> > text/uri-list ?
>
> [Same reply as to Darrel :-)] for you:
>
> Yes, exactly where I am at.
>
> However, I'd like to remove the burdon of timing issues from the
> "protocol" and instead use linked paged (rel=3Dprev-archive) for clients =
to
> process backwards until their last remembered timestamp.
>
> Hence, I'd need something like
>
> timestamp uri
> timestamp uri
>
> and this is where I wrote the last email :-)
>
> Jan
>
>
>
>
>
>
>
>
> > On Jan 8, 2014 9:46 AM, "Jan Algermissen" <jan.algermissen@nordsc.com>
> wrote:
> > Hi all,
> >
> > I am about to work on a media type for transferring lists of URIs of
> resource that have changed to an 'observer' of a collection of resources.
> >
> > It just occurred to me that something like that might already exist in
> the context of cache invalidation protocols.?
> >
> > Jan
> >
> >
> > _______________________________________________
> > 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
>
>

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

<div dir=3D"ltr">What Larry said, I=E2=80=99d do this in JSON and invest my=
 efforts in the application semantics.</div><div class=3D"gmail_extra"><br>=
<br><div class=3D"gmail_quote">On Wed, Jan 8, 2014 at 5:15 PM, Larry Masint=
er <span dir=3D"ltr">&lt;<a href=3D"mailto:masinter@adobe.com" target=3D"_b=
lank">masinter@adobe.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">





<div lang=3D"EN-US" link=3D"blue" vlink=3D"purple">
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d">It sounds like this is an=
 application that needs some extensibility, and you would be better off wit=
h<u></u><u></u></span></p>

<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=C2=A0<u></u></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d">application/json
<u></u><u></u></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=C2=A0<u></u></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d">since the content doesn=
=E2=80=99t really appear in a context where having a more specific media ty=
pe is useful.<u></u><u></u></span></p>

<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=C2=A0<u></u></spa=
n></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Larry<u></u><u></u></span=
></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d">--<u></u><u></u></span></=
p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><a href=3D"http://larry.m=
asinter.net" target=3D"_blank">http://larry.masinter.net</a><u></u><u></u><=
/span></p>

<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=C2=A0<u></u></spa=
n></p>
<p class=3D"MsoNormal"><b><span style=3D"font-size:11.0pt;font-family:&quot=
;Calibri&quot;,&quot;sans-serif&quot;">From:</span></b><span style=3D"font-=
size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;"> apps-d=
iscuss [mailto:<a href=3D"mailto:apps-discuss-bounces@ietf.org" target=3D"_=
blank">apps-discuss-bounces@ietf.org</a>]
<b>On Behalf Of </b>mike amundsen<br>
<b>Sent:</b> Wednesday, January 08, 2014 7:20 AM<br>
<b>To:</b> IETF Apps Discuss<br>
<b>Subject:</b> [apps-discuss] Fwd: Media type for lists of changed URIs?<u=
></u><u></u></span></p>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
<div>
<p class=3D"MsoNormal">timestamp thing is a wrinkle.<u></u><u></u></p>
<div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
<div>
<p class=3D"MsoNormal">maybe Atom w/ tombstones?<u></u><u></u></p>
</div>
<div>
<p class=3D"MsoNormal"><a href=3D"http://tools.ietf.org/html/rfc6721" targe=
t=3D"_blank">http://tools.ietf.org/html/rfc6721</a><br clear=3D"all">
<u></u><u></u></p>
<div>
<div>
<div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
<p class=3D"MsoNormal">mamund<u></u><u></u></p>
<div>
<p class=3D"MsoNormal"><a href=3D"tel:%2B1.859.757.1449" value=3D"+18597571=
449" target=3D"_blank">+1.859.757.1449</a><br>
skype: mca.amundsen<br>
<a href=3D"http://amundsen.com/blog/" target=3D"_blank">http://amundsen.com=
/blog/</a><br>
<a href=3D"http://twitter.com/mamund" target=3D"_blank">http://twitter.com/=
mamund</a><br>
<a href=3D"https://github.com/mamund" target=3D"_blank">https://github.com/=
mamund</a><br>
<a href=3D"http://linkedin.com/in/mamund" target=3D"_blank">http://linkedin=
.com/in/mamund</a><u></u><u></u></p>
</div>
</div>
</div>
<p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><u></u>=C2=A0<u></u><=
/p>
<div>
<p class=3D"MsoNormal">---------- Forwarded message ----------<br>
From: <b>Jan Algermissen</b> &lt;<a href=3D"mailto:jan.algermissen@nordsc.c=
om" target=3D"_blank">jan.algermissen@nordsc.com</a>&gt;<br>
Date: Wed, Jan 8, 2014 at 9:57 AM<br>
Subject: Re: [apps-discuss] Media type for lists of changed URIs?<br>
To: mike amundsen &lt;<a href=3D"mailto:mamund@yahoo.com" target=3D"_blank"=
>mamund@yahoo.com</a>&gt;<br>
<br>
<br>
<br>
On 08.01.2014, at 15:55, mike amundsen &lt;<a href=3D"mailto:mamund@yahoo.c=
om" target=3D"_blank">mamund@yahoo.com</a>&gt; wrote:<br>
<br>
&gt; text/uri-list ?<br>
<br>
[Same reply as to Darrel :-)] for you:<br>
<br>
Yes, exactly where I am at.<br>
<br>
However, I&#39;d like to remove the burdon of timing issues from the &quot;=
protocol&quot; and instead use linked paged (rel=3Dprev-archive) for client=
s to process backwards until their last remembered timestamp.<br>
<br>
Hence, I&#39;d need something like<br>
<br>
timestamp uri<br>
timestamp uri<br>
<br>
and this is where I wrote the last email :-)<br>
<span style=3D"color:#888888"><br>
Jan</span><u></u><u></u></p>
<div>
<div>
<p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><br>
<br>
<br>
<br>
<br>
<br>
<br>
&gt; On Jan 8, 2014 9:46 AM, &quot;Jan Algermissen&quot; &lt;<a href=3D"mai=
lto:jan.algermissen@nordsc.com" target=3D"_blank">jan.algermissen@nordsc.co=
m</a>&gt; wrote:<br>
&gt; Hi all,<br>
&gt;<br>
&gt; I am about to work on a media type for transferring lists of URIs of r=
esource that have changed to an &#39;observer&#39; of a collection of resou=
rces.<br>
&gt;<br>
&gt; It just occurred to me that something like that might already exist in=
 the context of cache invalidation protocols.?<br>
&gt;<br>
&gt; Jan<br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; apps-discuss mailing list<br>
&gt; <a href=3D"mailto:apps-discuss@ietf.org" target=3D"_blank">apps-discus=
s@ietf.org</a><br>
&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/apps-discuss" target=
=3D"_blank">https://www.ietf.org/mailman/listinfo/apps-discuss</a><u></u><u=
></u></p>
</div>
</div>
</div>
<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p>
</div>
</div>
</div>
</div>

<br>_______________________________________________<br>
apps-discuss mailing list<br>
<a href=3D"mailto:apps-discuss@ietf.org">apps-discuss@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/apps-discuss" target=3D"_b=
lank">https://www.ietf.org/mailman/listinfo/apps-discuss</a><br>
<br></blockquote></div><br></div>

--001a11c259927f6a6f04ef7f6cd3--

From jan.algermissen@nordsc.com  Wed Jan  8 17:24:28 2014
Return-Path: <jan.algermissen@nordsc.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF6481ADF0E for <apps-discuss@ietfa.amsl.com>; Wed,  8 Jan 2014 17:24:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.504
X-Spam-Level: *
X-Spam-Status: No, score=1.504 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADOBE2=2.455, HELO_EQ_DE=0.35, J_CHICKENPOX_38=0.6, 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 nQqz2mqHbErT for <apps-discuss@ietfa.amsl.com>; Wed,  8 Jan 2014 17:24:26 -0800 (PST)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by ietfa.amsl.com (Postfix) with ESMTP id 9E1ED1ADF5B for <apps-discuss@ietf.org>; Wed,  8 Jan 2014 17:24:26 -0800 (PST)
Received: from [192.168.2.103] (p548FAE9A.dip0.t-ipconnect.de [84.143.174.154]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0MK3ZF-1VzhRU1qPl-00241M; Thu, 09 Jan 2014 02:24:09 +0100
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jan Algermissen <jan.algermissen@nordsc.com>
In-Reply-To: <CAHBU6ivCBSrXME6OuHjwuLk8jO035WHpwbw6D0-Zk7s_yEDYhg@mail.gmail.com>
Date: Thu, 9 Jan 2014 02:24:08 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <1D9FD392-BC56-46A0-927E-94EE3BCC2C6A@nordsc.com>
References: <A4A8D5B5-73D7-4F4C-968A-D23337DF4FA2@nordsc.com> <CAPW_8m7OP8bG4ExEB6Dk867WJkoTgS5ODkM_-J3v0kr6zfyBuQ@mail.gmail.com> <C8613FAB-B758-44BC-A752-EBAD26D79E7A@nordsc.com> <CAPW_8m5q5hO0QjDiUx9FxU3xhc3b_Kjz3qAwWxQBi2rhJT7nQQ@mail.gmail.com> <d19ed0e39f2d4c9ab8cb395b6faa1078@BL2PR02MB307.namprd02.prod.outlook.com> <CAHBU6ivCBSrXME6OuHjwuLk8jO035WHpwbw6D0-Zk7s_yEDYhg@mail.gmail.com>
To: Tim Bray <tbray@textuality.com>
X-Mailer: Apple Mail (2.1510)
X-Provags-ID: V02:K0:ZHu39pimymRfTpP3fzOBiYIcfMVNkSALh7Fua3rDOdm jT8tq678Asi1BHeIID2icBnnjllXyf5iEKugT1L9Ndhpfk4Ef0 55Xt6xtO/ufXkIj9PctQTz88/fvm1AjlFGNSEx5Fz447RkLTNn IEpy1/oMmsArlHWT27dYTyzKf2GHEK+Rr6s9/gcbtiRtgxKKWi XUEcQNoSeSi02z6MyjSFHwN1JKNQXGN1J31P5N8XXRlBmXqrqI rZCuaQz6PG7DyzVLMwPXnLzmHqdt+VwaC+NoYOQTYSfKA+/WFu zyD+rGVqxMGKqdaLdCi3j8CyNeqrwbJyHo+md28omofEGMTT1O g53yqeSv4uroc+WqpsNDPpBW2pLUcDkovGTXEp4f9OLwOeBrSh guKwy9VcDDPTw==
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Fwd: Media type for lists of changed URIs?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Jan 2014 01:24:28 -0000

On 09.01.2014, at 02:21, Tim Bray <tbray@textuality.com> wrote:

> What Larry said, I=92d do this in JSON and invest my efforts in the =
application semantics.

Interesting - where in REST do you put application semantics if not in =
the media type?

Jan

>=20
>=20
> On Wed, Jan 8, 2014 at 5:15 PM, Larry Masinter <masinter@adobe.com> =
wrote:
> It sounds like this is an application that needs some extensibility, =
and you would be better off with
>=20
> =20
>=20
> application/json
>=20
> =20
>=20
> since the content doesn=92t really appear in a context where having a =
more specific media type is useful.
>=20
> =20
>=20
> Larry
>=20
> --
>=20
> http://larry.masinter.net
>=20
> =20
>=20
> From: apps-discuss [mailto:apps-discuss-bounces@ietf.org] On Behalf Of =
mike amundsen
> Sent: Wednesday, January 08, 2014 7:20 AM
> To: IETF Apps Discuss
> Subject: [apps-discuss] Fwd: Media type for lists of changed URIs?
>=20
> =20
>=20
> timestamp thing is a wrinkle.
>=20
> =20
>=20
> maybe Atom w/ tombstones?
>=20
> http://tools.ietf.org/html/rfc6721
>=20
> =20
>=20
> mamund
>=20
> +1.859.757.1449
> skype: mca.amundsen
> http://amundsen.com/blog/
> http://twitter.com/mamund
> https://github.com/mamund
> http://linkedin.com/in/mamund
>=20
> =20
>=20
> ---------- Forwarded message ----------
> From: Jan Algermissen <jan.algermissen@nordsc.com>
> Date: Wed, Jan 8, 2014 at 9:57 AM
> Subject: Re: [apps-discuss] Media type for lists of changed URIs?
> To: mike amundsen <mamund@yahoo.com>
>=20
>=20
>=20
> On 08.01.2014, at 15:55, mike amundsen <mamund@yahoo.com> wrote:
>=20
> > text/uri-list ?
>=20
> [Same reply as to Darrel :-)] for you:
>=20
> Yes, exactly where I am at.
>=20
> However, I'd like to remove the burdon of timing issues from the =
"protocol" and instead use linked paged (rel=3Dprev-archive) for clients =
to process backwards until their last remembered timestamp.
>=20
> Hence, I'd need something like
>=20
> timestamp uri
> timestamp uri
>=20
> and this is where I wrote the last email :-)
>=20
> Jan
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> > On Jan 8, 2014 9:46 AM, "Jan Algermissen" =
<jan.algermissen@nordsc.com> wrote:
> > Hi all,
> >
> > I am about to work on a media type for transferring lists of URIs of =
resource that have changed to an 'observer' of a collection of =
resources.
> >
> > It just occurred to me that something like that might already exist =
in the context of cache invalidation protocols.?
> >
> > Jan
> >
> >
> > _______________________________________________
> > apps-discuss mailing list
> > apps-discuss@ietf.org
> > https://www.ietf.org/mailman/listinfo/apps-discuss
>=20
> =20
>=20
>=20
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>=20
>=20
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss


From darrel.miller@gmail.com  Wed Jan  8 17:26:51 2014
Return-Path: <darrel.miller@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0FAA1ADF75 for <apps-discuss@ietfa.amsl.com>; Wed,  8 Jan 2014 17:26:51 -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 Sfu9uW3AXYN9 for <apps-discuss@ietfa.amsl.com>; Wed,  8 Jan 2014 17:26:50 -0800 (PST)
Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 8B86B1ADF0E for <apps-discuss@ietf.org>; Wed,  8 Jan 2014 17:26:50 -0800 (PST)
Received: by mail-ig0-f170.google.com with SMTP id k19so14752599igc.1 for <apps-discuss@ietf.org>; Wed, 08 Jan 2014 17:26:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type:content-transfer-encoding; bh=evwU86pl9xfoIlPsgWtUgL1/kbVhZdCVOuoqQolfVDM=; b=eZ63ROOmE6WjiNfQ1BFYAN0lxIGQFt9G3bGG7ITzsqY3ByemQWwS7PXKofHJq8g8jo 3IjO0aT2HAJdoAAGSlxrPCkgkyiVAlfB4op6GrnLEcOHz8b5X9WWCYuqBSrrcUrDOjbh ScbbMgAgsyxVEQ9MWok0xQkmcJO6AzrhlGfCTTCxuKBgqaWmZbB83fxRF6HnyqCkbSJw O8ltEFs7qRTfx2ly9UXKg38TtIPGA+qga72LuVi3pnELskQi8Wgg7JbnCPcCZz/kRcWO dIjp7A3SPrrkL2tQqEivIXiVsh+t2sNuV5b16/ZTJdXXdsIl6ZGsjgvp+jyMzueBTRQq eiVQ==
MIME-Version: 1.0
X-Received: by 10.43.0.202 with SMTP id nn10mr240275icb.54.1389230801145; Wed, 08 Jan 2014 17:26:41 -0800 (PST)
Received: by 10.42.195.206 with HTTP; Wed, 8 Jan 2014 17:26:41 -0800 (PST)
In-Reply-To: <1D9FD392-BC56-46A0-927E-94EE3BCC2C6A@nordsc.com>
References: <A4A8D5B5-73D7-4F4C-968A-D23337DF4FA2@nordsc.com> <CAPW_8m7OP8bG4ExEB6Dk867WJkoTgS5ODkM_-J3v0kr6zfyBuQ@mail.gmail.com> <C8613FAB-B758-44BC-A752-EBAD26D79E7A@nordsc.com> <CAPW_8m5q5hO0QjDiUx9FxU3xhc3b_Kjz3qAwWxQBi2rhJT7nQQ@mail.gmail.com> <d19ed0e39f2d4c9ab8cb395b6faa1078@BL2PR02MB307.namprd02.prod.outlook.com> <CAHBU6ivCBSrXME6OuHjwuLk8jO035WHpwbw6D0-Zk7s_yEDYhg@mail.gmail.com> <1D9FD392-BC56-46A0-927E-94EE3BCC2C6A@nordsc.com>
Date: Wed, 8 Jan 2014 20:26:41 -0500
Message-ID: <CAKioOqsyrKxTZdiiEUziDnwt=YFZhap4W_VR28GFpJ9gWYztgg@mail.gmail.com>
From: Darrel Miller <darrel.miller@gmail.com>
To: IETF Apps Discuss <apps-discuss@ietf.org>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Subject: Re: [apps-discuss] Fwd: Media type for lists of changed URIs?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: darrel@tavis.ca
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Jan 2014 01:26:52 -0000

On Wed, Jan 8, 2014 at 8:24 PM, Jan Algermissen
<jan.algermissen@nordsc.com> wrote:
>
> On 09.01.2014, at 02:21, Tim Bray <tbray@textuality.com> wrote:
>
>> What Larry said, I=92d do this in JSON and invest my efforts in the appl=
ication semantics.
>
> Interesting - where in REST do you put application semantics if not in th=
e media type?
>
> Jan
>

I was seconds away from pressing send with the same question.


Darrel

From tbray@textuality.com  Wed Jan  8 17:38:48 2014
Return-Path: <tbray@textuality.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A33071ADF89 for <apps-discuss@ietfa.amsl.com>; Wed,  8 Jan 2014 17:38:48 -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 S1IK6AZjckdk for <apps-discuss@ietfa.amsl.com>; Wed,  8 Jan 2014 17:38:47 -0800 (PST)
Received: from mail-la0-f48.google.com (mail-la0-f48.google.com [209.85.215.48]) by ietfa.amsl.com (Postfix) with ESMTP id C0B681AD8F4 for <apps-discuss@ietf.org>; Wed,  8 Jan 2014 17:38:46 -0800 (PST)
Received: by mail-la0-f48.google.com with SMTP id n7so1693826lam.21 for <apps-discuss@ietf.org>; Wed, 08 Jan 2014 17:38:36 -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=dvYET8TiMlAtSjyF4vJ5xF/1tnRDJY/QhjM/qLk9O6k=; b=Jjfq0j+6+mKClzr/ShLv460pCbiA2s/+zqW9z3uzHRrreTEtlARhqDqlmv/aTXuYTx FRQt2gbn9GcZtblFAxZ4M6SVsLk0XSf8b4ubpCrpmJTZYbXbXsnwLGTvpYjjdGSN2eO9 kce+xEiu6hG341ksWFeXP0BghfVd40ki3fNoAEd0oOQoK0WRF4DEagZ/SNWVCT0j35us pkoJNLUagB89xG3NdRdLUsb6+RWNsHH40K0AkYLXU9GCJOYOPu/MCehD+1k9mWYs6uuC 6kD+ZCkVi7WQ8XLLhDj2CPVBpPJ1+cRKSDdFT5/0EosF1kCTuDSamikJ/YFVNqgxh/K9 XBmg==
X-Gm-Message-State: ALoCoQmgcmOwFMiuhuk+Fnq2JTLEGAtEvaTmaD3u4IpE2nXTdORjGDbuPMZCQfTrjmtGBqTRM9ms
MIME-Version: 1.0
X-Received: by 10.112.219.170 with SMTP id pp10mr100603lbc.29.1389231516776; Wed, 08 Jan 2014 17:38:36 -0800 (PST)
Received: by 10.114.24.6 with HTTP; Wed, 8 Jan 2014 17:38:36 -0800 (PST)
X-Originating-IP: [96.49.81.176]
In-Reply-To: <CAKioOqsyrKxTZdiiEUziDnwt=YFZhap4W_VR28GFpJ9gWYztgg@mail.gmail.com>
References: <A4A8D5B5-73D7-4F4C-968A-D23337DF4FA2@nordsc.com> <CAPW_8m7OP8bG4ExEB6Dk867WJkoTgS5ODkM_-J3v0kr6zfyBuQ@mail.gmail.com> <C8613FAB-B758-44BC-A752-EBAD26D79E7A@nordsc.com> <CAPW_8m5q5hO0QjDiUx9FxU3xhc3b_Kjz3qAwWxQBi2rhJT7nQQ@mail.gmail.com> <d19ed0e39f2d4c9ab8cb395b6faa1078@BL2PR02MB307.namprd02.prod.outlook.com> <CAHBU6ivCBSrXME6OuHjwuLk8jO035WHpwbw6D0-Zk7s_yEDYhg@mail.gmail.com> <1D9FD392-BC56-46A0-927E-94EE3BCC2C6A@nordsc.com> <CAKioOqsyrKxTZdiiEUziDnwt=YFZhap4W_VR28GFpJ9gWYztgg@mail.gmail.com>
Date: Wed, 8 Jan 2014 17:38:36 -0800
Message-ID: <CAHBU6ivhW+OdXFTgppkJz9CkPnRD2QKG9MBm-AiWyZG+tS-Bwg@mail.gmail.com>
From: Tim Bray <tbray@textuality.com>
To: darrel@tavis.ca
Content-Type: multipart/alternative; boundary=001a11c259921180b004ef7fabbe
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Fwd: Media type for lists of changed URIs?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Jan 2014 01:38:48 -0000

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

application/url-delta+json


On Wed, Jan 8, 2014 at 5:26 PM, Darrel Miller <darrel.miller@gmail.com>wrot=
e:

> On Wed, Jan 8, 2014 at 8:24 PM, Jan Algermissen
> <jan.algermissen@nordsc.com> wrote:
> >
> > On 09.01.2014, at 02:21, Tim Bray <tbray@textuality.com> wrote:
> >
> >> What Larry said, I=E2=80=99d do this in JSON and invest my efforts in =
the
> application semantics.
> >
> > Interesting - where in REST do you put application semantics if not in
> the media type?
> >
> > Jan
> >
>
> I was seconds away from pressing send with the same question.
>
>
> Darrel
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

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

<div dir=3D"ltr">application/url-delta+json</div><div class=3D"gmail_extra"=
><br><br><div class=3D"gmail_quote">On Wed, Jan 8, 2014 at 5:26 PM, Darrel =
Miller <span dir=3D"ltr">&lt;<a href=3D"mailto:darrel.miller@gmail.com" tar=
get=3D"_blank">darrel.miller@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On Wed, Jan 8, 2014 at 8:2=
4 PM, Jan Algermissen<br>
&lt;<a href=3D"mailto:jan.algermissen@nordsc.com">jan.algermissen@nordsc.co=
m</a>&gt; wrote:<br>
&gt;<br>
&gt; On 09.01.2014, at 02:21, Tim Bray &lt;<a href=3D"mailto:tbray@textuali=
ty.com">tbray@textuality.com</a>&gt; wrote:<br>
&gt;<br>
&gt;&gt; What Larry said, I=E2=80=99d do this in JSON and invest my efforts=
 in the application semantics.<br>
&gt;<br>
&gt; Interesting - where in REST do you put application semantics if not in=
 the media type?<br>
&gt;<br>
&gt; Jan<br>
&gt;<br>
<br>
</div>I was seconds away from pressing send with the same question.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
<br>
Darrel<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5">_____________________=
__________________________<br>
apps-discuss mailing list<br>
<a href=3D"mailto:apps-discuss@ietf.org">apps-discuss@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/apps-discuss" target=3D"_b=
lank">https://www.ietf.org/mailman/listinfo/apps-discuss</a><br>
</div></div></blockquote></div><br></div>

--001a11c259921180b004ef7fabbe--

From masinter@adobe.com  Wed Jan  8 17:44:21 2014
Return-Path: <masinter@adobe.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77EA41ADF9A for <apps-discuss@ietfa.amsl.com>; Wed,  8 Jan 2014 17:44:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ae4SFT3HRCiH for <apps-discuss@ietfa.amsl.com>; Wed,  8 Jan 2014 17:44:19 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0149.outbound.protection.outlook.com [207.46.163.149]) by ietfa.amsl.com (Postfix) with ESMTP id 5B21C1ADFA1 for <apps-discuss@ietf.org>; Wed,  8 Jan 2014 17:44:19 -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; Thu, 9 Jan 2014 01:44:09 +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; Thu, 9 Jan 2014 01:44:09 +0000
From: Larry Masinter <masinter@adobe.com>
To: "Henry S. Thompson" <ht@inf.ed.ac.uk>
Thread-Topic: [apps-discuss] draft-ietf-appsawg-xml-mediatypes vs. JSON and BOM and UTF-8
Thread-Index: Ac8L2XBoRlaAodKPT3Ke5g3NgorsigAf0axqAB9QbvA=
Date: Thu, 9 Jan 2014 01:44:08 +0000
Message-ID: <9711cfa14ec04c29bc5eadc2bca83c15@BL2PR02MB307.namprd02.prod.outlook.com>
References: <dc29826a2bbf48088abe51bb5de22e0d@BL2PR02MB307.namprd02.prod.outlook.com> <f5b38kyhjyt.fsf@troutbeck.inf.ed.ac.uk>
In-Reply-To: <f5b38kyhjyt.fsf@troutbeck.inf.ed.ac.uk>
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: 008663486A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(189002)(199002)(65816001)(80976001)(74316001)(85306002)(76786001)(85852003)(2656002)(87936001)(79102001)(76576001)(56816005)(63696002)(66066001)(74366001)(69226001)(81686001)(83072002)(81542001)(76796001)(80022001)(87266001)(46102001)(74706001)(74876001)(81816001)(53806001)(31966008)(54356001)(76482001)(51856001)(74662001)(54316002)(77982001)(59766001)(90146001)(33646001)(81342001)(47446002)(50986001)(49866001)(56776001)(83322001)(74502001)(47976001)(4396001)(47736001)(92566001)(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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: adobe.com
Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] draft-ietf-appsawg-xml-mediatypes vs. JSON and BOM and UTF-8
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Jan 2014 01:44:21 -0000

I said
> I don't really understand what a "XML-unaware MIME producer" is. If
> they're "unaware", why are they reading this spec?

But I think I'd missed this the first pass, I think I just don't like the -=
aware terminology here.
Please don't clarify.

There are three ways content can advertise its encoding:
  Charset parameter to media type
   Internal charset declaration
   Initial BOM (indicates utf16be, utf16le, utf-32, utf-8)

I think things get simpler if you treat the non-aware case just one of the =
exceptions to the "SHOULD" for transmitters.
That is, rather than dividing the world into "aware" and "not-aware", just =
make two categories:

* Those than can send UTF-8 without a BOM and with an internal charset decl=
aration of UTF-8.
* Those that can't do so.

"producers of XML  SHOULD produce UTF-8, with no BOM, with no charset param=
eter, with an internal UTF-8 charset declaration", we make this the default=
; it is a new requirement. Those that can't are in some situation of deprec=
ated legacy implementation or limited capabilities. They can't transcode in=
to UTF-8, can't add or remove a BOM, or can't add or modify an internal cha=
rset declaration. Do the best you can, but try to make sure there's a chars=
et parameter and that it matches the actual encoding or an internal charset=
 declaration (because then processors will fail.=20

Of course, there are more constraints on processors, because they need to d=
eal with legacy, but this will give clear advice to senders.






From duerst@it.aoyama.ac.jp  Wed Jan  8 17:55:57 2014
Return-Path: <duerst@it.aoyama.ac.jp>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C703E1ADFBB for <apps-discuss@ietfa.amsl.com>; Wed,  8 Jan 2014 17:55:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.371
X-Spam-Level: 
X-Spam-Status: No, score=0.371 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.538] 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 9vpC3aVb28IT for <apps-discuss@ietfa.amsl.com>; Wed,  8 Jan 2014 17:55:56 -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 C3B9B1ADFB0 for <apps-discuss@ietf.org>; Wed,  8 Jan 2014 17:55:55 -0800 (PST)
Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id s091tdbN020754; Thu, 9 Jan 2014 10:55:39 +0900
Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 2b21_06a5_2402f654_78d1_11e3_9dd9_001e6722eec2; Thu, 09 Jan 2014 10:55:39 +0900
Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 750B6BF548; Thu,  9 Jan 2014 10:55:39 +0900 (JST)
Message-ID: <52CE018D.4020303@it.aoyama.ac.jp>
Date: Thu, 09 Jan 2014 10:55:25 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= <duerst@it.aoyama.ac.jp>
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: Larry Masinter <masinter@adobe.com>
References: <dc29826a2bbf48088abe51bb5de22e0d@BL2PR02MB307.namprd02.prod.outlook.com> <f5b38kyhjyt.fsf@troutbeck.inf.ed.ac.uk> <9711cfa14ec04c29bc5eadc2bca83c15@BL2PR02MB307.namprd02.prod.outlook.com>
In-Reply-To: <9711cfa14ec04c29bc5eadc2bca83c15@BL2PR02MB307.namprd02.prod.outlook.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] draft-ietf-appsawg-xml-mediatypes vs. JSON and BOM and UTF-8
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Jan 2014 01:55:58 -0000

On 2014/01/09 10:44, Larry Masinter wrote:
> I said
>> I don't really understand what a "XML-unaware MIME producer" is. If
>> they're "unaware", why are they reading this spec?
>
> But I think I'd missed this the first pass, I think I just don't like the -aware terminology here.
> Please don't clarify.
>
> There are three ways content can advertise its encoding:
>    Charset parameter to media type
>     Internal charset declaration
>     Initial BOM (indicates utf16be, utf16le, utf-32, utf-8)
>
> I think things get simpler if you treat the non-aware case just one of the exceptions to the "SHOULD" for transmitters.
> That is, rather than dividing the world into "aware" and "not-aware", just make two categories:
>
> * Those than can send UTF-8 without a BOM and with an internal charset declaration of UTF-8.
> * Those that can't do so.
>
> "producers of XML  SHOULD produce UTF-8, with no BOM, with no charset parameter, with an internal UTF-8 charset declaration", we make this the default; it is a new requirement. Those that can't are in some situation of deprecated legacy implementation or limited capabilities. They can't transcode into UTF-8, can't add or remove a BOM, or can't add or modify an internal charset declaration. Do the best you can, but try to make sure there's a charset parameter and that it matches the actual encoding or an internal charset declaration (because then processors will fail.

Why would the default here be *with* an internal UTF-8 declaration? 
Documents without such a declaration are also well-formed/valid UTF-8 
XML documents (assuming that they are well-formed/valid otherwise).

Moving to an UTF-8 only world, not having to declare UTF-8 anywhere 
should be part of that world. It is not for HTML, unfortunately, but it 
is perfectly possible for XML.

Regards,   Martin.

> Of course, there are more constraints on processors, because they need to deal with legacy, but this will give clear advice to senders.

From jan.algermissen@nordsc.com  Wed Jan  8 23:01:06 2014
Return-Path: <jan.algermissen@nordsc.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95B6D1ADEA6 for <apps-discuss@ietfa.amsl.com>; Wed,  8 Jan 2014 23:01:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level: 
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 3vp2n66bLVcF for <apps-discuss@ietfa.amsl.com>; Wed,  8 Jan 2014 23:01:05 -0800 (PST)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by ietfa.amsl.com (Postfix) with ESMTP id C743F1ADD9A for <apps-discuss@ietf.org>; Wed,  8 Jan 2014 23:01:04 -0800 (PST)
Received: from [172.20.10.5] (tmo-108-23.customers.d1-online.com [80.187.108.23]) by mrelayeu.kundenserver.de (node=mrbap4) with ESMTP (Nemesis) id 0Lnjgd-1VSvvR2PPz-00hrcy; Thu, 09 Jan 2014 08:00:51 +0100
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jan Algermissen <jan.algermissen@nordsc.com>
In-Reply-To: <CAHBU6ivhW+OdXFTgppkJz9CkPnRD2QKG9MBm-AiWyZG+tS-Bwg@mail.gmail.com>
Date: Thu, 9 Jan 2014 08:00:48 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <626ED025-6E7F-4A59-9C27-93574F907DEB@nordsc.com>
References: <A4A8D5B5-73D7-4F4C-968A-D23337DF4FA2@nordsc.com> <CAPW_8m7OP8bG4ExEB6Dk867WJkoTgS5ODkM_-J3v0kr6zfyBuQ@mail.gmail.com> <C8613FAB-B758-44BC-A752-EBAD26D79E7A@nordsc.com> <CAPW_8m5q5hO0QjDiUx9FxU3xhc3b_Kjz3qAwWxQBi2rhJT7nQQ@mail.gmail.com> <d19ed0e39f2d4c9ab8cb395b6faa1078@BL2PR02MB307.namprd02.prod.outlook.com> <CAHBU6ivCBSrXME6OuHjwuLk8jO035WHpwbw6D0-Zk7s_yEDYhg@mail.gmail.com> <1D9FD392-BC56-46A0-927E-94EE3BCC2C6A@nordsc.com> <CAKioOqsyrKxTZdiiEUziDnwt=YFZhap4W_VR28GFpJ9gWYztgg@mail.gmail.com> <CAHBU6ivhW+OdXFTgppkJz9CkPnRD2QKG9MBm-AiWyZG+tS-Bwg@mail.gmail.com>
To: Tim Bray <tbray@textuality.com>
X-Mailer: Apple Mail (2.1510)
X-Provags-ID: V02:K0:JZUko5ID4rb41LgypRMv58x6eko+k2sNt+H0FcCsyAQ xO2ZyjFY/TEft/okCdjI+zODHkfDvDeADSLp6e6usOkZeGPyme +yod2qq8cJEavxTpII61D3O5w+9WxwaDv5b63yrL+CcRiY3m6Z VOGTLsJU78SY4rtsY0IdLOwJF7SCgbDXkr+9cbNf0NEjdMQxCF 1zbdP9PHrucmaNRYjVMCA5hHGjrOUcPCu7aWW+8kYJnMigX9Q1 WXgwVat6JJvhj45Z8pnNQwgTZEHlIUtKxxJ56Oo+hItpaxbAkE oGEeQH8SiqrCepIgM/bgJz42+kmikRikZJ4vTcdj9XHTNuexbr BNUt3TGAOZRXnPtHhlB/ABRlsNJ7J9AksKb/N/fbM78lRzeMxg JoMYuHJ6d+E/Q==
Cc: darrel@tavis.ca, IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Fwd: Media type for lists of changed URIs?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Jan 2014 07:01:06 -0000

On 09.01.2014, at 02:38, Tim Bray <tbray@textuality.com> wrote:

> application/url-delta+json

Ah, I mistook you guys to mean application/json.

And +1 to the extensibility.

Jan

>=20
>=20
> On Wed, Jan 8, 2014 at 5:26 PM, Darrel Miller =
<darrel.miller@gmail.com> wrote:
> On Wed, Jan 8, 2014 at 8:24 PM, Jan Algermissen
> <jan.algermissen@nordsc.com> wrote:
> >
> > On 09.01.2014, at 02:21, Tim Bray <tbray@textuality.com> wrote:
> >
> >> What Larry said, I=92d do this in JSON and invest my efforts in the =
application semantics.
> >
> > Interesting - where in REST do you put application semantics if not =
in the media type?
> >
> > Jan
> >
>=20
> I was seconds away from pressing send with the same question.
>=20
>=20
> Darrel
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>=20
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss


From jan.algermissen@nordsc.com  Thu Jan  9 06:11:59 2014
Return-Path: <jan.algermissen@nordsc.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BABFD1AE311 for <apps-discuss@ietfa.amsl.com>; Thu,  9 Jan 2014 06:11:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level: 
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 z_KHID0GfPUN for <apps-discuss@ietfa.amsl.com>; Thu,  9 Jan 2014 06:11:58 -0800 (PST)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by ietfa.amsl.com (Postfix) with ESMTP id 4C0001AE306 for <apps-discuss@ietf.org>; Thu,  9 Jan 2014 06:11:58 -0800 (PST)
Received: from [10.90.143.216] ([87.253.171.202]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0MIxJ3-1VzKWp3AjJ-002RJs; Thu, 09 Jan 2014 15:11:46 +0100
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jan Algermissen <jan.algermissen@nordsc.com>
In-Reply-To: <52CEA611.5030101@ninebynine.org>
Date: Thu, 9 Jan 2014 15:11:41 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <CD885CFB-7A35-48A2-ADDF-300B2054787A@nordsc.com>
References: <A4A8D5B5-73D7-4F4C-968A-D23337DF4FA2@nordsc.com> <52CEA611.5030101@ninebynine.org>
To: Graham Klyne <GK@ninebynine.org>
X-Mailer: Apple Mail (2.1510)
X-Provags-ID: V02:K0:Kh5WozVGfU/4l+Lkgi6qyBtK/zGCJov+IhxQvsRiDCo lpXItZnS2LAC5RUY3ZCfYGm2KSZfXN/T9PtPiJHvlGGg3+K5JS klWwp6EJZRKGHRmaCz+yxwUQhMGwfUksTIteDMdWqBrvysGoSZ QzQ7Bcx+XMiBdbtZBPyD71wDoCWlhx14GruptfvrmeyXfZa6Wc ZWvgo0JejrybeE1Pm/w6x2zVoFK1Cte8lB6CrKIlUwstafps8A 8POBKcaLyzfUcUC/a0a0I+7QLWpAwXWcIPMmP5s7ctSsEoGNlq C7v9yfEDyRUPE/VYSA2Wu2x9dWK/iAdacBNpVzBIz+gCiD04Cu 45X48na+vZkVdKvWCHDp7GGnKGXSpGloSnqkaidkNCecoDtf59 Wx9AchtKkIX8w==
Cc: "apps-discuss@ietf.org Discuss" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Media type for lists of changed URIs?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Jan 2014 14:12:00 -0000

On 09.01.2014, at 14:37, Graham Klyne <GK@ninebynine.org> wrote:

> Hi,
>=20
> Maybe ResourceSync (http://www.openarchives.org/rs/0.9.1/resourcesync) =
has something for you?

Wow - basically what I am up to. How did I manage to miss it.=20

Only thing that's missing, AFAICS, and which  I'll eventually need is =
the put/patch payload in the change list because in my scenario the =
number of updates and frequency is too high to justify individual GETs =
to sync.=20

Will take a deeper look anyhow.


>=20
> (The data formats used are based on SiteMap/XML rather than JSON as =
recommended by others in this thread. =20

I actuall like XML quite a bit, still.

> Maybe unhelpful is the current lack of a separate MIME type?)
>=20

Well, .... yup :-)

Jan


> #g
> --
>=20
> On 08/01/2014 14:46, Jan Algermissen wrote:
>> Hi all,
>>=20
>> I am about to work on a media type for transferring lists of URIs of =
resource that have changed to an 'observer' of a collection of =
resources.
>>=20
>> It just occurred to me that something like that might already exist =
in the context of cache invalidation protocols.?
>>=20
>> Jan
>>=20
>>=20
>> _______________________________________________
>> apps-discuss mailing list
>> apps-discuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/apps-discuss
>>=20


From jan.algermissen@nordsc.com  Thu Jan  9 06:24:02 2014
Return-Path: <jan.algermissen@nordsc.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6734E1AE2E3 for <apps-discuss@ietfa.amsl.com>; Thu,  9 Jan 2014 06:24:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level: 
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 fJfdugChZL08 for <apps-discuss@ietfa.amsl.com>; Thu,  9 Jan 2014 06:24:01 -0800 (PST)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by ietfa.amsl.com (Postfix) with ESMTP id 19E9D1AE07F for <apps-discuss@ietf.org>; Thu,  9 Jan 2014 06:24:01 -0800 (PST)
Received: from [10.90.143.216] ([87.253.171.202]) by mrelayeu.kundenserver.de (node=mrbap3) with ESMTP (Nemesis) id 0Mg6ir-1VnIXL0ca5-00NDvS; Thu, 09 Jan 2014 15:23:50 +0100
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jan Algermissen <jan.algermissen@nordsc.com>
In-Reply-To: <52CEA611.5030101@ninebynine.org>
Date: Thu, 9 Jan 2014 15:23:49 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <8205FDEA-DCEE-43D6-B6F4-FF14FB156BC7@nordsc.com>
References: <A4A8D5B5-73D7-4F4C-968A-D23337DF4FA2@nordsc.com> <52CEA611.5030101@ninebynine.org>
To: Graham Klyne <GK@ninebynine.org>
X-Mailer: Apple Mail (2.1510)
X-Provags-ID: V02:K0:Oo3minybuwZrQYcXzNr85ZxI3Fk40NC64FfIETPaq1d nC8vdUYf27ob7TGB8KT+SMh7lZjF7UVIZU8Cry5qULBzLCAYwV 8bd4yN2wWZ+BYeh8HXhorqNjF9ehcZ6/aKAmTaPCv0RHMTtegD Ne2cUc2ziR0Eq9D2n5S/lnF0cd4qdxMSBPvCbSC3rnVYvCVlyH 5qKobgfGBAbRK1mXMYPdGXYMoNm4JPFYIEZhVSn5ziQP2I4KjC mldMxog70WCsSGFbj24L/4xmLZU3zEfTblvaDr4P5nuOTKgrBy rCh2QJ8HAmBwyOTjKtn9XMQ0+6FYOlL/mVEhzzdMbz6w311Yyy iyKbm8WPUD+nw6hvu/hUSZLl3mEFf7z3/N18FHy08rpmc4i+nR uD0IkY182HgMA==
Cc: "apps-discuss@ietf.org Discuss" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Media type for lists of changed URIs?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Jan 2014 14:24:02 -0000

On 09.01.2014, at 14:37, Graham Klyne <GK@ninebynine.org> wrote:

> Hi,
>=20
> Maybe ResourceSync (http://www.openarchives.org/rs/0.9.1/resourcesync) =
has something for you?

Any plans to register the link relation type resourceSync[1] with IANA?

Jan

[1] http://www.openarchives.org/rs/0.9.1/resourcesync#disco_links


>=20
> (The data formats used are based on SiteMap/XML rather than JSON as =
recommended by others in this thread.  Maybe unhelpful is the current =
lack of a separate MIME type?)
>=20
> #g
> --
>=20
> On 08/01/2014 14:46, Jan Algermissen wrote:
>> Hi all,
>>=20
>> I am about to work on a media type for transferring lists of URIs of =
resource that have changed to an 'observer' of a collection of =
resources.
>>=20
>> It just occurred to me that something like that might already exist =
in the context of cache invalidation protocols.?
>>=20
>> Jan
>>=20
>>=20
>> _______________________________________________
>> apps-discuss mailing list
>> apps-discuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/apps-discuss
>>=20


From jan.algermissen@nordsc.com  Thu Jan  9 06:40:15 2014
Return-Path: <jan.algermissen@nordsc.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 329E71AE338 for <apps-discuss@ietfa.amsl.com>; Thu,  9 Jan 2014 06:40:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level: 
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 XZB7xcM8vhnK for <apps-discuss@ietfa.amsl.com>; Thu,  9 Jan 2014 06:40:13 -0800 (PST)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by ietfa.amsl.com (Postfix) with ESMTP id 8225A1AE30F for <apps-discuss@ietf.org>; Thu,  9 Jan 2014 06:40:13 -0800 (PST)
Received: from [10.90.143.216] ([87.253.171.202]) by mrelayeu.kundenserver.de (node=mrbap3) with ESMTP (Nemesis) id 0LjJuR-1VOMn93aXP-00dCaK; Thu, 09 Jan 2014 15:40:01 +0100
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jan Algermissen <jan.algermissen@nordsc.com>
In-Reply-To: <52CEB233.2090003@ninebynine.org>
Date: Thu, 9 Jan 2014 15:39:59 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <E89D4E7F-82C6-4AE9-9EC3-E4AA5AF1B47C@nordsc.com>
References: <A4A8D5B5-73D7-4F4C-968A-D23337DF4FA2@nordsc.com> <52CEA611.5030101@ninebynine.org> <CD885CFB-7A35-48A2-ADDF-300B2054787A@nordsc.com> <52CEB233.2090003@ninebynine.org>
To: Graham Klyne <GK@ninebynine.org>
X-Mailer: Apple Mail (2.1510)
X-Provags-ID: V02:K0:JNe7Ka5D2wS1Pjm6rIoljKZJy56S//YLNRq7uYZZq6W CgSjcl1GQlC2J1fWEz/vbyBcT/RNf9mRZcsGvyILUdgpJq5lH3 +GycncuYBTlrtDbhFsXP9VLLy4818rM4NCWnVjiXvRq6BsF727 XR8Whb+lwv42KZux/JuxjSHLjjt+dxGcunBpPrDj0csdoGsCb/ pa5c8Q17ephyJmoZ8rF45Xl+X4n5speWFQQzNvpc/dMl7qGBM4 3OO6FLOrw81oKGvdxCTgfkVxYzC1S0xFXPu42WJlLUDuqS/Hwl UGXozkkNckcz5IN9/adPhG5jHCFywHbJtEBd9wxZoFwOr3/86S Y0KLBXrviQPKX1xDOg6gv/cNbyPpZf7T4LyzWnJ45wvsB9rhfe zItJ35aWNUI3w==
Cc: "apps-discuss@ietf.org Discuss" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Media type for lists of changed URIs?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Jan 2014 14:40:15 -0000

On 09.01.2014, at 15:29, Graham Klyne <GK@ninebynine.org> wrote:

> On 09/01/2014 14:11, Jan Algermissen wrote:
>>=20
>> On 09.01.2014, at 14:37, Graham Klyne <GK@ninebynine.org> wrote:
>>=20
>>> Hi,
>>>=20
>>> Maybe ResourceSync =
(http://www.openarchives.org/rs/0.9.1/resourcesync) has something for =
you?
>>=20
>> Wow - basically what I am up to. How did I manage to miss it.
>>=20
>> Only thing that's missing, AFAICS, and which  I'll eventually need is =
the put/patch payload in the change list because in my scenario the =
number of updates and frequency is too high to justify individual GETs =
to sync.
>>=20
>> Will take a deeper look anyhow.
>=20
> There are provisions for payload and patch-style operations through =
resource/change dumps and related-resource links respectively.

Ok, must have missed that at first glance. Either way, pretty exciting =
you ended up alost exactly where I did.

I have a question regarding a real practical problem from the eCommerce =
domain:

When eShops send product information to price comparison search engines =
there is the inherent problem of latency between price updates in the =
eShop and the re-publishing+ingestion to the shopping engine. If =
customers find higher prices in the shop, than on the site of the =
shopping engine, legal fees apply in some countries[1].

Have you ever thought of (or know about plans to) having the major =
shopping engines adopt resource sync to mitigate that problem? Would =
lead to a relief of quite some headaches of quite some people I must =
say.

Given there is sitemap in the mix, I thought Google might have a hand in =
it somehow.

Jan


[1] German federal court for example ruled the prices on the site may =
not be higher because "the customer can expect the systems to be in =
sync". Which shows an astonishing lack of understanding of the technical =
domain being ruled upon, IMHO :-)




>=20
> Also, the group is currently discussing PubSubHubbub-based =
notifications to reduce polling load for learning about updates.  The =
initial draft for that proposal should be public very soon (hopefully =
days).
>=20
>>=20
>>>=20
>>> (The data formats used are based on SiteMap/XML rather than JSON as =
recommended by others in this thread.
>>=20
>> I actuall like XML quite a bit, still.
>>=20
>>> Maybe unhelpful is the current lack of a separate MIME type?)
>>>=20
>>=20
>> Well, .... yup :-)
>=20
> I just posed that as a question to the ResourceSync working group.  =
There's a public discussion list at =
https://groups.google.com/forum/?fromgroups#!forum/resourcesync
>=20
> This would probably be a good time to get involved with the =
discussions :)
>=20
> #g
> --
>=20
>>>=20
>>> On 08/01/2014 14:46, Jan Algermissen wrote:
>>>> Hi all,
>>>>=20
>>>> I am about to work on a media type for transferring lists of URIs =
of resource that have changed to an 'observer' of a collection of =
resources.
>>>>=20
>>>> It just occurred to me that something like that might already exist =
in the context of cache invalidation protocols.?
>>>>=20
>>>> Jan
>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> apps-discuss mailing list
>>>> apps-discuss@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/apps-discuss
>>>>=20
>>=20
>> _______________________________________________
>> apps-discuss mailing list
>> apps-discuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/apps-discuss
>>=20


From GK@ninebynine.org  Thu Jan  9 06:38:03 2014
Return-Path: <GK@ninebynine.org>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D8721AE338 for <apps-discuss@ietfa.amsl.com>; Thu,  9 Jan 2014 06:38:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mxskWJJHSX1b for <apps-discuss@ietfa.amsl.com>; Thu,  9 Jan 2014 06:38:00 -0800 (PST)
Received: from relay16.mail.ox.ac.uk (relay16.mail.ox.ac.uk [163.1.2.166]) by ietfa.amsl.com (Postfix) with ESMTP id F27AD1AE350 for <apps-discuss@ietf.org>; Thu,  9 Jan 2014 06:37:59 -0800 (PST)
Received: from smtp0.mail.ox.ac.uk ([129.67.1.205]) by relay16.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from <GK@ninebynine.org>) id 1W1Gk2-0004xo-qH; Thu, 09 Jan 2014 14:37:50 +0000
Received: from gklyne.plus.com ([80.229.154.156] helo=conina.local) by smtp0.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <GK@ninebynine.org>) id 1W1Gk1-0000In-2q; Thu, 09 Jan 2014 14:37:50 +0000
Message-ID: <52CEB418.3080900@ninebynine.org>
Date: Thu, 09 Jan 2014 14:37:12 +0000
From: Graham Klyne <GK@ninebynine.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: Jan Algermissen <jan.algermissen@nordsc.com>
References: <A4A8D5B5-73D7-4F4C-968A-D23337DF4FA2@nordsc.com> <52CEA611.5030101@ninebynine.org> <8205FDEA-DCEE-43D6-B6F4-FF14FB156BC7@nordsc.com>
In-Reply-To: <8205FDEA-DCEE-43D6-B6F4-FF14FB156BC7@nordsc.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Oxford-Username: zool0635
Cc: "apps-discuss@ietf.org Discuss" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Media type for lists of changed URIs?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Jan 2014 14:54:37 -0000

On 09/01/2014 14:23, Jan Algermissen wrote:
>
> On 09.01.2014, at 14:37, Graham Klyne <GK@ninebynine.org> wrote:
>
>> Hi,
>>
>> Maybe ResourceSync (http://www.openarchives.org/rs/0.9.1/resourcesync) has something for you?
>
> Any plans to register the link relation type resourceSync[1] with IANA?

Yes, I believe so (though I can't find any registration drafts right now).

"Relation types other than the ones listed above can be used in the Resourcesync 
framework. Valid relation types must be registered in the IANA Link Relation 
Type Registry or expressed as URIs as specified in RFC 5988, Sec. 4.2. The 
document [Relation Types Used in the ResourceSync Framework] attempts to provide 
an up-to-date overview." -- 
http://www.openarchives.org/rs/0.9.1/resourcesync#DocumentFormats

See also: http://www.openarchives.org/rs/0.9.1/resourcesync#LinkRelRes

#g
--

>
> [1] http://www.openarchives.org/rs/0.9.1/resourcesync#disco_links
>
>
>>
>> (The data formats used are based on SiteMap/XML rather than JSON as recommended by others in this thread.  Maybe unhelpful is the current lack of a separate MIME type?)
>>
>> #g
>> --
>>
>> On 08/01/2014 14:46, Jan Algermissen wrote:
>>> Hi all,
>>>
>>> I am about to work on a media type for transferring lists of URIs of resource that have changed to an 'observer' of a collection of resources.
>>>
>>> It just occurred to me that something like that might already exist in the context of cache invalidation protocols.?
>>>
>>> Jan
>>>
>>>
>>> _______________________________________________
>>> 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 GK@ninebynine.org  Thu Jan  9 06:29:42 2014
Return-Path: <GK@ninebynine.org>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD8F1AE325 for <apps-discuss@ietfa.amsl.com>; Thu,  9 Jan 2014 06:29:42 -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 KLARQaz-z-g8 for <apps-discuss@ietfa.amsl.com>; Thu,  9 Jan 2014 06:29:40 -0800 (PST)
Received: from relay16.mail.ox.ac.uk (relay16.mail.ox.ac.uk [163.1.2.166]) by ietfa.amsl.com (Postfix) with ESMTP id 13F0A1AE07F for <apps-discuss@ietf.org>; Thu,  9 Jan 2014 06:29:40 -0800 (PST)
Received: from smtp0.mail.ox.ac.uk ([129.67.1.205]) by relay16.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from <GK@ninebynine.org>) id 1W1Gbx-00039D-qz; Thu, 09 Jan 2014 14:29:29 +0000
Received: from gklyne.plus.com ([80.229.154.156] helo=conina.local) by smtp0.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <GK@ninebynine.org>) id 1W1Gbw-000050-38; Thu, 09 Jan 2014 14:29:29 +0000
Message-ID: <52CEB233.2090003@ninebynine.org>
Date: Thu, 09 Jan 2014 14:29:07 +0000
From: Graham Klyne <GK@ninebynine.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: Jan Algermissen <jan.algermissen@nordsc.com>
References: <A4A8D5B5-73D7-4F4C-968A-D23337DF4FA2@nordsc.com> <52CEA611.5030101@ninebynine.org> <CD885CFB-7A35-48A2-ADDF-300B2054787A@nordsc.com>
In-Reply-To: <CD885CFB-7A35-48A2-ADDF-300B2054787A@nordsc.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Oxford-Username: zool0635
Cc: "apps-discuss@ietf.org Discuss" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Media type for lists of changed URIs?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Jan 2014 14:54:39 -0000

On 09/01/2014 14:11, Jan Algermissen wrote:
>
> On 09.01.2014, at 14:37, Graham Klyne <GK@ninebynine.org> wrote:
>
>> Hi,
>>
>> Maybe ResourceSync (http://www.openarchives.org/rs/0.9.1/resourcesync) has something for you?
>
> Wow - basically what I am up to. How did I manage to miss it.
>
> Only thing that's missing, AFAICS, and which  I'll eventually need is the put/patch payload in the change list because in my scenario the number of updates and frequency is too high to justify individual GETs to sync.
>
> Will take a deeper look anyhow.

There are provisions for payload and patch-style operations through 
resource/change dumps and related-resource links respectively.

Also, the group is currently discussing PubSubHubbub-based notifications to 
reduce polling load for learning about updates.  The initial draft for that 
proposal should be public very soon (hopefully days).

>
>>
>> (The data formats used are based on SiteMap/XML rather than JSON as recommended by others in this thread.
>
> I actuall like XML quite a bit, still.
>
>> Maybe unhelpful is the current lack of a separate MIME type?)
>>
>
> Well, .... yup :-)

I just posed that as a question to the ResourceSync working group.  There's a 
public discussion list at 
https://groups.google.com/forum/?fromgroups#!forum/resourcesync

This would probably be a good time to get involved with the discussions :)

#g
--

>>
>> On 08/01/2014 14:46, Jan Algermissen wrote:
>>> Hi all,
>>>
>>> I am about to work on a media type for transferring lists of URIs of resource that have changed to an 'observer' of a collection of resources.
>>>
>>> It just occurred to me that something like that might already exist in the context of cache invalidation protocols.?
>>>
>>> Jan
>>>
>>>
>>> _______________________________________________
>>> 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 GK@ninebynine.org  Thu Jan  9 07:12:20 2014
Return-Path: <GK@ninebynine.org>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE3FC1AD9AE for <apps-discuss@ietfa.amsl.com>; Thu,  9 Jan 2014 07:12:20 -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 MQpvhwvZsUjN for <apps-discuss@ietfa.amsl.com>; Thu,  9 Jan 2014 07:12:18 -0800 (PST)
Received: from relay15.mail.ox.ac.uk (relay15.mail.ox.ac.uk [163.1.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id 225AE1AE3CB for <apps-discuss@ietf.org>; Thu,  9 Jan 2014 07:12:18 -0800 (PST)
Received: from smtp0.mail.ox.ac.uk ([129.67.1.205]) by relay15.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from <GK@ninebynine.org>) id 1W1HHD-0006R2-oH; Thu, 09 Jan 2014 15:12:07 +0000
Received: from gklyne.plus.com ([80.229.154.156] helo=conina.local) by smtp0.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <GK@ninebynine.org>) id 1W1HHD-0001IT-0x; Thu, 09 Jan 2014 15:12:07 +0000
Message-ID: <52CEBC45.3050300@ninebynine.org>
Date: Thu, 09 Jan 2014 15:12:05 +0000
From: Graham Klyne <GK@ninebynine.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: Jan Algermissen <jan.algermissen@nordsc.com>
References: <A4A8D5B5-73D7-4F4C-968A-D23337DF4FA2@nordsc.com> <52CEA611.5030101@ninebynine.org> <CD885CFB-7A35-48A2-ADDF-300B2054787A@nordsc.com> <52CEB233.2090003@ninebynine.org> <E89D4E7F-82C6-4AE9-9EC3-E4AA5AF1B47C@nordsc.com>
In-Reply-To: <E89D4E7F-82C6-4AE9-9EC3-E4AA5AF1B47C@nordsc.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Oxford-Username: zool0635
Cc: "apps-discuss@ietf.org Discuss" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Media type for lists of changed URIs?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Jan 2014 15:12:21 -0000

On 09/01/2014 14:39, Jan Algermissen wrote:
>
> On 09.01.2014, at 15:29, Graham Klyne <GK@ninebynine.org> wrote:
>
>> On 09/01/2014 14:11, Jan Algermissen wrote:
>>>
>>> On 09.01.2014, at 14:37, Graham Klyne <GK@ninebynine.org> wrote:
>>>
>>>> Hi,
>>>>
>>>> Maybe ResourceSync (http://www.openarchives.org/rs/0.9.1/resourcesync) has something for you?
>>>
>>> Wow - basically what I am up to. How did I manage to miss it.
>>>
>>> Only thing that's missing, AFAICS, and which  I'll eventually need is the put/patch payload in the change list because in my scenario the number of updates and frequency is too high to justify individual GETs to sync.
>>>
>>> Will take a deeper look anyhow.
>>
>> There are provisions for payload and patch-style operations through resource/change dumps and related-resource links respectively.
>
> Ok, must have missed that at first glance. Either way, pretty exciting you ended up alost exactly where I did.
>
> I have a question regarding a real practical problem from the eCommerce domain:
>
> When eShops send product information to price comparison search engines there is the inherent problem of latency between price updates in the eShop and the re-publishing+ingestion to the shopping engine. If customers find higher prices in the shop, than on the site of the shopping engine, legal fees apply in some countries[1].
>
> Have you ever thought of (or know about plans to) having the major shopping engines adopt resource sync to mitigate that problem? Would lead to a relief of quite some headaches of quite some people I must say.
>
> Given there is sitemap in the mix, I thought Google might have a hand in it somehow.

There are not, to my knowledge, any explicit e-commerce involvements, or plans 
for such, but that's not a deliberate exclusion.  Also, no direct involvement 
with Google AFAIK, but the ResourceSync group did have some discussions with 
some Sitemap people about ensuring consistency of the extensions introduced. 
(Sitemap isn't *only* a Google thing:  cf. http://www.sitemaps.org.)

But the design has attempted to be applicable to web resources in the broadest 
sense.

Specifically, on the issue of synchronization, the design is intended to allow 
the Destination of a ResourceSync change list to be able to determine if it has 
the latest published update.  Some considerable discussion was given to timing 
issues and having confidence that updates could not go silently missing.  But, 
of course, the implementations would be ultimately responsible for ensuring 
changes are pushed out and used consistently.  (E.g. of the Source chooses to 
delay publication of an update, then there's no way for the Destination to know 
about it.)

#g
--



>
> Jan
>
>
> [1] German federal court for example ruled the prices on the site may not be higher because "the customer can expect the systems to be in sync". Which shows an astonishing lack of understanding of the technical domain being ruled upon, IMHO :-)
>
>
>
>
>>
>> Also, the group is currently discussing PubSubHubbub-based notifications to reduce polling load for learning about updates.  The initial draft for that proposal should be public very soon (hopefully days).
>>
>>>
>>>>
>>>> (The data formats used are based on SiteMap/XML rather than JSON as recommended by others in this thread.
>>>
>>> I actuall like XML quite a bit, still.
>>>
>>>> Maybe unhelpful is the current lack of a separate MIME type?)
>>>>
>>>
>>> Well, .... yup :-)
>>
>> I just posed that as a question to the ResourceSync working group.  There's a public discussion list at https://groups.google.com/forum/?fromgroups#!forum/resourcesync
>>
>> This would probably be a good time to get involved with the discussions :)
>>
>> #g
>> --
>>
>>>>
>>>> On 08/01/2014 14:46, Jan Algermissen wrote:
>>>>> Hi all,
>>>>>
>>>>> I am about to work on a media type for transferring lists of URIs of resource that have changed to an 'observer' of a collection of resources.
>>>>>
>>>>> It just occurred to me that something like that might already exist in the context of cache invalidation protocols.?
>>>>>
>>>>> Jan
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>

From GK@ninebynine.org  Thu Jan  9 06:01:13 2014
Return-Path: <GK@ninebynine.org>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6668E1AE30B for <apps-discuss@ietfa.amsl.com>; Thu,  9 Jan 2014 06:01:13 -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 fw5VmtNmeexk for <apps-discuss@ietfa.amsl.com>; Thu,  9 Jan 2014 06:01:11 -0800 (PST)
Received: from relay13.mail.ox.ac.uk (relay13.mail.ox.ac.uk [129.67.1.166]) by ietfa.amsl.com (Postfix) with ESMTP id B424D1AE306 for <apps-discuss@ietf.org>; Thu,  9 Jan 2014 06:01:11 -0800 (PST)
Received: from smtp0.mail.ox.ac.uk ([129.67.1.205]) by relay13.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from <GK@ninebynine.org>) id 1W1GAP-00037D-gI; Thu, 09 Jan 2014 14:01:01 +0000
Received: from gklyne.plus.com ([80.229.154.156] helo=conina.local) by smtp0.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <GK@ninebynine.org>) id 1W1GAO-0007xJ-2Y; Thu, 09 Jan 2014 14:01:01 +0000
Message-ID: <52CEA611.5030101@ninebynine.org>
Date: Thu, 09 Jan 2014 13:37:21 +0000
From: Graham Klyne <GK@ninebynine.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: Jan Algermissen <jan.algermissen@nordsc.com>
References: <A4A8D5B5-73D7-4F4C-968A-D23337DF4FA2@nordsc.com>
In-Reply-To: <A4A8D5B5-73D7-4F4C-968A-D23337DF4FA2@nordsc.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Oxford-Username: zool0635
Cc: "apps-discuss@ietf.org Discuss" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Media type for lists of changed URIs?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Jan 2014 15:15:20 -0000

Hi,

Maybe ResourceSync (http://www.openarchives.org/rs/0.9.1/resourcesync) has 
something for you?

(The data formats used are based on SiteMap/XML rather than JSON as recommended 
by others in this thread.  Maybe unhelpful is the current lack of a separate 
MIME type?)

#g
--

On 08/01/2014 14:46, Jan Algermissen wrote:
> Hi all,
>
> I am about to work on a media type for transferring lists of URIs of resource that have changed to an 'observer' of a collection of resources.
>
> It just occurred to me that something like that might already exist in the context of cache invalidation protocols.?
>
> Jan
>
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

From stephan@rename-it.nl  Thu Jan  9 16:02:23 2014
Return-Path: <stephan@rename-it.nl>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D5611AD66E for <apps-discuss@ietfa.amsl.com>; Thu,  9 Jan 2014 16:02:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.257
X-Spam-Level: 
X-Spam-Status: No, score=0.257 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_15=0.6, RP_MATCHES_RCVD=-0.538] 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 82obs58AcDTq for <apps-discuss@ietfa.amsl.com>; Thu,  9 Jan 2014 16:02:19 -0800 (PST)
Received: from drpepper.rename-it.nl (drpepper.rename-it.nl [217.119.238.16]) by ietfa.amsl.com (Postfix) with ESMTP id 3743A1AD34C for <apps-discuss@ietf.org>; Thu,  9 Jan 2014 16:02:18 -0800 (PST)
Received: from klara.student.utwente.nl ([130.89.162.218]:54175 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 <stephan@rename-it.nl>) id 1W1PY1-00087v-V1; Fri, 10 Jan 2014 01:02:04 +0100
Message-ID: <52CF384D.3080502@rename-it.nl>
Date: Fri, 10 Jan 2014 01:01:17 +0100
From: Stephan Bosch <stephan@rename-it.nl>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: "t.petch" <ietfc@btconnect.com>,  "Murray S. Kucherawy" <superuser@gmail.com>, IETF Apps Discuss <apps-discuss@ietf.org>
References: <CAL0qLwZqJPTssNVLLaSjAP5wqteZ==fuawNF+WUZYvi+YWV1UQ@mail.gmail.com> <00a301cf07e8$01352160$4001a8c0@gateway.2wire.net>
In-Reply-To: <00a301cf07e8$01352160$4001a8c0@gateway.2wire.net>
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] 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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Jan 2014 00:02:23 -0000

Hi Tom,

First of all, thanks for your review.  :)

On 1/2/2014 7:24 PM, t.petch wrote:
> This I-D seems to need more thought.
>
> s.1 "For example, if a member of the list decides to
>    reply to both the user and the mailing list itself, the user will
>    one copy of the message directly and another through the mailing
>    list.
>
> Well, they MAY, but they don't on a good list system, such as the one in
> use here.
>
> "Also, if someone cross-posts over several mailing lists to
>    which the user is subscribed, the user will receive a copy from each
>    of those lists."
>
> Ditto, not here.

Ok, but these situations are quite common. I've implemented an earlier
version of this extension based on user requests. So, what do you want
me to do? Word this differently so that it is clear that this shouldn't
happen for sanely configured mailing lists?

> "   Duplicate messages are normally detected using the Message-ID header
>    field, which is required to be unique for each message.  "
>
> REQUIRED maybe, but I seem to recall the malformed-mail I-D raising the
> possibility that it was not.  In which case, ...?

I'm not sure how common that is, but you are right:  as the
specification is now, that would cause a false positive. We can make the
default a bit more complex by combining the Message-ID  with some other
header (Date perhaps?), thereby further reducing the likelihood of a
false positive. I guess we need to think about that a little more.

> s.3
> "an earlier Sieve execution."
> reading on it is apparent that this is any number of executions limited
> by the size of the FIFO cache and the maximum lifetime of entries in the
> cache.

Yes. So, what exactly is your comment here? I don't think it is useful
to mention such detail early in the description.

> "   Usage:  [":header" <header-name: string> /
>                           ":uniqueid" <value: string>]
>
> Why have two way of doing the same thing?  As I read it, this test is on
> a header field, so why not have just ":header" with a default of message
> I-D?

I am not sure what you mean here. The :uniqueid argument does explicitly
not operate (directly) on a message header, but rather on some string
value composed by the user (using the variables extension). This can
consist of header field contents, but also on message body or even some
source other than the message being delivered.

> And what happens if I use header field X in one execution and then
> header field Y in another? I presume separate caches for X and Y, in
> which case, duplicates may not be detected.

No, there is only one 'cache' (in the document it is called the
duplicate tracking list). See the following text:

 The "duplicate" test MUST track an unique ID value independent of its
 source.  This means that it does not matter whether values are
 obtained from the message ID header, from an arbitrary header
 specified using the ":header" argument or explicitly from the
 ":uniqueid" argument. 

Some examples follow this text. Do you mean that this needs to be
clarified more?

> The use of multiple fields
> opens up all sorts of complications that need more explanation depending
> on the concept of the scope of the operation, which I do not see clearly
> explained.

I am not sure what you mean here. I am assuming this comment is not
relevant given the above. Please clarify otherwise.

> "The user can explicitly control the
>    length of this expiration time by means of the ":seconds" argument,
>    which is always specified in seconds.  "
>
> seconds seems short to me.  On the IETF lists, I typically see a gap of
> several hours between a message on one list and a message on another
> list, with four hours being the norm.  I would regard 5 minutes as the
> minimum and 36 hours, or perhaps less, as the maximum.

Given the vacation-seconds extension, the use of a seconds granularity
is not strange in the Sieve realm.

I like the flexibility of using seconds (mailinglists are not the only
application area of this extension), but I am not against changing it to
:minutes per se. Do any other people have thoughts?

> "By adding the ":header" argument with a message header
>    field name, the content of the specified header field can be used as
> "
>
> Does this apply to all headers? I assume it does, since if message I-D
> is not used, then it would be an X- proprietary one that would seem to
> me to be the next best thing.

Any header can be selected with this argument.

> "   If the tracked unique ID value is extracted directly from a message
>    header field, i.e., when the ":uniqueid" argument is not used,"
>
> you are saying that when uniqueid is not used, then a unique ID is used.
> I think that this will cause confusion here and elsewhere - you need
> another term than 'unique ID' as the collective noun for the identifying
> string you are using in the equality comparison.

Hmm, yeah. Any suggestions? :)

> "leading and trailing whitespace MUST first be trimmed from the value"
>
> This is a can of worms.  Normalisation often appears on these lists
> without, usually, a satisfactory answer, let alone the issues of i18n.
> More needs to be considered here.

This mainly serves as a means to prevent stray white space from messing
with the string match. The core Sieve language also does this for
instance for the header test. And how would i18n be relevant here?

Regards,

Stephan.




From Bert.Greevenbosch@huawei.com  Thu Jan  9 18:50:20 2014
Return-Path: <Bert.Greevenbosch@huawei.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0D811ADFAA for <apps-discuss@ietfa.amsl.com>; Thu,  9 Jan 2014 18:50:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.739
X-Spam-Level: 
X-Spam-Status: No, score=-4.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 XzJAX1J9XPRb for <apps-discuss@ietfa.amsl.com>; Thu,  9 Jan 2014 18:50:18 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D5C501ADFA1 for <apps-discuss@ietf.org>; Thu,  9 Jan 2014 18:50:17 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCI62530; Fri, 10 Jan 2014 02:50:07 +0000 (GMT)
Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 10 Jan 2014 02:49:38 +0000
Received: from SZXEMA406-HUB.china.huawei.com (10.82.72.38) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 10 Jan 2014 02:50:07 +0000
Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.206]) by SZXEMA406-HUB.china.huawei.com ([10.82.72.38]) with mapi id 14.03.0158.001; Fri, 10 Jan 2014 10:50:03 +0800
From: Bert Greevenbosch <Bert.Greevenbosch@huawei.com>
To: "Joe Hildebrand (jhildebr)" <jhildebr@cisco.com>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Thread-Topic: [apps-discuss] New draft: "CBOR data definition language: a notational convention to express CBOR data structures."
Thread-Index: AQHPCzaGHmsshsw4Q8W8K22Y6ECTkZp9MFrw
Date: Fri, 10 Jan 2014 02:50:02 +0000
Message-ID: <46A1DF3F04371240B504290A071B4DB63E3D6B76@SZXEMA510-MBX.china.huawei.com>
References: <CEF08453.34032%jhildebr@cisco.com>
In-Reply-To: <CEF08453.34032%jhildebr@cisco.com>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.66.162.63]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: Re: [apps-discuss] New draft: "CBOR data definition language: a notational convention to express CBOR data structures."
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Jan 2014 02:50:21 -0000

Hi Joe,

Thanks a lot for your feedback. Please find my response inline.

> Interesting.  Based on experience with XML, calling this "schema" may
> set
> the expectation that this information might be used to validate inputs
> or
> generate special-purpose parsers.  Both of these approaches are fraught
> with peril in the real world.  Your requirement G7 in section 2 will
> lead
> people toward the attractive nuisance.

Indeed XML schema is too complex, and I have no intention to develop someth=
ing as complex as that.

I think making the syntax machine processable gives a good chance to define=
 unambiguous data structures. The main goal, however, is to have a way to e=
xpress CBOR data structures in standards.

> I do agree it would be nice to have a consistent ABNF-like mechanism
> for
> specifying CBOR protocols, but the types of protocols you are
> envisioning
> seem to be a little less self-describing than the kinds of JSON
> protocols
> that are more resilient to change over time.  The typical approach for
> these is maps that have a set of keys defined for the first version,
> with
> receivers instructed to ignore any map value they don't understand.  In
> subsequent versions, new map values can be added safely.  Your section
> 4.5
> doesn't have the nuance yet to handle this approach.

Yes, indeed it may make sense to add a notation for map keys, and text abou=
t ignoring unknown keys.

> Sections 4.3-4.5, include simple examples.

I'll add some examples.

> Section 4.4, the idea of structs that don't have corresponding CBOR
> wire
> protocol is odd, except as a mechanism to make the schema syntax more
> readable.  I'm not sure if that's useful enough in practice.

Indeed the mechanism was included for readability.

> Section 4.6, the const type does seem less useful than it is complex to
> me, as you point out at the end of the section.

Yes, its current "const" mechanism certainly is too complex, so there will =
be pruning. I'll think how much of it may make sense to remain, or do you t=
hink we should remove it completely and let protocols define such values in=
 their textual descriptions?

> Section 4.8, optional values seem to me like they're going to cause
> interop problems, particularly if the struct isn't defined in the *
> (array) form.

Indeed that is a problem, as indicated at the end of the section. I see a u=
se for optional fields, so it would be good to express them somehow. The cu=
rrent optional field mechanism, however, does lead to possible ambiguity in=
 the code, and thus possible issues when machine processing the data withou=
t a proper context.

An alternative would indeed be using maps for optional fields, since then t=
he receiver has a hint from the map on the existence of such optional field=
, and can ignore it safely.

However that would lead to more bytes, which may be undesirable depending o=
n the protocol that is being specified, especially when it can already dete=
rmine the availability of the optional field in other ways.

This requires more thought. :-)

> Overall, I think you've got something a little more complicated than it
> could be to solve the slightly smaller problem that is safe (ish) to
> solve.

Thanks again for your feedback. This is just v00 of the draft, so I would b=
e happy to simplify things and reduce complexity.

Best regards,
Bert


> On 1/1/14 11:06 PM, "Bert Greevenbosch" <Bert.Greevenbosch@huawei.com>
> wrote:
>=20
> >Hello all,
> >
> >I have uploaded the following draft:
> >https://datatracker.ietf.org/doc/draft-greevenbosch-appsawg-cbor-cddl/
> >
> >The draft introduces a notation to express CBOR data structures.
> >
> >CBOR has recently been defined in RFC 7049. It is a general binary
> data
> >format, which can be used to encode data in a structural way. Next to
> >general data fields such as "integer" and "string", CBOR also supports
> >signalling
> > of e.g. arrays and maps.
> >
> >RFC 7049 does not define how to write down CBOR data structures in
> >specifications. I think it would be useful to have a standardised way
> for
> >this, hence this new draft.
> >
> >Since there is no working group chartered to do CBOR work, I have
> >uploaded it as input to the general Applications Area working group.
> >
> >I look forward to discussions on this, both technical and
> procedural. :-)
> >
> >I wish you all a happy 2014!
> >
> >Best regards,
> >Bert
> >
> >
>=20
>=20
> --
> Joe Hildebrand
>=20
>=20


From superuser@gmail.com  Fri Jan 10 10:19:21 2014
Return-Path: <superuser@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB2F21AE11F for <apps-discuss@ietfa.amsl.com>; Fri, 10 Jan 2014 10:19:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TBqcFjqBsIYq for <apps-discuss@ietfa.amsl.com>; Fri, 10 Jan 2014 10:19:20 -0800 (PST)
Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id F26A41AE103 for <apps-discuss@ietf.org>; Fri, 10 Jan 2014 10:19:19 -0800 (PST)
Received: by mail-wi0-f171.google.com with SMTP id bz8so8692373wib.16 for <apps-discuss@ietf.org>; Fri, 10 Jan 2014 10:19:09 -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=6pGiTengDbkwHHdT2QkejX7Aw59eSw/1YOOFP56O+74=; b=e413k++YMJ2gWnBhaz/6MH8+sae7t631PnACcW8a/Ms22ECbFkLbdPEHBg9vlzptAw PRwEkyPNGeVRwkUPnk1QDQ7UlnlWDXZBHdOfx4dVVhY8rkxaHdpXQzrHw+wFMPWjw6ty 354Q/b7hotvW6J/VFO/w3jtVsarSBcURHJN7txtCCbX5tNvY72IElyzYMaAkozKOaO9g SmLnI0nQWFPNPbjPfA2CqNFYflEPFIi7RrAM9WwKWZEn1IQTnFmO1LdfoXLDW0WqmjDF jnXjF2u3L2ajMxMqtLCRIudzTUsu6uHqQuV+zi0mJybdqaLRPL+7hBcRZr3O3Cdacrfo Llew==
MIME-Version: 1.0
X-Received: by 10.194.77.7 with SMTP id o7mr9933081wjw.35.1389377949577; Fri, 10 Jan 2014 10:19:09 -0800 (PST)
Received: by 10.180.84.106 with HTTP; Fri, 10 Jan 2014 10:19:09 -0800 (PST)
In-Reply-To: <CAL0qLwZqJPTssNVLLaSjAP5wqteZ==fuawNF+WUZYvi+YWV1UQ@mail.gmail.com>
References: <CAL0qLwZqJPTssNVLLaSjAP5wqteZ==fuawNF+WUZYvi+YWV1UQ@mail.gmail.com>
Date: Fri, 10 Jan 2014 10:19:09 -0800
Message-ID: <CAL0qLwZRGtkERzoY+oxhDdDvTYvp_W4agNb65wPfCdVp17MndA@mail.gmail.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
To: IETF Apps Discuss <apps-discuss@ietf.org>
Content-Type: multipart/alternative; boundary=047d7bfd05fc24b74104efa1c341
Subject: Re: [apps-discuss] REMINDER: Working Group Last Calls still open
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Jan 2014 18:19:22 -0000

--047d7bfd05fc24b74104efa1c341
Content-Type: text/plain; charset=ISO-8859-1

Final day for all of these.  If you've been putting off posting comments or
a review, here's your chance!

-MSK


On Wed, Jan 1, 2014 at 7:05 AM, Murray S. Kucherawy <superuser@gmail.com>wrote:

> Colleagues,
>
> I know many of us are busy or away possibly until next week.  This is just
> a reminder that there are three documents in Working Group Last Call state,
> extended for the holidays.  After two and a half weeks, there has been a
> lot of commentary on one of them, a small amount on a second, and none on
> the third.  Please remember to schedule some time to provide reviews and
> commentary on all of them early in the new year so they can be advanced to
> make room for new work.
>
> The documents are:
>
> draft-ietf-appsawg-sieve-duplicate
> draft-ietf-appsawg-rrvs-header-field
> draft-ietf-appsawg-xml-mediatypes
>
> Happy 2014 to everyone!
>
> -MSK, APPSAWG co-chair
>

--047d7bfd05fc24b74104efa1c341
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Final day for all of these.=A0 If you&#39;ve been put=
ting off posting comments or a review, here&#39;s your chance!<br><br></div=
>-MSK<br></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote=
">On Wed, Jan 1, 2014 at 7:05 AM, Murray S. Kucherawy <span dir=3D"ltr">&lt=
;<a href=3D"mailto:superuser@gmail.com" target=3D"_blank">superuser@gmail.c=
om</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div>Colleagues,<br><b=
r>I know many of us are busy or away possibly until next week.=A0 This is j=
ust a reminder that there are three documents in Working Group Last Call st=
ate, extended for the holidays.=A0 After two and a half weeks, there has be=
en a lot of commentary on one of them, a small amount on a second, and none=
 on the third.=A0 Please remember to schedule some time to provide reviews =
and commentary on all of them early in the new year so they can be advanced=
 to make room for new work.<br>

<br></div><div>The documents are:<br><br></div><div>draft-ietf-appsawg-siev=
e-duplicate<br>draft-ietf-appsawg-rrvs-header-field<br>draft-ietf-appsawg-x=
ml-mediatypes<br><br></div>Happy 2014 to everyone!<br><br></div>-MSK, APPSA=
WG co-chair<br>

</div>
</blockquote></div><br></div>

--047d7bfd05fc24b74104efa1c341--

From internet-drafts@ietf.org  Fri Jan 10 11:20:44 2014
Return-Path: <internet-drafts@ietf.org>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 743881AE1B4; Fri, 10 Jan 2014 11:20:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5HhKl-plaVsI; Fri, 10 Jan 2014 11:20:42 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D99C41AE1C8; Fri, 10 Jan 2014 11:20:36 -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.90.p2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140110192036.17904.85697.idtracker@ietfa.amsl.com>
Date: Fri, 10 Jan 2014 11:20:36 -0800
Cc: apps-discuss@ietf.org
Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-rrvs-header-field-06.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Jan 2014 19:20:44 -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 an=
d SMTP Service Extension
        Authors         : William J. Mills
                          Murray S. Kucherawy
	Filename        : draft-ietf-appsawg-rrvs-header-field-06.txt
	Pages           : 22
	Date            : 2014-01-10

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-06

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-rrvs-header-field-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 superuser@gmail.com  Fri Jan 10 11:23:45 2014
Return-Path: <superuser@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C7121AE0CC for <apps-discuss@ietfa.amsl.com>; Fri, 10 Jan 2014 11:23: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 hiJrxALdAxEG for <apps-discuss@ietfa.amsl.com>; Fri, 10 Jan 2014 11:23:43 -0800 (PST)
Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 7045C1ADFF3 for <apps-discuss@ietf.org>; Fri, 10 Jan 2014 11:23:43 -0800 (PST)
Received: by mail-wi0-f175.google.com with SMTP id hi5so23985wib.8 for <apps-discuss@ietf.org>; Fri, 10 Jan 2014 11:23:33 -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=9ss8XANlo8D7pxqMkf/r8I4BJdjJT9N5G1s1yaiY89E=; b=RnRcYkrHcgiL4uLzWX7EBPeuGqUbmdGa42GD5OFNoQwUjGWJKzRurnoclo9wVpmPis ipqtLBQ5QwGxI8JYp2h94ijjrmSsAfs6a4vBNyq7FVMub2yltBHTQkfDeh46yyc6tYFo pJDYG0Vax9khRgdzHslWfzilVwT41iS1VH8lw6cwEBCqtdG4rkVmC4YYNIdHJqtFkEV5 tF1Jm1oXouM+KVU8QHNZWoT2M+wWniK7aoidNkT6lfwr5ErhuqDGDayEkU+eB5rpNuTs jlR4YNm2fdjUsPKsXjJm4LrKgc20Y2nQXyeWucNaSuvcVj/cKNgnazRil/S3vSSEMLZj Gu1g==
MIME-Version: 1.0
X-Received: by 10.180.108.240 with SMTP id hn16mr4211299wib.5.1389381812896; Fri, 10 Jan 2014 11:23:32 -0800 (PST)
Received: by 10.180.84.106 with HTTP; Fri, 10 Jan 2014 11:23:32 -0800 (PST)
In-Reply-To: <20140110192036.17904.85697.idtracker@ietfa.amsl.com>
References: <20140110192036.17904.85697.idtracker@ietfa.amsl.com>
Date: Fri, 10 Jan 2014 11:23:32 -0800
Message-ID: <CAL0qLwawqPZoqjP6QjPQW4MW-n-8zd9hobWHU1WnFER+4LZ0PQ@mail.gmail.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
To: IETF Apps Discuss <apps-discuss@ietf.org>
Content-Type: multipart/alternative; boundary=e89a8f234c596a49e004efa2a944
Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rrvs-header-field-06.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Jan 2014 19:23:45 -0000

--e89a8f234c596a49e004efa2a944
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Jan 10, 2014 at 11:20 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
>         Authors         : William J. Mills
>                           Murray S. Kucherawy
>         Filename        : draft-ietf-appsawg-rrvs-header-field-06.txt
>         Pages           : 22
>         Date            : 2014-01-10
>
> 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 the results of the WGLC feedback.  Thanks to all of those who
chimed in!

-MSK

--e89a8f234c596a49e004efa2a944
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Fri, Jan 10, 2014 at 11:20 AM,  <span dir=3D"ltr">&lt;<=
a href=3D"mailto:internet-drafts@ietf.org" target=3D"_blank">internet-draft=
s@ietf.org</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=
=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br>
A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.<br>
=A0This draft is a work item of the Applications Area Working Group Working=
 Group of the IETF.<br>
<br>
=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : The Require-Recipient-Valid-Sin=
ce Header Field and SMTP Service Extension<br>
=A0 =A0 =A0 =A0 Authors =A0 =A0 =A0 =A0 : William J. Mills<br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Murray S. Kucherawy<br>
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-appsawg-rrvs-header-fi=
eld-06.txt<br>
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 22<br>
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2014-01-10<br>
<br>
Abstract:<br>
=A0 =A0This document defines an extension for the Simple Mail Transfer<br>
=A0 =A0Protocol called RRVS, and a header field called Require-Recipient-<b=
r>
=A0 =A0Valid-Since, to provide a method for senders to indicate to receiver=
s<br>
=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,=
<br>
=A0 =A0and thus prevent mail from being delivered to the wrong party.<br>
<br>
=A0 =A0The intended use of these facilities is on automatically generated<b=
r>
=A0 =A0messages that might contain sensitive information, though it may als=
o<br>
=A0 =A0be useful in other applications.<br>
<br></blockquote><div><br></div><div>Incorporates the results of the WGLC f=
eedback.=A0 Thanks to all of those who chimed in!<br><br></div><div>-MSK <b=
r></div></div></div></div>

--e89a8f234c596a49e004efa2a944--

From masinter@adobe.com  Fri Jan 10 13:30:18 2014
Return-Path: <masinter@adobe.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F14981AE1C0 for <apps-discuss@ietfa.amsl.com>; Fri, 10 Jan 2014 13:30:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TRjvCQ8BGP9Z for <apps-discuss@ietfa.amsl.com>; Fri, 10 Jan 2014 13:30:16 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0243.outbound.protection.outlook.com [207.46.163.243]) by ietfa.amsl.com (Postfix) with ESMTP id 02E461AE1BC for <apps-discuss@ietf.org>; Fri, 10 Jan 2014 13:30:15 -0800 (PST)
Received: from BLUPR02MB312.namprd02.prod.outlook.com (10.141.77.153) by BLUPR02MB309.namprd02.prod.outlook.com (10.141.77.140) with Microsoft SMTP Server (TLS) id 15.0.851.11; Fri, 10 Jan 2014 21:30:05 +0000
Received: from BLUPR02MB312.namprd02.prod.outlook.com ([10.141.77.153]) by BLUPR02MB312.namprd02.prod.outlook.com ([10.141.77.153]) with mapi id 15.00.0842.003; Fri, 10 Jan 2014 21:30:05 +0000
From: Larry Masinter <masinter@adobe.com>
To: "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Thread-Topic: draft-ietf-appsawg-xml-mediatypes-06: recommendation on file suffixes
Thread-Index: Ac8OSxT6MCKvizD5SjqTW2BWsD+tGA==
Date: Fri, 10 Jan 2014 21:30:04 +0000
Message-ID: <d46fbe152f6940d998370eb12fefabbd@BL2PR02MB307.namprd02.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.150.10.203]
x-forefront-prvs: 00872B689F
x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(189002)(199002)(53806001)(83322001)(74876001)(46102001)(51856001)(80976001)(81686001)(81342001)(47736001)(47976001)(50986001)(49866001)(85306002)(81542001)(77982001)(59766001)(79102001)(81816001)(69226001)(56776001)(4396001)(76786001)(76576001)(76176001)(92566001)(87936001)(76796001)(93136001)(87266001)(33646001)(2656002)(83072002)(85852003)(56816005)(74706001)(90146001)(54356001)(63696002)(76482001)(74316001)(74366001)(31966008)(54316002)(66066001)(80022001)(74502001)(47446002)(74662001)(65816001)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR02MB309; H:BLUPR02MB312.namprd02.prod.outlook.com; CLIP:192.150.10.203; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: adobe.com
Subject: [apps-discuss] draft-ietf-appsawg-xml-mediatypes-06: recommendation on file suffixes
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Jan 2014 21:30:18 -0000

Other than changing the recommendation of UTF-8, my other comments are mino=
r:




   XML MIME producers are RECOMMENDED to provide means for XML MIME
   entity authors to determine what value, if any, is given to charset
   parameters for their entities, for example by enabling user-level
   configuration of filename-to-Content-Type-header mappings on a file-
   by-file or suffix basis.

The example really needs recommendation not just for producers,
but also for consumers that store received XML in a file system.

  Receiver -> file system
  File system -> sender

and you recommend that the "file system" link be enhanced to
remember charset if it isn't UTF-8.

For this purpose you could recommend that the file suffix ".xml"
 be reserved for UTF-8 encoded XML and use separate file extensions
For XML encoded in any other charset. =20



From masinter@adobe.com  Fri Jan 10 13:33:07 2014
Return-Path: <masinter@adobe.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74E7E1AE1E0 for <apps-discuss@ietfa.amsl.com>; Fri, 10 Jan 2014 13:33: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, 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 AK0uvZIFdWgh for <apps-discuss@ietfa.amsl.com>; Fri, 10 Jan 2014 13:33:05 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0185.outbound.protection.outlook.com [207.46.163.185]) by ietfa.amsl.com (Postfix) with ESMTP id 056DF1AE1D4 for <apps-discuss@ietf.org>; Fri, 10 Jan 2014 13:33:03 -0800 (PST)
Received: from BLUPR02MB312.namprd02.prod.outlook.com (10.141.77.153) by BLUPR02MB311.namprd02.prod.outlook.com (10.141.77.150) with Microsoft SMTP Server (TLS) id 15.0.851.11; Fri, 10 Jan 2014 21:32:53 +0000
Received: from BLUPR02MB312.namprd02.prod.outlook.com ([10.141.77.153]) by BLUPR02MB312.namprd02.prod.outlook.com ([10.141.77.153]) with mapi id 15.00.0842.003; Fri, 10 Jan 2014 21:32:53 +0000
From: Larry Masinter <masinter@adobe.com>
To: "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Thread-Topic: draft-ietf-appsawg-xml-mediatypes-06: security considerations
Thread-Index: Ac8OS1DzeeNduZywQnKxy+6Ijectkw==
Date: Fri, 10 Jan 2014 21:32:52 +0000
Message-ID: <be73a33eb7bb4a6fb08a7df7bf9b5276@BLUPR02MB312.namprd02.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.150.10.203]
x-forefront-prvs: 00872B689F
x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(189002)(199002)(53806001)(83322001)(74876001)(46102001)(51856001)(80976001)(558084003)(81686001)(81342001)(47736001)(47976001)(50986001)(49866001)(85306002)(81542001)(77982001)(59766001)(79102001)(81816001)(69226001)(56776001)(4396001)(76786001)(76576001)(76176001)(92566001)(87936001)(76796001)(93136001)(87266001)(33646001)(2656002)(83072002)(85852003)(56816005)(74706001)(90146001)(54356001)(63696002)(76482001)(74316001)(74366001)(31966008)(54316002)(66066001)(80022001)(74502001)(47446002)(74662001)(65816001)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR02MB311; H:BLUPR02MB312.namprd02.prod.outlook.com; CLIP:192.150.10.203; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: adobe.com
Subject: Re: [apps-discuss] draft-ietf-appsawg-xml-mediatypes-06: security considerations
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Jan 2014 21:33:07 -0000

minor comment:

The examples in security considerations, inherited from the previous
document, seem contrived. Henry suggested privately that perhaps mentioning
entity spoofing of various sorts might be in order?

Larry


From sm@elandsys.com  Fri Jan 10 15:59:38 2014
Return-Path: <sm@elandsys.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D69F1AE0E2 for <apps-discuss@ietfa.amsl.com>; Fri, 10 Jan 2014 15:59:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.328
X-Spam-Level: 
X-Spam-Status: No, score=-2.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.538, T_DKIM_INVALID=0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oBTGqt8maFrx for <apps-discuss@ietfa.amsl.com>; Fri, 10 Jan 2014 15:59:36 -0800 (PST)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id B442B1AE0BF for <apps-discuss@ietf.org>; Fri, 10 Jan 2014 15:59:36 -0800 (PST)
Received: from SUBMAN.elandsys.com ([197.224.128.22]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s0ANxB10008849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Jan 2014 15:59:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1389398365; bh=ub4ioPGg3hkaMnvxIgw+967Zv/hRHNEJdao9yyj0Jl0=; h=Date:To:From:Subject:Cc; b=rI00jUNXOklbXOryEPBTWAZhbk1jf7u3BFuB2cFB17Vi5dcrfWpr69G8P78tjRaYx Xn8lg46K5P4idrUZS6IkkS+pzMCB9vYY8FGQfSg7hLVMiNpYrnjKm7kn7hyZiUdq2y BWd/zhc027n1peWUpo2qTHQhsXndtvvSJqDFHg8Y=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1389398365; i=@elandsys.com; bh=ub4ioPGg3hkaMnvxIgw+967Zv/hRHNEJdao9yyj0Jl0=; h=Date:To:From:Subject:Cc; b=h3v5r+IDNzJpEeR0CTbEDm1miuX84/8Lp96UuA1Domi5BSJs6Hlg1SBhpUBthCuwk xusYDo3APKjbMOOlFRDDwpXbEc4EwijnqXpO+4VfKjnNgYVUd6doYCMioGaTW+c+8V kExyGPTDsPmMZAmuu6J1fO05rvvk+mpZoJkIfR8Y=
Message-Id: <6.2.5.6.2.20140110142955.0ac73048@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Fri, 10 Jan 2014 15:57:23 -0800
To: "Henry S. Thompson" <ht@inf.ed.ac.uk>, Chris Lilley <chris@w3.org>
From: S Moonesamy <sm+ietf@elandsys.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: apps-discuss@ietf.org
Subject: [apps-discuss] Comments on draft-ietf-appsawg-xml-mediatypes-06
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Jan 2014 23:59:38 -0000

Hi Henry,

I have a few comments on draft-ietf-appsawg-xml-mediatypes-06.

In Section 3.1:

   "XML-unaware MIME producers MUST NOT supply a charset parameter with
    an XML MIME entity unless the entity's character encoding is reliably
    known."

The title of that section is "XML MIME producers".  The above states 
a (RFC 2119) requirement for a "XML-unaware MIME producer".  Can an 
agent which is not capable of processing XML MIME entities and 
detecting the XML encoding declaration follow the requirement, and 
does the requirement even apply given that the requirements being 
specified are for XML MIME producers?

As a nit, the unless clause in the requirement (sentence) seems 
odd.  It may be simpler to set requirements for "XML-aware" MIME 
producers only.

   "XML MIME producers are RECOMMENDED to provide means for XML MIME
    entity authors to determine what value, if any, is given to charset
    parameters for their entities, for example by enabling user-level
    configuration of filename-to-Content-Type-header mappings on a file-
    by-file or suffix basis."

The "entity authors" in the above is not clear.  Is it a person or an agent?

   "The use of UTF-32 is NOT RECOMMENDED for XML MIME entities."

I suggest having a short explanation about why the use of UTF-32 is 
not recommended instead of only saying that it is not recommended.

   "XML-aware consumers MUST follow the requirements in section 4.3.3
    of [XML] that directly address this case."

This is a requirement by reference to an external specification.  I 
am listing this as it is unusual.

   "XML-unaware MIME consumers SHOULD NOT assume a default encoding in
   this case."

Would a XML-unaware MIME consumer be following this specification?

In Section 4.2:

   'Interoperability considerations:  XML has proven to be interoperable
       across both generic and task-specific applications and for import
       and export from multiple XML authoring and editing tools.
       Validating processors provide maximum interoperability.  Although
       non-validating processors may be more efficient, they are not
       required to handle all features of XML.  For further information,
       see sub-section 2.9 "Standalone Document Declaration" and section
       5 "Conformance" of [XML].'

The paragraph is about interoperability considerations.  The text 
comes out as saying that "XML is great". :-)  Are there any 
interoperability issues to consider?  That's what the reader might 
wish to know.

In Section 8.1:

   "Media subtypes that do not represent XML MIME entities
    MUST NOT be allowed to register with a '+xml' suffix."

It would be easier to say that the "+xml" suffix can only be 
registered for media subtypes that represent XML MIME entities.

Section 8.1 is about IANA registrations.  I would read it as guidance 
for IANA and people requesting a registration.  I suggest phrasing 
the relevant text from that perspective and moving that text into the 
IANA Considerations section.

In Section 8.3:

   'Registrations for new XML-based media types which do _not_ use the
    '+xml' suffix SHOULD, in specifying the charset parameter and
    encoding considerations, define them as: "Same as [charset parameter
    / encoding considerations] of application/xml as specified in RFC
    XXXX."'

Why is this a RFC 2119 "should"?

   "These registrations SHOULD also make reference to RFC XXXX in
    specifying magic numbers, base URIs, and use of the BOM."

I suggest rephrasing this as guidance and not as a RFC 2119 
recommendation.  Please note that I do not have a strong opinion 
about this as it may be a matter of style.


   "These registrations MAY reference the application/xml registration in
    RFC XXXX in specifying interoperability and fragment identifier
    considerations, if these considerations are not overridden by issues
    specific to that media type."

Why is this a RFC 2119 "may"?

I suggest moving the examples in Section 9 to an appendix.

Regards,
S. Moonesamy


From mark@coactus.com  Fri Jan 10 18:29:43 2014
Return-Path: <mark@coactus.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD371ADBD0 for <apps-discuss@ietfa.amsl.com>; Fri, 10 Jan 2014 18:29:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.177
X-Spam-Level: *
X-Spam-Status: No, score=1.177 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, FRT_ADOBE2=2.455, 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 gjcxef_dEX54 for <apps-discuss@ietfa.amsl.com>; Fri, 10 Jan 2014 18:29:42 -0800 (PST)
Received: from mail-pd0-f169.google.com (mail-pd0-f169.google.com [209.85.192.169]) by ietfa.amsl.com (Postfix) with ESMTP id 5C2F31ADBCA for <apps-discuss@ietf.org>; Fri, 10 Jan 2014 18:29:42 -0800 (PST)
Received: by mail-pd0-f169.google.com with SMTP id v10so5317630pde.0 for <apps-discuss@ietf.org>; Fri, 10 Jan 2014 18:29: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:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=pUryKFR9POMTHvqOfoRVEh3UTjONBeI/ehwFWN1eDQ8=; b=Nx7k9fnyaJtLnyTN6cvuv/5mLnoNtM0csUltO3AnF+Bp3qPyQRlX4YG+IX7wHCo09n mM9UwOhmH3rC+DiFEuNFh+oGHH/IxR5e7EeKrpKYvbC6WfICvp5iSRTADSVby3/jDMrB q4KdpM/GJhER8eVqadqYbmaYNc2WGueIeMv9v2SOoF9/X1XO35Az20gfwPcHVgjFEeCV QTLYhwD2O+GhSrPgzb7NMxjCscloQoo0VqdMrJa2t1yyqB/uD5V7USh28pM1r2wePXKM PqN6yD/RIHJq/rJOjyL2hklfW6fQH1Rem1JQ7CPhhqpRB5gfDBjvr7lZxgzFkm/fZsZL LBjw==
X-Gm-Message-State: ALoCoQlAxO0z6pY2HZH2nyMr8GcgWW1elcch8v0zDVDVI4hnOv7wEbtp7OwVpdXjH8amLXQ6xDqL
MIME-Version: 1.0
X-Received: by 10.66.219.8 with SMTP id pk8mr15760788pac.28.1389407372386; Fri, 10 Jan 2014 18:29:32 -0800 (PST)
Sender: mark@coactus.com
Received: by 10.70.103.177 with HTTP; Fri, 10 Jan 2014 18:29:32 -0800 (PST)
X-Originating-IP: [192.0.216.13]
In-Reply-To: <d46fbe152f6940d998370eb12fefabbd@BL2PR02MB307.namprd02.prod.outlook.com>
References: <d46fbe152f6940d998370eb12fefabbd@BL2PR02MB307.namprd02.prod.outlook.com>
Date: Fri, 10 Jan 2014 21:29:32 -0500
X-Google-Sender-Auth: _KVGUMfL_2QELjCYhRCp3UAQzWo
Message-ID: <CALcoZiqiw5Qhhe33Pd+n_r+1+VDyuZsp_TSuYoRrpSch5JQDhA@mail.gmail.com>
From: Mark Baker <distobj@acm.org>
To: Larry Masinter <masinter@adobe.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] draft-ietf-appsawg-xml-mediatypes-06: recommendation on file suffixes
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 11 Jan 2014 02:29:43 -0000

On Fri, Jan 10, 2014 at 4:30 PM, Larry Masinter <masinter@adobe.com> wrote:
> The example really needs recommendation not just for producers,
> but also for consumers that store received XML in a file system.
>
>   Receiver -> file system
>   File system -> sender
>
> and you recommend that the "file system" link be enhanced to
> remember charset if it isn't UTF-8.
>
> For this purpose you could recommend that the file suffix ".xml"
>  be reserved for UTF-8 encoded XML and use separate file extensions
> For XML encoded in any other charset.

A problem I see with that is that it's lossy; in many (most?) cases a
+xml type will be inbound, and .xml is associated with
application/xml.

I agree that more specific guidance would be useful, but I'm not sure
what it could be.

Mark.

From ietfc@btconnect.com  Sat Jan 11 04:49:33 2014
Return-Path: <ietfc@btconnect.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E3DB1AD8E2 for <apps-discuss@ietfa.amsl.com>; Sat, 11 Jan 2014 04:49:33 -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_15=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 Tq2DRJ9TX9iz for <apps-discuss@ietfa.amsl.com>; Sat, 11 Jan 2014 04:49:30 -0800 (PST)
Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0188.outbound.messaging.microsoft.com [213.199.154.188]) by ietfa.amsl.com (Postfix) with ESMTP id A48BC1ADE86 for <apps-discuss@ietf.org>; Sat, 11 Jan 2014 04:49:29 -0800 (PST)
Received: from mail158-db8-R.bigfish.com (10.174.8.242) by DB8EHSOBE035.bigfish.com (10.174.4.98) with Microsoft SMTP Server id 14.1.225.22; Sat, 11 Jan 2014 12:49:18 +0000
Received: from mail158-db8 (localhost [127.0.0.1])	by mail158-db8-R.bigfish.com (Postfix) with ESMTP id 71DFEA03A1;	Sat, 11 Jan 2014 12:49:18 +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: -17
X-BigFish: PS-17(zzbb2dI98dI9371I542I1432I1418Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h20f7h2189h1d1ah1d2ah1fc6hzz1de098h1033IL8275bh8275dh1de097hz2dh2a8h5a9h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah2222h224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h2218h2216h226dh22d0h2327h2336h2438h2461h304l1d11m1155h)
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(479174003)(199002)(13464003)(51444003)(189002)(51704005)(377454003)(24454002)(85306002)(83322001)(80976001)(19580395003)(19580405001)(88136002)(87286001)(87266001)(87976001)(83072002)(89996001)(85852003)(92566001)(90146001)(56816005)(92726001)(31966008)(44736004)(46102001)(53806001)(51856001)(50986001)(47976001)(49866001)(47736001)(74502001)(93136001)(47446002)(74662001)(50226001)(4396001)(42186004)(76482001)(77156001)(61296002)(74366001)(77096001)(62966002)(54316002)(59766001)(77982001)(81542001)(63696002)(66066001)(56776001)(65816001)(74876001)(80022001)(81342001)(69226001)(47776003)(84392001)(23756003)(14496001)(74706001)(50466002)(79102001)(62236002)(44716002)(76796001)(76786001)(33646001)(74416001)(7726001); DIR:OUT; SFP:1101; SCL:1; SRVR:AMXPR07MB053; H:DBXPRD0611HT002.eurprd06.prod.outlook.com; CLIP:157.56.254.85; FPR:; RD:InfoNoRecords; A:0; MX:1; LANG:en; 
Received: from mail158-db8 (localhost.localdomain [127.0.0.1]) by mail158-db8 (MessageSwitch) id 1389444556153450_26698; Sat, 11 Jan 2014 12:49:16 +0000 (UTC)
Received: from DB8EHSMHS032.bigfish.com (unknown [10.174.8.235])	by mail158-db8.bigfish.com (Postfix) with ESMTP id 1F6B94C004A; Sat, 11 Jan 2014 12:49:16 +0000 (UTC)
Received: from AM2PRD0710HT002.eurprd07.prod.outlook.com (157.56.249.213) by DB8EHSMHS032.bigfish.com (10.174.4.42) with Microsoft SMTP Server (TLS) id 14.16.227.3; Sat, 11 Jan 2014 12:49:15 +0000
Received: from AMXPR07MB053.eurprd07.prod.outlook.com (10.242.67.142) by AM2PRD0710HT002.eurprd07.prod.outlook.com (10.255.165.37) with Microsoft SMTP Server (TLS) id 14.16.395.1; Sat, 11 Jan 2014 12:49:15 +0000
Received: from DBXPRD0611HT002.eurprd06.prod.outlook.com (157.56.254.85) by AMXPR07MB053.eurprd07.prod.outlook.com (10.242.67.142) with Microsoft SMTP Server (TLS) id 15.0.851.11; Sat, 11 Jan 2014 12:49:13 +0000
Message-ID: <005501cf0eca$faf86840$4001a8c0@gateway.2wire.net>
From: t.petch <ietfc@btconnect.com>
To: Stephan Bosch <stephan@rename-it.nl>, "Murray S. Kucherawy" <superuser@gmail.com>, IETF Apps Discuss <apps-discuss@ietf.org>
References: <CAL0qLwZqJPTssNVLLaSjAP5wqteZ==fuawNF+WUZYvi+YWV1UQ@mail.gmail.com> <00a301cf07e8$01352160$4001a8c0@gateway.2wire.net> <52CF384D.3080502@rename-it.nl>
Date: Sat, 11 Jan 2014 12:45:07 +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.254.85]
X-ClientProxiedBy: DB4PR07CA013.eurprd07.prod.outlook.com (10.242.229.23) To AMXPR07MB053.eurprd07.prod.outlook.com (10.242.67.142)
X-Forefront-PRVS: 0088C92887
X-OriginatorOrg: btconnect.com
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
Subject: Re: [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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 11 Jan 2014 12:49:33 -0000

Mostly inline, but my big comment which gets lost in the detail is about
scope of caches.  You say
"there is only one 'cache' (in the document it is called the duplicate
tracking list)"

Really, worldwide, like the DNS root?-)

Hitherto, as I understand it, sieve has had no state; a filter is
applied to a stream of messages and that is it, forget it and start
again.  This adds state.  This then introduces the question of scope.
If I get the same message from two different ISP (which I  do), will
that be detected?  I expect not.  When those ISP outsource their MX to
the same third party, will that be detected?  I expect not as long as
they have different mail domains.  At what point is there a single
cache?  When I used multiple mailboxes for the same mail domain?  Only
when I use a specific  mailbox? or when?

In a sense it does not matter because it only effects the user
experience and not the protocol on the wire, but I expect that users
will care if the implementation on ISP A gives totally different results
to ISP B.  And of course, when there is more than one cache (worldwide
:-), then operators of this facility will need more resources to
maintain them.

Tom Petch

----- Original Message -----
From: "Stephan Bosch" <stephan@rename-it.nl>
To: "t.petch" <ietfc@btconnect.com>; "Murray S. Kucherawy"
<superuser@gmail.com>; "IETF Apps Discuss" <apps-discuss@ietf.org>
Sent: Friday, January 10, 2014 12:01 AM
> On 1/2/2014 7:24 PM, t.petch wrote:
> > This I-D seems to need more thought.
> >
> > s.1 "For example, if a member of the list decides to
> >    reply to both the user and the mailing list itself, the user will
> >    one copy of the message directly and another through the mailing
> >    list.
> >
> > Well, they MAY, but they don't on a good list system, such as the
one in
> > use here.
> >
> > "Also, if someone cross-posts over several mailing lists to
> >    which the user is subscribed, the user will receive a copy from
each
> >    of those lists."
> >
> > Ditto, not here.
>
> Ok, but these situations are quite common. I've implemented an earlier
> version of this extension based on user requests. So, what do you want
> me to do? Word this differently so that it is clear that this
shouldn't
> happen for sanely configured mailing lists?

I found the 'will' too forceful; my instant reaction was 'no it won't'
because that is my experience.  Just moderate it slightly, 'will often'
'may' 'commonly'-  just not a somewhat forceful 'will'

> > "   Duplicate messages are normally detected using the Message-ID
header
> >    field, which is required to be unique for each message.  "
> >
> > REQUIRED maybe, but I seem to recall the malformed-mail I-D raising
the
> > possibility that it was not.  In which case, ...?
>
> I'm not sure how common that is, but you are right:  as the
> specification is now, that would cause a false positive. We can make
the
> default a bit more complex by combining the Message-ID  with some
other
> header (Date perhaps?), thereby further reducing the likelihood of a
> false positive. I guess we need to think about that a little more.

Yes, I think you should allow for the possibility in the I-D - as to
how, I am less fussed.  Could be 'outside the scope of' up to 'should
detect duplicates and discard as malformed' - just show that it has been
considered.

> > s.3
> > "an earlier Sieve execution."
> > reading on it is apparent that this is any number of executions
limited
> > by the size of the FIFO cache and the maximum lifetime of entries in
the
> > cache.
>
> Yes. So, what exactly is your comment here? I don't think it is useful
> to mention such detail early in the description.
>
> > "   Usage:  [":header" <header-name: string> /
> >                           ":uniqueid" <value: string>]
> >
> > Why have two way of doing the same thing?  As I read it, this test
is on
> > a header field, so why not have just ":header" with a default of
message
> > I-D?
>
> I am not sure what you mean here. The :uniqueid argument does
explicitly
> not operate (directly) on a message header, but rather on some string
> value composed by the user (using the variables extension). This can
> consist of header field contents, but also on message body or even
some
> source other than the message being delivered.

If I understand it aright, the test for duplication can be on
 - message id
 - header field
 - something else
which are invoked by <nothing>, :header, :unique-id respectively.
Since message id is just another header field, why not merge the first
two with the message id as the default header field if none other is
specified?

> > And what happens if I use header field X in one execution and then
> > header field Y in another? I presume separate caches for X and Y, in
> > which case, duplicates may not be detected.
>
> No, there is only one 'cache' (in the document it is called the
> duplicate tracking list). See the following text:
>
>  The "duplicate" test MUST track an unique ID value independent of its
>  source.  This means that it does not matter whether values are
>  obtained from the message ID header, from an arbitrary header
>  specified using the ":header" argument or explicitly from the
>  ":uniqueid" argument.

see above


> Some examples follow this text. Do you mean that this needs to be
> clarified more?
>
> > The use of multiple fields
> > opens up all sorts of complications that need more explanation
depending
> > on the concept of the scope of the operation, which I do not see
clearly
> > explained.
>
> I am not sure what you mean here. I am assuming this comment is not
> relevant given the above. Please clarify otherwise.
>
> > "The user can explicitly control the
> >    length of this expiration time by means of the ":seconds"
argument,
> >    which is always specified in seconds.  "
> >
> > seconds seems short to me.  On the IETF lists, I typically see a gap
of
> > several hours between a message on one list and a message on another
> > list, with four hours being the norm.  I would regard 5 minutes as
the
> > minimum and 36 hours, or perhaps less, as the maximum.
>
> Given the vacation-seconds extension, the use of a seconds granularity
> is not strange in the Sieve realm.
>
> I like the flexibility of using seconds (mailinglists are not the only
> application area of this extension), but I am not against changing it
to
> :minutes per se. Do any other people have thoughts?

Ok but I just got a duplicate, once via the ietf announce list, once via
the ietf main list, and they were 10 hours apart.  For me, this is
typical, hours not seconds.

> > "By adding the ":header" argument with a message header
> >    field name, the content of the specified header field can be used
as
> > "
> >
> > Does this apply to all headers? I assume it does, since if message
I-D
> > is not used, then it would be an X- proprietary one that would seem
to
> > me to be the next best thing.
>
> Any header can be selected with this argument.
>
> > "   If the tracked unique ID value is extracted directly from a
message
> >    header field, i.e., when the ":uniqueid" argument is not used,"
> >
> > you are saying that when uniqueid is not used, then a unique ID is
used.
> > I think that this will cause confusion here and elsewhere - you need
> > another term than 'unique ID' as the collective noun for the
identifying
> > string you are using in the equality comparison.
>
> Hmm, yeah. Any suggestions? :)

No good ones:-)  'identifier' ' message identifier'  just something that
is visually different from unique-id so preferably not incorporating
'unique'.

> > "leading and trailing whitespace MUST first be trimmed from the
value"
> >
> > This is a can of worms.  Normalisation often appears on these lists
> > without, usually, a satisfactory answer, let alone the issues of
i18n.
> > More needs to be considered here.
>
> This mainly serves as a means to prevent stray white space from
messing
> with the string match. The core Sieve language also does this for
> instance for the header test. And how would i18n be relevant here?

Read RFC6532; that you have not referenced it makes me think that you
have not considered i18n which I would regard as remiss nowadays.

> Regards,
>
> Stephan.



From jan.algermissen@nordsc.com  Sat Jan 11 05:13:14 2014
Return-Path: <jan.algermissen@nordsc.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79B5C1ADF78 for <apps-discuss@ietfa.amsl.com>; Sat, 11 Jan 2014 05:13:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level: 
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 f8LPfTbP_bLy for <apps-discuss@ietfa.amsl.com>; Sat, 11 Jan 2014 05:13:13 -0800 (PST)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by ietfa.amsl.com (Postfix) with ESMTP id 0C4A91ADBE5 for <apps-discuss@ietf.org>; Sat, 11 Jan 2014 05:13:13 -0800 (PST)
Received: from [192.168.2.103] (p548FAD76.dip0.t-ipconnect.de [84.143.173.118]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0LbxSO-1Vcqpm1NLw-00jhHd; Sat, 11 Jan 2014 14:13:02 +0100
From: Jan Algermissen <jan.algermissen@nordsc.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <7379B6E3-33DE-40BA-9BA8-258FD12FBFBC@nordsc.com>
Date: Sat, 11 Jan 2014 14:13:01 +0100
To: "apps-discuss@ietf.org Discuss" <apps-discuss@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
X-Mailer: Apple Mail (2.1510)
X-Provags-ID: V02:K0:aWHJkXTn4dkLetIFqm53oBuQnxL0WXPXey0UPl5l3ul oCafA3xCIPCDHILslFoBsYyC0GbaCjJWBzpxbzd0VY6RIcF4NY rjq3Qij18pr67cxD1X7hAOC7dd9kb23LLa3/mZb9yoHgTeWme0 fIha4q3LBl1Fq8m+wr99b1wdsMcFT74MsdJxSaJ5axn2g6wMBj WyaaAwxJJQWE8Pu7M4V1DTVqa5iRyhn65/oqagcgI510LVXhnN SdpBeZWJ4bCGOFrHI/GLwwIgcdnUBWeTP+IOdXOzANLjifquLH 3bf8cFKcKLbR35mgxrMiW250ECqlxUTMsrWyL8hYE19EFALPWO IDEP9p1ZAKp1VS/UUKxZHybkprG/pSVnbOTBYFE2PhVydafrUN 96WimxXV8wPaQ==
Subject: [apps-discuss] JSON-Home and application/json-home
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 11 Jan 2014 13:13:14 -0000

Mark,

might be obvious, but it just occurred to me that application/json-home =
is essentially a format to represent lists of links and/or =
link-templates.

(It occurred to me because I found that a discovery format that I am =
experimentally crafting actually looked like application/json-home :-)

This probably raises the question whether the application behind your =
JSON-Home I-D[1] should actually be reflected in the media type name?

Not that I am suggesting this change, but maybe it is stimulating to =
chew on the idea of renaming

  application/json-home

to

  application/links  or application/resourceinfo or whatever. You get =
the idea I guess.

Jan


[1] http://tools.ietf.org/html/draft-nottingham-json-home-03=

From jan.algermissen@nordsc.com  Sat Jan 11 05:22:21 2014
Return-Path: <jan.algermissen@nordsc.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19FF11AD9AC for <apps-discuss@ietfa.amsl.com>; Sat, 11 Jan 2014 05:22:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level: 
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 VKR4uaQTT2su for <apps-discuss@ietfa.amsl.com>; Sat, 11 Jan 2014 05:22:20 -0800 (PST)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by ietfa.amsl.com (Postfix) with ESMTP id AF94E1AD8CD for <apps-discuss@ietf.org>; Sat, 11 Jan 2014 05:22:19 -0800 (PST)
Received: from [192.168.2.103] (p548FAD76.dip0.t-ipconnect.de [84.143.173.118]) by mrelayeu.kundenserver.de (node=mrbap3) with ESMTP (Nemesis) id 0MgNZW-1VhZaQ3Wf0-00O0IG; Sat, 11 Jan 2014 14:22:08 +0100
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jan Algermissen <jan.algermissen@nordsc.com>
In-Reply-To: <7379B6E3-33DE-40BA-9BA8-258FD12FBFBC@nordsc.com>
Date: Sat, 11 Jan 2014 14:22:08 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <06AD293F-76CE-4472-83A9-A35D3C0E2FAE@nordsc.com>
References: <7379B6E3-33DE-40BA-9BA8-258FD12FBFBC@nordsc.com>
To: "apps-discuss@ietf.org Discuss" <apps-discuss@ietf.org>
X-Mailer: Apple Mail (2.1510)
X-Provags-ID: V02:K0:GPOIe+/1clIyvKGR+YETGRXVHdDqslqUeSH8o1mVsRa DQVzQn5LsL4uHHcSJ4aS0qDJsB9Yx7+yJOsSFbY0J6HFWgqJg/ fZFYvdkV/nGJKaA97slzySYEjhJvNIW0n8nIpFYpW/WVl75SiP JxPM3wztsvYorDWvwUxs2h84QpzLvfiRN/gLvIDrj1wYvz1Bpb rDnIOg84PACC1Wih5ytBZ2YApzaLmgIFyPDyj08ylXZsYqMixY xEtnN7xvYRSliAwqd8DmhqVzM+oAjrnd50YcbgOpdweBi3JDtg T5YCYIB+uNs2qZyfGrrm0/US7VxyhKmenxc69rgj9ADU9dVV+M foFZXXvH+rz0Pll6D+aeYCsMdBWC5IGmEz2sHkDsoFkQr41e88 NB+d1SpayQiYA==
Subject: Re: [apps-discuss] JSON-Home and application/json-home
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 11 Jan 2014 13:22:21 -0000

On 11.01.2014, at 14:13, Jan Algermissen <jan.algermissen@nordsc.com> =
wrote:

> Mark,
>=20
> might be obvious, but it just occurred to me that =
application/json-home is essentially a format to represent lists of =
links and/or link-templates.
>=20
> (It occurred to me because I found that a discovery format that I am =
experimentally crafting actually looked like application/json-home :-)
>=20
> This probably raises the question whether the application behind your =
JSON-Home I-D[1] should actually be reflected in the media type name?
>=20
> Not that I am suggesting this change, but maybe it is stimulating to =
chew on the idea of renaming
>=20
>  application/json-home
>=20
> to
>=20
>  application/links  or application/resourceinfo or whatever. You get =
the idea I guess.
>=20
> Jan
>=20
>=20
> [1] http://tools.ietf.org/html/draft-nottingham-json-home-03

Forgot to say: this reusability of application/json-home is probably a =
good indicator to leave the format as is, forget about the somewhat open =
issues[1][2] and move the spec towards standard? And -1 your todo-pile =
:-)

[1] Would actually not break the above POV, so you could put it in.
Jan

[1] =
http://www6.ietf.org/mail-archive/web/apps-discuss/current/msg09101.html
[2] =
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg09238.html



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


From ned.freed@mrochek.com  Sat Jan 11 10:37:19 2014
Return-Path: <ned.freed@mrochek.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA5FE1AE119 for <apps-discuss@ietfa.amsl.com>; Sat, 11 Jan 2014 10:37:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.84
X-Spam-Level: 
X-Spam-Status: No, score=-1.84 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jt1Eg9RjciSQ for <apps-discuss@ietfa.amsl.com>; Sat, 11 Jan 2014 10:37:16 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 1397B1AE11D for <apps-discuss@ietf.org>; Sat, 11 Jan 2014 10:37:16 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P30W7AFNC0002T08@mauve.mrochek.com> for apps-discuss@ietf.org; Sat, 11 Jan 2014 10:32:01 -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 <01P2SI6PLQJK0000AS@mauve.mrochek.com>; Sat, 11 Jan 2014 10:31:55 -0800 (PST)
Message-id: <01P30W782SVK0000AS@mauve.mrochek.com>
Date: Sat, 11 Jan 2014 08:21:12 -0800 (PST)
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Sat, 11 Jan 2014 12:45:07 +0000" <005501cf0eca$faf86840$4001a8c0@gateway.2wire.net>
References: <CAL0qLwZqJPTssNVLLaSjAP5wqteZ==fuawNF+WUZYvi+YWV1UQ@mail.gmail.com> <00a301cf07e8$01352160$4001a8c0@gateway.2wire.net> <52CF384D.3080502@rename-it.nl> <005501cf0eca$faf86840$4001a8c0@gateway.2wire.net>
To: "t.petch" <ietfc@btconnect.com>
Cc: Stephan Bosch <stephan@rename-it.nl>, IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 11 Jan 2014 18:37:20 -0000

> Mostly inline, but my big comment which gets lost in the detail is about
> scope of caches.  You say
> "there is only one 'cache' (in the document it is called the duplicate
> tracking list)"

> Really, worldwide, like the DNS root?-)

The phrase "only one cache" appears nowhere in the document that I can see. In
fact the word "cache" doesn't appear anywhere, which seems correct given that
nothing in this document involves using a cache, at least not in the sense that
I (or Wikipedia) understand the term.

> Hitherto, as I understand it, sieve has had no state; a filter is
> applied to a stream of messages and that is it, forget it and start
> again.

That's completely incorrect. The obvious counterexample is the vacation
extension, which has essentially been part of sieve from the beginning. Another
example is the notify extension. And in both of these cases the maintained
state is used to suppress duplicate messages. So they have a lot in common with
this extension.

More generally, sieve implementations often impose limits on the number of
times some operation can be performed. Sometimes this is per-script, but
sometimes it isn't. And that also requires state.

As a result sieve implementors are quite familiar with the ins and outs of
state storage.

> This adds state.  This then introduces the question of scope.

Nope. It's also been there pretty much from day one in Sieve.

> If I get the same message from two different ISP (which I  do), will
> that be detected?  I expect not.

It depends on where your sieve is store and evaluated. If it's a single sieve
being evaluated by your MUA that sees both messages, then yes, it will be
detected. If you have separate sieves attached to your ISP accounts, where each
one only sees one copy of the message, then no, it won't.

To put it another way, the "scope" of the state associated with a script
is always the script itself. Nothing more and nothing less. And the current
document does in fact say this, in the first paragraph of section 1:

   It adds a test to determine whether a certain message
   was seen before by the delivery agent in an earlier execution of ***the
   Sieve script.***

And it doesn't matter if your two sieves are both "yours" for some value of
"yours", they are identical, and if the two script instances are in fact under
shared admiistrative control so their storage could be coordinated. Why?
Because there's no way to devine the intent of having two separate instances of
a script. Maybe you want them to share some context. Or maybe for some reason
you don't. There's no way to communicate your intent in any case (and even if
there was there's no chance users would understand such a facility), so the
only sensible thing to do is to handle them separately.

> When those ISP outsource their MX to
> the same third party, will that be detected?

MX outsourcing has nothing to do with Sieve. Sieves are by definition evaluated
around the time of final delivery. A secondary MX by definition is not
performing final delivery.

Now, of course you can operate sieve outside of the context where it is
specified. But that's not something sieve specifications have to deal with.

> I expect not as long as
> they have different mail domains.

Mail domains have nothing to do with it either. Examples abound where users
have multiple mail domains associated with a single server or the handling of a
single mail domain is spread across multiple administrative domains.

But even this made sense, it wouldn't matter. The scope of storate associated
with a script is always just that script instance.

> At what point is there a single cache?

Again, this isn't a cache, at least not in the sense I understand the term. But
in any case, storage is per-script, that is, every sieve script gets its own
separate space for storing duplicate information.

> When I used multiple mailboxes for the same mail domain?

Those would each have separate scripts. You could choose to set them to be the
same script, but that doesn't make them the same instance.

> Only when I use a specific  mailbox? or when?

> In a sense it does not matter because it only effects the user
> experience and not the protocol on the wire, but I expect that users
> will care if the implementation on ISP A gives totally different results
> to ISP B.  And of course, when there is more than one cache (worldwide
> :-), then operators of this facility will need more resources to
> maintain them.

You're assuming vast complexity in the sieve space which AFAIK does not exist.
(There is in fact vast complexity in the space, but it's along fairly different
axes than the one you talk about here. And since almost all of lies far
outside the usage context defined by the specifications, it is not relevant
here.)

And perhaps more to the point, we have considerable experience with duplicate
elimination associated with the sieve vacation extension. In 10+ years of use,
I can't recall a single complaint about vacation duplicates that wasn't
associated with either a bug or some species of outright storage failure.
(Indeed, far and away the most common complaint we see in regards to vacation
is that the suppression mechanisms work too well and fail to send messages when
they are needed.)

> ----- Original Message -----
> From: "Stephan Bosch" <stephan@rename-it.nl>
> To: "t.petch" <ietfc@btconnect.com>; "Murray S. Kucherawy"
> <superuser@gmail.com>; "IETF Apps Discuss" <apps-discuss@ietf.org>
> Sent: Friday, January 10, 2014 12:01 AM
> > On 1/2/2014 7:24 PM, t.petch wrote:
> > > This I-D seems to need more thought.
> > >
> > > s.1 "For example, if a member of the list decides to
> > >    reply to both the user and the mailing list itself, the user will
> > >    one copy of the message directly and another through the mailing
> > >    list.
> > >
> > > Well, they MAY, but they don't on a good list system, such as the
> one in
> > > use here.

I get duplicate messages from IETF lists all the time.

> > >
> > > "Also, if someone cross-posts over several mailing lists to
> > >    which the user is subscribed, the user will receive a copy from
> each
> > >    of those lists."
> > >
> > > Ditto, not here.
> >
> > Ok, but these situations are quite common. I've implemented an earlier
> > version of this extension based on user requests. So, what do you want
> > me to do? Word this differently so that it is clear that this
> shouldn't happen for sanely configured mailing lists?

It does happen for sanely configured lists.

> I found the 'will' too forceful; my instant reaction was 'no it won't'
> because that is my experience.  Just moderate it slightly, 'will often'
> 'may' 'commonly'-  just not a somewhat forceful 'will'

I see no point to making such a change but don't object to it.

> > > "   Duplicate messages are normally detected using the Message-ID
> header
> > >    field, which is required to be unique for each message.  "
> > >
> > > REQUIRED maybe, but I seem to recall the malformed-mail I-D raising
> the
> > > possibility that it was not.  In which case, ...?
> >
> > I'm not sure how common that is, but you are right:  as the
> > specification is now, that would cause a false positive. We can make
> the
> > default a bit more complex by combining the Message-ID  with some
> other
> > header (Date perhaps?), thereby further reducing the likelihood of a
> > false positive. I guess we need to think about that a little more.

No, you really don't. The default has the virtue of simplicity and working fine
in almost all cases. The minute you start throwing other fields into the mix,
especially ones that tend to be messed with on submission, the less effective
the process will be.

> Yes, I think you should allow for the possibility in the I-D - as to
> how, I am less fussed.  Could be 'outside the scope of' up to 'should
> detect duplicates and discard as malformed' - just show that it has been
> considered.

I have no problem with pointing this out.

> > > s.3
> > > "an earlier Sieve execution."
> > > reading on it is apparent that this is any number of executions
> limited
> > > by the size of the FIFO cache and the maximum lifetime of entries in
> the
> > > cache.
> >
> > Yes. So, what exactly is your comment here? I don't think it is useful
> > to mention such detail early in the description.
> >
> > > "   Usage:  [":header" <header-name: string> /
> > >                           ":uniqueid" <value: string>]
> > >
> > > Why have two way of doing the same thing?  As I read it, this test
> is on
> > > a header field, so why not have just ":header" with a default of
> message
> > > I-D?
> >
> > I am not sure what you mean here. The :uniqueid argument does
> explicitly
> > not operate (directly) on a message header, but rather on some string
> > value composed by the user (using the variables extension). This can
> > consist of header field contents, but also on message body or even
> some
> > source other than the message being delivered.

> If I understand it aright, the test for duplication can be on
>  - message id
>  - header field
>  - something else
> which are invoked by <nothing>, :header, :unique-id respectively.
> Since message id is just another header field, why not merge the first
> two with the message id as the default header field if none other is
> specified?

Because it's a bad idea. The full syntax of the three cases is:

    duplicate

    duplicate :header "foo"

    duplicate :uniqueid "bar"

The only way to "merge" the first two syntactically would be something
like:

   duplicate :header

But that would be a case of a tagged argument that takes an optional parameter.
AFAICT this is not prohibited by RFC 5228, but this would be the first
extension to use such a construct. And given that it's unnecessary verbiage
added to a elegantly simple default case, I'm strongly opposed to making
such a change.

> > > And what happens if I use header field X in one execution and then
> > > header field Y in another? I presume separate caches for X and Y, in
> > > which case, duplicates may not be detected.
> >
> > No, there is only one 'cache' (in the document it is called the
> > duplicate tracking list). See the following text:
> >
> >  The "duplicate" test MUST track an unique ID value independent of its
> >  source.  This means that it does not matter whether values are
> >  obtained from the message ID header, from an arbitrary header
> >  specified using the ":header" argument or explicitly from the
> >  ":uniqueid" argument.

> see above

And see my response. I guess I have no objection to adding a statement
along the lines of "stored information about duplciates is always associated
with a single script" or something similar, but I don't see it as necessary.

> > Some examples follow this text. Do you mean that this needs to be
> > clarified more?
> >
> > > The use of multiple fields
> > > opens up all sorts of complications that need more explanation
> depending
> > > on the concept of the scope of the operation, which I do not see
> clearly
> > > explained.
> >
> > I am not sure what you mean here. I am assuming this comment is not
> > relevant given the above. Please clarify otherwise.
> >
> > > "The user can explicitly control the
> > >    length of this expiration time by means of the ":seconds"
> argument,
> > >    which is always specified in seconds.  "
> > >
> > > seconds seems short to me.  On the IETF lists, I typically see a gap
> of
> > > several hours between a message on one list and a message on another
> > > list, with four hours being the norm.  I would regard 5 minutes as
> the
> > > minimum and 36 hours, or perhaps less, as the maximum.
> >
> > Given the vacation-seconds extension, the use of a seconds granularity
> > is not strange in the Sieve realm.
> >
> > I like the flexibility of using seconds (mailinglists are not the only
> > application area of this extension), but I am not against changing it
> to
> > :minutes per se. Do any other people have thoughts?

> Ok but I just got a duplicate, once via the ietf announce list, once via
> the ietf main list, and they were 10 hours apart.  For me, this is
> typical, hours not seconds.

The history of vacation seems precisely on point here. The origincal vacation
extension only had a :days parameter, because that's what people thought
the finest granularity needed would be.

But that turned out to be wrong, and we had to create a second RFC, with
all the associated pother, not to mention grotting up the require namespace,
to fix it by adding :seconds.

The truth is we don't know what the finest granularity needs to be here. But
we do know three things:

(1) The chances it's less than a second are extremely small.
(2) You can always express a coarser granularity using a finer one, but not
    vice versa.
(3) Fixing this things after the fact is a big PITA.

I therefore think seconds is the right choice.

> > > "leading and trailing whitespace MUST first be trimmed from the
> value"
> > >
> > > This is a can of worms.  Normalisation often appears on these lists
> > > without, usually, a satisfactory answer, let alone the issues of
> i18n.
> > > More needs to be considered here.
> >
> > This mainly serves as a means to prevent stray white space from
> messing
> > with the string match. The core Sieve language also does this for
> > instance for the header test. And how would i18n be relevant here?

> Read RFC6532; that you have not referenced it makes me think that you
> have not considered i18n which I would regard as remiss nowadays.

I coauthored RFC 6532 and completely fail to see any relevance. In particular,
if two messages are in fact duplicates, don't you think they're going to be
normalized the same way? 

Put another way, while it's a well established fact that various intermediaries
muck around with header whitespace, I've yet to hear of intermediaries playing
normalization games. Absent evidence of even the existence of such things, let
alone sufficient information for how you'd want to deal with them, I'm
completely comfortable with this document not saying anything on this topic.

				Ned

From darrel.miller@gmail.com  Sat Jan 11 18:18:44 2014
Return-Path: <darrel.miller@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAC651AD672 for <apps-discuss@ietfa.amsl.com>; Sat, 11 Jan 2014 18:18:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.979
X-Spam-Level: 
X-Spam-Status: No, score=-0.979 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, MISSING_HEADERS=1.021, 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 D85cWG3Zvf83 for <apps-discuss@ietfa.amsl.com>; Sat, 11 Jan 2014 18:18:43 -0800 (PST)
Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id 362AB1A1EF9 for <apps-discuss@ietf.org>; Sat, 11 Jan 2014 18:18:43 -0800 (PST)
Received: by mail-ig0-f176.google.com with SMTP id j1so1622768iga.3 for <apps-discuss@ietf.org>; Sat, 11 Jan 2014 18:18:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:cc:content-type; bh=yVXtptypFN2aFPJ0mmjR8n8yR69+DUWOUgGhY4X5nPo=; b=jncdBC/BI2UGdMpQNDhICzLMf3PiwAkMPhiTNAfcuYom/x79PVZNJWmEOypEdyFH0x z82oAWihPyRIlCnpyeRiN8lhgEo1v40RJjaGDORsMZmT67qtXAN3+XOfNahtRrqgZ5Rx VipwSKp9PLpdZnmwPObsOXjUCgtZU9Xqr65Z3+Z02S7qlaw2ZAxAgSzyxDtmgQzz0uhH 4ZpHwi9MDMj8HaoNorK72v13c4bu3W9dxpVDLn3B8MdmigYLie+yNEVMpGT8I8e+hjgg PUUkxe4GK2KjgVaqkgLIsVIf5/8qmQ+9gfThSrfCyOCvoAwVcNqNitG4xk+KQm/1r86x PwgA==
MIME-Version: 1.0
X-Received: by 10.50.143.10 with SMTP id sa10mr11717262igb.8.1389493112634; Sat, 11 Jan 2014 18:18:32 -0800 (PST)
Received: by 10.42.195.206 with HTTP; Sat, 11 Jan 2014 18:18:32 -0800 (PST)
In-Reply-To: <7379B6E3-33DE-40BA-9BA8-258FD12FBFBC@nordsc.com>
References: <7379B6E3-33DE-40BA-9BA8-258FD12FBFBC@nordsc.com>
Date: Sat, 11 Jan 2014 21:18:32 -0500
Message-ID: <CAKioOqsLJmxV34z7VXs4OjP5LzR0MmHADk04m2iwbYh3zTAkKA@mail.gmail.com>
From: Darrel Miller <darrel.miller@gmail.com>
Cc: "apps-discuss@ietf.org Discuss" <apps-discuss@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [apps-discuss] JSON-Home and application/json-home
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: darrel@tavis.ca
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 12 Jan 2014 02:18:44 -0000

Hey Jan,

Be aware that json-home does not support two links that have the same
link relation type.   Initially I was convinced this was a
short-coming of the format, however, after stewing on it for a while,
I believe that instead of adding some mechanism to allow a user-agent
to discriminate between different links with the same link relation
type, an additional URI template parameter would be able to achieve
must the same capability.



Darrel

On Sat, Jan 11, 2014 at 8:13 AM, Jan Algermissen
<jan.algermissen@nordsc.com> wrote:
> Mark,
>
> might be obvious, but it just occurred to me that application/json-home is essentially a format to represent lists of links and/or link-templates.
>
> (It occurred to me because I found that a discovery format that I am experimentally crafting actually looked like application/json-home :-)
>
> This probably raises the question whether the application behind your JSON-Home I-D[1] should actually be reflected in the media type name?
>
> Not that I am suggesting this change, but maybe it is stimulating to chew on the idea of renaming
>
>   application/json-home
>
> to
>
>   application/links  or application/resourceinfo or whatever. You get the idea I guess.
>
> Jan
>
>
> [1] http://tools.ietf.org/html/draft-nottingham-json-home-03
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss

From jan.algermissen@nordsc.com  Sun Jan 12 02:18:17 2014
Return-Path: <jan.algermissen@nordsc.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95B781ADFB4 for <apps-discuss@ietfa.amsl.com>; Sun, 12 Jan 2014 02:18:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level: 
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 EuB31Ma3wlwW for <apps-discuss@ietfa.amsl.com>; Sun, 12 Jan 2014 02:18:15 -0800 (PST)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0061ADFBB for <apps-discuss@ietf.org>; Sun, 12 Jan 2014 02:18:15 -0800 (PST)
Received: from [192.168.2.103] (p548F9BDD.dip0.t-ipconnect.de [84.143.155.221]) by mrelayeu.kundenserver.de (node=mrbap4) with ESMTP (Nemesis) id 0MVuae-1VrCHj49d2-00X6N1; Sun, 12 Jan 2014 11:18:04 +0100
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jan Algermissen <jan.algermissen@nordsc.com>
In-Reply-To: <CAKioOqsLJmxV34z7VXs4OjP5LzR0MmHADk04m2iwbYh3zTAkKA@mail.gmail.com>
Date: Sun, 12 Jan 2014 11:18:03 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <5D108345-F64D-4FD3-9891-97D765045069@nordsc.com>
References: <7379B6E3-33DE-40BA-9BA8-258FD12FBFBC@nordsc.com> <CAKioOqsLJmxV34z7VXs4OjP5LzR0MmHADk04m2iwbYh3zTAkKA@mail.gmail.com>
To: darrel@tavis.ca
X-Mailer: Apple Mail (2.1510)
X-Provags-ID: V02:K0:CiP3EjATyXockruG0FwTAw6w3Xc3GPNTNQmeyTKgJsd T8RxWwjw1TV1Bqpe896VfnPorYvrxN3HpA1bcODl6H33udErDF U5NVAOPAI/JP1AIbX4AcAIb+4HjJfCR2LGb5Q2VUhQcTZDf0g8 17+fjoPRc+HKLEwDgQtaEZI8x/WG47WLdJwzfhMiZfhFFBghYR 4lF/pB1FDLcPoCbk0yG0NTcP0vCt1E6ubElCZ94GxZNh6WC762 /BLqwYF50MB3QsJZBL1elGqgwlHnYCJFLcfqQAIx44gJR6G/MA fgcpxkmFFGYLhiu8G9OxGk1o+WR3WMhg/iZJ60npDaCky2J/Vk pmFrFY8OTuGh9rrHnJKJPZrhQH7EEKuLnnoa+rCSBomriKfYNW L2Loq6Z3v+I2A==
Cc: "apps-discuss@ietf.org Discuss" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] JSON-Home and application/json-home
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 12 Jan 2014 10:18:17 -0000

Hi Darrel,

On 12.01.2014, at 03:18, Darrel Miller <darrel.miller@gmail.com> wrote:

> Hey Jan,
>=20
> Be aware that json-home does not support two links that have the same
> link relation type.  =20

Yes, right. So not quite any link lists :-)

> Initially I was convinced this was a
> short-coming of the format, however, after stewing on it for a while,
> I believe that instead of adding some mechanism to allow a user-agent
> to discriminate between different links with the same link relation
> type, an additional URI template parameter would be able to achieve
> must the same capability.

Funny, same thought I have two days ago.

I then ended up solving a situation with more than one link of the same =
rel with another layer of "dscription document". When I designed the =
media type for that I realized I was re-doing application/json-home :-)

Jan

>=20
>=20
>=20
> Darrel
>=20
> On Sat, Jan 11, 2014 at 8:13 AM, Jan Algermissen
> <jan.algermissen@nordsc.com> wrote:
>> Mark,
>>=20
>> might be obvious, but it just occurred to me that =
application/json-home is essentially a format to represent lists of =
links and/or link-templates.
>>=20
>> (It occurred to me because I found that a discovery format that I am =
experimentally crafting actually looked like application/json-home :-)
>>=20
>> This probably raises the question whether the application behind your =
JSON-Home I-D[1] should actually be reflected in the media type name?
>>=20
>> Not that I am suggesting this change, but maybe it is stimulating to =
chew on the idea of renaming
>>=20
>>  application/json-home
>>=20
>> to
>>=20
>>  application/links  or application/resourceinfo or whatever. You get =
the idea I guess.
>>=20
>> Jan
>>=20
>>=20
>> [1] http://tools.ietf.org/html/draft-nottingham-json-home-03
>> _______________________________________________
>> 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 cyrus@daboo.name  Mon Jan 13 08:41:48 2014
Return-Path: <cyrus@daboo.name>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1AA01AE1AD for <apps-discuss@ietfa.amsl.com>; Mon, 13 Jan 2014 08:41:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.438
X-Spam-Level: 
X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1kO_qm1S1Wd for <apps-discuss@ietfa.amsl.com>; Mon, 13 Jan 2014 08:41:45 -0800 (PST)
Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id 29F3C1AE1A8 for <apps-discuss@ietf.org>; Mon, 13 Jan 2014 08:41:45 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id E27085944168; Mon, 13 Jan 2014 11:41:33 -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 yq-9q2lyPsz0; Mon, 13 Jan 2014 11:41:33 -0500 (EST)
Received: from caldav.corp.apple.com (unknown [17.45.162.46]) by daboo.name (Postfix) with ESMTPSA id 636A05944156; Mon, 13 Jan 2014 11:41:32 -0500 (EST)
Date: Mon, 13 Jan 2014 11:41:07 -0500
From: Cyrus Daboo <cyrus@daboo.name>
To: "Murray S. Kucherawy" <superuser@gmail.com>, IETF Apps Discuss <apps-discuss@ietf.org>
Message-ID: <82C3BF0849C9F441B88C65BF@caldav.corp.apple.com>
In-Reply-To: <CAL0qLwZyEPBgZSQOF0WfOpRT_S40Sit6WYrjxnFswkvfNXDvOA@mail.gmail.com>
References: <CAL0qLwZyEPBgZSQOF0WfOpRT_S40Sit6WYrjxnFswkvfNXDvOA@mail.gmail.com>
X-Mailer: Mulberry/4.1.0a3 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; size=505
Subject: Re: [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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Jan 2014 16:41:48 -0000

Hi Murray,

--On December 13, 2013 at 10:37:00 AM -0800 "Murray S. Kucherawy" 
<superuser@gmail.com> wrote:

> This message initiates an extended Working Group Last Call for
> draft-ietf-appsawg-sieve-duplicate, ending Friday, January 10, 2014.

I reviewed the previous version of this draft and issues I brought up have 
been addressed in the current draft (the on in WGLC). I am happy with this 
draft and I believe it represents a useful feature for SIEVE that we should 
standardize.

-- 
Cyrus Daboo


From ned.freed@mrochek.com  Mon Jan 13 09:27:18 2014
Return-Path: <ned.freed@mrochek.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECC881ACCDA for <apps-discuss@ietfa.amsl.com>; Mon, 13 Jan 2014 09:27:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.44
X-Spam-Level: 
X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Swahn-0_SCbN for <apps-discuss@ietfa.amsl.com>; Mon, 13 Jan 2014 09:27:16 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 848AE1AC4A7 for <apps-discuss@ietf.org>; Mon, 13 Jan 2014 09:27:16 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P33MC8DM74002917@mauve.mrochek.com> for apps-discuss@ietf.org; Mon, 13 Jan 2014 09:22:01 -0800 (PST)
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=utf-8
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P2SI6PLQJK0000AS@mauve.mrochek.com>; Mon, 13 Jan 2014 09:21:58 -0800 (PST)
Message-id: <01P33MC6OLZM0000AS@mauve.mrochek.com>
Date: Mon, 13 Jan 2014 08:19:28 -0800 (PST)
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Tue, 07 Jan 2014 19:01:31 +0000" <dc29826a2bbf48088abe51bb5de22e0d@BL2PR02MB307.namprd02.prod.outlook.com>
References: <dc29826a2bbf48088abe51bb5de22e0d@BL2PR02MB307.namprd02.prod.outlook.com>
To: Larry Masinter <masinter@adobe.com>
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] draft-ietf-appsawg-xml-mediatypes vs. JSON and BOM	and UTF-8
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Jan 2014 17:27:18 -0000

> I have some discussion topics for draft-ietf-appsawg-xml-mediatypes which I will send out one-by-one.
> This first one was discussed but here I'm making some specific suggestions.

> It cannot be right that everyone specifying a text-based media type should
> have to go through the process of deciding, for themselves, independently, how
> to decide between conflicting sources of information about charset, coming from
> an initial BOM, from external metadata, from any supplied "charset" parameter
> of the media type, and from internal embedded metadata such as found in XML.

It may not be "right" but it is the reality of the situation.

> If the future is UTF-8, UTF-8, UTF-8, then the two documents should say so,
> right at the beginning.

I believe the future is UTF-8, including but not limited to its use in XML, and
we should do what we can to promote it. But beliefs about the future don't
necessarily belong in an RFC.

Moreover, is this the right place and the right organization to make such a
statement about XML? The IETF doesn't own the XML specification, the W3C does.
And this is a document about how to register XML media types, not about how to
use XML.

Mind you, given my own beliefs I don't personally object to such a statement if
there is consensus to include it. I just wonder if it is appropriate.

				Ned

From arnt@gulbrandsen.priv.no  Tue Jan 14 01:06:35 2014
Return-Path: <arnt@gulbrandsen.priv.no>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9624A1AE071 for <apps-discuss@ietfa.amsl.com>; Tue, 14 Jan 2014 01:06:35 -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 blnOxOleQDNC for <apps-discuss@ietfa.amsl.com>; Tue, 14 Jan 2014 01:06:33 -0800 (PST)
Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id B4DCE1AE070 for <apps-discuss@ietf.org>; Tue, 14 Jan 2014 01:06:33 -0800 (PST)
Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 6207AFA00B6; Tue, 14 Jan 2014 09:06:21 +0000 (UTC)
Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1389690380-11863-11863/11/1; Tue, 14 Jan 2014 09:06:20 +0000
Date: Tue, 14 Jan 2014 10:06:23 +0100
From: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
To: apps-discuss@ietf.org
Message-Id: <20140114085709.GA21460@gulbrandsen.priv.no>
References: <52D3A2C8.5030807@rename-it.nl> <01P33JH6T0LO0000AS@mauve.mrochek.com> <CAL0qLwY+pejVBVOmz_PMRF_0ORaNVrOmzB4_SVYVnw+dtC0QQA@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain
In-Reply-To: <CAL0qLwY+pejVBVOmz_PMRF_0ORaNVrOmzB4_SVYVnw+dtC0QQA@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Content-Transfer-Encoding: quoted-printable
Cc: Stephan Bosch <stephan@rename-it.nl>
Subject: [apps-discuss] Review of 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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Jan 2014 09:06:35 -0000

Hi,

I read this draft earlier and decided to ignore it. There's nothing
terribly bad about it, I wouldn't want to block it, but IMO also
nothing terribly good.

I have one real problem and a word nit.

Consider the main use case, from the document's introduction:

   Duplicate deliveries are a common side-effect of being subscribed
   to a mailing list.

I would expect that the draft makes handling that use case simple, and
a well-rounded set of other use cases possible. IMO it does poorly at
that use case.

Here's the first example for the Pigeonhole sieve server, modified to
suppress duplicates rather like how the first example in
sieve-duplicate does:

   require ["fileinto", "envelope", "duplicate"];
   if address :is "to" "dovecot@dovecot.org" {
     fileinto "Dovecot-list";
   } elsif envelope :is "from" "owner-cipe-l@inka.de" {
     fileinto "lists.cipe";
   } elsif anyof (header :contains "X-listname" "lugog@cip.rz.fh-offenbur=
g.de",
                  header :contains "List-Id" "Linux User Group Offenburg"=
) {
     fileinto "ml.lugog";
   } elsif duplicate {
     discard;
   } else {
     # The rest goes into INBOX
     # default is "implicit keep", we do it explicitly here
     keep;
   }

If a message is sent to you personally with a cc to cipe-l or lugog,
this sieve script will file it into either lists.cipe/ml.lugg or
inbox, randomly, depending on which copy arrives first. This strikes
me as rather poor handling of the use case.

1. It's not what I want. What I personally want is to have a single
instance of the message filed in all the mailboxes fileinto/keep
specifies for any instance of the message, and the other instances
suppressed. But feel free to disregard this point, after all it's just
my personal desire.

2. It's not deterministic. And that's worse. This draft makes the
lists.cipe/ml.lugog mailbox into a randomly incomplete set of messages
to the relevant list, which isn't much of an improvement over the
status quo.

My nit concerns the word multiple. Four is a multiple of two, but
"several" and "many" are perfectly fine words to mean "integers larger
than one".

I once had a student who met his minimum pagecount by using long words
and hacky tex wordwrapping. He would write "multiple independent
purposes" instead of "several purposes" or "many purposes". Unlike
him, internet-drafts authors have no need to leverage multiple
unnecesssary polysyllabic words in order to meet university-imposed
arbitrary minimum length requirements.

Arnt

From arnt@gulbrandsen.priv.no  Tue Jan 14 01:25:58 2014
Return-Path: <arnt@gulbrandsen.priv.no>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F49D1ADF7B for <apps-discuss@ietfa.amsl.com>; Tue, 14 Jan 2014 01:25:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dnReXxJ9GAJs for <apps-discuss@ietfa.amsl.com>; Tue, 14 Jan 2014 01:25:57 -0800 (PST)
Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id 167911ADFFC for <apps-discuss@ietf.org>; Tue, 14 Jan 2014 01:25:57 -0800 (PST)
Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 35ECEFA044B; Tue, 14 Jan 2014 09:25:45 +0000 (UTC)
Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1389691544-11863-11863/11/3; Tue, 14 Jan 2014 09:25:44 +0000
Date: Tue, 14 Jan 2014 10:25:47 +0100
From: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
To: apps-discuss@ietf.org
Message-Id: <20140114092547.GB21760@gulbrandsen.priv.no>
References: <52D3A2C8.5030807@rename-it.nl> <01P33JH6T0LO0000AS@mauve.mrochek.com> <CAL0qLwY+pejVBVOmz_PMRF_0ORaNVrOmzB4_SVYVnw+dtC0QQA@mail.gmail.com> <20140114085709.GA21460@gulbrandsen.priv.no>
In-Reply-To: <20140114085709.GA21460@gulbrandsen.priv.no>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Stephan Bosch <stephan@rename-it.nl>
Subject: Re: [apps-discuss] Review of 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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Jan 2014 09:25:58 -0000

Btw. I apologize for either the lateness of my review or its nature.
Pick whichever you prefer ;)

My tonsils and I are going to hospital in two days, to part our ways
forever, so replies may be late for a while.

Arnt

From ietf-secretariat-reply@ietf.org  Tue Jan 14 01:33:09 2014
Return-Path: <ietf-secretariat-reply@ietf.org>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6272D1ADBD1 for <apps-discuss@ietfa.amsl.com>; Tue, 14 Jan 2014 01:33:09 -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 NrjRwCbwhtlV for <apps-discuss@ietfa.amsl.com>; Tue, 14 Jan 2014 01:33:08 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4268F1AE061 for <apps-discuss@ietf.org>; Tue, 14 Jan 2014 01:33:06 -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.90.p2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140114093306.14198.52224.idtracker@ietfa.amsl.com>
Date: Tue, 14 Jan 2014 01:33:06 -0800
From: IETF Secretariat <ietf-secretariat-reply@ietf.org>
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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Jan 2014 09:33:09 -0000

Changed milestone "Publication requested for
draft-ietf-appsawg-rrvs-header-field", set due date to January 2014
from December 2013.

Changed milestone "Publication requested for
draft-ietf-appsawg-json-merge-patch", set due date to February 2014
from December 2013.

Changed milestone "Publication requested for
draft-ietf-appsawg-xml-mediatypes", set due date to February 2014 from
December 2013.

Changed milestone "Publication requested for
draft-ietf-appsawg-sieve-duplicate", set due date to February 2014
from December 2013.

Changed milestone "Publication requested for
draft-ietf-appsawg-uri-get-off-my-lawn", set due date to February 2014
from December 2013.

URL: http://datatracker.ietf.org/wg/appsawg/charter/

From stephan@rename-it.nl  Tue Jan 14 02:20:02 2014
Return-Path: <stephan@rename-it.nl>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 222F31AE078 for <apps-discuss@ietfa.amsl.com>; Tue, 14 Jan 2014 02:20:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.257
X-Spam-Level: 
X-Spam-Status: No, score=0.257 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_25=0.6, RP_MATCHES_RCVD=-0.538] 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 IuiZHsXjJ8oG for <apps-discuss@ietfa.amsl.com>; Tue, 14 Jan 2014 02:20:00 -0800 (PST)
Received: from drpepper.rename-it.nl (drpepper.rename-it.nl [217.119.238.16]) by ietfa.amsl.com (Postfix) with ESMTP id DB2051AE070 for <apps-discuss@ietf.org>; Tue, 14 Jan 2014 02:19:59 -0800 (PST)
Received: from wlan024124.mobiel.utwente.nl ([130.89.24.124]:1763) by drpepper.rename-it.nl with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <stephan@rename-it.nl>) id 1W315z-0006C2-Qo; Tue, 14 Jan 2014 11:19:46 +0100
Message-ID: <52D50F3A.8040206@rename-it.nl>
Date: Tue, 14 Jan 2014 11:19:38 +0100
From: Stephan Bosch <stephan@rename-it.nl>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>, apps-discuss@ietf.org
References: <52D3A2C8.5030807@rename-it.nl> <01P33JH6T0LO0000AS@mauve.mrochek.com> <CAL0qLwY+pejVBVOmz_PMRF_0ORaNVrOmzB4_SVYVnw+dtC0QQA@mail.gmail.com> <20140114085709.GA21460@gulbrandsen.priv.no>
In-Reply-To: <20140114085709.GA21460@gulbrandsen.priv.no>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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] Review of 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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Jan 2014 10:20:02 -0000

Arnt Gulbrandsen schreef op 14-1-2014 10:06:
> Hi,
>
> I read this draft earlier and decided to ignore it. There's nothing
> terribly bad about it, I wouldn't want to block it, but IMO also
> nothing terribly good.
>
> I have one real problem and a word nit.
>
> Consider the main use case, from the document's introduction:
>
>     Duplicate deliveries are a common side-effect of being subscribed
>     to a mailing list.
>
> I would expect that the draft makes handling that use case simple, and
> a well-rounded set of other use cases possible. IMO it does poorly at
> that use case.
>
> Here's the first example for the Pigeonhole sieve server, modified to
> suppress duplicates rather like how the first example in
> sieve-duplicate does:
>
>     require ["fileinto", "envelope", "duplicate"];
>     if address :is "to" "dovecot@dovecot.org" {
>       fileinto "Dovecot-list";
>     } elsif envelope :is "from" "owner-cipe-l@inka.de" {
>       fileinto "lists.cipe";
>     } elsif anyof (header :contains "X-listname" "lugog@cip.rz.fh-offenburg.de",
>                    header :contains "List-Id" "Linux User Group Offenburg") {
>       fileinto "ml.lugog";
>     } elsif duplicate {
>       discard;
>     } else {
>       # The rest goes into INBOX
>       # default is "implicit keep", we do it explicitly here
>       keep;
>     }
>
> If a message is sent to you personally with a cc to cipe-l or lugog,
> this sieve script will file it into either lists.cipe/ml.lugg or
> inbox, randomly, depending on which copy arrives first. This strikes
> me as rather poor handling of the use case.
>
> 1. It's not what I want. What I personally want is to have a single
> instance of the message filed in all the mailboxes fileinto/keep
> specifies for any instance of the message, and the other instances
> suppressed. But feel free to disregard this point, after all it's just
> my personal desire.
>
> 2. It's not deterministic. And that's worse. This draft makes the
> lists.cipe/ml.lugog mailbox into a randomly incomplete set of messages
> to the relevant list, which isn't much of an improvement over the
> status quo.

There are two aspects to this problem.

First, this example is flawed. The duplicate test has a side effect: 
apart from testing for a duplicate it also records the identifier (in 
the bare case the Message-ID) for comparison in subsequent deliveries. 
So, if the test is not evaluated, the identifier is never recorded.

This example should address that problem:

require ["fileinto", "envelope", "duplicate"];
  
if duplicate {
   discard;
} else {
   if address :is "to" "dovecot@dovecot.org" {
     fileinto "Dovecot-list";
   } elsif envelope :is "from" "owner-cipe-l@inka.de" {
     fileinto "lists.cipe";
   } elsif anyof (header :contains "X-listname" "lugog@cip.rz.fh-offenburg.de",
                  header :contains "List-Id" "Linux User Group Offenburg") {
     fileinto "ml.lugog";
   } else {
     # The rest goes into INBOX
     # default is "implicit keep", we do it explicitly here
     keep;
   }
}

The second aspect is a bigger issue. It is indeed uncertain which copy arrives first: the Cc or the message through the mailing list. The latter will have the List-Id header, the former will not. The above example would therefore still be problematic for the ml.lugog mailing list. I am not certain whether there could be any solution for that, other than not relying on the List-ID header and accepting that the destination folder will contain a mixture of the Cc and the actual mailing list messages.

> My nit concerns the word multiple. Four is a multiple of two, but
> "several" and "many" are perfectly fine words to mean "integers larger
> than one".

So, you want me to vary  a bit? :)

> I once had a student who met his minimum pagecount by using long words
> and hacky tex wordwrapping. He would write "multiple independent
> purposes" instead of "several purposes" or "many purposes". Unlike
> him, internet-drafts authors have no need to leverage multiple
> unnecesssary polysyllabic words in order to meet university-imposed
> arbitrary minimum length requirements.

I used the word independent to stress the fact that these applications 
would not influence each other when applied within the same Sieve 
script. I can word that differently, but I doubt it will become much 
shorter. :)

Regards,

Stephan.

From arnt@gulbrandsen.priv.no  Tue Jan 14 03:24:21 2014
Return-Path: <arnt@gulbrandsen.priv.no>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65ED81AE08E for <apps-discuss@ietfa.amsl.com>; Tue, 14 Jan 2014 03:24:21 -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 20A4PDgSBk-r for <apps-discuss@ietfa.amsl.com>; Tue, 14 Jan 2014 03:24:20 -0800 (PST)
Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A8131AE089 for <apps-discuss@ietf.org>; Tue, 14 Jan 2014 03:24:19 -0800 (PST)
Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 6E195FA00B6; Tue, 14 Jan 2014 11:24:06 +0000 (UTC)
Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1389698645-14162-14162/11/1; Tue, 14 Jan 2014 11:24:05 +0000
Date: Tue, 14 Jan 2014 12:24:08 +0100
From: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
To: Stephan Bosch <stephan@rename-it.nl>
Message-Id: <20140114112403.GA24989@gulbrandsen.priv.no>
References: <52D3A2C8.5030807@rename-it.nl> <01P33JH6T0LO0000AS@mauve.mrochek.com> <CAL0qLwY+pejVBVOmz_PMRF_0ORaNVrOmzB4_SVYVnw+dtC0QQA@mail.gmail.com> <20140114085709.GA21460@gulbrandsen.priv.no> <52D50F3A.8040206@rename-it.nl>
In-Reply-To: <52D50F3A.8040206@rename-it.nl>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Review of 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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Jan 2014 11:24:21 -0000

On Tue, Jan 14, 2014 at 11:19:38AM +0100, Stephan Bosch wrote:
> There are two aspects to this problem.
> 
> First, this example is flawed. The duplicate test has a side effect:
> apart from testing for a duplicate it also records the identifier
> (in the bare case the Message-ID) for comparison in subsequent
> deliveries. So, if the test is not evaluated, the identifier is
> never recorded.

Good point. So you might want to point out that this test has to go
first, then. Unless you want to assume that most reader are smarter
than I am, which I concede is a possibility.

> The second aspect is a bigger issue. It is indeed uncertain which
> copy arrives first: ...

The only way I can think of is to use an action instead of a test.

  require ["fileinto", "envelope", "duplicate"];
  merge-duplicates;
  if address :is "to" "dovecot@dovecot.org" {
    fileinto "Dovecot-list";
  } elsif envelope :is "from" "owner-cipe-l@inka.de" {
    fileinto "lists.cipe";
  } elsif anyof (header :contains "X-listname" "lugog@cip.rz.fh-offenburg.de",
                 header :contains "List-Id" "Linux User Group Offenburg") {
    fileinto "ml.lugog";
  } else {
    # The rest goes into INBOX
    # default is "implicit keep", we do it explicitly here
    keep;
  }

If merge-duplicates detects that the current message is a duplicate of
an already stored message, then

 - fileinto and keep act on the old copy, and copy/link that into the
   mailbox specified by fileinto/keep
 - discard discards this new copy and leaves the old copy as is
 - other actions use the new copy
 - all tests act on the new copy

> So, you want me to vary  a bit? :)

Say several if you mean several, many if you mean many.

Multiple is a fashionable word at the moment. Like ask as a noun.

Arnt

From arnt@gulbrandsen.priv.no  Tue Jan 14 03:31:14 2014
Return-Path: <arnt@gulbrandsen.priv.no>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F6DA1AE06A for <apps-discuss@ietfa.amsl.com>; Tue, 14 Jan 2014 03:31:14 -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 794jofLYzOvC for <apps-discuss@ietfa.amsl.com>; Tue, 14 Jan 2014 03:31:12 -0800 (PST)
Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id B81551AE04D for <apps-discuss@ietf.org>; Tue, 14 Jan 2014 03:31:12 -0800 (PST)
Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 59AD6FA00B6; Tue, 14 Jan 2014 11:31:00 +0000 (UTC)
Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1389699059-14162-14162/11/3; Tue, 14 Jan 2014 11:30:59 +0000
Date: Tue, 14 Jan 2014 12:31:02 +0100
From: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
To: Stephan Bosch <stephan@rename-it.nl>
Message-Id: <20140114113101.GC24989@gulbrandsen.priv.no>
References: <52D3A2C8.5030807@rename-it.nl> <01P33JH6T0LO0000AS@mauve.mrochek.com> <CAL0qLwY+pejVBVOmz_PMRF_0ORaNVrOmzB4_SVYVnw+dtC0QQA@mail.gmail.com> <20140114085709.GA21460@gulbrandsen.priv.no> <52D50F3A.8040206@rename-it.nl> <20140114112403.GA24989@gulbrandsen.priv.no>
In-Reply-To: <20140114112403.GA24989@gulbrandsen.priv.no>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Review of 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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Jan 2014 11:31:14 -0000

On Tue, Jan 14, 2014 at 12:24:08PM +0100, Arnt Gulbrandsen wrote:
> The only way I can think of is to use an action instead of a test.

No, there are many ways. Variations. But if you want predictable
results, you have to tie it to fileinto/keep somehow. For instance:

  fileinto :deduplicated "ml.lugog";

to either stores the new or widens the mailbox set for the old copy.
Many ways. None of them are particularly appealing, if you ask me.

Arnt

From ietfc@btconnect.com  Tue Jan 14 07:42:11 2014
Return-Path: <ietfc@btconnect.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E2531ADF93 for <apps-discuss@ietfa.amsl.com>; Tue, 14 Jan 2014 07:42: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,  J_CHICKENPOX_15=0.6, 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 n_V6QAdsrVSt for <apps-discuss@ietfa.amsl.com>; Tue, 14 Jan 2014 07:42:06 -0800 (PST)
Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe004.messaging.microsoft.com [213.199.154.207]) by ietfa.amsl.com (Postfix) with ESMTP id B0B161ADF7F for <apps-discuss@ietf.org>; Tue, 14 Jan 2014 07:42:05 -0800 (PST)
Received: from mail66-am1-R.bigfish.com (10.3.201.227) by AM1EHSOBE002.bigfish.com (10.3.204.22) with Microsoft SMTP Server id 14.1.225.22; Tue, 14 Jan 2014 15:41:53 +0000
Received: from mail66-am1 (localhost [127.0.0.1])	by mail66-am1-R.bigfish.com (Postfix) with ESMTP id A20D8180110; Tue, 14 Jan 2014 15:41:53 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.249.213; KIP:(null); UIP:(null); IPV:NLI; H:AM2PRD0710HT003.eurprd07.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -18
X-BigFish: PS-18(zzbb2dI98dI9371I542I1432I1418I1447Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h20f7h2189h1d1ah1d2ah1fc6hzz1de098h1033IL8275bh8275dh1de097hz2dh2a8h5a9h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah2222h224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h2218h2216h226dh22d0h2327h2336h2438h2461h304l1d11m1155h)
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(779001)(689001)(679001)(189002)(377454003)(479174003)(51914003)(199002)(24454002)(51444003)(51704005)(13464003)(19580395003)(69226001)(77156001)(42186004)(33646001)(83322001)(63696002)(79102001)(54316002)(14496001)(44716002)(62236002)(59766001)(19580405001)(56776001)(77982001)(81542001)(92566001)(76482001)(80022001)(92726001)(53806001)(65816001)(84392001)(61296002)(66066001)(50466002)(77096001)(76786001)(74366001)(76796001)(51856001)(89996001)(74502001)(50226001)(74876001)(74662001)(74706001)(31966008)(47446002)(88136002)(44736004)(47736001)(80976001)(87976001)(46102001)(81342001)(47776003)(87286001)(23756003)(49866001)(4396001)(85306002)(85852003)(50986001)(47976001)(87266001)(83072002)(56816005)(90146001)(62966002)(93136001)(74416001)(7726001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB3PR07MB060; H:DBXPRD0611HT002.eurprd06.prod.outlook.com; CLIP:157.56.254.85; FPR:; RD:InfoNoRecords; MX:1; A:0; LANG:en; 
Received: from mail66-am1 (localhost.localdomain [127.0.0.1]) by mail66-am1 (MessageSwitch) id 1389714111664895_7017; Tue, 14 Jan 2014 15:41:51 +0000 (UTC)
Received: from AM1EHSMHS009.bigfish.com (unknown [10.3.201.227])	by mail66-am1.bigfish.com (Postfix) with ESMTP id 93DBD4C0060;	Tue, 14 Jan 2014 15:41:51 +0000 (UTC)
Received: from AM2PRD0710HT003.eurprd07.prod.outlook.com (157.56.249.213) by AM1EHSMHS009.bigfish.com (10.3.207.109) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 14 Jan 2014 15:41:51 +0000
Received: from DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) by AM2PRD0710HT003.eurprd07.prod.outlook.com (10.255.165.38) with Microsoft SMTP Server (TLS) id 14.16.395.1; Tue, 14 Jan 2014 15:41:50 +0000
Received: from DBXPRD0611HT002.eurprd06.prod.outlook.com (157.56.254.85) by DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) with Microsoft SMTP Server (TLS) id 15.0.842.7; Tue, 14 Jan 2014 15:41:48 +0000
Message-ID: <002801cf113e$93167200$4001a8c0@gateway.2wire.net>
From: t.petch <ietfc@btconnect.com>
To: Ned Freed <ned.freed@mrochek.com>
References: <CAL0qLwZqJPTssNVLLaSjAP5wqteZ==fuawNF+WUZYvi+YWV1UQ@mail.gmail.com> <00a301cf07e8$01352160$4001a8c0@gateway.2wire.net> <52CF384D.3080502@rename-it.nl> <005501cf0eca$faf86840$4001a8c0@gateway.2wire.net> <01P30W782SVK0000AS@mauve.mrochek.com>
Date: Tue, 14 Jan 2014 15:37:25 +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.254.85]
X-ClientProxiedBy: AMXPR07CA002.eurprd07.prod.outlook.com (10.242.64.42) To DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151)
X-Forefront-PRVS: 0091C8F1EB
X-OriginatorOrg: btconnect.com
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
Cc: Stephan Bosch <stephan@rename-it.nl>, IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Working Group Last Calldraft-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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Jan 2014 15:42:11 -0000

Ned

Thanks for the clarification.  The part that I did not understand is
"It adds a test to determine whether a certain message
   was seen before by the delivery agent in an earlier execution of the
   Sieve script.  "
and I think that that should be clarified.   You say that 'the sieve
script'
defines the scope, and how many there are, of  'the internal duplicate
tracking list'.  I think that this is fundamental to understanding how
this
extension works - something which I did not understand and so should
be clarified.

You say too that the vacation and notify extensions have the concept
of state and indeed these are Informative References; but only
Informative - I read the Normative ones before posting my comments
so again, did not have that additional information.

Finally, I am surprised that you do not see 'the internal duplicate
tracking list' as a cache - I read the description of this mechanism
and thought, this is a cache, and cache is so much easier to type
(and read) than 'the internal duplicate tracking list' so I used that
for the purposes of this thread.

Tom Petch

----- Original Message -----
From: "Ned Freed" <ned.freed@mrochek.com>
To: "t.petch" <ietfc@btconnect.com>
Cc: "Stephan Bosch" <stephan@rename-it.nl>; "Murray S. Kucherawy"
<superuser@gmail.com>; "IETF Apps Discuss" <apps-discuss@ietf.org>
Sent: Saturday, January 11, 2014 4:21 PM
Subject: Re: [apps-discuss] Working Group Last
Calldraft-ietf-appsawg-sieve-duplicate


> > Mostly inline, but my big comment which gets lost in the detail is
about
> > scope of caches.  You say
> > "there is only one 'cache' (in the document it is called the
duplicate
> > tracking list)"
>
> > Really, worldwide, like the DNS root?-)
>
> The phrase "only one cache" appears nowhere in the document that I can
see. In
> fact the word "cache" doesn't appear anywhere, which seems correct
given that
> nothing in this document involves using a cache, at least not in the
sense that
> I (or Wikipedia) understand the term.
>
> > Hitherto, as I understand it, sieve has had no state; a filter is
> > applied to a stream of messages and that is it, forget it and start
> > again.
>
> That's completely incorrect. The obvious counterexample is the
vacation
> extension, which has essentially been part of sieve from the
beginning. Another
> example is the notify extension. And in both of these cases the
maintained
> state is used to suppress duplicate messages. So they have a lot in
common with
> this extension.
>
> More generally, sieve implementations often impose limits on the
number of
> times some operation can be performed. Sometimes this is per-script,
but
> sometimes it isn't. And that also requires state.
>
> As a result sieve implementors are quite familiar with the ins and
outs of
> state storage.
>
> > This adds state.  This then introduces the question of scope.
>
> Nope. It's also been there pretty much from day one in Sieve.
>
> > If I get the same message from two different ISP (which I  do), will
> > that be detected?  I expect not.
>
> It depends on where your sieve is store and evaluated. If it's a
single sieve
> being evaluated by your MUA that sees both messages, then yes, it will
be
> detected. If you have separate sieves attached to your ISP accounts,
where each
> one only sees one copy of the message, then no, it won't.
>
> To put it another way, the "scope" of the state associated with a
script
> is always the script itself. Nothing more and nothing less. And the
current
> document does in fact say this, in the first paragraph of section 1:
>
>    It adds a test to determine whether a certain message
>    was seen before by the delivery agent in an earlier execution of
***the
>    Sieve script.***
>
> And it doesn't matter if your two sieves are both "yours" for some
value of
> "yours", they are identical, and if the two script instances are in
fact under
> shared admiistrative control so their storage could be coordinated.
Why?
> Because there's no way to devine the intent of having two separate
instances of
> a script. Maybe you want them to share some context. Or maybe for some
reason
> you don't. There's no way to communicate your intent in any case (and
even if
> there was there's no chance users would understand such a facility),
so the
> only sensible thing to do is to handle them separately.
>
> > When those ISP outsource their MX to
> > the same third party, will that be detected?
>
> MX outsourcing has nothing to do with Sieve. Sieves are by definition
evaluated
> around the time of final delivery. A secondary MX by definition is not
> performing final delivery.
>
> Now, of course you can operate sieve outside of the context where it
is
> specified. But that's not something sieve specifications have to deal
with.
>
> > I expect not as long as
> > they have different mail domains.
>
> Mail domains have nothing to do with it either. Examples abound where
users
> have multiple mail domains associated with a single server or the
handling of a
> single mail domain is spread across multiple administrative domains.
>
> But even this made sense, it wouldn't matter. The scope of storate
associated
> with a script is always just that script instance.
>
> > At what point is there a single cache?
>
> Again, this isn't a cache, at least not in the sense I understand the
term. But
> in any case, storage is per-script, that is, every sieve script gets
its own
> separate space for storing duplicate information.
>
> > When I used multiple mailboxes for the same mail domain?
>
> Those would each have separate scripts. You could choose to set them
to be the
> same script, but that doesn't make them the same instance.
>
> > Only when I use a specific  mailbox? or when?
>
> > In a sense it does not matter because it only effects the user
> > experience and not the protocol on the wire, but I expect that users
> > will care if the implementation on ISP A gives totally different
results
> > to ISP B.  And of course, when there is more than one cache
(worldwide
> > :-), then operators of this facility will need more resources to
> > maintain them.
>
> You're assuming vast complexity in the sieve space which AFAIK does
not exist.
> (There is in fact vast complexity in the space, but it's along fairly
different
> axes than the one you talk about here. And since almost all of lies
far
> outside the usage context defined by the specifications, it is not
relevant
> here.)
>
> And perhaps more to the point, we have considerable experience with
duplicate
> elimination associated with the sieve vacation extension. In 10+ years
of use,
> I can't recall a single complaint about vacation duplicates that
wasn't
> associated with either a bug or some species of outright storage
failure.
> (Indeed, far and away the most common complaint we see in regards to
vacation
> is that the suppression mechanisms work too well and fail to send
messages when
> they are needed.)
>
> > ----- Original Message -----
> > From: "Stephan Bosch" <stephan@rename-it.nl>
> > To: "t.petch" <ietfc@btconnect.com>; "Murray S. Kucherawy"
> > <superuser@gmail.com>; "IETF Apps Discuss" <apps-discuss@ietf.org>
> > Sent: Friday, January 10, 2014 12:01 AM
> > > On 1/2/2014 7:24 PM, t.petch wrote:
> > > > This I-D seems to need more thought.
> > > >
> > > > s.1 "For example, if a member of the list decides to
> > > >    reply to both the user and the mailing list itself, the user
will
> > > >    one copy of the message directly and another through the
mailing
> > > >    list.
> > > >
> > > > Well, they MAY, but they don't on a good list system, such as
the
> > one in
> > > > use here.
>
> I get duplicate messages from IETF lists all the time.
>
> > > >
> > > > "Also, if someone cross-posts over several mailing lists to
> > > >    which the user is subscribed, the user will receive a copy
from
> > each
> > > >    of those lists."
> > > >
> > > > Ditto, not here.
> > >
> > > Ok, but these situations are quite common. I've implemented an
earlier
> > > version of this extension based on user requests. So, what do you
want
> > > me to do? Word this differently so that it is clear that this
> > shouldn't happen for sanely configured mailing lists?
>
> It does happen for sanely configured lists.
>
> > I found the 'will' too forceful; my instant reaction was 'no it
won't'
> > because that is my experience.  Just moderate it slightly, 'will
often'
> > 'may' 'commonly'-  just not a somewhat forceful 'will'
>
> I see no point to making such a change but don't object to it.
>
> > > > "   Duplicate messages are normally detected using the
Message-ID
> > header
> > > >    field, which is required to be unique for each message.  "
> > > >
> > > > REQUIRED maybe, but I seem to recall the malformed-mail I-D
raising
> > the
> > > > possibility that it was not.  In which case, ...?
> > >
> > > I'm not sure how common that is, but you are right:  as the
> > > specification is now, that would cause a false positive. We can
make
> > the
> > > default a bit more complex by combining the Message-ID  with some
> > other
> > > header (Date perhaps?), thereby further reducing the likelihood of
a
> > > false positive. I guess we need to think about that a little more.
>
> No, you really don't. The default has the virtue of simplicity and
working fine
> in almost all cases. The minute you start throwing other fields into
the mix,
> especially ones that tend to be messed with on submission, the less
effective
> the process will be.
>
> > Yes, I think you should allow for the possibility in the I-D - as to
> > how, I am less fussed.  Could be 'outside the scope of' up to
'should
> > detect duplicates and discard as malformed' - just show that it has
been
> > considered.
>
> I have no problem with pointing this out.
>
> > > > s.3
> > > > "an earlier Sieve execution."
> > > > reading on it is apparent that this is any number of executions
> > limited
> > > > by the size of the FIFO cache and the maximum lifetime of
entries in
> > the
> > > > cache.
> > >
> > > Yes. So, what exactly is your comment here? I don't think it is
useful
> > > to mention such detail early in the description.
> > >
> > > > "   Usage:  [":header" <header-name: string> /
> > > >                           ":uniqueid" <value: string>]
> > > >
> > > > Why have two way of doing the same thing?  As I read it, this
test
> > is on
> > > > a header field, so why not have just ":header" with a default of
> > message
> > > > I-D?
> > >
> > > I am not sure what you mean here. The :uniqueid argument does
> > explicitly
> > > not operate (directly) on a message header, but rather on some
string
> > > value composed by the user (using the variables extension). This
can
> > > consist of header field contents, but also on message body or even
> > some
> > > source other than the message being delivered.
>
> > If I understand it aright, the test for duplication can be on
> >  - message id
> >  - header field
> >  - something else
> > which are invoked by <nothing>, :header, :unique-id respectively.
> > Since message id is just another header field, why not merge the
first
> > two with the message id as the default header field if none other is
> > specified?
>
> Because it's a bad idea. The full syntax of the three cases is:
>
>     duplicate
>
>     duplicate :header "foo"
>
>     duplicate :uniqueid "bar"
>
> The only way to "merge" the first two syntactically would be something
> like:
>
>    duplicate :header
>
> But that would be a case of a tagged argument that takes an optional
parameter.
> AFAICT this is not prohibited by RFC 5228, but this would be the first
> extension to use such a construct. And given that it's unnecessary
verbiage
> added to a elegantly simple default case, I'm strongly opposed to
making
> such a change.
>
> > > > And what happens if I use header field X in one execution and
then
> > > > header field Y in another? I presume separate caches for X and
Y, in
> > > > which case, duplicates may not be detected.
> > >
> > > No, there is only one 'cache' (in the document it is called the
> > > duplicate tracking list). See the following text:
> > >
> > >  The "duplicate" test MUST track an unique ID value independent of
its
> > >  source.  This means that it does not matter whether values are
> > >  obtained from the message ID header, from an arbitrary header
> > >  specified using the ":header" argument or explicitly from the
> > >  ":uniqueid" argument.
>
> > see above
>
> And see my response. I guess I have no objection to adding a statement
> along the lines of "stored information about duplciates is always
associated
> with a single script" or something similar, but I don't see it as
necessary.
>
> > > Some examples follow this text. Do you mean that this needs to be
> > > clarified more?
> > >
> > > > The use of multiple fields
> > > > opens up all sorts of complications that need more explanation
> > depending
> > > > on the concept of the scope of the operation, which I do not see
> > clearly
> > > > explained.
> > >
> > > I am not sure what you mean here. I am assuming this comment is
not
> > > relevant given the above. Please clarify otherwise.
> > >
> > > > "The user can explicitly control the
> > > >    length of this expiration time by means of the ":seconds"
> > argument,
> > > >    which is always specified in seconds.  "
> > > >
> > > > seconds seems short to me.  On the IETF lists, I typically see a
gap
> > of
> > > > several hours between a message on one list and a message on
another
> > > > list, with four hours being the norm.  I would regard 5 minutes
as
> > the
> > > > minimum and 36 hours, or perhaps less, as the maximum.
> > >
> > > Given the vacation-seconds extension, the use of a seconds
granularity
> > > is not strange in the Sieve realm.
> > >
> > > I like the flexibility of using seconds (mailinglists are not the
only
> > > application area of this extension), but I am not against changing
it
> > to
> > > :minutes per se. Do any other people have thoughts?
>
> > Ok but I just got a duplicate, once via the ietf announce list, once
via
> > the ietf main list, and they were 10 hours apart.  For me, this is
> > typical, hours not seconds.
>
> The history of vacation seems precisely on point here. The origincal
vacation
> extension only had a :days parameter, because that's what people
thought
> the finest granularity needed would be.
>
> But that turned out to be wrong, and we had to create a second RFC,
with
> all the associated pother, not to mention grotting up the require
namespace,
> to fix it by adding :seconds.
>
> The truth is we don't know what the finest granularity needs to be
here. But
> we do know three things:
>
> (1) The chances it's less than a second are extremely small.
> (2) You can always express a coarser granularity using a finer one,
but not
>     vice versa.
> (3) Fixing this things after the fact is a big PITA.
>
> I therefore think seconds is the right choice.
>
> > > > "leading and trailing whitespace MUST first be trimmed from the
> > value"
> > > >
> > > > This is a can of worms.  Normalisation often appears on these
lists
> > > > without, usually, a satisfactory answer, let alone the issues of
> > i18n.
> > > > More needs to be considered here.
> > >
> > > This mainly serves as a means to prevent stray white space from
> > messing
> > > with the string match. The core Sieve language also does this for
> > > instance for the header test. And how would i18n be relevant here?
>
> > Read RFC6532; that you have not referenced it makes me think that
you
> > have not considered i18n which I would regard as remiss nowadays.
>
> I coauthored RFC 6532 and completely fail to see any relevance. In
particular,
> if two messages are in fact duplicates, don't you think they're going
to be
> normalized the same way?
>
> Put another way, while it's a well established fact that various
intermediaries
> muck around with header whitespace, I've yet to hear of intermediaries
playing
> normalization games. Absent evidence of even the existence of such
things, let
> alone sufficient information for how you'd want to deal with them, I'm
> completely comfortable with this document not saying anything on this
topic.
>
> Ned
>



From ned.freed@mrochek.com  Tue Jan 14 08:23:36 2014
Return-Path: <ned.freed@mrochek.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08DBD1AE127 for <apps-discuss@ietfa.amsl.com>; Tue, 14 Jan 2014 08:23:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.44
X-Spam-Level: 
X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uWbwceYJWCok for <apps-discuss@ietfa.amsl.com>; Tue, 14 Jan 2014 08:23:34 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 0E1301AE129 for <apps-discuss@ietf.org>; Tue, 14 Jan 2014 08:23:34 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P34YELLMLC002EKB@mauve.mrochek.com> for apps-discuss@ietf.org; Tue, 14 Jan 2014 08:18:20 -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 <01P2SI6PLQJK0000AS@mauve.mrochek.com>; Tue, 14 Jan 2014 08:18:16 -0800 (PST)
Message-id: <01P34YEJICZS0000AS@mauve.mrochek.com>
Date: Tue, 14 Jan 2014 08:15:01 -0800 (PST)
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Tue, 14 Jan 2014 15:37:25 +0000" <002801cf113e$93167200$4001a8c0@gateway.2wire.net>
References: <CAL0qLwZqJPTssNVLLaSjAP5wqteZ==fuawNF+WUZYvi+YWV1UQ@mail.gmail.com> <00a301cf07e8$01352160$4001a8c0@gateway.2wire.net> <52CF384D.3080502@rename-it.nl> <005501cf0eca$faf86840$4001a8c0@gateway.2wire.net> <01P30W782SVK0000AS@mauve.mrochek.com> <002801cf113e$93167200$4001a8c0@gateway.2wire.net>
To: "t.petch" <ietfc@btconnect.com>
Cc: Stephan Bosch <stephan@rename-it.nl>, Ned Freed <ned.freed@mrochek.com>, IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Working Group Last Calldraft-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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Jan 2014 16:23:36 -0000

> Finally, I am surprised that you do not see 'the internal duplicate
> tracking list' as a cache - I read the description of this mechanism
> and thought, this is a cache, and cache is so much easier to type
> (and read) than 'the internal duplicate tracking list' so I used that
> for the purposes of this thread.

A cache is a secondary mechanism that provides a faster way to get at
frequently accessed data. (At least that's what every reference I can
find says, more or less.) This facility fails to meet that definition in
at least two ways: It's not secondary to anything (unless you count the
end user, which seems a bit silly), and it's not there to provide a performance
boost.

				Ned

From arnt@gulbrandsen.priv.no  Tue Jan 14 08:52:11 2014
Return-Path: <arnt@gulbrandsen.priv.no>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EDCB1AE0D6 for <apps-discuss@ietfa.amsl.com>; Tue, 14 Jan 2014 08:52:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pSubnkceazrG for <apps-discuss@ietfa.amsl.com>; Tue, 14 Jan 2014 08:52:09 -0800 (PST)
Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id 896021AE0F6 for <apps-discuss@ietf.org>; Tue, 14 Jan 2014 08:52:08 -0800 (PST)
Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 4D88CFA0038; Tue, 14 Jan 2014 16:51:56 +0000 (UTC)
Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1389718315-23118-23118/11/1; Tue, 14 Jan 2014 16:51:55 +0000
Date: Tue, 14 Jan 2014 17:51:58 +0100
From: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
To: Ned Freed <ned.freed@mrochek.com>
Message-Id: <20140114165153.GA402@gulbrandsen.priv.no>
References: <CAL0qLwZqJPTssNVLLaSjAP5wqteZ==fuawNF+WUZYvi+YWV1UQ@mail.gmail.com> <00a301cf07e8$01352160$4001a8c0@gateway.2wire.net> <52CF384D.3080502@rename-it.nl> <005501cf0eca$faf86840$4001a8c0@gateway.2wire.net> <01P30W782SVK0000AS@mauve.mrochek.com> <002801cf113e$93167200$4001a8c0@gateway.2wire.net> <01P34YEJICZS0000AS@mauve.mrochek.com>
In-Reply-To: <01P34YEJICZS0000AS@mauve.mrochek.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Stephan Bosch <stephan@rename-it.nl>, IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Working Group Last Calldraft-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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Jan 2014 16:52:11 -0000

On Tue, Jan 14, 2014 at 08:15:01AM -0800, Ned Freed wrote:
> > Finally, I am surprised that you do not see 'the internal duplicate
> > tracking list' as a cache - I read the description of this mechanism
> > and thought, this is a cache, and cache is so much easier to type
> > (and read) than 'the internal duplicate tracking list' so I used that
> > for the purposes of this thread.
> 
> A cache is a secondary mechanism that provides a faster way to get at
> frequently accessed data. (At least that's what every reference I can
> find says, more or less.)

I've also seen it used as "data structure that's permitted to throw
contents away", ie. a where a miss has a cost other than performance.

I don't care one way or another.

Arnt

From hsantos@isdg.net  Tue Jan 14 12:09:53 2014
Return-Path: <hsantos@isdg.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A6E01AE23A for <apps-discuss@ietfa.amsl.com>; Tue, 14 Jan 2014 12:09:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.002
X-Spam-Level: 
X-Spam-Status: No, score=-102.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HUcNLaf26Ufn for <apps-discuss@ietfa.amsl.com>; Tue, 14 Jan 2014 12:09:50 -0800 (PST)
Received: from news.winserver.com (pop3.winserver.com [208.247.131.9]) by ietfa.amsl.com (Postfix) with ESMTP id 97B851AE232 for <apps-discuss@ietf.org>; Tue, 14 Jan 2014 12:09:50 -0800 (PST)
DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1926; t=1389730177; h=Received:Received: Received:Received:Message-ID:Date:From:Organization:To:Subject: List-ID; bh=yT1jOYJF2ya3bSgEFme5AhbsMBw=; b=qdzVcaeGuKcmD4Wr6iis Ko2Ro4TWFJT+Bbqb7h7y2nqCkx3daIKPwVflCkSzLL+MrkzYr+1KmFV2ROjXPbii 2rl34WbMECnnttDaWSBOdTJXLrGBLc0u5Bj1Q50fgSWodCgB1BoCt+NcyZFeuwqU Uzg5bBLYwdZcghaJhzSJiuA=
Received: by winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Tue, 14 Jan 2014 15:09:37 -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 3307646398.43621.5440; Tue, 14 Jan 2014 15:09:36 -0500
DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1926; t=1389729611; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=PGbhAIj CMQ5qz565anRmST23ke9huZhN/56irSmM6oQ=; b=RRVYqjtcyqTEEouerkZ3tI4 pCV3aecpe2fn9q8edTJJk9kSvhepUBelkv2oRRfgOIs0shF5TYeaUAw5H+KwaDyG Ma8ULWa7imXdqqTHk6qxJkvlUi5/0ZrUEeNlQ07t/l9mTOK++0dpmTAbYMlPY10c 62ivjbBgzWn7XDeNXTHo=
Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.4) for apps-discuss@ietf.org; Tue, 14 Jan 2014 15:00:11 -0500
Received: from [192.168.1.2] ([99.121.4.27]) by beta.winserver.com (Wildcat! SMTP v7.0.454.4) with ESMTP id 2753957833.9.6968; Tue, 14 Jan 2014 15:00:10 -0500
Message-ID: <52D5997F.7090608@isdg.net>
Date: Tue, 14 Jan 2014 15:09:35 -0500
From: Hector Santos <hsantos@isdg.net>
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: Ned Freed <ned.freed@mrochek.com>
References: <CAL0qLwZqJPTssNVLLaSjAP5wqteZ==fuawNF+WUZYvi+YWV1UQ@mail.gmail.com> <00a301cf07e8$01352160$4001a8c0@gateway.2wire.net> <52CF384D.3080502@rename-it.nl> <005501cf0eca$faf86840$4001a8c0@gateway.2wire.net> <01P30W782SVK0000AS@mauve.mrochek.com> <002801cf113e$93167200$4001a8c0@gateway.2wire.net> <01P34YEJICZS0000AS@mauve.mrochek.com>
In-Reply-To: <01P34YEJICZS0000AS@mauve.mrochek.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Stephan Bosch <stephan@rename-it.nl>, IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Working Group Last Calldraft-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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Jan 2014 20:09:53 -0000

FWIW, I read section 3 as a functional description and need for a 
secondary "Session Cache" design in order to:

   - Reduce redundancy,
   - Lower the API overhead, there by
   - Speeding up lookups, and overall
   - Improving the performance of the Session.

Perhaps "Internal Duplicate Tracking List" and its lengthy description 
can be reduced to suggesting a "Session Cache" should be considered to 
lower lookup overhead.  You certainly don't need it as the main dupe 
ID database can be one and the same.   But I can certainly see where a 
smaller, lightweight "Session-only Cache" list is remembered during an 
session instance.

What will probably help is a process outline of the lookup:

     - Check Session Cache List (Internal Duplicate Tracking List)
        - Found, return TRUE
     - Check Main ID database
        - Found,
           - is Expired, reset expiration
           - Add to Session Cache
           - return TRUE
        - Add to Main ID Data
        - Add to Session Cache,
        - return TRUE

--
HLS


On 1/14/2014 11:15 AM, Ned Freed wrote:
>> Finally, I am surprised that you do not see 'the internal duplicate
>> tracking list' as a cache - I read the description of this mechanism
>> and thought, this is a cache, and cache is so much easier to type
>> (and read) than 'the internal duplicate tracking list' so I used that
>> for the purposes of this thread.
>
> A cache is a secondary mechanism that provides a faster way to get at
> frequently accessed data. (At least that's what every reference I can
> find says, more or less.) This facility fails to meet that definition in
> at least two ways: It's not secondary to anything (unless you count the
> end user, which seems a bit silly), and it's not there to provide a performance
> boost.
>
> 				Ned
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>

-- 
HLS



From wwwrun@rfc-editor.org  Tue Jan 14 21:17:47 2014
Return-Path: <wwwrun@rfc-editor.org>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5F571AE2BE; Tue, 14 Jan 2014 21:17:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.44
X-Spam-Level: 
X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iawSzjBZ-Zzf; Tue, 14 Jan 2014 21:17:45 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id 7F3501AE2B2; Tue, 14 Jan 2014 21:17:45 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id D3C897FC175; Tue, 14 Jan 2014 21:17:33 -0800 (PST)
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
From: rfc-editor@rfc-editor.org
Message-Id: <20140115051733.D3C897FC175@rfc-editor.org>
Date: Tue, 14 Jan 2014 21:17:33 -0800 (PST)
Cc: drafts-update-ref@iana.org, apps-discuss@ietf.org, rfc-editor@rfc-editor.org
Subject: [apps-discuss] RFC 7103 on Advice for Safe Handling of Malformed Messages
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Jan 2014 05:17:47 -0000

A new Request for Comments is now available in online RFC libraries.

        
        RFC 7103

        Title:      Advice for Safe Handling of 
                    Malformed Messages 
        Author:     M. Kucherawy, G. Shapiro,
                    N. Freed
        Status:     Informational
        Stream:     IETF
        Date:       January 2014
        Mailbox:    superuser@gmail.com, 
                    gshapiro@proofpoint.com, 
                    ned.freed@mrochek.com
        Pages:      24
        Characters: 48387
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-appsawg-malformed-mail-11.txt

        URL:        http://www.rfc-editor.org/rfc/rfc7103.txt

Although Internet message formats have been precisely defined since
the 1970s, authoring and handling software often shows only mild
conformance to the specifications.  The malformed messages that
result are non-standard.  Nonetheless, decades of experience have
shown that using some tolerance in the handling of the malformations
that result is often an acceptable approach and is better than
rejecting the messages outright as nonconformant.  This document
includes a collection of the best advice available regarding a
variety of common malformed mail situations; it is to be used as
implementation guidance.

This document is a product of the Applications Area Working Group Working Group of the IETF.


INFORMATIONAL: This memo provides information for the Internet community.
It does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/search/rfc_search.php
For downloading RFCs, see http://www.rfc-editor.org/rfc.html

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC



From erlend@hamnaberg.net  Wed Jan 15 06:08:46 2014
Return-Path: <erlend@hamnaberg.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BC4D1AE37C for <apps-discuss@ietfa.amsl.com>; Wed, 15 Jan 2014 06:08:46 -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 liA9uNBP4IOO for <apps-discuss@ietfa.amsl.com>; Wed, 15 Jan 2014 06:08:43 -0800 (PST)
Received: from mail-ob0-f171.google.com (mail-ob0-f171.google.com [209.85.214.171]) by ietfa.amsl.com (Postfix) with ESMTP id B107C1AE0D7 for <apps-discuss@ietf.org>; Wed, 15 Jan 2014 06:08:43 -0800 (PST)
Received: by mail-ob0-f171.google.com with SMTP id wm4so1179680obc.2 for <apps-discuss@ietf.org>; Wed, 15 Jan 2014 06:08:31 -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:content-type; bh=cC7kSpajG+HduIbJX7tgw/m+JF0U4ATgO9qF+SL+Ueo=; b=Jft+sGz43jnnSQCe/zmi0SeA8HK4KAnffU99flJ8kZVid7tChAiVr2mUeCcLR60PnL MbpEQV1VoAqXxyVRCjFRSPpt5zlI6qxCkp2vyjvIaW0rBOaYrraa/P+W01eUq41FgDbZ zGMyAGqpcQzPewlCrgO9uwEUOh4CA677QCbL06+IjAtPni2Jhq0f9m+qBzC2qoXcRp8i sFGAj+laqVb9q+Jl97eHi01f+l7kruaQqdXYBiNvuIknzXqwiSQHukgWOLFMTcwBKscM g9Vdq6mY1fBfRycVPODcVGIeloIiZTpRgMTWP0DMoKnVDT6R0UblufI+2Seuo1f2mdTY WMeg==
X-Gm-Message-State: ALoCoQlXQeCMdYNqPhMtlY9XbdgbB9X0yN3JlA+tVkLm7KcAwarGSx0K877QbS8cm0IM5vec54He
MIME-Version: 1.0
X-Received: by 10.182.102.7 with SMTP id fk7mr1929204obb.28.1389794911704; Wed, 15 Jan 2014 06:08:31 -0800 (PST)
Received: by 10.182.160.98 with HTTP; Wed, 15 Jan 2014 06:08:31 -0800 (PST)
X-Originating-IP: [80.203.193.158]
In-Reply-To: <20140115140544.27701.78043.idtracker@ietfa.amsl.com>
References: <20140115140544.27701.78043.idtracker@ietfa.amsl.com>
Date: Wed, 15 Jan 2014 15:08:31 +0100
Message-ID: <CAGuwm8V+cFGE4aYP4rsZtGQR3_NPBOxf_t_BRgfxQbbTvOJTVQ@mail.gmail.com>
From: Erlend Hamnaberg <erlend@hamnaberg.net>
To: apps-discuss@ietf.org
Content-Type: multipart/alternative; boundary=089e015369f005e9ed04f002d87c
Subject: [apps-discuss] Fwd: New Version Notification for draft-hamnaberg-publish-link-relation-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Jan 2014 14:08:46 -0000

--089e015369f005e9ed04f002d87c
Content-Type: text/plain; charset=ISO-8859-1

My first Internet Draft, please be nice =)

Please give feedback.

Not sure if this is the correct mailing list to send this to.

Please let me know if I should send it somewhere else.

Yours,

Erlend

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Wed, Jan 15, 2014 at 3:05 PM
Subject: New Version Notification for
draft-hamnaberg-publish-link-relation-00.txt
To: Erlend Hamnaberg <erlend@hamnaberg.net>



A new version of I-D, draft-hamnaberg-publish-link-relation-00.txt
has been successfully submitted by Erlend Hamnaberg and posted to the
IETF repository.

Name:           draft-hamnaberg-publish-link-relation
Revision:       00
Title:          The 'publish' Link Relation Type
Document date:  2014-01-15
Group:          Individual Submission
Pages:          6
URL:
http://www.ietf.org/internet-drafts/draft-hamnaberg-publish-link-relation-00.txt
Status:
https://datatracker.ietf.org/doc/draft-hamnaberg-publish-link-relation/
Htmlized:
http://tools.ietf.org/html/draft-hamnaberg-publish-link-relation-00


Abstract:
   This memo defines a 'publish' link relation and provides a number of
   examples.




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

--089e015369f005e9ed04f002d87c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>My first Internet Draft, please be nice =3D)</div><di=
v><br></div>Please give feedback.<div><br></div><div>Not sure if this is th=
e correct mailing list to send this to.=A0</div><div><br></div><div>Please =
let me know if I should send it somewhere else.</div>
<div><br></div><div>Yours,=A0</div><div><br></div><div>Erlend<br><br><div c=
lass=3D"gmail_quote">---------- Forwarded message ----------<br>From: <b cl=
ass=3D"gmail_sendername"></b> <span dir=3D"ltr">&lt;<a href=3D"mailto:inter=
net-drafts@ietf.org" target=3D"_blank">internet-drafts@ietf.org</a>&gt;</sp=
an><br>

Date: Wed, Jan 15, 2014 at 3:05 PM<br>Subject: New Version Notification for=
 draft-hamnaberg-publish-link-relation-00.txt<br>To: Erlend Hamnaberg &lt;<=
a href=3D"mailto:erlend@hamnaberg.net" target=3D"_blank">erlend@hamnaberg.n=
et</a>&gt;<br>
<br>
<br><br>
A new version of I-D, draft-hamnaberg-publish-link-relation-00.txt<br>
has been successfully submitted by Erlend Hamnaberg and posted to the<br>
IETF repository.<br>
<br>
Name: =A0 =A0 =A0 =A0 =A0 draft-hamnaberg-publish-link-relation<br>
Revision: =A0 =A0 =A0 00<br>
Title: =A0 =A0 =A0 =A0 =A0The &#39;publish&#39; Link Relation Type<br>
Document date: =A02014-01-15<br>
Group: =A0 =A0 =A0 =A0 =A0Individual Submission<br>
Pages: =A0 =A0 =A0 =A0 =A06<br>
URL: =A0 =A0 =A0 =A0 =A0 =A0<a href=3D"http://www.ietf.org/internet-drafts/=
draft-hamnaberg-publish-link-relation-00.txt" target=3D"_blank">http://www.=
ietf.org/internet-drafts/draft-hamnaberg-publish-link-relation-00.txt</a><b=
r>
Status: =A0 =A0 =A0 =A0 <a href=3D"https://datatracker.ietf.org/doc/draft-h=
amnaberg-publish-link-relation/" target=3D"_blank">https://datatracker.ietf=
.org/doc/draft-hamnaberg-publish-link-relation/</a><br>
Htmlized: =A0 =A0 =A0 <a href=3D"http://tools.ietf.org/html/draft-hamnaberg=
-publish-link-relation-00" target=3D"_blank">http://tools.ietf.org/html/dra=
ft-hamnaberg-publish-link-relation-00</a><br>
<br>
<br>
Abstract:<br>
=A0 =A0This memo defines a &#39;publish&#39; link relation and provides a n=
umber of<br>
=A0 =A0examples.<br>
<br>
<br>
<br>
<br>
Please note that it may take a couple of minutes from the time of submissio=
n<br>
until the htmlized version and diff are available at <a href=3D"http://tool=
s.ietf.org" target=3D"_blank">tools.ietf.org</a>.<br>
<br>
The IETF Secretariat<br>
<br>
</div><br></div></div>

--089e015369f005e9ed04f002d87c--

From darrel.miller@gmail.com  Wed Jan 15 06:18:59 2014
Return-Path: <darrel.miller@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EBB31AE358 for <apps-discuss@ietfa.amsl.com>; Wed, 15 Jan 2014 06:18:59 -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 C1-G5pAGp1CU for <apps-discuss@ietfa.amsl.com>; Wed, 15 Jan 2014 06:18:57 -0800 (PST)
Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 504921AE0D2 for <apps-discuss@ietf.org>; Wed, 15 Jan 2014 06:18:57 -0800 (PST)
Received: by mail-ig0-f174.google.com with SMTP id hl1so7799859igb.1 for <apps-discuss@ietf.org>; Wed, 15 Jan 2014 06:18:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=fjVzAAWzfgJEOYHx7DJeugKOdSAxV0f5kuMYRwUpejU=; b=m8O6b3lT5FeEskle6S/IuqAGwU4gFAQSY+9hFnKwGxCzRWqzarDmv6pVsJST7haIeY gB4dZoKUe2mIa6aA5fum0T8Akt1abyePTsLWJvPfryb2BLa3XuGDZRzqFxoLXdgdXEPt 2EXdFFbasZxwwiHLIDqP6wDzndu/LRnB6We1fFCZscvDgnakEuB8A3CRctn9Nlcls302 k4ZotYeX/n3qtD4h8z8WpFst9w6kvPB9+EFjRdGT0y4R8Vn9mcW/HhTQ3R7DeWzTR2jS GtDIPsphR4EVobGYA9TbfD5iUTxzx6QvDcLf02GPPmhu4+8fWrNVbZHCiABNn39cbzG1 KrxA==
MIME-Version: 1.0
X-Received: by 10.43.0.202 with SMTP id nn10mr2525458icb.54.1389795525475; Wed, 15 Jan 2014 06:18:45 -0800 (PST)
Received: by 10.42.195.206 with HTTP; Wed, 15 Jan 2014 06:18:45 -0800 (PST)
In-Reply-To: <CAGuwm8V+cFGE4aYP4rsZtGQR3_NPBOxf_t_BRgfxQbbTvOJTVQ@mail.gmail.com>
References: <20140115140544.27701.78043.idtracker@ietfa.amsl.com> <CAGuwm8V+cFGE4aYP4rsZtGQR3_NPBOxf_t_BRgfxQbbTvOJTVQ@mail.gmail.com>
Date: Wed, 15 Jan 2014 09:18:45 -0500
Message-ID: <CAKioOqtUqJTMrx2U3qb9dhs3pAq-ZZ+3QCJcEgozyvaG1YLZGw@mail.gmail.com>
From: Darrel Miller <darrel.miller@gmail.com>
To: IETF Apps Discuss <apps-discuss@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-hamnaberg-publish-link-relation-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: darrel@tavis.ca
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Jan 2014 14:18:59 -0000

Hi Erlend,

I think this is an excellent idea.  Do you think it would be worth
suggesting that the Location header be set in the response to identify
the location of the "published resource"?  Can we assume that "to
publish" means to publish on the internet and that the result is
itself a resource with a URI?  Or is that an unnecessary restriction?

Darrel



On Wed, Jan 15, 2014 at 9:08 AM, Erlend Hamnaberg <erlend@hamnaberg.net> wrote:
> My first Internet Draft, please be nice =)
>
> Please give feedback.
>
> Not sure if this is the correct mailing list to send this to.
>
> Please let me know if I should send it somewhere else.
>
> Yours,
>
> Erlend
>
> ---------- Forwarded message ----------
> From: <internet-drafts@ietf.org>
> Date: Wed, Jan 15, 2014 at 3:05 PM
> Subject: New Version Notification for
> draft-hamnaberg-publish-link-relation-00.txt
> To: Erlend Hamnaberg <erlend@hamnaberg.net>
>
>
>
> A new version of I-D, draft-hamnaberg-publish-link-relation-00.txt
> has been successfully submitted by Erlend Hamnaberg and posted to the
> IETF repository.
>
> Name:           draft-hamnaberg-publish-link-relation
> Revision:       00
> Title:          The 'publish' Link Relation Type
> Document date:  2014-01-15
> Group:          Individual Submission
> Pages:          6
> URL:
> http://www.ietf.org/internet-drafts/draft-hamnaberg-publish-link-relation-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-hamnaberg-publish-link-relation/
> Htmlized:
> http://tools.ietf.org/html/draft-hamnaberg-publish-link-relation-00
>
>
> Abstract:
>    This memo defines a 'publish' link relation and provides a number of
>    examples.
>
>
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

From erlend@hamnaberg.net  Wed Jan 15 06:25:23 2014
Return-Path: <erlend@hamnaberg.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95A0F1AE35F for <apps-discuss@ietfa.amsl.com>; Wed, 15 Jan 2014 06:25:23 -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 wwGZh785T2tD for <apps-discuss@ietfa.amsl.com>; Wed, 15 Jan 2014 06:25:22 -0800 (PST)
Received: from mail-oa0-f48.google.com (mail-oa0-f48.google.com [209.85.219.48]) by ietfa.amsl.com (Postfix) with ESMTP id 00D071AE2A8 for <apps-discuss@ietf.org>; Wed, 15 Jan 2014 06:25:21 -0800 (PST)
Received: by mail-oa0-f48.google.com with SMTP id i11so1245621oag.21 for <apps-discuss@ietf.org>; Wed, 15 Jan 2014 06:25:10 -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=UDbAGL2rRePgT7yX4o/96wOSYO8scq0l7wIz5vKqJs8=; b=a1gK3QlnpmeTpinB2DIp4O1qwXNmBUrlHRpzN/PFrfrkDWl3wc8fz2tb/VmJT7Lq4j UlSSWcO2OB/kXHPwH/97mpaymUw4f1zEbLKX76iB/t34JP4op4TOGsrVhMiS09AMH3Fv Ib+WadBFO1HblF+WsoBsDivK+DYQKzt5BGu5svCvBEHSYBGkhe3oE3bdPTthN9Z5gTZ/ 0CNAoUJ4ooBQy6ZlYGtbhn4j7oOYJfUGPXfAN7/FlEmeZMbP6voQx7GyxEf5uxXcdVnx 5h3TiSQV01yybqI60cormzr/kKJY4iWZ8Gyru0iG5fZFCO0FnoO2p7SVYR6uP5zYi163 tjpA==
X-Gm-Message-State: ALoCoQlIqwduxc+3RdgkWJkRDcJlKHFGjj4BNM8145Uztu9osO/6/UJuAANq9SOAAtkbx2HZQBHT
MIME-Version: 1.0
X-Received: by 10.60.69.38 with SMTP id b6mr1942267oeu.27.1389795909818; Wed, 15 Jan 2014 06:25:09 -0800 (PST)
Received: by 10.182.160.98 with HTTP; Wed, 15 Jan 2014 06:25:09 -0800 (PST)
X-Originating-IP: [80.203.193.158]
In-Reply-To: <CAKioOqtUqJTMrx2U3qb9dhs3pAq-ZZ+3QCJcEgozyvaG1YLZGw@mail.gmail.com>
References: <20140115140544.27701.78043.idtracker@ietfa.amsl.com> <CAGuwm8V+cFGE4aYP4rsZtGQR3_NPBOxf_t_BRgfxQbbTvOJTVQ@mail.gmail.com> <CAKioOqtUqJTMrx2U3qb9dhs3pAq-ZZ+3QCJcEgozyvaG1YLZGw@mail.gmail.com>
Date: Wed, 15 Jan 2014 15:25:09 +0100
Message-ID: <CAGuwm8UXMw7KE8=WjJwY=mmoAZstED-Btkij+V5b1+PPxGGERw@mail.gmail.com>
From: Erlend Hamnaberg <erlend@hamnaberg.net>
To: darrel@tavis.ca
Content-Type: multipart/alternative; boundary=001a11330aba83ec3f04f00313ab
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-hamnaberg-publish-link-relation-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Jan 2014 14:25:23 -0000

--001a11330aba83ec3f04f00313ab
Content-Type: text/plain; charset=ISO-8859-1

Perhaps.




On Wed, Jan 15, 2014 at 3:18 PM, Darrel Miller <darrel.miller@gmail.com>wrote:

> Hi Erlend,
>
> I think this is an excellent idea.


Thanks.


>  Do you think it would be worth
> suggesting that the Location header be set in the response to identify
> the location of the "published resource"?


Perhaps.
That works only when you publish a single resource, and not a collection of
resources.

I was thinking that the application is defining what publishing means.
You may, for instance, still be required to log in, but now the resource
has become immutable.


> Can we assume that "to
> publish" means to publish on the internet and that the result is
> itself a resource with a URI?

Or is that an unnecessary restriction?
>

That would mean that you can only publish single resources yes?

--
Erlend

--001a11330aba83ec3f04f00313ab
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Perhaps.=A0<div><br></div><div><br></div><div class=3D"gma=
il_extra"><br><br><div class=3D"gmail_quote">On Wed, Jan 15, 2014 at 3:18 P=
M, Darrel Miller <span dir=3D"ltr">&lt;<a href=3D"mailto:darrel.miller@gmai=
l.com" target=3D"_blank">darrel.miller@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Hi Erlend,<br>
<br>
I think this is an excellent idea. </blockquote><div><br></div><div>Thanks.=
</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex">=A0Do you think it would=
 be worth<br>

suggesting that the Location header be set in the response to identify<br>
the location of the &quot;published resource&quot;? =A0</blockquote><div><b=
r></div><div>Perhaps.=A0</div><div>That works only when you publish a singl=
e resource, and not a collection of resources.</div><div><br></div><div>I w=
as thinking that the application is defining what publishing means.</div>
<div>You may, for instance, still be required to log in, but now the resour=
ce has become immutable.</div><div>=A0</div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
Can we assume that &quot;to<br>

publish&quot; means to publish on the internet and that the result is<br>
itself a resource with a URI? =A0</blockquote><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
">Or is that an unnecessary restriction?<br></blockquote><div><br></div><di=
v>
That would mean that you can only publish single resources yes?</div><div><=
br></div><div>--</div><div>Erlend</div></div></div></div>

--001a11330aba83ec3f04f00313ab--

From darrel.miller@gmail.com  Wed Jan 15 06:45:14 2014
Return-Path: <darrel.miller@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6504A1AE373 for <apps-discuss@ietfa.amsl.com>; Wed, 15 Jan 2014 06:45:14 -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 55E-BrALJ4E1 for <apps-discuss@ietfa.amsl.com>; Wed, 15 Jan 2014 06:45:12 -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 4929A1AE387 for <apps-discuss@ietf.org>; Wed, 15 Jan 2014 06:45:12 -0800 (PST)
Received: by mail-ie0-f174.google.com with SMTP id lx4so2095518iec.5 for <apps-discuss@ietf.org>; Wed, 15 Jan 2014 06:45:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=C99FaXqaGF/vjSv/M4DRrsZSzS2EZZKagWYCuZyloIA=; b=RJhWW9nU+pkeyTvpZim8eGOBJoy7AfN04WVPbdZ9rmFjoR3WE/OZ0xicbGYDgiOwgE BuifRAl3TAgzrpxAThKe9iZphL+Hio8jvXiLpOYeF2zLpkrhEY76SSzR7Kr/rD5/jHxq UXFMvjV7p8rYGafKIdaPfDDWmffmYuWQXoyJ8UaU0497Qh5DPKHqouBfayR+uH1ygBEr plqWBuGdocPKrsZH96WajPWqU+fLaN6b8ujY/EHVas7TcHwbdOhD7je/mMBO9NwJ2KkH VLAQWhbuUKsX9uv+sNOZNPXoGjlxCNJ3h9SzqGR+A+Hp6kH4KJ744lFQDJ+3RwZcb3b3 WQAw==
MIME-Version: 1.0
X-Received: by 10.50.30.42 with SMTP id p10mr3124954igh.5.1389797100456; Wed, 15 Jan 2014 06:45:00 -0800 (PST)
Received: by 10.42.195.206 with HTTP; Wed, 15 Jan 2014 06:45:00 -0800 (PST)
In-Reply-To: <CAGuwm8UXMw7KE8=WjJwY=mmoAZstED-Btkij+V5b1+PPxGGERw@mail.gmail.com>
References: <20140115140544.27701.78043.idtracker@ietfa.amsl.com> <CAGuwm8V+cFGE4aYP4rsZtGQR3_NPBOxf_t_BRgfxQbbTvOJTVQ@mail.gmail.com> <CAKioOqtUqJTMrx2U3qb9dhs3pAq-ZZ+3QCJcEgozyvaG1YLZGw@mail.gmail.com> <CAGuwm8UXMw7KE8=WjJwY=mmoAZstED-Btkij+V5b1+PPxGGERw@mail.gmail.com>
Date: Wed, 15 Jan 2014 09:45:00 -0500
Message-ID: <CAKioOqticgRPKdkeGFVRF+SrHdbL1vxj-byPAF=c1vaBo6k=dA@mail.gmail.com>
From: Darrel Miller <darrel.miller@gmail.com>
To: IETF Apps Discuss <apps-discuss@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-hamnaberg-publish-link-relation-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: darrel@tavis.ca
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Jan 2014 14:45:14 -0000

I was assuming that a publish link would use the target URI to publish
the resource at the context URI.  If the context URI happens to
contain links to a set of resources, then the publish processor could
publish that set of resources.

>From your response I take you are seeing this more as service where
you pass some kind of reference/list/collection and the service
publishes resource based on the content of the passed body?   I'm not
sure the two approaches are mutually exclusive, but you are correct
that Location header wouldn't be very useful in the second case.

Darrel

On Wed, Jan 15, 2014 at 9:25 AM, Erlend Hamnaberg <erlend@hamnaberg.net> wrote:
> Perhaps.
>
>
>
>
> On Wed, Jan 15, 2014 at 3:18 PM, Darrel Miller <darrel.miller@gmail.com>
> wrote:
>>
>> Hi Erlend,
>>
>> I think this is an excellent idea.
>
>
> Thanks.
>
>>
>>  Do you think it would be worth
>> suggesting that the Location header be set in the response to identify
>> the location of the "published resource"?
>
>
> Perhaps.
> That works only when you publish a single resource, and not a collection of
> resources.
>
> I was thinking that the application is defining what publishing means.
> You may, for instance, still be required to log in, but now the resource has
> become immutable.
>
>>
>> Can we assume that "to
>> publish" means to publish on the internet and that the result is
>> itself a resource with a URI?
>>
>> Or is that an unnecessary restriction?
>
>
> That would mean that you can only publish single resources yes?
>
> --
> Erlend
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

From erlend@hamnaberg.net  Wed Jan 15 07:24:27 2014
Return-Path: <erlend@hamnaberg.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93D7C1AE3A9 for <apps-discuss@ietfa.amsl.com>; Wed, 15 Jan 2014 07:24:27 -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_34=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 VbVZXTiQuejk for <apps-discuss@ietfa.amsl.com>; Wed, 15 Jan 2014 07:24:26 -0800 (PST)
Received: from mail-oa0-f45.google.com (mail-oa0-f45.google.com [209.85.219.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1B34A1AE37E for <apps-discuss@ietf.org>; Wed, 15 Jan 2014 07:24:26 -0800 (PST)
Received: by mail-oa0-f45.google.com with SMTP id j17so1356787oag.4 for <apps-discuss@ietf.org>; Wed, 15 Jan 2014 07:24:14 -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=6qgnzgO615h11N8jh7cezIpb2AR6SB6qa5V0n/8WYX8=; b=BNZFpCxCiE4tYlTmedJ+xoL9seOJcCLrPU068f8Ba29Onl+WSPClq8KH9726G+Lnvc takq8Bj7ya+sdal631BRVB4NG/XaJY4aHfm8MFIt6mc1JjHRsJjaUK2VMvTNLgZKOsCx T8P055P96w95A89TxETrKr/HORZN61C0wY/LQ9xOvUjcEtc1hpakQT+MiKIyhBKXj54V 6l0lz1ZDbVdHbz2vWC8ItlMJX/V2d8LeGTcuXyF+IKc5eB6/GYH7kb5fGddYZzsph1Hf twdpgwTjl+LMVQ+6qB0n1wJRREIQUUYdXO6aDuBZeWfrkbl9Yj3zpgk7mJoqj6a5YgVG Sw2w==
X-Gm-Message-State: ALoCoQla2UeoTwDgOJnMwSzGSd7vxrp+Jp3TAiZWrltygFCGLMbUuuJ00lqGEOcfdHZ2ON0spUuq
MIME-Version: 1.0
X-Received: by 10.182.84.132 with SMTP id z4mr2197238oby.49.1389799454062; Wed, 15 Jan 2014 07:24:14 -0800 (PST)
Received: by 10.182.160.98 with HTTP; Wed, 15 Jan 2014 07:24:13 -0800 (PST)
X-Originating-IP: [80.203.95.228]
In-Reply-To: <CAKioOqticgRPKdkeGFVRF+SrHdbL1vxj-byPAF=c1vaBo6k=dA@mail.gmail.com>
References: <20140115140544.27701.78043.idtracker@ietfa.amsl.com> <CAGuwm8V+cFGE4aYP4rsZtGQR3_NPBOxf_t_BRgfxQbbTvOJTVQ@mail.gmail.com> <CAKioOqtUqJTMrx2U3qb9dhs3pAq-ZZ+3QCJcEgozyvaG1YLZGw@mail.gmail.com> <CAGuwm8UXMw7KE8=WjJwY=mmoAZstED-Btkij+V5b1+PPxGGERw@mail.gmail.com> <CAKioOqticgRPKdkeGFVRF+SrHdbL1vxj-byPAF=c1vaBo6k=dA@mail.gmail.com>
Date: Wed, 15 Jan 2014 16:24:13 +0100
Message-ID: <CAGuwm8UVOM3Y0FZVthHFycm0s+TgEJibTcUMu+kwanP8c83xew@mail.gmail.com>
From: Erlend Hamnaberg <erlend@hamnaberg.net>
To: darrel@tavis.ca
Content-Type: multipart/alternative; boundary=089e0111c09ac5026604f003e638
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-hamnaberg-publish-link-relation-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Jan 2014 15:24:27 -0000

--089e0111c09ac5026604f003e638
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Jan 15, 2014 at 3:45 PM, Darrel Miller <darrel.miller@gmail.com>wrote:

> I was assuming that a publish link would use the target URI to publish
> the resource at the context URI.  If the context URI happens to
> contain links to a set of resources, then the publish processor could
> publish that set of resources.
>
> Both are viable options. The server decides.
There must be a way to communicate the context uri to the target uri.
There are multiple options here.

1) Link header:

Link: <http://example.com/1234>; rel=self

2) text/uri-list in body
http://example.com/1234\r\n

3) HTML Form in body
source=http://example.com/1234

4) Abuse of the Referer header.

LINK method
Can be used with (1).

POST method
Can be used with (1,2,3).


> From your response I take you are seeing this more as service where
> you pass some kind of reference/list/collection and the service
> publishes resource based on the content of the passed body?


This is one of the possible uses yes.



> I'm not
> sure the two approaches are mutually exclusive, but you are correct
> that Location header wouldn't be very useful in the second case.
>

You are correct that the two approaches are not mutually exclusive.
I am not sure if this link relations should specify _how_ the publishing is
done, this should be implementation specific.

--
Erlend

--089e0111c09ac5026604f003e638
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Wed, Jan 15, 2014 at 3:45 PM, Darrel Miller <span dir=3D"ltr">&l=
t;<a href=3D"mailto:darrel.miller@gmail.com" target=3D"_blank">darrel.mille=
r@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">I was assuming that a publish link would use the target UR=
I to publish<br>

the resource at the context URI. =A0If the context URI happens to<br>
contain links to a set of resources, then the publish processor could<br>
publish that set of resources.<br>
<br></blockquote><div>Both are viable options. The server decides.=A0</div>=
<div>There must be a way to communicate the context uri to the target uri.<=
/div><div>There are multiple options here.</div><div><br></div><div>1) Link=
 header:</div>
<div><br></div><div>Link: &lt;<a href=3D"http://example.com/1234">http://ex=
ample.com/1234</a>&gt;; rel=3Dself=A0</div><div><br></div><div>2) text/uri-=
list in body</div><div><a href=3D"http://example.com/1234\r\n">http://examp=
le.com/1234\r\n</a></div>
<div><br></div><div>3) HTML Form in body</div><div>source=3D<a href=3D"http=
://example.com/1234">http://example.com/1234</a></div><div><br></div><div>4=
) Abuse of the Referer header.</div><div><br></div><div>LINK method</div><d=
iv>
Can be used with (1).</div><div><br></div><div>POST method</div><div>Can be=
 used with (1,2,3).</div><div>=A0</div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb=
(204,204,204);border-left-style:solid;padding-left:1ex">

>From your response I take you are seeing this more as service where<br>
you pass some kind of reference/list/collection and the service<br>
publishes resource based on the content of the passed body? =A0 </blockquot=
e><div><br></div><div>This is one of the possible uses yes.</div><div><br><=
/div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border=
-left-style:solid;padding-left:1ex">
I&#39;m not<br>
sure the two approaches are mutually exclusive, but you are correct<br>
that Location header wouldn&#39;t be very useful in the second case.<br></b=
lockquote><div><br></div><div>You are correct that the two approaches are n=
ot=A0mutually exclusive.</div><div>I am not sure if this link relations sho=
uld specify _how_ the publishing is</div>
<div>done, this should be implementation specific.</div><div><br></div><div=
>--</div><div>Erlend</div></div></div></div>

--089e0111c09ac5026604f003e638--

From Peter.Rushforth@NRCan-RNCan.gc.ca  Wed Jan 15 07:26:52 2014
Return-Path: <Peter.Rushforth@NRCan-RNCan.gc.ca>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89D541ADFE3 for <apps-discuss@ietfa.amsl.com>; Wed, 15 Jan 2014 07:26:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_36=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 e6hEyY_duY5W for <apps-discuss@ietfa.amsl.com>; Wed, 15 Jan 2014 07:26:49 -0800 (PST)
Received: from nrcan.gc.ca (s-bsc-edge1.nrcan.gc.ca [132.156.238.13]) by ietfa.amsl.com (Postfix) with ESMTP id AEE301AE05F for <apps-discuss@ietf.org>; Wed, 15 Jan 2014 07:26:48 -0800 (PST)
Received: from S-BSC-CAS1.nrn.nrcan.gc.ca (132.156.238.11) by S-BSC-EDGE1.nrcan.gc.ca (132.156.238.13) with Microsoft SMTP Server (TLS) id 14.2.347.0; Wed, 15 Jan 2014 10:26:36 -0500
Received: from S-BSC-MBX4.nrn.nrcan.gc.ca ([169.254.4.125]) by S-BSC-CAS1.nrn.nrcan.gc.ca ([fe80::a1cd:5722:74ed:d1fd%21]) with mapi id 14.02.0387.000; Wed, 15 Jan 2014 10:26:36 -0500
From: "Rushforth, Peter" <Peter.Rushforth@NRCan-RNCan.gc.ca>
To: Erlend Hamnaberg <erlend@hamnaberg.net>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Thread-Topic: [apps-discuss] Fwd: New Version Notification for draft-hamnaberg-publish-link-relation-00.txt
Thread-Index: AQHPEftMbHQqmy5ae0q/uZ7Mri3bCZqF5VdQ
Date: Wed, 15 Jan 2014 15:26:36 +0000
Message-ID: <1CD55F04538DEA4F85F3ADF7745464AF24AE62A7@S-BSC-MBX4.nrn.nrcan.gc.ca>
References: <20140115140544.27701.78043.idtracker@ietfa.amsl.com> <CAGuwm8V+cFGE4aYP4rsZtGQR3_NPBOxf_t_BRgfxQbbTvOJTVQ@mail.gmail.com>
In-Reply-To: <CAGuwm8V+cFGE4aYP4rsZtGQR3_NPBOxf_t_BRgfxQbbTvOJTVQ@mail.gmail.com>
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [132.156.238.22]
Content-Type: multipart/alternative; boundary="_000_1CD55F04538DEA4F85F3ADF7745464AF24AE62A7SBSCMBX4nrnnrca_"
MIME-Version: 1.0
Subject: Re: [apps-discuss] Fwd: New Version Notification for	draft-hamnaberg-publish-link-relation-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Jan 2014 15:26:52 -0000

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

Erlend,

I think the publish link relation might be useful in the context of AtomPub=
, but I think that putting the text/uri-list media type in the app:accept l=
ist per your draft is a different meaning from AtomPub, where the list of m=
edia types is of types that can be POSTed to the feed as media entries.  Ie=
 it specifies what happens generically not based on media type.  Perhaps sp=
ecifying an app:collection/atom:link[@rel=3D'publish'][@type=3D'text/uri-li=
st']  would be the right approach?  Not sure about the @type value, since i=
n my understanding the @type advertises what media type should be negoiated=
 with the server, not what should be POSTed.  But perhaps narrowing the sco=
pe of the link to app:collection would alleviate that?

Cheers,
Peter


From: apps-discuss [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Erle=
nd Hamnaberg
Sent: January 15, 2014 09:09
To: apps-discuss@ietf.org
Subject: [apps-discuss] Fwd: New Version Notification for draft-hamnaberg-p=
ublish-link-relation-00.txt

My first Internet Draft, please be nice =3D)

Please give feedback.

Not sure if this is the correct mailing list to send this to.

Please let me know if I should send it somewhere else.

Yours,

Erlend
---------- Forwarded message ----------
From: <internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>>
Date: Wed, Jan 15, 2014 at 3:05 PM
Subject: New Version Notification for draft-hamnaberg-publish-link-relation=
-00.txt
To: Erlend Hamnaberg <erlend@hamnaberg.net<mailto:erlend@hamnaberg.net>>



A new version of I-D, draft-hamnaberg-publish-link-relation-00.txt
has been successfully submitted by Erlend Hamnaberg and posted to the
IETF repository.

Name:           draft-hamnaberg-publish-link-relation
Revision:       00
Title:          The 'publish' Link Relation Type
Document date:  2014-01-15
Group:          Individual Submission
Pages:          6
URL:            http://www.ietf.org/internet-drafts/draft-hamnaberg-publish=
-link-relation-00.txt
Status:         https://datatracker.ietf.org/doc/draft-hamnaberg-publish-li=
nk-relation/
Htmlized:       http://tools.ietf.org/html/draft-hamnaberg-publish-link-rel=
ation-00


Abstract:
   This memo defines a 'publish' link relation and provides a number of
   examples.




Please note that it may take a couple of minutes from the time of submissio=
n
until the htmlized version and diff are available at tools.ietf.org<http://=
tools.ietf.org>.

The IETF Secretariat


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

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{mso-style-priority:99;
	mso-style-link:"Balloon Text Char";
	margin:0cm;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Tahoma","sans-serif";}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.BalloonTextChar
	{mso-style-name:"Balloon Text Char";
	mso-style-priority:99;
	mso-style-link:"Balloon Text";
	font-family:"Tahoma","sans-serif";
	mso-fareast-language:EN-CA;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri","sans-serif";
	mso-fareast-language:EN-US;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"EN-CA" link=3D"blue" vlink=3D"purple">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Erlend,<o:p></o:p></span>=
</p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">I think the publish link =
relation might be useful in the context of AtomPub, but I think that puttin=
g the text/uri-list media type in the app:accept list per
 your draft is a different meaning from AtomPub, where the list of media ty=
pes is of types that can be POSTed to the feed as media entries.&nbsp; Ie i=
t specifies what happens generically not based on media type.&nbsp; Perhaps=
 specifying an app:collection/atom:link[@rel=3D&#8217;publish&#8217;][@type=
=3D&#8217;text/uri-list&#8217;]
 &nbsp;would be the right approach?&nbsp; Not sure about the @type value, s=
ince in my understanding the @type advertises what media type should be neg=
oiated with the server, not what should be POSTed.&nbsp; But perhaps narrow=
ing the scope of the link to app:collection would
 alleviate that?<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Cheers,<o:p></o:p></span>=
</p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D">Peter<o:p></o:p></span></=
p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span><=
/p>
<p class=3D"MsoNormal"><b><span lang=3D"EN-US" style=3D"font-size:10.0pt;fo=
nt-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span =
lang=3D"EN-US" style=3D"font-size:10.0pt;font-family:&quot;Tahoma&quot;,&qu=
ot;sans-serif&quot;"> apps-discuss [mailto:apps-discuss-bounces@ietf.org]
<b>On Behalf Of </b>Erlend Hamnaberg<br>
<b>Sent:</b> January 15, 2014 09:09<br>
<b>To:</b> apps-discuss@ietf.org<br>
<b>Subject:</b> [apps-discuss] Fwd: New Version Notification for draft-hamn=
aberg-publish-link-relation-00.txt<o:p></o:p></span></p>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
<div>
<div>
<p class=3D"MsoNormal">My first Internet Draft, please be nice =3D)<o:p></o=
:p></p>
</div>
<div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<p class=3D"MsoNormal">Please give feedback.<o:p></o:p></p>
<div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class=3D"MsoNormal">Not sure if this is the correct mailing list to send=
 this to.&nbsp;<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class=3D"MsoNormal">Please let me know if I should send it somewhere els=
e.<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class=3D"MsoNormal">Yours,&nbsp;<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">Erlend<o:p></o:p></p>
<div>
<p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">---------- Forwarded =
message ----------<br>
From: &lt;<a href=3D"mailto:internet-drafts@ietf.org" target=3D"_blank">int=
ernet-drafts@ietf.org</a>&gt;<br>
Date: Wed, Jan 15, 2014 at 3:05 PM<br>
Subject: New Version Notification for draft-hamnaberg-publish-link-relation=
-00.txt<br>
To: Erlend Hamnaberg &lt;<a href=3D"mailto:erlend@hamnaberg.net" target=3D"=
_blank">erlend@hamnaberg.net</a>&gt;<br>
<br>
<br>
<br>
A new version of I-D, draft-hamnaberg-publish-link-relation-00.txt<br>
has been successfully submitted by Erlend Hamnaberg and posted to the<br>
IETF repository.<br>
<br>
Name: &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; draft-hamnaberg-publish-link-relat=
ion<br>
Revision: &nbsp; &nbsp; &nbsp; 00<br>
Title: &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;The 'publish' Link Relation Type<b=
r>
Document date: &nbsp;2014-01-15<br>
Group: &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Individual Submission<br>
Pages: &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;6<br>
URL: &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;<a href=3D"http://www.ietf.or=
g/internet-drafts/draft-hamnaberg-publish-link-relation-00.txt" target=3D"_=
blank">http://www.ietf.org/internet-drafts/draft-hamnaberg-publish-link-rel=
ation-00.txt</a><br>
Status: &nbsp; &nbsp; &nbsp; &nbsp; <a href=3D"https://datatracker.ietf.org=
/doc/draft-hamnaberg-publish-link-relation/" target=3D"_blank">
https://datatracker.ietf.org/doc/draft-hamnaberg-publish-link-relation/</a>=
<br>
Htmlized: &nbsp; &nbsp; &nbsp; <a href=3D"http://tools.ietf.org/html/draft-=
hamnaberg-publish-link-relation-00" target=3D"_blank">
http://tools.ietf.org/html/draft-hamnaberg-publish-link-relation-00</a><br>
<br>
<br>
Abstract:<br>
&nbsp; &nbsp;This memo defines a 'publish' link relation and provides a num=
ber of<br>
&nbsp; &nbsp;examples.<br>
<br>
<br>
<br>
<br>
Please note that it may take a couple of minutes from the time of submissio=
n<br>
until the htmlized version and diff are available at <a href=3D"http://tool=
s.ietf.org" target=3D"_blank">
tools.ietf.org</a>.<br>
<br>
The IETF Secretariat<o:p></o:p></p>
</div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
</div>
</div>
</body>
</html>

--_000_1CD55F04538DEA4F85F3ADF7745464AF24AE62A7SBSCMBX4nrnnrca_--

From erlend@hamnaberg.net  Wed Jan 15 07:39:35 2014
Return-Path: <erlend@hamnaberg.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFDDD1AE372 for <apps-discuss@ietfa.amsl.com>; Wed, 15 Jan 2014 07:39:35 -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_36=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 z2uCPqAP8f20 for <apps-discuss@ietfa.amsl.com>; Wed, 15 Jan 2014 07:39:34 -0800 (PST)
Received: from mail-oa0-f41.google.com (mail-oa0-f41.google.com [209.85.219.41]) by ietfa.amsl.com (Postfix) with ESMTP id 461FB1AE370 for <apps-discuss@ietf.org>; Wed, 15 Jan 2014 07:39:33 -0800 (PST)
Received: by mail-oa0-f41.google.com with SMTP id i4so1390966oah.28 for <apps-discuss@ietf.org>; Wed, 15 Jan 2014 07:39:21 -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=GF1D0r4Lo/BfXS4x6eaRGiMg7K1sHxuY4O8u/lyuqQg=; b=gHzQyTsm8SlGocVpPhlZF+R/XPUnS2rwo79bDXX5sh4/DNH1gTYeCXVEj9FUBEld7i 1eq2Y7kR2wiPRbkW+1MaTuMuM8SyU3lo6rNnOH/REWilZt4iHDtwz/JPCFN2XczLnZm/ G8nw/DoyOr/sM8+77BsgwyzI0CdBVijGQRuRpYtkW1K/DT2hf79gD8LSrqgWnC/+cZkA fcWOND0PWV90tB9tg/fvf5NI/RzB8mDfb3JgH5ynXrM3s9EroPYKNsPHcdmaSFZL996B WPCFLi6I0gJs8qRTiWQMACjcOzWrDDO2F8xXa5fT7dkS5qCPRrCMEjSY8NHULz0BYCVP M3tQ==
X-Gm-Message-State: ALoCoQl3p4/leVuwz/Z+jegSqCZ1Uhm0EG9XL4Z5N/VWv9faPNvAd8l2lrP3OpkNHlsGEMX+whVZ
MIME-Version: 1.0
X-Received: by 10.182.84.132 with SMTP id z4mr2262694oby.49.1389800361306; Wed, 15 Jan 2014 07:39:21 -0800 (PST)
Received: by 10.182.160.98 with HTTP; Wed, 15 Jan 2014 07:39:21 -0800 (PST)
X-Originating-IP: [80.203.95.228]
In-Reply-To: <1CD55F04538DEA4F85F3ADF7745464AF24AE62A7@S-BSC-MBX4.nrn.nrcan.gc.ca>
References: <20140115140544.27701.78043.idtracker@ietfa.amsl.com> <CAGuwm8V+cFGE4aYP4rsZtGQR3_NPBOxf_t_BRgfxQbbTvOJTVQ@mail.gmail.com> <1CD55F04538DEA4F85F3ADF7745464AF24AE62A7@S-BSC-MBX4.nrn.nrcan.gc.ca>
Date: Wed, 15 Jan 2014 16:39:21 +0100
Message-ID: <CAGuwm8Uc4FywtZqMb8gwckq-Kx92Y1mApwiDn4Coa2NUdFZQ-g@mail.gmail.com>
From: Erlend Hamnaberg <erlend@hamnaberg.net>
To: "Rushforth, Peter" <Peter.Rushforth@nrcan-rncan.gc.ca>
Content-Type: multipart/alternative; boundary=089e0111c09ad834e504f0041cd9
Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-hamnaberg-publish-link-relation-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Jan 2014 15:39:35 -0000

--089e0111c09ad834e504f0041cd9
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Peter.

On Wed, Jan 15, 2014 at 4:26 PM, Rushforth, Peter <
Peter.Rushforth@nrcan-rncan.gc.ca> wrote:

>  Erlend,
>
>
>
> I think the publish link relation might be useful in the context of
> AtomPub, but I think that putting the text/uri-list media type in the
> app:accept list per your draft is a different meaning from AtomPub, where
> the list of media types is of types that can be POSTed to the feed as med=
ia
> entries.  Ie it specifies what happens generically not based on media
> type.
>

Atompub is just one format where this is useful. I have used a similar
approach with for instance collection+json.

Right. My understanding of atompub is probably flawed.


> Perhaps specifying an
> app:collection/atom:link[@rel=3D=92publish=92][@type=3D=92text/uri-list=
=92]  would be
> the right approach?  Not sure about the @type value, since in my
> understanding the @type advertises what media type should be negotiated
> with the server, not what should be POSTed.  But perhaps narrowing the
> scope of the link to app:collection would alleviate that?
>

Perhaps.

If there is another way of defining this, in hypertext, that would be grand=
.
I will update the draft.

--
Erlend

--089e0111c09ad834e504f0041cd9
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Peter.<div class=3D"gmail_extra"><br><div class=3D"gmail_q=
uote">On Wed, Jan 15, 2014 at 4:26 PM, Rushforth, Peter <span dir=3D"ltr">&=
lt;<a href=3D"mailto:Peter.Rushforth@nrcan-rncan.gc.ca" target=3D"_blank">P=
eter.Rushforth@nrcan-rncan.gc.ca</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">





<div lang=3D"EN-CA" link=3D"blue" vlink=3D"purple">
<div>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d">Erlend,<u></u><u></u></sp=
an></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u>=A0<u></u></span><=
/p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;font-family:&quot;Ca=
libri&quot;,&quot;sans-serif&quot;;color:#1f497d">I think the publish link =
relation might be useful in the context of AtomPub, but I think that puttin=
g the text/uri-list media type in the app:accept list per
 your draft is a different meaning from AtomPub, where the list of media ty=
pes is of types that can be POSTed to the feed as media entries.=A0 Ie it s=
pecifies what happens generically not based on media type.=A0 </span></p></=
div>
</div></blockquote><div><br></div><div>Atompub is just one format where thi=
s is useful. I have used a similar approach with for instance collection+js=
on.</div><div><br></div><div>Right. My understanding of atompub is probably=
 flawed.</div>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div lang=3D"EN-CA" link=3D"bl=
ue" vlink=3D"purple"><div><p class=3D"MsoNormal"><span style=3D"font-size:1=
1.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d"=
>Perhaps specifying an app:collection/atom:link[@rel=3D=92publish=92][@type=
=3D=92text/uri-list=92]
 =A0would be the right approach?=A0 Not sure about the @type value, since i=
n my understanding the @type advertises what media type should be negotiate=
d with the server, not what should be POSTed.=A0 But perhaps narrowing the =
scope of the link to app:collection would
 alleviate that?</span></p></div></div></blockquote><div><br></div><div>Per=
haps.=A0</div><div><br></div><div>If there is another way of defining this,=
 in hypertext, that would be grand.</div><div>I will update the draft.</div=
>
<div>=A0</div><div>--</div><div>Erlend</div></div></div></div>

--089e0111c09ad834e504f0041cd9--

From darrel.miller@gmail.com  Wed Jan 15 07:45:17 2014
Return-Path: <darrel.miller@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C79C1AE37B for <apps-discuss@ietfa.amsl.com>; Wed, 15 Jan 2014 07:45:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level: 
X-Spam-Status: No, score=-1.4 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, 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 tWh6NL-lnC11 for <apps-discuss@ietfa.amsl.com>; Wed, 15 Jan 2014 07:45:16 -0800 (PST)
Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id E0CCD1AE370 for <apps-discuss@ietf.org>; Wed, 15 Jan 2014 07:45:15 -0800 (PST)
Received: by mail-ig0-f170.google.com with SMTP id m12so10684432iga.1 for <apps-discuss@ietf.org>; Wed, 15 Jan 2014 07:45:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type:content-transfer-encoding; bh=ecd12nmWAuI+Q+tLZhWuGE5GQIyNgKaa4bTVcgkknRc=; b=HUUzjSSlMglBWJirzeQ0KJ6vK7mLeeKtDEiL5ByZNsBhqW0Ez6agldfbdqZyEj/Fk2 An0jzMmt5+zSYhQ/GLUEsGfJg/mSdYej/0zDSqARDAdX4Zg+KaeW3PRKjyNeqGFqGJ3U B6SfO1Hgos4i9buwqG66jS43IP68V4VVeDvboD/2BudcZ6SQ/haaR0vLE6Ej3swNhyXW 66cx2Qz43/geKjkWZflLpUjcW1iDegHbMSaL2A1FlTYXJ39vFMEIrP2aL5WJi3F5yqyr +th+MFvfZ/8ByYjAbZrl/d7hubXyN/wozvnTtlugwTX53TK+ER04WY2SwpvcCVCtumSM Mxww==
MIME-Version: 1.0
X-Received: by 10.43.0.202 with SMTP id nn10mr3027776icb.54.1389800704102; Wed, 15 Jan 2014 07:45:04 -0800 (PST)
Received: by 10.42.195.206 with HTTP; Wed, 15 Jan 2014 07:45:04 -0800 (PST)
In-Reply-To: <CAGuwm8Uc4FywtZqMb8gwckq-Kx92Y1mApwiDn4Coa2NUdFZQ-g@mail.gmail.com>
References: <20140115140544.27701.78043.idtracker@ietfa.amsl.com> <CAGuwm8V+cFGE4aYP4rsZtGQR3_NPBOxf_t_BRgfxQbbTvOJTVQ@mail.gmail.com> <1CD55F04538DEA4F85F3ADF7745464AF24AE62A7@S-BSC-MBX4.nrn.nrcan.gc.ca> <CAGuwm8Uc4FywtZqMb8gwckq-Kx92Y1mApwiDn4Coa2NUdFZQ-g@mail.gmail.com>
Date: Wed, 15 Jan 2014 10:45:04 -0500
Message-ID: <CAKioOqsD=OS2x83bmBPVuPdJa+--O2cA1WX02ndB0YrtFk_jZg@mail.gmail.com>
From: Darrel Miller <darrel.miller@gmail.com>
To: "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-hamnaberg-publish-link-relation-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: darrel@tavis.ca
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Jan 2014 15:45:17 -0000

Erlend, Peter,

If someone really wants to advertise what content-type can be used in
the POST, the link hints spec [1] has an 'accept-post' property
intended to do this.

Darrel


[1] http://tools.ietf.org/html/draft-nottingham-link-hint-00#section-3.4

On Wed, Jan 15, 2014 at 10:39 AM, Erlend Hamnaberg <erlend@hamnaberg.net> w=
rote:
> Peter.
>
> On Wed, Jan 15, 2014 at 4:26 PM, Rushforth, Peter
> <Peter.Rushforth@nrcan-rncan.gc.ca> wrote:
>>
>> Erlend,
>>
>>
>>
>> I think the publish link relation might be useful in the context of
>> AtomPub, but I think that putting the text/uri-list media type in the
>> app:accept list per your draft is a different meaning from AtomPub, wher=
e
>> the list of media types is of types that can be POSTed to the feed as me=
dia
>> entries.  Ie it specifies what happens generically not based on media ty=
pe.
>
>
> Atompub is just one format where this is useful. I have used a similar
> approach with for instance collection+json.
>
> Right. My understanding of atompub is probably flawed.
>
>>
>> Perhaps specifying an
>> app:collection/atom:link[@rel=3D=92publish=92][@type=3D=92text/uri-list=
=92]  would be
>> the right approach?  Not sure about the @type value, since in my
>> understanding the @type advertises what media type should be negotiated =
with
>> the server, not what should be POSTed.  But perhaps narrowing the scope =
of
>> the link to app:collection would alleviate that?
>
>
> Perhaps.
>
> If there is another way of defining this, in hypertext, that would be gra=
nd.
> I will update the draft.
>
> --
> Erlend
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

From jan.algermissen@nordsc.com  Wed Jan 15 07:47:15 2014
Return-Path: <jan.algermissen@nordsc.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A18B81AE3B3 for <apps-discuss@ietfa.amsl.com>; Wed, 15 Jan 2014 07:47:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level: 
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 26PdwYiDgN7H for <apps-discuss@ietfa.amsl.com>; Wed, 15 Jan 2014 07:47:14 -0800 (PST)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD621AE3A6 for <apps-discuss@ietf.org>; Wed, 15 Jan 2014 07:47:09 -0800 (PST)
Received: from [172.20.10.5] (tmo-106-199.customers.d1-online.com [80.187.106.199]) by mrelayeu.kundenserver.de (node=mreu4) with ESMTP (Nemesis) id 0M5m7Z-1VAgAW1uCP-00xsa3; Wed, 15 Jan 2014 16:46:55 +0100
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jan Algermissen <jan.algermissen@nordsc.com>
In-Reply-To: <CAGuwm8V+cFGE4aYP4rsZtGQR3_NPBOxf_t_BRgfxQbbTvOJTVQ@mail.gmail.com>
Date: Wed, 15 Jan 2014 16:46:50 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <F1F4C81D-5106-46B9-9A4C-B3C2F696A07F@nordsc.com>
References: <20140115140544.27701.78043.idtracker@ietfa.amsl.com> <CAGuwm8V+cFGE4aYP4rsZtGQR3_NPBOxf_t_BRgfxQbbTvOJTVQ@mail.gmail.com>
To: Erlend Hamnaberg <erlend@hamnaberg.net>
X-Mailer: Apple Mail (2.1510)
X-Provags-ID: V02:K0:uoB99/rNbHkBDcYolkfsvmY45ZSKvDNOdoeRcF4yMDB CJAmq0MXieadRGzTPvh/FX8qhDIYQFmJD5FziAcKuPzWb5/QVu iGuVOTXgxyQldwm3gm66dl/K44OVbwuLNayhqunGOYPSq7NN68 9ZTKSh55OyNB5xRSd10jsNWOpYfzuAvAxGn4VUcKpnhTptY/y3 gSzdM9vVjMFS/W403z3wBKhDEJ4IETJUDchkefeJX+tVTjsrIz /C4lR6ipP4EylqEM8O+/Q521yZIjupSFYvTWrUPO7jRCTbzSbM fiHSxHb3GP/I6lFm0WMEWSyECkWWXR+Q22q7VsFgGxjleN0+7/ KrR8DAU3tO96r8KwxreXdYuwDImL7Pl84mleEaVvfw/Pwme2vD yvqZEj1/cVCmA==
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] New Version Notification for draft-hamnaberg-publish-link-relation-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Jan 2014 15:47:15 -0000

On 15.01.2014, at 15:08, Erlend Hamnaberg <erlend@hamnaberg.net> wrote:

> My first Internet Draft, please be nice =3D)

Great!

>=20
> Please give feedback.

I am not sure I understand what publishing means to you. Can you explain =
your context?

In general, I think that you should model 'publishing' as a state change =
and not as a submission).

Jan


>=20
> Not sure if this is the correct mailing list to send this to.=20
>=20
> Please let me know if I should send it somewhere else.
>=20
> Yours,=20
>=20
> Erlend
>=20
> ---------- Forwarded message ----------
> From: <internet-drafts@ietf.org>
> Date: Wed, Jan 15, 2014 at 3:05 PM
> Subject: New Version Notification for =
draft-hamnaberg-publish-link-relation-00.txt
> To: Erlend Hamnaberg <erlend@hamnaberg.net>
>=20
>=20
>=20
> A new version of I-D, draft-hamnaberg-publish-link-relation-00.txt
> has been successfully submitted by Erlend Hamnaberg and posted to the
> IETF repository.
>=20
> Name:           draft-hamnaberg-publish-link-relation
> Revision:       00
> Title:          The 'publish' Link Relation Type
> Document date:  2014-01-15
> Group:          Individual Submission
> Pages:          6
> URL:            =
http://www.ietf.org/internet-drafts/draft-hamnaberg-publish-link-relation-=
00.txt
> Status:         =
https://datatracker.ietf.org/doc/draft-hamnaberg-publish-link-relation/
> Htmlized:       =
http://tools.ietf.org/html/draft-hamnaberg-publish-link-relation-00
>=20
>=20
> Abstract:
>    This memo defines a 'publish' link relation and provides a number =
of
>    examples.
>=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
>=20
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss


From erlend@hamnaberg.net  Wed Jan 15 08:00:02 2014
Return-Path: <erlend@hamnaberg.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC4061AE3BA for <apps-discuss@ietfa.amsl.com>; Wed, 15 Jan 2014 08:00:02 -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 dgMVf7K9ob8C for <apps-discuss@ietfa.amsl.com>; Wed, 15 Jan 2014 08:00:01 -0800 (PST)
Received: from mail-ob0-f179.google.com (mail-ob0-f179.google.com [209.85.214.179]) by ietfa.amsl.com (Postfix) with ESMTP id 3771F1AE3A7 for <apps-discuss@ietf.org>; Wed, 15 Jan 2014 08:00:01 -0800 (PST)
Received: by mail-ob0-f179.google.com with SMTP id wp4so1345097obc.24 for <apps-discuss@ietf.org>; Wed, 15 Jan 2014 07:59:49 -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=5Vdpn6wm9UGJUa/3tgzIFex6Bm7bfLmFWhI3oyWav+A=; b=OnTBPdY6PFi9hGILM7zpJX0/1q7R4qWSRbdDoBuGS1E6h0rE2+bHGZ2wAZe30/7gof z7vQdgIsnUpRZHNj4AJqiUkVj6jSnz8NY6oGA9cD0yzMfvVo52TtBb0Y7rKxX5NdC9/2 lMRJGuW29B0HL/kDh8U3nx4VciRpyROLiwdMS7y6b5fW1reE1YKlq/amJ9PgRjVzYgtm bv+nGv41Q7J7lFD4wdx6qlcERoEN1Q0O6Brn+DO3HPg1sZkNsyfWUGymia9o/Deef7nV 2btaWqoxlpecBoEZN+YLSNEs1bXv5/VXIdItrPEpWbhmnjB2XMa49XLd7C8jMIj72kqj 24Bg==
X-Gm-Message-State: ALoCoQmOISO+Gl9CRf0RemSXKBbWgjwgRSouMLBmG4vM91z9FeKYrgOJdrp/dbbrGveRSevgP++y
MIME-Version: 1.0
X-Received: by 10.182.250.200 with SMTP id ze8mr1541700obc.72.1389801589215; Wed, 15 Jan 2014 07:59:49 -0800 (PST)
Received: by 10.182.160.98 with HTTP; Wed, 15 Jan 2014 07:59:49 -0800 (PST)
X-Originating-IP: [80.203.95.228]
In-Reply-To: <F1F4C81D-5106-46B9-9A4C-B3C2F696A07F@nordsc.com>
References: <20140115140544.27701.78043.idtracker@ietfa.amsl.com> <CAGuwm8V+cFGE4aYP4rsZtGQR3_NPBOxf_t_BRgfxQbbTvOJTVQ@mail.gmail.com> <F1F4C81D-5106-46B9-9A4C-B3C2F696A07F@nordsc.com>
Date: Wed, 15 Jan 2014 16:59:49 +0100
Message-ID: <CAGuwm8Vh_bAKW9Lo3qLy5Usb5atM52BQ3cm_4WGc0X1--3QvKA@mail.gmail.com>
From: Erlend Hamnaberg <erlend@hamnaberg.net>
To: Jan Algermissen <jan.algermissen@nordsc.com>
Content-Type: multipart/alternative; boundary=089e0160c66008aa5004f00466e4
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] New Version Notification for draft-hamnaberg-publish-link-relation-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Jan 2014 16:00:02 -0000

--089e0160c66008aa5004f00466e4
Content-Type: text/plain; charset=ISO-8859-1

Jan,

On Wed, Jan 15, 2014 at 4:46 PM, Jan Algermissen <jan.algermissen@nordsc.com
> wrote:

>
> On 15.01.2014, at 15:08, Erlend Hamnaberg <erlend@hamnaberg.net> wrote:
>
> > My first Internet Draft, please be nice =)
>
> Great!
>
> >
> > Please give feedback.
>
> I am not sure I understand what publishing means to you. Can you explain
> your context?
>
> In general, I think that you should model 'publishing' as a state change
> and not as a submission).
>
> Jan
>
>
My use case has been a schedule for a conference.

The program is built over time, but once it is done, I want to publish it.

I could, of course, go through each session and publish it directly.
Each publishing step is then a state change for each session.
However, for a user interface can become cumbersome.

However, If I decide to model this as two separate URIs,
I may need a different mechanism.

Not sure I am able to explain this appropriately.

Erlend

--089e0160c66008aa5004f00466e4
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra">Jan,<br><br><div class=3D"gmail=
_quote">On Wed, Jan 15, 2014 at 4:46 PM, Jan Algermissen <span dir=3D"ltr">=
&lt;<a href=3D"mailto:jan.algermissen@nordsc.com" target=3D"_blank">jan.alg=
ermissen@nordsc.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div class=3D"im"><br>
On 15.01.2014, at 15:08, Erlend Hamnaberg &lt;<a href=3D"mailto:erlend@hamn=
aberg.net">erlend@hamnaberg.net</a>&gt; wrote:<br>
<br>
&gt; My first Internet Draft, please be nice =3D)<br>
<br>
</div>Great!<br>
<br>
&gt;<br>
&gt; Please give feedback.<br>
<br>
I am not sure I understand what publishing means to you. Can you explain yo=
ur context?<br>
<br>
In general, I think that you should model &#39;publishing&#39; as a state c=
hange and not as a submission).<br>
<span class=3D""><font color=3D"#888888"><br>
Jan<br>
</font></span><div class=3D""><div class=3D"h5"><br></div></div></blockquot=
e><div><br></div><div>My use case has been a schedule for a conference.=A0<=
br></div><div><br></div><div>The program is built over time, but once it is=
 done, I want to publish it.</div>
<div><br></div><div>I could, of course, go through each session and publish=
 it directly.=A0</div><div>Each publishing step is then a state change for =
each session.</div><div>However, for a user interface can become cumbersome=
.=A0</div>
<div><br></div><div>However, If I decide to model this as two separate URIs=
,=A0</div><div>I may need a different mechanism.=A0</div><div><br></div><di=
v>Not sure I am able to explain this appropriately.</div><div><br></div><di=
v>
Erlend</div></div></div></div>

--089e0160c66008aa5004f00466e4--

From jan.algermissen@nordsc.com  Wed Jan 15 08:45:27 2014
Return-Path: <jan.algermissen@nordsc.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BFE11AE413 for <apps-discuss@ietfa.amsl.com>; Wed, 15 Jan 2014 08:45:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level: 
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 myBqwxnQXAkS for <apps-discuss@ietfa.amsl.com>; Wed, 15 Jan 2014 08:45:26 -0800 (PST)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by ietfa.amsl.com (Postfix) with ESMTP id 7B56F1AE409 for <apps-discuss@ietf.org>; Wed, 15 Jan 2014 08:45:26 -0800 (PST)
Received: from [172.20.10.5] (tmo-097-113.customers.d1-online.com [80.187.97.113]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0Me5Bm-1Vi4aH2NXK-00QK8p; Wed, 15 Jan 2014 17:45:14 +0100
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jan Algermissen <jan.algermissen@nordsc.com>
In-Reply-To: <CAGuwm8Vh_bAKW9Lo3qLy5Usb5atM52BQ3cm_4WGc0X1--3QvKA@mail.gmail.com>
Date: Wed, 15 Jan 2014 17:45:03 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <05628088-5731-4BEB-BD79-7C83896279FF@nordsc.com>
References: <20140115140544.27701.78043.idtracker@ietfa.amsl.com> <CAGuwm8V+cFGE4aYP4rsZtGQR3_NPBOxf_t_BRgfxQbbTvOJTVQ@mail.gmail.com> <F1F4C81D-5106-46B9-9A4C-B3C2F696A07F@nordsc.com> <CAGuwm8Vh_bAKW9Lo3qLy5Usb5atM52BQ3cm_4WGc0X1--3QvKA@mail.gmail.com>
To: Erlend Hamnaberg <erlend@hamnaberg.net>
X-Mailer: Apple Mail (2.1510)
X-Provags-ID: V02:K0:qWhTHZhF3ZleAll8vvGj8AqkN4B+NNOG9Q/JiVP7R6V aeLid0qI+6l9a3ixFhk7ogksbv5rxDYtVJNZLjpLBRGDiI0Y/4 lbMB25AwkJXzKe8RtDKV9Vf+o1pxe0jhnLMQ0WdvY8VrLKKfyl NDXOHheJDnuKFfSFd18wOLlCGGNXKBSlRj+prQPqyBdyUYWMU0 /N3QIH2yL2cwhDlChkle0Ot37r24Ean/g3Rq6oYdcnmECx8S9n yqh7nrPTs9J4mwhDahjDRHdJDPsL3TQxqYrdd6Gf34todiLQdf d8QVclGZo5IKRu9C42pgR4RDMOf4gMH57UghNUVzW7+iZcsnDV /CeGT1BRyo52SIxcq7+clg6PsXVeFe58jgGFRnIPyLnMtg8j7d uPD83td2w1JxQ==
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] New Version Notification for draft-hamnaberg-publish-link-relation-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Jan 2014 16:45:27 -0000

On 15.01.2014, at 16:59, Erlend Hamnaberg <erlend@hamnaberg.net> wrote:

>=20
> My use case has been a schedule for a conference.=20
>=20
> The program is built over time, but once it is done, I want to publish =
it.

If publishing is done by the same server, I'd change a property of the =
program to tell the server that it should publish.

When on a nother server, I'd try to POST the program's representation, =
implicitly creating a new publishing job. That job will have a URI which =
I would use to observer the state of the job.

Having "publish" point to the publishing system might make sense, in =
that sense "publish" would identoty a "resource providing publishing =
services".

I'd ovoid to POST the URI to the publishing service if possible, because =
it reduces simpicity IMHO, because the publishing system will need to go =
and GET the resuorec to be published which feels unnatural to me.=20

How does that resonate with you?

Jan

>=20
> I could, of course, go through each session and publish it directly.=20=

> Each publishing step is then a state change for each session.
> However, for a user interface can become cumbersome.=20
>=20
> However, If I decide to model this as two separate URIs,=20
> I may need a different mechanism.=20
>=20
> Not sure I am able to explain this appropriately.
>=20
> Erlend


From mca@amundsen.com  Wed Jan 15 10:05:59 2014
Return-Path: <mca@amundsen.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCB0B1AE3D1 for <apps-discuss@ietfa.amsl.com>; Wed, 15 Jan 2014 10:05:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.155
X-Spam-Level: *
X-Spam-Status: No, score=1.155 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FM_FORGED_GMAIL=0.622, FORGED_YAHOO_RCVD=1.63, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, NML_ADSP_CUSTOM_MED=0.9, 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 aXLSIPfK0kbN for <apps-discuss@ietfa.amsl.com>; Wed, 15 Jan 2014 10:05:58 -0800 (PST)
Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id EF26A1AE3AB for <apps-discuss@ietf.org>; Wed, 15 Jan 2014 10:05:57 -0800 (PST)
Received: by mail-wi0-f170.google.com with SMTP id ex4so1023255wid.3 for <apps-discuss@ietf.org>; Wed, 15 Jan 2014 10:05:45 -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:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-type; bh=dVvmNhRENRaMWD9HIbljJVNvl20QXHAPSxk3BUNXkzE=; b=FoyjD1jzDykv3rsee7dwtx38fFR7brU9eBjOkQ01aud+d72a4qoh9QPjC3+lylzdXv SXniM32r7ndFnnCP6xiwAKwrM0M0/wS4SsnbBFilOLBGCvjpPZtWY4dkH2W46SKObnRQ UyNv8VNckPZHelZcmGOK6MyYOOufMzUGifK+m9A1NxaXOKylMpYKyZNmmtThJWXjFgpd zy80njbH8YgOt9NkQ84j0HqAheL49NVIgFgQUlvygHGsJtAmbD7ZKwksWcw7pcEXx9Wz uVjZvK0NeMwBpvsOU5wgktf/eqoKnaZ7DmCiERMaZwkUDPWz48ncOLxton236ZybbUJv D5HA==
X-Gm-Message-State: ALoCoQmOaMa7bcYBIzeHTXl8TmCKLi+kQoIdYDgCY8Vh1Wg0JyR6gnSNIfXxjTL+KEoRXJbFkGdr
X-Received: by 10.180.189.6 with SMTP id ge6mr3695593wic.1.1389809145006; Wed, 15 Jan 2014 10:05:45 -0800 (PST)
MIME-Version: 1.0
Sender: mca@amundsen.com
Received: by 10.194.119.226 with HTTP; Wed, 15 Jan 2014 10:05:24 -0800 (PST)
In-Reply-To: <05628088-5731-4BEB-BD79-7C83896279FF@nordsc.com>
References: <20140115140544.27701.78043.idtracker@ietfa.amsl.com> <CAGuwm8V+cFGE4aYP4rsZtGQR3_NPBOxf_t_BRgfxQbbTvOJTVQ@mail.gmail.com> <F1F4C81D-5106-46B9-9A4C-B3C2F696A07F@nordsc.com> <CAGuwm8Vh_bAKW9Lo3qLy5Usb5atM52BQ3cm_4WGc0X1--3QvKA@mail.gmail.com> <05628088-5731-4BEB-BD79-7C83896279FF@nordsc.com>
From: mike amundsen <mamund@yahoo.com>
Date: Wed, 15 Jan 2014 13:05:24 -0500
X-Google-Sender-Auth: d3_aLC8p8IWswE6wKqWiT9lCbjg
Message-ID: <CAPW_8m66V2YJeGMK3zN_qnKpph8ujnrA85585FFwLoBtfWvfXA@mail.gmail.com>
To: Jan Algermissen <jan.algermissen@nordsc.com>
Content-Type: multipart/alternative; boundary=001a11c222e464ff2504f00628c8
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] New Version Notification for draft-hamnaberg-publish-link-relation-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Jan 2014 18:06:00 -0000

--001a11c222e464ff2504f00628c8
Content-Type: text/plain; charset=ISO-8859-1

My advice is to *not* attempt to constrain how the client or server behaves
when using the link relation (e.g. "client SHOULD use POST to ....", etc.).

Instead just define the link relation's meaning and let clients and servers
use that shared meaning to do whatever they want with it.




mamund
+1.859.757.1449
skype: mca.amundsen
http://amundsen.com/blog/
http://twitter.com/mamund
https://github.com/mamund
http://linkedin.com/in/mamund


On Wed, Jan 15, 2014 at 11:45 AM, Jan Algermissen <
jan.algermissen@nordsc.com> wrote:

>
> On 15.01.2014, at 16:59, Erlend Hamnaberg <erlend@hamnaberg.net> wrote:
>
> >
> > My use case has been a schedule for a conference.
> >
> > The program is built over time, but once it is done, I want to publish
> it.
>
> If publishing is done by the same server, I'd change a property of the
> program to tell the server that it should publish.
>
> When on a nother server, I'd try to POST the program's representation,
> implicitly creating a new publishing job. That job will have a URI which I
> would use to observer the state of the job.
>
> Having "publish" point to the publishing system might make sense, in that
> sense "publish" would identoty a "resource providing publishing services".
>
> I'd ovoid to POST the URI to the publishing service if possible, because
> it reduces simpicity IMHO, because the publishing system will need to go
> and GET the resuorec to be published which feels unnatural to me.
>
> How does that resonate with you?
>
> Jan
>
> >
> > I could, of course, go through each session and publish it directly.
> > Each publishing step is then a state change for each session.
> > However, for a user interface can become cumbersome.
> >
> > However, If I decide to model this as two separate URIs,
> > I may need a different mechanism.
> >
> > Not sure I am able to explain this appropriately.
> >
> > Erlend
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

--001a11c222e464ff2504f00628c8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">My advice is to *not* attempt to constrain how the client =
or server behaves when using the link relation (e.g. &quot;client SHOULD us=
e POST to ....&quot;, etc.).<div><br></div><div>Instead just define the lin=
k relation&#39;s meaning and let clients and servers use that shared meanin=
g to do whatever they want with it.</div>

<div><br></div><div><br></div></div><div class=3D"gmail_extra"><br clear=3D=
"all"><div><div dir=3D"ltr"><div><br></div>mamund<div><span><span title=3D"=
Call with Google Voice"><span title=3D"Call with Google Voice">+1.859.757.1=
449</span></span></span><br>

skype: mca.amundsen<br><a href=3D"http://amundsen.com/blog/" target=3D"_bla=
nk">http://amundsen.com/blog/</a><br><a href=3D"http://twitter.com/mamund" =
target=3D"_blank">http://twitter.com/mamund</a><br><a href=3D"https://githu=
b.com/mamund" target=3D"_blank">https://github.com/mamund</a><br>

<a href=3D"http://linkedin.com/in/mamund" target=3D"_blank">http://linkedin=
.com/in/mamund</a></div></div></div>
<br><br><div class=3D"gmail_quote">On Wed, Jan 15, 2014 at 11:45 AM, Jan Al=
germissen <span dir=3D"ltr">&lt;<a href=3D"mailto:jan.algermissen@nordsc.co=
m" target=3D"_blank">jan.algermissen@nordsc.com</a>&gt;</span> wrote:<br><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex">

<div class=3D"im"><br>
On 15.01.2014, at 16:59, Erlend Hamnaberg &lt;<a href=3D"mailto:erlend@hamn=
aberg.net">erlend@hamnaberg.net</a>&gt; wrote:<br>
<br>
&gt;<br>
&gt; My use case has been a schedule for a conference.<br>
&gt;<br>
&gt; The program is built over time, but once it is done, I want to publish=
 it.<br>
<br>
</div>If publishing is done by the same server, I&#39;d change a property o=
f the program to tell the server that it should publish.<br>
<br>
When on a nother server, I&#39;d try to POST the program&#39;s representati=
on, implicitly creating a new publishing job. That job will have a URI whic=
h I would use to observer the state of the job.<br>
<br>
Having &quot;publish&quot; point to the publishing system might make sense,=
 in that sense &quot;publish&quot; would identoty a &quot;resource providin=
g publishing services&quot;.<br>
<br>
I&#39;d ovoid to POST the URI to the publishing service if possible, becaus=
e it reduces simpicity IMHO, because the publishing system will need to go =
and GET the resuorec to be published which feels unnatural to me.<br>
<br>
How does that resonate with you?<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Jan<br>
</font></span><div class=3D"im HOEnZb"><br>
&gt;<br>
&gt; I could, of course, go through each session and publish it directly.<b=
r>
&gt; Each publishing step is then a state change for each session.<br>
&gt; However, for a user interface can become cumbersome.<br>
&gt;<br>
&gt; However, If I decide to model this as two separate URIs,<br>
&gt; I may need a different mechanism.<br>
&gt;<br>
&gt; Not sure I am able to explain this appropriately.<br>
&gt;<br>
&gt; Erlend<br>
<br>
</div><div class=3D"HOEnZb"><div class=3D"h5">_____________________________=
__________________<br>
apps-discuss mailing list<br>
<a href=3D"mailto:apps-discuss@ietf.org">apps-discuss@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/apps-discuss" target=3D"_b=
lank">https://www.ietf.org/mailman/listinfo/apps-discuss</a><br>
</div></div></blockquote></div><br></div>

--001a11c222e464ff2504f00628c8--

From darrel.miller@gmail.com  Wed Jan 15 12:59:05 2014
Return-Path: <darrel.miller@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF1BF1AE415 for <apps-discuss@ietfa.amsl.com>; Wed, 15 Jan 2014 12:59:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level: 
X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_38=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 6eEo2DVrJRWD for <apps-discuss@ietfa.amsl.com>; Wed, 15 Jan 2014 12:59:04 -0800 (PST)
Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 421FC1AE0D5 for <apps-discuss@ietf.org>; Wed, 15 Jan 2014 12:59:04 -0800 (PST)
Received: by mail-ie0-f176.google.com with SMTP id lx4so2815425iec.35 for <apps-discuss@ietf.org>; Wed, 15 Jan 2014 12:58:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=L4I6ipwlyhyM/OnnpZfTlklLgywSLlNdpJZtf6jHfVw=; b=taklZvKH5ftKJW2D+OCK7ucfYEOP36/q03R5l4N4Ax1GfESoiEAPIHVleeicOwnnDK Rtnz8aA+M5T4ps6pHg0JAMnxXpCX1Fxs0nWPCl+LsZc+ySs7OC1IKjujJ0P8abiVEmWh kSEEA19cYU4B7FTwXgpdmvtW0znXr7XY0otZhMuv9JNT3+vT3Y73dKP3Avwxh4osDNeE ibFlL0G/FFB5XJ8MaNDz6b1TibIWF5xfBzZHTFeiajxgHfEXE9HnELK3MoKM9aUByunu kB9B/d2T8kU30uKkAIuacPY1g8NZiljWevwmmXLMsng7C7kj9yUm7K0tkUOZ1DzdwbcW 6A1w==
MIME-Version: 1.0
X-Received: by 10.50.126.10 with SMTP id mu10mr5354322igb.24.1389819532258; Wed, 15 Jan 2014 12:58:52 -0800 (PST)
Received: by 10.42.195.206 with HTTP; Wed, 15 Jan 2014 12:58:52 -0800 (PST)
In-Reply-To: <CAPW_8m66V2YJeGMK3zN_qnKpph8ujnrA85585FFwLoBtfWvfXA@mail.gmail.com>
References: <20140115140544.27701.78043.idtracker@ietfa.amsl.com> <CAGuwm8V+cFGE4aYP4rsZtGQR3_NPBOxf_t_BRgfxQbbTvOJTVQ@mail.gmail.com> <F1F4C81D-5106-46B9-9A4C-B3C2F696A07F@nordsc.com> <CAGuwm8Vh_bAKW9Lo3qLy5Usb5atM52BQ3cm_4WGc0X1--3QvKA@mail.gmail.com> <05628088-5731-4BEB-BD79-7C83896279FF@nordsc.com> <CAPW_8m66V2YJeGMK3zN_qnKpph8ujnrA85585FFwLoBtfWvfXA@mail.gmail.com>
Date: Wed, 15 Jan 2014 15:58:52 -0500
Message-ID: <CAKioOqt4-7tOoN66zth2vatLUFBXRSRaG4973trpEQRMP9dyYQ@mail.gmail.com>
From: Darrel Miller <darrel.miller@gmail.com>
To: IETF Apps Discuss <apps-discuss@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [apps-discuss] New Version Notification for draft-hamnaberg-publish-link-relation-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: darrel@tavis.ca
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Jan 2014 20:59:06 -0000

Mike,

How do you feel about a link relation that says, if you do POST, it
means this ...

If that concerns you then do you have suggestions on how the these
link relations should work:

rel=payment        https://web-payments.org/specs/source/payment-links/
rel=hub
https://pubsubhubbub.googlecode.com/git/pubsubhubbub-core-0.4.html
rel=oauth2-token http://tools.ietf.org/html/draft-wmills-oauth-lrdd-07#page-8

As far as I understand it, all of these have an associated meaning to
a POST request.  Curiously, that meaning is not described in the rel
relation registration, but in the specification that describes the
protocol that uses the link relation.  This separation concerns me
because we could end up with a situation where different protocols
assign different interaction semantics to the same link relation.

Darrel



On Wed, Jan 15, 2014 at 1:05 PM, mike amundsen <mamund@yahoo.com> wrote:
> My advice is to *not* attempt to constrain how the client or server behaves
> when using the link relation (e.g. "client SHOULD use POST to ....", etc.).
>
> Instead just define the link relation's meaning and let clients and servers
> use that shared meaning to do whatever they want with it.
>
>
>
>
> mamund
> +1.859.757.1449
> skype: mca.amundsen
> http://amundsen.com/blog/
> http://twitter.com/mamund
> https://github.com/mamund
> http://linkedin.com/in/mamund
>
>
> On Wed, Jan 15, 2014 at 11:45 AM, Jan Algermissen
> <jan.algermissen@nordsc.com> wrote:
>>
>>
>> On 15.01.2014, at 16:59, Erlend Hamnaberg <erlend@hamnaberg.net> wrote:
>>
>> >
>> > My use case has been a schedule for a conference.
>> >
>> > The program is built over time, but once it is done, I want to publish
>> > it.
>>
>> If publishing is done by the same server, I'd change a property of the
>> program to tell the server that it should publish.
>>
>> When on a nother server, I'd try to POST the program's representation,
>> implicitly creating a new publishing job. That job will have a URI which I
>> would use to observer the state of the job.
>>
>> Having "publish" point to the publishing system might make sense, in that
>> sense "publish" would identoty a "resource providing publishing services".
>>
>> I'd ovoid to POST the URI to the publishing service if possible, because
>> it reduces simpicity IMHO, because the publishing system will need to go and
>> GET the resuorec to be published which feels unnatural to me.
>>
>> How does that resonate with you?
>>
>> Jan
>>
>> >
>> > I could, of course, go through each session and publish it directly.
>> > Each publishing step is then a state change for each session.
>> > However, for a user interface can become cumbersome.
>> >
>> > However, If I decide to model this as two separate URIs,
>> > I may need a different mechanism.
>> >
>> > Not sure I am able to explain this appropriately.
>> >
>> > Erlend
>>
>> _______________________________________________
>> 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 jan.algermissen@nordsc.com  Wed Jan 15 13:35:40 2014
Return-Path: <jan.algermissen@nordsc.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ADFB1AE248 for <apps-discuss@ietfa.amsl.com>; Wed, 15 Jan 2014 13:35:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.351
X-Spam-Level: 
X-Spam-Status: No, score=-0.351 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_37=0.6, J_CHICKENPOX_38=0.6, 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 utRBMF4zpuiB for <apps-discuss@ietfa.amsl.com>; Wed, 15 Jan 2014 13:35:38 -0800 (PST)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by ietfa.amsl.com (Postfix) with ESMTP id EC0A41AE237 for <apps-discuss@ietf.org>; Wed, 15 Jan 2014 13:35:37 -0800 (PST)
Received: from [192.168.2.103] (p548FAFBD.dip0.t-ipconnect.de [84.143.175.189]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0MQs8Y-1VvBLe2Wvm-00Ttr3; Wed, 15 Jan 2014 22:35:24 +0100
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jan Algermissen <jan.algermissen@nordsc.com>
In-Reply-To: <CAKioOqt4-7tOoN66zth2vatLUFBXRSRaG4973trpEQRMP9dyYQ@mail.gmail.com>
Date: Wed, 15 Jan 2014 22:35:24 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <4ACFE05D-D204-4363-9A8B-AAC7F0695D66@nordsc.com>
References: <20140115140544.27701.78043.idtracker@ietfa.amsl.com> <CAGuwm8V+cFGE4aYP4rsZtGQR3_NPBOxf_t_BRgfxQbbTvOJTVQ@mail.gmail.com> <F1F4C81D-5106-46B9-9A4C-B3C2F696A07F@nordsc.com> <CAGuwm8Vh_bAKW9Lo3qLy5Usb5atM52BQ3cm_4WGc0X1--3QvKA@mail.gmail.com> <05628088-5731-4BEB-BD79-7C83896279FF@nordsc.com> <CAPW_8m66V2YJeGMK3zN_qnKpph8ujnrA85585FFwLoBtfWvfXA@mail.gmail.com> <CAKioOqt4-7tOoN66zth2vatLUFBXRSRaG4973trpEQRMP9dyYQ@mail.gmail.com>
To: darrel@tavis.ca
X-Mailer: Apple Mail (2.1510)
X-Provags-ID: V02:K0:TG0g7QEvn792SHNXfJnEmOmmBKr0LCBGsofv7qDjfar IyazSKAKlADeo/tipPmCx5RELUaF8QzejfwOFDngKco3RAm+WZ ESMHRUydquVtsotScRt94qLDvdRtOAIlzrkJXP+Yrk+1GhSf/4 HjO9kTRVAZm0qrZZ26v4TLg7IpGQEXwNS+jlTfXoZEuqRpQ45n jC7xkT1m8kIzgWsCWxD/sdp3m0DPSqo2Px08F2EdKPABoOLEkf +vIkDh9jMjtVu4hrC81wSCssKGjbcAFOjA/JVomKQDfiMCCgzZ 0TQQAc99HhKgvU7lpRKl982l8GiXQKIypr13P0ExGJWcocbo/g 8iJvVCcW352+mFKubK5iQdkVgwgDFgawoi7OVzbYvzoJMa/FG/ Zhwp417/ZlqeQ==
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] New Version Notification for draft-hamnaberg-publish-link-relation-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Jan 2014 21:35:40 -0000

On 15.01.2014, at 21:58, Darrel Miller <darrel.miller@gmail.com> wrote:

> Mike,
>=20
> How do you feel about a link relation that says, if you do POST, it
> means this ...

Uuuh - POST means POST ("process this"). A link rel cannot re-specify =
that.

The rel conveys information about the nature of a target resource. This =
helps the client to form an expection about the resource and interact =
with it if it is programmed to do so. Maybe the resource does not even =
support a POST.=20

>=20
> If that concerns you then do you have suggestions on how the these
> link relations should work:
>=20
> rel=3Dpayment        =
https://web-payments.org/specs/source/payment-links/

You are loosing me here ... "payment" already exists in =
<http://tools.ietf.org/html/rfc5988#section-6.3>. And why is that spec =
not defining URI template variables and references the URI Template =
draft? <http://tools.ietf.org/html/rfc6570>


> rel=3Dhub
> https://pubsubhubbub.googlecode.com/git/pubsubhubbub-core-0.4.html

The target 'is a hub' - what else do I need to know?

> rel=3Doauth2-token =
http://tools.ietf.org/html/draft-wmills-oauth-lrdd-07#page-8

target is a resource where I can obtain an oauth2 token

>=20
> As far as I understand it, all of these have an associated meaning to
> a POST request.

Which is simpl not possible - you cannot override HTTP and still be =
'within the system'. If you associate meaning with POST, you are =
defining an application protocol on top of HTTP.

>  Curiously, that meaning is not described in the rel
> relation registration, but in the specification that describes the
> protocol that uses the link relation.

Which you can, if you mark it as a 'hint' or 'example' - just do not =
trick the client into making assumptions that REST deliberately wants =
the client *not* to make.

The most interesting thing about all this is, IMHO, that you frankly do =
not need to know, because the method to use is usually sraight forward =
given the context. I mean, what method would you use for obtaining an =
oauth2 token?=20

>  This separation concerns me
> because we could end up with a situation where different protocols
> assign different interaction semantics to the same link relation.

HTTP is for the interaction semantics, link rels can only express the =
nature of a resource. They cannot constrain the server.

Jan


>=20
> Darrel
>=20
>=20
>=20
> On Wed, Jan 15, 2014 at 1:05 PM, mike amundsen <mamund@yahoo.com> =
wrote:
>> My advice is to *not* attempt to constrain how the client or server =
behaves
>> when using the link relation (e.g. "client SHOULD use POST to ....", =
etc.).
>>=20
>> Instead just define the link relation's meaning and let clients and =
servers
>> use that shared meaning to do whatever they want with it.
>>=20
>>=20
>>=20
>>=20
>> mamund
>> +1.859.757.1449
>> skype: mca.amundsen
>> http://amundsen.com/blog/
>> http://twitter.com/mamund
>> https://github.com/mamund
>> http://linkedin.com/in/mamund
>>=20
>>=20
>> On Wed, Jan 15, 2014 at 11:45 AM, Jan Algermissen
>> <jan.algermissen@nordsc.com> wrote:
>>>=20
>>>=20
>>> On 15.01.2014, at 16:59, Erlend Hamnaberg <erlend@hamnaberg.net> =
wrote:
>>>=20
>>>>=20
>>>> My use case has been a schedule for a conference.
>>>>=20
>>>> The program is built over time, but once it is done, I want to =
publish
>>>> it.
>>>=20
>>> If publishing is done by the same server, I'd change a property of =
the
>>> program to tell the server that it should publish.
>>>=20
>>> When on a nother server, I'd try to POST the program's =
representation,
>>> implicitly creating a new publishing job. That job will have a URI =
which I
>>> would use to observer the state of the job.
>>>=20
>>> Having "publish" point to the publishing system might make sense, in =
that
>>> sense "publish" would identoty a "resource providing publishing =
services".
>>>=20
>>> I'd ovoid to POST the URI to the publishing service if possible, =
because
>>> it reduces simpicity IMHO, because the publishing system will need =
to go and
>>> GET the resuorec to be published which feels unnatural to me.
>>>=20
>>> How does that resonate with you?
>>>=20
>>> Jan
>>>=20
>>>>=20
>>>> I could, of course, go through each session and publish it =
directly.
>>>> Each publishing step is then a state change for each session.
>>>> However, for a user interface can become cumbersome.
>>>>=20
>>>> However, If I decide to model this as two separate URIs,
>>>> I may need a different mechanism.
>>>>=20
>>>> Not sure I am able to explain this appropriately.
>>>>=20
>>>> Erlend
>>>=20
>>> _______________________________________________
>>> apps-discuss mailing list
>>> apps-discuss@ietf.org
>>> https://www.ietf.org/mailman/listinfo/apps-discuss
>>=20
>>=20
>>=20
>> _______________________________________________
>> apps-discuss mailing list
>> apps-discuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/apps-discuss
>>=20
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss


From mca@amundsen.com  Wed Jan 15 13:37:41 2014
Return-Path: <mca@amundsen.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8936A1AE255 for <apps-discuss@ietfa.amsl.com>; Wed, 15 Jan 2014 13:37:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.755
X-Spam-Level: *
X-Spam-Status: No, score=1.755 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FM_FORGED_GMAIL=0.622, FORGED_YAHOO_RCVD=1.63, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, J_CHICKENPOX_38=0.6, NML_ADSP_CUSTOM_MED=0.9, 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 voJGwWD6BgUM for <apps-discuss@ietfa.amsl.com>; Wed, 15 Jan 2014 13:37:39 -0800 (PST)
Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) by ietfa.amsl.com (Postfix) with ESMTP id 9C2491AE237 for <apps-discuss@ietf.org>; Wed, 15 Jan 2014 13:37:38 -0800 (PST)
Received: by mail-wg0-f51.google.com with SMTP id z12so2325325wgg.18 for <apps-discuss@ietf.org>; Wed, 15 Jan 2014 13:37:26 -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:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-type; bh=9iF2JSW5iC6psaTHhp2+QCeTQ4iAZvz9lvS8sU/q+1Y=; b=G4f1iOoAU5WGeM4DfXOIVc+clYTVSfR0tYQBkWllZPdflRpMOVUiD/5Yo4optjIvEY wivLbxKdf/f5l/9O+BpCb0GJROZ3X85OeXVFRVs8SJuuA1rJlDG8DV0NtFXtsDgeCN2E sd0X0ZH10hmoVwycX62E+jqXt5Ph+P/6bt/we7xO8LVyH5HtKvZc0V4lNx0iozGo9nS2 jMDhzOIcxP7ayzNEhgO6jp+OCZujOnPzx4ftq3v41kf7yQPLvLeImnpOvsLPhsJ+bQeh atqP4BdJE6WJfVigJdBaZr+8CNRiQVxVzzwitGkxft4chHolovBYyxp+YISXWq+wAZb+ ChCA==
X-Gm-Message-State: ALoCoQmrObVlfNVuz2usnWhAlCVs1/d1X6aVwOCHgz9trjIImwe3VberH5lF6UKaZIoYQACGAz/k
X-Received: by 10.180.14.231 with SMTP id s7mr4589269wic.1.1389821846231; Wed, 15 Jan 2014 13:37:26 -0800 (PST)
MIME-Version: 1.0
Sender: mca@amundsen.com
Received: by 10.194.119.226 with HTTP; Wed, 15 Jan 2014 13:37:06 -0800 (PST)
In-Reply-To: <CAKioOqt4-7tOoN66zth2vatLUFBXRSRaG4973trpEQRMP9dyYQ@mail.gmail.com>
References: <20140115140544.27701.78043.idtracker@ietfa.amsl.com> <CAGuwm8V+cFGE4aYP4rsZtGQR3_NPBOxf_t_BRgfxQbbTvOJTVQ@mail.gmail.com> <F1F4C81D-5106-46B9-9A4C-B3C2F696A07F@nordsc.com> <CAGuwm8Vh_bAKW9Lo3qLy5Usb5atM52BQ3cm_4WGc0X1--3QvKA@mail.gmail.com> <05628088-5731-4BEB-BD79-7C83896279FF@nordsc.com> <CAPW_8m66V2YJeGMK3zN_qnKpph8ujnrA85585FFwLoBtfWvfXA@mail.gmail.com> <CAKioOqt4-7tOoN66zth2vatLUFBXRSRaG4973trpEQRMP9dyYQ@mail.gmail.com>
From: mike amundsen <mamund@yahoo.com>
Date: Wed, 15 Jan 2014 16:37:06 -0500
X-Google-Sender-Auth: -K1LhDemjjcMneryzsUqbJLA7J8
Message-ID: <CAPW_8m7F8VFN1XXFkYYfVvTN2RNcOmGo3zEzjiq-bg-uWDpZ-w@mail.gmail.com>
To: Darrel Miller <darrel@tavis.ca>
Content-Type: multipart/alternative; boundary=f46d040fa00472352504f0091dc0
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] New Version Notification for draft-hamnaberg-publish-link-relation-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Jan 2014 21:37:41 -0000

--f46d040fa00472352504f0091dc0
Content-Type: text/plain; charset=ISO-8859-1

I'm not a fan of using a string as a network affordance ;) I know this is
not a universally held conviction. for example, HAL relies on this very
notion quite heavily.

i assert the best way to use link relation values is as identifiers. The
registry let's use describe these values in a general way much the way a
 language dictionary (e.g. English, French, etc.) does. The way in which
the words are used, their intent, implied meaning, etc. are often based on
immediate context ("you owe me a payment" vs. "there is were you go to make
payments") and so forth.

To your last point, I think tying operational semantics to a link relation
is over-constraining and limits it's use over time. Esp. when the
operational semantics are tied to a single protocol or format. I prefer to
keep usage details separate from the registry of unique values.





mamund
+1.859.757.1449
skype: mca.amundsen
http://amundsen.com/blog/
http://twitter.com/mamund
https://github.com/mamund
http://linkedin.com/in/mamund


On Wed, Jan 15, 2014 at 3:58 PM, Darrel Miller <darrel.miller@gmail.com>wrote:

> Mike,
>
> How do you feel about a link relation that says, if you do POST, it
> means this ...
>
> If that concerns you then do you have suggestions on how the these
> link relations should work:
>
> rel=payment        https://web-payments.org/specs/source/payment-links/
> rel=hub
> https://pubsubhubbub.googlecode.com/git/pubsubhubbub-core-0.4.html
> rel=oauth2-token
> http://tools.ietf.org/html/draft-wmills-oauth-lrdd-07#page-8
>
> As far as I understand it, all of these have an associated meaning to
> a POST request.  Curiously, that meaning is not described in the rel
> relation registration, but in the specification that describes the
> protocol that uses the link relation.  This separation concerns me
> because we could end up with a situation where different protocols
> assign different interaction semantics to the same link relation.
>
> Darrel
>
>
>
> On Wed, Jan 15, 2014 at 1:05 PM, mike amundsen <mamund@yahoo.com> wrote:
> > My advice is to *not* attempt to constrain how the client or server
> behaves
> > when using the link relation (e.g. "client SHOULD use POST to ....",
> etc.).
> >
> > Instead just define the link relation's meaning and let clients and
> servers
> > use that shared meaning to do whatever they want with it.
> >
> >
> >
> >
> > mamund
> > +1.859.757.1449
> > skype: mca.amundsen
> > http://amundsen.com/blog/
> > http://twitter.com/mamund
> > https://github.com/mamund
> > http://linkedin.com/in/mamund
> >
> >
> > On Wed, Jan 15, 2014 at 11:45 AM, Jan Algermissen
> > <jan.algermissen@nordsc.com> wrote:
> >>
> >>
> >> On 15.01.2014, at 16:59, Erlend Hamnaberg <erlend@hamnaberg.net> wrote:
> >>
> >> >
> >> > My use case has been a schedule for a conference.
> >> >
> >> > The program is built over time, but once it is done, I want to publish
> >> > it.
> >>
> >> If publishing is done by the same server, I'd change a property of the
> >> program to tell the server that it should publish.
> >>
> >> When on a nother server, I'd try to POST the program's representation,
> >> implicitly creating a new publishing job. That job will have a URI
> which I
> >> would use to observer the state of the job.
> >>
> >> Having "publish" point to the publishing system might make sense, in
> that
> >> sense "publish" would identoty a "resource providing publishing
> services".
> >>
> >> I'd ovoid to POST the URI to the publishing service if possible, because
> >> it reduces simpicity IMHO, because the publishing system will need to
> go and
> >> GET the resuorec to be published which feels unnatural to me.
> >>
> >> How does that resonate with you?
> >>
> >> Jan
> >>
> >> >
> >> > I could, of course, go through each session and publish it directly.
> >> > Each publishing step is then a state change for each session.
> >> > However, for a user interface can become cumbersome.
> >> >
> >> > However, If I decide to model this as two separate URIs,
> >> > I may need a different mechanism.
> >> >
> >> > Not sure I am able to explain this appropriately.
> >> >
> >> > Erlend
> >>
> >> _______________________________________________
> >> 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
>

--f46d040fa00472352504f0091dc0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I&#39;m not a fan of using a string as a network affordanc=
e ;) I know this is not a universally held conviction. for example, HAL rel=
ies on this very notion quite heavily.<div><br></div><div style>i assert th=
e best way to use link relation values is as identifiers. The registry let&=
#39;s use describe these values in a general way much the way a =A0language=
 dictionary (e.g. English, French, etc.) does. The way in which the words a=
re used, their intent, implied meaning, etc. are often based on immediate c=
ontext (&quot;you owe me a payment&quot; vs. &quot;there is were you go to =
make payments&quot;) and so forth.<br>

</div><div style><br></div><div style>To your last point, I think tying ope=
rational semantics to a link relation is over-constraining and limits it&#3=
9;s use over time. Esp. when the operational semantics are tied to a single=
 protocol or format. I prefer to keep usage details separate from the regis=
try of unique values.</div>

<div style><br></div><div style><br></div><div style><br></div></div><div c=
lass=3D"gmail_extra"><br clear=3D"all"><div><div dir=3D"ltr"><div><br></div=
>mamund<div><span><span title=3D"Call with Google Voice"><span title=3D"Cal=
l with Google Voice">+1.859.757.1449</span></span></span><br>

skype: mca.amundsen<br><a href=3D"http://amundsen.com/blog/" target=3D"_bla=
nk">http://amundsen.com/blog/</a><br><a href=3D"http://twitter.com/mamund" =
target=3D"_blank">http://twitter.com/mamund</a><br><a href=3D"https://githu=
b.com/mamund" target=3D"_blank">https://github.com/mamund</a><br>

<a href=3D"http://linkedin.com/in/mamund" target=3D"_blank">http://linkedin=
.com/in/mamund</a></div></div></div>
<br><br><div class=3D"gmail_quote">On Wed, Jan 15, 2014 at 3:58 PM, Darrel =
Miller <span dir=3D"ltr">&lt;<a href=3D"mailto:darrel.miller@gmail.com" tar=
get=3D"_blank">darrel.miller@gmail.com</a>&gt;</span> wrote:<br><blockquote=
 class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex">

Mike,<br>
<br>
How do you feel about a link relation that says, if you do POST, it<br>
means this ...<br>
<br>
If that concerns you then do you have suggestions on how the these<br>
link relations should work:<br>
<br>
rel=3Dpayment =A0 =A0 =A0 =A0<a href=3D"https://web-payments.org/specs/sour=
ce/payment-links/
rel=3Dhub" target=3D"_blank">https://web-payments.org/specs/source/payment-=
links/<br>
rel=3Dhub</a><br>
<a href=3D"https://pubsubhubbub.googlecode.com/git/pubsubhubbub-core-0.4.ht=
ml" target=3D"_blank">https://pubsubhubbub.googlecode.com/git/pubsubhubbub-=
core-0.4.html</a><br>
rel=3Doauth2-token <a href=3D"http://tools.ietf.org/html/draft-wmills-oauth=
-lrdd-07#page-8" target=3D"_blank">http://tools.ietf.org/html/draft-wmills-=
oauth-lrdd-07#page-8</a><br>
<br>
As far as I understand it, all of these have an associated meaning to<br>
a POST request. =A0Curiously, that meaning is not described in the rel<br>
relation registration, but in the specification that describes the<br>
protocol that uses the link relation. =A0This separation concerns me<br>
because we could end up with a situation where different protocols<br>
assign different interaction semantics to the same link relation.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Darrel<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
<br>
On Wed, Jan 15, 2014 at 1:05 PM, mike amundsen &lt;<a href=3D"mailto:mamund=
@yahoo.com">mamund@yahoo.com</a>&gt; wrote:<br>
&gt; My advice is to *not* attempt to constrain how the client or server be=
haves<br>
&gt; when using the link relation (e.g. &quot;client SHOULD use POST to ...=
.&quot;, etc.).<br>
&gt;<br>
&gt; Instead just define the link relation&#39;s meaning and let clients an=
d servers<br>
&gt; use that shared meaning to do whatever they want with it.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; mamund<br>
&gt; <a href=3D"tel:%2B1.859.757.1449" value=3D"+18597571449">+1.859.757.14=
49</a><br>
&gt; skype: mca.amundsen<br>
&gt; <a href=3D"http://amundsen.com/blog/" target=3D"_blank">http://amundse=
n.com/blog/</a><br>
&gt; <a href=3D"http://twitter.com/mamund" target=3D"_blank">http://twitter=
.com/mamund</a><br>
&gt; <a href=3D"https://github.com/mamund" target=3D"_blank">https://github=
.com/mamund</a><br>
&gt; <a href=3D"http://linkedin.com/in/mamund" target=3D"_blank">http://lin=
kedin.com/in/mamund</a><br>
&gt;<br>
&gt;<br>
&gt; On Wed, Jan 15, 2014 at 11:45 AM, Jan Algermissen<br>
&gt; &lt;<a href=3D"mailto:jan.algermissen@nordsc.com">jan.algermissen@nord=
sc.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; On 15.01.2014, at 16:59, Erlend Hamnaberg &lt;<a href=3D"mailto:er=
lend@hamnaberg.net">erlend@hamnaberg.net</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; My use case has been a schedule for a conference.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; The program is built over time, but once it is done, I want t=
o publish<br>
&gt;&gt; &gt; it.<br>
&gt;&gt;<br>
&gt;&gt; If publishing is done by the same server, I&#39;d change a propert=
y of the<br>
&gt;&gt; program to tell the server that it should publish.<br>
&gt;&gt;<br>
&gt;&gt; When on a nother server, I&#39;d try to POST the program&#39;s rep=
resentation,<br>
&gt;&gt; implicitly creating a new publishing job. That job will have a URI=
 which I<br>
&gt;&gt; would use to observer the state of the job.<br>
&gt;&gt;<br>
&gt;&gt; Having &quot;publish&quot; point to the publishing system might ma=
ke sense, in that<br>
&gt;&gt; sense &quot;publish&quot; would identoty a &quot;resource providin=
g publishing services&quot;.<br>
&gt;&gt;<br>
&gt;&gt; I&#39;d ovoid to POST the URI to the publishing service if possibl=
e, because<br>
&gt;&gt; it reduces simpicity IMHO, because the publishing system will need=
 to go and<br>
&gt;&gt; GET the resuorec to be published which feels unnatural to me.<br>
&gt;&gt;<br>
&gt;&gt; How does that resonate with you?<br>
&gt;&gt;<br>
&gt;&gt; Jan<br>
&gt;&gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; I could, of course, go through each session and publish it di=
rectly.<br>
&gt;&gt; &gt; Each publishing step is then a state change for each session.=
<br>
&gt;&gt; &gt; However, for a user interface can become cumbersome.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; However, If I decide to model this as two separate URIs,<br>
&gt;&gt; &gt; I may need a different mechanism.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Not sure I am able to explain this appropriately.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Erlend<br>
&gt;&gt;<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; apps-discuss mailing list<br>
&gt;&gt; <a href=3D"mailto:apps-discuss@ietf.org">apps-discuss@ietf.org</a>=
<br>
&gt;&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/apps-discuss" tar=
get=3D"_blank">https://www.ietf.org/mailman/listinfo/apps-discuss</a><br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; apps-discuss mailing list<br>
&gt; <a href=3D"mailto:apps-discuss@ietf.org">apps-discuss@ietf.org</a><br>
&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/apps-discuss" target=
=3D"_blank">https://www.ietf.org/mailman/listinfo/apps-discuss</a><br>
&gt;<br>
_______________________________________________<br>
apps-discuss mailing list<br>
<a href=3D"mailto:apps-discuss@ietf.org">apps-discuss@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/apps-discuss" target=3D"_b=
lank">https://www.ietf.org/mailman/listinfo/apps-discuss</a><br>
</div></div></blockquote></div><br></div>

--f46d040fa00472352504f0091dc0--

From darrel.miller@gmail.com  Wed Jan 15 14:18:38 2014
Return-Path: <darrel.miller@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB8E1AE266 for <apps-discuss@ietfa.amsl.com>; Wed, 15 Jan 2014 14:18:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level: 
X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_37=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 wUZvxBrZa7Uj for <apps-discuss@ietfa.amsl.com>; Wed, 15 Jan 2014 14:18:36 -0800 (PST)
Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 5A9771AE42B for <apps-discuss@ietf.org>; Wed, 15 Jan 2014 14:18:36 -0800 (PST)
Received: by mail-ig0-f174.google.com with SMTP id hl1so9005779igb.1 for <apps-discuss@ietf.org>; Wed, 15 Jan 2014 14:18:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type:content-transfer-encoding; bh=Jxn9ISONOQjKNzLfLE+SR5Fu1xvXS8gkZfdSSJOrOu8=; b=JNh2FHbRm/bZ976PGdaNUhNGOSd06LEIgghMdhzlJAB1TyaNpIjPq857tS5to9yAli +mLVNxeOW3X6ezcaxCQl/PjC3xOt8Crpz3IMxeyyRoziPEiATW1SqrnlxHPg63s+JfC7 OlAL7lcOS6i6Y7CdB4WCZmC9B95IHPh75CCukeawMj3UCR9WRQ5jKuMuJxda/N3DNuAL RIS4UDrdzH5WTUzgnboz6Lrkfoe1IP1Ayyr5R+xsptpyEzV7MZ5YEDW7F+BrV6rbbVmu 8fE+lM4HlmeI9N+ElajzPxIZX2QP2oPpea4Nce/d4PekE2Dehk2A9FtAqLL97WTaMqs8 VqHg==
MIME-Version: 1.0
X-Received: by 10.50.29.114 with SMTP id j18mr5645924igh.24.1389824304441; Wed, 15 Jan 2014 14:18:24 -0800 (PST)
Received: by 10.42.195.206 with HTTP; Wed, 15 Jan 2014 14:18:24 -0800 (PST)
In-Reply-To: <4ACFE05D-D204-4363-9A8B-AAC7F0695D66@nordsc.com>
References: <20140115140544.27701.78043.idtracker@ietfa.amsl.com> <CAGuwm8V+cFGE4aYP4rsZtGQR3_NPBOxf_t_BRgfxQbbTvOJTVQ@mail.gmail.com> <F1F4C81D-5106-46B9-9A4C-B3C2F696A07F@nordsc.com> <CAGuwm8Vh_bAKW9Lo3qLy5Usb5atM52BQ3cm_4WGc0X1--3QvKA@mail.gmail.com> <05628088-5731-4BEB-BD79-7C83896279FF@nordsc.com> <CAPW_8m66V2YJeGMK3zN_qnKpph8ujnrA85585FFwLoBtfWvfXA@mail.gmail.com> <CAKioOqt4-7tOoN66zth2vatLUFBXRSRaG4973trpEQRMP9dyYQ@mail.gmail.com> <4ACFE05D-D204-4363-9A8B-AAC7F0695D66@nordsc.com>
Date: Wed, 15 Jan 2014 17:18:24 -0500
Message-ID: <CAKioOquOW1Gogr5SR3E88=U31rvk8LEya62bJg++KbuXDXF+iA@mail.gmail.com>
From: Darrel Miller <darrel.miller@gmail.com>
To: IETF Apps Discuss <apps-discuss@ietf.org>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Subject: Re: [apps-discuss] New Version Notification for draft-hamnaberg-publish-link-relation-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: darrel@tavis.ca
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Jan 2014 22:18:38 -0000

Jan,


On Wed, Jan 15, 2014 at 4:35 PM, Jan Algermissen
<jan.algermissen@nordsc.com> wrote:
>
> Uuuh - POST means POST ("process this"). A link rel cannot re-specify tha=
t.
>
> The rel conveys information about the nature of a target resource. This h=
elps the client to form an expection about the resource and interact with i=
t if it is programmed to do so. Maybe the resource does not even support a =
POST.
>

So, you agree that the rel "conveys the nature of a target resource".
And httpbis says

"The POST method requests that the target resource process the
representation enclosed in the request according to the resource's own
specific semantics."

So, if we put those two together then we can determine that the rel
defines the nature of the target resource and the resource defines the
semantics of POST for interactions with that resource.  Hence, I'm
going to conclude that it is not a huge stretch to say that you can
use link relations to define the semantics of a POST.

>>
>> If that concerns you then do you have suggestions on how the these
>> link relations should work:
>>
>> rel=3Dpayment        https://web-payments.org/specs/source/payment-links=
/
>
> You are loosing me here ... "payment" already exists in <http://tools.iet=
f.org/html/rfc5988#section-6.3>. And why is that spec not defining URI temp=
late variables and references the URI Template draft? <http://tools.ietf.or=
g/html/rfc6570>
>

Yes rel=3D"payment" does exist already and as far as I know no-one
defined what it really did, or how to use it, so no-one used it.
Someone now is actually trying to define some real semantics for it so
that it can actually be useful.


>
>> rel=3Dhub
>> https://pubsubhubbub.googlecode.com/git/pubsubhubbub-core-0.4.html
>
> The target 'is a hub' - what else do I need to know?
>

Where in the HTTP spec does it tell me what are the consequences of
doing a POST to link with rel=3D"hub"?  If that information shouldn't be
in the link relation specification, where should it be?


>> rel=3Doauth2-token http://tools.ietf.org/html/draft-wmills-oauth-lrdd-07=
#page-8
>
> target is a resource where I can obtain an oauth2 token
>

How do you get a token?  By doing a GET? a POST?  Where should this be
documented?


>>
>> As far as I understand it, all of these have an associated meaning to
>> a POST request.
>
> Which is simpl not possible - you cannot override HTTP and still be 'with=
in the system'. If you associate meaning with POST, you are defining an app=
lication protocol on top of HTTP.
>

But we are not redefining the meaning of POST.  Httpbis _explicitly_
says the meaning of POST is defined by the target resource and the rel
tells me that kind of resource that target resource is.


>>  Curiously, that meaning is not described in the rel
>> relation registration, but in the specification that describes the
>> protocol that uses the link relation.
>
> Which you can, if you mark it as a 'hint' or 'example' - just do not tric=
k the client into making assumptions that REST deliberately wants the clien=
t *not* to make.
>

Let me quote from Roy's famous "REST APIs must be hypertext driven" blog po=
st.

"The only types that are significant to a client are the current
representation=92s media type and standardized relation names."

Let me re-phrase that to make my point.  Standard relation names can
be significant to the client.  I.e. In the same way we know from the
content-Type text/html that a tag called <form> can cause the user
agent to generate a POST request with a body
application/x-www-form-urlencoded we can use "Standardized relation
names" to tell the client how to generate POST requests with specific
media types.   Or is your assertion web browsers are making a non
RESTful assumption?


> The most interesting thing about all this is, IMHO, that you frankly do n=
ot need to know, because the method to use is usually sraight forward given=
 the context. I mean, what method would you use for obtaining an oauth2 tok=
en?

So, are you asserting is that it is straightforward to know that you
must do a POST with application/x-www-form-urlencoded and a subset of
the following parameters:
grant_type,code,redirect_uri,username,password,scope.  And don't
forget each of those parameters have certain constraints defined by
the OAuth framework.

I apologize if any of this comes across as aggressive, I have tried to
filter out how annoyed I am, but may have failed.  I completely
respect your opinion.  I don't agree with it, but I hope we can work
towards a common ground.


Darrel

From jan.algermissen@nordsc.com  Wed Jan 15 14:43:16 2014
Return-Path: <jan.algermissen@nordsc.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 944681AE22F for <apps-discuss@ietfa.amsl.com>; Wed, 15 Jan 2014 14:43:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.951
X-Spam-Level: 
X-Spam-Status: No, score=-0.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_37=0.6, 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 L37w70jnCAQN for <apps-discuss@ietfa.amsl.com>; Wed, 15 Jan 2014 14:43:14 -0800 (PST)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by ietfa.amsl.com (Postfix) with ESMTP id 955F91AE225 for <apps-discuss@ietf.org>; Wed, 15 Jan 2014 14:43:14 -0800 (PST)
Received: from [192.168.2.103] (p548FAFBD.dip0.t-ipconnect.de [84.143.175.189]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0MQd8X-1VvgOO33Qj-00Uli0; Wed, 15 Jan 2014 23:43:01 +0100
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jan Algermissen <jan.algermissen@nordsc.com>
In-Reply-To: <CAKioOquOW1Gogr5SR3E88=U31rvk8LEya62bJg++KbuXDXF+iA@mail.gmail.com>
Date: Wed, 15 Jan 2014 23:43:01 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <110C8DC5-A85F-4BDF-BF7F-07CCDBE0CADE@nordsc.com>
References: <20140115140544.27701.78043.idtracker@ietfa.amsl.com> <CAGuwm8V+cFGE4aYP4rsZtGQR3_NPBOxf_t_BRgfxQbbTvOJTVQ@mail.gmail.com> <F1F4C81D-5106-46B9-9A4C-B3C2F696A07F@nordsc.com> <CAGuwm8Vh_bAKW9Lo3qLy5Usb5atM52BQ3cm_4WGc0X1--3QvKA@mail.gmail.com> <05628088-5731-4BEB-BD79-7C83896279FF@nordsc.com> <CAPW_8m66V2YJeGMK3zN_qnKpph8ujnrA85585FFwLoBtfWvfXA@mail.gmail.com> <CAKioOqt4-7tOoN66zth2vatLUFBXRSRaG4973trpEQRMP9dyYQ@mail.gmail.com> <4ACFE05D-D204-4363-9A8B-AAC7F0695D66@nordsc.com> <CAKioOquOW1Gogr5SR3E88=U31rvk8LEya62bJg++KbuXDXF+iA@mail.gmail.com>
To: darrel@tavis.ca
X-Mailer: Apple Mail (2.1510)
X-Provags-ID: V02:K0:NBS6kAdns5QX8AzU1vRcEBbMUvSW4TVRr1Ej9/BQWA6 SfyEpfyah27UoiORnUpFfLRt7l3N4qSXleMBCH2v5Lo1NNfqPW O0wfZEmo1xQ5KtrX1RpYmE1kZLT9AFz32H6R3o+NZvoHAT40U4 hdlQOZ7v5eZdvWFboZP6g1o83uC3WB4TuokYhCEgjS18gJp6wn zRNa5RTo4+IpHgZMdOOUf42iJBgd1Mgdk9cP9gRYCQ8dvtyD3H H65tSI0scIulIUZ5KQ3C0q0jVLVCu41ueFZRGMuMepr5Q2gLJn 3DQABicQH7i5Q72goKPSvyU4vuqZrlH79inKW10TOstxRV2zRh uJDz0OzdxvVGH0mvSh4fk04rPLqsq/0MvaUcsCjjvudHmwIlqk KmSxf8pLJOD3w==
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] New Version Notification for draft-hamnaberg-publish-link-relation-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Jan 2014 22:43:16 -0000

On 15.01.2014, at 23:18, Darrel Miller <darrel.miller@gmail.com> wrote:

> Jan,
>=20
>=20
> On Wed, Jan 15, 2014 at 4:35 PM, Jan Algermissen
> <jan.algermissen@nordsc.com> wrote:
>>=20
>> Uuuh - POST means POST ("process this"). A link rel cannot re-specify =
that.
>>=20
>> The rel conveys information about the nature of a target resource. =
This helps the client to form an expection about the resource and =
interact with it if it is programmed to do so. Maybe the resource does =
not even support a POST.
>>=20
>=20
> So, you agree that the rel "conveys the nature of a target resource".
> And httpbis says
>=20
> "The POST method requests that the target resource process the
> representation enclosed in the request according to the resource's own
> specific semantics."
>=20
> So, if we put those two together then we can determine that the rel
> defines the nature of the target resource and the resource defines the
> semantics of POST for interactions with that resource.

=46rom the POV of the client POST means "process according to what you =
'are'". And yes, the link rel leads the client to combine the POST with =
an expectation about the effect - manifested in the choice of resource =
(which is lead by the rel).

But I would not got further than that, let alone say "POSTing to a foo =
means X'.

>  Hence, I'm
> going to conclude that it is not a huge stretch to say that you can
> use link relations to define the semantics of a POST.

How can a link relation spec say anything about what method a resource =
will support at any given point in time?

But still, what bothers me the most os that you simply do not *need to* =
say all this.

To me, doing so merely signals RPC-driven thinking (not saying *you* do =
not 'get it').


>=20
>>>=20
>>> If that concerns you then do you have suggestions on how the these
>>> link relations should work:
>>>=20
>>> rel=3Dpayment        =
https://web-payments.org/specs/source/payment-links/
>>=20
>> You are loosing me here ... "payment" already exists in =
<http://tools.ietf.org/html/rfc5988#section-6.3>. And why is that spec =
not defining URI template variables and references the URI Template =
draft? <http://tools.ietf.org/html/rfc6570>
>>=20
>=20
> Yes rel=3D"payment" does exist already and as far as I know no-one
> defined what it really did, or how to use it, so no-one used it.
> Someone now is actually trying to define some real semantics for it so
> that it can actually be useful.

Hmm, but 'a resource where payment can be made' seems like fine =
semantics to me. I guess the original idea was somehow connected to "402 =
Payment Required" - if you find you need to pay for access, =
rel=3D"payment" is how you find out where.

>=20
>=20
>>=20
>>> rel=3Dhub
>>> https://pubsubhubbub.googlecode.com/git/pubsubhubbub-core-0.4.html
>>=20
>> The target 'is a hub' - what else do I need to know?
>>=20
>=20
> Where in the HTTP spec does it tell me what are the consequences of
> doing a POST to link with rel=3D"hub"?  If that information shouldn't =
be
> in the link relation specification, where should it be?
>=20

Isn't the nature of a pubsuhubbub hub just all you need to know?

>=20
>>> rel=3Doauth2-token =
http://tools.ietf.org/html/draft-wmills-oauth-lrdd-07#page-8
>>=20
>> target is a resource where I can obtain an oauth2 token
>>=20
>=20
> How do you get a token?  By doing a GET? a POST?  Where should this be
> documented?

How would you think you should get a token with an idempotent and safe =
GET? With a PUT? nah? DELETE?

Hence: POST.

>=20
>=20
>>>=20
>>> As far as I understand it, all of these have an associated meaning =
to
>>> a POST request.
>>=20
>> Which is simpl not possible - you cannot override HTTP and still be =
'within the system'. If you associate meaning with POST, you are =
defining an application protocol on top of HTTP.
>>=20
>=20
> But we are not redefining the meaning of POST.  Httpbis _explicitly_
> says the meaning of POST is defined by the target resource

No, it says "process according to .. own semantics". Maybe another, last =
finding for httpbis?

> and the rel
> tells me that kind of resource that target resource is.
>=20
>=20
>>> Curiously, that meaning is not described in the rel
>>> relation registration, but in the specification that describes the
>>> protocol that uses the link relation.
>>=20
>> Which you can, if you mark it as a 'hint' or 'example' - just do not =
trick the client into making assumptions that REST deliberately wants =
the client *not* to make.
>>=20
>=20
> Let me quote from Roy's famous "REST APIs must be hypertext driven" =
blog post.
>=20
> "The only types that are significant to a client are the current
> representation=92s media type and standardized relation names."
>=20
> Let me re-phrase that to make my point.  Standard relation names can
> be significant to the client.  I.e. In the same way we know from the
> content-Type text/html that a tag called <form> can cause the user
> agent to generate a POST request with a body
> application/x-www-form-urlencoded we can use "Standardized relation
> names" to tell the client how to generate POST requests with specific
> media types.   Or is your assertion web browsers are making a non
> RESTful assumption?

Hmm, nice point. Will come back on that tomorrow.

>=20
>=20
>> The most interesting thing about all this is, IMHO, that you frankly =
do not need to know, because the method to use is usually sraight =
forward given the context. I mean, what method would you use for =
obtaining an oauth2 token?
>=20
> So, are you asserting is that it is straightforward to know that you
> must do a POST with application/x-www-form-urlencoded and a subset of
> the following parameters:
> grant_type,code,redirect_uri,username,password,scope.  And don't
> forget each of those parameters have certain constraints defined by
> the OAuth framework.

Id id not say I liked OAuth2 or the link rel very much :-)  The stuff =
you mention above is surely something to be discovered at runtime.
[Set aside maybe the problem that security and discovery don't mix so =
well since a MITM could trick me in discovering malicious suff :-) I am =
still personally chewing on discovery and security. Should a 401 =
response tell a client where an authorization server is???]

>=20
> I apologize if any of this comes across as aggressive

Nah - I like sticking to positions rather than giving up too fast. =
Yields much better analysis.

> , I have tried to
> filter out how annoyed I am, but may have failed.  I completely
> respect your opinion. =20

Dito!

> I don't agree with it, but I hope we can work
> towards a common ground.
>=20

I'll chew on that paragraph above. Not having a good answer yet.

Jan

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


From darrel.miller@gmail.com  Wed Jan 15 14:45:00 2014
Return-Path: <darrel.miller@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 814081AE3C9 for <apps-discuss@ietfa.amsl.com>; Wed, 15 Jan 2014 14:45:00 -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 7ufhQsGzgu8F for <apps-discuss@ietfa.amsl.com>; Wed, 15 Jan 2014 14:44:58 -0800 (PST)
Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) by ietfa.amsl.com (Postfix) with ESMTP id CBA8E1AE225 for <apps-discuss@ietf.org>; Wed, 15 Jan 2014 14:44:58 -0800 (PST)
Received: by mail-ig0-f182.google.com with SMTP id uy17so5918303igb.3 for <apps-discuss@ietf.org>; Wed, 15 Jan 2014 14:44:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=/47cVsDNK5+fa9cyUkjJTTNAthX/lXZ1XRD/mBI20nU=; b=a6FYKOyRtbeyrjYxF6vW+p3vaTBbvKXJHLZPQyJ2tY4gshKZMe7h2dGKjmwiXFcUsk DYayMWkD/4s3jBUQ+bn50CdQYpUcO9qGar3W0p0yVmPdvwCrvfQi5PIC0WD+V9gE/E1G RaqGQZ3XpxQW3wuyHuRYFDExi1oyAyxhAhvTDLytVWUqeGsBgQp60GQR8SRKkIv5LgMw lJvHLjb/PoQXwdQHGkLVah3XmpmN86Cs/CpDaIlZfEjHREXackI3c+iqPKMisTKWD7ec uuCDesVH6P5d71HJ62GrfKAUAWe/3YT/WKbHCrR9SAJqOIl2CnivV8toO7TgWxc1ZORE fzYA==
MIME-Version: 1.0
X-Received: by 10.50.126.10 with SMTP id mu10mr5796148igb.24.1389825886838; Wed, 15 Jan 2014 14:44:46 -0800 (PST)
Received: by 10.42.195.206 with HTTP; Wed, 15 Jan 2014 14:44:46 -0800 (PST)
In-Reply-To: <CAPW_8m7F8VFN1XXFkYYfVvTN2RNcOmGo3zEzjiq-bg-uWDpZ-w@mail.gmail.com>
References: <20140115140544.27701.78043.idtracker@ietfa.amsl.com> <CAGuwm8V+cFGE4aYP4rsZtGQR3_NPBOxf_t_BRgfxQbbTvOJTVQ@mail.gmail.com> <F1F4C81D-5106-46B9-9A4C-B3C2F696A07F@nordsc.com> <CAGuwm8Vh_bAKW9Lo3qLy5Usb5atM52BQ3cm_4WGc0X1--3QvKA@mail.gmail.com> <05628088-5731-4BEB-BD79-7C83896279FF@nordsc.com> <CAPW_8m66V2YJeGMK3zN_qnKpph8ujnrA85585FFwLoBtfWvfXA@mail.gmail.com> <CAKioOqt4-7tOoN66zth2vatLUFBXRSRaG4973trpEQRMP9dyYQ@mail.gmail.com> <CAPW_8m7F8VFN1XXFkYYfVvTN2RNcOmGo3zEzjiq-bg-uWDpZ-w@mail.gmail.com>
Date: Wed, 15 Jan 2014 17:44:46 -0500
Message-ID: <CAKioOqtvpx6YEkM8PaQaPkeEX64JNn560ybZFugfOQz-Q80-Ow@mail.gmail.com>
From: Darrel Miller <darrel.miller@gmail.com>
To: mike amundsen <mamund@yahoo.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] New Version Notification for draft-hamnaberg-publish-link-relation-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: darrel@tavis.ca
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Jan 2014 22:45:00 -0000

Mike,


On Wed, Jan 15, 2014 at 4:37 PM, mike amundsen <mamund@yahoo.com> wrote:
> I'm not a fan of using a string as a network affordance ;) I know this is
> not a universally held conviction. for example, HAL relies on this very
> notion quite heavily.

Isn't content type a string?  Don't we rely heavily on content type
for conveying semantics?


>
> i assert the best way to use link relation values is as identifiers. The
> registry let's use describe these values in a general way much the way a
> language dictionary (e.g. English, French, etc.) does. The way in which the
> words are used, their intent, implied meaning, etc. are often based on
> immediate context ("you owe me a payment" vs. "there is were you go to make
> payments") and so forth.
>

Ideally, all link relations would have no constraints on their
interaction semantics.  However, to say that we should not attach
interaction semantics to a link relation limits, our ability to use
link relations to point to resources that do have limits on their
interaction.  The OAuth2 spec has decided that retrieving a token is
an unsafe operation.  It seems rather ridiculous to have a client that
understands the meaning of the rel="oauth2-token" but has to guess at
what HTTP method to use because we don't want to write that constraint
in the spec.  Sure, we could add link hints to suggest to the client
that probably POST is the right method and add accept-post to tell it
the media type and href vars to tell it the parameters.  Or we could
just document it in the link relation spec and when it has breaking
changes create an oauth3-token.
If we don't convey to the client the details of the OAuth dance via
links and link relations, then how can the client possibly do OAuth
authentication without out of band knowledge.  There is no HTTP header
to say "let's do the OAuth dance".


> To your last point, I think tying operational semantics to a link relation
> is over-constraining and limits it's use over time. Esp. when the
> operational semantics are tied to a single protocol or format. I prefer to
> keep usage details separate from the registry of unique values.
>

Yes, tying operational semantics to a link relation is constraining
its usage.  But I think the practical value to be gained by lowering
the idealism bar far outweighs the negatives effects of link relations
with limited applicability.

Don't you remember the time before C+J and HAL and JSON-LD and
JSON-API and Siren when we were being told, there is no need to create
more media types.  I believe the upsurge in the adoption of hypermedia
is due in no small part to the creation of these imperfect hypermedia
types.

Most of the hypermedia I see these days are using extension link
relations. That's because people can't see how they can use standard
link relations in their domains.  We need to loosen the reins and let
some imperfection seep into the link relations.   Having every
developer create their own extension link relations is just as bad as
the "media type explosion" that was feared.

Darrel

From mca@amundsen.com  Wed Jan 15 15:03:27 2014
Return-Path: <mca@amundsen.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E6B91AE2B6 for <apps-discuss@ietfa.amsl.com>; Wed, 15 Jan 2014 15:03:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.755
X-Spam-Level: *
X-Spam-Status: No, score=1.755 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FM_FORGED_GMAIL=0.622, FORGED_YAHOO_RCVD=1.63, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, J_CHICKENPOX_38=0.6, NML_ADSP_CUSTOM_MED=0.9, 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 LCbmU5btCvfr for <apps-discuss@ietfa.amsl.com>; Wed, 15 Jan 2014 15:03:25 -0800 (PST)
Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by ietfa.amsl.com (Postfix) with ESMTP id 0034E1AE22A for <apps-discuss@ietf.org>; Wed, 15 Jan 2014 15:03:24 -0800 (PST)
Received: by mail-wi0-f182.google.com with SMTP id ex4so2899981wid.15 for <apps-discuss@ietf.org>; Wed, 15 Jan 2014 15:03:12 -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:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-type; bh=Wz+teCwPSkBZbpmNalaU6ANEEJ3dLE2fG0e1aTCLfes=; b=ELHecJNKzQRNa4W4wIvTXJkuYvUDJaMVoBXEXA0MGecME0mnp4Zcp4ZzAiBIjDlyoJ XI53sYAKc7PQ7VqdnxsxFhhnw9ELDoHciP1t9D7pPu7J6v0jSwD0qJR6Ggmle+mojz7k u7dFuVgsid2SZgSiLGkf690qsdqCVkyoqN5nQNid3F5ukDTjvnRPhhTH2DoFPUGBHPsS NakhFVJos74BfNEHLsVrHZvoctXczs+AgcUt/nWOE9k8aI1gpZock/z5EKuq18UQXuK+ IX5svCFe5fqpcOni2TN+2AJBegkONZty8e8lhwVtitwxjGHHIuImsyCLAmvZJAhnkbFU SfrQ==
X-Gm-Message-State: ALoCoQlIsXrTtznUMqHD2vL1EZeL6dcsHcOENKIzmI2UfBk92wDtWNX0swy8hrc9IPstaoiNDqF3
X-Received: by 10.180.107.136 with SMTP id hc8mr4884390wib.11.1389826989502; Wed, 15 Jan 2014 15:03:09 -0800 (PST)
MIME-Version: 1.0
Sender: mca@amundsen.com
Received: by 10.194.119.226 with HTTP; Wed, 15 Jan 2014 15:02:49 -0800 (PST)
In-Reply-To: <CAKioOquOW1Gogr5SR3E88=U31rvk8LEya62bJg++KbuXDXF+iA@mail.gmail.com>
References: <20140115140544.27701.78043.idtracker@ietfa.amsl.com> <CAGuwm8V+cFGE4aYP4rsZtGQR3_NPBOxf_t_BRgfxQbbTvOJTVQ@mail.gmail.com> <F1F4C81D-5106-46B9-9A4C-B3C2F696A07F@nordsc.com> <CAGuwm8Vh_bAKW9Lo3qLy5Usb5atM52BQ3cm_4WGc0X1--3QvKA@mail.gmail.com> <05628088-5731-4BEB-BD79-7C83896279FF@nordsc.com> <CAPW_8m66V2YJeGMK3zN_qnKpph8ujnrA85585FFwLoBtfWvfXA@mail.gmail.com> <CAKioOqt4-7tOoN66zth2vatLUFBXRSRaG4973trpEQRMP9dyYQ@mail.gmail.com> <4ACFE05D-D204-4363-9A8B-AAC7F0695D66@nordsc.com> <CAKioOquOW1Gogr5SR3E88=U31rvk8LEya62bJg++KbuXDXF+iA@mail.gmail.com>
From: mike amundsen <mamund@yahoo.com>
Date: Wed, 15 Jan 2014 18:02:49 -0500
X-Google-Sender-Auth: VCE_vczbLewig3SrQP42D52KR74
Message-ID: <CAPW_8m6UZXxY1+C=SidZxD3RQ2ut4LvjQAuQUC4Wzq=19319DQ@mail.gmail.com>
To: Darrel Miller <darrel@tavis.ca>
Content-Type: multipart/alternative; boundary=e89a8f3bad450249ef04f00a50bb
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] New Version Notification for draft-hamnaberg-publish-link-relation-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Jan 2014 23:03:27 -0000

--e89a8f3bad450249ef04f00a50bb
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

PMFJI...

<snip>
>> rel=3Doauth2-token
http://tools.ietf.org/html/draft-wmills-oauth-lrdd-07#page-8
>
> target is a resource where I can obtain an oauth2 token
>
How do you get a token?  By doing a GET? a POST?  Where should this be
documented?
</snip>

The rei is NOT the affordance. It does not tell you how to do anything.

for HTML/HTTP this is one way to know "how":
<form method=3D"get" href=3D"..." class=3D"oauth2-token">...</form>
AND/OR
<form method=3D"post" href=3D"..." class=3D"oauth2-token">...</form>

over CoAP, MQTT, using Cj, Siren, etc. the details will vary but what is
consistent is that you get hits "how" information via the affordance
itself. IMO, do not need to load network semantics into a link rel value.
and, as i mentioned earlier in this thread, i think doing so is a bad idea.

<snip>
So, if we put those two together then we can determine that the rel
defines the nature of the target resource and the resource defines the
semantics of POST for interactions with that resource.
</snip>

yes. IF you put those two together. that doesn't mean you MUST. that
doesn't mean putting them together as part of the link rel valu
registration is the best (or only) way to do it. that doesn't even mean it
is a good idea. that just means IF.

<snip>
Hence, I'm going to conclude that it is not a huge stretch to say that you
can use link relations to define the semantics of a POST.
</snip>

not sure what you think you are "stretching" here. the HTTP spec? the
LinkRel registry? logic? credibility? ;D

finally, just because you CAN doesn't mean you SHOULD.

Cheers.





mamund
+1.859.757.1449
skype: mca.amundsen
http://amundsen.com/blog/
http://twitter.com/mamund
https://github.com/mamund
http://linkedin.com/in/mamund


On Wed, Jan 15, 2014 at 5:18 PM, Darrel Miller <darrel.miller@gmail.com>wro=
te:

> Jan,
>
>
> On Wed, Jan 15, 2014 at 4:35 PM, Jan Algermissen
> <jan.algermissen@nordsc.com> wrote:
> >
> > Uuuh - POST means POST ("process this"). A link rel cannot re-specify
> that.
> >
> > The rel conveys information about the nature of a target resource. This
> helps the client to form an expection about the resource and interact wit=
h
> it if it is programmed to do so. Maybe the resource does not even support=
 a
> POST.
> >
>
> So, you agree that the rel "conveys the nature of a target resource".
> And httpbis says
>
> "The POST method requests that the target resource process the
> representation enclosed in the request according to the resource's own
> specific semantics."
>
> So, if we put those two together then we can determine that the rel
> defines the nature of the target resource and the resource defines the
> semantics of POST for interactions with that resource.  Hence, I'm
> going to conclude that it is not a huge stretch to say that you can
> use link relations to define the semantics of a POST.
>
> >>
> >> If that concerns you then do you have suggestions on how the these
> >> link relations should work:
> >>
> >> rel=3Dpayment        https://web-payments.org/specs/source/payment-lin=
ks/
> >
> > You are loosing me here ... "payment" already exists in <
> http://tools.ietf.org/html/rfc5988#section-6.3>. And why is that spec not
> defining URI template variables and references the URI Template draft? <
> http://tools.ietf.org/html/rfc6570>
> >
>
> Yes rel=3D"payment" does exist already and as far as I know no-one
> defined what it really did, or how to use it, so no-one used it.
> Someone now is actually trying to define some real semantics for it so
> that it can actually be useful.
>
>
> >
> >> rel=3Dhub
> >> https://pubsubhubbub.googlecode.com/git/pubsubhubbub-core-0.4.html
> >
> > The target 'is a hub' - what else do I need to know?
> >
>
> Where in the HTTP spec does it tell me what are the consequences of
> doing a POST to link with rel=3D"hub"?  If that information shouldn't be
> in the link relation specification, where should it be?
>
>
> >> rel=3Doauth2-token
> http://tools.ietf.org/html/draft-wmills-oauth-lrdd-07#page-8
> >
> > target is a resource where I can obtain an oauth2 token
> >
>
> How do you get a token?  By doing a GET? a POST?  Where should this be
> documented?
>
>
> >>
> >> As far as I understand it, all of these have an associated meaning to
> >> a POST request.
> >
> > Which is simpl not possible - you cannot override HTTP and still be
> 'within the system'. If you associate meaning with POST, you are defining
> an application protocol on top of HTTP.
> >
>
> But we are not redefining the meaning of POST.  Httpbis _explicitly_
> says the meaning of POST is defined by the target resource and the rel
> tells me that kind of resource that target resource is.
>
>
> >>  Curiously, that meaning is not described in the rel
> >> relation registration, but in the specification that describes the
> >> protocol that uses the link relation.
> >
> > Which you can, if you mark it as a 'hint' or 'example' - just do not
> trick the client into making assumptions that REST deliberately wants the
> client *not* to make.
> >
>
> Let me quote from Roy's famous "REST APIs must be hypertext driven" blog
> post.
>
> "The only types that are significant to a client are the current
> representation=92s media type and standardized relation names."
>
> Let me re-phrase that to make my point.  Standard relation names can
> be significant to the client.  I.e. In the same way we know from the
> content-Type text/html that a tag called <form> can cause the user
> agent to generate a POST request with a body
> application/x-www-form-urlencoded we can use "Standardized relation
> names" to tell the client how to generate POST requests with specific
> media types.   Or is your assertion web browsers are making a non
> RESTful assumption?
>
>
> > The most interesting thing about all this is, IMHO, that you frankly do
> not need to know, because the method to use is usually sraight forward
> given the context. I mean, what method would you use for obtaining an
> oauth2 token?
>
> So, are you asserting is that it is straightforward to know that you
> must do a POST with application/x-www-form-urlencoded and a subset of
> the following parameters:
> grant_type,code,redirect_uri,username,password,scope.  And don't
> forget each of those parameters have certain constraints defined by
> the OAuth framework.
>
> I apologize if any of this comes across as aggressive, I have tried to
> filter out how annoyed I am, but may have failed.  I completely
> respect your opinion.  I don't agree with it, but I hope we can work
> towards a common ground.
>
>
> Darrel
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

--e89a8f3bad450249ef04f00a50bb
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">PMFJI...<div><br></div><div style>&lt;snip&gt;</div><div s=
tyle><div class=3D"im" style=3D"font-family:arial,sans-serif;font-size:13px=
">&gt;&gt; rel=3Doauth2-token=A0<a href=3D"http://tools.ietf.org/html/draft=
-wmills-oauth-lrdd-07#page-8" target=3D"_blank">http://tools.ietf.org/html/=
draft-wmills-oauth-lrdd-07#page<span class=3D"">-8</span></a><br>

&gt;<br>&gt; target is a resource where I can obtain an oauth2 token<br>&gt=
;<br><span style=3D"color:rgb(34,34,34)">How do you get a token? =A0By doin=
g a=A0</span><span class=3D"" style=3D"color:rgb(34,34,34)">GET</span><span=
 style=3D"color:rgb(34,34,34)">? a POST? =A0Where should this be</span><br>

</div><span style=3D"font-family:arial,sans-serif;font-size:13px">documente=
d?</span><br></div><div style><span style=3D"font-family:arial,sans-serif;f=
ont-size:13px">&lt;/snip&gt;</span></div><div style><span style=3D"font-fam=
ily:arial,sans-serif;font-size:13px"><br>

</span></div><div style><span style=3D"font-family:arial,sans-serif;font-si=
ze:13px">The rei is NOT the affordance. It does not tell you how to do anyt=
hing.</span></div><div style><span style=3D"font-family:arial,sans-serif;fo=
nt-size:13px"><br>

</span></div><div style><span style=3D"font-family:arial,sans-serif;font-si=
ze:13px">for HTML/HTTP this is one way to know &quot;how&quot;:</span></div=
><div style><span style=3D"font-family:arial,sans-serif;font-size:13px">&lt=
;form method=3D&quot;get&quot; href=3D&quot;...&quot; class=3D&quot;oauth2-=
token&quot;&gt;...&lt;/form&gt;</span></div>

<div style><span style=3D"font-family:arial,sans-serif;font-size:13px">AND/=
OR</span></div><div style><span style=3D"font-family:arial,sans-serif;font-=
size:13px">&lt;form method=3D&quot;post&quot; href=3D&quot;...&quot; class=
=3D&quot;oauth2-token&quot;&gt;...&lt;/form&gt;</span></div>

<div style><span style=3D"font-family:arial,sans-serif;font-size:13px"><br>=
</span></div><div style><span style=3D"font-family:arial,sans-serif;font-si=
ze:13px">over CoAP, MQTT, using Cj, Siren, etc. the details will vary but w=
hat is consistent is that you get hits &quot;how&quot; information via the =
affordance itself. IMO, do not need to load network semantics into a link r=
el value. and, as i mentioned earlier in this thread, i think doing so is a=
 bad idea.</span></div>

<div style><span style=3D"font-family:arial,sans-serif;font-size:13px"><br>=
</span></div><div style><span style=3D"font-family:arial,sans-serif;font-si=
ze:13px">&lt;snip&gt;</span></div><div style><span style=3D"font-family:ari=
al,sans-serif;font-size:13px">So, if we put those two together then we can =
determine that the rel</span><br style=3D"font-family:arial,sans-serif;font=
-size:13px">

<span style=3D"font-family:arial,sans-serif;font-size:13px">defines the nat=
ure of the target resource and the resource defines the</span><br style=3D"=
font-family:arial,sans-serif;font-size:13px"><span style=3D"font-family:ari=
al,sans-serif;font-size:13px">semantics of POST for interactions with that =
resource.</span></div>

<div style><span style=3D"font-family:arial,sans-serif;font-size:13px">&lt;=
/snip&gt;</span></div><div style><span style=3D"font-family:arial,sans-seri=
f;font-size:13px"><br></span></div><div style><font face=3D"arial, sans-ser=
if">yes. IF you put those two together. that doesn&#39;t mean you MUST. tha=
t doesn&#39;t mean putting them together as part of the link rel valu regis=
tration is the best (or only) way to do it. that doesn&#39;t even mean it i=
s a good idea. that just means IF.</font></div>

<div style><font face=3D"arial, sans-serif"><br></font></div><div style><sp=
an style=3D"font-family:arial,sans-serif;font-size:13px">&lt;snip&gt;</span=
></div><div style><span style=3D"font-family:arial,sans-serif;font-size:13p=
x">Hence, I&#39;m=A0</span><span style=3D"font-family:arial,sans-serif;font=
-size:13px">going to conclude that it is not a huge stretch to say that you=
 can=A0</span><span style=3D"font-family:arial,sans-serif;font-size:13px">u=
se link relations to define the semantics of a POST.</span><span style=3D"f=
ont-family:arial,sans-serif;font-size:13px"><br>

</span></div><div style><span style=3D"font-family:arial,sans-serif;font-si=
ze:13px">&lt;/snip&gt;</span></div><div style><span style=3D"font-family:ar=
ial,sans-serif;font-size:13px"><br></span></div><div style><span style=3D"f=
ont-family:arial,sans-serif;font-size:13px">not sure what you think you are=
 &quot;stretching&quot; here. the HTTP spec? the LinkRel registry? logic?=
=A0</span><span style=3D"font-family:arial,sans-serif;font-size:13px">credi=
bility?</span><span style=3D"font-family:arial,sans-serif;font-size:13px">=
=A0;D</span></div>

<div style><span style=3D"font-family:arial,sans-serif;font-size:13px"><br>=
</span></div><div style><span style=3D"font-family:arial,sans-serif;font-si=
ze:13px">finally, just because you CAN doesn&#39;t mean you SHOULD.</span><=
/div>

<div style><span style=3D"font-family:arial,sans-serif;font-size:13px"><br>=
</span></div><div style><span style=3D"font-family:arial,sans-serif;font-si=
ze:13px">Cheers.</span></div><div style><span style=3D"font-family:arial,sa=
ns-serif;font-size:13px"><br>

</span></div><div style><br></div><div style><br></div></div><div class=3D"=
gmail_extra"><br clear=3D"all"><div><div dir=3D"ltr"><div><br></div>mamund<=
div><span><span title=3D"Call with Google Voice"><span title=3D"Call with G=
oogle Voice">+1.859.757.1449</span></span></span><br>

skype: mca.amundsen<br><a href=3D"http://amundsen.com/blog/" target=3D"_bla=
nk">http://amundsen.com/blog/</a><br><a href=3D"http://twitter.com/mamund" =
target=3D"_blank">http://twitter.com/mamund</a><br><a href=3D"https://githu=
b.com/mamund" target=3D"_blank">https://github.com/mamund</a><br>

<a href=3D"http://linkedin.com/in/mamund" target=3D"_blank">http://linkedin=
.com/in/mamund</a></div></div></div>
<br><br><div class=3D"gmail_quote">On Wed, Jan 15, 2014 at 5:18 PM, Darrel =
Miller <span dir=3D"ltr">&lt;<a href=3D"mailto:darrel.miller@gmail.com" tar=
get=3D"_blank">darrel.miller@gmail.com</a>&gt;</span> wrote:<br><blockquote=
 class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex">

Jan,<br>
<div class=3D"im"><br>
<br>
On Wed, Jan 15, 2014 at 4:35 PM, Jan Algermissen<br>
&lt;<a href=3D"mailto:jan.algermissen@nordsc.com">jan.algermissen@nordsc.co=
m</a>&gt; wrote:<br>
&gt;<br>
&gt; Uuuh - POST means POST (&quot;process this&quot;). A link rel cannot r=
e-specify that.<br>
&gt;<br>
&gt; The rel conveys information about the nature of a target resource. Thi=
s helps the client to form an expection about the resource and interact wit=
h it if it is programmed to do so. Maybe the resource does not even support=
 a POST.<br>


&gt;<br>
<br>
</div>So, you agree that the rel &quot;conveys the nature of a target resou=
rce&quot;.<br>
And httpbis says<br>
<br>
&quot;The POST method requests that the target resource process the<br>
representation enclosed in the request according to the resource&#39;s own<=
br>
specific semantics.&quot;<br>
<br>
So, if we put those two together then we can determine that the rel<br>
defines the nature of the target resource and the resource defines the<br>
semantics of POST for interactions with that resource. =A0Hence, I&#39;m<br=
>
going to conclude that it is not a huge stretch to say that you can<br>
use link relations to define the semantics of a POST.<br>
<div class=3D"im"><br>
&gt;&gt;<br>
&gt;&gt; If that concerns you then do you have suggestions on how the these=
<br>
&gt;&gt; link relations should work:<br>
&gt;&gt;<br>
&gt;&gt; rel=3Dpayment =A0 =A0 =A0 =A0<a href=3D"https://web-payments.org/s=
pecs/source/payment-links/" target=3D"_blank">https://web-payments.org/spec=
s/source/payment-links/</a><br>
&gt;<br>
&gt; You are loosing me here ... &quot;payment&quot; already exists in &lt;=
<a href=3D"http://tools.ietf.org/html/rfc5988#section-6.3" target=3D"_blank=
">http://tools.ietf.org/html/rfc5988#section-6.3</a>&gt;. And why is that s=
pec not defining URI template variables and references the URI Template dra=
ft? &lt;<a href=3D"http://tools.ietf.org/html/rfc6570" target=3D"_blank">ht=
tp://tools.ietf.org/html/rfc6570</a>&gt;<br>


&gt;<br>
<br>
</div>Yes rel=3D&quot;payment&quot; does exist already and as far as I know=
 no-one<br>
defined what it really did, or how to use it, so no-one used it.<br>
Someone now is actually trying to define some real semantics for it so<br>
that it can actually be useful.<br>
<div class=3D"im"><br>
<br>
&gt;<br>
&gt;&gt; rel=3Dhub<br>
&gt;&gt; <a href=3D"https://pubsubhubbub.googlecode.com/git/pubsubhubbub-co=
re-0.4.html" target=3D"_blank">https://pubsubhubbub.googlecode.com/git/pubs=
ubhubbub-core-0.4.html</a><br>
&gt;<br>
&gt; The target &#39;is a hub&#39; - what else do I need to know?<br>
&gt;<br>
<br>
</div>Where in the HTTP spec does it tell me what are the consequences of<b=
r>
doing a POST to link with rel=3D&quot;hub&quot;? =A0If that information sho=
uldn&#39;t be<br>
in the link relation specification, where should it be?<br>
<div class=3D"im"><br>
<br>
&gt;&gt; rel=3Doauth2-token <a href=3D"http://tools.ietf.org/html/draft-wmi=
lls-oauth-lrdd-07#page-8" target=3D"_blank">http://tools.ietf.org/html/draf=
t-wmills-oauth-lrdd-07#page-8</a><br>
&gt;<br>
&gt; target is a resource where I can obtain an oauth2 token<br>
&gt;<br>
<br>
</div>How do you get a token? =A0By doing a GET? a POST? =A0Where should th=
is be<br>
documented?<br>
<div class=3D"im"><br>
<br>
&gt;&gt;<br>
&gt;&gt; As far as I understand it, all of these have an associated meaning=
 to<br>
&gt;&gt; a POST request.<br>
&gt;<br>
&gt; Which is simpl not possible - you cannot override HTTP and still be &#=
39;within the system&#39;. If you associate meaning with POST, you are defi=
ning an application protocol on top of HTTP.<br>
&gt;<br>
<br>
</div>But we are not redefining the meaning of POST. =A0Httpbis _explicitly=
_<br>
says the meaning of POST is defined by the target resource and the rel<br>
tells me that kind of resource that target resource is.<br>
<div class=3D"im"><br>
<br>
&gt;&gt; =A0Curiously, that meaning is not described in the rel<br>
&gt;&gt; relation registration, but in the specification that describes the=
<br>
&gt;&gt; protocol that uses the link relation.<br>
&gt;<br>
&gt; Which you can, if you mark it as a &#39;hint&#39; or &#39;example&#39;=
 - just do not trick the client into making assumptions that REST deliberat=
ely wants the client *not* to make.<br>
&gt;<br>
<br>
</div>Let me quote from Roy&#39;s famous &quot;REST APIs must be hypertext =
driven&quot; blog post.<br>
<br>
&quot;The only types that are significant to a client are the current<br>
representation=92s media type and standardized relation names.&quot;<br>
<br>
Let me re-phrase that to make my point. =A0Standard relation names can<br>
be significant to the client. =A0I.e. In the same way we know from the<br>
content-Type text/html that a tag called &lt;form&gt; can cause the user<br=
>
agent to generate a POST request with a body<br>
application/x-www-form-urlencoded we can use &quot;Standardized relation<br=
>
names&quot; to tell the client how to generate POST requests with specific<=
br>
media types. =A0 Or is your assertion web browsers are making a non<br>
RESTful assumption?<br>
<div class=3D"im"><br>
<br>
&gt; The most interesting thing about all this is, IMHO, that you frankly d=
o not need to know, because the method to use is usually sraight forward gi=
ven the context. I mean, what method would you use for obtaining an oauth2 =
token?<br>


<br>
</div>So, are you asserting is that it is straightforward to know that you<=
br>
must do a POST with application/x-www-form-urlencoded and a subset of<br>
the following parameters:<br>
grant_type,code,redirect_uri,username,password,scope. =A0And don&#39;t<br>
forget each of those parameters have certain constraints defined by<br>
the OAuth framework.<br>
<br>
I apologize if any of this comes across as aggressive, I have tried to<br>
filter out how annoyed I am, but may have failed. =A0I completely<br>
respect your opinion. =A0I don&#39;t agree with it, but I hope we can work<=
br>
towards a common ground.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
<br>
Darrel<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5">_____________________=
__________________________<br>
apps-discuss mailing list<br>
<a href=3D"mailto:apps-discuss@ietf.org">apps-discuss@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/apps-discuss" target=3D"_b=
lank">https://www.ietf.org/mailman/listinfo/apps-discuss</a><br>
</div></div></blockquote></div><br></div>

--e89a8f3bad450249ef04f00a50bb--

From darrel.miller@gmail.com  Wed Jan 15 15:37:22 2014
Return-Path: <darrel.miller@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C672A1AE246 for <apps-discuss@ietfa.amsl.com>; Wed, 15 Jan 2014 15:37:22 -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 mjJZqjy52MIT for <apps-discuss@ietfa.amsl.com>; Wed, 15 Jan 2014 15:37:21 -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 33ABF1AE0D0 for <apps-discuss@ietf.org>; Wed, 15 Jan 2014 15:37:21 -0800 (PST)
Received: by mail-ig0-f169.google.com with SMTP id uq10so9111979igb.0 for <apps-discuss@ietf.org>; Wed, 15 Jan 2014 15:37:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=rdbXdl89vFrlKiy1Aj5AhGCkIhCpLIjCUJIvSFuffmY=; b=KbEv/umRp0cWVgHBf3r5WzsjUcPvFp1TVZVjAh4OBRormuylJRr8wng1tAsq5Dgl8M DzE1T9ZaIkgz8549x7VqgNVMspC8cKsnQJ3QAucfGQgZ+yIyIQf4XuG11eqjSPXtqQuA 5FSjhNt5MP6QB5ENav6QdkEPTASNNwMetC7KOnXaXSbD0w0rwMQhxEX/1GhDOqDoFxRD ywDddhZXuAT5GYJ9jwKuRf6cUU1YMMpHPFh/xi6ff65ieSrN9u/mlpshux+A/cCdIoG0 HWCLnvWdn7uR+rSJDquZfLuMEDeaLuyLGVapVVwIRjREpMKcFiDNy1tfUKTHAhcU/BX7 nY2Q==
MIME-Version: 1.0
X-Received: by 10.50.102.99 with SMTP id fn3mr5974816igb.5.1389829029256; Wed, 15 Jan 2014 15:37:09 -0800 (PST)
Received: by 10.42.195.206 with HTTP; Wed, 15 Jan 2014 15:37:09 -0800 (PST)
In-Reply-To: <CAPW_8m6UZXxY1+C=SidZxD3RQ2ut4LvjQAuQUC4Wzq=19319DQ@mail.gmail.com>
References: <20140115140544.27701.78043.idtracker@ietfa.amsl.com> <CAGuwm8V+cFGE4aYP4rsZtGQR3_NPBOxf_t_BRgfxQbbTvOJTVQ@mail.gmail.com> <F1F4C81D-5106-46B9-9A4C-B3C2F696A07F@nordsc.com> <CAGuwm8Vh_bAKW9Lo3qLy5Usb5atM52BQ3cm_4WGc0X1--3QvKA@mail.gmail.com> <05628088-5731-4BEB-BD79-7C83896279FF@nordsc.com> <CAPW_8m66V2YJeGMK3zN_qnKpph8ujnrA85585FFwLoBtfWvfXA@mail.gmail.com> <CAKioOqt4-7tOoN66zth2vatLUFBXRSRaG4973trpEQRMP9dyYQ@mail.gmail.com> <4ACFE05D-D204-4363-9A8B-AAC7F0695D66@nordsc.com> <CAKioOquOW1Gogr5SR3E88=U31rvk8LEya62bJg++KbuXDXF+iA@mail.gmail.com> <CAPW_8m6UZXxY1+C=SidZxD3RQ2ut4LvjQAuQUC4Wzq=19319DQ@mail.gmail.com>
Date: Wed, 15 Jan 2014 18:37:09 -0500
Message-ID: <CAKioOquBtYF4PT_F2hWA40mGau4FdCz4UF0o0Y-dm66aZdpqRA@mail.gmail.com>
From: Darrel Miller <darrel.miller@gmail.com>
To: mike amundsen <mamund@yahoo.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] New Version Notification for draft-hamnaberg-publish-link-relation-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: darrel@tavis.ca
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Jan 2014 23:37:23 -0000

Mike,


On Wed, Jan 15, 2014 at 6:02 PM, mike amundsen <mamund@yahoo.com> wrote:
> PMFJI...
>
>
> The rei is NOT the affordance. It does not tell you how to do anything.
>

Right, the rel is not the affordance it is the "type" of affordance
and in my world, types can define semantics.


> for HTML/HTTP this is one way to know "how":
> <form method="get" href="..." class="oauth2-token">...</form>
> AND/OR
> <form method="post" href="..." class="oauth2-token">...</form>

This goes back to our age old debate.  Just because you put a bunch of
parameters in a form doesn't mean the client suddenly knows the
meaning of grant, scope, authorization_code, username.  If you are not
conveying those semantics in the media type (and to my knowledge the
text/html spec hasn't yet absorbed the OAuth spec) then how are you
conveying them?

So here is another question.  Why are you allowed to put interaction
semantics on your <form> tag (e.g. method="get") but it is evil if I
do the same on a <link> tag?  Is this because you feel only media
types are allowed to define interaction details?

>
> <snip>
> So, if we put those two together then we can determine that the rel
> defines the nature of the target resource and the resource defines the
> semantics of POST for interactions with that resource.
> </snip>
>
> yes. IF you put those two together. that doesn't mean you MUST. that doesn't
> mean putting them together as part of the link rel valu registration is the
> best (or only) way to do it. that doesn't even mean it is a good idea. that
> just means IF.
>
I've never said that you MUST.  I am all for creating link relations
with no interaction semantics where possible.  My problem is that we
are being told that we should not do it and that's where I disagree.
I think that sometimes, it can have value.

> <snip>
> Hence, I'm going to conclude that it is not a huge stretch to say that you
> can use link relations to define the semantics of a POST.
> </snip>
>
> not sure what you think you are "stretching" here. the HTTP spec? the
> LinkRel registry? logic? credibility? ;D
>
Our imagination of what is possible without having any significant
negative side effects. :-)


Darrel

From jan.algermissen@nordsc.com  Wed Jan 15 15:53:22 2014
Return-Path: <jan.algermissen@nordsc.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5301F1AE456 for <apps-discuss@ietfa.amsl.com>; Wed, 15 Jan 2014 15:53:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level: 
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 0vp210tuuNIp for <apps-discuss@ietfa.amsl.com>; Wed, 15 Jan 2014 15:53:21 -0800 (PST)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by ietfa.amsl.com (Postfix) with ESMTP id 7D9791AE425 for <apps-discuss@ietf.org>; Wed, 15 Jan 2014 15:53:21 -0800 (PST)
Received: from [192.168.2.103] (p548FAFBD.dip0.t-ipconnect.de [84.143.175.189]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0Lx3gz-1VJKGr1i1J-016Zgu; Thu, 16 Jan 2014 00:53:08 +0100
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jan Algermissen <jan.algermissen@nordsc.com>
In-Reply-To: <CAKioOqtvpx6YEkM8PaQaPkeEX64JNn560ybZFugfOQz-Q80-Ow@mail.gmail.com>
Date: Thu, 16 Jan 2014 00:53:07 +0100
Content-Transfer-Encoding: 7bit
Message-Id: <CBA6A260-D478-4B8B-A204-059418DAA272@nordsc.com>
References: <20140115140544.27701.78043.idtracker@ietfa.amsl.com> <CAGuwm8V+cFGE4aYP4rsZtGQR3_NPBOxf_t_BRgfxQbbTvOJTVQ@mail.gmail.com> <F1F4C81D-5106-46B9-9A4C-B3C2F696A07F@nordsc.com> <CAGuwm8Vh_bAKW9Lo3qLy5Usb5atM52BQ3cm_4WGc0X1--3QvKA@mail.gmail.com> <05628088-5731-4BEB-BD79-7C83896279FF@nordsc.com> <CAPW_8m66V2YJeGMK3zN_qnKpph8ujnrA85585FFwLoBtfWvfXA@mail.gmail.com> <CAKioOqt4-7tOoN66zth2vatLUFBXRSRaG4973trpEQRMP9dyYQ@mail.gmail.com> <CAPW_8m7F8VFN1XXFkYYfVvTN2RNcOmGo3zEzjiq-bg-uWDpZ-w@mail.gmail.com> <CAKioOqtvpx6YEkM8PaQaPkeEX64JNn560ybZFugfOQz-Q80-Ow@mail.gmail.com>
To: darrel@tavis.ca
X-Mailer: Apple Mail (2.1510)
X-Provags-ID: V02:K0:rI5D6fT1hXHtDApyABkHwG/AiMo05jD7wZ1Z+JMUy0I VnJVKPsNNXfkvjKHMM4209TYsVyuV0N+F3MOKmz2BnwS7GEf7L VN+H371wTfZs1TwJ2blS98uB45VAvK29oqvjI6wJO9ojWDjzMA nMrErIBdyo8ok0tzMc82cIWz5ZEnrbBeNuOF1QR4tS6g/zamwD jswb1BTgRKrcBONxcMWDyHF8Zism9zu4obDEsljbSsCNs1N5Q2 gf2ct9n9bnxKjO8qG3bqdgKtTl2ppyTcbwNJ0lcPl/JXtb3z6x cPFObiBJm97edmYWa2UI0Uk836SlzkdJlWzV3RvS5mJLeqHf9b 1jPv8b0YeNvF+z42MOJwYzxhJAjOyhx50nL3csejPm2IwtDruh 7X6fxqrbRgMNg==
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] New Version Notification for draft-hamnaberg-publish-link-relation-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Jan 2014 23:53:22 -0000

On 15.01.2014, at 23:44, Darrel Miller <darrel.miller@gmail.com> wrote:

> There is no HTTP header
> to say "let's do the OAuth dance".

WWW-Authenticate: OAuth

Jan

From jan.algermissen@nordsc.com  Wed Jan 15 16:00:15 2014
Return-Path: <jan.algermissen@nordsc.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE7291AE44F for <apps-discuss@ietfa.amsl.com>; Wed, 15 Jan 2014 16:00:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level: 
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ns1jaAg6O7lh for <apps-discuss@ietfa.amsl.com>; Wed, 15 Jan 2014 16:00:15 -0800 (PST)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by ietfa.amsl.com (Postfix) with ESMTP id ECB1F1AE425 for <apps-discuss@ietf.org>; Wed, 15 Jan 2014 16:00:14 -0800 (PST)
Received: from [192.168.2.103] (p548FAFBD.dip0.t-ipconnect.de [84.143.175.189]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0LzWOk-1VGpaV3OqI-014etq; Thu, 16 Jan 2014 01:00:01 +0100
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jan Algermissen <jan.algermissen@nordsc.com>
In-Reply-To: <CAKioOqtvpx6YEkM8PaQaPkeEX64JNn560ybZFugfOQz-Q80-Ow@mail.gmail.com>
Date: Thu, 16 Jan 2014 01:00:01 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <F8496F5B-0DC4-4EBE-A476-0F6C41C891B8@nordsc.com>
References: <20140115140544.27701.78043.idtracker@ietfa.amsl.com> <CAGuwm8V+cFGE4aYP4rsZtGQR3_NPBOxf_t_BRgfxQbbTvOJTVQ@mail.gmail.com> <F1F4C81D-5106-46B9-9A4C-B3C2F696A07F@nordsc.com> <CAGuwm8Vh_bAKW9Lo3qLy5Usb5atM52BQ3cm_4WGc0X1--3QvKA@mail.gmail.com> <05628088-5731-4BEB-BD79-7C83896279FF@nordsc.com> <CAPW_8m66V2YJeGMK3zN_qnKpph8ujnrA85585FFwLoBtfWvfXA@mail.gmail.com> <CAKioOqt4-7tOoN66zth2vatLUFBXRSRaG4973trpEQRMP9dyYQ@mail.gmail.com> <CAPW_8m7F8VFN1XXFkYYfVvTN2RNcOmGo3zEzjiq-bg-uWDpZ-w@mail.gmail.com> <CAKioOqtvpx6YEkM8PaQaPkeEX64JNn560ybZFugfOQz-Q80-Ow@mail.gmail.com>
To: darrel@tavis.ca
X-Mailer: Apple Mail (2.1510)
X-Provags-ID: V02:K0:DCdBxkII0ZO21od67TD5x+iSNAXDsoB34vZ2GMBN4y0 7tV/vA/zINqcJ+BhtuR802B84g4J1SVQUPE/CdKaEq/APM4cW7 d/Appv5mD40KAJLol9YB+7pI3cvA6h/CkCxU95ZsOaMQs5wf02 XMSk6zbLwYg3X2aboAF05jRxagGBbzdXmEC2Xg8fnbBfCyX2s9 j0y1FtM6aLdPqDW3e7EzoObl8dWggvAK2qKRFja7f8tID3knxs KSqAu+DAvmHInxei6dVygwWZoSu5zmw0QfxoZP5ovEBoYwA4k4 1JmpbLBtnwdcUkVgea98Y2XunnWgUzWte1W37Uu7fTdkM0url8 b86xC0adqvavVjhT3VmMDeHSziSJwiy6hyyqIIdWq7jGm2vNGm 7QACQVRSAL55g==
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] New Version Notification for draft-hamnaberg-publish-link-relation-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Jan 2014 00:00:15 -0000

On 15.01.2014, at 23:44, Darrel Miller <darrel.miller@gmail.com> wrote:

> when we were being told, there is no need to create
> more media types.

Well, I didn't :-) Who did?

Sure you need new media types for new 'domains' of applications. (Think =
'procurement', for example)

In the  (intra-enterprise) projects I was/am involved in some 5-20 media =
types was/is a common number.

Jan=

From darrel.miller@gmail.com  Wed Jan 15 17:10:16 2014
Return-Path: <darrel.miller@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 814141AE203 for <apps-discuss@ietfa.amsl.com>; Wed, 15 Jan 2014 17:10:16 -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 rsy4PfXFrynw for <apps-discuss@ietfa.amsl.com>; Wed, 15 Jan 2014 17:10:15 -0800 (PST)
Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id 0E17E1AE490 for <apps-discuss@ietf.org>; Wed, 15 Jan 2014 17:10:11 -0800 (PST)
Received: by mail-ig0-f179.google.com with SMTP id c10so6215774igq.0 for <apps-discuss@ietf.org>; Wed, 15 Jan 2014 17:10:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Xf2F3pBMOOMcBFIME9GZRWFDLLc5vmdHEo2/G4D5huE=; b=ZZU9I77gmMmcKbUcZeHp1kxoDcy4hCL3yBmqz7S9ndm0LHLtNwSTNcww0VWpWcAo8S 18JXlxGojtr3ANZjYFTJF4wUhD9jj3fITaUUfrNDMHXTdRd4LfJpdvUCFqxmtn0Gy6Uw Ic6+WRR+DiuLHX9omS38oDgjTwZYVBZbfNc6wGzvYUJxw//wTGyDoYu9WMVnZ7y/sgnO ukO8OU5xqd84fK68VlEgboB59UEYs3tmOnUHUC2B8ew9l8flyuwW3/pwIZpUuZsmPijV b4UdTV9jNecVoqnCbsRhVX+EOwuw5zZIu8bCD4CxX5aCTu8AHsFSv2YliyZWOCvzGzGX 8/tg==
MIME-Version: 1.0
X-Received: by 10.43.103.67 with SMTP id dh3mr5350599icc.60.1389834600178; Wed, 15 Jan 2014 17:10:00 -0800 (PST)
Received: by 10.42.195.206 with HTTP; Wed, 15 Jan 2014 17:10:00 -0800 (PST)
In-Reply-To: <CBA6A260-D478-4B8B-A204-059418DAA272@nordsc.com>
References: <20140115140544.27701.78043.idtracker@ietfa.amsl.com> <CAGuwm8V+cFGE4aYP4rsZtGQR3_NPBOxf_t_BRgfxQbbTvOJTVQ@mail.gmail.com> <F1F4C81D-5106-46B9-9A4C-B3C2F696A07F@nordsc.com> <CAGuwm8Vh_bAKW9Lo3qLy5Usb5atM52BQ3cm_4WGc0X1--3QvKA@mail.gmail.com> <05628088-5731-4BEB-BD79-7C83896279FF@nordsc.com> <CAPW_8m66V2YJeGMK3zN_qnKpph8ujnrA85585FFwLoBtfWvfXA@mail.gmail.com> <CAKioOqt4-7tOoN66zth2vatLUFBXRSRaG4973trpEQRMP9dyYQ@mail.gmail.com> <CAPW_8m7F8VFN1XXFkYYfVvTN2RNcOmGo3zEzjiq-bg-uWDpZ-w@mail.gmail.com> <CAKioOqtvpx6YEkM8PaQaPkeEX64JNn560ybZFugfOQz-Q80-Ow@mail.gmail.com> <CBA6A260-D478-4B8B-A204-059418DAA272@nordsc.com>
Date: Wed, 15 Jan 2014 20:10:00 -0500
Message-ID: <CAKioOqt+pqY+0HGj0N-UBu33EJ23N-2VumWDKo-zHAnBEhK=PA@mail.gmail.com>
From: Darrel Miller <darrel.miller@gmail.com>
To: Jan Algermissen <jan.algermissen@nordsc.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] New Version Notification for draft-hamnaberg-publish-link-relation-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: darrel@tavis.ca
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Jan 2014 01:10:16 -0000

On Wed, Jan 15, 2014 at 6:53 PM, Jan Algermissen
<jan.algermissen@nordsc.com> wrote:
>
> On 15.01.2014, at 23:44, Darrel Miller <darrel.miller@gmail.com> wrote:
>
>> There is no HTTP header
>> to say "let's do the OAuth dance".
>
> WWW-Authenticate: OAuth
>

As far as I can tell, OAuth2 isn't registered as an Http authentication scheme.

Darrel

From jan.algermissen@nordsc.com  Wed Jan 15 23:25:58 2014
Return-Path: <jan.algermissen@nordsc.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66AC01AE1EA for <apps-discuss@ietfa.amsl.com>; Wed, 15 Jan 2014 23:25:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level: 
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 80Y3hOtq9gK0 for <apps-discuss@ietfa.amsl.com>; Wed, 15 Jan 2014 23:25:57 -0800 (PST)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by ietfa.amsl.com (Postfix) with ESMTP id 01FA81ADBCD for <apps-discuss@ietf.org>; Wed, 15 Jan 2014 23:25:57 -0800 (PST)
Received: from [172.20.10.5] (tmo-108-12.customers.d1-online.com [80.187.108.12]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0McxrW-1VlcU12EPC-00HoIZ; Thu, 16 Jan 2014 08:25:44 +0100
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jan Algermissen <jan.algermissen@nordsc.com>
In-Reply-To: <CAKioOquBtYF4PT_F2hWA40mGau4FdCz4UF0o0Y-dm66aZdpqRA@mail.gmail.com>
Date: Thu, 16 Jan 2014 08:25:41 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <A7EE36B2-DB41-40A8-A6AF-71008E0145FF@nordsc.com>
References: <20140115140544.27701.78043.idtracker@ietfa.amsl.com> <CAGuwm8V+cFGE4aYP4rsZtGQR3_NPBOxf_t_BRgfxQbbTvOJTVQ@mail.gmail.com> <F1F4C81D-5106-46B9-9A4C-B3C2F696A07F@nordsc.com> <CAGuwm8Vh_bAKW9Lo3qLy5Usb5atM52BQ3cm_4WGc0X1--3QvKA@mail.gmail.com> <05628088-5731-4BEB-BD79-7C83896279FF@nordsc.com> <CAPW_8m66V2YJeGMK3zN_qnKpph8ujnrA85585FFwLoBtfWvfXA@mail.gmail.com> <CAKioOqt4-7tOoN66zth2vatLUFBXRSRaG4973trpEQRMP9dyYQ@mail.gmail.com> <4ACFE05D-D204-4363-9A8B-AAC7F0695D66@nordsc.com> <CAKioOquOW1Gogr5SR3E88=U31rvk8LEya62bJg++KbuXDXF+iA@mail.gmail.com> <CAPW_8m6UZXxY1+C=SidZxD3RQ2ut4LvjQAuQUC4Wzq=19319DQ@mail.gmail.com> <CAKioOquBtYF4PT_F2hWA40mGau4FdCz4UF0o0Y-dm66aZdpqRA@mail.gmail.com>
To: darrel@tavis.ca
X-Mailer: Apple Mail (2.1510)
X-Provags-ID: V02:K0:fDlOmlZyRmq7Y1HKG76UHIzsNWbiX95OAAajvrwAfPT N/Dye7bW6m4GLDz8W7lFhZmJD8cNidodDnPTFN64M8P9cObujJ rYDTnrupjQHYPBNIp+KSKbNU2A19B2LQAuPXic5MG3iYx70BWw 2RS37QRXxVJnT4Dvx3QoIRGNHo+svS1GgwDtIcqjOVFG+uTt1b /v53wim3BW8TXYGvhtipM1Mp+Mg98ikxPLIpRf2N2x/xWVJYfr cJpiS2Dz3eZK+STHq942Jx4MRMYodE9zxMWiGGvxH/HQ1lS7Ge 9CFXFiNUlGRECMS6K80en7g+P4NDl86MgPbIgHHGgGhCFnGx8Z 2yh81suW2WlEkloKDxoWmGuXUQQZUxWdgDut9jPABQ2RNvael8 HVxx1OkU5hBEw==
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] New Version Notification for draft-hamnaberg-publish-link-relation-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Jan 2014 07:25:58 -0000

On 16.01.2014, at 00:37, Darrel Miller <darrel.miller@gmail.com> wrote:

> So here is another question.  Why are you allowed to put interaction
> semantics on your <form> tag (e.g. method=3D"get") but it is evil if I
> do the same on a <link> tag?  Is this because you feel only media
> types are allowed to define interaction details?

Yes, because in the case of a hypermedia response entity the control is =
embedded in the message (at runtime) - putting that information in the =
link relation is design time.

We want the client to be prepared for the runtime odds of decentralized =
systems.

Jan


From mca@amundsen.com  Thu Jan 16 00:09:17 2014
Return-Path: <mca@amundsen.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70FF71AE1A2 for <apps-discuss@ietfa.amsl.com>; Thu, 16 Jan 2014 00:09:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.155
X-Spam-Level: *
X-Spam-Status: No, score=1.155 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FM_FORGED_GMAIL=0.622, FORGED_YAHOO_RCVD=1.63, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, NML_ADSP_CUSTOM_MED=0.9, 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 RrgYbwmfbfVx for <apps-discuss@ietfa.amsl.com>; Thu, 16 Jan 2014 00:09:15 -0800 (PST)
Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by ietfa.amsl.com (Postfix) with ESMTP id E7B311AE180 for <apps-discuss@ietf.org>; Thu, 16 Jan 2014 00:09:14 -0800 (PST)
Received: by mail-wg0-f46.google.com with SMTP id x12so2761681wgg.25 for <apps-discuss@ietf.org>; Thu, 16 Jan 2014 00:09:02 -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:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-type; bh=A/7rhpIoPV3X3VOnA7p4j06KdOr3/zJ8/+rHxHDGctQ=; b=RMUyNaImthcYPYaqITzZ8TKgI6c+WUMAZnjuBJamYdujUaNSohSk31ZA1VAzFeMTHc eQZ2/lbTga3MMVcaBs6fjo/Z1JQSwvQkzXSuSlY+alvk+zgk8MfV2Df2rkXpbJJFcCdw HSs2lpFL0WS4k8aZClTHNEb57A6mmeGg2aryJMJvXPijWWQKtw8WFUofpTQ0gqYrGUM6 2Q5Scp9kPtFV0201X8ENuKu3/dmzz6d+BjzqjX9RQBj4zHcp9LTp5pIxLp8abtUL++C8 1lZ3mI9FLDbhxZFp916lzqlR59NHdSjMGxVF0hZ1Fup5dmALISKc2rI8JQo3QZcWMa7H P9kg==
X-Gm-Message-State: ALoCoQma6NLgWcUUz647TfXtH1Gq5Irkdl17V+1kjlxsVnAiahKCx80aCrLQMDROKtnbfM82APcI
X-Received: by 10.180.228.8 with SMTP id se8mr6523028wic.29.1389859742463; Thu, 16 Jan 2014 00:09:02 -0800 (PST)
MIME-Version: 1.0
Sender: mca@amundsen.com
Received: by 10.194.119.226 with HTTP; Thu, 16 Jan 2014 00:08:42 -0800 (PST)
In-Reply-To: <CAKioOqtvpx6YEkM8PaQaPkeEX64JNn560ybZFugfOQz-Q80-Ow@mail.gmail.com>
References: <20140115140544.27701.78043.idtracker@ietfa.amsl.com> <CAGuwm8V+cFGE4aYP4rsZtGQR3_NPBOxf_t_BRgfxQbbTvOJTVQ@mail.gmail.com> <F1F4C81D-5106-46B9-9A4C-B3C2F696A07F@nordsc.com> <CAGuwm8Vh_bAKW9Lo3qLy5Usb5atM52BQ3cm_4WGc0X1--3QvKA@mail.gmail.com> <05628088-5731-4BEB-BD79-7C83896279FF@nordsc.com> <CAPW_8m66V2YJeGMK3zN_qnKpph8ujnrA85585FFwLoBtfWvfXA@mail.gmail.com> <CAKioOqt4-7tOoN66zth2vatLUFBXRSRaG4973trpEQRMP9dyYQ@mail.gmail.com> <CAPW_8m7F8VFN1XXFkYYfVvTN2RNcOmGo3zEzjiq-bg-uWDpZ-w@mail.gmail.com> <CAKioOqtvpx6YEkM8PaQaPkeEX64JNn560ybZFugfOQz-Q80-Ow@mail.gmail.com>
From: mike amundsen <mamund@yahoo.com>
Date: Thu, 16 Jan 2014 03:08:42 -0500
X-Google-Sender-Auth: syWwAApd0a8G58fjDCuvNAdG5ik
Message-ID: <CAPW_8m5GZorXvJUW=EyB4X1w5mUi0rPMexuAk9WWXgKdpB7CrQ@mail.gmail.com>
To: Darrel Miller <darrel@tavis.ca>
Content-Type: multipart/alternative; boundary=001a1134db543cd24604f011f036
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] New Version Notification for draft-hamnaberg-publish-link-relation-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Jan 2014 08:09:17 -0000

--001a1134db543cd24604f011f036
Content-Type: text/plain; charset=ISO-8859-1

<snip>
Isn't content type a string?
</snip>
yes. content type is a string

<snip>
Don't we rely heavily on content type for conveying semantics?
</snip>
no. the content type *string* does not convey (carry) semantics. it is an
identifier of a message design. and  that message design can be used to
craft messages that can carry semantics.





mamund
+1.859.757.1449
skype: mca.amundsen
http://amundsen.com/blog/
http://twitter.com/mamund
https://github.com/mamund
http://linkedin.com/in/mamund


On Wed, Jan 15, 2014 at 5:44 PM, Darrel Miller <darrel.miller@gmail.com>wrote:

> Mike,
>
>
> On Wed, Jan 15, 2014 at 4:37 PM, mike amundsen <mamund@yahoo.com> wrote:
> > I'm not a fan of using a string as a network affordance ;) I know this is
> > not a universally held conviction. for example, HAL relies on this very
> > notion quite heavily.
>
> Isn't content type a string?  Don't we rely heavily on content type
> for conveying semantics?
>
>
> >
> > i assert the best way to use link relation values is as identifiers. The
> > registry let's use describe these values in a general way much the way a
> > language dictionary (e.g. English, French, etc.) does. The way in which
> the
> > words are used, their intent, implied meaning, etc. are often based on
> > immediate context ("you owe me a payment" vs. "there is were you go to
> make
> > payments") and so forth.
> >
>
> Ideally, all link relations would have no constraints on their
> interaction semantics.  However, to say that we should not attach
> interaction semantics to a link relation limits, our ability to use
> link relations to point to resources that do have limits on their
> interaction.  The OAuth2 spec has decided that retrieving a token is
> an unsafe operation.  It seems rather ridiculous to have a client that
> understands the meaning of the rel="oauth2-token" but has to guess at
> what HTTP method to use because we don't want to write that constraint
> in the spec.  Sure, we could add link hints to suggest to the client
> that probably POST is the right method and add accept-post to tell it
> the media type and href vars to tell it the parameters.  Or we could
> just document it in the link relation spec and when it has breaking
> changes create an oauth3-token.
> If we don't convey to the client the details of the OAuth dance via
> links and link relations, then how can the client possibly do OAuth
> authentication without out of band knowledge.  There is no HTTP header
> to say "let's do the OAuth dance".
>
>
> > To your last point, I think tying operational semantics to a link
> relation
> > is over-constraining and limits it's use over time. Esp. when the
> > operational semantics are tied to a single protocol or format. I prefer
> to
> > keep usage details separate from the registry of unique values.
> >
>
> Yes, tying operational semantics to a link relation is constraining
> its usage.  But I think the practical value to be gained by lowering
> the idealism bar far outweighs the negatives effects of link relations
> with limited applicability.
>
> Don't you remember the time before C+J and HAL and JSON-LD and
> JSON-API and Siren when we were being told, there is no need to create
> more media types.  I believe the upsurge in the adoption of hypermedia
> is due in no small part to the creation of these imperfect hypermedia
> types.
>
> Most of the hypermedia I see these days are using extension link
> relations. That's because people can't see how they can use standard
> link relations in their domains.  We need to loosen the reins and let
> some imperfection seep into the link relations.   Having every
> developer create their own extension link relations is just as bad as
> the "media type explosion" that was feared.
>
> Darrel
>

--001a1134db543cd24604f011f036
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">&lt;snip&gt;<div><span style=3D"font-family:arial,sans-ser=
if;font-size:13px">Isn&#39;t content type a string?</span></div><div><font =
face=3D"arial, sans-serif">&lt;/snip&gt;</font></div><div><span style=3D"fo=
nt-family:arial,sans-serif;font-size:13px">yes. content type is a string</s=
pan></div>

<div><span style=3D"font-family:arial,sans-serif;font-size:13px"><br></span=
></div><div><span style=3D"font-family:arial,sans-serif;font-size:13px">&lt=
;snip&gt;</span></div><div><span style=3D"font-family:arial,sans-serif;font=
-size:13px">Don&#39;t we rely heavily on content type=A0</span><span style=
=3D"font-family:arial,sans-serif;font-size:13px">for conveying semantics?</=
span><br>

</div><div><span style=3D"font-family:arial,sans-serif;font-size:13px">&lt;=
/snip&gt;</span></div><div><span style=3D"font-family:arial,sans-serif;font=
-size:13px">no. the co</span><span style=3D"font-family:arial,sans-serif;fo=
nt-size:13px">ntent type *string* does not convey (carry) semantics. it is =
an identifier of a message design. and =A0that message design can be used t=
o craft messages that can carry semantics.</span></div>

<div>=A0<br></div><div><br></div><div><span style=3D"font-family:arial,sans=
-serif;font-size:13px"><br></span></div></div><div class=3D"gmail_extra"><b=
r clear=3D"all"><div><div dir=3D"ltr"><div><br></div>mamund<div><span><span=
 title=3D"Call with Google Voice"><span title=3D"Call with Google Voice">+1=
.859.757.1449</span></span></span><br>

skype: mca.amundsen<br><a href=3D"http://amundsen.com/blog/" target=3D"_bla=
nk">http://amundsen.com/blog/</a><br><a href=3D"http://twitter.com/mamund" =
target=3D"_blank">http://twitter.com/mamund</a><br><a href=3D"https://githu=
b.com/mamund" target=3D"_blank">https://github.com/mamund</a><br>

<a href=3D"http://linkedin.com/in/mamund" target=3D"_blank">http://linkedin=
.com/in/mamund</a></div></div></div>
<br><br><div class=3D"gmail_quote">On Wed, Jan 15, 2014 at 5:44 PM, Darrel =
Miller <span dir=3D"ltr">&lt;<a href=3D"mailto:darrel.miller@gmail.com" tar=
get=3D"_blank">darrel.miller@gmail.com</a>&gt;</span> wrote:<br><blockquote=
 class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex">

Mike,<br>
<div class=3D"im"><br>
<br>
On Wed, Jan 15, 2014 at 4:37 PM, mike amundsen &lt;<a href=3D"mailto:mamund=
@yahoo.com">mamund@yahoo.com</a>&gt; wrote:<br>
&gt; I&#39;m not a fan of using a string as a network affordance ;) I know =
this is<br>
&gt; not a universally held conviction. for example, HAL relies on this ver=
y<br>
&gt; notion quite heavily.<br>
<br>
</div>Isn&#39;t content type a string? =A0Don&#39;t we rely heavily on cont=
ent type<br>
for conveying semantics?<br>
<div class=3D"im"><br>
<br>
&gt;<br>
&gt; i assert the best way to use link relation values is as identifiers. T=
he<br>
&gt; registry let&#39;s use describe these values in a general way much the=
 way a<br>
&gt; language dictionary (e.g. English, French, etc.) does. The way in whic=
h the<br>
&gt; words are used, their intent, implied meaning, etc. are often based on=
<br>
&gt; immediate context (&quot;you owe me a payment&quot; vs. &quot;there is=
 were you go to make<br>
&gt; payments&quot;) and so forth.<br>
&gt;<br>
<br>
</div>Ideally, all link relations would have no constraints on their<br>
interaction semantics. =A0However, to say that we should not attach<br>
interaction semantics to a link relation limits, our ability to use<br>
link relations to point to resources that do have limits on their<br>
interaction. =A0The OAuth2 spec has decided that retrieving a token is<br>
an unsafe operation. =A0It seems rather ridiculous to have a client that<br=
>
understands the meaning of the rel=3D&quot;oauth2-token&quot; but has to gu=
ess at<br>
what HTTP method to use because we don&#39;t want to write that constraint<=
br>
in the spec. =A0Sure, we could add link hints to suggest to the client<br>
that probably POST is the right method and add accept-post to tell it<br>
the media type and href vars to tell it the parameters. =A0Or we could<br>
just document it in the link relation spec and when it has breaking<br>
changes create an oauth3-token.<br>
If we don&#39;t convey to the client the details of the OAuth dance via<br>
links and link relations, then how can the client possibly do OAuth<br>
authentication without out of band knowledge. =A0There is no HTTP header<br=
>
to say &quot;let&#39;s do the OAuth dance&quot;.<br>
<div class=3D"im"><br>
<br>
&gt; To your last point, I think tying operational semantics to a link rela=
tion<br>
&gt; is over-constraining and limits it&#39;s use over time. Esp. when the<=
br>
&gt; operational semantics are tied to a single protocol or format. I prefe=
r to<br>
&gt; keep usage details separate from the registry of unique values.<br>
&gt;<br>
<br>
</div>Yes, tying operational semantics to a link relation is constraining<b=
r>
its usage. =A0But I think the practical value to be gained by lowering<br>
the idealism bar far outweighs the negatives effects of link relations<br>
with limited applicability.<br>
<br>
Don&#39;t you remember the time before C+J and HAL and JSON-LD and<br>
JSON-API and Siren when we were being told, there is no need to create<br>
more media types. =A0I believe the upsurge in the adoption of hypermedia<br=
>
is due in no small part to the creation of these imperfect hypermedia<br>
types.<br>
<br>
Most of the hypermedia I see these days are using extension link<br>
relations. That&#39;s because people can&#39;t see how they can use standar=
d<br>
link relations in their domains. =A0We need to loosen the reins and let<br>
some imperfection seep into the link relations. =A0 Having every<br>
developer create their own extension link relations is just as bad as<br>
the &quot;media type explosion&quot; that was feared.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Darrel<br>
</font></span></blockquote></div><br></div>

--001a1134db543cd24604f011f036--

From dret@berkeley.edu  Thu Jan 16 00:16:54 2014
Return-Path: <dret@berkeley.edu>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D96B1AD8E3 for <apps-discuss@ietfa.amsl.com>; Thu, 16 Jan 2014 00:16:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.738
X-Spam-Level: 
X-Spam-Status: No, score=-4.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0yFhtF95-CcN for <apps-discuss@ietfa.amsl.com>; Thu, 16 Jan 2014 00:16:53 -0800 (PST)
Received: from cm06fe.IST.Berkeley.EDU (cm06fe.IST.Berkeley.EDU [169.229.218.147]) by ietfa.amsl.com (Postfix) with ESMTP id 3C2501AD6A4 for <apps-discuss@ietf.org>; Thu, 16 Jan 2014 00:16:53 -0800 (PST)
Received: from 46-126-158-51.dynamic.hispeed.ch ([46.126.158.51] helo=dretpro.local) by cm06fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from <dret@berkeley.edu>) id 1W3i7z-00052Z-JM; Thu, 16 Jan 2014 00:16:40 -0800
Message-ID: <52D79563.4080601@berkeley.edu>
Date: Thu, 16 Jan 2014 09:16:35 +0100
From: Erik Wilde <dret@berkeley.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Jan Algermissen <jan.algermissen@nordsc.com>, darrel@tavis.ca
References: <20140115140544.27701.78043.idtracker@ietfa.amsl.com> <CAGuwm8V+cFGE4aYP4rsZtGQR3_NPBOxf_t_BRgfxQbbTvOJTVQ@mail.gmail.com> <F1F4C81D-5106-46B9-9A4C-B3C2F696A07F@nordsc.com> <CAGuwm8Vh_bAKW9Lo3qLy5Usb5atM52BQ3cm_4WGc0X1--3QvKA@mail.gmail.com> <05628088-5731-4BEB-BD79-7C83896279FF@nordsc.com> <CAPW_8m66V2YJeGMK3zN_qnKpph8ujnrA85585FFwLoBtfWvfXA@mail.gmail.com> <CAKioOqt4-7tOoN66zth2vatLUFBXRSRaG4973trpEQRMP9dyYQ@mail.gmail.com> <4ACFE05D-D204-4363-9A8B-AAC7F0695D66@nordsc.com>
In-Reply-To: <4ACFE05D-D204-4363-9A8B-AAC7F0695D66@nordsc.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] New Version Notification for draft-hamnaberg-publish-link-relation-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Jan 2014 08:16:54 -0000

hello jan.

On 2014-01-15, 22:35 , Jan Algermissen wrote:
> The rel conveys information about the nature of a target resource. This helps the client to form an expection about the resource and interact with it if it is programmed to do so. Maybe the resource does not even support a POST.

a link relation should convey information about how the target is 
related to the source in the given link context, specifically *not* 
information just about the target resource itself. link relations that 
try to define *what* to expect as the target are not all that great; 
instead, they should define *why* a client might want to follow the 
link, and how to do that, given the link context.

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 jan.algermissen@nordsc.com  Thu Jan 16 00:37:49 2014
Return-Path: <jan.algermissen@nordsc.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8551AE04C for <apps-discuss@ietfa.amsl.com>; Thu, 16 Jan 2014 00:37:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level: 
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 onmZ3tYPAFQQ for <apps-discuss@ietfa.amsl.com>; Thu, 16 Jan 2014 00:37:48 -0800 (PST)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by ietfa.amsl.com (Postfix) with ESMTP id 8F93A1ADEA7 for <apps-discuss@ietf.org>; Thu, 16 Jan 2014 00:37:47 -0800 (PST)
Received: from [172.20.10.5] (tmo-108-12.customers.d1-online.com [80.187.108.12]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0M689C-1VA4bG2AmY-00xTw2; Thu, 16 Jan 2014 09:37:34 +0100
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jan Algermissen <jan.algermissen@nordsc.com>
In-Reply-To: <52D79563.4080601@berkeley.edu>
Date: Thu, 16 Jan 2014 09:37:31 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <E8819E18-0994-4748-ABCC-0BE8BAC6DED6@nordsc.com>
References: <20140115140544.27701.78043.idtracker@ietfa.amsl.com> <CAGuwm8V+cFGE4aYP4rsZtGQR3_NPBOxf_t_BRgfxQbbTvOJTVQ@mail.gmail.com> <F1F4C81D-5106-46B9-9A4C-B3C2F696A07F@nordsc.com> <CAGuwm8Vh_bAKW9Lo3qLy5Usb5atM52BQ3cm_4WGc0X1--3QvKA@mail.gmail.com> <05628088-5731-4BEB-BD79-7C83896279FF@nordsc.com> <CAPW_8m66V2YJeGMK3zN_qnKpph8ujnrA85585FFwLoBtfWvfXA@mail.gmail.com> <CAKioOqt4-7tOoN66zth2vatLUFBXRSRaG4973trpEQRMP9dyYQ@mail.gmail.com> <4ACFE05D-D204-4363-9A8B-AAC7F0695D66@nordsc.com> <52D79563.4080601@berkeley.edu>
To: Erik Wilde <dret@berkeley.edu>
X-Mailer: Apple Mail (2.1510)
X-Provags-ID: V02:K0:6PgOST6VWVK4fsbkjwaZiSIKDr28uUaDRNjMb2INp55 XLRzNGOLgxBIejELsZyOQ8ekDoou1/MD7FPZGUFw7WWcdaXfjP j9paGehh1r6vb9FfNh7WusjUoON1LrTpOV2hi8n59Y/uXrURwS DYxbLPaeudL08GVvbUHzl8JPNU5kVBh9Owi4fgFN5JEg8f/ldz BjNnck1Z8jC/5tHy20X92HZ7vQY7gEtcOlgwB4RaOc5TfoeNqY mxz9tu7LdsQQY39WxFXyUJKfS31aDNr0dO9zn1o/UmfQl+Tu5d WGGwj373nFMfd9rikV4wPFEoho2/qlX6iVIMKzEStuwf0fF4+8 lWv729nc+MjzcP5Q4hNXqKIn+VJ4rgLIOD4aotq6/oXOPc7WgB UfljKLVeDn9Nw==
Cc: darrel@tavis.ca, IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] New Version Notification for draft-hamnaberg-publish-link-relation-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Jan 2014 08:37:49 -0000

On 16.01.2014, at 09:16, Erik Wilde <dret@berkeley.edu> wrote:

> hello jan.
>=20
> On 2014-01-15, 22:35 , Jan Algermissen wrote:
>> The rel conveys information about the nature of a target resource. =
This helps the client to form an expection about the resource and =
interact with it if it is programmed to do so. Maybe the resource does =
not even support a POST.
>=20
> a link relation should convey information about how the target is =
related to the source in the given link context, specifically *not* =
information just about the target resource itself. link relations that =
try to define *what* to expect as the target are not all that great; =
instead, they should define *why* a client might want to follow the =
link, and how to do that, given the link context.

Hmm, in my world it is exactly the opposite.=20

Link rel says "what", client knows "why" (aka "intent") and how is a =
runtime/introspection time issue.

A link rel spec has no business saying "why" because it cannot know the =
application a client will be stepping through at any given time.

Jan


>=20
> cheers,
>=20
> dret.
>=20
> --=20
> 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 dret@berkeley.edu  Thu Jan 16 01:13:26 2014
Return-Path: <dret@berkeley.edu>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F008A1ADFF4 for <apps-discuss@ietfa.amsl.com>; Thu, 16 Jan 2014 01:13:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.738
X-Spam-Level: 
X-Spam-Status: No, score=-4.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yTimMOmaXFao for <apps-discuss@ietfa.amsl.com>; Thu, 16 Jan 2014 01:13:24 -0800 (PST)
Received: from cm04fe.IST.Berkeley.EDU (cm04fe.IST.Berkeley.EDU [169.229.218.145]) by ietfa.amsl.com (Postfix) with ESMTP id 29F8D1ACCF6 for <apps-discuss@ietf.org>; Thu, 16 Jan 2014 01:13:24 -0800 (PST)
Received: from 46-126-158-51.dynamic.hispeed.ch ([46.126.158.51] helo=dretpro.local) by cm04fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from <dret@berkeley.edu>) id 1W3j0e-0005Lp-Fl; Thu, 16 Jan 2014 01:13:10 -0800
Message-ID: <52D7A2A0.5040806@berkeley.edu>
Date: Thu, 16 Jan 2014 10:13:04 +0100
From: Erik Wilde <dret@berkeley.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Jan Algermissen <jan.algermissen@nordsc.com>
References: <20140115140544.27701.78043.idtracker@ietfa.amsl.com> <CAGuwm8V+cFGE4aYP4rsZtGQR3_NPBOxf_t_BRgfxQbbTvOJTVQ@mail.gmail.com> <F1F4C81D-5106-46B9-9A4C-B3C2F696A07F@nordsc.com> <CAGuwm8Vh_bAKW9Lo3qLy5Usb5atM52BQ3cm_4WGc0X1--3QvKA@mail.gmail.com> <05628088-5731-4BEB-BD79-7C83896279FF@nordsc.com> <CAPW_8m66V2YJeGMK3zN_qnKpph8ujnrA85585FFwLoBtfWvfXA@mail.gmail.com> <CAKioOqt4-7tOoN66zth2vatLUFBXRSRaG4973trpEQRMP9dyYQ@mail.gmail.com> <4ACFE05D-D204-4363-9A8B-AAC7F0695D66@nordsc.com> <52D79563.4080601@berkeley.edu> <E8819E18-0994-4748-ABCC-0BE8BAC6DED6@nordsc.com>
In-Reply-To: <E8819E18-0994-4748-ABCC-0BE8BAC6DED6@nordsc.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: darrel@tavis.ca, IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] New Version Notification for draft-hamnaberg-publish-link-relation-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Jan 2014 09:13:27 -0000

hello jan.

On 2014-01-16, 9:37 , Jan Algermissen wrote:
> On 16.01.2014, at 09:16, Erik Wilde <dret@berkeley.edu> wrote:
>> a link relation should convey information about how the target is related to the source in the given link context, specifically *not* information just about the target resource itself. link relations that try to define *what* to expect as the target are not all that great; instead, they should define *why* a client might want to follow the link, and how to do that, given the link context.
> Hmm, in my world it is exactly the opposite.
> Link rel says "what", client knows "why" (aka "intent") and how is a runtime/introspection time issue.

let's say i have an image i want to link to. this may be an image for 
displaying inline, or it may be a page's favicon that goes into browser 
tabs/controls. it may even play both roles. what determines its *role* 
is how it's linked: from an <img> element (equivalent to a "embedded 
image role"), or from <link rel="icon"/>, and if i link it in both ways, 
it plays both roles. *what* it is (PNG, ICO) is not known, and the 
client will have to GET it to see whether it can handle it.

> A link rel spec has no business saying "why" because it cannot know the application a client will be stepping through at any given time.

the *why* allows the client to decide "am i interested in inline images" 
and "am i interested in icon images", and *if* the client is interested 
in them, it will follow the respective links. the containing resource 
types the link and puts it into context, and the client decides whether 
it wants to follow that link, based on its application goal.

it would be bad if the link relation just said "here's some image". and 
notice that neither <img> nor <link rel="icon"/> constrain the target 
resource nor its URI scheme in any way; it's up to the client to decide 
based on the *why* that it wants to engage with the linked resource, and 
then its URI (plus potentially some context of the link, such as a 
<form>'s method attribute) will determine how that interaction looks 
like. that interaction will eventually reveal what you called "the 
nature of the resource", but that's entirely a runtime mechanism and not 
represented by the link relation at all.

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 erlend@hamnaberg.net  Thu Jan 16 02:08:33 2014
Return-Path: <erlend@hamnaberg.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6392A1AE2FB for <apps-discuss@ietfa.amsl.com>; Thu, 16 Jan 2014 02:08:33 -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 o6jaLAzY7zfR for <apps-discuss@ietfa.amsl.com>; Thu, 16 Jan 2014 02:08:26 -0800 (PST)
Received: from mail-ob0-f169.google.com (mail-ob0-f169.google.com [209.85.214.169]) by ietfa.amsl.com (Postfix) with ESMTP id BD3081AE1F5 for <apps-discuss@ietf.org>; Thu, 16 Jan 2014 02:08:26 -0800 (PST)
Received: by mail-ob0-f169.google.com with SMTP id wp4so2554480obc.0 for <apps-discuss@ietf.org>; Thu, 16 Jan 2014 02:08:14 -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=ylmZX+npvR35cn7JzPPhDPMZQMUMH+VlIMi26UQRf/0=; b=U9YzFP9rfue7Bbl/oN+O6+4kVEzwr5uWaQOgVEStP60qGsQIU1sFTSfUP3QkXRr1av FQz4ZVC8KHohf2UinGAMByz15F+vznKZ5MtkIQ8dvxXdIWvP0tPcvS0reLPyYnd+DxgX C2Bx6xiP5lMcUNJk4W8+eJ2AOP3g8pOSmJBugKYQDSlZxRQ7CRbH/o/6Me5b4Oedc3Xc ZmhROCl1XEezdMWlGtKpp3JhT/4KUfY9j2HXXOc87jWSKR3aHJlDGy+6Ix1yKrA0rAOh jRIKzq40ehy0K5y2O7/yfbyJLyerk4FNatmjPDuTemM0gz+e6Y1MQfWcrRTc8Mjg3weW yK5w==
X-Gm-Message-State: ALoCoQmpGUVLuLbCBscwRQsP9I4MuKBBKBuB8hL2wXjUuuT9i5vgnKpYOY0jlA0/4ZlQrg1hyIiu
MIME-Version: 1.0
X-Received: by 10.60.123.10 with SMTP id lw10mr4335480oeb.24.1389866894277; Thu, 16 Jan 2014 02:08:14 -0800 (PST)
Received: by 10.182.160.98 with HTTP; Thu, 16 Jan 2014 02:08:14 -0800 (PST)
X-Originating-IP: [80.203.95.228]
In-Reply-To: <05628088-5731-4BEB-BD79-7C83896279FF@nordsc.com>
References: <20140115140544.27701.78043.idtracker@ietfa.amsl.com> <CAGuwm8V+cFGE4aYP4rsZtGQR3_NPBOxf_t_BRgfxQbbTvOJTVQ@mail.gmail.com> <F1F4C81D-5106-46B9-9A4C-B3C2F696A07F@nordsc.com> <CAGuwm8Vh_bAKW9Lo3qLy5Usb5atM52BQ3cm_4WGc0X1--3QvKA@mail.gmail.com> <05628088-5731-4BEB-BD79-7C83896279FF@nordsc.com>
Date: Thu, 16 Jan 2014 11:08:14 +0100
Message-ID: <CAGuwm8U0oO9p-FMC+8PzZX6CTbzdz3C2ec=AQoN7aaBQmzogiA@mail.gmail.com>
From: Erlend Hamnaberg <erlend@hamnaberg.net>
To: Jan Algermissen <jan.algermissen@nordsc.com>
Content-Type: multipart/alternative; boundary=047d7b5d49ce84d60704f0139a33
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] New Version Notification for draft-hamnaberg-publish-link-relation-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Jan 2014 10:08:33 -0000

--047d7b5d49ce84d60704f0139a33
Content-Type: text/plain; charset=ISO-8859-1

Jan,

Trying to bring the disussion back to the topic.


On Wed, Jan 15, 2014 at 5:45 PM, Jan Algermissen <jan.algermissen@nordsc.com
> wrote:

>
> On 15.01.2014, at 16:59, Erlend Hamnaberg <erlend@hamnaberg.net> wrote:
>
> >
> > My use case has been a schedule for a conference.
> >
> > The program is built over time, but once it is done, I want to publish
> it.
>
> If publishing is done by the same server, I'd change a property of the
> program to tell the server that it should publish.
>

Which property is that?


>
> When on a nother server, I'd try to POST the program's representation,
> implicitly creating a new publishing job. That job will have a URI which I
> would use to observer the state of the job.
>
> Having "publish" point to the publishing system might make sense, in that
> sense "publish" would identoty a "resource providing publishing services".
>

Sure. that is one valid use case.

>
> I'd ovoid to POST the URI to the publishing service if possible, because
> it reduces simpicity IMHO, because the publishing system will need to go
> and GET the resuorec to be published which feels unnatural to me.
>

Well, A lot of the services I build are usually proxies to other HTTP based
services. Since this may already be the case, the publishing system can in
its own time determine when it wants to publish each resource.
Either by POSTIng the program as you suggest, or letting the publishing
service get each and figure out how to do that. I see no problem with
either option.

>
> How does that resonate with you?
>
> Jan
>
>

Erlend

--047d7b5d49ce84d60704f0139a33
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Jan,<div><br></div><div>Trying to bring the disussion back=
 to the topic.<br><div class=3D"gmail_extra"><br><br><div class=3D"gmail_qu=
ote">On Wed, Jan 15, 2014 at 5:45 PM, Jan Algermissen <span dir=3D"ltr">&lt=
;<a href=3D"mailto:jan.algermissen@nordsc.com" target=3D"_blank">jan.algerm=
issen@nordsc.com</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div><br>
On 15.01.2014, at 16:59, Erlend Hamnaberg &lt;<a href=3D"mailto:erlend@hamn=
aberg.net" target=3D"_blank">erlend@hamnaberg.net</a>&gt; wrote:<br>
<br>
&gt;<br>
&gt; My use case has been a schedule for a conference.<br>
&gt;<br>
&gt; The program is built over time, but once it is done, I want to publish=
 it.<br>
<br>
</div>If publishing is done by the same server, I&#39;d change a property o=
f the program to tell the server that it should publish.<br></blockquote><d=
iv><br></div><div>Which property is that?</div><div>=A0</div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex">


<br>
When on a nother server, I&#39;d try to POST the program&#39;s representati=
on, implicitly creating a new publishing job. That job will have a URI whic=
h I would use to observer the state of the job.<br>
<br>
Having &quot;publish&quot; point to the publishing system might make sense,=
 in that sense &quot;publish&quot; would identoty a &quot;resource providin=
g publishing services&quot;.<br></blockquote><div><br></div><div>Sure. that=
 is one valid use case.=A0</div>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<br>
I&#39;d ovoid to POST the URI to the publishing service if possible, becaus=
e it reduces simpicity IMHO, because the publishing system will need to go =
and GET the resuorec to be published which feels unnatural to me.<br></bloc=
kquote>

<div><br></div><div>Well, A lot of the services I build are usually proxies=
 to other HTTP based services. Since this may already be the case, the publ=
ishing system can in its own time determine when it wants to publish each r=
esource.</div>
<div>Either by POSTIng the program as you suggest, or letting the publishin=
g service get each and figure out how to do that. I see no problem with eit=
her option.</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
How does that resonate with you?<br>
<span><font color=3D"#888888"><br>
Jan<br>
</font></span><div><div><br></div></div></blockquote><div><br></div><div><b=
r></div><div>Erlend=A0</div></div></div></div></div>

--047d7b5d49ce84d60704f0139a33--

From GK@ninebynine.org  Thu Jan 16 03:46:22 2014
Return-Path: <GK@ninebynine.org>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85F051AE2FD for <apps-discuss@ietfa.amsl.com>; Thu, 16 Jan 2014 03:46:22 -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_37=0.6, J_CHICKENPOX_38=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 r6x-gRTbkgp2 for <apps-discuss@ietfa.amsl.com>; Thu, 16 Jan 2014 03:46:20 -0800 (PST)
Received: from relay15.mail.ox.ac.uk (relay15.mail.ox.ac.uk [163.1.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id 2E93B1AE2A7 for <apps-discuss@ietf.org>; Thu, 16 Jan 2014 03:46:20 -0800 (PST)
Received: from smtp2.mail.ox.ac.uk ([163.1.2.205]) by relay15.mail.ox.ac.uk with esmtp (Exim 4.80) (envelope-from <GK@ninebynine.org>) id 1W3lOe-0000An-ny; Thu, 16 Jan 2014 11:46:04 +0000
Received: from gklyne.plus.com ([80.229.154.156] helo=conina.local) by smtp2.mail.ox.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <GK@ninebynine.org>) id 1W3lOe-0003fU-6Z; Thu, 16 Jan 2014 11:46:04 +0000
Message-ID: <52D7B601.1010100@ninebynine.org>
Date: Thu, 16 Jan 2014 10:35:45 +0000
From: Graham Klyne <GK@ninebynine.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: mike amundsen <mamund@yahoo.com>
References: <20140115140544.27701.78043.idtracker@ietfa.amsl.com> <CAGuwm8V+cFGE4aYP4rsZtGQR3_NPBOxf_t_BRgfxQbbTvOJTVQ@mail.gmail.com> <F1F4C81D-5106-46B9-9A4C-B3C2F696A07F@nordsc.com> <CAGuwm8Vh_bAKW9Lo3qLy5Usb5atM52BQ3cm_4WGc0X1--3QvKA@mail.gmail.com> <05628088-5731-4BEB-BD79-7C83896279FF@nordsc.com> <CAPW_8m66V2YJeGMK3zN_qnKpph8ujnrA85585FFwLoBtfWvfXA@mail.gmail.com> <CAKioOqt4-7tOoN66zth2vatLUFBXRSRaG4973trpEQRMP9dyYQ@mail.gmail.com> <CAPW_8m7F8VFN1XXFkYYfVvTN2RNcOmGo3zEzjiq-bg-uWDpZ-w@mail.gmail.com>
In-Reply-To: <CAPW_8m7F8VFN1XXFkYYfVvTN2RNcOmGo3zEzjiq-bg-uWDpZ-w@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Oxford-Username: zool0635
Cc: Darrel Miller <darrel@tavis.ca>, IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] New Version Notification for draft-hamnaberg-publish-link-relation-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Jan 2014 11:46:22 -0000

[Slightly off-topic...]

Mike,

Accepting that the operational details be separate from the link relation 
semantics...

In your (REST-informed?) view, where the link relation occurs within some 
retrieved representation, would be be reasonable for the representation to 
*also* indicate the operations that might be applicable?  (Somewhat like HTML 
<form> @method, maybe.)

For example, to abuse an example from Darrel's draft [1]:

        <link rel="self" type="application/atom+xml"
            href="http://example.org/feed"/>
        <link rel="publish"
          href="http://example.org/publish"/
          method="POST" post_types="text/uri-list" />

("method" and "post-types" here are pure invention for the purpose of discussion.)

So in this context, a client can move straight to the publication step, which I 
think is Darrel's goal with the operational discussion in the link relation.  In 
a different context, a client might have to perform a GET (or equivalent) to the 
linked resource to discover its affordances.

#g
--

[1] http://www.ietf.org/id/draft-hamnaberg-publish-link-relation-00.txt

On 15/01/2014 21:37, mike amundsen wrote:
> I'm not a fan of using a string as a network affordance ;) I know this is
> not a universally held conviction. for example, HAL relies on this very
> notion quite heavily.
>
> i assert the best way to use link relation values is as identifiers. The
> registry let's use describe these values in a general way much the way a
>   language dictionary (e.g. English, French, etc.) does. The way in which
> the words are used, their intent, implied meaning, etc. are often based on
> immediate context ("you owe me a payment" vs. "there is were you go to make
> payments") and so forth.
>
> To your last point, I think tying operational semantics to a link relation
> is over-constraining and limits it's use over time. Esp. when the
> operational semantics are tied to a single protocol or format. I prefer to
> keep usage details separate from the registry of unique values.
>
>
>
>
>
> mamund
> +1.859.757.1449
> skype: mca.amundsen
> http://amundsen.com/blog/
> http://twitter.com/mamund
> https://github.com/mamund
> http://linkedin.com/in/mamund
>
>
> On Wed, Jan 15, 2014 at 3:58 PM, Darrel Miller <darrel.miller@gmail.com>wrote:
>
>> Mike,
>>
>> How do you feel about a link relation that says, if you do POST, it
>> means this ...
>>
>> If that concerns you then do you have suggestions on how the these
>> link relations should work:
>>
>> rel=payment        https://web-payments.org/specs/source/payment-links/
>> rel=hub
>> https://pubsubhubbub.googlecode.com/git/pubsubhubbub-core-0.4.html
>> rel=oauth2-token
>> http://tools.ietf.org/html/draft-wmills-oauth-lrdd-07#page-8
>>
>> As far as I understand it, all of these have an associated meaning to
>> a POST request.  Curiously, that meaning is not described in the rel
>> relation registration, but in the specification that describes the
>> protocol that uses the link relation.  This separation concerns me
>> because we could end up with a situation where different protocols
>> assign different interaction semantics to the same link relation.
>>
>> Darrel
>>
>>
>>
>> On Wed, Jan 15, 2014 at 1:05 PM, mike amundsen <mamund@yahoo.com> wrote:
>>> My advice is to *not* attempt to constrain how the client or server
>> behaves
>>> when using the link relation (e.g. "client SHOULD use POST to ....",
>> etc.).
>>>
>>> Instead just define the link relation's meaning and let clients and
>> servers
>>> use that shared meaning to do whatever they want with it.
>>>
>>>
>>>
>>>
>>> mamund
>>> +1.859.757.1449
>>> skype: mca.amundsen
>>> http://amundsen.com/blog/
>>> http://twitter.com/mamund
>>> https://github.com/mamund
>>> http://linkedin.com/in/mamund
>>>
>>>
>>> On Wed, Jan 15, 2014 at 11:45 AM, Jan Algermissen
>>> <jan.algermissen@nordsc.com> wrote:
>>>>
>>>>
>>>> On 15.01.2014, at 16:59, Erlend Hamnaberg <erlend@hamnaberg.net> wrote:
>>>>
>>>>>
>>>>> My use case has been a schedule for a conference.
>>>>>
>>>>> The program is built over time, but once it is done, I want to publish
>>>>> it.
>>>>
>>>> If publishing is done by the same server, I'd change a property of the
>>>> program to tell the server that it should publish.
>>>>
>>>> When on a nother server, I'd try to POST the program's representation,
>>>> implicitly creating a new publishing job. That job will have a URI
>> which I
>>>> would use to observer the state of the job.
>>>>
>>>> Having "publish" point to the publishing system might make sense, in
>> that
>>>> sense "publish" would identoty a "resource providing publishing
>> services".
>>>>
>>>> I'd ovoid to POST the URI to the publishing service if possible, because
>>>> it reduces simpicity IMHO, because the publishing system will need to
>> go and
>>>> GET the resuorec to be published which feels unnatural to me.
>>>>
>>>> How does that resonate with you?
>>>>
>>>> Jan
>>>>
>>>>>
>>>>> I could, of course, go through each session and publish it directly.
>>>>> Each publishing step is then a state change for each session.
>>>>> However, for a user interface can become cumbersome.
>>>>>
>>>>> However, If I decide to model this as two separate URIs,
>>>>> I may need a different mechanism.
>>>>>
>>>>> Not sure I am able to explain this appropriately.
>>>>>
>>>>> Erlend
>>>>
>>>> _______________________________________________
>>>> 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
>>
>
>
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

From jan.algermissen@nordsc.com  Thu Jan 16 04:29:58 2014
Return-Path: <jan.algermissen@nordsc.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC5D21AE330 for <apps-discuss@ietfa.amsl.com>; Thu, 16 Jan 2014 04:29:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.351
X-Spam-Level: 
X-Spam-Status: No, score=-0.351 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_37=0.6, J_CHICKENPOX_38=0.6, 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 n_5k_EyYbeaG for <apps-discuss@ietfa.amsl.com>; Thu, 16 Jan 2014 04:29:55 -0800 (PST)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by ietfa.amsl.com (Postfix) with ESMTP id E39681AE32B for <apps-discuss@ietf.org>; Thu, 16 Jan 2014 04:29:54 -0800 (PST)
Received: from [172.20.10.5] (tmo-108-12.customers.d1-online.com [80.187.108.12]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0MN912-1W1Z9Y1IO8-007Msm; Thu, 16 Jan 2014 13:29:32 +0100
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jan Algermissen <jan.algermissen@nordsc.com>
In-Reply-To: <52D7B601.1010100@ninebynine.org>
Date: Thu, 16 Jan 2014 13:29:31 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <6A337E1E-895B-44A4-AC09-E5E103ED8913@nordsc.com>
References: <20140115140544.27701.78043.idtracker@ietfa.amsl.com> <CAGuwm8V+cFGE4aYP4rsZtGQR3_NPBOxf_t_BRgfxQbbTvOJTVQ@mail.gmail.com> <F1F4C81D-5106-46B9-9A4C-B3C2F696A07F@nordsc.com> <CAGuwm8Vh_bAKW9Lo3qLy5Usb5atM52BQ3cm_4WGc0X1--3QvKA@mail.gmail.com> <05628088-5731-4BEB-BD79-7C83896279FF@nordsc.com> <CAPW_8m66V2YJeGMK3zN_qnKpph8ujnrA85585FFwLoBtfWvfXA@mail.gmail.com> <CAKioOqt4-7tOoN66zth2vatLUFBXRSRaG4973trpEQRMP9dyYQ@mail.gmail.com> <CAPW_8m7F8VFN1XXFkYYfVvTN2RNcOmGo3zEzjiq-bg-uWDpZ-w@mail.gmail.com> <52D7B601.1010100@ninebynine.org>
To: Graham Klyne <GK@ninebynine.org>
X-Mailer: Apple Mail (2.1510)
X-Provags-ID: V02:K0:3EVuiVoEs5Vxu54qRAP/WujXN0XpesVCrboyGGskkqJ sF/JWUklOPnB8yUOfhWxYcsS72wSg7bpj3kB8ZEu75WjABQG9o Cm5NHWD+BQlcCvLpC+L6zubRjDkoHCHmq/devVNhrG5nmnGmgA CHRtvs5bShANfn0dh7OvDDfj749Pa6H9kClnDIIdfm4oQit96k 3ZUN3nK283R7FBZ4hWahtnsapWjP1IlZ/G20BMgUNWJk7BQmtw g/0SuiyebrMxiXb1DpLXXo8gybUlc0PsgqYfTi4fMSYBOavMvi EZ3z59ZTaXdpap/RddEMaut+OV1l+Nt4lpnIYm5H5wOEutKvmf YuIinmwFLS/a+/1akYOfYG7n/OCghEYjJhmAN+kemMDKNc11Ok IGR+V6+/mtvdg==
Cc: Darrel Miller <darrel@tavis.ca>, IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] New Version Notification for draft-hamnaberg-publish-link-relation-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Jan 2014 12:29:58 -0000

On 16.01.2014, at 11:35, Graham Klyne <GK@ninebynine.org> wrote:

> [Slightly off-topic...]
>=20
> Mike,
>=20
> Accepting that the operational details be separate from the link =
relation semantics...
>=20
> In your (REST-informed?) view, where the link relation occurs within =
some retrieved representation, would be be reasonable for the =
representation to *also* indicate the operations that might be =
applicable?  (Somewhat like HTML <form> @method, maybe.)
>=20
> For example, to abuse an example from Darrel's draft [1]:
>=20
>       <link rel=3D"self" type=3D"application/atom+xml"
>           href=3D"http://example.org/feed"/>
>       <link rel=3D"publish"
>         href=3D"http://example.org/publish"/
>         method=3D"POST" post_types=3D"text/uri-list" />
>=20
> ("method" and "post-types" here are pure invention for the purpose of =
discussion.)
>=20
> So in this context, a client can move straight to the publication =
step, which I think is Darrel's goal with the operational discussion in =
the link relation.  In a different context, a client might have to =
perform a GET (or equivalent) to the linked resource to discover its =
affordances.

The problem is that you are making the specification of the link rel =
overly complex by extending already established linking specs.

If you want HTTP-header inline forms with similar semantics of HTML =
forms, I'd roll an I-D - but I would not try to bake it into something =
else using extensions.

As to why the operational semantics need not go into the rel spec, I =
just remembered this:

http://www.imc.org/atom-protocol/mail-archive/msg03925.html

in which Roy is touching the issue that you ust do not need to know =
operational semantics - it is a configuration-time issue (or call it =
introspection time).

Looking for tighter coupling by baking operational constraints into =
design time information is just trying to 'fix' the runtime uncertainty =
that REST deliberately makes explicit (REST aims to do away with the =
constraints because they are too constly to hold up in a decentralized =
environment).

Just assume the POST based on context and prepare the client that it =
might fail.

jan


>=20
> #g
> --
>=20
> [1] =
http://www.ietf.org/id/draft-hamnaberg-publish-link-relation-00.txt
>=20
> On 15/01/2014 21:37, mike amundsen wrote:
>> I'm not a fan of using a string as a network affordance ;) I know =
this is
>> not a universally held conviction. for example, HAL relies on this =
very
>> notion quite heavily.
>>=20
>> i assert the best way to use link relation values is as identifiers. =
The
>> registry let's use describe these values in a general way much the =
way a
>>  language dictionary (e.g. English, French, etc.) does. The way in =
which
>> the words are used, their intent, implied meaning, etc. are often =
based on
>> immediate context ("you owe me a payment" vs. "there is were you go =
to make
>> payments") and so forth.
>>=20
>> To your last point, I think tying operational semantics to a link =
relation
>> is over-constraining and limits it's use over time. Esp. when the
>> operational semantics are tied to a single protocol or format. I =
prefer to
>> keep usage details separate from the registry of unique values.
>>=20
>>=20
>>=20
>>=20
>>=20
>> mamund
>> +1.859.757.1449
>> skype: mca.amundsen
>> http://amundsen.com/blog/
>> http://twitter.com/mamund
>> https://github.com/mamund
>> http://linkedin.com/in/mamund
>>=20
>>=20
>> On Wed, Jan 15, 2014 at 3:58 PM, Darrel Miller =
<darrel.miller@gmail.com>wrote:
>>=20
>>> Mike,
>>>=20
>>> How do you feel about a link relation that says, if you do POST, it
>>> means this ...
>>>=20
>>> If that concerns you then do you have suggestions on how the these
>>> link relations should work:
>>>=20
>>> rel=3Dpayment        =
https://web-payments.org/specs/source/payment-links/
>>> rel=3Dhub
>>> https://pubsubhubbub.googlecode.com/git/pubsubhubbub-core-0.4.html
>>> rel=3Doauth2-token
>>> http://tools.ietf.org/html/draft-wmills-oauth-lrdd-07#page-8
>>>=20
>>> As far as I understand it, all of these have an associated meaning =
to
>>> a POST request.  Curiously, that meaning is not described in the rel
>>> relation registration, but in the specification that describes the
>>> protocol that uses the link relation.  This separation concerns me
>>> because we could end up with a situation where different protocols
>>> assign different interaction semantics to the same link relation.
>>>=20
>>> Darrel
>>>=20
>>>=20
>>>=20
>>> On Wed, Jan 15, 2014 at 1:05 PM, mike amundsen <mamund@yahoo.com> =
wrote:
>>>> My advice is to *not* attempt to constrain how the client or server
>>> behaves
>>>> when using the link relation (e.g. "client SHOULD use POST to =
....",
>>> etc.).
>>>>=20
>>>> Instead just define the link relation's meaning and let clients and
>>> servers
>>>> use that shared meaning to do whatever they want with it.
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> mamund
>>>> +1.859.757.1449
>>>> skype: mca.amundsen
>>>> http://amundsen.com/blog/
>>>> http://twitter.com/mamund
>>>> https://github.com/mamund
>>>> http://linkedin.com/in/mamund
>>>>=20
>>>>=20
>>>> On Wed, Jan 15, 2014 at 11:45 AM, Jan Algermissen
>>>> <jan.algermissen@nordsc.com> wrote:
>>>>>=20
>>>>>=20
>>>>> On 15.01.2014, at 16:59, Erlend Hamnaberg <erlend@hamnaberg.net> =
wrote:
>>>>>=20
>>>>>>=20
>>>>>> My use case has been a schedule for a conference.
>>>>>>=20
>>>>>> The program is built over time, but once it is done, I want to =
publish
>>>>>> it.
>>>>>=20
>>>>> If publishing is done by the same server, I'd change a property of =
the
>>>>> program to tell the server that it should publish.
>>>>>=20
>>>>> When on a nother server, I'd try to POST the program's =
representation,
>>>>> implicitly creating a new publishing job. That job will have a URI
>>> which I
>>>>> would use to observer the state of the job.
>>>>>=20
>>>>> Having "publish" point to the publishing system might make sense, =
in
>>> that
>>>>> sense "publish" would identoty a "resource providing publishing
>>> services".
>>>>>=20
>>>>> I'd ovoid to POST the URI to the publishing service if possible, =
because
>>>>> it reduces simpicity IMHO, because the publishing system will need =
to
>>> go and
>>>>> GET the resuorec to be published which feels unnatural to me.
>>>>>=20
>>>>> How does that resonate with you?
>>>>>=20
>>>>> Jan
>>>>>=20
>>>>>>=20
>>>>>> I could, of course, go through each session and publish it =
directly.
>>>>>> Each publishing step is then a state change for each session.
>>>>>> However, for a user interface can become cumbersome.
>>>>>>=20
>>>>>> However, If I decide to model this as two separate URIs,
>>>>>> I may need a different mechanism.
>>>>>>=20
>>>>>> Not sure I am able to explain this appropriately.
>>>>>>=20
>>>>>> Erlend
>>>>>=20
>>>>> _______________________________________________
>>>>> apps-discuss mailing list
>>>>> apps-discuss@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/apps-discuss
>>>>=20
>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> apps-discuss mailing list
>>>> apps-discuss@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/apps-discuss
>>>>=20
>>> _______________________________________________
>>> apps-discuss mailing list
>>> apps-discuss@ietf.org
>>> https://www.ietf.org/mailman/listinfo/apps-discuss
>>>=20
>>=20
>>=20
>>=20
>> _______________________________________________
>> apps-discuss mailing list
>> apps-discuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/apps-discuss
>>=20
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss


From julian.reschke@gmx.de  Thu Jan 16 06:03:41 2014
Return-Path: <julian.reschke@gmx.de>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33B251AE349 for <apps-discuss@ietfa.amsl.com>; Thu, 16 Jan 2014 06:03:41 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 5GFfwRzzh_C0 for <apps-discuss@ietfa.amsl.com>; Thu, 16 Jan 2014 06:03:40 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id A74FA1AE2CB for <apps-discuss@ietf.org>; Thu, 16 Jan 2014 06:03:39 -0800 (PST)
Received: from [192.168.1.102] ([217.91.35.233]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MYKGj-1VqEtb2vhp-00V82w for <apps-discuss@ietf.org>; Thu, 16 Jan 2014 15:03:26 +0100
Message-ID: <52D7E67A.90405@gmx.de>
Date: Thu, 16 Jan 2014 15:02:34 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Carsten Bormann <cabo@tzi.org>,  "apps-discuss@ietf.org Discuss" <apps-discuss@ietf.org>
References: <B3789B30-2698-4525-96ED-BBA9D8351941@tzi.org>
In-Reply-To: <B3789B30-2698-4525-96ED-BBA9D8351941@tzi.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K0:9tW+XhINBXipbxUsYgZ8Y0DMK1fQgZpR4KrJxexbf2a3G162K9D waq9EC7fB0Yde/9XI0+lwTT2IwP7fESvKkxk4QN+Zxrc2KK4Gg4yV1dEJ1sJbBQXaHfkiQe OTTRX8Ww6T0H1yrbV2/rGx289DmE49AcQLv8nhT8bN13EyjJzXYoXGltYoLlXj5uwEMRMYQ JKvR9p+txcaBm0o8+LnPg==
Subject: Re: [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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Jan 2014 14:03:41 -0000

On 2013-12-09 23:14, Carsten Bormann wrote:
> ...
> PS.: The appsdir review template doesn�t 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.
> ...

Indeed. See also 
<http://tools.ietf.org/html/draft-ietf-scim-api-02#section-3.3.2> where 
PATCH is used with a type of application/json although nobody has 
defines the semantics for that so far.

Best regards, Julian

From erlend@hamnaberg.net  Fri Jan 17 03:22:50 2014
Return-Path: <erlend@hamnaberg.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0933E1ADFBB for <apps-discuss@ietfa.amsl.com>; Fri, 17 Jan 2014 03:22:50 -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 0QzD8mDB5oPC for <apps-discuss@ietfa.amsl.com>; Fri, 17 Jan 2014 03:22:47 -0800 (PST)
Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by ietfa.amsl.com (Postfix) with ESMTP id B7E6E1ADF27 for <apps-discuss@ietf.org>; Fri, 17 Jan 2014 03:22:47 -0800 (PST)
Received: by mail-ob0-f182.google.com with SMTP id wn1so4204900obc.27 for <apps-discuss@ietf.org>; Fri, 17 Jan 2014 03:22:35 -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:content-type; bh=MzyxGwH0avKeVryhbtTfs1iRFPWzxcNa1Vuj/13UqtQ=; b=j2ssjIXh2Ddu7Wrz/s2rKtDOg1fdKeOHSUM59/E1ebVzf95l+X9ZoiVVKKJJE0VR5s 385eKYvnzEGynv5BlMNQJoQNjKCxWEOoCOWYUr9GbwAENHZm7BatMNkm51u5NUZYOWLA 5A63VFZijGZQoX5HbU8Wq5+5hrRjWtybaMPH6hcAV2TAjPgzNXMAsEiNE97YSkSf3NyR /6ZUwKRcHtW+631Mu/4HkR0fgEjJ7e6WxcnuBBNbXpIqaAVtZC+HZBA1LjfbxeZhoftP XBm34c+EUi0K0CpFyoSj1j9LI1xCt5f7JVQgg4I16wp6upg4itQlDhWTSN9GhaLQ0bVj ZxCw==
X-Gm-Message-State: ALoCoQnOT3dnwtzw3U2t8qqucyG2nFrIQ7mRypixXLzH2Dcdeac+GvsLyFljz8LRyThcclQii0jk
MIME-Version: 1.0
X-Received: by 10.182.44.167 with SMTP id f7mr1033164obm.3.1389957755178; Fri, 17 Jan 2014 03:22:35 -0800 (PST)
Received: by 10.182.160.98 with HTTP; Fri, 17 Jan 2014 03:22:35 -0800 (PST)
X-Originating-IP: [80.203.95.228]
In-Reply-To: <20140117112133.29469.81386.idtracker@ietfa.amsl.com>
References: <20140117112133.29469.81386.idtracker@ietfa.amsl.com>
Date: Fri, 17 Jan 2014 12:22:35 +0100
Message-ID: <CAGuwm8U-ULy0j9dEgNM5HeM98dSgf-YxPMi6-kxvxEyPtFOhJQ@mail.gmail.com>
From: Erlend Hamnaberg <erlend@hamnaberg.net>
To: IETF Apps Discuss <apps-discuss@ietf.org>
Content-Type: multipart/alternative; boundary=001a11c1d7e04022a804f028c239
Subject: [apps-discuss] Fwd: New Version Notification for draft-hamnaberg-publish-link-relation-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Jan 2014 11:22:50 -0000

--001a11c1d7e04022a804f028c239
Content-Type: text/plain; charset=ISO-8859-1

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Fri, Jan 17, 2014 at 12:21 PM
Subject: New Version Notification for
draft-hamnaberg-publish-link-relation-01.txt
To: Erlend Hamnaberg <erlend@hamnaberg.net>



A new version of I-D, draft-hamnaberg-publish-link-relation-01.txt
has been successfully submitted by Erlend Hamnaberg and posted to the
IETF repository.

Name:           draft-hamnaberg-publish-link-relation
Revision:       01
Title:          The 'publish' Link Relation Type
Document date:  2014-01-17
Group:          Individual Submission
Pages:          6
URL:
http://www.ietf.org/internet-drafts/draft-hamnaberg-publish-link-relation-01.txt
Status:
https://datatracker.ietf.org/doc/draft-hamnaberg-publish-link-relation/
Htmlized:
http://tools.ietf.org/html/draft-hamnaberg-publish-link-relation-01
Diff:
http://www.ietf.org/rfcdiff?url2=draft-hamnaberg-publish-link-relation-01

Abstract:
   This memo defines a 'publish' link relation and provides a number of
   examples.




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

--001a11c1d7e04022a804f028c239
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br><div class=3D"gmail_quote">---------- Forwarded me=
ssage ----------<br>From: <b class=3D"gmail_sendername"></b> <span dir=3D"l=
tr">&lt;<a href=3D"mailto:internet-drafts@ietf.org">internet-drafts@ietf.or=
g</a>&gt;</span><br>
Date: Fri, Jan 17, 2014 at 12:21 PM<br>Subject: New Version Notification fo=
r draft-hamnaberg-publish-link-relation-01.txt<br>To: Erlend Hamnaberg &lt;=
<a href=3D"mailto:erlend@hamnaberg.net">erlend@hamnaberg.net</a>&gt;<br><br=
>
<br><br>
A new version of I-D, draft-hamnaberg-publish-link-relation-01.txt<br>
has been successfully submitted by Erlend Hamnaberg and posted to the<br>
IETF repository.<br>
<br>
Name: =A0 =A0 =A0 =A0 =A0 draft-hamnaberg-publish-link-relation<br>
Revision: =A0 =A0 =A0 01<br>
Title: =A0 =A0 =A0 =A0 =A0The &#39;publish&#39; Link Relation Type<br>
Document date: =A02014-01-17<br>
Group: =A0 =A0 =A0 =A0 =A0Individual Submission<br>
Pages: =A0 =A0 =A0 =A0 =A06<br>
URL: =A0 =A0 =A0 =A0 =A0 =A0<a href=3D"http://www.ietf.org/internet-drafts/=
draft-hamnaberg-publish-link-relation-01.txt" target=3D"_blank">http://www.=
ietf.org/internet-drafts/draft-hamnaberg-publish-link-relation-01.txt</a><b=
r>
Status: =A0 =A0 =A0 =A0 <a href=3D"https://datatracker.ietf.org/doc/draft-h=
amnaberg-publish-link-relation/" target=3D"_blank">https://datatracker.ietf=
.org/doc/draft-hamnaberg-publish-link-relation/</a><br>
Htmlized: =A0 =A0 =A0 <a href=3D"http://tools.ietf.org/html/draft-hamnaberg=
-publish-link-relation-01" target=3D"_blank">http://tools.ietf.org/html/dra=
ft-hamnaberg-publish-link-relation-01</a><br>
Diff: =A0 =A0 =A0 =A0 =A0 <a href=3D"http://www.ietf.org/rfcdiff?url2=3Ddra=
ft-hamnaberg-publish-link-relation-01" target=3D"_blank">http://www.ietf.or=
g/rfcdiff?url2=3Ddraft-hamnaberg-publish-link-relation-01</a><br>
<br>
Abstract:<br>
=A0 =A0This memo defines a &#39;publish&#39; link relation and provides a n=
umber of<br>
=A0 =A0examples.<br>
<br>
<br>
<br>
<br>
Please note that it may take a couple of minutes from the time of submissio=
n<br>
until the htmlized version and diff are available at <a href=3D"http://tool=
s.ietf.org" target=3D"_blank">tools.ietf.org</a>.<br>
<br>
The IETF Secretariat<br>
<br>
</div><br></div>

--001a11c1d7e04022a804f028c239--

From superuser@gmail.com  Fri Jan 17 11:09:04 2014
Return-Path: <superuser@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 153921A1F71 for <apps-discuss@ietfa.amsl.com>; Fri, 17 Jan 2014 11:09: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 yGx3TCBZHhL5 for <apps-discuss@ietfa.amsl.com>; Fri, 17 Jan 2014 11:09:02 -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 A1A6A1A1F63 for <apps-discuss@ietf.org>; Fri, 17 Jan 2014 11:09:02 -0800 (PST)
Received: by mail-we0-f177.google.com with SMTP id x55so4777013wes.8 for <apps-discuss@ietf.org>; Fri, 17 Jan 2014 11:08:49 -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=d1B0bTfASQudbzQ9rAWztk0A/wopejdN0qlSeKNGhrY=; b=pSxUvUcFIEqAPbQtJLqW0f8etdupljHw2god39QRrRjUD1YlppV4fsmnmCrvpdnirM ThOYputS0HtUtGSnfZfiGMo5YyGF6Z5K0iDdIPJsgTjxv2/sLrdRz6tt697sfPhfZq64 JsnuZnaRChOvJ/Iz51n4GJGSnMUO3UTntISl0iAC0KJUkPvHkCWYdBz1Eswi6Be/P8Zg wKAzz6cLyGP95yWJAVwYQBL5CYKxvHT7/dgC7bRsLSXcTWW+fNWAERV5qLMh23OYUAx2 EWAXEFc8Aua44dSQ8p2u9NJD7o4TpxCSNYaJCX5YdVy9Y/JtUNuKGBRosssf/01S+1ns dE0A==
MIME-Version: 1.0
X-Received: by 10.180.187.72 with SMTP id fq8mr4137565wic.26.1389985729514; Fri, 17 Jan 2014 11:08:49 -0800 (PST)
Received: by 10.180.84.106 with HTTP; Fri, 17 Jan 2014 11:08:49 -0800 (PST)
Date: Fri, 17 Jan 2014 11:08:49 -0800
Message-ID: <CAL0qLwaER1tEaVvXb8yJzU8ujNcUFkRKdRpnEEdousvKwJwFBg@mail.gmail.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
To: IETF Apps Discuss <apps-discuss@ietf.org>
Content-Type: multipart/alternative; boundary=001a11c2679ca6910904f02f4583
Subject: [apps-discuss] IETF 89 scheduling
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Jan 2014 19:09:04 -0000

--001a11c2679ca6910904f02f4583
Content-Type: text/plain; charset=ISO-8859-1

Colleagues,

I've requested our usual 2.5-hour session with the same conflicts as we had
for Vancouver.

Please propose agenda items for London.  The draft agenda is due to the
Secretariat on 2/17.

Thanks,
-MSK, WEIRDS co-chair

--001a11c2679ca6910904f02f4583
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Colleagues,<br><br>I&#39;ve requested our usual 2.5-h=
our=20
session with the same conflicts as we had for Vancouver.<br>
<br></div>Please propose agenda items for London.=A0 The draft agenda is du=
e to the Secretariat on 2/17.<br><br>Thanks,<br>-MSK, WEIRDS co-chair<br><b=
r></div>

--001a11c2679ca6910904f02f4583--

From gonzalo.camarillo@ericsson.com  Tue Jan 21 07:57:22 2014
Return-Path: <gonzalo.camarillo@ericsson.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63D051A03D9; Tue, 21 Jan 2014 07:57:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.24
X-Spam-Level: 
X-Spam-Status: No, score=-101.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, 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 rsKzrrK1sKFF; Tue, 21 Jan 2014 07:57:20 -0800 (PST)
Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 438711A0393; Tue, 21 Jan 2014 07:57:17 -0800 (PST)
X-AuditID: c1b4fb32-b7f4c8e0000012f5-2c-52de98dd975e
Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 05.C4.04853.DD89ED25; Tue, 21 Jan 2014 16:57:17 +0100 (CET)
Received: from [147.214.22.241] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.44) with Microsoft SMTP Server id 14.2.347.0; Tue, 21 Jan 2014 16:57:16 +0100
Message-ID: <52DE98DC.90900@ericsson.com>
Date: Tue, 21 Jan 2014 16:57:16 +0100
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: <dcrocker@bbiw.net>, Peter Saint-Andre <stpeter@stpeter.im>, Apps Discuss <apps-discuss@ietf.org>, <draft-ietf-stox-presence.all@tools.ietf.org>, <stox@ietf.org>
References: <52A94AF6.8090702@dcrocker.net> <52AB8E69.7070906@stpeter.im> <52B07028.4020609@dcrocker.net>
In-Reply-To: <52B07028.4020609@dcrocker.net>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHLMWRmVeSWpSXmKPExsUyM+Jvje7dGfeCDLa0SlmsfrmCzeL3pw9s FvN6rzJbzPgzkdni/44mVotje/qZHdg8Lu08yeaxZMlPJo+5e14we3y5/JktgCWKyyYlNSez LLVI3y6BK6Nv9wTGggmJFfe7lzI2MO717mLk5JAQMJH4s3oKI4QtJnHh3nq2LkYuDiGBE4wS 6yd/YoJw1jBKLLuyG6iKg4NXQFNi71IDkAYWAVWJg33d7CA2m4CFxJZb91lAbFGBKIkD83aA DeUVEJQ4OfMJC8gcEYGVjBLvV15mB5nDLCAhcWRlEEiNsIC1xLpF69hAbCGBTImlK0+DreIU 0JG4sK0KxJQQEJfoaQSrZhbQk5hytYURwpaX2P52DjNEp7bE8mctLBMYhWYhWTwLScssJC0L GJlXMUoWpxYX56YbGejlpueW6KUWZSYXF+fn6RWnbmIExsHBLb+NdjCe3GN/iFGag0VJnPc6 a02QkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsY9LDPVOf9+t/7etnfT/x3Cqcrn3Zyt94ft 3Fz7teR9Q7A398/7tZP/q/s84NW/J9vNM+3bRIvDLJOKrpgZLYzqZWe503nyqtGfxfPlYriv tJvfjebZw95x9ohiMItlrcyt7e75Zl+D71r2vru+Z2Oq6PmC06aqL20zYubEXvfboH59S9SC txOUWIozEg21mIuKEwG1cXvPUQIAAA==
Cc: iesg <iesg@ietf.org>
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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Jan 2014 15:57:22 -0000

Hi Peter,

when do you think you will get around to revising the draft per Dave's
comments?

Thanks for the review, Dave.

Cheers,

Gonzalo

On 17/12/2013 4:39 PM, Dave Crocker wrote:
> Only responded where it seems needed or useful...
> 
> 
> 
> On 12/13/2013 2:47 PM, Peter Saint-Andre wrote:
> 
>>>     1.  When citing the earlier efforts, there should be something to
>>> explain why the current work is expected to be more successful.
>>
>> Not "expected", but "is". :-) AFAIK there are no implementations of the
> 
> I'd missed that this is based on deployed work.  That is a point that
> always makes writing text justifying/motivating the document quite easy:
>  just say that.
> 
> 
>> approach taken by RFC 3922 and draft-ietf-simple-cpim-mapping (i.e.,
>> mapping to the abstract semantics of RFC 3860), whereas there are
>> multiple implementations of the approach described here (i.e., direct
>> mapping between SIP and XMPP).
>>
>>> That is,
>>> what makes the current approach notably tractable for implementation and
>>> deployment?
>>
>> Do you think that explaining why would improve the document? IMHO this
> 
> I'm a fan of context and systems views, because I think it orients the
> reader usefully, so the simple answer is yes.
> 
> Whenever there is a lengthy history with alternative efforts, readers
> can benefit from some context that distinguishes the current work.  Not
> in qualitative terms like better or worse, but in technical and
> operational terms.
> 
> Hence I think language like what's already in the document, that
> distinguishes the 'architectural' difference from earlier work, but also
> one that says that the current work is based on deployed industry choice.
> 
> 
>> verges into developer psychology (I've got this SIP thing here and this
> 
> 
>>>     5.  When showing protocol examples, usually only one side of the
>>> sequence is shown.  For gatewaying that does interesting transforms,
>>> such as this one, an example should show both the before and after
>>> versions.  That is, the 'native' protocol unit that was created and then
>>> the one that results from the translation.
>>
>> I thought we'd already done that. For instance, Example 2 is the SIP
>> transformation of the XMPP stanza shown in Example 1.
> 
> Either the document didn't do it as diligently as I'm suggesting, or I
> didn't understand this aspect of the document, which might be remedied
> by better labeling.
> 
> For any example that is done in a gateway and is a translation between
> sip presence and xmpp presence, something simple and rigorous, such as
> "before" and "after" labels to source and transformed versions, ought to
> remedy this.
> 
> 
> 
> 
>>> This probably raises a larger issue:  How much expertise is expected of
>>> someone who is implementing this or otherwise reading for deep
>>> comprehension?  In the extreme, they will need to have serious expertise
>>> on both protocol sets.  The other extreme would be a cookbook inside
>>> this document, with no outside knowledge required.  The document needs
>>> to specify the nature and extent of the expertise required.  (In fact,
>>> the document seems pretty clean, in terms of explaining things, so I
>>> suspect that 'fair' knowledge of one suite will suffice.  But the author
>>> and wg beliefs about the requirement should be made explicit.)
>>
>> See above. Perhaps not expert level, but significant familiarity with
>> one "side" or the other.
> 
> Just to emphasize, whatever the knowledge-level of reader that's
> required, the document should make that explicit.
> 
> I'm always a fan of making documents more accessible to wider
> readership, but it's not practical to make all documents fully
> accessible, especially within a suite of docs that build on each other.
> 
> 
>>>>     |  SUBSCRIBE sip:romeo@example.net SIP/2.0
>>>
>>> Later text (section 4.1) equates the label pres: with sip: and sips:.
>>> Why choose sip: here?
>>
>> In practice, we don't see 'pres' URIs in the wild.
> 
> Hmmm.  While 'statistics' of use is a relatively fragile basis for
> putting things into a spec -- since a doc can last for decades and
> statistics can change -- it might be worth mentioning as the basis for
> the choice in the doc.  I suppose that's in the realm of giving the
> reader a bit of operational insight.  But definitely not an important
> point.
> 
> 
> 
>>>>     Example 3: SIP accepts subscription request:
>>>>
>>>>     |  SIP/2.0 200 OK
>>>>     |  Via: SIP/2.0/TCP s2x.example.net;branch=z9hG4bKna998sk
>>>>     |  From: <sip:romeo@example.net>;tag=ffd2
>>>>     |  To: <sip:juliet@example.com>;tag=j89d
>>>>     |  Call-ID: 5BCF940D-793D-43F8-8972-218F7F4EAA8C
>>>>     |  CSeq: 234 SUBSCRIBE
>>>>     |  Contact: <sip:simple.example.net;transport=tcp>
>>>>     |  Expires: 3600
>>>>     |  Content-Length: 0
>>>
>>> Hmmm.  This appears to be the original SIP acceptance, but with no
>>> separate display of it's being translated into XMPP.
>>
>> That is Example 5.
> 
> Oh. It's worth making that explicit.  (My tendency to get confused
> reading specs is a useful canary in the tunnel, for what needs
> clarifying for other readers, IMO...)
> 
> 
> 
>>>>     Example 10: SIP user subscribes to XMPP contact:
>>>>
>>>>     |  SUBSCRIBE sip:juliet@example.com SIP/2.0
>>>>     |  Via: SIP/2.0/TCP s2x.example.net;branch=z9hG4bKna998sk
>>>>     |  From: <sip:romeo@example.net>;tag=xfg9
>>>>     |  Call-ID: AA5A8BE5-CBB7-42B9-8181-6230012B1E11
>>>>     |  Event: presence
>>>>     |  Max-Forwards: 70
>>>>     |  CSeq: 263 SUBSCRIBE
>>>>     |  Contact: <sip:simple.example.net;transport=tcp>
>>>>     |  Accept: application/pidf+xml
>>>>     |  Content-Length: 0
>>>>
>>>>     Notice that the "Expires" header was not included in the SUBSCRIBE
>>>>     request; this means that the default value of 3600 (i.e., 3600
>>>>     seconds = 1 hour) applies.
>>>>
>>>>     Upon receiving the SUBSCRIBE, the SIP server needs to determine the
>>>>     identity of the domain portion of the Request-URI or To header,
>>>> which
>>>>     it does by following the procedures discussed in
>>>>     [I-D.ietf-stox-core].  Here we assume that the SIP server has
>>>>     determined that the domain is serviced by an XMPP server, that it
>>>
>>>
>>> This seems to mean that a regular SIP server needs to be familiar with
>>> technical details in a gatewaying specification??
>>
>> Well, it is (IMHO) really the responsibility of a core "server" to
>> implement this kind of routing functionality, but the "gateway" might
>> make the determination that the remote domain uses SIP or XMPP and if
>> SIP then pass it on to the SIP "server" and if not handle delivery to
> 
> I think this matches the usual model:  an unchanged server does routing
> as if all participants were part of its 'native' protocol service.  A
> gateway translates and tries to hide any differences between two services.
> 
> The current doc language seems confusing on this point, when it talks
> about a (native) server choosing a server that is part of the other
> service.
> 
> This is a sufficiently basic point to probably warrant going into -core,
> rather than here.  But the language here probably therefore ought to
> just be in terms of originators and recipients (or whatever generic
> terminology works for presence) with an initial, simple note that
> knowledge of the need for translation only resides in the gateway(s).
> 
> But I'm not sure I mentioned another point that confused me from -core:
>  It shows the two types of gateways as talking to each other, but I
> suspect that's not reality.  FOr example, when doing SIP-XMPP, I suspect
> the actual flow is:
> 
>    SIP User
>    SIP Server
>    SIP-XMPP Server
>    XMPP Server
>    XMPP User
> 
> whereas the implication from the -core diagram and some of the language
> in the spec(s) is:
> 
>    SIP User
>    SIP Server
>    SIP-XMPP Server
>    XMPP-SIP Server
>    XMPP Server
>    XMPP Use
> 
> If it really is the later sequence, I don't understand why.
> 
> 
> 
>> the remote XMPP domain. To some extent it's a matter of implementation
>> where exactly the code lives to complete these functions, which is why
>> draft-ietf-stox-core talks about a "SIP service" consisting of both a
>> SIP "server" and a "gateway". In XMPP this translation function is often
>> handled by what we call a "connection manager", but that depends a bit
>> on the internal architecture of the overall "service".
> 
> This point highlights the essential difference between a "networking
> architecture" and an "implementation architecture".
> 
> Mapping from the first to the second often permits very wide variations.
>  The former concerns distinct functionality that /can/ be distributed,
> where the latter makes specific choices for what /is/ distributed.
> 
> 
> 
> 
>>>>     As described in [RFC3856], presence information about an entity is
>>>>     communicated by means of a SIP NOTIFY event sent from a SIP user
>>>>     agent to an intended recipient who is most generally referenced
>>>> by an
>>>>     Presence URI of the form <pres:user@domain> but who might be
>>>>     referenced by a SIP or SIPS URI of the form <sip:user@domain> or
>>>>     <sips:user@domain>.  Here again we introduce the simplifying
>>>>     assumption that the user agent is controlled by a human user.
>>>
>>> I guess I'm not understanding how the nature of what is controlling the
>>> agent affects anything in this document.  Might be worth explaining
>>> that.
>>
>> A "presentity" doesn't have to be a human -- it could be a bot, a
>> device, or some other automated entity. People related more to human
>> users.
> 
> Sure, but when reading the doc, it felt as if the reference to this
> issue was relevant to functionality.  I'd expect the issue to be raised
> once in an Intro and then avoided later by use of a neutral term like
> user or presentity or whatever.
> 
> 
> 
>>>>     Note the following regarding these mappings:
>>>>
>>>>     1.  Only a presence stanza that lacks a 'type' attribute or whose
>>>
>>>     presence -> XMPP presence
>>
>> Stanzas are an XMPP artifact. But yes.
> 
> Choosing the level of semantic redundancy in the language is always a
> balancing act.  In a gatewaying document that will be reader by folks
> likely to be expert in only one half of the necessary technologies, I'd
> be inclined towards more redundancy, to reduce likelihood of
> misunderstanding...
> 
> 
> 
>>>>         'type' attribute has a value of "unavailable" SHOULD be
>>>> mapped by
>>>>         an XMPP-SIMPLE gateway to a SIP NOTIFY request, since those are
>>>>         the only presence stanzas that represent notifications.
>>>>     2.  The PIDF schema defines the tuple 'id' attribute as having a
>>>>         datatype of "xs:ID"; because this datatype is more restrictive
>>>>         than the "xs:string" datatype for XMPP resourceparts (in
>>>>         particular, a number is not allowed as the first character
>>>> of an
>>>>         ID), it is RECOMMENDED to prepend the resourcepart with
>>>> "ID-" or
>>>>         some other alphabetic string when mapping from XMPP to SIP.
>>>>     3.  This mapping is OPTIONAL.
>>>
>>> What does that mean?  This sort of mapping is usually the essence of
>>> gatewaying semantics.  How can interoperability tolerate it's being
>>> optional?
>>
>> In XMPP, the 'id' attribute is not usually included in presence stanzas,
>> and nothing is lost if it's ignored. But I'll give it a bit more thought.
>>
>>>> 4.3.  SIP to XMPP
>>>>
>>>>     When Romeo changes his presence, his SIP user agent generates a SIP
>>>
>>> Romeo is doing SIP?  And Juliet does XMPP?
>>
>> You noticed, eh? "Juliet does Jabber" makes it easy to remember, at
>> least for me.
> 
> So why isn't the other side Steve or Sid or...
> 
> Nevermind...
> 
> 
> 
>>> So, SIP is more macho than XMPP???
>>
>> Have you configured a SIP client lately? ;-)
>>
>> But seriously, the Romeo and Juliet scenarios enable me to use a male
> 
> The word seriously is entirely out of scope for this segment.  Or at
> least, it certainly was when I started it...
> 
> d/
> 


From ietfc@btconnect.com  Tue Jan 21 09:36:38 2014
Return-Path: <ietfc@btconnect.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BD561A0165 for <apps-discuss@ietfa.amsl.com>; Tue, 21 Jan 2014 09:36:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.701
X-Spam-Level: 
X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, J_CHICKENPOX_25=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 XlcOoF3RVCoG for <apps-discuss@ietfa.amsl.com>; Tue, 21 Jan 2014 09:36:34 -0800 (PST)
Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe004.messaging.microsoft.com [207.46.163.27]) by ietfa.amsl.com (Postfix) with ESMTP id AB9131A018E for <apps-discuss@ietf.org>; Tue, 21 Jan 2014 09:36:34 -0800 (PST)
Received: from mail88-co9-R.bigfish.com (10.236.132.254) by CO9EHSOBE018.bigfish.com (10.236.130.81) with Microsoft SMTP Server id 14.1.225.22; Tue, 21 Jan 2014 17:36:34 +0000
Received: from mail88-co9 (localhost [127.0.0.1])	by mail88-co9-R.bigfish.com (Postfix) with ESMTP id EB020A010B; Tue, 21 Jan 2014 17:36:33 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.249.213; KIP:(null); UIP:(null); IPV:NLI; H:AM2PRD0710HT001.eurprd07.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -17
X-BigFish: PS-17(zz9371I936eI1454I542Ie0eah1432I1418Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h20f7h2189h1d1ah1d2ah21bch1fc6hzz1de098h1033IL8275dh1de097h186068hz2dh2a8h5a9h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah2222h224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h2218h2216h226dh22d0h24afh2327h2336h2438h2461h2487h24ach304l1d11m1155h)
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(52044002)(51444003)(13464003)(51704005)(189002)(199002)(377454003)(377424004)(50986001)(4396001)(74876001)(47976001)(47736001)(53806001)(50226001)(33646001)(84392001)(44736004)(77156001)(23756003)(86362001)(93916002)(54316002)(56776001)(50466002)(93516002)(575784001)(62236002)(81342001)(65816001)(59766001)(92566001)(49866001)(92726001)(93136001)(66066001)(80022001)(47776003)(74706001)(85306002)(88136002)(44716002)(79102001)(62966002)(81542001)(87286001)(61296002)(14496001)(42186004)(63696002)(69226001)(46102001)(56816005)(83072002)(90146001)(85852003)(77096001)(76796001)(89996001)(76786001)(31966008)(51856001)(47446002)(74366001)(87976001)(77982001)(76482001)(15975445006)(87266001)(74502001)(74662001)(19580405001)(83322001)(80976001)(19580395003)(74416001)(7726001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB3PR07MB060; H:DBXPRD0611HT003.eurprd06.prod.outlook.com; CLIP:157.56.254.85; FPR:; RD:InfoNoRecords; MX:1; A:0; LANG:en; 
Received: from mail88-co9 (localhost.localdomain [127.0.0.1]) by mail88-co9 (MessageSwitch) id 1390325791312764_13671; Tue, 21 Jan 2014 17:36:31 +0000 (UTC)
Received: from CO9EHSMHS014.bigfish.com (unknown [10.236.132.248])	by mail88-co9.bigfish.com (Postfix) with ESMTP id 489A5220047;	Tue, 21 Jan 2014 17:36:31 +0000 (UTC)
Received: from AM2PRD0710HT001.eurprd07.prod.outlook.com (157.56.249.213) by CO9EHSMHS014.bigfish.com (10.236.130.24) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 21 Jan 2014 17:36:30 +0000
Received: from DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) by AM2PRD0710HT001.eurprd07.prod.outlook.com (10.255.165.36) with Microsoft SMTP Server (TLS) id 14.16.395.1; Tue, 21 Jan 2014 17:36:29 +0000
Received: from DBXPRD0611HT003.eurprd06.prod.outlook.com (157.56.254.85) by DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) with Microsoft SMTP Server (TLS) id 15.0.851.15; Tue, 21 Jan 2014 17:36:28 +0000
Message-ID: <026d01cf16ce$bb20d980$4001a8c0@gateway.2wire.net>
From: t.petch <ietfc@btconnect.com>
To: Stephan Bosch <stephan@rename-it.nl>, apps-discuss <apps-discuss@ietf.org>
References: <52D3A2C8.5030807@rename-it.nl> <01P33JH6T0LO0000AS@mauve.mrochek.com> <CAL0qLwY+pejVBVOmz_PMRF_0ORaNVrOmzB4_SVYVnw+dtC0QQA@mail.gmail.com> <20140114085709.GA21460@gulbrandsen.priv.no> <52D50F3A.8040206@rename-it.nl>
Date: Tue, 21 Jan 2014 17:18:09 +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.254.85]
X-ClientProxiedBy: DBXPR07CA008.eurprd07.prod.outlook.com (10.255.191.166) To DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151)
X-Forefront-PRVS: 0098BA6C6C
X-OriginatorOrg: btconnect.com
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
Subject: Re: [apps-discuss] Review of 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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Jan 2014 17:36:38 -0000

Stephan

I previously raised the issue of i18n, or Normalisation, which I still
think needs
more attention in this I-D.

This I-D allows comparisons of the message body while RFC5228, as far as
I can see, only covers the treatment of strings in the headers (s.2.7.2)

So if the body of a message is in base64, then is the comparison based
on

SGVsbG8gTWFuYXYsCgpZb3Ugd3JvdGU6Cgo+IEkgaGF2ZSBiZWVu

or

Hello Manav ...

And where the implementation cannot convert a header to UTF8, then
RFC5228 treats
anything over 127 as voiding the comparison.   So when the subject line
is

=?utf-8?b?5Zue5aSN77yaIHByb3Bvc2VkIGRyYWZ0cyBmb3IgYWxpZ25p?=
 =?utf-8?q?ng_MPLS-TP_PSC_linear_protection_protocol_to_transport_r?=
 =?utf-8?q?equirements?=

does that count as being below 127? is that used or

proposed drafts for aligning MPLS-TP PSC linear protection protocol to
transport requirements

I haven't got an example of messages arriving from the IETF via two
different ISP with different encodings, but suspect that that is only a
matter of time.

Like I said, I think that this topic is much more important now than it
was when sieve first appeared, and that the use of non-ASCII in e-mail
has grown enormously, so something needs to be said, even if it is just
that the results are unpredictable when .... is used, for some values of
....

Tom Petch

----- Original Message -----
From: "Stephan Bosch" <stephan@rename-it.nl>
To: "Arnt Gulbrandsen" <arnt@gulbrandsen.priv.no>;
<apps-discuss@ietf.org>
Sent: Tuesday, January 14, 2014 10:19 AM

> Arnt Gulbrandsen schreef op 14-1-2014 10:06:
> > Hi,
> >
> > I read this draft earlier and decided to ignore it. There's nothing
> > terribly bad about it, I wouldn't want to block it, but IMO also
> > nothing terribly good.
> >
> > I have one real problem and a word nit.
> >
> > Consider the main use case, from the document's introduction:
> >
> >     Duplicate deliveries are a common side-effect of being
subscribed
> >     to a mailing list.
> >
> > I would expect that the draft makes handling that use case simple,
and
> > a well-rounded set of other use cases possible. IMO it does poorly
at
> > that use case.
> >
> > Here's the first example for the Pigeonhole sieve server, modified
to
> > suppress duplicates rather like how the first example in
> > sieve-duplicate does:
> >
> >     require ["fileinto", "envelope", "duplicate"];
> >     if address :is "to" "dovecot@dovecot.org" {
> >       fileinto "Dovecot-list";
> >     } elsif envelope :is "from" "owner-cipe-l@inka.de" {
> >       fileinto "lists.cipe";
> >     } elsif anyof (header :contains "X-listname"
"lugog@cip.rz.fh-offenburg.de",
> >                    header :contains "List-Id" "Linux User Group
Offenburg") {
> >       fileinto "ml.lugog";
> >     } elsif duplicate {
> >       discard;
> >     } else {
> >       # The rest goes into INBOX
> >       # default is "implicit keep", we do it explicitly here
> >       keep;
> >     }
> >
> > If a message is sent to you personally with a cc to cipe-l or lugog,
> > this sieve script will file it into either lists.cipe/ml.lugg or
> > inbox, randomly, depending on which copy arrives first. This strikes
> > me as rather poor handling of the use case.
> >
> > 1. It's not what I want. What I personally want is to have a single
> > instance of the message filed in all the mailboxes fileinto/keep
> > specifies for any instance of the message, and the other instances
> > suppressed. But feel free to disregard this point, after all it's
just
> > my personal desire.
> >
> > 2. It's not deterministic. And that's worse. This draft makes the
> > lists.cipe/ml.lugog mailbox into a randomly incomplete set of
messages
> > to the relevant list, which isn't much of an improvement over the
> > status quo.
>
> There are two aspects to this problem.
>
> First, this example is flawed. The duplicate test has a side effect:
> apart from testing for a duplicate it also records the identifier (in
> the bare case the Message-ID) for comparison in subsequent deliveries.
> So, if the test is not evaluated, the identifier is never recorded.
>
> This example should address that problem:
>
> require ["fileinto", "envelope", "duplicate"];
>
> if duplicate {
>    discard;
> } else {
>    if address :is "to" "dovecot@dovecot.org" {
>      fileinto "Dovecot-list";
>    } elsif envelope :is "from" "owner-cipe-l@inka.de" {
>      fileinto "lists.cipe";
>    } elsif anyof (header :contains "X-listname"
"lugog@cip.rz.fh-offenburg.de",
>                   header :contains "List-Id" "Linux User Group
Offenburg") {
>      fileinto "ml.lugog";
>    } else {
>      # The rest goes into INBOX
>      # default is "implicit keep", we do it explicitly here
>      keep;
>    }
> }
>
> The second aspect is a bigger issue. It is indeed uncertain which copy
arrives first: the Cc or the message through the mailing list. The
latter will have the List-Id header, the former will not. The above
example would therefore still be problematic for the ml.lugog mailing
list. I am not certain whether there could be any solution for that,
other than not relying on the List-ID header and accepting that the
destination folder will contain a mixture of the Cc and the actual
mailing list messages.
>
> > My nit concerns the word multiple. Four is a multiple of two, but
> > "several" and "many" are perfectly fine words to mean "integers
larger
> > than one".
>
> So, you want me to vary  a bit? :)
>
> > I once had a student who met his minimum pagecount by using long
words
> > and hacky tex wordwrapping. He would write "multiple independent
> > purposes" instead of "several purposes" or "many purposes". Unlike
> > him, internet-drafts authors have no need to leverage multiple
> > unnecesssary polysyllabic words in order to meet university-imposed
> > arbitrary minimum length requirements.
>
> I used the word independent to stress the fact that these applications
> would not influence each other when applied within the same Sieve
> script. I can word that differently, but I doubt it will become much
> shorter. :)
>
> Regards,
>
> Stephan.
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>



From stephan@rename-it.nl  Tue Jan 21 10:10:58 2014
Return-Path: <stephan@rename-it.nl>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C06721A0180 for <apps-discuss@ietfa.amsl.com>; Tue, 21 Jan 2014 10:10:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.26
X-Spam-Level: 
X-Spam-Status: No, score=0.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_15=0.6, RP_MATCHES_RCVD=-0.535] 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 aSdO7-QI-lJt for <apps-discuss@ietfa.amsl.com>; Tue, 21 Jan 2014 10:10:56 -0800 (PST)
Received: from drpepper.rename-it.nl (drpepper.rename-it.nl [217.119.238.16]) by ietfa.amsl.com (Postfix) with ESMTP id 8096E1A00C8 for <apps-discuss@ietf.org>; Tue, 21 Jan 2014 10:10:55 -0800 (PST)
Received: from klara.student.utwente.nl ([130.89.162.218]:59542 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 <stephan@rename-it.nl>) id 1W5fmk-0002YH-A8; Tue, 21 Jan 2014 19:10:52 +0100
Message-ID: <52DEB827.9090606@rename-it.nl>
Date: Tue, 21 Jan 2014 19:10:47 +0100
From: Stephan Bosch <stephan@rename-it.nl>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: "t.petch" <ietfc@btconnect.com>, apps-discuss <apps-discuss@ietf.org>
References: <52D3A2C8.5030807@rename-it.nl> <01P33JH6T0LO0000AS@mauve.mrochek.com> <CAL0qLwY+pejVBVOmz_PMRF_0ORaNVrOmzB4_SVYVnw+dtC0QQA@mail.gmail.com> <20140114085709.GA21460@gulbrandsen.priv.no> <52D50F3A.8040206@rename-it.nl> <026d01cf16ce$bb20d980$4001a8c0@gateway.2wire.net>
In-Reply-To: <026d01cf16ce$bb20d980$4001a8c0@gateway.2wire.net>
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] Review of 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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Jan 2014 18:10:59 -0000

On 1/21/2014 6:18 PM, t.petch wrote:
> Stephan
>
> I previously raised the issue of i18n, or Normalisation, which I still
> think needs
> more attention in this I-D.
>
> This I-D allows comparisons of the message body while RFC5228, as far as
> I can see, only covers the treatment of strings in the headers (s.2.7.2)

The transcoding of the header content to UTF-8 is actually something I
should mention more explicitly by referring to that section.

> So if the body of a message is in base64, then is the comparison based
> on
>
> SGVsbG8gTWFuYXYsCgpZb3Ugd3JvdGU6Cgo+IEkgaGF2ZSBiZWVu
>
> or
>
> Hello Manav ...

This extension does not access the message body directly. The only way
to achieve testing against the body is putting (parts of) the message
body in a variable. This can currently only be done using the
extracttext extension (http://tools.ietf.org/html/rfc5703#section-7).
The specification of extracttext states:

"Servers MUST support transcoding of any textual body part into UTF-8 for use with this action. This requires decoding any transfer encoding as well as transcoding from the indicated character set into UTF-8."

The issue you raise is therefore no problem at all.

The use of the extracttext extension is already mentioned in the document.


> And where the implementation cannot convert a header to UTF8, then
> RFC5228 treats
> anything over 127 as voiding the comparison.

That is a bit of a corner case. I think we can satisfactory solve this
by stating that in the case the implementation is not able to convert to
UTF-8, it should perform an octet comparison (voiding the 127 rule).
Keep in mind that we're not comparing against a user-provided string;
we're basically comparing a message against a copy of itself. I think
intermediaries that change the encoding are pretty rare and are not
likely in the future. And, in any case, implementations can solve this
by implementing proper transcoding to UTF-8 for headers.

> Like I said, I think that this topic is much more important now than it
> was when sieve first appeared, and that the use of non-ASCII in e-mail
> has grown enormously, so something needs to be said, even if it is just
> that the results are unpredictable when .... is used, for some values of
> ....

I'll make a new version soon, based on the comments we've seen so far
since the latest version. I'll add a little bit of text on the UTF-8
transcoding of headers. I don't think additional text is needed on body
comparisons.

Regards,

Stephan.





From stephan@rename-it.nl  Tue Jan 21 10:22:18 2014
Return-Path: <stephan@rename-it.nl>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB44D1A0157 for <apps-discuss@ietfa.amsl.com>; Tue, 21 Jan 2014 10:22:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.34
X-Spam-Level: 
X-Spam-Status: No, score=-0.34 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RP_MATCHES_RCVD=-0.535] 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 GQCfelvqRxdQ for <apps-discuss@ietfa.amsl.com>; Tue, 21 Jan 2014 10:22:15 -0800 (PST)
Received: from drpepper.rename-it.nl (drpepper.rename-it.nl [217.119.238.16]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED3B1A0135 for <apps-discuss@ietf.org>; Tue, 21 Jan 2014 10:22:14 -0800 (PST)
Received: from klara.student.utwente.nl ([130.89.162.218]:59757 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 <stephan@rename-it.nl>) id 1W5fxk-0002mJ-Af; Tue, 21 Jan 2014 19:22:14 +0100
Message-ID: <52DEBAD1.6000807@rename-it.nl>
Date: Tue, 21 Jan 2014 19:22:09 +0100
From: Stephan Bosch <stephan@rename-it.nl>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
References: <52D3A2C8.5030807@rename-it.nl> <01P33JH6T0LO0000AS@mauve.mrochek.com> <CAL0qLwY+pejVBVOmz_PMRF_0ORaNVrOmzB4_SVYVnw+dtC0QQA@mail.gmail.com> <20140114085709.GA21460@gulbrandsen.priv.no> <52D50F3A.8040206@rename-it.nl> <20140114112403.GA24989@gulbrandsen.priv.no>
In-Reply-To: <20140114112403.GA24989@gulbrandsen.priv.no>
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
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Review of 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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Jan 2014 18:22:19 -0000

Hi Arnt,

On 1/14/2014 12:24 PM, Arnt Gulbrandsen wrote:
> On Tue, Jan 14, 2014 at 11:19:38AM +0100, Stephan Bosch wrote:
>> There are two aspects to this problem.
>>
>> First, this example is flawed. The duplicate test has a side effect:
>> apart from testing for a duplicate it also records the identifier
>> (in the bare case the Message-ID) for comparison in subsequent
>> deliveries. So, if the test is not evaluated, the identifier is
>> never recorded.
> Good point. So you might want to point out that this test has to go
> first, then. Unless you want to assume that most reader are smarter
> than I am, which I concede is a possibility.

Ok.

>> The second aspect is a bigger issue. It is indeed uncertain which
>> copy arrives first: ...
> The only way I can think of is to use an action instead of a test.
>
>   require ["fileinto", "envelope", "duplicate"];
>   merge-duplicates;
>   if address :is "to" "dovecot@dovecot.org" {
>     fileinto "Dovecot-list";
>   } elsif envelope :is "from" "owner-cipe-l@inka.de" {
>     fileinto "lists.cipe";
>   } elsif anyof (header :contains "X-listname" "lugog@cip.rz.fh-offenburg.de",
>                  header :contains "List-Id" "Linux User Group Offenburg") {
>     fileinto "ml.lugog";
>   } else {
>     # The rest goes into INBOX
>     # default is "implicit keep", we do it explicitly here
>     keep;
>   }
>
> If merge-duplicates detects that the current message is a duplicate of
> an already stored message, then
>
>  - fileinto and keep act on the old copy, and copy/link that into the
>    mailbox specified by fileinto/keep
>  - discard discards this new copy and leaves the old copy as is
>  - other actions use the new copy
>  - all tests act on the new copy

I discussed this briefly with Ned.  The proposed extension is a simple
mechanism for straightforward duplicate elimination in the usual Sieve
context, which is at or around the time of final delivery. We think
eliminating duplicates at the store level, possibly by deleting
previously delivered messages and replacing them with a new version is
out of scope.

So, for your scenario a different new extension would have to be devised.

>> So, you want me to vary  a bit? :)
> Say several if you mean several, many if you mean many.
>
> Multiple is a fashionable word at the moment. Like ask as a noun.

Ok.

Regards,

Stephan.


From prvs=0091320397=johnl@iecc.com  Tue Jan 21 11:58:59 2014
Return-Path: <prvs=0091320397=johnl@iecc.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33C011A0257 for <apps-discuss@ietfa.amsl.com>; Tue, 21 Jan 2014 11:58:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.163
X-Spam-Level: 
X-Spam-Status: No, score=0.163 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, 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 CohAGmIW_Te3 for <apps-discuss@ietfa.amsl.com>; Tue, 21 Jan 2014 11:58:58 -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 9EDE61A0251 for <apps-discuss@ietf.org>; Tue, 21 Jan 2014 11:58:57 -0800 (PST)
Received: (qmail 51313 invoked from network); 21 Jan 2014 19:58:56 -0000
Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 21 Jan 2014 19:58:56 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=52ded180.xn--i8sz2z.k1401; i=johnl@user.iecc.com; bh=bJIq+t7VkQGYEqii1GiEyBXUMEjJ3tRShPZehy1itPs=; b=azkvlKiWm2X7paxx3ZbzGuukXIqJ0nAYVldMJ3cU8ou2P5v2KYoFLKq46/JXvSN7AB4Izg1aTkLeSnVgZ5RnXeoXXOmWrsWO6mQ4X9wTaeMHge+wsXstOXhjJoHMS9BNUDhzu+Y2vSBKSvvvi7KMzwNuXZk/Gn5YSCh+3IbNm6amF5dqywyPocrbhe4pesdYlUJNbgSZnNS4bvCduRqrl4L7q3Nxe0+fSuHgB8ZZ46NFkhsRWKrnQoqobRJaia6j
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=52ded180.xn--i8sz2z.k1401; olt=johnl@user.iecc.com; bh=bJIq+t7VkQGYEqii1GiEyBXUMEjJ3tRShPZehy1itPs=; b=ajqVefCpFEdrboXU+VKZnwI6PDVFgW9Kz90lK35I+6f30eGPkfTWNI4sqNwAPFul/T/3sU35JjJpekVz8Lq1pFFbQ92r6kruH+YAQme8zCVVfc6f1EnLEt1aBABAPlrLnro3UP1f+7wGGU1ms3I6QXGNOenkRwe3Y60zOknUL9Uwed4JxYWzNsp+aWdu6jEXu9yN5Pk9YndN8CY2bxGtDXO1t2MW4R8uCJRMdI8BquZLeyp3Xbk4d+p8Cd29nNYW
Date: 21 Jan 2014 19:58:33 -0000
Message-ID: <20140121195833.70257.qmail@joyce.lan>
From: "John Levine" <johnl@taugh.com>
To: apps-discuss@ietf.org
In-Reply-To: <20140110192036.17904.85697.idtracker@ietfa.amsl.com>
Organization: 
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Subject: Re: [apps-discuss] last call: draft-ietf-appsawg-rrvs-header-field-06.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Jan 2014 19:58:59 -0000

I've reviewed the changes to the -06 version and they address the
concerns I noted.  Ship it, please.

R's,
John

From ned.freed@mrochek.com  Tue Jan 21 15:12:47 2014
Return-Path: <ned.freed@mrochek.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 796941A0232 for <apps-discuss@ietfa.amsl.com>; Tue, 21 Jan 2014 15:12:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.437
X-Spam-Level: 
X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 eQ_XKf5wkJsZ for <apps-discuss@ietfa.amsl.com>; Tue, 21 Jan 2014 15:12:45 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 4A76A1A01D7 for <apps-discuss@ietf.org>; Tue, 21 Jan 2014 15:12:45 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P3F4QLM16O003DY4@mauve.mrochek.com> for apps-discuss@ietf.org; Tue, 21 Jan 2014 15:07:43 -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 <01P2SI6PLQJK0000AS@mauve.mrochek.com>; Tue, 21 Jan 2014 15:07:40 -0800 (PST)
Message-id: <01P3F4QK9Y2G0000AS@mauve.mrochek.com>
Date: Tue, 21 Jan 2014 15:00:55 -0800 (PST)
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Tue, 21 Jan 2014 19:58:33 +0000" <20140121195833.70257.qmail@joyce.lan>
References: <20140110192036.17904.85697.idtracker@ietfa.amsl.com> <20140121195833.70257.qmail@joyce.lan>
To: John Levine <johnl@taugh.com>
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] last call:	draft-ietf-appsawg-rrvs-header-field-06.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Jan 2014 23:12:47 -0000

> I've reviewed the changes to the -06 version and they address the
> concerns I noted.  Ship it, please.

I concur. This time I tried to review the document in light of
draft-farrell-perpass-attack, and I think the security considerations are
well done in that regard. (Of course this doesn't mean others will share
my opinion... And it should be interesting to see how this goes.)

				Ned

From duerst@it.aoyama.ac.jp  Tue Jan 21 19:05:46 2014
Return-Path: <duerst@it.aoyama.ac.jp>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB8EC1A0374 for <apps-discuss@ietfa.amsl.com>; Tue, 21 Jan 2014 19:05:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.926
X-Spam-Level: 
X-Spam-Status: No, score=-1.926 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yt2TUggfcdKk for <apps-discuss@ietfa.amsl.com>; Tue, 21 Jan 2014 19:05:43 -0800 (PST)
Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 562A01A0373 for <apps-discuss@ietf.org>; Tue, 21 Jan 2014 19:05:42 -0800 (PST)
Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id s0M35f2r014908; Wed, 22 Jan 2014 12:05:41 +0900
Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 01d2_8337_137e1b6a_8312_11e3_989c_001e6722eec2; Wed, 22 Jan 2014 12:05:40 +0900
Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 44498BF4D7; Wed, 22 Jan 2014 12:05:40 +0900 (JST)
Message-ID: <52DF3576.9010505@it.aoyama.ac.jp>
Date: Wed, 22 Jan 2014 12:05:26 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= <duerst@it.aoyama.ac.jp>
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: apps-discuss@ietf.org, draft-ietf-p2psip-self-tuning.all@tools.ietf.org
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Subject: [apps-discuss] [APPS-REVIEW] review of draft-ietf-p2psip-self-tuning-09
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Jan 2014 03:05:46 -0000

I have been selected as the Applications Area Review Team reviewer for=20
this draft (for background on apps-review, please see=20
http://www.apps.ietf.org/content/applications-area-review-team).

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

Document: draft-ietf-p2psip-self-tuning
Title: Self-tuning Distributed Hash Table (DHT) for REsource LOcation=20
And Discovery (RELOAD)
Reviewer: Martin J. D=C3=BCrst
Review Date: December 27, 2013
IETF Last Call Date: not yet
IESG Telechat Date: not yet

Summary: From what I have read, this draft looks like it's almost ready=20
for publication in IETF Standards Track but has a few issues that should=20
be fixed before publication. However, I have to admit that I'm not a SIP=20
expert, nor an expert in P2P systems.


Minor Issues:

Section 2, definitions of O(g(n)) and Omega(g(n)): The informal=20
definitions are fine, but there should also be a reference to a more=20
formal definition.

Definitions of "Predecessor List" and "Successor List": The former has=20
"first predecessors", whereas the later has "first *r* successors"=20
(emphasis by the reviewer). This may be an editorial issue, but it looks=20
to me like the *r* should be present for predecessors, too.

Section 3.2, bottom of page 6 and top of page 7: First, the big-O and=20
big-Omega notation makes the base of the logarithm irrelevant, so it=20
should be O(log(N)) rather than O(log2(N)), and so on. But this shows=20
that statements such as "a successor list of size O(log2(N)) makes it=20
unlikely..." are actually flawed, because both a function 0.01*log2(N)=20
and a function 100*log2(N) would be O(log2(N)) (the constant multiple is=20
mentioned in the definitions of O() and Omega()), and I'm pretty sure=20
that with the former, connectivity will be lost quite soon, whereas the=20
later is most probably heavy overkill.

The notation log2^2(N) is quite difficult to read. It's a logical=20
combination of the notations N^2 and log2(N), which are both not too=20
difficult to read, but in combination, the mental gymnastics required to=20
translate this to a 2D mathematical formula and then interpret are too=20
much. I'd strongly prefer a more functional notation, e.g.=20
square(log2(N)), which would be much more straightforward to read. This=20
would also work better together with the fact that there are parentheses=20
around the N, which wouldn't be needed in a 2D mathematical formula.

Section 6.2:
"the finger table MUST be set to max(log2(N), 16)": the finger table=20
size obviously must be integral, but log2(N) will rarely be integral,=20
and it is not clear what kind of rounding to apply. Same for the size of=20
the successor list.

Section 6.4: In "Ages[rsize/2]", is the division an integer division=20
(rounding down) or what?

Section 6.5, last paragraph: "75th percentile": This probably needs a=20
better definition. See http://en.wikipedia.org/wiki/Percentile, where it=20
says: "Definition: There is no standard definition of percentile,=20
however all definitions yield similar results when the number of=20
observations is very large.". In this draft, we will normally be in a=20
situation with very *few* observations, so a careful definition seems=20
required.

Section 7:
"This document extends the RELOAD overlay configuration document": It=20
would be good to have a reference here. Actually, I was specifically=20
asked to review this section, but I don't feel I'm able to do a good job=20
here because while I found quite a few references to "RELOAD overlay=20
configuration document *extensions*", I didn't easily find a good=20
reference to the base document.

Section 8 (security):
"In addition, as long as the amount of
    malicious peers in the overlay remains modest, the statistical
    mechanisms applied in Section 6.5 (i.e., the use of 75th percentiles)
    to process the shared estimates a peer obtains help ensuring that
    estimates that are clearly different from (i.e., larger or smaller
    than) other received estimates will not significantly influence the
    process of adapting the stabilization interval and routing table
    size."
This seems good for the overall network, but it should be mentioned that=20
this is not the case locally. If an attacker wants to e.g. isolate a=20
specific node, it should not be too difficult to generate hashes to=20
place nodes in "strategic" locations on the ring to in effect isolate=20
and detach a specific node.


Regards,    Martin.

From Claudio.Allocchio@garr.it  Wed Jan 22 01:33:27 2014
Return-Path: <Claudio.Allocchio@garr.it>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE6F1A0099 for <apps-discuss@ietfa.amsl.com>; Wed, 22 Jan 2014 01:33:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.656
X-Spam-Level: 
X-Spam-Status: No, score=-0.656 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.535, 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 o8NTnq34yMAL for <apps-discuss@ietfa.amsl.com>; Wed, 22 Jan 2014 01:33:25 -0800 (PST)
Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [193.206.158.29]) by ietfa.amsl.com (Postfix) with ESMTP id D5F8C1A007D for <apps-discuss@ietf.org>; Wed, 22 Jan 2014 01:33:24 -0800 (PST)
Received: internal info suppressed
Date: Wed, 22 Jan 2014 10:33:22 +0100 (CET)
From: Claudio Allocchio <Claudio.Allocchio@garr.it>
X-X-Sender: claudio@mac-allocchio3.garrtest.units.it
To: apps-discuss@ietf.org
Message-ID: <alpine.OSX.2.02.1401221032480.38263@mac-allocchio3.garrtest.units.it>
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=1390383203; bh=PmMlLbreI+zLGNpPxrhy5fYwsaN/zADHr5t0uKu57jU=; h=Date:From:To:Subject; b=rxomdYH3y50S41wavW/PWEkWtv/sofhBbE4aC22kiaR3yIoV/OcVa6bZujmB6MCa0 BzOI6J9n99BMm4J7rVFLe5imyF8796d39ddNU9uV80crWHoc7GMrr/uK4JEQwBgddh s+9rZk8OLvCkpYcUlg2lNPyo1OarDOGyU4hFBZWM=
Subject: [apps-discuss] Schema nit in p2psip service discovery (fwd)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Jan 2014 09:33:27 -0000

Date: Wed, 22 Jan 2014 07:14:17 +0100
From: Martin Thomson <martin.thomson@gmail.com>
To: draft-ietf-p2psip-service-discovery.authors@tools.ietf.org,
     draft-ietf-p2psip-service-discovery.chairs@tools.ietf.org,
     Claudio Allocchio <Claudio.Allocchio@garr.it>
Subject: Schema nit in p2psip service discovery

The schema seems to use a "please copy and paste this code into this
other document" pattern, which isn't really necessary.  I'm not
actually an expert in relaxNG, so I can't remember the exact way to do
this, but you can - and should - either import the base reload schema
in order to modify 'parameter', or maybe it's sufficient to simply
name it properly by setting the namespace prefix.

From Claudio.Allocchio@garr.it  Wed Jan 22 01:34:12 2014
Return-Path: <Claudio.Allocchio@garr.it>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67BAB1A0099 for <apps-discuss@ietfa.amsl.com>; Wed, 22 Jan 2014 01:34:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.544
X-Spam-Level: 
X-Spam-Status: No, score=0.544 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_35=0.6, J_CHICKENPOX_36=0.6, RP_MATCHES_RCVD=-0.535, 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 afLRJRLuBXAz for <apps-discuss@ietfa.amsl.com>; Wed, 22 Jan 2014 01:34:11 -0800 (PST)
Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [193.206.158.29]) by ietfa.amsl.com (Postfix) with ESMTP id 3F61F1A007D for <apps-discuss@ietf.org>; Wed, 22 Jan 2014 01:34:11 -0800 (PST)
Received: internal info suppressed
Date: Wed, 22 Jan 2014 10:34:05 +0100 (CET)
From: Claudio Allocchio <Claudio.Allocchio@garr.it>
X-X-Sender: claudio@mac-allocchio3.garrtest.units.it
To: apps-discuss@ietf.org
Message-ID: <alpine.OSX.2.02.1401221033270.38263@mac-allocchio3.garrtest.units.it>
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=1390383247; bh=3jdXwa9ls+we8ueRxlxEAkncxjpztfAQtvqRXd5DGr0=; h=Date:From:To:Subject; b=YWdrJH/UxgU3mq/88gdKBg5J9jEuvH5YexCrJ605CoJ2KUbx4a5dKF+8cWRu52mfP VA4W2tS3QZPLooikw7DykxwxkMUDHGWpfl4I71KFRxAM4auuDGrLro/xJMsBCK//JB 4q6MMLznbPzeZbXE29D+5TCJj295ZV7r7/tfNS4Q=
Subject: [apps-discuss] Schema comments on draft-ietf-mile-sci (fwd)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Jan 2014 09:34:12 -0000

---------- Forwarded message ----------
Date: Wed, 22 Jan 2014 07:23:17 +0100
From: Martin Thomson <martin.thomson@gmail.com>
To: draft-ietf-mile-sci.authors@tools.ietf.org,
     draft-ietf-mile-sci.chairs@tools.ietf.org,
     Claudio Allocchio <Claudio.Allocchio@garr.it>
Subject: Schema comments on draft-ietf-mile-sci

I did take a quick look at the schema.  This is a fairly big, yet simple 
schema.

At this stage, the only comments I'd be prepared to advance :

There is no need to wrap <xs:choice> with <xs:sequence> when both have
cardinality 1.  That's redundant.

schemaLocation on the import is unnecessary (and not especially useful
given that it's a URN).

use of xsd:string throughout is an anti-pattern.  xsd:token is better,
even more so if you can restrict the value-space further;
unconstrained strings can be a real burden later.  In particular,
xsd:string causes usability issues, and can lead to some major issues
with whitespace normalization.  Unless you need to carefully preserve
whitespace, I'd strongly recommend against its use.

From cabo@tzi.org  Wed Jan 22 01:56:48 2014
Return-Path: <cabo@tzi.org>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 539B81A03FB for <apps-discuss@ietfa.amsl.com>; Wed, 22 Jan 2014 01:56:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level: 
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, 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 rYBSgZ99qXOI for <apps-discuss@ietfa.amsl.com>; Wed, 22 Jan 2014 01:56:47 -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 B90C51A03F7 for <apps-discuss@ietf.org>; Wed, 22 Jan 2014 01:56:46 -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 s0M9tt81010252; Wed, 22 Jan 2014 10:55:55 +0100 (CET)
Received: from [192.168.217.105] (p54891FF1.dip0.t-ipconnect.de [84.137.31.241]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 75E2D73F; Wed, 22 Jan 2014 10:55:54 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
Content-Type: text/plain; charset=windows-1252
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <alpine.OSX.2.02.1401221032480.38263@mac-allocchio3.garrtest.units.it>
Date: Wed, 22 Jan 2014 10:55:52 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <7655635F-2EEC-4693-AA61-E37FF855CB87@tzi.org>
References: <alpine.OSX.2.02.1401221032480.38263@mac-allocchio3.garrtest.units.it>
To: Claudio Allocchio <Claudio.Allocchio@garr.it>
X-Mailer: Apple Mail (2.1827)
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Schema nit in p2psip service discovery (fwd)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Jan 2014 09:56:48 -0000

On 22 Jan 2014, at 10:33, Claudio Allocchio <Claudio.Allocchio@garr.it> =
wrote:

> The schema seems to use a "please copy and paste this code into this
> other document" pattern, which isn't really necessary.  I'm not
> actually an expert in relaxNG, so I can't remember the exact way to do
> this, but you can - and should - either import the base reload schema
> in order to modify 'parameter', or maybe it's sufficient to simply
> name it properly by setting the namespace prefix.

It seems to me that the schema extension is fine (haven=92t thrown tools =
at it, though).

It is all of:

   namespace redir =3D "urn:ietf:params:xml:ns:p2p:service-discovery"

   parameter &=3D element redir:branching-factor { xsd:unsignedInt }

To make this into a complete schema, you would have to prepend a third =
line:

   include =93foo://bar/original-schema.rnc=94

(That schema doesn=92t seem to have a name; maybe it should be given =
one.)

Gr=FC=DFe, Carsten


From Claudio.Allocchio@garr.it  Wed Jan 22 03:25:55 2014
Return-Path: <Claudio.Allocchio@garr.it>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1257A1A03F8 for <apps-discuss@ietfa.amsl.com>; Wed, 22 Jan 2014 03:25:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.656
X-Spam-Level: 
X-Spam-Status: No, score=-0.656 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.535, 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 jD_VYA-JwzVB for <apps-discuss@ietfa.amsl.com>; Wed, 22 Jan 2014 03:25:51 -0800 (PST)
Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [193.206.158.29]) by ietfa.amsl.com (Postfix) with ESMTP id B477D1A00B4 for <apps-discuss@ietf.org>; Wed, 22 Jan 2014 03:25:50 -0800 (PST)
Received: internal info suppressed
Date: Wed, 22 Jan 2014 12:25:39 +0100 (CET)
From: Claudio Allocchio <Claudio.Allocchio@garr.it>
X-X-Sender: claudio@mac-allocchio3.garrtest.units.it
To: Carsten Bormann <cabo@tzi.org>, Martin Thomson <martin.thomson@gmail.com>
In-Reply-To: <7655635F-2EEC-4693-AA61-E37FF855CB87@tzi.org>
Message-ID: <alpine.OSX.2.02.1401221224250.38263@mac-allocchio3.garrtest.units.it>
References: <alpine.OSX.2.02.1401221032480.38263@mac-allocchio3.garrtest.units.it> <7655635F-2EEC-4693-AA61-E37FF855CB87@tzi.org>
User-Agent: Alpine 2.02 (OSX 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="0-541447524-1390389905=:38263"
Content-ID: <alpine.OSX.2.02.1401221225170.38263@mac-allocchio3.garrtest.units.it>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=garr.it; s=cyrus; t=1390389941; bh=w2FGBH2PLW7bPtpYYKNIythjF13A/6mtxPJiWPqKgcQ=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=sBRAI9vFzhq97Xbq6K5sNTB35DYLOUz+E1QrrkZ+uFCM4bBxRI4pJh3beNa4sV/8A bhbrrbVCmJIcQeXgMlwVx7aZDMky7qVT4c/Eq+jxINB4XM54lO1hbZBnl0DCsS+LD8 CJXwFHz9u1kn86FndQYm1VDIKeWt29yO8x7XIr4k=
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Schema nit in p2psip service discovery (fwd)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Jan 2014 11:25:55 -0000

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--0-541447524-1390389905=:38263
Content-Type: TEXT/PLAIN; CHARSET=UTF-8; FORMAT=flowed
Content-Transfer-Encoding: 8BIT
Content-ID: <alpine.OSX.2.02.1401221225171.38263@mac-allocchio3.garrtest.units.it>


On Wed, 22 Jan 2014, Carsten Bormann wrote:

> On 22 Jan 2014, at 10:33, Claudio Allocchio <Claudio.Allocchio@garr.it> wrote:

BTW: I just forwarded Martin's message, which was not sent to the whole 
list ;-)


>> The schema seems to use a "please copy and paste this code into this
>> other document" pattern, which isn't really necessary.  I'm not
>> actually an expert in relaxNG, so I can't remember the exact way to do
>> this, but you can - and should - either import the base reload schema
>> in order to modify 'parameter', or maybe it's sufficient to simply
>> name it properly by setting the namespace prefix.
>
> It seems to me that the schema extension is fine (haven’t thrown tools at it, though).
>
> It is all of:
>
>   namespace redir = "urn:ietf:params:xml:ns:p2p:service-discovery"
>
>   parameter &= element redir:branching-factor { xsd:unsignedInt }
>
> To make this into a complete schema, you would have to prepend a third line:
>
>   include “foo://bar/original-schema.rnc”
>
> (That schema doesn’t seem to have a name; maybe it should be given one.)
>
> Grüße, Carsten
>
>

------------------------------------------------------------------------------
Claudio Allocchio             G   A   R   R          Claudio.Allocchio@garr.it
                         Senior Technical Officer
tel: +39 040 3758523      Italian Academic and       G=Claudio; S=Allocchio;
fax: +39 040 3758565        Research Network         P=garr; A=garr; C=it;

            PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca
--0-541447524-1390389905=:38263--

From sm@elandsys.com  Wed Jan 22 07:47:45 2014
Return-Path: <sm@elandsys.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3A331A029C for <apps-discuss@ietfa.amsl.com>; Wed, 22 Jan 2014 07:47:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.535
X-Spam-Level: 
X-Spam-Status: No, score=-2.535 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.535] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5QxRms93LfGQ for <apps-discuss@ietfa.amsl.com>; Wed, 22 Jan 2014 07:47:44 -0800 (PST)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A7D61A0193 for <apps-discuss@ietf.org>; Wed, 22 Jan 2014 07:47:44 -0800 (PST)
Received: from SUBMAN.elandsys.com ([197.224.157.187]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s0MFlTYj019188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Jan 2014 07:47:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1390405663; bh=Foau0Fik+ZmcsMQkSVoNhtxeDRsGBAW3rxAfvPVJ+J0=; h=Date:To:From:Subject:Cc; b=NZGd8QU58aH6vOqjn0NvVLVAE7d37xRPXzmEHPJyeSFG/NPfMP3rbwv5US5/Mqzpa 44LwAnou32DrNYD8TFqX8eGGoIiK8LCwTLyIsDLb6GntGkP0F2cWezSjRa5sAExSnq XYqOU09G/qPy2DI3KYzECek/ZF/bjBAcLdc4fOcE=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1390405663; i=@elandsys.com; bh=Foau0Fik+ZmcsMQkSVoNhtxeDRsGBAW3rxAfvPVJ+J0=; h=Date:To:From:Subject:Cc; b=dkxTkf0dy/+aOJ3J5E48+x6ckwxq5rylIt3AZ32VElR99j78zMEMpWurOYQbZK3iD z7QrUgb+y0JqS5TIC2iyiIDfeOQMomAFGGnPbcpj8JYbS5Mzdmp1Zm0fsVI9lZj23d nsn30VJAOuZ9ImEO2OOo86++2JOJz2M/ux5EIZbw=
Message-Id: <6.2.5.6.2.20140122064007.0b7e6760@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Wed, 22 Jan 2014 07:32:05 -0800
To: Stephan Bosch <stephan@rename-it.nl>
From: S Moonesamy <sm+ietf@elandsys.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: apps-discuss@ietf.org
Subject: [apps-discuss] Comments on draft-ietf-appsawg-sieve-duplicate-02
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Jan 2014 15:47:46 -0000

Hi Stephan,

I have a few comments on draft-ietf-appsawg-sieve-duplicate-02.

In Section 3:

   "In its basic form, the "duplicate" test keeps track of which messages
    were seen before by this test during an earlier Sieve execution.
    Messages are identified by their message ID as contained in the
    Message-ID header."

The minimum nunber of message-id fields in a RFC 5322 message is 
zero.  A few MTAs do not add the message-id header when there isn't 
one in a message.  I'll mention it without suggesting any change as 
the "duplicate" test should work in most cases.

   "Implementations MUST prevent making any definitive modifications to
    the internal duplicate tracking list until the Sieve script execution
    finishes successfully"

It would be easier to say that implementations MUST only update the 
internal duplicate tracking list when the Sieve script execution 
finishes successfully instead of having  RFC 2119 requirement about 
preventing modifications.

   'But, irrespective of what implementation is chosen, situations in
    which the "duplicate" test erroneously yields "true" MUST be
    prevented.'

That's the same requirement as the one I quoted (implementations must 
...).  The draft mentions that there is a race condition.  I would 
leave it at that as the draft explains under which circumstances the 
condition can occur.

   'The "duplicate" test MUST only check for duplicates amongst message
    ID values encountered in previous executions of the Sieve script; it
    MUST NOT consider ID values encountered earlier in the current Sieve
    script execution as potential duplicates.  This means that all
    "duplicate" tests in a Sieve script execution, including those
    located in scripts included using the "include" [INCLUDE] extension,
    MUST always yield the same result if the arguments are identical.'

There is already a requirement where the internal tracking list is 
only updated on successful execution of the Sieve script.  I gather 
that the above is trying to cover the case where there is an 
"include" extension.  I suggest keeping the above simple by 
discussing that case and using one RFC 2119 key word for clarity.

In Section 6:

   "A flood of unique messages could cause the list of tracked message ID
    values to grow indefinitely.  Implementations SHOULD apply limits on
    the number and lifespan of entries in that list."

There is already "implementations SHOULD limit the number of entries 
..." in Section 3.  If the implementation follows that recommendation 
the list of tracked values should not grow indefinitely.

Regards,
S. Moonesamy


From eburger@standardstrack.com  Wed Jan 22 08:43:00 2014
Return-Path: <eburger@standardstrack.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE881A039D for <apps-discuss@ietfa.amsl.com>; Wed, 22 Jan 2014 08:43:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.578
X-Spam-Level: *
X-Spam-Status: No, score=1.578 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wHFarfhNk_PE for <apps-discuss@ietfa.amsl.com>; Wed, 22 Jan 2014 08:42:59 -0800 (PST)
Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.108]) by ietfa.amsl.com (Postfix) with ESMTP id 191041A0384 for <apps-discuss@ietf.org>; Wed, 22 Jan 2014 08:42:59 -0800 (PST)
Received: from ip68-100-74-215.dc.dc.cox.net ([68.100.74.215]:61081 helo=[192.168.15.104]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1) (envelope-from <eburger@standardstrack.com>) id 1W60tB-0006Ns-5L for apps-discuss@ietf.org; Wed, 22 Jan 2014 08:42:57 -0800
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Eric Burger <eburger@standardstrack.com>
In-Reply-To: <01P3F4QK9Y2G0000AS@mauve.mrochek.com>
Date: Wed, 22 Jan 2014 11:42:51 -0500
Content-Transfer-Encoding: 7bit
Message-Id: <3DBEAD11-C1D6-43CE-B4FC-BD190A0A4879@standardstrack.com>
References: <20140110192036.17904.85697.idtracker@ietfa.amsl.com> <20140121195833.70257.qmail@joyce.lan> <01P3F4QK9Y2G0000AS@mauve.mrochek.com>
To: IETF Apps Discuss <apps-discuss@ietf.org>
X-Mailer: Apple Mail (2.1827)
X-OutGoing-Spam-Status: No, score=-2.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Subject: Re: [apps-discuss] last call:	draft-ietf-appsawg-rrvs-header-field-06.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Jan 2014 16:43:00 -0000

Agreed.

On Jan 21, 2014, at 6:00 PM, Ned Freed <ned.freed@mrochek.com> wrote:

>> I've reviewed the changes to the -06 version and they address the
>> concerns I noted.  Ship it, please.
> 
> I concur. This time I tried to review the document in light of
> draft-farrell-perpass-attack, and I think the security considerations are
> well done in that regard. (Of course this doesn't mean others will share
> my opinion... And it should be interesting to see how this goes.)
> 
> 				Ned
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss


From masinter@adobe.com  Wed Jan 22 12:31:36 2014
Return-Path: <masinter@adobe.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8ECE1A0265 for <apps-discuss@ietfa.amsl.com>; Wed, 22 Jan 2014 12:31:36 -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 98569HZ861sH for <apps-discuss@ietfa.amsl.com>; Wed, 22 Jan 2014 12:31:34 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0190.outbound.protection.outlook.com [207.46.163.190]) by ietfa.amsl.com (Postfix) with ESMTP id D3D2F1A0354 for <apps-discuss@ietf.org>; Wed, 22 Jan 2014 12:31:33 -0800 (PST)
Received: from BL2PR02MB307.namprd02.prod.outlook.com (10.141.91.21) by BL2PR02MB308.namprd02.prod.outlook.com (10.141.91.24) with Microsoft SMTP Server (TLS) id 15.0.859.15; Wed, 22 Jan 2014 20:31:32 +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.0859.013; Wed, 22 Jan 2014 20:31:31 +0000
From: Larry Masinter <masinter@adobe.com>
To: Ned Freed <ned.freed@mrochek.com>
Thread-Topic: [apps-discuss] draft-ietf-appsawg-xml-mediatypes vs. JSON and BOM	and UTF-8
Thread-Index: AQHPEITLO/6Ue+XJikmXsxJV64yrQpqH8fHQ
Date: Wed, 22 Jan 2014 20:31:30 +0000
Message-ID: <3acc9b5d43754c7b976b2850e0a3da94@BL2PR02MB307.namprd02.prod.outlook.com>
References: <dc29826a2bbf48088abe51bb5de22e0d@BL2PR02MB307.namprd02.prod.outlook.com> <01P33MC6OLZM0000AS@mauve.mrochek.com>
In-Reply-To: <01P33MC6OLZM0000AS@mauve.mrochek.com>
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: 00997889E7
x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(6009001)(199002)(189002)(51704005)(85852003)(74316001)(83072002)(93516002)(90146001)(93136001)(56816005)(86362001)(15975445006)(76786001)(15202345003)(76796001)(76576001)(74366001)(69226001)(53806001)(76482001)(54356001)(74706001)(54316002)(56776001)(51856001)(46102001)(74876001)(2656002)(224313003)(81816001)(224303002)(81686001)(83322001)(4396001)(79102001)(74502001)(47446002)(65816001)(63696002)(87936001)(74662001)(31966008)(92566001)(33646001)(47736001)(49866001)(80976001)(512874002)(19580395003)(81342001)(50986001)(47976001)(87266001)(77982001)(85306002)(80022001)(59766001)(66066001)(81542001)(94316002)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR02MB308; H:BL2PR02MB307.namprd02.prod.outlook.com; CLIP:50.184.24.49; FPR:; InfoNoRecordsA:1; MX:1; LANG:en; 
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: adobe.com
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] draft-ietf-appsawg-xml-mediatypes vs. JSON and BOM	and UTF-8
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Jan 2014 20:31:36 -0000

PiA+IEl0IGNhbm5vdCBiZSByaWdodCB0aGF0IGV2ZXJ5b25lIHNwZWNpZnlpbmcgYSB0ZXh0LWJh
c2VkIG1lZGlhIHR5cGUgc2hvdWxkDQo+ID4gaGF2ZSB0byBnbyB0aHJvdWdoIHRoZSBwcm9jZXNz
IG9mIGRlY2lkaW5nLCBmb3IgdGhlbXNlbHZlcywgaW5kZXBlbmRlbnRseSwuIC4uLg0KDQoNCj4g
SXQgbWF5IG5vdCBiZSAicmlnaHQiIGJ1dCBpdCBpcyB0aGUgcmVhbGl0eSBvZiB0aGUgc2l0dWF0
aW9uLg0KDQpBZ3JlZSBpdCdzIHRoZSByZWFsaXR5Lg0KDQo+ID4gSWYgdGhlIGZ1dHVyZSBpcyBV
VEYtOCwgVVRGLTgsIFVURi04LCB0aGVuIHRoZSB0d28gZG9jdW1lbnRzIHNob3VsZCBzYXkgc28s
DQo+ID4gcmlnaHQgYXQgdGhlIGJlZ2lubmluZy4NCj4gDQo+IEkgYmVsaWV2ZSB0aGUgZnV0dXJl
IGlzIFVURi04LCBpbmNsdWRpbmcgYnV0IG5vdCBsaW1pdGVkIHRvIGl0cyB1c2UgaW4gWE1MLCBh
bmQNCj4gd2Ugc2hvdWxkIGRvIHdoYXQgd2UgY2FuIHRvIHByb21vdGUgaXQuIEJ1dCBiZWxpZWZz
IGFib3V0IHRoZSBmdXR1cmUgZG9uJ3QNCj4gbmVjZXNzYXJpbHkgYmVsb25nIGluIGFuIFJGQy4N
Cg0KV2UgaGF2ZSBtYW55IGRvY3VtZW50cyB0aGF0IGdpdmUgZ3VpZGVsaW5lcy4gDQoNCj4gTW9y
ZW92ZXIsIGlzIHRoaXMgdGhlIHJpZ2h0IHBsYWNlIGFuZCB0aGUgcmlnaHQgb3JnYW5pemF0aW9u
IHRvIG1ha2Ugc3VjaCBhDQo+IHN0YXRlbWVudCBhYm91dCBYTUw/IFRoZSBJRVRGIGRvZXNuJ3Qg
b3duIHRoZSBYTUwgc3BlY2lmaWNhdGlvbiwgdGhlIFczQyAgZG9lcy4NCj4gQW5kIHRoaXMgaXMg
YSBkb2N1bWVudCBhYm91dCBob3cgdG8gcmVnaXN0ZXIgWE1MIG1lZGlhIHR5cGVzLCBub3QgYWJv
dXQgaG93DQo+IHRvICB1c2UgWE1MLg0KDQpPcmdhbml6YXRpb246IHllcy4gV2UncmUgZ2l2aW5n
IGd1aWRlbGluZXMgZm9yIGNvbW11bmljYXRpbmcgdGV4dCB1c2luZyBNSU1FLA0KYW5kIHRoZSBp
bnRlcmFjdGlvbiBvZiB0aGUgJ2NoYXJzZXQnIHBhcmFtZXRlciBpbiB0aGUgbWV0YWRhdGEgd2l0
aCBvdGhlcg0Kc291cmNlcyBvZiBlbmNvZGluZyBpbmZvcm1hdGlvbi4NCg0KUGxhY2U6IFBhcnRs
eS4gIEd1aWRlbGluZXMgZm9yIGZ1dHVyZSB0ZXh0IG1lZGlhIHR5cGVzIGJlbG9uZyBpbiBhIE1J
TUUgQkNQLg0KDQo+IE1pbmQgeW91LCBnaXZlbiBteSBvd24gYmVsaWVmcyBJIGRvbid0IHBlcnNv
bmFsbHkgb2JqZWN0IHRvIHN1Y2ggYSBzdGF0ZW1lbnQgaWYNCj4gdGhlcmUgaXMgY29uc2Vuc3Vz
IHRvIGluY2x1ZGUgaXQuIEkganVzdCB3b25kZXIgaWYgaXQgaXMgYXBwcm9wcmlhdGUuDQoNCkFs
dGhvdWdoIHRoZSBnZW5lcmFsIHBvbGljeSBkb2Vzbid0IGJlbG9uZyBpbiBhcHBzYXdnLXhtbC1t
ZWRpYXR5cGVzLCBidXQNCkl0IHdvdWxkIGJlIGFwcHJvcHJpYXRlIHRvIGFkdmlzZSBzZW5kZXJz
IG9mIHRleHQveG1sIGFuZCBhcHBsaWNhdGlvbi94bWwNCnRvIHNlbmQgVVRGLTgsIHRvIG5vdCBp
bmNsdWRlIGEgQk9NLCB0byByZWNvbW1lbmQgd2hldGhlciBvciBub3QgdG8gdXNlDQogYSBjaGFy
c2V0PSJVVEYtOCIgcGFyYW1ldGVyLCB0byByZWNvbW1lbmQgd2hldGhlciBvciBub3QgdG8gaW5j
bHVkZQ0KYW4gaW50ZXJuYWwgY2hhcnNldCBkZWNsYXJhdGlvbiwgZXZlbiB3aGVuIHJlY2VpdmVy
cyByZWNvZ25pemUgYW5kIGludGVycHJldA0Kb3RoZXIgZW5jb2RpbmdzLg0KDQpUaGlzIGlzIGFu
IGludGVyb3BlcmFiaWxpdHkgY29uc2lkZXJhdGlvbiBmb3IgYSByZXZpc2VkIHNwZWNpZmljYXRp
b24gb2YgDQphIHdpZGVseSBkZXBsb3llZCBwcm90b2NvbCwgYmFzZWQgb24gdGhlIGJlbGllZiB0
aGF0IFVURi04IGlzIGJlY29taW5nDQpnZW5lcmFsbHkgZXZlbiBtb3JlIHRoZSBkZWZhdWx0IGlu
IHRleHQtYmFzZWQgTUlNRSB0eXBlcy4NCg0KVGhvc2Uga2luZHMgb2YgZm9yd2FyZC1pbnRlcm9w
ZXJhYmlsaXR5IHJlcXVpcmVtZW50cyBzZWVtIHRvIGJlDQpjb21tb24gaW4gcHJvdG9jb2xzLi4u
IGEgU0hPVUxEIGludHJvZHVjZXMgYSBuZXcgcG9saWN5IHRvDQpjb3JyZWN0IHBhc3QgaW50ZXJv
cGVyYWJpbGl0eSBkaWZmaWN1bHRpZXMuDQoNCkxhcnJ5DQotLQ0KaHR0cDovL2xhcnJ5Lm1hc2lu
dGVyLm5ldA0KDQoNCg0KDQogDQo=

From tony@att.com  Wed Jan 22 15:15:34 2014
Return-Path: <tony@att.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E07A11A01F6 for <apps-discuss@ietfa.amsl.com>; Wed, 22 Jan 2014 15:15:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.236
X-Spam-Level: 
X-Spam-Status: No, score=-1.236 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.535] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rDDKwUcyg5Ht for <apps-discuss@ietfa.amsl.com>; Wed, 22 Jan 2014 15:15:33 -0800 (PST)
Received: from flpi406.enaf.ffdc.sbc.com (egssmtp03.att.com [144.160.128.152]) by ietfa.amsl.com (Postfix) with ESMTP id 2ECF81A0192 for <discuss@apps.ietf.org>; Wed, 22 Jan 2014 15:15:33 -0800 (PST)
Received: from dns.maillennium.att.com (maillennium.att.com [135.25.114.99]) by egssmtp03.att.com (8.14.4/8.14.4) with ESMTP id s0MNFUJh010167 for <discuss@apps.ietf.org>; Wed, 22 Jan 2014 15:15:32 -0800
Received: from vpn-135-70-100-134.vpn.swst.att.com ([135.70.100.134]) by maillennium.att.com (mailgw1) with ESMTP id <20140122231529gw100j0cj2e>; Wed, 22 Jan 2014 23:15:30 +0000
X-Originating-IP: [135.70.100.134]
Message-ID: <52E05113.7000601@att.com>
Date: Wed, 22 Jan 2014 18:15:31 -0500
From: Tony Hansen <tony@att.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Apps-Discusssion <discuss@apps.ietf.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [apps-discuss] AppsDir review of 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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Jan 2014 23:15:35 -0000

I have been selected as the Applications Area Directorate reviewer for this draft (for background on APPSDIR, please seehttp://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-appsawg-sieve-duplicate-02.txt
Title: Sieve Email Filtering: Detecting Duplicate Deliveries
Reviewer: Tony Hansen
Review Date: January 21, 2014


This document is ready to be published.

	Tony Hansen

Major issues: none
Minor issues: none
Nits:

In section 1, paragraph 3, the second sentence below would read better if the words "based on" were changed to "using" or removed entirely:

    Duplicate messages are normally detected using the Message-ID header
    field, which is required to be unique for each message.  However, the
    "duplicate" test is flexible enough to use different criteria for
    defining what makes a message a duplicate, for example based on the
    subject line or parts of the message body.  Other applications of

giving this (after removing):

    Duplicate messages are normally detected using the Message-ID header
    field, which is required to be unique for each message.  However, the
    "duplicate" test is flexible enough to use different criteria for
    defining what makes a message a duplicate, for example the
    subject line or parts of the message body.  Other applications of

In section 3, paragraph 15, the words "an unique" should be "a unique".


From stpeter@stpeter.im  Wed Jan 22 18:38:21 2014
Return-Path: <stpeter@stpeter.im>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A83FE1A0365; Wed, 22 Jan 2014 18:38:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.837
X-Spam-Level: 
X-Spam-Status: No, score=-1.837 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_21=0.6, RP_MATCHES_RCVD=-0.535, 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 tVf5oXnmydmF; Wed, 22 Jan 2014 18:38:18 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 77AF71A01D6; Wed, 22 Jan 2014 18:38:18 -0800 (PST)
Received: from [192.168.1.6] (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 423F5400AD; Wed, 22 Jan 2014 19:38:16 -0700 (MST)
Message-ID: <52E08096.5070307@stpeter.im>
Date: Wed, 22 Jan 2014 19:38:14 -0700
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: dcrocker@bbiw.net, Apps Discuss <apps-discuss@ietf.org>,  draft-ietf-stox-presence.all@tools.ietf.org, stox@ietf.org
References: <52A94AF6.8090702@dcrocker.net> <52AB8E69.7070906@stpeter.im>
In-Reply-To: <52AB8E69.7070906@stpeter.im>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: iesg <iesg@ietf.org>
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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Jan 2014 02:38:21 -0000

Hi Dave, sorry about the delayed processing of your feedback. Life has
gotten in the way here.

Further comments and proposed text inline.

On 12/13/2013 03:47 PM, Peter Saint-Andre wrote:
> 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).

Text adjusted to read:

   One approach to helping ensure interworking between these protocols
   is to map each protocol to the abstract semantics described in
   [RFC3860]; although that is the approach taken by both [RFC3922] and
   [I-D.ietf-simple-cpim-mapping], to the best of our knowledge that
   approach has never been implemented.  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), since that is how
   existing systems solve the interworking problem.

See also http://tools.ietf.org/rfcdiff?url2=draft-ietf-stox-core-09.txt
for relevant changes to the "core" STOX document.

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

Added the following section:

2.  Intended Audience

   The documents in this series are intended for use by software
   developers who have an existing system based on one of these
   technologies (e.g., SIP), and would like to enable communication from
   that existing system to systems based on the other technology (e.g.,
   XMPP).  We assume that readers are familiar with the core
   specifications for both SIP [RFC3261] and XMPP [RFC6120], with the
   base document for this series [I-D.ietf-stox-core], and with the
   following presence-related specifications:

   o  A Presence Event Package for the Session Initiation Protocol
      [RFC3856]

   o  Presence Information Data Format (PIDF) [RFC3863]

   o  Extensible Messaging and Presence Protocol: Instant Messaging and
      Presence [RFC6121]

   o  SIP-Specific Event Notification [RFC6665]

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

See text posted above.

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

I've added sequence diagrams.

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

I've made the example descriptions a bit clearer in this regard.

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

See previous note.

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

See note above about the new Section 2.

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

Done.

>>>    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 <pres:user@domain> but who might be referenced by a
>>>    SIP or SIPS URI of the form <sip:user@domain> or <sips:user@domain>.
>>>
>>>    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.

Changed to:

   The subscription models underlying XMPP and SIP differ mainly in the
   fact that XMPP presence subscriptions are long-lived (indeed
   permanent if not explicitly cancelled, so that a subscription need
   never be refreshed during any given presence "session"), 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], so that a subscription needs to be
   explicitly refreshed if it will have the appearance of being
   permanent or even of lasting as for the duration of a presence
   "session").  This disparity has implications for the handling of
   subscription cancellations in either direction and, from the SIP
   side, subscription refreshes.

[much text snipped where we have areas of agreement]

Thanks again for the review! I'll post a revised I-D soon.

Peter


From dhc@dcrocker.net  Wed Jan 22 19:00:39 2014
Return-Path: <dhc@dcrocker.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 726031A00D9; Wed, 22 Jan 2014 19:00:39 -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 tOVvLkQXHGSW; Wed, 22 Jan 2014 19:00:37 -0800 (PST)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id B618F1A00AC; Wed, 22 Jan 2014 19:00:37 -0800 (PST)
Received: from [192.168.200.211] (rrcs-74-62-19-234.west.biz.rr.com [74.62.19.234]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id s0N30XaN005784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 22 Jan 2014 19:00:36 -0800
Message-ID: <52E085C0.5060202@dcrocker.net>
Date: Wed, 22 Jan 2014 19:00:16 -0800
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Peter Saint-Andre <stpeter@stpeter.im>, Apps Discuss <apps-discuss@ietf.org>, draft-ietf-stox-presence.all@tools.ietf.org, stox@ietf.org
References: <52A94AF6.8090702@dcrocker.net> <52AB8E69.7070906@stpeter.im> <52E08096.5070307@stpeter.im>
In-Reply-To: <52E08096.5070307@stpeter.im>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Wed, 22 Jan 2014 19:00:37 -0800 (PST)
Cc: iesg <iesg@ietf.org>
Subject: Re: [apps-discuss] [Stox] Review of:  draft-ietf-stox-presence-06
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Jan 2014 03:00:39 -0000

On 1/22/2014 6:38 PM, Peter Saint-Andre wrote:
> Text adjusted to read:
>
>     One approach to helping ensure interworking between these protocols
>     is to map each protocol to the abstract semantics described in
>     [RFC3860]; although that is the approach taken by both [RFC3922] and
>     [I-D.ietf-simple-cpim-mapping], to the best of our knowledge that
>     approach has never been implemented.  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), since that is how
>     existing systems solve the interworking problem.

wfm.



>>>     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.
>
> Added the following section:
>
> 2.  Intended Audience
>
>     The documents in this series are intended for use by software
>     developers who have an existing system based on one of these
>     technologies (e.g., SIP), and would like to enable communication from
>     that existing system to systems based on the other technology (e.g.,
>     XMPP).  We assume that readers are familiar with the core
>     specifications for both SIP [RFC3261] and XMPP [RFC6120], with the
>     base document for this series [I-D.ietf-stox-core], and with the
>     following presence-related specifications:
>
>     o  A Presence Event Package for the Session Initiation Protocol
>        [RFC3856]
>
>     o  Presence Information Data Format (PIDF) [RFC3863]
>
>     o  Extensible Messaging and Presence Protocol: Instant Messaging and
>        Presence [RFC6121]
>
>     o  SIP-Specific Event Notification [RFC6665]

Well, that's certainly clear and thorough... if onerous.  But yeah, 
probably right.




>>>>     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 <pres:user@domain> but who might be referenced by a
>>>>     SIP or SIPS URI of the form <sip:user@domain> or <sips:user@domain>.
>>>>
>>>>     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.
>
> Changed to:
>
>     The subscription models underlying XMPP and SIP differ mainly in the
>     fact that XMPP presence subscriptions are long-lived (indeed
>     permanent if not explicitly cancelled, so that a subscription need
>     never be refreshed during any given presence "session"), 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], so that a subscription needs to be
>     explicitly refreshed if it will have the appearance of being
>     permanent or even of lasting as for the duration of a presence
>     "session").  This disparity has implications for the handling of
>     subscription cancellations in either direction and, from the SIP
>     side, subscription refreshes.

wfm.

> Thanks again for the review! I'll post a revised I-D soon.

ack. tnx.

d/


-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

From odonoghue@isoc.org  Wed Jan 22 21:46:09 2014
Return-Path: <odonoghue@isoc.org>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 506D51A016D; Wed, 22 Jan 2014 21:46:09 -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, 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 vU0CQi9MSa0P; Wed, 22 Jan 2014 21:46:07 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0189.outbound.protection.outlook.com [207.46.163.189]) by ietfa.amsl.com (Postfix) with ESMTP id 31C391A003E; Wed, 22 Jan 2014 21:46:07 -0800 (PST)
Received: from kodonog-mac.local (74.214.48.55) by DM2PR06MB591.namprd06.prod.outlook.com (10.141.176.154) with Microsoft SMTP Server (TLS) id 15.0.851.15; Thu, 23 Jan 2014 05:46:05 +0000
Message-ID: <52E0AC98.9090609@isoc.org>
Date: Thu, 23 Jan 2014 00:46:00 -0500
From: Karen O'Donoghue <odonoghue@isoc.org>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: <oauth@ietf.org>, <saag@ietf.org>, <apps-discuss@ietf.org>, <json@ietf.org>
References: <52E0AB85.1070409@isoc.org>
In-Reply-To: <52E0AB85.1070409@isoc.org>
X-Forwarded-Message-Id: <52E0AB85.1070409@isoc.org>
Content-Type: multipart/alternative; boundary="------------080507020009020703000405"
X-Originating-IP: [74.214.48.55]
X-ClientProxiedBy: BLUPR03CA028.namprd03.prod.outlook.com (10.141.30.21) To DM2PR06MB591.namprd06.prod.outlook.com (10.141.176.154)
X-Forefront-PRVS: 0100732B76
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019001)(2473001)(199002)(189002)(13464003)(41574002)(56816005)(74366001)(49866001)(59896001)(80316001)(76482001)(77982001)(19580405001)(74706001)(54316002)(85306002)(19580395003)(64126003)(77096001)(56776001)(46102001)(87976001)(47976001)(80976001)(94316002)(50986001)(80022001)(4396001)(47736001)(512934002)(76786001)(92726001)(15202345003)(15975445006)(92566001)(85852003)(93136001)(81542001)(79102001)(74876001)(83072002)(63696002)(33656001)(47446002)(76796001)(69226001)(31966008)(65806001)(54356001)(65956001)(2201001)(81342001)(83506001)(81686001)(42186004)(59766001)(51856001)(84326002)(90146001)(83322001)(66066001)(53806001)(93516002)(74502001)(81816001)(74662001)(71186001)(86362001)(16236675002)(36756003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR06MB591; H:kodonog-mac.local; CLIP:74.214.48.55; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; 
X-OriginatorOrg: isoc.org
Subject: [apps-discuss] Fwd: WGLC for JWA, JWE, JWK, and JWS
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Jan 2014 05:46:09 -0000

--------------080507020009020703000405
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit


The JOSE WG has started WGLCs on the documents below. We would like to
encourage this group to review the specifications as well. You are 
welcome to
either use the issue tracker 
(http://tools.ietf.org/wg/jose/trac/report/1) or
send email to the working group. Thanks!


-------- Original Message --------
Subject: 	WGLC for JWA, JWE, JWK, and JWS
Date: 	Thu, 23 Jan 2014 00:41:25 -0500
From: 	Karen O'Donoghue <odonoghue@isoc.org>
To: 	jose@ietf.org <jose@ietf.org>



Folks,

This message initiates three week WGLCs for the four JOSE WG specifications
referenced below:

https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-algorithms/
https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-encryption/
https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-key/
https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-signature/

Please review and comment on the documents and put any issues in the
JOSE WG issue tracker. The WGLC will end on 13 February 2014.

Regards,
JOSE WG co-chairs




--------------080507020009020703000405
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    The JOSE WG has started WGLCs on the documents below. We would like
    to
    <br>
    encourage this group to review the specifications as well. You are
    welcome to
    <br>
    either use the issue tracker (<a class="moz-txt-link-freetext"
      href="http://tools.ietf.org/wg/jose/trac/report/1">http://tools.ietf.org/wg/jose/trac/report/1</a>)
    or
    <br>
    send email to the working group. Thanks!<br>
    <div class="moz-forward-container"><br>
      <br>
      -------- Original Message --------
      <table class="moz-email-headers-table" border="0" cellpadding="0"
        cellspacing="0">
        <tbody>
          <tr>
            <th align="RIGHT" valign="BASELINE" nowrap="nowrap">Subject:
            </th>
            <td>WGLC for JWA, JWE, JWK, and JWS</td>
          </tr>
          <tr>
            <th align="RIGHT" valign="BASELINE" nowrap="nowrap">Date: </th>
            <td>Thu, 23 Jan 2014 00:41:25 -0500</td>
          </tr>
          <tr>
            <th align="RIGHT" valign="BASELINE" nowrap="nowrap">From: </th>
            <td>Karen O'Donoghue <a class="moz-txt-link-rfc2396E" href="mailto:odonoghue@isoc.org">&lt;odonoghue@isoc.org&gt;</a></td>
          </tr>
          <tr>
            <th align="RIGHT" valign="BASELINE" nowrap="nowrap">To: </th>
            <td><a class="moz-txt-link-abbreviated" href="mailto:jose@ietf.org">jose@ietf.org</a> <a class="moz-txt-link-rfc2396E" href="mailto:jose@ietf.org">&lt;jose@ietf.org&gt;</a></td>
          </tr>
        </tbody>
      </table>
      <br>
      <br>
      <pre>Folks,

This message initiates three week WGLCs for the four JOSE WG specifications
referenced below:

<a class="moz-txt-link-freetext" href="https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-algorithms/">https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-algorithms/</a>
<a class="moz-txt-link-freetext" href="https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-encryption/">https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-encryption/</a>
<a class="moz-txt-link-freetext" href="https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-key/">https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-key/</a>
<a class="moz-txt-link-freetext" href="https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-signature/">https://datatracker.ietf.org/doc/draft-ietf-jose-json-web-signature/</a>

Please review and comment on the documents and put any issues in the
JOSE WG issue tracker. The WGLC will end on 13 February 2014.

Regards,
JOSE WG co-chairs

</pre>
      <br>
    </div>
    <br>
  </body>
</html>

--------------080507020009020703000405--

From 0680753764@orange.fr  Thu Jan 23 01:57:05 2014
Return-Path: <0680753764@orange.fr>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 031811A0362 for <apps-discuss@ietfa.amsl.com>; Thu, 23 Jan 2014 01:57:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.834
X-Spam-Level: 
X-Spam-Status: No, score=-1.834 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.535] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GwTive3fkgww for <apps-discuss@ietfa.amsl.com>; Thu, 23 Jan 2014 01:57:03 -0800 (PST)
Received: from smtp.smtpout.orange.fr (smtp11.smtpout.orange.fr [80.12.242.133]) by ietfa.amsl.com (Postfix) with ESMTP id 677FE1A0349 for <apps-discuss@ietf.org>; Thu, 23 Jan 2014 01:57:02 -0800 (PST)
Received: from [10.41.246.22] ([10.162.66.150]) by mwinf5d21 with ME id HMx01n00K3EX3gy03Mx1Re; Thu, 23 Jan 2014 10:57:02 +0100
From: Ferrand Julien <0680753764@orange.fr>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
Message-Id: <04901A8A-9CCF-44DA-867D-60F8A79B7433@orange.fr>
Date: Thu, 23 Jan 2014 10:57:01 +0100
To: "apps-discuss@ietf.org" <apps-discuss@ietf.org>
X-Mailer: iPad Mail (11B554a)
Subject: [apps-discuss] http://www.ietf.org/maillist.html
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Jan 2014 09:57:05 -0000

Envoy=C3=A9 de mon iPad=

From 0680753764@orange.fr  Thu Jan 23 02:13:13 2014
Return-Path: <0680753764@orange.fr>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 673FE1A0373 for <apps-discuss@ietfa.amsl.com>; Thu, 23 Jan 2014 02:13:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.834
X-Spam-Level: 
X-Spam-Status: No, score=-1.834 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.535] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e95OsJ84-aXv for <apps-discuss@ietfa.amsl.com>; Thu, 23 Jan 2014 02:13:11 -0800 (PST)
Received: from smtp.smtpout.orange.fr (smtp11.smtpout.orange.fr [80.12.242.133]) by ietfa.amsl.com (Postfix) with ESMTP id C37741A0355 for <apps-discuss@ietf.org>; Thu, 23 Jan 2014 02:13:10 -0800 (PST)
Received: from [10.41.246.22] ([10.162.66.150]) by mwinf5d21 with ME id HND81n00p3EX3gy03ND9Jd; Thu, 23 Jan 2014 11:13:09 +0100
From: Ferrand Julien <0680753764@orange.fr>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
Message-Id: <404991D0-7752-4A11-901E-810B5A7C4242@orange.fr>
Date: Thu, 23 Jan 2014 11:13:09 +0100
To: "apps-discuss@ietf.org" <apps-discuss@ietf.org>
X-Mailer: iPad Mail (11B554a)
Subject: [apps-discuss] apps-discuss-request@ietf.org
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Jan 2014 10:13:13 -0000

Envoy=C3=A9 de mon iPad=

From 0680753764@orange.fr  Wed Jan 22 19:47:48 2014
Return-Path: <0680753764@orange.fr>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 505291A01A6 for <apps-discuss@ietfa.amsl.com>; Wed, 22 Jan 2014 19:47:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.834
X-Spam-Level: 
X-Spam-Status: No, score=-1.834 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.535] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mnhroiUw3q_g for <apps-discuss@ietfa.amsl.com>; Wed, 22 Jan 2014 19:47:44 -0800 (PST)
Received: from smtp.smtpout.orange.fr (smtp03.smtpout.orange.fr [80.12.242.125]) by ietfa.amsl.com (Postfix) with ESMTP id A15571A0179 for <apps-discuss@ietf.org>; Wed, 22 Jan 2014 19:47:44 -0800 (PST)
Received: from [10.24.229.176] ([10.163.23.176]) by mwinf5d38 with ME id HFnh1n00D3nxVki03Fnhbq; Thu, 23 Jan 2014 04:47:43 +0100
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Ferrand Julien <0680753764@orange.fr>
Mime-Version: 1.0 (1.0)
Date: Thu, 23 Jan 2014 04:47:41 +0100
Message-Id: <65664CF6-8F53-40C2-9320-924EC8AE53FE@orange.fr>
To: "apps-discuss@ietf.org" <apps-discuss@ietf.org>
X-Mailer: iPad Mail (11B554a)
Subject: [apps-discuss] Mailman request
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Jan 2014 10:54:50 -0000

Envoy=C3=A9 de mon iPad=

From 0680753764@orange.fr  Thu Jan 23 04:46:14 2014
Return-Path: <0680753764@orange.fr>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3176B1A02E8 for <apps-discuss@ietfa.amsl.com>; Thu, 23 Jan 2014 04:46:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.834
X-Spam-Level: 
X-Spam-Status: No, score=-1.834 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.535] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hSHiAvEDEKaL for <apps-discuss@ietfa.amsl.com>; Thu, 23 Jan 2014 04:46:12 -0800 (PST)
Received: from smtp.smtpout.orange.fr (smtp11.smtpout.orange.fr [80.12.242.133]) by ietfa.amsl.com (Postfix) with ESMTP id 96C541A0171 for <apps-discuss@ietf.org>; Thu, 23 Jan 2014 04:46:12 -0800 (PST)
Received: from [10.41.246.22] ([10.162.66.150]) by mwinf5d21 with ME id HQmA1n00Y3EX3gy03QmBZ1; Thu, 23 Jan 2014 13:46:11 +0100
From: Ferrand Julien <0680753764@orange.fr>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
Message-Id: <60AD6530-2E2C-46AB-800C-C0F8DA4B8CCC@orange.fr>
Date: Thu, 23 Jan 2014 13:46:11 +0100
To: "apps-discuss@ietf.org" <apps-discuss@ietf.org>
X-Mailer: iPad Mail (11B554a)
Subject: [apps-discuss] Plant food palace
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Jan 2014 12:46:14 -0000

Envoy=C3=A9 de mon iPad=

From jtrentadams@gmail.com  Thu Jan 23 08:57:30 2014
Return-Path: <jtrentadams@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42B861A0098 for <apps-discuss@ietfa.amsl.com>; Thu, 23 Jan 2014 08:57:30 -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 Wj-3mUNHzqQI for <apps-discuss@ietfa.amsl.com>; Thu, 23 Jan 2014 08:57:26 -0800 (PST)
Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 3BECD1A0041 for <apps-discuss@ietf.org>; Thu, 23 Jan 2014 08:57:26 -0800 (PST)
Received: by mail-ie0-f176.google.com with SMTP id tp5so1440144ieb.21 for <apps-discuss@ietf.org>; Thu, 23 Jan 2014 08:57:25 -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=Vfot7N1M4TzqLw6LxNXRZNOC3l3lWn0odITfpxBLrqk=; b=QZ0dPxGXGu6GXtrsrkmZi2UQyGuVAdpAjkgKsui+odeE6+V95p/u+jp9tlA3QhcV5g aX55Zvug4xuewVlvCeM1s1b45NRDyKTsOpG/cxLAlZ1irhplcOiS4ARkStO48jWFKpaQ 9RENQhudKk4lV4OwzMDtT8Ou9yABUUNv+jHxCp2EX/64kjy66GK4eBCo+nqaABm051DH lJNiloS8t391BsG/KsitLKxuoswrQ9iP0+Uy6kmVWin7mggfeQplbMRUmDuWtcApTDHx WMAR5a/icdVWWzbHNfDbEfMG0U4J4SkjUjMQKUoTsvE1GWpk2cegquvHyqOe0Zs+qViI gYSw==
X-Received: by 10.42.4.201 with SMTP id 9mr2538561ict.57.1390496245353; Thu, 23 Jan 2014 08:57:25 -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 fk5sm191812igb.9.2014.01.23.08.57.24 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 23 Jan 2014 08:57:24 -0800 (PST)
Message-ID: <52E149F4.1080309@gmail.com>
Date: Thu, 23 Jan 2014 09:57:24 -0700
From: "J. Trent Adams" <jtrentadams@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <20140110192036.17904.85697.idtracker@ietfa.amsl.com> <20140121195833.70257.qmail@joyce.lan> <01P3F4QK9Y2G0000AS@mauve.mrochek.com> <3DBEAD11-C1D6-43CE-B4FC-BD190A0A4879@standardstrack.com>
In-Reply-To: <3DBEAD11-C1D6-43CE-B4FC-BD190A0A4879@standardstrack.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [apps-discuss] last call: draft-ietf-appsawg-rrvs-header-field-06.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Jan 2014 16:57:30 -0000

All -

As the document shepherd, I  compared the -05 and -06 versions, guided
by the comments sent to the discussion list, and confirmed that the
issues raised appear to have been effectively addressed.  I also noted
that the IANA considerations issues that I had identified in the
previous writeup have also been corrected.

I have updated the shepherd's writeup within the data tracker to reflect
the current state of the document:

https://datatracker.ietf.org/doc/draft-ietf-appsawg-rrvs-header-field/shepherdwriteup/

At this time, it is my opinion that the document is ready to be moved
forward.

Thanks,
Trent


On 1/22/14 9:42 AM, Eric Burger wrote:
> Agreed.
>
> On Jan 21, 2014, at 6:00 PM, Ned Freed <ned.freed@mrochek.com> wrote:
>
>>> I've reviewed the changes to the -06 version and they address the
>>> concerns I noted.  Ship it, please.
>> I concur. This time I tried to review the document in light of
>> draft-farrell-perpass-attack, and I think the security considerations are
>> well done in that regard. (Of course this doesn't mean others will share
>> my opinion... And it should be interesting to see how this goes.)
>>
>> 				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

-- 
J. Trent Adams

Profile: http://www.mediaslate.org/jtrentadams/
LinkedIN: http://www.linkedin.com/in/jtrentadams
Twitter: http://twitter.com/jtrentadams


From internet-drafts@ietf.org  Thu Jan 23 10:15:37 2014
Return-Path: <internet-drafts@ietf.org>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 403271A006B; Thu, 23 Jan 2014 10:15:37 -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 NAMxi_rBR8xP; Thu, 23 Jan 2014 10:15:30 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5760D1A0024; Thu, 23 Jan 2014 10:15: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.90.p2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140123181524.15533.65684.idtracker@ietfa.amsl.com>
Date: Thu, 23 Jan 2014 10:15:24 -0800
Cc: apps-discuss@ietf.org
Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-acct-uri-07.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Jan 2014 18:15:37 -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 'acct' URI Scheme
        Author          : Peter Saint-Andre
	Filename        : draft-ietf-appsawg-acct-uri-07.txt
	Pages           : 8
	Date            : 2014-01-23

Abstract:
   This document defines the 'acct' Uniform Resource Identifier (URI)
   scheme as a way to identify a user's account at a service provider,
   irrespective of the particular protocols that can be used to interact
   with the account.


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

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

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-acct-uri-07


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

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


From stpeter@stpeter.im  Thu Jan 23 10:18:49 2014
Return-Path: <stpeter@stpeter.im>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 681B81A0024 for <apps-discuss@ietfa.amsl.com>; Thu, 23 Jan 2014 10:18:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.437
X-Spam-Level: 
X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 jtgEipsfjWQe for <apps-discuss@ietfa.amsl.com>; Thu, 23 Jan 2014 10:18:42 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id A028B1A01CD for <apps-discuss@ietf.org>; Thu, 23 Jan 2014 10:18:42 -0800 (PST)
Received: from [10.0.0.10] (unknown [24.8.129.242]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 993C2400AD; Thu, 23 Jan 2014 11:18:41 -0700 (MST)
Message-ID: <52E15D00.1000705@stpeter.im>
Date: Thu, 23 Jan 2014 11:18:40 -0700
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <20140123181524.15533.65684.idtracker@ietfa.amsl.com>
In-Reply-To: <20140123181524.15533.65684.idtracker@ietfa.amsl.com>
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-acct-uri-07.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Jan 2014 18:18:49 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Just updating the references...

On 01/23/2014 11:15 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 'acct' URI Scheme Author          : Peter
> Saint-Andre Filename        : draft-ietf-appsawg-acct-uri-07.txt 
> Pages           : 8 Date            : 2014-01-23
> 
> Abstract: This document defines the 'acct' Uniform Resource
> Identifier (URI) scheme as a way to identify a user's account at a
> service provider, irrespective of the particular protocols that can
> be used to interact with the account.
> 
> 
> The IETF datatracker status page for this draft is: 
> https://datatracker.ietf.org/doc/draft-ietf-appsawg-acct-uri/
> 
> There's also a htmlized version available at: 
> http://tools.ietf.org/html/draft-ietf-appsawg-acct-uri-07
> 
> A diff from the previous version is available at: 
> http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-acct-uri-07
> 
> 
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at: 
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________ apps-discuss
> mailing list apps-discuss@ietf.org 
> https://www.ietf.org/mailman/listinfo/apps-discuss
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJS4V0AAAoJEOoGpJErxa2pZe4P/35tGFOAmPa/f1/ihO9ssiM+
//0EfEbVhCFqlGBp0Kyevr7PY1R9Y4ApzJy7G/wGOrLzPFE6qCImnVhX9zHTzqOE
zLMn+2OyRvuK7CW1RFEHX+GKkHONMoT/KgHFvdLr1BqfrYdKSm9ubpN+hZd/D9eQ
ji7blNVPzyk3BIEATWFCKnDV43PmzgLuSaYTWiwsJwMffwbPxzHmUh0s0dCZKyoc
lQ64uEBE/jvJHtoyJaSj2Yppd6So+uS9zZUNBbsHg0Mycj2nIVshAOoBD3ZYylpA
+SzsohDH/YHodulSAYUzMdK923CBT/ZVO1CfPseVA3gBs6aMY9FTwKgMHkMdMHXl
mVxy2pC1U6XzHbwQzudFFw2QweAst38JFWZgWpYC+5UWLsuqLh3UEewjR7TARERG
jIB9XeD5IfkZQcg8/+OjeQnH0lE9WDd+RaYrzeC7APo0FAz7MMr70+LtEWLPfPnN
VqfQYcnF11uA1NrX7ow0FUiZWHFi7Mk+x3wWzziZ4svX2nD+HZuw+V4xQE5gdhjw
7jrxEfSBUgxmpQ3KHYVyjQ/HNxwiBpI/1yUra87zMUcfEYsem/auSOQenzlUSKw2
SvTiYDevdjF6IS/ZKxq23ye8dpiS0tn8d2LWkrIRv4FiHlpc5MpOdIxoUEl+wfPr
oOjOe49f3AJF39gAI9iT
=MyPR
-----END PGP SIGNATURE-----

From ned.freed@mrochek.com  Thu Jan 23 12:22:24 2014
Return-Path: <ned.freed@mrochek.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63B011A012B for <apps-discuss@ietfa.amsl.com>; Thu, 23 Jan 2014 12:22:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.437
X-Spam-Level: 
X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 2YMxIN6AEKGH for <apps-discuss@ietfa.amsl.com>; Thu, 23 Jan 2014 12:22:22 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 469371A0049 for <apps-discuss@ietf.org>; Thu, 23 Jan 2014 12:22:22 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P3HRD0RADC003J9E@mauve.mrochek.com> for apps-discuss@ietf.org; Thu, 23 Jan 2014 12:17:18 -0800 (PST)
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=iso-8859-1; Format=flowed
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P2SI6PLQJK0000AS@mauve.mrochek.com>; Thu, 23 Jan 2014 12:17:16 -0800 (PST)
Message-id: <01P3HRCZFWP00000AS@mauve.mrochek.com>
Date: Thu, 23 Jan 2014 11:43:48 -0800 (PST)
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Wed, 22 Jan 2014 07:32:05 -0800" <6.2.5.6.2.20140122064007.0b7e6760@elandnews.com>
References: <6.2.5.6.2.20140122064007.0b7e6760@elandnews.com>
To: S Moonesamy <sm+ietf@elandsys.com>
Cc: Stephan Bosch <stephan@rename-it.nl>, apps-discuss@ietf.org
Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-sieve-duplicate-02
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Jan 2014 20:22:24 -0000

> Hi Stephan,

> I have a few comments on draft-ietf-appsawg-sieve-duplicate-02.

> In Section 3:

>    "In its basic form, the "duplicate" test keeps track of which messages
>     were seen before by this test during an earlier Sieve execution.
>     Messages are identified by their message ID as contained in the
>     Message-ID header."

> The minimum nunber of message-id fields in a RFC 5322 message is
> zero.  A few MTAs do not add the message-id header when there isn't
> one in a message.  I'll mention it without suggesting any change as
> the "duplicate" test should work in most cases.

Also note that this text is talking about the "basic form".

>    "Implementations MUST prevent making any definitive modifications to
>     the internal duplicate tracking list until the Sieve script execution
>     finishes successfully"

> It would be easier to say that implementations MUST only update the
> internal duplicate tracking list when the Sieve script execution
> finishes successfully instead of having  RFC 2119 requirement about
> preventing modifications.

This seems like a reasonable change to me.

>    'But, irrespective of what implementation is chosen, situations in
>     which the "duplicate" test erroneously yields "true" MUST be
>     prevented.'

> That's the same requirement as the one I quoted (implementations must
> ...).  The draft mentions that there is a race condition.  I would
> leave it at that as the draft explains under which circumstances the
> condition can occur.

Not necessarily. We have no way of knowing what way people will implement 
things, so stating the more general requirement is helpful.

>    'The "duplicate" test MUST only check for duplicates amongst message
>     ID values encountered in previous executions of the Sieve script; it
>     MUST NOT consider ID values encountered earlier in the current Sieve
>     script execution as potential duplicates.  This means that all
>     "duplicate" tests in a Sieve script execution, including those
>     located in scripts included using the "include" [INCLUDE] extension,
>     MUST always yield the same result if the arguments are identical.'

> There is already a requirement where the internal tracking list is
> only updated on successful execution of the Sieve script.  I gather
> that the above is trying to cover the case where there is an
> "include" extension.  I suggest keeping the above simple by
> discussing that case and using one RFC 2119 key word for clarity.

Updating the internal tracking list isn't the only thing that may be going on.
There could be caching involved as well, and it's important that cacching not
generate a match.

And it is not just the include case. Just as one counterexample, sieves can be
and often are built up from templates that result in tests of all kinds being
repeated without any use of the include extension.

> In Section 6:

>    "A flood of unique messages could cause the list of tracked message ID
>     values to grow indefinitely.  Implementations SHOULD apply limits on
>     the number and lifespan of entries in that list."

> There is already "implementations SHOULD limit the number of entries
> ..." in Section 3.  If the implementation follows that recommendation
> the list of tracked values should not grow indefinitely.

I agree that this one is redundant.

				Ned

From sm@elandsys.com  Thu Jan 23 12:58:57 2014
Return-Path: <sm@elandsys.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D5F81A01B3 for <apps-discuss@ietfa.amsl.com>; Thu, 23 Jan 2014 12:58:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.325
X-Spam-Level: 
X-Spam-Status: No, score=-2.325 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.535, T_DKIM_INVALID=0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9ogYPzubMNU for <apps-discuss@ietfa.amsl.com>; Thu, 23 Jan 2014 12:58:56 -0800 (PST)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 23E791A0161 for <apps-discuss@ietf.org>; Thu, 23 Jan 2014 12:58:56 -0800 (PST)
Received: from SUBMAN.elandsys.com ([197.224.147.146]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id s0NKwfwZ003468 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Jan 2014 12:58:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1390510734; bh=vrCrEzsvNifbKDn2+PGErqkZD7vAE715dQqSDPwPOrM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=PSSYjeKx1YCkeGsnXXjm/giMY51S1Hw+Ee49/dRa+j2OxvYrlUnJ26C9X6OFUAYUq ZRtAf++TosxkB3i4YKLqtiSSdkg9TqtDdngHcIN5F5VWoTjH3AwVAOXEZ5uf+yZmzc BudkfayokMgL5Ati6SeCwJljm7RQIn4BfN5oi6CM=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1390510734; i=@elandsys.com; bh=vrCrEzsvNifbKDn2+PGErqkZD7vAE715dQqSDPwPOrM=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=qoT9jmBFIQe1icnihUxqUzB3AbKkxZiL56KDh5H9/shhGEJuAruclrByNSzaQ4eIg GSxIs9ZPVMeByQ/sPrKRPH4auJIMkYwOfy+R8CkAbaKT6PUCbFj9gZ2MEhLU+rNhqx bgQkrKcZ7MrDVX0+l5qcThk3zxAYFUwHCE/eGaIA=
Message-Id: <6.2.5.6.2.20140123123112.0ab99500@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Thu, 23 Jan 2014 12:41:46 -0800
To: Ned Freed <ned.freed@mrochek.com>
From: S Moonesamy <sm+ietf@elandsys.com>
In-Reply-To: <01P3HRCZFWP00000AS@mauve.mrochek.com>
References: <6.2.5.6.2.20140122064007.0b7e6760@elandnews.com> <01P3HRCZFWP00000AS@mauve.mrochek.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: Stephan Bosch <stephan@rename-it.nl>, apps-discuss@ietf.org
Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-sieve-duplicate-02
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Jan 2014 20:58:57 -0000

Hi Ned,
At 11:43 23-01-2014, Ned Freed wrote:
>Also note that this text is talking about the "basic form".

Ok.

>Not necessarily. We have no way of knowing what way people will 
>implement things, so stating the more general requirement is helpful.

Ok.

>And it is not just the include case. Just as one counterexample, sieves can be
>and often are built up from templates that result in tests of all kinds being
>repeated without any use of the include extension.

Thanks for the explanation.  I am okay with the current text.

Regards,
S. Moonesamy 


From rjsparks@nostrum.com  Thu Jan 23 14:34:52 2014
Return-Path: <rjsparks@nostrum.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D36B1A035C for <apps-discuss@ietfa.amsl.com>; Thu, 23 Jan 2014 14:34:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level: 
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] 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 tFKUIlEUm_Bb for <apps-discuss@ietfa.amsl.com>; Thu, 23 Jan 2014 14:34:49 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id D7A101A023D for <apps-discuss@ietf.org>; Thu, 23 Jan 2014 14:34:48 -0800 (PST)
Received: from unnumerable.local (pool-173-71-10-88.dllstx.fios.verizon.net [173.71.10.88]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id s0NMYfqD075127 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK); Thu, 23 Jan 2014 16:34:42 -0600 (CST) (envelope-from rjsparks@nostrum.com)
Message-ID: <52E19901.4020705@nostrum.com>
Date: Thu, 23 Jan 2014 16:34:41 -0600
From: Robert Sparks <rjsparks@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: IETF Apps Discuss <apps-discuss@ietf.org>, "Murray S. Kucherawy" <superuser@gmail.com>, draft-ietf-appsawg-sieve-duplicate@tools.ietf.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (shaman.nostrum.com: 173.71.10.88 is authenticated by a trusted mechanism)
Subject: [apps-discuss] Suggestions for draft-ietf-appsawg-sieve-duplicate-02
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Jan 2014 22:34:52 -0000

I was asked to take a look at draft-ietf-appsawg-sieve-duplicate-02.

I haven't been following the list discussion, but I skimmed it briefly 
and I don't _think_ any of the following are duplicate or already 
discussed. Apologies if that's wrong.

1) The draft suggests a server protect itself from large :seconds 
arguments by providing a maximum limit. Should it also suggest a limit 
on how long a string it would accept from a :header, a :uniqueid, or a 
:handle (especially given that the strings might come from using the 
variables extension)?

2) Should the draft say anything about potential interaction with 
duplicate suppression in already deployed systems (such as what's 
described in the first entry at 
<http://cyrusimap.web.cmu.edu/mediawiki/index.php/FAQ>?

3) Comparison of the values taken from :header is assumed to be bitwise 
(though case insensitive). Should that be made explicit? In particular, 
you're not expecting a duplicate check on :header "Foo" to treat 
messages with
Foo: a=one-thing; b=the-other
and
Foo: b=the-other; a=one-thing
as duplicates.

4) (minor, editorial) At the beginning of the description, I suggest 
adding "by default" to "Messages are identified by their message ID as 
contained in the Message-ID header".

5) (minor, editorial) It might make implementation less error prone to 
not use "message ID" at all, but say something like "Messages are 
identified by a 'seen' value computed from the message, which defaults 
to the contents of the Message-ID header. That would lead to sentences 
like "The 'duplicate' test MUST only check for duplicates amongst 'seen' 
values encountered in previous executions of the Sieve script; it MUST 
NOT consider 'seen' values encountered earlier in the current Sieve 
script execution as potential duplicates.

6) How did the group arrive at 7 days as the default "deemed to be 
appropriate"? (I don't particularly disagree with the number, but can't 
really support it either - can the document say why it was chosen and 
when a server might choose a different default?)

7) I would expect a sieve script writer to be surprised by one 
consequence of the duplicate test comparison happening independent from 
the source of the value. If there were two rules, one trying to look for 
duplicates based on the "Foo" header and one on the "Bar" header, and a 
pair of messages arrived, one containing
Foo: a
and the other
Bar: a
the second will be identified as a duplicate.
If that's not what the writer wanted, they can use :handle to straighten 
it out, but it's not immediately obvious that they need to.
Could a note be added pointing them at using :handle for cases like this?

Hope this helps,

RjS

From ned.freed@mrochek.com  Thu Jan 23 19:32:21 2014
Return-Path: <ned.freed@mrochek.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A05E1A0043 for <apps-discuss@ietfa.amsl.com>; Thu, 23 Jan 2014 19:32:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.845
X-Spam-Level: 
X-Spam-Status: No, score=-0.845 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, RP_MATCHES_RCVD=-0.535, 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 K2v8n7Zwv_nu for <apps-discuss@ietfa.amsl.com>; Thu, 23 Jan 2014 19:32:19 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id B79941A0014 for <apps-discuss@ietf.org>; Thu, 23 Jan 2014 19:32:19 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P3I6E3M8RK002PFE@mauve.mrochek.com> for apps-discuss@ietf.org; Thu, 23 Jan 2014 19:27: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 <01P2SI6PLQJK0000AS@mauve.mrochek.com>; Thu, 23 Jan 2014 19:27:14 -0800 (PST)
Message-id: <01P3I6E26IRG0000AS@mauve.mrochek.com>
Date: Thu, 23 Jan 2014 14:18:04 -0800 (PST)
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Tue, 21 Jan 2014 17:18:09 +0000" <026d01cf16ce$bb20d980$4001a8c0@gateway.2wire.net>
References: <52D3A2C8.5030807@rename-it.nl> <01P33JH6T0LO0000AS@mauve.mrochek.com> <CAL0qLwY+pejVBVOmz_PMRF_0ORaNVrOmzB4_SVYVnw+dtC0QQA@mail.gmail.com> <20140114085709.GA21460@gulbrandsen.priv.no> <52D50F3A.8040206@rename-it.nl> <026d01cf16ce$bb20d980$4001a8c0@gateway.2wire.net>
To: "t.petch" <ietfc@btconnect.com>
Cc: Stephan Bosch <stephan@rename-it.nl>, apps-discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Review of 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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Jan 2014 03:32:21 -0000

> I previously raised the issue of i18n, or Normalisation, which I still
> think needs more attention in this I-D.

I strongly disagree. The fact is Sieve has a well defined i18n model and it is
neither necessary nor appropriate to reiterate it in this document.

> This I-D allows comparisons of the message body while RFC5228, as far as
> I can see, only covers the treatment of strings in the headers (s.2.7.2)

You're looking at the wrong document. The Sieve body test and associated
extensions are specified in RFC 5173. And given that people are now complaining
about redundant text in this document, I don't think reitering how the body
extension, variables, or anything else in Sieve handles i18n matters in this
document is a good idea.

> So if the body of a message is in base64, then is the comparison based
> on

> SGVsbG8gTWFuYXYsCgpZb3Ugd3JvdGU6Cgo+IEkgaGF2ZSBiZWVu

> or

> Hello Manav ...

See Stephan's response.

> And where the implementation cannot convert a header to UTF8, then
> RFC5228 treats
> anything over 127 as voiding the comparison.   So when the subject line
> is

> =?utf-8?b?5Zue5aSN77yaIHByb3Bvc2VkIGRyYWZ0cyBmb3IgYWxpZ25p?=
>  =?utf-8?q?ng_MPLS-TP_PSC_linear_protection_protocol_to_transport_r?=
>  =?utf-8?q?equirements?=

> does that count as being below 127? is that used or

> proposed drafts for aligning MPLS-TP PSC linear protection protocol to
> transport requirements

In the context of this draft, who cares? This draft is about detecting
duplicates. A duplicate is, you know, a duplicate. That means it has the same
content, and unless something very wierd is going on, it's going to use the
same charsets, normalizations, and so on.

Of course there can be cases where message handling differs for the two copies,
resulting in differences cropping up. Sieve is designed to handle most of
these, like body encodings, automatically.

But more exotic those are, and the tricker the duplicate mechanism you've
elected to use is, the more likely it is that you'll get a false negative.

And the reality is there are also cases where message-ids are replaced
wholesale. That breaks the most common form of duplicate testing completely.
And lots of other stuff having nothing to do with i18n will break other kinds
of checks. Not only is duplicate detection always going to be a best effort
sort of thing, the very concept of "duplicate message" has considerable slop to
it.

> I haven't got an example of messages arriving from the IETF via two
> different ISP with different encodings, but suspect that that is only a
> matter of time.

If you're talking about content-transfer-encodings, that happens all the time.
And the Sieve body extension is designed to deal with it. (Or not, if you want
test such things.)

> Like I said, I think that this topic is much more important now than it
> was when sieve first appeared, and that the use of non-ASCII in e-mail
> has grown enormously, so something needs to be said, even if it is just
> that the results are unpredictable when .... is used, for some values of
> ....

You're assuming Sieve was developed without fully considering these issues. I
can assure you that is not the case - in fact lots of time was spent working
out how Sieve handles i18n matters. And Sieve was built on top of the
comparators schem first defined for ACAP - a lot of effort when into those,
too.

Now, this is not to say there aren't some open issues. There always are
with i18n stuff. In the case of Sieve they generally have to do with
the semantics of comparators, which don't provide a convenient way
to tease out the normalization part.

The main place where this matters is regular expression tests, but there are
also cases where a normalizing set action would be handy. (We basically 
ended up punting on this; see section 4.1 of RFC 5529 for details of what
we ended up doing.) 

But as I noted above, given the intended application of the duplicate etension,
all of this stuff is far, far, far afield. If you really care about i18n issues
in Sieve, I suggest you start a discussion of those issues on the Sieve list.
Additional  extensions to deal with the remaining issues are always possible.

				Ned

From ned.freed@mrochek.com  Thu Jan 23 19:54:34 2014
Return-Path: <ned.freed@mrochek.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07B1C1A025B for <apps-discuss@ietfa.amsl.com>; Thu, 23 Jan 2014 19:54:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.845
X-Spam-Level: 
X-Spam-Status: No, score=-0.845 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, RP_MATCHES_RCVD=-0.535, 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 JLKjJLeJaYsH for <apps-discuss@ietfa.amsl.com>; Thu, 23 Jan 2014 19:54:32 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 1EBD01A02C8 for <apps-discuss@ietf.org>; Thu, 23 Jan 2014 19:54:32 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P3I75MHER4003IL2@mauve.mrochek.com> for apps-discuss@ietf.org; Thu, 23 Jan 2014 19:49:28 -0800 (PST)
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=iso-8859-1; Format=flowed
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P3HW227U740000CD@mauve.mrochek.com>; Thu, 23 Jan 2014 19:49:26 -0800 (PST)
Message-id: <01P3I75L6TC60000CD@mauve.mrochek.com>
Date: Thu, 23 Jan 2014 16:11:51 -0800 (PST)
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Thu, 23 Jan 2014 16:34:41 -0600" <52E19901.4020705@nostrum.com>
References: <52E19901.4020705@nostrum.com>
To: Robert Sparks <rjsparks@nostrum.com>
Cc: draft-ietf-appsawg-sieve-duplicate@tools.ietf.org, IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Suggestions for draft-ietf-appsawg-sieve-duplicate-02
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Jan 2014 03:54:34 -0000

> I was asked to take a look at draft-ietf-appsawg-sieve-duplicate-02.

> I haven't been following the list discussion, but I skimmed it briefly
> and I don't _think_ any of the following are duplicate or already
> discussed. Apologies if that's wrong.

> 1) The draft suggests a server protect itself from large :seconds
> arguments by providing a maximum limit. Should it also suggest a limit
> on how long a string it would accept from a :header, a :uniqueid, or a
> :handle (especially given that the strings might come from using the
> variables extension)?

In regards to :header, I note that exactly the same considerations apply to the
header and address tests as well as the addheader and deleteheader actions. Not
having text about this elsewhere doesn't appear to have been a problem. It also
means that I don't really know what limit to suggest, if any. (Our
implementation limit is 256 characters in such a field name, but that's
probably needlessly large.)

As for :uniqueid and :handle, given that any sane implementation is going to
hash the values given to thsse parameters if they are large, and the variables
extension already lets you impose some fairly drastic limits on variable size,
I really don't see much point in imposing a specific limit here, especially
since Sieve allows for reasonable implementations limits in the base
specification.

> 2) Should the draft say anything about potential interaction with
> duplicate suppression in already deployed systems (such as what's
> described in the first entry at
> <http://cyrusimap.web.cmu.edu/mediawiki/index.php/FAQ>?

I don't think it's incumbent on any document to talk about nonstandard stuff
done by particular implementations that happens to have some degree of overlap.

> 3) Comparison of the values taken from :header is assumed to be bitwise
> (though case insensitive). Should that be made explicit? In particular,
> you're not expecting a duplicate check on :header "Foo" to treat
> messages with
> Foo: a=one-thing; b=the-other
> and
> Foo: b=the-other; a=one-thing
> as duplicates.

Sorry, that's incorrect on both counts. First, the document is very clear that
the comparison is case-sensitive and you have to force the case if you want
sometihng different. From section 3:

   The tracked unique ID value MUST be matched case-sensitively,
   irrespective of whether it originates from a header or is specified
   explicitly using the ":uniqueid" argument.  To achieve case-
   insensitive behavior, the "set" command added by the "variables"
   [VARIABLES] extension can be used in combination with the ":uniqueid"
   argument to normalize the tracked unique ID value to upper or lower
   case.

Second, it's not an octet-by-octet comprison with :header - whitespace trimming
is part of the operation. Again from section 3:

   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 MUST first be trimmed from the value
   before performing the actual duplicate verification (see Section 2.2
   of RFC 5228 [SIEVE]).  Note that this also applies to the Message-ID
   header field used by the basic "duplicate" test without a ":header"
   or ":uniqueid" argument.  When the ":uniqueid" argument is used, such
   normalization concerns are the responsibility of the user.

> 4) (minor, editorial) At the beginning of the description, I suggest
> adding "by default" to "Messages are identified by their message ID as
> contained in the Message-ID header".

WFM.

> 5) (minor, editorial) It might make implementation less error prone to
> not use "message ID" at all, but say something like "Messages are
> identified by a 'seen' value computed from the message, which defaults
> to the contents of the Message-ID header. That would lead to sentences
> like "The 'duplicate' test MUST only check for duplicates amongst 'seen'
> values encountered in previous executions of the Sieve script; it MUST
> NOT consider 'seen' values encountered earlier in the current Sieve
> script execution as potential duplicates.

This doesn't sound much better to me. Or any worse, for that matter.

> 6) How did the group arrive at 7 days as the default "deemed to be
> appropriate"? (I don't particularly disagree with the number, but can't
> really support it either - can the document say why it was chosen and
> when a server might choose a different default?)

A week seems like a reasonable default. I really don't know what else
can be said about it. (I think I said as much on the list when the topic
came up.)

> 7) I would expect a sieve script writer to be surprised by one
> consequence of the duplicate test comparison happening independent from
> the source of the value. If there were two rules, one trying to look for
> duplicates based on the "Foo" header and one on the "Bar" header, and a
> pair of messages arrived, one containing
> Foo: a
> and the other
> Bar: a
> the second will be identified as a duplicate.

> If that's not what the writer wanted, they can use :handle to straighten
> it out, but it's not immediately obvious that they need to.
> Could a note be added pointing them at using :handle for cases like this?

Couldn't hurt.

				Ned

From arnt@gulbrandsen.priv.no  Fri Jan 24 01:56:18 2014
Return-Path: <arnt@gulbrandsen.priv.no>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A85341A01BF for <apps-discuss@ietfa.amsl.com>; Fri, 24 Jan 2014 01:56:18 -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 4JzuVP0zvCPC for <apps-discuss@ietfa.amsl.com>; Fri, 24 Jan 2014 01:56:16 -0800 (PST)
Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id A773D1A018D for <apps-discuss@ietf.org>; Fri, 24 Jan 2014 01:56:16 -0800 (PST)
Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 9A2C0FA0038; Fri, 24 Jan 2014 09:56:14 +0000 (UTC)
Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1390557372-16718-16717/11/10; Fri, 24 Jan 2014 09:56:12 +0000
From: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
To: apps-discuss@ietf.org
Date: Fri, 24 Jan 2014 10:56:27 +0100
User-Agent: Trojita/v0.3.96-176-g713fcbb; Qt/4.8.4; X11; Linux; Ubuntu 13.10
Mime-Version: 1.0
Message-Id: <2fccf1dc-d9c0-41d6-8a15-6e082557555c@gulbrandsen.priv.no>
In-Reply-To: <01P3I6E26IRG0000AS@mauve.mrochek.com>
References: <52D3A2C8.5030807@rename-it.nl> <01P33JH6T0LO0000AS@mauve.mrochek.com> <CAL0qLwY+pejVBVOmz_PMRF_0ORaNVrOmzB4_SVYVnw+dtC0QQA@mail.gmail.com> <20140114085709.GA21460@gulbrandsen.priv.no> <52D50F3A.8040206@rename-it.nl> <026d01cf16ce$bb20d980$4001a8c0@gateway.2wire.net> <01P3I6E26IRG0000AS@mauve.mrochek.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Subject: Re: [apps-discuss] Review of 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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Jan 2014 09:56:18 -0000

On Thursday, January 23, 2014 11:18:04 PM CEST, Ned Freed wrote:
> In the context of this draft, who cares? This draft is about detecting
> duplicates. A duplicate is, you know, a duplicate. That means 
> it has the same
> content, and unless something very wierd is going on, it's going to use 
the
> same charsets, normalizations, and so on.

The very weird thing is list managers decoding c-t-e and sometimes charset, 
adding a list-specific footer, then reencoding.

Arnt

From arnt@gulbrandsen.priv.no  Fri Jan 24 02:15:16 2014
Return-Path: <arnt@gulbrandsen.priv.no>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCE201A0226 for <apps-discuss@ietfa.amsl.com>; Fri, 24 Jan 2014 02:15:16 -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 0HhkeFOOyvgi for <apps-discuss@ietfa.amsl.com>; Fri, 24 Jan 2014 02:15:14 -0800 (PST)
Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id 3DDBB1A0218 for <apps-discuss@ietf.org>; Fri, 24 Jan 2014 02:15:14 -0800 (PST)
Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 68B01FA003D; Fri, 24 Jan 2014 10:15:12 +0000 (UTC)
Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1390558511-16718-16717/11/11; Fri, 24 Jan 2014 10:15:11 +0000
From: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
To: apps-discuss@ietf.org
Date: Fri, 24 Jan 2014 11:15:26 +0100
User-Agent: Trojita/v0.3.96-176-g713fcbb; Qt/4.8.4; X11; Linux; Ubuntu 13.10
Mime-Version: 1.0
Message-Id: <da174c51-9f27-40c7-b16e-bb89de0d9b5f@gulbrandsen.priv.no>
In-Reply-To: <2fccf1dc-d9c0-41d6-8a15-6e082557555c@gulbrandsen.priv.no>
References: <52D3A2C8.5030807@rename-it.nl> <01P33JH6T0LO0000AS@mauve.mrochek.com> <CAL0qLwY+pejVBVOmz_PMRF_0ORaNVrOmzB4_SVYVnw+dtC0QQA@mail.gmail.com> <20140114085709.GA21460@gulbrandsen.priv.no> <52D50F3A.8040206@rename-it.nl> <026d01cf16ce$bb20d980$4001a8c0@gateway.2wire.net> <01P3I6E26IRG0000AS@mauve.mrochek.com> <2fccf1dc-d9c0-41d6-8a15-6e082557555c@gulbrandsen.priv.no>
Content-Type: text/plain; charset=utf-8; format=flowed
Subject: Re: [apps-discuss] Review of 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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Jan 2014 10:15:17 -0000

I wrote:
> The very weird thing is list managers decoding c-t-e and 
> sometimes charset, adding a list-specific footer, then 
> reencoding.

Since this list has a footer, I looked at my own message's header to see 
what changed. The message I bcc'd myself has this content-type:

    Content-Type: text/plain; charset=utf-8; format=flowed

The one I got back from the list has this:

    Content-Type: text/plain; format=flowed

Arnt

From ned.freed@mrochek.com  Fri Jan 24 06:08:37 2014
Return-Path: <ned.freed@mrochek.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A93CC1A0295 for <apps-discuss@ietfa.amsl.com>; Fri, 24 Jan 2014 06:08:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.437
X-Spam-Level: 
X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 F5JHEVjvJprr for <apps-discuss@ietfa.amsl.com>; Fri, 24 Jan 2014 06:08:36 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 4CAE21A026C for <apps-discuss@ietf.org>; Fri, 24 Jan 2014 06:08:36 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P3ISLWPUJ4002Q0Q@mauve.mrochek.com> for apps-discuss@ietf.org; Fri, 24 Jan 2014 06:03:31 -0800 (PST)
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=iso-8859-1; Format=flowed
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P2SI6PLQJK0000AS@mauve.mrochek.com>; Fri, 24 Jan 2014 06:03:27 -0800 (PST)
Message-id: <01P3ISLUDI620000AS@mauve.mrochek.com>
Date: Fri, 24 Jan 2014 05:58:37 -0800 (PST)
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Fri, 24 Jan 2014 10:56:27 +0100" <2fccf1dc-d9c0-41d6-8a15-6e082557555c@gulbrandsen.priv.no>
References: <52D3A2C8.5030807@rename-it.nl> <01P33JH6T0LO0000AS@mauve.mrochek.com> <CAL0qLwY+pejVBVOmz_PMRF_0ORaNVrOmzB4_SVYVnw+dtC0QQA@mail.gmail.com> <20140114085709.GA21460@gulbrandsen.priv.no> <52D50F3A.8040206@rename-it.nl> <026d01cf16ce$bb20d980$4001a8c0@gateway.2wire.net> <01P3I6E26IRG0000AS@mauve.mrochek.com> <2fccf1dc-d9c0-41d6-8a15-6e082557555c@gulbrandsen.priv.no>
To: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Review of 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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Jan 2014 14:08:37 -0000

> On Thursday, January 23, 2014 11:18:04 PM CEST, Ned Freed wrote:
> > In the context of this draft, who cares? This draft is about detecting
> > duplicates. A duplicate is, you know, a duplicate. That means
> > it has the same
> > content, and unless something very wierd is going on, it's going to use
> the
> > same charsets, normalizations, and so on.

> The very weird thing is list managers decoding c-t-e and sometimes charset,
> adding a list-specific footer, then reencoding.

My response was in the context of header, not body, tests. Even so, your point
is well taken - duplicate applied to captured body text is not likely to be
your friend.

And these sorts of transformations are especially fun when the body is
text/html, not text/plain.

				Ned

From kurta@drkurt.com  Fri Jan 24 08:52:44 2014
Return-Path: <kurta@drkurt.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7A721A0026 for <apps-discuss@ietfa.amsl.com>; Fri, 24 Jan 2014 08:52:44 -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 Css_hmTrYEod for <apps-discuss@ietfa.amsl.com>; Fri, 24 Jan 2014 08:52:43 -0800 (PST)
Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id C46031A0016 for <apps-discuss@ietf.org>; Fri, 24 Jan 2014 08:52:42 -0800 (PST)
Received: by mail-wg0-f44.google.com with SMTP id l18so3185556wgh.11 for <apps-discuss@ietf.org>; Fri, 24 Jan 2014 08:52:41 -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:content-type; bh=hKo2PTP/nsvjcWKT7mEKwC3kfLCWau5eOjKTeB58xnY=; b=TIsBWYSuVRoJlUJmY4M8IHCTq/SVXXZhNm04n7l2U/eeGzMllAx3tlBNpue76jFri7 SbiVCrkrhAunpWuaV8/QmW58CVya59+31NnNSknzhgA06nd1eLvTLlkqknga644GOZ9w O7r2KsBbXsh6E6p0ANJkKtFwxXr2dVK6MitTU=
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:content-type; bh=hKo2PTP/nsvjcWKT7mEKwC3kfLCWau5eOjKTeB58xnY=; b=ADq1iiwBusK5P/vDguuFRzEViCzcG616vY+j2WdlROJU7G8b0GupUk/F6KVvSica7i H/8NhfPLbgjQYp3gs+3hnGD2DX2ghdtcimKOaz/sSETgpMMg/Z0yC7VIwNmtQBtP+i7B 41fDmqUEB4pmYytDqqsePBnpF4ypihTlR784LBREX/W/F7Kral6uNWdns8KBbDPoPCwU FFgbnPze/xQ/vspXMH+UBp0iBOtesjYqvvgV2v8BAHc8ih5uokTk3yWblO4Xlto1jiGe wAXvi0wws67V11gboT6Ia6ShrXBszP9M09d3UGyG8QUTgmEhCDVThm0+iw0pgEYTHOnJ 4vaA==
X-Gm-Message-State: ALoCoQm0hl7rBIj/KU9gceM+V+TBxel85VYA5hGR5myZFkPa0Io6qX4IxggUW31HyfaohhUhmeIY
MIME-Version: 1.0
X-Received: by 10.194.84.144 with SMTP id z16mr1819441wjy.23.1390582361074; Fri, 24 Jan 2014 08:52:41 -0800 (PST)
Sender: kurta@drkurt.com
Received: by 10.195.12.137 with HTTP; Fri, 24 Jan 2014 08:52:40 -0800 (PST)
In-Reply-To: <52E149F4.1080309@gmail.com>
References: <20140110192036.17904.85697.idtracker@ietfa.amsl.com> <20140121195833.70257.qmail@joyce.lan> <01P3F4QK9Y2G0000AS@mauve.mrochek.com> <3DBEAD11-C1D6-43CE-B4FC-BD190A0A4879@standardstrack.com> <52E149F4.1080309@gmail.com>
Date: Fri, 24 Jan 2014 08:52:41 -0800
X-Google-Sender-Auth: GTttIH46OHzs1JFbvwek1-GmAKo
Message-ID: <CABuGu1qZWx6Zswk7e8c80hLWy_aE53Uod-SbfX48ddGfW8qjqg@mail.gmail.com>
From: Kurt Andersen <kboth@drkurt.com>
To: IETF Apps Discuss <apps-discuss@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [apps-discuss] last call: draft-ietf-appsawg-rrvs-header-field-06.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Jan 2014 16:52:45 -0000

Looks good to me as well.

--Kurt Andersen

On Thu, Jan 23, 2014 at 8:57 AM, J. Trent Adams <jtrentadams@gmail.com> wrote:
>
> All -
>
> As the document shepherd, I  compared the -05 and -06 versions, guided
> by the comments sent to the discussion list, and confirmed that the
> issues raised appear to have been effectively addressed.  I also noted
> that the IANA considerations issues that I had identified in the
> previous writeup have also been corrected.
>
> I have updated the shepherd's writeup within the data tracker to reflect
> the current state of the document:
>
> https://datatracker.ietf.org/doc/draft-ietf-appsawg-rrvs-header-field/shepherdwriteup/
>
> At this time, it is my opinion that the document is ready to be moved
> forward.
>
> Thanks,
> Trent
>
>
> On 1/22/14 9:42 AM, Eric Burger wrote:
>> Agreed.
>>
>> On Jan 21, 2014, at 6:00 PM, Ned Freed <ned.freed@mrochek.com> wrote:
>>
>>>> I've reviewed the changes to the -06 version and they address the
>>>> concerns I noted.  Ship it, please.
>>> I concur. This time I tried to review the document in light of
>>> draft-farrell-perpass-attack, and I think the security considerations are
>>> well done in that regard. (Of course this doesn't mean others will share
>>> my opinion... And it should be interesting to see how this goes.)
>>>
>>>                              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
>
> --
> J. Trent Adams
>
> Profile: http://www.mediaslate.org/jtrentadams/
> LinkedIN: http://www.linkedin.com/in/jtrentadams
> Twitter: http://twitter.com/jtrentadams
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss

From ietfc@btconnect.com  Fri Jan 24 09:58:01 2014
Return-Path: <ietfc@btconnect.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBA731A004B for <apps-discuss@ietfa.amsl.com>; Fri, 24 Jan 2014 09:58:00 -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,  J_CHICKENPOX_15=0.6, 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 IMhlxxJpzY_w for <apps-discuss@ietfa.amsl.com>; Fri, 24 Jan 2014 09:57:58 -0800 (PST)
Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id 63BAE1A0032 for <apps-discuss@ietf.org>; Fri, 24 Jan 2014 09:57:58 -0800 (PST)
Received: from mail28-ch1-R.bigfish.com (10.43.68.236) by CH1EHSOBE007.bigfish.com (10.43.70.57) with Microsoft SMTP Server id 14.1.225.22; Fri, 24 Jan 2014 17:57:56 +0000
Received: from mail28-ch1 (localhost [127.0.0.1])	by mail28-ch1-R.bigfish.com (Postfix) with ESMTP id AD98F20016F; Fri, 24 Jan 2014 17:57:56 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.249.213; KIP:(null); UIP:(null); IPV:NLI; H:AM2PRD0710HT003.eurprd07.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -17
X-BigFish: PS-17(zzbb2dI98dI9371I542I1432I1418Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h20f7h2189h1d1ah1d2ah21bch1fc6hzz1de098h1033IL17326ah8275bh8275dh1de097h186068hz2dh2a8h5a9h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah2222h224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h2218h2216h226dh22d0h24afh2327h2336h2438h2461h2487h24ach24d7h304l1d11m1155h)
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(199002)(189002)(51704005)(24454002)(51444003)(479174003)(13464003)(377454003)(69226001)(50466002)(74706001)(53806001)(42186004)(76796001)(77096001)(47976001)(51856001)(92566001)(76482001)(74876001)(14496001)(50986001)(77156001)(33646001)(87286001)(76786001)(92726001)(87266001)(44736004)(81542001)(4396001)(47446002)(74502001)(74662001)(50226001)(84392001)(86362001)(93136001)(19580395003)(93916002)(15202345003)(93516002)(19580405001)(62966002)(87976001)(61296002)(47736001)(49866001)(77982001)(80022001)(85306002)(59766001)(83322001)(44716002)(62236002)(56816005)(85852003)(89996001)(79102001)(74366001)(15975445006)(54316002)(31966008)(90146001)(56776001)(46102001)(88136002)(23756003)(65816001)(94316002)(63696002)(47776003)(81342001)(83072002)(66066001)(80976001)(74416001)(7726001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB3PR07MB060; H:DB3PRD0210HT004.eurprd02.prod.outlook.com; CLIP:157.56.253.69; FPR:; InfoNoRecordsA:0; MX:1; LANG:en ;
Received: from mail28-ch1 (localhost.localdomain [127.0.0.1]) by mail28-ch1 (MessageSwitch) id 1390586275398037_15135; Fri, 24 Jan 2014 17:57:55 +0000 (UTC)
Received: from CH1EHSMHS006.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.231])	by mail28-ch1.bigfish.com (Postfix) with ESMTP id 5BEA844007B;	Fri, 24 Jan 2014 17:57:55 +0000 (UTC)
Received: from AM2PRD0710HT003.eurprd07.prod.outlook.com (157.56.249.213) by CH1EHSMHS006.bigfish.com (10.43.70.6) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 24 Jan 2014 17:57:55 +0000
Received: from DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) by AM2PRD0710HT003.eurprd07.prod.outlook.com (10.255.165.38) with Microsoft SMTP Server (TLS) id 14.16.395.1; Fri, 24 Jan 2014 17:57:54 +0000
Received: from DB3PRD0210HT004.eurprd02.prod.outlook.com (157.56.253.69) by DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151) with Microsoft SMTP Server (TLS) id 15.0.859.15; Fri, 24 Jan 2014 17:57:53 +0000
Message-ID: <06b901cf192d$35a0ff40$4001a8c0@gateway.2wire.net>
From: t.petch <ietfc@btconnect.com>
To: Stephan Bosch <stephan@rename-it.nl>, apps-discuss <apps-discuss@ietf.org>
References: <52D3A2C8.5030807@rename-it.nl> <01P33JH6T0LO0000AS@mauve.mrochek.com> <CAL0qLwY+pejVBVOmz_PMRF_0ORaNVrOmzB4_SVYVnw+dtC0QQA@mail.gmail.com> <20140114085709.GA21460@gulbrandsen.priv.no> <52D50F3A.8040206@rename-it.nl> <026d01cf16ce$bb20d980$4001a8c0@gateway.2wire.net> <52DEB827.9090606@rename-it.nl>
Date: Fri, 24 Jan 2014 17:52:09 +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.69]
X-ClientProxiedBy: AMSPR07CA005.eurprd07.prod.outlook.com (10.242.77.173) To DB3PR07MB060.eurprd07.prod.outlook.com (10.242.137.151)
X-Forefront-PRVS: 01018CB5B3
X-OriginatorOrg: btconnect.com
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
Subject: Re: [apps-discuss] Review of 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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Jan 2014 17:58:01 -0000

Stephan

Thanks for that - you have addressed the points I had in mind.

A separate question, hence the top post.  If this function is used by
sieve script X which is included in both sieve scripts A and B, is there
an internal duplicate tracking list for X; or two, one for A.X and
one for B.X; or ... ?

Tom Petch


----- Original Message -----
From: "Stephan Bosch" <stephan@rename-it.nl>
To: "t.petch" <ietfc@btconnect.com>; "apps-discuss"
<apps-discuss@ietf.org>
Sent: Tuesday, January 21, 2014 6:10 PM
> On 1/21/2014 6:18 PM, t.petch wrote:
> > Stephan
> >
> > I previously raised the issue of i18n, or Normalisation, which I
still
> > think needs
> > more attention in this I-D.
> >
> > This I-D allows comparisons of the message body while RFC5228, as
far as
> > I can see, only covers the treatment of strings in the headers
(s.2.7.2)
>
> The transcoding of the header content to UTF-8 is actually something I
> should mention more explicitly by referring to that section.
>
> > So if the body of a message is in base64, then is the comparison
based
> > on
> >
> > SGVsbG8gTWFuYXYsCgpZb3Ugd3JvdGU6Cgo+IEkgaGF2ZSBiZWVu
> >
> > or
> >
> > Hello Manav ...
>
> This extension does not access the message body directly. The only way
> to achieve testing against the body is putting (parts of) the message
> body in a variable. This can currently only be done using the
> extracttext extension (http://tools.ietf.org/html/rfc5703#section-7).
> The specification of extracttext states:
>
> "Servers MUST support transcoding of any textual body part into UTF-8
for use with this action. This requires decoding any transfer encoding
as well as transcoding from the indicated character set into UTF-8."
>
> The issue you raise is therefore no problem at all.
>
> The use of the extracttext extension is already mentioned in the
document.
>
>
> > And where the implementation cannot convert a header to UTF8, then
> > RFC5228 treats
> > anything over 127 as voiding the comparison.
>
> That is a bit of a corner case. I think we can satisfactory solve this
> by stating that in the case the implementation is not able to convert
to
> UTF-8, it should perform an octet comparison (voiding the 127 rule).
> Keep in mind that we're not comparing against a user-provided string;
> we're basically comparing a message against a copy of itself. I think
> intermediaries that change the encoding are pretty rare and are not
> likely in the future. And, in any case, implementations can solve this
> by implementing proper transcoding to UTF-8 for headers.
>
> > Like I said, I think that this topic is much more important now than
it
> > was when sieve first appeared, and that the use of non-ASCII in
e-mail
> > has grown enormously, so something needs to be said, even if it is
just
> > that the results are unpredictable when .... is used, for some
values of
> > ....
>
> I'll make a new version soon, based on the comments we've seen so far
> since the latest version. I'll add a little bit of text on the UTF-8
> transcoding of headers. I don't think additional text is needed on
body
> comparisons.
>
> Regards,
>
> Stephan.
>
>
>
>
>



From stephan@rename-it.nl  Fri Jan 24 12:10:47 2014
Return-Path: <stephan@rename-it.nl>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F41EE1A004E for <apps-discuss@ietfa.amsl.com>; Fri, 24 Jan 2014 12:10:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.34
X-Spam-Level: 
X-Spam-Status: No, score=-0.34 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RP_MATCHES_RCVD=-0.535] 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 Ta8v3Dzgw8ko for <apps-discuss@ietfa.amsl.com>; Fri, 24 Jan 2014 12:10:44 -0800 (PST)
Received: from drpepper.rename-it.nl (drpepper.rename-it.nl [217.119.238.16]) by ietfa.amsl.com (Postfix) with ESMTP id 768FA1A001A for <discuss@apps.ietf.org>; Fri, 24 Jan 2014 12:10:42 -0800 (PST)
Received: from klara.student.utwente.nl ([130.89.162.218]:49194 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 <stephan@rename-it.nl>) id 1W6n5J-0007Fd-2b; Fri, 24 Jan 2014 21:10:39 +0100
Message-ID: <52E2C89A.6010204@rename-it.nl>
Date: Fri, 24 Jan 2014 21:10:02 +0100
From: Stephan Bosch <stephan@rename-it.nl>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Tony Hansen <tony@att.com>, Apps-Discusssion <discuss@apps.ietf.org>
References: <52E05113.7000601@att.com>
In-Reply-To: <52E05113.7000601@att.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] AppsDir review of 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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Jan 2014 20:10:47 -0000

Hi Tony,

On 1/23/2014 12:15 AM, Tony Hansen wrote:
> I have been selected as the Applications Area Directorate reviewer for
> this draft (for background on APPSDIR, please
> seehttp://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.

Ok.

> In section 1, paragraph 3, the second sentence below would read better
> if the words "based on" were changed to "using" or removed entirely:
>
>    Duplicate messages are normally detected using the Message-ID header
>    field, which is required to be unique for each message.  However, the
>    "duplicate" test is flexible enough to use different criteria for
>    defining what makes a message a duplicate, for example based on the
>    subject line or parts of the message body.  Other applications of
>
> giving this (after removing):
>
>    Duplicate messages are normally detected using the Message-ID header
>    field, which is required to be unique for each message.  However, the
>    "duplicate" test is flexible enough to use different criteria for
>    defining what makes a message a duplicate, for example the
>    subject line or parts of the message body.  Other applications of
>
> In section 3, paragraph 15, the words "an unique" should be "a unique".

Agreed, thanks.

Regards,

Stephan.

From stephan@rename-it.nl  Fri Jan 24 12:44:50 2014
Return-Path: <stephan@rename-it.nl>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9078F1A01F0 for <apps-discuss@ietfa.amsl.com>; Fri, 24 Jan 2014 12:44:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.26
X-Spam-Level: 
X-Spam-Status: No, score=0.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_15=0.6, RP_MATCHES_RCVD=-0.535] 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 iZ5gAvL6xUHd for <apps-discuss@ietfa.amsl.com>; Fri, 24 Jan 2014 12:44:49 -0800 (PST)
Received: from drpepper.rename-it.nl (drpepper.rename-it.nl [217.119.238.16]) by ietfa.amsl.com (Postfix) with ESMTP id D74B61A01E5 for <apps-discuss@ietf.org>; Fri, 24 Jan 2014 12:44:47 -0800 (PST)
Received: from klara.student.utwente.nl ([130.89.162.218]:49945 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 <stephan@rename-it.nl>) id 1W6ncJ-0007oZ-F0; Fri, 24 Jan 2014 21:44:45 +0100
Message-ID: <52E2D098.3090506@rename-it.nl>
Date: Fri, 24 Jan 2014 21:44:08 +0100
From: Stephan Bosch <stephan@rename-it.nl>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: "t.petch" <ietfc@btconnect.com>, apps-discuss <apps-discuss@ietf.org>
References: <52D3A2C8.5030807@rename-it.nl> <01P33JH6T0LO0000AS@mauve.mrochek.com> <CAL0qLwY+pejVBVOmz_PMRF_0ORaNVrOmzB4_SVYVnw+dtC0QQA@mail.gmail.com> <20140114085709.GA21460@gulbrandsen.priv.no> <52D50F3A.8040206@rename-it.nl> <026d01cf16ce$bb20d980$4001a8c0@gateway.2wire.net> <52DEB827.9090606@rename-it.nl> <06b901cf192d$35a0ff40$4001a8c0@gateway.2wire.net>
In-Reply-To: <06b901cf192d$35a0ff40$4001a8c0@gateway.2wire.net>
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] Review of 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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Jan 2014 20:44:50 -0000

Hi Tom,

On 1/24/2014 6:52 PM, t.petch wrote:
> Stephan
>
> Thanks for that - you have addressed the points I had in mind.
>
> A separate question, hence the top post.  If this function is used by
> sieve script X which is included in both sieve scripts A and B, is there
> an internal duplicate tracking list for X; or two, one for A.X and
> one for B.X; or ... ?

First of all, this situation is not really relevant to Sieve in its
normal context: each user can have only one main active script, so
either A or B and not both. The new ImapSieve context would be an
exception, but this is out of the scope of this draft and the use of the
duplicate extension is explicitly marked as NOT RECOMMENDED for that
context.

Also, the document talks about Sieve executions and not about the
duplicate test being scoped/limited on a strictly per-script basis. A
Sieve execution is the whole act of running the main active script at
final delivery with all include actions it encounters. So, there will be
only one duplicate tracking list per user. I can add a sentence to
clarify this a little more, but I am not convinced that that is necessary.

Regards,

Stephan.



From ned.freed@mrochek.com  Fri Jan 24 13:35:16 2014
Return-Path: <ned.freed@mrochek.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E37E1A013C for <apps-discuss@ietfa.amsl.com>; Fri, 24 Jan 2014 13:35:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.437
X-Spam-Level: 
X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 9ZIc0oJXypIW for <apps-discuss@ietfa.amsl.com>; Fri, 24 Jan 2014 13:35:14 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 1A8BA1A00DE for <apps-discuss@ietf.org>; Fri, 24 Jan 2014 13:35:14 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P3J87K8SR4003K9M@mauve.mrochek.com> for apps-discuss@ietf.org; Fri, 24 Jan 2014 13:30:05 -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 <01P2SI6PLQJK0000AS@mauve.mrochek.com>; Fri, 24 Jan 2014 13:29:59 -0800 (PST)
Message-id: <01P3J87H8OWC0000AS@mauve.mrochek.com>
Date: Fri, 24 Jan 2014 11:35:34 -0800 (PST)
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Fri, 24 Jan 2014 17:52:09 +0000" <06b901cf192d$35a0ff40$4001a8c0@gateway.2wire.net>
References: <52D3A2C8.5030807@rename-it.nl> <01P33JH6T0LO0000AS@mauve.mrochek.com> <CAL0qLwY+pejVBVOmz_PMRF_0ORaNVrOmzB4_SVYVnw+dtC0QQA@mail.gmail.com> <20140114085709.GA21460@gulbrandsen.priv.no> <52D50F3A.8040206@rename-it.nl> <026d01cf16ce$bb20d980$4001a8c0@gateway.2wire.net> <52DEB827.9090606@rename-it.nl> <06b901cf192d$35a0ff40$4001a8c0@gateway.2wire.net>
To: "t.petch" <ietfc@btconnect.com>
Cc: Stephan Bosch <stephan@rename-it.nl>, apps-discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Review of 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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Jan 2014 21:35:16 -0000

> Stephan

> Thanks for that - you have addressed the points I had in mind.

> A separate question, hence the top post.  If this function is used by
> sieve script X which is included in both sieve scripts A and B, is there
> an internal duplicate tracking list for X; or two, one for A.X and
> one for B.X; or ... ?

In the case of the include extension, there's only one. This is covered
explicitly in the draft:

   The "duplicate" test MUST only check for duplicates amongst message
   ID values encountered in previous executions of the Sieve script; it
   MUST NOT consider ID values encountered earlier in the current Sieve
   script execution as potential duplicates.  This means that all
   "duplicate" tests in a Sieve script execution, including those
   located in scripts included using the "include" [INCLUDE] extension,
   MUST always yield the same result if the arguments are identical.

Note the last sentence.

If you want your included scripts to operate in a different namespace, that's
what :handle is for.

More generally, this all gets very complex in a multiple sieve-per-message
environment. There's a correct answer, one that has been arrived at
independently by multiple implementors, but since such environments are outside
our current standards, I see no reason to worry about them here.

				Ned

From ietf-secretariat-reply@ietf.org  Sat Jan 25 07:39:36 2014
Return-Path: <ietf-secretariat-reply@ietf.org>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00EED1A011E for <apps-discuss@ietfa.amsl.com>; Sat, 25 Jan 2014 07:39:36 -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 HaOhk_bChDR7 for <apps-discuss@ietfa.amsl.com>; Sat, 25 Jan 2014 07:39:35 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 170F21A0253 for <apps-discuss@ietf.org>; Sat, 25 Jan 2014 07:39:34 -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.90.p2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140125153934.5032.55933.idtracker@ietfa.amsl.com>
Date: Sat, 25 Jan 2014 07:39:34 -0800
From: IETF Secretariat <ietf-secretariat-reply@ietf.org>
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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 25 Jan 2014 15:39:36 -0000

Changed milestone "Publication requested for
draft-ietf-appsawg-rrvs-header-field", resolved as "Done".

URL: http://datatracker.ietf.org/wg/appsawg/charter/

From mnot@mnot.net  Tue Jan 28 02:34:37 2014
Return-Path: <mnot@mnot.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4017F1A0387 for <apps-discuss@ietfa.amsl.com>; Tue, 28 Jan 2014 02:34:37 -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 eBR48-wroJZG for <apps-discuss@ietfa.amsl.com>; Tue, 28 Jan 2014 02:34:35 -0800 (PST)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 8B51F1A0379 for <apps-discuss@ietf.org>; Tue, 28 Jan 2014 02:34:35 -0800 (PST)
Received: from [192.168.1.55] (unknown [118.209.40.94]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 5F6AC50A84; Tue, 28 Jan 2014 05:34:30 -0500 (EST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <CAHBU6it8+wVK6Mm3gppD-M_0YT03DgEbL82f777DUy1qMtncvA@mail.gmail.com>
Date: Tue, 28 Jan 2014 21:34:27 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: <8AAB0B1F-9D95-472D-A310-2F7335FD57F8@mnot.net>
References: <CAHBU6it8+wVK6Mm3gppD-M_0YT03DgEbL82f777DUy1qMtncvA@mail.gmail.com>
To: Tim Bray <tbray@textuality.com>
X-Mailer: Apple Mail (2.1827)
Cc: "apps-discuss@ietf.org" <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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Jan 2014 10:34:37 -0000

Hi again Tim,

See:
  https://github.com/mnot/I-D/commit/007b9b4



On 6 Dec 2013, at 5:22 pm, Tim Bray <tbray@textuality.com> 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.

I like the latter, and have tweaked (since the above commit) to "URI =
Design and Ownership" -- sound good?

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

See how it looks now.

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

I think this is covered by Collision, no?

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

I've trimmed and focused a bit.

Thanks again,


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




From alexey.melnikov@isode.com  Tue Jan 28 03:06:16 2014
Return-Path: <alexey.melnikov@isode.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A0A51A0348 for <apps-discuss@ietfa.amsl.com>; Tue, 28 Jan 2014 03:06:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.536
X-Spam-Level: 
X-Spam-Status: No, score=-2.536 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.535, 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 LFCI_tMs4Bzb for <apps-discuss@ietfa.amsl.com>; Tue, 28 Jan 2014 03:06:14 -0800 (PST)
Received: from waldorf.isode.com (waldorf.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 927541A01EC for <apps-discuss@ietf.org>; Tue, 28 Jan 2014 03:06:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1390907170; d=isode.com; s=selector; i=@isode.com; bh=96AHzqFwwo549M72Sq1gWXydIDgA1mYyqKEox1RkT9U=; 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=QMYLE9KfksmngGpkph4oP/xW5idUXN29xLOWwJXiBXj7FxjegVEl8ujhNEoULRUYUi0xl6 88I2Srp7AOS2uEAKzMTeX6i5KaWR1d424q4aEaHj6qnfeqi72MTUwYrOSTSel4koRCQunv 3wtb8ROTWL4T4ZewqtODZwrHZKbtbJ0=;
Received: from [172.16.1.29] (richard.isode.com [62.3.217.249])  by waldorf.isode.com (submission channel) via TCP with ESMTPA  id <UuePIAAIPwh3@waldorf.isode.com>; Tue, 28 Jan 2014 11:06:10 +0000
Message-ID: <52E78F1F.3040902@isode.com>
Date: Tue, 28 Jan 2014 11:06:07 +0000
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
To: apps-discuss@ietf.org
References: <20140121195833.70257.qmail@joyce.lan>
In-Reply-To: <20140121195833.70257.qmail@joyce.lan>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [apps-discuss] last call: draft-ietf-appsawg-rrvs-header-field-06.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Jan 2014 11:06:16 -0000

I reviewed the latest version and it looks good to me. Ship it.


From andy.davidson@allegro.net  Tue Jan 28 03:35:53 2014
Return-Path: <andy.davidson@allegro.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02A6B1A0122 for <apps-discuss@ietfa.amsl.com>; Tue, 28 Jan 2014 03:35:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PfCYVstwk068 for <apps-discuss@ietfa.amsl.com>; Tue, 28 Jan 2014 03:35:50 -0800 (PST)
Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lp0017.outbound.protection.outlook.com [213.199.154.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF6D1A017A for <apps-discuss@ietf.org>; Tue, 28 Jan 2014 03:35:50 -0800 (PST)
Received: from DB3PR02MB155.eurprd02.prod.outlook.com (10.141.3.151) by DB3PR02MB153.eurprd02.prod.outlook.com (10.141.3.149) with Microsoft SMTP Server (TLS) id 15.0.868.8; Tue, 28 Jan 2014 11:35:46 +0000
Received: from DB3PR02MB155.eurprd02.prod.outlook.com ([169.254.11.228]) by DB3PR02MB155.eurprd02.prod.outlook.com ([169.254.11.228]) with mapi id 15.00.0859.020; Tue, 28 Jan 2014 11:35:46 +0000
From: Andy Davidson <andy.davidson@allegro.net>
To: Franck Martin <fmartin@linkedin.com>
Thread-Topic: Please review these 2 I-D on IPv6 and SMTP.
Thread-Index: AQHPELU2QAQzTqfFW0ytG4D60k2JdJqaBYlA
Date: Tue, 28 Jan 2014 11:35:45 +0000
Message-ID: <94463e5222e14a18a46f6f7b39542829@DB3PR02MB155.eurprd02.prod.outlook.com>
References: <77426B543150464AA3F30DF1A91365DE6AF662B5@ESV4-MBX02.linkedin.biz>
In-Reply-To: <77426B543150464AA3F30DF1A91365DE6AF662B5@ESV4-MBX02.linkedin.biz>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [213.5.92.22]
x-forefront-prvs: 0105DAA385
x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(189002)(199002)(77096001)(46102001)(69226001)(51856001)(76576001)(93136001)(15975445006)(87936001)(76786001)(76796001)(59766001)(79102001)(54356001)(76482001)(53806001)(74502001)(47446002)(77982001)(31966008)(74662001)(83072002)(85306002)(87266001)(74366001)(90146001)(19580395003)(92566001)(74316001)(2656002)(56816005)(85852003)(83322001)(54316002)(81686001)(81816001)(81342001)(80976001)(66066001)(74876001)(74706001)(93516002)(49866001)(47736001)(65816001)(80022001)(4396001)(56776001)(15202345003)(33646001)(15974865002)(81542001)(94316002)(86362001)(47976001)(63696002)(50986001)(568214004)(24736002)(18886075002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB3PR02MB153; H:DB3PR02MB155.eurprd02.prod.outlook.com; CLIP:213.5.92.22; FPR:BF96467C.B4D1DCDB.55E3B7B8.D4E013A9.2016A; InfoNoRecordsMX:1; A:1; LANG:en;
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: allegro.net
Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Please review these 2 I-D on IPv6 and SMTP.
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Jan 2014 11:35:53 -0000

Hi, Frank, apps --

> http://datatracker.ietf.org/doc/draft-martin-smtp-ipv6-to-ipv4-fallback/

Please don't implement this type of behaviour in SMTP.

- There are spam filtering techniques which have no logical equivalent in d=
omain based reputation, for example "I wish to take action X on all mail fr=
om domestic internet access subscribers."

- We can not make the assumption that it is possible to fall back from an I=
Pv6 transport to an IPv4 transport in our future.  The end goal, whilst dis=
tant, is to turn that old stuff off.


--=20
Andy Davidson
CTO, Allegro Networks Ltd | Connectivity You Control=20
T. +44 161 200 1610       | www.allegro.net

From john@jlc.net  Tue Jan 28 05:19:05 2014
Return-Path: <john@jlc.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7680C1A03DB for <apps-discuss@ietfa.amsl.com>; Tue, 28 Jan 2014 05:19:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.735
X-Spam-Level: 
X-Spam-Status: No, score=-4.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bFy1r99sgT3h for <apps-discuss@ietfa.amsl.com>; Tue, 28 Jan 2014 05:19:03 -0800 (PST)
Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 3158F1A03D6 for <apps-discuss@ietf.org>; Tue, 28 Jan 2014 05:19:03 -0800 (PST)
Received: by mailhost.jlc.net (Postfix, from userid 104) id 6A46DC94BE; Tue, 28 Jan 2014 08:18:59 -0500 (EST)
Date: Tue, 28 Jan 2014 08:18:59 -0500
From: John Leslie <john@jlc.net>
To: Andy Davidson <andy.davidson@allegro.net>
Message-ID: <20140128131859.GB75603@verdi>
References: <77426B543150464AA3F30DF1A91365DE6AF662B5@ESV4-MBX02.linkedin.biz> <94463e5222e14a18a46f6f7b39542829@DB3PR02MB155.eurprd02.prod.outlook.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <94463e5222e14a18a46f6f7b39542829@DB3PR02MB155.eurprd02.prod.outlook.com>
User-Agent: Mutt/1.4.1i
Cc: Franck Martin <fmartin@linkedin.com>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: [apps-discuss] draft-martin-smtp-ipv6-to-ipv4-fallback
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Jan 2014 13:19:05 -0000

Andy Davidson <andy.davidson@allegro.net> wrote:
> 
>> http://datatracker.ietf.org/doc/draft-martin-smtp-ipv6-to-ipv4-fallback/
> 
> Please don't implement this type of behaviour in SMTP.

   Out of context, it's hard to distinguish what "this type of behaviour"
refers to...

   As things stand now, many tools for spam-control don't work in
IPv6-land.

   While I sincerely hope we can fix that, and I'm not particularly
fond of this draft, I don't see how we can avoid some mail-servers
refusing IPv6 connections by default.

   How we progress from here deserves discussion, IMHO.

> - There are spam filtering techniques which have no logical equivalent
>   in domain based reputation, for example "I wish to take action X on
>   all mail from domestic internet access subscribers."

   True. IMHO that doesn't work too well in IPv4-land, and the problem
looks worse for IPv6...

> - We can not make the assumption that it is possible to fall back from
>   an IPv6 transport to an IPv4 transport in our future.

   True.

>   The end goal, whilst distant, is to turn that old stuff off.

   I don't expect to live that long. :^(

   (BTW, realage.com suggests that's 25 years.)

--
John Leslie <john@jlc.net>

From franck@peachymango.org  Tue Jan 28 10:34:31 2014
Return-Path: <franck@peachymango.org>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 279DB1A0263 for <apps-discuss@ietfa.amsl.com>; Tue, 28 Jan 2014 10:34:31 -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 d0ubWQYz8Nyt for <apps-discuss@ietfa.amsl.com>; Tue, 28 Jan 2014 10:34:27 -0800 (PST)
Received: from smtp.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id 523D71A035F for <apps-discuss@ietf.org>; Tue, 28 Jan 2014 10:34:27 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 81E1229507B; Tue, 28 Jan 2014 12:34:24 -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 T-hFBpexuYGa; Tue, 28 Jan 2014 12:34:24 -0600 (CST)
Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 64DAB29507D; Tue, 28 Jan 2014 12:34:24 -0600 (CST)
Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 580C7295080; Tue, 28 Jan 2014 12:34:24 -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 uj865hY5-7go; Tue, 28 Jan 2014 12:34:24 -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 37C4729507B; Tue, 28 Jan 2014 12:34:24 -0600 (CST)
Date: Tue, 28 Jan 2014 12:34:23 -0600 (CST)
From: Franck Martin <franck@peachymango.org>
To: John Leslie <john@jlc.net>
Message-ID: <197378636.21608.1390934063805.JavaMail.zimbra@peachymango.org>
In-Reply-To: <WM!4f0cd99bf84af09257d98185e47cbd5c57a1e0c906f568cd5939b68b537065af2b3d926f1c2cc19f6658e81fc382ed44!@asav-1.01.com>
References: <77426B543150464AA3F30DF1A91365DE6AF662B5@ESV4-MBX02.linkedin.biz> <94463e5222e14a18a46f6f7b39542829@DB3PR02MB155.eurprd02.prod.outlook.com> <20140128131859.GB75603@verdi> <WM!4f0cd99bf84af09257d98185e47cbd5c57a1e0c906f568cd5939b68b537065af2b3d926f1c2cc19f6658e81fc382ed44!@asav-1.01.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 - FF26 (Mac)/8.0.5_GA_5839)
Thread-Topic: draft-martin-smtp-ipv6-to-ipv4-fallback
Thread-Index: jVFHFb0U8DsfTe30encXO/iQiQxSEA==
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] draft-martin-smtp-ipv6-to-ipv4-fallback
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Jan 2014 18:34:31 -0000

As data points:
-rbldnsd now supports IPv6 since June 2013. It used to be a patch.
-Domain based blocking lists for email is sketchy at best. For instance, spamassassin does not have a single rule using domain based blocking lists. I'm not talking about URL checking, but if this email comes from that domain, I don't want it.

More inline...

----- Original Message -----
> From: "John Leslie" <john@jlc.net>
> To: "Andy Davidson" <andy.davidson@allegro.net>
> Cc: "Franck Martin" <fmartin@linkedin.com>, apps-discuss@ietf.org
> Sent: Tuesday, January 28, 2014 5:18:59 AM
> Subject: [apps-discuss] draft-martin-smtp-ipv6-to-ipv4-fallback
> 
> Andy Davidson <andy.davidson@allegro.net> wrote:
> > 
> >> http://datatracker.ietf.org/doc/draft-martin-smtp-ipv6-to-ipv4-fallback/
> > 
> > Please don't implement this type of behaviour in SMTP.
> 
>    Out of context, it's hard to distinguish what "this type of behaviour"
> refers to...
> 
>    As things stand now, many tools for spam-control don't work in
> IPv6-land.
> 
>    While I sincerely hope we can fix that, and I'm not particularly
> fond of this draft, I don't see how we can avoid some mail-servers
> refusing IPv6 connections by default.

Yes, it is similar to greylisting in some ways, it is making software do what they were not really designed for, but it works. Gmail tends to send by default to the spam folder non-authenticated emails received over IPv6. We do this fallback, and so far it is working well. A few people questioned why so many transfail in their logs and quickly added their IPv6 space to their SPF records (being able to send to gmail helps too).
> 
>    How we progress from here deserves discussion, IMHO.

Yes, I prefer to have it documented, even if this may take some time to progress, or even if it is to close a door.

> 
> > - There are spam filtering techniques which have no logical equivalent
> >   in domain based reputation, for example "I wish to take action X on
> >   all mail from domestic internet access subscribers."
> 
>    True. IMHO that doesn't work too well in IPv4-land, and the problem
> looks worse for IPv6...

I'm not sure what is the use case here but submission is better than whitelisting based on the source IP for SMTP. If you are talking about domestic internet access.

> 
> > - We can not make the assumption that it is possible to fall back from
> >   an IPv6 transport to an IPv4 transport in our future.
> 
>    True.

As long as there is IPv4... and this is app specific. Web browsers fall back to IPv4 already.

I think we should not assume that the IPv6/IPv4 selection can only be solved at the network stack level. It is there for unaware applications.

> 
> >   The end goal, whilst distant, is to turn that old stuff off.
> 
>    I don't expect to live that long. :^(
> 
>    (BTW, realage.com suggests that's 25 years.)
> 

I'm not holding my breath either....

From prvs=0098f42702=johnl@iecc.com  Tue Jan 28 12:10:59 2014
Return-Path: <prvs=0098f42702=johnl@iecc.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14B101A045F for <apps-discuss@ietfa.amsl.com>; Tue, 28 Jan 2014 12:10:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.537
X-Spam-Level: 
X-Spam-Status: No, score=-2.537 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.535, 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 wnEMLanoaQ2x for <apps-discuss@ietfa.amsl.com>; Tue, 28 Jan 2014 12:10:57 -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 126A71A0440 for <apps-discuss@ietf.org>; Tue, 28 Jan 2014 12:10:56 -0800 (PST)
Received: (qmail 27210 invoked from network); 28 Jan 2014 20:10:53 -0000
Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 28 Jan 2014 20:10:53 -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=52e80ecd.xn--btvx9d.k1401; i=johnl@user.iecc.com; bh=lOg0xpugYG+qIaUSyaRLSqn+oznm4cStOGFFM0EeBpY=; b=fDD2UldVgzaxdNSf7KcNGwFVGWsfUDJAQ/ElehSJpaIEHC5KqxX6U1Lywk2q/ZKYw5vmDPbXjDGfYsfVtFFWcQSPXYbl+iOHojRybJu6upy/K4EI+zsY/Oi2dgedSMApWHgDWlXzJ9kcCaDf2qDPCauN4IpVfXv+tiYfj3iSOlbezB7QkdqalIFMGOQ97RL3B3Mo6v5H3edSzd6qIkx6o5PdtBktJBOgVc0yX3KfSmYxEyTrfEB/COGlqfuN4aHG
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=52e80ecd.xn--btvx9d.k1401; olt=johnl@user.iecc.com; bh=lOg0xpugYG+qIaUSyaRLSqn+oznm4cStOGFFM0EeBpY=; b=3w1+0OlWS1RnARKBKmvQLgwsoLd4a1uMmwBgWegGLu0xterOJONSmIXvZ8onozOo9paD/LQELGcPh05GrWk44pyfSLXVmIp/QA1+Im8qO1LnxnAhN+8Qb5i6d0V5fEh2JVxN6k1YpKM5EDB+im4IXDfqL/ATkUDIdgtlDWgRBlUvATvUr3d6wRRjhEGC3auw9jxn8N3pd2NK02Lov9+Dh2sgd2c4Pv/LQs6rwGL20xiknwx5rTZhqGJxShRzA35r
Date: 28 Jan 2014 20:10:31 -0000
Message-ID: <20140128201031.28174.qmail@joyce.lan>
From: "John Levine" <johnl@taugh.com>
To: apps-discuss@ietf.org
In-Reply-To: <20140128131859.GB75603@verdi>
Organization: 
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Subject: Re: [apps-discuss] draft-martin-smtp-ipv6-to-ipv4-fallback
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Jan 2014 20:10:59 -0000

>Andy Davidson <andy.davidson@allegro.net> wrote:
>> 
>>> http://datatracker.ietf.org/doc/draft-martin-smtp-ipv6-to-ipv4-fallback/
>> 
>> Please don't implement this type of behaviour in SMTP.

Please don't even try to implement this type of behavior in SMTP.
I've looked at a variety of MTAs and it simply is not possible to do
fallback from v6 to v4 in a reliable way, despite what the draft
implies.

More to the point, if people are going to upgrade their sending
software, I would much rather encourage them to sign their outgoing
mail with DKIM so v6 hosts will accept it, rather than to implement
this crock.

R's,
John

From simon.perreault@viagenie.ca  Tue Jan 28 12:26:36 2014
Return-Path: <simon.perreault@viagenie.ca>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B4E71A03DB for <apps-discuss@ietfa.amsl.com>; Tue, 28 Jan 2014 12:26:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.436
X-Spam-Level: 
X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 PhSD50BFeWWe for <apps-discuss@ietfa.amsl.com>; Tue, 28 Jan 2014 12:26:34 -0800 (PST)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 764E11A027B for <apps-discuss@ietf.org>; Tue, 28 Jan 2014 12:26:34 -0800 (PST)
Received: from porto.nomis80.org (ringo.viagenie.ca [IPv6:2620:0:230:c000:3e97:eff:fe0b:dd8a]) by jazz.viagenie.ca (Postfix) with ESMTPSA id AD9EE403CA for <apps-discuss@ietf.org>; Tue, 28 Jan 2014 15:26:31 -0500 (EST)
Message-ID: <52E81277.5050807@viagenie.ca>
Date: Tue, 28 Jan 2014 15:26:31 -0500
From: Simon Perreault <simon.perreault@viagenie.ca>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <20140128201031.28174.qmail@joyce.lan>
In-Reply-To: <20140128201031.28174.qmail@joyce.lan>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [apps-discuss] draft-martin-smtp-ipv6-to-ipv4-fallback
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Jan 2014 20:26:36 -0000

Le 2014-01-28 15:10, John Levine a �crit :
> Please don't even try to implement this type of behavior in SMTP.
> I've looked at a variety of MTAs and it simply is not possible to do
> fallback from v6 to v4 in a reliable way, despite what the draft
> implies.

Why?

> More to the point, if people are going to upgrade their sending
> software, I would much rather encourage them to sign their outgoing
> mail with DKIM so v6 hosts will accept it, rather than to implement
> this crock.

Why?

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

From superuser@gmail.com  Tue Jan 28 14:07:38 2014
Return-Path: <superuser@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C47C11A028B for <apps-discuss@ietfa.amsl.com>; Tue, 28 Jan 2014 14:07:38 -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 waEZ3I5wq-YO for <apps-discuss@ietfa.amsl.com>; Tue, 28 Jan 2014 14:07:36 -0800 (PST)
Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id 96D8B1A037C for <apps-discuss@ietf.org>; Tue, 28 Jan 2014 14:07:36 -0800 (PST)
Received: by mail-wg0-f51.google.com with SMTP id z12so1963488wgg.6 for <apps-discuss@ietf.org>; Tue, 28 Jan 2014 14:07:33 -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=0b+eO9csER/bfbBXXkKZhjwI4CLE/RZCRyfmal2//bQ=; b=ed9WJBF8ZoLUIdD0JJylnn3zwapTepC5m4n69nyW1hfPexTbH1i8a3EgYqJsvoYlqS wc7UkHVzSSIbai6LMdv6PoFP2/YDEb0QSfCBNjQ/AKwqMRgUCEPlfBZnO+GefATZfRkp cOd0ZA54ZcM4F4F9yNWY6m+YH5cz7BxHZo1WLAyonAhmIOisrtsQkhmsVKieNNUeiOM7 wPPkCmDODm4LXMFV+bOFZDT+o0XdTdod0cjD8CqdPXFX8IY8Uy9+terGI1jKNtDUbxi6 5y/sBJAH3aOjevMDaM+SOj2vPVUv8wKLWZ609dE1tRBeVn1R0uuBt3MTed0s39HT/krf 4Y/Q==
MIME-Version: 1.0
X-Received: by 10.180.187.16 with SMTP id fo16mr17007089wic.26.1390946853428;  Tue, 28 Jan 2014 14:07:33 -0800 (PST)
Received: by 10.180.98.41 with HTTP; Tue, 28 Jan 2014 14:07:33 -0800 (PST)
In-Reply-To: <20140128201031.28174.qmail@joyce.lan>
References: <20140128131859.GB75603@verdi> <20140128201031.28174.qmail@joyce.lan>
Date: Tue, 28 Jan 2014 14:07:33 -0800
Message-ID: <CAL0qLwZodOY4YBuYnTBfeTtUpbBxhhpSTQDwc1YzGZoPLv+Npg@mail.gmail.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
To: John Levine <johnl@taugh.com>
Content-Type: multipart/alternative; boundary=001a11c266c419a3bf04f10f0d8f
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] draft-martin-smtp-ipv6-to-ipv4-fallback
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Jan 2014 22:07:39 -0000

--001a11c266c419a3bf04f10f0d8f
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Jan 28, 2014 at 12:10 PM, John Levine <johnl@taugh.com> wrote:

>
> Please don't even try to implement this type of behavior in SMTP.
> I've looked at a variety of MTAs and it simply is not possible to do
> fallback from v6 to v4 in a reliable way, despite what the draft
> implies.
>
> More to the point, if people are going to upgrade their sending
> software, I would much rather encourage them to sign their outgoing
> mail with DKIM so v6 hosts will accept it, rather than to implement
> this crock.
>
>
I think the claim is that most available MTA code now does some kind of
reasonable fallback despite the ambiguity in the email RFCs.  Thus, there
wouldn't be much in the way of upgrades needed, and the point is to codify
existing behavior to ensure a coherent path forward.

What counter-evidence exists?  That would be useful information to include
here.

-MSK

--001a11c266c419a3bf04f10f0d8f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tue, Jan 28, 2014 at 12:10 PM, John Levine <span dir=3D=
"ltr">&lt;<a href=3D"mailto:johnl@taugh.com" target=3D"_blank">johnl@taugh.=
com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail=
_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex=
;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class=3D"im"><br>
</div>Please don&#39;t even try to implement this type of behavior in SMTP.=
<br>
I&#39;ve looked at a variety of MTAs and it simply is not possible to do<br=
>
fallback from v6 to v4 in a reliable way, despite what the draft<br>
implies.<br>
<br>
More to the point, if people are going to upgrade their sending<br>
software, I would much rather encourage them to sign their outgoing<br>
mail with DKIM so v6 hosts will accept it, rather than to implement<br>
this crock.<br><br></blockquote><div>=A0<br>I think the claim is that most =
available MTA code now does some kind of reasonable fallback despite the am=
biguity in the email RFCs.=A0 Thus, there wouldn&#39;t be much in the way o=
f upgrades needed, and the point is to codify existing behavior to ensure a=
 coherent path forward.<br>
<br></div><div>What counter-evidence exists?=A0 That would be useful inform=
ation to include here.<br><br></div><div>-MSK<br></div></div></div></div>

--001a11c266c419a3bf04f10f0d8f--

From arnt@gulbrandsen.priv.no  Tue Jan 28 14:20:36 2014
Return-Path: <arnt@gulbrandsen.priv.no>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 950671A02E5 for <apps-discuss@ietfa.amsl.com>; Tue, 28 Jan 2014 14:20:36 -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 YDAv2NM7FVP0 for <apps-discuss@ietfa.amsl.com>; Tue, 28 Jan 2014 14:20:34 -0800 (PST)
Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4E21A026E for <apps-discuss@ietf.org>; Tue, 28 Jan 2014 14:20:34 -0800 (PST)
Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 810D1FA0076; Tue, 28 Jan 2014 22:20:31 +0000 (UTC)
Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1390947630-17068-17067/11/1; Tue, 28 Jan 2014 22:20:30 +0000
From: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
To: apps-discuss@ietf.org
Date: Tue, 28 Jan 2014 23:20:49 +0100
User-Agent: Trojita/v0.3.96-176-g713fcbb; Qt/4.8.4; X11; Linux; Ubuntu 13.10
Mime-Version: 1.0
Message-Id: <85d37e62-d8ac-4c23-8c7e-83a54216f75b@gulbrandsen.priv.no>
In-Reply-To: <>
References: <20140128131859.GB75603@verdi> <20140128201031.28174.qmail@joyce.lan>
Content-Type: text/plain; charset=utf-8; format=flowed
Subject: Re: [apps-discuss] draft-martin-smtp-ipv6-to-ipv4-fallback
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Jan 2014 22:20:36 -0000

On Tuesday, January 28, 2014 11:07:33 PM CEST, Murray S. Kucherawy wrote:
> I think the claim is that most available MTA code now does some 
> kind of reasonable fallback despite the ambiguity in the email 
> RFCs.  Thus, there wouldn't be much in the way of upgrades 
> needed, and the point is to codify existing behavior to ensure a 
> coherent path forward.

"Use 4 instead of 6" isn't a way forward, it's a way backward. "Use 6 
instead of 4" is forward.

Arnt

From kurta@drkurt.com  Tue Jan 28 14:23:16 2014
Return-Path: <kurta@drkurt.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7881F1A026E for <apps-discuss@ietfa.amsl.com>; Tue, 28 Jan 2014 14:23:16 -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 CrtQyX1GwdOS for <apps-discuss@ietfa.amsl.com>; Tue, 28 Jan 2014 14:23:15 -0800 (PST)
Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 3F1051A0069 for <apps-discuss@ietf.org>; Tue, 28 Jan 2014 14:23:15 -0800 (PST)
Received: by mail-wg0-f41.google.com with SMTP id n12so6945849wgh.0 for <apps-discuss@ietf.org>; Tue, 28 Jan 2014 14:23:12 -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=ZU/HO8smlCr3a20Qy1AhD6zIVO1cQ83Fkgvc2aASgNs=; b=H+quA3DlctADi1NSnfqi8+Y0Z2jrpITzepwTg3ZdzYFjJl28tKleN/U+6zqvuD1KVT MtTrXqn7dyxY0O3h1fj15QUBQZSE8vZbl7OxzV5ZG87y/NEx1MepPHFiplRYui05kekE ODbmjBxQyS7WiqrTgGxhIEf7V6GAovCmVoTF4=
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=ZU/HO8smlCr3a20Qy1AhD6zIVO1cQ83Fkgvc2aASgNs=; b=LrMerthn0QYH/2sMcYh+IsPRT8/ghFC3Ad0P/Sn1TCc0lzvmmTIjBdJPfM41WUpJt4 1SyXcgBUITEDRU0nWPOYNS3SUegYxbyNl0moRjHvxD3XbZybwBZikE3a9Qv96hDkWiCW BkBobhqeMiStoUWKOMJtlSdHenGfip2CNygeWJwcsGuIT29c9eNBCpCAiuMhWbLZJ6nR 8LtkIaxd9Vb5p5lTmGRuKGknLcO1SwzV8Iqr4JkFaNf8dsiP3q1oKGc5/oC08m3Xegv3 My8y3JKzMoP5obR1r8YUjghdfhaKPgmqkpHWMBmOLqZsAZa9FJEUHuOOsOlB7TKhYFsT V9SQ==
X-Gm-Message-State: ALoCoQlUSbNiHSh8I7MuLX+iPG02AO37oDGsha+eKICGVbVjneksIbORxb1PxJ6/wO+kfDs2d2AY
MIME-Version: 1.0
X-Received: by 10.180.37.162 with SMTP id z2mr3372612wij.51.1390947792176; Tue, 28 Jan 2014 14:23:12 -0800 (PST)
Sender: kurta@drkurt.com
Received: by 10.195.12.137 with HTTP; Tue, 28 Jan 2014 14:23:12 -0800 (PST)
In-Reply-To: <85d37e62-d8ac-4c23-8c7e-83a54216f75b@gulbrandsen.priv.no>
References: <20140128131859.GB75603@verdi> <20140128201031.28174.qmail@joyce.lan> <85d37e62-d8ac-4c23-8c7e-83a54216f75b@gulbrandsen.priv.no>
Date: Tue, 28 Jan 2014 14:23:12 -0800
X-Google-Sender-Auth: Ich-t2Yo3c-HL_6ydoqD6puDdt8
Message-ID: <CABuGu1quRJBQrREDJSWBfrfKT9MwF2U0S_K6CzOxBCxw4Ry+iQ@mail.gmail.com>
From: Kurt Andersen <kboth@drkurt.com>
To: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
Content-Type: text/plain; charset=ISO-8859-1
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] draft-martin-smtp-ipv6-to-ipv4-fallback
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Jan 2014 22:23:16 -0000

On Tue, Jan 28, 2014 at 2:20 PM, Arnt Gulbrandsen
<arnt@gulbrandsen.priv.no> wrote:
>
> "Use 4 instead of 6" isn't a way forward, it's a way backward. "Use 6
> instead of 4" is forward.

It's only "use 4 until you can figure out how to use 6 properly" :-)

--Kurt

From prvs=009803a606=johnl@taugh.com  Tue Jan 28 14:29:30 2014
Return-Path: <prvs=009803a606=johnl@taugh.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEF871A02E5 for <apps-discuss@ietfa.amsl.com>; Tue, 28 Jan 2014 14:29:30 -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 IQhFQIl0iWWC for <apps-discuss@ietfa.amsl.com>; Tue, 28 Jan 2014 14:29:28 -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 8C95C1A0069 for <apps-discuss@ietf.org>; Tue, 28 Jan 2014 14:29:28 -0800 (PST)
Received: (qmail 40225 invoked from network); 28 Jan 2014 22:29:24 -0000
Received: from miucha.iecc.com (64.57.183.18) by mail1.iecc.com with QMQP; 28 Jan 2014 22:29:24 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=dfd5.52e82f43.k1401; i=johnl%iecc.com@submit.iecc.com; bh=Rp7ejGg5/DI5j7C6q+Brkb/8WbK5CTDJPKhmJX4kcrM=; b=Jt6w2Pouhj1o8fmyWopXdI8Rhcu1Talx+YAn4ZlCS6Ot9bfk2FKYub9KhMmZvwCmXRoPXtH0CnHI0NYoK95KcI5nB4QsgIEuVi/k9tyX0yjz58OBK6JqnD19wtNXPvYTctb3mczKlmtC1xlHxN7SSK1Gf4hIZi8ThOxMqqepopXLrGFYwdpMYtsxT5D1B5URlbWBIIAGJElHLOEG3NHk33Xk+8klq8aHUy4RzZL5ejkCGmqCzNpUx8nfK5ygp+Mb
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=dfd5.52e82f43.k1401; olt=johnl%iecc.com@submit.iecc.com; bh=Rp7ejGg5/DI5j7C6q+Brkb/8WbK5CTDJPKhmJX4kcrM=; b=ULPqSeRpETiHphDfUsHPtUKLcIgl03D+pHOHbXRT5yyG3YTtJi1L69m5QLpK2XHdDZfsDToWvShngRz5MiiZ0Rz6p3miiwUEXG/fOPHAhRxQ6WALgr9gQpJ6K6RplwndanxhVfVqSCBTykm0p3tyfXMwP61pDOv3e5vfA1QTl1TO2OsBRCW89Ak374KdMwVTbgRWlvfKI1N5RZ6fkZ0vxzV0z1gPgtnc8Ic3SjnZP4O3htIEDLd+BEyf5NsvJubl
Received: from joyce.lan ([24.59.92.2]) by nimap.iecc.com ([64.57.183.76]) with ESMTPSA (TLS1.0/X.509/SHA1, johnl@iecc.com) via TCP; 28 Jan 2014 22:29:23 -0000
Date: 28 Jan 2014 17:29:23 -0500
Message-ID: <alpine.BSF.2.00.1401281710290.28427@joyce.lan>
From: "John R Levine" <johnl@taugh.com>
To: "Murray S. Kucherawy" <superuser@gmail.com>
In-Reply-To: <CAL0qLwZodOY4YBuYnTBfeTtUpbBxhhpSTQDwc1YzGZoPLv+Npg@mail.gmail.com>
References: <20140128131859.GB75603@verdi> <20140128201031.28174.qmail@joyce.lan> <CAL0qLwZodOY4YBuYnTBfeTtUpbBxhhpSTQDwc1YzGZoPLv+Npg@mail.gmail.com>
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
Cleverness: None detected
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] draft-martin-smtp-ipv6-to-ipv4-fallback
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Jan 2014 22:29:31 -0000

> I think the claim is that most available MTA code now does some kind of
> reasonable fallback despite the ambiguity in the email RFCs.

I've taken a look, and it's not consistent, in particular the way they 
respond to 4xx at the end of data, which is the only place a receiver can 
respond to the absence of DKIM.  You can come up with hacks that sorta 
kinda work, but they're not what I would want to standardize.  As you may 
recall from previous discussions on other lists, some MTAs will try other 
IPs, some will keep retrying the same IP that gave them the 4xx.

I suggested a grosse hackque in which the receiving MTA remembers sending 
MTAs to which it's given the back-off return code, and refuses connections 
from them for a while, to try and force them to use other MXes.  But I 
really don't think we want to go there.

More to the point, this draft suggests adding a new SMTP status code and 
ESMTP keywords, which sending MTAs would add new code to interpret.  If 
people are going to add new code to their sending MTAs, why in the world 
would you want them to do this hack, rather than just DKIM signing all 
their mail so the v6 systems will accept it, no hack required.  We already 
know how to do that.  Note that any DKIM signature will do to get MTAs to 
accept mail, no need to match the headers.

Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

From franck@peachymango.org  Tue Jan 28 15:48:54 2014
Return-Path: <franck@peachymango.org>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C0651A0378 for <apps-discuss@ietfa.amsl.com>; Tue, 28 Jan 2014 15:48:54 -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 SvHEYx78JjZD for <apps-discuss@ietfa.amsl.com>; Tue, 28 Jan 2014 15:48:53 -0800 (PST)
Received: from smtp.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id 3F2621A036C for <apps-discuss@ietf.org>; Tue, 28 Jan 2014 15:48:53 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id AC8ED3981E0; Tue, 28 Jan 2014 17:48:50 -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 aTSdlRyd5vUW; Tue, 28 Jan 2014 17:48:50 -0600 (CST)
Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 8C9F63981E2; Tue, 28 Jan 2014 17:48:50 -0600 (CST)
Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 775F53981E1; Tue, 28 Jan 2014 17:48:50 -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 aaKaInujzweT; Tue, 28 Jan 2014 17:48:50 -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 428863981E0; Tue, 28 Jan 2014 17:48:50 -0600 (CST)
Date: Tue, 28 Jan 2014 17:48:49 -0600 (CST)
From: Franck Martin <franck@peachymango.org>
To: Terry Zink <tzink@exchange.microsoft.com>
Message-ID: <761335783.34347.1390952929308.JavaMail.zimbra@peachymango.org>
In-Reply-To: <WM!ee6e31e815b725bfb189271632c23b1bd5f6508482c10a6ef4c71694d9f80ec58eca5f7e86c6c0c50b7545142c937756!@asav-1.01.com>
References: <77426B543150464AA3F30DF1A91365DE6AF662B5@ESV4-MBX02.linkedin.biz> <94463e5222e14a18a46f6f7b39542829@DB3PR02MB155.eurprd02.prod.outlook.com> <20140128131859.GB75603@verdi> <WM!4f0cd99bf84af09257d98185e47cbd5c57a1e0c906f568cd5939b68b537065af2b3d926f1c2cc19f6658e81fc382ed44!@asav-1.01.com> <197378636.21608.1390934063805.JavaMail.zimbra@peachymango.org> <99f0f33595384767b848b0cf23715727@BL2SR01MB605.namsdf01.sdf.exchangelabs.com> <WM!ee6e31e815b725bfb189271632c23b1bd5f6508482c10a6ef4c71694d9f80ec58eca5f7e86c6c0c50b7545142c937756!@asav-1.01.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 - FF26 (Mac)/8.0.5_GA_5839)
Thread-Topic: draft-martin-smtp-ipv6-to-ipv4-fallback
Thread-Index: AQHPHFeXiYX6tIvhP0mIAwqNrC5E9Jqaqb7wDG8xyQ0=
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] draft-martin-smtp-ipv6-to-ipv4-fallback
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Jan 2014 23:48:54 -0000

----- Original Message -----
> From: "Terry Zink" <tzink@exchange.microsoft.com>
> To: "Franck Martin" <franck@peachymango.org>, "John Leslie" <john@jlc.net>
> Cc: apps-discuss@ietf.org
> Sent: Tuesday, January 28, 2014 1:45:35 PM
> Subject: RE: draft-martin-smtp-ipv6-to-ipv4-fallback
> 
> 
> According to a Google blog post
> (http://googleonlinesecurity.blogspot.com/2013/12/internet-wide-efforts-to-fight-email.html),
> 91% of all messages today are validated with either SPF or DKIM. They don't
> say how many pass the PTR requirement, but we can use this as an estimate of
> how much email traffic it would affect. This statistic applies to number of
> emails, not to domains, so there may be a long tail of small senders who do
> not do basic email authentication.
> 

And it is in this long tail that the badness happens...

From prvs=00995a0cdf=johnl@iecc.com  Tue Jan 28 17:02:54 2014
Return-Path: <prvs=00995a0cdf=johnl@iecc.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F05C41A044C for <apps-discuss@ietfa.amsl.com>; Tue, 28 Jan 2014 17:02:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.537
X-Spam-Level: 
X-Spam-Status: No, score=-2.537 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.535, 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 WiJPiZI1GTtM for <apps-discuss@ietfa.amsl.com>; Tue, 28 Jan 2014 17:02:53 -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 588281A037C for <apps-discuss@ietf.org>; Tue, 28 Jan 2014 17:02:53 -0800 (PST)
Received: (qmail 50383 invoked from network); 29 Jan 2014 01:02:49 -0000
Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 29 Jan 2014 01:02:49 -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=52e85339.xn--9vv.k1401; i=johnl@user.iecc.com; bh=9kyoyVz0Cl5GKlB4X2QLU5p+2ryUq525dPHrrsfTTwk=; b=NlyxSpPdpv9qm2FoR/uSgnewGASLbSOXwX7vn5LRDVcYcI7d0qC+VTLd0Fv96kjbec2zOhRfAzKGjEAXqzNgZ76lIirTBaj+l7BCXCfAMTORx2ocyz0h/h/AjrUxKs4dKSu3+bnK7EUC4RHx8czAfsGDzY5vQJcXcq0UsL2T1dUFSXtpd7G/KYIxgjZ9Khet3jtOZJdAj9IS85OI3Y4FMhFX5uoSCH5RJuS67MVELedng/Iv72PmPHELvHJZlur4
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=52e85339.xn--9vv.k1401; olt=johnl@user.iecc.com; bh=9kyoyVz0Cl5GKlB4X2QLU5p+2ryUq525dPHrrsfTTwk=; b=Tpf9A+edEFqK6+GmRohyR4swqLNZhYSFGqUExFrDMcvMx4d1MWHl8KOon+PftPg0fXVloMr3ggzj0Qyng1FVK7806Su+MvldnXqAnb3slkcuCn5N3LzI4RrwYiN9YVfFOrV9lsC7SChKiDws/3XojNRuVkatrUDmw/S+6ymUbuLRh6DIIvwCA/tIxjSlBF646kLwCV4tMA3NpftiNUT5NwntBbS2J/8z5SlUgtFPgSfeJ0BugCOhw9ojGy3nf5D+
Date: 29 Jan 2014 01:02:27 -0000
Message-ID: <20140129010227.33719.qmail@joyce.lan>
From: "John Levine" <johnl@taugh.com>
To: apps-discuss@ietf.org
In-Reply-To: <761335783.34347.1390952929308.JavaMail.zimbra@peachymango.org>
Organization: 
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Subject: Re: [apps-discuss] draft-martin-smtp-ipv6-to-ipv4-fallback
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Jan 2014 01:02:55 -0000

>> emails, not to domains, so there may be a long tail of small senders who do
>> not do basic email authentication.
>
>And it is in this long tail that the badness happens...

Right.  It's nuts to imagine that these small senders, with their
dusty old Windows and linux boxes, would ever implement this fallback
hack.

If they'd ever upgraded their MTAs, they'd have SPF and DKIM working
already.

R's,
John

From tzink@exchange.microsoft.com  Tue Jan 28 17:21:50 2014
Return-Path: <tzink@exchange.microsoft.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD0511A048F for <apps-discuss@ietfa.amsl.com>; Tue, 28 Jan 2014 17:21:50 -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 qdNDr8JdCNI2 for <apps-discuss@ietfa.amsl.com>; Tue, 28 Jan 2014 17:21:48 -0800 (PST)
Received: from na01-by1-obe.outbound.o365filtering.com (na01-by1-obe.ptr.o365filtering.com [64.4.22.94]) by ietfa.amsl.com (Postfix) with ESMTP id C44821A048D for <apps-discuss@ietf.org>; Tue, 28 Jan 2014 17:21:47 -0800 (PST)
Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com (10.255.109.167) by BL2SR01MB606.namsdf01.sdf.exchangelabs.com (10.255.109.168) with Microsoft SMTP Server (TLS) id 15.0.878.3; Tue, 28 Jan 2014 21:45:36 +0000
Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.6.9]) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.6.194]) with mapi id 15.00.0878.003; Tue, 28 Jan 2014 21:45:36 +0000
From: Terry Zink <tzink@exchange.microsoft.com>
To: Franck Martin <franck@peachymango.org>, John Leslie <john@jlc.net>
Thread-Topic: draft-martin-smtp-ipv6-to-ipv4-fallback
Thread-Index: AQHPHFeXiYX6tIvhP0mIAwqNrC5E9Jqaqb7w
Date: Tue, 28 Jan 2014 21:45:35 +0000
Message-ID: <99f0f33595384767b848b0cf23715727@BL2SR01MB605.namsdf01.sdf.exchangelabs.com>
References: <77426B543150464AA3F30DF1A91365DE6AF662B5@ESV4-MBX02.linkedin.biz> <94463e5222e14a18a46f6f7b39542829@DB3PR02MB155.eurprd02.prod.outlook.com> <20140128131859.GB75603@verdi> <WM!4f0cd99bf84af09257d98185e47cbd5c57a1e0c906f568cd5939b68b537065af2b3d926f1c2cc19f6658e81fc382ed44!@asav-1.01.com> <197378636.21608.1390934063805.JavaMail.zimbra@peachymango.org>
In-Reply-To: <197378636.21608.1390934063805.JavaMail.zimbra@peachymango.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [131.107.160.254]
x-forefront-prvs: 0105DAA385
x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(51704005)(46034005)(377454003)(13464003)(24454002)(189002)(199002)(15975445006)(85306002)(90146001)(83072002)(85852003)(56816005)(69226001)(65816001)(46102001)(2656002)(51856001)(74662001)(47446002)(31966008)(19580395003)(83322001)(19580405001)(54356001)(92566001)(87936001)(53806001)(81342001)(66066001)(80022001)(33646001)(87266001)(81542001)(15202345003)(74366001)(74502001)(59766001)(77982001)(76786001)(76796001)(77096001)(54316002)(56776001)(76482001)(63696002)(74706001)(81816001)(81686001)(49866001)(93886001)(80976001)(94316002)(47736001)(4396001)(47976001)(50986001)(93516002)(93136001)(79102001)(74876001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2SR01MB606; H:BL2SR01MB605.namsdf01.sdf.exchangelabs.com; CLIP:131.107.160.254; FPR:EEECCD44.AFEA545B.99F1B143.5EE4C26D.20510; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: exchange.microsoft.com
Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] draft-martin-smtp-ipv6-to-ipv4-fallback
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Jan 2014 01:21:51 -0000

> Gmail tends to send by default to the spam folder non-authenticated email=
s received over IPv6.

Correct. Google's requirements are published here: https://support.google.c=
om/mail/answer/81126?hl=3Den under "Authentication & Identification" wherei=
n they state that the sending IP must have  PTR record and it should match =
the forward DNS resolution of the hostname in the PTR, and that the sending=
 domain should pass SPF or DKIM.

>>  We can not make the assumption that it is possible to fall back from
>>   an IPv6 transport to an IPv4 transport in our future.
>=20
>    True.

According to a Google blog post (http://googleonlinesecurity.blogspot.com/2=
013/12/internet-wide-efforts-to-fight-email.html), 91% of all messages toda=
y are validated with either SPF or DKIM. They don't say how many pass the P=
TR requirement, but we can use this as an estimate of how much email traffi=
c it would affect. This statistic applies to number of emails, not to domai=
ns, so there may be a long tail of small senders who do not do basic email =
authentication.

-- Terry

-----Original Message-----
From: apps-discuss [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Fran=
ck Martin
Sent: Tuesday, January 28, 2014 10:34 AM
To: John Leslie
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] draft-martin-smtp-ipv6-to-ipv4-fallback

As data points:
-rbldnsd now supports IPv6 since June 2013. It used to be a patch.
-Domain based blocking lists for email is sketchy at best. For instance, sp=
amassassin does not have a single rule using domain based blocking lists. I=
'm not talking about URL checking, but if this email comes from that domain=
, I don't want it.

More inline...

----- Original Message -----
> From: "John Leslie" <john@jlc.net>
> To: "Andy Davidson" <andy.davidson@allegro.net>
> Cc: "Franck Martin" <fmartin@linkedin.com>, apps-discuss@ietf.org
> Sent: Tuesday, January 28, 2014 5:18:59 AM
> Subject: [apps-discuss] draft-martin-smtp-ipv6-to-ipv4-fallback
>=20
> Andy Davidson <andy.davidson@allegro.net> wrote:
> >=20
> >> http://datatracker.ietf.org/doc/draft-martin-smtp-ipv6-to-ipv4-fall
> >> back/
> >=20
> > Please don't implement this type of behaviour in SMTP.
>=20
>    Out of context, it's hard to distinguish what "this type of behaviour"
> refers to...
>=20
>    As things stand now, many tools for spam-control don't work in=20
> IPv6-land.
>=20
>    While I sincerely hope we can fix that, and I'm not particularly=20
> fond of this draft, I don't see how we can avoid some mail-servers=20
> refusing IPv6 connections by default.

Yes, it is similar to greylisting in some ways, it is making software do wh=
at they were not really designed for, but it works. Gmail tends to send by =
default to the spam folder non-authenticated emails received over IPv6. We =
do this fallback, and so far it is working well. A few people questioned wh=
y so many transfail in their logs and quickly added their IPv6 space to the=
ir SPF records (being able to send to gmail helps too).
>=20
>    How we progress from here deserves discussion, IMHO.

Yes, I prefer to have it documented, even if this may take some time to pro=
gress, or even if it is to close a door.

>=20
> > - There are spam filtering techniques which have no logical equivalent
> >   in domain based reputation, for example "I wish to take action X on
> >   all mail from domestic internet access subscribers."
>=20
>    True. IMHO that doesn't work too well in IPv4-land, and the problem=20
> looks worse for IPv6...

I'm not sure what is the use case here but submission is better than whitel=
isting based on the source IP for SMTP. If you are talking about domestic i=
nternet access.

>=20
> > - We can not make the assumption that it is possible to fall back from
> >   an IPv6 transport to an IPv4 transport in our future.
>=20
>    True.

As long as there is IPv4... and this is app specific. Web browsers fall bac=
k to IPv4 already.

I think we should not assume that the IPv6/IPv4 selection can only be solve=
d at the network stack level. It is there for unaware applications.

>=20
> >   The end goal, whilst distant, is to turn that old stuff off.
>=20
>    I don't expect to live that long. :^(
>=20
>    (BTW, realage.com suggests that's 25 years.)
>=20

I'm not holding my breath either....
_______________________________________________
apps-discuss mailing list
apps-discuss@ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

From marc.blanchet@viagenie.ca  Tue Jan 28 18:56:58 2014
Return-Path: <marc.blanchet@viagenie.ca>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7694A1A035E; Tue, 28 Jan 2014 18:56:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.435
X-Spam-Level: 
X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, 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 VJ6Uf0_7_wOc; Tue, 28 Jan 2014 18:56:56 -0800 (PST)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id D57831A033C; Tue, 28 Jan 2014 18:56:55 -0800 (PST)
Received: from h195.viagenie.ca (h195.viagenie.ca [206.123.31.195]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 9A70B40D17; Tue, 28 Jan 2014 21:56:51 -0500 (EST)
From: Marc Blanchet <marc.blanchet@viagenie.ca>
Content-Type: multipart/alternative; boundary="Apple-Mail=_CCD0E480-4C35-4722-9C7A-38ADB49AB9C9"
Date: Tue, 28 Jan 2014 21:56:50 -0500
References: <20140128223101.31170.24891.idtracker@ietfa.amsl.com>
To: apps-discuss@ietf.org, dnsop@ietf.org
Message-Id: <20F732BA-C497-4501-9843-BD2B83DA426A@viagenie.ca>
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
X-Mailer: Apple Mail (2.1827)
Subject: [apps-discuss] Fwd: New Non-WG Mailing List: Dbound -- DNS tree bounds
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Jan 2014 02:56:58 -0000

--Apple-Mail=_CCD0E480-4C35-4722-9C7A-38ADB49AB9C9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

FYI, This new mailing list is to focus the discussion that would lead =
into the dbound BOF in IETF London. Information about the BOF is at: =
http://trac.tools.ietf.org/bof/trac/

Please subscribe.

Regards, Marc.

D=E9but du message r=E9exp=E9di=E9 :

> De: IETF Secretariat <ietf-secretariat@ietf.org>
> Objet: New Non-WG Mailing List: Dbound -- DNS tree bounds
> Date: 28 janvier 2014 17:31:01 HNE
> =C0: IETF Announcement List <ietf-announce@ietf.org>
> Cc: olaf@nlnetlabs.nl, marc.blanchet@viagenie.ca
> R=E9pondre =E0: ietf@ietf.org
>=20
> A new IETF non-working group email list has been created.
>=20
> List address: dbound@ietf.org
> Archive: http://www.ietf.org/mail-archive/web/dbound/
> To subscribe: https://www.ietf.org/mailman/listinfo/dbound
>=20
> Purpose:=20
>=20
> Both users and applications make inferences from domain names, usually=20=

> in an effort to make some determination about identity or the correct=20=

> security stance to take. Such inferences, however, are usually based=20=

> on heuristics, rules of thumb, and large static lists describing parts=20=

> of the DNS name space. The DNS root is expanding rapidly, and the=20
> existing mechanisms -- primarily the public suffix list=20
> (http://publicsuffix.org/) and related systems -- are unlikely to be=20=

> sustainable in the medium term. Most of the existing mechanisms are=20
> managed semi-manually, and there are good reasons to suppose that the=20=

> limits of such management are either about to be exceeded, or already=20=

> have been. Moreover, the existing mechanisms are made without regard=20=

> to the semantics of domain name boundaries, and sometimes miss subtle=20=

> but important parts of those semantics (in particular, the public=20
> suffix list has sometimes failed to take into account so-called empty=20=

> non-terminals). Perhaps most importantly, the public suffix list puts=20=

> the control of policy assertions about a given name outside of the=20
> control of the domain operator, and in the hands of the operator of=20
> the list.=20
>=20
> The purpose of this mailing list is to discuss this issue and to=20
> identify as completely as we can the cases in need of addressing, to=20=

> identify the necessary lines of work to address each case, and to=20
> determine whether there is sufficient interest and energy to set up a=20=

> working group to complete that work.
>=20
> For additional information, please contact the list administrators.


--Apple-Mail=_CCD0E480-4C35-4722-9C7A-38ADB49AB9C9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Diso-8859-1"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">FYI, =
This new mailing list is to focus the discussion that would lead into =
the dbound BOF in IETF London. Information about the BOF is at:&nbsp;<a =
href=3D"http://trac.tools.ietf.org/bof/trac/">http://trac.tools.ietf.org/b=
of/trac/</a><div><br></div><div>Please =
subscribe.<div><br></div><div>Regards, Marc.<br><div><br><div>D=E9but du =
message r=E9exp=E9di=E9 :</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px;"><span style=3D"font-family:'Helvetica'; color:rgba(0, =
0, 0, 1.0);"><b>De: </b></span><span =
style=3D"font-family:'Helvetica';">IETF Secretariat &lt;<a =
href=3D"mailto:ietf-secretariat@ietf.org">ietf-secretariat@ietf.org</a>&gt=
;<br></span></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px;"><span =
style=3D"font-family:'Helvetica'; color:rgba(0, 0, 0, 1.0);"><b>Objet: =
</b></span><span style=3D"font-family:'Helvetica';"><b>New Non-WG =
Mailing List: Dbound -- DNS tree bounds</b><br></span></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px;"><span style=3D"font-family:'Helvetica'; color:rgba(0, =
0, 0, 1.0);"><b>Date: </b></span><span =
style=3D"font-family:'Helvetica';">28 janvier 2014 17:31:01 =
HNE<br></span></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px;"><span =
style=3D"font-family:'Helvetica'; color:rgba(0, 0, 0, 1.0);"><b>=C0: =
</b></span><span style=3D"font-family:'Helvetica';">IETF Announcement =
List &lt;<a =
href=3D"mailto:ietf-announce@ietf.org">ietf-announce@ietf.org</a>&gt;<br><=
/span></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px;"><span =
style=3D"font-family:'Helvetica'; color:rgba(0, 0, 0, 1.0);"><b>Cc: =
</b></span><span style=3D"font-family:'Helvetica';"><a =
href=3D"mailto:olaf@nlnetlabs.nl">olaf@nlnetlabs.nl</a>, <a =
href=3D"mailto:marc.blanchet@viagenie.ca">marc.blanchet@viagenie.ca</a><br=
></span></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px;"><span =
style=3D"font-family:'Helvetica'; color:rgba(0, 0, 0, 1.0);"><b>R=E9pondre=
 =E0: </b></span><span style=3D"font-family:'Helvetica';"><a =
href=3D"mailto:ietf@ietf.org">ietf@ietf.org</a><br></span></div><br><div>A=
 new IETF non-working group email list has been created.<br><br>List =
address: <a =
href=3D"mailto:dbound@ietf.org">dbound@ietf.org</a><br>Archive: <a =
href=3D"http://www.ietf.org/mail-archive/web/dbound/">http://www.ietf.org/=
mail-archive/web/dbound/</a><br>To subscribe: <a =
href=3D"https://www.ietf.org/mailman/listinfo/dbound">https://www.ietf.org=
/mailman/listinfo/dbound</a><br><br>Purpose: <br><br>Both users and =
applications make inferences from domain names, usually <br>in an effort =
to make some determination about identity or the correct <br>security =
stance to take. Such inferences, however, are usually based <br>on =
heuristics, rules of thumb, and large static lists describing parts =
<br>of the DNS name space. The DNS root is expanding rapidly, and the =
<br>existing mechanisms -- primarily the public suffix list <br>(<a =
href=3D"http://publicsuffix.org/">http://publicsuffix.org/</a>) and =
related systems -- are unlikely to be <br>sustainable in the medium =
term. Most of the existing mechanisms are <br>managed semi-manually, and =
there are good reasons to suppose that the <br>limits of such management =
are either about to be exceeded, or already <br>have been. Moreover, the =
existing mechanisms are made without regard <br>to the semantics of =
domain name boundaries, and sometimes miss subtle <br>but important =
parts of those semantics (in particular, the public <br>suffix list has =
sometimes failed to take into account so-called empty =
<br>non-terminals). Perhaps most importantly, the public suffix list =
puts <br>the control of policy assertions about a given name outside of =
the <br>control of the domain operator, and in the hands of the operator =
of <br>the list. <br><br>The purpose of this mailing list is to discuss =
this issue and to <br>identify as completely as we can the cases in need =
of addressing, to <br>identify the necessary lines of work to address =
each case, and to <br>determine whether there is sufficient interest and =
energy to set up a <br>working group to complete that work.<br><br>For =
additional information, please contact the list =
administrators.<br></div></blockquote></div><br></div></div></body></html>=

--Apple-Mail=_CCD0E480-4C35-4722-9C7A-38ADB49AB9C9--

From arnt@gulbrandsen.priv.no  Wed Jan 29 00:00:56 2014
Return-Path: <arnt@gulbrandsen.priv.no>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 212381A007A for <apps-discuss@ietfa.amsl.com>; Wed, 29 Jan 2014 00:00:56 -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 jSSe6SbKnStE for <apps-discuss@ietfa.amsl.com>; Wed, 29 Jan 2014 00:00:54 -0800 (PST)
Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id 135561A00F5 for <apps-discuss@ietf.org>; Wed, 29 Jan 2014 00:00:53 -0800 (PST)
Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 601E0FA0069; Wed, 29 Jan 2014 08:00:50 +0000 (UTC)
Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1390982449-17068-17067/11/2; Wed, 29 Jan 2014 08:00:49 +0000
From: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
To: Kurt Andersen <kboth@drkurt.com>
Date: Wed, 29 Jan 2014 09:01:08 +0100
User-Agent: Trojita/v0.3.96-176-g713fcbb; Qt/4.8.4; X11; Linux; Ubuntu 13.10
Mime-Version: 1.0
Message-Id: <fea4f08f-818a-4fba-89eb-a99815e2f997@gulbrandsen.priv.no>
In-Reply-To: <>
References: <20140128131859.GB75603@verdi> <20140128201031.28174.qmail@joyce.lan> <85d37e62-d8ac-4c23-8c7e-83a54216f75b@gulbrandsen.priv.no>
Content-Type: text/plain; charset=utf-8; format=flowed
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] draft-martin-smtp-ipv6-to-ipv4-fallback
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Jan 2014 08:00:56 -0000

Kurt Andersen answers me:
>> "Use 4 instead of 6" isn't a way forward, it's a way backward. "Use 6
>> instead of 4" is forward.
>
> It's only "use 4 until you can figure out how to use 6 properly" :-)

In that case it's a standstill. The way forward would be "here's what 
you're missing to use 6 properly". In someone's example yesterday, "use 
DKIM and I'll accept mail from you".

Arnt

From arnt@gulbrandsen.priv.no  Wed Jan 29 01:13:20 2014
Return-Path: <arnt@gulbrandsen.priv.no>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BFFB1A03B8 for <apps-discuss@ietfa.amsl.com>; Wed, 29 Jan 2014 01:13:20 -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 jVXfPvyEJt4B for <apps-discuss@ietfa.amsl.com>; Wed, 29 Jan 2014 01:13:18 -0800 (PST)
Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E8631A0364 for <apps-discuss@ietf.org>; Wed, 29 Jan 2014 01:13:17 -0800 (PST)
Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 586AAFA003D; Wed, 29 Jan 2014 09:13:14 +0000 (UTC)
Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1390986793-17068-17067/11/3; Wed, 29 Jan 2014 09:13:13 +0000
From: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
To: apps-discuss@ietf.org
Date: Wed, 29 Jan 2014 10:13:32 +0100
User-Agent: Trojita/v0.3.96-176-g713fcbb; Qt/4.8.4; X11; Linux; Ubuntu 13.10
Mime-Version: 1.0
Message-Id: <95944a51-a5ff-4741-be24-a6e63c567b5a@gulbrandsen.priv.no>
In-Reply-To: <fea4f08f-818a-4fba-89eb-a99815e2f997@gulbrandsen.priv.no>
References: <20140128131859.GB75603@verdi> <20140128201031.28174.qmail@joyce.lan> <85d37e62-d8ac-4c23-8c7e-83a54216f75b@gulbrandsen.priv.no> <fea4f08f-818a-4fba-89eb-a99815e2f997@gulbrandsen.priv.no>
Content-Type: text/plain; charset=utf-8; format=flowed
Subject: Re: [apps-discuss] draft-martin-smtp-ipv6-to-ipv4-fallback
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Jan 2014 09:13:20 -0000

As an example of how that might be:

   If the server advertises the capability REJECTIONDETAILS, then certain
   bracketed keywords in 4xx and 5xx responses to MAIL FROM, RCPT TO and
   DATA mean as follows:

     [MISSINGDKIM]  The lack of a DKIM signature is (part of) the reason
                    for rejecting this transaction.

     ...

In some ways this would be like RFC 5530 (for IMAP), which has been 
surprisingly widely deployed. I like something along these lines a great 
deal better than "go back to ipv4".

Arnt

From michawe@ifi.uio.no  Wed Jan 29 06:39:45 2014
Return-Path: <michawe@ifi.uio.no>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 460741A03E9 for <apps-discuss@ietfa.amsl.com>; Wed, 29 Jan 2014 06:39:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.435
X-Spam-Level: 
X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KtHDz7-b3eYM for <apps-discuss@ietfa.amsl.com>; Wed, 29 Jan 2014 06:39:41 -0800 (PST)
Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) by ietfa.amsl.com (Postfix) with ESMTP id 5C4391A03F3 for <apps-discuss@ietf.org>; Wed, 29 Jan 2014 06:39:41 -0800 (PST)
Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from <michawe@ifi.uio.no>) id 1W8WIi-0007Rt-VK for apps-discuss@ietf.org; Wed, 29 Jan 2014 15:39:36 +0100
Received: from [79.140.208.33] (helo=[10.10.8.160]) by mail-mx2.uio.no with esmtpsa (TLSv1:AES128-SHA:128) user michawe (Exim 4.80) (envelope-from <michawe@ifi.uio.no>) id 1W8WIi-0003Zt-7y for apps-discuss@ietf.org; Wed, 29 Jan 2014 15:39:36 +0100
From: Michael Welzl <michawe@ifi.uio.no>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <1FA55465-DD9B-4CB2-A993-CED4DE5B2550@ifi.uio.no>
Date: Wed, 29 Jan 2014 15:39:32 +0100
To: apps-discuss@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
X-Mailer: Apple Mail (2.1510)
X-UiO-SPF-Received: 
X-UiO-Ratelimit-Test: rcpts/h 1 msgs/h 1 sum rcpts/h 4 sum msgs/h 4 total rcpts 12110 max rcpts/h 44 ratelimit 0
X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO)
X-UiO-Scanned: 2B62F071359DB47D58B8B7DFA6538C5BEA15458F
X-UiO-SPAM-Test: remote_host: 79.140.208.33 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 3 total 63 max/h 8 blacklist 0 greylist 0 ratelimit 0
Subject: [apps-discuss] BOF on Transport Services (TAPS)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Jan 2014 14:39:45 -0000

Dear all,

A BOF called "TAPS" has been approved as a non-WG-forming BOF in London. =
The point of this activity is to move away from applications choosing =
"TCP" or "UDP" by letting them select a service instead. This is bound =
to let the transport layer evolve - details are at: =
https://sites.google.com/site/transportprotocolservices/

Much of this is about the API that the transport layer exposes to =
applications. We had a bar BOF in Vancouver, where the major criticism =
was that we might be ignoring what applications *really* want, as many =
aren't really using the socket layer anyway. We're trying to counter =
this criticism as good as we can, because we really do want to do =
something useful here, something that does help applications. e.g., if =
the socket layer provided a richer set of services than "TCP" and "UDP", =
some of these services might be reasonably replicated in higher-level =
APIs; also, these higher-level APIs could be improved by using a richer =
set of services underneath - we've begun analyzing some in =
draft-hurtig-tsvwg-transport-apis

What's more, if there was a common API that's independent of the =
transport protocol, it wouldn't be necessary to implement functions like =
PMTUD, things for middlebox traversal etc. in the application per =
protocol, but these functions could be taken care of underneath the API, =
leading to a better integrated networking stack.

At this point, I'm hoping for folks from the applications area to join =
our mailing list and participate in discussions - raise your concerns =
there and help us create something that will really be useful. the list =
management page is at: =
https://sympa.uio.no/ifi.uio.no/info/transport-services

Cheers,
Michael


From ned.freed@mrochek.com  Wed Jan 29 06:50:24 2014
Return-Path: <ned.freed@mrochek.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C3931A03AB for <apps-discuss@ietfa.amsl.com>; Wed, 29 Jan 2014 06:50:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.437
X-Spam-Level: 
X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 SHuohrL8NL_D for <apps-discuss@ietfa.amsl.com>; Wed, 29 Jan 2014 06:50:23 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 653AF1A03DF for <apps-discuss@ietf.org>; Wed, 29 Jan 2014 06:50:22 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P3PTIF03SW003XSI@mauve.mrochek.com> for apps-discuss@ietf.org; Wed, 29 Jan 2014 06:45:16 -0800 (PST)
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=iso-8859-1; Format=flowed
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P3NP4TEOIO0000AS@mauve.mrochek.com>; Wed, 29 Jan 2014 06:45:10 -0800 (PST)
Message-id: <01P3PTIBT1WO0000AS@mauve.mrochek.com>
Date: Wed, 29 Jan 2014 06:43:18 -0800 (PST)
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Wed, 29 Jan 2014 10:13:32 +0100" <95944a51-a5ff-4741-be24-a6e63c567b5a@gulbrandsen.priv.no>
References: <20140128131859.GB75603@verdi> <20140128201031.28174.qmail@joyce.lan> <85d37e62-d8ac-4c23-8c7e-83a54216f75b@gulbrandsen.priv.no> <fea4f08f-818a-4fba-89eb-a99815e2f997@gulbrandsen.priv.no> <95944a51-a5ff-4741-be24-a6e63c567b5a@gulbrandsen.priv.no>
To: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] draft-martin-smtp-ipv6-to-ipv4-fallback
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Jan 2014 14:50:24 -0000

> As an example of how that might be:

>    If the server advertises the capability REJECTIONDETAILS, then certain
>    bracketed keywords in 4xx and 5xx responses to MAIL FROM, RCPT TO and
>    DATA mean as follows:

>      [MISSINGDKIM]  The lack of a DKIM signature is (part of) the reason
>                     for rejecting this transaction.

>      ...

> In some ways this would be like RFC 5530 (for IMAP), which has been
> surprisingly widely deployed. I like something along these lines a great
> deal better than "go back to ipv4".

Completely unnecessary. All you need to do is assign an enhanced status
code (5.7.x) for this purpose.

The absolute last thing SMTP needs is a third status code field in responses.

				Ned

From arnt@gulbrandsen.priv.no  Wed Jan 29 06:57:34 2014
Return-Path: <arnt@gulbrandsen.priv.no>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6504B1A03E6 for <apps-discuss@ietfa.amsl.com>; Wed, 29 Jan 2014 06:57:34 -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 ykXJofgcA39V for <apps-discuss@ietfa.amsl.com>; Wed, 29 Jan 2014 06:57:32 -0800 (PST)
Received: from strange.aox.org (strange.aox.org [80.244.248.170]) by ietfa.amsl.com (Postfix) with ESMTP id 516081A0218 for <apps-discuss@ietf.org>; Wed, 29 Jan 2014 06:57:32 -0800 (PST)
Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 588F7FA0069; Wed, 29 Jan 2014 14:57:28 +0000 (UTC)
Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1391007447-17068-17067/11/8; Wed, 29 Jan 2014 14:57:27 +0000
From: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
To: apps-discuss@ietf.org
Date: Wed, 29 Jan 2014 15:57:46 +0100
User-Agent: Trojita/v0.3.96-176-g713fcbb; Qt/4.8.4; X11; Linux; Ubuntu 13.10
Mime-Version: 1.0
Message-Id: <c8e958d1-2448-47cd-adbc-7d440dfa0363@gulbrandsen.priv.no>
In-Reply-To: <01P3PTIBT1WO0000AS@mauve.mrochek.com>
References: <20140128131859.GB75603@verdi> <20140128201031.28174.qmail@joyce.lan> <85d37e62-d8ac-4c23-8c7e-83a54216f75b@gulbrandsen.priv.no> <fea4f08f-818a-4fba-89eb-a99815e2f997@gulbrandsen.priv.no> <95944a51-a5ff-4741-be24-a6e63c567b5a@gulbrandsen.priv.no> <01P3PTIBT1WO0000AS@mauve.mrochek.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Subject: Re: [apps-discuss] draft-martin-smtp-ipv6-to-ipv4-fallback
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Jan 2014 14:57:34 -0000

On Wednesday, January 29, 2014 3:43:18 PM CEST, Ned Freed wrote:
> Completely unnecessary. All you need to do is assign an enhanced status

You're right of course. Stupid of me.

My point stands, though: It's better to point out the problems with the v6 
connection than to specify an RFC with a transtion from v6 to v4.

Arnt


From ned.freed@mrochek.com  Wed Jan 29 07:12:59 2014
Return-Path: <ned.freed@mrochek.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5ABD1A045F for <apps-discuss@ietfa.amsl.com>; Wed, 29 Jan 2014 07:12:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.437
X-Spam-Level: 
X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 UgFPgikLAnZl for <apps-discuss@ietfa.amsl.com>; Wed, 29 Jan 2014 07:12:58 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 5FB401A0452 for <apps-discuss@ietf.org>; Wed, 29 Jan 2014 07:12:57 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P3PUB8FH6O003VYB@mauve.mrochek.com> for apps-discuss@ietf.org; Wed, 29 Jan 2014 07:07:43 -0800 (PST)
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=iso-8859-1; Format=flowed
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P3NP4TEOIO0000AS@mauve.mrochek.com>; Wed, 29 Jan 2014 07:07:35 -0800 (PST)
Message-id: <01P3PUB3GWZ20000AS@mauve.mrochek.com>
Date: Wed, 29 Jan 2014 07:04:06 -0800 (PST)
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Wed, 29 Jan 2014 15:57:46 +0100" <c8e958d1-2448-47cd-adbc-7d440dfa0363@gulbrandsen.priv.no>
References: <20140128131859.GB75603@verdi> <20140128201031.28174.qmail@joyce.lan> <85d37e62-d8ac-4c23-8c7e-83a54216f75b@gulbrandsen.priv.no> <fea4f08f-818a-4fba-89eb-a99815e2f997@gulbrandsen.priv.no> <95944a51-a5ff-4741-be24-a6e63c567b5a@gulbrandsen.priv.no> <01P3PTIBT1WO0000AS@mauve.mrochek.com> <c8e958d1-2448-47cd-adbc-7d440dfa0363@gulbrandsen.priv.no>
To: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] draft-martin-smtp-ipv6-to-ipv4-fallback
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Jan 2014 15:13:00 -0000

> On Wednesday, January 29, 2014 3:43:18 PM CEST, Ned Freed wrote:
> > Completely unnecessary. All you need to do is assign an enhanced status

> You're right of course. Stupid of me.

> My point stands, though: It's better to point out the problems with the v6
> connection than to specify an RFC with a transtion from v6 to v4.

Quite right. And did we miss an opportunity to assign a similar code for
SPF failures in the recent revision to that document? I think we did...
damn it.

				Ned

From arnt@gulbrandsen.priv.no  Wed Jan 29 07:20:46 2014
Return-Path: <arnt@gulbrandsen.priv.no>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ADC41A03DF for <apps-discuss@ietfa.amsl.com>; Wed, 29 Jan 2014 07:20:46 -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 DOiOkBy5f2Gy for <apps-discuss@ietfa.amsl.com>; Wed, 29 Jan 2014 07:20:44 -0800 (PST)
Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id D969F1A03D5 for <apps-discuss@ietf.org>; Wed, 29 Jan 2014 07:20:43 -0800 (PST)
Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 3DB16FA003D; Wed, 29 Jan 2014 15:20:40 +0000 (UTC)
Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1391008838-17068-17067/11/9; Wed, 29 Jan 2014 15:20:38 +0000
From: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
To: apps-discuss@ietf.org
Date: Wed, 29 Jan 2014 16:20:58 +0100
User-Agent: Trojita/v0.3.96-176-g713fcbb; Qt/4.8.4; X11; Linux; Ubuntu 13.10
Mime-Version: 1.0
Message-Id: <bf1d64fa-957b-475c-b1d1-e7cd096799ef@gulbrandsen.priv.no>
In-Reply-To: <01P3PUB3GWZ20000AS@mauve.mrochek.com>
References: <20140128131859.GB75603@verdi> <20140128201031.28174.qmail@joyce.lan> <85d37e62-d8ac-4c23-8c7e-83a54216f75b@gulbrandsen.priv.no> <fea4f08f-818a-4fba-89eb-a99815e2f997@gulbrandsen.priv.no> <95944a51-a5ff-4741-be24-a6e63c567b5a@gulbrandsen.priv.no> <01P3PTIBT1WO0000AS@mauve.mrochek.com> <c8e958d1-2448-47cd-adbc-7d440dfa0363@gulbrandsen.priv.no> <01P3PUB3GWZ20000AS@mauve.mrochek.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Subject: Re: [apps-discuss] draft-martin-smtp-ipv6-to-ipv4-fallback
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Jan 2014 15:20:46 -0000

Ned Freed answers me:
> Quite right. And did we miss an opportunity to assign a similar code for
> SPF failures in the recent revision to that document? I think we did...
> damn it.

Well, it doesn't cost more to publish an RFC that defines three codes (SPF, 
DKIM and PTR) than just one ;)

I'm not sure I really like it. But it definitely is better than the thing 
that started this thread.

Arnt


From superuser@gmail.com  Wed Jan 29 08:18:58 2014
Return-Path: <superuser@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1511A04CC for <apps-discuss@ietfa.amsl.com>; Wed, 29 Jan 2014 08:18:58 -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 rufs96cwTxyd for <apps-discuss@ietfa.amsl.com>; Wed, 29 Jan 2014 08:18:56 -0800 (PST)
Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 1F8221A02C8 for <apps-discuss@ietf.org>; Wed, 29 Jan 2014 08:18:55 -0800 (PST)
Received: by mail-wg0-f46.google.com with SMTP id x12so3912822wgg.25 for <apps-discuss@ietf.org>; Wed, 29 Jan 2014 08:18: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 :cc:content-type; bh=hYuNzTK+QJR5Jafe2QjJP3H0drRP+xYBchsfwDoIFko=; b=dIw1JTz/+oYW14bh/+cwjUtYPldbvKxhOE6X3CuXnmRjXtvQa5IWKET1lWNGLvziu1 H/HcCxP0QE24UTP+piMpszuybAVIpF4qj+JfJbfkYg+NKzBf9sehWC7r5+RY1/Vq/k1B zpE0faBcwSV1+NZAB1p3TGwj4r50NatquRyFoHhyknaSMU9ppAVKrqp7lgAYwPruAnHE zZu0NP5M/BT3gfu5PoAAiSJWu/tFWdymJXzkOZHLliEDClrPCjjJ0bmMZp0dgS4YZjY6 vAjpwSmdvb0xJLTpKUM1//knGEAfAsLqv6r5h1scGOMCbFG2alnE2JyP8cpjCUGVwiCN SRtw==
MIME-Version: 1.0
X-Received: by 10.194.77.7 with SMTP id o7mr2454882wjw.35.1391012332728; Wed, 29 Jan 2014 08:18:52 -0800 (PST)
Received: by 10.180.98.41 with HTTP; Wed, 29 Jan 2014 08:18:52 -0800 (PST)
In-Reply-To: <bf1d64fa-957b-475c-b1d1-e7cd096799ef@gulbrandsen.priv.no>
References: <20140128131859.GB75603@verdi> <20140128201031.28174.qmail@joyce.lan> <85d37e62-d8ac-4c23-8c7e-83a54216f75b@gulbrandsen.priv.no> <fea4f08f-818a-4fba-89eb-a99815e2f997@gulbrandsen.priv.no> <95944a51-a5ff-4741-be24-a6e63c567b5a@gulbrandsen.priv.no> <01P3PTIBT1WO0000AS@mauve.mrochek.com> <c8e958d1-2448-47cd-adbc-7d440dfa0363@gulbrandsen.priv.no> <01P3PUB3GWZ20000AS@mauve.mrochek.com> <bf1d64fa-957b-475c-b1d1-e7cd096799ef@gulbrandsen.priv.no>
Date: Wed, 29 Jan 2014 08:18:52 -0800
Message-ID: <CAL0qLwYSaxvs+-P48MZr0=421_L36FNrr4uPw2G2+keX28f+_w@mail.gmail.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
To: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
Content-Type: multipart/alternative; boundary=047d7bfd05fcf8788104f11e4bda
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] draft-martin-smtp-ipv6-to-ipv4-fallback
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Jan 2014 16:18:58 -0000

--047d7bfd05fcf8788104f11e4bda
Content-Type: text/plain; charset=ISO-8859-1

I'll take this on if you two (and hopefully others) will support such a
draft with reviews and comments.


On Wed, Jan 29, 2014 at 7:20 AM, Arnt Gulbrandsen
<arnt@gulbrandsen.priv.no>wrote:

> Ned Freed answers me:
>
>  Quite right. And did we miss an opportunity to assign a similar code for
>> SPF failures in the recent revision to that document? I think we did...
>> damn it.
>>
>
> Well, it doesn't cost more to publish an RFC that defines three codes
> (SPF, DKIM and PTR) than just one ;)
>
> I'm not sure I really like it. But it definitely is better than the thing
> that started this thread.
>
> Arnt
>
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

--047d7bfd05fcf8788104f11e4bda
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I&#39;ll take this on if you two (and hopefully others) wi=
ll support such a draft with reviews and comments.<br></div><div class=3D"g=
mail_extra"><br><br><div class=3D"gmail_quote">On Wed, Jan 29, 2014 at 7:20=
 AM, Arnt Gulbrandsen <span dir=3D"ltr">&lt;<a href=3D"mailto:arnt@gulbrand=
sen.priv.no" target=3D"_blank">arnt@gulbrandsen.priv.no</a>&gt;</span> wrot=
e:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Ned Freed answers me:<div class=3D"im"><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Quite right. And did we miss an opportunity to assign a similar code for<br=
>
SPF failures in the recent revision to that document? I think we did...<br>
damn it.<br>
</blockquote>
<br></div>
Well, it doesn&#39;t cost more to publish an RFC that defines three codes (=
SPF, DKIM and PTR) than just one ;)<br>
<br>
I&#39;m not sure I really like it. But it definitely is better than the thi=
ng that started this thread.<span class=3D"HOEnZb"><font color=3D"#888888">=
<br>
<br>
Arnt</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
______________________________<u></u>_________________<br>
apps-discuss mailing list<br>
<a href=3D"mailto:apps-discuss@ietf.org" target=3D"_blank">apps-discuss@iet=
f.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/apps-discuss" target=3D"_b=
lank">https://www.ietf.org/mailman/<u></u>listinfo/apps-discuss</a><br>
</div></div></blockquote></div><br></div>

--047d7bfd05fcf8788104f11e4bda--

From aljf1981@gmail.com  Wed Jan 29 11:31:56 2014
Return-Path: <aljf1981@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 226141A03F6 for <apps-discuss@ietfa.amsl.com>; Wed, 29 Jan 2014 11:31:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level: 
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 y4_KDSdiQt2L for <apps-discuss@ietfa.amsl.com>; Wed, 29 Jan 2014 11:31:54 -0800 (PST)
Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 64A7B1A0361 for <apps-discuss@ietf.org>; Wed, 29 Jan 2014 11:31:54 -0800 (PST)
Received: by mail-qc0-f174.google.com with SMTP id x13so3476320qcv.33 for <apps-discuss@ietf.org>; Wed, 29 Jan 2014 11:31:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/HF7sejxc9zcfQhRlJ6poxBXeGJGQNCkKraUFD2DGfI=; b=OuBZIGt5Ic/OPNt2qys80FAv4+Xsw8RFxrP+nDWiZDxi+95Yd3+JObrd0gW0+kz+BJ 2Iv9ItRdzreXjO52E2nCdpgFkTU3irScLqH5wVSTAcH+aiYVmitZ2gAXMGAuSmBKIQ0t VTd08txb8RGkbFTjnH2QzyjiMBen7N+aiiOhkOwi6qSHR0MXXUeSpRppI+eTNYWLcy1g nMA+wBP88pAIRYHJV6Mi3LSPKSSsmOVNP0mPA5VHMNjj4xYZLqUNSWOly1XEfktQtbYD ojIa+0dz2X93vacxGTaEL0oANE3UU08EWjR6nK3BIEgTqSPRdEMfvQxyP3G5UIXA9SuW fcJQ==
MIME-Version: 1.0
X-Received: by 10.224.74.74 with SMTP id t10mr15408173qaj.82.1391023911192; Wed, 29 Jan 2014 11:31:51 -0800 (PST)
Received: by 10.96.185.6 with HTTP; Wed, 29 Jan 2014 11:31:51 -0800 (PST)
In-Reply-To: <CAL0qLwYSaxvs+-P48MZr0=421_L36FNrr4uPw2G2+keX28f+_w@mail.gmail.com>
References: <20140128131859.GB75603@verdi> <20140128201031.28174.qmail@joyce.lan> <85d37e62-d8ac-4c23-8c7e-83a54216f75b@gulbrandsen.priv.no> <fea4f08f-818a-4fba-89eb-a99815e2f997@gulbrandsen.priv.no> <95944a51-a5ff-4741-be24-a6e63c567b5a@gulbrandsen.priv.no> <01P3PTIBT1WO0000AS@mauve.mrochek.com> <c8e958d1-2448-47cd-adbc-7d440dfa0363@gulbrandsen.priv.no> <01P3PUB3GWZ20000AS@mauve.mrochek.com> <bf1d64fa-957b-475c-b1d1-e7cd096799ef@gulbrandsen.priv.no> <CAL0qLwYSaxvs+-P48MZr0=421_L36FNrr4uPw2G2+keX28f+_w@mail.gmail.com>
Date: Wed, 29 Jan 2014 17:31:51 -0200
Message-ID: <CALJ-P7mL3b-OnRBR2owJSauEym1HKuad9t+H_zM9zTV8bQsAXA@mail.gmail.com>
From: Andre Luis <aljf1981@gmail.com>
To: "Murray S. Kucherawy" <superuser@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c3ec6a19cea204f120fef2
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] draft-martin-smtp-ipv6-to-ipv4-fallback
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Jan 2014 19:31:56 -0000

--001a11c3ec6a19cea204f120fef2
Content-Type: text/plain; charset=ISO-8859-1

I think mutch profiable create RFCs for normalize the parameters of
protocols of th internet get away in the benefits of self have an Internet
regulated
I proporse an discussion for the preparation of an RFC in this one sense


2014/1/29 Murray S. Kucherawy <superuser@gmail.com>

> I'll take this on if you two (and hopefully others) will support such a
> draft with reviews and comments.
>
>
> On Wed, Jan 29, 2014 at 7:20 AM, Arnt Gulbrandsen <
> arnt@gulbrandsen.priv.no> wrote:
>
>> Ned Freed answers me:
>>
>>  Quite right. And did we miss an opportunity to assign a similar code for
>>> SPF failures in the recent revision to that document? I think we did...
>>> damn it.
>>>
>>
>> Well, it doesn't cost more to publish an RFC that defines three codes
>> (SPF, DKIM and PTR) than just one ;)
>>
>> I'm not sure I really like it. But it definitely is better than the thing
>> that started this thread.
>>
>> Arnt
>>
>>
>> _______________________________________________
>> 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
>
>

--001a11c3ec6a19cea204f120fef2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I think mutch profiable create RFCs for normalize the para=
meters of protocols of th internet get away in the benefits of self have an=
 Internet regulated=A0<div>I proporse an discussion for the preparation of =
an RFC in this one sense</div>
</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">2014/1/=
29 Murray S. Kucherawy <span dir=3D"ltr">&lt;<a href=3D"mailto:superuser@gm=
ail.com" target=3D"_blank">superuser@gmail.com</a>&gt;</span><br><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex">
<div dir=3D"ltr">I&#39;ll take this on if you two (and hopefully others) wi=
ll support such a draft with reviews and comments.<br></div><div class=3D"H=
OEnZb"><div class=3D"h5"><div class=3D"gmail_extra"><br><br><div class=3D"g=
mail_quote">
On Wed, Jan 29, 2014 at 7:20 AM, Arnt Gulbrandsen <span dir=3D"ltr">&lt;<a =
href=3D"mailto:arnt@gulbrandsen.priv.no" target=3D"_blank">arnt@gulbrandsen=
.priv.no</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Ned Freed answers me:<div><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Quite right. And did we miss an opportunity to assign a similar code for<br=
>
SPF failures in the recent revision to that document? I think we did...<br>
damn it.<br>
</blockquote>
<br></div>
Well, it doesn&#39;t cost more to publish an RFC that defines three codes (=
SPF, DKIM and PTR) than just one ;)<br>
<br>
I&#39;m not sure I really like it. But it definitely is better than the thi=
ng that started this thread.<span><font color=3D"#888888"><br>
<br>
Arnt</font></span><div><div><br>
<br>
______________________________<u></u>_________________<br>
apps-discuss mailing list<br>
<a href=3D"mailto:apps-discuss@ietf.org" target=3D"_blank">apps-discuss@iet=
f.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/apps-discuss" target=3D"_b=
lank">https://www.ietf.org/mailman/<u></u>listinfo/apps-discuss</a><br>
</div></div></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
apps-discuss mailing list<br>
<a href=3D"mailto:apps-discuss@ietf.org">apps-discuss@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/apps-discuss" target=3D"_b=
lank">https://www.ietf.org/mailman/listinfo/apps-discuss</a><br>
<br></blockquote></div><br></div>

--001a11c3ec6a19cea204f120fef2--

From franck@peachymango.org  Wed Jan 29 12:06:55 2014
Return-Path: <franck@peachymango.org>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ACEC1A02B6 for <apps-discuss@ietfa.amsl.com>; Wed, 29 Jan 2014 12:06:55 -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 SvJV2PcXvIdL for <apps-discuss@ietfa.amsl.com>; Wed, 29 Jan 2014 12:06:53 -0800 (PST)
Received: from smtp.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id C732C1A0248 for <apps-discuss@ietf.org>; Wed, 29 Jan 2014 12:06:53 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id CC1EF3F6DFD; Wed, 29 Jan 2014 14:06:50 -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 aizq-S1OXFN7; Wed, 29 Jan 2014 14:06:50 -0600 (CST)
Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id AE4AD3F6E02; Wed, 29 Jan 2014 14:06:50 -0600 (CST)
Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id A0B5D3F6E00; Wed, 29 Jan 2014 14:06:50 -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 PrDnSgbmri0C; Wed, 29 Jan 2014 14:06:50 -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 750703F6DFD; Wed, 29 Jan 2014 14:06:50 -0600 (CST)
Date: Wed, 29 Jan 2014 14:06:49 -0600 (CST)
From: Franck Martin <franck@peachymango.org>
To: Ned Freed <ned.freed@mrochek.com>
Message-ID: <1758787190.59583.1391026009351.JavaMail.zimbra@peachymango.org>
In-Reply-To: <WM!bf1d1358f6e0c2c07bf67308ff6142eea4e74008a28b1026371c77f1d2f55a91bd8aa36df792d2bb9a913914933b45ce!@asav-2.01.com>
References: <20140128131859.GB75603@verdi> <20140128201031.28174.qmail@joyce.lan> <85d37e62-d8ac-4c23-8c7e-83a54216f75b@gulbrandsen.priv.no> <fea4f08f-818a-4fba-89eb-a99815e2f997@gulbrandsen.priv.no> <95944a51-a5ff-4741-be24-a6e63c567b5a@gulbrandsen.priv.no> <01P3PTIBT1WO0000AS@mauve.mrochek.com> <WM!bf1d1358f6e0c2c07bf67308ff6142eea4e74008a28b1026371c77f1d2f55a91bd8aa36df792d2bb9a913914933b45ce!@asav-2.01.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 - FF26 (Mac)/8.0.5_GA_5839)
Thread-Topic: draft-martin-smtp-ipv6-to-ipv4-fallback
Thread-Index: PxRLQA37a4GjbSxqzDbv4QHhWy3B7w==
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] draft-martin-smtp-ipv6-to-ipv4-fallback
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Jan 2014 20:06:55 -0000

----- Original Message -----
> From: "Ned Freed" <ned.freed@mrochek.com>
> To: "Arnt Gulbrandsen" <arnt@gulbrandsen.priv.no>
> Cc: apps-discuss@ietf.org
> Sent: Wednesday, January 29, 2014 6:43:18 AM
> Subject: Re: [apps-discuss] draft-martin-smtp-ipv6-to-ipv4-fallback
> 
> > As an example of how that might be:
> 
> >    If the server advertises the capability REJECTIONDETAILS, then certain
> >    bracketed keywords in 4xx and 5xx responses to MAIL FROM, RCPT TO and
> >    DATA mean as follows:
> 
> >      [MISSINGDKIM]  The lack of a DKIM signature is (part of) the reason
> >                     for rejecting this transaction.
> 
> >      ...
> 
> > In some ways this would be like RFC 5530 (for IMAP), which has been
> > surprisingly widely deployed. I like something along these lines a great
> > deal better than "go back to ipv4".
> 
> Completely unnecessary. All you need to do is assign an enhanced status
> code (5.7.x) for this purpose.
> 
> The absolute last thing SMTP needs is a third status code field in responses.

Agreed on the creation of Enhanced Status code for SPF, DKIM, PTR, however this is not read by MTAs, and not acted upon, this is read later by "bounce processors" to, for instance, update the status of the emails in a sending list. The MTA acts on 4xx or 5xx, I don't know any that acts synchronously on enhanced status codes.

The problem of rejecting a message (permfail) due to say failed DKIM, is that you reject a message that would have been perfectly accepted if it was sent over IPv4. The mailbox receiver now gets complains because "mum cannot send me emails", therefore the mailbox receivers disable IPv6 SMTP, or let anything in and hope for the best.

I'm not sure that receivers are willing to permfail on non spam emails because of technicalities. This draft allows to not permfails emails, but ensure mandatory domain reputation over IPv6.

I'm cool about this ID to be informational and not propose new protocols, I needed mainly to document this behavior, but after talking to some folks it was suggested the path to standard was better. 

Anyhow, I'm listening to the list traffic. We have an opportunity to kind of mandate authenticated emails over IPv6, rather than tell dummies they should authenticate their emails and hope for the best.

From prvs=00995a0cdf=johnl@iecc.com  Wed Jan 29 12:28:46 2014
Return-Path: <prvs=00995a0cdf=johnl@iecc.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D8E11A0372 for <apps-discuss@ietfa.amsl.com>; Wed, 29 Jan 2014 12:28:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.537
X-Spam-Level: 
X-Spam-Status: No, score=-2.537 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.535, 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 YLj-zzlDgdby for <apps-discuss@ietfa.amsl.com>; Wed, 29 Jan 2014 12:28:44 -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 6DB1D1A0370 for <apps-discuss@ietf.org>; Wed, 29 Jan 2014 12:28:44 -0800 (PST)
Received: (qmail 50107 invoked from network); 29 Jan 2014 20:28:40 -0000
Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 29 Jan 2014 20:28:40 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=52e96478.xn--i8sz2z.k1401; i=johnl@user.iecc.com; bh=soJIM9hytZ7BQoLjtywn4e52QgOkKNDKS45vfMJPDRs=; b=Hb54XYpTlUnsXfGawxvYV/k30U3d4JshSss8BUSN8FtMYokaVigp2PqKgywNRcRew/oseAcxfYdLmD9uSVEKW1CnaagPwA4sFcA98Ktpq1bHhbVdQ4zyKNagBBBdGrDr4zdgswYlYslpY+asHF4cc4zp+K9wKP9cTXsizI42eMyQxIyTPP2Q1QCo3OfoDJV0uv7fU7Ttv0Y8knWKx0DTv6FejFQ4Vu6cUt/DmrnuXEDOm/zqiG9i0Z5UiR0raZSF
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=52e96478.xn--i8sz2z.k1401; olt=johnl@user.iecc.com; bh=soJIM9hytZ7BQoLjtywn4e52QgOkKNDKS45vfMJPDRs=; b=UBjyRAuDcv7LPtMs5xDluplligZyNHSReU44lDPZtRz+NZin2LP6M3/bJnPonwD0rSaKpHDiZ+NX9a9cigq3QIjYHfpxDCNHSFv0iMlteX1l+dkNyQTSkq5oxp2l4vKs/aYaaMHN8mrwlNiJLwJKro+V+oITN5jsNJMiupT7nbdsIgav7576Clr7SQnkdCvWXIcUSH6XOV/njdpYMfwJzZatBsevvoun/Zkp28q9EtOqCZ5CyPXN1IyGESTfZQI0
Date: 29 Jan 2014 20:28:17 -0000
Message-ID: <20140129202817.9644.qmail@joyce.lan>
From: "John Levine" <johnl@taugh.com>
To: apps-discuss@ietf.org
In-Reply-To: <CAL0qLwYSaxvs+-P48MZr0=421_L36FNrr4uPw2G2+keX28f+_w@mail.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] draft-martin-smtp-ipv6-to-ipv4-fallback
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Jan 2014 20:28:46 -0000

In article <CAL0qLwYSaxvs+-P48MZr0=421_L36FNrr4uPw2G2+keX28f+_w@mail.gmail.com> you write:
> [ draft to define "you need DKIM" and other codes ]
>I'll take this on if you two (and hopefully others) will support such a
>draft with reviews and comments.

Sure.  At worst it's harmless, at best it'll help people diagnose
their mail problems.

Regards,
John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly


From prvs=00995a0cdf=johnl@iecc.com  Wed Jan 29 12:30:26 2014
Return-Path: <prvs=00995a0cdf=johnl@iecc.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6190C1A03CD for <apps-discuss@ietfa.amsl.com>; Wed, 29 Jan 2014 12:30:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.537
X-Spam-Level: 
X-Spam-Status: No, score=-2.537 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.535, 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 uX889Whrfhrk for <apps-discuss@ietfa.amsl.com>; Wed, 29 Jan 2014 12:30: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 9ECF51A0370 for <apps-discuss@ietf.org>; Wed, 29 Jan 2014 12:30:24 -0800 (PST)
Received: (qmail 50261 invoked from network); 29 Jan 2014 20:30:20 -0000
Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 29 Jan 2014 20:30:20 -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=52e964dd.xn--30v786c.k1401; i=johnl@user.iecc.com; bh=LYyPi+4M0Ft6ShJ50+YDPGIfKlD7H7B4TvdxVUqFy8Q=; b=bW7GvvGdeXPwBtXlpkrx/DyjhKkme1+UjnVVeMH+MpiEqppaDwvK9WA/0wkJOWAB/YOSDc70213GPSpHR5YGDvMPR+JY5yQ/SM5GIGqTclj33N/fzFsnjc42u1y7LAuHzKClPzHuo5zbJrJMDNwiVLYRLL+7ffEG1+QMN/Zya8dk4Ks7ENxmriAiDeFHpd9Sp24KsBR5pHsCVMQhNGATpKWIIKX08XJwtQrMIMQCEKYEbUDdiMWS83JpW/KJlZ9v
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=52e964dd.xn--30v786c.k1401; olt=johnl@user.iecc.com; bh=LYyPi+4M0Ft6ShJ50+YDPGIfKlD7H7B4TvdxVUqFy8Q=; b=yb0GS0eoUJ35HYBjP1XOd1HGLXarH0AinPjGxzG1OQsRvtE6j662UW2CuOV0M0TJlhe3K5Wfvwx8HXOYUQPwoAOn+LEwVpMDp/+CbbWyuUYNTUrahLTJxopjFCeFyRHUeSEc6a8975RoM7b7VSZZdOAek5nJGlXkoM2dyb/HqBgfwEh4GXVJ9CrGAyGwDCm0prntNu0xAYw1m764X1o+9afCdPAzzUtdVDqs8sqASDRdGqPpa8pCtUTFYzMmvTAU
Date: 29 Jan 2014 20:29:58 -0000
Message-ID: <20140129202958.9668.qmail@joyce.lan>
From: "John Levine" <johnl@taugh.com>
To: apps-discuss@ietf.org
In-Reply-To: <1758787190.59583.1391026009351.JavaMail.zimbra@peachymango.org>
Organization: 
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Subject: Re: [apps-discuss] draft-martin-smtp-ipv6-to-ipv4-fallback
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Jan 2014 20:30:26 -0000

>Agreed on the creation of Enhanced Status code for SPF, DKIM, PTR, however this is not read by
>MTAs, and not acted upon, ...

In this case, it's read by people looking at the logs and trying to
diagnose their mail problems.

>I'm not sure that receivers are willing to permfail on non spam emails because of
>technicalities. This draft allows to not permfails emails, but ensure mandatory domain
>reputation over IPv6.

Um, why do you think MTAs can't put enhanced status codes on 4xx rejections?

R's,
John

From franck@peachymango.org  Wed Jan 29 14:23:27 2014
Return-Path: <franck@peachymango.org>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDCFF1A03FA for <apps-discuss@ietfa.amsl.com>; Wed, 29 Jan 2014 14:23:27 -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 7NxIZ6H7Ygg1 for <apps-discuss@ietfa.amsl.com>; Wed, 29 Jan 2014 14:23:26 -0800 (PST)
Received: from smtp.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id 3CFCE1A03F8 for <apps-discuss@ietf.org>; Wed, 29 Jan 2014 14:23:26 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 285D53F6D8D for <apps-discuss@ietf.org>; Wed, 29 Jan 2014 16:23:23 -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 dlK3Wd-oFGiI for <apps-discuss@ietf.org>; Wed, 29 Jan 2014 16:23:23 -0600 (CST)
Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 0CB0D3F6DF4 for <apps-discuss@ietf.org>; Wed, 29 Jan 2014 16:23:23 -0600 (CST)
Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 00F443F6DED for <apps-discuss@ietf.org>; Wed, 29 Jan 2014 16:23:23 -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 9EcoonsALV6j for <apps-discuss@ietf.org>; Wed, 29 Jan 2014 16:23:22 -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 DE43E3F6D8D for <apps-discuss@ietf.org>; Wed, 29 Jan 2014 16:23:22 -0600 (CST)
Date: Wed, 29 Jan 2014 16:23:22 -0600 (CST)
From: Franck Martin <franck@peachymango.org>
To: apps-discuss@ietf.org
Message-ID: <1060109933.65136.1391034201999.JavaMail.zimbra@peachymango.org>
In-Reply-To: <WM!ad4c4d4721536afae2a72b8be2443a1e3f06fde366599b8cb0902b92bf42695b628945cc41c33308cdc8475671ca6e85!@asav-3.01.com>
References: <20140129202958.9668.qmail@joyce.lan> <WM!ad4c4d4721536afae2a72b8be2443a1e3f06fde366599b8cb0902b92bf42695b628945cc41c33308cdc8475671ca6e85!@asav-3.01.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 - FF26 (Mac)/8.0.5_GA_5839)
Thread-Topic: draft-martin-smtp-ipv6-to-ipv4-fallback
Thread-Index: YXUvdc5coHuJuNinxQWVaV5O5iT9kw==
Subject: Re: [apps-discuss] draft-martin-smtp-ipv6-to-ipv4-fallback
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Jan 2014 22:23:28 -0000

----- Original Message -----
> From: "John Levine" <johnl@taugh.com>
> To: apps-discuss@ietf.org
> Cc: franck@peachymango.org
> Sent: Wednesday, January 29, 2014 12:29:58 PM
> Subject: Re: [apps-discuss] draft-martin-smtp-ipv6-to-ipv4-fallback
> 
> >Agreed on the creation of Enhanced Status code for SPF, DKIM, PTR, however
> >this is not read by
> >MTAs, and not acted upon, ...
> 
> In this case, it's read by people looking at the logs and trying to
> diagnose their mail problems.

Thanks for rephrasing

> 
> >I'm not sure that receivers are willing to permfail on non spam emails
> >because of
> >technicalities. This draft allows to not permfails emails, but ensure
> >mandatory domain
> >reputation over IPv6.
> 
> Um, why do you think MTAs can't put enhanced status codes on 4xx rejections?
> 

I don't:
http://tools.ietf.org/html/draft-martin-smtp-ipv6-to-ipv4-fallback-00#section-5.1

From tzink@exchange.microsoft.com  Wed Jan 29 14:39:25 2014
Return-Path: <tzink@exchange.microsoft.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24E891A03C2 for <apps-discuss@ietfa.amsl.com>; Wed, 29 Jan 2014 14:39:25 -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 2v3KRgkyCv9i for <apps-discuss@ietfa.amsl.com>; Wed, 29 Jan 2014 14:39:23 -0800 (PST)
Received: from na01-by1-obe.outbound.o365filtering.com (na01-by1-obe.ptr.o365filtering.com [64.4.22.92]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0CE1A03AA for <apps-discuss@ietf.org>; Wed, 29 Jan 2014 14:39:23 -0800 (PST)
Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com (10.255.109.167) by BL2SR01MB606.namsdf01.sdf.exchangelabs.com (10.255.109.168) with Microsoft SMTP Server (TLS) id 15.0.878.3; Wed, 29 Jan 2014 22:39:18 +0000
Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.6.9]) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.6.194]) with mapi id 15.00.0878.003; Wed, 29 Jan 2014 22:39:18 +0000
From: Terry Zink <tzink@exchange.microsoft.com>
To: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Thread-Topic: [apps-discuss] draft-martin-smtp-ipv6-to-ipv4-fallback
Thread-Index: AQHPHCuH3cerTEp5TUatiLegOJobepqakaaAgAAkXouAAKIhRoAAFEYAgABeJEaAAAIKAIAABEQGgAACNwCAAHmokA==
Date: Wed, 29 Jan 2014 22:39:18 +0000
Message-ID: <4d1246dd86194193b20692a7c7ee7c3b@BL2SR01MB605.namsdf01.sdf.exchangelabs.com>
References: <20140128131859.GB75603@verdi> <20140128201031.28174.qmail@joyce.lan> <85d37e62-d8ac-4c23-8c7e-83a54216f75b@gulbrandsen.priv.no> <fea4f08f-818a-4fba-89eb-a99815e2f997@gulbrandsen.priv.no> <95944a51-a5ff-4741-be24-a6e63c567b5a@gulbrandsen.priv.no> <01P3PTIBT1WO0000AS@mauve.mrochek.com> <c8e958d1-2448-47cd-adbc-7d440dfa0363@gulbrandsen.priv.no> <01P3PUB3GWZ20000AS@mauve.mrochek.com> <bf1d64fa-957b-475c-b1d1-e7cd096799ef@gulbrandsen.priv.no>
In-Reply-To: <bf1d64fa-957b-475c-b1d1-e7cd096799ef@gulbrandsen.priv.no>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [131.107.160.2]
x-forefront-prvs: 01068D0A20
x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(199002)(189002)(377454003)(13464003)(76482001)(63696002)(77096001)(76786001)(76796001)(77982001)(54316002)(56776001)(4396001)(74876001)(79102001)(93516002)(93136001)(93886001)(94316002)(80976001)(49866001)(47736001)(74706001)(81816001)(81686001)(47976001)(50986001)(19580405001)(59766001)(51856001)(87936001)(53806001)(92566001)(83072002)(54356001)(90146001)(85852003)(56816005)(85306002)(15975445006)(46102001)(2656002)(65816001)(69226001)(81542001)(31966008)(87266001)(47446002)(74662001)(74502001)(19580395003)(83322001)(74366001)(66066001)(80022001)(81342001)(94946001)(33646001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2SR01MB606; H:BL2SR01MB605.namsdf01.sdf.exchangelabs.com; CLIP:131.107.160.2; FPR:E019D177.8FF36FFA.9F4B964.4CFDFF1.20204; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: exchange.microsoft.com
Subject: Re: [apps-discuss] draft-martin-smtp-ipv6-to-ipv4-fallback
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Jan 2014 22:39:25 -0000

> Well, it doesn't cost more to publish an RFC that defines three codes (SP=
F, DKIM and PTR)=20
> than just one ;)

Wouldn't this require only two codes for IPv6, and not three:

1) x.x.x Message does not have a PTR
2) x.x.x Message does not pass either SPF or DKIM

A message can pass SPF and not DKIM, or DKIM but not SPF, and still be acce=
pted by the email receiver. Therefore, a third one is not required individu=
ally (one for no SPF and one for no DKIM).

-- Terry

-----Original Message-----
From: apps-discuss [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Arnt=
 Gulbrandsen
Sent: Wednesday, January 29, 2014 7:21 AM
To: apps-discuss@ietf.org
Subject: Re: [apps-discuss] draft-martin-smtp-ipv6-to-ipv4-fallback

Ned Freed answers me:
> Quite right. And did we miss an opportunity to assign a similar code=20
> for SPF failures in the recent revision to that document? I think we did.=
..
> damn it.

Well, it doesn't cost more to publish an RFC that defines three codes (SPF,=
 DKIM and PTR) than just one ;)

I'm not sure I really like it. But it definitely is better than the thing t=
hat started this thread.

Arnt

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

From mnot@mnot.net  Wed Jan 29 19:42:01 2014
Return-Path: <mnot@mnot.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 654061A035D for <apps-discuss@ietfa.amsl.com>; Wed, 29 Jan 2014 19:42:01 -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 nKg3id--Glxs for <apps-discuss@ietfa.amsl.com>; Wed, 29 Jan 2014 19:41:57 -0800 (PST)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id F1C841A02EA for <apps-discuss@ietf.org>; Wed, 29 Jan 2014 19:41:56 -0800 (PST)
Received: from [192.168.1.55] (unknown [118.209.40.94]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 4A46550A84; Wed, 29 Jan 2014 22:41:50 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <52C2E825.9010405@dcrocker.net>
Date: Thu, 30 Jan 2014 14:41:46 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: <2278BFA5-0C88-4FDD-9EF7-2D8A20E9E2DF@mnot.net>
References: <52C2E825.9010405@dcrocker.net>
To: Dave Crocker <dcrocker@bbiw.net>
X-Mailer: Apple Mail (2.1827)
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Review of: draft-ietf-appsawg-uri-get-off-my-lawn-00
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Jan 2014 03:42:01 -0000

Hi Dave,

Thanks for the review. Some responses below. Latest source with updates =
is at:
  https://raw.github.com/mnot/I-D/master/uri-get-off-my-lawn/draft.md


On 1 Jan 2014, at 2:52 am, Dave Crocker <dhc@dcrocker.net> wrote:
>=20
> Summary:
>=20
>     URIs are the core citation and client transaction (request) form =
on the Internet.  Anything used that widely and in such variable =
circumstances is likely to get ad hoc tailoring for use with particular =
applications and/or particular implementations and/or particular =
servers.  The "and/or" combinations highlight the potential for chaotic =
tailoring which, therefore, creates ambiguities and conflicts.   The =
current draft seeks to impose better global discipline on the use of =
URIs.
>=20
>    For a construct as important as a URI, the importance of moving =
towards clean and unconflicted use can't be overstated.  However the =
requirements that prompt the ad hoc tailoring typically are legitimate, =
even if the method of dealing with it is problematic.  So the challenges =
here are in clarity and precision about what should /not/ be done, =
sufficiency in the available alternatives, and clarity in the way all =
this is explained.  Any specification needs to worry that it is =
adequately understandable to a reader new to the topic, but in the case =
of a document attempting to repair existing confusion and misbehavior, =
it is especially important:  the document needs an added degree of tight =
and coherent organization, with very pedantic logical sequences to what =
is said, and very careful wording that says it.
>=20
> Unfortunately, at the highest level, I'm not sure how this document =
can be used, for those most needing to use it.  It's not a question of =
whether the document isn't chock full of specific advice.  And the issue =
is separate from agreeing or disagreeing with any of the points made in =
the document.  It's a question of how it is organized for long-term use. =
 The current form of the document doesn't seem tightly-enough organized =
for that use, but I'm not sure what to suggest.  In addition, it varies =
between portions that appear to be protocol specification, versus =
portions that appear to be best current practices.
>=20
> Also I found myself periodically confused about the exact meaning of =
text in the document.  Some of this might merely need somewhat more =
careful wording.  Some of the confusion might be due to deeper issues =
with the document.  I'm not sure.  Obviously some of the confusion could =
be my own limitations, but I spent some time trying to track things down =
and was still left confused, as noted below.

Upon some reflection, I feel some sympathy, in that I feel the same way =
about the comments above, I think. :)

What would you like to see -- can you give me something actionable?


> The title of the document asserts that it is /creating/ structure for =
URI's, but I believe it is, instead, mostly clarifying /existing/ =
structure.  Beyond that I believe that it is at most making -- or, at =
least, intending to make -- modest tweaks.  (I see that as a Good Thing, =
for something like this.  Anything more ambitious would probably disrupt =
current, legitimate uses of URIs...)

I've changed the title.


> Detailed Comments:
>=20
>> Abstract
>>=20
>>   Sometimes, it is attractive to add features to protocols or
>>   applications by specifying a particular structure for URIs (or =
parts
>>   thereof).  This document cautions against this practice in =
standards
>>   (sometimes called "URI Squatting").
>=20
> This implies that URIs must not have any 'features' or 'structure'. I =
think that what is meant is more limited than that.  So what is needed =
is a statement to balance, that indicates what is normal and acceptable. =
 Maybe that's just a pointer to Section 3, but I suspect there's more =
needed than that.
>=20
> Note, for example, that the URI spec (RFC 3986) allocates the role of =
providing "generative grammar for URIs; that task is performed by the =
individual specifications of each URI scheme."  A grammar is, by =
definition, a structure.  So some sorts of structures are acceptable, in =
some sorts of specifications.  What is ok and what isn't ok needs to be =
clarified.
>=20
> That leaves a basic question for the current draft:  when/where is =
acceptable for specifying functions and structures in a URI and =
when/where isn't?
>=20
> In addition, the use of sub-structure in URI's is integral to many, =
established web practices.  Again:  this document needs to distinguish =
between those and whatever others that are /not/ acceptable.

The document is very clear that it applies to standards, not people =
deploying their own servers as they choose.=20


>> 1.  Introduction
>>=20
>>   URIs [RFC3986] very often include structured application data.  =
This
>=20
> In spite of the examples provided in the next sentence, it isn't =
obvious to me what "structured application data" means.  Yet it's the =
key construct for the document.

There are examples below, but I do agree they're somewhat abstract. Will =
try to make them more concrete.


>>   might include artifacts from filesystems (often occurring in the =
path
>>   component), and user information (often in the query component).  =
In
>>   some cases, there can even be application-specific data in the
>>   authority component (e.g., some applications are spread across
>>   several hostnames to enable a form of partitioning or dispatch).
>>=20
>>   Furthermore, constraints upon the structure of URIs can be imposed =
by
>>   an implementation; for example, many Web servers use the filename
>>   extension of the last path segment to determine the media type of =
the
>>   response.  Likewise, pre-packaged applications often have highly
>>   structured URIs that can only be changed in limited ways (often, =
just
>>   the hostname and port they are deployed upon).
>>=20
>>   Because the owner of the URI is choosing to use the server or the
>>   software, this can be seen as reasonable delegation of authority.
>>   When such conventions are mandated by standards, however, it can =
have
>>   several potentially detrimental effects:
>>=20
>>   o  Collisions - As more conventions for URI structure become
>>      standardised, it becomes more likely that there will be =
collisions
>=20
> If indeed they are being standardized, then the real issue is to have =
coordination of the standards documents, through a registry or the like.

I think you're missing one of the central points of the document here; =
standardising such structure (e.g., through creation of a registry) =
where it isn't appropriate shouldn't be done. The task of this draft is =
to point out where it is and isn't appropriate.

In other words, URIs provide many possible affordances for extension, =
but some -- indeed, many -- are reserved for the use of their authority, =
not a random third party (including IETF WGs).


> I suspect the word "standardize" is being used ambiguously in this =
document, to mean both "formal" standards and "common practice" (de =
fact).

No, it's not.  While it would be nice to encourage other third parties =
(e.g., open source projects) not to "bake" assumptions into the format =
of their URIs, that's out of scope for this document.



>                This can lead to interoperability
>>      problems; for example, if a specification documents that the =
"sig"
>>      URI query parameter indicates that its payload is a =
cryptographic
>>      signature for the URI, it can lead to false positives.
>=20
> The example seems to presume that the attribute associated with 'sig' =
will incorrectly validate as a signature.  What are the odds of that, if =
the sig is using competent modern cryptography?  False negatives seem =
more likely.

The interesting scenario is where a client assumes that "sig" indicates =
a signature and acts upon that (most likely, failing in some way because =
the sig doesn't validate). "false positive" refers to falsely assuming =
that "sig" means what the client thinks it means, but I see how that can =
be confusing; will modify.


>>   While it is not ideal when a server or a deployed application
>>   constrains URI structure (indeed, this is not recommended practice,
>>   but that discussion is out of scope for this document), publishing
>>   standards that mandate URI structure is inappropriate because the
>>   structure of a URI needs to be firmly under the control of its =
owner,
>=20
> See comment above, in Abstract:  the URI spec assigns exactly that =
role to exactly such documents.  But perhaps I've misunderstood that doc =
or this one?

There are some defined ways that URI structure can be specified / =
constrained, and they're covered in the sections below. Read in =
isolation, I can see how this text could be confusion; will update.



>>   and the IETF (as well as other organisations) should not usurp this
>>   ownership; see [webarch] Section 2.2.2.1.
>=20
> Huh?
>=20

Errr...


>>   This document explains best current practices for establishing URI
>>   structures, conventions and formats in standards.  It also offers
>>   strategies for specifications to avoid violating these guidelines =
in
>>   Section 3.
>>=20
>> 1.1.  Who This Document Is For
>>=20
>>   These guidelines are IETF Best Current Practice, and are therefore
>>   binding upon IETF standards-track documents, as well as submissions
>>   to the RFC Editor on the Independent and IRTF streams.  See =
[RFC2026]
>>   and [RFC4844] for more information.
>=20
> Having a document like this make such a broad and absolute assertion =
seems inappropriate.
>=20
>>   Other Open Standards organisations (in the sense of [RFC2026]) are
>>   encouraged to adopt them.  Questions as to their applicability =
ought
>>   to be handled through the liaison relationship, if present.
>>=20
>>   Ad hoc efforts are also encouraged to adopt them, as this RFC
>>   reflects Best Current Practice.
>=20
> Instead of making the above statements of "authority" over other =
documents, it would be more useful for the text to describe the nature =
of its utility and, therefore, /when/ it should apply.  I think the =
draft text that follows this probably suffices for that.

OK, I'm removing those paragraphs; I agree that they're a bit clunky, =
but liked being direct / unambiguous (I know that's unfashionable in the =
IETF).


>>   types of specifications:
>>=20
>>   o  URI Scheme Definitions ("scheme definitions") - specifications
>>      that define and register URI schemes, as per [RFC4395].
>>   o  Protocol Extensions ("extensions") - specifications that offer =
new
>>      capabilities to potentially any identifier, or a large subset;
>>      e.g., a new signature mechanism for 'http' URIs, or metadata for
>>      any URI.
>=20
> How are these formally/notationally distinguished?  For example, must =
they be issued as updates to existing definitions?

Protocol extensions aren't; really, URIs shouldn't be considered a valid =
way to extend the protocol at all (on their own), but people keep =
trying...


>>   o  Applications Using URIs ("applications") - specifications that =
use
>>      URIs to meet specific needs; e.g., a HTTP interface to =
particular
>>      information on a host.
>>=20
>>   Requirements that target the generic class "Specifications" apply =
to
>>   all specifications, including both those enumerated above above and
>>   others.
>=20
> This document makes requirements on all other specifications ever =
written?

Well, yes. We do that all the time, really, don't we?



>>   Note that this specification ought not be interpreted as preventing
>>   the allocation of control of URIs by parties that legitimately own
>>   them, or have delegated that ownership; for example, a =
specification
>>   might legitimately specify the semantics of a URI on the IANA.ORG =
Web
>>   site as part of the establishment of a registry.
>=20
> How is that meaningfully different from the specifications done by the =
IETF, or others, that are /not/ legitimate?

Because IANA is the authority for URIs under iana.org, but not mnot.net =
(for example).



>> 1.2.  Notational Conventions
>>=20
>>   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>>   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in =
this
>>   document are to be interpreted as described in [RFC2119].
>>=20
>>=20
>> 2.  Best Current Practices for Standardising Structured URIs
>>=20
>>   Different components of a URI have differing practices recommended.
>>=20
>> 2.1.  URI Schemes
>>=20
>>   Applications and extensions MAY require use of specific URI
>>   scheme(s); for example, it is perfectly acceptable to require that =
an
>>   application support 'http' and 'https' URIs.  However, applications
>>   SHOULD NOT preclude the use of other URI schemes in the future, to
>>   promote reuse, unless they are clearly specific to the nominated
>>   schemes.
>=20
> What does it mean, in practical, technical terms, to not preclude use =
of other schemes?  (A desire to avoid limiting future specification =
choices is always nice, but knowing what will and won't limit things =
isn't always obvious.)

It means that the specification SHOULD NOT say something like "you can =
never use a different scheme with this."

> For example, how is it reasonable for a file transfer application to =
be required to permit use of a mailto: or sip: scheme?  zThe current =
wording seems to imply such flexibility.

That's not what it's saying. SHOULD NOT preclude !=3D require to permit.


> Also, "reuse"?  What does that mean?

I'll drop that clause.


>>   Applications SHOULD NOT directly specify the syntax of queries, as
>>   this can cause operational difficulties for deployments that do not
>>   support a particular form of a query.
>=20
> The implication of this is that all applications that accept any =
queries must accept all queries.  But that doesn't make sense.  The =
nature of an application constrains what types of queries it can process =
usefully.



>>   Extensions MUST NOT specify the format or semantics of queries.  In
>>   particular, extensions MUST NOT assume that all HTTP(S) resources =
are
>>   capable of accepting queries in the format defined by [HTML4],
>>   Section 17.13.4.
>=20
> The first sentence seems to mean that a "protocol extension" is not =
allowed to extend a protocol to support queries.  But the second =
sentence clearly means otherwise.  I'm obviously misunderstanding what =
this means or how it is to be applied.

Rewritten, thanks.


>>   Given the issues above, the most successful strategy for =
applications
>>   and extensions that wish to use URIs is to use them in the fashion
>>   they were designed; as run-time artifacts that are exchanged as =
part
>>   of the protocol, rather than statically specified syntax.
>>=20
>>   For example, if a specific URI needs to be known to interact with =
an
>=20
> I'm not sure what it means for a URI to be "known to interact" with an =
application.  A URI isn't a protocol; it's a format.  And so I don't =
think of it as "interacting".
>=20
> Do you mean that an application accepts a particular URI or that the =
application uses the URI?

This section has been rewritten.


>>   application, its "shape" can be determined by interacting with the
>=20
> I've searched a number of the documents cited in the references and =
none of them uses the word 'shape'.  What does it mean here?

I've modified the language.


>>   application's more general interface (in Web terms, its "home =
page")
>>   to learn about that URI.
>=20
> How?  This seems a hugely important point but it contains no technical =
detail.

Working on it in other draft(s) that I don't want to depend upon.


> In general, this document would be greatly aided by many more =
examples, including examples that show the wrong way something is often =
done and then the right way it should be done.

Agreed.



>> 4.  Security Considerations
>>=20
>>   This document does not introduce new protocol artifacts with =
security
>>   considerations.
>=20
> Hmmm.  This draft touches on ambiguity and false positives/negatives.  =
I would think that these have some potential security implications.

Will work on some.


Thanks again,

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




From internet-drafts@ietf.org  Wed Jan 29 20:09:31 2014
Return-Path: <internet-drafts@ietf.org>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D04AB1A0497; Wed, 29 Jan 2014 20:09:31 -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 YdyHqm-dZNt4; Wed, 29 Jan 2014 20:09:30 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 718001A04DF; Wed, 29 Jan 2014 20:09:29 -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.90.p2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140130040929.5094.92778.idtracker@ietfa.amsl.com>
Date: Wed, 29 Jan 2014 20:09:29 -0800
Cc: apps-discuss@ietf.org
Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-uri-get-off-my-lawn-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Jan 2014 04:09:32 -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           : URI Design and Ownership
        Author          : Mark Nottingham
	Filename        : draft-ietf-appsawg-uri-get-off-my-lawn-01.txt
	Pages           : 8
	Date            : 2014-01-29

Abstract:
   Sometimes, it is attractive to add features to protocols or
   applications by specifying a particular structure for URIs (or parts
   thereof).  However, publishing standards that mandate URI structure
   is inappropriate because the structure of a URI needs to be firmly
   under the control of its owner, and the IETF (as well as other
   organisations) should not usurp this ownership.

   This document is intended to prevent this practice (sometimes called
   "URI Squatting") in standards, but updating RFC3986 to indicate where
   it is acceptable.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-appsawg-uri-get-off-my-lawn/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-appsawg-uri-get-off-my-lawn-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-uri-get-off-my-lawn-01


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

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


From superuser@gmail.com  Wed Jan 29 22:27:56 2014
Return-Path: <superuser@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AAE91A04E6 for <apps-discuss@ietfa.amsl.com>; Wed, 29 Jan 2014 22:27: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 59df3cJfHHhI for <apps-discuss@ietfa.amsl.com>; Wed, 29 Jan 2014 22:27:55 -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 A681D1A02F3 for <apps-discuss@ietf.org>; Wed, 29 Jan 2014 22:27:54 -0800 (PST)
Received: by mail-wg0-f42.google.com with SMTP id l18so9616287wgh.1 for <apps-discuss@ietf.org>; Wed, 29 Jan 2014 22:27:51 -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=oAXVcvZnRZLFyQqGrRTbgixvwCifgnqPsVVUUnPu6a0=; b=AW8H/D00EAQrne+rjh4kz1oQUfh876u0nJA4SCANi4g9NJdIlzjTxajSps9WXojKlX kefVLm1XLLE84ubSAl2/Zc6GN6f/O1BZlZ8bPXA7KsOMwZl0MsT6MmKQjV0t80nSING6 9Za9pn7NRGIEWJiA+xJUVJQyhBRbF2wVYm6b8nEiOfzVw0qJwcEePO7+IHiIRmC4Fuj4 N7zsea8Ajb1qSAvFXl7Z6fQuRIbD+MnBjMqJgdXl13zyDYci/d8cNrqSBXnI49SycE2W Z8xMCccYpvWqdgm6AqyhsdJ3HLxQFnVImCeZX3yPqUhScb7mD7qZugfQo5+YUZawj3On KUBQ==
MIME-Version: 1.0
X-Received: by 10.180.187.16 with SMTP id fo16mr21927149wic.26.1391063271130;  Wed, 29 Jan 2014 22:27:51 -0800 (PST)
Received: by 10.180.98.41 with HTTP; Wed, 29 Jan 2014 22:27:50 -0800 (PST)
Date: Wed, 29 Jan 2014 22:27:50 -0800
Message-ID: <CAL0qLwYtDzpCGnw_R9YKnpPnTmxpebeBm49J3VTBvtGmM-6bWg@mail.gmail.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
To: IETF Apps Discuss <apps-discuss@ietf.org>
Content-Type: multipart/alternative; boundary=001a11c266c422cbd804f12a28ef
Subject: [apps-discuss] Working Group Last Call: 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 <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Jan 2014 06:27:56 -0000

--001a11c266c422cbd804f12a28ef
Content-Type: text/plain; charset=ISO-8859-1

Colleagues,

This message initiates an extended Working Group Last Call for
draft-ietf-appsawg-uri-get-off-my-lawn, ending Friday, February 21, 2014.
Please submit substantive comments of support or other review feedback to
apps-discuss@ietf.org (preferably on this thread), or privately to the
author 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.

Someone (maybe Mark, since he is the liaison), please forward this
announcement to any appropriate W3C lists.

Thank you,

-MSK, APPSAWG co-chair

--001a11c266c422cbd804f12a28ef
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div>Colleagues,<br><br>This message initiates a=
n extended Working Group <span class=3D"">Last</span> <span class=3D"">Call=
</span> for draft-ietf-appsawg-uri-get-off-my-lawn, ending Friday, February=
 21, 2014.=A0 Please submit substantive comments of support or other review=
 feedback to <a href=3D"mailto:apps-discuss@ietf.org" target=3D"_blank">app=
s-discuss@ietf.org</a> (preferably on this thread), or privately to the aut=
hor or to <a href=3D"mailto:appsawg-chairs@tools.ietf.org" target=3D"_blank=
">appsawg-chairs@tools.ietf.org</a>,
 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.<br>
<br></div><div>Someone (maybe Mark, since he is the liaison), please forwar=
d this announcement to any appropriate W3C lists.<br><br></div>Thank you,<b=
r></div><br></div>-MSK, APPSAWG co-chair</div>

--001a11c266c422cbd804f12a28ef--

From arnt@gulbrandsen.priv.no  Thu Jan 30 00:01:30 2014
Return-Path: <arnt@gulbrandsen.priv.no>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7B1B1A0429 for <apps-discuss@ietfa.amsl.com>; Thu, 30 Jan 2014 00:01:30 -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 pi8t4ck3Wauv for <apps-discuss@ietfa.amsl.com>; Thu, 30 Jan 2014 00:01:28 -0800 (PST)
Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id 95A361A03DC for <apps-discuss@ietf.org>; Thu, 30 Jan 2014 00:01:28 -0800 (PST)
Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 4AC6BFA0076; Thu, 30 Jan 2014 08:01:24 +0000 (UTC)
Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1391068882-17068-17067/11/12; Thu, 30 Jan 2014 08:01:22 +0000
From: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
To: Terry Zink <tzink@exchange.microsoft.com>
Date: Thu, 30 Jan 2014 09:01:43 +0100
User-Agent: Trojita/v0.3.96-176-g713fcbb; Qt/4.8.4; X11; Linux; Ubuntu 13.10
Mime-Version: 1.0
Message-Id: <b1dd88b1-6369-4101-9afb-e57a63aa6c2e@gulbrandsen.priv.no>
In-Reply-To: <>
References: <20140128131859.GB75603@verdi> <20140128201031.28174.qmail@joyce.lan> <85d37e62-d8ac-4c23-8c7e-83a54216f75b@gulbrandsen.priv.no> <fea4f08f-818a-4fba-89eb-a99815e2f997@gulbrandsen.priv.no> <95944a51-a5ff-4741-be24-a6e63c567b5a@gulbrandsen.priv.no> <01P3PTIBT1WO0000AS@mauve.mrochek.com> <c8e958d1-2448-47cd-adbc-7d440dfa0363@gulbrandsen.priv.no> <01P3PUB3GWZ20000AS@mauve.mrochek.com> <bf1d64fa-957b-475c-b1d1-e7cd096799ef@gulbrandsen.priv.no>
Content-Type: text/plain; charset=utf-8; format=flowed
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] draft-martin-smtp-ipv6-to-ipv4-fallback
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Jan 2014 08:01:31 -0000

On Wednesday, January 29, 2014 11:39:18 PM CEST, Terry Zink wrote:
> Wouldn't this require only two codes for IPv6, and not three:
>
> 1) x.x.x Message does not have a PTR
> 2) x.x.x Message does not pass either SPF or DKIM

Neither of them are strictly required, x.7.0 already covers any and all 
policy reasons. They're there to inform senders what their problem is. "You 
need to fix either your DKIM or your SPF, but I'm not going to tell you 
which" is, IMO, an offensively bad error message.

> A message can pass SPF and not DKIM, or DKIM but not SPF, and 
> still be accepted by the email receiver.

I don't understand your point.

Suppose a site uses a Spamhaus list, a content scanner, DKIM and SPF, and 
that it'll reject if any of the four sources say no (simplistic, I know). 
If I understand you correctly, you think the site should report "rejected 
for miscellaneous policy reasons" if either of the first two fail and 
"rejected for DKIM/SPF-related reasons" if the latter two fail. Why the 
half-generic, half-specific response in the latter case? It's neither fish 
nor fowl.

Arnt

From arnt@gulbrandsen.priv.no  Thu Jan 30 00:17:27 2014
Return-Path: <arnt@gulbrandsen.priv.no>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D2421A03DC for <apps-discuss@ietfa.amsl.com>; Thu, 30 Jan 2014 00:17: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 dLTHTnJZvnCo for <apps-discuss@ietfa.amsl.com>; Thu, 30 Jan 2014 00:17:25 -0800 (PST)
Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id F24CB1A02BF for <apps-discuss@ietf.org>; Thu, 30 Jan 2014 00:17:24 -0800 (PST)
Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 11729FA0076; Thu, 30 Jan 2014 08:17:19 +0000 (UTC)
Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1391069838-17068-17067/11/13; Thu, 30 Jan 2014 08:17:18 +0000
From: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
To: apps-discuss@ietf.org
Date: Thu, 30 Jan 2014 09:17:39 +0100
User-Agent: Trojita/v0.3.96-176-g713fcbb; Qt/4.8.4; X11; Linux; Ubuntu 13.10
Mime-Version: 1.0
Message-Id: <c543aad4-02d8-4239-af37-22f0426d0fa8@gulbrandsen.priv.no>
In-Reply-To: <1758787190.59583.1391026009351.JavaMail.zimbra@peachymango.org>
References: <20140128131859.GB75603@verdi> <20140128201031.28174.qmail@joyce.lan> <85d37e62-d8ac-4c23-8c7e-83a54216f75b@gulbrandsen.priv.no> <fea4f08f-818a-4fba-89eb-a99815e2f997@gulbrandsen.priv.no> <95944a51-a5ff-4741-be24-a6e63c567b5a@gulbrandsen.priv.no> <01P3PTIBT1WO0000AS@mauve.mrochek.com> <WM!bf1d1358f6e0c2c07bf67308ff6142eea4e74008a28b1026371c77f1d2f55a91bd8aa36df792d2bb9a913914933b45ce!@asav-2.01.com> <1758787190.59583.1391026009351.JavaMail.zimbra@peachymango.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Subject: Re: [apps-discuss] draft-martin-smtp-ipv6-to-ipv4-fallback
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Jan 2014 08:17:27 -0000

Franck Martin wrote:
> I'm not sure that receivers are willing to permfail on non spam=20
> emails because of technicalities. This draft allows to not=20
> permfails emails, but ensure mandatory domain reputation over=20
> IPv6.

That's already allowed.

Consider a more well-defined failure case: An MTA has two IP addresses =
and=20
the SPF policy for the message it wants to send allows only one of the =
two.

Your draft handles case where the disallowed IP address is an IPv6 =
address=20
and the IPv4 address is allowed. But what you tell clients to do is =
already=20
possible: The MTA can try from its other address just as easily without=20
your draft as with. "Hm, I got an x.7.x failure, I wonder if that's =
related=20
to the IP address or to the message? I'd better try again from the other =
IP=20
address."

For that matter, it can also try from its other address if the server=20
response is "your IP address fails SPF", just as if the response were =
"try=20
from IPv4".

Arnt


From prvs=01008e54e0=johnl@iecc.com  Thu Jan 30 08:50:13 2014
Return-Path: <prvs=01008e54e0=johnl@iecc.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5DFA1A0429 for <apps-discuss@ietfa.amsl.com>; Thu, 30 Jan 2014 08:50:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.537
X-Spam-Level: 
X-Spam-Status: No, score=-2.537 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.535, 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 sWgBeoUEunFA for <apps-discuss@ietfa.amsl.com>; Thu, 30 Jan 2014 08:50:12 -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 EC5B01A03FD for <apps-discuss@ietf.org>; Thu, 30 Jan 2014 08:50:11 -0800 (PST)
Received: (qmail 44729 invoked from network); 30 Jan 2014 16:50:07 -0000
Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 30 Jan 2014 16:50:07 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=52ea82bf.xn--9vv.k1401; i=johnl@user.iecc.com; bh=LqiS7d35NsrcYo9EbT9SO74fBR45zdxfy3ShDSIx+Yk=; b=vMVujU1bPt2AKqXzHjhzomocHm5lninCVVcytYlW73OeoBtKqNgGTBPs+2fARuty6FhhVhQB3u28fYPGaKMIpXSWf/Pw715hX4PRUWLZS6kkfWhOmBUDYxq12QbRocoUjpOQBVvHq8MtYQ/J+XQNpq/1LC91yOPRvynzwlONwadWqlAa/ZEy6X9fzByGCwHkiW1cx6iRuSIQhzQ5fuajpa5h+4LbapNupHhacwj89KxNCXmDdbJ8b+oNk4CUGvLX
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=52ea82bf.xn--9vv.k1401; olt=johnl@user.iecc.com; bh=LqiS7d35NsrcYo9EbT9SO74fBR45zdxfy3ShDSIx+Yk=; b=RwyQWg3PXfivygUoFe5M3LiMq59vPxBgrhAZPBKP3TWEAPi/649nD/n/bL7jIiCrQYSXTFN7cjjWMwb3w23axt9De1yIsqUD6DK8XcN0s4H2kGPECLwC9vVO1l8EQANWhPHnLOp0+wRpkCQygVvEe8GXWC/JtSB5ib1txOjhvY5ushex0Fu42bSCyANAgbbtLqPPrMp0huLu9GaJ0d53M0PmeR8WdtJB3Lp/N7lk946IjyTUEKIBowV6/05sOpwJ
Date: 30 Jan 2014 16:49:45 -0000
Message-ID: <20140130164945.15274.qmail@joyce.lan>
From: "John Levine" <johnl@taugh.com>
To: apps-discuss@ietf.org
In-Reply-To: <b1dd88b1-6369-4101-9afb-e57a63aa6c2e@gulbrandsen.priv.no>
Organization: 
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Subject: Re: [apps-discuss] draft-martin-smtp-ipv6-to-ipv4-fallback
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Jan 2014 16:50:14 -0000

>> 1) x.x.x Message does not have a PTR
>> 2) x.x.x Message does not pass either SPF or DKIM
>
>Neither of them are strictly required, x.7.0 already covers any and all 
>policy reasons. They're there to inform senders what their problem is. "You 
>need to fix either your DKIM or your SPF, but I'm not going to tell you 
>which" is, IMO, an offensively bad error message.

I think you're missing a key point here: v6 MTAs will generally accept
mail if it passes *either* SPF or DKIM.  So this message is telling
you that your message failed both of them, and you can fix either one
to get the mail accepted.

>Suppose a site uses a Spamhaus list, a content scanner, DKIM and SPF, and 
>that it'll reject if any of the four sources say no (simplistic, I know). 

Not simplistic, 100% completely totally unrealistic.

R's,
John

From prvs=01008e54e0=johnl@iecc.com  Thu Jan 30 08:52:03 2014
Return-Path: <prvs=01008e54e0=johnl@iecc.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 783451A0429 for <apps-discuss@ietfa.amsl.com>; Thu, 30 Jan 2014 08:52:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.537
X-Spam-Level: 
X-Spam-Status: No, score=-2.537 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.535, 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 1eTaxbrgcQ3x for <apps-discuss@ietfa.amsl.com>; Thu, 30 Jan 2014 08:52:02 -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 E701B1A042D for <apps-discuss@ietf.org>; Thu, 30 Jan 2014 08:52:00 -0800 (PST)
Received: (qmail 44808 invoked from network); 30 Jan 2014 16:51:56 -0000
Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 30 Jan 2014 16:51:56 -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=52ea832d.xn--hew.k1401; i=johnl@user.iecc.com; bh=FbL/HDpjCW2VpOepvA2GvrDTAkZubW/p4YzOjHWAHxM=; b=Uynioxj6o2lqz1xauOE5jPoAqiJX7a6jhJJfbwpImtGhDs5Ck9UzcuVA3pIM+VT7pMLsLFzf1/d6v/3Jho4ctGL7ZuywsT4s84pIzYvJgsKUIYxnyEq4RNJ1RsDoWUaZvNEIxs+Ze3j+cCciyJDNmQUlS/wDEDF9gnkCL8Qap53//U9WZAgZPlOIdslPNwjI5wuhiwg/FI4sj9zFhG5eSaFVvX/NYOjDsQpj+aPifsSDfdho+vdAzVsBUarc2RLf
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=52ea832d.xn--hew.k1401; olt=johnl@user.iecc.com; bh=FbL/HDpjCW2VpOepvA2GvrDTAkZubW/p4YzOjHWAHxM=; b=el14QU4ypK5peh0xiuqTSoCHpJ69wfIu+OD9+paMrNw0eaEEuAlA0rmr/zRE40lXhjMtVGCZqKdmqFuRU+QBxW76Lbg+9ZqLBAKDKmIGfbEhbaeje9vwMvYRtng2vh4hVMtw/ctcuanWRbFkweSizjkpSDvwiFVrmi0qOdWl6VogRTJBBPlDsWoxmTUsPpv08Nr+pUsQcvgSli87O09onO2DVKtESIDCi/lw/nHWo+nAwd7BWlyeir3yBe2uMHKG
Date: 30 Jan 2014 16:51:34 -0000
Message-ID: <20140130165134.15297.qmail@joyce.lan>
From: "John Levine" <johnl@taugh.com>
To: apps-discuss@ietf.org
In-Reply-To: <c543aad4-02d8-4239-af37-22f0426d0fa8@gulbrandsen.priv.no>
Organization: 
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Subject: Re: [apps-discuss] draft-martin-smtp-ipv6-to-ipv4-fallback
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Jan 2014 16:52:03 -0000

>Consider a more well-defined failure case: An MTA has two IP addresses and 
>the SPF policy for the message it wants to send allows only one of the two.

There's not much we can do if people insist on publishing SPF records
that don't correctly describe their mail sending policies.

R's,
John

From rjsparks@nostrum.com  Thu Jan 30 10:52:05 2014
Return-Path: <rjsparks@nostrum.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 758A51A0451 for <apps-discuss@ietfa.amsl.com>; Thu, 30 Jan 2014 10:52:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level: 
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] 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 m97juaWiWsk6 for <apps-discuss@ietfa.amsl.com>; Thu, 30 Jan 2014 10:52:03 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id D098C1A0433 for <apps-discuss@ietf.org>; Thu, 30 Jan 2014 10:52:03 -0800 (PST)
Received: from unnumerable.local (pool-173-71-10-88.dllstx.fios.verizon.net [173.71.10.88]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id s0UIprqm086704 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK); Thu, 30 Jan 2014 12:51:53 -0600 (CST) (envelope-from rjsparks@nostrum.com)
Message-ID: <52EA9F4B.1090700@nostrum.com>
Date: Thu, 30 Jan 2014 12:51:55 -0600
From: Robert Sparks <rjsparks@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Ned Freed <ned.freed@mrochek.com>
References: <52E19901.4020705@nostrum.com> <01P3I75L6TC60000CD@mauve.mrochek.com>
In-Reply-To: <01P3I75L6TC60000CD@mauve.mrochek.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (shaman.nostrum.com: 173.71.10.88 is authenticated by a trusted mechanism)
Cc: draft-ietf-appsawg-sieve-duplicate@tools.ietf.org, IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Suggestions for draft-ietf-appsawg-sieve-duplicate-02
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Jan 2014 18:52:05 -0000

(Apologies for lag)
Trimming to a couple of points:

On 1/23/14, 6:11 PM, Ned Freed wrote:
> 3) Comparison of the values taken from :header is assumed to be bitwise
>> (though case insensitive). Should that be made explicit? In particular,
>> you're not expecting a duplicate check on :header "Foo" to treat
>> messages with
>> Foo: a=one-thing; b=the-other
>> and
>> Foo: b=the-other; a=one-thing
>> as duplicates.
>
> Sorry, that's incorrect on both counts. First, the document is very 
> clear that
> the comparison is case-sensitive 
Apologies, I got that bit flipped when writing this up. My calling out 
sensitivity
or not was triggered specifically by the text you quote below. However, 
that's
not really the main point I was hoping to discuss.
> and you have to force the case if you want
> sometihng different. From section 3:
>
>   The tracked unique ID value MUST be matched case-sensitively,
>   irrespective of whether it originates from a header or is specified
>   explicitly using the ":uniqueid" argument.  To achieve case-
>   insensitive behavior, the "set" command added by the "variables"
>   [VARIABLES] extension can be used in combination with the ":uniqueid"
>   argument to normalize the tracked unique ID value to upper or lower
>   case.
>
> Second, it's not an octet-by-octet comprison with :header - whitespace 
> trimming
> is part of the operation. Again from section 3:
>
>   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 MUST first be trimmed from the value
>   before performing the actual duplicate verification (see Section 2.2
>   of RFC 5228 [SIEVE]).  Note that this also applies to the Message-ID
>   header field used by the basic "duplicate" test without a ":header"
>   or ":uniqueid" argument.  When the ":uniqueid" argument is used, such
>   normalization concerns are the responsibility of the user.
And I missed this. Does it apply also to what comes out of variables, or 
does
variable handling already ensure that you wouldn't have leading or trailing
whitespace to worry about?

But what I was really trying to is confirm (and I don't think you 
verified in your response)
that you aren't asking this code to learn about the details of any 
particular header
field and treat things that are semantically the same (such as what 
might result
from reordering name=value pairs as in the Foo example I gave above) as 
equal
for this comparison.

>> 5) (minor, editorial) It might make implementation less error prone to
>> not use "message ID" at all, but say something like "Messages are
>> identified by a 'seen' value computed from the message, which defaults
>> to the contents of the Message-ID header. That would lead to sentences
>> like "The 'duplicate' test MUST only check for duplicates amongst 'seen'
>> values encountered in previous executions of the Sieve script; it MUST
>> NOT consider 'seen' values encountered earlier in the current Sieve
>> script execution as potential duplicates.
>
> This doesn't sound much better to me. Or any worse, for that matter.
I had asked a few non-IETF sysadmin/implementers to read this, and they
consistently hung on this point, saying they had to stop halfway through
and start rereading the document to make sure they kept when message ID
mean Message-ID and when it might not straight as they were reading.
The other suggestion to point out early that Message ID is Message-ID by
default might be enough, but this suggestion seemed to resonate with those
folks. Maybe you can see something else that would do just as well. (And
I'm ok if you leave it as is).

RjS

From franck@peachymango.org  Thu Jan 30 11:30:26 2014
Return-Path: <franck@peachymango.org>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9327B1A046B for <apps-discuss@ietfa.amsl.com>; Thu, 30 Jan 2014 11:30:26 -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 z90zNLoi011x for <apps-discuss@ietfa.amsl.com>; Thu, 30 Jan 2014 11:30:24 -0800 (PST)
Received: from smtp.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id AAF3E1A0435 for <apps-discuss@ietf.org>; Thu, 30 Jan 2014 11:30:14 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 5F9B4295034; Thu, 30 Jan 2014 13:30:11 -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 eB-3RVKiIMd7; Thu, 30 Jan 2014 13:30:11 -0600 (CST)
Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 40392295069; Thu, 30 Jan 2014 13:30:11 -0600 (CST)
Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 311AB295035; Thu, 30 Jan 2014 13:30:11 -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 QjLLdjgG-NIr; Thu, 30 Jan 2014 13:30:11 -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 13424295034; Thu, 30 Jan 2014 13:30:11 -0600 (CST)
Date: Thu, 30 Jan 2014 13:30:10 -0600 (CST)
From: Franck Martin <franck@peachymango.org>
To: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
Message-ID: <1138458378.17726.1391110210079.JavaMail.zimbra@peachymango.org>
In-Reply-To: <WM!821256ba3b54ab238f7b3a6d9c2979b28f2124b62915b111395fdf5b27e484be7ec61a6ece483720212ec081109f4dd7!@asav-2.01.com>
References: <20140128131859.GB75603@verdi> <fea4f08f-818a-4fba-89eb-a99815e2f997@gulbrandsen.priv.no> <95944a51-a5ff-4741-be24-a6e63c567b5a@gulbrandsen.priv.no> <01P3PTIBT1WO0000AS@mauve.mrochek.com> <WM!bf1d1358f6e0c2c07bf67308ff6142eea4e74008a28b1026371c77f1d2f55a91bd8aa36df792d2bb9a913914933b45ce!@asav-2.01.com> <1758787190.59583.1391026009351.JavaMail.zimbra@peachymango.org> <c543aad4-02d8-4239-af37-22f0426d0fa8@gulbrandsen.priv.no> <WM!821256ba3b54ab238f7b3a6d9c2979b28f2124b62915b111395fdf5b27e484be7ec61a6ece483720212ec081109f4dd7!@asav-2.01.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 - FF26 (Mac)/8.0.5_GA_5839)
Thread-Topic: draft-martin-smtp-ipv6-to-ipv4-fallback
Thread-Index: hnz5KXhxuLAg0oul0cs7BPjuR5ZxVA==
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] draft-martin-smtp-ipv6-to-ipv4-fallback
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Jan 2014 19:30:26 -0000

----- Original Message -----
> From: "Arnt Gulbrandsen" <arnt@gulbrandsen.priv.no>
> To: apps-discuss@ietf.org
> Sent: Thursday, January 30, 2014 12:17:39 AM
> Subject: Re: [apps-discuss] draft-martin-smtp-ipv6-to-ipv4-fallback
> 
> Franck Martin wrote:
> > I'm not sure that receivers are willing to permfail on non spam
> > emails because of technicalities. This draft allows to not
> > permfails emails, but ensure mandatory domain reputation over
> > IPv6.
> 
> That's already allowed.
> 
> Consider a more well-defined failure case: An MTA has two IP addresses and
> the SPF policy for the message it wants to send allows only one of the two.
> 
> Your draft handles case where the disallowed IP address is an IPv6 address
> and the IPv4 address is allowed. But what you tell clients to do is already
> possible: The MTA can try from its other address just as easily without
> your draft as with. "Hm, I got an x.7.x failure, I wonder if that's related
> to the IP address or to the message? I'd better try again from the other IP
> address."
> 
> For that matter, it can also try from its other address if the server
> response is "your IP address fails SPF", just as if the response were "try
> from IPv4".
>
Allowed yes, implemented no

MTA's do not read x.7.x extended smtp codes, they read 4xx and 5xx and act on them.

This draft just throws a 421 and disconnect, telling the sender, this receiver is having existential issues, don't try it for a little while, try another one.

http://tools.ietf.org/html/rfc5321#section-4.2.3


From superuser@gmail.com  Thu Jan 30 12:57:33 2014
Return-Path: <superuser@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E1191A04ED for <apps-discuss@ietfa.amsl.com>; Thu, 30 Jan 2014 12:57:33 -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 HQtAVl-fIkZX for <apps-discuss@ietfa.amsl.com>; Thu, 30 Jan 2014 12:57:29 -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 C4A151A04D0 for <apps-discuss@ietf.org>; Thu, 30 Jan 2014 12:57:28 -0800 (PST)
Received: by mail-wg0-f50.google.com with SMTP id l18so7198558wgh.17 for <apps-discuss@ietf.org>; Thu, 30 Jan 2014 12:57:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=k8QSUGTvIiFZPoAbr9sz8UsDGmq4Rb6qfUSSyJ6vAF4=; b=a6J69ejVxq2nbjXJS7o2MrfuAGIOc3sJBaPBFVzMqV4Y8bF8xeF1OzufxF1Vff/J/q LCDBForFOFk1sQ383cVMeCgcP7gY4G4k2Z0bVcOhTi06W4fS50HSjVb+pZ/984lNtnuV +gj6BE5cKjhkga5CFYZQsnvEV8eH547iwL9xITHM50lyGPZbm67mGVvS3+DTaYbgdtQ1 cQnZjmvHYTcxNnAkKw7Rslr1uh9cIVZpgtA+0/c18h+Gvso7+h1OkpEEeHBgFEFDFxwA Vnli8PrZJskoQI+7+6M0DM2V8+tYIGtyu3T0kCWOXEyknKjSbAxNa5j9Ix4Q364zDDzV U8WQ==
MIME-Version: 1.0
X-Received: by 10.180.221.38 with SMTP id qb6mr11052781wic.26.1391115445031; Thu, 30 Jan 2014 12:57:25 -0800 (PST)
Received: by 10.180.98.41 with HTTP; Thu, 30 Jan 2014 12:57:24 -0800 (PST)
In-Reply-To: <1138458378.17726.1391110210079.JavaMail.zimbra@peachymango.org>
References: <20140128131859.GB75603@verdi> <fea4f08f-818a-4fba-89eb-a99815e2f997@gulbrandsen.priv.no> <95944a51-a5ff-4741-be24-a6e63c567b5a@gulbrandsen.priv.no> <01P3PTIBT1WO0000AS@mauve.mrochek.com> <WM!bf1d1358f6e0c2c07bf67308ff6142eea4e74008a28b1026371c77f1d2f55a91bd8aa36df792d2bb9a913914933b45ce!@asav-2.01.com> <1758787190.59583.1391026009351.JavaMail.zimbra@peachymango.org> <c543aad4-02d8-4239-af37-22f0426d0fa8@gulbrandsen.priv.no> <WM!821256ba3b54ab238f7b3a6d9c2979b28f2124b62915b111395fdf5b27e484be7ec61a6ece483720212ec081109f4dd7!@asav-2.01.com> <1138458378.17726.1391110210079.JavaMail.zimbra@peachymango.org>
Date: Thu, 30 Jan 2014 12:57:24 -0800
Message-ID: <CAL0qLwaHWWcJ0UsSLzCb4WvT9NoiB2WcUgcy8sk1UJNc37Zo7A@mail.gmail.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
To: Franck Martin <franck@peachymango.org>
Content-Type: multipart/alternative; boundary=001a1134d2daf156cb04f1364df5
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] draft-martin-smtp-ipv6-to-ipv4-fallback
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Jan 2014 20:57:33 -0000

--001a1134d2daf156cb04f1364df5
Content-Type: text/plain; charset=ISO-8859-1

As I read it, Sections 4.5.4.1 and 5.1 of RFC5321 don't specify a
particular retry behavior that clients have to use in the face of a 421 or
an interrupted connection.  Specifically, "try another one" is not
necessarily how all deployed clients will respond.  I think you're only
guaranteed that if the lowest precedence MX is completely unreachable, the
client will try at least one other.

-MSK


On Thu, Jan 30, 2014 at 11:30 AM, Franck Martin <franck@peachymango.org>wrote:

>
>
>
>
> ----- Original Message -----
> > From: "Arnt Gulbrandsen" <arnt@gulbrandsen.priv.no>
> > To: apps-discuss@ietf.org
> > Sent: Thursday, January 30, 2014 12:17:39 AM
> > Subject: Re: [apps-discuss] draft-martin-smtp-ipv6-to-ipv4-fallback
> >
> > Franck Martin wrote:
> > > I'm not sure that receivers are willing to permfail on non spam
> > > emails because of technicalities. This draft allows to not
> > > permfails emails, but ensure mandatory domain reputation over
> > > IPv6.
> >
> > That's already allowed.
> >
> > Consider a more well-defined failure case: An MTA has two IP addresses
> and
> > the SPF policy for the message it wants to send allows only one of the
> two.
> >
> > Your draft handles case where the disallowed IP address is an IPv6
> address
> > and the IPv4 address is allowed. But what you tell clients to do is
> already
> > possible: The MTA can try from its other address just as easily without
> > your draft as with. "Hm, I got an x.7.x failure, I wonder if that's
> related
> > to the IP address or to the message? I'd better try again from the other
> IP
> > address."
> >
> > For that matter, it can also try from its other address if the server
> > response is "your IP address fails SPF", just as if the response were
> "try
> > from IPv4".
> >
> Allowed yes, implemented no
>
> MTA's do not read x.7.x extended smtp codes, they read 4xx and 5xx and act
> on them.
>
> This draft just throws a 421 and disconnect, telling the sender, this
> receiver is having existential issues, don't try it for a little while, try
> another one.
>
> http://tools.ietf.org/html/rfc5321#section-4.2.3
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

--001a1134d2daf156cb04f1364df5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>As I read it, Sections 4.5.4.1 and 5.1 of RFC5321 don=
&#39;t specify a particular retry behavior that clients have to use in the =
face of a 421 or an interrupted connection.=A0 Specifically, &quot;try anot=
her one&quot; is not necessarily how all deployed clients will respond.=A0 =
I think you&#39;re only guaranteed that if the lowest precedence MX is comp=
letely unreachable, the client will try at least one other.<br>
<br></div>-MSK<br></div><div class=3D"gmail_extra"><br><br><div class=3D"gm=
ail_quote">On Thu, Jan 30, 2014 at 11:30 AM, Franck Martin <span dir=3D"ltr=
">&lt;<a href=3D"mailto:franck@peachymango.org" target=3D"_blank">franck@pe=
achymango.org</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im"><br>
<br>
<br>
<br>
----- Original Message -----<br>
&gt; From: &quot;Arnt Gulbrandsen&quot; &lt;<a href=3D"mailto:arnt@gulbrand=
sen.priv.no">arnt@gulbrandsen.priv.no</a>&gt;<br>
&gt; To: <a href=3D"mailto:apps-discuss@ietf.org">apps-discuss@ietf.org</a>=
<br>
&gt; Sent: Thursday, January 30, 2014 12:17:39 AM<br>
&gt; Subject: Re: [apps-discuss] draft-martin-smtp-ipv6-to-ipv4-fallback<br=
>
&gt;<br>
</div><div class=3D"im">&gt; Franck Martin wrote:<br>
&gt; &gt; I&#39;m not sure that receivers are willing to permfail on non sp=
am<br>
&gt; &gt; emails because of technicalities. This draft allows to not<br>
&gt; &gt; permfails emails, but ensure mandatory domain reputation over<br>
&gt; &gt; IPv6.<br>
&gt;<br>
&gt; That&#39;s already allowed.<br>
&gt;<br>
&gt; Consider a more well-defined failure case: An MTA has two IP addresses=
 and<br>
&gt; the SPF policy for the message it wants to send allows only one of the=
 two.<br>
&gt;<br>
&gt; Your draft handles case where the disallowed IP address is an IPv6 add=
ress<br>
&gt; and the IPv4 address is allowed. But what you tell clients to do is al=
ready<br>
&gt; possible: The MTA can try from its other address just as easily withou=
t<br>
&gt; your draft as with. &quot;Hm, I got an x.7.x failure, I wonder if that=
&#39;s related<br>
&gt; to the IP address or to the message? I&#39;d better try again from the=
 other IP<br>
&gt; address.&quot;<br>
&gt;<br>
&gt; For that matter, it can also try from its other address if the server<=
br>
&gt; response is &quot;your IP address fails SPF&quot;, just as if the resp=
onse were &quot;try<br>
&gt; from IPv4&quot;.<br>
&gt;<br>
</div>Allowed yes, implemented no<br>
<br>
MTA&#39;s do not read x.7.x extended smtp codes, they read 4xx and 5xx and =
act on them.<br>
<br>
This draft just throws a 421 and disconnect, telling the sender, this recei=
ver is having existential issues, don&#39;t try it for a little while, try =
another one.<br>
<br>
<a href=3D"http://tools.ietf.org/html/rfc5321#section-4.2.3" target=3D"_bla=
nk">http://tools.ietf.org/html/rfc5321#section-4.2.3</a><br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
_______________________________________________<br>
apps-discuss mailing list<br>
<a href=3D"mailto:apps-discuss@ietf.org">apps-discuss@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/apps-discuss" target=3D"_b=
lank">https://www.ietf.org/mailman/listinfo/apps-discuss</a><br>
</div></div></blockquote></div><br></div>

--001a1134d2daf156cb04f1364df5--

From arnt@gulbrandsen.priv.no  Thu Jan 30 13:42:43 2014
Return-Path: <arnt@gulbrandsen.priv.no>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D281B1A04DB for <apps-discuss@ietfa.amsl.com>; Thu, 30 Jan 2014 13:42:43 -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 EVMbdKTXmvQV for <apps-discuss@ietfa.amsl.com>; Thu, 30 Jan 2014 13:42:41 -0800 (PST)
Received: from strange.aox.org (strange.aox.org [IPv6:2001:4d88:100c::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB891A04CC for <apps-discuss@ietf.org>; Thu, 30 Jan 2014 13:42:41 -0800 (PST)
Received: from fri.gulbrandsen.priv.no (localhost [127.0.0.1]) by strange.aox.org (Postfix) with ESMTP id 5F7BCFA003D; Thu, 30 Jan 2014 21:42:37 +0000 (UTC)
Received: from arnt@gulbrandsen.priv.no by fri.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1391118156-15953-15952/11/9; Thu, 30 Jan 2014 21:42:36 +0000
From: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
To: "Murray S. Kucherawy" <superuser@gmail.com>
Date: Thu, 30 Jan 2014 22:42:57 +0100
User-Agent: Trojita/v0.3.96-176-g713fcbb; Qt/4.8.4; X11; Linux; Ubuntu 13.10
Mime-Version: 1.0
Message-Id: <8e8dd97d-0fa6-44a1-b8a4-6fa3c6ca9413@gulbrandsen.priv.no>
In-Reply-To: <>
References: <20140128131859.GB75603@verdi> <fea4f08f-818a-4fba-89eb-a99815e2f997@gulbrandsen.priv.no> <95944a51-a5ff-4741-be24-a6e63c567b5a@gulbrandsen.priv.no> <01P3PTIBT1WO0000AS@mauve.mrochek.com> <WM!bf1d1358f6e0c2c07bf67308ff6142eea4e74008a28b1026371c77f1d2f55a91bd8aa36df792d2bb9a913914933b45ce!@asav-2.01.com> <1758787190.59583.1391026009351.JavaMail.zimbra@peachymango.org> <c543aad4-02d8-4239-af37-22f0426d0fa8@gulbrandsen.priv.no> <WM!821256ba3b54ab238f7b3a6d9c2979b28f2124b62915b111395fdf5b27e484be7ec61a6ece483720212ec081109f4dd7!@asav-2.01.com> <1138458378.17726.1391110210079.JavaMail.zimbra@peachymango.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] draft-martin-smtp-ipv6-to-ipv4-fallback
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Jan 2014 21:42:44 -0000

Murray S. Kucherawy wrote:
> As I read it, Sections 4.5.4.1 and 5.1 of RFC5321 don't specify 
> a particular retry behavior that clients have to use in the face 
> of a 421 or an interrupted connection.  Specifically, "try 
> another one" is not necessarily how all deployed clients will 
> respond.  I think you're only guaranteed that if the lowest 
> precedence MX is completely unreachable, the client will try at 
> least one other.

I wasn't trying to say that unextended clients do the right thing. Rather, 
I tried to say that an MTA can get the same functionality as in 
draft-martin-smtp-ipv6-to-ipv4-fallback even without server extension. It 
just has to fall back to its other address(es) if the server sends x.7.x 
instead of falling back based on the draft-...-fallback extension.

Of course that requires implementation work, and of course it would lead to 
some futile retries.

Arnt


From superuser@gmail.com  Thu Jan 30 13:46:27 2014
Return-Path: <superuser@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED2D01A0489 for <apps-discuss@ietfa.amsl.com>; Thu, 30 Jan 2014 13:46:26 -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 b_7bkhUWKIuj for <apps-discuss@ietfa.amsl.com>; Thu, 30 Jan 2014 13:46:24 -0800 (PST)
Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id 87D6A1A0486 for <apps-discuss@ietf.org>; Thu, 30 Jan 2014 13:46:24 -0800 (PST)
Received: by mail-wg0-f48.google.com with SMTP id x13so7307587wgg.15 for <apps-discuss@ietf.org>; Thu, 30 Jan 2014 13:46:20 -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=1X+ed806udE/cKb2/d7WW85y5JdI8VmFKs6KnzuPtL0=; b=MhQXrhGvNGEvsbfwXKbN13mflR5pOl72LfMUed3wMQr9iEhGRH+YKpchCvJQDb8zcp R4Oft8NZsTRsl8tg0OrddXcVPl2Pwod9BR0MR7/p5gziCgplK0hRpI/Fi5ZX7KgibXEt CAwCIsFKa1bXl6wr+3FKMQ8aFuOGEmSkQbmnMw5vHsFUkggQYkr8CjjFDiqXOCl0LuLJ HnVdY7s7n53C/xcwOnR0SPZGkM5gZDSH5qw7VmG1ljImTK7c/nZIKs9ZV4QVFAWXAzLG 7iNeA13GHbOxmJ2OUorrZaOkgzYH3ggT8VjrDadOxew7kXw7EN1pVyOCjO/hxIeuddQH 6MwQ==
MIME-Version: 1.0
X-Received: by 10.180.39.43 with SMTP id m11mr24642715wik.8.1391118380732; Thu, 30 Jan 2014 13:46:20 -0800 (PST)
Received: by 10.180.98.41 with HTTP; Thu, 30 Jan 2014 13:46:20 -0800 (PST)
Date: Thu, 30 Jan 2014 13:46:20 -0800
Message-ID: <CAL0qLwZFF_oDPsUSu7dV6M=JXG7=OAmb50MVwYS_r=ZRtsRtrg@mail.gmail.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
To: IETF Apps Discuss <apps-discuss@ietf.org>
Content-Type: multipart/alternative; boundary=001a1134cdd8ec983204f136fc42
Subject: [apps-discuss] Call for Adoption: draft-delany-nullmx
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Jan 2014 21:46:27 -0000

--001a1134cdd8ec983204f136fc42
Content-Type: text/plain; charset=ISO-8859-1

Colleagues,

This is a formal call for adoption of draft-delany-nullmx into APPSAWG.
The call will close on February 14, 2014.  The chairs note that there has
already been some expression of support for adoption in past threads; more
feedback is requested.

As you've heard us say in Vancouver and earlier, we are instituting a new
experimental idea with respect to documents in APPSAWG, namely
"mini-charters" in order to frame discussions, set goals, and secure a
minimal set of reviewers and supporters.  The mini-charter for this draft
appears at the end of this message.

Please submit comments, concerns, support, etc. for this document's
handling by APPSAWG in reply to this thread by February 14, 2014.  Note
that this is not an indication of support for the document as-is, only for
APPSAWG adopting it for further development.

The mini-charter lists four people (in addition to the authors) willing to
provide timely reviews and support for the document through publication.
I'd like to be able to list a couple more.  If you'd like to be added to
that list, please say so in your reply.

-MSK

The mini-charter:

SMTP mail has never provided a way for a domain to state that it does
not receive mail.  If a domain publishes MX records, it definitely
does receive mail.  If it publishes no MX, but does publish A or AAAA
records there is no way to tell whether those records are indended to
identify an "implicit MX".  If a sending host attempts to send to an A
or AAAA, and is unable to connect, there is no way to tell whether the
failure is temporary or permanent, short of repeated retries.

As a result, if a user attempts to send mail to a mistyped domain, it
can take up to a week (the recommended retry limit) to get back a
failure report.  In principle, a domain could set up a stub mail
server that accepted connections and immediately rejected delivery
attempts, but that is more work than most domains want to do.  Hence
our goal is to provide a cheap way to quickly tell senders not to
bother.  (Note that an SPF record with "-all" says that a domain sends
no mail, which is not necessarily the same as receiving no mail.)

We propose that an MX record pointing to the root of the DNS, known as
"MX ." means the domain accepts no mail.  This approach has been used
informally for almost a decade, with few if any problems, but has
never been described in an IETF document.  We propose only to assign
the no-mail semantics to "MX ." and not make any other changes to
SMTP.

There is one draft to adopt: draft-delany-nullmx, to be submitted to the
IESG by the end of May, 2014.

The following have committed to work on the document through to publication:

Murray Kucherawy <superuser@gmail.com>
Dave Crocker <dcrocker@bbiw.net>
Terry Zink <tzink@exchange.microsoft.com>
Arnt Gulbrandsend <arnt@gulbrandsen.priv.no>

--001a1134cdd8ec983204f136fc42
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div><div><div>Colleagues,<br><br></div>This is =
a formal call for adoption of draft-delany-nullmx into APPSAWG.=A0 The call=
 will close on February 14, 2014.=A0 The chairs note that there has already=
 been some expression of support for adoption in past threads; more feedbac=
k is requested.<br>
<br></div>As you&#39;ve heard us say in Vancouver and earlier, we are insti=
tuting a new experimental idea with respect to documents in APPSAWG, namely=
 &quot;mini-charters&quot; in order to frame discussions, set goals, and se=
cure a minimal set of reviewers and supporters.=A0 The mini-charter for thi=
s draft appears at the end of this message.<br>
<br></div></div>Please submit comments, concerns, support, etc. for this do=
cument&#39;s handling by APPSAWG in reply to this thread by February 14, 20=
14.=A0 Note that this is not an indication of support for the document as-i=
s, only for APPSAWG adopting it for further development.<br>
<br></div>The mini-charter lists four people (in addition to the authors) w=
illing to provide timely reviews and support for the document through publi=
cation.=A0 I&#39;d like to be able to list a couple more.=A0 If you&#39;d l=
ike to be added to that list, please say so in your reply.<br>
<div><div><br></div><div>-MSK<br><br></div><div>The mini-charter:<br><br>SM=
TP mail has never provided a way for a domain to state that it does<br>
not receive mail. =A0If a domain publishes MX records, it definitely<br>
does receive mail. =A0If it publishes no MX, but does publish A or AAAA<br>
records there is no way to tell whether those records are indended to<br>
identify an &quot;implicit MX&quot;. =A0If a sending host attempts to send =
to an A<br>
or AAAA, and is unable to connect, there is no way to tell whether the<br>
failure is temporary or permanent, short of repeated retries.<br>
<br>
As a result, if a user attempts to send mail to a mistyped domain, it<br>
can take up to a week (the recommended retry limit) to get back a<br>
failure report. =A0In principle, a domain could set up a stub mail<br>
server that accepted connections and immediately rejected delivery<br>
attempts, but that is more work than most domains want to do. =A0Hence<br>
our goal is to provide a cheap way to quickly tell senders not to<br>
bother. =A0(Note that an SPF record with &quot;-all&quot; says that a domai=
n sends<br>
no mail, which is not necessarily the same as receiving no mail.)<br>
<br>
We propose that an MX record pointing to the root of the DNS, known as<br>
&quot;MX .&quot; means the domain accepts no mail. =A0This approach has bee=
n used<br>
informally for almost a decade, with few if any problems, but has<br>
never been described in an IETF document. =A0We propose only to assign<br>
the no-mail semantics to &quot;MX .&quot; and not make any other changes to=
<br>
SMTP.<br>
<br>
There is one draft to adopt: draft-delany-nullmx, to be submitted to the IE=
SG by the end of May, 2014.<br>
<br>
</div><div>The following have committed to work on the document through to =
publication:<br><br></div><div>Murray Kucherawy &lt;<a href=3D"mailto:super=
user@gmail.com">superuser@gmail.com</a>&gt;<br></div><div>Dave Crocker &lt;=
<a href=3D"mailto:dcrocker@bbiw.net">dcrocker@bbiw.net</a>&gt;<br>
</div><div>Terry Zink &lt;<a href=3D"mailto:tzink@exchange.microsoft.com">t=
zink@exchange.microsoft.com</a>&gt;<br>Arnt Gulbrandsend &lt;<a href=3D"mai=
lto:arnt@gulbrandsen.priv.no">arnt@gulbrandsen.priv.no</a>&gt;<br><br></div=
>
</div></div>

--001a1134cdd8ec983204f136fc42--

From georgehanes@hushmail.com  Thu Jan 30 14:04:04 2014
Return-Path: <georgehanes@hushmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 842771A04DD for <apps-discuss@ietfa.amsl.com>; Thu, 30 Jan 2014 14:04:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.323
X-Spam-Level: 
X-Spam-Status: No, score=-2.323 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.535, SPF_HELO_NEUTRAL=0.112, 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 2fxWAgkWhUa0 for <apps-discuss@ietfa.amsl.com>; Thu, 30 Jan 2014 14:04:03 -0800 (PST)
Received: from smtp5.hushmail.com (smtp5a.hushmail.com [65.39.178.235]) by ietfa.amsl.com (Postfix) with ESMTP id 214C11A04DB for <apps-discuss@ietf.org>; Thu, 30 Jan 2014 14:04:03 -0800 (PST)
Received: from smtp5.hushmail.com (smtp5a.hushmail.com [65.39.178.235]) by smtp5.hushmail.com (Postfix) with SMTP id C5D476025C for <apps-discuss@ietf.org>; Thu, 30 Jan 2014 22:03:59 +0000 (UTC)
Received: from smtp.hushmail.com (w8.hushmail.com [65.39.178.52]) by smtp5.hushmail.com (Postfix) with ESMTP for <apps-discuss@ietf.org>; Thu, 30 Jan 2014 22:03:59 +0000 (UTC)
Received: by smtp.hushmail.com (Postfix, from userid 99) id AFF046018A; Thu, 30 Jan 2014 22:03:59 +0000 (UTC)
MIME-Version: 1.0
Date: Thu, 30 Jan 2014 17:03:59 -0500
To: apps-discuss@ietf.org
From: georgehanes@hushmail.com
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20140130220359.AFF046018A@smtp.hushmail.com>
Subject: [apps-discuss] Be cautious of this computer science conference
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Jan 2014 22:12:36 -0000

Be cautious of this computer science conference

If you have any thought of attending the world’s biggest 
f-a-k-e conference in computer science 
http://www.world-academy-of-science.org  you should visit 
any websites below

https://sites.google.com/site/worlddump1 
or
https://sites.google.com/site/dumpconf 
https://sites.google.com/site/moneycomp1
https://sites.google.com/site/worlddump4

The organizer of this conference is H-amid A-rabnia  
http://www.cs.uga.edu/~hra  a professor from University 
of Georgia, Athens, US.  He already earned millions of 
dollars from the registration fee. He recently started 
a new conference CSCI due to his hunger for money 
http://www.americancse.org 

He did not reveal the reviews and reviewers' information 
for all the papers he received, despite repeated requests 
and challenges. The reason for his failure is there are 
no reviews and reviewers and he just cheated the research 
community for more than a decade by announcing that each 
draft paper is reviewed by two experts. We challenge him 
to publish these details at the conference website. 
Where are your experts? Where are your reviews? 

Soon he comes up with a story announcing that he lost all 
the information having reviews and reviewers because of 
computer crash or theft.

DBLP stopped indexing these conferences since 2011 and 
displayed an explicit message; 
"The DBLP Advisory Board decided to discontinue indexing 
of this conference series". Visit 
http://www.informatik.uni-trier.de/~ley/db/conf/biocomp/index.html 
as a sample.

He was forced to remove his name, the university of Georgia 
name, and university of Georgia email address from the 
conference’s contact page because the University has 
banned him from doing that. Do not spoil your resume by 
publishing in this conference.

Apologies for posting to multiple mailing lists. Spreading 
the news is the only way to stop this conference from 
harming innocent researchers.

Respectfully,

Many researchers cheated by these conferences


From jfesler@gigo.com  Thu Jan 30 15:18:35 2014
Return-Path: <jfesler@gigo.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84D461A04F1 for <apps-discuss@ietfa.amsl.com>; Thu, 30 Jan 2014 15:18:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.199
X-Spam-Level: 
X-Spam-Status: No, score=-1.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id um5_4h7-vLOE for <apps-discuss@ietfa.amsl.com>; Thu, 30 Jan 2014 15:18:34 -0800 (PST)
Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com [209.85.214.181]) by ietfa.amsl.com (Postfix) with ESMTP id 3B7441A04EE for <apps-discuss@ietf.org>; Thu, 30 Jan 2014 15:18:34 -0800 (PST)
Received: by mail-ob0-f181.google.com with SMTP id va2so4181210obc.26 for <apps-discuss@ietf.org>; Thu, 30 Jan 2014 15:18:30 -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=f3AGbIEFdJyQKUBMqMX7kuBxGAbFS+serT0z6v1/CyI=; b=hL5cGvF/ttyNr6a9L0SlEQ15w2ehnTOqVvM003zg4H1sWzRDSfpSsDbZO5xR+kztOk gO5rFYP0f0nLEhf+WBlYeCC9mJPyPoVvxe8STFnnukwpXvSVtG85LxawvkzKAmfcWzrS SYLD/DOvQDN12v4DXMyRA0aKpeHDJtQPHA73fG/LLc+Mxo19QWWC1HcQuZze6EWBewbl z5GxBpy/IK2Qo3xJi0BRb/GQLsmTDgR68YL/g93s58NYoV6hBzuEsL2mGNDiivDv62zU J112hmQRl++DdjuX7koPq3zm7jvb0ifIqlU621fPVnUIXVUehJW4D1GKZaIVl1rQHY5J NwKg==
X-Gm-Message-State: ALoCoQlyW90+VvAA1aYZwfR34C/97ufir/p4V1gzreBCmn+NKk4S6OZYvmj64/hDcQyOT/tc0qjE
MIME-Version: 1.0
X-Received: by 10.182.126.225 with SMTP id nb1mr4015051obb.48.1391123910628; Thu, 30 Jan 2014 15:18:30 -0800 (PST)
Received: by 10.76.141.115 with HTTP; Thu, 30 Jan 2014 15:18:30 -0800 (PST)
Date: Thu, 30 Jan 2014 15:18:30 -0800
Message-ID: <CADCiYHB3je9WVcs1GO=Lykn5RipKuFNARp0Rm9hXToJh2jcOwA@mail.gmail.com>
From: Jason Fesler <jfesler@gigo.com>
To: apps-discuss@ietf.org
Content-Type: text/plain; charset=UTF-8
Subject: [apps-discuss] Comments on draft-martin-smtp-target-host-selection-ipv4-ipv6-01
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Jan 2014 23:18:35 -0000

As I re-read http://tools.ietf.org/html/rfc5321#section-5 ..

   When the lookup succeeds, the mapping can result in a list of
   alternative delivery addresses rather than a single address, because
   of multiple MX records, multihoming, or both.  To provide reliable
   mail transmission, the SMTP client MUST be able to try (and retry)
   each of the relevant addresses in this list in order, until a
   delivery attempt succeeds.  However, there MAY also be a configurable
   limit on the number of alternate addresses that can be tried.  In any
   case, the SMTP client SHOULD try at least two addresses.

I wonder if Mr. Martin's draft should be simplified; to simply amend
5321 by modifying the last line:

   In any case, the SMTP client SHOULD try at least two addresses of
each address family found.


That would seem to address most issues except perhaps the caching of
unreachable destinations.

-- 
 Jason Fesler, email/jabber <jfesler@gigo.com> resume: http://jfesler.com
 "Give a man fire, and he'll be warm for a day;
 set a man on fire, and he'll be warm for the rest of his life."

From tim@eudaemon.net  Thu Jan 30 16:38:50 2014
Return-Path: <tim@eudaemon.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40BB61A04F1 for <apps-discuss@ietfa.amsl.com>; Thu, 30 Jan 2014 16:38:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.436
X-Spam-Level: 
X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, 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 31QbUXAdsIgX for <apps-discuss@ietfa.amsl.com>; Thu, 30 Jan 2014 16:38:48 -0800 (PST)
Received: from pie.eudaemon.net (pie.eudaemon.net [72.250.241.194]) by ietfa.amsl.com (Postfix) with ESMTP id E4E401A04EE for <apps-discuss@ietf.org>; Thu, 30 Jan 2014 16:38:47 -0800 (PST)
Received: from [10.0.1.5] (75-130-203-145.dhcp.hckr.nc.charter.com [75.130.203.145]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by pie.eudaemon.net (Postfix) with ESMTPSA id 1B5B9CB46; Thu, 30 Jan 2014 19:39:02 -0500 (EST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_F6B1013F-08EE-49F8-A4DD-A49430DFA8CC"
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Tim Draegen <tim@eudaemon.net>
In-Reply-To: <CAL0qLwZFF_oDPsUSu7dV6M=JXG7=OAmb50MVwYS_r=ZRtsRtrg@mail.gmail.com>
Date: Thu, 30 Jan 2014 19:38:42 -0500
Message-Id: <65EF4F6D-0D6A-4F52-94CF-795A01E62F4B@eudaemon.net>
References: <CAL0qLwZFF_oDPsUSu7dV6M=JXG7=OAmb50MVwYS_r=ZRtsRtrg@mail.gmail.com>
To: "Murray S. Kucherawy" <superuser@gmail.com>
X-Mailer: Apple Mail (2.1827)
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Call for Adoption: draft-delany-nullmx
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 31 Jan 2014 00:38:50 -0000

--Apple-Mail=_F6B1013F-08EE-49F8-A4DD-A49430DFA8CC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

On Jan 30, 2014, at 4:46 PM, Murray S. Kucherawy <superuser@gmail.com> =
wrote:
> The mini-charter lists four people (in addition to the authors) =
willing to provide timely reviews and support for the document through =
publication.  I'd like to be able to list a couple more.  If you'd like =
to be added to that list, please say so in your reply.

This practical work makes sense to me.  Feel free to add me to the list.

=3D- Tim


--Apple-Mail=_F6B1013F-08EE-49F8-A4DD-A49430DFA8CC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Diso-8859-1"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">On Jan =
30, 2014, at 4:46 PM, Murray S. Kucherawy &lt;<a =
href=3D"mailto:superuser@gmail.com">superuser@gmail.com</a>&gt; =
wrote:<br><div><blockquote type=3D"cite"><span style=3D"font-family: =
Thonburi; font-size: 12px; font-style: normal; font-variant: normal; =
font-weight: normal; letter-spacing: normal; line-height: normal; =
orphans: auto; text-align: start; text-indent: 0px; text-transform: =
none; white-space: normal; widows: auto; word-spacing: 0px; =
-webkit-text-stroke-width: 0px; float: none; display: inline =
!important;">The mini-charter lists four people (in addition to the =
authors) willing to provide timely reviews and support for the document =
through publication.&nbsp; I'd like to be able to list a couple =
more.&nbsp; If you'd like to be added to that list, please say so in =
your reply.</span></blockquote><br></div><div>This practical work makes =
sense to me. &nbsp;Feel free to add me to the =
list.</div><div><br></div><div>=3D- =
Tim</div><div><br></div></body></html>=

--Apple-Mail=_F6B1013F-08EE-49F8-A4DD-A49430DFA8CC--

From kurta@drkurt.com  Thu Jan 30 17:10:30 2014
Return-Path: <kurta@drkurt.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60EBD1A0515 for <apps-discuss@ietfa.amsl.com>; Thu, 30 Jan 2014 17:10:30 -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 aoL7s71RVgES for <apps-discuss@ietfa.amsl.com>; Thu, 30 Jan 2014 17:10:29 -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 0F2691A04E2 for <apps-discuss@ietf.org>; Thu, 30 Jan 2014 17:10:28 -0800 (PST)
Received: by mail-wg0-f52.google.com with SMTP id b13so7810403wgh.7 for <apps-discuss@ietf.org>; Thu, 30 Jan 2014 17:10:25 -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=5TDHG2Kst4AKJ4nYX184RwpyOiFrLCMq8SMcv4JUMXg=; b=Ia5cNBXOgW+TMUVbABcRiQ1irwK5lw9khijlnog85K8Ut3sJdmt3E/QKK+bM1lMPua LIw7qyo1ItoQkuINRa1TNmPeK/rBVf0tv/YCqqCRO1Z8EDnIhXL9+Fp8lMm0ejB4pd8e xWtbQUwLa1CHP5pwNGC54SyRRweIfk0/VwfPU=
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=5TDHG2Kst4AKJ4nYX184RwpyOiFrLCMq8SMcv4JUMXg=; b=kOuZC0sCh/GPdwGz05oW2b4idUwfv+3ajNHWWIl6a4rx6GRU7xNPAzqA8nanaMhSmg aJZBYlDRH5+CsJaozzjQZZHdiKuPaJhZeFh6nrKNdHBg2KAwXmjApZ8u+wyS4C2LNIzB Daio7MHAUjaQsV03JkHJ7m/Ig/ZhZum/tiv1GJTSHRtFr20+FVsx8J45oJKa6SBxPPsv 5EbTFU4tqgxrzg9hjyfTcr1ODFhzK5reoFaTzhHu3c0RUxuOzgN4LIgOcjcrDvUbZ1L0 ew8BWHS8IEeXF7lWddABcnxCrE1CHQr/nYao3m1ExPjjnoKz1E34a8txJUhkaU9twbir HXbg==
X-Gm-Message-State: ALoCoQkFtX4AUIqAul//EtSwKedAFtfiy1radQ1Z060qVGvPK3fbj4VIFmwXziMD4e+5CMwtpvqJ
MIME-Version: 1.0
X-Received: by 10.180.108.130 with SMTP id hk2mr25575960wib.16.1391130625205;  Thu, 30 Jan 2014 17:10:25 -0800 (PST)
Sender: kurta@drkurt.com
Received: by 10.195.12.137 with HTTP; Thu, 30 Jan 2014 17:10:25 -0800 (PST)
In-Reply-To: <CAL0qLwZFF_oDPsUSu7dV6M=JXG7=OAmb50MVwYS_r=ZRtsRtrg@mail.gmail.com>
References: <CAL0qLwZFF_oDPsUSu7dV6M=JXG7=OAmb50MVwYS_r=ZRtsRtrg@mail.gmail.com>
Date: Thu, 30 Jan 2014 17:10:25 -0800
X-Google-Sender-Auth: -wNNlWnIv7pHUc3YvE3GO2BEprk
Message-ID: <CABuGu1qF3Yk+8OUsghPshLjWDAV9yAnHNrpv13v53McN+C1cdg@mail.gmail.com>
From: Kurt Andersen <kboth@drkurt.com>
To: "Murray S. Kucherawy" <superuser@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Call for Adoption: draft-delany-nullmx
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 31 Jan 2014 01:10:30 -0000

On Thu, Jan 30, 2014 at 1:46 PM, Murray S. Kucherawy
<superuser@gmail.com> wrote:
> The mini-charter lists four people (in addition to the authors) willing to
> provide timely reviews and support for the document through publication.
> I'd like to be able to list a couple more.  If you'd like to be added to
> that list, please say so in your reply.


I'll volunteer as well.

--Kurt Andersen

From ned.freed@mrochek.com  Thu Jan 30 19:41:58 2014
Return-Path: <ned.freed@mrochek.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CAD41A052A for <apps-discuss@ietfa.amsl.com>; Thu, 30 Jan 2014 19:41:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.437
X-Spam-Level: 
X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 VxnUvsYSqbB4 for <apps-discuss@ietfa.amsl.com>; Thu, 30 Jan 2014 19:41:56 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 6BEF11A0529 for <apps-discuss@ietf.org>; Thu, 30 Jan 2014 19:41:56 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P3RYRC4A34003TXZ@mauve.mrochek.com> for apps-discuss@ietf.org; Thu, 30 Jan 2014 19:36:49 -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 <01P3NP4TEOIO0000AS@mauve.mrochek.com>; Thu, 30 Jan 2014 19:36:43 -0800 (PST)
Message-id: <01P3RYR89V7M0000AS@mauve.mrochek.com>
Date: Thu, 30 Jan 2014 19:35:07 -0800 (PST)
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Thu, 30 Jan 2014 13:46:20 -0800" <CAL0qLwZFF_oDPsUSu7dV6M=JXG7=OAmb50MVwYS_r=ZRtsRtrg@mail.gmail.com>
References: <CAL0qLwZFF_oDPsUSu7dV6M=JXG7=OAmb50MVwYS_r=ZRtsRtrg@mail.gmail.com>
To: "Murray S. Kucherawy" <superuser@gmail.com>
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Call for Adoption: draft-delany-nullmx
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 31 Jan 2014 03:41:58 -0000

I support moving this document putting this document on the standards
track.

				Ned

> Colleagues,

> This is a formal call for adoption of draft-delany-nullmx into APPSAWG.
> The call will close on February 14, 2014.  The chairs note that there has
> already been some expression of support for adoption in past threads; more
> feedback is requested.

> As you've heard us say in Vancouver and earlier, we are instituting a new
> experimental idea with respect to documents in APPSAWG, namely
> "mini-charters" in order to frame discussions, set goals, and secure a
> minimal set of reviewers and supporters.  The mini-charter for this draft
> appears at the end of this message.

> Please submit comments, concerns, support, etc. for this document's
> handling by APPSAWG in reply to this thread by February 14, 2014.  Note
> that this is not an indication of support for the document as-is, only for
> APPSAWG adopting it for further development.

> The mini-charter lists four people (in addition to the authors) willing to
> provide timely reviews and support for the document through publication.
> I'd like to be able to list a couple more.  If you'd like to be added to
> that list, please say so in your reply.

> -MSK

> The mini-charter:

> SMTP mail has never provided a way for a domain to state that it does
> not receive mail.  If a domain publishes MX records, it definitely
> does receive mail.  If it publishes no MX, but does publish A or AAAA
> records there is no way to tell whether those records are indended to
> identify an "implicit MX".  If a sending host attempts to send to an A
> or AAAA, and is unable to connect, there is no way to tell whether the
> failure is temporary or permanent, short of repeated retries.

> As a result, if a user attempts to send mail to a mistyped domain, it
> can take up to a week (the recommended retry limit) to get back a
> failure report.  In principle, a domain could set up a stub mail
> server that accepted connections and immediately rejected delivery
> attempts, but that is more work than most domains want to do.  Hence
> our goal is to provide a cheap way to quickly tell senders not to
> bother.  (Note that an SPF record with "-all" says that a domain sends
> no mail, which is not necessarily the same as receiving no mail.)

> We propose that an MX record pointing to the root of the DNS, known as
> "MX ." means the domain accepts no mail.  This approach has been used
> informally for almost a decade, with few if any problems, but has
> never been described in an IETF document.  We propose only to assign
> the no-mail semantics to "MX ." and not make any other changes to
> SMTP.

> There is one draft to adopt: draft-delany-nullmx, to be submitted to the
> IESG by the end of May, 2014.

> The following have committed to work on the document through to publication:

> Murray Kucherawy <superuser@gmail.com>
> Dave Crocker <dcrocker@bbiw.net>
> Terry Zink <tzink@exchange.microsoft.com>
> Arnt Gulbrandsend <arnt@gulbrandsen.priv.no>

From yoshiro.yoneya@jprs.co.jp  Thu Jan 30 23:21:48 2014
Return-Path: <yoshiro.yoneya@jprs.co.jp>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5AFF1A0567 for <apps-discuss@ietfa.amsl.com>; Thu, 30 Jan 2014 23:21:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.773
X-Spam-Level: **
X-Spam-Status: No, score=2.773 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RP_MATCHES_RCVD=-0.535, 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 PetDoZD9fO5N for <apps-discuss@ietfa.amsl.com>; Thu, 30 Jan 2014 23:21:47 -0800 (PST)
Received: from off-send01.tyo.jprs.co.jp (off-send01.tyo.jprs.co.jp [IPv6:2001:df0:8:17::10]) by ietfa.amsl.com (Postfix) with ESMTP id 54E3A1A0566 for <apps-discuss@ietf.org>; Thu, 30 Jan 2014 23:21:47 -0800 (PST)
Received: from off-sendsmg01.tyo.jprs.co.jp (off-sendsmg01.tyo.jprs.co.jp [172.18.8.32]) by off-send01.tyo.jprs.co.jp (8.13.8/8.13.8) with ESMTP id s0V7LRpI023523; Fri, 31 Jan 2014 16:21:38 +0900
X-AuditID: ac120820-b7f196d00000167f-ec-52eb4f0081de
Received: from NOTE701 (off-cpu04.tyo.jprs.co.jp [172.18.4.14]) by off-sendsmg01.tyo.jprs.co.jp (Symantec Messaging Gateway) with SMTP id 64.FB.05759.00F4BE25; Fri, 31 Jan 2014 16:21:37 +0900 (JST)
Date: Fri, 31 Jan 2014 16:21:34 +0900
From: Yoshiro YONEYA <yoshiro.yoneya@jprs.co.jp>
To: apps-discuss@ietf.org, idna-update@alvestrand.no
Message-Id: <20140131162134.88f0cc49c3e9c98967f1345d@jprs.co.jp>
X-Mailer: Sylpheed 3.3.0 (GTK+ 2.10.14; i686-pc-mingw32)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHIsWRmVeSWpSXmKPExsWyRoiFT5fR/3WQQf9GFovVL1ewWcw//o/V gcnjyoQrrB5LlvxkCmCK4rJJSc3JLEst0rdL4Mq4+mQ3W8EZ9orHXxawNDDOZuti5OSQEDCR uD23mxHCFpO4cG89UJyLQ0jgOKPEnzv7WEASLAKqEnNbO8Aa2AQMJH4t+83UxcjBIQLUPGtz AEhYWEBGYu+MOewgYV4BB4nth6QhRlpIXGjqgAoLSvzdIQwSZhbQknj46xYLhC0vsf3tHOYJ jDyzEKpmIamahaRqASPzKkaZ/LQ03eLUvJTi3HQDQ72Syny9rIKiYr1kEL2JERw8HAo7GGec MjjEKMDBqMTDy1XwKkiINbGsuDL3EKMkB5OSKG+w2+sgIb6k/JTKjMTijPii0pzU4kOMEhzM SiK8Pe5AOd6UxMqq1KJ8mJQ0B4uSOO/xP2cChQTSE0tSs1NTC1KLYLIyHBxKErwLfYEaBYtS 01Mr0jJzShDSTBycIMN5gIYvB6nhLS5IzC3OTIfIn2KUlBLnTQZJCIAkMkrz4HpfMYoDvSDM exAkywNMBHBdr4AGMgEN1Cp/BTKwJBEhJdXAKFPjG7GtkfdI/brtpV5du69MnPnMjTvPw6j4 zRW/dZoP2eqfc3adzf+1zG+2rT2Djtr23U/vme9ZVRW378Mf1qIWeRext7cFXPNOusXmtDIb HNKLbOytPisX/fh6Vs3k/Xqnwp9sLLp9ZX7Kqw8mV59+n388dIuf7pvNv+Zp2S+RL3splBcu ocRSnJFoqMVcVJwIAB65bZnBAgAA
Subject: [apps-discuss] idnkit-2.3 released
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 31 Jan 2014 07:21:49 -0000

Dear all,

I'm very pleased to announce that JPRS has released idnkit-2.3 which is
an implementation of IDNA2008, and it provides features IDN encoding 
conversion tool and APIs for application software.

The idnkit-2.3 and its additional packages are available from following URL:
<http://jprs.co.jp/idn/index-e.html>

Major changes since idnkit-2.2 release are:

- Correspond to Unicode 6.3.0
  + IDNA Table version was updated according to IANA's idna-tables-6.3.0
  + Reference revision of UTS#46 was updated (5->11) according to Unicode 
    6.3.0 correspondence
- Fixed minor bugs

We hope that the idnkit-2.3 is useful for IDN zone administrators, IDN site 
administrators, IDN-aware application developers, and I18N related protocol 
designers.

Please feel free to give your comments regarding to the idnkit-2.3 to 
following e-mail address:
<mailto:idnkit-info@jprs.co.jp>

Regards,

-- 
Yoshiro YONEYA <yoshiro.yoneya@jprs.co.jp>


From ietfc@btconnect.com  Fri Jan 31 01:54:46 2014
Return-Path: <ietfc@btconnect.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD6371A044A for <apps-discuss@ietfa.amsl.com>; Fri, 31 Jan 2014 01:54:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 vFZmUcn1Djkc for <apps-discuss@ietfa.amsl.com>; Fri, 31 Jan 2014 01:54:44 -0800 (PST)
Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe002.messaging.microsoft.com [216.32.180.12]) by ietfa.amsl.com (Postfix) with ESMTP id AEAAE1A0388 for <apps-discuss@ietf.org>; Fri, 31 Jan 2014 01:54:44 -0800 (PST)
Received: from mail60-va3-R.bigfish.com (10.7.14.243) by VA3EHSOBE006.bigfish.com (10.7.40.26) with Microsoft SMTP Server id 14.1.225.22; Fri, 31 Jan 2014 09:54:40 +0000
Received: from mail60-va3 (localhost [127.0.0.1])	by mail60-va3-R.bigfish.com (Postfix) with ESMTP id BE54E601BB; Fri, 31 Jan 2014 09:54:40 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.253.85; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0710HT001.eurprd07.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -19
X-BigFish: PS-19(zz9371I542I1432Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h20f7h2189h1d1ah1d2ah21bch1fc6hzz8275ch1de098h1033IL8275bh8275dh186M1de097h186068hz2dh2a8h5a9h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh19f0h1ad9h1b0ah2222h224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h2218h2216h226dh22d0h24afh2327h2336h2438h2461h2487h24d7h2516h304l1d11m1155h)
Received: from mail60-va3 (localhost.localdomain [127.0.0.1]) by mail60-va3 (MessageSwitch) id 1391162078754635_32749; Fri, 31 Jan 2014 09:54:38 +0000 (UTC)
Received: from VA3EHSMHS011.bigfish.com (unknown [10.7.14.247])	by mail60-va3.bigfish.com (Postfix) with ESMTP id 99549420096;	Fri, 31 Jan 2014 09:54:38 +0000 (UTC)
Received: from DB3PRD0710HT001.eurprd07.prod.outlook.com (157.56.253.85) by VA3EHSMHS011.bigfish.com (10.7.99.21) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 31 Jan 2014 09:54:38 +0000
Received: from pc6 (81.159.188.189) by pod51017.outlook.com (10.255.75.36) with Microsoft SMTP Server (TLS) id 14.16.411.0; Fri, 31 Jan 2014 09:54:26 +0000
Message-ID: <00bd01cf1e69$cec2b560$4001a8c0@gateway.2wire.net>
From: t.petch <ietfc@btconnect.com>
To: "Murray S. Kucherawy" <superuser@gmail.com>, IETF Apps Discuss <apps-discuss@ietf.org>
References: <CAL0qLwZFF_oDPsUSu7dV6M=JXG7=OAmb50MVwYS_r=ZRtsRtrg@mail.gmail.com>
Date: Fri, 31 Jan 2014 09:49:55 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [81.159.188.189]
X-OriginatorOrg: btconnect.com
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
Subject: Re: [apps-discuss] Call for Adoption: draft-delany-nullmx
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 31 Jan 2014 09:54:47 -0000

Adopt (at last)

Tom Petch


----- Original Message -----
From: "Murray S. Kucherawy" <superuser@gmail.com>
To: "IETF Apps Discuss" <apps-discuss@ietf.org>
Sent: Thursday, January 30, 2014 9:46 PM

> Colleagues,
>
> This is a formal call for adoption of draft-delany-nullmx into
APPSAWG.
> The call will close on February 14, 2014.  The chairs note that there
has
> already been some expression of support for adoption in past threads;
more
> feedback is requested.
>
> As you've heard us say in Vancouver and earlier, we are instituting a
new
> experimental idea with respect to documents in APPSAWG, namely
> "mini-charters" in order to frame discussions, set goals, and secure a
> minimal set of reviewers and supporters.  The mini-charter for this
draft
> appears at the end of this message.
>
> Please submit comments, concerns, support, etc. for this document's
> handling by APPSAWG in reply to this thread by February 14, 2014.
Note
> that this is not an indication of support for the document as-is, only
for
> APPSAWG adopting it for further development.
>
> The mini-charter lists four people (in addition to the authors)
willing to
> provide timely reviews and support for the document through
publication.
> I'd like to be able to list a couple more.  If you'd like to be added
to
> that list, please say so in your reply.
>
> -MSK
>
> The mini-charter:
>
> SMTP mail has never provided a way for a domain to state that it does
> not receive mail.  If a domain publishes MX records, it definitely
> does receive mail.  If it publishes no MX, but does publish A or AAAA
> records there is no way to tell whether those records are indended to
> identify an "implicit MX".  If a sending host attempts to send to an A
> or AAAA, and is unable to connect, there is no way to tell whether the
> failure is temporary or permanent, short of repeated retries.
>
> As a result, if a user attempts to send mail to a mistyped domain, it
> can take up to a week (the recommended retry limit) to get back a
> failure report.  In principle, a domain could set up a stub mail
> server that accepted connections and immediately rejected delivery
> attempts, but that is more work than most domains want to do.  Hence
> our goal is to provide a cheap way to quickly tell senders not to
> bother.  (Note that an SPF record with "-all" says that a domain sends
> no mail, which is not necessarily the same as receiving no mail.)
>
> We propose that an MX record pointing to the root of the DNS, known as
> "MX ." means the domain accepts no mail.  This approach has been used
> informally for almost a decade, with few if any problems, but has
> never been described in an IETF document.  We propose only to assign
> the no-mail semantics to "MX ." and not make any other changes to
> SMTP.
>
> There is one draft to adopt: draft-delany-nullmx, to be submitted to
the
> IESG by the end of May, 2014.
>
> The following have committed to work on the document through to
publication:
>
> Murray Kucherawy <superuser@gmail.com>
> Dave Crocker <dcrocker@bbiw.net>
> Terry Zink <tzink@exchange.microsoft.com>
> Arnt Gulbrandsend <arnt@gulbrandsen.priv.no>
>


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


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



From ietfc@btconnect.com  Fri Jan 31 02:12:02 2014
Return-Path: <ietfc@btconnect.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2F261A0578 for <apps-discuss@ietfa.amsl.com>; Fri, 31 Jan 2014 02:12:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BfGHvS1scBbw for <apps-discuss@ietfa.amsl.com>; Fri, 31 Jan 2014 02:12:01 -0800 (PST)
Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id 0DBAF1A0579 for <apps-discuss@ietf.org>; Fri, 31 Jan 2014 02:12:00 -0800 (PST)
Received: from mail212-tx2-R.bigfish.com (10.9.14.251) by TX2EHSOBE011.bigfish.com (10.9.40.31) with Microsoft SMTP Server id 14.1.225.22; Fri, 31 Jan 2014 10:11:56 +0000
Received: from mail212-tx2 (localhost [127.0.0.1])	by mail212-tx2-R.bigfish.com (Postfix) with ESMTP id DFE282C01BB;	Fri, 31 Jan 2014 10:11:56 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.253.85; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0710HT004.eurprd07.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -16
X-BigFish: PS-16(zzbb2dI98dI9371I542I1432Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h20f7h2189h1d1ah1d2ah21bch1fc6hzz1de098h1033IL8275bh8275dh1de097hz2dh2a8h5a9h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh19f0h1ad9h1b0ah2222h224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h2218h2216h226dh22d0h24afh2327h2336h2438h2461h2487h24d7h2516h304l1d11m1155h)
Received: from mail212-tx2 (localhost.localdomain [127.0.0.1]) by mail212-tx2 (MessageSwitch) id 1391163115179742_23459; Fri, 31 Jan 2014 10:11:55 +0000 (UTC)
Received: from TX2EHSMHS019.bigfish.com (unknown [10.9.14.244])	by mail212-tx2.bigfish.com (Postfix) with ESMTP id 26BB714004F; Fri, 31 Jan 2014 10:11:55 +0000 (UTC)
Received: from DB3PRD0710HT004.eurprd07.prod.outlook.com (157.56.253.85) by TX2EHSMHS019.bigfish.com (10.9.99.119) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 31 Jan 2014 10:11:45 +0000
Received: from pc6 (81.159.188.189) by pod51017.outlook.com (10.255.75.39) with Microsoft SMTP Server (TLS) id 14.16.411.0; Fri, 31 Jan 2014 10:11:40 +0000
Message-ID: <00e701cf1e6c$36f59880$4001a8c0@gateway.2wire.net>
From: t.petch <ietfc@btconnect.com>
To: Robert Sparks <rjsparks@nostrum.com>, Ned Freed <ned.freed@mrochek.com>
References: <52E19901.4020705@nostrum.com> <01P3I75L6TC60000CD@mauve.mrochek.com> <52EA9F4B.1090700@nostrum.com>
Date: Fri, 31 Jan 2014 10:07:08 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [81.159.188.189]
X-OriginatorOrg: btconnect.com
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
Cc: draft-ietf-appsawg-sieve-duplicate@tools.ietf.org, IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Suggestions fordraft-ietf-appsawg-sieve-duplicate-02
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 31 Jan 2014 10:12:02 -0000

Robert

I am with you on these points.  Thus you cite the ambiguity of message
id while I cited unique id, same difference.

Looking back at those first comments I made, I now see that this I-D is
fine for Sieve expert implementers but lacks clarity for a wider
audience (which is where I fall - perhaps you do too).  Whether or not
that is ok I am less sure of; my starting point was that it should be
and am still inclined to that.

Tom Petch


----- Original Message -----
From: "Robert Sparks" <rjsparks@nostrum.com>
To: "Ned Freed" <ned.freed@mrochek.com>
Cc: <draft-ietf-appsawg-sieve-duplicate@tools.ietf.org>; "IETF Apps
Discuss" <apps-discuss@ietf.org>
Sent: Thursday, January 30, 2014 6:51 PM
Subject: Re: [apps-discuss] Suggestions
fordraft-ietf-appsawg-sieve-duplicate-02


> (Apologies for lag)
> Trimming to a couple of points:
>
> On 1/23/14, 6:11 PM, Ned Freed wrote:
> > 3) Comparison of the values taken from :header is assumed to be
bitwise
> >> (though case insensitive). Should that be made explicit? In
particular,
> >> you're not expecting a duplicate check on :header "Foo" to treat
> >> messages with
> >> Foo: a=one-thing; b=the-other
> >> and
> >> Foo: b=the-other; a=one-thing
> >> as duplicates.
> >
> > Sorry, that's incorrect on both counts. First, the document is very
> > clear that
> > the comparison is case-sensitive
> Apologies, I got that bit flipped when writing this up. My calling out
> sensitivity
> or not was triggered specifically by the text you quote below.
However,
> that's
> not really the main point I was hoping to discuss.
> > and you have to force the case if you want
> > sometihng different. From section 3:
> >
> >   The tracked unique ID value MUST be matched case-sensitively,
> >   irrespective of whether it originates from a header or is
specified
> >   explicitly using the ":uniqueid" argument.  To achieve case-
> >   insensitive behavior, the "set" command added by the "variables"
> >   [VARIABLES] extension can be used in combination with the
":uniqueid"
> >   argument to normalize the tracked unique ID value to upper or
lower
> >   case.
> >
> > Second, it's not an octet-by-octet comprison with :header -
whitespace
> > trimming
> > is part of the operation. Again from section 3:
> >
> >   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 MUST first be trimmed from the
value
> >   before performing the actual duplicate verification (see Section
2.2
> >   of RFC 5228 [SIEVE]).  Note that this also applies to the
Message-ID
> >   header field used by the basic "duplicate" test without a
":header"
> >   or ":uniqueid" argument.  When the ":uniqueid" argument is used,
such
> >   normalization concerns are the responsibility of the user.
> And I missed this. Does it apply also to what comes out of variables,
or
> does
> variable handling already ensure that you wouldn't have leading or
trailing
> whitespace to worry about?
>
> But what I was really trying to is confirm (and I don't think you
> verified in your response)
> that you aren't asking this code to learn about the details of any
> particular header
> field and treat things that are semantically the same (such as what
> might result
> from reordering name=value pairs as in the Foo example I gave above)
as
> equal
> for this comparison.
>
> >> 5) (minor, editorial) It might make implementation less error prone
to
> >> not use "message ID" at all, but say something like "Messages are
> >> identified by a 'seen' value computed from the message, which
defaults
> >> to the contents of the Message-ID header. That would lead to
sentences
> >> like "The 'duplicate' test MUST only check for duplicates amongst
'seen'
> >> values encountered in previous executions of the Sieve script; it
MUST
> >> NOT consider 'seen' values encountered earlier in the current Sieve
> >> script execution as potential duplicates.
> >
> > This doesn't sound much better to me. Or any worse, for that matter.
> I had asked a few non-IETF sysadmin/implementers to read this, and
they
> consistently hung on this point, saying they had to stop halfway
through
> and start rereading the document to make sure they kept when message
ID
> mean Message-ID and when it might not straight as they were reading.
> The other suggestion to point out early that Message ID is Message-ID
by
> default might be enough, but this suggestion seemed to resonate with
those
> folks. Maybe you can see something else that would do just as well.
(And
> I'm ok if you leave it as is).
>
> RjS



From tzink@exchange.microsoft.com  Fri Jan 31 11:06:47 2014
Return-Path: <tzink@exchange.microsoft.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B0E41A046F for <apps-discuss@ietfa.amsl.com>; Fri, 31 Jan 2014 11:06:47 -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 T2Z8xTkcTyhk for <apps-discuss@ietfa.amsl.com>; Fri, 31 Jan 2014 11:06:40 -0800 (PST)
Received: from na01-by1-obe.outbound.o365filtering.com (na01-by1-obe.ptr.o365filtering.com [64.4.22.89]) by ietfa.amsl.com (Postfix) with ESMTP id 84F381A0443 for <apps-discuss@ietf.org>; Fri, 31 Jan 2014 11:06:40 -0800 (PST)
Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com (10.255.109.167) by BL2SR01MB604.namsdf01.sdf.exchangelabs.com (10.255.109.166) with Microsoft SMTP Server (TLS) id 15.0.878.8; Fri, 31 Jan 2014 18:51:26 +0000
Received: from BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.8.36]) by BL2SR01MB605.namsdf01.sdf.exchangelabs.com ([169.254.8.36]) with mapi id 15.00.0878.008; Fri, 31 Jan 2014 18:51:25 +0000
From: Terry Zink <tzink@exchange.microsoft.com>
To: Kurt Andersen <kboth@drkurt.com>, "Murray S. Kucherawy" <superuser@gmail.com>
Thread-Topic: [apps-discuss] Call for Adoption: draft-delany-nullmx
Thread-Index: AQHPHgS74DulrLH2lkiV6cb3Ez10uJqeBmeAgAEoa0A=
Date: Fri, 31 Jan 2014 18:51:24 +0000
Message-ID: <910a6a81564d428ca36ac430f016f654@BL2SR01MB605.namsdf01.sdf.exchangelabs.com>
References: <CAL0qLwZFF_oDPsUSu7dV6M=JXG7=OAmb50MVwYS_r=ZRtsRtrg@mail.gmail.com> <CABuGu1qF3Yk+8OUsghPshLjWDAV9yAnHNrpv13v53McN+C1cdg@mail.gmail.com>
In-Reply-To: <CABuGu1qF3Yk+8OUsghPshLjWDAV9yAnHNrpv13v53McN+C1cdg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [131.107.147.248]
x-forefront-prvs: 0108A997B2
x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(377454003)(24454002)(189002)(199002)(13464003)(87936001)(74366001)(87266001)(19580405001)(83322001)(19580395003)(2656002)(85306002)(80976001)(59766001)(77982001)(69226001)(76482001)(56776001)(54316002)(80022001)(65816001)(66066001)(74876001)(79102001)(63696002)(81342001)(53806001)(81542001)(77096001)(46102001)(51856001)(76786001)(49866001)(47976001)(76796001)(54356001)(31966008)(47446002)(74662001)(74502001)(94946001)(94316002)(74706001)(93136001)(93516002)(50986001)(47736001)(4396001)(85852003)(81686001)(83072002)(81816001)(92566001)(33646001)(15975445006)(56816005)(90146001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BL2SR01MB604; H:BL2SR01MB605.namsdf01.sdf.exchangelabs.com; CLIP:131.107.147.248; FPR:D4154941.9F079FE2.79F0BDBF.18CE9E5D.20177; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: exchange.microsoft.com
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Call for Adoption: draft-delany-nullmx
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 31 Jan 2014 19:06:47 -0000

Me, too.

-- Terry

-----Original Message-----
From: apps-discuss [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Kurt=
 Andersen
Sent: Thursday, January 30, 2014 5:10 PM
To: Murray S. Kucherawy
Cc: IETF Apps Discuss
Subject: Re: [apps-discuss] Call for Adoption: draft-delany-nullmx

On Thu, Jan 30, 2014 at 1:46 PM, Murray S. Kucherawy <superuser@gmail.com> =
wrote:
> The mini-charter lists four people (in addition to the authors)=20
> willing to provide timely reviews and support for the document through pu=
blication.
> I'd like to be able to list a couple more.  If you'd like to be added=20
> to that list, please say so in your reply.


I'll volunteer as well.

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

From ned.freed@mrochek.com  Fri Jan 31 12:17:23 2014
Return-Path: <ned.freed@mrochek.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 870871A0443 for <apps-discuss@ietfa.amsl.com>; Fri, 31 Jan 2014 12:17:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.437
X-Spam-Level: 
X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 s7YvJ6PhsakB for <apps-discuss@ietfa.amsl.com>; Fri, 31 Jan 2014 12:17:18 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 9E1511A03F5 for <apps-discuss@ietf.org>; Fri, 31 Jan 2014 12:17:18 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P3SXIDRX0G003MSU@mauve.mrochek.com> for apps-discuss@ietf.org; Fri, 31 Jan 2014 12:12:10 -0800 (PST)
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=iso-8859-1; format=flowed
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P3NP4TEOIO0000AS@mauve.mrochek.com>; Fri, 31 Jan 2014 12:12:03 -0800 (PST)
Message-id: <01P3SXI9NT3Q0000AS@mauve.mrochek.com>
Date: Fri, 31 Jan 2014 11:42:04 -0800 (PST)
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Thu, 30 Jan 2014 12:51:55 -0600" <52EA9F4B.1090700@nostrum.com>
References: <52E19901.4020705@nostrum.com> <01P3I75L6TC60000CD@mauve.mrochek.com> <52EA9F4B.1090700@nostrum.com>
To: Robert Sparks <rjsparks@nostrum.com>
Cc: Ned Freed <ned.freed@mrochek.com>, draft-ietf-appsawg-sieve-duplicate@tools.ietf.org, IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Suggestions for draft-ietf-appsawg-sieve-duplicate-02
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 31 Jan 2014 20:17:23 -0000

> > Second, it's not an octet-by-octet comprison with :header - whitespace
> > trimming
> > is part of the operation. Again from section 3:
> >
> >   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 MUST first be trimmed from the value
> >   before performing the actual duplicate verification (see Section 2.2
> >   of RFC 5228 [SIEVE]).  Note that this also applies to the Message-ID
> >   header field used by the basic "duplicate" test without a ":header"
> >   or ":uniqueid" argument.  When the ":uniqueid" argument is used, such
> >   normalization concerns are the responsibility of the user.

> And I missed this. Does it apply also to what comes out of variables, or
> does variable handling already ensure that you wouldn't have leading or trailing
> whitespace to worry about?

The answer is no, it doesn't apply to stuff coming out of variables - and I
think the draft is clear about this.

As for stuff coming out of variables not needing such processing, it depends.
The header test strips leading and trailing spaces, so if it was used to load
the variable, then yes, there won't be leading and trailing spaces. But
variables can be assigned values in lots of ways, and if you do it in a way
that adds leading or trailing spaces, then that's going to be part of the
compared value. Which is the way it needs to work, because who's to say those
spaces aren't put there intentionally?

That said, given the way sieve works it's actually kind of hard to end up with
leading or trailing whitespace in a variable that you don't want or need. If
you do end up with it, then a string :matches test can always be used to get
rid of it.

> But what I was really trying to is confirm (and I don't think you
> verified in your response)
> that you aren't asking this code to learn about the details of any
> particular header
> field and treat things that are semantically the same (such as what
> might result
> from reordering name=value pairs as in the Foo example I gave above) as
> equal
> for this comparison.

Of course not. And I have no idea how you could have possibly gotten the 
notion that would be desireable, let alone required, by anything in the draft.

More generally, this discussion is becoming less and less about the specifics
of this draft and more and more about general sieve semantics. The whitespace
semantics  here were intentionally chosen so they match those of the sieve
header and string tests - the former drops leading and trailing whitespace
while the latter does not.

And as for how the language embeds handling of header syntax, the general sieve
model for that is to define a separate tests for each semantic you're
interested in. The sieve base specification defines the header (entire content
of header minus leading and trailing whitespace) and the address (parse out
address from header, test specified part) tests, and subsequent drafts have
defined the date test (parse out date, test specified part(s) in specified
form), the index extension (test Nth appearing field), the subaddress extension
(add detail part to address test), and the mime extension (parse MIME
content-type and content-disposition fields, test specified part or parameter).
A combination of the header and string tests can also be used to implement
limited forms of header parsing. And it may make sense to add additional tests
in the future.

And since the matching part(s) of any test can be stored in a variable, all of
these provide ways to parse a header field and store the result in a variable.
Which then can be used as part of a uniqueid value.

But all of this is just part and parcel of using sieve; none of it seems
relevant to what is after all a draft defining a small, simple duplicate
elimination facility. If you want to argue that there should be some document
somewhere that explains all this, fine, but this isn't that document.

				Ned

From rjsparks@nostrum.com  Fri Jan 31 12:32:08 2014
Return-Path: <rjsparks@nostrum.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 626321A0456 for <apps-discuss@ietfa.amsl.com>; Fri, 31 Jan 2014 12:32:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level: 
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] 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 6QyPZijVI2_Q for <apps-discuss@ietfa.amsl.com>; Fri, 31 Jan 2014 12:32:06 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9E8381A03CC for <apps-discuss@ietf.org>; Fri, 31 Jan 2014 12:32:06 -0800 (PST)
Received: from unnumerable.local (pool-173-71-10-88.dllstx.fios.verizon.net [173.71.10.88]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id s0VKVxg7055943 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK); Fri, 31 Jan 2014 14:31:59 -0600 (CST) (envelope-from rjsparks@nostrum.com)
Message-ID: <52EC083F.8070100@nostrum.com>
Date: Fri, 31 Jan 2014 14:31:59 -0600
From: Robert Sparks <rjsparks@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Ned Freed <ned.freed@mrochek.com>
References: <52E19901.4020705@nostrum.com> <01P3I75L6TC60000CD@mauve.mrochek.com> <52EA9F4B.1090700@nostrum.com> <01P3SXI9NT3Q0000AS@mauve.mrochek.com>
In-Reply-To: <01P3SXI9NT3Q0000AS@mauve.mrochek.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (shaman.nostrum.com: 173.71.10.88 is authenticated by a trusted mechanism)
Cc: draft-ietf-appsawg-sieve-duplicate@tools.ietf.org, IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Suggestions for draft-ietf-appsawg-sieve-duplicate-02
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 31 Jan 2014 20:32:08 -0000

I think you're reading far more into what I'm saying than what's there.

Let me try to bring this up a level, and make a slightly different 
suggestion
based on your feedback.

Would you be willing to point out in the draft that if a script writer 
wanted
comparisons of headers to match even when parameters are reordered, they
need to do some work (probably using variables) themselves?

No is ok (and I'm guessing you don't think it's necessary based on the
exposition below), but I suggest it's a case where the script writers (who
aren't always going to be deeply steeped sieve experts when they start
out) are likely to stub their toe and a short nudge that this is something
for them to watch out for will help.

RjS

On 1/31/14, 1:42 PM, Ned Freed wrote:
>> > Second, it's not an octet-by-octet comprison with :header - whitespace
>> > trimming
>> > is part of the operation. Again from section 3:
>> >
>> >   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 MUST first be trimmed from the value
>> >   before performing the actual duplicate verification (see Section 2.2
>> >   of RFC 5228 [SIEVE]).  Note that this also applies to the Message-ID
>> >   header field used by the basic "duplicate" test without a ":header"
>> >   or ":uniqueid" argument.  When the ":uniqueid" argument is used, 
>> such
>> >   normalization concerns are the responsibility of the user.
>
>> And I missed this. Does it apply also to what comes out of variables, or
>> does variable handling already ensure that you wouldn't have leading 
>> or trailing
>> whitespace to worry about?
>
> The answer is no, it doesn't apply to stuff coming out of variables - 
> and I
> think the draft is clear about this.
>
> As for stuff coming out of variables not needing such processing, it 
> depends.
> The header test strips leading and trailing spaces, so if it was used 
> to load
> the variable, then yes, there won't be leading and trailing spaces. But
> variables can be assigned values in lots of ways, and if you do it in 
> a way
> that adds leading or trailing spaces, then that's going to be part of the
> compared value. Which is the way it needs to work, because who's to 
> say those
> spaces aren't put there intentionally?
>
> That said, given the way sieve works it's actually kind of hard to end 
> up with
> leading or trailing whitespace in a variable that you don't want or 
> need. If
> you do end up with it, then a string :matches test can always be used 
> to get
> rid of it.
>
>> But what I was really trying to is confirm (and I don't think you
>> verified in your response)
>> that you aren't asking this code to learn about the details of any
>> particular header
>> field and treat things that are semantically the same (such as what
>> might result
>> from reordering name=value pairs as in the Foo example I gave above) as
>> equal
>> for this comparison.
>
> Of course not. And I have no idea how you could have possibly gotten 
> the notion that would be desireable, let alone required, by anything 
> in the draft.
>
> More generally, this discussion is becoming less and less about the 
> specifics
> of this draft and more and more about general sieve semantics. The 
> whitespace
> semantics  here were intentionally chosen so they match those of the 
> sieve
> header and string tests - the former drops leading and trailing 
> whitespace
> while the latter does not.
>
> And as for how the language embeds handling of header syntax, the 
> general sieve
> model for that is to define a separate tests for each semantic you're
> interested in. The sieve base specification defines the header (entire 
> content
> of header minus leading and trailing whitespace) and the address 
> (parse out
> address from header, test specified part) tests, and subsequent drafts 
> have
> defined the date test (parse out date, test specified part(s) in 
> specified
> form), the index extension (test Nth appearing field), the subaddress 
> extension
> (add detail part to address test), and the mime extension (parse MIME
> content-type and content-disposition fields, test specified part or 
> parameter).
> A combination of the header and string tests can also be used to 
> implement
> limited forms of header parsing. And it may make sense to add 
> additional tests
> in the future.
>
> And since the matching part(s) of any test can be stored in a 
> variable, all of
> these provide ways to parse a header field and store the result in a 
> variable.
> Which then can be used as part of a uniqueid value.
>
> But all of this is just part and parcel of using sieve; none of it seems
> relevant to what is after all a draft defining a small, simple duplicate
> elimination facility. If you want to argue that there should be some 
> document
> somewhere that explains all this, fine, but this isn't that document.
>
>                 Ned


From ned.freed@mrochek.com  Fri Jan 31 16:00:18 2014
Return-Path: <ned.freed@mrochek.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64BB11ACC7D for <apps-discuss@ietfa.amsl.com>; Fri, 31 Jan 2014 16:00:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.437
X-Spam-Level: 
X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 O9NNEogttRjH for <apps-discuss@ietfa.amsl.com>; Fri, 31 Jan 2014 16:00:17 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 01C9A1ACB4E for <apps-discuss@ietf.org>; Fri, 31 Jan 2014 16:00:17 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P3T5ATBYTS003UQG@mauve.mrochek.com> for apps-discuss@ietf.org; Fri, 31 Jan 2014 15:55:08 -0800 (PST)
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=iso-8859-1; format=flowed
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P3NP4TEOIO0000AS@mauve.mrochek.com>; Fri, 31 Jan 2014 15:55:02 -0800 (PST)
Message-id: <01P3T5AP6CES0000AS@mauve.mrochek.com>
Date: Fri, 31 Jan 2014 15:29:00 -0800 (PST)
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Fri, 31 Jan 2014 14:31:59 -0600" <52EC083F.8070100@nostrum.com>
References: <52E19901.4020705@nostrum.com> <01P3I75L6TC60000CD@mauve.mrochek.com> <52EA9F4B.1090700@nostrum.com> <01P3SXI9NT3Q0000AS@mauve.mrochek.com> <52EC083F.8070100@nostrum.com>
To: Robert Sparks <rjsparks@nostrum.com>
Cc: Ned Freed <ned.freed@mrochek.com>, draft-ietf-appsawg-sieve-duplicate@tools.ietf.org, IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Suggestions for draft-ietf-appsawg-sieve-duplicate-02
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 01 Feb 2014 00:00:18 -0000

> I think you're reading far more into what I'm saying than what's there.

> Let me try to bring this up a level, and make a slightly different
> suggestion
> based on your feedback.

> Would you be willing to point out in the draft that if a script writer wanted
> comparisons of headers to match even when parameters are reordered, they
> need to do some work (probably using variables) themselves?

I'm not the author; what goes in the draft is not up to me.

That said, IMO saying something like this would be both pointless and a bad
idea. If you're checking headers that contain parameters (as opposed to the
straightforward checks of things like message-id and subject fields, which
don't contain parameter lists), you're either doing something wrong or you're
doing something very tricky indeed.

And if parameters were reordered, it's a reasonable supposition that it was
done as a consequence of something other change being made. How do you propose
to accomodate such a change in the context of a duplicate test? Given that, I
see any discussion of accomodating parameter reordering as likely to lead users
into doing things they should not be doing.

Frankly, I can't even think of a use-case where I'd want to feed a header field
whose syntax involves an unordered set of parameters into a duplicate test, let
alone one where I'd want to do the test in a way that needed to ignore
parameter ordering.

				Ned

From rjsparks@nostrum.com  Fri Jan 31 16:27:15 2014
Return-Path: <rjsparks@nostrum.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B256D1AC7EE for <apps-discuss@ietfa.amsl.com>; Fri, 31 Jan 2014 16:27:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level: 
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] 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 Iq1UjMNdgUsd for <apps-discuss@ietfa.amsl.com>; Fri, 31 Jan 2014 16:27:14 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 470321A04F8 for <apps-discuss@ietf.org>; Fri, 31 Jan 2014 16:27:14 -0800 (PST)
Received: from unnumerable.local (pool-173-71-10-88.dllstx.fios.verizon.net [173.71.10.88]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id s110R6C8065062 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK); Fri, 31 Jan 2014 18:27:06 -0600 (CST) (envelope-from rjsparks@nostrum.com)
Message-ID: <52EC3F59.8070608@nostrum.com>
Date: Fri, 31 Jan 2014 18:27:05 -0600
From: Robert Sparks <rjsparks@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Ned Freed <ned.freed@mrochek.com>
References: <52E19901.4020705@nostrum.com> <01P3I75L6TC60000CD@mauve.mrochek.com> <52EA9F4B.1090700@nostrum.com> <01P3SXI9NT3Q0000AS@mauve.mrochek.com> <52EC083F.8070100@nostrum.com> <01P3T5AP6CES0000AS@mauve.mrochek.com>
In-Reply-To: <01P3T5AP6CES0000AS@mauve.mrochek.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (shaman.nostrum.com: 173.71.10.88 is authenticated by a trusted mechanism)
Cc: draft-ietf-appsawg-sieve-duplicate@tools.ietf.org, IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Suggestions for draft-ietf-appsawg-sieve-duplicate-02
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 01 Feb 2014 00:27:15 -0000

On 1/31/14, 5:29 PM, Ned Freed wrote:
>> I think you're reading far more into what I'm saying than what's there.
>
>> Let me try to bring this up a level, and make a slightly different
>> suggestion
>> based on your feedback.
>
>> Would you be willing to point out in the draft that if a script 
>> writer wanted
>> comparisons of headers to match even when parameters are reordered, they
>> need to do some work (probably using variables) themselves?
>
> I'm not the author; what goes in the draft is not up to me.
>
> That said, IMO saying something like this would be both pointless and 
> a bad
> idea. If you're checking headers that contain parameters (as opposed 
> to the
> straightforward checks of things like message-id and subject fields, 
> which
> don't contain parameter lists), you're either doing something wrong or 
> you're
> doing something very tricky indeed.
>
> And if parameters were reordered, it's a reasonable supposition that 
> it was
> done as a consequence of something other change being made. How do you 
> propose
> to accomodate such a change in the context of a duplicate test? Given 
> that, I
> see any discussion of accomodating parameter reordering as likely to 
> lead users
> into doing things they should not be doing.
>
> Frankly, I can't even think of a use-case where I'd want to feed a 
> header field
> whose syntax involves an unordered set of parameters into a duplicate 
> test, let
> alone one where I'd want to do the test in a way that needed to ignore
> parameter ordering.
So, finding _safe_ use cases where you use anything besides Message-ID seems
really suspect, but that bridge appears to have been crossed.

The draft calls out an example of getting effectively the same message from
more than one monitoring agent, and looking at things like Subject to decide
to mark some messages "seen". Such a test might well want to look at the 
mime
parameters in Content-Type and see if any attachments are likely the 
same before
making than seen marking. Since these came from different monitoring agents,
the order of the parameters might well be very different.

Yeah, that's nuts, and I wouldn't want to rely on it, but it seems to be 
what's
motivating matching more than Message-ID in the first place.

RjS
>
>                 Ned


From ned.freed@mrochek.com  Fri Jan 31 19:15:43 2014
Return-Path: <ned.freed@mrochek.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FC0D1ABBB1 for <apps-discuss@ietfa.amsl.com>; Fri, 31 Jan 2014 19:15:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.437
X-Spam-Level: 
X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 23Ss0E9j7kVO for <apps-discuss@ietfa.amsl.com>; Fri, 31 Jan 2014 19:15:41 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 6A4761A0508 for <apps-discuss@ietf.org>; Fri, 31 Jan 2014 19:15:41 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P3TC52L60W003U0Y@mauve.mrochek.com> for apps-discuss@ietf.org; Fri, 31 Jan 2014 19:10:32 -0800 (PST)
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=iso-8859-1; format=flowed
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P3NP4TEOIO0000AS@mauve.mrochek.com>; Fri, 31 Jan 2014 19:10:26 -0800 (PST)
Message-id: <01P3TC4YBNUO0000AS@mauve.mrochek.com>
Date: Fri, 31 Jan 2014 19:01:05 -0800 (PST)
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Fri, 31 Jan 2014 18:27:05 -0600" <52EC3F59.8070608@nostrum.com>
References: <52E19901.4020705@nostrum.com> <01P3I75L6TC60000CD@mauve.mrochek.com> <52EA9F4B.1090700@nostrum.com> <01P3SXI9NT3Q0000AS@mauve.mrochek.com> <52EC083F.8070100@nostrum.com> <01P3T5AP6CES0000AS@mauve.mrochek.com> <52EC3F59.8070608@nostrum.com>
To: Robert Sparks <rjsparks@nostrum.com>
Cc: Ned Freed <ned.freed@mrochek.com>, draft-ietf-appsawg-sieve-duplicate@tools.ietf.org, IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Suggestions for draft-ietf-appsawg-sieve-duplicate-02
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 01 Feb 2014 03:15:43 -0000

> So, finding _safe_ use cases where you use anything besides Message-ID seems
> really suspect, but that bridge appears to have been crossed.

Given that the draft gives not one but two perfectly reasonable examples of
such uses, this  claim appears to be bogus.

> The draft calls out an example of getting effectively the same message from
> more than one monitoring agent, and looking at things like Subject to decide
> to mark some messages "seen". Such a test might well want to look at the
> mime
> parameters in Content-Type and see if any attachments are likely the
> same before
> making than seen marking. Since these came from different monitoring agents,
> the order of the parameters might well be very different.

Actually, no, it would not want to do that. The point of the example is to
avoid being showered with alerts about the same underlying event from different
systems. In such cases the alerts will at a minimum be formatted different and
may well have different content-types.

> Yeah, that's nuts, and I wouldn't want to rely on it, but it seems to be
> what's motivating matching more than Message-ID in the first place.

I'm afraid I find this modification to be entirely unpersuasive.

				Ned

From ned.freed@mrochek.com  Fri Jan 31 19:23:30 2014
Return-Path: <ned.freed@mrochek.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC9391A04D6 for <apps-discuss@ietfa.amsl.com>; Fri, 31 Jan 2014 19:23:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.437
X-Spam-Level: 
X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 DzuiVywBxkex for <apps-discuss@ietfa.amsl.com>; Fri, 31 Jan 2014 19:23:29 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id BE3101A0454 for <apps-discuss@ietf.org>; Fri, 31 Jan 2014 19:23:29 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P3TCEQAO6O0041XU@mauve.mrochek.com> for apps-discuss@ietf.org; Fri, 31 Jan 2014 19:18:20 -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 <01P3NP4TEOIO0000AS@mauve.mrochek.com>; Fri, 31 Jan 2014 19:18:13 -0800 (PST)
Message-id: <01P3TCEMZHRS0000AS@mauve.mrochek.com>
Date: Fri, 31 Jan 2014 19:13:35 -0800 (PST)
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Fri, 31 Jan 2014 10:07:08 +0000" <00e701cf1e6c$36f59880$4001a8c0@gateway.2wire.net>
References: <52E19901.4020705@nostrum.com> <01P3I75L6TC60000CD@mauve.mrochek.com> <52EA9F4B.1090700@nostrum.com> <00e701cf1e6c$36f59880$4001a8c0@gateway.2wire.net>
To: "t.petch" <ietfc@btconnect.com>
Cc: Ned Freed <ned.freed@mrochek.com>, draft-ietf-appsawg-sieve-duplicate@tools.ietf.org, IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Suggestions fordraft-ietf-appsawg-sieve-duplicate-02
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 01 Feb 2014 03:23:31 -0000

> Robert

> I am with you on these points.  Thus you cite the ambiguity of message
> id while I cited unique id, same difference.

I have no idea what ambiguity you're referring to here.

> Looking back at those first comments I made, I now see that this I-D is
> fine for Sieve expert implementers but lacks clarity for a wider
> audience (which is where I fall - perhaps you do too).  Whether or not
> that is ok I am less sure of; my starting point was that it should be
> and am still inclined to that.

This makes no sense to me either. Are you saying that the extension is hard for
people writing sieves to use? If so, then I don't think you've made  a case for
that. Indeed, one of the things I find to be most appealing about this
extension is how simple it is to use.

And if you actually mean the people who implement sieve extensions, well,
yeah, if you're adding an extension to a Sieve interpreter you'd damn well
be familiar with the semantics of the language. How is it in any way
unreasonable to expect that?

				Ned

From mnot@mnot.net  Fri Jan 31 21:30:34 2014
Return-Path: <mnot@mnot.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C70BA1A04E0 for <apps-discuss@ietfa.amsl.com>; Fri, 31 Jan 2014 21:30:34 -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 Tuj9H7XVpnfT for <apps-discuss@ietfa.amsl.com>; Fri, 31 Jan 2014 21:30:32 -0800 (PST)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id CC4841A045A for <apps-discuss@ietf.org>; Fri, 31 Jan 2014 21:30:32 -0800 (PST)
Received: from [192.168.1.57] (unknown [118.209.40.94]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 1E71150A73 for <apps-discuss@ietf.org>; Sat,  1 Feb 2014 00:30:27 -0500 (EST)
From: Mark Nottingham <mnot@mnot.net>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Date: Sat, 1 Feb 2014 16:30:23 +1100
References: <20140201051504.8239.65074.idtracker@ietfa.amsl.com>
To: IETF Apps Discuss <apps-discuss@ietf.org>
Message-Id: <07D9CE9F-E042-4C6E-B5F4-6933E51EED0F@mnot.net>
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
X-Mailer: Apple Mail (2.1827)
Subject: [apps-discuss] Fwd: New Version Notification for draft-nottingham-http-problem-06.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 01 Feb 2014 05:30:35 -0000

FYI. Major change was to allow =91type=92 to default to =91about:blank=92.=



Begin forwarded message:

> From: internet-drafts@ietf.org
> Subject: New Version Notification for =
draft-nottingham-http-problem-06.txt
> Date: 1 February 2014 4:15:04 pm AEDT
> To: "Mark Nottingham" <mnot@mnot.net>, "Erik Wilde" =
<dret@berkeley.edu>, Erik Wilde <dret@berkeley.edu>, Mark Nottingham =
<mnot@mnot.net>
>=20
>=20
> A new version of I-D, draft-nottingham-http-problem-06.txt
> has been successfully submitted by Mark Nottingham and posted to the
> IETF repository.
>=20
> Name:		draft-nottingham-http-problem
> Revision:	06
> Title:		Problem Details for HTTP APIs
> Document date:	2014-02-01
> Group:		Individual Submission
> Pages:		13
> URL:            =
http://www.ietf.org/internet-drafts/draft-nottingham-http-problem-06.txt
> Status:         =
https://datatracker.ietf.org/doc/draft-nottingham-http-problem/
> Htmlized:       =
http://tools.ietf.org/html/draft-nottingham-http-problem-06
> Diff:           =
http://www.ietf.org/rfcdiff?url2=3Ddraft-nottingham-http-problem-06
>=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 rjsparks@nostrum.com  Fri Jan 31 21:44:57 2014
Return-Path: <rjsparks@nostrum.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28B951A0530 for <apps-discuss@ietfa.amsl.com>; Fri, 31 Jan 2014 21:44:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level: 
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] 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 N4vPsDs2guX7 for <apps-discuss@ietfa.amsl.com>; Fri, 31 Jan 2014 21:44:55 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id ACACF1A052F for <apps-discuss@ietf.org>; Fri, 31 Jan 2014 21:44:55 -0800 (PST)
Received: from unnumerable.local (pool-173-71-10-88.dllstx.fios.verizon.net [173.71.10.88]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id s115insZ076433 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=OK); Fri, 31 Jan 2014 23:44:49 -0600 (CST) (envelope-from rjsparks@nostrum.com)
Message-ID: <52EC89D1.8050805@nostrum.com>
Date: Fri, 31 Jan 2014 23:44:49 -0600
From: Robert Sparks <rjsparks@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Ned Freed <ned.freed@mrochek.com>
References: <52E19901.4020705@nostrum.com> <01P3I75L6TC60000CD@mauve.mrochek.com> <52EA9F4B.1090700@nostrum.com> <01P3SXI9NT3Q0000AS@mauve.mrochek.com> <52EC083F.8070100@nostrum.com> <01P3T5AP6CES0000AS@mauve.mrochek.com> <52EC3F59.8070608@nostrum.com> <01P3TC4YBNUO0000AS@mauve.mrochek.com>
In-Reply-To: <01P3TC4YBNUO0000AS@mauve.mrochek.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (shaman.nostrum.com: 173.71.10.88 is authenticated by a trusted mechanism)
Cc: draft-ietf-appsawg-sieve-duplicate@tools.ietf.org, IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Suggestions for draft-ietf-appsawg-sieve-duplicate-02
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 01 Feb 2014 05:44:57 -0000

On 1/31/14, 9:01 PM, Ned Freed wrote:
>> So, finding _safe_ use cases where you use anything besides 
>> Message-ID seems
>> really suspect, but that bridge appears to have been crossed.
>
> Given that the draft gives not one but two perfectly reasonable 
> examples of
> such uses, this  claim appears to be bogus.
>
>> The draft calls out an example of getting effectively the same 
>> message from
>> more than one monitoring agent, and looking at things like Subject to 
>> decide
>> to mark some messages "seen". Such a test might well want to look at the
>> mime
>> parameters in Content-Type and see if any attachments are likely the
>> same before
>> making than seen marking. Since these came from different monitoring 
>> agents,
>> the order of the parameters might well be very different.
>
> Actually, no, it would not want to do that. The point of the example 
> is to
> avoid being showered with alerts about the same underlying event from 
> different
> systems. In such cases the alerts will at a minimum be formatted 
> different and
> may well have different content-types.
>
>> Yeah, that's nuts, and I wouldn't want to rely on it, but it seems to be
>> what's motivating matching more than Message-ID in the first place.
>
> I'm afraid I find this modification to be entirely unpersuasive.
Wow.

I would seriously not want a message that had a pcap dump of what led to 
a serious situation marked read
because an earlier text message from some other system provided a 
shallow text overview of what happened,
but I wouldn't try to use this extension this way anyway.

Maybe that's your point - that someone that cared wouldn't write a 
script that does that.
But I feel the current text points down that path.

RjS



>
>                 Ned


From ned.freed@mrochek.com  Fri Jan 31 22:41:07 2014
Return-Path: <ned.freed@mrochek.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 873E31A0535 for <apps-discuss@ietfa.amsl.com>; Fri, 31 Jan 2014 22:41:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.437
X-Spam-Level: 
X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, 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 RUGHuVl9bNtU for <apps-discuss@ietfa.amsl.com>; Fri, 31 Jan 2014 22:41:05 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC611A0530 for <apps-discuss@ietf.org>; Fri, 31 Jan 2014 22:41:05 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P3TJAQDZWW004339@mauve.mrochek.com> for apps-discuss@ietf.org; Fri, 31 Jan 2014 22:35:55 -0800 (PST)
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=iso-8859-1; format=flowed
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01P3NP4TEOIO0000AS@mauve.mrochek.com>; Fri, 31 Jan 2014 22:35:47 -0800 (PST)
Message-id: <01P3TJALUVNE0000AS@mauve.mrochek.com>
Date: Fri, 31 Jan 2014 22:08:49 -0800 (PST)
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Fri, 31 Jan 2014 23:44:49 -0600" <52EC89D1.8050805@nostrum.com>
References: <52E19901.4020705@nostrum.com> <01P3I75L6TC60000CD@mauve.mrochek.com> <52EA9F4B.1090700@nostrum.com> <01P3SXI9NT3Q0000AS@mauve.mrochek.com> <52EC083F.8070100@nostrum.com> <01P3T5AP6CES0000AS@mauve.mrochek.com> <52EC3F59.8070608@nostrum.com> <01P3TC4YBNUO0000AS@mauve.mrochek.com> <52EC89D1.8050805@nostrum.com>
To: Robert Sparks <rjsparks@nostrum.com>
Cc: Ned Freed <ned.freed@mrochek.com>, draft-ietf-appsawg-sieve-duplicate@tools.ietf.org, IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Suggestions for draft-ietf-appsawg-sieve-duplicate-02
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss/>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 01 Feb 2014 06:41:07 -0000

> >> The draft calls out an example of getting effectively the same
> >> message from
> >> more than one monitoring agent, and looking at things like Subject to
> >> decide
> >> to mark some messages "seen". Such a test might well want to look at the
> >> mime
> >> parameters in Content-Type and see if any attachments are likely the
> >> same before
> >> making than seen marking. Since these came from different monitoring
> >> agents,
> >> the order of the parameters might well be very different.
> >
> > Actually, no, it would not want to do that. The point of the example
> > is to
> > avoid being showered with alerts about the same underlying event from
> > different
> > systems. In such cases the alerts will at a minimum be formatted
> > different and
> > may well have different content-types.
> >
> >> Yeah, that's nuts, and I wouldn't want to rely on it, but it seems to be
> >> what's motivating matching more than Message-ID in the first place.
> >
> > I'm afraid I find this modification to be entirely unpersuasive.

> Wow.

> I would seriously not want a message that had a pcap dump of what led to
> a serious situation marked read
> because an earlier text message from some other system provided a
> shallow text overview of what happened,
> but I wouldn't try to use this extension this way anyway.

So?  Your point appears to be that if the situation was completely different -
in particular, if these weren't simple alerts the text is clearly talking
about, but rather a mixture of alerts and messages containing problem details -
then it wouldn't make sense to handle them this way.

That's obviously true, but what it has to do with the actual example given
escapes me completely.

> Maybe that's your point - that someone that cared wouldn't write a
> script that does that.

Actually, while I didn't come up with this example, I do something very close
to it to limit the amount of useless email I get from my Sonicwall appliance.

I also note that this entirely different use-case you've constructed still
fails to provide an example where reordering parameters would be part of the
resulting script. If the presence of a certain type of attachment makes the
content critical to see, then the right thing to do is to exempt such 
messages from the test. Something like:

   require ["duplicate", "variables", "imap4flags",
     "fileinto", "mime"];

   if header :matches "subject" "ALERT: *" {
     if allof (not (header :mime :anychild :contentype :is
               "content-type" "application/vnd.pcap"),
               duplicate :seconds 60 :uniqueid "${1}" {
       setflag "\\seen";
     }
     fileinto "Alerts";
   }

Or maybe even:

   require ["duplicate", "variables", "imap4flags",
     "fileinto", "mime"];

   if header :matches "subject" "ALERT: *" {
     if header :mime :anychild :contentype :is
               "content-type" "application/vnd.pcap" {
       fileinto "Pcap-info";
     } elsif duplicate :seconds 60 :uniqueid "${1}" {
       setflag "\\seen";
     }
     fileinto "Alerts";
   }

> But I feel the current text points down that path.

What text? The example? I really have no idea where you're getting the notion
that the text is saying that everything will still be copacetic if you feed
insufficiently precise information into the test.

				Ned