From ioseb.dzmanashvili@gmail.com  Sun Jun  2 12:11:03 2013
Return-Path: <ioseb.dzmanashvili@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9038B21F91CA; Sun,  2 Jun 2013 12:11:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.401
X-Spam-Level: **
X-Spam-Status: No, score=2.401 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_22=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_91=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uxq0eC0C8-wb; Sun,  2 Jun 2013 12:11:02 -0700 (PDT)
Received: from mail-ea0-x22a.google.com (mail-ea0-x22a.google.com [IPv6:2a00:1450:4013:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id B743D21F91BF; Sun,  2 Jun 2013 12:11:01 -0700 (PDT)
Received: by mail-ea0-f170.google.com with SMTP id h10so616513eaj.1 for <multiple recipients>; Sun, 02 Jun 2013 12:11:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject:x-mailer :mime-version:content-type:content-transfer-encoding :content-disposition; bh=P1pcUbp2OEJYtxd8/oj3OfbRqFsp9XcftzJlAFRJ+nc=; b=bZcLH2W6FyLgrHrepvObZAJRGINGd9Cr8LhuHZu5XjBWzC4aQo4FDbEU0w1Lgiplqd kIeubYcR5Kc02MOBFApu0ZBlbhUDkJgSzpFUsUO5LMf5NNFJE4c+kgU8QKTzGV0M5BDe 9u2mG7lOEB13aDSRoPzG+JhyqwlifzPbs/itObw0+2vKk5QZFB1SBWXzx6uC0s0pIfwv nduFCl1XCa1p6eACzqJBZplu/a9dQlx7XvRk9xgvzyCLUFOcL8/15Y00qw4Q3P0vYj2M cevaah+Vj1SoxQ/C+k0ctB6Xom7XvSbrwjUZT4K6nLd7Wi5IXlOQYabi/3oHRLYLvdcW i3rw==
X-Received: by 10.15.90.139 with SMTP id q11mr6680929eez.137.1370200260833; Sun, 02 Jun 2013 12:11:00 -0700 (PDT)
Received: from [192.168.1.7] ([176.73.174.236]) by mx.google.com with ESMTPSA id bo9sm66067589eeb.9.2013.06.02.12.10.58 for <multiple recipients> (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 02 Jun 2013 12:10:59 -0700 (PDT)
Date: Sun, 2 Jun 2013 23:10:55 +0400
From: Ioseb Dzmanashvili <ioseb.dzmanashvili@gmail.com>
To: Markus Lanthaler <markus.lanthaler@gmx.net>
Message-ID: <3090B4B6BA1F427BB7433814C140CAAD@gmail.com>
In-Reply-To: <51a932b9.c8490f0a.4879.ffff86b3SMTPIN_ADDED_BROKEN@mx.google.com>
References: <4038B5FE76874C54A819A07FE192AEF8@gmail.com> <CABP7Rbd815stpCPLL5q9eVuxbHDW6NbGrBPdfjJbSywKFRRJ4g@mail.gmail.com> <51a53d34.48b40e0a.70fc.1549SMTPIN_ADDED_BROKEN@mx.google.com> <CABP7RbfbicAaXOpy8r3w-YVmLjM=APLDjhTohUgGnqAfkHm0dA@mail.gmail.com> <51a54dfa.086f0e0a.693f.2ff4SMTPIN_ADDED_BROKEN@mx.google.com> <FEB564CAAF9B47B8BE41F0BBE8556650@gmail.com> <51a64b5f.87000e0a.78ef.ffff87a2SMTPIN_ADDED_BROKEN@mx.google.com> <87194C5A218E42F9AA9B81339D2C1BC5@gmail.com> <51a932b9.c8490f0a.4879.ffff86b3SMTPIN_ADDED_BROKEN@mx.google.com>
X-Mailer: sparrow 1.6.4 (build 1178)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Cc: IETF Apps Discuss <apps-discuss@ietf.org>, link-relations@ietf.org
Subject: Re: [apps-discuss] NEW RELATION: property and context
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 02 Jun 2013 19:11:03 -0000

On Saturday, June 1, 2013 at 3:30 AM, Markus Lanthaler wrote:
> On Wednesday, May 29, 2013 10:08 PM, Ioseb Dzmanashvili wrote:
> > > This is right at the heart of my first question: How does the clien=
t
> > =20
> > =20
> > know to fetch /article/photo;prop1 instead of /article/photo;prop2=3F=

> > > =20
> > > There are only two options here: a) code against the target URL or =
b)
> > > code against the title attribute. Since you said b) is used exclusi=
vely
> > > for rendering purposes I assume you would code your client against =
the
> > > URL (or parts thereof) which would go against the fundamental idea =
of
> > > typed links.
> > =20
> > =20
> > =20
> > Both options are wrong.
> > =20
> > > a) code against the target URL or
> > =20
> > 1) the =22property=22 link relation is enough to indicate that target=

> > resource is a property and allow agents to distinguish these links fo=
rm
> > others;
> =20
> =20
> =20
> Yes, distinguish from other rels, but not enough to distinguish two pro=
perties as in your example:
> =20
> *** RESPONSE: Photo representation ***
> HTTP/1.1 200 OK
> Content-Type: image/jpeg
> Content-Length: ...
> Link: </article/photo;prop1>; rel=3D=22property=22; title=3D=22Property=
 1=22,
> </article/photo;prop2>; rel=3D=22property=22; title=3D=22Property 2=22,=

> =20
As I already mentioned in my previous emails, annotated links are very im=
portant in apps designed for humans too.  =20
> =20
> > 2) additional semantics can be provided with extension link relations=

> > and there is nothing wrong with it, it doesn't violate anything nor c=
an
> > be considered as anti pattern.
> =20
> =20
> Right, but the question I ask myself then is why you need the generic =22=
property=22 relation then.
=46or several reasons:

1) we do not need to redefine meaning of the =22property=22 relation from=
 application to application
2) we do not need to define meaning of the property from media type to me=
dia type
3) shared understanding of what the =22property=22 relationship is, takes=
 away needles part of redefining it each time we need it and we only need=
 to concentrate on describing particular properties which obviously are a=
pplication specific. =20
> > 3) your argument implicitly claims that there exists only M2M
> > interaction which is also wrong. there are also GUI apps for which it=
's
> > enough to just know that some of links are properties(identified by t=
he
> > =22property=22 relation)
> =20
> =20
> =20
> Hmm... it helps you to render just the property links, yes. But then th=
e user has to choose the right link based on the title attribute.
In non m2m interaction yes users choose the right links based on the labe=
l, this is what they understand but yet application logic needs at least =
basic understanding of what the link means. =20
> > 4) having a general purpose link relation makes it useful and reusabl=
e
> > from application to application, it eliminates need to redefine each
> > time what =22property=22 is and is media format agnostic. shared
> > understanding is important i believe and additional semantics for eac=
h
> > specific property is solvable on another level.
> =20
> =20
> =20
> Right, but property is so generic that I have problems seeing its value=
. This goes a bit in the direction of Jan's question. Would you think the=
 following would be a reasonable design choice:
> =20
> Link: </a/resource>; rel=3D=22link=22
> =20
> This allows your application to render all =22link=22 links but by itse=
lf doesn't add any semantics beyond the ones the Link header already has.=

> =20
yes it sound reasonable, but this is a different story, the =22property=22=
 relation doesn't mean =22render it=22 it defines specific kind of relati=
onship between resources stating that this one is a property of that one(=
or vice versa) and it doesn't mean =22here is the link and grab it and re=
nder it=22 =20
> =20
> =20
> =5B...=5D
> > > Hmm.. I do partly agree for the /article/photo -> /article link but=

> > > would argue that /article/photo;prop1 does *describe* /article/phot=
o.
> > > Similarly it could be argued that /article/photo *isDescribedBy*
> > > /article.
> > =20
> > =20
> > =20
> > Are you sure that =22describedby=22 and =22describes=22 relations giv=
e enough
> > semantics to agents=3F is not it necessary to provide some kind of
> > description=3F
> =20
> =20
> =20
> Yes, this alongside the media type of the referenced/referencing resour=
ce provides enough semantics for an agent to do something useful with it.=

Does this approach work well with =22image/jpeg=22 or =22image/png=22 or =
=22application/zip=22 media types=3F Or is it always reasonable to wrap t=
hese binary media types in another media types which describe binary reso=
urce and its properties=3F how it works with HEAD requests=3F
> > if one describes another how it is described=3F
> =20
> =20
> The media type defines that. One obvious answer is e.g. RD=46.
> =20
See my answer above. =20
> =20
> =20
> > and what it
> > gives to agent particularly in M2M interaction case=3F do automated
> > agents strangely become smart and happy when they just identify typed=

> > links annotated with those relations=3F
> =20
> =20
> =20
> No, but they do know that they can follow the link to get a description=
 which they (may) understand. You could argue that the same is true for p=
roperties/contexts but that would mean that you, e.g., would have to defi=
ne media types for all properties so that clients can express what they u=
nderstand. Just returning a string as text/plain for a title property is =
definitely not enough to enable M2M communication without having to rely =
on out-of-band information.
> =20

mmm=E2=80=A6 and who says that dereferencing the property link couldn't h=
ave information describing the property itself and still maintaining the =
=22property=22 type relationship between resources=3F
> =20
> > > So you want to express a relationship without any specific semantic=
s=3F
> > > In that case, why do you need a typed link=3F Can't you just use a
> > > untyped one=3F
> > =20
> > =20
> > =20
> > Than how GUI or automated agent will distinguish resources which are
> > properties accessible individually from for example the =22edit=22 or=

> > =22edit-form=22 links=3F or implementations are going to follow some
> > convention like: if a link doesn't have relation just display it=3F o=
r
> > ignore 'em=3F or=3F
> =20
> =20
> =20
> Displaying just links without relation would be a reasonable design cho=
ice IMO because they do not provide enough semantics to be handled automa=
tically. Thus, the choice has to be made by the (human) user which interp=
rets the link's label, i.e., the title attribute.
> =20
So would be ignoring 'em. Why should agents care about links without rela=
tions(i do not mean HTML where this kind of approach works perfectly)=3F =
=20
> =20
> =20
> > > If article would be called slideshow or gallery, would you see it
> > > then=3F :-) You could say that an article is a collection of
> > > information, some prose, some images, maybe some movies etc.
> > =20
> > =20
> > =20
> > but i didn't say =22gallery=22 or =22slideshow=22 in my example. what=
 if a
> > resource is an ID card which has only one and only one photo of a
> > person=3F do you think that ID card or driving license are collection=
s=3F
> =20
> =20
> =20
> =46irst of all, I don't understand why such a link would have to be exp=
osed on the HTTP layer. If you really want to, I think in such a specific=
 case it makes much more sense to use a URL as link relation. You probabl=
y don't even have to invent it yourself as other people did already and y=
ou profit in terms of interoperability and code reusability if you just r=
euse it. The =46OA=46 Vocabulary e.g., defines a =22depiction=22 URL whic=
h you could use. See:
> http://xmlns.com/foaf/spec/=23term=5Fdepiction
> =20

I understand your point, but it constrains me(my applications - clients a=
nd servers) to RD=46/=46OA=46 things which is not acceptable always(due t=
o different requirements). =20
> =20
> > and yes i can not say that an article is a collection, not because we=

> > can not say it generally but because what you say is overgeneralisati=
on
> > of things. we can discuss everything as a collection and item but wha=
t
> > you say makes me think that =22collection=22, =22item=22, =22describe=
s=22 and
> > =22describedby=22 link relations suddenly solved whole world problems=
.
> =20
> =20
> =20
> :-) You are putting words in my mouth. I tried to show that that =22pro=
perty=22 has extremely weak semantics - IMHO too weak.
> =20
Not that weak IMHO :-) =20
> =20
> =20
> =5B...=5D
> > > Could be any of those. If the article describe the photo you could
> > > use =22describes=22. If the article is more a collection of informa=
tion
> > > (e.g. pictures as in a gallery) you could say it is a =22collection=
=22 and
> > > the photo is an =22item=22.
> > =20
> > =20
> > =20
> > could you please point me to the example how article describes photo=3F=

> > it would be really helpful for me=21
> =20
> =20
> =20
> http://en.wikipedia.org/wiki/Vitruvian=5FMan *describes* http://upload.=
wikimedia.org/wikipedia/commons/2/22/Da=5FVinci=5FVitruve=5FLuc=5FViatour=
.jpg
> =20

Thanks=21
> =20
> > I believe i know and clearly
> > understand when i can say that an article is a collection, but does i=
t
> > make whole world a collection=3F again, is not it overgeneralisation =
and
> > oversimplification of things=3F
> =20
> =20
> =20
> No, of course not. But every link is a property of a resource and thus,=
 again IMO, =22property=22 has too weak semantics for a standardized link=
 relation.
> =20

I do not agree. One thing is that i didn't give enough description in dra=
ft and i understand confusion, second thing is that i submitted it and st=
arted discussion in hope to re-shape it's purpose more precisely. With th=
is relation i'm trying to define relationship between a property(which is=
 an individually accessible data member) and it's defining context. I'm n=
ot trying to define and convince everyone that everything is just a prope=
rty. =20
> =20
> > > Btw. On mailing lists it is typically considered as a best practice=

> > > to write text-only mails. This makes it much easier to quote etc. C=
ould
> > > you please update your client settings to send text-only mails inst=
ead
> > > of HTML formatted mails. Thanks a lot=21
> > =20
> > =20
> > =20
> > done, thanks for letting me know.
> =20
> Thanks a lot=21 This definitely makes replying much easier
> =20

np ;-) =20
> =20
> =20
> --
> Markus Lanthaler
> =40markuslanthaler


Cheers,
ioseb =20



From James.H.Manger@team.telstra.com  Mon Jun  3 08:26:03 2013
Return-Path: <James.H.Manger@team.telstra.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E581621F99C7 for <apps-discuss@ietfa.amsl.com>; Mon,  3 Jun 2013 08:26:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.301
X-Spam-Level: 
X-Spam-Status: No, score=-0.301 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_37=0.6, RELAY_IS_203=0.994]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VCGqga9TQfUR for <apps-discuss@ietfa.amsl.com>; Mon,  3 Jun 2013 08:25:57 -0700 (PDT)
Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by ietfa.amsl.com (Postfix) with ESMTP id 2EE8321F99C1 for <apps-discuss@ietf.org>; Mon,  3 Jun 2013 08:25:57 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.87,793,1363093200"; d="scan'208";a="132213997"
Received: from unknown (HELO ipccni.tcif.telstra.com.au) ([10.97.216.208]) by ipobni.tcif.telstra.com.au with ESMTP; 04 Jun 2013 01:25:56 +1000
X-IronPort-AV: E=McAfee;i="5400,1158,7094"; a="141438833"
Received: from wsmsg3705.srv.dir.telstra.com ([172.49.40.203]) by ipccni.tcif.telstra.com.au with ESMTP; 04 Jun 2013 01:25:56 +1000
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3705.srv.dir.telstra.com ([172.49.40.203]) with mapi; Tue, 4 Jun 2013 01:21:18 +1000
From: "Manger, James H" <James.H.Manger@team.telstra.com>
To: Nico Williams <nico@cryptonector.com>, Carsten Bormann <cabo@tzi.org>
Date: Tue, 4 Jun 2013 01:21:17 +1000
Thread-Topic: [apps-discuss] Concise Binary Object Representation (CBOR) -- new version -01
Thread-Index: Ac5ePk35P6Ovi2NWTy2DcNg0rvPVvQCJEyaw
Message-ID: <255B9BB34FB7D647A506DC292726F6E1151AEFE6BB@WSMSG3153V.srv.dir.telstra.com>
References: <8D8A0953-FE0D-428D-9E57-27376FA5986D@tzi.org> <CAK3OfOhm2LNTZaDWXAgM5sReUb8du-N3CO-8c2uZQrVTrSks4g@mail.gmail.com> <9FD69DDF-F8CE-4301-AC55-3176B41D244B@vpnc.org> <CAK3OfOhhrZj0HhBZjbusWThwX-0EOHXNprnXC_F6Ug=1N4kCgA@mail.gmail.com> <8DF8E01E-EB27-431A-A19A-A25926BA53AC@tzi.org> <CAK3OfOj5RVDopoke3k9VbFb4zSUupd=fbBKwmWSoFJDpOFoY5Q@mail.gmail.com>
In-Reply-To: <CAK3OfOj5RVDopoke3k9VbFb4zSUupd=fbBKwmWSoFJDpOFoY5Q@mail.gmail.com>
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, en-AU
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: Paul Hoffman <paul.hoffman@vpnc.org>, "apps-discuss@ietf.org Discuss" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) -- new version -01
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 03 Jun 2013 15:26:04 -0000

TmljbyBtYWtlcyBhbiBpbXBvcnRhbnQgcG9pbnQgYWJvdXQgYW4gaWdub3JhYmxlIHRhZyBiZWlu
ZyB1bnN1aXRhYmxlIGFzIGEgY2h1bmtpbmcgaW5kaWNhdG9yLg0KIA0KQ29uc2lkZXIgYW4gb2Jq
ZWN0IHdpdGggYSAndG8nIGZpZWxkIHRoYXQgY2FuIGhvbGQgMSBvciBtb3JlIG5hbWVzIC0tIGVp
dGhlciBhcyBhbiBhcnJheSBvZiBzdHJpbmdzLCBvciAoaWYgdGhlcmUgaXMgb25seSAxIG5hbWUp
IGFzIGEgc3RyaW5nIHdpdGhvdXQgdGhlIGFycmF5IHdyYXBwZWQuDQpFeGFtcGxlIDE6IHsgInRv
IjpbImFsaWNlIiwgImJvYiJdIH0NCkV4YW1wbGUgMjogeyAidG8iOiJqb2FubmUiIH0NCkNvbnNp
ZGVyIHRoZSBmb2xsb3dpbmcgQ0JPUiBlbmNvZGluZzoNCg0KIEExICAgICAgICAgICAgICAgICAg
IC0tIG1hcA0KICAgIDYyIDc0NkYgICAgICAgICAgIC0tICJ0byINCiAgICBDNSAgICAgICAgICAg
ICAgICAtLSB0YWc9Y2h1bmtlZA0KICAgICAgIDgyICAgICAgICAgICAgIC0tIGFycmF5DQogICAg
ICAgICAgNjIgNkE2RiAgICAgLS0gImpvIg0KICAgICAgICAgIDY0IDYxNkU2RTY1IC0tICJhbm5l
Ig0KDQpJZiB0aGUgdGFnIEM1IGlzIGlnbm9yZWQsIGFuIGFwcCB3aWxsIGRlY29kZSBhICJ0byIg
ZmllbGQgd2l0aCAyIG5hbWVzICJqbyIgYW5kICJhbm5lIi4gSWYgdGhlIHRhZyBDNSBpcyByZWNv
Z25pemVkLCBhbiBhcHAgd2lsbCBkZWNvZGUgYSAidG8iIGZpZWxkIHdpdGggMSBuYW1lICJqb2Fu
bmUiIHRoYXQganVzdCBoYXBwZW5lZCB0byBiZSBzZW50IGluIDIgY2h1bmtzLiBUaGVyZSBtdXN0
IGJlIG5vIHBvc3NpYmlsaXR5IG9mIGFuIGFwcCBjb25mdXNpbmcgdGhlc2UuDQoNCg0KV2UgY291
bGQgc3RhdGUgdGFnIEM1IE1VU1QgTk9UIGJlIGlnbm9yZWQuIFRob3VnaCB1c2luZyB0aGUgc2Ft
ZSB0YWdnaW5nIG1lY2hhbmlzbSBmb3Igb3RoZXIgdGhpbmdzIHRoYXQgYXJlIHRydWx5IG9wdGlv
bmFsIGlzIGEgYml0IG1lc3N5Lg0KDQpQZXJoYXBzIGEgY2xlYW5lciBzb2x1dGlvbiBpcyB0byB1
c2UgdGhlIGluZGVmaW5pdGUgZmxhZyAoYWRkaXRpb25hbCBpbmZvIDMxKSB3aXRoIG90aGVyIG1h
am9yIHR5cGVzLg0KQSBDQk9SIGl0ZW0gY29uc2lzdHMgb2Y6DQoqIGEgbWFqb3IgdHlwZTogUE9T
SVRJVkUgfCBORUdBVElWRSB8IEJZVEVTIHwgU1RSSU5HIHwgQVJSQVkgfCBNQVAgfCBUQUdHRUQg
fCBTSU1QTEVfT1JfRkxPQVQ7DQoqIGEgbW9kZTogMEJZVEVTIHwgMUJZVEUgfCAyQllURVMgfCA0
QllURVMgfCA4QllURVMgfCBSRVNFUlZFRDI4IHwgUkVTRVJWRUQyOSB8IFJFU0VSVkVEMzAgfA0K
SU5ERUZJTklURQ0KKiBhZGRpdGlvbmFsIGluZm8NCiogb3B0aW9uYWwgY29udGVudA0KDQpXaGVu
IG1vZGUgaXMgSU5ERUZJTklURSAoYW5kIG1ham9yIHR5cGUgaXNuJ3QgU0lNUExFX09SX0ZMT0FU
KSwgdGhlIGNvbnRlbnQgY29uc2lzdHMgb2YgYWxsIGZvbGxvd2luZyBDQk9SIGl0ZW1zIHVwIHRv
IHRoZSBzcGVjaWFsIEJSRUFLIGl0ZW0gKHdoaWNoIGlzIFNJTVBMRV9PUl9GTE9BVC9JTkRFRklO
SVRFKS4NCg0KQVJSQVkvSU5ERUZJTklURSBhbmQgTUFQL0lOREVGSU5JVEUgYXJlIGFzIGRlZmlu
ZWQgaW4gZHJhZnQgMDEuDQpCWVRFUy9JTkRFRklOSVRFIGlzIGEgYnl0ZSBhcnJheSBpbiBjaHVu
a3MuIFRoZSBmb2xsb3dpbmcgaXRlbXMgTVVTVCBiZSBCWVRFUy9ub3QtSU5ERUZJTklURS4NClNU
UklORy9JTkRFRklOSVRFIGlzIGEgc3RyaW5nIGluIGNodW5rcy4gVGhlIGZvbGxvd2luZyBpdGVt
cyBNVVNUIGJlIFNUUklORy9ub3QtSU5ERUZJTklURS4NCg0KSSB3b3VsZCBwcm9iYWJseSBnbyBm
dXJ0aGVyIGFuZCBzYXkgUE9TSVRJVkUvSU5ERUZJTklURSBjb252ZXlzIGEgYmlnbnVtLiBUaGVy
ZSBNVVNUIGJlIGV4YWN0bHkgMSBmb2xsb3dpbmcgaXRlbSB0aGF0IGlzIEJZVEVTL25vdC1JTkRF
RklOSVRFLiBTaW1pbGFybHkgTkVHQVRJVkUvSU5ERUZJTklURSBjb252ZXlzIGEgbmVnYXRpdmUg
YmlnbnVtLg0KDQpJIGRvbid0IGhhdmUgYW55IHNlbWFudGljcyB0byBhc3NpZ24gdG8gVEFHR0VE
L0lOREVGSU5JVEUsIGJ1dCBhdCBsZWFzdCBpdCBjYW4gYmUgZGVjb2RlZCBpbiB0aGUgc2FtZSB3
YXkgYXMgdGhlIG90aGVyICovSU5ERUZJTklURSBpdGVtcy4NCg0KDQpQLlMuIE9uIGNodW5rZWQg
YmlnbnVtcw0KPiA+PiBCaWdudW1zIGNhbiBnZXQgdmVyeSBiaWcuICBUaGF0J3MuLi4gdGhlaXIg
cG9pbnQgOikNCj4gPg0KPiA+IFRoaXMgaXMganVzdCBwcm9vZiBieSBsYWNrIG9mIGltYWdpbmF0
aW9uLCBidXQgSSBjYW4ndCBpbWFnaW5lDQo+IHNlcmlhbGl6aW5nIGEgYmlnbnVtIHRoZSBzaXpl
IG9mIHdoaWNoIHlvdSBkb24ndCBrbm93IGJ5IHRoZSB0aW1lIHlvdQ0KPiBzdGFydCBzZXJpYWxp
emluZyBpdC4NCj4gDQo+IEltYWdpbmUgSlNPTiBoYWQgYmlnbnVtcyAoZG9lc24ndCwgYnV0IGlt
YWdpbmUpLg0KDQpKYXZhU2NyaXB0IG1pZ2h0IG5vdCwgYnV0IEpTT04gYWN0dWFsbHkgZG9lcyBo
YXZlIGluZGVmaW5pdGUgbGVuZ3RoIGJpZ251bXMuIEEgSlNPTiBudW1iZXIgY2FuIGhhdmUgYW55
IG51bWJlciBvZiBkZWNpbWFsIGRpZ2l0cy4NCkhvd2V2ZXIsIEkgYW0gd2l0aCBDYXJ0ZW4gaGVy
ZS4gRG9u4oCZdCBhbGxvdyBjaHVua2luZyBmb3IgYmlnbnVtcywgaXQgaXMgYSBjb21wbGljYXRp
b24gdGhhdCB3ZSB3aWxsIG5ldmVyIG5lZWQuDQoNCi0tDQpKYW1lcyBNYW5nZXINCg0KPiA+IExv
b2tpbmcgYXQgdGhlIG90aGVyIHRhZ3MgdGhhdCBhY2NlcHQgc3RyaW5ncywgdGhlIDMwKyB0YWdz
IHByb2JhYmx5DQo+IGFsbCB3YW50IHRvIGFjY2VwdCBjaHVua2luZy4NCj4gPiBPZiBjb3Vyc2Us
IHdlIGNvdWxkIHJlZGVmaW5lIHRoZW0gdG8ganVzdCBhY2NlcHQgYXJyYXlzIHdpdGggY2h1bmtp
bmcNCj4gc2VtYW50aWNzLCBzYXZpbmcgYSBieXRlLg0KPiA+ICgyMSB0byAyMyBjYW4ndCBiZSBy
ZWRlZmluZWQgdGhhdCB3YXkgdW5sZXNzIHdlIGxvc2UgdGhlICJhbGwgdGhlDQo+ID4gdGhpbmdz
IGluIHRoaXMgbWFwL2FycmF5IGFyZSBiYXNlNjR1cmwiIHNlbWFudGljcy4pDQo+IA0KPiBObywg
cmVhbGx5LCBjaHVua2luZyBpcyBqdXN0IGluZGVmaW5pdGUtbGVuZ3RoIGVuY29kaW5nIGZvciBz
dHJpbmctbGlrZQ0KPiB2YWx1ZXMuICBXZSBuZWVkIGl0IGZvciB0aGUgc2FtZSByZWFzb25zIHRo
YXQgd2UgbmVlZCBpbmRlZmluaXRlLWxlbmd0aA0KPiBlbmNvZGluZyBmb3IgYXJyYXlzIGFuZCBv
YmplY3RzLg0KPiANCj4gSWYgeW91IGRpc2FncmVlLCB0aGVuIHBsZWFzZSBleHBsYWluIHRoZSBk
aXN0aW5jdGlvbiBiZXR3ZWVuIHRoZSB0d28NCj4ga2luZHMgb2YgdmFsdWVzIChzdHJpbmdzIG9u
IG9uZSBzaWRlLCBhcnJheXMvb2JqZWN0cyBvbiB0aGUgb3RoZXIpLg0KPiANCj4gPiBXaXRoIHJl
c3BlY3QgdG8gdGhlIGZpcnN0IGNsYXNzIHRoaW5nOiAgTm90aGluZyBzdG9wcyB1cyBmcm9tDQo+
IHByb2NsYWltaW5nIDB4YzUgImZpcnN0IGNsYXNzIi4NCj4gDQo+IFlvdSBtYWRlIGl0ICJ0cnVs
eSBvcHRpb25hbCIuICAoTm90IE9QVElPTkFMLCBidXQgcHJvcGVyIHVzZSBvZg0KPiBSRkMyMTE5
IHdvcmRzIGlzIGEgc2VwYXJhdGUgbml0OyBJIGFzc3VtZSB5b3UgbWVhbnQgT1BUSU9OQUwuKQ0K
PiANCj4gPiBTeW1tZXRyeSBhbHdheXMgaXMgYXBwZWFsaW5nLg0KPiA+IFRvIGFkZCBtb3JlIGFw
cGFyZW50IHN5bW1ldHJ5LCB3ZSBjYW4gYWx3YXlzIGNoYW5nZSBpdCB0byAweGRmIDotKQ0KPiAN
Cj4gSSBkb24ndCBjYXJlIGFib3V0IGFlc3RoZXRpY3MgaGVyZS4gIEkgY2FyZSBhYm91dCBoYXZp
bmcgaW5kZWZpbml0ZS0NCj4gbGVuZ3RoIGVuY29kaW5ncyBmb3IgKmFsbCogdmFsdWVzIHRoYXQg
bGFjayBhIGJvdW5kZWQgZW5jb2RlZCBzaXplLg0KPiBUaGF0J3MgYSBmb3JtIG9mIHN5bW1ldHJ5
LCBidXQgaGlnaGVyIHVwIGluIHRoZSBzdGFjay4NCj4gSSBkb24ndCBtaW5kIGNodW5raW5nIGJl
aW5nIGV4cHJlc3NlZCB3aXRoIGEgdGFnLCBhcyBsb25nIGFzIGl0J3MNCj4gUkVRVUlSRUQgYW5k
IGFzIGxvbmcgYXMgaXQncyBjbGVhciB3aGF0IG90aGVyIHRhZ3MgaXQgY2FuIGJlIG1peGVkDQo+
IHdpdGguDQo+IA0KPiAoVGhlIGZhY3QgdGhhdCBjaHVua2luZyB3YXMgbWFkZSBhIHRhZyBtYWRl
IG1lIG5lcnZvdXMgYmVjYXVzZSBpdCBtYWRlDQo+IGl0IHNlZW0gbGlrZSBhbiBhZnRlci10aG91
Z2h0LCBhbmQgSSdtIG5vdyBjb252aW5jZWQgdGhhdCdzIGp1c3Qgd2hhdA0KPiBpdCB3YXMuICBZ
b3UgbWlzdW5kZXJzdG9vZCB0aGUgcG9pbnQgb2YgY2h1bmtpbmcsIGl0J3MgYmVpbmcganVzdA0K
PiBhbm90aGVyIHdheSBvZiBzYXlpbmcgImluZGVmaW5pdGUtbGVuZ3RoIHdpdGhvdXQgZXNjYXBp
bmciLiAgSSBjYW4gc2VlDQo+IHdoeSB5b3UgdGhvdWdodCB0aGF0IG15IGNvbXBsYWludCBhcyBh
Ym91dCBsYWNrIG9mIHN5bW1ldHJ5IGluIHRoZQ0KPiBkZXRhaWxzIG9mIGVuY29kaW5nLCBidXQg
aXQgd2Fzbid0LikNCj4gDQo+IE5pY28NCg0K

From sm@resistor.net  Mon Jun  3 09:43:20 2013
Return-Path: <sm@resistor.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40FD721F964C for <apps-discuss@ietfa.amsl.com>; Mon,  3 Jun 2013 09:43:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PKoDJFgqhvgZ for <apps-discuss@ietfa.amsl.com>; Mon,  3 Jun 2013 09:43:19 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id E958921F96B1 for <apps-discuss@ietf.org>; Mon,  3 Jun 2013 09:43:16 -0700 (PDT)
Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r53Gh8jp020136; Mon, 3 Jun 2013 09:43:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1370277795; bh=eN2RfjcXRwpXMEBnPuH11MgD+xGeluzxJLoSyah6LOI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=P69AZ8oyBToxNcCYCOLkdjGULOktr56Tm1GOtS2Y4QXs0F0YqDBvD3r+iEzxnbayx REcaQ2jlmgkIq8geHwAAGcIqt9+frvlzFsTq/HHUJPpk7P28wk0gBDzHQGPaetl/Wz fu/lOppnNKe4lnM922HXO6L1TIE748WDrwLITTsI=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1370277795; i=@resistor.net; bh=eN2RfjcXRwpXMEBnPuH11MgD+xGeluzxJLoSyah6LOI=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=cgEgPZ/Nw9QvrwK98UdUxnRgCoIdIWvPPfKRErQxKrWoL48CgQ73KsJ6TIt0E4nA+ Cr6dJuyH+65f3ZCKYIVkpMq+9csaQK5QZbGIxOnyL7KX0qreyge/AFD24zRnvTBwbj lDEtsahV1t3yGFEVShs8KOnQEm8mrlLVuXiSelxw=
Message-Id: <6.2.5.6.2.20130603092459.0e4cb8e0@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Mon, 03 Jun 2013 09:32:42 -0700
To: ht@inf.ed.ac.uk (Henry S. Thompson)
From: SM <sm@resistor.net>
In-Reply-To: <f5bsj17rqzj.fsf@calexico.inf.ed.ac.uk>
References: <20130528150820.16413.98334.idtracker@ietfa.amsl.com> <f5bwqqjruux.fsf@calexico.inf.ed.ac.uk> <f5bsj17rqzj.fsf@calexico.inf.ed.ac.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-xml-mediatypes-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 03 Jun 2013 16:43:20 -0000

Hi Henry,
At 09:47 28-05-2013, Henry S. Thompson wrote:
>As promised, a quick-and-dirty-formatted Disposition of Comments is
>now available at
>
>   http://www.w3.org/XML/2012/10/3023bis/00-comments.html

I'll comment on my previous comments.

 From Section 9.12:

   "If sent using a 7-bit transport (e.g., SMTP) or an 8-bit clean transport
    (e.g., 8BITMIME ESMTP or NNTP), the XML MIME entity MUST be encoded in
     quoted-printable or base64."

The RFC 2119 requirement are in several places (if I recall 
correctly) in the draft.  I suggest having the requirement in one place.

I'll read the new revision of the draft and comment (re. overall comment).

Regards,
-sm 


From nico@cryptonector.com  Mon Jun  3 13:56:40 2013
Return-Path: <nico@cryptonector.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D538D21F96B1 for <apps-discuss@ietfa.amsl.com>; Mon,  3 Jun 2013 13:56:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.544
X-Spam-Level: 
X-Spam-Status: No, score=-1.544 tagged_above=-999 required=5 tests=[AWL=0.433,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJJb-7YQwRkQ for <apps-discuss@ietfa.amsl.com>; Mon,  3 Jun 2013 13:56:25 -0700 (PDT)
Received: from homiemail-a35.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 3653011E811A for <apps-discuss@ietf.org>; Mon,  3 Jun 2013 13:49:45 -0700 (PDT)
Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id DB00E54095 for <apps-discuss@ietf.org>; Mon,  3 Jun 2013 13:49:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=mtsTkiWfRq/G0YYtCme+M1M8pM8=; b=OxkfVrqrYKa FRDrxUOxYNymCwgBN9InwoHGizzcqgejOzbfQ7CdG8mZHHqRWlAOYMq/5chv/OuA +npIXlDSJwiV3XgNuBDnLGfk1fPOYFpfc8pwmPs/eH5EHwJNYyeIH4xGtFaPuPiw sK09eqEpJmv0iJJvhvr6UrIrKowx45Hs=
Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTPSA id 68B805409D for <apps-discuss@ietf.org>; Mon,  3 Jun 2013 13:49:22 -0700 (PDT)
Received: by mail-wg0-f51.google.com with SMTP id b13so3675828wgh.30 for <apps-discuss@ietf.org>; Mon, 03 Jun 2013 13:49:21 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=vByHinW7SQEdS0UV7cgUfnDjvKbUbVqrfUH6eMbCLac=; b=JXsPdJzsulXbVt2tTxZFJ3p8BROj7Jwt0VIVkJuxiDEpJDaZa0Iea7kEwMq9sVXhTt 5XoBafj+CwVwXimGgrjD0P49X/dA3gkcR3B6z4wKYsIMLb08Mry1sB+mfPccV3WEO++K io6zt3FOBdBbM8ynfXxgx606DrcrUkUsOgghamm8SaSiupaUWlkDdchk4aquZ0duu6+A NidhYTqhkTTho0RUXW6QCYbqRj5ut6eg1jBiRTeSjD/a1qYYaUyRhHWBBN4CzpqSIZIh Ux7ezrJnbtpIy6AUYyi+raP7yBJz2Ivv4o93fdwgJJ30JT8olefrn2DJ3uqJJX+mkIMg q4pg==
MIME-Version: 1.0
X-Received: by 10.180.183.139 with SMTP id em11mr14443864wic.16.1370292561026;  Mon, 03 Jun 2013 13:49:21 -0700 (PDT)
Received: by 10.216.63.136 with HTTP; Mon, 3 Jun 2013 13:49:20 -0700 (PDT)
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1151AEFE6BB@WSMSG3153V.srv.dir.telstra.com>
References: <8D8A0953-FE0D-428D-9E57-27376FA5986D@tzi.org> <CAK3OfOhm2LNTZaDWXAgM5sReUb8du-N3CO-8c2uZQrVTrSks4g@mail.gmail.com> <9FD69DDF-F8CE-4301-AC55-3176B41D244B@vpnc.org> <CAK3OfOhhrZj0HhBZjbusWThwX-0EOHXNprnXC_F6Ug=1N4kCgA@mail.gmail.com> <8DF8E01E-EB27-431A-A19A-A25926BA53AC@tzi.org> <CAK3OfOj5RVDopoke3k9VbFb4zSUupd=fbBKwmWSoFJDpOFoY5Q@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E1151AEFE6BB@WSMSG3153V.srv.dir.telstra.com>
Date: Mon, 3 Jun 2013 15:49:20 -0500
Message-ID: <CAK3OfOgPGi4PKxKAGEG=PCv-xaszMqWpUUUH2B9f0UaeMMO1gQ@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: "Manger, James H" <James.H.Manger@team.telstra.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Paul Hoffman <paul.hoffman@vpnc.org>, "apps-discuss@ietf.org Discuss" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) -- new version -01
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 03 Jun 2013 20:56:40 -0000

On Mon, Jun 3, 2013 at 10:21 AM, Manger, James H
<James.H.Manger@team.telstra.com> wrote:
> Consider an object with a 'to' field that can hold 1 or more names -- eit=
her as an array of strings, or (if there is only 1 name) as a string withou=
t the array wrapped.

I think the principle is sufficient, but what a great example!

> If the tag C5 is ignored, an app will decode a "to" field with 2 names "j=
o" and "anne". If the tag C5 is recognized, an app will decode a "to" field=
 with 1 name "joanne" that just happened to be sent in 2 chunks. There must=
 be no possibility of an app confusing these.

Right.  I think it's fine to drop some unsupported tags on decoding
like the tag that says some value is a date, because the consumer has
no way to express that.  But all consumers can be expected to be able
to express strings and arrays, so that excuse wouldn't work for
strings.

> We could state tag C5 MUST NOT be ignored. Though using the same tagging =
mechanism for other things that are truly optional is a bit messy.

I would live with that.  I would prefer that the indefinite-length
encoding choice were encoded in the same place as definitely length
encoding.  It seems cleaner that way.  But this is a bit subjective.
What's objective is the need for indefinite length encoding at least
for all types that JSON does the same for.

> Perhaps a cleaner solution is to use the indefinite flag (additional info=
 31) with other major types.
> A CBOR item consists of:

Or use some of the currently unallocated values from type 7's
supplementary bits.

> P.S. On chunked bignums
>>
>> Imagine JSON had bignums (doesn't, but imagine).
>
> JavaScript might not, but JSON actually does have indefinite length bignu=
ms. A JSON number can have any number of decimal digits.

Yeah, but it is constrained to IEEE 754 64-bit floating point values, no?

> However, I am with Carten here. Don=E2=80=99t allow chunking for bignums,=
 it is a complication that we will never need.

But in CBOR bignums devolve into byte strings, so if chunking (really,
escape-less indefinite-length encoding of strings) is in the core, and
required, then there's no need to think about whether chunked bignums
are allowed: it falls out that they are, and at no extra
implementation cost.  Even if it were otherwise I think I'd still
stand on the principle that all unbounded-size values must have an
indefinite-length encoding, though I concede that the "chunking
bignums, meh" sentiment does come up.  But if "chunked bignums" falls
out of having chunked byte strings, well, hey, why complain?

Nico
--

From hallam@gmail.com  Mon Jun  3 14:11:18 2013
Return-Path: <hallam@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A9F121E80AD for <apps-discuss@ietfa.amsl.com>; Mon,  3 Jun 2013 14:11:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nCSuIjv1NWWD for <apps-discuss@ietfa.amsl.com>; Mon,  3 Jun 2013 14:11:08 -0700 (PDT)
Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 9D51F21E80BF for <apps-discuss@ietf.org>; Mon,  3 Jun 2013 14:05:51 -0700 (PDT)
Received: by mail-wg0-f43.google.com with SMTP id x12so3690010wgg.22 for <apps-discuss@ietf.org>; Mon, 03 Jun 2013 14:05:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AR5xoUP2I/+JM1jzFD/p9HU7hzSVLiQWshKC8jceErc=; b=V+0pvIWoF+Cq2Q4Ck6yZ9yGVk0qZmHES/177UO1qmVjJMJTQT4TcD3JTLEH0nDotoA un96UnVUuYVMZ5GExzRIiskbYyawifpAAT4UK0Rtf8DuXuXhEQnbpwAJpfHINTqmkdaM /dnS+hD7Xt6XApeI2S1bk0klqTjAWLJOOX1FaxizyTbcwTtbMpecmF78fxutsYD7KReV bjyUIo3yUYF2ODQ5rU4ESgOHsb31MnNd83BLPyFURp5qsRr4WEGWDziXJPohA9vnmaDo Zd8hXMUkcBU3gOde5JJppG5moVyBSA99Jx2P/icBxGhS+B+I9kaSfr5XdBubGFKXYc9M 9zpg==
MIME-Version: 1.0
X-Received: by 10.194.158.194 with SMTP id ww2mr20970954wjb.3.1370293550229; Mon, 03 Jun 2013 14:05:50 -0700 (PDT)
Received: by 10.194.60.195 with HTTP; Mon, 3 Jun 2013 14:05:50 -0700 (PDT)
In-Reply-To: <CAK3OfOgPGi4PKxKAGEG=PCv-xaszMqWpUUUH2B9f0UaeMMO1gQ@mail.gmail.com>
References: <8D8A0953-FE0D-428D-9E57-27376FA5986D@tzi.org> <CAK3OfOhm2LNTZaDWXAgM5sReUb8du-N3CO-8c2uZQrVTrSks4g@mail.gmail.com> <9FD69DDF-F8CE-4301-AC55-3176B41D244B@vpnc.org> <CAK3OfOhhrZj0HhBZjbusWThwX-0EOHXNprnXC_F6Ug=1N4kCgA@mail.gmail.com> <8DF8E01E-EB27-431A-A19A-A25926BA53AC@tzi.org> <CAK3OfOj5RVDopoke3k9VbFb4zSUupd=fbBKwmWSoFJDpOFoY5Q@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E1151AEFE6BB@WSMSG3153V.srv.dir.telstra.com> <CAK3OfOgPGi4PKxKAGEG=PCv-xaszMqWpUUUH2B9f0UaeMMO1gQ@mail.gmail.com>
Date: Mon, 3 Jun 2013 17:05:50 -0400
Message-ID: <CAMm+Lwhvy_LtSmErPohZQLYd2a3A0N7Ksfs=O98SsAwj_PsdXw@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Nico Williams <nico@cryptonector.com>
Content-Type: multipart/alternative; boundary=089e013c64de4cafba04de465428
Cc: Paul Hoffman <paul.hoffman@vpnc.org>, "apps-discuss@ietf.org Discuss" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) -- new version -01
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 03 Jun 2013 21:11:18 -0000

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

I can't see any case where chunked bignums was a requirement and even if
there was such a case it would be easy enough to convert them to binary
blobs.

This is what is done in XML Signature today, there is a number type but the
spec actually uses Base64 encoding.

An easy way to avoid this being an issue would be to limit the length field
of a bignum to 16 bits. That way you have a guarantee that an intermediate
processor with a fixed size buffer can always transcode to JSON. 64Kb is a
pretty reasonable size to expect applications would support.

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

<div dir=3D"ltr">I can&#39;t see any case where chunked bignums was a requi=
rement and even if there was such a case it would be easy enough to convert=
 them to binary blobs.=A0<div><br></div><div style>This is what is done in =
XML Signature today, there is a number type but the spec actually uses Base=
64 encoding.</div>
<div style><br></div><div style>An easy way to avoid this being an issue wo=
uld be to limit the length field of a bignum to 16 bits. That way you have =
a guarantee that an intermediate processor with a fixed size buffer can alw=
ays transcode to JSON. 64Kb is a pretty reasonable size to expect applicati=
ons would support.</div>
</div>

--089e013c64de4cafba04de465428--

From nico@cryptonector.com  Mon Jun  3 14:21:01 2013
Return-Path: <nico@cryptonector.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDB9F11E80F6 for <apps-discuss@ietfa.amsl.com>; Mon,  3 Jun 2013 14:21:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.81
X-Spam-Level: 
X-Spam-Status: No, score=-1.81 tagged_above=-999 required=5 tests=[AWL=0.167,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZODzp9MRfNvl for <apps-discuss@ietfa.amsl.com>; Mon,  3 Jun 2013 14:20:46 -0700 (PDT)
Received: from homiemail-a31.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 409CF21F84D9 for <apps-discuss@ietf.org>; Mon,  3 Jun 2013 14:15:18 -0700 (PDT)
Received: from homiemail-a31.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTP id 78A8120204B for <apps-discuss@ietf.org>; Mon,  3 Jun 2013 14:15:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=ZVqwB9PrS+mlnrXWWMxD wwiT+UU=; b=AenhCGwLjjKjSTWsAPSOBp3u5drValqcDuCIJPufy8B5qhroMyXR +/PP8tcMsYMCnrJKRVA+It+RK/xkiAj2n0XJpL770ZcOA7T/Abrb8a9V7x1Heeq+ gXGJRQUsJweL9+XDO7J3LG5b07dWr35qnIbhq+bXJU7CM7liH+2nJKo=
Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTPSA id 16626202046 for <apps-discuss@ietf.org>; Mon,  3 Jun 2013 14:15:14 -0700 (PDT)
Received: by mail-wi0-f170.google.com with SMTP id hr14so3252127wib.3 for <apps-discuss@ietf.org>; Mon, 03 Jun 2013 14:15:13 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dFD54gu38i4Fy+1veivzJjhXwULkbYvpnxQqlXtLOHI=; b=EADGg91pc8u7NgW3F2FyWss0fD0YVb2gY9xb2fKEQU2jr5HScunPf+8xR8H0ABVP0h r55zkoAiv1FFbMxEzOo4ZVEktyWtijPi9WT+oKJtfuuevP2LnuibGJ14B9v4992olEDP SNuYqDLVhLh3Rzd/+nTAlDnky11+cn+7rmZOXzZGBXEHatUTACM6T4DqE26g+GxRm7Y5 K3GOlRQYwbGlwuoQex4KeYbisup97OUGlm4KFY+cvGPlTDgSmKbAHtGAtcAKiC9NeEO1 myFQSE6qzwwlnZLH8SfiecPX38XsKgkGePllUDSCQFZj5+II3h52u19AwhdwzLklJsWl fnoQ==
MIME-Version: 1.0
X-Received: by 10.194.77.66 with SMTP id q2mr20872823wjw.34.1370294113905; Mon, 03 Jun 2013 14:15:13 -0700 (PDT)
Received: by 10.216.63.136 with HTTP; Mon, 3 Jun 2013 14:15:13 -0700 (PDT)
In-Reply-To: <CAMm+Lwhvy_LtSmErPohZQLYd2a3A0N7Ksfs=O98SsAwj_PsdXw@mail.gmail.com>
References: <8D8A0953-FE0D-428D-9E57-27376FA5986D@tzi.org> <CAK3OfOhm2LNTZaDWXAgM5sReUb8du-N3CO-8c2uZQrVTrSks4g@mail.gmail.com> <9FD69DDF-F8CE-4301-AC55-3176B41D244B@vpnc.org> <CAK3OfOhhrZj0HhBZjbusWThwX-0EOHXNprnXC_F6Ug=1N4kCgA@mail.gmail.com> <8DF8E01E-EB27-431A-A19A-A25926BA53AC@tzi.org> <CAK3OfOj5RVDopoke3k9VbFb4zSUupd=fbBKwmWSoFJDpOFoY5Q@mail.gmail.com> <255B9BB34FB7D647A506DC292726F6E1151AEFE6BB@WSMSG3153V.srv.dir.telstra.com> <CAK3OfOgPGi4PKxKAGEG=PCv-xaszMqWpUUUH2B9f0UaeMMO1gQ@mail.gmail.com> <CAMm+Lwhvy_LtSmErPohZQLYd2a3A0N7Ksfs=O98SsAwj_PsdXw@mail.gmail.com>
Date: Mon, 3 Jun 2013 16:15:13 -0500
Message-ID: <CAK3OfOgQmGmOvd3ohCLcWV6CN124r8OQqzA5Erqtx_8yS49-ZQ@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Phillip Hallam-Baker <hallam@gmail.com>
Content-Type: text/plain; charset=UTF-8
Cc: Paul Hoffman <paul.hoffman@vpnc.org>, "apps-discuss@ietf.org Discuss" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Concise Binary Object Representation (CBOR) -- new version -01
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 03 Jun 2013 21:21:01 -0000

On Mon, Jun 3, 2013 at 4:05 PM, Phillip Hallam-Baker <hallam@gmail.com> wrote:
> I can't see any case where chunked bignums was a requirement and even if
> there was such a case it would be easy enough to convert them to binary
> blobs.

Who's to say that some mathematician doesn't need to encode truly
gargantuan (from our puny perspective) numbers.  Still, I too feel
unenthused about chunked bignums.

What interests me is that if bignums are byte strings (in CBOR as
proposed they are) and there's a chunked byte string encoding, then
chunked bignums are supported and there's no need to think about it or
write a line of extra code to make that feasible.  (If a codec has a
native bignum type that would require conversion to byte string first
then it might be difficult to stream bignums without having to have
arbitrarily large buffers, but we can't cater to every possible native
bignum representation.)

> An easy way to avoid this being an issue would be to limit the length field
> of a bignum to 16 bits. That way you have a guarantee that an intermediate
> processor with a fixed size buffer can always transcode to JSON. 64Kb is a
> pretty reasonable size to expect applications would support.

I would feel more comfortable eliding the whole problem by saying that
since bignums are encoded as byte strings they can be chunked like any
other byte string.  Since the chunking happens one layer lower, it
just works and who cares.  16-bit bignums will definitely feel small
for math apps.

Nico
--

From ullner@gmail.com  Mon Jun  3 12:30:00 2013
Return-Path: <ullner@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75E6C21E80B3; Mon,  3 Jun 2013 12:30:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IAX4L8hGizOg; Mon,  3 Jun 2013 12:29:50 -0700 (PDT)
Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id C5AD421E80A5; Mon,  3 Jun 2013 12:23:09 -0700 (PDT)
Received: by mail-ie0-f180.google.com with SMTP id b11so11783943iee.11 for <multiple recipients>; Mon, 03 Jun 2013 12:23:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lUH6L0u2bM/hlkGr9M6ix7jg5uTnM7wgsNtEte0SFvg=; b=gBYInMsjkwiTjRyQkssflIoZ1HmShLdHDRy03QydoOGFGU9CzESwg/IoBDJkhhTz2G 8Veqcn7JbLYZ83TZHAEwkJzK9TkZVt40DmZoWS3ADwcLtbH42Mf3hCO8GdyU54IEYCWk v09kjCS7reUZxq/kgGVaO/fOTS9BrksbdhcuVIdNlsHwUb6lTPidMjsRiHhPNx26yNDB MDT8iTMkm9hO8bO+yqxhhERDLYlSF/auvMNjBGnSc2z2to9eaVKD1VyeIr2cQ+tZejgl OVGyn/47j6Ap7unHBKfmM7UaSveCmLYxbeur9AdjwPvDRkIgA+9IX8uyYQQUaVZqb0QN UJMA==
MIME-Version: 1.0
X-Received: by 10.50.153.47 with SMTP id vd15mr9111621igb.92.1370287389313; Mon, 03 Jun 2013 12:23:09 -0700 (PDT)
Received: by 10.42.171.2 with HTTP; Mon, 3 Jun 2013 12:23:09 -0700 (PDT)
In-Reply-To: <513E26F5.9080207@tibco.com>
References: <CAOd=0fOPCgEwPWxOm3QDn=QKe8Rb8RmShn5sEL3iBS_z6aOUXg@mail.gmail.com> <512663B2.20809@tibco.com> <CAOd=0fPuFsoTCh0mcYt_vVi-=Y5Or4oNQT+BYpKZv1zop0vdHA@mail.gmail.com> <51278B10.10200@ninebynine.org> <CAOd=0fMyEVHgQnzZpoH3wXws+T30V5O82u13nFwA+A=4FwQbnQ@mail.gmail.com> <513CAD82.409@ninebynine.org> <513E26F5.9080207@tibco.com>
Date: Mon, 3 Jun 2013 21:23:09 +0200
Message-ID: <CAOd=0fNA3OFG0_AH1ga8auUUrs7PbxGq1srGxZiox1NWGwO8eg@mail.gmail.com>
From: Fredrik Ullner <ullner@gmail.com>
To: Eric Johnson <eric@tibco.com>
Content-Type: multipart/alternative; boundary=089e0149532c1494cd04de44e5a0
X-Mailman-Approved-At: Tue, 04 Jun 2013 08:48:45 -0700
Cc: uri-review@ietf.org, Graham Klyne <GK@ninebynine.org>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] [Uri-review] URI scheme registration request - dchub
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 03 Jun 2013 19:30:00 -0000

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

Hi,

There is now a new version of the dchub URI scheme proposal at <
http://nmdc.sourceforge.net/Versions/nmdc-uri-scheme-0.3.txt>. There are a
couple of changes:

* It was decided to drop the secure dchub URI (nmdcs) inclusion. While this
is an URI that is used, it was felt that it is better to have that as a
separate URI scheme proposal. (The reason for the naming was simply that
the person who wrote it in the first place, wrote it as such.)
* Scheme syntax is very slightly changed to allow a forward slash after
user (as it is allowed elsewhere, too).
* Semantics is heavily revised, taking into account suggested changes from
you as well as from multiple developers of the Direct Connect network (i.e.
implementators).
* Encoding slightly revised, primarily for normalization. A question came
up: should the 'normalization' be changed to 'canonicalization'?
* Applications/protocol slightly revised, specifying more implementations.
Perhaps it is otherwise better to create a reference on a NMDC project page
and reference that in the URI scheme? Or perhaps reference Wikipedia?
* Minor wording in other sections to clarify use or intent.

The document, as is, is also commited to the SourceForge SVN. Note that
SourceForge decided to change repositories, so you would need to do a diff
on your own if you desire to see the exact changes.


-- 
Fredrik Ullner

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

<div dir=3D"ltr">Hi,<div><br></div><div style>There is now a new version of=
 the dchub URI scheme proposal at &lt;<a href=3D"http://nmdc.sourceforge.ne=
t/Versions/nmdc-uri-scheme-0.3.txt">http://nmdc.sourceforge.net/Versions/nm=
dc-uri-scheme-0.3.txt</a>&gt;. There are a couple of changes:</div>
<div style><br></div><div style>* It was decided to drop the secure dchub U=
RI (nmdcs) inclusion. While this is an URI that is used, it was felt that i=
t is better to have that as a separate URI scheme proposal. (The reason for=
 the naming was simply that the person who wrote it in the first place, wro=
te it as such.)</div>
<div style>* Scheme syntax is very slightly changed to allow a forward slas=
h after user (as it is allowed elsewhere, too).</div><div style>* Semantics=
 is heavily revised, taking into account suggested changes from you as well=
 as from multiple developers of the Direct Connect network (i.e. implementa=
tors).</div>
<div style>* Encoding slightly revised, primarily for normalization. A ques=
tion came up: should the &#39;normalization&#39; be changed to &#39;canonic=
alization&#39;?</div><div style>* Applications/protocol slightly revised, s=
pecifying more implementations. Perhaps it is otherwise better to create a =
reference on a NMDC project page and reference that in the URI scheme? Or p=
erhaps reference Wikipedia?</div>
<div style>* Minor wording in other sections to clarify use or intent.=A0</=
div><div style><br></div><div class=3D"gmail_extra"><div style>The document=
, as is, is also commited to the SourceForge SVN. Note that SourceForge dec=
ided to change repositories, so you would need to do a diff on your own if =
you desire to see the exact changes.</div>
<div><br></div><div><br></div>-- <br>Fredrik Ullner
</div></div>

--089e0149532c1494cd04de44e5a0--

From stpeter@stpeter.im  Tue Jun  4 16:29:33 2013
Return-Path: <stpeter@stpeter.im>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2163D21F99F0; Tue,  4 Jun 2013 16:29:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xvMJpDWRsl0p; Tue,  4 Jun 2013 16:29:28 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 5D5C121F992A; Tue,  4 Jun 2013 16:29:25 -0700 (PDT)
Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0B90741240; Tue,  4 Jun 2013 17:42:13 -0600 (MDT)
Message-ID: <51AE783F.5060204@stpeter.im>
Date: Tue, 04 Jun 2013 17:29:03 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: saag@ietf.org, "apps-discuss@ietf.org" <apps-discuss@ietf.org>
References: <51AE771F.6080005@stpeter.im>
In-Reply-To: <51AE771F.6080005@stpeter.im>
X-Enigmail-Version: 1.5.1
X-Forwarded-Message-Id: <51AE771F.6080005@stpeter.im>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: [apps-discuss] Fwd: [POSH] PKIX Over Secure HTTP (POSH)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 04 Jun 2013 23:29:33 -0000

FYI.


-------- Original Message --------
Subject: [POSH] PKIX Over Secure HTTP (POSH)
Date: Tue, 04 Jun 2013 17:24:15 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
To: posh@ietf.org

Matt Miller and I have been working on a specification for "PKIX Over
Secure HTTP" (POSH), which aims to make it easier to ensure proper TLS
server identity checking in multi-tenanted environments (where it's
basically impossible right now):

https://datatracker.ietf.org/doc/draft-miller-posh/

As the abstract says:

   This document defines two methods that make it easier to deploy
   certificates for proper server identity checking in application
   protocols.  The first method enables a TLS client to obtain a TLS
   server's end-entity certificate over secure HTTP as an alternative to
   standard Public Key Infrastructure using X.509 (PKIX) and DNS-Based
   Authentication of Named Entities (DANE).  The second method enables a
   source domain to securely delegate an application to a derived domain
   using HTTPS redirects.

We love PKIX (really!), we love DNSSEC, and we love DANE (which solves
some of the same problems for some application protocols as POSH
does). However, we want a technology that can be deployed more quickly
than DANE in order to solve pressing operational security issues with
standard PKIX in multi-tenanted environments.

This effort emerged from the XMPP community, but we have heard from
folks working on other application technologies that it might be
useful for things like IMAP and SMTP, thus the more generalized
version of POSH that we published today (superseding
draft-miller-xmpp-posh-prooftype).

We are planning to hold a BoF on this topic in Berlin, but in the
meantime comments are very much welcome. Please post your feedback to
the new posh@ietf.org list:

https://www.ietf.org/mailman/listinfo/posh

Thanks!

Peter

_______________________________________________
posh mailing list
posh@ietf.org
https://www.ietf.org/mailman/listinfo/posh



From internet-drafts@ietf.org  Wed Jun  5 00:34:12 2013
Return-Path: <internet-drafts@ietf.org>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E61321F9A4E; Wed,  5 Jun 2013 00:34:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.413
X-Spam-Level: 
X-Spam-Status: No, score=-102.413 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t1DYjNKiYqL7; Wed,  5 Jun 2013 00:34:11 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AC5C21F9A52; Wed,  5 Jun 2013 00:34:11 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.50
Message-ID: <20130605073411.25330.72960.idtracker@ietfa.amsl.com>
Date: Wed, 05 Jun 2013 00:34:11 -0700
Cc: apps-discuss@ietf.org
Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc5451bis-06.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 05 Jun 2013 07:34:12 -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           : Message Header Field for Indicating Message Authenticati=
on Status
	Author(s)       : Murray S. Kucherawy
	Filename        : draft-ietf-appsawg-rfc5451bis-06.txt
	Pages           : 42
	Date            : 2013-06-05

Abstract:
   This document specifies a header field for use with electronic mail
   messages to indicate the results of message authentication efforts.
   Any receiver-side software, such as mail filters or Mail User Agents
   (MUAs), can use this header field to relay that information in a
   convenient and meaningful way to users, or make sorting and filtering
   decisions.

   This document is a candidate for Internet Standard status.  [RFC
   Editor: Please delete this notation, as I imagine it will be
   indicated some other way.]


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-appsawg-rfc5451bis

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-appsawg-rfc5451bis-06

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-rfc5451bis-06


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From internet-drafts@ietf.org  Wed Jun  5 00:34:12 2013
Return-Path: <internet-drafts@ietf.org>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94FE721F9A52 for <apps-discuss@ietfa.amsl.com>; Wed,  5 Jun 2013 00:34:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.305
X-Spam-Level: 
X-Spam-Status: No, score=-101.305 tagged_above=-999 required=5 tests=[AWL=-0.924, BAYES_00=-2.599, NO_RELAYS=-0.001, TVD_SPACE_RATIO=2.219, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id twTy+2Zpg17z; Wed,  5 Jun 2013 00:34:12 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A9EC321F9A59; Wed,  5 Jun 2013 00:34:11 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-rfc5451bis@tools.ietf.org, apps-discuss@ietf.org, barryleiba@computer.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.50
Message-ID: <20130605073411.25330.98991.idtracker@ietfa.amsl.com>
Date: Wed, 05 Jun 2013 00:34:11 -0700
Subject: [apps-discuss] New Version Notification - draft-ietf-appsawg-rfc5451bis-06.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 05 Jun 2013 07:34:12 -0000

A new version (-06) has been submitted for draft-ietf-appsawg-rfc5451bis:
http://www.ietf.org/internet-drafts/draft-ietf-appsawg-rfc5451bis-06.txt


The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-appsawg-rfc5451bis/

Diff from previous version:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-rfc5451bis-06

IETF Secretariat.


From dcrocker@bbiw.net  Wed Jun  5 04:41:17 2013
Return-Path: <dcrocker@bbiw.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3498321F8793 for <apps-discuss@ietfa.amsl.com>; Wed,  5 Jun 2013 04:41:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MSFYD1f5upZQ for <apps-discuss@ietfa.amsl.com>; Wed,  5 Jun 2013 04:41:12 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id D01FD21F86D5 for <apps-discuss@ietf.org>; Wed,  5 Jun 2013 04:41:12 -0700 (PDT)
Received: from [172.16.16.101] (62-50-200-178.client.stsn.net [62.50.200.178]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r55Bf69G003823 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 5 Jun 2013 04:41:11 -0700
Message-ID: <51AF23CD.7030300@bbiw.net>
Date: Wed, 05 Jun 2013 13:41:01 +0200
From: Dave Crocker <dcrocker@bbiw.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: draft-ietf-appsawg-rfc5451bis.all@tools.ietf.org, Apps Discuss <apps-discuss@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.67]); Wed, 05 Jun 2013 04:41:11 -0700 (PDT)
Subject: [apps-discuss] Review of: draft-ietf-appsawg-rfc5451bis
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 05 Jun 2013 11:41:17 -0000

Howdy.

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.



Title:  Message Header Field for Indicating Message
         Authentication Status
I-D:      draft-ietf-appsawg-rfc5451bis-06

By:     D. Crocker <dcrocker@bbiw.net>
Date:   5 June 20113


Summary:

    It is common for an enterprise to distribute the security functions 
of its email service, as well distributing the transfer mechanisms.  The 
most common example is to have some message assessment -- such as 
determining the identity of the client SMTP server that sent the message 
over the public net to the enterprise's border host.  This often creates 
a need to communicate output of the border host's processing to machines 
later receiving the message within the enterprise.  The current draft 
specifies modification of a header field-based mechanism for 
communicating 'authentication' information about the message.

    An initial version of this review was provided for the previous 
version of the draft and sent to the author.  The current version of the 
document reflects many changes that derived from that review.

    The current draft is usable in its current form.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

From mikeadouglass@gmail.com  Thu Jun  6 12:27:10 2013
Return-Path: <mikeadouglass@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FE6D21F8BC0 for <apps-discuss@ietfa.amsl.com>; Thu,  6 Jun 2013 12:27:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7s5ncaoEDVgH for <apps-discuss@ietfa.amsl.com>; Thu,  6 Jun 2013 12:27:09 -0700 (PDT)
Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 7F45921F8B35 for <apps-discuss@ietf.org>; Thu,  6 Jun 2013 12:27:09 -0700 (PDT)
Received: by mail-ie0-f170.google.com with SMTP id e14so8376469iej.1 for <apps-discuss@ietf.org>; Thu, 06 Jun 2013 12:27:09 -0700 (PDT)
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=qK9g040Cw7kH5pHV32uMPhI+a2nFl3v3hh2HJzMLdMo=; b=Mur3qAFN912mrIPapgq3DaWpzZDRpou6w6vIr/DRcfx5CID8wDnEF2kyEjCTMWljPy +mPrpJbd3ThpL6eiFEudyclQRZ+cjUxm6HDs+IUxPakDhkYKnG/Hwt+SpYG3XRmnbfdS hDB86bstLpjcJsGeOEJ5eGXDWkiq6Ib+HnjMuhDNsAlzY8N2+zIl0LDX67CIMdpLkWtp drKmHSBGjqytqBevfkocIySXEYHa4imjTq5vAxAZqJiFqT0PVw45tWTfPpEJy4j0n4ma B+p5Kk6gIB99LLDiSKexPzgHkewK5Sjxq5FqCbqkwieKtyZMNcwjhdkMSnNd9OfM71xc uy4A==
X-Received: by 10.50.1.70 with SMTP id 6mr6267151igk.54.1370546829139; Thu, 06 Jun 2013 12:27:09 -0700 (PDT)
Received: from [72.33.184.209] (dyn-72-33-184-209.uwnet.wisc.edu. [72.33.184.209]) by mx.google.com with ESMTPSA id d7sm12742552igx.5.2013.06.06.12.27.07 for <apps-discuss@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Jun 2013 12:27:08 -0700 (PDT)
Message-ID: <51B0E28A.4090308@gmail.com>
Date: Thu, 06 Jun 2013 15:27:06 -0400
From: Mike Douglass <mikeadouglass@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130404 Thunderbird/17.0.5
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <32031_1369751656_r4SEYFTw020097_4F5FFFB33B6673887C6A5ADF@cyrus.local> <51A4C62E.9000201@andrew.cmu.edu>
In-Reply-To: <51A4C62E.9000201@andrew.cmu.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [apps-discuss] Request for adoption of iSchedule as a WG work item
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 06 Jun 2013 19:27:10 -0000

I am also in favor of appsawg adopting this draft. I am happy to help 
work on it.

On 05/28/2013 10:58 AM, Ken Murchison wrote:
> On 5/28/2013 10:34 AM, Cyrus Daboo wrote:
>> Hi folks,
>> After consultation with Apps Area ADs and Apps Area WG chairs I would 
>> like to request that the Apps Area WG adopt iSchedule 
>> (<https://datatracker.ietf.org/doc/draft-desruisseaux-ischedule/>) as 
>> a working group item.
>>
>> iSchedule is a cross-domain calendaring and scheduling protocol based 
>> on iCalendar (RFC5545), iTIP (RFC5546) and HTTP. The goal is to allow 
>> efficient, secure and timely exchange of scheduling messages between 
>> servers.
>>
>> The calendaring aspects of this protocol are pretty straightforward. 
>> The hard part is security - in effect what we have is a messaging 
>> protocol akin to email and what we want to avoid are all the problems 
>> inherent in email (spoofing, spam etc). To that end we have adapted 
>> DKIM (RFC6376) for use within our protocol (with the primary goal of 
>> solving only the issues we need for iSchedule as opposed to 
>> developing a generic solution for signing HTTP messages).
>>
>> iSchedule originated with work done at the Calendaring and Scheduling 
>> Consortium (CalConnect) and has been developed over the last several 
>> years via IETF drafts. There are already a number of prototype 
>> implementations and CalConnect has been holding regular interop 
>> events to test those and weed out issues with the spec.
>>
>> At this point we want to move forward with the draft with more 
>> rigorous review, specifically of the security piece, and ultimately 
>> move forward with publication as a proposed standard.
>>
>> So this is a call to see who in this WG would be willing to work on 
>> this document, and whether the WG should adopt it
>
> I am in favor of appsawg adopting this draft and I will continue to 
> help work on it.
>


From James.H.Manger@team.telstra.com  Thu Jun  6 22:00:47 2013
Return-Path: <James.H.Manger@team.telstra.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3799821F867B for <apps-discuss@ietfa.amsl.com>; Thu,  6 Jun 2013 22:00:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.462
X-Spam-Level: 
X-Spam-Status: No, score=-0.462 tagged_above=-999 required=5 tests=[AWL=0.439,  BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wh0pExIAhLVy for <apps-discuss@ietfa.amsl.com>; Thu,  6 Jun 2013 22:00:40 -0700 (PDT)
Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by ietfa.amsl.com (Postfix) with ESMTP id 5569C21F8E9D for <apps-discuss@ietf.org>; Thu,  6 Jun 2013 22:00:40 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.87,819,1363093200"; d="scan'208";a="140216932"
Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipocvi.tcif.telstra.com.au with ESMTP; 07 Jun 2013 15:00:39 +1000
X-IronPort-AV: E=McAfee;i="5400,1158,7098"; a="136623637"
Received: from wsmsg3751.srv.dir.telstra.com ([172.49.40.172]) by ipcdvi.tcif.telstra.com.au with ESMTP; 07 Jun 2013 15:00:39 +1000
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3751.srv.dir.telstra.com ([172.49.40.172]) with mapi; Fri, 7 Jun 2013 15:00:38 +1000
From: "Manger, James H" <James.H.Manger@team.telstra.com>
To: "apps-discuss@ietf.org Discuss" <apps-discuss@ietf.org>
Date: Fri, 7 Jun 2013 15:00:38 +1000
Thread-Topic: CBOR: Decimal fractions
Thread-Index: Ac5jO/OHCtPzeGBgS/uGZe5aaNnBHw==
Message-ID: <255B9BB34FB7D647A506DC292726F6E1151B21FB5E@WSMSG3153V.srv.dir.telstra.com>
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, en-AU
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Subject: [apps-discuss] CBOR: Decimal fractions
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 07 Jun 2013 05:00:49 -0000

ZHJhZnQtYm9ybWFubi1jYm9yLTAxIGNhbiBleHByZXNzIGEgZGVjaW1hbCBmcmFjdGlvbiBtICog
MTBeZSB3aXRoIGEgdGFnZ2VkIGFycmF5IG9mIGUgYW5kIG0uIFRoaXMgaXMgYSB1c2VmdWwgZmVh
dHVyZS4NCg0KRGVzY3JpYmluZyB0aGlzIGZlYXR1cmUgYnkgcmVmZXJyaW5nIHRvIGRlY2ltYWw2
NCBpbiBSRkM2MDIwICJZQU5HIiBvbmx5IGFkZHMgY29uZnVzaW9uLiBXaHkgZG9lcyB0aGUgZXhw
b25lbnQgaGF2ZSB0byBiZSBuZWdhdGl2ZT8gSXMgdGhlIG51bWJlciBtICogMTBeLWUgb3IgbSAq
IDEwXmU/IENhbiB0aGUgZXhwb25lbnQgYmUgMCAod2hpY2ggcmVxdWlyZXMgdXNpbmcgdGhlIFBP
U0lUSVZFIG1ham9yIHR5cGUpPyBDYW4gdGhlIG1hbnRpc3NhIGJlIGEgYmlnbnVtPyBIb3cgYWJv
dXQgdGhlIGV4cG9uZW50Pw0KDQpTdWdnZXN0aW9uOg0KDQogIDIuMy4zLiBEZWNpbWFsIEZyYWN0
aW9ucw0KDQogICAgQSBkZWNpbWFsIGZyYWN0aW9uIGNhbiBwcmVjaXNlbHkgcmVwcmVzZW50IGFu
eSBudW1iZXIgdGhhdA0KICAgIGNhbiBiZSBleHByZXNzZWQgd2l0aCBkZWNpbWFsIGRpZ2l0cyBh
bmQgYSBkZWNpbWFsIHBvaW50Lg0KICAgIEl0IGNvbnNpc3RzIG9mIGFuIG1hbnRpc3NhIChtKSBh
bmQgZXhwb25lbnQgKGUpLCBib3RoIG9mDQogICAgd2hpY2ggYXJlIGludGVnZXJzLiBUaGUgbnVt
YmVyIHJlcHJlc2VudGVkIGlzIG0gKiAxMF5lLg0KICAgIEEgZGVjaW1hbCBmcmFjdGlvbiBpcyBy
ZXByZXNlbnRlZCBpbiBDQk9SIHVzaW5nIHRhZyA0DQogICAgZm9sbG93ZWQgYnkgYW4gYXJyYXkg
aG9sZGluZyAyIGl0ZW1zOiB0aGUgZXhwb25lbnQsDQogICAgdGhlbiB0aGUgbWFudGlzc2EuIFRo
ZSBleHBvbmVudCBhbmQgbWFudGlzc2EgY2FuIHVzZSBhbnkNCiAgICBDQk9SIGludGVnZXIgcmVw
cmVzZW50YXRpb24sIGluY2x1ZGluZyBCaWdudW1zLg0KDQogICAgRXhhbXBsZTogMjczLjE1IGNv
dWxkIGJlIHJlcHJlc2VudGVkIGFzIDI3MzE1ICogMTBeLTI6DQogICAgICBDNCAgICAgICAgICAg
ICAtLSB0YWcsICM0DQogICAgICAgICA4MiAgICAgICAgICAtLSBhcnJheSwgMiBpdGVtcw0KICAg
ICAgICAgICAgMjEgICAgICAgLS0gbmVnYXRpdmUsIC0xLTEgPSAtMg0KICAgICAgICAgICAgMTkg
NkFCMyAgLS0gcG9zaXRpdmUsIDB4NkFCMyA9IDI3MzE1DQogICAgDQpQLlMuIFN3YXBwaW5nIHRo
ZSBvcmRlciBpbiB0aGUgYXJyYXkgdG8gbWFudGlzc2EgdGhlbiBleHBvbmVudCB3b3VsZCBiZSBt
b3JlIGludHVpdGl2ZSwgbWF0Y2hpbmcgaG93IHRoZXkgYXJlIHdyaXR0ZW4gKGVnIDEyM2UtNCwg
MTIzeDEwXi00KS4NCg0KU2hvdWxkIHdlIGNvbXBsZXRlIHRoZSBzZXQgd2l0aCAiQmlnIFJlYWwi
PyBUYWcgeHggZm9sbG93ZWQgYnkgYW4gYXJyYXkgb2YgbSBhbmQgZSwgcmVwcmVzZW50aW5nIHRo
ZSBudW1iZXIgbSAqIDJeZSwgd2hlcmUgbSAoYW5kIGUpIGNhbiBiZSBhIGJpZ251bS4NCg0KLS0N
CkphbWVzIE1hbmdlcg0KDQoNCg==

From cabo@tzi.org  Fri Jun  7 16:19:16 2013
Return-Path: <cabo@tzi.org>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B25BB21E804D for <apps-discuss@ietfa.amsl.com>; Fri,  7 Jun 2013 16:19:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.166
X-Spam-Level: 
X-Spam-Status: No, score=-105.166 tagged_above=-999 required=5 tests=[AWL=-1.083, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lAtLW9IymTSG for <apps-discuss@ietfa.amsl.com>; Fri,  7 Jun 2013 16:19:10 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 7999F21F99F0 for <apps-discuss@ietf.org>; Fri,  7 Jun 2013 16:19:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r57NJ2R2022194; Sat, 8 Jun 2013 01:19:02 +0200 (CEST)
Received: from [192.168.217.105] (p54891ED1.dip0.t-ipconnect.de [84.137.30.209]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 0F83D351A; Sat,  8 Jun 2013 01:19:01 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
Content-Type: text/plain; charset=utf-8
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1151B21FB5E@WSMSG3153V.srv.dir.telstra.com>
Date: Sat, 8 Jun 2013 01:18:58 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <06265AC1-2ACF-4E8F-86C0-927F4A86028D@tzi.org>
References: <255B9BB34FB7D647A506DC292726F6E1151B21FB5E@WSMSG3153V.srv.dir.telstra.com>
To: "Manger, James H" <James.H.Manger@team.telstra.com>
X-Mailer: Apple Mail (2.1503)
Cc: "apps-discuss@ietf.org Discuss" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] CBOR: Decimal fractions
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 07 Jun 2013 23:19:16 -0000

On Jun 7, 2013, at 07:00, "Manger, James H" =
<James.H.Manger@team.telstra.com> wrote:

> draft-bormann-cbor-01 can express a decimal fraction m * 10^e with a =
tagged array of e and m. This is a useful feature.
>=20
> Describing this feature by referring to decimal64 in RFC6020 "YANG" =
only adds confusion.

Well, it *was* modeled after RFC 6020, but we can move this to a comment =
later.

> Why does the exponent have to be negative?

The idea is that you already can send integers as integers; the decimal =
fractions format is just in support of fractions that cannot be =
represented exactly as floats (e.g., 1.1 =3D 11e-1 =E2=89=85 =
0xfb3ff199999999999a).
(If you have a good use-case for non-negative exponents, I'd like to =
hear it -- maybe I just lack imagination.)

> Is the number m * 10^-e or m * 10^e?

10**e (as e is a negative number).
(We use C syntax plus "**" in the draft, so 10^e would be 10 XOR e.  =
Sorry about that...)

> Can the exponent be 0 (which requires using the POSITIVE major type)?

No.  In this case, just send the mantissa as an integer, no need to wrap =
it in a decimal fraction.

> Can the mantissa be a bignum? How about the exponent?

This needs to be clarified, as the current text just says "integer" and =
does not define whether a bignum is an integer.  (I would expect a =
bignum mantissa to be highly useful, but a use for a bignum exponent =
escapes me.)

> Suggestion:
>=20
>  2.3.3. Decimal Fractions
>=20
>    A decimal fraction can precisely represent any number that
>    can be expressed with decimal digits and a decimal point.
>    It consists of an mantissa (m) and exponent (e), both of
>    which are integers. The number represented is m * 10^e.
>    A decimal fraction is represented in CBOR using tag 4
>    followed by an array holding 2 items: the exponent,
>    then the mantissa. The exponent and mantissa can use any
>    CBOR integer representation, including Bignums.
>=20
>    Example: 273.15 could be represented as 27315 * 10^-2:
>      C4             -- tag, #4
>         82          -- array, 2 items
>            21       -- negative, -1-1 =3D -2
>            19 6AB3  -- positive, 0x6AB3 =3D 27315

Much nicer example format.
We should adopt this...

> P.S. Swapping the order in the array to mantissa then exponent would =
be more intuitive, matching how they are written (eg 123e-4, 123x10^-4).

People who invent floating point representations typically keep the =
exponent where the MSBs would be, which in network byte order is sent =
first.
For processing the number, this order is also slightly more useful.
(For a state-limited streaming JSON-to-CBOR converter this is lots of =
fun anyway, as you still have to do the decimal-binary conversion.  For =
this, you already have to store the entire mantissa, so this does not =
cause any additional storage requirement.)

> Should we complete the set with "Big Real"? Tag xx followed by an =
array of m and e, representing the number m * 2^e, where m (and e) can =
be a bignum.

Not a bad idea.  So far, we tried to stick to IEEE 754 for floating =
point.  Their big binary floats are a bit complicated to use, though, so =
I haven't made up my mind whether they should be added or something like =
this (but probably not with bignum exponents).  One nice thing is that =
the big float doesn't have to cover the Infinities and NaN, because we =
can already represent those in shorter formats.

(Why didn't we stick with IEEE 754 for decimal: IEEE 754's decimal =
floats are complicated by the fact that they also keep the mantissa in =
decimal, using the famous 10-bit Cowlishaw declets for three decimal =
digits each.  What a guy.  A fun subject for an evening at the =
fireplace.)

Gr=C3=BC=C3=9Fe, Carsten


From James.H.Manger@team.telstra.com  Sat Jun  8 04:58:25 2013
Return-Path: <James.H.Manger@team.telstra.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22F1421F9965 for <apps-discuss@ietfa.amsl.com>; Sat,  8 Jun 2013 04:58:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.556
X-Spam-Level: 
X-Spam-Status: No, score=-0.556 tagged_above=-999 required=5 tests=[AWL=0.345,  BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ONiAiMsr89sC for <apps-discuss@ietfa.amsl.com>; Sat,  8 Jun 2013 04:58:19 -0700 (PDT)
Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by ietfa.amsl.com (Postfix) with ESMTP id 6190B21F9962 for <apps-discuss@ietf.org>; Sat,  8 Jun 2013 04:58:17 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.87,827,1363093200"; d="scan'208";a="141516165"
Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipoani.tcif.telstra.com.au with ESMTP; 08 Jun 2013 21:58:13 +1000
X-IronPort-AV: E=McAfee;i="5400,1158,7099"; a="138657603"
Received: from wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) by ipcbni.tcif.telstra.com.au with ESMTP; 08 Jun 2013 21:58:13 +1000
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) with mapi; Sat, 8 Jun 2013 21:58:13 +1000
From: "Manger, James H" <James.H.Manger@team.telstra.com>
To: Carsten Bormann <cabo@tzi.org>
Date: Sat, 8 Jun 2013 21:58:11 +1000
Thread-Topic: [apps-discuss] CBOR: Decimal fractions
Thread-Index: Ac5j1W2GGmNJL5/jSGa7789c6X1gQwAVzCSw
Message-ID: <255B9BB34FB7D647A506DC292726F6E1151B21FF5C@WSMSG3153V.srv.dir.telstra.com>
References: <255B9BB34FB7D647A506DC292726F6E1151B21FB5E@WSMSG3153V.srv.dir.telstra.com> <06265AC1-2ACF-4E8F-86C0-927F4A86028D@tzi.org>
In-Reply-To: <06265AC1-2ACF-4E8F-86C0-927F4A86028D@tzi.org>
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, en-AU
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "apps-discuss@ietf.org Discuss" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] CBOR: Decimal fractions
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 08 Jun 2013 11:58:25 -0000

PiA+IGRyYWZ0LWJvcm1hbm4tY2Jvci0wMSBjYW4gZXhwcmVzcyBhIGRlY2ltYWwgZnJhY3Rpb24g
bSAqIDEwXmUgd2l0aCBhDQo+IHRhZ2dlZCBhcnJheSBvZiBlIGFuZCBtLiBUaGlzIGlzIGEgdXNl
ZnVsIGZlYXR1cmUuDQo+ID4NCj4gPiBEZXNjcmliaW5nIHRoaXMgZmVhdHVyZSBieSByZWZlcnJp
bmcgdG8gZGVjaW1hbDY0IGluIFJGQzYwMjAgIllBTkciDQo+IG9ubHkgYWRkcyBjb25mdXNpb24u
DQo+IA0KPiBXZWxsLCBpdCAqd2FzKiBtb2RlbGVkIGFmdGVyIFJGQyA2MDIwLCBidXQgd2UgY2Fu
IG1vdmUgdGhpcyB0byBhDQo+IGNvbW1lbnQgbGF0ZXIuDQoNClRvIG1lIGl0IGxvb2tlZCBsaWtl
IGEgcGFydGlhbCBBU04uMSBSRUFMIChpbiB2YWx1ZSBub3RhdGlvbik6DQogIHsgbWFudGlzc2Eg
eHh4LCBiYXNlIDJ8MTAsIGV4cG9uZW50IHh4eCB9DQogDQo+ID4gV2h5IGRvZXMgdGhlIGV4cG9u
ZW50IGhhdmUgdG8gYmUgbmVnYXRpdmU/DQo+IA0KPiBUaGUgaWRlYSBpcyB0aGF0IHlvdSBhbHJl
YWR5IGNhbiBzZW5kIGludGVnZXJzIGFzIGludGVnZXJzOyB0aGUgZGVjaW1hbA0KPiBmcmFjdGlv
bnMgZm9ybWF0IGlzIGp1c3QgaW4gc3VwcG9ydCBvZiBmcmFjdGlvbnMgdGhhdCBjYW5ub3QgYmUN
Cj4gcmVwcmVzZW50ZWQgZXhhY3RseSBhcyBmbG9hdHMgKGUuZy4sIDEuMSA9IDExZS0xIOKJhQ0K
PiAweGZiM2ZmMTk5OTk5OTk5OTk5YSkuDQo+IChJZiB5b3UgaGF2ZSBhIGdvb2QgdXNlLWNhc2Ug
Zm9yIG5vbi1uZWdhdGl2ZSBleHBvbmVudHMsIEknZCBsaWtlIHRvDQo+IGhlYXIgaXQgLS0gbWF5
YmUgSSBqdXN0IGxhY2sgaW1hZ2luYXRpb24uKQ0KDQpBIHByb3RvY29sIGhhcywgc2F5LCBhIGN1
cnJlbmN5IGZpZWxkOyBuZWVkcyBleGFjdCBkZWNpbWFsIGZyYWN0aW9uczsgc3BlY2lmaWVzIHRo
ZSBmaWVsZCBpcyBhbHdheXMgZW5jb2RlZCBhcyBhIENCT1IgZGVjaW1hbCBmcmFjdGlvbjsgZXZl
biB0aG91Z2ggc29tZSBjdXJyZW5jeSBhbW91bnRzIGFyZSBpbnRlZ2Vycy4gQ291bGQgcmV3cml0
ZSBpbnRlZ2VycyBzbyBleHBvbmVudCBpcyBuZWdhdGl2ZSAoZWcgY2hhbmdlIDFlOSB0byAxMDAw
MDAwMDAwMGUtMSksIGJ1dCB3aHkgYm90aGVyLg0KDQpJbiBKYXZhLCBhIENCT1IgZGVjaW1hbCBm
cmFjdGlvbiBtYXBzIHdlbGwgdG8gYSBqYXZhLm1hdGguQmlnRGVjaW1hbC4gQSBCaWdEZWNpbWFs
4oCZcyBzY2FsZSAoZXF1aXZhbGVudCB0byAtZXhwb25lbnQpIGNhbiBiZSBuZWdhdGl2ZSBvciBw
b3NpdGl2ZS4NCg0KDQo+ID4gSXMgdGhlIG51bWJlciBtICogMTBeLWUgb3IgbSAqIDEwXmU/DQo+
IA0KPiAxMCoqZSAoYXMgZSBpcyBhIG5lZ2F0aXZlIG51bWJlcikuDQo+IChXZSB1c2UgQyBzeW50
YXggcGx1cyAiKioiIGluIHRoZSBkcmFmdCwgc28gMTBeZSB3b3VsZCBiZSAxMCBYT1IgZS4NCj4g
U29ycnkgYWJvdXQgdGhhdC4uLikNCj4gDQo+ID4gQ2FuIHRoZSBleHBvbmVudCBiZSAwICh3aGlj
aCByZXF1aXJlcyB1c2luZyB0aGUgUE9TSVRJVkUgbWFqb3IgdHlwZSk/DQo+IA0KPiBOby4gIElu
IHRoaXMgY2FzZSwganVzdCBzZW5kIHRoZSBtYW50aXNzYSBhcyBhbiBpbnRlZ2VyLCBubyBuZWVk
IHRvDQo+IHdyYXAgaXQgaW4gYSBkZWNpbWFsIGZyYWN0aW9uLg0KPiANCj4gPiBDYW4gdGhlIG1h
bnRpc3NhIGJlIGEgYmlnbnVtPyBIb3cgYWJvdXQgdGhlIGV4cG9uZW50Pw0KPiANCj4gVGhpcyBu
ZWVkcyB0byBiZSBjbGFyaWZpZWQsIGFzIHRoZSBjdXJyZW50IHRleHQganVzdCBzYXlzICJpbnRl
Z2VyIiBhbmQNCj4gZG9lcyBub3QgZGVmaW5lIHdoZXRoZXIgYSBiaWdudW0gaXMgYW4gaW50ZWdl
ci4gIChJIHdvdWxkIGV4cGVjdCBhDQo+IGJpZ251bSBtYW50aXNzYSB0byBiZSBoaWdobHkgdXNl
ZnVsLCBidXQgYSB1c2UgZm9yIGEgYmlnbnVtIGV4cG9uZW50DQo+IGVzY2FwZXMgbWUuKQ0KDQpO
byBuZWVkIGZvciBhIGJpZ251bSBleHBvbmVudC4NCg0KLS0NCkphbWVzIE1hbmdlcg0KDQogDQo+
ID4gU3VnZ2VzdGlvbjoNCj4gPg0KPiA+ICAyLjMuMy4gRGVjaW1hbCBGcmFjdGlvbnMNCj4gPg0K
PiA+ICAgIEEgZGVjaW1hbCBmcmFjdGlvbiBjYW4gcHJlY2lzZWx5IHJlcHJlc2VudCBhbnkgbnVt
YmVyIHRoYXQNCj4gPiAgICBjYW4gYmUgZXhwcmVzc2VkIHdpdGggZGVjaW1hbCBkaWdpdHMgYW5k
IGEgZGVjaW1hbCBwb2ludC4NCj4gPiAgICBJdCBjb25zaXN0cyBvZiBhbiBtYW50aXNzYSAobSkg
YW5kIGV4cG9uZW50IChlKSwgYm90aCBvZg0KPiA+ICAgIHdoaWNoIGFyZSBpbnRlZ2Vycy4gVGhl
IG51bWJlciByZXByZXNlbnRlZCBpcyBtICogMTBeZS4NCj4gPiAgICBBIGRlY2ltYWwgZnJhY3Rp
b24gaXMgcmVwcmVzZW50ZWQgaW4gQ0JPUiB1c2luZyB0YWcgNA0KPiA+ICAgIGZvbGxvd2VkIGJ5
IGFuIGFycmF5IGhvbGRpbmcgMiBpdGVtczogdGhlIGV4cG9uZW50LA0KPiA+ICAgIHRoZW4gdGhl
IG1hbnRpc3NhLiBUaGUgZXhwb25lbnQgYW5kIG1hbnRpc3NhIGNhbiB1c2UgYW55DQo+ID4gICAg
Q0JPUiBpbnRlZ2VyIHJlcHJlc2VudGF0aW9uLCBpbmNsdWRpbmcgQmlnbnVtcy4NCj4gPg0KPiA+
ICAgIEV4YW1wbGU6IDI3My4xNSBjb3VsZCBiZSByZXByZXNlbnRlZCBhcyAyNzMxNSAqIDEwXi0y
Og0KPiA+ICAgICAgQzQgICAgICAgICAgICAgLS0gdGFnLCAjNA0KPiA+ICAgICAgICAgODIgICAg
ICAgICAgLS0gYXJyYXksIDIgaXRlbXMNCj4gPiAgICAgICAgICAgIDIxICAgICAgIC0tIG5lZ2F0
aXZlLCAtMS0xID0gLTINCj4gPiAgICAgICAgICAgIDE5IDZBQjMgIC0tIHBvc2l0aXZlLCAweDZB
QjMgPSAyNzMxNQ0KPiANCj4gTXVjaCBuaWNlciBleGFtcGxlIGZvcm1hdC4NCj4gV2Ugc2hvdWxk
IGFkb3B0IHRoaXMuLi4NCj4gDQo+ID4gUC5TLiBTd2FwcGluZyB0aGUgb3JkZXIgaW4gdGhlIGFy
cmF5IHRvIG1hbnRpc3NhIHRoZW4gZXhwb25lbnQgd291bGQNCj4gYmUgbW9yZSBpbnR1aXRpdmUs
IG1hdGNoaW5nIGhvdyB0aGV5IGFyZSB3cml0dGVuIChlZyAxMjNlLTQsIDEyM3gxMF4tDQo+IDQp
Lg0KPiANCj4gUGVvcGxlIHdobyBpbnZlbnQgZmxvYXRpbmcgcG9pbnQgcmVwcmVzZW50YXRpb25z
IHR5cGljYWxseSBrZWVwIHRoZQ0KPiBleHBvbmVudCB3aGVyZSB0aGUgTVNCcyB3b3VsZCBiZSwg
d2hpY2ggaW4gbmV0d29yayBieXRlIG9yZGVyIGlzIHNlbnQNCj4gZmlyc3QuDQo+IEZvciBwcm9j
ZXNzaW5nIHRoZSBudW1iZXIsIHRoaXMgb3JkZXIgaXMgYWxzbyBzbGlnaHRseSBtb3JlIHVzZWZ1
bC4NCj4gKEZvciBhIHN0YXRlLWxpbWl0ZWQgc3RyZWFtaW5nIEpTT04tdG8tQ0JPUiBjb252ZXJ0
ZXIgdGhpcyBpcyBsb3RzIG9mDQo+IGZ1biBhbnl3YXksIGFzIHlvdSBzdGlsbCBoYXZlIHRvIGRv
IHRoZSBkZWNpbWFsLWJpbmFyeSBjb252ZXJzaW9uLiAgRm9yDQo+IHRoaXMsIHlvdSBhbHJlYWR5
IGhhdmUgdG8gc3RvcmUgdGhlIGVudGlyZSBtYW50aXNzYSwgc28gdGhpcyBkb2VzIG5vdA0KPiBj
YXVzZSBhbnkgYWRkaXRpb25hbCBzdG9yYWdlIHJlcXVpcmVtZW50LikNCj4gDQo+ID4gU2hvdWxk
IHdlIGNvbXBsZXRlIHRoZSBzZXQgd2l0aCAiQmlnIFJlYWwiPyBUYWcgeHggZm9sbG93ZWQgYnkg
YW4NCj4gYXJyYXkgb2YgbSBhbmQgZSwgcmVwcmVzZW50aW5nIHRoZSBudW1iZXIgbSAqIDJeZSwg
d2hlcmUgbSAoYW5kIGUpIGNhbg0KPiBiZSBhIGJpZ251bS4NCj4gDQo+IE5vdCBhIGJhZCBpZGVh
LiAgU28gZmFyLCB3ZSB0cmllZCB0byBzdGljayB0byBJRUVFIDc1NCBmb3IgZmxvYXRpbmcNCj4g
cG9pbnQuICBUaGVpciBiaWcgYmluYXJ5IGZsb2F0cyBhcmUgYSBiaXQgY29tcGxpY2F0ZWQgdG8g
dXNlLCB0aG91Z2gsDQo+IHNvIEkgaGF2ZW4ndCBtYWRlIHVwIG15IG1pbmQgd2hldGhlciB0aGV5
IHNob3VsZCBiZSBhZGRlZCBvciBzb21ldGhpbmcNCj4gbGlrZSB0aGlzIChidXQgcHJvYmFibHkg
bm90IHdpdGggYmlnbnVtIGV4cG9uZW50cykuICBPbmUgbmljZSB0aGluZyBpcw0KPiB0aGF0IHRo
ZSBiaWcgZmxvYXQgZG9lc24ndCBoYXZlIHRvIGNvdmVyIHRoZSBJbmZpbml0aWVzIGFuZCBOYU4s
DQo+IGJlY2F1c2Ugd2UgY2FuIGFscmVhZHkgcmVwcmVzZW50IHRob3NlIGluIHNob3J0ZXIgZm9y
bWF0cy4NCj4gDQo+IChXaHkgZGlkbid0IHdlIHN0aWNrIHdpdGggSUVFRSA3NTQgZm9yIGRlY2lt
YWw6IElFRUUgNzU0J3MgZGVjaW1hbA0KPiBmbG9hdHMgYXJlIGNvbXBsaWNhdGVkIGJ5IHRoZSBm
YWN0IHRoYXQgdGhleSBhbHNvIGtlZXAgdGhlIG1hbnRpc3NhIGluDQo+IGRlY2ltYWwsIHVzaW5n
IHRoZSBmYW1vdXMgMTAtYml0IENvd2xpc2hhdyBkZWNsZXRzIGZvciB0aHJlZSBkZWNpbWFsDQo+
IGRpZ2l0cyBlYWNoLiAgV2hhdCBhIGd1eS4gIEEgZnVuIHN1YmplY3QgZm9yIGFuIGV2ZW5pbmcg
YXQgdGhlDQo+IGZpcmVwbGFjZS4pDQo+IA0KPiBHcsO8w59lLCBDYXJzdGVuDQoNCg==

From hallam@gmail.com  Sat Jun  8 05:05:47 2013
Return-Path: <hallam@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 911D821F9A33 for <apps-discuss@ietfa.amsl.com>; Sat,  8 Jun 2013 05:05:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.349
X-Spam-Level: 
X-Spam-Status: No, score=-1.349 tagged_above=-999 required=5 tests=[AWL=-0.916, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PmnaoLYEeOI7 for <apps-discuss@ietfa.amsl.com>; Sat,  8 Jun 2013 05:05:46 -0700 (PDT)
Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 1419D21F994D for <apps-discuss@ietf.org>; Sat,  8 Jun 2013 05:05:45 -0700 (PDT)
Received: by mail-we0-f169.google.com with SMTP id n57so3790895wev.0 for <apps-discuss@ietf.org>; Sat, 08 Jun 2013 05:05:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IXslSu/edvRSFwaEeoENtU1DcppBEcup9gFmxnCPRmg=; b=h1EXRpKxS0/CW/SogEBy0kkXdQqCn7chMBiQ0HKfmvVVh5vkxZ6H8T+0yiUqa+VMQN TtLOTuprfdKKVqgH1ZeZhPH9HkDDQVP4/TtdHp/0HbZ2FwmaHuXUNC8u+PIW//aWZAIs j5CS9yRov6TCsTRKRI664+I5CAx/tfGZvvdC+V9aYCFrn2U/hDlvdBaOhUbfNKf+FAiW SbgtUjg974OdWMVfMYvSdIegjOLHq5VJARQQ+zuo70VTfueL79iPa3NRawKiNBJpi4zi RVF2UfsxmvZBBvyKRdInxbm1mjfIEcKW7P5tmrHDDH29VYJWVx9BSn46/mMrGEDnBUuR WZCA==
MIME-Version: 1.0
X-Received: by 10.194.104.105 with SMTP id gd9mr1559665wjb.1.1370693145154; Sat, 08 Jun 2013 05:05:45 -0700 (PDT)
Received: by 10.194.44.100 with HTTP; Sat, 8 Jun 2013 05:05:45 -0700 (PDT)
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1151B21FF5C@WSMSG3153V.srv.dir.telstra.com>
References: <255B9BB34FB7D647A506DC292726F6E1151B21FB5E@WSMSG3153V.srv.dir.telstra.com> <06265AC1-2ACF-4E8F-86C0-927F4A86028D@tzi.org> <255B9BB34FB7D647A506DC292726F6E1151B21FF5C@WSMSG3153V.srv.dir.telstra.com>
Date: Sat, 8 Jun 2013 08:05:45 -0400
Message-ID: <CAMm+LwjQc7-M7=zv+VnD+WVnBdpDGLehCtuTjH7VE=-Y1g+nhA@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: "Manger, James H" <James.H.Manger@team.telstra.com>
Content-Type: multipart/alternative; boundary=089e0102fddc0367fb04dea35e53
Cc: "apps-discuss@ietf.org Discuss" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] CBOR: Decimal fractions
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 08 Jun 2013 12:05:47 -0000

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

There are three IEEE 754 floating point decimal representations already.

JavaScript only uses IEEE 754 binary64.

If this is a standards effort I think there should be a really good reason
not to use the established standard. Especially so when it is outside IETF
field of expertise.


On Sat, Jun 8, 2013 at 7:58 AM, Manger, James H <
James.H.Manger@team.telstra.com> wrote:

> > > draft-bormann-cbor-01 can express a decimal fraction m * 10^e with a
> > tagged array of e and m. This is a useful feature.
> > >
> > > Describing this feature by referring to decimal64 in RFC6020 "YANG"
> > only adds confusion.
> >
> > Well, it *was* modeled after RFC 6020, but we can move this to a
> > comment later.
>
> To me it looked like a partial ASN.1 REAL (in value notation):
>   { mantissa xxx, base 2|10, exponent xxx }
>
> > > Why does the exponent have to be negative?
> >
> > The idea is that you already can send integers as integers; the decimal
> > fractions format is just in support of fractions that cannot be
> > represented exactly as floats (e.g., 1.1 =3D 11e-1 =E2=89=85
> > 0xfb3ff199999999999a).
> > (If you have a good use-case for non-negative exponents, I'd like to
> > hear it -- maybe I just lack imagination.)
>
> A protocol has, say, a currency field; needs exact decimal fractions;
> specifies the field is always encoded as a CBOR decimal fraction; even
> though some currency amounts are integers. Could rewrite integers so
> exponent is negative (eg change 1e9 to 10000000000e-1), but why bother.
>
> In Java, a CBOR decimal fraction maps well to a java.math.BigDecimal. A
> BigDecimal=E2=80=99s scale (equivalent to -exponent) can be negative or p=
ositive.
>
>
> > > Is the number m * 10^-e or m * 10^e?
> >
> > 10**e (as e is a negative number).
> > (We use C syntax plus "**" in the draft, so 10^e would be 10 XOR e.
> > Sorry about that...)
> >
> > > Can the exponent be 0 (which requires using the POSITIVE major type)?
> >
> > No.  In this case, just send the mantissa as an integer, no need to
> > wrap it in a decimal fraction.
> >
> > > Can the mantissa be a bignum? How about the exponent?
> >
> > This needs to be clarified, as the current text just says "integer" and
> > does not define whether a bignum is an integer.  (I would expect a
> > bignum mantissa to be highly useful, but a use for a bignum exponent
> > escapes me.)
>
> No need for a bignum exponent.
>
> --
> James Manger
>
>
> > > Suggestion:
> > >
> > >  2.3.3. Decimal Fractions
> > >
> > >    A decimal fraction can precisely represent any number that
> > >    can be expressed with decimal digits and a decimal point.
> > >    It consists of an mantissa (m) and exponent (e), both of
> > >    which are integers. The number represented is m * 10^e.
> > >    A decimal fraction is represented in CBOR using tag 4
> > >    followed by an array holding 2 items: the exponent,
> > >    then the mantissa. The exponent and mantissa can use any
> > >    CBOR integer representation, including Bignums.
> > >
> > >    Example: 273.15 could be represented as 27315 * 10^-2:
> > >      C4             -- tag, #4
> > >         82          -- array, 2 items
> > >            21       -- negative, -1-1 =3D -2
> > >            19 6AB3  -- positive, 0x6AB3 =3D 27315
> >
> > Much nicer example format.
> > We should adopt this...
> >
> > > P.S. Swapping the order in the array to mantissa then exponent would
> > be more intuitive, matching how they are written (eg 123e-4, 123x10^-
> > 4).
> >
> > People who invent floating point representations typically keep the
> > exponent where the MSBs would be, which in network byte order is sent
> > first.
> > For processing the number, this order is also slightly more useful.
> > (For a state-limited streaming JSON-to-CBOR converter this is lots of
> > fun anyway, as you still have to do the decimal-binary conversion.  For
> > this, you already have to store the entire mantissa, so this does not
> > cause any additional storage requirement.)
> >
> > > Should we complete the set with "Big Real"? Tag xx followed by an
> > array of m and e, representing the number m * 2^e, where m (and e) can
> > be a bignum.
> >
> > Not a bad idea.  So far, we tried to stick to IEEE 754 for floating
> > point.  Their big binary floats are a bit complicated to use, though,
> > so I haven't made up my mind whether they should be added or something
> > like this (but probably not with bignum exponents).  One nice thing is
> > that the big float doesn't have to cover the Infinities and NaN,
> > because we can already represent those in shorter formats.
> >
> > (Why didn't we stick with IEEE 754 for decimal: IEEE 754's decimal
> > floats are complicated by the fact that they also keep the mantissa in
> > decimal, using the famous 10-bit Cowlishaw declets for three decimal
> > digits each.  What a guy.  A fun subject for an evening at the
> > fireplace.)
> >
> > Gr=C3=BC=C3=9Fe, Carsten
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>



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

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

<div dir=3D"ltr"><span style=3D"font-family:arial,sans-serif;font-size:12.8=
00000190734863px">There are three IEEE 754 floating point decimal represent=
ations already.</span><div style=3D"font-family:arial,sans-serif;font-size:=
12.800000190734863px">
<br></div><div style=3D"font-family:arial,sans-serif;font-size:12.800000190=
734863px">JavaScript only uses IEEE 754 binary64.</div><div style=3D"font-f=
amily:arial,sans-serif;font-size:12.800000190734863px"><br></div><div style=
=3D"font-family:arial,sans-serif;font-size:12.800000190734863px">
If this is a standards effort I think there should be a really good reason =
not to use the established standard. Especially so when it is outside IETF =
field of expertise.</div></div><div class=3D"gmail_extra"><br><br><div clas=
s=3D"gmail_quote">
On Sat, Jun 8, 2013 at 7:58 AM, Manger, James H <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:James.H.Manger@team.telstra.com" target=3D"_blank">James.H.Man=
ger@team.telstra.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
">
<div class=3D"im">&gt; &gt; draft-bormann-cbor-01 can express a decimal fra=
ction m * 10^e with a<br>
&gt; tagged array of e and m. This is a useful feature.<br>
&gt; &gt;<br>
&gt; &gt; Describing this feature by referring to decimal64 in RFC6020 &quo=
t;YANG&quot;<br>
&gt; only adds confusion.<br>
&gt;<br>
&gt; Well, it *was* modeled after RFC 6020, but we can move this to a<br>
&gt; comment later.<br>
<br>
</div>To me it looked like a partial ASN.1 REAL (in value notation):<br>
=C2=A0 { mantissa xxx, base 2|10, exponent xxx }<br>
<div class=3D"im"><br>
&gt; &gt; Why does the exponent have to be negative?<br>
&gt;<br>
&gt; The idea is that you already can send integers as integers; the decima=
l<br>
&gt; fractions format is just in support of fractions that cannot be<br>
&gt; represented exactly as floats (e.g., 1.1 =3D 11e-1 =E2=89=85<br>
&gt; 0xfb3ff199999999999a).<br>
&gt; (If you have a good use-case for non-negative exponents, I&#39;d like =
to<br>
&gt; hear it -- maybe I just lack imagination.)<br>
<br>
</div>A protocol has, say, a currency field; needs exact decimal fractions;=
 specifies the field is always encoded as a CBOR decimal fraction; even tho=
ugh some currency amounts are integers. Could rewrite integers so exponent =
is negative (eg change 1e9 to 10000000000e-1), but why bother.<br>

<br>
In Java, a CBOR decimal fraction maps well to a java.math.BigDecimal. A Big=
Decimal=E2=80=99s scale (equivalent to -exponent) can be negative or positi=
ve.<br>
<div class=3D"im"><br>
<br>
&gt; &gt; Is the number m * 10^-e or m * 10^e?<br>
&gt;<br>
&gt; 10**e (as e is a negative number).<br>
&gt; (We use C syntax plus &quot;**&quot; in the draft, so 10^e would be 10=
 XOR e.<br>
&gt; Sorry about that...)<br>
&gt;<br>
&gt; &gt; Can the exponent be 0 (which requires using the POSITIVE major ty=
pe)?<br>
&gt;<br>
&gt; No. =C2=A0In this case, just send the mantissa as an integer, no need =
to<br>
&gt; wrap it in a decimal fraction.<br>
&gt;<br>
&gt; &gt; Can the mantissa be a bignum? How about the exponent?<br>
&gt;<br>
&gt; This needs to be clarified, as the current text just says &quot;intege=
r&quot; and<br>
&gt; does not define whether a bignum is an integer. =C2=A0(I would expect =
a<br>
&gt; bignum mantissa to be highly useful, but a use for a bignum exponent<b=
r>
&gt; escapes me.)<br>
<br>
</div>No need for a bignum exponent.<br>
<br>
--<br>
James Manger<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
&gt; &gt; Suggestion:<br>
&gt; &gt;<br>
&gt; &gt; =C2=A02.3.3. Decimal Fractions<br>
&gt; &gt;<br>
&gt; &gt; =C2=A0 =C2=A0A decimal fraction can precisely represent any numbe=
r that<br>
&gt; &gt; =C2=A0 =C2=A0can be expressed with decimal digits and a decimal p=
oint.<br>
&gt; &gt; =C2=A0 =C2=A0It consists of an mantissa (m) and exponent (e), bot=
h of<br>
&gt; &gt; =C2=A0 =C2=A0which are integers. The number represented is m * 10=
^e.<br>
&gt; &gt; =C2=A0 =C2=A0A decimal fraction is represented in CBOR using tag =
4<br>
&gt; &gt; =C2=A0 =C2=A0followed by an array holding 2 items: the exponent,<=
br>
&gt; &gt; =C2=A0 =C2=A0then the mantissa. The exponent and mantissa can use=
 any<br>
&gt; &gt; =C2=A0 =C2=A0CBOR integer representation, including Bignums.<br>
&gt; &gt;<br>
&gt; &gt; =C2=A0 =C2=A0Example: 273.15 could be represented as 27315 * 10^-=
2:<br>
&gt; &gt; =C2=A0 =C2=A0 =C2=A0C4 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
-- tag, #4<br>
&gt; &gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 82 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
-- array, 2 items<br>
&gt; &gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A021 =C2=A0 =C2=A0 =C2=A0 =
-- negative, -1-1 =3D -2<br>
&gt; &gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A019 6AB3 =C2=A0-- positiv=
e, 0x6AB3 =3D 27315<br>
&gt;<br>
&gt; Much nicer example format.<br>
&gt; We should adopt this...<br>
&gt;<br>
&gt; &gt; P.S. Swapping the order in the array to mantissa then exponent wo=
uld<br>
&gt; be more intuitive, matching how they are written (eg 123e-4, 123x10^-<=
br>
&gt; 4).<br>
&gt;<br>
&gt; People who invent floating point representations typically keep the<br=
>
&gt; exponent where the MSBs would be, which in network byte order is sent<=
br>
&gt; first.<br>
&gt; For processing the number, this order is also slightly more useful.<br=
>
&gt; (For a state-limited streaming JSON-to-CBOR converter this is lots of<=
br>
&gt; fun anyway, as you still have to do the decimal-binary conversion. =C2=
=A0For<br>
&gt; this, you already have to store the entire mantissa, so this does not<=
br>
&gt; cause any additional storage requirement.)<br>
&gt;<br>
&gt; &gt; Should we complete the set with &quot;Big Real&quot;? Tag xx foll=
owed by an<br>
&gt; array of m and e, representing the number m * 2^e, where m (and e) can=
<br>
&gt; be a bignum.<br>
&gt;<br>
&gt; Not a bad idea. =C2=A0So far, we tried to stick to IEEE 754 for floati=
ng<br>
&gt; point. =C2=A0Their big binary floats are a bit complicated to use, tho=
ugh,<br>
&gt; so I haven&#39;t made up my mind whether they should be added or somet=
hing<br>
&gt; like this (but probably not with bignum exponents). =C2=A0One nice thi=
ng is<br>
&gt; that the big float doesn&#39;t have to cover the Infinities and NaN,<b=
r>
&gt; because we can already represent those in shorter formats.<br>
&gt;<br>
&gt; (Why didn&#39;t we stick with IEEE 754 for decimal: IEEE 754&#39;s dec=
imal<br>
&gt; floats are complicated by the fact that they also keep the mantissa in=
<br>
&gt; decimal, using the famous 10-bit Cowlishaw declets for three decimal<b=
r>
&gt; digits each. =C2=A0What a guy. =C2=A0A fun subject for an evening at t=
he<br>
&gt; fireplace.)<br>
&gt;<br>
&gt; Gr=C3=BC=C3=9Fe, Carsten<br>
<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><br clear=3D"all"><div><br></div>-- <br>=
Website: <a href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br=
>
</div>

--089e0102fddc0367fb04dea35e53--

From cabo@tzi.org  Sat Jun  8 08:48:13 2013
Return-Path: <cabo@tzi.org>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DA8F21F87B7 for <apps-discuss@ietfa.amsl.com>; Sat,  8 Jun 2013 08:48:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.888
X-Spam-Level: 
X-Spam-Status: No, score=-105.888 tagged_above=-999 required=5 tests=[AWL=0.361, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0rb4VQRf+fQr for <apps-discuss@ietfa.amsl.com>; Sat,  8 Jun 2013 08:48:07 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 7194621F86D3 for <apps-discuss@ietf.org>; Sat,  8 Jun 2013 08:48:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r58Fm3TF025323; Sat, 8 Jun 2013 17:48:03 +0200 (CEST)
Received: from [192.168.217.105] (p54893DC9.dip0.t-ipconnect.de [84.137.61.201]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 4E2D5360A; Sat,  8 Jun 2013 17:48:03 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
Content-Type: text/plain; charset=utf-8
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1151B21FF5C@WSMSG3153V.srv.dir.telstra.com>
Date: Sat, 8 Jun 2013 17:47:58 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <B317C655-DBED-49FE-A31D-3D68261A2D69@tzi.org>
References: <255B9BB34FB7D647A506DC292726F6E1151B21FB5E@WSMSG3153V.srv.dir.telstra.com> <06265AC1-2ACF-4E8F-86C0-927F4A86028D@tzi.org> <255B9BB34FB7D647A506DC292726F6E1151B21FF5C@WSMSG3153V.srv.dir.telstra.com>
To: "Manger, James H" <James.H.Manger@team.telstra.com>
X-Mailer: Apple Mail (2.1503)
Cc: "apps-discuss@ietf.org Discuss" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] CBOR: Decimal fractions
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 08 Jun 2013 15:48:13 -0000

> To me it looked like a partial ASN.1 REAL (in value notation):
>  { mantissa xxx, base 2|10, exponent xxx }

I liked the idea behind YANG decimals to only add what is not already =
there.
Integers can already be used to represent the case where the exponent is =
non-negative.
(IEEE 754 binary float is a different situation because it is a =
well-established standard.)

>>> Why does the exponent have to be negative?
>>=20
>> The idea is that you already can send integers as integers; the =
decimal
>> fractions format is just in support of fractions that cannot be
>> represented exactly as floats (e.g., 1.1 =3D 11e-1 =E2=89=85
>> 0xfb3ff199999999999a).
>> (If you have a good use-case for non-negative exponents, I'd like to
>> hear it -- maybe I just lack imagination.)
>=20
> A protocol has, say, a currency field; needs exact decimal fractions; =
specifies the field is always encoded as a CBOR decimal fraction;

Don't do that, then.
Maybe the text should be more explicit that decimalfraction is a =
complement to the existing integer capability.

> In Java, a CBOR decimal fraction maps well to a java.math.BigDecimal. =
A BigDecimal=E2=80=99s scale (equivalent to -exponent) can be negative =
or positive.

Mapping to existing libraries is a better argument.
However, instead of binary mantissa/base-10 exponent representation as =
in decimalfraction, some of the bigdecimal libraries might map even =
better to a representation that keeps the digits in the mantissa in =
decimal, too.
It is not hard to add such a type as a new tag to CBOR.
Likely, this type would use IEEE 754 decimal (which used to be called =
"densely-packed decimal" for a reason).

Decimalfraction is for the case where your arithmetic is in binary, but =
you do have a fractional scale that can be expressed using a negative =
base-10 exponent.  The example in the draft is about a temperature =
reading. Of course there could be separate meta-information somewhere =
else that says the reading is in centi-Kelvin, but it is often more =
convenient to keep the scale with the data.

An argument can be made that the format should not make restrictions =
that are somewhat arbitrary, and limiting the exponent for =
decimalfraction to a negative number may be slightly arbitrary for one =
specific application, while other applications benefit from it.  For =
java.math.BigDecimal, the current decimalfraction means that the sender =
needs to check if the scale is negative (=3D exponent is positive), and =
then multiply the mantissa with 10**-scale before encoding; the encoding =
would then be as an integer/bignum as with a zero scale (=3D zero =
exponent).  (There would be no need for a similar operation for =
decoding.)

My current view is that a full-featured decimal-with-all-frills would =
look more like IEEE 754 decimal, and the decimalfraction type, as =
inspired by RFC 6020, should stay minimal.  It is exactly the fraction =
type you would want to use with SenML, and it is a non-starter to put =
IEEE 754 decimals into a constrained sensor -- the declet conversion =
alone is almost as big as the entirety of CBOR.  But I'm also open to =
lifting the "exponent must be negative" restriction.

>> This needs to be clarified, as the current text just says "integer" =
and
>> does not define whether a bignum is an integer.  (I would expect a
>> bignum mantissa to be highly useful, but a use for a bignum exponent
>> escapes me.)
>=20
> No need for a bignum exponent.

Thanks for confirming this.

Gr=C3=BC=C3=9Fe, Carsten


From mnot@mnot.net  Sun Jun  9 20:38:39 2013
Return-Path: <mnot@mnot.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFBD221F8E41 for <apps-discuss@ietfa.amsl.com>; Sun,  9 Jun 2013 20:38:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-4.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZbmJNYaRjHF for <apps-discuss@ietfa.amsl.com>; Sun,  9 Jun 2013 20:38:35 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 3CCB121F8E2C for <apps-discuss@ietf.org>; Sun,  9 Jun 2013 20:38:35 -0700 (PDT)
Received: from [131.113.150.228] (unknown [131.113.150.228]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id C02D922E1F4 for <apps-discuss@ietf.org>; Sun,  9 Jun 2013 23:38:28 -0400 (EDT)
From: Mark Nottingham <mnot@mnot.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Mon, 10 Jun 2013 12:38:21 +0900
References: <20130610033804.19451.29465.idtracker@ietfa.amsl.com>
To: IETF Apps Discuss <apps-discuss@ietf.org>
Message-Id: <E6062DBC-CD7B-47CA-A6F0-5E7D64C0DB55@mnot.net>
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
X-Mailer: Apple Mail (2.1508)
Subject: [apps-discuss] Fwd: New Version Notification for draft-nottingham-link-hint-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 10 Jun 2013 03:38:39 -0000

FYI.


Begin forwarded message:

> From: internet-drafts@ietf.org
> Subject: New Version Notification for =
draft-nottingham-link-hint-00.txt
> Date: 10 June 2013 12:38:04 PM GMT+09:00
> To: Mark Nottingham <mnot@mnot.net>
>=20
>=20
> A new version of I-D, draft-nottingham-link-hint-00.txt
> has been successfully submitted by Mark Nottingham and posted to the
> IETF repository.
>=20
> Filename:	 draft-nottingham-link-hint
> Revision:	 00
> Title:		 HTTP Link Hints
> Creation date:	 2013-06-10
> Group:		 Individual Submission
> Number of pages: 12
> URL:             =
http://www.ietf.org/internet-drafts/draft-nottingham-link-hint-00.txt
> Status:          =
http://datatracker.ietf.org/doc/draft-nottingham-link-hint
> Htmlized:        =
http://tools.ietf.org/html/draft-nottingham-link-hint-00
>=20
>=20
> Abstract:
>   This memo specifies "HTTP Link Hints", a mechanism for annotating =
Web
>   links to HTTP(S) resources with information that otherwise might be
>   discovered by interacting with them.
>=20
> Note to Readers
>=20
>   This draft should be discussed on the apps-discuss mailing list; see
>   [apps-discuss].
>=20
>=20
>=20
>=20
> The IETF Secretariat
>=20

--
Mark Nottingham   http://www.mnot.net/




From johnl@iecc.com  Sun Jun  9 21:00:20 2013
Return-Path: <johnl@iecc.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F361E21F8763 for <apps-discuss@ietfa.amsl.com>; Sun,  9 Jun 2013 21:00:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -111.199
X-Spam-Level: 
X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HOc6vHi7Gfs4 for <apps-discuss@ietfa.amsl.com>; Sun,  9 Jun 2013 21:00:16 -0700 (PDT)
Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id EA5B921F86C0 for <apps-discuss@ietf.org>; Sun,  9 Jun 2013 21:00:14 -0700 (PDT)
Received: (qmail 53095 invoked from network); 10 Jun 2013 04:00:13 -0000
Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 10 Jun 2013 04:00:13 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:content-transfer-encoding; s=51b54f4d.xn--i8sz2z.k1306; i=johnl@user.iecc.com; bh=hE2nHkbZQBLbGXXWWtSfB57HLIAL9q4R5bVrgBfgvuk=; b=Q2uGMijqDzGUYkIZwXwQwjlIgNwAGwFH9EAnrY7qCulCZm70A8EYIBVTVRPxuWyjVIyeSrfWnj4Xa2Tz8+/xuiwPkuAw1PtFpI/A4pk3HhoAO0Qfx0GjCEvk73CquvXHWspAU3cfIZF9i1Edqpr1pw7FXCU+lBk5GDFlGl94FRfjGS2m6psvzPLx/Jom8TXTiB1aeSVM62UrhatmrAgdesP74jpsHoBFHUCNkuDlY6IWfHSHT0yDHQQrDVo9BGEt
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:mime-version:content-type:content-transfer-encoding; s=51b54f4d.xn--i8sz2z.k1306; olt=johnl@user.iecc.com; bh=hE2nHkbZQBLbGXXWWtSfB57HLIAL9q4R5bVrgBfgvuk=; b=vQVN34fqx/mVYawMAb511PMwTXsyaAtZuwyzcTiKqDdCIdqqEThTEZVbNNk3MpHvvjxal7XrY05bj0N7V5O4iSuVLk7qQV2Yz37SUZ8oX1CQbCnjiwzQxI+2a6dW/0XHosr4UBUGVtIaKKMEujXueXEAfDh6lzj8PC7oK26j09vHg794csuIp4ZDSxYYGd5vFzLqX8mdEVrW7oTLzNFPWQ1EFVvY+c6S50W5ShG4cov6t8fNE3Bry587sw19IwBY
Date: 10 Jun 2013 03:59:50 -0000
Message-ID: <20130610035950.26738.qmail@joyce.lan>
From: "John Levine" <johnl@taugh.com>
To: apps-discuss@ietf.org
Organization: 
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Subject: [apps-discuss] Another organization boundary design
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 10 Jun 2013 04:00:20 -0000

I've sent in a short draft describing a way to publish DNS
organizational boundaries, more or less what Mozilla's public suffix
list does, except published in the DNS itself.

This is much less ambitious than Andrew Sullivan's draft, with no way
to describe cross-links, but it does have the advantages that it uses
wildcards so the number of records added to the DNS is roughly the
number of boundaries, not the number of nodes below a boundary. In
most cases you can find the boundary for any domain name with a single
DNS lookup.

Please take a look and tell me why it's a terrible idea, or not.  (But
please do read it before complaining.  It's only six pages.)

http://datatracker.ietf.org/doc/draft-levine-orgboundary/


From ietf-secretariat-reply@ietf.org  Mon Jun 10 13:57:29 2013
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 (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D55D21F997D for <apps-discuss@ietfa.amsl.com>; Mon, 10 Jun 2013 13:57:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.432
X-Spam-Level: 
X-Spam-Status: No, score=-101.432 tagged_above=-999 required=5 tests=[AWL=-1.051, BAYES_00=-2.599, NO_RELAYS=-0.001, TVD_SPACE_RATIO=2.219, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hqYLK9XWvMTr; Mon, 10 Jun 2013 13:57:29 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C9BE21F9A13; Mon, 10 Jun 2013 13:57:28 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
To: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-rfc5451bis@tools.ietf.org, apps-discuss@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.51
Message-ID: <20130610205728.19065.70263.idtracker@ietfa.amsl.com>
Date: Mon, 10 Jun 2013 13:57:28 -0700
From: IETF Secretariat <ietf-secretariat-reply@ietf.org>
Subject: [apps-discuss] ID Tracker State Update Notice: <draft-ietf-appsawg-rfc5451bis-06.txt>
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 10 Jun 2013 20:57:29 -0000

State changed to AD Evaluation from Publication Requested
ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-rfc5451b=
is/


From hallam@gmail.com  Mon Jun 10 18:21:34 2013
Return-Path: <hallam@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC09821E8094 for <apps-discuss@ietfa.amsl.com>; Mon, 10 Jun 2013 18:21:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.28
X-Spam-Level: 
X-Spam-Status: No, score=-2.28 tagged_above=-999 required=5 tests=[AWL=0.319,  BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e-8J+-F1VIu1 for <apps-discuss@ietfa.amsl.com>; Mon, 10 Jun 2013 18:21:33 -0700 (PDT)
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 43E7C11E80BA for <apps-discuss@ietf.org>; Mon, 10 Jun 2013 18:21:33 -0700 (PDT)
Received: by mail-wg0-f48.google.com with SMTP id f12so5365358wgh.15 for <apps-discuss@ietf.org>; Mon, 10 Jun 2013 18:21:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=AUX+EngUMH/uhtEcvt3zZdUPpfBoozKeyOIuIPgdAQ8=; b=pkiHUFLKwZZeVTkc4gISlc4/u/kvoXO7DXRrvRYiDeU1P6idmGXjhGPPiITPC/vaK8 hVsYsuGhWct51olxTFKDOyQW2ePyNxBtLBrBb0z0yOFE/8db1Pi1DByMoKJ1EMgGPkJU ZhpdCINkmtCDCYd+xxVyYGjzkzdXxUq1kJmGRUaWJuM8FrooVnFSiz5XZ7HswigDVqT5 RT4jnaiOHIysf7jkHTUNRUrLd1odxu4pAfDNEFCmLLQVOkckLIZwQmCrVxGqbUv3pqjR VJthvp0Q3s+jNE/7pkbAOI2tPYsa/e945W76ZAL8/uZ/9gVGA1skiEGUoPEnT4mS8EZW 39+A==
MIME-Version: 1.0
X-Received: by 10.194.104.105 with SMTP id gd9mr7148833wjb.1.1370913692445; Mon, 10 Jun 2013 18:21:32 -0700 (PDT)
Received: by 10.194.44.100 with HTTP; Mon, 10 Jun 2013 18:21:32 -0700 (PDT)
Date: Mon, 10 Jun 2013 21:21:32 -0400
Message-ID: <CAMm+Lwg_dws_RNkJjPPccQarcYy7Z1v5hgZV0_EEKVmpOseASg@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: General discussion of application-layer protocols <apps-discuss@ietf.org>
Content-Type: multipart/alternative; boundary=089e0102fddca7f24604ded6b72f
Subject: [apps-discuss] Extended JSON encodings JSON-B, JSON-C, JSON-D
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 11 Jun 2013 01:21:34 -0000

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

Following on from Paul and Carsten's useful discussion on binary encodings
and comments by Nico et. al. I propose a different approach:


JSON-B 'Binary'
    Is a strict superset of JSON encoding that adds binary encodings for
Javascript data types (Integer, double, String) and a binary data type.

JSON-C 'Compact'
    A strict superset of JSON-B that adds in simple string compression byt
replacement with tag codes

JSON-D 'Data'
    Adds in additional floating point types that are useful for encoding
scientific data.


The basic idea here is to minimize the impact of adding the additional
encodings when using them in a Web Service. All valid JSON encodings are
also valid JSON-B encodings. begin-object '{' and begin-array '[' have the
same code values in each. All the new codes are in the range x80-xFF so as
to avoid conflicts.

One decoder can read both lexical forms. So I would imagine this could be
implemented in JavaScript etc. pretty easily. All you would need to know is
what the capabilities of your decoder are so that you can tell the sender
what is acceptable.


If you are debugging a Web Service, you might tell the system to send data
in plain old JSON so you can read it.

There is no canonical encoding defined. So there are 5 different encodings
for '42': byte, Int16, Int32, Int64, Bignum16

I did not define a date type. This is tempting but probably a bad idea as
there is really no agreement on what the representation of time should be.
If a choice was to be forced it should probably be to specify a time quanta
as 100 nanosecond units as per Windows since that allows a 64 bit value to
represent approx. 58,000 years and thus be Y10K compliant.

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

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

<div dir=3D"ltr">Following on from Paul and Carsten&#39;s useful discussion=
 on binary encodings and comments by Nico et. al. I propose a different app=
roach:<div><br></div><div><br></div><div style>JSON-B &#39;Binary&#39;=A0</=
div>
<div style>=A0 =A0 Is a strict superset of JSON encoding that adds binary e=
ncodings for Javascript data types (Integer, double, String) and a binary d=
ata type.<br></div><div style><br></div><div style>JSON-C &#39;Compact&#39;=
</div>
<div style>=A0 =A0 A strict superset of JSON-B that adds in simple string c=
ompression byt replacement with tag codes</div><div style><br></div><div st=
yle>JSON-D &#39;Data&#39;</div><div style>=A0 =A0 Adds in additional floati=
ng point types that are useful for encoding scientific data.</div>
<div><br></div><div><br></div><div><div style>The basic idea here is to min=
imize the impact of adding the additional encodings when using them in a We=
b Service. All valid JSON encodings are also valid JSON-B encodings. begin-=
object &#39;{&#39; and begin-array &#39;[&#39; have the same code values in=
 each. All the new codes are in the range x80-xFF so as to avoid conflicts.=
</div>
<div style><br></div><div style>One decoder can read both lexical forms. So=
 I would imagine this could be implemented in JavaScript etc. pretty easily=
. All you would need to know is what the capabilities of your decoder are s=
o that you can tell the sender what is acceptable.</div>
<div style><br></div><div style><br></div><div style>If you are debugging a=
 Web Service, you might tell the system to send data in plain old JSON so y=
ou can read it.</div><div><br></div><div style>There is no canonical encodi=
ng defined. So there are 5 different encodings for &#39;42&#39;: byte, Int1=
6, Int32, Int64, Bignum16</div>
<div><br></div><div style>I did not define a date type. This is tempting bu=
t probably a bad idea as there is really no agreement on what the represent=
ation of time should be. If a choice was to be forced it should probably be=
 to specify a time quanta as 100 nanosecond units as per Windows since that=
 allows a 64 bit value to represent approx. 58,000 years and thus be Y10K c=
ompliant.</div>
<div><br></div>-- <br>Website: <a href=3D"http://hallambaker.com/">http://h=
allambaker.com/</a><br>
</div></div>

--089e0102fddca7f24604ded6b72f--

From hallam@gmail.com  Mon Jun 10 18:22:34 2013
Return-Path: <hallam@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7B4421E8094 for <apps-discuss@ietfa.amsl.com>; Mon, 10 Jun 2013 18:22:34 -0700 (PDT)
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=[AWL=0.274,  BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QrnXoVUh0cEd for <apps-discuss@ietfa.amsl.com>; Mon, 10 Jun 2013 18:22:33 -0700 (PDT)
Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 1D54B11E80A6 for <apps-discuss@ietf.org>; Mon, 10 Jun 2013 18:22:32 -0700 (PDT)
Received: by mail-we0-f176.google.com with SMTP id t56so5269244wes.7 for <apps-discuss@ietf.org>; Mon, 10 Jun 2013 18:22:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=V41nIyG5cmIfXxKU0iFc0l9N7J8lZQHBcJYlyGgozkg=; b=iOYYbhucU7NQ3lgwWRFENOjbKYmeCC5SvqNa0OWiTsYsbUx6tviuLWRhk1xV6h5nJC u9tWCKMq8jdrYDKxAu7KifGxTUmc4zBlhgFxfpUyq97Rr8jMsAcbkMwDlZmjxbr4IHWU ZfmfHDLiKUD5Xu4dG2JON8B/EFgYZz0qjMZFnccJ3zklq5haJFDt7MPkymGP3qjxvubp UYZrd88ZZheCjXFnn7J6SGAJCcD73vpjV3BwonbRUJVeewZkByOkGMaTFIHbPdbBG1v0 vp/vpskuEde59DJ9i+zkF0eWWLSsIchXJ2ryDmkN/5RYWkNhpNRBPDfxgoyNetq2QVgI 7YTg==
MIME-Version: 1.0
X-Received: by 10.180.206.77 with SMTP id lm13mr6003577wic.18.1370913752181; Mon, 10 Jun 2013 18:22:32 -0700 (PDT)
Received: by 10.194.44.100 with HTTP; Mon, 10 Jun 2013 18:22:31 -0700 (PDT)
In-Reply-To: <CAMm+Lwg_dws_RNkJjPPccQarcYy7Z1v5hgZV0_EEKVmpOseASg@mail.gmail.com>
References: <CAMm+Lwg_dws_RNkJjPPccQarcYy7Z1v5hgZV0_EEKVmpOseASg@mail.gmail.com>
Date: Mon, 10 Jun 2013 21:22:31 -0400
Message-ID: <CAMm+LwiJjEGDZu5HfvGnV_JQ4aYK6KjByk7qFq-iAO1WdBU2ig@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: General discussion of application-layer protocols <apps-discuss@ietf.org>
Content-Type: multipart/alternative; boundary=001a11c380ae37726e04ded6bba1
Subject: Re: [apps-discuss] Extended JSON encodings JSON-B, JSON-C, JSON-D
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 11 Jun 2013 01:22:34 -0000

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

Once more with the link to the draft:

http://www.ietf.org/id/draft-hallambaker-jsonbcd-00.txt


On Mon, Jun 10, 2013 at 9:21 PM, Phillip Hallam-Baker <hallam@gmail.com>wrote:

> Following on from Paul and Carsten's useful discussion on binary encodings
> and comments by Nico et. al. I propose a different approach:
>
>
> JSON-B 'Binary'
>     Is a strict superset of JSON encoding that adds binary encodings for
> Javascript data types (Integer, double, String) and a binary data type.
>
> JSON-C 'Compact'
>     A strict superset of JSON-B that adds in simple string compression byt
> replacement with tag codes
>
> JSON-D 'Data'
>     Adds in additional floating point types that are useful for encoding
> scientific data.
>
>
> The basic idea here is to minimize the impact of adding the additional
> encodings when using them in a Web Service. All valid JSON encodings are
> also valid JSON-B encodings. begin-object '{' and begin-array '[' have the
> same code values in each. All the new codes are in the range x80-xFF so as
> to avoid conflicts.
>
> One decoder can read both lexical forms. So I would imagine this could be
> implemented in JavaScript etc. pretty easily. All you would need to know is
> what the capabilities of your decoder are so that you can tell the sender
> what is acceptable.
>
>
> If you are debugging a Web Service, you might tell the system to send data
> in plain old JSON so you can read it.
>
> There is no canonical encoding defined. So there are 5 different encodings
> for '42': byte, Int16, Int32, Int64, Bignum16
>
> I did not define a date type. This is tempting but probably a bad idea as
> there is really no agreement on what the representation of time should be.
> If a choice was to be forced it should probably be to specify a time quanta
> as 100 nanosecond units as per Windows since that allows a 64 bit value to
> represent approx. 58,000 years and thus be Y10K compliant.
>
> --
> Website: http://hallambaker.com/
>



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

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

<div dir=3D"ltr"><div style>Once more with the link to the draft:</div><div=
><br></div><a href=3D"http://www.ietf.org/id/draft-hallambaker-jsonbcd-00.t=
xt">http://www.ietf.org/id/draft-hallambaker-jsonbcd-00.txt</a><br><div cla=
ss=3D"gmail_extra">
<br><br><div class=3D"gmail_quote">On Mon, Jun 10, 2013 at 9:21 PM, Phillip=
 Hallam-Baker <span dir=3D"ltr">&lt;<a href=3D"mailto:hallam@gmail.com" tar=
get=3D"_blank">hallam@gmail.com</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
<div dir=3D"ltr">Following on from Paul and Carsten&#39;s useful discussion=
 on binary encodings and comments by Nico et. al. I propose a different app=
roach:<div><br></div><div><br></div><div>JSON-B &#39;Binary&#39;=A0</div>
<div>=A0 =A0 Is a strict superset of JSON encoding that adds binary encodin=
gs for Javascript data types (Integer, double, String) and a binary data ty=
pe.<br></div><div><br></div><div>JSON-C &#39;Compact&#39;</div>
<div>=A0 =A0 A strict superset of JSON-B that adds in simple string compres=
sion byt replacement with tag codes</div><div><br></div><div>JSON-D &#39;Da=
ta&#39;</div><div>=A0 =A0 Adds in additional floating point types that are =
useful for encoding scientific data.</div>

<div><br></div><div><br></div><div><div>The basic idea here is to minimize =
the impact of adding the additional encodings when using them in a Web Serv=
ice. All valid JSON encodings are also valid JSON-B encodings. begin-object=
 &#39;{&#39; and begin-array &#39;[&#39; have the same code values in each.=
 All the new codes are in the range x80-xFF so as to avoid conflicts.</div>

<div><br></div><div>One decoder can read both lexical forms. So I would ima=
gine this could be implemented in JavaScript etc. pretty easily. All you wo=
uld need to know is what the capabilities of your decoder are so that you c=
an tell the sender what is acceptable.</div>

<div><br></div><div><br></div><div>If you are debugging a Web Service, you =
might tell the system to send data in plain old JSON so you can read it.</d=
iv><div><br></div><div>There is no canonical encoding defined. So there are=
 5 different encodings for &#39;42&#39;: byte, Int16, Int32, Int64, Bignum1=
6</div>

<div><br></div><div>I did not define a date type. This is tempting but prob=
ably a bad idea as there is really no agreement on what the representation =
of time should be. If a choice was to be forced it should probably be to sp=
ecify a time quanta as 100 nanosecond units as per Windows since that allow=
s a 64 bit value to represent approx. 58,000 years and thus be Y10K complia=
nt.</div>
<span class=3D"HOEnZb"><font color=3D"#888888">
<div><br></div>-- <br>Website: <a href=3D"http://hallambaker.com/" target=
=3D"_blank">http://hallambaker.com/</a><br>
</font></span></div></div>
</blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>Website: <a =
href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br>
</div></div>

--001a11c380ae37726e04ded6bba1--

From nico@cryptonector.com  Mon Jun 10 18:55:39 2013
Return-Path: <nico@cryptonector.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B093721F9953 for <apps-discuss@ietfa.amsl.com>; Mon, 10 Jun 2013 18:55:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GLG79+rjWt84 for <apps-discuss@ietfa.amsl.com>; Mon, 10 Jun 2013 18:55:34 -0700 (PDT)
Received: from homiemail-a30.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id BCCD921F96EB for <apps-discuss@ietf.org>; Mon, 10 Jun 2013 18:55:34 -0700 (PDT)
Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id EFF6321DE59 for <apps-discuss@ietf.org>; Mon, 10 Jun 2013 18:55:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=iA9Lxs0Bb9B9uXuP3bZ1 MkIR0TU=; b=Qhqn/AlfBW1dUMYq4i0nEUd9H0FpchEHDSXOlXGiI4U1OqV/JsSN NCi1oSh4aeGr/IVTptjHUKIrHatzXZ3defi+7Q5YFTcOJpgi9rNBOLO8CdPQmv+t vTqUpdlITkV/D/y/j+dbIA8j/GezNG3FCwvlnZOiWaerKp/VaKlTn7s=
Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTPSA id 9199921DE58 for <apps-discuss@ietf.org>; Mon, 10 Jun 2013 18:55:33 -0700 (PDT)
Received: by mail-wi0-f180.google.com with SMTP id c10so1934003wiw.13 for <apps-discuss@ietf.org>; Mon, 10 Jun 2013 18:55:32 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=A84FajF48bd9HGwd3NdyfcmvYZKooxJ6odzK/nM68QY=; b=A+FkHNhmYv5Ow5Jdw2y9HAa0vfOQVBERNdOzFPaMEDQEBosAUxBl7i2o+XpcX+vuDY 7Ioh4vlJRXh0NRO2/54QKV5Jz0T8JqfLQJ/26mLnV2/ckvIiJzftroyynT3TwP+sebFG DXN5Xz3hjtgYeZjaRk/kB1hhs2JzvBlUe8azCb1TiwFeVahgcy3h4GK1AMICLLMjRcSP 8xwg2nI1VPd9Nq+z3J6P2vzocOsX+Xo5LHAszapme00UB8j3QQ21P9/DkR3+hl4RxJco g10wb8nYEs5rKoSO3f+j90EnPPIgZBOZ9PIOEb4VcB1lBHCs7U2Q3fD7V9UuCgcdw497 mN/g==
MIME-Version: 1.0
X-Received: by 10.194.63.46 with SMTP id d14mr4461593wjs.81.1370915732015; Mon, 10 Jun 2013 18:55:32 -0700 (PDT)
Received: by 10.216.63.136 with HTTP; Mon, 10 Jun 2013 18:55:31 -0700 (PDT)
In-Reply-To: <CAMm+Lwg_dws_RNkJjPPccQarcYy7Z1v5hgZV0_EEKVmpOseASg@mail.gmail.com>
References: <CAMm+Lwg_dws_RNkJjPPccQarcYy7Z1v5hgZV0_EEKVmpOseASg@mail.gmail.com>
Date: Mon, 10 Jun 2013 20:55:31 -0500
Message-ID: <CAK3OfOhnUyB4=JruvZVzg7hthRCQiCA5mWMkyqeLg6UVzNqWpQ@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Phillip Hallam-Baker <hallam@gmail.com>
Content-Type: text/plain; charset=UTF-8
Cc: General discussion of application-layer protocols <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Extended JSON encodings JSON-B, JSON-C, JSON-D
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 11 Jun 2013 01:55:39 -0000

On Mon, Jun 10, 2013 at 8:21 PM, Phillip Hallam-Baker <hallam@gmail.com> wrote:
> The basic idea here is to minimize the impact of adding the additional
> encodings when using them in a Web Service. All valid JSON encodings are
> also valid JSON-B encodings. begin-object '{' and begin-array '[' have the
> same code values in each. All the new codes are in the range x80-xFF so as
> to avoid conflicts.

Using byte values that don't appear in UTF-8 might help w.r.t.
auto-detection.  You might want to have a byte value that's akin to
whitespace, a value that all top-level values in your encoding can
start with, that way there's no ambiguity.

> One decoder can read both lexical forms. So I would imagine this could be
> implemented in JavaScript etc. pretty easily. All you would need to know is
> what the capabilities of your decoder are so that you can tell the sender
> what is acceptable.

This is good.

> I did not define a date type. This is tempting but probably a bad idea as
> there is really no agreement on what the representation of time should be.
> If a choice was to be forced it should probably be to specify a time quanta
> as 100 nanosecond units as per Windows since that allows a 64 bit value to
> represent approx. 58,000 years and thus be Y10K compliant.

That representation works for me (with the epoch
1601-01-01T00:00:00Z).  Signed or unsigned?

Nico
--

From hallam@gmail.com  Mon Jun 10 19:13:15 2013
Return-Path: <hallam@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A52E21E8099 for <apps-discuss@ietfa.amsl.com>; Mon, 10 Jun 2013 19:13:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.36
X-Spam-Level: 
X-Spam-Status: No, score=-2.36 tagged_above=-999 required=5 tests=[AWL=0.240,  BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJsW0+k+gBgC for <apps-discuss@ietfa.amsl.com>; Mon, 10 Jun 2013 19:13:14 -0700 (PDT)
Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id DC0EC21E805A for <apps-discuss@ietf.org>; Mon, 10 Jun 2013 19:13:13 -0700 (PDT)
Received: by mail-wi0-f171.google.com with SMTP id hj3so1258831wib.10 for <apps-discuss@ietf.org>; Mon, 10 Jun 2013 19:13:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fGj98ZqStfOrmgTewyuHx8joWoAJN8pr3CadWN9vijk=; b=0ut++piGWq2gmHw8OKHoK/q4eRJ+1IMJ1FJnvcdmcs4yQaGgiPoZ1Kf3HKygi7jE/P WEfiXiBmLmXsaL8OdEDSYf2f6KG3/AaS+I7DEZXLR7AT2b18C1GlaJwMN+PGCWLWvwbh 0+X9lyUQxF5mKOevYyqOGNbclIe67/DrFuskv88Qp2+TaflNmw0KWYFgdhvcGANFf/lb TwQuXknuFteF6ZofYvResyukSzMwlZR0ASU4iOH1euRxXCkERxvE4rI30xkYgzY4GetM qmGSwoveDkeJ9r1rUB9YYySiQ2MGpG5DLvwYvShH0YK50C3dXHE3wAigRM4zmchyaSLh ixaA==
MIME-Version: 1.0
X-Received: by 10.180.189.136 with SMTP id gi8mr100815wic.11.1370916793042; Mon, 10 Jun 2013 19:13:13 -0700 (PDT)
Received: by 10.194.44.100 with HTTP; Mon, 10 Jun 2013 19:13:12 -0700 (PDT)
In-Reply-To: <CAK3OfOhnUyB4=JruvZVzg7hthRCQiCA5mWMkyqeLg6UVzNqWpQ@mail.gmail.com>
References: <CAMm+Lwg_dws_RNkJjPPccQarcYy7Z1v5hgZV0_EEKVmpOseASg@mail.gmail.com> <CAK3OfOhnUyB4=JruvZVzg7hthRCQiCA5mWMkyqeLg6UVzNqWpQ@mail.gmail.com>
Date: Mon, 10 Jun 2013 22:13:12 -0400
Message-ID: <CAMm+LwhXaP4+RZHgVTZf7HBTkZeP5nJvs0jJ=gf3MLd3rNrACw@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Nico Williams <nico@cryptonector.com>
Content-Type: multipart/alternative; boundary=001a11c2412c774ebf04ded7701f
Cc: General discussion of application-layer protocols <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Extended JSON encodings JSON-B, JSON-C, JSON-D
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 11 Jun 2013 02:13:15 -0000

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

On Mon, Jun 10, 2013 at 9:55 PM, Nico Williams <nico@cryptonector.com>wrote:

> On Mon, Jun 10, 2013 at 8:21 PM, Phillip Hallam-Baker <hallam@gmail.com>
> wrote:
> > The basic idea here is to minimize the impact of adding the additional
> > encodings when using them in a Web Service. All valid JSON encodings are
> > also valid JSON-B encodings. begin-object '{' and begin-array '[' have
> the
> > same code values in each. All the new codes are in the range x80-xFF so
> as
> > to avoid conflicts.
>
> Using byte values that don't appear in UTF-8 might help w.r.t.
> auto-detection.  You might want to have a byte value that's akin to
> whitespace, a value that all top-level values in your encoding can
> start with, that way there's no ambiguity.


Perhaps you could propose a preamble sequence?



> > I did not define a date type. This is tempting but probably a bad idea as
> > there is really no agreement on what the representation of time should
> be.
> > If a choice was to be forced it should probably be to specify a time
> quanta
> > as 100 nanosecond units as per Windows since that allows a 64 bit value
> to
> > represent approx. 58,000 years and thus be Y10K compliant.
>
> That representation works for me (with the epoch
> 1601-01-01T00:00:00Z).  Signed or unsigned?
>


Following the principle of copying JavaScript types, would mean using a
signed 64 bit integer with millisecond resolution with an epoch of
1970-01-01T00:00:00Z

I think it would actually be a good idea to also support the Windows .NET
100 nanosecond resolution in JSON-D. This has a base of Jan 1 0001 in the
Gregorian calendar and is always positive:

The value of this property is the number of 100-nanosecond intervals that
have elapsed since 12:00 A.M., January 1, 0001.




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

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

<div dir=3D"ltr">On Mon, Jun 10, 2013 at 9:55 PM, Nico Williams <span dir=
=3D"ltr">&lt;<a href=3D"mailto:nico@cryptonector.com" target=3D"_blank">nic=
o@cryptonector.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-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div class=3D"im">On Mon, Jun 10, 2013 at 8:21 PM, Phillip=
 Hallam-Baker &lt;<a href=3D"mailto:hallam@gmail.com">hallam@gmail.com</a>&=
gt; wrote:<br>

</div><div class=3D"im">&gt; The basic idea here is to minimize the impact =
of adding the additional<br>
&gt; encodings when using them in a Web Service. All valid JSON encodings a=
re<br>
&gt; also valid JSON-B encodings. begin-object &#39;{&#39; and begin-array =
&#39;[&#39; have the<br>
&gt; same code values in each. All the new codes are in the range x80-xFF s=
o as<br>
&gt; to avoid conflicts.<br>
<br>
</div>Using byte values that don&#39;t appear in UTF-8 might help w.r.t.<br=
>
auto-detection. =A0You might want to have a byte value that&#39;s akin to<b=
r>
whitespace, a value that all top-level values in your encoding can<br>
start with, that way there&#39;s no ambiguity.</blockquote><div><br></div><=
div style>Perhaps you could propose a preamble sequence?</div><div><br></di=
v><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-le=
ft-style:solid;padding-left:1ex">
<div class=3D"im">
&gt; I did not define a date type. This is tempting but probably a bad idea=
 as<br>
&gt; there is really no agreement on what the representation of time should=
 be.<br>
&gt; If a choice was to be forced it should probably be to specify a time q=
uanta<br>
&gt; as 100 nanosecond units as per Windows since that allows a 64 bit valu=
e to<br>
&gt; represent approx. 58,000 years and thus be Y10K compliant.<br>
<br>
</div>That representation works for me (with the epoch<br>
1601-01-01T00:00:00Z). =A0Signed or unsigned?<br></blockquote></div><div cl=
ass=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><br></div>Followin=
g the principle of copying JavaScript types, would mean using a signed 64 b=
it integer with millisecond resolution with an epoch of 1970-01-01T00:00:00=
Z</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">I think it =
would actually be a good idea to also support the Windows .NET 100 nanoseco=
nd resolution in JSON-D. This has a base of Jan 1 0001 in the Gregorian cal=
endar and is always positive:<br clear=3D"all">
<div><br></div><div><span style=3D"color:rgb(42,42,42);font-family:&#39;Seg=
oe UI&#39;,&#39;Lucida Grande&#39;,Verdana,Arial,Helvetica,sans-serif;font-=
size:13px;line-height:18px">The value of this property is the number of 100=
-nanosecond intervals that have elapsed since 12:00 A.M., January 1, 0001.<=
/span><br>
</div><div><br></div><div><br></div><div><br></div><div><br></div>-- <br>We=
bsite: <a href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br>
</div></div>

--001a11c2412c774ebf04ded7701f--

From dret@berkeley.edu  Tue Jun 11 15:59:43 2013
Return-Path: <dret@berkeley.edu>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A62321F9989 for <apps-discuss@ietfa.amsl.com>; Tue, 11 Jun 2013 15:59:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t2XR2WCoqLXW for <apps-discuss@ietfa.amsl.com>; Tue, 11 Jun 2013 15:59:38 -0700 (PDT)
Received: from cm02fe.IST.Berkeley.EDU (cm02fe.IST.Berkeley.EDU [169.229.218.143]) by ietfa.amsl.com (Postfix) with ESMTP id 7656921F9984 for <apps-discuss@ietf.org>; Tue, 11 Jun 2013 15:59:38 -0700 (PDT)
Received: from mobile-166-137-185-191.mycingular.net ([166.137.185.191] helo=dretpro.local) by cm02fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from <dret@berkeley.edu>) id 1UmXXM-0005cS-9d; Tue, 11 Jun 2013 15:59:38 -0700
Message-ID: <51B7ABD8.6070809@berkeley.edu>
Date: Tue, 11 Jun 2013 15:59:36 -0700
From: Erik Wilde <dret@berkeley.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: "apps-discuss@ietf.org application-layer protocols" <apps-discuss@ietf.org>, REST-Discuss <rest-discuss@yahoogroups.com>
References: <20130611224838.5955.72969.idtracker@ietfa.amsl.com>
In-Reply-To: <20130611224838.5955.72969.idtracker@ietfa.amsl.com>
X-Forwarded-Message-Id: <20130611224838.5955.72969.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [apps-discuss] Fwd: New Version Notification for draft-wilde-home-xml-01.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 11 Jun 2013 22:59:43 -0000

FYI.


-------- Original Message --------
Subject: New Version Notification for draft-wilde-home-xml-01.txt
Date: Tue, 11 Jun 2013 15:48:38 -0700
From: internet-drafts@ietf.org
To: Erik Wilde <erik.wilde@emc.com>, Erik Wilde <dret@berkeley.edu>


A new version of I-D, draft-wilde-home-xml-01.txt
has been successfully submitted by Erik Wilde and posted to the
IETF repository.

Filename:	 draft-wilde-home-xml
Revision:	 01
Title:		 Home Documents for HTTP Services: XML Syntax
Creation date:	 2013-06-11
Group:		 Individual Submission
Number of pages: 11
URL: 
http://www.ietf.org/internet-drafts/draft-wilde-home-xml-01.txt
Status:          http://datatracker.ietf.org/doc/draft-wilde-home-xml
Htmlized:        http://tools.ietf.org/html/draft-wilde-home-xml-01
Diff:            http://www.ietf.org/rfcdiff?url2=draft-wilde-home-xml-01

Abstract:
    The current draft for HTTP Home Documents provides a JSON syntax
    only.  This draft provides an XML syntax for the same underlying data
    model, so that the concept of HTTP Home Documents can be consistently
    exposed in both JSON- and XML-based HTTP services.

Note to Readers

    Please discuss this draft on the apps-discuss mailing list [7].
    Online access to all versions and files is available on github [8].

 



The IETF Secretariat

From dret@berkeley.edu  Tue Jun 11 16:11:50 2013
Return-Path: <dret@berkeley.edu>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83C7321F9B86 for <apps-discuss@ietfa.amsl.com>; Tue, 11 Jun 2013 16:11:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2m0031gqx58 for <apps-discuss@ietfa.amsl.com>; Tue, 11 Jun 2013 16:11:46 -0700 (PDT)
Received: from cm02fe.IST.Berkeley.EDU (cm02fe.IST.Berkeley.EDU [169.229.218.143]) by ietfa.amsl.com (Postfix) with ESMTP id 61F5821F9B77 for <apps-discuss@ietf.org>; Tue, 11 Jun 2013 16:11:46 -0700 (PDT)
Received: from mobile-166-137-185-191.mycingular.net ([166.137.185.191] helo=dretpro.local) by cm02fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from <dret@berkeley.edu>) id 1UmXj6-00025x-9K; Tue, 11 Jun 2013 16:11:46 -0700
Message-ID: <51B7AEAF.20404@berkeley.edu>
Date: Tue, 11 Jun 2013 16:11:43 -0700
From: Erik Wilde <dret@berkeley.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: IETF Apps Discuss <apps-discuss@ietf.org>
References: <20130610033804.19451.29465.idtracker@ietfa.amsl.com> <E6062DBC-CD7B-47CA-A6F0-5E7D64C0DB55@mnot.net>
In-Reply-To: <E6062DBC-CD7B-47CA-A6F0-5E7D64C0DB55@mnot.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Mark Nottingham <mnot@mnot.net>, REST-Discuss <rest-discuss@yahoogroups.com>
Subject: Re: [apps-discuss] Fwd: New Version Notification for draft-nottingham-link-hint-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 11 Jun 2013 23:11:50 -0000

On 2013-06-09 20:38 , Mark Nottingham wrote:
>> Filename:	 draft-nottingham-link-hint
>> Revision:	 00
>> Title:		 HTTP Link Hints
>> Creation date:	 2013-06-10
>> Group:		 Individual Submission
>> Number of pages: 12
>> URL:             http://www.ietf.org/internet-drafts/draft-nottingham-link-hint-00.txt
>> Status:          http://datatracker.ietf.org/doc/draft-nottingham-link-hint
>> Htmlized:        http://tools.ietf.org/html/draft-nottingham-link-hint-00
>> Abstract:
>>    This memo specifies "HTTP Link Hints", a mechanism for annotating Web
>>    links to HTTP(S) resources with information that otherwise might be
>>    discovered by interacting with them.

generally speaking, i think this might become a very useful way how 
various services can expose more helpful links to clients, if they 
choose to do so, and if the clients are interesting in taking that 
information into account.

but i have one question about the general registry model: the current 
draft says that hints MUST have a name (very reasonable, of course), but 
also that hints MUST have their data model being defined in JSON.

http://tools.ietf.org/html/draft-nottingham-link-hint-00#section-5.1

living in a world where we have JSON services, XML services, and RDF 
services, it seems that hard-coding a specific language data model into 
such a spec (without constraining it in any way) will limit the utility 
of such a registry. for example, in the Home Document draft, which is 
the original source of the link hint idea, the hints were hard-coded 
with very constrained data models. this made it relatively easy to 
expose them in a different syntax (in the XML Home Document draft):

http://tools.ietf.org/html/draft-wilde-home-xml-01#page-4

without getting too much into the details of this specific registry: 
what are the best practices about allowing/controlling language 
dependencies in registries? personally, i would feel more comfortable 
with having a registry that is of equal value to people regardless of 
their implementation language, but then again that means that the 
registry itself must define a "mini-language" of its own.

any pointers to similar situations and how they were resolved would be 
greatly appreciated. thanks and cheers,

dret.

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

From ietf-secretariat-reply@ietf.org  Tue Jun 11 19:26:57 2013
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 (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00A2121F9BAD for <apps-discuss@ietfa.amsl.com>; Tue, 11 Jun 2013 19:26:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.423
X-Spam-Level: 
X-Spam-Status: No, score=-101.423 tagged_above=-999 required=5 tests=[AWL=-1.042, BAYES_00=-2.599, NO_RELAYS=-0.001, TVD_SPACE_RATIO=2.219, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wol1C2DbcRZ1; Tue, 11 Jun 2013 19:26:56 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5327221F9BAA; Tue, 11 Jun 2013 19:26:56 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
To: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-rfc5451bis@tools.ietf.org, sm+ietf@elandsys.com, apps-discuss@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.51.p2
Message-ID: <20130612022656.3496.93166.idtracker@ietfa.amsl.com>
Date: Tue, 11 Jun 2013 19:26:56 -0700
From: IETF Secretariat <ietf-secretariat-reply@ietf.org>
Subject: [apps-discuss] ID Tracker State Update Notice: <draft-ietf-appsawg-rfc5451bis-06.txt>
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 12 Jun 2013 02:26:57 -0000

State changed to AD Evaluation::Revised I-D Needed from AD Evaluation
ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-rfc5451b=
is/


From internet-drafts@ietf.org  Wed Jun 12 23:42:43 2013
Return-Path: <internet-drafts@ietf.org>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CBDA21F99EF; Wed, 12 Jun 2013 23:42:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.51
X-Spam-Level: 
X-Spam-Status: No, score=-102.51 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pominG6SQ6N2; Wed, 12 Jun 2013 23:42:42 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D69621F9A1E; Wed, 12 Jun 2013 23:42:42 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.51.p2
Message-ID: <20130613064242.8211.59399.idtracker@ietfa.amsl.com>
Date: Wed, 12 Jun 2013 23:42:42 -0700
Cc: apps-discuss@ietf.org
Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc5451bis-07.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 13 Jun 2013 06:42:43 -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           : Message Header Field for Indicating Message Authenticati=
on Status
	Author(s)       : Murray S. Kucherawy
	Filename        : draft-ietf-appsawg-rfc5451bis-07.txt
	Pages           : 47
	Date            : 2013-06-12

Abstract:
   This document specifies a header field for use with electronic mail
   messages to indicate the results of message authentication efforts.
   Any receiver-side software, such as mail filters or Mail User Agents
   (MUAs), can use this header field to relay that information in a
   convenient and meaningful way to users, or make sorting and filtering
   decisions.

   This document is a candidate for Internet Standard status.  [RFC
   Editor: Please delete this notation, as I imagine it will be
   indicated some other way.]


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-appsawg-rfc5451bis

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-appsawg-rfc5451bis-07

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-rfc5451bis-07


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From internet-drafts@ietf.org  Wed Jun 12 23:42:43 2013
Return-Path: <internet-drafts@ietf.org>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5BF921F99FE for <apps-discuss@ietfa.amsl.com>; Wed, 12 Jun 2013 23:42:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.511
X-Spam-Level: 
X-Spam-Status: No, score=-102.511 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fLaX6BnjneS6; Wed, 12 Jun 2013 23:42:43 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BD45721F9A21; Wed, 12 Jun 2013 23:42:42 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-rfc5451bis@tools.ietf.org, sm+ietf@elandsys.com, apps-discuss@ietf.org, barryleiba@computer.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.51.p2
Message-ID: <20130613064242.8211.24345.idtracker@ietfa.amsl.com>
Date: Wed, 12 Jun 2013 23:42:42 -0700
Subject: [apps-discuss] New Version Notification - draft-ietf-appsawg-rfc5451bis-07.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 13 Jun 2013 06:42:43 -0000

A new version (-07) has been submitted for draft-ietf-appsawg-rfc5451bis:
http://www.ietf.org/internet-drafts/draft-ietf-appsawg-rfc5451bis-07.txt

Sub state has been changed to AD Followup from Revised ID Needed


The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-appsawg-rfc5451bis/

Diff from previous version:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-rfc5451bis-07

IETF Secretariat.


From ietf-secretariat-reply@ietf.org  Thu Jun 13 00:50:18 2013
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 (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0487321F9A3F for <apps-discuss@ietfa.amsl.com>; Thu, 13 Jun 2013 00:50:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.424
X-Spam-Level: 
X-Spam-Status: No, score=-101.424 tagged_above=-999 required=5 tests=[AWL=-1.043, BAYES_00=-2.599, NO_RELAYS=-0.001, TVD_SPACE_RATIO=2.219, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTcXMjJDgVSi; Thu, 13 Jun 2013 00:50:17 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D97D21F8F6E; Thu, 13 Jun 2013 00:50:11 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
To: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-rfc5451bis@tools.ietf.org, sm+ietf@elandsys.com, apps-discuss@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.51.p2
Message-ID: <20130613075011.11545.73964.idtracker@ietfa.amsl.com>
Date: Thu, 13 Jun 2013 00:50:11 -0700
From: IETF Secretariat <ietf-secretariat-reply@ietf.org>
Subject: [apps-discuss] ID Tracker State Update Notice: <draft-ietf-appsawg-rfc5451bis-07.txt>
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 13 Jun 2013 07:50:18 -0000

State changed to Last Call Requested from AD Evaluation::AD Followup
ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-rfc5451b=
is/


From Bert.Greevenbosch@huawei.com  Thu Jun 13 01:06:33 2013
Return-Path: <Bert.Greevenbosch@huawei.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D59221F9A6A; Thu, 13 Jun 2013 01:06:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.782
X-Spam-Level: 
X-Spam-Status: No, score=-4.782 tagged_above=-999 required=5 tests=[AWL=1.817,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-N+B-t39RwR; Thu, 13 Jun 2013 01:06:28 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC4921F9A75; Thu, 13 Jun 2013 01:06:26 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASK38001; Thu, 13 Jun 2013 08:06:20 +0000 (GMT)
Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 13 Jun 2013 09:06:04 +0100
Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 13 Jun 2013 09:06:09 +0100
Received: from szxeml558-mbx.china.huawei.com ([169.254.7.152]) by szxeml412-hub.china.huawei.com ([10.82.67.91]) with mapi id 14.01.0323.007; Thu, 13 Jun 2013 16:06:05 +0800
From: Bert Greevenbosch <Bert.Greevenbosch@huawei.com>
To: "apps-discuss@ietf.org" <apps-discuss@ietf.org>, "draft-ietf-avtcore-avp-codecs.all@tools.ietf.org" <draft-ietf-avtcore-avp-codecs.all@tools.ietf.org>, "iesg@ietf.org" <iesg@ietf.org>
Thread-Topic: Applications Area Directorate Review of draft-ietf-avtcore-avp-codecs-02
Thread-Index: Ac5oDNerh7dhbvRBRF2N44qjOGB5Zw==
Date: Thu, 13 Jun 2013 08:06:04 +0000
Message-ID: <46A1DF3F04371240B504290A071B4DB63D77C5C7@szxeml558-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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: [apps-discuss] Applications Area Directorate Review of draft-ietf-avtcore-avp-codecs-02
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 13 Jun 2013 08:06:33 -0000

Document: draft-ietf-avtcore-avp-codecs-02
Title: RTP/AVP codecs
Reviewer: Bert Greevenbosch
Review Date: 13 June 2013
IETF Last Call Date: [include if known]
IESG Telechat Date: [include if known]
Summary: No major issues, only editorials.

Major Issues:

none

Minor Issues:

(1) "Some environments REQUIRE support for PCMU.". The key word "REQUIRE" i=
s not defined in RFC 2119. RFC 2119 defines "REQUIRED", which IMHO should b=
e used differently. Maybe a better phrasing would be: "Some environments MA=
Y require support for PCMU.".

Nits:

(2) Section 3 contains the original text from RFC 3551. However, this is a =
bit confusing when reading it the first time; when you miss that it is the =
original text from RFC 3551, it seems inconsistent with the introduction.

Maybe it is good to split section 3 into three sections:
"3.1 original text from RFC 3551"
"3.2 updates"
"3.3 resulting text"

The header of section 3 could be "Updates to RFC 3551 section 6". Introduct=
ory text could be

"Section 6 of RFC 3551 is hereby updated as set forth below."

Alternatively one could put all into a single section 3 (no subsections). G=
oal is that it should be clearer what is the original text, what is the pro=
posed change and what is the result.=20

From iesg-secretary@ietf.org  Thu Jun 13 06:43:52 2013
Return-Path: <iesg-secretary@ietf.org>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2EE221F9A95; Thu, 13 Jun 2013 06:43:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.534
X-Spam-Level: 
X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ojjimVXmC-yF; Thu, 13 Jun 2013 06:43:52 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 36D9B21F9A2C; Thu, 13 Jun 2013 06:43:52 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 4.51.p2
Sender: <iesg-secretary@ietf.org>
Message-ID: <20130613134352.19092.1425.idtracker@ietfa.amsl.com>
Date: Thu, 13 Jun 2013 06:43:52 -0700
Cc: apps-discuss@ietf.org
Subject: [apps-discuss] Last Call: <draft-ietf-appsawg-rfc5451bis-07.txt> (Message Header	Field for Indicating Message Authentication Status) to Internet	Standard
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: ietf@ietf.org
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, 13 Jun 2013 13:43:52 -0000

The IESG has received a request from the Applications Area Working Group
WG (appsawg) to consider the following document:
- 'Message Header Field for Indicating Message Authentication Status'
  <draft-ietf-appsawg-rfc5451bis-07.txt> as Internet Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-06-27. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


   This document specifies a header field for use with electronic mail
   messages to indicate the results of message authentication efforts.
   Any receiver-side software, such as mail filters or Mail User Agents
   (MUAs), can use this header field to relay that information in a
   convenient and meaningful way to users, or make sorting and filtering
   decisions.

   This document is a candidate for Internet Standard status.  [RFC
   Editor: Please delete this notation, as I imagine it will be
   indicated some other way.]




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-appsawg-rfc5451bis/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-appsawg-rfc5451bis/ballot/

Reviewers should particularly note the "downref" information in
Section 7.1 of the document.

No IPR declarations have been submitted directly on this I-D.



From ietf-secretariat-reply@ietf.org  Thu Jun 13 06:43:54 2013
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 (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4265921F9AD3 for <apps-discuss@ietfa.amsl.com>; Thu, 13 Jun 2013 06:43:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.535
X-Spam-Level: 
X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NdjD5IO9-4AA; Thu, 13 Jun 2013 06:43:53 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ACF321F9A9F; Thu, 13 Jun 2013 06:43:53 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
To: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-rfc5451bis@tools.ietf.org, sm+ietf@elandsys.com, apps-discuss@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.51.p2
Message-ID: <20130613134353.19092.44876.idtracker@ietfa.amsl.com>
Date: Thu, 13 Jun 2013 06:43:53 -0700
From: IETF Secretariat <ietf-secretariat-reply@ietf.org>
Subject: [apps-discuss] ID Tracker State Update Notice: <draft-ietf-appsawg-rfc5451bis-07.txt>
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 13 Jun 2013 13:43:54 -0000

Last call has been made for draft-ietf-appsawg-rfc5451bis and state has bee=
n changed to In Last Call
ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-rfc5451b=
is/


From derhoermi@gmx.net  Thu Jun 13 07:11:04 2013
Return-Path: <derhoermi@gmx.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC34B21F9A31 for <apps-discuss@ietfa.amsl.com>; Thu, 13 Jun 2013 07:11:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.544
X-Spam-Level: 
X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MeB3Ophc+KSu for <apps-discuss@ietfa.amsl.com>; Thu, 13 Jun 2013 07:11:00 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 40E7721F9951 for <apps-discuss@ietf.org>; Thu, 13 Jun 2013 07:11:00 -0700 (PDT)
Received: from mailout-de.gmx.net ([10.1.76.24]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0LuZtm-1UMYpW418C-00zqvD for <apps-discuss@ietf.org>; Thu, 13 Jun 2013 16:10:58 +0200
Received: (qmail invoked by alias); 13 Jun 2013 14:10:58 -0000
Received: from p5B233947.dip0.t-ipconnect.de (EHLO netb.Speedport_W_700V) [91.35.57.71] by mail.gmx.net (mp024) with SMTP; 13 Jun 2013 16:10:58 +0200
X-Authenticated: #723575
X-Provags-ID: V01U2FsdGVkX196dgw5+QR65jhLLlnU02aftMTkDiqyoDgAxTxAMS 5/gBmiBvYsd+pV
From: Bjoern Hoehrmann <derhoermi@gmx.net>
To: apps-discuss@ietf.org
Date: Thu, 13 Jun 2013 16:11:00 +0200
Message-ID: <c0kjr8dihl1l14lt6q0gq83d8qkpj8lqki@hive.bjoern.hoehrmann.de>
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
Subject: [apps-discuss] Editorial comments on draft-ietf-appsawg-rfc5451bis-07
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 13 Jun 2013 14:11:04 -0000

Hi,

  In http://tools.ietf.org/html/draft-ietf-appsawg-rfc5451bis-07 I think
it would be helpful to spell out the name of the header field in the ab-
stract. It should probably also be in the Introduction.

There should be syntax examples near the ABNF grammar for the header. As
it is, examples are only in Appendix C, so you don't get to see any use
of the header until after you read through the Acknowledgements and Re-
ferences.

The "[other names]" in Appendix A is probably not intentional.

regards,
-- 
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 Bert.Greevenbosch@huawei.com  Thu Jun 13 23:12:24 2013
Return-Path: <Bert.Greevenbosch@huawei.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C6E421F9C02; Thu, 13 Jun 2013 23:12:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.127
X-Spam-Level: 
X-Spam-Status: No, score=-5.127 tagged_above=-999 required=5 tests=[AWL=1.472,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f5O8lWjyPTSH; Thu, 13 Jun 2013 23:12:18 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C9BB821F9BC3; Thu, 13 Jun 2013 23:12:15 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASL17974; Fri, 14 Jun 2013 06:12:13 +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.1.323.7; Fri, 14 Jun 2013 07:11:52 +0100
Received: from SZXEML416-HUB.china.huawei.com (10.82.67.155) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 14 Jun 2013 14:12:09 +0800
Received: from szxeml558-mbx.china.huawei.com ([169.254.7.152]) by szxeml416-hub.china.huawei.com ([10.82.67.155]) with mapi id 14.01.0323.007; Fri, 14 Jun 2013 14:12:02 +0800
From: Bert Greevenbosch <Bert.Greevenbosch@huawei.com>
To: "apps-discuss@ietf.org" <apps-discuss@ietf.org>, "draft-ietf-payload-vp8.all@tools.ietf.org" <draft-ietf-payload-vp8.all@tools.ietf.org>, "iesg@ietf.org" <iesg@ietf.org>
Thread-Topic: Applications Area Directorate Review of draft-ietf-payload-vp8-08
Thread-Index: AQHOaMYV9R5yaz6io0a7dByn7mnSLw==
Date: Fri, 14 Jun 2013 06:12:02 +0000
Message-ID: <46A1DF3F04371240B504290A071B4DB63D77CED7@szxeml558-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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: [apps-discuss] Applications Area Directorate Review of draft-ietf-payload-vp8-08
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 14 Jun 2013 06:12:24 -0000

Document: draft-ietf-payload-vp8-08
Title: RTP Payload Format for VP8 Video
Reviewer: Bert Greevenbosch
Review Date: 14 June 2013
Summary: Some minor issues and nits.

Major Issues:

none

Minor Issues:

(1) P.10: "KEYIDX: ... KEYIDX SHOULD start on a random number"
-> Why is this recommended?
=20
(2) P.10: "In the case of a key frame the remaining 7 octets are considered=
 to be part of the remaining payload in this RTP format."
-> Is this different from the case of an interframe? Where lies the differe=
nce?

(3) P.10: "Note that the header is present only in packets which have the S=
 bit equal to one and the PartID equal to zero in the payload descriptor. S=
ubsequent packets for the same frame do not carry the payload header."
-> What happens if the packet with the payload header was lost?
-> Is the rest of the partition still usable or is it completely useless?=20
-> If it still can be usable, wouldn't it need the size information?

(4) The specification uses dynamic RTP payload numbers. This can be deduced=
 from example 6.2.1.1 on P.23. However, it would be good to say this explic=
itly.

Nits:

(5) P.9: "M: ... If set the PictureID field MUST contain 16 bits else it MU=
ST contain 8 bits including this MSB, see PictureID."
-> This is unclear in figure 2.

(6) P.9: "TID: ... The TID/KEYIDX octet MUST be present when either the T b=
it or the K bit or both are equal to 1, and MUST NOT be present otherwise."
P.9: "Y: ... The TID/KEYIDX octet MUST be present when either the T bit or =
the K bit or both are equal to 1, and MUST NOT be present otherwise."
P.10: "KEYIDX: ... The TID/KEYIDX octet MUST be present when either the T b=
it or the K bit or both are equal to 1, and MUST NOT be present otherwise."
-> These three sentences are superfluous in the light of
P.8: "T: TID present. When set to one, the OPTIONAL TID/KEYID octet MUST be=
 present. ... If neither T nor K is set to one, the TID/KEYIDX octet MUST N=
OT be present" and
P.8: "K: KEYIDX present. When set to one, the OPTIONAL TID/KEYIDX octet MUS=
T be present."

(7) In section 4.5.3, it would be good to indicate how L depends on size N.

(8) I think in which order the fragments need to be re-assembled depends on=
 the RTP sequence number. Should that be stated somewhere in the example in=
 section 4.5.4?

From Claudio.Allocchio@garr.it  Sat Jun 15 06:15:13 2013
Return-Path: <Claudio.Allocchio@garr.it>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D132821F9C3F for <apps-discuss@ietfa.amsl.com>; Sat, 15 Jun 2013 06:15:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.719
X-Spam-Level: 
X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iDuXUuULBxEo for <apps-discuss@ietfa.amsl.com>; Sat, 15 Jun 2013 06:15:09 -0700 (PDT)
Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [193.206.158.29]) by ietfa.amsl.com (Postfix) with ESMTP id 17D6521F9A7E for <apps-discuss@ietf.org>; Sat, 15 Jun 2013 06:15:08 -0700 (PDT)
Received: internal info suppressed
Date: Sat, 15 Jun 2013 15:14:59 +0200 (CEST)
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.1306151514400.22481@mac-allocchio3.garrtest.units.it>
User-Agent: Alpine 2.02 (OSX 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="0-715880594-1371302100=:22481"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=garr.it; s=cyrus; t=1371302100; bh=MfgI3UoYS4Jcxv9FG1I4RRVTZIyzcZU2qBfs/q9WyKc=; h=Date:From:To:Subject; b=GZqUQpqhJytX55YyzK3fEHOrJlfH6ugC2T/kNuXO+HDiVEEnQSBh0ZISFlXhvCOm/ xWAgIJ4EA9LDF7RdpTmeME1hh3lYuUyR4407mt18aoJjFpVgDwUtWfVfTLiDc88Zwv Gt0tPFARIgJE1GRuCnc4VdM3bYROnCFRnart1v4g=
Subject: [apps-discuss] Apps DIr May 2013 reviews
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 15 Jun 2013 13:15:14 -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-715880594-1371302100=:22481
Content-Type: TEXT/PLAIN; format=flowed; charset=UTF-8
Content-Transfer-Encoding: 8BIT


during May 2013 we had the following 7 drafts reviwed by AppsDir:

draft-ietf-cuss-sip-uui-10                      Peter Saint-Andre
draft-ietf-nfsv4-rfc3530bis-dot-x-17            Joseph Yee
draft-ietf-softwire-public-4over6-09            Xuan He, S. Moonesamy
draft-ietf-6man-impatient-nud-06                Murray S. Kucherawy
​draft-saintandre-impp-call-info-02              Salvatore Loreto
​draft-ietf-dhc-triggered-reconfigure-05         Claudio Allocchio
draft-sparks-genarea-imaparch-06                Martin Dürst

and the total count since 2013 is 59.

thanks to all reviewrs for their precious work!

------------------------------------------------------------------------------
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-715880594-1371302100=:22481--

From jpalme@dsv.su.se  Sat Jun 15 09:52:54 2013
Return-Path: <jpalme@dsv.su.se>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AAC221F9DD8 for <apps-discuss@ietfa.amsl.com>; Sat, 15 Jun 2013 09:52:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.159
X-Spam-Level: *
X-Spam-Status: No, score=1.159 tagged_above=-999 required=5 tests=[ADVANCE_FEE_2=1.234, BAYES_20=-0.74, HELO_EQ_SE=0.35, SARE_MILLIONSOF=0.315]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HamJBFlNuhS9 for <apps-discuss@ietfa.amsl.com>; Sat, 15 Jun 2013 09:52:50 -0700 (PDT)
Received: from smtprelay-b31.telenor.se (smtprelay-b31.telenor.se [213.150.131.20]) by ietfa.amsl.com (Postfix) with ESMTP id C37D621F9DC9 for <apps-discuss@ietf.org>; Sat, 15 Jun 2013 09:52:49 -0700 (PDT)
Received: from ipb5.telenor.se (ipb5.telenor.se [195.54.127.168]) by smtprelay-b31.telenor.se (Postfix) with ESMTP id D0954C28D for <apps-discuss@ietf.org>; Sat, 15 Jun 2013 18:52:47 +0200 (CEST)
X-SENDER-IP: [85.224.105.20]
X-LISTENER: [smtp.bredband.net]
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AmA2AAubvFFV4GkUPGdsb2JhbAADCjcMCoM6qxiFaY4IAwGBGgIDAQEBATiCVAQBAQEBAgEBAQE3MAEBAggICzYCGSccFAYTG4UuCIIfGBKnJ5F7jXwDCAYDBgFTZgqCdWEDkS+SNIgygW8
X-IronPort-AV: E=Sophos;i="4.87,872,1363129200"; d="scan'208";a="344969542"
Received: from c-1469e055.022-17-73746f16.cust.bredbandsbolaget.se (HELO [192.168.0.103]) ([85.224.105.20]) by ipb5.telenor.se with ESMTP; 15 Jun 2013 18:52:47 +0200
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1085)
From: Jacob Palme <jpalme@dsv.su.se>
In-Reply-To: <p06240800ccc189b2c3ff@[192.168.0.101]>
Date: Sat, 15 Jun 2013 18:52:46 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <43892743-D4CD-4137-B3BD-BCA321D9CE41@dsv.su.se>
References: <p06240800ccc189b2c3ff@[192.168.0.101]>
To: General discussion of application-layer protocols <apps-discuss@ietf.org>
X-Mailer: Apple Mail (2.1085)
Subject: [apps-discuss] Is e-mail going to die?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 15 Jun 2013 16:52:54 -0000

I wrote a message in November 2012 which is quoted at the end of=20
this message.

One thing I am noting since then is that other message systems=20
are more and more used instead of email.

Examples of such alternative messaging systems are SMS, Facebook=20
and Kik.

Large companies more and more are telling people who want to=20
communicate with them to use a special web page instead of e-mail.=20
Banks only allow me to communicate through a message system where=20
I first have to log in to my bank account before sending and=20
receiving messages to and from my bank. Other companies may do the
same.

It would not surprise me if email will die out, or rather will be less
and less used as alternative messaging systems will replace email,
so that in a few years most internet messaging will be done using
another protocol than email.

The reason why email may die out, is that email has not succeeded
to ensure that I get all messages I want, but not a large number
of unwanted messages (spam). Email is therefore not percieved as=20
reliable. Some other network will be percieved as more reliable.

There are anti-spam systems like SpamSieve and SpamFire, but they
have the problem that sometimes wanted messages are wrongly filtered
out. And to manually read the mailbox containing all messages which
have been filtered out, will mean that I do not get the advantage
with spam filters - I have to scan through a list of all spam
messages, and this is what the spam filters are meant to avoid.

Even though there are technical problems, I still believe that
email's opportunity to succeed is to replace email into a system
where the sender pays a fee, say $0.10 per recipient, for sending
messages. The old, unpaid system can continue to live in parallel
to the new system.

This new e-mail network should use all the existing standards,
technology and client and server software which e-mail is using
today. That would be a huge advantage compared to competing
systems like SMS, Facebook and Kik. I would enter my ordinary email
client, and first see all messages for which the sender paid a
fee, and then, if I have time, also see unpaid email. Probably
I would sort the old, unsafe mail into an alternative mailbox
than my ordinary inbox.

The new mail network will probably not get much spam, because spammers
will not be willing to pay $0.10 per recipient for sending messages.
And since spam filters are not needed for messages arriving through
the new network, there is no risk that messages which are important
to me will be filtered out by mistake.

Certainly there are technical problems with such a new email network.
For example handling of mailing lists - you should not have to pay
for every member of a mailing list when you post to the list.
Technical problems have to be overcome.

But having more and more messages sent through alternative networks
like SMS, Kik and Facebook is not a happy future. We who have spent
a lot of effort into making email into a good standard will not be
happy if our effort has been in vain, and if some competing system
will replace e-mail as the major messaging system on the internet.

On 8 nov 2012, at 17.58, Jacob Palme wrote:

> Talk to ordinary people, people who are not technical experts, as we =
are in this mailing list. Ask them what is good and bad about the =
Internet. You will find that most people will answer that spam control =
is IETF's largest failure.
>=20
> IETF started as a network for university people. They wanted a network =
to make interconnection between university and research people easy. =
They had no expectation that these people would misuse the network such =
as spammers do today.
>=20
> The root of the problem is that the cost of seinding e-mail is so low. =
You just submit your message, no fee, and a network of SMTP servers is =
eager and willing to forward your message to thousands or millions of =
recipients. We even get messages which ask us to buy software which =
makes it easy to forward your message to many recipients. Companies =
collect e-mail addresses from various sources and sell lists of millions =
of e-mail addresses for a low cost.
>=20
> The only solution which works is to make it more expensive to send =
messages. IETF should establish a new network, independent of the =
present e-mail forwarding network, with separate mail servers (SMTP, =
POP, IMAP servers) using new, separate ports for spam-free e-mail. The =
main difference is that there should be a charge, perhaps 0.10 dollars, =
to submit e-mail. 0.10 dollars per recipient when you submit your =
message. The new network should use cryptographic methods to stop =
bandits from using it without paying this fee. The money collected from =
paying clients should use to further recognize and stop any spammers =
which might get into the new network. But the important thing is not to =
detech and stop spammers - this has been tried for many years and thus =
not work. The important thing is the fee per recipient for submitting =
messages into the new network. Spammers will not be willing to pay this =
cost. Their business model is built on the idea that you can for a =
negligible cost submit mail to millions of recipients. Their business =
model will collapse if they have to pay for submitting messages.
>=20
> I expect that recipients will be happy to recieve messages from the =
new spam-free network.
>=20
> There are, of course, problems with this solution.
>=20
> One large problem is mailing lists. Mailing lists, such as the one to =
which I am sending this message, will be too costly if the list =
maintainer has to pay a fee for every recipient. And people who submit =
messages to mailing list may not be willing to pay 0.10 dollars for =
every member of the maling list. The solution will have to allow =
exceptions from the 0.10 dollars/message for messages coming from =
mailing lists. There should be some kind of authority, established by =
IETF, which identifies serious mailing lists which are allowed to =
forward messages to members of mailing lists. However, the 0.10 fee will =
pay for the cost of running such an authority body.
>=20
> Another possible problem might be spammers who are willing to pay 0.10 =
dollars/recipient because they are able to identify recipients who will =
buy the product they are selling, so that the 0.10 dollar is acceptable =
cost. However, if a message is so interesting to recipients that senders =
are willing to pay 0.10 dollars per recipient for the sales message, =
then the recipients may be willing to read this spam and not regard it =
as spam.
>=20
> The new network should run in parallel to the present mail networks. =
Protocols should be mostly the same as those used today for the mail =
networks used today. Recipients will have to modify their POP or IMAP =
client so that it collects mail from two networks, the old spam-allowing =
network and the new spam-safe network. Mail reading clients will either =
put incoming messages into two "In" folders, one for the new spam-free =
mail and another for the old spam-containing net. Or alternately mark =
messages with different colors for messages from the spam-free and =
spam-containing net. The result may be that most people will not want to =
download any message from the old network. But if that is the case, it =
just shows the value of establishing a spam-free network.
>=20
> The establishing of a spam-free network, based on a fee per recipient =
for sending messages, will not be entirely easy. Some people may not be =
willing to pay for sending messages. Especially senders of private mail =
may not be willing to pay. The running of two parallel mail networks, =
one for spam-safe and one for non-spam-safe messages, will be a major =
effort for the IETF. But the gain is so large, and many people will be =
so happy for getting spam-free messages, that this is an effort which =
will cause people to thank IETF for the effort of establishing this new =
mail network.
>=20
> The income of 0.10 dollars per recipient will allow paying the cost of =
running the new spam-safe mail network.
> --=20
> Jacob Palme <jpalme@dsv.su.se>, university professor emeritus
> for more info see URL: http://www.dsv.su.se/jpalme/
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss

--
Professor Jacob Palme <jpalme@dsv.su.se> (Stockholm University and KTH)
for more info see URL: http://www.dsv.su.se/jpalme/






From tss@iki.fi  Sat Jun 15 11:59:27 2013
Return-Path: <tss@iki.fi>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5544621F9E09 for <apps-discuss@ietfa.amsl.com>; Sat, 15 Jun 2013 11:59:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.449
X-Spam-Level: 
X-Spam-Status: No, score=-110.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Nr1kFGTtfHM for <apps-discuss@ietfa.amsl.com>; Sat, 15 Jun 2013 11:59:22 -0700 (PDT)
Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 01CDC21F9E07 for <apps-discuss@ietf.org>; Sat, 15 Jun 2013 11:59:22 -0700 (PDT)
Received: from [192.168.10.100] (cs181255018.pp.htv.fi [82.181.255.18]) by dovecot.org (Postfix) with ESMTP id 706CC1AE88B5; Sat, 15 Jun 2013 21:59:20 +0300 (EEST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Timo Sirainen <tss@iki.fi>
In-Reply-To: <43892743-D4CD-4137-B3BD-BCA321D9CE41@dsv.su.se>
Date: Sat, 15 Jun 2013 21:59:20 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <CDE93777-E0E9-4D9D-89F3-AFCEBE3D6E4B@iki.fi>
References: <p06240800ccc189b2c3ff@[192.168.0.101]> <43892743-D4CD-4137-B3BD-BCA321D9CE41@dsv.su.se>
To: Jacob Palme <jpalme@dsv.su.se>
X-Mailer: Apple Mail (2.1508)
Cc: General discussion of application-layer protocols <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Is e-mail going to die?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 15 Jun 2013 18:59:27 -0000

On 15.6.2013, at 19.52, Jacob Palme <jpalme@dsv.su.se> wrote:

> I wrote a message in November 2012 which is quoted at the end of=20
> this message.
>=20
> One thing I am noting since then is that other message systems=20
> are more and more used instead of email.

Email usage still keeps growing though.

> Examples of such alternative messaging systems are SMS, Facebook=20
> and Kik.

Companies don't use those to communicate.

> Large companies more and more are telling people who want to=20
> communicate with them to use a special web page instead of e-mail.=20
> Banks only allow me to communicate through a message system where=20
> I first have to log in to my bank account before sending and=20
> receiving messages to and from my bank. Other companies may do the
> same.

I don't see that happening. Sure, for banks and other such institutions =
that actually require secure mail a regular email won't currently really =
work (a bank can't force customers to encrypt their mails before sending =
them and leaking confidential data). I doubt it's going to catch on to =
many other companies though.

> Even though there are technical problems, I still believe that
> email's opportunity to succeed is to replace email into a system
> where the sender pays a fee, say $0.10 per recipient, for sending
> messages. The old, unpaid system can continue to live in parallel
> to the new system.

http://www.taugh.com/epostage.pdf was mentioned as a reply to your last =
post, which I think describes pretty well why I doubt any actual money =
transactions aren't going to work. But I do wonder how far people have =
thought about using hashcash. I haven't really followed antispam efforts =
myself.. but I'd think a hashcash and some crypto combination could be =
made to work, if enough people show interest. A high level plan:

 - Every time you send a mail to a new contact, you'll have to pay with =
hashcash. The recipient SMTP server specifies the cost requirement and =
rejects the mail at RCPT TO stage if the payment isn't given.

 - For big ISPs/webmails and such the cost would have to be offloaded to =
the actual sender client, not the sending SMTP server. Yes, some slow =
clients might have to calculate it for minutes and show the user a =
progress bar showing how long it's going to take. ISPs could also sell =
this as a service to do it on the server side. Users could also opt to =
send it the old way and hope it gets through.

 - Each email you send to someone will contain a crypto key header that =
allows the recipient to send you back emails without calculating the =
hashcash.

 - Mailing list subscriptions would be done by sending them an email =
with the crypto key, which mailing lists can remember to make it free =
for them to send you the actual mails.

 - A crypto key would be specific to a single email address, so the =
crypto key headers could be thought of as public information. This =
requires SPF/DKIM to be enabled for the senders.

 - If your private crypto key gets leaked, you need to switch to a new =
one. This wouldn't be too bad, except you'd have to re-subscribe to the =
legitimate mailing lists, which perhaps could be automated with some =
extra work.

 - During transition phase this would basically just affect the spam =
scoring, so this could be implemented incrementally.

 - Requires new software for sending and receiving SMTP servers to be =
able to use this, but not necessarily new email clients. Webmail =
providers could calculate hashcash using Javascript on the background =
during composing the email. The main problem would be the old IMAP/POP3 =
clients trying to use free email providers.

I don't see any obvious reason why the above couldn't work, other than =
the huge amount of work required and convincing all the major players to =
implement it. And it of course wouldn't completely eliminate spam, but =
it would make it much more costly, hopefully dropping the amount of spam =
from 99% of all mails to a few %. Botnets aren't free to use either.


From johnl@iecc.com  Sat Jun 15 14:19:21 2013
Return-Path: <johnl@iecc.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23F8621F9DF0 for <apps-discuss@ietfa.amsl.com>; Sat, 15 Jun 2013 14:19:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -111.149
X-Spam-Level: 
X-Spam-Status: No, score=-111.149 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Th19KiEI7cNo for <apps-discuss@ietfa.amsl.com>; Sat, 15 Jun 2013 14:19:16 -0700 (PDT)
Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id A9E1F21F9D9D for <apps-discuss@ietf.org>; Sat, 15 Jun 2013 14:19:16 -0700 (PDT)
Received: (qmail 48473 invoked from network); 15 Jun 2013 21:19:15 -0000
Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 15 Jun 2013 21:19:15 -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=51bcda53.xn--30v786c.k1306; i=johnl@user.iecc.com; bh=UpKxgF7XlQ65o6aMOR762eQZJs6iEAyoUHAht3oTGww=; b=BGEs150ZGrf1PWV0+4bvPPtlU5Tk1RX3F55Blv7nbOg+YZGAOLxtgqD+QoekA9BIltKXaed7Y7EtbP3hbEalGP7MJxlkCUlG/6i+QE9WmMS4Yt35uOD5PZbER4Qer/IuFcEOc5f2cH6aMKKLUvbmFL+tzuA8xu71beVx+gJYtQMNFqkCPAoZNmaEEV61oRyV6PT+Uu0xsxBwtFyVvoz2cChRfOFx3zCnSHTi7XpTxIuhJX8W4P3R/KcZ8AkZlsGJ
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=51bcda53.xn--30v786c.k1306; olt=johnl@user.iecc.com; bh=UpKxgF7XlQ65o6aMOR762eQZJs6iEAyoUHAht3oTGww=; b=mrZPFFpMmhweZ4m3CGv16I5wRiXfLEWgxBTEpCsBurlQYfSIqZijkp2IOqoeBayaFy+Er/5hRQOUOovd+sbvAm4fv3Rto9LCwCJvABN1F0aahF5n2zNEIHhgZv0OlgRkaHUo9zDyP8MrsTf10GwrdXX3t4H1+nTmaSy8F+w+zNDsmdoj3khrFa3vYMtJTRnTrjk34m2ZBVhi9X+R8nZeJyUGc2UbCa9ZGUzQBLsMqiY2pyNDFwYwr06eHRHgVIhX
Date: 15 Jun 2013 21:18:52 -0000
Message-ID: <20130615211852.9269.qmail@joyce.lan>
From: "John Levine" <johnl@taugh.com>
To: apps-discuss@ietf.org
In-Reply-To: <CDE93777-E0E9-4D9D-89F3-AFCEBE3D6E4B@iki.fi>
Organization: 
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Subject: Re: [apps-discuss] Is e-mail going to die?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 15 Jun 2013 21:19:21 -0000

>> One thing I am noting since then is that other message systems 
>> are more and more used instead of email.

The death of e-mail has been regularly predicted for over a decade.
It remains the best way to communicate between entities over the
Internet because it doesn't require that you go poll every different
place that might want to send you something.

>http://www.taugh.com/epostage.pdf was mentioned as a reply to your last post, which I think
>describes pretty well why I doubt any actual money transactions aren't going to work. But I
>do wonder how far people have thought about using hashcash.

Far enough to realize that through the magic of bot nets, the bad guys
have far more resources to burn than the good guys.  (Keep in mind
that the bots doing the computing don't have to be the same ones that
are sending the spam.)  Hashcash also has all of the same white listing
problems of any other epostage scheme.  My paper you cited says that
on pages 4 and 5.  I haven't updated it since 2004, but nothing of
importance to the analysis has changed.

I ran into Cynthia Dwork, who invented hashcash, at a conference a few
years ago and she concurred.

R's,
John

From tss@iki.fi  Sat Jun 15 15:21:02 2013
Return-Path: <tss@iki.fi>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EA5621F9D0D for <apps-discuss@ietfa.amsl.com>; Sat, 15 Jun 2013 15:21:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.179
X-Spam-Level: 
X-Spam-Status: No, score=-110.179 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Gfu3kZ+8BtL for <apps-discuss@ietfa.amsl.com>; Sat, 15 Jun 2013 15:20:57 -0700 (PDT)
Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 00D6721F9CEC for <apps-discuss@ietf.org>; Sat, 15 Jun 2013 15:20:56 -0700 (PDT)
Received: from [192.168.10.100] (cs181255018.pp.htv.fi [82.181.255.18]) by dovecot.org (Postfix) with ESMTP id E917B1AE888A; Sun, 16 Jun 2013 01:20:54 +0300 (EEST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Timo Sirainen <tss@iki.fi>
In-Reply-To: <20130615211852.9269.qmail@joyce.lan>
Date: Sun, 16 Jun 2013 01:20:54 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <18E8452A-675A-4D75-85F0-DFF3818C77C1@iki.fi>
References: <20130615211852.9269.qmail@joyce.lan>
To: "John Levine" <johnl@taugh.com>
X-Mailer: Apple Mail (2.1508)
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Is e-mail going to die?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 15 Jun 2013 22:21:02 -0000

On 16.6.2013, at 0.18, "John Levine" <johnl@taugh.com> wrote:

>> http://www.taugh.com/epostage.pdf was mentioned as a reply to your =
last post, which I think
>> describes pretty well why I doubt any actual money transactions =
aren't going to work. But I
>> do wonder how far people have thought about using hashcash.
>=20
> Far enough to realize that through the magic of bot nets, the bad guys
> have far more resources to burn than the good guys.  (Keep in mind
> that the bots doing the computing don't have to be the same ones that
> are sending the spam.) =20

Bad guys have a lot of computing power, but not more than the legitimate =
guys sending mail. If the hashcash is made expensive enough, at some =
point generating them would require so much computing power that all the =
botnets wouldn't have enough enough power to send the amount of spam =
they are sending now. And I've understood that many spammers still pay =
for the use of botnets, and that they could be sold for other purposes =
as well (becoming more lucrative than spamming at some point). Or =
assuming that the bad guys actually buy the CPU power from AWS and such, =
the hashcash would just need to be slow enough that it wouldn't be worth =
the cost for most spammers.

So the question is mostly about how much would we be willing to waste =
CPU cycles for sending legitimate mails. With whitelisting the hashcash =
would only need to be done during the initial introduction, whereas =
spammers would need to do it to all the mails. The introduction hashcash =
could also be avoided entirely by sending the whitelist token =
out-of-band (e.g. as part of a vCard you send to someone). And all of =
the hashcash calculations could be outsourced to the end user clients, =
where it wouldn't necessarily even be a huge problem if the calculation =
for a single recipient took even a minute. (A side bonus: People =
mass-Cc'ing 1000 people within a company would have to wait a long time =
for it to finish, hopefully causing the sender to rethink if they really =
intended to do that. :)

> Hashcash also has all of the same white listing
> problems of any other epostage scheme.  My paper you cited says that
> on pages 4 and 5.  I haven't updated it since 2004, but nothing of
> importance to the analysis has changed.

I think the main idea in my previous mail that I hadn't seen before, was =
about how the whitelisting could be implemented in a pretty practical =
way using cryptographic tokens. It would go a long way without requiring =
anyone to even have a "whitelist database", because the whitelist token =
would be in the email itself that you're replying to. And in particular =
the receiving SMTP servers wouldn't need a whitelist database, they =
could simply verify that the token is a valid digital signature for the =
sender+receiver combination (using a single cert+private key). The email =
clients would ideally store received tokens to the address book for =
future use, or this could also be done at SMTP/IMAP level.

After a bit of googling, I found that CAMRAM attempted something =
similar, but since its web page is gone I'm not sure how exactly it =
worked. I think it was more complex than what I was envisioning.


From dhc@dcrocker.net  Sat Jun 15 15:28:51 2013
Return-Path: <dhc@dcrocker.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 402EA21F9E30 for <apps-discuss@ietfa.amsl.com>; Sat, 15 Jun 2013 15:28:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.433
X-Spam-Level: 
X-Spam-Status: No, score=-6.433 tagged_above=-999 required=5 tests=[AWL=0.166,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eEK-unpbwJWd for <apps-discuss@ietfa.amsl.com>; Sat, 15 Jun 2013 15:28:46 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 539D521F9E2F for <apps-discuss@ietf.org>; Sat, 15 Jun 2013 15:28:46 -0700 (PDT)
Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r5FMRalf023421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 15 Jun 2013 15:28:39 -0700
Message-ID: <51BCEA4E.3010107@dcrocker.net>
Date: Sat, 15 Jun 2013 15:27:26 -0700
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Jacob Palme <jpalme@dsv.su.se>
References: <p06240800ccc189b2c3ff@[192.168.0.101]> <43892743-D4CD-4137-B3BD-BCA321D9CE41@dsv.su.se>
In-Reply-To: <43892743-D4CD-4137-B3BD-BCA321D9CE41@dsv.su.se>
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]); Sat, 15 Jun 2013 15:28:39 -0700 (PDT)
Cc: General discussion of application-layer protocols <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Is e-mail going to die?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: General discussion of application-layer protocols <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, 15 Jun 2013 22:28:51 -0000

On 6/15/2013 9:52 AM, Jacob Palme wrote:
> One thing I am noting since then is that other message systems
> are more and more used instead of email.


This is a remarkably poor choice of venue for discussing hypothetical 
industry usage trends.

And as raised, it's a topic that lacks any utility, no matter where it's 
discussed.

If there's a technical proposal or a technical criticism to consider, 
lets' hear it.

Otherwise, the topic is entirely noise to the list.


d/

ps. and as John L. notes, the topic isn't new, nevermind the irony of 
trying to discuss it through the medium that is purportedly vanishing...

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

From nico@cryptonector.com  Sat Jun 15 16:08:44 2013
Return-Path: <nico@cryptonector.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF3BF11E80C5 for <apps-discuss@ietfa.amsl.com>; Sat, 15 Jun 2013 16:08:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id orD2AfExsLLG for <apps-discuss@ietfa.amsl.com>; Sat, 15 Jun 2013 16:08:39 -0700 (PDT)
Received: from homiemail-a33.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id BD94D11E80AE for <apps-discuss@ietf.org>; Sat, 15 Jun 2013 16:08:39 -0700 (PDT)
Received: from homiemail-a33.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTP id 73133594059 for <apps-discuss@ietf.org>; Sat, 15 Jun 2013 16:08:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=h87MqPygvvWliSGTK1r6 80fRSqI=; b=oYvVBM8JeEG9Au2LIWfqVKUt+gKs86t76CGnKYWUGEar0eiGT0tM y1HVNwsLLQbAkAQj+AE3HNk9+GXYQv5URCV5k6wrh4rC3hnmBYylTnSBji3+QZ/7 vWUZvGrmi3o+xzsiIguY+nJC0Itj9YBs+hBWhBLOPrN4drxMVBiicG8=
Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTPSA id 567CA594058 for <apps-discuss@ietf.org>; Sat, 15 Jun 2013 16:08:39 -0700 (PDT)
Received: by mail-ie0-f179.google.com with SMTP id c10so3963549ieb.24 for <apps-discuss@ietf.org>; Sat, 15 Jun 2013 16:08:38 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pngevfIHnOODfACy+pri3F9Jc2zffPQnKgRGc/5VSVw=; b=HEeBmB9Dmg65u5dYOMC981Gyb2UwyIb59fjZhRFCtcxtl4c+P3d1dY24mgO6Vcqwo5 NhWRd8w954Ffp/v2MUPRmubFnjL3UsZpYyfzTPoy9+Zn7sa2uRxCfP2v62GE9JjYV6jR xaUtGDgPeiLNf6/X4IOWQ6Cvf8lmOBxsHdJMzOo4cubT2xEiYXYJU3V4QvnsW1mXQBzR gjk0dvflzCY5eW/3NaYWFG7eFKEC2edm8QiJC6xIvA70IOC2OOvseG+xdXRVaBmNxdog rUjWckz2fEZ3OUY4g83RdrOZBgZFfvdhT0Fn7fcm5xuFdKFtd0nwwD9hV4ehR3sqzHFl lxOA==
MIME-Version: 1.0
X-Received: by 10.50.27.37 with SMTP id q5mr1807720igg.52.1371337718846; Sat, 15 Jun 2013 16:08:38 -0700 (PDT)
Received: by 10.64.106.232 with HTTP; Sat, 15 Jun 2013 16:08:38 -0700 (PDT)
In-Reply-To: <43892743-D4CD-4137-B3BD-BCA321D9CE41@dsv.su.se>
References: <p06240800ccc189b2c3ff@192.168.0.101> <43892743-D4CD-4137-B3BD-BCA321D9CE41@dsv.su.se>
Date: Sat, 15 Jun 2013 18:08:38 -0500
Message-ID: <CAK3OfOgrsrFujQ00bAGn58yKAwaabe_CFD9-uHoytZUWVxQ+Og@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Jacob Palme <jpalme@dsv.su.se>
Content-Type: text/plain; charset=UTF-8
Cc: General discussion of application-layer protocols <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Is e-mail going to die?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 15 Jun 2013 23:08:44 -0000

On Sat, Jun 15, 2013 at 11:52 AM, Jacob Palme <jpalme@dsv.su.se> wrote:
> Even though there are technical problems, I still believe that
> email's opportunity to succeed is to replace email into a system
> where the sender pays a fee, say $0.10 per recipient, for sending
> messages. The old, unpaid system can continue to live in parallel
> to the new system.

This again.  Once in a while someone proposes this nonsense again.

Stop it.  It won't happen, and anyways, this is the wrong forum for
you.  If you want it to happen you'll have to get Google, Yahoo!, and
others to stop providing free e-mail services, but they make real
money off of free email services.  And you'd have to figure out who
gets paid these fees, who gets a cut, ...  You'll find it'd probably
have to be a tax in order for it to be fair at all.

You'd have to be *bigger* than Google, Yahoo!, and friends to get this
to happen, or come up with a new business model for Google and
friends.  The only entities that can pull this off today are
governments, and this is the wrong forum for lobbying governments
though.

So please stop it, stop bringing this to us.  It's *boring*.

Maybe we should have a filter for "$0.10" anti-spam spam.

Nico
--

From johnl@iecc.com  Sat Jun 15 16:30:00 2013
Return-Path: <johnl@iecc.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15BAE21F973A for <apps-discuss@ietfa.amsl.com>; Sat, 15 Jun 2013 16:30:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.3
X-Spam-Level: 
X-Spam-Status: No, score=-102.3 tagged_above=-999 required=5 tests=[AWL=0.300,  BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4k7q9iX1P2f for <apps-discuss@ietfa.amsl.com>; Sat, 15 Jun 2013 16:29:59 -0700 (PDT)
Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 1A69221F9927 for <apps-discuss@ietf.org>; Sat, 15 Jun 2013 16:29:58 -0700 (PDT)
Received: (qmail 70392 invoked from network); 15 Jun 2013 23:29:58 -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=112f7.51bcf8f6.k1306; bh=dmEdBNTntiqRRiiQ7PNM2XATS0XbhSrk0hiIxLvjM0k=; b=ASVwU4+AnkOyfhhR7MZXYeBWqy9KRQigykJYye42c19KyVnocS3mj/BPnwHtaqlxU7AH2bm4Iu7v7nS+c4U+xzczbRUJvoPLax3XQEozfmxrsRURBBE1WjeVYCatQq+2Qxc2eZfu7RXMXntBUH3x3LcfJWZBStZ7XP0Q60Jc8tWEVjCBOdDEodhZwIebvADFw6HlEDgwU+7gzzfFhpthlQKyBsF3Rt9ISapFr5ReBCT5UGq1ppg0F+PKjkOTJ9EA
Received: (ofmipd 127.0.0.1); 15 Jun 2013 23:29:36 -0000
Date: 15 Jun 2013 19:29:58 -0400
Message-ID: <alpine.BSF.2.00.1306151926100.9636@joyce.lan>
From: "John R. Levine" <johnl@iecc.com>
To: "Timo Sirainen" <tss@iki.fi>
In-Reply-To: <18E8452A-675A-4D75-85F0-DFF3818C77C1@iki.fi>
References: <20130615211852.9269.qmail@joyce.lan> <18E8452A-675A-4D75-85F0-DFF3818C77C1@iki.fi>
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
Cleverness: None detected
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Is e-mail going to die?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 15 Jun 2013 23:30:00 -0000

> Bad guys have a lot of computing power, but not more than the legitimate 
> guys sending mail.

Bad guys have multiple botnets with 100,000 nodes or more.  Of course they 
have more than the legitimate senders.  There probably aren't 100,000 
legitimate mail servers in the whole world.

> So the question is mostly about how much would we be willing to waste 
> CPU cycles for sending legitimate mails.

The answer hasn't changed in a decade -- nowhere as many as the bad guys 
have, by orders of magnitude.  There is also the "everyone in the world 
has to implement my FUSSP" problem, of course.

> I think the main idea in my previous mail that I hadn't seen before, was 
> about how the whitelisting could be implemented in a pretty practical 
> way using cryptographic tokens.

The technology isn't the problem, it's the social part of bad guys gaming 
the system by persuading people to whitelist them and then spamming.

By the way, there's nothing in this discussion so far that we couldn't 
have said a decade ago.

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 tss@iki.fi  Sat Jun 15 16:31:00 2013
Return-Path: <tss@iki.fi>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6B0521F9CD5 for <apps-discuss@ietfa.amsl.com>; Sat, 15 Jun 2013 16:31:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.291
X-Spam-Level: 
X-Spam-Status: No, score=-110.291 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m++LPN-UYXft for <apps-discuss@ietfa.amsl.com>; Sat, 15 Jun 2013 16:30:55 -0700 (PDT)
Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id A637C21F9927 for <apps-discuss@ietf.org>; Sat, 15 Jun 2013 16:30:54 -0700 (PDT)
Received: from [192.168.10.100] (cs181255018.pp.htv.fi [82.181.255.18]) by dovecot.org (Postfix) with ESMTP id 1CAD41AE888A for <apps-discuss@ietf.org>; Sun, 16 Jun 2013 02:30:53 +0300 (EEST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Timo Sirainen <tss@iki.fi>
In-Reply-To: <18E8452A-675A-4D75-85F0-DFF3818C77C1@iki.fi>
Date: Sun, 16 Jun 2013 02:30:52 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <1B465280-C9C9-464C-B02E-2B6CEC10B676@iki.fi>
References: <20130615211852.9269.qmail@joyce.lan> <18E8452A-675A-4D75-85F0-DFF3818C77C1@iki.fi>
To: "apps-discuss@ietf.org application-layer protocols" <apps-discuss@ietf.org>
X-Mailer: Apple Mail (2.1508)
Subject: Re: [apps-discuss] Is e-mail going to die?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 15 Jun 2013 23:31:01 -0000

On 16.6.2013, at 1.20, Timo Sirainen <tss@iki.fi> wrote:

> So the question is mostly about how much would we be willing to waste =
CPU cycles for sending legitimate mails. With whitelisting the hashcash =
would only need to be done during the initial introduction, whereas =
spammers would need to do it to all the mails. The introduction hashcash =
could also be avoided entirely by sending the whitelist token =
out-of-band (e.g. as part of a vCard you send to someone). And all of =
the hashcash calculations could be outsourced to the end user clients, =
where it wouldn't necessarily even be a huge problem if the calculation =
for a single recipient took even a minute. (A side bonus: People =
mass-Cc'ing 1000 people within a company would have to wait a long time =
for it to finish, hopefully causing the sender to rethink if they really =
intended to do that. :)

Actually the more I think about this the more I like it. If each user is =
able to specify how costly hashcash they want, it would effectively =
become a negotiation between the sender and the receiver about how much =
the sender wants to send the email vs. how much the recipient wants to =
receive it. So for example:

 - sales@example.com - Company wants a lot of sales, so hashcash could =
be very small, even nonexistent.
 - first.last@example.com - Medium large hashcash to avoid most spam
 - A very public person might have a very large hashcash. Bill Gates's =
spam would drop from millions of mails a day to almost nonexistent if =
his hashcash took 1 week of CPU time to calculate.

The more someone would get spam, the higher they could increase their =
hashcash to get rid of it (at the expense of the new initial contact =
senders). So the price of electricity for the sender would make sending =
the mail a real cost, and the less the recipient wants emails the more =
the sender would have to pay for it.

I think a lot of the things previously against hashcash/whitelisting =
don't really apply anymore:

 - SPF/DKIM prevents spoofing and is getting more and more popular =
anyway (having this working correctly for the sender would be a =
requirement)

 - Too expensive for GMail/Hotmail/etc. They can simply offload this to =
client's Javascript. Google would probably even be happy to advertise to =
people: "Sending email is too slow? Switch to Chrome to make it 10x =
faster!"

 - Mailing lists can avoid hashcashes entirely using the methods I =
mentioned earlier.


From tss@iki.fi  Sat Jun 15 16:42:31 2013
Return-Path: <tss@iki.fi>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5218311E80CC for <apps-discuss@ietfa.amsl.com>; Sat, 15 Jun 2013 16:42:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.29
X-Spam-Level: 
X-Spam-Status: No, score=-110.29 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zR8zVqRXPP39 for <apps-discuss@ietfa.amsl.com>; Sat, 15 Jun 2013 16:42:25 -0700 (PDT)
Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 5A82B11E80AE for <apps-discuss@ietf.org>; Sat, 15 Jun 2013 16:42:25 -0700 (PDT)
Received: from [192.168.10.100] (cs181255018.pp.htv.fi [82.181.255.18]) by dovecot.org (Postfix) with ESMTP id 4FC271AE888A; Sun, 16 Jun 2013 02:42:24 +0300 (EEST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Timo Sirainen <tss@iki.fi>
In-Reply-To: <alpine.BSF.2.00.1306151926100.9636@joyce.lan>
Date: Sun, 16 Jun 2013 02:42:23 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <E9779EF2-B2CB-4BD7-A9C5-5027C194439B@iki.fi>
References: <20130615211852.9269.qmail@joyce.lan> <18E8452A-675A-4D75-85F0-DFF3818C77C1@iki.fi> <alpine.BSF.2.00.1306151926100.9636@joyce.lan>
To: "John R. Levine" <johnl@iecc.com>
X-Mailer: Apple Mail (2.1508)
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Is e-mail going to die?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 15 Jun 2013 23:42:31 -0000

On 16.6.2013, at 2.29, "John R. Levine" <johnl@iecc.com> wrote:

>> Bad guys have a lot of computing power, but not more than the =
legitimate guys sending mail.
>=20
> Bad guys have multiple botnets with 100,000 nodes or more.  Of course =
they have more than the legitimate senders.  There probably aren't =
100,000 legitimate mail servers in the whole world.

There are actually millions of mail servers in the world (6M SMTP =
servers by my count a year ago). But more importantly: There are =
hundreds of millions of email senders! If each email sent required at =
minimum 30 seconds of CPU time (from the *user's device*, not the email =
server), a 100k node botnet could send only 288 million mails a day. To =
send the 30 billion spams/day they do now would require 1000 such =
botnets. (And if the botnets used 100% CPU all the time, I'd think that =
the people owning the machines would at some point start to wonder about =
their electricity consumption, reducing the botnet's size.)

>> I think the main idea in my previous mail that I hadn't seen before, =
was about how the whitelisting could be implemented in a pretty =
practical way using cryptographic tokens.
>=20
> The technology isn't the problem, it's the social part of bad guys =
gaming the system by persuading people to whitelist them and then =
spamming.

I don't see how that could be a big problem. If I accidentally do =
whitelist a bad guy's email address, I could just then just blacklist =
that one specific address and the spam would be gone. But yes, such =
blacklists would make this more complex. But then again it would still =
make the situation significantly better than it is now. Spam filtering =
will always be required anyway, just the spam amount would be far less =
than now.

> By the way, there's nothing in this discussion so far that we couldn't =
have said a decade ago.

I listed a few things that have changed in the mail I just sent.


From johnl@iecc.com  Sat Jun 15 16:55:57 2013
Return-Path: <johnl@iecc.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CF6821F9B29 for <apps-discuss@ietfa.amsl.com>; Sat, 15 Jun 2013 16:55:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.293
X-Spam-Level: 
X-Spam-Status: No, score=-102.293 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id helVAt2qsGoc for <apps-discuss@ietfa.amsl.com>; Sat, 15 Jun 2013 16:55:56 -0700 (PDT)
Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 41C3221F9B13 for <apps-discuss@ietf.org>; Sat, 15 Jun 2013 16:55:56 -0700 (PDT)
Received: (qmail 74668 invoked from network); 15 Jun 2013 23:55:54 -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=123ab.51bcff0a.k1306; bh=M0Mn7I7zEj3bIiOa+BAMMr1shP+5GAfw0/MGZNyUHD0=; b=NabU6Kgtay/cbByKbdLdjYh/UC9vuXrYwAW1g+RLQAYr6NY82hyndK0qrAKDB2T4jZYcvsjyKNipeEBo3V3LkvlfnObWtWGdjuuDZZHZj8Tjaj0GmbBPq7MFjzr6NX6dIGyX1ex6kTd/YSC6js02Tbi6NC4A1iRZf7p9Q18PBrBey4EHS//7e7cg/ZX5fZpiufCfD/cYdA1WZupTrGyunp9Ef8wMK/ADBajfgT8MTQPxc3shi35P0gT3+uhhy2kd
Received: (ofmipd 127.0.0.1); 15 Jun 2013 23:55:32 -0000
Date: 15 Jun 2013 19:55:54 -0400
Message-ID: <alpine.BSF.2.00.1306151952090.9689@joyce.lan>
From: "John R. Levine" <johnl@iecc.com>
To: "Timo Sirainen" <tss@iki.fi>
In-Reply-To: <E9779EF2-B2CB-4BD7-A9C5-5027C194439B@iki.fi>
References: <20130615211852.9269.qmail@joyce.lan> <18E8452A-675A-4D75-85F0-DFF3818C77C1@iki.fi> <alpine.BSF.2.00.1306151926100.9636@joyce.lan> <E9779EF2-B2CB-4BD7-A9C5-5027C194439B@iki.fi>
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
Cleverness: None detected
MIME-Version: 1.0
Content-Type: MULTIPART/signed; protocol="application/pkcs7-signature"; micalg=sha1; BOUNDARY="3825401791-364197093-1371340554=:9689"
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Is e-mail going to die?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 15 Jun 2013 23:55:57 -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.

--3825401791-364197093-1371340554=:9689
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

> There are actually millions of mail servers in the world (6M SMTP 
> servers by my count a year ago). But more importantly: There are 
> hundreds of millions of email senders! If each email sent required at 
> minimum 30 seconds of CPU time (from the *user's device*, not the email 
> server), a 100k node botnet could send only 288 million mails a day. To 
> send the 30 billion spams/day they do now would require 1000 such 
> botnets. (And if the botnets used 100% CPU all the time, I'd think that 
> the people owning the machines would at some point start to wonder about 
> their electricity consumption, reducing the botnet's size.)

Your numbers are vastly different from the numbers I hear at MAAWG 
meetings.  There may be millions of hosts that respond on port 25, but 
there aren't millions of hosts sending mail that anyone wants to get. 
(That's SMTP servers, not submit clients.)

In any event, the suggestion that everyone in the world wait an extra 30 
seconds every time they send a mail message is so absurd that I don't see 
much point in continuing the discussion.

R's,
John
--3825401791-364197093-1371340554=:9689
Content-Type: APPLICATION/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: BASE64
Content-Description: S/MIME Cryptographic Signature
Content-Disposition: attachment; filename=smime.p7s

MIIJwAYJKoZIhvcNAQcCoIIJsTCCCa0CAQExCzAJBgUrDgMCGgUAMAsGCSqG
SIb3DQEHAaCCBvEwggbtMIIF1aADAgECAgMElr8wDQYJKoZIhvcNAQELBQAw
gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD
VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTAeFw0xMjA3MjYwMTI5NTNaFw0xMzA3MjcwODE4NTVaMDgxFzAV
BgNVBAMMDmpvaG5sQGllY2MuY29tMR0wGwYJKoZIhvcNAQkBFg5qb2hubEBp
ZWNjLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMFb8p7E
Amn6F6QRKCe3TS54cIt5/+qSF4wmlM5cfiZyDvr1H4ttCWDKjUS1N2QaH38J
G23LRAanlY+G/WKY/SCuEtNqIApqHrbF2QGlzDEYIHXg+5//vlSXZ/lNof8p
96XDqnZZZQrqhcvy2Vrx6YWeIzobO+HHSQTqOvAotXx6LRwLIrQ38jIN4FPr
kYescZlMWFG4dlrQLkgzn31heyqn0Mg0i+y2w+UaeHyLBKxzyIzaoQY5yJje
e+hihNtn+SBSwzR6JD88Jp1tet/oxsDfR6TWf6cnujXRR8kCgWryJ5DkiL8B
5SAL5WR7XvrLnhxMNZmDl0g2/0QoHiLdXv8CAwEAAaOCA6kwggOlMAkGA1Ud
EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEF
BQcDBDAdBgNVHQ4EFgQUOjyDiYoWWJbXWPUtB8wSSe3G6qIwHwYDVR0jBBgw
FoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwGQYDVR0RBBIwEIEOam9obmxAaWVj
Yy5jb20wggIhBgNVHSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAu
BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBk
ZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJt
ZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlm
aWNhdGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2Fz
IGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiBy
ZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeSwgcmVsaWFu
Y2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29tcGxpYW5j
ZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUF
BwICMIGPMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMC
AQIaZExpYWJpbGl0eSBhbmQgd2FycmFudGllcyBhcmUgbGltaXRlZCEgU2Vl
IHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9ucyIgb2YgdGhlIFN0YXJ0
Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5z
dGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5
BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFz
czEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3Ns
LmNvbS9jZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBww
GoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBCwUAA4IB
AQAJApMkA1Q6kZOLmOfAqp9Cd/6crBHszmxKVg0rlIXR9eLtbjohunMDRm8l
is4y5XLr/oHuUrY42wPt6gbjSL7BTJJv//HjgZGQQ1pTUIB+MPD4WefCwTG/
+SSLGcGW/mcXTCK7XvD3e+PIudfK+HnqpyAr1lH/pkunWWnoSWf408QIxIIa
RVNFhQlyr75H1RKiYZllbJTwbMsQqbkHE+W08Dl2LMz9AWW+Qq0v1WGSOYr/
prkSmqpNyNN3yInNRM2ju1/EWLxaK0ViITL4pY7Ck/RKPz+7hufcLZmA51XY
tVY8nqITnFz5N6FJLGvCQ7tom5cHp5D8vtujPcMYKjJuMYIClzCCApMCAQEw
gZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgw
NgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRl
IENsaWVudCBDQQIDBJa/MAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsG
CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNjE1MjM1NTU0WjAjBgkq
hkiG9w0BCQQxFgQU/1zYtCY/PiH2+7UId4gYbJwmKegweQYJKoZIhvcNAQkP
MWwwajALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYF
Kw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAqW/JVj9v
Gl8uVgH9lujsYOvquMLjekV8fbxezMEQu1YfX7q7qNLOVkKs7Dfs7eLjMSKv
jMrFG2BOt1hk6NOQ+4Tqy5v5YJ6ulcmgH67J8I7duWBBR4okRJbxgpwES9TH
/Ien6pNQ5Q7TuRHX6hBwVeSgqACc40Y0iW45pEIAf1eP9VZL9jWlkKPBUZIe
pbR0Ho+jxrymqu9uMNPuyRNeRbOHsBy+eD+l7qMCXOfuoSclNmXchMQ7YW5C
uPZTv7+DtYq8O1TsD0F2aydLDK4J/kiuHZriz1Kp2yNmJBalf1/icz6qymqQ
7Cg9O4HxsiwZagS2Dm833Rfzh+2HDHDWnQ==

--3825401791-364197093-1371340554=:9689--

From tss@iki.fi  Sat Jun 15 17:14:05 2013
Return-Path: <tss@iki.fi>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB08C21F9E3C for <apps-discuss@ietfa.amsl.com>; Sat, 15 Jun 2013 17:14:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.29
X-Spam-Level: 
X-Spam-Status: No, score=-110.29 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lK3u2t8On3K8 for <apps-discuss@ietfa.amsl.com>; Sat, 15 Jun 2013 17:13:59 -0700 (PDT)
Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC0521F9E3B for <apps-discuss@ietf.org>; Sat, 15 Jun 2013 17:13:59 -0700 (PDT)
Received: from [192.168.10.100] (cs181255018.pp.htv.fi [82.181.255.18]) by dovecot.org (Postfix) with ESMTP id 6EC661AE888A; Sun, 16 Jun 2013 03:13:57 +0300 (EEST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Timo Sirainen <tss@iki.fi>
In-Reply-To: <alpine.BSF.2.00.1306151952090.9689@joyce.lan>
Date: Sun, 16 Jun 2013 03:13:57 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <D157A5C5-69A4-4948-9AC8-FD556CFAD77F@iki.fi>
References: <20130615211852.9269.qmail@joyce.lan> <18E8452A-675A-4D75-85F0-DFF3818C77C1@iki.fi> <alpine.BSF.2.00.1306151926100.9636@joyce.lan> <E9779EF2-B2CB-4BD7-A9C5-5027C194439B@iki.fi> <alpine.BSF.2.00.1306151952090.9689@joyce.lan>
To: "John R. Levine" <johnl@iecc.com>
X-Mailer: Apple Mail (2.1508)
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Is e-mail going to die?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 16 Jun 2013 00:14:05 -0000

On 16.6.2013, at 2.55, "John R. Levine" <johnl@iecc.com> wrote:

>> There are actually millions of mail servers in the world (6M SMTP =
servers by my count a year ago). But more importantly: There are =
hundreds of millions of email senders! If each email sent required at =
minimum 30 seconds of CPU time (from the *user's device*, not the email =
server), a 100k node botnet could send only 288 million mails a day. To =
send the 30 billion spams/day they do now would require 1000 such =
botnets. (And if the botnets used 100% CPU all the time, I'd think that =
the people owning the machines would at some point start to wonder about =
their electricity consumption, reducing the botnet's size.)
>=20
> Your numbers are vastly different from the numbers I hear at MAAWG =
meetings.  There may be millions of hosts that respond on port 25, but =
there aren't millions of hosts sending mail that anyone wants to get. =
(That's SMTP servers, not submit clients.)

Yeah, I meant the number of hosts responding to port 25. But that's =
irrelevant anyway, since my plan was to make the clients do the =
calculation in most situations. (The 30B spams/day I just found with =
google.)

> In any event, the suggestion that everyone in the world wait an extra =
30 seconds every time they send a mail message is so absurd that I don't =
see much point in continuing the discussion.

I've been typing this mail already for well over 30 seconds. The =
hashcash would have been calculated already by now without any extra =
wait by the time I send the mail. And that would have been necessary =
only the first time I sent you an email, for further replies the mail =
would have been whitelisted (since you also sent me a private reply, =
which would have contained the whitelist token). At least 99% of the =
emails I send go to either mailing lists or replying to other people's =
mails, and all of them would be whitelisted already (except if there =
were new Cc'd people).

I think this is nearly practical enough to be implemented and if used =
widely to significantly reduce the amount of spam. The important part is =
that the recipient decides how costly the sending would be, and the =
sender can then decide if it's worth it even. And that this is a =
technological solution that requires nothing more than software upgrades =
to become used, and it can be done incrementally. But I can see why =
overall people don't think implementing all this is worth the trouble. =
Even though people complain about spam, the filtering works well enough =
nowadays that they aren't demanding something better.


From franck@peachymango.org  Sat Jun 15 19:23:56 2013
Return-Path: <franck@peachymango.org>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEB7511E80E4 for <apps-discuss@ietfa.amsl.com>; Sat, 15 Jun 2013 19:23:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.203
X-Spam-Level: 
X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WnF9YZRMNCK5 for <apps-discuss@ietfa.amsl.com>; Sat, 15 Jun 2013 19:23:51 -0700 (PDT)
Received: from smtp.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id C45C711E80E2 for <apps-discuss@ietf.org>; Sat, 15 Jun 2013 19:23:51 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 1085839004B for <apps-discuss@ietf.org>; Sat, 15 Jun 2013 21:23:51 -0500 (CDT)
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 UsxYxCtYIzFb for <apps-discuss@ietf.org>; Sat, 15 Jun 2013 21:23:50 -0500 (CDT)
Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id E5A2A390055 for <apps-discuss@ietf.org>; Sat, 15 Jun 2013 21:23:50 -0500 (CDT)
Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id D029F390054 for <apps-discuss@ietf.org>; Sat, 15 Jun 2013 21:23:50 -0500 (CDT)
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 fF2B1oaQFeMf for <apps-discuss@ietf.org>; Sat, 15 Jun 2013 21:23:50 -0500 (CDT)
Received: from mail-2.01.com (mail.01.com [172.18.30.178]) by smtp-out-2.01.com (Postfix) with ESMTP id B8DAA39004B for <apps-discuss@ietf.org>; Sat, 15 Jun 2013 21:23:50 -0500 (CDT)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
References: <20130615211852.9269.qmail@joyce.lan> <18E8452A-675A-4D75-85F0-DFF3818C77C1@iki.fi> <alpine.BSF.2.00.1306151926100.9636@joyce.lan> <E9779EF2-B2CB-4BD7-A9C5-5027C194439B@iki.fi> <alpine.BSF.2.00.1306151952090.9689@joyce.lan> <D157A5C5-69A4-4948-9AC8-FD556CFAD77F@iki.fi> <WM!f5342bb891a689bc287c994b9b3cc8de6c2865e4d4de77d2204d3a89c5db7d34d689b50d5b6398f0b08ee5e698c40e50!@asav-3.01.com>
From: Franck Martin <franck@peachymango.org>
In-Reply-To: <WM!f5342bb891a689bc287c994b9b3cc8de6c2865e4d4de77d2204d3a89c5db7d34d689b50d5b6398f0b08ee5e698c40e50!@asav-3.01.com>
Message-Id: <18BC4946-9169-4475-BB29-9FC08FA6CC39@peachymango.org>
Date: Sat, 15 Jun 2013 21:23:50 -0500 (CDT)
To: "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Mime-Version: 1.0
X-Mailer: Zimbra 8.0.3_GA_5664 (MobileSync - Apple-iPad2C1/1002.329)
Thread-Topic: Is e-mail going to die?
Thread-Index: wMkJdB5ZF2VU7639/7YP6s8UaMygsQ==
Subject: Re: [apps-discuss] Is e-mail going to die?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 16 Jun 2013 02:23:57 -0000

Email has been pronounced dead so many times, we should call it zombie messa=
ging!

Printed on recycled paper!=

From franck@peachymango.org  Sat Jun 15 19:39:15 2013
Return-Path: <franck@peachymango.org>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B18A11E80E6 for <apps-discuss@ietfa.amsl.com>; Sat, 15 Jun 2013 19:39:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.203
X-Spam-Level: 
X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-C2jDDMVNvs for <apps-discuss@ietfa.amsl.com>; Sat, 15 Jun 2013 19:39:10 -0700 (PDT)
Received: from smtp.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id 208BB11E80DC for <apps-discuss@ietf.org>; Sat, 15 Jun 2013 19:39:10 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id D5DB239002A for <apps-discuss@ietf.org>; Sat, 15 Jun 2013 21:39:09 -0500 (CDT)
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 EwJhqte00QNm for <apps-discuss@ietf.org>; Sat, 15 Jun 2013 21:39:09 -0500 (CDT)
Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id BAD5C390041 for <apps-discuss@ietf.org>; Sat, 15 Jun 2013 21:39:09 -0500 (CDT)
Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id A57EE39003E for <apps-discuss@ietf.org>; Sat, 15 Jun 2013 21:39:09 -0500 (CDT)
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 6N1MzpQ6_3Xr for <apps-discuss@ietf.org>; Sat, 15 Jun 2013 21:39:09 -0500 (CDT)
Received: from mail-2.01.com (mail.01.com [172.18.30.178]) by smtp-out-2.01.com (Postfix) with ESMTP id 8EBE339002A for <apps-discuss@ietf.org>; Sat, 15 Jun 2013 21:39:09 -0500 (CDT)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
References: <c0kjr8dihl1l14lt6q0gq83d8qkpj8lqki@hive.bjoern.hoehrmann.de> <WM!ace934e949a25580d74895b4bd60f953ef46b340dc5b400067e880e11a9d83096ec31aa0cebc2fc290ded499f08b47e2!@asav-1.01.com>
From: Franck Martin <franck@peachymango.org>
In-Reply-To: <WM!ace934e949a25580d74895b4bd60f953ef46b340dc5b400067e880e11a9d83096ec31aa0cebc2fc290ded499f08b47e2!@asav-1.01.com>
Message-Id: <4C379D76-F395-4DF9-8AEF-0FF49801754D@peachymango.org>
Date: Sat, 15 Jun 2013 21:39:09 -0500 (CDT)
To: "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Mime-Version: 1.0
X-Mailer: Zimbra 8.0.3_GA_5664 (MobileSync - Apple-iPad2C1/1002.329)
Thread-Topic: comments on draft-ietf-appsawg-rfc5451bis-07
Thread-Index: qx2Pj8XyPoVykU8adpkg1d2FawAFDw==
Subject: Re: [apps-discuss] comments on draft-ietf-appsawg-rfc5451bis-07
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 16 Jun 2013 02:39:15 -0000

There is no specification for exposing the result of an SMTP TLS transaction=
, and the certificates used?

What I have seen so far in the wild did not see particularly formatted nor u=
seful and attached mainly with auth=3D which is one narrow use of SMTP TLS c=
ertificates.

Printed on recycled paper!=

From superuser@gmail.com  Sat Jun 15 21:57:25 2013
Return-Path: <superuser@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9041F21F9B4D for <apps-discuss@ietfa.amsl.com>; Sat, 15 Jun 2013 21:57:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001,  BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g+OCzwdsBE4x for <apps-discuss@ietfa.amsl.com>; Sat, 15 Jun 2013 21:57:25 -0700 (PDT)
Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id BBEAC21F9B3F for <apps-discuss@ietf.org>; Sat, 15 Jun 2013 21:57:24 -0700 (PDT)
Received: by mail-wg0-f49.google.com with SMTP id a12so1483897wgh.28 for <apps-discuss@ietf.org>; Sat, 15 Jun 2013 21:57:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xNN01PgqGN94k402V7Nx6DpfGmuCMPmUG1V8d39BwaM=; b=ulw+gqcRC8wyoN4NUvNhtb/YicexfT+3b2Z5HRsqulpDy5hMxux8fKO1sblPIQlk96 BMADdGbz4eRTX4+iEL/W+CegFaeEMUOxdxE9Jyh3V6VteOdMHrfMmr291X6idVMxVXbW mI8qN8yqfCDmTb406JuVFCv1L8qpK4BUC4o1yhCtlO5xbKOHl6jY5m3NZshxFFj68OpB DQHulw8Vq7PjCt9mO+CAmbsQkW57yaerBD7/kDNMJh1a2xT8m1ICBFCnSjI2tq2G8KMl DUqUK/xJ1bMuKL539h/BaatzaooE0ZSQyChrVJnvFdVwZ3IAEqig/PdaemT7cxI8N7tg yvtA==
MIME-Version: 1.0
X-Received: by 10.180.83.166 with SMTP id r6mr2097539wiy.60.1371358643919; Sat, 15 Jun 2013 21:57:23 -0700 (PDT)
Received: by 10.180.74.203 with HTTP; Sat, 15 Jun 2013 21:57:23 -0700 (PDT)
In-Reply-To: <43892743-D4CD-4137-B3BD-BCA321D9CE41@dsv.su.se>
References: <p06240800ccc189b2c3ff@192.168.0.101> <43892743-D4CD-4137-B3BD-BCA321D9CE41@dsv.su.se>
Date: Sat, 15 Jun 2013 21:57:23 -0700
Message-ID: <CAL0qLwb8OiaTUcn3dP+eWjrQbKk1U3CiV42DOhP=+4Ho3kmKSw@mail.gmail.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
To: Jacob Palme <jpalme@dsv.su.se>
Content-Type: multipart/alternative; boundary=f46d043c07f4d4a14904df3e506f
Cc: General discussion of application-layer protocols <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Is e-mail going to die?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 16 Jun 2013 04:57:25 -0000

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

On Sat, Jun 15, 2013 at 9:52 AM, Jacob Palme <jpalme@dsv.su.se> wrote:

> I wrote a message in November 2012 which is quoted at the end of
> this message.
>
> One thing I am noting since then is that other message systems
> are more and more used instead of email.
>
> Examples of such alternative messaging systems are SMS, Facebook
> and Kik.
> [...]
>

The death of email has been predicted more times than I can remember.  At
no point in my career have I ever been told we need to throttle back on
email related infrastructure because volumes are dropping.  Some large
companies do their own private message systems where the communication is
highly sensitive (banks, hospitals, the IRS), but they're relatively small
in number.

Facebook, Kik, AIM, and whatever other communication platform you can think
of (apart from SMS) all rely on email for account recovery in case you
forget your password.  That goes for just about every other web site I've
ever used, except maybe the few exceptions we've already covered.  That
suggests to me they think it's reliable and long-lived enough for those
purposes.

Just about every social media site I know uses email to ping you about
account activity of interest if you haven't logged in lately.

>From where I sit, if anything, email use (even without considering spam) is
still increasing.

-MSK

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

<div dir=3D"ltr">On Sat, Jun 15, 2013 at 9:52 AM, Jacob Palme <span dir=3D"=
ltr">&lt;<a href=3D"mailto:jpalme@dsv.su.se" target=3D"_blank">jpalme@dsv.s=
u.se</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmai=
l_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">I wrote a message in Nove=
mber 2012 which is quoted at the end of<br>
this message.<br>
<br>
One thing I am noting since then is that other message systems<br>
are more and more used instead of email.<br>
<br>
Examples of such alternative messaging systems are SMS, Facebook<br>
and Kik.<br>
[...]<br></blockquote><div><br></div><div>The death of email has been predi=
cted more times than I can remember.=A0 At no point in my career have I eve=
r been told we need to throttle back on email related infrastructure becaus=
e volumes are dropping.=A0 Some large companies do their own private messag=
e systems where the communication is highly sensitive (banks, hospitals, th=
e IRS), but they&#39;re relatively small in number.<br>
<br>Facebook, Kik, AIM, and whatever other communication platform you can t=
hink of (apart from SMS) all rely on email for account recovery in case you=
 forget your password.=A0 That goes for just about every other web site I&#=
39;ve ever used, except maybe the few exceptions we&#39;ve already covered.=
=A0 That suggests to me they think it&#39;s reliable and long-lived enough =
for those purposes.<br>
<br>Just about every social media site I know uses email to ping you about =
account activity of interest if you haven&#39;t logged in lately.<br><br></=
div><div>From where I sit, if anything, email use (even without considering=
 spam) is still increasing.<br>
</div><div><br></div><div>-MSK<br></div></div></div></div>

--f46d043c07f4d4a14904df3e506f--

From yaojk@cnnic.cn  Sun Jun 16 01:33:09 2013
Return-Path: <yaojk@cnnic.cn>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD2B921F9E68 for <apps-discuss@ietfa.amsl.com>; Sun, 16 Jun 2013 01:33:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.389
X-Spam-Level: 
X-Spam-Status: No, score=-99.389 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_EXCESS_BASE64=1.456, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kpLbGwU0Yep6 for <apps-discuss@ietfa.amsl.com>; Sun, 16 Jun 2013 01:33:04 -0700 (PDT)
Received: from cnnic.cn (smtp.cnnic.cn [218.241.118.7]) by ietfa.amsl.com (Postfix) with SMTP id 6D1CB21F9CB4 for <apps-discuss@ietf.org>; Sun, 16 Jun 2013 01:33:02 -0700 (PDT)
X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn
Received: from unknown127.0.0.1 (HELO smtpbg298.qq.com) (127.0.0.1) by 127.0.0.1 with SMTP; Sun, 16 Jun 2013 16:32:52 +0800
X-QQ-SSF: 0000000000000010000000000000000
X-HAS-ATTACH: no
X-QQ-BUSINESS-ORIGIN: 2
X-QQ-DNTY: 1
X-Originating-IP: 123.115.103.11
X-QQ-STYLE: 
X-QQ-mid: webmail667t1371371567t681748
From: "=?ISO-8859-1?B?SmlhbmthbmcgWWFv?=" <yaojk@cnnic.cn>
To: "=?ISO-8859-1?B?Sm9obiBMZXZpbmU=?=" <johnl@taugh.com>, "=?ISO-8859-1?B?YXBwcy1kaXNjdXNz?=" <apps-discuss@ietf.org>
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_51BD782E_09774698_6851BFCA"
Content-Transfer-Encoding: 8Bit
Date: Sun, 16 Jun 2013 16:32:46 +0800
X-Priority: 3
Message-ID: <tencent_320549D964DD68075E62FCEF@qq.com>
X-QQ-MIME: TCMime 1.0 by Tencent
X-Mailer: QQMail 2.x
X-QQ-Mailer: QQMail 2.x
X-QQ-ReplyHash: 1168286043
X-QQ-FName: 617F8ABD21354388B570DB46E80A0B07
X-QQ-LocalIP: 58.250.134.100
Subject: Re: [apps-discuss] Is e-mail going to die?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 16 Jun 2013 08:33:10 -0000

This is a multi-part message in MIME format.

------=_NextPart_51BD782E_09774698_6851BFCA
Content-Type: text/plain;
	charset="ISO-8859-1"
Content-Transfer-Encoding: base64

QWdyZWUgd2l0aCBKb2huJ3MgY29tbWVudHMuDQogc29tZW9uZSBoYXMgdGhlIGdvb2dsZSBh
Y2NvdW50LCBzb21lb25lIGhhcyBmYWNlYm9vayBhY2NvdW50LCBhbmQgb3RoZXJzIGhhcyAu
Li4uLiBZb3UgbmVlZCB0byBsb2cgb24gZGlmZmVyZW50IHN5c3RlbXMgdG8gY29tbXVuaWNh
dGUgd2l0aCBkaWZmZXJlbnQgcGVyc29ucyBpbiB0aGF0IHN5c3RlbS4NCiBidXQgZW1haWwg
bWVzc2FnZXMgY29ubmVjdCB3aXRoIGFsbCB0aGVzZSBzeXN0ZW1zLg0KICANCg0KIEkgdGhp
bmsgdGhhdCB0aGUgZW1haWwgd2lsbCBpbmNyZWFzZSBpbnN0ZWFkIG9mIGR5aW5nLg0KICAN
CiBKaWFua2FuZyBZYW8NCg0KIC0tLS0tLS0tLS0tLS0tLS0tLSBPcmlnaW5hbCAtLS0tLS0t
LS0tLS0tLS0tLS0NCiAgRnJvbTogICJKb2huIExldmluZSI8am9obmxAdGF1Z2guY29tPjsN
CiBEYXRlOiAgU3VuLCBKdW4gMTYsIDIwMTMgMDU6MTggQU0NCiBUbzogICJhcHBzLWRpc2N1
c3MiPGFwcHMtZGlzY3Vzc0BpZXRmLm9yZz47IA0KIA0KIFN1YmplY3Q6ICBSZTogW2FwcHMt
ZGlzY3Vzc10gSXMgZS1tYWlsIGdvaW5nIHRvIGRpZT8NCg0KID4uLi4NCg0KSXQgcmVtYWlu
cyB0aGUgYmVzdCB3YXkgdG8gY29tbXVuaWNhdGUgYmV0d2VlbiBlbnRpdGllcyBvdmVyIHRo
ZQ0KSW50ZXJuZXQgYmVjYXVzZSBpdCBkb2Vzbid0IHJlcXVpcmUgdGhhdCB5b3UgZ28gcG9s
bCBldmVyeSBkaWZmZXJlbnQNCnBsYWNlIHRoYXQgbWlnaHQgd2FudCB0byBzZW5kIHlvdSBz
b21ldGhpbmcu

------=_NextPart_51BD782E_09774698_6851BFCA
Content-Type: text/html;
	charset="ISO-8859-1"
Content-Transfer-Encoding: base64

PERJVj4mbmJzcDs8L0RJVj4NCjxESVY+QWdyZWUgd2l0aCBKb2huJ3MgY29tbWVudHMuPC9E
SVY+DQo8RElWPnNvbWVvbmUgaGFzIHRoZSBnb29nbGUgYWNjb3VudCwgc29tZW9uZSBoYXMg
ZmFjZWJvb2sgYWNjb3VudCwgYW5kIG90aGVycyBoYXMgLi4uLi4gWW91IG5lZWQgdG8gbG9n
IG9uIGRpZmZlcmVudCBzeXN0ZW1zIHRvIGNvbW11bmljYXRlIHdpdGggZGlmZmVyZW50IHBl
cnNvbnMgaW4gdGhhdCBzeXN0ZW0uPC9ESVY+DQo8RElWPmJ1dCBlbWFpbCBtZXNzYWdlcyBj
b25uZWN0IHdpdGggYWxsIHRoZXNlIHN5c3RlbXMuPC9ESVY+DQo8RElWPg0KPERJVj48QlI+
PC9ESVY+DQo8RElWPkkgdGhpbmsgdGhhdCB0aGUgZW1haWwgd2lsbCBpbmNyZWFzZSBpbnN0
ZWFkIG9mIGR5aW5nLjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+Smlhbmthbmcg
WWFvPEJSPjwvRElWPg0KPERJViBzdHlsZT0iUEFERElORy1CT1RUT006IDJweDsgUEFERElO
Ry1MRUZUOiAwcHg7IFBBRERJTkctUklHSFQ6IDBweDsgRk9OVC1GQU1JTFk6IEFyaWFsIE5h
cnJvdzsgRk9OVC1TSVpFOiAxMnB4OyBQQURESU5HLVRPUDogMnB4Ij4tLS0tLS0tLS0tLS0t
LS0tLS0mbmJzcDtPcmlnaW5hbCZuYnNwOy0tLS0tLS0tLS0tLS0tLS0tLTwvRElWPg0KPERJ
ViBzdHlsZT0iUEFERElORy1CT1RUT006IDhweDsgUEFERElORy1MRUZUOiA4cHg7IFBBRERJ
TkctUklHSFQ6IDhweDsgQkFDS0dST1VORDogI2VmZWZlZjsgRk9OVC1TSVpFOiAxMnB4OyBQ
QURESU5HLVRPUDogOHB4Ij4NCjxESVY+PEI+RnJvbTogPC9CPiZuYnNwOyJKb2huIExldmlu
ZSImbHQ7am9obmxAdGF1Z2guY29tJmd0Ozs8L0RJVj4NCjxESVY+PEI+RGF0ZTogPC9CPiZu
YnNwO1N1biwgSnVuIDE2LCAyMDEzIDA1OjE4IEFNPC9ESVY+DQo8RElWPjxCPlRvOiA8L0I+
Jm5ic3A7ImFwcHMtZGlzY3VzcyImbHQ7YXBwcy1kaXNjdXNzQGlldGYub3JnJmd0OzsgPFdC
Uj48L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPjxCPlN1YmplY3Q6IDwvQj4mbmJzcDtSZTog
W2FwcHMtZGlzY3Vzc10gSXMgZS1tYWlsIGdvaW5nIHRvIGRpZT88L0RJVj48L0RJVj4NCjxE
SVY+Jmd0Oy4uLjxCUj48L0RJVj5JdCByZW1haW5zIHRoZSBiZXN0IHdheSB0byBjb21tdW5p
Y2F0ZSBiZXR3ZWVuIGVudGl0aWVzIG92ZXIgdGhlPEJSPkludGVybmV0IGJlY2F1c2UgaXQg
ZG9lc24ndCByZXF1aXJlIHRoYXQgeW91IGdvIHBvbGwgZXZlcnkgZGlmZmVyZW50PEJSPnBs
YWNlIHRoYXQgbWlnaHQgd2FudCB0byBzZW5kIHlvdSBzb21ldGhpbmcuPEJSPjxCUj4NCjxE
SVY+PC9ESVY+PC9ESVY+

------=_NextPart_51BD782E_09774698_6851BFCA--


From mike5guo@gmail.com  Sun Jun 16 03:25:54 2013
Return-Path: <mike5guo@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2EC421F9C1B for <apps-discuss@ietfa.amsl.com>; Sun, 16 Jun 2013 03:25:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.591
X-Spam-Level: 
X-Spam-Status: No, score=0.591 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_51=0.6, J_CHICKENPOX_53=0.6, J_CHICKENPOX_74=0.6, NO_RELAYS=-0.001, PLING_QUERY=1.39]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o1SdCY+jVKbt for <apps-discuss@ietfa.amsl.com>; Sun, 16 Jun 2013 03:25:53 -0700 (PDT)
Received: from mail-oa0-x232.google.com (mail-oa0-x232.google.com [IPv6:2607:f8b0:4003:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 1A1B421F9C00 for <apps-discuss@ietf.org>; Sun, 16 Jun 2013 03:25:52 -0700 (PDT)
Received: by mail-oa0-f50.google.com with SMTP id k7so2375003oag.9 for <apps-discuss@ietf.org>; Sun, 16 Jun 2013 03:25:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=cyw7CM5N9C62Fzylzr/hi8QhzyMxHkejLI4AhlvoGPk=; b=LF2CuZVVmQ0HP82oil1lDCjRIBrJuosVlvQ8lplHHPrVmwPEH98OemCCETE6ABaAzT RwJ4RwrMgifGdhuyrJYYM8cJiarKcNtIQCAtdN/3VXde1UcWMQg1CqCi81jdLOzrL+PN ErHupIrcAJ0KFuHJOu794RemZhkN4pNjINaXxmXw1LZojQk4zKBJIz5A2O+ahnygCrzb +75TOoF6FrP5ihxcFxwjhSb6xpT6u2JM4SzWc064GfeFflEXQzBv0D+OfxXQEbT8HqtM fbCpKCjiTKRgZlwN546lla5+9Z7Xtl3xZ3/lntJ8qOI5pq9oNV/KgQKdDg5dcGE61pdN mBoA==
MIME-Version: 1.0
X-Received: by 10.182.66.46 with SMTP id c14mr6067483obt.33.1371378352439; Sun, 16 Jun 2013 03:25:52 -0700 (PDT)
Received: by 10.182.250.130 with HTTP; Sun, 16 Jun 2013 03:25:52 -0700 (PDT)
Date: Sun, 16 Jun 2013 18:25:52 +0800
Message-ID: <CAMFEDe5hLRDaaj7HJr43MBrAMS-0JvnTTR=_MLwyQs7zXd5r4Q@mail.gmail.com>
From: Zhun Guo <mike5guo@gmail.com>
To: apps-discuss@ietf.org, jpalme@dsv.su.se
Content-Type: multipart/alternative; boundary=e89a8fb200e68cc79604df42e78f
Cc: johnl@taugh.com, johnl@iecc.com
Subject: Re: [apps-discuss] Is e-mail going to die? (Jacob Palme)A new way to solve the spam!
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 16 Jun 2013 10:25:54 -0000

--e89a8fb200e68cc79604df42e78f
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: quoted-printable

Dear all:
    for this topic ,  two RFCs is concerning,RFC
4406<https://datatracker.ietf.org/doc/rfc4406/>
 (https://datatracker.ietf.org/doc/draft-lyon-senderid-core/) ,RFC
6686<https://datatracker.ietf.org/doc/rfc6686/>
 (https://datatracker.ietf.org/doc/rfc6686/)  ,or maybe SPF of Sender ID is
the best way.
   But because of the Cloud Computing=A3=ACmany applications have move to t=
he
cloud. Such as  Google Drive ,Microsoft Office 365 will replace native
office software.If the interconnection of different online office is done,
then the online office can do every thing that Email and  native office can
do . Just like when you know one person's email address,then you can send
email to him ,  whether or not you are in the same website.
    In the market of telecommunications, the interconnection of voice calli=
ng
and messaging applications has been realized among different noperators or
different information platforms and it was the interconnection among the
three major telecommunications operators in USA in 2005 that led the
vigorous development of SMS (short messaging service) among them. According
to OSI/RM (Open System Interconnection Reference Model) and TCP/IP
reference model, the more lower or basic the layer of the applications is,
the more the demand mof the interconnection among them is. Reed's Law in
the field of the Internet shows that the value of the telecommunications
network is proportional to the exponential function of the number of users.
The interconnection of different IM (instant messaging) applications in  th=
e
market of value added services of telecommunications is only partially
realized because IM is only used for informal communication. The
interconnection among different office applications was realized in the
field of the formal business communication. The traditional editing tools
of office documents are office applications, and the means of the
interconnection (transmission) are email, IM, sharing in social networking
website or in LAN (local area network), and U disk. It is thought that
the interoperability
of different office applications includes two aspects. One is that a
document can be surely opened. The other is that it can be surely reedited.
The traditional file formats of office documents are mainly xml-based ODF
(Open Document Format),OOXML (Office Open Extensible Markup Language) and
PDF. In order to deal with the users' needs, the authority of the
interoperability of traditional office documents is ISO/IEC JTC1/SC34. Beca=
use
of the rapid development of web technology, a large number of traditional
applications were moved onto the Internet in recent ten years, which
hastened the births of many cloud-office websites. With

Html5 and WebSocket being protocols, those cloud-office application
have successfully implemented the functions of editing html-based
documents such as word, spreadsheets, PowerPoint and
pictures,uploading and downloading documents between a cloud-office
website

     And in the old days ,  SMTP  replaced  UUCP ,so the four email
services company such as AOL, CompuServe,Prodigy,MCIMail can be inconnected
with each other in 1980s. So I think it is a new way to solve the email
spam .please see more about the Internet Draft:The Interconnection and
Interoperability of Different Cloud-office Applications (IDCOA) with the
HTML File Format
draft-guo-idoca-with-the-html-file-format-00(
https://datatracker.ietf.org/doc/draft-guo-idoca-with-the-html-file-format/=
?include_text=3D1)
 Thanks!

Zhun Guo

--e89a8fb200e68cc79604df42e78f
Content-Type: text/html; charset=GB2312
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Dear all:<div style>&nbsp; &nbsp; for this topic , &nbsp;t=
wo RFCs is concerning,<a href=3D"https://datatracker.ietf.org/doc/rfc4406/"=
 style=3D"font-size:13px;font-family:arial,helvetica,clean,sans-serif;line-=
height:16px;background-color:rgb(237,245,255)">RFC 4406</a><span style=3D"f=
ont-size:13px;color:rgb(0,0,0);font-family:arial,helvetica,clean,sans-serif=
;line-height:16px;background-color:rgb(237,245,255)">&nbsp;(</span><a href=
=3D"https://datatracker.ietf.org/doc/draft-lyon-senderid-core/">https://dat=
atracker.ietf.org/doc/draft-lyon-senderid-core/</a><span style=3D"backgroun=
d-color:rgb(237,245,255);color:rgb(0,0,0);font-family:arial,helvetica,clean=
,sans-serif;font-size:13px;line-height:16px">) ,</span><a href=3D"https://d=
atatracker.ietf.org/doc/rfc6686/" style=3D"font-size:13px;font-family:arial=
,helvetica,clean,sans-serif;line-height:16px"><font class=3D"" style=3D"bac=
kground-color:rgb(201,215,241)">RFC 6686</font></a><span style=3D"font-size=
:13px;color:rgb(0,0,0);font-family:arial,helvetica,clean,sans-serif;line-he=
ight:16px">&nbsp;(</span><a href=3D"https://datatracker.ietf.org/doc/rfc668=
6/">https://datatracker.ietf.org/doc/rfc6686/</a><span style=3D"color:rgb(0=
,0,0);font-family:arial,helvetica,clean,sans-serif;font-size:13px;line-heig=
ht:16px">) &nbsp;,or maybe SPF of&nbsp;</span><span style=3D"color:rgb(51,5=
1,51);font-family:=CB=CE=CC=E5;font-size:14px;line-height:21px">Sender ID i=
s the best way.&nbsp;</span></div>
<div style><span style=3D"color:rgb(51,51,51);font-family:=CB=CE=CC=E5;font=
-size:14px;line-height:21px">&nbsp; &nbsp;But because of the&nbsp;</span><s=
pan style=3D"color:rgb(0,0,0);line-height:18px">Cloud Computing=A3=ACmany a=
pplications have move to the cloud. Such as &nbsp;Google Drive ,Microsoft O=
ffice 365 will replace native office software.</span><font color=3D"#000000=
"><span style=3D"line-height:18px">If the interconnection of different onli=
ne office is done, then the online office can do every thing that Email and=
 &nbsp;</span></font><span style=3D"line-height:18px;color:rgb(0,0,0)">nati=
ve office can do . Just like when you know one person&#39;s email address,t=
hen you can send email to him , &nbsp;whether or not you are in the same we=
bsite.&nbsp;</span></div>
<div style><span style=3D"line-height:18px;color:rgb(0,0,0)">&nbsp; &nbsp;&=
nbsp;</span><span style=3D"color:rgb(0,0,0);font-size:13px;line-height:1.2e=
m">In the market of telecommunications, the interconnection of voice&nbsp;<=
/span><span style=3D"color:rgb(0,0,0);font-size:13px;line-height:1.2em">cal=
ling and messaging applications has been realized among different n</span><=
span style=3D"color:rgb(0,0,0);font-size:13px;line-height:1.2em">operators =
or different information platforms and it was the&nbsp;</span><span style=
=3D"color:rgb(0,0,0);font-size:13px;line-height:1.2em">interconnection amon=
g the three major telecommunications operators in&nbsp;</span><span style=
=3D"color:rgb(0,0,0);font-size:13px;line-height:1.2em">USA in 2005 that led=
 the vigorous development of SMS (short messaging&nbsp;</span><span style=
=3D"color:rgb(0,0,0);font-size:13px;line-height:1.2em">service) among them.=
  According to OSI/RM (Open System&nbsp;</span><span style=3D"color:rgb(0,0=
,0);font-size:13px;line-height:1.2em">Interconnection Reference Model) and =
TCP/IP reference model, the more&nbsp;</span><span style=3D"color:rgb(0,0,0=
);font-size:13px;line-height:1.2em">lower or basic the layer of the applica=
tions is, the more the demand m</span><span style=3D"color:rgb(0,0,0);font-=
size:13px;line-height:1.2em">of the interconnection among them is.  Reed&#3=
9;s Law in the field of the&nbsp;</span><span style=3D"color:rgb(0,0,0);fon=
t-size:13px;line-height:1.2em">Internet shows that the value of the telecom=
munications network is&nbsp;</span><span style=3D"color:rgb(0,0,0);font-siz=
e:13px;line-height:1.2em">proportional to the exponential function of the n=
umber of users.  The&nbsp;</span><span style=3D"color:rgb(0,0,0);font-size:=
13px;line-height:1.2em">interconnection of different IM (instant messaging)=
 applications in&nbsp;</span><span style=3D"color:rgb(0,0,0);font-size:13px=
;line-height:1.2em">&nbsp;the market of value added services of telecommuni=
cations is only&nbsp;</span><span style=3D"color:rgb(0,0,0);font-size:13px;=
line-height:1.2em">partially realized because IM is only used for informal&=
nbsp;</span><span style=3D"color:rgb(0,0,0);font-size:13px;line-height:1.2e=
m">communication.  The interconnection among different office&nbsp;</span><=
span style=3D"color:rgb(0,0,0);font-size:13px;line-height:1.2em">applicatio=
ns was realized in the field of the formal business&nbsp;</span><span style=
=3D"color:rgb(0,0,0);font-size:13px;line-height:1.2em">communication.  The =
traditional editing tools of office documents are&nbsp;</span><span style=
=3D"color:rgb(0,0,0);font-size:13px;line-height:1.2em">office applications,=
 and the means of the interconnection&nbsp;</span><span style=3D"color:rgb(=
0,0,0);font-size:13px;line-height:1.2em">(transmission) are email, IM, shar=
ing in social networking website or&nbsp;</span><span style=3D"color:rgb(0,=
0,0);font-size:13px;line-height:1.2em">in LAN (local area network), and U d=
isk.  It is thought that the&nbsp;</span><span style=3D"color:rgb(0,0,0);fo=
nt-size:13px;line-height:1.2em">interoperability of different office applic=
ations includes two&nbsp;</span><span style=3D"color:rgb(0,0,0);font-size:1=
3px;line-height:1.2em">aspects. One is that a document can be surely opened=
.  The other is&nbsp;</span><span style=3D"color:rgb(0,0,0);font-size:13px;=
line-height:1.2em">that it can be surely reedited. The traditional file for=
mats of&nbsp;</span><span style=3D"color:rgb(0,0,0);font-size:13px;line-hei=
ght:1.2em">office documents are mainly xml-based ODF (Open Document Format)=
,</span><span style=3D"color:rgb(0,0,0);font-size:13px;line-height:1.2em">O=
OXML (Office Open Extensible Markup Language) and PDF.  In order to&nbsp;</=
span><span style=3D"color:rgb(0,0,0);font-size:13px;line-height:1.2em">deal=
 with the users&#39; needs, the authority of the interoperability of&nbsp;<=
/span><span style=3D"color:rgb(0,0,0);font-size:13px;line-height:1.2em">tra=
ditional office documents is ISO/IEC JTC1/SC34.&nbsp;</span><span style=3D"=
color:rgb(0,0,0);font-size:13px;line-height:1.2em">Because of the rapid dev=
elopment of web technology, a large number of&nbsp;</span><span style=3D"co=
lor:rgb(0,0,0);font-size:13px;line-height:1.2em">traditional applications w=
ere moved onto the Internet in recent ten&nbsp;</span><span style=3D"color:=
rgb(0,0,0);font-size:13px;line-height:1.2em">years, which hastened the birt=
hs of many cloud-office websites.  With</span></div>
<pre style=3D"line-height:1.2em;margin-top:0px;margin-bottom:0px;color:rgb(=
0,0,0);font-size:13px">Html5 and WebSocket being protocols, those cloud-off=
ice application have successfully implemented the functions of editing html=
-based documents such as word, spreadsheets, PowerPoint and pictures,upload=
ing and downloading documents between a cloud-office website</pre>
<div style><span style=3D"color:rgb(0,0,0);line-height:18px">&nbsp; &nbsp; =
&nbsp;And in the old days , &nbsp;SMTP &nbsp;replaced &nbsp;UUCP ,so the fo=
ur email services company such as AOL, CompuServe,Prodigy,MCIMail can be in=
connected with each other in 1980s. So I think it is a new way to solve the=
 email spam .please see more about the Internet Draft:</span><span style=3D=
"color:rgb(0,0,0);font-family:arial,helvetica,clean,sans-serif;font-size:22=
px">The Interconnection and Interoperability of Different Cloud-office Appl=
ications (IDCOA) with the HTML File Format</span></div>
<h1 style=3D"margin:0px 0px 0.5em;font-size:22px;color:rgb(0,0,0);font-fami=
ly:arial,helvetica,clean,sans-serif">draft-guo-idoca-with-the-html-file-for=
mat-00(<a href=3D"https://datatracker.ietf.org/doc/draft-guo-idoca-with-the=
-html-file-format/?include_text=3D1" style=3D"font-family:arial;font-size:s=
mall;font-weight:normal">https://datatracker.ietf.org/doc/draft-guo-idoca-w=
ith-the-html-file-format/?include_text=3D1</a><span style=3D"font-weight:no=
rmal">) &nbsp;Thanks!</span></h1>
<div><span style=3D"font-weight:normal"><br></span></div><div style><span s=
tyle=3D"font-weight:normal">Zhun Guo</span></div></div>

--e89a8fb200e68cc79604df42e78f--

From eburger@standardstrack.com  Sun Jun 16 07:12:17 2013
Return-Path: <eburger@standardstrack.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10A9E21F9BA8 for <apps-discuss@ietfa.amsl.com>; Sun, 16 Jun 2013 07:12:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.999
X-Spam-Level: 
X-Spam-Status: No, score=-99.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ler9F8aoRftB for <apps-discuss@ietfa.amsl.com>; Sun, 16 Jun 2013 07:12:12 -0700 (PDT)
Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.246.237]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA1421F9B8B for <apps-discuss@ietf.org>; Sun, 16 Jun 2013 07:12:12 -0700 (PDT)
Received: from ip-64-134-167-46.public.wayport.net ([64.134.167.46]:59596 helo=[192.168.8.74]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from <eburger@standardstrack.com>) id 1UoDgf-0007IR-9m; Sun, 16 Jun 2013 07:12:09 -0700
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Eric Burger <eburger@standardstrack.com>
In-Reply-To: <18BC4946-9169-4475-BB29-9FC08FA6CC39@peachymango.org>
Date: Sun, 16 Jun 2013 09:12:08 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <086D0BFC-37E5-412F-8431-6EC97EBE9625@standardstrack.com>
References: <20130615211852.9269.qmail@joyce.lan> <18E8452A-675A-4D75-85F0-DFF3818C77C1@iki.fi> <alpine.BSF.2.00.1306151926100.9636@joyce.lan> <E9779EF2-B2CB-4BD7-A9C5-5027C194439B@iki.fi> <alpine.BSF.2.00.1306151952090.9689@joyce.lan> <D157A5C5-69A4-4948-9AC8-FD556CFAD77F@iki.fi> <WM!f5342bb891a689bc287c994b9b3cc8de6c2865e4d4de77d2204d3a89c5db7d34d689b50d5b6398f0b08ee5e698c40e50!@asav-3.01.com> <18BC4946-9169-4475-BB29-9FC08FA6CC39@peachymango.org>
To: "apps-discuss@ietf.org" <apps-discuss@ietf.org>
X-Mailer: Apple Mail (2.1508)
X-OutGoing-Spam-Status: No, score=-1.5
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Get-Message-Sender-Via: biz104.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Subject: Re: [apps-discuss] Is e-mail going to die?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 16 Jun 2013 14:12:17 -0000

I will second Franck's comment, by pointing out that 1.7 MILLION fax =
machines were sold last year in Japan alone.[1] If we cannot kill off =
fax, we certainly have no hope of killing off email.


[1] Fackler, Martin, "In High-Tech Japan, the Fax Machines Roll On," The =
New York Times February 13, 2013,=20
=
http://www.nytimes.com/2013/02/14/world/asia/in-japan-the-fax-machine-is-a=
nything-but-a-relic.html

On Jun 15, 2013, at 9:23 PM, Franck Martin <franck@peachymango.org> =
wrote:

> Email has been pronounced dead so many times, we should call it zombie =
messaging!
>=20
> Printed on recycled paper!
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss


From hallam@gmail.com  Sun Jun 16 07:35:36 2013
Return-Path: <hallam@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0EB621F9AC9 for <apps-discuss@ietfa.amsl.com>; Sun, 16 Jun 2013 07:35:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NX8q+22ROjBf for <apps-discuss@ietfa.amsl.com>; Sun, 16 Jun 2013 07:35:36 -0700 (PDT)
Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 2E4D821F9A7C for <apps-discuss@ietf.org>; Sun, 16 Jun 2013 07:35:36 -0700 (PDT)
Received: by mail-we0-f175.google.com with SMTP id t59so1658315wes.20 for <apps-discuss@ietf.org>; Sun, 16 Jun 2013 07:35:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=63TaJOxPqmzeRpiIflRRDiaM+xtarpLwG+eO8Jqo7HE=; b=B0myRwcKQUUCZW6vXUcvVe1tyObBbWltFPjEN3nwz3zS74LfySWGH9gKGKbUiACM6Z 3pIQevsydNIrodpscDK40NgRj/pV8KYWrL1h2xFgYhIvMxuFSbiX8+eWvBk6YbeMkHQ2 eiwUDm/+aNAufBcfQKPoYS1aZoh9WnQMbP26CqgQnGCBlE++iP7XDgmC6dE01LeZPS9n 1/yqB/svVzjWjvTrRB9T5zPTcOHwZUX2/TfEu+M3IJCIaGiZOI58tIaQOpF3p90seClx X93mdGKgJMLx1sgqs6lDkMfAAh8Xn87Uz9C+k9+W+K1txpceZ0u2h8ZFnatfexoGJz/J 9+uA==
MIME-Version: 1.0
X-Received: by 10.180.206.77 with SMTP id lm13mr2839768wic.18.1371393335342; Sun, 16 Jun 2013 07:35:35 -0700 (PDT)
Received: by 10.194.54.10 with HTTP; Sun, 16 Jun 2013 07:35:35 -0700 (PDT)
In-Reply-To: <CAL0qLwb8OiaTUcn3dP+eWjrQbKk1U3CiV42DOhP=+4Ho3kmKSw@mail.gmail.com>
References: <p06240800ccc189b2c3ff@192.168.0.101> <43892743-D4CD-4137-B3BD-BCA321D9CE41@dsv.su.se> <CAL0qLwb8OiaTUcn3dP+eWjrQbKk1U3CiV42DOhP=+4Ho3kmKSw@mail.gmail.com>
Date: Sun, 16 Jun 2013 10:35:35 -0400
Message-ID: <CAMm+LwgyGWvccMSDZmzT+bD7Dx+9E2eF8+f92M=-VjWkE6Wz3w@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: "Murray S. Kucherawy" <superuser@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c380ae99bd9d04df466460
Cc: General discussion of application-layer protocols <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Is e-mail going to die?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 16 Jun 2013 14:35:37 -0000

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

The question of whether email will die is silly. There is no way that I am
getting accounts on every proprietary platform people might use. I have a
FaceBook account only to stop other people taking my name there. If someone
sends me mail on Facebook is it is not going to reach me unless it gets
forwarded to my SMTP email.

There have always been closed email communities but open email has always
dominated. Email now means an account identifier <account>@<dns-name>.

We can change the SMTP and DNS protocols. The DNS may end up run by
different institutions over time. But continuity with the DNS namespace is
certain.


A more interesting question is whether chat/IM/video is ever going to
escape completely from closed communities. It looked like that was going to
happen but it doesn't seem to have done in the same way as email. People
tell me to get a Yahoo account or a Skype account or whatever just to chat
which is a stupid situation.

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

<div dir=3D"ltr">The question of whether email will die is silly. There is =
no way that I am getting accounts on every proprietary platform people migh=
t use. I have a FaceBook account only to stop other people taking my name t=
here. If someone sends me mail on Facebook is it is not going to reach me u=
nless it gets forwarded to my SMTP email.<div>
<br></div><div style>There have always been closed email communities but op=
en email has always dominated. Email now means an account identifier &lt;ac=
count&gt;@&lt;dns-name&gt;.</div><div style><br></div><div style>We can cha=
nge the SMTP and DNS protocols. The DNS may end up run by different institu=
tions over time. But continuity with the DNS namespace is certain.</div>
<div style><br></div><div style><br></div><div style>A more interesting que=
stion is whether chat/IM/video is ever going to escape completely from clos=
ed communities. It looked like that was going to happen but it doesn&#39;t =
seem to have done in the same way as email. People tell me to get a Yahoo a=
ccount or a Skype account or whatever just to chat which is a stupid situat=
ion.</div>
<div style><br></div></div>

--001a11c380ae99bd9d04df466460--

From nico@cryptonector.com  Sun Jun 16 07:48:46 2013
Return-Path: <nico@cryptonector.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5172621F9BD8 for <apps-discuss@ietfa.amsl.com>; Sun, 16 Jun 2013 07:48:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.964
X-Spam-Level: 
X-Spam-Status: No, score=-1.964 tagged_above=-999 required=5 tests=[AWL=0.013,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6eYDF5NYUdK5 for <apps-discuss@ietfa.amsl.com>; Sun, 16 Jun 2013 07:48:41 -0700 (PDT)
Received: from homiemail-a64.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 701B921F9BD5 for <apps-discuss@ietf.org>; Sun, 16 Jun 2013 07:48:41 -0700 (PDT)
Received: from homiemail-a64.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTP id 2E67043807E for <apps-discuss@ietf.org>; Sun, 16 Jun 2013 07:48:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=5gscGUdKOdpqcudycx6t RV+wEiI=; b=lF1EJ35ho4H6upfl9L9trWcYSK2VB04MJ75jpaT92ACEeM26BNra bxY4ew3mpNxkadjFVH8XbHbWc/R9k3+67kBFQyfpY/bQEk8L0N6/A0sp0NMqXPay N5M37twEnY1pOlPWyLtIcnJp3FcXdKuOkpyG18ObW7MHwlBuXAZq55o=
Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTPSA id CA40743807C for <apps-discuss@ietf.org>; Sun, 16 Jun 2013 07:48:40 -0700 (PDT)
Received: by mail-wg0-f45.google.com with SMTP id j13so1729787wgh.24 for <apps-discuss@ietf.org>; Sun, 16 Jun 2013 07:48:39 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8UKUpBOMYKDRT0hGPqrDUyxpUOSf9Ei07jUWgQ5tZww=; b=b2YxRzb4glpHnNoUoXue5l0Y0x2vzaBdgh/gCfrQ0yIgKXF7sBB6v6tugBU7FXXnJg sLbjwMu/tqojXsjX5BR5NXL/+LJs3Z74yYFbS+fuIFqy2XaPyXPYlg+MNwDJZmwsPEYr 2gyuGRFX7fjdBiT2/N4e/BMBUKgZKfI2dd12Lek5VqqDq8AscUmSmi/j8I0wjYaAYvuY UVE4rZPYbDcgPRN1i1VFswienGMQi6cdtocc0U7G/auFjcUZoU7nFVoa7wSFfuifMH9W EEfVECUI4IfpEXzIrwIK7AChJA7UlvFQVw0Ue4SdskRRwQL0kJe20Eljz2PeI2KMrJOZ iLXg==
MIME-Version: 1.0
X-Received: by 10.194.63.46 with SMTP id d14mr5913940wjs.81.1371394119626; Sun, 16 Jun 2013 07:48:39 -0700 (PDT)
Received: by 10.216.29.5 with HTTP; Sun, 16 Jun 2013 07:48:39 -0700 (PDT)
In-Reply-To: <43892743-D4CD-4137-B3BD-BCA321D9CE41@dsv.su.se>
References: <p06240800ccc189b2c3ff@192.168.0.101> <43892743-D4CD-4137-B3BD-BCA321D9CE41@dsv.su.se>
Date: Sun, 16 Jun 2013 09:48:39 -0500
Message-ID: <CAK3OfOgXz+YxVNw-P+c++B-tJCCnNEagWEYXNEktnzNUz9fCcg@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Jacob Palme <jpalme@dsv.su.se>
Content-Type: text/plain; charset=UTF-8
Cc: General discussion of application-layer protocols <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Is e-mail going to die?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 16 Jun 2013 14:48:46 -0000

On Sat, Jun 15, 2013 at 11:52 AM, Jacob Palme <jpalme@dsv.su.se> wrote:
> Even though there are technical problems, I still believe that
> email's opportunity to succeed is to replace email into a system
> where the sender pays a fee, say $0.10 per recipient, for sending
> messages. The old, unpaid system can continue to live in parallel
> to the new system.

Perhaps I was too quick to dismiss this.  Instead of thinking of a
$.10 per-email charge we might think of periodic settlements between
MTA operators, who might then pass costs on to their users.
Delinquent MTA operators would see that others don't take their
e-mail.  Is there any way to deploy such a scheme?  I think it'd be
like moving a mountain.  I think too many operators would want to
setup something akin to peering agreements and we'd end up with
something not unlike routing.  It would suck.  But it was worth more
thought than I'd thought.

Nico
--

From evan@e14n.com  Sun Jun 16 07:50:19 2013
Return-Path: <evan@e14n.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAACB21F9B29 for <apps-discuss@ietfa.amsl.com>; Sun, 16 Jun 2013 07:50:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GkYfdMe0pKrr for <apps-discuss@ietfa.amsl.com>; Sun, 16 Jun 2013 07:50:13 -0700 (PDT)
Received: from office.statusnetinc.com (office.statusnetinc.com [50.57.148.252]) by ietfa.amsl.com (Postfix) with ESMTP id 4EC0321F9AE2 for <apps-discuss@ietf.org>; Sun, 16 Jun 2013 07:50:11 -0700 (PDT)
Received: from [192.168.1.24] (pool-64-223-125-116.burl.east.myfairpoint.net [64.223.125.116]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by office.statusnetinc.com (Postfix) with ESMTPSA id 59DBA8D4D6B; Sun, 16 Jun 2013 15:07:43 +0000 (UTC)
Message-ID: <51BDD0A0.3020707@e14n.com>
Date: Sun, 16 Jun 2013 10:50:08 -0400
From: Evan Prodromou <evan@e14n.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6
MIME-Version: 1.0
To: dcrocker@bbiw.net
References: <p06240800ccc189b2c3ff@[192.168.0.101]> <43892743-D4CD-4137-B3BD-BCA321D9CE41@dsv.su.se> <51BCEA4E.3010107@dcrocker.net>
In-Reply-To: <51BCEA4E.3010107@dcrocker.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Sun, 16 Jun 2013 08:24:15 -0700
Cc: General discussion of application-layer protocols <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Is e-mail going to die?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 16 Jun 2013 14:50:19 -0000

On 13-06-15 06:27 PM, Dave Crocker wrote:
>
> This is a remarkably poor choice of venue for discussing hypothetical 
> industry usage trends.

+1. Please move this discussion elsewhere; it's inappropriate for this list.

-Evan


From markus.lanthaler@gmx.net  Sun Jun 16 09:06:18 2013
Return-Path: <markus.lanthaler@gmx.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA91A21F9B5E for <apps-discuss@ietfa.amsl.com>; Sun, 16 Jun 2013 09:06:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.15
X-Spam-Level: 
X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[AWL=-0.000,  BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N37yr1lvIW5T for <apps-discuss@ietfa.amsl.com>; Sun, 16 Jun 2013 09:06:14 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id D148421F9B5B for <apps-discuss@ietf.org>; Sun, 16 Jun 2013 09:06:13 -0700 (PDT)
Received: from mailout-de.gmx.net ([10.1.76.17]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0LpzgH-1U9i321Vfr-00fj0s for <apps-discuss@ietf.org>; Sun, 16 Jun 2013 18:06:11 +0200
Received: (qmail invoked by alias); 16 Jun 2013 16:06:11 -0000
Received: from 84-115-182-43.dynamic.surfer.at (EHLO Vostro3500) [84.115.182.43] by mail.gmx.net (mp017) with SMTP; 16 Jun 2013 18:06:11 +0200
X-Authenticated: #419883
X-Provags-ID: V01U2FsdGVkX1+49q4MLre49u2jpqliv+Db1GyUH87gejNMG2wtwg bJs3dsBDMaZ5PC
From: "Markus Lanthaler" <markus.lanthaler@gmx.net>
To: <apps-discuss@ietf.org>
Date: Sun, 16 Jun 2013 18:06:09 +0200
Message-ID: <010601ce6aab$6b42b9d0$41c82d70$@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: Ac5qqaWPj4qol2TUSVSMC1elVXgTEwAAEDBQ
Content-Language: de
X-Y-GMX-Trusted: 0
Subject: [apps-discuss] FW: I-D Action: draft-lanthaler-profile-registry-02.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 16 Jun 2013 16:06:18 -0000

I've just published a new version of my I-D in which I've removed the
registration request for the urn:ietf:params:profile URN subnamespace.

There wasn't the amount of interested I hoped for so I'll try to do what I
think is the minimum required to ensure interoperability. This also means
that the document can now go through the independent stream, i.e., directly
to the RFC editor.

Feedback would of course be much appreciated.


Thanks,
Markus


--
Markus Lanthaler
@markuslanthaler




-----Original Message-----
From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org]
On Behalf Of internet-drafts@ietf.org
Sent: Sunday, June 16, 2013 5:53 PM
To: i-d-announce@ietf.org
Subject: I-D Action: draft-lanthaler-profile-registry-02.txt


A New Internet-Draft is available from the on-line Internet-Drafts
directories.


	Title           : The IETF Profile URI Registry
	Author(s)       : Markus Lanthaler
	Filename        : draft-lanthaler-profile-registry-02.txt
	Pages           : 5
	Date            : 2013-06-16

Abstract:
   This document defines a registry for profile URIs to be used in
   specifications standardizing profiles.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-lanthaler-profile-registry

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-lanthaler-profile-registry-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-lanthaler-profile-registry-02


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


From paul.hoffman@vpnc.org  Sun Jun 16 12:31:36 2013
Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82CC921F9C35 for <apps-discuss@ietfa.amsl.com>; Sun, 16 Jun 2013 12:31:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.484
X-Spam-Level: 
X-Spam-Status: No, score=-102.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NfqEIc-3ZbMZ for <apps-discuss@ietfa.amsl.com>; Sun, 16 Jun 2013 12:31:36 -0700 (PDT)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id F3B3521F9C25 for <apps-discuss@ietf.org>; Sun, 16 Jun 2013 12:31:35 -0700 (PDT)
Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r5GJVWuv004209 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <apps-discuss@ietf.org>; Sun, 16 Jun 2013 12:31:32 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
From: Paul Hoffman <paul.hoffman@vpnc.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Sun, 16 Jun 2013 12:31:37 -0700
References: <20130616192439.26086.79348.idtracker@ietfa.amsl.com>
To: "apps-discuss@ietf.org Discuss" <apps-discuss@ietf.org>
Message-Id: <E452AE73-C76C-406B-B480-2362611AD9C9@vpnc.org>
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
X-Mailer: Apple Mail (2.1508)
Subject: [apps-discuss] Fwd: I-D Action: draft-bormann-cbor-02.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 16 Jun 2013 19:31:36 -0000

Greetings again. Carsten and I have updated CBOR to reflect the request =
to allow streaming / chunked byte strings and UTF-8 strings. We moved =
the streaming discussion up in the document and added prettier examples. =
We also added bigfloats, making them similar to decimal fractions.

--Paul Hoffman

Begin forwarded message:

> From: internet-drafts@ietf.org
> Subject: I-D Action: draft-bormann-cbor-02.txt
> Date: June 16, 2013 12:24:39 PM PDT
> To: i-d-announce@ietf.org
> Reply-To: internet-drafts@ietf.org
>=20
>=20
> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
>=20
>=20
> 	Title           : Concise Binary Object Representation (CBOR)
> 	Author(s)       : Carsten Bormann
>                          Paul Hoffman
> 	Filename        : draft-bormann-cbor-02.txt
> 	Pages           : 45
> 	Date            : 2013-06-16
>=20
> Abstract:
>   The Concise Binary Object Representation (CBOR) is a data format
>   whose design goals include the possibility of extremely small code
>   size, fairly small message size, and extensibility without the need
>   for version negotiation.  These design goals make it different from
>   earlier binary serializations such as ASN.1 and MessagePack.
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-bormann-cbor
>=20
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-bormann-cbor-02
>=20
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-bormann-cbor-02
>=20
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>=20


From johnl@iecc.com  Sun Jun 16 13:13:45 2013
Return-Path: <johnl@iecc.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4287121F9D12 for <apps-discuss@ietfa.amsl.com>; Sun, 16 Jun 2013 13:13:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -111.153
X-Spam-Level: 
X-Spam-Status: No, score=-111.153 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jRQC0UZastbk for <apps-discuss@ietfa.amsl.com>; Sun, 16 Jun 2013 13:13:41 -0700 (PDT)
Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id A929621F9D19 for <apps-discuss@ietf.org>; Sun, 16 Jun 2013 13:13:36 -0700 (PDT)
Received: (qmail 73167 invoked from network); 16 Jun 2013 20:13:34 -0000
Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 16 Jun 2013 20:13:34 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:mime-version:content-type:content-transfer-encoding:subject:cleverness; s=51be1c6e.xn--30v786c.k1306; i=johnl@user.iecc.com; bh=cyuaOvwIrxrIusbUbjxe5hlEIMfgtOlGcIyKe4seGA4=; b=FwTeFtzgNJmkpIdTumJ85K4Kvq3EmL/DdYk0IxSqK6AR8byh2AEYkVmOK1JOfOmuUZ6DOinZMBZ9O5ECLKS6qbl11o8+1lw1lyuX/S9COI7G+5hc7Rc5pke6AuOCF+6gtMTPoaVbS3P8ntTH/qOpeKGU03oBmY3YABja1xVKBsAjaqbTdyj8EDNZDJj+zXlAEv+qJV7ga9eFPozxNav3R8TbSttEou1cKz2wt+4gk7DlT5+9nIe6SCUmT6kNtFNZ
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:mime-version:content-type:content-transfer-encoding:subject:cleverness; s=51be1c6e.xn--30v786c.k1306; olt=johnl@user.iecc.com; bh=cyuaOvwIrxrIusbUbjxe5hlEIMfgtOlGcIyKe4seGA4=; b=hOXueVjvR5nObKXyRzlz2vchEvBhQkgdmqghHoZgbe8IRHsUJUciIMoTtYt0qzuUiRWfuOT3RIspj91tZ5cHvdWL701voRYDiHuEB8FIFvsQ8AaIGbyr49PG4jev/coEYXX7FTreE8iriECOYqnWvEUCBUQvWixyzfdRbBegyDImZpsRqvoVC3cS3XsXIb05DxgYOzra4Y05kUJYtgIKFrSYmmXhqeXOv0+qSI+WrI9IuCVJ8O3oxnKaAEejW4Np
Date: 16 Jun 2013 20:13:12 -0000
Message-ID: <20130616201312.33244.qmail@joyce.lan>
From: "John Levine" <johnl@taugh.com>
To: apps-discuss@ietf.org
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Cleverness: some
Subject: [apps-discuss] EPP extensions
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 16 Jun 2013 20:13:45 -0000

I'm seeing a lot of drafts go by for EPP extensions.  Some are
actively under development, like draft-tan-epp-launchphase, while some
seem to be one-offs like the recent
draft-xie-epp-trademark-mapping-00.  Many, like draft-obispo-epp-idn
and its predecessors, appear to be in active use in live EPP
registries.  

It seems like it would be a good idea to turn the ones that are in
active use or likely to be in active use (such as ones for the
Trademark Clearinghouse required for all of the new ICANN gTLDS) into
RFCs rather than making registries run forever on expired I-Ds.

Is it worth spinning up an eppext WG to handle them, or do it here?


From dsr@w3.org  Mon Jun 17 01:09:44 2013
Return-Path: <dsr@w3.org>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7DDD21F9A1B for <apps-discuss@ietfa.amsl.com>; Mon, 17 Jun 2013 01:09:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level: 
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1a-XsytfX5pD for <apps-discuss@ietfa.amsl.com>; Mon, 17 Jun 2013 01:09:36 -0700 (PDT)
Received: from lewis.sophia.w3.org (lewis.sophia.w3.org [193.51.208.72]) by ietfa.amsl.com (Postfix) with ESMTP id E25F621F9798 for <apps-discuss@ietf.org>; Mon, 17 Jun 2013 01:09:35 -0700 (PDT)
Received: from host2-94-static.28-87-b.business.telecomitalia.it ([87.28.94.2] helo=[192.168.1.208]) by lewis.sophia.w3.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <dsr@w3.org>) id 1UoUVJ-00084M-0h for apps-discuss@ietf.org; Mon, 17 Jun 2013 08:09:33 +0000
Message-ID: <51BEC43B.8020804@w3.org>
Date: Mon, 17 Jun 2013 09:09:31 +0100
From: Dave Raggett <dsr@w3.org>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <p06240800ccc189b2c3ff@192.168.0.101> <43892743-D4CD-4137-B3BD-BCA321D9CE41@dsv.su.se> <CAL0qLwb8OiaTUcn3dP+eWjrQbKk1U3CiV42DOhP=+4Ho3kmKSw@mail.gmail.com> <CAMm+LwgyGWvccMSDZmzT+bD7Dx+9E2eF8+f92M=-VjWkE6Wz3w@mail.gmail.com>
In-Reply-To: <CAMm+LwgyGWvccMSDZmzT+bD7Dx+9E2eF8+f92M=-VjWkE6Wz3w@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------080504040304000006080008"
Subject: Re: [apps-discuss] Is e-mail going to die?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 17 Jun 2013 08:09:45 -0000

This is a multi-part message in MIME format.
--------------080504040304000006080008
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 16/06/13 15:35, Phillip Hallam-Baker wrote:
>
> A more interesting question is whether chat/IM/video is ever going to 
> escape completely from closed communities. It looked like that was 
> going to happen but it doesn't seem to have done in the same way as 
> email. People tell me to get a Yahoo account or a Skype account or 
> whatever just to chat which is a stupid situation.
>

This is where a federated approach based upon personal zones may help. 
In the EU FP7 project "webinos" [1] we have been exploring the concept 
of a personal zone which encompasses your personal devices and services 
with each device being secured as part of the zone. The zone is exposed 
24x7 by a hub on which can you install personal services. Our 
implementation is based upon Node.JS.  The hub could be hosted by your 
ISP in the cloud, or run on a home gateway device. Finger can then be 
used to find the URI for someone's hub based upon their email address.

We are already seeing browser sync across devices, but only for the same 
brand of browser. Non-proprietary sync is the next step and will require 
some notion akin to the webinos personal zone, as users will in most 
cases have devices and browsers from different vendors. The notion is 
also relevant to managing privacy and security, especially for services 
based upon the Internet of Things. In conclusion, I agree that email is 
here to stay, but federated services for chat etc. are likely to emerge 
as a result of consumer pressure for non-proprietary means for managing 
a collection of personal devices and services.

[1] http://www.webinos.org/

-- 
Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett


--------------080504040304000006080008
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 16/06/13 15:35, Phillip Hallam-Baker
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAMm+LwgyGWvccMSDZmzT+bD7Dx+9E2eF8+f92M=-VjWkE6Wz3w@mail.gmail.com"
      type="cite">
      <div dir="ltr"><br>
        <div style="">A more interesting question is whether
          chat/IM/video is ever going to escape completely from closed
          communities. It looked like that was going to happen but it
          doesn't seem to have done in the same way as email. People
          tell me to get a Yahoo account or a Skype account or whatever
          just to chat which is a stupid situation.</div>
        <br>
      </div>
    </blockquote>
    <br>
    This is where a federated approach based upon personal zones may
    help. In the EU FP7 project "webinos" [1] we have been exploring the
    concept of a personal zone which encompasses your personal devices
    and services with each device being secured as part of the zone.&nbsp;
    The zone is exposed 24x7 by a hub on which can you install personal
    services. Our implementation is based upon Node.JS.&nbsp; The hub could
    be hosted by your ISP in the cloud, or run on a home gateway device.
    Finger can then be used to find the URI for someone's hub based upon
    their email address.<br>
    <br>
    We are already seeing browser sync across devices, but only for the
    same brand of browser. Non-proprietary sync is the next step and
    will require some notion akin to the webinos personal zone, as users
    will in most cases have devices and browsers from different vendors.
    The notion is also relevant to managing privacy and security,
    especially for services based upon the Internet of Things. In
    conclusion, I agree that email is here to stay, but federated
    services for chat etc. are likely to emerge as a result of consumer
    pressure for non-proprietary means for managing a collection of
    personal devices and services.<br>
    <br>
    [1]
    <meta http-equiv="content-type" content="text/html;
      charset=ISO-8859-1">
    <a href="http://www.webinos.org/">http://www.webinos.org/</a>
    <pre class="moz-signature" cols="72">-- 
Dave Raggett <a class="moz-txt-link-rfc2396E" href="mailto:dsr@w3.org">&lt;dsr@w3.org&gt;</a> <a class="moz-txt-link-freetext" href="http://www.w3.org/People/Raggett">http://www.w3.org/People/Raggett</a>
</pre>
  </body>
</html>

--------------080504040304000006080008--

From anything@michielbdejong.com  Mon Jun 17 04:09:08 2013
Return-Path: <anything@michielbdejong.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BCAB21F8B98 for <apps-discuss@ietfa.amsl.com>; Mon, 17 Jun 2013 04:09:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.275
X-Spam-Level: 
X-Spam-Status: No, score=-3.275 tagged_above=-999 required=5 tests=[AWL=0.172,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFBEApK4TfXs for <apps-discuss@ietfa.amsl.com>; Mon, 17 Jun 2013 04:09:00 -0700 (PDT)
Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) by ietfa.amsl.com (Postfix) with ESMTP id 6D05C21F8CDD for <apps-discuss@ietf.org>; Mon, 17 Jun 2013 04:08:33 -0700 (PDT)
Received: from mfilter26-d.gandi.net (mfilter26-d.gandi.net [217.70.178.154]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id 2C17BA80ED for <apps-discuss@ietf.org>; Mon, 17 Jun 2013 13:08:18 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter26-d.gandi.net
Received: from relay3-d.mail.gandi.net ([217.70.183.195]) by mfilter26-d.gandi.net (mfilter26-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id j9OLm8j2y-Z7 for <apps-discuss@ietf.org>; Mon, 17 Jun 2013 13:08:16 +0200 (CEST)
X-Originating-IP: 10.58.1.144
Received: from webmail.gandi.net (unknown [10.58.1.144]) (Authenticated sender: anything@michielbdejong.com) by relay3-d.mail.gandi.net (Postfix) with ESMTPA id C7237A80BE for <apps-discuss@ietf.org>; Mon, 17 Jun 2013 13:08:16 +0200 (CEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Date: Mon, 17 Jun 2013 13:08:16 +0200
From: "Michiel B. de Jong" <anything@michielbdejong.com>
To: Apps Discuss <apps-discuss@ietf.org>
In-Reply-To: <51BEC43B.8020804@w3.org>
References: <p06240800ccc189b2c3ff@192.168.0.101> <43892743-D4CD-4137-B3BD-BCA321D9CE41@dsv.su.se> <CAL0qLwb8OiaTUcn3dP+eWjrQbKk1U3CiV42DOhP=+4Ho3kmKSw@mail.gmail.com> <CAMm+LwgyGWvccMSDZmzT+bD7Dx+9E2eF8+f92M=-VjWkE6Wz3w@mail.gmail.com> <51BEC43B.8020804@w3.org>
Message-ID: <73e44da4d86c0e17a2d57a9ef736a10f@michielbdejong.com>
X-Sender: anything@michielbdejong.com
User-Agent: Roundcube Webmail/0.7.2
Subject: [apps-discuss] =?utf-8?q?Non-proprietary_sync_=28was_Re=3A__Is_e-?= =?utf-8?q?mail_going_to_die=3F?=
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 17 Jun 2013 11:09:10 -0000

On 2013-06-17 10:09, Dave Raggett wrote:
> Non-proprietary sync is the next step

That is exactly what "remote storage" tries to propose: a 
non-proprietary protocol that does something like 
Dropbox/GoogleDrive/SkyDrive over cross-origin HTTP.

We uploaded the -01 version of the I-D last week:

     http://www.ietf.org/id/draft-dejong-remotestorage-01.txt

From hallam@gmail.com  Mon Jun 17 04:42:11 2013
Return-Path: <hallam@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD70421F9A93 for <apps-discuss@ietfa.amsl.com>; Mon, 17 Jun 2013 04:42:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.766
X-Spam-Level: 
X-Spam-Status: No, score=-1.766 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NPNAEDlM6Rxt for <apps-discuss@ietfa.amsl.com>; Mon, 17 Jun 2013 04:42:10 -0700 (PDT)
Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 06C8121F9B9F for <apps-discuss@ietf.org>; Mon, 17 Jun 2013 04:42:04 -0700 (PDT)
Received: by mail-we0-f180.google.com with SMTP id w56so2248454wes.39 for <apps-discuss@ietf.org>; Mon, 17 Jun 2013 04:42:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uZ73K5px9aRH4VMnDSQoe6LCO8KHm0xps/kFxTDwfE8=; b=JjwKGMSXqIyerdAARlrkSiomRVtWVVhAkpm95xLVYatYa2jTeYq61LAnFHU4PWN5g2 lwofOhEcxUQmMId0lu1uA3ZJM29goUSBcTgHCaZ/u1ivkPgz1Aur2jBZ7ikF2am4wzOd O+HsWy0bij2bHXVTWiEVB0RNcXXXEMAC7qrnQ/CrROiF+eJpK7Zw6atkGxpwFWoj2124 jUtY+pIH4xobP+Ka+U+zvbuyIgIp/mS8i2vnu+feNjxTBLR+wsG+J65U8OKs/zF6Kfz4 9XmRYPi88SVXsQQGtOEwNhIONcEe89YqX9kYBy/YC2BkntJmw4xrF9asvvTkl03LYmF2 +WPg==
MIME-Version: 1.0
X-Received: by 10.180.189.136 with SMTP id gi8mr4672902wic.11.1371469323331; Mon, 17 Jun 2013 04:42:03 -0700 (PDT)
Received: by 10.194.54.10 with HTTP; Mon, 17 Jun 2013 04:42:03 -0700 (PDT)
In-Reply-To: <73e44da4d86c0e17a2d57a9ef736a10f@michielbdejong.com>
References: <p06240800ccc189b2c3ff@192.168.0.101> <43892743-D4CD-4137-B3BD-BCA321D9CE41@dsv.su.se> <CAL0qLwb8OiaTUcn3dP+eWjrQbKk1U3CiV42DOhP=+4Ho3kmKSw@mail.gmail.com> <CAMm+LwgyGWvccMSDZmzT+bD7Dx+9E2eF8+f92M=-VjWkE6Wz3w@mail.gmail.com> <51BEC43B.8020804@w3.org> <73e44da4d86c0e17a2d57a9ef736a10f@michielbdejong.com>
Date: Mon, 17 Jun 2013 07:42:03 -0400
Message-ID: <CAMm+LwhoNaqf6f9GEBA_-5SFuxRbwAXyGp7qBzNSjfQpnQRHnA@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: "Michiel B. de Jong" <anything@michielbdejong.com>
Content-Type: multipart/alternative; boundary=001a11c2412cd66d8a04df5815a2
Cc: Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Non-proprietary sync (was Re: Is e-mail going to die?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 17 Jun 2013 11:42:11 -0000

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

Interesting idea. I was thinking about a similar scheme only with the data
being encrypted on the storage drive and a decryption key issued bound to
each device authorized to read. The idea being to leverage the Ford-Wiener
model of CRM which is coming out of patent very soon.

Much of the protocol complexity of this type of scheme ends up being how
the end user establishes a device as authorized to access their account.
When I wrote Omnibroker I discovered that ended up being about 80% of the
protocol and the actual query-response piece was very straightforward.

Since this piece is applicable to many similar Web Services, I took it out
and made it a separate draft as Web Services Connect:

http://tools.ietf.org/html/draft-hallambaker-wsconnect-02

One issue that I have is working out what to call it as " Web Services *"
has been effectively grabbed by the SOAP/WS* crowd. And this is a JSON
protocol. I changed to JSON Connect (JCX) but I don't like that either.





On Mon, Jun 17, 2013 at 7:08 AM, Michiel B. de Jong <
anything@michielbdejong.com> wrote:

> On 2013-06-17 10:09, Dave Raggett wrote:
>
>> Non-proprietary sync is the next step
>>
>
> That is exactly what "remote storage" tries to propose: a non-proprietary
> protocol that does something like Dropbox/GoogleDrive/SkyDrive over
> cross-origin HTTP.
>
> We uploaded the -01 version of the I-D last week:
>
>     http://www.ietf.org/id/draft-**dejong-remotestorage-01.txt<http://www.ietf.org/id/draft-dejong-remotestorage-01.txt>
> ______________________________**_________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/**listinfo/apps-discuss<https://www.ietf.org/mailman/listinfo/apps-discuss>
>



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

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

<div dir=3D"ltr">Interesting idea. I was thinking about a similar scheme on=
ly with the data being encrypted on the storage drive and a decryption key =
issued bound to each device authorized to read. The idea being to leverage =
the Ford-Wiener model of CRM which is coming out of patent very soon.<div>
<br></div><div style>Much of the protocol complexity of this type of scheme=
 ends up being how the end user establishes a device as authorized to acces=
s their account. When I wrote Omnibroker I discovered that ended up being a=
bout 80% of the protocol and the actual query-response piece was very strai=
ghtforward.</div>
<div style><br></div><div style>Since this piece is applicable to many simi=
lar Web Services, I took it out and made it a separate draft as Web Service=
s Connect:</div><div style><br></div><div style><a href=3D"http://tools.iet=
f.org/html/draft-hallambaker-wsconnect-02">http://tools.ietf.org/html/draft=
-hallambaker-wsconnect-02</a><br>
</div><div style><br></div><div style>One issue that I have is working out =
what to call it as &quot;=A0Web Services *&quot; has been effectively grabb=
ed by the SOAP/WS* crowd. And this is a JSON protocol. I changed to JSON Co=
nnect (JCX) but I don&#39;t like that either.</div>
<div style><br></div><div style><br></div><div style><br></div></div><div c=
lass=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Mon, Jun 17, 201=
3 at 7:08 AM, Michiel B. de Jong <span dir=3D"ltr">&lt;<a href=3D"mailto:an=
ything@michielbdejong.com" target=3D"_blank">anything@michielbdejong.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">On 2013-06-17 10:09, Dave Raggett wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Non-proprietary sync is the next step<br>
</blockquote>
<br>
That is exactly what &quot;remote storage&quot; tries to propose: a non-pro=
prietary protocol that does something like Dropbox/GoogleDrive/SkyDrive ove=
r cross-origin HTTP.<br>
<br>
We uploaded the -01 version of the I-D last week:<br>
<br>
=A0 =A0 <a href=3D"http://www.ietf.org/id/draft-dejong-remotestorage-01.txt=
" target=3D"_blank">http://www.ietf.org/id/draft-<u></u>dejong-remotestorag=
e-01.txt</a><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>
</blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>Website: <a =
href=3D"http://hallambaker.com/">http://hallambaker.com/</a><br>
</div>

--001a11c2412cd66d8a04df5815a2--

From melvincarvalho@gmail.com  Mon Jun 17 04:57:42 2013
Return-Path: <melvincarvalho@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1060221F9AD2 for <apps-discuss@ietfa.amsl.com>; Mon, 17 Jun 2013 04:57:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.766
X-Spam-Level: 
X-Spam-Status: No, score=-1.766 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K4hLEvU0b15J for <apps-discuss@ietfa.amsl.com>; Mon, 17 Jun 2013 04:57:40 -0700 (PDT)
Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 1B16321F9AAD for <apps-discuss@ietf.org>; Mon, 17 Jun 2013 04:57:30 -0700 (PDT)
Received: by mail-la0-f53.google.com with SMTP id fs12so2355364lab.12 for <apps-discuss@ietf.org>; Mon, 17 Jun 2013 04:57:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PACgslCq9YOdCKsuNburRd4VVzGEJ54BAmJ8ftADI7o=; b=MGAYMrhp0HZbWY29UkdymdDaMXNRea9EUWuFtTeLoYVbia6DDz758Z1nou3JJjzor/ qOWpjVougvKt4jYd7kRnLNsCrWpPIx+BQmukM6H5a5JAfkWS0Wi0UCHM511d4ybcorH6 GnOlq+BLFBqeHsy/BmWAYbOuD6FlaYUqI13NjZ7cRAsQulSuPJ+zHL6rDVfQKBAlGTJY YBlxIVUCMsHmzYkoPjMPgi30xywxLSJRHRGhK8ZRBKhJgvjzuPerKsrKy56232PNT0fD 0GhJ9dDp6QOp46rGpDp60iPlF2z5ng0cg24Q/PmEb96xpi/ZfVLgy64LMcWrKoowOyMR L3Qw==
MIME-Version: 1.0
X-Received: by 10.152.29.227 with SMTP id n3mr6526477lah.43.1371470249935; Mon, 17 Jun 2013 04:57:29 -0700 (PDT)
Received: by 10.112.2.8 with HTTP; Mon, 17 Jun 2013 04:57:29 -0700 (PDT)
In-Reply-To: <CAMm+LwhoNaqf6f9GEBA_-5SFuxRbwAXyGp7qBzNSjfQpnQRHnA@mail.gmail.com>
References: <p06240800ccc189b2c3ff@192.168.0.101> <43892743-D4CD-4137-B3BD-BCA321D9CE41@dsv.su.se> <CAL0qLwb8OiaTUcn3dP+eWjrQbKk1U3CiV42DOhP=+4Ho3kmKSw@mail.gmail.com> <CAMm+LwgyGWvccMSDZmzT+bD7Dx+9E2eF8+f92M=-VjWkE6Wz3w@mail.gmail.com> <51BEC43B.8020804@w3.org> <73e44da4d86c0e17a2d57a9ef736a10f@michielbdejong.com> <CAMm+LwhoNaqf6f9GEBA_-5SFuxRbwAXyGp7qBzNSjfQpnQRHnA@mail.gmail.com>
Date: Mon, 17 Jun 2013 13:57:29 +0200
Message-ID: <CAKaEYhK_joxD1XK65JKG+h3TYSyD0EumfkU0MRv3i-BTDMzLHw@mail.gmail.com>
From: Melvin Carvalho <melvincarvalho@gmail.com>
To: Phillip Hallam-Baker <hallam@gmail.com>
Content-Type: multipart/alternative; boundary=089e0158c76c11488804df584d78
Cc: Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Non-proprietary sync (was Re: Is e-mail going to die?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 17 Jun 2013 11:57:42 -0000

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

On 17 June 2013 13:42, Phillip Hallam-Baker <hallam@gmail.com> wrote:

> Interesting idea. I was thinking about a similar scheme only with the data
> being encrypted on the storage drive and a decryption key issued bound to
> each device authorized to read. The idea being to leverage the Ford-Wiener
> model of CRM which is coming out of patent very soon.
>
> Much of the protocol complexity of this type of scheme ends up being how
> the end user establishes a device as authorized to access their account.
> When I wrote Omnibroker I discovered that ended up being about 80% of the
> protocol and the actual query-response piece was very straightforward.
>
> Since this piece is applicable to many similar Web Services, I took it out
> and made it a separate draft as Web Services Connect:
>
> http://tools.ietf.org/html/draft-hallambaker-wsconnect-02
>

Also in this space:

The mission of the Linked Data Platform (LDP) Working Group is to produce a
W3C Recommendation for HTTP-based (RESTful) application integration
patterns using read/write Linked Data. This work will benefit both
small-scale in-browser applications (WebApps) and large-scale Enterprise
Application Integration (EAI) efforts. It will complement SPARQL and will
be compatible with standards for publishing Linked Data, bringing the data
integration features of RDF to RESTful, data-oriented software development

http://www.w3.org/2012/ldp/charter

It's the combined effort of about 30 firms including IBM, Fujitsu, Apache,
Oracle, BBC and more.

This is expected to become a W3C REC around March 2014


>
> One issue that I have is working out what to call it as " Web Services *"
> has been effectively grabbed by the SOAP/WS* crowd. And this is a JSON
> protocol. I changed to JSON Connect (JCX) but I don't like that either.
>
>
>
>
>
> On Mon, Jun 17, 2013 at 7:08 AM, Michiel B. de Jong <
> anything@michielbdejong.com> wrote:
>
>> On 2013-06-17 10:09, Dave Raggett wrote:
>>
>>> Non-proprietary sync is the next step
>>>
>>
>> That is exactly what "remote storage" tries to propose: a non-proprietary
>> protocol that does something like Dropbox/GoogleDrive/SkyDrive over
>> cross-origin HTTP.
>>
>> We uploaded the -01 version of the I-D last week:
>>
>>     http://www.ietf.org/id/draft-**dejong-remotestorage-01.txt<http://www.ietf.org/id/draft-dejong-remotestorage-01.txt>
>> ______________________________**_________________
>> apps-discuss mailing list
>> apps-discuss@ietf.org
>> https://www.ietf.org/mailman/**listinfo/apps-discuss<https://www.ietf.org/mailman/listinfo/apps-discuss>
>>
>
>
>
> --
> Website: http://hallambaker.com/
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>

--089e0158c76c11488804df584d78
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 17 June 2013 13:42, Phillip Hallam-Baker <span dir=3D"ltr">&lt;<=
a href=3D"mailto:hallam@gmail.com" target=3D"_blank">hallam@gmail.com</a>&g=
t;</span> wrote:<br>
<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 dir=3D"ltr">Interest=
ing idea. I was thinking about a similar scheme only with the data being en=
crypted on the storage drive and a decryption key issued bound to each devi=
ce authorized to read. The idea being to leverage the Ford-Wiener model of =
CRM which is coming out of patent very soon.<div>

<br></div><div>Much of the protocol complexity of this type of scheme ends =
up being how the end user establishes a device as authorized to access thei=
r account. When I wrote Omnibroker I discovered that ended up being about 8=
0% of the protocol and the actual query-response piece was very straightfor=
ward.</div>

<div><br></div><div>Since this piece is applicable to many similar Web Serv=
ices, I took it out and made it a separate draft as Web Services Connect:</=
div><div><br></div><div><a href=3D"http://tools.ietf.org/html/draft-hallamb=
aker-wsconnect-02" target=3D"_blank">http://tools.ietf.org/html/draft-halla=
mbaker-wsconnect-02</a><br>
</div></div></blockquote><div><br></div><div>Also in this space:<br><br>The=
 mission of the Linked Data Platform (LDP) Working Group is to produce a W3=
C Recommendation for HTTP-based (RESTful) application integration patterns =
using read/write Linked Data. This work will benefit both small-scale in-br=
owser applications (WebApps) and large-scale Enterprise Application Integra=
tion (EAI) efforts. It will complement SPARQL and will be compatible with s=
tandards for publishing Linked Data, bringing the data integration features=
 of RDF to RESTful, data-oriented software development<br>
<br><a href=3D"http://www.w3.org/2012/ldp/charter">http://www.w3.org/2012/l=
dp/charter</a><br><br></div><div>It&#39;s the combined effort of about 30 f=
irms including IBM, Fujitsu, Apache, Oracle, BBC and more.<br><br>This is e=
xpected to become a W3C REC around March 2014<br>
</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div =
dir=3D"ltr"><div>
</div><div><br></div><div>One issue that I have is working out what to call=
 it as &quot;=A0Web Services *&quot; has been effectively grabbed by the SO=
AP/WS* crowd. And this is a JSON protocol. I changed to JSON Connect (JCX) =
but I don&#39;t like that either.</div>

<div><br></div><div><br></div><div><br></div></div><div class=3D"gmail_extr=
a"><div><div class=3D"h5"><br><br><div class=3D"gmail_quote">On Mon, Jun 17=
, 2013 at 7:08 AM, Michiel B. de Jong <span dir=3D"ltr">&lt;<a href=3D"mail=
to:anything@michielbdejong.com" target=3D"_blank">anything@michielbdejong.c=
om</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex">On 2013-06-17 10:09, Dave=
 Raggett wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex">
Non-proprietary sync is the next step<br>
</blockquote>
<br>
That is exactly what &quot;remote storage&quot; tries to propose: a non-pro=
prietary protocol that does something like Dropbox/GoogleDrive/SkyDrive ove=
r cross-origin HTTP.<br>
<br>
We uploaded the -01 version of the I-D last week:<br>
<br>
=A0 =A0 <a href=3D"http://www.ietf.org/id/draft-dejong-remotestorage-01.txt=
" target=3D"_blank">http://www.ietf.org/id/draft-<u></u>dejong-remotestorag=
e-01.txt</a><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>
</blockquote></div><br><br clear=3D"all"><div><br></div></div></div><span c=
lass=3D""><font color=3D"#888888">-- <br>Website: <a href=3D"http://hallamb=
aker.com/" target=3D"_blank">http://hallambaker.com/</a><br>
</font></span></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></div>

--089e0158c76c11488804df584d78--

From bobwyman@gmail.com  Mon Jun 17 08:23:57 2013
Return-Path: <bobwyman@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51AAA21F9CA4 for <apps-discuss@ietfa.amsl.com>; Mon, 17 Jun 2013 08:23:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.311
X-Spam-Level: 
X-Spam-Status: No, score=-0.311 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EFID9lOL2ZKM for <apps-discuss@ietfa.amsl.com>; Mon, 17 Jun 2013 08:23:54 -0700 (PDT)
Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 2F05121F9D00 for <apps-discuss@ietf.org>; Mon, 17 Jun 2013 08:23:50 -0700 (PDT)
Received: by mail-wg0-f43.google.com with SMTP id z11so2464929wgg.34 for <apps-discuss@ietf.org>; Mon, 17 Jun 2013 08:23:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=uvie3JvSPlJOj09UPzkpRPBM31+HBSyySZZsE0wsZ+U=; b=IkbKGimZYTdg3JdGCcmVXntC3p/Wbf7LAk8aF1otWZIruPcnWYKKNTRzliwWiAP2uN 6Id265WOr/kdUYMII7Lsa+ZUOfv6LNdhkGmOrRQ+PhGx+w4SZtQ6prrU3AFVB1M1j+9r ngL8W6GNMDSV60YzIT3WgcJW9D9DBiiLuldZuwKwvO+oujwcEhAnPyTtfkb/g/810EdZ wFaSNFx32ArurndVRtUWC4DI5X2xRMhq9STnoI6CxfAui5JV3FznqJ+6Hzw4FuInwkmo ntok+rFriV6r0lbHW76hbuT04zQoSR/15HaJu/VgBUS41LNX7G3/EaM6/snPoFK7SS4r Rhjg==
MIME-Version: 1.0
X-Received: by 10.180.100.35 with SMTP id ev3mr5187001wib.12.1371482629000; Mon, 17 Jun 2013 08:23:49 -0700 (PDT)
Sender: bobwyman@gmail.com
Received: by 10.194.125.200 with HTTP; Mon, 17 Jun 2013 08:23:48 -0700 (PDT)
In-Reply-To: <73e44da4d86c0e17a2d57a9ef736a10f@michielbdejong.com>
References: <p06240800ccc189b2c3ff@192.168.0.101> <43892743-D4CD-4137-B3BD-BCA321D9CE41@dsv.su.se> <CAL0qLwb8OiaTUcn3dP+eWjrQbKk1U3CiV42DOhP=+4Ho3kmKSw@mail.gmail.com> <CAMm+LwgyGWvccMSDZmzT+bD7Dx+9E2eF8+f92M=-VjWkE6Wz3w@mail.gmail.com> <51BEC43B.8020804@w3.org> <73e44da4d86c0e17a2d57a9ef736a10f@michielbdejong.com>
Date: Mon, 17 Jun 2013 11:23:48 -0400
X-Google-Sender-Auth: ffmbNH5I6Yu1eRxzSQ4MZi6lCak
Message-ID: <CAA1s49X1hnWC0qmXX=4CC83K1TjsZm=hapooJkh6=5ZMbcwgUQ@mail.gmail.com>
From: Bob Wyman <bob@wyman.us>
To: "Michiel B. de Jong" <anything@michielbdejong.com>
Content-Type: multipart/alternative; boundary=f46d044282a6eadc4c04df5b2e6c
Cc: Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Non-proprietary sync (was Re: Is e-mail going to die?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 17 Jun 2013 15:23:57 -0000

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

Reading remoteStorage, I can't help seeing another excuse to rehash the
"folders" vs "labels" debate. "Folders" typically imply some sort of
containment and a unique location-based address for an object while labels
are attributes and allow a single document to be viewed as having a variety
of retrieval specifications. (i.e. you can retrieve based on any attribute
or set of attributes.)

Why do you introduce the complexity of "folders" in this proposal? Why not
just have document PUT and GET and define a "document collection" (aka:
folder) type? Then, "folders" would simply be documents that could be
fetched. One assumes that a 'document collection" would be able to link to
another "document collection" (i.e. either a sub or parent folder) and that
there would be a "well-known" name for that document collection which would
correspond to a "root" folder. Also, it would be good if there were no
binding between a document's retrieval name (URI) and the folder-paths or
set of attributes associated with it. The metadata for a document can often
change even if the document doesn't change and in many applications, the
folder-path or attributes can reveal information that has a higher security
level than the document itself. Thus, it would be good to allow at least
fetching of documents without knowledge of meta-data other than the
document's potentially opaque URI.

bob wyman



On Mon, Jun 17, 2013 at 7:08 AM, Michiel B. de Jong <
anything@michielbdejong.com> wrote:

> On 2013-06-17 10:09, Dave Raggett wrote:
>
>> Non-proprietary sync is the next step
>>
>
> That is exactly what "remote storage" tries to propose: a non-proprietary
> protocol that does something like Dropbox/GoogleDrive/SkyDrive over
> cross-origin HTTP.
>
> We uploaded the -01 version of the I-D last week:
>
>     http://www.ietf.org/id/draft-**dejong-remotestorage-01.txt<http://www.ietf.org/id/draft-dejong-remotestorage-01.txt>
> ______________________________**_________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/**listinfo/apps-discuss<https://www.ietf.org/mailman/listinfo/apps-discuss>
>

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

<div dir=3D"ltr">Reading=A0<span style=3D"color:rgb(0,0,0);white-space:pre-=
wrap">remoteStorage, I can&#39;t help seeing another excuse to rehash the &=
quot;folders&quot; vs &quot;labels&quot; debate. &quot;Folders&quot; typica=
lly imply some sort of containment and a unique location-based address for =
an object while labels are attributes and allow a single document to be vie=
wed as having a variety of retrieval specifications. (i.e. you can retrieve=
 based on any attribute or set of attributes.)</span><div>
<span style=3D"color:rgb(0,0,0);white-space:pre-wrap"><br></span></div><div=
 style><span style=3D"color:rgb(0,0,0);white-space:pre-wrap">Why do you int=
roduce the complexity of &quot;folders&quot; in this proposal? Why not just=
 have document PUT and GET and define a &quot;document collection&quot; (ak=
a: folder) type? Then, &quot;folders&quot; would simply be documents that c=
ould be fetched.  One assumes that a &#39;document collection&quot; would b=
e able to link to another &quot;document collection&quot; (i.e. either a su=
b or parent folder) and that there would be a &quot;well-known&quot; name f=
or that document collection which would correspond to a &quot;root&quot; fo=
lder. Also, it would be good if there were no binding between a document&#3=
9;s retrieval name (URI) and the folder-paths or set of attributes associat=
ed with it. The metadata for a document can often change even if the docume=
nt doesn&#39;t change and in many applications, the folder-path or attribut=
es can reveal information that has a higher security level than the documen=
t itself. Thus, it would be good to allow at least fetching of documents wi=
thout knowledge of meta-data other than the document&#39;s potentially opaq=
ue URI.</span></div>
<div style><span style=3D"color:rgb(0,0,0);white-space:pre-wrap"><br></span=
></div><div style><span style=3D"color:rgb(0,0,0);white-space:pre-wrap">bob=
 wyman</span></div><div style><span style=3D"color:rgb(0,0,0);white-space:p=
re-wrap"><br>
</span></div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_q=
uote">On Mon, Jun 17, 2013 at 7:08 AM, Michiel B. de Jong <span dir=3D"ltr"=
>&lt;<a href=3D"mailto:anything@michielbdejong.com" target=3D"_blank">anyth=
ing@michielbdejong.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">On 2013-06-17 10:09, Dave Raggett wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Non-proprietary sync is the next step<br>
</blockquote>
<br>
That is exactly what &quot;remote storage&quot; tries to propose: a non-pro=
prietary protocol that does something like Dropbox/GoogleDrive/SkyDrive ove=
r cross-origin HTTP.<br>
<br>
We uploaded the -01 version of the I-D last week:<br>
<br>
=A0 =A0 <a href=3D"http://www.ietf.org/id/draft-dejong-remotestorage-01.txt=
" target=3D"_blank">http://www.ietf.org/id/draft-<u></u>dejong-remotestorag=
e-01.txt</a><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>
</blockquote></div><br></div>

--f46d044282a6eadc4c04df5b2e6c--

From anything@michielbdejong.com  Mon Jun 17 08:37:20 2013
Return-Path: <anything@michielbdejong.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E3D321F9CFE for <apps-discuss@ietfa.amsl.com>; Mon, 17 Jun 2013 08:37:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.318
X-Spam-Level: 
X-Spam-Status: No, score=-3.318 tagged_above=-999 required=5 tests=[AWL=0.129,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vKTd45ON-oxw for <apps-discuss@ietfa.amsl.com>; Mon, 17 Jun 2013 08:37:14 -0700 (PDT)
Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) by ietfa.amsl.com (Postfix) with ESMTP id E39D321F9CCF for <apps-discuss@ietf.org>; Mon, 17 Jun 2013 08:37:13 -0700 (PDT)
Received: from mfilter15-d.gandi.net (mfilter15-d.gandi.net [217.70.178.143]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id C8CE3A80E9; Mon, 17 Jun 2013 17:37:00 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter15-d.gandi.net
Received: from relay3-d.mail.gandi.net ([217.70.183.195]) by mfilter15-d.gandi.net (mfilter15-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id ClOBmA+2M6GM; Mon, 17 Jun 2013 17:36:59 +0200 (CEST)
X-Originating-IP: 10.58.1.143
Received: from webmail.gandi.net (unknown [10.58.1.143]) (Authenticated sender: anything@michielbdejong.com) by relay3-d.mail.gandi.net (Postfix) with ESMTPA id 4AFCBA80B9; Mon, 17 Jun 2013 17:36:58 +0200 (CEST)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Date: Mon, 17 Jun 2013 17:36:58 +0200
From: "Michiel B. de Jong" <anything@michielbdejong.com>
To: Bob Wyman <bob@wyman.us>
In-Reply-To: <CAA1s49X1hnWC0qmXX=4CC83K1TjsZm=hapooJkh6=5ZMbcwgUQ@mail.gmail.com>
References: <p06240800ccc189b2c3ff@192.168.0.101> <43892743-D4CD-4137-B3BD-BCA321D9CE41@dsv.su.se> <CAL0qLwb8OiaTUcn3dP+eWjrQbKk1U3CiV42DOhP=+4Ho3kmKSw@mail.gmail.com> <CAMm+LwgyGWvccMSDZmzT+bD7Dx+9E2eF8+f92M=-VjWkE6Wz3w@mail.gmail.com> <51BEC43B.8020804@w3.org> <73e44da4d86c0e17a2d57a9ef736a10f@michielbdejong.com> <CAA1s49X1hnWC0qmXX=4CC83K1TjsZm=hapooJkh6=5ZMbcwgUQ@mail.gmail.com>
Message-ID: <81ecc4272738703c681959108251e8c9@michielbdejong.com>
X-Sender: anything@michielbdejong.com
User-Agent: Roundcube Webmail/0.7.2
Cc: Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] =?utf-8?q?Non-proprietary_sync_=28was_Re=3A_Is_e-m?= =?utf-8?q?ail_going_to_die=3F?=
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 17 Jun 2013 15:37:20 -0000

On 2013-06-17 17:23, Bob Wyman wrote:
> Why do you introduce the complexity of "folders" in this proposal? 
> Why
> not just have document PUT and GET and define a "document collection"
> (aka: folder) type? Then, "folders" would simply be documents that
> could be fetched. One assumes that a document collection" would be
> able to link to another "document collection" (i.e. either a sub or
> parent folder) and that there would be a "well-known" name for that
> document collection which would correspond to a "root" folder.

thanks for asking that question! The reason is that the tree structure, 
with folder versioning, allows a client to retrieve the root of a 
subtree, see if its ETag changed, and if not, know for sure that none of 
the contained documents changed. If folders were mere tags/pointers, 
then a client would have to check for changes in each document 
individually, which would be much more work.

From patrickdlogan@gmail.com  Mon Jun 17 10:02:29 2013
Return-Path: <patrickdlogan@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 635BE21F9B2F for <apps-discuss@ietfa.amsl.com>; Mon, 17 Jun 2013 10:02:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.307
X-Spam-Level: 
X-Spam-Status: No, score=-1.307 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MISSING_HEADERS=1.292]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IK9Csaxo4E6G for <apps-discuss@ietfa.amsl.com>; Mon, 17 Jun 2013 10:02:15 -0700 (PDT)
Received: from mail-pd0-f180.google.com (mail-pd0-f180.google.com [209.85.192.180]) by ietfa.amsl.com (Postfix) with ESMTP id 5CB7221F99B4 for <apps-discuss@ietf.org>; Mon, 17 Jun 2013 10:02:15 -0700 (PDT)
Received: by mail-pd0-f180.google.com with SMTP id 10so2975702pdi.39 for <apps-discuss@ietf.org>; Mon, 17 Jun 2013 10:02:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; bh=BX6YUx07SBvlDnZuyOp6HTdd6M2b76tyKMHaUkNiESA=; b=jc7C/WReipYUN87mwNFv+GeMPYRdncUJoaHRsL9eqgXOv7NX7vD48cPWFclwf8/ZCN /w9l/8p519keu2bsHy4/1XIBslz388WLImurOKiiDIag8LeF0noltiUHsqqHyTWbPXdm 1uW41Dl3+21aPl9JrEoWdK8C7k3i9pOSS88R1Sk/m7iwjLaUN6nf/jQo8kIA03EFSga2 oyw03hbS87afIL0z0ideeYBAA7UHTevfcr52mlYYHdW7USbhNRptmuwBvqDdW400OedK xePhfyka3HT5pPI960A1Wr8buyBhf3y6r2wZEbsqq9bLZtBYI3+czb8hjx3+289ihSS9 iwHQ==
MIME-Version: 1.0
X-Received: by 10.66.13.8 with SMTP id d8mr14101007pac.4.1371488524226; Mon, 17 Jun 2013 10:02:04 -0700 (PDT)
Received: by 10.70.93.1 with HTTP; Mon, 17 Jun 2013 10:02:04 -0700 (PDT)
In-Reply-To: <51BEC43B.8020804@w3.org>
References: <p06240800ccc189b2c3ff@192.168.0.101> <43892743-D4CD-4137-B3BD-BCA321D9CE41@dsv.su.se> <CAL0qLwb8OiaTUcn3dP+eWjrQbKk1U3CiV42DOhP=+4Ho3kmKSw@mail.gmail.com> <CAMm+LwgyGWvccMSDZmzT+bD7Dx+9E2eF8+f92M=-VjWkE6Wz3w@mail.gmail.com> <51BEC43B.8020804@w3.org>
Date: Mon, 17 Jun 2013 10:02:04 -0700
Message-ID: <CAD_aa-8Uw5SQ5uaPycNbpsGgZ5H8e+M4Vey_8OWJi-dG5wdx5w@mail.gmail.com>
From: Patrick Logan <patrickdlogan@gmail.com>
Cc: apps-discuss@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [apps-discuss] Is e-mail going to die?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 17 Jun 2013 17:02:29 -0000

Clearly if there will be a "death of email"  it will be a long, slow,
painful death for the reasons given. Almost as clearly, the use of
email has shifted. As people pointed out we hardly distribute photos
via email, we hardly announce things via email.

But as people pointed out, there's still not a good way to send
secure, encrypted, and/or signed messages via email (or any other
standard protocol.) Also "RSS is dead", etc.

My position would be "although email will be here for a long time to
come, the landscape of standard messaging is still wide open".

In the short run I would look at emerging standards like Web Keys [1]
and HTTP Signatures [2] to contribute to a improved messaging systems.

In the long run I would look at something like Named Data Networking
[3] which has a really good general solution to many problems of
messaging today, including email. But NDN is not a new layer 7
protocol. It's a redesign influenced by IP, not dependent on IP,
intended to be deployed alongside IP based on what we know now about
the internet.

[1] https://payswarm.com/specs/source/web-keys/#messaging
[2] http://tools.ietf.org/html/draft-cavage-http-signatures-00
[3] http://www.named-data.net/


On Mon, Jun 17, 2013 at 1:09 AM, Dave Raggett <dsr@w3.org> wrote:
> On 16/06/13 15:35, Phillip Hallam-Baker wrote:
>
>
> A more interesting question is whether chat/IM/video is ever going to escape
> completely from closed communities. It looked like that was going to happen
> but it doesn't seem to have done in the same way as email. People tell me to
> get a Yahoo account or a Skype account or whatever just to chat which is a
> stupid situation.
>
>
> This is where a federated approach based upon personal zones may help. In
> the EU FP7 project "webinos" [1] we have been exploring the concept of a
> personal zone which encompasses your personal devices and services with each
> device being secured as part of the zone.  The zone is exposed 24x7 by a hub
> on which can you install personal services. Our implementation is based upon
> Node.JS.  The hub could be hosted by your ISP in the cloud, or run on a home
> gateway device. Finger can then be used to find the URI for someone's hub
> based upon their email address.
>
> We are already seeing browser sync across devices, but only for the same
> brand of browser. Non-proprietary sync is the next step and will require
> some notion akin to the webinos personal zone, as users will in most cases
> have devices and browsers from different vendors. The notion is also
> relevant to managing privacy and security, especially for services based
> upon the Internet of Things. In conclusion, I agree that email is here to
> stay, but federated services for chat etc. are likely to emerge as a result
> of consumer pressure for non-proprietary means for managing a collection of
> personal devices and services.
>
> [1] http://www.webinos.org/
>
> --
> Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett
>
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

From melvincarvalho@gmail.com  Mon Jun 17 10:21:06 2013
Return-Path: <melvincarvalho@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFB5221F934C for <apps-discuss@ietfa.amsl.com>; Mon, 17 Jun 2013 10:21:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.35
X-Spam-Level: 
X-Spam-Status: No, score=-1.35 tagged_above=-999 required=5 tests=[AWL=-0.416,  BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Eup0NMGNv51 for <apps-discuss@ietfa.amsl.com>; Mon, 17 Jun 2013 10:21:04 -0700 (PDT)
Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id A66AD21F93D7 for <apps-discuss@ietf.org>; Mon, 17 Jun 2013 10:21:01 -0700 (PDT)
Received: by mail-la0-f54.google.com with SMTP id ec20so2640525lab.41 for <apps-discuss@ietf.org>; Mon, 17 Jun 2013 10:21:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EQ855rbrNmcOXRisYUQn5hdAMYxq+xGlL6zqdjJIB6A=; b=GHJRRYk8tR8HiH3EnTMAMxRF4C5gAcVBi+Nbh3w2kTd7KERF46GqqQlMtQHCHJQzvK lEh1rWgWzvx7bb3h/RoqH7M3K+EJGoH4tU8QQ2ENUZaPwsvJANHdgKUbg+jNa+eH4I3M MokqiSzjWxbRcMw7gZmdDs7TGj/d/+t7Q7knvaXgw+0ZwHyBsXPwAyrtOETHaqKppPT/ /j7BXa3M17fUJLDRmjDF5pUS5d6JwyZSbQTz+JkHL4BL0w6pDaJqYTg+yxd6s4h3rjTR jOBA0nKrdJi9faDgxnpYHjeoykYKNrKr5WbyOrQa3rGX+zDhWjXz44Kfh0N9T9dQ7Yx4 Ve7g==
MIME-Version: 1.0
X-Received: by 10.112.219.133 with SMTP id po5mr6692587lbc.80.1371489660226; Mon, 17 Jun 2013 10:21:00 -0700 (PDT)
Received: by 10.112.2.8 with HTTP; Mon, 17 Jun 2013 10:21:00 -0700 (PDT)
In-Reply-To: <CAA1s49X1hnWC0qmXX=4CC83K1TjsZm=hapooJkh6=5ZMbcwgUQ@mail.gmail.com>
References: <p06240800ccc189b2c3ff@192.168.0.101> <43892743-D4CD-4137-B3BD-BCA321D9CE41@dsv.su.se> <CAL0qLwb8OiaTUcn3dP+eWjrQbKk1U3CiV42DOhP=+4Ho3kmKSw@mail.gmail.com> <CAMm+LwgyGWvccMSDZmzT+bD7Dx+9E2eF8+f92M=-VjWkE6Wz3w@mail.gmail.com> <51BEC43B.8020804@w3.org> <73e44da4d86c0e17a2d57a9ef736a10f@michielbdejong.com> <CAA1s49X1hnWC0qmXX=4CC83K1TjsZm=hapooJkh6=5ZMbcwgUQ@mail.gmail.com>
Date: Mon, 17 Jun 2013 19:21:00 +0200
Message-ID: <CAKaEYhJ+FnnW517q27YXJTbT5iNFBZQV7vSkRPE4vG+X5b+C+A@mail.gmail.com>
From: Melvin Carvalho <melvincarvalho@gmail.com>
To: Bob Wyman <bob@wyman.us>
Content-Type: multipart/alternative; boundary=001a11c32ed802d1ea04df5cd2ba
Cc: Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Non-proprietary sync (was Re: Is e-mail going to die?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 17 Jun 2013 17:21:06 -0000

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

On 17 June 2013 17:23, Bob Wyman <bob@wyman.us> wrote:

> Reading remoteStorage, I can't help seeing another excuse to rehash the
> "folders" vs "labels" debate. "Folders" typically imply some sort of
> containment and a unique location-based address for an object while labels
> are attributes and allow a single document to be viewed as having a variety
> of retrieval specifications. (i.e. you can retrieve based on any attribute
> or set of attributes.)
>
> Why do you introduce the complexity of "folders" in this proposal? Why not
> just have document PUT and GET and define a "document collection" (aka:
> folder) type? Then, "folders" would simply be documents that could be
> fetched. One assumes that a 'document collection" would be able to link to
> another "document collection" (i.e. either a sub or parent folder) and that
> there would be a "well-known" name for that document collection which would
> correspond to a "root" folder. Also, it would be good if there were no
> binding between a document's retrieval name (URI) and the folder-paths or
> set of attributes associated with it. The metadata for a document can often
> change even if the document doesn't change and in many applications, the
> folder-path or attributes can reveal information that has a higher security
> level than the document itself. Thus, it would be good to allow at least
> fetching of documents without knowledge of meta-data other than the
> document's potentially opaque URI.
>

The Resource / Container pattern seems to have some traction.  It may be of
interest the way that Linked Data Platform Containers are modelled:

https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html#linked-data-platform-containers


>
> bob wyman
>
>
>
> On Mon, Jun 17, 2013 at 7:08 AM, Michiel B. de Jong <
> anything@michielbdejong.com> wrote:
>
>> On 2013-06-17 10:09, Dave Raggett wrote:
>>
>>> Non-proprietary sync is the next step
>>>
>>
>> That is exactly what "remote storage" tries to propose: a non-proprietary
>> protocol that does something like Dropbox/GoogleDrive/SkyDrive over
>> cross-origin HTTP.
>>
>> We uploaded the -01 version of the I-D last week:
>>
>>     http://www.ietf.org/id/draft-**dejong-remotestorage-01.txt<http://www.ietf.org/id/draft-dejong-remotestorage-01.txt>
>> ______________________________**_________________
>> apps-discuss mailing list
>> apps-discuss@ietf.org
>> https://www.ietf.org/mailman/**listinfo/apps-discuss<https://www.ietf.org/mailman/listinfo/apps-discuss>
>>
>
>
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>

--001a11c32ed802d1ea04df5cd2ba
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 17 June 2013 17:23, Bob Wyman <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:bob@wyman.us" target=3D"_blank">bob@wyman.us</a>&gt;</span> wrote:<br=
><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 dir=3D"ltr">Reading=A0<span style=3D"white-space:pre-wrap">remoteStora=
ge, I can&#39;t help seeing another excuse to rehash the &quot;folders&quot=
; vs &quot;labels&quot; debate. &quot;Folders&quot; typically imply some so=
rt of containment and a unique location-based address for an object while l=
abels are attributes and allow a single document to be viewed as having a v=
ariety of retrieval specifications. (i.e. you can retrieve based on any att=
ribute or set of attributes.)</span><div>

<span style=3D"white-space:pre-wrap"><br></span></div><div><span style=3D"w=
hite-space:pre-wrap">Why do you introduce the complexity of &quot;folders&q=
uot; in this proposal? Why not just have document PUT and GET and define a =
&quot;document collection&quot; (aka: folder) type? Then, &quot;folders&quo=
t; would simply be documents that could be fetched.  One assumes that a &#3=
9;document collection&quot; would be able to link to another &quot;document=
 collection&quot; (i.e. either a sub or parent folder) and that there would=
 be a &quot;well-known&quot; name for that document collection which would =
correspond to a &quot;root&quot; folder. Also, it would be good if there we=
re no binding between a document&#39;s retrieval name (URI) and the folder-=
paths or set of attributes associated with it. The metadata for a document =
can often change even if the document doesn&#39;t change and in many applic=
ations, the folder-path or attributes can reveal information that has a hig=
her security level than the document itself. Thus, it would be good to allo=
w at least fetching of documents without knowledge of meta-data other than =
the document&#39;s potentially opaque URI.</span></div>
</div></blockquote><div><br></div><div>The Resource / Container pattern see=
ms to have some traction.=A0 It may be of interest the way that Linked Data=
 Platform Containers are modelled:<br><br><a href=3D"https://dvcs.w3.org/hg=
/ldpwg/raw-file/default/ldp.html#linked-data-platform-containers">https://d=
vcs.w3.org/hg/ldpwg/raw-file/default/ldp.html#linked-data-platform-containe=
rs</a><br>
</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div =
dir=3D"ltr"><span class=3D""><font color=3D"#888888">
<div><span style=3D"white-space:pre-wrap"><br></span></div><div><span style=
=3D"white-space:pre-wrap">bob wyman</span></div><div><span style=3D"white-s=
pace:pre-wrap"><br>
</span></div></font></span></div><div class=3D"gmail_extra"><br><br><div cl=
ass=3D"gmail_quote"><div class=3D"im">On Mon, Jun 17, 2013 at 7:08 AM, Mich=
iel B. de Jong <span dir=3D"ltr">&lt;<a href=3D"mailto:anything@michielbdej=
ong.com" target=3D"_blank">anything@michielbdejong.com</a>&gt;</span> wrote=
:<br>

</div><div><div class=3D"h5"><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex">On 2013-06-17 10:09, Dave Raggett wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex">
Non-proprietary sync is the next step<br>
</blockquote>
<br>
That is exactly what &quot;remote storage&quot; tries to propose: a non-pro=
prietary protocol that does something like Dropbox/GoogleDrive/SkyDrive ove=
r cross-origin HTTP.<br>
<br>
We uploaded the -01 version of the I-D last week:<br>
<br>
=A0 =A0 <a href=3D"http://www.ietf.org/id/draft-dejong-remotestorage-01.txt=
" target=3D"_blank">http://www.ietf.org/id/draft-<u></u>dejong-remotestorag=
e-01.txt</a><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>
</blockquote></div></div></div><br></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></div>

--001a11c32ed802d1ea04df5cd2ba--

From johnl@taugh.com  Mon Jun 17 12:26:08 2013
Return-Path: <johnl@taugh.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA7C21F8FF3 for <apps-discuss@ietfa.amsl.com>; Mon, 17 Jun 2013 12:26:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.467
X-Spam-Level: 
X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[AWL=0.133,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lSlCVTB3kJvp for <apps-discuss@ietfa.amsl.com>; Mon, 17 Jun 2013 12:26:07 -0700 (PDT)
Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id AB9F021F84AF for <apps-discuss@ietf.org>; Mon, 17 Jun 2013 12:26:03 -0700 (PDT)
Received: (qmail 59207 invoked from network); 17 Jun 2013 19:26:02 -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=e745.51bf62ca.k1306; bh=ti9R00nb9wT4q62NopZn3YkQdw+ZgmHFh8buV8lMDgc=; b=m9W4WoI51hgyHHq0sUgWo5zwuXroZ/oAqMeAWW6oPrqZyQvdpXqHMXr0TI/5VTIexjXzBbvhKa2K4axOlJs/i30NSCMsrxTbwzZBfxKrKlDnnh4fZ4TahN1XjVkDkCV19TP+GYBSM8rJH19wOEPpCunmLPsOwNlETKzToQhg+D6PNvPpWaiKAo1pRVEqLQ+t8lRUirjzrmAue51nTZQFmgLxKs+RxCB3kaL7ahbAkso0QylV+m5daymdVnaQ0GEj
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=e745.51bf62ca.k1306; bh=ti9R00nb9wT4q62NopZn3YkQdw+ZgmHFh8buV8lMDgc=; b=m4UyxLNgBgEhdEpDlv4IWvAP5Txpkg3w64XkaV0OubC2p2iaFQxXWX+QYQo1oZ7pjgNCUuIJWdV0ZpFyuq66UNwaskhJKrN2NjHuDifyBZB8RC1WsLDnmzvDRMmRozKMTg1SaSG1+EI7lOQJW5JMQi10xetJuwRHq0cyXmM3T238s2sr6YUVEf2AufPaanGjRBGOEk4/qF/rWTpUAFUjQ4MuPyxv1QmfLkESPUXpB8rmQ0OTN1LxGCmk221DJEJ2
Received: (ofmipd 127.0.0.1); 17 Jun 2013 19:25:40 -0000
Date: 17 Jun 2013 15:26:02 -0400
Message-ID: <alpine.BSF.2.00.1306171525200.98473@joyce.lan>
From: "John R Levine" <johnl@taugh.com>
To: "Patrick Logan" <patrickdlogan@gmail.com>
In-Reply-To: <CAD_aa-8Uw5SQ5uaPycNbpsGgZ5H8e+M4Vey_8OWJi-dG5wdx5w@mail.gmail.com>
References: <CAL0qLwb8OiaTUcn3dP+eWjrQbKk1U3CiV42DOhP=+4Ho3kmKSw@mail.gmail.com> <CAMm+LwgyGWvccMSDZmzT+bD7Dx+9E2eF8+f92M=-VjWkE6Wz3w@mail.gmail.com> <p06240800ccc189b2c3ff@192.168.0.101> <51BEC43B.8020804@w3.org> <43892743-D4CD-4137-B3BD-BCA321D9CE41@dsv.su.se> <CAD_aa-8Uw5SQ5uaPycNbpsGgZ5H8e+M4Vey_8OWJi-dG5wdx5w@mail.gmail.com>
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
Cleverness: None detected
MIME-Version: 1.0
Content-Type: MULTIPART/signed; protocol="application/pkcs7-signature"; micalg=sha1; BOUNDARY="3825401791-674987168-1371497162=:98473"
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Is e-mail going to die?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 17 Jun 2013 19:26:08 -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.

--3825401791-674987168-1371497162=:98473
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

> But as people pointed out, there's still not a good way to send
> secure, encrypted, and/or signed messages via email (or any other
> standard protocol.) Also "RSS is dead", etc.

The technology is there, but the usual key distribution problems apply.

Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.
--3825401791-674987168-1371497162=:98473
Content-Type: APPLICATION/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: BASE64
Content-Description: S/MIME Cryptographic Signature
Content-Disposition: attachment; filename=smime.p7s

MIIJCQYJKoZIhvcNAQcCoIII+jCCCPYCAQExCzAJBgUrDgMCGgUAMAsGCSqG
SIb3DQEHAaCCBjowggY2MIIFHqADAgECAgMGLywwDQYJKoZIhvcNAQEFBQAw
gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD
VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTAeFw0xMzAzMTYxOTQ0MDdaFw0xNDAzMTgxMjI4MzVaMFUxGTAX
BgNVBA0TEHFaMXRuOTBuMkdVODZzemYxGDAWBgNVBAMMD2pvaG5sQHRhdWdo
LmNvbTEeMBwGCSqGSIb3DQEJARYPam9obmxAdGF1Z2guY29tMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAve/4NFMbuvtD6QSuXAoYQ0SkaO9s
DiNHA4saJNV0OIXd6dtM87w7OETKWWVq24Ab6vQaYh218oCF1GDdLv6EiRB8
oL1k9sK2v70iAVT83vEnmaj6/hQVcBI6mZJH6LXyCgYSP2e5yBQqJu+hgLte
bdg7kOKW2tb937jDn9KYRVFIlEU0/iu/b/Buwq3ahg2BsG3vg92Zk+Dv5VON
QDLE8x8wdi1cor7qBY/RERw4O3LXo3644OU0t6KS3aQxLrXEvWZHHvLhsAu1
BjYbC+qdSddDT1t+adEnZq9/wMhNGhPWCd/uFDZanSpyM913b7eI1Q2aNgA0
cccjEgBsp8IipwIDAQABo4IC1TCCAtEwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSL
djRDW8NpGZJjlhjZ0SLge0hCvjAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6W
NU7y1LhRgjAaBgNVHREEEzARgQ9qb2hubEB0YXVnaC5jb20wggFMBgNVHSAE
ggFDMIIBPzCCATsGCysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0
cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjCB9wYIKwYBBQUHAgIw
geowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqB
vlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhl
IENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0
Q29tIENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVk
IHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBv
YmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5zdGFy
dHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5Bggr
BgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEv
Y2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNv
bS9jZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYY
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQCM
pgcOpxRJazPzEBYnhGENuQqzXeLyA3a8XL7YaxaAJwV7ucDVkyQHu35PUEkh
vVgIKnxq6N9WxHiO6GK/imdwS3LrUBbs+0v+95m6YhJv6ZfvAHTyTLqrozXU
ohR5NRFeL0p1OfK1llnl/I71Fe/JNgxJHDn1puzsFoJD3zYCKgNdST3FPNIb
2v/xIiubuB85tiJSWUlc56OkCdBK3ZgBnwYV8LxFmpOlwedaHC6sxIk1rsuX
BHbRIJwLFy2LqVtNm0M5NzBVyPQf72lPn/aaJLbqY5DDm4/lSy94R+CKXabE
6lWan7xmbqdDDlMxGbpMRWV2Cxi5ONp4uNgNcwI6MYIClzCCApMCAQEwgZQw
gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD
VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQQIDBi8sMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqG
SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNjE3MTkyNjAyWjAjBgkqhkiG
9w0BCQQxFgQUyy0FGPfXN8u6sn88y+BSYhzIGiMweQYJKoZIhvcNAQkPMWww
ajALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBAjAKBggq
hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4D
AgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAsId1DKxN80LJ
BCWLj/+xelM/zziNmq+j394DQ8ayS4+XV5I0OkEbxtT1ZG7g0zwAOC5Z2T94
9Y70Um9pgFYqgMcL6mWZd+bPDyEfqxi0lF4u7YJPfosTiN9bJXwxSTzBQrRf
2GhnzuvbJlDFDT2cCViusAJHINx5p9LGuWg3OEVflt2qNsOmKuQwdAqAG3O4
V2oIcAhsjmopJ+ptFWwBmgSNhFMc7YYBv7o/vWW/BmWW82e7XOD0LtGAd/K/
UIl7LaWo63l6p1GGwno9PXDXBGq5AOjnrHy7wR0bz9Uj9MTZGaKhAiJf9rH9
PRD29BrA9POC5IzMty28wyX1/od0Og==

--3825401791-674987168-1371497162=:98473--

From michiel@unhosted.org  Mon Jun 17 04:04:27 2013
Return-Path: <michiel@unhosted.org>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 267E921F8A03 for <apps-discuss@ietfa.amsl.com>; Mon, 17 Jun 2013 04:04:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.425
X-Spam-Level: 
X-Spam-Status: No, score=-0.425 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JR9iYzw0O9md for <apps-discuss@ietfa.amsl.com>; Mon, 17 Jun 2013 04:04:22 -0700 (PDT)
Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 910E221F9BC9 for <apps-discuss@ietf.org>; Mon, 17 Jun 2013 04:02:10 -0700 (PDT)
Received: by mail-pa0-f44.google.com with SMTP id lj1so2749019pab.17 for <apps-discuss@ietf.org>; Mon, 17 Jun 2013 04:02:07 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=oHMZO3fo5LhDJopzUi3avWnlIgYmXk4VDRe99fe1xx8=; b=UXupgS1ZJPrDaccGQKfbY5brGZVXfcbiMCYjWP8SkKCNy4kVMjquXhEUM7gerYZsDl TI+c+WdnRxDu/eR+pGR+v0zHrcBCuz1Ts/mWQZKFVVzEPeL2gUlpBrsrA1ZaYX31x/Wd DflSOdvOnq+vrp9RGZ9+5/gl4ox0S587NI4sB4sC6pnyl3Qp17YNRhQYu8xG+kNnOG67 4N3L8AgEVxUQ6nl+OSWRkpwjoYMSIotd2BquUgFWywu0X1ovA1Ps2Hs6Jb8UPRRO1b8f lK5t6AyW9IeVJbJDflvGF2As3g2j9UOd3V0bRXjnwHfq0FU0HY18GmDEGFBrnIF1aiEk 1AGA==
MIME-Version: 1.0
X-Received: by 10.66.8.69 with SMTP id p5mr12442063paa.57.1371466927783; Mon, 17 Jun 2013 04:02:07 -0700 (PDT)
Received: by 10.68.247.37 with HTTP; Mon, 17 Jun 2013 04:02:07 -0700 (PDT)
X-Originating-IP: [178.19.209.38]
Date: Mon, 17 Jun 2013 13:02:07 +0200
Message-ID: <CA+aD3u0cWrKKtiyS2HcqnSG3XfqLQJ-VLOR18ZhYZMBHewVWhQ@mail.gmail.com>
From: Michiel de Jong <michiel@unhosted.org>
To: Apps Discuss <apps-discuss@ietf.org>
Content-Type: multipart/alternative; boundary=bcaec51f97b50d5b2b04df57879b
X-Gm-Message-State: ALoCoQlAs84WgyjwF6oEosCFsyWgxlz9nsim2dCPSzQDM4doY+tZNflOzI6PdhDesLoYslUkzt0I
X-Mailman-Approved-At: Mon, 17 Jun 2013 12:45:52 -0700
Subject: [apps-discuss] Non-proprietary sync (was Re: Is e-mail going to die?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 17 Jun 2013 11:07:54 -0000

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

On 2013-06-17 10:09, Dave Raggett wrote:
> Non-proprietary sync is the next step

That is exactly what "remote storage" tries to propose: a non-proprietary
protocol that does something like Dropbox/GoogleDrive/SkyDrive over
cross-origin HTTP.

We uploaded the -01 version of the I-D last week:

    http://www.ietf.org/id/draft-dejong-remotestorage-01.txt

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

<div dir=3D"ltr">On 2013-06-17 10:09, Dave Raggett wrote:<br>&gt; Non-propr=
ietary sync is the next step<br><br>That is exactly what &quot;remote stora=
ge&quot; tries to propose: a non-proprietary protocol that does something l=
ike Dropbox/GoogleDrive/SkyDrive over cross-origin HTTP.<br>
<br>We uploaded the -01 version of the I-D last week:<br><br>=A0=A0=A0 <a h=
ref=3D"http://www.ietf.org/id/draft-dejong-remotestorage-01.txt">http://www=
.ietf.org/id/draft-dejong-remotestorage-01.txt</a><br></div>

--bcaec51f97b50d5b2b04df57879b--

From internet-drafts@ietf.org  Mon Jun 17 13:53:51 2013
Return-Path: <internet-drafts@ietf.org>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72F3F21F9BF8; Mon, 17 Jun 2013 13:53:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.511
X-Spam-Level: 
X-Spam-Status: No, score=-102.511 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z68Gq8kGHCYM; Mon, 17 Jun 2013 13:53:50 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ED8C21F9D99; Mon, 17 Jun 2013 13:53:41 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.51.p2
Message-ID: <20130617205341.15641.96770.idtracker@ietfa.amsl.com>
Date: Mon, 17 Jun 2013 13:53:41 -0700
Cc: apps-discuss@ietf.org
Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-acct-uri-05.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 17 Jun 2013 20:53:51 -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(s)       : Peter Saint-Andre
	Filename        : draft-ietf-appsawg-acct-uri-05.txt
	Pages           : 9
	Date            : 2013-06-17

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

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-acct-uri-05


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From stpeter@stpeter.im  Mon Jun 17 13:58:26 2013
Return-Path: <stpeter@stpeter.im>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9F3A21F9E07 for <apps-discuss@ietfa.amsl.com>; Mon, 17 Jun 2013 13:58:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.56
X-Spam-Level: 
X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7LBdvHcMF0D0 for <apps-discuss@ietfa.amsl.com>; Mon, 17 Jun 2013 13:58:22 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 35FA021F9E0C for <apps-discuss@ietf.org>; Mon, 17 Jun 2013 13:58:22 -0700 (PDT)
Received: from ergon.local (unknown [64.101.72.59]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 95A1241189; Mon, 17 Jun 2013 15:12:13 -0600 (MDT)
Message-ID: <51BF786B.9060703@stpeter.im>
Date: Mon, 17 Jun 2013 14:58:19 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <20130617205341.15641.96770.idtracker@ietfa.amsl.com>
In-Reply-To: <20130617205341.15641.96770.idtracker@ietfa.amsl.com>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-acct-uri-05.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 17 Jun 2013 20:58:26 -0000

Based on IESG feedback, added a paragraph about putting a user@host
address into the localpart of an 'acct' URI (percent-encoding the
at-sign when doing so).

On 6/17/13 2:53 PM, internet-drafts@ietf.org wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>  This draft is a work item of the Applications Area Working Group Working Group of the IETF.
> 
> 	Title           : The 'acct' URI Scheme
> 	Author(s)       : Peter Saint-Andre
> 	Filename        : draft-ietf-appsawg-acct-uri-05.txt
> 	Pages           : 9
> 	Date            : 2013-06-17
> 
> 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-05
> 
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-appsawg-acct-uri-05
> 
> 
> 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
> 


-- 
Peter Saint-Andre
https://stpeter.im/



From superuser@gmail.com  Tue Jun 18 00:15:45 2013
Return-Path: <superuser@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA50021F8EFE for <apps-discuss@ietfa.amsl.com>; Tue, 18 Jun 2013 00:15:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i8EcmIS08ZEd for <apps-discuss@ietfa.amsl.com>; Tue, 18 Jun 2013 00:15:45 -0700 (PDT)
Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id E3F0921F8D6D for <apps-discuss@ietf.org>; Tue, 18 Jun 2013 00:15:44 -0700 (PDT)
Received: by mail-wg0-f43.google.com with SMTP id z11so3150739wgg.22 for <apps-discuss@ietf.org>; Tue, 18 Jun 2013 00:15:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=N33SF3i918WhczlAyk3LMBB1dqvJediuiV+JpsbXKYA=; b=dQlaP+bRMw8E1tKKoWPSxBlggnuPXkckod1Fm+gZ1XrRnKSNCcN814gr/49Gv+AUs2 TGh6BfqkRhG/Lsq6zej9aE+T7iFk8y/AAyy9q/lznjAOC8zqqpKM+MPqqUqerBmBBlzz ZylbiuXveQmUKEVEak+3NbU/kcpdmUJvstDNFes0Op4B0i1VobQzJnagSkiPGfADSmRI uW7AtlklCOL2LMaZmoOfawCPqFZEOLBK5SrOvYRHormQb2LgWOJTMeHsz187QZJdd4AP PceM8qRDYmbSYfKckYZ+0Gg4JRGqjCqtG+MDOo+vk3lP8tjj+vcvu+CkUO6v9pZ9HvV5 MqRg==
MIME-Version: 1.0
X-Received: by 10.194.48.116 with SMTP id k20mr10317406wjn.23.1371539743913; Tue, 18 Jun 2013 00:15:43 -0700 (PDT)
Received: by 10.180.126.97 with HTTP; Tue, 18 Jun 2013 00:15:43 -0700 (PDT)
Date: Tue, 18 Jun 2013 00:15:43 -0700
Message-ID: <CAL0qLwbo+YnKsuivUqtTYz5+8D-yd4BZXRyEbPCsA_d=Q9Lqjg@mail.gmail.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
To: IETF Apps Discuss <apps-discuss@ietf.org>
Content-Type: multipart/alternative; boundary=047d7ba975e63b3dc904df687b74
Subject: [apps-discuss] Lots of documents, no document work
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 18 Jun 2013 07:15:45 -0000

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

Hi there,

APPSAWG currently has several documents open, but no recent reviews or
comments about any of them.  In order to progress them through to
publication, we need to see evidence of adequate review and support from
the working group.

The open documents and their milestones are:

draft-ietf-appsawg-json-merge-patch (September)
draft-ietf-appsawg-malformed-mail (Septermber) [*]
draft-ietf-appsawg-sieve-duplicate (August)
draft-ietf-appsawg-xml-mediatypes (November)

There have been several suggestions for other work to be considered for
adoption by APPSAWG, but we really should finish up some of our existing
work first.

-MSK, APPSAWG co-chair

[*] This one is mine; I have a new version ready for posting.  Will do that
very soon.  It has seen a good amount of review and discussion already, but
could use one or two more reviewers before sending it to the IESG.

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

<div dir=3D"ltr"><div><div>Hi there,<br><br></div>APPSAWG currently has sev=
eral documents open, but no recent reviews or comments about any of them.=
=A0 In order to progress them through to publication, we need to see eviden=
ce of adequate review and support from the working group.<br>
<br>The open documents and their milestones are:<br><br>draft-ietf-appsawg-=
json-merge-patch (September)<br>draft-ietf-appsawg-malformed-mail (Septermb=
er) [*]<br>draft-ietf-appsawg-sieve-duplicate (August)<br>draft-ietf-appsaw=
g-xml-mediatypes (November)<br>
<br></div><div>There have been several suggestions for other work to be con=
sidered for adoption by APPSAWG, but we really should finish up some of our=
 existing work first.<br><br>-MSK, APPSAWG co-chair<br></div><div><br></div=
>
[*] This one is mine; I have a new version ready for posting.=A0 Will do th=
at very soon.=A0 It has seen a good amount of review and discussion already=
, but could use one or two more reviewers before sending it to the IESG.<br=
>
</div>

--047d7ba975e63b3dc904df687b74--

From internet-drafts@ietf.org  Tue Jun 18 00:23:02 2013
Return-Path: <internet-drafts@ietf.org>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B04A21F99C3; Tue, 18 Jun 2013 00:23:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.508
X-Spam-Level: 
X-Spam-Status: No, score=-102.508 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bnVZPvTVUN6K; Tue, 18 Jun 2013 00:23:01 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B396221F99D0; Tue, 18 Jun 2013 00:23:01 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.51.p2
Message-ID: <20130618072301.24613.52745.idtracker@ietfa.amsl.com>
Date: Tue, 18 Jun 2013 00:23:01 -0700
Cc: apps-discuss@ietf.org
Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-malformed-mail-06.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 18 Jun 2013 07:23:02 -0000

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

	Title           : Advice for Safe Handling of Malformed Messages
	Author(s)       : Murray S. Kucherawy
                          Gregory N. Shapiro
	Filename        : draft-ietf-appsawg-malformed-mail-06.txt
	Pages           : 19
	Date            : 2013-06-18

Abstract:
   Although Internet mail formats have been precisely defined since the
   1970s, authoring and handling software often show only mild
   conformance to the specifications.  The distributed and non-
   interactive nature of email has often prompted adjustments to
   receiving software, to handle these variations, rather than trying to
   gain better conformance by senders, since the receiving operator is
   primarily driven by complaining recipient users and has no authority
   over the sending side of the system.  Processing with such
   flexibility comes at some cost, since mail software is faced with
   decisions about whether or not to permit non-conforming messages to
   continue toward their destinations unaltered, adjust them to conform
   (possibly at the cost of losing some of the original message), or
   outright rejecting them.

   A core requirement for interoperability is that both sides of an
   exchange work from the same details and semantics.  By having
   receivers be flexible, beyond the specifications, there can be -- and
   often has been -- a good chance that a message will not be fully
   interoperable.  Worse, a well-established pattern of tolerance for
   variations can sometimes be used as an attack vector.

   This document includes a collection of the best advice available
   regarding a variety of common malformed mail situations, to be used
   as implementation guidance.  It must be emphasized, however, that the
   intent of this document is not to standardize malformations or
   otherwise encourage their proliferation.  The messages are manifestly
   malformed, and the code and culture that generates them needs to be
   fixed.  Therefore, these messages should be rejected outright if at
   all possible.  Nevertheless, many malformed messages from otherwise
   legitimate senders are in circulation and will be for some time, and,
   unfortunately, commercial reality shows that we cannot always simply
   reject or discard them.  Accordingly, this document presents
   alternatives for dealing with them in ways that seem to do the least
   additional harm until the infrastructure is tightened up to match the
   standards.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-appsawg-malformed-mail

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-appsawg-malformed-mail-06

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-malformed-mail-06


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From superuser@gmail.com  Tue Jun 18 00:27:16 2013
Return-Path: <superuser@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E11FA21F9A91 for <apps-discuss@ietfa.amsl.com>; Tue, 18 Jun 2013 00:27:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9BPZvx00xhRJ for <apps-discuss@ietfa.amsl.com>; Tue, 18 Jun 2013 00:27:16 -0700 (PDT)
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 691DB21F9A9B for <apps-discuss@ietf.org>; Tue, 18 Jun 2013 00:27:09 -0700 (PDT)
Received: by mail-wg0-f46.google.com with SMTP id c11so3075085wgh.13 for <apps-discuss@ietf.org>; Tue, 18 Jun 2013 00:27:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Lldwcoq6ImOjs4qTz79xg4SE50R3+N8jGSxS/xYP/fo=; b=Yn+1SBjwa507rJEw5wwoSE6On+3ymQPSzUKqU7tzpse2F8rwIIfK80ajk9EOZi0SXj dWhw5u6zfxBuVjgCvH6DzVNy3Bv+UcMU4lQ2vSJLNsoNLx3gf2dJlNlxAJ4d/XGy0gdC 3PcKLNJ/DRJefBjBP1MRs53xwbC1PpGIdV+5MnOx8H82Tu7HRgQshNyNqbU15QCLMUD8 0SwN8Pha7haNASGzmLtSRmYmqxJRUc6Mo2n6I3hnyTnYIHdDQOyXAMH3SpoeiMj26srv UXXPnVwlXLx0xOon21yE0ju1Ad/cOeJqk+/nAS3zuRiAhIbY79TMge7XfuuZzqnBEevE et1Q==
MIME-Version: 1.0
X-Received: by 10.180.20.228 with SMTP id q4mr4111135wie.60.1371540428531; Tue, 18 Jun 2013 00:27:08 -0700 (PDT)
Received: by 10.180.126.97 with HTTP; Tue, 18 Jun 2013 00:27:08 -0700 (PDT)
In-Reply-To: <20130618072301.24613.52745.idtracker@ietfa.amsl.com>
References: <20130618072301.24613.52745.idtracker@ietfa.amsl.com>
Date: Tue, 18 Jun 2013 00:27:08 -0700
Message-ID: <CAL0qLwaO1iOJT4XR9Z+qUVtPVJps39w2LBUD_UikJQ+Tm8TGBA@mail.gmail.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
To: IETF Apps Discuss <apps-discuss@ietf.org>
Content-Type: multipart/alternative; boundary=f46d0421848509b09904df68a4e4
Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-malformed-mail-06.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 18 Jun 2013 07:27:17 -0000

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

On Tue, Jun 18, 2013 at 12:23 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           : Advice for Safe Handling of Malformed Messages
>         Author(s)       : Murray S. Kucherawy
>                           Gregory N. Shapiro
>         Filename        : draft-ietf-appsawg-malformed-mail-06.txt
>         Pages           : 19
>         Date            : 2013-06-18
> [...]
>

Includes changes suggested by John and Ned's recent conversation about the
content.

Anyone else interested in providing feedback on it?  Should I poke
Salvatore to start the machine?

-MSK

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

<div dir=3D"ltr">On Tue, Jun 18, 2013 at 12:23 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 : Advice for Safe Handling of Mal=
formed Messages<br>
=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Murray S. Kucherawy<br>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Gregory N. Shapiro<br>
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-appsawg-malformed-mail=
-06.txt<br>
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 19<br>
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-06-18<br>
[...]<br></blockquote><div><br></div><div>Includes changes suggested by Joh=
n and Ned&#39;s recent conversation about the content.<br><br>Anyone else i=
nterested in providing feedback on it?=A0 Should I poke Salvatore to start =
the machine?<br>
<br></div><div>-MSK<br></div></div></div></div>

--f46d0421848509b09904df68a4e4--

From dave@cridland.net  Tue Jun 18 01:56:41 2013
Return-Path: <dave@cridland.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D43A621F9D83 for <apps-discuss@ietfa.amsl.com>; Tue, 18 Jun 2013 01:56:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.959
X-Spam-Level: 
X-Spam-Status: No, score=-1.959 tagged_above=-999 required=5 tests=[AWL=0.018,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hc-cO0JacW7B for <apps-discuss@ietfa.amsl.com>; Tue, 18 Jun 2013 01:56:41 -0700 (PDT)
Received: from mail-oa0-x22d.google.com (mail-oa0-x22d.google.com [IPv6:2607:f8b0:4003:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 61AD021F9D05 for <apps-discuss@ietf.org>; Tue, 18 Jun 2013 01:56:37 -0700 (PDT)
Received: by mail-oa0-f45.google.com with SMTP id j1so4720935oag.18 for <apps-discuss@ietf.org>; Tue, 18 Jun 2013 01:56:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jW3VidFKWS1SrS2GL8PcLC1XzFOvkeYZSdBzA0iVwWQ=; b=e5DwHgI18EmwDmRyrBXZapKguqAG1xJcNlIV7LyXK0spem1YIgmXtzC3BZiK7xV/qN 7jM6rS/W7oI4giLxpiv7b3GfhJkF/D/g2p6C6uOv8u5Ok4SMtYi2/dP0vURJJWUs/EDU hRc29PvwSdwlVxXyusKAGD70V9wx9V6BdiD8M=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=jW3VidFKWS1SrS2GL8PcLC1XzFOvkeYZSdBzA0iVwWQ=; b=hXWCeeG+jIk56f4mCcr3APouSuJrlmlVNBtc1TuAIJjvTYuGnwd4l4tQIryBdFP2yh xntSvW7GSKyA2LtdwkD6/s03zbrnP/VrWHtx64E7NiA8Ri8vCs88LokokOUTn2z/ekaJ oJi2UfdIc3NvQaL49IeHSMPvkpIPDp0mjRhlD8WjHwi2k7Q2FnFanQFPUZuz474ZAMGj 94T6moX2a6hrGyQe7j2O3mZRHSzlsoonwStp8DO7NIvimPdlynzSXeJLwA+TAviPV485 5RtQLIj0MJ9Oba5ZT87zJL03HU/EFimZw7l6YvHmJUASEeLJFHoaUIXN9OVsCdrYgHaJ o7/Q==
MIME-Version: 1.0
X-Received: by 10.182.200.129 with SMTP id js1mr11403921obc.5.1371545796938; Tue, 18 Jun 2013 01:56:36 -0700 (PDT)
Received: by 10.60.139.212 with HTTP; Tue, 18 Jun 2013 01:56:36 -0700 (PDT)
In-Reply-To: <CAL0qLwaO1iOJT4XR9Z+qUVtPVJps39w2LBUD_UikJQ+Tm8TGBA@mail.gmail.com>
References: <20130618072301.24613.52745.idtracker@ietfa.amsl.com> <CAL0qLwaO1iOJT4XR9Z+qUVtPVJps39w2LBUD_UikJQ+Tm8TGBA@mail.gmail.com>
Date: Tue, 18 Jun 2013 09:56:36 +0100
Message-ID: <CAKHUCzxPyHrgRBPX9Qvhe2pQAEBRyRV9=-HQy8D56suo1xbbeg@mail.gmail.com>
From: Dave Cridland <dave@cridland.net>
To: "Murray S. Kucherawy" <superuser@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c23696051ed004df69e4e5
X-Gm-Message-State: ALoCoQkyjteO2g84lsXlJQJRR/j6riVDMgAcehKy7kqpbagpWZIKDhXXKzA7NWGpF884shL4D82w
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-malformed-mail-06.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 18 Jun 2013 08:56:41 -0000

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

On Tue, Jun 18, 2013 at 8:27 AM, Murray S. Kucherawy <superuser@gmail.com>w=
rote:

>
> Anyone else interested in providing feedback on it?  Should I poke
> Salvatore to start the machine?
>

=A76, last para should explicitly state this is only a suitable fixup for
text/plain and text/html; and even then only in known character encodings
(charsets), such as ASCII, ISO 8859, and UTF-8. I'd hate everyone to
"correct" the 0x0A octets in my JPEGs.

=A76 title is misnamed - missing "i" in "terminaton".

I'm concerned with =A77.1.4's implication that implementations should be
looking for possibly email addresses in header field comments. I'm happy
that a bare ")" should be treated as a literal, but I'm wary of the
possibility of "hiding" email addresses in comments. Overall, I'm inclined
to say I'd prefer that we advised that an unterminated comment in a header
field value were treated as being terminated at the end of the value.

I have similar concerns with $7.1.6 - more so because I suspect that "Foo
local@example.net could also be interpreted as "Foo local"@example.net.
Also typo in =A77.1.6, example has "&gt" at the end.

I don't think you can show valid syntax and describe it as "Header
Malformations", as =A77.4. I think this might be better described as
"Non-normalized Header".

=A77.5 mentioned the case of two From fields - it doesn't mention the
possibility of combining the two, so:

From: First <first@example.org>
From: Second <second@example.net>

... could become:

From: First <first@example.org>, Second <second@example.net>

Obviously you'd need to inject a Sender field as needed (as per =A77.6 of
this memo).

I'm not suggesting it has to offer this, but I'm wondering if the lack of
offer is intentional?

=A79.1 describes a technique of breaking lines at points that make no
semantic difference. Given the poor NLP capability in the majority of
deployed MTAs, I'm slightly suspect of this advice. Even without any snark
at all, cases such as format=3Dflowed (and other message quoting) could
easily be warped or broken by breaking lines.

Hope that all helps more than hinders,

Dave.

--001a11c23696051ed004df69e4e5
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 Tue, Jun 18, 2013 at 8:27 AM, Murray S. Kucherawy <span dir=3D"l=
tr">&lt;<a href=3D"mailto:superuser@gmail.com" target=3D"_blank">superuser@=
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 dir=3D"ltr"><div class=3D"im"><br></div=
><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div>Anyone else int=
erested in providing feedback on it?=A0 Should I poke Salvatore to start th=
e machine?</div>
</div></div></div></blockquote><div><br></div><div style>=A76, last para sh=
ould explicitly state this is only a suitable fixup for text/plain and text=
/html; and even then only in known character encodings (charsets), such as =
ASCII, ISO 8859, and UTF-8. I&#39;d hate everyone to &quot;correct&quot; th=
e 0x0A octets in my JPEGs.</div>
<div style><br></div><div style>=A76 title is misnamed - missing &quot;i&qu=
ot; in &quot;terminaton&quot;.</div><div style><br></div><div style>I&#39;m=
 concerned with =A77.1.4&#39;s implication that implementations should be l=
ooking for possibly email addresses in header field comments. I&#39;m happy=
 that a bare &quot;)&quot; should be treated as a literal, but I&#39;m wary=
 of the possibility of &quot;hiding&quot; email addresses in comments. Over=
all, I&#39;m inclined to say I&#39;d prefer that we advised that an untermi=
nated comment in a header field value were treated as being terminated at t=
he end of the value.</div>
<div style><br></div><div style>I have similar concerns with $7.1.6 - more =
so because I suspect that &quot;Foo <a href=3D"mailto:local@example.net">lo=
cal@example.net</a> could also be interpreted as &quot;Foo local&quot;@<a h=
ref=3D"http://example.net">example.net</a>. Also typo in =A77.1.6, example =
has &quot;&amp;gt&quot; at the end.</div>
<div style><br></div><div style>I don&#39;t think you can show valid syntax=
 and describe it as &quot;Header Malformations&quot;, as =A77.4. I think th=
is might be better described as &quot;Non-normalized Header&quot;.</div><di=
v style>
<br></div><div style>=A77.5 mentioned the case of two From fields - it does=
n&#39;t mention the possibility of combining the two, so:</div><div style><=
br></div><div style>From: First &lt;<a href=3D"mailto:first@example.org">fi=
rst@example.org</a>&gt;</div>
<div style>From: Second &lt;<a href=3D"mailto:second@example.net">second@ex=
ample.net</a>&gt;</div><div style><br></div><div style>... could become:</d=
iv><div style><br></div><div style>From: First &lt;<a href=3D"mailto:first@=
example.org">first@example.org</a>&gt;, Second &lt;<a href=3D"mailto:second=
@example.net">second@example.net</a>&gt;</div>
<div style><br></div><div style>Obviously you&#39;d need to inject a Sender=
 field as needed (as per =A77.6 of this memo).</div><div style><br></div><d=
iv style>I&#39;m not suggesting it has to offer this, but I&#39;m wondering=
 if the lack of offer is intentional?</div>
<div style><br></div><div style>=A79.1 describes a technique of breaking li=
nes at points that make no semantic difference. Given the poor NLP capabili=
ty in the majority of deployed MTAs, I&#39;m slightly suspect of this advic=
e. Even without any snark at all, cases such as format=3Dflowed (and other =
message quoting) could easily be warped or broken by breaking lines.</div>
<div style><br></div><div style>Hope that all helps more than hinders,</div=
><div style><br></div><div style>Dave.</div></div></div></div>

--001a11c23696051ed004df69e4e5--

From ned.freed@mrochek.com  Tue Jun 18 06:38:41 2013
Return-Path: <ned.freed@mrochek.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C18C921F9F60 for <apps-discuss@ietfa.amsl.com>; Tue, 18 Jun 2013 06:38:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h+ULyueHBVdE for <apps-discuss@ietfa.amsl.com>; Tue, 18 Jun 2013 06:38:31 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 5974621F9F61 for <apps-discuss@ietf.org>; Tue, 18 Jun 2013 06:38:30 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OUZHJ2TVK0007SK6@mauve.mrochek.com> for apps-discuss@ietf.org; Tue, 18 Jun 2013 06:33:28 -0700 (PDT)
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 <01OUY9HQQS3K000054@mauve.mrochek.com>; Tue, 18 Jun 2013 06:33:24 -0700 (PDT)
Message-id: <01OUZHJ179TW000054@mauve.mrochek.com>
Date: Tue, 18 Jun 2013 06:10:07 -0700 (PDT)
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Tue, 18 Jun 2013 09:56:36 +0100" <CAKHUCzxPyHrgRBPX9Qvhe2pQAEBRyRV9=-HQy8D56suo1xbbeg@mail.gmail.com>
References: <20130618072301.24613.52745.idtracker@ietfa.amsl.com> <CAL0qLwaO1iOJT4XR9Z+qUVtPVJps39w2LBUD_UikJQ+Tm8TGBA@mail.gmail.com> <CAKHUCzxPyHrgRBPX9Qvhe2pQAEBRyRV9=-HQy8D56suo1xbbeg@mail.gmail.com>
To: Dave Cridland <dave@cridland.net>
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] I-D Action:	draft-ietf-appsawg-malformed-mail-06.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 18 Jun 2013 13:38:41 -0000

> On Tue, Jun 18, 2013 at 8:27 AM, Murray S. Kucherawy <superuser@gmail.com>wrote:

> >
> > Anyone else interested in providing feedback on it?  Should I poke
> > Salvatore to start the machine?
> >

> §6, last para should explicitly state this is only a suitable fixup for
> text/plain and text/html; and even then only in known character encodings
> (charsets), such as ASCII, ISO 8859, and UTF-8. I'd hate everyone to
> "correct" the 0x0A octets in my JPEGs.

Disagree. This section is talking about processing messages as a whole
as received via SMTP, prior to MIME interpretation.

What needs to be made clear is that this is talking about SMTP specificially,
not interpretation of MIME entities. And it probably should note that
it doesn't apply to binary SMTP.

Similar considerations do apply to 7bit and 8bit entities and types under text,
but this section isn't written to cover that. And covering all the permutations
of entity type/encoding/contnent mismatch is a pretty tall order. Do we really
want to get into this so late in the game/

> §6 title is misnamed - missing "i" in "terminaton".

> I'm concerned with §7.1.4's implication that implementations should be
> looking for possibly email addresses in header field comments. I'm happy
> that a bare ")" should be treated as a literal, but I'm wary of the
> possibility of "hiding" email addresses in comments. Overall, I'm inclined
> to say I'd prefer that we advised that an unterminated comment in a header
> field value were treated as being terminated at the end of the value.

I'm ambivalent about this one. It's quite true that addresses are sometimes
hidden in comments, but as a practical matter, anyone who does that as opposed
to removing the address outright and then gets the syntax wrong kinda deserves
what they get.

> I have similar concerns with $7.1.6 - more so because I suspect that "Foo
> local@example.net could also be interpreted as "Foo local"@example.net.

Well, of the three, which do you think is more likely to have been the
intent?

       To: "Joe <joe@example.com>"@example.net
       To: "Joe" <joe@example.com>
       To: "Joe joe"@example.net

Yes, they're all legal, but in practice how often do you see local parts in
valid addresses containing angle brackets and spaces?

> §7.5 mentioned the case of two From fields - it doesn't mention the
> possibility of combining the two, so:

> From: First <first@example.org>
> From: Second <second@example.net>

> ... could become:

> From: First <first@example.org>, Second <second@example.net>

> Obviously you'd need to inject a Sender field as needed (as per §7.6 of
> this memo).

> I'm not suggesting it has to offer this, but I'm wondering if the lack of
> offer is intentional?

I hadn't considered this. It's kind of an interesting idea, but given the
issues that arise in practice when more than one address is present in a From:
field, I have doubts about its utility.

> §9.1 describes a technique of breaking lines at points that make no
> semantic difference. Given the poor NLP capability in the majority of
> deployed MTAs, I'm slightly suspect of this advice. Even without any snark
> at all, cases such as format=flowed (and other message quoting) could
> easily be warped or broken by breaking lines.

Strongly disagree. The alternative of encoding oversized lines may not be
practical, so the choices are truncate or wrap. The chances that truncation
is going to produce better results than wrapping are pretty low.

And I'm not even slightly sympathetic about the possible damage done due to
lack of NLP knowledge in MTAs. If you want your format=flowed material to
arrive intact, don't spew out illegal garbage.

				Ned

From dave@cridland.net  Tue Jun 18 06:54:49 2013
Return-Path: <dave@cridland.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEC5A21F9F68 for <apps-discuss@ietfa.amsl.com>; Tue, 18 Jun 2013 06:54:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.962
X-Spam-Level: 
X-Spam-Status: No, score=-1.962 tagged_above=-999 required=5 tests=[AWL=0.015,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0aTMIZPRXJPb for <apps-discuss@ietfa.amsl.com>; Tue, 18 Jun 2013 06:54:48 -0700 (PDT)
Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 96F9021F9F67 for <apps-discuss@ietf.org>; Tue, 18 Jun 2013 06:54:48 -0700 (PDT)
Received: by mail-ob0-f180.google.com with SMTP id eh20so4503485obb.25 for <apps-discuss@ietf.org>; Tue, 18 Jun 2013 06:54:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wRFA9oUcuobhksP8aPxjENLgkEaMzphZ4MHVllupWJU=; b=IVuvztnd0Y4WRh2Yk/ycHIqCqgnpWsAIP59HtSvrHTKMTtjbc9qUEGsPtbPiPqnvJN 3ValWNFrxYcaHRWoiFAVeDu0l6BNBLQrz/bLDbyW3a6Mbw5L74Xf5V1Cz+yb98ObOjFj oHQrn7ETTr51/RWdehBWZReELF0CiS0Z+Sfec=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=wRFA9oUcuobhksP8aPxjENLgkEaMzphZ4MHVllupWJU=; b=RRx3nAagTdzdsPJ/qHVMUWXWbfU5P9IcWaGge8LQD0cG+x+bMoGpxw4tiTcQnpXFTE 0wdTcGYNCYXfwelTfRf03WaE3HkAxy2Wktyh5ow66C9a/4KS4UWNqsrOO2PKV+mv0nnv DBqkBJapYID4guhrh/lOx6Z+RdjK87Zz3WLQ99KezSCx1PMErsmaD2cFrbEXgcpQ++qt fb8mymOufEqlZPvYX+/3ObdWfFVRixrS7q3RD7Ut6zmNVaGfPbl7U57AjRM3EyNRiFm6 VvSzyx4LoKJ5bYLv+y+NH8s5oSuV1ETXkhxUV5J/FhvPccwFc8Dmtgcd78XjTpD/p7k6 xsjg==
MIME-Version: 1.0
X-Received: by 10.182.24.131 with SMTP id u3mr12209298obf.29.1371563688056; Tue, 18 Jun 2013 06:54:48 -0700 (PDT)
Received: by 10.60.139.212 with HTTP; Tue, 18 Jun 2013 06:54:47 -0700 (PDT)
In-Reply-To: <01OUZHJ179TW000054@mauve.mrochek.com>
References: <20130618072301.24613.52745.idtracker@ietfa.amsl.com> <CAL0qLwaO1iOJT4XR9Z+qUVtPVJps39w2LBUD_UikJQ+Tm8TGBA@mail.gmail.com> <CAKHUCzxPyHrgRBPX9Qvhe2pQAEBRyRV9=-HQy8D56suo1xbbeg@mail.gmail.com> <01OUZHJ179TW000054@mauve.mrochek.com>
Date: Tue, 18 Jun 2013 14:54:47 +0100
Message-ID: <CAKHUCzyAAZybgHna_ZpqyCYd4UxLtev126906c0eA+0JAeYtyQ@mail.gmail.com>
From: Dave Cridland <dave@cridland.net>
To: Ned Freed <ned.freed@mrochek.com>
Content-Type: multipart/alternative; boundary=001a11c3025269f00804df6e0e6c
X-Gm-Message-State: ALoCoQmgA+jKLSfUUxDagg0TMIV4DrGX9txoVOFxvoCg2y+kG2XrJhSzWUmjuVTl+2eY/I33fcoN
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-malformed-mail-06.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 18 Jun 2013 13:54:49 -0000

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

First off, I should say this was my first run-through, and I've not been
following the discussion - if things have been discussed to death already,
then feel free to shoot me down.

On Tue, Jun 18, 2013 at 2:10 PM, Ned Freed <ned.freed@mrochek.com> wrote:

> > On Tue, Jun 18, 2013 at 8:27 AM, Murray S. Kucherawy <
> superuser@gmail.com>wrote:
>
> > >
> > > Anyone else interested in providing feedback on it?  Should I poke
> > > Salvatore to start the machine?
> > >
>
> > =A76, last para should explicitly state this is only a suitable fixup f=
or
> > text/plain and text/html; and even then only in known character encodin=
gs
> > (charsets), such as ASCII, ISO 8859, and UTF-8. I'd hate everyone to
> > "correct" the 0x0A octets in my JPEGs.
>
> Disagree. This section is talking about processing messages as a whole
> as received via SMTP, prior to MIME interpretation.
>
> What needs to be made clear is that this is talking about SMTP
> specificially,
> not interpretation of MIME entities. And it probably should note that
> it doesn't apply to binary SMTP.
>
>
Right, I'd misunderstood the notion. So yes, it was the paragraph before
derailling me, because it starts discussing ASCII. I think if it merely
said that bare CRs and LFs were uncommon in non-binary messages, we'd be
good here.

   Within modern Internet Mail it is highly unlikely that an isolated CR
   or LF is valid in a message, outside of binary transfers [BINARY].
 Furthermore [MIME] presents
   mechanisms for encoding content that actually does need to contain
   such an unusual character sequence.



> > I'm concerned with =A77.1.4's implication that implementations should b=
e
> > looking for possibly email addresses in header field comments. I'm happ=
y
> > that a bare ")" should be treated as a literal, but I'm wary of the
> > possibility of "hiding" email addresses in comments. Overall, I'm
> inclined
> > to say I'd prefer that we advised that an unterminated comment in a
> header
> > field value were treated as being terminated at the end of the value.
>
> I'm ambivalent about this one. It's quite true that addresses are sometim=
es
> hidden in comments, but as a practical matter, anyone who does that as
> opposed
> to removing the address outright and then gets the syntax wrong kinda
> deserves
> what they get.
>
>
What's concerning me here is that I wouldn't want to be trying to parse
comments in the hope of finding things there. I'd rather assume that the
error with an unterminated comment was the lack of termination, not that it
might contain something useful I should go hunting for.


> > I have similar concerns with $7.1.6 - more so because I suspect that "F=
oo
> > local@example.net could also be interpreted as "Foo local"@example.net.
>
> Well, of the three, which do you think is more likely to have been the
> intent?
>
>        To: "Joe <joe@example.com>"@example.net
>        To: "Joe" <joe@example.com>
>        To: "Joe joe"@example.net
>
> Yes, they're all legal, but in practice how often do you see local parts =
in
> valid addresses containing angle brackets and spaces?
>
>
Bear in mind I worked for Isode for years, so I've built up a strong
immunity to local parts with spaces due to MIXER, but in any case the
middle one is likely to be the intent. However I'm again concerned that it
means finding an unterminated phrase and back-tracking to see if the phrase
"looks interesting".


> > =A77.5 mentioned the case of two From fields - it doesn't mention the
> > possibility of combining the two, so:
>
> > From: First <first@example.org>
> > From: Second <second@example.net>
>
> > ... could become:
>
> > From: First <first@example.org>, Second <second@example.net>
>
> > Obviously you'd need to inject a Sender field as needed (as per =A77.6 =
of
> > this memo).
>
> > I'm not suggesting it has to offer this, but I'm wondering if the lack =
of
> > offer is intentional?
>
> I hadn't considered this. It's kind of an interesting idea, but given the
> issues that arise in practice when more than one address is present in a
> From:
> field, I have doubts about its utility.
>
>
Yes, multiple addresses in a From is unusual; but I'd have thought that
collapsing multiple header fields into one would in general be sane?
(Another example might be concatenating two subject header fields into one
longer one).


> > =A79.1 describes a technique of breaking lines at points that make no
> > semantic difference. Given the poor NLP capability in the majority of
> > deployed MTAs, I'm slightly suspect of this advice. Even without any
> snark
> > at all, cases such as format=3Dflowed (and other message quoting) could
> > easily be warped or broken by breaking lines.
>
> Strongly disagree. The alternative of encoding oversized lines may not be
> practical, so the choices are truncate or wrap. The chances that truncati=
on
> is going to produce better results than wrapping are pretty low.
>
> And I'm not even slightly sympathetic about the possible damage done due =
to
> lack of NLP knowledge in MTAs. If you want your format=3Dflowed material =
to
> arrive intact, don't spew out illegal garbage.
>

Happy to let your strong disagreement trump my slight suspicion.

Dave.

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

<div dir=3D"ltr"><div style>First off, I should say this was my first run-t=
hrough, and I&#39;ve not been following the discussion - if things have bee=
n discussed to death already, then feel free to shoot me down.</div><div><b=
r>
</div>On Tue, Jun 18, 2013 at 2:10 PM, Ned Freed <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:ned.freed@mrochek.com" target=3D"_blank">ned.freed@mrochek.co=
m</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_q=
uote">
<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">&gt; On Tue, Jun 18, 2013 at 8:27 AM, Mu=
rray S. Kucherawy &lt;<a href=3D"mailto:superuser@gmail.com">superuser@gmai=
l.com</a>&gt;wrote:<br>

<br>
&gt; &gt;<br>
&gt; &gt; Anyone else interested in providing feedback on it? =A0Should I p=
oke<br>
&gt; &gt; Salvatore to start the machine?<br>
&gt; &gt;<br>
<br>
&gt; =A76, last para should explicitly state this is only a suitable fixup =
for<br>
&gt; text/plain and text/html; and even then only in known character encodi=
ngs<br>
&gt; (charsets), such as ASCII, ISO 8859, and UTF-8. I&#39;d hate everyone =
to<br>
&gt; &quot;correct&quot; the 0x0A octets in my JPEGs.<br>
<br>
</div>Disagree. This section is talking about processing messages as a whol=
e<br>
as received via SMTP, prior to MIME interpretation.<br>
<br>
What needs to be made clear is that this is talking about SMTP specificiall=
y,<br>
not interpretation of MIME entities. And it probably should note that<br>
it doesn&#39;t apply to binary SMTP.<br>
<br></blockquote><div><br></div><div style>Right, I&#39;d misunderstood the=
 notion. So yes, it was the paragraph before derailling me, because it star=
ts discussing ASCII. I think if it merely said that bare CRs and LFs were u=
ncommon in non-binary messages, we&#39;d be good here.</div>
<div style><br></div><div style><div>=A0 =A0Within modern Internet Mail it =
is highly unlikely that an isolated CR</div><div>=A0 =A0or LF is valid in a=
 message, outside of binary transfers [BINARY]. =A0Furthermore [MIME] prese=
nts</div>
<div>=A0 =A0mechanisms for encoding content that actually does need to cont=
ain</div><div>=A0 =A0such an unusual character sequence.</div><div><br></di=
v></div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px=
 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bor=
der-left-style:solid;padding-left:1ex">
<div class=3D"im">&gt; I&#39;m concerned with =A77.1.4&#39;s implication th=
at implementations should be<br>
&gt; looking for possibly email addresses in header field comments. I&#39;m=
 happy<br>
&gt; that a bare &quot;)&quot; should be treated as a literal, but I&#39;m =
wary of the<br>
&gt; possibility of &quot;hiding&quot; email addresses in comments. Overall=
, I&#39;m inclined<br>
&gt; to say I&#39;d prefer that we advised that an unterminated comment in =
a header<br>
&gt; field value were treated as being terminated at the end of the value.<=
br>
<br>
</div>I&#39;m ambivalent about this one. It&#39;s quite true that addresses=
 are sometimes<br>
hidden in comments, but as a practical matter, anyone who does that as oppo=
sed<br>
to removing the address outright and then gets the syntax wrong kinda deser=
ves<br>
what they get.<br>
<div class=3D"im"><br></div></blockquote><div><br></div><div style>What&#39=
;s concerning me here is that I wouldn&#39;t want to be trying to parse com=
ments in the hope of finding things there. I&#39;d rather assume that the e=
rror with an unterminated comment was the lack of termination, not that it =
might contain something useful I should go hunting for.</div>
<div>=A0</div><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;padding-left:1ex"><div class=3D"im">
&gt; I have similar concerns with $7.1.6 - more so because I suspect that &=
quot;Foo<br>
&gt; <a href=3D"mailto:local@example.net">local@example.net</a> could also =
be interpreted as &quot;Foo local&quot;@<a href=3D"http://example.net" targ=
et=3D"_blank">example.net</a>.<br>
<br>
</div>Well, of the three, which do you think is more likely to have been th=
e<br>
intent?<br>
<br>
=A0 =A0 =A0 =A0To: &quot;Joe &lt;<a href=3D"mailto:joe@example.com">joe@exa=
mple.com</a>&gt;&quot;@<a href=3D"http://example.net" target=3D"_blank">exa=
mple.net</a><br>
=A0 =A0 =A0 =A0To: &quot;Joe&quot; &lt;<a href=3D"mailto:joe@example.com">j=
oe@example.com</a>&gt;<br>
=A0 =A0 =A0 =A0To: &quot;Joe joe&quot;@<a href=3D"http://example.net" targe=
t=3D"_blank">example.net</a><br>
<br>
Yes, they&#39;re all legal, but in practice how often do you see local part=
s in<br>
valid addresses containing angle brackets and spaces?<br>
<div class=3D"im"><br></div></blockquote><div><br></div><div style>Bear in =
mind I worked for Isode for years, so I&#39;ve built up a strong immunity t=
o local parts with spaces due to MIXER, but in any case the middle one is l=
ikely to be the intent. However I&#39;m again concerned that it means findi=
ng an unterminated phrase and back-tracking to see if the phrase &quot;look=
s interesting&quot;.</div>
<div>=A0</div><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;padding-left:1ex"><div class=3D"im">
&gt; =A77.5 mentioned the case of two From fields - it doesn&#39;t mention =
the<br>
&gt; possibility of combining the two, so:<br>
<br>
&gt; From: First &lt;<a href=3D"mailto:first@example.org">first@example.org=
</a>&gt;<br>
&gt; From: Second &lt;<a href=3D"mailto:second@example.net">second@example.=
net</a>&gt;<br>
<br>
&gt; ... could become:<br>
<br>
&gt; From: First &lt;<a href=3D"mailto:first@example.org">first@example.org=
</a>&gt;, Second &lt;<a href=3D"mailto:second@example.net">second@example.n=
et</a>&gt;<br>
<br>
&gt; Obviously you&#39;d need to inject a Sender field as needed (as per =
=A77.6 of<br>
&gt; this memo).<br>
<br>
&gt; I&#39;m not suggesting it has to offer this, but I&#39;m wondering if =
the lack of<br>
&gt; offer is intentional?<br>
<br>
</div>I hadn&#39;t considered this. It&#39;s kind of an interesting idea, b=
ut given the<br>
issues that arise in practice when more than one address is present in a Fr=
om:<br>
field, I have doubts about its utility.<br>
<div class=3D"im"><br></div></blockquote><div><br></div><div style>Yes, mul=
tiple addresses in a From is unusual; but I&#39;d have thought that collaps=
ing multiple header fields into one would in general be sane? (Another exam=
ple might be concatenating two subject header fields into one longer one).<=
/div>
<div>=A0</div><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;padding-left:1ex"><div class=3D"im">
&gt; =A79.1 describes a technique of breaking lines at points that make no<=
br>
&gt; semantic difference. Given the poor NLP capability in the majority of<=
br>
&gt; deployed MTAs, I&#39;m slightly suspect of this advice. Even without a=
ny snark<br>
&gt; at all, cases such as format=3Dflowed (and other message quoting) coul=
d<br>
&gt; easily be warped or broken by breaking lines.<br>
<br>
</div>Strongly disagree. The alternative of encoding oversized lines may no=
t be<br>
practical, so the choices are truncate or wrap. The chances that truncation=
<br>
is going to produce better results than wrapping are pretty low.<br>
<br>
And I&#39;m not even slightly sympathetic about the possible damage done du=
e to<br>
lack of NLP knowledge in MTAs. If you want your format=3Dflowed material to=
<br>
arrive intact, don&#39;t spew out illegal garbage.<br></blockquote><div><br=
></div><div style>Happy to let your strong disagreement trump my slight sus=
picion.</div><div style><br></div><div style>Dave.=A0</div></div></div></di=
v>

--001a11c3025269f00804df6e0e6c--

From ned.freed@mrochek.com  Tue Jun 18 07:50:20 2013
Return-Path: <ned.freed@mrochek.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3C0721F9EA9 for <apps-discuss@ietfa.amsl.com>; Tue, 18 Jun 2013 07:50:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8BwegUVASwNj for <apps-discuss@ietfa.amsl.com>; Tue, 18 Jun 2013 07:50:15 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 956E021F9CEB for <apps-discuss@ietf.org>; Tue, 18 Jun 2013 07:50:06 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OUZK1UC38G0083OJ@mauve.mrochek.com> for apps-discuss@ietf.org; Tue, 18 Jun 2013 07:45:04 -0700 (PDT)
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 <01OUY9HQQS3K000054@mauve.mrochek.com>; Tue, 18 Jun 2013 07:45:00 -0700 (PDT)
Message-id: <01OUZK1S0ZXU000054@mauve.mrochek.com>
Date: Tue, 18 Jun 2013 07:37:16 -0700 (PDT)
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Tue, 18 Jun 2013 14:54:47 +0100" <CAKHUCzyAAZybgHna_ZpqyCYd4UxLtev126906c0eA+0JAeYtyQ@mail.gmail.com>
References: <20130618072301.24613.52745.idtracker@ietfa.amsl.com> <CAL0qLwaO1iOJT4XR9Z+qUVtPVJps39w2LBUD_UikJQ+Tm8TGBA@mail.gmail.com> <CAKHUCzxPyHrgRBPX9Qvhe2pQAEBRyRV9=-HQy8D56suo1xbbeg@mail.gmail.com> <01OUZHJ179TW000054@mauve.mrochek.com> <CAKHUCzyAAZybgHna_ZpqyCYd4UxLtev126906c0eA+0JAeYtyQ@mail.gmail.com>
To: Dave Cridland <dave@cridland.net>
Cc: Ned Freed <ned.freed@mrochek.com>, IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] I-D Action:	draft-ietf-appsawg-malformed-mail-06.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 18 Jun 2013 14:50:21 -0000

> > > I'm concerned with §7.1.4's implication that implementations should be
> > > looking for possibly email addresses in header field comments. I'm happy
> > > that a bare ")" should be treated as a literal, but I'm wary of the
> > > possibility of "hiding" email addresses in comments. Overall, I'm
> > inclined
> > > to say I'd prefer that we advised that an unterminated comment in a
> > header
> > > field value were treated as being terminated at the end of the value.
> >
> > I'm ambivalent about this one. It's quite true that addresses are sometimes
> > hidden in comments, but as a practical matter, anyone who does that as
> > opposed
> > to removing the address outright and then gets the syntax wrong kinda
> > deserves
> > what they get.
> >
> >
> What's concerning me here is that I wouldn't want to be trying to parse
> comments in the hope of finding things there. I'd rather assume that the
> error with an unterminated comment was the lack of termination, not that it
> might contain something useful I should go hunting for.

The problem is that assumption leaves you with nothing actionable in the  field
in most if not all cases. (There's still the question of what to do if you hit
a comma - does that terminate the comment?) Since the intent of inserting
the field likely was, with the possible exception of a Bcc:, to actually
communicate one or more addresses, this doesn't seem like a good
interpretation.

> > > I have similar concerns with $7.1.6 - more so because I suspect that "Foo
> > > local@example.net could also be interpreted as "Foo local"@example.net.
> >
> > Well, of the three, which do you think is more likely to have been the
> > intent?
> >
> >        To: "Joe <joe@example.com>"@example.net
> >        To: "Joe" <joe@example.com>
> >        To: "Joe joe"@example.net
> >
> > Yes, they're all legal, but in practice how often do you see local parts in
> > valid addresses containing angle brackets and spaces?
> >
> >
> Bear in mind I worked for Isode for years, so I've built up a strong
> immunity to local parts with spaces due to MIXER, but in any case the
> middle one is likely to be the intent. However I'm again concerned that it
> means finding an unterminated phrase and back-tracking to see if the phrase
> "looks interesting".

Quite true. Some of this is undeniably tricky to code, and the document
doesn't really get into all of the issues with actually implementing some
of this stuff.

Nevertheless, I think this is, on balance, reasonable advice for this case.


> > > §7.5 mentioned the case of two From fields - it doesn't mention the
> > > possibility of combining the two, so:
> >
> > > From: First <first@example.org>
> > > From: Second <second@example.net>
> >
> > > ... could become:
> >
> > > From: First <first@example.org>, Second <second@example.net>
> >
> > > Obviously you'd need to inject a Sender field as needed (as per §7.6 of
> > > this memo).
> >
> > > I'm not suggesting it has to offer this, but I'm wondering if the lack of
> > > offer is intentional?
> >
> > I hadn't considered this. It's kind of an interesting idea, but given the
> > issues that arise in practice when more than one address is present in a
> > From:
> > field, I have doubts about its utility.
> >
> >
> Yes, multiple addresses in a From is unusual; but I'd have thought that
> collapsing multiple header fields into one would in general be sane?

Absolutely. I'm just concerned with subsequent handling. But the more
I think about it the more I like this appraoch.

> (Another example might be concatenating two subject header fields into one
> longer one).

Also a good idea, although I'd recommend checking to see if they aren't the
same value before doing it.

I guess the meta-question here is whether or not this document is open to
new material at this point. I'd actually like to see both of these added if
it is.

				Ned

From ned.freed@mrochek.com  Tue Jun 18 07:50:28 2013
Return-Path: <ned.freed@mrochek.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03BE821F9C76 for <apps-discuss@ietfa.amsl.com>; Tue, 18 Jun 2013 07:50:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bDaEQUcdB5my for <apps-discuss@ietfa.amsl.com>; Tue, 18 Jun 2013 07:50:21 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id C303821F9E85 for <apps-discuss@ietf.org>; Tue, 18 Jun 2013 07:50:15 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OUZK7G4YDS00757Z@mauve.mrochek.com> for apps-discuss@ietf.org; Tue, 18 Jun 2013 07:49:36 -0700 (PDT)
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 <01OUY9HQQS3K000054@mauve.mrochek.com>; Tue, 18 Jun 2013 07:49:32 -0700 (PDT)
Message-id: <01OUZK7E1Y4E000054@mauve.mrochek.com>
Date: Tue, 18 Jun 2013 07:45:46 -0700 (PDT)
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Tue, 18 Jun 2013 14:54:47 +0100" <CAKHUCzyAAZybgHna_ZpqyCYd4UxLtev126906c0eA+0JAeYtyQ@mail.gmail.com>
References: <20130618072301.24613.52745.idtracker@ietfa.amsl.com> <CAL0qLwaO1iOJT4XR9Z+qUVtPVJps39w2LBUD_UikJQ+Tm8TGBA@mail.gmail.com> <CAKHUCzxPyHrgRBPX9Qvhe2pQAEBRyRV9=-HQy8D56suo1xbbeg@mail.gmail.com> <01OUZHJ179TW000054@mauve.mrochek.com> <CAKHUCzyAAZybgHna_ZpqyCYd4UxLtev126906c0eA+0JAeYtyQ@mail.gmail.com>
To: Dave Cridland <dave@cridland.net>
Cc: Ned Freed <ned.freed@mrochek.com>, IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-malformed-mail-06.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 18 Jun 2013 14:50:28 -0000

And if we're going to add new material, all this discussion of how to
handle other cases of repeated fields reminded me of another one: Return-path.

I see multiple return-paths in messages pretty regularly. In most cases
the values are the same, but sometimes they are different.

IMO the correct interpretation is that the first one wins since that's most
likely to actually be the MAIL FROM inserted at final delivery. However, we
might want to mention that delivery agents could check to see if there's
already a return-path present with the same value as the one they're about to
insert, and if there is, don't insert an additional one.

				Ned

From stpeter@stpeter.im  Tue Jun 18 07:53:15 2013
Return-Path: <stpeter@stpeter.im>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 142CA21F99F6 for <apps-discuss@ietfa.amsl.com>; Tue, 18 Jun 2013 07:53:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.06
X-Spam-Level: 
X-Spam-Status: No, score=-102.06 tagged_above=-999 required=5 tests=[AWL=0.539, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0cLYVhc8Xeqd for <apps-discuss@ietfa.amsl.com>; Tue, 18 Jun 2013 07:53:07 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 5C91721E8055 for <apps-discuss@ietf.org>; Tue, 18 Jun 2013 07:53:05 -0700 (PDT)
Received: from ergon.local (unknown [24.8.129.242]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 850BE412DA; Tue, 18 Jun 2013 09:06:59 -0600 (MDT)
Message-ID: <51C07451.5010106@stpeter.im>
Date: Tue, 18 Jun 2013 08:53:05 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: "Murray S. Kucherawy" <superuser@gmail.com>
References: <CAL0qLwbo+YnKsuivUqtTYz5+8D-yd4BZXRyEbPCsA_d=Q9Lqjg@mail.gmail.com>
In-Reply-To: <CAL0qLwbo+YnKsuivUqtTYz5+8D-yd4BZXRyEbPCsA_d=Q9Lqjg@mail.gmail.com>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Lots of documents, no document work
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 18 Jun 2013 14:53:15 -0000

On 6/18/13 1:15 AM, Murray S. Kucherawy wrote:
> Hi there,
> 
> APPSAWG currently has several documents open, but no recent reviews or
> comments about any of them.  In order to progress them through to
> publication, we need to see evidence of adequate review and support from
> the working group.
> 
> The open documents and their milestones are:
> 
> draft-ietf-appsawg-json-merge-patch (September)
> draft-ietf-appsawg-malformed-mail (Septermber) [*]
> draft-ietf-appsawg-sieve-duplicate (August)
> draft-ietf-appsawg-xml-mediatypes (November)

I'll definitely take a look at a few of these.

Also, might it be appropriate to put the AppsDir to work here?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



From franck@peachymango.org  Tue Jun 18 08:43:14 2013
Return-Path: <franck@peachymango.org>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFC6421E8083 for <apps-discuss@ietfa.amsl.com>; Tue, 18 Jun 2013 08:43:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j0nod24vIVV2 for <apps-discuss@ietfa.amsl.com>; Tue, 18 Jun 2013 08:43:09 -0700 (PDT)
Received: from smtp.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id 75AD721F9AD5 for <apps-discuss@ietf.org>; Tue, 18 Jun 2013 08:43:06 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 6C6C63900C7; Tue, 18 Jun 2013 10:43:05 -0500 (CDT)
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 2d6gwV17t02Z; Tue, 18 Jun 2013 10:43:05 -0500 (CDT)
Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 277AB3900D0; Tue, 18 Jun 2013 10:43:05 -0500 (CDT)
Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 14F5F390034; Tue, 18 Jun 2013 10:43:05 -0500 (CDT)
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 MS5pcnJ1TXfZ; Tue, 18 Jun 2013 10:43:04 -0500 (CDT)
Received: from mail-2.01.com (mail.01.com [172.18.30.178]) by smtp-out-2.01.com (Postfix) with ESMTP id C2BA53900BC; Tue, 18 Jun 2013 10:43:04 -0500 (CDT)
Date: Tue, 18 Jun 2013 10:43:03 -0500 (CDT)
From: Franck Martin <franck@peachymango.org>
To: Dave Cridland <dave@cridland.net>
Message-ID: <1588480560.71477.1371570183273.JavaMail.root@peachymango.org>
In-Reply-To: <WM!970d54e81163466b3d05b30e6390fa1124b2a33138a0be56308543a983c276a730e5c96e22e9bda8ee417c3df6ef0a3b!@asav-2.01.com>
References: <20130618072301.24613.52745.idtracker@ietfa.amsl.com> <CAL0qLwaO1iOJT4XR9Z+qUVtPVJps39w2LBUD_UikJQ+Tm8TGBA@mail.gmail.com> <CAKHUCzxPyHrgRBPX9Qvhe2pQAEBRyRV9=-HQy8D56suo1xbbeg@mail.gmail.com> <WM!970d54e81163466b3d05b30e6390fa1124b2a33138a0be56308543a983c276a730e5c96e22e9bda8ee417c3df6ef0a3b!@asav-2.01.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_71476_2104390829.1371570183272"
X-Originating-IP: [69.28.149.29]
X-Mailer: Zimbra 8.0.3_GA_5664 (ZimbraWebClient - FF21 (Mac)/8.0.3_GA_5664)
Thread-Topic: I-D Action: draft-ietf-appsawg-malformed-mail-06.txt
Thread-Index: BP3SAkeWUzr9Nk3ZnF+HOKNFX2TTsA==
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] I-D Action:	draft-ietf-appsawg-malformed-mail-06.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 18 Jun 2013 15:43:15 -0000

------=_Part_71476_2104390829.1371570183272
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

----- Original Message -----

> From: "Dave Cridland" <dave@cridland.net>
> To: "Murray S. Kucherawy" <superuser@gmail.com>
> Cc: "IETF Apps Discuss" <apps-discuss@ietf.org>
> Sent: Tuesday, June 18, 2013 1:56:36 AM
> Subject: Re: [apps-discuss] I-D Action:
> draft-ietf-appsawg-malformed-mail-06.txt

> On Tue, Jun 18, 2013 at 8:27 AM, Murray S. Kucherawy < superuser@gmail.co=
m >
> wrote:

> > Anyone else interested in providing feedback on it? Should I poke Salva=
tore
> > to start the machine?
>=20

> =C2=A77.5 mentioned the case of two From fields - it doesn't mention the
> possibility of combining the two, so:

> From: First < first@example.org >
> From: Second < second@example.net >

> ... could become:

> From: First < first@example.org >, Second < second@example.net >

> Obviously you'd need to inject a Sender field as needed (as per =C2=A77.6=
 of this
> memo).

> I'm not suggesting it has to offer this, but I'm wondering if the lack of
> offer is intentional?

We should not do that, having more than one From header makes the message n=
on valid (as per RFC). There must be one and one only From: header. Combini=
ng makes an invalid message become a valid message. It is not like there is=
 ambiguity on the meaning. The only option here is to reject the email so t=
hat the sender can correct its implementation. At least that's my point of =
view.=20

------=_Part_71476_2104390829.1371570183272
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><body><div style=3D"font-family: arial,helvetica,sans-serif; font-siz=
e: 12pt; color: #000000"><div><br></div><div><br></div><br><div><br></div><=
hr id=3D"zwchr"><blockquote style=3D"border-left:2px solid #1010FF;margin-l=
eft:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;te=
xt-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;">=
<b>From: </b>"Dave Cridland" &lt;dave@cridland.net&gt;<br><b>To: </b>"Murra=
y S. Kucherawy" &lt;superuser@gmail.com&gt;<br><b>Cc: </b>"IETF Apps Discus=
s" &lt;apps-discuss@ietf.org&gt;<br><b>Sent: </b>Tuesday, June 18, 2013 1:5=
6:36 AM<br><b>Subject: </b>Re: [apps-discuss] I-D Action:&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;draft-ietf-appsawg-malformed-mail-06.txt<br><=
div><br></div><div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div><br>=
</div><div class=3D"gmail_quote">On Tue, Jun 18, 2013 at 8:27 AM, Murray S.=
 Kucherawy <span dir=3D"ltr">&lt;<a href=3D"mailto:superuser@gmail.com" tar=
get=3D"_blank">superuser@gmail.com</a>&gt;</span> wrote:<br><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"ltr"><div class=3D"im"><br></div><div class=3D"=
gmail_extra"><div class=3D"gmail_quote"><div>Anyone else interested in prov=
iding feedback on it?&nbsp; Should I poke Salvatore to start the machine?</=
div></div></div></div></blockquote><br><div style=3D""><br></div><div style=
=3D"">=C2=A77.5 mentioned the case of two From fields - it doesn't mention =
the possibility of combining the two, so:</div><div style=3D""><br></div><d=
iv style=3D"">From: First &lt;<a href=3D"mailto:first@example.org" target=
=3D"_blank">first@example.org</a>&gt;</div><div style=3D"">From: Second &lt=
;<a href=3D"mailto:second@example.net" target=3D"_blank">second@example.net=
</a>&gt;</div><div style=3D""><br></div><div style=3D"">... could become:</=
div><div style=3D""><br></div><div style=3D"">From: First &lt;<a href=3D"ma=
ilto:first@example.org" target=3D"_blank">first@example.org</a>&gt;, Second=
 &lt;<a href=3D"mailto:second@example.net" target=3D"_blank">second@example=
.net</a>&gt;</div><div style=3D""><br></div><div style=3D"">Obviously you'd=
 need to inject a Sender field as needed (as per =C2=A77.6 of this memo).</=
div><div style=3D""><br></div><div style=3D"">I'm not suggesting it has to =
offer this, but I'm wondering if the lack of offer is intentional?</div><di=
v style=3D""><br></div></div></div></div></blockquote><div>We should not do=
 that, having more than one From header makes the message non valid (as per=
 RFC). There must be one and one only From: header. Combining makes an inva=
lid message become a valid message. It is not like there is ambiguity on th=
e meaning. The only option here is to reject the email so that the sender c=
an correct its implementation. At least that's my point of view.<br></div><=
br></div></body></html>
------=_Part_71476_2104390829.1371570183272--

From paul.hoffman@vpnc.org  Tue Jun 18 09:39:13 2013
Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CAAE11E80F7 for <apps-discuss@ietfa.amsl.com>; Tue, 18 Jun 2013 09:39:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.522
X-Spam-Level: 
X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pWSGJNHo88gj for <apps-discuss@ietfa.amsl.com>; Tue, 18 Jun 2013 09:39:12 -0700 (PDT)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id B264711E80A2 for <apps-discuss@ietf.org>; Tue, 18 Jun 2013 09:39:10 -0700 (PDT)
Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r5IGd8o7088962 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for <apps-discuss@ietf.org>; Tue, 18 Jun 2013 09:39:09 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
From: Paul Hoffman <paul.hoffman@vpnc.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <2D7B00D1-74C9-4EE5-A4BB-B461CA455933@vpnc.org>
Date: Tue, 18 Jun 2013 09:39:08 -0700
To: "apps-discuss@ietf.org Discuss" <apps-discuss@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
X-Mailer: Apple Mail (2.1508)
Subject: [apps-discuss] Comments on draft-ietf-appsawg-json-merge-patch
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <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, 18 Jun 2013 16:39:13 -0000

Greetings again. This document mostly looks fine, and is pretty mature.

I'm still confused about why the following exists in the document:
       Any
       object member or array element contained in the provided data
       whose value is explicitly null is to be treated as if the member
       is undefined and MUST NOT appear within the result.
The wording has changed from draft to draft, but there is no explanation =
of why there should be something that exists in the patch document that =
should not exist in the result. Adding a paragraph about this design =
choice would clear things up. If that paragraph doesn't make enough =
sense, maybe remove this and all its friends from the document.

The test cases are great. Consider adding a few more whose result is =
"Invalid Patch".

--Paul Hoffman=

From dret@berkeley.edu  Tue Jun 18 09:43:03 2013
Return-Path: <dret@berkeley.edu>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06F7D11E80C5 for <apps-discuss@ietfa.amsl.com>; Tue, 18 Jun 2013 09:43:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wbb7sceHBPrd for <apps-discuss@ietfa.amsl.com>; Tue, 18 Jun 2013 09:42:58 -0700 (PDT)
Received: from cm02fe.IST.Berkeley.EDU (cm02fe.IST.Berkeley.EDU [169.229.218.143]) by ietfa.amsl.com (Postfix) with ESMTP id 51E8A11E80E3 for <apps-discuss@ietf.org>; Tue, 18 Jun 2013 09:42:58 -0700 (PDT)
Received: from 99-38-249-227.lightspeed.sntcca.sbcglobal.net ([99.38.249.227] helo=[192.168.1.112]) by cm02fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from <dret@berkeley.edu>) id 1Uoyzg-0002nj-8K for apps-discuss@ietf.org; Tue, 18 Jun 2013 09:42:58 -0700
Message-ID: <51C08E0F.3080608@berkeley.edu>
Date: Tue, 18 Jun 2013 09:42:55 -0700
From: Erik Wilde <dret@berkeley.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: "apps-discuss@ietf.org application-layer protocols" <apps-discuss@ietf.org>
References: <20130618163623.21184.36942.idtracker@ietfa.amsl.com>
In-Reply-To: <20130618163623.21184.36942.idtracker@ietfa.amsl.com>
X-Forwarded-Message-Id: <20130618163623.21184.36942.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [apps-discuss] Fwd: New Version Notification for draft-sinnema-xacml-media-type-05.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 18 Jun 2013 16:43:03 -0000

FYI.


-------- Original Message --------

A new version of I-D, draft-sinnema-xacml-media-type-05.txt
has been successfully submitted by Remon Sinnema and posted to the
IETF repository.

Filename:	 draft-sinnema-xacml-media-type
Revision:	 05
Title:		 eXtensible Access Control Markup Language (XACML) XML Media Type
Creation date:	 2013-06-18
Group:		 Individual Submission
Number of pages: 9
URL: 
http://www.ietf.org/internet-drafts/draft-sinnema-xacml-media-type-05.txt
Status: 
http://datatracker.ietf.org/doc/draft-sinnema-xacml-media-type
Htmlized: 
http://tools.ietf.org/html/draft-sinnema-xacml-media-type-05
Diff: 
http://www.ietf.org/rfcdiff?url2=draft-sinnema-xacml-media-type-05

Abstract:
    This specification registers an XML-based media type for the
    eXtensible Access Control Markup Language (XACML).

Note to Readers

    This draft should be discussed on the apps-discuss mailing list [1].
    Online access to all versions and files is available on github [2].

From jasnell@gmail.com  Tue Jun 18 09:44:48 2013
Return-Path: <jasnell@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C465D11E80E3 for <apps-discuss@ietfa.amsl.com>; Tue, 18 Jun 2013 09:44:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AIfIZawUfVaA for <apps-discuss@ietfa.amsl.com>; Tue, 18 Jun 2013 09:44:48 -0700 (PDT)
Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 2033911E80C5 for <apps-discuss@ietf.org>; Tue, 18 Jun 2013 09:44:48 -0700 (PDT)
Received: by mail-ob0-f174.google.com with SMTP id wd20so4850619obb.5 for <apps-discuss@ietf.org>; Tue, 18 Jun 2013 09:44:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iHLLoUCmoauuVNc4wqA6NURspfhtyHbH+UkHHl9AQaM=; b=CgbFbjA+loIVkOLkqUXoVf/MALXUroU+8n5iolI8v9JdPm8PsOHKlZ9uWeiMOZcthE H1U4B9C6sk6uRi8TA5k+dcfa9mam3n4PFgUapfnSN8ZJY/7EKyznN6XsX86hjT8R01bE UmFmMI4JO492TGraH26uxJp2pZ8w8xXuXC/OYBfI0YsvvQZrPA1bsR41qezDXRH+7unF Zdco8poui8AGujuW74EGredyn1WM3584cg9o23RxJcYinlZHq7QSRRam/EIdvOEai5VQ uJzOnYzAgpTAu3nTUwlvbmmKhnu0lTshSYRtwBa8o1pwME4swDlMuGsBTBy0OsHGuu+s x63A==
MIME-Version: 1.0
X-Received: by 10.60.44.209 with SMTP id g17mr12443570oem.23.1371573887323; Tue, 18 Jun 2013 09:44:47 -0700 (PDT)
Received: by 10.60.76.231 with HTTP; Tue, 18 Jun 2013 09:44:47 -0700 (PDT)
Received: by 10.60.76.231 with HTTP; Tue, 18 Jun 2013 09:44:47 -0700 (PDT)
In-Reply-To: <2D7B00D1-74C9-4EE5-A4BB-B461CA455933@vpnc.org>
References: <2D7B00D1-74C9-4EE5-A4BB-B461CA455933@vpnc.org>
Date: Tue, 18 Jun 2013 09:44:47 -0700
Message-ID: <CABP7RbcH9r0LmpH8p=fsrAKd+ft=FAL24wSvbOgLXufceYeHcw@mail.gmail.com>
From: James M Snell <jasnell@gmail.com>
To: Paul Hoffman <paul.hoffman@vpnc.org>
Content-Type: multipart/alternative; boundary=001a1133120656568a04df706eaf
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Comments on draft-ietf-appsawg-json-merge-patch
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <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, 18 Jun 2013 16:44:48 -0000

--001a1133120656568a04df706eaf
Content-Type: text/plain; charset=UTF-8

I will try to clarify in the doc but the main point is that null values in
the patch doc are used to indicate deletion. That is, something like
{"foo":null} means "delete foo from the result".

Thank you for reviewing the draft.
On Jun 18, 2013 9:40 AM, "Paul Hoffman" <paul.hoffman@vpnc.org> wrote:

> Greetings again. This document mostly looks fine, and is pretty mature.
>
> I'm still confused about why the following exists in the document:
>        Any
>        object member or array element contained in the provided data
>        whose value is explicitly null is to be treated as if the member
>        is undefined and MUST NOT appear within the result.
> The wording has changed from draft to draft, but there is no explanation
> of why there should be something that exists in the patch document that
> should not exist in the result. Adding a paragraph about this design choice
> would clear things up. If that paragraph doesn't make enough sense, maybe
> remove this and all its friends from the document.
>
> The test cases are great. Consider adding a few more whose result is
> "Invalid Patch".
>
> --Paul Hoffman
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

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

<p dir=3D"ltr">I will try to clarify in the doc but the main point is that =
null values in the patch doc are used to indicate deletion. That is, someth=
ing like {&quot;foo&quot;:null} means &quot;delete foo from the result&quot=
;.</p>

<p dir=3D"ltr">Thank you for reviewing the draft.</p>
<div class=3D"gmail_quote">On Jun 18, 2013 9:40 AM, &quot;Paul Hoffman&quot=
; &lt;<a href=3D"mailto:paul.hoffman@vpnc.org">paul.hoffman@vpnc.org</a>&gt=
; wrote:<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Greetings again. This document mostly looks fine, and is pretty mature.<br>
<br>
I&#39;m still confused about why the following exists in the document:<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0Any<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0object member or array element contained in the =
provided data<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0whose value is explicitly null is to be treated =
as if the member<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0is undefined and MUST NOT appear within the resu=
lt.<br>
The wording has changed from draft to draft, but there is no explanation of=
 why there should be something that exists in the patch document that shoul=
d not exist in the result. Adding a paragraph about this design choice woul=
d clear things up. If that paragraph doesn&#39;t make enough sense, maybe r=
emove this and all its friends from the document.<br>

<br>
The test cases are great. Consider adding a few more whose result is &quot;=
Invalid Patch&quot;.<br>
<br>
--Paul Hoffman<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>
</blockquote></div>

--001a1133120656568a04df706eaf--

From bortzmeyer@nic.fr  Tue Jun 18 14:08:18 2013
Return-Path: <bortzmeyer@nic.fr>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1985C21F9A7C for <apps-discuss@ietfa.amsl.com>; Tue, 18 Jun 2013 14:08:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TrOMJNJrHNEj for <apps-discuss@ietfa.amsl.com>; Tue, 18 Jun 2013 14:08:13 -0700 (PDT)
Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [217.70.190.232]) by ietfa.amsl.com (Postfix) with ESMTP id B5B5021E8054 for <apps-discuss@ietf.org>; Tue, 18 Jun 2013 14:08:09 -0700 (PDT)
Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 178EE3B533; Tue, 18 Jun 2013 21:08:07 +0000 (UTC)
Received: by mail.sources.org (Postfix, from userid 1000) id C58ABCB3A3; Tue, 18 Jun 2013 23:07:24 +0200 (CEST)
Date: Tue, 18 Jun 2013 23:07:24 +0200
From: Stephane Bortzmeyer <bortzmeyer@nic.fr>
To: John Levine <johnl@taugh.com>
Message-ID: <20130618210724.GA19511@sources.org>
References: <20130610035950.26738.qmail@joyce.lan>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20130610035950.26738.qmail@joyce.lan>
X-Transport: UUCP rules
X-Operating-System: Debian GNU/Linux 7.1
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Another organization boundary design
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 18 Jun 2013 21:08:18 -0000

On Mon, Jun 10, 2013 at 03:59:50AM -0000,
 John Levine <johnl@taugh.com> wrote 
 a message of 20 lines which said:

> I've sent in a short draft describing a way to publish DNS
> organizational boundaries,

I confess that I do not understand it. It seems that TLD has a
special rule, for a reason I do not see. You write:

> and if the domain is just example, the client looks up _sb.example. 

To be consistent with the other examples, it should be example._sb,
no? (Also, switching from example.com to example in the middle of the
paragraph does not help.)


From johnl@taugh.com  Tue Jun 18 14:23:12 2013
Return-Path: <johnl@taugh.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E879F11E8109 for <apps-discuss@ietfa.amsl.com>; Tue, 18 Jun 2013 14:23:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.48
X-Spam-Level: 
X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.120,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IF1AkroU8NUb for <apps-discuss@ietfa.amsl.com>; Tue, 18 Jun 2013 14:23:09 -0700 (PDT)
Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 5979C11E80F9 for <apps-discuss@ietf.org>; Tue, 18 Jun 2013 14:23:08 -0700 (PDT)
Received: (qmail 96020 invoked from network); 18 Jun 2013 21:23:08 -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=17713.51c0cfbc.k1306; bh=g7uDmwvcma4CzD7m4e0+G6SkDkanVd0oNhTSYNhye2g=; b=N0OFwwGlESWcMxLWQUo7wP/YykRwYnPNwQIlgFf69QvCpmAnfwmja+tQ6hGvaFWZQRxijM15SeREFx6Djd3Any/GAfkHpwgz8/Yon/wpwikoUfEUCspgJezXv3tEz4lKgl9YMRUAvtYv6rt6+mn+3MtAFAx2hE5tDzRbVVDBlVbjFjabgGMZRGWqKOBJcHu10IuS0Q9fkP67+++T2PqcR4aNKstH3m1kYRjtUCuY1+QgNGkjUTqucar08GYzIxk+
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=17713.51c0cfbc.k1306; bh=g7uDmwvcma4CzD7m4e0+G6SkDkanVd0oNhTSYNhye2g=; b=NFBJ80LcS+yyLxoTVLOeGOS/U5UAUu9umPGyyCq6G5yI99EZCgjcn8rEIzsiXYG/pXooel9b7FuUKu8XinKgRREmizhlziR6cvRDJ8RLy+jQZY5ZA+88CBxa1IpOytpaYvTkWc+Sbphp0jz16OfoWAsNirQ4BaPj2GWEe6Ym6381L1qtZgNb178WLRbh17iW4Jb9BS1eBJF5Kj1qUfoWlbYxsQCkhS/Z1h0pJKitSfzslVDvXhOcOKS4eCHKv6Jk
Received: (ofmipd 127.0.0.1); 18 Jun 2013 21:22:45 -0000
Date: 18 Jun 2013 17:23:07 -0400
Message-ID: <alpine.BSF.2.00.1306181719440.37010@joyce.lan>
From: "John R Levine" <johnl@taugh.com>
To: "Stephane Bortzmeyer" <bortzmeyer@nic.fr>
In-Reply-To: <20130618210724.GA19511@sources.org>
References: <20130610035950.26738.qmail@joyce.lan> <20130618210724.GA19511@sources.org>
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: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Another organization boundary design
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 18 Jun 2013 21:23:12 -0000

> I confess that I do not understand it. It seems that TLD has a
> special rule, for a reason I do not see. You write:
>
>> and if the domain is just example, the client looks up _sb.example.

> To be consistent with the other examples, it should be example._sb, no?

That would require a _sb TLD, and one of the goals here is to make it 
possible for people to publish the policy records in zones they already 
manage.  It seems likely that ICANN will approve a large number of vanity 
TLDs where a single entity owns all names from the TLD on down, so I 
wanted a plausible way to describe that.

> (Also, switching from example.com to example in the middle of the
> paragraph does not help.)

It's true, this not not easy to explain using only IETF-approved sample 
domains.  That's why I gave up later and used real Canadian ones.

R's,
John

From mkomu@cs.hut.fi  Tue Jun 18 07:41:41 2013
Return-Path: <mkomu@cs.hut.fi>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E762E11E80DE for <apps-discuss@ietfa.amsl.com>; Tue, 18 Jun 2013 07:41:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xdtTsscNEh7L for <apps-discuss@ietfa.amsl.com>; Tue, 18 Jun 2013 07:41:37 -0700 (PDT)
Received: from mail.cs.hut.fi (mail.cs.hut.fi [130.233.192.7]) by ietfa.amsl.com (Postfix) with ESMTP id 778C121F9944 for <apps-discuss@ietf.org>; Tue, 18 Jun 2013 07:41:37 -0700 (PDT)
Received: from [127.0.0.1] (hutcs.cs.hut.fi [130.233.192.10]) by mail.cs.hut.fi (Postfix) with ESMTP id B65C9308E15 for <apps-discuss@ietf.org>; Tue, 18 Jun 2013 17:41:35 +0300 (EEST)
Message-ID: <51C0719F.2000500@cs.hut.fi>
Date: Tue, 18 Jun 2013 17:41:35 +0300
From: Miika Komu <mkomu@cs.hut.fi>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <p06240800ccc189b2c3ff@[192.168.0.101]> <43892743-D4CD-4137-B3BD-BCA321D9CE41@dsv.su.se> <CDE93777-E0E9-4D9D-89F3-AFCEBE3D6E4B@iki.fi>
In-Reply-To: <CDE93777-E0E9-4D9D-89F3-AFCEBE3D6E4B@iki.fi>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Tue, 18 Jun 2013 17:54:09 -0700
Subject: Re: [apps-discuss] Is e-mail going to die?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 18 Jun 2013 14:41:42 -0000

Hi,

On 06/15/2013 09:59 PM, Timo Sirainen wrote:
>> Even though there are technical problems, I still believe that
>>> email's opportunity to succeed is to replace email into a system
>>> where the sender pays a fee, say $0.10 per recipient, for
>>> sending messages. The old, unpaid system can continue to live in
>>> parallel to the new system.
> http://www.taugh.com/epostage.pdf  was mentioned as a reply to your
> last post, which I think describes pretty well why I doubt any actual
> money transactions aren't going to work. But I do wonder how far
> people have thought about using hashcash. I haven't really followed
> antispam efforts myself.. but I'd think a hashcash and some crypto
> combination could be made to work, if enough people show interest. A
> high level plan:
>
> - Every time you send a mail to a new contact, you'll have to pay
> with hashcash. The recipient SMTP server specifies the cost
> requirement and rejects the mail at RCPT TO stage if the payment
> isn't given.
>
> - For big ISPs/webmails and such the cost would have to be offloaded
> to the actual sender client, not the sending SMTP server. Yes, some
> slow clients might have to calculate it for minutes and show the user
> a progress bar showing how long it's going to take. ISPs could also
> sell this as a service to do it on the server side. Users could also
> opt to send it the old way and hope it gets through.
>
> - Each email you send to someone will contain a crypto key header
> that allows the recipient to send you back emails without calculating
> the hashcash.
>
> - Mailing list subscriptions would be done by sending them an email
> with the crypto key, which mailing lists can remember to make it free
> for them to send you the actual mails.
>
> - A crypto key would be specific to a single email address, so the
> crypto key headers could be thought of as public information. This
> requires SPF/DKIM to be enabled for the senders.
>
> - If your private crypto key gets leaked, you need to switch to a new
> one. This wouldn't be too bad, except you'd have to re-subscribe to
> the legitimate mailing lists, which perhaps could be automated with
> some extra work.
>
> - During transition phase this would basically just affect the spam
> scoring, so this could be implemented incrementally.
>
> - Requires new software for sending and receiving SMTP servers to be
> able to use this, but not necessarily new email clients. Webmail
> providers could calculate hashcash using Javascript on the background
> during composing the email. The main problem would be the old
> IMAP/POP3 clients trying to use free email providers.
>
> I don't see any obvious reason why the above couldn't work, other
> than the huge amount of work required and convincing all the major
> players to implement it. And it of course wouldn't completely
> eliminate spam, but it would make it much more costly, hopefully
> dropping the amount of spam from 99% of all mails to a few %. Botnets
> aren't free to use either.

for the record, Goodman et al have investigated spam mitigation with 
human-interactive proofs and computational puzzles:

http://dl.acm.org/citation.cfm?id=988779

Levchenko et al have analyzed that payment infrastructure is the 
bottleneck of the spam value chain and argue that spam could be tackled 
most effectively by political means, i.e, by enforcing a payment tier:

http://cseweb.ucsd.edu/~klevchen/kklevps-ccs08.pdf

I have been myself involved in investigating how to use the built-in 
puzzles of Host Identity Protocol for spam mitigation:

http://www.cs.helsinki.fi/u/starkoma/xhip_final.pdf

Deployment is an issue, similarly as in hashcash.

From internet-drafts@ietf.org  Tue Jun 18 20:10:45 2013
Return-Path: <internet-drafts@ietf.org>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F206E21F9A2C; Tue, 18 Jun 2013 20:10:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.514
X-Spam-Level: 
X-Spam-Status: No, score=-102.514 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNR6ydcyJ4Xj; Tue, 18 Jun 2013 20:10:44 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1017821F9079; Tue, 18 Jun 2013 20:10:44 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.51.p2
Message-ID: <20130619031044.17864.48882.idtracker@ietfa.amsl.com>
Date: Tue, 18 Jun 2013 20:10:44 -0700
Cc: apps-discuss@ietf.org
Subject: [apps-discuss] I-D Action: draft-wilde-xml-patch-05.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 19 Jun 2013 03:10:45 -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           : A Media Type for XML Patch Operations
	Author(s)       : Erik Wilde
	Filename        : draft-wilde-xml-patch-05.txt
	Pages           : 17
	Date            : 2013-06-18

Abstract:
   The XML Patch media type "application/xml-patch+xml" defines an XML
   document structure for expressing a sequence of patch operations that
   are applied to an XML document.  The XML Patch document format's
   foundations are defined in RFC 5261, this specification defines a
   document format and a media type registration, so that XML Patch
   documents can be labeled with a media type, for example in HTTP
   conversations.

   In addition to the media type registration, this specification also
   updates RFC 5261 in some aspects, limiting these updates to cases
   where RFC 5261 needed to be fixed, or was hard to understand.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-wilde-xml-patch

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-wilde-xml-patch-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-wilde-xml-patch-05


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From vesely@tana.it  Wed Jun 19 00:52:02 2013
Return-Path: <vesely@tana.it>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF1D321F9BD2 for <apps-discuss@ietfa.amsl.com>; Wed, 19 Jun 2013 00:52:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.719
X-Spam-Level: 
X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2z9bkDEiL6lB for <apps-discuss@ietfa.amsl.com>; Wed, 19 Jun 2013 00:51:58 -0700 (PDT)
Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id A198121F9CB4 for <apps-discuss@ietf.org>; Wed, 19 Jun 2013 00:51:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1371628305; bh=EPYdLvzZw31HGrajwQb1+GWmWHH4Jw9JrdyZklLzxc8=; l=1473; h=Date:From:To:References:In-Reply-To; b=jmBzPz2r2cO34M7PdIz3OPi8k9FX41u9mFyRloUSPL8tC9Vb51JkBxIGk/QOmIpu8 fXKvYF0cN0z6w/hZbSDzLkMxJ3ARBiIorD14+QGokEhEHb4mB8v/YG3y9gfPrKJXE+ Q6dmPrEgVlpohEaOalj+t/ChHF2n0UxkEagjIvk4=
Authentication-Results: tana.it; auth=pass (details omitted)
Received: from [172.25.197.156] (pcale.tana [172.25.197.156]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Wed, 19 Jun 2013 09:51:45 +0200 id 00000000005DC033.0000000051C16311.00002D1A
Message-ID: <51C16311.3040509@tana.it>
Date: Wed, 19 Jun 2013 09:51:45 +0200
From: Alessandro Vesely <vesely@tana.it>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <20130618072301.24613.52745.idtracker@ietfa.amsl.com> <CAL0qLwaO1iOJT4XR9Z+qUVtPVJps39w2LBUD_UikJQ+Tm8TGBA@mail.gmail.com> <CAKHUCzxPyHrgRBPX9Qvhe2pQAEBRyRV9=-HQy8D56suo1xbbeg@mail.gmail.com> <01OUZHJ179TW000054@mauve.mrochek.com> <CAKHUCzyAAZybgHna_ZpqyCYd4UxLtev126906c0eA+0JAeYtyQ@mail.gmail.com> <01OUZK7E1Y4E000054@mauve.mrochek.com>
In-Reply-To: <01OUZK7E1Y4E000054@mauve.mrochek.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-malformed-mail-06.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 19 Jun 2013 07:52:02 -0000

On Tue 18/Jun/2013 16:45:46 +0200 Ned Freed wrote:
> And if we're going to add new material, all this discussion of how to
> handle other cases of repeated fields reminded me of another one: Return-path.
> 
> I see multiple return-paths in messages pretty regularly. In most cases
> the values are the same, but sometimes they are different.
> 
> IMO the correct interpretation is that the first one wins since that's most
> likely to actually be the MAIL FROM inserted at final delivery. However, we
> might want to mention that delivery agents could check to see if there's
> already a return-path present with the same value as the one they're about to
> insert, and if there is, don't insert an additional one.

The abstract and the introduction let the reader guess that the
document is talking about modules of an MTA that strive to make sense
of a message received via SMTP.  However, "receivers" could also mean
IMAP clients downloading from a mailbox.  Some fields ought to be
treated differently in that case.

On SMTP reception, renaming Return-Path to Old-Return-Path is, IMHO, a
safe option.  The "true" Return-Path will be added by the MDA later
on.  On retrieval dices have rolled, and the above heuristic is all
that's left.

And how about Delivered-To?  Some MTAs use it to detect circular
dot-forward recipes, so its presence in the original message can be
disruptive --in some circumstances it can be an attack vector to force
NDNs.

From paulej@packetizer.com  Wed Jun 19 05:53:15 2013
Return-Path: <paulej@packetizer.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 634B121F9BD8 for <apps-discuss@ietfa.amsl.com>; Wed, 19 Jun 2013 05:53:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.284
X-Spam-Level: 
X-Spam-Status: No, score=-2.284 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_MILLIONSOF=0.315]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R4RwW3DRjDYT for <apps-discuss@ietfa.amsl.com>; Wed, 19 Jun 2013 05:52:58 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 39CED21F9BD3 for <apps-discuss@ietf.org>; Wed, 19 Jun 2013 05:52:58 -0700 (PDT)
Received: from [10.147.116.91] (64-103-25-233.cisco.com [64.103.25.233]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id r5JCqlQm029462 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 19 Jun 2013 08:52:49 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1371646370; bh=qwdYFFlYAEgl6S111JhXMXltp5wsBAZGRjFujpTJo7A=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=hS5fMRHDTdBNwCyIMhg74diJxXcAyXrxLzrJMbWbhQTGBeK8ffCDOvETNR/eQAXXG Xs66UF8DVDdcra46IuyixznKAFyIGwroRNmyBX+tabtNxrVMoev3CUG8IYkbahQCb4 vtZ0l4ndTNc3q31ePM1kktiBvhbpBeXAqZA3odPs=
Message-ID: <51C1A9A7.5040702@packetizer.com>
Date: Wed, 19 Jun 2013 08:52:55 -0400
From: "Paul E. Jones" <paulej@packetizer.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: Jacob Palme <jpalme@dsv.su.se>
References: <p06240800ccc189b2c3ff@[192.168.0.101]> <43892743-D4CD-4137-B3BD-BCA321D9CE41@dsv.su.se>
In-Reply-To: <43892743-D4CD-4137-B3BD-BCA321D9CE41@dsv.su.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: General discussion of application-layer protocols <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Is e-mail going to die?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 19 Jun 2013 12:53:15 -0000

On 6/15/2013 12:52 PM, Jacob Palme wrote:
> One thing I am noting since then is that other message systems
> are more and more used instead of email.

There have been for years, because each provides a different kind of 
service.  SMS and IM are usually for short messages that often encourage 
a relatively immediate response.  Bulletin boards of old and sites like 
Facebook today have always had private messaging capabilities.

> Large companies more and more are telling people who want to
> communicate with them to use a special web page instead of e-mail.
> Banks only allow me to communicate through a message system where
> I first have to log in to my bank account before sending and
> receiving messages to and from my bank. Other companies may do the
> same.

This is a pain point of mine and there are two parts to this.

First, there is the requirement to log in to send a message. The reasons 
for this are often said to be for "security" reasons. That's probably 
true in part, because end-to-end security of email often does not 
exist.  Another reason is likely because it's easier to build a 
proprietary messaging platform than to try to integrate the messaging 
platform with email.  And the banks will want to record and keep all of 
these messages.  Also, spam is a real problem, so they'd prefer to know 
who is sending messages.  Still, the end-to-end security is an issue.

Second, my bank will not send me communications, primarily for security 
reasons.  There is no guaranteed end-to-end security.  I'd love to have 
bank statements to me, but that will not happen with the current lack of 
security.  It would be very nice if the bank's MTA would be able to 
require end-to-end security and each MTA in the path would honor that 
request.  That would mean that each MTA in the path would have to refuse 
to forward messages unless the next hop agrees to adhere to the required 
end-to-end security procedures (whatever those are).


> It would not surprise me if email will die out, or rather will be less
> and less used as alternative messaging systems will replace email,
> so that in a few years most internet messaging will be done using
> another protocol than email.

I do not think it will die out, but I think it is falling short of its 
full potential due to lack of end-to-end security and uncontrollable spam.


> There are anti-spam systems like SpamSieve and SpamFire, but they
> have the problem that sometimes wanted messages are wrongly filtered
> out. And to manually read the mailbox containing all messages which
> have been filtered out, will mean that I do not get the advantage
> with spam filters - I have to scan through a list of all spam
> messages, and this is what the spam filters are meant to avoid.

Yeah, I have found no good solution.  If I filter spam, something gets 
misclassified.  I do block a lot of IP addresses if I get repeated 
spam.  I white list those that I know are known good senders.

> Even though there are technical problems, I still believe that
> email's opportunity to succeed is to replace email into a system
> where the sender pays a fee, say $0.10 per recipient, for sending
> messages. The old, unpaid system can continue to live in parallel
> to the new system.

Email fees have been discussed for years, but the problem is that valid 
senders of bulk email get hit pretty hard.  Just imagine how much money 
the IETF would have to pay to send messages to all of its subscribers.  
I don't think that's a workable solution.

What I do wish I had was better end-to-end security.  This security 
would include TLS so that communicating MTAs could mutually 
authenticate.  I would want MTAs to accept mail only over TLS and only 
to users that authenticate.  I would want all messages to be signed 
using DKIM.  I would want to be able to look at a message and know 
exactly who sent it and know it was secured end-to-end.  Any message not 
signed, I could reject.  Any legitimate sender would play be these rules.

Spammers would go to a CA and get a certificate and try to present 
itself as a valid sender, but once a purchaser of certificates is 
identified as a spammers, the CA could refuse to issue new 
certificates.  Essentially, the CAs can do a lot to help bring an end to 
spam.

Not every domain owner would necessarily need a certificate, but the 
hosting company would have to enforce rules that require entities using 
its services do not abuse its mail servers by sending spam.

Until we can get anything better in place, I continue to block millions 
of IP addresses.  I do enforce SPF if the domain indicates clearly all 
of its authorized mail servers, but that only prevents certain types of 
abuse.  I cannot enforce DKIM at all, because some senders do not sign 
messages properly.  I cannot even indicate that my domain always signs 
messages, because the signatures become invalid when going through some 
mailing lists and then rejected by receiving domains.

While I don't think email will die, there are certainly things that 
could and should be done to make it a more useful service and to cut 
down on spam.

Paul


From ned.freed@mrochek.com  Wed Jun 19 06:58:14 2013
Return-Path: <ned.freed@mrochek.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE52E21F9C0F for <apps-discuss@ietfa.amsl.com>; Wed, 19 Jun 2013 06:58:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6NYB8hF5linM for <apps-discuss@ietfa.amsl.com>; Wed, 19 Jun 2013 06:58:09 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id 41F5F21F9BCC for <apps-discuss@ietf.org>; Wed, 19 Jun 2013 06:58:09 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OV0WIQNJCG008GYM@mauve.mrochek.com> for apps-discuss@ietf.org; Wed, 19 Jun 2013 06:53:04 -0700 (PDT)
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 <01OUY9HQQS3K000054@mauve.mrochek.com>; Wed, 19 Jun 2013 06:53:01 -0700 (PDT)
Message-id: <01OV0WIOC6JI000054@mauve.mrochek.com>
Date: Wed, 19 Jun 2013 06:49:16 -0700 (PDT)
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Wed, 19 Jun 2013 09:51:45 +0200" <51C16311.3040509@tana.it>
References: <20130618072301.24613.52745.idtracker@ietfa.amsl.com> <CAL0qLwaO1iOJT4XR9Z+qUVtPVJps39w2LBUD_UikJQ+Tm8TGBA@mail.gmail.com> <CAKHUCzxPyHrgRBPX9Qvhe2pQAEBRyRV9=-HQy8D56suo1xbbeg@mail.gmail.com> <01OUZHJ179TW000054@mauve.mrochek.com> <CAKHUCzyAAZybgHna_ZpqyCYd4UxLtev126906c0eA+0JAeYtyQ@mail.gmail.com> <01OUZK7E1Y4E000054@mauve.mrochek.com> <51C16311.3040509@tana.it>
To: Alessandro Vesely <vesely@tana.it>
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] I-D Action:	draft-ietf-appsawg-malformed-mail-06.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 19 Jun 2013 13:58:15 -0000

> On Tue 18/Jun/2013 16:45:46 +0200 Ned Freed wrote:
> > And if we're going to add new material, all this discussion of how to
> > handle other cases of repeated fields reminded me of another one: Return-path.
> >
> > I see multiple return-paths in messages pretty regularly. In most cases
> > the values are the same, but sometimes they are different.
> >
> > IMO the correct interpretation is that the first one wins since that's most
> > likely to actually be the MAIL FROM inserted at final delivery. However, we
> > might want to mention that delivery agents could check to see if there's
> > already a return-path present with the same value as the one they're about to
> > insert, and if there is, don't insert an additional one.

> The abstract and the introduction let the reader guess that the
> document is talking about modules of an MTA that strive to make sense
> of a message received via SMTP.  However, "receivers" could also mean
> IMAP clients downloading from a mailbox.  Some fields ought to be
> treated differently in that case.

It's really talking about message interpretations at various stages,
not necessarily message modifications. In that view, the thing to say,
assuming we say anything, is only look at the top one.

> On SMTP reception, renaming Return-Path to Old-Return-Path is, IMHO, a
> safe option.  The "true" Return-Path will be added by the MDA later
> on.  On retrieval dices have rolled, and the above heuristic is all
> that's left.

The underlying point being that return-path is only supposed to appear
later.

Thinking about it more, the best thing to do on submission is probably
delete the field outright. But this document isn't about submit fixups, so
that's really out of scope.

> And how about Delivered-To?  Some MTAs use it to detect circular
> dot-forward recipes, so its presence in the original message can be
> disruptive --in some circumstances it can be an attack vector to force
> NDNs.

I don't think we should make any recommendations for nonstandard fields.

				Ned

From douglasroyer@gmail.com  Wed Jun 19 08:06:53 2013
Return-Path: <douglasroyer@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5751421F9CB8 for <apps-discuss@ietfa.amsl.com>; Wed, 19 Jun 2013 08:06:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.513
X-Spam-Level: 
X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W6EE4MUa-pf8 for <apps-discuss@ietfa.amsl.com>; Wed, 19 Jun 2013 08:06:34 -0700 (PDT)
Received: from mail-pb0-x234.google.com (mail-pb0-x234.google.com [IPv6:2607:f8b0:400e:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 6006B21F9CB2 for <apps-discuss@ietf.org>; Wed, 19 Jun 2013 08:06:33 -0700 (PDT)
Received: by mail-pb0-f52.google.com with SMTP id xa12so5124469pbc.25 for <apps-discuss@ietf.org>; Wed, 19 Jun 2013 08:06:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=kDvIyZYP0+c64g4qXKTgxpfdL/SKZkwEY1218EK0Z24=; b=jf+KjEHXkqt/IbIIf3bvzKXd9Ee0WKBqJ+/+eZ6KgcNQORGL+nw/bRDfSR7mGh5qrk LCxM43rljEuPzf5wdoizSEfq7NObb0SsM2nkVoeNSTOVM5I9ouxbiieN8Wg3tju/uEZ9 upMTIm6Lp5kNWqSRa7PVnXVGnjOmUlycEcZyyIfzDKDWzn+FsOfWqcco2U+Ur19jvcMP 9W770cTXO2TS/GuENhGzLx63XfWtn9iuSzt9qRN4FTo7sEX4+fKcmRBtdHw8aFEb2ZnX k2SSNwMQPSkeEZWHJaGPagaBwL1hsLYbolQt7LJrHU7x3dw4GRLDSJBG/EgyBKNCq063 8vFg==
X-Received: by 10.66.25.10 with SMTP id y10mr7206496paf.96.1371654392863; Wed, 19 Jun 2013 08:06:32 -0700 (PDT)
Received: from [192.168.15.4] (184-76-96-188.war.clearwire-wmx.net. [184.76.96.188]) by mx.google.com with ESMTPSA id ix3sm23448772pbc.37.2013.06.19.08.06.30 for <apps-discuss@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Jun 2013 08:06:31 -0700 (PDT)
Message-ID: <51C1C8F4.4090105@gmail.com>
Date: Wed, 19 Jun 2013 09:06:28 -0600
From: Doug Royer <douglasroyer@gmail.com>
Organization: http://SoftwareAndServices.NET
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <p06240800ccc189b2c3ff@[192.168.0.101]> <43892743-D4CD-4137-B3BD-BCA321D9CE41@dsv.su.se> <51C1A9A7.5040702@packetizer.com>
In-Reply-To: <51C1A9A7.5040702@packetizer.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [apps-discuss] e-mail / Security?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 19 Jun 2013 15:06:53 -0000

I think the solution is for person-to-person email is for MUA's to 
develop the ability to generate their own certs and a secure way to pass 
them as you see fit.

Clubs, mailing lists, and groups could post their public cert on their 
web pages so you can get them as you subscribe.

A new email header that says where your public cert is located. If it is 
a new email sender and you want to have secure email with them, click on 
a button on your MUA to load it.

Forget the pay for cert companies. It is easy to generate your own CA 
and cert for your own usage.

You could create black and white lists. No cert in the email, filter to 
a separate folder and decide on your own.

It is not common for me to get an email that I want from someone I have 
never heard of.

With MUA modifications, the MUA could select the appropriate cert for 
the destination email address. Sign up  for a mailing list, you get a 
cert for that list or organization you download. The MUA (for example), 
notices it ends with ietf.org and selects the ietf.org-cert it 
previously loaded.

There is MUCH more to think about, I think it would be an interesting 
discussion.



Doug Royer - (K7DMR.us / DougRoyer.com)
DouglasRoyer@gmail.com
714-989-6135



From dhc@dcrocker.net  Wed Jun 19 08:09:33 2013
Return-Path: <dhc@dcrocker.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5282421F9BB5 for <apps-discuss@ietfa.amsl.com>; Wed, 19 Jun 2013 08:09:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.552
X-Spam-Level: 
X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[AWL=0.047,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e53zQVTNLgLV for <apps-discuss@ietfa.amsl.com>; Wed, 19 Jun 2013 08:09:28 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 21F5621F9CB0 for <apps-discuss@ietf.org>; Wed, 19 Jun 2013 08:09:28 -0700 (PDT)
Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r5JF9NaZ018360 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 19 Jun 2013 08:09:26 -0700
Message-ID: <51C1C993.9020604@dcrocker.net>
Date: Wed, 19 Jun 2013 08:09:07 -0700
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Doug Royer <douglasroyer@gmail.com>
References: <p06240800ccc189b2c3ff@[192.168.0.101]> <43892743-D4CD-4137-B3BD-BCA321D9CE41@dsv.su.se> <51C1A9A7.5040702@packetizer.com> <51C1C8F4.4090105@gmail.com>
In-Reply-To: <51C1C8F4.4090105@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Wed, 19 Jun 2013 08:09:26 -0700 (PDT)
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] e-mail / Security?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: General discussion of application-layer protocols <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, 19 Jun 2013 15:09:33 -0000

On 6/19/2013 8:06 AM, Doug Royer wrote:
> Forget the pay for cert companies. It is easy to generate your own CA
> and cert for your own usage.


How is this different from the OpenPGP model?

d/


-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

From barryleiba@gmail.com  Wed Jun 19 08:13:00 2013
Return-Path: <barryleiba@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB3C621F9C78 for <apps-discuss@ietfa.amsl.com>; Wed, 19 Jun 2013 08:13:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.022
X-Spam-Level: 
X-Spam-Status: No, score=-102.022 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TOm8TDKHzhPj for <apps-discuss@ietfa.amsl.com>; Wed, 19 Jun 2013 08:13:00 -0700 (PDT)
Received: from mail-qa0-x22e.google.com (mail-qa0-x22e.google.com [IPv6:2607:f8b0:400d:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 710DF21F9BB5 for <apps-discuss@ietf.org>; Wed, 19 Jun 2013 08:12:59 -0700 (PDT)
Received: by mail-qa0-f46.google.com with SMTP id ih17so487810qab.5 for <apps-discuss@ietf.org>; Wed, 19 Jun 2013 08:12:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=+Aoi9gCwpwy+VMlRn1eVtEJKJXuP7TLHhNTqsNEJYAw=; b=wZKqaaOznneYxb4T98FvR76ItmpQ3w9KnQOWz/zjf3SJX3Imrv/ZsB68eRWGq2XVaZ MfkH45R27vBiIiJ0/DdRMDYjj9VI8jRF7pSC3Oh5FtK2iYUFJWgmWm9rMnIEwEA44kD2 01ioAsHQ+VW5hDi1IaPNJbFs5MJKRrARFWdWr8V+7MdH6C5Fj99Qi5h/6z/RjN8XThrx X0KQX9vrvVN7zJbcAxJqiQzQ8LU1QJij6DoAJcXWzl1mvaxg7HTFNWevLVsjOB1tDC2F BDPi8tTtDU9r42fmWxLkCSDknxmSlS8G0pTA4I3jasUbVrROaqDNfR8o2Z+L97UKQoBb X75g==
MIME-Version: 1.0
X-Received: by 10.229.117.132 with SMTP id r4mr1245909qcq.127.1371654778830; Wed, 19 Jun 2013 08:12:58 -0700 (PDT)
Sender: barryleiba@gmail.com
Received: by 10.224.0.139 with HTTP; Wed, 19 Jun 2013 08:12:58 -0700 (PDT)
In-Reply-To: <20130611111203.85CE06211A@rfc-editor.org>
References: <20130611111203.85CE06211A@rfc-editor.org>
Date: Wed, 19 Jun 2013 11:12:58 -0400
X-Google-Sender-Auth: GcLCe7JLMjnANmonSjOJYfZzru4
Message-ID: <CALaySJKOBMP7DxBkdvpaf0fjJ_3hoB+La4K=d6VX86onhqejxA@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
To: Apps Discuss <apps-discuss@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1
Cc: bkleint@gmail.com, ggood@netscape.com
Subject: Re: [apps-discuss] [Editorial Errata Reported] RFC2849 (3646)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 19 Jun 2013 15:13:01 -0000

The following errata report (which is about RFC 2849, in "Notes on
LDIF Syntax", note 4 (page 6)) seems correct to me.  "SAFE-UTF8-CHAR"
and "SAFE-INIT-UTF8-CHAR" are not defined in the ABNF, and it looks
like the note:

      4)  Any dn or rdn that contains characters other than those
          defined as "SAFE-UTF8-CHAR", or begins with a character other
          than those defined as "SAFE-INIT-UTF8-CHAR", above, MUST be
          base-64 encoded.  Other values MAY be base-64 encoded.  Any
          value that contains characters other than those defined as
          "SAFE-CHAR", or begins with a character other than those
          defined as "SAFE-INIT-CHAR", above, MUST be base-64 encoded.
          Other values MAY be base-64 encoded.

...was meant to use "SAFE-CHAR" and "SAFE-INIT-CHAR" in both sections
of the note (about dn or rdn, and about other values).

Does anyone here have comments about this report?  Does anyone think
it is *not* correct?

Barry, Applications AD

On Tue, Jun 11, 2013 at 7:12 AM, RFC Errata System
<rfc-editor@rfc-editor.org> wrote:
> The following errata report has been submitted for RFC2849,
> "The LDAP Data Interchange Format (LDIF) - Technical Specification".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=2849&eid=3646
>
> --------------------------------------
> Type: Editorial
> Reported by: Boris Kleint <bkleint@gmail.com>
>
> Section: Notes on LDI
>
> Original Text
> -------------
> Any dn or rdn that contains characters other than those
> defined as "SAFE-UTF8-CHAR", or begins with a character other
> than those defined as "SAFE-INIT-UTF8-CHAR",
>
> Corrected Text
> --------------
> Any dn or rdn that contains characters other than those
> defined as "SAFE-CHAR", or begins with a character other
> than those defined as "SAFE-INIT-CHAR",
>
> Notes
> -----
>
>
> Instructions:
> -------------
> This errata is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC2849 (draft-good-ldap-ldif-06)
> --------------------------------------
> Title               : The LDAP Data Interchange Format (LDIF) - Technical Specification
> Publication Date    : June 2000
> Author(s)           : G. Good
> Category            : PROPOSED STANDARD
> Source              : IETF - NON WORKING GROUP
> Area                : N/A
> Stream              : IETF
> Verifying Party     : IESG

From douglasroyer@gmail.com  Wed Jun 19 08:24:24 2013
Return-Path: <douglasroyer@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E272D21F9BAD for <apps-discuss@ietfa.amsl.com>; Wed, 19 Jun 2013 08:24:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.524
X-Spam-Level: 
X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 59a2luMAuNiq for <apps-discuss@ietfa.amsl.com>; Wed, 19 Jun 2013 08:24:19 -0700 (PDT)
Received: from mail-pd0-f173.google.com (mail-pd0-f173.google.com [209.85.192.173]) by ietfa.amsl.com (Postfix) with ESMTP id DCD2621F9CB8 for <apps-discuss@ietf.org>; Wed, 19 Jun 2013 08:24:18 -0700 (PDT)
Received: by mail-pd0-f173.google.com with SMTP id v14so5200338pde.4 for <apps-discuss@ietf.org>; Wed, 19 Jun 2013 08:24:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=7M498lXHdv+tk7f6GjQdsH2TIi5FvDt30yPoPCz7rqE=; b=Hn1p7rn6WlMpy0xs752HQoaygLNKUZxokHaVY9fN77klzlwZdV6K26QFNkxv56B52y yHMopSrOd/WKZjS4YpKePQDr1XebPluz/WGkk6MFxdJjgD0DOOAj6fygOeQsSXKghOOH P+nByLj2oEt4OhpcfehU21KR0TFlN/SMnx0mxITLhIogGRjx96yM2jJqAqBhFoASy34V 02NvoRRGdz6mJAYrWzhgU8K427HdOYSYpyEiq9EIuwYn2/GWUYSmJG1urYSxZaJAfvHi pYMqFLVio3xIeaezrrHIJlJICoczG0umaFJxMYRk1dVQKqU87tERjfd72/MYUkf5n+/p P6Xw==
X-Received: by 10.68.213.42 with SMTP id np10mr3357920pbc.37.1371655458265; Wed, 19 Jun 2013 08:24:18 -0700 (PDT)
Received: from [192.168.15.4] (184-76-96-188.war.clearwire-wmx.net. [184.76.96.188]) by mx.google.com with ESMTPSA id z5sm23570673pbk.0.2013.06.19.08.24.16 for <apps-discuss@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Jun 2013 08:24:17 -0700 (PDT)
Message-ID: <51C1CD1E.30605@gmail.com>
Date: Wed, 19 Jun 2013 09:24:14 -0600
From: Doug Royer <douglasroyer@gmail.com>
Organization: http://SoftwareAndServices.NET
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <p06240800ccc189b2c3ff@[192.168.0.101]> <43892743-D4CD-4137-B3BD-BCA321D9CE41@dsv.su.se> <51C1A9A7.5040702@packetizer.com> <51C1C8F4.4090105@gmail.com> <51C1C993.9020604@dcrocker.net>
In-Reply-To: <51C1C993.9020604@dcrocker.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [apps-discuss] e-mail / Security?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 19 Jun 2013 15:24:24 -0000

On 06/19/2013 09:09 AM, Dave Crocker wrote:
> On 6/19/2013 8:06 AM, Doug Royer wrote:
>> Forget the pay for cert companies. It is easy to generate your own CA
>> and cert for your own usage.
>
> How is this different from the OpenPGP model?
>
Mostly I am talking about modifications to the process and MUA's when 
sending and validating email. I will read more about OpenPGP later today 
(I am not up to date).  As I remember PGP was a trust ring. So maybe it 
would be the same process logical process, if the MUA supported it.

Few MUA's allow for non-technical persons to use S/MIME or PGP.

The act of using it (S/MIME or PGP) in the IETF mailing lists to start 
seeing what people like or works needs to start. Several years ago I 
used S/MIME to sign my email and the IETF mailing lists trimmed off the 
signature. Whatever methods that need to work, we need to try them. The 
mailing lists trimmed them off because MUA simply displayed them, did 
nothing with them, and users had to manually trim off the signature when 
replying. So people complained. No one ever complained that the message 
had a verified sender.

Heck, If we can agree to some real trial methods, and the mailing list 
does not trim it off - I'll write an add-on for Thunderbird to use it.

This topic has been discussed for decades. There does not seem to be a 
perfect solution. I don't think we will ever get to a solution until the 
MUA's support it.

Doug Royer - (K7DMR.us / DougRoyer.com)
DouglasRoyer@gmail.com
714-989-6135


From nico@cryptonector.com  Wed Jun 19 08:27:17 2013
Return-Path: <nico@cryptonector.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BABE21F9D01 for <apps-discuss@ietfa.amsl.com>; Wed, 19 Jun 2013 08:27:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.955
X-Spam-Level: 
X-Spam-Status: No, score=-1.955 tagged_above=-999 required=5 tests=[AWL=0.022,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id czuHrSe7v0cY for <apps-discuss@ietfa.amsl.com>; Wed, 19 Jun 2013 08:27:12 -0700 (PDT)
Received: from homiemail-a33.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 9C9D721F9121 for <apps-discuss@ietf.org>; Wed, 19 Jun 2013 08:27:12 -0700 (PDT)
Received: from homiemail-a33.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTP id 1148A59406B for <apps-discuss@ietf.org>; Wed, 19 Jun 2013 08:27:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=4kOHecSgNf1H9Ard+LkA 1q1GKWs=; b=lSlpGRpf1j3gqMZCSkJRFLzXSu3fg91LZCoZn1fJ0N9GsbngykRN NWNFS+bIUvrvhVU5uGOLPunGAmp5Zrzkci0KgWNHGal5reZWmGKF+UrHpcSG7cjX YIjaqn0RLIQ9d6RupCKWOoTla4owAO+xZ4y+3kPtXdCFtWAxDMz/FfY=
Received: from mail-we0-f178.google.com (mail-we0-f178.google.com [74.125.82.178]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTPSA id 77FB4594069 for <apps-discuss@ietf.org>; Wed, 19 Jun 2013 08:27:06 -0700 (PDT)
Received: by mail-we0-f178.google.com with SMTP id u53so4571230wes.37 for <apps-discuss@ietf.org>; Wed, 19 Jun 2013 08:27:03 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3F0rOTru9H7cuoaE+qD3msgJotqlXk4YZAG6GuryUDE=; b=KkFv0DNOU71SzCOgg7wtWPbmvO3oC1XnQoeSGqkjI7AQN4xH2LFQJW0vppAq99ekXR kCWR1uerHXzXMODi9/WPUAvFL8VDOSJOTSjxRpPvHVlqjP9JsG663rah2W6cOsL76rCA FaaVN8tiFbsV//xe/J6De+6oaz8/FV8Qrnfn34ng2MvM4oEas4Ox/eBxsTnM3N7M4mi1 T9kk6bKo8ufl3JbtGcGFEXBfItXu0e/1q93o5drcmebCmyVtTiQoNN4QDyYPCllbwVoz uqjLkEymn4g2PJrbV69rUi5KqFALtC1V0T9+aqAXKd2RHsBXOXJQAtwEWZzfNWhuFigT 7LGA==
MIME-Version: 1.0
X-Received: by 10.180.74.162 with SMTP id u2mr5646275wiv.36.1371655623692; Wed, 19 Jun 2013 08:27:03 -0700 (PDT)
Received: by 10.216.29.5 with HTTP; Wed, 19 Jun 2013 08:27:03 -0700 (PDT)
In-Reply-To: <51C1C8F4.4090105@gmail.com>
References: <p06240800ccc189b2c3ff@192.168.0.101> <43892743-D4CD-4137-B3BD-BCA321D9CE41@dsv.su.se> <51C1A9A7.5040702@packetizer.com> <51C1C8F4.4090105@gmail.com>
Date: Wed, 19 Jun 2013 10:27:03 -0500
Message-ID: <CAK3OfOh1DLZJWCMKmNALxWdU+e2QChyyx8HCkx6UVwU8BRX9DA@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Doug Royer <douglasroyer@gmail.com>
Content-Type: text/plain; charset=UTF-8
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] e-mail / Security?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 19 Jun 2013 15:27:17 -0000

I'd be happy with an MUA adaptation of OTR.  Exchange a couple of
e-mails and you have a session key in which to encrypt everything.
Then you could do ad-hoc authentication just like OTR.

Nico
--

From stpeter@stpeter.im  Wed Jun 19 08:34:03 2013
Return-Path: <stpeter@stpeter.im>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EEE021F9D19 for <apps-discuss@ietfa.amsl.com>; Wed, 19 Jun 2013 08:34:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.568
X-Spam-Level: 
X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mueB09iP+7PT for <apps-discuss@ietfa.amsl.com>; Wed, 19 Jun 2013 08:33:59 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B8DFF21F9CCF for <apps-discuss@ietf.org>; Wed, 19 Jun 2013 08:33:56 -0700 (PDT)
Received: from ergon.local (unknown [64.101.72.59]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 13087412CC; Wed, 19 Jun 2013 09:33:56 -0600 (MDT)
Message-ID: <51C1CF62.2010504@stpeter.im>
Date: Wed, 19 Jun 2013 09:33:54 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <p06240800ccc189b2c3ff@192.168.0.101> <43892743-D4CD-4137-B3BD-BCA321D9CE41@dsv.su.se> <51C1A9A7.5040702@packetizer.com> <51C1C8F4.4090105@gmail.com> <CAK3OfOh1DLZJWCMKmNALxWdU+e2QChyyx8HCkx6UVwU8BRX9DA@mail.gmail.com>
In-Reply-To: <CAK3OfOh1DLZJWCMKmNALxWdU+e2QChyyx8HCkx6UVwU8BRX9DA@mail.gmail.com>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: Paul Wouters <paul@cypherpunks.ca>
Subject: Re: [apps-discuss] e-mail / Security?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 19 Jun 2013 15:34:03 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 6/19/13 9:27 AM, Nico Williams wrote:
> I'd be happy with an MUA adaptation of OTR.  Exchange a couple of 
> e-mails and you have a session key in which to encrypt everything. 
> Then you could do ad-hoc authentication just like OTR.

Hi Nico,

Paul Wouters and I plan to spend some quality time together in Berlin
(postponed from Orland) working on an I-D about OTR as it stands
today. If we can get that published even as an informational RFC, the
OTR community might become more comfortable with working in the IETF
and we could look into an initiative to work on next-gen OTR-related
topics, including what you propose.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRwc9iAAoJEOoGpJErxa2pxBUP+QFai40ZuFWbpYbqCISFjh0Z
fRZsU345WznCE7s3jveA8px3uKSPh8D1patjD/xUdqc9nsvujzK3Dv9POwaLL/vl
h+9Fm8mEYJ4PumonrVvkqypIHlxTrWEjsAXHpg+awnZRpATMk4eQyuOjrHPLp4LT
j54GiwvHLLv8OHGlmvjWKvKSf3fmNtgsonAONYzsX9sYA/Gd3N6gClO4noFtscSB
P30PxVC59McXMV26/IClDnHCWNUUkVWkhxP2sX+5vvK9IfUVGFm4+wC255+rJSdF
GlQ4+w8WcZUHDMyhuamStc7k86XUkGuFHyTnQYMpRM4eQ5iM4VYF0eBaR/rp0sns
0CTRkIy3w5uo1GlNGXdx9duba0YAZnEjm811PKddPckf6l8P2cXWV9Hc6kwxGRJx
OpDwAFu2RamZaHmp73OVx+DvphHiba01cepoIQ8hq6Ese3BpTQYb661fsuZOrVEP
1o2oAWgXAXIs76qGKen6Bc2Wl+l1mW1RqA1XuoDCxWQNlFPCtKjPHN3eb05sIkLu
8koRQHJqYgVIpx4K0ULcgp72rIDnpUZ0qZX7BkdLH3YT2bhyxeQKq/tqmrPXgUiC
A4UKkKo0CZLXaKvn3FVCc4qPJflsYcLPfUeRv7LZ3q5xlIp51jw+wjKoZ2Of6Gud
dXZdgAWT67K9eFKEVUe7
=M7Ie
-----END PGP SIGNATURE-----

From johnl@taugh.com  Wed Jun 19 14:33:10 2013
Return-Path: <johnl@taugh.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B46AD21E810E for <apps-discuss@ietfa.amsl.com>; Wed, 19 Jun 2013 14:33:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.5
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y3UQEybiNYKh for <apps-discuss@ietfa.amsl.com>; Wed, 19 Jun 2013 14:33:09 -0700 (PDT)
Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id BAB1121E810A for <apps-discuss@ietf.org>; Wed, 19 Jun 2013 14:32:59 -0700 (PDT)
Received: (qmail 89469 invoked from network); 19 Jun 2013 21:32:58 -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=15d7c.51c2238a.k1306; bh=26TdShyW5ZNLli0J0OFpbEVNVtVLtzA/Jo81TYz8nEM=; b=VeBNPwGhZXK5/eda53vViIyIrAty1S6M2qr7DnYwZSH64NesJzbdRJRIRn4kzi8pWQDnr/FMS3vzy6kk8bHjLN4oVth12GNs/qSfHZpTYim3+tDCYUykrNMcA+r/AOPs45VKXDfcxKFRQmNDlMdv1XEhBEqMYskOHF/lx8mzLwklAF7hJ7eU5EM3vnun/4hrlWMkNQyATsdz+bseSFflLUzQrXZYPN1UgGJTDJzqlU+v0YRstTqlIQy7qbGxH5UN
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=15d7c.51c2238a.k1306; bh=26TdShyW5ZNLli0J0OFpbEVNVtVLtzA/Jo81TYz8nEM=; b=Z8EB90lZuJdFOFtc+1EFLmuTWuKw7fBtC6cjUS/i+hrnuVeWyOrZ1jxJA0lt58j8dHlNWZDFCMahQcBe6LGpILs5XoDFdtEUrJliYulXnQaHJ7oh9cH3ChVbkPbgDwJP4Z0r1GFrHTGaatSIrnPg0WYpKRJXT8sZFz6+HVJsHIn3ucBFoyyH4lRla2LM9rlsWURUP/PuO/OtSKeyNCaJ353Evh6fUPO9JdTSgRdQiOFi4/j/fl2U+8yDAKfPgXfh
Received: (ofmipd 127.0.0.1); 19 Jun 2013 21:32:36 -0000
Date: 19 Jun 2013 17:32:58 -0400
Message-ID: <alpine.BSF.2.00.1306191727320.49895@joyce.lan>
From: "John R Levine" <johnl@taugh.com>
To: "Nico Williams" <nico@cryptonector.com>
In-Reply-To: <CAK3OfOh1DLZJWCMKmNALxWdU+e2QChyyx8HCkx6UVwU8BRX9DA@mail.gmail.com>
References: <p06240800ccc189b2c3ff@192.168.0.101> <51C1C8F4.4090105@gmail.com> <51C1A9A7.5040702@packetizer.com> <43892743-D4CD-4137-B3BD-BCA321D9CE41@dsv.su.se> <CAK3OfOh1DLZJWCMKmNALxWdU+e2QChyyx8HCkx6UVwU8BRX9DA@mail.gmail.com>
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
Cleverness: None detected
MIME-Version: 1.0
Content-Type: MULTIPART/signed; protocol="application/pkcs7-signature"; micalg=sha1; BOUNDARY="3825401791-1923604991-1371677578=:49895"
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] e-mail / Security?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 19 Jun 2013 21:33:10 -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.

--3825401791-1923604991-1371677578=:49895
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

> I'd be happy with an MUA adaptation of OTR.  Exchange a couple of
> e-mails and you have a session key in which to encrypt everything.
> Then you could do ad-hoc authentication just like OTR.

Most MUAs that support S/MIME will remember the key from messages like 
this one and encrypt (perhaps after tweaking a global setting) mail to 
recipients whose keys they have.

S/MIME is also supposed to solve the introduction problem (how do you know 
that a correspondent is who she says she is?) so most MUAs get unhappy 
with unsigned certs, but I'd think that a tweak to accept them would 
typically be pretty easy.

Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.
--3825401791-1923604991-1371677578=:49895
Content-Type: APPLICATION/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: BASE64
Content-Description: S/MIME Cryptographic Signature
Content-Disposition: attachment; filename=smime.p7s

MIIJCQYJKoZIhvcNAQcCoIII+jCCCPYCAQExCzAJBgUrDgMCGgUAMAsGCSqG
SIb3DQEHAaCCBjowggY2MIIFHqADAgECAgMGLywwDQYJKoZIhvcNAQEFBQAw
gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD
VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTAeFw0xMzAzMTYxOTQ0MDdaFw0xNDAzMTgxMjI4MzVaMFUxGTAX
BgNVBA0TEHFaMXRuOTBuMkdVODZzemYxGDAWBgNVBAMMD2pvaG5sQHRhdWdo
LmNvbTEeMBwGCSqGSIb3DQEJARYPam9obmxAdGF1Z2guY29tMIIBIjANBgkq
hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAve/4NFMbuvtD6QSuXAoYQ0SkaO9s
DiNHA4saJNV0OIXd6dtM87w7OETKWWVq24Ab6vQaYh218oCF1GDdLv6EiRB8
oL1k9sK2v70iAVT83vEnmaj6/hQVcBI6mZJH6LXyCgYSP2e5yBQqJu+hgLte
bdg7kOKW2tb937jDn9KYRVFIlEU0/iu/b/Buwq3ahg2BsG3vg92Zk+Dv5VON
QDLE8x8wdi1cor7qBY/RERw4O3LXo3644OU0t6KS3aQxLrXEvWZHHvLhsAu1
BjYbC+qdSddDT1t+adEnZq9/wMhNGhPWCd/uFDZanSpyM913b7eI1Q2aNgA0
cccjEgBsp8IipwIDAQABo4IC1TCCAtEwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSL
djRDW8NpGZJjlhjZ0SLge0hCvjAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6W
NU7y1LhRgjAaBgNVHREEEzARgQ9qb2hubEB0YXVnaC5jb20wggFMBgNVHSAE
ggFDMIIBPzCCATsGCysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0
cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjCB9wYIKwYBBQUHAgIw
geowJxYgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqB
vlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhl
IENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0
Q29tIENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVk
IHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBv
YmxpZ2F0aW9ucy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5zdGFy
dHNzbC5jb20vY3J0dTEtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5Bggr
BgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczEv
Y2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNv
bS9jZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYY
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQCM
pgcOpxRJazPzEBYnhGENuQqzXeLyA3a8XL7YaxaAJwV7ucDVkyQHu35PUEkh
vVgIKnxq6N9WxHiO6GK/imdwS3LrUBbs+0v+95m6YhJv6ZfvAHTyTLqrozXU
ohR5NRFeL0p1OfK1llnl/I71Fe/JNgxJHDn1puzsFoJD3zYCKgNdST3FPNIb
2v/xIiubuB85tiJSWUlc56OkCdBK3ZgBnwYV8LxFmpOlwedaHC6sxIk1rsuX
BHbRIJwLFy2LqVtNm0M5NzBVyPQf72lPn/aaJLbqY5DDm4/lSy94R+CKXabE
6lWan7xmbqdDDlMxGbpMRWV2Cxi5ONp4uNgNcwI6MYIClzCCApMCAQEwgZQw
gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD
VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQQIDBi8sMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqG
SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNjE5MjEzMjU4WjAjBgkqhkiG
9w0BCQQxFgQUkJtv+rcRWt+RaiJXPkflx1japTQweQYJKoZIhvcNAQkPMWww
ajALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBAjAKBggq
hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4D
AgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAd4y+MNWZVBDL
5ZXZq4+vwO4IO+GH9BYXTYZGAug7ojRYdPuvUa2q7IrBBLs3rrcABoWSr++Q
evsUfTt/Ual2/iejXgFHsn02jwXEk1AKIhPfJDzCB8w+HWMpXT3ald+oK8xH
Q9olcakObwloT9j9QmGG42HBE+orvsg1hTiZgavK+ZEZH8nS2Yx+kt7QovJw
5Vy8/FYfUaoekslhkz4J1Kzrme+0y/V8vm3mDhdOZtGhGgHFFSLOIW+oN98A
Mh7m2npmcpHxUo/WmBXM3ax56WfwpKRogTVPUQz3tUd+kARCvK+K6DJ4lmii
4uZh2fwR+19k0uyz1/eb3yVlSbfVqA==

--3825401791-1923604991-1371677578=:49895--

From douglasroyer@gmail.com  Wed Jun 19 16:15:08 2013
Return-Path: <douglasroyer@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C10B821F9BB1 for <apps-discuss@ietfa.amsl.com>; Wed, 19 Jun 2013 16:15:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.803
X-Spam-Level: 
X-Spam-Status: No, score=-1.803 tagged_above=-999 required=5 tests=[AWL=-0.662, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YesiD06-6JON for <apps-discuss@ietfa.amsl.com>; Wed, 19 Jun 2013 16:15:07 -0700 (PDT)
Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id A84BB21F9B1D for <apps-discuss@ietf.org>; Wed, 19 Jun 2013 16:15:07 -0700 (PDT)
Received: by mail-pa0-f46.google.com with SMTP id fa11so5620903pad.5 for <apps-discuss@ietf.org>; Wed, 19 Jun 2013 16:15:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=G9UOXcd67KDGU9hg5pGMM2t3y6FIZwm1ac+3ZABhYTk=; b=tVYJ8+eLHzpsoBwgf1wr1XLGcdd/04KsaIOQVtiDPinIYBqaIt3JLMaBIMQYNqHscV lSsTW3hAzxUPGzal9tDBh2X3RRvq0H+7n7HIIuPo8wQCicHjIxMshi8J2Y1rChp0W0ma 8aMJF4kYYINdsXRqp3yZe6rxWMiTx2i06M4zylVrxKCx4Syk8A9wVdJJvDBm6d+Af3wu d3erfdbJfSaa5FvcdtzkyNy4vqo/HjELqTKxK2v712+YDvPEOWfu9iPeECPLTI4YvD4b KsMue8k9FaQWdJc4VMsK1xwns1STSDCXE4Tv/UdZkcHlmSOJfiqXHunleRs+urKL/vFy XvDA==
X-Received: by 10.66.121.169 with SMTP id ll9mr8782148pab.126.1371683707075; Wed, 19 Jun 2013 16:15:07 -0700 (PDT)
Received: from [192.168.15.4] (184-76-96-188.war.clearwire-wmx.net. [184.76.96.188]) by mx.google.com with ESMTPSA id o10sm24898300pbq.39.2013.06.19.16.15.05 for <apps-discuss@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Jun 2013 16:15:06 -0700 (PDT)
Message-ID: <51C23B77.7050105@gmail.com>
Date: Wed, 19 Jun 2013 17:15:03 -0600
From: Doug Royer <douglasroyer@gmail.com>
Organization: http://SoftwareAndServices.NET
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <p06240800ccc189b2c3ff@192.168.0.101> <51C1C8F4.4090105@gmail.com> <51C1A9A7.5040702@packetizer.com> <43892743-D4CD-4137-B3BD-BCA321D9CE41@dsv.su.se> <CAK3OfOh1DLZJWCMKmNALxWdU+e2QChyyx8HCkx6UVwU8BRX9DA@mail.gmail.com> <alpine.BSF.2.00.1306191727320.49895@joyce.lan>
In-Reply-To: <alpine.BSF.2.00.1306191727320.49895@joyce.lan>
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [apps-discuss] e-mail / Security?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 19 Jun 2013 23:15:08 -0000

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 06/19/2013 03:32 PM, John R Levine
      wrote:<br>
    </div>
    <blockquote cite="mid:alpine.BSF.2.00.1306191727320.49895@joyce.lan"
      type="cite">...<br>
      S/MIME is also supposed to solve the introduction problem (how do
      you know that a correspondent is who she says she is?) so most
      MUAs get unhappy with unsigned certs, but I'd think that a tweak
      to accept them would typically be pretty easy.&nbsp; ...<br>
    </blockquote>
    <br>
    The MUA implementations also need a way with S/MIME to load them in
    a more friendly manner. They ask this horrific question on a root
    cert load that scars the heck out of non-technical persons.<br>
    <br>
    In addition, if I could go to my Google, Yahoo, Bing, AOL, ...
    whoever and get a cert from my web&nbsp; email page. And they support
    using it, uploading it, and verifying it on reading email, this
    would go a long way.<br>
    <br>
    If the MUA gets a <b><i>new cert</i> </b>it does not recognize, it
    could verify it with some process yet to be defined. Ask the user,
    verify it against the ISP root cert (cert list, whatever...) the
    first new one (or updated one) would go through the verification
    process.<br>
    <br>
    If I press a button that says, 'someone stole my cert', then I think
    the replacement process could be simplified (perhaps?) by adding an
    email header saying 'by the way, my cert ID 'X', 'Y', and 'Z' are
    invalid. Over time, as I send email, those I communicate with would
    get updated with the new cert and my revocation list. They don't
    have to remember the revocation list, they just have to delete my
    'X', 'Y', and 'Z' certs.<br>
    <br>
    Having tried the public free and paid for CA/cert sites, the
    verification and distribution process is sometimes so complex that I
    have been unable to get a couple of them to work. They need to have
    rigid user verification processes because they are responsible for
    the certs and for verifying the identity of the email address. If
    however the certs are issued by the ISP's themselves, they don't
    need to do complex verification, as Google knows that
    <a class="moz-txt-link-abbreviated" href="mailto:DouglasRoyer@gmail.com">DouglasRoyer@gmail.com</a> is in fact <a class="moz-txt-link-abbreviated" href="mailto:DouglasRoyer@gmail.com">DouglasRoyer@gmail.com</a> . They can
    generate that cert, make it available to me, and if I can load it
    into any MUA I desire, I can just use it.<br>
    <br>
    I got over 300 spams last week. Ramping up to holidays where people
    tend to buy gifts, I have received up to 1200 in a day. Some of this
    is very rough thoughts, but I really think it is time to start it.<br>
    <br>
    I would think that Google for one would like me to one day say 'if
    it is not signed, toss it". And later "if it can not be verified,
    toss it'. It would save a ton of disk space.<br>
    <br>
    I would also like to see a POP/IMAP extension that allows the MUA to
    inform the POP/IMAP server that a message is SPAM. I can think of
    all kinds of spam unfriendly things a server can do with their smart
    spam filters. <br>
    <br>
    <pre class="moz-signature" cols="72">-- 

Doug Royer - (K7DMR.us / DougRoyer.com)
<a class="moz-txt-link-abbreviated" href="mailto:DouglasRoyer@gmail.com">DouglasRoyer@gmail.com</a>
714-989-6135
</pre>
  </body>
</html>

From nico@cryptonector.com  Wed Jun 19 16:25:12 2013
Return-Path: <nico@cryptonector.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3FAA21F9D85 for <apps-discuss@ietfa.amsl.com>; Wed, 19 Jun 2013 16:25:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.958
X-Spam-Level: 
X-Spam-Status: No, score=-1.958 tagged_above=-999 required=5 tests=[AWL=0.019,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7CdTRelp45H0 for <apps-discuss@ietfa.amsl.com>; Wed, 19 Jun 2013 16:25:08 -0700 (PDT)
Received: from homiemail-a28.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id DA0CD21F9D69 for <apps-discuss@ietf.org>; Wed, 19 Jun 2013 16:25:07 -0700 (PDT)
Received: from homiemail-a28.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTP id 4D6631B4058 for <apps-discuss@ietf.org>; Wed, 19 Jun 2013 16:25:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:content-type; s=cryptonector.com; bh=THkpqCntUGqVwjeVi249C6E ePNo=; b=v3vTp6Q8bsLlO0kcfrceU+7fU9/vvnuXWNcnQc162laqffvVNDW6ltJ BGp/s1Dl/8yKkzMZbvd3xFCA5WYOJ4tYgKfa1OJOibvXIj6sgjIEt2xqs+zzFhFe kEJYT0okzaWWNkENzEvQMtJ6v9RA0aTDARdP3HKSQwIeGFEo23Jk=
Received: from mail-we0-f176.google.com (mail-we0-f176.google.com [74.125.82.176]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTPSA id E50431B4057 for <apps-discuss@ietf.org>; Wed, 19 Jun 2013 16:25:06 -0700 (PDT)
Received: by mail-we0-f176.google.com with SMTP id t56so4929511wes.35 for <apps-discuss@ietf.org>; Wed, 19 Jun 2013 16:25:05 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=CU5Cj2UAOOw/CfqBQ81qu8p1KYHR2Szodi4u7ohsDYU=; b=DFoNjjmnT9vqeMMvVapzidXI1VPDP6gl1gJ9AxX3WDyNXv1El+hFSjSGTDMX57TEFD MKny7Z4JmyQY0hZEtQ1yCDtM0lCzWb284y5R5JnOxz7jLlC/GRPJEPJuqzOTpddB6fws eugrW2AjAbOur0pclFDcIm0TEwRnbIfDA92kX7JTEjOAzyb/8Spo2kkOZ+mQCsg6rD7W 1aTGTBgfmUGiYNjpyDtEdhnr8ibcNmlb9dtxTjaZmCqT1OUDeIqVoBN7HlUBLtpKCy11 sEfpyKb2uTkyt49ZO8z9QzjwaYlcJqY794inbkYtSnKO5gekjbqm6U4MawG2e3KV05OZ zqiQ==
MIME-Version: 1.0
X-Received: by 10.180.107.163 with SMTP id hd3mr11606872wib.13.1371684305047;  Wed, 19 Jun 2013 16:25:05 -0700 (PDT)
Received: by 10.216.29.5 with HTTP; Wed, 19 Jun 2013 16:25:04 -0700 (PDT)
In-Reply-To: <51C23B77.7050105@gmail.com>
References: <p06240800ccc189b2c3ff@192.168.0.101> <51C1C8F4.4090105@gmail.com> <51C1A9A7.5040702@packetizer.com> <43892743-D4CD-4137-B3BD-BCA321D9CE41@dsv.su.se> <CAK3OfOh1DLZJWCMKmNALxWdU+e2QChyyx8HCkx6UVwU8BRX9DA@mail.gmail.com> <alpine.BSF.2.00.1306191727320.49895@joyce.lan> <51C23B77.7050105@gmail.com>
Date: Wed, 19 Jun 2013 18:25:04 -0500
Message-ID: <CAK3OfOimc95NeRay4OGbWBi3sUQWzBXSNA=d2QUM8YOb26it-w@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: apps-discuss@ietf.org
Content-Type: text/plain; charset=UTF-8
Subject: Re: [apps-discuss] e-mail / Security?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 19 Jun 2013 23:25:12 -0000

Also, one of the nice things about OTR is that you don't need to have
a device that can memorize keys.  If you lose your device or your
peers change keys you just... re-authenticate them.

From johnl@iecc.com  Wed Jun 19 17:11:14 2013
Return-Path: <johnl@iecc.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B8A421F99D1 for <apps-discuss@ietfa.amsl.com>; Wed, 19 Jun 2013 17:11:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.79
X-Spam-Level: 
X-Spam-Status: No, score=-110.79 tagged_above=-999 required=5 tests=[AWL=0.409, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lvzyZ8KGIZGY for <apps-discuss@ietfa.amsl.com>; Wed, 19 Jun 2013 17:11:10 -0700 (PDT)
Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id EBD3321F9D0E for <apps-discuss@ietf.org>; Wed, 19 Jun 2013 17:11:09 -0700 (PDT)
Received: (qmail 23293 invoked from network); 20 Jun 2013 00:11:08 -0000
Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 20 Jun 2013 00:11:08 -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=51c2489c.xn--hew.k1306; i=johnl@user.iecc.com; bh=eJctFVmejxBjEMufWxYRYo4L1K8bi5GbeCh0+gTvOZc=; b=Y833OeqcsAxRCzOzbSqJoL//LAhlVceB1uGTkHSprI29SpMYi9HJ8SF3XSSWifyDk+dOjlhPDisMn4LF5o7j1WjIxInoX/EZTMMlHfa4/UZk3nBTYskMnsq8AMvkYexgd148abT4GJNJ4QOIPNReuxo0GQkIaZv+KsVBWfIdd0234LlPW4QmWBiCXh1OO1oJ7dBeWQMp0hLhNpuNZGK3MKxitEYtPGsoQVbIkTeeriP+7AgpIMvLsKeTlIJmbT/C
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=51c2489c.xn--hew.k1306; olt=johnl@user.iecc.com; bh=eJctFVmejxBjEMufWxYRYo4L1K8bi5GbeCh0+gTvOZc=; b=F4guBZae5idQrC6OcQsHxB7t9OQVeqySOxn5xaaEoczGeBrjiyFQy7BV9JCMYdbbdLNfequP1B9WEV01dSyVNuK+N1Zhnl54zwsScQ17C/2F7RbqlJ2HXBAI0Lh6LqkcuhvWfbN0dkmrvNCG/TFoX3D3zeYEgtZVqLTrkTRhtyT3WRX1evnN9fxt+X2gZkR9zTPTM+lIsUfYVxODptOPwfnq8nESfg2HB3zzE4wDHCVuO8AJm0Tdlm8Sl28N+FGw
Date: 20 Jun 2013 00:10:45 -0000
Message-ID: <20130620001045.50416.qmail@joyce.lan>
From: "John Levine" <johnl@taugh.com>
To: apps-discuss@ietf.org
In-Reply-To: <51C23B77.7050105@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] e-mail / Security?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 20 Jun 2013 00:11:14 -0000

>If the MUA gets a new cert it does not recognize, it could verify it with some process yet
>to be defined. Ask the user, verify it against the ISP root cert (cert list, whatever...)

Um, that's what it does now, verifies it against a list of signers.

>If I press a button that says, 'someone stole my cert', then I think the replacement process
>could be simplified (perhaps?) by adding an email header saying 'by the way, my cert ID 'X',
>'Y', and 'Z' are invalid.

I think we've just invented CRLs.  Keep in mind that bad guys will
send mail pretending to be from you saying that your certs are all
invalid.

>Having tried the public free and paid for CA/cert sites, the verification and distribution
>process is sometimes so complex that I have been unable to get a couple of them to work.

Yes, it's widely agreed that key distribution is the hardest part of
any signing scheme.

R's,
John

From ietf-secretariat-reply@ietf.org  Wed Jun 19 19:56:54 2013
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 (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5BC121F9FF5 for <apps-discuss@ietfa.amsl.com>; Wed, 19 Jun 2013 19:56:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.538
X-Spam-Level: 
X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YXQH8bkw+rYh; Wed, 19 Jun 2013 19:56:54 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E5D721F9F39; Wed, 19 Jun 2013 19:56:54 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
To: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-rfc5451bis@tools.ietf.org, sm+ietf@elandsys.com, apps-discuss@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.51.p2
Message-ID: <20130620025654.20959.90594.idtracker@ietfa.amsl.com>
Date: Wed, 19 Jun 2013 19:56:54 -0700
From: IETF Secretariat <ietf-secretariat-reply@ietf.org>
Subject: [apps-discuss] ID Tracker State Update Notice: <draft-ietf-appsawg-rfc5451bis-07.txt>
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 20 Jun 2013 02:56:55 -0000

IANA review state changed to IANA OK - Actions Needed
ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-rfc5451b=
is/


From vesely@tana.it  Thu Jun 20 02:45:10 2013
Return-Path: <vesely@tana.it>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A09B621E8113 for <apps-discuss@ietfa.amsl.com>; Thu, 20 Jun 2013 02:45:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.719
X-Spam-Level: 
X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ndUxjipuJo-S for <apps-discuss@ietfa.amsl.com>; Thu, 20 Jun 2013 02:45:05 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 225BB21E8114 for <apps-discuss@ietf.org>; Thu, 20 Jun 2013 02:45:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1371721501; bh=tNl//Wi3jS/EcoTuhofKVY1gDkq5zoJYMse1RXMhOn4=; l=1517; h=Date:From:To:References:In-Reply-To; b=vlnaziWfFKQoILcXqYe85MhPVnE5S/vRj/X9oJKdnBgsBXzILqHExhSOdu+ubx44+ O64UCQgjB0lNwTFDT/AeDTZN7VF1nxwP4ss/8sayrsHhs0cg4xta4HpZ90WtizWng7 N4XUlZUO8/6FBF+CflzT5kwzQ5q1tED4I2Sl5Gz8=
Authentication-Results: tana.it; auth=pass (details omitted)
Received: from [172.25.197.156] (pcale.tana [172.25.197.156]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k) by wmail.tana.it with ESMTPA; Thu, 20 Jun 2013 11:45:01 +0200 id 00000000005DC039.0000000051C2CF1D.00002DCA
Message-ID: <51C2CF1D.5070100@tana.it>
Date: Thu, 20 Jun 2013 11:45:01 +0200
From: Alessandro Vesely <vesely@tana.it>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <20130618072301.24613.52745.idtracker@ietfa.amsl.com> <CAL0qLwaO1iOJT4XR9Z+qUVtPVJps39w2LBUD_UikJQ+Tm8TGBA@mail.gmail.com> <CAKHUCzxPyHrgRBPX9Qvhe2pQAEBRyRV9=-HQy8D56suo1xbbeg@mail.gmail.com> <01OUZHJ179TW000054@mauve.mrochek.com> <CAKHUCzyAAZybgHna_ZpqyCYd4UxLtev126906c0eA+0JAeYtyQ@mail.gmail.com> <01OUZK7E1Y4E000054@mauve.mrochek.com> <51C16311.3040509@tana.it> <01OV0WIOC6JI000054@mauve.mrochek.com>
In-Reply-To: <01OV0WIOC6JI000054@mauve.mrochek.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-malformed-mail-06.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 20 Jun 2013 09:45:10 -0000

On Wed 19/Jun/2013 15:49:16 +0200 Ned Freed wrote:
> 
>> The abstract and the introduction let the reader guess that the
>> document is talking about modules of an MTA that strive to make sense
>> of a message received via SMTP.  However, "receivers" could also mean
>> IMAP clients downloading from a mailbox.
> 
> It's really talking about message interpretations at various stages,
> not necessarily message modifications. In that view, the thing to say,
> assuming we say anything, is only look at the top one.
> 
> [...] Thinking about it more, the best thing to do on submission is
> probably delete the field outright. But this document isn't about
> submit fixups, so that's really out of scope.

Agreed, submission is yet another stage where a message may get
interpreted and possibly modified.  Even if it's out of scope, Section
5 is not conceived as part of an attempt to enumerate those stages,
possibly summarizing, for each one, the pros and cons of committing an
interpretation vs keeping it private to the module that carried it
out.  In that sense, it may seem to contradict Section 4.

>> And how about Delivered-To?  Some MTAs use it to detect circular
>> dot-forward recipes, so its presence in the original message can be
>> disruptive --in some circumstances it can be an attack vector to force
>> NDNs.
> 
> I don't think we should make any recommendations for nonstandard fields.

Correct.  Do you know if there is any good reason why Delivered-To was
never registered?

From douglasroyer@gmail.com  Thu Jun 20 07:49:56 2013
Return-Path: <douglasroyer@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9CC921F9D59 for <apps-discuss@ietfa.amsl.com>; Thu, 20 Jun 2013 07:49:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.737
X-Spam-Level: 
X-Spam-Status: No, score=-1.737 tagged_above=-999 required=5 tests=[AWL=-0.596, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jXMiEOxU31eg for <apps-discuss@ietfa.amsl.com>; Thu, 20 Jun 2013 07:49:56 -0700 (PDT)
Received: from mail-pb0-x22d.google.com (mail-pb0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 4BB0121F9D3C for <apps-discuss@ietf.org>; Thu, 20 Jun 2013 07:49:50 -0700 (PDT)
Received: by mail-pb0-f45.google.com with SMTP id mc8so6339260pbc.4 for <apps-discuss@ietf.org>; Thu, 20 Jun 2013 07:49:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=BhyAa8BDAfvpARKLgYMtq6g3chkVC4yMbiot9a4zBXA=; b=bUa30vVNfBb1FTeejJr+oW6dBuO6fD/oum4Fi9ZyAoR2zGjtQmuR6S9FH2b7Ct5g5X pGxDo4cL09ARmzGyQLACFXGn6bgexHw7ixvZ4k8zaXBgPgQbI3J8YM7C5bB4heTPAbJh 2vCYaaHY8pL9TtDTA8LDAeoGN4afkwd/zjhIsBb+Svm9EqeLniuc961OBnqsk9V2koRp oka/1YUgnw2+5/SC1XWXi118CP6neE3u/kJ1ErkFcy9B96TMethbR2EfZcWO/pwERcFW kBFSLy+fEVaACl9I4pktDNUk+xt2Na0NB7ZJxtusK7VH2C2d3YcCIBMkrk39KM4B6IJ2 RR5Q==
X-Received: by 10.66.224.237 with SMTP id rf13mr11820812pac.26.1371739789995;  Thu, 20 Jun 2013 07:49:49 -0700 (PDT)
Received: from [192.168.15.4] (184-76-96-188.war.clearwire-wmx.net. [184.76.96.188]) by mx.google.com with ESMTPSA id v20sm1137300paj.4.2013.06.20.07.49.47 for <apps-discuss@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 20 Jun 2013 07:49:48 -0700 (PDT)
Message-ID: <51C3168A.5080605@gmail.com>
Date: Thu, 20 Jun 2013 08:49:46 -0600
From: Doug Royer <douglasroyer@gmail.com>
Organization: http://SoftwareAndServices.NET
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <20130620001045.50416.qmail@joyce.lan>
In-Reply-To: <20130620001045.50416.qmail@joyce.lan>
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: Re: [apps-discuss] e-mail / Security?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 20 Jun 2013 14:49:56 -0000

<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 06/19/2013 06:10 PM, John Levine
      wrote:<br>
    </div>
    <blockquote cite="mid:20130620001045.50416.qmail@joyce.lan"
      type="cite">
      <blockquote type="cite">
        <pre wrap="">If the MUA gets a new cert it does not recognize, it could verify it with some process yet
to be defined. Ask the user, verify it against the ISP root cert (cert list, whatever...)
</pre>
      </blockquote>
      <pre wrap="">
Um, that's what it does now, verifies it against a list of signers.</pre>
    </blockquote>
    Have you ever tried to get a new root CA into your browser or MUA?
    Could your grandmother do it? <i><b>Most of this is MUA
        implementation issues.</b></i> I still want to help move
    *something* forward.<br>
    <br>
    PGP or S/MIME in my opinion are not being used because it is too
    complicated for the average user to use.  Recently
    <a class="moz-txt-link-abbreviated" href="mailto:stpeter@stpeter.im">stpeter@stpeter.im</a> sent an email to the list that was PGP signed. No
    MUA that I have did anything except show it as in-line text. The
    text in the PGP signature said it was sent using Thunderbird. I am
    using Thunderbird - it did NOTHING with it, except show it as text.<br>
    <br>
    He could have generated that text from a random number generator,
    Thunderbird does not care. What process in the data flow of that
    email message cared to verify it or show it?<br>
    <br>
    Would it be possible for SMTP submission or relay sites to do some
    validation?<br>
    I would think it would be reasonable for Google , to require that
    when I submit an email using their SMTP server that it be verified
    with their signature or cert? <br>
    <blockquote cite="mid:20130620001045.50416.qmail@joyce.lan"
      type="cite">
      <blockquote type="cite">
        <pre wrap="">If I press a button that says, 'someone stole my cert', then I think the replacement process
could be simplified (perhaps?) by adding an email header saying 'by the way, my cert ID 'X',
'Y', and 'Z' are invalid.
</pre>
      </blockquote>
      <pre wrap="">
I think we've just invented CRLs.  Keep in mind that bad guys will
send mail pretending to be from you saying that your certs are all
invalid.</pre>
    </blockquote>
    Signed by me? With my new Cert ? Maybe I am uninformed. How would
    that work?<br>
    <br>
    <blockquote cite="mid:20130620001045.50416.qmail@joyce.lan"
      type="cite">
      <pre wrap="">
</pre>
      <blockquote type="cite">
        <pre wrap="">Having tried the public free and paid for CA/cert sites, the verification and distribution
process is sometimes so complex that I have been unable to get a couple of them to work.
</pre>
      </blockquote>
      <pre wrap="">
Yes, it's widely agreed that key distribution is the hardest part of
any signing scheme.
</pre>
    </blockquote>
    <br>
    I think that most of the problem is MUA implementation. Perhaps a
    S/MIME and PGP in a nutshell for implementers draft. Not sure,
    that's why I am poking around.<br>
    <br>
    <pre class="moz-signature" cols="72">-- 

Doug Royer - (K7DMR.us / DougRoyer.com)
<a class="moz-txt-link-abbreviated" href="mailto:DouglasRoyer@gmail.com">DouglasRoyer@gmail.com</a>
714-989-6135
</pre>
  </body>
</html>

From fanf2@hermes.cam.ac.uk  Thu Jun 20 08:46:11 2013
Return-Path: <fanf2@hermes.cam.ac.uk>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 016B721F9997 for <apps-discuss@ietfa.amsl.com>; Thu, 20 Jun 2013 08:46:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2AQBRzB7Pq2A for <apps-discuss@ietfa.amsl.com>; Thu, 20 Jun 2013 08:46:10 -0700 (PDT)
Received: from ppsw-33.csi.cam.ac.uk (ppsw-33.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f33]) by ietfa.amsl.com (Postfix) with ESMTP id 85B9221F998B for <apps-discuss@ietf.org>; Thu, 20 Jun 2013 08:46:07 -0700 (PDT)
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:37901) by ppsw-33.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1Uph3f-0000W5-ih (Exim 4.80_167-5a66dd3) (return-path <fanf2@hermes.cam.ac.uk>); Thu, 20 Jun 2013 16:45:59 +0100
Received: from fanf2 by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1Uph3f-0004VG-QE (Exim 4.72) (return-path <fanf2@hermes.cam.ac.uk>); Thu, 20 Jun 2013 16:45:59 +0100
Date: Thu, 20 Jun 2013 16:45:59 +0100
From: Tony Finch <dot@dotat.at>
X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk
To: Timo Sirainen <tss@iki.fi>
In-Reply-To: <CDE93777-E0E9-4D9D-89F3-AFCEBE3D6E4B@iki.fi>
Message-ID: <alpine.LSU.2.00.1306201644430.9686@hermes-2.csi.cam.ac.uk>
References: <p06240800ccc189b2c3ff@[192.168.0.101]> <43892743-D4CD-4137-B3BD-BCA321D9CE41@dsv.su.se> <CDE93777-E0E9-4D9D-89F3-AFCEBE3D6E4B@iki.fi>
User-Agent: Alpine 2.00 (LSU 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Tony Finch <fanf2@hermes.cam.ac.uk>
Cc: General discussion of application-layer protocols <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Is e-mail going to die?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 20 Jun 2013 15:46:11 -0000

Timo Sirainen <tss@iki.fi> wrote:
>
> But I do wonder how far people have thought about using hashcash. I
> haven't really followed antispam efforts myself.. but I'd think a
> hashcash and some crypto combination could be made to work, if enough
> people show interest.

Proof of work proves not to work:
http://www.cl.cam.ac.uk/~rnc1/talks/040607-ProofWork.pdf

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.

From johnl@iecc.com  Thu Jun 20 09:45:23 2013
Return-Path: <johnl@iecc.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 230E021F9E45 for <apps-discuss@ietfa.amsl.com>; Thu, 20 Jun 2013 09:45:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.826
X-Spam-Level: 
X-Spam-Status: No, score=-110.826 tagged_above=-999 required=5 tests=[AWL=0.373, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vUfS7oF-xdtZ for <apps-discuss@ietfa.amsl.com>; Thu, 20 Jun 2013 09:45:19 -0700 (PDT)
Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id D82F421F9E42 for <apps-discuss@ietf.org>; Thu, 20 Jun 2013 09:45:18 -0700 (PDT)
Received: (qmail 26962 invoked from network); 20 Jun 2013 16:45:16 -0000
Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 20 Jun 2013 16:45:16 -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=51c3319c.xn--30v786c.k1306; i=johnl@user.iecc.com; bh=7FhGquJroeQR3S+B7mS4oX8/HdBaIWkJQxqfZRGXAD4=; b=gmqacPVGpVBKLjxRqGmJIdy1bPCsLi2B4PMoj0WwQheMBzSPgu/flnNMdbJw+V1u6rcysPmobEwUQR4ok8SiDzf6PRa1iR8YYOvSJRwWvwy3D/TtUVHNtr7HkSCiRNwJsQDwhjKC0kj8+2cSuEipIyzcCWBhRhuCmTfSmo+Z/HQxDmlHzkKj1PCr2oHqMsixvNFHQB5uUQZ1ezuYwIO/lnh/Xl4N7S/nMRJsBkm2u7jtwdpUkqq3AbbQuOVuc5pg
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=51c3319c.xn--30v786c.k1306; olt=johnl@user.iecc.com; bh=7FhGquJroeQR3S+B7mS4oX8/HdBaIWkJQxqfZRGXAD4=; b=l4JLcgfvl8K3sBGJPGGG8hEwjL403VPBkeGOUUOm/RPePhC/3mfC3Uej7SkJihQeWrXu86KhOTcQDnFyvfqe+wBHcjCklCumABUnSwVdO+Q+GjPX7p1kF/raWmiqouENkD1HfcsCVur/QrhB1n7QZNsa3sNQ4L0awFD+BmZmmgEx2XA8QAOMYteNrGzFScFbTuFK139HcPeu2DYZ0aJatv/NImRXu3oHaO6zHCzeVR4+LsyZPRYivnetmOhXJNMU
Date: 20 Jun 2013 16:44:53 -0000
Message-ID: <20130620164453.61202.qmail@joyce.lan>
From: "John Levine" <johnl@taugh.com>
To: apps-discuss@ietf.org
In-Reply-To: <51C3168A.5080605@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] e-mail / Security?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 20 Jun 2013 16:45:23 -0000

>    Um, that's what it does now, verifies it against a list of signers.
>
>Have you ever tried to get a new root CA into your browser or MUA?

Yes.  Browsers are easy, visit http://www.abuse.net, scroll down to
the bottom, click, ignore the warnings as we have been trained to do,
and install my root CA.  I agree that getting them into MUAs is a lot
harder since they never have a UI for it.  Getting them into a browser
is too easy, into an MUA is too hard.

> Could your grandmother do it?

Probably not, since she's dead, but I take your point.

>    Yes, it's widely agreed that key distribution is the hardest part of
>    any signing scheme.
>
>I think that most of the problem is MUA implementation. Perhaps a S/MIME and PGP in a
>nutshell for implementers draft. Not sure, that's why I am poking around.

What you're thinking about is the introduction problem, how to tell
that a new acquaintance is who she says she is.  It is one that people
have been thinking about in computer contexts for decades, and in the
real world for millenia.  Before dashing off to solve it, I would
encourage you to do some homework so you know how and where your ideas
have failed before.

Also, if you think that better authentication will solve the spam
problem, don't waste your time.

R's,
John

From nico@cryptonector.com  Thu Jun 20 10:00:10 2013
Return-Path: <nico@cryptonector.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EE9421F9EA4 for <apps-discuss@ietfa.amsl.com>; Thu, 20 Jun 2013 10:00:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.959
X-Spam-Level: 
X-Spam-Status: No, score=-1.959 tagged_above=-999 required=5 tests=[AWL=0.018,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GF-WGMuMAIjI for <apps-discuss@ietfa.amsl.com>; Thu, 20 Jun 2013 10:00:04 -0700 (PDT)
Received: from homiemail-a72.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id A082421F9E6E for <apps-discuss@ietf.org>; Thu, 20 Jun 2013 10:00:02 -0700 (PDT)
Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id 0EBFE6B007C for <apps-discuss@ietf.org>; Thu, 20 Jun 2013 10:00:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=5eW8+JRCHYJbBSwsRUrW p3+A1yo=; b=vZ/k11yJYmOwdgW5cIoPO7Dnt/qrMH233ViLr4Ivm7A3RuTIXi9Q CCCLQOJV1UxYPddyzMgoP7icv82r141q1DbLadWuUppJJiGiHy93pXUARfjz8E5b 8S1wY40ARL+6jjQy+7AQdrwlYvlhC7nnIXVQn3tVGpY4BC9SNd+ywWc=
Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTPSA id E67996B0083 for <apps-discuss@ietf.org>; Thu, 20 Jun 2013 10:00:00 -0700 (PDT)
Received: by mail-wg0-f43.google.com with SMTP id z11so5741702wgg.10 for <apps-discuss@ietf.org>; Thu, 20 Jun 2013 09:59:59 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AFJ0y4KV0Ap7j75O3abUzHxC7grZ3nyTWjUvc9p9LxI=; b=ahqgA4OCfCOkgwiLOr6bb3vZLMTo0fELtWmkKakji7wUdxaO+Zvh4nKtgJ7VgkkqZM 8dM+gWEWPQ9tALp6uuoHTsqp/jadnCFB/AxKvHS67ovJeWDSZEDftTo5i/x0FyOjcZGF U3WdkvHAJhUhXwFKa3uBKVXGDH4Wi+b0tE01c96Cz5Y3oqOAXLgsfPEl0gRYWYCZmutm whL1+huneRUjGHXOGabsNSs9QihFZu7p9/M3damIuTwcTgb+z3i75hOVx8yH+MjJbta0 3PdKBqsD0F0n1EsphYQOyki0sw7G3YWYMTwORJimbJx5kCb5OSb13MxlQV8IXXzdyNBg /T7Q==
MIME-Version: 1.0
X-Received: by 10.180.182.83 with SMTP id ec19mr2718063wic.0.1371747599093; Thu, 20 Jun 2013 09:59:59 -0700 (PDT)
Received: by 10.216.29.5 with HTTP; Thu, 20 Jun 2013 09:59:58 -0700 (PDT)
In-Reply-To: <20130620164453.61202.qmail@joyce.lan>
References: <51C3168A.5080605@gmail.com> <20130620164453.61202.qmail@joyce.lan>
Date: Thu, 20 Jun 2013 11:59:58 -0500
Message-ID: <CAK3OfOiyvfwc5zTd=K8ygCsNuVkqNT0KJ3Q9fccn3zeqyA7Zog@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: John Levine <johnl@taugh.com>
Content-Type: text/plain; charset=UTF-8
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] e-mail / Security?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 20 Jun 2013 17:00:10 -0000

On Thu, Jun 20, 2013 at 11:44 AM, John Levine <johnl@taugh.com> wrote:
>>I think that most of the problem is MUA implementation. Perhaps a S/MIME and PGP in a
>>nutshell for implementers draft. Not sure, that's why I am poking around.
>
> What you're thinking about is the introduction problem, how to tell
> that a new acquaintance is who she says she is.  It is one that people
> have been thinking about in computer contexts for decades, and in the
> real world for millenia.  Before dashing off to solve it, I would
> encourage you to do some homework so you know how and where your ideas
> have failed before.

There are no (and almost certainly will not be) new solutions to the
introduction problem.  However, OTR is about as workable as we can get
with no infrastructure and no web of trust, and it's the
infrastructure and web of trust that makes existing systems hard to
use.  OTR is therefore the easiest-to-use solution.

> Also, if you think that better authentication will solve the spam
> problem, don't waste your time.

Indeed, there's no solution to the spam problem (hmmm, except
deterrence; there are times when the death penalty seems too lenient
for spammers).

Nico
--

From dhc@dcrocker.net  Thu Jun 20 10:09:42 2013
Return-Path: <dhc@dcrocker.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19E7A21F9D57 for <apps-discuss@ietfa.amsl.com>; Thu, 20 Jun 2013 10:09:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.568
X-Spam-Level: 
X-Spam-Status: No, score=-6.568 tagged_above=-999 required=5 tests=[AWL=0.031,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y+xHLpuZrLzT for <apps-discuss@ietfa.amsl.com>; Thu, 20 Jun 2013 10:09:36 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 60E0C21F9D30 for <apps-discuss@ietf.org>; Thu, 20 Jun 2013 10:09:36 -0700 (PDT)
Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r5KH9V5E019158 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 20 Jun 2013 10:09:35 -0700
Message-ID: <51C3373A.4000308@dcrocker.net>
Date: Thu, 20 Jun 2013 10:09:14 -0700
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Nico Williams <nico@cryptonector.com>
References: <51C3168A.5080605@gmail.com> <20130620164453.61202.qmail@joyce.lan> <CAK3OfOiyvfwc5zTd=K8ygCsNuVkqNT0KJ3Q9fccn3zeqyA7Zog@mail.gmail.com>
In-Reply-To: <CAK3OfOiyvfwc5zTd=K8ygCsNuVkqNT0KJ3Q9fccn3zeqyA7Zog@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Thu, 20 Jun 2013 10:09:35 -0700 (PDT)
Cc: John Levine <johnl@taugh.com>, apps-discuss@ietf.org
Subject: Re: [apps-discuss] e-mail / Security?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: General discussion of application-layer protocols <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, 20 Jun 2013 17:09:42 -0000

On 6/20/2013 9:59 AM, Nico Williams wrote:
> There are no (and almost certainly will not be) new solutions to the
> introduction problem.  However, OTR is about as workable as we can get
> with no infrastructure and no web of trust, and it's the
> infrastructure and web of trust that makes existing systems hard to
> use.  OTR is therefore the easiest-to-use solution.


Just to add some seasoning to the frankly bland abstractions of this 
technical exchange, I'll suggest that the only interesting problems in 
this space are with the human factors.  Figure out how to make this 
usable for non-technical folk.

The state of the art -- nevermind the state of the industry -- for 
usable security is remarkably and tenaciously poor.  As an example, we 
still have software from major vendors that issues security alerts 
users' screens without indicating what package is generating the alert; 
and then, of course, there's the cognitive demands at the foundation of 
most such alerts.

As a hint, I'll note that "get a new root CA into your browser or MUA" 
is a technically reasonable piece of the puzzle, but it primarily 
highlights the failed UX design that we currently experience.  That is, 
simply casting a design goal in terms of a user's adding a root 
guarantees failure.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

From johnl@taugh.com  Thu Jun 20 10:25:15 2013
Return-Path: <johnl@taugh.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE02421F9A5F for <apps-discuss@ietfa.amsl.com>; Thu, 20 Jun 2013 10:25:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.5
X-Spam-Level: 
X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3IixN1Es+Eq0 for <apps-discuss@ietfa.amsl.com>; Thu, 20 Jun 2013 10:25:15 -0700 (PDT)
Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id C735E21F9A52 for <apps-discuss@ietf.org>; Thu, 20 Jun 2013 10:25:14 -0700 (PDT)
Received: (qmail 36236 invoked from network); 20 Jun 2013 17:25:13 -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=8d8b.51c33af9.k1306; bh=fD499IeCk9KzzlEIXBiCcRYICrDNk3qqzuGp2rDxBLQ=; b=fjHd2OGE7ECsppCq1sLgwpW/MPnx4X+fxFNY+cfoqydWht1fG8v0EgIvAjvxle3dzwM8oco7UcUtPxoL59fmSccoQ1e72yzCpJ7jHW8HGZK0lONVYrmh4c6m2AstT5UfJLS3bfYCwmJp80+I2UP4W65H2qa99YW6ZHg9a+jnQM1EiU15LxH/4i3gzSy3LkQV0hPN4DvlI+9vyGa8YalaOpVw7KYDL4lqentGeqtwBCzKWjYrYTIZe8aeigj4Z9Ve
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=8d8b.51c33af9.k1306; bh=fD499IeCk9KzzlEIXBiCcRYICrDNk3qqzuGp2rDxBLQ=; b=lE3sEUaFmD0YHvWYYfLdpo/73pMCMx4dufyJpbX2xD3I4pynzk1qPpDahIrY2I9ZI8gRROTu9q2mJx3ZC3wU9nepPpdQ3UFBBMs1HvQQnsLgnhtrPiI1fK2Zx3sLdpg8qNnUL44IjblDWArucbI1TWMESrQyRaSgGbRPYW9A7R8Wgifi78doKk9KCHDWlxLOtaKMDuWKXpd0DcEBg8g8Bi/bTB0rxxUnZyHV2cCtzMV86eP2f3pa2CxpKVPKeZjQ
Received: (ofmipd 127.0.0.1); 20 Jun 2013 17:24:51 -0000
Date: 20 Jun 2013 13:25:13 -0400
Message-ID: <alpine.BSF.2.00.1306201303550.61276@joyce.lan>
From: "John R Levine" <johnl@taugh.com>
To: "Nico Williams" <nico@cryptonector.com>
In-Reply-To: <CAK3OfOiyvfwc5zTd=K8ygCsNuVkqNT0KJ3Q9fccn3zeqyA7Zog@mail.gmail.com>
References: <51C3168A.5080605@gmail.com> <20130620164453.61202.qmail@joyce.lan> <CAK3OfOiyvfwc5zTd=K8ygCsNuVkqNT0KJ3Q9fccn3zeqyA7Zog@mail.gmail.com>
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
Cleverness: None detected
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] e-mail / Security?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 20 Jun 2013 17:25:15 -0000

> There are no (and almost certainly will not be) new solutions to the
> introduction problem.  However, OTR is about as workable as we can get
> with no infrastructure and no web of trust, and it's the
> infrastructure and web of trust that makes existing systems hard to
> use.  OTR is therefore the easiest-to-use solution.

OTR does a nice job of protecting the channel.  It has some ways to verify 
the other party, but it is my impression that everyone turns them off.

Perhaps if we more clearly separated the identity applications from the 
channel applications, we'd be able to design stuff that addresses one or 
the other more effectively.

Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

From douglasroyer@gmail.com  Thu Jun 20 15:11:27 2013
Return-Path: <douglasroyer@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66CDC21F9EF6 for <apps-discuss@ietfa.amsl.com>; Thu, 20 Jun 2013 15:11:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.204
X-Spam-Level: 
X-Spam-Status: No, score=-2.204 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599, SARE_HOMELOAN=0.415]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15qt+63r5klJ for <apps-discuss@ietfa.amsl.com>; Thu, 20 Jun 2013 15:11:26 -0700 (PDT)
Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 69B8B21F9EF5 for <apps-discuss@ietf.org>; Thu, 20 Jun 2013 15:11:26 -0700 (PDT)
Received: by mail-pa0-f42.google.com with SMTP id rl6so6842097pac.1 for <apps-discuss@ietf.org>; Thu, 20 Jun 2013 15:11:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=HqtOEfS34WhuQnolbkvULGWGDHY7Ie3K4sOBv0BgHDk=; b=NFFdadFBR2KXJBpmMGaLPwj0uAJQeobn6nGhdw0GTHvv6vpEHxIhU0QeydwrSgVf0h 38CkiVC2jcHcBj+Q1s4VBJ8YjhfZfbwus/3UJPjdq83Liu9q9ZFX6LnXo8YmmGaIUV+X uAriKjaX5O9mZ9Jsx0z7YyyodWuScNJhZZddr0HsvRgiSNan7tqsW3Blvlgd9vqUP97Z 01WdDfK/5RgiwCC4pRzzisOVQAobgmsMIX2OhB1gWt/+LBor9/ltAjc17cmnUMT2G1iZ DbTfrKvYdGFQ+Nfv/cZ8UZBvD3lYdMCr06JtfQlf4LTSgmgc9zruJ3kp+rvqSuxQ/I5e nKhw==
X-Received: by 10.68.236.42 with SMTP id ur10mr9334948pbc.206.1371766285459; Thu, 20 Jun 2013 15:11:25 -0700 (PDT)
Received: from [192.168.15.4] (184-76-96-188.war.clearwire-wmx.net. [184.76.96.188]) by mx.google.com with ESMTPSA id fn9sm2525507pab.2.2013.06.20.15.11.23 for <apps-discuss@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 20 Jun 2013 15:11:24 -0700 (PDT)
Message-ID: <51C37E09.9070704@gmail.com>
Date: Thu, 20 Jun 2013 16:11:21 -0600
From: Doug Royer <douglasroyer@gmail.com>
Organization: http://SoftwareAndServices.NET
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130510 Thunderbird/17.0.6
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <20130620164453.61202.qmail@joyce.lan>
In-Reply-To: <20130620164453.61202.qmail@joyce.lan>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [apps-discuss] e-mail / Security?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 20 Jun 2013 22:11:27 -0000

On 06/20/2013 10:44 AM, John Levine wrote: (and Below Response to Dave 
Cocker email)
> What you're thinking about is the introduction problem, how to tell 
> that a new acquaintance is who she says she is. It is one that people 
> have been thinking about in computer contexts for decades, and in the 
> real world for millenia. Before dashing off to solve it, I would 
> encourage you to do some homework so you know how and where your ideas 
> have failed before. Also, if you think that better authentication will 
> solve the spam problem, don't waste your time. R's, John 

I agree it will not stop spam. It might help me or an ISP identify it.

I think that adding a IMAP/POP extension that says message #3 is spam 
can help the ISP filters when 10,000 people have clicked spam for the 
same message. If signed email was required for submission or acceptance, 
and the spammer generated a new CA for each set of spam messages, you 
could identify and stop it real fast with dynamic feedback to the 
servers. Or if they used the same cert for all of their spam, again it 
could be stopped real fast.

I think that moving to cert based email submission will prevent the 
person that broke in to my hotmail account last week that hacked my 
obscure and complex password from submitting email as me - unless he 
also steals my cert. I knew it happened only after getting some nutty 
replies to email I never sent. If I would have had to supply an S/MIME 
message to be submitted, it would have not made it to a few hundred (or 
more) people.

My other concern is the few emails I send per year that I want private.

I did some consulting work for mortgage processing and home loans 
(mismo.org) where they concluded that they wanted to be in control of 
their CA. There distribution process was certified snail mail. I would 
be happy if Google gave me my cert for my gmail account with a simple 
button to generate a new one when needed. A protocol between the browser 
and MUA to their server that auto-loaded and set it up to work. My MUA 
(browser) connects to your email's POP/IMAP or SMTP (or email web page) 
server, their server recognizes I have not submitted THEIR cert or have 
an old one. It sends message, agreed on authentication occurs, my 
MUA/browser gets auto-updated via SMTP, POP, IMAP, extensions or some 
other out of band protocol.

I have been reading IETF lists since 1978 when my email address ended 
with .arpa, and have seen a lot of failures. Technology has evolved, 
S/MIME would have been impossible when a 1-MIP VAX cost $1-million 
dollars and the IT staff said HELL NO - don't waste any CPU time on that 
stuff. I tried S/MIME and the only complaint I got was "what is that 
stuff at the end of your email?".  An MUA that supports S/MIME reported 
it as authenticated. That is backwards, they should flash a red box that 
says "not authenticated"

I have not seen an ISP generated certs for their customers auto loaded 
and by default get used. I have not seen signed email required or even 
preferred for submission.

And Dave Crocker Wrote:

 > As a hint, I'll note that "get a new root CA into your browser or MUA 
" is a technically
 > reasonable piece of the puzzle, but it primarily highlights the 
failed UX design that we
 > currently experience.  That is, simply casting a design goal in terms 
of a user's adding
 > a root guarantees failure.

Yes. The solution needs to include a user model that can be easily 
replicated by any MUA. Same well thought out steps in the same order to 
reach a new and safer working conclusion.

I want it to be as simple as: (1) Get an email address (2) run your here 
is my email address to my MUA, (3) it asks the same difficult to figure 
out SMTP/POP/IMAP questions (4) does agreed on authentication (5) when 
happy AUTO-LOADS my new cert.

Perhaps a SMTP/POP/IMAP configuration protocol? I know the mobile world 
would love that. I did some technical work for a huge mobile phone 
company last year.  The most annoying problem to solve was how to convey 
to a grandmother that wants to get grandchildren photos via email and 
just knows her email address. They had a small staff of people that did 
nothing but try to keep up to date on the port, protocol, user name vs 
email is the user name, vs IMAP or POP, vs other Android or iPhone 
specific ways of asking the same questions different ways for each ISP. 
And  while your at it, auto-load the cert and send a test email message 
to the grandmother so she knows it worked.

Gmail has spam filters, Thunderbird has spam filters. Did you know that 
Google recommends you turn off Thunderbird spam filters? I have no idea 
how (or if) Google knows that I think a message is spam. I can configure 
Thunderbird to auto-delete it or store it in a local or gmail spam 
folder. Only the latter might be how they figure it out.

-- 

Doug Royer - (K7DMR.us / DougRoyer.com)
DouglasRoyer@gmail.com
714-989-6135


From vesely@tana.it  Fri Jun 21 08:27:59 2013
Return-Path: <vesely@tana.it>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9650921F9AE1 for <apps-discuss@ietfa.amsl.com>; Fri, 21 Jun 2013 08:27:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.719
X-Spam-Level: 
X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1LeZu+ghjbU6 for <apps-discuss@ietfa.amsl.com>; Fri, 21 Jun 2013 08:27:55 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 1480221F9A77 for <apps-discuss@ietf.org>; Fri, 21 Jun 2013 08:27:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1371828473; bh=B43fvrh+SBFFh47kW+8v3XzTiecX6iNstItvA/ny54g=; l=1417; h=Date:From:To:References:In-Reply-To; b=v2Dpcdc7upC8iLMIKr4xLDU9IXSMKgLR87Tqran/52ccXR7AxFJRvHEeKTRIVt4nb SiLvLCxG2cCvIp4fjVG7s8PCF2GJZbTOtkJve7DQEqTuGd16zVCI2VWE/2eMGUgDw9 KLTn83WdNvxLdvcr/SJNB06OwCZdJ2cEKyYBTOxw=
Authentication-Results: tana.it; auth=pass (details omitted)
Received: from [172.25.197.98] (ubuntu.tana [172.25.197.98]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by wmail.tana.it with ESMTPSA; Fri, 21 Jun 2013 17:27:53 +0200 id 00000000005DC035.0000000051C470F9.00003D69
Message-ID: <51C470F9.7070806@tana.it>
Date: Fri, 21 Jun 2013 17:27:53 +0200
From: Alessandro Vesely <vesely@tana.it>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <20130620164453.61202.qmail@joyce.lan> <51C37E09.9070704@gmail.com>
In-Reply-To: <51C37E09.9070704@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [apps-discuss] e-mail / Security?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 21 Jun 2013 15:27:59 -0000

On Fri 21/Jun/2013 00:11:21 +0200 Doug Royer wrote:
> 
> I think that moving to cert based email submission will prevent the
> person that broke in to my hotmail account last week that hacked my
> obscure and complex password from submitting email as me - unless he
> also steals my cert. I knew it happened only after getting some nutty
> replies to email I never sent. If I would have had to supply an S/MIME
> message to be submitted, it would have not made it to a few hundred (or
> more) people.

I disagree, irrespectively of my inclination toward S/MIME.  You clearly
identified the failure point, although it is not clear what kind of
attack revealed your password.  Until that is fixed, you cannot know
whether adding yet another certificate or password would help.

> Gmail has spam filters, Thunderbird has spam filters. Did you know that
> Google recommends you turn off Thunderbird spam filters? I have no idea
> how (or if) Google knows that I think a message is spam. I can configure
> Thunderbird to auto-delete it or store it in a local or gmail spam
> folder. Only the latter might be how they figure it out.

Perhaps they think their filters are better.  IMHO, it would be good to
report messages that users classify as spam, independently of how such
classification was made.  That would contribute to determining mailbox
providers' reputation, and could cure false positives.

From tss@iki.fi  Fri Jun 21 08:57:19 2013
Return-Path: <tss@iki.fi>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E15C21F9F87 for <apps-discuss@ietfa.amsl.com>; Fri, 21 Jun 2013 08:57:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.447
X-Spam-Level: 
X-Spam-Status: No, score=-110.447 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HKPjLqdQ696U for <apps-discuss@ietfa.amsl.com>; Fri, 21 Jun 2013 08:57:14 -0700 (PDT)
Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id E957F21F9F70 for <apps-discuss@ietf.org>; Fri, 21 Jun 2013 08:57:12 -0700 (PDT)
Received: from [192.168.10.100] (cs181255018.pp.htv.fi [82.181.255.18]) by dovecot.org (Postfix) with ESMTP id 1B6291AE87B3; Fri, 21 Jun 2013 18:57:11 +0300 (EEST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Timo Sirainen <tss@iki.fi>
In-Reply-To: <alpine.LSU.2.00.1306201644430.9686@hermes-2.csi.cam.ac.uk>
Date: Fri, 21 Jun 2013 18:57:10 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <ADA45969-79AA-4AE8-ADE8-5B6E094B68FA@iki.fi>
References: <p06240800ccc189b2c3ff@[192.168.0.101]> <43892743-D4CD-4137-B3BD-BCA321D9CE41@dsv.su.se> <CDE93777-E0E9-4D9D-89F3-AFCEBE3D6E4B@iki.fi> <alpine.LSU.2.00.1306201644430.9686@hermes-2.csi.cam.ac.uk>
To: Tony Finch <dot@dotat.at>
X-Mailer: Apple Mail (2.1508)
Cc: General discussion of application-layer protocols <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Is e-mail going to die?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 21 Jun 2013 15:57:19 -0000

On 20.6.2013, at 18.45, Tony Finch <dot@dotat.at> wrote:

> Timo Sirainen <tss@iki.fi> wrote:
>>=20
>> But I do wonder how far people have thought about using hashcash. I
>> haven't really followed antispam efforts myself.. but I'd think a
>> hashcash and some crypto combination could be made to work, if enough
>> people show interest.
>=20
> Proof of work proves not to work:
> http://www.cl.cam.ac.uk/~rnc1/talks/040607-ProofWork.pdf

Not in 2004, but nowadays the work could be delegated to email clients =
(not email servers), such as GMail using Javascript to force users to =
calculate the necessary work. There is a LOT more CPU available to =
legitimate email clients than there are for botnets. Using crypto based =
"whitelists" (crypto signature token encoding a specific sender -> =
recipient) could avoid most of the hashcash calculations, and especially =
would avoid them completely for mailing lists (each user would provide =
the whitelist token when subscribing).

It wouldn't of course completely solve spam problem, but I think it =
could be used to significantly reduce it. But I guess spam isn't big =
enough of a problem to actually bother implementing this currently, and =
the cure is especially bad because as the pdf says: "warms up the planet =
:("


From johnl@iecc.com  Fri Jun 21 10:57:52 2013
Return-Path: <johnl@iecc.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5345721E812D for <apps-discuss@ietfa.amsl.com>; Fri, 21 Jun 2013 10:57:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.668
X-Spam-Level: 
X-Spam-Status: No, score=-110.668 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AO+bjeOgiQlV for <apps-discuss@ietfa.amsl.com>; Fri, 21 Jun 2013 10:57:48 -0700 (PDT)
Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id DA78A21F96EB for <apps-discuss@ietf.org>; Fri, 21 Jun 2013 10:57:47 -0700 (PDT)
Received: (qmail 12095 invoked from network); 21 Jun 2013 17:57:47 -0000
Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 21 Jun 2013 17:57:47 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=51c4941b.xn--i8sz2z.k1306; i=johnl@user.iecc.com; bh=Ubw7v/NAqE0wfD3hT5IBikEwd69bHKbejeVzUhKkP7I=; b=DIRDjHLP2ggyUXoLbLaNnJRf5Cw9s1K7a+9dUMAt3NlpHpYMl8DYAxIuy3+e7c7Fm2diG7PiF4AgAgoPiTU18LWtp3iuMpJWNHmL7mgiDrCSqlQDnjzWOR8+YfU04Ys0KsK1Tp+sVgePirVgVGMziZ8rkIGIiEGycSNexekLfnmIHHXlxvfDGiDiqRtzrQoYkxybRInhE0U7ty+TPQ78Q0gtiOtjg7c3kz5wT8JEOiPFSmZ50gJXsztXhfJ8gDXA
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=51c4941b.xn--i8sz2z.k1306; olt=johnl@user.iecc.com; bh=Ubw7v/NAqE0wfD3hT5IBikEwd69bHKbejeVzUhKkP7I=; b=TokucLyNG/t9m5UQdBQjhWxGDvV089FU54Bo3MD7VhruLRIMTav5YpghlF/jwjINV2pBQPNh8H+jwGe5Y8/WfyJLJ2yJvbrGwzNZTV8XXJHC+TNuRYSrwfs6BlMW7bHoIrZFrvW+BfwXBK4Gkb97K79zwqUAkHr1YVu3sbtSL3kpR9ExiGcctk6bkuWtTPvBqA/gua5qaUQqDXLl1I8nxH+1//ykQiWLvv3aFqyosm2wfWh+LXmvwpKhlxT1MRqi
Date: 21 Jun 2013 17:57:24 -0000
Message-ID: <20130621175724.93728.qmail@joyce.lan>
From: "John Levine" <johnl@taugh.com>
To: apps-discuss@ietf.org
In-Reply-To: <ADA45969-79AA-4AE8-ADE8-5B6E094B68FA@iki.fi>
Organization: 
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Subject: Re: [apps-discuss] Is e-mail going to die?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 21 Jun 2013 17:57:52 -0000

>It wouldn't of course completely solve spam problem, but I think it could be used to
>significantly reduce it. But I guess spam isn't big enough of a problem to actually bother
>implementing this currently, and the cure is especially bad because as the pdf says: "warms
>up the planet :("

This particular FUSSP has the "won't work unless everyone does it" and
the "millions of PCs in botnets" problems.

If people really want to rehash well known ineffective anti-spam techniques, I can give
you the info for the son-of-ASRG list.

R's,
John

From dhc@dcrocker.net  Fri Jun 21 11:05:40 2013
Return-Path: <dhc@dcrocker.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF4B711E81A3 for <apps-discuss@ietfa.amsl.com>; Fri, 21 Jun 2013 11:05:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.573
X-Spam-Level: 
X-Spam-Status: No, score=-6.573 tagged_above=-999 required=5 tests=[AWL=0.026,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xv1CgsRMYGq3 for <apps-discuss@ietfa.amsl.com>; Fri, 21 Jun 2013 11:05:36 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9C03421E812D for <apps-discuss@ietf.org>; Fri, 21 Jun 2013 11:05:34 -0700 (PDT)
Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r5LI5VrR016567 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <apps-discuss@ietf.org>; Fri, 21 Jun 2013 11:05:34 -0700
Message-ID: <51C495D8.4080203@dcrocker.net>
Date: Fri, 21 Jun 2013 11:05:12 -0700
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <20130621175724.93728.qmail@joyce.lan>
In-Reply-To: <20130621175724.93728.qmail@joyce.lan>
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]); Fri, 21 Jun 2013 11:05:34 -0700 (PDT)
Subject: Re: [apps-discuss] Is e-mail going to die?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: General discussion of application-layer protocols <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, 21 Jun 2013 18:05:40 -0000

On 6/21/2013 10:57 AM, John Levine wrote:
> If people really want to rehash well known ineffective anti-spam techniques, I can give
> you the info for the son-of-ASRG list.


Of course, less work, quicker result and a better summary is at:

    http://craphound.com/spamsolutions.txt

d/


-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

From tss@iki.fi  Fri Jun 21 11:33:22 2013
Return-Path: <tss@iki.fi>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCB6A21F9EEF for <apps-discuss@ietfa.amsl.com>; Fri, 21 Jun 2013 11:33:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.304
X-Spam-Level: 
X-Spam-Status: No, score=-110.304 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zkhs09YRJCKj for <apps-discuss@ietfa.amsl.com>; Fri, 21 Jun 2013 11:33:17 -0700 (PDT)
Received: from dovecot.org (dovecot.org [193.210.130.67]) by ietfa.amsl.com (Postfix) with ESMTP id E341021E8130 for <apps-discuss@ietf.org>; Fri, 21 Jun 2013 11:33:16 -0700 (PDT)
Received: from [192.168.10.100] (cs181255018.pp.htv.fi [82.181.255.18]) by dovecot.org (Postfix) with ESMTP id 2FFE31AE87B3 for <apps-discuss@ietf.org>; Fri, 21 Jun 2013 21:33:15 +0300 (EEST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Timo Sirainen <tss@iki.fi>
In-Reply-To: <20130621175724.93728.qmail@joyce.lan>
Date: Fri, 21 Jun 2013 21:33:14 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <77D18373-DD2C-4636-8CE1-E0C6CBB0F6CB@iki.fi>
References: <20130621175724.93728.qmail@joyce.lan>
To: apps-discuss@ietf.org
X-Mailer: Apple Mail (2.1508)
Subject: Re: [apps-discuss] Is e-mail going to die?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 21 Jun 2013 18:33:23 -0000

On 21.6.2013, at 20.57, John Levine <johnl@taugh.com> wrote:

>> It wouldn't of course completely solve spam problem, but I think it =
could be used to
>> significantly reduce it. But I guess spam isn't big enough of a =
problem to actually bother
>> implementing this currently, and the cure is especially bad because =
as the pdf says: "warms
>> up the planet :("
>=20
> This particular FUSSP has the "won't work unless everyone does it"

It could help even without everyone by using it as part of the spam =
score, but yeah, it definitely needs a few of the major ones =
implementing it to be worth the trouble. I wouldn't bother with it =
unless I got a large number of people to agree with it, which doesn't =
really look like it's happening. I think the core idea is still workable =
enough though.

> and the "millions of PCs in botnets" problems.

I still don't agree with this. There are at least 100x more legitimate =
email clients than spammers have servers, and most of the mails that =
legitimate senders send would be sent to known recipients or mailing =
lists which are whitelisted anyway, bringing the total amount of work =
required by spammers vs legitimate senders closer to 10000x.

Also I'm thinking that it's possible that email will evolve into =
something slightly different in future than how it's used now. It's =
about the only thing now where if you simply know one ID string you can =
send a message to anyone in the world, and everyone has at least one. =
Perhaps at some point it wouldn't be considered impossible that sending =
a mail to a new contact would take even hours, depending on the =
popularity of the recipient and how much effort the sender is willing to =
do to send the mail. Mainly it would be different than now, worse in =
many ways but also better in some ways, depending on what you want to =
use it for. For my email usage it wouldn't make much of a difference if =
it worked that way, and I send quite a lot of emails each day. But =
anyway, lets see again in 10 years :)


From superuser@gmail.com  Sun Jun 23 01:33:10 2013
Return-Path: <superuser@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70E7F21F9E02 for <apps-discuss@ietfa.amsl.com>; Sun, 23 Jun 2013 01:33:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1FpYoObkijPW for <apps-discuss@ietfa.amsl.com>; Sun, 23 Jun 2013 01:33:10 -0700 (PDT)
Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id B464321F9DAD for <apps-discuss@ietf.org>; Sun, 23 Jun 2013 01:33:09 -0700 (PDT)
Received: by mail-wg0-f49.google.com with SMTP id a12so7422687wgh.28 for <apps-discuss@ietf.org>; Sun, 23 Jun 2013 01:33:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6pWUXtpK+AbOkbX7XzsgfgHlUVJyF4+Q21jOWXAuOHw=; b=wCzUiFWHlsflbF/rzipRGlJRxJhp7kz2BuTmmS90Y3GpMmaKVhjvpi0/gS+cwdxNQK wnwWSq5sOfFahnRU/dtgdgD6TR5pEQqhi4NFa5KDMpE1D+zynXruxhPXIzd8pub0Vud9 IeV4kGgct9cMhXL2fR3dfksy4mRBD+y3YU+HD3OzScFw2+sPV6cjxOrZqM7phPJsg7T8 tpZi3Wm0uCw/Uozn2xXdflpbmyb6YWh12/TjopU8D2JqGdOPre3bELNH+E3frvqC3ctG 5IZ5Sdx2tA4Qu7L8KDBq3FLltGgXxjCzhPzEmkK7O5Lk40mRHiM3JOYhbq0iEfKmKwDP Nxeg==
MIME-Version: 1.0
X-Received: by 10.194.122.71 with SMTP id lq7mr8960148wjb.77.1371976388893; Sun, 23 Jun 2013 01:33:08 -0700 (PDT)
Received: by 10.180.90.16 with HTTP; Sun, 23 Jun 2013 01:33:08 -0700 (PDT)
In-Reply-To: <4C379D76-F395-4DF9-8AEF-0FF49801754D@peachymango.org>
References: <c0kjr8dihl1l14lt6q0gq83d8qkpj8lqki@hive.bjoern.hoehrmann.de> <WM!ace934e949a25580d74895b4bd60f953ef46b340dc5b400067e880e11a9d83096ec31aa0cebc2fc290ded499f08b47e2!@asav-1.01.com> <4C379D76-F395-4DF9-8AEF-0FF49801754D@peachymango.org>
Date: Sun, 23 Jun 2013 01:33:08 -0700
Message-ID: <CAL0qLwZsTfg6ytPk90NSV4W1+A-Gva1CPZ40wDcvi1YVa1a6KA@mail.gmail.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
To: Franck Martin <franck@peachymango.org>
Content-Type: multipart/alternative; boundary=089e012297504ce3ff04dfce2507
Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] comments on draft-ietf-appsawg-rfc5451bis-07
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 23 Jun 2013 08:33:10 -0000

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

On Sat, Jun 15, 2013 at 7:39 PM, Franck Martin <franck@peachymango.org>wrote:

> There is no specification for exposing the result of an SMTP TLS
> transaction, and the certificates used?
>
> What I have seen so far in the wild did not see particularly formatted nor
> useful and attached mainly with auth= which is one narrow use of SMTP TLS
> certificates.
>
>
There has not to date been any demand for adding that to the list of
supported mechanisms.   If you think it should be, it doesn't necessarily
need to be added here; rather, it could be added via the IANA registries
this document creates.

-MSK

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

<div dir=3D"ltr">On Sat, Jun 15, 2013 at 7:39 PM, Franck Martin <span dir=
=3D"ltr">&lt;<a href=3D"mailto:franck@peachymango.org" target=3D"_blank">fr=
anck@peachymango.org</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><d=
iv 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">There is no specification for exposing the r=
esult of an SMTP TLS transaction, and the certificates used?<br>
<br>
What I have seen so far in the wild did not see particularly formatted nor =
useful and attached mainly with auth=3D which is one narrow use of SMTP TLS=
 certificates.<br><br></blockquote><div><br></div><div>There has not to dat=
e been any demand for adding that to the list of supported mechanisms. =A0 =
If you think it should be, it doesn&#39;t necessarily need to be added here=
; rather, it could be added via the IANA registries this document creates.<=
br>
<br></div><div>-MSK<br></div></div></div></div>

--089e012297504ce3ff04dfce2507--

From franck@peachymango.org  Sun Jun 23 14:24:51 2013
Return-Path: <franck@peachymango.org>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C21821F9F6F for <apps-discuss@ietfa.amsl.com>; Sun, 23 Jun 2013 14:24:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.298
X-Spam-Level: 
X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0NV0zpuYW3Rn for <apps-discuss@ietfa.amsl.com>; Sun, 23 Jun 2013 14:24:45 -0700 (PDT)
Received: from smtp-out-2.01.com (smtp.01.com [199.36.142.181]) by ietfa.amsl.com (Postfix) with ESMTP id 6808821F9F68 for <apps-discuss@ietf.org>; Sun, 23 Jun 2013 14:24:45 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 77BAB39000C; Sun, 23 Jun 2013 16:24:42 -0500 (CDT)
X-Virus-Scanned: amavisd-new at smtp-out-2.01.com
Received: from smtp-out-2.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qpasvowmv0GL; Sun, 23 Jun 2013 16:24:42 -0500 (CDT)
Received: from smtp-out-2.01.com (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 52DC639002A; Sun, 23 Jun 2013 16:24:42 -0500 (CDT)
Received: from localhost (localhost [127.0.0.1]) by smtp-out-2.01.com (Postfix) with ESMTP id 3CDA6390012; Sun, 23 Jun 2013 16:24:42 -0500 (CDT)
X-Virus-Scanned: amavisd-new at smtp-out-2.01.com
Received: from smtp-out-2.01.com ([127.0.0.1]) by localhost (smtp-out-2.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id q6CkYCz-xLWo; Sun, 23 Jun 2013 16:24:42 -0500 (CDT)
Received: from mail-2.01.com (mail.01.com [172.18.30.178]) by smtp-out-2.01.com (Postfix) with ESMTP id 12F7639000C; Sun, 23 Jun 2013 16:24:42 -0500 (CDT)
Date: Sun, 23 Jun 2013 16:24:41 -0500 (CDT)
From: Franck Martin <franck@peachymango.org>
To: "Murray S. Kucherawy" <superuser@gmail.com>
Message-ID: <1585719489.4826.1372022681563.JavaMail.zimbra@peachymango.org>
In-Reply-To: <WM!c687cc98ae350a630795a4c171757acaf092db3368fe0581144b3bf20d72d7b7c0b4f4eae151d177df50e9e0e19ab618!@asav-2.01.com>
References: <c0kjr8dihl1l14lt6q0gq83d8qkpj8lqki@hive.bjoern.hoehrmann.de> <WM!ace934e949a25580d74895b4bd60f953ef46b340dc5b400067e880e11a9d83096ec31aa0cebc2fc290ded499f08b47e2!@asav-1.01.com> <4C379D76-F395-4DF9-8AEF-0FF49801754D@peachymango.org> <CAL0qLwZsTfg6ytPk90NSV4W1+A-Gva1CPZ40wDcvi1YVa1a6KA@mail.gmail.com> <WM!c687cc98ae350a630795a4c171757acaf092db3368fe0581144b3bf20d72d7b7c0b4f4eae151d177df50e9e0e19ab618!@asav-2.01.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_4825_107807130.1372022681562"
X-Originating-IP: [69.28.149.29]
X-Mailer: Zimbra 8.0.4_GA_5737 (ZimbraWebClient - FF21 (Mac)/8.0.4_GA_5737)
Thread-Topic: comments on draft-ietf-appsawg-rfc5451bis-07
Thread-Index: MRR9qjrmTdwKxgwhypA3te80u9YlzQ==
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] comments on draft-ietf-appsawg-rfc5451bis-07
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 23 Jun 2013 21:24:51 -0000

------=_Part_4825_107807130.1372022681562
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

----- Original Message -----

> From: "Murray S. Kucherawy" <superuser@gmail.com>
> To: "Franck Martin" <franck@peachymango.org>
> Cc: apps-discuss@ietf.org
> Sent: Sunday, June 23, 2013 1:33:08 AM
> Subject: Re: [apps-discuss] comments on draft-ietf-appsawg-rfc5451bis-07

> On Sat, Jun 15, 2013 at 7:39 PM, Franck Martin < franck@peachymango.org >
> wrote:

> > There is no specification for exposing the result of an SMTP TLS
> > transaction,
> > and the certificates used?
> 

> > What I have seen so far in the wild did not see particularly formatted nor
> > useful and attached mainly with auth= which is one narrow use of SMTP TLS
> > certificates.
> 

> There has not to date been any demand for adding that to the list of
> supported mechanisms. If you think it should be, it doesn't necessarily need
> to be added here; rather, it could be added via the IANA registries this
> document creates.

Fair enough, it is just I do not have enough experience on it, to recommend something, but it seems to me it was a weird use so far. So if anyone can pitch in, on how SMTP+TLS should be indicated in the AR header, that would be useful. 

------=_Part_4825_107807130.1372022681562
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><body><div style=3D"font-family: arial,helvetica,sans-serif; font-siz=
e: 12pt; color: #000000"><div><br></div><div><br></div><hr id=3D"zwchr"><bl=
ockquote style=3D"border-left:2px solid #1010FF;margin-left:5px;padding-lef=
t:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;=
font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>From: </b>"Murra=
y S. Kucherawy" &lt;superuser@gmail.com&gt;<br><b>To: </b>"Franck Martin" &=
lt;franck@peachymango.org&gt;<br><b>Cc: </b>apps-discuss@ietf.org<br><b>Sen=
t: </b>Sunday, June 23, 2013 1:33:08 AM<br><b>Subject: </b>Re: [apps-discus=
s] comments on draft-ietf-appsawg-rfc5451bis-07<br><div><br></div><div dir=
=3D"ltr">On Sat, Jun 15, 2013 at 7:39 PM, Franck Martin <span dir=3D"ltr">&=
lt;<a href=3D"mailto:franck@peachymango.org" target=3D"_blank">franck@peach=
ymango.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 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">There is no specification f=
or exposing the result of an SMTP TLS transaction, and the certificates use=
d?<br><br>
What I have seen so far in the wild did not see particularly formatted nor =
useful and attached mainly with auth=3D which is one narrow use of SMTP TLS=
 certificates.<br><div><br></div></blockquote><div><br></div><div>There has=
 not to date been any demand for adding that to the list of supported mecha=
nisms. &nbsp; If you think it should be, it doesn't necessarily need to be =
added here; rather, it could be added via the IANA registries this document=
 creates.<br><br></div></div></div></div></blockquote><div>Fair enough, it =
is just I do not have enough experience on it, to recommend something, but =
it seems to me it was a weird use so far. So if anyone can pitch in, on how=
 SMTP+TLS should be indicated in the AR header, that would be useful.<br></=
div></div></body></html>
------=_Part_4825_107807130.1372022681562--

From johnl@iecc.com  Mon Jun 24 20:39:20 2013
Return-Path: <johnl@iecc.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8717021F9D7F for <apps-discuss@ietfa.amsl.com>; Mon, 24 Jun 2013 20:39:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.833
X-Spam-Level: 
X-Spam-Status: No, score=-110.833 tagged_above=-999 required=5 tests=[AWL=0.366, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8yH+DhFzw6N for <apps-discuss@ietfa.amsl.com>; Mon, 24 Jun 2013 20:39:15 -0700 (PDT)
Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 131F921F9D7A for <apps-discuss@ietf.org>; Mon, 24 Jun 2013 20:39:09 -0700 (PDT)
Received: (qmail 66412 invoked from network); 25 Jun 2013 03:39:09 -0000
Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 25 Jun 2013 03:39:09 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:content-transfer-encoding; s=51c910dd.xn--3zv.k1306; i=johnl@user.iecc.com; bh=8HvM2xZCkIWn3FmLi6jEUD7LkXk4DSkRV/MBFK8ntTc=; b=FxWTuoS8KyOTWrZ4NFNDBamDsgtnHY/eututRSouqeeTqRZjgaH2UaYi5zUrA+X+ZdAZJyO125jyL+K/HZ1KEz/xJBmr+1UGmD5YsctHxRH7hmJu+qr100+rA0tAx6VKisiwOzZK4KXBqkMB6AhbRNl3c3tmJYg6bNXGO+9/SyJLA1OxAb1c92Un9he5sdCnS6RI2zWX19i5IvgHbaS8GVzcd0Zycth3VSUazUQVZBS36OCTi5cj1S64vh3wYlM4
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:mime-version:content-type:content-transfer-encoding; s=51c910dd.xn--3zv.k1306; olt=johnl@user.iecc.com; bh=8HvM2xZCkIWn3FmLi6jEUD7LkXk4DSkRV/MBFK8ntTc=; b=sWFlk8Kd/pO706AosLRNzQsfOmR07OpR19FhHWOKJiBTgxlHfFhSJSfH2JqyiRLWg2NzHU64CLT3GE50OAGSvLTUUUA9FoVP3p6D/037x+nhF8xavj4okY5vZS2yL6Zq4l//2VZig+bgqo/6mfExQRPsScVGQ6z62wig2ZGFJn5ZcPmwYbuAG8J08YtdCgYup1msiPxK7jwz1Lu4pheGJynputcURiljv3LZ3SE0TfTh5U+5kWYu73iNkQ0AHd0/
Date: 25 Jun 2013 03:38:46 -0000
Message-ID: <20130625033846.25553.qmail@joyce.lan>
From: "John Levine" <johnl@taugh.com>
To: apps-discuss@ietf.org
Organization: 
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Subject: [apps-discuss] Remember the MX 0 . draft?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 25 Jun 2013 03:39:20 -0000

The question came up on another list about how you can tell the world
that a domain handles no mail, and do it more efficiently than by
running a dummy SMTP server that rejects everything.  It's
particularly an issue when a domain has an A or AAAA record and no
SMTP server, so attempts to send mail take a week to time out before
they fail.

Everyone seems to agree that this is what you do:

  nomailhere.example. MX 0 .

but the only place that's documented is an expired I-D from 2005.

Since it is (as far as I can tell) useful and uncontroversial, would
it be worth reviving the I-D here, tidying it up, and sending it along
as a standards track RFC?

R's,
John



From mnot@mnot.net  Mon Jun 24 21:18:03 2013
Return-Path: <mnot@mnot.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A56421E8175 for <apps-discuss@ietfa.amsl.com>; Mon, 24 Jun 2013 21:18:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.3
X-Spam-Level: 
X-Spam-Status: No, score=-105.3 tagged_above=-999 required=5 tests=[AWL=-2.700, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PNwFm8cUwQd7 for <apps-discuss@ietfa.amsl.com>; Mon, 24 Jun 2013 21:17:58 -0700 (PDT)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 9FBD921F9CB7 for <apps-discuss@ietf.org>; Mon, 24 Jun 2013 21:17:54 -0700 (PDT)
Received: from [192.168.1.80] (unknown [118.209.171.15]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id CE8A9509B6; Tue, 25 Jun 2013 00:17:52 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <51B7AEAF.20404@berkeley.edu>
Date: Tue, 25 Jun 2013 14:17:59 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <4CD4652F-4EAF-4258-A6EB-577019018D2C@mnot.net>
References: <20130610033804.19451.29465.idtracker@ietfa.amsl.com> <E6062DBC-CD7B-47CA-A6F0-5E7D64C0DB55@mnot.net> <51B7AEAF.20404@berkeley.edu>
To: Erik Wilde <dret@berkeley.edu>
X-Mailer: Apple Mail (2.1508)
Cc: REST-Discuss <rest-discuss@yahoogroups.com>, IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] New Version Notification for draft-nottingham-link-hint-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 25 Jun 2013 04:18:03 -0000

Hi Erik,=20

Sorry for the delay - just back home now.

> but i have one question about the general registry model: the current =
draft says that hints MUST have a name (very reasonable, of course), but =
also that hints MUST have their data model being defined in JSON.
>=20
> http://tools.ietf.org/html/draft-nottingham-link-hint-00#section-5.1
>=20
> living in a world where we have JSON services, XML services, and RDF =
services, it seems that hard-coding a specific language data model into =
such a spec (without constraining it in any way) will limit the utility =
of such a registry.

It needs *a* data model.

> for example, in the Home Document draft, which is the original source =
of the link hint idea, the hints were hard-coded with very constrained =
data models. this made it relatively easy to expose them in a different =
syntax (in the XML Home Document draft):
>=20
> http://tools.ietf.org/html/draft-wilde-home-xml-01#page-4
>=20
> without getting too much into the details of this specific registry: =
what are the best practices about allowing/controlling language =
dependencies in registries?

Whoa, hold on - who said anything about a language? This is just the =
underlying data model; you can express it in a document however makes =
sense.

> personally, i would feel more comfortable with having a registry that =
is of equal value to people regardless of their implementation language

You're using "language" quite loosely here.=20

> , but then again that means that the registry itself must define a =
"mini-language" of its own.

-1. Defining Yet Another Data Model as a political solution to avoid =
picking an existing one is sub-optimal at best.

Cheers,


--
Mark Nottingham   http://www.mnot.net/




From dret@berkeley.edu  Mon Jun 24 21:49:13 2013
Return-Path: <dret@berkeley.edu>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1507721F9DDC for <apps-discuss@ietfa.amsl.com>; Mon, 24 Jun 2013 21:49:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G5GRL8IucQgI for <apps-discuss@ietfa.amsl.com>; Mon, 24 Jun 2013 21:49:06 -0700 (PDT)
Received: from cm03fe.IST.Berkeley.EDU (cm03fe.IST.Berkeley.EDU [169.229.218.144]) by ietfa.amsl.com (Postfix) with ESMTP id 9884721F9DC1 for <apps-discuss@ietf.org>; Mon, 24 Jun 2013 21:49:06 -0700 (PDT)
Received: from 99-38-249-227.lightspeed.sntcca.sbcglobal.net ([99.38.249.227] helo=[192.168.1.68]) by cm03fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from <dret@berkeley.edu>) id 1UrLBg-0000PJ-Cs; Mon, 24 Jun 2013 21:49:06 -0700
Message-ID: <51C92146.7000309@berkeley.edu>
Date: Mon, 24 Jun 2013 21:49:10 -0700
From: Erik Wilde <dret@berkeley.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: IETF Apps Discuss <apps-discuss@ietf.org>,  REST-Discuss <rest-discuss@yahoogroups.com>
References: <20130610033804.19451.29465.idtracker@ietfa.amsl.com> <E6062DBC-CD7B-47CA-A6F0-5E7D64C0DB55@mnot.net> <51B7AEAF.20404@berkeley.edu> <4CD4652F-4EAF-4258-A6EB-577019018D2C@mnot.net>
In-Reply-To: <4CD4652F-4EAF-4258-A6EB-577019018D2C@mnot.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Mark Nottingham <mnot@mnot.net>
Subject: Re: [apps-discuss] [rest-discuss] Re: New Version Notification for draft-nottingham-link-hint-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 25 Jun 2013 04:49:13 -0000

hello mark.

On 2013-06-24 21:17 , Mark Nottingham wrote:
>> but i have one question about the general registry model: the current draft says that hints MUST have a name (very reasonable, of course), but also that hints MUST have their data model being defined in JSON.
>> http://tools.ietf.org/html/draft-nottingham-link-hint-00#section-5.1
>> living in a world where we have JSON services, XML services, and RDF services, it seems that hard-coding a specific language data model into such a spec (without constraining it in any way) will limit the utility of such a registry.
> It needs *a* data model.

yes, that's definitely true. i think what i'm trying to figure out a 
first is whether there is any precedence of a registry requiring a JSON 
data model, or any other specific language for that matter, for a 
structured values. it seems it's mostly specific micro-syntaxes (if any 
structure beyond identifiers is required), but i am really wondering 
about what people have usually done in similar situations.

>> for example, in the Home Document draft, which is the original source of the link hint idea, the hints were hard-coded with very constrained data models. this made it relatively easy to expose them in a different syntax (in the XML Home Document draft):
>> http://tools.ietf.org/html/draft-wilde-home-xml-01#page-4
>> without getting too much into the details of this specific registry: what are the best practices about allowing/controlling language dependencies in registries?
> Whoa, hold on - who said anything about a language? This is just the underlying data model; you can express it in a document however makes sense.

that's kind of true, but not really. since the draft allows *any* kind 
of JSON, if i had a non-JSON document format (let's say XML ;-) that 
wanted to be able to represent registry values in general, it needs to 
define a generic mapping from *any* kind of JSON to XML. that's 
technically possible, but not really what works well for any non-JSON 
document model.

i think this is my main argument: if you have a micro-syntax for the 
registry, you can map that much easier to something that maps reasonably 
well into a variety of document models. if you require JSON, and allow 
arbitrary JSON, the JSON bias translates into rather inconvenient models 
for any non-JSON language.

>> personally, i would feel more comfortable with having a registry that is of equal value to people regardless of their implementation language
> You're using "language" quite loosely here.

maybe. and like i said above, apart from having implementation concerns 
about non-JSON formats, i am also really interested to learn about prior 
art: how was this problem approached/solved in other situations like this?

>> , but then again that means that the registry itself must define a "mini-language" of its own.
> -1. Defining Yet Another Data Model as a political solution to avoid picking an existing one is sub-optimal at best.

not sure. if JSON is #1 on the requirement list, then maybe define a 
well-defined subset of JSON, so that mappings into other languages don't 
need to be able to handle *any* JSON?

more specifically, what do the current hints actually need? it seems 
that the set of possibilities is actually rather small. for example, 
http://tools.ietf.org/html/draft-nottingham-link-hint-00#section-3.2 
says "Content MUST be an object, whose keys are media types, and values 
are objects", but what are the objects containing? maybe a simple array 
of media type strings would suffice? and then, if we can boil down the 
needs to "hints are strings or arrays of strings", then we can create 
good mappings for a variety of document models, and not just for JSON.

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 tobias.gondrom@gondrom.org  Tue Jun 25 01:29:33 2013
Return-Path: <tobias.gondrom@gondrom.org>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88E9F21E8086 for <apps-discuss@ietfa.amsl.com>; Tue, 25 Jun 2013 01:29:33 -0700 (PDT)
X-Quarantine-ID: <9YS4N9K1fiob>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char E2 hex): To: ....org, draft-ietf-pkix-est\342\200\213.all@tools.ie[...]
X-Spam-Flag: NO
X-Spam-Score: -95.061
X-Spam-Level: 
X-Spam-Status: No, score=-95.061 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9YS4N9K1fiob for <apps-discuss@ietfa.amsl.com>; Tue, 25 Jun 2013 01:29:29 -0700 (PDT)
Received: from lvps176-28-13-69.dedicated.hosteurope.de (lvps176-28-13-69.dedicated.hosteurope.de [176.28.13.69]) by ietfa.amsl.com (Postfix) with ESMTP id 1944F21F9E1E for <apps-discuss@ietf.org>; Tue, 25 Jun 2013 01:29:24 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1;  q=dns; c=nofws; s=default; d=gondrom.org; b=q37AnQ4Dl9d4cIFgqR/PS6ZX2AAzSLA3aDuZLiP6ImA7E8kN4Kdmqjy6Kgs4dVSjHoCqSnV7M0YnhuoKPqK2dF2/sUKyZT45DeEkOHKSRYPGh/HXQO7ZFHa28GehTRPM; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:X-Enigmail-Version:Content-Type;
Received: (qmail 19494 invoked from network); 25 Jun 2013 10:29:17 +0200
Received: from softdnserror (HELO ?183.199.6.81?) (183.199.6.81) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 25 Jun 2013 10:29:17 +0200
Message-ID: <51C954C5.4060401@gondrom.org>
Date: Tue, 25 Jun 2013 16:28:53 +0800
From: Tobias Gondrom <tobias.gondrom@gondrom.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6
MIME-Version: 1.0
To: apps-discuss@ietf.org, draft-ietf-pkix-est​.all@tools.ietf.org
X-Enigmail-Version: 1.5.1
Content-Type: multipart/alternative; boundary="------------010305010302060502040702"
Cc: iesg@ietf.org
Subject: [apps-discuss] AppsDir review of draft-ietf-pkix-est-07
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 25 Jun 2013 08:29:33 -0000

This is a multi-part message in MIME format.
--------------010305010302060502040702
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

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

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

Document: draft-ietf-pkix-est-07
Title: Enrollment over Secure Transport
Reviewer: Tobias Gondrom
Review Date: 25.6.2013

Summary: The draft looks fine.
It is heading for STD track and mostly describes Simple PKI over TLS
(and using the protected channel mechanisms for mutual authentication as
well (beyond simple confidentiality)).

comments:


1. section 2.2.2 and 2.2.3
( client verification.)
(Certificate-less TLS (e.g., with a shared credential distributed
out-of-band);
and HTTP-based with a username/password distributed out-of-band.)

make sure to avoid information leakage. E.g. in case of certificate-less
TLS, if cookies are used, make sure that are not transmitted over the
normal unprotected HTTP band.
(section 3.2.3 already specifies that "HTTP Basic and Digest
authentication MUST only be performed over TLS 1.1 [RFC4346] or later
versions." which is good.)



2. section 3.2.4:
when registering  "application/csrattrs" with IANA in section 6
I see you have no Magic number or file extension.
Is there a chance that this request might at some point be made without
direct HTTP and might want some of the two?



3. section 3.2.2:
as you want to offer to use HTTP POST and GET.
I am not so happy about the HTTP GET parts. How do you consider the risk
of information leakage with HTTP GET when you have e.g. labels?
e.g. in case of    "2. 
https://www.example.com/.well-known/est/arbitraryLabel1/cacerts"

Second you may consider to note URI length limitations in GET requests. 


nits:
page 32
s/to use the the secp384r1 elliptic curve/to use the secp384r1 elliptic
curve


Oh and you should clean up idnits:
 ** Downref: Normative reference to an Informational RFC: RFC 2986
  ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246)


Best regards, Tobias



--------------010305010302060502040702
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-text-html" lang="x-unicode"> <font face="Arial">I
        have been selected as the Applications Area Directorate reviewer
        for <br>
        this draft (for background on appsdir, please see ​ <br>
        <a class="moz-txt-link-freetext"
href="http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate">http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate</a>
        ).<br>
        <br>
        Please resolve these comments along with any other Last Call
        comments <br>
        you may receive. Please wait for direction from your document
        shepherd <br>
        or AD before posting a new version of the draft.<br>
        <br>
        Document: draft-ietf-pkix-est-07<br>
        Title: Enrollment over Secure Transport<br>
        Reviewer: Tobias Gondrom<br>
        Review Date: 25.6.2013<br>
        <br>
        Summary: The draft looks fine. <br>
        It is heading for STD track and mostly describes Simple PKI over
        TLS (and using the protected channel mechanisms for mutual
        authentication as well (beyond simple confidentiality)). <br>
        <br>
        comments: <br>
        <br>
        <br>
        1. section 2.2.2 and 2.2.3<br>
        ( client verification.)<br>
        (Certificate-less TLS (e.g., with a shared credential
        distributed out-of-band);<br>
        and HTTP-based with a username/password distributed
        out-of-band.)<br>
        <br>
        make sure to avoid information leakage. E.g. in case of
        certificate-less TLS, if cookies are used, make sure that are
        not transmitted over the normal unprotected HTTP band. <br>
        (section 3.2.3 already specifies that "HTTP Basic and Digest
        authentication MUST only be performed over TLS 1.1 [RFC4346] or
        later versions." which is good.)<br>
        <br>
        <br>
        <br>
        2. section 3.2.4: <br>
        when registering  "application/csrattrs" with IANA in section 6<br>
        I see you have no Magic number or file extension. <br>
        Is there a chance that this request might at some point be made
        without direct HTTP and might want some of the two? <br>
        <br>
        <br>
        <br>
        3. section 3.2.2: <br>
        as you want to offer to use HTTP POST and GET. <br>
        I am not so happy about the HTTP GET parts. How do you consider
        the risk of information leakage with HTTP GET when you have e.g.
        labels? <br>
        e.g. in case of    "2. 
        <a class="moz-txt-link-freetext" href="https://www.example.com/.well-known/est/arbitraryLabel1/cacerts">https://www.example.com/.well-known/est/arbitraryLabel1/cacerts</a>"<br>
        <br>
        Second you may consider to note URI length limitations in GET
        requests.  <br>
        <br>
        <br>
        nits: <br>
        page 32<br>
        s/to use the the secp384r1 elliptic curve/to use the secp384r1
        elliptic curve<br>
        <br>
        <br>
        Oh and you should clean up idnits: <br>
         ** Downref: Normative reference to an Informational RFC: RFC
        2986<br>
          ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC
        5246)<br>
        <br>
      </font><font face="Arial"><br>
        Best regards, Tobias<br>
        <br>
        <br>
      </font> </div>
  </body>
</html>

--------------010305010302060502040702--

From stephen.farrell@cs.tcd.ie  Tue Jun 25 02:37:19 2013
Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78D3F21F9D5A for <apps-discuss@ietfa.amsl.com>; Tue, 25 Jun 2013 02:37:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.901
X-Spam-Level: 
X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fuJugSpvMNL9 for <apps-discuss@ietfa.amsl.com>; Tue, 25 Jun 2013 02:37:09 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 4B15621F91AB for <apps-discuss@ietf.org>; Tue, 25 Jun 2013 02:37:09 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D57C5BE7C; Tue, 25 Jun 2013 10:36:45 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6vxJuSNq45oN; Tue, 25 Jun 2013 10:36:44 +0100 (IST)
Received: from [10.36.85.74] (unknown [95.83.248.215]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 31434BE7B; Tue, 25 Jun 2013 10:36:44 +0100 (IST)
References: <20130610033804.19451.29465.idtracker@ietfa.amsl.com> <E6062DBC-CD7B-47CA-A6F0-5E7D64C0DB55@mnot.net> <51B7AEAF.20404@berkeley.edu> <4CD4652F-4EAF-4258-A6EB-577019018D2C@mnot.net>
Mime-Version: 1.0 (1.0)
In-Reply-To: <4CD4652F-4EAF-4258-A6EB-577019018D2C@mnot.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <1A136C4D-4F0C-446F-B307-D53FB9A40622@cs.tcd.ie>
X-Mailer: iPhone Mail (10B329)
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Date: Tue, 25 Jun 2013 10:36:38 +0100
To: Mark Nottingham <mnot@mnot.net>
Cc: IETF Apps Discuss <apps-discuss@ietf.org>, REST-Discuss <rest-discuss@yahoogroups.com>
Subject: Re: [apps-discuss] New Version Notification for draft-nottingham-link-hint-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 25 Jun 2013 09:37:19 -0000

Just had a a quick peek at this since we've seen a case where stuff went wro=
ng because a registry contained structured data. Roughly: 1) can we have an e=
arly allocation to work with IEEE; 2) oops that bit there should've been a 1=
; 3) can we mark (1) as reserved and redo stuff?=20

I think it's a mistake to ask IANA to handle structured data of any sort and=
 this does that in spades.

As a question: what makes you think this wouldn't be very likely to result i=
n erroneous registrations? (Damaging the effectiveness of this registry but a=
lso possibly the IANA function, a bit)

S


On 25 Jun 2013, at 05:17, Mark Nottingham <mnot@mnot.net> wrote:

> Hi Erik,=20
>=20
> Sorry for the delay - just back home now.
>=20
>> but i have one question about the general registry model: the current dra=
ft says that hints MUST have a name (very reasonable, of course), but also t=
hat hints MUST have their data model being defined in JSON.
>>=20
>> http://tools.ietf.org/html/draft-nottingham-link-hint-00#section-5.1
>>=20
>> living in a world where we have JSON services, XML services, and RDF serv=
ices, it seems that hard-coding a specific language data model into such a s=
pec (without constraining it in any way) will limit the utility of such a re=
gistry.
>=20
> It needs *a* data model.
>=20
>> for example, in the Home Document draft, which is the original source of t=
he link hint idea, the hints were hard-coded with very constrained data mode=
ls. this made it relatively easy to expose them in a different syntax (in th=
e XML Home Document draft):
>>=20
>> http://tools.ietf.org/html/draft-wilde-home-xml-01#page-4
>>=20
>> without getting too much into the details of this specific registry: what=
 are the best practices about allowing/controlling language dependencies in r=
egistries?
>=20
> Whoa, hold on - who said anything about a language? This is just the under=
lying data model; you can express it in a document however makes sense.
>=20
>> personally, i would feel more comfortable with having a registry that is o=
f equal value to people regardless of their implementation language
>=20
> You're using "language" quite loosely here.=20
>=20
>> , but then again that means that the registry itself must define a "mini-=
language" of its own.
>=20
> -1. Defining Yet Another Data Model as a political solution to avoid picki=
ng an existing one is sub-optimal at best.
>=20
> Cheers,
>=20
>=20
> --
> Mark Nottingham   http://www.mnot.net/
>=20
>=20
>=20
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss

From mnot@mnot.net  Tue Jun 25 02:46:20 2013
Return-Path: <mnot@mnot.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10F8521F9F08 for <apps-discuss@ietfa.amsl.com>; Tue, 25 Jun 2013 02:46:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.833
X-Spam-Level: 
X-Spam-Status: No, score=-104.833 tagged_above=-999 required=5 tests=[AWL=-2.233, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KaM6z34O2iVv for <apps-discuss@ietfa.amsl.com>; Tue, 25 Jun 2013 02:46:15 -0700 (PDT)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 7B7A121F960D for <apps-discuss@ietf.org>; Tue, 25 Jun 2013 02:46:15 -0700 (PDT)
Received: from [192.168.1.80] (unknown [118.209.171.15]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 53CF2509B5; Tue, 25 Jun 2013 05:46:12 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <1A136C4D-4F0C-446F-B307-D53FB9A40622@cs.tcd.ie>
Date: Tue, 25 Jun 2013 19:46:10 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <8BE038EC-1580-4D27-ABBA-1890EEFD4853@mnot.net>
References: <20130610033804.19451.29465.idtracker@ietfa.amsl.com> <E6062DBC-CD7B-47CA-A6F0-5E7D64C0DB55@mnot.net> <51B7AEAF.20404@berkeley.edu> <4CD4652F-4EAF-4258-A6EB-577019018D2C@mnot.net> <1A136C4D-4F0C-446F-B307-D53FB9A40622@cs.tcd.ie>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
X-Mailer: Apple Mail (2.1508)
Cc: IETF Apps Discuss <apps-discuss@ietf.org>, REST-Discuss <rest-discuss@yahoogroups.com>
Subject: Re: [apps-discuss] New Version Notification for draft-nottingham-link-hint-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 25 Jun 2013 09:46:20 -0000

Please have a look at the draft; the level of detail in the =
registrations is "a number" or "a list" or (infrequently) "an object" -- =
roughly on par with saying that a field in a registry is "an integer," =
which is quite common in IANA-land.


On 25/06/2013, at 7:36 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> =
wrote:

> Just had a a quick peek at this since we've seen a case where stuff =
went wrong because a registry contained structured data. Roughly: 1) can =
we have an early allocation to work with IEEE; 2) oops that bit there =
should've been a 1; 3) can we mark (1) as reserved and redo stuff?=20
>=20
> I think it's a mistake to ask IANA to handle structured data of any =
sort and this does that in spades.
>=20
> As a question: what makes you think this wouldn't be very likely to =
result in erroneous registrations? (Damaging the effectiveness of this =
registry but also possibly the IANA function, a bit)
>=20
> S
>=20
>=20
> On 25 Jun 2013, at 05:17, Mark Nottingham <mnot@mnot.net> wrote:
>=20
>> Hi Erik,=20
>>=20
>> Sorry for the delay - just back home now.
>>=20
>>> but i have one question about the general registry model: the =
current draft says that hints MUST have a name (very reasonable, of =
course), but also that hints MUST have their data model being defined in =
JSON.
>>>=20
>>> http://tools.ietf.org/html/draft-nottingham-link-hint-00#section-5.1
>>>=20
>>> living in a world where we have JSON services, XML services, and RDF =
services, it seems that hard-coding a specific language data model into =
such a spec (without constraining it in any way) will limit the utility =
of such a registry.
>>=20
>> It needs *a* data model.
>>=20
>>> for example, in the Home Document draft, which is the original =
source of the link hint idea, the hints were hard-coded with very =
constrained data models. this made it relatively easy to expose them in =
a different syntax (in the XML Home Document draft):
>>>=20
>>> http://tools.ietf.org/html/draft-wilde-home-xml-01#page-4
>>>=20
>>> without getting too much into the details of this specific registry: =
what are the best practices about allowing/controlling language =
dependencies in registries?
>>=20
>> Whoa, hold on - who said anything about a language? This is just the =
underlying data model; you can express it in a document however makes =
sense.
>>=20
>>> personally, i would feel more comfortable with having a registry =
that is of equal value to people regardless of their implementation =
language
>>=20
>> You're using "language" quite loosely here.=20
>>=20
>>> , but then again that means that the registry itself must define a =
"mini-language" of its own.
>>=20
>> -1. Defining Yet Another Data Model as a political solution to avoid =
picking an existing one is sub-optimal at best.
>>=20
>> Cheers,
>>=20
>>=20
>> --
>> Mark Nottingham   http://www.mnot.net/
>>=20
>>=20
>>=20
>> _______________________________________________
>> apps-discuss mailing list
>> apps-discuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/apps-discuss

--
Mark Nottingham   http://www.mnot.net/




From stephen.farrell@cs.tcd.ie  Tue Jun 25 03:29:24 2013
Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 874B921F9ED0 for <apps-discuss@ietfa.amsl.com>; Tue, 25 Jun 2013 03:29:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tloKOUvNBiWX for <apps-discuss@ietfa.amsl.com>; Tue, 25 Jun 2013 03:29:20 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 389F011E80E0 for <apps-discuss@ietf.org>; Tue, 25 Jun 2013 03:29:20 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C47DDBE51; Tue, 25 Jun 2013 11:28:56 +0100 (IST)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RxLRW9WrxsBh; Tue, 25 Jun 2013 11:28:56 +0100 (IST)
Received: from [IPv6:2001:770:10:203:355a:797c:2a54:eb0b] (unknown [IPv6:2001:770:10:203:355a:797c:2a54:eb0b]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A1B58BE24; Tue, 25 Jun 2013 11:28:56 +0100 (IST)
Message-ID: <51C970E8.3090504@cs.tcd.ie>
Date: Tue, 25 Jun 2013 11:28:56 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6
MIME-Version: 1.0
To: Mark Nottingham <mnot@mnot.net>
References: <20130610033804.19451.29465.idtracker@ietfa.amsl.com> <E6062DBC-CD7B-47CA-A6F0-5E7D64C0DB55@mnot.net> <51B7AEAF.20404@berkeley.edu> <4CD4652F-4EAF-4258-A6EB-577019018D2C@mnot.net> <1A136C4D-4F0C-446F-B307-D53FB9A40622@cs.tcd.ie> <8BE038EC-1580-4D27-ABBA-1890EEFD4853@mnot.net>
In-Reply-To: <8BE038EC-1580-4D27-ABBA-1890EEFD4853@mnot.net>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: IETF Apps Discuss <apps-discuss@ietf.org>, REST-Discuss <rest-discuss@yahoogroups.com>
Subject: Re: [apps-discuss] New Version Notification for draft-nottingham-link-hint-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 25 Jun 2013 10:29:24 -0000

On 06/25/2013 10:46 AM, Mark Nottingham wrote:
> Please have a look at the draft; the level of detail in the registrations is "a number" or "a list" or (infrequently) "an object" -- roughly on par with saying that a field in a registry is "an integer," which is quite common in IANA-land.

Ah fair enough. (Serves me right for reading & replying via phone
from a bus:-)

I misread it as you wanting the registry to contain [ "foo": "bar" ]
but you just want the registry to contain "array". Given you'd need
to read the spec I'm not sure its that much use to have that in the
registry, but I agree its not harmful.

Sorry for the distraction,
S.

> 
> On 25/06/2013, at 7:36 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
> 
>> Just had a a quick peek at this since we've seen a case where stuff went wrong because a registry contained structured data. Roughly: 1) can we have an early allocation to work with IEEE; 2) oops that bit there should've been a 1; 3) can we mark (1) as reserved and redo stuff? 
>>
>> I think it's a mistake to ask IANA to handle structured data of any sort and this does that in spades.
>>
>> As a question: what makes you think this wouldn't be very likely to result in erroneous registrations? (Damaging the effectiveness of this registry but also possibly the IANA function, a bit)
>>
>> S
>>
>>
>> On 25 Jun 2013, at 05:17, Mark Nottingham <mnot@mnot.net> wrote:
>>
>>> Hi Erik, 
>>>
>>> Sorry for the delay - just back home now.
>>>
>>>> but i have one question about the general registry model: the current draft says that hints MUST have a name (very reasonable, of course), but also that hints MUST have their data model being defined in JSON.
>>>>
>>>> http://tools.ietf.org/html/draft-nottingham-link-hint-00#section-5.1
>>>>
>>>> living in a world where we have JSON services, XML services, and RDF services, it seems that hard-coding a specific language data model into such a spec (without constraining it in any way) will limit the utility of such a registry.
>>>
>>> It needs *a* data model.
>>>
>>>> for example, in the Home Document draft, which is the original source of the link hint idea, the hints were hard-coded with very constrained data models. this made it relatively easy to expose them in a different syntax (in the XML Home Document draft):
>>>>
>>>> http://tools.ietf.org/html/draft-wilde-home-xml-01#page-4
>>>>
>>>> without getting too much into the details of this specific registry: what are the best practices about allowing/controlling language dependencies in registries?
>>>
>>> Whoa, hold on - who said anything about a language? This is just the underlying data model; you can express it in a document however makes sense.
>>>
>>>> personally, i would feel more comfortable with having a registry that is of equal value to people regardless of their implementation language
>>>
>>> You're using "language" quite loosely here. 
>>>
>>>> , but then again that means that the registry itself must define a "mini-language" of its own.
>>>
>>> -1. Defining Yet Another Data Model as a political solution to avoid picking an existing one is sub-optimal at best.
>>>
>>> Cheers,
>>>
>>>
>>> --
>>> Mark Nottingham   http://www.mnot.net/
>>>
>>>
>>>
>>> _______________________________________________
>>> apps-discuss mailing list
>>> apps-discuss@ietf.org
>>> https://www.ietf.org/mailman/listinfo/apps-discuss
> 
> --
> Mark Nottingham   http://www.mnot.net/
> 
> 
> 

From barryleiba@gmail.com  Tue Jun 25 05:54:33 2013
Return-Path: <barryleiba@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B035A21F9EE6; Tue, 25 Jun 2013 05:54:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.018
X-Spam-Level: 
X-Spam-Status: No, score=-102.018 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kN30vjzBT5Wx; Tue, 25 Jun 2013 05:54:32 -0700 (PDT)
Received: from mail-qe0-x231.google.com (mail-qe0-x231.google.com [IPv6:2607:f8b0:400d:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id B201821F96D9; Tue, 25 Jun 2013 05:54:10 -0700 (PDT)
Received: by mail-qe0-f49.google.com with SMTP id cz11so556108qeb.36 for <multiple recipients>; Tue, 25 Jun 2013 05:54:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=utu2FjCjgjj6V32JKeyL8Yf8qrGntKscrGpJiJSTSgI=; b=fKLHa/5xrMol/8tkqUHbcdjhEiIWoX7EHmh9elWLTp3qskW2sGmYlf3uBIq7P/gnM2 +/aV+DiuNe1GEO+CbOvaM1KnEFjoHFQWAmLo3Hgk63W9Gx4Lcr4VPScyTQImu/aED4Wq RuAnA/ii3qzquaznfzvm/haLZKjumliCZE0+4F1t03FsRg/CtmJK5T44IiWKqwL9ogQu SFZpg9Y4cMktGqATdxWiMT/kqgxd2A05dKpoepK/YZQx+NBck+00TgMk+1cKJaefP8gz aSGyfLnlduC+PwB5RMZ6piktTHSSpmlwH//+/5PrqYswDJLRnw9147rODiBfNJkSZSoA Bj1Q==
MIME-Version: 1.0
X-Received: by 10.224.56.9 with SMTP id w9mr4904587qag.109.1372164850288; Tue, 25 Jun 2013 05:54:10 -0700 (PDT)
Sender: barryleiba@gmail.com
Received: by 10.224.0.139 with HTTP; Tue, 25 Jun 2013 05:54:10 -0700 (PDT)
In-Reply-To: <51C954C5.4060401@gondrom.org>
References: <51C954C5.4060401@gondrom.org>
Date: Tue, 25 Jun 2013 08:54:10 -0400
X-Google-Sender-Auth: Df27wMvL7xIZq9obyet-JLlAiTg
Message-ID: <CALaySJJ7uW_+LbhgqjVMxUyy9600KW_OjeeczLe+fW7Pdt5v-A@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
To: Tobias Gondrom <tobias.gondrom@gondrom.org>
Content-Type: text/plain; charset=ISO-8859-1
Cc: draft-ietf-pkix-est.all@tools.ietf.org, IESG <iesg@ietf.org>, Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] AppsDir review of draft-ietf-pkix-est-07
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 25 Jun 2013 12:54:34 -0000

Thanks for the appsdir review, Tobias.
Just a note on the last item:

> Oh and you should clean up idnits:
>  ** Downref: Normative reference to an Informational RFC: RFC 2986
>  ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246)

No, they're fine.  2986 is PKCS #10, and is in the downref registry:
http://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry

And 4346 is TLS 1.1, needed for the "HTTP Basic and Digest
authentication MUST only be performed over TLS 1.1 [RFC4346] or later
versions." that you mention earlier in the review.

Barry

From tobias.gondrom@gondrom.org  Tue Jun 25 07:00:55 2013
Return-Path: <tobias.gondrom@gondrom.org>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79DF621F9E98 for <apps-discuss@ietfa.amsl.com>; Tue, 25 Jun 2013 07:00:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -95.212
X-Spam-Level: 
X-Spam-Status: No, score=-95.212 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7aTSh1YKQdfv for <apps-discuss@ietfa.amsl.com>; Tue, 25 Jun 2013 07:00:51 -0700 (PDT)
Received: from lvps176-28-13-69.dedicated.hosteurope.de (lvps176-28-13-69.dedicated.hosteurope.de [176.28.13.69]) by ietfa.amsl.com (Postfix) with ESMTP id 73CA121F9ED2 for <apps-discuss@ietf.org>; Tue, 25 Jun 2013 07:00:50 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1;  q=dns; c=nofws; s=default; d=gondrom.org; b=C6xjGnD3eg4zjAk+r8PTr1snpYkZyBeu7Ca1X7i03yVuMTnixfERpUsqSsDlWOim1MTHbyzSKNQ9NBt8TMTuft/sdEzaG4o/41YA1zh+mZvPno81T9fl5uwyD4kcrtev; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding;
Received: (qmail 23670 invoked from network); 25 Jun 2013 16:00:49 +0200
Received: from softdnserror (HELO ?183.199.6.81?) (183.199.6.81) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 25 Jun 2013 16:00:48 +0200
Message-ID: <51C9A266.6090202@gondrom.org>
Date: Tue, 25 Jun 2013 22:00:06 +0800
From: Tobias Gondrom <tobias.gondrom@gondrom.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6
MIME-Version: 1.0
To: barryleiba@computer.org
References: <51C954C5.4060401@gondrom.org> <CALaySJJ7uW_+LbhgqjVMxUyy9600KW_OjeeczLe+fW7Pdt5v-A@mail.gmail.com>
In-Reply-To: <CALaySJJ7uW_+LbhgqjVMxUyy9600KW_OjeeczLe+fW7Pdt5v-A@mail.gmail.com>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: draft-ietf-pkix-est.all@tools.ietf.org, iesg@ietf.org, apps-discuss@ietf.org
Subject: Re: [apps-discuss] AppsDir review of draft-ietf-pkix-est-07
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 25 Jun 2013 14:00:55 -0000

Ah I see. Thanks for the clarification.
Best regards, Tobias
Ps.: my standard procedure is to include the idnits.
Maybe in the future shall also include the DownrefRegistry. ;-)


On 25/06/13 20:54, Barry Leiba wrote:
> Thanks for the appsdir review, Tobias.
> Just a note on the last item:
>
>> Oh and you should clean up idnits:
>>  ** Downref: Normative reference to an Informational RFC: RFC 2986
>>  ** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246)
> No, they're fine.  2986 is PKCS #10, and is in the downref registry:
> http://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry
>
> And 4346 is TLS 1.1, needed for the "HTTP Basic and Digest
> authentication MUST only be performed over TLS 1.1 [RFC4346] or later
> versions." that you mention earlier in the review.
>
> Barry


From superuser@gmail.com  Tue Jun 25 07:21:12 2013
Return-Path: <superuser@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A95FA21E80A8 for <apps-discuss@ietfa.amsl.com>; Tue, 25 Jun 2013 07:21:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kVKuhXYbYNiy for <apps-discuss@ietfa.amsl.com>; Tue, 25 Jun 2013 07:21:12 -0700 (PDT)
Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) by ietfa.amsl.com (Postfix) with ESMTP id BBD6021E80C8 for <apps-discuss@ietf.org>; Tue, 25 Jun 2013 07:21:07 -0700 (PDT)
Received: by mail-wi0-f182.google.com with SMTP id m6so809198wiv.15 for <apps-discuss@ietf.org>; Tue, 25 Jun 2013 07:21:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=aLkKOM2CcnzkXJw1w11GA3ilOdL7+WZFcX1puZ0vq1k=; b=AuJQHnb7h6eyPyc+jIV71XU4qNpfMe9sVPm9peJPegR+WuiNJxF45TVyo5ocmozZwt nquOEw8IVF345GWEIVXGGXQK66kp9YvhvRlXDeVosPY5bJcdlumH7Wko1T5UrNL4JL1e PY3aYGbf3+LsIUu1IxBe5COD5zQWgUi+tgwNv6JkeIdu5f5/M/wPtP8Lo5/3Ke1g2qOw 93i/8Xlbzpajw/4JZluVtxRmIEbmfezQShxOmrPMBrPRJugr43GmqNDVaCQUu1z80hvl ROzNKjaYsZgEAY2nF7dmjvKGj+uEy/3s9FWeIuzNujJTMpTJ4ZaYSQuz8rM2ZHvGm+CJ l9jg==
MIME-Version: 1.0
X-Received: by 10.180.187.209 with SMTP id fu17mr9346012wic.52.1372170066816;  Tue, 25 Jun 2013 07:21:06 -0700 (PDT)
Received: by 10.180.90.16 with HTTP; Tue, 25 Jun 2013 07:21:06 -0700 (PDT)
In-Reply-To: <20130625033846.25553.qmail@joyce.lan>
References: <20130625033846.25553.qmail@joyce.lan>
Date: Tue, 25 Jun 2013 07:21:06 -0700
Message-ID: <CAL0qLwaWkZfy9r2TUkptn5Y04Acc3C4_m3vCwZfmgsDa+Ozdmg@mail.gmail.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
To: John Levine <johnl@taugh.com>
Content-Type: multipart/alternative; boundary=001a11c269ac67763404dffb3d97
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Remember the MX 0 . draft?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 25 Jun 2013 14:21:12 -0000

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

On Mon, Jun 24, 2013 at 8:38 PM, John Levine <johnl@taugh.com> wrote:

> The question came up on another list about how you can tell the world
> that a domain handles no mail, and do it more efficiently than by
> running a dummy SMTP server that rejects everything.  It's
> particularly an issue when a domain has an A or AAAA record and no
> SMTP server, so attempts to send mail take a week to time out before
> they fail.
>
> Everyone seems to agree that this is what you do:
>
>   nomailhere.example. MX 0 .
>
> but the only place that's documented is an expired I-D from 2005.
>
> Since it is (as far as I can tell) useful and uncontroversial, would
> it be worth reviving the I-D here, tidying it up, and sending it along
> as a standards track RFC?
>
>
Never heard of this before.  Are there implementations?

-MSK

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

<div dir=3D"ltr">On Mon, Jun 24, 2013 at 8:38 PM, John Levine <span dir=3D"=
ltr">&lt;<a href=3D"mailto:johnl@taugh.com" target=3D"_blank">johnl@taugh.c=
om</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:1px #ccc solid;padding-left:1ex">
The question came up on another list about how you can tell the world<br>
that a domain handles no mail, and do it more efficiently than by<br>
running a dummy SMTP server that rejects everything. =A0It&#39;s<br>
particularly an issue when a domain has an A or AAAA record and no<br>
SMTP server, so attempts to send mail take a week to time out before<br>
they fail.<br>
<br>
Everyone seems to agree that this is what you do:<br>
<br>
=A0 nomailhere.example. MX 0 .<br>
<br>
but the only place that&#39;s documented is an expired I-D from 2005.<br>
<br>
Since it is (as far as I can tell) useful and uncontroversial, would<br>
it be worth reviving the I-D here, tidying it up, and sending it along<br>
as a standards track RFC?<br>
<br></blockquote><div><br></div><div>Never heard of this before.=A0 Are the=
re implementations?<br><br></div><div>-MSK <br></div></div><br></div></div>

--001a11c269ac67763404dffb3d97--

From dave@cridland.net  Tue Jun 25 08:07:45 2013
Return-Path: <dave@cridland.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BB1021F9D64 for <apps-discuss@ietfa.amsl.com>; Tue, 25 Jun 2013 08:07:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZN9n6plx+ZQ for <apps-discuss@ietfa.amsl.com>; Tue, 25 Jun 2013 08:07:45 -0700 (PDT)
Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id B81E021F9DB5 for <apps-discuss@ietf.org>; Tue, 25 Jun 2013 08:07:42 -0700 (PDT)
Received: by mail-ob0-f179.google.com with SMTP id xk17so12050780obc.24 for <apps-discuss@ietf.org>; Tue, 25 Jun 2013 08:07:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TUAxt0d2jAH5+WVVUAS/zZ9QxwMHAEXgYo7PAY8Or7w=; b=YfueOh9l6je+9DyZANME3XJFptUNLKkX3alP970kPfiYQXVxys00Q3BpU/fjsdqTHe IRfbQaKZec9cMGWfCn5FAtSozhzlpGE9rh1Lzl1DWUTXs18edhl2TCWfCRNHXkok19Lx BYGRumEd7OxyH4i8FPo+1XrmvzJkgxWY27WBY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=TUAxt0d2jAH5+WVVUAS/zZ9QxwMHAEXgYo7PAY8Or7w=; b=TQZD7Ug04j40wI7cqiFH8TzMX5ZdRabwYCYp/qJlxO9VtHfggQJlIPn9gimNS7mrbS IMhcW/oteA6nviJabHsxXtp71/calcREgwMNV49DLWkMmQ0HhcS5h1PHpQqtG7FRA7EF xmF6UHcOY5v3HgKzyrKFMfaWo+uP4sOvqzXm21zW1gorlpuyBKxHYSzlrgUXqBSUjsBe EUdRuKyFvlgkjAw8hRCWQY2TMVb06bWyMelb4uRhwogrQiUCkjEbLiAq0kBO8x0F6xdQ suT8SBxVKGannS1WxPqL5lHWmoBmFN4UQh/s8f+6vi8FxiRKiSMRBtF4DB1twmIl2Zxe HxiA==
MIME-Version: 1.0
X-Received: by 10.60.92.163 with SMTP id cn3mr13045746oeb.107.1372172862290; Tue, 25 Jun 2013 08:07:42 -0700 (PDT)
Received: by 10.60.139.212 with HTTP; Tue, 25 Jun 2013 08:07:42 -0700 (PDT)
Received: by 10.60.139.212 with HTTP; Tue, 25 Jun 2013 08:07:42 -0700 (PDT)
In-Reply-To: <CAL0qLwaWkZfy9r2TUkptn5Y04Acc3C4_m3vCwZfmgsDa+Ozdmg@mail.gmail.com>
References: <20130625033846.25553.qmail@joyce.lan> <CAL0qLwaWkZfy9r2TUkptn5Y04Acc3C4_m3vCwZfmgsDa+Ozdmg@mail.gmail.com>
Date: Tue, 25 Jun 2013 16:07:42 +0100
Message-ID: <CAKHUCzwSTyk=NeS1h18B0VkrA=oSzzx-CHesWok7rUZrDbijEQ@mail.gmail.com>
From: Dave Cridland <dave@cridland.net>
To: Murray Kucherawy <superuser@gmail.com>
Content-Type: multipart/alternative; boundary=047d7b33d41207131304dffbe4a2
X-Gm-Message-State: ALoCoQltqAvUijp/Vyh8R/6KpjVFARTPkIxC8B0V4anVu/q1UIjnZoTAjQ2cU+A0v2D30fz+Ei+r
Cc: John Levine <johnl@taugh.com>, apps-discuss@ietf.org
Subject: Re: [apps-discuss] Remember the MX 0 . draft?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 25 Jun 2013 15:07:45 -0000

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

On 25 Jun 2013 15:21, "Murray S. Kucherawy" <superuser@gmail.com> wrote:
> Never heard of this before.  Are there implementations?

It's a direct mirror of the technique documented for SRV records, which is
certainly deployed. As such, this seems reasonable to formalize for MX.

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

<p dir=3D"ltr"><br>
On 25 Jun 2013 15:21, &quot;Murray S. Kucherawy&quot; &lt;<a href=3D"mailto=
:superuser@gmail.com">superuser@gmail.com</a>&gt; wrote:<br>
&gt; Never heard of this before.=A0 Are there implementations?</p>
<p dir=3D"ltr">It&#39;s a direct mirror of the technique documented for SRV=
 records, which is certainly deployed. As such, this seems reasonable to fo=
rmalize for MX.</p>

--047d7b33d41207131304dffbe4a2--

From johnl@iecc.com  Tue Jun 25 08:53:45 2013
Return-Path: <johnl@iecc.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86B8011E810D for <apps-discuss@ietfa.amsl.com>; Tue, 25 Jun 2013 08:53:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.6
X-Spam-Level: 
X-Spam-Status: No, score=-108.6 tagged_above=-999 required=5 tests=[HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F3crhguDEqqa for <apps-discuss@ietfa.amsl.com>; Tue, 25 Jun 2013 08:53:39 -0700 (PDT)
Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 53A8611E80F5 for <apps-discuss@ietf.org>; Tue, 25 Jun 2013 08:53:33 -0700 (PDT)
Received: (qmail 22416 invoked from network); 25 Jun 2013 15:53:32 -0000
Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 25 Jun 2013 15:53:32 -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=51c9bcfc.xn--yuvv84g.k1306; i=johnl@user.iecc.com; bh=mAsOb3GXErUfIrG3rFbUbTsodDHHws+DP1ptCbthelg=; b=em1t06e95nZetXW/rI6B6PBDAREoOqbrKu3SEWm498zCLHHJD+SBl4/oUpToMpWRPgxdYfEfWqmSFxDvqa2iTOrik+V/z50wDLD6L3kyG0UvXvXVSHoL2OmDeZqxzeMZeqiRApBHq4XYUHRWYm8ErP8jUGsEOsywuyFlBiEK+zUdCB6CPBb3RFq6CIaG+BIqb24PCfju1KMCM50N3Ibf8OwTt8/850hiY7UxASNz6TRSq8yUm1QwQpV/4yAgOiBT
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=51c9bcfc.xn--yuvv84g.k1306; olt=johnl@user.iecc.com; bh=mAsOb3GXErUfIrG3rFbUbTsodDHHws+DP1ptCbthelg=; b=Z0EH+7wh5kNE31vvMU124UB4mWH7c7Kg4aBA7CG7WM5RFVDLODK2LjkrMuayJQGWTnW+ErnxtswKglS7eg6LuHZQ+ltCT9cRbYfwci2OIWCh88comVjSovDdSmk57tWu/E4XFR+b23nf0LJnXnfZzJi+ZypRGrqLwlJmApPMe4k3JAOMCeiPWVoM/EHBaEoCXQnKLh11ktMVfw7cuBIDwoVgDYRwLYwi2fveXAc/1a8IR+J+gExfrLrKZX3K0BkY
Date: 25 Jun 2013 15:53:09 -0000
Message-ID: <20130625155309.32246.qmail@joyce.lan>
From: "John Levine" <johnl@taugh.com>
To: apps-discuss@ietf.org
In-Reply-To: <CAL0qLwaWkZfy9r2TUkptn5Y04Acc3C4_m3vCwZfmgsDa+Ozdmg@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] Remember the MX 0 . draft?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 25 Jun 2013 15:53:47 -0000

>>   nomailhere.example. MX 0 .

>Never heard of this before.  Are there implementations?

Here's the draft, by Mark Delany of domainkeys fame:

http://tools.ietf.org/html/draft-delany-nullmx-00

It is my impression that a fair number of MTAs do implement it but I
haven't collected any statistics.

R's,
John

From alexey.melnikov@isode.com  Tue Jun 25 09:11:38 2013
Return-Path: <alexey.melnikov@isode.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD12E11E8110; Tue, 25 Jun 2013 09:11:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100
X-Spam-Level: 
X-Spam-Status: No, score=-100 tagged_above=-999 required=5 tests=[USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Izu3Xa6omCLQ; Tue, 25 Jun 2013 09:11:38 -0700 (PDT)
Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id B38DD11E810F; Tue, 25 Jun 2013 09:11:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1372176694; d=isode.com; s=selector; i=@isode.com; bh=SA1DLLratxHGCBtsu3NUTVo3TIpsFtz5RKJ+G8ecE/c=; 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=f3QhWfhVwoo79X9zNyD9gahK8Sj5SpZ20++f16kHDABZ/R8UUt37Sa8G+/PgLE5+KNhRzi vk/091vForx6WLmIRtYDYUsbqDpzszdExdvj8DRoRk63ZcmWkzDg++dd4tijcW7dtz8chQ 6rv3KyQOuebAG2b6Q1+/6VnDMaqzFLo=;
Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250])  by waldorf.isode.com (submission channel) via TCP with ESMTPA  id <UcnBNQBjMy7O@waldorf.isode.com>; Tue, 25 Jun 2013 17:11:34 +0100
Message-ID: <51C9C15C.9070405@isode.com>
Date: Tue, 25 Jun 2013 17:12:12 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
To: 'IETF Apps Discuss' <apps-discuss@ietf.org>, draft-ietf-abfab-eapapplicability.all@tools.ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: 'The IESG' <iesg@ietf.org>
Subject: [apps-discuss] AppsDir review of draft-ietf-abfab-eapapplicability-03
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 25 Jun 2013 16:11:38 -0000

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

Please resolve these comments along with any other Last Call comments 
you may receive.

Please wait for direction from your document shepherd or AD before 
posting a new version of the draft.

Document: draft-ietf-abfab-eapapplicability-03
Update to the EAP Applicability Statement for ABFAB
Reviewer: Alexey Melnikov

Review Date: June 25, 2013

IETF Last Call Date: June 17 2013

IESG Telechat Date: N/A

Summary:

This draft is ready for publication as a Standards Track document.

Major Issues: None
Minor Issues: None
Nits:

I think it would be a good idea to expand acronym MSK on first use. Be 
nice to novice readers.

SMTP and HTTP need Informative references.



From phluid61@gmail.com  Mon Jun 24 20:34:09 2013
Return-Path: <phluid61@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26F4421F9C1F for <apps-discuss@ietfa.amsl.com>; Mon, 24 Jun 2013 20:34:09 -0700 (PDT)
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=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zrSD3X+wzv+m for <apps-discuss@ietfa.amsl.com>; Mon, 24 Jun 2013 20:34:08 -0700 (PDT)
Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 3425821F9CC5 for <apps-discuss@ietf.org>; Mon, 24 Jun 2013 20:34:05 -0700 (PDT)
Received: by mail-lb0-f174.google.com with SMTP id x10so713874lbi.5 for <apps-discuss@ietf.org>; Mon, 24 Jun 2013 20:34:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=u/GrlRxIBispDVr0HZO1BqCRK8fehKKlUhk47trBpHg=; b=ln0WxWkBNyIjbxEVaCBGlDqXNM60WJ5/kigMzkRJrxaEZUU5vIGfY8YlXpmA6GXvMf Dp9KD4L3czP5mUC2u5j818szNY5n0nMOLmhf+OieQIxxtORE7DB2JcWoHIt39nCqsEFV +IVR8F//xSwpPqbegxABW8T76ZEHvPDpxHAIa1boB6TLKuNyOCD7bIfhQvqT5baGBnBB kPOj1B57RBMLuPFyM5TuMkSkmJHTQ3dkBurVDutXdi9XQnCpB/Obg+GN67Nx6W1QeK39 0cPFr9m7ehYcDHV/4d6JpvFQyBOXmz/UUUsHqg5vYanwAYXvdkl60VJOdyP1dfHNy7c2 Lisw==
MIME-Version: 1.0
X-Received: by 10.152.22.42 with SMTP id a10mr12923358laf.30.1372131242463; Mon, 24 Jun 2013 20:34:02 -0700 (PDT)
Sender: phluid61@gmail.com
Received: by 10.114.200.103 with HTTP; Mon, 24 Jun 2013 20:34:02 -0700 (PDT)
Date: Tue, 25 Jun 2013 13:34:02 +1000
X-Google-Sender-Auth: e5K8fbpkJKgiR22Ox3IouI2Xe_U
Message-ID: <CACweHNCTSZ3xvZPLeahZmJVg6pYheqvPfGxa_GPc1O9Aomi9hw@mail.gmail.com>
From: Matthew Kerwin <matthew@kerwin.net.au>
To: apps-discuss@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
X-Mailman-Approved-At: Tue, 25 Jun 2013 09:28:13 -0700
Subject: [apps-discuss] File URI Scheme
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 25 Jun 2013 03:34:51 -0000

Hi, it recently came up in a discussion on the ruby core developers'
mailing list <https://bugs.ruby-lang.org/issues/8544> that there is
currently no living standard defining the file: URI scheme.  Somewhat
bullheadedly I created my own I-D, based on RFC 1738 and an expired
draft by Paul Hoffman; however it occurs to me that this should
probably be under the purview of the Apps Area Working Group.

Would you please consider creating a draft for the file: URI scheme
(or taking over my existing draft); or if not, point me to some
resources or discussions about why the file scheme seems to have gone
out of vogue?

The current revision of my draft is
<http://tools.ietf.org/html/draft-kerwin-file-scheme-03> , and the
working copy is on github
<https://github.com/phluid61/file-uri-scheme>

Cheers
-- 
  Matthew Kerwin, B.Sc (CompSci) (Hons)
  http://matthew.kerwin.net.au/

From dret@berkeley.edu  Tue Jun 25 09:45:21 2013
Return-Path: <dret@berkeley.edu>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 931B621E80B1 for <apps-discuss@ietfa.amsl.com>; Tue, 25 Jun 2013 09:45:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4
X-Spam-Level: 
X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Encq8y8-Pd+b for <apps-discuss@ietfa.amsl.com>; Tue, 25 Jun 2013 09:45:17 -0700 (PDT)
Received: from cm06fe.IST.Berkeley.EDU (cm06fe.IST.Berkeley.EDU [169.229.218.147]) by ietfa.amsl.com (Postfix) with ESMTP id 1695421E8093 for <apps-discuss@ietf.org>; Tue, 25 Jun 2013 09:45:17 -0700 (PDT)
Received: from mobile-166-137-186-253.mycingular.net ([166.137.186.253] helo=dretair.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 1UrWMe-0004XU-Lp; Tue, 25 Jun 2013 09:45:10 -0700
Message-ID: <51C9C91D.90206@berkeley.edu>
Date: Tue, 25 Jun 2013 09:45:17 -0700
From: Erik Wilde <dret@berkeley.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Mark Nottingham <mnot@mnot.net>
References: <20130610033804.19451.29465.idtracker@ietfa.amsl.com> <E6062DBC-CD7B-47CA-A6F0-5E7D64C0DB55@mnot.net> <51B7AEAF.20404@berkeley.edu> <4CD4652F-4EAF-4258-A6EB-577019018D2C@mnot.net> <1A136C4D-4F0C-446F-B307-D53FB9A40622@cs.tcd.ie> <8BE038EC-1580-4D27-ABBA-1890EEFD4853@mnot.net>
In-Reply-To: <8BE038EC-1580-4D27-ABBA-1890EEFD4853@mnot.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: IETF Apps Discuss <apps-discuss@ietf.org>, REST-Discuss <rest-discuss@yahoogroups.com>
Subject: Re: [apps-discuss] New Version Notification for draft-nottingham-link-hint-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 25 Jun 2013 16:45:21 -0000

hello mark.

On 2013-06-25 02:46 , Mark Nottingham wrote:
> Please have a look at the draft; the level of detail in the registrations is "a number" or "a list" or (infrequently) "an object" -- roughly on par with saying that a field in a registry is "an integer," which is quite common in IANA-land.
> On 25/06/2013, at 7:36 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
>> As a question: what makes you think this wouldn't be very likely to result in erroneous registrations? (Damaging the effectiveness of this registry but also possibly the IANA function, a bit)

i really like the places where it says "a number" and "a list", because 
these concepts can be easily mapped into pretty much any representation. 
when it says "an object", however, that's an entirely different matter. 
it would be great for the registry to really be clear about what kind of 
structures to expect for hints (single values, value lists, and maybe 
lists of key/value pairs or something along those lines), and then the 
registry would not depend on a specific language.

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 paul.hoffman@vpnc.org  Tue Jun 25 09:54:20 2013
Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37B4621E8093 for <apps-discuss@ietfa.amsl.com>; Tue, 25 Jun 2013 09:54:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100
X-Spam-Level: 
X-Spam-Status: No, score=-100 tagged_above=-999 required=5 tests=[USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KSipwnSW1HoG for <apps-discuss@ietfa.amsl.com>; Tue, 25 Jun 2013 09:54:18 -0700 (PDT)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA2C11E810F for <apps-discuss@ietf.org>; Tue, 25 Jun 2013 09:54:15 -0700 (PDT)
Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r5PGsBNS029724 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 25 Jun 2013 09:54:12 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <CACweHNCTSZ3xvZPLeahZmJVg6pYheqvPfGxa_GPc1O9Aomi9hw@mail.gmail.com>
Date: Tue, 25 Jun 2013 09:54:11 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <91D2381C-E93F-41E0-B4BB-4928BE227678@vpnc.org>
References: <CACweHNCTSZ3xvZPLeahZmJVg6pYheqvPfGxa_GPc1O9Aomi9hw@mail.gmail.com>
To: Matthew Kerwin <matthew@kerwin.net.au>
X-Mailer: Apple Mail (2.1508)
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] File URI Scheme
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 25 Jun 2013 16:54:20 -0000

On Jun 24, 2013, at 8:34 PM, Matthew Kerwin <matthew@kerwin.net.au> =
wrote:

> Hi, it recently came up in a discussion on the ruby core developers'
> mailing list <https://bugs.ruby-lang.org/issues/8544> that there is
> currently no living standard defining the file: URI scheme.  Somewhat
> bullheadedly I created my own I-D, based on RFC 1738 and an expired
> draft by Paul Hoffman

...without asking me. :-) If you had, I would have warned you of the =
futility of such an effort. There is no general agreement on how this =
URI scheme should work, and different implementations act wildly =
different. The reason I dropped the effort was not lack of interest: it =
was too much interest from people who knew the one true way.

Having said that, maybe your enthusiasm will trump my cynicism. If so, =
the Internet will be a more interoperable place.

> ; however it occurs to me that this should
> probably be under the purview of the Apps Area Working Group.

No opinion.

> Would you please consider creating a draft for the file: URI scheme
> (or taking over my existing draft); or if not, point me to some
> resources or discussions about why the file scheme seems to have gone
> out of vogue?

It is *not* out of vogue: it is still widely employed in many areas.

--Paul Hoffman


From superuser@gmail.com  Tue Jun 25 11:25:06 2013
Return-Path: <superuser@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0867421E80D0 for <apps-discuss@ietfa.amsl.com>; Tue, 25 Jun 2013 11:25:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ZHtzqvYdYdG for <apps-discuss@ietfa.amsl.com>; Tue, 25 Jun 2013 11:25:02 -0700 (PDT)
Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id A568321F99D0 for <apps-discuss@ietf.org>; Tue, 25 Jun 2013 11:24:33 -0700 (PDT)
Received: by mail-wg0-f44.google.com with SMTP id m15so9492116wgh.11 for <apps-discuss@ietf.org>; Tue, 25 Jun 2013 11:24:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jOJjlYWOdzK2U2QcTxOkI364yYWiq3b/sLmyEvdKGYo=; b=adyqKFpj4wUb+gTMudXpNrZ8D1OHAeqIYilk1wH8uHlCiYc1LzvQQxp0o8EaGsGk4R pnLgqcf1YVVGDhq42nmVeudz+lpK32AqaIfNm4NoH/koZdxkMIjKgp2P32wYYpxKOjWV I2ldjRcie5xhCFJNC6gzB/k/L92ERFHnpUjPlhdapFED23awKNEAWOYNclT3fK25zvSB exT64dghFlDnrZ0R81cbt/RUb9JShghadOZLtESOXMtBXP4sX48pyqsIMzO+NL8kxC+E Ux1Vev6GqQ2neYFSaj6nuNcHC+4fnNcKQhqjy8EGiteU617vaKV1H7OCSNNqZLy37an5 dIog==
MIME-Version: 1.0
X-Received: by 10.194.122.71 with SMTP id lq7mr138294wjb.77.1372184663775; Tue, 25 Jun 2013 11:24:23 -0700 (PDT)
Received: by 10.180.90.16 with HTTP; Tue, 25 Jun 2013 11:24:23 -0700 (PDT)
In-Reply-To: <CACweHNCTSZ3xvZPLeahZmJVg6pYheqvPfGxa_GPc1O9Aomi9hw@mail.gmail.com>
References: <CACweHNCTSZ3xvZPLeahZmJVg6pYheqvPfGxa_GPc1O9Aomi9hw@mail.gmail.com>
Date: Tue, 25 Jun 2013 11:24:23 -0700
Message-ID: <CAL0qLwYNx17z42_pNucbPGY9ZvMx9yV9hnD74Nfhje_Rx9rcaw@mail.gmail.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
To: Matthew Kerwin <matthew@kerwin.net.au>
Content-Type: multipart/alternative; boundary=089e01229750735ef304dffea3a6
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] File URI Scheme
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 25 Jun 2013 18:25:06 -0000

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

On Mon, Jun 24, 2013 at 8:34 PM, Matthew Kerwin <matthew@kerwin.net.au>wrote:

> Would you please consider creating a draft for the file: URI scheme
> (or taking over my existing draft); or if not, point me to some
> resources or discussions about why the file scheme seems to have gone
> out of vogue?
>
> The current revision of my draft is
> <http://tools.ietf.org/html/draft-kerwin-file-scheme-03> , and the
> working copy is on github
> <https://github.com/phluid61/file-uri-scheme>
>
>
>
By "creating a draft", are you asking APPSAWG to adopt yours, or are you
asking us to come up with something else and process that?

-MSK, APPSAWG co-chair

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

<div dir=3D"ltr">On Mon, Jun 24, 2013 at 8:34 PM, Matthew Kerwin <span dir=
=3D"ltr">&lt;<a href=3D"mailto:matthew@kerwin.net.au" target=3D"_blank">mat=
thew@kerwin.net.au</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">Would you please consider creating a draft f=
or the file: URI scheme<br>
(or taking over my existing draft); or if not, point me to some<br>
resources or discussions about why the file scheme seems to have gone<br>
out of vogue?<br>
<br>
The current revision of my draft is<br>
&lt;<a href=3D"http://tools.ietf.org/html/draft-kerwin-file-scheme-03" targ=
et=3D"_blank">http://tools.ietf.org/html/draft-kerwin-file-scheme-03</a>&gt=
; , and the<br>
working copy is on github<br>
&lt;<a href=3D"https://github.com/phluid61/file-uri-scheme" target=3D"_blan=
k">https://github.com/phluid61/file-uri-scheme</a>&gt;<br>
<br><br></blockquote><div><br></div><div>By &quot;creating a draft&quot;, a=
re you asking APPSAWG to adopt yours, or are you asking us to come up with =
something else and process that?<br><br></div><div>-MSK, APPSAWG co-chair<b=
r>
=A0<br></div></div><br></div></div>

--089e01229750735ef304dffea3a6--

From johnl@iecc.com  Tue Jun 25 13:43:10 2013
Return-Path: <johnl@iecc.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4E5111E814D for <apps-discuss@ietfa.amsl.com>; Tue, 25 Jun 2013 13:43:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.766
X-Spam-Level: 
X-Spam-Status: No, score=-110.766 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DIWW+EtBjYUl for <apps-discuss@ietfa.amsl.com>; Tue, 25 Jun 2013 13:43:06 -0700 (PDT)
Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 8290211E814B for <apps-discuss@ietf.org>; Tue, 25 Jun 2013 13:43:02 -0700 (PDT)
Received: (qmail 92732 invoked from network); 25 Jun 2013 20:43:01 -0000
Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 25 Jun 2013 20:43:01 -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=51ca00d5.xn--30v786c.k1306; i=johnl@user.iecc.com; bh=eQo2Yb96cL7kEziLDdu1d3VacZH0nkpMSwvANOafBUQ=; b=JypnBFMf+hsPtcvoOkg0CICtAoYeGyUjeib4BnHdI7+Iz1LE3tJ0RxhFmZgklx6j3aRUFJ5t+0niIe0ixUsLugpwmkoNMBsClyMFipAAF0axMuOClc6c9y3c3+q8f1rnw79UylZ+z56rV2mdrpinHykgilLCMxMpwp+gq8ilKTe2KuzIIH9YmKquDrDCFpnFqoejjLWfcs/V5c2OmnBqcnoy0GbVPRF4rFEC6CX1hLic3TiCjlO7JLMPEtOVZTKa
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=51ca00d5.xn--30v786c.k1306; olt=johnl@user.iecc.com; bh=eQo2Yb96cL7kEziLDdu1d3VacZH0nkpMSwvANOafBUQ=; b=Wg6wj08SuqX9anQcy7dmO0QJEc6Cct56zh5Mjp4AswZ2/rGWZ8g/nBwfe8Czp1ua0c7da/zVy3NwkTY7ijeJGsXGtkDINJUhbdeUnTCeWThgstcYYvqJcnQNNpA9tMFO65l3rjn+1ffeBCe/LLOc2wCSPTmiVZucsHOidCHpOD8RUR//D3vKfMzynQFg34PvnO7RrMAzjXKu2Pr4n2Qp/utQDEjFJv8UhcOqZNJEWXaByiIG71vBVP0pN8gUWfyD
Date: 25 Jun 2013 20:42:39 -0000
Message-ID: <20130625204239.35722.qmail@joyce.lan>
From: "John Levine" <johnl@taugh.com>
To: apps-discuss@ietf.org
In-Reply-To: <CAL0qLwaWkZfy9r2TUkptn5Y04Acc3C4_m3vCwZfmgsDa+Ozdmg@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] Remember the MX 0 . draft?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 25 Jun 2013 20:43:10 -0000

>>   nomailhere.example. MX 0 .

>Never heard of this before.  Are there implementations?

I did some experiements:

Yahoo: mail fails immediately

Gmail, AOL: doesn't fail immediately, will report back next week

Hotmail/Outlook.com: some attempts fail with an odd error message, some succeed

qmail: fails immediately (code unchanged since 1998)

So I'd say there are some implementations but we have a way to go.

R's,
John

From johnl@iecc.com  Tue Jun 25 14:37:44 2013
Return-Path: <johnl@iecc.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7E2611E8159 for <apps-discuss@ietfa.amsl.com>; Tue, 25 Jun 2013 14:37:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.874
X-Spam-Level: 
X-Spam-Status: No, score=-110.874 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GWfdvligY4IE for <apps-discuss@ietfa.amsl.com>; Tue, 25 Jun 2013 14:37:40 -0700 (PDT)
Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 8D48611E8143 for <apps-discuss@ietf.org>; Tue, 25 Jun 2013 14:37:39 -0700 (PDT)
Received: (qmail 4885 invoked from network); 25 Jun 2013 21:37:38 -0000
Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 25 Jun 2013 21:37:38 -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=51ca0da2.xn--i8sz2z.k1306; i=johnl@user.iecc.com; bh=r/CftyuGv9qUylCQoUY4mw19xvXVP7P6/UFjFIp0H+0=; b=YsuO+Q+m27vgXadm5yaqmMYNUtWF55fLf07/6As3RxTyqN24kNcD/I/8KL4yi2RByb6xSqo0n2sPMNh5OHsp/d+8s0DnHll4Pae7j1LJ0h7gFVtiA1bsHUOfi/9ksHS6MYNZxos6rq3R81+RjCH8FIbM/cw9NrGGE97yMb1HkXuxuBXMQSed/BbgjiZn/zcFHx4reJWNU65HCk7+KdexcQvUeRqABT/qJSxp2ktqX9SIdh9Krk2Ke+Y6AdRa1mAf
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=51ca0da2.xn--i8sz2z.k1306; olt=johnl@user.iecc.com; bh=r/CftyuGv9qUylCQoUY4mw19xvXVP7P6/UFjFIp0H+0=; b=krafRAfvFaFlSXsCMTTkZHEFVzyl1iyZ6YVsoyff1bPx1yyXl4ZjWAuVLyoJ377NsXIz2mMLlwchf5raDUl2GcLGljWG9oadWsHGCunyWwJsw2f8onw/lLWdLuUVa2E4Uzac0Y/kf1NRdmMbWmwnwHS1UO59G+awMzNK4xYFWplpFZpVhAUSyhcRrnIGEY5AzEr7HnlV3OFCZTjMExgklIAGU7S3jxBggShxPnNrTvG45GOnlOfLpFG/FgknDXnw
Date: 25 Jun 2013 21:37:16 -0000
Message-ID: <20130625213716.35943.qmail@joyce.lan>
From: "John Levine" <johnl@taugh.com>
To: apps-discuss@ietf.org
In-Reply-To: <20130625204239.35722.qmail@joyce.lan>
Organization: 
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Cc: johnl@taugh.com
Subject: Re: [apps-discuss] Remember the MX 0 . draft?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 25 Jun 2013 21:37:45 -0000

>>>   nomailhere.example. MX 0 .


>I did some experiements:
>
>Yahoo: mail fails immediately
>
>Gmail, AOL: doesn't fail immediately, will report back next week
>
>Hotmail/Outlook.com: some attempts fail with an odd error message, some succeed
>
>qmail: fails immediately (code unchanged since 1998)

postfix: fails immediately, not due to special case code, but Wietse
agrees that's the correct thing for it to do.


From scott@kitterman.com  Tue Jun 25 17:42:05 2013
Return-Path: <scott@kitterman.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD6B321F9AD5 for <apps-discuss@ietfa.amsl.com>; Tue, 25 Jun 2013 17:42:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A+CRTCbhFV4d for <apps-discuss@ietfa.amsl.com>; Tue, 25 Jun 2013 17:42:01 -0700 (PDT)
Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 33E6E21F9AD1 for <apps-discuss@ietf.org>; Tue, 25 Jun 2013 17:42:01 -0700 (PDT)
Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id ED25220E40FD; Tue, 25 Jun 2013 20:41:58 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1372207319; bh=EaW7tnj69dY1puhRW3CbOeY7M8kR10AybqmQoJMFXsk=; h=From:To:Subject:Date:In-Reply-To:References:From; b=hTjRnI7Ix3SYbUThIClFhqEPe73tnXxoAMMiPRKkqJWh8yrcrsgqK3DcXXIyf1Q3C PbbyVtWbjIfODD9qjwz3Roa3phMWoGi/ttA12Yx2Ll9yTw1C3ofToaV/9FR4zn8J7Z uHtqEDkUG3KKZf/b6Ne8uCUjCP/Dho/ja5Sef3IM=
Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id C41D820E40F0;  Tue, 25 Jun 2013 20:41:58 -0400 (EDT)
From: Scott Kitterman <scott@kitterman.com>
To: apps-discuss@ietf.org
Date: Tue, 25 Jun 2013 20:41:56 -0400
Message-ID: <14447063.Ixv9s5JjU4@scott-latitude-e6320>
User-Agent: KMail/4.10.4 (Linux/3.8.0-25-generic; KDE/4.10.4; i686; ; )
In-Reply-To: <20130625213716.35943.qmail@joyce.lan>
References: <20130625213716.35943.qmail@joyce.lan>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-AV-Checked: ClamAV using ClamSMTP
Subject: Re: [apps-discuss] Remember the MX 0 . draft?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 26 Jun 2013 00:42:05 -0000

On Tuesday, June 25, 2013 09:37:16 PM John Levine wrote:
> >>>   nomailhere.example. MX 0 .
> >
> >I did some experiements:
> >
> >Yahoo: mail fails immediately
> >
> >Gmail, AOL: doesn't fail immediately, will report back next week
> >
> >Hotmail/Outlook.com: some attempts fail with an odd error message, some
> >succeed
> >
> >qmail: fails immediately (code unchanged since 1998)
> 
> postfix: fails immediately, not due to special case code, but Wietse
> agrees that's the correct thing for it to do.

When this was first seen in the wild, it did surface a bug in postfix:

20061227

	Bugfix (introduced with Postfix 2.3): the MX hostname syntax
	check was skipped with reject_unknown_helo_hostname and
	reject_unknown_sender/recipient_domain, so that Postfix
	would still accept mail from domains with a zero-length MX
	hostname.  File: smtpd/smtpd_check.c.

(from the history file)

I remember when this came up.  It was due to mx 0 ., so it did, at least in 
2006, have enough deployment that a related bug got reported and fixed.

Scott K

From duerst@it.aoyama.ac.jp  Tue Jun 25 18:25:56 2013
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 (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDB3521F9A52 for <apps-discuss@ietfa.amsl.com>; Tue, 25 Jun 2013 18:25:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.79
X-Spam-Level: 
X-Spam-Status: No, score=-103.79 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uKwN9fylPA5X for <apps-discuss@ietfa.amsl.com>; Tue, 25 Jun 2013 18:25:52 -0700 (PDT)
Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 101EB21F9AF8 for <apps-discuss@ietf.org>; Tue, 25 Jun 2013 18:25:50 -0700 (PDT)
Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id r5Q1PiG9022657; Wed, 26 Jun 2013 10:25:44 +0900
Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 4c0d_88f0_52592630_ddff_11e2_882d_001e6722eec2; Wed, 26 Jun 2013 10:25:44 +0900
Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 6078EC00D5; Wed, 26 Jun 2013 10:24:16 +0900 (JST)
Message-ID: <51CA430C.8060602@it.aoyama.ac.jp>
Date: Wed, 26 Jun 2013 10:25:32 +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: "Murray S. Kucherawy" <superuser@gmail.com>
References: <CACweHNCTSZ3xvZPLeahZmJVg6pYheqvPfGxa_GPc1O9Aomi9hw@mail.gmail.com> <CAL0qLwYNx17z42_pNucbPGY9ZvMx9yV9hnD74Nfhje_Rx9rcaw@mail.gmail.com>
In-Reply-To: <CAL0qLwYNx17z42_pNucbPGY9ZvMx9yV9hnD74Nfhje_Rx9rcaw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: IETF Apps Discuss <apps-discuss@ietf.org>, Matthew Kerwin <matthew@kerwin.net.au>
Subject: Re: [apps-discuss] File URI Scheme
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 26 Jun 2013 01:25:57 -0000

Hello Kerwin,

On 2013/06/26 3:24, Murray S. Kucherawy wrote:
> On Mon, Jun 24, 2013 at 8:34 PM, Matthew Kerwin<matthew@kerwin.net.au>wrote:
>
>> Would you please consider creating a draft for the file: URI scheme
>> (or taking over my existing draft); or if not, point me to some
>> resources or discussions about why the file scheme seems to have gone
>> out of vogue?
>>
>> The current revision of my draft is
>> <http://tools.ietf.org/html/draft-kerwin-file-scheme-03>  , and the
>> working copy is on github
>> <https://github.com/phluid61/file-uri-scheme>
>>
>>
>>
> By "creating a draft", are you asking APPSAWG to adopt yours, or are you
> asking us to come up with something else and process that?

To be more specific:

"come up with something else and process that" means that somebody would 
volunteer to become an author/editor. I wouldn't know anybody here who 
would volunteer (of course I might be wrong).

"adopt yours" would mean that you would republish your draft as 
something like draft-ietf-appsawg-file-scheme-00, and continue as the 
author/editor. The WG would mostly help with reviewing the draft, and 
the WG chairs (and maybe others) would help with shepherding the draft 
through the process.

My personal opinion is that it would indeed be desirable to have a 
specification (*) for the file: URI scheme. However, as Paul said in a 
separate mail, and as I indicated a few days ago at 
https://bugs.ruby-lang.org/issues/8544#note-4 (sorry for mixing up file: 
and ftp:), the file: URI scheme is really messy.

So my opinion would be that you work on your draft a some more, trying 
to get help from wherever you can find it (including of course this 
group), and formally come back here when you think that you have 
something that may be widely acceptable.

Regards,    Martin.


(*) Note that "living standard" is a very specific term used mostly by 
WHATWG, see 
http://wiki.whatwg.org/wiki/FAQ#What_does_.22Living_Standard.22_mean.3F.

From mnot@mnot.net  Tue Jun 25 23:51:32 2013
Return-Path: <mnot@mnot.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC4F421F9EBB for <apps-discuss@ietfa.amsl.com>; Tue, 25 Jun 2013 23:51:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-4.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id egmS75Sk9gHD for <apps-discuss@ietfa.amsl.com>; Tue, 25 Jun 2013 23:51:26 -0700 (PDT)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 877DA21F9EB8 for <apps-discuss@ietf.org>; Tue, 25 Jun 2013 23:51:26 -0700 (PDT)
Received: from [192.168.1.80] (unknown [118.209.171.15]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id DC79B509B5; Wed, 26 Jun 2013 02:51:19 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <51C9C91D.90206@berkeley.edu>
Date: Wed, 26 Jun 2013 16:51:32 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <4C2FD8A7-4F3E-433B-A7F6-F0BD751D31AD@mnot.net>
References: <20130610033804.19451.29465.idtracker@ietfa.amsl.com> <E6062DBC-CD7B-47CA-A6F0-5E7D64C0DB55@mnot.net> <51B7AEAF.20404@berkeley.edu> <4CD4652F-4EAF-4258-A6EB-577019018D2C@mnot.net> <1A136C4D-4F0C-446F-B307-D53FB9A40622@cs.tcd.ie> <8BE038EC-1580-4D27-ABBA-1890EEFD4853@mnot.net> <51C9C91D.90206@berkeley.edu>
To: Erik Wilde <dret@berkeley.edu>
X-Mailer: Apple Mail (2.1508)
Cc: IETF Apps Discuss <apps-discuss@ietf.org>, REST-Discuss <rest-discuss@yahoogroups.com>
Subject: Re: [apps-discuss] New Version Notification for draft-nottingham-link-hint-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 26 Jun 2013 06:51:32 -0000

On 26/06/2013, at 2:45 AM, Erik Wilde <dret@berkeley.edu> wrote:

> i really like the places where it says "a number" and "a list", =
because these concepts can be easily mapped into pretty much any =
representation. when it says "an object", however, that's an entirely =
different matter. it would be great for the registry to really be clear =
about what kind of structures to expect for hints (single values, value =
lists, and maybe lists of key/value pairs or something along those =
lines), and then the registry would not depend on a specific language.

It's certainly possible to map the JSON data model into XML; it just =
won't make XML people happy, because it'll have lots of elements named =
"object" and "array" (although I see a fair amount of "native" XML like =
this anyway!).

Likewise for (most any, since JSON is pretty basic) other data models.

I very much agree that it would be good to not have a dependency upon =
the JSON data model here. However, I don't see a way to avoid that, =
without either a) using another data model with exactly the same =
problem, or b) prohibiting any structured information.

AIUI you're suggesting (b). Looking through the current list of hints, =
we already have quite a few that need structure. Can you suggest how to =
convey the information without using structured data?

Regards,

--
Mark Nottingham   http://www.mnot.net/




From ietfc@btconnect.com  Wed Jun 26 02:48:54 2013
Return-Path: <ietfc@btconnect.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76C9121E8122 for <apps-discuss@ietfa.amsl.com>; Wed, 26 Jun 2013 02:48:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EvGkcVoqhAe7 for <apps-discuss@ietfa.amsl.com>; Wed, 26 Jun 2013 02:48:50 -0700 (PDT)
Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe006.messaging.microsoft.com [216.32.180.189]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8F721E8116 for <apps-discuss@ietf.org>; Wed, 26 Jun 2013 02:48:44 -0700 (PDT)
Received: from mail65-co1-R.bigfish.com (10.243.78.238) by CO1EHSOBE019.bigfish.com (10.243.66.82) with Microsoft SMTP Server id 14.1.225.23; Wed, 26 Jun 2013 09:48:43 +0000
Received: from mail65-co1 (localhost [127.0.0.1])	by mail65-co1-R.bigfish.com (Postfix) with ESMTP id BF5089C0587; Wed, 26 Jun 2013 09:48:43 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.249.85; KIP:(null); UIP:(null); IPV:NLI; H:AMSPRD0710HT001.eurprd07.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -14
X-BigFish: PS-14(zz9371I542I1432Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275bh8275dhz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h304l1d11m1155h)
Received: from mail65-co1 (localhost.localdomain [127.0.0.1]) by mail65-co1 (MessageSwitch) id 1372240121925438_19741; Wed, 26 Jun 2013 09:48:41 +0000 (UTC)
Received: from CO1EHSMHS019.bigfish.com (unknown [10.243.78.236])	by mail65-co1.bigfish.com (Postfix) with ESMTP id DFE1B8800AD; Wed, 26 Jun 2013 09:48:41 +0000 (UTC)
Received: from AMSPRD0710HT001.eurprd07.prod.outlook.com (157.56.249.85) by CO1EHSMHS019.bigfish.com (10.243.66.29) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 26 Jun 2013 09:48:41 +0000
Received: from DBXPRD0411HT001.eurprd04.prod.outlook.com (157.56.253.165) by pod51017.outlook.com (10.255.160.164) with Microsoft SMTP Server (TLS) id 14.16.324.0; Wed, 26 Jun 2013 09:48:34 +0000
Message-ID: <022d01ce7252$663bc180$4001a8c0@gateway.2wire.net>
From: t.petch <ietfc@btconnect.com>
To: Matthew Kerwin <matthew@kerwin.net.au>, apps-discuss <apps-discuss@ietf.org>
References: <CACweHNCTSZ3xvZPLeahZmJVg6pYheqvPfGxa_GPc1O9Aomi9hw@mail.gmail.com>
Date: Wed, 26 Jun 2013 10:44:22 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [157.56.253.165]
X-OriginatorOrg: btconnect.com
Subject: Re: [apps-discuss] File URI Scheme
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 26 Jun 2013 09:48:54 -0000

Well, you have created a draft, which is more than most manage when
first they approach the IETF, so I assume you do have an understanding
of what it takes.  That said, there are a number of changes you would
have to make for it to conform to the layout of an RFC but that can be
done.

You may not know that there is a mailing list dedicated to URI,
uri@w3.org
which is the usual home for URI discussions.  The archive contains
discussions of file: and in particular, Paul's comments in May 2005
about not reaching consensus; probably worth a look.

Tom Petch

----- Original Message -----
From: "Matthew Kerwin" <matthew@kerwin.net.au>
To: <apps-discuss@ietf.org>
Sent: Tuesday, June 25, 2013 4:34 AM

> Hi, it recently came up in a discussion on the ruby core developers'
> mailing list <https://bugs.ruby-lang.org/issues/8544> that there is
> currently no living standard defining the file: URI scheme.  Somewhat
> bullheadedly I created my own I-D, based on RFC 1738 and an expired
> draft by Paul Hoffman; however it occurs to me that this should
> probably be under the purview of the Apps Area Working Group.
>
> Would you please consider creating a draft for the file: URI scheme
> (or taking over my existing draft); or if not, point me to some
> resources or discussions about why the file scheme seems to have gone
> out of vogue?
>
> The current revision of my draft is
> <http://tools.ietf.org/html/draft-kerwin-file-scheme-03> , and the
> working copy is on github
> <https://github.com/phluid61/file-uri-scheme>
>
> Cheers
> --
>   Matthew Kerwin, B.Sc (CompSci) (Hons)
>   http://matthew.kerwin.net.au/
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>



From fanf2@hermes.cam.ac.uk  Wed Jun 26 03:48:21 2013
Return-Path: <fanf2@hermes.cam.ac.uk>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE73D11E81B0 for <apps-discuss@ietfa.amsl.com>; Wed, 26 Jun 2013 03:48:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fVX9wXktYji3 for <apps-discuss@ietfa.amsl.com>; Wed, 26 Jun 2013 03:48:20 -0700 (PDT)
Received: from ppsw-33.csi.cam.ac.uk (ppsw-33.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f33]) by ietfa.amsl.com (Postfix) with ESMTP id 8D05211E81AF for <apps-discuss@ietf.org>; Wed, 26 Jun 2013 03:48:20 -0700 (PDT)
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:49498) by ppsw-33.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.157]:25) with esmtpa (EXTERNAL:fanf2) id 1UrnGs-0006Yr-ia (Exim 4.80_167-5a66dd3) (return-path <fanf2@hermes.cam.ac.uk>); Wed, 26 Jun 2013 11:48:18 +0100
Received: from fanf2 by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1UrnGs-00012n-Od (Exim 4.72) (return-path <fanf2@hermes.cam.ac.uk>); Wed, 26 Jun 2013 11:48:18 +0100
Date: Wed, 26 Jun 2013 11:48:18 +0100
From: Tony Finch <dot@dotat.at>
X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk
To: John Levine <johnl@taugh.com>
In-Reply-To: <20130625213716.35943.qmail@joyce.lan>
Message-ID: <alpine.LSU.2.00.1306261147020.9686@hermes-2.csi.cam.ac.uk>
References: <20130625213716.35943.qmail@joyce.lan>
User-Agent: Alpine 2.00 (LSU 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Tony Finch <fanf2@hermes.cam.ac.uk>
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Remember the MX 0 . draft?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 26 Jun 2013 10:48:21 -0000

John Levine <johnl@taugh.com> wrote:

> >>>   nomailhere.example. MX 0 .
>
> >I did some experiements:
> >
> >Yahoo: mail fails immediately
> >
> >Gmail, AOL: doesn't fail immediately, will report back next week
> >
> >Hotmail/Outlook.com: some attempts fail with an odd error message, some succeed
> >
> >qmail: fails immediately (code unchanged since 1998)
>
> postfix: fails immediately, not due to special case code, but Wietse
> agrees that's the correct thing for it to do.

Exim will immediately reject too. (Logic shared with SRV implementation;
i.e. null targets are special cased to avoid bogus queries against the
root name servers.)

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.

From dret@berkeley.edu  Wed Jun 26 10:26:03 2013
Return-Path: <dret@berkeley.edu>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD3CA11E81DF for <apps-discuss@ietfa.amsl.com>; Wed, 26 Jun 2013 10:26:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.3
X-Spam-Level: 
X-Spam-Status: No, score=-5.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xOMK6sc3nBbR for <apps-discuss@ietfa.amsl.com>; Wed, 26 Jun 2013 10:25:45 -0700 (PDT)
Received: from cm03fe.IST.Berkeley.EDU (cm03fe.IST.Berkeley.EDU [169.229.218.144]) by ietfa.amsl.com (Postfix) with ESMTP id B8CF411E81DD for <apps-discuss@ietf.org>; Wed, 26 Jun 2013 10:25:43 -0700 (PDT)
Received: from mobile-166-137-186-253.mycingular.net ([166.137.186.253] helo=dretpro.local) by cm03fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from <dret@berkeley.edu>) id 1UrtTE-0004o8-9h; Wed, 26 Jun 2013 10:25:28 -0700
Message-ID: <51CB240C.3060101@berkeley.edu>
Date: Wed, 26 Jun 2013 10:25:32 -0700
From: Erik Wilde <dret@berkeley.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: Mark Nottingham <mnot@mnot.net>
References: <20130610033804.19451.29465.idtracker@ietfa.amsl.com> <E6062DBC-CD7B-47CA-A6F0-5E7D64C0DB55@mnot.net> <51B7AEAF.20404@berkeley.edu> <4CD4652F-4EAF-4258-A6EB-577019018D2C@mnot.net> <1A136C4D-4F0C-446F-B307-D53FB9A40622@cs.tcd.ie> <8BE038EC-1580-4D27-ABBA-1890EEFD4853@mnot.net> <51C9C91D.90206@berkeley.edu> <4C2FD8A7-4F3E-433B-A7F6-F0BD751D31AD@mnot.net>
In-Reply-To: <4C2FD8A7-4F3E-433B-A7F6-F0BD751D31AD@mnot.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: IETF Apps Discuss <apps-discuss@ietf.org>, REST-Discuss <rest-discuss@yahoogroups.com>
Subject: Re: [apps-discuss] New Version Notification for draft-nottingham-link-hint-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 26 Jun 2013 17:26:03 -0000

hello mark.

On 2013-06-25 23:51 , Mark Nottingham wrote:
>> i really like the places where it says "a number" and "a list", because these concepts can be easily mapped into pretty much any representation. when it says "an object", however, that's an entirely different matter. it would be great for the registry to really be clear about what kind of structures to expect for hints (single values, value lists, and maybe lists of key/value pairs or something along those lines), and then the registry would not depend on a specific language.
> It's certainly possible to map the JSON data model into XML; it just won't make XML people happy, because it'll have lots of elements named "object" and "array" (although I see a fair amount of "native" XML like this anyway!).

sure, with enough effort, anything can be mapped to anything. my point 
was to have something for the link hints that can be mapped into more 
useful structures for any target mapping, and not just for JSON.

> I very much agree that it would be good to not have a dependency upon the JSON data model here. However, I don't see a way to avoid that, without either a) using another data model with exactly the same problem, or b) prohibiting any structured information.
> AIUI you're suggesting (b). Looking through the current list of hints, we already have quite a few that need structure. Can you suggest how to convey the information without using structured data?

i think there are three possibilities:

- pick a generic format (such as JSON) as allow anything it allows. this 
makes things great for JSON and not so great for non-JSON.

- be structure agnostic (hints are strings) and then hints will probably 
define their own mappings into string-based structures (using regexes 
and usual patterns such as whitespace- or comma-separated lists). this 
might be bad because then parsing a hint's value needs to be done on a 
per-hint basis.

- pick a small set of structures allowed such as the ones i suggested 
above (single values, value lists, and maybe lists of key/value pairs) 
and require that any hint is defined in terms of this more restricted 
model. this maps better to many formats, but you're stuck with the 
choices you make.

so my suggestion is not so much your (b) but my (c) ;-) fwiw, it seems 
that thew current draft uses overly complicated structures, for example, 
"formats" maybe just could be an array of formats?

it's clearly a trade-off between allowing arbitrarily structured hints 
(in which case you need some generic metamodel) or predefining the kinds 
of structures that hints can use (in which case you can remove the 
dependency on a particular generic metamodel). i am still trying to 
understand how that problem has been solved in similar cases. i assume 
this is not the first (proposed) IANA registry that has to deal with 
this tradeoff; does anybody have pointers to this has been handled in 
similar cases?

thanks and cheers,

dret.

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

From mnot@mnot.net  Wed Jun 26 16:40:19 2013
Return-Path: <mnot@mnot.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAB9411E8111 for <apps-discuss@ietfa.amsl.com>; Wed, 26 Jun 2013 16:40:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.599
X-Spam-Level: 
X-Spam-Status: No, score=-105.599 tagged_above=-999 required=5 tests=[AWL=-3.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZlWh4nvU1TQa for <apps-discuss@ietfa.amsl.com>; Wed, 26 Jun 2013 16:40:14 -0700 (PDT)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id B908011E814C for <apps-discuss@ietf.org>; Wed, 26 Jun 2013 16:40:14 -0700 (PDT)
Received: from [192.168.1.80] (unknown [118.209.171.15]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 8498C509B6; Wed, 26 Jun 2013 19:40:11 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <51CB240C.3060101@berkeley.edu>
Date: Thu, 27 Jun 2013 09:40:08 +1000
Content-Transfer-Encoding: quoted-printable
Message-Id: <F2662B38-CDD6-401D-85F8-438FF67AFAFF@mnot.net>
References: <20130610033804.19451.29465.idtracker@ietfa.amsl.com> <E6062DBC-CD7B-47CA-A6F0-5E7D64C0DB55@mnot.net> <51B7AEAF.20404@berkeley.edu> <4CD4652F-4EAF-4258-A6EB-577019018D2C@mnot.net> <1A136C4D-4F0C-446F-B307-D53FB9A40622@cs.tcd.ie> <8BE038EC-1580-4D27-ABBA-1890EEFD4853@mnot.net> <51C9C91D.90206@berkeley.edu> <4C2FD8A7-4F3E-433B-A7F6-F0BD751D31AD@mnot.net> <51CB240C.3060101@berkeley.edu>
To: Erik Wilde <dret@berkeley.edu>
X-Mailer: Apple Mail (2.1508)
Cc: IETF Apps Discuss <apps-discuss@ietf.org>, REST-Discuss <rest-discuss@yahoogroups.com>
Subject: Re: [apps-discuss] New Version Notification for draft-nottingham-link-hint-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 26 Jun 2013 23:40:20 -0000

On 27/06/2013, at 3:25 AM, Erik Wilde <dret@berkeley.edu> wrote:

> hello mark.
>=20
> On 2013-06-25 23:51 , Mark Nottingham wrote:
>>> i really like the places where it says "a number" and "a list", =
because these concepts can be easily mapped into pretty much any =
representation. when it says "an object", however, that's an entirely =
different matter. it would be great for the registry to really be clear =
about what kind of structures to expect for hints (single values, value =
lists, and maybe lists of key/value pairs or something along those =
lines), and then the registry would not depend on a specific language.
>> It's certainly possible to map the JSON data model into XML; it just =
won't make XML people happy, because it'll have lots of elements named =
"object" and "array" (although I see a fair amount of "native" XML like =
this anyway!).
>=20
> sure, with enough effort, anything can be mapped to anything. my point =
was to have something for the link hints that can be mapped into more =
useful structures for any target mapping, and not just for JSON.
>=20
>> I very much agree that it would be good to not have a dependency upon =
the JSON data model here. However, I don't see a way to avoid that, =
without either a) using another data model with exactly the same =
problem, or b) prohibiting any structured information.
>> AIUI you're suggesting (b). Looking through the current list of =
hints, we already have quite a few that need structure. Can you suggest =
how to convey the information without using structured data?
>=20
> i think there are three possibilities:
>=20
> - pick a generic format (such as JSON) as allow anything it allows. =
this makes things great for JSON and not so great for non-JSON.

Yep, this is where we're at.


> - be structure agnostic (hints are strings) and then hints will =
probably define their own mappings into string-based structures (using =
regexes and usual patterns such as whitespace- or comma-separated =
lists). this might be bad because then parsing a hint's value needs to =
be done on a per-hint basis.

I'm -1 on this; it hasn't worked out so well for HTTP headers (and in =
fact a significant number of people are agitating to just define new =
headers in JSON) nor for media type parameters.


> - pick a small set of structures allowed such as the ones i suggested =
above (single values, value lists, and maybe lists of key/value pairs) =
and require that any hint is defined in terms of this more restricted =
model. this maps better to many formats, but you're stuck with the =
choices you make.
>=20
> so my suggestion is not so much your (b) but my (c) ;-) fwiw, it seems =
that thew current draft uses overly complicated structures, for example, =
"formats" maybe just could be an array of formats?

Could you spell out an example?


> it's clearly a trade-off between allowing arbitrarily structured hints =
(in which case you need some generic metamodel) or predefining the kinds =
of structures that hints can use (in which case you can remove the =
dependency on a particular generic metamodel). i am still trying to =
understand how that problem has been solved in similar cases. i assume =
this is not the first (proposed) IANA registry that has to deal with =
this tradeoff; does anybody have pointers to this has been handled in =
similar cases?
>=20
> thanks and cheers,


Cheers,

--
Mark Nottingham   http://www.mnot.net/




From dret@berkeley.edu  Wed Jun 26 17:24:51 2013
Return-Path: <dret@berkeley.edu>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08AE811E8170 for <apps-discuss@ietfa.amsl.com>; Wed, 26 Jun 2013 17:24:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.949
X-Spam-Level: 
X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.650,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kjFVRWIlQDuS for <apps-discuss@ietfa.amsl.com>; Wed, 26 Jun 2013 17:24:47 -0700 (PDT)
Received: from cm01fe.IST.Berkeley.EDU (cm01fe.IST.Berkeley.EDU [169.229.218.142]) by ietfa.amsl.com (Postfix) with ESMTP id F0A6F11E8155 for <apps-discuss@ietf.org>; Wed, 26 Jun 2013 17:24:46 -0700 (PDT)
Received: from mobile-166-137-186-253.mycingular.net ([166.137.186.253] helo=dretpro.local) by cm01fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:dret@berkeley.edu) (envelope-from <dret@berkeley.edu>) id 1Us00w-0002ES-57; Wed, 26 Jun 2013 17:24:43 -0700
Message-ID: <51CB8646.60101@berkeley.edu>
Date: Wed, 26 Jun 2013 17:24:38 -0700
From: Erik Wilde <dret@berkeley.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: Mark Nottingham <mnot@mnot.net>
References: <20130610033804.19451.29465.idtracker@ietfa.amsl.com> <E6062DBC-CD7B-47CA-A6F0-5E7D64C0DB55@mnot.net> <51B7AEAF.20404@berkeley.edu> <4CD4652F-4EAF-4258-A6EB-577019018D2C@mnot.net> <1A136C4D-4F0C-446F-B307-D53FB9A40622@cs.tcd.ie> <8BE038EC-1580-4D27-ABBA-1890EEFD4853@mnot.net> <51C9C91D.90206@berkeley.edu> <4C2FD8A7-4F3E-433B-A7F6-F0BD751D31AD@mnot.net> <51CB240C.3060101@berkeley.edu> <F2662B38-CDD6-401D-85F8-438FF67AFAFF@mnot.net>
In-Reply-To: <F2662B38-CDD6-401D-85F8-438FF67AFAFF@mnot.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: IETF Apps Discuss <apps-discuss@ietf.org>, REST-Discuss <rest-discuss@yahoogroups.com>
Subject: Re: [apps-discuss] New Version Notification for draft-nottingham-link-hint-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 27 Jun 2013 00:24:51 -0000

hello mark.

On 2013-06-26 16:40 , Mark Nottingham wrote:
> On 27/06/2013, at 3:25 AM, Erik Wilde <dret@berkeley.edu> wrote:
>>> I very much agree that it would be good to not have a dependency upon the JSON data model here. However, I don't see a way to avoid that, without either a) using another data model with exactly the same problem, or b) prohibiting any structured information.
>>> AIUI you're suggesting (b). Looking through the current list of hints, we already have quite a few that need structure. Can you suggest how to convey the information without using structured data?
>> i think there are three possibilities:
>> - pick a generic format (such as JSON) as allow anything it allows. this makes things great for JSON and not so great for non-JSON.
> Yep, this is where we're at.
>> - be structure agnostic (hints are strings) and then hints will probably define their own mappings into string-based structures (using regexes and usual patterns such as whitespace- or comma-separated lists). this might be bad because then parsing a hint's value needs to be done on a per-hint basis.
> I'm -1 on this; it hasn't worked out so well for HTTP headers (and in fact a significant number of people are agitating to just define new headers in JSON) nor for media type parameters.

i agree that this is not such a great way to go. it makes things easy in 
the short run, but harder in the long run. in particular, it means that 
the same concepts ("a list") may be serialized differently in different 
hints (a "comma-separated" one, a "space-separated" one), which makes it 
harder to build general facilities for hints.

>> - pick a small set of structures allowed such as the ones i suggested above (single values, value lists, and maybe lists of key/value pairs) and require that any hint is defined in terms of this more restricted model. this maps better to many formats, but you're stuck with the choices you make.
>> so my suggestion is not so much your (b) but my (c) ;-) fwiw, it seems that thew current draft uses overly complicated structures, for example, "formats" maybe just could be an array of formats?
> Could you spell out an example?

afaict, "formats" 
(http://tools.ietf.org/html/draft-nottingham-link-hint-00#section-3.2) 
right now says says it's an object with the keys being media types, but 
the values are not specified. but maybe i am reading it wrong and where 
it says "The object" in the second and third paragraph it actually 
refers to the object that's a value of one of the keys? hmmm, i guess 
that's what it means... i had been reading it wrong so far. but for a 
minute, let's just assume it's only media types, which is how i am using 
it in an example using link hints here: 
https://github.com/dret/I-D/blob/master/link-desc/ld-atompub-00.xml

so let's assume for a minute that this is just a list. then i would 
suggest is the following: the hint is defined as follows (stealing your 
structure here):

o  Hint Name: formats
o  Description: Hints the representation type(s) that the target 
resource can produce and consume, using the GET and PUT (if allowed) 
methods respectively.
o  Content Model: list
o  Specification: [this document]
Content MUST be a list, whose values are media types.

then, the term "list" in the content model must be defined somewhere. 
like i said, maybe we could say there are three "content models" hints 
support: single values, lists, key/value pairs. how a particular hint 
value would be serialized then would be up to the format where it's 
being represented.

- in JSON, you might represent them as string, array, something else.

- in XML, you might choose a mix of element/attribute designs. or you 
could go text-based such as my example (which is text-based because it 
uses JSON syntax right now)

none of these representations would be binding, they would just be one 
way of mapping the abstract link hint model into some concrete model. i 
guess the only exception for this would be how to represent links 
outside of media types, i.e. in HTTP. 
http://tools.ietf.org/html/draft-nottingham-link-hint-00#appendix-A 
could be changed then to map the abstract moden into a concrete JSON 
syntax (or whatever else looks like a good syntax choice to go into a 
Link header).

as i see it, when i design media types that use link hints, it would be 
nice if i could expose them in a way that is as useful as possible for 
consumers of that media type. my example from above is from an XML 
design for link descriptions that i plan to base on link hints. if that 
means that the XML-oriented clients using this format need to include a 
general-purpose JSON parser, then that's certainly doable, but i don't 
think the link hints design has to be like that.

but again, of course my option (c) means that link hints have a 
predefined and probably small set of structures that hints can use to 
expose whatever they want to expose, and if they want to go beyond that, 
that's not covered by the link hint framework anymore.

cheers,

dret.

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

From superuser@gmail.com  Wed Jun 26 17:32:31 2013
Return-Path: <superuser@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32D0021F9A2F for <apps-discuss@ietfa.amsl.com>; Wed, 26 Jun 2013 17:32:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oAMjBcBapeni for <apps-discuss@ietfa.amsl.com>; Wed, 26 Jun 2013 17:32:30 -0700 (PDT)
Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 3ABA521F9273 for <apps-discuss@ietf.org>; Wed, 26 Jun 2013 17:32:30 -0700 (PDT)
Received: by mail-wg0-f43.google.com with SMTP id z11so76940wgg.10 for <apps-discuss@ietf.org>; Wed, 26 Jun 2013 17:32:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=vd9nUWs+/KmzAwkVN60r7ACCkHr5Gw5Pr4Mx2QeORkc=; b=pme5j2Njuds5H9Zc4qE+3UI2uhvpYa2bZ9S4SrUAn0ICt3ibuOJNN45v1BkWv+i28u Wp7AXi88nC/ypSMckCB5DZKC3G94qv7HHIH14IpOnuyNPiWMW1ERRLI3JD9X2WkHQu5d Rv3Pm5YuFrgQ47RjTTGIJ9AHlnSG4JAnevOtVuijjw4+aFPyIVXu6Rcz73Buc1BhrCpq nA9F1eq+lIeY9RlVUhvkru76S336nNT+ee8BBsgRWn5WLWhZbyGFQj5QqYcCVo0YPWjm 9qgy42t8mEX3J3YPHlKPbn+9orYC25mSMnJng//OHRAI95Fxvb764fzVC4+Zovin7R+M oE7A==
MIME-Version: 1.0
X-Received: by 10.180.187.209 with SMTP id fu17mr4230481wic.52.1372293149340;  Wed, 26 Jun 2013 17:32:29 -0700 (PDT)
Received: by 10.180.90.16 with HTTP; Wed, 26 Jun 2013 17:32:28 -0700 (PDT)
Date: Wed, 26 Jun 2013 17:32:28 -0700
Message-ID: <CAL0qLwY+AbMqyzryFSvAR=bkYP1C1W4XeT7vB1vC0hPAsOYurg@mail.gmail.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
To: IETF Apps Discuss <apps-discuss@ietf.org>
Content-Type: multipart/alternative; boundary=001a11c269acb1ba7504e017e52e
Subject: [apps-discuss] SECOND CALL for IETF 87 (Berlin) agenda items
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 27 Jun 2013 00:32:31 -0000

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

On Mon, May 20, 2013 at 4:56 PM, Murray S. Kucherawy <superuser@gmail.com>wrote:

> Colleagues,
>
> As usual, we will be requesting a Monday morning slot.  This is a call for
> agenda items, or suggestions for same.  Please submit them before June 3rd,
> which is the cutoff date for submitting or amending meeting requests.  We
> will request the usual 2.5 hour session, but we'll shrink it if our agenda
> appears to be thin enough.
>
> You can expect the usual general structure:
>
> - administrivia
> - APPSAWG section
> --- recent activity
> --- current document status and open document issues [*]
> --- incoming/proposed new work [*]
> --- other WG business [*]
> - APPAREA section
> --- new WGs of interest
> --- BoF overview
> --- area-specific topics / AD theatre [*]
> --- presentations [*]
> --- AOB [*]
>
> If you have something you'd like to present in any of the [*] slots above,
> please reply to this post.  If you will be chairing a BoF or a new WG and
> would like to present on that, you are also invited to reply for an agenda
> slot.
>
>
We haven't received a single request for a time slot.  We're beginning to
assemble an agenda now, since we have to post a draft agenda by July 17th.
Also, this meeting in general will be extremely tight time-wise, so if we
don't really need the full 2 1/2 hour time slot, we should determine that
and let the Secretariat know quickly.

Thus, second call: Does anyone wish to present, or request a presentation,
other than the usual administrivia and overview/update items from the
chairs and the ADs?

-MSK, APPSAWG co-chair

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

<div dir=3D"ltr">On Mon, May 20, 2013 at 4:56 PM, Murray S. Kucherawy <span=
 dir=3D"ltr">&lt;<a href=3D"mailto:superuser@gmail.com" target=3D"_blank">s=
uperuser@gmail.com</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"><div dir=3D"ltr"><div><div><div><div><div><d=
iv><div><div><div><div><div><div><div><div>Colleagues,<br><br>As usual, we =
will be requesting a Monday morning slot.=A0 This is a call for agenda item=
s, or suggestions for same.=A0 Please submit them before June 3rd, which is=
 the cutoff date for submitting or amending meeting requests.=A0 We will re=
quest the usual 2.5 hour session, but we&#39;ll shrink it if our agenda app=
ears to be thin enough.<br>

<br></div>You can expect the usual general structure:<br><br></div>- admini=
strivia<br></div>- APPSAWG section<br></div>--- recent activity<br></div>--=
- current document status and open document issues [*]<br></div>--- incomin=
g/proposed new work [*]<br>

</div>--- other WG business [*]<br></div>- APPAREA section<br></div>--- new=
 WGs of interest<br></div>--- BoF overview<br></div>--- area-specific topic=
s / AD theatre [*]<br></div>--- presentations [*]<br>--- AOB [*]<br><br>

</div>If you have something you&#39;d like to present in any of the [*] slo=
ts above, please reply to this post.=A0 If you will be chairing a BoF or a =
new WG and would like to present on that, you are also invited to reply for=
 an agenda slot.<br>

<br></div></div></blockquote><div><br></div><div>We haven&#39;t received a =
single request for a time slot.=A0 We&#39;re beginning to assemble an agend=
a now, since we have to post a draft agenda by July 17th.=A0 Also, this mee=
ting in general will be extremely tight time-wise, so if we don&#39;t reall=
y need the full 2 1/2 hour time slot, we should determine that and let the =
Secretariat know quickly.<br>
<br>Thus, second call: Does anyone wish to present, or request a presentati=
on, other than the usual administrivia and overview/update items from the c=
hairs and the ADs?<br><br></div><div>-MSK, APPSAWG co-chair<br><br></div>
</div></div></div>

--001a11c269acb1ba7504e017e52e--

From ned.freed@mrochek.com  Wed Jun 26 18:35:47 2013
Return-Path: <ned.freed@mrochek.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81D5711E8177 for <apps-discuss@ietfa.amsl.com>; Wed, 26 Jun 2013 18:35:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PLU2TSTn+k0x for <apps-discuss@ietfa.amsl.com>; Wed, 26 Jun 2013 18:35:42 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by ietfa.amsl.com (Postfix) with ESMTP id ADF3611E815C for <apps-discuss@ietf.org>; Wed, 26 Jun 2013 18:35:34 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01OVBCWVPUN4005T28@mauve.mrochek.com> for apps-discuss@ietf.org; Wed, 26 Jun 2013 18:30:31 -0700 (PDT)
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 <01OVBCNODMOG007PSE@mauve.mrochek.com> for apps-discuss@ietf.org; Wed, 26 Jun 2013 18:30:30 -0700 (PDT)
Message-id: <01OVBCWUMFA0007PSE@mauve.mrochek.com>
Date: Wed, 26 Jun 2013 18:23:32 -0700 (PDT)
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Mon, 13 May 2013 15:39:32 +0000" <20130513153932.91355.qmail@joyce.lan>
References: <CAL0qLwaBPhyPEKHPwRurqoCnNy2_tp6rCHe7YzvPonvfN_ALHQ@mail.gmail.com> <20130513153932.91355.qmail@joyce.lan>
To: apps-discuss@ietf.org
Subject: [apps-discuss] Malformed mail (was Re: Review of: draft-ietf-appsawg-malformed-mail-03)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 27 Jun 2013 01:35:47 -0000

In regards to malformed message, I just ran into one containing, among other
things, the following fields:

Received: from 1.2.3.4 @ host user@host
Received: from 4.5.6. user@host
Return-Path: user@host "phrase"
Content-Type: text/plain
Content-Transfer-Encoding: 9-bit
Content-Type: text/plain
MIME Ver: 1.40

(I have of course anonymized things.)

Of course I've seen plenty of broken messages, but this is taking things
to a whole new level.

				Ned

From iesg-secretary@ietf.org  Thu Jun 27 00:24:19 2013
Return-Path: <iesg-secretary@ietf.org>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56EE321F9B44; Thu, 27 Jun 2013 00:24:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.4
X-Spam-Level: 
X-Spam-Status: No, score=-102.4 tagged_above=-999 required=5 tests=[AWL=0.200,  BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5mI5dSkucuz4; Thu, 27 Jun 2013 00:24:18 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E861621F9B25; Thu, 27 Jun 2013 00:24:17 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: DraftTracker Mail System <iesg-secretary@ietf.org>
To: iesg@ietf.org, appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-rfc5451bis@tools.ietf.org, sm+ietf@elandsys.com, apps-discuss@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.51.p2
Message-ID: <20130627072417.22065.66266.idtracker@ietfa.amsl.com>
Date: Thu, 27 Jun 2013 00:24:17 -0700
Cc: iesg-secretary@ietf.org
Subject: [apps-discuss] Last Call Expired: <draft-ietf-appsawg-rfc5451bis-07.txt>
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 27 Jun 2013 07:24:19 -0000

Please DO NOT reply to this email.

I-D: <draft-ietf-appsawg-rfc5451bis-07.txt>
ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-rfc5451b=
is/

IETF Last Call has ended, and the state has been changed to
Waiting for AD Go-Ahead.


From ietf-secretariat-reply@ietf.org  Thu Jun 27 06:31:47 2013
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 (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80F5821F99E7 for <apps-discuss@ietfa.amsl.com>; Thu, 27 Jun 2013 06:31:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.517
X-Spam-Level: 
X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WcIJBlyA3wpB; Thu, 27 Jun 2013 06:31:47 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 92C7121F9815; Thu, 27 Jun 2013 06:31:20 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
To: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-rfc5451bis@tools.ietf.org, sm+ietf@elandsys.com, apps-discuss@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.51.p2
Message-ID: <20130627133120.24596.48860.idtracker@ietfa.amsl.com>
Date: Thu, 27 Jun 2013 06:31:20 -0700
From: IETF Secretariat <ietf-secretariat-reply@ietf.org>
Subject: [apps-discuss] ID Tracker State Update Notice: <draft-ietf-appsawg-rfc5451bis-07.txt>
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 27 Jun 2013 13:31:47 -0000

State changed to IESG Evaluation from Waiting for AD Go-Ahead
ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-appsawg-rfc5451b=
is/


From barryleiba.mailing.lists@gmail.com  Thu Jun 27 13:16:00 2013
Return-Path: <barryleiba.mailing.lists@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28CAE21F9EFB for <apps-discuss@ietfa.amsl.com>; Thu, 27 Jun 2013 13:16:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.978
X-Spam-Level: 
X-Spam-Status: No, score=-101.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NBoMDed4IndU for <apps-discuss@ietfa.amsl.com>; Thu, 27 Jun 2013 13:15:59 -0700 (PDT)
Received: from mail-ve0-x22a.google.com (mail-ve0-x22a.google.com [IPv6:2607:f8b0:400c:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 86D7E21F9EEA for <apps-discuss@ietf.org>; Thu, 27 Jun 2013 13:15:59 -0700 (PDT)
Received: by mail-ve0-f170.google.com with SMTP id 14so1144408vea.1 for <apps-discuss@ietf.org>; Thu, 27 Jun 2013 13:15:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=2eXlq1xPm74gettebw/eLWV+suzh4sFS/pyxSIXEvFM=; b=KbqkZ7MXh+IJYNRun4s2N8FrpR/nO6tuIGqiWmcIIq2YWUxNFbWbRa8N7XAmVpD6i8 5EsajLuMdHsUsgwLW3GuCLEnBOUWoBV2zqttdLIglVs9v30mn+4CiOnXcA18eTS/jKbC 6rowJtJc2a11sVuNYOxMFddIvvoVOoZxA9jXrU9UYc7Y5/eFcoet9RPwr33vcqv4lkSU eHYF5pzo7JYvx+6PT7DXp0Z8aBkT8LPZnFihn4HtOeYuxrsUuxq4ryJARLFC6usuvCpZ wU9SH8wKZ6WBdIk71Pi+LDJ4WI+Xl+UbuGaoY7fBRIhx5I0FD0/zLWIwVroN+yAupIRl rEtA==
MIME-Version: 1.0
X-Received: by 10.220.181.69 with SMTP id bx5mr4154373vcb.71.1372364159002; Thu, 27 Jun 2013 13:15:59 -0700 (PDT)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.58.137.227 with HTTP; Thu, 27 Jun 2013 13:15:58 -0700 (PDT)
In-Reply-To: <01OVBCWUMFA0007PSE@mauve.mrochek.com>
References: <CAL0qLwaBPhyPEKHPwRurqoCnNy2_tp6rCHe7YzvPonvfN_ALHQ@mail.gmail.com> <20130513153932.91355.qmail@joyce.lan> <01OVBCWUMFA0007PSE@mauve.mrochek.com>
Date: Thu, 27 Jun 2013 16:15:58 -0400
X-Google-Sender-Auth: m0uyPFr9vOpUYaAanwlOeahUC8g
Message-ID: <CAC4RtVCJOrmQBMzRUNSBpjqUJZtYEFKUVL+Bi85bB2=Oi9tLuQ@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
To: Ned Freed <ned.freed@mrochek.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Malformed mail (was Re: Review of: draft-ietf-appsawg-malformed-mail-03)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 27 Jun 2013 20:16:00 -0000

> Content-Transfer-Encoding: 9-bit

NINE-bit?  Oy.

Barry

From johnl@iecc.com  Thu Jun 27 17:49:19 2013
Return-Path: <johnl@iecc.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E89A621F9C73 for <apps-discuss@ietfa.amsl.com>; Thu, 27 Jun 2013 17:49:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -111.199
X-Spam-Level: 
X-Spam-Status: No, score=-111.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xi2KsrGOjl2r for <apps-discuss@ietfa.amsl.com>; Thu, 27 Jun 2013 17:49:15 -0700 (PDT)
Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 8F40921F9C6A for <apps-discuss@ietf.org>; Thu, 27 Jun 2013 17:49:15 -0700 (PDT)
Received: (qmail 10917 invoked from network); 28 Jun 2013 00:49:14 -0000
Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 28 Jun 2013 00:49:14 -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=51ccdd8a.xn--hew.k1306; i=johnl@user.iecc.com; bh=N0itYtKzi99mpy45LwvbxtbNqYJLC7ymRC+FtXnJSsg=; b=qkaajQx7x6KqL0fVZIyj3Ss9jW5RwIioa40l+M6Hh/Bvj8GMrhLEb/e2GIy2yfGW+4gK7KzaVZoEY7DYo0csM0E7OB88vESRZ1KemUFzpR1i1xLcMvkNmONBZxwYn5uVbdKP/6UOJ24aRDLmu6FdR3tK2d47HtO9lGRNyCaNUmMxx1UWO92kFNJ+sC91n8xGghu4IQn1HJJuZqLXoAlD3caeZbsnGRjUjKUZuwprFPbkyVeb1hz7KlpRrH/wV9qZ
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=51ccdd8a.xn--hew.k1306; olt=johnl@user.iecc.com; bh=N0itYtKzi99mpy45LwvbxtbNqYJLC7ymRC+FtXnJSsg=; b=cnWDQqMwzoU6N+XzyzUJxRWSWXtaZ58XMLlk+kiL3tRGMyfM3dKV7FmVukeb6jeoRS/J2jqBDqh7ehMV8YjZc3V0fPLu+8tEHE1FnK/n60AFAo9F1DMplyYaSbjm5YcGg4d9+okH7F+PrTpLgyOi814IuahiuDfr2ONidTIVS5SoQuWU6aw68CCeK+OX6tNo3Zyg+iOi2q7olt5K+NfuiUaJ4WXLzZoPDDR3L+WClIxtCmQqcBAGyyFbGWYOJBqj
Date: 28 Jun 2013 00:48:52 -0000
Message-ID: <20130628004852.77149.qmail@joyce.lan>
From: "John Levine" <johnl@taugh.com>
To: apps-discuss@ietf.org
In-Reply-To: <CAC4RtVCJOrmQBMzRUNSBpjqUJZtYEFKUVL+Bi85bB2=Oi9tLuQ@mail.gmail.com>
Organization: 
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Cc: barryleiba@computer.org
Subject: Re: [apps-discuss] Malformed mail (was Re: Review of: draft-ietf-appsawg-malformed-mail-03)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 28 Jun 2013 00:49:20 -0000

In article <CAC4RtVCJOrmQBMzRUNSBpjqUJZtYEFKUVL+Bi85bB2=Oi9tLuQ@mail.gmail.com> you write:
>> Content-Transfer-Encoding: 9-bit
>
>NINE-bit?  Oy.

You got something against Multics?

R's,
John

From dhc@dcrocker.net  Thu Jun 27 20:22:54 2013
Return-Path: <dhc@dcrocker.net>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C65821F89A6 for <apps-discuss@ietfa.amsl.com>; Thu, 27 Jun 2013 20:22:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FmXYr+FFF5Q2 for <apps-discuss@ietfa.amsl.com>; Thu, 27 Jun 2013 20:22:37 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id F328021F9CC6 for <apps-discuss@ietf.org>; Thu, 27 Jun 2013 20:22:35 -0700 (PDT)
Received: from [192.168.1.116] (cpe-76-93-143-183.san.res.rr.com [76.93.143.183]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r5S3MThF030767 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 27 Jun 2013 20:22:32 -0700
Message-ID: <51CD016E.6020109@dcrocker.net>
Date: Thu, 27 Jun 2013 20:22:22 -0700
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: John Levine <johnl@taugh.com>
References: <20130628004852.77149.qmail@joyce.lan>
In-Reply-To: <20130628004852.77149.qmail@joyce.lan>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Thu, 27 Jun 2013 20:22:32 -0700 (PDT)
Cc: barryleiba@computer.org, apps-discuss@ietf.org
Subject: Re: [apps-discuss] Malformed mail (was Re: Review of: draft-ietf-appsawg-malformed-mail-03)
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: General discussion of application-layer protocols <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, 28 Jun 2013 03:22:54 -0000

On 6/27/2013 5:48 PM, John Levine wrote:
> In article <CAC4RtVCJOrmQBMzRUNSBpjqUJZtYEFKUVL+Bi85bB2=Oi9tLuQ@mail.gmail.com> you write:
>>> Content-Transfer-Encoding: 9-bit
>>
>> NINE-bit?  Oy.
>
> You got something against Multics?


IASTR Tenex could do that, too.

d/


-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

From vesely@tana.it  Fri Jun 28 02:16:55 2013
Return-Path: <vesely@tana.it>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 606E021F9590 for <apps-discuss@ietfa.amsl.com>; Fri, 28 Jun 2013 02:16:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.719
X-Spam-Level: 
X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GW7b9cxggibX for <apps-discuss@ietfa.amsl.com>; Fri, 28 Jun 2013 02:16:45 -0700 (PDT)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 9A21F21F9C44 for <apps-discuss@ietf.org>; Fri, 28 Jun 2013 02:16:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=beta; t=1372410972; bh=32xIMSLxNC5SG2sBDGCkG2/QLBNj1EWWxdWblEioBUM=; l=680; h=Date:From:To:References:In-Reply-To; b=Dm5YipLc4p17IqvIiJk0hYTVsq03o4P7dCG+DJOMUA8vOEMEc1tCiPvaDpn2RCBbh 8qmt6Dq2FYyLePNUFVSHcV5D3EibePdVeX23E8S/gzeDAZrEAo59p7nbABGawxJJij fL/LctJClCj1kDLILMQVV1KotnlQgaiIOegoLWvs=
Authentication-Results: tana.it; auth=pass (details omitted)
Received: from [172.25.197.98] (pcale.tana [172.25.197.98]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by wmail.tana.it with ESMTPSA; Fri, 28 Jun 2013 11:16:12 +0200 id 00000000005DC111.0000000051CD545C.00003BA5
Message-ID: <51CD545C.3050804@tana.it>
Date: Fri, 28 Jun 2013 11:16:12 +0200
From: Alessandro Vesely <vesely@tana.it>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7
MIME-Version: 1.0
To: apps-discuss@ietf.org
References: <20130625213716.35943.qmail@joyce.lan> <alpine.LSU.2.00.1306261147020.9686@hermes-2.csi.cam.ac.uk>
In-Reply-To: <alpine.LSU.2.00.1306261147020.9686@hermes-2.csi.cam.ac.uk>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [apps-discuss] Remember the MX 0 . draft?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 28 Jun 2013 09:16:55 -0000

> 
>>>>>   nomailhere.example. MX 0 .
>>
>>> I did some experiements:

I've been too lazy to do it, because there's actually no mx record
labeled nomailhere.example.  Would it be too much of a burden to publish
it, there or at some other example domain?

(www.example.org not only has an address, but also an http server:
* Connected to www.example.org (192.0.43.10) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.29.0
> Host: www.example.org
> Accept: */*
>
* HTTP 1.0, assume close after body
< HTTP/1.0 302 Found
< Location: http://example.iana.org
< Server: BigIP
* HTTP/1.0 connection set to keep alive!
< Connection: Keep-Alive
< Content-Length: 0
)

From internet-drafts@ietf.org  Fri Jun 28 10:46:11 2013
Return-Path: <internet-drafts@ietf.org>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7DCB21F9C47; Fri, 28 Jun 2013 10:46:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.203
X-Spam-Level: 
X-Spam-Status: No, score=-102.203 tagged_above=-999 required=5 tests=[AWL=0.397, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZmMnv8a2qaCp; Fri, 28 Jun 2013 10:46:11 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C76A021F9C3E; Fri, 28 Jun 2013 10:45:58 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.51.p2
Message-ID: <20130628174558.29205.14147.idtracker@ietfa.amsl.com>
Date: Fri, 28 Jun 2013 10:45:58 -0700
Cc: apps-discuss@ietf.org
Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc5451bis-08.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 28 Jun 2013 17:46:12 -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           : Message Header Field for Indicating Message Authenticati=
on Status
	Author(s)       : Murray S. Kucherawy
	Filename        : draft-ietf-appsawg-rfc5451bis-08.txt
	Pages           : 47
	Date            : 2013-06-28

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

   This document is a candidate for Internet Standard status.  [RFC
   Editor: Please delete this notation, as I imagine it will be
   indicated some other way.]


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-appsawg-rfc5451bis

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-appsawg-rfc5451bis-08

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-rfc5451bis-08


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From internet-drafts@ietf.org  Fri Jun 28 10:46:12 2013
Return-Path: <internet-drafts@ietf.org>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5087221F9C46 for <apps-discuss@ietfa.amsl.com>; Fri, 28 Jun 2013 10:46:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.104
X-Spam-Level: 
X-Spam-Status: No, score=-101.104 tagged_above=-999 required=5 tests=[AWL=-0.723, BAYES_00=-2.599, NO_RELAYS=-0.001, TVD_SPACE_RATIO=2.219, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3DRCPU-GsP2l; Fri, 28 Jun 2013 10:46:11 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 06C3D21F9C41; Fri, 28 Jun 2013 10:45:59 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-rfc5451bis@tools.ietf.org, sm+ietf@elandsys.com, apps-discuss@ietf.org, barryleiba@computer.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.51.p2
Message-ID: <20130628174558.29205.98440.idtracker@ietfa.amsl.com>
Date: Fri, 28 Jun 2013 10:45:58 -0700
Subject: [apps-discuss] New Version Notification - draft-ietf-appsawg-rfc5451bis-08.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 28 Jun 2013 17:46:12 -0000

A new version (-08) has been submitted for draft-ietf-appsawg-rfc5451bis:
http://www.ietf.org/internet-drafts/draft-ietf-appsawg-rfc5451bis-08.txt


The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-appsawg-rfc5451bis/

Diff from previous version:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-rfc5451bis-08

IETF Secretariat.


From barryleiba@gmail.com  Fri Jun 28 10:46:18 2013
Return-Path: <barryleiba@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1095E21F9C39 for <apps-discuss@ietfa.amsl.com>; Fri, 28 Jun 2013 10:46:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.753
X-Spam-Level: 
X-Spam-Status: No, score=-101.753 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b1q9SnJHJmsn for <apps-discuss@ietfa.amsl.com>; Fri, 28 Jun 2013 10:46:17 -0700 (PDT)
Received: from mail-qc0-x22b.google.com (mail-qc0-x22b.google.com [IPv6:2607:f8b0:400d:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 9077B21F9C2C for <apps-discuss@ietf.org>; Fri, 28 Jun 2013 10:46:11 -0700 (PDT)
Received: by mail-qc0-f171.google.com with SMTP id n1so1532164qcw.16 for <apps-discuss@ietf.org>; Fri, 28 Jun 2013 10:46:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=wpbFyxf1g8mDKjeXEXH4HKL+rzkK5c66WxWzqfi7/nQ=; b=mvpkFE3Y/SetvwR1zaIHcktjul8jOnxj2oSi7hnuPSJJ+OGsQmc48aQirae8BJ5YAH s4ApYUQiw+pcnQJ7Ijmb+RGay9KlIFDT79a9EdmZy032YZOPfZ1pkcvf/2aLnyMeV8D3 YX2t6KlavTTOr5QMiHVcaQLsscBxYvxVYD3GFAOKsqUV4pn/NnugU4zvrrZbhnyIZ7ME R6flg9MAwHyofHYYs0cxOyeCWKut37/zTAlW/Lpjy/JbquKEhaxcpzDjMib+B7mXCnJH eKEqUtvGYyDIBoiWtfnoH16NP15I5H2OlQoQwcqTTgCK/JfD8aksUoqRNX8+Xt2DFzj4 ctDw==
MIME-Version: 1.0
X-Received: by 10.49.132.69 with SMTP id os5mr18863035qeb.48.1372441563727; Fri, 28 Jun 2013 10:46:03 -0700 (PDT)
Sender: barryleiba@gmail.com
Received: by 10.224.0.139 with HTTP; Fri, 28 Jun 2013 10:46:03 -0700 (PDT)
Date: Fri, 28 Jun 2013 13:46:03 -0400
X-Google-Sender-Auth: Ef0TWy1OrnUMufzZ13fj7LOxtas
Message-ID: <CALaySJ+s610bC2epuKXvM-r3XLfwH7xTQAJqjEJHwm3Jy0b6Og@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
To: "dmarc@ietf.org" <dmarc@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1
X-Mailman-Approved-At: Fri, 28 Jun 2013 10:51:50 -0700
Cc: Russ Housley <housley@vigilsec.com>
Subject: [apps-discuss] DMARC BoF at IETF 87, Berlin
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 28 Jun 2013 17:46:18 -0000

(BCC to apps-discuss)

As some of you may have seen from the preliminary agenda, the App Area
will have one BoF in Berlin: Domain-based Message Authentication,
Reporting & Conformance (DMARC).  See the BoF wiki for details:
http://trac.tools.ietf.org/bof/trac/wiki

The BoF is currently scheduled for Tuesday afternoon, 30 July, from
15:20 to 16:50 Berlin time... though that could change as the IETF
meeting agenda is finalized.

Russ Housley (CC) has agreed to chair the BoF.  Russ is experienced
with what's needed to have a successful BoF, and will make sure we
stay on the right track to answer the questions we need to answer in
order to move forward with a working group, if that's the outcome of
the BoF.  He'll be working with the BoF proponents on the BoF agenda
over the next weeks.

Barry, Applications AD

From phluid61@gmail.com  Tue Jun 25 18:10:57 2013
Return-Path: <phluid61@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E17ED21F9E0D for <apps-discuss@ietfa.amsl.com>; Tue, 25 Jun 2013 18:10:57 -0700 (PDT)
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=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PdPSiYZ5XLsd for <apps-discuss@ietfa.amsl.com>; Tue, 25 Jun 2013 18:10:57 -0700 (PDT)
Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id F335721F9E07 for <apps-discuss@ietf.org>; Tue, 25 Jun 2013 18:10:56 -0700 (PDT)
Received: by mail-la0-f49.google.com with SMTP id ea20so12711352lab.22 for <apps-discuss@ietf.org>; Tue, 25 Jun 2013 18:10:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=IBU8v2MiMPMVwsTgkCRtVED8YVSjs6PawsAx5K2EaTk=; b=FvBr6QYPLKQuX2kSNwrppdxtY/CtgblsdhpF7uYVP/2Ay5RVhHj48dlqFwxNtni+Hj UH4Ui1MaS2Zph/TElxGq5haUnX0pazeA5UbGYQICNJsJ/2kAavbgwW5wj/z58EWXs/9s cEeAjY1DMq5LJaUBxEXtr9ZdFvdBbUJkQgbhGg8JMdbmppOhMsldcW4qoYHDshXU5G0F 4/UKnqyRh29XyHsIxRTcXJlwYc/RLuVve1IgpunAeALkOp8fqC5/5ssTMALEVV9pvJJH JCVfexCM/TRvWSYSzjNCePAq9LFT6eja8UcqUWlbfyGl45fVlDsXGIrErXQwLRTsk+gw 96eg==
MIME-Version: 1.0
X-Received: by 10.152.23.168 with SMTP id n8mr682608laf.88.1372209054538; Tue, 25 Jun 2013 18:10:54 -0700 (PDT)
Sender: phluid61@gmail.com
Received: by 10.114.200.103 with HTTP; Tue, 25 Jun 2013 18:10:54 -0700 (PDT)
In-Reply-To: <CAL0qLwYNx17z42_pNucbPGY9ZvMx9yV9hnD74Nfhje_Rx9rcaw@mail.gmail.com>
References: <CACweHNCTSZ3xvZPLeahZmJVg6pYheqvPfGxa_GPc1O9Aomi9hw@mail.gmail.com> <CAL0qLwYNx17z42_pNucbPGY9ZvMx9yV9hnD74Nfhje_Rx9rcaw@mail.gmail.com>
Date: Wed, 26 Jun 2013 11:10:54 +1000
X-Google-Sender-Auth: 26oqDXL09lngNl70sKE4EOv9mvg
Message-ID: <CACweHNBQJRXaS5EZn-WEg7RSe_CMYjF-eTrRd8n1nCAEXmAyqQ@mail.gmail.com>
From: Matthew Kerwin <matthew@kerwin.net.au>
To: "Murray S. Kucherawy" <superuser@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
X-Mailman-Approved-At: Fri, 28 Jun 2013 10:52:06 -0700
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] File URI Scheme
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 26 Jun 2013 01:10:58 -0000

On 26 June 2013 04:24, Murray S. Kucherawy <superuser@gmail.com> wrote:
> On Mon, Jun 24, 2013 at 8:34 PM, Matthew Kerwin <matthew@kerwin.net.au>
> wrote:
>>
>> Would you please consider creating a draft for the file: URI scheme
>> (or taking over my existing draft); or if not, point me to some
>> resources or discussions about why the file scheme seems to have gone
>> out of vogue?
>>
>> The current revision of my draft is
>> <http://tools.ietf.org/html/draft-kerwin-file-scheme-03> , and the
>> working copy is on github
>> <https://github.com/phluid61/file-uri-scheme>
>>
>
> By "creating a draft", are you asking APPSAWG to adopt yours, or are you
> asking us to come up with something else and process that?
>
> -MSK, APPSAWG co-chair
>

I guess I was leaving that up to the WG to decide, but my proposal is
to adopt my draft and build on it from there.

-- 
  Matthew Kerwin, B.Sc (CompSci) (Hons)
  http://matthew.kerwin.net.au/

From matthewlmcclure@gmail.com  Wed Jun 26 05:04:27 2013
Return-Path: <matthewlmcclure@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7054311E814E for <apps-discuss@ietfa.amsl.com>; Wed, 26 Jun 2013 05:04:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.202
X-Spam-Level: 
X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xrkq8EdENE4F for <apps-discuss@ietfa.amsl.com>; Wed, 26 Jun 2013 05:04:26 -0700 (PDT)
Received: from mail-qa0-x22f.google.com (mail-qa0-x22f.google.com [IPv6:2607:f8b0:400d:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 3915C11E80D9 for <apps-discuss@ietf.org>; Wed, 26 Jun 2013 05:04:26 -0700 (PDT)
Received: by mail-qa0-f47.google.com with SMTP id i13so1484893qae.6 for <apps-discuss@ietf.org>; Wed, 26 Jun 2013 05:04:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=7qav/hWfTPSlQqK9kOn4lHO8tcJCbNSBjFj3/oKnS/Q=; b=mbEobt8jgMV/aUS889eQb5ucwU04u9rE6WFbn7BBExxnsVvazbrciTkQHLfznrxYBj +YJfCPj0M/Iz4u3cVUuOIbd2vPj9eVJoKvNZeYyUFMijHflwi0OCnms2xCzt71TYDTTG A4y5Z/s8rxqov+3iCai+Ci4gO19eya3MGwQQUBaDnPDToF2bGXg8/urPIuUp8AIjAFIJ NwWMLJDRwenpotD5xRPhy6Hut8KaROJjmw0aAAVXITGmd/RGCHl0RBHBIOkdVO5jKg+H XR5hyEKeoMg3QC2CcPwU5HEC3TPK8j37Qlss28d6rcmfYvtnElDBbwfT5NQywL9ugHvZ h4ww==
X-Received: by 10.224.177.201 with SMTP id bj9mr5018106qab.14.1372248264606; Wed, 26 Jun 2013 05:04:24 -0700 (PDT)
Received: from [10.118.14.13] (mobile-198-228-195-086.mycingular.net. [198.228.195.86]) by mx.google.com with ESMTPSA id k7sm12593405qad.7.2013.06.26.05.04.22 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 26 Jun 2013 05:04:23 -0700 (PDT)
References: <20130610033804.19451.29465.idtracker@ietfa.amsl.com> <E6062DBC-CD7B-47CA-A6F0-5E7D64C0DB55@mnot.net> <51B7AEAF.20404@berkeley.edu> <4CD4652F-4EAF-4258-A6EB-577019018D2C@mnot.net> <1A136C4D-4F0C-446F-B307-D53FB9A40622@cs.tcd.ie> <8BE038EC-1580-4D27-ABBA-1890EEFD4853@mnot.net> <51C9C91D.90206@berkeley.edu> <4C2FD8A7-4F3E-433B-A7F6-F0BD751D31AD@mnot.net>
Mime-Version: 1.0 (1.0)
In-Reply-To: <4C2FD8A7-4F3E-433B-A7F6-F0BD751D31AD@mnot.net>
Content-Type: multipart/alternative; boundary=Apple-Mail-619BF606-D466-458D-BDE3-C715CED84FD6
Content-Transfer-Encoding: 7bit
Message-Id: <7E03AF26-CD95-46D1-AC6D-6D68B92B7504@gmail.com>
X-Mailer: iPhone Mail (10B329)
From: Matt McClure <matthewlmcclure@gmail.com>
Date: Wed, 26 Jun 2013 08:04:16 -0400
To: Mark Nottingham <mnot@mnot.net>
X-Mailman-Approved-At: Fri, 28 Jun 2013 10:52:26 -0700
Cc: IETF Apps Discuss <apps-discuss@ietf.org>, REST-Discuss <rest-discuss@yahoogroups.com>
Subject: Re: [apps-discuss] [rest-discuss] Re: New Version Notification for draft-nottingham-link-hint-00.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 26 Jun 2013 12:14:02 -0000

--Apple-Mail-619BF606-D466-458D-BDE3-C715CED84FD6
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

On Jun 26, 2013, at 2:51 AM, Mark Nottingham <mnot@mnot.net> wrote:
> Can you suggest how to convey the information without using structured dat=
a?
>=20
Is it just an issue of terminology? If so, using the name of an abstract dat=
a type instead of the JSON name for it is an option. Something like associat=
ive array, map, or dictionary.

--=20
http://matthewlmcclure.com
http://about.mapmyfitness.com__,_._,___=

--Apple-Mail-619BF606-D466-458D-BDE3-C715CED84FD6
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div style=3D"-webkit-text-size-adjust: aut=
o; ">On Jun 26, 2013, at 2:51 AM, Mark Nottingham &lt;<a href=3D"mailto:mnot=
@mnot.net">mnot@mnot.net</a>&gt; wrote:</div><blockquote type=3D"cite" style=
=3D"-webkit-text-size-adjust: auto; "><div>














<span style=3D"display:none">&nbsp;</span>

<!--~-|**|PrettyHtmlStartT|**|-~-->
<div id=3D"ygrp-mlmsg" style=3D"position:relative;">
  <div id=3D"ygrp-msg" style=3D"z-index: 1;">
<!--~-|**|PrettyHtmlEndT|**|-~-->

    <div id=3D"ygrp-text">
     =20
     =20
      <p>Can you suggest how to convey the information without using structu=
red data?<br></p></div></div></div></div></blockquote><div><span style=3D"-w=
ebkit-text-size-adjust: auto;">Is it just an issue of terminology? If so, us=
ing the name of an abstract data type instead of the JSON name for it is an o=
ption. Something like&nbsp;</span><span style=3D"-webkit-text-size-adjust: a=
uto; background-color: rgba(255, 255, 255, 0);"><b style=3D"margin: 0px; pad=
ding: 0px; border: 0px; font: inherit; vertical-align: baseline; ">associati=
ve array</b>,&nbsp;<b style=3D"margin: 0px; padding: 0px; border: 0px; font:=
 inherit; vertical-align: baseline; ">map</b>, or&nbsp;<b style=3D"margin: 0=
px; padding: 0px; border: 0px; font: inherit; vertical-align: baseline; ">di=
ctionary.</b></span></div><div><br></div><span style=3D"-webkit-tap-highligh=
t-color: rgba(26, 26, 26, 0.296875); -webkit-composition-fill-color: rgba(17=
5, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0=
.230469); -webkit-text-size-adjust: auto; ">--&nbsp;</span><div style=3D"-we=
bkit-tap-highlight-color: rgba(26, 26, 26, 0.296875); -webkit-composition-fi=
ll-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rg=
ba(77, 128, 180, 0.230469); -webkit-text-size-adjust: auto; "><a href=3D"htt=
p://matthewlmcclure.com">http://matthewlmcclure.com</a><div><a href=3D"http:=
//about.mapmyfitness.com">http://about.mapmyfitness.com</a><span style=3D"co=
lor: rgb(255, 255, 255); ">__,_._,___</span></div></div></body></html>=

--Apple-Mail-619BF606-D466-458D-BDE3-C715CED84FD6--

From sm@elandsys.com  Fri Jun 28 11:20:37 2013
Return-Path: <sm@elandsys.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EFA821F9C37 for <apps-discuss@ietfa.amsl.com>; Fri, 28 Jun 2013 11:20:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sjL9pF6byI1w for <apps-discuss@ietfa.amsl.com>; Fri, 28 Jun 2013 11:20:36 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E58521F9C33 for <apps-discuss@ietf.org>; Fri, 28 Jun 2013 11:20:35 -0700 (PDT)
Received: from SUBMAN.elandsys.com ([197.224.129.81]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r5SIK5tE027647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Jun 2013 11:20:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1372443620; bh=Upwlf6GkbVBN5vAS+TLVcMACNB4TyqjjNw9Bd18cXwU=; h=Date:To:From:Subject:Cc; b=0AL+r+4ryXdQ+vSiglzsxhahi2y94Zvyz1APH/Zw9FZfm9w96VlgDfKFl66ov+sR+ Zy7P+ld5pRNAIFRGKkz9sMZ4WXdUZ5yOKdl5MCUl+3Um6ZYIKriAiA7xxj3Z+4kEWy FEarWXMsVGVtU5ZEiGNwrzvovj366afnu8jhLxKU=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1372443620; i=@elandsys.com; bh=Upwlf6GkbVBN5vAS+TLVcMACNB4TyqjjNw9Bd18cXwU=; h=Date:To:From:Subject:Cc; b=mFlMZX9VMcoqwjLq1IF8V5hEWl1yZk4T/YCYixZjcEkYtuQ+tndGj8jmkzI+VjW2G NQ51Cm5vup8WmP8Wp93ajVFP5IHl7t0SbXMluPVPbgLfFH8y2euZQEfS/vD4cXapMg na6ztGNzYRdHOc9pb+GiHffMzrm1rx06mPRknfGE=
Message-Id: <6.2.5.6.2.20130628110754.0cd605b0@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Fri, 28 Jun 2013 11:19:29 -0700
To: apps-discuss@ietf.org, Barry Leiba <barryleiba@computer.org>
From: S Moonesamy <sm+ietf@elandsys.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: Bjoern Hoehrmann <derhoermi@gmx.net>
Subject: [apps-discuss] Summary of Last Call for draft-ietf-appsawg-rfc5451bis-07
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 28 Jun 2013 18:20:37 -0000

Hello,

This is a summary of the comments received during the Last Call of 
draft-ietf-appsawg-rfc5451bis-07.

I didn't see any comments on ietf@ietf.org.  There was some editorial 
comments from Bjoern Hoehrmann ( 
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg09721.html 
).  There was a comment from Franck Martin about exposing the results 
of a SMTP TLS transaction ( 
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg09736.html ).

I'll consider that all the Last Call comments have been addressed in 
draft-ietf-appsawg-rfc5451bis-08.  Please email me if you consider 
that your comments have not been addressed.

Regards,
S. Moonesamy (as document shepherd)


From scott@kitterman.com  Fri Jun 28 12:28:35 2013
Return-Path: <scott@kitterman.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C29521F84E7 for <apps-discuss@ietfa.amsl.com>; Fri, 28 Jun 2013 12:28:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bwRtSnz1+n4s for <apps-discuss@ietfa.amsl.com>; Fri, 28 Jun 2013 12:28:30 -0700 (PDT)
Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 503BD21F848A for <apps-discuss@ietf.org>; Fri, 28 Jun 2013 12:28:30 -0700 (PDT)
Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 52E1820E40F0; Fri, 28 Jun 2013 15:28:29 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1372447709; bh=tDygs8/xbOK26uUfLWvBN4AkrYi7oNhZG2rUciUyN3s=; h=From:To:Subject:Date:In-Reply-To:References:From; b=dqjlcLC3ASOIrOs8yfO8++EgctV/KPVpMyB8f123lbIvWzTt4jiYgss9mkz5cqbPo jx5aUb+nlp5iwBEF7a2pYHTkL8SK1yrlHtL4CiOhtMNwTjFutZEP1ZW+4a2/tEiO+E C9K200VVBpLEefcn/X5gvxdFTSJQcbfRZ0hB8YvM=
Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 34BF320E4085;  Fri, 28 Jun 2013 15:28:28 -0400 (EDT)
From: Scott Kitterman <scott@kitterman.com>
To: apps-discuss@ietf.org
Date: Fri, 28 Jun 2013 15:28:27 -0400
Message-ID: <2039041.H0Q2G1vWB3@scott-latitude-e6320>
User-Agent: KMail/4.10.4 (Linux/3.8.0-25-generic; KDE/4.10.4; i686; ; )
In-Reply-To: <20130628174558.29205.14147.idtracker@ietfa.amsl.com>
References: <20130628174558.29205.14147.idtracker@ietfa.amsl.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-AV-Checked: ClamAV using ClamSMTP
Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc5451bis-08.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 28 Jun 2013 19:28:35 -0000

On Friday, June 28, 2013 10:45:58 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           : Message Header Field for Indicating Message
> Authentication Status Author(s)       : Murray S. Kucherawy
> 	Filename        : draft-ietf-appsawg-rfc5451bis-08.txt
> 	Pages           : 47
> 	Date            : 2013-06-28

It doesn't look t me like this change is correct:

	C.7. Comment-Heavy Example	
				
	The formal syntax permits comments within the content in a number of
	places. For the sake of illustration, this example is also legal:
				
	Authentication-Results: foo.example.net (foobar) 1 (baz);
	dkim (Because I like it) / 1 (One yay) = (wait for it) fail
	policy (A dot can go here) . (like that) expired
	(this surprised me) = (as I wasn't expecting it) 1362471462

	C.7. Comment-Heavy Example	
				
	The formal syntax permits comments within the content in a number of
	places. For the sake of illustration, this example is also legal:
				
	Authentication-Results: foo.example.net (foobar) 1 (baz);
	dkim (Because I like it) 1 (One yay) = (wait for it) fail
	policy (A dot can go here) . (like that) expired
	(this surprised me) = (as I wasn't expecting it) 1362471462

The ABNF says:

method = Keyword [ [CFWS] "/" [CFWS] method-version ]

So isn't the "/" mandatory with the method-version?

Scott K

From johnl@iecc.com  Fri Jun 28 12:55:17 2013
Return-Path: <johnl@iecc.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 880F021F9B2C for <apps-discuss@ietfa.amsl.com>; Fri, 28 Jun 2013 12:55:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.9
X-Spam-Level: 
X-Spam-Status: No, score=-106.9 tagged_above=-999 required=5 tests=[AWL=4.300,  BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zsNVVP8Rp5ua for <apps-discuss@ietfa.amsl.com>; Fri, 28 Jun 2013 12:55:13 -0700 (PDT)
Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 0C36321F9B0F for <apps-discuss@ietf.org>; Fri, 28 Jun 2013 12:55:12 -0700 (PDT)
Received: (qmail 89224 invoked from network); 28 Jun 2013 19:55:10 -0000
Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 28 Jun 2013 19:55:10 -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=51cdea1e.xn--i8sz2z.k1306; i=johnl@user.iecc.com; bh=gL2iutk2vZotMnHNNCv5rxsd6rFKERibiqPWrio2YLs=; b=g+vI6OPXUFKlwtnyBDiKdLpJmeoYv6LIRxQ97KJ0b4K8mCdWdR3ywCuoqvmv5Ev2A1RSSjezl9+X5iPOZyetPuUzATZ8wbaMKAHftIIYtaP2SQUINxtnmDlhmox4jdSjDXR2ceXmdhmr8+vab+T7BGzin17qu48WiXcKFQdXnY6A3KXoNLz/Sh6dkbA5bbhnUWzNP8YJIQf05KQok0PskUDfwglfhi9i93Qw27yFFmbN7kziQRkA1U9IhIvDMqiu
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=51cdea1e.xn--i8sz2z.k1306; olt=johnl@user.iecc.com; bh=gL2iutk2vZotMnHNNCv5rxsd6rFKERibiqPWrio2YLs=; b=Ci7h23wSPEjAvC3fTFKV0CchbLQ5s5z6O+CT6Vv48Siqechs4FV1AcZp1pYT/v6tffHCZFhdlYv9xoWEteSdm3NZ0jI/9K2T6PyJKpMyowQkwtb/58b154X1bVH1OohFlBapWVFkWedV9LCznwWrr/8XJ7QtjO1l2oBC0034bXnSNN6zm29LGzfmtyRQ1ZnqTts8x/D1JZEWEv3GN/g+fMOWtZb9FXZFTkPQMUzGWUcT/AW6BpaLeXEZC7P1F1GN
Date: 28 Jun 2013 19:54:48 -0000
Message-ID: <20130628195448.84607.qmail@joyce.lan>
From: "John Levine" <johnl@taugh.com>
To: apps-discuss@ietf.org
In-Reply-To: <2039041.H0Q2G1vWB3@scott-latitude-e6320>
Organization: 
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Cc: scott@kitterman.com
Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc5451bis-08.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 28 Jun 2013 19:55:17 -0000

>	Authentication-Results: foo.example.net (foobar) 1 (baz);
>	dkim (Because I like it) 1 (One yay) = (wait for it) fail
>	policy (A dot can go here) . (like that) expired
>	(this surprised me) = (as I wasn't expecting it) 1362471462
>
>The ABNF says:
>
>method = Keyword [ [CFWS] "/" [CFWS] method-version ]
>
>So isn't the "/" mandatory with the method-version?

Yes, that's a recent change to avoid ambiguity where foo1 might be a
method called foo1 or might be method foo version 1.  Looks like
Murray missed updating the example.



From scott@kitterman.com  Fri Jun 28 13:00:43 2013
Return-Path: <scott@kitterman.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A82821F9C31 for <apps-discuss@ietfa.amsl.com>; Fri, 28 Jun 2013 13:00:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nf03DASIjoJ8 for <apps-discuss@ietfa.amsl.com>; Fri, 28 Jun 2013 13:00:38 -0700 (PDT)
Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 84F0621F9C2B for <apps-discuss@ietf.org>; Fri, 28 Jun 2013 13:00:38 -0700 (PDT)
Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id ACB4C20E40F0; Fri, 28 Jun 2013 16:00:37 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1372449637; bh=t0NkK06+AkpGs/gpafSuWHRXHBcnobg1x5F890zHPtQ=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Z+y9swgSuxGiZfPCPG24CeZqbGRxCjfQAbmiGcVBFyQP//BJrgMO6q9uH6NpFvgwO lF5m/KR7B9NrhwfhgIf8DKERiVBKdzXXIYS3OGmXFdSBAhDh4+SKE5N7krupr9/c59 AEMA1OSnacf4q68knrrzopsqU2knIB8yaBXrDQzM=
Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 9063420E4085;  Fri, 28 Jun 2013 16:00:37 -0400 (EDT)
From: Scott Kitterman <scott@kitterman.com>
To: apps-discuss@ietf.org
Date: Fri, 28 Jun 2013 16:00:34 -0400
Message-ID: <1890595.pPFvXvIWb5@scott-latitude-e6320>
User-Agent: KMail/4.10.4 (Linux/3.8.0-25-generic; KDE/4.10.4; i686; ; )
In-Reply-To: <20130628195448.84607.qmail@joyce.lan>
References: <20130628195448.84607.qmail@joyce.lan>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-AV-Checked: ClamAV using ClamSMTP
Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc5451bis-08.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 28 Jun 2013 20:00:43 -0000

On Friday, June 28, 2013 07:54:48 PM John Levine wrote:
> >	Authentication-Results: foo.example.net (foobar) 1 (baz);
> >	dkim (Because I like it) 1 (One yay) = (wait for it) fail
> >	policy (A dot can go here) . (like that) expired
> >	(this surprised me) = (as I wasn't expecting it) 1362471462
> >
> >The ABNF says:
> >
> >method = Keyword [ [CFWS] "/" [CFWS] method-version ]
> >
> >So isn't the "/" mandatory with the method-version?
> 
> Yes, that's a recent change to avoid ambiguity where foo1 might be a
> method called foo1 or might be method foo version 1.  Looks like
> Murray missed updating the example.

It's the other way around.  -08 removes the "/", so think it changed in 
exactly the wrong way.

Scott K

From superuser@gmail.com  Fri Jun 28 14:45:38 2013
Return-Path: <superuser@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62DAA21F9CD8 for <apps-discuss@ietfa.amsl.com>; Fri, 28 Jun 2013 14:45:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ChpGFFxtKM2 for <apps-discuss@ietfa.amsl.com>; Fri, 28 Jun 2013 14:45:38 -0700 (PDT)
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 B20CD21F9CD7 for <apps-discuss@ietf.org>; Fri, 28 Jun 2013 14:45:37 -0700 (PDT)
Received: by mail-we0-f177.google.com with SMTP id m19so1561937wev.8 for <apps-discuss@ietf.org>; Fri, 28 Jun 2013 14:45:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pe8gL1YRP14TonuQVz6RCbiKMv6yeT1+HYhjr1ECF5U=; b=Xf8ILvU6ve/OqQexxsX5UOpZMsvMdUvRXyidGOdvsyguwLyMqDsEaM44DfBwtfjaIm 5MsRPZewBswAtvR6z0juwSdzp6FJ8ma5Hm3cn5J66gWYqeaJQrH9b6wxmRqDuMAbEOAH bbioTrkNWH08tNRGUmno3EUy0ZBeOL3DPsI+q/oQhM17z78SvM3HbI9+5vyRa9qvfYkE +qj+oViuWuMfQaAM8Ld7QX2rTmRtTfX36CEyAEP2MANlFnYVn4lsw+35dcgpatQRotdS VenWR8Wvy0Coa6oeYDtRFtPhNUVyoDLXxJgX/SMGFLIngPhrAoXJP0ppy5kickpsnW85 GAEw==
MIME-Version: 1.0
X-Received: by 10.180.189.102 with SMTP id gh6mr3728104wic.19.1372455935581; Fri, 28 Jun 2013 14:45:35 -0700 (PDT)
Received: by 10.180.90.16 with HTTP; Fri, 28 Jun 2013 14:45:35 -0700 (PDT)
In-Reply-To: <1890595.pPFvXvIWb5@scott-latitude-e6320>
References: <20130628195448.84607.qmail@joyce.lan> <1890595.pPFvXvIWb5@scott-latitude-e6320>
Date: Fri, 28 Jun 2013 14:45:35 -0700
Message-ID: <CAL0qLwZh0vgWxAFbeoSn7EOF4Hc7z3Zh7-=arnTAi-hiSuFoMg@mail.gmail.com>
From: "Murray S. Kucherawy" <superuser@gmail.com>
To: Scott Kitterman <scott@kitterman.com>
Content-Type: multipart/alternative; boundary=001a11c3436a82d54a04e03dcc65
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc5451bis-08.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 28 Jun 2013 21:45:38 -0000

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

On Fri, Jun 28, 2013 at 1:00 PM, Scott Kitterman <scott@kitterman.com>wrote:

> > Yes, that's a recent change to avoid ambiguity where foo1 might be a
> > method called foo1 or might be method foo version 1.  Looks like
> > Murray missed updating the example.
>
> It's the other way around.  -08 removes the "/", so think it changed in
> exactly the wrong way.
>
>
>
Scott's correct; I over-undid the controversial change that got reverted.
I'll clean it up and post again.  Apologies for the noise.

-MSK

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

<div dir=3D"ltr">On Fri, Jun 28, 2013 at 1:00 PM, Scott Kitterman <span dir=
=3D"ltr">&lt;<a href=3D"mailto:scott@kitterman.com" target=3D"_blank">scott=
@kitterman.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div cla=
ss=3D"gmail_quote">
<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">&gt; Yes, that&#39;s a rec=
ent change to avoid ambiguity where foo1 might be a<br>
&gt; method called foo1 or might be method foo version 1. =A0Looks like<br>
&gt; Murray missed updating the example.<br>
<br>
</div>It&#39;s the other way around. =A0-08 removes the &quot;/&quot;, so t=
hink it changed in<br>
exactly the wrong way.<br>
<br><br></blockquote><div><br></div><div>Scott&#39;s correct; I over-undid =
the controversial change that got reverted.=A0 I&#39;ll clean it up and pos=
t again.=A0 Apologies for the noise.<br><br>-MSK <br></div></div><br></div>
</div>

--001a11c3436a82d54a04e03dcc65--

From internet-drafts@ietf.org  Fri Jun 28 14:49:03 2013
Return-Path: <internet-drafts@ietf.org>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A71CA21F9D08; Fri, 28 Jun 2013 14:49:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.245
X-Spam-Level: 
X-Spam-Status: No, score=-102.245 tagged_above=-999 required=5 tests=[AWL=0.355, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hkkDz69yYfc0; Fri, 28 Jun 2013 14:49:03 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E7DEE21F9CEE; Fri, 28 Jun 2013 14:49:02 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.51.p2
Message-ID: <20130628214902.29127.97246.idtracker@ietfa.amsl.com>
Date: Fri, 28 Jun 2013 14:49:02 -0700
Cc: apps-discuss@ietf.org
Subject: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc5451bis-09.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 28 Jun 2013 21:49:03 -0000

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

	Title           : Message Header Field for Indicating Message Authenticati=
on Status
	Author(s)       : Murray S. Kucherawy
	Filename        : draft-ietf-appsawg-rfc5451bis-09.txt
	Pages           : 47
	Date            : 2013-06-28

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

   This document is a candidate for Internet Standard status.  [RFC
   Editor: Please delete this notation, as I imagine it will be
   indicated some other way.]


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-appsawg-rfc5451bis

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-appsawg-rfc5451bis-09

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-rfc5451bis-09


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From internet-drafts@ietf.org  Fri Jun 28 14:49:04 2013
Return-Path: <internet-drafts@ietf.org>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BDA021F9CF0 for <apps-discuss@ietfa.amsl.com>; Fri, 28 Jun 2013 14:49:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.143
X-Spam-Level: 
X-Spam-Status: No, score=-101.143 tagged_above=-999 required=5 tests=[AWL=-0.762, BAYES_00=-2.599, NO_RELAYS=-0.001, TVD_SPACE_RATIO=2.219, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sCx2iBBB1zh6; Fri, 28 Jun 2013 14:49:03 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7048E21F9CEC; Fri, 28 Jun 2013 14:49:03 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: appsawg-chairs@tools.ietf.org, draft-ietf-appsawg-rfc5451bis@tools.ietf.org, sm+ietf@elandsys.com, apps-discuss@ietf.org, barryleiba@computer.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.51.p2
Message-ID: <20130628214903.29127.76345.idtracker@ietfa.amsl.com>
Date: Fri, 28 Jun 2013 14:49:03 -0700
Subject: [apps-discuss] New Version Notification - draft-ietf-appsawg-rfc5451bis-09.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 28 Jun 2013 21:49:04 -0000

A new version (-09) has been submitted for draft-ietf-appsawg-rfc5451bis:
http://www.ietf.org/internet-drafts/draft-ietf-appsawg-rfc5451bis-09.txt


The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-appsawg-rfc5451bis/

Diff from previous version:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-appsawg-rfc5451bis-09

IETF Secretariat.


From scott@kitterman.com  Fri Jun 28 14:55:57 2013
Return-Path: <scott@kitterman.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D637B21F9CF2 for <apps-discuss@ietfa.amsl.com>; Fri, 28 Jun 2013 14:55:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kILdT4xN6DH2 for <apps-discuss@ietfa.amsl.com>; Fri, 28 Jun 2013 14:55:52 -0700 (PDT)
Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id 2584421F9D19 for <apps-discuss@ietf.org>; Fri, 28 Jun 2013 14:55:45 -0700 (PDT)
Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 0C79520E40F0; Fri, 28 Jun 2013 17:55:44 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1372456544; bh=OWmQXwvaa6Ky72YwKjIFXEfHNteCUrtZgQthv0it94c=; h=From:To:Subject:Date:In-Reply-To:References:From; b=enzUTpL5DJxmrcLU347k1JPnTXOKZadQ1+seVnoYUHmbT4of8n3ajSeFlo6B/e58d 85+9vNbj+S+PGs0zxgCzoDPxHY7dE/+rpGDTM/7Tv3OoiXbzKVIRSYz9LIe3pjXGvf 1ZiKybcpI8uvu49Pv/PEBs0+KObWCO4cHzt4XU1w=
Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id E99CD20E4085;  Fri, 28 Jun 2013 17:55:43 -0400 (EDT)
From: Scott Kitterman <scott@kitterman.com>
To: apps-discuss@ietf.org
Date: Fri, 28 Jun 2013 17:55:43 -0400
Message-ID: <1564153.zYEufhdDMG@scott-latitude-e6320>
User-Agent: KMail/4.10.4 (Linux/3.8.0-25-generic; KDE/4.10.4; i686; ; )
In-Reply-To: <CAL0qLwZh0vgWxAFbeoSn7EOF4Hc7z3Zh7-=arnTAi-hiSuFoMg@mail.gmail.com>
References: <20130628195448.84607.qmail@joyce.lan> <1890595.pPFvXvIWb5@scott-latitude-e6320> <CAL0qLwZh0vgWxAFbeoSn7EOF4Hc7z3Zh7-=arnTAi-hiSuFoMg@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
X-AV-Checked: ClamAV using ClamSMTP
Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc5451bis-08.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 28 Jun 2013 21:55:58 -0000

On Friday, June 28, 2013 02:45:35 PM Murray S. Kucherawy wrote:
> On Fri, Jun 28, 2013 at 1:00 PM, Scott Kitterman <scott@kitterman.com>wrote:
> > > Yes, that's a recent change to avoid ambiguity where foo1 might be a
> > > method called foo1 or might be method foo version 1.  Looks like
> > > Murray missed updating the example.
> > 
> > It's the other way around.  -08 removes the "/", so think it changed in
> > exactly the wrong way.
> 
> Scott's correct; I over-undid the controversial change that got reverted.
> I'll clean it up and post again.  Apologies for the noise.
> 
> -MSK

Thanks.  that takes care of it.

Scott K

From ietfc@btconnect.com  Sat Jun 29 04:26:52 2013
Return-Path: <ietfc@btconnect.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9B0221F9FCF for <apps-discuss@ietfa.amsl.com>; Sat, 29 Jun 2013 04:26:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K-zrsvsdziA3 for <apps-discuss@ietfa.amsl.com>; Sat, 29 Jun 2013 04:26:48 -0700 (PDT)
Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0253.outbound.messaging.microsoft.com [213.199.154.253]) by ietfa.amsl.com (Postfix) with ESMTP id F2CBC21F9FDD for <apps-discuss@ietf.org>; Sat, 29 Jun 2013 04:26:47 -0700 (PDT)
Received: from mail78-db9-R.bigfish.com (10.174.16.226) by DB9EHSOBE014.bigfish.com (10.174.14.77) with Microsoft SMTP Server id 14.1.225.23; Sat, 29 Jun 2013 11:26:46 +0000
Received: from mail78-db9 (localhost [127.0.0.1])	by mail78-db9-R.bigfish.com (Postfix) with ESMTP id 25EA61E00C2; Sat, 29 Jun 2013 11:26:46 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.249.85; KIP:(null); UIP:(null); IPV:NLI; H:AMSPRD0710HT001.eurprd07.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -16
X-BigFish: PS-16(zz98dI9371I542I1432I1418Idb82hzz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275bh8275dhz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h304l1d11m1155h)
Received: from mail78-db9 (localhost.localdomain [127.0.0.1]) by mail78-db9 (MessageSwitch) id 1372505204486164_13218; Sat, 29 Jun 2013 11:26:44 +0000 (UTC)
Received: from DB9EHSMHS028.bigfish.com (unknown [10.174.16.252])	by mail78-db9.bigfish.com (Postfix) with ESMTP id 703C522004B; Sat, 29 Jun 2013 11:26:44 +0000 (UTC)
Received: from AMSPRD0710HT001.eurprd07.prod.outlook.com (157.56.249.85) by DB9EHSMHS028.bigfish.com (10.174.14.38) with Microsoft SMTP Server (TLS) id 14.16.227.3; Sat, 29 Jun 2013 11:26:44 +0000
Received: from DB3PRD0511HT003.eurprd05.prod.outlook.com (157.56.254.213) by pod51017.outlook.com (10.255.160.164) with Microsoft SMTP Server (TLS) id 14.16.324.0; Sat, 29 Jun 2013 11:26:34 +0000
Message-ID: <00be01ce74bb$939142c0$4001a8c0@gateway.2wire.net>
From: t.petch <ietfc@btconnect.com>
To: Matthew Kerwin <matthew@kerwin.net.au>, "Murray S. Kucherawy" <superuser@gmail.com>
References: <CACweHNCTSZ3xvZPLeahZmJVg6pYheqvPfGxa_GPc1O9Aomi9hw@mail.gmail.com><CAL0qLwYNx17z42_pNucbPGY9ZvMx9yV9hnD74Nfhje_Rx9rcaw@mail.gmail.com> <CACweHNBQJRXaS5EZn-WEg7RSe_CMYjF-eTrRd8n1nCAEXmAyqQ@mail.gmail.com>
Date: Sat, 29 Jun 2013 12:26:52 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [157.56.254.213]
X-OriginatorOrg: btconnect.com
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
Cc: IETF Apps Discuss <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] File URI Scheme
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 29 Jun 2013 11:26:53 -0000

Were the WG Chairs to undertake a poll as to whether or not this I-D is
adopted, I would oppose that request at this time

Two reasons
First; should this be discussed in whole or part on the URI list?  I
think that that needs resolving before adoption.

Second; it is not in the right format for an IETF I-D; I think most of
what
I have in mind would show up with a nits check, and these should be
fixed
first (given that much of the rest comes from an expired I-D, which was
discussed on the URI :-)

Tom Petch

----- Original Message -----
From: "Matthew Kerwin" <matthew@kerwin.net.au>
To: "Murray S. Kucherawy" <superuser@gmail.com>
Cc: "IETF Apps Discuss" <apps-discuss@ietf.org>
Sent: Wednesday, June 26, 2013 2:10 AM
> On 26 June 2013 04:24, Murray S. Kucherawy <superuser@gmail.com>
wrote:
> > On Mon, Jun 24, 2013 at 8:34 PM, Matthew Kerwin
<matthew@kerwin.net.au>
> > wrote:
> >>
> >> Would you please consider creating a draft for the file: URI scheme
> >> (or taking over my existing draft); or if not, point me to some
> >> resources or discussions about why the file scheme seems to have
gone
> >> out of vogue?
> >>
> >> The current revision of my draft is
> >> <http://tools.ietf.org/html/draft-kerwin-file-scheme-03> , and the
> >> working copy is on github
> >> <https://github.com/phluid61/file-uri-scheme>
> >>
> >
> > By "creating a draft", are you asking APPSAWG to adopt yours, or are
you
> > asking us to come up with something else and process that?
> >
> > -MSK, APPSAWG co-chair
> >
>
> I guess I was leaving that up to the WG to decide, but my proposal is
> to adopt my draft and build on it from there.
>
> --
>   Matthew Kerwin, B.Sc (CompSci) (Hons)
>   http://matthew.kerwin.net.au/
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>



From johnl@iecc.com  Sat Jun 29 10:32:47 2013
Return-Path: <johnl@iecc.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1747311E818E for <apps-discuss@ietfa.amsl.com>; Sat, 29 Jun 2013 10:32:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level: 
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IER6dhIbp-Cp for <apps-discuss@ietfa.amsl.com>; Sat, 29 Jun 2013 10:32:46 -0700 (PDT)
Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 4DBA911E8186 for <apps-discuss@ietf.org>; Sat, 29 Jun 2013 10:32:42 -0700 (PDT)
Received: (qmail 84000 invoked from network); 29 Jun 2013 17:32:40 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=1481e.51cf1a38.k1306; bh=UKA7KO2N4W86NUl6vlkL39SqMtIl66JNgjzEeG8PlVc=; b=iShGjcJqcVjDYpZfsoI08A3E7W3T7fzWP+EXxz/QHaHKXPVvlJhC62Thcc2dgdhNXU7xDgANcoxJAtpiCJiZ32xW6nlfO31tGTfleXvFlhhyRB8ah1BJk0QLqRrKfsfsw8eXf0BxiHyutCXJimQ7tOme3cK37+RVryNcQwHuBxrpx7FXldGGJzEBaN24V3wwQq+Eas4yyLGAd6VDXE+sHlC0ELo+JRl8cIYYiCqe6UUjvCgGV6/PUQwqY4wnH0IT
Received: (ofmipd 127.0.0.1); 29 Jun 2013 17:32:18 -0000
Date: 29 Jun 2013 13:32:39 -0400
Message-ID: <alpine.BSF.2.00.1306291330410.97113@joyce.lan>
From: "John R. Levine" <johnl@iecc.com>
To: "John Levine" <johnl@taugh.com>
In-Reply-To: <20130625204239.35722.qmail@joyce.lan>
References: <20130625204239.35722.qmail@joyce.lan>
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
Cleverness: None detected
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: apps-discuss@ietf.org
Subject: Re: [apps-discuss] Remember the MX 0 . draft?
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 29 Jun 2013 17:32:47 -0000

>>>   nomailhere.example. MX 0 .
>
>> Never heard of this before.  Are there implementations?
>
> I did some experiements:
>
> Yahoo: mail fails immediately
>
> Gmail, AOL: doesn't fail immediately, will report back next week
>
> Hotmail/Outlook.com: some attempts fail with an odd error message, some succeed

Gmail, AOL, and Hotmail all failed eventually with complaints about bad 
DNS records.  So there is room for more consistent implementations.

The only objection I've heard was from someone who expected it wouldn't 
work because there might be A records at ".".  Other than that, it still 
seems uncontroversial.

Do I formally ask appsarea to take it up, or what?

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 datapacrat@gmail.com  Sat Jun 29 20:27:40 2013
Return-Path: <datapacrat@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5093221F9D2E for <apps-discuss@ietfa.amsl.com>; Sat, 29 Jun 2013 20:27:40 -0700 (PDT)
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=[AWL=0.160,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sdrxQtuOfJhT for <apps-discuss@ietfa.amsl.com>; Sat, 29 Jun 2013 20:27:39 -0700 (PDT)
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 89A2A21F9D94 for <apps-discuss@ietf.org>; Sat, 29 Jun 2013 20:27:39 -0700 (PDT)
Received: by mail-we0-f177.google.com with SMTP id m19so2348075wev.36 for <apps-discuss@ietf.org>; Sat, 29 Jun 2013 20:27:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=dtaSXHUL0r3TixaR3vlz9EYa8yOLU8HwmFjkPYTW9Tc=; b=GD/xEky19LYjhsfr0MWoOjJT+pGr173PuAR8dIzro+SSPQVas3pyzGwGCxyF6hZdzX UvXfLFtz5cuqW204JfV45d5ZcifkjNQsQB1IB6GrVT1xaHQVkpoAm0pbf4IQjAtOMrXd aBwtfKuprjiVddPcVr/IOWfy7Q2KSUVU4PS9Sopy1iaE5YtHqrDEDVj8FU6na+DvWY1d aOa6kDevP0EoO2xUdmE45z3GMcTzh3prgzzwY5bHbqvV4u9Y4K5AnruL+SHQNEOUWclS qTsU1gc+2XLVJ5UoMJ0TWZ4aIjGvqoEUm1JF2hDoD/w5Po2buyxENBl0Yrjbhl/ewmQ1 74kQ==
MIME-Version: 1.0
X-Received: by 10.194.216.99 with SMTP id op3mr16670085wjc.52.1372562858731; Sat, 29 Jun 2013 20:27:38 -0700 (PDT)
Received: by 10.194.243.193 with HTTP; Sat, 29 Jun 2013 20:27:38 -0700 (PDT)
Date: Sat, 29 Jun 2013 23:27:38 -0400
Message-ID: <CAB5WduAQxA37JnOmZykcVjzQ8O+r-TYwbAZcE5dmaJgVMpq4rw@mail.gmail.com>
From: DataPacRat <datapacrat@gmail.com>
To: apps-discuss@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Subject: [apps-discuss]  Initial inquiry: P2P identity authentication
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Jun 2013 03:27:40 -0000

Over on the vcarddav and pkix WGs, I'm in the middle of proposing a
"signed vCard" extension to the current vCard format. I'm hoping to
use that as the basis for a distributed, peer-to-peer identity
authentication system; one that doesn't rely on email addresses as
personal identifiers, or on any particular third-party authorities.

The webfist extension to webfinger would be just about ideal, save for
its reliance on DKIM-verified email addresses. Would I be correct
that, as this WG seems to be the home of webfinger, this would be the
mailing list to start discussing an upgrade or fork of webfist? If
not, might I ask for a recommendation of where I should go instead?


Thank you for your time,
--
DataPacRat
"Then again, I could be wrong."

From datapacrat@gmail.com  Sat Jun 29 20:58:14 2013
Return-Path: <datapacrat@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E02421F9AF9 for <apps-discuss@ietfa.amsl.com>; Sat, 29 Jun 2013 20:58:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.452
X-Spam-Level: 
X-Spam-Status: No, score=-2.452 tagged_above=-999 required=5 tests=[AWL=0.148,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LzL5bM6Ncilc for <apps-discuss@ietfa.amsl.com>; Sat, 29 Jun 2013 20:58:13 -0700 (PDT)
Received: from mail-wg0-x235.google.com (mail-wg0-x235.google.com [IPv6:2a00:1450:400c:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB5721F84B5 for <apps-discuss@ietf.org>; Sat, 29 Jun 2013 20:58:13 -0700 (PDT)
Received: by mail-wg0-f53.google.com with SMTP id y10so2867639wgg.32 for <apps-discuss@ietf.org>; Sat, 29 Jun 2013 20:58:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=PzWRTEHGG11JF7Ym9GSZfEN2gnwwEJneabpqCqMUeeE=; b=K30gitdirblDlIDiGfVletQBw5oVBnZzajavYmKeeyH/kWCTTrjNRPE6iDpuFM0nTu 3tSfr1A9ltBviUIg+oQhH6W7PhEE/mu6SrEN5h/6w0y9+Z5wYmDdbGh0hcZ84yoU+ffM qAHKEymJccvoUXVAGxM5B5o5R23sVBuVoZl1zz9PKiinO7rji49u3ofBLri8G8sVWI2N gZ/Peng6eRbEh/25AUav2wumW1Aw8SDNOoBUWlSwf6+N5XwgyiJ5V7w77AMLwGdGLrF0 tmp+IXs0LwS0FdLklGJeM2ItDc6mAmLgxDmfogBEBCDD/PbsR9YLCCZ/g2UIOJUXdosM MdUA==
MIME-Version: 1.0
X-Received: by 10.194.47.167 with SMTP id e7mr16505681wjn.57.1372564691383; Sat, 29 Jun 2013 20:58:11 -0700 (PDT)
Received: by 10.194.243.193 with HTTP; Sat, 29 Jun 2013 20:58:11 -0700 (PDT)
In-Reply-To: <CAKaEYh++UfRNt7s7o1muoFG3pznZLK6MwvgFsyREJ=Avq_bGiA@mail.gmail.com>
References: <CAB5WduAQxA37JnOmZykcVjzQ8O+r-TYwbAZcE5dmaJgVMpq4rw@mail.gmail.com> <CAKaEYh++UfRNt7s7o1muoFG3pznZLK6MwvgFsyREJ=Avq_bGiA@mail.gmail.com>
Date: Sat, 29 Jun 2013 23:58:11 -0400
Message-ID: <CAB5WduBr9Rua4On3_YUajh28MZw=u1z+m1Tpa0naZ7u-ybFi9Q@mail.gmail.com>
From: DataPacRat <datapacrat@gmail.com>
To: Melvin Carvalho <melvincarvalho@gmail.com>, apps-discuss@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [apps-discuss] Initial inquiry: P2P identity authentication
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Jun 2013 03:58:14 -0000

On Sat, Jun 29, 2013 at 11:48 PM, Melvin Carvalho
<melvincarvalho@gmail.com> wrote:
> On 30 June 2013 05:27, DataPacRat <datapacrat@gmail.com> wrote:

>> Over on the vcarddav and pkix WGs, I'm in the middle of proposing a
>> "signed vCard" extension to the current vCard format. I'm hoping to
>> use that as the basis for a distributed, peer-to-peer identity
>> authentication system; one that doesn't rely on email addresses as
>> personal identifiers, or on any particular third-party authorities.
>>
>> The webfist extension to webfinger would be just about ideal, save for
>> its reliance on DKIM-verified email addresses. Would I be correct
>> that, as this WG seems to be the home of webfinger, this would be the
>> mailing list to start discussing an upgrade or fork of webfist? If
>> not, might I ask for a recommendation of where I should go instead?

> Sounds amazing.  We desperately need identity that does not rely on email.
>
> Do you have a pointer to your proposal?

At the moment, not really. At this stage, I'm still focusing on the
signed vCard format, and am paying attention to infrastructure mostly
to have a better idea of what needs to be included in the vCard
extension. (My three most recent messages to vcarddav -
https://www.ietf.org/mail-archive/web/vcarddav/current/msg02758.html ,
 https://www.ietf.org/mail-archive/web/vcarddav/current/msg02760.html
, and https://www.ietf.org/mail-archive/web/vcarddav/current/msg02761.html
- cover the rough outline of what seems to be required there, though I
welcome any and all constructive criticism.)


Thank you for your time,
--
DataPacRat
"What can be asserted without evidence can also be dismissed without
evidence." -- Christopher Hitchens

From sakimura@gmail.com  Sat Jun 29 21:14:25 2013
Return-Path: <sakimura@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C246321F9D16 for <apps-discuss@ietfa.amsl.com>; Sat, 29 Jun 2013 21:14:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JCYagtK+7PFZ for <apps-discuss@ietfa.amsl.com>; Sat, 29 Jun 2013 21:14:24 -0700 (PDT)
Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 36BC821F9D05 for <apps-discuss@ietf.org>; Sat, 29 Jun 2013 21:14:23 -0700 (PDT)
Received: by mail-la0-f41.google.com with SMTP id fn20so3371006lab.14 for <apps-discuss@ietf.org>; Sat, 29 Jun 2013 21:14:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=44GQ1qNjNevuS3L9yOW7W0N8c6vmCn4+M9ASowXg3Pg=; b=yR0J7pfYDUt6OXMMr2gCaS5Oc6OvfVKQFFoOztPmhK0btLf6akUp+iNNJcqsrocTxb 4aiQ6hQ9Z3AfnMAIYFw+xZIc/2vzNzLznaAogM1D53NT6tOq6tf8owRPX+lvA5au32an puFVeY39ZVSTtkyyRDzF3dUY5i4BpASkjWH/p4ZPHIRPXGLrpdic8MmPK2On6vi5Pz3k kpMWp7VXOHl4zgnkkCPqDKeWo4FN1fsn1Q+s3GhooG0HoCvtgun6qOpbRDK56dAxL1X6 qer3oQDZEmDfwW+hb4BQRJ9zZ5UwJp7iWM4Fw8s+6Kx1VJ/vsImvck5Jk2NtcI3TYIMe nYWg==
MIME-Version: 1.0
X-Received: by 10.152.88.42 with SMTP id bd10mr9466957lab.32.1372565663100; Sat, 29 Jun 2013 21:14:23 -0700 (PDT)
Received: by 10.112.199.33 with HTTP; Sat, 29 Jun 2013 21:14:23 -0700 (PDT)
In-Reply-To: <CAB5WduBr9Rua4On3_YUajh28MZw=u1z+m1Tpa0naZ7u-ybFi9Q@mail.gmail.com>
References: <CAB5WduAQxA37JnOmZykcVjzQ8O+r-TYwbAZcE5dmaJgVMpq4rw@mail.gmail.com> <CAKaEYh++UfRNt7s7o1muoFG3pznZLK6MwvgFsyREJ=Avq_bGiA@mail.gmail.com> <CAB5WduBr9Rua4On3_YUajh28MZw=u1z+m1Tpa0naZ7u-ybFi9Q@mail.gmail.com>
Date: Sun, 30 Jun 2013 13:14:23 +0900
Message-ID: <CABzCy2Cg7QwiHfCs2xavLcRrupjSXJA-hWoHh60us8p5r0icgQ@mail.gmail.com>
From: Nat Sakimura <sakimura@gmail.com>
To: DataPacRat <datapacrat@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c35098c7b3e104e05758dd
Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Initial inquiry: P2P identity authentication
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Jun 2013 04:14:25 -0000

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

So it sounds a bit like X.509 or ID Token in OpenID Connect (JWT + JWS) in
a different format.

Through what kind of user interface t the user is going to use it?



2013/6/30 DataPacRat <datapacrat@gmail.com>

> On Sat, Jun 29, 2013 at 11:48 PM, Melvin Carvalho
> <melvincarvalho@gmail.com> wrote:
> > On 30 June 2013 05:27, DataPacRat <datapacrat@gmail.com> wrote:
>
> >> Over on the vcarddav and pkix WGs, I'm in the middle of proposing a
> >> "signed vCard" extension to the current vCard format. I'm hoping to
> >> use that as the basis for a distributed, peer-to-peer identity
> >> authentication system; one that doesn't rely on email addresses as
> >> personal identifiers, or on any particular third-party authorities.
> >>
> >> The webfist extension to webfinger would be just about ideal, save for
> >> its reliance on DKIM-verified email addresses. Would I be correct
> >> that, as this WG seems to be the home of webfinger, this would be the
> >> mailing list to start discussing an upgrade or fork of webfist? If
> >> not, might I ask for a recommendation of where I should go instead?
>
> > Sounds amazing.  We desperately need identity that does not rely on
> email.
> >
> > Do you have a pointer to your proposal?
>
> At the moment, not really. At this stage, I'm still focusing on the
> signed vCard format, and am paying attention to infrastructure mostly
> to have a better idea of what needs to be included in the vCard
> extension. (My three most recent messages to vcarddav -
> https://www.ietf.org/mail-archive/web/vcarddav/current/msg02758.html ,
>  https://www.ietf.org/mail-archive/web/vcarddav/current/msg02760.html
> , and https://www.ietf.org/mail-archive/web/vcarddav/current/msg02761.html
> - cover the rough outline of what seems to be required there, though I
> welcome any and all constructive criticism.)
>
>
> Thank you for your time,
> --
> DataPacRat
> "What can be asserted without evidence can also be dismissed without
> evidence." -- Christopher Hitchens
> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss
>



-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

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

<div dir=3D"ltr">So it sounds a bit like X.509 or ID Token in OpenID Connec=
t (JWT + JWS) in a different format.=A0<div><br></div><div>Through what kin=
d of user interface t the user is going to use it?=A0<br><div><br></div></d=
iv>
</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">2013/6/=
30 DataPacRat <span dir=3D"ltr">&lt;<a href=3D"mailto:datapacrat@gmail.com"=
 target=3D"_blank">datapacrat@gmail.com</a>&gt;</span><br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
On Sat, Jun 29, 2013 at 11:48 PM, Melvin Carvalho<br>
&lt;<a href=3D"mailto:melvincarvalho@gmail.com">melvincarvalho@gmail.com</a=
>&gt; wrote:<br>
<div class=3D"im">&gt; On 30 June 2013 05:27, DataPacRat &lt;<a href=3D"mai=
lto:datapacrat@gmail.com">datapacrat@gmail.com</a>&gt; wrote:<br>
<br>
&gt;&gt; Over on the vcarddav and pkix WGs, I&#39;m in the middle of propos=
ing a<br>
&gt;&gt; &quot;signed vCard&quot; extension to the current vCard format. I&=
#39;m hoping to<br>
&gt;&gt; use that as the basis for a distributed, peer-to-peer identity<br>
&gt;&gt; authentication system; one that doesn&#39;t rely on email addresse=
s as<br>
&gt;&gt; personal identifiers, or on any particular third-party authorities=
.<br>
&gt;&gt;<br>
&gt;&gt; The webfist extension to webfinger would be just about ideal, save=
 for<br>
&gt;&gt; its reliance on DKIM-verified email addresses. Would I be correct<=
br>
&gt;&gt; that, as this WG seems to be the home of webfinger, this would be =
the<br>
&gt;&gt; mailing list to start discussing an upgrade or fork of webfist? If=
<br>
&gt;&gt; not, might I ask for a recommendation of where I should go instead=
?<br>
<br>
</div>&gt; Sounds amazing. =A0We desperately need identity that does not re=
ly on email.<br>
&gt;<br>
&gt; Do you have a pointer to your proposal?<br>
<br>
At the moment, not really. At this stage, I&#39;m still focusing on the<br>
signed vCard format, and am paying attention to infrastructure mostly<br>
to have a better idea of what needs to be included in the vCard<br>
extension. (My three most recent messages to vcarddav -<br>
<a href=3D"https://www.ietf.org/mail-archive/web/vcarddav/current/msg02758.=
html" target=3D"_blank">https://www.ietf.org/mail-archive/web/vcarddav/curr=
ent/msg02758.html</a> ,<br>
=A0<a href=3D"https://www.ietf.org/mail-archive/web/vcarddav/current/msg027=
60.html" target=3D"_blank">https://www.ietf.org/mail-archive/web/vcarddav/c=
urrent/msg02760.html</a><br>
, and <a href=3D"https://www.ietf.org/mail-archive/web/vcarddav/current/msg=
02761.html" target=3D"_blank">https://www.ietf.org/mail-archive/web/vcardda=
v/current/msg02761.html</a><br>
- cover the rough outline of what seems to be required there, though I<br>
welcome any and all constructive criticism.)<br>
<div class=3D"im"><br>
<br>
Thank you for your time,<br>
--<br>
DataPacRat<br>
</div>&quot;What can be asserted without evidence can also be dismissed wit=
hout<br>
evidence.&quot; -- Christopher Hitchens<br>
<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><br clear=3D"all"><div><br></div>-- <br>=
Nat Sakimura (=3Dnat)<div>Chairman, OpenID Foundation<br><a href=3D"http://=
nat.sakimura.org/" target=3D"_blank">http://nat.sakimura.org/</a><br>@_nat_=
en</div>

</div>

--001a11c35098c7b3e104e05758dd--

From datapacrat@gmail.com  Sat Jun 29 21:27:46 2013
Return-Path: <datapacrat@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0192121F9D41 for <apps-discuss@ietfa.amsl.com>; Sat, 29 Jun 2013 21:27:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.463
X-Spam-Level: 
X-Spam-Status: No, score=-2.463 tagged_above=-999 required=5 tests=[AWL=0.137,  BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e6bKlb8vWq3i for <apps-discuss@ietfa.amsl.com>; Sat, 29 Jun 2013 21:27:45 -0700 (PDT)
Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id F170221F9CE1 for <apps-discuss@ietf.org>; Sat, 29 Jun 2013 21:27:42 -0700 (PDT)
Received: by mail-wg0-f51.google.com with SMTP id e11so2837036wgh.30 for <apps-discuss@ietf.org>; Sat, 29 Jun 2013 21:27:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=N6x290wW3Iob45JeaEbAVSFalyHKMPGlxsVMrRbbEEw=; b=c7AJKBg3p26Mf8N9ZLjVv6x2LwvDoR1GmbRQQbzP+1lwj+TipIybawH9kH4or+L54Z UW2UvLpa6NC/mGAe2I0ycAoUnmVIE7wTF/wG3p6XI6+53iYqchLBcL1s8oW481tL2608 upaWXbynPCp5Rl11mb4vqZtTpUKzPKmnk5KDtNla6ro5etbzmCJ/5xhrlnQOQacr78Rf odgOZHGcJb0WahiE46zOTPVvN3HWGh5maVCkIMrjeWUU4bAhUzujvx5lRw0sTXHExYkM 6E1gyA2oJZZKJJ2h1OxEMxpMo79X7hDzOTCt24Ylb6wuT06AV9EJcdoai1xJzOzdeWLk NSfA==
MIME-Version: 1.0
X-Received: by 10.180.198.10 with SMTP id iy10mr8847739wic.29.1372566461145; Sat, 29 Jun 2013 21:27:41 -0700 (PDT)
Received: by 10.194.243.193 with HTTP; Sat, 29 Jun 2013 21:27:41 -0700 (PDT)
In-Reply-To: <CABzCy2Cg7QwiHfCs2xavLcRrupjSXJA-hWoHh60us8p5r0icgQ@mail.gmail.com>
References: <CAB5WduAQxA37JnOmZykcVjzQ8O+r-TYwbAZcE5dmaJgVMpq4rw@mail.gmail.com> <CAKaEYh++UfRNt7s7o1muoFG3pznZLK6MwvgFsyREJ=Avq_bGiA@mail.gmail.com> <CAB5WduBr9Rua4On3_YUajh28MZw=u1z+m1Tpa0naZ7u-ybFi9Q@mail.gmail.com> <CABzCy2Cg7QwiHfCs2xavLcRrupjSXJA-hWoHh60us8p5r0icgQ@mail.gmail.com>
Date: Sun, 30 Jun 2013 00:27:41 -0400
Message-ID: <CAB5WduB2WN48ZOERr6J-s2_2xx1CC0-bMjFzNAVogd3PyOs4wQ@mail.gmail.com>
From: DataPacRat <datapacrat@gmail.com>
To: Nat Sakimura <sakimura@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "apps-discuss@ietf.org" <apps-discuss@ietf.org>
Subject: Re: [apps-discuss] Initial inquiry: P2P identity authentication
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Jun 2013 04:27:46 -0000

On Sun, Jun 30, 2013 at 12:14 AM, Nat Sakimura <sakimura@gmail.com> wrote:
> So it sounds a bit like X.509 or ID Token in OpenID Connect (JWT + JWS) in a
> different format.

At least one main difference between what I'm hoping to achieve, and
what X.509 currently does, is that X.509 relies on Certificate
Authorities which are implicitly trusted. I'm trying to lay the
groundwork to allow anyone and their grandmother to act as ad-hoc CAs,
with a few Bayesian tricks to allow easy evaluation of the
trustworthiness of any such authority or the certificates so
authorized.


> Through what kind of user interface t the user is going to use it?

One of the use-cases I hope to accomplish is for an end-user to click
on a link leading to a signed vCard file (or possibly the JSON
variant, jCard) stored somewhere, which fires up their preferred
contacts/email software, which then works through the authentication
hash, the authority's authentication hash, and so forth, to arrive at
a final trustworthiness score to present to the user. (For a few
mathematical reasons, I favor using a logarithmic unit called
'decibans' for that score, which in most practical cases, can be an
integer between -127 and 127.)

Another of the use-cases is for somebody participating in a Tor-hosted
chat forum to be able to easily assert their identity over a
Tor-hosted IM client, such as by pasting a signed vCard (linked to the
forum identity, rather than an email address) inline in the chat
window, which the contact software can evaluate as above.


Thank you for your time,
--
DataPacRat
"Then again, I could be wrong."

From mike5guo@gmail.com  Sun Jun 30 01:36:10 2013
Return-Path: <mike5guo@gmail.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB87021F9DFE for <apps-discuss@ietfa.amsl.com>; Sun, 30 Jun 2013 01:36:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.246
X-Spam-Level: **
X-Spam-Status: No, score=2.246 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, SARE_SUB_ENC_GB2312=1.345]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wQc5C7uZRa7T for <apps-discuss@ietfa.amsl.com>; Sun, 30 Jun 2013 01:36:10 -0700 (PDT)
Received: from mail-oa0-x22c.google.com (mail-oa0-x22c.google.com [IPv6:2607:f8b0:4003:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 7CF4121F9DC7 for <apps-discuss@ietf.org>; Sun, 30 Jun 2013 01:36:10 -0700 (PDT)
Received: by mail-oa0-f44.google.com with SMTP id l10so3742593oag.17 for <apps-discuss@ietf.org>; Sun, 30 Jun 2013 01:36:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=yAKGo+NOQ3DJPKXh4eY3Upq7JCX35PmY7w3ZuErzI7U=; b=dIoHMCCRN22ddalmcye1Byh3KxEDCq3kO3yvcqtKUqfUCiSAYVYuqeDHcwvA5AH8v0 6IaZwLUqfOOplbheFVsO4uGSnd2elbgvKKOofjlz4qAK5nnH6SU1m+gYCDeQ57LHqxsi WqWwyIljRnweQAiNUT/YHlpnYfznPsyezO0L592OGWAbcFlnrH4AtApgrJgado0D7Qhl RDlIstYWrMIR11KsqMuMUYd57ma1sPkoie8r+/JPwFDyRe7/bxzz3d0JNx279E125KDm iTIzt5jc4RsVDtzjXe7Ibm2u1khPH+Cz3HMa5xy0osBtS7CC5UlJ5iwZpFyB+YIGArR0 WKUg==
MIME-Version: 1.0
X-Received: by 10.60.80.165 with SMTP id s5mr7794613oex.55.1372581368882; Sun, 30 Jun 2013 01:36:08 -0700 (PDT)
Received: by 10.182.250.130 with HTTP; Sun, 30 Jun 2013 01:36:08 -0700 (PDT)
Date: Sun, 30 Jun 2013 16:36:08 +0800
Message-ID: <CAMFEDe5Zk3hGBLMikZRkQxL_fp2SMZhVCEy49_nnW9=93T-qvQ@mail.gmail.com>
From: Zhun Guo <mike5guo@gmail.com>
To: apps-discuss@ietf.org
Content-Type: multipart/alternative; boundary=089e012299baeaead104e05b0078
Subject: [apps-discuss] =?gb2312?b?V2hvIHVzZSBvbmxpbmUgb2ZmaWNlIHNvZnR3?= =?gb2312?b?YXJlICxzdWNoIGFzIEdvb2dsZSBkcml2ZSAsTWljcm9zb2Z0IG9m?= =?gb2312?b?ZmljZSAzNjUsIERvIHlvdSB0aGluayBpdCBuZWVkIGJyZWFrIHRo?= =?gb2312?b?ZSBpbmZvcm1hdGlvbiBpc2xhbmSjvw==?=
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Jun 2013 08:36:11 -0000

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

Dear all,
Who use online office software ,such as Google drive ,Microsoft office 365,
Do you think it need break the information island (information silo)? I
have subitted a Internet-drafts about this topic :
The Interconnection and Interoperability of Different Cloud-office
Applications (IDCOA) with the HTML File Format ,
https://datatracker.ietf.org/doc/draft-guo-idoca-with-the-html-file-format/
 . Please give me more suggestion!
Best regards!

Zhun Guo

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

<div dir=3D"ltr">Dear all,=A0<div>Who use online office software ,such as G=
oogle drive ,Microsoft office 365, Do you think it need break the informati=
on island (information silo)? I have subitted a Internet-drafts about this =
topic :<br>
</div><h1 style=3D"margin:0px 0px 0.5em;font-size:22px;color:rgb(0,0,0);fon=
t-family:arial,helvetica,clean,sans-serif">The Interconnection and Interope=
rability of Different Cloud-office Applications (IDCOA) with the HTML File =
Format ,<a href=3D"https://datatracker.ietf.org/doc/draft-guo-idoca-with-th=
e-html-file-format/" style=3D"font-family:arial;font-size:small;font-weight=
:normal">https://datatracker.ietf.org/doc/draft-guo-idoca-with-the-html-fil=
e-format/</a>=A0.<span style=3D"font-family:arial;font-size:small;font-weig=
ht:normal;color:rgb(34,34,34)">=A0Please give me more suggestion!</span></h=
1>
<div style><span style=3D"font-family:arial;font-size:small;font-weight:nor=
mal;color:rgb(34,34,34)">Best regards!</span></div><div style><span style=
=3D"font-family:arial;font-size:small;font-weight:normal;color:rgb(34,34,34=
)"><br>
</span></div><div style><span style=3D"font-family:arial;font-size:small;fo=
nt-weight:normal;color:rgb(34,34,34)">Zhun Guo</span></div></div>

--089e012299baeaead104e05b0078--

From johnl@taugh.com  Sun Jun 30 15:39:51 2013
Return-Path: <johnl@taugh.com>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EFA121F90CD for <apps-discuss@ietfa.amsl.com>; Sun, 30 Jun 2013 15:39:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.3
X-Spam-Level: 
X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJOjWbK8eIhy for <apps-discuss@ietfa.amsl.com>; Sun, 30 Jun 2013 15:39:50 -0700 (PDT)
Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id AF0C721F9BF7 for <apps-discuss@ietf.org>; Sun, 30 Jun 2013 15:39:45 -0700 (PDT)
Received: (qmail 4559 invoked from network); 30 Jun 2013 22:39:45 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:user-agent:cleverness; s=11ce.51d0b3b1.k1306; bh=jlzVPS3VgSUgO/oSmn1rNrm1LESQF8AwWEBgvTphmrc=; b=Tt8l3PugrA35VAuU8HFeerJ1yjVnEdt0BykxHbelCegeNuiBTwtoHGIeiUnK/2W6PkEuqdHqZQ59eU0PZUCsSBJmfR4wS2LX+2Qq9bufmgQXOgoS1/m7600tR/pZv5qxFJhSAzrcCBwJE3R8uAAEFMZXdA7GLcPhU6iF6Z6BiJRv4C3nVuTTYpEzwxJBVuhWG1hjum4O5itqyxtYdtGsa7DkV0tkaf+D4fZx2EiNDd9sF2MyymzsDIFyfaLPXuUQ
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:mime-version:content-type:user-agent:cleverness; s=11ce.51d0b3b1.k1306; bh=jlzVPS3VgSUgO/oSmn1rNrm1LESQF8AwWEBgvTphmrc=; b=s2cRvc4XWI7FvinPPFNqa4yHislgsJ/uqIPTvUqizwxGh/NqdI8wT1NrSWoCKTHLh6iDPoMaCnc3Vleoqgsnxx0CySVBad5HQ0LkQ2+CviCY+uLBT9TxDzYbhuIG8xJkN5qIsUvHD5CS05UJpY2R+OSRty/DpzkwrQJBUWxXWLASVLUrc56J2qDkx116mahOHbFPO9GWyGpndZeHUdERPc0HfFjX8YxjLaxxqg8qAJ1O1AqLnpmzOg0yJK/NLFKh
Received: (ofmipd 127.0.0.1); 30 Jun 2013 22:39:22 -0000
Date: 30 Jun 2013 18:39:44 -0400
Message-ID: <alpine.BSF.2.00.1306301837390.71205@joyce.lan>
From: "John R Levine" <johnl@taugh.com>
To: apps-discuss@ietf.org
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
Cleverness: None detected
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Subject: [apps-discuss] Fwd: I-D Action: draft-levine-dnsextlang-06.txt
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Jun 2013 22:39:51 -0000

This version fixes some nits and adds a flag to say that an RRTYPE 
requires special processing, so a DNS server can notice it and complain if 
it doesn't know what the special processing is.  For provisioning systems 
that just need to parse or generate the record, it generally wouldn't 
matter.

Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

---------- Forwarded message ----------
Date: Sun, 30 Jun 2013 16:28:01
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
Newsgroups: iecc.lists.ietf
Subject: I-D Action: draft-levine-dnsextlang-06.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.


 	Title           : An Extension Language for the DNS
 	Author(s)       : John Levine
                           Paul Vixie
 	Filename        : draft-levine-dnsextlang-06.txt
 	Pages           : 10
 	Date            : 2013-06-30

Abstract:
    Adding new RRTYPEs to the DNS requires that DNS servers and
    provisioning software be upgraded to support each new RRTYPE in
    Master files.  This document defines a DNS extension language
    intended to allow most new RRTYPEs to be supported by adding entries
    to configuration data read by the DNS software, with no software
    changes needed for each RRTYPE.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-levine-dnsextlang

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-levine-dnsextlang-06

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-levine-dnsextlang-06


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt